Суть
Короткий вопрос и длинный содержательный документ различаются по форме. Даже если они говорят об одном, их векторы могут оказаться далеко друг от друга. HyDE переводит запрос в форму документа прежде, чем искать:
- LLM генерирует гипотетический документ по вопросу.
- Энкодер строит его вектор.
- По вектору находятся ближайшие реальные документы корпуса.
- Ответ строится только по найденным реальным фрагментам.
Исходная работа решает задачу zero-shot retrieval: релевантных пар для дообучения ретривера нет, но генеративная модель умеет воспроизвести лексику и структуру вероятного ответа. Контрастивный энкодер превращает этот текст в область поиска среди настоящих документов.
Граница доказательности
Гипотетический документ может содержать выдуманные имена, числа и причинные связи — авторы метода называют его fake document прямо. Его функция заканчивается после построения поискового вектора.
Отсюда три запрета:
- не добавлять гипотезу в корпус как найденный документ;
- не показывать её пользователю как цитату или evidence;
- не смешивать её с retrieved chunks при проверке faithfulness.
Провенанс итогового ответа начинается с реального документа, найденного после HyDE, а не с текста генератора. Иначе retrieval-трюк превращается в самоподтверждающуюся галлюцинацию.
Один документ или несколько
Ядро метода требует одного гипотетического документа. Практический вариант может породить несколько, получить отдельный эмбеддинг каждого и усреднить векторы. Это снижает зависимость от одной формулировки, но не гарантирует разнообразия: одна модель с одним промптом часто производит несколько вариантов одной и той же гипотезы.
Усреднение также может размыть редкий, но правильный сигнал. Поэтому число гипотез — параметр retrieval, который проверяется на golden set, а не универсальное улучшение.
Когда применять
HyDE уместен, когда:
- нет relevance labels для обучения доменного ретривера;
- запросы короткие или формулируются иначе, чем документы;
- генератор знаком с языком и терминологией домена;
- дополнительный LLM-вызов укладывается в бюджет задержки и стоимости.
Он не заменяет Hybrid Search и Reranking. HyDE меняет представление запроса до dense retrieval; гибридный поиск добавляет лексический канал, а reranker переставляет уже найденных кандидатов. Выбор и комбинация определяются сравнением на одном наборе запросов по Hit Rate, MRR и latency (RAG Metrics).
Где ломается
- Генератор якорит поиск на правдоподобной, но неверной терминологии и уводит в неправильную область корпуса.
- Редкие идентификаторы и точные названия могут потеряться в длинном гипотетическом тексте; здесь лексический поиск часто надёжнее.
- Дополнительная генерация повышает latency и стоимость каждого запроса.
- Результат исходной статьи относится к конкретной постановке zero-shot dense retrieval и не доказывает превосходство HyDE на любом RAG-корпусе или с любым энкодером.
Практический гейт: сравнить прямой query embedding и HyDE на одном фиксированном наборе, сохранив одинаковыми корпус, chunking, encoder, top-k и downstream generation. Без такого A/B прирост качества невозможно отделить от смены других частей пайплайна.
Связано с
- RAG — HyDE меняет только шаг формирования retrieval-запроса.
- Embeddings — поиск переносится из пространства «вопрос — документ» в пространство «документ — документ».
- Hybrid Search — точный лексический канал компенсирует потерю редких терминов.
- Reranking — независимый последующий этап над найденными кандидатами.
- RAG Metrics — метод принимается только по сравнительному retrieval-eval.
- Agentic RAG — агент может выбирать HyDE как одну из стратегий повторного поиска.