Пилот «считается» только тогда, когда заранее согласованные числовые пороги выполнены на реальных данных заказчика. Четыре оси проверки — accuracy, latency, edge cases, бизнес-метрика. Без акта с цифрами приёмка превращается в переговоры о субъективных ощущениях. ```markdown --- slug: pilot-kriterii-priemki type: playbook format: flagship title: "Критерии приёмки пилота: когда результат «считается»" summary: "Фреймворк приёмки ИИ-пилота: accuracy, latency, edge cases, бизнес-метрика. Шаблон акта и антипаттерны «работает на демо, падает в проде»." seoTitle: "Критерии приёмки ИИ-пилота: фреймворк и шаблон акта" datePublished: 2026-07-20 tags: [пилот, приёмка, ИИ, фреймворк, качество, метрики, LLM, автоматизация] relatedService: /uslugi relatedServiceLabel: Услуги brezatech relatedCase: relatedCaseLabel: ogImage: /assets/blog/pilot-kriterii-priemki-og.svg imagePrompt: "Офисный стол с распечатанным актом приёмки, рядом ноутбук с дашбордом метрик accuracy и latency, стакан кофе, деловая атмосфера, дневной свет, без абстрактного AI-свечения" keyFacts: - "По данным Gartner, до 85% ИИ-проектов не доходят до промышленной эксплуатации — чаще всего из-за отсутствия формальных критериев приёмки." - "«Работает на демо» и «работает в проде» — разные состояния: демо-данные чище, объём меньше, edge cases убраны вручную." - "Бизнес-метрика (время обработки, конверсия, экономия FTE) должна быть зафиксирована до старта пилота, иначе приёмка превращается в переговоры." - "Latency — часто игнорируемый критерий: модель с accuracy 95% и ответом 8 секунд неприменима в операционном потоке." - "Акт приёмки с числовыми порогами защищает обе стороны: заказчика от «почти готово», исполнителя от бесконечных доработок." faq: - q: "Что такое критерии приёмки пилота?" a: "Это заранее согласованные числовые пороги и условия, при выполнении которых пилот считается успешным: точность модели, время отклика, покрытие edge cases и изменение бизнес-метрики." - q: "Чем отличается приёмка ИИ-пилота от приёмки обычного ПО?" a: "ИИ-системы имеют вероятностный выход — нельзя написать детерминированный тест «всегда верно». Поэтому приёмка строится на статистических порогах, тест-сетах и мониторинге дрейфа данных." - q: "Когда фиксировать критерии приёмки?" a: "До начала разработки, в рамках discovery или технического задания. Критерии, согласованные после демо, всегда смещаются в пользу исполнителя." - q: "Что делать, если модель прошла приёмку, но в проде деградировала?" a: "Это отдельный сценарий — дрейф данных. Акт приёмки должен включать период гарантийного мониторинга (обычно 30–90 дней) с пороговыми алертами." - q: "Можно ли принять пилот частично?" a: "Да. Практика условной приёмки фиксирует, какие критерии выполнены, какие — нет, и устанавливает срок устранения. Это честнее, чем бинарное «принято/отклонено»." sources: - "Gartner, «AI Project Failure Rates», 2023" - "Martin Fowler, «Evals for LLM Applications», martinfowler.com, 2024" mentions: - Gartner - Martin Fowler aboutBrezatech: "brezatech — интегратор ИИ в данные и процессы: разработка LLM-решений, BI, автоматизация документооборота для B2B-компаний в РФ." --- Почему «работает на демо» — не критерий Почти каждый ИИ-пилот проходит одинаковый путь: впечатляющая демонстрация → энтузиазм команды → первые недели в проде → разочарование. Причина не в плохой модели. Причина в том, что демо и прод — принципиально разные среды. На демо: • данные отобраны вручную или очищены заранее, • объём — десятки примеров, не тысячи, • «неудобные» случаи убраны из выборки, • оператор рядом и может скорректировать запрос. В проде: • данные приходят из живых систем с опечатками, дублями, нестандартными форматами, • нагрузка в часы пик в 10–50 раз выше демо-стенда, • пользователь не знает «правильных» формулировок, • никто не стоит рядом с кнопкой «перезапустить». Это не вопрос доверия к исполнителю. Это структурная проблема: без формальных критериев приёмки обе стороны смотрят на разные вещи и называют их одним словом — «работает». Четыре оси фреймворка приёмки Хороший акт приёмки ИИ-пилота проверяет систему по четырём независимым осям. Ни одна из них не заменяет остальные. Ось 1. Accuracy — точность на реальных данных {#accuracy} Accuracy — самый очевидный критерий, но чаще всего измеряемый неправильно. Типичная ошибка: точность считается на тех же данных, на которых модель обучалась или настраивалась. Это называется data leakage и делает метрику бессмысленной. Правильный подход: • Тест-сет формирует заказчик, не исполнитель. Минимум 200–500 примеров, отражающих реальное распределение запросов. • Метрика выбирается под задачу: для классификации — F1 или precision/recall в зависимости от цены ошибки; для генерации текста — human eval или специализированные LLM-as-judge; для извлечения данных — exact match + partial match. • Порог фиксируется заранее: например, «F1 ≥ 0.87 на тест-сете из 300 документов, предоставленных заказчиком». Важный нюанс: для разных классов ошибок цена разная. Если модель извлекает реквизиты из договоров, ошибка в сумме контракта критичнее, чем ошибка в названии города. Это должно быть отражено в весовых коэффициентах метрики. Ось 2. Latency — время отклика под нагрузкой {#latency} Latency — наиболее часто игнорируемый критерий на этапе пилота. Модель, которая отвечает за 8 секунд, технически «работает», но неприменима в операционном потоке, где оператор обрабатывает 200 документов в день. Что измерять: • P50 и P95 latency — медиана и 95-й перцентиль времени ответа. P95 важнее: именно он определяет пользовательский опыт в худших 5% случаев. • Нагрузочный тест: не единичный запрос, а конкурентная нагрузка, соответствующая реальному пиковому использованию. • Деградация под нагрузкой: некоторые системы держат P50 хорошо, но P95 растёт экспоненциально при увеличении RPS. Пример порога: «P95 latency ≤ 3 секунды при конкурентной нагрузке 20 одновременных запросов». Ось 3. Edge cases — устойчивость на граничных случаях {#edge-cases} Edge cases — это место, где большинство пилотов падают в проде. Граничные случаи не случайны: они предсказуемы, если потратить время на их каталогизацию до начала разработки. Типичные категории edge cases для ИИ-систем: Категория | Пример Нестандартный формат входа | Скан низкого качества, рукописный текст, PDF с таблицами Пустой или неполный ввод | Документ без обязательных полей Языковые аномалии | Смешение языков, жаргон, аббревиатуры отрасли Граничные значения | Очень длинный документ, очень короткий запрос Противоречивые данные | Два разных значения одного поля в одном документе Атипичный бизнес-сценарий | Нестандартный тип договора, исключение из правил Критерий приёмки по edge cases формулируется так: «Система корректно обрабатывает или явно сигнализирует об ошибке в 100% случаев из каталога edge cases (не менее 30 сценариев, согласованных с заказчиком)». Молчаливый неверный ответ хуже явной ошибки — это тоже должно быть зафиксировано. Ось 4. Бизнес-метрика — измеримое изменение {#business-metric} Это самая важная ось и одновременно самая сложная для измерения. Бизнес-метрика отвечает на вопрос: «Что изменилось в операционной реальности заказчика?» Примеры бизнес-метрик по типу задачи: Задача | Бизнес-метрика Обработка входящих документов | Среднее время обработки одного документа (мин) Классификация обращений | Доля обращений, маршрутизированных без участия оператора (%) Генерация отчётов | Время подготовки отчёта (часы) Поиск по базе знаний | Время поиска ответа на типовой вопрос (мин) Верификация данных | Количество ошибок, пропущенных в проде (шт/месяц) Ключевое правило: бизнес-метрика измеряется до старта пилота (baseline) и после. Без baseline невозможно доказать улучшение. Если baseline не зафиксирован, его придётся реконструировать по памяти — и это всегда предмет спора. Шаблон акта приёмки Акт приёмки — не формальность. Это документ, который защищает обе стороны: заказчика от «почти готово», исполнителя от бесконечных доработок без чёткой цели. Минимальная структура акта: 1. Идентификация • Название пилота, версия системы, дата тестирования • Состав тест-сета (количество примеров, источник, дата формирования) • Ответственные лица с обеих сторон 2. Результаты по осям Критерий | Порог (согласован) | Результат | Статус F1 на тест-сете заказчика | ≥ 0.87 | 0.91 | ✓ Выполнен P95 latency (20 RPS) | ≤ 3 сек | 2.4 сек | ✓ Выполнен Edge cases (30 сценариев) | 100% обработаны | 28/30 | ✗ Не выполнен Время обработки документа | ≤ 4 мин | 3.2 мин | ✓ Выполнен 3. Детализация несоответствий • Описание каждого невыполненного критерия • Оценка критичности (блокирующее / некритичное) • Предложение по устранению и срок 4. Решение • Принято / Условно принято (с перечнем доработок и сроком) / Отклонено 5. Гарантийный период • Срок мониторинга в проде (рекомендуется 30–60 дней) • Пороговые значения для алертов о деградации • Порядок реагирования Антипаттерны, которые разрушают приёмку Антипаттерн 1: Критерии согласуются после демо Исполнитель показывает результат, заказчик впечатлён — и только потом начинается разговор о метриках. В этот момент планка неосознанно выставляется «чуть ниже того, что уже показано». Критерии должны быть зафиксированы до первой строки кода. Антипаттерн 2: Тест-сет формирует исполнитель Если исполнитель сам выбирает, на чём тестировать, — это не независимая оценка. Тест-сет должен отражать реальное распределение данных заказчика, включая «неудобные» случаи. Антипаттерн 3: Только accuracy, без latency Модель с точностью 96% и временем ответа 12 секунд не пройдёт операционную нагрузку. Latency — такой же обязательный критерий, как точность. Антипаттерн 4: Нет baseline для бизнес-метрики «Стало быстрее» — не измеримый результат. «Время обработки снизилось с 7 до 3 минут» — измеримый. Без baseline второй формулировки не существует. Антипаттерн 5: Акт подписывается «в целом всё хорошо» Размытые формулировки в акте — источник конфликтов через 3 месяца, когда система деградировала или появились новые требования. Каждый критерий — число, каждое число — порог. Как выстроить процесс приёмки внутри компании Если вы принимаете ИИ-решения регулярно — от внешних интеграторов или внутренней команды — имеет смысл стандартизировать процесс. Минимальный чеклист для любого ИИ-пилота: • До старта: зафиксировать baseline бизнес-метрики, согласовать тест-сет, прописать пороги по всем четырём осям в ТЗ или отдельном приложении. • В процессе: промежуточные срезы accuracy на реальных данных (не только на синтетике), логирование всех запросов для последующего анализа edge cases. • На приёмке: независимое тестирование силами заказчика или третьей стороны, нагрузочный тест в условиях, близких к проду. • После приёмки: мониторинг дрейфа данных и деградации метрик в течение гарантийного периода. Этот процесс работает независимо от того, кто делает пилот: внешний интегратор, внутренняя команда или облачный вендор с готовым решением. Критерии приёмки — это язык, на котором бизнес разговаривает с технологией. --- Связанные материалы в блоге brezatech: • Как выбрать интегратора ИИ: 7 вопросов до подписания договора • LLM в проде: что идёт не так после пилота • BI-дашборд для операционного контроля: метрики, которые важны ```