هوش مصنوعی

RAG چیست؟ ساخت دستیار هوشمند روی داده‌های سازمان

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

کتابی باز روی میز چوبی در کتابخانه‌ای گرم با نور آفتاب از پنجره‌ها؛ نمادی از بازیابی دانش از اسناد در RAG

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

در این مقاله توضیح می‌دهیم RAG دقیقاً چیست، چه اجزایی دارد، جستجوی برداری در آن چه نقشی دارد، چه زمانی بهتر از تنظیم دقیق مدل است و برای ساخت یک دستیار هوشمند سازمانی قابل اعتماد به چه نکاتی باید توجه کرد.

RAG چیست و چه مشکلی را حل می‌کند؟

RAG مخفف Retrieval-Augmented Generation است که در فارسی می‌توان آن را «تولید افزوده با بازیابی» نامید. ایده ساده است: مدل زبانی به‌تنهایی پاسخ نمی‌دهد، بلکه اول یک سیستم بازیابی مرتبط‌ترین قطعه‌های متن را از میان اسناد شما پیدا می‌کند و بعد مدل با تکیه بر همین قطعه‌ها پاسخ می‌نویسد.

این روش چند مشکل مهم را هم‌زمان حل می‌کند:

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

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

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

آماده‌سازی و نمایه‌سازی اسناد

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

برای متن فارسی این مرحله ظرافت‌های خودش را دارد: یکسان‌سازی «ی» و «ک» عربی و فارسی، مدیریت نیم‌فاصله و حذف سرصفحه‌ها و پانویس‌های تکراری کیفیت بازیابی را به‌طور محسوس بهتر می‌کند. مدل Embedding را هم از میان مدل‌های چندزبانه‌ای انتخاب کنید که روی متن فارسی خوب کار می‌کنند و آن را با نمونه‌پرسش‌های واقعی بسنجید.

بازیابی و پاسخ‌گویی

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

جستجوی برداری و پایگاه‌داده برداری

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

برای نگهداری بردارها چند مسیر رایج وجود دارد:

  • PostgreSQL با افزونه pgvector: اگر از قبل PostgreSQL دارید، ساده‌ترین شروع است؛ متن، متادیتا، سطح دسترسی و بردار کنار هم در یک پایگاه‌داده می‌مانند و با یک کوئری فیلتر می‌شوند.
  • موتورهای جستجو مانند OpenSearch و Elasticsearch: قابلیت جستجوی برداری دارند و ترکیب آن با جستجوی متنی کلاسیک در آن‌ها طبیعی است.
  • پایگاه‌داده برداری اختصاصی مانند Qdrant، Milvus یا Weaviate: برای حجم بسیار بالا و نیازهای خاص جستجوی برداری طراحی شده‌اند، اما یک سامانه دیگر به زیرساخت شما اضافه می‌کنند.

برای بیشتر پروژه‌های سازمانی، شروع با PostgreSQL روی پایگاه‌داده مدیریت‌شده انتخاب منطقی است، به شرطی که پیش از شروع مطمئن شوید افزونه موردنیاز در نسخه انتخابی در دسترس است. در عمل، بهترین نتیجه معمولاً از جستجوی ترکیبی به دست می‌آید: جستجوی برداری برای معنا و جستجوی کلیدواژه‌ای برای کدها، شماره‌ها و نام‌های خاص. افزودن یک مرحله رتبه‌بندی دوباره (Reranking) روی نتایج اولیه هم دقت را بالاتر می‌برد.

RAG یا تنظیم دقیق مدل؟

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

دسترسی، امنیت و کیفیت پاسخ

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

معماری پیشنهادی RAG روی ابر

  • اسناد خام و نسخه‌های پردازش‌شده در فضای ذخیره‌سازی فایل با کلید دسترسی جدا برای هر سرویس.
  • فرایند استخراج متن، قطعه‌بندی و ساخت بردار روی سرور ابری یا به شکل کار زمان‌بندی‌شده روی کوبرنتیز.
  • متن، متادیتا و بردارها در PostgreSQL یا موتور جستجو روی پایگاه‌داده مدیریت‌شده، با بکاپ منظم.
  • سرویس پاسخ‌گو و مدل زبانی در شبکهٔ خصوصی پروژه، با فایروال و یک ورودی کنترل‌شده.
  • برای سازمان‌هایی که داده‌شان نباید خارج شود، اجرای کل این مسیر روی ابر خصوصی سازمانی.

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

  • منابع اسناد و مالک هر کدام را مشخص کنید.
  • متن فارسی را پیش از قطعه‌بندی یکسان‌سازی و پاک‌سازی کنید.
  • مدل Embedding را با پرسش‌های واقعی فارسی ارزیابی کنید.
  • سطح دسترسی هر سند را در متادیتا ذخیره و هنگام جستجو اعمال کنید.
  • جستجوی ترکیبی برداری و کلیدواژه‌ای را امتحان کنید.
  • پاسخ‌ها را همراه منبع نمایش دهید.
  • مجموعه آزمون پرسش و پاسخ بسازید و پس از هر تغییر اجرا کنید.
  • برای به‌روزرسانی و حذف اسناد یک فرایند منظم داشته باشید.

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

برای RAG حتماً به پایگاه‌داده برداری جداگانه نیاز داریم؟

نه. برای بیشتر پروژه‌ها PostgreSQL با افزونه برداری یا یک موتور جستجو با قابلیت برداری کافی است. پایگاه‌داده برداری اختصاصی معمولاً وقتی ارزش پیدا می‌کند که حجم بردارها بسیار زیاد باشد یا نیاز خاصی داشته باشید.

آیا RAG با متن فارسی خوب کار می‌کند؟

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

آیا RAG پاسخ‌های ساختگی را کاملاً حذف می‌کند؟

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

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

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