Чтобы получить 99% точности на партии изделий, иногда не нужна нейросеть. Достаточно всегда отвечать: «Брака нет».
Если в партии тысяча изделий и только десять дефектных, такой ответ окажется правильным 990 раз. Все десять дефектов при этом уйдут дальше.
Это учебный пример, но арифметика настоящая. Она объясняет, почему разговор с AI-подрядчиком стоит начинать с определения результата. Число «99%» без состава данных и видов ошибок слишком мало говорит о будущей работе системы.
Ниже разберем, что запросить после демонстрации и как превратить обещание в условия пилота.
Сначала расшифруйте слово «точность»
На тех же учебных тысяче изделий сравним два варианта. Первый считает годным все подряд. Второй находит восемь дефектов из десяти, но ошибочно отправляет на проверку двадцать годных изделий.
| Результат на одной партии | Всегда отвечает «норма» | Находит часть дефектов |
|---|---|---|
| Дефект найден | 0 | 8 |
| Дефект пропущен | 10 | 2 |
| Годное изделие ошибочно признано дефектным | 0 | 20 |
| Годное изделие верно признано годным | 990 | 970 |
У первого варианта общая доля правильных ответов, accuracy, составляет 990 / 1 000 = 99%. У второго — (8 + 970) / 1 000 = 97,8%.
Но recall, доля найденных дефектов среди всех дефектных изделий, у первого равна нулю. У второго — 8 / 10 = 80%. Его precision, доля настоящего брака среди всех срабатываний, равна 8 / (8 + 20) ≈ 28,6%. У первого варианта precision по этой формуле не определена: срабатываний нет, знаменатель равен нулю.
Определения метрик и проблему редкого класса разбирает официальный курс Google по машинному обучению. Для покупателя практический смысл простой: попросите четыре числа из таблицы ошибок. Они дадут больше пищи для разговора, чем один крупный процент на слайде.
Второй вариант еще нельзя объявить подходящим. Возможно, двадцать лишних проверок допустимы. Возможно, они остановят участок. И восемь найденных дефектов — слишком мало наблюдений, чтобы уверенно судить о качестве на всех будущих партиях.
Одна ошибка может стоить дороже сотни других
Для продолжения примера зададим условные последствия: проверка ложной тревоги обходится в 300 рублей, пропущенный дефект — в 20 тысяч. Это допущения, без учета стоимости самой системы.
У варианта «всегда норма» потери на партии составят 10 × 20 000 = 200 тысяч рублей. У второго — 2 × 20 000 + 20 × 300 = 46 тысяч.
Разница выглядит убедительно. Но если пропуск на конкретном участке стоит 500 рублей, числа станут другими: 5 тысяч против 7 тысяч. При таких вводных второй вариант увеличит прямые потери от ошибок.
Поэтому вопрос «Какую точность вы гарантируете?» полезно заменить более содержательным: «Какие ошибки останутся, сколько их ожидается и что будет происходить после каждой из них?»
Стоимость ошибки нужно собирать вместе с владельцем процесса. Не каждый пропуск приводит к полной стоимости брака, не каждая тревога требует остановки. Подставлять максимальный ущерб во все случаи — верный способ переоценить пользу проекта.
Какие данные показали на демонстрации
Попросите описать происхождение выборки: откуда изображения, за какой период, кто подтвердил правильные ответы и какие случаи исключили. Затем уточните, использовались ли эти примеры при настройке системы.
Для видеопотока разделение особенно легко сделать формальным: соседние кадры одной детали попали и в обучение, и в тест. Файлы разные, ситуация практически одна. Для проверки переноса на будущую работу полезнее отделять партии, периоды или объекты так, чтобы тест соответствовал реальному сценарию применения.
Состав редких событий тоже заслуживает отдельного разговора. Допустим, из десяти дефектов девять — крупные царапины, один — небольшой скол. Общая доля обнаружений мало расскажет о каждом виде брака.
Запишите пропуски в доказательствах: «Нет проверки на ночной смене», «Не представлены мокрые поверхности», «Не согласована разметка спорных случаев». Это будущие задания для пилота. Делать из каждого пробела обвинение подрядчику не нужно: демонстрация могла решать более узкую задачу.
Проверьте путь от входных данных до действия
Фраза «Модель отвечает за 40 миллисекунд» может относиться к уже подготовленному изображению в памяти сервера. В вашей системе сначала нужно получить кадр, передать его, поставить в очередь, обработать результат и отправить команду оборудованию.
Уточните начало и конец измерения задержки. Попросите показать работу на целевом оборудовании и при ожидаемой нагрузке, включая пики. Среднее время скрывает отдельные долгие ответы; для процесса с жестким сроком реакции нужны и распределение задержек, и число пропущенных сроков.
После изменения модели, размера входного изображения или режима вычислений проверку качества повторяют. Направление и величину изменения заранее не угадывают по названию оптимизации.
Не менее важен режим отказа. Кто получает задание, если камера недоступна? Что делает линия, если ответ не пришел? Как сотрудник замечает, что автоматическая проверка прекратилась? Удачная демонстрация распознавания эти вопросы не закрывает.
Протокол, который можно заполнить после встречи
В учебном примере запись по демонстрации будет выглядеть так:
| Заявление | Что сейчас известно | Что проверить дальше |
|---|---|---|
| «Находим 80% дефектов» | Найдено 8 из 10 в одной подготовленной партии | Проверка по видам дефекта и условиям съемки на отдельной выборке; оценка неопределенности |
| «Ложных тревог немного» | 20 тревог на 990 годных изделий | Загрузка проверяющего сотрудника и стоимость разбора на целевом потоке |
| «Успеваем за линией» | Измерено только время модели | Полная задержка и пропущенные сроки при рабочей нагрузке |
| «Готово к внедрению» | Показан экран с результатами | Передача события, журнал, ручной режим и восстановление после сбоя |
Следом назначьте владельцев проверки. Технолог определяет допустимый брак и последствия ошибок. Представитель заказчика дает доступ к данным и согласует условия. Исполнитель воспроизводит измерения и передает результаты по каждому случаю.
Критерии продолжения договоритесь записать до пилота: какие дефекты проверяем, какая нагрузка допустима для ручного контроля, что считаем достаточными данными. Если редких событий не набралось, результат может быть «данных недостаточно». Пилот не обязан закончиться рекомендацией внедрять.
С чем идти в MoranaLabs
Если вам нужен ответ о работе системы на своем потоке, начните с обсуждения AI-пилота. Согласуем задачу, данные, измерения и условия следующего этапа. Результат относится к проверенным условиям; перенос на другие площадки и режимы потребует отдельной оценки.
Если до эксперимента нужно разобраться в предложении другого поставщика, можно заказать проверку материалов в аналитическом отделе. Соберем заявления, пересчитаем представленные метрики и подготовим вопросы с проектом критериев пилота.
Для первого разговора достаточно описать, что система должна замечать и что происходит, когда она ошибается. Качество, которое имеет смысл покупать, начинается с этих двух ответов.