zisky:
- Navrhování komponent a datového toku end-to-end podnikového asistenta RAG
- Kombinace dat z více zdrojů (wiki, tiket, PDF, databáze) do jednoho asistenta
- Provádějte architektonická rozhodnutí ohledně škálovatelnosti, ukládání do mezipaměti a latence
V předchozích dílech jsme se jednotlivé části učili jednu po druhé: vkládání, vektorová databáze, chunking, vyhledávání. Nyní je zkombinujme a vybudujeme komplexní architekturu asistenta, který mluví s vašimi vlastními firemními daty. Cílem je, aby se zaměstnanec zeptal: „Jaké jsou naše zásady dovolené? Systém, kde lidé mohou klást otázky, odpovědi jsou založeny na skutečných interních dokumentech, citacích a kombinují více zdrojů dat. Tato jednotka zpracovává celou architekturu, tok dat a rozhodnutí o úrovni výroby.
End-to-End komponenty
Firemní asistent RAG se skládá ze dvou samostatných linek. Řádek indexování (offline) připraví data; Dotazový řádek (online) odpovídá na otázku.
Komponenty indexové čáry:
- Konektory: Konektory, které stahují data ze zdrojů — wiki, lístkový systém, úložiště souborů, databáze, e-mail.
- Normalizace: Převod různých formátů (PDF, HTML, DOCX) na čistý text; čištění záhlaví/zápatí.
- Chunking + metadata: Chunking a označování (zdroj, datum, autorita).
- Vkládání + načítání: Zápis vektorů a metadat do vektorové databáze.
Komponenty kanálu dotazů:
- Předzpracování dotazu: Přepisování, decentralizace.
- Vyhledávání: Hybridní vyhledávání + filtr metadat + přehodnocení.
- Vytvoření výzvy: Umístění kontextu + otázky + pokynů do šablony.
- Generování: Uzemněná (kontextová) odpověď z modelu + zdroje.
- Následné zpracování: Formátování citace, bezpečnostní kontrola, protokolování.
Tip: Fyzicky oddělte řádek indexování od řádku dotazu. Indexace je pomalá a periodická (běží v dávkách přes noc); Linka dotazu by měla být lehká a bezprostřední. Smíchání dvou řádků vyžaduje náročné zpracování, zatímco uživatel čeká.
Vizualizace datového toku
[INDEXING - offline]Zdroje → Normalizovat → Chunk+Metadata → Vložit → Vektorová DB (wiki, tiket, PDF, DB)[QUERY - online]Dotaz uživatele → Předběžné zpracování → Načtení (hybrid+filtr+přehodnocení) → Výzva (kontext+otázka+pokyn) → Model → Odpověď+zdroj → Uživatel
Kombinování vícezdrojových dat
Ve skutečných společnostech se odpověď nezastaví na jednom místě. "Jak vrátit zákazníkovi peníze?" Odpověď na otázku lze nalézt jak v článku nápovědy (postup), v historii tiketu (reálné příklady), tak v zásadě PDF (pravidla). Asistent by je měl všechny prohledat v jedné skupině.
Kritický bod: při kombinování zdrojů do jednoho vektorového úložiště musí každý fragment nést metadata `source_tour`. Můžete je tedy všechny prohledávat a v případě potřeby filtrovat, například „přinášejte pouze oficiální zásady“. Různé zdroje mají také různou úroveň spolehlivosti: oficiální zásady > článek nápovědy > lístek zaměstnance. Tuto prioritu můžete zadat při změně pořadí nebo výzvě.
Zdroj
Typ obsahu
důvěřovat
Frekvence aktualizace
Zásady PDF
oficiální pravidlo
vysoká
měsíčně
Článek nápovědy
Postup
středně vysoká
týdně
Historie lístků
skutečný vzorek
střední
Kontinuální
wiki
Smíšená/aktuální poznámka
Variabilní
Kontinuální
Škálovatelnost, mezipaměť a latence
V produkci vynikají tři problémy. Latence: Zkušenost se zhoršuje, když uživatel čeká déle než 2 sekundy. Řešení: zobrazte odpověď ve streamované podobě — vysype se na obrazovku tak, jak modelka píše. Mezipaměť: U často kladených otázek a opakujících se kontextů mezipaměť zvyšuje rychlost a snižuje náklady. Měřítko: Jak se uživatel zvětšuje, je nutné mít možnost horizontálně měnit měřítko vyhledávání a volání modelu.
Základní pravidlo na straně nákladů: nejdražším krokem je obvykle počet tokenů připadajících na větší model. Proto snížení kontextu na 4 dobré části změnou pořadí zlepšuje kvalitu i náklady. Běžným návrhem je použití menšího/rychlejšího modelu pro jednoduchou klasifikaci nebo směrování a výkonnějšího modelu pro konečnou odpověď (např. claude-opus-4-8).
Upozornění: Nenastavujte indexování jako „udělej to jednou, zapomeň na to“. Dokumenty se mění, mažou, přidávají. Stanovte si strategii opětovného indexování: zjistěte změněné dokumenty a znovu je zpracujte. Zastaralý index vytváří odpověď, která se jeví jako aktuální, ale je nesprávná.
Slabá architektura / Silná architektura
Slabé (jediný scénář, vše smíšené):
Když se uživatel zeptá: přečtěte si dokumenty v tu chvíli, skartujte je, vložte je, prohledejte je, odpovězte na ně.# Problém: veškerá indexace se opakuje pro každou otázku; sekund zpoždění, # žádné oddělení zdroje, žádný filtr, žádné obnovení.
Výkonné (rozdělené kanály + metadata + mezipaměť + streamování):
Indexování: dávkové spouštění v noci, obnovování změněných dokumentů. Dotaz: odlehčený řádek — předběžné zpracování → hybridní vyhledávání+filtr → přehodnocení → výzva → model (streamování) → citace → log. Často kladené otázky a zdroje jsou uloženy v mezipaměti.
Tři mini pouzdra
Případ 1 – Zmatená linka, velké zpoždění. Startup napsal skript, který znovu zpracuje PDF s každou otázkou; Každá odpověď trvala v průměru 11 sekund. Když byl řádek indexování oddělen a data byla předtím přenesena do vektorového úložiště, čas dotazu se zkrátil na 1,3 sekundy a při streamování se „první slovo“ objevilo za 400 ms.
Případ 2 — Příliš mnoho zdrojů, špatná priorita. Asistent podpory dal stejnou váhu zásadám PDF a starým lístkům; Model někdy prezentoval nesprávné hodnocení zaměstnance z doby před dvěma lety jako oficiální pravidlo. Když byla do výzvy přidána metadata source_tour a instrukce „v případě konfliktu zvažte oficiální politiku“, chyby s falešnou prioritou se snížily o 89 %.
Případ 3 – Zastaralý index. HR asistent pracoval s indexem, který nebyl aktualizován po dobu 3 měsíců; Pravidla dovolené se změnila, ale asistent říkal staré časy. Když byla nainstalována denní aktualizace, která detekuje změněné soubory, rychlost aktuální odezvy se zvýšila ze 70 % na 99 %.
Časté chyby
- Míchání řádků indexování a dotazů: Náročné zpracování se provádí, zatímco uživatel čeká; zpoždění exploduje.
- Neuvedení typu zdroje do metadat: Žádná priorita a filtrování; Zdá se, že nedůvěryhodný zdroj je oficiální.
- Nestanovení obnovovací strategie: Index se stane zastaralým; Vytvářejí se nesprávné odpovědi, které se zdají aktuální.
- Přeskočit streamování: Uživatel se dívá na prázdnou obrazovku; Vnímané zpoždění je vysoké.
- Použití největšího modelu v každém kroku: Náklady se zbytečně zvyšují; Řízení nechte na menším modelu.
V souhrnu
- Podnikový asistent RAG se skládá ze dvou samostatných řad: offline indexování a online dotaz; fyzicky je oddělit.
- Indexování = konektor + normalizace + blok/metadata + vložení/nahrání; dotaz = předzpracování + vyhledání + výzva + vygenerování + následné zpracování.
- Vícezdrojová data jsou sloučena do jednoho úložiště, ale metadata source_type a priorita důvěryhodnosti jsou zachovány.
- Streamování a mezipaměť pro latenci, omezování kontextu a výběr modelu z hlediska nákladů jsou zásadní.
- Bez opětovného indexování se index stane zastaralým; Měnící se dokumenty pravidelně zpracovávat.
Aplikační úkol
Nakreslete architektonický diagram asistenta pro svůj vlastní tým. (1) Identifikujte alespoň tři skutečné zdroje dat a zapište si pro každý potřebu konektoru, frekvenci aktualizací a úroveň důvěryhodnosti. (2) Nakreslete čáry indexování a dotazu odděleně pomocí diagramu s obdélníkovou šipkou. (3) „Kde u tohoto asistenta snížím latenci a náklady?“ Napište k otázce alespoň dvě konkrétní rozhodnutí. (4) Popište svou strategii obnovování jednou větou: který zdroj bude reindexován a jak často?
kontrolní seznam
- [ ] Dokážu nakreslit čáry indexování a dotazu samostatně a se správnými komponentami.
- [ ] Mohu kombinovat data z více zdrojů s typem zdroje a prioritou důvěryhodnosti.
- [ ] Mohu rozhodovat o streamování/mezipaměti pro latenci a výběr modelu podle ceny.
- [ ] Vím, proč je strategie opětovného indexování nezbytná.
- [ ] Mám na paměti, že nejdražším krokem v mé architektuře je obvykle token, který jde do většího modelu.