Наскрізне виробництво: перевірка, моніторинг і етика

Прибуток:

Може розробити наскрізну архітектуру, яка переносить функцію LLM від ідеї до виробництва
Встановлює рівні перевірки, схвалення людиною та відстеження (реєстрація/метрики)
Межі втілюють принципи етики та конфіденційності у виробничих рішеннях

У попередніх десяти розділах ми вивчали частини одну за одною: структуру запиту, економіку маркерів, потік, системну підказку, вибір моделі, кеш, пакет, керування помилками, безпечний ключ і автоматизацію. У цьому останньому підрозділі ми об’єднуємо частини та створюємо цілісну архітектуру, яка переносить функцію LLM від ідеї до виробництва. Виробництво відрізняється від «робочої демонстрації»: перевірка є обов’язковою, результат має контролюватися, обмеження та етичні принципи мають бути вбудовані в рішення. Цей блок є несучою колоною модуля; Тут сходяться всі попередні.

Рівні виробничої архітектури

Надійна кваліфікація LLM складається приблизно з п’яти рівнів:

Вхідний рівень: збирайте дані, очищайте їх, маскуйте чутливі області, передайте лише те, що необхідно.
Рівень моделі: виберіть правильну модель (блок 5), установіть системну підказку та параметри (блок 4), кеш (блок 6).
Рівень перевірки: перевірте вихідні дані на відповідність схемі/правилу, джерелу та схвалення людини, якщо необхідно.
Рівень дій: виконання дії з перевіреним результатом; Знімайте вражаючі дії.
Рівень моніторингу: записуйте та вимірювайте кожен дзвінок, вартість, помилку та якість.

Ці шари є конвеєром; кожен з них перевіряє результат попереднього.

Чому потрібна перевірка?

LLM можуть видавати плавні, але іноді неточні результати. Це називається галюцинацією: модель може сфабрикувати інформацію, яка здається правдивою, але не є такою. У чаті це допустимо; не можна допускати у виробничій системі (рахунки-фактури, охорона здоров’я, юридична, фінансова). Так вийшло, наосліп ненадійний; підтверджується.

Верифікаційні шари (збільшуються за впливом):

Перевірка формату/схеми: чи відповідає результат очікуваній схемі JSON? (Структурований вихід значною мірою гарантує це.)
Перевірка правила/логіки: чи обґрунтовані значення? (Чи є сума від’ємною, чи дата в майбутньому, чи категорія дійсна?)
Перевірка джерела: Чи ґрунтується заява на наданій документації? Чи говорить модель щось, чого немає в документі?
Схвалення людини: Експерт розглядає серйозні або неоднозначні рішення.

Застереження: «Модель настільки хороша, що подальша перевірка не потрібна» — це найнебезпечніша виробнича помилка. Незалежно від того, наскільки гарна модель, рівень перевірки є запобіжною сіткою для прийняття важливих рішень. Навіть одне неправильне автоматичне рішення може забрати весь заощаджений час.

Людина в циклі

Не кожне рішення має бути повністю автоматичним. У підході «людина в циклі» модель прискорює роботу, а людина її схвалює. Правильний баланс залежить від впливу рішення та надійності моделі на це завдання.

Вплив рішення

Підхід

Низький (пропозиція мітки, чернетка)

Повна автоматизація; помилка дешева і оборотна

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

Автоматизація + вибірковий контроль

Високий (гроші, контракт, здоров'я, видалення)

Згода людини є обов'язковою; модель лише підказує

Моніторинг: Ви не можете керувати тим, чого не бачите

У виробництві ви повинні контролювати кожен виклик. Без моніторингу ви не зможете покращити вартість, якість або завчасно виявити проблему. Ключові показники для запису:

Використання/вартість: за запит і загальна кількість токенів, розподіл моделі, щоденні витрати.
Затримка: середній і найгірший час відповіді.
Частота помилок: 429/500 ставок, повторних спроб, відмов.
Якість: частота відхилених вихідних даних на верифікаційному рівні, швидкість виправлення після схвалення людини, відгуки користувачів.

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

Етика та межі

Етична відповідальність є такою ж частиною виробничого рішення, як і технічна точність:

Прозорість: користувач повинен знати, чи він розмовляє зі штучним інтелектом чи людиною.
Справедливість і упередженість: модель може мати упередженість від даних, на яких вона навчається; Моніторинг дискримінаційних наслідків у рішеннях із значним впливом (наймання, кредит).
Відповідальність: якщо автоматизоване рішення завдає шкоди, ви несете відповідальність; «Модель так сказала» не є захистом.
Прийняття обмежень: модель не може надійно виконувати деякі завдання; не автоматизувати їх також є проектним рішенням.

Шаблони, які можна копіювати

# Контрольний список перевірки (після створення вихідних даних)1) Чи дійсна схема? (перевірка структурованих вихідних даних)2) Чи значення мають сенс? (перевірка правила: діапазон, дата, перелік)3) Чи базується твердження на джерелі? (відхилити, якщо немає в документі)4) Чи великий вплив? → надіслати на затвердження людині5) Якщо все прийнято → дозволити дію, зберегти

# Системна підказка, яка змушує покладатися на джерело Покладайтеся лише на інформацію в наданому документі. Не додавайте нічого, чого немає в документі. Якщо інформації немає в документі, напишіть «Не знайдено в документі». Ніколи не гадайте і не вигадуйте.

# Поріг схвалення людиною (правило прийняття рішення) ЯКЩО тип_рішення в [гроші, контракт, видалення, здоров’я] → схвалення людиною обов’язкове, ЯКЩО model_trust < поріг АБО перевірка «невизначено» → надати схвалення людиною OTHER → автоматичне застосування + контроль вибірки

# Шаблон журналу трасування (запис конфіденційних даних){ "time":"...", "model":"...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason":"...", "authentication":"passed|rejected|human", "cost_usd":... } // особисті дані та ключ НІКОЛИ не записуються

Слабка підказка / Сильна підказка (надійність виробництва)

# СЛАБКО (немає перевірки, немає джерела, застосовується автоматично) Оцініть цей запит, прийміть рішення про відшкодування та подайте заявку.

# СИЛЬНИЙ (на основі джерела, генерує рекомендацію, залишає на схвалення людині) Оцініть цей запит на повернення лише на основі документа політики повернення. Рекомендувати рішення з обґрунтуванням, але не виконувати: {"recommendation":"approve|reject","reason":"...","policy_clause":"..."}. Якщо в документі політики немає чіткої основи, укажіть "нечітко". Остаточне рішення затвердить представник.

Потужна версія; Він приписує рішення джерелу, позиціонує модель як «пропозицію», а не «виконавця», і ставить крок із високим ступенем впливу за схвалення людини. Це суть надійності виробництва.

Три міні-чохли

Випадок 1 — день збереження верифікаційного рівня. Фінансова техніка мала модель класифікувати описи транзакцій і створювати автоматичні облікові записи. Вони додали перевірку правила: як тільки модель вивела суму неправильно (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) Потрібен лише для виставлення рахунків, не впливає на модель
D) Історія надсилання є обов’язковою, щоб уникнути уповільнення відповіді

Пояснення: виклики LLM API не мають стану; Модель не запам’ятовує попередні раунди, тому вся релевантна історія повторно надсилається на кожен запит, щоб зберегти контекст.

3. Що таке «токен» у ціноутворенні LLM?

A) Одноразовий пароль, який використовується для входу в API
Б) Фіксована комісія, що сплачується за кожен запит
В) Найменший блок, у якому модель обробляє текст; зазвичай відповідає частині слова ✔
Г) Одиниця, яка вимірює лише довжину виходу

Опис: Токен — це найменша одиниця, в якій модель обробляє текст; Зазвичай він відповідає фрагменту слова, і як вхід, так і вихід тарифікуються за кількістю токенів.

4. Чому вихідні токени дорожчі за вхідні токени в більшості постачальників LLM?

A) Вихідні маркери завжди довші за вхідні
Б) Жетони введення безкоштовні
C) Вихідні маркери надсилаються двічі через Інтернет
D) Вартість одиниці вища, оскільки для створення результату потрібні додаткові обчислення для кожного токена ✔

Опис: кожен із вихідних токенів вимагає від моделі виконання покрокової генерації (обчислення); Ці виробничі витрати вищі, ніж обробка вхідних матеріалів відразу, тому вихідна ціна одиниці зазвичай вища.

5. У якій ситуації використання потокового передавання є найбільш вигідним?

А) У довгих відповідях; Зменшує відчутну затримку та запобігає тайм-ауту ✔
Б) Тільки дуже короткими, однослівними відповідями
В) Звести собівартість до нуля
D) Щоб приховати ключ API

Опис: у довгих відповідях потокова передача зменшує сприйняту затримку, змушуючи перші слова з’являтися негайно, і запобігає тайм-ауту HTTP при великих значеннях max_tokens.

6. На що загалом впливає збільшення параметра «зусиль» у сучасних моделях?

А) Завжди скорочуйте відповідь
Б) Автоматично змінює ключ API
C) Це лише знижує ціну вхідного токена
D) Збільшує глибину мислення та символічні витрати; Це може покращити якість, але також збільшить затримку та вартість ✔

Опис: параметр зусилля регулює, наскільки глибоко модель думатиме про завдання та скільки жетонів вона витрачатиме; Оновлення може покращити якість, але воно також збільшує затримку та вартість. Для простих завдань достатньо невеликих зусиль.

7. Який, загалом, є найбільш рентабельним підходом до простого завдання класифікації великого обсягу?

А) Завжди використовуйте найдорожчу і найпотужнішу модель
B) Виклик усіх моделей одночасно для кожного запиту
C) Вибір найлегшої/найдешевшої моделі, яка виконує завдання, перевіряючи її за допомогою невеликого eval ✔
D) збереження занадто високого значення max_tokens

Пояснення: якщо завдання не складне, вибір швидшої та дешевшої моделі, яка легко виконує завдання (наприклад, клас Haiku), замість використання найдорожчої та потужної моделі значно зменшить вартість.

8. За якого сценарію оперативне кешування найбільше знижує витрати?

A) Коли великий і фіксований контекст використовується неодноразово в багатьох запитах ✔
B) Коли з кожним запитом надсилається зовсім інший текст
C) Коли зроблено лише один запит
Г) Зменшити випуск жетонів

Опис: Кешування - це збіг префікса; У випадках, коли великий, незмінний контекст (системна підказка, документи) повторно використовується для багатьох запитів, читання з кешу становить невелику частку (~0,1x) від повної ціни.

9. Як мені відредагувати підказку, щоб кеш підказок потрапляв у кеш?

A) Розміщення змінного вмісту на початку та фіксованого вмісту в кінці
B) Вставте поточну дату й час у системне підказка для кожного запиту
C) Розміщення фіксованого вмісту (системна підказка, документи) на початку та змінного вмісту в кінці ✔
D) Зміна порядку списку інструментів з кожним запитом

Пояснення: Оскільки кеш є збігом префікса, фіксований/незмінний вміст (системна підказка, документи) ініціалізується; змінний вміст (дата, питання користувача, ID запиту) ставиться в кінці. Навіть один байт, змінений на початку, зробить кеш недійсним.

10. Для якого типу робочого навантаження найкраще підходить пакетна обробка?

A) Живий чат, де користувач очікує миттєвої відповіді на екрані
Б) Лише одне коротке запитання
C) Створення ключа API
D) Роботи, які терплять затримки, мають великий обсяг і не вимагають негайних результатів ✔

Опис: Пакетна обробка підходить для великих обсягів завдань, які не вимагають негайної відповіді та терпимі до затримок; результати надаються через деякий час, але вартість одиниці зазвичай нижча.

11. Що використовується для впевненого зіставлення запиту, до якого належать результати в пакеті?

А) Відправлення порядку (позиції) запитів
Б) Довжина відповідей
C) Останні 4 цифри ключа API
D) Унікальний custom_id для кожного запиту ✔

Примітка. Масові результати можуть повертатися в порядку, відмінному від порядку надсилання; тому необхідно зіставляти результати за ідентифікатором, а не за місцем розташування, з унікальним custom_id, наданим кожному запиту.

12. Яка поведінка рекомендована, коли ви отримуєте помилку 429 (обмеження швидкості) від API?

A) Примусове надсилання значної кількості запитів одночасно
B) Повторна спроба з експоненційною відстрочкою, слідуючи заголовком «Після повторної спроби» ✔
C) Повністю скасуйте запит і покажіть користувачеві помилку як збій
D) Зміна ключа API

Пояснення: 429 — це повторна помилка; Правильний підхід полягає в тому, щоб повторити спробу з експоненціальним відстрочкою, дотримуючись заголовка retry-after. Більшість офіційних SDK роблять це автоматично.

13. Які з наведених нижче кодів помилок HTTP зазвичай вважаються повторними?

A) 400 (недійсний запит)
Б) 401 (помилка автентифікації)
C) 529 (сервер перевантажений) ✔
D) 404 (не знайдено)

Пояснення: 429 (обмеження швидкості), 500 (помилка сервера) і 529 (перевантаження) є тимчасовими помилками, і їх можна повторити, відступивши. Такі помилки, як 400 і 401, є проблемами запиту/ідентифікації; Повторна спроба не вирішить проблему.

14. Що з наведеного нижче є безпечним способом керування ключами API?

A) Зберігання в змінній середовища/прихованому менеджері, не вбудовуючи його в код і регулярно змінюючи ✔
B) Запишіть ключ безпосередньо у вихідний код і надішліть його в репозиторій
C) Розміщення ключа на стороні клієнта (браузер) JavaScript
D) Надання єдиного ключа всій команді електронною поштою

Опис: ключі ніколи не записуються у вихідний код або репозиторій; Він зберігається у змінній середовища або прихованому інструменті керування, надається з мінімальними привілеями та регулярно змінюється.

15. Який найкращий підхід до інтеграції LLM із інструментом автоматизації (n8n, Zapier, Make) з точки зору конфіденційності?

A) Надсилання всіх необроблених даних до моделі, навіть якщо це не потрібно
B) Написання ключа API у вигляді звичайного тексту всередині кроку потоку
C) Мінімізація та маскування конфіденційних даних і збереження ключа як секретних облікових даних ✔
D) Постійне збереження персональних даних в історії потоків

Опис: оскільки дані, що вводяться в систему автоматизації, проходять через сторонні системи та моделі, конфіденційні/особисті дані потрібно мінімізувати, маскувати та надсилати лише обов’язкові поля; Ключ API також зберігається в інструменті як секретні облікові дані.

16. Чому перевірка вихідних даних є обов’язковою для функції виробництва на базі LLM?

A) Потрібне лише форматування, оскільки модель ніколи не робить помилок
B) Тому що модель може виробляти плавно, але іноді неправильно; Схему/правило необхідно перевірити з дозволу ресурсів і персоналу ✔
C) Перевірки слід уникати, оскільки вона лише збільшує вартість
D) Перевірка полягає лише в тому, щоб зменшити кількість токенів

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