Портативні бізнес-онтології для ШІ-агентів

Термін «онтологія» нині на часі. Чому? Агентам і великим мовним моделям (LLM), на яких вони працюють, потрібен релевантний контекст бізнесу.

Перш ніж погоджуватися на онтологію, запитайте постачальника: «Як наші працівники можуть виправити онтологію, якщо вона неправильно описує наш бізнес, і що й надалі залежатиме від вас?» Відповідь багато розповість про те, чию модель бізнесу ви купуєте. Вона також вказує на ширші ставки: вашу здатність удосконалювати цю модель у міру змін у бізнесі й зберегти цінність цих інвестицій, якщо ви зміните платформу.

Варто розрізняти онтологію та граф знань, хоча вони часто перетинаються.

Онтологія: які види речей існують, що означають зв’язки між ними та які правила діють. Обладнання, компоненти, команди, ролі, процеси. Наприклад, онтологія може визначити тип «Обладнання» та зв’язок «Містить» із типом «Компонент». Тоді граф знань може зафіксувати твердження: «Насос 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.

Але під час вилучення даних можуть закріпитися й помилки. Команди можуть використовувати різні назви для тієї самої сутності, створюючи дублікати. Джерела можуть суперечити одне одному або застарівати. Навіть чисте джерело LLM може неправильно витлумачити. Те, що такі помилки виглядають авторитетно, не робить їх менш небезпечними.

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

Ризики продуктів для роботи з онтологіями

По-перше, остерігайтеся негнучких моделей. Прагнучи запропонувати рішення, у якому «все необхідне вже є», постачальник може зробити власні сутності повноправними, водночас обмеживши можливості ваших. Самої лише можливості налаштування замало, якщо користувацькі типи не підтримують пошук, перевірку або виконання дій.

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

Найбільший ризик — прив’язати бізнес-процеси до платформи, з якої неможливо перейти. Ваша онтологія описує ваш бізнес: його знання, процеси та зв’язки. Інвестиції в упорядкування даних і бізнес-логіку мають залишатися корисними, навіть якщо ви зміните інструменти. Чому постачальник має право замикати все це на ключ?

Коли корисні векторні подання графів

Коли графи знань стають дуже великими, варто розглянути інструмент або постачальника, що підтримує векторні подання графів. Вони близькі до семантичних векторних подань, на яких працює багато RAG-застосунків. Варто зважити на дві корисні переваги.

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

По-друге, моделі векторних подань можуть ранжувати можливі відсутні зв’язки. Те саме навчання може виявляти закономірності в атрибутах і зв’язках, характерних для певного типу сутностей, допомагаючи побудувати повніший граф.

На користь поступового вдосконалення

Як розпочати, не маючи цілої армії інженерів, які працюють безпосередньо на місцях, — щоб самостійно визначати власний шлях, уникнути залежності від постачальника й моделювати реальний бізнес, а не його карикатуру, нав’язану постачальником? На мою думку, саме тут сучасний ШІ розкриває свій потенціал — якщо інструменти забезпечують шлях від виявлення до перевірки.

Спершу скористайтеся автоматизованими засобами для виявлення й вилучення інформації. На основі ділових документів, політик, електронних листів або повідомлень у Slack можна створити початкове уявлення про певну предметну область. Важливо, що вважати його точним не можна, доки його не перевірено.

Другий етап — перевірка. Ваші інструменти мають забезпечувати зручний перехід від вилучених кандидатів до тверджень, підтверджених джерелами, а також до знань, перевірених відповідальною особою або авторитетною системою. Зберігайте джерело кожного твердження.

Підтримання актуальності — це безперервна робота. Процес опрацювання заявки до служби підтримки чи відповідь на запитання «Скільки магазинів у Нью-Джерсі?» сьогодні можуть відрізнятися від тих, що були три роки тому. Але оновлення сучасних знань не має стирати вчорашню реальність. Час фіксації факту й період, до якого він стосувався, можуть не збігатися; корисна онтологія має давати змогу отримувати як актуальні відповіді, так і точне уявлення про минуле. Хтось однаково має стежити за актуальністю цих знань.

Масштаб може бути величезним. Почніть із меншого корпусу даних, змоделюйте корисну предметну область і поступово створюйте цілісну картину, водночас забезпечуючи цінність на кожному етапі.

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

Обмеження добре ілюструє Common Service Data Model від ServiceNow. У білій книзі CSDM 5 йдеться: «Якщо ці дані не містяться у визначених таблицях, ви можете не отримати всіх переваг платформи ServiceNow AI Platform». Саме це застереження створює обмеження для проєктування й експлуатації: пристосуватися до моделі постачальника або прийняти на себе ризик. А що, як для цього доведеться втискати круглий кілок у їхній квадратний отвір?

А тепер уявімо, що платформа для онтологій також забезпечує завантаження даних, перетворення, дії та бізнес-правила. Можливо, вам вдасться експортувати сутності, атрибути й зв’язки. Але чи зможете ви також перенести перетворення та конвеєри дій, які вносять зміни у ваші бази даних, викликають вебхуки й спричиняють інші побічні ефекти? Через тісно пов’язані інтеграції прив’язаним до платформи може опинитися сам бізнес.

Чому гнучкість важлива саме зараз

Програмне забезпечення поглинає світ, а ШІ — програмне забезпечення. Команди використовують ШІ і для розроблення програмного забезпечення, і для забезпечення його роботи, тож дедалі більше бізнес-логіки може прив’язуватися до цих платформ. Кожна корисна автоматизація може стати ще однією залежністю, яку доведеться враховувати під час міграції. Небезпечно дозволяти постачальнику ставати на заваді вашій гнучкості.

Висновки

Неймовірно, що ми живемо саме в такий час! Не дивно, що люди досліджують онтології, аби надавати агентам контекст. Розширення цього контексту на процеси й інтеграції може створити реальну цінність. Повернімося до початкового запитання. Завдяки виправленням ваших працівників модель має точніше відображати ваш бізнес. Накопичене розуміння надто цінне, щоб втратити його під час переходу на іншу платформу. Та й загнати себе в глухий кут зараз було б особливо недоречно.