Как тестировать AI-приложения: Determinism vs. Probability

Традиционный QA, даже вооруженный до зубов AI-инструментами, принципиально не отличается от тестирования без них. Вы планируете покрытие, опираясь на классический тест-дизайн: эквивалентное разделение, попарное тестирование и т.п. Вы работаете с установкой, что если ожидаемый результат A + B = C, а на деле A + B != C - это дефект. В этом детерминированном мире почти никогда нет смысла прогонять один и тот же тест дважды.

Однако, если вы AI QA или ML Evaluation инженер, ваше A + B в первом прогоне может быть C, во втором - C + k, а в третьем C - k или даже C + n. Вы живете в мире подброшенных кубиков. По сути, вы измеряете вероятность результата. А чтобы рассчитать эту вероятность, у вас должно быть статистически репрезентативное количество наблюдений.

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

В полной версии поста я разобрала, как именно адаптировать процесс под эту недетерминированность - от работы с доверительными интервалами и N-прогонами до конкретного примера стресс-теста промптов на задаче «нарисуй дом» и подхода, который мы применяем у себя на проекте для минимизации галлюцинаций: читать далее