Guadagni:
- Progettazione dei componenti e del flusso di dati di un assistente RAG aziendale end-to-end
- Combinazione di dati provenienti da più fonti (wiki, ticket, PDF, database) in un unico assistente
- Prendi decisioni sull'architettura per scalabilità, memorizzazione nella cache e latenza
Nelle unità precedenti, abbiamo imparato le parti una per una: incorporamento, database vettoriale, suddivisione, recupero. Ora combiniamo questi elementi e creiamo un'architettura end-to-end di un assistente che comunichi con i dati della tua azienda. L'obiettivo è che un dipendente chieda: "Qual è la nostra politica sulle ferie?" Un sistema in cui le persone possono porre domande, le risposte si basano su documenti interni reali, citazioni e combinano più fonti di dati. Questa unità elabora l'intera architettura, il flusso di dati e le decisioni a livello di produzione.
Componenti end-to-end
Un assistente RAG aziendale è composto da due linee separate. La linea di indicizzazione (offline) prepara i dati; La riga di query (online) risponde alla domanda.
Componenti della linea di indicizzazione:
- Connettori: connettori che estraggono dati da fonti: wiki, sistema di ticket, archivio file, database, e-mail.
- Normalizzazione: conversione di diversi formati (PDF, HTML, DOCX) per pulire il testo; pulizia dell'intestazione/piè di pagina.
- Chunking + metadati: Chunking e tagging (fonte, data, autorità).
- Incorporamento + caricamento: scrittura di vettori e metadati nel database dei vettori.
Interrogare i componenti della pipeline:
- Preelaborazione delle query: riscrittura, decentralizzazione.
- Recupero: ricerca ibrida + filtro metadati + riclassificazione.
- Creazione rapida: inserimento di contesto + domanda + istruzioni nel modello.
- Generazione: risposta fondata (contestuale) dal modello + fonti.
- Post-elaborazione: formattazione delle citazioni, controllo di sicurezza, registrazione.
Suggerimento: separare fisicamente la riga di indicizzazione dalla riga di query. L'indicizzazione è lenta e periodica (viene eseguita in batch durante la notte); La linea di indagine dovrebbe essere leggera e immediata. La combinazione delle due righe impone un'elaborazione pesante mentre l'utente attende.
Visualizzazione del flusso di dati
[INDICIZZAZIONE - offline]Risorse → Normalizza → Blocco+Metadati → Incorpora → DB vettoriale (wiki, ticket, PDF, DB)[QUERY - online]Domanda utente → Pre-elaborazione → Recupero (ibrido+filtro+riclassificazione) → Prompt (contesto+domanda+istruzione) → Modello → Risposta+Sorgente → Utente
Combinazione di dati da più fonti
Nelle aziende reali, la risposta non si ferma in un unico posto. "Come emettere un rimborso a un cliente?" La risposta alla domanda può essere trovata sia nell'articolo di aiuto (procedura), nello storico dei ticket (esempi reali), sia nel PDF della policy (regole). L'assistente dovrebbe cercarli tutti in un unico pool.
Punto critico: quando si combinano le risorse in un unico archivio vettoriale, ogni frammento deve contenere i metadati "source_tour". Quindi puoi cercarli tutti e filtrarli se necessario, ad esempio "porta solo polizze ufficiali". Inoltre, diverse fonti hanno diversi livelli di affidabilità: politica ufficiale > articolo della guida > nota del ticket di un dipendente. È possibile specificare questa priorità nella riclassificazione o nel prompt.
Fonte
Tipo di contenuto
fiducia
Frequenza di aggiornamento
PDF della politica
regola ufficiale
alto
mensile
Articolo della guida
Procedura
medio-alto
settimanale
Cronologia dei biglietti
campione reale
medio
Continuo
wiki
Nota mista/attuale
Variabile
Continuo
Scalabilità, cache e latenza
Tre questioni risaltano nella produzione. Latenza: l'esperienza peggiora quando l'utente attende più di 2 secondi. Soluzione: mostra la risposta in streaming: viene visualizzata sullo schermo mentre il modello scrive. Cache: per le domande frequenti e i contesti ripetitivi, la cache aumenta la velocità e riduce i costi. Scala: man mano che l'utente aumenta, è necessario essere in grado di scalare orizzontalmente il recupero e il modello delle chiamate.
Regola pratica dal punto di vista dei costi: il passo più costoso è solitamente il numero di gettoni destinati al modello più grande. Pertanto, ridurre il contesto a 4 parti buone mediante una riclassificazione migliora sia la qualità che i costi. Un progetto comune consiste nell'utilizzare un modello più piccolo/veloce per la classificazione o l'instradamento semplice e un modello più potente per la risposta finale (ad esempio claude-opus-4-8).
Attenzione: non impostare l'indicizzazione come "fallo una volta, dimenticalo". I documenti vengono modificati, cancellati, aggiunti. Stabilire una strategia di reindicizzazione: rilevare i documenti modificati e rielaborarli solo. L'indice obsoleto produce una risposta che sembra attuale ma è sbagliata.
Architettura debole / Architettura forte
Debole (scrittura singola, tutto mescolato):
Quando l'utente chiede: leggi i documenti in quel momento, distruggili, incorporali, cercali, rispondi.# Problema: tutta l'indicizzazione viene ripetuta per ogni domanda; secondi di ritardo, # nessuna separazione della sorgente, nessun filtro, nessun aggiornamento.
Potente (split pipe + metadati + cache + streaming):
Indicizzazione: esecuzione batch di notte, aggiornamento dei documenti modificati. Query: linea leggera — pre-elaborazione → recupero ibrido+filtro → riclassificazione → prompt → modello (streaming) → citazione → log. Le domande frequenti e la fonte vengono memorizzate nella cache.
Tre mini custodie
Caso 1 — Linea confusa, forte ritardo. Una startup ha scritto uno script che rielabora i PDF con ogni domanda; Ogni risposta ha richiesto in media 11 secondi. Quando la linea di indicizzazione veniva separata e i dati venivano precedentemente trasferiti nell'archivio vettoriale, il tempo di interrogazione scendeva a 1,3 secondi e con lo streaming la "prima parola" appariva in 400 ms.
Caso 2 — Troppe risorse, priorità sbagliata. Un assistente di supporto ha dato uguale peso al PDF della policy e alle note dei vecchi ticket; Il modello a volte presentava come regola ufficiale la valutazione errata di un dipendente di due anni fa. Quando i metadati source_tour e l'istruzione "considera la politica ufficiale in caso di conflitto" sono stati aggiunti al prompt, gli errori con falsa priorità sono stati ridotti dell'89%.
Caso 3 — Indice obsoleto. Un assistente HR lavorava con un indice che non veniva aggiornato da 3 mesi; La politica sui congedi è cambiata, ma l'assistente diceva i vecchi tempi. Quando è stato installato l'aggiornamento giornaliero, che rileva i file modificati, il tasso di risposta corrente è aumentato dal 70% al 99%.
Errori comuni
- Combinazione di righe di indicizzazione e di query: l'elaborazione pesante viene eseguita mentre l'utente attende; il ritardo esplode.
- Non inserire il tipo di origine nei metadati: nessuna definizione di priorità e filtro; La fonte non attendibile sembra essere ufficiale.
- Non stabilire una strategia di aggiornamento: l'indice diventa obsoleto; Vengono prodotte risposte sbagliate che sembrano attuali.
- Salta streaming: l'utente guarda uno schermo vuoto; Il ritardo percepito diventa elevato.
- Utilizzando il modello più grande in ogni passaggio: i costi aumentano inutilmente; Lascia lo sterzo al modello più piccolo.
In sintesi
- L'assistente RAG aziendale è composto da due linee separate: indicizzazione offline e interrogazione online; separarli fisicamente.
- Indicizzazione = connettore + normalizzazione + blocco/metadati + incorporamento/caricamento; query = pre-elaborazione + recupero + prompt + generazione + post-elaborazione.
- I dati da più origini vengono combinati in un unico repository, ma i metadati source_type e la priorità di attendibilità vengono preservati.
- Lo streaming e la cache per la latenza, la limitazione del contesto e la selezione del modello in termini di costi sono fondamentali.
- Senza reindicizzazione, l'indice diventa obsoleto; Rielaborare regolarmente i documenti che cambiano.
Compito dell'applicazione
Disegna un diagramma architettonico di un assistente per la tua squadra. (1) Identificare almeno tre origini dati reali e annotare la necessità di un connettore, la frequenza di aggiornamento e il livello di attendibilità per ciascuna. (2) Disegnare le linee di indicizzazione e di query separatamente con un diagramma a freccia. (3) "Dove posso ridurre la latenza e i costi in questo assistente?" Scrivi almeno due decisioni concrete alla domanda. (4) Descrivi la tua strategia di aggiornamento in una frase: quale risorsa verrà reindicizzata e con quale frequenza?
lista di controllo
- [ ] Posso disegnare le linee di indicizzazione e di query separatamente e con i componenti corretti.
- [] Posso combinare dati multi-origine con source_type e priorità di attendibilità.
- [ ] Posso prendere decisioni relative allo streaming/cache per la latenza e alla selezione del modello in termini di costi.
- [ ] So perché una strategia di reindicizzazione è essenziale.
- [] Tengo presente che il passaggio più costoso nella mia architettura è solitamente il token destinato al modello più grande.