Maxim.ML - канал

BERTScore vs косинус: лайфхак для подготовки к конференции с помощью алгоритмов RAG-а

Недавно готовился к выступлению на AhaConf, а это, на минуточку, 70+ спикеров и 1000+ слушателей. Сразу возникает классическая проблема: как сделать свой доклад уникальным и не повторить то, что уже рассказали до тебя?

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

Зачем вообще искать похожие доклады?

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

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

2️⃣Нетворкинг. Заранее вычислить «своих» по духу и темам. С таким списком можно подходить в кулуарах не с банальным «чем занимаешься?», а с конкретным «слушай, видел твой доклад про X, у меня как раз очень похожий кейс»

План эксперимента: старый добрый косинус против BERTScore

Мой план был прост:

1️⃣Собрать данные: выгрузить все названия и описания докладов

2️⃣Измерить близость: прогнать каждый доклад через два фильтра для сравнения с моим - старую добрую косинусную близость и более «вдумчивый» BERTScore

3️⃣Проанализировать топ-5 от каждого метода и посмотреть, какие доклады попали в топ

Что получилось

И вот тут-то и проявилась вся разница подходов

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

BERTScore. Этот подход работает на более детальном уровне, сопоставляя контекстные эмбеддинги каждого токена из одного текста с токенами другого. На основе этой матрицы попарных сходств он вычисляет метрику F1, что позволяет улавливать локальные семантические связи, например, между «ML-платформой» и «автоматизацией ресурсов», даже при отсутствии общих ключевых слов. (подробнее в оригинальной статье «BERTScore: Evaluating Text Generation with BERT»). Но из-за циклично расчета эмбедингов время получения метрики растет в разы

Главный вывод: дилемма близости в RAG - скорость или глубина?

Мой эксперимент отлично подсветил классический компромисс в мире RAG: выбор между скоростью и семантической глубиной. Здесь нет однозначного победителя, потому что косинусная близость и BERTScore решают разные задачи

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

Если бы кто-то придумал «быстрый BERTScore», это бы кардинально изменило подходы к поиску релевантных чанков в RAG. Мы бы получили поиск, который по-настоящему понимает запрос. Но пока приходится жить в мире компромиссов

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

Please open Telegram to view this post