Как получить желаемый результат от внедрения ИИ: роль тестирования

Денис Воденеев Директор отделения функционального тестирования группы компаний IBS

Развитие рынка ИИ

Уровень внедрения ИИ среди российских компаний вырос с 20% в 2021 году до 43-74% в 2024 году в зависимости от сегмента и методики подсчета. Среди крупнейших игроков 54% уже внедрили ИИ-решения хотя бы в одну бизнес-функцию.

Между тем глобальная статистика показывает, что более 80% ИИ-проектов терпят неудачу из-за системных проблем. Основные из них:

• неготовность ИТ-инфраструктуры,
• недостаток качественных данных,
• несоответствие результата планам,
• завышенные ожидания руководства от возможностей ИИ.

Сложности в обеспечении качества ИИ-решений

Классическая разработка ПО включает обязательный блок тестирования. В рамках него проводится проверка на соответствие фактического результата ожидаемому. Это позволяет выводить в продуктивную среду решения, которые полностью удовлетворяют предъявляемым к ним требованиям.

Однако при разработке систем с ИИ-аугментациями процент выделения функции тестирования пока критически мал. Как показывают наблюдения, чаще всего проводится A/B-тестирование потенциальными пользователями. Там же, где все-таки привлекаются отдельные специалисты, им приходится оперативно обучаться специфике ИИ-систем, на ходу разрабатывать метрики для оценки качества, а результат тестирования не всегда учитывает все показатели системы, которые могут повлиять на ее бизнес-эффект. Например, процент правильных ответов от общего количества или время отклика при массовом использовании.

Наиболее распространенный подход — субъективная оценка со стороны фокус-группы, в состав которой входят эксперты по тематике системы. Причем в подавляющем количестве случаев группа включает всего трех специалистов.

Можно выделить несколько трудностей в обеспечении качества систем с использованием ИИ:

• отсутствие полноценного тестирования в процессе разработки;
• частые обновления ИИ-моделей;
• недостаток понимания объекта и процесса тестирования.

Риски при использовании ИИ без тестирования

Основной риск от внедрения непроверенного решения в том, что фактические результаты проекта могут не соответствовать запланированным, несмотря на большие затраты. Завышенные ожидания от технологии — одна из главных проблем, затем идут классические риски: финансовые, репутационные и прочие, только помноженные на ИИ. Вот только несколько примеров за 2024 год.

McDonald's завершил эксперимент с ИИ-решением в точках drive-through. Система, разработанная IBM, неконтролируемо увеличивала размер заказов. В одном вирусном видео ИИ предложил клиенту 260 наггетсов вместо стандартной порции. Проект был свернут более чем на 100 локациях из-за неспособности решения корректно функционировать.

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

В том же году канадский суд обязал Air Canada компенсировать ущерб клиенту, которому чат-бот предоставил неверную информацию о льготных тарифах. Авиакомпания утверждала, что чат-бот является «отдельной юридической единицей», но суд отклонил этот аргумент. Дело установило прецедент: компании несут полную ответственность за действия своих ИИ-систем.

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

В то же время у ИИ есть ограничения, которые не до конца понятны. Как пример, недавний кейс с генератором «случайных чисел» в ИИ, когда разные модели при просьбе назвать любое число от 1 до 50 снова и снова выдавали 27.

Особенности тестирования ИИ

Такие аспекты, как некоторая «вольность» при реализации задачи со стороны ИИ и вариативность взаимодействия пользователя с самой системой, нельзя оставлять без внимания при тестировании ИИ-решений, но и классические направления остаются актуальными.

Функциональное тестирование позволяет проверить, работает ли система, как ожидается, и не делает ли того, что не должна. Нагрузочное тестирование ответит на вопросы: сколько пользователей могут работать с этим решением, насколько быстро оно дает отклик, какое требуются оборудование для его эффективной работы. Учитывая скорость появления новых ИИ-архитектур и моделей, особенно важным становится регрессионное тестирование. Недостаточно просто подтвердить, что ИИ-инструмент успешно встроился в ИТ-ландшафт, надо убедиться, что он продолжает выполнять функции после выхода новой модели. Проблема деградации после обновлений встречается даже у известных чат-ботов.

Есть и более специфичные подходы к проверке ИИ-решений. Например, метаморфное тестирование помогает находить ошибки в работе ИИ за счет сравнения результатов программы на исходных и модифицированных входных данных. Хотя тестировщик не может знать фиксированный итоговый результат, он понимает, что должно произойти с входной информацией в процессе обработки. Его задача — найти инварианты (свойства, которые должны сохраняться при трансформациях входных данных), определить метаморфозы для разных инвариантов и провести проверку.

ИИ-модели принимают решения на основе данных. Если данные, на которых проходило обучение или дообучение, содержат искажения, итоговые результаты могут быть некорректными, как в случае с Google. С помощью биас-тестирования (Bias Testing) можно выявить и измерить систематические смещения в алгоритмах и данных.

При тестировании ИИ-решений, кроме классического стека инструментов, используются дополнительные. Например, фреймворк LangTest позволяет выявлять смещения (bias), оценивать справедливость модели и отсутствие дискриминаций по расе, полу, возрасту и т. д. (fairness) и проверять ее устойчивость к неблагоприятным условиям (robustness). Среди других специализированных решений можно выделить Deepchecks — Python-библиотеку с открытым исходным кодом для комплексного тестирования моделей и данных, а также Inspect-AI — библиотеку для анализа результатов генерации, в рамках которой для верификации можно использовать другие модели.

Тестирование ИИ-решений проводится на разных этапах проекта в зависимости от контекста. В одних случаях уместнее подход Shift Left (тестирование в начале процесса разработки), в других — Shift Right (тестирование после внедрения). Первый подход обычно применяется при подготовке и обучении моделей, второй рекомендуется для динамических и адаптивных ИИ-систем.

Тестирование ИИ в IBS

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

Кейс 1. ИИ-ассистент для разработчиков

Первоначально при выборе оптимальной модели для генерации и автодополнения программного кода использовался экспертный подход. Была разработана методология бенчмаркинга с тестовым набором задач. Специалисты IBS оценивали эффективность системы по пятибалльной шкале. Однако при каждой смене модели приходилось проводить полное регрессионное тестирование. К тому же экспертные суждения не были лишены субъективности.

Команда IBS создала специализированный инструмент для автоматизированного бенчмаркинга моделей с готовыми тестовыми заданиями и наборами данных. Он позволяет значительно экономить время и ресурсы, обеспечивая при этом уверенность в надежности системы.

Кейс 2. Интеллектуальный поиск по корпоративной регламентной документации

В этом проекте ИИ-модель применялась для обработки свободного пользовательского ввода и последующего поиска в масштабируемом и динамически изменяющемся информационном массиве.

Ключевым требованием к системе была гарантированная точность результатов. Помимо базового поиска нужно было валидировать дополнительные характеристики решения: проверить его на информационное смещение (bias testing), оценить справедливость (fairness assessment), протестировать производительность при высоких пользовательских нагрузках, а также исключить генерацию ложной информации при невозможности найти релевантные данные.

Команда по обеспечению качества разработала комплексную методологию, которая включает:

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

Полученный опыт, а также обратная связь от бизнеса показали востребованность таких решений. В начале 2024 года IBS начала разработку новых услуг, направленных на повышение качества внедрения ИИ-систем через их тестирование.

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

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

Чек-лист «Как приблизить результат проекта к желаемому»

Успех проекта во многом зависит от четко поставленных целей, организации процесса и слаженной работы на всех этапах.

Мы подготовили чек-лист ключевых практик, направленных на синхронизацию команды разработки, специалистов по качеству и бизнеса:

1. Сформулировать конкретные задачи, которые должна решать система, и ожидаемые эффекты от ее внедрения.
2. На ранних этапах подключить к проекту QA-специалистов, чтобы фокусироваться на вопросах «что делаем» и «для чего», а не только на «как это сделать».
3. Использовать стек инструментов для тестирования с учетом специфики ИИ-решений.
4. Проводить разработку итеративно, с поэтапной демонстрацией состояния системы бизнес-пользователям.
5. Сделать отчет по тестированию обязательной частью приемки проекта.

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

В случае сложных комплексных проектов внутренней экспертизы может оказаться недостаточно. В этой ситуации стоит задуматься о привлечении внешнего ИТ-партнера.