AutoGuide: как агенту вспомнить правило в нужный момент
Агент может помнить полезный совет и ошибаться именно из-за него. «Сначала открой первый результат» помогает при поиске по точному номеру и мешает, когда выдача содержит несколько похожих обращений. Для памяти важно сохранить условия, при которых совет имеет смысл, а затем узнать эти условия в текущей работе.
Стрелки показывают, откуда берётся следующий шаг. Условия и ограничения разобраны в статье.
Эту задачу рассматривают Yao Fu и соавторы в AutoGuide. Здесь разобрана версия 2403.08978v2 от 3 декабря 2024 года. После краткого описания метода мы построим собственный пример и проверочную процедуру. Пример и рекомендации ниже не являются экспериментом из работы.
Что именно предлагает метод
AutoGuide сравнивает заранее собранные траектории одной задачи с разными результатами. Траектория — последовательность наблюдений и действий. В месте расхождения система описывает ситуацию и извлекает условную рекомендацию. Похожие описания ситуаций объединяются; рекомендации сохраняются по соответствующему контексту. Метод, §3.1–3.2.
Во время выполнения новой задачи ситуация определяется заново на каждом шаге. Для неё выбираются подходящие рекомендации, при необходимости — ограниченный набор наиболее полезных. Вместе с текущей ситуацией их передают модели для выбора действия. При отсутствии совпадения набор может быть пустым. Это помощь в принятии следующего решения, а не исполнение заранее заданного маршрута. Применение, §3.3 и алгоритм 2.
Для меня основной проектный вопрос здесь звучит так: какие признаки нужно сохранить, чтобы полезное правило не стало вредным при переносе?
Два прогона одной задачи
Представим вымышленную службу поддержки. Агенту поручили найти текущее обращение клиента по поводу замены оборудования и сообщить его статус. У клиента несколько похожих заявок: одна закрыта год назад, другая открыта вчера. В поисковой выдаче обе выглядят правдоподобно.
В первом прогоне агент ищет по названию клиента, открывает верхний результат и отвечает: «Обращение закрыто». Во втором он сначала ограничивает выдачу открытыми заявками, сверяет тему и дату, затем открывает нужную карточку. Для учебной проверки у нас заранее известен номер требуемого обращения, поэтому мы можем различить правильный и неправильный результат независимо от уверенности агента.
Из этой пары можно предложить такую запись:
На странице результатов поиска обращений, если требуется текущее открытое обращение клиента, проверь статус и соответствие теме до выбора карточки.
Это наш пример условной рекомендации. В нём есть место действия, цель и проверяемое ограничение. Из него убраны название клиента, номер заявки и её положение в выдаче: эти значения принадлежат конкретному случаю.
Но одной удачной формулировки недостаточно. Возможно, второй прогон выиграл потому, что искал другое слово, а фильтр не имел отношения к результату. Сопоставление двух историй даёт кандидата на полезное правило; причинную роль отдельных действий в нашем примере придётся проверять отдельными заданиями.
Где начинается ошибочное обобщение
Теперь пользователь просит: «Найди закрытое обращение, в котором мы согласовали замену». Сайт и клиент прежние. Если память узнаёт только экран поиска, совет отбирать открытые заявки срабатывает ошибочно.
Поэтому я бы проверял запись на трёх уровнях:
| Уровень | Вопрос к нашей памяти | Ошибка при пропуске |
|---|---|---|
| Место | Агент действительно видит выдачу обращений? | Совет о фильтре применяется внутри карточки или в другом разделе |
| Намерение | Нужна текущая открытая заявка или историческое свидетельство? | Архив исключается из поиска, хотя ответ находится именно там |
| Наблюдаемое условие | Статусы доступны и означают то, что предполагает правило? | Агент доверяет старому названию фильтра после изменения интерфейса |
Эта таблица — мой способ проверки примера, а не дополнительный модуль AutoGuide. Она помогает различить похожесть текста и применимость действия.
Условие также не стоит делать чрезмерно узким. Запись «на странице клиента Север, после поиска слова “насос”, нажми второй результат» почти не переносится. Запись «всегда проверяй всё» переносится куда угодно, но слабо помогает выбрать конкретный следующий шаг. Рабочая формулировка находится между этими крайностями: достаточно общая для следующего клиента и достаточно точная для наблюдаемой ситуации.
Память должна допускать отсутствие ответа
Предположим, агент встретил новый экран: вместо статуса система показывает сроки и ответственных. В нашей библиотеке есть только рекомендация про фильтр открытых обращений.
Мне важно, чтобы система могла признать: подходящей подсказки сейчас нет. Иначе выбор «самого похожего» правила незаметно превращается в обязательное применение чужого опыта. Следующее действие тогда следует выводить из задачи и доступных наблюдений, а при нехватке основания — уточнять данные.
Это особенно заметно после обновления продукта. Слова в памяти могут сохраниться, а смысл интерфейса — измениться. Например, «активные» теперь означает заявки, назначенные текущему оператору, а не все незакрытые обращения. Текстовое совпадение стало сильнее, а практическая применимость — хуже.
Для собственной реализации я бы связывал рекомендацию с исходными прогонами и описанием среды. Не обязательно добавлять всё это в каждый запрос модели. Ссылки нужны тому процессу, который проверяет, исправляет и при необходимости исключает запись из применения.
Как проверить пользу на своей задаче
Начать можно с небольшой контролируемой коллекции обращений. Все имена и номера — тестовые; правильная карточка и допустимый ответ известны заранее. Следующие сценарии проверяют разные причины ошибки.
| Сценарий | Что должно произойти |
|---|---|
| Открытая и закрытая заявки имеют одинаковую тему | Агент выбирает карточку по условиям запроса, а не позиции в выдаче |
| Пользователь прямо ищет закрытую заявку | Правило про открытые обращения не применяется |
| У клиента две открытые заявки | Агент учитывает дополнительные признаки или сообщает о неоднозначности |
| Интерфейс изменил смысл фильтра | Агент не принимает знакомое название за подтверждение прежнего смысла |
| Подходящих рекомендаций нет | Память не подставляет произвольный совет ради непустого ответа |
Я бы сравнил три варианта одного агента: без этой памяти, со всеми нашими рекомендациями сразу и с выбором по ситуации. Модель, доступные записи, ограничения действий и число попыток должны совпадать. Иначе мы проверим сразу несколько изменений и не узнаем, помог ли именно выбор памяти.
Для каждого прогона полезно записать найденную карточку, использованное правило и наблюдение, на основании которого его выбрали. Дополнительно стоит считать лишние переходы, обращения к модели и случаи неверной уверенности. Сокращение числа ошибок может оказаться полезным даже без ускорения; ускорение поиска неправильной карточки пользы не даёт.
Что позволяют сказать опубликованные эксперименты
Авторы оценивали метод на ALFWorld, WebShop, части WebArena и отдельных задачах реальных сайтов. Основной тест WebArena ограничен Reddit; перенос на Shopping использует дополнительное согласование с новой средой. В ограничениях отмечены зависимость от разнообразия исходного опыта и отсутствие стандартизованной оценки качества рекомендаций. Эксперименты, §4, ограничения, приложение A, детали оценки, приложение B.
Мы не воспроизводили эти эксперименты. Для нашей службы поддержки результаты работы дают основание проверить подход, но не готовую оценку его надёжности. Особенно важно собрать случаи, в которых знакомая рекомендация неприменима: именно они позволяют увидеть цену ошибочного переноса.
Начните с одного повторяющегося промаха. Сохраните ситуацию, полезное действие и пример, где это действие делать не следует. Затем проверьте, различает ли агент эти случаи. Такой результат даст конкретное основание расширять библиотеку или менять способ выбора.
Термины
- Траектория — запись наблюдений и действий за одну попытку выполнить задачу.
- Условная рекомендация — совет, связанный с ситуацией, в которой его предполагается применять.
- Контекст ситуации — краткое описание текущего положения агента; здесь это не всё содержимое запроса модели.
- Применимость — соответствие рекомендации текущей цели, наблюдениям и условиям среды.
Источник
Yao Fu, Dong-Ki Kim, Jaekyeom Kim, Sungryull Sohn, Lajanugen Logeswaran, Kyunghoon Bae, Honglak Lee. AutoGuide: Automated Generation and Selection of Context-Aware Guidelines for Large Language Model Agents. Проверенная редакция: arXiv:2403.08978v2, 3 декабря 2024 года. Карточка и история версий, полный текст.
Все материалы по теме: «Организационная и агентская память».
Хотите внедрить это у себя?
Помогаю командам перейти на агентную разработку: как советник, через обучение команды или внедрение изменений с проверкой эффекта по данным. Короткие заметки между статьями выходят в Telegram-канале.