Agentic RAG — агент сам решает что и когда искать
Классический RAG — конвейер без мозгов: запрос, поиск, ответ. Agentic RAG — это когда агент сам решает, нужен ли поиск, что искать и достаточно ли найденного. Разбираем, как превратить линейный пайплайн в цикл с принятием решений — на LangGraph и ChromaDB.
СреднийRAG и данные30 минLangGraph, Python, ChromaDB
1
Простой вопрос — конвейер. Сложный — нужен детектив
«Какова политика возврата?» — один поиск, один ответ, RAG справляется. «Сравни подходы двух команд и реши, какой лучше для нашего случая» — и конвейер ломается. Не потому что модель слабая или база плохая. Потому что архитектура не умеет думать: «А достаточно ли я нашёл? Правильно ли понял вопрос?»
Agentic RAG добавляет именно эти контрольные точки. Результат — агент, который ищет итеративно, а не вслепую.
❌ Классический RAG
- Запрос → поиск → ответ (всегда)
- Нет оценки качества результатов
- Один поиск на весь ответ
✅ Agentic RAG
- Сначала план, потом поиск
- Оценивает найденное перед ответом
- Может переформулировать и искать снова
80% проблем с качеством RAG — это не проблемы модели. Это проблемы архитектуры: плохая нарезка документов, однократный поиск там, где нужен итеративный.
2
План → поиск → оценка → решение. Вот и весь секрет
Весь Agentic RAG сводится к одному циклу с четырьмя шагами. На каждом шагу агент принимает решение: искать дальше, переформулировать запрос или ответить. LangGraph реализует это буквально — узлы графа и условные переходы между ними.
Планировать
Искать
Оценить
достаточно
Ответить
мало / нерелевантно
Переформулировать
цикл агента:
1. план → разбить вопрос на подзапросы
2. поиск → найти документы по каждому подзапросу
3. оценка → документы релевантны? (порог > 0.7)
4. решение:
достаточно → ответить
мало / нерелевантно → переформулировать → п.2
3 итерации без результата → "нет данных"Добавьте жёсткий лимит итераций (например, 3). Без него агент может бесконечно искать «идеальный ответ» — особенно если база не покрывает тему.
3
Нарезка документов решает всё ещё до агента
Можно построить идеального агента — и он всё равно провалится, если документы нарезаны неправильно. Нужная информация есть в базе, но разбита так, что поиск её не находит. Это самая частая и самая игнорируемая причина плохого RAG.
Универсальной стратегии нет. Фиксированный размер ломает смысловые единицы. Семантическая нарезка точнее, но дороже. Иерархический подход (parent-child) хорош для длинных документов, но сложнее в реализации. Выбор зависит от ваших документов и запросов — и это решение стоит принять до написания кода агента.
| Стратегия | Лучше для | Слабая сторона |
|---|---|---|
| Фиксированный размер | Однородный текст (логи, статьи) | Разрывает смысловые единицы |
| По абзацам | Структурированные документы | Теряет контекст между секциями |
| Иерархический (parent-child) | Длинные документы, разделы | Сложнее в реализации |
| Семантический | Разнородный контент | Медленнее и дороже |
Стратегия «small-to-big»: индексируйте маленькие чанки для точного поиска, но возвращайте агенту родительский блок целиком. Точность поиска + достаточный контекст.
4
Агент, который не умеет сказать «не знаю» — опасен
Самый опасный режим RAG — уверенный ответ на основе нерелевантных документов. Классический пайплайн всегда что-то возвращает, даже если это совсем не о том.
Решение — явный шаг оценки перед ответом. Отдельный LLM-вызов: «Этот документ отвечает на вопрос? Да / нет / частично». По агрегату агент решает: отвечать, искать дальше или честно сказать «нет данных». Два сигнала нужно различать: «нашли нерелевантное» (переформулировать запрос) и «нашли мало» (расширить поиск). Разные проблемы — разные действия.
для каждого найденного документа:
вопрос: "Этот документ отвечает на вопрос?"
ответ: да | частично | нет
нет → отбросить
да/частично → оставить
если осталось ≥ 2 релевантных → достаточно для ответа
если 0 → переформулировать запрос и искать зановоНе смешивайте оценку релевантности и саморефлексию в один промпт. Релевантность — «про то ли это?» Полнота — «хватает ли для ответа?» Две задачи — два вызова.
5
Хватает для полного ответа — или только частично?
Оценка релевантности и оценка полноты — разные вещи. Три документа могут быть релевантны, но если ключевой факт отсутствует — ответ будет неполным. Саморефлексия — финальная проверка перед генерацией: агент оценивает не отдельные куски, а картину целиком.
Если после 2-3 итераций агент не собрал достаточно — лучше ответить частично или честно сказать «нет данных», чем галлюцинировать.
Контекста достаточно, если...
≥2 релевантных документа по теме
Документы охватывают все части вопроса
Нет противоречий между источниками
Один документ, но прямо отвечает на вопрос
После 3 итераций ничего полезного — выход «не знаю»
6
Если нельзя объяснить ответ по логам — наблюдаемости нет
Агент-чёрный-ящик — это не фича, а технический долг. Плохой ответ? Нужно понять: проблема в поиске, в оценке или в финальном промпте? Без трейсов это гадание на кофейной гуще.
LangGraph помогает: каждый узел графа — точка логирования. Сохраняйте на каждом шагу: исходный вопрос, подзапросы, найденные документы с оценками, решение агента и его причину. В итоговый ответ добавьте метаданные — сколько итераций, сколько документов отброшено. Через неделю реальных запросов эти данные покажут, где система ломается чаще всего.
на каждом шаге сохраняй:
номер_итерации, решение, причина,
найдено_документов, из_них_релевантных
в итоговый ответ добавь:
сколько итераций, какие подзапросы,
сколько отброшено — "рентген" для отладкиСохраняйте трейсы в базу, не только в логи. Через неделю вы увидите паттерны: какие вопросы требуют больше итераций, где агент чаще ошибается. Это данные для улучшения промптов и нарезки.
Результат
Agentic RAG-агент на LangGraph с циклом план → поиск → оценка → решение. Умеет переформулировать запросы, оценивать релевантность и полноту, честно говорить «не знаю» и объяснять каждое решение через трейсы.