Ich habe RAG von Grund auf in Python gebaut, um es zu verstehen

Ich habe LangChain sechs Monate lang in der Produktion eingesetzt. Ich konnte nicht erklären, wie es funktionierte. Ich wusste nicht, warum ich bestimmte Metriken gewählt hatte oder wie Text zu Vektoren wurde. Die Bibliothek hat die Logik verborgen.

Um das zu beheben, habe ich das Framework gelöscht. Ich habe eine RAG-Pipeline von Grund auf mit 500 Zeilen reinem Python geschrieben.

Hier ist das, was ich beim manuellen Aufbau des Stacks gelernt habe.

Das Problem mit Black Boxes

Wenn man High-Level-Bibliotheken verwendet, verliert man die Kontrolle. Ich habe erlebt, wie Modelle Fakten halluzinierten oder falsche Zitate angaben. Ich konnte nicht sagen, ob der Fehler im Chunker, im Embedding-Modell oder im Prompt lag.

Wenn man es selbst baut, ist jede Ebene überprüfbar. Man kann die exakten Chunks ausgeben, die an das LLM gesendet werden. Man kann genau sehen, wo ein Satz unterbrochen wird.

Die fünf Ebenen von RAG

RAG ist nicht ein einzelner Algorithmus. Es sind fünf verschiedene Prozesse, die übereinander gestapelt sind:

  • Chunking: Die Entscheidung, wie Text aufgeteilt wird.
  • Embedding: Text in Mathematik umwandeln.
  • Retrieval: Die richtigen Teile finden.
  • Prompt Construction: Dem Modell sagen, wie es sich verhalten soll.
  • Generation: Die endgültige Antwort erhalten.

Erkenntnisse aus dem Aufbau

  1. Chunking ist der wichtigste Schritt Die meisten Tutorials überspringen das. Wenn man keinen Overlap verwendet, verliert man den Kontext an den Grenzen. Ich habe ein Sliding Window mit Overlap auf Zeichenebene verwendet. Dies stellt sicher, dass das Modell die Verbindung zwischen zwei Chunks sieht.

  2. Distanzmetriken sind entscheidend Ich habe Stunden damit verbracht, schlechte Suchergebnisse zu debuggen. Das Problem waren nicht die Daten. Es war die Metrik. ChromaDB verwendet standardmäßig die L2-Distanz. Für die semantische Suche benötigt man die Cosine Similarity. Eine Zeile Code hat alles verändert.

  3. Prompts benötigen Einschränkungen Ein LLM ist ein Vervollständiger, kein Orakel. Wenn man eine vage Frage stellt, wird es eine Antwort erfinden. Ich habe gelernt, eine strikte Verweigerungsvorlage (Refusal Template) zu verwenden. Ich sagte dem Modell: „Wenn der Kontext die Antwort nicht enthält, sage, dass du es nicht weißt.“ Dies senkte die Halluzinationen von 40 % auf 5 %.

  4. Batching von Anfragen Das Senden einer HTTP-Anfrage pro Chunk ist langsam. Das Senden in Batches ist viel schneller. Es ermöglicht dem lokalen Modell, die Arbeit zu pipelinen.

  5. Testen von unten nach oben Schreiben Sie Tests nicht erst am Ende. Testen Sie zuerst Ihren Chunker. Dann testen Sie Ihren Embedder. Dann testen Sie Ihren Store. Wenn Sie erst am Ende testen, testen Sie die Bugs statt der Logik.

Wenn Sie das Gefühl haben, Ihren AI-Stack nicht wirklich zu verstehen, bauen Sie ihn selbst. Der Code ist nicht das Ziel. Das Denken ist das Ziel.

Source: https://dev.to/avinash_zala_1c6f5e7c4af9/i-built-rag-from-scratch-in-python-to-understand-it-heres-what-i-learned-33kf

Optional learning community: https://t.me/GyaanSetuAi