ایده اصلی RAG — بازیابی + تولید

ایده اصلی RAG — بازیابی + تولید

توی اپیزود قبلی دیدیم که LLM چهار تا محدودیت اساسی داره. حالا وقتشه بفهمیم RAG دقیقاً چیه و چطور این مشکلات رو حل می‌کنه.

RAG مخفف Retrieval-Augmented Generation هست. بذار کلمه به کلمه ترجمه‌ش کنیم:

• Retrieval = بازیابی (پیدا کردن اطلاعات مرتبط)
• Augmented = تقویت‌شده (غنی‌تر کردن)
• Generation = تولید (ساختن جواب نهایی)

یعنی: تولید متن که با بازیابی اطلاعات تقویت شده. به زبان ساده‌تر: قبل از اینکه بخوای جواب بدی، اول اطلاعات مرتبط رو پیدا کن، بعد بر اساس اونا جواب بده.

تشبیه دکتر و پرونده پزشکی

بهترین تشبیهی که می‌تونم برای RAG بیارم، تشبیه دکتره.

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

پرونده پزشکیت رو باز می‌کنه.

چرا؟ چون:

• نمی‌دونه آخرین بار چه دارویی بهت داده
• نمی‌دونه به چه چیزی آلرژی داری
• نمی‌دونه نتیجه آزمایش خونت چی بوده
• نمی‌دونه تاریخچه بیماری‌هات چیه

دکتر با همه دانش عمومیش، بدون پرونده پزشکی تو نمی‌تونه تشخیص درست بده.

LLM مثل اون دکتره: کلی دانش عمومی داره ولی پرونده پزشکی بیمار رو نداره. RAG همون سیستمیه که پرونده رو پیدا می‌کنه و میذاره جلوی دکتر.

حالا دکتر دو تا چیز داره: دانش عمومی پزشکی (مثل LLM) + اطلاعات خاص بیمار (مثل اطلاعات بازیابی‌شده). ترکیب این دو تا باعث میشه تشخیص و درمانش دقیق، شخصی‌سازی‌شده و قابل اعتماد باشه.

RAG دقیقاً همین کار رو برای LLM انجام میده.

معماری سه مرحله‌ای RAG

معماری پایه RAG سه مرحله داره. ساده‌ست ولی قدرتمند:

مرحله ۱: Retrieve (بازیابی)

وقتی کاربر یه سؤال می‌پرسه، اولین کار اینه که توی منابع اطلاعاتی جستجو کنی و مرتبط‌ترین قطعات اطلاعات رو پیدا کنی.

این منابع می‌تونن هر چیزی باشن:

• مستندات فنی
• مقالات وبلاگ
• فایل‌های PDF
• رکوردهای دیتابیس
• ایمیل‌ها
• هر نوع متن دیگه‌ای

نکته مهم اینه که نمی‌خوای همه اطلاعات رو بدی به مدل. فقط مرتبط‌ترین‌ها رو می‌خوای. مثل همون دکتر که فقط پرونده تو رو باز می‌کنه، نه پرونده همه بیمارها.

مرحله ۲: Augment (تقویت)

حالا اطلاعات مرتبط رو پیدا کردی. مرحله بعدی اینه که اونا رو با سؤال کاربر ترکیب کنی و یه Prompt غنی‌شده بسازی.

یه Prompt ساده اینه:

سؤال کاربر: گوشی سامسونگ A54 ضد آبه؟

یه Prompt تقویت‌شده با RAG اینه:

بر اساس اطلاعات زیر به سؤال کاربر جواب بده:

--- اطلاعات مرتبط ---
محصول: سامسونگ Galaxy A54 5G
استاندارد ضد آب: IP67
توضیح: مقاوم در برابر غوطه‌وری در آب تا عمق ۱ متر به مدت ۳۰ دقیقه
گارانتی: ۱۸ ماه شرکتی
قیمت: ۱۲,۵۰۰,۰۰۰ تومان
وضعیت: موجود
--- پایان اطلاعات ---

سؤال کاربر: گوشی سامسونگ A54 ضد آبه؟

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

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

آخرین مرحله اینه که Prompt تقویت‌شده رو بدی به LLM و ازش بخوای جواب نهایی رو تولید کنه. مدل حالا هم دانش عمومیش رو داره، هم اطلاعات خاص و به‌روز. پس می‌تونه یه جواب دقیق، طبیعی و قابل اعتماد بده.

جواب مدل ممکنه اینطوری باشه:

بله، سامسونگ Galaxy A54 5G دارای استاندارد IP67 هست. یعنی در برابر غوطه‌وری در آب تا عمق ۱ متر به مدت ۳۰ دقیقه مقاومه. البته توصیه میشه عمداً گوشی رو توی آب نبری چون گارانتی خیسی رو پوشش نمیده. این گوشی الان با ۱۸ ماه گارانتی شرکتی موجوده.

RAG در مقابل روش‌های دیگه

شاید بپرسی: «خب چرا RAG؟ مگه روش‌های دیگه‌ای نیست؟» بذار مقایسه کنیم:

روش ۱: Prompt Engineering ساده

یعنی اطلاعات رو دستی بذاری توی Prompt. مثلاً هر بار قیمت محصولات رو کپی-پیست کنی. مشکلش: مقیاس‌پذیر نیست. وقتی هزاران مستند داری نمیشه دستی این کار رو کرد.

روش ۲: Fine-tuning

یعنی خود مدل رو روی داده‌هات بازآموزی کنی. مشکلش: گرونه، زمان‌بره و هر بار داده عوض بشه باید دوباره آموزش بدی. به‌علاوه مدل ممکنه اطلاعات قدیمی و جدید رو قاطی کنه.

روش ۳: RAG

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

یه مثال ساده با کد

بذار یه مثال خیلی ساده ببینیم. فعلاً بدون Vector Database و Embedding. فقط ایده اصلی رو نشون بدم:

import openai

# مرحله ۱: منابع اطلاعاتی ما (در واقعیت از دیتابیس میاد)
knowledge_base = [
    "سامسونگ A54 دارای استاندارد IP67 است و ضد آب تا عمق ۱ متر می‌باشد.",
    "گارانتی سامسونگ A54 در فروشگاه ما ۱۸ ماه شرکتی است.",
    "قیمت سامسونگ A54 برابر ۱۲,۵۰۰,۰۰۰ تومان است.",
    "آیفون ۱۵ دارای استاندارد IP68 است.",
    "شیائومی ردمی نوت ۱۳ ضد آب نیست.",
]

# مرحله ۲: جستجوی ساده (بعداً با Embedding جایگزین میشه)
def simple_search(query, docs, top_k=3):
    """جستجوی خیلی ساده بر اساس کلمات مشترک"""
    scores = []
    query_words = set(query.lower().split())
    for doc in docs:
        doc_words = set(doc.lower().split())
        score = len(query_words & doc_words)
        scores.append((score, doc))
    scores.sort(reverse=True)
    return [doc for score, doc in scores[:top_k]]

# مرحله ۳: RAG Pipeline
def rag_answer(question):
    # Retrieve: پیدا کردن اطلاعات مرتبط
    relevant_docs = simple_search(question, knowledge_base)
    
    # Augment: ساختن Prompt غنی‌شده
    context = "\n".join(relevant_docs)
    prompt = f"""بر اساس اطلاعات زیر به سؤال کاربر جواب بده.
اگه اطلاعات کافی نیست، بگو نمی‌دونم.

اطلاعات:
{context}

سؤال: {question}"""
    
    # Generate: تولید جواب
    response = openai.chat.completions.create(
        model="gpt-4",
        messages=[{"role": "user", "content": prompt}]
    )
    return response.choices[0].message.content

# استفاده
answer = rag_answer("آیا سامسونگ A54 ضد آبه؟")
print(answer)

این کد خیلی ساده‌ست و توی پروداکشن اینطوری نمی‌نویسیم. ولی ایده اصلی RAG رو نشون میده: جستجو → ترکیب → تولید.

اجزای یه سیستم RAG واقعی

حالا که ایده اصلی رو فهمیدی، بذار یه نگاه کلی به اجزای یه سیستم RAG واقعی بندازیم. توی اپیزودهای بعدی هر کدوم رو مفصل بررسی می‌کنیم:

۱. Document Loader (بارگذاری مستندات)

مستنداتت رو از منابع مختلف می‌خونه: PDF، Word، HTML، دیتابیس، API و…

۲. Chunking (تکه‌تکه کردن)

مستندات بزرگ رو به قطعات کوچیک‌تر تقسیم می‌کنه. چرا؟ چون هم جستجو دقیق‌تر میشه، هم توی Context Window جا میشه.

۳. Embedding Model (مدل تبدیل به بردار)

هر قطعه متن رو تبدیل به یه بردار عددی می‌کنه. این بردارها معنای متن رو نشون میدن.

۴. Vector Database (دیتابیس برداری)

بردارها رو ذخیره می‌کنه و امکان جستجوی سریع بر اساس شباهت معنایی رو فراهم می‌کنه.

۵. Retriever (بازیابی‌کننده)

سؤال کاربر رو تبدیل به بردار می‌کنه و مشابه‌ترین قطعات رو از Vector Database پیدا می‌کنه.

۶. Prompt Template (قالب Prompt)

اطلاعات بازیابی‌شده رو با سؤال کاربر ترکیب می‌کنه و یه Prompt مناسب می‌سازه.

۷. LLM (مدل زبانی)

Prompt نهایی رو می‌گیره و جواب تولید می‌کنه.

۸. Post-processing (پردازش نهایی)

جواب رو فرمت می‌کنه، منابع رو اضافه می‌کنه و کنترل کیفیت انجام میده.

دو فاز اصلی RAG

یه سیستم RAG دو فاز اصلی داره:

فاز ۱: Ingestion (خوردن داده)

این فاز آفلاینه و معمولاً یه بار (یا به‌صورت دوره‌ای) اجرا میشه:

1. مستندات رو بخون
2. تکه‌تکه‌شون کن
3. هر تکه رو تبدیل به بردار کن
4. بردارها رو توی Vector Database ذخیره کن

فاز ۲: Query (پرسش)

این فاز آنلاینه و هر بار که کاربر سؤال می‌پرسه اجرا میشه:

1. سؤال کاربر رو تبدیل به بردار کن
2. مشابه‌ترین بردارها رو از دیتابیس پیدا کن
3. متن اصلی اون بردارها رو بردار
4. با سؤال ترکیب کن و بده به LLM
5. جواب رو برگردون به کاربر

RAG چقدر مؤثره؟

تحقیقات نشون داده که RAG می‌تونه:

• دقت جواب‌ها رو تا ۴۰-۶۰ درصد بهبود بده
• نرخ توهم رو تا ۷۰ درصد کاهش بده
• رضایت کاربر رو به‌شکل قابل توجهی افزایش بده
• هزینه رو نسبت به Fine-tuning به‌شدت کاهش بده

البته این اعداد بسته به کیفیت پیاده‌سازی فرق می‌کنه. یه سیستم RAG بد ممکنه حتی بدتر از LLM خالی باشه. ولی یه سیستم RAG خوب واقعاً تحول‌آفرینه.

جمع‌بندی

توی این اپیزود یاد گرفتی که:

• RAG یعنی بازیابی اطلاعات + تولید متن
• مثل دکتری که پرونده پزشکی رو قبل از تشخیص باز می‌کنه
• سه مرحله اصلی داره: Retrieve → Augment → Generate
• دو فاز داره: Ingestion (آفلاین) و Query (آنلاین)
• نسبت به Fine-tuning ارزون‌تر، سریع‌تر و انعطاف‌پذیرتره

توی اپیزود بعدی میریم سراغ Embedding — قلب تپنده RAG. یاد می‌گیری چطور متن تبدیل به عدد میشه و چرا این تبدیل انقدر مهمه.