Gdy podobieństwo nie jest istotne: budowa korporacyjnego RAG wykraczającego poza wyszukiwanie wektorowe

Wyszukiwanie wektorowe doskonale radzi sobie z wydobywaniem tekstu przypominającego pytanie. Jednak podobieństwo i użyteczność to różne rzeczy, a właśnie ta luka sprawia, że rozwiązania typu RAG w środowiskach korporacyjnych często zawodzą.

Dokument odzyskany może korzystać z słownictwa użytkownika, a mimo to być przestarzały, niedostępny, niepełny lub nieodpowiedni dla danej sytuacji biznesowej. Tymczasem dokument, który faktycznie mógłby odpowiedzieć na pytanie, może być sformułowany inaczej i uzyskać niższy wynik. Problem zazwyczaj nie leży w modelu embeddingu ani w bazie danych wektorowej – chodzi o błędne przekonanie, że podobieństwo semantyczne stanowi pełną definicję istotności, czego w rzeczywistości nie jest.

W firmie istotność zależy od znacznie więcej niż samego sformułowania. Ważną rolę odgrywają aktualność, autorytet, lokalizacja geograficzna, typ dokumentu, uprawnienia użytkownika, stan procesu pracy, zobowiązania umowne oraz powiązania pomiędzy podmiotami gospodarczymi. Niezawodny system musi wziąć pod uwagę wszystkie te czynniki i nie traktować bliskości w przestrzeni wektorowej jako ostatecznego werdyktu.

Jak wyszukiwanie wektorowe stało się standardem

Wyszukiwanie według słów kluczowych opiera się w dużej mierze na dokładnych terminach. Osoba szukająca „polityki odejścia pracowników” może przeoczyć plik zatytułowany „Procedura zakończenia współpracy z pracownikami”, ponieważ oba nie zawierają żadnych wspólnych słów.

Poszukiwanie wektorowe stało się rozwiązaniem tego problemu. Dokumenty są przekształcane w wektory reprezentujące ich znaczenie, a pytanie użytkownika również jest zamieniane na taki sam wektor. System następnie zwraca fragmenty, których wektory znajdują się najbliżej wektora zapytania. Materiały pojęciowo powiązane można znaleźć nawet wtedy, gdy pytanie i źródło używają różnych sformułowań.

Dzięki temu poszukiwanie wektorowe doskonale nadaje się do różnych zadań: obsługi pytań w języku naturalnym, dopasowywania synonimów i parafraz, wyszukiwania w dokumentach niestrukturyzowanych, obsługi zapytań konwersacyjnych lub wielojęzycznych oraz redukcji dużej liczby elementów do krótkiej listy kandydatów.

Te zalety sprawiły, że bazy wektorowe znalazły się w centrum wczesnych projektów RAG, a standardowa procedura wydawała się prosta. Dokumenty były dzielone na fragmenty, każdy fragment otrzymywał wektor reprezentujący jego treść, a następnie te wektory były przechowywane. Podczas zadawania pytania pytanie również było przekształcane w wektor, pobierano najbliższe fragmenty i przekazywano je modelowi językowemu, który następnie generował odpowiedź.

Demo i małe bazy wiedzy funkcjonują dobrze przy takim podejściu. To właśnie w środowiskach korporacyjnych zaczynają pojawiać się trudności.

Podobieństwo to jeden z kilku wskaźników

Wyobraźmy sobie menedżera zakupów, który pisze: „Jakie warunki płatności obowiązują na mocy naszej obecnej umowy z Northstar Components?”

System oparty wyłącznie na wektorach mógłby obejmować aktualną umowę z dostawcą, wygasłą umowę z tym samym dostawcą, szablon zawierający standardowe warunki płatności, e-mail dotyczący proponowanej zmiany, politykę zakupową wspominającą o płatnościach dla dostawców oraz umowę z jakąś inną spółką z grupy Northstar.

Każdy z tych elementów jest semantycznie powiązany z pytaniem, jednak tylko jeden lub dwa mają znaczenie z punktu widzenia funkcjonowania. Prawidłowy wybór oznacza konieczność odpowiedzi na dodatkowe pytania: Do której osoby prawnej odnosi się określenie „nasz”? Która firma z grupy Northstar jest zaangażowana? Czy umowa nadal obowiązuje, a czy poprawki zmieniły pierwotne warunki? Który organ prawny nią rządzi? Czy ten użytkownik ma uprawnienia do jej przeglądania? Czy istnieje podpisana wersja, i który źródło ma najwyższą autorytetowość?

Embedding nie posiada wbudowanego rozumienia takich ograniczeń. Mierzy bliskość w nauczonej przestrzeni semantycznej. Nie może określić, który dokument ma moc prawną lub jest operacyjnie ważny.

W ten sposób wysoki wynik podobieństwa rodzi fałszywą pewność siebie. System pobiera prawdopodobny tekst, model językowy przekształca go w dopracowaną odpowiedź, a gładki styl ukrywa błąd w wyszukiwaniu.

Siedem sposobów, w jakie czyste podobieństwo zawodzi

Kilka powtarzających się wzorców niepowodzeń sprawia, że wyszukiwanie oparte wyłącznie na wektorach jest ryzykowne.

Przestarzały materiał. Stare dokumenty często wyglądają jak te aktualne. Wygasła polisa może być podobna do swojej zastępczyni z wyjątkiem jednego progu, daty lub zasady zatwierdzenia. Ze względu na dużą liczbę wspólnych sformułowań obie uzyskują wysokie oceny. Bez kontroli wersji i daty wejścia w życie system może podawać przestarzałe wytyczne, co jest szczególnie niebezpieczne w pracach regulowanych, gdzie niewielka zmiana w polisie może wpłynąć na zgodność z przepisami, raportowanie lub sposób traktowania klientów.

Ślepotę na autorytet. Notatka z sesji brainstormingu, wewnętrzny e-mail oraz zatwierdzona polityka mogą dotyczyć tego samego tematu, a ta nieformalna może być przedkładana jako pierwsza po prostu dlatego, że jej sformułowanie przypomina pytanie. Wiedza organizacyjna nie funkcjonuje według zasad demokracji. Podpisany kontrakt powinien zazwyczaj mieć większą wagę niż projekt, zatwierdzona procedura powinna być ważniejsza od protokołu ze spotkania, a zweryfikowana dokumentacja regulacyjna powinna przewyższać notatki analityka. Aby coś było istotne, potrzebna jest hierarchia dowodów.

Relacje rozdzielone dzięki dzieleniu na fragmenty. Aby poprawić dokładność i dostosować się do okien kontekstowych, systemy RAG dzielą dokumenty na małe części, co może oddzielić fakty od relacji nadających im znaczenie. Jeden fragment może definiować zobowiązanie płatnicze, inny podawać nazwę dostawcy, a trzeci zawierać zmianę anulującą pierwotną klauzulę. Każda z tych części sama w sobie jest niekompletna, a pobranie najbardziej podobnego fragmentu nie gwarantuje odtworzenia pełnego obrazu sytuacji.

Problemy z dokładnymi identyfikatorami. Embeddingi są optymalizowane pod kątem znaczenia i często słabo radzą sobie z reprezentacją dosłownych ciągów znaków. Typowymi ofiarami są numery części, numery kont, odniesienia do klauzul, kody leków, identyfikatory sprzętu oraz numery wersji. Wyszukiwanie „Model AX-1047” nie powinno zwracać wyniku „AX-1041”, ponieważ opisy tych modeli są do siebie podobne. W biznesowych zastosowaniach wyszukiwania często potrzebna jest zarówno precyzja dosłowna, jak i semantyczna.

Krytyczne ograniczenia. Ludzie często pytają o to, czego brakuje: którzy klienci nie zakończyli weryfikacji, które urządzenia nie podlegają obecnemu umowie konserwacyjnemu, które faktury pozostają niespłacone po 60 dniach, które strony testowe nie przesłały wymaganych dokumentów. Takie pytania opierają się na braku, wykluczeniu lub porównaniu różnych rekordów. Wyszukiwanie podobieństw dostarcza tekstów dotyczących danego pojęcia, ale nie może pewnie określić, co jest nieobecne.

Obiekt przedsiębiorstwa przechodzi przez różne stany, takie jak projekt, złożony, zatwierdzony, wstrzymany, wygasły i archiwizowany. Dwa dokumenty dotyczące tego samego obiektu mogą wyglądać niemal identycznie, choć znajdują się w różnych stanach, a aktualny stan może decydować o tym, czy dany dokument w ogóle jest istotny.

Sama autorizacja nie wystarcza. Najbardziej semantycznie istotny dokument może być takim, którego użytkownik nie ma prawa oglądać. Kontrola dostępu nie może polegać jedynie na instrukcji w komendzie. Treści ograniczone muszą zostać usunięte, zanim trafią do kontekstu modelu, w przeciwnym razie system ryzykuje wyciekem poufnych informacji bezpośrednio lub pozwoleniem modelowi na ich domyślną dedukcję.

Istotność ma wiele wymiarów

W systemach RAG dla przedsiębiorstw istotność najlepiej postrzegać jako połączenie różnych wskaźników: podobieństwa semantycznego, istotności słów kluczowych lub dokładnego dopasowania, autorytetu źródła, ważności czasowej, zgodności z zasadami biznesowymi, kwalifikacji do uzyskania dostępu oraz istotności relacji lub grafu. Wzór rankingu mógłby je połączyć, przyznając każdemu własną wagę.

Waga ma związek z przypadkiem użycia. Wewnętrzny asystent badawczy może przywiązywać dużą wagę do podobieństwa semantycznego. Narzędzie do odpowiadania na pytania w kontekście umów może bardziej skupiać się na datach wejścia w życie i autorytecie źródła. Platforma do prowadzenia dochodzeń może być kierowana przede wszystkim przez relacje pomiędzy ludźmi, wydarzeniami, lokalizacjami i zasobami.

To wcale nie oznacza, że każda organizacja potrzebuje skomplikowanego matematycznego modelu rankingu. Oznacza to, że istotność powinna być celowo określona, a nie odziedziczona od domyślnej oceny bazy danych wektorowych.

Jak wygląda bardziej solidna architektura wyszukiwania

Niezawodny RAG zazwyczaj przechodzi przez kilka etapów wyszukiwania i weryfikacji.

1. Zrozumienie zapytania

Zanim rozpocznie się wyszukiwanie, system określa, o co chodzi. Może to oznaczać wyodrębnienie intencji oraz wszelkich nazwanych entytetów, przedziałów czasowych, typów dokumentów, jurysdykcji, identyfikatorów klientów lub produktów, jednostek biznesowych oraz wymaganego poziomu uprawnień, a następnie decyzję o tym, czy pytanie wymaga wyszukiwania, obliczeń, porównania czy przeszukiwania grafu.

Weźmy przykład pytania „Co zmieniło się w naszej europejskiej polityce przechowywania danych w tym roku?”. Nie powinno ono być traktowane jako zwykłe wyszukiwanie semantyczne. Odnosi się do konkretnej regionu, kategorii dokumentu, okna czasowego oraz porównania wersji. Zrozumienie zapytania przekształca swobodne zdanie w ustrukturyzowany plan wyszukiwania.

2. Filtrowanie metadanych

Metadane zawężają obszar wyszukiwania przed lub w trakcie jego przeprowadzania. Wśród najważniejszych pól znajdują się region, właściciel, jednostka biznesowa, daty wejścia w życie i wygaśnięcia dokumentu, jego status zatwierdzenia i wersja, typ dokumentu, klasyfikacja danych, rodzina produktów, identyfikatory klientów lub dostawców oraz atrybuty używane do kontroli dostępu.

Stosowanie filtrów zapobiega temu, by kandydaci wyraźnie niekwalifikowani konkurowali z tymi kwalifikowanymi. Ponadto jakość metadanych staje się elementem jakości RAG: gdy dokumenty są przetwarzane bez wiarygodnych dat, właścicieli, statusu wersji czy etykiet dostępu, proces wyszukiwania pozostaje wrażliwy, niezależnie od używanego modelu embedowania.

3. Hybrydowe wyszukiwanie

Hybrydowe metody wyszukiwania łączą wyszukiwanie semantyczne z wyszukiwaniem leksykalnym. Wektory zajmują się znaczeniem i parafrazami, natomiast metody leksykalne, takie jak BM25, obsługują dokładną terminologię, identyfikatory oraz rzadkie terminy. System hybrydowy może zrozumieć, że „procedura zakończenia współpracy” jest powiązana z „polityką odejścia pracowników”, a mimo to wymagać dokładnego dopasowania dla „HR-OPS-204”.

Wyniki można połączyć za pomocą fuzji rankingu wzajemnego lub funkcji oceny specyficznej dla danej dziedziny. Dla wielu przedsiębiorstw jest to jedna z najpraktyczniejszych ulepszeń w stosunku do systemów opartych wyłącznie na wektorach.

4. Wyszukiwanie danych strukturalnych

Kawałki dokumentów nie są odpowiednim źródłem informacji na niektóre pytania. Informacje dotyczące liczb, sum, progów, stanów lub porównań często lepiej pasują do zapytań SQL, indeksów wyszukiwania, API, magazynów danych, baz wiedzy, systemów danych głównych lub silników reguł.

Jeśli ktoś zapyta: „Ile otwartych roszczeń przekroczyło kwotę 5 lakh w tym kwartale?”, właściwym krokiem jest zapytanie strukturyzowanego źródła przechowującego dane o roszczeniach. Tekst opisowy, który jedynie omawia roszczenia, nie może podać takiej liczby. Dojrzały projekt kieruje każde zapytanie do odpowiedniego mechanizmu.

5. Grafy wiedzy i wyszukiwanie uwzględniające relacje

Część zapytań dotyczy w istocie relacji pomiędzy różnymi elementami. Graf wiedzy może modelować klientów, dostawców, produkty, umowy, lokalizacje, incydenty oraz przepisy, a także powiązania między nimi.

Załóżmy, że analityk ryzyka chce dowiedzieć się, które aktywne dostawcy łączą się z sankcjonowanymi podmiotami poprzez strukturę właścicielską. Prawdopodobnie żaden pojedynczy akapit nie będzie zawierał wystarczających dowodów. Aby na to odpowiedzieć, trzeba prześledzić linki w dokumentacji dostawców, danych dotyczących struktury własności korporacyjnej, wynikach weryfikacji oraz stanie umów. Wykorzystanie grafów umożliwia zlokalizowanie sieci podmiotów zaangażowanych, a wyszukiwanie wektorowe pozwala następnie znaleźć odpowiednie fragmenty tekstowe dotyczące tych podmiotów oraz powiązania, które zostały odkryte.

Tę kombinację powszechnie nazywa się GraphRAG, chociaż implementacje mogą się różnić. Jej zaleta nie polega na tym, że grafy są bardziej zaawansowane od wektorów, lecz na tym, że grafy zachowują wyraźne relacje, które w przypadku wektorów zostają sprowadzone do statystycznej bliskości.

6. Ponowna klasyfikacja

W pierwszym etapie wyszukiwania należy priorytetowo dbać o wskaźnik odnalezienia – należy zebrać szeroki zbiór potencjalnie istotnych kandydatów. Następnie model rankingowy ocenia je dokładniej w odniesieniu do całego zapytania. Kodery krzyżowe, specjalistyczne modele rankingowe lub narzędzia oparte na LLM mogą określić, czy dany fragment rzeczywiście odpowiada na pytanie.

Do analizy można wykorzystać takie wskaźniki jak stopień bezpośredniości odpowiedzi fragmentu, zgodność z danymi o entytetach, autorytet źródła, aktualność, kompletność, precyzja, sprzeczności oraz reguły biznesowe. Celem jest odróżnienie fragmentów „dotyczących tematu” od tych, które są „przydatne dla tego pytania”.

7. Budowa kontekstu

Przekazywanie pięciu najważniejszych fragmentów do modelu językowego nie stanowi strategii zarządzania kontekstem. Dowody mogą wymagać grupowania według dokumentów, uporządkowania chronologicznego, rozszerzenia o sąsiednie sekcje, odnośników do definicji lub tabel, usuwania duplikatów, łączenia z poprawkami, porównywania różnych wersji, oznaczeń źródła i autorytetu oraz kompresji, która nie pomija wyjątków.

Celem jest zachowanie struktury niezbędnej do rozumowania. W przypadku klauzuli umowy oznacza to uwzględnienie jej definicji, wyjątków oraz historii poprawek. Procedura kliniczna może wymagać informacji o otaczających ją ostrzeżeniach. Wynik finansowy może potrzebować okresu sprawozdawczego oraz zasad rachunkowości.

8. Walidacja dowodów

Zanim zostanie napisana ostateczna odpowiedź, system powinien sprawdzić, czy dostępnych dowodów jest wystarczająco dużo. Czy źródła bezpośrednio potwierdzają odpowiedź i czy są aktualne? Czy autorytatywne źródła są ze sobą sprzeczne? Czy brakuje niezbędnego dokumentu? Czy odpowiedź opiera się na nieudokumentowanej dedukcji? Czy użytkownik może rzeczywiście otworzyć każdy cytowany fragment?

Gdy dowodów jest niewystarczająco, najbezpieczniejszą reakcją może być przyznanie się do tego, poproszenie o wyjaśnienia lub eskalacja sytuacji. Systemy RAG typu enterprise powinny być zaprojektowane tak, by unikać udzielania odpowiedzi, a nie tylko je udzielać.

Zasady biznesowe mają rzeczywisty wpływ

Znaczna część błędów w wyszukiwaniu nigdy nie zostanie rozwiązana dzięki lepszym embeddingom, ponieważ istotność jest określana przez strukturę organizacji. Przykładowe zasady: stosować najnowszą zatwierdzoną politykę, chyba że obowiązuje polityka regionalna; stosować zmiany umowy w kolejności ich wprowadzenia; preferować sprawdzone dane finansowe nad szacunkami kierownictwa; pominąć projekty dokumentów regulacyjnych; identyfikować klienta na podstawie osoby prawnej, a nie nazwy handlowej; oraz zwracać tylko te rekordy, które należą do terytorium, do którego użytkownik ma dostęp.

Zasady te powinny znaleźć się w kodzie odpowiedzialnym za wyszukiwanie, ranking lub koordynację procesów. Oczekiwanie, że model językowy sam wydedukuje je z kontekstu, jest niewiarygodne i nie pozostawia nic do sprawdzenia. W tym przypadku RAG w przedsiębiorstwach staje się zadaniem inżynierii systemów, a nie tylko kwestią wyboru modelu.

Ocena poza dokładnością odpowiedzi

System może podać prawidłową odpowiedź z niewłaściwego powodu, korzystając z słabych dowodów i opierając się na wcześniejszej wiedzy modelu. Może również wydawać się dokładny podczas testów, ale zawieść, gdy zmienią się dokumenty. Dlatego ocena musi sprawdzić każdą warstwę całego procesu.

Pobieranie danych. Sprawdź, czy znaleziono niezbędne dowody: recall@k, precision@k, średni odwrotny rank oraz znormalizowany dyskontowany zysk kumulatywny, a także to, jak często znajdują się dokładne identyfikatory oraz jak często wyniki są aktualne i wiarygodne.

Kontekst. Sprawdź, czy zebrane materiały są przydatne: kompletność dowodów, redundancja, stopień sprzeczności, trafność kontekstowa, zachowanie struktur tabel i relacji między sekcjami oraz spójność wersji.

Generowanie. Sprawdź ostateczną odpowiedź: wierność dowodom, poprawność cytowań, kompletność, częstotliwość pojawiania się nieudokumentowanych twierdzeń, odpowiednie unikanie błędów oraz przestrzeganie zasad i regulaminów.

Wyniki biznesowe. Śledź wartość operacyjną: zaoszczędzone godziny, częstotliwość eskalacji przypadków, ilość pozostałej pracy nad przeglądaniem, stopień powagi błędów, szybkość rozwiązywania problemów, czy użytkownicy ufają narzędziu, ewentualne incydenty związane z przestrzeganiem zasad oraz stopień rozpowszechnienia się tego narzędzia w procesach pracy. Lepsze wyniki w wyszukiwaniu semantycznym niewiele znaczą, jeśli nadal pojawiają się wygasłe umowy lub niedostępne dane.

Błędy, które popełniają zespoły przechodząc na wyszukiwanie wektorowe

Organizacje często dostrzegają ograniczenia modeli RAG opartych wyłącznie na wektorach, a następnie dodają dodatkową złożoność bez jasnego modelu istotności informacji.

Jednym z błędów jest stosowanie wszystkich technik naraz. Graf wiedzy, narzędzie do ponownego rankowania oraz agenty nie naprawią brakujących metadanych ani słabej kontroli dokumentów.

Kolejnym błędem jest uczynienie z modeli językowych uniwersalnych sędziów. Modele sprawdzają się przy interpretacji zapytań i rankowaniu dowodów, jednak reguły, które muszą być dokładne, takie jak kontrole dostępu, daty i identyfikatory entity, zazwyczaj powinny pozostać kodem deterministycznym.

Trzecim błędem jest dostrojenie rozwiązań wyłącznie pod kątem zadań z benchmarków. Prawdziwi użytkownicy zadają niejasne, częściowe zapytania wymagające dużo kontekstu, dlatego dane testowe muszą zawierać rzeczywiste przypadki krawędziowe, przestarzałe dokumenty, sprzeczne źródła oraz ograniczenia uprawnień.

Wreszcie, niektóre zespoły postrzegają proces wydobywania informacji jako zakup infrastruktury. Wybór bazy danych wektorowej to zaledwie jedna z wielu decyzji, ponieważ trafność wyników zależy również od sposobu przetwarzania i strukturyzowania dokumentów, dołączanych metadanych, sposobu rozwiązywania problemów z identyfikacją, a także od sposobu zarządzania rankingiem, koordynacją i nadzorem.

Praktyczny plan działania

Aby poprawić trafność wyników, nie jest konieczne zastępowanie istniejącej platformy RAG – można rozwijać ją krok po kroku.

Zacznij od pytań, które nie przyniosły rezultatów, i sklasyfikuj każdą błąd w procesie wydobywania informacji. Czy brakowało odpowiednich dowodów, zostały one źle sklasyfikowane, błędnie przefiltrowane, podzielone na kilka części, czy też przeważył nad nimi przestarzały źródło?

Następnie określ, co oznacza trafność w danym procesie pracy, decydując, które źródła mają autorytet, które pola metadanych są istotne oraz jakie zasady biznesowe regulują ich ważność.

Następnie dodaj najprostszy mechanizm pasujący do każdego błędu. Dokładne identyfikatory wymagają wyszukiwania leksykalnego. Daty, regiony i typy dokumentów wymagają filtrów metadanych. Słabe oceny zapytania i dokumentu wymagają ponownego rankowania. Fragmenty pozbawione kontekstu wymagają pobierania sąsiednich sekcji. Pytania analityczne pasują do strukturyzowanych baz danych. Odpowiedzi zależne od relacji między entytetami wymagają przeszukiwania grafu. Uprawnienia powinny być sprawdzane w sposób deterministyczny przed pobieraniem danych, a niekompletne dowody powinny uruchamiać zasady powstrzymania się od działania.

Na koniec utwórz zestaw oceny na podstawie rzeczywistych pytań użytkowników i rzeczywistych błędów, oraz testuj pobieranie danych i generowanie odpowiedzi oddzielnie, aby postępy na jednym poziomie nie maskowały problemów na innym.

Prawidłowe dowody zamiast podobnego tekstu

Wyszukiwanie wektorowe pozostaje cenne i doskonale sprawdza się przy znajdowaniu fragmentów o podobnych tematach. Nie potrafi jednak samo zdecydować, który fragment jest aktualny, autorytatywny, dozwolony, kompletny lub odpowiedni dla konkretnej sytuacji biznesowej.

Wymagana jest szersza architektura relewności, łącząca wyszukiwanie semantyczne z wyszukiwaniem dokładnego dopasowania, metadane, reguły biznesowe, ustrukturyzowane źródła, relacje grafowe, ponowną klasyfikację oraz weryfikację dowodów.

Następna fala systemów RAG nie zostanie wygrana poprzez pozyskiwanie coraz większej ilości podobnych tekstów. Zwycięzcy dostarczą właściwe dowody dla właściwego użytkownika, we właściwym kontekście, we właściwym momencie.