Dobici:
- Dizajniranje komponenti i protoka podataka end-to-end poslovnog RAG asistenta
- Kombiniranje podataka iz više izvora (wiki, ulaznica, PDF, baza podataka) u jednog pomoćnika
- Donesite arhitektonske odluke za skalabilnost, predmemoriju i kašnjenje
U prethodnim jedinicama učili smo dijelove jedan po jedan: ugrađivanje, vektorska baza podataka, chunking, retrieval. Sada kombinirajmo ovo i izgradimo end-to-end arhitekturu pomoćnika koji razgovara s podacima vaše tvrtke. Cilj je navesti zaposlenika da pita: "Kakva je naša politika dopusta?" Sustav u kojem ljudi mogu postavljati pitanja, odgovori se temelje na stvarnim internim dokumentima, citatima i kombiniraju više izvora podataka. Ova jedinica obrađuje cjelokupnu arhitekturu, protok podataka i odluke na razini proizvodnje.
Komponente od kraja do kraja
Korporativni RAG pomoćnik sastoji se od dvije odvojene linije. Linija za indeksiranje (offline) priprema podatke; Linija upita (online) odgovara na pitanje.
Komponente retka za indeksiranje:
- Konektori: konektori koji povlače podatke iz izvora — wiki, sustav ulaznica, pohrana datoteka, baza podataka, e-pošta.
- Normalizacija: Pretvaranje različitih formata (PDF, HTML, DOCX) u čisti tekst; čišćenje zaglavlja/podnožja.
- Chunking + metapodaci: Chunking i označavanje (izvor, datum, ovlaštenje).
- Ugrađivanje + učitavanje: Zapisivanje vektora i metapodataka u vektorsku bazu podataka.
Komponente cjevovoda upita:
- Predprocesiranje upita: Prepisivanje, decentralizacija.
- Dohvaćanje: Hibridno pretraživanje + filter metapodataka + ponovno rangiranje.
- Stvaranje upita: postavljanje konteksta + pitanja + uputa u predložak.
- Generacija: Utemeljeni (kontekstualni) odgovor iz modela + izvora.
- Naknadna obrada: Oblikovanje citata, sigurnosna provjera, bilježenje.
Savjet: fizički odvojite redak indeksiranja od retka upita. Indeksiranje je sporo i periodično (radi se u serijama preko noći); Linija ispitivanja trebala bi biti lagana i neposredna. Miješanje dviju linija zahtijeva intenzivnu obradu dok korisnik čeka.
Vizualizacija protoka podataka
[INDEXING - offline]Resursi → Normaliziraj → Chunk+Metapodaci → Embed → Vector DB (wiki, ulaznica, PDF, DB)[QUERY - online]Korisničko pitanje → Predobrada → Dohvaćanje (hibrid+filtar+prerangiranje) → Upit (kontekst+pitanje+uputa) → Model → Odgovor+Izvor → Korisnik
Kombiniranje podataka iz više izvora
U pravim tvrtkama odgovor ne staje na jednom mjestu. "Kako izvršiti povrat kupcu?" Odgovor na pitanje možete pronaći u članku za pomoć (procedura), u povijesti tiketa (stvarni primjeri) iu PDF-u pravila (pravila). Pomoćnik bi ih sve trebao pretražiti u jednom bazenu.
Kritična točka: kada se resursi kombiniraju u jednu vektorsku pohranu, svaki shard mora sadržavati metapodatke `source_tour`. Dakle, možete ih sve pretraživati i filtrirati ako je potrebno, npr. "donesite samo službene police". Također, različiti izvori imaju različite razine pouzdanosti: službena pravila > članak za pomoć > bilješka zaposlenika. Ovaj prioritet možete navesti u ponovnom rangiranju ili upitu.
Izvor
Vrsta sadržaja
povjerenje
Učestalost ažuriranja
Politika PDF
službeno pravilo
visoka
mjesečno
Pomoćni članak
Postupak
srednje-visoka
tjedno
Povijest ulaznica
pravi uzorak
srednji
Kontinuirano
wiki
Mješovita/trenutna nota
Varijabilna
Kontinuirano
Skalabilnost, predmemorija i latencija
U proizvodnji se ističu tri problema. Latencija: iskustvo se pogoršava kada korisnik čeka više od 2 sekunde. Rješenje: prikaži odgovor u strujanom obliku — on se izlijeva na ekran dok model piše. Predmemorija: Za često postavljana pitanja i kontekste koji se ponavljaju predmemorija povećava brzinu i smanjuje troškove. Mjerilo: Kako se korisnik povećava, potrebno je moći vodoravno skalirati dohvaćanje i modelirati pozive.
Pravilo o trošku: najskuplji korak je obično broj tokena koji ide većem modelu. Stoga reduciranje konteksta na 4 dobra dijela ponovnim rangiranjem poboljšava kvalitetu 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: nemojte postavljati indeksiranje kao "učini jednom, zaboravi". Dokumenti se mijenjaju, brišu, dodaju. Uspostavite strategiju ponovnog indeksiranja: otkrijte promijenjene dokumente i ponovno obradite samo njih. Zastarjeli indeks daje odgovor koji se čini trenutnim, ali je pogrešan.
Slaba arhitektura / Jaka arhitektura
Slab (jedna skripta, sve pomiješano):
Kada korisnik pita: pročitajte dokumente u tom trenutku, uništite ih, ugradite ih, pretražite ih, odgovorite na njih. # Problem: svo indeksiranje se ponavlja za svako pitanje; sekunde odgode, # nema odvajanja izvora, nema filtera, nema osvježavanja.
Snažan (split pipes + metapodaci + cache + streaming):
Indeksiranje: skupni rad noću, osvježavanje promijenjenih dokumenata. Upit: lagana linija — prethodna obrada → hibridno dohvaćanje+filtar → ponovno rangiranje → upit → model (streaming) → citat → zapisnik. Često postavljana pitanja i izvor su predmemorirani.
Tri mini kućišta
Slučaj 1 — Zbunjena linija, veliko kašnjenje. Startup je napisao skriptu koja ponovno obrađuje PDF-ove sa svakim pitanjem; Svaki odgovor je u prosjeku trajao 11 sekundi. Kada je linija za indeksiranje odvojena i podaci prethodno prebačeni u vektorsku pohranu, vrijeme upita se smanjilo na 1,3 sekunde, a uz strujanje se "prva riječ" 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 police i starim bilješkama; Model je ponekad kao službeno pravilo prikazivao netočnu ocjenu zaposlenika od prije dvije godine. Kada su metapodaci source_tour i uputa "razmotri službenu politiku u slučaju sukoba" dodani upitu, pogreške lažnog prioriteta smanjene su za 89%.
Slučaj 3 — Zastarjeli indeks. Pomoćnik za ljudske resurse radio je s indeksom koji nije ažuriran 3 mjeseca; Politika dopusta se promijenila, ali asistent je govorio stare dane. Kada je instalirano dnevno osvježavanje, koje detektira promijenjene datoteke, trenutna stopa odgovora porasla je sa 70% na 99%.
Uobičajene greške
- Miješanje indeksiranja i redaka upita: teška obrada se obavlja dok korisnik čeka; kašnjenje eksplodira.
- Nestavljanje vrste izvora u metapodatke: Nema prioriteta i filtriranja; Čini se da je nepouzdani izvor službeni.
- Ne uspostavljanje strategije osvježavanja: Indeks postaje ustajao; Proizvode se pogrešni odgovori koji se čine aktualnima.
- Preskoči strujanje: Korisnik gleda u prazan ekran; Percipirano kašnjenje postaje veliko.
- Korištenje najvećeg modela u svakom koraku: Trošak se nepotrebno povećava; Prepustite upravljanje manjem modelu.
Ukratko
- Korporativni RAG pomoćnik sastoji se od dvije odvojene linije: offline indeksiranje i online upit; odvojiti ih fizički.
- Indeksiranje = konektor + normalizacija + komad/metapodaci + ugradnja/upload; upit = pretproces + dohvaćanje + upit + generiranje + naknadni proces.
- Podaci iz više izvora kombiniraju se u jedno spremište, ali metapodaci source_type i prioritet povjerenja su sačuvani.
- Streaming i predmemorija za latenciju, prigušivanje konteksta i odabir modela za cijenu su ključni.
- Bez ponovnog indeksiranja, indeks postaje ustajao; Redovito obrađujte dokumente koji se mijenjaju.
Zadatak aplikacije
Nacrtajte arhitektonski dijagram pomoćnika za svoj tim. (1) Identificirajte najmanje tri stvarna izvora podataka i zapišite potrebu konektora, učestalost ažuriranja i razinu povjerenja za svaki. (2) Odvojeno nacrtajte linije za indeksiranje i upite pomoću dijagrama sa strelicama. (3) "Gdje mogu smanjiti kašnjenje i troškove u ovom pomoćniku?" Na pitanje napišite barem dvije konkretne odluke. (4) Opišite svoju strategiju osvježavanja u jednoj rečenici: koji će se resurs ponovno indeksirati i koliko često?
popis za provjeru
- [ ] Mogu nacrtati indeksiranje i retke upita odvojeno i s ispravnim komponentama.
- [ ] Mogu kombinirati podatke iz više izvora s izvornom_vrstom i prioritetom povjerenja.
- [ ] Mogu donositi odluke o strujanju/predmemoriji za kašnjenje i odabir modela za cijenu.
- [ ] Znam zašto je ključna strategija ponovnog indeksiranja.
- [ ] Imam na umu da je najskuplji korak u mojoj arhitekturi obično token koji ide na veći model.