На прошлой неделе мы писали о том, как скармливали терабайты CI-логов LLM. Большинство вопросов на Hacker News касались не самих логов — спрашивали про агента: какие модели, как они взаимодействуют и во сколько всё это обходится.
Сейчас мы работаем на Opus 4.6 и платим меньше, чем когда всё крутилось на Sonnet 4.0.
Причина в основном в том, чего Opus не делает: 80% сбоев до него не доходят, а когда доходят — он не читает ни одной строки лога.
Архитектура выглядит так:
Пусть дешёвый агент решает, нужен ли дорогой
На прошлой неделе мы проанализировали около 4 000 CI-сбоев. 818 оказались новыми проблемами. Остальные 3 187 — это уже известная проблема, которая снова всплыла: нестабильный тест, сбой инфраструктуры, сетевой глюк, который мы уже фиксировали.
Нет смысла поднимать дорогую модель, если в 80% случаев ответ — «это дубликат». К сожалению, детектировать дубликаты детерминированно невозможно: одна и та же задача может падать по совершенно разным причинам, поэтому нужно реально смотреть в логи, чтобы понять, встречали ли вы это раньше.
Изначально мы использовали Sonnet — как баланс между ценой и качеством. Работало, но это было худшее из двух миров: всё равно дорого, и результаты хуже, чем у frontier-модели.
Мы перешли на паттерн «triager»: Haiku-агент с очень конкретной и узкой задачей. Отслеживается ли эта проблема уже или нет? Если да — стоп. Если нет — эскалация до Opus.
Детектировать дубликаты с Haiku оказалось непросто. Чтобы максимально упростить задачу, мы прикрепили сообщения об ошибках к предыдущим сбоям и дали Haiku два инструмента поиска: точное совпадение для известных фрагментов ошибок и семантический поиск (pgvector) для похожих, но не идентичных ошибок. RAG умер, а семантический поиск — вполне себе. operator does not exist bigint character varying и migration type mismatch on installation_id — разные строки, но одна и та же первопричина, и семантический поиск это видит.
Haiku-агент читает логи, ищет сообщения об ошибках, пытается найти совпадение с известными сбоями и принимает решение. При сомнениях — эскалирует. Ложноположительный результат стоит немного денег; ложноотрицательный означает, что мы пропустим что-то реальное.
4 из 5 сбоев до Opus не доходят. Совпадение у triager стоит примерно в 25 раз меньше, чем полное расследование.
Если статья понравится — приглашаю в канал AI for Devs. Каждый день публикую похожие материалы: модели, агенты, практические кейсы и новости из мира AI.
Пусть агент сам вытягивает контекст, не нужно пушить его
Несколько человек спрашивали, как мы работаем с логами на 200K+ строк. Мы не пушим их в промпт. Мы даём агенту SQL-интерфейс к ClickHouse и позволяем запрашивать то, что нужно.
Дело не только в стоимости токенов. Если передать агенту конкретный набор строк лога, вы уже сами решили, что релевантно, — ещё до того, как поняли, в чём реальная проблема. Агент цепляется за то, что вы ему дали. Если настоящая причина где-то в другом месте, вы сами усложнили её поиск. Та же история, что с «не стоит начинать дебаг со слов "я думаю, проблема в этом файле"»: вы предвзято настраиваете расследование ещё до его начала.
О SQL-настройке мы подробно писали на прошлой неделе, но вкратце: есть одна таблица с сырыми данными (github_logs, одна строка = одна строка лога) и набор материализованных представлений с пре-агрегированными данными: частота сбоев по workflow, тайминги задач, счётчики результатов. Большинство расследований начинается с материализованных представлений, чтобы сузить причину, и переходит к сырым логам, когда нужно.
Мы не говорим агенту, какую таблицу запрашивать. Вместо этого используем сами ответы, чтобы направлять его постепенно. Если запрос возвращает слишком много строк — обрезаем и предлагаем более конкретное материализованное представление. Если логи ещё не проиндексированы — указываем на GitHub CLI. Агент сам разбирается, что ему нужно, без необходимости заранее предусматривать каждый возможный путь.
Дорогие агенты планируют, дешёвые — делают работу
Opus смотрит, что упало, формулирует гипотезу и запускает суб-агентов Haiku для фактического расследования. Каждый суб-агент получает промпт от Opus: что именно искать, как искать, что вернуть. Суб-агенты ограничены одним уровнем глубины — они не могут порождать собственных суб-агентов. Неограниченный fan-out — это путь к неконтролируемым расходам.
Несколько недель назад три CI-задачи Storybook упали на одном коммите, все — на pnpm install.
Opus начал с того, что попросил суб-агента получить сообщения об ошибках из упавшего шага pnpm install. Логов в ClickHouse ещё не было, поэтому суб-агент переключился на GitHub CLI.
Промпт суб-агента #1:
Получи CI-логи для этого запуска. Верни точные сообщения об ошибках из шага pnpm install, полный вывод ошибки — особенно последние 50–100 строк.
Результат: gyp ERR! not found: make. re2@1.23.0 не смог скомпилироваться, потому что на раннере не было make.
Opus поискал в существующих инсайтах (совпадений нет), затем запросил из ClickHouse тренд сбоев за 14 дней:
Feb 23: 0.2% failure rate
Feb 24: 1.1%
Feb 25: 8.0% <- inflection point
Что-то явно изменилось 25 февраля. Opus запустил суб-агент #2:
Исследуй, что изменилось около 24–25 февраля. Частота сбоев выросла с 0.2% до 8%. Ошибка —
gyp ERR! not found: make. Запусти git log по файлу workflow и package.json за этот период.
Build-зависимости были удалены в ходе несвязанной миграции. Для той миграции — правильно, но re2 всё ещё нужен make для нативной компиляции. Opus запустил суб-агент #3 для проверки текущего состояния workflow, затем создал инсайт с описанием первопричины и фиксом.
Оркестратор не прочитал ни одной строки логов, git-истории или кода.
Несколько вещей, на которые стоит обратить внимание:
Стоимость. Haiku обрабатывает ~65% всех входных токенов, но занимает только ~36% расходов на LLM. Дорогая модель думает; дешёвая — читает. Без иерархии моделей ежедневный счёт более чем удваивается.
Opus планирует на ходу. Он начинает с гипотезы, но результаты каждого суб-агента определяют следующий шаг. В этом расследовании: получил ошибку, поискал в истории, спросил, что изменилось. Каждый раунд информировал следующий. Более трети расследований идут в несколько раундов, причём новые проблемы требуют примерно вдвое большей глубины, чем известные.
Чистота контекста. Контекст оркестратора остаётся чистым: структурированные сводки от суб-агентов, а не сырой вывод логов. Каждый суб-агент стартует с чистого листа, и его контекст удаляется по завершении. Вывод tool call накапливается быстро, а устаревший контекст из предыдущих шагов сессии ухудшает качество последующих решений.
Направленный поиск. «Верни точные сообщения об ошибках из шага pnpm install» — это совсем другой промпт, чем «проанализируй эти логи». Opus решает, что искать; Haiku находит. Соотношение input/output у Haiku — 86:1 (читает много, возвращает сфокусированные выжимки), у оркестратора — около 50:1 (синтезирует и принимает решения). Haiku поглощает данные, чтобы Opus этого не делал.
Шесть месяцев назад это было невозможно
Полгода назад мы работали на Sonnet 4.0. Он плохо справлялся с написанием корректных ClickHouse-запросов: неверные таблицы, отсутствующие фильтры, чтение избыточного количества данных. Haiku 4.0 был полезен разве что для классификации в формате «да/нет».
Сегодня Opus 4.6 умеет планировать расследования и писать точные промпты для суб-агентов. Haiku 4.5 справляется с узкими направленными задачами — потому что задачи достаточно ограничены, чтобы быструю дешёвую модель можно было успешно применять.
Переход на frontier-модель снизил расходы.
Паттерн универсален
Мы строили это под CI-логи, но паттерн подходит для всего с высоким объёмом событий: логи безопасности, IoT-телеметрия, финансовые данные. Большинство событий — шум или повторы, и дорогая модель должна видеть только те, которые таковыми не являются.
Есть четвёртый слой, о котором мы не рассказывали: переоценка. Система периодически проверяет, верны ли ранее сделанные выводы — закрывает устаревшие инсайты, отлавливает ложноположительные результаты, верифицирует, что фиксы сработали. Это тема для отдельного поста.
Мы продолжаем настраивать, где именно проходит граница суб-агента. Иногда запуск суб-агента обходится дороже, чем выполнение задачи inline, потому что накладные расходы на инициализацию превышают экономию.
Самым сложным оказалось не сделать агента умнее. Самым сложным было выстроить слои, которые останавливают его от запуска там, где этого не нужно.
Русскоязычное сообщество про AI в разработке
Друзья! Перевод этой статьи подготовила команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-агентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!