Многоуровневая RAG-система под ключ для вашего бизнеса

Коротко. RAG это способ заставить языковую модель отвечать по вашим документам, а не по общим знаниям: вопрос переводится в вектор, из вашего хранилища достаются подходящие фрагменты, и только они уходят в модель вместе с вопросом. Это заметно снижает долю выдуманных ответов, но не устраняет её, и любой, кто обещает обратное, продаёт не то, что построит. Работает такая система ровно настолько, насколько пригодны ваши документы, и основная работа в проекте приходится на них, а не на выбор модели.

Рядом есть другие страницы: какие задачи автоматизируются в первую очередь, сколько стоит внедрение и как устроена архитектура AI-системы в целом.

Чем это отличается от поиска, который у вас уже есть

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

Почему «никаких галлюцинаций» это неправда

Эта формулировка встречается почти во всех предложениях RAG-систем, включая прежнюю версию этой страницы. Она неверна, и вот механика. Модель получает вопрос и несколько фрагментов текста. Выдумать ответ она может как минимум тремя способами: подходящего фрагмента в выдаче не оказалось, но модель всё равно отвечает; фрагмент нашёлся, но он устарел, и модель не знает об этом; фрагментов несколько, они противоречат друг другу, и модель сшивает их в одно гладкое утверждение.

Ни один из трёх случаев не лечится выбором модели. Лечится архитектурой:

• Порог отсечения. Если лучший найденный фрагмент недостаточно близок к вопросу, правильный ответ системы это «в документах такого нет», а не попытка. Сколько именно таких отказов приемлемо, решается вместе с заказчиком, потому что это выбор между молчанием и риском.
• Обязательная ссылка. Ответ без указания фрагмента, на котором он построен, не показывается. Это дорого стоит в редких случаях и спасает в частых.
• Свежесть индекса. Документ изменился, а вектор остался прежним, и система уверенно цитирует прошлую редакцию. Значит нужен механизм обновления, привязанный к изменению источника, а не ночной пересбор всего.
• Разрешение противоречий. Если найденные фрагменты расходятся, ответ должен это сказать и показать оба, а не выбрать один молча.
• Права по роли. Один вопрос от юриста и от менеджера должен доставать разные документы, иначе система либо утечёт лишнее, либо будет бесполезна.

Что даёт многоуровневая схема вместо простой

Простая схема это «нашли похожее, отдали модели». Её достаточно для FAQ и регламентов. Дальше начинаются вопросы, на которые одним поиском не ответить, и тогда нужны уровни.

Составной запрос

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

Смешанный поиск

Смысловой поиск плох на точных совпадениях: номер договора, артикул, фамилия. Полнотекстовый плох на переформулировках. Рабочая система использует оба и объединяет результаты, а не выбирает один способ навсегда.

Структурированные данные рядом с документами

Часть ответа почти всегда лежит не в документах, а в базе: текущий статус, остаток, срок. Если система умеет только читать документы, она будет цитировать описание процесса вместо того, чтобы назвать текущее значение.

Самопроверка

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

Архитектура по ролям, без привязки к поставщику

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

• Приёмник документов. Забирает источники, приводит к тексту, разбивает на фрагменты с перекрытием, следит за изменениями.
• Модель представлений. Превращает фрагмент и вопрос в векторы. Менять её означает пересобрать индекс целиком, поэтому решение долгосрочное.
• Векторное хранилище. Ищет близкие фрагменты. Изоляция между клиентами или отделами задаётся здесь.
• Слой поиска. Смешивает смысловой и полнотекстовый результат, применяет права доступа и порог отсечения.
• Модель генерации. Формулирует ответ строго по переданным фрагментам.
• Журнал и измерение. Пишет вопрос, выданные фрагменты, ответ и оценку. Без этого слоя качество системы обсуждается впечатлениями.

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

Что требуется от вас

1. Документы в одном месте или хотя бы перечень того, где они лежат, с указанием, какие из них действующие.
2. Готовность признать часть архива устаревшей. Это самая неприятная часть: система будет цитировать всё, что ей дали, и старый регламент выглядит так же убедительно, как новый.
3. Права доступа, сформулированные ролями, а не списком людей, иначе они рассыплются через месяц.
4. Человек, отвечающий за содержание, к которому идут с вопросом «почему система ответила так».
5. Оценка объёма запросов, потому что в отличие от обычного поиска каждый ответ стоит денег.

Чем измерять, что система работает

Проценты из чужих предложений тут бесполезны: они получены на другом корпусе документов. Снимать надо своё, и до запуска.

• Доля вопросов с полезным ответом на наборе реальных вопросов, собранных заранее у тех, кто будет пользоваться.
• Доля уверенных ошибок, то есть ответов, которые выглядели верными и не были. Это главный показатель, и считать его можно только вручную, выборкой.
• Доля отказов «в документах такого нет». Ноль означает, что порога отсечения нет.
• Проверяемость: у какой доли ответов ссылка ведёт туда, где действительно есть утверждение из ответа.
• Стоимость ответа и её изменение при росте числа запросов.

Признаки, что RAG вам не нужен

• Вопросов немного и они однотипны: дешевле написать нормальный FAQ и обычный поиск.
• Ответ всегда лежит в базе, а не в тексте: нужен отчёт или запрос, а не языковая модель.
• Документы противоречат друг другу, и никто не готов решить, какой из них действующий.
• Цена уверенной ошибки высока, а проверять ответы человеком вы не планируете.
• Документы нельзя передавать наружу, а собственный контур не рассматривается.

Как я в этом участвую

Практика ведётся с 2004 года, работа с AI-системами с 2023 года. Моя часть здесь начинается с ваших документов: что в них есть, чему из этого можно доверять и что придётся объявить устаревшим. Дальше я проектирую систему по ролям выше, закладываю порог отсечения и журнал, и передаю её так, чтобы смена модели не означала переделку продукта. Отдельный формат, если у вас уже есть разработчики: архитектурный разбор того, что построено, с перечнем конкретных мест, где система может уверенно ошибаться.

Чего я не обещаю: отсутствия выдуманных ответов, конкретной доли снижения нагрузки на поддержку и срока окупаемости до того, как увижу ваши документы и объём запросов.