Продвинутый RAG: векторные БД, оценка качества и галлюцинации

Темы 59–62: HyDE, multi-query и graph RAG, HNSW и IVF-PQ в векторных базах, метрики поиска и ответа, борьба с галлюцинациями.

59. Продвинутый RAG

Важность на собеседовании: 9/10 █████████░

🔥🔥🔥 Критично для middle+. Отличает того, кто собрал туториал, от того, кто доводил RAG до рабочего состояния. Не нужно знать все 40 разновидностей — нужно понимать 5–6 приёмов и когда каждый оправдан.

Работа с запросом (до поиска):

• Query rewriting — LLM переписывает запрос пользователя в удобный для поиска вид. Особенно важно в диалоге: «а сколько это стоит?» без истории бессмысленно, надо развернуть в «сколько стоит тариф Премиум».
• Query decomposition — сложный вопрос разбивается на подвопросы, по каждому свой поиск. Нужно для многошаговых вопросов («сравни условия по А и по Б»).
• HyDE (Hypothetical Document Embeddings) — LLM пишет гипотетический ответ на вопрос, и ищем мы по эмбеддингу этого ответа. Логика: ответ по стилю и лексике ближе к документам, чем вопрос. Хорошо работает там, где вопрос и документ сформулированы по-разному.
• Step-back prompting — сначала задаём более общий вопрос, чтобы достать фоновый контекст, потом конкретный.
• Multi-query — генерируем несколько переформулировок и объединяем результаты. Дёшево и заметно поднимает recall.

Работа с результатами (после поиска):

• Реранкинг cross-encoder'ом — самая окупаемая оптимизация.
• Сжатие контекста — выбросить из найденных чанков предложения, не относящиеся к вопросу. Экономит токены и снижает шум.
• MMR (Maximal Marginal Relevance) — балансирует релевантность и разнообразие, чтобы в топ-5 не попали пять почти одинаковых чанков.
• Фильтрация по порогу — если ни один чанк не набрал минимальной релевантности, честно ответить «не нашёл», а не генерировать по мусору.

Архитектурные варианты (знать названия и суть):

• Agentic RAG — поиск становится инструментом, который агент вызывает столько раз, сколько нужно, между рассуждениями. Это главный сдвиг 2026 года: RAG перестал быть «один раз загрузить контекст в начало» и стал частью управляющей логики.
• Self-RAG — модель сама решает, нужен ли поиск, и оценивает, поддержан ли её ответ найденным.
• Corrective RAG (CRAG) — оценивает качество найденного и, если плохо, идёт в веб-поиск или переформулирует.
• GraphRAG — строит граф сущностей и связей. Сильно выигрывает на вопросах «как связаны X и Y» и на обобщающих вопросах по всему корпусу, где обычный top-k бесполезен.
• RAPTOR — иерархические суммаризации: кластеризуем чанки, суммируем кластеры, строим дерево. Позволяет отвечать и на детальные, и на обзорные вопросы.
• CAG (Cache-Augmented Generation) — для маленькой статичной базы: загружаем всё в контекст один раз и кэшируем. Проще и быстрее RAG там, где применимо.

Порядок внедрения (правильный ответ на «с чего начать»):

1. Сначала eval-набор и метрики. До любых улучшений.
2. Простой пайплайн: рекурсивный чанкинг → готовый эмбеддер → векторная БД → промпт.
3. Гибридный поиск.
4. Реранкер.
5. Работа с запросом (переписывание, мульти-запрос).
6. Улучшение чанкинга под свои документы.
7. И только в самом конце — дообучение эмбеддера на домене.

Такой порядок — от дешёвого и эффективного к дорогому — сам по себе хороший сигнал для интервьюера.

Вопрос: Когда GraphRAG оправдан, а когда это оверинжиниринг? — Оправдан, когда вопросы требуют связывать информацию из разных документов («какие проекты вёл этот человек и с кем пересекался») или обобщать по всему корпусу («какие основные темы жалоб за квартал») — обычный top-k здесь бессилен. Оверинжиниринг, когда вопросы фактологические и ответ целиком лежит в одном фрагменте: построение и поддержка графа дороги, а выигрыша не будет.

60. Векторные БД и приближённый поиск

Важность на собеседовании: 8/10 ████████░░

🔥🔥🔥 Критично. Спрашивают «какую БД выбрал и почему» и «как работает HNSW». Ждут инженерного, а не маркетингового ответа — и умения сказать «нам хватило pgvector».

Разбивка:

Задача. Найти ближайшие векторы среди миллионов. Точный перебор — O(n) на запрос, не масштабируется. Значит нужен приближённый поиск (ANN): мы сознательно жертвуем частью полноты ради скорости. Главный компромисс: recall против latency против памяти.

HNSW (Hierarchical Navigable Small World) — доминирующий алгоритм. Идея: строим многослойный граф. Верхние слои разрежены — по ним делаем «дальние прыжки», нижние плотные — по ним уточняем. Аналогия — сначала долетели до нужного города, потом на такси до дома.

• M — сколько связей у узла. Больше — выше recall, больше памяти.
• ef_construction — тщательность построения индекса.
• ef_search — сколько кандидатов рассматривать при поиске. Главный рычаг в рантайме: крутите его, чтобы поменять recall на скорость без перестройки индекса.
• Свойства: recall 95%+ «из коробки», принимает новые вектора без перестройки, но памяти нужно в 2–5 раз больше, чем у IVF.

IVF (Inverted File Index). Кластеризуем векторы (k-means), при поиске смотрим только несколько ближайших кластеров (nprobe). Строится быстро, памяти мало, но recall «плывёт» при изменении данных и требует переобучения кластеров.

PQ (Product Quantization). Сжатие: вектор режется на части, каждая заменяется номером ближайшего центроида из маленького словаря. Память падает в десятки раз, точность немного тоже. Комбинируется: IVF+PQ — стандарт для миллиардов векторов.

Что выбрать (честный ответ на собесе):

По замерам при 50 млн векторов и recall 99% специализированные движки дают на порядок больший QPS, чем pgvector. Но для большинства задач до 10 млн векторов правильный ответ — начать с pgvector и не плодить инфраструктуру.

Практические моменты, которые ценятся:

• Фильтрация по метаданным должна применяться до/во время поиска, а не после. Иначе после фильтра от топ-100 останется 3 результата. В корпоративных системах через этот же механизм реализуются права доступа.
• Мультитенантность — изоляция данных клиентов через отдельные коллекции или обязательный фильтр по tenant_id.
• Переиндексация — при смене модели эмбеддингов надо пересчитать всю базу. Планируйте это заранее.
• Нормализуйте векторы и используйте скалярное произведение вместо косинуса — быстрее при том же результате.

Вопрос: Как выбрать между HNSW и IVFFlat в pgvector? — HNSW для большинства задач: выше recall из коробки, спокойно принимает новые записи. IVFFlat, если данных очень много, они почти не меняются, а память или время построения индекса критичны. Практически: до 10 млн векторов с активной записью — HNSW.

61. Оценка RAG

Важность на собеседовании: 10/10 ██████████

🔥🔥🔥 Критично. Прямо назван вопросом, на котором отказывают сильным кандидатам. Если на «как измеряли качество» вы отвечаете «смотрели глазами» — секция провалена. Разобрано досконально.

Главный принцип: мерить retrieval и generation раздельно. Иначе непонятно, что чинить.

Метрики поиска

• Recall@k — доля вопросов, для которых нужный фрагмент попал в топ-k. Самая важная метрика ретривера: это потолок качества всей системы. Чего не нашли — того не будет в ответе.
• Precision@k — доля релевантных среди найденных. Влияет на шум в контексте.
• MRR — насколько высоко стоит первый правильный.
• NDCG@k — учитывает и позицию, и степень релевантности.

Метрики ответа (RAGAS-подобные)

• Faithfulness (обоснованность) — доля утверждений в ответе, которые подтверждаются найденным контекстом. Прямо меряет галлюцинации. Главная метрика генератора.
• Answer relevancy — отвечает ли ответ на заданный вопрос.
• Context precision — насколько найденный контекст релевантен, нет ли мусора.
• Context recall — вся ли нужная для ответа информация оказалась в контексте.

Считаются они LLM-судьёй, то есть без ручной разметки — этим и удобны. Инструменты: RAGAS, DeepEval, TruLens, LangSmith, Arize Phoenix, Braintrust.

Как построить оценку с нуля — практический план

1. Собрать golden-набор: 50–200 пар «вопрос → эталонный ответ → фрагменты-источники». Брать из реальных запросов пользователей, а не выдумывать: настоящие вопросы кривые, неполные и содержат опечатки, а синтетические — стерильные.
2. Разметить вручную минимум для части набора. Это скучно и это надо сделать. Можно ускорить: LLM генерирует вопросы по документам, человек проверяет.
3. Замерить бейзлайн. До любых улучшений.
4. Прогонять весь набор на каждое изменение — промпта, чанкинга, эмбеддера, модели. Это регрессионное тестирование.
5. Валидировать судью. Проверить, что оценки LLM-судьи коррелируют с человеческими на контрольной выборке (корреляция Спирмена). Без этого шага судья — просто ещё один источник шума.
6. Онлайн-метрики: лайки/дизлайки, доля эскалаций на человека, повторные запросы, время до решения, конверсия. В конечном счёте только они и важны бизнесу.

Три уровня оценки — так и стоит отвечать

Вопрос: Как мерить качество, если правильного ответа не существует (открытый вопрос)? — Через критерии, а не через сравнение с эталоном: обоснованность (все ли утверждения подтверждены источниками), полнота (покрыты ли ключевые пункты из чек-листа), отсутствие противоречий, соблюдение формата. Плюс попарное сравнение side-by-side двух версий системы — людям и судье проще сказать «А лучше Б», чем поставить абсолютную оценку. Плюс продуктовые метрики на реальном трафике.

62. Галлюцинации

Важность на собеседовании: 9/10 █████████░

🔥🔥🔥 Критично. Спрашивают всегда. Слабый ответ — «добавить RAG». Сильный — понимать, почему модель галлюцинирует и что для разных типов галлюцинаций нужны разные лекарства.

Почему модель врёт — корень проблемы. Модель обучена выдавать правдоподобное продолжение текста, а не истину. Когда она не знает ответа, у неё нет механизма «промолчать» — она сэмплирует наиболее вероятные токены, и получается текст, который выглядит правильно, но ничем не подкреплён. Плюс SFT усугубляет: в обучающих примерах ответы всегда уверенные и полные, и модель выучивает, что отвечать надо всегда.

Четыре типа галлюцинаций — и разные лекарства для каждого:

Что делать — по слоям:

До генерации: RAG с качественным поиском; вызов инструментов там, где нужны точные вычисления или свежие данные; фильтрация нерелевантного контекста.

В промпте: «отвечай только на основании контекста»; явно разрешить не знать («если информации нет, напиши "не найдено"») — без этого модель обязана что-то выдумать; требовать цитату к каждому утверждению; температура 0 для фактических задач.

После генерации: проверить, что все цитаты ведут на реально существующие чанки; прогнать проверку обоснованности (модель-судья сверяет утверждения с контекстом); при низкой уверенности — эскалация на человека.

Ключевая цифра: структурированные, чистые источники против сваленных в кучу дают снижение галлюцинаций в разы. То есть половина борьбы с галлюцинациями — это качество данных на входе, а не промпты.

Важная честность: галлюцинации нельзя устранить полностью — это следствие того, как устроена генерация. Можно снизить частоту и, что важнее, сделать их обнаружимыми. Ответ «мы гарантированно убрали галлюцинации» на собеседовании звучит наивно; ответ «мы снизили долю необоснованных утверждений с 12% до 3% и добавили автоматическую проверку цитат» — профессионально.

Вопрос: Нужный фрагмент найден и лежит в контексте, а модель всё равно отвечает неверно. Причины? — Контекст слишком длинный и факт «потерялся в середине»; в контексте есть противоречащие фрагменты и модель выбрала не тот; промпт не заставляет опираться на контекст, и модель отвечает из своих внутренних знаний; температура слишком высокая; чанк содержит факт в неявной форме, требующей вывода. Диагностика — сократить контекст до одного нужного чанка и проверить, отвечает ли модель правильно тогда.

Часть 13 из 17 конспекта для подготовки к собеседованиям на NLP/LLM-разработчика. Остальные части — в разделе «Собесы».