TL;DR
Когда AI-ассистент с памятью получает новую информацию от вас, он должен решить: закрепить это навсегда, использовать только сейчас, перепроверить позже или спросить уточнение. Исследователи проверили, как модели делают этот выбор, и дали им либо явный список из пяти правил («policy prompt»), либо четыре примера правильных решений (few-shot).
Главная находка неприятная: модели почти никогда не спрашивают уточнение, даже когда ситуация явно неоднозначна. Если вы говорите "сделай как в прошлый раз" при нескольких похожих вариантах — модель скорее угадает и молча закрепит свою догадку в памяти, чем переспросит. В одном из тестов модель без подсказок правильно спросила уточнение 0 раз из 12 нужных случаев, хотя корректно перепроверяла изменяющиеся факты в 12 из 18 случаев. То есть модель охотнее "сходит проверить в источник", чем "спросит у вас" — хотя источник истины здесь именно вы.
Явный policy prompt с пятью правилами снижает ошибочное постоянное запоминание почти в два раза (с 24% до 10% случаев). Few-shot примеры повышают общую точность решений заметнее. Но ни один приём не решает проблему недоспрашивания — модель всё равно упускает большинство случаев, где стоило задать вопрос.
Схема метода
ШАГ 1: Добавить в промпт явные правила разграничения 4 действий → policy prompt (один запрос)
ШАГ 2 (опционально, усиливает эффект): добавить 4 примера-демонстрации —
по одному на каждое действие (запомнить/разово/перепроверить/спросить) → few-shot
Оба шага применяются в одном system-промпте или custom instructions — без дополнительных запросов.
Пример применения
Задача: Вы настроили в ChatGPT/Claude персонального ассистента, который ведёт заметки о клиентах для вашего фриланс-бизнеса или небольшого агентства. Клиент в переписке пишет: "Скидка 20%, как договаривались с Ольгой в прошлом месяце".
Промпт (custom instructions / system prompt):
Когда ты получаешь новую информацию, которая может повлиять на твои будущие ответы
об этом клиенте, выбери одно из четырёх действий:
1. ЗАПОМНИТЬ НАВСЕГДА — если это явное постоянное условие или факт,
который клиент/пользователь прямо хочет закрепить.
2. ИСПОЛЬЗОВАТЬ ТОЛЬКО СЕЙЧАС — если информация касается только текущей
задачи или разговора и не должна переноситься дальше.
3. ПЕРЕПРОВЕРИТЬ — если факт может измениться со временем (цена, статус,
договорённость), и нельзя слепо доверять старой версии позже.
4. СПРОСИТЬ — если неясно, к чему относится информация, насколько она
постоянна, или это пересказ чужих слов ("договаривались с Ольгой") —
в этих случаях только человек может дать точный ответ.
Если сомневаешься между "запомнить навсегда" и более слабым действием —
выбирай более слабое. Лишний вопрос не страшен, ошибочная постоянная
запись — проблема.
Ситуация: {вставить сообщение клиента}
Результат: Модель явно назовёт, какое из четырёх действий выбирает, и объяснит почему — например, отметит, что "договаривались с Ольгой" это второстепенное свидетельство и нужно уточнение у пользователя, а не автоматическое закрепление скидки в памяти клиента.
Почему это работает
LLM по умолчанию склонны действовать, а не спрашивать — это похоже на человека, который стесняется переспросить и лучше угадает. Особенно ярко это видно, когда модель встречает неопределённость: она скорее попробует "перепроверить" факт (как будто это безопаснее), чем признается, что не понимает вас, и задаст вопрос.
Сильная сторона моделей — они хорошо следуют явным спискам правил, если правила прописаны текстом. Именно поэтому policy prompt работает: он не учит модель "думать по-новому", а превращает смутное решение "запомнить или нет" в понятную классификацию по четырём чётким категориям.
Рычаги управления: - Сами правила persist/ephemeral/verify/clarify — можно переформулировать под свою предметную область (например, для CRM, для личного дневника, для проекта с командой). - Few-shot примеры — добавьте 1-2 примера именно тех неоднозначных ситуаций, которые часто встречаются в вашей практике, это усиливает эффект сильнее, чем просто правила. - Явная фраза "при сомнении выбирай более слабое действие" — это asymmetric tie-breaker, который стоит сохранить: он смещает модель от риска молча запомнить ошибку в сторону более безопасного поведения.
Ограничения
⚠️ Проблема недоспрашивания не решается: даже с правилами и примерами модель правильно уточняла лишь треть нужных случаев. Не рассчитывайте, что policy prompt научит ассистента активно с вами советоваться — он в основном снижает ошибочное постоянное запоминание, а не заставляет модель чаще задавать вопросы.
⚠️ Слова ≠ действия: если ваш ассистент использует функции (например, "сохранить в памяти", "запросить у пользователя") а не просто текстовые ответы, то то, что модель говорит о решении, и то, что она реально вызывает как функцию — разные вещи. В тестах расхождение достигало 40-70%. Если строите ассистента с function calling, проверяйте реальные вызовы, а не только объяснения модели.
⚠️ Проверено на английском и синтетических сценариях: выводы основаны на 70-140 искусственно созданных ситуациях на английском языке, не на реальных диалогах пользователей.
Как исследовали
Команда создала 140 сценариев, где у модели есть исходная информация от пользователя и ситуация, в которой её нужно применить повторно. Каждый сценарий размечен верным действием — запомнить, использовать разово, перепроверить или спросить. Разметку независимо проверяли два человека, не связанных с авторами (совпадение 97%), а спорные случаи разрешал третий "слепой" судья — это редкий уровень строгости для такого исследования.
Протестировали три модели из двух разных семейств: Claude Haiku, Claude Sonnet и локальный Qwen. Каждой давали три варианта промпта — без подсказок, с явными правилами (policy) и с примерами (few-shot), — а потом сравнивали результаты попарно на одних и тех же вопросах (это честнее, чем сравнивать модели по отдельности).
Удивительный результат: policy prompt у Qwen почти не повысил общую точность статистически значимо, но при этом вдвое снизил долю ошибочных постоянных записей — то есть эффект был "невидим" в общей метрике точности, но реален в конкретном опасном поведении. Это и есть главный практический вывод: если измерять только "правильно/неправильно", легко упустить, что промпт всё-таки изменил поведение модели в лучшую сторону — просто не в той метрике, на которую смотрели.
Отдельно проверили, совпадает ли то, что модель заявляет как решение, с тем, что она реально вызывает как функцию (tool call). Совпадение оказалось всего 23-57% — то есть привычка модели "говорить одно, а по факту вызывать другое" — распространённая проблема, а не случайность одной модели.
Ресурсы
Baichuan Li (Southern Methodist University), Junyi Yao, Zihao Zheng (Washington University in St. Louis). Бенчмарк MCB (Memory–Clarification Boundary), включает данные, разметку, промпты и код для воспроизведения. Упомянутые связанные работы: LongMemEval, LoCoMo, MemBench, CLAMBER, τ-bench.