LLM не знаем какой сейчас год

Проблема банальная, но частая. LLM модели тренированы на какой-то момент, и для некоторых моделей (например, mini) это может быть 2023 год. В результате модель на вопросы типа «сколько лет прошло с ...» и подобные будет отвечать неправильно.

Решение простое — в system prompt всегда передавать:

f"Имей ввиду сегодня {today}."

где today:

today = datetime.now().strftime("%-d %B %Y")

Подпишись 👉🏻 @aigentto 🤖

Факт чекинг RAG системы

RAG берет данные из векторной БД, куда данные попадают в виде чанков (векторов) из ваших документов. Затем есть важный параметр top-k, который определяет, сколько чанков получать при запросе пользователя, то есть будут получены X чанков, наиболее семантически схожих с запросом пользователя. В этом вся магия векторного представления.

Дальше разные настройки LLM (температура и top-k) могут сильно влиять на то, как LLM интерпретирует полученные чанки, и даже если поставить temperature=0, то LLM может изобрести что-то новое (что по факту неправда) из набора чанков.

Для полного избегания этого можно использовать гейт факт-чекинга: после получения ответа от LLM все выбранные чанки, откуда была получена информация и ответ LLM, передаются обратно в нейросеть с вопросом: "найди чанк, из которого получена информация в ответе, используй строгое соответствие, не предлагаю чанки, в которых есть похожая информация". Если чанк не найден или найдено много чанков, то высока вероятность провала гейта факт-чекинга.

Подпишись 👉🏻 @aigentto 🤖

Адаптивный порог выборки top-k векторов

Часто бывает сложно определить, какой top-k нужно выбирать для качественного ответа RAG. Если выбрать мало — не сможет ответить, если много — начнет сочинять.
Плюс этот параметр часто нужно менять после существенного изменения количества и типа документов, на основе которых отвечает RAG.

Но есть способ сделать этот параметр адаптивным. Для начала нужно иметь автооценку ответов. Гейт автооценки можно организовать, как описано тут. После этого, если у нас становится больше score = 0, нужно увеличить top-k. Если стало много score = -1, нужно уменьшить top-k.

Подпишись 👉🏻 @aigentto 🤖

Неполный вопрос от пользователя

Бывает, ленится не LLM, а пользователь системы, и задаёт вопросы, из которых сложно понять, что он спрашивает.

Например: "Хочу поиграть в футбол?" вместо "Где в компании можно поиграть в футбол?". Первый вариант может быть воспринят LLM как просто выражение своего желания, не связанного с тем, что есть в компании, и вместо ответа пользователь получит "Хорошая идея!" 😀

Для исключения недопонимания можно добавить гейт прояснения вопроса. Надо отправить вопрос в LLM и спросить: "В этом сообщении есть вопрос от пользователя или нет? Отвечай да или нет".

Если ответ — нет, то просим LLM прояснить, что хочет пользователь. Это можно сделать и в одном промте по схеме chain-of-thought: "В этом сообщении есть вопрос от пользователя или нет? Если вопроса нет, то задай дополнительный вопрос, проясняющий, что хочет пользователь, если вопрос уже есть — ответь да".

Подпишись 👉🏻 @aigentto 🤖

Динамические промты

Обычно промты для RAG и ИИ-агентов подбираются вручную и фиксируются, пока не обнаруживается новая проблема. После её обнаружения промт апдейтится. Это очень надёжный подход, хорошо себя зарекомендовавший.

Но никто не мешает сделать промты RAG и ИИ-агентов динамическими. Для этого нужно иметь гейт валидации ответа. Если гейт даёт красный сигнал, то проблема может быть в том числе и в промте. После этого мы просим LLM внимательно рассмотреть промт и внести изменения, чтобы улучшить ответ на текущий запрос.

Это не всегда сработает, потому что проблема может быть не в промте. Если не сработало, то промт не меняем, если сработало — новый промт становится новой нормой для конкретного ИИ-агента или RAG-системы. Важно следить, чтобы изменение не было кардинальным, чтобы не поломать другие случаи.

Подпишись 👉🏻 @aigentto 🤖

Рой ИИ-агентов

В системах с большим количеством пользователей имеет смысл применять эволюционный подход к автоулучшению ИИ-агентов и RAG-систем.
Самый простой вариант — создание роя ИИ-агентов/RAG-систем, выполняющих одну и ту же задачу. Агенты имеют слегка модифицированные параметры (промт, top-k, temperature и т.д.).

Затем мы случайным роутингом выбираем очередного агента для ответа. Вес тех агентов, которые получают лучший scoring, растёт, а тех, кто выдаёт плохие ответы — падает. Тем самым плохие вымирают, лучшие выживают. По сути, это A/B/C тестирование с автовыбором лучших.

Ещё раз подчеркну, это может работать только на больших выборках — когда запросов 100–1000. Если запросов десятки, то эволюция будет идти слишком медленно.

Подпишись 👉🏻 @aigentto 🤖

Права на сгенерированный контент

Права на сгенерированный контент по законам РФ принадлежат автору этой генерации, если он внес творческий вклад.

Если ответы бота формируются автоматически (ИИ-агенты и RAG), без творческого вклада конкретного человека, такой контент, скорее всего, не будет считаться объектом авторского права. Исключительные права в этом случае не возникают.

Короче, для RAG и ИИ-агентов по умолчания права на контент не возникают 🧐

Подпишись 👉🏻 @aigentto 🤖

LLM-агенты с памятью сессии — и почему это не всегда плюс

Кажется логичным: чем дольше LLM «помнит» историю диалога, тем умнее и полезнее агент.
Но на практике это часто работает наоборот.

📉 Почему память мешает:

Контекст растёт, и LLM начинает «тянуть» устаревшие детали в новые ответы.

Ошибки из начала сессии переносятся дальше, закрепляясь как «факты».

В длинных цепочках агентов старые промты и ответы могут «переигрывать» свежие данные.

Решения:
1️⃣ Срез по времени — хранить только последние N минут диалога.
2️⃣ Срез по смыслу — в памяти остаются только реплики, релевантные текущей задаче (определяет LLM или скрипт на правилах).
3️⃣ Многослойная память — краткое резюме прошлого опыта + полный контекст текущей задачи.

Иногда агент без долговременной памяти работает быстрее, дешевле и даёт более точные ответы, чем «мудрый» собеседник с полной историей.

Подпишись 👉🏻 @aigentto 🤖

Метрики для LLM-агентов, которые реально полезны

Многие оценивают работу агентов по субъективным отзывам («нравится / не нравится») или по количеству решённых задач.
Но такие метрики почти ничего не говорят о том, почему агент работает хорошо или плохо.

🔍 Что стоит измерять:
1️⃣ Latency — среднее время ответа. Если агент медленный, его не будут использовать, даже если он гениален.
2️⃣ Token efficiency — сколько токенов уходит на решение задачи. Высокий расход = лишний контекст или неэффективные промты.
3️⃣ Success rate по гейту — процент ответов, прошедших автоматическую валидацию (факт-чекинг, структура, ключевые данные).
4️⃣ Self-correction rate — как часто агент исправляет сам себя без участия человека.
5️⃣ Escalation rate — процент задач, которые агент передал человеку (и причины этого).

📈 При регулярном мониторинге этих метрик можно быстро понять, где агент «течёт» — в скорости, в промтах, в архитектуре цепочек или в источниках данных.

Подпишись 👉🏻 @aigentto 🤖

Контекст в RAG — почему модель иногда теряется

Чем больше данных кидаешь модели, тем сложнее ей понять, что именно важно. Просто скинуть всё подряд — не вариант, контекст у LLM ограничен, и лишняя информация только мешает.

Поэтому важно:

🔹 Делить данные на смысловые части, а не просто резать по символам.
🔹 В контекст класть только те куски, которые действительно относятся к запросу.
🔹 Если информация меняется, обязательно обновлять контекст и передавать в system prompt актуальную дату и версию — чтобы модель не жила в прошлом.

В итоге контекст — это не просто набор слов, а структурированная и свежая информация, которая помогает модели давать точные ответы.

Подпишись 👉🏻 @aigentto 🤖

Плотность полезной информации в чатах

Дополнительным источником информации для базы знаний бота по компании могут быть переписки сотрудников в чатах. Если переписок много и они качественные (вопросы и ответы по теме), то это может стать и начальной базой знаний по компании, если никакого другого источника нет.

Но надо помнить про закон чатов — там, как правило, очень-очень низкая плотность полезной информации. Типичный пример на скриншоте 🤦

Данные из чатов обычно закидываются в LLM с промптом типа:
"В приложении файлы html из переписок сотрудников компании. Нужно выбрать полезную информацию по компании, то есть найти факты, которые могут быть важны и другим сотрудникам, и организовать их в текстовый файл. Файл будет использован в базе знаний бота, который отвечает на вопросы сотрудников. Не нужно добавлять личную информацию и переписку, не несущую полезной информации для сотрудников вне контекста конкретных событий. На выходе создай md-файл с фактами и вопросами-ответами."

Подпишись 👉🏻 @aigentto 🤖

Плотность эмоций в чатах 😩

Как показано выше, фактов в чатах сотрудников, как правило, мало, но зато там много эмоций (позитивных и негативных).

На основании этого можно смотреть, что волнует сотрудников, прогнозировать тренды (если делать периодические срезы) и даже предсказывать проблемы HR.

Это та область, которую LLM делает очень хорошо, но мало кто этим пользуется: все хотят фактологических систем, а работа с людьми — это всегда работа как минимум на 50% с их эмоциями.

Такой же анализ можно строить по перепискам с клиентами.

Можно внедрять триггеры (если по теме X эмоции негативные/позитивные, то сообщить об этом) и автоматически создавать алерты.

Подпишись 👉🏻 @aigentto 🤖

LLM нападет на человечество

Вокруг пугают тем, что ИИ нападет на человечество. И есть уже эксперименты, где LLM принимает аморальные решения для достижения поставленной цели.
Но как всегда слона (большую проблему) в лавке и не заметили, реальная проблема — это использование ИИ людьми для незаконных действий.

Мошенники всех мастей уже на пике технологий. Ко мне лично уже приходили аватары на Zoom-собеседование, и HR не заметил, что это не люди 😎

Принимать голосовые или видеозвонки от неизвестных в наше время — это уже достаточно высокая угроза. Текст имеет значительно меньшее влияние.

Возможен и видеозвонок от того, кого вы знаете, тогда лучше перезвонить самому.

Короче, нужно перейти на минимальное доверие ко всем видео/голосовым входящим. Сейчас уже даже сделки с недвижимостью совершаются без созвонов, чата достаточно.

Текст будет единственным валидным способом коммуникации в будущем, до тех пор, пока Elon Musk, не внедрил всем в мозг нейролинк 🧠

Подпишись 👉🏻 @aigentto 🤖

Как сделать ИИ-агента умнее?

Бывает, что ИИ-агент, обученный на документах компании, тупит и многого не знает. Стандартная причина в том, что в документах есть слепок прошлого, а в компании уже многое поменялось и появились новые правила, процессы. Обновлять документы в большой компании — это опять процедура на 3-6 месяцев.

Но есть способ проще — берем ответственных за каждую область и садим их поговорить с ботом (ИИ-агентом) на свою тему. Специалист в своей области быстро выявит места, где у бота неактуальная или неверная информация, и прямо в чате ему скажет: "Вот это не так — а вот так".

Затем берем список никнеймов специалистов и выгружаем все диалоги за этот день, загоняем в LLM и просим создать из этого красивый FAQ в md формате. И подкладываем этот FAQ в базу знаний бота.

Дополнительно можно еще провести кросс-анализ и вычистить старую инфу или даже напрямую автоматом обновить старые документы.

Процедура занимает 1-2 дня.

Подпишись 👉🏻 @aigentto 🤖

Хрупкость всех agentic систем

Во всех мультиагентных системах есть одно хрупкое место — это протокол общения между агентами или роутинг между ними.

По сути, можно сделать жёсткий роутинг прямо в коде. Можно сделать условный роутинг тоже в коде. А можно настроить гибкий роутинг во фреймворках AutoGen, LangChain. Но даже в гибких вариантах это определённая договорённость (правила общения).

Хрупкость в том, что агенты используют LLM, которая может вернуть не совсем то, что ожидается, и да, конечно, они должны валидировать то, что им возвращает LLM, а потом передавать данные следующему агенту в строго определённом формате. Любое изменение кода, промтов и прочего может поломать цепочку. Неожиданный ответ LLM может поломать цепочку. Изменения API вендоров могут поломать одного агента и поломать цепочку.

Это всё норма в мире технологий прошлого, где не было LLM. Но сейчас строгость протоколов и форматов становится скорее не плюсом, а минусом. Ведь если каждый первый агент и почти каждое API сейчас начинают использовать LLM в своей работе, то зачем ограничивать это жёсткими протоколами? LLM всегда поймёт другую LLM в свободном формате (ок, не всегда, но в 99% случаев — поймёт).

Поэтому мир будет двигаться от строго определённых протоколов к гибким и даже к отсутствию протоколов.

Мы провели эксперимент — попробовали загнать множество разных агентов в пространство без протоколов и дали им возможность общаться на человеческом языке, и они отлично справляются. Агенты читают этот общий чат и публикуют свои результаты и наблюдения обратно. В этом, казалось бы, мусоре сообщений возникает чёткое общение и выполнение целей агентов. Без роутинга, без протокола.

Более детально про результаты нашего эксперимента скоро будет статья на habr.

Подпишись 👉🏻 @aigentto 🤖

Вышел RAG ChunkTester

Это фреймворк для автоматического тестирования качества Retrieval-Augmented Generation систем.

Он позволяет быстро оценивать влияние разных стратегий чанкования, настройки эмбеддинга, параметров ретривера и промпта.

Как работает я описывал тут https://habr.com/ru/articles/930008/

Доступен тут https://github.com/alx1379/ChunkTester.

Лицензия Appache-2.0.

Подпишись 👉🏻 @aigentto 🤖

Информационные пузыри в нейросетях

Мы все давно живём в своих инфопузырях. Google/Yandex выдаёт на один и тот же запрос немного разный список линков, подстроенный под вас, социальные сети и видеосервисы выдают нашу ленту. И реклама у нас у каждого уже своя. Это и есть информационный пузырь для каждого из нас — мы получаем не фактически нейтральную информацию, а подстроенную под нас.

В нейросетях это проявляется тем, что LLM знает контекст нашей переписки и будет тоже подстраивать ответы под нас, поэтому для фактологических сервисов (типа RAG-систем) важно для сохранения объективности правильно выстраивать промты, давать минимально нужный контекст и задавать немотивированные вопросы.

Самый банальный пример — это вопрос типа: «Подскажи, какую мне выбрать машину? Мне вообще нравится Toyota, что думаешь?». В ответ на это LLM начнёт рассуждать о Toyota, вместо нейтрального качественного сравнения, потому что вы задаёте вектор разговора, и в LLM это не метафора — весь текст будет переведён в вектор, и избавиться от направления Toyota в этом разговоре уже не удастся.

Для избегания эффекта пузыря вопрос нужно задавать так: «Подскажи, какую мне выбрать машину? Я буду ездить от дома до работы 5 дней в неделю один, и на выходные возить семью (4 человека) погулять в город». То есть мы задаём условия, но не задаём вектор выбора (Toyota).

Подпишись 👉🏻 @aigentto 🤖

Промт для извлечения эмоций

Недавно писал про то, как мало фактов в чатах и как много там эмоций.

Вот полезный промт для извлечения эмоций и тем из чатов:

Ты — аналитик по эмоциям и темам чатов.  
Я передам тебе переписку, а твоя задача:  
1. Для каждого сообщения определить эмоцию (или несколько эмоций) из списка: [радость, интерес, удивление, грусть, злость, раздражение, страх, тревога, нейтральное].  
2. Определить тему сообщения (например: работа, личные отношения, проект, деньги, отдых, здоровье и т.д.).  
3. Сгруппировать сообщения по темам и подсчитать частоту каждой эмоции внутри темы.  
4. Вернуть результат в структурированном JSON формате, пригодном для построения графика «Тема vs Эмоции».

Формат ответа:
{
  "topics": [
    {
      "topic": "название темы",
      "emotions": {
        "радость": число,
        "интерес": число,
        "удивление": число,
        "грусть": число,
        "злость": число,
        "раздражение": число,
        "страх": число,
        "тревога": число,
        "нейтральное": число
      }
    },
    ...
  ]
}

Теперь обработай этот чат:

[ВСТАВЬ ТЕКСТ ПЕРЕПИСКИ]

Подпишись 👉🏻 @aigentto 🤖

LLM спасет локальный debug

Раньше, когда я писал на C/C++, я всегда делал локальный пошаговый debug с отсмотром всех переменных для понимания, где может быть проблема. Сейчас почти никто так не делает, тем более что это все усложняется необходимостью написания большого числа заглушек для такого дебага.

Это был очень мощный инструмент, НО сейчас есть LLM, и простое скармливание кода с просьбой дебагинга находит 90% потенциальных проблем 👏

Подпишись 👉🏻 @aigentto 🤖

Очень лёгкий фреймворк (low-code) для Agentic AI

Наткнулся на очень простой фрейм для создания мультиагентных систем. Намного проще, легче и красивее, чем LangChain, AutoGen и прочие монстры.

Там уже есть правила для Cursor, Windsurf, Claude и прочих LLM IDE.

По сути, просто загружаешь в том же Cursor и говоришь, что нужно сделать, — и оно собирает достаточно сложную мультиагентную систему за 5 минут. В no-code решения я не верю, но low-code типа этого реально работают.

Подпишись 👉🏻 @aigentto 🤖

Инструкции для LLM нельзя положить в RAG

Часто RAG пытаются применить там, где он не нужен, например, когда есть большой набор примеров или методик, по которым мы хотим, чтобы LLM строила ответы. То есть мы хотим дать на вход большую инструкцию и заставить LLM, руководствуясь большим объемом примеров о том, как надо делать, либо большим объемом теории (методики), выдать результат.

Из-за того, что в этом случае мы имеем большой объем примеров или методик, которые определяют руководство к действию для LLM, мы начинаем думать, что по причине того, что это нельзя впихнуть в промт, надо прикрутить RAG и выбирать часть (top-k) примеров и методик, которые наиболее семантически сходны с поданным контекстом (запросом пользователя, например). Это ошибка!

Только лишь потому, что наша инструкция (примеры и методики) объемные, впихивание их в RAG не только ничего не даст, оно поломает нашу логику, потому что инструкция (какой длины бы она ни была) должна быть полностью передана в LLM. А когда мы получаем куски инструкции, по семантике схожие с поданным контекстом, мы получаем полную ерунду.

Важно понять, что RAG — это про выборку фактов из большого количества данных, именно фактов! Выбирать динамически инструкцию для LLM — это не RAG, и это работать не будет! Инструкция, какой бы длины она ни была, подаётся всегда полностью со всеми примерами, контекст выбирается под запрос по семантике.

Поэтому надо искать способ подать это всё как инструкцию, способов много:
1. Подумать, а нужны ли все примеры? И сделать few-shots, то есть несколько разных примеров того, что мы хотим получить.
2. Использовать LLM для уменьшения объема нашей инструкции (LLM очень хорошо умеет ужимать смысл, сохраняя суть).
3. Использовать подачу инструкции частями и отдельно контекст, сообщить LLM о том, что мы будем делать это частями и пока не скажем GO, она не должна давать ответ.

Подпишись 👉🏻 @aigentto 🤖