Эксплуатация: измерять деградацию, а не надеяться

Всё предыдущее было про то, как собрать контекст. Эта часть — про то, как узнать, что он перестал работать, и узнать об этом раньше пользователя. Ishita Daga (Tesla, «Enterprise Agents Have a Structure Problem») формулирует диагноз в одну фразу: многие команды не занимаются eval вообще, поэтому и не знают, что агент деградирует. Lance Martin (LangChain) добавляет условия входа: трейсинг токенов и evaluation — «table stakes» до любой оптимизации контекста. Без первого ты не считаешь, без второго сжатие слепое: ты не знаешь, испортил поведение или нет.

Эксплуатация: измерять деградацию, а не надеяться

Как вообще ловить деградацию

Главная особенность агентных отказов в том, что они поздние. Правило, которое держалось на пятом ходу, тихо перестаёт держаться на пятнадцатом, и на коротком тесте это не воспроизводится.

Arize («How we solved Context Management in Agents») сделали под это отдельный вид evals: подгружают 10 ходов истории и тестируют 11-й. Смысл — сделать поздние отказы воспроизводимыми: баги контекста становятся тестируемыми, не нужно ждать жалобы пользователя. Они прямо называют это полезным сигналом того, как работает твоя стратегия управления контекстом. Это единственный найденный способ систематически ловить именно поздние отказы — и при этом самый дешёвый в реализации.

Оговорка от них же: метрик «качества контекста» у Arize всё равно нет, evals используются как прокси, а выбор того, что остаётся в контексте, после года работы — по-прежнему эвристика «первые 100, последние 100». Готовой методики нет ни у кого.

Второй детектор — расхождение между прогонами. Diane Lin (Datadog, «Why Your Agent Disagrees With Itself») взяла реальные security-алерты и прогнала каждый трижды: 93 алерта × 3 прогона. Без принятого решения в контексте около 25% меняли вердикт между прогонами. С эпизодической памятью примерно 15% стали консистентными, а около 10% продолжали «мигать» — либо нет похожего прецедента, либо расхождение сохраняется даже при наличии ссылки. Эти 10% уходят человеку.

Инструмент не требует ни разметки, ни эксперта, ни эталона. Всё, что «мигает», — либо дефект контекста, либо честно неопределённый случай, и оба ответа полезны.

Третий слой — дрейф траектории. Carly Richmond (Elastic) смотрит трассы через OpenLIT: видно каждый вызов инструмента — какие, в каком порядке, сколько заняли. Изменилось число вызовов или их порядок — изменится и результат. Её конкретный провал: подмена модели на FunctionGemma превратила выдачу маршрута в «я не могу этого сделать». Вывод — регрессионный набор эталонных пользовательских входов обязателен и для мажорных, и для минорных апгрейдов модели.

Добавь два дешёвых обязательных теста: пройти сессию хотя бы раз за реальную точку компакции и проверить, держится ли правило на следующем ходу (об этом — вторая часть серии), и сверять самоотчёт агента с tool-call history — Zach Blumenfeld (Neo4j) объективной проверкой считает только историю вызовов.

Петля самоулучшения: цифры и потолок

Что произошло: автоматическая оптимизация промпта упёрлась в плато на 80%

• Кто: Annabell Schäfer, Langfuse (доклад «Stop Burning Tokens», AI Engineer).
• Что делали: датасеты: 200 примеров для fit, 100 для validate и 300 для test; агент — простой промпт на дешёвой модели; оптимизатор — Claude Code с prompting guide и task.md. Цикл: прогон, поштучный скоринг, анализ кластеров ошибок на fit, гипотеза правки под самую крупную категорию, перепрогон, принять правку только если улучшился и validate. Ссылку на test-датасет оптимизатору не давали до самого конца.
• Результат: baseline 68%, на первой же итерации 78% (на 10 процентных пунктов выше), пик 83% на 3–4-й итерации, плато около 80%. На неприкосновенном тесте из 300 примеров — 80,2%, то есть улучшение обобщилось. Стоп-правило задано заранее: 15 итераций или 92% accuracy.
• Вывод: почти вся выгода пришла на первую итерацию. 92% не достигнуто и достигнуто не будет. Дальнейшие итерации жгут токены впустую — отсюда название доклада.

Важна здесь форма кривой. Разрыв между стоп-правилом (92%) и реальным плато (~80%) — это потолок, заданный шумом самой разметки.

Откуда берётся шум. Рынок любит оценщики вида correctness, helpfulness и hallucination по шкале 0–1 или 1–5, но чтобы это работало, надо определить каждое значение шкалы для каждого контекста — чего почти никто не делает. Отсюда низкий сигнал и нестабильность между прогонами: LLM-as-a-judge недетерминирован. Langfuse переходят на бинарные доменные проверки: «основан ли ответ на retrieved context» (проверяемо), «имя бренда написано правильно и не переведено на испанский», «к какому из пяти известных failure mode относится случай». Такие критерии нельзя купить — их вытаскивают из доменных экспертов, прогоняя сэмплы и спрашивая «почему здесь так, а там иначе».

Но и при бинарных критериях остаётся слой примеров, где сама разметка спорна: два эксперта расходятся, а «правильный» ответ зависит от прочтения. Остаток неустраним — и оптимизатор, продолжая крутиться, начинает подгонять промпт под шум вместо задачи. Так пик 83% и сползает к 80%. Тот же остаток виден у Datadog: 10% «мигающих» алертов не чинят, их маршрутизируют человеку. Вывод: оцени свой потолок по доле спорных примеров и ставь стоп-правило рядом с ним, а не рядом со 100%.

Экономика: где реально сгорают деньги

KV-кэш — самый быстрый рычаг. Разбор Manus и Manifold в пересказе Marina Wyss: провайдеры кешируют key-value представления токенов, и если префикс контекста между вызовами не менялся, обрабатываются только новые токены на конце. Для Claude Sonnet это 30 центов за миллион кешированных входных токенов против $3 за миллион некешированных — разница в 10 раз. Агент делает 30–40 API-вызовов на задачу, так что множитель применяется ко всему прогону. Отсюда раскладка: стабильное (system prompt, определения tools) — наверх, динамическое (история, шаг, состояние) — вниз. Любая правка ранней части инвалидирует кеш.

Прямое следствие — не добавляй и не удаляй инструменты по ходу разговора: это ломает кеш. Manus держат все определения в стабильном префиксе и помечают часть недоступной для текущей фазы (tool masking). И неочевидная строка в счёте: компакция молча убивает prompt cache — без ошибки, просто счёт выше.

На что уходят токены. /context показывает разбивку: system prompt, tools, memory-файлы, MCP tools, описания skills, сообщения (обычно крупнейшая статья), свободное место и буфер под авто-компакцию. Конкретика: сорок с лишним определений tools — это около 10 000 токенов ещё до первого хода. Уже на трёх подключённых MCP-серверах расход «весьма существенный», а на 20–40 съедает огромную долю окна (Jono Catliff). Системный оверхед модели — отдельная статья: одно и то же «Hey» съело больше трети окна на Haiku против 9% на Opus. Дело не только в деньгах: квантованная Llama 3.1 8B провалила бенчмарк GeoEngine с 46 инструментами и отработала нормально с 19, хотя контекст спокойно помещался в окно.

Стоимость холистических запросов. Запрос, который обязан охватить картину целиком, дёшево не бывает. У ZS Associates после перестройки один прогон — 50 с лишним ходов и «изрядное количество токенов», зато результат за 20–30 минут против 3–4 недель работы аналитика. Суммы они не назвали, и это честно: метрика тут — цена результата, а не цена вызова. Sarah Sachs (Notion, «Token Town») о том же: их поставщик веб-поиска не выигрывал ни по латентности вызова, ни по цене — преимущество было видно только на целых поисковых траекториях.

Что ломает юнит-экономику. Оттуда же два сценария. Первый: reasoning-модель обновили, цена за токен та же, но она тратит втрое больше выходных токенов. Второй: новая модель на 40% дороже предшественника, которого депрекейтят через 4 месяца. Отсюда — маршрутизация трафика по типам задач (триаж почтового ящика на Opus — «обдираловка и клиента, и себя») и трезвость насчёт того, что для целых классов работы LLM не нужен вовсе: чтобы превратить CSV в PDF или выполнить детерминированный SQL. Ориентир по бюджету на фоновых агентов (LatentSpace): $1 000 – $5 000 на инженера в месяц. И правило JetBrains: токен-бюджет и максимум итераций задаются до запуска петли, а размытая цель («сделай лучше») означает бесконечную петлю.

Скорость устаревания: что фиксировать, а что делать сменным

Dan Farrelly (CTO Inngest, «Your agent architecture has a half-life of 6 months») режет систему на три слоя с разным периодом полураспада: execution (поток, состояние, durability, ретраи) живёт годы; context (модели, промпты, инструменты, память) меняется чаще всего — промпты живут недели, иногда одну, модели — месяцы; compute — руки: сэндбоксы, рантаймы, браузеры. Тезис: если слои связаны, короткий период полураспада одного тянет вниз остальные — технический долг под другим именем. Симптомы: оркестрация закопана внутри фреймворка, состояние держится в сэндбоксе, ретраи перепутаны с логикой промптов.

Граница получается такая. Фиксировать стоит слой исполнения: как устроен поток, где живёт состояние, как считаются ретраи, как всё трассируется. Сменным закладывать всё, что относится к знанию: модель, промпт, набор инструментов, стратегию памяти. Sarah Sachs формулирует это со стороны продукта — строить под мультимодельность, воспринимая харнесс как слой интероперабельности, и не покупать скидку ценой опциональности. Технически это трудно («тяжело убить кеш и переключить модель посреди транскрипта»).

Состояние держи вне рантайма. Sandbox как хранилище состояния — удобный приём внутри сессии и антипаттерн с точки зрения долговечности: срок жизни песочницы измеряется прогоном, срок жизни системы — годами. Cognition строит наоборот и называет это «отделить мозг от машины»: мозг в control plane, песочница — только руки, дёргаемые tool calls. На машину кладут секреты в объёме прав пользователя. Альтернатива — агент целиком «в коробке», где состояние локализовано, но туда же попадают все секреты.

Масштаб, ради которого всё это: фоновый агент работает минуты и часы, делает порядка 200 вызовов инструментов, и хотя бы один отказ практически гарантирован. Без сквозного трейса всей сессии — не только LLM-вызовов, но и ошибок БД, проблем прав, триггеров — такого агента невозможно даже отладить. Петля у Inngest: cron-хелсчек раз в 30 минут тянет метрики и спрашивает модель, всё ли здорово. При проблеме поднимается triage-агент. Раз в неделю ревьюер читает историю прогонов и оценивает сам триаж. Скоринг — outcome-based: метрика это факт (открыли ли PR по итогу триажа, сохранили ли отчёт агента), посчитанный после прогона по полному трейсу.

Организационное дополнение от Ben AI: у контекстного слоя должен быть один ответственный владелец, иначе слой деградирует, и нужен регулярный ручной проход по дубликатам и противоречиям. Ian Gotts даёт метафору: контекст — топливо агента, а в Формуле-1 больше всего регламентируют и измеряют именно топливо, а не двигатель.

Отрезвляющий контекст — это аргумент за измерение

Две цифры, которые сейчас цитируют все: по данным MIT NANDA («GenAI Divide», 2025) 95% корпоративных ИИ-пилотов не дают измеримого эффекта на P&L, а Gartner прогнозирует отмену 40% agentic-AI проектов к 2027 году. Методология в докладах не разбирается, так что это ориентир, а не закон.

Важно, какой диагноз идёт следом. MIT указывает не на модели: системы не удерживают обратную связь, не адаптируются к контексту, не улучшаются со временем. За цифрой 95% стоит незамкнутая петля обратной связи, и модели здесь ни при чём. Ровно то, о чём говорит Ishita Daga: eval нет — значит, и деградацию никто не видит.

Обратный полюс держи рядом. Cognition опубликовала внутренние цифры: доля коммитов Devin в их репозиториях выросла с 16% в январе до 80% в марте, число смерженных PR — в 7 раз за 2–3 месяца при росте штата примерно на 10%. И тут же их измеренный предел: вайб-кодинг с автомержем и без code review держит кодовую базу около 2 недель, дальше её проще выбросить. Разница между 95% провалов и 80% коммитов в том, что во втором случае есть число, которое кто-то смотрит. Модели у всех одни.

Что с этим делать

Заведи long-session eval раньше, чем расширишь функциональность. Подгрузи 10 ходов реальной истории и тестируй 11-й (Arize). Единственный способ сделать поздние отказы воспроизводимыми, и он не требует инфраструктуры.

Прогоняй один и тот же вход трижды и смотри на расхождение. У Datadog так нашлись 25% «мигающих» вердиктов без разметки и экспертов. Остаток в 10% маршрутизируется человеку. Стабильно неопределённые случаи — не баг, а очередь на ручную проверку.

Ставь стоп-правило по реальному потолку. Langfuse: baseline 68%, первая итерация 78%, пик 83%, плато 80%, стоп 15 итераций или 92%. Почти вся выгода в первом прогоне, дальше оптимизатор подгоняется под шум разметки.

Проверь раскладку контекста под KV-кэш сегодня. Стабильный префикс наверх, динамика вниз, инструменты не добавлять и не удалять на лету (маскировать). 30¢ против $3 за миллион при 30–40 вызовах на задачу — самая быстрая экономия.

Разведи слои по сроку жизни. Execution фиксируй и владей им сам; модель, промпт и набор инструментов делай сменными; состояние выноси из песочницы в control plane. Промпты живут недели, execution — годы (Inngest).

Замкни петлю обратной связи, иначе ты в тех самых 95%. Лог событий «это определение неверно» (Tesla), еженедельный ревьюер поверх прогонов (Inngest), outcome-based скоринг вместо лайков, один ответственный владелец контекстного слоя (Ben AI).

Чек-лист и порядок действий

Если свести всю серию к одному тезису: контекст — это то, что вы решили положить в окно. Всё остальное — следствия. Деградация начинается уже на трети окна. Лишний инструмент вредит сильнее лишней тысячи токенов. Компакция экономит место и молча забирает правила. Retrieval решает большинство задач и не решает целый класс по конструкции.

Ниже — порядок, в котором это внедряют, и чек-лист для проверки того, что уже работает.

Порядок внедрения

Не пытайтесь закрыть всё сразу: первые два шага дают больше, чем остальные вместе.

Шаг 1 — Измерь то, что есть (полдня)

• Открой пустую сессию и посмотри разбивку окна до первого сообщения. Системный промпт, инструменты, MCP, файлы правил, skills.
• Если занято больше трети, проблема в конфигурации.
• Посчитай «шагов до деградации»: на каком ходу агент начинает вызывать бессмысленные инструменты.

Шаг 2 — Убери лишнее (1–2 дня)

• Отключи MCP-серверы, которыми не пользуешься: вред от числа инструментов начинается при свободном окне.
• Вынеси знание из файла правил в skills: сокращение файла даёт единицы процентов, перенос — десятки.
• Читай файлы с диска вместо вставки в чат.

Шаг 3 — Возьми компакцию под контроль (1 день)

• Поставь свой порог вместо умолчания, режь на границе хода.
• Опиши схему сводки: что сохранять обязательно (решения, без сырых входов).
• ПРОВЕРЬ на реальной сессии, переживают ли твои правила компакцию. Источники об этом спорят — значит, у тебя это открытый вопрос.

Шаг 4 — Подключи retrieval (неделя)

• Подгружай по требованию вместо загрузки заранее.
• Сократи набор инструментов до тех, что реально используются.
• Помни про класс задач, который retrieval не берёт: холистические вопросы вида «чего у нас НЕ произошло».

Шаг 5 — Память и структура (по необходимости)

• Память заводи под измеренную нестабильность решений.
• Граф и онтологию — когда markdown перестал справляться, начиная с десятка узлов и без попытки сразу построить полную карту предметной области.

Шаг 6 — Эксплуатация (постоянно)

• Long-session eval: 10 ходов истории, проверяем 11-й.
• Один вход трижды: расхождение между прогонами — детектор проблем.
• Разложи контекст под KV-кэш: стабильное вверх, динамика вниз.

Чек-лист: контекст в проекте

• Знаю, сколько токенов занято до первого сообщения
• Утилизация рабочего окна держится ниже 40%
• Набор инструментов ревизован по количеству
• Знание вынесено в skills; в корневом файле правил — навигация
• Skills написаны руками (сгенерированные моделью вредят)
• Файлы читаются с диска, без вставки в чат
• Стабильные инструкции вверху окна, актуальное состояние внизу
• Результаты фаз сохраняются в артефакты, а не живут в истории

Чек-лист: контекст в системе

• Порог компакции задан явно, а не оставлен по умолчанию
• Схема сводки описана: что сохраняем обязательно
• Проверено на практике, что правила переживают компакцию
• Последние 5–10 ходов остаются дословными
• Retrieval подгружает по требованию; индекс без дублей
• Понятно, какие запросы retrieval не закрывает в принципе
• Память заведена под измеренную проблему
• Суб-агенты возвращают результат, а не суждение
• Состояние хранится вне рантайма
• Есть long-session eval и мониторинг расхождения прогонов

Пять правил, которые стоит запомнить

1. Контекст — это бюджет. Больше положено не значит лучше работает: деградация начинается задолго до предела окна.
2. Считай инструменты, а не только токены. Сорок шесть инструментов проваливают задачу, которую девятнадцать решают при том же окне.
3. Проверяй гарантии на практике. Обещание «правила сохраняются при компакции» стоит одного теста и не стоит ни одного предположения.
4. Один агент владеет рассуждением. Суб-агенты экономят контекст, но каждая передача теряет смысл: результат бывает связным по форме и бессвязным по сути.
5. Измеряй деградацию, иначе её измерят пользователи. Прогон одного входа несколько раз ловит нестабильность дешевле, чем разметка и эксперты.

Что дальше

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

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