RAG چیست؟ راهنمای اتصال هوش مصنوعی به اسناد و دانش سازمان

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

نویسنده
تحریریه آیوان
تاریخ انتشار
۲۱ فروردین ۱۴۰۵
زمان مطالعه
۱۰ دقیقه
فهرست بخش‌ها
  1. RAG چیست؟
  2. RAG چگونه کار می‌کند؟
  3. اجزای اصلی معماری RAG
  4. Embedding چیست؟
  5. Chunking چیست و چرا اهمیت دارد؟
  6. Retrieval فقط Vector Search نیست
  7. پاسخ مستند یا Grounded Response
  8. امنیت و کنترل دسترسی در RAG
  9. RAG یا Fine-tuning؟
  10. کاربرد RAG در سازمان
  11. RAG در آیوان
  12. پرسش‌های متداول
  13. منابع و مطالعه بیشتر

RAG چیست؟

مدل‌های زبانی می‌توانند درباره طیف گسترده‌ای از موضوعات پاسخ دهند، اما معمولاً اطلاعات اختصاصی و به‌روز یک سازمان را در پارامترهای خود ندارند.

مدل از قرارداد جدید شرکت، آخرین دستورالعمل منابع انسانی، اطلاعات یک سامانه داخلی یا تغییرات اخیر پایگاه دانش سازمان اطلاعی ندارد؛ مگر اینکه این اطلاعات به شکلی در اختیار آن قرار گیرد.

یکی از روش‌های اصلی برای حل این مسئله Retrieval-Augmented Generation یا RAG است.

در RAG، سیستم قبل از تولید پاسخ، اطلاعات مرتبط را از یک یا چند منبع مشخص پیدا می‌کند و سپس آن اطلاعات را به‌عنوان Context در اختیار مدل زبانی قرار می‌دهد.

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

RAG چگونه کار می‌کند؟

یک معماری ساده RAG معمولاً دو بخش اصلی دارد: آماده‌سازی اطلاعات و پاسخ‌گویی.

آماده‌سازی اطلاعات

اسناد و داده‌ها باید دریافت، پردازش و قابل جست‌وجو شوند. این مرحله ممکن است شامل دریافت فایل، استخراج متن، تشخیص ساختار سند، Chunking، ایجاد Embedding، ذخیره Metadata و Indexing باشد.

پاسخ‌گویی

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

  1. تحلیل سؤال کاربر
  2. جست‌وجوی اطلاعات مرتبط
  3. انتخاب مرتبط‌ترین بخش‌های محتوا
  4. افزودن Context به ورودی مدل
  5. تولید پاسخ و، در صورت امکان، نمایش منبع

Google Cloud در معماری مرجع خود نیز RAG را به فرایند آماده‌سازی داده و مرحله Serving تقسیم می‌کند.

اجزای اصلی معماری RAG

RAG یک قابلیت منفرد یا صرفاً یک پایگاه داده برداری نیست؛ بلکه زنجیره‌ای از اجزای مرتبط است. دریافت و آماده‌سازی اسناد، ساخت نمایه، تحلیل پرسش، بازیابی، رتبه‌بندی، تولید پاسخ و کنترل دسترسی باید در کنار هم طراحی شوند.

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

Embedding چیست؟

Embedding روشی برای نمایش عددی معنای محتوا است. به‌جای اینکه جست‌وجو فقط به تطابق دقیق واژه‌ها وابسته باشد، Embedding کمک می‌کند سیستم شباهت معنایی میان سؤال و بخش‌های مختلف محتوا را پیدا کند.

برای مثال، «شرایط مرخصی کارکنان چیست؟» و «کارکنان چند روز مرخصی سالانه دارند؟» از نظر واژگان دقیقاً یکسان نیستند، اما از نظر معنایی نزدیک‌اند.

این موضوع یکی از دلایلی است که Vector Search و Semantic Search در بسیاری از معماری‌های RAG استفاده می‌شوند.

Chunking چیست و چرا اهمیت دارد؟

یک سند طولانی معمولاً به‌صورت کامل وارد Prompt نمی‌شود. سند به بخش‌های کوچک‌تر یا Chunk تقسیم می‌شود تا سیستم بتواند بخش‌های مرتبط‌تر را پیدا کند.

اما Chunking صرفاً بریدن متن هر چند صد کاراکتر نیست. در بسیاری از اسناد سازمانی بهتر است ساختار واقعی محتوا، مانند عنوان، فصل، بند، ماده، تبصره، جدول، بخش قرارداد و دستورالعمل، در نظر گرفته شود.

Chunk بسیار کوچک ممکن است Context کافی نداشته باشد و Chunk بسیار بزرگ نیز ممکن است اطلاعات نامرتبط زیادی وارد Context کند. به همین دلیل Chunking یکی از عوامل مهم کیفیت RAG است.

Retrieval فقط Vector Search نیست

RAG لزوماً به معنای استفاده از Vector Search به‌تنهایی نیست. بسته به نوع محتوا می‌توان از ترکیبی از Keyword Search، Semantic Search، Vector Search، Metadata Filtering، Hybrid Search و Ranking استفاده کرد.

در محیط سازمانی Metadata اهمیت ویژه‌ای دارد. واحد سازمانی، نوع سند، تاریخ، نسخه، مالک سند و سطح محرمانگی می‌توانند در Retrieval مؤثر باشند و دامنه جست‌وجو را دقیق‌تر کنند.

پاسخ مستند یا Grounded Response

یکی از کاربردهای مهم RAG در محیط سازمانی این است که پاسخ بتواند به منابع واقعی متصل باشد. برای مثال، به‌جای اینکه سیستم فقط بگوید «طبق مقررات سازمان، این درخواست مجاز است»، بهتر است مشخص کند پاسخ بر اساس کدام سند، بند یا بخش ارائه شده است.

این کار باعث می‌شود کاربر بتواند پاسخ را بررسی کند. اما Citation به‌تنهایی تضمین‌کننده درستی پاسخ نیست.

RAG خطای مدل را از بین نمی‌برد. ممکن است سند نامرتبط یا قدیمی بازیابی شود، Chunk مناسب پیدا نشود، مدل Context را اشتباه تفسیر کند، سؤال مبهم باشد یا منبع درستی وجود نداشته باشد. RAG می‌تواند با فراهم‌کردن Context مرتبط، احتمال پاسخ‌های بدون پشتوانه را کاهش دهد، اما یک سیستم Production باید Evaluation داشته باشد.

  • Retrieval را ارزیابی کنید.
  • منابع نامعتبر یا قدیمی را حذف کنید.
  • پاسخ مدل را کنترل کنید.
  • در کاربردهای حساس امکان بررسی انسانی فراهم کنید.

امنیت و کنترل دسترسی در RAG

در یک سیستم سازمانی، وجود سند در Knowledge Base به این معنا نیست که همه کاربران باید بتوانند آن را ببینند. Retrieval باید Permission-aware باشد.

اگر کاربر به یک سند مالی یا منابع انسانی دسترسی ندارد، مدل نیز نباید بتواند آن محتوا را برای پاسخ به همان کاربر بازیابی کند.

در معماری سازمانی، Identity، Authorization، Role-Based Access، Metadata Filters، Tenant Isolation، Audit و Logging باید از ابتدا در طراحی دیده شوند.

RAG یا Fine-tuning؟

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

Fine-tuning بیشتر زمانی مفید است که بخواهیم رفتار، قالب پاسخ یا مهارت خاص مدل را تغییر دهیم؛ مانند سبک مشخص پاسخ، ساختار خروجی، نوع خاصی از طبقه‌بندی یا رفتار تخصصی تکرارشونده.

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

کاربرد RAG در سازمان

مدیریت دانش

پرسش از اسناد و دستورالعمل‌های سازمان.

پشتیبانی

جست‌وجوی پاسخ از Knowledge Base و اطلاعات محصول.

منابع انسانی

پاسخ به سیاست‌ها و فرایندهای داخلی.

قراردادها

جست‌وجو و استخراج اطلاعات از قراردادهای مجاز.

فناوری اطلاعات

جست‌وجوی Documentation و Runbookها.

عملیات

دسترسی سریع به دستورالعمل‌ها و اطلاعات مرتبط با فرایند.

RAG در آیوان

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

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

پرسش‌های متداول

RAG چیست؟

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

آیا RAG همان Vector Database است؟

خیر. Vector Database می‌تواند یکی از اجزای معماری RAG باشد، اما RAG شامل فرایندهای گسترده‌تری مانند آماده‌سازی داده، Retrieval، Ranking و تولید پاسخ است.

آیا RAG نیاز به Fine-tuning را از بین می‌برد؟

خیر. RAG و Fine-tuning اهداف متفاوتی دارند و در برخی پروژه‌ها می‌توانند در کنار هم استفاده شوند.

آیا RAG خطای مدل را کاملاً حذف می‌کند؟

خیر. RAG می‌تواند پاسخ را به منابع مرتبط متصل کند، اما Retrieval اشتباه یا تفسیر نادرست مدل همچنان ممکن است باعث خطا شود.

آیا RAG می‌تواند کاملاً داخل سازمان اجرا شود؟

بله، بسته به معماری انتخاب‌شده، اجزای RAG مانند Embedding Model، Vector Store و مدل زبانی می‌توانند در زیرساخت داخلی اجرا شوند.

منابع و مطالعه بیشتر

دانش سازمان را در اختیار دستیارهای هوشمند قرار دهید

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