dropout_duo 24 фев в 12:15

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

Сложный

23 мин

3.2K

Машинное обучение*Python*

Туториал

Из песочницы

Введение

О чем эта статья

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

Кому и зачем её читать

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

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

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

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

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

Таким образом, если

вы работаете с поиском или строите RAG (Retrieval Augmented Generation) систему;
ваша доменная область быстро развивается или в ней есть специализрованный язык;
у вас нет данных;
вам нужно выбрать эмбеддинги, которые будут работать эффективно именно на ваших задачах;

то это руководство для вас.

Что будет в этой статье

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

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

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

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

Какие модели мы рассматриваем здесь

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

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

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

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

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

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

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

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

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

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

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

набор документов ,
набор запросов ,
и метки релевантности запросов к документам из $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 можно анализировать клики и покупки, связанные с различными запросами. В фармацевтике это могут быть данные об интересе пользователей к определённым препаратам или исследованиям.

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

Вовлечённость ≠ релевантность. Вовлеченные пользователи могут взаимодействовать с нерелевантными результатами (например, с кликбейтами). Или наоборот, выдача может быть релевантной, а вовлечение низким, например, если поиск отработал правильно, но пользователи игнорируют корректную выдачу.
Шумы в данных. Например, если нужный товар находится на второй странице, но человек случайно её пропустил, то эти данные не будут учтены в выборке, что исказит картину.
Редкие запросы и пустая выдача. Для редких запросов или тех, по которым база не содержит документов, собрать достаточное количество данных на её основе невозможно.

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

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

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

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

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

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

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

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

Различает ли модель семантику запросов? – в пеовом разделе мы рассматриваем, как модель кодирует запросы в векторы. Если модель не может сопоставить близкие по смыслу, но сформулированные разными словами запросы из вашего домена, то это беда.
Правильно ли взаимодейстуют запросы и документы? – во втором разделе мы анализируем, насколько релевантные документы действительно оказываются ближе к запросу, чем нерелевантные. Это помогает понять, видит ли модель смысловые различия между похожими темами и не сваливает ли всё в одну кучу.
Устойчива ли модель к опечаткам? В разделе 3 мы имитируем пользовательские ошибки и оцениваем, насколько модель сохраняет смысловую близость между словарной формой слова и его искаженной версией. Если в вашей системе планируется ввод от пользователей, то в нем гарантированно будут ошибки и важно понимать, как хорошо модель справляется с ними.
Тест на работу с доменными терминами – показывает, насколько эмбеддинги улавливают терминологию вашей предметной области. Если медицинская модель ассоциирует название лекарства с видом спорта, то на неё нельзя полагаться.

В следующем разделе разберём, как провести такие оценки.

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

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

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

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

Чтобы проверить это, мы сформировали 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"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OpenAI (text-embedding-3-large): Средняя близость текстов к своей категории (Gestational diabetes) составляет около 0.45, тогда как к соседней категории (LADA) — около 0.3. Это указывает на хорошее различение модели между категориями, при этом для модели в целом не характерны высокие значения близости.
Voyage (voyage-large-2): Для этой модели характерны более высокие значения семантической близости — средние значения для обеих категорий около 0.8. Хотя модель хорошо различает документы, распределения перекрываются и это может создавать проблемы в сценариях, требующих строгого разделения.
Alibaba (gte-large-en-v1.5): Модель уверенно различает категории: средняя близость текстов к Gestational diabetes составляет почти 0.8, тогда как к LADA — чуть меньше 0.6. Такое поведение делает Alibaba подходящим выбором для задач, где требуется уверенное различение между схожими, но различными по смыслу текстами.
Jina (jina-embeddings-v3): Результаты модели схожи с Alibaba: модель хорошо разделяет категории, при этом распределения более широкие, а разница между средней близостью к своей категории и к соседней заметная. Средние значения для своей категории выше, чем для нерелевантной, что подтверждает способность модели различать документы.
BioBERT: Средняя близость текстов к своей категории (Gestational diabetes) составляет около 0.5, тогда как к нерелевантной (LADA) — около 0.3, что демонстрирует способность модели различать категории. Также видно, что модель в целом не выдает высоких значений близости, а среди нерелевантных текстов минимальные значения опускаются очень низко, что соответствует ее специализации на биомедицинском домене.
MedEmbed: Модель не слишком уверенно разделение категории, со средними значениями около 0.7 для своей категории (Gestational diabetes) и 0.6 для соседней (LADA). Однако различие между категориями не так выражено, как, например, у BioBERT, что может свидетельствовать о меньшей уверенности модели в оценке семантической релевантности.
ModernBERT-gte (gte-modernbert-base): средняя близость текстов к своей категории составляет около 0.7 и примерно 0.6 к соседней, и распределения практически не перекрываются. То есть, модель склонна выдавать высокие скоры текстам, но уверенно отличает релевантные тексты от нерелевантных, а значит, хорошо проходит этот тест.
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). Лучше, чтобы в наборе были представлены ошибки разных типов, например,

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

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

OpenAI (text-embedding-3-large) уверенно обрабатывает большинство терминов, включая сложные случаи, как "therapy → therpay" (0.71), которые смогли «смутить» остальные модели. Поскольку из первого теста мы ожидаем сходство для идентичных запросов не ниже 0.5, то видим, что "delstrigo → deltrigo" (0.45) и "patient → aptient" (0.43) немного не дотягивают до этого порога. Это показывает, что хоть модель не всегда корректно распознает опечатки, в целом присваивает высокий уровень сходства большинству примеров.
Voyage (voyage-large-2) выглядит очень устойчиво к опечаткам. Например, "delstrigo → deltrigo" и "pregnancy → regnancy" получили почти идеальные 0.99. По первому тесту ожидаем сходство для идентичных запросов не ниже 0.85 — и все скоры здесь превышают этот порог. Это говорит о том, что модель уверенно справляется с опечатками.
Alibaba (gte-large-en-v1.5) не справляется с опечатками. По первому тесту ожидаем сходство для идентичных запросов не ниже 0.75, но здесь только "delstrigo → deltrigo" (0.84) выше этого уровня, а остальные значения заметно ниже. Модель плохо обрабатывает ошибки, и если в системе ожидаются пользовательские опечатки, возможно, ее лучше исключить из рассмотрения.
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). Результаты неоднородные, и модель не всегда уверенно справляется с опечатками.
BioBERT не склонна выдавать сравниваемым текстам высокие значения сходства (около 0.5 на данных из первого теста). На этом фоне получается, что модель не распознала около половины терминов с опечатками, что указывает на посредственное качество обработки ошибок.
MedEmbed в прошлых тестах наоборот показывала тенденцию к завышению значений, со средним скором около 0.65 для релевантных текстов. В этом тесте примерно половина из 12 значений превысили порог, что также не говорит о высокой устойчивости к опечаткам.
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), но в целом модель имеет хорошую устойчивость к опечаткам.
ModernBERT-base, поскольку в прошлых тестах результаты модели были неадекватными, всерьёз оценить её работу в этом тесте невозможно.

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

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

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

Соберем набор специализированных терминов из медицинской области, включая как общеизвестные термины, так и редкие.
Преобразуем их в эмбеддинг-векторы, используя модели, участвующие в анализе.
Сравним полученные векторы с векторами из какого-нибудь доступного словаря (например, 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

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

OpenAI (text-embedding-3-large) продемонстрировала отличные результаты. Она единственная корректно связала термин "BBB disruption therapy" с "blood-brain_barrier" из WordNet. Термин "PD-L1 mAbs" правильно ассоциировала с "cancer_drug", отражая связь с лекарствами от рака. Точно обработала "Frey syndrome", связав его с "hyperhidrosis", что соответствует клиническому проявлению этого синдрома. Также успешно определила кластер лекарств для "Ozempic", связав его другими медикаментами для лечения диабета второго типа. Модель не справилась с терминами "Zolgensma" и "ReoPro", но сохранила ассоциацию с медицинским контекстом.
Voyage (voyage-large-2) показала средние результаты. Для "BBB disruption therapy" модель зацепилась за слово "therapy", но не смогла вытащить релевантные слова. Для "Frey syndrome" она извлекла лишь общие термины со словом "синдром", не учитывая специфики. В "PD-L1 mAbs" модель правильно распознала сокращение, но не ассоциировала его механизмом действия или назначением. Для "Ozempic" и "ReoPro" модель не смогла выделить ничего значимого, вытащив нерелевантные слова, такие как "otic", "zocor", "ream". В целом, Voyage справляется, но обрабатывает медицинские термины поверхностно.
Alibaba (gte-large-en-v1.5) проявила себя неоднородно. Например, она ассоциировала "BBB disruption therapy" с психотерапевтическими терминами ("implosion_therapy"), что является ошибкой. С "Antisense oligonucleotide" модель справилась неплохо, распознав молекулярные компоненты, и с "Waldenström Macroglobulinemia" — определив её как опухоль. Однако с "Ozempic" модель не смогла выдать полезные ассоциации, предложив термины из другого домена. "Zolgensma" также осталась для неё загадкой, так как среди ближайших слов оказались "zeugma" и "zygnema", не связанные с медициной.
Jina (jina-embeddings-v3) явно не ориентирована на медицинский контекст. Например, для терминов "lncRNA", "Ozempic", "Cladribine", "Zolgensma" и "ReoPro" она предложила слоги вместо осмысленных ассоциаций. С "BBB disruption therapy" модель также ошибочно вытащила психотерапевтические термины ("implosion_therapy"). Несмотря на это, она справилась с терминами вроде "Antisense oligonucleotide", "PD-L1 mAbs", и "Waldenström Macroglobulinemia", значительно уступая OpenAI и Voyage.
BioBERT, неожиданно для модели, обученной на медицинских данных, показал слабые результаты. Она не смогла корректно обработать большинство терминов, включая "BBB disruption therapy", где выдала совершенно нерелевантное "bobsledding". Видна тенденция к опоре на отдельные токены, например, для "Ozempic" и других лекарств. Для "Frey syndrome" модель предложила набор слов ("frey", "freyr", "freya"), что также указывает на её слабость в медицинском домене.
MedEmbed оказалась только чуть лучше BioBERT. Она сохраняет общую привязку к медицинскому домену, что делает её использование в этом контексте возможным, хотя с лекарствами, такими как "Ozempic" и "Cladribine", модель не справилась.
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, среди ближайших терминов все же оказались медицинские слова. В целом, модель показывает неплохое, но не выдающееся качество обработки медицинских терминов.
ModernBERT-base не работает: её ассоциации в более чем половине случаев выходят за рамки медицинского контекста. Например, вместо медицинских терминов модель предлагает слова вроде "bombastically", "queenfish", "frostwort", "schmaltz". Подобные результаты указывают на то, что модель не справляется с обработкой медицинского контекста.

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

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

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

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

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

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

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

Руководство по сборке шкафа IKEA,
Список лучших мест для пикников в Лондоне,
Инструкцию по ловле форели на искусственные приманки.

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

Вывод

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

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

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

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

во время обучения они могли не получить редкие данные,
они точно не «видели» новых данных, появившихся после их обучения.

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

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

Спасибо, что дочитали статью до конца! Если у вас есть вопросы или идеи, будем рады обсудить их в комментариях. А также спасибо Косте Шевченко за помощь с примерами и экспертное ревью биологических тестов.

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

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

Вдохновлено

Теги:

Хабы: