Регрессионное тестирование промптов: почему ИИ-человек пропускает брак
Разработчик ИИ-агентов создал собственный тестовый набор для проверки промптов, где одна языковая модель играет роль строгого редактора. Результат эксперимента выявил парадокс: сильно отредактированные тексты, которые человек признал качественными, с высокой долей вероятности проходили незаметными для алгоритмического судьи, в то время как скрытый брак часто оставался незамеченным. Это подтверждает, что автоматизированное качество-контроль на основе LLM не может полностью заменить человеческое суждение.
# Регрессионное тестирование промптов: ИИ-модель в роли читателя пропустила три из четырёх текстов
В мире разработки ИИ-агентов, которые генерируют и проверяют текстовый контент, существует постоянная борьба с регрессией. Каждая правка промпта (инструкции) может непредсказуемо изменить поведение модели: что работало вчера, сегодня может перестать функционировать корректно. Инженер игнориров, занимающийся настройкой таких систем, применил нетривиальный подход к решению этой проблемы, используя саму языковую модель в качестве судьи.
Результаты эксперимента оказались удручающими для доверия к полностью автоматическим проверкам. Система, где ИИ оценивает тексты, сгенерированные другими ИИ, оказалась неспособной выявить существенные отклонения, когда оригинальный текст подвергся радикальной переработке. В то же время, она демонстрировала склонность к «ложным тревогам» по отношению к неизменным или слегка улучшенным материалам.
Методология: как собирать эталон для тестирования
Основой любого регрессионного тестирования является эталон — набор данных с известным качеством. В контексте генеративного ИИ автор использовал стратегию, основанную на двух типах примеров:
1. Сильно правленные тексты: Материалы, которые после обработки агентом были радикально переписаны вручную. Совпадение с исходной версией таких текстов составило от 64% до 79%. В человеческом суждении они часто не признавались за браком из-за улучшения качества изложения, несмотря на существенные изменения смысла или структуры. 2. Почти нетронутые тексты: Материалы, где правка была минимальной, а совпадение с оригиналом составляло от 95% и выше. Для ИИ-модели эти примеры являлись эталоном качества.
Автор использовал метрику SequenceMatcher из модуля difflib для количественной оценки совпадения предложений. Порогом качества считалось совпадение выше 95%, ниже 85% — явным браком, а промежуточные значения (85–95%) исключались из тестового набора как «серые зоны».
Ключевая проблема, с которой столкнулись исследователи, — это невозможность использовать балл самой модели-судьи в качестве эталона. Если судья ошибается, это создаст замкнутый круг, где ошибка подтверждает ошибку. Эталон должен быть исключительно человеческим, так как именно человек определяет, был ли текст действительно исправлен.
Парадокс пропускаемого брака и ложных тревог
В ходе испытаний автор сопоставил результаты своей ручной разметки с выводами трех различных ролей читателя, каждая из которых оценивала текст по шкале от 1 до 10. Для прохода теста минимальная оценка должна была быть не ниже 7.
Анализ выявил две фундаментальные категории ошибок, которые должны учитываться отдельно при оценке промптов:
* Пропущенный брак (Missed Fault): Плохой пример, который система-судья ошибочно приняла за хороший. Это самый опасный сценарий, так как дефектный контент попадает в публикацию. * Ложная тревога (False Alarm): Хороший пример, который система ошибочно заблокировала.
Если считать лишь общую долю совпадений с человеком, эти ошибки могут нивелировать друг друга, создавая иллюзию корректной работы системы. Однако раздельный подсчет показывает тревожную картину: из четырёх сильно правленных текстов (где человек, судя по совпадению, ожидал брака или сложных изменений), читатель-алгоритм пропустил три. Он вернул лишь один текст, тогда как остальные три, имевшие значительные отклонения, прошли проверку без замечаний.
Более того, обнаружилось, что алгоритм часто «перестраховывается» на неизменном контенте. Из одиннадцати почти нетронутых текстов, которые по определению должны были пройти, система вернула лишь два, отметив остальные как проблемные. Это привело к росту количества ложных срабатываний.
Интересный случай связан с одним текстом, который прошел первичную оценку (минимальная оценка 5, что ниже порога 7) и был отправлен на доработку. После правки тот же текст получил оценку 7 и был одобрен. Однако при детальном разборе выяснилось, что в самой анкете для читателей отсутствовал вопрос, касающийся сути статьи («О чем она?»), тогда как вопросы о стиле изложения были перегружены. Текст, состоящий на треть из теоретического разбора метода, получил высокие оценки за форму, но не соответствовал ожиданиям по содержанию.
Смена модели и внутренняя нестабильность проверки
Эксперимент также включал проверку на смену конкретной модели. Перед миграцией с модели Opus на Sonnet автор прогнал тест на 12 версиях текстов. Хотя оценки совпадали в 89% случаев (в пределах одного балла), ключевые решения о проходе/непроходе текстов совпали лишь в 7 случаях из 12. Все расхождения пошли в сторону повышенной строгости Sonnet: модель вернула бы больше текстов, чем пропустила бы Opus.
Автор выбрал оставить модель на Opus, так как миграция на более строгую Sonnet привела бы к избыточному количеству возвратов на доработку, что неэффективно с точки зрения ресурсных затрат. Это подчеркивает, что даже небольшие изменения в архитектуре модели могут кардинально менять баланс между качеством и количеством пропущенных ошибок.
Кроме того, сама логика проверки подвержена поломкам. Автор столкнулся с ситуацией, когда проверка понятности заголовков за одну ночь стала отбрасывать четыре из семи хороших статей, так как алгоритм находил новые уточнения в каждом варианте, которые ранее не учитывались. В результате эта проверка была временно отключена одной константой, хотя код логики и 13 соответствующих тестов остались на месте. Это демонстрирует хрупкость автоматизированных систем контроля качества, где логика может быть верной, но интерпретация входных данных — нестабильной.
Выводы: человек остаётся необходимым звеном
Для эффективного тестирования промптов необходимо соблюдать ряд правил:
1. Динамическое обновление набора: На каждую найденную ошибку в системе следует сразу добавлять заведомо плохой пример в тестовую выборку. Рядом с ним обязательно должен быть хороший пример, чтобы проверка не начала блокировать живой контент после первой же правки. 2. Отдельный учет ошибок: Нельзя сводить всё к общей доле совпадений. Необходимо отслеживать отдельно количество пропущенных браков и ложных тревог. 3. Периодическая валидация самой проверки: Раз в две недели необходимо запускать тест с заведомо плохим примером, чтобы убедиться, что система контроля не сломалась.
Использование LLM-as-a-judge (ИИ как судья) является мощным инструментом, но оно не освобождает разработчика от необходимости постоянной валидации на человеческом эталоне. Малая выборка данных (в данном случае 4–11 текстов в группах) уже демонстрирует высокую дисперсию результатов, что делает выводы о надежности метода на больших объемах преждевременными. Факты показывают: чем сильнее текст отличается от оригинала без потери смысла, тем выше риск того, что ИИ-контроль его не увидит. А чем ближе текст к эталону, тем выше риск ложной блокировки. В этом напряжении и заключается необходимость постоянного участия человека в цикле разработки промптов.