RAG с нуля: от документа до проверенного ответа
Production-конвейер RAG: ingestion, нормализация, chunking, embeddings, retrieval, reranking, grounded generation, цитаты и evaluation.
Содержание статьи
Что решает RAG
Retrieval-Augmented Generation добавляет к запросу внешние фрагменты знаний. Это позволяет работать с приватными документами, свежими данными и источниками, которых не было при обучении модели.
RAG не обновляет параметры LLM. Знания остаются во внешнем хранилище, поэтому их можно версионировать, удалять, ограничивать правами доступа и цитировать.
Ingestion и нормализация
PDF, HTML, письма и таблицы содержат шум: меню, повторы, колонтитулы, скрытые символы и неправильный порядок чтения. Если ingestion теряет структуру, retrieval уже не сможет восстановить её позже.
Каждый фрагмент должен сохранять document_id, версию, источник, дату, язык, права доступа и позицию в оригинале. Метаданные нужны для фильтрации, цитирования и удаления устаревших записей.
Chunking и представление
Слишком маленькие chunks теряют контекст, слишком большие смешивают темы и занимают ценное контекстное окно. Лучше делить по семантическим границам: заголовкам, абзацам, пунктам политик или функциям кода.
После нормализации chunks преобразуются в embeddings. Векторный поиск находит семантическую близость, но для названий, кодов и точных терминов его стоит сочетать с keyword search и фильтрами метаданных.
Retrieval, reranking и grounding
Первичный retriever быстро возвращает кандидатов, а reranker точнее определяет, какие фрагменты действительно отвечают на запрос. Модели следует передавать компактный набор самых сильных доказательств.
Модель должна отвечать на основе переданных источников и явно сообщать о нехватке доказательств. Цитаты формируются из реальных source_id, а система проверяет, что каждый идентификатор присутствовал в контексте.
Оценивание RAG
Retrieval и generation нужно оценивать отдельно. Если правильный документ не найден, проблема не в модели. Если доказательство найдено, но ответ добавляет неподтверждённые утверждения, проблема в grounding или generation policy.
Evaluation set должен содержать реальные вопросы, ожидаемые источники, правильные ответы и негативные случаи, где система обязана отказаться от ответа. Метрики включают retrieval recall, precision, groundedness и citation accuracy.
Минимальная production-архитектура RAG
Базовый RAG состоит из ingestion, нормализации, chunking, embeddings, индекса, retrieval и генерации ответа. В production добавляются ACL, версионность документов, metadata filters, reranking, журналирование запросов и механизм удаления устаревших фрагментов. Без этих слоёв прототип быстро превращается в неуправляемую коллекцию векторов.
Каждый chunk должен хранить provenance: документ, версию, страницу или секцию, время индексации и права доступа. Тогда ответ можно объяснить, проверить и отозвать после обновления источника. Вектор без происхождения почти непригоден для надёжной системы.
Как оценивать retrieval отдельно от генерации
Если ответ неверен, сначала нужно выяснить, получила ли модель нужные доказательства. Retrieval оценивают по recall, precision, hit rate, MRR или nDCG на наборе запросов с известными релевантными фрагментами. Генерацию проверяют отдельно: использованы ли источники, нет ли противоречий и корректны ли цитаты.
Такое разделение ускоряет диагностику. Если релевантный chunk не найден, изменение prompt не поможет; нужно улучшать chunking, embeddings, query rewriting или reranking. Если доказательства есть, но игнорируются, проблема уже в сборке контекста, инструкциях или модели.
Типичные причины провала RAG
Частые проблемы — слишком большие или слишком маленькие chunks, отсутствие metadata filters, дубликаты, смешивание версий, слабые пользовательские запросы и слишком много возвращённых фрагментов. Больше контекста не гарантирует лучший ответ: нерелевантные отрывки снижают сигнал и создают противоречия.
Начните с небольшого eval dataset, измеряйте retrieval до подключения LLM и логируйте каждый этап. После запуска собирайте неудачные запросы, классифицируйте причины и обновляйте индекс или pipeline на основе фактов, а не впечатлений от нескольких демо.
End-to-end приёмка первого RAG
Первый RAG следует рассматривать как измеримый pipeline: ingestion, parsing, chunking, embedding, indexing, retrieval, reranking, generation и validation цитат. Для каждого этапа нужны собственные identifiers и traces, чтобы понимать, где именно потерялся правильный документ. Evaluation dataset должен содержать реальные запросы, ожидаемые sources и критерии completeness. При недостатке evidence ответ должен отказаться или запросить уточнение, а не компенсировать слабый retrieval уверенной генерацией.
Production baseline включает access filters на этапе retrieval, versioned index, idempotent reindex и rollback. Метрики должны охватывать recall@k, citation precision, groundedness, p95 latency и cost per successful answer. После любого изменения embeddings, chunking или prompt один и тот же regression set запускают повторно.
- Не смешивайте retrieval errors и answer errors.
- Сохраняйте source IDs в final response.
- Используйте контролируемый reindex.
Практические примеры
Evidence package
Retriever возвращает source_id, document_version, fragment, score и access policy. Ответ может ссылаться только на фрагменты из этого пакета.
FAQ
Нужна ли vector database для любого RAG?
Нет. Для небольшого корпуса достаточно PostgreSQL, поискового движка или даже контролируемого keyword search.
Почему RAG придумывает цитаты?
Так происходит, когда модель генерирует ссылки как свободный текст. Идентификаторы источников нужно передавать структурированно и проверять после генерации.
Когда обновлять индекс?
При событиях изменения источников или по определённому SLA. Каждая версия документа должна оставаться прослеживаемой.