Прибуток:
- Можливість встановлення рівнів перевірки вихідних даних на основі схем і правил
- Здатність суттєво вимагати участі людини в процесі ухвалення вагомих рішень
- Можливість розробки верифікації та маршрутизації на основі порогу довіри за допомогою другої моделі
Мовна модель створює плавний, переконливий і часто точний, але «переконливий» не те саме, що «правильний». Модель може мовчки вставляти суму, дату або поле JSON; Це називається галюцинацією (модель впевнено видає інформацію, якої не існує в реальності). У корпоративній системі, якщо цей вихід переходить до наступного кроку — платіж, електронний лист, запис у базу даних — помилка поширюється на реальний світ. У цьому розділі ми навчимося фільтрувати вихідні дані за допомогою верифікаційних рівнів перед тим, як вони потраплять у систему, і вимагати участі людини в циклі для прийняття важливих рішень.
Чому необхідна перевірка вихідних даних?
Вихідні дані моделі можуть бути пошкоджені двома основними способами: формат (не відповідає очікуваній схемі JSON, поле відсутнє/зайве) і вміст (формат правильний, але значення неправильне — неіснуючий код продукту, нелогічна дата). Існує третій аспект безпеки: зловмисний вихід (зловмисна команда, створена в результаті ін’єкції або витоку). Міцна система зупиняє всіх трьох біля дверей.
Застереження: «Загалом точна модель» не є виробничим критерієм. У системі без верифікації навіть одна помилка з тисячі означає 100 помилкових транзакцій на день на 100 000 запитів на день.
Рівні автентифікації: крок за кроком
- Перевірка схеми. Перевірте за допомогою машини, чи відповідає вихід очікуваній структурі: чи присутні поля, чи правильні їх типи, чи заповнені необхідні поля?
- Перевірка правила/бізнес-логіки. Чи відповідають цінності бізнес-правилам? (Сума > 0, дата не в майбутньому, код товару належить до каталогу.)
- Контроль посилань/джерел. Якщо модель створює твердження, чи можна його пов’язати з джерелом? (Чи насправді в документі є цитата RAG?)
- Перевірка за другою моделлю (LLM-as-judge). Незалежна модель оцінює результат як «правильний/неповний/ризикований».
- Поріг довіри та орієнтація. Якщо модель або валідатор повідомляє про низьку достовірність, вихідні дані не проходять автоматично; спрямована на людей.
- Контроль людини. Результат високої або низької безпеки залежить від схвалення експерта.
Чотири шаблони, які можна копіювати
Схема + «придумай, якщо не знаєш» разом:
Повертайте відповідь ЛИШЕ в такій схемі JSON: Напишіть "low". НІКОЛИ не пишіть оцінку так, ніби вона точна.
Перевірка з другою моделлю (підказка судді):
Ви незалежний валідатор. Нижче наведено текст <джерело> та <претензія>. Перевірте, чи КОЖНА цифра та дата в заяві дослівно зустрічаються в джерелі. Для кожного скажіть: "перевірено | не в джерелі | суперечить джерелу". Якщо хоча б один із них є «відсутнім/конфліктним», позначте результат як «ПОТРІБНА ПЕРЕГЛЯД ЛЮДИНОЮ».<source>{{ text }}</source><claim>{{ model_output }}</claim>
Правило маршрутизації порогового значення довіри:
Правило маршрутизації:- emin_misin = "високий" І сума < 10 000 TL -> автоматична обробка- emin_misin = "середній" АБО сума 10 000-100 000 TL -> друга перевірка моделі- emin_misin = "низька" АБО сума > 100 000 TL -> потрібне схвалення людини
Підсумкова картка людського аудиту (прискорює перегляд):
Представляючи рішення особі, подайте цю картку: - Що пропонується? (одне речення)- На основі якого джерела? (посилання на статтю/документ) - Які 2 найслабкіших припущення? - У разі схвалення, чи можна їх скасувати? (так/ні)
Слабка підказка / Сильна підказка
поганий підхід
Сильний підхід
«Відняти суму з рахунку-фактури» (вільний текст)
Сувора схема JSON + null + поле довіри
Запис вихідних даних безпосередньо в платіжну систему
Схема → правило → схвалення людини (за необхідності)
Просто кажу моделі "будь впевнена"
Підтвердження номера/дати з другою моделлю
Обробка кожного виходу з однаковою впевненістю
Маршрутизація на основі впливу та довіри
Сильний підхід не сподівається, що модель правильна; Це створює двері, які будуть ловити вас, коли ви неправі.
Три міні-чохли
Випадок 1 — однієї схеми виявилося недостатньо. Автоматизація бухгалтерського обліку витягувала суму з рахунків-фактур як JSON. Схема була правильною, але модель видала «125 000» замість «1 250,00» у рахунку-фактурі (десятковий зсув). Схема не змогла зафіксувати це; Перевірку правила ("сума має відповідати загальній кількості позицій рахунку-фактури на ±1%") було виявлено та попереджено неправильний запис 112 500 TL.
Випадок 2 — друга модель зафіксувала галюцинацію. «Повідомлення про розірвання за 30 днів», — сказав помічник з юридичної підтримки в резюме контракту; Проте в договорі було 90 днів. Коли незалежний суддя позначив модель як «конфліктну з джерелом», результат було передано людині та виправлено. Якби це було автоматично, клієнт сповістив би про скасування на основі неправильної дати.
Випадок 3 — маршрутизація зменшила навантаження на 70%. Система страхових претензій автоматично схвалювала претензії з низькими сумами та претензіями з високим рівнем безпеки та надсилала експерту лише претензії, що перевищували поріг/низькозабезпечені. З 3200 щоденних потреб лише 950 припадало на долю людей; експерти присвятили свій час справді ризикованим 30%, середній час транзакції скоротився з 4 годин до 40 хвилин.
Порада: не встановлюйте людський контроль так, щоб «люди могли все бачити» — це втомить людей і схвалення перетвориться на штамп. Замість цього перенаправляйте людині лише результати, що мають значний вплив і низьку достовірність; Це зосереджує увагу на тому, що дійсно важливо.
Зробити людський контроль значущим
Human-in-the-loop не означає поставити прапорець на папері. Рецензент повинен мати (1) контекст, щоб зрозуміти рішення, (2) доступ до джерела та (3) повноваження сказати «ні». В іншому випадку контроль залишається косметичним. Картка огляду (четвертий шаблон вище) призначена для надання саме цього контексту.
Поширені помилки
- Просто виконується перевірка схеми та пропускаються помилки вмісту/значення.
- Думаючи, що, кажучи моделі «переконайтеся», ви виконуєте справжню перевірку.
- Автоматично впроваджуйте результативні незворотні рішення.
- Встановлення людського контролю над кожним результатом і перетворення схвалення на безглуздий штамп.
- Сказати «схвалити» рецензенту без вказівки джерела та контексту.
- Обробка всіх виходів з однаковим ризиком без встановлення порогу довіри та маршрутизації.
Підсумовуючи
- Вихідні дані пошкоджуються трьома способами: формою, вмістом і зловмисним умислом; міцна система зупиняє всіх трьох біля дверей.
- Рівні: перевірка схеми, правила/бізнес-логіка, контроль джерела, друга модель (LLM-as-judge) і маршрутизація порогу довіри.
- Людина в циклі має бути обов’язковою для виходів із сильним ударом і низькою безпекою.
- Рецензування людьми має бути значущим: рецензент повинен мати контекст, доступ до ресурсів і повноваження сказати «ні».
- І безпеки, і ефективності досягається, якщо спрямовувати на людей лише ризиковані, а не всі результати.
Аплікаційне завдання
Візьміть приклад із ваших власних результатів ШІ. Спочатку визначте схему JSON і примусово виведіть її. Потім запишіть принаймні два бізнес-правила (наприклад, «сума відповідає загальній кількості елементів»). Нарешті, створіть таблицю маршрутизації: яка комбінація довіри/впливу переходить автоматично, яка переходить до другої моделі, яка переходить до людини? Згенеруйте несправний зразок і спостерігайте, де кожен шар його фіксує.
контрольний список
- [ ] Я визначаю сувору схему для виведення та перевіряю її за допомогою машини.
- [ ] Я додав принаймні одну перевірку бізнесу/правил (логіка значень).
- [ ] Я можу пов’язати твердження з джерелом і перевірити їх.
- [ ] Друга модель або перевірка людиною доступна для результатів високого впливу/низького рівня безпеки.
- [ ] Правило маршрутизації, визначене на основі довіри та впливу.
- [ ] Рецензенту надається контекст, джерело та повноваження для відхилення.