Jedes RAG-Tutorial endet bei denselben zwei Schritten: einbetten und abfragen. Sie zerlegen Ihre Dokumente in Chunks, speichern (id, embedding), starten eine Nearest-Neighbor-Suche, und die Demo funktioniert. Dann setzen Sie das System echten Nutzern vor, und es f\u00e4llt still auseinander. Der Vektor war nie der schwierige Teil. Was Sie daneben speichern, schon. Ein produktives Retrieval-System \u00fcber echte Dokumente trifft mindestens sieben Speicherentscheidungen, bevor es zuverl\u00e4ssig ist, und die Tutorial-Voreinstellung w\u00e4hlt bei den meisten stillschweigend die falsche Seite. Das hier ist die Checkliste: was neben die Embeddings geh\u00f6rt, und welcher Trade-off hinter jeder Entscheidung steckt.<\/p>\n\n\n\n
Die unbequeme Wahrheit: “einbetten und abfragen” ist kein Startpunkt, den Sie sp\u00e4ter verbessern. Es ist eine Entscheidung, von der Sie nicht wussten, dass Sie sie treffen. Sobald echte Skalierung, echte Berechtigungen und echte Compliance ins Spiel kommen, \u00e4ndert sich alles.<\/p>\n\n\n\n
Eine v1, die nur (id, embedding) speichert, findet Nearest Neighbors und liefert deren IDs zur\u00fcck. Mehr nicht. Ein LLM kann keinen 768-dimensionalen Float-Vektor lesen. Es braucht den eigentlichen Text, um einen Prompt zu bauen, und Sie brauchen genug Kontext um diesen Text herum, um einem Nutzer die Herkunft einer Antwort zu zeigen, ein Dokument sauber zu l\u00f6schen oder zwei Mandanten getrennt zu halten.<\/p>\n\n\n\n
Der Datensatz, den ein produktives System speichert, sieht eher so aus:<\/p>\n\n\n\n
chunk = {
“embedding”: embed(text),
“text”: text, # das LLM liest Text, keine Vektoren
“doc_id”: “arxiv2205.14135”, # ein ganzes Dokument auf einmal aktualisieren oder loeschen
“source_uri”: “https:\/\/…”, # dem Nutzer die Herkunft zeigen
“page”: 4,
“content_hash”: sha256(text), # unveraenderte Chunks nicht neu einbetten
“embed_model”: “bge-large-v1.5”, # Vektorraeume nie mischen
“visibility”: “public”, # wer das sehen darf
}<\/p>\n\n\n\n
Jedes Feld verdient seinen Platz. doc_id<\/strong> ist wichtig, weil Dokumente \u00fcberarbeitet und zur\u00fcckgezogen werden. Ohne sie m\u00fcssten Sie den gesamten Index durchsuchen, um alle Chunks eines Papers zu finden. content_hash<\/strong> l\u00f6st ein Kostenproblem: Zehntausende Chunks erneut gegen eine kostenpflichtige API einzubetten kostet Geld und Zeit. Ein Hash pr\u00fcft, ob sich ein Chunk \u00fcberhaupt ge\u00e4ndert hat, bevor Sie f\u00fcr die Neuberechnung zahlen. embed_model<\/strong> verhindert einen subtileren Fehler: Ein neueres Embedding-Modell ver\u00e4ndert den Vektorraum komplett. Alte und neue Vektoren sind dann nicht mehr vergleichbar, selbst bei gleicher Dimension, und ein Mix verschlechtert jede Suche, ganz ohne Fehlermeldung. visibility<\/strong> sorgt daf\u00fcr, dass ein einziger Index \u00f6ffentliche und private Dokumente oder mehrere Mandanten bedient, ohne dass Sie einen zweiten aufsetzen.<\/p>\n\n\n\n Stellen Sie sich ein blo\u00dfes Embedding als Garderobenmarke vor, auf der nur eine Nummer steht. Die Nummer passt schnell und l\u00fcgt nie, aber sie verr\u00e4t nicht, wie der Mantel aussieht, wem er geh\u00f6rt oder ob er \u00fcberhaupt ins Haus darf. Jedes Feld oben ist etwas, das auf die Marke geschrieben wird, damit Sie nach dem Treffer tats\u00e4chlich etwas Brauchbares in der Hand haben.<\/p>\n\n\n\n Hier steckt eine zweite Entscheidung. Kopieren Sie diese Metadaten in jeden Chunk, oder halten Sie sie einmal in einer separaten Tabelle? Kopieren bedeutet: Ein Lesezugriff verl\u00e4sst den Chunk nie, keine Joins, keine zus\u00e4tzlichen Roundtrips, was z\u00e4hlt, wenn Lesezugriffe die Schreibzugriffe weit \u00fcbertreffen. Der Preis f\u00e4llt an, sobald sich Metadaten \u00e4ndern: Die visibility eines Dokuments umzustellen hei\u00dft, jeden zugeh\u00f6rigen Chunk zu aktualisieren, manchmal Tausende Zeilen. Halten Sie die Metadaten normalisiert an einer Stelle, dreht sich der Trade um. Updates werden zu einem einzigen Schreibvorgang, aber jeder Lesezugriff zahlt jetzt einen Join. Keine Variante ist im luftleeren Raum richtig. Die Antwort h\u00e4ngt davon ab, wie oft sich Ihre Metadaten \u00e4ndern und wie oft Sie lesen.<\/p>\n\n\n\n Eine Bin\u00e4rdatei als Base64 zu kodieren bl\u00e4ht sie um rund ein Drittel auf. Diesen String direkt in einen Chunk-Datensatz zu legen bedeutet, dass jeder Lesezugriff \u2014 auch einer, der nur den Vektor f\u00fcr einen \u00c4hnlichkeitsvergleich braucht \u2014 Kilobyte an Bilddaten mitladen muss, die er gar nicht ben\u00f6tigt. Im gro\u00dfen Ma\u00dfstab bl\u00e4ht das den Speicherbedarf der In-Memory-Indexstrukturen auf und verlangsamt jede Abfrage, nicht nur die mit Bildbezug.<\/p>\n\n\n\n Speichern Sie stattdessen einen Pointer:<\/p>\n\n\n\n figure = { Ein Vektorindex ist f\u00fcr schnelle, leichtgewichtige Lookups gebaut, nicht zum Herumschleppen schwerer Dateien. Ein ganzes Bild hineinzuzw\u00e4ngen ist, als sch\u00f6ben Sie ein Sofa durch einen Briefkastenschlitz: Es blockiert alles andere. Ein Pointer, w\u00e4hrend die Datei im Object Storage liegt, h\u00e4lt den Index f\u00fcr jede Abfrage schnell, und der gro\u00dfe Blob wird nur geholt, wenn er wirklich gebraucht wird.<\/p>\n\n\n\n Dense Embeddings sind eine starke und zugleich enge Voreinstellung. Drei verbreitete Abfragetypen hebeln sie komplett aus, und jeder braucht einen eigenen Index neben den Vektoren.<\/p>\n\n\n\n Ein Modell wie CLIP legt ein Bild und seine Bildunterschrift nah beieinander in einem gemeinsamen Raum ab, was einen einzigen Index m\u00f6glich macht. Sein Textverst\u00e4ndnis ist aber schw\u00e4cher als das eines reinen Textmodells, weil es beim Training zwischen zwei Modalit\u00e4ten Kompromisse eingeht. Trennen Sie in Indizes pro Modalit\u00e4t, bekommen Sie f\u00fcr jeden Typ das beste Modell, aber ein Cosine-Score aus einem Textmodell und einer aus CLIP liegen nicht auf derselben Skala. Sie k\u00f6nnen beide Listen nicht per Rohwert sortieren. Reciprocal Rank Fusion umgeht das, indem es die Scores wegwirft und stattdessen \u00fcber die Rangposition fusioniert:<\/p>\n\n\n\n def rrf(rank, c=60): return 1 \/ (c + rank)<\/p>\n\n\n\n Die Rangposition ist \u00fcber Systeme hinweg vergleichbar, auch wenn es die Zahlen darunter nicht sind.<\/p>\n\n\n\n Fragen Sie “Was hat FlashAttention verbessert?”, scheitert reine \u00c4hnlichkeitssuche. Ein Paper, das ein anderes verbessert, beschreibt meist einen anderen Mechanismus mit anderen Worten. Es teilt vielleicht ein, zwei S\u00e4tze Vokabular mit dem Original. Es antwortet auf dieses Paper, indem es zitiert, nicht indem es wiederholt. \u00c4hnlichkeitssuche beurteilt Verwandtschaft \u00fcber Vokabelvergleich, so wie man die N\u00e4he zweier Wissenschaftler an gemeinsamen W\u00f6rtern misst. Zwei Rivalen, die seit einem Jahrzehnt streiten, klingen fast gleich, w\u00e4hrend ein Fremder mit ein paar geteilten Begriffen genauso nah wirkt. Ein Zitationsgraph ist der Stammbaum: Er liest nicht, was Leute sagen, er verfolgt, wer tats\u00e4chlich mit wem spricht. Speichern Sie Entit\u00e4ten und Zitationskanten neben Ihren Chunks und rufen Sie in zwei Stufen ab. Die Vektorsuche findet Ausgangsdokumente, die Graphtraversierung geht einen Schritt weiter und bringt Paper zutage, die eine \u00c4hnlichkeitssuche nie zur\u00fcckg\u00e4be.<\/p>\n\n\n\n Dense-Modelle zerlegen Text in Subword-Teile, und genau deshalb sind sie schlecht bei w\u00f6rtlichen Treffern. “FlashAttention-2” zerf\u00e4llt vielleicht in ein St\u00fcck, das wie “FlashAttention” aussieht, plus ein generisches Zahlentoken, sodass das Modell es als ungef\u00e4hr “irgendwas mit FlashAttention” darstellt statt als eigenst\u00e4ndige Einheit. Dasselbe trifft arXiv-IDs, Produktcodes und Funktionsnamen. Ein Keyword-Index mit BM25 wertet exakte Token-\u00dcberschneidung, sodass ein w\u00f6rtlicher Treffer auf “2205.14135” hoch rankt, gerade weil er exakt ist. Betreiben Sie ihn neben dem Dense-Index und fusionieren Sie die Ergebnisse.<\/p>\n\n\n\n Die meisten Speicher-Trade-offs sind Geschwindigkeit gegen Kosten. Zwei sind anders: Trifft man sie falsch, ist das System nicht langsam, sondern falsch oder nicht regelkonform.<\/p>\n\n\n\n Eine Vektordatenbank holt approximative Nearest Neighbors und wendet, nur auf Anfrage, danach einen Berechtigungsfilter auf das bereits Zur\u00fcckgegebene an. Durchsuchen Sie die Top 8 ohne Kenntnis der Berechtigungen, k\u00f6nnen alle 8 legitim Dokumente sein, die der Nutzer nicht sehen darf. Ein Filter im Nachhinein liefert dann nichts, obwohl weiter unten in einer nie zur\u00fcckgegebenen Liste reichlich \u00f6ffentliche Treffer stehen. Ziehen Sie die Berechtigungspr\u00fcfung in die Suche hinein, betrachtet der Algorithmus nur Kandidaten, die der Nutzer sehen darf:<\/p>\n\n\n\n index.search(embed(q), k=8, filter={“visibility”: {“$in”: user_groups}})<\/p>\n\n\n\n Die meisten produktiven Vektordatenbanken bieten das als nativen Filter-Parameter. Es lohnt sich, das ausdr\u00fccklich zu pr\u00fcfen, denn der Unterschied ist keine Performance-Feinheit. Er ist der Unterschied zwischen einem korrekten und einem leeren Ergebnis. Nachtr\u00e4gliches Filtern ist ein Club, der alle durch die T\u00fcr l\u00e4sst und die Tickets erst drinnen kontrolliert: Bis dahin ist der Raum voller falscher Leute, und die geladenen G\u00e4ste stehen drau\u00dfen. Vorfiltern ist der T\u00fcrsteher an der T\u00fcr.<\/p>\n\n\n\n Ein Hard Delete entfernt die Zeile und irgendwann ihren Vektor, was Sie bei Wegwerf- oder Cache-Daten wollen, aber es bleibt kein Nachweis, wenn sp\u00e4ter jemand fragt, warum etwas fehlt oder wer es entfernt hat. Ein Soft Delete setzt einen deleted_at-Zeitstempel und l\u00e4sst die Zeile stehen, wodurch jede Abfrage einen zus\u00e4tzlichen Filter tr\u00e4gt, um tote Daten nicht anzuzeigen \u2014 eine kleine, dauerhafte Steuer. F\u00fcr alles, was Compliance, gesetzliche Aufbewahrungspflichten oder DSGVO-L\u00f6schkonzepte ber\u00fchrt, ist diese Steuer es wert. F\u00fcr Logs, die niemand pr\u00fcft, ist sie reiner Overhead.<\/p>\n\n\n\n Legt man die sieben Entscheidungen \u00fcbereinander, zeigt sich ein Muster. Ein produktives Retrieval-System ist keine einzelne Suchbox, sondern vier zusammenspielende Schichten:<\/p>\n\n\n\n Query Keine davon ist jenseits einer Demo optional. Die Vektorschicht beantwortet “Was ist dem hier \u00e4hnlich”. Die Graphschicht beantwortet “Was ist mit dem hier verbunden”, was \u00c4hnlichkeit strukturell nicht kann, egal wie gut das Embedding-Modell wird. Der Object Storage h\u00e4lt gro\u00dfe Dateien aus dem hei\u00dfen Pfad. Die eigentliche Aufgabe des Orchestrators ist die Entscheidung, pro Abfrage, welche Schichten zu befragen sind und wie das Zur\u00fcckkommende zusammengef\u00fchrt wird. Behandeln Sie das als eine Suchbox statt als vier Systeme, und genau hier bricht die Architektur mit wachsender Skalierung leise.<\/p>\n\n\n\n Das ist exakt die L\u00fccke zwischen einer Retrieval-Demo und einem Retrieval-Produkt, und sie ist nicht auf RAG beschr\u00e4nkt. Hier bleiben die meisten KI-Projekte stecken. GoTeams vertritt eine bewusst enge Haltung zu KI: KI generiert schnell Code, aber LLMs liefern Snippets, keine Systeme, und MVPs, die allein mit KI gebaut sind, skalieren selten. Die Arbeit, die ein Notebook mit plausiblen Antworten von einem System mit korrekten, berechtigten, pr\u00fcfbaren Antworten trennt, ist Orchestrierung, und Orchestrierung ist eine menschliche Disziplin, keine Modellf\u00e4higkeit.<\/p>\n\n\n\n Genau daf\u00fcr ist ein KI-orchestriertes Entwicklungsteam gebaut. Zennify<\/strong> (KI und Kommunikation, 17-k\u00f6pfiges Team) ist ein laufendes Beispiel: eine Contact-Center-Plattform, erweitert zu einem Framework f\u00fcr KI-Assistenten, mit LLM-Orchestrierung, Sprachdiensten und Twilio-Integration hinter \u00fcber 200 Konfigurationsoptionen. Sie ist heute europ\u00e4ischer Marktf\u00fchrer und bedient Kunden wie Nestl\u00e9 und FlixBus. Der Unterschied zu einem stecken gebliebenen Pilotprojekt war nie das Modell. Es waren die Schichten darum herum und das Team, das wusste, welche Entscheidungen zu treffen sind.<\/p>\n\n\n\n Speichern Sie den Quelltext, nicht nur den Vektor, denn ein LLM liest Text und keinen Float-Vektor. Erg\u00e4nzen Sie eine Dokument-ID, um ein ganzes Dokument auf einmal zu aktualisieren oder zu l\u00f6schen, eine Source-URI, um Nutzern die Herkunft einer Antwort zu zeigen, einen Content-Hash, um unver\u00e4nderte Chunks nicht neu einzubetten, den Namen des verwendeten Embedding-Modells und ein visibility-Feld f\u00fcr Berechtigungen. Der Vektor findet den Treffer. Alles, was daneben liegt, macht den Treffer brauchbar, korrekt und sicher auslieferbar.<\/p>\n\n\n\n Dense Embeddings treffen auf semantische \u00c4hnlichkeit, das falsche Werkzeug f\u00fcr drei Abfragetypen. Exakte Zeichenketten wie eine arXiv-ID oder ein Funktionsname werden in Subword-Teile zerlegt und verlieren ihre Identit\u00e4t \u2014 sie brauchen einen Keyword-Index mit BM25. Beziehungsfragen wie “Was hat X verbessert” scheitern, weil die Antwort X zitiert statt seine Worte zu wiederholen \u2014 sie brauchen einen Zitationsgraphen. Und Scores verschiedener Embedding-Modelle sind nicht vergleichbar, multimodale Suche braucht daher Rang-Fusion statt Rohwert-Sortierung. Produktive Systeme betreiben diese Indizes gemeinsam und fusionieren die Ergebnisse.<\/p>\n\n\n\n Vorfilterung wendet den Berechtigungsfilter innerhalb der Suche an, sodass der Algorithmus nur Kandidaten rankt, die der Nutzer sehen darf. Nachfilterung sucht zuerst und entfernt verbotene Treffer danach, was ein leeres Ergebnis liefern kann, obwohl weiter unten g\u00fcltige Treffer stehen, weil die Suche nur eine kleine Top-k zur\u00fcckgab, die zuf\u00e4llig komplett privat war. F\u00fcr jedes System mit Berechtigungen oder mehreren Mandanten ist Vorfilterung keine Optimierung. Sie ist der Unterschied zwischen einem korrekten und einem falschen Ergebnis. Die meisten produktiven Vektordatenbanken bieten sie als Filter-Parameter.<\/p>\n\n\n\n Weil “einbetten und abfragen” eine Entscheidung ist, keine Voreinstellung, und bei den meisten Produktions-Trade-offs still die falsche Seite w\u00e4hlt. Eine Demo hat keine Berechtigungen, keine Mandantentrennung, keine Compliance-Anforderung, keine Exact-Match- und keine Beziehungsabfragen, also wirkt ein blo\u00dfer Vektorindex ausreichend. Echter Betrieb bringt alle f\u00fcnf auf einmal. Die L\u00f6sung ist kein besseres Modell. Es sind die vier Schichten aus Vektor, Graph, Object Storage und Orchestrator, plus die Disziplin, jeden Speicher-Trade-off bewusst zu entscheiden. An dieser Orchestrierung bleiben KI-Projekte am h\u00e4ufigsten h\u00e4ngen.<\/p>\n\n\n\n Es gibt keine allgemeing\u00fcltig richtige Antwort, nur den Trade in die richtige Richtung f\u00fcr Ihr System. Jede Entscheidung hat dieselbe Form: jetzt Aufwand investieren, beim Schreiben oder bei der Ingestion, um sp\u00e4ter beim Abfragen zu sparen, oder umgekehrt. Content-Hashing gibt Speicher aus, um Rechenzeit zu sparen. Metadaten zu kopieren gibt Schreibkosten aus, um Leselatenz zu sparen. Ein Zitationsgraph gibt Ingestion-Komplexit\u00e4t aus, um Fragen zu beantworten, die \u00c4hnlichkeit nicht kann. Messen Sie zuerst Ihr tats\u00e4chliches Lese-Schreib-Verh\u00e4ltnis, Ihre Abfragetypen und Ihre Compliance-Anforderungen. Ein Setup, das bei 1000:1 offensichtlich richtig ist, kann f\u00fcr ein st\u00e4ndig neu einlesendes System genauso offensichtlich falsch sein.<\/p>\n\n\n\n Bauen Sie eine Wegwerf-Demo \u00fcber eine Handvoll \u00f6ffentlicher Dokumente, reicht einbetten und abfragen, und alles oben ist Overhead, den Sie noch nicht brauchen.<\/em> Doch sobald echte Nutzer, echte Berechtigungen und echte Skalierung dazukommen, ist die Tutorial-Voreinstellung kein Startpunkt mehr, sondern eine Reihe stiller Entscheidungen, die gegen Sie arbeiten. Ein produktives Retrieval-System speichert weit mehr als Vektoren: Text, Identifikatoren, Hashes, Modellnamen, Berechtigungen, Pointer, Graphkanten und einen Keyword-Index \u2014 jede davon ein bewusst gew\u00e4hlter Trade. Kennen Sie Ihr Lese-Schreib-Verh\u00e4ltnis, Ihre Abfragetypen und Ihre Compliance-Anforderungen. Dann zahlen Sie in der W\u00e4hrung, die Sie sich leisten k\u00f6nnen.<\/p>\n\n\n\n Die L\u00fccke zwischen einer Retrieval-Demo und einem Retrieval-Produkt ist Orchestrierung, und Orchestrierung ist eine menschliche Disziplin. Genau das liefert ein KI-orchestriertes Entwicklungsteam<\/strong>: Entwickler, die wissen, welche dieser Entscheidungen in welche Richtung zu treffen sind, f\u00fcr das System, das Sie tats\u00e4chlich bauen, und die es so ausliefern, dass es mit der Skalierung korrekt bleibt. Das ist der Unterschied zwischen einem Pilotprojekt, das beeindruckt, und einem Produkt, das bleibt.<\/p>\n","protected":false},"excerpt":{"rendered":" Jedes RAG-Tutorial endet bei denselben zwei Schritten: einbetten und abfragen. Sie zerlegen Ihre Dokumente in Chunks, speichern (id, embedding), starten eine Nearest-Neighbor-Suche, und die Demo funktioniert. Dann setzen Sie das System echten Nutzern vor, und es f\u00e4llt still auseinander. Der Vektor war nie der schwierige Teil. Was Sie daneben speichern, schon. Ein produktives Retrieval-System \u00fcber […]<\/p>\n","protected":false},"author":15,"featured_media":368,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[22,26],"tags":[166,160,162,164,168],"class_list":["post-370","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-engineering-de","category-ai-de","tag-hybrid-suche-bm25","tag-rag-in-produktion","tag-vektordatenbank-metadaten","tag-vorfilterung-vektorsuche","tag-zitationsgraph-rag"],"yoast_head":"\n2. Gro\u00dfe Dateien geh\u00f6ren nicht in den hei\u00dfen Pfad<\/strong><\/h2>\n\n\n\n
“embedding”: clip_embed(image),
“caption”: “Figure 2: memory hierarchy”,
“modality”: “image”,
“media_uri”: “s3:\/\/blob\/2205.14135\/fig2.png”, # ein Pointer, nicht die Datei
}<\/p>\n\n\n\n3. Wo \u00c4hnlichkeitssuche strukturell nicht weiterhilft<\/strong><\/h2>\n\n\n\n
Verschiedene Modalit\u00e4ten brauchen Rang-Fusion, keinen Score-Vergleich<\/strong><\/h3>\n\n\n\n
Beziehungen leben in einem Graphen, nicht in Wort\u00fcberschneidung<\/strong><\/h3>\n\n\n\n
Exakte Zeichenketten brauchen Keyword-Suche<\/strong><\/h3>\n\n\n\n
4. Die Entscheidungen, bei denen “falsch” schlimmer ist als “langsam”<\/strong><\/h2>\n\n\n\n
Berechtigungen w\u00e4hrend der Suche filtern, nie danach<\/strong><\/h3>\n\n\n\n
L\u00f6schen: f\u00fcr immer weg, oder als gel\u00f6scht markiert<\/strong><\/h3>\n\n\n\n
5. Vier Schichten, ein Orchestrator: die L\u00fccke vom PoC zur Produktion<\/strong><\/h2>\n\n\n\n
|
Orchestrator (fusionieren + reranken)
|
Vektorschicht: Text- \/ Bild- \/ Keyword-Indizes + Berechtigungsfilter
|
Graphschicht: Entitaeten + Zitationen
|
Object Storage: Rohdateien, ueber Pointer<\/p>\n\n\n\nH\u00e4ufig gestellte Fragen<\/strong><\/h2>\n\n\n\n
Was speichert man in einem RAG-System neben den Embeddings?<\/strong><\/h3>\n\n\n\n
Warum scheitert reine \u00c4hnlichkeitssuche bei manchen Abfragen?<\/strong><\/h3>\n\n\n\n
Was ist der Unterschied zwischen Vor- und Nachfilterung in der Vektorsuche?<\/strong><\/h3>\n\n\n\n
Warum funktionieren so viele RAG-Systeme als Demo, aber nicht in Produktion?<\/strong><\/h3>\n\n\n\n
Wie entscheidet man, welcher RAG-Speicher-Trade-off richtig ist?<\/strong><\/h3>\n\n\n\n
Das Fazit<\/strong><\/h2>\n\n\n\n