Qdrant, pgvector o Milvus: quina base vectorial et cal

Si has llegit els dos articles anteriors i has arribat a la conclusió que sí, et cal recuperació (el corpus no cap a cap finestra de context, o les dades canvien, o hi ha permisos diferents per usuari), la pregunta següent és avorridament pràctica: on guardes els vectors i com els busques.

Aquest és el tercer article de la sèrie que comença amb el límit del coneixement tàcit i continua amb quan un RAG ja no cal. Aquí deixem la teoria i entrem en tres eines concretes: pgvector, Qdrant i Milvus. No hi ha una resposta universal, però sí criteris clars per triar sense llançar una moneda a l’aire.

Què és, exactament, una base vectorial

Un model d’embeddings converteix un text en una llista de números (un vector) que representa el seu significat. Textos amb significats semblants tenen vectors propers. Una base vectorial guarda milions d’aquests vectors i, davant d’una consulta, en troba els més propers en mil·lisegons, sense comparar-la un per un amb tots els altres (això es diu cerca aproximada del veí més proper, ANN). És el motor que fa possible que un RAG trobi «el fragment rellevant» entre milions de fragments.

Les tres opcions

pgvector no és una base de dades nova: és una extensió de PostgreSQL. Té llicència PostgreSQL (permissiva, no cal preocupar-se’n per a ús comercial) i afegeix dos tipus d’índex: IVFFlat (més ràpid de construir, menys memòria) i HNSW (millor relació entre precisió i velocitat un cop construït, però més car de crear). Si ja tens Postgres (i a substrat.cat el fem servir per als tiquets del panell de client), afegir pgvector és activar una extensió, no muntar infraestructura nova. Com a regla pràctica, no una xifra tancada, sol funcionar bé fins a l’entorn dels deu milions de vectors en un sol node.

Qdrant és una base vectorial pròpia, escrita en Rust, amb llicència Apache 2.0. Es distribueix com un sol binari o contenidor, i és la que més sovint es recomana per defecte per a un RAG en producció: filtratge ràpid (buscar «els vectors semblants, però només dels documents d’aquest client»), latències baixes i molt poca fricció per autoallotjar-la. És una empresa amb inversió de capital risc qui la manté, cosa que val la pena tenir present: no és un problema avui, però és el patró que ha portat canvis de llicència sobtats en altres projectes de codi obert els últims anys.

Milvus és l’opció pensada per a una escala que les altres dues no cobreixen. Arquitectura distribuïda de veritat: separa el que coordina, el que processa i el que emmagatzema (aquest últim, sobre S3 o equivalent). Té llicència Apache 2.0 i el governa la Linux Foundation AI & Data, amb Zilliz com a principal impulsora. És l’elecció quan parles de desenes o centenars de milions de vectors i necessites escalar horitzontalment de veritat, no de créixer una mica més la màquina. El preu és la complexitat operativa: per sota, hi ha etcd, un sistema de cua (Pulsar o Kafka) i emmagatzematge d’objectes. No és un contenidor que aixeques en cinc minuts.

El que diuen (i no diuen) els números

No existeix un benchmark independent i net que compari les tres a igualtat de condicions. El que hi ha són bancs de proves d’algorismes (com ann-benchmarks.com, que sí és independent) i comparatives publicades pels mateixos fabricants, que cal llegir sabent que defensen la seva eina.

Un exemple honest d’això: una prova publicada per l’empresa que fa pgvectorscale (una extensió per accelerar pgvector, per tant, part interessada) va trobar que, amb un 99 % de precisió exigida, Qdrant tenia una latència de cua millor (uns 37 ms al percentil 95, contra uns 60 ms de Postgres) però Postgres amb pgvectorscale aconseguia un rendiment per node més d’onze vegades superior. Els dos números són certs alhora, perquè mesuren coses diferents: latència de la pregunta més lenta contra quantes preguntes per segon aguanta la màquina sencera. Que la font tingui interès en el resultat no vol dir que el número sigui fals, vol dir que cal llegir-lo sabent d’on surt.

La lectura pràctica: si el que t’importa és que cap resposta trigui més del compte, Qdrant té l’avantatge. Si el que t’importa és aguantar molt de trànsit amb el mínim de maquinari, pgvector ben afinat sorprèn per amunt.

El preu

Ni Qdrant Cloud ni Zilliz Cloud (el servei gestionat de Milvus) publiquen una taula de preus fixa: es cobra per ús, amb una calculadora pròpia. Com a orientació aproximada, un projecte petit amb Qdrant Cloud sol moure’s entre 30 i 200 dòlars al mes; Zilliz Cloud, per un milió de vectors de mida habitual, ronda els 80-150 dòlars. Són xifres de tercers, no del fabricant, i cal prendre-les com a ordre de magnitud, no com a pressupost. pgvector no té cost propi: pagues el que ja pagues per Postgres.

Quina tries

• Ja tens Postgres i el corpus és de mida moderada (fins a desenes de milions de vectors): pgvector. No afegeixes cap peça nova al sistema, i les dades vectorials viuen a la mateixa transacció que la resta.
• Necessites la millor cerca filtrada i vols autoallotjar-ho sense complicacions: Qdrant. És, avui, l’opció per defecte més citada per a un RAG en producció, i amb raó: un binari, latències baixes, filtratge ràpid.
• Parles de centenars de milions de vectors o més, i necessites escalar horitzontalment de veritat: Milvus, acceptant que arrossegues etcd, una cua i emmagatzematge d’objectes com a peces addicionals a mantenir.

I si el corpus és petit i estable, val la pena preguntar-se abans de triar cap de les tres si, seguint el segon article, no et sortiria més senzill posar-ho tot dins la finestra de context i estalviar-te aquesta decisió sencera.

Sigui quina sigui la base que triïs, val la pena tancar la sèrie on la vam obrir: cap d’aquestes tres eines fa que el sistema sàpiga res que ningú hagi escrit abans. Indexen, cerquen i recuperen text amb una eficiència notable, però el que hi ha per sota, el criteri, l’excepció, el «per què ho fem així», continua sense estar-hi fins que algú es pren la molèstia d’escriure-ho.