# Hybrydowy RAG w systemach korporacyjnych: wyszukiwanie w dokumentach bez chmury i wycieków
Duże firmy w regulowanych branżach borykają się z chorobą: wyszukiwanie w wewnętrznych dokumentach zajmuje godziny. Kierownik firmy logistycznej na przykład marnuje czas na przeszukiwanie poczty, SharePoint i archiwów, aby sprawdzić historię roszczeń wobec dostawcy. Przyczyna — brak inteligentnego wyszukiwania, które rozumie sens zapytania, a nie tylko słowa kluczowe. Hybrydowy RAG rozwiązuje ten problem, trzymając dane wewnątrz obwodu firmy.
Dlaczego klasyczne wyszukiwanie zawodzi w regulowanych branżach
Korporacyjne archiwa to PDF-y, skany, tabele, korespondencja w dwóch językach. Standardowe systemy EDR i wyszukiwarki nie radzą sobie z heterogenicznymi danymi. Zapytanie „czy były spory dotyczące kodu 8471300000?” wymaga jednocześnie zrozumienia semantycznego i dokładnego dopasowania liczby. Zwykły RAG oparty na wyszukiwaniu semantycznym pada, gdy dokumenty zawierają tabele, ręczne notatki lub treści wielojęzyczne. W bankach, celnych i prawie dane nie mogą opuszczać obwodu — rozwiązania chmurowe są wykluczone wymogami architektonicznymi.
Hybrydowy RAG łączy dwa podejścia:
- Wyszukiwanie semantyczne (dense vectors) do rozumienia sensu
- Dokładne wyszukiwanie (sparse vectors) dla kodów, artykułów, liczb
To nie zwykła kombinacja, lecz matematycznie uzasadnione scalanie wyników za pomocą Reciprocal Rank Fusion (RRF). Algorytm działa bez ręcznego dostrajania wag i dodatkowego uczenia, zintegrowany z bazami wektorowymi takimi jak Qdrant.
Architektura self-hosted hybrydowego RAG: od dokumentu do odpowiedzi
Proces obsługi zapytania obejmuje sześć etapów, z których każdy jest kluczowy dla bezpieczeństwa i precyzji:
- Wstępne przetwarzanie dokumentów — biblioteka Docling normalizuje skany do 300 DPI, wydziela tabele i strukturę. Jest to niezbędne dla poprawnego działania multimodalnego modelu Qwen2.5-VL, który czyta ręczne notatki i skomplikowane tabele.
- Generowanie podwójnych embeddingów — model BAAI/bge-m3 tworzy dwa wektory na chunk: dense (semantyka) i sparse (dokładne dopasowania). Użycie jednego modelu do indeksowania i zapytań gwarantuje zgodność przestrzeni.
- Hybrydowe wyszukiwanie w Qdrant — jednoczesne zapytanie po wektorach dense i sparse z automatycznym scalaniem przez RRF.
- Wstępne rangowanie — FastEmbed skraca listę do 10 kandydatów w 30–50 ms.
- Ostateczne rerank — cross-encoder bge-reranker-v2-m3 ocenia relewantność fragmentu do konkretnego zapytania. Wersja self-hosted dodaje opóźnienie 150–400 ms, ale trzyma dane wewnątrz obwodu.
- Generowanie odpowiedzi — skwantowany model Qwen2.5-72B-Instruct (AWQ INT4) tworzy odpowiedź na podstawie przefiltrowanego kontekstu.
Kluczowa cecha — wszystkie etapy odbywają się lokalnie. Nawet rerank, który w rozwiązaniach chmurowych (np. Voyage AI) przyspiesza proces, jest tu zaimplementowany przez komponenty self-hosted, by spełnić wymogi data sovereignty.
Narzędzia do produkcji: dlaczego LangGraph i Haystack są niezastąpione
LangChain nadaje się do prototypów, ale w regulowanych środowiskach pojawiają się dwa problemy. Po pierwsze, brak natywnego zarządzania stanem: obsługa scenariuszy typu „jeśli rerank-score poniżej progu — przeformułuj zapytanie” wymaga kruczków. LangGraph rozwiązuje to przez jawne węzły grafu, co jest kluczowe do debugowania w produkcji.
Po drugie, problem observability. Bez śledzenia degradacja jakości odpowiedzi (z powodu aktualizacji dokumentów lub zmiany wzorców zapytań) pozostaje niezauważona do czasu skarg użytkowników. Langfuse (self-hosted) rejestruje:
- Znalezione fragmenty
- Rerank-score
- Opóźnienia po etapach
Ważne, że Langfuse też działa wewnątrz obwodu — w przeciwnym razie korporacyjne dane trafią do obcego SaaS.
Haystack odpowiada za testowanie pre-production. Przy zmianie pipeline'u (np. strategii chunkowania) system pozwala uruchomić ocenę na zbiorze testowym i uzyskać metryki:
- Precyzję wyszukiwania (jak często właściwy dokument jest w top-5)
- Zgodność odpowiedzi ze źródłem
To daje pewność, że zmiany poprawiają system, a nie pogarszają. LlamaIndex, choć elastyczny do prototypowania, przegrywa pod względem głębokości wbudowanych narzędzi oceny.
Optymalizacja pod infrastrukturę: od RTX 4090 do A100
Wybór modelu zależy od budżetu i wymagań jakościowych:
- Qwen2.5-72B-Instruct w AWQ INT4 — wariant flagowy. Wymaga dwóch A100 80GB, zapewnia maksymalną jakość, zwłaszcza z danymi tabelarycznymi. Nadaje się dla dużych kancelarii prawnych lub banków.
- Qwen2.5-32B-Instruct — optymalne rozwiązanie. Uruchamia się na jednej L40S 48GB (3 razy tańszej od A100), zachowując 90% jakości wersji 72B. Polecane na start.
- Qwen2.5-14B-Instruct — wariant dla ograniczonych zasobów. Działa na RTX 4090, ale słabnie na skomplikowanych wieloetapowych zapytaniach.
Praktyczna rada: zacznij od 32B na L40S, testuj na rzeczywistych danych, skaluj tylko w razie potrzeby. Kwantryzacja AWQ INT4 redukuje zużycie pamięci o połowę bez krytycznej utraty jakości.
Co jest ważne
- Hybrydowy RAG jest niezbędny dla heterogenicznych archiwów: łączy wyszukiwanie semantyczne i dokładne dopasowania przez RRF.
- Architektura self-hosted to warunek konieczny w regulowanych branżach. Dane nie opuszczają obwodu na żadnym etapie.
- LangGraph i Haystack są kluczowe dla produkcji: pierwszy zarządza logiką zapytania w czasie rzeczywistym, drugi zapewnia obiektywną ocenę jakości.
- Koszty infrastruktury można zoptymalizować: Qwen2.5-32B na L40S daje 90% jakości flagowca przy trzykrotnej oszczędności.
System odpowiada w sekundy, odwołując się do konkretnych dokumentów i stron, i uczciwie przyznaje brak danych zamiast halucynacji. To nie ulepszenie wyszukiwania — to przejście od rutyny do inteligentnego dostępu do wiedzy bez kompromisów w bezpieczeństwie.
— Editorial Team
Brak komentarzy.