Моделі Jev і System One: Калібрування перевершує точність

Минулого тижня TypeSafe AI випустив те, що він називає своєю першою «моделлю System One», Jev. Це модель, де немає ні балачок, ні писань, ні покрокових міркувань. Дайте відповіді на структуровані запитання про вхідні дані за один прохід вперед і дайте ймовірність кожної відповіді. Більшість матеріалів присвячені швидкості. Більш цікаве твердження калібруванняТому що калібрування — це те, що таємно обмежує кожен класифікатор продуктів, який я постачав, включно з описаним у документі COMPSAC.

Ця публікація — моя спроба з’ясувати, що Jev насправді змінює, де він вписується в реальний стек машинного навчання та як я планую перевірити його заяви, а не просто вірити їм.

Згідно зі статтею про випуск TypeSafe, Jev побудовано на трьох ідеях.

1. Неавторегресійний вихід. Звичайний LLM генерує відповіді один маркер за раз, і кожен маркер залежить від останнього. Jev виводить всю структуровану відповідь одразу. TypeSafe оцінює від 70 до 500 мілісекунд від кінця до кінця, «у 40-200 разів швидше», ніж Frontier LLM для порівнянних завдань.¹
2. Введені запитання, а не підказки. ти, стан (текст, структуровані дані або історія повідомлень) і набір запитання. Кожне запитання є одним із трьох типів: вибір (виберіть із набору й отримайте ймовірності для кожного варіанту), Оцінка (оцінювання за впорядкованими рівнями, отримання безперервних балів і розподілів), або Ноул (Так/Ні, повертається як ймовірність того, що твердження є істинним).² Усі запитання в запиті оцінюються паралельно, тому додавання додаткових питань дуже незначно змінює затримку.
3. Навчання коректурі. Модель навчається за допомогою того, що TypeSafe називає підкріпленням для узгоджених рішень (RLCD). Заявлені цілі є «епістемічно чесними ймовірностями», а не людськими уподобаннями чи перевіреними цілями винагороди, до яких адаптується модель чату.¹

Обмеження так само важливі, як і функціональність. Jev не може створити довільний текст. Питання з кількома варіантами відповідей підтримують до 255 варіантів. Ще не введено зображення. Ціна становить 0,042 долара за мільйон вхідних токенів, вихідні токени безкоштовні, а доступ наразі здійснюється за листом очікування.¹

Отже, GPT не малий. Це більше схоже на дуже швидкий і дуже поширений табличний класифікатор, який читає неструктурований вхід і повертає введене рішення, яке вважається надійним.

Це частина моєї власної статті, яку я читаю знову і знову. Ми передбачили, чи буде об’єднано запит на отримання, використовуючи лише сигнали, доступні на момент подання. F1 випадкового лісу становив 0,958. Базовий рівень для класу більшості, який «об’єднав» усе, досяг 0,957. Цифрою, яка відокремлює дійсно корисні моделі від непотрібних, було ROC-AUC. Це було 0,676 у лісі та 0,500 у базовій лінії. І навіть у цьому випадку я чітко написав, що модель «не слід розглядати як повністю відкалібровану імовірнісну модель» і підходить для сортування, а не для автоматизованих рішень щодо прийняття/відхилення.³

Це явище не характерне для одного набору даних. Це звичайна форма для виробничих класифікаторів.

• Точність насичується рано. У незбалансованих задачах більша частина доступної точності вільна. Складна частина – це рейтинг і впевненість.
• Логіка низхідної течії вимагає ймовірностей, а не міток. «Направити це замовлення на перевірку вручну, якщо достовірність моделі менше 80%» працює, лише якщо 80% означає 80%. Якщо ваша модель показує 0,95 за правильність у 70% випадків, тоді всі встановлені вами пороги є брехнею.
• Помилки калібрування невидимі для звичайних показників. F1, точність і навіть AUC є пороговими або ранговими показниками. Модель може мати хорошу AUC, але погану калібрування, і ви не дізнаєтесь про це, доки створені на її основі бізнес-правила не почнуть працювати неправильно.

Стандартні модифікації пост-хок: шкала Платта, ізотонічна регресія, температурна шкала. Вони працюють, але є ще одним відповідним компонентом, який змінюється в міру коливань даних. Те, що Джев стверджує, якщо я правильно це прочитав, це те, що ймовірності вже є чесними з моделі, оскільки чесність була метою навчання. Якщо це застосувати до завдань поза межами власних тестів TypeSafe, це видаляє цілий шар клею з виробничих систем ML.

Це «що, якби» — ось суть питання, і це можна перевірити.

Я працюю над ML в галузі оптової торгівлі. Там дуже мало чату. Більшість із них — це невеликі ітераційні рішення між двома системами.

Шаблон чіткий. Скрізь, де магістратури справді добре працюють; Класифікується за носінням костюма чатумодель System One є розумною альтернативою з меншою затримкою та вартістю на два порядки. Це розумна заміна правилам, якщо у вас є написані від руки правила, які постійно порушуються, оскільки введення є вільним текстом. Усюди, де ваша робота полягає в генерації чи оптимізації, це неправильний інструмент, і сам TypeSafe це говорить.

Історія інтеграції ERP також захоплююча. моделі повертаються Зумійте сісти протягом 100 мілісекунд внутрішній шлях запиту. LLM, які повертають абзаци протягом 4 секунд, повинні бути розміщені поруч із абзацом у черзі. Ця різниця визначає, чи є ML функціями чи пакетним завданням.

Деякі з презентаційних матеріалів варто прочитати з певним скептицизмом.

«Нуль ілюзій» TypeSafe може це гарантувати Тип виведення завжди дійсний. Якщо ви запитаєте будь-яку з 5 категорій, ви отримаєте одну з 5 категорій із ймовірністю того, що сума дорівнює 1. Це вірно та корисно, і режим структурованого виведення LLM лише наближає її. Однак обрана категорія правильно. Відповідь, яка є впевнено неправильною в дійсній схемі, все одно є неправильною відповіддю. Чесне кадрування означає «нуль помилок схеми», а калібрування покриває решту.

Для якого розподілу проводиться калібрування? Навіть якщо модель добре налаштована на основі тренувань і еталонних розподілів, вона може погано дрейфувати в реальному світі. Калібрування є властивістю моделі і Набір даних. Єдині цифри, яким я можу довіряти, це ті, які виміряні на основі моїх даних.

Базова лінія для порівняння. Це правда, що це в 200 разів швидше, ніж LLM для класифікації, але це також трохи несправедливо. Тому що LLM не є хорошою базою для багатьох із цих завдань. Це підсилене градієнтом дерево інженерних функцій, яке також займає менше мілісекунди та є безкоштовним. Цікавим порівнянням є тристороннє порівняння класичних табличних моделей, LLM як класифікатора та Jev з точки зору точності, ранжирування, калібрування, затримки та вартості того самого завдання.

У мене вже є правильний тестовий стенд. Це канал прийняття PR з моєї статті. У нас є загальнодоступна базова модель дерева, яка враховує витоки, 5-кратно виправлена ​​та має відомі недоліки калібрування. Ось дизайн.

завдання. Те саме, що й RQ1 у документі: укажіть PR під час подання, щоб передбачити, чи буде його об’єднано чи закрито без об’єднання. джеб стан Ті самі метадані подання та дельта-статистика, на які посилаються PR-заголовок, тіло та дерево, серіалізуються як текст. Ніщо, що з’являється після подання (коментарі, CI, пізніші коміти), не потрапляє в стан. Оскільки модель нова, правила витоку не послаблюються.

запитання. один Ноул: один варіант для «Цей запит на отримання буде об’єднано». вибір Перегляньте теги наміру завдання (виправлення, функція, рефакторинг, документація), щоб побачити, чи власна інтерпретація наміру Джева відповідає правилу ключових слів.

базова лінія. Випадковий ліс паперу (400 дерев), той самий ліс із ізотонічним калібруванням, підігнаним шляхом згортання, і Frontier LLM поставили ті самі запитання зі структурованим виходом.

Метрики. Ранжування та калібрування не лише для F1:

• Оскільки це ROC-AUC, результати еквівалентні наведеним у статті.
• бал бріарасередня квадратична помилка ймовірності результату:

$$\textS_b = \frac\sum_{i=1}^{N}\left(\hat{p}_i – y_i\right)^2$$

• Очікувана помилка калібруваннярозділіть прогнози за достовірністю та виміряйте, наскільки точність кожного біну відрізняється від зазначеної достовірності.

$$\text{ECE} = \sum_{b=1}^{B} \frac{|S_b|}{N}\,\Big|\,\text{acc}(S_b) – \text{conf}(S_b)\,\Big|$$

• Діаграма надійності по моделях, оскільки один номер ECE прихований де Модель занадто або недостатньо самовпевнена.
• Середня затримка, p95 і вартість за 1000 PR.

Що б змінило мою думку? Jev відповідає AUC лісу; відкалібрований Якщо ви створюєте ліс на Brier і ECE без будь-якої пост-гоц підгонки, вимоги щодо калібрування будуть реальними в дистрибутиві, якого TypeSafe ніколи не бачив, і почнуть переміщувати виклики LLM для формату класифікації, над яким ви там працюєте. Якщо ви можете перемогти неналаштований ліс, але не налаштований ліс, це зручність, а не функціональність. Якщо AUC значно нижчий, швидкість не є проблемою.

У будь-якому випадку, цифри будуть опубліковані, і я їх тут прив’язую.

Якщо ви вирішуєте, чи піклуватися про Джеба прямо зараз, ось моя порада:

1. Інвентаризуйте свої дзвінки LLM. позначте кожен генерувати або вирішити. з вирішити є кандидатом. З мого досвіду, в основному це так.
2. Виміряйте калібрування тим, що у вас уже є. Обчисліть Brier та ECE поточного класифікатора. Якщо вони погані, Єв може вам допомогти з проблемою. Якщо проблем немає, це здебільшого питання затримки та вартості.
3. Не пропускайте класичну басову лінію. Посилене градієнтом дерево на пристойній функції – це смуга. Нова модель має перевершити її за даними на основі правил витоку, інакше це не оновлення.
4. Розглядайте «скоригований» як гіпотезу. Перевірте свої бізнес-правила на дистрибутиві, перш ніж робити їх залежними від нього.

Ідея моделі System One обґрунтована. Більшість рішень, які програмне забезпечення вимагає від ML, невеликі, структуровані та чутливі до затримки, а модель чату є дивним інструментом для програмного забезпечення. Чи зможе Джев виконати свою обіцянку щодо вичитки, це емпіричне питання. У мене є набір даних, щоб відповісти на це питання, і я маю намір це зробити.

Я хотів би порівняти нотатки, якщо у вас є позначений набір даних класифікації з доступом Jev і відомими проблемами калібрування. Моя контактна інформація знаходиться на головній сторінці.