Trieve vs Vespa vs Qdrant: RAG voor servicehandleidingen

Het is 23:14 op een dinsdag in een sluis voor de cleanroom op de High Tech Campus. Een field engineer staat in een papieren overall, telefoon in de ene hand, momentsleutel in de andere. Hij heeft de O-ring spec nodig voor een subassembly van een vacuümkamer, en de servicehandleiding van 1.412 pagina's op zijn scherm heeft drie revisies over elkaar heen liggen. Het verkeerde getal betekent een reparatie van zes cijfers de volgende ochtend.

Dat is de situatie die de retrieval-laag achter een handleidingen-agent moet overleven. We hebben zes weken besteed aan het vergelijken van drie opties voor een toeleverancier van halfgeleiderapparatuur met 34 mensen. Hun engineers draaiden ruwweg 140.000 zoekopdrachten per maand over 92.000 PDF-pagina's. Dit is wat we vonden, gescoord op de drie getallen waar de klant echt om gaf: kosten per 1.000 queries, freshness-latency als een handleiding verandert, en wie de inkoopauditor in februari antwoord kan geven.

De opdracht

De corpus bestond uit ongeveer 6.000 documenten, vooral assemblage-instructies, kalibratieprocedures en after-action reports van service engineers in het veld. Nieuwe revisies komen ruwweg twee keer per week binnen. Oude revisies blijven hangen omdat een deel van de geïnstalleerde apparatuur vijftien jaar oud is en nog onder contract staat.

De klant was helder over wat de retrieval-laag moest doen. Voorspelbare kosten per 1.000 queries. Een verdedigbaar antwoord op "hoe stale mag een net geüploade revisie zijn voordat een engineer het verkeerde aandraaimoment krijgt". En een geloofwaardig content-provenance spoor voor de jaarlijkse inkoopaudit, die meer leest als een vliegtuigonderhoudsaudit dan als een softwarereview.

We hebben drie opties end-to-end getest met een sample van 4.000 echte queries uit hun support-inbox.

Trieve als de managed default

Trieve is de YC-backed managed RAG-laag. Je upload chunks, je belt een HTTP-endpoint, je krijgt resultaten terug met hybrid search en reranking al aangesloten. Hun pipeline is BM25 plus dense embeddings plus een optionele cross-encoder rerank.

Time to first useful answer was hier het snelst van de drie. Ongeveer een dag om ingestion aan te sluiten, een halve dag om de bestaande search calls in de agent te vervangen. De SDK is eerlijk over wat hij doet en het dashboard laat zien wat er terugkwam voor een bepaalde query.

import requests

resp = requests.post(
    "https://api.trieve.ai/api/chunk",
    headers={
        "Authorization": f"Bearer {API_KEY}",
        "TR-Dataset": DATASET_ID,
    },
    json={
        "chunk_html": chunk_text,
        "tracking_id": f"manual:{doc_id}:p{page}:c{idx}",
        "tag_set": ["assembly-note", f"rev:{revision}"],
        "metadata": {
            "doc_id": doc_id,
            "page": page,
            "revised_at": revised_at,
        },
    },
)
resp.raise_for_status()

Waar we steeds tegenaan liepen, was het plafond op controle. Het embedding-model is van hen. De reranker is van hen. De versienummers staan niet in onze git-repository. Toen de klant vroeg "welk model produceerde deze score op 4 februari", was het eerlijke antwoord "het model dat Trieve die dag had gedeployed". Voor veel producten is dat prima. Voor dit product niet.

Vespa Cloud voor controle in de machinekamer

Vespa is de search engine die Yahoo open source maakte na meer dan tien jaar productie. Vespa Cloud is de managed variant. Hij doet dense vectors, sparse vectors, lexical search, ranking expressions en tensor math in één engine, en je schrijft de ranking expression zelf.

We hebben een schema opgezet met drie velden: een BM25-geïndexeerde body, een 768-dim dense embedding van een domein-getuned BGE-model, en een ColBERT-stijl late-interaction tensor die alleen in de tweede ranking-fase wordt gebruikt. De eerste iteratie kostte ons vier engineering-dagen, vooral omdat phased ranking een leercurve heeft en de documentatie ervan uitgaat dat je al in cheap-then-expensive cascades denkt. De Vespa phased ranking documentatie is de canonieke referentie en het lezen waard voordat je je eerste schema schrijft.

Vespa Cloud factureert per resource (vCPU, geheugen, disk), niet per query. Bij 140k queries per maand op 92k pagina's was de resource footprint klein genoeg dat één productienode met een hot standby het comfortabel aankon.

Het provenance-verhaal is hier het sterkst van de drie. Elk veld, elk ranking-gewicht, elke modelversie staat in een YAML-bestand in onze git-repository. De deployment is een git push. Als inkoop vraagt "laat me de zoekconfiguratie op 4 februari zien", wijzen we een commit hash aan en draaien we 'm opnieuw.

Qdrant met een ColBERT-v2 reranker

De derde optie was de self-hosted stack die we voor de meeste klanten draaien. Qdrant voor dense vectors, een kleine Tantivy-sidecar voor BM25, en ColBERT-v2 als reranker. De documentatie van Qdrant is helder genoeg dat een back-end engineer 'm in een middag aan het indexeren krijgt. ColBERT-v2 van Stanford is zwaarder om te draaien: de index is groter dan je verwacht, de GPU-keuze maakt uit, en de rerank-latency staat of valt met de batch size.

from qdrant_client import QdrantClient
from rerank.colbert import colbert_rerank

qdrant = QdrantClient(host="qdrant.internal", port=6333)

def search(query_text, query_vec, k_dense=200, k_final=10):
    dense = qdrant.search(
        collection_name="manuals",
        query_vector=query_vec,
        limit=k_dense,
        query_filter={"must": [{"key": "is_current", "match": {"value": True}}]},
        with_payload=True,
    )
    candidates = [(h.id, h.payload["text"]) for h in dense]
    return colbert_rerank(query_text, candidates)[:k_final]

We hebben het opgezet als een Hetzner CCX33 voor Qdrant (16 vCPU, 64GB, NVMe) en een aparte AX52 met één NVIDIA L4 voor de reranker, beide met hot replicas. De hardwarerekening kwam onder de 300 euro per maand uit.

De verborgen kosten waren wij zelf. De chunking-pipeline, de ingestion queue, de staleness check, de rerank-cascade en de observability moesten allemaal geschreven worden. Ruwweg zes engineering-dagen voor de eerste versie, en daarna ongeveer één ops-dag per maand.

Kosten per duizend queries

Bij 140.000 queries per maand ziet de kostenstructuur er als volgt uit. De getallen zijn afgeronde schattingen uit onze testdeployments en de publieke pricing pages; jouw factuur zal anders zijn.

Trieve, op een mid-tier plan met de rerank-toggle aan, zat in de orde van 4 tot 7 euro per 1.000 queries. De prijs per query is laag; wat de totaalprijs omhoog duwt, is de per-chunk storage als je twee of drie revisies van elke pagina bewaart.

Vespa Cloud, op de kleinste productieconfiguratie die de corpus met een hot standby hield, kwam uit op ongeveer 2 tot 4 euro per 1.000 queries. Omdat de resource-kosten op deze schaal zwaarder wegen dan het aantal queries, is de prijs ruwweg vlak ten opzichte van het volume totdat je nodes moet toevoegen.

Self-hosted Qdrant + ColBERT-v2 was het goedkoopst op hardware, ruim onder de 0,50 euro per 1.000 queries. Als je de bouwkosten over twaalf maanden afschrijft, kom je all-in uit op ruwweg 1,50 tot 2 euro per 1.000 queries in het eerste jaar en duidelijk onder een euro in het tweede jaar.

De rangorde verschuift met je tijdshorizon. Wil je in drie weken live en daarna vergeten, dan wint Trieve. Heb je een back-end team en een horizon van vijf jaar, dan is de self-hosted stack veruit het goedkoopst.

Freshness als een assemblage-instructie verandert

Een field engineer uploadt om 14:32 een herziene assemblage-instructie. Wanneer stopt de agent met het teruggeven van de oude versie?

Trieve: ruwweg 90 seconden tot 4 minuten van upload tot eerste vindbaar resultaat in onze tests, afhankelijk van het aantal chunks. Hun ingest is asynchroon en de backlog was kort op de dagen dat we maten.

Vespa Cloud: onder de 10 seconden in de praktijk. Vespa indexeert in realtime en rankt het nieuwe document bij de volgende query. Hier zie je zijn "search engine, geen vector database" erfgoed terug.

Qdrant: onder de 5 seconden tot de dense vector queryable is. De ColBERT-index merge kan een paar minuten achterlopen als compaction op de standaardinstellingen blijft staan. We hebben een kleine "staat de nieuwste revisie al geïndexeerd" probe geschreven die de agent voor het antwoorden aanroept, omdat de auditclausule zegt dat we geen stale revisie mogen teruggeven als er een nieuwe bestaat.

Provenance en de audit in februari

Inkoopaudits in de halfgeleiderwereld willen een content-provenance spoor. Voor elk antwoord dat de agent op een bepaalde dag heeft gegeven, wil de auditor vier dingen zien: welke documentrevisie werd teruggegeven, welke versie van het embedding-model de vector produceerde, welk reranker-checkpoint de kandidaten scoorde, en welke ranking-parameters actief waren.

Trieve laat een deel hiervan zien in hun dashboard, maar de versies van het embedding-model en de reranker zijn van de leverancier. We konden geen git commit aanwijzen en zeggen "dit was de configuratie die dag". Voor een klant wiens eigen klanten TSMC en ASML zijn, was dat gat diskwalificerend.

Vespa Cloud was het makkelijkst te auditen. De volledige ranking-specificatie staat in version control. Embeddings komen uit een modelbestand dat met de deployment meegaat. De auditor pakt de commit hash, jij reconstrueert de deployment, je draait de query opnieuw, de ranking klopt.

Qdrant + ColBERT-v2 kan het provenance-verhaal van Vespa evenaren, maar je moet het zelf bouwen. Je hebt een stabiel manifest per query nodig dat de corpus-snapshot id, de embedding-model hash, de reranker-checkpoint hash en de ranking-parameters vastlegt. We zijn uiteindelijk een klein "audit packet" gaan schrijven dat de search wrapper bij elke query naar een logging bucket stuurt, geïndexeerd op query id en zeven jaar bewaard.

Wat we voor het Eindhovense team hebben opgeleverd

We hebben de self-hosted Qdrant + ColBERT-v2 stack uitgerold met een provenance-log in Vespa-stijl eromheen. De doorslaggevende factor was niet kosten. Het was de audit. De klant wilde een configuratie die ze end-to-end zelf bezitten, in hun eigen git-repository, met de optie om het embedding-model te wisselen zonder opnieuw te onderhandelen met een leverancier.

Hadden we gebouwd voor een bedrijf van 200 man dat het hele zoekprobleem wilde uitbesteden en er nooit meer aan wilde denken, dan was het Vespa Cloud geworden. Hadden we een prototype van zes weken gebouwd om te bewijzen dat de agent nuttig was voordat er in retrieval geïnvesteerd werd, dan Trieve.

Toen we deze handleidingen-agent bouwden, was waar we tegenaan liepen het audit packet zelf. We hebben dat opgelost door het manifest op querytijd te schrijven in plaats van op antwoordtijd, zodat het spoor blijft bestaan ook als de antwoordgeneratie-stap faalt. Dat patroon is uit een paar late avonden voortgekomen en is nu standaard in de AI-agents die wij opleveren.

Een audit van vijf minuten die je vandaag kunt doen

Heb je nu een RAG-systeem in productie, pak dan één query uit de logs van gisteren. Vraag jezelf af: welke documentrevisie, welke versie van het embedding-model, welk reranker-checkpoint produceerde dat antwoord. Kun je niet alle drie beantwoorden vanuit een git commit of een gelogd manifest, dan heb je nog geen provenance-spoor. Dat is het gat dat je wilt dichten voordat de volgende audit op je bureau ligt.