ИИ над аналитикой: как Bayer упростила разбор результатов и сбоев

Что объявлено: агентный интерфейс поверх действующей платформы

Согласно сообщению AWS, Bayer Crop Science создала Agentic Decision Engine, или ADE, поверх Connected Decision Engine — CDE. Базовая система развёртывает, координирует и контролирует процессы машинного обучения, сохраняя историю выполнения. Она работает с данными геномики, полевых испытаний, изображениями и условиями окружающей среды.

По мере распространения CDE узким местом стало понимание происходящего. Ответы приходилось собирать из разных источников. ADE принимает вопрос на естественном языке: управляющий агент определяет тему, направляет запрос профильному агенту и объединяет результаты, если вопрос затрагивает несколько областей.

В промышленной эксплуатации работают 22 специализированных агента. Одни объясняют предметные понятия, другие получают текущий статус процессов, анализируют телеметрию или готовят визуализации. Система использует Amazon Bedrock AgentCore, а собственная оркестрация Bayer построена на LangGraph.

AWS приводит пример диагностики сбоя процесса фенотипирования. Агент обращается к телеметрии и API CDE, находит место отказа и возвращает объяснение. По сообщению компании, такая диагностика теперь занимает менее 10 минут вместо более часа ручного поиска и ожидания инженера.

Подготовку и эксплуатацию сопровождали специалисты AWS Unified Operations. При этом архитектурные решения оставались за Bayer. Запуск ограничили выбранной группой; с момента запуска ADE воспользовались более 100 сотрудников, включая селекционеров, аналитиков, исследователей и инженеров.

Бизнес-сценарий: помощник для объяснения, а не замена системы

Редакционное предложение для бизнеса — применить похожий подход там, где сотрудникам трудно разобраться в уже работающей аналитике. Начинать стоит не с автономного управления процессами, а с ограниченного помощника, который объясняет статус задания, происхождение результата и доступные сведения об ошибке.

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

Такой сценарий не предполагает, что ИИ сам исправляет процесс или меняет настройки. Его задача — сократить путь от вопроса до проверяемого контекста. Это редакционная рекомендация по применению подхода, а не описание дополнительной функции Bayer или обещание аналогичных результатов.

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

Ограничения и контроль: правильный ответ важнее успешного запроса

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

Доступ разграничен по назначению агента. Агент диагностики читает необходимые эксплуатационные данные, но не изменяет процессы. Агент предметных знаний обращается к своему поисковому индексу, но не получает доступ к посторонним API. Ответы опираются на извлечённые данные CDE и телеметрию.

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

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

Стоимость команда анализирует на уровне агентов и запросов. По данным AWS, кеширование стабильной части промпта снизило затраты на входные токены на 20–30%. Этот показатель относится к ADE; он не означает такого же снижения полной стоимости другого внедрения.

Практический чек-лист: что проверить перед пилотом

Ниже — редакционный чек-лист по мотивам кейса. Он предназначен для обсуждения с владельцами аналитики, службой поддержки и командой безопасности. Его цель — заранее определить границы ответственности и способ проверки ответов, а не воспроизвести архитектуру Bayer целиком.

• Соберите типовые вопросы пользователей и укажите для каждого источник ответа: документацию, статус выполнения, журнал или метаданные.
• Ограничьте инструменты областью задачи. Для объяснения ошибок начните с чтения данных без права изменять процессы.
• Проверьте отдельно полномочия пользователя, агента и вызываемого сервиса. Опишите действия при отказе доступа.
• Оценивайте выполнение задачи и соответствие ответа источникам, а не только отсутствие технической ошибки.
• Измеряйте стоимость взаимодействия, фиксируйте неразрешённые вопросы и предусмотрите передачу обращения человеку.
• Начните с ограниченной группы пользователей. Перед расширением проверьте нагрузку, совместимость модели и видимость сбоев.

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

Сцена по теме: Работа с корпоративной аналитикой →