Онтология может стать решением проблемы непонимания бизнес-контекста ИИ-агентами

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

Проблема смыслового разрыва в данных

Хотя интеграции управляются хорошо с помощью технологий вроде API-менеджмента и Model Context Protocol (MCP), обеспечить истинное понимание «смысла» данных в контексте конкретного бизнеса — совсем другая история. Корпоративные данные в основном разрознены между различными системами в структурированной и неструктурированной формах и требуют анализа через призму предметной области бизнеса.

Например, термин «клиент» может относиться к разным группам людей в CRM-системе продаж по сравнению с финансовой системой, где этот тег используется для платящих клиентов. Один отдел может определять «продукт» как SKU; другой — как семейство продуктов; третий — как маркетинговый пакет.

Данные о «продажах продуктов» таким образом различаются по смыслу без согласованных отношений и определений. Чтобы агенты могли комбинировать данные из нескольких систем, они должны понимать различные представления. Агентам нужно знать, что означают данные в контексте и как найти правильные данные для правильного процесса. Более того, изменения схем в системах и проблемы качества данных при сборе могут привести к дополнительной неопределенности и неспособности агентов знать, как действовать в таких ситуациях.

Кроме того, классификация данных по категориям вроде PII (персонально идентифицируемая информация) должна строго соблюдаться для поддержания соответствия стандартам вроде GDPR и CCPA. Это требует корректной маркировки данных и способности агентов понимать и уважать эту классификацию. Следовательно, создание крутого демо с использованием агентов вполне осуществимо — но вывод в продакшн с работой на реальных бизнес-данных — совсем другая история.

Онтология как единый источник истины

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

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

Онтология может быть реализована с использованием общедоступных запрашиваемых форматов вроде triplestore. Более сложные бизнес-правила с многошаговыми отношениями могут использовать размеченные графы свойств вроде Neo4j. Эти графы также могут помочь предприятиям открывать новые отношения и отвечать на сложные вопросы. Онтологии вроде FIBO (Finance Industry Business Ontology) и UMLS (Unified Medical Language System) доступны в публичном достоянии и могут быть хорошей отправной точкой. Однако их обычно нужно кастомизировать для захвата специфических деталей предприятия.

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

Практическая реализация онтологического подхода

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

Агенты, спроектированные таким образом и настроенные на следование онтологии, могут придерживаться ограничений и избегать галлюцинаций, которые могут быть вызваны большими языковыми моделями (LLM), питающими их. Например, бизнес-политика может определять, что пока все документы, связанные с кредитом, не имеют установленных флагов проверки в «true», статус кредита должен оставаться в состоянии «ожидание». Агенты могут работать вокруг этой политики и определять, какие документы нужны, и запрашивать базу знаний.

Вот пример реализации. Как показано на иллюстрации, у нас есть структурированные и неструктурированные данные, обрабатываемые агентом документного интеллекта (DocIntel), который заполняет базу данных Neo4j на основе онтологии бизнес-домена. Агент обнаружения данных в Neo4j находит и запрашивает правильные данные и передает их другим агентам, обрабатывающим выполнение бизнес-процессов. Межагентская коммуникация происходит с помощью популярного протокола вроде A2A (agent to agent). Новый протокол под названием AG-UI (Agent User Interaction) может помочь строить более универсальные UI-экраны для захвата работы и ответов от этих агентов.

Источник: venturebeat

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

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

По материалам VentureBeat