TL;DR
MNL — метод для улучшения работы LLM без обновления весов модели через ведение "блокнота ошибок". Работает в три шага: (1) модель решает задачи базовым промптом, (2) ошибки группируются по темам, анализируются батчами и превращаются в структурированные заметки с правилами и антипаттернами, (3) новые заметки применяются ко всему батчу — если результат улучшился, заметки сохраняются в базе знаний, если нет — отбрасываются. Для каждой новой задачи релевантные заметки достаются из базы и добавляются в промпт.
Существующие методы учатся на отдельных ошибках (instance-level) — это шумно, легко переобучиться на детали конкретного примера. Memento добавляет в промпт траектории решения, TFGO извлекает опыт из сравнений, но оба принимают любые обновления без проверки. В итоге база знаний засоряется неработающими или вредными советами. Второй провал — отсутствие проверки: если новое правило ухудшает результат, его всё равно добавляют в систему, и откатить назад невозможно.
MNL решает через batch-wise abstraction — группирует 5-10 похожих ошибок по темам, ищет общий паттерн ("путаете > и >="), а не запоминает детали одного случая. Каждая заметка содержит 5 блоков: исправленные примеры, правильный подход, суть ошибки, общую стратегию и антипаттерны — когда этот совет НЕ применять. Обновления принимаются только если новая заметка улучшает результат на всём батче (wins > losses) — это гарантирует монотонный рост качества.
Схема метода
ЦИКЛ на каждом батче задач:
ШАГ 1: Baseline Generation
Для каждой задачи → найти релевантные заметки в базе знаний (по семантической близости)
→ добавить в промпт с инструкцией оценить применимость
→ сгенерировать ответ → запомнить как baseline
ШАГ 2: Batch Clustering & Error Analysis
Весь батч задач одновременно → кластеризация по темам/предметам (LLM видит все задачи сразу)
→ группировка ошибок по темам
→ анализ паттернов внутри каждой темы (несколько ошибок → общая закономерность)
ШАГ 3: Guidance Synthesis
Для каждой темы с ошибками → создать структурированную заметку:
• Corrected Examples (исправленные примеры)
• Correct Approach (правильный подход)
• Mistake Summary (суть ошибки)
• Generalizable Strategy (общая стратегия)
• Anti-Patterns (когда НЕ применять)
→ слить с существующими заметками через RAG
→ создать candidate KB'
ШАГ 4: Selective Validation
Применить candidate KB' ко всему батчу → сгенерировать новые ответы
→ сравнить с baseline: wins - losses
→ ЕСЛИ улучшение > 0: принять обновление KB ← KB'
→ ИНАЧЕ: отбросить, вернуться к прежней KB
РЕЗУЛЬТАТ: База знаний растёт только когда новые заметки эмпирически улучшают результат
Ключевое отличие от других методов: - Batch-wise вместо instance-level — снижает шум - Selective update вместо greedy — гарантирует рост качества - Anti-patterns вместо только позитивных правил — предотвращает переприменение
Принципы для применения
Цель: Понять идеи MNL и применить в работе с LLM вручную или через простые промпты.
MNL — это сложная система с кодом (embeddings, retrieval, batch processing), но принципы метода можно использовать в обычном чате.
Принцип 1: Структурированный анализ ошибок
Когда LLM ошибается, не просто "запомнить что пошло не так", а разобрать по 5 компонентам:
Структура заметки об ошибке:
ТЕМА: [Краткое название проблемной области]
1. ИСПРАВЛЕННЫЙ ПРИМЕР:
Задача: [что было]
Моя ошибка: [что модель выдала]
Правильно: [корректный ответ]
2. ПРАВИЛЬНЫЙ ПОДХОД:
[Пошаговая методология решения]
3. СУТЬ ОШИБКИ:
[Почему произошла ошибка, корневая причина]
4. ОБЩАЯ СТРАТЕГИЯ:
[Переиспользуемый принцип для похожих задач]
5. ⚠️ АНТИПАТТЕРНЫ — когда НЕ применять:
• [Ситуация 1, когда стратегия вредит]
• [Признак 2, что стратегия неприменима]
• [Красный флаг 3]
Зачем это работает: - Блок 5 (антипаттерны) — ключевой — предотвращает переприменение. Большинство людей записывают только "что делать", но не "когда НЕ делать". LLM склонны следовать любым инструкциям в промпте, даже когда они неуместны. Явные антипаттерны дают модели "разрешение" игнорировать совет.
- 5 компонентов вместо свободной формы — снижают двусмысленность. LLM лучше работает со структурированной информацией: "извлеки общую стратегию" точнее чем "опиши что пошло не так".
Принцип 2: Batch-wise анализ вместо instance-level
Не анализируй ошибку сразу после возникновения. Собери 3-5 похожих ошибок, потом ищи паттерн.
Промпт для batch-анализа:
Вот 5 задач, где ты ошибся в последние дни. Все они про [общая тема].
[Задача 1]
Твой ответ: ...
Правильный ответ: ...
[Задача 2]
Твой ответ: ...
Правильный ответ: ...
[Задача 3-5 аналогично]
Задание:
1. Найди ОБЩИЙ паттерн в этих ошибках. Не пересказывай каждую отдельно — ищи повторяющуюся закономерность.
2. Сформулируй одну корневую причину, которая объясняет все 5 случаев.
3. Предложи стратегию, которая предотвратит ВСЕ эти ошибки в будущем.
4. Укажи ситуации, когда эта стратегия НАВРЕДИТ.
Используй структуру [вставить структуру из Принципа 1].
Почему batch-wise лучше: - Отдельная ошибка может быть случайной (glitch, edge case) — паттерн из 5 ошибок надёжнее. - LLM может переобучиться на детали одного примера ("всегда используй симметрию" → ошибка, когда симметрии нет). Паттерн из нескольких примеров — более общий. - Экономия токенов: 1 заметка на 5 ошибок вместо 5 отдельных заметок.
Принцип 3: Проверка перед добавлением в базу знаний
Не добавляй новое правило в систему, пока не проверишь что оно помогает.
Workflow: 1. Создал новую заметку на основе анализа ошибок 2. Возьми те же 5 задач + ещё 5 новых похожих 3. Реши их два раза: (а) с текущей базой знаний, (б) с новой заметкой 4. Сравни результаты: wins vs losses 5. ЕСЛИ новая заметка улучшила больше задач, чем ухудшила → добавь в базу 6. ИНАЧЕ → выброси или переформулируй
Промпт для проверки:
Я создал новое правило для базы знаний. Проверь, действительно ли оно помогает.
НОВАЯ ЗАМЕТКА:
[вставить заметку]
ТЕСТОВЫЙ НАБОР (10 задач):
[Задача 1], [Задача 2], ... [Задача 10]
Задание:
1. Реши каждую задачу БЕЗ новой заметки (используя только старые правила из базы).
2. Реши каждую задачу С новой заметкой.
3. Для каждой задачи: новая заметка помогла / навредила / не повлияла?
4. Подсчитай: wins (помогла) - losses (навредила)
5. ЕСЛИ wins > losses → заметка принята
ИНАЧЕ → заметка отклонена, нужна переформулировка
Почему это критично: - LLM могут генерировать правдоподобные, но неработающие советы. Без проверки база знаний засоряется. - Интуитивно очевидное правило может вредить в неожиданных случаях (пример из статьи: "используй симметрию" → модель применяет даже когда симметрии нет, ошибается). - Проверка на батче (не на одной задаче) даёт надёжный сигнал.
Принцип 4: Явная проверка применимости при использовании
Когда добавляешь заметку в промпт, не просто вставь совет — дай инструкцию проверить применимость.
Формат промпта с базой знаний:
БАЗА ЗНАНИЙ (использовать избирательно):
[Заметка 1]
...
⚠️ НЕ применять если: [антипаттерны]
[Заметка 2]
...
⚠️ НЕ применять если: [антипаттерны]
ИНСТРУКЦИЯ ПО ИСПОЛЬЗОВАНИЮ:
Перед решением задачи:
1. Просмотри релевантные заметки
2. Для каждой заметки: проверь антипаттерны — подходит ли ситуация?
3. ЕСЛИ антипаттерн срабатывает → проигнорируй эту заметку
4. ИНАЧЕ → используй стратегию из заметки
ЗАДАЧА:
[твоя задача]
Реши задачу, явно указав какие заметки применил, а какие отклонил и почему.
Зачем это работает: - LLM склонны выполнять любые инструкции в промпте (over-application problem). Явная проверка даёт "разрешение" игнорировать неподходящие советы. - "Объясни какие заметки применил" → включает механизм рефлексии, снижает автоматическое следование правилам.
Пример применения
Задача: Ты пишешь SQL-запросы для анализа данных интернет-магазина. За неделю собралось несколько ошибок в запросах про фильтрацию диапазонов (цены, даты, рейтинги). Хочешь систематизировать проблему и больше не ошибаться.
Шаг 1: Сбор похожих ошибок (batch-wise)
Собери все случаи за неделю, где я ошибся с операторами сравнения в SQL:
1. Задача: товары дороже 1000₽
Мой запрос: WHERE price > 1000
Проблема: не включил товары ровно за 1000₽, а в ТЗ было "от 1000₽"
2. Задача: заказы за последние 30 дней
Мой запрос: WHERE order_date > CURDATE() - INTERVAL 30 DAY
Проблема: не включил заказы ровно 30 дней назад
3. Задача: товары с рейтингом не ниже 4 звёзд
Мой запрос: WHERE rating > 4
Проблема: не включил товары с рейтингом ровно 4.0
4. Задача: скидки больше 10%
Мой запрос: WHERE discount >= 10 ✅ ПРАВИЛЬНО
5. Задача: активные пользователи (last_login за последние 7 дней)
Мой запрос: WHERE last_login > CURDATE() - INTERVAL 7 DAY
Проблема: не включил пользователей, заходивших ровно 7 дней назад
Найди общий паттерн в ошибках 1, 2, 3, 5. Почему в задаче 4 я не ошибся?
Создай заметку по структуре [5 компонентов]. КРИТИЧНО: укажи антипаттерны — когда нужен строгий >, а не >=.
Шаг 2: LLM создаёт структурированную заметку
Результат: Модель проанализирует паттерн: во всех ошибках ты использовал строгое неравенство (> или <) там, где по смыслу нужно нестрогое (>= или <=). Формулировки типа "от X", "не ниже Y", "за последние N дней" включают граничное значение, но ты системно его отсекал. В задаче 4 ты интуитивно правильно выбрал >=, потому что явно написано "больше 10%" (хотя правильно было >=10 для "от 10%").
LLM выдаст заметку из 5 блоков: исправленные примеры, правильный подход (маппинг фраз "от/до/не ниже" → оператор), суть ошибки (дефолтишь на строгие неравенства), общую стратегию (сначала перевести бизнес-требование в математическое, потом в SQL), и антипаттерны — когда действительно нужен строгий >: - "Строго больше", "выше чем", "превышает" (не включают границу) - Конкурентные сравнения: "лучше чем X", "опережает Y" - Исключающие диапазоны: "между X и Y не включая границы"
Шаг 3: Проверка на новом батче
Протестируй новую заметку на 10 задачах (5 старых + 5 новых):
Реши БЕЗ заметки, потом С заметкой. Сравни результаты. ЕСЛИ заметка улучшила ≥7 задач → добавь в базу знаний.
Шаг 4: Использование в будущем
БАЗА ЗНАНИЙ:
[Заметка "SQL: Строгие vs нестрогие неравенства"]
...
⚠️ НЕ применять если: фраза содержит "строго больше", "превышает", "выше чем"
ЗАДАЧА: Найди товары, которые продавались лучше, чем в среднем по категории
Перед решением: проверь антипаттерны заметки → "лучше чем" = строгое неравенство → НЕ применяй стратегию ">=" → используй строгий ">"
Почему это работает
Слабость 1: LLM запоминают детали вместо паттернов
Модель как студент, который зубрит решения задач, но не понимает принцип. Дашь ей один пример ошибки "используй симметрию в геометрии" → она запомнит "всегда ищи симметрию" и применит даже там, где симметрии нет (пример из статьи Figure 3: модель навязывает симметрию в задаче про касательные окружности, хотя фигуры несимметричны по вертикали). Это instance-level overfitting — переобучение на деталях одного примера.
Решение MNL: batch-wise abstraction — анализируй 5-10 похожих ошибок сразу. Если паттерн повторяется в разных контекстах — это настоящая закономерность, а не артефакт одного случая. Общий принцип из нескольких примеров устойчивее к шуму.
Слабость 2: LLM применяют все инструкции в промпте автоматически
Модель видит в промпте совет → использует его, даже если он неуместен. Это over-application problem: база знаний растёт, советы начинают конфликтовать, модель запутывается. Нет механизма "я знаю это правило, но тут оно не подходит".
Решение MNL: антипаттерны — явные запреты. "Используй X, НО НЕ если Y" — даёт модели структурированный способ отклонить совет. Проверка применимости перед использованием превращает базу знаний из набора императивов в набор условных правил.
Слабость 3: Нет механизма отката плохих обновлений
Существующие методы (Memento, TFGO) добавляют любое новое правило в систему без проверки. LLM может сгенерировать правдоподобный, но неработающий совет → он попадает в базу знаний → ухудшает результаты в будущем → откатить нельзя, база засоряется мусором.
Решение MNL: selective validation — эмпирическая проверка на батче задач. Новое правило применяется ко всем задачам в батче → подсчитываются wins (улучшения) и losses (ухудшения) → правило принимается только если wins > losses. Это гарантирует монотонный рост качества — база знаний никогда не ухудшается.
Комбинированный эффект:
Три механизма работают вместе как система фильтров: 1. Batch-wise отсеивает случайный шум на входе (не все ошибки достойны правила) 2. Антипаттерны отсеивают неуместное применение на выходе (не все правила подходят к каждой задаче) 3. Selective validation отсеивает неработающие правила перед добавлением (не все сгенерированные советы полезны)
Результат: база знаний содержит только проверенные, переиспользуемые, условные правила — каждое из них улучшило результат на реальных задачах и содержит явные ограничения применимости.
Ограничения
⚠️ Требует накопления данных: Метод начинает работать после анализа 10-20 ошибок. Для новой задачи, где ещё нет ошибок, MNL ничего не даст — нужен baseline период для сбора материала.
⚠️ Плохо работает для субъективных задач: MNL требует чёткой функции оценки правильности (exact match для SQL, числовой ответ для математики). Для креативных задач (написать слоган, придумать метафору) нет однозначного "правильного ответа" — непонятно, улучшило ли новое правило результат или нет.
⚠️ Затраты на проверку: Каждое обновление базы знаний требует прогнать весь батч задач дважды (с новым правилом и без). Для больших батчей (50+ задач) это удваивает количество запросов к API. На маленьких задачах (GSM8K) это $1.20, на сложных (KaggleDBQA) может быть дороже.
⚠️ Риск переоптимизации на узкий домен: Если база знаний заполнялась на задачах одного типа (например, геометрия окружностей), правила могут плохо переноситься на другие типы (комбинаторика, алгебра). MNL группирует ошибки по темам, но не гарантирует что правило из темы A не навредит в теме B при пересечении контекстов.
Как исследовали
Исследователи взяли четыре бенчмарка разного уровня сложности: GSM8K (школьная математика, 8.5K задач), Spider (Text-to-SQL, 1K запросов), AIME (олимпиадная математика, сложность — только 14% людей решают), KaggleDBQA (реальные SQL-задачи из соревнований Kaggle, самый сложный). Протестировали на трёх моделях: Qwen3-8B (лёгкая), DeepSeekV3-7B (средняя), Qwen3-Max (тяжёлая). Цель — показать, что MNL работает на разных масштабах: от простых задач (GSM8K) до соревновательных (AIME, KaggleDBQA), и на моделях разного размера.
Дизайн эксперимента — сравнение с четырьмя типами baseline:
- Zero-shot — модель без контекста (самый слабый baseline)
- Few-shot ICL — добавили 5-10 примеров в промпт (классический ICL)
- Training-free методы — Memento (память из траекторий), TFGO (оптимизация контекста через сравнения), ReasoningBank (стратегии из прошлых решений)
- Supervised Fine-Tuning (SFT) — полноценный fine-tuning на обучающих данных (самый сильный baseline)
Главная интрига: может ли training-free метод (MNL) догнать SFT?
Результаты удивили даже авторов:
На GSM8K: MNL (93.9%) почти догнал SFT (94.3%) — разница всего 0.4%. При этом SFT требует обновления весов модели, доступ к GPU, риск catastrophic forgetting. MNL — просто улучшает промпт.
На KaggleDBQA (самый сложный): MNL показал 47% relative improvement с Qwen3-8B — вырос с 19% (zero-shot) до 28%. Это больше чем у всех training-free конкурентов: Memento (15.1%), TFGO (22.1%). Интересно, что на сложных задачах разрыв между MNL и конкурентами растёт — простые методы ломаются, MNL держится.
Стоимость: На GSM8K MNL стоил $1.20 за обучение против $1.99 у SFT (40% дешевле). На KaggleDBQA MNL достиг 45.9% accuracy за $0.19, а Memento нужно $0.43 для 47% (в 2.3 раза дороже). Cost-accuracy tradeoff — MNL даёт лучшее соотношение цена/качество.
Почему такие результаты?
Авторы провели ablation study (убирали компоненты метода по одному) и выяснили:
- Без selective validation: точность падает на 3-5% — система начинает принимать вредные правила
- Без anti-patterns: модель переприменяет правила, точность падает на 2-4%
- Instance-level вместо batch-wise: шумные правила, точность падает на 4-6%
Каждый компонент MNL критичен. Комбинация всех трёх (batch-wise + anti-patterns + selective validation) даёт синергию.
Инсайт для практики: На простых задачах (GSM8K) даже простые методы работают — разница между MNL и Memento небольшая. Но на сложных задачах (KaggleDBQA, AIME) разрыв огромный — там нужна систематичность MNL. Если работаешь с рутинными задачами — можно обойтись простым ICL. Если задачи сложные и разнообразные — нужна структурированная база знаний с проверкой.
Ресурсы
- Mistake Notebook Learning: Selective Batch-Wise Context Optimization for In-Context Learning — препринт от 15 декабря 2025
- Авторы: Xuanbo Su, Yingfang Zhang, Hao Luo, Xiaoteng Liu, Leo Huang (Bairong Inc., Harbin Institute of Technology, Jilin University)
- Бенчмарки: GSM8K, Spider, AIME, KaggleDBQA
- Сравнение с: Memento (Zhou et al., 2025), TFGO (Cai et al., 2025), ReasoningBank (Ouyang et al., 2025)