Поливекторный поиск, ссылки и контентные эмбеддинги для юридических документов

Исследование показывает, что большие языковые модели плохо справляются с поиском информации в документах, когда пользователь ссылается на раздел по его названию или номеру (например, "статья 69"), а не по содержанию. Для решения этой проблемы авторы предлагают создавать два типа поисковых векторов: один для "метки" (названия) и второй для самого "содержания" (текста).

Ключевой результат: такой двойной подход резко повышает точность поиска по названиям и номерам, не ухудшая при этом качество семантического поиска по смыслу.

Суть метода "Poly-Vector Retrieval" можно объяснить на простой аналогии с библиотекой.

Представьте, что стандартная система поиска в LLM (RAG) — это библиотекарь, который читал все книги, но не помнит их названий и номеров на полках. Если вы спросите его: "Найди мне книгу про смелость и дружбу", он отлично справится. Но если вы скажете: "Дай мне книгу 'Три мушкетера', том 2, глава 5", он растеряется, потому что "том 2, глава 5" для него — просто набор слов, не связанный со смыслом повествования.

Метод Poly-Vector Retrieval добавляет к этому библиотекарю второго сотрудника — каталогизатора. Этот каталогизатор не читал книг, но идеально знает все названия, номера томов, глав и их точное место на полке.

Когда вы задаете вопрос, система обращается сразу к обоим: 1. Запрос по смыслу ("про смелость и дружбу") — отвечает библиотекарь (поиск по эмбеддингу содержания). 2. Запрос по названию ("глава 5") — отвечает каталогизатор (поиск по эмбеддингу метки).

Система объединяет их результаты и выдает вам самую релевантную книгу (текстовый фрагмент). Таким образом, вы можете быть уверены, что модель найдет нужную информацию, как бы вы ее ни назвали — по смыслу или по формальному "адресу". Это делает поиск гораздо более надежным, особенно в юридических, технических и любых других документах с четкой структурой.

*Прямая применимость:Для обычного пользователя, работающего с ChatGPT или Claude, прямая применимость метода равна нулю, так как он не может изменять способ индексации документов. Однако, если пользователь работает с собственным RAG-агентом или платформой, где можно влиять на индексацию, метод становится крайне полезным.

• Концептуальная ценность: Огромная. Главный вывод для пользователя — всегда помогайте модели связать "метку" с "содержанием". LLM не обладает человеческим пониманием, что "Глава 3" и текст этой главы — это одно и то же. Это объясняет, почему запросы вида "Проанализируй раздел 'SWOT-анализ' в загруженном документе" часто проваливаются. Модель ищет семантическую близость к словам "проанализируй раздел свот-анализ", а не к самому тексту SWOT-анализа.

• Потенциал для адаптации: Очень высокий. Пользователь может "симулировать" Poly-Vector Retrieval в своих промптах. Механизм адаптации прост: при формулировке запроса к документу нужно явно предоставить модели и метку (reference), и намек на содержание (sense). Это помогает модели сузить область поиска и найти правильный фрагмент текста.

Предположим, вы загрузили в LLM-чат (поддерживающий работу с файлами) книгу Стивена Кови "7 навыков высокоэффективных людей" и хотите проанализировать один из навыков.

# РОЛЬ

Ты — опытный бизнес-коуч и эксперт по личной эффективности.

# КОНТЕКСТ

Я загрузил книгу Стивена Кови "7 навыков высокоэффективных людей". Я хочу глубоко разобраться в одном из ключевых навыков.

# ЗАДАЧА

Твоя задача — проанализировать **Навык 2: "Начинайте, представляя конечную цель"**. Этот навык связан с личной миссией, видением будущего и самолидерством.

Основываясь на тексте соответствующей главы в книге, выполни следующее:
1. **Суммаризируй** ключевую идею этого навыка в 2-3 предложениях.
2. **Приведи 3 практических шага**, которые автор предлагает для применения этого навыка в повседневной жизни.
3. **Объясни**, почему этот навык является "первым творением" (созданием в уме), предваряющим "второе творение" (физическое создание).

Этот промпт эффективен, потому что он симулирует подход Poly-Vector Retrieval:

1. Явная Метка (Reference): Промпт четко указывает название навыка: Навык 2: "Начинайте, представляя конечную цель". Это прямой указатель, "метка", которая помогает модели точно идентифицировать нужную главу, даже если ее номер или название в тексте файла немного отличаются.

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

3. Структурированный запрос: Дальнейшие пункты заставляют модель искать в найденном фрагменте конкретные детали ("первое творение", "практические шаги"), что дополнительно верифицирует, что был найден правильный текст.

Предположим, менеджер по продукту загрузил в LLM документ "Стратегия развития продукта Q3 2024" и хочет сравнить два раздела.

# РОЛЬ

Ты — старший продакт-менеджер, анализирующий стратегический документ.

# КОНТЕКСТ

Я загрузил документ "Стратегия развития продукта Q3 2024.docx". Документ содержит несколько ключевых разделов, включая "Анализ конкурентов" и "Карта пути клиента (CJM)".

# ЗАДАЧА

Сравни информацию из двух разделов этого документа:
1. **Раздел "Анализ конкурентов"**: выдели 2 основные угрозы со стороны конкурента "Innovate Corp".
2. **Раздел "Карта пути клиента (CJM)"**: найди этап, на котором эти угрозы наиболее сильно влияют на наших пользователей.

В итоге сформулируй краткий вывод: как выявленные угрозы из раздела анализа конкурентов проявляются в опыте пользователя согласно CJM.

Этот пример, как и предыдущий, использует главный принцип исследования для решения более сложной задачи, требующей информации из нескольких мест в документе (аналогично запросу Q8 из статьи, где сравнивались две статьи конституции).

1. Множественные Метки (Multiple References): Промпт предоставляет точные названия двух независимых разделов: "Анализ конкурентов" и "Карта пути клиента (CJM)". Это позволяет модели выполнить два точных "указательных" поиска вместо одного размытого семантического.

2. Снижение когнитивной нагрузки: Без этих точных меток модель должна была бы сама догадаться, где в документе говорится о конкурентах, а где — о пути клиента. Это сложная задача, которая часто приводит к ошибкам. Предоставляя "адреса" нужных данных, мы упрощаем задачу для LLM до простого извлечения и синтеза информации.

Запрос не просто просит найти информацию, а требует ее синтезировать (как угрозы... проявляются в CJM). Это заставляет модель не просто извлечь два фрагмента, а убедиться, что они верны и логически связаны, что повышает общую надежность ответа.

• A. Релевантность техникам промтинга: Да, раскрывает фундаментальную проблему: LLM плохо сопоставляет "название" (например, "Статья 5") с его "содержанием" (текстом статьи). Хотя прямых фраз не даёт, это знание напрямую влияет на то, как нужно формулировать запросы при работе с документами.
• B. Улучшение качества диалоговых ответов: Значительное. Улучшая релевантность извлекаемого контекста (RAG), исследование напрямую ведет к более точным и полным ответам LLM, так как модель получает правильную "шпаргалку".
• C. Прямая практическая применимость: Средняя. Пользователь не может сам реализовать Poly-vector retrieval в ChatGPT. Однако он может симулировать этот подход, явно указывая в промпте и "метку" (название раздела), и краткое описание ожидаемого содержания, чтобы помочь модели найти нужный фрагмент.
• D. Концептуальная ценность: Очень высокая. Исследование дает пользователю ключевую "ментальную модель": для LLM название документа и его содержание — это не одно и то же. Понимание этого объясняет, почему многие запросы к документам проваливаются, и дает интуицию, как их исправить.
• E. Новая полезная практика (кластеризация):
  • Кластер 2 (Поведенческие закономерности LLM): Прямое попадание. Раскрывает, что короткие референциальные запросы (по названию/номеру) плохо работают при семантическом поиске.
  • Кластер 6 (Контекст и память): Прямое попадание. Это исследование фундаментально улучшает стратегии работы с контекстом, особенно в RAG-системах.
  • Кластер 7 (Надежность и стабильность): Прямое попадание. Повышая точность извлечения фактов, метод кардинально снижает риск галлюцинаций.
• Чек-лист практичности (+15 баллов):
  • Дает готовые фразы/конструкции для промптов? (Нет)
  • Объясняет, где в промпте размещать важную информацию? (Косвенно, указывая на важность меток)
  • Показывает, как структурировать сложные запросы? (Да, например, запросы с несколькими метками)
  • Раскрывает неочевидные особенности поведения LLM? (Да, это его главная ценность)
  • Раскрывает эффективные метода суммаризации текста? (Нет)
  • Предлагает способы улучшить consistency/точность ответов? (Да, через улучшение RAG)
  • Итог: ДА на 3 пункта. Применяю бонус +15 баллов.

Изначально исследование заслуживает ~70 баллов за огромную концептуальную ценность и объяснение важной закономерности поведения LLM. С бонусом +15 баллов итоговая оценка составляет 85.

• Аргументы за оценку 85:

  • Фундаментальное знание: Исследование объясняет одну из самых частых причин неудач при работе с документами в LLM. Поняв принцип "метка ≠ содержание", пользователь начинает писать промпты совершенно иначе и получает лучшие результаты.
  • Высокая концептуальная ценность: Аналогия с "Sense" (смысл/содержание) и "Reference" (ссылка/метка) — это мощный инструмент для мышления, который помогает формировать более точные запросы.
  • Прямое влияние на результат: Применение принципов из статьи напрямую снижает галлюцинации и повышает точность ответов при работе с любыми структурированными текстами (договоры, отчеты, книги).

• Контраргументы (почему оценка могла быть ниже/выше):

  • Почему не 90+: Метод Poly-vector retrieval не может быть применен пользователем напрямую. Это бэкенд-технология для разработчиков RAG-систем. Польза для пользователя — непрямая, через адаптацию принципов в своих промптах, что требует дополнительного осмысления.
  • Почему не 60-70: Несмотря на техническую сложность реализации, концептуальный вывод настолько прост, универсален и полезен, что его ценность для продвинутого пользователя перевешивает невозможность прямого применения. Это знание из разряда "must-have" для тех, кто серьезно работает с LLM и документами.