Стандартний 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.