Kasu:
- Täieliku ettevõtte RAG assistendi komponentide ja andmevoo kujundamine
- Mitme allika andmete (wiki, pilet, PDF, andmebaas) ühendamine üheks assistendiks
- Tehke arhitektuurseid otsuseid skaleeritavuse, vahemällu salvestamise ja latentsuse osas
Eelmistes osakondades õppisime osi ükshaaval: kinnistamine, vektorandmebaas, tükkideks jagamine, otsimine. Nüüd ühendame need ja loome assistendi täieliku arhitektuuri, mis räägib teie enda ettevõtte andmetega. Eesmärk on lasta töötajal küsida: "Mis on meie puhkusepoliitika?" Süsteem, kus inimesed saavad küsimusi esitada, vastused põhinevad reaalsetel sisedokumentidel, tsitaatidel ja kombineerivad mitut andmeallikat. See üksus töötleb kogu arhitektuuri, andmevoo ja tootmistasandi otsuseid.
Otsast lõpuni komponendid
Ettevõtte RAG-i assistent koosneb kahest eraldi reast. Indekseerimisrida (offline) valmistab andmed ette; Päringurida (võrgus) vastab küsimusele.
Indekseerimisrea komponendid:
- Ühendused: konnektorid, mis tõmbavad andmeid allikatest – wikist, piletisüsteemist, failihoidlast, andmebaasist, meilist.
- Normaliseerimine: erinevate vormingute (PDF, HTML, DOCX) teisendamine puhtaks tekstiks; päise/jaluse puhastamine.
- Tükeldamine + metaandmed: tükeldamine ja sildistamine (allikas, kuupäev, asutus).
- Manustamine + laadimine: vektorite ja metaandmete kirjutamine vektorite andmebaasi.
Päringu konveieri komponendid:
- Päringu eeltöötlus: ümberkirjutamine, detsentraliseerimine.
- Otsimine: hübriidotsing + metaandmete filter + järjestamine ümber.
- Viipe loomine: konteksti + küsimuse + juhiste lisamine malli.
- Põlvkond: maandatud (kontekstuaalne) vastus mudelist + allikad.
- Järeltöötlus: tsitaadi vormindamine, turvakontroll, logimine.
Näpunäide. Eraldage indekseerimisrida füüsiliselt päringurealt. Indekseerimine on aeglane ja perioodiline (töötab partiidena üleöö); Päring peaks olema kerge ja vahetu. Kahe rea segamine sunnib kasutaja ootamise ajal rasket töötlemist.
Andmevoo visualiseerimine
[INDEKSERIMINE – võrguühenduseta]Ressursid → Normaliseeri → Tükk+Metaandmed → Manusta → Vektori andmebaas (wiki, pilet, PDF, DB)[PÄRING – võrgus]Kasutaja küsimus → Eeltöötlus → Otsimine (hübriid+filter+reiting) → Viip (kontekst+küsimus+juhis) → Mudel → Vastus+Allikas →
Mitme allika andmete kombineerimine
Päris ettevõtetes ei peatu vastus ühes kohas. "Kuidas kliendile raha tagasi maksta?" Vastuse küsimusele leiab nii abiartiklist (protseduur), piletite ajaloost (reaalsed näited) kui ka poliitika PDF-ist (reeglid). Assistent peaks need kõik ühest basseinist läbi otsima.
Kriitiline punkt: kui ühendate ressursse üheks vektorsalveks, peab iga killu kandma metaandmeid "source_tour". Nii saate neid kõiki otsida ja vajadusel filtreerida, näiteks "too ainult ametlikud eeskirjad". Samuti on erinevatel allikatel erinev usaldusväärsuse tase: ametlik poliitika > abiartikkel > töötaja piletimärkus. Saate selle prioriteedi määrata ümberpaigutamise või viipa kaudu.
Allikas
Sisu tüüp
usaldada
Värskendamise sagedus
Poliitika PDF
ametlik reegel
kõrge
igakuine
Abiartikkel
Menetlus
keskmine-kõrge
iganädalane
Pileti ajalugu
tõeline näidis
keskmine
Pidev
wiki
Segatud/praegune noot
Muutuv
Pidev
Skaleeritavus, vahemälu ja latentsusaeg
Tootmises paistavad silma kolm probleemi. Latentsus: kasutuskogemus halveneb, kui kasutaja ootab rohkem kui 2 sekundit. Lahendus: kuvage vastus voogedastusvormingus – see valatakse mudeli kirjutamise ajal ekraanile. Vahemälu: korduma kippuvate küsimuste ja korduvate kontekstide puhul suurendab vahemälu kiirust ja vähendab kulusid. Skaala: kasutaja kasvades on vaja hankimist ja kõnesid horisontaalselt modelleerida.
Rusikareegel kulu poolel: kõige kallim samm on tavaliselt suuremale mudelile minevate žetoonide arv. Seetõttu parandab konteksti taandamine neljale heale osale ümber järjestamise teel nii kvaliteeti kui ka kulusid. Levinud lahendus on kasutada väiksemat/kiiremat mudelit lihtsaks klassifitseerimiseks või marsruutimiseks ja võimsamat mudelit lõplikuks vastuseks (nt claude-opus-4-8).
Ettevaatust: ärge seadistage indekseerimist kui "tee üks kord, unusta see". Dokumente muudetakse, kustutatakse, lisatakse. Looge uuesti indekseerimise strateegia: tuvastage muutunud dokumendid ja töötlege ainult neid. Vananenud indeks annab vastuse, mis näib olevat aktuaalne, kuid on vale.
Nõrk arhitektuur / tugev arhitektuur
Nõrk (üks skript, kõik segamini):
Kui kasutaja küsib: lugege dokumente sel hetkel, tükeldage, manustage, otsige, vastake neile.# Probleem: iga küsimuse puhul korratakse kogu indekseerimist; sekundit viivitust, # allikate eraldamist, filtrit, värskendamist pole.
Võimas (lõigatud torud + metaandmed + vahemälu + voogesitus):
Indekseerimine: partii töötab öösel, muudetud dokumentide värskendamine. Päring: kerge rida — eeltöötlus → hübriidotsing+filter → rerank → viip → mudel (voogesitus) → tsiteerimine → logi. Korduma kippuvad küsimused ja allikas salvestatakse vahemällu.
Kolm miniümbrist
Juhtum 1 – segane rida, suur viivitus. Käivitaja kirjutas skripti, mis töötleb iga küsimusega PDF-faile uuesti; Igale vastusele kulus keskmiselt 11 sekundit. Kui indekseerimisrida eraldati ja andmed kanti eelnevalt vektorsalve, lühenes päringuaeg 1,3 sekundini ja voogedastusega ilmus "esimene sõna" 400 ms pärast.
Juhtum 2 – liiga palju ressursse, vale prioriteet. Tugiabi andis võrdse kaalu poliitika PDF-ile ja vanadele piletimärkmetele; Mõnikord esitas mudel ametliku reeglina töötaja kahe aasta taguse vale hinnangu. Kui viipale lisati source_tour metaandmed ja juhis "konflikti korral kaaluge ametlikku poliitikat", vähenesid valeprioriteediga vead 89%.
Juhtum 3 – aegunud indeks. Personali assistent töötas indeksiga, mida ei värskendatud 3 kuud; Puhkusepoliitika on muutunud, kuid assistent rääkis vanasti. Kui installiti igapäevane värskendus, mis tuvastab muudetud failid, tõusis praegune reageerimise määr 70%-lt 99%-le.
Levinud vead
- Indekseerimis- ja päringuridade segamine: intensiivne töötlemine toimub kasutaja ootamise ajal; viivitus plahvatab.
- Lähtetüübi metaandmetesse lisamata jätmine: prioritiseerimine ja filtreerimine puudub; Ebausaldusväärne allikas näib olevat ametlik.
- Värskendusstrateegiat ei kehtestata: indeks muutub aeglaseks; Antakse valed vastused, mis näivad olevat aktuaalsed.
- Voogesituse vahelejätmine: kasutaja vaatab tühja ekraani; Tajutav viivitus muutub suureks.
- Suurima mudeli kasutamine igal etapil: kulud suurenevad tarbetult; Jätke juhtimine väiksemale mudelile.
Kokkuvõttes
- Ettevõtte RAG-i assistent koosneb kahest eraldi reast: võrguühenduseta indekseerimine ja võrgupäring; eraldage need füüsiliselt.
- Indekseerimine = konnektor + normaliseerimine + tükk/metaandmed + manustamine/üleslaadimine; päring = eeltöötlus + otsimine + viip + genereerimine + järeltöötlus.
- Mitme allika andmed ühendatakse ühte hoidlasse, kuid allikatüübi metaandmed ja usaldusprioriteet säilivad.
- Latentsi voogesitus ja vahemälu, konteksti piiramine ja kulude mudeli valimine on kriitilise tähtsusega.
- Ilma uuesti indekseerimiseta muutub indeks aeglaseks; Muudetavate dokumentide korrapärane ümbertöötlemine.
Rakenduse ülesanne
Joonistage oma meeskonnale assistendi arhitektuurne skeem. (1) Tehke kindlaks vähemalt kolm tegelikku andmeallikat ja kirjutage iga jaoks üles konnektori vajadus, värskendamise sagedus ja usaldustase. (2) Joonistage kast-nool diagrammiga eraldi indekseerimis- ja päringuread. (3) "Kus ma saan selle assistendi latentsusaega ja kulusid vähendada?" Kirjutage küsimusele vähemalt kaks konkreetset otsust. (4) Kirjeldage oma värskendusstrateegiat ühe lausega: millist ressurssi ja kui sageli uuesti indekseeritakse?
kontrollnimekiri
- [ ] Oskan joonistada indekseerimis- ja päringuridasid eraldi ja õigete komponentidega.
- [ ] Saan kombineerida mitmest allikast pärinevaid andmeid lähtetüübi ja usalduse prioriteediga.
- [ ] Saan teha voogesituse/vahemälu otsuseid latentsusaja ja mudelivaliku hinna osas.
- [ ] Ma tean, miks uuesti indekseerimise strateegia on hädavajalik.
- [ ] Pean meeles, et minu arhitektuuri kõige kallim samm on tavaliselt suuremale mudelile minev token.