Как устроена архитектура RAG
Что проверяют
Понимаете ли вы RAG как инженерную систему, а не как «подложили документы в промпт». Следом обычно спрашивают, как вы измеряли качество поиска и что делать, когда модель отвечает мимо найденного контекста.
Как отвечать
Разделите систему на две фазы: индексацию и обработку запроса.
- загрузка и чанкинг: документы режутся на фрагменты по несколько сотен токенов с перекрытием, лучше по структуре (заголовки, абзацы), а не по фиксированной длине;
- эмбеддинги: каждый чанк переводится в вектор моделью-энкодером, вектор и метаданные (источник, дата, права доступа) кладутся в векторное хранилище:
pgvector, Qdrant, FAISS, Milvus; - поиск: запрос кодируется той же моделью, ближайшие соседи ищутся через ANN-индекс (HNSW, IVF). Сильный ход: гибридный поиск, BM25 плюс векторы со слиянием через RRF;
- реранкинг: кросс-энкодер переоценивает топ-50 и оставляет 5-10 лучших;
- генерация: LLM получает вопрос и найденные фрагменты с инструкцией отвечать только по ним и ссылаться на источник.
Отдельно скажите про оценку. Поиск меряют recall@k и MRR на размеченном наборе вопросов, генерацию проверяют на faithfulness (ответ опирается на контекст) и релевантность, часто через LLM-судью. Инструменты вроде Ragas это автоматизируют.
И назовите, ради чего всё это: знания обновляются переиндексацией без дообучения модели, а ответ можно проверить по ссылке на источник.
Где спотыкаются
Называют генератором BERT. Это энкодер, текст он не генерирует. В RAG BERT-подобные модели работают как раз на стороне поиска: считают эмбеддинги и реранкают.
Считают, что RAG убирает галлюцинации. Он их снижает, но если поиск принёс не тот фрагмент, модель уверенно ответит по нему или вовсе проигнорирует контекст. Поэтому поиск и генерацию оценивают раздельно.
Не думают о чанкинге и метаданных. Слишком мелкие куски теряют смысл, слишком крупные размывают эмбеддинг, а без фильтра по правам доступа пользователь получит ответ из документа, который ему видеть нельзя.