RAG Architecture: как построить проверяемый поиск по корпоративным данным

Production RAG состоит из контура индексации и контура ответа. Индексация получает документы, извлекает структуру, делит содержимое на фрагменты, добавляет метаданные, вычисляет embeddings и записывает версии в поисковый индекс. Контур ответа преобразует вопрос, находит кандидатов, ранжирует их, собирает контекст и только затем вызывает LLM.

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

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

Каждый chunk получает document_id, version, section, source_url, access labels, timestamps и checksum. Embedding — производная, а не первичный источник: его можно пересчитать при смене модели. Повторная индексация должна быть идемпотентной и удалять фрагменты старой версии, иначе поиск начнёт возвращать противоречивые копии.

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

Reranker повторно оценивает небольшой набор найденных фрагментов относительно конкретного вопроса. Он повышает precision, но добавляет задержку и стоимость, поэтому сначала извлекают умеренный пул кандидатов, затем ранжируют и передают модели только top-N. Порог релевантности нужен, чтобы система могла честно ответить «данных недостаточно».

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

ACL фильтруются до retrieval, а не после генерации. Иначе запрещённый документ уже попадёт в prompt и может повлиять на ответ. Отдельно защищаются инструкции: текст внутри документа считается данными, а не системной командой. Логи не должны сохранять секретный контекст без той же политики доступа и срока хранения.

Набор оценки должен содержать реальные вопросы, ожидаемые источники, допустимые формулировки и случаи без ответа. Retrieval оценивают отдельно через recall@k, precision и позицию правильного фрагмента. Генерацию проверяют на соответствие источнику, полноту, качество цитат и корректный отказ.

В production отслеживают отсутствие результатов, низкую релевантность, переходы по цитатам, feedback пользователей, задержку и стоимость. Каждое изменение chunking, embeddings, reranker или prompt сравнивается на одном регрессионном наборе. Без этого оптимизация RAG строится на нескольких эффектных demo-вопросах.