Vektor-DB / RAG-Implementierungsleitfaden — von naivem RAG zum Produktivbetrieb
Sie wissen, „was RAG ist“, doch beim Bauen kommt die Antwort schief heraus — weil es noch naives RAG ist: achtlos zerstückeln und eine einfache Vektorsuche durchführen. Als Implementierungs-Fortsetzung zu Artikel 030 erklärt dieser Beitrag die praxistaugliche RAG-Pipeline von 2026 (intelligentes Chunking, Embedding, Vektor-DB, hybride Suche, Reranking) Stufe für Stufe: Chunking-Strategien (recursive 512 als Standard, semantic/structural/parent-child, Contextual Retrieval senkt Retrieval-Fehler Berichten zufolge um bis zu 67%), Auswahl eines Embedding-Modells (text-embedding-3-large usw.), ein Vergleich von sechs Vektor-DBs (Chroma fürs Prototyping, pgvector mit Postgres, niedrig-latentes Qdrant, vollständig verwaltetes Pinecone, Hybrid-Champion Weaviate, großskaliges Milvus), hybride Suche, die BM25 + dichte Vektoren mit RRF verschmilzt, retrieve-then-rerank mit bi-encoder und dann cross-encoder (Cohere/Voyage/BGE/Jina), die Aufteilung LlamaIndex (Retrieval) vs. LangChain/LangGraph (Steuerung), warum ein 1M-Token-Fenster RAG nicht ersetzt (lost in the middle, Ablenkung) und Hinweise für den Produktivbetrieb wie zuerst eine Evaluations-Menge aufzubauen.