Стандартный RAG часто не находит нужные документы из-за асимметрии embedding-пространства: запрос кодируется в вектор из облака вопросов, далёкого от облака документов. Решение — HyDE (Hypothetical Document Embeddings). LLM генерирует гипотетический ответ на запрос, его embedding естественно ложится рядом с реальными документами. Наша команда внедряет HyDE под ключ: от выбора модели до интеграции в продакшн. За 5+ лет работы мы реализовали 30+ проектов по улучшению RAG, гарантируя прирост MRR на 10–15%.
Почему стандартный retrieval отстаёт
В обычном RAG embedding запроса попадает в область, отличную от документов. Embedding гипотетического ответа — наоборот, рядом с документами. Разница ощутима: на юридическом датасете (8500 доков) стандартный поиск даёт MRR@5=0.68, HyDE — 0.77 (+13% точности).
Обычный RAG: Запрос → Embedding(запрос) → поиск → документы HyDE: Запрос → LLM → Гипотетический_ответ → Embedding(ответа) → поиск → документы Как HyDE работает на практике?
Разберём на примере. В юридической сфере запрос «Каков срок исковой давности по трудовым спорам о невыплате зарплаты?» обычно ищет документы, где упомянуты сроки. LLM генерирует гипотетический документ вроде «Согласно Трудовому кодексу, срок исковой давности по спорам о невыплате зарплаты составляет 3 месяца…». Embedding этого документа почти совпадает с реальными статьями кодекса. Итог: retrieval находит не просто документы со словом «срок», а именно те, где срок описан — точность растёт.
Почему HyDE даёт прирост точности на 10–15%?
Причина в коллизии embedding-пространств. Запросы формулируются как вопросы — их векторы концентрируются в области вопросительных конструкций. Документы же написаны утвердительно, их embedding лежит в другой области. HyDE генерирует текст в стиле документа, и его embedding автоматически попадает в кластер реальных документов. На датасете из 8500 юридических документов мы замерили прирост MRR@5 с 0.68 до 0.77 — это 13%.
Как HyDE генерирует гипотетические документы: пример с LangChain
Реализация через LangChain минимальна. Код ниже показывает генерацию гипотетического документа и поиск в Qdrant.
from langchain.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI, OpenAIEmbeddings from langchain_core.runnables import RunnableParallel, RunnablePassthrough from langchain_community.vectorstores import Qdrant llm = ChatOpenAI(model="gpt-4o-mini", temperature=0.3) embeddings = OpenAIEmbeddings(model="text-embedding-3-large") vectorstore = Qdrant.from_existing_collection( embeddings=embeddings, collection_name="legal_docs", url="http://localhost:6333", ) HYDE_PROMPT = ChatPromptTemplate.from_template("""Напиши короткий отрывок документа (150-250 слов), который полностью отвечает на следующий вопрос. Пиши как фрагмент официального документа, без вводных фраз типа "Согласно документу". Вопрос: {question} Гипотетический документ:""") def hyde_retriever(question: str, top_k: int = 5) -> list: hypothetical_doc = llm.invoke( HYDE_PROMPT.format_messages(question=question) ).content docs = vectorstore.similarity_search(hypothetical_doc, k=top_k) return docs question = "Каков срок исковой давности по трудовым спорам о невыплате зарплаты?" docs = hyde_retriever(question) Когда стоит использовать HyDE?
HyDE особенно эффективен для больших корпусов (10 000+ документов) в специфичных доменах: юриспруденция, медицина, техническая документация. Вы платите 300–500 мс латентности за дополнительный вызов LLM. Для коротких запросов (номера, даты) лучше комбинировать с обычным retrieval и пропускать через reranker.
Сравнение методов на практике
На датасете из 8500 юридических документов и 300 тестовых вопросов мы получили:
| Метод | MRR@5 | NDCG@5 | Latency (ms) |
|---|---|---|---|
| Standard RAG | 0.68 | 0.65 | 180 |
| HyDE | 0.77 | 0.74 | 580 |
| Multi-Query | 0.81 | 0.78 | 650 |
| HyDE + Reranker | 0.84 | 0.81 | 820 |
HyDE даёт прирост точности, но latency растёт. Для production мы рекомендуем кэширование и параллельный вызов LLM.
Что входит в нашу работу по внедрению HyDE
- Анализ корпуса и запросов: оценка применимости HyDE, сбор метрик baseline.
- Интеграция HyDE: настройка пайплайна генерации гипотетических документов под вашу LLM (GPT-4o, Claude, LLaMA).
- Подбор промпта: 2–3 дня экспериментов с temperature, стилем и длиной ответа.
- Тестирование на ваших данных: замеры MRR, NDCG, latency p99.
- Оптимизация: внедрение кэширования, параллельного вызова LLM, комбинации с multi-query.
- Документация и обучение: передача кода, инструкций и демо-сессия для команды.
- Поддержка: 2 недели пост-продакшн мониторинга и корректировок.
Пошаговая инструкция внедрения HyDE (для технических специалистов)
- Соберите метрики baseline (MRR, NDCG) на вашем корпусе.
- Выберите LLM (GPT-4o-mini, Claude 3 Haiku — хороший баланс скорости/качества).
- Напишите промпт для генерации гипотетического документа (образец выше).
- Подключите векторное хранилище (Qdrant, Pinecone).
- Замените retriever в вашем RAG-пайплайне на hyde_retriever.
- Протестируйте на 100 случайных запросах, сравните с baseline.
- Если latency высока, добавьте кэш для частых запросов.
Сроки реализации
| Этап | Срок |
|---|---|
| Интеграция HyDE | 1–2 дня |
| Подбор промпта | 2–3 дня |
| Тестирование vs baseline | 2–3 дня |
| Итого | от 5 дней |
Стоимость рассчитывается индивидуально — зависит от объёма корпуса, количества LLM-запросов и необходимых доработок. Свяжитесь с нами: опишите задачу — мы предложим оптимальное решение. Если хотите дополнительно повысить точность, закажите аудит вашего корпуса — он покажет, насколько HyDE эффективен именно для ваших данных.
Подробнее о реализации HyDE читайте в документации LangChain. Получите консультацию: расскажите о ваших задачах — мы подберём подходящий вариант внедрения HyDE.