На конференции AI Dev 25 в Нью-Йорке эксперты компании SAP, Ларс Хелинг и Кристоф Мейер, представили инновационный подход к управлению ИИ-агентами в корпоративной среде. В центре их решения — использование технологий графов знаний (Knowledge Graphs) для устранения разрыва между сложными бизнес-процессами и способностью нейросетей корректно вызывать нужные API.
🤖 Бизнес-копилот в мире сложных ERP-систем 0:41
Ларс Хелинг и Кристоф Мейер (SAP Business AI) работают над внедрением искусственного интеллекта во все решения SAP — от управления ресурсами предприятия (ERP) до цепочек поставок . Главным интерфейсом для взаимодействия пользователя с этими системами стал Joule — бизнес-копилот, способный автоматизировать задачи в области HR, закупок и финансов .
Однако под капотом Joule лежат не просто чат-боты, а автономные ИИ-агенты. По словам Хелинга, их основная задача — захватывать контекст из множества различных решений SAP и выполнять на его основе сложные бизнес-сценарии . В этой архитектуре граф знаний SAP занимает центральное место между облаком данных и ИИ-модулем, выполняя роль «переводчика», который делает информацию пригодной для действий агента .
🧩 Почему агенты «ломаются» на обычных API 2:47
Основная проблема современных ИИ-агентов в бизнесе заключается в сложности ИТ-ландшафта. Хелинг приводит пример: пользователь просит Joule заказать пять карандашей для определенной закупочной группы . Если просто дать агенту доступ ко всем API системы ERP, он, скорее всего, не справится.
Выделяются две ключевые проблемы:
- Сложность обнаружения API (Discovery): В современных облачных системах (например, S/4 HANA Public Cloud) может быть более 3500 сервисов API и свыше 110 000 конечных точек (endpoints) . Метаданные фрагментированы, а терминология перегружена акронимами. Например, сокращение PO в одном контексте означает Product Owner, а в другом — Purchase Order (заказ на закупку) .
- Контекст бизнес-процессов: API не существуют в вакууме. Их нельзя вызывать в случайном порядке. По мнению Хелинга, последовательность вызовов определяется жесткой бизнес-логикой . Например, прежде чем создать заказ (Purchase Order), система может требовать создания заявки на закупку (Purchase Requisition), или проведения проверки на отмывание денег перед открытием счета .
🧠 Граф знаний как фундамент для RAG 6:58
Граф знаний представляет собой структуру данных, состоящую из «триплетов»: субъект, предикат и объект (например, «SAP — находится в — Вальдорфе») . Однако его истинная мощь, как утверждает Хелинг, заключается в онтологии .
- Семантика и иерархия: Онтология позволяет задать правила. Если SAP — это компания, а компания — подкласс организации, агент понимает иерархию сущностей .
- Логический вывод (Inference): Если граф знает, что «SAP находится в Вальдорфе», а «Вальдорф находится в Германии», он может автоматически вычислить, что SAP находится в Германии, даже если этот факт не прописан явно .
Для обучения агентов SAP использует многослойный граф метаданных. Он включает слои обнаружения ресурсов, спецификации API (OpenAPI, MCP) и, что самое важное, слой бизнес-процессов (BPMN), который связывает разрозненные инструменты в единую логическую цепочку .
🛠️ Демонстрация: как граф «дообучает» агента на лету 11:38
Кристоф Мейер продемонстрировал работу агента на примере 100 «игрушечных» API. Традиционный подход с векторным поиском (RAG) часто выдает неполный результат: на запрос о создании заказа он может найти API для заказа, но «забыть» про обязательный предварительный шаг — API для заявки .
Решение от SAP — улучшенное обнаружение (Enhanced Discovery):
- Сначала выполняется классический векторный поиск по текстовому описанию .
- Затем система обращается к графу знаний, чтобы найти все входящие и исходящие связи (процессы) для найденных API .
- В итоге агент получает не просто список инструментов, а полную «дорожную карту» процесса .
В ходе демо Мейер показал, как легко исправлять ошибки агента, просто добавляя новые узлы в граф. Когда агент не понимал, что статус «Active» соответствует техническому коду «02», разработчики просто добавили это сопоставление в граф знаний . При повторном запросе агент мгновенно подхватил контекст и сформировал правильный фильтр для API .
⚖️ «Широкие инструменты» против SQL-подхода 27:33
SAP применяет стратегию «широких инструментов» (Broad Tools). Вместо того чтобы регистрировать по одному инструменту на каждый из тысяч API, агенту дают три базовых инструмента: для обнаружения API, для получения спецификаций и для выполнения запросов (GET/POST) . Это решает проблему оркестрации, так как ИИ не перегружен огромным количеством функций в промпте .
Отвечая на вопрос из зала о том, почему нельзя использовать обычный SQL с джоинами (joins) для тех же целей, Хелинг пояснил:
- Сложность логики: В крупных компаниях бизнес-логика и правила доступа (permissions) зашиты в слои выше SQL. Прямое обращение к таблицам сделало бы задачу агента невыполнимой из-за чрезмерной сложности структур данных .
- Безопасность и роли: Уровни API в SAP уже включают в себя проверку полномочий, которую опасно и сложно обходить на уровне «сырых» запросов к базе данных .
По прогнозам спикеров, использование графов знаний станет стандартом для масштабируемых ИИ-агентов, так как это единственный способ обеспечить прозрачность (traceability) — возможность всегда отследить, откуда именно агент взял те или иные метаданные для принятия решения .
