Haiku 5.5 дешевле на 75%: что делать с агентами в проде

AWS добавила Claude Haiku 5.5 в Amazon Bedrock.

По данным Anthropic, это самая быстрая и эффективная модель семейства 5.5.

Её сделали для субагентов и массовых задач, где важна цена, и для большинства задач она стоит примерно на 75% дешевле Haiku 4.5.

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

Остаются два вопроса: какие данные агент вправе читать и кто отвечает за исправление, которое он предлагает.

Субагент - узкий исполнитель внутри большой системы.

Один агент читает логи, другой выполняет запросы к системным представлениям базы, третий сверяет результат с регламентом.

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

Снижение цены примерно на 75% по сравнению с Haiku 4.5 меняет арифметику: схему, которую раньше считали слишком дорогой для постоянной работы, можно пересчитать заново. Bedrock добавляет к модели условия, которые проверяет служба безопасности.

Данные остаются внутри инфраструктуры AWS с региональной привязкой, а доступ регулируется через IAM, теми же ролями, которыми команда уже пользуется.

Если компания не готова отправлять внутренние данные во внешний API, пилот без этих условий не стартует.

Cornerstone OnDemand обслуживает 140 миллионов пользователей в 186 странах.

Раньше команда DataOps тратила до 45 минут на один инцидент с базой: вручную опрашивала системные представления и сопоставляла результаты.

Теперь работает мультиагентная система Orion AI на Amazon Bedrock и Strands Agents, открытом фреймворке AWS для оркестрации агентов.

Специализированные агенты разбирают инцидент параллельно.

Компания заявляет сокращение времени диагностики на 78%.

Если взять потолок в 45 минут, получится около десяти минут вместо трёх четвертей часа.

Это наш расчёт по заявленным цифрам, независимого измерения нет, поэтому применять его стоит осторожно.

Механика простая: оркестратор делит задачу, субагенты выполняют узкие проверки, результат собирается в один вывод.

Дешёвая быстрая модель в роли субагента делает такую схему экономически разумной.

AWS DevOps Agent круглосуточно разбирает инциденты по метрикам, логам и топологии приложения.

На выходе он выдаёт анализ первопричины (RCA) и рекомендуемые действия.

Дежурный инженер среди ночи получает готовый диагноз, но исправление делает вручную.

Новая статья AWS описывает следующий шаг: автоматизировать исправление после расследования агента. Здесь появляется ответственность.

Диагноз ничего не ломает, а исправление меняет прод.

Рабочая схема требует трёх вещей: - ограниченный набор разрешённых действий; - журнал, из которого видно, что агент сделал и почему; - точка, где человек подтверждает рискованный шаг.

Без них автоматическое исправление становится источником новых инцидентов.

Мы в KT.Team закладываем такие контуры на этапе проектирования интеграции, до первой аварии.

RAG (retrieval augmented generation) - схема, где модель отвечает по найденным документам компании из SharePoint, Google Drive, Confluence. В этих системах у каждого документа свой список прав.

Если ассистент отвечает по материалам, которые сотрудник не вправе видеть, это утечка, даже когда формулировка ответа безобидна. Amazon Quick вместе с Amazon Bedrock Knowledge Bases проверяет права в момент запроса: сверяет списки контроля доступа (ACL) в источнике и не копирует их заранее в индекс. Разница существенная.

Скопированные права устаревают в тот же день, когда сотрудника переводят в другой отдел.

Проверка в момент запроса видит актуальное состояние.

Для российских компаний тот же принцип применим к 1С,

Битрикс и корпоративным базам знаний: слой доступа определяет, можно ли вообще запускать RAG на данных, поэтому его строят до выбора модели.

AWS отдельно описывает, как сократить разрыв между разговорами об ИИ и созданием решений.

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

Им нужны инструменты, структурированная поддержка и право на ошибку.

Это совпадает с нашим опытом: рабочие агенты появляются там, где владелец процесса участвует в сборке решения вместе с инженерами.