pgvector 10M+ soron · index-döntés, query-mintak, valodi teljesítmény

A pgvector-nek 'játék-skálájú' a híre. A hír elavult. Produkciós RAG-ot üzemeltetünk 10M+ soros pgvector-ben, p95 query-latencia 80ms alatt. A kulcs a megfelelo index + a szürö-baráti query. Itt van hogyan.

HNSW vs IVFFlat

• HNSW: jobb recall, több memória, lassabb build. 2024+ default választás.
• IVFFlat: gyorsabb build, kevesebb memória, rosszabb recall. Csak ha gyakran újra-építesz.
• Egyik sem: sequential scan jó ~500k soronként jó szelektivitással.

A szürt keresés a nehéz rész

A legtöbb RAG query tenant_id, document_type vagy recency alapján szür a hasonlóság elott. A pgvector 0.5+ hozta a rendes szürt HNSW-t, de a naiv query-k még mindig túl sokat scan-elnek. Mindig elobb a szelektív szürot alkalmazd.

-- JÓ: tenant-szuro elobb szukit, vektor-kereses kicsi halmazon
SELECT * FROM chunks
WHERE tenant_id = $1 AND created_at > now() - interval '30 days'
ORDER BY embedding <=> $2
LIMIT 10;

-- Index: btree (tenant_id, created_at) + HNSW az embedding-en

Valodi szamok

• Jogi iroda RAG · 12M chunk · HNSW m=16 ef=64 · p50 38ms, p95 72ms.
• Hir-aggregator · 8M cikk · HNSW m=12 ef=40 · p50 24ms, p95 58ms.
• SaaS support bot · 4M ticket · HNSW + tenant-szuro · p50 18ms, p95 44ms.