Производство од крај до крај: верификација, мониторинг и етика

Добивки:

Може да ја дизајнира архитектурата од крај до крај што ја зема карактеристиката за LLM од идеја до производство
Воспоставува слоеви на спроведување на верификација, човечко одобрување и следење (логирање/метрика)
Границите ги преточуваат етичките и принципите на приватност во одлуки за производство

Во претходните десет единици, ги научивме деловите еден по еден: структура на барање, економика на токен, проток, системско известување, избор на модел, кеш, серија, управување со грешки, безбеден клуч и автоматизација. Во оваа последна единица, ги комбинираме деловите и воспоставуваме холистичка архитектура која носи карактеристика на LLM од идеја до производство. Производството се разликува од „работното демо“: верификацијата е задолжителна, излезот мора да се следи, границите и етичките принципи мора да бидат вградени во одлуките. Оваа единица е носечка колона на модулот; Сите претходни се собираат овде.

Слоеви на производствена архитектура

Солидна квалификација за LLM се состои од приближно пет слоеви:

Влезен слој: собирајте податоци, исчистете ги, маскирајте ги чувствителните области, пренесувајте само она што е потребно.
Слој на модел: Изберете го точниот модел (единица 5), поставете системски промпт и параметри (единица 4), кеш (единица 6).
Слој за валидација: проверете го излезот според шемата/правилото, изворот и човечкото одобрение доколку е потребно.
Акционен слој: Изведете дејство со потврден излез; Снимајте дејства со големо влијание.
Слој за следење: снимајте и измерете го секој повик, цена, грешка и квалитет.

Овие слоеви се цевковод; секој од нив го проверува излезот од претходниот.

Зошто е потребна верификација?

LLM може да произведат течен, но понекогаш неточен резултат. Ова се нарекува халуцинација: моделот може да фабрикува информации што се чини дека се вистинити, но не се. Во игра за разговор ова е толерантно; не може да се толерира во производствен систем (фактура, здравствен, правен, финансии). Така испадна, слепо несигурно; се потврдува.

Слоеви за верификација (се зголемуваат со влијание):

Валидација на формат/шема: Дали излезот е во согласност со очекуваната JSON шема? (Структурираниот излез во голема мера го гарантира ова.)
Проверка на правило/логика: Дали вредностите се разумни? (Дали сумата е негативна, дали датумот е во иднина, дали категоријата важи?)
Проверка на изворот: Дали побарувањето се заснова на обезбедената документација? Дали моделот кажува нешто што го нема во документот?
Човечко одобрување: експерт ги разгледува одлуките со големо влијание или двосмислени одлуки.

Внимание: „Моделот е толку добар, не е потребна дополнителна проверка“ е најопасната производствена заблуда. Без разлика колку е добар моделот, слојот за верификација е безбедносна мрежа во одлуките со големо влијание. Дури и една погрешна автоматска одлука може да го одземе целото заштедено време.

Human-in-the-Loop

Не мора секоја одлука да биде целосно автоматска. Во пристапот човек во јамка, моделот ја забрзува работата и човекот го одобрува. Вистинската рамнотежа зависи од влијанието на одлуката и веродостојноста на моделот на таа задача.

Влијание на одлуката

Пристап

Ниско (предлог етикета, нацрт)

Целосна автоматизација; грешката е евтина и реверзибилна

Средно (рутирање, приоритизација)

Автоматизација + контрола на земање примероци

Високо (пари, договор, здравје, бришење)

Човечката согласност е задолжителна; моделот само сугерира

Мониторинг: Не можете да управувате со она што не го гледате

Во производството, мора да го следите секој повик. Без следење, не можете да ги подобрите трошоците, квалитетот или рано да го откриете проблемот. Клучни метрики за снимање:

Употреба/трошок: по барање и вкупни токени, дистрибуција на модели, дневно трошење.
Латентност: Просечно и време на одговор во најлош случај.
Стапка на грешка: 429/500 стапки, повторувања, напуштања.
Квалитет: Отфрлена излезна стапка на слојот за верификација, стапка на корекција при човечко одобрување, повратни информации од корисниците.

Совет: Не пишувајте чувствителни податоци (лични информации, клучеви) во дневниците за следење. Разгледајте ги дневниците во рамките на доверливоста; снима со маскирање ако е потребно (оддел 9).

Етика и граници

Етичката одговорност е исто толку дел од одлуката за производство како и техничката точност:

Транспарентност: Корисникот треба да знае дали разговара со вештачка интелигенција или со човек.
Праведност и пристрасност: Моделот може да носи пристрасност од податоците за кои е обучен; Следете ги дискриминаторските последици во одлуките со големо влијание (вработување, кредит).
Одговорност: Ако автоматизирана одлука предизвика штета, вие сте одговорни; „Моделот рече така“ не е одбрана.
Прифаќање на ограничувања: Моделот не може сигурно да извршува некои задачи; неавтоматизирањето на истите е исто така дизајнерска одлука.

Шаблони за копирање

# Список за проверка за валидација (по генерирање на излез) 1) Дали шемата е валидна? (структурирана валидација на излезот) 2) Дали вредностите имаат смисла? (проверка на правила: опсег, датум, број)3) Дали тврдењето се заснова на изворот? (отфрли ако не е во документот)4) Дали влијанието е големо? → испрати за човечко одобрување5) Ако сите поминаа → дозволи акција, зачувај

# Системско известување кое принудува да се потпира на изворот Се потпираат само на информациите во дадениот документ. Не додавајте ништо што го нема во документот. Ако некоја информација ја нема во документот, напишете „Не е пронајдено во документот“. Никогаш не погодувајте или измислувајте работи.

# Праг на човечко одобрување (правило за одлука) IF одлука_тип во [пари, договор, бришење, здравје] → човечко одобрување задолжителноIF model_trust < праг ИЛИ валидација „неизвесно“ → доставете до човечко одобрување ДРУГО → автоматска примена + контрола на земање примероци

# Шаблон за евиденција за следење (за пишување чувствителни податоци){ „време“:“...“, „модел“:“...“, „влезен_токен“:..., „излезен_токен“:..., „одложено_ms“:..., „стоп_причина“:“...“, „автентикација“: „положено|отфрлено|податоци за луѓе: НЕ/НС се запишани личните податоци...}

Слаба навестување / Силно известување (сигурност на производството)

# СЛАБ (без потврда, без извор, се применува автоматски) Оценете го ова барање, донесете одлука за рефундирање и аплицирајте.

# STRONG (засновано на извор, генерира препорака, остава на човечко одобрување) Оценете го ова барање за враќање само врз основа на документот за политиката за враќање. Препорачај одлука со оправдување, но не имплементирај: {"препорака":"одобри|одбиј","причина":"...","политичка_клаузула":"..."}.Ако нема јасна основа во документот за политика, наведете "нејасно". Претставник ќе ја одобри конечната одлука.

Моќна верзија; Таа му ја припишува одлуката на изворот, го позиционира моделот како „предлагач“ наместо како „сторител“ и го става чекорот со големо влијание зад човечкото одобрување. Ова е суштината на сигурноста на производството.

Три мини футроли

Случај 1 - Денот на зачуваниот слој за верификација. Финтек бараше моделот да ги класифицира описите на трансакциите и да креира автоматска сметководствена евиденција. Тие додадоа валидација на правилата: штом моделот погрешно го изнесе износот (12.500 наместо 1.250 во документот), правилото „износот не се совпаѓа со документот“ го отфрли резултатот и записот падна на човекот. Ако немаше верификација, неточниот запис тивко ќе влезе во системот.

Случај 2 - Бегалец фатен од надзор. Тим на SaaS формираше мониторинг панел; Едно утро дневниот трошок се зголеми тројно. Од дневниците се виде дека клиентот влегол во циклус и го испраќал истото барање илјадници пати. Додадоа квота и дедупликација; Проблемот беше решен за неколку часа. Без следење, сметката би била изненадување на крајот на месецот.

Случај 3 - Прифаќање на лимитот. Здравствен стартап планираше целосно автоматски да направи препорака за дијагноза и да му ја покаже на пациентот. Во прегледот на етиката и одговорноста, тие одлучија дека ова е забрането: моделот дава само резиме и можни поени на лекарот, лекарот ја поставува дијагнозата. Неавтоматизирањето на работата е исто така зрела одлука за дизајн.

Вообичаени грешки

Прескокнување на валидација: слепо применувајќи го излезот, велејќи „моделот е добар“.
Автоматизирање на одлуката со големо влијание: Човечкото одобрување е од суштинско значење за парите/здравјето/законот.
Немониторинг: Проблемите со трошоците и квалитетот се откриваат доцна.
Пишување чувствителни податоци во дневници: повреда на приватноста; Зачувајте го со маскирање.
Не се обидува да се потпре на изворот: Моделот може да го сочинува она што не е во документот.
Игнорирање на границите: Неавтоматизирањето на некои задачи е вистинската одлука; Транспарентноста и одговорноста се ваши.

Подлабоко: Управување со издавање, враќање и инкрементално распоредување

Преземањето на функцијата LLM во производство не е за нејзино поставување и заборавање; е безбедно менување на живиот систем со текот на времето. Има три столба.

Верзија. Правилата за системско известување, избор на модел и проверка се менуваат со текот на времето. Верзија на секоја значајна промена и запишете која верзија е во живо. Ако еден ден падне квалитетот, „што сменивме? Треба да можете да одговорите на прашањето за неколку минути. Во систем без верзија, наоѓањето на основната причина за регресија трае со денови.

Враќање назад. Ако новото известување или модел се однесува полошо од очекуваното во живо, треба да можете брзо да се вратите на претходната, добро позната верзија. Промената без план за враќање е слепо прифаќање на ризик во живо. „Сменив нешто, стана лошо, не можам да се вратам“ е најскапото продукциско сценарио.

Постепено воведување. Наместо да примените промена на целиот сообраќај одеднаш, прво ја распоредувате во мал процент (на пр. 5%) и ги следите метриките (квалитет, цена, грешки). Ако е добро, го зголемуваш процентот; Ако е лошо, ќе го вратите со засегнат само мал дел. Ова во голема мера го ограничува ризикот.

Овие три практики ги комбинираат техниките од сите претходни единици: евалуацијата (единица 5) мерките се менуваат однапред, мониторингот (оваа единица) дава рано предупредување за време на ширењето, слојот за верификација фаќа погрешни резултати пред тие да станат активна. Производството не е единствено правилно поставување; Тоа е континуирана дисциплина која мери, следи и може да се менува со доверба. Целиот модул е за вас да ја воспоставите оваа дисциплина.

Сумирано

Производството е повеќе од работна демо: тоа е цевковод од слоеви на влез, модел, верификација, акција и следење. Излезот е несигурен без верификација; одлуките со големо влијание се врзани за човечко одобрување; Секој повик се следи за трошоци, грешки и квалитет. Етиката, транспарентноста, контролата на пристрасноста, отчетноста и прифаќањето на ограничувањата се составен дел на техничките одлуки. Секое парче научено во овој модул се спојува во овој холистички дизајн.

Задача за апликација

Дизајнирајте LLM функција од крај до крај. (1) Пополнете ги петте слоеви (влез, модел, верификација, акција, следење) за вашата конкретна задача. (2) Означете според влијанието кои одлуки ќе бараат човечко одобрување. (3) Напишете најмалку три проверки за валидација (шема, правило, извор). (4) Определете ги клучните показатели што ќе ги следите и што нема да најавувате. (5) Напишете ограничување и етички принцип што ги прифаќате во оваа карактеристика.

листа за проверка

[ ] Можам да дизајнирам пет слоја од производниот цевковод.
[ ] Можам да го потврдам излезот според шемата, правилото и изворот.
[ ] Можам да поставам праг на човечко одобрување врз основа на влијанието на одлуката.
[ ] Ги надгледувам трошоците, грешките и квалитетот и вежбам да не пишувам чувствителни податоци во дневници.
[ ] Можам да ги трансформирам етиката, одговорноста и границите во одлуки за производство.

Модул испит

1. Што прави улогата на „систем“ во LLM chat API?

А) На моделот му дава постојани упатства и правила на однесување кои важат во текот на целиот разговор ✔
Б) Го задржува последното прашање напишано од корисникот
В) Го складира одговорот произведен од моделот
Г) Го шифрира клучот API

Опис: Системската улога му дава на моделот постојани инструкции, личност и правила кои се применуваат во текот на целиот разговор; Тоа е пренасочување на високо ниво, одвоено од корисничките пораки.

2. Зошто историјата на разговори (претходните пораки) се испраќа повторно секој пат во барање за API?

А) Неопходно е да се направи резервна копија бидејќи серверот ја брише историјата
Б) API повиците се без државјанство; ✔ Контекстот повторно се испраќа на секое барање бидејќи моделот не се сеќава на историјата
В) Се бара само за фактурирање, нема ефект врз моделот
Г) Испраќањето историја е задолжително за да се избегне забавување на одговорот

Објаснување: LLM API повиците се без државјанство; Моделот не се сеќава на претходните кругови, така што целата релевантна историја се испраќа на секое барање за зачувување на контекстот.

3. Што е „токен“ во цените за LLM?

А) Еднократна лозинка што се користи за најавување на API
Б) Фиксна такса платена на секое барање
В) Најмалата единица во која моделот го обработува текстот; обично одговара на зборот дел ✔
Г) Единица која ја мери само должината на излезот

Опис: Токен е најмалата единица во која моделот обработува текст; Обично одговара на фрагмент од збор, и влезот и излезот се наплаќаат врз основа на бројот на токени.

4. Зошто излезните токени се поскапи од влезните токени кај повеќето даватели на LLM?

А) Излезните токени се секогаш подолги од влезните
Б) Влезните токени се бесплатни
В) Излезните токени се испраќаат двапати преку интернет
Г) Единечната цена е поголема бидејќи производството на излез бара дополнителни пресметки за секој токен ✔

Опис: Секој од излезните токени бара моделот да изврши чекор-по-чекор генерирање (пресметка); Овој производствен трошок е поголем од обработката на влезот одеднаш, така што излезната единечна цена е обично повисока.

5. Во која ситуација е најкорисно користењето на стриминг?

А) Во долгите одговори; Го намалува вооченото доцнење и го спречува истекот на времето ✔
Б) Само во многу кратки одговори со еден збор
В) Да се намалат трошоците на нула
Г) За да се скрие клучот API

Опис: во долгите одговори, стриминг ја намалува воочената латентност со тоа што првите зборови се појавуваат веднаш и го спречува HTTP истекувањето на големите вредности на max_tokens.

6. На што генерално влијае зголемувањето на параметарот „напор“ кај модерните модели?

А) Секогаш скратувајте го одговорот
Б) Автоматски го ротира копчето API
В) Само ја намалува цената на влезниот токен
Г) Ја зголемува длабочината на размислувањето и токенското трошење; Може да го подобри квалитетот, но исто така ја зголемува доцнењето и цената ✔

Опис: Параметарот напор прилагодува колку длабоко моделот ќе размислува за задачата и колку токени ќе потроши; Надградбата може да го подобри квалитетот, но исто така ја зголемува доцнењето и трошоците. За едноставни задачи, доволен е мал напор.

7. Кој е генерално најисплатливиот пристап за едноставна задача за класификација со голем обем?

А) Секогаш користете го најскапиот и најмоќниот модел
Б) Повикување на сите модели во исто време за секое барање
В) Избирање на најлесниот/најевтиниот модел што ја исполнува задачата со тоа што ќе го потврдите со малку евал ✔
Г) одржување на вредноста на max_tokens непотребно премногу висока

Објаснување: Ако задачата не е сложена, изборот на побрз и поевтин модел кој лесно ја исполнува задачата (на пр. класа Хаику) наместо користење на најскапиот и најмоќниот модел значително ќе ги намали трошоците.

8. Во кое сценарио брзото кеширање најмногу ги намалува трошоците?

А) Кога голем и фиксен контекст се користи постојано во многу барања ✔
Б) Кога со секое барање се испраќа сосема различен текст
В) Кога е поднесено само едно барање
Г) Да се намалат излезните токени

Опис: Кеширањето е совпаѓање на префиксот; Во случаи кога голем, непроменлив контекст (системско известување, документи) повторно се користи за многу барања, читањето од кешот е мал дел (~0,1x) од целосната цена.

9. Како треба да го уредувам промптот така што кешот за промпт ќе погоди?

А) Ставање променлива содржина на почетокот и фиксна содржина на крајот
Б) Вметнете го тековниот датум и време во системското известување за секое барање
В) Ставање фиксна содржина (системски промпт, документи) на почетокот и променлива содржина на крајот ✔
Г) Промена на редоследот на списокот со алатки со секое барање

Објаснување: Бидејќи кешот е совпаѓање со префикс, фиксната/непроменливата содржина (системско известување, документи) е иницијализирана; на крајот се става променлива содржина (датум, корисничко прашање, ID на барање). Дури и еден бајт променет на почетокот ќе го поништи кешот.

10. За каков вид на обем на работа е најдобро прилагодена сериската обработка?

А) Разговор во живо каде што корисникот очекува моментален одговор на екранот
Б) Само едно кратко прашање
В) Генерирање API клуч
Г) Работи кои се толерантни за доцнење, голем обем и не бараат моментални резултати ✔

Опис: Сериската обработка е погодна за големи количини на работни места кои не бараат итен одговор и се толерантни за одложување; резултатите се испорачуваат по некое време, но единечната цена е обично помала.

11. Што се користи за самоуверено усогласување на кое барање на кое припаѓаат резултатите во серија?

А) Испраќање налог (позиција) на барања
Б) Должина на одговорите
В) Последните 4 цифри од клучот API
Г) Единствен custom_id даден на секое барање ✔

Забелешка: Масовните резултати може да се вратат по различен редослед од налогот за поднесување; па затоа е неопходно да се совпаднат резултатите по ID, а не според локација, со единствена custom_id дадена на секое барање.

12. Кое е препорачаното однесување кога ќе добиете грешка од 429 (ограничување на стапката) од API?

А) Принудување со испраќање многу повеќе барања во исто време
Б) Обидувајќи се повторно со експоненцијално повлекување, следејќи го насловот повторно обид-по ✔
В) Откажете го барањето целосно и прикажете ја грешката како пад на корисникот
Г) Промена на клучот API

Објаснување: 429 е грешка која може да се повтори; Точниот пристап е да се обидете повторно со експоненцијално повлекување, почитувајќи го заглавието повторно обиди после. Повеќето официјални SDK го прават тоа автоматски.

13. Кои од следните кодови за грешка на HTTP генерално се сметаат за повторени обиди?

А) 400 (неважечко барање)
Б) 401 (грешка при автентикација)
В) 529 (серверот е преоптоварен) ✔
Г) 404 (не е пронајден)

Објаснување: 429 (ограничување на брзината), 500 (грешка на серверот) и 529 (преоптоварување) се привремени грешки и може повторно да се обидат со повлекување. Грешките како 400 и 401 се прашања за барање/идентитет; Обидот повторно нема да го реши.

14. Кој од наведените е безбеден начин за управување со клучевите на API?

А) Складирање во променливата на околината/скриен менаџер, не вметнување во кодот и редовно ротирање ✔
Б) Напишете го клучот директно во изворниот код и испратете го во складиштето
В) Ставање на клучот во страната на клиентот (прелистувач) JavaScript
Г) Споделување единствен клуч со целиот тим преку е-пошта

Опис: клучевите никогаш не се запишуваат на изворниот код или складиштето; Се чува во променлива на околината или во скриена алатка за управување, доделена со минимални привилегии и редовно се ротира.

15. Кој е најдобриот пристап за интеграција на LLM со алатка за автоматизација (n8n, Zapier, Make) во однос на приватноста?

А) Испраќање на сите необработени податоци до моделот, дури и ако тоа не е потребно
Б) Пишување на клучот API во обичен текст во чекорот на проток
В) Минимизирање и маскирање чувствителни податоци и складирање на клучот како тајни ингеренции ✔
Г) Трајно чување на личните податоци во историјата на протокот

Опис: бидејќи автоматиката за внесување податоци поминува низ системи и модел од трети страни, чувствителните/лични податоци треба да се минимизираат, да се маскираат и да се испраќаат само потребните полиња; Клучот API исто така се чува како тајни ингеренции во алатката.

16. Зошто валидацијата на излезот е задолжителна во производствената карактеристика базирана на LLM?

А) Потребно е само форматирање бидејќи моделот никогаш не прави грешки
Б) Бидејќи моделот може да произведува флуидно, но понекогаш погрешно; Шемата/правилото мора да биде ревидирана со одобрение од ресурси и луѓе ✔
В) Валидацијата треба да се избегнува бидејќи само ги зголемува трошоците
Г) Верификацијата е само за да се намали бројот на токени

Опис: LLM може да произведат течен, но понекогаш неточен (халуцинаторен) излез; така што излезе во одлуки со големо влијание; Треба да се ревидира со проверка на шема/правила, валидација на изворот и човечко одобрување кога е потребно.