Обновить

SKILL.state в coding-агентах: меньше истории, но не всегда меньше работы

Уровень сложностиСредний
Время на прочтение37 мин
Охват и читатели9K
Всего голосов 3: ↑3 и ↓0+5
Комментарии11

Комментарии 11

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

Смотрел, просто позже написания статьи - в ней фокус был именно на input.
И Вы правы, там картина далека от приятной) Но и не ужас кромешный, чего я подспудно опасался.
Вот тут подробно по одной из серий (25 сессий): https://articles.rexarrior.online/skill-state-input-cache-output/
"Сокращение общего input сопровождается меньшей долей кешированных токенов. У Sol она падает с 89,4% в Native до 52,3% в V2; у Astra — с 85,3% до 56,5% в V3."

В общем, чтобы эти наброски превратить в новое ready-to-use ядро агента, еще работать и работать...

О ну не так все и плохо, я думал будет хуже =)
я все ваши шишки тоже собрал в своем проекте агента и уже решил по своему, так что да решение есть, но оно не столь простое, ну мне так показалось =)

А "проект агента" - он у Вас о чем? Свой харнесс (кодового агента) делаете?

Он больше по автономному управлению инфраструктурой для локальных моделей, код писать тоже может, но это скорей больше опция, чем цель, кодовых агентов как грязи, и по большей части для фронтир моделей, мой живет 24/7 с бесконечным окном в 32к, и может нормально работать с моделями начиная от Ornith 1.5 9B.

После прочтения данного пейпера сложилось впечатление (вынесенное из заголовка, собственно: 'SKILL.state: Scalable Long-Horizon Agent Skills'), что данный подход скорее как избежать переполнение контекста на "длинных дистанциях". Не даром там приводится пример со складом и 200-ми шагами его управления. Экономии токенов (особенно на коротком отрезке) никто не обещал, скорее это приятный побочный эффект.

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

Да, в первую очередь данный подход направлен на долгие (или вечные) задачи с незначительным изменением контекста (зафиксированной в памяти схемы). Адапатция к кодингу у авторов оригинальной статьи была опцией, требующей "адаптацию под домен" (цитата-перевод). Но, посколько подход все-таки обобщенный, мне стало интересно именно направление работы с кодом пощупать. В классических агентах (аля подбери мне детальку по фото авто) я такой подход уже с успехом использовал и нового тут для меня было мало.

Экономия токенов к сожалению не всегда равна экономии денег. В этой статье я рассматривал только input. Если приведенный выше разбор по прочим параметрам посмотреть, уже видно, что экономия - сомнительная.

Сейчас работаю над более точечным и более полным анализом, в частности прогнал на кусочке TB 2.1

Резульатты прогона Paper2 с различными N на Terminal Bench v2.1, 10 выбранных задач по 2 попытки каждая, модель GPT 5.6 Sol high effort
Резульатты прогона Paper2 с различными N на Terminal Bench v2.1, 10 выбранных задач по 2 попытки каждая, модель GPT 5.6 Sol high effort

Если на это посмотреть с точки зрения денег, получится что у Paper 2 N=3 (лучший среди рассмотренных) +$0,39 за прогон, или +$7,80 за двадцатку, при одинаковом результате 18/20. Несмотря на то, что Paper2 N=3 сокращает общий input на 62%, но некэшированных входных токенов тратит в 4,15 раза больше, а output — на 69% больше.


А где деньги то и скорость?

Совершенно не учитывается что уголовник токены и стоят в 10 раз дешевле и работают быстрее чем не кешированные.

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

Разные задачки - тут способ формирование контекста заточен под сокращение потребления инпута, проверялось именно это. Другие аспекты смотрелись по остаточному принципу. Время и циклы учтены - собственно, почитайте таблицы и графики. Чаще всего по этим 2 параметрам выигрывает Native, но не без исключений - у Sol встречается, что V2 оказывается быстрее.

По поводу кеша и output - вот разбор по одной из серий, уже давал ссылку выше - https://articles.rexarrior.online/skill-state-input-cache-output/

Насчет денег - вот выше есть разбор, правда, по другому немного эксперименту. По текущему не разбирал, репо открыт - хотите, сами посчитайте)

Насчет харнес - категорически не согласен. Их харнес весь такой успешный большей частью потому, что через него их подписка работает. А модели у них действительно сейчас лучшие, тут сложно спорить. Сам по себе харнес в разных рейтингах по разному ранжируется, например вот тут https://composio.dev/content/best-ai-agent-harnesses Oh My Pi в топе. Но методологию не проверял. На мой личный вкус, как минимум opencode desktop нормально обвешанный ничуть не уступает Codex Desktop, а консольный вариант у него вообще лучше и удобнее, чем у codex и claude вместе взятых. Но это субъективно)

Вообще харнес - сложная тема для обсуждения в коментариях. Слишком много параметров для сравнения: удобство, скорость работы семантического ядра, качество работы семантического ядра, поддерживаемые фичи, расширяемость, etc. Мне вообще семантическое ядро больше у Roo Code нравится, мы с коллегами даже делали эксперименты по переносу этого семантического ядра на рельсы langraph - летает)

Ну тут проблема то в том что кешед инпут и оутпут в 10 раз дешевле и у антропик и у кодекса и остальных наверно тоже, с учётом того что натив ещё и быстрее в итоге мы проигрываем и в деньгах и во времени

"...мы проигрываем и в деньгах и во времени" на этом классе задач и с этой схемой контекста)
Такой вывод меня тоже вполне устраивает - найти под эту схему контекста задачу где она идеально подойдет несложно. И это сделали сами авторы SKILL.state. Я же проверял ее на общих задачах кодинга, причем не сильно длинных

Сейчас работаю в том числе над проблемой кеша , там есть потенциал чтобы улучшить кешхиты. Отдельно надо работать с output. К сожалению, с нахрапа что-то качественно улучшить получается редко, нужна планомерная работа над вопросом.

Да даже если не получится улучшить, для меня эта серия экспериментов - отличный повод лучше разобраться в вариантах памяти для агентов, этого уже достаточно

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации