Лев Рябов, фронтенд-разработчик в М2 Tech, собрал продакшн-систему RAG поверх 62 книг по античной истории — это примерно 46 000 чанков — и проверил каждое проектное решение на фиксированном тестовом наборе. Результаты он описал в статье на Habr, где предупреждает: типичный базовый RAG из туториалов работает в демо, но в проде начинает врать.
RAG (Retrieval-Augmented Generation) — это подход, при котором языковая модель отвечает не по своим внутренним знаниям, а по результатам поиска по внешнему корпусу документов. Схема проста: документы разбиваются на фрагменты (чанки), для каждого считается эмбеддинг — вектор чисел, отражающий смысл текста. Когда приходит запрос, система вычисляет эмбеддинг вопроса и находит ближайшие векторы в корпусе. Затем эти фрагменты передаются LLM с инструкцией отвечать только по ним. Для типичного backend-разработчика новый компонент — только эмбеддинги; остальное — привычная инженерная работа.
Рябов замерил наивный бейзлайн: фиксированные чанки по 500 токенов, стандартный эмбеддер, топ-5 результатов. На тестовом наборе из 135 вопросов recall@5 составил 35,2% — то есть примерно для двух вопросов из трёх нужный фрагмент вообще не доходил до модели. При этом модель всё равно отвечала — гладко и уверенно, тем же тоном, что и при успешном извлечении. Это ключевая ловушка: сбой RAG выглядит не как «ничего не найдено», а как правдоподобная выдумка, которую невозможно отличить от правильного ответа, если заранее не знаешь эталон.
Автор подчёркивает: система, которая права в 65% случаев и молча выдумывает в остальных 35%, хуже, чем бесполезна — вы не можете понять, какой ответ перед вами. Ничто в демо не выдаст проблему, единственный способ — измерять. Поэтому главный совет: прежде чем улучшать что-либо, соберите тестовый набор. Нужно написать 30–50 реальных вопросов по корпусу, для каждого зафиксировать, где находится ответ, и добавить 5–10 вопросов-ловушек, на которые корпус не отвечает. Правильное поведение на ловушках — отказ, всё остальное — галлюцинация.
Измерять нужно две вещи отдельно: извлечение (retrieval) — попадает ли нужный фрагмент в топ-k, и генерацию (generation) — обоснован ли ответ, если нужные фрагменты переданы. Для retrieval не нужна оценка LLM, это чистая метрика, которую оптимизируют в первую очередь. Автор отмечает, что для построения RAG не нужно быть ML-инженером — достаточно уметь писать REST API и работать с PostgreSQL, но без тестового набора вы будете улучшать то, что не работает.
Статья Рябова — редкий пример практического разбора RAG без маркетинга фреймворков. Она будет полезна разработчикам, которые впервые сталкиваются с RAG и хотят понять, почему демо-проекты не переносятся в прод. Основной вывод: качество RAG определяется не выбором библиотеки, а систематическим измерением и итеративной настройкой.
