TL;DR
QCR — техника повторного использования прошлого опыта LLM: вместо того чтобы вставлять в промпт всю историю решения похожей задачи целиком, модель сначала превращает её в компактную заметку из четырёх частей — какой шаблон действий остаётся неизменным, какие значения нужно проверить заново (имена, даты, номера — всё, что изменилось), когда этот шаблон вообще не подходит, и как проверить итоговый результат.
Главная находка: чем длиннее прошлая история, которую копируют в промпт для новой похожей задачи, тем хуже результат. Модель начинает буквально копировать старые детали — имя прошлого клиента, старый номер заказа, устаревшую дату — вместо того чтобы найти актуальные значения для новой задачи. Полная история не столько помогает объёмом, сколько заражает контекст устаревшими фактами, и это перевешивает пользу от количества информации.
QCR решает это явным разделением: перед тем как показать модели прошлый успешный кейс, его превращают в короткую заметку с четырьмя полями — что делать одинаково всегда, что нужно узнать заново, в каких случаях не применять этот шаблон, как проверить, что всё сделано верно. Модель работает с этой заметкой, а не с сырой историей.
Схема метода
ШАГ 1 (отдельный запрос): Дай модели прошлый успешный пример решения похожей задачи
→ попроси разложить его на 4 поля:
1. Workflow — неизменный порядок действий
2. Bindings — конкретные значения, которые нужно ЗАНОВО проверить/узнать
3. Applicability — условия, когда этот шаблон НЕ подходит
4. Verification — как проверить итоговый результат
→ формат вывода: короткая заметка (в 2 раза короче исходной истории)
ШАГ 2 (новый запрос): Дай модели эту заметку + описание новой задачи
→ модель решает новую задачу по шаблону, но не тащит старые значения
→ формат вывода: решение новой задачи + явная проверка по гайдрейлу
Пример применения
Задача: Рекрутер в найме вёл переговоры с кандидатом на позицию менеджера — успешно закрыл сделку: договорился про зарплату, дату старта, обсудил релокацию. Теперь нужно провести такие же переговоры с новым кандидатом на похожую позицию, но с другими условиями.
Промпт (шаг 1):
Вот переписка, где я успешно договорился с кандидатом Иваном о найме на позицию
менеджера по продажам (зарплата 180к, старт 1 марта, без релокации):
{вставить переписку}
Разбери этот успешный кейс на 4 части:
1. Workflow — какая последовательность шагов в переговорах сработала (независимо от деталей)
2. Bindings — какие конкретные значения (зарплата, даты, условия)
я должен будет заново узнать/обсудить с новым кандидатом, а не брать из этого кейса
3. Applicability — в каких ситуациях этот подход к переговорам не сработает
4. Verification — как проверить, что переговоры с новым кандидатом прошли так же успешно
Дай короткую заметку, без цитирования старой переписки.
Результат: Модель выдаст компактную заметку на 4 пункта: например, workflow — «сначала обозначить вилку зарплаты, потом обсудить нематериальные условия, потом закрепить дату старта письменно»; bindings — «зарплата, дата старта, релокация — для нового кандидата все эти пункты нужно обсудить с нуля»; applicability — «подход не сработает, если кандидат уже имеет офер от конкурента с дедлайном»; verification — «переговоры успешны, если кандидат подтвердил дату старта письменно». Эту заметку дальше можно вставить в новый диалог о переговорах со следующим кандидатом — без риска, что модель случайно предложит новому человеку зарплату или дату Ивана.
Почему это работает
Слабость LLM: когда в контексте лежит длинная прошлая история с конкретными именами, датами и цифрами, модель склонна буквально повторять эти значения для новой задачи — они «на виду» и выглядят как готовый ответ, даже если они уже неактуальны. Это не ошибка логики, а эффект того, что все детали в контексте выглядят одинаково весомыми, и старые конкретные цифры для модели неотличимы от актуальных.
Сильная сторона LLM: модель отлично умеет разделять общее и частное, если её явно попросить — вытащить закономерность отдельно от конкретных цифр это стандартная задача на извлечение структуры, с которой LLM справляется хорошо.
QCR использует это: заставляет модель сначала явно назвать, что в прошлом кейсе — правило, а что — временное значение, которое надо проверить снова. Дальше модель работает не с полным текстом, а с этой разметкой, и у неё нет соблазна скопировать старую цифру, потому что рядом явно написано «это нужно узнать заново».
Рычаги управления: - Количество полей (4) → для простых повторяющихся задач можно сократить до 2 (workflow + bindings), для рискованных задач (юридические документы, финансы) добавить больше проверочных условий. - Поле Verification → замени формулировку под свою задачу («проверить, что сумма совпадает с договором» вместо общего «проверить результат»). - Applicability → явно добавь свои условия отказа от повторного использования шаблона — это защищает от слепого копирования подхода туда, где он не подходит.
Шаблон промпта
Вот успешный прошлый кейс решения похожей задачи:
{текст прошлой переписки/решения}
Новая задача:
{описание новой задачи}
Разбери прошлый кейс на 4 части и дай короткую заметку (без цитирования исходного текста):
1. Workflow — какая последовательность действий/подход сработали и остаются актуальными
2. Bindings — какие конкретные значения (имена, даты, числа, условия) из прошлого кейса
НЕ подходят для новой задачи и должны быть заново получены/уточнены
3. Applicability — при каких условиях этот подход вообще неприменим к новой задаче
(когда лучше не использовать этот шаблон)
4. Verification — как проверить, что новая задача решена так же успешно, как прошлая
Используй эту заметку, чтобы решить новую задачу — не копируй значения из прошлого кейса.
Подставь: {текст прошлой переписки/решения} — любой прошлый успешный результат (переговоры, письмо, отчёт, код, план); {описание новой задачи} — новая похожая ситуация с другими деталями.
🚀 Быстрый старт — вставь в чат:
Вот шаблон QCR (повторное использование прошлого опыта). Адаптируй под мою задачу:
{твоя задача}. Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит какой именно прошлый кейс использовать и что именно изменилось в новой задаче — потому что без этого она не сможет разделить «правило» и «значения для проверки». Она возьмёт структуру из шаблона и адаптирует под твою ситуацию.
Ограничения
⚠️ Нужен реально похожий прошлый пример: если у вас нет успешного прошлого кейса с похожей структурой задачи, у QCR нет из чего извлекать шаблон — метод не создаёт опыт с нуля, только переупаковывает уже существующий.
⚠️ Не работает, если задачи структурно разные: метод помогает, когда меняются детали (имена, даты, цифры), но сам подход к задаче одинаковый. Если новая задача требует другой логики решения — заметка не спасёт.
⚠️ Прошлый пример нужно находить вручную: в исследовании это делал автоматический поиск по базе. В чате вам придётся самому решить, какой прошлый разговор релевантен новой задаче — модель не сделает это за вас.
Ресурсы
Yifei Li, Heng Wang, Lingling Zhang и др. (Xi'an Jiaotong University), «Beyond Retrieval: Query-Conditioned Reuse of Long-Horizon Agent Trajectories». Тестировали на бенчмарках агентов WebArena, WorkArena, AppWorld.