Производња од краја до краја: верификација, праћење и етика

Добици:

Може да дизајнира архитектуру од краја до краја која преузима функцију ЛЛМ од идеје до производње
Успоставља нивое спровођења верификације, људског одобрења и праћења (регистровање/метрика)
Границе преводе етику и принципе приватности у производне одлуке

У претходних десет јединица учили смо један по један делове: структуру захтева, економију токена, ток, системски промпт, избор модела, кеш меморију, групу, управљање грешкама, сигуран кључ и аутоматизацију. У овој последњој јединици комбинујемо делове и успостављамо холистичку архитектуру која носи карактеристике ЛЛМ од идеје до производње. Производња се разликује од „радне демонстрације“: верификација је обавезна, излаз се мора пратити, границе и етички принципи морају бити уграђени у одлуке. Ова јединица је носећа колона модула; Овде се окупљају сви претходни.

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

Чврста ЛЛМ квалификација се састоји од отприлике пет слојева:

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

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

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

ЛЛМ могу произвести течан, али понекад нетачан резултат. Ово се зове халуцинација: модел може измислити информације које изгледају истините, али нису. У игрици за ћаскање ово је подношљиво; не може се толерисати у производном систему (фактура, здравствени, правни, финансијски). Тако се испоставило, слепо непоуздано; је потврђено.

Слојеви верификације (повећавају се утицајем):

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

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

Човек-у-петљи

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

Утицај одлуке

Приступ

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

Потпуна аутоматизација; грешка је јефтина и реверзибилна

Средњи (усмеравање, одређивање приоритета)

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

Висок (новац, уговор, здравље, брисање)

Људска сагласност је обавезна; модел само сугерише

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

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

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

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

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

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

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

Цопиабле Темплатес

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

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

# Праг људског одобрења (правило одлуке)ИФ тип_одлуке у [новац, уговор, брисање, здравље] → људско одобрење обавезноИФ модел_труст < праг ИЛИ валидација „неизвесна“ → поднесите људском одобрењуОТХЕР → аутоматска примена + контрола узорковања

# Шаблон евиденције праћења (писање осетљивих података){ "време":"...", "модел":"...", "инпут_токен":..., "оутпут_токен":..., "делаи_мс":..., "стоп_реасон":"...", "аутхентицатион":"прошло|одбијено|људски", "цост_усд" НИКАД нису лични подаци

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

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

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

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

Три мини кућишта

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

Случај 2 — Бегунац ухваћен присмотром. СааС тим је поставио надзорни панел; Једног јутра дневни трошак се утростручио. Из евиденције се видело да је клијент улазио у петљу и слао исти захтев хиљадама пута. Додали су квоту и дедупликацију; Проблем је решен у року од неколико сати. Без праћења, рачун би био изненађење на крају месеца.

Случај 3 — Прихватање ограничења. Један здравствени стартуп планирао је да потпуно аутоматски направи препоруку за дијагнозу и покаже је пацијенту. У прегледу етике и одговорности, одлучили су да је ово забрањено: модел пружа само резиме и могуће тачке за лекара, лекар поставља дијагнозу. Неаутоматизација посла је такође зрела дизајнерска одлука.

Уобичајене грешке

Прескакање валидације: слепо примењује излаз, говорећи „модел је добар“.
Аутоматизација одлука са великим утицајем: Људско одобрење је од суштинског значаја за новац/здравље/закон.
Не надгледање: Проблеми са трошковима и квалитетом се откривају касно.
Уписивање осетљивих података у дневнике: Кршење приватности; Сачувајте га тако што ћете га маскирати.
Не покушавајући да се ослоните на извор: модел може да чини оно што није у документу.
Игнорисање ограничења: Неаутоматизација неких задатака је права одлука; Транспарентност и одговорност су на вама.

Дубље: Управљање издањима, враћање уназад и инкрементална примена

Увођење ЛЛМ функције у продукцију не значи да је поставите и заборавите на њу; је безбедно модификовање живог система током времена. Има три стуба.

Версионинг. Ваш системски упит, избор модела и правила верификације се временом мењају. Верзија сваке значајне промене и забележите која је верзија активна. Ако једног дана квалитет опадне, "шта смо променили?" Требало би да будете у могућности да одговорите на питање у року од неколико минута. У систему без верзије, проналажење основног узрока регресије траје данима.

Роллбацк. Ако се нови упит или модел понаша лошије него што се очекивало уживо, требало би да будете у могућности да се брзо вратите на претходну, добро познату верзију. Промена без плана враћања је слепо прихватање живог ризика. „Променио сам нешто, покварило се, не могу да се вратим” најскупљи је сценарио производње.

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

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

Укратко

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

Задатак апликације

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

контролна листа

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

Модул Екам

1. Шта ради 'системска' улога у ЛЛМ АПИ-ју за ћаскање?

А) Даје моделу трајна упутства и правила понашања која се примењују током читавог разговора ✔
Б) Задржава последње питање које је написао корисник
Ц) Чува одговор произведен од стране модела
Д) Шифрује АПИ кључ

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

2. Зашто се историја разговора (претходне поруке) поново шаље сваки пут у АПИ захтеву?

А) Потребно је направити резервну копију пошто сервер брише историју
Б) АПИ позиви су без држављанства; ✔ Контекст се замењује на сваки захтев јер модел не памти историју
Ц) Захтева се само за фактурисање, нема утицаја на модел
Д) Слање историје је обавезно како би се избегло успоравање одговора

Објашњење: ЛЛМ АПИ позиви су без држављанства; Модел не памти претходне рунде, па се сва релевантна историја замера на сваки захтев да се сачува контекст.

3. Шта је 'токен' у ЛЛМ ценама?

А) Једнократна лозинка која се користи за пријаву на АПИ
Б) Фиксна накнада која се плаћа на сваки захтев
В) Најмања јединица у којој модел обрађује текст; обично одговара делу речи ✔
Д) Јединица која мери само дужину излаза

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

4. Зашто су излазни токени скупљи од улазних токена код већине ЛЛМ провајдера?

А) Излазни токени су увек дужи од улазних
Б) Улазни токени су бесплатни
Ц) Излазни токени се шаљу два пута преко интернета
Д) Јединични трошак је већи јер генерисање излаза захтева додатне прорачуне за сваки токен ✔

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

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

А) У дугим одговорима; Смањује уочено кашњење и спречава временско ограничење ✔
Б) Само у врло кратким одговорима од једне речи
Ц) Смањење трошкова на нулу
Д) Да сакријете АПИ кључ

Опис: У дугим одговорима, стриминг смањује уочено кашњење тако што се прве речи појављују одмах и спречава ХТТП тајмауте при великим вредностима мак_токена.

6. На шта генерално утиче повећање параметра 'напор' у савременим моделима?

А) Увек скратите одговор
Б) Аутоматски ротира АПИ кључ
Ц) То само смањује цену улазног токена
Д) Повећава дубину размишљања и трошење симбола; Може побољшати квалитет, али такође повећава кашњење и трошкове ✔

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

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

А) Увек користите најскупљи и најмоћнији модел
Б) Позивање свих модела у исто време за сваки захтев
Ц) Одабир најлакшег/најјефтинијег модела који испуњава задатак тако што га верификујемо малом проценом ✔
Д) задржавање вредности мак_токенс непотребно превисоке

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

8. У ком сценарију промптно кеширање највише смањује трошкове?

А) Када се велики и фиксни контекст више пута користи у многим захтевима ✔
Б) Када се уз сваки захтев шаље потпуно другачији текст
Ц) Када је поднет само један захтев
Д) За смањење излазних токена

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

9. Како да уредим промпт тако да се кеш промпт појави?

А) Стављање променљивог садржаја на почетак и фиксног садржаја на крају
Б) Уградите тренутни датум и време у системску линију за сваки захтев
Ц) Стављање фиксног садржаја (системски промпт, документи) на почетак и променљиви садржај на крају ✔
Д) Промена редоследа листе алата са сваким захтевом

Објашњење: Пошто се кеш подудара са префиксом, фиксни/непроменљиви садржај (системски промпт, документи) се иницијализује; променљиви садржај (датум, корисничко питање, ИД захтева) ставља се на крај. Чак и један бајт промењен на почетку поништиће кеш меморију.

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

А) Ћаскање уживо где корисник очекује тренутни одговор на екрану
Б) Само једно кратко питање
Ц) Генерисање АПИ кључа
Д) Послови који су толерантни на кашњење, велики обим и не захтевају тренутне резултате ✔

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

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

А) Слање редоследа (позиције) захтева
Б) Дужина одговора
Ц) Последње 4 цифре АПИ кључа
Д) Јединствени цустом_ид дат сваком захтеву ✔

Напомена: Групни резултати могу бити враћени другачијим редоследом од налога за подношење; тако да је неопходно ускладити резултате према ИД-у, а не локацији, са јединственим цустом_ид датим за сваки захтев.

12. Какво је препоручено понашање када добијете грешку 429 (ограничење брзине) од АПИ-ја?

А) Форсирање слањем више захтева у исто време
Б) Покушавамо поново са експоненцијалним повлачењем, након наслова ✔
Ц) Откажите захтев у потпуности и прикажите грешку као рушење кориснику
Д) Промена АПИ кључа

Објашњење: 429 је грешка која се може поновити; Исправан приступ је да покушате поново са експоненцијалним повлачењем, поштујући заглавље поновног покушаја. Већина званичних СДК-ова то ради аутоматски.

13. Који од следећих ХТТП кодова грешака се генерално сматрају поновним покушајем?

А) 400 (неважећи захтев)
Б) 401 (грешка у аутентификацији)
Ц) 529 (сервер преоптерећен) ✔
Д) 404 (није пронађено)

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

14. Шта од следећег је безбедан начин управљања АПИ кључевима?

А) Чување променљиве окружења/скривеног менаџера, не уграђивање у код и редовно ротирање ✔
Б) Упишите кључ директно у изворни код и пошаљите га у спремиште
Ц) Стављање кључа у ЈаваСцрипт на страни клијента (прегледач).
Д) Дељење једног кључа са целим тимом путем е-поште

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

15. Који је најбољи приступ интеграцији ЛЛМ са алатом за аутоматизацију (н8н, Запиер, Маке) у погледу приватности?

А) Слање свих необрађених података у модел, чак и ако то није неопходно
Б) Писање АПИ кључа у обичном тексту унутар корака тока
Ц) Минимизирање и маскирање осетљивих података и чување кључа као тајне акредитиве ✔
Д) Трајно чување личних података у историји тока

Опис: Како аутоматизација уноса података пролази кроз системе и моделе трећих страна, осетљиви/лични подаци морају бити минимизирани, маскирани и послати само обавезна поља; АПИ кључ се такође чува као тајни акредитиви у оквиру алата.

16. Зашто је валидација резултата обавезна у производној функцији заснованој на ЛЛМ?

А) Потребно је само форматирање јер модел никада не прави грешке
Б) Зато што модел може да производи флуидно, али понекад нетачно; Шема/правило мора бити ревидирано уз одобрење ресурса и људи ✔
Ц) Валидацију треба избегавати јер само повећава трошкове
Д) Верификација је само да се смањи број токена

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