Cum funcționează embeddings și de ce contează pentru RAG

Ai un LLM performant, o bază de cunoștințe solidă și un pipeline RAG care pare bine pus la punct. Și totuși, răspunsurile vin cu context alăturat, nu chiar potrivit — pasaje care ating subiectul, dar nu răspund la întrebare. În majoritatea cazurilor, problema nu e modelul de limbaj. E ce recuperezi înainte să ajungă la el. Iar ce recuperezi depinde aproape în întregime de embeddings.

Un embedding e mecanismul care transformă text în ceva ce poți compara matematic. Dacă înțelegi cum se generează, ce înseamnă dimensiunile unui vector, cum se măsoară similaritatea și ce se întâmplă exact când schimbi modelul, poți diagnostica jumătate din problemele tipice de retrieval fără să atingi promptul sau arhitectura de bază descrisă în ce este RAG.

Ce este, de fapt, un embedding

Un embedding e un vector — un șir de câteva sute până la câteva mii de numere zecimale — care reprezintă sensul unei bucăți de text, nu cuvintele ei literale. Două propoziții care spun același lucru cu vocabular complet diferit ajung la vectori apropiați. Două propoziții cu aceleași cuvinte, dar sens opus, ajung la vectori depărtați.

Diferența față de o căutare full-text clasică contează enorm pentru retrieval. Un motor de căutare pe cuvinte cheie caută potriviri literale: dacă întrebarea conține „anulare abonament", iar documentul spune „reziliere contract", căutarea clasică ratează legătura — cuvintele nu se suprapun deloc. Embeddings-urile prind sensul, nu șirul de caractere, exact componenta care lipsește dintr-o căutare bazată doar pe cuvinte cheie. Contrastul complet dintre cele două abordări — plus cazurile în care căutarea pe cuvinte cheie rămâne superioară — e detaliat în ce este semantic search și cum diferă de full-text.

De la cuvinte la vectori de sens

Modelul de embeddings a fost antrenat pe volume mari de text și a învățat să plaseze concepte similare aproape unele de altele, într-un spațiu cu sute sau mii de dimensiuni. Exemplul clasic din cercetarea NLP: dacă iei vectorul pentru „rege", scazi vectorul pentru „bărbat" și aduni vectorul pentru „femeie", rezultatul cade aproape de vectorul pentru „regină". Modelul n-a memorat regula asta — a dedus-o din tiparele statistice observate în datele de antrenament, la scară de miliarde de propoziții.

Pentru RAG, ce contează practic e mai simplu decât exemplul de mai sus: fiecare bucată de conținut — un paragraf, o secțiune, un document întreg — devine un punct într-un spațiu numeric, iar întrebarea utilizatorului devine, la rândul ei, un punct în același spațiu. Recuperarea (retrieval) se reduce, matematic, la a găsi cele mai apropiate puncte de întrebare.

Un exemplu concret

Ia două propoziții:

• „Cum îmi anulez abonamentul?"
• „Vreau să opresc plata lunară pentru cont."

Zero cuvinte comune relevante, dar exact același sens. Un embedding de calitate le plasează la o distanță mică una de cealaltă. Compară acum cu:

• „Cum îmi anulez abonamentul?"
• „Cum îmi activez abonamentul?"

Aici cuvintele se suprapun aproape complet, dar sensul e opus. Un model bun ține aceste două propoziții mai departe una de alta decât ai bănui din suprapunerea lexicală — pentru că a învățat diferența dintre „anulez" și „activez" ca acțiuni contrare, nu doar ca șiruri de caractere apropiate.

Cum se generează embeddings-urile

Procesul e simplu la suprafață: trimiți un fragment de text către un model de embeddings, primești înapoi un vector de dimensiune fixă. Modelul e o rețea neuronală antrenată specific pentru sarcina asta — diferită de modelul de generare, cel care scrie răspunsuri conversaționale. Multe familii de modele au atât o variantă de „chat", cât și una de „embedding", antrenate separat, cu obiective diferite: una învață să genereze text coerent, cealaltă învață să plaseze corect sensul în spațiu.

Modelul de embeddings

Nu există un singur model de embeddings „standard". Fiecare provider își antrenează propriile modele, pe propriile date, cu propriile obiective de optimizare — iar rezultatul practic e că vectorii produși de modele diferite nu sunt comparabili între ei, chiar dacă au aceeași dimensiune. Revin la asta mai jos, la capcana cu re-indexarea, pentru că e motivul principal pentru care echipele își strică indexul de producție.

Peisajul din 2026 e mult mai variat decât acum doi-trei ani. OpenAI rămâne alegerea implicită pentru multe stack-uri prin text-embedding-3-small și text-embedding-3-large. Cohere a mutat granița cu embed-v4, primul model multimodal de producție care vectorizează text și imagini în același spațiu — util pentru RAG peste PDF-uri cu tabele și diagrame, nu doar text curat. Voyage AI, parte din MongoDB din 2024, conduce constant pe benchmark-urile publice de retrieval cu familia voyage-4. Google a intrat serios în joc cu Gemini Embedding, iar în modelele open-source, Qwen3-Embedding și BGE-M3 au ajuns să egaleze sau să depășească opțiunile plătite pe multe sarcini — cu prețul infrastructurii GPU pe care trebuie s-o operezi singur. În practică, alegerea se leagă adesea și de restul stack-ului: dacă folosești deja un anumit provider pentru modelul de generare, rămânerea în același ecosistem simplifică integrarea și facturarea, chiar dacă nu e neapărat modelul cu scorul cel mai mare pe benchmark.

Un detaliu ușor de ratat: unele modele mai noi — Voyage și anumite variante Qwen, printre altele — diferențiază explicit între embedding-ul unei interogări și embedding-ul unui document, cu un prefix sau o instrucțiune diferită la generare pentru fiecare caz. O întrebare scurtă și un paragraf lung de documentație nu au aceeași „formă" lingvistică, chiar dacă discută același subiect, iar modelele antrenate să țină cont de asta recuperează mai precis. Verifică documentația modelului ales: dacă suportă acest mod asimetric, folosește-l corect la ambele capete ale pipeline-ului, nu doar la indexare.

Dimensiuni și ce înseamnă practic

Dimensiunea unui embedding — 384, 768, 1024, 1536, 3072 — e pur și simplu numărul de valori din vector. Mai multe dimensiuni înseamnă, teoretic, mai multă nuanță capturată, dar costul crește direct proporțional: un vector de 3072 de dimensiuni ocupă dublu față de unul de 1536, atât în stocare, cât și în timpul de calcul la fiecare căutare. La scară, diferența devine concretă: un index cu 41 de milioane de documente stocate ca vectori de 3072 de dimensiuni ocupă aproximativ 500GB; același volum de documente, reprezentat la 512 dimensiuni, coboară la aproximativ 84GB — o reducere de șase ori, atât în stocare, cât și în numărul de operații făcute la fiecare comparație de similaritate.

Aici intervine o tehnică pe care merită s-o cunoști: Matryoshka Representation Learning (MRL). Modelele antrenate cu MRL — text-embedding-3 de la OpenAI, embed-v4 de la Cohere, familia voyage-4 — sunt construite astfel încât primele valori din vector duc cea mai multă informație semantică. Practic, poți trunchia vectorul, de la 1536 la 512 dimensiuni, de exemplu, și pierzi doar câteva puncte de calitate pe benchmark-uri standard, în schimbul unei reduceri de stocare de 3x. Pentru un index cu milioane de documente, asta transformă costul de infrastructură dintr-o problemă serioasă într-una gestionabilă. Trunchierea se face la interogare, prin parametrul de dimensiuni al API-ului, și nu presupune reantrenare.

Cum măsori similaritatea între doi vectori

Odată ce ai vectori pentru documente și pentru întrebare, retrieval-ul se reduce la o singură operație: găsește vectorii de document cei mai „apropiați" de vectorul întrebării. „Apropiat" nu e un concept singular — există câteva moduri standard de a-l măsura, iar alegerea contează.

Cosine similarity — standardul de facto în RAG

Cosine similarity măsoară unghiul dintre doi vectori, nu distanța dintre capetele lor. Rezultatul e un număr între -1 și 1, sau între 0 și 1 pentru embeddings normalizate, care e cazul comun: cu cât unghiul e mai mic, cu atât textele sunt mai apropiate semantic. Avantajul practic e că cosine similarity ignoră magnitudinea vectorului — lungimea lui — și se concentrează exclusiv pe direcție, adică pe „orientarea" semantică. Un document scurt și unul lung, care exprimă aceeași idee, pot avea magnitudini diferite, dar orientare identică, iar cosine similarity le tratează corect ca fiind apropiate.

Aproape toate motoarele vectoriale populare — pgvector, Pinecone, Qdrant, Weaviate — au cosine similarity ca opțiune implicită sau recomandată pentru embeddings de text.

Dot product și distanța euclidiană — când contează diferența

Dot product, adică produsul scalar, e matematic aproape identic cu cosine similarity dacă vectorii sunt deja normalizați la lungime 1 — caz în care rezultatele sunt identice, iar dot product e puțin mai ieftin de calculat, pentru că sare peste pasul de normalizare la fiecare comparație. Majoritatea modelelor moderne de embeddings produc vectori normalizați implicit, motiv pentru care unele baze de date vectoriale recomandă dot product ca optimizare de performanță, nu ca alegere semantic diferită.

Distanța euclidiană (L2) e altceva: măsoară distanța „în linie dreaptă" între capetele celor doi vectori, ceea ce înseamnă că e sensibilă la magnitudine. Pentru embeddings nenormalizate, doi vectori pot fi apropiați ca direcție, dar depărtați ca distanță euclidiană, dacă au lungimi foarte diferite. E utilă în clustering sau în cazuri unde magnitudinea chiar contează, dar pentru retrieval semantic în RAG, cosine similarity, sau dot product echivalent pe vectori normalizați, rămâne alegerea implicită și motivul pentru care marea majoritate a implementărilor de RAG o folosesc fără s-o discute.

Ce model de embeddings alegi: calitate vs. cost vs. dimensiuni

Nu există un model „cel mai bun" universal — există un model potrivit pentru bugetul, volumul și domeniul tău. Trei axe de decizie: calitatea pe sarcina ta specifică, costul pe volum, care se plătește o dată la indexare, dar și la fiecare interogare nouă, și dimensiunea vectorului, care determină costul de stocare și viteza de căutare pe termen lung.

Peisajul modelelor în 2026

Prețurile se schimbă des în piața asta — verifică întotdeauna pagina oficială a providerului înainte să bugetezi un index mare. Ce rămâne stabil e logica din spate: modelele mici și ieftine acoperă majoritatea cazurilor de RAG obișnuit; diferența de calitate față de modelele premium se simte mai ales pe conținut tehnic de nișă, texte multilingve sau documente cu structură complexă, cum ar fi tabele sau diagrame scanate.

Cum testezi calitatea pe datele tale, nu doar pe leaderboard

MTEB, Massive Text Embedding Benchmark, e referința publică pentru compararea modelelor — acoperă zeci de seturi de date, pe sarcini de retrieval, clasificare și similaritate. E un punct de plecare util, dar nu o garanție pentru domeniul tău. O echipă care a construit un sistem de retrieval pentru contracte juridice a observat că primele trei modele din MTEB s-au clasat pe locurile 5, 7 și 2 pe setul lor real de întrebări, iar modelul câștigător pe datele lor era abia pe locul 11 în clasamentul general. Diferența dintre limbajul juridic și limbajul general din benchmark-urile publice a contat mai mult decât scorul agregat.

Concluzia practică: construiește un set mic de evaluare din documentele și întrebările tale reale — 50-100 de perechi întrebare-pasaj relevant sunt suficiente pentru un semnal util — și măsoară precizia de recuperare, adică proporția rezultatelor din top-k care sunt chiar relevante, înainte să blochezi alegerea modelului. Diferența de model, singură, poate muta precizia de retrieval cu 20-30% pe workload-uri tipice de RAG, mult mai mult decât orice ajustare de prompt ulterioară. Pentru domenii de nișă — juridic, medical, cod sursă — fine-tuning-ul unui model open-source pe propriile date poate aduce câștiguri suplimentare de 10-30% față de un model generic, dar presupune infrastructură GPU și expertiză ML peste ce cere un API gata de folosit; merită doar dacă evaluarea pe datele tale arată deja un plafon clar cu modelele generice.

Odată ales modelul, pasul următor e unde ajung, de fapt, aceste vectori — vezi comparația dintre pgvector, Pinecone, Qdrant și Weaviate pentru cum alegi baza de date vectorială potrivită volumului tău.

De la embeddings la baza de date vectorială

Un vector generat nu e util izolat — trebuie stocat undeva de unde poate fi căutat rapid, la scară. O bază de date vectorială indexează milioane de vectori folosind structuri de tip ANN, approximate nearest neighbor, cel mai des HNSW, care fac un trade-off deliberat între precizie perfectă și viteză: găsesc „aproape sigur" cei mai apropiați vecini, nu garantat cei mai apropiați, dar de mii de ori mai rapid decât o comparație exhaustivă pe tot indexul. Diferența practică — recall de 95% în loc de 100%, la o fracțiune din timp — e motivul pentru care aproape nimeni nu face căutare vectorială exhaustivă în producție, la volume relevante.

Chunking-ul decide ce ajunge, de fapt, în vector

Calitatea unui embedding depinde direct de ce bagi în el. Un chunk, adică o bucată de text, prea mare diluează sensul — embedding-ul unui document întreg de cinci pagini devine o medie vagă a tuturor subiectelor atinse, nu o reprezentare precisă a niciunuia. Un chunk prea mic pierde context — o propoziție ruptă din paragraf poate deveni ambiguă chiar și pentru un model bun de embeddings. De exemplu, un ghid tehnic împărțit strict la fiecare 500 de cuvinte, fără să țină cont de secțiuni, poate rupe o definiție de exemplul care o însoțește — iar embedding-ul bucății rămase, cu doar exemplul și fără definiție, devine greu de potrivit cu o întrebare care folosește terminologia din definiția lipsă. Strategia de chunking — dimensiune, overlap, respectarea granițelor semantice ca paragrafe sau secțiuni — e, de fapt, prima decizie care afectează calitatea embedding-ului, înaintea oricărei alegeri de model. Pentru detalii pe subiectul ăsta, strategiile de chunking pentru RAG intră exact pe cum alegi dimensiunea și overlap-ul potrivite.

Capcana practică: schimbarea modelului forțează re-indexare completă

Aici pică majoritatea echipelor prima dată: schimbă modelul de embeddings, fie pentru cost, fie pentru calitate, fie pentru că au migrat provider-ul de LLM, și se așteaptă ca vechiul index să funcționeze în continuare. Nu funcționează.

De ce nu poți amesteca vectori din modele diferite

Fiecare model de embeddings învață propriul „spațiu" — propria hartă a sensului, cu propriile axe și propria orientare. Doi vectori din modele diferite, chiar dacă au exact aceeași dimensiune numerică, ambele 1536, de exemplu, nu trăiesc în același spațiu. Cosine similarity între un vector din text-embedding-3-small și unul din embed-v4 e un număr fără sens — nu măsoară nimic relevant, pentru că cele două modele n-au învățat aceeași hartă. Nu e o limitare tehnică pe care o poți ocoli cu o conversie de tip sau o normalizare — e o diferență fundamentală de reprezentare.

Practic, asta înseamnă: dacă schimbi modelul de embeddings, fiecare document din index trebuie re-vectorizat de la zero, cu noul model. Nu poți amesteca vectori vechi și noi în aceeași colecție, nici măcar temporar — rezultatele de căutare devin, în cel mai bun caz, aleatorii.

Cum planifici o migrare fără downtime

Abordarea sigură e „blue-green": construiești indexul nou, cu noul model, într-o colecție separată, în paralel cu cea veche, care rămâne activă și servește trafic. Abia după ce indexul nou e complet și validat, testat pe același set de evaluare folosit la alegerea modelului, comuți traficul de căutare pe colecția nouă și ștergi colecția veche. Costul de calcul al re-indexării complete depinde de volumul de documente și de prețul per token al noului model — pentru bugetare, ghidul de cost pentru un sistem RAG detaliază exact ce intră în calculul ăsta. Costul de inginerie — timpul de rulare a pipeline-ului, validarea, comutarea — depășește adesea costul brut al API-ului, mai ales la volume mari de documente.

Embeddings în cod: un exemplu minimal cu Vercel AI SDK

Generarea unui embedding, la nivel de cod, e o singură funcție. Vercel AI SDK expune embed() peste orice provider compatibil:

1import { embed } from 'ai';
2import { openai } from '@ai-sdk/openai';
3
4const { embedding } = await embed({
5  model: openai.embedding('text-embedding-3-small'),
6  value: chunkText,
7});
8
9// embedding e un array de 1536 de numere,
10// gata de salvat alături de chunkText în baza de date vectorială

1import { embed } from 'ai';
2import { openai } from '@ai-sdk/openai';
3
4const { embedding } = await embed({
5  model: openai.embedding('text-embedding-3-small'),
6  value: chunkText,
7});
8
9// embedding e un array de 1536 de numere,
10// gata de salvat alături de chunkText în baza de date vectorială

Pentru un pipeline complet — chunking, generare embeddings în batch, stocare și interogare — vezi ghidul pas-cu-pas pentru un sistem RAG cu Next.js și Vercel AI SDK.

Întrebări frecvente

Ce dimensiune de embedding ar trebui să aleg?

Pornește de la dimensiunea implicită a modelului ales, de obicei între 1024 și 1536, și trunchiază doar dacă stocarea sau viteza de căutare devin o problemă reală la volumul tău. Pentru modele cu Matryoshka Representation Learning, trunchierea la jumătate pierde de regulă doar 1-2 puncte de calitate, în schimbul unei reduceri semnificative de cost.

Pot combina embeddings de la modele diferite în aceeași bază vectorială?

Nu. Vectorii din modele diferite trăiesc în spații semantice diferite, iar similaritatea calculată între ei nu are sens, chiar dacă dimensiunea numerică coincide. Orice schimbare de model cere re-indexare completă a colecției.

Cât costă să generezi embeddings pentru o bază de cunoștințe mare?

Depinde de volumul de tokeni și de modelul ales — de la aproximativ $0.02 la $0.15 per milion de tokeni, în funcție de provider și de calitate. Pentru o bază de 10.000 de documente a câte 500 de tokeni fiecare, costul brut de indexare inițială e, de regulă, sub câțiva dolari cu un model economic; costul real crește cu re-indexările ulterioare și cu volumul de interogări.

Cosine similarity sau dot product — care e mai bun pentru RAG?

Pentru embeddings normalizate, cazul majorității modelelor moderne, rezultatele sunt identice — diferența e doar de performanță de calcul, unde dot product e ușor mai rapid. Alege ce recomandă implicit baza ta de date vectorială.

Trebuie să regenerezi embeddings dacă schimbi doar modelul de generare, adică LLM-ul care scrie răspunsul?

Nu. Modelul de embeddings și modelul de generare sunt complet independente — poți schimba LLM-ul care formulează răspunsul final fără să atingi indexul vectorial, atât timp cât modelul de embeddings rămâne același.

Ce se întâmplă dacă un chunk de text e mai lung decât limita modelului de embeddings?

Textul e trunchiat sau respins, în funcție de provider — verifică limita de context a modelului ales, care variază de la câteva mii la peste 100.000 de tokeni în funcție de model, și dimensionează strategia de chunking sub acea limită, cu rezervă. Limita modelului de embeddings e însă doar prima constrângere: fragmentele recuperate trebuie apoi să încapă și în fereastra de context a LLM-ului care scrie răspunsul, unde concurează cu instrucțiunile, tools-urile și istoricul conversației.

Explorează și restul fundamentelor RAG sau secțiunea completă AI & RAG pentru arhitectură, costuri și cazuri de utilizare.