TL;DR
TCDE — техника поиска, которая расширяет и запрос, и документы через общие топики для лучшего совпадения. Обычно расширяют что-то одно: либо "распушают" запрос (добавляют синонимы, контекст), либо обогащают документ. TCDE делает оба шага синхронно: модель извлекает 5 ключевых тем из запроса и генерирует по мини-документу на каждую, затем из каждого документа выжимает 5 тематических предложений. Поиск идёт по расширенным версиям — они лучше "видят" друг друга.
Проблема раздельного расширения — семантический дрейф. Расширил запрос — добавил контекста, но этого контекста нет в документах. Расширил документы — добавил деталей, которых нет в запросе. В итоге: запрос про "инвестиции в стартапы", расширение добавило "венчурные фонды, бизнес-ангелы", а документы расширены про "финансирование, капитал" — разные слова, хотя смысл один. Модель может промахнуться. В цифрах: спросил 100 слов, расширение выдало то 80, то 120 — нестабильно.
TCDE синхронизирует через топики: модель сначала определяет о чём именно запрос (например: "риски стартапов", "этапы финансирования", "оценка команды"), генерирует текст по каждому топику. Потом извлекает из документов предложения по тем же топикам. Результат — общий "язык" между запросом и документами. Тематические мосты работают на двух уровнях: лексическом (больше общих слов) и семантическом (ближе в пространстве эмбеддингов).
Схема метода
ШАГ 1 (Query Expansion): LLM извлекает 5 топиков из запроса → генерирует мини-документ на каждый топик
ШАГ 2 (Document Expansion): LLM извлекает 5 ключевых тематических предложений из каждого документа
ШАГ 3: Расширенный запрос (оригинал + 5 мини-документов) ищется по расширенным документам (оригинал + 5 тематических предложений)
Шаги 1-2 выполняются отдельными запросами к LLM. Шаг 3 — поиск через BM25 или векторную модель.
Пример применения
⚠️ Ограничения метода: TCDE требует поисковую инфраструктуру (индексация документов, векторный поиск или BM25). Прямое применение в чате ограничено. Но принцип topic-alignment работает для ручного анализа документов.
Задача: У вас 15 коммерческих предложений от подрядчиков на разработку мобильного приложения. Нужно найти тех, кто реально понимает специфику вашего бизнеса (маркетплейс для локальных услуг) и предлагает релевантное решение, а не шаблонную отписку.
Промпт (адаптация принципа для ручного анализа):
У меня есть запрос: "Разработка iOS/Android приложения для маркетплейса локальных услуг: мастера публикуют услуги, клиенты бронируют, встроенный чат, оплата и рейтинги."
И 15 коммерческих предложений от подрядчиков.
Шаг 1: Извлеки 5 ключевых тематических аспектов из моего запроса — что именно важно для оценки подрядчика.
Шаг 2: Для каждого КП извлеки 5 ключевых тематических предложений — о чём они реально говорят в предложении.
Шаг 3: Сопоставь топики КП с топиками моего запроса. Покажи матрицу совпадений: какие подрядчики покрывают мои темы, а какие отвечают мимо.
[Вставить тексты КП]
Результат:
Модель выдаст: 1. 5 топиков вашего запроса (например: "двусторонний маркетплейс", "встроенные коммуникации", "платёжная интеграция", "система репутации", "кроссплатформенность") 2. 5 топиков из каждого КП — что реально предлагают (например: один про "красивый UI", другой про "масштабируемую архитектуру", третий про "опыт в маркетплейсах") 3. Матрицу соответствия — визуально видно кто попал в ваши темы, а кто шлёт общие слова
Почему это работает
Слабость поиска: Когда расширяешь только запрос или только документ, они могут разойтись семантически. Расширил запрос — добавил "венчурные фонды, pitch deck", а в документе таких слов нет, хотя смысл тот же. Или наоборот: документ расширен деталями, которых нет в запросе. Semantic mismatch — запрос и документ говорят об одном, но разными словами после расширения.
Сильная сторона LLM: Модель умеет извлекать абстрактные топики — ключевые темы без воды. Топик — это не пересказ, а сжатая суть. Вместо "мы предлагаем разработку мобильного приложения с использованием современных технологий" → топик "кроссплатформенная разработка". Компактно и однозначно.
Как TCDE использует это: Метод создаёт общий тематический словарь между запросом и документами. Оба расширяются через топики — получается синхронизация. Запрос превращается в набор мини-документов по темам, документ сжимается в ключевые тематические предложения. При поиске они лучше находят друг друга — больше общих слов (лексический уровень) и ближе в пространстве эмбеддингов (семантический уровень). Визуально: t-SNE показывает, что после TCDE релевантная пара (запрос, документ) сдвигается ближе (cosine similarity 0.64 → 0.74), а нерелевантная остаётся далеко.
Рычаги управления: - Число топиков (5 в оригинале) — уменьши до 3 для узких запросов, увеличь до 7-10 для многогранных тем - Повтор оригинала (5 раз в запросе) — усиливает вес исходной формулировки vs сгенерированных топиков; убери повторы если хочешь чистый поиск по топикам - Формат извлечения топиков — можешь заменить "одно предложение на топик" на "ключевые слова" или "короткие фразы" для ещё большей компактности
Шаблон промпта (адаптация для ручного анализа)
**Задача:** {описание что ищешь или анализируешь}
**Документы/тексты для анализа:** {тексты}
Шаг 1: Извлеки {число} ключевых тематических аспектов из моей задачи — что именно важно.
Шаг 2: Для каждого документа извлеки {число} ключевых тематических предложений — о чём реально этот текст.
Шаг 3: Сопоставь топики документов с топиками задачи. Покажи матрицу: какие документы покрывают мои темы, какие нет, где есть пробелы.
Заполнение:
- {описание что ищешь} — твой запрос или критерии поиска
- {тексты} — документы, резюме, статьи, предложения для анализа
- {число} — обычно 5, но можно 3-7 в зависимости от сложности
🚀 Быстрый старт — вставь в чат:
Вот шаблон TCDE для анализа документов через топики. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит: что именно ты анализируешь, сколько документов, какие критерии важны — потому что от этого зависит сколько топиков извлекать и на чём фокусироваться. Она возьмёт паттерн "топики запроса → топики документов → сопоставление" и адаптирует под твою ситуацию.
Ограничения
⚠️ Требует инфраструктуры для прямого применения: Полная реализация TCDE (автоматический поиск по большой коллекции) требует поисковой системы, индексации документов, API для массовой обработки. В чате можно применить принцип topic-alignment вручную для анализа 5-20 документов, но не для автоматического поиска в тысячах.
⚠️ Затраты на расширение: Каждый документ нужно предварительно обработать через LLM (извлечь топики). Для большой коллекции это дорого. В исследовании расширяли офлайн (один раз), но если документы постоянно обновляются — накладно.
⚠️ Не для простых запросов: Если запрос короткий и однозначный ("автор книги Война и мир"), topic-centric expansion избыточен. Работает лучше для многогранных информационных запросов ("риски инвестиций в стартапы на ранних стадиях").
Как исследовали
Команда из University of Massachusetts Boston и Xi'an Jiaotong University проверила TCDE на двух крупных бенчмарках: TREC Deep Learning (веб-поиск) и BEIR (12 датасетов из разных доменов — от научных статей до fact-checking). Сравнивали с сильными baseline: Query2doc (генерация псевдо-документа для запроса), docT5query (генерация запросов для документов через обученную T5), GRF (многогранное расширение запроса), CSQE (retrieval-augmented expansion).
Дизайн: Взяли LLM Qwen-turbo, сгенерировали 5 топиков для каждого запроса (на лету) и 5 тематических предложений для каждого документа (офлайн, заранее). Потом запускали поиск в двух режимах: sparse retrieval (BM25, лексическое совпадение слов) и dense retrieval (E5-Base, векторные эмбеддинги). Измеряли NDCG@10 (насколько релевантные документы в топ-10), MAP и Recall.
Результаты оказались неожиданными: В dense retrieval TCDE выиграла почти везде — 9 из 12 датасетов BEIR показали лучший NDCG@10. Особенно сильно на задачах fact verification (SciFact: +2.8% относительно E5-Base, FEVER: +7.6%). В sparse retrieval картина смешанная: TCDE лучше на 3 из 12 датасетов, но в среднем стабильнее конкурентов.
Почему такие выводы: Topic-centric alignment работает как семантический клей — запрос и документ начинают говорить на одном "языке топиков". Это сильнее влияет на dense retrieval (где важна близость в embedding space), чем на sparse (где всё ещё доминирует точное совпадение слов). Ablation study показала: изолированное расширение запроса (TQE) даёт +8-10% на TREC DL'19, изолированное расширение документов (TDE) даёт +2-3%, но вместе они дают +15-20% — чистый синергетический эффект.
Инсайт для практики: Dual expansion не просто складывает эффекты — она создаёт общее тематическое пространство. Если расширяешь что-то одно, рискуешь semantic drift. Если оба — синхронизируешь. Это объясняет почему TCDE стабильнее: даже на MS MARCO Dev (где модели обучены и так хороши) TCDE падает меньше всех baseline при добавлении шума от expansion.
Адаптации и экстраполяции
🔧 Техника: Асимметричное число топиков → баланс детализации
Необязательно извлекать одинаковое число топиков из запроса и документа. Для сложного запроса с множеством аспектов — возьми 7-10 топиков. Для документа, который заведомо узкий — хватит 3. Или наоборот: короткий запрос (3 топика), а документ длинный (10 топиков). Главное — покрытие, а не симметрия.
Шаг 1: Извлеки 3 ключевых аспекта из моего короткого запроса: "Как оценить product-market fit?"
Шаг 2: Для каждой статьи в подборке извлеки 7-10 тематических предложений.
Шаг 3: Какие статьи покрывают все 3 аспекта моего запроса?
🔧 Техника: Topic-first search → двухступенчатый фильтр
Сначала попроси модель извлечь топики из всех документов (без запроса). Потом сформулируй запрос через топики и ищи пересечения. Это полезно когда не знаешь что именно ищешь — разведочный поиск.
Шаг 1: Вот 20 статей про AI в маркетинге. Извлеки из каждой 5 ключевых топиков.
Шаг 2: Покажи мне кластеры — какие топики повторяются, какие уникальны.
Шаг 3: Теперь мой запрос: "Как AI помогает в персонализации email-рассылок". Какие статьи из 20 покрывают эту тему по топикам?
Ресурсы
TCDE: Topic-Centric Dual Expansion of Queries and Documents with Large Language Models for Information Retrieval
Ping Chen (University of Massachusetts Boston), Yu Yang, Feng Tian (Xi'an Jiaotong University)