Переносимые бизнес-онтологии для ИИ-агентов

Термин «онтология» сейчас в моде. Почему? Агентам и лежащим в их основе большим языковым моделям нужен релевантный контекст бизнеса.

Прежде чем решиться на внедрение онтологии, спросите поставщика: «Если онтология неверно описывает наш бизнес, как наши сотрудники смогут это исправить — и от чего мы по-прежнему будем зависеть от вас?» Ответ многое расскажет о том, чью модель бизнеса вы приобретаете. Он также укажет на более важные ставки: сможете ли вы совершенствовать эту модель по мере изменений в бизнесе и останутся ли полезными вложения в нее, если вы смените платформу.

Полезно различать онтологию и граф знаний, хотя зачастую они пересекаются.

Онтология: какие виды объектов существуют, что означают связи и какие правила применяются. Оборудование, компоненты, команды, роли, процессы. Например, онтология может определить тип «Оборудование» и отношение «Содержит» к типу «Компонент». Затем в графе знаний можно зафиксировать утверждение: «Насос P-101 содержит уплотнение S-7» — две конкретные сущности и связь между ними.

Представьте, что вы просите агента: «Рассчитай рост продаж сопоставимых магазинов, но покажи мне рядом два варианта: сначала по всем магазинам, затем по магазинам, которые открыты не менее 2 лет; после этого разбей оба варианта на внутренний рынок, международные рынки и общий показатель».

Для этого нужны сведения, которые агент не может угадать:

• какие магазины существуют и когда они открылись
• где они находятся
• внутреннее определение понятия «продажи сопоставимых магазинов»

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

Онтология должна связывать эти магазины с политикой, определяющей порядок расчета. Поиск связанных фактов полезен, но именно применение правильного правила делает ответ ценным.

Прежде чем ответить на вопрос, агент может использовать связи в графе для извлечения релевантного контекста. И неудивительно, что такие возможности полезны: области знаний легко могут стать очень сложными.

Рисунок 1. Граф объединённых общедоступных моделей SysML: TMT Thirty Meter Telescope (Open-MBEE/JPL, Apache-2.0), CubeSat System Reference Model (© 2022 INCOSE SSWG & OMG SDTF, CC BY 4.0), Architecting Spacecraft with SysML (Friedenthal & Oster, BSD-2-Clause), а также содержимое вымышленного созвездия MDC и общедоступные спецификации (IS-GPS-200, IS-GPS-705, GSFC-STD-7000B). Визуализация выполнена в Kamiwaza Kaizen.

Но извлечение данных может также закреплять ошибки. Команды могут использовать разные названия для одной и той же сущности, создавая дубликаты. Источники могут противоречить друг другу или устаревать. Даже верно составленный источник большая языковая модель может неверно истолковать. Если представить такие ошибки как достоверные сведения, они не станут менее опасными.

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

Риски, связанные с продуктами для работы с онтологиями

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

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

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

Когда помогают графовые эмбеддинги

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

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

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

В пользу постепенного совершенствования

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

Для начала используйте автоматический поиск и извлечение данных. На основе деловых документов, правил, электронной почты или сообщений в Slack можно составить первоначальное представление о предметной области. Главное — не считать его точным, пока оно не проверено.

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

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

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

Служба поддержки клиентов — один из полезных сегментов: входящие звонки, электронные письма, система учёта заявок, автоматическое решение проблем, команда поддержки, которая может отвечать клиентам, и возможность передавать настоящие ошибки инженерам. Такой сегмент связывает знания с действиями и позволяет изучить те же риски и преимущества в управляемом масштабе.

Общая модель данных сервисов ServiceNow показывает, в чём заключается ограничение. В белой книге CSDM 5 предупреждают: «Если эти данные не размещены в предписанных таблицах, вы можете не получить всей ценности платформы ServiceNow AI Platform». Это предупреждение само по себе создаёт ограничения при проектировании и эксплуатации: следовать модели поставщика или принять на себя риск. А что, если это означает, что придётся втискивать круглую деталь в квадратное отверстие?

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

Почему гибкость важна именно сейчас

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

Выводы

Удивительное время, чтобы жить! Неудивительно, что люди изучают онтологии, чтобы дать агентам необходимый контекст. Расширение этого контекста на процессы и интеграции может принести реальную пользу. Вернёмся к вопросу, с которого мы начали. Исправления, внесённые вашими сотрудниками, должны помогать модели точнее отражать ваш бизнес. Эти накопленные знания слишком ценны, чтобы потерять их при смене платформы. И сейчас как никогда легко оказаться загнанным в угол.