-- Activarea extensiei și crearea unui index HNSW pentru performanță
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id bigserial PRIMARY KEY,
content text,
embedding vector(1536) -- Dimensiunea pentru text-embedding-3-small
);
-- Creăm indexul HNSW pentru căutări rapide sub 100ms
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- Căutare semantică simplă
SELECT content FROM documents
ORDER BY embedding <=> '[0.12, -0.56, ...]'
LIMIT 5;M-am tot lovit de faza asta cu vector search-ul în ultima vreme, mai ales că toată lumea vrea un RAG (Retrieval-Augmented Generation) peste documentele proprii. Prima reacție e să mergi pe Pinecone că e peste tot în tutoriale, dar te prinzi repede că planul lor free e destul de restrictiv și te trezești cu latențe mari dacă nu plătești serios.
Am testat trei variante care chiar fac sens pentru un side-project unde nu vrei să arunci cu banii, dar vrei să se miște decent. Am avut un proiect recent cu vreo 15.000 de embeddings pe care trebuia să fac search semantic și mi-am dat seama că alegerea bazei de date îți mănâncă mai mult timp decât codul propriu-zis de AI.
pgvector: Dacă ai deja Postgres, nu te mai complica
Asta e recomandarea mea numărul unu pentru 90% din cazuri. Dacă proiectul tău rulează deja pe Postgres, e suficient să instalezi extensia pgvector. Nu trebuie să mai gestionezi încă un serviciu, încă un set de backup-uri sau alte credențiale în .env.
Am observat că la un set de date sub 100k de vectori, performanța e absolut ok pentru un side-project. Trade-off-ul e că trebuie să înveți diferența dintre index-ul IVFFlat și HNSW. IVFFlat e rapid de construit dar mai lent la căutare dacă vrei precizie, pe când HNSW e tăticul căutărilor rapide, dar îți mănâncă mult RAM. La un proiect mic, am economisit cam 20% din timpul de dezvoltare doar pentru că n-am stat să fac sync între baza de date principală și una externă de vectori.
Qdrant: Performanță de Rust când lucrurile devin serioase
Când am sărit de 50k de vectori cu metadata complexă, pgvector a început să gâfâie puțin pe un VPS ieftin. Aici a intrat în scenă Qdrant. E scris în Rust, e incredibil de rapid și are un feature care mie îmi place la nebunie: filtrarea payload-ului înainte de search-ul vectorial.
Majoritatea bazelor de date fac search-ul și apoi filtrează rezultatele. Qdrant face invers sau în paralel, ceea ce înseamnă că dacă vrei să cauți „doar în documentele utilizatorului X”, interogarea e instantanee. Planul lor Managed are un free tier generos de 1GB de RAM, care e arhisuficient pentru vreo 20-30k de vectori de dimensiune 1536 (standardul OpenAI). Nasol e că dacă depășești limita, prețurile sar destul de brusc.
Chroma: Cel mai bun pentru prototipare locală
Chroma e preferatul celor care vin din zona de Python și vor ceva care „pur și simplu merge”. Poți să-l rulezi în memorie sau pe disc local cu o singură linie de cod. E excelent când vrei să vezi dacă ideea ta de RAG funcționează fără să te chinui cu Docker sau instanțe în cloud.
Totuși, la capitolul trade-offs, Chroma e încă destul de „tânăr”. Am pățit ca la un update de versiune să se schimbe formatul de stocare și a trebuit să re-indexez tot. Nu l-aș folosi în producție pentru ceva critic, dar pentru un tool intern sau un experiment, e de departe cel mai rapid de pus pe picioare.
Concluzia mea
Dacă vrei stabilitate și ai deja Postgres, mergi pe pgvector. Dacă ai nevoie de viteză brută și filtrare complexă pe un volum mai mare de date, Qdrant e regele. Chroma rămâne în sandbox pentru când te joci cu notebook-uri și vrei rezultate în 5 minute.
Voi ce folosiți pentru stocat embeddings? V-ați lovit de limitări de memorie pe VPS-urile mici?