Добивки:
- Способност да се воспостават слоеви за валидација на излезот заснован на шема и правила
- Способност значајно да се бара човек во јамката при одлуки со големо влијание
- Способност за дизајнирање верификација и рутирање базирано на праг на доверба со вториот модел
Јазичниот модел произведува течен, убедлив и често точен - но „уверливото“ не е исто што и „точно“. Моделот може тивко да собере износ, датум или поле JSON; Ова се нарекува халуцинација (моделот самоуверено произведува информации што не постојат во реалноста). Во претпријатието систем, ако тој излез тече на следниот чекор - плаќање, е-пошта, пишување база на податоци - грешката се прелева во реалниот свет. Во оваа единица, ќе научиме да го филтрираме излезот со слоеви за верификација пред да влезе во системот и да бараме човек во јамката при одлуки со големо влијание.
Зошто е потребна валидација на излезот?
Излезот на моделот може да се оштети на два основни начини: формат (не е во согласност со очекуваната шема JSON, полето недостасува/вишокот) и содржина (форматот е точен, но вредноста е погрешна - непостоечки код на производот, нелогичен датум). Постои трета димензија во однос на безбедноста: злонамерен излез (злонамерна команда произведена како резултат на инјектирање или истекување). Цврст систем ги запира сите три на вратата.
Внимание: „Моделот генерално точен“ не е производствен критериум. Во систем без верификација, дури и една грешка во илјада значи 100 погрешни трансакции дневно во 100.000 барања дневно.
Слоеви на автентикација: чекор по чекор
- Потврда на шемата. Проверете со машината дали излезот е усогласен со очекуваната структура: дали се присутни полињата, дали се точни нивните типови, дали се пополнети потребните полиња?
- Валидација на правило/деловна логика. Дали вредностите се совпаѓаат со деловните правила? (Износ > 0, датумот не е во иднина, кодот на производот припаѓа на каталогот.)
- Контрола на референца/извор. Ако моделот произведува тврдење, дали може да се поврзе со изворот? (Дали цитатот на RAG е всушност во документот?)
- Валидација со вториот модел (LLM-as-judge). Независен модел го оценува излезот како „точен/нецелосен/ризичен“.
- Праг на доверба и ориентација. Ако моделот или валидаторот пријави ниска доверба, излезот автоматски не поминува; е насочена кон луѓето.
- Човечка контрола. Високомоќен или нискобезбеден исход зависи од одобрението на експертот.
Четири шаблони за копирање
Шема + „направи ако не знаеш“ заедно:
Вратете го одговорот САМО во следната шема JSON: Напишете „ниско“. НИКОГАШ не пишувајте проценка како да е точна.
Потврда со вториот модел (програма на судијата):
Вие сте независен валидатор. Подолу е текстот <извор> и <claim>. Проверете дали СЕКОЈ број и датум во тврдењето се појавуваат дословно во изворот. За секој, кажете: "проверено | не е во изворот | противречи на изворот." Ако дури и еден од нив е „отсутен/конфликтен“, означете го резултатот како „Потребен е ЧОВЕЧКИ ПРЕГЛЕД“.<source>{{ текст }}</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%. Системот за штети од осигурување автоматски одобруваше штети со ниска сума и висока безбедност и ги испраќаше само оние над прагот/нискосигурните до експертот. Од 3.200 дневни барања, само 950 паднаа на луѓе; експертите го посветија своето време на навистина ризичните 30%, при што просечното време на трансакција падна од 4 часа на 40 минути.
Совет: Не поставувајте човечка контрола така што „луѓето можат да видат сè“ - ова ќе ги измори луѓето и одобрувањето ќе стане гумен печат. Наместо тоа, само насочувајте излези со големо влијание и ниска доверба кон човекот; Ова го фокусира вниманието на она што навистина е важно.
Да ја направиме човечката контрола значајна
Human-in-the-loop не е за ставање поле за избор на хартија. Рецензентот мора да има (1) контекст за да ја разбере одлуката, (2) пристап до изворот и (3) овластување да каже „не“. Во спротивно, контролата останува козметичка. Картичката за преглед (четвртиот образец погоре) е наменета да го обезбеди токму тој контекст.
Вообичаени грешки
- Само прави валидација на шемата и прескокнување на грешки во содржината/вредноста.
- Мислејќи дека со тоа што му кажувате на моделот „погрижете се“ да правите вистинска проверка.
- Автоматски спроведувајте одлуки со големо влијание, неповратни.
- Ставање човечка контрола на секој излез и претворање на одобрението во бесмислен гумен печат.
- Кажување „одобрување“ на рецензентот без да се наведат изворот и контекстот.
- Обработка на сите резултати со ист ризик без воспоставување праг на доверба и рутирање.
Сумирано
- Излезот е оштетен на три начини: форма, содржина и злонамерна намера; цврст систем ги запира сите три на вратата.
- Слоеви: валидација на шема, правило/деловна логика, контрола на изворот, втор модел (LLM-as-judge) и рутирање на прагот на доверба.
- Human-in-the-loop треба да биде задолжителен за излези со големо влијание и ниска безбедност.
- Човечкиот преглед мора да биде значаен: рецензентот мора да има контекст, пристап до ресурси и овластување да каже „не“.
- И безбедноста и ефикасноста се добиваат со насочување само на ризичните кон луѓето, а не секој резултат.
Задача за апликација
Земете пример од вашиот сопствен излез за вештачка интелигенција. Прво дефинирајте JSON шема и принудете го излезот на неа. Потоа напишете најмалку две деловни правила (на пример, „количината се совпаѓа со вкупните ставки“). Конечно, поставете рутирачка табела: која комбинација на доверба/влијание оди автоматски, која оди кај вториот модел, која кај човекот? Генерирајте неисправен примерок и набљудувајте каде го зафаќа секој слој.
листа за проверка
- [ ] Јас дефинирам строга шема за излезот и ја потврдувам со машината.
- [ ] Додадов барем една валидација на бизнис/правила (логика на вредност).
- [ ] Можам да ги поврзам тврдењата со изворот и да ги проверам.
- [ ] Достапен е втор модел или човечка валидација за високо влијание/ниски безбедносни резултати.
- [ ] Правило за рутирање дефинирано врз основа на доверба и влијание.
- [ ] Рецензентот има контекст, извор и овластување за отфрлање.