# Cum construiești un sistem RAG cu Next.js și Vercel AI SDK Un model lingvistic nu știe nimic despre documentele tale interne. RAG (Retrieval-Augmented Generation) rezolvă asta: cauți bucățile relevante din baza ta de cunoștințe, le pui în context și lași modelul să răspundă pe baza lor. Multe ghiduri adaugă o bază de date vectorială separată — Pinecone, Qdrant sau pgvector. Nu e obligatoriu. Dacă folosești deja MongoDB, **Atlas Vector Search** ține embeddings în aceeași colecție cu datele tale: mai puțină infrastructură, un singur loc de administrat. Tot stack-ul: **Next.js 16, Vercel AI SDK și MongoDB**. Cod complet, pas cu pas. > Dacă nu ești sigur ce e RAG sau dacă e alegerea potrivită, citește mai întâi [ce este RAG și când îl folosești](/blog/ce-este-rag). ## Ce construiești (arhitectura pe scurt) Sistemul are două fluxuri. **Ingestion** (o dată, sau când adaugi documente): * Spargi documentul în bucăți mici (chunks). * Generezi un embedding pentru fiecare bucată. * Stochezi bucata + vectorul în MongoDB. **Query** (la fiecare întrebare): * Generezi un embedding pentru întrebare. * Cauți semantic în Mongo cu `$vectorSearch`. * Pui bucățile găsite în system prompt și apelezi `streamText`. Atât. Restul e cod. ![Diagramă flat vector cu fluxurile RAG ingestion și query, de la document la chunks, vectori, bază de date și răspuns.](https://pub-05fe7f6c08814b92acf8fd74d03a6c18.r2.dev/inline/Cum%20construie%C8%99ti%20un%20sistem%20RAG%20cu%20Next.js%20%C8%99i%20Vercel%20AI%20SDK/IMAGE_PROMPT_INLINE_1.webp "Arhitectura unui sistem RAG: ingestion și query") ## Ce-ți trebuie în stack * **MongoDB Atlas** — vector search rulează doar pe Atlas (clusterul M0 gratuit merge pentru test), nu pe un MongoDB community obișnuit. * **Cheie OpenAI** — pentru embeddings și generare. * **Pachetele AI SDK**: ```bash npm install ai @ai-sdk/openai @ai-sdk/react ``` Mongoose îl ai deja în proiect. Folosim modelul `text-embedding-3-small` (1536 dimensiuni) — ieftin și suficient pentru majoritatea cazurilor. ## Pasul 1 — Stochezi embeddings în MongoDB Întâi, un model pentru bucăți. Câmpul `embedding` e un array de numere. ```ts // database/embedding.model.ts import { model, models, Schema } from "mongoose"; export interface IEmbedding { source: string; // ce document a generat această bucată content: string; // textul bucății embedding: number[]; // 1536 numere de la text-embedding-3-small } const EmbeddingSchema = new Schema( { source: { type: String, required: true, index: true }, content: { type: String, required: true }, embedding: { type: [Number], required: true }, }, { timestamps: true }, ); const Embedding = models?.Embedding || model("Embedding", EmbeddingSchema); export default Embedding; ``` Apoi, indexul vectorial. **Atenție:** acesta nu se creează din Mongoose. Îl definești în Atlas (UI → Atlas Search → Create Index, tip `vectorSearch`), cu acest JSON: ```json { "fields": [ { "type": "vector", "path": "embedding", "numDimensions": 1536, "similarity": "cosine" }, { "type": "filter", "path": "source" } ] } ``` `numDimensions` trebuie să fie exact 1536. Dacă schimbi modelul de embedding, schimbi și numărul aici — altfel indexul respinge vectorii. Câmpul `filter` pe `source` îți permite mai târziu să cauți doar într-un anumit document. ## Pasul 2 — Ingestion: chunking și embedding Modelul de embedding pierde calitate pe texte lungi. Deci spargi documentul în bucăți. O variantă simplă, cu overlap ca să nu tai ideile la mijloc: ```ts // lib/rag/chunk.ts export function chunkText(text: string, size = 800, overlap = 100): string[] { const clean = text.replace(/\s+/g, " ").trim(); const chunks: string[] = []; for (let i = 0; i < clean.length; i += size - overlap) { chunks.push(clean.slice(i, i + size)); } return chunks; } ``` Pentru producție, un chunking pe paragrafe sau propoziții dă rezultate mai bune. Pentru un MVP, varianta de mai sus e suficientă. Acum generezi embeddings pentru toate bucățile dintr-un singur apel cu `embedMany` și le salvezi: ```ts // lib/rag/ingest.ts import { openai } from "@ai-sdk/openai"; import { embedMany } from "ai"; import dbConnect from "@/lib/mongoose"; import Embedding from "@/database/embedding.model"; import { chunkText } from "./chunk"; export async function ingestDocument(source: string, raw: string) { await dbConnect(); const chunks = chunkText(raw); const { embeddings } = await embedMany({ model: openai.embedding("text-embedding-3-small"), values: chunks, }); await Embedding.insertMany( chunks.map((content, i) => ({ source, content, embedding: embeddings[i], })), ); return chunks.length; } ``` `embedMany` trimite toate bucățile odată și păstrează ordinea — `embeddings[i]` corespunde lui `chunks[i]`. ## Pasul 3 — Retrieval: cauți semantic cu $vectorSearch La query, generezi embedding pentru întrebare cu `embed`, apoi rulezi un pipeline de agregare. `$vectorSearch` trebuie să fie prima etapă: ```ts // lib/rag/retrieve.ts import { openai } from "@ai-sdk/openai"; import { embed } from "ai"; import dbConnect from "@/lib/mongoose"; import Embedding from "@/database/embedding.model"; export async function retrieve(query: string, k = 5) { await dbConnect(); const { embedding } = await embed({ model: openai.embedding("text-embedding-3-small"), value: query, }); return Embedding.aggregate([ { $vectorSearch: { index: "embeddings_vector_index", path: "embedding", queryVector: embedding, numCandidates: 100, limit: k, }, }, { $project: { _id: 0, content: 1, source: 1, score: { $meta: "vectorSearchScore" }, }, }, { $match: { score: { $gte: 0.5 } } }, ]); } ``` Câteva detalii care contează: * `index` e numele exact al indexului din Atlas. Greșești numele → zero rezultate, fără eroare. * `numCandidates` (câți vectori scanează) trebuie să fie mai mare decât `limit`. 100 e un punct bun de plecare. * `vectorSearchScore` merge de la 0 la 1. Filtrul `$gte: 0.5` aruncă bucățile slabe, ca să nu bagi zgomot în context. ![Căutare semantică ilustrată flat vector: un vector de interogare portocaliu conectat la cele mai apropiate puncte din spațiu.](https://pub-05fe7f6c08814b92acf8fd74d03a6c18.r2.dev/inline/Cum%20construie%C8%99ti%20un%20sistem%20RAG%20cu%20Next.js%20%C8%99i%20Vercel%20AI%20SDK/IMAGE_PROMPT_INLINE_2.webp "Căutare semantică cu $vectorSearch") ## Pasul 4 — Generation: streamText cu context Endpoint-ul de chat. Extragi întrebarea, faci retrieval, pui contextul în system prompt și dai drumul la streaming: ```ts // app/api/chat/route.ts import { openai } from "@ai-sdk/openai"; import { streamText, convertToModelMessages, type UIMessage } from "ai"; import { retrieve } from "@/lib/rag/retrieve"; export async function POST(req: Request) { const { messages }: { messages: UIMessage[] } = await req.json(); const last = messages[messages.length - 1]; const query = last.parts .filter((p) => p.type === "text") .map((p) => p.text) .join(" "); const context = await retrieve(query); const contextText = context.map((c) => c.content).join("\n---\n"); const result = streamText({ model: openai("gpt-4o"), system: `Răspunzi strict pe baza contextului de mai jos. Dacă informația nu există în context, spui clar că nu o ai. Nu inventezi. Context: ${contextText}`, messages: convertToModelMessages(messages), }); return result.toUIMessageStreamResponse(); } ``` Două lucruri specifice AI SDK 5: * `convertToModelMessages` transformă mesajele din format UI (cele de la `useChat`) în formatul pe care îl așteaptă modelul. * Răspunsul se întoarce cu `toUIMessageStreamResponse()`. Dacă ai văzut `toDataStreamResponse()` în tutoriale vechi — a dispărut în v5. System prompt-ul care îi spune modelului să nu inventeze e partea cea mai importantă. Fără el, modelul completează golurile din memoria lui și pierzi tot rostul RAG-ului. ## Pasul 5 — Frontend cu useChat Componenta de client. În AI SDK 5, `useChat` vine din `@ai-sdk/react`, gestionezi tu input-ul, iar mesajele sunt array de `parts`: ```tsx // app/chat/page.tsx "use client"; import { useChat } from "@ai-sdk/react"; import { useState } from "react"; export default function Chat() { const [input, setInput] = useState(""); const { messages, sendMessage, status } = useChat(); return (

{messages.map((m) => (

{m.role === "user" ? "Tu" : "Asistent"}: {m.parts.map((part, i) => part.type === "text" ? {part.text} : null, )}

))} setInput(e.target.value)} onKeyDown={(e) => { if (e.key === "Enter" && input.trim()) { sendMessage({ text: input }); setInput(""); } }} placeholder="Întreabă ceva despre documentele tale..." className="rounded-full border px-4 py-2" /> {status === "streaming" &&

Se generează răspunsul...

}

); } ``` `sendMessage({ text: input })` trimite întrebarea către `/api/chat`. Răspunsul curge înapoi token cu token. Gata — ai un sistem RAG funcțional. ## Capcane de producție MVP-ul de mai sus merge. Înainte să-l pui în fața clienților, ai grijă la: * **Indexul nu e gata instant.** După ce-l creezi în Atlas, durează câteva secunde până se construiește. Până atunci, `$vectorSearch` întoarce zero rezultate. Verifică statusul în Atlas. * **Nepotrivirea de dimensiuni.** `text-embedding-3-small` are 1536, `text-embedding-3-large` are 3072. Dacă schimbi modelul fără să refaci indexul și să re-embeddezi tot, totul se rupe în tăcere. * **Costul la ingestion.** Re-embeddarea unei baze mari de documente costă. Salvează vectorii o dată; nu-i regenera la fiecare deployment. * **Mărimea chunk-ului.** Bucăți prea mari diluează relevanța, prea mici pierd contextul. 500–1000 de caractere e un interval rezonabil de la care pornești și măsori. * **Filtrarea pe sursă.** Câmpul `filter` din index îți permite să restrângi căutarea la un singur document sau client. Esențial pentru aplicații multi-tenant. * **Evaluarea.** Fără un set de întrebări de test, nu știi dacă o schimbare a îmbunătățit sau a stricat retrieval-ul. Măsoară, nu ghici. Pentru când abordarea asta nu e suficientă, compară cu alternativa în [RAG vs fine-tuning](/blog/rag-vs-fine-tuning). Și dacă vrei tot ecosistemul de implementare, ai mai multe articole în [categoria Implementare & Stack Tehnic](/blog/categorii/implementare-stack-tehnic). ## Întrebări frecvente ### Pot folosi MongoDB local, fără Atlas? Nu pentru `$vectorSearch`. Vector search e o funcție Atlas. Poți rula un deployment Atlas local prin Atlas CLI pentru dezvoltare, dar nu merge pe un MongoDB community obișnuit. ### Ce model de embedding aleg? `text-embedding-3-small` (1536 dimensiuni) e ieftin și bun pentru majoritatea cazurilor. Treci la `text-embedding-3-large` doar dacă măsori o nevoie reală de acuratețe mai mare — și nu uita să schimbi `numDimensions` în index. ### Câte rezultate să returnez din retrieval? Începe cu 5. Prea puține și modelul n-are context; prea multe și umpli fereastra de context cu zgomot și plătești mai mulți tokeni. Ajustează în funcție de mărimea chunk-urilor. ### De ce primesc zero rezultate de la $vectorSearch? Trei cauze frecvente: numele indexului e greșit, indexul încă se construiește, sau `numDimensions` nu se potrivește cu vectorii salvați. Verifică-le în ordinea asta. ### Funcționează cu alt model decât OpenAI? Da. Vercel AI SDK e agnostic de provider. Schimbi `openai(...)` cu `anthropic(...)` sau alt adapter pentru generare. Pentru embeddings, asigură-te că `numDimensions` din index se potrivește cu modelul ales. ### Cât costă să rulezi un astfel de sistem? Depinde de volumul de documente și de trafic. Costurile principale sunt embeddings (o dată, la ingestion) și apelurile de generare (la fiecare întrebare). Detaliem bugetul într-un articol dedicat: cât costă un sistem RAG. ## Pornește Ai acum un sistem RAG complet pe stack-ul tău, fără infrastructură vectorială separată. Construim astfel de sisteme end-to-end — cu evaluare, filtrare pe surse și deployment în producție — ca parte din [serviciul de Integrări AI & RAG](/blog/serviciu/ai-rag). [Hai să vorbim despre proiectul tău](/contact).

Toate articolele

MongoDB Vector Search

Cum construiești un sistem RAG cu Next.js și Vercel AI SDK