Kształt ontologii a rozmiar modelu: ile kosztuje projekt grafu dla agenta sztucznej inteligencji
Jak trzy bezstratne formy jednego grafu wiedzy ubezpieczeniowej wpłynęły na dokładność, liczba wywołań narzędzi, liczba tokenów oraz koszty w małych i dużych modelach w Azure Cosmos DB.
Gdy agent nie radzi sobie dobrze, rozwiązaniem, do którego uciekają się większość zespołów, jest użycie większego modelu. To również działa, choć kosztuje to mniej więcej czternaście razy więcej niż naprawa samego grafu. Ta liczba pochodzi z eksperymentu, w którym te same dane zostały zamodelowane na trzy różne sposoby, a pojedynczy agent w Microsoft Foundry otrzymał cztery narzędzia do przeszukiwania i żadną inną drogę do znalezienia odpowiedzi. Mierzono wtedy koszt struktury wiedzy na jeden pytanie.
Powyżej przedstawiono trzy wersje tej samej bazy faktów, łącznie 2 435 faktów. Każda z tych części to rzeczywisty podgraf pochodzący z danych eksperymentalnych, pokazujący, w jaki sposób każda ontologia przedstawia otoczenie tych samych trzech roszczeń ubezpieczeniowych. W układzie płaskim struktura jest ukryta wewnątrz atrybutów, więc prawie nic się ze sobą nie łączy. W układzie znormalizowanym każdy fakt stanowi osobny wierzchołek: nic nie jest pominięte, ale żaden z nich nie ma nazwy. W układzie z kształtami każda jednostka jest oznaczona, a każdy krawędź nazwany. Agent, model i baza danych pozostają identyczne we wszystkich trzech wersjach, a jedyną zmianą jest kształt.
Najpierw kilka słów na temat danych. Wszystko w nich jest wymyślone: osoby, firmy, miejsca oraz ubezpieczyciel pochodzą z skonstruowanych list słów z ustalonym „semem”, więc nic z tego nie odnosi się do rzeczywistości. Pomiary pochodzą z rzeczywistych testów przeprowadzonych w Sweden Central. Procesy analityczne odbywały się na dedykowanej platformie Microsoft Foundry, dane przechowywano w kontcie Azure Cosmos DB dla Apache Gremlin, a każde wezwanie narzędzia stanowiło zapytanie Gremlin skierowane do żywego grafu. Łącznie powstało 480 epizodów z udziałem agentów, 4,3 miliona tokenów oraz koszt 8,09 dolarów. Pierwsza próba przetworzenia tej samej struktury, przy której narzędzia czytały pliki generatory zamiast bazy danych, kosztowała 7,74 dolarów; nazywa się to testem weryfikacyjnym. Wszystkie podane liczby pochodzą z kampanii w Cosmos, a test weryfikacyjny jest stosowany tylko wtedy, gdy dwa testy łącznie pokazują coś, czego jeden z nich sam nie był w stanie wykryć.
Szczegół, którego nikt nie aktualizuje
Zespoły, które wdrażają agenty, zazwyczaj powtarzają pewien schemat. Agent zawodzi przy pytaniach, które powinien potrafić rozwiązać. Ktoś proponuje większy model. Rachunek się podwaja, błędy przenoszą się na inne pytania, a podsumowanie wskazuje, że agenci jeszcze nie są gotowi.
Prawie nikt nie przedstawia rzeczywistego materiału: struktury wiedzy, którą otrzymał agent. Na chwilę zapomnijmy o faktach. Zastanówmy się, czy adjuster to węzeł, czy ciąg znaków ukryty w obiekcie JSON, czy krawędź ma wartość assessed_by, czy po prostu related, oraz czy przejście od roszczenia do ubezpieczonego wymaga jednego kroku, czy pięciu.
Poprzednie prace pomiarowe dotyczyły systemu podejmującego decyzje oraz narzędzia, które je utrwalało. W innych badaniach trzyczęściowa seria publikacji stworzyła trwałą warstwę wiedzy, uruchomiła na niej agenty przy użyciu własnych syntetycznych danych ubezpieczeniowych i argumentowała za traktowaniem wiedzy jako celowo zaprojektowanego produktu, a nie zbiórki informacji do późniejszego wykorzystania. Brakowało w tych argumentach pomiarów, a to doświadczenie je dostarcza. Dodaje ono warstwę do podstawy, nad którą działają agenty, i stawia pytanie, na które rzadko udaje się uzyskać konkretne liczby: przy nieruchomych modelu, narzędziach, instrukcjach i faktach, przy jednoczesnej zmianie tylko struktury ontologii, jak reagują dokładność, wysiłek i koszt?
Pierwsza odpowiedź rodzi zarzut, dlatego cała struktura została ponownie przeprowadzona na znacznie większym modelu, aby sprawdzić, czy pieniądze mogą po prostu prześcignąć słabo skonstruowany graf. Mogą. Interesującym elementem jest cena oraz to, co mówi ona o kształcie, który warto stworzyć. Jak wcześniej, każde twierdzenie wymaga potwierdzenia.
Trzy formy jednej prawdy
Domeną testową jest księga umów ubezpieczeniowych zawierająca informacje o ubezpieczonych, polisach, zakresie ochrony, roszczeniach, brokerach, firmach naprawczych, płatnościach oraz regionach. Specjalny skrypt wygenerował to wszystko raz, dając 2 435 kanonicznych faktów dotyczących 507 jednostek, z których każda jest fikcyjna.
Z tej jednej bazy faktów pochodzą trzy ontologie. Nazywanie ich trzema zbiorkami danych byłoby błędem; są to trzy formy tych samych danych, rządzone jedną zasadą: każda wersja musi przedstawić fakty bez żadnych dodatków ani usunięć. Aby to zagwarantować, skrypt przegląda każdy utworzony graf, odbudowuje fakty i sprawdza, czy wynik jest dokładnie taki sam jak w źródle. Wersja, która znałaby jeden fakt więcej lub mniej niż inna, przekształciłaby tę rywalizację w test pokrycia danych. System CI w repozytorium przeprowadza tę weryfikację przy każdym dodaniu zmian do głównej gałęzi oraz przy każdym pull requestu, a także sprawdza, czy zapisane dane odpowiadają bit po bicie temu, co generuje „seed”, przy czym eksperyment jest nieważny, jeśli któreś z tych sprawdzeń nie przejdzie. Istnieje ważna uwaga dotycząca obiektywności: narzędzia Flat i Shaped zostały napisane bez odniesienia do zbioru faktów, co sprawia, że ich sprawdzania mają charakter merytoryczny, natomiast znormalizowany graf jest kodowany bezpośrednio na podstawie faktów, dzięki czemu z konstrukcji jest bliższy oryginałowi niż w przypadku dowodu.
Flat to rozwiązanie, które wiele zespołów najpierw wprowadza do użycia, i wykorzystuje zaledwie dwa rodzaje węzłów o dużej objętości danych. Każdy węzeł ubezpieczonego przechowuje swoje polisy oraz zakresy ochrony w postaci obiektu JSON w jednej właściwości. Każdy węzeł roszczenia zawiera informacje o swoim negocjatorze, dostawcy usług oraz płatnościach w ten sam sposób. Jeden ogólny typ krawędzi, related, łączy ubezpieczonych z roszczeniami – to właśnie stanowi całą strukturę schematu. Wszystkie informacje istnieją, ale są ukryte.
Normalizacja w tym przypadku działa w przeciwnym kierunku i nie jest „strawmanem”, ponieważ podręczniki ją by pochwały. Ona ucieleśnia wszystko – entity stają się prostymi węzłami Resource zawierającymi jedynie ich typ, każdy atrybut staje się węzłem Attribute dostępnym poprzez ogólny krawędź has, a każda relacja staje się węzłem Relation z krawędziami subject i object. Na papierze wygląda doskonale, ale nauka czegokolwiek wymaga czterech kroków.
Shaped został zaprojektowany z myślą o konsumentach, którzy rzeczywiście będą go używać. Typy węzłów mają określoną granularność, a każda krawędź ma kierunek, typ oraz nazwę, która ma konkretne znaczenie, np. filed_against, assessed_by lub settles. Polityki wskazują na ubezpieczonych za pomocą held_by, a ta sama nazwa jest ponownie używana z celowym dodatkowym efektem: dziewięćdziesiąt krawędzi held_by prowadzi bezpośrednio od roszczenia do jego ubezpieczonego, co skraca ścieżkę roszczenie-ubezpieczony do jednego kroku. Ponowne użycie tej nazwy jest celowe, ponieważ związek ten wygląda tak samo z obu stron, a agent nie potrzebuje drugiego słownika. Te dziewięćdziesiąt krawędzi ma flagę derived, nie dostarczają żadnej informacji i nie są uwzględniane w dowodzie braku strat, ponieważ opierają się na faktach, które już istnieją.
Rysunek 1 przedstawia pojedynczą relację – roszczenie oraz osobę odpowiedzialną za jego ocenę – we wszystkich trzech wariantach. W wersji flat osoba ta jest włączana jako właściwość JSON w ramach roszczenia, przy czym prawie nie ma żadnych powiązań. W wersji znormalizowanej relacja ta ma własny węzeł, dwa krawędzie oraz oddzielny węzeł atrybutów dla każdego faktu. W wersji shaped wystarczy podać nazwę krawędzi, a dodatkowy panel wyjaśnia, dlaczego istnieje ten pojedynczy skrót. Skrypt rekonstrukcji potwierdza, że wszystkie trzy wersje zawierają dokładnie te same 2 435 faktów.
Liczba węzłów daje wstępne pojęcie o strukturze. Jeden zbiór faktów wymaga 130 węzłów w wersji flat, 507 w wersji shaped i 2 942 w wersji znormalizowanej, a każdy dodatkowy węzeł to kolejny element, do którego agent może potrzebować dotrzeć.
Konkretna jednostka lepiej pokazuje różnice niż opis. Weźmy polisę, która stanie się sławna dzięki tym wynikom – przechowywana tak, jak to faktycznie robi każda z wariantów:
Rysunek 2 pobiera politykę P-7009 bezpośrednio z zapisanych plików ontologii za pomocą skryptu renderowania rysunków – tych samych plików, które zostały załadowane do Cosmos – więc pokazuje dokładnie ścieżkę, którą przeszedł agent. Metoda Flat przechowuje politykę jako ciąg znaków w właściwości ubezpieczonego: jest tam, ale nie stanowi wierzchołka i nie może być adresowana. Metoda Normalized przechowuje ją jako zwykły wierzchołek Resource, którego atrybuty znajdują się w oddzielnych wierzchołkach, dwa kroki dalej. Metoda Shaped przechowuje wierzchołek o określonym typie, do którego przypisane są właściwości oraz krawędzie o nazwach wychodzące od niego. Składka ubezpieczeniowa jest taka sama we wszystkich trzech przypadkach, jednak znajduje się na trzech różnych odległościach od pytania.
Każda forma znajduje się w swoim własnym kontenerze grafu wewnątrz Azure Cosmos DB dla Apache Gremlin, i to właśnie ten graf jest przemierzany przez agenta; każde wywołanie narzędzia przekształca się w operacje przemierzania grafu w czasie rzeczywistym. Generator wytwarza bazę faktów, a loader zapisuje ją do Cosmos DB, przy czym mechanizm ładowania sam sprawdza swoją pracę: liczba wierzchołków i krawędzi musi odpowiadać wartościom z źródła, w przeciwnym razie zgłaszany jest brak zgodności zamiast odkrycia niekompletnego grafu później.
Jeden baz danych, jedna warstwa narzędziowa oraz identyczne domyślne metody indeksowania sprawiają, że projekty są porównywalne, a także ułatwiają ich widoczność. Graf właściwości nic nie ukrywa – wystarczy zapytać go o to, co wie, a odpowiedzią będzie sam projekt.
Tabela 1 podaje tę samą liczbę 2 435 faktów w ramach każdego schematu, pobranych z plików grafowych. W wersji flat liczba wierzchołków przewyższa liczbę krawędzi, a pięć wierzchołków nie jest połączonych z niczym. Wersja znormalizowana jest jednolita i pozbawiona słów. Wersja ukształtowana ma najlepsze połączenia, a jej etykiety wykorzystują słownictwo z danej dziedziny.
Wracamy do kolumny flat. Liczba krawędzi jest mniejsza od liczby wierzchołków, a pięć węzłów nie jest połączonych z niczym; są to ubezpieczyciele bez roszczeń, a w tym projekcie nic innego na świecie nie prowadzi do nich. To baza danych grafowych przechowująca coś, co ledwo można uznać za graf. Struktura nadal istnieje, ale została przekształcona w 8,2 właściwości na wierzchołek, więc zachowuje się jak tekst, a nie jak topologia. Wyniki zależą od tej decyzji projektowej, a baza grafowa przedstawia ją jako fakt, a nie jako opinię.
Kolumna znormalizowana odzwierciedla to. Jest to najbardziej jednolity z trzech grafów: mniej więcej jeden krawędź na wierzchołek, nic izolowanego, 1,6 właściwości na węzeł, ponieważ reifikacja przekształca każdy fakt w te same trzy elementy budulcowe, powtórzone 2 942 razy. Struktura jest obfita, a słownictwo nieobecne – trzy etykiety wierzchołków i trzy etykiety krawędzi wystarczają do opisania całego biznesu ubezpieczeniowego.
Z 1,36 krawędzi na wierzchołek graf ukształtowany jest najlepiej połączony, posiada osiem etykiet wierzchołków i dziewięć typów krawędzi. Różnica staje się natychmiast widoczna, gdy każdemu grafowi zadaje się pytanie o rodzaje elementów, które zawiera:
g.V().groupCount().by(label)
- W formularzu znajdują się tylko dane dotyczące roszczenia (90) oraz ubezpieczonego (40).
- Znormalizowane raporty obejmują zasób (507), atrybut (1834) oraz relację (601).
- Lista zawiera osiem etykiet domen: 216 dotyczących zakresu ubezpieczenia, 90 roszczeń, 75 polis, 59 płatności, 40 ubezpieczonych, 12 dostawców, 10 likwidatorów szkód oraz 5 regionów.
Druga zapytanie liczy polisy według etykiet:
g.V().hasLabel('policy').count()
Tabela 2 umieszcza jedno zapytanie obok trzech odpowiedzi. Oba zera oznaczają niepowodzenia różnego rodzaju. W grafie płaskim po prostu nie ma żadnej polityki do znalezienia. W grafie znormalizowanym polityka istnieje, ale nie daje o sobie znać. W wersji płaskiej utracono entytet; w wersji znormalizowanej zachowano entytet, ale utracono słownictwo, więc do polityki można dotrzeć jedynie poprzez kroczenie w jej kierunku, a nie poprzez jej nazwanie. Nic z tego nie wynika z sposobu przechowywania danych: trzy schematy, jedna baza danych, jedno zapytanie.
To samo nierównowagę występuje przy ustalaniu ceny dla realistycznego pytania. W którym mieście mieszka ubezpieczony, w odniesieniu do polisy przy roszczeniu C-31020? Każdy graf odpowiada Larkfield, ponieważ każdy graf zawiera te same fakty. To droga do tego miejsca się różni. W grafie ukształtowanym pochodna krawędź ją skraca:
# shaped - the derived shortcut collapses the path
g.V().has('number','C-31020').out('held_by').values('city')
Proste i znormalizowane wykresy wymagają tego zamiast tego:
# 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 radzi sobie z tym w jednym kroku, ponieważ roszczenie i posiadacz są przypadkowo jedynymi dwoma rodzajami elementów w tym schemacie. Normalizacja wymaga pięciu kroków oraz dwóch operacji rozpakowywania. Agent nigdy sam nie komponuje tych zapytań; znajduje ścieżkę krok po kroku, poprzez kolejne wywołania narzędzi, co stanowi cel eksperymentu. Mimo to zapytania ujawniają, co jest odkrywane oraz ile tego jest.
Rysunek 3 pokazuje, że identyczne zapytanie jest wykonywane we wszystkich trzech grafach w Cosmos DB Data Explorer. Niezależnie od tego, czy graf zawiera dwa etykiety, trzy metaetykiety, czy opis domeny własnymi słowami, schematy nie przechowują różnych danych; przechowują jeden zbiór danych w różnych formach.
Rysunek 4 wybiera roszczenie C-31020 w każdym grafie i umożliwia narzędziu Data Explorer narysowanie jego sąsiadów. W grafie płaskim dostępny jest tylko jeden wierzchołek – ubezpieczony – poprzez krawędź oznaczoną jako related. Uprawniony AJ-09 oraz polisa PL-043 są widoczne w panelu właściwości, ale w formie tekstu, więc agent nie ma możliwości dotarcia do nich. W grafie znormalizowanym pojawia się osiem wierzchołków, sześć atrybutów i dwie relacje, z których żadna nie ma nazwy w języku domeny. W grafie ukształtowanym nazwy te występują wraz z krawędziami filed_against, assessed_by i held_by. Jedno roszczenie, jedna baza danych, trzy odległości.
Narzędzie: cztery narzędzia i paragon
Agenat jest celowo minimalny, ponieważ nie jest to obiekt testowany. Jest to zwykły pętla wywoływania funkcji działająca na modelu Microsoft Foundry, skonfigurowana zgodnie z opisem sposobu używania narzędzi w dokumentacji Foundry poprzez Chat Completions API. Składa się on z ustalonego promptu systemowego, ograniczenia do szesnastu iteracji modelu na pytanie (po których sesja zostaje zakończona) oraz czterech narzędzi, których sygnatury są identyczne we wszystkich trzech ontologiach.
Rysunek 5 pokazuje całkowite zapotrzebowanie obliczeniowe: pojedynczy zasób Microsoft Foundry zawierający dwa wdrożenia modeli – agent-small uruchamiający gpt-5.4-nano oraz agent-large uruchamiający gpt-5.5, oba z serii Global Standard. Nazwy i wersje pochodzą z szablonu infrastruktury w repozytorium, więc za tymi danymi nie kryje się żaden ukryty zasób.
Cztery narzędzia to:
find_nodeswyszukuje właściwości i ID węzłów według podciągu tekstu, z ograniczeniem do dwudziestu wynikówget_nodeodczytuje typ i właściwości jednego węzłatraversezwraca do trzydziestu sąsiadów węzła, które można filtrować według typu krawędzi i kierunkudescribe_edgespodsumowuje, które krawędzie wychodzą z węzła lub do niego wchodzą oraz ile ich jest każdego typu
W rzeczywistości każde narzędzie przekształca się w Gremlina w Cosmos. get_node i find_nodes wymagają po jednej wizycie, czyli odczytu jednego węzła i jego przeszukania, natomiast traverse i describe_edges potrzebują trzech wizyt, ponieważ najpierw sprawdzają, czy węzeł istnieje, a następnie kolejno przeglądają krawędzie wychodzące i przychodzące. Agent nie zapisuje żadnych z tych informacji. Prosi o węzeł lub sąsiada i otrzymuje zwięzłą odpowiedź w formacie JSON – to standardowy format narzędzi produkcyjnych używanych z magazynami grafów, który także chroni język zapytań przed dostępem do modelu.
Przechodzenie po grafie to jedyny sposób na znalezienie odpowiedzi. Agent nigdy nie przegląda schematu ani nie pisze kodu w języku Gremlin, a ma instrukcje, by w przypadku braku w grafie informacji potrzebnych do odpowiedzi na pytanie użyć wartości NOT_MODELED. Wielkość liter ma znaczenie: graf o niewłaściwej strukturze wymusza dodatkowe wywołania narzędzi zamiast jednej ogromnej odpowiedzi, podobnie jak to ma miejsce w rzeczywistych budżetach narzędzi. Limit szesnastu rund obejmuje rundy rozmowy, a nie wywołania narzędzi; jedna runda może obejmować żądania kilku narzędzi jednocześnie, więc najbardziej intensywny epizod przeprowadził sześćdziesiąt takich wywołań w ciągu szesnastu rund.
Trzy praktyczne lekcje wynikające z pracy z prawdziwą bazą danych grafowych, które wymagały ciągłej przebudowy struktury, pokazały, że Cosmos odrzuca skrypty zawierające wiele zapytań. Dlatego załadunek danych oznacza jedną wizytę w strukturze na każde żądanie, a przepustowość uzyskuje się poprzez wykonywanie wielu zapytań równolegle zamiast ich grupowania. Krótki czas oczekiwania na odpowiedź wynoszący sześćdziesiąt sekund sprawia, że polecenie g.V().drop() nie może usunąć kilku tysięcy wierzchołków – przerwa się w połowie i pozostawi niekompletną bazę grafową, więc czyszczenie odbywa się stopniowo. Poziom serverless ma również ograniczenie przepustowości, które zamienia nagły napływ czterdziestu jednoczesnych zapisów w przerwy w działaniu, dlatego zarówno narzędzie do ładowania, jak i narzędzie agenta próbują ponownie z większym opóźnieniem. Nic z tego nie jest egzotyczne, ale to właśnie różnice te odróżniają bazę grafową w stanie spoczynku od tej pod obciążeniem.
Ocenianie bez sędziego
Ocena agentów ma tendencję do łagodzenia się na etapie oceniania, dlatego temu poświęcono najwięcej uwagi, a żaden sędzia oparty na modelu językowym nie występuje. Czterdzieści pytań dzieli się na cztery grupy po dziesięć: zapytania wymagające poszukiwania jednego faktu, krótkie ścieżki składające się z dwóch lub trzech kroków, pytania wymagające długiej ścieżki lub agregacji danych z podgrafu oraz pytania, na które nie da się odpowiedzieć. Skrypt generuje je na podstawie bazy faktów i wyprowadza każdą poprawną odpowiedź z surowych faktów. Ocena jest mechaniczna – liczba musi odpowiadać obliczonemu wartości, ciąg znaków musi ją zawierać, a pytanie bez możliwości odpowiedzi uznaje się za poprawne tylko wtedy, gdy agent wyraźnie stwierdzi, że nie może na nie odpowiedzieć. Żadna ontologia sama siebie nie ocenia, żaden model nie ocenia innego modelu, a poprawność wynika z porównania, a nie z opinii.
Ponieważ agent może działać wyłącznie za pośrednictwem swoich czterech narzędzi, każda odpowiedź zawiera pełny wykaz wywołań, które ją stworzyły. W wcześniejszych pomiarach routera pole model pełniło rolę potwierdzenia; tutaj tę rolę pełni ścieżka. Poprawną odpowiedź można prześledzić krok po kroku, a niepowodzenie pokazuje dokładnie, w którym momencie struktura straciła kontakt z agentem.
Rysunek 6 przedstawia taką konfigurację. Jedna baza faktów służy do tworzenia trzech struktur bez strat, które stają się trzema kontenerami grafów w Azure Cosmos DB dla Apache Gremlin, natomiast oddzielna gałąź dostarcza informacje do orakula, które wyprowadza każdą poprawną odpowiedź na podstawie tych samych faktów. Agent uzyskuje dostęp do grafów wyłącznie za pomocą czterech narzędzi, przy czym każde wywołanie polega na jednym zapytaniu Gremlin. Narzędzia, pętle i pytania pozostają niezmienne, podczas gdy struktury się zmieniają, a każdy przebieg testu generuje informacje o wywołaniach narzędzi, tokenach, opóźnieniach oraz werdykcie orakula.
Nierozwiązywalny zestaw pytań zasługuje na osobny werdykt. Jego dziesięć pytań dotyczy rzeczy, których baza faktów nigdy nie modeluje: numerów telefonów, adresów e-mail, pogody, numerów identyfikacyjnych pojazdów. Prawidłowym zachowaniem jest odpowiedź, że graf nie może tego powiedzieć. Agent, który wymyśla krawędź zamiast przyznać, że graf nie posiada takich informacji, wykazuje najniebezpieczniejszą awarię w tej rodzinie systemów, a prawie nikt jej nie mierzy.
Koszt przemierzania
Główna kampania była przeprowadzana na żywych grafach Cosmos DB, przy użyciu dedykowanej implementacji Microsoft Foundry w regionie Sweden Central. Obejmowała trzy ontologie, czterdzieści pytań oraz trzy pełne przejścia z jednym małym modelem pozostawionym niezmienionym, co dało 360 odcinków z udziałem agentów, 3,1 miliona tokenów oraz siedemdziesiąt centów. Każde wezwanie narzędzia stanowiło zapytanie Gremlin. Druga kampania, opisana później, ponownie uruchamiała ten proces na większym modelu, co przyniosło kolejne 120 odcinków i koszt 7,39 dolarów. Skrypt w repozytorium oblicza wszystkie podane poniżej liczby na podstawie zapisanych faktur, przy czym żadna z nich nie została wpisana ręcznie.
Tabela 3 podsumowuje wyniki kampanii: mały model, trzy przejścia, 360 odcinków oraz zapytanie Gremlin za każde wezwanie narzędzia. Zielony kolor oznacza najlepszy wynik w danej wierszu. Wiersze dotyczące zasobów są celowo bez koloru, ponieważ ich wartość jest najniższa we wszystkich czterech kryteriach, a jak pokazują późniejsze sekcje, część tej oszczędności służy do pokrycia kosztów odpowiedzi, których w rzeczywistości nie dostarczono.
Najpierw obniżmy wartość pierwszego wiersza, który przedstawia najmniej informacyjną liczbę w tabeli. Metoda „Shaped” odpowiedziała poprawnie na 84,2% pytań, metoda „Flat” na 78,3%, a metoda „Normalized” na 59,2%. Jednak przy trzech identycznych próbach dokładność tych wariantów zmieniła się odpowiednio o 0,075, 0,150 i 0,075, więc sześciopunktowa różnica pomiędzy metodą „Shaped” a „Flat” mieści się w granicach ich własnego szumu, a przy trzech próbach nic nie pozwala odróżnić tych dwóch metod pod względem ogólnej dokładności. Dwudziestopunktowa przewaga nad metodą „Normalized” łatwo eliminuje ten szum.
To brzmi słabiej, niż jest w rzeczywistości. Ogólna wartość jest niejasna, ponieważ jest średnią wartości z grup, które znacznie się od siebie różnią, a to właśnie ta różnica stanowi kluczowy wynik:
Tabela 4 wyjaśnia problem z tą sumą. Kształty nie różnią się nieznacznie we wszystkich obszarach; dzielą się wyraźnie na poszczególne grupy, a każda z tych grup stawia inne wymagania wobec wykresu.
Najpierw przyjrzyjmy się wyszukiwaniom opartym na jednym faktorze. Wyniki w przypadku kształtu „shaped” wyniosły 0,967, a w przypadku „flat” 0,533 – różnica wynosiła 43 punkty, przy czym poziom szumu wynosił 0,100 dla pierwszego i 0,200 dla drugiego, co potwierdza autentyczność sygnału. W przypadku tras dwu- i trzyetapowych oba wyniki osiągnęły 0,967. W najtrudniejszym przypadku poziom szumu wynosił 0,300 i 0,400, więc nie ma możliwości wyłonienia zwycięzcy.
Dlatego te dwa kształty nie są ani lepsze, ani gorsze. Są uszkodzone w różnych miejscach, a łączenie ich w jeden wynik ukrywa istotną informację. Gdy trzeba coś znaleźć, metoda „flat” zawodzi i nadal zawodzi. Gdy agent już ma punkt oparcia i musi jedynie iść dalej, metoda „flat” radzi sobie tak samo dobrze jak zaprojektowana struktura grafu.
Metoda „normalized” odzwierciedla to, co pokazują jej wyniki: 0,867 przy wyszukiwaniach, co jest lepsze od metody „flat”, ponieważ każda jednostka stanowi rzeczywisty wierzchołek; następnie wyniki spadają do 0,467 i 0,133 w miarę wydłużania się tras. Udaje jej się znaleźć wszystko, ale nic nie kończy.
Jak każdy kształt zawodzi
Kształty różnią się sposobem i miejscem występowania błędów. Każdy z nich rozwiązywał trzydzieści pytań trzy razy, łącznie dziewięćdziesiąt odcinków, a grupowanie błędów według typu ujawnia mechanizm ich powstawania.
Tabela 5 grupuje błędy z tych dziewięćdziesięciu odcinków. Normalized wyczerpuje swój budżet rund; Flat zatrzymuje się wcześnie i z pewnością siebie w przypadku pytań, na które baza danych mogła udzielić odpowiedzi.
Dwadzieścia dwa z dziewięćdziesięciu odcinków, w których Normalized rozwiązywało pytania, czyli około jednej czwartej, kończyło się wyczerpaniem budżetu, podczas gdy agent wciąż był w ruchu. Flat rzadko tak robiło – zatrzymywało się wcześnie i z pewnością siebie, odrzucając osiemnaście pytań, na które istniały odpowiedzi w bazie danych. Jeden kształt wyczerpuje się, a drugi rezygnuje.
Awaria całkowita jest bardziej gwałtowna, a ślady wskazują na mechanizm, którego nikt się nie spodziewał. Oto dwa rzeczywiste przypadki. W obu przypadkach żądano dopłaty do polisy P-7009, a różnią się one jedynie tym, jaki schemat stoi za tymi narzędziami:
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
Na zgraphizowanym grafie wystarczą dwa wywołania. Prosi się o polisę pod numerem, otrzymuje się wierzchołek reprezentujący polisę, czyta się z niego kwotę składki – i to wszystko.
Prosty graf opowiada inną historię. Pierwsze wyszukiwanie zwróciło wierzchołek, podobnie jak drugie. Trzecie zapytanie zawierało parametr type=policy, ale nic nie znalazło, ponieważ taka etykieta nie istnieje w tym schemacie. Czwarte zapytanie użyło parametru type=policyholder i odniosło sukces. Zatem na podstawie typu agent znalazł dokładnie ten wierzchołek, który zawierał odpowiedź, a mimo to ogłosił dane nieobecne.
Premia znajdowała się w tym wierzchołku, w określonej właściwości, zaledwie jednym wywołaniem get_node od niej. W ciągu dziesięciu nieudanych prób odnalezienia premii niefiltrowane wyszukiwanie dostarczyło informacji o tym wierzchołku piętnaście razy, natomiast funkcja get_node została na niego wywołana zero razy. Wierzchołek ten miał etykietę „Ivo Renner”, czyli nazwisko osoby. W pozostałych nieudanych próbach etykieta ta należała do jednego z dwóch innych ubezpieczonych, nigdy jednak do samej polisy, a nazwisko osoby nie dawało żadnych wskazówek na to, że szukana polisa znajduje się wewnątrz.
To właśnie stanowi szczególne zagrożenie związane z ukrywaniem entytetów, a baza danych grafowych to ujawniają. Dane są dostępne, ale nierozpoznawalne. Są indeksowane, zwracane przez zapytanie i obecne w kontekście agenta, jednak nie odpowiadają na żadną z użytych nazw.
Normalizacja zawodzi w otwartym środowisku i to kosztownie. Odczytanie jednego atrybutu oznacza przejście przez węzeł Attribute, a śledzenie jednej relacji wymaga objazdu przez węzeł Relation. Kolumna „Tokeny” pokazuje koszt: 13 701 za każde pytanie w porównaniu z 7 176 w przypadku formatu shaped, oraz 12,15 wywołań narzędzia w porównaniu z 7,24. Dwadzieścia pięć z 120 odcinków osiągnęło limit szesnastu ruchów, podczas gdy w przypadku formatu shaped było to trzy odcinki, a w przypadku formatu flat dwa; najtrudniejszy zestaw uzyskał wynik 0,133. W grafie nie brakowało niczego. Agent po prostu zabrakło tchu, zanim zdołał dokończyć zdanie.
Najtańsza opcja rzeczywiście jest najtańsza, choć to nie jest komplement. Wersja prostsza kosztuje 0,109 dolara za sto pytań, podczas gdy wersja z kształtem kosztuje 0,165 dolara, a jeśli weźmiemy pod uwagę dokładność, to nadal wygrywa – 0,14 dolara za sto poprawnych odpowiedzi w porównaniu z 0,20 dolara. Zgodnie z tym modelem wersja prostsza jest rzeczywiście tańsza w obsłudze. Ceną, której nie da się kupić, są osiemnaście odpowiedzi, których system odrzucił. Szybkie zakończenie jest tanie, a niska kwota rachunku nie stanowi oszczędności, czego sama kolumna kosztów nigdy nie ujawni.
Paradoks odrzucenia
Najlepsza i najgorsza opcja zamieniają się miejscami w grupie pytań bez odpowiedzi po przeanalizowaniu pytań z możliwymi odpowiedziami. Wersja prostsza poprawnie odrzuciła wszystkie trzydzieści pytań bez odpowiedzi, co stanowi jedyną perfekcyjną ocenę w tabeli. Wersja z kształtem osiągnęła wynik 0,933 po normalizacji 0,900, a jej błędy wynikały z wyczerpania się rund, a nie z wymyślonych odpowiedzi.
Patrząc na to samodzielnie, ta grupa daje wynik równy zero. Obok liczby fałszywych odmów kolejność się odwraca: forma z najwyższym wynikiem odmów pominęła osiemnaście pytań, na które mogła odpowiedzieć, podczas gdy forma z najgorszym wynikiem odmów pominęła trzynaście. Wynik zero nie jest lepszy w wykrywaniu braku odpowiedzi – skłania się raczej do jego deklarowania, a ta tendencja, która przynosi sukces przy pytaniami bez odpowiedzi, przegrywa przy pytaniami z odpowiedziami. Metryka odmów bez towarzyszącej jej metryki możliwości udzielenia odpowiedzi prowadzi do stworzenia najmniej trafnego wykresu, jaki można zbudować.
Wynik sprzeczny z projektem
Jeden z wyników jest sprzeczny z projektem opartym na kształtach, który preferuje eksperyment, a druga kampania go jeszcze wyostrzyła. W tym projekcie istnieje tylko jeden pochodny skrót: held_by, który łączy roszczenie bezpośrednio z jego ubezpieczonym. W kwestii powiązania roszczenia z miastem ubezpieczyciela uzyskał on wynik 0,83, podczas gdy wersja znormalizowana – 0,33, natomiast wersja prostsza osiągnęła 0,92 bez żadnego skrótu, ponieważ w tym schemacie istnieją tylko roszczenie i ubezpieczony. Wynik, w którym wersja bez elementu krawędzi radzi sobie lepiej, nie może być przypisywany temu elementowi.
Gorsza jeszcze jest sytuacja, gdy brakuje skrótu w miejscu, gdzie był oczekiwany. Licząc różne rodzaje pokrycia w ramach polis posiadacza, uzyskano wynik 0,17 w przypadku rzekomo dobrze zaprojektowanego grafu oraz 0,67 w przypadku grafu płaskiego, co umożliwia traktowanie ich jako jednej czytelnej właściwości. Łączna kwota płatności za roszczenia posiadacza wyniosła 0,33. Przy agregacji w ramach podgrafu projekt, który jest propagowany, przegrywa z projektem określanym jako „uszkodzony”. Denormalizacja nie jest kompromisem wobec dobrego projektowania, lecz jego częścią; ponadto zaprojektowany w ten sposób graf stosował swój własny princip zbyt oszczędnie dokładnie w tych miejscach, gdzie pracochłonność wymagała tego.
Kupowanie wyjścia za pomocą większego modelu
Cała siatka została następnie przeprowadzona po raz drugi na znacznie większym modelu, a odpowiedź na główne pytanie pojawiła się dzięki jego nieoczekiwanemu zachowaniu. Na początku zakładano, że mały model na dobrze ukształtowanym grafie pokona duży model na źle ukształtowanym. Tak się nie stało. Do tej porównania wchodzą tylko pytania, na które można odpowiedzieć, więc odrzucenie pytań bez odpowiedzi nie może poprawić wizerunku żadnego kształtu. Każdy wiersz dotyczący małego modelu zawiera dziewięćdziesiąt epizodów z trzech przebiegów, natomiast każdy wiersz dotyczący dużego modelu ma trzydzieści epizodów z jednego przebiegu.
Tabela 6 ogranicza się do pytań, na które można odpowiedzieć, więc prawidłowe odrzucenia nie mogą sprawić, by kształt skłonny do odrzucania wyglądał lepiej.
Wielki model bez trudu odczytuje ukryte właściwości. Odpowiedział na wszystkie trzydzieści pytań związanych z płaskim grafem, w tym te dotyczące entytetów, które schemat przekształcił w tekst, a osiemnaście fałszywych odmów, które utrudniały pracę małego modelu, zniknęło. Szczera informacja nie jest tą, której oczekiwali wszyscy.
Słabo skonstruowana ontologia może się opłacić. Koszt wynosi około czternastokrotność ceny za pojedyncze pytanie: wielki model w przypadku płaskiego grafu kosztuje 1,90 dolarów za sto pytań, natomiast mały model w przypadku grafu skonstruowanego w inny sposób – trzynaście centów. Zachowaj płaski graf i zaktualizuj tylko model używany z nim – wtedy rachunek będzie dwudziestokrotnie wyższy niż koszt tego samego małego modelu w tym samym kontekście.
Ten wynik jest bardziej przydatny niż przewidywany ze względu na to, co implikuje. Dzięki modelowi granicznemu i pytaniom wymagającym odpowiedzi kwestia kształtu przestała być problemem poprawności i przekształciła się w problem kosztów: zarówno wariant płaski, jak i kształtowany uzyskały odpowiedzi na wszystkie trzydzieści pytań, a jedynie rachunek je rozdzielał. W przypadku małego modelu kształt był równoznaczny z poprawnością. Dlatego dobrze zaprojektowana ontologia zapewnia mniejszą jakość niż możliwość uruchomienia taniego modelu. Płaski graf łączy warstwę wiedzy z budżetem modelu i działa tylko tak długo, jak długo trwa płatność za model wystarczająco duży, by móc na każde pytanie udzielać odpowiedzi w nieskończoność.
We wszystkich czterech kategoriach kolejność wyników jest bardziej uporządkowana niż sugeruje pogląd oparty wyłącznie na możliwości udzielenia odpowiedzi. W przypadku dużego modelu wariant kształtowany osiągnął doskonałą wartość 1,000 we wszystkich kategoriach, włączając tę, w której nie dało się udzielić odpowiedzi. Wariant płaski osiągnął wartość 0,950, a po normalizacji 0,825. Pieniądze poprawiają poprawność tylko w dużej mierze, natomiast rachunek pozostaje bez zmian.
Co pokażła weryfikacja co do konieczności ostrożności
Przeprowadzona weryfikacja (ta sama siatka, te same pytania, narzędzia czytające pliki zamiast Cosmos) dała najbardziej niepokojący wynik w ramach projektu, a pochodził on z wykresu w określonej formie. Gdy zapytano o warunki pogodowe w dniu incydentu, który świadomie nie jest modelowany w ontologii, agent odpowiedział „uszkodzenia spowodowane gradem”. Znalazł właściwość cause zgłoszenia i przedstawił ją jako warunki pogodowe. Zostało to wówczas odnotowane jako najniebezpieczniejszy błąd wynikający z preferowanego projektu, z zastrzeżeniem, że była to jedna z prób, obserwacja, a nie pomiar, bez podstaw do sformułowania prawa.
Ponowne przetestowanie na rzeczywistej infrastrukturze okazało się słusznym posunięciem. W przeprowadzonej kampanii wykres o określonym kształcie poprawnie odrzucił wszystkie dziesięć trudnych pytań dla dużych modeli, natomiast wykres płaski udzielił na to samo pytanie odpowiedzi „hail”. Model, pytanie i pułapka były identyczne; różnił się jedynie kształt, który dał się złapać.
Zatem wniosek nie brzmi, że bogate wykresy sprzyjają tworzeniu fałszywych odpowiedzi. Atrybut przyczyna o wartości „uszkodzenia spowodowane gradem” skusi każdy model, do którego zadano pytanie o pogodę, niezależnie od miejsca jego przechowywania, a kształt, który da się złapać, zmienia się przy każdym przetestowaniu. To jest mniej radykalne stwierdzenie niż to, które niemal zostało sformułowane, i jest to to, co potwierdzają dowody. Oznacza to również, że zagrożenie nie zależy od kształtu: jeśli wykres zawiera pole, które wygląda jak odpowiedź na coś, na co tak naprawdę nie odpowiada, jakiś model gdzieś to przyjmie.
Znormalizowana forma w obu modelach
W obu modelach nastąpiła ogólna utrata normalizacji. W przypadku modelu małego zajął on ostatnie miejsce, a w przypadku modelu dużego nadal plasował się na poziomie 0,867 w kwestiach wymagających odpowiedzi, przy koszcie 9,31 dolarów na sto zapytań – co stanowi prawie pięciokrotność wyniku uzyskanego przez ten sam model przy użyciu prostego podejścia. Ponadto siedem razy zabrakło mu możliwości dalszych odpowiedzi. Model o większych rozmiarach nie radzi sobie lepiej, ponieważ jego problemem nie była nigdy kompreensja, lecz odległość: piętnaście wywołań narzędzi na jedno pytanie w porównaniu do 8,3 w przypadku modelu „shaped”, który nigdy niczego nie błędnie zinterpretował.
Wersja znormalizowana nie przegrała we wszystkich przypadkach, a ta wyjątkowa sytuacja uczy najwięcej. Przy wyszukiwaniu na podstawie jednego faktu wersja znormalizowana osiągnęła wynik 0,867, podczas gdy wersja prostsza – 0,533; przy dwóch pytaniach, które sprawiły, że wersja prostsza zawiodła, wersja znormalizowana była wyraźnie lepsza: 0,83 w porównaniu z 0,17 w przypadku składki ubezpieczeniowej oraz 0,83 w porównaniu z 0,33 w przypadku specjalizacji dostawcy. Reifikacja jest niezwykle kosztowna, ale nic nie ukrywa. Każda entytet to wierzchołek, więc każdą entytet można znaleźć.
To podsumowuje argument: każda nieudana forma zachowała połowę problemu i odrzuciła drugą połowę. Wersja prostsza zachowała odległości, ale straciła możliwość lokalizacji. Wersja znormalizowana zachowała możliwość lokalizacji, ale straciła odległości. Każda z nich konkuje na podstawie tej połowy, którą zachowała, i jest bezradna wobec drugiej połowy.
Shaped nie stanowi kompromisu pomiędzy tymi dwoma podejściami. Otrzymuje wynik 0,967 w skali dla wartości wyższych od flat oraz 0,967 w skali dla wartości wyższych od znormalizowanych, więc odrzuca tę kompromisową opcję. W tym właśnie tkwi jego zaleta, a jedna liczba odnosząca się do dokładności całkowitej całkowicie ją ukrywa.
Opóźnienie w porównaniu z rzeczywistą bazą danych
Opóźnienie to jedna z miar, której nie można było sprawdzić poprzez wzajemną weryfikację. W przypadku plików czasy wykonywania zapytań znacznie się różniły przy identycznych przetworzeniach – ta sama wersja mogła potrzebować 1,17 sekundy na jedno zapytanie przy jednym przetworzeniu i 4,21 sekundy przy innym, dlatego nic nie zostało zgłoszone, gdy różnice w wydajności usługi przewyższyły różnice w ontologii. W przypadku Cosmos sytuacja jest uporządkowana, i to z łagodnie ujemnego powodu.
Tabela 7 pokazuje czas wykonywania każdego pytania – różnice między różnymi formami są wyraźne, a w obrębie danej formy czas pozostaje stały; jednocześnie czas wykonywania zapytania dla każdego narzędzia jest identyczny we wszystkich trzech przypadkach, dzięki czemu tabela przedstawia liczbę wywołań narzędzia w sekundach.
W ramach jednej konkretnej wersji największa różnica czasu wynosi siedem sekund, podczas gdy od wersji płaskiej do znormalizowanej różnica ta sięga prawie pięćdziesięciu sekund. Znormalizowane pytanie zajmuje dwa i pół raza więcej czasu niż pytanie w wersji płaskiej. Ostatnia kolumna obniża ten wynik: przy każdej próbie wszystkie trzy wersje wymagają mniej więcej tyle samo czasu – od 6,2 do 7,4 sekundy, niezależnie od schematu. Dlatego nie jest to odkrycie niezależne. Baza danych zapewnia spójność, ponieważ czas realizacji operacji w Cosmos jest przewidywalny, czego nie dało się stwierdzić przy użyciu lokalnego słownika, i to właśnie umożliwia podawanie takich danych.
Powstaje z tego jedna praktyczna konsekwencja. Ponieważ opóźnienie przy każdej próbie jest mniej więcej stałe, zbiory form ontologicznych wpływają na czas odpowiedzi w taki sam sposób, w jaki wpływają na koszt transakcji, a tę wartość można oszacować jeszcze przed jej wykonaniem, licząc liczba kroków w procesie.
Zasady, każda z ich potwierdzeniem
Pisanie na temat projektowania ontologii zazwyczaj przedstawia zasady jako kwestię gustu. Większość z tych poniżej ma przypisany im numer, a te, które go nie mają, o tym wspominają.
Wszystko, o czym można zadać pytanie, musi być wierzchołkiem. Jeśli trzeba wyryć jakąś zasadę nad drzwiami, niech to będzie właśnie ta. Prosty graf przechowuje każdą składkę ubezpieczeniową oraz specjalizację dostawcy, zindeksowane, w tej samej bazie danych co wszystko inne, a mały model ledwo je odnajdywał. Składki pojawiały się w 17% przypadków, a specjalizacje w 33%, podczas gdy model oparty na strukturze przypisów dawał wyniki 100% i 83%. Pełny zakres wartości wynosi od 0,533 do 0,967. Ukrywanie entity wewnątrz właściwości innej entity nie utrudnia jej znalezienia. Zamiast tego pytanie dotyczące niej pojawia się pod inną nazwą, co agent interpretuje jako dowód na jej brak. Metoda krzyżowa dodaje dodatkowy warunek, ponieważ model graniczny wydobywa je wszystkie. Ukrycie nie stanowi absolutnej bariery, lecz jedynie „podatku” do zapłacenia w danym poziomie modelu.
Granularność to rodzaj budżetu, a jej nadmierne wykorzystanie szybko go wyczerpuje. Każdy dodany węzeł w imię czystości schematu generuje dodatkowe koszty przy każdym wejściu. W porównaniu z wersją ukształtowaną, wersja znormalizowana wymagała 3,7 raza więcej wywołań narzędzia przy wyszukiwaniu pojedynczych faktów, 2,3 raza więcej przy krótkich trasach, a także czterokrotnie więcej tokenów przy długich ścieżkach; ponadto osiągnęła limit liczby ruchów w 25 z 120 epizodów, podczas gdy wersja znormalizowana – tylko w 3. Model o cenie 25 razy wyższej za token wejściowy podniósł wynik na pytania wymagające odpowiedzi z 0,489 do 0,867. To rzeczywiście znaczna poprawa, ale kosztowała ona 9,31 dolara za sto tokenów, co jest prawie pięciokrotnie więcej niż koszt tego samego modelu w wersji znormalizowanej. Odległość nigdy nie jest tania, niezależnie od budżetu.
Punkty wejścia to architektura, a ona w dużej mierze opiera się na modelu. Każde pytanie zaczyna się od jakiegoś nazwy lub numeru, a to, co zwraca pierwsza wywołana funkcja, decyduje o tym, czy agent może przystąpić do pracy, czy zacznie zgadywać. W przypadku małego modelu to wywołanie zwracało wartość pustą w 10% epizodów o określonej strukturze, 26% epizodów prostych oraz 53% epizodów znormalizowanych, gdy wyszukiwanie prowadziło do wierzchołka Attribute, a nie do entity. W przypadku modelu typu frontier to wywołanie nigdy nie zwracało wartości pustej, niezależnie od struktury. Dlatego zmarnowany pierwszy ruch to nie tylko właściwość grafu – to efekt spotkania słabszego modelu z punktem wejścia, którego się nie spodziewał. Należy stworzyć infrastrukturę dla modelu, który będzie działał w produkcji, a nie dla tego używanego podczas testów.
Celowo używaj denormalizacji i przyznaj to, gdy faktura jest sprzeczna. Jeden z użytych skrótów, held_by, został zaimplementowany z założeniem, że będzie przydatny w ścieżce od roszczenia do posiadacza. W tym przypadku osiągnął wynik 0,83 w porównaniu z 0,33 w wersji znormalizowanej, natomiast wersja prostsza dała wynik 0,92 przy tym samym pytaniu bez skrótu, więc kredyt nie jest dostępny, a test czysty (przeprowadzony z uwzględnieniem brzegów i bez nich) nie został wykonany. Brakujący skrót uczy więcej. Liczenie rodzajów pokrycia w polisach posiadaczy dało wynik 0,17 w dobrze zaprojektowanym grafie i 0,67 w wersji prostszej, co pozwala traktować je jako jedną czytelną właściwość. Przy agregacji w podgrafie projekt proponowany przegrał z tym oznaczonym jako uszkodzony. Wybór skrótów to element projektu, obciążenie pracy pokazuje, które są potrzebne, a tutaj wybrano niewłaściwy, co potwierdziły dane.
Ograniczono rozprzestrzenianie się zapytań. Limit wyszukiwania wynoszący dwadzieścia wyników oraz maksymalna liczba przeszukiwań na poziomie trzydziestu oznaczały, że nadmiernie połączony węzeł powodował widoczne, liczbalne dodatkowe wywołania, a nie jeden ogromny odpowiedź. Nie uruchamiano żadnych nieograniczonych procesów, więc oszczędności pozostają nieznane. Wiadomo natomiast, że bez takich ograniczeń koszt ukrywa się w wielkości odpowiedzi, której nie analizuje żadna metryka liczby wywołań.
Uczyń nieobecność czytelną i oceniaj ją uczciwie. Traktuj obszar nieodpowiedzi jako wymóg projektowy, a nie podstęp w teście, ale umieść go obok obszaru z odpowiedziami. System Flat uzyskał doskonałą ocenę 1,000 w kategorii odmów, odrzucając osiemnaście pytań, na które mógł odpowiedzieć. System Shaped odrzucił najmniej pytań, a dwa przypadki nieodpowiedzi skończyły się rezygnacją zamiast wymyślania czegoś. Dobra ontologia pozwala, by stwierdzenie „nie modelujemy tego” było zarówno osiągalne, jak i prawdziwe, a ocena wymaga obu tych aspektów, aby odróżnić graf świadomy swoich ograniczeń od takiego, który nie potrafi zlokalizować swoich własnych elementów.
Nazwy to API. Agent odczytuje nazwy elementów tak, jak programista odczytuje sygnaturę funkcji, a w tym eksperymencie celowo łączy nazewnictwo i strukturę w jedną zmienną o nazwie „design”. Żaden numer sam w sobie nie potwierdza tej zasady. Oczywistym następnym krokiem jest rozdzielenie tych dwóch elementów, a stwierdzenie tego jest lepsze niż twierdzenie czegoś więcej, niż zostało zmierzone.
Czym to nie jest
To nie jest test wydajności bazy danych grafowych. Wszystkie trzy rozwiązania korzystają z jednego konta Cosmos DB, jednego warstwy narzędziowej oraz tych samych domyślnych ustawień indeksowania, więc elementy przechowywania są stałe, a nie zmienną, i nic nie porównuje Cosmos z żadną inną bazą danych grafowych ani jej nie dostosowuje. Nie twierdzi również, że sam przeglądanie jest jedynym sposobem, w jaki agenty produkcyjne powinny pobierać dane, ponieważ niejasne zapytania bez wyraźnego punktu wejścia wymagają wyszukiwania; wyniki pokazują, gdzie zwykłe przeglądanie ma sens, a gdzie nie. Nie przedstawia argumentów przeciwko normalizacji w systemach transakcyjnych, ponieważ normalizowana struktura jest tutaj niewłaściwa dla tego użytkownika – agenta płacącego za każdy krok – a nie błędna w ogólności. To również nie jest porównanie dostawców: Microsoft Foundry jest elementem stałym, a nie zmienną, a ta metoda mogłaby być zastosowana na każdej platformie z możliwością wywoływania funkcji.
Czy baza danych w pętli zmieniłaby wynik? To wymaga odpowiedzi, a nie zapewnienia. Przed przeprowadzeniem testowanych kampanii te same cztery narzędzia zostały zaimplementowane dwa razy – za pośrednictwem Cosmos oraz w odniesieniu do plików wytwarzanych przez generator – a zarejestrowane wywołania narzędzi zostały ponownie przetworzone w obu przypadkach: 3 056 różnych wywołań, każda unikalna para narzędzia i argumentu powstała w wyniku kampanii. Obie implementacje dały identyczne wyniki we wszystkich przypadkach. Baza danych nadal odgrywa rolę – dodaje opóźnienie i jednostki żądań, a Cosmos wymaga mniej więcej o 4% więcej kroków agenta w porównaniu z wersją opartą na plikach, przy czym prawie cała ta różnica dotyczy znormalizowanego grafu. Jednak odpowiedzi otrzymane przez agenta pochodziły z struktury ontologii, a nie z silnika znajdującego się poniżej, co jest wystarczające do porównania. Ponowne przetwarzanie znajduje się w repozytorium jako skrypt.
Ograniczenia narzędzia
Kilka zastrzeżeń pochodzi z badań nad routerami. Czterdzieści syntetycznych pytań w jednej syntetycznej domenie daje niewielki instrument pomiarowy. Kontrasty są wyraźne, ponieważ kształty stanowią archetypy, a ontologia produkcji znajduje się pomiędzy nimi, dlatego to właśnie punkty końcowe zostały zmierzone. Kampania z małym modelem przeprowadzona została trzy razy, a jej poziom szumu jest stale podawany. Sieć z dużym modelem przeprowadzona została tylko raz, więc tylko jej nasyczone wyniki – trzydzieści poprawnych odpowiedzi na dwa kształty – są łatwe do zaufania. Luka dwóch pytań w tej sieci uznawana jest za anegdotę, a nic tutaj nie opiera się na niej. Porównano również tylko jeden mały i jeden duży model, więc krzywa pomiędzy nimi pozostaje niewymierzona.
Audyt kodu przed wydaniem ujawnił dwa błędy w tym narzędziu. Po pierwsze: gdy żądany typ krawędzi nie występuje w grafie, funkcja traverse zwraca pustą listę sąsiadów, co jest nierozróżnialne od węzła, który rzeczywiście nie ma sąsiadów. Agent wykonał 112 takich wywołań w ramach różnych kampanii, a dziewięć z dwudziestu dwóch fałszywych odmów na znormalizowanym grafie zawiera takie przypadki; skrypt analityczny liczy je obie. Różnica w wynikach nadal istnieje, ponieważ narzędzie shaped wykonało najwięcej takich wywołań, ale odrzuciło najmniej pytań. Mimo to narzędzie odpowiadające „nic tu nie ma” zamiast „takiego typu krawędzi nie ma” stanowi źródło zamieszania, a uczciwą alternatywą jest błąd w nazewnictwie dostępnych typów. Po drugie: dowód braku strat porównuje zrekonstruowane fakty, więc nie może dostrzec krawędzi, które same w sobie nie przenoszą żadnych faktów, co odnosi się do krawędzi łączących w narzędziu flat oraz pochodnych skrótów w narzędziu shaped. Druga weryfikacja sprawdza teraz te krawędzie pod kątem faktów, które przytaczają, i wykrywa usunięcia oraz błędne odsyłacze dla każdej z nich. Kampanie powstały przed tą weryfikacją, więc gwarancja nie istniała w momencie ich uruchomienia.
Kształt to instrukcja systemu
Wiele wysiłku wkłada się w słowa umieszczone przed modelem, a prawie żadnego w kształt wiedzy, która za nim stoi. Dla agenta używającego narzędzi ontologia stanowi instrukcję: określa możliwe działania świata, zapisane w typach węzłów i nazwach krawędzi, i są one odczytywane po jednej prośbie o użycie narzędzia. Należy ją zaprojektować z myślą o rzeczywistym odbiorcy.
Materiały pomocnicze znajdują się w repozytorium kodu eksperymentu: baza faktów, trzy ontologie, dowód braku strat, pytania, orakulum, agent oraz każdy dowód realizacji kampanii. Każdy, kto przedstawi tę samą prawdę w czwarty sposób i pokaże lepsze wyniki w pytaniach, które pokonały te poprzednie rozwiązania, wniesie coś wartościowego do porównania.
Aby uzyskać więcej informacji na temat użytych komponentów, odpowiednia dokumentacja referencyjna omawia Azure Cosmos DB dla Apache Gremlin, wywoływanie funkcji za pomocą modeli Microsoft Foundry oraz API Azure Retail Prices REST, które dostarczało ceny za token jako podstawę do obliczania kosztów.