От бота к агенту Честно, до недавнего времени я был уверен, что «ИИ-агент» — просто бот, которого переименовали, коммерческий ход, не более. Однако разница существенная — агент способен оценивать промежуточный результат и на основе этой оценки менять свой дальнейший ход. Добавил своему юридическому боту (в сфере IP) способность принимать решения на промежуточных этапах. Для этого внёс три изменения в архитектуру: ✔️ Анализ вопроса перед поиском (Intake-агент) Перед поиском отдельная LLM переводит бытовой язык пользователя в юридические термины, извлекает факты из сообщения и решает — начать поиск или задать дополнительный вопрос. Пользователь пишет «украли фотки на озоне», но ведь база не понимает некоторых слов, а некоторые воспринимает совершенно не так как нам нужно, например "озон", для неё это скорее газ, чем маркетплейс. Добавил вызов LLM перед поиском, которая переформулирует запрос на юридический язык («нарушение исключительных авторских прав на фотографическое произведение, маркетплейс Ozon, компенсация ст. 1301 ГК РФ»), извлекает структурированные факты (тип объекта, роль пользователя, наличие переработки) и принимает решение: — данных достаточно, отправляем в работу — данных недостаточно, задаем дополнительный вопрос пользователю ✔️ Порог релевантности (score threshold) Бот научился отсеивать мусорные фрагменты (чанки) до того, как они будут переданы из векторного хранилища в нейросеть. Раньше передавал всё подряд — теперь фильтрует и меняет поведение, если качественного контекста мало. В боте уже был реранкер — модель, которая оценивает, насколько каждый найденный фрагмент подходит к вопросу. Из 30 найденных фрагментов он отбирал 10 лучших и передавал в нейросеть. Если же по теме поиска нашлось всего 5 близких фрагментов, то остальные 5 мест он заполнял потому что «надо» и тем «чем пришлось». В итоге LLM могла получить «хвост» из не релевантных фрагментов и начинала галлюцинировать на их основе. Добавил числовой порог, то есть если скор (оценка) фрагмента ниже определённого значения, то он отсеивается, сколько бы свободных мест ни оставалось. ✔️ Цикл поиска (retrieval loop) Если первый поиск в базе дал мало результатов, бот сам формирует второй запрос, но с другими ключевыми словами и ищет ещё раз. Раньше бот один раз обращался к базе — что нашёл, с тем и работал. Теперь после первого поиска происходит отдельный вызов LLM и она оценивает: хватает ли найденного? Если нет — формирует второй запрос с другими ключевыми словами, ищет ещё раз, а результаты от двух поисков объединяются. Если даже после повторного поиска релевантных фрагментов мало, то бот честно скажет, что практики в базе недостаточно, и предоставит то, что нашёл. Тест изменений (на скриншотах)— один вопрос, два пайплайна: ➡️Старый — линейный rag (скрин 1): одно основание → 45–90 тыс. руб. ➡️Новый — agentic rag (скрин 2): агент определил переработку, применил два основания (ст. 1301 п.1 + п.2) → 66–180 тыс. руб. Стал ли ответ точнее? Однозначно. Но я бы не спешил приписывать этот успех «магии» Agentic RAG. Часть улучшений — это результат донастройки фильтров и промптов. Тем не менее, в архитектуре появилась та самая «агентная сущность» — система перестала следовать одному алгоритму и начала принимать решения на промежуточных этапах. Однако здесь важно понимать, агентность — это не всегда плюс. Чем больше в системе «самостоятельных» узлов, тем выше вероятность того, что агент примет неверное решение на промежуточном шаге и уверенно уведёт ответ в сторону. Автономность требует кратно большего внимания к настройке. Есть кейсы, где Agentic RAG будет чрезмерен или даже вреден, а классического линейного пайплайна хватит с головой, поэтому нужно выбирать инструмент под конкретные цели и задачи. Кстати, кто хочет копнуть глубже — у Екатерины есть классный материал по agentic-RAG, рекомендую.