Вопросы для собеседования по AI, часть 11: Как оптимизировать RAG?

Оптимизация RAG — это не настройка одного компонента, а оптимизация всего конвейера. Ниже я привожу систематические стратегии оптимизации с четырех сторон: индексации данных, поиска, генерации и оценки, а также практический опыт, который можно упомянуть на собеседовании.

1. Оптимизация стороны индексации данных (улучшение качества «базы знаний»)

Это место, которое чаще всего упускают из виду, но оно дает самый быстрый эффект.

Точка оптимизации	Проблема	Решение	Показатель
Разбор документов	Таблицы и блок-схемы в PDF игнорируются, или текст искажается, порядок нарушается.	Используйте более качественные библиотеки для разбора (например, `unstructured`, режим сохранения макета `pypdf`); для таблиц извлекайте с помощью `pandas` и преобразуйте в Markdown.	Полнота +5–15%
Размер чанка	Слишком маленький чанк теряет контекст (например, теряется ссылка «он» в «его выручка в этом году выросла»); слишком большой чанк приводит к шуму при поиске.	Экспериментируйте с разными размерами чанков (256/512/768 токенов), перекрытие 10–20%; для длинных документов используйте семантические границы (абзацы/заголовки) вместо фиксированной длины.	Точность попадания / Достоверность
Добавление метаданных	Найден релевантный абзац, но невозможно отследить источник или время, или требуется фильтрация по области.	Добавьте метаданные к каждому чанку: `source` (имя файла/URL), `timestamp`, `page_num`, `doc_type`. При поиске используйте фильтры (например, `doc_type == 'legal'`).	Точность фильтрации
Выбор модели эмбеддинга	Универсальный embedding плохо работает в предметных областях (медицина, код, право).	Используйте тонконастроенные модели для предметной области (BGE‑large‑zh, GTE‑Qwen2‑7B‑instruct); или донастройте свою модель эмбеддинга (с triplet loss).	MRR@10 при поиске +10–20%

2. Оптимизация стороны поиска (повышение точности «перелистывания книг»)

Поиск определяет качество «справочных материалов», подаваемых LLM.

Точка оптимизации	Проблема	Решение	Эффект
Гибридный поиск	Векторный поиск не может сопоставить точные термины (например, модель продукта `ABC-123`), а поиск по ключевым словам не понимает синонимы.	Используйте одновременно векторный поиск (семантический) и BM25 (ключевые слова), объединяя через взвешивание (например, 0.7вектор + 0.3BM25) или rerank.	Полнота +10–25%
Ранжирование (Rerank)	Первые результаты векторного поиска не всегда самые релевантные; лучший может быть на 10-м месте.	Используйте модель cross‑encoder (например, BGE‑reranker-v2, Cohere Rerank) для повторного ранжирования кандидатов (например, топ-20) и выбора топ‑K.	Значительное повышение точности попадания (особенно топ‑1)
Переписывание запроса	Вопрос пользователя расплывчат или содержит неоднозначные ссылки в многопользовательском диалоге («А его цена?»).	Используйте LLM для переписывания исходного вопроса в форму, более подходящую для поиска (например, «Сколько стоит iPhone 15?»); или дополняйте с помощью истории диалога.	Полнота +5–15%
HyDE	Вопрос пользователя слишком короткий или абстрактный (например, «Расскажите о фотосинтезе»), прямой поиск неэффективен.	Сначала заставьте LLM сгенерировать гипотетический ответ, а затем используйте этот ответ для поиска документов.	Подходит для открытых областей, но не для точных фактологических вопросов
Настройка Top‑K	Слишком маленький K может пропустить ключевую информацию; слишком большой — увеличивает расход токенов и шум.	Экспериментируйте с K=3/5/10, наблюдайте баланс между полнотой и достоверностью ответа.	Компромисс эффективности и качества

3. Оптимизация стороны генерации (заставьте LLM хорошо использовать справочные материалы)

Даже при отличном поиске, плохой промпт или слабая модель бесполезны.

Точка оптимизации	Проблема	Решение	Эффект
Инженерия промптов	LLM игнорирует найденный контент или выдумывает.	Четкая инструкция: «Отвечай только на основе предоставленных справочных материалов. Если материалов недостаточно или они нерелевантны, ответь: „Недостаточно информации“». Добавьте few‑shot examples, показывающие, как цитировать источники.	Достоверность +20–40%
Сжатие контекста	Найденный контент слишком длинный (превышает окно контекста модели) или содержит много шума.	Используйте `LLMLingua` или `селективный контекст` для сжатия, оставляя наиболее релевантные предложения перед подачей в LLM.	Снижение риска потери информации
Обновление модели LLM	Маленькая модель (7B) не справляется со сложными рассуждениями или не запоминает длинный контекст.	Замените на более сильную модель (GPT‑4o, Claude 3.5 Sonnet, Qwen2.5‑72B).	Значительное повышение точности рассуждений
Потоковый вывод и цитирование	Пользователь не может проверить достоверность ответа.	Заставьте LLM выводить `[citation:1]` с номером найденного документа. На бэкенде приложите ссылку на исходник.	Доверие пользователя + возможность отладки
Калибровка отказа от ответа	Модель выдумывает, когда не следует, или говорит «не знаю», когда следует ответить.	Установите порог схожести: если косинусная схожесть топ‑1 чанка с вопросом ниже 0.7, укажите LLM «Материалы нерелевантны».	Снижение уровня галлюцинаций

4. Оценка и итерации (знать, куда настраивать)

Без измерений невозможно оптимизировать.

Точка оптимизации	Действие	Метрика
Создание оценочного набора	Подготовьте 100–300 реальных пользовательских вопросов + эталонные ответы + правильные ID документов для поиска.	Покрытие различных уровней сложности и интентов.
Автоматизированная оценка	Используйте RAGAS (Faithfulness, Answer Relevance, Context Recall) или TruLens.	Три основные метрики: достоверность, релевантность ответа, полнота контекста.
Ручная оценка	Еженедельно выборочно проверяйте 20 bad case, анализируйте типы ошибок (ошибка поиска / ошибка генерации / отсутствие в базе знаний).	Приоритизация улучшений.
A/B тестирование	В продакшене проводите сплит-тесты разных стратегий поиска (например, BM25 против гибридного).	Онлайн-метрики: удовлетворенность пользователей, процент ответов «нет информации».

5. Практический опыт, который можно упомянуть на собеседовании (бонусные баллы)

«В моем проекте RAG начальная точность попадания была всего 67%. Я сделал три вещи:
1. Изменил фиксированное разбиение на чанки (1024) на динамическое семантическое (по заголовкам+абзацам) — точность поднялась до 74%;
2. Добавил гибридный поиск (векторы + BM25) и небольшую модель rerank — точность выросла до 83%;
3. Оптимизировал промпт и обязал выводить [не найдено информации] — уровень галлюцинаций снизился с 22% до менее 5%.

Кроме того, мы создали конвейер непрерывной оценки: перед каждым изменением прогоняли 200 вопросов через RAGAS, чтобы убедиться в отсутствии деградации.»

Итог: полная дорожная карта оптимизации RAG

Уровень данных ─→ очистка документов, оптимизация чанков, обогащение метаданными, предметный embedding
Уровень поиска ─→ гибридный поиск, rerank, переписывание запроса, HyDE, настройка Top‑K
Уровень генерации ─→ усиление промпта, инструкции, сжатие, цитирование, порог отказа
Уровень оценки ─→ оценочный набор, RAGAS, ручной анализ, A/B эксперименты