Практический тест ColBERT и MUVERA: когда сложные поисковые архитектуры уступают простой нарезке

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

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

Красивая идея и её цена

Логика работы классического плотного поиска выглядит довольно грубо: текстовый документ целиком прогоняется через нейросетевую модель и сжимается в единый вектор фиксированной длины. Если в документе содержится десяток абзацев, а поисковый запрос релевантен лишь одному из них, итоговый вектор описывает материал лишь «в среднем», из-за чего нужная информация растворяется. Архитектура ColBERT предлагает принципиально иной подход без этапа глобального усреднения. Здесь каждый отдельный токен документа обретает собственный вектор, а во время поискового запроса система сопоставляет каждый токен запроса с наиболее близким токеном из документа, суммируя полученные максимальные значения. Подобная концепция получила название позднего взаимодействия, или late interaction.

Главным препятствием на пути массового внедрения становится стоимость хранения таких индексов. Обычный плотный вектор одного документа занимает около четырех килобайт, тогда как детальная матрица токенов ColBERT для документа средней длины требует уже порядка ста пятидесяти килобайт. В масштабах корпоративной базы на миллион записей разница колоссальна: четыре гигабайта против ста сорока. В качестве компромиссного решения была разработана технология MUVERA, которая сжимает объемную матрицу мультивектора в единый длинный вектор фиксированного размера. Это позволяет быстро отбирать первичных кандидатов, выполняя ресурсоемкий точный расчет только для узкого подмножества документов. Сочетание высокой скорости и глубокого анализа казалось идеальным решением.

Для проверки эффективности я подготовил четыре размеченных датасета: русскую и английскую версии Википедии из бенчмарка MIRACL, коллекцию российских кодексов и научные аннотации SciFact, суммарно охватывающие около трех тысяч запросов. В качестве прямого конкурента выступал стандартный плотный поиск на базе мультиязычной модели multilingual-e5-large. Чтобы соблюсти корректность сравнения, я сопоставил габариты моделей: e5-large и jina-colbert-v2 насчитывают 560 и 559 миллионов параметров соответственно, являясь прямыми аналогами.

Метрика, которая чуть не соврала

Первые результаты оказались разочаровывающими: метрика recall@10, отражающая долю запросов, при которых правильный документ попадал в первую десятку выдачи, не продемонстрировала заметного роста ни на одном из тестовых наборов. Логичный вывод о нецелесообразности внедрения технологии напрашивался сам собой. Ситуацию изменил анализ базовых показателей. На юридических кодексах стандартный плотный поиск и так находил релевантный документ в топ-10 в 93.7% случаев. Когда исходная точность находится на столь высоком уровне, традиционная метрика упирается в потолок, и отсутствие видимой разницы между методами свидетельствует лишь о ее нечувствительности к деталям.

Пересчет результатов по метрике recall@1, оценивающей попадание правильного ответа строго на первую позицию, кардинально изменил картину. На тех же кодексах базовый плотный поиск успешно справлялся в 70.5% случаев, а применение архитектуры ColBERT обеспечило статистически значимый прирост в 4.7 пункта. Эффект, который едва не остался незамеченным при оценке широкой выдачи, на первой позиции проявился в полной мере. Тем не менее, аналогичный детальный анализ на русской Википедии показал, что там ColBERT, напротив, ухудшил качество выдачи. Итоговый баланс по четырем тестовым доменам оказался неоднозначным: один набор продемонстрировал улучшение, один — ухудшение, а два других не показали статистически значимой разницы.

Две причины вместо одной

Глубинный анализ причин такого поведения выявил несколько интересных нюансов. В официальной документации к моделям Jina часто утверждается, что их версия ColBERT значительно превосходит классический алгоритм BM25 на всех языках бенчмарка MIRACL. Однако подобные сравнения обычно противопоставляют архитектуру позднего взаимодействия устаревшим алгоритмам подсчета совпадений или моделям первого поколения, а не современным мощным энкодерам вроде e5, обученным на колоссальных массивах данных. Более того, современные схемы обучения современных плотных моделей уже вобрали в себя многие преимущества продвинутых стратегий дистилляции знаний.

Второй фактор кроется в особенностях мультиязычного обучения. В тестах на англоязычном корпусе SciFact мультиязычная модель jina-colbert-v2 уступила специализированной англоязычной модели answerai-colbert-small, которая уступает ей по числу параметров почти в семнадцать раз. Показатель recall@1 у компактной специализированной модели составил 64.7%, в то время как крупная мультиязычная система остановилась на отметке 58.3%. Очевидно, что универсальные мультиязычные решения в рамках конкретного языка могут проигрывать узкоспециализированным аналогам.

Гипотеза, которая была слишком хороша

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

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

Истинная причина крылась в другом: сжатый вектор MUVERA строится на основе случайных проекций без предварительного обучения на задачах релевантности. Жесткий контрольный эксперимент показал, что крошечная обученная модель e5-small, чей вектор весит в десятки раз меньше структуры MUVERA, справляется с первичным отбором кандидатов значительно эффективнее за счет того, что ее пространства признаков целенаправленно оптимизированы для поиска. Тем не менее, MUVERA таит в себе неочевидную ловушку: эффективность ее работы сильно зависит от общего размера корпуса документов, причем падение качества на крупных базах происходит незаметно для оператора.

Скучная идея

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

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

Где плотная модель слепнет

Логично предположить, что архитектуры вроде MUVERA и ColBERT востребованы лишь в тех редких случаях, когда стандартные плотные модели бессильны. Для проверки этой гипотезы я использовал нестандартные данные — скомпилированный байткод пяти тысяч функций стандартной библиотеки Python, записанный в виде сырых шестнадцатеричных последовательностей. Стандартная модель e5 на таких данных практически полностью теряла работоспособность, выдавая корректный результат лишь в 6% случаев, в то время как ColBERT успешно справлялся с задачей в 97% тестов.

Тем не менее, даже в этой узкой нише альтернативные подходы продемонстрировали высокую конкурентоспособность. Классический алгоритм BM25, настроенный на поиск по триплетным последовательностям инструкций без применения нейросетей, обеспечивал точность на уровне 94–96%. Это подтверждает, что реальная ниша технологий позднего взаимодействия значительно уже рекламных заявлений: они эффективны на специфических цифровых артефактах, химических формулах, геномных последовательностях или материалах на редких языках, где стандартные семантические пространства бессильны. Однако во многих подобных сценариях предварительный анализ с помощью символьных n-грамм позволяет добиться сопоставимых результатов с минимальными затратами ресурсов.

Что с этим делать

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