Форма онтології проти розміру моделі: скільки коштує проектування графа для штучного інтелекту.

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

Вище показано три варіанти форматування однієї бази фактів — загалом 2 435 фактів. Кожна панель є справжнім підграфом, взятим з даних експерименту, який демонструє, як кожна онтологія представляє сусідство саме цих трьох страхових вимог. У плоскому форматі структура розміщена всередині властивостей, тому майже ніщо не пов’язане між собою. У нормалізованому форматі кожен факт є окремим вершином: нічого не бракує, проте ніщо не має назви. У форматі з формами кожна ентитет має позначення, а кожна грань — назву. Агент, модель та база даних залишаються ідентичними у всіх трьох варіантах, а лише форма змінюється.

По-перше, кілька слів про дані. Усе в них вигадано: люди, компанії, місця та страховик походять із сконструйованих списків слів із фіксованим початковим даним, тож ніщо з цього не відноситься до реальних об’єктів. Значення показників отримано під час реальних запусків у Sweden Central. Міркування відбувалися на спеціалізованій інфраструктурі Microsoft Foundry, знання зберігалися у рахунку Azure Cosmos DB для Apache Gremlin, а кожен виклик інструменту був запитом Gremlin до живої графи. Усього це дало 480 епізодів роботи агентів, 4,3 мільйона токенів та суму 8,09 доларів. Перший проходження тієї ж сітки, під час якого інструменти читали файли-генератори замість бази даних, коштувало 7,74 долара; його називають перевіркою. Усі наведені цифри походять з кампаній Cosmos, а перевірка використовується лише тоді, коли два запуски разом показують щось, чого не міг показати один запуск.

Шар, який ніхто не оновлює

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

Майже ніхто не розглядає справжній матеріал — форму знань, які були надані агенту. На мить забудьмо про факти. Запитаймося, чи є коригувальник вузлом чи рядком у JSON-об’єкті, чи містить ребро значення assessed_by чи просто related, та чи потрібно для переходу від заявки до страхувальника один крок чи п’ять.

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

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

Три форми однієї істини

Областю тестування є страхова система з полісоутримувачами, полісами, формами страхування, заявками на відшкодування, експертами, постачальниками ремонтних послуг, оплатами та регіонами. Скрипт, який був запущений один раз, створив усе це, отримавши 2 435 канонічних фактів щодо 507 ентитетів, кожен з яких є вигаданим.

З цієї однієї бази фактів походять три онтології. Називати їх трьома наборами даних було б неправильно; це три форми одних і тих самих даних, які підпорядковуються єдиному правилу: кожна версія мусить переформулювати факти без додаткових змін та без втрат. Щоб це забезпечити, скрипт аналізує кожну створену графіку, відновлює факти та перевіряє, чи результат точно збігається з вихідними даними. Версія, яка містила б на один факт більше чи менше, перетворила б цей процес на тест на повноту охоплення даних. Система CI у репозиторії виконує цю перевірку після кожного додавання коду до основної гілки та після кожної заявки на з’єднання, а також перевіряє, чи дані, які були збережені, збігаються байт за байтом із тими, що генерується на початковому етапі; експеримент вважається недійсним, якщо не пройдено обидві перевірки. Існує застереження щодо справедливості: конструкції типу Flat та Shaped були розроблені без урахування набору фактів, що робить їхні перевірки більш суттєвими, тоді як нормалізований граф кодується безпосередньо з фактів, тому за своєю суттю є безвтратнішим, ніж той, що отримується шляхом доведення.

Конструкція типу Flat зазвичай першою використовується багатьма командами, і вона передбачає лише два типи вузлів. Кожен вузол страхувальника зберігає свої поліси та умови страхування у вигляді JSON-об’єкта в одній властивості. Кожен вузол заявки так само містить інформацію про свого аудитора, постачальника та оплати. Єдиний універсальний тип ребра related пов’язує власників полісів із заявками, і це є основою всієї схеми. Уся інформація існує, але залишається прихованою.

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

Shaped розроблений з урахуванням споживача, який буде ним фактично користуватися. Типи вузлів мають чітку структуру, а кожна грань має напрямок, тип та назву, які мають певне значення, наприклад filed_against, assessed_by чи settles. Політики вказують на страхувальників за допомогою held_by, і ця сама назва використовується ще й з однією конкретною метою: дев’яносто похідних граней held_by, які йдуть від заявки безпосередньо до її страхувальника, що скорочує шлях від заявки до страхувальника до одного кроку. Повторне використання назви є навмисним, оскільки цей зв’язок однаково зрозумілий з обох боків, і агенту не потрібен додатковий словниковий запас. Ці дев’яносто граней мають позначку derived, не надають жодних додаткових даних та не враховуються у доведенні відсутності втрат, оскільки вони є результатом арифметичних операцій над вже існуючими фактами.

На рисунку 1 показано один тип взаємозв’язку — твердження та особа, яка його оцінює, — у всіх трьох форматах. У режимі «Flat» особа, яка оцінює, вбудовується як властивість JSON до твердження, і майже нічого не пов’язується. У режимі «Normalized» цьому взаємозв’язку надається власний вузол, дві ребра та окремий вузол атрибутів для кожного факту. У режимі «Shaped» просто називається ребро, і на панелі також пояснюється, чому існує цей окремий спрощений шлях. Скрипт реконструкції підтверджує, що всі три формати містять точно такі самі 2 435 фактів.

Кількість вузлів дає уявлення про структуру. Один набір істинних даних складає 130 вузлів у режимі «Flat», 507 у режимі «Shaped» та 2 942 у режимі «Normalized», причому кожен додатковий вузол — це можливий напрямок для подальшого аналізу.

Конкретна entitas показує різницю краще, ніж опис. Візьмемо поліс, який стане відомим завдяки цим результатам; кожна з версій насправді зберігає його у своєму форматі:

На рисунку 2 політика P-7009 отримується безпосередньо з файлів онтології, які були збережені, за допомогою скрипта генерації рисунків — тих самих файлів, що були завантажені до Cosmos, тож там точно показано шлях, яким пройшов агент. У режимі Flat політика зберігається у вигляді рядка всередині властивості страхувальника: вона існує, але не є вершиною та не може бути адресована. У режимі Normalized вона зберігається як проста вершина Resource, атрибути якої розташовані у окремих вершинах, що знаходяться на відстані двох кроків. У режимі Shaped зберігається вершина з визначеним типом та приєднаними до неї властивостями, а також краї, які від неї відходять. Страхова премія залишається однаковою у всіх трьох випадках, проте знаходиться на трьох різних відстанях від запитання.

Кожна форма знаходиться у власному контейнері графу всередині Azure Cosmos DB для Apache Gremlin, і саме його перетинає агент; кожен виклик інструменту перетворюється на операції перетину графу у режимі реального часу. Генератор створює базу фактів, завантажувач записує її до Cosmos, а механізм завантаження сам перевіряє дані: кількість вершин та ребер має збігатися з даними вихідного джерела, інакше фіксується неузгодженість замість того, щоб пізніше знайти неповністю створений граф.

Одна база даних, один шар інструментів та ідентичні стандартні налаштування індексування роблять ці конструкції порівнянними та забезпечують їхню видимість. Граф властивостей нічого не приховує. Якщо запитати його про те, що він знає, відповіддю буде сама структура даних.

У таблиці 1 наведено ті самі 2 435 фактів за кожною схемою, взятих з файлів графа. У форматі „Flat“ кількість вершин перевищує кількість ребер, причому п’ять вершин не мають жодних зв’язків. У нормалізованому форматі структура є однорідною та без слів. У форматі „Shaped“ зв’язки між елементами найкращі, а мітки використовують словниковий запас відповідної галузі.

Повернімося до формату „Flat“. Кількість вершин перевищує кількість ребер, а п’ять вузлів не мають жодних зв’язків; це абоненти без заявок, і за цією схемою ніщо інше у системі не пов’язане з ними. Це база даних графів, яка зберігає щось, що ледве можна вважати графом. Структура все ще існує, але вона була перетворена на 8,2 властивості на кожну вершину, тож вона поводиться як текст, а не як топологія. Результати залежать від цього вибору проектування, і база даних графів пропонує це як факт, а не як думку.

Нормалізований стовпець відображає це. Це найбільш однорідна з трьох діаграм: приблизно одна ребро на вершину, нічого ізольованого, 1,6 властивостей на вузол, оскільки процес реіфікації перетворює кожен факт на ті самі три базові елементи, які повторюються 2 942 рази. Структура є дуже насиченою, а лексикон відсутній – три позначення вершин та три позначення ребер охоплюють усю страхову діяльність.

З 1,36 ребер на вершину ця діаграма є найкраще з’єднаною, маючи вісім позначень вершин та дев’ять типів ребер. Різниця стає очевидною відразу, коли кожній діаграмі ставлять запитання про те, які типи елементів вона містить:

g.V().groupCount().by(label)

• У форматі Flat зберігаються лише інформація про заявку (90) та страхувальника (40).
• У нормалізованих звітах вказуються Ресурс (507), Атрибут (1834) та Відношення (601).
• У структурованих списках є вісім категорій: 216 – обсяг страхування, 90 – заявки, 75 – поліси, 59 – оплати, 40 – страхувальники, 12 – постачальники послуг, 10 – експерти та 5 – регіони.

Другий запит підраховує кількість полісів за категоріями:

g.V().hasLabel('policy').count()

У таблиці 2 одне запитання розміщено поруч із трьома відповідями. Обидва нулі є проявами різних видів невдач. У плоскій графіці просто не існує політики, яку можна було б знайти. У нормалізованій графіці політика існує, але не розкриває себе. У плоскій версії була втрачена сутність; у нормалізованій — сутність збереглася, але був втрачений словниковий запас, тому до політики можна дістатися лише шляхом пошуку, а не шляхом її найменування. Усе це не залежить від того, як саме зберігалися дані: три схеми, одна база даних, один запит.

Така ж дисбалансна ситуація виникає під час оцінки реалістичного запитання. У якому місті проживає страхувальник за полісом, пов’язаним із заявою C-31020? Кожна графіка відповідає Larkfield, оскільки всі вони містять однакові факти. Відрізняється лише шлях, яким до цього результату дістаються. У графіці з формованими елементами отриманий край скорочує цей шлях:

# shaped - the derived shortcut collapses the path
g.V().has('number','C-31020').out('held_by').values('city')

Плоскі та нормалізовані графіки потребують цього замість:

# flat - one hop, but only because claims and holders are the only two things
g.V().has('number','C-31020').in('related').values('city')# normalized - the same answer, five steps and two unwrappings later
g.V().has('value','C-31020').in('has')
     .in('subject').has('kind','filed_against').out('object')
     .in('subject').has('kind','held_by').out('object')
     .out('has').has('attr','city').values('value')

Flat обробляє це за один крок лише тому, що у цій схемі існують лише два типи елементів — запит та власник. Нормалізований підхід вимагає п’яти кроків та двох процедур розпакування. Агент ніколи не складає ці запити самостійно; він знаходить шлях, викликаючи інструмент по одному разу, і саме це є метою експерименту. Проте запити розкривають те, що виявляється, та кількість цих даних.

На рисунку 3 показано, що ідентичний запит виконується на всіх трьох графах у Cosmos DB Data Explorer. Незалежно від того, чи має граф два мітки, три мета-мітки чи описує домен власними словами, схеми не містять різних даних; вони містять один набір даних у різних формах.

На рисунку 4 у кожній діаграмі вибирається заява C-31020, і інструмент Data Explorer дозволяє визначити її сусідів. У плоскій діаграмі доступний лише один вершин — страхувальник, до якого можна дістатися через ребро, позначене як related. Агент AJ-09 та страховий поліс PL-043 видно у панелі властивостей, але у вигляді тексту, тож агент не може до них дістатися. У нормалізованій діаграмі з’являється вісім вершин, шість атрибутів та дві відношення; жоден з них не має назв у мові домену. У діаграмі з формою вершини мають назви — filed_against, assessed_by та held_by. Одна заява, одна база даних, три відстані.

Інструмент: чотири засоби та квитанція

Агента тримають у мінімальному обсязі навмисно, оскільки він не є об’єктом тестування. Це простий цикл виклику функцій, який працює з розгортанням моделі Microsoft Foundry, налаштований згідно з інструкціями Foundry щодо використання інструментів через API Chat Completions. Існує фіксований системний запит, ліміт у шістнадцять обертів моделі на запитання (після чого сеанс закінчується), а також чотири інструменти, які завершують роботу, причому їхні підписи є ідентичними у всіх трьох онтологіях.

На рисунку 5 показано повний обсяг обчислень: один ресурс Microsoft Foundry, який містить два розгортання моделей — agent-small, що працює з gpt-5.4-nano, та agent-large, що працює з gpt-5.5, обидві з категорії Global Standard. Назви та версії взяті з шаблону інфраструктури у репозиторії, тому за цими даними не приховано жодних інших ресурсів.

Чотири інструменти є наступними:

• find_nodes шукає властивості та ідентифікатори вузлів за підстрокою, обмежуючись двадцятьма знахідками
• get_node читає тип та властивості одного вузла
• traverse повертає до тридцяти сусідів вузла, які можна фільтрувати за типом кроку та напрямком
• describe_edges узагальнює інформацію про те, які кроки виходять з вузла чи входять до нього, та скільки їх кожного

Під капотом кожен інструмент перетворюється на Gremlin у Cosmos. get_node та find_nodes виконують по одній обходу — одне читання точки та один сканування, тоді як traverse та describe_edges потребують трьох обходів, оскільки спочатку перевіряють наявність вузла, а потім по черзі аналізують вихідні та вхідні ребра. Агент нічого з цього не записує. Він запитує про вузол або сусіда та отримує компактну відповідь у форматі JSON — це стандартний формат інтерфейсу інструментів для роботи з графовими базами даних, що також дозволяє тримати мову запитів окремо від моделі.

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

Три практичні уроки, отримані під час роботи з справжньою базою даних графів, які вимагали її перебудови. Cosmos не підтримує скрипти з кількома запитами, тому завантаження означає один обхід структури на кожен запит, а пропускна здатність досягається шляхом виконання багатьох запитів паралельно замість їх групування. Жорсткий таймаут у шістдесят секунд не дозволяє команді g.V().drop() видалити кілька тисяч вершин: вона зупиняється на півдорозі, залишаючи напіввидалену структуру графа, тому очищення відбувається поетапно. У рівні без сервера також існує верхня межа пропускної здатності, яка перетворює сплеск з сорока одночасних записів на таймаути, тому як інструмент завантаження, так і інструмент агента повторюють спроби з затримкою. Усе це не є чимось незвичайним, але саме це відрізняє базу даних графів у стані спокою від тієї, що працює під навантаженням.

Оцінювання без судді

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

Оскільки агент може діяти лише за допомогою своїх чотирьох інструментів, кожна відповідь супроводжується повним списком викликів, які її створили. У попередніх вимірюваннях маршрутизатора полем model був квитанційний запис; тут цим є шлях. Правильну відповідь можна простежити крок за кроком, а невдача точно показує, де форма втратила контроль над агентом.

На рисунку 6 показана схема роботи. Одна база даних фактів живить три безвтратні форми, які стають трема контейнерами графів у Azure Cosmos DB для Apache Gremlin, а окрема гілка живить оракула, який формує кожну правильну відповідь на основі тих самих фактів. Агент доходить до графів лише за допомогою чотирьох інструментів, виконуючи по одному запиту Gremlin за кожен виклик. Інструменти, цикли та запитання залишаються незмінними, тоді як форми змінюються, і кожен запуск генерує квитанційні записи: виклики інструментів, токени, час відгуку та вердикт оракула.

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

Вартість просування

Основна кампанія працювала з реальними графами Cosmos DB, використовуючи спеціалізовану інфраструктуру Microsoft Foundry у Центральній Швеції. Вона охоплювала три онтології, сорок запитань та три повні проходження з однією незмінною невеликою моделлю, що дало 360 епізодів, 3,1 мільйона токенів та сімдесят центів. Кожен виклик інструменту був запитом Gremlin. Друга кампанія, описана пізніше, повторює обробку з більшою моделлю протягом ще 120 епізодів за 7,39 долара. Скрипт у репозиторії обчислює всі наведені нижче цифри на основі записаних квитанцій, причому жодна з них не була введена вручну.

У таблиці 3 узагальнено результати кампанії: невелика модель, три проходження, 360 епізодів, запит Gremlin після кожного виклику інструменту. Зелений колір позначає найкращий результат у кожному рядку. Рядки, що стосуються ресурсів, навмисно залишені без кольору, оскільки їхній показник є найнижчим у всіх чотирьох категоріях, і, як покажуть наступні розділи, частина цієї економії використовується для оплати відповідей, яких так і не було надано.

Почніть зі зниження значень у першому рядку — це найменш інформативне число в таблиці. Метод „Shaped“ відповів правильно на 84,2% запитань, метод „Flat“ — на 78,3%, а метод „Normalized“ — на 59,2%. Проте під час трьох інших однакових тестувань точність цих методів змінилась на 0,075, 0,150 та 0,075 відповідно, тож шістьопунктна різниця між методами „Shaped“ та „Flat“ знаходиться в межах їхнього власного шуму, і за допомогою трьох тестувань неможливо визначити різницю у загальній точності між ними. Перевага у двадцять п’ять пунктів над методом „Normalized“ легко дозволяє проігнорувати цей шум.

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

У таблиці 4 пояснюється проблема з цим агрегованим показником. Форми графіка не відрізняються незначно скрізь; вони різко змінюються в кожному окремому діапазоні, і кожен діапазон ставить до графіка інші вимоги.

Спочатку розгляньмо пошук за одним фактом. Значення для „Shaped“ становлять 0,967, а для „Flat“ — 0,533, що дає різницю у сорок три пункти; при цьому рівень шуму становить 0,100 для першого та 0,200 для другого, тож сигнал є справжнім. Для пошуків через два та три етапи обидва підходи досягають значення 0,967. У найскладнішому випадку рівень шуму становить 0,300 та 0,400, що не дає можливості визначити переможця.

Отже, ці два підходи не є ані кращими, ані гіршими. Вони ламаються в різних місцях, і їх об’єднання в одне число приховує корисну інформацію. Коли потрібно щось знайти, підхід „Flat“ зазнає невдач та продовжує їх зазнавати. Коли агент вже має точку опори та потрібно лише просуватися далі, підхід „Flat“ працює так само добре, як і запроєктована структура графа.

Нормалізований підхід відображає схожу ситуацію, як видно з його показників: 0,867 під час пошуку, що перевищує показник „Flat“, оскільки кожна одиниця є справжнім вершином; потім значення знижуються до 0,467 та 0,133 у міру подовження шляху. Він знаходить все, але не завершує жодної задачі.

Як кожен підхід зазнає невдач

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

У таблиці 5 наведено помилки, що трапилися під час цих дев’яноста епізодів. Модель “Normalized” вичерпує свій бюджет ходів; модель “Flat” зупиняється рано та впевнено щодо запитань, на які база даних могла б дати відповідь.

Двадцять два з дев’яноста епізодів для моделі “Normalized”, тобто приблизно чверть, закінчувалися вичерпанням бюджету та припиненням роботи агента посеред процесу. Модель “Flat” рідко так робила – вона зупинялася рано та впевнено, відмовляючись від вісімнадцяти запитань, на які вже були відповіді в базі даних. Одна модель виснажується, а інша просто припиняє роботу.

Плоске збої є більш різкими, а сліди вказують на механізм, якого ніхто не очікував. Ось два реальні випадки. У обох випадках проситься доплата за поліс P-7009, і вони відрізняються лише тим, яка схема стоїть за інструментами:

flat                                       shaped
find_nodes "P-7009"          -> 1 hit:     find_nodes "P-7009" type=policy
   policyholder:PH-05 "Ivo Renner"            -> 1 hit: policy:PL-009 "P-7009"
find_nodes "7009"            -> 1 hit      get_node policy:PL-009
find_nodes "P-7009" type=policy       -> 0     -> premium 750
find_nodes "P-7009" type=policyholder -> 1 hit
ANSWER: NOT_MODELED                        ANSWER: 750

У структурованій графіці достатньо двох запитів. Запитайте про поліс за номером, отримайте відповідний вершину, прочитайте з неї суму страховки — і все готово.

У плоскій графіці ситуація інша. Перший пошук повернув вершину, так само як і другий. Третій запит містив параметр type=policy, але нічого не знайшов, оскільки така мітка відсутня в цій схемі. Четвертий запит містив параметр type=policyholder та дав результат. Отже, за типом агент знайшов саме ту вершину, яка містила відповідь, проте все одно оголосив дані відсутніми.

Цей преміум знаходився всередині того вершини, у певній властивості, за один виклик функції get_node. Протягом десяти епізодів з невдалими пошуками незфільтрований пошук знаходив вершину, яка містила цей преміум, п’ятнадцять разів, проте функція get_node виконувалась щодо неї нуль разів. На цій вершині була позначка „Іво Реннер“ — ім’я людини. У решті епізодів з невдалими пошуками ця позначка належала одному з двох інших страхувальників, а не самій страховій політиці, і ім’я людини не давало жодних підказок про те, що запитувана політика знаходиться всередині.

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

Нормалізація провалюється публічно та дуже дорого. Читання одного атрибута означає проходження через вузол Attribute, а відстеження однієї залежності — обхід через вузол Relation. У стовпці „Токени“ відображається вартість: 13 701 за кожне запитання проти 7 176 для формату „shaped“, а також 12,15 викликів інструментів проти 7,24. У 25 з 120 епізодів було досягнуто ліміту у 16 кроків, проти 3 у форматі „shaped“ та 2 у форматі „flat“; найскладніший варіант мав показник 0,133. У графі не бракувало нічого. Агент просто втрачав подих, перш ніж завершити речення.

Найдешевший варіант справді є найдешевшим, хоча це не є компліментом. Варіант „Flat“ коштує 0,109 долара за сто запитань проти 0,165 долара для варіанту „Shaped“, і навіть якщо врахувати точність, він все одно перемагає – 0,14 долара за сто правильних відповідей проти 0,20 долара. За цією моделлю варіант „Flat“ справді дешевший у використанні. Однак жодна ціна не може купити ті вісімнадцять відповідей, які він відхилив. Швидке припинення роботи коштує недорого, а невеликий рахунок при низькій сумі не є економією, що сама колонка з витратами ніколи не показує.

Парадокс відмови

Найкращий та найгірший варіанти міняються місцями у категорії невідповідних запитань після аналізу тих, на які можна було дати відповідь. Варіант „Flat“ правильно відхилив усі тридцять невідповідних запитань, що є єдиним ідеальним результатом у таблиці. Варіант „Shaped“ показав рівень 0,933 та нормалізований рівень 0,900, а його невдачі були пов’язані з тим, що у запитань закінчилися ходи, а не з вигадками.

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

Висновок проти цього дизайну

Один з результатів суперечить формату проектування, який підтримує експеримент, а друга кампанія ще більше його посилила. У форматі «shaped» існує лише один похідний скорочений шлях: held_by, який безпосередньо пов’язує заявку з її власником полісу. За питанням «заявка – місто власника» цей формат набрав 0,83, тоді як нормалізований варіант – 0,33; у той же час формат «flat» досяг 0,92 без жодних скорочень, оскільки в цій схемі є лише заявка та власник. Результат, який досягається форматом без елементів «edge», не можна приписувати саме цим елементам.

Ще гірше те, що відсутній шорткат коштував саме там, де це було очікувано. Підрахунок різних видів покриття в межах політик власника дав 0,17 у нібито добре спроєктованій графіці та 0,67 у плоскій, що дозволяє об’єднати їх у одну зрозумілу властивість. Сума виплат за претензіями власника становила 0,33. При агрегації в межах підграфа пропонований дизайн програє дизайну під назвою «broken». Денормалізація — це не компроміс проти хорошого дизайну, а його частина; крім того, формована графіка застосовувала власні принципи занадто обережно саме там, де це було необхідно через обсяг роботи.

Купування виходу за допомогою більшої моделі

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

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

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

Недостатньо добре сформовану онтологію можна компенсувати. Кошти становлять приблизно чотирнадцять разів більше, ніж вартість одного запитання: велика модель у форматі плоскої графики коштує 1,90 долара за сто запитань, а мала модель у форматі структурованої графики — тринадцять центів. Залиште плоску графіку та оновлюйте лише модель, яка працює в ній; тоді рахунок буде у двадцять разів вищим, ніж вартість тієї самої малої моделі у цьому форматі.

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

У всіх чотирьох категоріях порядок є більш чітким, ніж можна було б припустити, спираючись лише на підхід з чітко сформульованими запитаннями. З великою моделлю модель типу „формована“ досягла ідеального значення 1,000 у кожній категорії, включаючи ту, де запитання були нерозв’язними. Модель типу „плоска“ досягла значення 0,950, а нормалізоване значення — 0,825. Гроші лише частково забезпечують коректність, а рахунок залишається незмінним.

Що показала перевірка щодо обережності

Перевірка (той самий формат даних, ті самі запитання, інструменти, які читають файли замість Cosmos) дала найбільш тривожний результат у проекті, і він стосувався графіка форми. Коли агента запитали про погоду у день інциденту, яку онтологія навмисно не моделює, він відповів «пошкодження від граду». Він знайшов властивість cause заяви та представив її як погоду. На той момент це було зафіксовано як найнебезпечніший варіант проектування, що призвів до помилки, з застереженням, що це був лише один епізод під час однієї обробки даних — спостереження, а не вимірювання, без підстав для формулювання закону.

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

Отже, висновок полягає не в тому, що складні графіки спонукають до вигадок. Властивість причина з значенням „шкода від граду“ спокусить будь-яку модель, до якої ставлять запитання про погоду, незалежно від того, де вона зберігається, а форма, яка потрапляє в пастку, змінюється під час різних запусків. Це менша твердження, ніж те, що майже було зроблено, і саме це підтверджують докази. Це також означає, що небезпека не залежить від форми: якщо графік містить поле, яке виглядає як відповідь на щось, на що він насправді не відповідає, якась модель десь його передасть.

Нормалізована форма у обох моделях

У обох моделях спостерігалося загальне зниження рівня нормалізації. У меншій моделі цей показник був найнижчим, а у більшій він все одно становив 0,867 при відповідях на запитання, причому витрати склали 9,31 долара за сотню — майже в п’ять разів більше, ніж у моделі з простою структурою, крім того, вона сім разів закінчувала роботу без можливості продовжити. Ситуація з моделлю типу „реіфікація“ не покращується навіть із більшою моделлю, адже її проблемою ніколи не було розуміння — проблемою була відстань у обробці даних: п’ятнадцять викликів інструментів на запитання проти 8,3 у моделі з формованою структурою, причому остання ніколи не помилялась у розумінні інформації.

Формат нормалізованого даних не програв у всіх випадках, і саме цей виняток навчає найбільше. При пошуку за одним фактом нормалізований формат показав результат 0,867 проти 0,533 у форматі «плоскому»; при двох запитах, які робили неможливим використання формату «плоского», нормалізований формат явно був кращим: 0,83 проти 0,17 для показника страхової премії та 0,83 проти 0,33 для показника спеціалізації постачальника. Формат рефікації є надзвичайно дорогим, але нічого не приховує. Кожна сутність є вершиною, тож кожну сутність можна знайти.

Це підсумовує аргумент: кожен невдалий формат зберігав половину проблеми та відкидав іншу. Формат «плоский» зберігав відстані, але втрачав можливість адресації; нормалізований формат зберігав можливість адресації, але втрачав відстані. Кожен з цих форматів конкурує у тій частині, яку зберіг, і є безнадійним у іншій.

Shaped — це не компроміс між цими двома підходами. Він має значення 0,967 у діапазоні, що перевищує значення flat, та 0,967 у діапазоні, що перевищує значення normalized, тому він відкидає цей компроміс. Саме тут полягає його перевага, проте одне загальне значення точності повністю його приховує.

Затримка при роботі з реальною базою даних

Затримка — це показник, який не можна було перевірити за допомогою крос-перевірки. З файлами час виконання кожного запиту сильно коливався під час однакових проходжень: одна й та сама операція могла займати 1,17 секунди під час одного проходження та 4,21 секунди під час іншого, тому жодних даних не було надано, оскільки варіації в роботі сервісу переважали над особливостями онтології. У випадку Cosmos ситуація є більш упорядкованою, причому злегка зумовленою певними факторами.

У таблиці 7 показаний час виконання кожного запиту, який чітко розрізняє різні формати даних та залишається стабільним всередині кожного з них; водночас час виконання кожного запиту до інструменту є однаковим у всіх трьох випадках, що робить цю таблицю своєрідним підсумком кількості запитів до інструменту, вираженим у секундах.

У межах будь-якої однієї версії найбільша різниця становить сім секунд, тоді як різниця від простої до нормалізованої версії сягає майже п’ятдесяти секунд. Нормалізоване запитання виконується у два з половиною рази довше, ніж просте. Останній стовпець зменшує цей розрив: для кожного запиту всі три формати вимагають приблизно однакового часу — від 6,2 до 7,4 секунд, незалежно від схеми. Отже, це не є незалежним висновком. База даних забезпечує послідовність, адже час виконання операцій у Cosmos є прогнозованим, на відміну від ситуації з локальним словником, і саме це дозволяє взагалі надавати такі цифри.

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

Принципи та їх підтвердження

У написанні про проектування онтологій зазвичай пропонуються принципи як справа смаку. Більшість з наведених нижче мають номер, який їм присвоєно, а ті, у кого його немає, про це зазначають.

Усе, щодо чого можна поставити запитання, має бути вершиною. Якщо потрібно викарбувати один принцип над дверима, нехай це буде саме він. У плоскій моделі кожна страхова премія та спеціалізація постачальника з індексацією зберігаються в тій самій базі даних, що й усе інше, проте невелика модель ледве їх знаходила. Премії знаходилися у 17% випадків, а спеціалізації — у 33%, тоді як у моделі з формуванням результатів цей показник становив 100% та 83% відповідно. Повний діапазон значень — від 0,533 до 0,967. Приховування елемента всередині властивості іншого елемента не ускладнює його пошук; це лише змушує законний запит повертатися під іншою назвою, що агент сприймає як доказ відсутності цього елемента. Модель з перетином додає додаткову умову, оскільки модель фронтиру витягує їх усі. Приховування не є абсолютною перешкодою — це лише «податок», який потрібно сплатити на певному рівні моделі.

Гранулярність — це бюджет, а реіфікація швидко його споживає. Кожен доданий вузол заради чистоти схеми стягує плату за кожен візит. Порівняно з формованими даними, нормалізовані вимагали в 3,7 рази більше викликів інструменту для пошуку одного факту, у 2,3 рази більше — для коротких переходів, та в чотири рази більше токенів у випадку довгих шляхів; крім того, у 25 з 120 епізодів було досягнуто ліміту кількості поворотів, на відміну від 3 епізодів у іншому варіанті. Модель, ціна якої була у 25 разів вищою за один токен вхідних даних, підвищила рівень точності відповідей з 0,489 до 0,867. Це справжнє покращення, але його досягли за ціною 9,31 долара за сотню, що майже в п’ять разів більше, ніж коштувала та сама модель у звичайному варіанті. Відстань ніколи не є дешевою, незалежно від бюджету.

Точки входу — це архітектура, і вони сильно залежать від моделі. Кожне запитання починається з певної назви чи номера, і те, що повертає перший виклик інструменту, визначає, чи буде агент працювати, чи почне здогадуватися. Для невеликої моделі цей виклик повертав порожній результат у 10% епізодів з визначеною структурою, 26% епізодів без структури та 53% епізодів у нормалізованому вигляді, коли пошук завершувався на вершині Attribute, а не на сутності. Для передової моделі він ніколи не був порожнім, незалежно від структури. Отже, марна перша дія — це не лише властивість графа. Це те, що відбувається, коли слабша модель стикається з точкою входу, якої не очікувала. Створюйте інтерфейси для моделі, яка буде працювати в продакшені, а не для тієї, що використовується під час тестування.

Навмисно використовуйте денормалізацію та визнавайте це, коли результати не збігаються. Один з використаних швидких способів — held_by — був розроблений з надією на ефективність у сценарії «заява → власник». У цьому випадку його результат становив 0,83 проти 0,33 для нормалізованого варіанту, але у варіанті без швидкого способу результат склав 0,92, тому кредит надати не можна, і чистий тест (з врахуванням меж та без них) не було проведено. Відсутність цього швидкого способу дає більше корисної інформації. Підрахунок різних видів покриття за політиками власників дав результат 0,17 у добре спроєктованій структурі та 0,67 у простій структурі, що дозволяє об’єднати їх у одну зрозумілу властивість. Для агрегації даних у підграфі спроєктований варіант програв варіанту, позначеному як «несправний». Вибір швидких способів — це частина проектування, а обсяг роботи показує, які з них потрібні; у цьому випадку було обрано неправильний варіант, і дані це підтверджують.

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

Зробіть відсутність помітною та оцінюйте її чесно. Розглядайте сегмент, на який неможливо дати відповідь, як вимогу дизайну, а не як хитрість тесту, але розміщуйте його поруч із сегментом, на який можна дати відповідь. Flat отримав ідеальну оцінку 1,000 за відмови, відмовившись від вісімнадцяти запитань, на які міг би відповісти. Shaped відмовлявся найменше, і два випадки, коли він пропустив нерозв’язні запитання, закінчилися відмовою, а не вигадуванням чогось. Хороша онтологія дозволяє твердженню „ми не моделюємо це“ бути одночасно досяжним та правдивим, а оцінка потребує обох аспектів, щоб відрізнити граф, обізнаний про свої обмеження, від того, який не може знайти власний вміст.

Назви — це API. Агент читає назви елементів так само, як розробник читає сигнатуру функції, і в цьому експерименті назви та структуру навмисно об’єднують у одну змінну під назвою design. Жодне число саме по собі не підтверджує цей принцип. Очевидним наступним кроком є розділення цих двох аспектів, і зазначити це краще, ніж стверджувати більше, ніж було виміряно.

Що це не є

Це не є тестом продуктивності графових баз даних. Усі три варіанти використовують один обліковий запис Cosmos DB, один шар інструментів та однакові стандартні налаштування індексації, тому хранилище є константою, а не змінною, і ніщо не порівнює Cosmos із іншими графовими базами даних чи не налаштовує його. Також не стверджується, що лише перебір елементів є способом, яким агенти у продакшені повинні отримувати всю інформацію, адже нечіткі запити без чіткого точки входу потребують пошуку; результати показують, де простий перебір елементів є доцільним, а де — ні. У тексті немає аргументів проти нормалізації в транзакційних системах, оскільки нормалізована структура тут є неправильною для цього користувача — агента, який платить за кожен крок, а не загалом неправильною. Це також не є порівнянням постачальників: Microsoft Foundry є константою, а не змінною, і цей метод може бути застосований на будь-якій платформі з можливістю виклику функцій.

Чи змінила б база даних у цьому циклі результат? Це вимагає відповіді, а не гарантії. Перед проведенням тестових кампаній ті самі чотири інструменти були використані двічі — через Cosmos та через файли, які генерує програмний засіб, причому записані виклики інструментів були переграні для обох варіантів: 3 056 різних викликів, кожен з яких представляв унікальну комбінацію інструменту та аргументів, створену кампаніями. Обидві реалізації у всіх випадках давали ідентичні результати. База даних все ще відіграє певну роль: вона додає затримку та кількість запитів, а Cosmos вимагає приблизно на 4% більше кроків агента порівняно з варіантом на основі файлів, причому майже весь додатковий час витрачається на обробку нормалізованої структури даних. Однак результати, які бачив агент, походили від форми онтології, а не від двигуна, що знаходиться під нею, і цього достатньо для порівняння. Ці записи зберігаються у репозиторії у вигляді скрипту.

Обмеження інструменту

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

Під час аудиту коду перед випуском було виявлено дві проблеми в цьому інструменті. По-перше: коли запитуваний тип ребра відсутній у графі, функція traverse повертає порожній список сусідів, що неможливо відрізнити від вузла, який дійсно не має сусідів. Агент здійснив 112 таких викликів під час різних кампаній, і дев’ять із двадцяти двох хибних відмов у нормалізованому графі містили такий випадок; скрипт аналізу враховує обидва варіанти. Різниця у кількості залишається, оскільки інструмент shaped здійснив найбільшу кількість таких викликів, але відхилив найменшу кількість запитів. Проте інструмент, який відповідає „тут нічого немає“ на запит про „відсутність такого типу ребра“, створює плутанину, а чесною альтернативою є повідомлення про помилку з переліком наявних типів. По-друге: доведення безвтратності порівнює відновлені факти, тому воно не може бачити ребра, які самі по собі не несуть жодних фактів, тобто з’єднуючі ребра в інструменті flat та отримані швидкі шляхи в інструменті shaped. Зараз друга перевірка підтверджує ці краї відповідно до фактів, які вони відтворюють, і виявляє випадки видалення чи неправильного спрямування для кожного з них. Кампанії почалися раніше, ніж з’явилася ця перевірка, тому гарантії не існувало під час їхньої реалізації.

Форма є системним запитом

Багато зусиль вкладається у слова, які ставляться перед моделлю, а майже жодних — у форму знань, що стоїть за нею. Для агента, який використовує інструменти, онтологія є запитом: це опис дій, дозволених світом, написаний у вигляді типів вузлів та назв країв, який читається по одному виклику інструменту. Його потрібно розробляти для реального користувача.

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

Щоб дізнатися більше про використані компоненти, відповідна документація охоплює Azure Cosmos DB для Apache Gremlin, виклик функцій із моделями Microsoft Foundry та REST API Azure Retail Prices, який надавав ціни за токен, що лежать в основі показників витрат.