RAG چیست و چرا قلب پروژه‌های AI تجاری هست؟

فرض کن یه مدل زبانی داری که خیلی باهوشه — می‌تونه کد بنویسه، شعر بگه، ریاضی حل کنه. ولی یه مشکل داره: اطلاعاتش تا یه تاریخ مشخصه و هیچ چیزی از کسب‌وکار تو نمی‌دونه. حالا تصور کن بخوای یه چت‌بات بسازی که به سوالات مشتری‌ها جواب بده. مدل نه محصولاتت رو می‌شناسه، نه قیمت‌هات رو می‌دونه، نه سیاست‌های شرکتت رو. اینجاست که RAG وارد می‌شه.

LLM به تنهایی کافی نیست — چهار محدودیت اساسی

قبل از اینکه بریم سراغ RAG، بذار ببینیم چرا اصلاً بهش نیاز داریم. مدل‌های زبانی بزرگ (Large Language Models) با وجود قدرت زیادشون، چهار محدودیت اساسی دارن:

۱. دانش قدیمی (Knowledge Cutoff)

هر مدلی تا یه تاریخ مشخص آموزش دیده. مثلاً اگه مدلت تا مارس ۲۰۲۶ آموزش دیده، هیچ چیزی از رویدادهای بعدش نمی‌دونه. قیمت سهام امروز؟ نمی‌دونه. خبر دیروز؟ نمی‌دونه. محصول جدیدی که هفته پیش لانچ کردی؟ نمی‌دونه.

۲. بدون دسترسی به داده‌های خصوصی

مدل روی داده‌های عمومی اینترنت آموزش دیده. مستندات داخلی شرکتت، ایمیل‌ها، تیکت‌های پشتیبانی، دیتابیس محصولات — هیچ کدوم رو نمی‌شناسه. و نباید هم بشناسه — نمی‌خوای داده‌های محرمانه‌ات توی Training Data یه مدل عمومی باشه.

۳. توهم (Hallucination)

وقتی مدل جواب یه سوال رو نمی‌دونه، به جای گفتن «نمی‌دونم»، یه جواب قانع‌کننده ولی کاملاً من‌درآوردی می‌سازه. این مشکل رو بهش می‌گن Hallucination. برای یه چت‌بات سرگرم‌کننده شاید مهم نباشه، ولی برای یه سیستم پشتیبانی مشتری یا مشاوره پزشکی؟ فاجعه‌ست.

۴. محدودیت Context Window

حتی اگه بخوای همه اطلاعاتت رو توی Prompt بذاری، Context Window محدوده. بهترین مدل‌ها الان حدود ۲۰۰ هزار تا ۱ میلیون توکن Context دارن. به نظر زیاد میاد، ولی وقتی داری با هزاران صفحه مستندات کار می‌کنی، خیلی زود تموم می‌شه.

RAG چیه؟ — ساده‌ترین توضیح

Retrieval-Augmented Generation (یا RAG) یه ایده ساده‌ست:

به جای اینکه مدل همه چیز رو حفظ باشه، اطلاعات لازم رو همون لحظه پیداش کن و بذار جلوش.

فکر کن به یه دکتر. یه دکتر خوب لازم نیست همه کتاب‌های پزشکی رو حفظ باشه. کافیه بدونه کجا دنبال اطلاعات بگرده و بتونه اون اطلاعات رو درست تفسیر کنه.

RAG هم همینه. سه مرحله داره:

1. Retrieval (بازیابی): سوال کاربر رو بگیر و اطلاعات مرتبط رو از منابع داده‌ات پیدا کن
2. Augmentation (تقویت): اطلاعات پیدا شده رو به Prompt اضافه کن
3. Generation (تولید): مدل با استفاده از اطلاعات اضافه‌شده، جواب بسازه

قیاس دکتر — RAG رو عمیق‌تر بفهم

بذار قیاس دکتر رو بیشتر باز کنم چون خیلی به درک RAG کمک می‌کنه.

تصور کن یه دکتر هست که:

• تحصیلات عالی داره (= مدل زبانی آموزش‌دیده)
• ولی حافظه‌اش هر روز پاک می‌شه (= Knowledge Cutoff)
• هیچ چیزی از سوابق بیمارها نمی‌دونه (= بدون داده خصوصی)

حالا بهش یه پرونده پزشکی بده. ناگهان این دکتر خیلی مفیدتر می‌شه! می‌تونه سوابق بیمار رو ببینه، آزمایش‌های قبلی رو مرور کنه، و با ترکیب دانش پزشکی‌اش + اطلاعات پرونده، تشخیص درست بده.

RAG دقیقاً همین کار رو می‌کنه:

• دکتر = LLM (دانش عمومی + قدرت استدلال)
• پرونده پزشکی = اطلاعات بازیابی‌شده (داده‌های مرتبط با سوال)
• تشخیص = جواب نهایی (ترکیب دانش + اطلاعات)

معماری RAG — قدم به قدم

حالا بریم ببینیم RAG فنی‌تر چطور کار می‌کنه. یه سیستم RAG استاندارد این مراحل رو داره:

مرحله ۱: آماده‌سازی داده (Indexing)

قبل از اینکه سیستم بتونه سوالی جواب بده، باید داده‌هات رو آماده کنی:

1. جمع‌آوری اسناد: فایل‌های PDF، صفحات وب، مستندات داخلی، دیتابیس
2. تکه‌تکه کردن (Chunking): هر سند رو به قطعات کوچک‌تر تقسیم کن — مثلاً هر ۵۰۰ کلمه
3. تبدیل به بردار (Embedding): هر قطعه رو به یه بردار عددی تبدیل کن
4. ذخیره در Vector Database: بردارها رو توی یه دیتابیس مخصوص ذخیره کن

مرحله ۲: بازیابی (Retrieval)

وقتی کاربر سوال می‌پرسه:

1. سوال کاربر هم به بردار تبدیل می‌شه
2. بردار سوال با بردارهای ذخیره‌شده مقایسه می‌شه
3. مرتبط‌ترین قطعات پیدا می‌شن (معمولاً ۳ تا ۱۰ قطعه)

مرحله ۳: تولید (Generation)

1. قطعات بازیابی‌شده + سوال کاربر توی یه Prompt ترکیب می‌شن
2. Prompt به LLM فرستاده می‌شه
3. LLM با استفاده از Context اضافه‌شده، جواب می‌سازه

یه Prompt ساده RAG اینطوری هست:

بر اساس اطلاعات زیر به سوال کاربر جواب بده.
اگه جواب توی اطلاعات نیست، بگو "نمی‌دونم".

اطلاعات:
{قطعات بازیابی‌شده}

سوال: {سوال کاربر}
جواب:

Vector Database چیه؟ — ساده توضیح می‌دم

شاید اسم Vector Database رو زیاد شنیده باشی. بذار ساده توضیح بدم.

دیتابیس‌های معمولی (مثل MySQL) برای جستجوی دقیق طراحی شدن. یعنی: «رکوردی رو پیدا کن که نام = علی و سن = ۳۰». ولی وقتی داری با معنا و مفهوم کار می‌کنی، جستجوی دقیق کافی نیست.

مثلاً اگه کاربر بپرسه «چطور محصول رو پس بدم؟» و توی مستنداتت نوشته «نحوه مرجوع کالا»، جستجوی کلمه‌ای این دو تا رو به هم وصل نمی‌کنه. ولی Vector Database می‌تونه بفهمه این دو تا معنای مشابه دارن.

چطور؟ هر متن به یه بردار تبدیل می‌شه — یه لیست از اعداد که موقعیتش رو توی فضای معنایی نشون می‌ده. متن‌هایی که معنای مشابه دارن، بردارهاشون هم نزدیک هم هستن.

محبوب‌ترین Vector Database ها:

• Pinecone: مدیریت‌شده (Managed)، راحت‌ترین برای شروع
• Weaviate: اوپن‌سورس، قابلیت‌های خوب
• Qdrant: سریع، مناسب برای مقیاس بالا
• Chroma: سبک، مناسب برای پروتوتایپ
• pgvector: اگه از PostgreSQL استفاده می‌کنی، لازم نیست دیتابیس جدید اضافه کنی

Embedding چیه و چرا مهمه؟

Embedding فرایندی هست که یه متن (یا تصویر، یا هر نوع داده‌ای) رو به یه بردار عددی تبدیل می‌کنه. این بردار خیلی جالبه چون معنای متن رو رمزگذاری می‌کنه.

مثلاً:

• «گربه روی بالشت نشسته» و «فِلین روی کوسن استراحت می‌کنه» → بردارهای نزدیک
• «گربه روی بالشت نشسته» و «قیمت سهام بالا رفت» → بردارهای دور

برای RAG، انتخاب مدل Embedding خیلی مهمه. مدل‌های محبوب:

• OpenAI text-embedding-3-large: کیفیت بالا، هزینه‌دار
• Cohere Embed v3: خوب برای جستجوی چندزبانه
• BGE-M3: اوپن‌سورس، چندزبانه، رایگان
• E5-Mistral: عملکرد عالی برای Retrieval

یه مثال عملی ساده

بذار یه مثال عملی با Python بزنم تا قضیه ملموس‌تر بشه:

from langchain.document_loaders import TextLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma
from langchain.chat_models import ChatOpenAI
from langchain.chains import RetrievalQA

# ۱. لود کردن سند
loader = TextLoader("company_docs.txt")
documents = loader.load()

# ۲. تکه‌تکه کردن
splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50
)
chunks = splitter.split_documents(documents)

# ۳. ساخت Vector Store
embeddings = OpenAIEmbeddings()
vectorstore = Chroma.from_documents(chunks, embeddings)

# ۴. ساخت Chain
llm = ChatOpenAI(model="gpt-4")
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=vectorstore.as_retriever()
)

# ۵. پرسیدن سوال
answer = qa_chain.run("سیاست مرجوعی کالا چیه؟")
print(answer)

این کد ساده‌ست ولی اصل ماجرا رو نشون می‌ده. توی Production باید خیلی چیزهای دیگه‌ای هم اضافه کنی — Error Handling، Caching، Monitoring و…

Chunking — هنر تکه‌تکه کردن

یکی از مهم‌ترین بخش‌های RAG که خیلی‌ها دست‌کم می‌گیرنش، Chunking هست. نحوه تکه‌تکه کردن اسناد مستقیماً روی کیفیت جواب‌ها تأثیر داره.

روش‌های مختلف Chunking:

• Fixed Size: هر ۵۰۰ کاراکتر یه تکه. ساده ولی ممکنه وسط جمله قطع کنه.
• Recursive: سعی می‌کنه از مرزهای طبیعی (پاراگراف، جمله) استفاده کنه. معمولاً بهتره.
• Semantic: بر اساس معنا تکه‌تکه می‌کنه — وقتی موضوع عوض می‌شه، تکه جدید شروع می‌شه.
• Document-based: بر اساس ساختار سند (عنوان، زیرعنوان) تکه‌تکه می‌کنه.

RAG vs Fine-tuning — کِی از کدوم استفاده کنی؟

یه سوال رایج: «چرا مدل رو Fine-tune نکنم؟ مگه نمی‌شه اطلاعاتم رو بهش یاد بدم؟»

جواب کوتاه: می‌شه، ولی RAG و Fine-tuning برای کارهای مختلفی مناسبن.

RAG رو انتخاب کن وقتی:

• داده‌هات مرتب عوض می‌شن (قیمت، موجودی، اخبار)
• دقت و قابلیت استناد مهمه (باید بگی جواب از کجا اومده)
• حجم داده زیاده (هزاران سند)
• بودجه محدوده (Fine-tuning گرونه)
• می‌خوای سریع شروع کنی

Fine-tuning رو انتخاب کن وقتی:

• می‌خوای لحن و سبک مدل رو عوض کنی
• تسک خیلی تخصصیه (مثلاً تحلیل تصاویر پزشکی)
• ساختار خروجی مهمه (مثلاً همیشه JSON با فرمت خاص)
• داده‌ها ثابتن و زیاد عوض نمی‌شن

یا هر دو!

بهترین سیستم‌ها معمولاً هر دو رو ترکیب می‌کنن. مدل رو Fine-tune می‌کنن برای لحن و سبک، و RAG استفاده می‌کنن برای اطلاعات به‌روز. این ترکیب بهترین نتیجه رو می‌ده.

چالش‌های واقعی RAG

RAG روی کاغذ ساده‌ست. توی عمل، چند تا چالش مهم داره:

۱. کیفیت Retrieval

اگه مرحله بازیابی اطلاعات اشتباه بیاره، بقیه فرایند خراب می‌شه. Garbage In, Garbage Out. بهبود کیفیت Retrieval با تکنیک‌هایی مثل Hybrid Search (ترکیب Keyword + Semantic) و Re-ranking (مرتب‌سازی مجدد نتایج) ممکنه.

۲. مدیریت داده‌های ناهمگن

داده‌هات ممکنه توی فرمت‌های مختلف باشن: PDF، Word، HTML، دیتابیس، API. هر کدوم نیاز به پیش‌پردازش متفاوتی دارن.

۳. به‌روزرسانی

وقتی اطلاعات عوض می‌شن، باید Vector Store هم آپدیت بشه. مدیریت این به‌روزرسانی‌ها توی مقیاس بزرگ چالش‌برانگیزه.

۴. Latency

اضافه شدن مرحله Retrieval، زمان پاسخ‌دهی رو بیشتر می‌کنه. بهینه‌سازی سرعت بازیابی مهمه.

تکنیک‌های پیشرفته RAG

اگه RAG پایه رو راه انداختی و می‌خوای بهترش کنی:

• Hybrid Search: ترکیب جستجوی Keyword (مثل BM25) با Semantic Search. خیلی وقت‌ها نتیجه بهتری می‌ده.
• Re-ranking: بعد از بازیابی اولیه، یه مدل دیگه نتایج رو دوباره رتبه‌بندی می‌کنه. Cohere Reranker یه گزینه خوبه.
• Query Expansion: سوال کاربر رو بازنویسی یا گسترش بده قبل از جستجو. مثلاً «مرجوعی» رو تبدیل کن به «مرجوعی OR بازگشت کالا OR استرداد».
• Parent-Child Retrieval: تکه کوچیک پیدا کن، ولی تکه بزرگ‌تر (والد) رو به LLM بده. این‌طوری هم دقت بالاست، هم Context کافی.
• Multi-step RAG: جواب اولیه بساز، بعد بر اساس اون جواب دوباره جستجو کن و جواب بهتری بده.

جمع‌بندی — RAG قلب پروژه‌های AI تجاریه

اگه می‌خوای یه محصول AI واقعی بسازی — نه یه دمو، نه یه پروژه دانشگاهی — احتمالاً به RAG نیاز داری. دلیلش ساده‌ست: LLM به تنهایی داده‌های تو رو نمی‌شناسه.

RAG بهت اجازه می‌ده:

• اطلاعات به‌روز به مدل بدی
• داده‌های خصوصیت رو استفاده کنی بدون اینکه توی Training باشن
• Hallucination رو کاهش بدی
• منبع جواب‌ها رو نشون بدی (Citation)

شروع کردن با RAG سخت نیست. یه Vector Database، یه مدل Embedding، و یه LLM — این سه تا هسته اصلی هستن. بقیه‌اش بهینه‌سازی و مهندسیه.

قدم اولت رو امروز بردار: یه سند ساده رو Embed کن، توی Chroma ذخیره کن، و یه سوال ازش بپرس. وقتی جواب درست رو دیدی، می‌فهمی چرا RAG قلب پروژه‌های AI تجاریه.