Оценка на глаз: единственное, что ловит новые ошибки

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

Дальше выходит релиз, а через неделю приходит жалоба на что-то, чего ни одна проверка не измеряла. Метрики при этом росли.

Это не сбой в системе проверок. Это её устройство.

Что метрика может и чего не может

Проверка устроена так: вы формулируете утверждение об ответе и проверяете его программой. Утверждение формулируется заранее — иначе проверять нечего.

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

Она превосходно ловит просадку внутри известного класса: было 94% разбора по схеме, стало 71% — увидели сразу и точно. Она не ловит появление класса, которого в списке нет. Не потому что плохо написана, а потому что для этого её пришлось бы написать до того, как ошибка возникла.

Периметр расширяется только в одну сторону: человек замечает новое, новое превращается в свойство, свойство дальше проверяется автоматически и бесплатно. Обратного хода нет — автоматика сама себя не расширяет.

Что именно видит человек

Список получается конкретный, и он объясняет, почему это нельзя переложить на судью.

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

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

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

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

Судья тут не помощник по той же причине, что и метрика: он оценивает по заданной рубрике, то есть внутри того же периметра.

Как читать, чтобы это была работа

Ритуал «посмотреть выдачу» вырождается за две недели. Чтобы не выродился, у чтения должны быть правила — такие же, как у прогона.

Читать сырое, а не сводку. Таблица с процентами — это уже метрика, и она покажет то же, что показала автоматика. Смысл в полном тексте ответа вместе с входом.

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

Читать до метрик, а не после. Увидев «97% успеха», вы будете читать подтверждающе — это не сила воли, это устройство внимания.

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

Останавливаться на двадцати. Дальше внимание падает, а ощущение проделанной работы растёт — худшее из сочетаний.

Условие несогласия

Если ответ модели в вашем контуре и так читает человек перед тем, как что-то произойдёт, отдельная процедура не нужна: чтение уже встроено в работу, и остаётся только сделать так, чтобы замечания куда-то записывались.

Отдельная процедура нужна там, где ответ уходит дальше без человека. Ровно в тех контурах, где её и не делают, потому что «всё же автоматизировано».

Чего я делать не стал бы

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

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

Не стал бы считать чтение заменой набору примеров. Оно ловит новое и совершенно не годится для сравнения версий: человек не помнит, как отвечала прошлая версия, и добросовестно придумает воспоминание.

Открытый вопрос

Есть неприятная асимметрия. Чем лучше работает автоматика, тем скучнее читать выдачу — почти всё правильно, — и тем быстрее чтение бросают. То есть процедура саморазрушается ровно в тот момент, когда система становится достаточно хорошей, чтобы новые классы ошибок были редкими и дорогими.

Способа удержать внимание на редком событии я не знаю. В других инженерных областях это решают учениями — искусственно подсовывают поломку и смотрят, заметят ли. Для контура с моделью я такого приёма не встречал и сам не пробовал, хотя подозреваю, что он бы работал.