AI-агент може дати правильну фінальну відповідь небезпечним шляхом: викликати зайвий інструмент, прочитати надмірні дані, повторити дію або витратити більше норми.
Тому в продакшені потрібен повний шлях виконання, а не лише uptime та остання репліка.
Пов'яжіть один запуск наскрізним trace ID
Призначте вхідному запиту ID і передавайте його через модель, пошук, інструменти, погодження та результат. Траса має показувати порядок, тривалість, статус і виконавця.
OpenTelemetry описує traces, metrics та events як взаємодоповнювальні сигнали. Промпти й результати зберігайте лише за обґрунтованої мети, прав і строку.
Логуйте кожне рішення про інструмент
Записуйте запропонований інструмент, аргументи, права, погодження, результат і retry. Відділяйте пропозицію моделі від системної дії.
OWASP попереджає про excessive agency. Застосовуйте мінімальні права зі статті про prompt injection.
- actor і request ID
- версія моделі та процесу
- інструмент і перевірені аргументи
- рішення політики або людини
- результат, помилка й повтори
- змінений запис у зовнішній системі
Вимірюйте якість після запуску
Рахуйте прийняті результати, суттєві виправлення, ескалації, скасування й хибні дії. Перевіряйте вибірку звичайних успішних запусків.
Повторюйте golden dataset із передзапускових тестів і порівнюйте версії.
Обмежуйте затримку та вартість
Вимірюйте час до корисної відповіді, повну тривалість, токени, зовнішні API та ручну перевірку.
Обмежте кроки, токени, повтори й паралельні виклики. Контролюйте вартість прийнятого результату.
Робіть алерти виконуваними
Сигнали мають вести до рішення: зайвий доступ, помилка схеми, повтор дії, зростання помилок або вартості, черга й падіння якості.
Алерт потребує власника, рівня, часу реакції, runbook і приглушення дублікатів.
Збережіть fallback і ручний стоп
Fallback може бути детермінованим процесом, read-only режимом, завданням людині або попередньою версією. Перехід тестують.
Важливі дії зупиняє зовнішній механізм. Human-in-the-loop включає погодження, скасування, rollback і аудит.
Розбирайте інциденти та near miss
Збережіть трасу, конфігурацію, входи, інструменти та наслідки. Визначте джерело проблеми.
Додайте висновок як тест, зміну контролю та завдання власнику.
Як я контролюю publishing-agent
У моєму конвеєрі модель не отримує загальну здатність «опублікувати». Процес створює чернетку, порівнює 21 поле, перевіряє мовні сторінки та посилання і лише потім переводить матеріал у published.
Траса розділяє текст, завантаження обкладинки, збережений запис і публічну сторінку. Будь-яка різниця зупиняє процес. Один робочий URL не доводить коректність усього ланцюга.
Питання та відповіді
Що контролювати спочатку?
Бізнес-результат, дії інструментів, помилки, затримку, вартість і ручні скасування.
Чи треба зберігати промпти?
Лише за необхідності й правомірної підстави. Мінімізуйте вміст, доступ і строк.
Як виявити цикл?
Обмежте кроки, повторні виклики, час і бюджет та зупиняйте на межі.
Чи достатньо dashboard?
Ні. Потрібні власник, поріг, канал повідомлення та перевірений порядок реакції.
Як часто робити evals?
Постійно за вибіркою, за розкладом і після суттєвих змін.
Операційний аркуш контролю
До погодження внесіть кожен контроль у таблицю: власник, доказ, поріг і дата наступної перевірки. Фраза «контролювати якість» не є виконуваною. Правило «операційний власник щопонеділка перевіряє частку суттєвих виправлень і ставить процес на паузу вище погодженого порога» можна перевірити.
Пов'яжіть контроль із наслідком для бізнесу. Якщо помилка схеми може пошкодити запис клієнта, опишіть containment і reconciliation. Якщо стрибок вартості пояснюється сезонним обсягом, задайте контекст проти хибної ескалації.
Версіонуйте промпти, схеми, політики, інструменти та зовнішні залежності. Результат без конфігурації неможливо відтворити. Винятки повинні мати причину, власника і строк завершення.
Відрепетируйте людський шлях. Власник має знайти докази, зупинити або обмежити workflow, увімкнути fallback і пояснити стан без прохання до AI діагностувати себе.