Ce este o bază de date vectorială?

O bază de date vectorială răspunde la o singură întrebare, foarte rapid

Îi dai o listă de numere și îți returnează listele stocate care sunt cele mai apropiate de ea. Aceasta e întreaga interfață.

Listele sunt embeddinguri. Un model de embedding transformă un pasaj, o descriere de produs sau o imagine în câteva sute până la câteva mii de numere, plasate astfel încât sensurile similare să ajungă apropiate unele de altele, iar ce sunt embeddingurile în IA explică cum. O bază de date vectorială este locul unde trăiesc acele liste odată ce ai multe dintre ele. Stochează fiecare cu un ID și niște metadate, construiește un index peste ele și răspunde la căutarea celor mai apropiați vecini: "iată un vector de interogare, dă-mi cele mai apropiate zece."

Partea grea e cuvântul rapid. Compararea unei interogări cu un milion de vectori stocați de câte 1.536 de numere fiecare înseamnă 1,5 miliarde de înmulțiri, iar a face asta la fiecare apăsare de tastă nu se scalează. Așa că bazele de date vectoriale folosesc indexuri aproximative pentru cei mai apropiați vecini, cel mai comun fiind HNSW, o structură de graf dintr-un articol din 2016 al lui Malkov și Yashunin care vizitează câteva sute de candidați în loc de întregul milion și returnează răspunsul corect aproape de fiecare dată. Acel "aproape" e compromisul: puțină acuratețe pentru o viteză de o mie de ori mai mare.

Baza ta de date existentă potrivește cuvinte; o bază de date vectorială potrivește sensul

O bază de date relațională găsește rânduri ale căror valori se potrivesc: WHERE customer_id = 4127. Un index full-text găsește documente care conțin cuvinte: refund AND policy. O bază de date vectorială găsește elemente al căror sens este apropiat: interogarea "cum îmi recuperez banii" returnează pasajul intitulat "Returnări și rambursări" chiar dacă cele două nu au niciun cuvânt comun.

Ultimul rând arată cât de neclară e categoria. pgvector adaugă coloane vectoriale și un index HNSW în Postgres obișnuit, iar Elasticsearch poartă un câmp vectorial încă din versiunea 7.0 din 2019 și căutare HNSW din 8.0 din 2022. O "bază de date vectorială" e adesea o capabilitate în interiorul unei baze de date pe care deja o rulezi, nu un produs nou, iar produsele independente concurează pe scalabilitate și rafinament operațional, nu pe a face ceva ce Postgres nu poate.

Chat-ul cu documentele tale e o căutare vectorială cu un model la final

Generarea augmentată prin recuperare, pe care ce este RAG o explică pas cu pas, are un pas de căutare și unul de scriere. Baza de date vectorială e pasul de căutare.

1. Împarte fiecare document în pasaje de câteva sute până la o mie de tokenuri.
2. Fă embedding pentru fiecare pasaj și stochează vectorii, împreună cu textul pasajului și sursa lui, în baza de date vectorială.
3. Când sosește o întrebare, fă-i embedding și cere bazei de date cele mai apropiate pasaje.
4. Predă acele pasaje modelului de limbaj împreună cu întrebarea și lasă-l să scrie răspunsul.

Pașii 1 și 2 se întâmplă o singură dată, când sunt adăugate documentele. Pașii 3 și 4 se întâmplă la fiecare întrebare. Modelul de limbaj nu vede niciodată întreaga colecție; vede cele cinci sau zece pasaje alese de bază de date. De aceea răspunsul e la fel de bun ca și căutarea: dacă cel mai apropiat vector e pasajul greșit, modelul răspunde cu încredere la întrebarea greșită, ceea ce ce este o halucinație de IA clasifică drept un eșec de recuperare, nu o inventare.

Când ai nevoie de una și când e mai bine să trimiți tot fișierul

Decizia e despre mărime. Un model poate considera doar fereastra sa de context odată, și fiecare token din interiorul ei e plătit la fiecare tură. O bază de date vectorială există pentru a pune doar felia relevantă în fața modelului. Pentru un singur document care încape, recuperarea e un pas pe care îl poți sări; pentru o colecție care nu încape, e singura opțiune.

Calculează prețul celor două soluții pe un raport de 300.000 de tokenuri, câteva sute de pagini, la care se pun zece întrebări, recuperând câte cinci pasaje de 1.000 de tokenuri per întrebare. Trimiterea întregului fișier de fiecare dată înseamnă 3 milioane de tokenuri de intrare. Recuperarea a cinci pasaje de 1.000 de tokenuri per întrebare înseamnă 50.000. La ratele de preț de listă de intrare din indexul de cost al modelelor de IA, preluate de la OpenRouter pe 2026-08-20, diferența e de 60x la fiecare model. Caching-ul de prompt, acolo unde furnizorul îl oferă, facturează o recitire a aceluiași fișier la o zecime până la o jumătate din prețul de listă, ceea ce reduce diferența la aproximativ 6x până la 30x. Recuperarea tot câștigă, dar cu mai puțin.

Soluția cu fișierul întreg cumpără ceva pentru acei bani atunci când fișierul încape în buget: un contract de 60 de pagini, cam 40.000 de tokenuri, permite modelului să răspundă la întrebări care au nevoie de tot documentul deodată, precum "există ceva aici care contrazice clauza 14", întrebare pe care recuperarea nu o poate pune pentru că nu vede niciodată clauza 14 și contradicția în aceeași tură. Regula care rezultă: un document, sau câteva, intră întregi; o bibliotecă trece printr-o bază de date vectorială. Între cele două, împarte încărcarea pe subiecte astfel încât modelul să primească secțiunea de care are nevoie.

Whizi trimite textul propriu-zis, până la o tură de 40.000 de tokenuri

Whizi nu rulează o bază de date vectorială pentru chat-ul tău. Când atașezi un fișier, calea de încărcare a documentelor extrage textul și îl trimite modelului ca text de prompt, până la un buget fix de 40.000 de tokenuri per tură; o încărcare mai lungă e tăiată, cu un toast și un marcaj în mesaj care anunță acest lucru. Fișierele de proiect funcționează la fel: funcția proiecte fixează până la 10 fișiere și reconstruiește textul lor în prompt la fiecare mesaj, cu o limită de 32.000 de caractere per fișier și 120.000 pentru întregul bloc de proiect.

Limitele sunt marginea designului. Un fișier fixat peste 32.000 de caractere e trunchiat, un atașament peste bugetul de 40.000 de tokenuri per tură e tăiat, iar un proiect e un dosar, nu o bibliotecă cu căutare. Compromisul e deliberat: pentru un contract sau o lucrare care încape în bugetul turei, a avea textul prezent bate a-l avea căutat, iar verificarea care contează, cererea către model să citeze pasajul folosit, funcționează pentru că pasajul chiar e acolo. Pentru o mie de documente, o bază de date vectorială e uneltea potrivită, iar o aplicație de chat e cea greșită.

Două obiceiuri decurg din mecanism. Numește fișierul în întrebarea ta odată ce ai mai multe atașate, pentru că altfel modelul alege în tăcere. Și la orice răspuns pe care vei acționa, cere citatul. Un sistem de recuperare poate returna pasajul greșit; un sistem cu fișier întreg poate răspunde din memorie în loc de fișier. Citatul le prinde pe amândouă.