ИИ прошёл все тесты, но всё равно ошибается у клиентов: почему так выходит
ИИ прошёл все тесты, но всё равно ошибается у клиентов: почему так выходит Инженер по качеству ПО с 19-летним стажем в IBM Раджешкумар Раджасекаран Наир объясняет, почему ИИ-система может пройти все проверки перед запуском и всё равно выдавать ошибки в продакшене — рабочей версии продукта, которой пользуются клиенты. По его словам, дело не в том, что тестировщики плохо работали, а в том, что к ИИ применяют привычные правила тестирования обычного софта, хотя ведёт он себя совсем иначе. Обычную программу проверяют просто: при тех же вводных должен быть тот же результат. С ИИ это не работает. На вопрос «почему мой платёж отклонён?» есть несколько одинаково правильных ответов — объяснить причины, уточнить данные или подсказать следующий шаг. Поэтому «сдал тест» перестаёт быть однозначным понятием: нужно проверять ещё точность фактов, уместность, безопасность и соответствие правилам бизнеса. Вторая причина — тестовая среда не совпадает с реальной. Автор приводит пример: ИИ поддержки протестировали на 1000 запросах, справился с 970 — команда отчиталась о 97% успеха. Но это касается только этих конкретных 1000 запросов. Живые пользователи пишут с ошибками, задают несколько вопросов сразу, меняют язык, вставляют простыни текста и спрашивают то, чего тестировщики не предвидели, а некоторые специально пытаются обойти инструкции ИИ. Третья особенность — генеративный ИИ (модели, которые создают текст, а не выполняют жёсткий сценарий) может отвечать на один и тот же вопрос по-разному. Четыре пересказа политики возврата из пяти могут быть верными, а пятый — с ошибкой. Если сценарий проверили один раз, тест пройден, но надёжность под вопросом. Важные сценарии автор советует прогонять многократно и оценивать не «прошёл или нет», а «насколько стабильно результат приемлемый». Ещё один источник сбоев — сама обвязка вокруг модели. Корпоративные ИИ-системы опираются на инструкции, базы знаний, поисковые сервисы, API (готовый способ программам обмениваться данными) и бизнес-правила. Модель может работать верно, но поиск подсунет устаревший документ, а интерфейс вернёт неполные данные. Для клиента всё это неважно — он просто получил неверный ответ. Поэтому проверять нужно всё приложение, а не только модель. Высокая точность тоже может скрывать риск. При 98% успеха на 100 000 обращений проблемными остаются 2000. Если это мелкие огрехи формулировок — одно, а если ошибки в финансовых операциях или неверные инструкции клиентам — совсем другое. Автор предлагает оценивать не только частоту сбоев, но и их последствия: редкий критический сбой важнее сотни мелких. Самый коварный сбой выглядит как нормальная работа. ИИ уверенно сообщает клиенту: «по политике компании у вас 90 дней на возврат» — хотя на деле только 30. Ничего не падает, мониторинг показывает исправную работу, но по смыслу система уже ошибается. Плюс система дрейфует со временем: меняются продукты, правила, поведение пользователей, обновляются базы знаний и версии модели — поэтому «проверено и готово» не навсегда, контроль должен продолжаться и после запуска. Что автор предлагает командам. Тестировать неудобные сценарии: расплывчатые запросы вроде «отмени это», противоречивые инструкции, очень длинные диалоги, попытки манипуляции — они показывают готовность к продакшену лучше сотни предсказуемых тестов. Оценивать ответы по нескольким измерениям, а не «зачёт/незачёт». Сделать мониторинг живой системы частью тестирования: каждый значимый сбой в продакшене превращать в новый тестовый сценарий. И заранее решать, что ИИ делает, когда не уверен — уточняет, отказывается или передаёт человеку; для критичных действий могут понадобиться дополнительные проверки или одобрение человеком. Источник: https://hackernoon.com/your-ai-passed-every-test-why-can-it-still-fail-in-production