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

RAG — это два контура, а не один prompt

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

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

Ingestion и chunking

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

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

Hybrid retrieval и reranking

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

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

Generation, citations и безопасность

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

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

Evaluation до и после запуска

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

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

Метаданные chunk перед записью в индекс

{
  "document_id": "policy-2026-14",
  "version": 3,
  "section": "4.2 Возврат средств",
  "source_url": "/docs/policy-2026-14.pdf#page=6",
  "access_labels": ["role:support", "role:sales"],
  "checksum": "sha256:9f2a...",
  "indexed_at": "2026-07-25T09:00:00Z"
}

FAQ