Վեկտորային բազաներ

01Embedding-ներ՝ իմաստը որպես կոորդինատներ

Embedding մոդելը կոնտենտի կտորը վերածում է վեկտորի, օրինակ՝ 1,024 թվի։ Պատկերացրեք հսկայական քարտեզ, որտեղ նման իմաստները մոտ են միմյանց․ «dog»-ը մոտ է «puppy»-ին և հեռու «invoice»-ից։ Մոդելը վարժեցված է այնպես, որ այս քարտեզի վրա հեռավորությունն արտացոլի նմանությունը։ Դուք մեկ անգամ embed եք անում ձեր փաստաթղթերը և պահում վեկտորները․ հարցման ժամանակ նույն մոդելով embed եք անում հարցը և փնտրում ամենամոտ հարևաններին։ Նմանությունը չափվում է cosine similarity-ով (վեկտորների միջև անկյունը), dot product-ով կամ Euclidean (L2) հեռավորությամբ։ Տեքստային մոդելների մեծ մասը արտադրում է նորմալացված վեկտորներ, այնպես որ cosine-ը և dot product-ը նույն կերպ են դասակարգում։

• Չափողականություն (dimension)՝ քանի թիվ ունի յուրաքանչյուր վեկտոր (օրինակ՝ 384, 768, 1024, 1536, 3072)։
• Փաստաթղթերի և հարցումների համար միշտ օգտագործեք նույն մոդելը․ տարբեր մոդելների վեկտորները համեմատելի չեն։
• Մոդելը փոխելը նշանակում է ամեն ինչ վերա-embed անել, այնպես որ յուրաքանչյուր վեկտորի հետ գրանցեք մոդելի անունը և տարբերակը։

02Ինչո՞ւ ճշգրիտ որոնումը չի մասշտաբավորվում, և ինչպես է օգնում ANN-ը

Ճշգրիտ որոնումը հարցումը համեմատում է յուրաքանչյուր պահված վեկտորի հետ։ 10,000 վեկտորի համար դա լավ է, իսկ 1,024 չափողականությամբ 50 միլիոնի համար՝ չափազանց դանդաղ։ Approximate nearest neighbour (ANN) ինդեքսները մի փոքր ճշգրտություն փոխանակում են հսկայական արագության հետ։ HNSW-ն (Hierarchical Navigable Small World) կառուցում է շերտավոր գրաֆ․ վերին շերտերը նոսր մայրուղիներ են, ստորին շերտերը՝ խիտ տեղական փողոցներ։ Որոնումը սկսվում է վերևից, ագահաբար շարժվում դեպի հարցումը և իջնում։ IVF-ը (inverted file) վեկտորները կլաստերավորում է և որոնում միայն ամենամոտ կլաստերներում։ Recall-ը չափում է որակը՝ իրական ամենամոտ հարևանների այն մասը, որը վերադարձնում է ինդեքսը։ Լավ կարգավորումները մի քանի միլիվայրկյանում հասնում են 95–99% recall-ի։

• HNSW՝ recall/արագություն լավագույն փոխզիջումը, ավելի շատ հիշողություն, ավելի դանդաղ կառուցում։
• IVF՝ ավելի քիչ հիշողություն և ավելի արագ կառուցում, պահանջում է վարժեցում տվյալների վրա և probe-երի կարգավորում։
• Quantization՝ վեկտորների պահում ավելի քիչ բիթերով (int8, binary)՝ հիշողությունը կրճատելու համար, ճշգրտության համար rescoring-ով։

03Սկսել pgvector-ով PostgreSQL-ում

Եթե արդեն աշխատեցնում եք PostgreSQL, pgvector-ը հաճախ ամենապարզ սկիզբն է․ վեկտորներն ապրում են ձեր տողերի կողքին, անվճար ստանում եք տրանզակցիաներ, join-եր, backup-ներ և access control, իսկ ֆիլտրերը սովորական SQL են։ Extension-ն ավելացնում է vector տիպը (և halfvec՝ 16-բիթանոց պահման համար), հեռավորության օպերատորներ (<->՝ L2-ի համար, <=>՝ cosine distance-ի համար, <#>՝ բացասական inner product-ի համար) և HNSW ու IVFFlat ինդեքսներ։ Օգտագործեք ձեր հեռավորությանը համապատասխանող operator class․ vector_cosine_ops-ով կառուցված ինդեքսն օգնում է միայն այն հարցումներին, որոնք դասավորում են <=>-ով։ Բարձրացրեք hnsw.ef_search-ը ավելի լավ recall-ի համար՝ latency-ի որոշակի գնով։

1CREATE EXTENSION IF NOT EXISTS vector;
2 
3CREATE TABLE doc_chunks (
4  id         bigserial PRIMARY KEY,
5  doc_id     bigint NOT NULL,
6  tenant_id  int    NOT NULL,
7  content    text   NOT NULL,
8  embedding  vector(1024) NOT NULL
9);
10 
11CREATE INDEX ON doc_chunks USING hnsw (embedding vector_cosine_ops)
12  WITH (m = 16, ef_construction = 64);
13 
14SET hnsw.ef_search = 100;
15SELECT id, content, 1 - (embedding <=> $1) AS similarity
16FROM doc_chunks WHERE tenant_id = 7
17ORDER BY embedding <=> $1 LIMIT 10;

04Առանձին վեկտորային բազաներ

Առանձին engine-ները, ինչպիսիք են Qdrant-ը, Weaviate-ը, Milvus-ը և Pinecone-ը, կառուցված են vector որոնման շուրջ։ Դրանք առաջարկում են արագ ֆիլտրված որոնում, quantization, sharding node-երի միջև, multi-tenancy ֆունկցիաներ, sparse վեկտորներ hybrid որոնման համար և կառավարվող ամպային տարբերակներ։ Դուք պահում եք point-եր, որոնք բաղկացած են ID-ից, մեկ կամ մի քանի վեկտորից և payload-ից (մետատվյալներ), որով ֆիլտրում եք։ Փոխզիջումը ևս մեկ համակարգ է, որը պետք է աշխատեցնել, պաշտպանել և սինքրոն պահել ձեր հիմնական բազայի հետ։ Գործնական կանոն՝ մի քանի միլիոն վեկտորից ցածր և չափավոր թրաֆիկի դեպքում pgvector-ը կամ ձեր գոյություն ունեցող որոնման շարժիչը սովորաբար բավարար են․ տասնյակ միլիոնավոր վեկտորների, ծանր ֆիլտրման կամ latency-ի խիստ թիրախների դեպքում առանձին engine-ն արդարացնում է իրեն։

1# Qdrant: create a collection and search with a filter (HTTP API)
2curl -X PUT http://localhost:6333/collections/docs -H 'Content-Type: application/json' \
3  -d '{ "vectors": { "size": 1024, "distance": "Cosine" } }'
4 
5curl -X POST http://localhost:6333/collections/docs/points/query \
6  -H 'Content-Type: application/json' -d '{
7    "query": [0.01, 0.12, 0.03],
8    "filter": { "must": [ { "key": "tenant_id", "match": { "value": 7 } } ] },
9    "limit": 10, "with_payload": true
10  }'

05Hybrid որոնում և reranking

Վեկտորները հիանալի են իմաստի հարցում, բայց թույլ են ճշգրիտ token-ների հարցում՝ ապրանքների կոդեր, անուններ, սխալի հաղորդագրություններ։ Keyword որոնումը (BM25) հակառակն է։ Hybrid որոնումն աշխատեցնում է երկուսն էլ և միավորում ցուցակները, ամենից հաճախ reciprocal rank fusion-ով (RRF), որտեղ յուրաքանչյուր փաստաթուղթ յուրաքանչյուր ցուցակում ստանում է 1 / (k + rank) score, և գումարները որոշում են վերջնական հերթականությունը։ RRF-ը score-ի նորմալացում չի պահանջում, և հենց դրա համար է հանրաճանաչ։ Միավորելուց հետո cross-encoder reranker-ը կարող է վերագնահատել top 50–100 թեկնածուներին՝ կարդալով հարցումը և փաստաթուղթը միասին․ այն ավելի դանդաղ է, բայց շատ ավելի ճշգրիտ, այնպես որ աշխատում է միայն կարճ ցուցակի վրա։

1-- Hybrid in PostgreSQL: full-text + vector, merged with RRF (k = 60)
2WITH kw AS (
3  SELECT id, row_number() OVER (ORDER BY ts_rank(tsv, q) DESC) AS r
4  FROM doc_chunks, websearch_to_tsquery('english', $2) q
5  WHERE tsv @@ q ORDER BY r LIMIT 50
6), vec AS (
7  SELECT id, row_number() OVER (ORDER BY embedding <=> $1) AS r
8  FROM doc_chunks ORDER BY embedding <=> $1 LIMIT 50
9)
10SELECT id, sum(1.0 / (60 + r)) AS score
11FROM (SELECT * FROM kw UNION ALL SELECT * FROM vec) s
12GROUP BY id ORDER BY score DESC LIMIT 10;

06HNSW-ի կարգավորում՝ m, ef_construction, ef_search

m-ը յուրաքանչյուր node-ի կապերի քանակն է։ Ավելի բարձր m-ը բարելավում է recall-ը բարձր չափողականությամբ տվյալների վրա, բայց մեծացնում է հիշողությունը և կառուցման ժամանակը․ 16-ը տարածված լռելյայն արժեք է, 32–64՝ բարդ dataset-երի համար։ ef_construction-ը թեկնածուների ցուցակի չափն է կառուցման ժամանակ․ ավելի բարձրը նշանակում է ավելի լավ գրաֆ և ավելի դանդաղ insert-ներ (64–200-ը բնորոշ է)։ ef_search-ը թեկնածուների ցուցակն է հարցման ժամանակ և runtime-ի հիմնական կարգավորիչը․ ավելի բարձրը նշանակում է ավելի լավ recall և ավելի շատ latency, և այն պետք է առնվազն LIMIT-ի չափ լինի։ Կարգավորեք էմպիրիկ կերպով․ վերցրեք 1,000 նմուշային հարցում, sequential scan-ով հաշվեք ճշգրիտ հարևաններին, ապա փոփոխեք ef_search-ը և գծեք recall at 10-ն ընդդեմ p95 latency-ի։ HNSW-ի կառուցումը հիշողություն է ուտում․ PostgreSQL-ում կառուցման համար բարձրացրեք maintenance_work_mem-ը և max_parallel_maintenance_workers-ը։

1-- Build faster with more memory and workers (PostgreSQL)
2SET maintenance_work_mem = '4GB';
3SET max_parallel_maintenance_workers = 7;
4CREATE INDEX CONCURRENTLY idx_chunks_emb
5  ON doc_chunks USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 128);
6 
7-- Filtered queries: keep scanning until enough rows match (pgvector 0.8+)
8SET hnsw.iterative_scan = relaxed_order;

07Հիշողություն, quantization և rescoring

1,024 չափողականությամբ float32 վեկտորը զբաղեցնում է 4 KB։ Դրանցից տաս միլիոնը մոտ 40 GB է՝ մինչև ինդեքսի overhead-ը, և HNSW-ն ուզում է, որ տաք մասը լինի RAM-ում։ Quantization-ը փոքրացնում է սա։ Half precision-ը (halfvec pgvector-ում) կիսով չափ կրճատում է չափը՝ գրեթե առանց recall-ի կորստի։ Scalar quantization-ը դեպի int8 կրճատում է չորս անգամ։ Binary quantization-ը պահում է մեկ բիթ յուրաքանչյուր չափողականության համար՝ 32 անգամ ավելի փոքր, և զարմանալիորեն լավ է աշխատում շատ ժամանակակից embedding մոդելների վրա, երբ համադրվում է rescoring-ի հետ․ կոմպակտ ինդեքսում որոնեք, ասենք, top 200 թեկնածուներին, ապա վերադասակարգեք նրանց ամբողջական ճշգրտության վեկտորներով։ Qdrant-ի, Milvus-ի և Elasticsearch-ի նման engine-ները իրականացնում են այս պատերնը native կերպով․ pgvector-ում կարող եք ինդեքսավորել binary արտահայտություն և rescore անել SQL-ում։

1-- pgvector: binary-quantized index with full-precision rescoring
2CREATE INDEX ON doc_chunks USING hnsw
3  ((binary_quantize(embedding)::bit(1024)) bit_hamming_ops);
4 
5SELECT id FROM (
6  SELECT id, embedding FROM doc_chunks
7  ORDER BY binary_quantize(embedding)::bit(1024) <~> binary_quantize($1)
8  LIMIT 200
9) candidates
10ORDER BY embedding <=> $1 LIMIT 10;

08Վեկտորները թարմ պահել՝ ingestion և վերա-embedding

Վեկտորները ածանցյալ տվյալներ են։ Embedding-ը դիտարկեք որպես pipeline․ երբ փաստաթուղթը փոխվում է, իրադարձությունը (outbox տող կամ queue job) գործարկում է chunking և embedding, և արդյունքը upsert է արվում կայուն ID-ով, ինչպիսին doc_id-ն է գումարած chunk-ի համարը՝ ջնջելով նույն փաստաթղթի հնացած chunk-երը։ Job-երը դարձրեք idempotent և rate-limited, քանի որ embedding API-ներն ունեն quota-ներ։ Մոդելի upgrade-ներին պետք է միգրացիոն պլան․ ստեղծեք նոր սյունակ կամ կոլեկցիա նոր մոդելի համար, backfill արեք ֆոնում, գնահատեք կողք կողքի, ընթերցումները փոխարկեք flag-ի հետևում, ապա ջնջեք հին վեկտորները։ HNSW ինդեքսները մի փոքր վատանում են ծանր update-ներից և delete-ներից․ պլանավորեք պարբերական reindex (REINDEX CONCURRENTLY PostgreSQL-ում) կամ ապավինեք engine-ի optimiser-ին։

09Embedding-ների անվտանգություն և գաղտնիություն

Embedding-ները անանուն չեն։ Հետազոտությունները ցույց են տվել, որ տեքստը կարող է մասնակիորեն վերականգնվել իր embedding-ից, այնպես որ վեկտորներին վերաբերվեք նույն զգայունությամբ, ինչ աղբյուր կոնտենտին։ Access control-ը պարտադրեք հարցման ժամանակ՝ tenant-ի և թույլտվությունների ֆիլտրեր որոնման ներսում, row-level security PostgreSQL-ում կամ առանձին կոլեկցիաներ խիստ մեկուսացման համար։ Կոնտենտն արտաքին embedding API ուղարկելիս ստուգեք տվյալների մշակման պայմանները և խուսափեք գաղտնիքներ կամ ավելորդ անձնական տվյալներ ուղարկելուց։ Փաստաթուղթը ջնջելը պետք է ջնջի նաև նրա վեկտորները, ինչը կարևոր է GDPR ջնջման համար։ Վերջապես, RAG-ում օգտագործելիս retrieved կոնտենտը կարող է պարունակել prompt injection, այնպես որ prompt-ում retrieved տեքստը դիտարկեք որպես անվստահելի տվյալ։