Bază de date vectorială Qdrant în România

Ce construim pentru un RAG care funcționează

Un chatbot care răspunde din documentele firmei are nevoie de mai mult decât o bază vectorială. Construim lanțul complet: extragere din PDF-uri, contracte sau pagini interne, împărțire în fragmente cu suprapunere controlată, generare de embeddings, indexare în Qdrant și căutare hibridă, care combină apropierea semantică cu potrivirea pe cuvinte exacte. Adăugăm filtrare pe metadate, ca un utilizator să nu primească fragmente din documente la care nu are drept de acces.

• Pipeline de ingestie reluabil, cu reindexare la actualizarea documentelor
• Căutare hibridă: vectori plus potrivire lexicală pentru termeni exacți
• Filtrare pe metadate: departament, client, nivel de confidențialitate
• Evaluarea calității răspunsurilor pe un set de întrebări reale

Bune practici pe care le aplicăm în RAG

Proiectele de RAG eșuează rar din cauza modelului; eșuează din cauza datelor și a accesului. Lista de mai jos o aplicăm la fiecare livrare și o lăsăm scrisă în documentația ta, împreună cu setul de întrebări pe care măsurăm calitatea răspunsurilor. Fără o măsurare stabilită la început, orice schimbare de model, de fragmentare sau de parametri de căutare pare o îmbunătățire, dar nimeni din echipă nu poate demonstra că este.

• Acces doar pe rețea privată sau VPN, plus chei de API pe fiecare consumator
• Instantanee periodice ale colecțiilor, cu restaurare testată
• Cuantizarea vectorilor acolo unde reduce memoria fără pierdere de relevanță
• Filtrare pe metadate obligatorie, ca răspunsurile să respecte drepturile de acces
• Anonimizarea datelor personale înainte de indexare, când scopul nu le cere

Date în UE, AI Act și GDPR

Motivul principal pentru care echipele din România își aduc RAG-ul pe infrastructură proprie este controlul datelor. Documentele rămân în Frankfurt, embeddings-urile se pot genera local pe servere GPU, iar dacă folosești totuși un model extern, îți arătăm exact ce fragmente pleacă și ce rămâne. Primești contract de prelucrare conform art. 28 și SCC pentru transferuri, iar operarea noastră este aliniată la ISO 27001. Pentru discuția de AI Act, contează că poți documenta traseul datelor.

Orele incluse și serverele GPU

Instalarea, indexarea inițială și tuningul intră în orele lunare din abonament: 1–8 ore pe VPS, 5–10 ore pe servere dedicate, în funcție de plan, și 10 ore pe GPU. Le ceri din panoul de client, la Servicii DevOps, cu termenul propus de tine. Pentru modele de embeddings rulate local recomandăm un server GPU, unde cota de 10 ore acoperă de obicei configurarea și reindexările. Orele nu se reportează; ce trece peste cotă se facturează separat.

Cum lucrăm

1. Ceri lucrarea din panou

   Ne spui ce documente vrei să interoghezi, în ce volum și cine trebuie să aibă acces, apoi propui un termen din panoul de client.

2. Stabilim scopul și termenul

   Alegem baza vectorială și modelul de embeddings potrivite volumului tău, definim setul de întrebări de evaluare și estimăm orele.

3. Livrăm și măsurăm relevanța

   Indexăm documentele, punem căutarea hibridă și filtrarea pe metadate, apoi rulăm evaluarea și ajustăm fragmentarea până la rezultate stabile.

4. Predăm cu documentație

   Primești pipeline-ul în repozitoriul tău, schema colecțiilor, regulile de acces, procedura de reindexare și raportul de evaluare.

Cazuri de utilizare

Tehnologii

• Qdrant
• ChromaDB
• pgvector
• PostgreSQL
• Ollama
• vLLM
• LiteLLM
• Prometheus
• Grafana

Întrebări frecvente

• Qdrant vs Chroma: care e mai bun pentru RAG?

  Chroma este comod pentru prototipuri și volume mici, se instalează în câteva minute. Qdrant rezistă mai bine în producție: filtrare pe metadate performantă, cuantizare, instantanee, replicare. Dacă proiectul trece de faza de demonstrație, pornim direct pe Qdrant.

• Ce este o bază de date vectorială?

  Este o bază care stochează vectori, adică reprezentări numerice ale textelor sau imaginilor, și găsește rapid elementele cele mai apropiate de o interogare. Asta permite căutarea după sens, nu doar după cuvinte identice, și este stratul pe care se sprijină orice sistem RAG.

• Pot ține datele pentru RAG în UE, fără să ajungă la un furnizor extern?

  Da. Baza vectorială și documentele stau pe serverele tale din Frankfurt, iar modelul de embeddings poate rula local pe un server GPU. Dacă alegi totuși un model extern pentru generarea răspunsului, îți documentăm exact ce fragmente sunt trimise.

• pgvector sau Qdrant?

  pgvector este alegerea potrivită dacă ai deja PostgreSQL și câteva zeci de mii de fragmente: un singur sistem de administrat, backup comun. Qdrant devine mai bun la volume mari, filtrare complexă pe metadate și trafic constant de căutări, pentru că este proiectat exact pentru asta.

• De ce am nevoie de un server GPU pentru embeddings?

  Nu ai nevoie întotdeauna. Pentru reindexări rare, un VPS este suficient. GPU-ul se justifică la reindexări frecvente, la volume mari de documente sau când vrei să rulezi local și modelul care generează răspunsul, ca nimic să nu iasă din infrastructura ta.

• Cum știu dacă răspunsurile sunt corecte?

  Stabilim la început un set de întrebări cu răspunsuri așteptate și măsurăm pe el, înainte și după fiecare schimbare de fragmentare, model sau parametri de căutare. Fără măsurare, orice ajustare pare o îmbunătățire și nimeni nu poate demonstra contrariul.