ChatGPT, Claude və ya Gemini — fərq etməz — istənilən AI modelindən şirkətinizin satış hesabatı haqqında soruşsanız, nə cavab alarsınız? “Üzr istəyirəm, bu məlumata çıxışım yoxdur.” Dünyanın ən güclü AI modelləri belə sizin sənədlərinizi, daxili qaydalarınızı, müştəri tarixçənizi tanımır. Bəs bu problemi necə həll etmək olar? Qısa cavab: RAG. Bu yazıda RAG-ın nə olduğunu, necə işlədiyini və nə vaxt istifadə edilməli olduğunu sadə dildə izah edəcəyik.
Problem: LLM yalnız öyrədildiyi datanı bilir
LLM (Large Language Model) — ChatGPT, Claude, Gemini kimi modellər — milyardlarla mətn üzərində train olunub. Amma bu train datasının iki böyük məhdudiyyəti var:
1. Sənin datan orada yoxdur. Şirkətinin daxili sənədləri, HR siyasəti, satış hesabatları, müştəri yazışmaları — bunların heç biri modelin train datasına daxil deyil. Və olmamalıdır da — bu, məxfi məlumatdır.
2. Data köhnəlir. Modelin bilik bazası train olunduğu tarixdə “donur”. Dünən qəbul edilən yeni qayda, bu səhər dəyişən qiymət cədvəli — model bunları bilmir.
Bir çox şirkət bu problemi görəndə ilk ağlına gələn fine-tuning olur: “Modeli öz datamızla yenidən train edək.” Amma fine-tuning bahalıdır, vaxt aparır və data hər dəyişəndə prosesi təkrarlamaq lazımdır. Gündəlik dəyişən data üçün bu, praktiki deyil.
Məhz burada RAG meydana çıxır.
RAG nədir?
RAG — Retrieval-Augmented Generation deməkdir. Adı mürəkkəb səslənsə də, ideya çox sadədir: modelə sualla birlikdə lazımi məlumatı da ver.
Üç sözü ayrı-ayrı açaq:
- Retrieval (Tapma): İstifadəçi sual verəndə, sistem sənin data bazandan həmin suala uyğun parçaları tapır.
- Augmented (Zənginləşdirmə): Tapılan parçalar sualın yanına, prompt-a əlavə olunur.
- Generation (Generasiya): LLM artıq bu kontekstlə birlikdə cavab yaradır.
Bir bənzətmə ilə desək: LLM çox savadlı, amma sənin şirkətində heç vaxt işləməmiş bir məsləhətçidir. RAG isə ona deyir: “Cavab verməzdən əvvəl bu sənədlərə bax.” Məsləhətçi ağıllıdır — düzgün sənədi görəndə dəqiq cavab verir.
RAG necə işləyir? 5 addımda pipeline
Texniki tərəfə keçək. Tipik RAG sistemi belə işləyir:
Addım 0 — Hazırlıq (Indexing): Sənədlərin əvvəlcədən kiçik parçalara (chunk) bölünür, hər parça embedding adlanan rəqəm vektoruna çevrilir və Vector Database-ə (Pinecone, Qdrant, pgvector və s.) yazılır. Bu, bir dəfə edilir və data dəyişəndə yenilənir.
Addım 1 — Sual: İstifadəçi sual verir: “2024 satış hesabatında ən güclü region hansı idi?”
Addım 2 — Search: Sual da embedding-ə çevrilir və Vector DB-də ona semantik olaraq ən yaxın chunk-lar tapılır. Burada açar söz axtarışı yox, məna axtarışı gedir — “ən güclü region” sorğusu “regional performans liderləri” cümləsini də tapa bilir.
Addım 3 — Context: Tapılan ən uyğun 3-5 chunk sualın yanına əlavə olunur: “Bu sənədlərə əsasən cavab ver: [chunk-lar] Sual: [istifadəçinin sualı]”
Addım 4 — Generation: LLM bu zənginləşdirilmiş prompt ilə cavab yaradır: “Abşeron regionu — illik 34% artımla lider oldu.”
Addım 5 — Cavab + Mənbə: İstifadəçi cavabı alır və bonus olaraq sistem mənbəni də göstərə bilir: “Mənbə: Sales_Report_2024.pdf, səh. 12”
Real dünya misalı: daxili knowledge bot
Təsəvvür edin, şirkətdə yüzlərlə səhifəlik HR sənədi var. Yeni işçi soruşur: “Məzuniyyət siyasətimiz necədir?”
RAG olmadan: model ümumi cavab verəcək və ya uyduracaq (buna hallucination deyilir). Hansı modeldən istifadə etməyinizdən asılı olmayaraq — sənəd yoxdursa, dəqiq cavab da yoxdur.
RAG ilə: Sistem HR_Policy.pdf-dən uyğun bölməni tapır və model dəqiq cavab verir: “İllik 21 iş günü məzuniyyət hüququnuz var. Sənədin 4-cü bölməsinə əsasən…”
Fərq böyükdür: cavab sənin datana əsaslanır, mənbə göstərilir və model uydurmur.
Bu yanaşma ilə qurula bilən sistemlər: müştəri dəstəyi botları (şirkətin FAQ və sənədləri üzərində), hüquqi sənəd axtarışı, daxili IT helpdesk, e-commerce məhsul məsləhətçisi və sair.
Nə vaxt RAG istifadə etməli?
RAG hər problem üçün deyil. Bu hallarda RAG düzgün seçimdir:

Cavablar öz datanıza əsaslanmalıdır (şirkət sənədləri, daxili bilik bazası)

Data tez-tez dəyişir — fine-tuning hər dəfə bahalı olardı

Mənbə göstərmək kritikdir (hüquq, tibb, maliyyə sahələri)

Hallucination riskini azaltmaq lazımdır

Amma ümumi bilik sualları üçün (“Python-da loop necə yazılır?”) RAG lazım deyil — model bunu onsuz da bilir. Hər sualda Vector DB-yə getmək sadəcə sistemi yavaşladar və xərci artırar.
RAG-ın çətinlikləri
Dürüst olaq — RAG sehrli çubuq deyil. Real layihələrdə qarşılaşacağınız məsələlər:
Chunking strategiyası: Sənədi necə bölmək? Çox kiçik parçalar konteksti itirir, çox böyük parçalar isə axtarışın dəqiqliyini azaldır. Düzgün chunk ölçüsü və overlap tapmaq təcrübə tələb edir.
Retrieval keyfiyyəti: Əgər axtarış yanlış chunk-ları tapırsa, LLM nə qədər güclü olsa da, cavab zəif olacaq. “Garbage in, garbage out” prinsipi burada da işləyir. Hybrid search (semantik + keyword) çox vaxt daha yaxşı nəticə verir.
Qiymətləndirmə: RAG sisteminin nə qədər yaxşı işlədiyini ölçmək ayrıca bir mövzudur — retrieval dəqiqliyi, cavab keyfiyyəti və hallucination dərəcəsi ayrı-ayrı izlənməlidir.
Nəticə
RAG bu gün AI Engineering-in ən praktik və ən çox tələb olunan texnikalarından biridir. Fine-tuning-dən ucuz, sadə prompt-dan güclü, və ən əsası — öz datanız üzərində işləyir.
Əgər şirkətinizdə “AI-dan necə istifadə edək?” sualı müzakirə olunursa, böyük ehtimalla cavabın bir hissəsi RAG-dan keçir.