Печалби:
- Възможност за установяване на схеми и базирани на правила слоеве за валидиране на изхода
- Способност за смислено изискване на човек в цикъла при решения с голямо въздействие
- Възможност за проектиране на маршрутизация, базирана на проверка и праг на доверие с втория модел
Един езиков модел произвежда течен, убедителен и често точен, но „убедителен“ не е същото като „правилен“. Моделът може тихо да побере сума, дата или JSON поле; Това се нарича халюцинация (моделът уверено произвежда информация, която не съществува в действителност). В корпоративна система, ако този резултат премине към следващата стъпка - плащане, имейл, запис в база данни - грешката се пренася в реалния свят. В този модул ще се научим да филтрираме изхода със слоеве за проверка, преди да влезе в системата и да изискваме човек в цикъла при решения с голямо въздействие.
Защо се изисква валидиране на изхода?
Изходът на модела може да бъде повреден по два основни начина: формат (не съответства на очакваната JSON схема, полето липсва/излишно) и съдържание (форматът е правилен, но стойността е грешна — несъществуващ продуктов код, нелогична дата). Има и трето измерение по отношение на сигурността: злонамерен изход (злонамерена команда, създадена в резултат на инжектиране или изтичане). Здрава система спира и тримата на вратата.
Внимание: „Общо точен модел“ не е производствен критерий. В система без проверка дори една грешка на хиляда означава 100 грешни транзакции на ден при 100 000 заявки на ден.
Слоеве на удостоверяване: стъпка по стъпка
- Валидиране на схема. Проверете с машината дали изходът отговаря на очакваната структура: налични ли са полетата, правилни ли са техните типове, попълнени ли са задължителните полета?
- Валидиране на правило/бизнес логика. Съвпадат ли стойностите с бизнес правилата? (Сума > 0, датата не е в бъдещето, кодът на продукта принадлежи на каталога.)
- Контрол на препратки/източник. Ако моделът произвежда твърдение, може ли то да бъде свързано с източника? (Цитата RAG действително ли е в документа?)
- Валидиране с втория модел (LLM-as-judge). Независим модел оценява изхода като "правилен/непълен/рисков".
- Праг на доверие и ориентация. Ако моделът или валидаторът отчете ниска степен на достоверност, изходът не преминава автоматично; е насочен към хората.
- Човешки контрол. Резултатът с висока ефективност или с ниска безопасност зависи от одобрението на експерт.
Четири копируеми шаблона
Схема + "измисли си, ако не знаеш" заедно:
Върнете отговора САМО в следната JSON схема: Напишете „ниско“. НИКОГА не пишете оценка, сякаш е точна.
Проверка с втори модел (подкана за съдия):
Вие сте независим валидатор. По-долу има <source> текст и <claim>. Проверете дали ВСЯКО число и дата в твърдението се срещат дословно в източника. За всеки кажете: "проверено | не е в източника | противоречи на източника." Ако дори един от тях е „отсъстващ/конфликтен“, маркирайте резултата като „ИЗИСКВА СЕ ПРЕГЛЕД ОТ ЧОВЕК“.<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 схема + нула + поле за доверие
Писане на изхода директно в платежната система
Схема → правило → човешко одобрение (ако е необходимо)
Просто казвам на модела "бъди сигурен"
Валидиране на номер/дата с втори модел
Обработка на всеки изход с еднаква увереност
Маршрутизиране въз основа на влияние и доверие
Силният подход не се надява, че моделът е правилен; Създава врата, която ще ви хване, когато грешите.
Три мини калъфа
Случай 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) и маршрутизиране на прага на доверие.
- Човекът в цикъла трябва да бъде задължителен за изходи с голямо въздействие и ниска безопасност.
- Човешкият преглед трябва да е смислен: рецензентът трябва да има контекст, достъп до ресурси и правомощието да каже „не“.
- Както безопасността, така и ефективността се постигат чрез насочване към хората само на рисковите, а не на всеки изход.
Задача за приложение
Вземете пример от вашия собствен AI резултат. Първо дефинирайте JSON схема и принудете изхода към нея. След това напишете поне две бизнес правила (например „сумата съответства на общия брой елементи“). И накрая, създайте таблица за маршрутизиране: коя комбинация доверие/влияние отива автоматично, коя отива към втория модел, коя отива към човека? Генерирайте дефектна проба и наблюдавайте къде всеки слой я улавя.
контролен списък
- [ ] Дефинирам стриктна схема за изхода и я проверявам с машината.
- [ ] Добавих поне едно валидиране на бизнес/правила (логика на стойността).
- [ ] Мога да свържа твърденията с източника и да ги проверя.
- [ ] Наличен е втори модел или валидиране от хора за резултати с голямо въздействие/ниска безопасност.
- [ ] Правило за маршрутизиране, дефинирано въз основа на доверие и влияние.
- [ ] Рецензентът получава контекст, източник и пълномощия за отхвърляне.