Что это и как работает: BASM — способ хранить примеры прошлых решений так, чтобы модель не копировала их слепо. К каждому примеру-навыку добавляют не только «как делать», но и «когда это делать нельзя»: условия применимости, признаки риска, что избегать, как исправить если не сработало.
Главная находка: Когда модели дают только успешные примеры прошлых решений — она видит похожую задачу и повторяет старый приём инструмента, даже если реальный контекст требует другого инструмента. И чем больше похожих примеров дают модели, тем увереннее она хватается за неправильный инструмент — потому что видит паттерн действия, но не видит сигнала «стоп, тут не так». Исследователи замерили: модель предпочитала неправильный инструмент на 47% сильнее, если ей давали больше «успешных» примеров без границ.
Суть метода: К каждому примеру-навыку добавляют 4 явных поля кроме описания процедуры: когда применимо, признаки риска (когда не применимо), что не делать, как исправить если не сработало. Модель сначала проверяет условия, потом решает — применить приём, отказаться от него или исправить ошибку.
Схема метода
ШАГ 1: Извлечь навык из прошлого опыта → 7 полей: цель, процедура, инструменты + условия применимости, риски, запреты, план восстановления
ШАГ 2: При новой задаче найти похожие навыки → топ-k релевантных примеров
ШАГ 3: Перед использованием проверить условия → применить / подавить / исправить
Оригинал реализован через код (эмбеддинги, поиск, JSON-схемы), но принцип — структура примера с границами применимости — переносится в обычный промпт без кода.
Пример применения
Задача: Служба поддержки маркетплейса хочет, чтобы GPT отвечал клиентам, используя базу прошлых успешных ответов как образец — но не отправлял шаблон «оформили возврат за 3 дня», если у клиента нестандартный случай (товар уже использован, брак обнаружен после 14 дней, повторное обращение).
Промпт:
Ты работаешь с базой прошлых успешных решений поддержки. Каждый пример оформлен так:
НАВЫК: Возврат неисправного товара
- Цель: оформить возврат за брак
- Процедура: попросить фото брака → создать заявку → уведомить клиента о сроках
- Применимо когда: товар не использовался, обращение в течение 14 дней с покупки
- Признаки риска: клиент упоминает "пользовался", "прошло больше 2 недель", "уже писал раньше"
- Не делай: не обещай возврат автоматически, если есть признаки риска
- Если не сработало: если клиент недоволен стандартной процедурой — предложи эскалацию на старшего специалиста
Текущее обращение клиента: {текст_обращения}
Проверь: подходят ли условия "Применимо когда" к этому обращению?
- Если да — используй процедуру.
- Если есть признаки риска — не используй шаблон, объясни клиенту нестандартность случая и предложи альтернативу.
- Если процедура уже была применена и клиент недоволен — используй "Если не сработало".
Результат: Модель сначала явно сверяет обращение клиента с условиями применимости, и только потом либо выдаёт стандартный ответ, либо помечает случай как нестандартный с объяснением почему, либо переходит к плану восстановления. Ответ придёт в виде короткого решения + обоснования, почему выбран этот путь.
Почему это работает
Модель, увидев похожий пример, по умолчанию фокусируется на процедуре — «как это было сделано в прошлый раз» — и переносит её на новую ситуацию, даже если условия другие. Никакого встроенного сигнала «здесь стоп» у неё нет.
При этом модель хорошо считывает явные условия в тексте — конструкции «если… то…», «применимо когда», «не делай если». Когда такие условия прописаны явно, модель использует их как фильтр перед действием, а не после.
Метод превращает пример из «шаблона для копирования» в «условное правило»: сначала проверка условий, потом действие. Это и есть рычаг — если убрать поля риска и запретов, модель вернётся к слепому копированию.
Рычаги управления: - Поля риска и запретов — самые важные, убирать их последними. Именно они гасят слепое копирование. - План восстановления — можно упростить или убрать для одноразовых задач без повторных попыток. - Число примеров-навыков в контексте — больше примеров без границ вредит (усиливает неправильный выбор), с границами — не вредит. Для простых задач достаточно 1-2 примеров с границами.
Шаблон промпта
Ты работаешь с базой прошлых решений задачи "{тип_задачи}". Для каждого решения используй структуру:
НАВЫК: {название}
- Цель: {что_решает}
- Процедура: {шаги_решения}
- Ресурсы/инструменты: {что_нужно}
- Применимо когда: {условия_подходящей_ситуации}
- Признаки риска: {что_говорит_что_ситуация_другая}
- Не делай: {что_нельзя_повторять_в_рискованном_случае}
- Если не сработало: {как_исправить}
Текущая ситуация: {описание_задачи}
Сначала проверь: подходят ли условия "Применимо когда"?
— Да → используй процедуру.
— Есть признаки риска → не копируй процедуру, объясни отличие и предложи альтернативу.
— Процедура применена, но не сработала → используй "Если не сработало".
🚀 Быстрый старт — вставь в чат:
Вот шаблон Boundary-Aware Skill Memory. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля на основе моих реальных прошлых кейсов.
[вставить шаблон выше]
LLM спросит про твои конкретные прошлые случаи — где приём сработал, а где похожая ситуация обманула — потому что без этого различия границы применимости не заполнить. Она возьмёт структуру полей и адаптирует под твою базу знаний.
Ограничения
⚠️ Нужна ручная разметка: чтобы границы сработали, нужно самому (или с помощью модели) проанализировать, где приём не срабатывал — просто списка успешных кейсов недостаточно.
⚠️ Работает для повторяющихся задач с вариациями: если каждая задача уникальна и нет похожих прошлых случаев, границы применимости бессмысленны.
⚠️ Проверено на задачах с вызовом инструментов/функций: перенос принципа на чисто творческие или текстовые задачи в исследовании не тестировался.
Ресурсы
When Not to Imitate: Boundary-Aware Skill Memory for Reliable Tool-Use LLM Agents — Zihan Lin, Zhenyu Chen, Jiawen Wei и др., Meituan / Institute of Automation, Chinese Academy of Sciences (CASIA) / UCAS.