Проверка качества функции с ИИ

ИИ-функция может впечатляюще сработать на демонстрации и ошибиться на обычном клиентском материале. Её ответ иногда меняется при повторном запуске, а убедительный тон не показывает правильность. Поэтому проверять нужно конкретное поведение продукта в заданной задаче, включая случаи, когда системе следует остановиться или запросить уточнение.

Начните с обещания пользователю: что функция делает, какие данные получает и кто принимает окончательное решение. «Помогает подготовить черновик» и «автоматически отправляет готовый ответ клиенту» требуют разного уровня контроля, даже если внутри используется одна модель.

Опишите результат и недопустимые ошибки

В учебном примере сервис извлекает из письма клиента дату, адрес и состав заказа, чтобы сотрудник подготовил подтверждение. Хороший результат сохраняет факты, отмечает отсутствующие сведения и не добавляет выдуманные позиции. Сотрудник проверяет черновик перед отправкой.

Разделите ошибки по последствиям. Неудачная формулировка, неверная дата и раскрытие данных другого клиента не равноценны. Общая доля «хороших ответов» может скрывать редкую, но недопустимую проблему.

Согласуйте критерии с человеком, который понимает предметную область. Для каждого поля или действия запишите, что считается верным, что требует уточнения и что блокирует применение. Если эксперты расходятся, сначала уточните правило, иначе оценка модели будет зависеть от проверяющего.

Соберите набор реальных по структуре ситуаций

Включите обычные запросы, неполные данные, противоречия, длинные материалы, опечатки и случаи вне обещанной задачи. Используйте допустимые данные, удаляя лишние личные сведения. Удобные примеры автора функции не представляют всё будущее использование.

Добавьте проверки воздействия посторонних указаний внутри обрабатываемого текста. Письмо или документ может содержать фразу, предлагающую игнорировать правила продукта. Система должна сохранять границы своей задачи и полномочий, а не считать любое содержимое входного файла управляющей командой.

NIST обращает внимание на проверку до внедрения и на разрыв между лабораторными тестами и реальными условиями применения. Для малого продукта это означает необходимость проверять именно свои задачи, материалы и последствия ошибок, а не ссылаться только на общий рейтинг модели.

Сделайте оценку воспроизводимой

Для каждого примера сохраните входные данные, ожидаемые обязательные признаки и допустимые варианты ответа. Полное совпадение текста часто не нужно: два разных черновика могут одинаково правильно передавать факты. Но дата или сумма должны оцениваться по точному правилу.

Записывайте версию модели, инструкции, настройки, используемые источники и дату проверки. Прогоняйте неоднозначные и важные случаи несколько раз. Один успешный ответ не показывает устойчивость поведения.

Часть примеров оставьте для независимой проверки после доработок. Если бесконечно подстраивать инструкцию под один известный набор, можно улучшить результат на нём и не улучшить работу с новыми материалами. Обнаруженные реальные ошибки затем добавляйте в постоянный набор повторной проверки.

Оцените всю функцию, а не только ответ модели

Проверьте, правильно ли продукт передаёт исходные данные, показывает отсутствие ответа, обрабатывает задержку и сохраняет изменения пользователя. Хороший текст бесполезен, если интерфейс подставил его не в тот заказ.

Измеряйте время до результата, стоимость и объём исправлений сотрудника. Автоматическая оценка другой моделью может помогать сортировать ответы, но её саму нужно сопоставить с человеческой проверкой. Она способна пропускать ошибки того же типа.

В учебном тесте из 100 ответов 97 признаны приемлемыми. Один из оставшихся содержит сведения чужой организации. Общие 97% не дают основания выпускать такую версию: критический дефект требует устранения. Отсутствие подобных ошибок в следующем небольшом тесте тоже не доказывает их невозможность.

Тест

Из 100 ответов 97 приемлемы. Один из остальных содержит сведения чужой организации. 97% выпуск не разрешают.

Отсутствие такой ошибки в следующем небольшом тесте не доказывает, что она невозможна.

Установите порядок выпуска и наблюдения

До запуска согласуйте, какие результаты допускают ограниченное использование, какие требуют обязательной проверки человеком и какие останавливают выпуск. Укажите круг пользователей, поддерживаемые случаи и доступный способ сообщить об ошибке.

Для действий с существенными последствиями проверьте, имеет ли человек время, информацию и полномочия заметить ошибку. Кнопка «подтвердить» не обеспечивает контроль, если сотрудник вынужден нажимать её без чтения.

После изменения модели, инструкции или базы материалов повторяйте проверки. Сохраняйте возможность отключить функцию или вернуться к предыдущей версии. Назначьте ответственного за сообщения об ошибках и наблюдайте за реальными отказами, а не только за средней оценкой.

Практическое задание

Выберите одну ИИ-функцию и опишите обещание, границы и критические ошибки. Подготовьте набор обычных и сложных случаев с правилами оценки, проведите повторные прогоны и независимую проверку части результатов. Составьте решение о допуске: что уже можно использовать, где нужен человек, какие дефекты блокируют запуск и как функция будет отключена при проблеме.