Хабр Курсы для бэкендеров
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Поток Бэкенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 11
6. Ошибки инструментов не бесплатны
Интересно, насколько в борьбе с этим может помочь плагин, который даёт модели возможность суммаризировать часть контекста. Модель делает запрос к логам, понимает, что там мусор и ничего полезного и сразу суммаризирует результат этого “хода” и продолжает уже с этими знаниями. Какое-то время использовал opencode-dynamic-context-pruning, но ничего не замерял и не добавлял инструкции убирать из контекста подобный мусор. Надо будет попробовать.
Так сам вызов плагина останется в истории, вместе с саммари. Контекст не сожмется. Только прямой /compact сожмет (ну или харнес автомат включит тогда контекста 200k+)
Смысл плагина как раз в том, чтобы дать модели самой вызывать компактизацию, причём не всей переписки, а только её части. Допустим после полезной ориентациина было 30к, а потом модель начала диагностику и наелась логов, но оказалось, что это был тупиковый путь, а контекста уже 100к. Перед тем как переходить к следующей попытке модель вызывает сама компактизацию части нижних сообщений и после этой компактизации она будет видеть изначальные 30к + столько, сколько напишет сама в суммаризации.
Надо попробовать. Но я пошел другим путем - на длинных задачах у меня диспетчер который вызывает уже разраба, затем ревьювера. В итоге у каждого контекст мал (хоть и шагов много). И после ревью тотже разраб начинает заново по найденным недочетам. В итоге суммарно контекста сильно меньше. + автоматизации повер, которые рутину (подряд вызываемые операции типа определение контекста проекта, подготовка ветки и тд - делаются через вызов js метода, чтобы зазря шаги не жечь).
Тоже использую диспетчеров, но думаю оба способа друг друга дополняют. Диспетчеру сжатие может быть и не нужно, он принимает стратегические решения и мусорный контекст ест редко, а вот модель-разработчик вполне себе может в процессе диагностики чего-то лишнего набраться. Всё конечно зависит от типа задач и композиции, но по сути выдать дополнительный инструмент “compact” тем агентам, которым он может пригодиться лишним не будет.
А что за автоматизации? У меня во всех проектах Justfile с разными часто-повторяемыми рецептами. Чтобы все проверки качества запустить, модели нужно вызвать лишь just check, который в параллель уже 50 команд запускает. На подготовку git workgree и ветки тоже свои рецепты. Но, честно говоря этого не хватает. Хочется прикрутить какой-то честный движок запуска workflow. Присматриваюсь к microsoft/conductor, но не хочется, чтобы движок сам запускал модели. Скорее, чтобы модель имела опорный механизм в виде движка и знала что дальше делать и чтобы некоторые шаги запускались автоматически после перехода процесса в новый узел выполнения. Возможно получится siemens/wfx как-то приспособить. Все сейчас пилят столько нового инструментария вокруг ИИ-агентов, что едва успеваешь за всем этим следить, не то чтобы попробовать.
Когда контекст больше 500К всё начинает тупить и по скорости и по глупости.
Поэтому, сжимаю вручную в удобный момент примерно на этом уровне. А сессии у меня бесконечные: 40 часов непрерывной работы запросто.
После сжатия приходится немного подруливать ход работы, но зато бежит быстро.
факт, даже больше 300к уже тупит нещадно.
я еще делаю /handoff сначала, а потом /compact - тогда детали не теряются (почти))
Для своей работы разработал другой подход: "RAG per WORKSPACE" и "RAG per TASK" для очень объемных задач. Сейчас использую deepseek-harness с собственными дообученными моделями, его главное преимущество (для меня) в том, что все в нем является плагином.
Я просто накидал архитектуру плагина по RAG как мне нужно и харнес сам для себя ее написал плагином. В итоге в окне чата есть выпадающий список RAG-баз.
И есть отдельная страница настройки RAG, где одна папка это один RAG, сначала сам вручную закидывал в нее документы и индексировал, затем добавил tool чтобы модель сама искала информацию кидала в папку файлами и индексировала на этапе предварительного анализа.
Текущий контекст также уходит в выбранный RAG перед сжатием и обновляется при следующем сжатии. Бывает что нужно начать новую ветку, в этом случае начинаю ее с чистого листа указывая RAG и модель работает дальше отбросив ненужный хвост так сказать.
Пункт про паузы совпал с тем, что я видела в собственных счетах: одна и та же задача обходится дороже, когда я сижу рядом и думаю над каждой правкой агента, чем когда он идет без остановок. А в моей раскладке главный поставщик мусора в контекст — не Read, а поиск без лимита по строкам, который тащит полфайла ради одного совпадения. Считали ли вы отдельно цену компакции: она же ломает кэшируемый префикс, и следующий после нее шаг тарифицируется как запись, а не как чтение из кэша?
Сейчас подсчитал - выигрыш будет шаге на 4-м уже. Контекст меньше -- соответственно каждый следующий шаг стоит дешевле и где-то с 5-го шага экономия уже превысит стоимость складывания в кэш.
Есть ньюанс - после компакции агент может забыть важное и начать читать по новой то, что уже читал до сброса. А это снова контекст раздувает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Налог на контекст: куда утекают токены