Jevjitsu: или как мы пробовали обобщенные классификаторы на всем

Классификация — одна из старейших задач в машинном обучении. В отличие от современных декодирующих трансформеров, большинство моделей классификации по своей природе не были авторегрессионными. До появления Jev распространенными подходами были обучение собственного классификатора, для которого нужны размеченные данные, использование zero-shot классификатора (сравнение приведено в этом бенчмарке Hugging Face) или промптинг LLM с добавлением некоторой «хакерской» проверки типов. Существовали также мета-ML методы, но ни один из них не стал мейнстримом.

С появлением Jev, модели принятия решений от TypeSafe, предоставляемой через OpenRouter, таксономия классификаторов снова изменилась:

Существуют две фундаментальные идеи, которые проливают свет на прогресс Jev:

• Jev — это следующий шаг к тому, чтобы сделать модели пригодными для использования без обучения под конкретную задачу. Предобученные трансформеры означали, что вам больше не нужно обучать модель с нуля для каждой задачи, а LLM позволяют описать то, что вы хотите. Jev сохраняет принцип «опиши, а не обучай», решая при этом проблемы, которые делают LLM неудобными для классификации: медленные ответы, высокие затраты и ответы вне заданных вами вариантов.
• Концептуальный сдвиг в восприятии подхода «LLM Is All You Need». В последнее время стандартом было пытаться применить LLM ко всему. Jev — это часть движения в сторону конкретных методов. Даже если базовая концепция все еще использует архитектуру трансформера, ограничения и перспективы для конечного пользователя сильно отличаются.

Поскольку Jev может справиться с любой задачей классификации, мы протестировали его на нескольких. К настоящему моменту все уже протестировали его в качестве переранжировщика (reranker), и мы тоже, но самое интересное началось потом: как переранжировать лучше, как чтение запроса перед поиском помогает и что будет, если заставить Jev разбивать документ на части. Вот что мы ожидали, что нас удивило и что мы попробуем дальше. Все эксперименты находятся в many-jev-recipies репозитории, если вы хотите запустить их самостоятельно.

Переранжирование

Гибридный поиск обычно находит полезные результаты. Более сложная часть — это порядок: разница между лучшим ответом на седьмой позиции и более слабым на первой может быть слишком тонкой для первого этапа, поэтому нужен «более умный кузен», переранжировщик, чтобы расставить кандидатов по порядку. LLM-судьи достаточно умны для этой работы, но слишком медленны и дороги для запуска на каждом запросе. Jev здесь подходит идеально: он возвращает числовые оценки без генерации текста, поэтому они сразу сортируются, и ничего не нужно парсить.

Мы попробовали три способа запроса:

На данный момент тестирование Jev в качестве переранжировщика на нескольких сотнях запросов — это практически обряд посвящения. Каждый поисковый вендор запускает его на 80, 100, 200 или 300 запросах, публикует таблицу и идет дальше. Поэтому мы, естественно, сделали то же самое: 100 NFCorpus запросов, топ-30 и топ-50 кандидатов из Qdrant с BGE-small, каждый метод, плюс два локальных кросс-энкодера для сравнения, переупорядочивающих тех же кандидатов. Таблица показывает прирост nDCG@10 каждого метода по сравнению с одним только BGE-small:

Мы ожидали, что самый дорогой метод, итеративный, победит с большим отрывом. У него был самый высокий балл, но лишь с небольшим преимуществом: все три метода Jev обошли BGE-small на обеих глубинах, а разрыв между ними составил менее 0.02. Большие усилия не всегда дают лучший результат, поэтому дешевые варианты выигрывают: Score — наш выбор по умолчанию, а итеративный метод не стоит десяти запросов на один поиск. Полное сравнение, включая кросс-энкодеры, находится в ноутбуке по переранжированию.

Оба кросс-энкодера показали меньший прирост, чем любой из методов Jev, а bge-reranker-base вообще не улучшил показатели BGE-small. Jev позволяет нам адаптировать вопрос о релевантности без обучения новой модели. Кросс-энкодеры предлагают локальное выполнение и могут быть быстрее или дешевле. Что именно выбрать, зависит от того, как вы взвешиваете гибкость, качество, задержку и стоимость. Но переранжирование — это только начало: суждения Jev могут направлять и другие поисковые решения.

Уменьшение повторяющихся ответов

Представьте себе поиск в интернет-магазине по запросу «iphone», который выдает десять вариантов одного и того же iPhone 18. Иногда это именно то, что нужно покупателю, но часто они предпочли бы видеть ассортимент товаров на первой странице.

Мы измерили это на 240 отложенных запросах из WANDS бенчмарка, оценивая релевантность (nDCG@10) и повторения: пары почти дубликатов, результаты, чьи эмбеддинги схожи на 0.95 или более, на первой странице из 10. Классы товаров учитывают различные категории продуктов в топ-10 результатов. Это помогает понять, видят ли покупатели полезный ассортимент товаров или в основном вариации одного и того же.

Переранжирование с помощью Jev улучшило релевантность, но оставило почти дубликаты на месте и снизило разнообразие товаров. Даже сортировка по человеческим меткам релевантности сузила страницу до 2.66 классов товаров. Релевантные результаты все равно могут быть повторяющимися.

Встроенный в Qdrant механизм Maximal Marginal Relevance (MMR) работает иначе: при коэффициенте разнообразия 0.5 он удаляет почти дубликаты и дает наиболее широкую страницу, но стоит 0.12 nDCG@10, потому что измеряет релевантность как векторное сходство с запросом.

Решением стало использование оценки переранжировщика в качестве сигнала релевантности для разнообразия: либо заменить член релевантности в MMR на ответ Jev, либо сначала запустить MMR в Qdrant, а затем позволить Jev переранжировать его топ-20. Оба варианта превзошли гибридный поиск по релевантности и повторениям, жертвуя частью прироста от простого переранжирования ради более разнообразной страницы. На этом наборе данных простое переранжирование дало сильнейшую релевантность; комбинация Jev с MMR уменьшила повторения, сохранив релевантность выше базового уровня гибридного поиска. Полное сравнение находится в ноутбуке по прунингу.

Понимание запроса

Покупатель, вводящий «замена кухонного смесителя», хочет сантехнические детали, и распознавание этой категории может улучшить результаты. Мы следовали главному правилу из экспериментов Дага Тернбулла: фильтровать только тогда, когда есть полная уверенность, потому что неверный фильтр скрывает полезные товары; в противном случае — повышать рейтинг соответствующих товаров.

Мы ожидали, что эта часть заработает «из коробки», но выбор названий категорий из товаров почти не дал прироста. Что помогло, так это кластеризация товаров, использование дешевой LLM для именования каждой группы и использование Jev для проверки названий. Точные проверки находятся в notebook.

С этого момента ничего не генерируется, только классифицируется:

• Во время индексации Jev помечает каждый товар этими категориями, которые сохраняются как полезная нагрузка (payload): чехол для Nintendo Switch получает категорию «чехлы для устройств» в разделе «Электроника и аксессуары».
• Во время поиска Jev оценивает каждую категорию товара относительно запроса. При значении 0.9 или выше поиск фильтруется по этой категории. От 0.5 до 0.9 он повышает рейтинг соответствующих товаров. Ниже этого значения он ничего не делает.

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

Мы сравнили настройки на 300 Amazon-C4 поисковых запросах, и эта комбинация фильтрации и повышения рейтинга сработала лучше всего:

Маршрутизация таксономии Jev в поисковых запросах Amazon-C4300, чем выше, тем лучше nDCG@10 (x100) Уровневый По умолчанию Только повышение Только фильтр 0 10 20 30 40 Гибридный поиск С таксономией Jev

Jev добавляет от половины секунды до двух секунд на запрос, в зависимости от того, сколько категорий он считывает. Небольшие классификаторы, обученные на тегах товаров Jev, обработали 37% запросов только с повышением рейтинга, пропуская Jev с немного более высоким средним nDCG@10. Подробности приведены в разделе 6 .

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

Фильтрация работает, когда категория полностью соответствует намерению. Короткие запросы более неоднозначны, и фильтр вредит им больше всего: как только он удаляет товары, MMR не может вернуть их обратно. Есть две идеи, которые мы еще не протестировали. Одна из них — повышение веса вместо фильтрации для запросов из одного или двух слов. Другая — предоставление Jev большего контекста, например, «apple», отправленное вместе с магазином, в котором оно было введено, скажем, "shop": "electronics". В любом случае, уверенное предсказание категории все равно может не угадать, что нужно покупателю. Урок заключается в том, чтобы проверить свои собственные запросы и граничные случаи, прежде чем внедрять даже самое уверенное решение.

Семантическая нарезка (Semantic Chunking)

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

Что, если бы Jev оценивал каждый промежуток между предложениями? Мы отправляем ему окно из пронумерованных предложений из документа, сокращенное здесь до четырех из статьи QASPER:

Для каждого промежутка мы спрашиваем, начинает ли следующее предложение новую тему, где новая тема означает «начинается новый раздел, история, вопрос или тема». Для предложения 2 вопрос звучит так: «Начинает ли предложение 2 новую тему?» Jev вернул вероятность «да» 0,97 для этого заголовка раздела, за которой последовали 0,13 и 0,03 для следующих двух предложений.

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

Мы протестировали это на 407 научных статьях QASPER и 1297 вопросах с абзацами-доказательствами, отмеченными исследователями. Для каждого вопроса Qdrant извлекал пять фрагментов из статьи. Мы измерили, сколько доказательств они содержали и сколько несвязанного текста они несли, используя полноту, точность и пересечение по объединению (IoU) на основе символов.

При сопоставимых средних размерах фрагментов Jev улучшил все три метрики по сравнению с алгоритмами с фиксированным размером, рекурсивными и основанными на эмбеддингах. Средний относительный прирост составил 13,0% по IoU, 11,2% по точности и 9,1% по полноте. Каждый 95% доверительный интервал исключал ноль. Мы ожидали скромного улучшения и получили его с первой попытки, без настройки вопроса. Вот один пример:

Компромисс заключается в стоимости и простоте: другие алгоритмы нарезки работают локально бесплатно, в то время как Jev отправляет ваш текст в API по цене около $0,27 за миллион токенов документа. Наименьший прирост был по сравнению с рекурсивным разделителем, который сначала разбивает по пустым строкам, поскольку ответы QASPER — это целые абзацы. Перефразирование вопроса может еще больше улучшить фрагменты. Реализация и полное сравнение находятся в notebook.

Что мы бы попробовали в первую очередь

Для RAG начните с алгоритма нарезки: его легко настроить, и он не создает накладных расходов во время запроса. Для поиска товаров попробуйте объединить оценки релевантности Jev с MMR, чтобы уменьшить повторения, сохраняя релевантность выше гибридного базового уровня.

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

Мы бы пока пропустили итеративное переранжирование: десять запросов на один поисковый запрос дали лишь небольшой прирост в нашем эксперименте.

Резюме

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

Индустрия изучает ту же идею с помощью API Decisions API от OpenAI и подходов с открытым исходным кодом, таких как OpenJev, JevLite и CLM.

Найдите в своем конвейере решение, которое стоит улучшить, а затем проверьте, делает ли Jev его лучше по приемлемой для вас цене. Наши дадут вам отправную точку.