Проектирование архитектуры RAG-пайплайна

Почему RAG-пайплайн отвечает неточно на сложные вопросы

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

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

Третий сбой — устаревший индекс. Документ обновили, старую редакцию удалили, а поиск по базе знаний продолжает находить её копию: пересчёт векторов либо не запускался, либо захватил не все источники. Ассистент транслирует отменённое правило с той же уверенностью, что и действующее, — и расхождение обнаруживает уже человек, читающий первоисточник.

Все три rag-пайплайн ошибки лежат не в модели, а в подготовке данных, поиске и проверке опоры — разбираем, как это закрывается.

Что даёт управляемая архитектура поиска и генерации

Управляемая архитектура переводит качество ответов в измеримые величины. Каждый ответ либо опирается на подтверждающий фрагмент источника, либо помечается как неуверенный — доля ответов со ссылкой видна в отчёте и растёт итерациями. Метрики верности источнику и релевантности, как в RAGAS, снимаются на наборе контрольных вопросов до выката: регрессия ловится на тестовом прогоне, а не на жалобах пользователей.

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

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

Устойчивость к росту нагрузки даёт разделение слоёв: индексация, поиск и генерация масштабируются независимо, узкое место видно по метрикам и снимается добавлением узлов. При десятикратном росте числа пользователей система деградирует предсказуемо — растёт время ожидания в очереди, а не доля ошибок.

Сравнение вариантов: векторный, гибридный и графовый поиск

Схема поиска определяет, какие фрагменты попадут в контекст генерации, — на этом шаге ломается большинство прототипов на RAG-пайплайне. Векторный поиск по эмбеддингам уверенно ловит смысловую близость, но теряет артикулы, коды и редкие термины; лексический — наоборот. Поэтому на практике сравнивают три сборки.

Что меняется на этапе выдачи

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

Этапы работы: от аудита данных до передачи в поддержку

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

1. Аудит данных. Разбираем источники — регламенты, базу обращений, договоры, базу знаний — и считаем объём, дубли, устаревшие редакции, закрытые разделы. На выходе карта: что индексируем, что исключаем, по какому признаку разграничиваем доступ между отделами.
2. Проектирование схемы поиска. Определяем размер смыслового фрагмента, стратегию поиска, набор фильтров и правила, по которым ответ обязан ссылаться на источник, а не пересказывать его своими словами.
3. Настройка индекса. Собираем конвейер индексации: разбор форматов, разметка метаданными (отдел, дата, версия документа), регулярное обновление по расписанию вместо ручной перезагрузки.
4. Проверка качества ответов. Готовим контрольный набор вопросов, включая те, ответа на которые в базе нет. Смотрим долю ответов с корректной ссылкой, долю честных «в данных нет» и ошибки на устаревших версиях документов.
5. Пилот и донастройка. Запускаем на одной команде: реальные формулировки запросов отличаются от тестовых, после них правим фрагментацию и порог отсечения.
6. Передача в поддержку. Отдаём документацию, регламент переиндексации при обновлении источников, панель метрик качества и порядок разбора обращений «ответ неверный».

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

Техническая документация, схемы и регламенты обновления

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

• Схема архитектуры — состав компонентов RAG-пайплайна, путь данных от источника до ответа и точки отказа: где происходит разбор документа, построение векторов, поиск и обращение к модели.
• Карта источников — перечень систем-поставщиков, владельцы данных, частота изменений, форматы, объём и ограничения по доступу для каждой коллекции.
• Правила доступа — разграничение прав на уровне документа и раздела, чтобы сотрудник получал ответ только по разрешённым ему фрагментам.
• Регламент обновления индекса — триггеры и частота переиндексации, режим инкрементального обновления, порядок действий при смене структуры документа или выводе источника из эксплуатации.
• Мониторинг качества — набор контрольных вопросов, доля ответов с подтверждённой ссылкой на источник, отслеживание попадания нужного фрагмента в контекст и оповещения при просадке метрик.
• Документация решения — порядок развёртывания, состав конфигураций, где смотреть журналы, как откатить версию индекса и как подключить новый источник.
• История изменений — версии настроек поиска и инструкций модели с пометками, какое изменение к какому сдвигу качества привело.

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

Кейс: как убрали ответы без опоры на источники

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

Что изменили

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

Метрики до и после

Доля ответов без опоры на источник — 34% → 4%, среднее время ответа — 9 → 2,5 секунды, обращения в живую поддержку по типовым вопросам — минус 41%. Каждый ответ приходит со ссылкой на конкретный документ, а спорные формулировки уходят на доработку базы, а не в переписку с поддержкой.

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

Чем RAG-пайплайн отличается от дообучения модели

Оба подхода решают одну задачу — заставить модель отвечать по вашим данным, но работают на разных уровнях. RAG-пайплайн не трогает веса: он находит релевантные фрагменты в базе знаний и подставляет их в контекст запроса. Дообучение меняет саму модель — она осваивает форму ответа, терминологию и логику предметной области.

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

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

Выбор сводится к двум вопросам: как часто меняются данные и что именно модель должна воспроизвести — знание или форму. Частые изменения и потребность в цитируемости указывают на поиск по базе, стабильный корпус и нестандартный формат вывода — на дообучение. Рабочий вариант — комбинация: поиск даёт факты, дообучение задаёт стиль.

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

Вопросы, которые задают инженеры заказчика

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

Как делите документы на части, чтобы ответы не теряли смысл?

Нарезка идёт по структуре документа, а не по фиксированной длине: границы разделов, пунктов регламента, строк таблиц. Иерархию заголовков сохраняем в метаданных, чтобы в цитате был виден путь до пункта. Таблицы и схемы обрабатываем отдельной веткой, иначе числа теряют привязку к строке. Перекрытие соседних фрагментов оставляем, чтобы определение не разрывалось пополам.

Как убедиться, что система не выдумывает ответы?

Ответ строится только на найденных фрагментах, каждый — со ссылкой на исходный документ. Ниже порога релевантности система честно отвечает, что данных нет. До ввода в эксплуатацию собираем набор контрольных вопросов с эталонными ответами и прогоняем его на каждой сборке. Смотрим долю ответов с корректной ссылкой и полноту покрытия; спорные случаи разбираем вручную.

Документы меняются каждый день — как обновляется база знаний?

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