Dobici:
- Dizajniranje komponenti i protoka podataka RAG pomoćnika preduzeća od kraja do kraja
- Kombinovanje podataka iz više izvora (wiki, ulaznica, PDF, baza podataka) u jedan pomoćnik
- Donosite arhitektonske odluke za skalabilnost, keširanje i kašnjenje
U prethodnim nastavnim jedinicama učili smo dijelove jedan po jedan: ugrađivanje, vektorska baza podataka, chunking, pronalaženje. Hajde sada da ih kombinujemo i izgradimo end-to-end arhitekturu pomoćnika koji razgovara sa podacima vaše kompanije. Cilj je da zaposleni pita: „Koja je naša politika odsustva?“ Sistem u kojem ljudi mogu postavljati pitanja, odgovori su zasnovani na stvarnim internim dokumentima, citatima i kombinuju više izvora podataka. Ova jedinica obrađuje cjelokupnu arhitekturu, tok podataka i odluke na nivou proizvodnje.
End-to-End komponente
Korporativni RAG asistent se sastoji od dvije odvojene linije. Linija za indeksiranje (offline) priprema podatke; Linija upita (online) odgovara na pitanje.
Komponente linije indeksiranja:
- Konektori: Konektori koji povlače podatke iz izvora — wikija, sistema tiketa, skladišta datoteka, baze podataka, e-pošte.
- Normalizacija: Konvertovanje različitih formata (PDF, HTML, DOCX) u čist tekst; čišćenje zaglavlja/podnožja.
- Seckanje + metapodaci: Seckanje i označavanje (izvor, datum, autoritet).
- Ugrađivanje + učitavanje: Upisivanje vektora i metapodataka u vektorsku bazu podataka.
Komponente cjevovoda upita:
- Prethodna obrada upita: ponovno pisanje, decentralizacija.
- Dohvaćanje: Hibridna pretraga + filter metapodataka + ponovno rangiranje.
- Brzo kreiranje: Postavljanje konteksta + pitanja + instrukcija u šablon.
- Generacija: Utemeljeni (kontekstualni) odgovor iz modela + izvori.
- Naknadna obrada: Formatiranje citata, sigurnosna provjera, evidentiranje.
Savjet: Fizički odvojite liniju za indeksiranje od linije upita. Indeksiranje je sporo i periodično (radi u serijama preko noći); Linija istrage treba da bude lagana i neposredna. Miješanje dva reda dovodi do teške obrade dok korisnik čeka.
Vizualizacija toka podataka
[INDEKSIRANJE - van mreže]Resursi → Normaliziraj → Chunk+Metapodaci → Ugradi → Vektorski DB (wiki, ulaznica, PDF, DB)[QUERY - online]Korisničko pitanje → Prethodna obrada → Dohvaćanje (hibrid+filter+ponovno rangiranje) → Prompt (kontekst+pitanje+instrukcija) → Model → Odgovor+izvor
Kombinacija podataka iz više izvora
U stvarnim kompanijama, odgovor se ne zaustavlja na jednom mjestu. “Kako izdati povrat novca kupcu?” Odgovor na pitanje možete pronaći u članku pomoći (procedura), u povijesti tiketa (pravi primjeri) i u PDF-u politike (pravila). Asistent treba da ih sve pretraži u jednom bazenu.
Kritična tačka: kada se resursi kombinuju u jedno vektorsko skladište, svaki šard mora nositi metapodatke `source_tour`. Dakle, možete ih sve pretražiti i filtrirati ako je potrebno, kao što je "donesite samo službene politike". Takođe, različiti izvori imaju različite nivoe pouzdanosti: službena politika > članak pomoći > bilješka zaposlenog. Možete odrediti ovaj prioritet u ponovnom rangiranju ili promptu.
Izvor
Vrsta sadržaja
povjerenje
Učestalost ažuriranja
Policy PDF
zvanično pravilo
visoko
mjesečno
Članak pomoći
Procedura
srednje visok
sedmično
Istorija karata
pravi uzorak
srednje
Kontinuirano
wiki
Mješovita/trenutna nota
Varijabilna
Kontinuirano
Skalabilnost, keš memorija i kašnjenje
U proizvodnji se ističu tri problema. Latencija: iskustvo se pogoršava kada korisnik čeka više od 2 sekunde. Rješenje: prikažite odgovor u striming formi — sipa se na ekran dok model piše. Keširanje: Za često postavljana pitanja i kontekste koji se ponavljaju, keširanje povećava brzinu i smanjuje troškove. Skala: Kako se korisnik povećava, potrebno je biti u mogućnosti horizontalno skalirati preuzimanje i modelirati pozive.
Pravilo na strani troškova: najskuplji korak je obično broj tokena koji idu na veći model. Stoga, smanjenje konteksta na 4 dobra dijela ponovnim rangiranjem poboljšava i kvalitet i cijenu. Uobičajeni dizajn je korištenje manjeg/bržeg modela za jednostavnu klasifikaciju ili usmjeravanje, i moćnijeg modela za konačni odgovor (npr. claude-opus-4-8).
Oprez: Ne postavljajte indeksiranje kao "uradi jednom, zaboravi". Dokumenti se mijenjaju, brišu, dodaju. Uspostavite strategiju ponovnog indeksiranja: otkrijte promijenjene dokumente i ponovno obradite samo njih. Zastarjeli indeks proizvodi odgovor koji se čini aktuelnim, ali je pogrešan.
Slaba arhitektura / jaka arhitektura
Slabo (jedna skripta, sve pomiješano):
Kada korisnik pita: pročitajte dokumente u tom trenutku, usitnite ih, ugradite ih, pretražite ih, odgovorite na njih.# Problem: svo indeksiranje se ponavlja za svako pitanje; sekundi kašnjenja, # bez razdvajanja izvora, bez filtera, bez osvježavanja.
Moćan (podijeljene cijevi + metapodaci + keš memorija + streaming):
Indeksiranje: serija radi noću, osvježavanje promijenjenih dokumenata. Upit: lagana linija — prethodna obrada → hibridno preuzimanje+filter → ponovno rangiranje → upit → model (striming) → citat → dnevnik. Često postavljana pitanja i izvor su keširani.
Tri mini futrole
Slučaj 1 — Zbunjena linija, veliko kašnjenje. Startup je napisao skriptu koja ponovo obrađuje PDF-ove sa svakim pitanjem; Svaki odgovor je u prosjeku trajao 11 sekundi. Kada je indeksna linija odvojena i podaci su prethodno prebačeni u vektorsko skladište, vreme upita se smanjilo na 1,3 sekunde i sa strimingom, "prva reč" se pojavila za 400 ms.
Slučaj 2 — Previše resursa, pogrešan prioritet. Pomoćnik za podršku dao je jednaku težinu PDF-u o politici i starim bilješkama; Model je ponekad predstavljao pogrešnu ocjenu zaposlenog od prije dvije godine kao zvanično pravilo. Kada su metapodaci source_tour i instrukcija "razmotrite službenu politiku u slučaju sukoba" dodani u prompt, greške lažnog prioriteta su smanjene za 89%.
Slučaj 3 — Zastarjeli indeks. HR asistent je radio sa indeksom koji nije ažuriran 3 mjeseca; Politika odsustva se promijenila, ali asistent je govorio starim danima. Kada je instalirano dnevno osvježavanje, koje otkriva promijenjene datoteke, stopa trenutnog odgovora porasla je sa 70% na 99%.
Uobičajene greške
- Mešanje indeksiranja i linija upita: Teška obrada se obavlja dok korisnik čeka; kašnjenje eksplodira.
- Ne stavljajući izvorni tip u metapodatke: Nema prioriteta i filtriranja; Čini se da je nepouzdani izvor zvaničan.
- Neuspostavljanje strategije osvježavanja: Indeks postaje zastarjeli; Stvaraju se pogrešni odgovori koji izgledaju aktuelni.
- Preskoči striming: Korisnik gleda prazan ekran; Uočeno kašnjenje postaje veliko.
- Korišćenje najvećeg modela u svakom koraku: Troškovi se nepotrebno povećavaju; Ostavite upravljanje manjem modelu.
Ukratko
- Korporativni RAG pomoćnik se sastoji od dvije odvojene linije: vanmrežno indeksiranje i online upit; fizički ih razdvojiti.
- Indeksiranje = konektor + normalizacija + komad/metapodaci + ugradnja/prenos; upit = pre-proces + dohvaćanje + prompt + generiranje + naknadna obrada.
- Podaci iz više izvora su kombinovani u jedno spremište, ali su sačuvani metapodaci tipa_source i prioritet povjerenja.
- Streaming i keširanje za kašnjenje, ograničavanje konteksta i odabir modela za cijenu su kritični.
- Bez ponovnog indeksiranja, indeks postaje zastarjeli; Redovno obradite dokumente koji se mijenjaju.
Zadatak aplikacije
Nacrtajte arhitektonski dijagram asistenta za svoj tim. (1) Identifikujte najmanje tri stvarna izvora podataka i zapišite potrebu za konektorom, učestalost ažuriranja i nivo poverenja za svaki. (2) Nacrtajte linije za indeksiranje i upite odvojeno dijagramom okvir-strelica. (3) "Gdje da smanjim kašnjenje i troškove u ovom pomoćniku?" Napišite barem dvije konkretne odluke na pitanje. (4) Opišite svoju strategiju osvježavanja u jednoj rečenici: koji će resurs biti ponovo indeksiran i koliko često?
kontrolna lista
- [ ] Mogu nacrtati linije za indeksiranje i upite odvojeno i sa ispravnim komponentama.
- [ ] Mogu kombinirati podatke iz više izvora sa izvornim_tipom i prioritetom povjerenja.
- [ ] Mogu donositi odluke za striming/keširanje za kašnjenje i odabir modela za cijenu.
- [ ] Znam zašto je strategija ponovnog indeksiranja neophodna.
- [ ] Imam na umu da je najskuplji korak u mojoj arhitekturi obično token koji ide na veći model.