Эмбеддинги — это не магия: предсказуемые режимы отказов при извлечении RAG-данных

Enterprise Document Intelligence [Том 1 #2] Почему тот же векторный поиск, который обрабатывает синонимы и перефразирование, незаметно дает сбой при работе с отрицанием, точными идентификаторами и аббревиатурами вашей компании, и что использовать в таких случаях.

Делиться

Две сцены, обе знакомые.

Сцена 1 : Небольшая команда запускает в работу систему RAG, обрабатывающую несколько сотен страниц нормативных документов.

• Первое, что впечатляет всех: система обрабатывает перефразирование. Кто-то спрашивает: «Как отменить?», в документе ни разу не используется слово «отменить», применяются процедуры прекращения действия, и система всё равно находит нужный фрагмент.
• Другой пользователь задает вопрос на французском, в то время как правила представлены на английском, и возвращается нужная страница. Опечатка здесь, фонетическая орфография там — никаких проблем. Через несколько дней команда была искренне впечатлена. Самое близкое к волшебству, что есть у RAG, находится прямо перед ними, и для этого не потребовалось никаких написанных вручную таблиц синонимов.

Сцена 2 : Та же система, две недели спустя.

• Пользователь спрашивает: «Каковы правила оплаты сверхурочных работ подрядчиков?» Система отвечает: «Я не смог найти эту информацию». Пользователь, который, кстати, является экспертом по бизнесу и написал половину этого руководства, хмурится, открывает PDF-файл, вводит «нештатный персонал» в Ctrl-F и за три секунды находит нужный абзац. Правильное ключевое слово было не «сверхурочные». Это был термин, который действительно используется в документе. Эксперт это знал; встроенная система — нет.
• Довольно быстро появляются новые подобные случаи. Нарушается отрицание. Неправильно указываются точные номера ссылок в контракте. Внутренний код продукта возвращает неверный уровень. Ничего из этого нельзя исправить заменой поставщика встраивания.

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

Классическая топология ранжирует слои по стоимости:

• дешевое сходство встраивания внизу,
• необязательный механизм переранжирования между кодировщиками,
• LLM завершения чата находится сверху.

Ничто из этого не является волшебством; каждый ломается по-своему.

Эта статья является частью более обширной серии «Entreprise Document Intelligence Vol. 1», в которой пошагово выстраивается корпоративная система RAG, начиная с базового конвейера и заканчивая архитектурой масштаба корпуса документов.

1. Что показывают эмбеддинги

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

Эмбеддинг преобразует фрагмент текста в вектор. Тексты со схожими терминами оказываются близко расположенными в векторном пространстве.

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

• GloVe-avg (2014): усредненные 300-мерные векторные представления слов. Без контекстуализации. Сильно смещен в сторону буквального совпадения токенов. Apache 2.0, указано на карточке модели HuggingFace.
• all-MiniLM-L6-v2 (2021): небольшой контекстный кодировщик предложений с открытым исходным кодом, 22 млн параметров, 384-мерный. Apache 2.0, объявлен на карточке модели HuggingFace.
• text-embedding-ada-002 (OpenAI 2022): 1536-dim. Собственность компании; регулируется Условиями использования OpenAI.
• text-embedding-3-large (OpenAI 2024): 3072-dim. Собственность компании; регулируется Условиями использования OpenAI.

Загрузка каждой модели осуществляется одной строкой кода. Две локальные модели получаются из sentence-transformers (веса HuggingFace загружаются на диск при первом вызове); две модели OpenAI обрабатываются через API-клиент. Форма вызова одинакова для всех четырех моделей, возвращая вектор.

 from sentence_transformers import SentenceTransformer from openai import OpenAI # Local models: weights downloaded from HuggingFace, run in-process. glove = SentenceTransformer("average_word_embeddings_glove.6B.300d") # 2014, 300-dim minilm = SentenceTransformer("all-MiniLM-L6-v2") # 2021, 384-dim # OpenAI models: called through the API. client = OpenAI() def openai_embed(text: str, model: str) -> list[float]: return client.embeddings.create(input=text, model=model).data[0].embedding # Same call shape across all four; each returns a vector of its own dimension. v_glove = glove.encode("policy renewal") v_minilm = minilm.encode("policy renewal") v_ada = openai_embed("policy renewal", "text-embedding-ada-002") # 2022, 1536-dim v_large = openai_embed("policy renewal", "text-embedding-3-large") # 2024, 3072-dim

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

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

 def _cos(u, v): """Cosine similarity : dot-product of two vectors, normalised by their lengths.""" return float(np.dot(u, v) / (np.linalg.norm(u) * np.linalg.norm(v))) def compare_models(query, candidates, target=None): qg = glove.encode(query) qm = minilm.encode(query) qa = openai_embed(query, "text-embedding-ada-002") ql = openai_embed(query, "text-embedding-3-large") rows = [] for c in candidates: rows.append({ "candidate": c, "GloVe-avg": _cos(qg, glove.encode(c)), "MiniLM": _cos(qm, minilm.encode(c)), "ada-002": _cos(qa, openai_embed(c, "text-embedding-ada-002")), "3-large": _cos(ql, openai_embed(c, "text-embedding-3-large")), }) return pd.DataFrame(rows).set_index("candidate")

1.1 Концептуальная близость

Слово car соответствует фрагментам текста, содержащим vehicles , automobiles , motor vehicles . Слово fire damage находит фрагменты текста, описывающие smoke damage и scorching . Слово manager approval соответствует предложению об executive approval . Модель улавливает семантическое поле, а не только поверхностные слова. Именно это делает векторные представления эффективными: пользователю не нужно угадывать лексику документа; векторное представление заполняет остальной текст.

1.2 Синонимы и перефразирование

Phone number соответствует telephone . Policy cancellation соответствует разделу под названием « termination procedures . Fee соответствует charge . Monthly cost соответствует premium . Expiration соответствует policy end date . Doctor соответствует physician , lawyer соответствует attorney , car соответствует vehicle . Одиночные слова и многословные составные слова. Модель научилась различать два слова, выражающие одно и то же, включая разницу между неформальными фразами пользователей и формальным языком, на котором написаны документы. Никто не кодировал это сопоставление вручную.

Тест: запросите what is the monthly fee сопоставив ее с синонимом TARGET ( A flat charge of $9.99... ), подсказкой с буквальным совпадением ( Premium payments are due monthly... , которая имеет тот же буквальный monthly токен) и двумя подсказками, не относящимися к теме.

Только GloVe-avg попадает в ловушку буквального перекрытия. Обучение кодировщика предложений (уже в MiniLM 2021 года) обеспечивает реальную обработку синонимов. Без неё побеждает кандидат, просто повторяющий токены запроса в любом порядке. С ней модель связывает fee ↔︎ charge даже если эти два слова не имеют общих букв. Запрос также сформулирован как вопрос ( what is the monthly fee ), а TARGET — как утверждение ( A flat charge of $9.99... ). Здесь побеждает обработка синонимов. Но фактический ответ (само число $9.99 США или Yes для вопроса «да/нет») не обязательно победил бы независимо от силы модели. Раздел 2.2 демонстрирует это напрямую.

1.3 Опечатки и орфографические ошибки

insurence по-прежнему отображается рядом со insurance . polciy по-прежнему находит раздел полиса. Слово «франшиза» с неправильной гласной по- deductable попадает на страницу, посвященную франшизе. Диакритические знаки, опущенные во французских терминах (например, resiliation без ударения), по-прежнему соответствуют канонической форме. Современные модели встраивания были обучены на наборе текста, собранном с веб-сайтов, где эти опечатки встречаются постоянно, и они научились поглощать этот шум.

Смотрите на разницу в баллах, а не на абсолютные значения. GloVe-avg не учитывает опечатки. Токены с ошибками выходят за пределы словаря, поэтому эмбеддинги разрушаются, а косинусы становятся отрицательными. Порядок, по сути, случаен. Модели OpenAI без проблем обрабатывают опечатки. Устойчивость на уровне символов реальна и масштабируется с мощностью модели.

1.4 Межъязыковое сопоставление

Многоязычные векторные представления размещают premium , prime и Prämie в близлежащих областях пространства. То же самое относится к deductible / franchise / Selbstbeteiligung , для claim / sinistre / Schadensfall . Французское ключевое слово выдает англоязычный фрагмент, посвященный той же концепции. Для предприятий со смешанными языковыми корпусами (французские контракты, английская переписка, немецкие страховые полисы) это действительно полезно, когда работает, а в современных моделях это обычно так и есть.

GloVe терпит полное фиаско : он выбирает Coverage limit: $50,000 per year. вместо Annual premium: $1,200. потому что французское annuelle лексически ассоциируется с year в его усредненном словарном пространстве, и он не знает, что prime означает premium . MiniLM технически выбирает TARGET, но косинусы находятся около 0,12, что по сути является шумом. ada-002 и 3-large являются многоязычными по обучению, как BGE-M3 и multilingual-e5, и они чисто связывают французский и английский языки. Выбор не в смысле «вектор против ключевого слова», а в смысле «многоязычная векторная модель против модели, работающей только на английском языке».

1.5 Сложная полисемия

Многозначные слова имеют несколько значений, которые уточняются контекстом:

• bank (финансовое учреждение / берег реки),
• claim (страховое событие / заявление),
• store (глагол: убрать / существительное: торговая точка),
• green card (иммиграционный документ / карта зеленого цвета),
• hot dog (горячая еда / горячая собака).

Когда кандидат использует буквальное значение слова в неправильном смысле, сильное векторное представление всё равно должно выбрать семантически правильное. Именно здесь наиболее ярко проявляется смещение в сторону буквального значения токенов в слабых моделях: GloVe-avg не может различить два прочтения составного слова и выбирает того кандидата, который имеет больше всего общих токенов с запросом. Кодировщики предложений постепенно восстанавливают правильное значение, но насколько постепенно — зависит от того, насколько известно составное слово в обучающих данных.

Мы тестируем два соединения: сначала простое, затем сложное.

Во-первых, green card — простой случай. Значение слова «иммиграция» настолько часто встречается в учебных корпусах (новости, юридические тексты, Википедия), что даже MiniLM решает эту сложную задачу. Тест: запрос green card , три варианта. Перефразирование иммиграционного документа (ЦЕЛЬ, ноль общих токенов), предложение в игровом контексте, содержащее слова green и card в буквальном смысле (ловушка), и один отвлекающий пример, не относящийся к теме.

Только GloVe попадает в эту ловушку. Модели усреднения слов не имеют представления о том, что «зеленая карта» как составное слово относится к иммиграции. Они видят два токена, ищут кандидатов, имеющих такие же токены, и ловушка с игрой побеждает. MiniLM уже достаточно, чтобы перевернуть ситуацию, потому что обучение на уровне предложений улавливает институциональный смысл. ada-002 выбирает TARGET с комфортным отрывом; 3-large — с большим отрывом. Это тот тип многозначных эмбеддингов, с которым хорошо справляются, потому что общедоступный интернет обучает этому составному слову повсюду.

Теперь hot dog , сложный случай. Та же структурная основа (сложное слово, которое читается и буквально), но буквальное прочтение (собака, которой жарко) также широко распространено в обучающих текстах. Модель видела множество предложений о жаркой погоде и собаках в ней. Смысл, связанный с едой, и буквальное прочтение конкурируют практически на равных, и склонность к буквальному прочтению, характерная для слабых и средних моделей, побеждает.

В первом разделе градиент модели играет наибольшую роль. GloVe-avg, MiniLM и ada-002 попадают в эту ловушку. Они цепляются за общие токены hot — dog , несмотря на неправильное значение. Тот же эффект уже наблюдался на GloVe в разделе 1.2 (буквальный monthly токен превосходит синоним fee ↔︎ charge ). Наихудший случай — сложная полисемия: буквальные токены запроса появляются в приманке, поэтому даже ada-002 не может различить два значения. 3-large — первая модель, которая восстанавливается : она с большим отрывом выбирает парафразу про еду, хотя TARGET не имеет общих токенов с запросом.

Таким образом, практический вопрос для вашего корпуса заключается не в том, «есть ли полисемия», а в том, «насколько институциональной является имеющаяся у меня полисемия». В корпусе, посвященном страхованию, много составной полисемии, которая отсутствует в общедоступных обучающих материалах ( claim handling как глагол в рабочем процессе, pool как инструмент распределения рисков). В таких случаях даже ada-002 ведет себя так же, как GloVe ведет себя с хот-догом. Модель 2024-го класса — это реалистичное решение; остальная часть серии посвящена структурному решению.

1.6 Что на самом деле показывают и чего не показывают эти победы

Словарь в этом разделе объединяет одно: он общедоступный. Модель обнаружила выражения green card ↔︎ permanent resident card , prime ↔︎ premium , polciy → policy в миллионах обучающих документов. Эмбеддинги хорошо справляются с ними, поскольку эквивалентность заложена в весах. Большую часть работы выполняет то, что в литературе называют параметрической памятью модели (часть, которая «знает» вещи из обучения без какого-либо извлечения).

Прежде чем двигаться дальше, стоит упомянуть два последствия.

1. В этих случаях RAG может вообще не понадобиться. Спросите GPT-4: «Как еще называется зеленая карта?» — и вы получите ответ без необходимости повторного поиска. Параметрическая часть модели уже знает ответ. RAG находит свое место именно там, где параметрическая часть его не находит: факты, которых нет в открытом доступе в интернете, пункты контракта, которые не являются обобщаемыми, внутренние коды продуктов, которые модель никогда не видела. В разделе 1 использовалась хорошо известная лексика, поэтому демонстрационные примеры воспроизводимы и понятны. В производственной среде RAG для ответа на эти вопросы не используется.

2. Преимущества раздела 1 не переносятся на корпоративную терминологию. У страховой компании есть ShieldPro Elite (уровень продукта), pool (инструмент распределения рисков, а не плавательный бассейн), non-employee labor (термин в контракте для contractor ), ссылки на нормативные акты, такие как Solvency II Article 7 . Ничего из этого не входит в обучающую программу модели. С точки зрения предприятия, эмбеддинги терпят неудачу так же, как GloVe терпит неудачу в случае с hot dog , потому что институциональный смысл, необходимый для восстановления эмбеддинга, нигде за пределами этой компании не закреплен.

Решение заключается не в создании более крупной модели встраивания. Решение заключается в эксперте, знающем словарь , кодифицированный в виде словаря ключевых слов (это подробно описано в разделе 3.3). В разделе 2.1 ошибка рассматривается на конкретном примере pool .

В разделе 2 перечислены структурные недостатки. Читайте их, помня о следующем: каждый из них является правилом, а не исключением, в корпоративных корпорациях.

2. Где они ломаются и почему.

Возможности, описанные в разделе 1, реальны; описанные ниже ошибки столь же реальны, столь же воспроизводимы и сохраняются во всех четырех моделях. Увеличение размера модели не меняет рейтинг. Решение носит архитектурный характер, а не заключается в «выборе более сильного векторного представления».

В разделе 1.6 уже был выдвинут очевидный контраргумент («в таких случаях просто обратитесь напрямую к LLM»). В масштабах корпуса это не масштабируется: корпус из 200 000 документов не может быть обработан LLM при каждом запросе. Сначала должен быть какой-то этап поиска. В основном конвейере между эмбеддингами и LLM используется алгоритм переранжирования; в этой серии статей предлагается фильтрация на этапе экспертной обработки ключевых слов и структуры документа (статьи 6, 7, 9). В любом случае, описанные ниже ошибки относятся к этапу эмбеддинга. Ни один из этих уровней не является волшебным.

2.1 Простейший способ: термин отсутствует в модели.

Перед структурными повреждениями — самое основное. В разделе 1.6 это описано словами. Вот демонстрация.

Возьмем, к примеру, слово pool . В страховом договоре pool — это инструмент разделения рисков: группа застрахованных лиц, которые коллективно поглощают убытки за счет суммарных страховых премий. В общем английском языке pool — это водоем, в котором вы плаваете. Два значения одного и того же слова, с одним существенным различием: значение «плавание» встречается повсюду в открытом доступе в интернете; значение «пул рисков» затеряно в учебниках по актуарной науке, нормативных документах и договорах перестрахования, с которыми модель едва ли сталкивалась во время обучения.

Тест повторяет схему с хот-догом из раздела 1.5, с одним нюансом. Запросите само слово pool . Три варианта: перефразирование слова «плавание» (общепринятое значение, без упоминания слова pool ), перефразирование слова «перестрахование» с использованием реального отраслевого жаргона (специализированное значение, также без упоминания слова pool ») и случайное контрольное предложение об отправлении поезда (без упоминания слова pool , без связи со страхованием, без упоминания слова «плавание»).

Перефразирование процесса плавания выигрывает во всех моделях с большим отрывом (от 0,353 до 0,843 косинуса, в зависимости от модели). Перефразирование процесса перестрахования, написанное на языке, соответствующем отраслевой терминологии, уступает случайному управлению отправлением поездов в трех из четырех моделей . Даже ada-002, основной инструмент большинства корпоративных систем RAG, опережает специализированное предложение на 0,010. Только 3-large дает специализированному варианту прирост на 0,006 по сравнению с контрольным вариантом, что находится в пределах шума измерения.

Это наиболее прямой из возможных причин сбоя: пространство вложений просто не кодирует специализированное значение слова pool . Добавление алгоритма переранжирования сверху не поможет, потому что оценки кандидатов, которые он будет переоценивать, сами по себе являются шумом. Более крупная модель вложений также не поможет, потому что модель, которая видела бассейн миллион раз, а пул перестрахования, возможно, сто раз, будет продолжать придавать вес значению слова «плавание».

pool на самом деле является мягким случаем, когда один из слов не совпадает с другим: смысл плавания и смысл риска используют один регистр, а «3-large» улавливает какой-то сигнал. Более сложные случаи — это строгие термины, которые не совпадают с другими словами: ShieldPro Elite (вымышленный уровень продукта), Solvency II Article 7 (реальная нормативная ссылка), ZRX-2025 (внутренний код продукта). Для них встраивание вообще не имеет привязки. Модель рассматривает их как случайные байтовые строки; ранжирование их по сравнению с любым другим текстом — это подбрасывание монеты, смещенное в сторону особенностей токенизации.

Решение заключается в привлечении эксперта, знающего терминологию , кодифицированную в виде словаря ключевых слов. В разделе 3.3 описан рабочий процесс.

В оставшейся части раздела 2 рассматриваются структурные повреждения, которые проявляются даже тогда, когда соответствующий термин присутствует в модели. В случае с бассейном рассматривается более простая поломка, которая возникает первой.

2.2 Структурный разрыв: сходство терминов, а не релевантность ответа.

В разделе 2.1 рассматривался случай, когда термин просто отсутствует в модели. Остальная часть раздела 2 посвящена случаю, когда термин присутствует в модели, но векторное представление всё равно даёт неверный ответ. Эти ошибки имеют одну общую структурную причину. Векторное представление анализирует текст и ранжирует его по сходству терминов. Оно совершенно не отражает связь «вопрос-ответ». Два самых простых запроса, которые можно задать, наглядно это демонстрируют. Это не корпоративные крайние случаи, это самые общие вопросы в мире.

«Да» — правильный ответ на вопрос типа «да/нет». Он никогда не побеждает. Побеждает буквальное значение существительного в вопросе. Так было со всеми моделями с 2014 по 2024 год.

Тонкость, заслуживающая упоминания. Эта конкретная ошибка на практике менее вредна, чем кажется. Для вопроса типа «да/нет» нам на самом деле нужно не буквальное слово «да». Нам нужны доказательства по теме: страница, где находится правило. На этапе ответа LLM выдает «да/нет» на основе этих доказательств. Поэтому Termination may be required. поиск с использованием Termination или «Завершение» (тематические совпадения), а не Yes, it is possible. Это ближе к правильному поведению, чем предполагает вывод демонстрации. Принцип, который постоянно всплывает в статье, применим и здесь: этап поиска — это не этап ответа, и их необходимо разделить и оптимизировать как два отдельных шага. Разделение рассматривается в статьях 6, 7 и 8.

Ошибка особенно заметна в следующем примере, где для поиска необходимо найти нить, содержащую ответ.

А теперь самый понятный факт в мире: «Какова столица Франции?» В интернете миллионы раз встречался вопрос «Париж — столица Франции». Если бы сопоставление вопросов и ответов появилось где угодно и в любом пространстве встраивания, оно бы появилось именно здесь.

Париж никогда не занимает первое место. В трех из четырех моделей (GloVe, ada-002, 3-large) победителем становится Capital of Italy , кандидат, который имеет в запросе буквальное значение фразы Capital of . В MiniLM побеждает другая приманка: France is in Europe. , потому что она имеет токен France . Разные приманки, одна и та же первопричина: сходство тем, а не релевантность ответа. Переход от 300-мерной модели 2014 года с векторным представлением «мешка слов» к 3072-мерной модели OpenAI 2024 года не меняет ситуацию. Для фактоидного вопроса поиск должен извлекать строку, содержащую ответ. Вместо этого каждая модель выбирает строку, которая соответствует тематике запроса.

Второй нюанс, заслуживающий упоминания. Современные модели встраивания обучаются на парах «вопрос-текст» (MS MARCO, Natural Questions, BEIR). Это действительно немного приближает содержащие ответы тексты к вопросам, на которые они отвечают. Предвзятость существует. Она слабая. В случае очень общих фактов она иногда меняет решение. В случае специализированной лексики, с которой модель никогда не сталкивалась во время обучения (внутренние коды продуктов, экспертная терминология, договорная терминология), предвзятость исчезает. Сходство тем снова становится доминирующим.

В разделах ниже эта первопричина описана в четырех конкретных формах отказа (отрицание, величина, близость к теме, ослабление сигнала), а также рассмотрены очевидные случаи. В каждом случае один и тот же механизм применяется к различному типу запроса.

2.3 Отрицание

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

Вопрос: «Что НЕ является городом?» Четыре варианта: три из них — реальные объекты (два конкретных города + само слово « City »), и один — Table , обыденный предмет, который, по совпадению, является единственным вариантом, правильно отвечающим на вопрос.

Все модели терпят неудачу одинаково. Кандидаты, соответствующие теме ( City , Paris , New York ), находятся на вершине, а Table , единственный кандидат, который действительно отвечает на вопрос, оказывается последним. Слово запроса NOT практически не несет никакого сигнала в пространстве эмбеддингов: эмбеддинг видит набор, содержащий «город», и ранжирует все, что связано с городом, выше всего, что не связано с ним. Решение заключается не в создании более сильной модели эмбеддингов. Это шаг, который обнаруживает отрицание во время синтаксического анализа вопроса и инвертирует процесс поиска (статья 6).

«Конечно, но ни один реальный пользователь не пишет запрос на отрицание». Разумное возражение, которое срабатывает на мгновение, а затем перестаёт работать в реальных условиях. Пользователи не задают вопрос: «Что НЕ является городом?». Они задают вопрос: «Какова сумма страховой премии по этому полису?». Система по ошибке возвращает сумму франшизы . Разочарованный пользователь, естественно, пытается исправить: «Мне нужна сумма страховой премии, а не франшиза». Этот второй запрос — это запрос на отрицание, и именно в этот момент реальный корпоративный пользователь его и пишет.

Интуиция вполне разумна: человек воспринимает «не» как исключение. Встраивание делает обратное. Добавляя к запросу deductible , даже с префиксом not , встраивание приближает строки, содержащие вычет, к исходному запросу, а не отдаляет от него. Исправление пользователя делает ошибку значительно хуже, чем исходный запрос.

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

2.4 Величины и пороговые значения

Числовые сравнения, даты, суммы контрактов, остатки на счетах. Все, где ответ зависит от самого значения. Рассмотрим упрощенный вариант: запрос find value greater than 1M , четыре варианта, представляющие собой просто суммы.

Каждая модель выбирает 1M — кандидата, который равен пороговому значению, но не строго его превышает. Победа достигается за счет чисто лексического соответствия: буквальный токен 1M находится в запросе. 3B , единственный кандидат, который действительно отвечает на вопрос, занимает 4-е место (последнее) как в ada-002, так и в 3-large. В эмбеддинге отсутствует понятие величины. Он видит 1M рядом с 1M , и тот побеждает.

Это применимо к любому вопросу сравнения значений или пороговым значениям: денежным порогам, датам («после 2020 года»), продолжительности («более 30 дней»), количеству. Эмбеддинги плохо справляются с этим практически по своей природе: они сжимают смысл в плотные векторы, и именно дискриминирующий сигнал (само значение или оператор, выбирающий значения) разрушается в результате сжатия. Решение хорошо известно: BM25 / полнотекстовое индексирование для лексического совпадения, плюс этап анализа вопроса, который извлекает оператор и пороговое значение в виде структурированных полей (статья 6), чтобы последующий фильтр мог выполнить сравнение.

2.5 Тематическая близость против релевантности ответа

Вопрос пользователя: «Кто подписал контракт?» В корпусе есть один отрывок, описывающий порядок подписания контрактов (уполномоченный представитель, требования к подписи), и один отрывок с самой подписью («Подписано: Джон Смит, директор по маркетингу, от 15.03.2025»). Первый отрывок рассказывает о подписании; второй — о самой подписи. Какой из них лучше?

Это структурный недостаток, который градиент модели не исправляет. Сходство встраивания измеряет тематическую близость, а не связь вопроса и ответа. Страница, которая обсуждает тему, часто получает более высокий балл, чем страница, которая отвечает на вопрос по этой теме. Определения оцениваются выше, чем значения. Разделы с вводной информацией оцениваются выше, чем выводы. Процедуры оцениваются выше, чем конкретные примеры, которые они описывают.

Три из четырех моделей подтверждают эту закономерность (GloVe, ada-002, 3-large). Исключением является MiniLM: в ее обучении на парах предложений количество конкретных ответов немного превышает количество формулировок, содержащих процедурные детали. Закономерность стабильна на остальных трех моделях и воспроизводится для большинства пар «фактоид против процедуры», которые мы тестировали.

2.6. Разбавление сигнала в длинном контексте

В предыдущих тестах использовались кандидаты, приблизительно равные по длине запросу. Реальные страницы корпуса — нет. Реальная страница содержит 300-500 слов, насыщенных деталями, а ответ на конкретный вопрос спрятан где-то в середине одного предложения. Когда вы встраиваете всю страницу в виде единого вектора, сигнал этой одной строки с ответом усредняется со всем остальным, и векторное представление на уровне страницы смещается к центру окружающего шума.

Наиболее наглядный способ это продемонстрировать — провести эксперимент с одной переменной. Оставьте предложение с ответом неизменным. Добавьте к нему всё большее количество несвязанных с офисной жизнью предложений (рабочее время, правила парковки, стандартные фразы отдела кадров, ничего о франшизах или повреждении водой). Сравните результаты с контрольным вариантом, который не имеет общего с запросом термина, а просто относится к той же широкой лексике страхования/урегулирования претензий.

• Запрос: deductible for water damage claims
• Ответ (различный): For water damage claims, the standard deductible is $500. (с префиксом N ∈ {0, 1, 2, 4, 8, 16} несвязанных предложений)
• Контрольная группа (постоянная для всего N): Claims must include photographs, repair estimates, and police reports where applicable.

Каждая модель терпит неудачу в своё время, но все они терпят неудачу. GloVe рушится мгновенно, потому что усреднение по мешку слов смещает векторное представление в сторону шума после одного предложения. MiniLM продерживается четыре предложения, прежде чем его представление, созданное с помощью кодировщика предложений, сдаётся. ada-002 и 3-large, обе модели OpenAI 2022+, обученные на парах вопрос-текст, работают дольше всего, но к тому моменту, когда число кандидатов достигает 144 слов (восемь несвязанных предложений), правильный ответ оказывается ниже кандидата, который вообще не содержит слов deductible , water или damage . Встраивание страницы объёмом 300 слов — это производственная версия «ответ + 16 шумовых предложений».

Вот почему в производственных конвейерах, которые встраивают информацию на уровне страницы, часто пропускается нужная страница, даже если ответ действительно находится на ней. В среднем, вектор страницы содержит 300-500 слов тематического шума вокруг одной или двух строк, содержащих ответ. Раздел 3.1 предлагает архитектурное решение: встраивайте информацию построчно , а не постранично. Агрегируйте информацию до уровня страницы только тогда, когда для генерации необходим окружающий контекст. Правильная строка на зашумленной странице снова становится доступной, потому что ее встраивание не усредняется со всем остальным.

2.7 Очевидные случаи (демонстрация не требуется)

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

• Идентификаторы OOV и внутренний жаргон : ссылки на контракты ( Section 4.2.1 ), ссылки на нормативные акты ( GDPR Art. 17.3 ), номера счетов-фактур, идентификаторы заявок, внутренние названия продуктов ( ShieldPro Elite , SAP-MRP , KPI-Q4-V3 ). Встраивание обрабатывает их как непрозрачные последовательности и не может ранжировать их семантически. Решение: BM25 или индекс точного совпадения для поиска, а также глоссарий, сопоставляющий псевдонимы с каноническими терминами ( ShieldPro Elite → план высшего уровня для домовладельцев), поддерживаемый в качестве экспертных ключевых слов (статья 6).
• Логическая композиция : «документы проверены Алисой , но не Бобом», «претензии с возмещением ущерба и показаниями свидетелей». Метод усреднения «мешка слов» удаляет логические операторы. Исправление: разбить вопрос на структурированный фильтр (статья 6) и применить его после извлечения данных.
• Подсчет и агрегация : «Сколько контрактов подписала Алиса?», «Перечислите все открытые претензии». Эмбеддинги возвращают один наиболее похожий фрагмент текста; для подсчета требуется полное сканирование или SQL-запрос по индексу. Решение: направить эти запросы в конвейер агрегации (статьи 15-20).
• Временные предикаты : « последняя версия», «заявки, поданные после 2020 года », «полисы, срок действия которых истекает до декабря». Эмбеддинги не отражают временной порядок. Исправление: извлечь временной фильтр во время анализа вопроса и применить его в качестве фильтра метаданных к индексу.
• Многошаговое рассуждение : «Кто является менеджером человека, подписавшего контракт X?» Каждый шаг — это отдельный запрос; встраивание дает вам только одну попытку. Решение: агентная цепочка или обход графа по правильно индексированному корпусу.

Закономерность устойчива. Когда встраивание явно не удается, ответ редко сводится к «купить более крупную модель встраивания». Чаще всего говорят: «перенесите запрос из области встраивания в подходящий инструмент».

2.8 Аналогичные трещины в масштабе страницы (реальный документ)

Четыре описанные выше ошибки были продемонстрированы на рукописных документах. Они проявляются идентично при постраничном поиске в реальном документе. Мы встроили каждую страницу книги «Внимание — это все, что вам нужно» (Vaswani et al. 2017; лицензия на неисключительное распространение arXiv, указанная на странице аннотации arXiv; 15 страниц) и задали три вопроса; каждый из них выявил различную патологию ранжирования на уровне отдельных страниц.

Что показывает каждый результат.

• Q1, едва побеждает. Три страницы отличаются друг от друга всего на 0,01; правильная страница (страница 7, где находится формула скорости обучения Адама) побеждает с разницей в 0,007. Это результат удачи, а не точности поиска. Вариант раздела 2.5 (тематическая близость), усугубленный общей нестабильностью ранжирования.
• В вопросе 2, вариант «топ-3» нас спасает. Страница 8 важнее страницы 9, но ответ (таблица 3, строка d_k абляции) находится на странице 9. Варианта «топ-3» достаточно; вариант «топ-1» бы просто не сработал. По сути, то же самое, что и в разделе 2.4 (точные значения в числовой таблице).
• Вопрос 3, полный провал. Страница с ответами (страница 8, ε_ls = 0.1 ) полностью выпадает из тройки лучших. Вместо неё попадает страница 15 (с примерами предложений, полными символов ε в формулах). Это пример срабатывания раздела 1.5 (сложная многозначность) на ε : векторное представление не может различить ε оптимизатора Adam (страница 7), ε_ls сглаживания меток (страница 8) и ε несвязанных формул (страница 15).

Те же категории ошибок, масштабированные до реального документа. Решение то же самое, что и в разделе 3.

3. Как ими пользоваться на практике

В разделе 1 были показаны преимущества эмбеддингов. В разделе 2 были показаны недостатки, имеющие две различные причины: когда термин просто отсутствует в модели (раздел 2.1) и когда термин присутствует в модели, но сходство терминов не отвечает на вопрос о релевантности (разделы 2.2 и далее). Естественно возникает следующий вопрос: учитывая это, как мы можем использовать их на практике?

Четыре раздела. Раздел 3.1 : правильная ментальная модель (построчный поиск с учетом синонимов). Раздел 3.2 : прием, который преодолевает разрыв между вопросом и ответом, на самом деле не связан с векторными представлениями, а с извлечением ключевых слов, которые содержал бы ответ. Раздел 3.3 : производственный рабочий процесс, который обеспечивает работу обоих подходов: обнаружение словарного запаса корпуса с помощью экспертов, кодификация его в словарь ключевых слов, а затем выполнение целевого поиска. Раздел 3.4 : частный случай корпусов с большим количеством сентиментальной информации (отзывы HR-специалистов, опросы клиентов, заявки в службу поддержки), где тот же механизм обнаружения применяется к эмоциональной лексике.

3.1 Переформулировка: поиск с использованием синонимов на уровне строки

Простейший способ понять, что такое векторные представления: векторный поиск — это поиск по ключевым словам, который обрабатывает синонимы, опечатки и другие языковые конструкции, применяемый построчно . Это не магия. Это не «семантическое понимание на уровне страницы». В одной строке модель рассматривает слова «отмена» и «завершение» как «закрытие». Она воспринимает слово «политика» как «политика». Она связывает «премиум» и «премиум» между языками. Все совпадения, которые работали в разделе 1, работали именно по этой причине.

Когда вы встраиваете целую страницу в один вектор (это было показано непосредственно в разделе 2.6), сигнал одной удачной строки усредняется с остальными, и правильная строка скрывается внутри страницы, которая в основном посвящена другим темам. Поэтому встраивайте построчно. Объединяйте данные до уровня страницы только тогда, когда для генерации необходим окружающий контекст.

Встраивание на уровне страницы по-прежнему оправдано в нескольких случаях: когда ни одна строка не содержит ключевого слова (страница посвящена автострахованию, но эта фраза нигде не используется), когда тема подразумевается окружающей лексикой (медицинская страница упоминает A1C / инсулин / уровень сахара в крови, но никогда не упоминает диабет), когда важен стиль или регистр, когда заголовок является общим («Примечания», «Раздел 5»). За пределами этих случаев построчное встраивание почти всегда выигрывает.

Приведенная ниже демонстрация наглядно показывает работу на реальном документе. В предыдущих разделах были представлены короткие рукописные варианты. Здесь мы вставляем каждую строку статьи «Внимание — это все, что вам нужно» (15 страниц, ~1000 строк) и выполняем поиск по короткому ключевому слову. K лучших результатов — это строки с указанием номера страницы и строки. Вы можете прочитать каждое совпадение и понять, почему оно совпало: ключевое слово или понятный пересказ находятся прямо в тексте.

Пять операций поверх pandas и numpy: кодирование запроса, объединение линейных векторных представлений в матрицу, пакетное вычисление косинуса в одном умножении матрицы, сортировка по сходству, возврат k лучших результатов. Никакой векторной базы данных, никакого фреймворка, никакой инфраструктуры. «Векторное хранилище» представляет собой столбец DataFrame плюс скалярное произведение numpy.

 def top_lines_for(question: str, line_df: pd.DataFrame, k: int = 10) -> pd.DataFrame: """Rank every line by cosine similarity to `question`. Return the top-k.""" q_vec = get_embedding(question, client=client) line_matrix = np.vstack(line_df["embedding"].values) sims = line_matrix @ q_vec / ( np.linalg.norm(line_matrix, axis=1) * np.linalg.norm(q_vec) ) return ( line_df.assign(similarity=sims) .nlargest(k, "similarity")[["page_num", "line_num", "similarity", "text"]] .reset_index(drop=True) ) 

Два момента, которые следует усвоить из демонстрации на линейном уровне.

1. Совпадающие строки буквально показывают, почему каждая из них совпала. Никакой магии, никакой непрозрачности ранжирования. Каждый результат сверху содержит либо ключевое слово якоря, либо его четкую перефразировку. Это построчное встраивание в одну фразу: нечеткий, допускающий синонимы поиск по всему документу Ctrl-F .

2. Совпадающая строка — это якорь, а не фрагмент текста, который вы отправляете в систему генерации. Строка — это небольшой фрагмент, который система поиска может уверенно найти. Фрагмент текста, отправляемый в LLM, обычно больше: окружающий абзац, раздел, иногда вся страница. В статье 7 это описывается как двухэтапная схема: сначала обнаружение якорей (на уровне строки, на уровне ключевых слов, на уровне структуры), затем выбор фрагмента текста вокруг каждого якоря в зависимости от того, что требуется в вопросе. Целевой поиск = небольшой N вокруг четкого якоря , а не 30 размытых страниц, отправленных в LLM.

3.2 HyDE: ищите то, что будет содержать ответ, а не сам вопрос.

В разделе 2.2 было показано, что эмбеддинги не видят вопросов; они видят сходство терминов. Естественная реакция: перестать передавать вопрос в рекрутер. Вместо этого передать ему текст, похожий на ответ . В этом и заключается идея HyDE (Hypothetical Document Embeddings). Напишите (или попросите магистра права написать) предложение, которое правдоподобно отвечает на вопрос, используя лексику, которая используется в документе, и встройте его . Рекрутер сравнивает вектор гипотетического ответа с корпусом.

Главная мысль, которую все отмечают о HyDE, — это сторона встраивания: «переписанный запрос попадает в область, окружающую документ, а не пользователя». Это правда, и это помогает. Но настоящая ценность HyDE, особенно в корпоративном контексте, заключается в другом уровне. Написание гипотетического ответа также является этапом извлечения: оно выявляет ключевые слова, которые мог бы содержать ответ. «Процедуры расторжения», «права на расторжение договора», «плата за аннулирование». Это слова, которые служат ориентиром для поиска, независимо от того, основан ли поиск на векторах или на ключевых словах.

Почему HyDE сработал в данном случае и что именно его использовало. Исходный запрос содержит cancel . Целевая строка содержит rescission и terminate . Ноль общих токенов контента. Три лексических отвлекающих элемента в пуле кандидатов повторяют cancel / cancellation несколько раз, и вместе они опускают формальный целевой запрос на 4-е место. Переписанный с помощью HyDE ответ представляет собой вымышленный ответ, который случайно содержит rescission , terminate , written notice , renewal — именно ту лексику, которую использует целевой запрос. Как только эти токены попадают в сторону запроса, рейтинг меняется, и целевой запрос поднимается на 1-е место.

Доминирующим фактором являются ключевые слова, содержащиеся в переписанном тексте. Соответствие регистру (формальный декларативный тон переписанного текста, совпадающий с регистром документа) и скрытые семантические ассоциации, полученные в ходе обучения LLM, вносят меньший вклад в виде вторичных эффектов (статья 6 подробно их анализирует); в корпусах с ограниченным словарём корпоративных слов они не влияют на результат. Если выполнить поиск по ключевым словам в наборе терминов {rescission, terminate, written notice, renewal} , вы получите тот же целевой результат без какой-либо обработки векторов.

HyDE — это неявное расширение ключевых слов, осуществляемое через этап встраивания. LLM генерирует полный гипотетический ответ, система встраивает его, а ретривер применяет косинусный анализ к корпусу. Вся эта работа направлена на добавление нескольких ключевых слов в запрос. Два более простых пути обеспечивают такое же явное расширение словарного запаса:

1. Запросите ключевые слова непосредственно у преподавателя магистратуры. Один вопрос: «Какие термины содержал бы ответ на этот вопрос в типичном страховом договоре?» Результат: rescission, terminate, written notice, renewal . Используйте их в поиске по ключевым словам. Никаких вымышленных документов, никаких вложений, никаких косинусов.
2. Пусть эксперт подскажет вам словарь. Юристы, специалисты по урегулированию претензий, сотрудники отделов по соблюдению нормативных требований уже знают, что в пользовательской терминологии cancellation » означает rescission договора». Кодификация этого соответствия один раз — это надежный способ его применения; просить магистра права заново находить его при каждом запросе — это расточительно.

Оба пути превосходят конвейер HyDE по трем параметрам. Проверяемость : найденные ключевые слова видны команде и регулирующему органу; показатель косинуса 0.83 — нет. Задержка : один вызов LLM, отсутствие обмена данными между встраиванием для каждого запроса. Долговечность : ключевые слова сохраняются в словаре, его можно использовать повторно в разных запросах; HyDE каждый раз генерирует гипотезу с нуля. Статья 6 (Анализующий анализ вопросов) формализует это как явный экспертный словарь ключевых слов , который растет вместе с корпусом.

Потребительский рынок против корпоративного. В случае с корпусами, ориентированными на потребительский рынок (часто задаваемые вопросы по общему страхованию, справка по электронной коммерции, формы для государственных служб), специалист по юриспруденции (LLM) уже видел множество обучающих текстов в нужном стиле, поэтому его предположение о ключевых словах обычно достаточно точное. HyDE работает без участия эксперта. В случае с корпоративными корпусами (внутренние коды продуктов, ссылки на нормативные документы, договорная терминология, пользовательские акронимы) LLM использует общие юридические формулировки («…будет изложено в условиях и положениях…») и упускает из виду фактическую лексику документа. Эксперт уже знает эту лексику. Просить LLM угадывать, что эксперт может вам предоставить по каждому отдельному запросу, — это медленный путь.

3.3 Решение для производства: поиск ключевых слов с помощью экспертов

Стандартный совет («используйте эмбеддинги для семантического поиска») слишком расплывчат. Более точный вопрос: когда же они действительно заслуживают своего места в конвейере обработки данных? Четыре ответа, каждый из которых указывает на разные аспекты.

Уже знаете нужные ключевые слова? Используйте поиск по ключевым словам. Это быстрее, дешевле, позволяет проводить аудит и не так непрозрачно, как векторное сопоставление. Если регулирующий орган спросит, почему был получен тот или иной фрагмент текста, ответ «строка содержит форс-мажорные обстоятельства и пандемию» будет вполне обоснованным. Ответ «косинусное сходство составило 0,83» — нет.

Опечатки в запросе? Исправьте запрос. Один вызов LLM исправит policy на policy, и вы снова получите чистый поиск по ключевым словам. Конвейер встраивания не требуется.

Опечатки в документах? Теперь векторные представления действительно находят своё место. Контракты, распознанные с помощью OCR, отсканированные формы, рукописные заметки. Поиск по ключевым словам буквально не может найти токен с орфографической ошибкой, но векторное представление на уровне строки всё равно попадает в нужное место. Именно в этом случае векторный поиск становится структурно незаменимым.

Многоязычный корпус? Тот же ответ, другой механизм. Контракты на французском, переписка на английском, нормативные приложения на немецком. Многоязычное встраивание позволяет пользователю делать запросы на одном языке и получать строки с других. Ежегодная премия prime annuelle Annual premium: $1,200. (это было показано в разделе 1.4). Поддержание двуязычных словарей ключевых слов вручную возможно, но дорого; многоязычное встраивание бесплатно связывает языки, и эксперт поддерживает работу словаря на одном языке, используя встраивания в качестве резервного варианта для межъязыковой работы. Требуется многоязычная модель: ada-002, 3-large, BGE-M3 работают; GloVe и кодировщики предложений только на английском языке — нет.

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

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

Конкретные пары в разных областях. Как на практике выглядят «синонимы предметной области»:

• Договоры страхования : cancellation ↔︎ rescission , termination , lapse of cover , surrender of the policy . deductible ↔︎ excess (Великобритания), franchise (Франция). claim страховом случае ↔︎ loss notification , incident report . policyholder ↔︎ insured , assured , named party .
• Медицинская карта : blood sugar ↔ glycemia , A1C , HbA1c , fasting plasma glucose . myocardial infarction heart attack ↔ MI , acute coronary event . high blood pressure ↔ hypertension , elevated BP reading .
• Юридические и договорные положения : force majeure ↔︎ act of God , unforeseeable circumstances , events beyond reasonable control . Соглашение non-compete ↔︎ restrictive covenant , restraint of trade clause . confidentiality ↔︎ non-disclosure , NDA , proprietary information clause .
• Кадровые вопросы и трудоустройство : dismissal ↔ termination of employment , separation , severance event . salary ↔ compensation , base pay , gross remuneration . harassment ↔ unwanted conduct , hostile environment , inappropriate behaviour .

Ни один из этих псевдонимов не является словарным синонимом в обычном смысле. Это эквиваленты, специфичные для конкретной области, подтвержденные страховым андеррайтером, врачом, юристом по договорному праву, специалистом по кадрам. Встраивание находит их как подходящие варианты ; эксперт говорит «да» или «нет». Форс-мажор равен стихийному бедствию только в том случае, если вы знаете, что это так.

В HyDE это подразумевается (в LLM вероятный словарь документа создается на ходу, в разделе 3.2 показано, где это не удается). В сериале же это явно выражено: тщательно подобранный словарь ключевых слов, поддерживаемый экспертами в данной области .

 # Discovery loop. One corpus, seed terms the expert already knows. # Same `top_lines_for` primitive from section 3.1: no new infrastructure. SEED_TERMS = ["cancellation", "deductible", "claim", "policyholder"] draft_aliases = { seed: top_lines_for(seed, corpus_lines, k=10) for seed in SEED_TERMS } # Each draft is the top-k corpus phrasings closest to the seed. # Hand to the expert: they keep the real aliases, drop the coincidences. validated_dictionary = { "cancellation": ["rescission", "termination", "lapse of cover", "surrender of the policy"], "deductible": ["excess", "franchise"], "claim": ["loss notification", "incident report"], "policyholder": ["insured", "assured", "named party"], } # Production retrieval hits this dictionary directly. No embedding call # on the hot path; the embedding only ran once, at discovery time.

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

Схема представляет собой рабочий процесс поиска информации. Модель составляет список кандидатов, ранжированных по степени сходства. Эксперт читает их, сохраняет rescission , termination договора, lapse of cover , surrender of the policy , отмене premium payments и другие не относящиеся к теме строки, а словарная статья для cancellation создается за один проход проверки. С этого момента поиск осуществляется путем поиска по ключевым словам в словаре.

Рабочий процесс прогрессивный и выполняется вместе с экспертами, а не вокруг них. Первые несколько запросов к новому корпусу выполняются построчно, как в разделе 3.1. Они выявляют неожиданные формулировки в документах: в контракте используется термин «нештатный работник», тогда как пользователь указал «подрядчик»; в медицинской карте используется термин «A1C», тогда как пользователь указал «уровень сахара в крови»; в руководстве по процедурам используется термин «раздел 4.2», тогда как пользователь указал «правило сверхурочной работы». Эти формулировки фиксируются как псевдонимы ключевых слов в постоянно пополняющемся словаре, при этом эксперт проверяет каждый из них (он знает, какие псевдонимы являются реальными эквивалентами, а какие — совпадениями).

Последующие запросы выполняются с помощью поиска по ключевым словам с использованием расширенного словаря, без необходимости вызова встраивания. Каждый результат теперь можно проверить (мы знаем, какие ключевые слова совпали), он работает быстрее (нет задержки LLM/встраивания на этапе «горячего» поиска), а сам словарь становится надежным корпоративным активом, который сохраняется после завершения разработки.

Переформулировка более четкая, чем стандартная. Эмбеддинги — это не средство поиска исходных данных. Это начальный этап, который создает средство поиска исходных данных, по одному псевдониму ключевого слова за раз, в сотрудничестве с людьми, которые уже знакомы с корпусом. Статья 6 («Понимание вопроса») описывает разработку словаря: подсказки по предметной области, псевдонимы экспертов, множество альтернативных формулировок, обратную связь с результатами поиска. Статья 7 («Поиск») описывает целевую архитектуру поиска, которая использует словарь.

3.4 Пример использования кадровых ресурсов и обратной связи от клиентов

Большинство корпоративных документов не содержат эмоционально окрашенной информации. Контракты, нормативные документы, финансовые отчеты, технические спецификации представляют собой фактические корпуса; разделы 3.1–3.3 созданы именно для них. Подмножество корпоративных корпусов отличается: дословные записи опросов клиентов, комментарии сотрудников, тексты заявок в службу поддержки, упоминания бренда в социальных сетях. Здесь используется эмоциональная ( drained , frustrated , delighted , let down ), а не техническая ( force majeure , Solvency II , cedent ).

Процесс поиска по-прежнему актуален. HR-аналитик, создающий лексикон сигналов выгорания, вводит конкретное понятие, которое его волнует, например, feeling overwhelmed . Встраивание отображает фразы из корпуса в том же эмоциональном кластере. Лучшее совпадение ниже не имеет ни одного общего слова с запросом; все четыре модели, от GloVe до 3-large, ставят его на первое место.

Здесь нет эмоционального понимания. Эмоциональная лексика группируется в пространстве модели так же, как и страховая лексика в разделе 1.2 ( fee ↔︎ charge ). TF-IDF + логистическая регрессия достигли примерно 88% точности в анализе настроений IMDB в 2010 году, до появления контекстных вложений, потому что эмоциональные слова сами по себе несут сигнал. Вложения расширяют это за счет синонимии: overwhelmed , drained , empty , hollow , on the edge автоматически находятся близко друг к другу в пространстве, поэтому запрос по одному термину выдает предложения, использующие любой из них. Тот же механизм, что и в разделе 1.2, применен к другой лексике.

Полезное разделение для производства. Если цель — классификация настроений (оценка каждой записи в отзыве, агрегирование тенденций, выявление всплесков кризиса), то специализированная модель анализа настроений превосходит общую модель эмбеддинга. Специализированная модель обучается для решения конкретной задачи; модель эмбеддинга обучается для определения сходства. Для поиска лексики (какие фразы в нашем корпусе выражают тревогу?) модель эмбеддинга остается подходящим инструментом. Она выявляет лексикон, подтвержденный экспертом. Две задачи, два инструмента. Сарказм («О, отлично, еще один понедельник») ломает обе задачи, и для надежности в этом случае необходим контекст, который обычно не предоставляется дословным текстом.

Здесь прослеживается общая закономерность, описанная в статье. Первое впечатление: это похоже на зарождающееся эмоциональное понимание. Присмотритесь внимательнее: это сходство ключевых слов с более продуманным пониманием «близости». Применяйте соответственно: используйте модель, чтобы обнаружить незнакомую вам лексику; не требуйте от неё понимания смысла, стоящего за этой лексикой.

4. Заключение

Встраивания — это один из элементов Enterprise Document Intelligence Volume 1, который шаг за шагом строит корпоративную систему RAG. Словарь ключевых слов, которым завершается эта статья, — это то, что система извлечения данных в производственной среде (статья 7) считывает во время запроса, быстро и с возможностью аудита.

Эмблемы обладают мощными возможностями, но имеют определенные, предсказуемые ограничения.

• Раздел 1: с чем они справляются. Синонимы, перефразирование, опечатки, межъязыковые запросы и многозначность работают хорошо, при этом каждое поколение модели расширяет запас безопасности.
• Раздел 2: где они ломаются. Два различных корня. Во-первых, иногда этот термин просто отсутствует в модели.
• В разделе 2.1 это было наглядно продемонстрировано на pool : случайное предложение, представляющее собой расписание поездов, превзошло перефразированное предложение о перестраховании в трех из четырех моделей. Здесь используется корпоративная лексика. Во-вторых, когда термин присутствует в модели, ранжирование происходит по сходству терминов, а не по соотношению вопроса и ответа.
• Раздел 2.2 продемонстрировал это непосредственно на простейших запросах. Из этого второго корня следует каскадное отрицание (раздел 2.3), точные значения (раздел 2.4), тематическая близость, превосходящая релевантность ответа (раздел 2.5), и ослабление сигнала в длинном контексте (раздел 2.6). Целый каталог «очевидных» ошибок (идентификаторы OOV, булевы конструкции, подсчет, временные предикаты, многошаговые рассуждения) не нуждается в демонстрации.
• Раздел 3: как использовать их в производственной среде. Используйте эмбеддинги построчно, как функцию Ctrl-F поддержкой синонимов (раздел 3.1). Когда вам нужно преодолеть разрыв между вопросом и ответом, основной опорой являются ключевые слова, которые должен содержать ответ , а не эмбеддинг переписанного запроса (раздел 3.2). Производственный ответ представляет собой тщательно подобранный словарь ключевых слов, созданный экспертами и поддерживаемый построчным обнаружением эмбеддингов (раздел 3.3). Эмбеддинги — это не средство поиска в производственной среде; это способ быстрого и контролируемого поиска ключевых слов, которые затем будет использовать средство поиска в производственной среде.

Пример из реального проекта. Команда разработала систему RAG на основе коммерческих страховых контрактов и потратила три месяца на повышение полноты ответа. Они начали с теста OpenAI text-embedding-3-small с показателем полноты ответа 71%, затем протестировали Voyage, Cohere, BGE-M3 (показатель полноты ответа колебался от 69% до 73%), после чего доработали BGE на синтетических парах «вопрос-текст». Полнота ответа выросла до 76%. Пять пунктов через три месяца. Затем они разделили 200 вопросов по типам: 92% — концептуальные, 23% — отрицательные, 31% — точные ссылки, 18% — внутренние акронимы. В сумме 76% скрывались две категории с почти нулевой производительностью — никакая доработка не помогла их исправить. Добавление BM25 к векторному поиску заняло два дня, повысив показатель полноты ответа по точным ссылкам до 88%. Добавление шага расширения запроса для аббревиатур через корпоративный глоссарий заняло еще один день, что повысило запоминаемость внутренних аббревиатур с 18% до 71%. Одна неделя структурной работы перевесила три месяца тонкой настройки внедрения.

Два признака того, что команда слишком увлеклась встраиванием эмбеддингов: в дорожной карте в качестве следующего этапа указана «тонкая настройка модели эмбеддингов», еще до того, как кто-либо проанализировал фактические случаи сбоев; показатели поиска представлены в виде единого числа полноты без разбивки по типам вопросов, что скрывает категории, в которых эмбеддинги структурно некорректны.

Вы только что наблюдали, как эмбеддинги давали сбои предсказуемым, структурным образом. Рефлексом, особенно для инженеров с опытом работы в области машинного обучения, является исправление модели: больше обучающих данных, тонкая настройка, смена поставщиков, проведение повторного тестирования. В статье 3 утверждается, что это неправильный подход. Сбои, которые вы только что наблюдали, — это не ошибки, которые модель может исправить самостоятельно. RAG — это не машинное обучение, и относиться к нему как к таковому — значит тратить шесть месяцев на оптимизацию той части системы, которая не была сломана.

5. Дополнительная литература

Эмпирическая закономерность, описанная в этой статье (синонимы, опечатки, многозначность работают; отрицание, точные идентификаторы, акронимы вне домена не работают), соответствует каждому контролируемому исследованию плотных рекрутинговых систем на корпоративных корпусах, не относящихся к предметной области. Реймерс и Гуревич (Sentence-BERT, 2019) являются эталоном для понимания того, что технически означает встраивание строки. Равичандер и др. (CONDAQA, 2022) четко документируют неудачу отрицания. В статье переосмыслена модель HyDE (Гао и др., 2023): несущей силой являются ключевые слова, содержащиеся в гипотетическом ответе, а не сам этап встраивания; запрос ключевых слов непосредственно у LLM позволяет получить тот же фрагмент текста с меньшими затратами ресурсов. Тонкая настройка встраиваний на корпоративных корпусах выходит за рамки данной статьи и будет рассмотрена в статье 21 (производство).

В том же направлении, что и в статье:

• Реймерс и Гуревич, Sentence-BERT, EMNLP 2019 (arXiv:1908.10084). Ссылка на техническое описание того, что означает встраивание строки.
• Равичандер и др., CONDAQA, EMNLP 2022 (arXiv:2211.00295). Документирует, что плотные модели систематически терпят неудачу при отрицании. Направление совпадает с эмпирической закономерностью в этой статье.
• Гао и др., HyDE: Точный поиск с нулевым количеством примеров без меток релевантности, ACL 2023 (arXiv:2212.10496). В статье переосмысливается техника HyDE: ключевые слова из гипотетического ответа выполняют основную работу.
• Формал и др., SPLADE, 2021 (arXiv:2107.05720). Обучение разреженному поиску; мост между миром ключевых слов и векторных представлений, в том же духе, что и векторный поиск как структура поиска по ключевым словам.

Другой ракурс, другой контекст:

• Карпухин и др., Плотный поиск фрагментов текста для вопросов и ответов в открытой предметной области, EMNLP 2020 (arXiv:2004.04906). Канонический плотный поиск превосходит результат BM25 на тестовых наборах вопросов и ответов в открытой предметной области. Контекст — обучающие данные в рамках предметной области; в этой статье рассматриваются корпоративные корпуса, выходящие за рамки предметной области, где результат не переносится без проблем.
• Ван и др., Встраивание текста с помощью слабо контролируемого контрастивного предварительного обучения (E5), 2022 (arXiv:2212.03533) и Ли и др., NV-Embed, 2024 (arXiv:2405.17428). Линия «масштаб решает проблему»: более крупные корпуса контрастивного предварительного обучения закрывают разрыв в отсутствии словаря. В статье утверждается, что сбои носят структурный характер (сжатие разрушает сигнал точного значения), а не ограничены объемом данных.
• Хаттаб и Захария, ColBERT, SIGIR 2020 (arXiv:2004.12832). Поиск поздних взаимодействий как ответ на точное сопоставление токенов на уровне встраивания; актуально для режима отказа «точные значения, внутренние акронимы».
• Мюннигхофф и др., MTEB: Massive Text Embedding Benchmark, EACL 2023 (arXiv:2210.07316). Эталон, определяющий подход «выбери наиболее высокооцененный вектор встраивания». Полезен для моделей покупок; в статье утверждается, что таблица лидеров не является релевантной осью для корпоративного объектно-ориентированного словаря.

Анджела Ши. Все материалы от Анджелы Ши.

Источник: towardsdatascience.com