Nyereség:
- Végponttól végpontig terjedő vállalati RAG-asszisztens összetevőinek és adatfolyamának tervezése
- Több forrásból származó adatok (wiki, jegy, PDF, adatbázis) egyesítése egyetlen asszisztensben
- Hozzon építészeti döntéseket a méretezhetőség, a gyorsítótár és a késleltetés érdekében
Az előző egységekben egyenként tanultuk meg a részeket: beágyazás, vektoros adatbázis, darabolás, visszakeresés. Most kombináljuk ezeket, és építsünk fel egy olyan asszisztens végpontok közötti architektúrát, amely kommunikál a saját vállalati adataival. A cél az, hogy egy alkalmazott megkérdezze: „Mi a szabadságpolitikánk?” Egy rendszer, ahol az emberek kérdéseket tehetnek fel, a válaszok valódi belső dokumentumokon, hivatkozásokon alapulnak, és több adatforrást kombinálnak. Ez az egység feldolgozza a teljes architektúrát, az adatáramlást és a termelési szintű döntéseket.
Végponttól végpontig tartó alkatrészek
A vállalati RAG-asszisztens két különálló vonalból áll. Az indexelő sor (offline) előkészíti az adatokat; A lekérdező sor (online) válaszol a kérdésre.
Az indexelési sor összetevői:
- Csatlakozók: Csatlakozók, amelyek forrásokból gyűjtik az adatokat – wiki, jegyrendszer, fájltároló, adatbázis, e-mail.
- Normalizálás: Különféle formátumok (PDF, HTML, DOCX) konvertálása tiszta szöveggé; fejléc/lábléc tisztítása.
- Feldarabolás + metaadatok: Felosztás és címkézés (forrás, dátum, jogosultság).
- Beágyazás + betöltés: Vektorok és metaadatok írása a vektoradatbázisba.
Lekérdezési folyamatösszetevők:
- Lekérdezés előfeldolgozása: Újraírás, decentralizálás.
- Lekérdezés: Hibrid keresés + metaadatszűrő + átsorolás.
- Prompt létrehozás: Kontextus + kérdés + utasítások elhelyezése a sablonban.
- Generáció: megalapozott (kontextuális) válasz a modellből + források.
- Utófeldolgozás: Idézet formázása, biztonsági ellenőrzés, naplózás.
Tipp: Fizikailag válassza le az indexelési sort a lekérdezési sortól. Az indexelés lassú és időszakos (egy éjszakán át kötegekben fut); A megkeresésnek könnyűnek és azonnalinak kell lennie. A két sor keverése nehéz feldolgozást kényszerít ki, amíg a felhasználó vár.
Az adatfolyam megjelenítése
[INDEXING - offline]Erőforrások → Normalizálás → Csom.+Metaadatok → Beágyazás → Vector DB (wiki, jegy, PDF, DB)[QUERY - online]Felhasználói kérdés → Előfeldolgozás → Lehívás (hibrid+szűrő+újrarangsorolás) → Prompt (környezet+kérdés+utasítás) → Modell → Válasz+Forrás →
Többforrású adatok kombinálása
A valódi cégeknél a válasz nem áll meg egy helyen. "Hogyan kérhetek visszatérítést az ügyfélnek?" A kérdésre a válasz megtalálható mind a súgócikkben (eljárás), mind a jegyelőzményekben (valódi példák), mind a szabályzat PDF-ben (szabályok). Az asszisztensnek mindegyiket át kell keresnie egy készletben.
Kritikus pont: amikor az erőforrásokat egyetlen vektortárba egyesítjük, minden szilánknak tartalmaznia kell a „source_tour” metaadatokat. Így mindegyikben kereshet, és szükség esetén szűrheti őket, például "csak hozzon hivatalos szabályzatot". Ezenkívül a különböző források különböző megbízhatósági szintekkel rendelkeznek: hivatalos szabályzat > súgócikk > alkalmazott jegyzete. Ezt a prioritást az újrarangsorolásban vagy promptban adhatja meg.
Forrás
Tartalom típusa
bizalom
Frissítési gyakoriság
Szabályzat PDF
hivatalos szabály
magas
havonta
Súgócikk
Eljárás
középmagas
hetente
Jegytörténet
valódi minta
közepes
Folyamatos
wiki
Vegyes/aktuális hangjegy
Változó
Folyamatos
Skálázhatóság, gyorsítótár és késleltetés
Három probléma emelkedik ki a gyártásban. Késés: Az élmény romlik, ha a felhasználó több mint 2 másodpercet vár. Megoldás: jelenítse meg a választ streaming formában – a modell írása közben a képernyőre önti. Gyorsítótár: A gyakran ismétlődő kérdések és az ismétlődő kontextusok esetén a gyorsítótár növeli a sebességet és csökkenti a költségeket. Méretezés: A felhasználó növekedésével szükséges a hívások vízszintes méretezése és modellezése.
Ökölszabály a költség oldalon: a legdrágább lépés általában a nagyobb modellhez kerülő tokenek száma. Ezért, ha a szövegkörnyezetet 4 jó alkatrészre redukálják az átsorolással, javítja a minőséget és a költségeket is. Gyakori megoldás, hogy egy kisebb/gyorsabb modellt használnak az egyszerű osztályozáshoz vagy útválasztáshoz, és egy erősebb modellt a végső válaszhoz (pl. claude-opus-4-8).
Figyelem: Ne állítsa be az indexelést úgy, hogy "csináld egyszer, felejtsd el". A dokumentumokat módosítják, törlik, hozzáadják. Hozzon létre egy újraindexelési stratégiát: észlelje a megváltozott dokumentumokat, és csak azokat dolgozza fel újra. Az elavult index olyan választ ad, amely aktuálisnak tűnik, de hibás.
Gyenge építészet / erős építészet
Gyenge (egy forgatókönyv, minden vegyes):
Amikor a felhasználó megkérdezi: olvassa el a dokumentumokat abban a pillanatban, aprítsa fel, ágyazza be, keresse meg, válaszoljon rájuk.# Probléma: minden indexelés megismétlődik minden kérdésnél; másodperces késleltetés, # nincs forrás szétválasztás, nincs szűrő, nincs frissítés.
Erőteljes (osztott csövek + metaadatok + gyorsítótár + streaming):
Indexelés: éjszakai köteg fut, a megváltozott dokumentumok frissítése. Lekérdezés: lightweight line — előfeldolgozás → hibrid visszakeresés+szűrő → rerank → prompt → modell (streaming) → idézet → napló. A gyakran ismételt kérdések és a forrás gyorsítótárban vannak.
Három mini tok
1. eset – Zavaros vonal, nagy késés. Egy startup írt egy szkriptet, amely minden kérdésnél újra feldolgozza a PDF-eket; Mindegyik válasz átlagosan 11 másodpercet vett igénybe. Az indexelési sor szétválasztása és az adatok előzőleg a vektortárba való átvitele után a lekérdezési idő 1,3 másodpercre csökkent, és streameléssel 400 ms alatt megjelent az "első szó".
2. eset – Túl sok erőforrás, rossz prioritás. Egy támogatási asszisztens azonos súlyt adott a szabályzat PDF-nek és a régi jegyzeteknek; A modell néha hivatalos szabályként egy alkalmazott két évvel ezelőtti hibás minősítését adta elő. Amikor a forrás_túra metaadatait és a „ütközés esetén fontolja meg a hivatalos szabályzatot” utasítást a prompthoz, a hamis prioritású hibák 89%-kal csökkentek.
3. eset – Elavult index. Egy HR-asszisztens olyan indexszel dolgozott, amelyet 3 hónapja nem frissítettek; A szabadságra vonatkozó politika megváltozott, de az asszisztens a régi időket mondta. A napi frissítés telepítésekor, amely észleli a megváltozott fájlokat, az aktuális válaszarány 70%-ról 99%-ra nőtt.
Gyakori hibák
- Indexelési és lekérdezési sorok keverése: Nehéz feldolgozás történik, amíg a felhasználó vár; késleltetés robban.
- A forrástípus nem szerepel a metaadatokban: Nincs prioritás és szűrés; A megbízhatatlan forrás hivatalosnak tűnik.
- Nem hoz létre frissítési stratégiát: Az index elavulttá válik; Hibás, aktuálisnak tűnő válaszok jönnek létre.
- Adatfolyam kihagyása: A felhasználó egy üres képernyőt néz; Az észlelt késleltetés magas lesz.
- A legnagyobb modell használata minden lépésnél: A költségek szükségtelenül nőnek; Hagyja a kormányzást a kisebb modellre.
Összefoglalva
- A vállalati RAG-asszisztens két külön sorból áll: offline indexelésből és online lekérdezésből; fizikailag szétválasztani őket.
- Indexelés = csatlakozó + normalizálás + darab/metaadatok + beágyazás/feltöltés; lekérdezés = előfeldolgozás + visszakeresés + felszólítás + generálás + utófeldolgozás.
- A több forrásból származó adatok egyetlen tárba vannak egyesítve, de a forrástípus metaadatok és a megbízhatósági prioritás megmarad.
- A streamelés és a gyorsítótár a késleltetéshez, a kontextusszabályozás és a költségmodell kiválasztása kritikus fontosságú.
- Újraindexelés nélkül az index elavulttá válik; A változó dokumentumok rendszeres újrafeldolgozása.
Pályázati feladat
Rajzoljon egy asszisztens építészeti diagramját a saját csapata számára. (1) Határozzon meg legalább három valós adatforrást, és írja le mindegyikhez az összekötő szükségességét, frissítési gyakoriságát és megbízhatósági szintjét. (2) Rajzolja meg külön-külön az indexelési és lekérdezési vonalakat egy doboz-nyíl diagrammal. (3) „Hol csökkenthetem a késleltetést és a költségeket ebben az asszisztensben?” Írj legalább két konkrét döntést a kérdésre! (4) Egy mondatban írja le a frissítési stratégiáját: melyik erőforrás lesz újraindexelve és milyen gyakran?
ellenőrző lista
- [ ] Az indexelő és lekérdező sorokat külön és a megfelelő komponensekkel tudom megrajzolni.
- [ ] Kombinálhatok több forrásból származó adatokat a forrás_típussal és a megbízhatósági prioritással.
- [ ] Döntéseket tudok hozni a streamelésről/gyorsítótárról a késleltetésről és a modell kiválasztásáról a költségek alapján.
- [ ] Tudom, miért elengedhetetlen az újraindexelési stratégia.
- [ ] Szem előtt tartom, hogy az architektúrám legdrágább lépése általában a nagyobb modellhez tartozó token.