Ключови моменти
Създай vector DB като започнеш от use case, добър chunking и измерими метрики, после избери платформа.
Най-практичният начин да „създадеш vector database“ е да избереш платформа (най-често Postgres + pgvector за старт или управлявана услуга като Pinecone/Weaviate/Qdrant), да дефинираш схема за (текст + embedding + метаданни), да индексираш за бързо търсене по сходство и да изградиш надежден процес за ingest (chunking, embeddings, обновявания и мониторинг).
Vector database е полезна само ако имаш ясна дефиниция какво означава „сходство“ за твоите данни.
Vector database (vector DB) е база, оптимизирана за съхранение и бързо търсене на вектори (embedding-и) с метрики като cosine similarity или dot product. Това е основен компонент в RAG (Retrieval-Augmented Generation), семантично търсене, препоръчващи системи и детекция на дубликати.
В тази статия ще минем през процес, който работи в реални проекти: започваш с минимална, ясна архитектура (за да стигнеш до работещ прототип), после добавяш индекси, филтри, обновявания и оценка на качеството.
Преди да инсталираш каквото и да е, отговори на тези въпроси:
Метриката има значение:
Най-честата причина vector DB да „не работи“ е лош chunking и неподходящ embedding модел, не самата база.
Има два разумни пътя.
Подходящо, ако:
Можеш да го пуснеш локално (Docker) или като управляван Postgres (например Supabase). В Supabase цената зависи от compute и disk; страницата им за Compute and Disk описва примерни планове и как се формират разходите за compute, storage и I/O (проверено към 10 февруари 2026).
Подходящо, ако:
Към началото на 2026 (провери страниците за ценообразуване преди решение):
Ако не си сигурен за натоварването и данните, започни с Postgres + pgvector и мигрирай към специализирана услуга, когато имаш метрики и болки.
CREATE EXTENSION IF NOT EXISTS vector;
Измеренията (vector(1536) например) трябва да съвпадат с embedding модела, който използваш.
CREATE TABLE IF NOT EXISTS doc_chunks (
id bigserial primary key,
doc_id text not null,
source text,
chunk_index int not null,
content text not null,
metadata jsonb default '{}'::jsonb,
embedding vector(1536) not null,
created_at timestamptz default now()
);
CREATE INDEX IF NOT EXISTS doc_chunks_doc_id_idx ON doc_chunks (doc_id);
CREATE INDEX IF NOT EXISTS doc_chunks_metadata_gin ON doc_chunks USING gin (metadata);
Подходът зависи от pgvector версията и размера на данните. За старт (и малки обеми) може да минеш и без индекс, но за реално търсене ще ти трябва.
Пример (HNSW, ако е налично):
CREATE INDEX IF NOT EXISTS doc_chunks_embedding_hnsw
ON doc_chunks USING hnsw (embedding vector_cosine_ops);
Важно: индексът ускорява, но изисква настройка и периодично VACUUM/ANALYZE.
Добър ingest започва с дисциплина:
chunk_index, за да можеш да възстановиш контекст.language, created_date, customer_id, permissions, tags;metadata и индексирай (GIN).Имаш два варианта:
Как да избереш:
Минималният pipeline изглежда така:
Псевдо-Python (идеята, не библиотеките):
chunks = chunk_text(text)
rows = []
for i, chunk in enumerate(chunks):
emb = embed(chunk) # връща list[float] с фиксирана дължина
rows.append((doc_id, source, i, chunk, metadata, emb))
# после batch insert
Практически съвети:
doc_id и версия на документа, за да можеш да обновяваш.doc_id и вкарай новите (или поддържай version).В Postgres с pgvector често ще правиш заявки тип:
SELECT id, doc_id, chunk_index, content, metadata,
1 - (embedding <=> $1) AS score
FROM doc_chunks
WHERE metadata @> '{"language":"bg"}'
ORDER BY embedding <=> $1
LIMIT 10;
Тук $1 е query embedding.
С филтри можеш да намалиш „шум“ и да подобриш precision. Пример: по клиент, дата, тип документ.
Vector търсенето е първи етап (retrieval). Ако искаш по-точни резултати, добави втори етап:
Това често подобрява качеството повече от „още индекси“.
Когато започнеш да имаш хиляди заявки на ден или милиони chunk-ове, дребните решения стават важни:
top_k без причина: често k=5..20 е достатъчно, ако chunking-ът и метаданните са добри.Vector DB често държи „извадка“ от фирмено знание. Ако работиш с клиентски или вътрешни данни:
customer_id/права на ниво заявка, не само в приложението;Семантичното търсене без контрол на достъп е риск за изтичане на информация, дори когато „нямаш директни линкове“.
Когато MVP тръгне, добави тези 6 елемента:
recall@k, human spot-check, „лоши“ заявки.recall@k и latency).Ако правиш MVP, имаш умерен обем и искаш SQL + права + транзакции, Postgres + pgvector често е достатъчен. При много големи обеми или специфични SLA изисквания, управляваните vector услуги могат да са по-подходящи.
Цената идва от три места: генериране на embeddings (ако е платен API), съхранение (disk) и заявки/compute. Управляваните услуги често имат минимум или pay-as-you-go модели, а при Postgres плащаш compute/disk според хостинга.
Започни с 300–800 думи и 10–20% overlap, после измери recall@k на реални въпроси. Няма универсално число, но има универсален тест: работи ли за твоите случаи.
Въведи doc_id + version (или checksum). При промяна: изтрий старите chunk-ове за документа и вкарай новите, или маркирай версията и филтрирай по „активна“.
Когато имаш ясни метрики и виждаш ограничения: latency при голям k, сложни SLA изисквания, HA/многорегионност, или оперативна тежест. Тогава сравни актуалните планове и модели за таксуване на страниците им (проверено към 10 февруари 2026).