Erfahren Sie, was eine Vektordatenbank ist, wie Embeddings Ähnlichkeitssuche ermöglichen und wann Sie pgvector, Pinecone oder Weaviate für KI‑Suche und RAG wählen sollten.
Eine Vektordatenbank ist ein System, das entwickelt wurde, um Embeddings zu speichern und zu durchsuchen — Zahlenlisten, die die „Bedeutung“ von Texten, Bildern oder anderen Daten repräsentieren. Statt zu fragen: „Enthält dieser Datensatz das genaue Wort Rückerstattung?“, fragt man: „Welche Datensätze sind am ähnlichsten zu dieser Frage?“ und erhält die nächstgelegenen Treffer.
Stellen Sie sich vor, jedes Dokument (oder Produkt, Ticket, FAQ) wird zu einem Punkt auf einer Landkarte. Items zum selben Thema landen nah beieinander — selbst wenn sie unterschiedliche Wörter verwenden. Eine Vektordatenbank beantwortet schnell die Frage: Was ist diesem neuen Punkt am nächsten?
Traditionelle SQL‑Datenbanken sind großartig, wenn Sie die Struktur Ihrer Frage kennen: filtern nach Datum, user_id, Status usw. Keyword‑Suche ist gut, wenn die richtige Antwort wörtlich die gleichen Worte enthält, die Sie eingeben.
Vektordatenbanken sind anders, weil sie auf semantische Ähnlichkeit abzielen. Sie sind dafür gebaut, Anfragen wie „Wie bekomme ich mein Geld zurück?“ zu verarbeiten und Inhalte zu finden, die „Unsere Rückerstattungsrichtlinie…“ sagen, ohne die exakt gleiche Formulierung zu benötigen.
Das ersetzt weder SQL noch Keyword‑Suche. In vielen Systemen verwenden Sie beide: SQL/Filter für Geschäftsregeln (Region, Berechtigungen, Aktualität) und Vektorsuche für „Bedeutung“.
Wenn Sie sich eine Zeile merken: Eine Vektordatenbank ist eine „ähnlichste Elemente“-Engine für Embeddings, optimiert für schnelle Suche in großem Maßstab.
Vektordatenbanken funktionieren, weil Embeddings es erlauben, Bedeutung numerisch zu vergleichen. Sie lesen die Zahlen nicht; Sie nutzen sie, um zu bewerten, „wie nah“ zwei Inhalte beieinander liegen.
Ein Embedding ist eine Liste von Zahlen (oft hunderte oder tausende Dimensionen), die ein Stück Inhalt repräsentiert. Jede Zahl erfasst einen Aspekt der Bedeutung, den ein ML‑Modell gelernt hat. Die einzelnen Zahlen werden nicht direkt interpretiert; wichtig ist, dass ähnliche Inhalte ähnliche Zahlenmuster erzeugen.
Denken Sie daran wie Koordinaten auf einer sehr hochdimensionalen Karte: Sätze über „Rückerstattungsrichtlinie“ und „ein Produkt zurückgeben“ landen nahe beieinander, auch wenn sie unterschiedliche Wörter verwenden.
Verschiedene Embedding‑Modelle wandeln verschiedene Medien in Vektoren um:
Sobald alles Vektoren ist, kann Ihre Datenbank große Sammlungen mit derselben Kernoperation durchsuchen: „Finde die nächsten Vektoren.“
Um zu entscheiden, was „am nächsten“ ist, nutzen Systeme einfache Bewertungsregeln:
Sie müssen diese nicht manuell berechnen — wichtig ist: höhere Scores bedeuten „ähnlicher“.
Die meisten Verbesserungen bei der Suche kommen durch bessere Embeddings und besseres Chunking, nicht durch den Datenbankwechsel. Wenn Ihr Modell die Domain‑Sprache nicht erfasst (Produktnamen, interne Begriffe, juristische Formulierungen), kann auch der beste Vektorindex nur die „am nächsten liegenden falschen Antworten“ zurückgeben. Die Wahl zwischen pgvector, Pinecone und Weaviate ist relevant, aber die Auswahl des richtigen Embedding‑Modells und des Eingabeformats ist meist wichtiger.
Keyword‑Suche, SQL‑Abfragen und Vektorsuche lösen unterschiedliche Probleme — Verwechslungen führen oft zu enttäuschenden Ergebnissen.
Traditionelle Suche (Elasticsearch, Postgres Full‑Text etc.) matcht Wörter und Phrasen. Sie ist hervorragend, wenn Nutzer wissen, was sie tippen müssen und das Dokument diese Begriffe enthält.
Sie hat Probleme bei:
Eine Vektordatenbank speichert Embeddings — numerische Repräsentationen der Bedeutung. Auch Anfragen werden eingebettet, und Ergebnisse werden nach Ähnlichkeit gerankt, sodass Sie konzeptuell verwandte Inhalte abrufen können, selbst wenn die exakten Wörter nicht übereinstimmen. Deshalb ist Vektorsuche beliebt für semantische Suche und RAG.
SQL ist das richtige Werkzeug für:
Vektoren sind schlecht geeignet, wenn Präzision unverhandelbar ist (z. B. „Bestellungen für customer_id = 123").
Auch bei semantischer Suche brauchen Sie klassische Filter — Preisspannen, Daten, Sprache, Kategorie und Berechtigungen. Die meisten echten Systeme arbeiten hybrid: zuerst SQL/Metadatenfilter, dann Vektor‑Similarity‑Ranking innerhalb der erlaubten Menge.
Wenn Sie Daten in einer Vektordatenbank speichern, wird jedes Item zu einer langen Zahlenliste (ein Embedding). Suchen bedeutet dann: „Finde die Vektoren, die diesem Query‑Vektor am nächsten sind.“
Eine reale Datenbank kann Millionen von Vektoren enthalten. Jeden Vektor einzeln zu vergleichen wäre zu langsam und zu teuer. Deshalb bauen Vektordatenbanken einen Index — eine Struktur, die hilft, die Kandidaten schnell einzugrenzen, sodass das System Entfernungen nur für eine kleine Untermenge messen muss.
Die meisten Vektorsuchen nutzen approximate nearest neighbor (ANN). „Approximate“ bedeutet, das System versucht, sehr gute Treffer schnell zu finden, anstatt jedes Mal mathematisch perfekte Top‑Ergebnisse zu garantieren.
Eine nützliche Analogie: Statt jedes Buch in einer Bibliothek zu prüfen, nutzt ANN eine smarte Karte, die Sie zuerst zu den richtigen Regalen führt.
Dieser Trade‑off wird meist mit Einstellungen wie „wie gründlich soll der Index suchen?“ feinjustiert:
Praktisch ist Recall die Frage, wie oft die Ergebnisse das enthalten, was ein Mensch als richtige Antworten ansehen würde. Für RAG reduziert höherer Recall oft fehlende Schlüsselfakten (kostet aber mehr).
Unterschiedliche Produkte (pgvector, Pinecone, Weaviate) setzen diese Konzepte mit verschiedenen Defaults und Einstellmöglichkeiten um, aber das Ziel ist dasselbe: schnelle Ähnlichkeitssuche mit kontrollierbarer Genauigkeit.
Der Workflow ist meist eine Schleife „speichere Dinge, dann rufe die besten Treffer ab“. Wichtig ist, Bedeutung (Embeddings) zusammen mit dem Originalinhalt zu speichern, damit die Suche Ideen und nicht nur exakte Worte abgleicht.
Sie beginnen damit, Dokumente (Seiten, PDFs, Tickets, Produktbeschreibungen usw.) zu sammeln, in Chunks zu teilen und ein Embedding für jeden Chunk zu generieren.
In der Datenbank speichern Sie typischerweise:
Zur Suchzeit betten Sie die Nutzeranfrage ein und fragen nach den nächsten Vektoren.
Viele Teams mischen Vektorähnlichkeit mit Keyword‑Scoring (BM25‑ähnlich), sodass Sie semantische Treffer und exakte Terme wie SKU‑Codes, Namen oder Fehlermeldungen belohnen.
Vor oder während der Retrieval‑Phase wenden Sie Metadatenfilter an — besonders bei Multi‑Tenant‑Apps und Berechtigungen. Filter helfen auch der Präzision (z. B. „nur letzte 90 Tage“, „nur im Hilfezentrum").
Ein verbreitetes Muster: schnell Top 50–200 abrufen, dann die Top 10–20 mit einem stärkeren Modell oder Regeln neu sortieren (Freshness‑Boosts, Quellpriorität).
Für RAG nehmen Sie die finalen Top‑Chunks und schicken sie als Kontext in ein LLM‑Prompt, oft mit Zitaten und der Anweisung „nicht antworten, wenn nichts gefunden wurde“. Das Ergebnis ist eine Antwort, die in Ihrem gespeicherten Inhalt verankert ist, nicht nur eine Vermutung des Modells.
Wenn Ihr Ziel ist, die Retrieval‑Qualität schnell zu validieren (statt Wochen mit Infrastruktur zu verbringen), kann eine Low‑code/No‑code‑Plattform wie Koder.ai helfen, ein End‑to‑End‑Proof‑of‑Concept für semantische Suche oder RAG aus einer Chat‑Oberfläche zu bauen. Praktisch heißt das: Sie können eine React‑UI, ein Go‑Backend und eine Postgres‑Datenbank (inkl. pgvector‑Ansatz) schnell aufsetzen, mit Planning‑Mode, Snapshots und Rollback iterieren — und den Quellcode exportieren, wenn Sie bereit sind.
pgvector ist eine PostgreSQL‑Erweiterung, mit der Sie Embedding‑Vektoren direkt in Ihrer bestehenden Datenbank speichern und durchsuchen können. Anstatt eine separate „Vektordatenbank“ zu betreiben, fügen Sie Ihrem Schema einen neuen Spaltentyp (vector) zu den Tabellen hinzu, die bereits Nutzer, Produkte, Dokumente und Metadaten enthalten.
pgvector ist ideal für Teams, die bereits auf Postgres gesetzt haben und weniger bewegliche Teile wollen. Wenn die Wahrheit Ihres Apps in Postgres liegt, kann das Speichern von Vektoren dort die Architektur vereinfachen: eine Backup‑Strategie, ein Zugriffsmodell, ein Ort für Migrationen und vertraute SQL‑Abfragen für Joins und Filter.
Der größte Gewinn liegt darin, strukturierte Daten und Vektoren zusammenzuhalten. Sie können semantische Suche durchführen und trotzdem „normale“ Constraints anwenden — wie tenant_id, Kategorie, Status oder Berechtigungen — ohne Ergebnisse über Systeme hinweg verknüpfen zu müssen. Operativ kann das Ausliefern einfacher sein: Ihre bestehende Postgres‑Instanz plus eine Erweiterung.
Hohe Vektor‑Workloads können Postgres an Bereiche bringen, für die es ursprünglich nicht optimiert war. Sie müssen Index‑Typen (häufig IVFFlat oder HNSW), Memory‑Einstellungen, Vacuum‑Verhalten und Abfragemuster bedenken.
Wenn Sie sehr große Embedding‑Sammlungen, starken parallelen Suchverkehr oder schnelles Wachstum erwarten, kann das Skalieren und Tuning deutlich aufwändiger werden als bei einem verwalteten Vektorservice. Für viele Teams ist pgvector aber die „einfach starten“-Option, die überraschend weit trägt.
Pinecone ist ein vollständig verwalteter Vektordatenbankdienst: Sie schicken Embeddings (Vektoren) plus IDs und Metadaten hin, und Pinecone liefert schnelle Ähnlichkeitssuche, wobei der operative Aufwand größtenteils von ihnen getragen wird.
Mit Pinecone müssen Sie in der Regel nicht selbst Maschinen bereitstellen, Low‑Level‑Index‑Einstellungen Tag für Tag abstimmen oder Ihre eigene Skalierungs‑ und Failover‑Story bauen. Sie interagieren per API, um Vektoren zu upserten, nach nächsten Nachbarn zu queryen und Ergebnisse nach Metadaten zu filtern (z. B. Sprache, Tenant, Dokumenttyp oder Zugriffsebene).
Pinecone ist eine starke Wahl, wenn Sie:
Teams wählen es oft, wenn die Kernfunktionalität auf hochwertigem Retrieval basiert und sie „Vector Search as a Service“ bevorzugen statt eines weiteren Systems, das gepflegt werden muss.
Pinecones größter Vorteil ist die Geschwindigkeit bis zur Produktion. Managed Scaling und Zuverlässigkeitsfeatures (je nach Plan) reduzieren Zeit für Kapazitätsplanung und Incident‑Response. Es integriert sich außerdem meist sauber in gängige AI‑Stacks für Suche und RAG.
Die Hauptnachteile sind potenzielle Vendor‑Lock‑in und laufende Nutzungs‑Kosten, die mit Query‑Volumen, Speicher und Durchsatz steigen können. Prüfen Sie außerdem Datenresidenz, Compliance‑Anforderungen und den Umgang mit sensiblen Daten, bevor Sie sich festlegen.
Weaviate ist eine Open‑Source Vektordatenbank, die ein voll ausgestattetes „AI‑Suchbackend“ mit einer GraphQL‑API bietet. Wenn Sie Kontrolle über Ihre Infrastruktur (oder Deployment in Ihrer Cloud) wollen, aber trotzdem eine produktähnliche Erfahrung — Schema, Filter, Indexierungsoptionen und Integrationen — wünschen, steht Weaviate oft auf der Shortlist.
Weaviate speichert Objekte (Ihre Dokumente, Produkte, Tickets usw.) zusammen mit Metadaten und Vektor‑Embeddings. Sie können semantisch abfragen („Finde Dinge wie dieses“) und gleichzeitig Filter anwenden („nur aus den letzten 30 Tagen“, „nur Kategorie = Support“). Die GraphQL‑API macht es zugänglicher für Teams, die ausdrucksstarke Abfragen ohne viele maßgeschneiderte Endpunkte möchten.
Weaviate passt oft zu Teams, die:
Vorteile: Starkes Schema/Metadaten‑Support, ein Feature‑reiches Ökosystem an Modulen/Integrationen und konfigurierbare Indexierungsansätze, mit denen Sie Performance feinjustieren können.
Nachteile: Wenn Sie es selbst betreiben, sind Sie verantwortlich für Betrieb — Upgrades, Skalierung, Monitoring, Backups und Incident‑Response. Mit zunehmender Modularität, Multi‑Tenancy und komplexeren Schemata kann das System schwerer zu durchschauen werden, wenn Sie nicht früh klare Konventionen setzen.
Wenn Sie Optionen vergleichen, sitzt Weaviate oft zwischen „einfaches Add‑on in Ihrer DB“ und „voll verwalteter Service“ und bietet Flexibilität zum Preis von operativer Verantwortung.
Die Auswahl einer Vektordatenbank ist weniger eine Frage von „besser“ als von Passung: wo Sie sie betreiben wollen, wie groß sie voraussichtlich wird, wie Ihre Abfragen aussehen und wie viel operativen Aufwand Ihr Team tragen kann.
pgvector bedeutet „Vektoren in Postgres“. Ideal, wenn Ihre App bereits auf Postgres läuft und Sie eine Datenbank für Geschäfts‑ und Embedding‑Daten bevorzugen.
Pinecone ist verwaltet. Sie tauschen Kontrolle gegen schnelle Adoption: weniger Knöpfe, weniger Infrastruktur‑Aufwand.
Weaviate ist Open‑Source und kann selbst gehostet oder als Managed‑Angebot genutzt werden. Gute Mittellösung, wenn Sie ein vektor‑natives System wollen, aber offene Tools bevorzugen.
Auf kleinem Maßstab funktionieren alle drei gut. Bei Wachstum fragen Sie:
Erwarten Sie schnelles Wachstum und hohen QPS, gewinnt oft Pinecone durch operative Einfachheit. Wenn Wachstum moderat ist und Sie Postgres schon in großem Maßstab betreiben, kann pgvector kosteneffizient sein.
Wenn Sie starke relationale Filter (Joins, komplexe Prädikate) neben Ähnlichkeitssuche brauchen, ist pgvector attraktiv.
Bei Bedarf an hybrider Suche (Keyword + semantisch), reichhaltigen Filtern oder starker Multi‑Tenant‑Isolation vergleichen Sie Pinecone und Weaviate Feature für Feature.
Seien Sie ehrlich zu Ihrer Teamkapazität für Backups, Monitoring, Upgrades und On‑Call. Managed reduziert die Last. Self‑Hosted kann günstiger sein, aber nur, wenn Ihr Team die nötigen Fähigkeiten und Zeit hat.
Gute Vektorsuche beginnt mit einer zuverlässigen, langweiligen Record‑Form. Behandeln Sie jede „durchsuchbare Einheit“ als Zeile/Objekt, die später gefetched, gefiltert und erklärt werden kann.
Speichern Sie mindestens:
So bleibt Retrieval einfach: Vektorsuche liefert IDs, dann holen Sie Chunk + Kontext, um Nutzern zu zeigen oder für RAG zu verwenden.
Chunking ist der größte Qualitätshebel, den Sie kontrollieren. Kleinere Chunks sind präziser, können aber Kontext verlieren; größere erhalten Kontext, verwässern aber das Signal.
Ein gängiger Startpunkt sind 200–400 Tokens mit 10–20% Overlap, dann an Inhalt anpassen. Für API‑Specs und rechtliche Texte funktionieren oft kleinere Chunks besser; für narrative Inhalte sind etwas größere Chunks nützlich.
Speichern Sie Metadaten, die Sie tatsächlich abfragen:
Vermeiden Sie riesige JSON‑Blobs; halten Sie häufig gefilterte Felder leicht indizierbar.
Embeddings sind nicht zeitlos. Tracken Sie embedding_model, model_version und chunking_version (plus created_at). Beim Modell‑Upgrade können Sie parallel neu einbetten und schrittweise den Traffic umschalten, ohne inkompatible Vektoren zu mischen.
Vektorsuche kann in Demos „sofort“ wirken und dann in Produktion langsamer oder teurer werden. Die gute Nachricht: die Haupttreiber sind vorhersehbar, und Sie können sie sowohl mit pgvector, Pinecone als auch Weaviate steuern.
Die meisten Teams unterschätzen die nicht‑Such Teile.
Bessere Ähnlichkeitssuche bedeutet nicht automatisch bessere Antworten.
Erstellen Sie ein kleines Testsatz: 30–100 reale Anfragen, jeweils mit einigen „guten“ erwarteten Ergebnissen. Messen Sie Relevanz (Hit‑Rate in Top‑k) und verfolgen Sie Änderungen beim Anpassen von Chunking, Indexen oder Prompts.
Behandeln Sie Embeddings als potenziell sensibel.
Vektorsuche‑Qualität hängt nicht nur von Indexen ab — auch davon, wie Sie das System täglich betreiben. Ein paar Governance‑Gewohnheiten verhindern „mysteriöse Ergebnisse“ und erleichtern Audits enorm.
Wenn Ihre Dokumente sensible Daten enthalten, überlegen Sie, den Rohinhalt in Ihrem primären Datastore (Objektspeicher, Datenbank, DMS) zu lassen und nur zu speichern:
Das reduziert die Angriffsfläche, falls der Vektorstore kompromittiert wird, und vereinfacht Zugriffskontrollen. Es hilft auch, wenn Sie mehrere Backends nutzen (z. B. pgvector intern, Pinecone für ein öffentliches Feature).
Embeddings können alte Texte „behalten“, wenn Sie diese nicht bereinigen.
Loggen Sie genug, um Relevanz zu debuggen, aber keine Geheimnisse:
So werden Drift und Regressionen nach Modell‑ oder Datenänderungen sichtbar.
Planen Sie Aufbewahrung (wie lange Vektoren und Logs leben), Verschlüsselung in Transit/at‑rest und Audit‑Anforderungen (wer hat wann gesucht). In regulierten Umgebungen dokumentieren Sie Datenflüsse und Zugriffspfade, damit Reviews Releases nicht blockieren.
Selbst eine solide Vektor‑Datenbank kann enttäuschen, wenn ein paar häufige Fehler passieren. Hier die typischen Probleme — und wie Sie sie früh vermeiden.
Vektoren sind großartig für „Bedeutung“, nicht für harte Constraints. Wenn Sie semantische Suche als alleiniges Werkzeug nutzen, können Ergebnisse zufällig oder unsicher wirken.
Vermeiden Sie das: kombinieren Sie Ähnlichkeitssuche mit strukturierten Filtern (tenant_id, Produktkategorie, Sprache, Datum). Behandeln Sie Metadatenfilter als integralen Teil des Query‑Designs.
Eine Demo mit ein paar Prompts kann erhebliche Recall‑ und Relevanzprobleme verbergen.
Vermeiden Sie das: bauen Sie ein kleines Evaluationsset mit realen Anfragen und „guten“ Zielen. Verfolgen Sie einfache Metriken (Top‑k‑Relevanz, Klickrate, menschliche Bewertungen). Führen Sie Evaluierungen nach Änderungen an Embeddings, Chunking oder Indexeinstellungen durch.
Embedding‑Modelle entwickeln sich. Ein Wechsel des Modells (oder einer Version) verändert den Vektorraum und kann Retrieval still verschlechtern.
Vermeiden Sie das: speichern Sie ein embedding_model‑Feld und behandeln Embeddings als versionierte Artefakte. Halten Sie eine Re‑Embedding‑Pipeline bereit und planen Sie Backfills (inkrementell, wenn Kosten eine Rolle spielen; zuerst meist am häufigsten genutzte Inhalte).
Wenn Ihre App Zugriffskontrollen hat, muss Retrieval das respektieren — sonst können eingeschränkte Inhalte auftauchen.
Vermeiden Sie das: erzwingen Sie Berechtigungen im Retrieval‑Schritt mittels per‑Tenant‑Indexen, Metadatenfilter oder voraggregierten ACL‑Feldern. Testen Sie das: „Nutzer A darf niemals Dokumente von Nutzer B abrufen“, auch nicht in Top‑k‑Kandidaten.
Eine Vektordatenbank ist ein System, das Embeddings (numerische Repräsentationen von Text, Bildern oder anderen Daten) speichert und die ähnlichsten Items schnell abruft. Sie ist besonders geeignet, wenn Nutzer nach Bedeutung suchen (semantische Suche) oder wenn Sie RAG bauen, damit ein KI‑Assistent relevante Passagen aus Ihrem eigenen Inhalt ziehen kann, bevor er antwortet.
Praktische Faustregeln:
Bauen Sie in einem Tag ein kleines Proof‑of‑Concept:
Wenn Sie mehr Implementierungs‑ oder Kosten‑Guidance möchten, siehe /blog. Für Preisüberlegungen oder gehostete Optionen schauen Sie bitte /pricing.
Eine Vektordatenbank speichert und durchsucht Embeddings (Vektoren: lange Zahlenlisten), die die Bedeutung von Texten, Bildern oder anderen Daten repräsentieren. Anstatt exakt nach gleichen Wörtern zu suchen, liefert sie die Elemente, die im semantischen Raum einer Abfrage am ähnlichsten sind — nützlich, wenn Nutzer die gleiche Absicht unterschiedlich formulieren.
Ein Embedding ist ein numerischer „Fingerabdruck“ von Inhalten, erzeugt von einem ML‑Modell. Man interpretiert nicht jede einzelne Zahl; stattdessen nutzt man den gesamten Vektor zum Vergleichen. Ähnliche Inhalte (z. B. „Rückerstattungsrichtlinie“ und „ein Produkt zurückgeben“) landen nahe beieinander und ermöglichen semantische Suche.
Keyword‑Suche findet Wörter und Phrasen (gut für exakte Begriffe). Vektorsuche findet Bedeutung (gut für Synonyme und Paraphrasen). In der Praxis verwenden Teams oft hybride Suche:
SQL ist am besten für strukturierte, exakte Fragen: IDs, Joins, Aggregationen und strikte Filter. Vektorsuche ist ideal für unscharfe „Finde ähnliches“-Fragen. Ein gängiges Muster ist:
Die meisten Systeme verwenden Approximate Nearest Neighbor (ANN) Indizes. Statt den Query‑Vektor mit jedem gespeicherten Vektor zu vergleichen, reduziert der Index die Kandidatenmenge, sodass nur eine kleine Untermenge vollständig bewertet wird. Man tauscht dabei ein bisschen „perfekte“ Ergebnisgarantie gegen sehr viel bessere Latenz und geringere Kosten ein.
Cosinus‑Ähnlichkeit vergleicht die Richtung der Vektoren (zeigen sie in dieselbe Richtung?). Skalarprodukt (Dot Product) belohnt ähnliche Richtung und kann je nach Normierung auch die Magnitude berücksichtigen.
Praktisch: Verwenden Sie die Metrik, die für Ihr Embedding‑Modell empfohlen wird, und nutzen Sie sie konsistent beim Indexieren und Abfragen.
Chunking bestimmt, was jeder Vektor repräsentiert. Zu große Chunks liefern oft störenden, breit gefächerten Kontext; zu kleine verlieren wichtigen Zusammenhang.
Ein praxisnaher Startpunkt:
Anschließend je nach Inhaltstyp anpassen (APIs/rechtliches oft kleiner; Erzählungen tendenziell größer).
RAG ist typischerweise eine Pipeline:
Wählen Sie nach Deployment‑ und Ops‑Toleranz:
Häufige Fallen:
