RAG czy graf wiedzy? 2 160 ocenionych odpowiedzi i wpływ modelu

Dlaczego w ogóle mierzyć?

Dyskusje na temat korporacyjnego asystenta technicznego zwykle utykają w tym samym miejscu. Jedna strona opowiada się za RAG, druga za grafem wiedzy – obie strony przedstawiają mocne argumenty, ale żadna nie podaje liczb. Eksperyment kontrolowany może dostarczyć takich danych: dwa podejścia, trzy rodziny modeli, trzy powtórzenia oraz 120 pytań z odpowiedziami referencyjnymi, co daje 2160 ocenionych odpowiedzi. Każdą odpowiedź oceniano za pomocą metryki deterministycznej oraz przez panel trzech sędziów.

Wyniki są mniej satysfakcjonujące, niż by ktoś chciał. Nie ma absolutnego zwycięzcy, kierunek efektu zmienia się w zależności od modelu, a zmienna o największym wpływie to nie żadna z tych strategii – chodzi o to, jaki model znajduje się u podstaw systemu.

Dla szybkiego przeczytania:

• Graph przewyższył RAG z istotnością statystyczną tylko w przypadku jednego z trzech modeli.
• Komisja sędziowska wyróżniła RAG we wszystkich trzech przypadkach.
• Zmiana modelu poprawiła jakość bardziej niż zmiana strategii.
• Zbiór danych jest syntetyczny, a klucz odpowiedzi został stworzony przez eksperymentatora, co ogranicza to, co można przenieść na inne przypadki.

W pierwszej kolejności wymieniane są ograniczenia, ponieważ one decydują o tym, czy reszta tekstu jest warta przeczytania.

Co badanie obejmuje, a czego nie obejmuje

Mierzy, która strategia wyszukiwania daje bardziej poprawne, kompletniejsze i łatwiejsze do prześledzenia odpowiedzi na temat ekosystemu mikrosług, przy tym model generujący pozostaje niezmienny w ramach każdego porównania.

Nie bada praktycznej użyteczności wśród rzeczywistych programistów, kosztów konserwacji w czasie, jakości ocenianej przez osoby znające ten obszar, ani zachowania w rzeczywistej dokumentacji, w tym jej nieścisłości i luki.

Nie mierzy również górnego limitu podejścia opartego na grafach. Graf tutaj jest celowo prosty, z sąsiedztwem jednoetapowym oraz nieprecyzyjnym dopasowywaniem entytetów. Graf umożliwiający zapytania wieloetapowe i agregację globalną mógłby odpowiadać na pytania, na które ten nie jest w stanie, więc część wad grafu przedstawionego w tabelach wynika z implementacji, a nie z samego paradygmatu.

Problem

Firma przeszła na mikrosługi. Tam, gdzie kiedyś cała baza kodu mieściła się w jednym miejscu, teraz istnieją dziesiątki usług, kontraktów, zdarzeń i baz danych. Wiedza ta jest rozproszona w plikach README, wewnętrznym katalogu, tablicy operacyjnej oraz w umysłach trzech osób, które ją doskonale znają. Codzienne pytania są banalne, ale kosztowne: która aplikacja przechowuje dane osobowe, od czego zależy usługa X, czy coś takiego już istnieje i czy można to ponownie wykorzystać? Obecnie rozwiązaniem jest zapytanie kogoś lub przeczytanie dokumentacji, która może być przestarzała, a prawdziwym kosztem nie jest czas wyszukiwania, lecz decyzja techniczna podjęta na podstawie starych informacji.

Asystent konwersacyjny mógłby rozwiązać problemy z dostępem, o ile jest specjalizowany w danej dziedzinie, a literatura przedmiotu proponuje dwa podejścia.

Niestrukturowane wyszukiwanie (RAG) dzieli dokumentację, indeksuje ją w magazynie wektorowym, pobiera fragmenty najbardziej podobne do pytania i włącza je do promptu. Termin ten pochodzi od Lewisa i jego współpracowników z 2020 roku, a Gao i jego współpracownicy przedstawiają najnowsze osiągnięcia w tym obszarze. Jest tani w utrzymaniu i radzi sobie ze zmianami bez konieczności ponownego szkolenia, ale słabo radzi sobie w sytuacjach, gdy odpowiedź wymaga rozumowania opartego na wyraźnych związkach.

Strukturalne wyszukiwanie (graf wiedzy) modeluje ekosystem jako węzły i krawędzie o określonych typach: usługa, zespół, wydarzenie, baza danych, zależność. Zapytania są deterministyczne i możliwe do śledzenia, chociaż modelowanie i zarządzanie grafem jest kosztowne. Przegląd grafów wiedzy autorstwa Hogana i jego współpracowników stanowi standardową referencję.

Oba podejścia łączą się w GraphRAG, i to właśnie w tym kierunku wskazują wyniki tego eksperymentu.

Projekt

Najważniejsza decyzja zapadała jeszcze przed napisaniem jakiegokolwiek kodu: tylko warstwa wiedzy może się różnić. Bez tej zasady porównuje się dwie implementacje, a nie dwie strategie. Każda różnica w formacie promptu lub wyniku zakłóca rezultat w sposób, którego nie da się później oddzielić, dlatego wiele nieformalnych benchmarków RAG ostatecznie mierzy umiejętności osoby, która napisała prompt.

Oba podejścia zwracają dokładnie ten sam kontrakt odpowiedzi: pytanie, podejście, odpowiedź, źródła, odzyskany kontekst, opóźnienie i szacowany koszt. Dzięki temu kod oceny, API oraz interfejs pozostają niezależne od wybranej metody.

Test wymagał realistycznego, publikowalnego i powtarzalnego ekosystemu, a wykorzystanie rzeczywistego ekosystemu pracodawcy było niemożliwe. Dlatego w ramach przygotowań stworzono CreditXPTO – nieistniejącą firmę z branży fintech zajmującą się kredytami osobistymi.

Korzystanie z rozwiązań syntetycznych przynosi trzy korzyści. Treść jest kontrolowana, zna się poprawną odpowiedź na każde pytanie, a każdy może ponownie przeprowadzić tę pracę bez dostępu do systemów wewnętrznych. Cena, jaką trzeba za to zapłacić, to zewnętrzna ważność, główna ograniczenie omówione na końcu.

W obu reprezentacjach znajdują się te same informacje, a równoważność jest zapewniana przez reguły walidacji działające w ramach ciągłej integracji: błędna odniesienie sprawia, że zbiór danych staje się nieważny. W przeciwnym razie jedna ze stron mogłaby potajemnie posiadać więcej wiedzy niż druga. 120 pytań jest sklasyfikowanych według kategorii (faktograficzne, wyjaśniające, dotyczące wpływu, relacyjne, odkrywcze, niejednoznaczne), poziomu trudności oraz rodzaju wiedzy, a każde z nich ma przewidzianą odpowiedź oraz źródła.

Część RAG wykorzystuje fragmenty składające się z 512 tokenów z nakładaniem się 50 tokenów oraz parametr top-k równy 5. Embeddingi pochodzą z modelu BAAI/bge-small-en-v1.5 uruchamianego lokalnie, przy czym jako magazyn wektorów służy Qdrant. Proces wyszukiwania gęstego odbywa się zgodnie z schematem opracowanym przez Karpukhina i współpracowników (DPR), embeddingi zdań pochodzą od Sentence-BERT, a rodzina modeli BGE jest opisana w C-Pack.

Część grafowa wykorzystuje bibliotekę NetworkX w pamięci, budowaną bezpośrednio na podstawie plików źródłowych, dzięki czemu zawsze odpowiada danym. Dopasowywanie entytetów odbywa się w sposób nieprecyzyjny przy progu 70/100, a wyszukiwanie obejmuje sąsiedztwo jednego poziomu.

Ocena

Ocena odbywa się na dwóch poziomach. Pierwszy poziom jest heurystyczny: opiera się na podobieństwie leksykalnym, obecności kluczowych entytetów oraz stopniu pokrycia źródła. Jest tani, deterministyczny i powtarzalny, ale jednocześnie powierzchowny, ponieważ kara parafrazowanie. To znany defekt metryk opartych na nakładaniu się n-gramów, a także powód istnienia alternatyw semantycznych takich jak BERTScore.

Drugi poziom polega na ocenie przeprowadzonej przez trzech sędziów z modeli językowych, po jednym z każdej rodziny modeli, którzy oceniają poprawność, kompletność, uzasadnienie i klarowność w skali od 0 do 3. Paradygmat wykorzystania modeli językowych jako sędziów został ugruntowany przez Zhenga i jego współpracowników dzięki MT-Bench.

Jedna kwestia jest kluczowa: główna miara dotyczy różnych rodzin modeli. Dla każdej odpowiedzi sędzia z tej samej rodziny generatora nie bierze udziału w obliczeniach. Modele rozpoznają swój własny tekst i oceniają go wyżej, a Panickssery i współpracownicy (2024) łączą tę samoprzedpożycie z tym samorozpoznaniem. Jedynym sposobem na zneutralizowanie tego efektu jest podejście strukturalne, a nie prośba o bezstronność w instrukcjach.

Znaczenie wyników określa test McNemar w wersji sparowanej, ponieważ obie strategie odpowiadają na te same pytania. Przedziały obliczane są metodą bootstrap z 5 000 ponownych prób, a zgodność ocen sędziów mierzona jest za pomocą współczynnika Kappy Cohena.

Wyniki

Pierwsza tabela przedstawia dokładność bezwzględną, przy której liczone są tylko w pełni poprawne odpowiedzi – w każdej komórce znajduje się n = 360:

Ważne są dwie interpretacje.

Najpierw oznaka zmienia się w zależności od modelu. RAG wygrywa przy użyciu dwóch generatorów, a graf przy użyciu trzeciego, przy czym tylko ta ostatnia różnica jest istotna. Przeprowadzenie eksperymentu z jednym modelem, jak to robi większość benchmarków, doprowadziłoby do pewnego, błędnego wniosku wraz z przedziałem ufności. W rezultacie nie byłoby żadnego wskazania na to.

Po drugie, różnica między modelami przewyższa różnicę między podejściami. Przejście z claude-sonnet-4-6 na gpt-5.5 przynosi większą korzyść niż zmiana strategii w obrębie danego modelu. To sprowadza pytanie „RAG czy graf?” do decyzji drugiego rzędu, co stanowi kluczowe ustalenie całego badania.

Powtórzenie testu przy szerokiej definicji, przyznawanie pełnych punktów oraz częściowych punktów oraz karanie jedynie za oczywiste błędy zmienia sytuację. RAG teraz znacznie przewyższa dwa pierwsze modele, a przewaga grafu w przypadku trzeciego przestaje być istotna. Dokładna interpretacja jest taka, że zaletą RAG nie jest częstsze trafianie, lecz mniej poważne błędy. Gdy pobieranie informacji jest częściowe, system odpowiada niekompletnie. Gdy dopasowanie entytetów nie udaje się, graf udziela błędnego, ale pewnego siebie odpowiedzi. Dla wewnętrznego asystenta ta różnica jest kluczowa: programista może uzupełnić niekompletną odpowiedź, natomiast błędna odpowiedź z podanym źródłem może trafić na spotkanie.

Następnie przedstawiono wyniki komisji oceniającej:

Zespół woli RAG we wszystkich trzech modelach, w tym w tym, w którym heurystyka przyznała grafowi znaczącą przewagę. To efekt narzędzia, a nie sprzeczność. W jednym konkretnym przypadku pytanie uzyskało wskaźnik podobieństwa leksykalnego 0,25 i zostało sklasyfikowane jako błędne przez heurystykę, jednak zespół przyznał mu 2,88 na 3 punkty. Odpowiedź była prawidłowa, tylko sformułowana inaczej. Metryki N-gram mierzą słownictwo, natomiast oceny LLM mierzą postrzeganą poprawność, z pewnym uprzedzeniem. Żadna z nich sama w sobie nie odpowiada na pytanie, a gdy się różnią, ta różnica wskazuje, gdzie należy szukać rozwiązania.

Zespół zasługuje na szczere zastrzeżenie: zgodność między sędziami była jedynie umiarkowana, przy współczynniku Kappa Coena w zakresie od 0,09 do 0,56. Zespół sędziów LLM nie jest narzędziem do pomiaru precyzji. Jest to ustrukturyzowana druga opinia, a frameworki takie jak RAGAS istnieją właśnie dlatego, że ocena generacji wzbogaconej o wyszukiwanie pozostaje otwartym problemem.

Jeśli chodzi o opóźnienie, RAG był o 12 do 20% szybszy we wszystkich trzech modelach. Kontekst w grafie jest bardziej zwięzły, ale zapytanie wymaga dodatkowego kroku. Koszt różni się w zależności od modelu – graf jest tańszy przy dwóch generatorach, a droższy przy jednym. Mieszanka tokenów wejściowych i wyjściowych różni się wystarczająco między dostawcami, by zmienić ich wartość. To jest obserwacja, a nie wniosek, ponieważ skład tokenów nie został formalnie przetestowany.

Jak każde podejście zawodzi

To jest najbardziej przydatna część, a nie pojawia się w żadnej tabeli.

Wykres zawodzi pod względem strukturalnym. Gdy zapytano, jaką bazę danych używa dany serwis, system zwrócił identyfikator węzła, a nie silnik, ponieważ ten atrybut nie został uwzględniony w modelu. Gdy zapytano, ile zespołów używa danej technologii, sąsiedztwo jednego kroku wykryło dwa serwisy, a system z pewnością siebie odpowiedział, że jest ich około dwóch. A jeśli algorytm dopasowywania wybierze niewłaściwą jednostkę, cały kontekst staje się błędny, przy czym nic tego nie sygnalizuje.

RAG zawodzi z powodu niekompletności. Poprawnie identyfikuje, że serwis używa Redis, ale ogranicza odpowiedź do zidentyfikowanego serwisu, podczas gdy pytanie wymagało informacji o sytuacji ogólnej.

Oba podejścia są błędne, choć w inny sposób. Wady te są wzajemnie uzupełniające, i właśnie dlatego oczywistym rozwiązaniem jest hybryda, z routowaniem według typu pytania.

Zalecenia

• Najpierw wybierz model. To zmienna o największym wpływie. Traktowanie jej jako szczegółu implementacyjnego podczas tygodniowych dostosowań rozmiaru fragmentów optymalizuje parametr drugiego rzędu.
• Zacznij od RAG. Ma lepsze minimalne wymagania i tańsze utrzymanie, a jego tryb awarii jest akceptowalny.
• Dodawaj strukturę w sposób celowy, dotycząc zależności, własności i konsumpcji zdarzeń. Nie próbuj modelować całego ekosystemu przed dostarczeniem jakichkolwiek rozwiązań.
• Nie ufaj żadnej pojedynczej metryce. Używaj heurystyki deterministycznej oraz zestawu z różnych grup. Gdy się różnią, oznacza to pojawienie się interesującego przypadku, a nie błędu.
• Wykorzystaj test sparowany. Obie strategie odpowiadają na te same pytania, a porównywanie średnich bez McNemara daje pewność, której dane nie potwierdzają.

Ograniczenia

• Zbiór danych jest syntetyczny, a klucz odpowiedzi został stworzony przez samego eksperymentatora. Nie został zweryfikowany przez rzeczywistych użytkowników. Dzięki temu zapewnia kontrolę i możliwość powtórzenia eksperymentu, ale kosztem walidności zewnętrznej.
• Implementacja grafu jest celowo prosta, więc niektóre z jej słabości w zakresie agregacji mogą wynikać z samej implementacji, a nie z charakteru paradygmatu.
• Praktyczna użyteczność i łatwość konserwacji nie zostały zmierzone. Należały one do celów projektu i pozostały kwestiami jakościowymi.
• Heurystyka nie została zweryfikowana w porównaniu z oceną ludzką. Grupa ekspercką łagodzi to problem, ale nie rozwiązuje go całkowicie.
• Jedenaście z 2 160 odpowiedzi (0,51%) wynikało z błędów w sieci dostawcy, a nie z błędów systemowych.

Wniosek

Można było mieć nadzieję, że wyniki będą brzmieć „użyj wykresu” lub „użyj RAG”. Okazało się jednak, że żadna z tych odpowiedzi nie istnieje, dopóki nie zostanie rozstrzygnięte pytanie dotyczące modelu, a zmienna traktowana jako tło była tą, która miała największy wpływ. To mniej satysfakcjonujące, ale bardziej praktyczne. Rozwiązanie to ma również zastosowanie poza tym przypadkiem: benchmark z ukrytą zmienną nie daje wyraźnych błędów, lecz błędy te są przedstawiane w postaci przedziału ufności. Zanim wybierzesz architekturę na podstawie liczby, zastanów się, co w eksperymencie pozostawiono niezmienne oraz czy rzeczywiście powinno tak być.

Literatura pokrewna

• Zaawansowana architektura RAG w produkcji: architektura, narzędzia i kompromisy — Przewodnik po zastosowaniu RAG w produkcji: pobieranie danych, analiza, dzielenie na fragmenty, tworzenie wektorów, przechowywanie wektorów, hybrydowe wyszukiwanie, ponowna sortowanie wyników, ocena i zabezpieczenia, wraz z kompromisami związanymi z każdym z tych elementów.
• GraphRAG kontra Vector RAG: dlaczego wyszukiwanie wektorowe zawodzi w dużych skali — Vector RAG ma trudności z izolacją fragmentów, rozumowaniem między dokumentami i skalowalnością. Dowiedz się, jak GraphRAG tworzy struktury wspólnotowe i streszczenia, aby to naprawić, oraz kiedy wybrać jeden z tych podejść.

ROE kontra TechRAG: GraphRAG na Dockerze i Qdrant lub na SQLite i LanceDB — Dwie perspektywy na jedną tezę GraphRAG: Qdrant, MongoDB i model o pojemności 120 miliardów parametrów przeciwko LanceDB, SQLite i qwen2.5 o pojemności 7 miliardów parametrów, z porównaniem logiki wyszukiwania i wyciągnięciem wniosków.