Четыре года назад один завод отказался подписывать акт приёмки системы визуального контроля, потому что камера пропустила микроскопическую царапину на тёмном, смазанном от вибрации станков кадре. В договоре юристы написали классическое: «система должна выявлять брак на конвейере». Это был дорогой урок, показавший разницу между инженерией и фантазиями. Правильно составленное ТЗ на AI-проект, по которому реально примут работу: метрики, приёмочный порог и тестовый датасет — это не корпоративная формальность для закупщиков, а единственный способ зафиксировать физическую реальность и не встретиться в суде.
Классическая разработка софта детерминирована. Разработчик пишет CRUD-интерфейс: пользователь нажал кнопку — запись упала в базу. Написали автотесты, прогнали, сдали. Приёмка сводится к бинарной логике: функция либо работает, либо падает с ошибкой.
Машинное обучение вероятностно по своей природе. Нейросети не бывают «готовыми» на 100%, они оперируют распределениями и вероятностями. Если вы пишете ТЗ на ML в парадигме обычного софта, требуя абсолютной безошибочности, вы закладываете под проект бомбу замедленного действия.
ТЗ на AI-проект, по которому реально примут работу: метрики, приёмочный порог и тестовый датасет
Заказчики из сурового B2B любят ГОСТ 34.602-2020. Как каркас для требований к информационной безопасности, отказоустойчивости и интеграции со смежными системами он работает отлично. Но он абсолютно слеп к природе ИИ. ГОСТ предполагает, что работу системы можно описать конечным алгоритмом действий. В глубоком обучении алгоритм — это веса внутри матриц. Вы можете описать архитектуру сети, но не путь принятия решения по конкретному кадру.
Поэтому ГОСТ приходится «пропатчивать» жёсткой связкой: бизнес-цель, целевая метрика и порог. «Хорошо распознавать дефекты» — это лирика. Выбор правильной метрики — вопрос выживания. Если вы используете Accuracy (долю правильных ответов) для задачи, где брак составляет 1% от потока, то модель, которая тупо всегда выдаёт «брака нет», получит точность 99%. Отлично на бумаге, катастрофа в цеху.
Инженерия начинается там, где появляются Precision (точность), Recall (полнота) или MAPE (для регрессий). «Recall не ниже 98% при Precision не ниже 95%» — вот язык, на котором бизнес разговаривает с ML.
Дальше идёт физика. Нефункциональные требования в AI — это не абстрактное «интерфейс должен не тормозить». Это хардкорные лимиты железа и сети. Если данные не должны покидать периметр предприятия, забудьте про облачные API. Модель будет крутиться на edge-устройстве или локальном сервере, и здесь нужно прописывать цифры:
- Latency: время инференса строго до 30 мс на кадр.
- Throughput: обработка видеопотока не менее 60 FPS.
- Энергопотребление: не более 15 Вт для локальной NPU, потому что в закрытом шкафу без активного охлаждения мощная карта сгорит через час.
Никакие метрики не имеют смысла без зафиксированного тестового датасета. Это гранитный фундамент приёмки. Подрядчик может обучать модель на аугментациях, синтетике или опенсорсных базах, но сдаёт работу он строго на скрытой выборке (hold-out). Эту выборку заказчик собирает на своём реальном оборудовании, размечает и прячет в сейф до дня приёмки. Нет скрытого датасета от заказчика — нет объективных критериев сдачи проекта.
Протокол приёмки в цифрах и цена exploratory-фазы
Описать критерии приёмки в цифрах — значит зафиксировать протокол. Жёсткий шаблон снимает любые разночтения на этапе сдачи:
| Параметр | Требование в ТЗ |
|---|---|
| Бизнес-сценарий | Детекция дефекта «скол» на линии розлива №2 |
| Тестовый набор | 5000 кадров (2500 с дефектом, 2500 без). Набор недоступен исполнителю до этапа приёмки |
| Целевая метрика | F1-score |
| Приёмочный порог | F1-score >= 0.94 |
| Условия среды | Освещенность 300-500 люкс, скорость конвейера 1.5 м/с |
А теперь про честный трейд-офф. ЛПР часто требует зафиксировать SLA по точности ещё до подписания договора, не показав сырые данные. Это не работает.
Если вы требуете гарантированный порог без предварительной exploratory-фазы (исследовательского R&D на ваших данных), грамотный подрядчик сделает одно из двух. Либо он умножит смету в три-четыре раза, закладывая финансовые риски на вытягивание неразмечаемого мусора. Либо просто откажется от проекта. Никто не подпишется под гарантиями законов оптики, пока не увидит реальные блики на ваших камерах и шум в логах датчиков. Правильный путь: сначала пилотное исследование и оценка достижимости метрик — затем фиксация приёмочных порогов в основном ТЗ.
Допустим, вы всё сделали правильно. Сдали модель. Подписали акт по протоколу. Отлично.
Только через два месяца оптика на камере запылится, освещение в цеху поменяют на светодиодное, а поставщик сырья изменит текстуру материала. И ваша идеально принятая по ТЗ метрика рухнет. Но это уже история про production ML, мониторинг деградации данных и MLOps, без которых любая, даже самая точная нейросеть, со временем превращается в тыкву.