Четыре года назад один завод отказался подписывать акт приемки системы визуального контроля, потому что камера пропустила микроскопическую царапину на темном, смазанном от вибрации станков кадре. В договоре юристы написали классическое: «система должна выявлять брак на конвейере». Это был дорогой урок, показавший разницу между инженерией и фантазиями. Правильно составленное ТЗ на 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, без которых любая, даже самая точная нейросеть, со временем превращается в тыкву.