3,583 papers
arXiv:2601.15812 73 22 янв. 2026 г. FREE

ErrorMap и ErrorAtlas: карта типичных ошибок LLM

КЛЮЧЕВАЯ СУТЬ
Модель провалила reasoning-тест не из-за слабой логики — она ошиблась в подсчёте на втором шаге. Вопрос по медицине решён неправильно не из-за незнания, а потому что модель пропустила важную деталь в контексте. Бенчмарки показывают где модель упала, но не раскрывают причину. ErrorMap — исследовательский метод, который строит таксономию ошибок: что именно сломалось в каждом неправильном ответе и почему. Фишка: модель-судья сравнивает ошибочный ответ с правильными решениями других моделей (ICP - правильные примеры для сравнения), находит первую главную ошибку — она задаёт траекторию всему остальному — и создаёт метку типа "пропущена обязательная деталь" или "неправильная интерпретация условия".
Адаптировать под запрос

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 самых частых:

  1. Logical Reasoning Error — сбой в логике, дедукции, шагах рассуждения
  2. Missing Required Element — пропущены обязательные части ответа, детали, уточнения
  3. Computation Error — неправильные вычисления, алгебраические ошибки
  4. Incorrect Identification — неверно определён объект, концепция, атрибут
  5. 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)


📋 Дайджест исследования

Ключевая суть

Модель провалила reasoning-тест не из-за слабой логики — она ошиблась в подсчёте на втором шаге. Вопрос по медицине решён неправильно не из-за незнания, а потому что модель пропустила важную деталь в контексте. Бенчмарки показывают где модель упала, но не раскрывают причину. ErrorMap — исследовательский метод, который строит таксономию ошибок: что именно сломалось в каждом неправильном ответе и почему. Фишка: модель-судья сравнивает ошибочный ответ с правильными решениями других моделей (ICP - правильные примеры для сравнения), находит первую главную ошибку — она задаёт траекторию всему остальному — и создаёт метку типа "пропущена обязательная деталь" или "неправильная интерпретация условия".

Принцип работы

Вместо того чтобы модель сама угадывала "как надо было" — покажи ей правильное решение. LLM отлично сравнивает тексты и находит расхождения. ErrorMap работает в два этапа: Первый — судья получает неправильный ответ + правильные решения от других моделей, разбирает по критериям, находит где именно разошлись пути. Второй — метки ошибок группируются в таксономию через итеративное уточнение: от конкретных промахов ("пропущена скобка в формуле") к общим категориям ("Computation Error"). Главное: фиксируется первый сбой, а не симптомы — если модель неправильно поняла условие на шаге 1, все дальнейшие рассуждения логичны, но ведут не туда.

Почему работает

LLM плохо находит собственные ошибки "в вакууме", но отлично видит где её ответ разошёлся с эталоном. Это как дать студенту правильное решение и попросить найти свой промах — гораздо проще чем решать задачу заново. Применив метод к 83 моделям и 35 датасетам, авторы построили ErrorAtlas — таксономию из 17 категорий частых ошибок LLM. Жесть — 44% провалов в reasoning-бенчмарках (MMLU-Pro, GPQA) не связаны с логикой: это технические промахи (неправильный подсчёт, пропущенная информация, ошибки форматирования). Топ недооценённых проблем: Missing Required Element (#2 по частоте) — модель упускает важные нюансы контекста, и Specification Misinterpretation (#5) — не улавливает что именно требуется в данной ситуации. Эти ошибки почти не обсуждаются в исследованиях, хотя встречаются постоянно.

Когда применять

Для тех, кто работает с повторяющимися задачами и хочет понять паттерны ошибок модели — своей или при выборе между моделями. Конкретно для отладки сложных промптов (понять где именно сломалось), выбора модели под специфику (Gemini Pro делает значительно меньше ошибок в вычислениях чем Flash, Claude 3.5 Haiku склонен к логическим ошибкам), анализа провалов в задачах где "вроде всё правильно, но ответ не тот". НЕ подходит: полная система ErrorMap требует код/API — нельзя запустить в ChatGPT. Для единичных задач избыточно.

Мини-рецепт

Хотя полный ErrorMap работает через пайплайн, принцип ICP (правильные примеры для сравнения) применим в чате:

1. Дай модели ошибочное решение + правильное: Вот задача: {задача}. Вот моё неправильное решение: {ошибка}. Вот правильное решение: {эталон}.

2. Попроси структурированный анализ: Проанализируй: 1) Разбей правильное решение по шагам — какие критерии нужны? 2) Для каждого критерия проверь: выполнен ли в неправильном? Где сломалось? 3) Найди ПЕРВУЮ главную ошибку — она задала траекторию остальному. 4) Дай метку типа ошибки (например: "пропущена важная деталь", "ошибка в вычислениях").

3. Категоризация паттернов (опционально): Если решаешь похожие задачи регулярно — попроси модель вести список типичных ошибок в чате. Через 10-20 задач спроси Покажи мои паттерны ошибок — модель выдаст статистику и предложит как избежать повторений.

Примеры

[ПЛОХО] : Найди ошибку в моём решении задачи (модель будет угадывать "как надо" без эталона)
[ХОРОШО] : Задача: рассчитать окупаемость стартапа при привлечении клиента 15к, удержании 25%, средний чек 8к. Моё решение: "15к / (8к × 0.25) = 7.5 месяцев". Правильное решение коллеги: "LTV = 8к × (1 / (1 - 0.25)) = 10.7к. CAC = 15к. Не окупается, LTV < CAC". Проанализируй: 1) Какие критерии я пропустил? 2) Где первая главная ошибка? 3) Тип ошибки? → Модель покажет: пропущен расчёт пожизненной ценности через формулу удержания, первая ошибка — неправильная интерпретация метрики "удержание 25%", тип: Specification Misinterpretation + Missing Required Element.
Источник: ErrorMap and ErrorAtlas: Charting the Failure Landscape of Large Language Models
ArXiv ID: 2601.15812 | Сгенерировано: 2026-01-23 05:34

Проблемы LLM

ПроблемаСутьКак обойти
Модель пропускает важные детали контекстаДаёт логичный ответ на общий случай. Но упускает тонкую деталь из условия. Результат выглядит разумно, но неверен для данной конкретной ситуации. Пример: набор симптомов обычно означает диагноз А, но одна фраза в описании указывает на диагноз Б — модель игнорирует её. Это вторая по частоте ошибка LLM, но почти не обсуждается в исследованияхПокажи модели правильный ответ (от другой модели или свой). Попроси: "Сравни мой ответ с правильным. Какую деталь из условия я пропустил?" Модель увидит расхождение и найдёт упущенный элемент
Модель не понимает ЧТО именно требуетсяЗнания есть. Логика работает. Но модель отвечает не с той экспертизой или не в том формате. Проблема не в незнании, а в интерпретации требования: что значит "подробно", "с точки зрения эксперта", "в формате отчёта". Модель даёт общий ответ вместо специфическогоСравни неправильный ответ с правильным: "Вот моё решение. Вот эталон. Найди: какое требование задачи я неправильно понял? Где я ответил НЕ ТАК как просили?" Фокус на разбор спецификации, не содержание

Методы

МетодСуть
Анализ ошибок через правильный пример (ICP)Модель ошиблась. Не спрашивай "где ошибка" в пустоту. Дай правильное решение (своё, от другой модели, эталон). Попроси: "Сравни мой ответ с правильным. Разбей правильное решение на критерии. Для каждого критерия проверь — выполнен ли он в моём ответе. Найди ПЕРВУЮ главную ошибку — она задала траекторию всему остальному". Почему работает: Модель отлично сравнивает тексты. Видя работающее решение, она находит где её ответ разошёлся с эталоном — гораздо точнее чем додумывание "как надо было". Когда применять: сложная задача с несколькими шагами, есть правильное решение для сравнения. Когда не работает: правильного решения нет, субъективная оценка

Тезисы

ТезисКомментарий
Первая ошибка задаёт траекторию всему остальномуМодель неправильно поняла условие на шаге 1. Дальше рассуждает логично — но идёт не туда. Вторая, третья, четвёртая ошибки — следствия первой. Если анализируешь провал — ищи корень, не симптомы. Применяй: Попроси модель при разборе ошибки: "Найди ПЕРВЫЙ момент где решение разошлось с правильным. Что сломалось раньше всего?" Это покажет источник проблемы
📖 Простыми словами

ErrorMap and ErrorAtlas: Charting the Failure Landscape ofLargeLanguageModels

arXiv: 2601.15812

Современные нейронки ошибаются не просто так — у них есть свои системные «глюки», которые теперь разложили по полочкам. Суть в том, что LLM не мыслят логическими цепочками, а просто угадывают следующее слово. Из-за этого они постоянно теряют нить повествования или игнорируют куски твоего промпта. Метод ErrorMap — это автоматический рентген, который прогнал 83 модели через тысячи тестов и выявил 17 типов косяков, из которых сложили целую карту провалов под названием ErrorAtlas.

Это как если бы ты нанял строителя, который вроде и умеет класть кирпич, но постоянно забывает то про окна, то про розетки, потому что в моменте увлечен замешиванием раствора. Формально стена стоит, но жить в таком доме нельзя. Модель ведет себя так же: она увлекается процессом генерации текста и просто «вымывает» из памяти важные детали, которые ты просил учесть в самом начале. Это не случайный сбой, а фундаментальная дыра в архитектуре, где вероятность слова важнее смысла задачи.

Исследователи выделили конкретные зоны поражения: логические провалы, когда модель противоречит сама себе, пропуск деталей, если инструкция была слишком длинной, и неверное понимание задачи, когда нейронка просто галлюцинирует на ровном месте. Самое интересное, что ErrorAtlas показывает: даже топовые модели лажают по одним и тем же сценариям. Если промпт сложный, модель гарантированно «поплывет» в одной из 17 категорий, будь то математика или обычный пересказ текста.

Хотя тест проводили на огромных датасетах, принцип универсален для любого, кто пользуется чат-ботами. Будь то написание кода, создание маркетингового плана или юридический анализ — везде работает один и тот же паттерн ошибок. ErrorMap доказывает, что слепо доверять результату нельзя, потому что у моделей нет внутреннего «чек-листа» для проверки качества. Они просто выдают наиболее вероятный текст, даже если он полная фигня с точки зрения логики.

Главный вывод: эпоха слепого восторга перед AI закончилась, началась эпоха систематизации косяков. Теперь у нас есть четкая таксономия того, где именно нейронка может тебя подставить. Вместо того чтобы надеяться на чудо, нужно проверять ответы по списку из ErrorAtlas и дробить задачи на мелкие части. Если не контролировать эти 17 зон риска, ты неизбежно получишь результат, который выглядит красиво, но разваливается при первой же проверке фактов.

Работа с исследованием

Адаптируйте исследование под ваши задачи или создайте готовый промпт на основе техник из исследования.

0 / 2000
~0.5-2 N-токенов ~10-30с
~0.3-1 N-токенов ~5-15с