OG-RAG: ontologia jako mapa dla wyszukiwania wiedzy

OG-RAG oznacza Ontology-Grounded Retrieval-Augmented Generation: próbę prowadzenia wyszukiwania przez jawnie opisane pojęcia i relacje, zamiast polegania wyłącznie na podobieństwie fragmentów tekstu. W pracy badawczej OG-RAG autorzy proponują reprezentację opartą na ontologii i hipergrafie, aby lepiej dobierać kontekst do odpowiedzi modelu. To metoda badawcza, nie gotowy standard ani uniwersalna aplikacja do instalacji.

Dlaczego sama bliskość wektorowa nie wystarcza?

Pytanie „kto zatwierdził zmianę dostawcy dla zamówienia klienta?” wymaga przejścia przez kilka relacji: klient → zamówienie → dostawca → zmiana → zatwierdzający. Trafny semantycznie fragment może mówić o dostawcy, lecz nie o tym konkretnym zatwierdzeniu. Ontologia definiuje, jakie typy obiektów istnieją i które relacje są sensowne. Dzięki temu retrieval może szukać ścieżki odpowiadającej pytaniu, a nie luźnego zestawu podobnych akapitów.

Nie oznacza to, że ontologia „dowodzi” prawdziwości odpowiedzi. Jeśli mapowanie dokumentów na obiekty jest błędne, wynik nadal będzie błędny. Dlatego trzeba przechować identyfikator dokumentu, wersję, fragment źródłowy i czas aktualizacji. Przewodnik budowy ontologii firmy opisuje, jak wypracować te podstawy zanim użyjemy ich w RAG.

Różnica względem GraphRAG

GraphRAG Microsoft Research wydobywa graf z korpusu i potrafi podsumować większe społeczności encji. OG-RAG akcentuje ugruntowanie w modelu pojęciowym, który organizuje fakty i zapytania. W praktyce granica nie jest absolutna: system GraphRAG można ograniczyć ontologią, a OG-RAG może używać grafu wyekstrahowanego z dokumentów. O wyborze decydują pytania, jakość ontologii i koszt utrzymania, nie sama etykieta.

Jak przeprowadzić próbę?

Wybierz jeden proces z gotowymi definicjami, np. obsługę reklamacji. Zbuduj małą ontologię (Reklamacja, Produkt, Seria, Przyczyna, Decyzja) i przypnij do rekordów dowody źródłowe. Przygotuj pytania wymagające jednej i kilku relacji. Porównaj OG-RAG z prostym RAG pod względem poprawności obiektów, kompletności dowodów, aktualności i czasu odpowiedzi. Mierz także przypadki, w których system powinien odpowiedzieć „nie wiem”.

Największy koszt może leżeć poza modelem językowym: w uzgodnieniu pojęć, zasilaniu grafu i pilnowaniu uprawnień. Jeśli organizacja ma już utrzymywaną ontologię, OG-RAG jest interesującym sposobem jej wykorzystania. Jeśli nie, warto najpierw sprawdzić, czy zwykły RAG nie rozwiązuje problemu prościej.

Jaki jest minimalny kontrakt między ontologią a dokumentem?

Każdy fakt używany do odpowiedzi powinien mieć co najmniej typ obiektu, stabilny identyfikator, typ relacji, źródło i czas ważności. Dla zdania „reklamacja R dotyczy partii P” potrzebne są dwa obiekty oraz relacja z dowodem: dokument jakości, rekord CRM albo zdarzenie w systemie produkcyjnym. Gdy autor dokumentu używa skrótu lub starej nazwy produktu, mapowanie musi być jawne. Bez tego ontologia może dodać pozór precyzji do błędnie przypiętego fragmentu.

Warto rozdzielić trzy etapy. Modelowanie mówi, jakie relacje są dopuszczalne. Ekstrakcja ustala, które relacje występują w konkretnym materiale. Retrieval decyduje, jaką ścieżkę i dowody pokazać modelowi. Każdy etap ma inne błędy i innego właściciela. Ekspert dziedzinowy może zatwierdzić definicję PrzyczynaAwarii, ale nie potwierdzi automatycznie, że ekstraktor poprawnie rozpoznał przyczynę w raporcie serwisowym.

Dlatego w próbie oznacz pytania, które wymagają relacji nieobecnych w ontologii. System powinien wtedy zgłosić lukę w modelu lub brak dowodu, zamiast dopisać krawędź z intuicji LLM. Przy ocenie patrz na precyzję identyfikacji obiektów, kompletność relacji, poprawność cytowania i liczbę odmów. Wynik pracy badawczej OG-RAG jest inspiracją do projektu; przy produkcji potrzebny jest jeszcze nadzór nad ewolucją ontologii i danych.