Naive, Graph и Agentic RAG: три уровня картотеки

🗄 Возвращаемся к умной картотеке

В теме про память (6.2 — Короткая и длинная память) мы завели умную картотеку по смыслу (vector DB — хранилище, которое ищет не по точному слову, а по смыслу). Спросил «прозрачный навар из птицы» — а она находит карточку «куриный бульон», хотя ни одно слово не совпало.

Так вот, сам по себе механизм «спросил — нашли похожее — приложили к ответу» называется RAG (поиск нужных фактов в базе перед ответом). Повар-модель не выдумывает факт из головы, а сначала идёт в картотеку, достаёт нужную карточку и готовит ответ уже по ней. Это и есть заземление (grounding) — ответ привязан к реальному документу, а не к фантазии (про то, почему модель вообще фантазирует, — 2.5 — Галлюцинации). И сразу важное: RAG — это не «дообучить модель на наших документах». Сама модель-повар не меняется, мы её ничему не учим — меняется только то, что ей подкладывают в картотеку под рукой. Поэтому «бот отвечает по нашим файлам» не значит «бот выучил наши файлы»: он каждый раз сходил и достал.

Но «сходить в картотеку» можно по-разному. И вот тут вся соль этой темы: есть три уровня, насколько умно агент с этой картотекой обращается. От самого простого и дешёвого — до самого хитрого и дорогого. Разберём по очереди, на одной и той же кухне.

📥 Naive RAG — достал первую попавшуюся карточку

Самый простой уровень. Naive RAG (наивный, простой RAG) — это пассивный конвейер из трёх шагов, без единой остановки на подумать: спросил → достал похожее → ответил. Пришёл вопрос, картотека выдала самые похожие по смыслу карточки, повар приготовил ответ ровно по ним. Точка. Никто по дороге не спросил себя «а то ли я вообще достал?».

Это как поварёнок, которому сказали: «нужен бульон» — он подбежал к картотеке, схватил первую попавшуюся похожую карточку и понёс готовить, не глядя. Чаще всего схватит правильную — на то она и умная картотека. Но если рядом лежит похожая, но не та (карточка про другой бульон, устаревшая версия, соседний пункт регламента) — он и её принесёт с тем же уверенным лицом. Именно так FAQ-бот из начала страницы «нашёл не то и уверенно ответил».

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

🕸 Graph RAG — картотека со связями между карточками

Следующий уровень. Представь, что карточки в картотеке не лежат вразнобой, а связаны между собой ниточками: кто кому поставщик, какое блюдо из какого полуфабриката, что от чего зависит. Это Graph RAG (RAG по графу связей) — картотека, в которой, кроме самих карточек, хранятся ещё и связи между ними.

Зачем это нужно? Затем, что появляются вопросы, на которые одной карточкой не ответишь — надо пройти по связям. «Если поставщик А сорвёт поставку — какие наши блюда из меню встанут?» Простая картотека найдёт карточку про поставщика А и карточку про меню — но не свяжет одно с другим. А картотека со связями пройдёт по ниточкам: поставщик А → эти три полуфабриката → вот эти семь позиций в меню. Ответ собран не из одной карточки, а из цепочки связей.

Звучит здорово — но есть цена. Эти связи кто-то должен сначала проложить, а потом поддерживать. Сменился поставщик, обновилось меню — все ниточки надо перепривязать, иначе граф врёт ещё увереннее простой картотеки. Поэтому Graph RAG — это дорого строить и дорого держать в актуальном состоянии. Он окупается там, где вопросы и правда «через связи»: зависимости, цепочки поставок, кто на кого влияет. Где таких вопросов нет — это просто дорогая картотека, которая делает работу простой.

🧑‍🍳 Agentic RAG — су-шеф у картотеки

Верхний уровень. Тут к картотеке приставлен су-шеф-привратник, который не просто хватает карточку, а работает с ней головой. Это agentic RAG (RAG с агентом-привратником): вместо пассивного конвейера — цикл «поиск → оценка → переспрос».

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

То есть су-шеф закрывает ровно ту дыру, из-за которой простой бот «уверенно отвечает не тем»: между «достал» и «ответил» он вставляет «а проверил ли я, что достал то, что надо». За это и платят — на сложных и важных вопросах.

🔍 Что именно делает су-шеф (по шагам)

Чтобы «agentic RAG» не звучало как магия, разложим цикл су-шефа на человеческом языке. Это всё ещё не настоящий код — просто логика того, что происходит между вопросом и ответом.

Видишь разницу с naive RAG? Там было три шага по прямой. Тут — петля с проверками: оценил, при нехватке переспросил, выкинул протухшее, разрулил конфликт. Именно эти проверки и стоят денег (каждый круг — это лишний прогон модели, дольше и дороже), и именно они спасают на вопросах, где ошибиться нельзя.

🎚 Правило выбора уровня

Не «бери что поумнее». Уровень подбирают под задачу, и логика простая:

• Простой вопрос, одна однозначная карточка, низкая цена ошибки (режим работы, доставка, типовой FAQ) — хватает naive RAG. Дёшево, быстро, надёжно. Ставить сюда что-то сложнее — выкинуть деньги.
• Вопрос «через связи» — как изменение у поставщика А ударит по заказу Б, что от чего зависит — нужен Graph RAG. Но только если таких вопросов реально много: связи дорого строить и поддерживать.
• Сложный, многошаговый, высокоставочный вопрос, где карточки могут спорить или устаревать (юридический, медицинский, дорогой контракт) — тут оправдан agentic RAG с его проверками. Цена ошибки выше, чем цена су-шефа.

Главная мысль: чем выше уровень, тем больше он умеет — но и тем дороже обходится и тем больше в нём того, что может само сломаться. На этом и построен тренажёр ниже.