Якоря в промптах искажают оценку LLM: F1-инфляция и миф о качестве
Статья документирует явление F1-инфляции: когда F1-метрика (основанная на подсчёте найденных ошибок) растёт, но качество локализации ошибок не улучшается. Авторы разработали тестовый протокол ErrorBench и оценили шесть современных LLM (включая GPT и Claude) в пяти вариантах промптов на базе 4290 ответов из 143 отрывков CoNLL-2014. Ключевое открытие: когда в промпт добавляют якорь (число вроде «В этом тексте 5 ошибок»), модели начинают генерировать больше ошибок, чтобы соответствовать числу, но точность их локализации растёт незначительно. Например, переход с «слепого» промпта на якорный поднял Count-F1 на +0.21, но многореференционный ERRANT F0.5 только на +0.04. GPT и Claude более поддаются якорям (как послушные системы), а Gemini менее чувствительна. Авторы рекомендуют отказаться от предзаполненных количеств ошибок и использовать span-aware метрики (измеряющие точность локализации) наряду со счётом.
Ключевые факты
- Count-based F1 может расти без улучшения качества локализации ошибок, эффект назван F1-инфляцией
- Численные якоря в промптах (число ошибок) искусственно увеличивают отклик моделей, но не улучшают точность
- Разные модели по-разному реагируют на якоря: GPT/Claude послушны, Gemini устойчива
- Текущая методология оценки LLM-прувридеров неадекватна: нужны метрики на основе span (позиции ошибок), не только счёт
- Рекомендация: при оценке LLM для обнаружения ошибок избегать предзаполненных количеств и отчитывать оба типа метрик
Почему это важно
LLM становятся инструментом проверки текстов и документов, от них требуется находить ошибки. Оценка качества такой работы обычно идёт по F1-метрике на основе подсчёта (сколько ошибок найдено). Эта статья показывает, что метрика легко манипулируется формулировкой промпта: простой численный якорь может имитировать улучшение качества, хотя на практике модель просто выплёвывает больше «ошибок», не умея их точно локализовать. Это критично для вычисления бенчмарков и выбора моделей для production.
Кому это важно
Разработчикам LLM-приложений для проверки текстов и документов (корректура, редактура, автоматическая правка). Авторам бенчмарков и методологий оценки LLM. Исследователям, занимающимся error detection в NLP. Компаниям, выбирающим LLM для конкретной задачи по опубликованным метрикам, нужно проверить, как эти метрики считались.
Как это применить
При разработке промпта для LLM-проверки избегать предзаполненного количества ошибок. При оценке качества моделей для error detection не полагаться на Count-F1 как единственную метрику, обязательно использовать span-aware метрики (ERRANT F0.5, метрики, считающие позиции и границы обнаруженных ошибок). При сравнении двух моделей смотреть не только на рост F1, но и проверять, улучшилась ли точность локализации. В документ-ревью систем и автокорректорах требовать от LLM не только списка ошибок, но и их точных позиций в тексте.
Можно ли доверять
Это рецензируемое исследование с контролируемым экспериментом (ErrorBench) на стандартном наборе данных CoNLL-2014. Авторы воспроизвели результаты на стандартном ERRANT pipeline и 100 проходах с мультиреференциями. Выводы осторожны: авторы не утверждают, что F1 вообще бесполезна, а показывают конкретный источник её искажения (якоря в промптах). Результаты генерализуются на шесть основных моделей и воспроизводимы другими исследователями.
Риски и подводные камни
Исследование сфокусировано на error detection в грамматике (CoNLL-2014, тесты на правку текстов). Обобщение на другие типы detection tasks (опечатки, логические ошибки, фактпроверка) требует отдельной проверки. Эффект якоря может различаться между языками, все эксперименты на англоязычных данных. Рекомендация отказаться от якорей может быть нецелесообразна, если в вашей задаче число ошибок известно заранее (например, инструкция такой).
«Оценка LLM-прувридеров и систем проверки документов должна избегать предзаполненных количеств ошибок и отчитывать span-aware метрики наряду со счётными метриками.»
— Статья (рекомендация авторов)