Graf wiedzy z AI: strzałka też jest twierdzeniem

Na diagramie firma Linea łączy się z panelem Noma strzałką „produkuje”. W dokumencie napisano, że korzysta z niego podczas zabudowy stoisk. Nazwy są poprawne, panel istnieje, firma też. Tylko strzałka właśnie awansowała użytkownika do roli producenta. To dość hojny sposób rozwijania działalności gospodarczej.

Ten wymyślony przykład pokazuje podstawowy problem odbioru grafu wiedzy tworzonego z pomocą AI. W grafie zapisuje się obiekty i ich powiązania, które później służą do szukania odpowiedzi. Błąd może dotyczyć samej relacji, mimo że każdy obiekt został rozpoznany prawidłowo. Dlatego kontrola listy nazw nie wystarcza. Trzeba przeczytać również każde znaczące połączenie.

Przeczytaj strzałkę jako pełne zdanie

Zamiast zaczynać od atrakcyjnej wizualizacji, zapisz wynik zwykłym językiem: „Linea produkuje panel Noma”. Wskaż wykonawcę czynności, rodzaj powiązania i drugi obiekt. Następnie odszukaj fragment źródła, który rzeczywiście uzasadnia całe zdanie. Podświetlona obecność obu nazw w tym samym akapicie jest dopiero początkiem sprawdzania, nie jego zakończeniem.

W specyfikacji RDF 1.1 Concepts podstawową konstrukcję opisano jako trójkę: podmiot, predykat i obiekt. Predykat, czyli środkowy element takiego zapisu, określa relację między zasobami. To konkretny model danych; nie każdy firmowy graf musi używać RDF. Do odbioru przydaje się jednak proste pytanie: kto pozostaje z kim w jakiej relacji?

Dla naszej próbki odpowiedź brzmi „Linea używa panelu Noma”. Odwrócenie kierunku dałoby „Noma używa Linei”, a zmiana typu na „produkuje” stworzyłaby inne twierdzenie. Oba błędy są czymś więcej niż niewłaściwym wyglądem wykresu. Mogą zmienić listę dostawców, wynik wyszukiwania części albo opis kompetencji partnera. Zapisana relacja powinna mieć tę samą treść co zaakceptowane zdanie.

Najpierw potwierdź tożsamość obiektów. Dwie firmy mogą nosić podobną nazwę, a produkt i seria produktowa mogą zostać pomieszane. Ten etap rozwija kontrola fałszywego łączenia rekordów przez AI. Dopiero po rozdzieleniu obiektów oceniaj strzałkę. Poprawny rodzaj relacji przypięty do innej firmy nadal daje fałszywą informację.

Rozróżnij produkt, egzemplarz i realizację. Użycie jednej sztuki panelu podczas jednego wydarzenia nie znaczy, że firma stale pracuje z całą serią. W próbce opisz zasięg twierdzenia: który produkt, w jakiej roli i przy jakim zadaniu. Bez tego poprawna strzałka może zostać rozszerzona na wszystkie realizacje tylko dlatego, że przyjęty model danych nie przewiduje bardziej szczegółowego zapisu.

W próbie zachowaj identyfikator każdej relacji, oba końce, nazwę typu i wskazanie dokumentu. Odczytuj wynik z danych, z których korzysta aplikacja, a nie wyłącznie z podpisu na diagramie. Warstwa wizualna może skracać nazwy albo zbierać kilka powiązań w jedną linię. Odbiorca powinien umieć dojść od pytania klienta do konkretnego zapisu i jego podstawy.

Cztery materiały o tych samych nazwach

Przygotuj krótki zestaw kontrolny na fikcyjnych danych. Niech w każdym materiale pojawiają się Linea i Noma, ale za każdym razem w innym związku:

• Linea używa panelu Noma przy realizacji stoisk. Oczekujemy relacji użycia, bez dopowiadania produkcji i własności.
• Linea rozważa użycie panelu Noma w przyszłym sezonie. To zamiar, a nie potwierdzone bieżące zastosowanie.
• Linea nie produkuje panelu Noma; zamawia go od wskazanego dostawcy. Zaprzeczenie nie powinno stać się potwierdzeniem produkcji.
• Do końca poprzedniego sezonu Linea korzystała z Nomy, potem wybrała inną serię. Relacja historyczna nie powinna odpowiadać bez zastrzeżeń na pytanie o obecne wyposażenie.

Uzgodnij oczekiwany wynik przed uruchomieniem ekstrakcji, czyli wydobywania informacji z tekstu. Jeśli schemat grafu nie pozwala zapisać zamiaru, zaprzeczenia lub okresu, ustal, co dzieje się z takim fragmentem. Można skierować go do ręcznego rozstrzygnięcia. Nie powinien być automatycznie wciskany w najbliższą dostępną relację tylko dlatego, że aplikacja musi coś narysować.

Dodaj także zdanie będące cudzą wypowiedzią: „Podczas spotkania klient pytał, czy Linea produkuje Nomę”. Pytanie nie potwierdza relacji, choć zawiera dokładnie te słowa, których szuka prosty mechanizm. Podobnie sprawdź przytoczenie starej propozycji w nowym dokumencie. Aktualna data pliku nie zmienia dawnego przypuszczenia w aktualny fakt.

Nie oceniaj wyłącznie liczby odnalezionych połączeń. Wynik bogatszy o trzy bezpodstawne strzałki może wyglądać imponująco, lecz pogarszać odpowiedzi. W naszym zestawie odróżnij brak wymaganej relacji od dodania relacji nieuzasadnionej. Zapisz też przypadek, w którym narzędzie poprawnie wstrzymało się z rozstrzygnięciem. Pusta lista i świadomy brak podstaw wymagają innego opisu w raporcie.

Uwzględnij materiał, w którym nazwy występują obok siebie bez wspólnej relacji: lista wystawców wymienia Lineę, a osobny boks prezentuje Nomę. Bliskość na stronie nie dowodzi używania produktu. Jeśli tekst pobiera się z PDF, obejrzyj również kolejność odczytu kolumn. Połączenie dwóch niezależnych bloków może stworzyć zdanie, którego autor dokumentu nigdy nie napisał.

Schemat porządkuje rodzaje, a źródło uzasadnia treść

Dokumentacja Neo4j GraphRAG Python opisuje prowadzenie ekstrakcji przez typy węzłów, relacji i wzorce łączące obiekt początkowy z docelowym. To użyteczny sposób określenia oczekiwanej struktury. Sam dozwolony wzorzec „firma używa produktu” nie dowodzi jednak, że ta konkretna firma rzeczywiście używa tego produktu.

Własny słownik relacji przygotuj z osobami znającymi materiał. „Dostarcza”, „sprzedaje”, „produkuje” i „serwisuje” mogą dotyczyć tej samej pary podmiotów, ale nie są wymienne. Do każdej nazwy dopisz krótką definicję i przykład, którego nie obejmuje. Jeśli relacja ma znaczyć „dostarcza w ramach tej realizacji”, nie skracaj jej później do bezwarunkowego „jest dostawcą firmy”.

Sprawdź także kierunek zapisany w danych. Zamiana podpisów po polsku może uczynić obraz czytelnym, podczas gdy zapytanie nadal przechodzi od niewłaściwego obiektu. Do próby dodaj pytanie w obie strony: „jakich paneli używa Linea?” i „kto używa Nomy?”. Oczekiwane wyniki powinny wynikać z tej samej poprawnej relacji, a nie z dwóch osobno dopisanych odpowiedzi demonstracyjnych.

Podstawę źródłową przypisuj do relacji, a nie tylko do całego obiektu. Dokument o firmie może uzasadniać adres i branżę, lecz nie rolę przy konkretnym produkcie. Zapisz fragment, jego położenie i wersję materiału. To rozwinięcie architektury wiedzy w firmie: właściciel źródła i jego status nadal mają znaczenie po przeniesieniu informacji do grafu.

Jeśli jedno powiązanie ma kilka źródeł, odróżnij niezależne potwierdzenia od kolejnych kopii tej samej wiadomości. Trzy dokumenty mogą powtarzać jeden niezweryfikowany opis. Ich liczba nie zwiększa automatycznie wiarygodności relacji. W protokole pokaż, czy dodano nową podstawę, czy tylko kolejne miejsce wystąpienia tej samej informacji. Nie usuwaj pochodzenia podczas łączenia podobnych zapisów.

Ustal reakcję na usunięcie lub wycofanie dokumentu. Samo zniknięcie pliku nie dowodzi, że opisana współpraca nie istniała. Może natomiast odebrać zespołowi możliwość sprawdzenia podstawy. W raporcie odróżnij relację zakwestionowaną po ocenie treści od relacji, której źródło stało się niedostępne. Pozostawienie obu pod etykietą „aktualne” utrudnia późniejszą rozmowę o wiarygodności odpowiedzi.

Czas ma dotyczyć relacji, nie daty uruchomienia

Data utworzenia strzałki mówi, kiedy system ją zapisał. Data publikacji dokumentu mówi, kiedy udostępniono materiał. Okres obowiązywania opisanej współpracy jest jeszcze inną informacją. Gdy źródło opisuje realizację sprzed dwóch lat, dzisiejszy import nie czyni jej bieżącym kontraktem. W próbie zaznacz te trzy momenty osobno, nawet jeśli na ekranie użytkownik widzi tylko krótkie objaśnienie.

Zbuduj przypadek zakończonej relacji. Stary dokument opisuje użycie Nomy, nowsza notatka potwierdza zmianę wyposażenia. Sprawdź odpowiedź na pytanie historyczne i na pytanie o aktualny stan. Zastąpienie starej strzałki nową może usunąć potrzebną historię, natomiast pozostawienie obu bez okresu może sugerować równoczesne używanie dwóch serii. Reguła zależy od zadania, któremu służy graf.

Zapisz też, co dokładnie znaczy „obecnie” w pytaniu użytkownika. Dla odtwarzania dawnej oferty punktem odniesienia może być data jej przygotowania, a dla obsługi nowego zlecenia dzień odpowiedzi. Ten sam zbiór historyczny może dać różne poprawne wyniki zależnie od tak wskazanego momentu. System powinien ujawnić przyjęte odniesienie, zamiast bez zapowiedzi utożsamiać każde pytanie z ostatnim importem.

Dołóż relację z nieznaną datą końcową. Brak informacji o zakończeniu nie stanowi sam w sobie potwierdzenia trwania współpracy. Zespół powinien ustalić, jak oznaczać taki stan i kiedy żądać sprawdzenia materiału. Sformułowanie „brak potwierdzenia aktualności” jest bardziej użyteczne niż arbitralne przedłużanie relacji do dziś. Nie zastępuj tej decyzji datą ostatniego odświeżenia indeksu.

Przy sprzecznych źródłach zachowaj rozbieżność do oceny. Nowszy materiał może być ważniejszy dla określonego zadania, ale sama nowość nie zapewnia jego poprawności. Sprawdź autora, zakres i status dokumentu. Możliwe, że opisuje inny oddział albo dotyczy tylko jednej realizacji. Rozstrzygnięcie powinno wskazywać, dlaczego dana relacja została przyjęta, ograniczona albo odłożona do potwierdzenia.

Błąd strzałki sprawdź w odpowiedzi, która z niej korzysta

Poprawienie grafu nie wystarcza, jeśli aplikacja nadal odpowiada na podstawie wcześniejszego wyniku. Przygotuj pytanie o producenta Nomy przed korektą i po niej. W drugim przebiegu oczekujemy odpowiedzi zgodnej z dostępnymi materiałami, a nie płynnego powtórzenia błędnego skojarzenia. Przy odpowiedziach RAG sprawdź także, który fragment rzeczywiście trafił do modelu.

Zobacz, czy relacja nie została powielona podczas importu. Dwa identyczne opisy użycia jednego panelu nie oznaczają dwóch realizacji ani dwóch klientów. Zliczanie powiązań wymaga jasnej jednostki. Podobną pułapkę pokazuje różnica między liczbą wierszy a liczbą spraw w SQL. Wynik zapytania może być technicznie poprawny, lecz odpowiadać na inne pytanie.

Kolejny przypadek to zbyt daleki wniosek. Linea współpracuje z firmą Oś, a Oś korzysta z Nomy. Z tych dwóch zdań nie wynika automatycznie, że Linea także używa tego panelu. Jeżeli rozwiązanie wyprowadza dodatkowe powiązania, oddziel je od relacji wprost odczytanych ze źródła. Odbiorca powinien rozpoznać, które zdanie ma bezpośrednią podstawę, a które powstało przez zastosowanie reguły wnioskowania.

Przy poprawce jednej relacji sprawdź zależne wyniki. Błędne przypisanie produkcji mogło już trafić do zestawienia dostawców albo opisu firmy. Korekta strzałki nie potwierdza, że te materiały zostały odświeżone. Wybierz jeden taki wynik i ustal, jak zostanie ponownie obliczony lub przekazany do poprawy. Pozwoli to ocenić, ile pracy wymaga naprawa jednego błędu, bez rozszerzania próby na wszystkie zastosowania grafu.

Na potrzeby prób można przygotować dane syntetyczne o spójnych relacjach i zdarzeniach. Oznacz je wyraźnie i nie mieszaj z firmową bazą potwierdzonych partnerów. Fikcyjna próbka służy sprawdzeniu zachowania narzędzia; nie potwierdza realnej współpracy. Zachowaj wzorcowe rozstrzygnięcia poza materiałem, do którego model ma zaglądać podczas ekstrakcji.

Na koniec wybierz jedną ważną relację i przejdź drogę od dokumentu do decyzji użytkownika. Czy da się wskazać podmioty, odczytać znaczenie, ocenić okres i otworzyć podstawę? Czy brak dowodu pozostaje widoczny? Taki ograniczony zakres można omówić w ramach Aeneia Audit. Próbę kończy zgodność twierdzenia z materiałem, a nie liczba kolorowych połączeń na ekranie.