Внутренний ассистент получает вопрос: «Какая у нас политика возвратов для корпоративных клиентов?» Через пару секунд выдаёт ответ и ссылку на сам документ. Выглядит так, будто модель знала. Она не знала. Её обучали задолго до того, как этот документ появился, и доступа к вашим файлам у неё нет.
Всё, что происходит между вопросом и ответом, называется RAG — Retrieval-Augmented Generation. Идея проще, чем аббревиатура: сначала найти нужный кусок текста, потом попросить модель ответить по нему. А восемь шагов ниже — это то, как такую идею обычно собирают руками.
Метафора, которая держит всю схему
Руководитель ставит задачу. Секретарь идёт в архив, достаёт папки, отсеивает лишнее и приносит готовый ответ со ссылкой на источник. Все восемь шагов — про это. Если держать в голове секретаря, дальше читается без словаря.
Восемь шагов: от вопроса до ответа со ссылкой
- Приём вопроса. Система берёт текст, который ввёл пользователь.
- Эмбеддинг и осмысление. Вопрос чистят: расплывчатые формулировки переписывают, добавляют синонимы, сложный вопрос разбивают на несколько простых. Затем превращают в вектор — строку чисел, чтобы компьютер мог сравнить смысл вопроса с содержимым базы.
- Поиск. По вектору ищут самые близкие по смыслу фрагменты. В рабочей системе это воронка от широкого к узкому: параллельно работают два канала — поиск по смыслу и поиск по буквальному совпадению слов. Потом отсекают то, что показывать нельзя: нет доступа, версия устарела. Остатки пересортировывает более внимательная модель — это называют реранкингом.
- Сборка промпта. Найденное, исходный вопрос и инструкции по поведению системы складывают в один текст. Слово Augmented в названии ровно про этот момент: найденным материалом дополняют ваш вопрос.
- Генерация. Модель читает папку и выдаёт ответ слово за словом.
- Ограждения. Проверка на утечку закрытых данных, сломанное форматирование, явную выдумку. По-английски — guardrails. В системах посложнее модель сверяет свой ответ с найденными документами и переписывает при расхождении; этот самоанализ называют reflection.
- Ответ со ссылками. Вместе с текстом приходит указание, на каком документе и каком фрагменте он основан.
- Логирование. Обмен сохраняют, обычно в двух видах. Лог — постоянная запись для отладки, аудита и статистики. История диалога — контекст для следующего вопроса. Задачи разные, лежат часто в разных местах.
То, что произошло задолго до вашего вопроса
Откуда вообще взялись векторы в базе, по которой ищет шаг третий? Это отдельный конвейер, работающий постоянно и вне восьми шагов, — офлайн-индексация. «Офлайн» здесь значит: не в момент ответа, а заранее.
Цепочка такая: документ → парсинг (PDF и Word читают в простой текст) → чанкинг (длинный документ режут на куски, скажем, по несколько сотен символов: модель не может прочитать всё сразу, а по длинным кускам точный поиск хуже) → эмбеддинг каждого куска → запись в векторную базу.
Это архивная рутина: папки разложили по темам заранее, чтобы потом доставать по требованию. Без неё каждый вопрос пришлось бы начинать с перерывания всей документации компании — unbearably долго и дорого. И это не работа «сделал и забыл»: новые документы, правки, смена стратегии поиска запускают обновление или перестройку индекса.
Прямая это линия? Четыре петли
На одном гладком обмене репликами восемь шагов действительно идут по прямой, и порядок не переставить. Но у реальной системы есть ответвления, которые включаются при определённых условиях.
Петля A · Искать заново. Ещё до генерации выясняется, что найденного материала для ответа не хватает. Тогда вопрос переформулируют и возвращаются к шагам 2–3 за новым раундом поиска — иногда несколько раз подряд. Ключевое: число раундов не зашито в код заранее, модель решает на месте. Это и есть агентный режим работы.
Петля B · Отказ на проверке. Если не прошёл шаг 6, система откатывается к генерации или к поиску по заранее прописанным правилам. Здесь, в отличие от петли A, всё решено до запуска: при каких условиях возвращаться, куда именно и сколько попыток максимум.
Петля C · Многоходовый диалог. Своей памяти у модели нет: раунд закончился — она ничего не помнит. То, что вы можете уточнить «а для второго тарифа?», обеспечивает шаг 8: вопрос и ответ попадают в историю диалога (именно в историю, а не в лог). При следующем вопросе шаг 4 подкладывает эту историю в общую папку вместе с новым вопросом и свежим материалом, и модель перечитывает всё заново. Коротко: вывод прошлого раунда становится частью входа следующего.
Петля D · Логи возвращаются в работу. Накопленные записи периодически уходят в систему оценки: какие вопросы отвечаются плохо и что виновато — поиск или генерация. По результатам инженеры правят чанкинг и стратегию поиска, после чего перестраивают офлайн-индекс. Цикл идёт днями и неделями, и решения тут принимают люди, а не система.
Три поколения RAG — и главный вопрос: кто решает
Деление на три поколения взялось из обзора 2023 года; третье там называлось Modular RAG, но прижилось другое слово — Agentic RAG, оно точнее описывает сдвиг.
| Поколение | Что меняется | Петли и кто ими управляет |
|---|---|---|
| Naive RAG | Восемь шагов идут напрямую, каждый в самой простой версии | Петли прописаны в коде инженерами |
| Advanced RAG | Скелет тот же, но шаги отточены: переформулировка и разложение вопроса на шаге 2, воронка «широко → узко» на шаге 3, reflection и повторные попытки на шаге 6 | Правила в коде и решения людей; история диалога пришивается фиксированно |
| Agentic RAG | Модель сама решает, искать ли ещё, как переформулировать и стоит ли доверять своему ответу | Право на решение у модели, на лету |
Компоненты во всех трёх поколениях одни и те же. Меняется ответ на вопрос, кто отдаёт команды. Как только решение о повторе поиска или о качестве ответа передают модели, петля становится агентной — и поколение вместе с ней.
Что с этим делать на практике
Если вы заказчик, а не разработчик, проверять систему удобно вопросами.
- Спросите про документ, которого заведомо не было в момент обучения модели. Система без RAG начнёт сочинять, система с RAG — искать.
- Спросите про документ, к которому у вас нет доступа. Он не должен всплыть ни в ответе, ни в цитате.
- Возьмите любую ссылку из ответа, откройте первоисточник и сверьте формулировку. Цитаты существуют ровно для этого.
- Уточните: «а если договор продлевается автоматически?» Так проверяется петля C — пришивается ли история диалога.
- Попросите устаревшую версию регламента. Если она всё ещё в индексе, значит, перестройку индекса никто не настроил.
Типичные ошибки при сборке встречаются одни и те же. Резать документы фиксированными кусками, не глядя на структуру — заголовок отдельно, таблица отдельно, смысл потерян. Искать только по смыслу, без канала буквальных совпадений — точные номера, артикулы и аббревиатуры находятся плохо. Отдавать ответ без ссылок — проверить нечего, доверие держится на вере. Не вести логи — тогда петля D не работает, и качество никуда не движется.
Подход хорошо ложится на корпоративные базы знаний, регламенты, поддержку и всё, что меняется и требует проверяемого источника. Он плохо подходит там, где ответ надо собирать рассуждением по всей базе сразу или где документов нет вовсе.
Сама схема выглядит громоздко только на бумаге. В основе — знакомая офисная логика: найти нужное, отдать тому, кто напишет, проверить и сохранить след. Всё остальное — надстройки над этим.
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.