Ieguvumi:
- Pilnīga uzņēmuma RAG palīga komponentu un datu plūsmas projektēšana
- Vairāku avotu datu (wiki, biļetes, PDF, datu bāzes) apvienošana vienā palīgā
- Pieņemiet arhitektūras lēmumus par mērogojamību, kešatmiņu un latentumu
Iepriekšējās vienībās mēs mācījāmies daļas pa vienai: iegulšana, vektoru datu bāze, sadalīšana, izguve. Tagad apvienosim tos un izveidosim visaptverošu palīga arhitektūru, kas runā ar jūsu uzņēmuma datiem. Mērķis ir likt darbiniekam jautāt: "Kāda ir mūsu atvaļinājuma politika?" Sistēma, kurā cilvēki var uzdot jautājumus, atbildes ir balstītas uz reāliem iekšējiem dokumentiem, citātiem un apvieno vairākus datu avotus. Šī vienība apstrādā visu arhitektūru, datu plūsmu un ražošanas līmeņa lēmumus.
Pilnīgi komponenti
Korporatīvais RAG palīgs sastāv no divām atsevišķām līnijām. Indeksēšanas līnija (bezsaistē) sagatavo datus; Vaicājuma rinda (tiešsaistē) atbild uz jautājumu.
Indeksēšanas līnijas komponenti:
- Savienotāji: savienotāji, kas iegūst datus no avotiem — wiki, biļešu sistēmas, failu krātuves, datu bāzes, e-pasta.
- Normalizācija: dažādu formātu (PDF, HTML, DOCX) konvertēšana uz tīru tekstu; galvenes/kājenes tīrīšana.
- Sadalīšana + metadati: sadalīšana un marķēšana (avots, datums, autoritāte).
- Iegulšana + ielāde: vektoru un metadatu ierakstīšana vektoru datu bāzē.
Vaicājumu konveijera komponenti:
- Vaicājuma priekšapstrāde: pārrakstīšana, decentralizācija.
- Izguve: hibrīda meklēšana + metadatu filtrs + atkārtota ranžēšana.
- Uzvednes izveide: konteksta + jautājuma + norādījumu ievietošana veidnē.
- Paaudze: pamatota (kontekstuāla) atbilde no modeļa + avotiem.
- Pēcapstrāde: citātu formatēšana, drošības pārbaude, reģistrēšana.
Padoms.: Fiziski atdaliet indeksēšanas rindiņu no vaicājuma rindas. Indeksēšana ir lēna un periodiska (tiek veikta partijās visu nakti); Izmeklēšanas līnijai jābūt vieglai un tūlītējai. Abu rindu sajaukšana piespiež intensīvu apstrādi, kamēr lietotājs gaida.
Datu plūsmas vizualizācija
[INDEKSĒŠANA — bezsaistē]Resursi → Normalizēt → Daļa+Metadati → Iegult → Vector DB (wiki, biļete, PDF, DB)[QUERY — tiešsaistē]Lietotāja jautājums → Iepriekšēja apstrāde → Izguve (hibrīds+filtrs+pārvērtēšana) → Uzvedne (konteksts+jautājums+instrukcija) → Modelis → Atbilde+Avots →
Vairāku avotu datu apvienošana
Reālos uzņēmumos atbilde neapstājas vienā vietā. "Kā izsniegt klientam atmaksu?" Atbildi uz jautājumu var atrast gan palīdzības rakstā (procedūrā), gan biļešu vēsturē (reāli piemēri), gan politikas PDF (noteikumos). Asistentam tie visi ir jāmeklē vienā baseinā.
Kritiskais punkts: apvienojot resursus vienā vektoru krātuvē, katrā fragmentā ir jābūt “source_tour” metadatiem. Tātad jūs varat meklēt tos visus un vajadzības gadījumā tos filtrēt, piemēram, "iesniedziet tikai oficiālas politikas". Turklāt dažādiem avotiem ir atšķirīgs uzticamības līmenis: oficiālā politika > palīdzības raksts > darbinieka biļetes piezīme. Varat norādīt šo prioritāti pārkārtošanā vai uzvednē.
Avots
Satura veids
uzticēties
Atjaunināšanas biežums
Politikas PDF
oficiālais noteikums
augsts
katru mēnesi
Palīdzības raksts
Procedūra
vidēji augsts
katru nedēļu
Biļešu vēsture
īsts paraugs
vidējs
Nepārtraukta
wiki
Jaukta/pašreizējā nots
Mainīgs
Nepārtraukta
Mērogojamība, kešatmiņa un latentums
Ražošanā izceļas trīs problēmas. Latentums: pieredze pasliktinās, ja lietotājs gaida vairāk nekā 2 sekundes. Risinājums: parādiet atbildi straumēšanas formā — tā tiek izlieta uz ekrāna, kamēr modelis raksta. Kešatmiņa: bieži uzdotajiem jautājumiem un atkārtotajiem kontekstiem kešatmiņa palielina ātrumu un samazina izmaksas. Mērogs: lietotājam palielinoties, ir jāspēj mērogot izguves un modelēt zvanus horizontāli.
Īkšķis izmaksu pusē: visdārgākais solis parasti ir tokenu skaits, kas tiek novirzīti lielākajam modelim. Tāpēc konteksta samazināšana līdz 4 labām daļām, veicot pārkārtošanu, uzlabo gan kvalitāti, gan izmaksas. Parasti tiek izmantots mazāks/ātrāks modelis vienkāršai klasifikācijai vai maršrutēšanai un jaudīgāks modelis galīgajai atbildei (piemēram, claude-opus-4-8).
Uzmanību! Neiestatiet indeksēšanu kā “dari to vienreiz, aizmirsti”. Dokumenti tiek mainīti, dzēsti, pievienoti. Izveidojiet atkārtotas indeksēšanas stratēģiju: atrodiet mainītos dokumentus un atkārtoti apstrādājiet tikai tos. Novecojušais indekss rada atbildi, kas šķiet aktuāla, bet ir nepareiza.
Vāja arhitektūra / spēcīga arhitektūra
Vāji (viens skripts, viss sajaukts):
Kad lietotājs jautā: tajā brīdī izlasi dokumentus, sasmalcina, iegulst, meklē, atbildi uz tiem.# Problēma: visa indeksēšana tiek atkārtota katram jautājumam; sekundes aizkave, # bez avotu atdalīšanas, bez filtra, bez atsvaidzināšanas.
Jaudīgs (sadalītas caurules + metadati + kešatmiņa + straumēšana):
Indeksēšana: partija darbojas naktī, atsvaidzina mainītos dokumentus. Vaicājums: viegla līnija — pirmapstrāde → hibrīda izguve+filtrs → pārkārtošana → uzvedne → modelis (straumēšana) → citēšana → žurnāls. Bieži uzdotie jautājumi un avots tiek saglabāti kešatmiņā.
Trīs mini futrāļi
1. gadījums — neskaidra līnija, liela kavēšanās. Starta programma uzrakstīja skriptu, kas atkārtoti apstrādā PDF failus ar katru jautājumu; Katra atbilde prasīja vidēji 11 sekundes. Kad indeksēšanas līnija tika atdalīta un dati iepriekš tika pārsūtīti uz vektoru krātuvi, vaicājuma laiks samazinājās līdz 1,3 sekundēm un ar straumēšanu "pirmais vārds" parādījās 400 ms.
2. gadījums — pārāk daudz resursu, nepareiza prioritāte. Atbalsta palīgs piešķīra vienādu nozīmi politikas PDF dokumentam un vecajām biļešu piezīmēm; Modelis dažkārt kā oficiālu noteikumu uzrādīja nepareizu darbinieka vērtējumu pirms diviem gadiem. Kad uzvednei tika pievienoti avota_ceļa metadati un norādījums “konfliktu gadījumā apsvērt oficiālo politiku”, kļūdainas prioritātes kļūdas tika samazinātas par 89%.
3. gadījums — novecojušais rādītājs. HR palīgs strādāja ar indeksu, kas netika atjaunināts 3 mēnešus; Atvaļinājuma politika ir mainījusies, bet asistente runāja vecos laikos. Kad tika instalēta ikdienas atsvaidzināšana, kas nosaka mainītos failus, pašreizējās atbildes līmenis palielinājās no 70% līdz 99%.
Biežas kļūdas
- Indeksēšanas un vaicājuma rindu sajaukšana: intensīva apstrāde tiek veikta, kamēr lietotājs gaida; kavēšanās eksplodē.
- Neievietot avota veidu metadatos: nav prioritāšu noteikšanas un filtrēšanas; Šķiet, ka neuzticamais avots ir oficiāls.
- Netiek izveidota atsvaidzināšanas stratēģija: indekss kļūst novecojis; Tiek radītas nepareizas atbildes, kas šķiet aktuālas.
- Izlaist straumēšanu: lietotājs skatās uz tukšu ekrānu; Uztvertā kavēšanās kļūst liela.
- Vislielākā modeļa izmantošana katrā solī: izmaksas palielinās nevajadzīgi; Atstājiet stūrēšanu mazākam modelim.
Rezumējot
- Uzņēmuma RAG palīgs sastāv no divām atsevišķām rindām: bezsaistes indeksēšanas un tiešsaistes vaicājuma; atdaliet tos fiziski.
- Indeksēšana = savienotājs + normalizēšana + gabals/metadati + iegulšana/augšupielāde; vaicājums = pirmsapstrāde + izguve + uzvedne + ģenerēšana + pēcapstrāde.
- Vairāku avotu dati tiek apvienoti vienā repozitorijā, taču tiek saglabāti avota tipa metadati un uzticamības prioritāte.
- Straumēšana un kešatmiņa latentumam, konteksta ierobežošana un modeļa izvēle izmaksām ir ļoti svarīga.
- Bez atkārtotas indeksācijas indekss kļūst novecojis; Regulāri apstrādājiet mainītos dokumentus.
Lietojumprogrammas uzdevums
Uzzīmējiet savas komandas asistenta arhitektūras shēmu. (1) Identificējiet vismaz trīs reālus datu avotus un katram pierakstiet savienotāja nepieciešamību, atjaunināšanas biežumu un uzticamības līmeni. (2) Uzzīmējiet indeksēšanas un vaicājuma līnijas atsevišķi, izmantojot lodziņa bultiņas diagrammu. (3) “Kur samazināt latentumu un izmaksas šajā palīgā?” Uz jautājumu uzrakstiet vismaz divus konkrētus lēmumus. (4) Aprakstiet savu atsvaidzināšanas stratēģiju vienā teikumā: kurš resurss tiks atkārtoti indeksēts un cik bieži?
kontrolsaraksts
- [ ] Es varu zīmēt indeksēšanas un vaicājuma līnijas atsevišķi un ar pareizajiem komponentiem.
- [ ] Es varu apvienot vairāku avotu datus ar avota_tipa un uzticības prioritāti.
- [ ] Varu pieņemt lēmumus par straumēšanu/kešatmiņu attiecībā uz latentumu un modeļa izvēli attiecībā uz izmaksām.
- [ ] Es zinu, kāpēc atkārtotas indeksācijas stratēģija ir būtiska.
- [ ] Es paturu prātā, ka manā arhitektūrā visdārgākais solis parasti ir marķieris, kas tiek izmantots lielākajam modelim.