Впевненість Jev

Перетворюйте ймовірності на пороги дії, перевірки чи ескалації.

Відповіді Choice і Score містять розподіл probabilities та показник confidence від 0 до 1. У Noul його немає. Впевненість визначається формою розподілу: зосередженість на одному результаті означає впевнену відповідь, а розпорошеність — невпевнену. TypeSafe обчислює confidence, щоб можна було застосовувати пороги без власних розрахунків, але ви завжди отримуєте повний набір probabilities, якщо потрібен інший показник. За цими числами код має діяти, передавати на перевірку або ескалувати.

Впевненість обчислюється з імовірностей

Для Choice розподіл — це probabilities за вашими варіантами. Для Score — розподіл за рівнями. Що рівномірніший розподіл, то нижча впевненість. Низька впевненість Choice часто означає, що жоден варіант явно не переважає. Для Score вона часто вказує на неоднозначні чи багатовимірні рівні або на недостатність даних у стані.

TypeSafe надає confidence як зручний типовий показник, але не прив’язує вас до нього. Залежно від рішення може краще підійти інший спосіб зведення розподілу. Такі рецепти винесено в окрему збірку, а кожна відповідь Choice і Score усе одно містить probabilities, тож ви не обмежені однією формулою.

Відповіді Noul містять noul у діапазоні [0, 1], і це все. Поля confidence, яке можна перенести на Noul, немає. Значення близько 0.5 означає, що модель не визначилася з відповіддю на запитання «так/ні». Не тлумачте 0.5 як «середню інтенсивність вимоги повернення коштів». Не переносьте поріг confidence із Choice на noul і не очікуйте, що P(noul) + P(not noul) дорівнюватиме 1 для двох окремих запитань.

Confidence gates: act, review, or escalate using probabilities
Дійте, перевіряйте або ескалюйте за ймовірностями. Noul не має окремого поля confidence.

Три шляхи у вашому коді

Корисна початкова схема має три діапазони. Висока впевненість: діяти автоматично. Середня: діяти обережно — отримати підтвердження користувача, позначити для перевірки або зібрати більше даних про стан. Низька: не діяти. Передати людині, поставити уточнювальне запитання або перейти на іншу систему. Межі залежать від наслідків.

Поріг упевненості не може бути одним числом для всього продукту. Помилково показаний екран балансу через неправильно визначений намір — виправна ситуація. Помилкове схвалення виведення коштів — ні. У прикладі TypeSafe 0.5 є межею справжньої невизначеності, а для підтвердження й виконання переказу потрібно >0.9; водночас для наміру перевірити баланс достатньо нижчого порога. Код відображає вашу терпимість до ризику. Jev лише повідомляє розподіл.

Якщо інтелектуальна система не здатна чесно виражати невпевненість, їй не можна довіряти. Для Choice і Score таким сигналом є впевненість. Враховуйте її разом з обмеженнями jaggedness: буквальне формулювання, обчислення в коді та жодної генерації. Choice з високою впевненістю, але погано складеною інструкцією — це все одно впевнена відповідь на неправильне запитання.

Noul проти Choice для того самого звернення

Запис jaggedness від TypeSafe для інваріантів здорового глузду містить звернення «Мене не влаштовує посадка. Які в мене тут варіанти?». На запит Noul «Клієнт просить повернути кошти?» отримано 0.22. Choice із відповіддю «так/ні» для того самого формулювання повернув імовірності: так — 0.01 / ні — 0.99, з упевненістю 0.97. Порівнювати слід noul і probabilities["yes"], але вони не взаємозамінні.

Для другого звернення сума двох Nouls — повернення коштів і відсутність повернення — становила 1.19. Не вимагайте від моделі дотримання арифметичних тотожностей між окремими запитаннями. Choice з варіантами дає відносну оцінку: який саме варіант. Кожен Noul абсолютний, і всі варіанти можуть мати низькі значення. У рецепті рекомендації навичок застосовано обидва: Choice вибирає навичку, а Nouls визначають, чи варто взагалі щось рекомендувати.

Налаштовуючи пороги, зазначайте примітив у таблиці. «0.8» нічого не означає без уточнення: 0.8 confidence Choice для department чи 0.8 Noul для urgency. Записуйте в журнал примітив, ключ, необроблені probabilities і версійний ідентифікатор моделі jev-1.13.0, щоб подальша зміна псевдоніма непомітно не переналаштувала робочі пороги.

Робота з порогами

Зберігайте повний набір probabilities, а не лише argmax і скаляр confidence. Якщо результат Choice здається хибним, варіант на другому місці часто підказує причину. Якщо Score застряг між рівнями, розподіл покаже, чи неоднозначна шкала, чи порожній стан.

Після кожної зміни ідентифікатора моделі переналаштовуйте пороги. jev-latest може змінитися. Поріг 0.9 для jev-1.13.0 нічого не гарантує в наступному офіційному випуску. Перш ніж перемикати робочі псевдоніми, тиждень ведіть тіньовий журнал того, як спрацював би новий ідентифікатор.

Для дій із високими ризиками потрібні і мітка, і мінімальна впевненість, а потім підтвердження на рівні продукту. У прикладі переказу від TypeSafe 0.5 використано як межу невизначеності, а 0.9 — як поріг перед виконанням. Запозичуйте схему, а не обов’язково числа. Для повернення коштів і блокування в грі пороги будуть різними. У робочому регламенті записуйте числа поруч із назвою примітива.

Не приховуйте probabilities від чергової команди. Панель, де confidence показано лише зеленим або червоним, не повідомить, що yes і no помінялися місцями, хоча впевненість лишилася високою. Основний результат — розподіл; скаляр лише для зручності обчислюється поверх нього системою TypeSafe.

Для запитання «так/ні» значення Noul біля 0.5 чесно означає «не знаю». Поля confidence до нього не додають. Якщо потрібна друга вісь, поставте друге запитання або додайте Choice з варіантами yes/no/not-sure та явними критеріями, враховуючи, що це інший показник, ніж noul.

Щотижня будуйте графік confidence для кожного ключа запитання. Повільне зміщення до 0.5 означає, що критерії більше не відповідають зверненням. Стрибок до 1.0 у черзі з шумними даними означає, що варіанти злилися, а не що світ став простішим.

Записуйте jev-1.13.0 поруч із кожним порогом, щоб зміна псевдоніма не сховалася в тижневому графіку.

Джерела