Winst:
- Ontwerp van de componenten en gegevensstroom van een end-to-end enterprise RAG-assistent
- Het combineren van gegevens uit meerdere bronnen (wiki, ticket, PDF, database) in één enkele assistent
- Neem architecturale beslissingen voor schaalbaarheid, caching en latentie
In eerdere units hebben we de onderdelen één voor één geleerd: inbedden, vectordatabase, chunking, ophalen. Laten we deze nu combineren en een end-to-end architectuur bouwen van een assistent die met uw eigen bedrijfsgegevens praat. Het doel is om een medewerker te laten vragen: “Wat is ons verlofbeleid?” Een systeem waar mensen vragen kunnen stellen, de antwoorden zijn gebaseerd op echte interne documenten, citaten en combineren meerdere databronnen. Deze eenheid verwerkt de volledige beslissingen op het gebied van architectuur, datastroom en productieniveau.
End-to-end-componenten
Een corporate RAG-assistent bestaat uit twee aparte lijnen. De indexeringslijn (offline) bereidt de gegevens voor; De vraagregel (online) beantwoordt de vraag.
Componenten van indexeringslijnen:
- Connectors: Connectors die gegevens uit bronnen halen: wiki, ticketsysteem, bestandsopslag, database, e-mail.
- Normalisatie: het converteren van verschillende formaten (PDF, HTML, DOCX) naar schone tekst; kop-/voettekst opschonen.
- Chunking + metadata: Chunking en tagging (bron, datum, autoriteit).
- Inbedden + laden: vectoren en metadata in de vectordatabase schrijven.
Onderdelen van querypijplijn:
- Voorverwerking van zoekopdrachten: herschrijven, decentralisatie.
- Ophalen: Hybride zoeken + metadatafilter + herrangschikking.
- Prompt maken: context + vraag + instructies in de sjabloon plaatsen.
- Generatie: Gefundeerd (contextueel) antwoord uit het model + bronnen.
- Nabewerking: citatieopmaak, veiligheidscontrole, loggen.
Tip: Scheid de indexeringsregel fysiek van de queryregel. Het indexeren is langzaam en periodiek (wordt 's nachts in batches uitgevoerd); De onderzoekslijn moet licht en onmiddellijk zijn. Het combineren van de twee lijnen dwingt zware verwerking af terwijl de gebruiker wacht.
Gegevensstroom visualiseren
[INDEXING - offline]Bronnen → Normaliseren → Chunk+Metadata → Insluiten → Vector DB (wiki, ticket, PDF, DB)[QUERY - online]Gebruikersvraag → Voorverwerking → Ophalen (hybride+filter+herrangschikken) → Prompt (context+vraag+instructie) → Model → Antwoord+Bron → Gebruiker
Combineren van gegevens uit meerdere bronnen
In echte bedrijven stopt het antwoord niet op één plek. “Hoe kan ik een klant een terugbetaling geven?” Het antwoord op de vraag vindt u zowel in het helpartikel (procedure), in de ticketgeschiedenis (echte voorbeelden), als in de beleids-pdf (regels). De assistent moet ze allemaal in één pool doorzoeken.
Kritiek punt: bij het combineren van bronnen in één enkele vectoropslag moet elke shard de metagegevens van 'source_tour' bevatten. Je kunt ze dus allemaal doorzoeken en indien nodig filteren, bijvoorbeeld ‘neem alleen officiële polissen mee’. Bovendien hebben verschillende bronnen verschillende niveaus van betrouwbaarheid: officieel beleid > helpartikel > ticketnotitie van een medewerker. U kunt deze prioriteit opgeven bij herrangschikking of prompt.
Bron
Inhoudstype
vertrouwen
Frequentie bijwerken
Beleid-pdf
officiële regel
hoog
maandelijks
Help-artikel
Werkwijze
middelhoog
wekelijks
Ticketgeschiedenis
echt monster
middelmatig
Continu
wiki
Gemengde/huidige noot
Variabel
Continu
Schaalbaarheid, cache en latentie
Bij de productie vallen drie problemen op. Latency: De ervaring verslechtert wanneer de gebruiker meer dan 2 seconden wacht. Oplossing: geef het antwoord in streamingvorm weer: het wordt op het scherm gegoten terwijl het model schrijft. Cache: Voor veelgestelde vragen en repetitieve contexten verhoogt cache zowel de snelheid als de kosten. Schaal: Naarmate de gebruiker groter wordt, is het noodzakelijk om het ophalen en modelleren van oproepen horizontaal te kunnen schalen.
Vuistregel aan de kostenkant: de duurste stap is meestal het aantal tokens dat naar het grotere model gaat. Daarom verbetert het reduceren van de context tot vier goede delen door het opnieuw rangschikken zowel de kwaliteit als de kosten. Een gebruikelijk ontwerp is het gebruik van een kleiner/sneller model voor eenvoudige classificatie of routering, en een krachtiger model voor het uiteindelijke antwoord (bijv. claude-opus-4-8).
Let op: Stel indexering niet in als 'doe het één keer en vergeet het maar'. Documenten worden gewijzigd, verwijderd, toegevoegd. Stel een herindexeringsstrategie op: detecteer gewijzigde documenten en verwerk alleen deze opnieuw. De verouderde index levert een antwoord op dat actueel lijkt, maar fout is.
Zwakke architectuur / sterke architectuur
Zwak (enkel script, alles gemengd):
Wanneer de gebruiker vraagt: lees de documenten op dat moment, versnipper ze, sluit ze in, doorzoek ze, beantwoord ze.# Probleem: alle indexering wordt herhaald voor elke vraag; seconden vertraging, # geen bronscheiding, geen filter, geen vernieuwing.
Krachtig (splitpipes + metadata + cache + streaming):
Indexering: batchruns 's nachts, gewijzigde documenten vernieuwen. Query: lichtgewicht regel - voorverwerking → hybride ophalen+filter → herrangschikken → prompt → model (streaming) → citatie → log. Veelgestelde vragen en de bron worden in de cache opgeslagen.
Drie mini-hoesjes
Geval 1 — Verwarde lijn, zware vertraging. Een startup schreef een script dat bij elke vraag pdf's opnieuw verwerkt; Elk antwoord duurde gemiddeld 11 seconden. Toen de indexeringslijn werd gescheiden en de gegevens eerder naar het vectorgeheugen waren overgebracht, nam de opvraagtijd af tot 1,3 seconden en bij streaming verscheen het "eerste woord" in 400 ms.
Geval 2 — Te veel middelen, verkeerde prioriteit. Een ondersteuningsassistent gaf evenveel gewicht aan de polis-pdf als aan oude ticketnotities; Het model presenteerde soms een onjuiste beoordeling van een medewerker van twee jaar geleden als officiële regel. Toen source_tour-metagegevens en de instructie 'Overweeg officieel beleid in geval van conflict' aan de prompt werden toegevoegd, werden fouten met valse prioriteit met 89% verminderd.
Geval 3 — Verouderde index. Een HR-assistent werkte met een index die al 3 maanden niet werd bijgewerkt; Het verlofbeleid is veranderd, maar de assistent zei vroeger. Toen dagelijkse vernieuwing werd geïnstalleerd, waarmee gewijzigde bestanden worden gedetecteerd, steeg het huidige responspercentage van 70% naar 99%.
Veel voorkomende fouten
- Mix van index- en queryregels: zware verwerking vindt plaats terwijl de gebruiker wacht; vertraging explodeert.
- Het brontype niet in metadata plaatsen: geen prioriteitstelling en filtering; De onbetrouwbare bron lijkt officieel te zijn.
- Geen vernieuwingsstrategie vaststellen: de index wordt verouderd; Er worden foute antwoorden geproduceerd die actueel lijken.
- Streaming overslaan: gebruiker kijkt naar een leeg scherm; De waargenomen vertraging wordt hoog.
- Bij elke stap het grootste model gebruiken: kosten stijgen onnodig; Laat de besturing over aan het kleinere model.
Samengevat
- De corporate RAG-assistent bestaat uit twee afzonderlijke lijnen: offline indexeren en online zoeken; scheid ze fysiek.
- Indexeren = connector + normaliseren + chunk/metadata + insluiten/uploaden; query = voorverwerken + ophalen + prompt + genereren + naverwerken.
- Gegevens uit meerdere bronnen worden gecombineerd in één opslagplaats, maar de metagegevens van het brontype en de vertrouwensprioriteit blijven behouden.
- Streaming en cache voor latentie, contextbeperking en modelselectie voor kosten zijn van cruciaal belang.
- Zonder herindexering wordt de index verouderd; Verwerk veranderende documenten regelmatig opnieuw.
Applicatie taak
Teken een bouwkundig diagram van een assistent voor je eigen team. (1) Identificeer ten minste drie echte gegevensbronnen en noteer voor elke connectorbehoefte, updatefrequentie en vertrouwensniveau. (2) Teken de indexerings- en querylijnen afzonderlijk met een doospijldiagram. (3) "Waar verminder ik de latentie en kosten in deze assistent?" Schrijf ten minste twee concrete beslissingen bij de vraag. (4) Beschrijf uw vernieuwingsstrategie in één zin: welke bron wordt opnieuw geïndexeerd en hoe vaak?
controlelijst
- [ ] Ik kan de indexerings- en querylijnen afzonderlijk en met de juiste componenten tekenen.
- [ ] Ik kan gegevens uit meerdere bronnen combineren met source_type en vertrouwensprioriteit.
- [ ] Ik kan streaming-/cachebeslissingen nemen over de latentie en modelselectie op basis van de kosten.
- [ ] Ik weet waarom een herindexeringsstrategie essentieel is.
- [ ] Ik houd er rekening mee dat de duurste stap in mijn architectuur meestal het token is dat naar het grotere model gaat.