Câștiguri:
- Proiectarea componentelor și a fluxului de date al unui asistent RAG pentru întreprinderi end-to-end
- Combinarea datelor din mai multe surse (wiki, bilet, PDF, bază de date) într-un singur asistent
- Luați decizii arhitecturale pentru scalabilitate, cache și latență
În unitățile anterioare, am învățat părțile una câte una: încorporarea, baza de date vectorială, fragmentarea, recuperarea. Acum să le combinăm și să construim o arhitectură de la capăt la capăt a unui asistent care vorbește cu datele proprii ale companiei. Scopul este ca un angajat să întrebe „Care este politica noastră de concediu?” Un sistem în care oamenii pot pune întrebări, răspunsurile se bazează pe documente interne reale, citări și combină mai multe surse de date. Această unitate procesează întreaga arhitectură, fluxul de date și deciziile la nivel de producție.
Componente end-to-end
Un asistent RAG corporativ este format din două linii separate. Linia de indexare (offline) pregătește datele; Linia de interogare (online) răspunde la întrebare.
Componentele liniei de indexare:
- Conectori: conectori care extrag date din surse — wiki, sistem de bilete, depozit de fișiere, bază de date, e-mail.
- Normalizare: Conversia diferitelor formate (PDF, HTML, DOCX) în text curat; curățare antet/subsol.
- Chunking + metadate: Chunking și etichetare (sursă, dată, autoritate).
- Încorporare + încărcare: scrierea vectorilor și a metadatelor în baza de date vectorială.
Interogați componentele conductei:
- Preprocesarea interogărilor: rescriere, descentralizare.
- Preluare: căutare hibridă + filtru de metadate + re-clasificare.
- Creare promptă: plasarea context + întrebare + instrucțiuni în șablon.
- Generație: răspuns bazat (contextual) din model + surse.
- Post-procesare: formatarea citațiilor, verificarea securității, înregistrarea în jurnal.
Sfat: separați fizic linia de indexare de linia de interogare. Indexarea este lentă și periodică (se rulează în loturi peste noapte); Linia de anchetă ar trebui să fie ușoară și imediată. Amestecarea celor două linii forțează procesarea grea în timp ce utilizatorul așteaptă.
Vizualizarea fluxului de date
[INDEXARE - offline]Resurse → Normalizare → Bucătă+Metadate → Încorporare → Vector DB (wiki, bilet, PDF, DB)[QUERY - online]Întrebare utilizator → Preprocesare → Recuperare (hibrid+filtru+reclasare) → Prompt (context+întrebare+instrucțiune) → Model → Răspuns+Sursă → Utilizator
Combinarea datelor cu mai multe surse
În companiile reale, răspunsul nu se oprește într-un singur loc. „Cum se eliberează o rambursare unui client?” Răspunsul la întrebare poate fi găsit atât în articolul de ajutor (procedură), în istoricul biletelor (exemple reale), cât și în PDF-ul politicii (reguli). Asistentul ar trebui să le caute pe toate într-un singur bazin.
Punct critic: atunci când combinați resurse într-un singur magazin de vectori, fiecare fragment trebuie să conțină metadatele `source_tour`. Deci, le puteți căuta pe toate și le puteți filtra dacă este necesar, cum ar fi „aduceți doar politici oficiale”. De asemenea, diferite surse au niveluri diferite de fiabilitate: politică oficială > articol de ajutor > nota de bilet a unui angajat. Puteți specifica această prioritate în re-clasificare sau prompt.
Sursa
Tip de conținut
încredere
Frecvența actualizării
Politica PDF
regula oficială
înalt
lunar
articol de ajutor
Procedura
mediu-înalt
săptămânal
Istoricul biletelor
probă reală
mediu
Continuă
wiki
Notă mixtă/actuală
Variabilă
Continuă
Scalabilitate, cache și latență
Trei probleme ies în evidență în producție. Latență: experiența se deteriorează atunci când utilizatorul așteaptă mai mult de 2 secunde. Soluție: afișați răspunsul sub formă de streaming - acesta este turnat pe ecran pe măsură ce modelul scrie. Cache: pentru întrebările frecvente și contexte repetitive, memoria cache mărește viteza și reduce costurile. Scalare: Pe măsură ce utilizatorul crește, este necesar să se poată scala recuperarea și modelarea apelurilor pe orizontală.
Regula generală în ceea ce privește costul: cel mai scump pas este de obicei numărul de jetoane care merg la modelul mai mare. Prin urmare, reducerea contextului la 4 părți bune prin re-clasificare îmbunătățește atât calitatea, cât și costul. Un design comun este utilizarea unui model mai mic/mai rapid pentru clasificarea simplă sau rutare și un model mai puternic pentru răspunsul final (de exemplu, claude-opus-4-8).
Atenție: nu configurați indexarea ca „fă-o o dată, uită-l”. Documentele sunt modificate, șterse, adăugate. Stabiliți o strategie de re-indexare: detectați documentele modificate și reprocesați-le numai. Indicele învechit produce un răspuns care pare actual, dar este greșit.
Arhitectură slabă / Arhitectură puternică
Slab (script unic, totul amestecat):
Când utilizatorul întreabă: citiți documentele în acel moment, zdrobiți-le, încorporați-le, căutați-le, răspundeți la ele.# Problemă: toată indexarea se repetă pentru fiecare întrebare; secunde de întârziere, # fără separare sursă, fără filtru, fără reîmprospătare.
Puternic (conducte divizate + metadate + cache + streaming):
Indexare: se rulează în loturi noaptea, reîmprospătând documentele modificate. Interogare: linie ușoară — preprocesare → preluare hibridă+filtru → reclasificare → prompt → model (streaming) → citare → jurnal. Întrebările frecvente și sursa sunt stocate în cache.
Trei mini carcase
Cazul 1 — Linie confuză, întârziere mare. Un startup a scris un script care reprocesează PDF-urile cu fiecare întrebare; Fiecare răspuns a durat în medie 11 secunde. Când linia de indexare a fost separată și datele au fost transferate în prealabil în magazinul de vectori, timpul de interogare a scăzut la 1,3 secunde și la streaming, „primul cuvânt” a apărut în 400 ms.
Cazul 2 — Prea multe resurse, prioritate greșită. Un asistent de asistență a acordat egală importanță PDF-ului politicii și notelor vechi de bilet; Modelul a prezentat uneori ratingul incorect al unui angajat de acum doi ani ca regulă oficială. Când au fost adăugate metadatele source_tour și instrucțiunea „Luați în considerare politica oficială în caz de conflict” la prompter, erorile cu prioritate falsă au fost reduse cu 89%.
Cazul 3 — Indexul învechit. Un asistent de resurse umane lucra cu un index care nu a fost actualizat timp de 3 luni; Politica de concediu s-a schimbat, dar asistenta spunea pe vremuri. Când a fost instalată reîmprospătarea zilnică, care detectează fișierele modificate, rata de răspuns curent a crescut de la 70% la 99%.
Greșeli comune
- Mixarea liniilor de indexare și interogare: procesarea grea se face în timp ce utilizatorul așteaptă; întârzierea explodează.
- Nu introducerea tipului sursei în metadate: Fără prioritizare și filtrare; Sursa nesigură pare să fie oficială.
- Nestabilirea unei strategii de reîmprospătare: indicele devine învechit; Se produc răspunsuri greșite care par actuale.
- Omite streaming: utilizatorul se uită la un ecran gol; Întârzierea percepută devine mare.
- Utilizarea celui mai mare model la fiecare pas: Costul crește inutil; Lăsați direcția modelului mai mic.
Pe scurt
- Asistentul RAG corporativ este format din două linii separate: indexare offline și interogare online; separa-le fizic.
- Indexare = conector + normalizare + bucată/metadate + încorporare/încărcare; interogare = pre-proces + extragere + prompt + generare + post-proces.
- Datele din mai multe surse sunt combinate într-un singur depozit, dar metadatele source_type și prioritatea de încredere sunt păstrate.
- Streamingul și memoria cache pentru latență, limitarea contextului și selectarea modelului pentru cost sunt critice.
- Fără re-indexare, indicele devine învechit; Reprocesează periodic documentele care se schimbă.
Sarcina de aplicare
Desenați o diagramă arhitecturală a unui asistent pentru propria echipă. (1) Identificați cel puțin trei surse de date reale și notați nevoia de conector, frecvența de actualizare și nivelul de încredere pentru fiecare. (2) Desenați separat liniile de indexare și de interogare cu o diagramă cu săgeți. (3) „Unde reduc latența și costul în acest asistent?” Scrie cel puțin două decizii concrete la întrebare. (4) Descrieți strategia dvs. de reîmprospătare într-o singură propoziție: ce resursă va fi reindexată și cât de des?
lista de verificare
- [ ] Pot desena liniile de indexare și de interogare separat și cu componentele corecte.
- [ ] Pot combina date multi-surse cu source_type și prioritatea de încredere.
- [ ] Pot lua decizii de streaming/cache pentru latență și pot selecta modelul pentru cost.
- [ ] Știu de ce este esențială o strategie de reindexare.
- [ ] Țin minte că cel mai scump pas din arhitectura mea este de obicei simbolul care merge la modelul mai mare.