Assistentarkitektur som talar med företagsdata

Vinster:

• Designa komponenterna och dataflödet för en RAG-assistent för hela företaget
• Kombinera data från flera källor (wiki, biljett, PDF, databas) till en enda assistent
• Fatta arkitektoniska beslut för skalbarhet, cachelagring och latens

I tidigare enheter lärde vi oss delarna en efter en: inbäddning, vektordatabas, chunking, hämtning. Låt oss nu kombinera dessa och bygga en end-to-end-arkitektur av en assistent som pratar med din egen företagsdata. Målet är att få en anställd att fråga: "Vad är vår ledighetspolicy?" Ett system där människor kan ställa frågor, svaren är baserade på riktiga interna dokument, citat och kombinera flera datakällor. Denna enhet bearbetar hela arkitekturen, dataflödet och produktionsnivåbeslut.

End-to-end-komponenter

En företags RAG-assistent består av två separata linjer. Indexeringsraden (offline) förbereder data; Frågeraden (online) besvarar frågan.

Indexeringslinjekomponenter:

1. Anslutningar: Anslutningar som hämtar data från källor - wiki, biljettsystem, filarkiv, databas, e-post.
2. Normalisering: Konvertera olika format (PDF, HTML, DOCX) till ren text; rengöring av sidhuvud/sidfot.
3. Chunking + metadata: Chunking och taggning (källa, datum, auktoritet).
4. Inbäddning + laddning: Skriva vektorer och metadata till vektordatabasen.

Fråga pipeline komponenter:

1. Frågeförbehandling: Omskrivning, decentralisering.
2. Hämtning: Hybridsökning + metadatafilter + omrankning.
3. Skapa snabbt: Placera sammanhang + fråga + instruktioner i mallen.
4. Generation: Grundat (kontextuellt) svar från modellen + källor.
5. Efterbehandling: Citeringsformatering, säkerhetskontroll, loggning.

Tips: Separera indexeringsraden fysiskt från frågeraden. Indexering är långsam och periodisk (körs i omgångar över natten); Frågan bör vara lätt och omedelbar. Att blanda de två raderna tvingar fram tung bearbetning medan användaren väntar.

Visualisera dataflöde

[INDEXERING - offline]Resurser → Normalisera → Chunk+Metadata → Bädda in → Vector DB (wiki, biljett, PDF, DB)[QUERY - online]Användarfråga → Förbearbetning → Hämtning (hybrid+filter+omrankning) → Fråga (sammanhang+fråga+instruktion →Användare) →+ Modell →

Kombinera data från flera källor

I riktiga företag stannar svaret inte på ett ställe. "Hur utfärdar man en återbetalning till en kund?" Svaret på frågan finns både i hjälpartikeln (proceduren), i biljetthistoriken (riktiga exempel) och i policy-PDF (regler). Assistenten bör söka igenom dem alla i en pool.

Kritisk punkt: när man kombinerar resurser till ett enda vektorlager måste varje skärva ha metadata för `source_tour`. Så du kan söka i dem alla och filtrera dem om det behövs, till exempel "ta bara med officiella policyer". Dessutom har olika källor olika tillförlitlighetsnivåer: officiell policy > hjälpartikel > en anställds biljettanteckning. Du kan ange denna prioritet i omrangering eller uppmaning.

Källa

Innehållstyp

lita på

Uppdateringsfrekvens

Policy PDF

officiell regel

hög

månadsvis

Hjälpartikel

Förfarande

medelhög

varje vecka

Biljetthistorik

verkligt prov

medium

Kontinuerlig

wiki

Blandad/aktuell not

Variabel

Kontinuerlig

Skalbarhet, cache och latens

Tre nummer sticker ut i produktionen. Latens: Upplevelsen försämras när användaren väntar mer än 2 sekunder. Lösning: visa svaret i strömmande form — det hälls upp på skärmen när modellen skriver. Cache: För vanliga frågor och repetitiva sammanhang ökar cachen både hastigheten och minskar kostnaderna. Skala: När användaren ökar är det nödvändigt att kunna skala hämtning och modellera anrop horisontellt.

Tumregel på kostnadssidan: det dyraste steget är vanligtvis antalet polletter som går till den större modellen. Att därför reducera sammanhanget till 4 bra delar genom att omrangera förbättrar både kvalitet och kostnad. En vanlig design är att använda en mindre/snabbare modell för enkel klassificering eller routing, och en mer kraftfull modell för det slutliga svaret (t.ex. claude-opus-4-8).

Varning: Ställ inte in indexering som "gör det en gång, glöm det". Dokument ändras, tas bort, läggs till. Upprätta en strategi för återindexering: upptäck ändrade dokument och bearbeta endast dem igen. Det inaktuella indexet ger ett svar som verkar aktuellt men är fel.

Svag arkitektur / Stark arkitektur

Svag (enkelt manus, allt blandat):

När användaren frågar: läs dokumenten i det ögonblicket, strimla dem, bädda in dem, sök i dem, svara på dem.# Problem: all indexering upprepas för varje fråga; sekunders fördröjning, # ingen källseparation, inget filter, ingen uppdatering.

Kraftfull (split pipes + metadata + cache + streaming):

Indexering: batchkörningar på natten, uppdaterar ändrade dokument. Fråga: lättviktslinje — förbearbetning → hybridhämtning+filter → omplacering → prompt → modell (strömning) → citat → logg. Vanliga frågor och källa cachelagras.

Tre minifodral

Fall 1 — Förvirrad linje, kraftig försening. En startup skrev ett skript som bearbetar PDF-filer med varje fråga; Varje svar tog i genomsnitt 11 sekunder. När indexeringsraden separerades och data tidigare överförts till vektorlagret minskade frågetiden till 1,3 sekunder och med streaming dök det "första ordet" upp efter 400 ms.

Fall 2 — För många resurser, fel prioritering. En supportassistent gav lika stor vikt åt policy-PDF och gamla biljettanteckningar; Modellen presenterade ibland en anställds felaktiga betyg från två år sedan som officiell regel. När source_tour-metadata och instruktionen "överväg officiell policy vid konflikt" lades till i prompten, reducerades felprioritetsfel med 89 %.

Fall 3 – Inaktuellt index. En HR-assistent arbetade med ett index som inte uppdaterades på 3 månader; Ledighetspolicyn har ändrats, men assistenten sa förr i tiden. När daglig uppdatering installerades, som upptäcker ändrade filer, ökade den aktuella svarsfrekvensen från 70 % till 99 %.

Vanliga misstag

• Blanda indexering och frågerader: Tung bearbetning görs medan användaren väntar; fördröjning exploderar.
• Att inte lägga in källtypen i metadata: Ingen prioritering och filtrering; Den opålitliga källan verkar vara officiell.
• Inte etablera en uppdateringsstrategi: Indexet blir inaktuellt; Fel svar som verkar aktuella produceras.
• Hoppa över streaming: Användaren tittar på en tom skärm; Den upplevda fördröjningen blir hög.
• Att använda den största modellen vid varje steg: Kostnaden ökar i onödan; Lämna styrningen till den mindre modellen.

Sammanfattningsvis

• Företagets RAG-assistent består av två separata rader: offlineindexering och onlineförfrågan; separera dem fysiskt.
• Indexering = koppling + normalisera + chunk/metadata + inbäddning/uppladdning; fråga = förbearbetning + hämtning + uppmaning + generera + efterbearbetning.
• Data från flera källor kombineras till ett enda arkiv, men metadata för källtyp och förtroendeprioritet bevaras.
• Streaming och cache för latens, kontextbegränsning och modellval för kostnad är avgörande.
• Utan omindexering blir indexet inaktuellt; Bearbeta ändrade dokument regelbundet.

Applikationsuppgift

Rita ett arkitektoniskt diagram av en assistent för ditt eget team. (1) Identifiera minst tre riktiga datakällor och skriv ner ett anslutningsbehov, uppdateringsfrekvens och förtroendenivå för var och en. (2) Rita indexerings- och frågelinjerna separat med ett diagram med rutor. (3) "Var minskar jag latens och kostnad i den här assistenten?" Skriv minst två konkreta beslut till frågan. (4) Beskriv din uppdateringsstrategi i en mening: vilken resurs kommer att återindexeras och hur ofta?

checklista

• [ ] Jag kan rita indexerings- och frågeraderna separat och med rätt komponenter.
• [ ] Jag kan kombinera multi-source data med source_type och trust priority.
• [ ] Jag kan göra streaming/cache-beslut för latens och modellval för kostnad.
• [ ] Jag vet varför en omindexeringsstrategi är viktig.
• [ ] Jag tänker på att det dyraste steget i min arkitektur vanligtvis är den pollett som går till den större modellen.