Представьте: вы на собеседовании в Perplexity на роль ML-инженера, и интервьюер задаёт вопрос:

«Ваша RAG-система начала "галлюцинировать" в продакшене. Как вы проверите, что сломалось — retriever или generator?»

Многие кандидаты наверное скажут: «проверить точность» или «запустить больше тестов». Возможно, так и получится найти проблему, но можно пойти чуть иначе.

RAG-системы дают сбой на разных этапах, и для каждого нужны свои метрики. Общая «точность» часто не отвечает на самый важный вопрос — "А где же именно кроется ошибка?"

Ключевая идея:
Качество RAG = Производительность Retriever'а × Производительность Generator'а

Метрики Retrieval (Достали ли мы правильный контекст?)
- Contextual Relevancy: Какой процент полученных чанков действительно релевантен?
- Contextual Recall: Достали ли мы всю необходимую информацию?
- Contextual Precision: Ранжируются ли релевантные чанки выше нерелевантных?

Метрики Generation (Правильно ли LLM использовала контекст?)
- Faithfulness: Насколько вывод соответствует предоставленным фактам?
- Answer Relevancy: Отвечает ли ответ на заданный вопрос?
- Кастомные метрики: Следует ли ответ нужному формату или стилю?

Диагностическая структура:
1️⃣ Высокий Faithfulness + Низкий Relevancy → Проблема в Retrieval
2️⃣ Низкий Faithfulness + Высокий Relevancy → Проблема в Generation
3️⃣ Обе метрики низкие → Сломан весь пайплайн
4️⃣ Обе метрики высокие → Ищите edge-кейсы

Метрика, которая ловит большинство продакшен-проблем: Contextual Recall.
Ваш retriever может находить «релевантный» контент, но упускать критически важные детали. Идеальная точность при нулевой полноте = уверенные, но неправильные ответы. Именно поэтому RAG-системы так уверенно «галлюцинируют».

Но интервьюер может продолжить вас спрашивать:

«У вашего RAG'а точность 85%. А какой accuracy у контекста? Каков score достоверности? Вы меряете end-to-end или на уровне компонентов?»

Если ваши метрики расплывчаты, интервьюер скорее всего решит, что вы не понимаете, как работают RAG-системы в продакшене.

Подход к оценке, который отличает джунов от сеньоров:

Джун: Тестирует всё end-to-end и надеется, что сработает.
Сеньор: Внедряет метрики на уровне компонентов, автоматизированную оценку в CI/CD и мониторинг в продакшене.

Суровая реальность продакшена:
➖ Идеальный retrieval + слабые промты = галлюцинации
➖ Идеальная LLM + плохие чанки = нерелевантные ответы
➖ Хороший retrieval + хорошая генерация + отсутствие мониторинга = неминуемый провал

❗Совет:
Упомяните оценку по методу LLM-as-a-judge.

«Я бы использовал GPT-4 для оценки faithfulness, сравнивая сгенерированные ответы с полученным контекстом, а затем отслеживал распределение скоров over time, чтобы поймать дрейф.»

Это покажет, что вы в курсе современных методов оценки.

Вопрос, который завершает интервью:

«Как бы вы реализовали такую оценку в продакшене?»

Возможный ответ:
- Автоматизированные оценки компонентов в CI/CD
- Мониторинг в реальном времени с оповещениями
- Асинхронная батч-оценка продакшен-трафика

Понимание причин сбоев RAG > заучивание архитектур трансформеров.