Data Panda haalt data uit je CRM, helpdesk, productcatalogus, kennisbank en warehouse, berekent de embeddings op een vast ritme, en zet ze in Qdrant-collections. Vanaf daar lezen je assistent, je zoekveld en je recommendation engine uit dezelfde vector-index, en houdt het warehouse bij wat geindexeerd is en hoe het scoort.
Qdrant is een vector similarity search engine en database geschreven in Rust, uitgebracht onder de Apache 2.0-licentie. Andrey Vasnetsov en Andre Zayarni richtten het bedrijf in 2021 op in Berlijn, nadat Andrey een productie-klare vector engine vanaf nul had gebouwd en op GitHub had gezet. Het team levert vandaag de open-source database naast Qdrant Cloud op AWS, GCP en Azure, een Hybrid Cloud-optie die de data plane in je eigen Kubernetes draait, en een Private Cloud-variant voor air-gapped omgevingen.
Het datamodel is overzichtelijk: een collection bevat points, en elke point draagt een of meer dense vectors, optioneel sparse vectors, en een JSON-payload met de metadata waarop je wil filteren. De HNSW-index doet de approximate nearest-neighbour zoek, payload-indexering houdt filters goedkoop, en quantisatie drukt het RAM-gebruik bij grote collections. REST en gRPC zijn allebei first-class, met officiele clients in Python, JS/TS, Go, Rust, Java en .NET.
Voor een Data Panda-klant is de rol helder: Qdrant is de vector-laag, niet de system of record. Het warehouse is waar de brondocumenten, tickets, producten en kennisartikels staan; Qdrant is waar de geembedde representatie staat zodat een assistent of een zoekveld in milliseconden de juiste slice vindt. De collection-state terughalen naar het warehouse is wat de loop meetbaar maakt, want hit-rate, drift en de kwaliteit van de queries komen pas in beeld als de vector-kant en de bron-kant in hetzelfde model zitten.
Collection-state, query-logs en drift opgevolgd naast de brondata, zodat de kwaliteit van RAG meetbaar wordt.
Gelijkenis tussen producten, content of accounts geserveerd vanuit een vector-index in plaats van nachtelijke batchjobs.
Vervang letterlijke keyword-zoek door hybride dense plus sparse retrieval op dezelfde content.
Een lijst van concrete rapporten, automatisaties en AI-toepassingen die we op Qdrant-data hebben gebouwd. Kies er een die bij je situatie past.
Waarom een vector-database naast ons warehouse draaien in plaats van vector search in het warehouse zelf?
Vector-functies in het warehouse zijn nuttig voor batch-scoring en offline analyse, waar een query van enkele seconden geen probleem is. Een assistent of zoekveld voor eindgebruikers heeft retrieval onder de 100 milliseconden op het 99ste percentiel nodig, met payload-filters en hybride scoring op elke call. Daar is Qdrant voor gebouwd: HNSW met one-stage filtering, sparse plus dense, quantisatie. We houden ze meestal allebei, met het warehouse als source of truth en Qdrant als de live serveerlaag.
Cloud, Hybrid Cloud of zelf hosten op onze eigen Kubernetes?
Qdrant Cloud is fully managed op AWS, GCP en Azure en haalt het operationele werk weg. Hybrid Cloud draait de data plane in je eigen Kubernetes tegen de Qdrant control plane aan, en dat is meestal de keuze wanneer de embeddings op klantendata zitten die je perimeter niet uit mag. Self-hosted op de Apache 2.0-build is op schaal het goedkoopst en het meest flexibel, maar je draagt zelf de upgrades, snapshots en replicatie. We dimensioneren de drie opties op de echte collection-grootte, het queryvolume en de data-residency-regels voor we een keuze aanbevelen.
Hoe weten we dat onze RAG echt beter wordt en niet gewoon vaker live gaat?
Door collection-state en query-logs uit Qdrant terug naar het warehouse te halen en te joinen op de brondata. Hit-rate, het aandeel queries dat leeg of met lage score terugkomt, de drift tussen embedding-versies en de vragen die negatieve feedback krijgen worden meetbaar op hetzelfde model als de broncontent. Zonder die loop is de kwaliteit van RAG wat de laatste persoon die het testte zich herinnert.
Finance krijgt een helder zicht op wat de vector-laag echt kost per use case, niet per cluster. Collection-grootte, upsert-volume en query-ritme per workload (RAG, zoek, aanbevelingen) koppelen aan de rest van de stack, zodat de AI-lijn op de cloudfactuur verdedigbaar wordt met gebruikscijfers in plaats van schattingen.
Sales ziet lookalike-accounts gerangschikt op gelijkenis met closed-won deals via CRM en productgebruik, geserveerd vanuit een Qdrant-collection. Vertegenwoordigers ranken de pipeline niet meer op buikgevoel, want het warehouse en de vector-index zijn het eens over wat 'lijkt op onze beste klanten' betekent.
Support- en platformteams krijgen een assistent die de juiste macro, KB-artikel of vorig ticket citeert in plaats van te gokken, en ze zien de vector-laag op dezelfde plek als de rest van de stack. Lege queries, upsert-vertraging, query-latency-percentielen en embedding-versie-drift staan naast de versheid van de brondata, zodat RAG-kwaliteit geen mening meer is.
Je houdt de rapporteringstool die je al hebt. Wij koppelen hem aan het warehouse waar je Qdrant-data staat.
OAuth-authenticatie. Standaard read-only. Wij tekenen een DPA en je admin houdt de sleutels.
Data stroomt naar je warehouse op het schema dat jij kiest. Bijna real-time of 's nachts, aan jou. Jij bent eigenaar.
We bouwen het eerste dashboard, de eerste workflow of AI-toepassing samen met jou, en geven de sleutels over. Of we blijven erbij voor doorlopende levering.
Wij zetten de basis op. Jouw team bouwt erop verder.
Beste match Teams die al een BI-analist of data engineer in huis hebben en zelf willen bouwen.
Wij bouwen het geheel, van A tot Z.
Beste match Teams zonder BI- of dev-capaciteit in huis. Jij zegt wat je nodig hebt en wij leveren het.
Jij. Ze komt in jouw warehouse terecht, op jouw cloud-account. Wij verkopen ze niet door en aggregeren ze niet. Stop je met ons, dan blijft het warehouse van jou en blijft het draaien.
Bijna real-time voor de meeste operationele systemen. Voor zwaardere bronnen plannen we per uur of per nacht. Je kiest op basis van wat de rapporten nodig hebben.
Nee. Heb je er geen, dan helpen we je er een kiezen en zetten we het op als deel van de eerste levering. Gangbare startpunten zijn Snowflake, Microsoft Fabric of een kleine Postgres-start.
Brondata uit je CRM, helpdesk, productcatalogus, kennisbank of warehouse wordt waar nodig in chunks geknipt, geembed met het model dat je koos, en als Qdrant-points in de juiste collection geupsert. Elke point draagt de dense vector, optioneel sparse vectors voor hybrid search, en een payload met de metadata waarop je wil filteren (tenant, taal, product, status, source-id). De originele record blijft in het warehouse, zodat de embedding herbouwd of vervangen kan worden zonder de bron te verliezen.
Collection-state (grootte, point-aantallen, laatste upsert per bron), query-logs waar je die bijhoudt, scoring-metadata en alle feedback-events die je vanuit de assistent of het zoekveld registreert. Dat is wat hit-rate, drift tussen embedding-versies en content-gaten zichtbaar maakt op hetzelfde model als de brondata, in plaats van te gokken op basis van enkele steekproeven.
We bekijken je Qdrant-opzet en de systemen eromheen. Samen kiezen we wat we als eerste bouwen.