TL;DR
MA-Bench — набор из десяти учебных кризисов с длинными пакетами документов. Модель пишет по ним аналитический бриф, а потом его проверяют чек-листом из атомарных пунктов. Каждый пункт — одно «да/нет» утверждение: «бриф назвал это решение» или «бриф НЕ выдал непроверенный факт за подтверждённый». За каждый пропуск и за каждый вредный ход считаются очки.
Главная находка: LLM почти не врут, они молчат. Большинство провалов — это просто отсутствие нужного вывода. Текст при этом гладкий, связный, без единой фактической ошибки. Хуже всего модели делают то, что нужно «вывести из головы»: предвидеть, какие решения придётся принимать дальше и какой информации не хватит. Описать ситуацию из документов они могут, предсказать развилки — гораздо хуже. Вторая беда — вредные ходы на очевидных ловушках: неподтверждённый слух превращается в факт, «семь конкретных партнёров» становятся «готовыми региональными партнёрами».
Метод оценки можно взять себе. Вместо вопроса «хороший ли получился бриф?» ты пишешь список проверяемых пунктов — что обязано быть и что запрещено. Потом отдельный проход модели-судьи возвращает только провалы с цитатами. Эффект двойной: видно, чего не хватает, и нет «дыры, которую не заметил бы читатель, оценивающий слог».
Схема метода
Это оригинал оценки из статьи (повторяется руками и через LLM-судью):
ШАГ 1: Эксперт пишет чек-лист → пункты "должно быть" (с весом: критично / важно / мелочь)
и пункты "нельзя" (с отрицательным весом)
ШАГ 2: Каждый пункт — атомарный (одна мысль), бинарный (да/нет),
проверяемый по тексту брифа, со ссылкой на источник
ШАГ 3: Модель-судья (отдельный запрос) получает бриф + чек-лист
БЕЗ исходных документов → возвращает ТОЛЬКО проваленные пункты
с цитатой и причиной. Не сказано явно — значит провал. Частичных баллов нет.
ШАГ 4: Счёт = (сумма весов выполненных − штрафы за вредные ходы) / сумма весов "должно быть"
Пункты делятся на три уровня по тому, откуда берётся ответ: - Уровень 1 — прямо написано в одном документе. - Уровень 2 — надо собрать из нескольких фактов. - Уровень 3 — нигде не написано, это вывод. Он самый ценный и самый трудный.
Пример применения
Задача: Директор по развитию продавца на Ozon решает, открывать ли склад в Алматы. У него пакет из 8 документов: проект договора аренды, письмо таможенного брокера, внутренняя выгрузка продаж, заметки юриста, письмо CEO с вводными. Он просит LLM сделать бриф для совета директоров. Хочет убедиться, что бриф ничего важного не упустил и не выдал слух за факт.
Промпт (судья, шаблон ниже заполнен):
Ты — строгий проверяющий. Ты НЕ переписываешь бриф и НЕ оцениваешь стиль.
Ты проверяешь только перечисленные пункты.
ТРЕБУЕТСЯ (критично):
R1. Бриф называет срок индексации ставок аренды как риск в первый год.
R2. Бриф явно говорит, что тарифы брокера — устные, письменного подтверждения нет.
R3. Бриф формулирует решение, которое совет должен принять ДО подписания аренды.
ТРЕБУЕТСЯ (важно):
R4. Бриф называет, какой информации не хватает для решения (например, подтверждённые ставки пошлин).
R5. Бриф отделяет условия, на которые можно опереться, от допущений.
ЗАПРЕЩЕНО (критично):
N1. Устные тарифы брокера названы подтверждёнными.
N2. Цифры из выгрузки продаж за 2 месяца выданы как устойчивый тренд.
ЗАПРЕЩЕНО (важно):
N3. Бриф смешивает «открываем склад» и «открываем юрлицо в РК» как одно решение.
- Бинарная проверка. Если пункт не выполнен ясно и прямо — это провал. Частичных баллов нет.
- Каждый пункт проверяй независимо.
- Исходных документов у тебя нет. Судишь только по тексту брифа.
Верни ТОЛЬКО провалы: список вида
[ID пункта] | цитата из брифа (или «в брифе нет») | причина провала в одном предложении.
Если провалов нет — напиши «Провалов нет».
{текст брифа}
Результат: Модель вернёт короткий список только проваленных пунктов. Каждый — с ID, цитатой из брифа (или пометкой «в брифе нет») и причиной. Выполненные пункты в ответе не появятся. Читатель сразу видит дыры: например, что бриф ни разу не сформулировал решение «до подписания аренды». Дальше он просит дописать бриф именно по этим провалам.
Почему это работает
Слабость. Гладкий текст создаёт иллюзию полноты. Читатель, оценивающий «в целом хорошо ли», не замечает отсутствия: ошибки нет, значит, всё в порядке. Метрики вроде «похоже на эталон» или «нет фактических ошибок» тоже пропустят провал. Ведь большинство провалов — не неверное предложение, а отсутствующее.
Сильная сторона. Модель-судья хорошо справляется с узкой задачей: найти в тексте конкретное утверждение и ответить «есть/нет» с цитатой. Согласие между судьёй и экспертами сопоставимо с тем, как эксперты согласны друг с другом. Результаты не зависят от того, какая модель судит: ранжирование стабильно при смене судьи.
Как метод использует это. Чек-лист превращает «оцени качество» в десятки мелких проверок на наличие. Каждая видна и обсуждаема. Отрицательные пункты ловят то, что иначе осталось бы незамеченным: слух, превращённый в факт.
Рычаги управления: - Веса пунктов (критично/важно/мелочь) → расставляй под свою задачу: что ломает решение, а что просто украшает. - Список «запрещено» → самое ценное. Туда пиши типичные ловушки именно твоего пакета (устные обещания, неподтверждённые цифры, смешение двух решений). - «Судья без доступа к документам» → убери это условие, если нужна проверка точности цитат из источников. Оставь, если проверяешь, что вообще есть в брифе. - Строгость («не ясно — провал») → ослабь для черновиков, держи жёстко для итоговых документов.
Что ещё показала статья (практические выводы)
- Лимит длины режет содержание. Если убрать потолок в 3000 слов, баллы растут. Значит, у моделей есть что сказать, но жёсткий лимит выбрасывает важное. Если нужен полный анализ, не ставь жёсткий потолок. Лучше проси краткое резюме отдельно.
- Больше «рассуждения» не лечит. Переключение с низкого на высокий уровень рассуждения почти не меняло результат и не в одну сторону, хотя токенов тратилось на порядки больше. Крутить «reasoning effort» вместо улучшения задачи и проверки — плохая замена.
- Модель покрывает «заголовочное» и теряет второй уровень. Критичные пункты проходят заметно чаще, чем «важные»: самое очевидное модель делает, второстепенное, но существенное теряет. Просить «ещё вторичные последствия» нужно явно.
- Слабее всего — взгляд вперёд. Какие решения придётся принять и какая информация понадобится. Это нужно запрашивать отдельным пунктом задания.
- Чаще всего вредный ход — на простых ловушках (непроверенное как факт), а не на сложных. Проверяй «статус достоверности» каждого утверждения.
- Размер модели помогает, но не закрывает разрыв: старшая модель в семействе чаще побеждает младшую.
Шаблон промпта
Это шаблон судьи по чек-листу в духе оригинала. Оговорка: я упростил полярность для читателя: в статье «запрещённые» пункты проверяются как «ход присутствует», здесь это записано явно в двух списках.
Ты — строгий проверяющий. Ты НЕ переписываешь текст и НЕ оцениваешь стиль.
Ты проверяешь только перечисленные пункты.
ТРЕБУЕТСЯ (критично):
R1. {что обязано быть в тексте}
R2. {...}
ТРЕБУЕТСЯ (важно):
R3. {...}
ТРЕБУЕТСЯ (мелочь):
R4. {...}
ЗАПРЕЩЕНО (критично):
N1. {вредный ход, который нельзя делать}
N2. {...}
ЗАПРЕЩЕНО (важно):
N3. {...}
- Каждый пункт: одна мысль, ответ да/нет.
- Если пункт не выполнен ясно и прямо — это провал. Частичных баллов нет.
- Проверяй каждый пункт независимо.
- Судишь только по тексту ниже. Исходных документов у тебя нет.
- Стиль, порядок, оформление не оцениваются.
Верни ТОЛЬКО проваленные пункты (R — не выполнены, N — нарушены):
[ID] | цитата из текста (или «в тексте нет») | причина в одном предложении.
Если провалов нет — напиши «Провалов нет».
{текст для проверки}
Что подставлять:
- {что обязано быть} — конкретные решения, риски, оговорки, которые должен содержать результат. Пиши по одному на пункт: «защитить инфраструктуру и сдержать диверсии» — это уже два пункта.
- {вредный ход} — типичные ловушки твоего материала: слух как факт, смешение двух задач, нарушение ограничения.
- {текст для проверки} — результат работы модели (бриф, отчёт, план).
🚀 Быстрый старт — вставь в чат:
Вот шаблон проверки по чек-листу. Адаптируй под мою задачу: {опиши, какой документ проверяешь и для чего он нужен}.
Задавай вопросы, чтобы составить чек-лист: что обязано быть в документе, какие ловушки есть в исходных данных.
[вставить шаблон выше]
LLM спросит, что считается критичным решением, какие факты в исходниках неподтверждённые или противоречат друг другу, и какие ошибки самые дорогие. Эти вопросы нужны, потому что качество чек-листа определяет всё. Модель возьмёт структуру из шаблона и превратит ответы в атомарные бинарные пункты.
Адаптации (наши идеи, в статье не проверялись)
Статья показывает, где модели падают, но промпты-лекарства не тестировала. Ниже — гипотезы, вытекающие из находок. Проверь на своей задаче.
Отдельный проход «чего не хватает». После первого брифа проси: «Перечисли решения, которые придётся принять в следующие две недели, и информацию, которой не хватает для каждого». Это бьёт в самое слабое место, взгляд вперёд.
Метка достоверности. Проси: «Рядом с каждым фактом поставь: подтверждено документом / слух / допущение». Это против самой частой ловушки.
Ограничения
⚠️ Лекарства не проверены: Статья измеряет и объясняет, где модели ошибаются. Она не проверяла, что именно в промпте это исправляет. Отдельные проходы и метки достоверности — наши предположения.
⚠️ Чек-лист нужно писать самому: Для проверки нужен эксперт, который знает, что должно быть в ответе. Авторы тратили на это месяцы. Чек-лист на 8–15 пунктов под свою задачу — реально, но «умная» проверка без предметных знаний не получится.
⚠️ Судья — тоже LLM: Согласие с экспертами умеренное, а эксперты друг с другом согласны слабо. Хуже всего судья справляется с вредными ходами: он ловит их примерно в половине случаев, где их видят эксперты. Выборочно проверяй вердикты руками.
⚠️ Один домен: Все сценарии — военное операционное планирование на синтетических данных. Перенос на бизнес-аналитику логичен, но самой статьёй не проверен.
⚠️ Нет сравнения с человеком: Баллы показывают место среди моделей, но не говорят, насколько бриф хуже написанного опытным штабным офицером или аналитиком.
⚠️ Отказы: Одна из моделей обрывала ответ фильтром на двух сценариях из десяти — без объяснения. Для чувствительных тем это реальный риск.
Ресурсы
- MA-Bench: Measuring Operational Planning in Language Models — Rodney Lafuente-Mercado, Robert Sincero, Phil Sage, Yuan (Emily) Xue; Scale AI, Data Machines.
- Датасет: huggingface.co/datasets/ScaleAI/MA-Bench
- Основа рубрики: доктрина Joint Planning Process (JP 5-0), шаг «анализ миссии».