Переход на более мощную и дорогую модель обычно означает рост расходов. Команда, которая анализирует CI-сбои с помощью ИИ-агентов, получила обратный результат: замена Claude Sonnet 4.0 на Opus 4.6 снизила счёт. Причина не в скидках и не в сжатии промптов — в архитектуре, при которой дорогая модель просто реже включается в работу.
За неделю система обработала около 4 000 CI-сбоев. 3 187 из них оказались повторами уже известных проблем: нестабильные тесты, сетевые сбои, инфраструктурные глюки, которые команда уже видела. Поднимать дорогую модель ради ответа «это дубликат» нет смысла. Но детектировать дубликаты детерминированно нельзя: одна и та же задача может падать по разным причинам, поэтому нужно реально смотреть в логи.
| Модель | Доля входных токенов | Доля расходов на ИИ | Соотношение input/output | Роль |
|---|---|---|---|---|
| Haiku 4.5 | ~65% | ~36% | 86:1 | Чтение логов, поиск, суб-агенты |
| Opus 4.6 | ~35% | ~64% | ~50:1 | Планирование, гипотезы, оркестрация |
Решение — паттерн «триажёра». Haiku-агент с узкой задачей проверяет, отслеживается ли проблема уже. Для этого у него два инструмента: точное совпадение по известным фрагментам ошибок и семантический поиск через pgvector. Последнее принципиально: строки «operator does not exist bigint character varying» и «migration type mismatch on installation_id» текстуально разные, но семантически указывают на одну первопричину. Семантический поиск это видит, точное совпадение — нет. Если Haiku сомневается — эскалирует. Ложноположительный результат стоит немного денег; ложноотрицательный означает пропущенный реальный инцидент. В итоге 4 из 5 сбоев до Opus не доходят, а совпадение у триажёра обходится примерно в 25 раз дешевле полного расследования.
Haiku-агент-«триажёр» отсеивает дубликаты с помощью точного и семантического поиска (pgvector), стоя в ~25 раз дешевле полного расследования.
Когда сбой всё же доходит до Opus 4.6, тот не читает логи напрямую. Агент получает SQL-интерфейс к ClickHouse и сам решает, что запрашивать. Есть таблица с сырыми данными (одна строка лога — одна строка таблицы) и набор материализованных представлений с пре-агрегированными метриками: частота сбоев по workflow, тайминги задач, счётчики результатов. Большинство расследований начинается с агрегатов, чтобы сузить причину, и переходит к сырым логам только при необходимости. Если агент пушит в промпт конкретный набор строк заранее, он сам решает, что релевантно, — ещё до того, как понял реальную проблему. Это предвзято настраивает расследование.
Opus формулирует гипотезу и запускает суб-агентов Haiku для фактического чтения данных. Каждый суб-агент получает точный промпт: что искать, как искать, что вернуть. Суб-агенты ограничены одним уровнем глубины — они не порождают собственных суб-агентов. Неограниченный fan-out ведёт к неконтролируемым расходам. Контекст оркестратора остаётся чистым: он получает структурированные сводки, а не сырой вывод логов. Контекст каждого суб-агента удаляется по завершении — устаревший контекст из предыдущих шагов ухудшает качество последующих решений.
Пример из практики: три CI-задачи Storybook упали на одном коммите при pnpm install. Opus запросил через суб-агента точные сообщения об ошибках — получил «gyp ERR! not found: make», re2 не смог скомпилироваться из-за отсутствия make на раннере. Затем запросил тренд сбоев за 14 дней из ClickHouse и увидел перегиб 25 февраля: частота выросла с 0,2% до 8%. Суб-агент #2 проверил git log по файлу workflow и package.json за этот период — оказалось, build-зависимости удалили в ходе несвязанной миграции. Opus не прочитал ни одной строки логов, git-истории или кода напрямую.
Цифры по токенам подтверждают логику: Haiku обрабатывает около 65% всех входных токенов, но занимает лишь ~36% расходов на ИИ. Соотношение input/output у Haiku — 86:1 (читает много, возвращает сфокусированные выжимки), у оркестратора — около 50:1 (синтезирует и принимает решения). Без иерархии моделей ежедневный счёт, по оценке команды, более чем удваивается.
Шесть месяцев назад такая архитектура не работала бы: Sonnet 4.0 плохо справлялся с написанием корректных ClickHouse-запросов, а Haiku 4.0 годился разве что для классификации «да/нет». Сегодня Opus 4.6 умеет планировать расследования и писать точные промпты для суб-агентов, а Haiku 4.5 справляется с узкими направленными задачами именно потому, что задачи достаточно ограничены. Паттерн не специфичен для CI: та же логика применима к логам безопасности, IoT-телеметрии, финансовым данным — везде, где большинство событий являются шумом или повторами и дорогая модель должна видеть только исключения.
