Laya — відкритий decision engine від Convai Innovations і одна з найзірковіших ML‑репозиторій вересня 2026. Це non‑autoregressive System 1: 421‑мільйонний енкодер читає текст і типізовані питання та повертає імовірності опцій за один прохід, без жодного згенерованого токена. У цьому матеріалі ми перевіряємо ці обіцянки на реальних мічених даних: банківський домен CLINC150. Міряємо zero‑shot проти простого класифікатора, вплив формулювань і порядку опцій, чесність імовірностей, температуру, браму відсікання, out‑of‑scope, упереджені так/ні та типізовані виходи pydantic. Відкрита відповідь на TypeSafe’s Jev — але як вона тримається в проді?
Що таке Laya і як працює однохідний вибір?
Коротко: Laya читає повідомлення і типи запитань, а повертає імовірності опцій за один forward‑pass. Вона не генерує текст і рахує нуль вихідних токенів. На вхід даєте вибір міток, шкалу або так/ні — і отримуєте розподіл. Це і є її швидкість і обґрунтована впевненість.
Ми ставимо реліз laya 0.3.27 і вантажимо англійський чекпойнт на зафіксованій авторами ревізії через laya.PINNED_REVISIONS. На CUDA Laya за замовчуванням кастує в half, тож ми вимикаємо це, щоб усі пристрої працювали у fp32. Так GPU відтворює показані CPU‑цифри. Все заради відтворюваності запуску.
Перша знахідка з температурою прилітає ще до інференсу. Запис для choice‑питань з 11+ опціями дорівнює 0.10, що поза валідним діапазоном, тож лоадер стискає до 0.5 і попереджає. Температура нижче одиниці загострює розподіл, тож відповіді з такою кількістю опцій виглядатимуть удвічі впевненішими за сирий стан моделі. Це важливо для будь‑яких рішень далі.
Одна подзвонка predict може відповісти на три різні типи запитань про тікет підтримки: відділ як вибір, терміновість як шкала 0–2, і ризик відтоку як так/ні. У результаті є імовірність для кожної опції та два схожі поля впевненості. answer_confidence — це імовірність обраної відповіді. А confidence — це одиниця мінус нормалізована ентропія, яка залежить від числа опцій. Не плутайте їх, бо метрики й брами дивляться саме на answer_confidence.
Скільки коштує прохід і як це впливає на дизайн питань?
Ціна проста: кожне запитання — окремий рядок у батчі. Шістнадцять так/ні коштують приблизно у вісім разів довше за одне так/ні. Усі опції одного choice ділять один рядок і його head‑бюджет. Тому сорок опцій ледве вдвічі дорожчі за три опції і приблизно у чотири рази дешевші за шістнадцять так/ні на нашому CPU. Отже, краще одне питання‑вибір з багатьма опціями, ніж багато бінарних.
Перш ніж іти далі, ми перевіряємо це правилом дизайну на реальному маркованому наборі. Беремо CLINC150 з Hugging Face Hub у parquet та фокусуємося на банківському домені: 15 інтенцій з розбиттям 100/20/30 на train/val/test. Ми питаємо Laya маршрутизувати 450 тестових запитів zero‑shot, даючи кожній інтенції назву і стислий опис, який би написав розробник.
Результат вражає для нуля навчальних прикладів: 0.804 точності у zero‑shot. Для масштабу, простий TF‑IDF + логістична регресія дає 0.651 з трьома прикладами на інтенцію, 0.848 з десятьма і 0.904 з тридцятьма. Одна подача Laya вже близько до сильнішого бейслайну з помітним етикетуванням.
І так, це все ще один прохід без жодного згенерованого токена. Хіба не цього ви хотіли від системи рішень? Але що стається, якщо змінити лише слова в опціях або їхній порядок? Чи не зрушуємо ми відповідь випадково?
Чому формулювання опцій і їхній порядок змінюють відповіді?
Пряма відповідь: короткі «голі» назви інтенцій працюють краще за описи. Коли ми забираємо наші однорядкові описи і лишаємо лише назви, точність підскакує з 0.804 до 0.878. Час також майже ділиться навпіл, бо опції займають менше половини токенів. Менше слів — менше плутанини.
Опис розмив близькі інтенції, які назви лишають окремими. account_blocked не раз переїжджав у freeze_account — десять разів. Питання про відсоткову ставку часто залітали у balance. Ці дрібниці у формулюваннях вартують відсотків точності й зайвих мілісекунд. Висновок простий: тестуйте саме ті слова, які підете у продакшн.
Порядок опцій також має вагу. Реверс bare‑списку змінює 4.2% окремих відповідей, хоча загальна точність ледь рухається. Це натяк на позиційний пріор. Не довіряйте інтуїції — довіряйте розміченим даним і фіксуйте порядок на етапі валідації. Потім не змінюйте його в проді.
Звідси ми рухаємося далі тільки з bare‑назвами. Це не вгадування — це перевірений факт на нашому спліті. Хочете зекономити токени й час? Скажіть коротко. Хочете стабільності? Зафіксуйте порядок, який протестували. Хіба це не очевидно після цих цифр?
Чи чесні імовірності «з коробки» і як їх калібрувати та відсікати?
Коротко: «як є» вони завищені для наших 15‑опційних питань. Це якраз кошик choice:11+, де відвантажена температура затиснута до 0.5. На 450 тестових запитах 92% відповідей заявляють впевненість не нижче 0.9, але з них права 91.1%. Середня впевненість 0.974, вище за точність 0.878. Очікувана помилка калібрування — 0.102. Отже, міряйте на власних лейблах.
Далі ми підганяємо температуру на валідаційних даних. Збираємо 300 записів сирих логітів і таргетів, викликаємо fit_temperatures і отримуємо choice‑температуру 1.258. Але автопідбір замінює всю мапу: кожен bucket зникає без 2,000 записів, а score і так/ні скидаються до 1.0, бо їх не бачили. Одне налаштування для choice тихо змінює калібрування інших типів. Ми відкотилися до відвантажених значень і поставили тільки виміряний bucket.
На тесті помилка калібрування падає з 0.102 до 0.059 без зміни точності, бо температура не міняє переможця. save_calibration пише JSON, який laya.load зможе підняти. Це акуратна, локальна правка, яка робить імовірності корисними для порогів і договорів про помилки. Не те щоб магія — радше санітарія.
Що з брамою відсікання? fit_abstention_thresholds на тих самих валідаційних записах для 5% бюджету помилки вибирає 0.602. Це лишає 95.7% валідаційних запитів із 4.5% помилки, і predict_batch сам відсікає нижче min_confidence, помічаючи 35 з 450 тестових як «утрималися». Але на тесті брама тримає 92.2% запитів із 9.2% помилки — майже удвічі вище бюджету. При 2% цільової помилки виходить 5.3%. Рейтинг сам по собі добрий: найвпевненішу половину відповіді модель вгадує у 97.8% випадків. Просто бюджет тримається лише на схожому трафіку. І так, пороги лишаються покошиково за числом опцій.
Out-of-scope: брама чи явна «інша» опція?
Реальний трафік містить запити поза доменом. Ми додаємо 150 out‑of‑scope CLINC‑запитів і 150 з інших доменів CLINC. Калібрована впевненість їх добре розділяє: банківські запити мають у середньому 0.912, інші — близько 0.25. Брама на 5% бюджеті зупиняє 89.3% запитів з інших доменів і 93.3% out‑of‑scope, утримуючись лише на 7.8% банківських.
Альтернатива не потребує лейблів: шістнадцята опція «не банківський запит». Вона ловить 80.0% інших доменів і 90.0% out‑of‑scope. Ціна — 2.0% банківських ідуть убік і точність по банкінгу падає з 0.878 до 0.864. Додавання опції змінює контекст оцінювання для кожної інтенції. Пам’ятайте про це перед запуском.
Що краще у проді? Брама дає сильніше відсіювання чужого трафіку за нашого спліту. «Інша» опція простіша, але з’їдає частку core‑точності. Ваш вибір залежить від метрики ризику і навантаження на людей. Маєте власні лейбли? Поміряйте обидва варіанти й зафіксуйте правила.
У всіх випадках ключове — чесна шкала впевненості. Саме вона дозволяє провести кордон між in‑scope і out‑of‑scope й не переплутати безпечне «утрималися» з небезпечним «помилилися». Без калібрування цього кордону просто немає.
Так/ні, schema та практичні висновки: чого температура не виправить?
Перевірка «у межах домену?» як окреме так/ні здається природною. Ми питаємо, чи повідомлення про банківський рахунок, рахунки або платежі. Рейтинг хороший: AUROC 0.945. Але є упередження в «ні»: банківські запити мають середню імовірність лише 0.361, і за дефолтного порога 0.5 впізнаємо 28.9% з них. Температура тут безсила.
Ми підбираємо температуру на 550 валідаційних відповідях, і вона впирається у стелю 5.0. На порозі 0.5 це нічого не змінює, бо поділ двох логітів на будь‑яку температуру не міняє, який більший. Температура лагодить шкалу, а не зсув. Що працює? Сприймати імовірність як скор і вибрати поріг на лейблах. 0.09 на валідації дає 92.0% recall і 83.0% specificity на тесті.
Нарешті, підключаємо це до застосунку через pydantic‑схему. decide_batch перетворює Literal на choice по bare‑назвах, а bool — на так/ні, і проектує відповіді назад у валідовану модель. Якщо передати браму як min_confidence, невпевнена інтенція стає None, і Optional це приймає — явний сигнал «спитати людину». Два out‑of‑scope повертаються як intent=None.
Втім, булеве всередині decide ріжеться фіксовано на 0.5, тому репорт про шахрайство при 0.29 позначається як in_scope=False. Правильна відповідь з’являється лише тоді, коли ми читаємо імовірність із деталей і застосовуємо поріг 0.09. Саме так і треба чинити з бінарними питаннями у Laya.
«Калібрована модель рішень — це та, яку ви відкалібрували, на власних лейблах і для власних питань».
Підсумок простий. Laya виконує більшість обіцянок: один прохід відповідає на кілька типізованих питань без генерації токенів, bare‑маршрутизатор досягає 0.878 на 15 банківських інтенціях без навчальних прикладів, а калібрована впевненість добре відділяє in‑scope від out‑of‑scope, зупиняючи понад дев’ять з десяти чужих запитів. Але цінність імовірностей залежить від вашої роботи: відвантажена температура для 11+ опцій загострює, one‑liner калібрування тихо стирає інші типи, бюджет помилки з валідації не переноситься без запасу, а так/ні може опинитися з «правильного» боку лише після власного порога. Усе це латається кількома рядками — якщо ви міряєте на власному трафіку.
На основі матеріалу the Laya tutorial.
