RAGFlow, wyszukiwanie po trudnych dokumentach

RAGFlow, czyli problem, który zaczyna się przed wyszukiwaniem

Większość narzędzi do wyszukiwania po własnych dokumentach zakłada, że dokument to tekst. W praktyce dokument to plik PDF z dwiema kolumnami, tabelą rozłożoną na dwie strony, nagłówkiem powtarzającym się w stopce i wykresem, którego opis leży obok, a nie pod nim.

Zwykłe wydobycie tekstu z takiego pliku daje ciąg znaków, w którym kolumny się przeplatają, tabela zamienia się w zbitkę liczb, a numer strony pojawia się w środku zdania. Wyszukiwanie po takim materiale zawodzi niezależnie od tego, jak dobry jest model osadzeń.

RAGFlow zaczyna właśnie od tego problemu. Analiza dokumentu rozpoznaje układ, zanim cokolwiek zostanie pocięte na fragmenty.

Analiza układu dokumentu

Warstwa odpowiedzialna za rozumienie dokumentów robi trzy rzeczy, których zwykłe wydobycie tekstu nie robi.

Rozpoznawanie układu odróżnia nagłówki od treści, przypisy od akapitów i podpisy od opisów rysunków. Dzięki temu kolumny zostają rozdzielone, a powtarzające się stopki i numery stron nie trafiają do fragmentów.

Rozpoznawanie struktury tabel wykrywa granice tabeli, nagłówki i przynależność komórek. To znaczy, że tabela trafia do indeksu jako tabela, z zachowaniem powiązania wartości z nagłówkiem kolumny, a nie jako ciąg liczb bez kontekstu.

Rozpoznawanie tekstu na obrazie obsługuje skany i pliki, w których tekst jest obrazem. Bez tego kroku dokumenty zeskanowane są dla wyszukiwania niewidoczne, a w wielu organizacjach stanowią one znaczną część archiwum.

Efekt jest widoczny przy pytaniach o wartości z tabel. Pytanie o limit dla konkretnego planu z tabeli porównawczej ma szansę na poprawną odpowiedź tylko wtedy, gdy tabela została odczytana jako struktura, a nie jako tekst.

Ta warstwa jest częścią aplikacji i nie wyjmiesz jej do własnego potoku. Gdy potrzebujesz samej zamiany plików na elementy opisane typem, tę rolę pełni Unstructured, które przyjmuje kilkadziesiąt formatów i zwraca listę elementów do dalszego cięcia. Wybór między jednym a drugim sprowadza się do tego, czy chcesz gotową aplikację, czy bibliotekę wpiętą we własny kod.

Szablony cięcia

Drugim wyróżnikiem jest to, że sposób dzielenia dokumentu na fragmenty zależy od jego rodzaju, a nie jest jednakowy dla wszystkiego.

Dokumentacja techniczna dzieli się po nagłówkach, bo sekcja jest naturalną jednostką odpowiedzi. Umowa dzieli się po paragrafach, bo tak jest zbudowana. Tabela zostaje w całości albo dzieli się po wierszach z powtórzonym nagłówkiem. Prezentacja dzieli się po slajdach. Wznowienie zawodowe dzieli się po sekcjach.

To podejście rozwiązuje problem, który przy jednakowym cięciu co pięćset znaków jest nie do obejścia. Fragment zaczynający się w połowie zdania i kończący w połowie tabeli nie odpowie na żadne pytanie, a takich fragmentów przy naiwnym cięciu powstaje wiele.

Praktyczna rada: przejrzyj wygenerowane fragmenty po pierwszym indeksowaniu, zanim zbudujesz cokolwiek dalej. Piętnaście minut przeglądania pokazuje zwykle, że wybrany szablon nie pasuje do części dokumentów, a poprawienie tego zmienia jakość odpowiedzi bardziej niż jakiekolwiek strojenie promptu.

Cytowania ze wskazaniem miejsca

Trzecim wyróżnikiem jest to, że odpowiedź wskazuje nie tylko dokument, ale konkretne miejsce w nim.

Ponieważ analiza zapamiętuje położenie fragmentu na stronie, interfejs potrafi pokazać oryginalny dokument z zaznaczonym miejscem, z którego pochodzi odpowiedź. Użytkownik widzi wtedy kontekst, a nie sam wycinek tekstu.

To ma znaczenie większe, niż wygląda, przy dokumentach, w których kontekst decyduje o znaczeniu. Wartość z tabeli bez widocznego nagłówka kolumny i bez przypisu pod tabelą bywa myląca, a wskazanie miejsca pozwala to sprawdzić w sekundę.

Druga korzyść dotyczy zaufania. Odpowiedź, którą da się zweryfikować jednym kliknięciem, jest traktowana inaczej niż odpowiedź bez źródła, zwłaszcza w organizacjach, gdzie ktoś odpowiada za decyzję podjętą na jej podstawie.

Wdrożenie u siebie

Projekt jest otwarty na licencji permisywnej i uruchamiany we własnej infrastrukturze, co przy dokumentach wewnętrznych bywa warunkiem, a nie preferencją.

git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker
docker compose up -d

Zestaw obejmuje serwer, bazę do przechowywania dokumentów, magazyn wektorów i interfejs. To znaczy, że uruchomienie jest proste, a wymagania sprzętowe wyraźnie wyższe niż przy bibliotece dodawanej do własnej aplikacji.

Modele można podłączyć zewnętrzne albo uruchomić lokalnie. Wariant w pełni lokalny, z modelem uruchomionym przez Ollamę albo serwer wnioskowania pokroju vLLM, pozwala pracować w sieci odciętej od internetu, co w części instytucji jest wymogiem formalnym.

Warto policzyć zasoby przed wdrożeniem. Analiza dokumentów z rozpoznawaniem tekstu na obrazie i struktury tabel jest kosztowna obliczeniowo, więc indeksowanie dużego archiwum wymaga czasu i mocy, a nie tylko miejsca na dysku.

Wyszukiwanie i zmiana kolejności

Po stronie odpowiadania rozwiązanie łączy dwa mechanizmy, których połączenie daje więcej niż każdy z osobna.

Wyszukiwanie hybrydowe zestawia wyniki wyszukiwania znaczeniowego z wyszukiwaniem po słowach kluczowych. To ważne przy dokumentach zawierających numery umów, oznaczenia produktów i kody, których wektor nie odda, bo semantycznie nic nie znaczą.

Zmiana kolejności wyników przez osobny model ocenia parę pytanie i fragment razem, więc rozstrzyga trafniej niż samo podobieństwo wektorów. Model porządkujący można podłączyć zewnętrzny albo uruchomić lokalnie, co przy pracy w sieci odciętej ma znaczenie.

Warto zmierzyć wpływ każdego z tych mechanizmów osobno, zanim uznasz sprawę za zamkniętą. Przy dokumentacji pełnej nazw własnych składnik słowny daje najwięcej, przy tekście ciągłym niewiele, a zmiana kolejności działa odwrotnie.

Trzecim parametrem wartym uwagi jest liczba fragmentów trafiających do odpowiedzi. Dwadzieścia to zwykle za dużo, bo model gubi się w nadmiarze i odpowiedź traci na precyzji. Pięć trafnych fragmentów daje lepszy wynik niż dwadzieścia przeciętnych, a przy okazji kosztuje mniej.

Poza wyszukiwaniem

Nowsze wersje dokładają rzeczy wykraczające poza samo odpowiadanie na pytania.

Przepływy agentowe pozwalają zbudować proces obejmujący wyszukiwanie, wywołanie narzędzia i decyzję, zamiast pojedynczego zapytania. To przydatne przy zadaniach, w których odpowiedź wymaga zestawienia informacji z dokumentów i z systemu zewnętrznego.

Wyszukiwanie po grafie wiedzy, opisane szerzej w tekście o GraphRAG, obsługuje pytania o całość zbioru, na które samo wyszukiwanie po fragmentach nie odpowie.

Złącza do źródeł danych pozwalają pobierać dokumenty przyrostowo z systemów, w których już są, zamiast wgrywać je ręcznie. To decyduje o tym, czy wdrożenie żyje po miesiącu, bo archiwum aktualizowane ręcznie przestaje być aktualizowane.

Integracje z komunikatorami pozwalają wystawić wyszukiwarkę tam, gdzie ludzie zadają pytania, zamiast wymagać wejścia na osobną stronę. To drobiazg, który zauważalnie zmienia liczbę faktycznych użyć.

Uprawnienia i dostęp do dokumentów

Wyszukiwarka po dokumentach firmowych staje przed pytaniem, na które trzeba odpowiedzieć przed wdrożeniem: kto może zobaczyć co.

Model oparty o bazy wiedzy pozwala rozdzielić dokumenty na zbiory i przypisać dostęp do nich. To wystarcza, gdy podział jest gruby: dokumentacja publiczna, wewnętrzna, kadrowa. Przy podziale na poziomie pojedynczych dokumentów robi się trudniej.

Trzeba tu powiedzieć rzecz nieprzyjemną. Fragment, który trafił do odpowiedzi, trafił też do promptu, więc każdy mechanizm ograniczający dostęp musi działać przed wyszukiwaniem, a nie po nim. Filtrowanie odpowiedzi po fakcie nie jest zabezpieczeniem, bo treść już opuściła bazę.

Praktyczna konsekwencja: jeśli Twój model uprawnień jest złożony, warto sprawdzić, czy narzędzie potrafi go odwzorować, zanim wgrasz dokumenty. Przebudowa podziału na bazy wiedzy po zaindeksowaniu archiwum oznacza indeksowanie od nowa.

Drugą rzeczą jest zapis dostępu. Przy dokumentach wrażliwych zwykle wymaga się wiedzy o tym, kto o co pytał i co dostał w odpowiedzi. To warto sprawdzić na etapie wyboru narzędzia, bo dopisanie tego samodzielnie oznacza sięganie do wnętrza aplikacji, której nie pisałeś.

Aktualizacja archiwum

Dokumenty się zmieniają, a wyszukiwarka odpowiadająca treścią sprzed roku jest gorsza niż jej brak, bo brzmi wiarygodnie.

Złącza do źródeł pobierają dokumenty przyrostowo, więc zmieniony plik trafia do indeksu bez ręcznej pracy. To decyduje o tym, czy wdrożenie żyje, bo archiwum wymagające ręcznego wgrywania przestaje być aktualizowane po kilku tygodniach.

Osobną sprawą jest usuwanie. Dokument wycofany ze źródła musi zniknąć również z indeksu, inaczej odpowiedź będzie oparta na treści, której już nie ma. To brzmi oczywiście i bywa pomijane, bo dodawanie jest widoczne, a usuwanie nie.

Trzecia rzecz to wersje. Przy dokumentach zmienianych regularnie warto zachować informację o dacie w metadanych i pokazywać ją przy odpowiedzi. Użytkownik widzący, że informacja pochodzi z dokumentu sprzed dwóch lat, oceni ją inaczej niż taką bez daty.

Warto ustawić cykliczne sprawdzenie spójności: ile dokumentów jest w źródle, ile w indeksie i czy te liczby się zgadzają. Rozjazd wykryty automatycznie jest problemem technicznym, a wykryty przez użytkownika jest problemem zaufania.

RAGFlow kontra alternatywy

Kluczowa różnica sprowadza się do tego, czy Twoje dokumenty są trudne. Zbiór plików tekstowych albo stron dokumentacji nie wymaga zaawansowanej analizy układu, więc lżejsze narzędzia dają ten sam wynik przy mniejszym nakładzie.

Archiwum plików PDF ze skanami, tabelami i wielokolumnowym układem to zupełnie inna sytuacja. Tam analiza dokumentu jest najtrudniejszą częścią całego zadania, a gotowe rozwiązanie oszczędza tygodni pracy, których nikt nie planował.

Prosty sposób na rozstrzygnięcie tej kwestii: weź dziesięć najtrudniejszych dokumentów ze swojego zbioru i przepuść je przez zwykłe wydobycie tekstu. Jeśli wynik da się przeczytać, lżejsze narzędzia wystarczą. Jeśli kolumny się przeplatają, a tabele zamieniają w ciąg liczb, masz odpowiedź.

Typowe błędy

Pierwszy to pominięcie przeglądu wygenerowanych fragmentów. Szablon cięcia niedopasowany do dokumentów daje fragmenty bezużyteczne, a widać to dopiero po ich obejrzeniu.

Drugi to zakładanie, że rozpoznawanie tekstu na obrazie działa idealnie. Skany słabej jakości dają błędy, więc przy dokumentach, gdzie liczy się dokładność wartości, warto sprawdzić próbkę ręcznie.

Trzeci to wdrożenie bez policzenia zasobów. Analiza z rozpoznawaniem obrazu i tabel obciąża procesor znacznie bardziej niż zwykłe wydobycie tekstu, więc indeksowanie dużego archiwum potrafi trwać dobę.

Czwarty to ręczne wgrywanie dokumentów przy zbiorze, który się zmienia. Bez złącza do źródła archiwum przestaje być aktualne w ciągu kwartału i nikt tego nie zauważa, dopóki ktoś nie dostanie starej odpowiedzi.

Piąty to brak pomiaru jakości. Miary opisane w tekście o Ragas stosują się tu tak samo, a bez nich każda zmiana konfiguracji jest zakładem.

Szósty to traktowanie tego rozwiązania jako biblioteki. To kompletna aplikacja z własnym interfejsem i magazynem, więc wpięcie jej do istniejącego produktu wymaga korzystania z jej interfejsu programistycznego, a nie importowania jej jako zależności.

FAQ

Czym RAGFlow różni się od innych narzędzi do wyszukiwania po dokumentach?

Skupieniem na analizie dokumentu przed indeksowaniem. Rozpoznaje układ strony, strukturę tabel i tekst na obrazach, więc radzi sobie z plikami PDF o złożonym układzie i ze skanami, na których zwykłe wydobycie tekstu zawodzi.

Czy jest darmowy?

Tak, projekt jest otwarty na licencji permisywnej i uruchamiasz go we własnej infrastrukturze. Płacisz za sprzęt oraz za wywołania modelu, o ile korzystasz z modelu zewnętrznego, a nie uruchomionego lokalnie.

Czy da się pracować bez dostępu do internetu?

Tak, przy modelach uruchomionych lokalnie całość działa w sieci odciętej od świata. To jeden z głównych powodów, dla których to rozwiązanie pojawia się w instytucjach z wymogami dotyczącymi przetwarzania danych.

Jakie są wymagania sprzętowe?

Wyraźnie wyższe niż przy bibliotece dodawanej do aplikacji, bo uruchamiasz kilka usług naraz, a analiza dokumentów z rozpoznawaniem obrazu obciąża procesor. Przy modelach uruchomionych lokalnie dochodzi karta graficzna, więc warto policzyć to przed decyzją.

Kiedy lepiej wybrać coś innego?

Gdy dokumenty są proste, na przykład strony dokumentacji albo pliki tekstowe, bo wtedy zaawansowana analiza układu nic nie wnosi. Gdy budujesz aplikację z własnym interfejsem, biblioteka pokroju Haystacka daje więcej kontroli przy mniejszym narzucie.

Dokumentacja i kod stoją w repozytorium projektu, a opis warstwy analizującej dokumenty znajdziesz w osobnym rozdziale.