# Как SAP учит ИИ-агентов понимать сложные бизнес-процессы с помощью графов знаний Источник: https://www.youtube.com/watch?v=XrYwFUdu2lk Канал: DeepLearning.AI Опубликовано: 03.12.2025 --- На конференции AI Dev 25 в Нью-Йорке эксперты компании SAP, Ларс Хелинг и Кристоф Мейер, представили инновационный подход к управлению ИИ-агентами в корпоративной среде. В центре их решения — использование технологий графов знаний (Knowledge Graphs) для устранения разрыва между сложными бизнес-процессами и способностью нейросетей корректно вызывать нужные API. ## 🤖 Бизнес-копилот в мире сложных ERP-систем [[JUMP:00:41]] Ларс Хелинг и Кристоф Мейер (SAP Business AI) работают над внедрением искусственного интеллекта во все решения SAP — от управления ресурсами предприятия (ERP) до цепочек поставок [01:09]. Главным интерфейсом для взаимодействия пользователя с этими системами стал Joule — бизнес-копилот, способный автоматизировать задачи в области HR, закупок и финансов [01:37]. Однако под капотом Joule лежат не просто чат-боты, а автономные ИИ-агенты. По словам Хелинга, их основная задача — захватывать контекст из множества различных решений SAP и выполнять на его основе сложные бизнес-сценарии [01:51]. В этой архитектуре граф знаний SAP занимает центральное место между облаком данных и ИИ-модулем, выполняя роль «переводчика», который делает информацию пригодной для действий агента [02:32]. ## 🧩 Почему агенты «ломаются» на обычных API [[JUMP:02:47]] Основная проблема современных ИИ-агентов в бизнесе заключается в сложности ИТ-ландшафта. Хелинг приводит пример: пользователь просит Joule заказать пять карандашей для определенной закупочной группы [02:47]. Если просто дать агенту доступ ко всем API системы ERP, он, скорее всего, не справится. Выделяются две ключевые проблемы: 1. **Сложность обнаружения API (Discovery):** В современных облачных системах (например, S/4 HANA Public Cloud) может быть более 3500 сервисов API и свыше 110 000 конечных точек (endpoints) [04:33]. Метаданные фрагментированы, а терминология перегружена акронимами. Например, сокращение PO в одном контексте означает Product Owner, а в другом — Purchase Order (заказ на закупку) [04:08]. 2. **Контекст бизнес-процессов:** API не существуют в вакууме. Их нельзя вызывать в случайном порядке. По мнению Хелинга, последовательность вызовов определяется жесткой бизнес-логикой [04:59]. Например, прежде чем создать заказ (Purchase Order), система может требовать создания заявки на закупку (Purchase Requisition), или проведения проверки на отмывание денег перед открытием счета [05:27]. ## 🧠 Граф знаний как фундамент для RAG [[JUMP:06:58]] Граф знаний представляет собой структуру данных, состоящую из «триплетов»: субъект, предикат и объект (например, «SAP — находится в — Вальдорфе») [07:26]. Однако его истинная мощь, как утверждает Хелинг, заключается в онтологии [07:54]. * **Семантика и иерархия:** Онтология позволяет задать правила. Если SAP — это компания, а компания — подкласс организации, агент понимает иерархию сущностей [08:08]. * **Логический вывод (Inference):** Если граф знает, что «SAP находится в Вальдорфе», а «Вальдорф находится в Германии», он может автоматически вычислить, что SAP находится в Германии, даже если этот факт не прописан явно [09:03]. Для обучения агентов SAP использует многослойный граф метаданных. Он включает слои обнаружения ресурсов, спецификации API (OpenAPI, MCP) и, что самое важное, слой бизнес-процессов (BPMN), который связывает разрозненные инструменты в единую логическую цепочку [10:20]. ## 🛠️ Демонстрация: как граф «дообучает» агента на лету [[JUMP:11:38]] Кристоф Мейер продемонстрировал работу агента на примере 100 «игрушечных» API. Традиционный подход с векторным поиском (RAG) часто выдает неполный результат: на запрос о создании заказа он может найти API для заказа, но «забыть» про обязательный предварительный шаг — API для заявки [15:35]. Решение от SAP — **улучшенное обнаружение (Enhanced Discovery)**: * Сначала выполняется классический векторный поиск по текстовому описанию [17:36]. * Затем система обращается к графу знаний, чтобы найти все входящие и исходящие связи (процессы) для найденных API [17:48]. * В итоге агент получает не просто список инструментов, а полную «дорожную карту» процесса [18:52]. В ходе демо Мейер показал, как легко исправлять ошибки агента, просто добавляя новые узлы в граф. Когда агент не понимал, что статус «Active» соответствует техническому коду «02», разработчики просто добавили это сопоставление в граф знаний [24:11]. При повторном запросе агент мгновенно подхватил контекст и сформировал правильный фильтр для API [25:03]. ## ⚖️ «Широкие инструменты» против SQL-подхода [[JUMP:27:33]] SAP применяет стратегию «широких инструментов» (Broad Tools). Вместо того чтобы регистрировать по одному инструменту на каждый из тысяч API, агенту дают три базовых инструмента: для обнаружения API, для получения спецификаций и для выполнения запросов (GET/POST) [28:43]. Это решает проблему оркестрации, так как ИИ не перегружен огромным количеством функций в промпте [29:10]. Отвечая на вопрос из зала о том, почему нельзя использовать обычный SQL с джоинами (joins) для тех же целей, Хелинг пояснил: * **Сложность логики:** В крупных компаниях бизнес-логика и правила доступа (permissions) зашиты в слои выше SQL. Прямое обращение к таблицам сделало бы задачу агента невыполнимой из-за чрезмерной сложности структур данных [35:05]. * **Безопасность и роли:** Уровни API в SAP уже включают в себя проверку полномочий, которую опасно и сложно обходить на уровне «сырых» запросов к базе данных [35:19]. По прогнозам спикеров, использование графов знаний станет стандартом для масштабируемых ИИ-агентов, так как это единственный способ обеспечить прозрачность (traceability) — возможность всегда отследить, откуда именно агент взял те или иные метаданные для принятия решения [28:17].