Hybridní RAG bez cloudu: vyhledávání v korporátních dokumentech

# Hybridní RAG v podnikových systémech: vyhledávání v dokumentech bez cloudu a úniků

Velké společnosti v regulovaných odvětvích se potýkají s nemocí: vyhledávání ve vnitřních dokumentech zabírá hodiny. Manažer logistické firmy například tráví čas procházením e-mailů, SharePointu a archivů, aby ověřil historii stížností na dodavatele. Příčina spočívá v absenci inteligentního vyhledávání, které chápe smysl dotazu, nejen klíčová slova. Hybridní RAG tento problém řeší tím, že data zůstávají uvnitř bezpečnostního obvodu společnosti.

Proč klasické vyhledávání selhává v regulovaných odvětvích

Podnikové archivy obsahují PDF, skeny, tabulky a korespondenci ve dvou jazycích. Standardní systémy pro elektronickou správu dokumentů a vyhledávací systémy se s heterogenními daty nevypořádají. Dotaz „byly spory pod kódem 8471300000?“ vyžaduje současně sémantické porozumění a přesné shody podle čísla. Běžný RAG postavený na sémantickém vyhledávání selže, když dokumenty obsahují tabulky, ručně psané poznámky nebo vícejazyčný obsah. V bankách, celních úřadech a právních firmách data nesmí opustit bezpečnostní obvod – cloudová řešení jsou vyloučena architektonickými požadavky.

Hybridní RAG spojuje dva přístupy:

• Sémantické vyhledávání (dense vectors) pro porozumění smyslu
• Přesné vyhledávání (sparse vectors) pro kódy, artikly a čísla

Není to jen kombinace, ale matematicky odůvodněné slévání výsledků prostřednictvím Reciprocal Rank Fusion (RRF). Algoritmus funguje bez ručního nastavování vah a dalšího tréninku, je integrován do vektorových databází jako Qdrant.

Architektura self-hosted hybridního RAG: od dokumentu k odpovědi

Proces zpracování dotazu zahrnuje šest fází, z nichž každá je klíčová pro bezpečnost a přesnost:

• Předzpracování dokumentů – knihovna Docling normalizuje skeny na 300 DPI, extrahuje tabulky a strukturu. To je nezbytné pro správný chod multimodálního modelu Qwen2.5-VL, který čte ručně psané poznámky a složité tabulky.
• Generování dvojitých embeddingů – model BAAI/bge-m3 vytváří pro každý chunk dva vektory: dense (sémantika) a sparse (přesné shody). Použití jednoho modelu pro indexování i dotazy zaručuje kompatibilitu prostorů.
• Hybridní vyhledávání v Qdrant – současný dotaz na dense a sparse vektory s automatickým sléváním přes RRF.
• Předběžné řazení – FastEmbed zkrátí seznam na 10 kandidátů za 30–50 ms.
• Finální reranking – cross-encoder bge-reranker-v2-m3 hodnotí relevanci fragmentu k konkrétnímu dotazu. Self-hosted varianta přidává zpoždění 150–400 ms, ale udržuje data uvnitř obvodu.
• Generování odpovědi – kvantovaný model Qwen2.5-72B-Instruct (AWQ INT4) vytváří odpověď na základě filtrovaného kontextu.

Klíčová vlastnost – všechny fáze probíhají lokálně. Dokonce i reranking, který v cloudových řešeních (např. Voyage AI) zrychluje proces, je zde realizován přes self-hosted komponenty pro dodržení požadavků na suverenitu dat.

Nástroje pro produkci: proč jsou LangGraph a Haystack nezbytné

LangChain je vhodný pro prototypy, ale v regulovaných prostředích vznikají dva problémy. Za prvé, absence nativního řízení stavu: zpracování scénářů jako „pokud rerank-score pod prahem – přeformuluj dotaz“ vyžaduje okliky. LangGraph to řeší explicitními uzly grafu, což je klíčové pro ladění v produkci.

Za druhé, problém observability. Bez traceování degradace kvality odpovědí (kvůli aktualizaci dokumentů nebo změně vzorců dotazů) zůstane nepovšimnuta až do stížností uživatelů. Langfuse (self-hosted) zaznamenává:

• Najdené fragmenty
• Rerank-score
• Latenci podle fází

Důležité je, že Langfuse také funguje uvnitř obvodu – jinak by podniková data skončila v cizím SaaS.

Haystack se stará o testování před produkcí. Při změně pipeline (např. strategie chunkování) systém umožňuje spustit evaluaci na kontrolním souboru a získat metriky:

• Přesnost vyhledávání (jak často je správný dokument v top-5)
• Soulad odpovědi se zdrojem

To poskytuje jistotu, že změny systém zlepšují, ne zhoršují. LlamaIndex, ačkoli flexibilní pro prototypování, zaostává v hloubce vestavěných nástrojů pro evaluaci.

Optimalizace pod infrastrukturu: od RTX 4090 po A100

Výběr modelu závisí na rozpočtu a požadavcích na kvalitu:

• Qwen2.5-72B-Instruct v AWQ INT4 – vlajkový model. Vyžaduje dva A100 80GB, zajišťuje maximální kvalitu, zejména s tabulkovými daty. Vhodný pro velké právní firmy nebo banky.
• Qwen2.5-32B-Instruct – optimální řešení. Běží na jedné L40S 48GB (v 3x levnější než A100), zachovává 90 % kvality 72B verze. Doporučeno pro start.
• Qwen2.5-14B-Instruct – varianta pro omezené zdroje. Funguje na RTX 4090, ale klesá na složitých vícekrokových dotazech.

Praktická rada: začněte s 32B na L40S, testujte na reálných datech, škálujte jen při potřebě. Kvantování AWQ INT4 snižuje spotřebu paměti na polovinu bez kritické ztráty kvality.

Co je důležité

• Hybridní RAG je nezbytný pro heterogenní archivy: kombinuje sémantické vyhledávání a přesné shody přes RRF.
• Self-hosted architektura je povinná podmínka pro regulovaná odvětví. Data neopouštějí obvod v žádné fázi.
• LangGraph a Haystack jsou klíčové pro produkci: první řídí logiku dotazu v reálném čase, druhý zajišťuje objektivní hodnocení kvality.
• Infrastrukturní náklady lze optimalizovat: Qwen2.5-32B na L40S poskytuje 90 % kvality vlajkového modelu při trojnásobné úspoře.

Systém odpovídá během sekund, odkazuje na konkrétní dokumenty a stránky a upřímně přiznává nedostatek dat místo halucinací. Není to jen vylepšení vyhledávání – je to přechod od rutiny k inteligentnímu přístupu k znalostem bez kompromisů v bezpečnosti.

— Editorial Team