Why Agents Need Ontology

📖 Источник: agentblueprint.substack.com

Почему агентам нужна онтология

Введение

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

Онтология vs схема vs модель данных

Ключевое заблуждение — путать онтологию с привычными понятиями из мира данных. Схема (schema) описывает, какие поля существуют в таблице и какие типы данных они содержат. Модель данных (data model) отражает, как информация хранится внутри отдельных систем. Онтология объясняет смысл этих полей и то, как они связаны во всём бизнесе — независимо от конкретной реализации в том или ином инструменте.

Когда агент ищет информацию о клиенте, онтология позволяет ему понять, что customer_id в Stripe, email в системе поддержки и контакт в Salesforce — это один и тот же реальный человек. Без онтологии агент видит лишь изолированные таблицы и не способен установить такие связи самостоятельно.

Три кита онтологии: сущности, связи и определения

Онтология строится из трёх фундаментальных элементов, которые вместе создают полную картину того, как работает бизнес.

Сущности (Entities) — это реальные объекты, которые имеет значение для бизнеса: клиенты, продукты, заказы, тикеты, контракты. Важно понимать: сущности — это не таблицы баз данных, а бизнес-пононятия. Одна сущность может существовать как когерентный объект в нескольких системах, даже если каждая система хранит о ней информацию по-разному.

Связи (Relationships) описывают, как сущности соединяются между собой. Этот клиент владеет этим аккаунтом. Этот тикет связан с этим заказом. Связи кодируют бизнес-логику, которая нигде не прописана в схемах, но существует повсюду в том, как люди реально работают. Именно эти связи превращают набор данных в модель бизнеса.

Определения (Definitions) закрепляют, что означают термины в конкретном контексте компании. Каждая компания определяет ключевые понятия по-разному. Например, one company может рассчитывать self-serve revenue, умножая расходы за последний месяц на двенадцать. Другая использует среднее значение за последние три месяца. Оба подхода валидны, но они разные. Онтология делает такие определения явными, чтобы агенты рассуждали последовательно и одинаково интерпретировали данные.

Семантический слой и онтология: в чём разница

Эти два понятия постоянно путают, хотя они служат принципиально разным целям. Семантический слой (semantic layer) помогает аналитикам генерировать отчёты, предоставляя согласованное представление о данных для бизнес-аналитики. Он построен для людей, которые смотрят на дашборды.

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

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

Большинство команд строят только семантиный слой, а затем удивляются, почему их агенты struggle with context — борются с контекстом.

Почему text-to-SQL провалились: урок истории

Сразу после запуска ChatGPT десятки компаний начали строить text-to-SQL инструменты. Обещание было простым: общайся с базой данных на обычном английском, задавай вопросы, получай мгновенные ответы. Многие из этих компаний уже закрылись.

Они не понимали, как данные соединяются между системами, и не осознавали роль онтологии. Инструменты отлично работали на CSV-файле с чётко определёнными колонками или на одном коннекторе с чистыми данными. Можно было подключиться к Shopify, увидеть все заказы, задать вопросы и получить разумные ответы.

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

Онтология в продакшене: граф знаний

В production-режиме онтология проявляется как граф знаний (knowledge graph) — живая сеть сущностей и связей, сшитых между системами. Граф знаний представляет ваш бизнес как связанные знания, а не изолированные таблицы.

Когда агенту нужно понять контекст клиента, он не запрашивает пять разных баз данных и не пытается собрать воедино найденное. Вместо этого онNavigate по графу знаний, где клиент уже существует как разрешённая сущность со всеми релевантными связями. Агент видит полную картину мгновенно.

Каждое серьёзное развёртывание агентов, которое я вижу, движется к графам знаний как фундаменту. Мы уже видели этот паттерн раньше. Базы данных были мощными, но потребовалась современная data stack, чтобы сделать их удобными в масштабе. Графы знаний следуют по тому же пути. Базовая технология существует. Инфраструктура для практического применения всё ещё появляется. Мы всё ещё выявляем лучшие паттерны для поддержания графов знаний в масштабе.

Практические шаги: как начать строить онтологию

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

Второе — отобразите связи между сущностями. Клиенты имеют аккаунты, аккаунты имеют контакты, контакты открывают тикеты, тикеты связаны с продуктами. Запишите эти связи явно. Это создаёт entity intelligence — понимание того, как ваши бизнес-объекты связаны друг с другом между системами. Без этого агент извлекает разрозненные фрагменты вместо связного контекста.

Третье — определите неоднозначные термины явно. Выручка означает разное в разных бизнесах. Активный клиент определяется конкретными критериями. Лид становится возможностью в определённый момент вашего процесса. Эти определения часто существуют как институциональные знания, но редко формализуются. Для агентных систем они критически важны, потому что агенты должны рассуждать из согласованного понимания ваших бизнес-сущностей и их связей.

Сложность — не в том, чтобы определить эти понятия один раз. Сложность в том, чтобы поддерживать их актуальность по мере развития бизнеса. Пока нет идеального ответа на вопрос версионирования онтологии в масштабе. То, что работает сейчас: treat ontology as code — рассматривайте онтологию как код, с контролем версий, ревью и процессами деплоя, аналогичными другим инфраструктурным изменениям.

Заключение

Риски: Без онтологии агенты обречены на провал в production. Они будут получать разрозненные данные из разных систем и не смогут установить связи между ними. Типичный сценарий: вы загружаете Stripe charges в контекст, но у агента нет способа получить информацию о клиенте. Агент не может определить, кому принадлежат эти платежи, и что известно об этом человеке в других системах. Он действует вслепую.

Перспективы: Команды, которые начнут строить онтологию сейчас, получат огромное преимущество. Агенты с онтологией распознают одного и того же клиента в Stripe, Salesforce и системе поддержки, рассуждают на основе связной картины вместо разрозненных фактов. Они меньше ломаются, лучше обрабатывают edge cases и действительно доходят до production, а не застревают в демо.

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

📢 Информация предоставлена телеграм-каналом: Data&AI Insights

🤖 Data&AI Insights - Ваш источник инсайтов о данных и ИИ