Strona główna / Artykuły

Zaawansowane zastosowania RAG w praktyce: architektura, narzędzia oraz ich zalety i wady.

Przewodnik po procesie tworzenia RAG: pobieranie danych, analiza, dzielenie na fragmenty, tworzenie wektorów, przechowywanie wektorów, hybrydowe wyszukiwanie, ponowna sortowanie wyników, ocena oraz zasady bezpieczeństwa, wraz z zaletami i wadami każdego etapu.

Wydawca: REACTAPP.TOP13 min czytania3002 słów

Źródła: **Advanced RAG: Production-Ready Architecture, Technologies, Key Features & Limitations**

RAG łączy krok wyszukiwania z modelem językowym. Dokumenty są wcześniej przetwarzane i indeksowane, a istotne fragmenty pobierane po zadaniu pytania, po czym model tworzy odpowiedź na podstawie tych danych. W praktyce jednak RAG rzadko polega jedynie na bazie danych wektorowych w połączeniu z modelem językowym. Prawdziwe systemy dodają funkcje takie jak strukturalne analizowanie dokumentów, dzielenie ich na fragmenty z uwzględnieniem struktury, intensywne wyszukiwanie według słów kluczowych, ponowne sortowanie wyników, budowanie kontekstu, ocenę jakości oraz możliwość monitorowania działania systemu.

Następne informacje dotyczą narzędzi powszechnie używanych w rzeczywistych systemach i pomijają mniej popularne, eksperymentalne techniki.

Zarys procesu

Prawdziwie zaawansowany pipeline rozpoczyna się od pobierania danych, ich analizy i czyszczenia, a następnie dzielenia na fragmenty, dodawania metadanych, tworzenia embeddingów i indeksowania. Podczas wyszukiwania następuje zrozumienie zapytania, hybrydowe odzyskiwanie informacji, fuzja wyników i ponowne sortowanie, po czym następuje kompresja kontekstu, generowanie treści z odniesieniami oraz wreszcie ocena i monitorowanie. Dokładna struktura tego pipeline zależy od typów dokumentów, skali obciążenia, celowanych czasów reakcji, zasad ochrony prywatności, budżetu oraz wymagań dotyczących jakości.

Pobieranie danych

Pliki lokalne. Python z bibliotekami pathlib, PyPDF, python-docx, openpyxl i pandas umożliwia tanie przetwarzanie plików PDF, dokumentów Word, arkuszy kalkulacyjnych, plików CSV oraz tekstu prostego i łatwo integruje się z zadaniami batch. Problem polega na tym, że każdy format wymaga własnego parsera – skanowane i złożone pliki PDF potrzebują specjalistycznych narzędzi do wydobywania danych, a duże zadania wymagają paralelizmu oraz procesowania stopniowego.

Przechowywanie obiektów. Amazon S3, Google Cloud Storage oraz Azure Blob Storage zapewniają trwałe, skalowalne rozwiązania do przechowywania dużych zbiorów i doskonale współpracują z asynchronicznym pobieraniem danych. Koszty obejmują konfigurację chmury, zarządzanie kontrolą dostępu oraz koszty przechowywania i transferu, które rosną wraz ze skalą.

Zródła internetowe i API. narzędzia takie jak requests lub httpx, BeautifulSoup, Playwright i Firecrawl utrzymują bazę wiedzy aktualną poprzez pobieranie stron, API i dynamicznych stron internetowych. Strony zmieniają swoją strukturę, strony oparte na JavaScript wymagają automatyzacji przeglądarki, a crawlowanie powoduje ograniczenia szybkości, duplikaty stron oraz nierówną jakość treści.

Analiza i wydobywanie danych

Unstructured obsługuje pliki PDF, Word, HTML, PowerPoint, obrazy i wiele innych, a także wyodrębnia elementy takie jak tytuły, akapity i tabele, co czyni go dobrym narzędziem uniwersalnym. Jest wolniejszy od prostych metod wydobywania tekstu, a trudne do przetworzenia dokumenty mogą wymagać specjalnego podejścia.

PyMuPDF szybko wydobywa tekst i metadane z plików PDF opartych na tekście i łatwo integruje się z kodem w Pythonie. Nie jest to pełny system rozumienia dokumentów, więc skanowane pliki wymagają OCR, a złożone układy lub tabele potrzebują dodatkowych działań.

Apache Tika obsługuje bardzo szeroki zakres formatów oraz zaawansowane narzędzia do wydobywania tekstu i metadanych z zmiennych zbiorów. Jest mniej zoptymalizowany pod kątem nowoczesnego rozumienia układu, więc złożone struktury wizualne wymagają dodatkowych narzędzi.

OCR i wydobywanie na podstawie widzenia

Tesseract jest oprogramowaniem open source, działa lokalnie i dobrze radzi sobie z zwykłym tekstem drukowanym. Rękopisy oraz skomplikowane układy tekstowe obniżają dokładność, a nieodpowiednio zeskanowane dokumenty wymagają przetwarzania wstępnego.

PaddleOCR oferuje skuteczny proces do wykrywania i rozpoznawania tekstu w wielu językach, co sprawdza się przy skanowanych dokumentach i strukturalnej ekstrakcji informacji. Złożone dokumenty mogą nadal wymagać dodatkowego przetwarzania układu, a ich wdrożenie może wymagać dodatkowych zależności modelowych.

Modele łączące widzenie z językiem, takie jak modele typu GPT-4, Gemini oraz rodzina Qwen-VL, rozumieją tekst, obrazy, wykresy oraz układ strony, co jest przydatne, gdy sama technologia OCR traci kontekst wizualny – umożliwiają one zatem pracę w trybie multimodalnym RAG. Są one droższe od klasycznych rozwiązań OCR, reagują wolniej i generują wyniki niedeterministyczne, które wymagają weryfikacji.

Dzielenie na fragmenty

Podział na fragmenty decyduje o tym, co stanie się jednostką dostępną do pobrania. Zły podział rozdziela istotne informacje lub łączy ze sobą materiał niepowiązany.

  • Recurencyjne dzielenie znakami (RecursiveCharacterTextSplitter z LangChain) to niezawodna baza, która stara się przestrzegać granic akapitów i zdań i jest łatwa do dostosowania. Działa na podstawie składni, a nie znaczenia, więc jedna stała wielkość nie pasuje do każdego dokumentu.
  • Dzielenie oparte na tokenach określa rozmiar fragmentów według tokenów modelu, co pomaga w radzeniu sobie z ograniczeniami okna kontekstowego. Granice tokenów nie muszą pokrywać się z granicami semantycznymi.
  • Podział semantyczny szuka zmian tematu przy użyciu podobieństwa, dzięki czemu spójne idee pozostają razem lepiej niż przy użyciu stałych rozmiarów. Wymaga większych zasobów obliczeniowych, potrzebuje embeddingów i polega na progu, który trzeba wybrać.
  • Dzielenie na fragmenty rodzic-dziecko polega na pobieraniu małych fragmentów dziecięcych, ale ich rozszerzaniu do większych fragmentów rodzicielskich w celu uzyskania kontekstu, co poprawia dokładność bez utraty otoczenia. Relacje między indeksami a metadanymi stają się bardziej złożone, a większy kontekst zwiększa koszt przetwarzania tokenów.
  • Dzielenie na fragmenty z uwzględnieniem struktury polega na śledzeniu nagłówków, sekcji, tabel i akapitów, co jest korzystne dla dokumentów technicznych i firmowych. Zależy to od niezawodnego analizowania tekstu, a różne typy dokumentów wymagają odmiennych zasad.
  • Metadane

    Typowe pola to identyfikator dokumentu, nazwa pliku, numer strony, sekcja, autor, data i czas, typ dokumentu, użytkownik lub najemca, uprawnienia dostępu, adres URL źródłowy oraz wersja. Dobre metadane umożliwiają filtrowanie przed lub w trakcie wyszukiwania, wspierają cytowanie i kontrolę dostępu oraz zwiększają dokładność. Z drugiej strony słabe metadane bezpośrednio obniżają jakość wyszukiwania, a schematy stają się trudniejsze do utrzymania w przypadku różnorodnych źródeł.

    Embeddingi

    Embeddingi przekształcają tekst w wektory, które oddają jego znaczenie.

    • Embeddingi OpenAI są zarządzane, wysokiej jakości i łatwe do wykorzystania, oferując skuteczne wyszukiwanie o zastosowaniu uniwersalnym. Wadami są koszt API, zależność od dostawcy oraz fakt, że wysyłanie danych może nie być odpowiednie w środowiskach wrażliwych.
  • BGE to silna rodzina narzędzi do wyszukiwania o otwartym kodzie, którą można uruchomić samodzielnie, dostępna w wariantach do gęstego wyszukiwania oraz ponownego rankowania. Samodzielne uruchomienie wymaga infrastruktury, a wybór modelu i jego wymiary wpływają na zużycie pamięci oraz opóźnienia.
  • E5 to popularna rodzina narzędzi o otwartym kodzie, oferująca solidne możliwości ogólnego wyszukiwania oraz warianty oparte na instrukcjach lub prefiksach. Niektóre warianty wymagają starannego formatowania zapytań i dokumentów, a ich samodzielne uruchomienie dodatkowo obciąża pracą.
  • Cohere Embed to zarządzana API o dobrych możliwościach wyszukiwania w wielu językach i w środowiskach korporacyjnych, w zależności od wersji modelu, przy czym jej wdrożenie jest proste. Pociąga za sobą koszty związane z API oraz wymaga zewnętrznej zależności.
  • Jina embeddings to modele skierowane na wyszukiwanie, z których niektóre obsługują długi kontekst oraz kilka języków. Ich możliwości różnią się w zależności od wersji, a modele otwarte wymagają infrastruktury do uruchomienia.
  • Bazy danych wektorowych

    • pgvector dodaje funkcję wyszukiwania wektorowego do PostgreSQL, łącząc dane relacyjne, metadane oraz wektory w jednym miejscu, co jest doskonałe, jeśli aplikacja już korzysta z Postgres. Bardzo duże obciążenia wektorowe mogą wymagać specjalistycznych systemów, a skalowanie staje się trudniejsze przy dużym obrocie danych.
    • Pinecone to zarządzana baza danych wektorowych, która skaluje się bez konieczności pracy nad infrastrukturą i oferuje funkcje filtrowania przydatne w środowisku produkcyjnym. Płacisz za usługę, polegasz na dostawcy i rezygnujesz z części kontroli.
    • Qdrant dostępny jest w wersji open source lub chmurowej, dobrze filtruje metadane, obsługuje wyszukiwanie gęste i hybrydowe oraz nadaje się do samodzielnego hostowania RAG. Samodzielne hostowanie wiąże się z koniecznością zajmowania się operacjami technicznymi, a rozwiązania rozproszone wymagają starannego planowania mocy obliczeniowej.
  • Weaviate oferuje zaawansowane funkcje wyszukiwania, hybrydowe metody wyszukiwania oraz filtrowanie metadanych, dostępne zarówno w chmurze, jak i w wersji samodzielnie hostowanej. Więcej funkcji może oznaczać większą złożoność systemu, a duże obciążenia wymagają dostosowań.
  • Chroma jest przyjazny programistom i wygodny do tworzenia prototypów oraz mniejszych aplikacji, dzięki prostej integracji z Pythonem. Zazwyczaj nie jest pierwszym wyborem przy bardzo dużych implementacjach korporacyjnych, gdzie ważniejsze są skalowalność i zarządzanie operacjami.
  • FAISS to niezwykle popularna biblioteka do szybkiego wyszukiwania podobieństw oraz do eksperymentów lokalnych bez użycia zewnętrznej bazy danych. Jest to biblioteka do wyszukiwania, a nie rozproszona baza danych, więc trwałość danych, filtrowanie, obsługa wielu użytkowników oraz rozproszenie wymagają dodatkowych rozwiązań inżynieryjnych.
  • Wyszukiwanie

    Gęste wyszukiwanie wektorowe łączy bazę danych wektorowych z modelem embeddingu i znajduje treści semantycznie podobne, lepiej radząc sobie z parafrazami niż ze słowami kluczowymi. Może pomijać dokładne identyfikatory, rzadkie terminy, kody i liczby, a jakość zależy w dużej mierze od modelu embeddingu oraz sposobu dzielenia tekstu na fragmenty.

    BM25 to skuteczna metoda leksykalna, doskonała do dokładnych terminów, nazw, identyfikatorów i słów kluczowych o charakterze technicznym; jest prosta w użyciu i łatwa do zrozumienia. Nie potrafi ocenić podobieństwa semantycznego, więc synonimy i parafrazy mogą umknąć uwadze.

    Wyszukiwanie hybrydowe zazwyczaj łączy BM25 z gęstym wyszukiwaniem, łącząc precyzję leksykalną z zasięgiem semantycznym w celu uzyskania bardziej wiarygodnych wyników przy różnych typach zapytań. Wymaga fuzji ocen lub rankingów oraz większej infrastruktury i dostosowań w porównaniu z pojedynczym mechanizmem wyszukiwania.

    Transformacja zapytania

    • Przepisywanie zapytania przekształca rozmowne lub niejasne dane we formę przyjazną do wyszukiwania, co ułatwia zadawanie dalszych pytań. Niewłaściwe przepisywanie może usunąć kluczowe informacje oraz zwiększyć opóźnienie i koszty działania modelu LLM.
    • Wyszukiwanie wielu zapytań polega na tym, że model tworzy kilka alternatywnych zapytań i przeprowadza wyszukiwanie dla każdego z nich, co poprawia dokładność wyników i umożliwia obsługę różnych sformułowań. Prowadzi to do większej liczby prób wyszukiwania, wyższego opóźnienia i kosztów, a czasami do nieistotnych wyników.
    • HyDE (Hypothetical Document Embeddings) generuje wymyśloną odpowiedź i umieszcza ją w formie wektorów do celów wyszukiwania, co może pomóc przy trudnych zapytaniach lub w przypadkach, gdy słownictwo pytania znacznie różni się od słownictwa dokumentów. Wymaga dodatkowej próby działania modelu LLM, a kiepsko opracowany dokument hipotetyczny może zniekształcić wyniki.

    Fuzja

    Fuzja rang recyprocznych łączy rankingi pochodzące od kilku systemów wyszukiwania. Jest prosta, niezawodna i dobrze funkcjonuje zarówno z metodą dense, jak i BM25; nie wymaga, aby wyniki z różnych systemów były porównywalne. Dodaje etap rankingu, ale nadal posiada parametry do dostosowania.

    Fuzja ocen ważonych przypisuje różną wagę sygnałom gęstym, rzadkim lub innym, co jest przydatne, gdy systemy wyszukiwania mają różne mocne strony. Skale ocen muszą być znormalizowane, a wagi zależą od obciążenia systemu.

    Ponowne rankowanie

    W pierwszym etapie wyszukiwania należy priorytetowo dbać o wskaźnik召回率. Następnie ponowne rankowanie zwiększa precyzję na mniejszym zbiorze kandydatów.

    Cross-encoder rerankers takie jak BGE Reranker, Cohere Rerank i Jina Reranker oceniają każdą parę zapytanie-dokument łącznie, zazwyczaj osiągając lepsze wyniki niż prosta podobieństwo embeddingów, i dobrze funkcjonują po hibrydowym wyszukiwaniu. Są droższe od wyszukiwania wektorowego, więc należy je używać tylko na ograniczonej liście kandydatów.

    LLM reranking prosi model o ocenę istotności i potrafi obsługiwać złożone kryteria, ale jest wolny, wymaga dużo zasobów i jest mniej deterministyczny niż dedykowany reranker.

    Maximum Marginal Relevance (MMR) równoważy istotność z różnorodnością, eliminując duplikaty, gdy wyniki top-k to niemal identyczne fragmenty. Dodaje parametr różnorodności, a zbyt duża różnorodność może usunąć istotne dane, które przypadkowo się powtarzają.

    Kompresja kontekstu

    Kompresja ekstraktywna zachowuje tylko istotne zdania lub fragmenty, co pozwala zaoszczędzić tokeny i zachować oryginalne sformułowania, ale może usunąć kontekst niezbędny do zrozumienia tekstu. Kompresja oparta na LLM streszczает pozyskany materiał i może znacznie skrócić kontekst w przypadku dużych dokumentów, z dodatkowymi kosztami i opóźnieniami, przy pewnym ryzyku utraty informacji lub powstawania halucynacji podczas kompresji.

    Generowanie

    Popularnymi rozwiązaniami w praktyce są modele OpenAI, Anthropic Claude, Google Gemini, Meta Llama i Qwen. Charakteryzują się silnymi umiejętnościami rozumowania, a zapytania można kierować według kosztów, opóźnień i trudności zadania. Modele API wiążą się z kosztami i zależnościami od dostawcy, modele otwarte wymagają infrastruktury, a większe modele zwiększają opóźnienia i koszty obliczeń.

    Ramki programowe

    LangChain posiada ogromny ekosystem ładowarek, narzędzi do wyszukiwania danych, integracji z magazynami wektorowymi oraz interfejsów modeli, które ułatwiają szybkie tworzenie pipeline’ów. Abstrakcje mogą się komplikować, a systemy produkcyjne często lepiej funkcjonują przy prostym i jasnym schemacie żądań.

    LlamaIndex koncentruje się na pobieraniu danych, indeksowaniu i ich wyszukiwaniu, oferując przydatne abstrakcje dla podejść typu RAG skupionych na dokumentach. Dodaje on jednak złożoność do frameworku, dlatego niektóre zaawansowane systemy ostatecznie przechodzą na SDK o niższym poziomie abstrakcji.

    LangGraph nadaje się do złożonych, rozgałęzionych procesów pracy z elementami agentowymi, obejmujących iteracyjne wyszukiwanie danych i wykonywanie narzędzi. Jest to rozwiązanie bardziej złożone, niż wymagają proste pipeline’y, i wymaga starannego zarządzania stanem oraz obsługi błędów.

    Zaawansowane wzorce

    • Corrective RAG ocenia pozyskany kontekst i może wywołać dodatkowe pobieranie danych, wykrywając słabe wyniki i umożliwiając wyszukiwanie awaryjne, ale przy tym powoduje większą opóźnioność i złożoność.
    • Self-RAG pozwala modelowi decydować, kiedy pobierać dane, oraz oceniać to, co zostało uzyskane. Adaptuje się, aby unikać niepotrzebnego pobierania informacji, jednak logika sterująca jest bardziej złożona i wymaga dokładnej oceny oraz wsparcia modelu.
    • Agentic RAG wykorzystuje agenta do planowania wyszukiwań, wywoływania narzędzi, iteracyjnego pobierania danych i ich weryfikacji, co umożliwia radzenie sobie z złożonymi, wieloetapowymi zadaniami opartymi na kilku źródłach. Może to wiązać się z wyższą opóźnionością i kosztami, większą liczbą problemów oraz trudniejszym debugowaniem.
  • Graph RAG łączy graf wiedzy z mechanizmem wyszukiwania, co pomaga w identyfikacji relacji pomiędzy entytetami oraz przy rozwiązywaniu zadań wieloetapowych, których nie potrafią załatwić zwykłe wektory. Budowa takiego grafu jest kosztowna, ekstrakcja entytetów powoduje błędy, a wymagana jest dodatkowa infrastruktura.
  • Multimodal RAG przetwarza tekst, obrazy, tabele i wykresy, co sprawdza się przy tworzeniu raportów, skanów i diagramów; wymaga jednak intensywniejszego przetwarzania i indeksowania oraz generuje wyższe koszty związane z modelami obrazowymi.
  • Dane strukturalne

    Text-to-SQL umożliwia modelowi przekształcanie zdań w języku naturalnym w zapytania do baz danych strukturalnych, co jest doskonałe do analizy świeżych danych. Generowane zapytania SQL mogą być błędne lub niebezpieczne, dlatego konieczne jest pobieranie schematu bazy, jego weryfikacja oraz kontrola dostępu.

    Hibrydowy tekst i SQL RAG wykorzystuje wyszukiwanie wektorowe lub na podstawie słów kluczowych do nieustrukturyzowanych informacji oraz SQL do danych ustrukturyzowanych, obejmując w jednym rozwiązaniu pliki PDF, dokumenty, pliki CSV oraz bazy danych. Wymaga przekierowywania pomiędzy różnymi trybami działania, co utrudnia testowanie i zapewnianie bezpieczeństwa.

    Ocena

    System produkcyjny wymaga oceny zarówno na poziomie wyszukiwania, jak i generowania treści.

    Metryki wyszukiwania (Recall@K, Precision@K, MRR, NDCG oraz wskaźnik trafień) określają, czy system znalazł odpowiednie dowody. Metryki generowania treści (wierność, trafność odpowiedzi, poprawność odpowiedzi, relevancja kontekstu, precyzja kontekstu oraz recall kontekstu) sprawdzają, czy model prawidłowo wykorzystał te dowody.

    Ragas został stworzony do oceny RAG, obejmuje oba poziomy i jest przydatny do testów regresji. Wiele jego metryk opiera się na modelach LLM lub mechanizmach oceny embeddingów, więc wyniki nie zastępują w pełni ludzkiej oceny, a modele służące do oceny mogą mieć uprzedzenia. Ludzka ocena jest najlepsza do sprawdzania jakości w specyficznych dziedzinach i pozwala wykryć to, co umyknie automatycznym metrykom, ale jest kosztowna, powolna i wymaga spójnych wytycznych.

    Obserwowalność

    LangSmith śledzi łańcuchy operacji, wywołania pobierania danych, prompty oraz wyniki i pomaga w debugowaniu pipeline’ów oraz porównywaniu eksperymentów. Jest to platforma zarządzana, która uwzględnia kwestie kosztów i prywatności. Langfuse oferuje funkcje śledzenia, zarządzania promptami oraz metryk, dostępne w wersji open-source do samodzielnego hostowania lub w chmurze, choć samodzielne hostowanie leży po twojej stronie i wymaga odpowiednich narzędzi. OpenTelemetry to otwarty standard dla śladów, metryk i logów, który umożliwia integrację RAG z istniejącą infrastrukturą, ale wymaga większych wysiłków inżynieryjnych niż platformy gotowe do użycia.

    Kasowanie z pamięci i wydajność

    Kasza semantyczna ponownie wykorzystuje odpowiedzi na podobne zapytania, redukując liczne wywołania modeli LLM, opóźnienia i koszty. Jednak podobne pytania mogą wymagać różnych odpowiedzi po zmianie danych, a unieważnienie tych informacji jest trudne. Kasza embeddingów unika ponownego obliczania wektorów dla powtarzającego się tekstu – to proste rozwiązanie, które musi zostać unieważnione za każdym razem, gdy zmienia się model embeddingów. Asynchroniczne i równoległe pobieranie umożliwia uruchamianie niezależnych mechanizmów pobierania jednocześnie, co skraca czas reakcji od początku do końca, chociaż obsługa błędów staje się bardziej złożona, a serwery muszą radzić sobie z jednoczesnym obciążeniem.

    Bезpieczeństwo

    • Iniekcja promptów. Pobrane dokumenty mogą zawierać instrukcje mające na celu przejęcie kontroli nad modelem.
    • Pobieranie z kontrolą dostępu. Użytkownicy powinni otrzymywać tylko te dokumenty, do których mają uprawnienia.
  • Obsługa danych osobowych. Dane osobowe muszą zostać zlokalizowane i zaszyfrowane lub w inny sposób zabezpieczone, zanim trafią do indeksu.
  • Izolacja użytkowników. W przypadku wielu użytkowników zapytania wymagają filtrów metadanych uwzględniających ich profil, a sama baza danych musi być podzielona.
  • Zatruwanie danych. Dokumenty z niepewnych źródeł mogą być dodawane celowo w celu wprowadzenia w błąd.
  • Żaden pojedynczy rozwiązanie nie gwarantuje bezpieczeństwa. Wymagane są środki kontroli na wszystkich etapach: pobierania, przechowywania, wyszukiwania, autoryzacji, wykonywania narzędzi oraz generowania danych.

    Rozwój

    Zwykłymi elementami składowymi są FastAPI do warstwy API, Docker do pakowania, Kubernetes do orkiestracji na dużą skalę, Redis do buforowania, PostgreSQL do przechowywania metadanych relacyjnych, S3, GCS lub Azure Blob do przechowywania obiektów, Prometheus do zbierania metryk, Grafana do tworzenia paneli kontrolnych, OpenTelemetry do śledzenia i MLflow do rejestrowania eksperymentów. Celem jest system RAG, który jest powtarzalny, obserwowalny, skalowalny i łatwy w utrzymaniu, a nie taki, który wydaje się dokładny jedynie w notatniku.

    Praktyczna lista narzędzi

    Mocny, uniwersalny projekt może pozostać dość prosty. Dokumenty przechodzą przez Unstructured, PyMuPDF lub PaddleOCR, następnie przez proces dzielenia na fragmenty z uwzględnieniem struktury lub w sposób rekurencyjny, potem przez embeddingi od OpenAI, BGE, E5 lub Cohere, a dalej przez pgvector, Qdrant lub Pinecone. Proces wyszukiwania obejmuje BM25 w połączeniu z intensywnym wyszukiwaniem, połączone z RRF, ponowne uporządkowanie za pomocą cross-encodera, kompresję oraz przekazanie danych do LLM wraz z cytatami uzupełniającymi informacje. Jakość oceniają Ragas oraz ludzka weryfikacja, podczas gdy LangSmith, Langfuse lub OpenTelemetry monitorują czas wykonywania.

    Nie każdy system potrzebuje wszystkich komponentów. Mała wewnętrzna baza wiedzy może funkcjonować przy użyciu PostgreSQL, pgvector, embeddingów oraz LLM. Hybrydowe metody wyszukiwania, ponowne sortowanie, pętle agentowe, wyszukiwanie w grafach oraz przetwarzanie multimodalne należy dodawać dopiero wtedy, gdy ocena pokaże, że prostszy projekt jest niewystarczający.

    Wybór narzędzia do zadań

    • Prosty tekst w PDF: PyMuPDF. Mieszane typy dokumentów: nieustrukturyzowane. Skany: PaddleOCR. Strony o złożonej strukturze wizualnej: model wzrokowo-językowy.
    • Bazowe dzielenie na fragmenty: rekurencyjny podziałnik. Granice semantyczne: dzielenie na fragmenty semantyczne. Kontekst rodzicowski i potomny: wyszukiwanie w kontekście rodzic-potomek.
    • Zarządzane embeddingi: OpenAI lub Cohere. Otwarte embeddingi: BGE lub E5.
    • Już dostępne w PostgreSQL: pgvector. Zarządzany magazyn wektorów: Pinecone. Samodzielnie hostowany: Qdrant. Prototypy: Chroma lub FAISS.
    • Wyszukiwanie oparte na znaczeniu: gęste wektory. Dokładne słowa kluczowe: BM25. Niezawodna obsługa danych: hybrydowy model. Łączenie rankingów: RRF. Wyższa precyzja: ponowny ranker z użyciem cross-encodera. Mniej duplikatów: MMR.
    • Złożone pytania wieloetapowe: agentic RAG. Związki między elementami: Graph RAG. Tabele i bazy danych: konwersja tekstu na SQL.
  • Ocena: Ragas. Śledzenie: LangSmith lub Langfuse. Standardowa telemetria: OpenTelemetry. API o dużej skali: FastAPI z Dockerem lub Kubernetes.
  • Zacznij od małego

    Największym błędem architektonicznym jest traktowanie LLM jako całego systemu. Jakość powstaje od pozyskiwania danych, przez kontekst, aż po generację, a następnie poprzez ocenę i możliwość obserwacji. Większy model nie może w sposób pewny zrekompensować braku dowodów.

    Korzystny cykl ulepszeń to: ustalenie punktu wyjścia, ocena, zlokalizowanie problematycznego etapu, zmiana jednego komponentu, ponowna ocena, wdrożenie i monitorowanie. W przypadku większości systemów produkcyjnych należy zacząć od solidnego parsowania i dzielenia na fragmenty uwzględniające strukturę, dobrych embeddingów, hybrydowego pozyskiwania danych oraz narzędzia do ponownego sortowania, a następnie dodać generację opartą na faktach i ocenę. Narzędzia typu agentic retrieval, Graph RAG, pipeline’y multimodalne, pętle korygujące lub fine-tuning należy wprowadzać tylko wtedy, gdy mierzalne wymagania uzasadniają ich koszt i złożoność.

    Dobra inżynieria RAG polega mniej na gromadzeniu wszelkich technologii, a bardziej na wyborze najprostszej architektury, która spełnia Twoje wymagania dotyczące jakości, opóźnienia, kosztów, bezpieczeństwa i łatwości konserwacji.