Оценка RAG
Тема дорожной карты · Большие языковые модели (LLM)
Оценка RAG разделяет систему на две части: извлечение (нашли ли нужные фрагменты?) и генерацию (использовала ли модель их корректно?). Метрики извлечения — recall@k, MRR, NDCG на размеченном наборе запросов. Метрики генерации — faithfulness (отсутствие выдуманных фактов), релевантность ответа и context precision; их обычно ставит LLM-as-judge, калиброванный по человеческим оценкам. Соберите эталонный набор на 200–500 запросов, заморозьте его и отслеживайте регрессии при изменениях в чанкинге, эмбеддере, top-k или промпте. Не оценивайте только "на глаз".
Как это работает
Оценка RAG (Retrieval-Augmented Generation) дополняет LLM-output релевантным контекстом из вашей knowledge base. Pipeline: embed документов → vector DB → на запросе embed query → retrieve top-k похожих chunks → включить как контекст в LLM-промпт → сгенерировать ответ. Embedding-модели: text-embedding-3-large (OpenAI), bge-large, e5-mistral, voyage-3. Vector DB: Postgres + pgvector, Qdrant, Weaviate, Chroma, Pinecone. Re-rankers (Cohere, BGE) улучшают качество top-k.
Когда применять
RAG — когда LLM нужно отвечать по знаниям, которые (а) превышают context window, (б) после knowledge cutoff модели, (в) проприетарны. Начните с Postgres + pgvector — дешевле, проще, масштабируется дальше ожидаемого. Re-ranker — когда качество retrieval плато. Тюньте chunk-size (256-1024 токена) + overlap (10-20%). Меряйте retrieval recall + качество ответа раздельно.
Типичные ошибки
Ловушки Оценка RAG: chunk слишком маленький (теряет контекст) или большой (нерелевантный контекст доминирует); нет метаданных (источник, timestamp, секция) для фильтрации + цитирования; расчёт, что embedding-модели взаимозаменяемы (нет — качество сильно варьируется); пропуск re-ranking + удивление, что ответы плохие на close-but-wrong retrieval.