Главная мысль урока: у автоматизации с LLM два режима поломки — громкий (упало, все видят) и тихий (работает, отвечает «успех», но качество уехало). Громкий ловит обвязка из урока 19, тихий — только трейсы и регулярные проверки качества. Плюс две статьи расходов, которые не показывают в смете: «беговая дорожка моделей» (провайдеры выводят модели из эксплуатации — приходится переезжать) и поддержка после запуска. Без них расчёт окупаемости — самообман.
Трейсы: чёрный ящик самолёта для каждого прогона
Первое требование эксплуатации: каждый запуск автоматизации оставляет трейс — подробную запись полёта, как чёрный ящик: какие шаги выполнились, что вернула модель, сколько длилось, сколько стоило. Это вы уже знаете из урока 7 — теперь это пункт приёмки.
Стандарт открытых инструментов — Langfuse: иерархические трейсы каждого LLM-вызова и инструмента, фильтры по пользователю, стоимости, задержке; можно развернуть на своём сервере. Формулировка в ТЗ: «каждый прогон виден как трейс со стоимостью и задержкой; разбор любого инцидента начинается с трейса». (доки Langfuse)
Тихие поломки: весы, которые врут
Опаснейший режим отказа LLM-автоматизации: API отвечает «200 OK», мониторинг зелёный — а модель начала отвечать иначе. Классифицирует жалобы как вопросы. Пишет приветствия другим тоном. Как сломанные напольные весы: показывают всем 70 кг — «работают» же.
Аптайм-мониторинг такое не ловит в принципе: технически всё исправно. Ловят два инструмента: трейсы (видно, что именно отвечала модель) и регулярный прогон проверочного набора — те же evals из урока 7.
Проверочный набор — это 50–500 типовых случаев с известными правильными ответами, прогоняемых по расписанию. Ночной прогон стоит копейки, а дрейф качества показывает за дни до того, как его заметят клиенты.
Беговая дорожка моделей
Статья расходов, о которой не предупреждают: модели выводят из эксплуатации (deprecation). Anthropic закрыла Claude 3.5 Sonnet с ~2 месяцами предупреждения; OpenAI при запуске GPT-5 поначалу отключила старые модели вовсе без переходного периода. Ваша автоматизация, настроенная под конкретную модель, переезжает на новую — и ведёт себя иначе. (Model Deprecation Treadmill, апр. 2026)
Зрелая практика: пиннинг (фиксация конкретной версии модели, а не «последней») + прогон проверочного набора не только против текущей модели, но и против следующего кандидата. Тогда «дельта переезда» известна за недели до дедлайна, и миграция — плановая работа, а не пожар.
🔬 Под капотом: почему модель «дрейфует», даже если вы ничего не меняли
Откуда берётся тихая поломка, если код не трогали? Три источника. Первый: провайдер обновляет модель под тем же именем — у «умолчательных» алиасов поведение может измениться без предупреждения (поэтому пиннинг версии). Второй: меняется входящий поток — ученики начали спрашивать о новом курсе, которого нет в примерах промпта.
Третий, самый коварный: каскад. Вы поменяли промпт в одном шаге, чтобы починить кейс А — и незаметно сломали кейс Б, который полгода работал. Без проверочного набора это обнаружит клиент; с набором — ночной прогон.
Отсюда правило: у живой автоматизации проверочный набор — такой же обязательный артефакт, как код. Он растёт из инцидентов: каждая пойманная ошибка становится новым проверочным случаем, и больше не повторяется молча.
Окупаемость: честная таблица
Формула проста: экономия = (часы ручной работы × ставка) − полная стоимость владения. Самообман начинается, когда правую часть считают одной строкой «токены». Полная таблица:
Разбор инцидентов, донастройка промптов, переезды моделей
Часы подрядчика ежемесячно — спросите ставку заранее
Человек в контуре
Время на согласования и эскалации (урок 20)
Минуты в день × ставка — мало, но не ноль
И отрезвляющий контекст из отчёта MIT (300 внедрений): 95% корпоративных AI-пилотов не дали измеримого эффекта на прибыль. Главная причина — не модели, а то, что инструмент не встроили в реальный рабочий процесс. Перевод: автоматизация окупается не в момент запуска, а в момент, когда ей реально начали жить — и это отдельная работа. (Fortune об отчёте MIT)
Зачем это вам как заказчику
В приёмке: «покажите трейс любого прогона за вчера — со стоимостью». Нет трейсов — нет эксплуатации.
В ТЗ: проверочный набор (50+ случаев) и его регулярный прогон; каждая инцидентная ошибка добавляется в набор.
Спросите: «какая версия модели зафиксирована и что произойдёт, когда её выведут из эксплуатации?» Ответ «возьмём последнюю» = поведение системы меняется без вашего ведома.
Смета без строки «поддержка, часов/мес» — неполная. Уточните ставку до подписания, а не после первого инцидента.
Проверьте себя
Повторение урока 20. Ученики стали жаловаться, что бот поддержки «не даёт поговорить с человеком». По уроку 20, что здесь нарушено?
Верно! «Клиенту всегда должен быть доступен человек, если он хочет» — вывод, к которому Klarna пришла через публичный откат. Эскалация по запросу — обязательная часть дизайна.
Вежливость не лечит запертую дверь. Нарушен принцип гибрида из урока 20: автоматика забирает поток, но путь к человеку остаётся всегда — иначе повторите откат Klarna.
Автоматизация три месяца работала отлично. Код не меняли. Качество ответов поползло вниз. Какая причина НЕ могла этого вызвать?
Именно! «Возраст» сервера на LLM-качество не влияет — код не изнашивается. А вот модель под алиасом и дрейф входящего потока — два реальных источника тихих поломок, которые ловятся только проверочным набором.
Перечитайте «Под капотом»: дрейф приходит от провайдера (модель обновили) или от мира (поток изменился). Сервер от времени не «изнашивается» — это единственный вариант, который причиной быть не мог.
Почему аптайм-мониторинг («сервис отвечает? зелёная лампочка») не защищает LLM-автоматизацию?
Верно! Сломанные весы показывают 70 кг — «работают». Технически исправная система с уехавшим качеством — самая дорогая поломка: её месяцами не замечают. Лекарство — трейсы + регулярный eval-прогон.
Дело не в цене: аптайм просто измеряет не то. «Отвечает ли сервис» и «хорошо ли он отвечает» — разные вопросы; на второй отвечают только трейсы и проверочный набор.
Смета подрядчика: «разработка 300 тыс. ₽ + токены ~3 тыс. ₽/мес». Что в ней отсутствует?
Точно! «Сдал и забыл» с LLM не работает (вы это уже видели в RAG, урок 14): модели выводят из эксплуатации, поток дрейфует, промпты требуют донастройки. Поддержка — строка сметы, а не жест доброй воли.
Подписывать рано: нет строки поддержки. Беговая дорожка моделей и дрейф потока гарантируют регулярную работу после запуска — если её нет в смете, она появится в счетах как «доп. работы» по любой ставке.
Практика: посчитайте окупаемость одной автоматизации
🛠 Задание на 10 минут
Возьмите процесс из практик уроков 18–20. Оцените: сколько часов ручной работы в месяц он съедает сейчас и по какой ставке.
Спросите Claude Code: «Посчитай полную стоимость владения автоматизацией [процесс]: токены (типовой объём — [N] прогонов/мес), инфраструктура, поддержка, время человека на согласования. Сравни с ручной работой [X] часов × [Y] ₽. Когда окупится с учётом разработки? Какие статьи я мог недооценить?»
Отдельно спросите: «какие три проверочных случая ты бы заложил в eval-набор этой автоматизации с первого дня?» — это начало вашего набора.
Что дальше
Все участки блока пройдены: лестница решений → анатомия → надёжность → человек в контуре → эксплуатация. Финал — собрать это в раздел «Автоматизация» вашего ТЗ, с чеклистом заказчика.