Многие дата-саентисты (data scientists) привыкли рассматривать косинусное сходство (cosine similarity) как универсальную «волшебную палочку» для сравнения векторных представлений. Мол, берём два вектора, вычисляем косинус угла между ними и получаем простое число от –1 до 1. И будто бы чем ближе к 1, тем сильнее сходство. Но, как в античном мифе о царе Мидасе, который превратил всё вокруг в золото (даже то, что не стоило превращать), слепое применение косинусного сходства порой ведёт к неожиданно плачевным результатам.
Однако мифы существуют не просто так: они учат нас осторожности и напоминают, что любая «золотая» методика может внезапно обернуться проблемами. Ниже я поделюсь своим взглядом на то, почему нужно относиться к косинусному сходству аккуратнее, какие технические детали помогают избежать подводных камней и почему иногда «классический» подход лучше дополнить другими методами.
Короткая притча о Мидасе и векторах
Царь Мидас был счастлив, когда приобрёл способность превращать всё в золото, пока не понял, что даже еда и вода превращаются в драгоценный металл и становятся непригодны для жизни. Похожее «проклятие» постигает и нас, когда мы начинаем видеть во всём векторные представления и сразу применять к ним косинусное сходство. На первый взгляд решение кажется универсальным и элегантным, но на практике становится ясно, что оно «всё превращает в одно и то же», игнорируя нюансы и специфические цели задачи.
В чём магия косинусного сходства?
Прежде всего косинусное сходство действительно обладает рядом привлекательных черт:
🧩 Оно даёт значение от –1 до 1: легко интерпретировать результат и, кажется, можно анализировать его как «процент схожести».
🧩 Лёгкость в расчётах: при единичной нормировке векторов (т. е. при одинаковой длине) косинусное сходство сводится к обычному скалярному произведению.
🧩 Универсальность: применимо для картинок, текстов, звуковых фрагментов, да практически чего угодно — лишь бы были вектора.
Но как и любое «универсальное» решение, оно даёт только один «ответ на всё», зачастую не учитывая контекст, семантику и реальную цель задачи.
Пример с тремя предложениями
Иллюстрация из оригинального блога показывает три фразы:
- (A) «Python can make you rich.» - Python может сделать вас богатым.
- (B) «Python can make you itch.» - Python может заставить вас чесаться.
- (C) «Mastering Python can fill your pockets.» - Овладение Python может наполнить ваш кошелек.
По смыслу (если вы не испытываете аллергию на деньги) A ближе к C. Однако если взглянуть на лексическую схожесть, B почти идентично фразе A, ведь отличаются всего две буквы. И только векторизация (например, с помощью современных эмбеддингов) выстраивает «логические связи» между A и C, поскольку они говорят примерно об одном: о том, что Python может принести финансовую выгоду.
Но дальше всё упирается в то, какие именно вектора мы используем и какую метрику берем для финального сравнения. Косинусное сходство здесь «отрабатывает» довольно корректно, хотя разница между 0.750 (A–C) и 0.576 (A–B) говорит лишь «кто-то поближе, кто-то подальше» — без абсолютных гарантий, что это именно нужная нам семантическая близость.
Где кроются проблемы?
🤔 Нет чёткого понимания масштаба. Косинусное сходство часто воспринимают как «вероятность», но число 0.6 не говорит однозначно «это похоже» или «это не похоже». Ведь модель не «училась» подгонять свои вектора строго под эту метрику.
🤔 Разные задачи — одна метрика? Иногда мы сравниваем вопросы и ответы, а косинусное сходство уделяет больше внимания сходству в стиле и орфографии, а не содержанию. «Что я сделал со своими ключами?» может быть ближе по вектору к «Что я сделал со своей жизнью?», чем к «Я оставил их в кармане». Формально оба — вопросы, значит, похожи по структуре.
🤔 Модель может не знать о косинусном сходстве. Если обучение шло на другой функции потерь (например, сигмоиде или MSE), то у нас фактически нет гарантии, что нормализация векторов приведёт к корректным результатам.
🤔 Не тот «тип» сходства. Сходство может быть тематическим, эмоциональным, языковым, стилистическим и т. д. Косинусное сходство даёт один усреднённый результат, стирая тонкие различия.
Как обойтись без «золотой ленты»?
Главный инсайт: если задача требует действительно специфического сравнения, лучше обучить свой подход или хотя бы задать для эмбеддингов правильный контекст.
🛠 Использовать LLM напрямую. Можно просить саму модель (GPT-подобную) отвечать на вопрос: «Похож ли текст A на B?». Тогда вся сложность перекладывается на большие языковые модели. Но платить (как в прямом, так и во временном смысле) придётся много, особенно при поиске по большим базам.
🛠 Тонкая настройка эмбеддингов. Вместо того чтобы брать универсальный вектор, можно обучить преобразование (fine-tuning или transfer learning). Например, если вы сопоставляете вопросы и ответы, делайте два разных преобразования (для вопросов и для ответов) и сводите их в общее пространство уже по своей функции потерь.
🛠 Промпт-инжиниринг. Вы можете «переупаковывать» текст перед эмбеддингом. Допустим, задача — определить национальность исторических личностей. Тогда встраивайте эту национальность прямо в текст (или используйте хитрое форматирование), чтобы модель «замечала» нужные детали.
🛠 Дополнительная предварительная обработка (preprocessing). Можно просить модель переписывать текст в нейтральном стиле с сохранением только фактов. Это помогает, когда вы не хотите, чтобы стилистические вещи вроде опечаток или разметки Markdown влияли на результат.
Личный взгляд: когда всё-таки достаточно косинусного сходства
Разумеется, косинусное сходство по-прежнему остаётся в моём «инструментарии по умолчанию». Для быстрого измерения «похоже / не похоже», особенно если я точно знаю, как обучался эмбеддер, это действительно удобный способ. Но если проект становится сложнее, задача приобретает неоднозначность, а «0.6» уже не помогает понять, подходит ли документ по смыслу, то пора двигаться дальше.
Как правило, чем больше в нашей задаче нюансов, тем осторожнее нужно применять косинусное сходство. Иногда «заводской» эмбеддинг уже хорошо натренирован на конкретный тип задач (например, поиск похожих документов), и тогда «косинус» работает отлично. Но бывает, что нужны другие метрики (евклидово расстояние, манхэттенское, какая-нибудь своя функция), или вовсе стоит перейти к более специфическим ML-моделям.
Заключение
Косинусное сходство — это «скотч», который выручает во множестве ситуаций, когда надо всего лишь что-то «склеить» между собой. Но, как и в случае со скотчем, им не стоит чинить трубы в доме, если вы не хотите потом крупной протечки.
Альтернативы же есть:
🔍 Настраивать эмбеддинги под задачу — через обучение или хотя бы корректный промпт.
🔍 Использовать LLM напрямую — если у вас небольшие наборы текстов и важна высокая точность.
🔍 Переформатировать тексты (rewrite, extract) — избавляться от «лишнего шума», стараясь вывести сходство по фактам, а не по лексическим украшениям.
Как говорил бы Мидас, если бы сам писал блог про машинное обучение: «Не всё золото, что косинус близко к единице».
Ссылки на оригинал и обсуждение
Спасибо за внимание! Если вы пробовали какие-то хитрые техники с косинусным сходством — делитесь в комментариях. Помните: иногда «скотч» действительно спасает, но полагаться только на него небезопасно.