Question-to-Question Retrieval: вопросные эмбеддинги вместо документов

ОФЛАЙН (индексация документов):

ШАГ 1: Разбить документы на чанки (800 символов, перекрытие 200)
ШАГ 2: Для каждого чанка → Qwen3-8B генерирует ~10 answerable questions (AQ)
ШАГ 3: AQ эмбеддятся через E5-encoder → индекс вопросов (каждый AQ привязан к исходному чанку)

ОНЛАЙН (обработка запроса):

ШАГ 1: Сложный вопрос → LLM (GPT-4o/Gemini/LLaMA) → последовательность подвопросов
ШАГ 2: Каждый подвопрос эмбеддится → поиск top-100 похожих AQ → получение связанных чанков
ШАГ 3: Чанки реранкируются кросс-энкодером относительно ОРИГИНАЛЬНОГО вопроса → top-7
ШАГ 4: Top-7 чанков + оригинальный вопрос → LLM генерирует ответ

⚠️ Зона применения: Сложные вопросы, требующие информации из разных частей документов. Не для простых фактов ("столица Франции") — декомпозиция не нужна.

Задача: У тебя коллекция разборов стартапов из подкастов вроде "Деструктивный пидкастинг". Хочешь понять: "Какие факторы успеха у компаний, которые поднимали раунды от Runa Capital и вышли в прибыль за 2 года?"

Промпт (декомпозиция вопроса):

Разбей этот вопрос на последовательность простых подвопросов, каждый из которых можно ответить отдельно:

"Какие факторы успеха у компаний, которые поднимали раунды от Runa Capital и вышли в прибыль за 2 года?"

Результат (декомпозиция): Модель выдаст 2-3 подвопроса:

1. "Какие компании поднимали раунды от Runa Capital?"
2. "Какие из этих компаний вышли в прибыль за 2 года?"
3. "Какие факторы успеха упоминаются для этих компаний?"

Промпт (генерация AQ из документа):

Из этого текста сгенерируй 10 конкретных вопросов, на которые можно ответить ТОЛЬКО из этого текста, без внешних знаний:

[кусок интервью: "Фаундер рассказал, что ключевым было решение сфокусироваться на B2B вместо B2C после первого пивота..."]

Результат (AQ):

• "На чём сфокусировалась компания после пивота?"
• "Какую аудиторию выбрали: B2B или B2C?"
• "Что стало ключевым решением для фаундера?"

Дальше: Эти сгенерированные вопросы эмбеддятся. Когда приходит подвопрос "Какие факторы успеха...", система ищет похожие AQ ("Что стало ключевым...") → находит нужные куски → реранкирует → собирает финальный ответ.

Слабость LLM: Эмбеддинг-модели обучены сопоставлять тексты, но вопросы и документы структурно разные — как сравнивать телеграмму с романом. Вопрос: "Где?", "Кто?", "Когда?" — короткий, прямой. Документ: повествование, контекст, детали. Даже если семантически связаны, синтаксис режет — эмбеддинг ловит форму, не только смысл.

Сильная сторона LLM: Модель умеет порождать вопросы из текста — это требует понимания что важно, что спрашивается, как информация связана. Когда LLM генерирует 10 вопросов из чанка, она переваривает текст с разных углов: что явно сказано, что подразумевается, что можно спросить. Это не просто перефразировка — это семантическая карта документа через призму вопросов.

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

Рычаги управления:

• Количество AQ (m): По умолчанию ~10 вопросов на чанк. Больше → больше покрытие, но больше шума. Меньше → быстрее, но можешь пропустить нюансы.
• Размер чанка и overlap: 800 символов с перекрытием 200 — баланс между контекстом и гранулярностью. Меньше чанк → больше точность, но теряется контекст. Больше → лучше контекст, но хуже таргетинг.
• k1 (candidates) и k2 (final): k1=100 AQ кандидатов, k2=7 финальных чанков. Уменьши k2 до 5 для экономии токенов, увеличь до 10-15 если есть запас и хочешь больше контекста (работает лучше с Gemini, хуже с LLaMA).
• Декомпозиция ON/OFF: На простых датасетах (HotpotQA) декомпозиция даёт меньше выигрыша — можно пропустить. На сложных (MuSiQue, 2WikiMultiHopQA) — обязательна.

Из этого текста сгенерируй {количество_вопросов} конкретных вопросов, на которые можно ответить ТОЛЬКО из этого текста, без привлечения внешних знаний.

Требования:
- Вопросы должны быть фактическими и конкретными
- Каждый вопрос должен иметь чёткий ответ в тексте
- Используй явные отсылки к существительным и событиям из текста
- Не дублируй вопросы, делай их разнообразными
- Покрывай и явную информацию, и то что подразумевается

ТЕКСТ:
{текст_чанка}

Выведи вопросы списком, каждый с новой строки.

Пояснение: {количество_вопросов} — обычно 10; {текст_чанка} — кусок документа 600-1000 символов.

Разбей этот сложный многошаговый вопрос на последовательность простых одношаговых подвопросов.

Требования:
- Каждый подвопрос должен быть независимым и фокусированным
- Подвопросы должны логически вести к ответу на исходный вопрос
- Формулируй так, чтобы на каждый можно было найти прямой ответ в документах
- Количество подвопросов: от 2 до 5, в зависимости от сложности

ИСХОДНЫЙ ВОПРОС:
{вопрос_пользователя}

Выведи подвопросы списком, в порядке рассуждения.

Пояснение: {вопрос_пользователя} — многошаговый вопрос ("Где родился основатель компании, которая выпустила первый смартфон на Android?").

Структурное выравнивание — ключ. Классический RAG делает так:

Запрос (20 слов) → Embedding → [vector]
Документ (500 слов) → Embedding → [vector]
Сравнение: cosine_similarity([vector_query], [vector_doc])

Проблема: запрос и документ разные по природе. Это как сравнивать телеграмму "СРОЧНО ПРИЕЗЖАЙ" с романом "Война и мир" — суть может быть связана, но форма убивает сигнал. Эмбеддинг-модели улавливают не только смысл, но и структуру: длину предложений, стиль, синтаксис.

Question-to-Question Retrieval переворачивает:

Запрос (20 слов) → Decomposition → [Q1, Q2, Q3] → Embedding → [v1, v2, v3]
Документ (500 слов) → AQ Generation → [AQ1...AQ10] → Embedding → [w1...w10]
Сравнение: cosine_similarity(v_i, w_j) — оба вопросы!

Теперь обе стороны симметричны: короткие, вопросительные, целевые. Эмбеддинг ловит смысл без структурного шума.

Почему генерация AQ обогащает документ:

Когда LLM генерирует вопросы из текста, она делает cognitive processing:

1. Извлечение фактов: "Что явно сказано?"
2. Вывод связей: "Что подразумевается?"
3. Формулировка запросов: "Как бы человек это спросил?"

Это не перефразировка (summarization/paraphrasing меняют слова, но сохраняют структуру). Это реструктуризация — текст превращается в карту возможных вопросов. Каждый AQ — это семантический хук, за который зацепится пользовательский запрос.

Эксперименты показали:

• Document embeddings: Baseline, слабо
• Summary embeddings: +небольшой прирост (сжатие помогает, но теряется детализация)
• Paraphrase embeddings: +минимальный прирост (слова меняются, структура остаётся)
• AQ embeddings: +драматический скачок (структура меняется под вопросы)

Данные из статьи (F1-score, GPT-4o):

• 2WikiMultiHopQA: Document 38.95 → AQ 67.29 (+28.34)
• MuSiQue: Document 29.26 → AQ 54.08 (+24.82)

⚠️ Латентность: Множественные подвопросы = множественные поиски + реранкинг. Для сложных вопросов время ответа увеличивается в 2-3 раза по сравнению с direct retrieval. Если нужна скорость — упрости декомпозицию или используй кэширование.

⚠️ Зависимость от качества AQ: Если LLM генерирует нерелевантные или слишком общие вопросы, индекс зашумляется. Qwen3-8B справляется хорошо, но на специфичных доменах (медицина, юриспруденция) может потребоваться fine-tuning или few-shot промптинг с примерами.

⚠️ Офлайн индексация: Нужно прогнать LLM по всем документам один раз для генерации AQ. Это не бесплатно — для корпуса в 10,000 документов (по 5 чанков каждый) это 50,000 генераций. С Qwen3-8B локально — ок, через API — $$.

⚠️ Не для простых вопросов: На односложных запросах ("Кто президент России?") декомпозиция избыточна, а AQ не даёт преимущества. Метод выигрывает на многошаговых и сложных запросах, где нужна цепочка рассуждений.

⚠️ Требует инфраструктуры для полной реализации: Двухэтапный поиск (эмбеддинги + реранкинг) требует vector database и cross-encoder. Это не просто "скопировал промпт в чат". НО принципы (декомпозиция, question-centric thinking) применимы вручную.

Команда протестировала метод на трёх хардкорных бенчмарках для многошаговых вопросов из LongBench: HotpotQA, 2WikiMultiHopQA и MuSiQue. Эти датасеты злые — требуют собрать ответ из кусков, разбросанных по разным документам. Full-wiki setup, то есть модель ищет в полной Википедии, не в заранее отфильтрованных 10 документах.

Сравнивали с No-RAG (LLM сам по себе), Self-RAG (модель сама решает когда искать), Query Rewriting (переформулировка запроса), ReSP (итеративное саммаризование), RAPTOR, LongRAG и MacRAG (свежий baseline с теми же LLM). Использовали три LLM: GPT-4o, Gemini-1.5-Pro, LLaMA-3.1-8B-inst. Метрика — F1-score (насколько ответ совпадает с reference).

Что удивило: AQ-эмбеддинги дали драматический скачок по сравнению с прямыми document embeddings — не 2-5%, а +20-30 F1 points. Это огромный gap. Ожидали улучшение, но не такое. Похоже, структурный мисматч вопрос-документ убивал качество сильнее, чем думали.

Интересная деталь: На HotpotQA декомпозиция давала меньший выигрыш, чем на MuSiQue. Почему? Посмотрели статистику декомпозиций — HotpotQA разбивается в среднем на 2.21 подвопроса (узкое распределение), а MuSiQue и 2WikiMultiHopQA — на 2.31-2.66 (шире разброс, до 6 подвопросов). HotpotQA проще структурно, меньше шагов, поэтому от разбивки меньше пользы.

Вывод из эксперимента: Унифицированная генерация (весь контекст сразу) билa последовательную (ответ на каждый подвопрос отдельно). GPT-4o и Gemini любят длинный контекст — могут reasoning делать лучше. LLaMA-3.1-8B наоборот, страдает от "Lost in the Middle" — чем больше чанков, тем хуже. Оптимальный k2 (сколько чанков в финал): GPT-4o любит 7-10, Gemini тянет до 15, LLaMA лучше 5.

Почему summary/paraphrase не сработали? Саммари сжимает, но теряет детали. Парафраз переформулирует, но структура остаётся narrative. AQ реструктурирует в вопросы — вот где магия. Это не про слова, это про форму мысли.

• Transforming Questions and Documents for Semantically Aligned Retrieval-Augmented Generation (Seokgi Lee, Seoul National University)
• Бенчмарки: HotpotQA (Yang et al. 2018), 2WikiMultiHopQA (Ho et al. 2020), MuSiQue (Trivedi et al. 2022) из LongBench (Bai et al. 2024)
• Модели: Qwen3-8B для AQ генерации, E5-multilingual для эмбеддингов, ms-macro-MiniLM-L-12-v2 для реранкинга

Применение: Вместо RAG-системы с кодом, используй вручную в Claude Projects или ChatGPT с Memory.

Workflow:

1. Офлайн подготовка: Загрузи документ → попроси сгенерировать 10 вопросов из каждого раздела → сохрани в отдельный файл или чат.
2. Онлайн поиск: Когда нужен ответ, открой файл с вопросами → визуально сканируй или используй Ctrl+F по ключевым словам → найди похожий вопрос → вернись к исходному чанку.

Промпт для генерации AQ (адаптация для ручного использования):

Я буду загружать части документа. Для каждой части сгенерируй 10 конкретных вопросов, которые можно задать про этот текст. Формулируй как если бы человек искал информацию. Вопросы должны быть:
- Конкретными и фактическими
- Покрывать и явное, и скрытое
- Разнообразными (кто, что, где, когда, почему, как)

После вопросов укажи номер части для ссылки.

---
ЧАСТЬ 1:
{текст}

Вопросы для части 1:
[генерация]

---
ЧАСТЬ 2:
{текст}

Вопросы для части 2:
[генерация]

Это создаёт ручной индекс вопросов, привязанных к частям документа. Не нужен код — просто структурированный файл.

Принцип метода — разбивать сложное на простое — можно усилить CoT на каждом шаге.

Стандартная декомпозиция:

Вопрос: "Какие факторы успеха у компаний, которые поднимали раунды от X?"

Подвопросы:
1. Какие компании поднимали раунды от X?
2. Какие из них успешны?
3. Какие факторы упоминаются?

Декомпозиция + CoT:

Вопрос: "Какие факторы успеха у компаний, которые поднимали раунды от X?"

Подвопросы с рассуждением:

1. "Какие компании поднимали раунды от X?"
 Рассуждение: Сначала найти список компаний-портфелио.

2. "Какие критерии успеха применимы? (выручка/прибыль/рост/exit?)"
 Рассуждение: Уточнить определение успеха до поиска.

3. "Какие из компаний соответствуют этим критериям?"
 Рассуждение: Фильтрация списка по метрикам.

4. "Какие общие факторы упоминаются в их историях?"
 Рассуждение: Поиск паттернов (команда, тайминг, продукт, рынок).

Добавление рассуждения делает декомпозицию прозрачнее и помогает модели не пропустить неявные шаги.

Принцип метода наоборот: не создавай документ, создавай вопросы, которые он должен отвечать.

Сценарий: Пишешь knowledge base статью или FAQ.

Стандартный подход:

1. Пишешь текст
2. Потом пытаешься индексировать/структурировать

Question-First подход:

1. Сначала генеришь вопросы, которые пользователи будут задавать
2. Потом пишешь текст, отвечающий на эти вопросы
3. Структура документа = структура вопросов

Промпт:

Мне нужна статья про {тема}. 

Шаг 1: Сгенерируй 20 вопросов, которые человек мог бы задать про эту тему. Покрой:
- Базовые определения
- Практическое применение
- Частые ошибки
- Продвинутые нюансы

Шаг 2: Для каждого вопроса напиши краткий ответ (2-3 предложения).

Шаг 3: Сгруппируй вопросы по темам и создай структуру статьи.

Результат: Документ, оптимизированный под поиск с самого начала, потому что написан через призму вопросов.