Производство от край до край: проверка, мониторинг и етика

Печалби:

Може да проектира архитектурата от край до край, която пренася функцията на LLM от идеята до производството
Установява слоеве на прилагане на проверката, човешко одобрение и проследяване (регистриране/метрики)
Границите превръщат етиката и принципите за поверителност в производствени решения

В предишните десет раздела научихме частите една по една: структура на заявката, икономика на токена, поток, системна подкана, избор на модел, кеш, партида, управление на грешки, защитен ключ и автоматизация. В този последен модул ние комбинираме частите и установяваме холистична архитектура, която носи LLM функция от идеята до производството. Производството е различно от „работеща демонстрация“: проверката е задължителна, продукцията трябва да се наблюдава, границите и етичните принципи трябва да бъдат вградени в решенията. Това устройство е носещата колона на модула; Всички предишни се събират тук.

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

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

Входен слой: Събирайте данни, почиствайте ги, маскирайте чувствителните зони, предавайте само това, което е необходимо.
Слой на модела: Изберете правилния модел (единица 5), задайте системна подкана и параметри (единица 4), кеш (единица 6).
Слой за валидиране: Проверете изхода спрямо схема/правило, източник и човешко одобрение, ако е необходимо.
Слой на действие: Извършване на действие с валидиран изход; Уловете действия със силно въздействие.
Слой за наблюдение: Записвайте и измервайте всяко обаждане, цена, грешка и качество.

Тези слоеве са тръбопровод; всеки проверява изхода на предишния.

Защо се изисква проверка?

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

Слоеве за проверка (увеличаване при въздействие):

Проверка на формат/схема: Изходът съответства ли на очакваната JSON схема? (Структурираният изход до голяма степен гарантира това.)
Проверка на правило/логика: Разумни ли са стойностите? (Сумата отрицателна ли е, датата в бъдеще ли е, категорията валидна ли е?)
Проверка на източника: твърдението базирано ли е на предоставената документация? Моделът казва ли нещо, което го няма в документа?
Човешко одобрение: Експерт преглежда силно въздействащи или двусмислени решения.

Внимание: „Моделът е толкова добър, че не е необходима допълнителна проверка“ е най-опасната производствена грешка. Без значение колко добър е моделът, верификационният слой е предпазна мрежа при решения с голямо въздействие. Дори едно грешно автоматично решение може да отнеме цялото спестено време.

Човек в цикъла

Не всяко решение трябва да бъде напълно автоматично. При подхода човек в цикъла моделът ускорява работата и човекът я одобрява. Правилният баланс зависи от въздействието на решението и надеждността на модела върху тази задача.

Въздействие на решението

подход

Ниско (предложение за етикет, чернова)

Пълна автоматизация; грешката е евтина и обратима

Среден (маршрутизиране, приоритизиране)

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

Високо (пари, договор, здраве, изтриване)

Човешкото съгласие е задължително; моделът само предполага

Мониторинг: Не можете да управлявате това, което не виждате

В производството трябва да наблюдавате всяко обаждане. Без мониторинг не можете да подобрите разходите, качеството или да откриете проблем навреме. Ключови показатели за записване:

Използване/цена: За заявка и общи токени, разпределение на модела, дневни разходи.
Латентност: Средно и най-лошо време за реакция.
Процент на грешки: 429/500 проценти, повторни опити, изоставяния.
Качество: Скорост на отхвърлен резултат при слой за проверка, процент на корекция при одобрение от човек, обратна връзка от потребителя.

Съвет: Не записвайте чувствителни данни (лична информация, ключове) в регистрационните файлове за наблюдение. Разгледайте регистрационните файлове в обхвата на поверителността; запис чрез маскиране, ако е необходимо (единица 9).

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

Етичната отговорност е също толкова част от производственото решение, колкото и техническата точност:

Прозрачност: Потребителят трябва да знае дали говори с изкуствен интелект или човек.
Справедливост и пристрастия: Моделът може да носи пристрастия от данните, върху които е обучен; Наблюдавайте дискриминационните последици при решения с голямо въздействие (наемане, кредит).
Отговорност: Ако автоматизирано решение причини вреда, вие носите отговорност; „Моделът каза така“ не е защита.
Приемане на ограничения: Моделът не може да изпълнява някои задачи надеждно; неавтоматизирането им също е дизайнерско решение.

Копируеми шаблони

# Контролен списък за проверка (след генериране на изход)1) Схемата валидна ли е? (проверка на структурирани изходни данни) 2) Имат ли смисъл стойностите? (проверка на правило: диапазон, дата, списък)3) Твърдението базирано ли е на източника? (отхвърлете, ако не е в документа) 4) Голямо ли е въздействието? → изпрати за одобрение от човек 5) Ако всички са преминали → разреши действие, запиши

# Системна подкана, която принуждава да се разчита на източник Разчитайте само на информация в предоставения документ. Не добавяйте нищо, което не е в документа. Ако информацията не е в документа, напишете „Не е намерена в документа“. Никога не гадайте и не измисляйте неща.

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

# Шаблон за регистър на проследяване (записване на чувствителни данни){ "време":"...", "модел":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "authentication":"passed|rejected|human", "cost_usd":... } // лични данни и ключ НИКОГА не се записват

Слаба подкана / Силна подкана (надеждност на производството)

# СЛАБ (без проверка, без източник, прилага се автоматично) Оценете тази заявка, вземете решение за възстановяване и кандидатствайте.

# СИЛЕН (базиран на източника, генерира препоръка, оставя на одобрение от човека) Оценете тази заявка за връщане само въз основа на документа за правила за връщане. Препоръчайте решение с обосновка, но не го прилагайте: {"recommendation":"approve|reject","reason":"...","policy_clause":"..."}.Ако няма ясна основа в документа за правилата, дайте "неясно". Представител ще одобри окончателното решение.

Мощна версия; Той приписва решението на източника, позиционира модела като „сугестор“, а не като „изпълнител“, и поставя стъпката с голямо въздействие зад одобрението на човека. Това е същността на надеждността на производството.

Три мини калъфа

Случай 1 — Денят, в който верификационният слой е запазил. Fintech накара модела да класифицира описанията на транзакциите и да създаде автоматични счетоводни записи. Те добавиха проверка на правилото: след като моделът изведе сумата неправилно (12 500 вместо 1250 в документа), правилото „сумата не съответства на документа“ отхвърли изхода и записът падна на човека. Ако нямаше проверка, неправилният запис тихо щеше да влезе в системата.

Случай 2 — Беглец, заловен от наблюдение. Екип на SaaS създаде панел за наблюдение; Една сутрин дневните разходи се утроиха. От регистрационните файлове се видя, че клиент е влязъл в цикъл и е изпратил същата заявка хиляди пъти. Те добавиха квота и дедупликация; Проблемът беше разрешен за часове. Без проследяване сметката би била изненада в края на месеца.

Случай 3 — Приемане на ограничението. Стартираща компания в здравеопазването планираше да направи препоръка за диагноза напълно автоматично и да я покаже на пациента. При преглед на етиката и отговорността те решиха, че това е забранено: моделът предоставя само резюме и възможни точки на лекар, лекарят поставя диагнозата. Неавтоматизирането на работа също е зряло дизайнерско решение.

Често срещани грешки

Пропускане на валидиране: Сляпо прилагане на изхода, казвайки „моделът е добър“.
Автоматизиране на решения с голямо въздействие: Човешкото одобрение е от съществено значение за парите/здравеопазването/закона.
Без наблюдение: Проблемите с разходите и качеството се откриват късно.
Записване на чувствителни данни в регистрационни файлове: нарушение на поверителността; Запазете го, като го маскирате.
Не се опитвайте да разчитате на източника: Моделът може да съставлява това, което не е в документа.
Пренебрегване на ограниченията: Неавтоматизирането на някои задачи е правилното решение; Прозрачността и отговорността са ваши.

По-дълбоко: Управление на версии, връщане назад и постепенно внедряване

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

Версиониране. Вашата системна подкана, избор на модел и правила за проверка се променят с времето. Версирайте всяка значителна промяна и запишете коя версия е активна. Ако един ден качеството падне, "какво променихме?" Трябва да можете да отговорите на въпроса в рамките на минути. В система без версии намирането на основната причина за регресия отнема дни.

Връщане назад. Ако нова подкана или модел се държи по-лошо от очакваното на живо, трябва да можете бързо да се върнете към предишната, добре позната версия. Промяна без план за връщане назад означава сляпо приемане на жив риск. „Промених нещо, стана лошо, не мога да се върна“ е най-скъпият продуцентски сценарий.

Постепенно внедряване. Вместо да приложите промяна към целия трафик наведнъж, първо я разгръщате до малък процент (напр. 5%) и наблюдавате показатели (качество, цена, грешки). Ако е добре, увеличавате процента; Ако е лошо, ще си го върнете само със засегната малка част. Това значително ограничава риска.

Тези три практики съчетават техники от всички предишни единици: eval (единица 5) измерва промяната предварително, наблюдението (този единица) дава ранно предупреждение по време на разпространението, верификационният слой улавя грешни изходи, преди да станат приложими. Производството не е единична правилна настройка; Това е непрекъсната дисциплина, която измерва, наблюдава и може да се променя с увереност. Целият модул е за вас да установите тази дисциплина.

В обобщение

Производството е повече от работеща демонстрация: това е конвейер от слоеве за въвеждане, моделиране, проверка, действие и наблюдение. Резултатът е ненадежден без проверка; решенията с голямо въздействие са обвързани с човешкото одобрение; Всяко обаждане се следи за цена, грешки и качество. Етика, прозрачност, контрол на пристрастия, отчетност и приемане на ограничения са неразделна част от техническите решения. Всяка част, научена в този модул, се събира в този холистичен дизайн.

Задача за приложение

Проектирайте LLM функция от край до край. (1) Попълнете петте слоя (вход, модел, проверка, действие, мониторинг) за вашата конкретна задача. (2) Маркирайте по въздействие кои решения ще изискват човешко одобрение. (3) Напишете поне три проверки за валидиране (схема, правило, източник). (4) Определете ключовите показатели, които ще проследявате и какво няма да регистрирате. (5) Напишете ограничение и етичен принцип, които приемате в тази функция.

контролен списък

[ ] Мога да проектирам пет слоя от производствения тръбопровод.
[ ] Мога да проверя изхода спрямо схема, правило и източник.
[ ] Мога да задам праг на човешко одобрение въз основа на въздействието на решението.
[ ] Следя разходите, грешките и качеството и практикувам да не записвам чувствителни данни в регистрационни файлове.
[ ] Мога да трансформирам етиката, отговорността и границите в производствени решения.

Изпит по модул

1. Какво прави „системната“ роля в API за LLM чат?

A) Дава на модела постоянни инструкции и правила за поведение, които се прилагат през целия разговор ✔
B) Запазва последния въпрос, написан от потребителя
C) Съхранява отговора, произведен от модела
D) Криптира API ключа

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

2. Защо историята на разговорите (предишни съобщения) се изпраща отново всеки път в заявка за API?

A) Необходимо е да се архивира, тъй като сървърът изтрива историята
B) API повикванията са без състояние; ✔ Контекстът се изпраща повторно при всяка заявка, защото моделът не помни историята
C) Изисква се само за фактуриране, няма ефект върху модела
Г) Изпращането на хронология е задължително, за да се избегне забавяне на отговора

Обяснение: LLM API извикванията са без състояние; Моделът не помни предишни кръгове, така че цялата съответна история се изпраща повторно при всяка заявка, за да се запази контекстът.

3. Какво е „токен“ в ценообразуването на LLM?

A) Еднократна парола, използвана за влизане в API
B) Фиксирана такса, заплащана при всяка заявка
В) Най-малката единица, в която моделът обработва текста; обикновено съответства на част от думата ✔
D) Единица, която измерва само дължината на изхода

Описание: Token е най-малката единица, в която моделът обработва текст; Обикновено съответства на фрагмент от дума и както входът, така и изходът се таксуват въз основа на броя токени.

4. Защо изходните токени са по-скъпи от входните токени при повечето доставчици на LLM?

A) Изходните токени винаги са по-дълги от входните
B) Входящите жетони са безплатни
C) Изходните токени се изпращат два пъти по интернет
Г) Единичната цена е по-висока, тъй като генерирането на изход изисква допълнителни изчисления за всеки токен ✔

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

5. В каква ситуация използването на стрийминг е най-полезно?

А) При дълги отговори; Намалява възприеманото забавяне и предотвратява времето за изчакване ✔
Б) Само в много кратки, еднословни отговори
В) За намаляване на разходите до нула
D) За да скриете API ключа

Описание: При дълги отговори стриймингът намалява възприеманото забавяне, като кара първите думи да се появяват незабавно и предотвратява изчакване на HTTP при големи стойности на max_tokens.

6. Какво общо влияе увеличаването на параметъра „усилие“ при съвременните модели?

А) Винаги съкращавайте отговора
B) Автоматично завърта API ключа
В) Намалява само цената на входния токен
D) Увеличава дълбочината на мислене и символичните разходи; Може да подобри качеството, но също така увеличава латентността и цената ✔

Описание: параметърът на усилието настройва колко дълбоко моделът ще обмисли дадена задача и колко жетони ще изразходва; Надграждането може да подобри качеството, но също така увеличава забавянето и разходите. За прости задачи е достатъчно малко усилие.

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

А) Винаги използвайте най-скъпия и най-мощен модел
B) Обаждане на всички модели едновременно за всяка заявка
C) Избор на най-лекия/най-евтиния модел, който изпълнява задачата, като го проверите с малко eval ✔
Г) поддържане на ненужно твърде висока стойност на max_tokens

Обяснение: Ако задачата не е сложна, изборът на по-бърз и по-евтин модел, който лесно изпълнява задачата (напр. Haiku клас), вместо използването на най-скъпия и мощен модел, значително ще намали разходите.

8. В кой сценарий бързото кеширане намалява разходите най-много?

A) Когато голям и фиксиран контекст се използва многократно в много заявки ✔
B) Когато с всяка заявка се изпраща напълно различен текст
В) Когато е направена само една заявка
Г) За намаляване на изходните жетони

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

9. Как трябва да редактирам подканата, така че кеша на подканата да се удря?

А) Поставяне на променливо съдържание в началото и фиксирано съдържание в края
B) Вградете текущата дата и час в системния ред за всяка заявка
C) Поставяне на фиксирано съдържание (системен ред, документи) в началото и променливо съдържание в края ✔
D) Промяна на реда на списъка с инструменти с всяка заявка

Обяснение: Тъй като кешът е съвпадение на префикс, фиксирано/непроменящо се съдържание (системен ред, документи) се инициализира; променливо съдържание (дата, потребителски въпрос, ID на заявка) се поставя в края. Дори един байт, променен в началото, ще обезсили кеша.

10. За какъв тип натоварване е най-подходяща груповата обработка?

A) Чат на живо, където потребителят очаква незабавен отговор на екрана
Б) Само един кратък въпрос
C) Генериране на API ключ
Г) Работи, които са толерантни към забавяне, голям обем и не изискват незабавни резултати ✔

Описание: Пакетната обработка е подходяща за големи обеми задачи, които не изискват незабавен отговор и са толерантни към забавяне; резултатите се дават след известно време, но единичната цена обикновено е по-ниска.

11. Какво се използва за уверено съответствие към коя заявка принадлежат резултатите в пакет?

A) Изпращане на ред (позиция) на заявките
Б) Дължина на отговорите
C) Последните 4 цифри от API ключа
D) Уникален custom_id, даден на всяка заявка ✔

Забележка: Груповите резултати могат да бъдат върнати в ред, различен от реда за изпращане; така че е необходимо да се съпоставят резултатите по ID, а не по местоположение, с уникален custom_id, даден на всяка заявка.

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

A) Принуждаване чрез изпращане на много повече заявки едновременно
B) Опитва се отново с експоненциално забавяне, следвайки заглавието „повторен опит след“ ✔
C) Отменете напълно заявката и покажете грешката като срив на потребителя
D) Промяна на API ключа

Обяснение: 429 е повторна грешка; Правилният подход е да опитате отново с експоненциално забавяне, зачитайки заглавката за повторен опит. Повечето официални SDK правят това автоматично.

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

A) 400 (невалидна заявка)
B) 401 (грешка при удостоверяване)
C) 529 (сървърът е претоварен) ✔
D) 404 (не е намерено)

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

14. Кое от следните е сигурният начин за управление на API ключове?

A) Съхраняване в променлива на средата/скрит мениджър, без вграждане в кода и редовна ротация ✔
B) Напишете ключа директно в изходния код и го изпратете в хранилището
C) Поставяне на ключа в JavaScript от страна на клиента (браузър).
Г) Споделяне на един ключ с целия екип по имейл

Описание: Ключовете никога не се записват в изходния код или хранилище; Той се съхранява в променлива на средата или скрит инструмент за управление, предоставя се с минимални привилегии и се редува редовно.

15. Какъв е най-добрият подход за интегриране на LLM с инструмент за автоматизация (n8n, Zapier, Make) от гледна точка на поверителността?

A) Изпращане на всички необработени данни към модела, дори и да не е необходимо
B) Писане на API ключа в обикновен текст в стъпката на потока
C) Минимизиране и маскиране на чувствителни данни и съхраняване на ключа като секретни идентификационни данни ✔
Г) Запазване на личните данни постоянно в историята на потока

Описание: Тъй като автоматизацията на въвеждане на данни преминава през системи и модел на трети страни, чувствителните/личните данни трябва да бъдат сведени до минимум, маскирани и изпратени само задължителни полета; API ключът също се съхранява като секретни идентификационни данни в инструмента.

16. Защо валидирането на изхода е задължително в производствена функция, базирана на LLM?

A) Изисква се само форматиране, защото моделът никога не прави грешки
B) Тъй като моделът може да произвежда плавно, но понякога неправилно; Схемата/правилото трябва да бъдат одитирани с одобрение от ресурси и хора ✔
В) Валидирането трябва да се избягва, защото само увеличава разходите
Г) Проверката е само за намаляване на броя на токените

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