Haiku выдала PASS и замечание major в проверке десяти статей: разбор отчета

При проверке десяти статей модель Haiku в одном отчете одновременно поставила вердикт PASS и пометила замечание как major, то есть существенное. Авторы материала на Хабре не стали выбирать, какому сигналу верить. Они прошли по отчету с исходниками в руках и разделили замечания на те, что привели к правкам, и те, что отклонили. Отдельно зафиксировали, какого контекста самой модели не хватило.

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

Где ломается логика отчета

PASS и major описывают разные вещи. Первое обычно означает итоговое решение «материал можно пропускать». Второе описывает серьезность отдельной находки. В нормальной схеме major должен блокировать PASS, и если этого не происходит, у ревьюера внутри одного ответа расходятся два поля.

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

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

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

Что показала сверка с исходниками

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

Третья категория практически самая полезная. Она показывает не качество модели вообще, а границу применимости конкретной связки «модель плюс входные данные». Если ревьюер систематически промахивается на фактах из внешних источников, проблему решает расширение входа, а не замена модели.

Ключевые параметры эксперимента:

• ревьюер: Haiku, по названию малая модель линейки Claude;
• выборка: 10 статей;
• зафиксированное противоречие: вердикт PASS при замечании major;
• метод проверки: ручная сверка отчета с исходниками;
• итог: правки частично приняты, частично отклонены, пробелы в контексте выделены отдельно.

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

Как строить такое ревью на практике

Главный вывод для тех, кто ставит LLM на вычитку текстов или кода: не доверяйте одиночному полю вердикта. Если в отчете есть серьезность замечаний, итог лучше вычислять правилом снаружи модели. Любой major или critical переводит материал в ручную проверку независимо от того, что написано в PASS.

Вторая мера: давать ревьюеру тот контекст, на который ссылается проверяемый материал. Исходные файлы, версии библиотек, ссылки на документацию. Если модель что-то не видит, пусть вернет статус «недостаточно данных» вместо уверенного PASS. Такой статус стоит прописать в промпте явно.

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

Дешевая модель в роли ревьюера остается рабочим вариантом, пока ее вердикт проверяется правилами, а не принимается на веру.