Assistentarkitektur som snakker med bedriftsdata

Gevinster:

• Utforme komponentene og dataflyten til en ende-til-ende bedrifts RAG-assistent
• Kombinere data fra flere kilder (wiki, billett, PDF, database) til en enkelt assistent
• Ta arkitektoniske avgjørelser for skalerbarhet, hurtigbufring og ventetid

I tidligere enheter lærte vi delene én etter én: innebygging, vektordatabase, chunking, gjenfinning. La oss nå kombinere disse og bygge en ende-til-ende-arkitektur av en assistent som snakker med dine egne bedriftsdata. Målet er å få en ansatt til å spørre: "Hva er vår permisjonspolicy?" Et system der folk kan stille spørsmål, svarene er basert på ekte interne dokumenter, siteringer og kombinere flere datakilder. Denne enheten behandler beslutninger om hele arkitekturen, dataflyten og produksjonsnivået.

Ende-til-ende-komponenter

En bedrifts RAG-assistent består av to separate linjer. Indekseringslinjen (frakoblet) forbereder dataene; Spørrelinjen (online) svarer på spørsmålet.

Indekseringslinjekomponenter:

1. Koblinger: Koblinger som henter data fra kilder - wiki, billettsystem, fillager, database, e-post.
2. Normalisering: Konvertering av forskjellige formater (PDF, HTML, DOCX) til ren tekst; rengjøring av topptekst/bunntekst.
3. Chunking + metadata: Chunking og tagging (kilde, dato, autoritet).
4. Innebygging + lasting: Skrive vektorer og metadata inn i vektordatabasen.

Spørr rørledningskomponenter:

1. Forbehandling av spørring: Omskriving, desentralisering.
2. Henting: Hybridsøk + metadatafilter + omrangering.
3. Rask oppretting: Plasser kontekst + spørsmål + instruksjoner i malen.
4. Generasjon: Begrunnet (kontekstuell) svar fra modellen + kilder.
5. Etterbehandling: Sitasjonsformatering, sikkerhetssjekk, logging.

Tips: Separer indekseringslinjen fysisk fra spørringslinjen. Indeksering er treg og periodisk (kjører i grupper over natten); Spørrelinjen bør være lett og umiddelbar. Blanding av de to linjene tvinger tung prosessering mens brukeren venter.

Visualisere dataflyt

[INDEKSERING - offline]Ressurser → Normaliser → Chunk+Metadata → Bygg inn → Vektor DB (wiki, billett, PDF, DB)[QUERY - online]Brukerspørsmål → Forbehandling → Henting (hybrid+filter+omrangering) → Spørsmål (kontekst+spørsmål+instruksjon) →+ Modell →

Kombinere data fra flere kilder

I ekte selskaper stopper ikke svaret på ett sted. "Hvordan gi en refusjon til en kunde?" Svaret på spørsmålet finner du både i hjelpeartikkelen (prosedyre), i billetthistorikken (virkelige eksempler) og i policy-PDFen (regler). Assistenten bør søke i alle i en pool.

Kritisk poeng: når du kombinerer ressurser til et enkelt vektorlager, må hvert shard inneholde `source_tour`-metadata. Så du kan søke i dem alle og filtrere dem om nødvendig, for eksempel "bare med offisielle retningslinjer". Forskjellige kilder har også ulike nivåer av pålitelighet: offisiell policy > hjelpeartikkel > en ansatts billettlapp. Du kan spesifisere denne prioriteten i omrangering eller spørsmål.

Kilde

Innholdstype

tillit

Oppdateringsfrekvens

Politikk PDF

offisiell regel

høy

månedlig

Hjelpeartikkel

Prosedyre

middels høy

ukentlig

Billetthistorikk

ekte prøve

medium

Kontinuerlig

wiki

Blandet/aktuell note

Variabel

Kontinuerlig

Skalerbarhet, hurtigbuffer og latens

Tre saker skiller seg ut i produksjonen. Latency: Opplevelsen forverres når brukeren venter mer enn 2 sekunder. Løsning: vis svaret i strømmeform — det helles på skjermen mens modellen skriver. Cache: For ofte stilte spørsmål og repeterende sammenhenger, øker hurtigbufferen både hastigheten og reduserer kostnadene. Skala: Etter hvert som brukeren øker, er det nødvendig å kunne skalere henting og modellere anrop horisontalt.

Tommelfingerregel på kostnadssiden: det dyreste trinnet er vanligvis antall tokens som går til den større modellen. Derfor vil det å redusere konteksten til 4 gode deler ved å omrangere både kvalitet og kostnad. En vanlig design er å bruke en mindre/raskere modell for enkel klassifisering eller ruting, og en kraftigere modell for det endelige svaret (f.eks. claude-opus-4-8).

Forsiktig: Ikke sett opp indeksering som "gjør det en gang, glem det". Dokumenter endres, slettes, legges til. Etabler en re-indekseringsstrategi: oppdage endrede dokumenter og behandle bare dem på nytt. Den foreldede indeksen produserer et svar som virker gjeldende, men som er feil.

Svak arkitektur / sterk arkitektur

Svak (enkelt manus, alt blandet):

Når brukeren spør: les dokumentene i det øyeblikket, makuler dem, bygg dem inn, søk i dem, svar på dem.# Problem: all indeksering gjentas for hvert spørsmål; sekunders forsinkelse, # ingen kildeseparasjon, ingen filter, ingen oppdatering.

Kraftig (delte rør + metadata + cache + streaming):

Indeksering: batchkjøring om natten, oppdater endrede dokumenter. Spørring: lettvektslinje — forhåndsbehandling → hybrid henting+filter → rangering på nytt → ledetekst → modell (streaming) → sitering → logg. Vanlige spørsmål og kilde lagres.

Tre minivesker

Tilfelle 1 - Forvirret linje, kraftig forsinkelse. En startup skrev et skript som behandler PDF-er på nytt med hvert spørsmål; Hvert svar tok i gjennomsnitt 11 sekunder. Da indekseringslinjen ble separert og dataene tidligere ble overført til vektorlageret, sank spørringstiden til 1,3 sekunder og med streaming dukket det "første ordet" opp etter 400 ms.

Sak 2 – For mange ressurser, feil prioritering. En støtteassistent la like stor vekt på policy-PDFen og gamle billettlapper; Modellen presenterte noen ganger en ansatts feilvurdering fra to år siden som den offisielle regelen. Da source_tour-metadata og instruksjonen "Vurder offisiell policy i tilfelle konflikt" ble lagt til ledeteksten, ble feilprioriterte feil redusert med 89 %.

Sak 3 - Foreldet indeks. En HR-assistent jobbet med en indeks som ikke ble oppdatert på 3 måneder; Permisjonspolitikken er endret, men assistenten sa i gamle dager. Da daglig oppdatering ble installert, som oppdager endrede filer, økte den nåværende svarfrekvensen fra 70 % til 99 %.

Vanlige feil

• Blanding av indeksering og spørringslinjer: Tung prosessering gjøres mens brukeren venter; forsinkelse eksploderer.
• Ikke å sette kildetypen i metadata: Ingen prioritering og filtrering; Den upålitelige kilden ser ut til å være offisiell.
• Ikke etablere en oppdateringsstrategi: Indeksen blir foreldet; Det produseres feil svar som virker aktuelle.
• Hopp over streaming: Brukeren ser på en tom skjerm; Den opplevde forsinkelsen blir høy.
• Bruker den største modellen på hvert trinn: Kostnaden øker unødvendig; Overlat styringen til den mindre modellen.

Oppsummert

• Bedriftens RAG-assistent består av to separate linjer: offline indeksering og online spørring; skille dem fysisk.
• Indeksering = kobling + normaliser + chunk/metadata + embed/upload; query = pre-prosess + henting + prompt + generere + etter-prosess.
• Data fra flere kilder kombineres til et enkelt depot, men metadata for kildetype og tillitsprioritet er bevart.
• Streaming og hurtigbuffer for ventetid, kontekstkontroll og modellvalg for kostnad er avgjørende.
• Uten ny indeksering blir indeksen foreldet; Behandle skiftende dokumenter regelmessig.

Søknadsoppgave

Tegn et arkitektonisk diagram av en assistent for ditt eget team. (1) Identifiser minst tre reelle datakilder og skriv ned et koblingsbehov, oppdateringsfrekvens og tillitsnivå for hver. (2) Tegn indekserings- og spørringslinjene separat med et boks-pildiagram. (3) "Hvor reduserer jeg ventetiden og kostnadene i denne assistenten?" Skriv minst to konkrete avgjørelser til spørsmålet. (4) Beskriv oppdateringsstrategien din i én setning: hvilken ressurs vil bli reindeksert og hvor ofte?

sjekkliste

• [ ] Jeg kan tegne indekserings- og spørringslinjene separat og med de riktige komponentene.
• [ ] Jeg kan kombinere data fra flere kilder med kildetype og tillitsprioritet.
• [ ] Jeg kan ta streaming/cache-avgjørelser for ventetid og modellvalg for kostnad.
• [ ] Jeg vet hvorfor en re-indekseringsstrategi er viktig.
• [ ] Jeg husker at det dyreste trinnet i arkitekturen min vanligvis er tokenet som går til den større modellen.