> Qdrant im Test: filterbares HNSW, vier Quantisierungsmethoden, die Memory-Tier in Version 1.19 und der Betrieb, den niemand mehr publiziert.
>
> Web page: https://balazscsorba.com/de/blog/qdrant · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/qdrant.md) · [Magyar](https://balazscsorba.com/hu/blog/qdrant.md)
> Author: Balázs Csorba · Published: 2026-05-26 · Keywords: qdrant, qdrant vs pinecone, vector database comparison, hnsw index, filtered vector search, vector quantisation, hybrid search rrf, rag vector store

[Blog](https://balazscsorba.com/de/blog)/Retrieval & Suche

# Qdrant: eine Vektordatenbank, gebaut um Filtern

Qdrant im Test: filterbares HNSW, vier Quantisierungsmethoden, die Memory-Tier in Version 1.19 und der Betrieb, den niemand mehr publiziert.

[Balázs Csorba](https://balazscsorba.com/de/about)·26\. Mai 2026·10 Min. Lesezeit

-   Vector search
-   HNSW
-   Quantisation
-   Hybrid search
-   Filtering

![Ein breiter Trichter mit einer Reihe kleiner Quadrate über der Öffnung, darunter drei Regale mit weniger.](https://balazscsorba.com/images/blog/qdrant/cover.webp?v=745837a3a9)

## Das Wichtigste in Kürze

-   Die aktuelle Version ist 1.19.2 vom 5. Oktober 2026; der Memory-Tier-Parameter, der jede Größenplanung bestimmt, kam mit 1.19.
-   Filtern ist das Argument für das Produkt: Ein Payload-Index steuert die HNSW-Traversierung, er muss aber vor dem Import existieren, sonst wird der Graph neu gebaut.
-   TurboQuant komprimiert bis zu 32-fach, arbeitet standardmäßig asymmetrisch und bewertet die Top-k gegen Vektoren in voller Präzision neu – ein Latenzpreis bei jeder Anfrage.
-   Eine selbst gehostete Instanz ist für jedes Netzwerkinterface offen und unauthentifiziert, bis API-Schlüssel, TLS und Netzwerkbindung von Hand konfiguriert sind.
-   Die Benchmark-Seite des Herstellers zeigt noch Läufe aus Januar und Juni 2024; ihre Vergleichszahlen tragen 2026 keine Kaufentscheidung mehr.

Auf dieser Seite

1.  [Was es ist](https://balazscsorba.com/#what-it-is)
2.  [Wie eine Anfrage tatsächlich läuft](https://balazscsorba.com/#how-it-works)
3.  [Erste Schritte](https://balazscsorba.com/#getting-started)
4.  [Speicher und Quantisierung](https://balazscsorba.com/#memory-and-quantisation)
5.  [Selbst hosten und Sicherheit](https://balazscsorba.com/#self-hosting-and-security)
6.  [Wo es schwächelt](https://balazscsorba.com/#where-it-weakens)
7.  [Fazit](https://balazscsorba.com/#verdict)
8.  [Quellen](https://balazscsorba.com/#sources)

Diesen Artikel anhören

0:000:00

Qdrant ist eine in Rust geschriebene Vektordatenbank unter Apache-2.0, gebaut um eine Entscheidung, die die meisten Wettbewerber als Nebensache behandeln: Ein Metadatenfilter ist nichts, was man nach dem Retrieval anwendet, sondern etwas, mit dem der Index durchlaufen wird. Heraus kommt das überzeugendste Bild für gefilterte Suche in der Open-Source-Welt, und eine wirklich einfache Betriebsgeschichte – ein Container, eine REST- und gRPC-Schnittstelle, offizielle Clients in sechs Sprachen. Der Preis dieser Fokussierung: Für die dichte Suche gibt es genau eine Indeximplementierung, HNSW, und das verwaltete Angebot rechnet nach Verbrauch statt nach veröffentlichtem Preis. Empfehlung für filterlastige Suche, weniger als Allzweckspeicher.

Es liegt in derselben Schicht wie pgvector, Milvus, Weaviate und Pinecone, aber das Versprechen unterscheidt sich. Weaviate verkauft einen integrierten KI-Speicher mit eingebauter hybrider Suche und Modulen; Milvus verkauft horizontale Skalierung in die Milliarden; Pinecone verkauft null Betrieb. Qdrant verkauft Speichereffizienz und Filterdurchsatz auf einem einzelnen Knoten – ein engeres und leichter haltbares Versprechen.

## Was es ist

Das Datenmodell ist absichtlich klein. Ein Punkt ist ein Datensatz mit einem Vektor und einem optionalen JSON-Payload. Eine Collection ist eine benannte Menge von Punkten mit gemeinsamer Dimension und Distanzmetrik. Benannte Vektoren erlauben mehrere Vektoren pro Punkt mit eigener Dimension und Metrik – so wird hybride Suche ausgedrückt. Alles Übrige im Produkt ist Maschinerie, um den nächsten Nachbarn schneller zu finden, ohne zu scannen.

-   Lizenz Apache-2.0, in Rust geschrieben, ein Repository mit rund 35.000 Sternen und 7.100 Commits.
-   Aktuelle Version 1.19.2 vom 5. Oktober 2026; die Version 1.19 brachte die `memory`\-Tiers, die bestimmen, wo Vektoren, Indizes und Payloads liegen.
-   Distanzmetriken sind Dot Product, Cosine, euklidisch und Manhattan; Cosine ist als Dot Product über normalisierte Vektoren implementiert, normalisiert beim Upload.
-   Für die dichte Suche wird ausschließlich HNSW verwendet, mit `m` standardmäßig 16 und `ef_construct` 100, beides pro Collection und benanntem Vektor überschreibbar.
-   Payload-Index-Typen sind keyword, integer, float, bool, geo, datetime, text und uuid, jeweils vor dem Import angelegt, damit das filterbare HNSW sie nutzen kann.
-   Hybride und mehrstufige Suche kam mit 1.10 über die Query API: `prefetch`\-Unterabfragen, verschmolzen mit RRF oder DBSF, wobei Prefetches verschachtelt sein können.
-   Offizielle Clients gibt es für Python, TypeScript, Rust, Go, Java und .NET über REST auf 6333 und gRPC auf 6334.

## Wie eine Anfrage tatsächlich läuft

Die interessante Technik steckt im Query-Planer, und sie zerfällt in drei Fälle. Ein so enger Filter, dass kaum Daten passen, ist mit einem Vollscan besser bedient als mit einem Graphendurchlauf. Ein so weiter Filter, dass fast die ganze Collection passt, kann das HNSW unverändert nutzen. Alles dazwischen – wo mandanten- und sprachbezogene Suche wohnt – ist der Fall, den ein reiner Vektorindex mit Nachfilterung schlecht beherrscht, und der Fall, für den das filterbare HNSW gebaut wurde.

![Three paths a filtered query can take through Qdrant A query carrying a vector and a filter enters at the top and splits three ways. Left: the filter is strict and few points match, so the payload index is used for a full scan and the HNSW graph is skipped; the default full scan threshold is 10,000 kilobytes, where one kilobyte is one vector of size 256. Middle: the filter is weak and most points match, so the HNSW graph is used as it is and filtering happens afterwards. Right: the filter is in the middle, the case that matters in production, so the payload index feeds the HNSW walk, and the payload indexes have to exist before the data is ingested or the graph has to be rebuilt. A band below: with quantisation enabled the graph is walked over compressed vectors and the top candidates are rescored against the originals, with rescore and oversampling as per-query settings.](https://balazscsorba.com/images/blog/qdrant/diagram-7.webp?v=98b3960983)

Der Filter entscheidet über den Ausführungspfad, und die Standardschwellen sind Konfiguration, die man übernimmt statt wählt.

Ein Betriebsdetail aus der mittleren Spalte verursacht mehr Ausfallzeit als jedes Query-Tuning: Payload-Indizes helfen dem HNSW-Graphen nur, wenn sie vor den Daten existierten. Ein Tenant-Feld zu einer bestehenden Collection hinzuzufügen heißt, den Graphen neu bauen zu lassen, damit er filterbewusst wird – bei großen Collections in Stunden gemessen. Das Payload-Schema gehört vor den ersten Upsert geplant, nicht nach dem ersten Vorfall.

## Erste Schritte

Ein Container auf 6333 ohne Authentifizierung reicht zum Start, und das ist zugleich das Wichtigste, was vor dem Verlassen des Laptops zu reparieren ist. Die Konfiguration unten legt eine Collection mit TurboQuant auf einem Bit an, indiziert das Tenant-Feld vor dem Import und führt eine gefilterte Anfrage über die Query API aus:

```
from qdrant_client import QdrantClient, models

client = QdrantClient(url="http://localhost:6333")

client.create_collection(
    collection_name="chunks",
    vectors_config=models.VectorParams(size=1024, distance=models.Distance.COSINE),
    quantization_config=models.TurboQuantization(
        turbo=models.TurboQuantQuantizationConfig(bits=models.TurboQuantBitSize.BITS1),
    ),
)

# Before ingestion: the HNSW graph can only be filter-aware for
# fields that already have a payload index.
client.create_payload_index(
    collection_name="chunks",
    field_name="tenant",
    field_schema=models.PayloadSchemaType.KEYWORD,
)

client.upsert(
    collection_name="chunks",
    points=[models.PointStruct(id=1, vector=[0.1] * 1024, payload={"tenant": "acme"})],
)

hits = client.query_points(
    collection_name="chunks",
    query=[0.1] * 1024,
    query_filter=models.Filter(
        must=[models.FieldCondition(key="tenant", match=models.MatchValue(value="acme"))],
    ),
    limit=10,
    search_params=models.SearchParams(quantization=models.QuantizationSearchParams(oversampling=2.0)),
).points
```

Zwei Dinge in diesem Snippet lohnen sich. Die Quantisierung ist eine Collection-Einstellung, die beim Indexieren angewendet wird, und die komprimierten Vektoren liegen neben den Originalen – die Originale bleiben also für ein Rescore vorhanden. Der Parameter `oversampling` verlangt das Doppelte an Kandidaten aus dem quantisierten Index, bevor neu bewertet wird. Das ist der Hebel, wenn die komprimierte Suche Ergebnisse verliert, die eigentlich drin sein müssten.

**Die Kapazitätsseite vor dem ersten Knoten lesen**

Die Größenregeln des Herstellers sind kurz genug zum Auswendiglernen. Vektoren und HNSW-Indizes stehen standardmäßig auf `cached`, sind also vorbeladen, aber verdrängbar; `cold` legt sie auf die Platte. Payloads stehen standardmäßig auf `cold`, Payload-Indizes und quantisierte Vektoren auf `pinned`. Für Payload-Indizes das Doppelte der indizierten Felder veranschlagen, für die Payload-Speicherung den Faktor 1,5 obendrauf.

## Speicher und Quantisierung

Quantisierung ist die wirksamste Einzelmaßnahme vor dem Produktivbetrieb, und Qdrant bietet inzwischen vier Methoden mit wirklich unterschiedlichen Zielkonflikten statt eines einzelnen Binärschalters. Die Produktions-Checkliste führt sie neben einer ehrlichen RAM-Planung und der Indizierung der gefilterten Felder zu den drei Dingen, die man zuerst tun sollte.

Methode

Kompression

Rewertet Standard

Wo sie passt

Preis

TurboQuant

Bis 32-fach, von 4 Bit bis 1 Bit

Ja, bei 1, 1,5 und 2 Bit

Standardwahl seit 1.18

Asymmetrisch, Anfragen bleiben in voller Präzision

Skalar

4-fach, float32 zu int8

Nein

Kompression mit dem geringsten Risiko

Braucht ein Quantil für Ausreißer

Binär

Bis 32-fach, 1 bis 2 Bit je Komponente

Ja

Hochdimensionale, zentrierte Embeddings

Versagt bei fremden Verteilungen

Produkt

Bis 64-fach, 256 Zentroide je Abschnitt

Nein

Wenn nur Speicher zählt

Größter Genauigkeitsverlust der vier

Über die Methode hinaus hat 1.19 einen Memory-Tier-Parameter für die quantisierte Kopie eingeführt, und der macht die Quantisierung als RAM-Reduktion brauchbar statt nur als Geschwindigkeitstrick. Die Originale in den Tier `cold` und die quantisierten Vektoren in `pinned` legen, dann greift die Suche nur beim Neubewerten der besten Kandidaten auf die Platte zu. Der Datentyp `turbo4`, der jede Dimension auf der Platte mit vier statt 32 Bit speichert, verkleinert die Plattseite weiter und kostet Recall. Inline-Storage im HNSW-Index, verfügbar seit 1.16, senkt die I/O-Zugriffe weiter, zahlt sich aber nur aus, wenn Vektoren und Index im Tier `cold` liegen und die Quantisierung aktiv ist; bei höchstens vier Bit je Dimension gehalten, sonst bläht der Index auf.

**Quantisierung ist eine Recall-Entscheidung, keine Speicherentscheidung**

Die Dokumentation sagt ausdrücklich, dass sich manche Embedding-Modelle nicht effizient quantisieren lassen, und die Produktions-Checkliste verlangt, die Retrieval-Qualität danach neu zu messen, statt das anzunehmen. Behandeln Sie Recall als Abnahmekriterium mit einer Zahl, und lassen Sie eine Möglichkeit, die Quantisierung pro Anfrage abzuschalten – der Suchparameter `ignore` tut genau das ohne Neuaufbau der Collection.

## Selbst hosten und Sicherheit

Die Sicherheitsdokumentation beginnt mit dem Satz, selbst gehostete Open-Source-Installationen seien standardmäßig nicht sicher und nicht produktionsreif, und eine Standardinstanz sei für alle Netzwerkinterfaces ohne konfigurierte Authentifizierung offen. Das ist eine ehrlichere Sicherheitsseite als bei den meisten Datenbankherstellern, und sie kommt mit einer konkreten Checkliste.

-   Drei Typen von API-Schlüsseln: Admin, Read-only für reine Abfragedienste und granulare Schlüssel mit Lese- oder Schreibrechten je Collection.
-   TLS für den Verkehr in beide Richtungen, dazu eine Netzwerkbindung an ein privates Interface; lokal an 127.0.0.1 binden.
-   Audit-Logging der API-Operationen in eine Datei, für Forensik und Nachweispflichten statt für Erkenntnisse.
-   Auf Qdrant Cloud funktioniert all das genauso, dort sind die Kontrollen standardmäßig aktiv – das ist das eigentliche Argument für das verwaltete Angebot.
-   Die Support-Tiers Community, Standard und Premium unterscheiden sich in der Reaktionszeit (vier Stunden bei einem Totalausfall im kostenlosen Tier, eine Stunde in Standard), nicht im Funktionsumfang.

**Migration ist ein behauptetes Nicht-Thema, meistens**

Das Unternehmen nennt ein Migrationstool und Dokumentation für den Weg von einer selbst gehosteten Installation zu Qdrant Cloud; in die andere Richtung reicht laut Anbieter der Container. Für die Vektoren stimmt das. Für alles, was Sie drumherum gebaut haben, nicht: Die Fusionsstrategien der Query API und Ihr HNSW-Tuning sind die Teile, die man aufschreiben sollte, bevor man umzieht.

## Wo es schwächelt

Fünf Schwächen sind klar zu benennen, denn sie sind es, die dagegen entscheiden.

-   Ein dichter Index. Die Dokumentation sagt, Qdrant nutze für dichte Vektoren ausschließlich HNSW. Es gibt kein IVF, keinen Graphen auf Platte und keinen GPU-Index; ein Korpus, der nicht in den Arbeitsspeicher einer Maschine passt, braucht einen Architekturwechsel statt einer Einstellung.
-   Payload-Indizes entstehen vor dem Import oder gar nicht. Die Wirksamkeit der Optimierung hängt von einer Migration ab, die man zu terminieren vergisst.
-   Horizontale Skalierung gibt es, aber nicht umsonst. Shards, Replikationsfaktoren und shard-key-bewusste Lesezugriffe sind Konfiguration, die stimmen muss, und die Kapazitätsseite verlangt, all das vor der Provisionierung zu entscheiden.
-   Das verwaltete Angebot veröffentlicht keinen Preis. Es wird stundenweise nach vCPU, Arbeitsspeicher, Speicher, Backups und Inferenz-Token abgerechnet, mit einem Rechner statt einer Preisliste, und Serverless steht weiterhin als kommend in der Navigation.
-   Der öffentliche Benchmark ist veraltet. Die Vergleichsseite des Herstellers trägt Januar und Juni 2024; ihr Fazit, Qdrant führe bei Durchsatz und Latenz, beschreibt Software von vor zwei Jahren.

Engine

Lizenz

Optionen für dichte Indizes

Wo gefiltert wird

Betriebsform

Qdrant

Apache-2.0

Nur HNSW, filterbar

Payload-Index speist den Graphendurchlauf

Ein Container oder verwaltete Cloud

pgvector

PostgreSQL-Lizenz

HNSW, IVFFlat

SQL WHERE auf derselben Tabelle

Erweiterung in einer vorhandenen Datenbank

Milvus

Apache-2.0

HNSW, IVF, DiskANN, SCANN, GPU

Skalarer Index in der Engine

Verteilte Dienste, aufwendig zu betreiben

Weaviate

BSD-3-Clause

HNSW, flat, dynamic

Invertierter Index, native BM25-Hybridsuche

Eine Binary, optionaler Cluster

Pinecone

Proprietär, nur verwaltet

Proprietärer Serverless-Index

Serverseitiges Filtern beim Dienst

Nichts zu betreiben, Abrechnung pro Anfrage

Die Kurzfassung: pgvector, wenn Sie bereits Postgres betreiben und der Korpus hineinpasst; Weaviate, wenn native hybride Suche die Anforderung ist; Milvus, wenn die Zahlen wirklich in die Hunderten von Millionen gehen; Pinecone, wenn niemand etwas betreiben will. Qdrant ist die Wahl dazwischen, wo ein Metadatenfilter bei jeder Anfrage wichtiger ist als die Obergrenze.

**Messen Sie Ihren eigenen Recall**

Jeder Vergleich in diesem Umfeld ist ein Hersteller, der seine eigene Testumgebung fährt. Der nützliche Wert ist deshalb der, den Sie selbst erzeugen: der Anteil der wirklich nächsten Nachbarn, die bei Ihrem `ef` und Ihrem `m` zurückkommen, mit und ohne Quantisierung. Die Such-API kennt dafür einen exakten Modus, und ein Lauf gegen Ihre eigenen Embeddings kostet einen Nachmittag und klärt die Debatte.

## Fazit

Qdrant ist die beste Open-Source-Antwort auf gefilterte Vektorsuche, und ihre Schwächen liegen alle in Bereichen, in denen es nicht gewinnen will. Steht auf praktisch jeder Anfrage ein Tenant, eine Sprache oder ein Datum – in Produktion fast immer –, ist das filterbare HNSW ein echter Architekturvorteil und kein Häkchen in einer Feature-Liste. Wählen Sie es wissend, dass die dichte Suche genau einen Index hat, das Payload-Schema an Tag eins stimmen muss und Sie die Sicherheits-Checkliste selbst abarbeiten.

1.  Wählen, wenn auf praktisch jeder Anfrage ein Metadatenfilter liegt und der Korpus auf eine Maschine passt, mit Reserve.
2.  Wählen, wenn Sie keine Lizenzverhandlung wollen: Apache-2.0, keine Feature-Schranke, kein Telemetrie-Zwang, keine Nutzungsberichte.
3.  Wählen, wenn Ihr Team API-Schlüssel, TLS-Zertifikat, Backup-Zeitplan und Versions-Upgrade selbst verantwortet.
4.  Nicht wählen, wenn der Korpus den Arbeitsspeicher sprengen wird und niemand Lust auf eine Migration zu einer verteilten Engine hat.
5.  Nicht auf Basis eines Benchmarks wählen. Prüfen Sie den Recall im exakten Modus an Ihren eigenen Embeddings, dann entscheiden Sie.

> Selbst gehostete Open-Source-Installationen sind standardmäßig nicht sicher und nicht produktionsreif. Alle selbst aufgesetzten Qdrant-Instanzen sind standardmäßig für alle Netzwerkinterfaces offen und haben keine konfigurierte Authentifizierung.

## Quellen

1.  [Qdrant Dokumentation](https://qdrant.tech/documentation/)
2.  [Qdrant: Points](https://qdrant.tech/documentation/manage-data/points/)
3.  [Qdrant: Collections](https://qdrant.tech/documentation/concepts/collections/)
4.  [Qdrant: Indizierung, Payload-Indizes und das filterbare HNSW](https://qdrant.tech/documentation/manage-data/indexing/)
5.  [Qdrant: Quantisierungsmethoden und Memory-Tiers](https://qdrant.tech/documentation/manage-data/quantization/)
6.  [Qdrant: Kapazitätsplanung](https://qdrant.tech/documentation/capacity-planning/)
7.  [Qdrant: Leistung optimieren](https://qdrant.tech/documentation/ops-optimization/optimize/)
8.  [Qdrant: hybride und mehrstufige Abfragen](https://qdrant.tech/documentation/concepts/hybrid-queries/)
9.  [Qdrant: Filterklauseln](https://qdrant.tech/documentation/concepts/filtering/)
10.  [Qdrant: Sicherheit und Zugriffskontrolle](https://qdrant.tech/documentation/security/)
11.  [Qdrant Preise: kostenlos, Standard und Premium](https://qdrant.tech/pricing/)
12.  [Qdrant auf GitHub](https://github.com/qdrant/qdrant)
13.  [Qdrant Vektor-Benchmarks](https://qdrant.tech/benchmarks/)

## Häufige Fragen

Ist Qdrant im Produktivbetrieb kostenlos?

Ja. Der Server steht unter Apache-2.0, und selbst gehostet gibt es keine Lizenzgebühr, keine Feature-Schranke und keinen Telemetrie-Zwang. Der Preis sind die Betriebsaufgaben: Authentifizierung, TLS, Backups, Shard-Rebalancing und Updates liegen bei Ihnen. Qdrant Cloud ist die verwaltete Alternative, mit einem kostenlosen Tier von einem Knoten, 1 GB RAM und 4 GB Platte.

Qdrant oder pgvector?

Unter einigen Millionen Vektoren, auf einer Datenbank, die Sie ohnehin betreiben, gewinnt pgvector auf allen Feldern außer Durchsatz: eine Erweiterung statt eines Dienstes, den jemand bereuen muss. Qdrant verdient seine Existenz, wenn auf jeder Anfrage ein Metadatenfilter liegt, weil er diesen Filter in die HNSW-Traversierung speisen kann, statt Kandidaten zu holen und wegzuwerfen.

Was kostet Qdrant Cloud?

Der Hersteller veröffentlicht keinen Einstiegspreis. Die Preisseite beschreibt stundenweise Abrechnung nach vCPU, Arbeitsspeicher, Speicher, Backup-Speicher und Inferenz-Token und verweist auf einen Rechner; das kostenlose Tier umfasst 1 GB RAM und 4 GB Platte, Standard bringt ein 99,5-Prozent-Uptime-SLA, Premium ergänzt SSO, private VPC-Links und 99,9 Prozent. Die oft zitierten rund 25 Dollar im Monat für den kleinsten bezahlten Cluster sind eine Schätzung Dritter, kein veröffentlichter Preis.

Was passiert beim Aktivieren der Quantisierung?

Die komprimierten Vektoren liegen neben den Originalen, es geht also nichts verloren und die Quantisierung lässt sich abschalten. Das Neubewerten der Top-k gegen die Originale ist standardmäßig an für binäre Quantisierung und für TurboQuant mit 1, 1,5 und 2 Bit, aus für skalare und Produktquantisierung. Die Produktions-Checkliste verlangt, die Retrieval-Qualität danach neu zu messen, weil manche Embedding-Modelle schlecht quantisieren.

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)