RAG in der Produktion im großen Maßstab: Erkenntnisse aus der Verarbeitung von über 10.000 Anzeigen täglich
Ich habe eine RAG-Pipeline für ein Jobportal entwickelt. In der Staging-Umgebung funktionierte sie einwandfrei, stieß aber unter realer Last an ihre Grenzen. Die tägliche Verarbeitung von Tausenden von Anzeigen erfordert mehr als nur einen guten Vector Store. Man muss verstehen, an welchen Stellen das System versagt.
Hier sind meine Erkenntnisse zu Chunking, Embeddings, Kosten und Observability.
1. Raten Sie nicht bei Ihrer Chunking-Strategie
Die meisten Tutorials behandeln Chunking als eine einfache Einstellung. In der Produktion bestimmt Ihre Strategie die Genauigkeit und die Kosten.
Ich habe drei Methoden für Stellenanzeigen getestet:
- Chunks mit fester Größe (Fixed-size chunks): Diese sind gescheitert. Sie haben Abschnitte wie „Anforderungen“ und „Benefits“ an willkürlichen Stellen getrennt. Dies führt zu ungenauem Retrieval.
- Semantisches Chunking: Dies war besser, aber inkonsistent. Einige Chunks waren zu lang, andere zu kurz.
- Rekursives Splitten von Zeichen mit Überlappung (Recursive character splitting with overlap): Dies funktionierte am besten. Ich habe nach Zeilenumbrüchen und Sätzen getrennt. Ich habe eine Größe von 400 Token mit einer Überlappung von 50 Token verwendet. Dies stellt sicher, dass Sätze, die über zwei Chunks gehen, zusammenhängend bleiben.
Profi-Tipp: Normalisieren Sie Ihre Daten vor dem Chunking. Verschiedene Quellen wie Greenhouse oder Lever liefern unterschiedliche Formate. Bereinigen Sie den Text zuerst, damit Ihr Chunker eine konsistente Struktur vorfindet.
2. Embeddings: Kosten vs. Genauigkeit
Ich habe Llama 3.1 via Ollama gegen OpenAI text-embedding-3-small getestet.
Das lokale Modell war kostenlos, hatte aber Schwierigkeiten mit fachspezifischen Begriffen wie „equity compensation“. Es lieferte ungenaue Ergebnisse.
OpenAI war teurer, lieferte aber präzise Treffer. Ich habe mich für OpenAI entschieden, da schlechtes Retrieval später durch teurere LLM-Aufrufe mehr kostet.
Um Zeit zu sparen, verarbeite ich meine Anfragen in Batches. Ich sende bis zu 100 Chunks in einem einzigen Aufruf. Dies reduziert die Latenz und hält die Pipeline schnell.
3. Der Kompromiss beim Vector Store
Ich habe Pinecone für das Prototyping verwendet, da es schnell einsatzbereit ist. Bei steigender Skalierung wurden die Kosten jedoch zu hoch.
Ich bin zu pgvector innerhalb von PostgreSQL gewechselt.
- Es war aufwendiger einzurichten.
- Es hat massiv Kosten gespart.
- Es bot transaktionale Konsistenz. Da die Embeddings in derselben Datenbank wie die Jobdaten liegen, haben Sie eine einzige „Single Source of Truth“. Sie müssen keine zwei verschiedenen Systeme synchronisieren.
4. LLM-Kosten kontrollieren
Jede Anzeige mit GPT-4o zu bewerten (Scoring), ist teuer. Ich habe drei Taktiken angewandt, um die Kosten zu senken:
- OpenAI Batch API: Ich verarbeite die Scoring-Jobs über Nacht. Dies ermöglicht einen großen Rabatt.
- Caching: Ich speichere Ergebnisse für wiederkehrende Kandidatenprofile zwischen.
- Model Tiering: Ich verwende GPT-4o-mini für gängige Rollen wie „Sales Representative“. GPT-4o setze ich nur für Nischenrollen ein, bei denen Präzision entscheidend ist.
5. Bauen Sie zuerst Observability auf
Meine Pipeline ist einmal lautlos fehlgeschlagen. Fehlerhafte Daten verursachten leere Chunks, die das System ohne Fehlermeldung einfach übersprang.
Ich habe dies behoben, indem ich strukturiertes Logging mit einer Correlation ID hinzugefügt habe. Dadurch konnte ich eine einzelne Anzeige vom Ingest bis zum Scoring nachverfolgen. Endlich konnte ich sehen, welche Datenquellen die Fehler verursachten.
Die wichtigste Erkenntnis: Die meisten Probleme entstehen durch unordentliche Daten, nicht durch die KI. Kümmern Sie sich zuerst um Ihre Daten-Infrastruktur.
Optionale Lern-Community: https://t.me/GyaanSetuAi