В фильме «Люди в чёрном 2» агент Джей навещает Кей в самом обычном на вид почтовом отделении. Он открывает машину для сортировки писем, а внутри обнаруживается инопланетянин, который молниеносно раскладывает корреспонденцию.
Сцена нелепая, но она даёт нам полезную метафору для размышлений об ИИ.
Между получением чего-либо и действием с этим чем-то часто нужно принять небольшое решение: куда это отнести?
Если принять его правильно и сразу, остальная часть системы пойдёт по нужному пути.
Я часто вспоминаю этого маленького пришельца, когда разрабатываю ИИ-софт.
Приложение получает вопрос о биллинге, баг-репорт, фотографию товара и запрос на бронирование демо. Каждому нужен свой подход. Но мы почему-то просим одну и ту же большую языковую модель проверять всё подряд и решать, что делать дальше. Это ни эффективно, ни экономично.
Поэтому я считаю, что специализированные модели будут играть гораздо большую роль в будущем ИИ. Например: Jev создан для структурированных решений, которые может обработать программа. Coinbase адаптировала Qwen3.5-9B специально для обнаружения мошенничества в своём сервисе Onramp. Каждая модель решает чёткую задачу с измеримым результатом.
https://x.com/brian_armstrong/status/2109412046244913643
Я строю слой сортировки
Знакомые запросы могут сразу уходить в готовый сценарий. Те, что требуют больше рассуждений, передаются другой модели. Неоднозначные помечаются для уточнения или ручной проверки.
Экономия достигается за счёт того, что каждый запрос получает ровно столько вычислительных ресурсов, сколько ему нужно. Затем нужно измерить, достаточно ли часто сортировщик принимает верные решения, чтобы оправдать своё существование.
Мы начали с CludeMem. Пытались понять, что ИИ должен запоминать, что извлекать, а что просто тратит токены впустую. Постоянное предпочтение, временная инструкция и нерешённый вопрос требуют разного подхода. Но прежде чем принимать такие решения, информацию нужно классифицировать.
Так появилась идея более широкого слоя классификации. Тот же шаг помогает отсортировать обращение в поддержку, направить документ или выбрать специалиста для задачи.
GIF
Чем больше появляется специализированных моделей, тем чаще приложениям придётся решать, какие входные данные заслуживают их внимания. Именно эту часть мы и создаём: классифицировать входящее, обрабатывать знакомые случаи локально, а сложные передавать подходящей модели или на проверку.
Встречайте Clude Cat (Cat — от слова categorisation 😉)
Прежде чем сохранить воспоминание, найти документ, вызвать инструмент или сгенерировать ответ, обычно нужно решить, с каким типом информации мы имеем дело.
Такие решения встречаются повсюду.
Представьте, что кто-то пишет в софтверную компанию:
«Где я могу скачать свой счёт?»
ИИ-агент мог бы прочитать сообщение, проверить свои инструменты, оценить намерение клиента и решить поискать счёт.
Более прямой сценарий выглядел бы так:
Сообщение → запрос платёжного документа → проверка аккаунта → получение счёта.
Языковая модель всё равно могла бы написать ответ. А вот начальное решение о маршрутизации можно было бы принять локально.
Теперь изменим сообщение:
«С меня списали деньги дважды, мой аккаунт заблокирован, и я хочу всё отменить».
Уверенно отправлять такое в сценарий для работы со счетами — значит создавать себе лишнюю работу. Здесь несколько проблем, и для правильного ответа может потребоваться уточнение или живой человек.
Сортировщику нужно дать право сказать: «Я не могу надёжно это классифицировать».
Это важнейшая часть продукта. Система, которая уверенно отправляет запросы не туда, сведёт на нет всю свою скорость работой над исправлением ошибок.
Для клиента выгода очевидна: меньше ожидания и повторений.
Для разработчика — это явное решение, которое можно проверить, протестировать и изменить. Он видит выбранную категорию, версию модели, время обработки и то, отказалась ли система принимать решение.
Под капотом текстовая реализация начинается с небольшой предобученной модели — энкодера.
Она превращает сообщение в список чисел, отражающих аспекты его смысла. Разработчики называют такое представление эмбеддингом.
«Где мой счёт?» и «Мне нужна копия квитанции» используют разные слова. Но их числовые представления могут быть достаточно похожими, чтобы система распознала один и тот же тип запроса.
Слой классификации использует эти представления, чтобы оценивать категории, заданные разработчиком.
Мы реализовали два подхода. Один сравнивает входящее сообщение с примерами каждой категории. Другой обучается находить границы между категориями на размеченных примерах.
В подходе с дообучением (fitted) мы оставляем энкодер неизменным и обучаем лишь небольшой решающий слой поверх него. Нам не нужно тренировать новую базовую модель для каждого приложения.
Разработчику всё равно придётся определить смысл категорий и связать их с полезными действиями. Классификатор не придумает сам отделы компании, политику возвратов или права доступа к аккаунту.
Ему также нужна политика принятия решений.
Категория с наивысшим баллом всё равно может не подходить. Две категории могут набрать почти одинаковые баллы. Незнакомый запрос может показаться похожим на знакомый.
Наши текущие локальные оценки — это не откалиброванные вероятности. Балл 0,92 не означает автоматически «вероятность правильности 92%».
Нужно тестировать, что происходит, когда эти оценки управляют решениями.
Поэтому результат разделяет принятую категорию, запрос, требующий проверки, и технический сбой. Таймауты, отмены и ошибки модели тоже должны обрабатываться предсказуемо.
В этом и заключается инженерия вокруг сортировщика. Она определяет, сможет ли другое приложение безопасно и стабильно использовать результат.
Мы провели эксперимент на 770 банковских запросах, чтобы проверить, может ли этот подход снизить нагрузку на генеративные модели.
В первой конфигурации каждый запрос отправлялся на классификацию в локально работающую модель Qwen2.5 7B.
Во второй сначала использовался наш локальный классификатор, а неразрешённые запросы уходили в Qwen.
Результаты:
- Количество вызовов Qwen упало с 770 до 227.
- Число верных классификаций выросло с 535 до 642.
- Точность по всем запросам поднялась с 69,5% до 83,4%.
- Суммарное измеренное время обработки упало с 299,7 секунды до 87,7 секунды.
Локальный этап позволил избежать 543 вызовов Qwen — снижение на 70,5%.
Кэширование оставалось включённым, а прямой подход запускался перед комбинированным. Время указано без учёта настройки и прогрева. Мы измеряли только классификацию, без генерации финальных ответов клиенту и оплаты провайдеру модели.
Эти цифры описывают конкретную конфигурацию. Они не доказывают превосходство над любой LLM и не гарантируют экономию для клиентов.
В другом, отдельном эксперименте мы проверили дообученный локальный классификатор на 24 намерениях из сферы путешествий и работы.
Из 720 запросов он обработал локально 688. Из них 681 оказался верным, а семь — ошибочными. 32 запроса были отправлены на проверку.
Это даёт нам два разных показателя:
- Покрытие: локально обработано 95,6% запросов.
- Точность принятых: 99,0% принятых решений оказались верными.
Оба показателя важны. Классификатор мог бы добиться впечатляющей точности, принимая лишь горстку самых простых запросов.
Мы также протестировали 100 000 незнакомых входных данных, которые должны выходить за рамки поддерживаемых категорий. Точность составила более 94%.
Умение распознавать то, чего система не знает, остаётся частью работы.
Скорость требует такого же внимания. В отдельном тесте на прогретом процессоре полный банковский классификатор обрабатывал один запрос примерно за 1,8 миллисекунды (медиана) на M4 Max. Это включает токенизацию, создание эмбеддинга и оценку.
Загрузка и запуск модели в расчёт не брались. Это измерение именно классификации, а не времени на полное решение проблемы пользователя. И это не гарантирует такой же производительности на телефоне или обычном ноутбуке.
Jev вписывается в эту тему, потому что уже решает схожий класс задач.
TypeSafe описывает Jev как модель для ограниченных суждений, включая выбор из предложенных вариантов и маршрутизацию запросов в обычный код, к специализированным моделям или людям. \Документация Jev по маршрутизации намерений\
Роль Jev, как я её вижу, — это опциональный путь эскалации для запросов, которые локальный классификатор не может надёжно обработать.
Архитектура, к которой мы стремимся, проста:
Входящий запрос → локальная классификация → знакомые запросы идут по заданному пути; сомнительные переходят к Jev, другой модели или человеку.
Без Jev тот же этап локальной классификации может возвращать неразрешённые запросы в существующую LLM приложения, на этап уточнения или на ручную проверку.
Разработчик управляет категориями, порогами принятия и запасным вариантом. Он может внедрить локальный классификатор в рабочий процесс и измерить, какие решения тот способен взять на себя.
Сегодня интеграция с Jev работает в теневом режиме: она сравнивает решения по пяти широким темам, не меняя поведение приложения. Следующий шаг — проверить, улучшает ли выборочная эскалация весь процесс целиком. Приведённые выше результаты Qwen — это не бенчмарк Jev.
Именно это нам и нужно измерить: меньше ненужных вызовов модели, более быстрая обработка знакомых запросов и чёткий путь для случаев, требующих повышенного внимания.
Мы начали применять тот же подход к изображениям.
Представьте бизнес, который получает чек, скриншот ошибки и фотографию товара. Каждому нужен свой путь обработки.
Чек уходит на извлечение данных. Скриншот попадает в сценарий поддержки. Фотография товара — в сценарий каталогизации. Непонятное изображение отправляется на проверку.
Классификатор выбирает пункт назначения. Считывание итоговой суммы, диагностика ошибки и определение характеристик товара остаются отдельными задачами.
Наша экспериментальная реализация для изображений использует предобученный энкодер CLIP для создания числового представления картинки.
Дообученный исследовательский кандидат верно классифицировал 19 из 20 фотографий продуктов питания в небольшом диагностическом тесте. А все 30 изображений листьев фасоли он отправил на проверку.
Единственная ошибка: панель с пищевой ценностью и штрихкод на бутылке были классифицированы как чек.
Проблема понятна. И то, и другое содержит плотный текст, цифры и прямоугольную компоновку. Нам нужны примеры, которые научат систему различать границы, важные именно для нашего приложения.
Этой выборки слишком мало для заявлений о готовности к продакшену. Метки были взяты из датасета, а не оценены независимо, и в тесте не было свежих примеров чеков или скриншотов. Публичное демо использует отдельную базовую модель, поэтому результаты дообученного кандидата нельзя приписывать ему.
Обработка изображений оказалась тяжелее классификации текста. Медианное время на прогретой системе составило около 36 миллисекунд в Node и 197 миллисекунд в Chromium на M4 Max. Браузеру сначала нужно загрузить около 85 МиБ файлов модели плюс среду выполнения.
Локальное выполнение тоже имеет свою цену. Размер загрузки, потребление памяти, время запуска и производительность устройства — всё это нужно учитывать при оценке.
Продукт, который я представляю, встраивается в существующее приложение и решает, что произойдёт дальше.
Разработчик задаёт категории, предоставляет характерные примеры, подключает пункты назначения и выбирает, что делать при неуверенной классификации.
Первый запуск должен просто наблюдать за текущим процессом, не меняя его результатов. Затем мы сможем сравнить предлагаемые решения с проверенными результатами, прежде чем разрешить классификатору управлять маршрутизацией.
Ошибки, которые система приняла, нужно изучать так же тщательно, как и отклонённые запросы. Иначе уверенно неверное решение просто спрячется за высоким баллом.
Для обучения, калибровки и тестирования нужны отдельные данные. Обучение задаёт категории. Калибровка выбирает правила принятия. Защищённый тест проверяет замороженный результат.
Как только ошибка из теста влияет на следующую модель, этот пример становится данными для разработки. Для следующей оценки потребуется свежий тест.
Маленький пришелец в сортировочной машине помогает людям представить эту задачу. Но чтобы создать полезную версию, нужно точно выяснить, какие входные данные она способна обработать, когда ей следует просить о помощи и во что обходятся её ошибки.
Следующий шаг — репрезентативный сценарий с независимыми метками и фиксацией каждого результата. Нам нужно измерить, сколько запросов идёт по локальному пути, сколько попадает в другую модель, сколько обрабатывается неверно, и становится ли всё приложение быстрее или дешевле с учётом этих ошибок.
Пора масштабироваться и накачать эту локальную модель стероидами.
