> turbopuffer im Test: Object Storage als Quelle der Wahrheit, SPFresh und RaBitQ, hybride Suche, Abrechnung pro GB gegenüber Pinecone und wann es sich lohnt. > > Web page: https://balazscsorba.com/de/blog/turbopuffer · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/turbopuffer.md) · [Magyar](https://balazscsorba.com/hu/blog/turbopuffer.md) > Author: Balázs Csorba · Published: 2026-09-29 · Updated: 2026-10-01 · Keywords: turbopuffer, turbopuffer pricing, vector search on object storage, serverless vector database, turbopuffer vs pinecone, turbopuffer namespaces, spfresh vector index, hybrid search bm25 vector, per-query vector database pricing, object storage vector database [Blog](https://balazscsorba.com/de/blog)/Retrieval & Suche # turbopuffer im Test: Vektorsuche auf Object Storage und was eine Anfrage kostet turbopuffer im Test: Object Storage als Quelle der Wahrheit, SPFresh und RaBitQ, hybride Suche, Abrechnung pro GB gegenüber Pinecone und wann es sich lohnt. [Balázs Csorba](https://balazscsorba.com/de/about)·29\. September 2026·aktualisiert 1\. Oktober 2026·8 Min. Lesezeit - turbopuffer - Vector database - Object storage - Pricing - Hybrid search ![Ein großer Speicher-Eimer unten und ein kleines Cache-Fach oben, das einige Karten hochholt.](https://balazscsorba.com/images/blog/turbopuffer/cover.webp?v=e4fb597603) ## Das Wichtigste in Kürze - turbopuffer hält jeden Namespace als Präfix im Object Storage und bedient Anfragen von zustandslosen Knoten mit NVMe- und Speicher-Caches, sodass ungenutzte Daten Speicherpreise kosten. - Vom Anbieter veröffentlichte Latenz: etwa 10 ms p90 für einen warmen Namespace mit 1 Mio. Vektoren und etwa 444 ms p90 kalt, wobei kalte Anfragen auf etwa drei Roundtrips zum Object Storage begrenzt sind. - Der ANN-v3-Index kombiniert hierarchisches Clustering nach SPFresh-Art mit binärer Quantisierung per RaBitQ und zielt auf 100 Milliarden Vektoren in einem Index. - Abgerechnet wird pro GB gespeichert, geschrieben, durchsucht und zurückgegeben statt pro Operation, was viele kleine Mandanten und überwiegend ruhende Korpora begünstigt; Stand Oktober 2026 liegen die Mindestbeträge bei $16 und $256 im Monat. - Alle Leistungs- und Kostenzahlen hier stammen vom Anbieter; rechnen Sie Ihre Namespace-Größe, Ihren Filtermix und Ihren Anteil kalter Anfragen vor einer Migration durch beide Preismodelle. Auf dieser Seite 1. [Was es ist](https://balazscsorba.com/#what-it-is) 2. [Wie es funktioniert](https://balazscsorba.com/#how-it-works) 3. [Einstieg](https://balazscsorba.com/#getting-started) 4. [Preise und der Vergleich mit Pinecone](https://balazscsorba.com/#pricing) 5. [Wo es an Grenzen stößt](https://balazscsorba.com/#where-it-breaks) 6. [Alternativen](https://balazscsorba.com/#alternatives) 7. [Fazit](https://balazscsorba.com/#verdict) 8. [Quellen](https://balazscsorba.com/#sources) Diesen Artikel anhören 0:000:00 **turbopuffer** ist eine gemanagte Suchmaschine für Vektoren und Volltext, deren Quelle der Wahrheit ein Object Storage ist, kein Servercluster. Jeder Namespace ist ein Präfix in einem Bucket, und zustandslose Anfrageknoten cachen das Gelesene auf NVMe und im Speicher. Daraus ergibt sich eine andere Kostenform als bei den meisten Vektordatenbanken: Daten, die niemand abfragt, kosten ungefähr so viel wie Object Storage, und Sie zahlen pro geschriebenem GB und pro durchsuchtem und zurückgegebenem GB statt pro Operation. Diese Besprechung behandelt die Architektur, den ANN-Index, hybride Suche, die Preise Stand Oktober 2026 im Vergleich mit Pinecone, wo es gewinnt und wo es an Grenzen stößt. Ich habe turbopuffer nicht produktiv betrieben, daher stammen alle Leistungs- und Kostenzahlen unten vom Anbieter und sind so gekennzeichnet. Andere Ansätze besprechen die Artikel zu [Pinecone](https://balazscsorba.com/de/blog/pinecone), [LanceDB](https://balazscsorba.com/de/blog/lancedb) und [Chroma](https://balazscsorba.com/de/blog/chroma). ## Was es ist turbopuffer ist eine Suchmaschine, die den Object Storage als Datenbank behandelt. Der Anbieter beschreibt die Speicher-Engine als LSM auf Object Storage, in der „jeder Such-Namespace einfach ein Präfix im Object Storage“ ist, jeder Knoten jeden Namespace bedienen kann und ein Namespace nach einer kalten Anfrage in etwa 500 ms wieder im Cache ist ([turbopuffer](https://turbopuffer.com/blog/turbopuffer)). Der Object Storage ist keine kalte Ebene, in die Daten abgeschoben werden; dort liegen die Daten immer. Die Wirtschaftlichkeit folgt aus den Speicherpreisen, die der Anbieter nennt: etwa $0,02 pro GB für S3, etwa $0,60 pro GB für dreifach replizierte SSD und „$2+ pro GB“ für In-Memory-Vektordatenbanken, Zahlen von 2022 ([turbopuffer](https://turbopuffer.com/blog/turbopuffer)). Der Gründungsfall war Readwise, wo mehr als 100 Millionen Dokumente in einem In-Memory-Speicher über $20.000 im Monat gekostet hätten, neben einer relationalen Datenbank für etwa $5.000 im Monat. Der Anbieter berichtet außerdem, dass Cursor im November 2023 binnen weniger Tage alles umgezogen und die Kosten um 95 Prozent gesenkt habe; Cursors Seite dieser Geschichte steht in [RAG über Code](https://balazscsorba.com/de/blog/code-rag-repository-indexing). Die eigenen, undatierten Größenangaben des Anbieters auf seiner Website lauten: mehr als eine Billion gehostete Dokumente, mehr als zehn Millionen Schreibvorgänge pro Sekunde und mehr als 100.000 Anfragen pro Sekunde über alle Kunden. Behandeln Sie das als Marketingzahlen, nicht als Kapazitätsplan; für Sie zählen die Grenzen pro Namespace weiter unten und die Latenz der Namespaces, die Sie tatsächlich anlegen. ## Wie es funktioniert Anfragen gehen an zustandslose Knoten, die quantisierte Zentroide im Speicher und Vektoren in voller Präzision auf lokalem NVMe halten. Warme Anfragen verlassen den Knoten nie; kalte holen in einer begrenzten Zahl von Roundtrips aus dem Object Storage nach. Der Anbieter veröffentlicht diese Werte: für eine Million Vektoren mit 768 Dimensionen etwa 10 ms p90 warm und 444 ms p90 kalt; für einen BM25-Index mit einer Million Dokumenten 18 ms warm und 285 ms kalt ([turbopuffer](https://turbopuffer.com/blog/turbopuffer)). ![Anfragepfad in turbopuffer Fünf Schritte von links nach rechts: Der Client sendet eine Anfrage; ein zustandsloser Anfrageknoten nimmt sie an, und jeder Knoten kann jeden Namespace bedienen; quantisierte Cluster-Zentroide werden aus dem Speicher gelesen; Vektoren in voller Präzision von lokalem NVMe dienen zum Reranking eines kleinen Teils der Kandidaten; und bei einem kalten Namespace kommen die Daten in etwa drei Roundtrips aus dem Object Storage und bleiben danach im Cache.](https://balazscsorba.com/images/blog/turbopuffer/diagram-8.webp?v=d4401d59c1) Warme Anfragen enden in Speicher und NVMe; nur kalte Namespaces erreichen den Object Storage, der in jedem Fall die Quelle der Wahrheit ist. Der aktuelle Index, ANN v3, zielt auf 100 Milliarden Vektoren in einem Index bei 200 ms p99. Er nutzt hierarchisches Clustering nach SPFresh mit Verzweigungsfaktor 100, durchsucht etwa 500 Cluster pro Ebene und speichert Vektoren mit binärer Quantisierung per RaBitQ, sodass weniger als ein Prozent der Kandidaten ein Reranking in voller Präzision braucht ([ANN v3](https://turbopuffer.com/blog/ann-v3)). Der Beitrag rechnet es vor: Eine Baumebene ist unquantisiert etwa 100 MB und quantisiert etwa 6 MB groß, was den Engpass von der Platte zur CPU verschoben hat. SPFresh selbst ist das SOSP-2023-Design für inkrementell aktualisierte Cluster-Indizes ([SPFresh](https://dl.acm.org/doi/10.1145/3600006.3613166)). Filter sind Teil des Index und kein Nachbearbeitungsschritt. Native Filterung macht Attributindizes das Clustering bekannt, sodass der Anfrageplan Cluster ohne passende Dokumente überspringen und die Kandidatenzahl nahe an einer ungefilterten Anfrage halten kann ([turbopuffer](https://turbopuffer.com/blog/native-filtering)). Die Konsistenz ist einstellbar: Lesezugriffe sind standardmäßig stark konsistent gegenüber dem Object Storage und lassen sich auf eventuell konsistente Anfragen unter 10 ms lockern ([Doku](https://turbopuffer.com/docs/architecture)). Eine Anfrage kann drei Signale nutzen. Volltextsuche ist BM25 auf derselben Engine, und der Hybrid-Leitfaden dokumentiert, Vektor- und Textanfragen auszuführen und die Ergebnisse vor einem optionalen Reranking zu fusionieren ([Hybrid-Doku](https://turbopuffer.com/docs/hybrid)). Seit dem 29. September 2026 kann turbopuffer die Embeddings auch selbst erzeugen, statt dass Sie sie mitbringen müssen ([native Embeddings](https://turbopuffer.com/blog/native-embedding)), was einen Dienst aus dem Schreibpfad entfernt. ## Einstieg Die natürliche Einheit ist ein Namespace pro Mandant, pro Kunde oder pro Datensatz, denn Namespaces sind günstige Präfixe und ungenutzte kosten nur Speicher. Die Skizze unten schreibt Zeilen mit einem Vektor- und einem Volltextfeld und führt eine gefilterte Vektoranfrage und eine BM25-Anfrage aus, deren Listen Sie selbst fusionieren; prüfen Sie vor dem Kopieren die aktuelle Client-Referenz auf die genauen Parameternamen. ``` # Sketch: one namespace per tenant, hybrid query with a filter (Python client) import turbopuffer tpuf = turbopuffer.Turbopuffer(region="gcp-europe-west3") ns = tpuf.namespace(f"tenant-{tenant_id}") # a prefix on object storage ns.write( upsert_rows=[{"id": doc.id, "vector": doc.embedding, "text": doc.text, "lang": doc.lang}], distance_metric="cosine_distance", schema={"text": {"type": "string", "full_text_search": True}}, ) vector_hits = ns.query(rank_by=("vector", "ANN", query_embedding), top_k=50, filters=("lang", "Eq", "de")) text_hits = ns.query(rank_by=("text", "BM25", query_text), top_k=50, filters=("lang", "Eq", "de")) # fuse both lists (for example with reciprocal rank fusion), then optionally rerank the top 50 ``` Das Namespace-Design ist die Entscheidung, die sich später am schwersten ändern lässt. Pro Mandant ist der übliche Standard, weil es Daten isoliert, das Löschen eines Kunden trivial macht und jede Anfrage klein hält. Pro Datensatz passt zu gemeinsamen Korpora wie einem Produktkatalog pro Sprache. Vermeiden Sie einen riesigen Namespace für alles, sofern nicht wirklich jede Anfrage alle Daten braucht, denn bezahlt werden durchsuchte und zurückgegebene Bytes, und Filter in einem riesigen Namespace berühren immer noch mehr davon als ein kleiner Namespace. Die dokumentierten Grenzen sind großzügig, aber real: bis zu 256 Shards und etwa 128 Milliarden Dokumente pro Namespace, 10.752 Dimensionen, 8 Vektorspalten, 64 MiB pro Dokument, rund 10.000 Schreibvorgänge pro Sekunde und 5.000 oder mehr Anfragen pro Sekunde pro Namespace, bei einem Recall bei 10 zwischen 90 und 100 Prozent ([Grenzen](https://turbopuffer.com/docs/limits)). ## Preise und der Vergleich mit Pinecone Stand Oktober 2026 nennt die Preisseite einen Mindestbetrag von $16 im Monat für Launch, $256 für Scale und mindestens $4.096 für Enterprise mit 35 Prozent Nutzungsaufschlag ([Preise](https://turbopuffer.com/pricing)). Die Einheitspreise stammen aus dem Kostenrechner der Seite statt aus ihrem Text, behandeln Sie sie also als Rechnerwerte: etwa $0,33 pro GB und Monat für indexierten Speicher, $2 pro geschriebenem GB mit 10 kB Minimum pro Schreibvorgang und Anfragen zu $1 pro durchsuchtem PB plus $0,05 pro zurückgegebenem GB, mit einer Mindestabrechnungsgröße pro Anfrage. ![Zwei Abrechnungsmodelle nebeneinander Zwei Spalten. turbopuffer berechnet gespeicherte GB, geschriebene GB und von Anfragen durchsuchte und zurückgegebene GB, mit einem monatlichen Mindestbetrag. Pinecone berechnet gespeicherte GB, Schreibeinheiten pro Million und Leseeinheiten pro Million, mit einem Enterprise-Mindestbetrag. Dieselbe Last kostet daher unterschiedlich, je nachdem wie viele Bytes sie bewegt und wie viele Operationen sie ausführt.](https://balazscsorba.com/images/blog/turbopuffer/diagram-19.webp?v=68b94e4adb) Speicher kostet in beiden gleich viel pro GB und Monat; der Unterschied ist, ob Schreiben und Anfragen nach Bytes oder nach Operationen abgerechnet werden (Preisrechner- und Preisseitenwerte, Oktober 2026). Pinecone berechnete am selben Tag ebenfalls $0,33 pro GB und Monat für Speicher, aber Schreiben mit $4 bis $4,50 pro Million Schreibeinheiten und Lesen mit $16 bis $18 pro Million Leseeinheiten im Standard-Tarif, mit einem Enterprise-Mindestbetrag von $500 im Monat ([Pinecone](https://www.pinecone.io/pricing/)). Der Vergleich dreht sich also nicht um Speicher, sondern um die Abrechnungsachse. Lasten mit vielen kleinen Mandanten, überwiegend ruhenden Daten oder großen, selten zurückgegebenen Dokumenten begünstigen eher die GB-Abrechnung; Lasten mit vielen winzigen Anfragen auf einen heißen Index brauchen eine sorgfältige Rechnung, weil Mindestbeträge pro Anfrage gelten. Zwei weitere Hebel verändern die Rechnung. Die Vektorpräzision hat einen Preis: Der Rechner berechnet f16-Vektoren mit der Hälfte des Speichers von f32 und i8 mit einem Viertel. Gepinnte Namespaces, also dedizierte Kapazität für einen heißen Namespace, kosten $9,67 pro GB und Monat mit 128 GB Minimum pro Replikat, ausgelegt auf etwa 500 Anfragen pro Sekunde pro Replikat. Mit Pinning beseitigt man den kalten Anteil für den einen Namespace, der ihn sich nicht leisten kann. Die Rechnung funktioniert wie Tokenkosten bei einer LLM-Funktion. Auf meiner eigenen Nuxt-Seite, auf der ich LLM-Funktionen betreibe, ist die nützliche Gewohnheit, die Kosten pro Anfrage aus öffentlichen Preisen aufzuschreiben, bevor ein Anbieter gewählt wird, und dieselbe Gewohnheit gilt hier: Nehmen Sie eine Woche echter Anfrageprotokolle, schätzen Sie durchsuchte und zurückgegebene Bytes pro Anfrage und bepreisen Sie dieselbe Woche in beiden Modellen. ## Wo es an Grenzen stößt Der kalte Anteil ist der strukturelle Preis. Die erste Anfrage auf einen nicht gecachten Namespace dauert nach den eigenen Zahlen des Anbieters Hunderte Millisekunden, was für einen Tool-Aufruf eines Agenten in Ordnung und in einem Suchfeld mit Live-Ergebnissen spürbar ist. Verteilt sich Ihr Verkehr dünn über Tausende Namespaces, sind viele Anfragen kalt, messen Sie den Anteil also, bevor Sie Latenz zusagen. **v3 wird noch abgestimmt** turbopuffer baut seine Speicher-Engine als v3 neu, die laut Anbieter inzwischen alle Tests besteht. Die eigene nächtliche Benchmark-Seite zeigt v3 derzeit bei den meisten Lasten im p90 langsamer als das produktive v2, etwa rund viermal bei heißen Volltextanfragen ([v3-Benchmarks](https://turbopuffer.com/v3)). Fragen Sie, auf welcher Engine Ihre Namespaces laufen, und testen Sie nach dem Wechsel erneut. Grenzen sind der dritte Punkt. Ein Namespace endet bei 256 Shards, und Pinning ist auf 4 TB pro Maschine und auf Konten mit höchstens 1.000 Namespaces begrenzt, sodass ein Produkt mit Zehntausenden Mandanten sich nicht per Pinning aus der kalten Latenz befreien kann. Schreibvorgänge pro Namespace sind bei rund 10.000 pro Sekunde gedeckelt, was beim massenhaften Neueinbetten zählt: Planen Sie große Nachladungen als gebündelte, gedrosselte Jobs statt als einen einzigen Schub. Die Abhängigkeit vom Anbieter ist das andere Risiko. In den hier genutzten Quellen gibt es keine selbst gehostete Edition, jede Leistungszahl ist selbst veröffentlicht, und einen unabhängigen Benchmark habe ich bei der Recherche nicht gefunden. Halten Sie Rohtext, Embedding-Modellnamen und Vektoren in einem Speicher unter Ihrer Kontrolle, damit ein Wechsel Neuindexieren statt Neuerzeugen von Daten bedeutet. ## Alternativen Aspekt turbopuffer Pinecone Serverless LanceDB Betrieb gemanagter Dienst gemanagter Dienst eingebettete Bibliothek oder Cloud Speichermodell Object Storage als Quelle der Wahrheit gemanagter serverloser Index spaltenorientierte Dateien in Ihrer Hand Abrechnungseinheit GB gespeichert, geschrieben, durchsucht, zurück GB gespeichert plus Lese- und Schreibeinheiten eigener Speicher und Rechenleistung Mandantenfähigkeit Namespace pro Mandant Namespaces Tabelle oder Datensatz pro Mandant Passt am besten viele Mandanten, meist ruhende Daten gleichmäßiger Verkehr, einfacher Betrieb lokale oder Lakehouse-Lasten Die drei unterscheiden sich mehr im Betrieb als in der Suchqualität. Pinecone ist der gemanagte Standard mit Abrechnung pro Operation und ohne Verhalten kalter Namespaces, das man einplanen müsste. LanceDB speichert Vektoren in spaltenorientierten Dateien in Ihrer Hand und läuft eingebettet in der Anwendung oder als Cloud-Dienst, was zu lokalen und Lakehouse-artigen Lasten passt. Chroma, beschrieben in [seiner eigenen Besprechung](https://balazscsorba.com/de/blog/chroma), ist der einfachste Einstieg für Prototypen und Anwendungen auf einem Knoten. turbopuffer steht Pinecone am nächsten, aber mit dem Kostenmodell des Object Storage. Betreiben Sie bereits einen Suchcluster, kann es alle drei schlagen, die Vektoren dort zu ergänzen, siehe [Vektorsuche in Elasticsearch und OpenSearch](https://balazscsorba.com/de/blog/elasticsearch-opensearch-vector-search). Sind die Daten klein und will das Team eine einzige Datenbank, ist [pgvector](https://balazscsorba.com/de/blog/pgvector) die unspektakuläre Option, die man zuerst bepreisen sollte. ## Fazit turbopuffer hat derzeit das interessanteste Kostenmodell unter den gemanagten Vektorsuchen: Object Storage als Datenbank, Caches davor und Abrechnung nach Bytes statt Operationen. Es passt zu mandantenfähigen Produkten, Agenten-Gedächtnis und archivähnlichen Korpora, in denen die meisten Daten ruhen und gelegentliche Latenzen im Bereich von Hunderten Millisekunden akzeptabel sind. Weniger gut passt es, wenn jede Anfrage auf einem langen Schwanz selten genutzter Namespaces schnell sein muss oder wenn Sie eine selbst gehostete Option brauchen. 1. Mandanten oder Datensätze auf Namespaces abbilden und schätzen, wie viele gleichzeitig warm sind. 2. Eine echte Woche Verkehr in beiden Modellen bepreisen, pro GB und pro Operation. 3. Latenz kalter Anfragen auf Namespaces in Ihrer echten Größe messen. 4. Recall mit Ihren Filtern testen, nicht mit ungefilterten Anfragen. 5. Entscheiden, welcher Namespace gegebenenfalls gepinnt werden muss. 6. Quelltext und Embeddings außerhalb des Dienstes halten, damit ein Wechsel möglich bleibt. Wenn Sie einen Vektorspeicher für ein mandantenfähiges RAG-Produkt wählen und das Kostenmodell vor der Entscheidung durchgerechnet haben wollen, sehen Sie sich meine [KI-Engineering-Arbeit](https://balazscsorba.com/de/expertise/ai-engineer) an. ## Quellen 1. [turbopuffer blog: turbopuffer (updated Mar 2026)](https://turbopuffer.com/blog/turbopuffer) 2. [turbopuffer blog: ANN v3 (Jan 2026)](https://turbopuffer.com/blog/ann-v3) 3. [SPFresh (SOSP 2023)](https://dl.acm.org/doi/10.1145/3600006.3613166) 4. [turbopuffer blog: native filtering](https://turbopuffer.com/blog/native-filtering) 5. [turbopuffer docs: hybrid search](https://turbopuffer.com/docs/hybrid) 6. [turbopuffer blog: native embedding (Sep 2026)](https://turbopuffer.com/blog/native-embedding) 7. [turbopuffer docs: architecture](https://turbopuffer.com/docs/architecture) 8. [turbopuffer pricing](https://turbopuffer.com/pricing) 9. [turbopuffer docs: limits](https://turbopuffer.com/docs/limits) 10. [turbopuffer v3 benchmarks](https://turbopuffer.com/v3) 11. [Pinecone pricing](https://www.pinecone.io/pricing/) ## Häufige Fragen Was ist turbopuffer? Eine gemanagte Suchmaschine für Vektoren und Volltext, die jeden Namespace in einem Object Storage wie S3 ablegt und Anfragen von zustandslosen Knoten mit SSD- und Speicher-Caches bedient. Kalte Daten sind günstig, weil sie im Object Storage liegen; heiße Daten sind schnell, weil sie gecacht sind. Was kostet turbopuffer? Stand Oktober 2026 hat der Launch-Plan einen Mindestbetrag von $16 im Monat und der Scale-Plan $256, Enterprise ab $4.096. Die Nutzung wird pro GB gespeichert, pro GB geschrieben und pro GB von Anfragen durchsucht und zurückgegeben abgerechnet; der Preisrechner nennt etwa $0,33 pro GB und Monat für indexierten Speicher und $2 pro geschriebenem GB. Wie unterscheidet sich turbopuffer von Pinecone? Beide sind gemanagt und serverlos, rechnen aber auf unterschiedlichen Achsen ab. Pinecone berechnet pro Million Lese- und Schreibeinheiten, turbopuffer pro GB geschrieben, durchsucht und zurückgegeben. turbopuffer behandelt außerdem den Object Storage als Quelle der Wahrheit, daher ist die Latenz bei einem kalten Namespace höher als bei einem warmen. Ist turbopuffer schnell genug für produktive Suche? Für warme Namespaces meldet der Anbieter ein p90 um 10 ms bei einer Million Vektoren. Die erste Anfrage auf einen kalten Namespace ist deutlich langsamer, im Bereich von Hunderten Millisekunden, während Daten in den Cache geladen werden. Lasten, die viele selten genutzte Namespaces berühren, sollten diesen kalten Anteil messen. Unterstützt turbopuffer hybride Suche? Ja. Es bietet BM25-Volltextsuche auf derselben Engine, Attributfilter, die das Vektor-Clustering kennen, und ein dokumentiertes Muster, Vektor- und Texttreffer vor einem optionalen Reranking zu fusionieren. Seit September 2026 kann es Embeddings auch selbst erzeugen. Geschrieben von Balázs Csorba Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten. [KI-Entwicklung & MCP-Server →](https://balazscsorba.com/de/expertise/ai-engineer)[Über mich →](https://balazscsorba.com/de/about) ## Weitere Artikel - [Embedding-Modell wählen 2026: Leaderboards, Kosten und ein Vergleichstest mit eigenen Daten](https://balazscsorba.com/de/blog/embedding-model-selection-2026) - [Contextual Retrieval und Late Chunking: RAG-Chunks ihren Kontext zurückgeben](https://balazscsorba.com/de/blog/contextual-retrieval-late-chunking) - [Zugriffskontrolle für RAG: berechtigungsbewusstes Retrieval ohne Datenlecks](https://balazscsorba.com/de/blog/rag-access-control-permissions) - [RAG über Produktkataloge: aus PIM-Daten Antworten machen, die halten](https://balazscsorba.com/de/blog/rag-product-catalog-pim-data) ## Klingt nach dem, was du suchst? Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören. [Kontakt aufnehmen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)