Сгенерировать аудио

Когда prefill и decode работают на одном GPU, длинные запросы останавливают генерацию токенов для всех параллельных обращений. Disaggregated Prefill and Decode (DPD) устраняет это влияние, разделяя каждую фазу между отдельными пулами GPU, соединёнными через Elastic Fabric Adapter (EFA) с Remote Direct Memory Access (RDMA). Инференс large language model (LLM) состоит из двух принципиально разных фаз. Prefill вычислительно ограничен: он обрабатывает весь входной prompt параллельно и формирует начальный key-value (KV) cache. Decode ограничен пропускной способностью памяти: он генерирует по одному токену за раз и требует значительной bandwidth к весам модели и растущему KV cache. Разделяя эти фазы на специализированные движки, можно задавать разные стратегии параллелизма для каждой из них. Такое разделение позволяет независимо настраивать time to first token (TTFT) и inter-token latency (ITL), надёжнее контролировать tail latency по сравнению с chunked prefill tuning и не допускать, чтобы длинные prefills блокировали текущие decode-запросы. vLLM повышает эффективность на одном узле за счёт continuous batching и PagedAttention. Однако организациям, которые разворачивают систему в масштабе, всё ещё приходится решать задачи оркестрации многонодовых деплоев и оптимизации routing.

В этой статье показано, как реализовать DPD с vLLM на Amazon SageMaker HyperPod с помощью HyperPod Inference Operator.

Когда использовать disaggregated inference

Разделение prefill и decode даёт наибольший эффект в потоковых нагрузках с длинным контекстом и высокой конкуренцией: чат-ассистентах, agentic pipelines, endpoints для анализа документов и Retrieval Augmented Generation (RAG) с крупными retrieved contexts. В таких сценариях один длинный prompt на совместно используемом GPU останавливает in-flight decode для всех остальных запросов, вызывая всплески per-token latency, которых DPD избегает по своей конструкции.

Рассмотрите DPD, если в вашей нагрузке есть:

• входные prompts, которые регулярно превышают 4,096 токенов;
• несколько параллельных пользователей или запросов;
• потоковые ответы, где важна стабильная доставка токенов;
• смешанный трафик с длинными и короткими prompts.

Совместное размещение prefill и decode проще, когда конкуренция за GPU не является проблемой: для batch или offline workload, оптимизирующих TTFT, для низкоконкурентных развёртываний или для трафика только с короткими prompts. Ниже порога routing фиксированная стоимость переноса KV cache через EFA RDMA перевешивает выгоду от изоляции decode. DPD router отправляет такие запросы напрямую в decoder. В результате один endpoint автоматически обслуживает смешанный длинный и короткий трафик без ручной логики routing.

DPD требует как минимум один prefill node и один decode node с RDMA-совместимой EFA-сетью. Поддерживаемые типы инстансов см. в разделе Deploy a DPD model endpoint to your HyperPod cluster.

Архитектура

Реализация DPD в HyperPod построена на router из vLLM Production Stack, а LMCache предоставляет слой переноса KV cache поверх NIXL и EFA. Развёртывание состоит из трёх компонентов плюс транспортного стека.

Интеллектуальный router

Router — это control plane. Он токенизирует каждый prompt и применяет настраиваемый порог по количеству токенов, чтобы определить, пойдёт ли запрос по disaggregated path или будет обработан end-to-end на decoder. Длинные prompts проходят через prefiller, а затем через decoder. Короткие prompts обходят prefiller, избегая cross-GPU KV transfer, который не окупается. Для disaggregated запросов router направляет prefiller на вычисление и отправку KV cache в decoder, а затем пересылает запрос в этот decoder для генерации. Он также поддерживает стратегии routing для каждого prefiller (prefixaware, kvaware, session, roundrobin) через intelligentRoutingSpec.routingStrategy, чтобы максимизировать cache locality между репликами.

Pod prefiller

Prefiller — это worker vLLM с LMCache в роли KV connector через LMCacheConnectorV1. Он вычисляет KV cache для длинных prompts и отправляет его в выбранный decoder через PD sender backend LMCache layer-by-layer, перекрывая вычисления и передачу, чтобы GPU не простаивали. LMCache также даёт каждому prefiller L1 CPU cache. Когда префикс повторяется (system prompts, multi-turn history, retrieval contexts), данные берутся из CPU memory без повторного вычисления на GPU. Это даёт заметный выигрыш по TTFT. Активация DPD на InferenceEndpointConfig автоматически разворачивает и connector, и cache.

Pod decoder

Decoder — это worker vLLM с LMCache в роли receiver. Он резервирует GPU memory (PD buffer, размер которого задаётся PD_BUFFER_SIZE) для входящих KV transfers. Он запускает полные CUDA graphs для decode kernel и начинает генерацию сразу после завершения передачи. Поскольку он никогда не выполняет prefill, decode latency остаётся стабильной под нагрузкой, а добавление длинного запроса не нарушает поток уже идущих токенов.

Передача KV cache

Передача KV cache использует четырёхуровневый стек (LMCache PD → NIXL → libfabric → EFA), который HyperPod собирает end-to-end. PD backend LMCache управляет put на стороне prefiller и retrieval на стороне decoder. NIXL предоставляет унифицированную абстракцию памяти для GPU, CPU и удалённых peers и выбирает нужную RDMA-операцию. Provider libfabric открывает EFA как kernel-bypass, GPU-Direct RDMA, убирая host CPU из data path. Это делает стоимость передачи незначительной по сравнению с вычислением prefill: на ml.p5.48xlarge с 3,200 Gbps EFA передача 8,000 токенов для Llama 3.3 70B занимает несколько миллисекунд. HyperPod поставляет этот стек прединтегрированным, поэтому вы выбираете worker image с поддержкой DPD, а operator на каждом pod настраивает connector, NIXL и EFA.

Обзор развёртывания

Disaggregated Prefill and Decode (DPD) — это функция, реализованная в HyperPod Inference Operator. В этом разделе описаны prerequisites, установка inference operator и развёртывание inference endpoint, использующего DPD для эффективного обслуживания модели Llama 70B.

Prerequisites и установка HyperPod Inference Operator

Убедитесь, что у вас есть AWS Command Line Interface (AWS CLI), доступ kubectl к вашему кластеру HyperPod, токен HuggingFace и достаточная service quota. Настройте локальную конфигурацию kubectl для подключения к кластеру HyperPod. Подробнее см. Disaggregated Prefill and Decode for HyperPod inference.

DPD требует HyperPod Inference Operator версии 3.2 или новее. На новых HyperPod EKS-кластерах operator устанавливается по умолчанию. Инструкции по установке, настройке и обновлению см. в материале Unlock efficient model deployment: simplified Inference Operator setup on Amazon SageMaker HyperPod.

Проверьте версию operator, выполнив:

kubectl get deployment hyperpod-inference-operator-controller-manager \
 -n hyperpod-inference-system \
 -o jsonpath='{.spec.template.spec.containers[?(@.name=="manager")].image}{"\n"}'

Вывод — это полный reference контейнерного image. Тег в конце кодирует версию, например:

XXXXXXXXXXX.dkr.ecr.us-east-2.amazonaws.com/hyperpod-inference-operator:v3.2

Если версия operator неактуальна, обновите её перед продолжением, следуя инструкциям по обновлению в HyperPod Inference Operator Release Notes.

Развёртывание DPD model endpoint в кластере HyperPod

В примере мы разворачиваем модель Meta Llama 3.3 70B на двух инстансах ml.p5.48xlarge. Перед продолжением убедитесь, что инстансы доступны в instance group внутри кластера HyperPod. Для DPD inference deployments выбирайте типы инстансов, поддерживающие и NVLink, и EFA. EFA должна поддерживать RDMA в режиме read и write. Это включает семейства P5 и P6 в AWS. Обратите внимание, что инстансы должны находиться в одной Availability Zone (AZ) для высокоскоростной EFA-связи. Хотя семейства G6, G6e и G7e тоже поддерживают EFA с RDMA read/write, производительность на многопроцессорных GPU-инстансах ограничивается связью GPU-to-GPU через PCIe.

Worker image для inference deployment должен включать vLLM, LMCache, NVIDIA NIXL и EFA libfabric provider. На момент публикации поддерживаются два варианта image:

• Open source LMCache: lmcache/vllm-openai v0.4.3.
• SageMaker Deep Learning Container (DLC): vllm:server-hyperpod-cuda-v1.1.

Расположение checkpoint модели

HyperPod Inference Operator поддерживает широкий набор источников загрузки checkpoint, включая бакеты Amazon Simple Storage Service (Amazon S3), файловые системы Amazon FSx, прямое получение из HuggingFace и instance NVMe storage. В этой статье checkpoint модели загружается из бакета Amazon S3.

Убедитесь, что вы загрузили нужный checkpoint в S3 bucket в том же Region, что и кластер HyperPod. Если вы этого ещё не сделали, задайте имя bucket и токен HuggingFace, затем скачайте Meta Llama 3.3 70B Instruct из HuggingFace и синхронизируйте его с Amazon S3. Для высокоскоростной передачи в Amazon S3 рекомендуется выполнять это с экземпляра Amazon Elastic Compute Cloud (Amazon EC2).

export MODEL_BUCKET=<YOUR_BUCKET>
export MODEL_PREFIX=Llama-3.3-70B-Instruct
export AWS_REGION=<CLUSTER_REGION>
export HF_TOKEN=<YOUR_HUGGINGFACE_TOKEN>
pip install -U "huggingface_hub[cli]" "huggingface_hub[hf-transfer]"
HF_HUB_ENABLE_HF_TRANSFER=1 hf download meta-llama/Llama-3.3-70B-Instruct \
 --local-dir ./$MODEL_PREFIX \
 --token "$HF_TOKEN"
aws s3 sync ./$MODEL_PREFIX \
 s3://$MODEL_BUCKET/$MODEL_PREFIX/ \
 --region "$AWS_REGION"

Подготовьте manifest развёртывания модели и при необходимости измените переменные окружения:

export DEPLOYMENT_NAME="dpd-test-deployment"
export ENDPOINT_NAME="dpd-test"
export MODEL_NAME="meta-llama-3-3-70b"
export NAMESPACE="default"
export INSTANCE_TYPE="ml.p5.48xlarge"
export GPUS_PER_NODE="8"
export MODEL_IMAGE="lmcache/vllm-openai:v0.4.3"

Полный YAML для развёртывания см. в Deploy a DPD endpoint.

Поля manifest, важные для DPD

Большинство полей InferenceEndpointConfig общие для DPD и не-DPD endpoints и описаны в документации Inference Operator. Ниже перечислены поля, обязательные или имеющие иную семантику для DPD.

spec.pdSpec: объявляет топологию prefill/decode и задаёт аргументы. Наличие этого поля и делает endpoint disaggregated: operator создаёт отдельные объекты Deployment для prefill и decode и соединяет их через router и LMCache PD backend.

• replicas: масштабирует prefill и decode независимо.
• resources: применяется к pod spec роли. Верхнеуровневое worker.resources игнорируется для DPD pod. Значения для роли имеют приоритет.
• routingThreshold: порог длины в токенах, выше которого запросы идут по disaggregated path. Ниже порога запросы минуют prefiller и сразу идут к decoder.
• args: флаги vLLM, специфичные для роли; они объединяются с worker.args при старте. Флаги, уже присутствующие в worker.args, заменяются значением для роли, а отсутствующие добавляются.

spec.worker.environmentVariables: эти переменные окружения применяются одинаково к контейнерам prefiller и decoder. Отдельного поля environment-variable для роли пока нет. Для поведения на уровне роли используйте вместо этого pdSpec.{prefillSpec,decodingSpec}.args.

Дополнительные сведения о переменных окружения см. в Deploy a DPD endpoint.

Применение manifest и проверка развёртывания

kubectl apply -f inference_endpoint_dpd_config.yaml

Operator создаёт два объекта Deployment в вашем namespace и один router Deployment в hyperpod-inference-system. Загрузка image и модели занимает несколько минут. Сначала pods переходят в ContainerCreating, затем становятся Running, когда контейнеры поднимаются. Посмотрите pods в обоих namespaces:

kubectl get pods -A \
 | grep -E "prefill-${DEPLOYMENT_NAME}|decode-${DEPLOYMENT_NAME}|${DEPLOYMENT_NAME}-${NAMESPACE}-router"

NAMESPACE                   NAME                                           READY   STATUS    RESTARTS   AGE
default                     prefill-dpd-test-deployment-XXXX               3/3     Running   0          7m
default                     decode-dpd-test-deployment-XXXX                3/3     Running   0          7m
hyperpod-inference-system   dpd-test-deployment-default-router-XXXX        2/2     Running   0          7m

Каждый model pod содержит 3 контейнера: worker vLLM, Nginx reverse proxy и OpenTelemetry collector. Router pod содержит 2 контейнера (router, otel). Состояние готовности сообщает условие IEC:

kubectl get inferenceendpointconfig ${DEPLOYMENT_NAME} -n ${NAMESPACE} \
 -o jsonpath='{.status.conditions[0].message}{"\n"}'

DPD prefill and decode deployments are ready

Вызов endpoint и проверка KV transfer

Когда endpoint готов, отправьте короткий и длинный prompt, чтобы задействовать оба маршрута routing. Проверьте логи prefiller и decoder, чтобы подтвердить, что KV cache передаётся по EFA. Приведённые ниже команды предполагают, что IEC развёрнут с ${NAMESPACE}, ${ENDPOINT_NAME} и ${DEPLOYMENT_NAME}, как указано в предыдущем manifest.

Получите нужные имена pods и URL router:

PREFILL_POD=$(kubectl get pod -n ${NAMESPACE} \
 -l 'inference.sagemaker.aws.amazon.com/dpd-role=prefill' \
 -o jsonpath='{.items[0].metadata.name}')
DECODE_POD=$(kubectl get pod -n ${NAMESPACE} \
 -l 'inference.sagemaker.aws.amazon.com/dpd-role=decode' \
 -o jsonpath='{.items[0].metadata.name}')
ROUTER_POD=$(kubectl get pods -n hyperpod-inference-system -o name \
 | grep -- "${DEPLOYMENT_NAME}-${NAMESPACE}-router" | head -1)
ROUTER_URL=http://${DEPLOYMENT_NAME}-${NAMESPACE}-routing-service.hyperpod-inference-system.svc.cluster.local:443/v1/chat/completions

Короткий prompt (ниже порога, прямой путь к decoder)

Запустите короткий prompt через pod внутри кластера, который вызывает endpoint:

kubectl run curl-short --rm -it --image=curlimages/curl --restart=Never -- \
 curl -s -k -X POST "$ROUTER_URL" \
 -H "Content-Type: application/json" \
 -d '{
      "model": "/opt/ml/model",
      "messages": [{"role": "user", "content": "What is disaggregated prefill-decode in one sentence?"}],
      "max_tokens": 80,
      "temperature": 0.0
    }'

{
 "id": "chatcmpl-7-...",
 "object": "chat.completion",
 "model": "/opt/ml/model",
 "choices": [{
 "index": 0,
 "message": {"role": "assistant", "content": "Disaggregated prefill-decode is an inference architecture that ..."},
 "finish_reason": "stop"
 }]
}

Длинный prompt (выше порога, DPD path)

Prompt длиной выше routing threshold 4,096 токенов проходит через prefiller, а затем через decoder для генерации токенов. В следующем примере создаётся prompt примерно на 6,000 токенов путём повторения предложения:

kubectl run curl-long --rm -it --image=curlimages/curl --restart=Never -- sh -c '
ROUTER="'"$ROUTER_URL"'"
LONG=""
i=0; while [ $i -lt 600 ]; do LONG="${LONG}The quick brown fox jumps over the lazy dog. "; i=$((i+1)); done
curl -s -k -X POST "$ROUTER" \
  -H "Content-Type: application/json" \
  -d "{\"model\":\"/opt/ml/model\",\"messages\":[{\"role\":\"user\",\"content\":\"${LONG}\"}],\"max_tokens\":30,\"temperature\":0.0}"
'

{
 "id": "chatcmpl-7-...",
 "object": "chat.completion",
 "model": "/opt/ml/model",
 "choices": [{
 "index": 0,
 "message": {"role": "assistant", "content": "The text is a repetitive sequence of ..."},
 "finish_reason": "length"
 }]
}

Чтобы подтвердить, что invocation использовал disaggregated path, можно проверить логи pod router:

kubectl logs $ROUTER_POD -n hyperpod-inference-system -c router-container --tail=20 \
 | grep -E "Conditional routing|prefill selection|prefill time|to decoder"

Для длинного prompt можно увидеть такой вывод:

[INFO] Conditional routing: estimated_tokens=6750, threshold=4096, disaggregate=True
[INFO] DPD prefill selection: delegating to PrefixAwareRouter with 1 endpoints
[INFO] DPD prefill selection: PrefixAwareRouter selected http://10.1.54.203:8081
[INFO] <req-id> prefill time (TTFT): 7.1913
[INFO] Routing request <req-id> to http://10.1.54.203:8081 at 1780486382.5954, process time = 7.1929
[INFO] Routing request <req-id> to decoder http://10.1.172.158:8081 at 1780486382.6098, process time = 0.0144

disaggregate=True подтверждает, что запрос прошёл через prefiller. Две строки Routing request показывают сначала hop prefill, а затем hop decode.

Рекомендации по масштабированию

Сейчас DPD поддерживает один decoder replica и несколько prefiller replicas. Это означает, что вы масштабируете prefill capacity независимо, а decoder остаётся фиксированным в одном экземпляре.

Начните с соотношения prefill-to-decode 1:1 для сбалансированных нагрузок (chat, code generation), где длины входа и выхода сопоставимы. Переходите к 2:1 или 3:1, когда нагрузка смещена в сторону prefill: summarization, classification или RAG с длинными retrieved contexts. Такое соотношение уместно, если вы видите, что TTFT растёт под нагрузкой, а per-token output latency (TPOT) остаётся стабильной.

При нескольких prefiller задайте intelligentRoutingSpec.routingStrategy для вашей нагрузки. Используйте kvaware для сценариев с повторяющимися префиксами: это максимизирует L1 cache hits между prefiller partitions. Используйте session для multi-turn conversations, где выгодно удерживать контекст пользователя на одном prefiller.

Если вместо этого растёт TPOT и output throughput выходит на плато, несмотря на доступность prefiller, значит, перегружен единственный decoder. В этом случае увеличьте PD_BUFFER_SIZE, уменьшите max-model-len или снизьте concurrency к endpoint, пока не появится поддержка multi-decoder.

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

В бенчмарках использовался genai-bench со synthetic prompts фиксированной длины: 4,096 input tokens и 256 output tokens, при уровнях concurrency 8, 16 и 32. Каждый уровень concurrency прогонялся до стабилизации результатов. Конфигурация DPD: 1 prefiller и 1 decoder на 2 узлах (16 GPUs), KV-aware routing, enforce-eager на prefiller и CUDA graphs на decoder. Базовый вариант: один узел (8 GPUs), та же модель и те же настройки GPU. Аппаратная платформа: ml.p5.48xlarge (8x H100 80GB, EFA enabled). Модель: Llama-3.3-70B-Instruct с tensor-parallel-size=8 и max-model-len=16,384. Следующие диаграммы показывают процент улучшения, которое даёт DPD по сравнению с colocated baseline на двух семействах инстансов. Более высокие столбцы означают больший выигрыш DPD.

Следующая диаграмма показывает те же бенчмарки на инстансах ml.p5en.48xlarge с GPU H200, где выигрыш DPD столь же выражен.

На обеих конфигурациях оборудования DPD даёт устойчивый выигрыш по per-token output latency (TPOT), end-to-end latency и throughput по мере роста concurrency:

• Per-token latency остаётся стабильной под нагрузкой. DPD изолирует decode от вмешательства prefill, сохраняя TPOT постоянной независимо от количества параллельных длинных запросов. Для workloads D(4096,256) при concurrency от 8 до 32 улучшение составляет от 22% на низкой concurrency до 66% на высокой concurrency на H100 и от 28% до 48% на H200.
• Throughput масштабируется с concurrency. Выделенный decoder работает с полной эффективностью CUDA graph без прерываний со стороны prefill. Output throughput увеличивается до 35% на H100 и до 64% на H200 при более высокой concurrency.
• End-to-end latency улучшается на P50. Совокупная экономия TPOT на выходных токенах перекрывает стоимость передачи KV cache. E2E P50 улучшается на 14-32% на H100 и на 29-41% на H200.

DPD действительно немного увеличивает time to first token из-за передачи KV cache по EFA RDMA. Для потоковых нагрузок, где важнее стабильная доставка каждого токена, чем самый первый ответ, такой компромисс обычно выгоден. Порог conditional routing по умолчанию 4,096 токенов нужен, чтобы короткие запросы вообще не проходили через disaggregation и не платили лишнюю стоимость передачи там, где это не нужно.

Наблюдаемость

Следить за метриками DPD можно через возможности наблюдаемости SageMaker HyperPod. Подробнее см. Accelerate foundation model development with one-click observability in Amazon SageMaker HyperPod.

Метрики DPD доступны в Inference dashboard.

Дополнительными полезными метриками могут быть CPU/GPU usage, доступные в dashboard Tasks, а также метрики из dashboard Cluster Overview.

Очистка ресурсов

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

• Удалите InferenceEndpointConfig, чтобы убрать pod prefiller, pod decoder, router и все связанные services:
  Копировать код

  kubectl delete inferenceendpointconfig ${DEPLOYMENT_NAME} -n ${NAMESPACE}
  

• (Опционально) удалите model из S3, если загружали её специально для этого walkthrough:
  Копировать код

  aws s3 rm s3://${MODEL_BUCKET}/${MODEL_PREFIX}/ --recursive --region ${AWS_REGION}
  

• (Опционально) уменьшите масштаб или удалите instance group HyperPod, если GPU-инстансы были выделены только под это развёртывание. Инструкции см. в документации Managing HyperPod clusters.

Заключение

Disaggregated Prefill and Decode (DPD) в Amazon SageMaker HyperPod запускает prefill и decode на отдельных пулах GPU. KV cache между ними передаётся по EFA с использованием GPU-Direct RDMA. Prefill ограничен вычислениями. Decode ограничен пропускной способностью памяти. При совместном размещении эти две фазы конкурируют за одни и те же GPU-ресурсы. Один длинный prompt может остановить in-flight decoding и увеличить tail per-token latency. Разделение устраняет это влияние, делает latency более предсказуемой при смешанном трафике и позволяет независимо масштабировать каждую фазу.

HyperPod Inference Operator берёт на себя базовую оркестрацию: разворачивает router, связывает pod prefiller и decoder и интегрируется с observability HyperPod. DPD включается добавлением нескольких полей в тот же ресурс InferenceEndpointConfig, который вы уже используете для неразделённых endpoints.

Начать можно уже сегодня, развернув DPD endpoint в вашем HyperPod EKS cluster по шагам из этой статьи. Чтобы узнать больше, см. документацию Amazon SageMaker HyperPod, руководство по развёртыванию моделей HyperPod Inference Operator или сразу попробуйте пример manifest из этой статьи.

Материал — перевод статьи с английского.

Оригинал: Disaggregated prefill and decode for LLM inference on SageMaker HyperPod

Сгенерировать аудио

AI-агент может обработать счет, помочь с рассмотрением претензии или классифицировать обращение в proof of concept. Но запуск таких агентов на тысячах или даже миллионах рабочих единиц в production создает совсем другой набор задач. На enterprise-масштабе успех зависит не только от самого агента. Организациям нужно отслеживать состояние каждого рабочего элемента по мере прохождения через нескольких агентов и систем, точно понимать, где и почему произошел сбой, позволять человеку подключаться при необходимости и динамически масштабировать инфраструктуру в зависимости от нагрузки. Amazon Quick Automate решает эти операционные задачи с помощью управления кейсами. Каждый рабочий элемент представлен как кейс, который сохраняется на протяжении всего жизненного цикла, дает пошаговую видимость состояния workflow, поддерживает обработку human-in-the-loop там, где требуется решение человека, и позволяет выполнять задачи параллельно, чтобы команды могли оркестрировать агентов и автоматизировать бизнес-процессы в масштабе.

В этой статье мы покажем, как объединить управление кейсами с агентной автоматизацией в Quick Automate. Мы познакомим с управлением кейсами и разберем жизненный цикл кейса в agentic workflow — от создания и обработки до закрытия. Мы рассмотрим, как создавать и управлять одним или несколькими кейсами, автоматически отслеживать и обновлять статус, обрабатывать исключения и включать шаги Human-in-the-loop (HITL) в workflow. Также мы покажем паттерн case creator-processor, который обеспечивает динамическое масштабирование. Наконец, на реальном примере мы разберем, как выстраивать управление кейсами для enterprise-процессов, включая HITL и отслеживание кейсов.

Quick Automate объединяет AI-агентов и оркестрацию workflow в Amazon Quick для автоматизации сложных end-to-end бизнес-процессов в приложениях, пользовательских интерфейсах и API. Нативно сочетая agentic и deterministic automation с enterprise workflow orchestration, Quick Automate приносит структуру, прозрачность и контроль в агентные бизнес-процессы. Он предоставляет нативное управление кейсами с отслеживаемыми рабочими единицами, а также такие механизмы, как гранулярное управление доступом, журналирование активности, контроль версий, обработка исключений и возможности HITL. В результате процессы надежно проходят путь от запуска до завершения на enterprise-масштабе.

Управление кейсами в Quick Automate дает несколько важных преимуществ. Оно повышает прозрачность по мере прохождения workflow через четко определенные стадии с отслеживанием в реальном времени. Владельцы процессов видят, на каком этапе находится каждый рабочий элемент, а менеджеры могут контролировать throughput, заранее находить узкие места и вмешиваться до того, как задержки повлияют на бизнес-результаты. Параллельная обработка позволяет выполнять несколько кейсов одновременно, увеличивая производительность и помогая организациям соблюдать бизнес-SLA. Комплаенс, аудитопригодность и governance усиливаются, потому что каждое действие, решение и переход состояния фиксируются в истории кейса. Вовлеченность стейкхолдеров тоже растет благодаря обновлениям статуса в реальном времени, которые синхронизируют операторов, менеджеров и бизнес-заказчиков. Общение происходит в контексте каждого кейса, заменяя разрозненные email-цепочки централизованной совместной работой, понятной ответственностью и меньшим числом потерянных передач задач.

Требования перед началом работы

Перед внедрением workflow управления кейсами в Quick Automate убедитесь, что у вас есть доступ к Amazon Quick и что вы работаете в правильном AWS Region для вашей организации, поскольку workflow в Quick Automate зависят от региона. У вашей учетной записи должна быть лицензия Enterprise, чтобы создавать workflow в Quick Automate.

Жизненный цикл кейса и статус

Управление кейсами в Quick Automate превращает сложные длительные workflow в дискретные отслеживаемые рабочие единицы, которые можно обрабатывать параллельно. Каждый кейс представляет собой отдельную рабочую единицу, проходящую через определенные стадии жизненного цикла. Кейс содержит тип кейса, который является пользовательским контейнером для группировки связанных работ, например счетов или претензий. Он также включает reference name, который служит уникальным ID для отслеживания, и пользовательские поля данных, хранящиеся в виде пар ключ-значение и содержащие бизнес-информацию, необходимую для обработки. Система автоматически управляет дополнительными метаданными, включая статус кейса в workflow, детали исключений при сбое и журналы выполнения, относящиеся к кейсу. Следующая таблица описывает статусы жизненного цикла, которые может иметь кейс.

Лучшие практики автоматизации управления кейсами

Управление кейсами в Quick Automate встроено в стандартный жизненный цикл автоматизации. В следующих подразделах мы пройдем по каждому этапу — от начального проектирования до мониторинга в production.

Проектирование автоматизации

При проектировании workflow сначала определите, что именно считается кейсом в вашей автоматизации. Кейс представляет собой одну единицу работы, например счет, претензию, тикет или заказ, которая проходит через workflow от запуска до завершения.

Затем решите, как создавать кейсы. Кейсы можно создавать по одному по мере наступления событий или генерировать пакетами из источников вроде файлов, баз данных или внешних систем. После этого определите, как обрабатывать кейсы. Кейсы могут обрабатываться последовательно или параллельно. Хотя один automation может выполнять весь workflow, команды часто разделяют обязанности между двумя automation, чтобы обеспечить параллельную обработку и более четкое владение. Case Creator получает данные из источников вроде Excel-файлов, баз данных и веб-приложений и преобразует каждую запись в кейс, представляющий отдельную рабочую единицу. Case Processor потребляет кейсы и выполняет фактические шаги workflow, включая обработку исключений и задачи HITL. Несколько processors могут работать параллельно, повышая throughput.

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

Создание automation

Quick Automate предоставляет разработчикам два действия для приема работ.

Первое — Create New Case, которое используется, когда источник данных — отдельное событие, например отправка формы пользователем, поступление API call или создание support ticket. Вы указываете уникальное reference name (например, Order-12345), выбираете тип кейса, который группирует похожие кейсы (например, SalesOrders), и добавляете пары ключ-значение, содержащие пользовательские данные кейса. Это действие создает ровно один кейс и сразу переводит его в Ready.

Второе — Create Multiple Cases, которое используется, когда источником является электронная таблица, CSV-файл или таблица записей, например массовые загрузки или запланированные data load. Вы задаете тип кейса, исходную таблицу и столбец, который служит уникальным ID. Действие создает отдельный кейс для каждой строки, автоматически сопоставляя каждый столбец с полем пользовательских данных.

Данные кейса часто нужно изменять по мере прохождения workflow через разные стадии. С помощью действия update cases вы можете добавлять или изменять существующие данные кейса, передав ID кейса и пары ключ-значение. Используйте это действие, чтобы фиксировать результаты обработки, сохранять отметки времени для аудита, хранить вычисленные значения или поддерживать пользовательские статусы. Это действие доступно только для кейсов в состоянии In Progress. Обновленную информацию можно получить в automation через updated_case["custom_data"]["key_name"]. Если нужно динамически найти или извлечь существующие кейсы, используйте действие Search Cases. С его помощью можно выполнять запросы по фильтрам, таким как тип кейса, reference ID, статус или другие атрибуты. Полученные результаты затем можно использовать для просмотра деталей кейса, запуска дополнительной обработки или обновления кейсов как части workflow.

Для задач Human in the loop (HITL) разработчики могут использовать действие Create User Task, чтобы приостановить кейс и показать человеческому проверяющему релевантный контекст и поля решений. Пока кейс ждет в статусе Pending Resolution, другие кейсы продолжают обрабатываться. Когда проверяющий завершает задачу в Task Center, кейс автоматически возвращается в состояние Ready с полученным человеческим вводом, и обработка возобновляется. Поскольку автоматизация возобновляется с начала, она должна проверять атрибут latest_task_resolution, чтобы определить следующую ветку выполнения.

Развертывание automation

После создания automation вы публикуете и настраиваете его для выполнения в production. Можно публиковать workflow и планировать их запуск через заданные интервалы. Во время развертывания настраиваются два ключевых аспекта. Во-первых, задается число параллельных экземпляров, которые будут выполняться одновременно при настройке триггера, исходя из ожидаемой нагрузки. Automation для case processor могут запускать несколько экземпляров параллельно, распределяя объем кейсов. Во-вторых, для задач HITL вы указываете пользователей или группы, которые могут завершать задачи в Task Center. На этапе развертывания вы добавляете отдельных пользователей или группы, чтобы предоставить пользователям Quick доступ к выполнению задач.

Мониторинг automation

Quick Automate предоставляет видимость в реальном времени для каждого кейса по мере его прохождения через workflow, позволяя пользователям отслеживать статус каждого экземпляра processor с одной панели. Представление мониторинга показывает ключевые метрики, такие как процент успешного завершения, бизнес-исключения (вызванные логическими ошибками или проблемами с данными, например отсутствующими обязательными полями), системные исключения (вызванные техническим сбоем) и незавершенные кейсы. Эти метрики помогают командам быстро находить узкие места и измерять эффективность automation. Каждая запись кейса содержит его статус, метаданные и детали обработки, а пользователи могут открывать кейсы, чтобы просматривать полные журналы, пользовательские поля данных, сообщения об исключениях, временные метки и, где доступно, скриншоты.

Пример использования: автоматизация обработки выписок нескольких банков с управлением кейсами

Этот пример показывает, как Quick Automate сокращает ручной ввод данных в двух системах за счет управления кейсами для параллельной обработки. Мы пройдем через реальный сценарий treasury consolidation — от архитектуры решения до деталей внедрения — и покажем, как каждый концепт из предыдущих разделов применяется в production automation.

Корпорации, работающие с несколькими банками, сталкиваются с повторяющейся операционной задачей. Каждый месяц treasury analysts скачивают выписки из порталов каждого банка и вручную вводят сотни транзакций в центральную treasury management system компании. Одна ошибка при вводе суммы может привести к проблемам сверки, на выяснение которых уходят часы, а требования Sarbanes-Oxley (SOX) требуют, чтобы каждая запись была точной и поддавалась аудиту. Ручной процесс медленный, подвержен ошибкам и задерживает сверку на конец месяца.

Архитектура решения

Следующая диаграмма показывает end-to-end архитектуру решения для автоматизации обработки банковских выписок из нескольких банков. Automation case creator и case processor работают вместе, обеспечивая параллельную обработку и сокращение времени цикла на масштабе. Первое automation, case creator, получает последнюю банковскую выписку, извлекает каждую транзакцию с помощью custom AI agent и загружает их как отдельные кейсы. Второе automation, case processor, обрабатывает каждый кейс, переходя в банковский портал, выбирая нужный счет и вводя транзакцию. Несколько экземпляров processor могут работать одновременно, каждый независимо забирает и вводит транзакции. Платежи свыше 200 долларов помечаются для human review, где treasury analyst проверяет получателя, сумму и авторизацию перед тем, как одобрить или отклонить транзакцию. Отклоненные транзакции фиксируются как business exceptions с кодом причины и комментариями аналитика для audit trail.

Рисунок 1: Архитектура решения для обработки выписок нескольких банков

Реализация: дизайн creator-processor

Workflow case creator (Treasury Bank Statement Gathering) выполняет три ключевых действия. Он переходит на портал банковских выписок и формирует последнюю выписку для загрузки. Затем он использует custom AI agent, чтобы разобрать загруженный PDF и извлечь каждую транзакцию в структурированные поля данных. Наконец, он массово создает кейсы, по одному на каждую извлеченную транзакцию, и каждый переводит в состояние Ready для последующей обработки. Следующее изображение показывает workflow case creator, как он создан в Quick Automate. Workflow содержит два process step. Первый обрабатывает навигацию браузера к банковскому порталу и загрузку PDF, а второй вызывает custom AI agent для извлечения с последующим массовым созданием кейсов.

Рисунок 2: Workflow case creator в Quick Automate

Custom agent, специализированный task agent, настроенный с действиями и инструкциями, используется внутри workflow нативно. Он получает загруженный PDF и использует Python code tool, чтобы извлечь строки транзакций в структурированную таблицу. Схема выхода агента определяет поля, необходимые для каждого кейса. Следующее изображение показывает конфигурацию агента с инструкцией и схемой выхода.

Рисунок 3: Конфигурация custom AI agent

После того как агент извлекает все транзакции, automation использует действие Create Multiple Cases для массового создания кейсов. В качестве типа кейса указывается “Bank Transaction”, таблица с результатами агента сопоставляется как источник пользовательских данных, а столбец Reference назначается уникальным ID для каждого кейса. Следующее изображение показывает конфигурацию массового создания кейсов внутри workflow.

Рисунок 4: Create multiple cases

После создания каждый кейс содержит полные данные транзакции в виде пользовательских атрибутов. Запись кейса включает статус кейса (Ready), его reference name, тип кейса (Bank Transaction) и пользовательские поля данных, содержащие название банка, номер счета, дату транзакции, описание, тип и сумму. Следующее изображение показывает Monitor dashboard с таблицей кейсов и их ключевыми компонентами.

Рисунок 5: Панель мониторинга с созданными кейсами

Workflow case processor (Treasury Bank Transaction Entry) извлекает кейсы со статусом Ready и обрабатывает каждую транзакцию независимо. Сначала он открывает банковский портал и проходит аутентификацию как администратор. Затем он входит в цикл обработки, который извлекает кейсы типа “Bank Transaction” и обрабатывает их по одному. Поскольку Quick Automate поддерживает несколько одновременных экземпляров processor, эту автоматизацию можно масштабировать горизонтально в соответствии с объемом транзакций.

Для каждого кейса processor сначала проверяет, был ли кейс уже направлен на human review. Если кейс ранее был отправлен treasury analyst и вернулся с решением, processor проверяет результат авторизации. Одобренные кейсы сразу переходят к вводу транзакции. Отклоненные кейсы поднимаются как business exceptions с кодом причины и комментариями аналитика, создавая полный audit record без ввода транзакции в портал.

Для кейсов, которые еще не были проверены, processor оценивает порог платежа. Если транзакция является платежом (Credit type) и сумма составляет 200 долларов или более, кейс направляется treasury analyst на проверку двойной авторизации через Task Center. Задача HITL включает данные транзакции, выпадающий список авторизации с вариантами Approved и Rejected, выпадающий список кода причины для отклонений и поле комментариев свободного текста. Кейс переходит в статус Pending Resolution в ожидании решения аналитика, а processor переходит к следующему доступному кейсу, не дожидаясь ответа.

Следующее изображение показывает workflow case processor, как он создан в Quick Automate, включая условную логику для обработки human review, проверку порога платежа, создание HITL-задачи и ввод транзакции.

Рисунок 6: Workflow case processor в Quick Automate

Для транзакций, которым не требуется human review, или которые были одобрены аналитиком, processor использует UI agent для ввода транзакции в банковский портал. Агент переходит к панели управления, добавляет новую транзакцию, выбирает нужный тип и сумму вместе с другими деталями и отправляет форму. Агент также проверяет, что ввод транзакции завершился успешно. Следующее изображение показывает конфигурацию UI agent с естественно-языковой инструкцией для ввода и проверки транзакции.

Рисунок 7: Нативный UI agent и инструкция

Мониторинг деталей и статуса кейсов

Monitor dashboard предоставляет видимость в реальном времени в производительности обработки кейсов для automation консолидации казначейства. В этом представлении операторы могут отслеживать, сколько кейсов было создано, сколько сейчас находится в процессе и сколько успешно завершились, завершились с ошибкой или ожидают human resolution. Панель содержит графики, показывающие динамику создания кейсов и паттерны исключений во времени, что поддерживает как операционный мониторинг, так и требования compliance audit.

Следующее изображение показывает вкладку Cases в Monitor dashboard, где отображаются статусы кейсов, время обработки и детали исключений по всем экземплярам processor.

Рисунок 8: Cases

Операторы также могут получать доступ к HITL-задачам через вкладку Tasks, чтобы видеть, какие транзакции ожидают проверки аналитика, отслеживать соблюдение SLA и просматривать историю решений, включая одобрения и причины отклонения. Следующее изображение показывает HITL-задачу в том виде, как она отображается в Task Center. Treasury analyst видит полный контекст транзакции вместе с полями формы авторизации для принятия решения.

Рисунок 9: Tasks

Заключение

Управление кейсами в Quick Automate позволяет обрабатывать высоконагруженные и сложные автоматизации в масштабе. Превращая работу в дискретные отслеживаемые кейсы с определенными жизненными циклами, вы получаете полную операционную видимость workflow. Такой подход сокращает время цикла за счет параллельной обработки, повышает качество решений за счет направления критических кейсов к человеческим проверяющим и повышает операционную уверенность благодаря мониторингу в реальном времени, который выявляет исключения до того, как они повлияют на результат.

Следующие шаги

Начните внедрять управление кейсами в свои workflow, изучив документацию по orchestration для Quick Automate и попробовав automation в виде готовых примеров, как описано в этой статье. Откройте Quick Automate, перейдите в свой проект, выберите Start building и найдите “Treasury Bank Statement Gathering” (case creator) и “Treasury Bank Transaction Entry” (case processor) в библиотеке образцов automation. После открытия обоих примеров вы можете сначала запустить case creator, чтобы сгенерировать кейсы транзакций, а затем настроить и запустить case processor, чтобы начать параллельный ввод транзакций.

Вы можете адаптировать этот паттерн и к другим automation, например к обработке счетов или рассмотрению претензий, изменив логику создания кейсов и правила маршрутизации processor, сохранив при этом ту же базовую структуру orchestration. Дополнительные ресурсы смотрите в публичной документации Quick Automate.

Материал — перевод статьи с английского.

Оригинал: Scaling agentic workflows with native case management in Amazon Quick Automate

Сгенерировать аудио

The New York Times и The Daily News утверждают, что OpenAI лгала о своей способности искать в данных чатов пользователей и в наборах данных следы их защищённых авторским правом материалов. Это новое обострение двухлетнего иска против AI-компании, которую обвиняют в том, что она обучала свои generative AI-модели на контенте Times и воспроизводила эту журналистику в ответах пользователей.

На протяжении дела OpenAI утверждала, что у неё нет возможности искать в собственном training corpus. Компания также заявляла, что поиск по её огромной коллекции разговоров ChatGPT или их предоставление были бы технически обременительными и подняли бы вопросы приватности пользователей, поскольку журналы пришлось бы извлекать, обрабатывать и деидентифицировать. Издания добивались этих данных, чтобы понять, содержится ли их защищённая журналистика в training dataset OpenAI и как часто ChatGPT генерировал ответы, использующие или воспроизводящие их материалы.

В апрельском допросе по решению суда инженер OpenAI по защите данных Vinnie Monaco, как утверждается, сообщил, что OpenAI уже проводила внутренние поиски и анализ своего training corpus на предмет наличия защищённых журналистских материалов.

Как утверждается, показания Monaco также раскрыли, что ещё до подачи иска NYT OpenAI уже накопила базу примерно из 78 миллионов деидентифицированных разговоров ChatGPT и использовала её внутри компании, чтобы определить, насколько она нарушает права на чужие произведения. Кроме того, на основе этого набора данных OpenAI якобы внедрила фильтр Bloom в составе набора инструментов под названием Project Giraffe, который выявлял и фиксировал regurgitation в ответах вскоре после подачи иска.

Последние два раскрытия особенно значимы. Изначально истцы просили OpenAI предоставить выборку из 120 миллионов chat logs, но OpenAI удалось договориться о сокращении объёма до 20 миллионов. OpenAI в итоге передала эту выборку суду в декабре прошлого года, однако, как утверждается, в ней было столько редактирований, что она стала «непригодной для использования», как указал суд. Истцы также заявили, что OpenAI удалила миллиарды ответов ChatGPT после подачи иска, прямо нарушив судебный приказ о сохранении доказательств, а также заменила миллионы логов в запрошенной выборке.

Иными словами, они утверждают, что OpenAI намеренно сделала получение информации, которая уже была у компании, максимально затруднительным.

«Если бы OpenAI действительно считала, что копирование журналистики наших клиентов было добросовестным и законным, она не стала бы скрывать правду о том, что она это сделала», — сказал в заявлении ведущий адвокат истцов Ian B. Crosby.

Теперь NYT и The Daily News просят судью наказать OpenAI за предполагаемое сокрытие доказательств и вмешательство в discovery-процесс. Они просят суд запретить OpenAI использовать выборку из 20 миллионов chat log в качестве доказательства, заявляя, что она ненадёжна; признать фактом, что логи ChatGPT показали бы значительную regurgitation и grounding материалов истцов; запретить OpenAI утверждать, что предоставленные ею логи не доказывают существенную regurgitation; и обязать OpenAI оплатить юридические расходы, связанные с поиском этих доказательств.

В заявлении представитель OpenAI Drew Pusateri отверг обвинения, заявив, что Times пытается получить доступ к частным перепискам пользователей, когда их дело слабеет.

«Поскольку дело Times слабеет, и им пришлось снять претензии против нас, они продолжают свои попытки нарушить приватность людей, не имеющих никакого отношения к этому делу, в том числе выдвигая эти откровенно ложные обвинения», — сказал Pusateri. «Мы продолжим защищать приватность наших пользователей и давно закреплённые принципы fair use».

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

Материал — перевод статьи с английского.

Оригинал: New York Times says OpenAI hid evidence in ChatGPT copyright trial

Сгенерировать аудио

Cloud finops can help enterprises get smart about controlling generative AI costs using the same playbooks that tamed cloud spending.

Каждые несколько лет появляется новая технология, которая обещает перевернуть бизнес, и компании бросаются внедрять ее, не спрашивая, во сколько это обойдется. Я наблюдаю этот сценарий уже 30 лет. Сначала это был cloud computing. Теперь это generative AI, и счет приходит быстрее, чем кто-либо ожидал.

Последние данные показывают, что у многих компаний затраты на AI token costs оказываются в 10–20 раз выше первоначальных прогнозов. Это не погрешность округления. Это стратегическая ошибка, которую CFO уже начинают замечать, и они этим недовольны.

Дело в том, что этот кризис был полностью предсказуем. Мы уже проходили это с cloud computing и усвоили жесткие уроки о том, что бывает, когда технологии внедряют без строгого контроля затрат. Хорошая новость в том, что компании наконец применяют эти уроки и обращаются к своим cloud finops playbooks, чтобы обуздать новый вид расходов.

The 50x problem

Объясню масштаб происходящего. Goldman Sachs оценивает, что AI agents потребляют примерно в 50 раз больше вычислительной мощности на задачу, чем традиционные чат-боты на prompt-based подходе. Это фундаментальный сдвиг в том, как расходуются ресурсы. Если умножить это на десятки или сотни AI agents, которые внедряет компания, математика очень быстро становится неприятной.

Проблема token costs усугубляется тем, что затраты на AI по своей природе переменные. В отличие от традиционного лицензионного ПО или инфраструктурных контрактов, вы платите за token, а его потребление может резко колебаться в зависимости от поведения пользователей, сложности запросов и общего объема обращений к системе. Это точно та же проблема, с которой мы сталкивались в cloud computing. Каждый раз, когда кто-то запускает новый instance или хранит данные не в том tier, счет растет.

Компании ожидали, что развернут AI и увидят стабилизацию расходов. Вместо этого затраты растут месяц за месяцем и часто превышают прогнозы в разы. Бизнес-кейс, который выглядел убедительно в переговорной, заметно теряет привлекательность на финансовом комитете.

Lessons from the cloud playbook

Вот здесь становится интересно. Cloud providers и managed service providers, которые работают с ними, почти два десятилетия строили дисциплину financial operations — finops, если использовать модное сокращение. Это практики, инструменты и организационные структуры, которые делают cloud spending видимым, управляемым и в итоге объяснимым для бизнеса.

Те же дисциплины теперь применяются к AI token costs, и компании с зрелыми finops-программами справляются лучше тех, у кого их нет. Набор действий по сути тот же:

• сделать расходы видимыми;
• привязать затраты к нужным командам;
• задать guardrails и alerts;
• создать feedback loops, которые поощряют эффективное поведение.

Компании вроде Priceline внедрили dashboards, которые дают руководителям visibility в реальном времени по token consumption, а ежемесячные отчеты поступают напрямую CFO и CTO. Smartsheet использует похожий подход, предоставляя department-level dashboards, чтобы менеджеры видели, как именно их команды расходуют tokens, и получали automated alerts, когда потребление приближается к заданным порогам.

Компонент accountability здесь критически важен. Когда разработчики и бизнес-пользователи видят, как их использование AI превращается в доллары, они принимают более взвешенные решения о том, какие models использовать, как строить prompts и когда лучше положиться на human judgment вместо AI processing.

The show-back revolution

Одна из самых эффективных техник, появившихся в ответ на этот кризис, — подход show back к управлению AI cost management. Вместо того чтобы просто показывать расходы отдельным департаментам, компании теперь относят AI spending на команды и конкретных людей, которые создают это потребление. Так появляется accountability без организационной сложности полноценной chargeback-модели.

OpenText сообщала, что внедрение подходов show-back и chargeback может снизить token costs на 20%–30% за несколько месяцев. Это немало. Если вы тратите $5 млн в месяц на AI tokens, это экономия $1,5 млн только за счет того, что люди начинают видеть, сколько они расходуют.

Механика проста: когда руководитель разработки понимает, что его команда израсходовала $200 000 в tokens за месяц, он начинает задавать вопросы. Почему для этой задачи используется самая дорогая model? Может ли более small model обработать 80% этих запросов? Не повторяются ли prompts без необходимости? Такие вопросы ведут к optimization, а optimization — к savings.

Model smarts

Еще один урок cloud-опыта заключается в том, что самый дорогой вариант редко оказывается лучшим. Это звучит очевидно, но организации часто по умолчанию выбирают самый большой и самый мощный AI model для любой задачи, даже если такая мощность на самом деле не нужна.

Новая best practice — подбирать model capability под требования задачи. Простая classification task не требует frontier model. Обычную text-generation задачу вполне может закрыть меньшая и более дешевая model, запущенная локально или через более дешевый API tier. Выигрыш в эффективности от такого подхода может быть существенным.

Некоторые компании идут дальше и для подходящих use cases используют более старые models или open source-альтернативы. Qualcomm, например, инвестировала в запуск models на собственном hardware вместо того, чтобы полагаться исключительно на cloud-based model providers. Такой подход требует большей технической зрелости, но может резко сократить per-token costs для high-volume приложений.

The real challenge

Больше всего меня в текущей ситуации беспокоит вот что. Многие компании внедряли AI, не выстроив заранее достаточную cost management infrastructure. Их захлестнули энтузиазм вокруг технологии, конкурентное давление и вера в то, что выгоды оправдают любые затраты. Такой подход работал, когда AI-проекты были небольшими экспериментами. Но теперь, когда AI становится ядром business operations, отсутствие финансового контроля превращается в серьезную проблему. Нам нужно применять к закупке и внедрению AI такую же дисциплину, какую мы применяли к любым другим крупным технологическим инвестициям.

Компании, которые добьются успеха, будут воспринимать AI token costs как управляемые operating expense, а не как непредсказуемую переменную. Это означает использование тех же инструментов и дисциплин, которые уже доказали эффективность в cloud cost management: visibility, accountability, optimization и continuous improvement.

Cloud providers и managed service partners, которые с ними работают, делают это уже много лет. Они построили инструменты, разработали best practices и подготовили специалистов, которые теперь могут применить этот опыт к проблеме AI costs. Если вашей организации трудно контролировать AI spending, поиск партнеров с глубоким опытом finops может стать самым быстрым путем к управлению затратами.

Хорошая новость в том, что этот кризис можно решить. Но для этого нужно признать проблему, вложиться в нужные возможности и принять, что внедрение технологий без финансовой дисциплины ведет к неприятностям.

Разумно управляйте расходами на AI. CFO это оценит.

Материал — перевод статьи с английского.

Оригинал: Relearning cloud lessons from runaway AI token costs

Сгенерировать аудио

Краткая сводка Dive

Американские компании включают киберриски в общую стратегию управления рисками на фоне роста AI и cloud

Быстрое внедрение AI и cloud заставляет компании сильнее фокусироваться на устойчивости бизнеса и финансовых последствиях.

Опубликовано 10 июля 2026 года

https://www.cybersecuritydive.com/editors/djones/

David Jones, reporter

Getty Images

Сначала опубликовано на

https://www.cybersecuritydive.com/

Краткая сводка Dive

• Американские компании объединяют вопросы киберриска со своей общей стратегией enterprise risk на фоне того, как внедрение AI и устойчивость бизнеса меняют приоритеты, говорится в отчете, опубликованном во вторник компанией Information Services Group, исследовательской и консультационной фирмой в сфере технологий.
• Кибербезопасность все чаще рассматривается как критически важный для бизнеса вопрос, поскольку компании ускоряют внедрение agentic AI и переводят значительную часть технологической и data-инфраструктуры в hybrid или multicloud-среду.
• Руководители компаний теснее связывают решения о киберрасходах с общей IT-стратегией. Кроме того, члены C-suite и советов директоров берут на себя большую ответственность за непрерывность бизнеса, финансовые риски и соблюдение регуляторных требований.

Комментарий Dive

Отчет отражает заметные изменения у крупных компаний в том, как расширенное использование AI и переход в cloud меняют разговор об общем бизнес-риске.

Внедрение AI заставляет компании пересматривать корпоративное управление, внутренние контроли и общую готовность к крупной кибератаке или сбою IT-инфраструктуры.

«Кибербезопасность стала ключевым бизнес-вопросом, а не отдельной технологической функцией», — заявил Cybersecurity Dive директор по кибербезопасности ISG Джейсон Стейдинг. «Организации встраивают киберриск в решения по внедрению AI, цифровой трансформации и более широким инвестициям в технологии; большинство компаний понимают, что безопасность позволяет развиваться, одновременно управляя enterprise risk».

По словам Стейдинга, директора по информационной безопасности и директора по информационным технологиям играют в этих организациях более стратегическую роль. Они взаимодействуют с советами директоров и исполнительным руководством, чтобы помогать формировать бизнес-решения и следить за тем, чтобы кибербезопасность была встроена в общую бизнес-стратегию.

В отчете S&P за июнь предупреждалось, что компании, у которых нет сильного внутреннего управления безопасностью, могут поставить под угрозу свои кредитные рейтинги.

Тем временем власти Великобритании призывали корпоративных лидеров включать киберриск в общую бизнес-стратегию и бьют тревогу из-за роста числа атак на критическую инфраструктуру.

Материал — перевод статьи с английского.

Оригинал: US enterprises incorporate cyber risk into larger strategic focus

Сгенерировать аудио

AI может разбирать сложные инциденты в SRE, но только если у него есть жесткие ограничители, а люди остаются в роли главных при сбоях.

Site reliability engineering выходит на новый этап. По мере того как инциденты становятся быстрее, насыщеннее данными и сложнее, команды SRE изучают agentic AI для triage алертов, анализа root cause, выполнения runbook и планирования mitigation. Но в production вопрос не в том, может ли агент действовать, а в том, могут ли люди доверять ему действовать безопасно, последовательно и прозрачно, когда система находится под нагрузкой.

В этой статье утверждается, что доверие — это инженерный результат, а не маркетинговое обещание. Надежные agentic SRE-системы строятся на grounded telemetry, явных safety boundaries, progressive autonomy, auditability и оценке на реальных инцидентах.

Почему доверие важно

Обычная автоматизация хорошо работает там, где мир предсказуем. Работа SRE устроена иначе, потому что инциденты хаотичны, частичны и требуют быстрых решений; симптомы неоднозначны, зависимости меняются, а бизнес-контекст редко укладывается в аккуратный playbook. Плавный AI-агент без системного контекста может звучать убедительно и при этом предлагать опасные рекомендации.

Доверие в SRE зарабатывается во время сбоев, а не на демо. Это означает, что система должна доказать пользу во время шумных алертов, неудачных deploy, частичных outage и противоречивой telemetry, оставаясь достаточно ограниченной, чтобы одна ошибка не превратилась в крупный инцидент. Работа Google по AI-in-SRE говорит о том же через строгие guardrails, progressive authorization и deterministic actuation controls.

Опоры доверия

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

Модель автономности SRE у Google отражает ту же последовательность: от assisted monitoring и investigation к частичной автономности с одобрением человека и далее — к более высокой автономности только после устойчивых успехов и доказанной безопасности.

Архитектурный шаблон

Надежная agentic SRE-система должна разделять reasoning и actuation. Агент может расследовать, суммировать, предлагать и даже готовить план, но сам путь исполнения должен проходить через deterministic safety layer, которая проверяет права, риск, текущее production state и blast radius до любого изменения.

Сильный шаблон выглядит так:

1. Алерт поступает из мониторинга или incident tooling.
2. Агент собирает контекст из telemetry, истории deploy, ownership и прошлых инцидентов.
3. Агент формирует ранжированную гипотезу и кандидатный remediation plan.
4. Safety layer проверяет policy, risk score, текущее состояние инцидента и результат dry-run.
5. Человек утверждает низкоуверенные или высокорисковые действия.
6. Actuation layer выполняет только предварительно одобренные, ограниченные изменения.
7. Система отслеживает последствия после действия и либо подтверждает успех, либо откатывается.

Описание AI operator и его mitigation safety verification layer у Google — полезная отправная точка: investigation не то же самое, что actuation, и они не должны разделять один и тот же trust boundary. Такое разделение уменьшает blast radius и позволяет прерывать систему.

Чтобы попробовать Agentic SRE, у StackGen есть community edition, где можно увидеть возможности agentic SRE, подключив Grafana или Datadog.

Рабочие guardrails

Самые эффективные ограничения в лучшем смысле скучны. Они включают least-privilege identity, жесткие rate limits, поддержку dry-run, явные approval workflows, action allowlists и механизмы hard stop для runaway loops. Подробное руководство о том, как SRE доверяет AI-агентам, можно посмотреть здесь. AWS описывает доверие к автономным системам теми же словами: identity, runtime guardrails, observability и policy enforcement — основа безопасной автономности.

Для SRE-агентов особенно важны несколько ограничителей:

• Least privilege identity, чтобы агент имел доступ только к тем системам, которые ему действительно нужны.
• Dry-run или simulation mode, чтобы возможный результат был известен до изменения production state.
• Circuit breakers и loop detection, чтобы останавливать повторяющиеся или runaway вызовы инструментов.
• Action tiers, чтобы низкорисковые задачи можно было автоматизировать, а высокорисковые — только утверждать.
• Red-button controls, чтобы люди могли мгновенно отозвать автономность во время плохого инцидента.

Эти меры не говорят о незрелости. Именно они делают автономность допустимой в среде с высокими ставками.

Observability для агентов

Observability нужна не только сервисам, но и самому агенту. Если reasoning, использование инструментов и результаты агента не наблюдаемы, то отладка во время инцидента превращается в догадки. Google прямо подчеркивает необходимость раскрывать reasoning traces и execution traces, чтобы автономные решения оставались auditable и debuggable.

Хороший стек observability для агента должен собирать:

• входные данные и извлеченный контекст;
• tool calls, параметры и результаты;
• промежуточные гипотезы;
• confidence и uncertainty;
• approval, отказ и override;
• финальное действие и результат;
• сигналы проверки после действия.

Это создает operational memory, необходимую для понимания того, помог ли агент, навредил или просто добавил шум. Это также помогает в post-incident review и в генерации будущих данных для обучения.

Human-in-the-loop

Human-in-the-loop не означает, что агент слаб; это означает, что система выстроена вокруг ответственности. SRE по-прежнему владеют инцидентом, rollback, влиянием на клиентов и финальным решением, когда контекста не хватает. Агент должен снижать toil и ускорять реакцию, а не создавать ложное чувство безопасности.

Лучший human-in-the-loop подход — пропорциональный. Низкорисковые задачи вроде сводки инцидентов или сбора dashboard можно автоматизировать. Среднерисковые действия, такие как перезапуск worker, могут требовать легкого одобрения. Высокорисковые действия вроде draining core capacity или отключения крупной зависимости должны оставаться под контролем человека. Такой progressive model позволяет доверию расти постепенно, а не требует опасного прыжка к полной автономии.

Стратегия оценки

Если проверять агента только на игрушечных benchmark, вы получите игрушечную надежность. Реальная оценка SRE должна воспроизводить исторические инциденты и измерять, правильно ли агент определил сигналы, выбрал гипотезу и рекомендовал безопасное remediation в реалистичных условиях. Подход Google использует непрерывные evaluation pipelines, human-verified gold data и nightly evals на реальных траекториях инцидентов, чтобы измерять готовность к автономным действиям.

Практическая программа оценки должна включать:

• воспроизведение исторических инцидентов;
• сравнение golden path и failure path;
• тесты на misuse инструментов;
• тесты на prompt injection и adversarial input;
• стресс-тесты на loops и retries;
• ручной разбор крайних случаев;
• отслеживание регрессий при изменении модели и policy.

Главный показатель — не «звучала ли модель правильно?». Вопрос в другом: сократила ли система время до mitigation, уменьшила ли toil и избежала ли нового operational risk?

Режимы отказа

Agentic SRE-системы ломаются не так, как классическое ПО. Они могут галлюцинировать root cause, неверно читать telemetry, слишком доверять устаревшему контексту, зацикливаться на сломанном действии или оптимизировать неправильную цель, при этом звуча уверенно. В среде с высокими ставками это опаснее простого бага, потому что система может успеть подействовать до того, как люди поймут, что она ошиблась.

Основные failure modes, против которых нужно проектировать систему:

• Confident incompleteness, когда агенту не хватает ключевого контекста, но он все равно дает категоричный ответ.
• Runaway loops, когда tool calls повторяются и съедают время или бюджет.
• Unsafe actuation, когда внешне корректное действие вредно в текущем operational state.
• Workflow drift, когда агент обходит установленные incident processes.
• Hidden fragility, когда скорость растет, а подотчетность падает.

Хорошая архитектура исходит из того, что сбои будут, и делает систему безопасной, заметной и обратимой.

Если нужен более подробный guide для сравнения AI SRE tools, можно посмотреть buyer’s guide от одного из senior leaders.

Операционная модель

Лучший способ внедрять agentic SRE — рассматривать его как ограниченного операционного партнера. Начинайте с read-only сценариев вроде alert enrichment, сводки инцидентов и помощи в investigation. Затем переходите к recommendation-only workflows, потом к low-risk automation и только позже — к строго ограниченной autonomous mitigation.

Такой поэтапный rollout должен сочетаться с дисциплиной policy, ownership и incident review. Каждое действие агента должно быть привязано к ответственной команде, ограниченной возможности и видимому audit trail. Так система одновременно заслуживает доверие инженеров, security-команд и руководства.

Вывод

Надежные agentic системы для SRE не предполагаются — они строятся. Рабочая формула включает grounded telemetry, явные guardrails, человеческий контроль, explainable reasoning и оценку на грязной реальности production-инцидентов. Когда все это есть, AI становится усилителем надежности, а не еще одним источником операционного риска.

Реальная цель — не полностью автономный агент, который никогда не ошибается. Реальная цель — agentic система, которая остается безопасной, когда ошибки все же происходят, аккуратно восстанавливается и сохраняет контроль у SRE-команды именно тогда, когда это важнее всего.

Эта статья опубликована в рамках Foundry Expert Contributor Network.Хотите присоединиться?

Материал — перевод статьи с английского.

Оригинал: How to teach SRE AI agents to fail safely and earn your team’s trust

Сгенерировать аудио

Три года назад партнер Sequoia Дэвид Канн был одним из первых, кто просчитал и оценил последствия колоссальных расходов Кремниевой долины на инфраструктуру ИИ.

В 2023 году он исходил из того, что годовая выручка Nvidia от GPU составляет $50 млрд. Отталкиваясь от этой цифры и добавляя предполагаемые затраты на эксплуатацию дата-центров и маржу их операторов, он пришел к выводу, что для окупаемости первоначальных вложений потребуется $200 млрд выручки.

Он воспринял это как вызов и предложил предпринимателям придумать продукты и сервисы ИИ, которые будут использовать всю эту инфраструктуру и приносить на ней доход. Перенесемся в сегодняшний день: с учетом трех лет гипермасштабирования Канн получил новую оценку расходов на инфраструктуру ИИ на 2026 год — $1,5 трлн.

В сумме, по его расчетам, индустрии ИИ нужно будет заработать $3 трлн, чтобы оправдать все эти чипы и другие расходы на дата-центры. И это, вероятно, заниженная оценка: рост цен на память и увеличение использования экзотических или специализированных для inference чипов поднимут эту сумму еще выше. «В последнее время, — пишет он, — требуемая выручка на каждый ГВт CapEx резко выросла из-за этих узких мест и роста стоимости строительства».

На другой стороне баланса, как считается, Anthropic достигла $60 млрд ARR, а OpenAI, по сообщениям, заработала $13 млрд в 2025 году (хотя в ноябре 2025 года компания заявляла о $20 млрд ARR) и, вероятно, заработает больше в этом году. Но разрыв между необходимой и фактической выручкой все равно остается большим.

Следит за этим разрывом Торстен Слок, главный экономист Apollo, крупного управляющего активами. В недавней записке он указывает, что гиперскейлеры — Google, Meta, Microsoft и Amazon — все прогнозируют резкое ускорение свободного денежного потока в 2028 году. Иными словами, они рассчитывают увидеть отдачу от всех тех чипов, которые купили.

Image Credits:Torsten Slok/Apollo

А что если этого не произойдет? Слок отмечает риск, который уже виден в использовании ИИ: все больше организаций переходят на более дешевые open weight-модели, часто китайские, а не на модели frontier labs, и цены на токены в целом снижаются. Последняя модель OpenAI, по словам CEO Сэма Альтмана, на 54% эффективнее по токенам в задачах кодинга. Для пользователей, которые переживают за стоимость своих AI agents, это хорошая новость, но для компаний, строящих «фабрики токенов», это может быть плохой новостью, если пользователи не начнут резко наращивать общий объем потребления токенов.

Image Credits:Torsten Slok/Apollo

Слок опасается, что если гиперскейлеры не достигнут своих целей по cash flow, реакция рынка может быть жесткой —

«при такой большой ставке на так мало имен, — пишет он, — более медленная окупаемость была бы не просто проблемой для сектора, она могла бы подтолкнуть экономику к рецессии, а S&P 500 — к коррекции».

Просто о чем стоит помнить, подталкивая своих AI agents к более дешевым токенам.

_При покупке по ссылкам в наших материалах мы можем получить небольшую комиссию. Это не влияет на нашу редакционную независимость._

Материал — перевод статьи с английского.

Оригинал: Can AI answer the $3 trillion question?

Сгенерировать аудио

OpenAI закрывает Atlas — браузер с ИИ, который компания запустила в октябре и построила вокруг ChatGPT. Но от идеи, что ИИ должен помогать людям работать с вебом, компания не отказывается: она переносит некоторые agentic-браузинг функции, протестированные в Atlas, в десктопное приложение ChatGPT и расширение для Google Chrome.

Решение закрыть Atlas последовало через несколько месяцев после того, как Fidji Simo, CEO по приложениям в OpenAI, призвала команду сократить число «побочных проектов». Это, в свою очередь, привело к закрытию ИИ-инструмента для генерации видео Sora.

Большую часть прошлого года ИИ-индустрия вела борьбу за то, чтобы сместить Chrome с позиции основного места, где люди проводят время онлайн. Perplexity выпустила Comet, The Browser Company — Dia, а Google и Microsoft обновили соответственно Chrome и Edge новыми функциями на базе ИИ.

После нескольких месяцев экспериментов OpenAI, похоже, пришла к выводу, что браузер — это функция, а не конечная цель. Поэтому компания встраивает возможности агентного браузинга из Atlas в те места, где люди уже работают, — и это включает Chrome.

OpenAI запускает расширение ChatGPT для Chrome, которое получает доступ к контексту открытой страницы, позволяет задавать вопросы о веб-страницах, суммировать содержание или запускать более длинные задачи прямо из браузера. Оно напрямую конкурирует с Gemini Side Panel от Google, который выполняет несколько похожих задач.

OpenAI также усиливает десктопное приложение ChatGPT, добавляя более мощный браузер, который позволяет пользователям переходить на сайты, входить в аккаунты, скачивать файлы и взаимодействовать с веб-страницами, не выходя из ChatGPT. Отдельный cloud browser работает удаленно на серверах OpenAI и служит местом, где агенты приложения могут выполнять задачи от имени пользователя.

Вместе эти обновления превращают ChatGPT в непрерывное рабочее пространство, которое охватывает Chrome, десктопное приложение и ИИ-агента.

Материал — перевод статьи с английского.

Оригинал: OpenAI is shutting down Atlas, but its AI browser ambitions are still growing

Сгенерировать аудио

Новый релиз добавляет мультиагентные сценарии, параллельное выполнение и встроенное управление, пока компании ищут способы выйти за пределы AI-помощников по коду и ускорить поставку ПО.

Компании используют ИИ для написания кода больше, чем когда-либо; по разным оценкам, от 25% до 75%. Это означает, что разработчики смещаются в другие части процесса, где сталкиваются с новым набором проблем.

Ранее в этом году IBM вывела на рынок agentic-платформу IBM Bob для разработки ПО, чтобы помочь разработчикам на всем протяжении жизненного цикла разработки ПО (SDLC), а не только в отдельных интерфейсах или изолированных задачах.

Чтобы развить платформу, в четверг IBM объявила о серии обновлений, включая новые мультиагентные возможности, параллельный вызов инструментов и встроенную аналитику затрат и использования. Компания также объявила о трех специализированных workflows, ориентированных на модернизацию Java, операционную систему IBM i и мейнфрейм-архитектуру IBM Z.

«Главное отличие IBM Bob в том, что IBM не строила его как очередного точечного ассистента по коду», — сказал Michael Kwok, вице-президент IBM Bob. «Рыночный разговор сместился от “какая модель пишет код быстрее?” к “какая платформа помогает предприятиям поставлять ПО безопасно, повторяемо и экономично на всем жизненном цикле?”»

По его словам, Bob рассчитан на более широкую задачу: понимание сложных систем, планирование изменений, выполнение работ, проверку результатов и предоставление руководителям видимости в части использования, governance и затрат. «IBM Bob поддерживает работу вокруг кода так же, как и сам код», — сказал он.

Новые возможности Bob

Bob, который стал доступен по всему миру в апреле, внедряет agentic ИИ во весь процесс разработки: discovery, planning, design, coding, testing, deployment и operations. Он предлагает разные режимы на основе ролей — «Agent», «Plan», «Ask», — повторно используемые playbooks и принудительное соблюдение стандартов.

Bob может вызывать инструменты для выполнения разных задач и распределять их между разными моделями, например IBM Granite или Anthropic’s Claude, в зависимости от требований к стоимости, производительности и точности. Он также может запускать несколько задач одновременно, каждая в своем потоке. С точки зрения безопасности он сканирует чувствительные данные, применяет политику в реальном времени и включает red-teaming прямо в workflows разработки.

«Работа над enterprise-софтом редко сводится к одному запросу или одному файлу», — сказал Kwok, отметив, что обычно требуются поиск по репозиторию, анализ зависимостей, тестирование, security review, документация и человеческое утверждение. «Bob координирует эту работу, а не заставляет разработчиков вручную собирать ее по частям», — сказал он.

Теперь, вместо того чтобы запускать все по отдельности, Bob может параллельно вызывать нативные для моделей инструменты и выполнять их одновременно. По словам IBM, задача, которая раньше занимала 30 секунд, теперь может выполняться за 10 секунд или меньше, что снижает потребление токенов на задачу. Размер контекстного окна также больше: 270K токенов против 200K в V1.

Кроме того, Bob может подключать subagents для выполнения разведывательных шагов. Когда агенту нужно выполнить самодостаточную задачу, например «понять, как работает аутентификация в этом кодовой базе», он поднимает subagent, который читает файлы, проводит анализ и выявляет паттерны. Затем основной агент получает сводку, а промежуточные шаги удаляются, говорит IBM. Это помогает избежать разрастания контекстного окна.

Параллельный вызов инструментов сокращает время ожидания в задачах, которые распадаются на поиски, чтение файлов и проверки, пояснил Kwok, а subagents очищают основной контекст, изолируя разведочную работу и возвращая краткие сводки.

«Смысл не в том, что Bob может делать больше вещей одновременно; смысл в том, что Bob может координировать их так, чтобы это оставалось понятным, повторяемым и проверяемым», — сказал он.

«Bobalytics» дает важные метрики

Кроме того, Bob теперь оснащен «Bobalytics» — инструментом видимости и оптимизации затрат для команд, который помогает сохранять контроль, отслеживать использование и распределять ресурсы.

«Цель — помочь предприятиям понять не только то, насколько активно используется ИИ, но и создает ли он значимую ценность», — сказал Kwok.

По его словам, Bobalytics построен вокруг нескольких представлений. Например, администраторам нужно видеть использование лицензий, потребление, элементы управления governance и видимость активности, а менеджерам — понимать «паттерны на уровне команды», например, кто начинает использовать Bob, какие workflows дают ценность и где командам может понадобиться помощь.

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

Специализированные пакеты Bob

IBM десятилетиями предлагала способы помогать предприятиям модернизировать мейнфреймы, Java codebases и OS. Теперь компания переносит этот накопленный опыт в три преднастроенных, настраиваемых workflows для модернизации Java, IBM i и IBM Z. По словам компании, они «структурированные, повторяемые, проверяемые и созданные под конкретные задачи».

Bob for Java modernization помогает командам мигрировать с Java 8 или более ранних версий на Java 11, 17, 21 или 25, выявляя проблемы совместимости, анализируя зависимости, координируя обновления кода и конфигурации и выполняя другие важные задачи.

Например, разработчик может попросить Bob оценить приложение для обновления версии Java. Bob может проверить систему сборки, проанализировать зависимости, изучить использование framework, выявить проблемы совместимости, прочитать логи, понять покрытие тестами и предложить план обновления. Теперь он выполняет эти задачи параллельно, а subagents могут заниматься точечными исследованиями «без загрязнения основного контекста разговора», сказал Kwok.

Bob for IBM i предлагает отобранные навыки и agentic workflows, оптимизированные для IBM i OS. Это включает рефакторинг «монолитных» приложений в более модульные современные структуры, создание документации, подготовку unit tests и генерацию разных типов кода (COBOL, DDS, CL, RPG) для разработчиков. Кроме того, режим «IBM i database mode» позволяет Bob имитировать опытного инженера по базам данных.

Мейнфрейм-среды традиционно были крайне сложны для интеграции ИИ, и IBM утверждает, что впервые приносит AI-native модернизацию приложений на IBM Z, включая модернизацию COBOL и PL/I и анализ job control language (JCL).

Bob for IBM Z предлагает повторно используемые навыки; специализированные режимы, которые позволяют адаптироваться к разным задачам, например рефакторингу кода или анализу архитектурного влияния, а также возможность писать код, читать файлы и выполнять команды.

Например, разработчик может спросить: «Какое влияние окажет изменение этого поля?» — и Bob сможет использовать анализ и метаданные, специфичные для Z, чтобы рассуждать по программам, copybooks, JCL, потокам данных и взаимодействиям подсистем, отметил Kwok. Subagent может исследовать одну часть системы, кратко изложить релевантные выводы и вернуть только то, что основному агенту нужно для продолжения планирования или выполнения изменения.

Java, Z и i — это среды с разными допущениями по runtime, языками, схемами интеграции, требованиями к governance и операционными ограничениями, сказал он, добавив, что доменная экспертиза IBM — «ключевое отличие».

В итоге IBM со временем расширит платформу и на другие capabilities, завязанные на workflows, отметил он, — туда, где «специализированные workflows могут существенно улучшить реальную поставку ПО».

IBM Bob — не «просто еще один copilot»

IBM Bob — это не очередной copilot, прикрученный к вашей integrated development environment, сказал Shashi Bellamkonda, principal research director в Info-Tech Research Group. Скорее, он «встраивает безопасность, тестирование и governance в шаг генерации, так что код приходит уже проверенным, а не попадает на reviewers, которые и были узким местом».

Нормализация prompt-ов блокирует небезопасные инструкции в момент их написания, чувствительные данные сканируются, а секреты обнаруживаются в реальном времени, а enforcement политики идет непрерывно на протяжении всего жизненного цикла кода, отметил он. Вместо человеческой команды модели выбирает Bob, а встроенные и кастомные модели позволяют разработчикам переходить между planning, coding и review без переключения инструментов. Кроме того, интеграция Model Context Protocol (MCP) подключает Bob к существующим toolchains.

Большинство AI coding tools обычно работают одинаково: генерируют код в coding tool, вставляют его в integrated development environment (IDE), а затем тратят время на исправление того, что сломалось, отметил Bellamkonda.

В итоге разработчики пишут много кода и теряют часы, гоняясь за багами. Затем код попадает в production, где каждая строка все равно должна пройти security review, testing и compliance. И хотя, например, AWS Kiro требует спецификацию до появления кода, а затем тестирует код по ней, AWS Transform идет с другой стороны — модернизирует старый код и в непрерывном цикле убирает technical debt.

«IBM Bob работает на той же стадии, но встраивает проверки в саму генерацию», — отметил Bellamkonda.

«Вся отрасль в этом году пришла к одному выводу: если просто прикрутить ускоритель к неизмененному pipeline, узкое место сместится вниз по цепочке», — сказал он. «Инструменты отличаются только тем, где именно они встраиваются».

Материал — перевод статьи с английского.

Оригинал: IBM Bob expands beyond code generation to orchestrate the entire SDLC

Сгенерировать аудио

Представляем ChatGPT Work — агент в ChatGPT, который помогает брать на себя более амбициозные задачи. Он может собирать информацию из ваших приложений и рабочих процессов, чтобы создавать готовые материалы вроде таблиц, слайдов, документов и веб-приложений, а также работать с комплексными проектами часами, разбивая их на более мелкие шаги и выполняя их самостоятельно.

С встроенной технологией Codex ChatGPT теперь может выходить за рамки ответов на вопросы и выполнять реальную работу в web, mobile и desktop. Более 5 миллионов человек используют Codex каждую неделю. Хотя он начинался как coding-агент для разработчиков, более 1 миллиона человек теперь используют его для задач вне software development, что показывает: его возможности подходят для гораздо более широкого круга работ.

Чтобы лучше управлять такими задачами, ChatGPT Work работает на нашей новейшей frontier-модели GPT-5.6, которая тоже начинает развёртываться сегодня. GPT-5.6 делает ChatGPT одним из лучших решений для рассуждений в многошаговых задачах и для создания материалов, которые соответствуют вашим шаблонам и reference files.

Лучший способ понять, как использовать ChatGPT Work, — дать ему задачу, которую вы и так хорошо знаете: проанализировать отклонение бюджета по итогам месяца, превратить исходные материалы в brief для marketing campaign или подготовиться к sales meeting. Вы можете следить за ходом работы, отвечать на вопросы, менять направление и подтверждать важные действия.

Вы даже можете попросить ChatGPT Work взять на себя целый workflow одним запросом. Например, он может превратить customer research в campaign brief, на его основе создать marketing assets и адаптировать эти материалы под разные рынки, сохраняя контекст на каждом шаге.

Даже когда вы не за компьютером или телефоном, ChatGPT Work может продолжать продвигать проекты с Scheduled Tasks. Например, он может самостоятельно превращать новые сообщения из Microsoft Teams и Slack в обновлённые документы или слайды, а затем делиться важными изменениями с вашей командой.

В раннем тестировании мы увидели, как ChatGPT Work расширяет возможности пользователей:

1 из 4

Почти 100% команд внутри OpenAI, включая finance и sales, теперь используют ChatGPT Work и Codex, чтобы работать быстрее, браться за более сложные задачи и проводить больше времени с клиентами.

• В sales ChatGPT Work превратил discovery conversation в tailored proof of concept для критически важной проблемы за 24 часа — процесс, который обычно занимает недели. ChatGPT структурировал заметки, направил запрос solutions architect и работал с technical team, освободив лида для общения с клиентом и роли высокоценного consultative partner.
• В finance ChatGPT Work сократил month-end close и forecasting с нескольких дней до нескольких часов, помогая командам находить исходные данные, переносить их в Excel или Sheets, сверять, собирать слайды и проверять результаты. Это позволяет finance-команде больше времени уделять анализу того, что изменилось в forecast, объяснению причин и рекомендациям руководителям, что компании делать дальше.

Работайте откуда угодно. Ещё больше возможностей на desktop.

ChatGPT Work создан так, чтобы задачи двигались вперёд, где бы вы ни находились. Вы можете попросить его начать задачу с телефона, проверить черновик на ходу или узнать статус долгого workflow между встречами. Когда вы вернётесь за рабочий стол, вы сможете продолжить ту же работу в web.

Для ещё более мощного сценария desktop-приложение ChatGPT теперь умеет больше. На desktop ChatGPT может использовать ваши локальные файлы и приложения, чтобы выполнять работу. Для web-задач новый встроенный browser в ChatGPT позволяет подтягивать сайты, инструменты и онлайн-файлы, объединяя всё в одном месте, чтобы двигать работу вперёд.

Создавайте слайды, таблицы, документы и Sites из своих приложений и workflows

Чтобы начать работать с ChatGPT Work, подключите инструменты и контекст там, где ваша работа уже происходит, используя plugins.

Plugins соединяют ChatGPT с приложениями и системами вроде Slack и Microsoft Teams, Google Drive и SharePoint, почтой, календарями, CRM, системами для отслеживания проектов и другими внутренними инструментами. ChatGPT будет автоматически понимать, когда ссылаться на plugin на основе вашего запроса, но вы также можете указать ему брать контекст из конкретного приложения, введя “@” и затем имя приложения в запросе. Новый объединённый каталог plugins собирает их в одном месте, а ChatGPT может предлагать подходящие варианты во время разговора.

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

Мы также запускаем Sites в ChatGPT в публичной beta-версии. С помощью Sites вы можете превратить свою работу или идеи в интерактивный сайт или web app и поделиться им с командой или публично через URL. Sites полезны, когда нужно создать live dashboards, project trackers, launch calendars, prototypes, internal portals и interactive reports. Вы можете тестировать созданные Sites прямо внутри ChatGPT и также подтягивать в проект свежий web-контекст. ChatGPT может обновлять их по мере изменения базовой информации.

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

ChatGPT Work помогает убрать повторяющиеся задачи с вашего плеча, освобождая время для более значимой работы.

Scheduled Tasks позволяют попросить ChatGPT выполнить действие один раз, повторять его по расписанию или при наступлении события, а также отслеживать изменения во времени.

Scheduled Tasks могут использовать подключённые приложения и browser, чтобы:

• Еженедельно просматривать новые обновления в Slack и обновлять повторяющуюся повестку встречи.
• Каждое утро проверять сайты и dashboards, кратко пересказывать, что изменилось, и отправлять отчёт.
• Отслеживать новые отзывы клиентов и превращать повторяющиеся темы в приоритизированные идеи для продукта.
• Обновлять презентацию, когда по email приходит новая обратная связь.

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

Выполняйте задачи быстрее в web и desktop-приложениях

На desktop ChatGPT теперь включает встроенный browser, который помогает собирать информацию онлайн, использовать web-инструменты и дорабатывать web-материалы в одном месте.

Вы можете попросить ChatGPT исследовать рынок, сравнить источники, извлечь информацию с сайтов или открыть и доработать файлы из Google Workspace и Microsoft 365 прямо в приложении. Browser помогает ему приносить свежий контекст, выполнять шаги на разных страницах и не останавливать работу, пока вы проверяете и направляете результат.

На desktop функция Computer Use позволяет ChatGPT использовать ваш компьютер от вашего имени, чтобы выполнять задачи в фоне в приложениях, инструментах и browser — нажимая, печатая и перемещая файлы туда, где они нужны. Вы можете использовать её для разовой задачи или как часть Scheduled Task, если повторяющаяся работа включает действия на вашем компьютере.

Мы также обновляем наше расширение Chrome, чтобы можно было использовать ChatGPT прямо в боковой панели Chrome. Эти возможности основаны на том, чему мы научились с Atlas и от пользователей, помогавших нам понять, как agentic tools могут делать работу в browser полезнее. Мы начнём выводить отдельный browser Atlas из эксплуатации и сообщим пользователям, как перейти на ChatGPT.

От целей к реальным результатам в каждой команде

ChatGPT Work сразу готов к разным видам работы: он может поддерживать сложные workflows, используя приложения, файлы и инструменты, которые каждая команда решает подключить. Ниже приведены реальные сценарии, которые мы видели в командах:

Sales: продавцы могут поддерживать актуальный live command center по мере изменения активности по аккаунту, не перестраивая account plans вручную. ChatGPT Work может синтезировать новые сигналы, обновлять следующие шаги и помогать продавцам тратить больше времени на продвижение сделок.[Пример запроса: Создайте автоматизацию, которая отслеживает новую активность по аккаунту и обновляет этот сайт каждый день в 8:00]

Безопасность и управление для организаций

Auto-review добавляет ещё один уровень защиты, используя наши самые продвинутые модели для проверки важных действий с подключёнными инструментами и APIs до того, как они произойдут, помогая предотвратить несанкционированную передачу конфиденциальной информации. Во время adversarial red teaming auto-review заблокировал 100% попыток извлечь защищённые данные, включая атаки, которых проверяющая модель не видела во время обучения.

Доступность и цены

Если вы уже используете приложение Codex, вы можете обновить его как обычно, и оно станет новым desktop-приложением ChatGPT. Разработчики могут сделать Codex экраном по умолчанию при открытии desktop-приложения и выбрать логотип Codex в качестве значка приложения. Desktop-проекты Codex останутся доступны на ходу через мобильное приложение ChatGPT. Текущая версия desktop-приложения ChatGPT будет переименована в ChatGPT Classic.

Что дальше

Это первый шаг к более широкой концепции ChatGPT — где интеллект выходит за рамки ответов на вопросы и помогает каждому превращать свои самые смелые идеи в реальность.

Материал — перевод статьи с английского.

Оригинал: ChatGPT is now a partner for your most ambitious work