Ich habe 500 $ für RAG-Infrastruktur ausgegeben, bevor ich 7 Fehler gemacht habe

Ich habe eine RAG-Pipeline für die Suche in privaten Dokumenten entwickelt. Es hat mich 500 $ an Rechenleistung und Wochen des Debuggings gekostet. Die Ergebnisse waren schlecht. Die Nutzer erhielten irrelevante Antworten und die Abfragen waren langsam.

Ich habe die Pipeline auditiert und 7 häufige Fehler gefunden. Die Behebung dieser Fehler hat alles verändert.

  1. Starres Token-Chunking Ich habe Dokumente nach einer festen Anzahl von Token aufgeteilt. Das hat den Kontext zerstört. Ein Satz wurde mitten im Wort getrennt. Das LLM erhielt fragmentierte Daten und lieferte schlechte Antworten.
  • Die Lösung: Verwenden Sie semantisches Chunking mit Parent-Document-Retrieval.
  • Teilen Sie nach natürlichen Grenzen wie Absätzen oder Überschriften auf.
  • Erstellen Sie kleine Child-Chunks für die Suche.
  • Geben Sie das vollständige Parent-Dokument an das LLM zurück, wenn ein Treffer erzielt wird.
  • Fügen Sie einen Überlapp (Overlap) von 10–20 % zwischen den Chunks hinzu.
  1. Standardmäßige Suchgewichtung Ich habe eine 50/50-Aufteilung für die Vektor- und Keyword-Suche verwendet. Bei technischen Dokumenten sind exakte Keywords wichtiger.
  • Die Lösung: Verwenden Sie dynamische Gewichtungen.
  • Faktische Abfragen: 35 % Vektor, 65 % Keyword.
  • Semantische Abfragen: 75 % Vektor, 25 % Keyword.
  1. Überoptimierung der HNSW-Parameter Ich habe ef_construction auf den Maximalwert gesetzt. Bei einem großen Index führte dies zum Absturz meines Servers und verbrauchte den gesamten RAM.
  • Die Lösung: Verwenden Sie angemessene HNSW-Einstellungen.
  • Halten Sie M zwischen 8 und 32.
  • Setzen Sie ef_construction auf 200.
  • Setzen Sie ef_search auf 50.
  1. Falsche Embedding-Modelle Ich habe ein allgemeines Modell verwendet, das auf Web-Texten trainiert wurde. Es verstand meine technischen Ingenieursdokumente nicht.
  • Die Lösung: Wechseln Sie zu einem Modell, das auf technische Inhalte oder Code feinabgestimmt ist.
  1. Diskrepanz in der natürlichen Sprache Nutzer stellen Fragen wie „Warum ist mein Build langsam?“. Die Dokumentation verwendet Begriffe wie „CI-Pipeline-Optimierung“. Es gab keinerlei Überschneidungen.
  • Die Lösung: Fügen Sie einen Schritt zum Umschreiben der LLM-Abfrage (Query Rewrite) hinzu.
  • Schreiben Sie die Nutzeranfrage vor der Suche in technische Fachbegriffe um.
  1. Redundanter Kontext Das Abrufen der Top-10-Chunks bedeutete oft, denselben Absatz dreimal zu erhalten. Dies führte zu Halluzinationen.
  • Die Lösung: Verwenden Sie Maximal Marginal Relevance (MMR), um die Diversität der Ergebnisse sicherzustellen.
  1. Nur End-to-End-Evaluierung Ich habe nur die finale Antwort überprüft. Ich wusste nicht, ob das Problem beim Retrieval oder beim LLM lag.
  • Die Lösung: Evaluieren Sie das Retrieval separat.
  • Verfolgen Sie die Hit-Rate und den Mean Reciprocal Rank (MRR).
  • Erstellen Sie einen Testdatensatz mit 100 Abfrage-Dokument-Paaren.

Ergebnisse nach der Behebung: • Antwortrelevanz: 45 % auf 85 % • Latenz der Abfrage: 3,2 s auf 1,8 s • Monatliche Kosten: 180 $ auf 95 $

Zuerst das Chunking optimieren. Dann die Weights. Dann die Embedding-Qualität.

Was bereitet dir bei RAG die größten Kopfschmerzen? Schreib es mir in die Kommentare.

Quelle: https://dev.to/kollittle/i-spent-500-on-rag-infrastructure-before-realizing-these-7-mistakes-were-killing-my-results-iph

Optionale Lern-Community: https://t.me/GyaanSetuAi