Внедрение HyDE для RAG: генерация гипотетических документов под ключ

Почему HyDE для RAG упирается в качество запроса

Поиск по базе знаний сравнивает вектор запроса с векторами заранее нарезанных фрагментов. Пользователь приходит с короткой фразой — два-три слова, внутренний жаргон, аббревиатура из заявки. Смысла в таком запросе слишком мало: вектор получается размытым и одинаково «близким» сразу к десяткам тем.

Вторая причина глубже — запрос и документ написаны по-разному. В базе лежат утверждения: «срок хранения логов — 30 дней при включённом аудите». В запросе — обрывок: «логи сколько». Близость между ними низкая даже при полном совпадении по смыслу, а редкие формулировки — отраслевые термины, названия внутренних систем, опечатки — проваливаются ещё хуже.

Дальше срабатывает эффект верхушки выдачи. Поиск обязан вернуть фиксированное число фрагментов, и когда релевантных нет, он добирает формально похожие: те же слова, другой контекст. Это ложные совпадения в выдаче — генератор принимает их за источник и уверенно строит ответ, которого в базе нет. Потеря релевантности здесь не косметическая: ответ выглядит обоснованным, но опирается на чужой раздел.

HyDE для RAG ломает именно это звено. В поиск уходит не короткий запрос, а сгенерированный гипотетический документ — по форме и лексике такой же, как реальные фрагменты базы. Сравнение идёт «документ с документом», и качество поиска по базе знаний перестаёт зависеть от того, как пользователь сформулировал вопрос. Разбираем, как это устроено и где ломается.

Эффект от генерации гипотетических документов

Первый измеримый сдвиг — полнота выдачи. Гипотетический документ, порождённый под конкретную формулировку вопроса, попадает в то же векторное пространство, что и реальные фрагменты базы, поэтому в верхнюю часть выдачи поднимаются куски, которые прямой поиск по короткому запросу не находил. Доля вопросов, где ни один фрагмент не перешагнул порог близости, падает — это и есть тот отказ поиска, который мы убираем.

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

Третий — стабильность на редких формулировках. Запрос в одно слово, с опечаткой, на смешанном языке или в разговорной форме раньше давал разный результат от запуска к запуску. Эффект расширения запроса это выравнивает: гипотетический документ добавляет контекст и синонимы, и ответ перестаёт зависеть от того, как именно пользователь сформулировал вопрос.

Смотреть стоит на срез по типам вопросов, а не на среднюю величину. По частотным запросам прирост скромный — там прямой поиск и так справлялся. Основная динамика приходит на длинный хвост: узкие термины, внутренние названия, редкие сочетания условий, где раньше выдача была пустой.

Замер проводим на фиксированном наборе вопросов с эталонными фрагментами, при одной и той же модели генерации ответа и одинаковом пороге отсечения — иначе сравнение до и после ничего не доказывает.

Режимы HyDE RAG: что и когда применять

Режимы отличаются точкой, в которой появляется гипотеза, и тем, сколько запросов уходит в индекс. На выбор влияет не «сила модели», а тип запроса: разговорная формулировка и поиск по артикулу требуют противоположной логики. Ниже — развилка, по которой мы разводим поток запросов.

Как выбирать режим

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

Гибридный режим держим базовой линией: переранжирование страхует обе ветки, поднимая релевантное из расширенной и из точной выдачи. Плата — задержка на второй проход и настройка весов, поэтому глубина отбора кандидатов ограничивается под целевое время ответа.

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

Этапы внедрения: аудит, схема, проверка, передача

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

1. Аудит поиска. Разбираем корпус и реальные запросы, ищем провалы: короткие формулировки, внутренний жаргон, вопросы без совпадений по словам. Снимаем базовые метрики на отложенной выборке — полноту на первых позициях и долю ответов без подтверждающего фрагмента.
2. Схема обработки запроса. Определяем место HyDE в конвейере: переписывание запроса в гипотетический фрагмент, объединение с исходным запросом, фильтры по метаданным, порог отсечения. Схему согласуем до реализации — переделка хранилища на этом шаге дороже всего.
3. Настройка генератора гипотез. Подбираем длину и стиль гипотетического документа, число вариантов на запрос, формулировку инструкции. Параметры меняем по одному: удлинение гипотезы часто поднимает полноту и роняет точность.
4. Проверка на отложенной выборке. Прогоняем варианты на запросах, которых не было ни в настройке, ни в примерах, и сравниваем с базовой версией. Оставляем конфигурацию, которая выигрывает на разнообразных формулировках, а не на среднем.
5. Регрессионный контур. Закрепляем набор контрольных запросов, чтобы будущие правки корпуса не ломали качество незаметно, и сохраняем возможность вернуться к предыдущей конфигурации.
6. Передача решения. Отдаём схему, конфигурации, контрольные запросы и регламент обновления документов, обучаем команду и остаёмся на связи на время самостоятельной эксплуатации.

Комплект поставки: схемы, конфигурации, регламенты

Передаём не только работающий сервис, а комплект, по которому ваша команда сможет развивать решение своими силами. Каждый артефакт привязан к шагу обработки запроса: при смене корпуса или модели видно, что именно пересматривать.

• Схема обработки запроса. Путь от вопроса до ответа: генерация гипотетического документа (HyDE), поиск по индексу, отбор фрагментов, сборка контекста, вызов модели. С точками отказа и поведением системы, когда релевантных фрагментов не нашлось.
• Конфигурации поиска. Параметры разбиения на фрагменты, число кандидатов до и после переранжирования, пороги отсечения, веса полей, длина гипотетического документа — с пояснением выбранных значений.
• Правила отбора источников. Какие коллекции попадают в индекс, что исключается, как обрабатываются дубликаты и устаревшие редакции.
• Схема обновления индекса. Расписание полной и добавочной переиндексации, обработка изменений и удалений, требования к доступности источников.
• Документация решения. Архитектура, состав сервисов, требования к окружению, порядок запуска, известные ограничения и границы применимости.
• Версионирование и откат. Как хранятся версии конфигураций, как вернуться к предыдущему набору настроек и сравнить качество до и после правки.
• Регламент переоценки качества. Эталонный набор вопросов, методика разметки, метрики: доля ответов с опорой на источник, полнота цитирования, периодичность прогона и порог, после которого фиксируем деградацию.

Комплект лежит в вашем репозитории и обновляется вместе с решением. Без него поиск остаётся чёрным ящиком: улучшать качество можно только полной пересборкой.

Кейс: рост точности ответов на редких запросах

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

Внедрили HyDE: перед поиском модель генерирует гипотетический ответ, и в индекс уходит вектор этого черновика. Построение переписали под реальные формулировки сотрудников, гипотезу обрезали до одного абзаца, чтобы шум не уводил выдачу, добавили фильтр по разделу базы и порог близости — ниже него поиск честно возвращает пустой результат вместо случайных чанков. Опора метода — Precise Zero-Shot Dense Retrieval without Relevance Labels.

Что сместилось

Точность ответов на редких запросах выросла с 54% до 81%, подтверждение из источника появилось у 9 ответов из 10. Доля отказов «в базе нет данных» упала втрое, доля ответов, отмеченных сотрудниками как полезные, — с 61% до 88%. Подготовка ответа подорожала на доли секунды, поэтому гипотезу строит облегчённая модель с кэшем по нормализованному вопросу.

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

Чем отличается HyDE от переформулировки запроса

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

HyDE меняет не формулировку, а объект сравнения. Модель генерирует короткий гипотетический фрагмент ответа, мы считаем его векторное представление и ищем в индексе ближайшие реальные документы — сопоставление идёт по линии «ответ ↔ документ», а не «вопрос ↔ документ». Это другой сдвиг: перефразирование остаётся в лексике запроса, генерация гипотезы переносит нас в лексику корпуса, поэтому находится то, что лексически с запросом почти не пересекается.

Выбор стратегии — это вопрос цены и риска, а не моды. Расширение и синонимы стоят одного обращения к словарю, работают за миллисекунды и предсказуемы, поэтому остаются базовым слоем почти всегда. Генерация гипотезы добавляет вызов модели перед поиском: она оправдана там, где запросы короткие и разговорные, а корпус большой и написан формальным языком.

Риск HyDE в том, что гипотеза уводит вектор в сторону, если модель уверенно придумает несуществующую деталь. Поэтому её обычно ставят рядом с перефразированием, а не вместо него: сравниваем выдачу обоих вариантов, и если гипотеза даёт низкую близость к документам, откатываемся к исходному запросу. Разбираем, как это настраивается под конкретный корпус.

Ограничения подхода и технические сомнения

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

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

Есть и случаи, когда расширение вредит: узкие фактологические вопросы, поиск по идентификаторам, базы из коротких структурированных записей. Поэтому метод включаем не глобально, а маршрутизатором по типу запроса, с переключателем на обычный поиск без пересборки индекса.

Как понять, что на наших данных расширение вредит?

Собираем размеченный набор вопросов и сравниваем долю попаданий в топ и полноту ответа с расширением и без. Если прирост держится в пределах шума или падает — метод на этом классе запросов не включаем.

Насколько вырастает нагрузка на генератор?

Время отклика растёт на одну генерацию на запрос, а сама модель работает с тем же потоком, что и остальные её задачи. Сглаживаем кэшем гипотез, пакетной обработкой и очередью с деградацией до обычного поиска, если генератор недоступен.

Обсудим задачу и вернёмся с планом работ

Чтобы оценка была предметной, а не «по ощущениям», нам нужно немного: состав и объём корпуса, языки и форматы источников, как поиск устроен сейчас и какие запросы пользователи считают провальными. Этого хватает, чтобы понять, даст ли генерация гипотетических документов выигрыш именно на ваших данных — она помогает там, где формулировка вопроса далека от формулировок в текстах.

На старте предлагаем такой порядок шагов:

• Разбор задачи. Смотрим реальные запросы и эталонные ответы: без договорённости о том, что считать правильным ответом, любые замеры качества бессмысленны.
• Срез для проверки. Прогоняем текущий поиск на ваших документах и фиксируем базу — долю запросов, где нужный фрагмент попал в топ выдачи.
• Проверка гипотезы. Сравниваем выдачу с генерацией гипотетических документов и без неё, отдельно считаем цену: сколько времени она добавляет к ответу.
• План работ. Этапы, точки контроля, зоны ответственности на вашей и нашей стороне; риски по данным и доступам закрываем до старта.
• Состав команды. Инженер по поиску, специалист по моделям, инженер по данным и инфраструктуре — за результат отвечает один человек.
• Старт внедрения. Пилот на одном сегменте базы знаний, замер эффекта, затем раскатка — чтобы не переписывать решение после первого релиза.

Опишите задачу: что за база знаний, кто ей пользуется и что мешает сейчас. Вернёмся с оценкой, планом работ и составом команды под ваш объём.