Автор AI-ментора проверил свои 61 тест и обнаружил, что стенд врёт

Месяц назад разработчик учебной платформы встроил в неё AI-ментора и собрал для него стенд из 61 автоматического теста, чтобы принимать решения по цифрам, а не по ощущениям. Через неделю выяснилось, что ошибается сам стенд: он засчитывал оборванные ответы, пропускал готовые решения под другими именами переменных и заваливал корректные отказы. Ещё через неделю модель на стенде работала безупречно, а на проде на тот же класс вопросов нет. Автор описал эту историю на Habr.

Что проверяли и зачем

Ментор в платформе не абстрактный чат-бот. Он видит уроки, прогресс студента и его последнюю попытку по заданию. Отсюда и критерий качества: репетитора оценивают не по знанию ответа, а по тому, где он остановится. Укажет строку с ошибкой или перепишет задачу за ученика. Скажет «не знаю, давай проверим» или уверенно додумает.

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

Где стенд врал

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

• Оборванный ответ засчитывался. Похоже, проверка искала нужные признаки в тексте, но не требовала, чтобы ответ был закончен. Модель, обрезанная по лимиту токенов, получала зачёт.
• Готовое решение под другим именем переменной проходило. Запрет на выдачу решения, скорее всего, опирался на сравнение текста. Переименуйте переменную, и совпадение исчезает, а студент получает полный код.
• Правильный отказ валился. Проверка ждала определённой формы отказа и не узнавала корректный ответ в другой формулировке.

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

Стенд чист, прод нет

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

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

Что можно забрать себе

• Проверяйте оценщика. Прогоните стенд на заведомо плохих ответах: обрезанных, с готовым решением, с переименованными переменными. Если стенд их пропускает, цифрам верить нельзя.
• Сравнивайте по смыслу. Для кода это нормализация идентификаторов, разбор структуры или запуск решения, а не поиск подстроки.
• Считайте ложные зачёты и ложные провалы отдельно. Одна доля прохождения скрывает ошибки обоих знаков.
• Возвращайте прод в набор. Каждый реальный провал должен становиться новым тестом.
• Не опирайтесь на модель в критичных местах. Запрет на выдачу полного решения надёжнее ставить как проверку на выходе, а не как просьбу в промпте.

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