zisky:
- Navrhovanie komponentov a dátového toku end-to-end podnikového asistenta RAG
- Spojenie dát z viacerých zdrojov (wiki, lístok, PDF, databáza) do jedného asistenta
- Robte architektonické rozhodnutia týkajúce sa škálovateľnosti, ukladania do vyrovnávacej pamäte a latencie
V predchádzajúcich častiach sme sa jednotlivé časti učili jednu po druhej: vkladanie, vektorová databáza, chunking, vyhľadávanie. Teraz ich skombinujme a zostavme komplexnú architektúru asistenta, ktorý sa rozpráva s vašimi vlastnými firemnými údajmi. Cieľom je, aby sa zamestnanec spýtal: „Aká je naša politika dovoleniek? Systém, kde ľudia môžu klásť otázky, odpovede sú založené na skutočných interných dokumentoch, citáciách a kombinujú viaceré zdroje údajov. Táto jednotka spracováva celú architektúru, dátový tok a rozhodnutia o úrovni produkcie.
End-to-End komponenty
Firemný pomocník RAG pozostáva z dvoch samostatných línií. Riadok indexovania (offline) pripravuje údaje; Dotazový riadok (online) odpovedá na otázku.
Komponenty indexovej čiary:
- Konektory: Konektory, ktoré získavajú údaje zo zdrojov – wiki, systém lístkov, úložisko súborov, databáza, e-mail.
- Normalizácia: Konverzia rôznych formátov (PDF, HTML, DOCX) na čistý text; čistenie hlavičky/päty.
- Chunking + metadáta: Chunking a označovanie (zdroj, dátum, autorita).
- Vkladanie + načítanie: Zápis vektorov a metadát do vektorovej databázy.
Komponenty dopytového kanála:
- Predspracovanie dotazu: Prepisovanie, decentralizácia.
- Získavanie: Hybridné vyhľadávanie + filter metadát + prehodnotenie.
- Vytvorenie výzvy: Umiestnenie kontextu + otázky + pokynov do šablóny.
- Generovanie: Uzemnená (kontextová) odpoveď z modelu + zdrojov.
- Následné spracovanie: Formátovanie citácií, bezpečnostná kontrola, protokolovanie.
Tip: Fyzicky oddeľte riadok indexovania od riadku dotazu. Indexovanie je pomalé a periodické (beží v dávkach cez noc); Linka vyšetrovania by mala byť ľahká a okamžitá. Zmiešanie dvoch riadkov si vynúti náročné spracovanie, kým používateľ čaká.
Vizualizácia toku údajov
[INDEXING - offline]Zdroje → Normalizovať → Chunk+Metadata → Vložiť → Vector DB (wiki, tiket, PDF, DB)[QUERY - online]Otázka používateľa → Predspracovanie → Získavanie (hybrid+filter+prehodnotenie) → Výzva (kontext+otázka+pokyn) → Model → Odpoveď+Zdroj → Používateľ
Kombinovanie údajov z viacerých zdrojov
V skutočných spoločnostiach sa odpoveď nezastaví na jednom mieste. "Ako vrátiť zákazníkovi peniaze?" Odpoveď na otázku možno nájsť v článku pomocníka (postup), v histórii tiketov (reálne príklady) a v zásade PDF (pravidlá). Asistent by ich mal všetky prehľadať v jednom bazéne.
Kritický bod: pri kombinovaní zdrojov do jedného vektorového úložiska musí každý zlomok niesť metadáta `source_tour`. Môžete ich teda všetky prehľadávať a v prípade potreby filtrovať, napríklad „priniesť len oficiálne pravidlá“. Rôzne zdroje majú tiež rôznu úroveň spoľahlivosti: oficiálna politika > článok pomocníka > poznámka zamestnanca. Túto prioritu môžete zadať pri zmene poradia alebo pri výzve.
Zdroj
Typ obsahu
dôverovať
Frekvencia aktualizácie
Zásady PDF
oficiálne pravidlo
vysoká
mesačne
Článok pomocníka
Postup
stredne vysoká
týždenne
História lístkov
skutočná vzorka
stredná
Nepretržitý
wiki
Zmiešaná/aktuálna poznámka
Variabilné
Nepretržitý
Škálovateľnosť, vyrovnávacia pamäť a latencia
Vo výrobe vynikajú tri problémy. Latencia: Zážitok sa zhoršuje, keď používateľ čaká viac ako 2 sekundy. Riešenie: zobrazte odpoveď vo forme streamovania — vysype sa na obrazovku tak, ako modelka píše. Cache: Pre často kladené otázky a opakujúce sa kontexty, cache zvyšuje rýchlosť a znižuje náklady. Mierka: Keď sa používateľ zväčšuje, je potrebné, aby bolo možné horizontálne škálovať vyhľadávanie a modelovanie.
Základné pravidlo na strane nákladov: najdrahším krokom je zvyčajne počet tokenov, ktoré idú do väčšieho modelu. Preto zníženie kontextu na 4 dobré časti prehodnotením zlepšuje kvalitu aj náklady. Bežným návrhom je použitie menšieho/rýchlejšieho modelu na jednoduchú klasifikáciu alebo smerovanie a výkonnejšieho modelu na konečnú odpoveď (napr. claude-opus-4-8).
Upozornenie: Nenastavujte indexovanie ako „urob to raz, zabudni na to“. Dokumenty sa menia, vymazávajú, pridávajú. Vytvorte stratégiu opätovného indexovania: zistite zmenené dokumenty a znova ich spracujte. Zastaraný index vytvára odpoveď, ktorá sa zdá aktuálna, ale je nesprávna.
Slabá architektúra / Silná architektúra
Slabé (jeden scenár, všetko zmiešané):
Keď sa používateľ spýta: v tej chvíli si prečítajte dokumenty, skartujte ich, vložte ich, hľadajte v nich, odpovedzte na ne.# Problém: všetky indexy sa opakujú pre každú otázku; sekundy oneskorenia, # žiadne oddelenie zdroja, žiadny filter, žiadne obnovenie.
Výkonné (rozdelené kanály + metadáta + vyrovnávacia pamäť + streamovanie):
Indexovanie: dávkové spustenie v noci, obnovenie zmenených dokumentov. Dotaz: ľahký riadok — predbežné spracovanie → hybridné vyhľadávanie+filter → prehodnotenie → výzva → model (streaming) → citácia → protokol. Často kladené otázky a zdroj sú uložené vo vyrovnávacej pamäti.
Tri mini puzdrá
Prípad 1 – Zmätená linka, veľké meškanie. Startup napísal skript, ktorý opätovne spracuje súbory PDF s každou otázkou; Každá odpoveď trvala v priemere 11 sekúnd. Keď bol riadok indexovania oddelený a údaje boli predtým prenesené do vektorového úložiska, čas dopytu sa skrátil na 1,3 sekundy a pri streamovaní sa „prvé slovo“ objavilo za 400 ms.
Prípad 2 – Príliš veľa zdrojov, nesprávna priorita. Asistent podpory dával rovnakú váhu zásadám PDF a starým lístkom; Model niekedy prezentoval nesprávne hodnotenie zamestnanca spred dvoch rokov ako oficiálne pravidlo. Keď boli do výzvy pridané metadáta source_tour a pokyn „v prípade konfliktu zvážte oficiálnu politiku“, chyby s falošnou prioritou sa znížili o 89 %.
Prípad 3 – Zastaraný index. HR asistent pracoval s indexom, ktorý nebol aktualizovaný 3 mesiace; Pravidlá dovoleniek sa zmenili, ale asistent hovoril staré časy. Keď bola nainštalovaná denná obnova, ktorá zisťuje zmenené súbory, rýchlosť aktuálnej odozvy sa zvýšila zo 70 % na 99 %.
Časté chyby
- Miešanie riadkov indexovania a dotazov: Náročné spracovanie sa vykonáva počas čakania používateľa; oneskorenie exploduje.
- Neuvádzanie typu zdroja do metadát: Žiadne uprednostňovanie a filtrovanie; Zdá sa, že nedôveryhodný zdroj je oficiálny.
- Nevytváranie obnovovacej stratégie: Index sa stáva neaktuálnym; Vytvárajú sa nesprávne odpovede, ktoré sa zdajú byť aktuálne.
- Preskočiť streamovanie: Používateľ sa pozerá na prázdnu obrazovku; Vnímané oneskorenie je vysoké.
- Použitie najväčšieho modelu v každom kroku: Náklady sa zbytočne zvyšujú; Riadenie nechajte na menší model.
V súhrne
- Podnikový asistent RAG pozostáva z dvoch samostatných riadkov: offline indexovanie a online dotaz; fyzicky ich oddeliť.
- Indexovanie = konektor + normalizácia + blok/metaúdaje + vloženie/načítanie; dotaz = predbežné spracovanie + vyhľadávanie + výzva + generovanie + následné spracovanie.
- Údaje z viacerých zdrojov sú kombinované do jedného úložiska, ale metadáta source_type a priorita dôveryhodnosti sú zachované.
- Streamovanie a vyrovnávacia pamäť pre latenciu, obmedzovanie kontextu a výber modelu z hľadiska nákladov sú kritické.
- Bez opätovného indexovania sa index stane neaktuálnym; Meniace sa dokumenty pravidelne spracovávajte.
Aplikačná úloha
Nakreslite architektonickú schému asistenta pre svoj vlastný tím. (1) Identifikujte aspoň tri skutočné zdroje údajov a pre každý si zapíšte potrebu konektora, frekvenciu aktualizácie a úroveň dôveryhodnosti. (2) Nakreslite riadky indexovania a dotazu oddelene pomocou diagramu so šípkami. (3) "Kde znížim latenciu a náklady v tomto asistentovi?" Napíšte aspoň dve konkrétne rozhodnutia k otázke. (4) Opíšte svoju stratégiu obnovenia jednou vetou: ktorý zdroj bude reindexovaný a ako často?
kontrolný zoznam
- [ ] Môžem nakresliť riadky indexovania a dotazu samostatne a so správnymi komponentmi.
- [ ] Môžem kombinovať údaje z viacerých zdrojov s typom zdroja a prioritou dôveryhodnosti.
- [ ] Môžem robiť rozhodnutia o streamovaní/vyrovnávacej pamäti pre latenciu a výber modelu podľa ceny.
- [ ] Viem, prečo je stratégia opätovného indexovania nevyhnutná.
- [ ] Mám na pamäti, že najdrahším krokom v mojej architektúre je zvyčajne token, ktorý ide do väčšieho modelu.