У фільмі «Люди в чорному 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% випадків.
Розпізнавання того, чого система не знає, залишається частиною роботи.
Швидкість потребує такої ж уваги. В окремому тесті на «прогрітому» CPU повний банківський класифікатор займав приблизно 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 MiB ресурсів моделі плюс його середовище виконання.
Локальне виконання все одно має свою ціну. Розмір завантаження, пам'ять, час запуску та продуктивність пристрою — все це треба враховувати при оцінці.
Продукт, який я маю на увазі, вбудовується в існуючий додаток, де він вирішує, що буде далі.
Розробник визначає категорії, надає репрезентативні приклади, підключає пункти призначення та обирає, що робити, коли класифікація неоднозначна.
Перше розгортання має спостерігати за поточним робочим процесом, не змінюючи його результат. Потім ми зможемо порівняти запропоновані рішення з перевіреними результатами, перш ніж дозволити класифікатору керувати маршрутизацією.
Нам потрібно перевіряти прийняті помилки так само ретельно, як і відхилені запити. Інакше впевнене, але хибне рішення може зникнути за заспокійливим високим балом.
Навчання, калібрування та тестування також потребують окремих даних. Навчання формує категорії. Калібрування обирає правила прийняття. Захищений тест перевіряє заморожений результат.
Щойно помилка з тесту впливає на наступну модель, цей приклад стає даними для розробки. Для наступної оцінки потрібен свіжий тест.
Маленький прибулець у сортувальній машині дає людям спосіб уявити цю роботу. Створення корисної версії означає з'ясувати, які саме вхідні дані вона здатна обробити, коли їй слід просити допомоги та чого коштують її помилки.
Наступний крок — репрезентативний робочий процес з незалежними мітками та записом кожного результату. Нам треба виміряти, скільки запитів ідуть локальним шляхом, скільки потрапляють до іншої моделі, скільки йдуть не так, і чи стає весь додаток швидшим або дешевшим після врахування цих помилок.
Час масштабуватися та дати цій локальній моделі трохи стероїдів.
