WikiSkill от Google Research дает ИИ-агентам постоянную запись их ошибок

Google Research представила WikiSkill — фреймворк, призванный помогать ИИ-агентам улучшать результаты в повторяющихся задачах, сохраняя информацию о том, что сработало, а что нет. Вместо обновления параметров модели система записывает опыт выполнения в постоянную, похожую на wiki, базу знаний и превращает выбранные уроки в переиспользуемые инструкции.

Этот подход устраняет ключевую слабость современных ИИ-агентов: информация, собранная во время одного запуска, часто выбрасывается, когда задача заканчивается. В описанном исследовании WikiSkill показал существенный прирост по нескольким бенчмаркам, хотя результаты относятся к исследовательской оценке, а не к коммерческому запуску продукта или независимо проверенному внедрению.

Трехуровневая система памяти для ИИ-агентов

WikiSkill организует рабочее пространство агента в три слоя. Raw Layer хранит полные трассы выполнения, включая вызовы инструментов и их результаты. Согласно описанию исследования, о котором сообщает The Decoder, этот материал неизменяем и служит доказательной базой для последующего анализа.

Wiki Layer преобразует эти трассы в структурированные знания. Она может фиксировать повторяющиеся паттерны ошибок, успешные стратегии и уроки из предыдущих попыток. В отличие от активных инструкций, которыми пользуется агент, этот слой рассчитан на длительное хранение и расширение со временем.

Skill Layer содержит процедурные указания, которые агент действительно использует. Эти инструкции упакованы как «Agent Skills», что позволяет системе менять подход к задаче без изменения весов обучения модели. Навыки можно откатывать, если обновление снижает производительность, а базовый wiki сохраняет запись о том, что было предпринято.

Рабочий процесс разделяет сбор опыта и обновление инструкций. Агент вывода выполняет задачи и создает трассы. «Wiki Maintainer» анализирует эти трассы, а «Skill Proposer» использует накопленную информацию, чтобы предложить изменения. Затем механизм фильтрации оценивает предложение на отдельном валидационном наборе. Если предложенный навык не помогает, его отклоняют, но неудачный эксперимент остается доступным для будущих предложений.

Такой дизайн ближе к постоянной внешней памяти и итеративной оптимизации промптов или рабочих процессов, чем к непрерывному обучению внутри модели. The Decoder отметил, что базовая модель после развертывания по-настоящему не учится; вместо этого система записывает более удачные инструкции и извлекает их в последующих запусках.

Сообщаемый прирост по бенчмаркам с важными ограничениями

Исследователи оценивали WikiSkill в пяти областях: математическое рассуждение, веб-поиск, работа с таблицами, ответ на вопросы по документам и интерактивные задачи в виртуальной среде. Среди упомянутых моделей были несколько вариантов Qwen, Gemma-4-31B и Gemini-3.5-Flash.

Согласно результатам исследования, на которые ссылается The Decoder, WikiSkill повысил средний показатель Gemini-3.5-Flash с 49,5% до 68,1%. Qwen-3.6-27B в том же сравнении вырос с 39,4% до 63,3%. На отдельных задачах рост был еще выше: Gemini-3.5-Flash поднялся с 33,0% до 72,6% на LiveMath и с 50,5% до 76,6% на SpreadSheet.

Это заявления на уровне исследовательских бенчмарков, а не доказательство того, что WikiSkill даст такие же результаты в продакшене. Сообщается, что оценка усредняла три независимых прогона, а фреймворк сравнивался с другими методами эволюции навыков в рамках исследования. Доступных материалов недостаточно, чтобы оценить полный экспериментальный дизайн, эксплуатационные издержки или поведение системы на меняющихся данных реального мира.

Производительность также различалась в зависимости от задачи. Наибольшие улучшения наблюдались в математике и работе с таблицами, тогда как OfficeQA, связанная с длинными документальными контекстами, получила гораздо меньшую пользу. Исследователи частично объяснили более слабые результаты меньших моделей трудностями с выполнением эволюционировавших многошаговых стратегий поиска на длинных контекстах. В таких случаях модели иногда возвращались к поведению по умолчанию.

Результаты показывают, что постоянная память не снимает ограничений по возможностям модели. Система может успешно задокументировать полезную процедуру, но не суметь надежно ее выполнить, особенно если процедура включает много шагов, длинные контекстные окна или несколько взаимодействий с инструментами.

Что это означает для разработчиков и компаний

Для разработчиков ИИ WikiSkill предлагает практическую альтернативу повторному обучению каждый раз, когда агент снова и снова сталкивается с одним и тем же типом задачи. Ассистент для кодинга, исследовательский агент или оператор таблиц могли бы сохранять проверенные процедуры, документировать неудачные вызовы инструментов и постепенно совершенствовать рабочий процесс. Это могло бы снизить необходимость помещать каждый урок в постоянно разрастающийся системный промпт, при условии, что память структурирована и извлекается выборочно.

Разделение между Wiki Layer и Skill Layer особенно важно для продакшн-систем. Команды могли бы сохранять полный аудиторский след, позволяя при этом только проверенным инструкциям влиять на живое поведение. Откаты сделали бы эксперименты менее рискованными, чем прямое редактирование промпта или политики агента, хотя качество Maintainer и процесса фильтрации по-прежнему определяет, попадут ли плохие уроки в активный набор навыков.

Фреймворк также может повлиять на экономику моделей. В исследовании сообщается, что меньшие модели с WikiSkill в некоторых сценариях могут сравняться по качеству с более крупными моделями без фреймворка. Если такой паттерн сохранится за пределами протестированных бенчмарков, компании смогут использовать постоянные навыки для снижения затрат на инференс или резервировать более крупные модели для сложных случаев. Однако этот вывод остается условным: источник не раскрывает общие затраты системы, включая хранение трасс, обслуживание, валидационные прогоны и дополнительные вызовы модели.

Переносимость — еще одно возможное преимущество. В описанном исследовании навыки, разработанные одной моделью, иногда могли использоваться другой и порой работали лучше, чем навыки, созданные самой принимающей моделью. Но переносимость не была универсальной, поэтому организациям пришлось бы тестировать навыки для каждой модели, задачи и среды инструментов, а не считать успешную процедуру переносимой автоматически.

Для команд enterprise AI главный операционный вопрос — это управление. Постоянная запись сбоев агента может повысить надежность, но может также сохранять неверные выводы, чувствительную информацию или устаревшие процедуры. Сообщаемый механизм фильтрации решает проблему падения производительности, но не обязательно приватности, авторизации или безопасности. Любое промышленное внедрение потребовало бы контроля над тем, что попадает в wiki, кто может его просматривать и когда накапливаемые знания устаревают.

За чем следить дальше

Следующим сигналом станет то, опубликует ли Google Research более полные технические детали, код или более широкие оценки WikiSkill. Эти материалы помогли бы прояснить вычислительные накладные расходы фреймворка, требования к памяти, дизайн валидации и поведение при сдвиге распределения.

Разработчикам также стоит смотреть на результаты для более долго работающих агентов и менее структурированных корпоративных рабочих процессов. Текущие доказательства наиболее сильны для математических и табличных задач и слабее для документной работы с длинным контекстом. Тестирование в службах поддержки клиентов, репозиториях программного обеспечения и многопользовательских средах покажет, распространяется ли метод за пределы эпизодов бенчмарков.

Еще один вопрос — сохраняют ли постоянные навыки полезность по мере изменения инструментов, сайтов и форматов данных. Процедура, выученная для одного интерфейса, может стать вредной после обновления приложения. Поэтому метрики возраста навыка, его происхождения, частоты откатов и обнаружения устаревшей памяти будут не менее важны, чем общая точность выполнения задачи.

Позиция Creati.ai

WikiSkill примечателен не столько тем, что решает проблему непрерывного обучения, сколько тем, что предлагает дисциплинированный обходной путь для одного из самых заметных ограничений агентов. Фреймворк рассматривает опыт как инженерный актив: сохранить трассу, кратко изложить урок, предложить изменение и протестировать его перед развертыванием.

Этот подход многообещающ для команд, создающих ИИ-агентов, но сообщаемые улучшения следует воспринимать как ранние исследовательские данные. Сложная часть в продакшене будет заключаться в том, чтобы решить, каким урокам можно доверять, сколько памяти сохранять и как не допустить, чтобы агент становился все лучше в повторении устаревшей или неверной стратегии.