Как выбрать embedding модель без датасета и исторических данных

в 9:15, , рубрики: AI, embeddings, nlp, python, rag, retrieval, retrieval augmented generation

Введение

С появлением больших языковых моделей тема векторного поиска обрела новое дыхание. Компании, которые хотят внедрить архитектуру Retrieval-Augmented Generation (RAG), сталкиваются с вопросом: как выбрать эмбеддинги, которые будут работать эффективно именно с их данными?

Выбор эмбеддинг-модели — это стратегически важное и долгосрочное решение, так как оно определяет качество поиска и производительность системы. Но этот выбор особенно сложно сделать на ранних этапах развития вашего проекта, когда данных для анализа ещё нет. При этом замена модели в будущем может оказаться дорогостоящей и ресурсозатратной.

На первый взгляд, решение принять несложно — заходим на какой-нибудь популярный бенчмарк и берем модель с топа. Но успех на лидерборде не гарантирует аналогичных результатов в специфичных доменах, таких как финансы, медицина или e-com. Без собственного датасета или пользовательской истории выбор модели становится настоящей проблемой.

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

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

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

  • Размер модели: мы избегаем больших языковых моделей и выбираем компактные, которые проще внедрить в продакшн.

  • Размерность векторов: для оптимального баланса между качеством и производительностью мы выбирали модели с размерностью векторов до 3000 измерений.

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

Общего назначения:

Биологические:

Мы намеренно включили в анализ ModernBERT от HuggingFase, базовую модель, которая не обучалась на задаче sentence similarity. Мы сделали это, чтобы продемонстрировать, как не должен работать векторный поиск. На её примере мы увидим, как ведет себя заведомо неподходящая модель и почему использование такого эмбеддера может привести к хаотичным и бессмысленным результатам.

Оба автора работают с медицинскими данными, поэтому для анализа мы используем медицинские и биологические термины и тексты из этой области. Но представленные подходы универсальны и легко адаптируются под задачи любого специализированного домена — будь то финтех, legaltech, e-com или любая другая отрасль.

Итак, приступим!

Стандартный подход к оценке качества поиска

Векторный поиск, как правило, делается следующим образом:

  1. Эмбеддинг-модель используется для создания векторных представлений документов базы,

  2. Запрос пользователя преобразуется в вектор с использованием той же модели,

  3. Представление запроса сравнивается с представлениями документов,

  4. Формируется ранжированный список наиболее релевантных документов.

В идеальной ситуации, если у нас есть

  • набор документов D,

  • набор запросов Q,

  • и метки релевантности запросов к документам (q, d) из Q times D, можно было бы применить стандартные количественные метрики качества поиска, такие как Precision@k, Recall@k, NDCG@k или MAP.

В реальном мире данных для расчёта таких метрик часто нет. Давайте подумаем, как их можно получить.

Где взять данные?

Для оценки векторных представлений можно использовать

  • Бенчмарки,

  • Ручную разметку,

  • Пользовательскую историю.

Давайте рассмотрим каждый из этих источников по отдельности.

Бенчмарки

Бенчмарки, такие как MTEB, предоставляют универсальные инструменты для оценки эмбеддинг-моделей. Но MTEB тестирует качество моделей на разных задачах: классификации, кластеризации, генерации текста, — и не фокусируется на векторном поиске. Поэтому топовые модели на MTEB могут не показать хороших результатов в ваших сценариях.

Альтернативный вариант — BEIR, платформа для оценки моделей в information retrieval. Она включает набор датасетов для оценки разных моделей поиска (необязательно основанных на эмбеддингах) в реальных сценариях.

Но если заглянуть в список датасетов BEIR, то становится ясно, что большинство из них ориентировано на:

  • Медицинские темы,

  • Задачам question answering.

Отличная отправная точка для тех, кто работает в фарме. Но если ваша область, например, legaltech, BEIR оказывается не так релевантен.

Таким образом, BEIR, как и MTEB, помогают в выборе моделей-кандидатов, но окончательное решение потребует дальнейшей оценки.

Ручная разметка

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

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

Если у вас уже есть подходящие данные — используйте их. Если нет, и разметка кажется непомерно дорогой, имеет смысл рассмотреть альтернативные подходы к оценке.

Пользовательская история

Анализ исторических данных о взаимодействии пользователей с поисковой выдачей может дать полезные сигналы для оценки качества поиска. Например, в e-commerce можно анализировать клики и покупки, связанные с различными запросами. В фармацевтике это могут быть данные об интересе пользователей к определённым препаратам или исследованиям.

Но у этого подхода есть ограничения:

  1. Вовлечённость ≠ релевантность. Вовлеченные пользователи могут взаимодействовать с нерелевантными результатами (например, с кликбейтами). Или наоборот, выдача может быть релевантной, а вовлечение низким, например, если поиск отработал правильно, но пользователи игнорируют корректную выдачу.

  2. Шумы в данных. Например, если нужный товар находится на второй странице, но человек случайно её пропустил, то эти данные не будут учтены в выборке, что исказит картину.

  3. Редкие запросы и пустая выдача. Для редких запросов или тех, по которым база не содержит документов, собрать достаточное количество данных на её основе невозможно.

Эти факторы приводят к появлению шума в данных и повышают риск усиления существующих bias-ов модели, а не их устранения. Поэтому формировать такую выборку вслепую нельзя: нужно быть очень, очень внимательным к данным.

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

Что такое идеальный эмбеддинг?

Давайте подумаем, что мы ждем от эмбеддингов в задаче поиска? Как должна себя вести идеальная модель?

Для подобных задач часто используют two-tower approach, который учитывает:

  • поиск релевантных документов по запросу (соответствие запрос → документ), чтобы выдача максимально точно отвечала запросу,

  • персонализацию документов для пользователей (соответствие документ → пользователь), чтобы выдача учитывали историю покупок и предпочтения пользователей.

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

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

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

  • Взаимодействие запросов и документов: эффективно ли эмбеддинги запросов и документов работают вместе.

  • Устойчивость к опечаткам: обеспечивает ли модель качественный поиск при наличии ошибок в запросах.

  • Работа с терминами: хорошо ли векторные представления отражают специфичную терминологию вашей предметной области.

Оценка эмбеддинг-моделей

Эмбеддинги запросов

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

схожие запросы → близкие векторы.

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

В этой паре использованы синонимы:

  • "Earwax removal is sometimes necessary when natural cleaning mechanisms fail"

  • "When cerumen does not clear on its own, medical intervention may be required"

Здесь в первом запросе название заболевания приведено полностью, а во втором в сокращении:

  • "What are the major predispositions for renal failure?"

  • "Which factors contribute to the development of CKD?"

Здесь использован в сокращении и без биологический термин:

  • "Role of M1dG in oxidative DNA damage"

  • "Impact of malondialdehyde-deoxyguanine adducts on genomic stability"

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

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

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

Результаты визуализированы на тепловых картах ниже, где интенсивность цвета отражает степень близости между запросами. На диагонали отображаются значения для синонимичных запросов, а вне диагонали — для запросов из разных пар.

image

image

OpenAI (text-embedding-3-large): Диагональ отлично выделена на фоне низких значений для запросов, относящихся к разным парам. Модель уверенно различает схожие запросы внутри пар и практически исключает высокие скоры для несвязанных запросов.

image

image

Voyage (voyage-large-2): Диагональ выделяется слабо, это означает, что модель плохо различает схожие и несхожие запросы, при этом несвязанные запросы в нескольких местах показывают такие же высокие значения косинусного сходства как на диагонали.

image

image

Alibaba (gte-large-en-v1.5): Диагональ выделена лучше, чем у Voyage, но имеет пропуски. Это означает, что в какох-то примерах она справляется с терминами, а в каких-то нет. Контраст с фоном показывает, что модель различает запросы, но не так контрастно, как OpenAI.

image

image

Jina (jina-embeddings-v3): Диагональ отлично выделена, по контрастности напоминает OpenAI, видно, что модель неплохо справилась с разделением тестовых запросов, хотя на диагонали видны пропуски, а вне диагонали — островки высоких значений, что говорит о том, что модель не очень справилась с этим тестом.

image

image

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

image

image

ModernBERT-gte (gte-modernbert-base): хорошо себя показывает в этом тесте: диагональ в целом различима, высоких скоров вне диагонали не много. Не-диагональные значения высокие относительно диагонали, то есть, модель мягко разделяет не синонимичные, но относящиеся к одной и той же области запросы.

image

image

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

Выбор между моделями зависит от задач. Например, если требуется строгое разделение запросов, подходящей будет модель от OpenAI. Для более мягкого разделения можно рассмотреть Voyage или ModernBERT-gte. Главное, чтобы модель не вела себя как ModernBERT-base в приведённой визуализации, где диагональ совсем не выделяется, а запросы на диагонали и вне выглядят одинаково релевантными.

Как эмбеддинги запросов и документов работают вместе

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

В биомедицинских данных можно ориентироваться на MeSH (Medical Subject Headings) — иерархическую систему медицинских терминов. В e-com такую иерархию можно позаимствовать из каталога товаров, а в hr-tech — из перечней профессий. В других областях таксономией могут служить теги, жанры, или другие классификации.

Вот как выглядят MeSH terms в медицине

image

image

Для демонстрации мы использовали аннотации научных статей за последние пять лет, относящиеся к термину MeSH Diabetes, Gestational [C19.246.200] — гестационный диабет, который может развиться у женщины во время беременности и как правило исчезает после родов.

В качестве «соседней» группы мы взяли Latent Autoimmune Diabetes in Adults [C19.246.656] (сокращенно LADA) — медленно прогрессирующий аутоиммунный тип диабета, диагностируемый в зрелом возрасте. Для категории LADA мы взяли только название категории, без текстов.

В среднем один токен составляет примерно 3/4 слова (то есть, 100 токенов ≈ 75 слов). Поэтому для простоты мы исключили из выборки аннотации длиной более 600 слов (оставив небольшой запас), чтобы избежать необходимости чанкинга, поскольку не все выбранные для анализа модели могут работать с длинными текстовыми последовательностями.

Таким образом, для анализа мы выбрали аннотации статей из PubMed, посвящённые двум формам диабета, схожим по клинической картине, но различным по этиологии.

image

image

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

Мы рассчитываем близость текстов документов из одной категории (например, Diabetes, Gestational) к:

  1. Названию своей категории, например, "Gestational diabetes".

  2. Названию соседней категории, например, "Latent autoimmune diabetes in adults".

Эта проверка позволяет понять:

  • Видит ли модель разницу между документами из своей категории и из соседней.

  • Насколько минимальные, максимальные и средние значения близости текстов к своим и соседним категориям различаются.

image

image

На графиках представлены распределения близостей текстов к названиям двух категорий: Gestational diabetes и LADA, рассчитанные для разных моделей. Вот какие наблюдения позволяет сделать визуализация:

  1. OpenAI (text-embedding-3-large): Средняя близость текстов к своей категории (Gestational diabetes) составляет около 0.45, тогда как к соседней категории (LADA) — около 0.3. Это указывает на хорошее различение модели между категориями, при этом для модели в целом не характерны высокие значения близости.

  2. Voyage (voyage-large-2): Для этой модели характерны более высокие значения семантической близости — средние значения для обеих категорий около 0.8. Хотя модель хорошо различает документы, распределения перекрываются и это может создавать проблемы в сценариях, требующих строгого разделения.

  3. Alibaba (gte-large-en-v1.5): Модель уверенно различает категории: средняя близость текстов к Gestational diabetes составляет почти 0.8, тогда как к LADA — чуть меньше 0.6. Такое поведение делает Alibaba подходящим выбором для задач, где требуется уверенное различение между схожими, но различными по смыслу текстами.

  4. Jina (jina-embeddings-v3): Результаты модели схожи с Alibaba: модель хорошо разделяет категории, при этом распределения более широкие, а разница между средней близостью к своей категории и к соседней заметная. Средние значения для своей категории выше, чем для нерелевантной, что подтверждает способность модели различать документы.

  5. BioBERT: Средняя близость текстов к своей категории (Gestational diabetes) составляет около 0.5, тогда как к нерелевантной (LADA) — около 0.3, что демонстрирует способность модели различать категории. Также видно, что модель в целом не выдает высоких значений близости, а среди нерелевантных текстов минимальные значения опускаются очень низко, что соответствует ее специализации на биомедицинском домене.

  6. MedEmbed: Модель не слишком уверенно разделение категории, со средними значениями около 0.7 для своей категории (Gestational diabetes) и 0.6 для соседней (LADA). Однако различие между категориями не так выражено, как, например, у BioBERT, что может свидетельствовать о меньшей уверенности модели в оценке семантической релевантности.

  7. ModernBERT-gte (gte-modernbert-base): средняя близость текстов к своей категории составляет около 0.7 и примерно 0.6 к соседней, и распределения практически не перекрываются. То есть, модель склонна выдавать высокие скоры текстам, но уверенно отличает релевантные тексты от нерелевантных, а значит, хорошо проходит этот тест.

  8. ModernBERT-base: Модель ведёт себя неадекватно: тексты категории Gestational diabetes имеют среднюю близость к LADA выше, чем к «своему» названию категории. Средняя близость к LADA превышает 0.8, тогда как к Gestational diabetes она составляет около 0.7. Такое поведение говорит о том, что модель не способна корректно различать категории.

Таким образом,

  • модели от Voyage, MedEmbed и ModernBERT-base показали недостаточную способность корректно различать категории в данном тесте,

  • а модели OpenAI, Alibaba, Jina и BioBERT показали хорошие результаты в этом тесте.

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

Устойчивость к опечаткам

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

Мы сформировали список из 12 медицинских терминов с различными типами ошибок:

  • willebrand disease → xillebrand disease

  • ozempik → 0zempik

  • patient → aptient

  • pregnancy → regnancy

  • transfusions → transfysions

  • diagnosis → diaqnosis

  • cystinuria → cystiunria

  • delstrigo → deltrigo

  • sclerosis → sclerosiq

  • fatigue → fatiguc

  • therapy → therpay

  • cyst → cys

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

  • замена буквы на близкую в раскладке,

  • пропуски,

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

image

image

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

  1. OpenAI (text-embedding-3-large) уверенно обрабатывает большинство терминов, включая сложные случаи, как "therapy → therpay" (0.71), которые смогли «смутить» остальные модели. Поскольку из первого теста мы ожидаем сходство для идентичных запросов не ниже 0.5, то видим, что "delstrigo → deltrigo" (0.45) и "patient → aptient" (0.43) немного не дотягивают до этого порога. Это показывает, что хоть модель не всегда корректно распознает опечатки, в целом присваивает высокий уровень сходства большинству примеров.

  2. Voyage (voyage-large-2) выглядит очень устойчиво к опечаткам. Например, "delstrigo → deltrigo" и "pregnancy → regnancy" получили почти идеальные 0.99. По первому тесту ожидаем сходство для идентичных запросов не ниже 0.85 — и все скоры здесь превышают этот порог. Это говорит о том, что модель уверенно справляется с опечатками.

  3. Alibaba (gte-large-en-v1.5) не справляется с опечатками. По первому тесту ожидаем сходство для идентичных запросов не ниже 0.75, но здесь только "delstrigo → deltrigo" (0.84) выше этого уровня, а остальные значения заметно ниже. Модель плохо обрабатывает ошибки, и если в системе ожидаются пользовательские опечатки, возможно, ее лучше исключить из рассмотрения.

  4. Jina (jina-embeddings-v3) нестабильно работает с опечатками. По первому тесту ожидаем сходство для идентичных запросов не ниже 0.5 (но модель показала там спорные результаты, так что четкий порог определить сложно). В некоторых примерах она справилась отлично: "fatigue → fatiguc" (0.90), "cystinuria → cystiunria" (0.90), "delstrigo → deltrigo" (0.89). А в других — провалилась: "therapy → therpay" (0.37), "pregnancy → regnancy" (0.25). Результаты неоднородные, и модель не всегда уверенно справляется с опечатками.

  5. BioBERT не склонна выдавать сравниваемым текстам высокие значения сходства (около 0.5 на данных из первого теста). На этом фоне получается, что модель не распознала около половины терминов с опечатками, что указывает на посредственное качество обработки ошибок.

  6. MedEmbed в прошлых тестах наоборот показывала тенденцию к завышению значений, со средним скором около 0.65 для релевантных текстов. В этом тесте примерно половина из 12 значений превысили порог, что также не говорит о высокой устойчивости к опечаткам.

  7. ModernBERT-gte (gte-modernbert-base) в первом тесте показывала среднее сходство для релевантных текстов около 0.7, и здесь большинство результатов соответствуют этому уровню. Отлично сработали "delstrigo → deltrigo" (0.93), "pregnancy → regnancy" (0.93) и "willebrand disease → xillebrand disease" (0.89) — это высокие значения для модели. Есть только один однозначный провал, это пара "therapy → therpay" (0.56), но в целом модель имеет хорошую устойчивость к опечаткам.

  8. ModernBERT-base, поскольку в прошлых тестах результаты модели были неадекватными, всерьёз оценить её работу в этом тесте невозможно.

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

Работа с доменными терминами

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

  1. Соберем набор специализированных терминов из медицинской области, включая как общеизвестные термины, так и редкие.

  2. Преобразуем их в эмбеддинг-векторы, используя модели, участвующие в анализе.

  3. Сравним полученные векторы с векторами из какого-нибудь доступного словаря (например, WordNet), чтобы определить ближайшие по смыслу слова и таким образом увидеть, «понимает» ли модель термины нашего домена.

Втот список терминов, который мы используем для этого теста:
- lncRNA — длинные некодирующие РНК, регулирующие экспрессию генов.
- BBB disruption therapy — метод временного нарушения гематоэнцефалического барьера для доставки лекарств в ткани мозга.
- Antisense oligonucleotide — короткие синтетические ДНК или РНК, используемые в терапии генетических заболеваний и рака.
- PD-L1 mAbs — моноклональные антитела, помогающие иммунной системе распознавать и уничтожать раковые клетки.
- Kabuki syndrome — редкое генетическое заболевание.
- Waldenström Macroglobulinemia — редкий вид неходжкинской лимфомы.
- Frey syndrome — состояние, вызывающее потливость лица во время еды.
- Ozempic — лекарство для лечения диабета 2 типа и контроля веса.
- Cladribine — препарат для лечения рассеянного склероза.
- Zolgensma — генная терапия для лечения спинальной мышечной атрофии.
- ReoPro — препарат для предотвращения свертывания крови при сосудистых операциях.

Если ближайшие к термину векторы представляют синонимы, связанные концепции или термины из той же области, это говорит о том, что модель корректно улавливает контекст. Например, если к «РНК» модель относит слова «геном» или «рибосома», это указывает на её способность корректно работать с этим термином. Если же модель выберет из словаря слоги или не связанные с медициной слова, это сигнализирует о проблемах в работе модели с терминами.

Ниже результаты для разных моделей:

Термин

OpenAI

Voyage

Alibaba

Jina

BioBERT

MedEmbed

ModernBERT-GTE

ModernBERT-base

lncRNA

nrna, nuclear_rna, informational_rna

nuclear_rna, mrna, rna

rna, informational_rna, mrna

nrna, rna, nrl

lunda, livistona, liliales

rna, nuclear_rna, nrna

nlrb, nrna, rna

mycophage, chalcid, flecainide

BBB disruption therapy

blood-brain_barrier, thrombolytic_therapy, clot

therapeutic, therapy, therapeutical

implosion_therapy, disrupt, therapeutical

implosion_therapy, behavior_therapy, disruption

bobsledding, bd, boding

disruption, bb, bbs

ebbtide, bas_relief, implosion_therapy

feedlot, birthwort, bombastically

Antisense oligonucleotide

nucleoside, antimetabolite, dideoxyinosine

antibody, recombinant, isoantibody

nucleoside, didanosine, mrna

non-nucleoside_reverse_transcriptase_inhibitor

ribonucleic_acid, antineoplastic, knock-down

nucleotide, dna, endonuclease

antipode, noncoding_dna, informational_rna

queenfish, immensurable, antihistamine

PD-L1 mAbs

cancer_drug, immunotherapeutic, anti-tnf_compound

monoclonal, monoclonal_antibody, antibody

monoclonal_antibody, immunotherapeutic, monoclonal

immunoglobulin_d, monoclonal_antibody, immunoassay

mam, lgb, mamma

monoclonal_antibody, monoclonal, pd

lablab, l-p, blood_profile

l-plate, hsv-2, 401-k_plan

Kabuki syndrome

kakke_disease, noonan's_syndrome, syndrome

syndrome, korsakoff's_syndrome, abasia

kallman's_syndrome, ekbom_syndrome, syndrome

ekbom_syndrome, akinesia, korsakoff's_syndrome

kaki, kalansuwa, kawaka

korzybski, kaki, ekbom_syndrome

kuki, ekbom_syndrome, kuki-chin

giant_reed, cushaw, mortal_sin

Waldenström Macroglobulinemia

plasmacytoma, myeloma, gammopathy

agammaglobulinemia, hypogammaglobulinemia, granulomatosis

agammaglobulinemia, multiple_myeloma, myeloma

agammaglobulinemia, myoglobinuria, megaloblast

myoglobinuria, mulishness, hypogammaglobulinemia

agammaglobulinemia, waldenses, hypogammaglobulinemia

wilms_tumour, blood_profile, williams_syndrome

osteosclerosis_congenita, drepanocytic_anaemia

Frey syndrome

hyperhidrosis, diaphoresis, polyhidrosis

syndrome, williams_syndrome, idiopathy

frey, bruxism, waterhouse-friderichsen_syndrome

syndrome, frey, reye's_syndrome

frey, freyr, freya

frey, freya, freyr

reye's_syndrome, frey, ramsay_hunt_syndrome

frostwort, foumart, fortunella

Ozempic

glucophage, glipizide, zapotecan

otic, zocor, empirin

ozena, obidoxime_chloride, oxyphencyclimine

ocimum, omotic, oecumenic

ozena, ozarks, ozaena

ozonize, typic, ozonide

zyloprim, oxytocic_drug, oxytocic

palometa, pseudemys, empyreal

Cladribine

chlorambucil, leukeran, mercaptopurine

clonidine, chlorpromazine, clomipramine

zalcitabine, lamivudine, deoxyadenosine

cladrastis, clerid, clinid

cladonia, cladrastis, cladode

clad, cladode, zalcitabine

cuprimine, calcimine, cadaverine

cladoniaceae, cladophyll, cicadellidae

Zolgensma

zoloft, lofortyx, vincristine

zetland, zinzendorf, nijmegen

zeugma, zygnema, genus_zygnema

zola, zymogen, zolaesque

ziziphus, zola, zetland

zeugma, glechoma, zygoma

zeugma, z, malosma

schmaltz, spotweld, zinfandel

ReoPro

lipo-hepin, thrombolytic_agent, plavix

pro, re, ream

appro, reechoing, recopy

pro, recco, ro

reproval, retem, reamer

requital, reenact, reproof

repp, revisal, reseau

galactocele, rectocele, proviso

Таблица показывает, что не все модели хорошо обрабатывают медицинские термины.

  1. OpenAI (text-embedding-3-large) продемонстрировала отличные результаты. Она единственная корректно связала термин "BBB disruption therapy" с "blood-brain_barrier" из WordNet. Термин "PD-L1 mAbs" правильно ассоциировала с "cancer_drug", отражая связь с лекарствами от рака. Точно обработала "Frey syndrome", связав его с "hyperhidrosis", что соответствует клиническому проявлению этого синдрома. Также успешно определила кластер лекарств для "Ozempic", связав его другими медикаментами для лечения диабета второго типа. Модель не справилась с терминами "Zolgensma" и "ReoPro", но сохранила ассоциацию с медицинским контекстом.

  2. Voyage (voyage-large-2) показала средние результаты. Для "BBB disruption therapy" модель зацепилась за слово "therapy", но не смогла вытащить релевантные слова. Для "Frey syndrome" она извлекла лишь общие термины со словом "синдром", не учитывая специфики. В "PD-L1 mAbs" модель правильно распознала сокращение, но не ассоциировала его механизмом действия или назначением. Для "Ozempic" и "ReoPro" модель не смогла выделить ничего значимого, вытащив нерелевантные слова, такие как "otic", "zocor", "ream". В целом, Voyage справляется, но обрабатывает медицинские термины поверхностно.

  3. Alibaba (gte-large-en-v1.5) проявила себя неоднородно. Например, она ассоциировала "BBB disruption therapy" с психотерапевтическими терминами ("implosion_therapy"), что является ошибкой. С "Antisense oligonucleotide" модель справилась неплохо, распознав молекулярные компоненты, и с "Waldenström Macroglobulinemia" — определив её как опухоль. Однако с "Ozempic" модель не смогла выдать полезные ассоциации, предложив термины из другого домена. "Zolgensma" также осталась для неё загадкой, так как среди ближайших слов оказались "zeugma" и "zygnema", не связанные с медициной.

  4. Jina (jina-embeddings-v3) явно не ориентирована на медицинский контекст. Например, для терминов "lncRNA", "Ozempic", "Cladribine", "Zolgensma" и "ReoPro" она предложила слоги вместо осмысленных ассоциаций. С "BBB disruption therapy" модель также ошибочно вытащила психотерапевтические термины ("implosion_therapy"). Несмотря на это, она справилась с терминами вроде "Antisense oligonucleotide", "PD-L1 mAbs", и "Waldenström Macroglobulinemia", значительно уступая OpenAI и Voyage.

  5. BioBERT, неожиданно для модели, обученной на медицинских данных, показал слабые результаты. Она не смогла корректно обработать большинство терминов, включая "BBB disruption therapy", где выдала совершенно нерелевантное "bobsledding". Видна тенденция к опоре на отдельные токены, например, для "Ozempic" и других лекарств. Для "Frey syndrome" модель предложила набор слов ("frey", "freyr", "freya"), что также указывает на её слабость в медицинском домене.

  6. MedEmbed оказалась только чуть лучше BioBERT. Она сохраняет общую привязку к медицинскому домену, что делает её использование в этом контексте возможным, хотя с лекарствами, такими как "Ozempic" и "Cladribine", модель не справилась.

  7. ModernBERT-gte (gte-modernbert-base) показал средние результаты. Модель корректно обработала "Antisense oligonucleotide", предложив "antipode" и "noncoding_dna", что частично отражает смысл термина. В "Kabuki syndrome" модель, как и другие, зацепилась за слово "syndrome", но дополнительно вытянула "kuki-chin", что не имеет отношения к медицине. Для "Waldenström Macroglobulinemia" результаты были неплохими — модель смогла выделить относительно релевантные термины, такие как "wilms_tumour" и "blood_profile". С "Ozempic" модель не справилась, но, в отличие от Jina и BioBERT, среди ближайших терминов все же оказались медицинские слова. В целом, модель показывает неплохое, но не выдающееся качество обработки медицинских терминов.

  8. ModernBERT-base не работает: её ассоциации в более чем половине случаев выходят за рамки медицинского контекста. Например, вместо медицинских терминов модель предлагает слова вроде "bombastically", "queenfish", "frostwort", "schmaltz". Подобные результаты указывают на то, что модель не справляется с обработкой медицинского контекста.

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

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

Бонус трек: поиск выбросов

Если вы дочитали до этого места, то это бонус-трек:)

Что модель считает «противоположностью» вашему запросу? Если у вас уже есть работающая поисковая система, попробуйте вместо top-n документов запросить те, которые находятся в самом конце списка по косинусному сходству .

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

Таким способом мы случайно обнаружили на одном из проектов в базе медицинских текстов:

  • Руководство по сборке шкафа IKEA,

  • Список лучших мест для пикников в Лондоне,

  • Инструкцию по ловле форели на искусственные приманки.

Это своеобразный sanity check на больших объемах данных, который может не только дать вам представление о поведении модели, но и помочь почистить данные. К тому же, это весело!

Вывод

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

Эти тесты — качественные, а не количественные. Они не дают строгих численных оценок, но зато дешевы в реализации, не требуют сложных вычислений и понятны даже не-техническим стейкхолдерам. Плюс качественного подхода в том, что он повышает explainability для бизнеса: помогает наглядно объяснить, как ведёт себя модель, где границы применимости и почему в каких-то случаях поиск может не работать так, как ожидалось.

Представленные методы оценки эмбеддинг-моделей позволяют построить первую версию RAG, даже если у вас нет golden датасета. Они дают быстрые результаты, помогая избежать работы с заведомо неподходящими моделями-кандидатами и помогают решить проблему холодного старта, чтобы не выбирать модель вслепую, а сначала проверить её адекватность в работе с данными вашей предметной области.

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

  • во время обучения они могли не получить редкие данные,

  • они точно не «видели» новых данных, появившихся после их обучения.

Эмбеддинги — не волшебная палочка. Поэтому если ваш проект связан со специализированными или быстро развивающимися областями, ванильного векторного поиска точно будет недостаточно.

Чтобы получить надёжную поисковую систему, стоит сразу думать о гибридных подходах, подключать реранкинг или использовать дополнительные источники знаний. Такой подход поможет построить поиск, который не просто возвращает документы, а действительно отвечает на запросы пользователей.

Спасибо, что дочитали статью до конца! Если у вас есть вопросы или идеи, будем рады обсудить их в комментариях.

Заглядывайте на наш GitHub: мы оставили там блокнот, который мы использовали для проведения анализа и который вы можете адаптировать для ваших задач. Будем благодарны за звёздочки, пулл-реквесты и комментарии!

Если вашему бизнесу или команде нужна экспертиза в обработке текстов, пишите в LinkedIn Марии или Екатерине — обсудим ваши задачи и поможем с их решением. А еще подписывайтесь, чтобы не пропустить новые статьи!

Вдохновлено

Автор: dropout_duo

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js