TL;DR
Исследователи проанализировали 83 модели на 35 датасетах и составили каталог из 17 типичных ошибок, которые делают современные LLM. Метод ErrorMap автоматически анализирует каждую ошибку модели (что пошло не так, почему) и группирует их в категории. Результат — ErrorAtlas, таксономия слабых мест LLM: от логических ошибок до пропуска деталей и неправильного понимания задачи.
Главная находка: модели массово упускают детали в ответах (Missing Required Element) и неправильно интерпретируют задачу (Specification Misinterpretation) — но эти проблемы почти не обсуждаются в исследованиях. Модель может дать частично правильный ответ, упустив важные нюансы из контекста. Например, описать симптомы болезни общо, не учитывая специфику случая из вопроса. При этом разные модели ошибаются по-разному: Gemini чаще ошибается в вычислениях, Claude — в логике.
Сам метод ErrorMap требует код и API для анализа бенчмарков — это инструмент разработчиков. Но каталог ошибок ErrorAtlas полезен обычным пользователям: зная слабые места LLM, можно строить промпты точнее и проверять ответы прицельнее. Знание что модели "склонны упускать детали" меняет подход к формулировке запросов.
Схема метода
STAGE 1 (для каждой ошибки модели):
LLM-аналитик изучает: вопрос + правильные ответы других моделей + неправильный ответ
→ Описание: что пошло не так, какие критерии не выполнены
→ Ярлык ошибки: короткая фраза типа "пропущен шаг вычисления"
STAGE 2 (группировка всех ошибок):
2.a: Генерация категорий из ярлыков → описания категорий
2.b: Распределение ошибок по категориям
→ Итеративное углубление: каждая категория дробится на подкатегории
→ Результат: иерархия ошибок (17 категорий верхнего уровня в ErrorAtlas)
Важно: Метод требует Python + API + данные бенчмарков. Это не для ручного применения. Ценность — в результатах анализа (каталоге типов ошибок).
17 типов ошибок из ErrorAtlas
Топ-5 самых частых:
- Logical Reasoning Error — сбой в логике, дедукции, шагах рассуждения
- Missing Required Element — пропущены обязательные части ответа, детали, уточнения
- Computation Error — неправильные вычисления, алгебраические ошибки
- Incorrect Identification — неверно определён объект, концепция, атрибут
- Specification Misinterpretation — неправильно понята задача, требования, формат
Остальные категории: - Output Formatting Error (нарушен формат) - Irrelevant/Extraneous Content (лишняя информация) - Counting/Enumeration Error (ошибки подсчёта) - Answer Selection Error (выбрал неправильный вариант) - Incomplete Reasoning (неполное объяснение) - Factual Error (фактическая неточность) - Tool/API Usage Error (неправильное использование инструментов) - Naming/Symbol Error (ошибки в именах, переменных) - Inappropriate Refusal (отказ отвечать без причины) - Unit Conversion Error (ошибки конвертации единиц) - False Positive Detection (ложное обнаружение ошибки) - Error Detection Failure (пропуск реальной ошибки)
Как использовать знание об ошибках
Задача: Попросить анализ бизнес-идеи (или любую сложную задачу требующую полноты)
Обычный промпт (рискованный):
Проанализируй мою бизнес-идею: [описание]. Что думаешь?
❌ Высокий риск Missing Required Element — модель может дать поверхностный анализ, упустив финансы, риски или конкурентов.
Промпт с учётом ErrorAtlas:
Проанализируй бизнес-идею запуска [твоя идея].
⚠️ Модели часто упускают важные детали. Обязательно покрой:
- Целевая аудитория и её боли
- Конкуренты и отличия от них
- Финансовая модель (откуда деньги, на что тратим)
- Риски и способы их снизить
- План первых шагов
После анализа сам себя проверь:
1. Не пропустил ли я критичные аспекты?
2. Правильно ли понял специфику идеи (не ответил ли "вообще про такие идеи")?
Если что-то упустил — допиши.
Результат:
Модель получает явный чеклист, снижающий риск Missing Required Element. Инструкция "проверь себя" активирует самопроверку, помогая поймать Specification Misinterpretation (если модель ответила общо, не про твой конкретный случай). Ответ будет полнее и точнее попадать в задачу.
Почему это работает
Слабость LLM: Модели генерируют текст вероятностно — могут "забыть" упомянуть деталь, если она не в фокусе внимания на текущем шаге генерации. Они не держат строгий чеклист требований в голове. Результат — неполные ответы, упущенные аспекты.
Вторая слабость: Модели часто ориентируются на поверхностные паттерны вопроса, а не на глубокий контекст. Если вопрос похож на типовой, модель может ответить "как обычно", игнорируя специфику. Отсюда Specification Misinterpretation.
Как знание помогает: Зная карту слабых мест, ты строишь промпт от обратного — явно закрываешь дыры: - Против "Missing Required Element" → даёшь чеклист обязательных элементов - Против "Specification Misinterpretation" → явно указываешь специфику, просишь повторить своими словами что понял - Против "Computation Error" → просишь показать расчёты пошагово или использовать калькулятор через code interpreter
Это не магия, а профилактика. Как знание что определённая дорога скользкая — едешь аккуратнее.
Дополнительный инсайт: Разные модели проваливаются в разных категориях. Если задача требует много вычислений — Gemini может дать больше Computation Errors, чем GPT-4. Если нужна логика — Claude косячит чаще. Выбор модели под задачу теперь точнее.
Чеклист проверки ответа
После получения ответа от модели, проверь:
Прочитай свой ответ выше как строгий критик. Проверь:
1. **Полнота (Missing Required Element):**
Все ли аспекты из вопроса покрыты? Нет ли пропущенных деталей?
2. **Понимание задачи (Specification Misinterpretation):**
Ответ на МОЙ конкретный вопрос или "вообще на такие вопросы"?
3. **Логика (Logical Reasoning Error):**
Шаги рассуждения логичны? Нет противоречий?
4. **Точность данных (Factual Error, Computation Error):**
Факты верны? Расчёты правильны?
5. **Формат (Output Formatting Error):**
Соблюдён ли запрошенный формат (таблица, JSON, список)?
Если нашёл проблемы — исправь их.
Как использовать: Скопируй этот чеклист в конец промпта или отдельным сообщением после получения ответа. Модель проверит сама себя по типичным слабым местам.
Ограничения
⚠️ Метод требует инфраструктуру: ErrorMap нельзя применить в обычном чате. Нужен код, API-доступ к моделям и данные бенчмарков для анализа. Это инструмент разработчиков и исследователей, не пользователей.
⚠️ Каталог основан на бенчмарках: ErrorAtlas построен на датасетах типа MMLU, HumanEval, GPQA — академических задачах. Распределение ошибок в реальных рабочих задачах может отличаться. Например, в creative writing могут доминировать другие типы ошибок (нет в топе ErrorAtlas).
⚠️ Не все ошибки применимы везде: Категории типа "Tool/API Usage Error" или "Unit Conversion Error" актуальны только для специфичных задач (code generation, научные расчёты). Для написания текстов они неактуальны.
⚠️ Знание ≠ готовое решение: ErrorAtlas даёт карту слабых мест, но КАК именно адаптировать промпт под каждую категорию ошибок — нужно додумывать самому. Это не готовая техника "делай так", а ориентир "смотри туда".
Ресурсы
Работа: ErrorMap and ErrorAtlas: Charting the Failure Landscape of Large Language Models
Код и данные: https://github.com/IBM/ErrorMap
Авторы: Shir Ashury-Tahan, Yifan Mai, Elron Bandel, Michal Shmueli-Scheuer, Leshem Choshen (IBM Research, Stanford University, MIT)
