RAG по большому корпусу документов
Как построить RAG/search систему, если корпус по масштабу похож на большой веб-поиск?
Ответить самому
Сначала сформулируйте ответ как на собеседовании, затем откройте разбор и оцените себя.
Короткий ответ
Нужен каскад: индексация и фильтры, быстрый lexical retrieval и векторный retrieval, дедупликация, реранкинг top-N, контроль свежести и генерация ответа только по компактному контексту.
Полный разбор
На большом корпусе нельзя отправить все документы в LLM или запускать дорогой reranker по всему индексу. Сначала строится ingestion: chunking, metadata, ACL, версии, язык, freshness и несколько индексов. Дешевый retrieval через BM25/filters/vector ANN достает тысячи или сотни кандидатов.
Дальше идут нормализация query, union/RRF/weighted merge источников, дедупликация, business/ACL фильтры и реранкинг top-N. Reranker может быть cross-encoder, LLM scorer или более дешевая ML-модель. Только после этого компактный контекст попадает в LLM.
Критичные production-вещи: latency budget на каждый этап, offline retrieval Recall@K, online success rate, логирование вкладов BM25/vector/reranker, fallback на lexical search и отказ от ответа при недостаточном контексте.
Теория
Большой RAG - это поисковый каскад; LLM находится в конце, а не заменяет весь retrieval.
Типичные ошибки
- Делать только векторный поиск без lexical fallback.
- Пускать дорогой reranker по всему корпусу.
- Не учитывать ACL и свежесть документов.