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

تیم آرادتیم مهندسی

مدل‌های زبانی به تنهایی از کسب‌وکار شما چیزی نمی‌دانند و گاهی با اطمینان، اشتباه جواب می‌دهند. RAG (تولید تقویت‌شده با بازیابی) همان تکنیکی است که پاسخ مدل را به اسناد، آیین‌نامه‌ها و دانش واقعی سازمان شما گره می‌زند — تا دستیار هوشمند، به‌جای حدس، با ارجاع به منبع پاسخ دهد.

مسئله‌ای که هر مدیری در اولین آزمایش با آن روبرو می‌شود

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

این پدیده را «توهم» می‌نامند و بدترین خصوصیتش این نیست که غلط است — این است که شبیه جواب درست به نظر می‌رسد. یک پاسخ مبهم را کاربر تشخیص می‌دهد و دوباره می‌پرسد؛ یک پاسخ قاطع و غلط را باور می‌کند و بر اساسش تصمیم می‌گیرد.

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

RAG به زبان ساده: اول بازیابی، بعد تولید

RAG مخفف Retrieval-Augmented Generation است — تولیدِ تقویت‌شده با بازیابی. اسم پیچیده است، ایده ساده: به مدل اجازه ندهید از حافظه‌اش جواب بدهد؛ اول متن مربوطه را از اسناد خودتان پیدا کنید و جواب را از همان متن بخواهید.

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

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

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

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

در عمل سه اتفاق پشت سر هم می‌افتد:

  1. آماده‌سازی، یک‌بار. اسناد شما — آیین‌نامه، کاتالوگ، قرارداد نمونه، تاریخچه تیکت‌های پشتیبانی — به قطعه‌های کوچک شکسته می‌شوند و هر قطعه به یک نمایش عددی تبدیل می‌شود که معنایش را رمزگذاری می‌کند. این نمایش‌ها در پایگاه داده‌ای ذخیره می‌شوند که می‌تواند «شبیه‌ترین معنا» را پیدا کند، نه فقط «همان کلمه» را.
  2. بازیابی، در لحظه پرسش. پرسش کاربر هم به همان فضا نگاشت می‌شود و چند قطعه نزدیک‌ترین به آن بیرون کشیده می‌شود. اینجاست که تفاوت با جستجوی کلیدواژه‌ای دیده می‌شود: کاربری که می‌پرسد «چند وقت ضمانت داره؟» متنی را پیدا می‌کند که نوشته «مدت گارانتی» — چون معنا نزدیک است، هرچند کلمه‌ها یکی نیستند.
  3. تولید. آن قطعه‌ها همراه با پرسش به مدل داده می‌شود، با این دستور که فقط از همین‌ها جواب بدهد و اگر جواب در متن نبود، بگوید نمی‌داند.

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

چرا نه فاین‌تیون، و چرا نه چت‌بات آماده

سه راه روی میز است و اغلب با هم اشتباه می‌شوند.

فاین‌تیون (آموزش تکمیلی مدل) یعنی وزن‌های مدل را با داده خودتان کمی جابه‌جا کنید. این کار در تغییر سبک و قالب پاسخ خوب است — مثلاً اینکه مدل همیشه با لحن رسمی و ساختار مشخص جواب دهد. برای دانش انتخاب بدی است: هر بار که یک بخشنامه عوض شود باید دوباره آموزش بدهید، نمی‌توانید بگویید جواب از کدام سند آمده، و حذف یک سند از حافظه مدل عملاً ممکن نیست. دانش سازمانی مرتب عوض می‌شود؛ چیزی که مرتب عوض می‌شود را نباید در وزن‌های مدل پخت.

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

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

این‌ها رقیب هم نیستند: یک سامانه پخته معمولاً RAG را برای دانش، و کمی تنظیم دستور و قالب را برای لحن، با هم دارد.

کجا واقعاً جواب می‌دهد

سه کاربرد در سازمان‌های ایرانی بیشترین بازگشت را داشته‌اند:

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

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

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

الگوی مشترک هر سه: جایی که جواب در جایی نوشته شده است ولی رسیدن به آن گران است. اگر جواب هیچ‌جا مستند نیست، RAG آن را نمی‌سازد — مسئله شما مستندسازی است، نه هوش مصنوعی.

دو ملاحظه که در ایران تعیین‌کننده‌اند

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

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

از کجا شروع کنیم

RAG را به‌عنوان یک پروژه بزرگ شروع نکنید. مسیری که کمترین هدررفت را داشته:

  1. یک حوزه پرسش با اسناد سالم انتخاب کنید. یک محصول، یک آیین‌نامه، یک واحد. نه «همه دانش سازمان».
  2. پنجاه پرسش واقعی جمع کنید — از تیکت‌ها، از تماس‌ها، از کارشناسان — همراه با جواب درستشان. این مجموعه، معیار سنجش شماست و بدون آن نمی‌توانید بگویید سامانه بهتر شده یا نه.
  3. نمونه اولیه را روی همان حوزه بسنجید، با همان پنجاه پرسش. سه سنجه: درصد پاسخ درست، درصد مواردی که درست گفته «نمی‌دانم»، و درصد پاسخ‌های قاطعِ غلط. سنجه سوم مهم‌ترین است.
  4. بعد از عبور از این آزمون، دامنه را باز کنید. نه قبلش.

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

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

پروژه یا ایده‌ای دارید؟

متخصصین ما آماده برگزاری یک جلسه مشاوره رایگان هستند.

مشاوره رایگان

پروژه‌تان را با هم بررسی کنیم

جلسهٔ اول رایگان است و معمولاً همان یک جلسه روشن می‌کند پروژه چقدر کار دارد.

چطور با شما تماس بگیریم؟

برای هماهنگی سریع‌تر — اگر تماس تلفنی را ترجیح نمی‌دهید، همان شماره را در پیام‌رسان پیام می‌دهیم.

راه دوم برای رساندن پاسخ — اگر تلفن در دسترس نبود، ایمیل می‌زنیم.

در حال ارسال…

درخواست شما ثبت شد.

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