Критериями приёмки называют проверяемые условия, по которым работу считают сделанной. Их записывают до начала работ, так чтобы заказчик и подрядчик прочитали их одинаково и могли проверить результат без спора.
«Бот отвечает клиентам» критерием не является: под это описание подходит любой бот, включая тот, что отвечает невпопад. «Бот отвечает на вопросы из утверждённого списка, остальные передаёт менеджеру в течение минуты» уже является. Его можно проверить, и после проверки не останется предмета для спора.
У рабочего критерия четыре признака. Он проверяемый: на него можно ответить «да» или «нет» или измерить. Он проверяется на ваших данных, со всеми их особенностями. У него есть порог, ниже которого работа не принята. И заранее известно, кто проверяет и как. Удобно записывать каждый критерий одной фразой: что проверяем, на каких данных, каким способом и какой результат достаточен. Например: «Сумма и номер счёта распознаны верно на всех документах тестового набора, проверяет бухгалтер по оригиналам».
Обычная программа на одни и те же данные отвечает одинаково. Модель может ответить по-разному, и на трёх удачных примерах любая демонстрация выглядит отлично. Поэтому критерий для ИИ почти всегда описывает долю: на скольких документах из тестового набора результат верный, сколько ошибок допустимо.
Ошибки тоже неравноценны. Опечатка в комментарии и неправильная сумма в счёте считаются по-разному, и это тоже надо записать. Иногда допустимая доля ошибок для одного поля ноль, а для другого вполне терпимая, если такие случаи уходят на проверку человеку.
И ещё одно. Критерий стоит привязывать к результату для работы, одного качества модели мало. Модель может распознавать почти всё верно, а время сотрудника на задачу не изменится, потому что он всё равно перепроверяет каждый документ.
В ТЗ пишут «удобный интерфейс» и «высокое качество распознавания», подрядчик сдаёт то, что получилось, и спорить не с чем. Критерии пишут после сдачи и подгоняют под результат. Критерии пишет сам подрядчик, и он, разумеется, записывает то, что точно выполнит. Проверяют, что функции есть, и не проверяют, решают ли они задачу.
От отсутствия критериев страдают обе стороны. Исполнитель тоже не может сдать работу: результат заранее не определили, поэтому он каждый раз оказывается «не совсем тем», и доработки идут по кругу. В больших компаниях с формальной приёмкой такое случается редко, с частными клиентами и небольшим бизнесом чаще. Критерии защищают заказчика от работы, сделанной как получилось, а исполнителя от проекта, который невозможно закончить.
Споров о приёмке в моих проектах не случалось. Зато есть история, где не записали, что считать успехом. Сортировку входящей почты, о которой я писал в статье про аудит процессов, мы делали без такой записи: сколько часов в день должно освободиться, какая доля писем может попасть не в ту папку. Поэтому на вопрос, окупилась ли работа, ответа нет до сих пор.
Набор тестовых примеров из ваших настоящих данных, включая неудобные. Что считается ошибкой и какие ошибки критичны. Порог для каждого критерия. Как работа идёт сейчас, чтобы было с чем сравнить, это удобно делать на пилоте. Кто принимает работу и что происходит, если она не прошла.
Всё это входит в спецификацию. Критерии без спецификации проверяют неизвестно что. Спецификация без критериев не даёт способа проверить результат.
Связанные термины: Спецификация для ИИ · Пилот · Human-in-the-loop · Галлюцинация
Сможете проверить, что подрядчик сделал то, за что вы платите? Спецификация для ИИ →