Gevinster:
- Design af komponenter og dataflow for en end-to-end enterprise RAG-assistent
- Kombinere multi-source data (wiki, billet, PDF, database) til en enkelt assistent
- Træf arkitektoniske beslutninger for skalerbarhed, caching og latency
I tidligere enheder lærte vi delene én efter én: indlejring, vektordatabase, chunking, genfinding. Lad os nu kombinere disse og bygge en ende-til-ende-arkitektur af en assistent, der taler med dine egne virksomhedsdata. Målet er at få en medarbejder til at spørge: "Hvad er vores orlovspolitik?" Et system, hvor folk kan stille spørgsmål, svarene er baseret på rigtige interne dokumenter, citater og kombinere flere datakilder. Denne enhed behandler hele arkitekturen, dataflowet og produktionsniveauets beslutninger.
End-to-end komponenter
En virksomheds RAG-assistent består af to separate linjer. Indekseringslinjen (offline) forbereder dataene; Forespørgselslinjen (online) besvarer spørgsmålet.
Indekseringslinjekomponenter:
- Connectors: Connectors, der trækker data fra kilder - wiki, billetsystem, fillager, database, e-mail.
- Normalisering: Konvertering af forskellige formater (PDF, HTML, DOCX) til ren tekst; rensning af sidehoved/sidefod.
- Chunking + metadata: Chunking og tagging (kilde, dato, autoritet).
- Indlejring + indlæsning: Skrivning af vektorer og metadata i vektordatabasen.
Forespørgsel pipeline komponenter:
- Forespørgselsforbehandling: Omskrivning, decentralisering.
- Hentning: Hybridsøgning + metadatafilter + omrangering.
- Hurtig oprettelse: Anbringelse af kontekst + spørgsmål + instruktioner i skabelonen.
- Generation: Jordet (kontekstuelt) svar fra modellen + kilder.
- Efterbehandling: Citationsformatering, sikkerhedstjek, logning.
Tip: Adskil fysisk indekseringslinjen fra forespørgselslinjen. Indeksering er langsom og periodisk (kører i batches natten over); Forespørgselslinjen skal være let og umiddelbar. Blanding af de to linjer fremtvinger tung behandling, mens brugeren venter.
Visualisering af dataflow
[INDEKSERING - offline]Ressourcer → Normaliser → Chunk+Metadata → Integrer → Vektor DB (wiki, billet, PDF, DB)[QUERY - online]Brugerspørgsmål → Forbehandling → Hentning (hybrid+filter+omplacering) → Spørg (kontekst+spørgsmål+instruktion) →+ Model →
Kombination af multikildedata
I rigtige virksomheder stopper svaret ikke ét sted. "Hvordan udsteder man en refusion til en kunde?" Svaret på spørgsmålet kan findes både i hjælpeartiklen (procedure), i billethistorikken (rigtige eksempler) og i politik-PDFen (regler). Assistenten skal søge dem alle i én pulje.
Kritisk punkt: Når ressourcer kombineres i et enkelt vektorlager, skal hvert shard bære `source_tour`-metadataene. Så du kan søge i dem alle og filtrere dem, hvis det er nødvendigt, såsom "medbring kun officielle politikker". Forskellige kilder har også forskellige niveauer af pålidelighed: officiel politik > hjælpeartikel > en medarbejders billetseddel. Du kan angive denne prioritet i omrangering eller prompt.
Kilde
Indholdstype
tillid
Opdateringsfrekvens
Politik pdf
officiel regel
høj
månedligt
Hjælpeartikel
Fremgangsmåde
medium-høj
ugentligt
Billethistorik
ægte prøve
medium
Kontinuerlig
wiki
Blandet/aktuel note
Variabel
Kontinuerlig
Skalerbarhed, cache og latens
Tre spørgsmål skiller sig ud i produktionen. Latency: Oplevelsen forringes, når brugeren venter mere end 2 sekunder. Løsning: Vis svaret i streamingform — det hældes på skærmen, mens modellen skriver. Cache: Til ofte stillede spørgsmål og gentagne sammenhænge øger cache både hastigheden og reducerer omkostningerne. Skala: Efterhånden som brugeren øges, er det nødvendigt at kunne skalere hentning og modellere opkald horisontalt.
Tommelfingerregel på omkostningssiden: Det dyreste trin er normalt antallet af poletter, der går til den større model. Derfor forbedrer det både kvalitet og omkostninger at reducere konteksten til 4 gode dele ved at omplacere. Et almindeligt design er at bruge en mindre/hurtigere model til simpel klassificering eller routing, og en mere kraftfuld model til det endelige svar (f.eks. claude-opus-4-8).
Forsigtig: Indstil ikke indeksering som "gør det én gang, glem det". Dokumenter ændres, slettes, tilføjes. Etabler en genindekseringsstrategi: Opdag ændrede dokumenter og genbearbejd kun dem. Det uaktuelle indeks producerer et svar, der virker aktuelt, men som er forkert.
Svag arkitektur / stærk arkitektur
Svag (enkelt script, alt blandet):
Når brugeren spørger: læs dokumenterne på det tidspunkt, makuler dem, indlejr dem, søg i dem, besvar dem. # Problem: al indeksering gentages for hvert spørgsmål; sekunders forsinkelse, # ingen kildeadskillelse, intet filter, ingen opdatering.
Kraftig (split pipes + metadata + cache + streaming):
Indeksering: batch kører om natten, opdaterer ændrede dokumenter. Forespørgsel: letvægtslinje — forbehandling → hybrid hentning+filter → omplacering → prompt → model (streaming) → citat → log. Ofte stillede spørgsmål og kilde gemmes.
Tre mini etuier
Tilfælde 1 — Forvirret linje, kraftig forsinkelse. En startup skrev et script, der genbehandler PDF'er med hvert spørgsmål; Hvert svar tog i gennemsnit 11 sekunder. Da indekseringslinjen blev adskilt og dataene tidligere blev overført til vektorlageret, faldt forespørgselstiden til 1,3 sekunder, og med streaming dukkede det "første ord" op efter 400 ms.
Case 2 — For mange ressourcer, forkert prioritering. En supportassistent gav lige stor vægt til policy-PDFen og gamle billetsedler; Modellen præsenterede nogle gange en medarbejders forkerte vurdering fra to år siden som den officielle regel. Da source_tour-metadata og instruktionen "overvej officiel politik i tilfælde af konflikt" blev føjet til prompten, blev fejlprioriteringsfejl reduceret med 89 %.
Tilfælde 3 - Forældet indeks. En HR-assistent arbejdede med et indeks, der ikke blev opdateret i 3 måneder; Orlovspolitikken er ændret, men assistenten sagde i gamle dage. Da daglig opdatering blev installeret, som registrerer ændrede filer, steg den aktuelle svarprocent fra 70 % til 99 %.
Almindelige fejl
- Blanding af indeksering og forespørgselslinjer: Tung behandling udføres, mens brugeren venter; forsinkelse eksploderer.
- Ikke at sætte kildetypen i metadata: Ingen prioritering og filtrering; Den upålidelige kilde ser ud til at være officiel.
- Ikke at etablere en opdateringsstrategi: Indekset bliver forældet; Der produceres forkerte svar, der virker aktuelle.
- Spring over streaming: Brugeren ser på en tom skærm; Den oplevede forsinkelse bliver høj.
- Brug af den største model på hvert trin: Omkostningerne stiger unødigt; Overlad styringen til den mindre model.
Sammenfattende
- Virksomhedens RAG-assistent består af to separate linjer: offline indeksering og online forespørgsel; adskille dem fysisk.
- Indeksering = connector + normaliser + chunk/metadata + embed/upload; forespørgsel = præ-proces + hentning + prompt + generere + efter-proces.
- Multikildedata kombineres til et enkelt lager, men source_type-metadata og tillidsprioritet bevares.
- Streaming og cache for latency, kontekstregulering og modelvalg for omkostninger er afgørende.
- Uden genindeksering bliver indekset forældet; Genbehandle skiftende dokumenter regelmæssigt.
Ansøgningsopgave
Tegn et arkitektonisk diagram af en assistent for dit eget team. (1) Identificer mindst tre rigtige datakilder, og skriv ned et connectorbehov, opdateringsfrekvens og tillidsniveau for hver. (2) Tegn indekserings- og forespørgselslinjerne separat med et boks-pildiagram. (3) "Hvor reducerer jeg latenstid og omkostninger i denne assistent?" Skriv mindst to konkrete beslutninger til spørgsmålet. (4) Beskriv din opdateringsstrategi i én sætning: hvilken ressource vil blive genindekseret og hvor ofte?
tjekliste
- [ ] Jeg kan tegne indekserings- og forespørgselslinjerne separat og med de korrekte komponenter.
- [ ] Jeg kan kombinere multi-source data med source_type og tillidsprioritet.
- [ ] Jeg kan træffe streaming/cache-beslutninger for latency og modelvalg for omkostninger.
- [ ] Jeg ved, hvorfor en re-indekseringsstrategi er vigtig.
- [ ] Jeg husker på, at det dyreste trin i min arkitektur normalt er den token, der går til den større model.