Mga nadagdag:
- Pagdidisenyo ng mga bahagi at daloy ng data ng isang end-to-end na enterprise RAG assistant
- Pagsasama-sama ng maraming mapagkukunan ng data (wiki, tiket, PDF, database) sa isang solong katulong
- Gumawa ng mga desisyon sa arkitektura para sa scalability, caching at latency
Sa mga nakaraang unit, isa-isa naming natutunan ang mga bahagi: pag-embed, vector database, chunking, retrieval. Ngayon, pagsamahin natin ang mga ito at bumuo ng isang end-to-end na arkitektura ng isang katulong na nakikipag-usap sa iyong sariling data ng kumpanya. Ang layunin ay itanong sa isang empleyado, "Ano ang aming patakaran sa bakasyon?" Isang sistema kung saan maaaring magtanong ang mga tao, ang mga sagot ay batay sa mga tunay na panloob na dokumento, pagsipi at pagsamahin ang maramihang mga mapagkukunan ng data. Pinoproseso ng unit na ito ang buong arkitektura, daloy ng data at mga desisyon sa antas ng produksyon.
End-to-End na Mga Bahagi
Ang isang corporate RAG assistant ay binubuo ng dalawang magkahiwalay na linya. Inihahanda ng linya ng pag-index (offline) ang data; Ang linya ng query (online) ay sumasagot sa tanong.
Mga bahagi ng linya ng pag-index:
- Mga Konektor: Mga konektor na kumukuha ng data mula sa mga mapagkukunan — wiki, ticket system, file store, database, email.
- Normalization: Pag-convert ng iba't ibang mga format (PDF, HTML, DOCX) upang linisin ang teksto; paglilinis ng header/footer.
- Chunking + metadata: Chunking at pag-tag (pinagmulan, petsa, awtoridad).
- Pag-embed + paglo-load: Pagsusulat ng mga vector at metadata sa database ng vector.
Mga bahagi ng pipeline ng query:
- Preprocessing ng query: Muling pagsusulat, desentralisasyon.
- Pagbawi: Hybrid na paghahanap + metadata filter + muling pagraranggo.
- Mabilis na paggawa: Paglalagay ng konteksto + tanong + mga tagubilin sa template.
- Generation: Grounded (contextual) na sagot mula sa modelo + source.
- Post-processing: Citation formatting, security check, logging.
Tip: Pisikal na paghiwalayin ang linya ng pag-index mula sa linya ng query. Ang pag-index ay mabagal at panaka-nakang (tumatakbo sa mga batch sa magdamag); Ang linya ng pagtatanong ay dapat na magaan at agaran. Ang paghahalo ng dalawang linya ay pinipilit ang mabigat na pagproseso habang naghihintay ang user.
Pagsasalarawan sa Daloy ng Data
[INDEXING - offline]Resources → Normalize → Chunk+Metadata → I-embed → Vector DB (wiki, ticket, PDF, DB)[QUERY - online]User question → Pre-processing → Retrieval (hybrid+filter+rerank) → Prompt (context+question+instruction)+→Sour Model → User
Pinagsasama-sama ang Multi-Source Data
Sa mga totoong kumpanya, ang sagot ay hindi humihinto sa isang lugar. "Paano mag-isyu ng refund sa isang customer?" Ang sagot sa tanong ay makikita pareho sa artikulo ng tulong (pamamaraan), sa kasaysayan ng tiket (mga tunay na halimbawa), at sa patakarang PDF (mga panuntunan). Dapat hanapin ng katulong ang lahat sa isang pool.
Kritikal na punto: kapag pinagsasama-sama ang mga mapagkukunan sa iisang vector store, dapat na taglay ng bawat shard ang metadata ng `source_tour`. Kaya maaari mong hanapin ang lahat ng ito at i-filter ang mga ito kung kinakailangan, tulad ng "dalhin lamang ang mga opisyal na patakaran." Gayundin, ang iba't ibang mapagkukunan ay may iba't ibang antas ng pagiging maaasahan: opisyal na patakaran > artikulo ng tulong > tala ng tiket ng empleyado. Maaari mong tukuyin ang priyoridad na ito sa muling pagraranggo o prompt.
Pinagmulan
Uri ng nilalaman
magtiwala
Dalas ng pag-update
PDF ng patakaran
opisyal na tuntunin
mataas
buwanan
Artikulo ng tulong
Pamamaraan
katamtaman-mataas
lingguhan
Kasaysayan ng tiket
tunay na sample
daluyan
tuloy-tuloy
wiki
Mixed/kasalukuyang tala
Variable
tuloy-tuloy
Scalability, Cache at Latency
Tatlong isyu ang namumukod-tangi sa produksyon. Latency: Lumalala ang karanasan kapag naghintay ang user nang higit sa 2 segundo. Solusyon: ipakita ang sagot sa streaming form — ibinubuhos ito sa screen habang nagsusulat ang modelo. Cache: Para sa mga madalas itanong at paulit-ulit na konteksto, parehong pinapataas ng cache ang bilis at binabawasan ang gastos. Scale: Habang dumarami ang user, kinakailangan na ma-scale ang retrieval at modelo ng mga tawag nang pahalang.
Rule of thumb on the cost side: ang pinakamahal na hakbang ay karaniwang ang bilang ng mga token na pupunta sa mas malaking modelo. Samakatuwid, ang pagbabawas ng konteksto sa 4 na magagandang bahagi sa pamamagitan ng muling pagraranggo ay nagpapabuti sa kalidad at gastos. Ang isang karaniwang disenyo ay ang paggamit ng isang mas maliit/mas mabilis na modelo para sa simpleng pag-uuri o pagruruta, at isang mas makapangyarihang modelo para sa huling sagot (hal. claude-opus-4-8).
Babala: Huwag i-set up ang pag-index bilang "gawin ito minsan, kalimutan ito". Ang mga dokumento ay binago, tinanggal, idinagdag. Magtatag ng diskarte sa muling pag-index: tuklasin ang mga nabagong dokumento at muling iproseso ang mga ito. Ang stale index ay gumagawa ng isang sagot na lumilitaw na kasalukuyan ngunit mali.
Mahinang Arkitektura / Malakas na Arkitektura
Mahina (iisang script, halo-halong lahat):
Kapag nagtanong ang gumagamit: basahin ang mga dokumento sa sandaling iyon, gupitin ang mga ito, i-embed ang mga ito, hanapin ang mga ito, sagutin ang mga ito.# Problema: paulit-ulit ang lahat ng pag-index para sa bawat tanong; segundo ng pagkaantala, # walang pinaghiwalay na pinagmulan, walang filter, walang pag-refresh.
Napakahusay (mga split pipe + metadata + cache + streaming):
Pag-index: tumatakbo ang batch sa gabi, nire-refresh ang mga binagong dokumento. Query: lightweight na linya — pre-processing → hybrid retrieval+filter → rerank → prompt → model (streaming) → citation → log. Ang mga madalas itanong at pinagmulan ay naka-cache.
Tatlong Mini Case
Case 1 — Nalilitong linya, matinding pagkaantala. Ang isang startup ay nagsulat ng isang script na muling nagpoproseso ng mga PDF sa bawat tanong; Ang bawat sagot ay tumagal ng average na 11 segundo. Kapag ang linya ng pag-index ay pinaghiwalay at ang data ay nailipat dati sa vector store, ang oras ng query ay bumaba sa 1.3 segundo at sa streaming, ang "unang salita" ay lumabas sa 400 ms.
Kaso 2 — Masyadong maraming mapagkukunan, maling priyoridad. Ang isang support assistant ay nagbigay ng pantay na timbang sa patakarang PDF at mga lumang tala ng tiket; Minsan ipinakita ng modelo ang maling rating ng isang empleyado mula noong nakaraang dalawang taon bilang opisyal na panuntunan. Kapag ang source_tour metadata at ang pagtuturo na "isaalang-alang ang opisyal na patakaran kung sakaling magkasalungat" ay idinagdag sa prompt, ang mga mali sa priyoridad na error ay nabawasan ng 89%.
Case 3 — Stale index. Ang isang HR assistant ay nagtatrabaho sa isang index na hindi na-update sa loob ng 3 buwan; Nagbago ang patakaran sa pag-iwan, ngunit sinasabi ng katulong ang mga lumang araw. Kapag na-install ang pang-araw-araw na pag-refresh, na nakakakita ng mga nabagong file, ang rate ng kasalukuyang tugon ay tumaas mula 70% hanggang 99%.
Mga karaniwang pagkakamali
- Paghahalo ng mga linya ng pag-index at query: Ang mabigat na pagproseso ay ginagawa habang naghihintay ang user; ang pagkaantala ay sumasabog.
- Hindi paglalagay ng uri ng pinagmulan sa metadata: Walang priyoridad at pag-filter; Mukhang opisyal ang hindi pinagkakatiwalaang source.
- Hindi nagtatatag ng diskarte sa pag-refresh: Nagiging lipas na ang index; Ang mga maling sagot na lumilitaw na kasalukuyan ay ginawa.
- Laktawan ang streaming: Tumitingin ang user sa isang blangkong screen; Ang pinaghihinalaang pagkaantala ay nagiging mataas.
- Gamit ang pinakamalaking modelo sa bawat hakbang: Tumataas ang gastos nang hindi kinakailangan; Iwanan ang pagpipiloto sa mas maliit na modelo.
Sa buod
- Ang corporate RAG assistant ay binubuo ng dalawang magkahiwalay na linya: offline na pag-index at online na query; paghiwalayin sila sa pisikal.
- Pag-index = connector + normalize + chunk/metadata + embed/upload; query = pre-process + retrieval + prompt + generate + post-process.
- Pinagsasama-sama ang maraming pinagmumulan ng data sa iisang repositoryo, ngunit pinapanatili ang source_type metadata at priyoridad ng tiwala.
- Ang streaming at cache para sa latency, context throttling at pagpili ng modelo para sa gastos ay kritikal.
- Nang walang muling pag-index, ang index ay nagiging lipas; Regular na iproseso ang pagpapalit ng mga dokumento.
Gawain ng aplikasyon
Gumuhit ng architectural diagram ng isang assistant para sa sarili mong team. (1) Tukuyin ang hindi bababa sa tatlong tunay na pinagmumulan ng data at isulat ang pangangailangan ng connector, dalas ng pag-update, at antas ng tiwala para sa bawat isa. (2) Iguhit ang mga linya ng pag-index at query nang hiwalay gamit ang isang box-arrow diagram. (3) "Saan ko babawasan ang latency at gastos sa assistant na ito?" Sumulat ng hindi bababa sa dalawang konkretong desisyon sa tanong. (4) Ilarawan ang iyong diskarte sa pag-refresh sa isang pangungusap: aling mapagkukunan ang muling i-reindex at gaano kadalas?
checklist
- [ ] Maaari kong iguhit ang mga linya ng pag-index at query nang hiwalay at gamit ang mga tamang bahagi.
- [ ] Maaari kong pagsamahin ang multi-source na data sa source_type at trust priority.
- [ ] Maaari akong gumawa ng mga desisyon sa streaming/cache para sa latency at pagpili ng modelo para sa gastos.
- [ ] Alam ko kung bakit mahalaga ang isang diskarte sa muling pag-index.
- [ ] Naaalala ko na ang pinakamahal na hakbang sa aking arkitektura ay karaniwang ang token na napupunta sa mas malaking modelo.