«پایان توهمات»؛ نقش معماری RAG در اتصال LLM به داده‌های خارجی

تصور کنید یکی از کارکنان شما می‌خواهد تحلیل دقیقی از یک فایل PDF خصوصی یا وضعیت آب‌وهوای همین لحظه داشته باشد، اما مدل هوش مصنوعی او فقط داده‌های تا دو سال پیش را می‌شناسد. آیا یک عامل هوش مصنوعی می‌تواند بدون حتی یک ثانیه آموزش اضافی، وضعیت آب‌وهوای امروز را ارائه دهد یا یک PDF خصوصی شرکت را تحلیل کند؟ این قابلیت محوری «تولید بازیابی‌افزا» (Retrieval-Augmented Generation یا RAG) است؛ چارچوبی که اساساً نحوه برخورد مدل‌های زبانی بزرگ (LLM) با صحت واقعیات را تغییر می‌دهد. RAG این کار را با بازیابی داده‌ها از منابع خارجی معتبر، پیش از تولید پاسخ نهایی، انجام می‌دهد تا مدل را از یک «جعبه بسته» به «پژوهشگری» تبدیل کند که ابتدا منابع را می‌خواند و سپس پاسخ می‌دهد.

این چارچوب اساساً روش برخورد مدل‌های زبانی بزرگ (LLM) — که شبیه کتابخانه‌داری هستند که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — با صحت واقعیات را تغییر می‌دهد. طبق تعریف رسمی، RAG یک چارچوب هوش مصنوعی است که دقت مدل‌های زبانی را از طریق استخراج واقعیات از یک پایگاه دانش خارجی و معتبر افزایش می‌دهد. این فرآیند از «توهم» (Hallucination) جلوگیری می‌کند؛ توهم زمانی رخ می‌دهد که هوش مصنوعی فارغ از اینکه اطلاعات حاصله نادرست است یا خیر، واقعیات را از خودش ابداع می‌کند. ما پیش‌تر در بررسی راهکار RAG برای توقف توهمات به تفصیل شرح دادیم که چگونه جست‌وجوی زنده می‌تواند حافظه ایستای مدل‌ها را به چالش بکشد.

اکثر مدل‌های زبانی از مشکل «تاریخ قطع دانش» (Knowledge Cutoff) رنج می‌برند که در واقع تاریخی است که داده‌های آموزشی آن‌ها در آنجا پایان می‌یابد. از آنجایی که به‌روزرسانی این مدل‌ها نیازمند توان محاسباتی عظیم و هزینه‌های نجومی است، نمی‌توان آن‌ها را به‌صورت لحظه‌ای برای keeping up با جریان عظیم داده‌های جهانی که هر ثانیه تولید می‌شوند، بازآموزی کرد. اگر شرکت‌ها بخواهند مدل‌های LLM خود را به‌طور مداوم بر اساس این حجم انبوه از داده‌ها به‌روز کنند، به دلیل مقیاس وسیع منابع محاسباتی مورد نیاز، هرج‌ومرج به بار خواهد آمد. RAG این مشکل را با treating کردن LLM به عنوان یک «موتور استدلال» (Reasoning Engine) به جای یک پایگاه داده ایستا حل می‌کند. طبق یک راهنمای فنی که در ۱۰ جولای ۲۰۲۶ در وب‌سایت dev.to منتشر شد، RAG به هوش مصنوعی اجازه می‌دهد تا ابزارها را فراخوانی کرده و داده‌های اینترنتی را در لحظه دریافت کند تا پاسخ‌هایی به‌روز و مختص به هر دامنه (Domain-specific) ارائه دهد.

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

سازوکار پاسخگویی به درخواست‌های لحظه‌ای

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

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

معماری RAG: نمایه سازی و پرس‌وجو

فرآیند RAG از طریق دو خط لوله (Pipeline) متمایز عمل می‌کند: مرحله نمایه‌سازی (Indexing) و مرحله پرس‌وجو (Query).

مرحله نمایه‌سازی (Indexing):
در طی این مرحله، سیستم پایگاه دانش را از طریق گام‌های زیر آماده می‌کند:

• تبدیل متن به تکه (Text to Chunk): متون خام حاصل از پرامپت‌ها، اسناد یا فایل‌های ارسالی کاربر (مانند PDFها) به قطعات کوچکی به نام «تکه‌ها» یا Chunks تقسیم می‌شوند. این تکه‌ها شبیه برش‌های یک کیک بلند هستند که مدل تکه‌تکه می‌خورد.
• تبدیل تکه به بردار معنایی (Chunk to Vector Embedding): از آنجایی که تکه‌های خام به خودی خود معنای ریاضی ندارند، تحت فرآیند بردار معنایی (Embedding) قرار می‌گیرند. این کار یک معنای واقعی و عددی به هر تکه می‌بخشد و داده‌ها را به صورت عددی نمایش می‌دهد؛ چیزی شبیه به کارت معرفی عددی برای هر واژه تا همسایگان معنایی‌اش شناسایی شوند.
• ذخیره‌سازی (Storage): این تکه‌ها و برداری‌های متناظر آن‌ها در یک پایگاه‌داده برداری (Vector Database) ذخیره می‌شوند. این روش ذخیره‌سازی به سیستم اجازه می‌دهد تا بعدها بر اساس پرس‌وجوی کاربر، نزدیک‌ترین معنا را انتخاب کند.

مرحله پرس‌وجو (Query):
زمانی که کاربر یک پرس‌وجو ارسال می‌کند، مرحله Query برای بازیابی و ترکیب اطلاعات آغاز می‌شود:

• تبدیل متن کاربر به تکه (User Text to Chunk): پرس‌وجو یا پرامپت کاربر، مشابه فرآیند نمایه‌سازی، به تکه‌ها تبدیل می‌شود.
• تبدیل تکه به بردار معنایی (Chunk to Vector Embedding): سیستم برداربندی را اعمال می‌کند تا به تکه‌های کاربر معنای ریاضی ببخشد.
• جست‌وجوی شباهت (Similarity Query Search): سیستم در VectorDB جست‌وجو می‌کند تا ببیند آیا هیچ معنای برداری نزدیک به پرس‌وجوی کاربر وجود دارد یا خیر.
• بازیابی تکه (Chunk Retrieval): شبیه‌ترین تکه‌ها از پایگاه داده بازیابی می‌شوند.
• تولید پرامپت سیستمی (System Prompt Generation): پرس‌وجوی اصلی کاربر و تکه‌های بازیابی‌شده به عنوان یک «پرامپت سیستمی» به مدل LLM ارسال می‌شوند. این کار، مدل را با زمینه (Context) مورد نیاز برای تولید یک پاسخ مستند و grounded تجهیز می‌کند.

کاربردهای عملی در دنیای واقعی

• آموزش: دانشجویان یا متخصصان یادگیری می‌توانند PDFهای حجیم را آپلود کنند تا سوالات خود را بپرسند یا موضوعات خاصی را مکان‌یابی کنند. عامل هوش مصنوعی از فایل‌های ارائه شده و داده‌های آموزشی خود برای ارائه پاسخ‌های استوار استفاده می‌کند. در دوره‌های آنلاین که شامل ویدیوهای بسیاری است، RAG به دانشجویان کمک می‌کند تا با ارائه شماره دقیق ویدیو و برچسب زمانی (Timestamp)، موضوعات مورد نظر را بیابند و مطالعه را قابل‌اعتمادتر و لذت‌بخش‌تر کنند.
• بهره‌وری سازمانی: کارکنان زمان قابل‌توجهی را صرف جست‌وجو در میان اسناد، PDFها، فایل‌ها و چت‌ها می‌کنند. یک سیستم RAG این زمان جست‌وجو را کاهش می‌دهد و به کارکنان اجازه می‌دهد تا بر حل مسائل واقعی متمرکز شوند.
• حوزه حقوقی و تطبیق (Compliance): کاربران اغلب به دلیل پاراگراف‌های طولانی و تعداد صفحات زیاد، از خواندن سیاست‌های حریم خصوصی اجتناب می‌کنند. RAG می‌تواند این سیاست‌ها را بخواند و به کاربر اجازه دهد سوالات خاصی درباره مفاد و شرایط بپرسد.
• تحلیل مالی: بخش مالی بر حجم عظیمی از گزارش‌ها و اسنادی متکی است که بررسی سنتی آن‌ها نیازمند نیروی انسانی گران‌قیمت و زمان زیاد است. عوامل RAG می‌توانند این اسناد را اسکن کنند، به سوالات پاسخ دهند و دقیقاً به خاطر بیاورند که داده‌ها در کجا قرار دارند (شامل شماره صفحه)، تا کاربران سریعاً اطلاعات صحیح را بیابند.

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

علیرغم کاربرد زیاد، RAG مستعد حالت‌های شکست خاصی است. یک مشکل اساسی این است که اگر داده‌های نادرستی به عامل داده شود، پاسخ‌های نادرستی ارائه می‌دهد، زیرا زمینه (Context) خود را بر اساس آن اطلاعات مسموم بنا کرده است. برخلاف انسان‌ها، مدل‌های LLM توانایی درک داده‌های مسموم یا بدون ساختار (Unstructured) را ندارند. علاوه بر این، محدودیت‌های حافظه وجود دارد؛ اگر یک مجموعه داده بسیار عظیم به درون پنجره متنی (Context Window) رانده شود — یعنی میز کاری که فقط جای چند ورق دارد، نه کل کتابخانه — مدل ممکن است دوباره شروع به توهم کند و پاسخ‌های غلط را با اعتماد به نفس کامل ارائه دهد.

بازیابی ضعیف (Poor Retrieval):
یک شکست رایج «بازیابی ضعیف» است، جایی که بازیاب (Retriever) اسنادی را پیدا می‌کند، اما آن‌ها اسناد اشتباهی هستند. برای مثال، اگر کاربر بپرسد «چگونه می‌توانم رمز عبور لینکدین خود را بازنشانی کنم؟» اما پایگاه داده فقط حاوی اسنادی درباره «نحوه بازنشانی رمز عبور در فیس‌بوک» باشد، مدل LLM به جای راهنمای لینکدین، پاسخی بر اساس اسناد فیس‌بوک ارائه می‌دهد. این موضوع تأیید می‌کند که بیشتر شکست‌های RAG ناشی از خطای بازیابی داده‌ها است تا ضعف مدل‌های زبانی.

بازیابی ضعیف به دو دلیل اصلی رخ می‌دهد:

۱. برداربندی بد (Bad Embedding): برداربندی، متن را به بردار تبدیل می‌کند. اگر دو جمله مرتبط (مثلاً «چگونه رمز عبور فیس‌بوک خود را بازنشانی کنم» و «رمز عبور فیس‌بوک خود را فراموش کردم») در فضای برداری سه بعدی (3D vector space) از هم دور قرار گیرند، جست‌وجوی شباهت شکست می‌خورد و مدل نمی‌تواند تطابق مناسبی ایجاد کند.
۲. تکه‌بندی نادرست (Poor Chunking): اگر متن به تکه‌هایی تقسیم شود که ارتباطی با یکدیگر نداشته باشند، پاسخ‌ها آسیب می‌بینند. برای مثال، اگر یک راهنما به تکه A («گام ۱: به تنظیمات بروید»)، تکه B («روی رمز عبور کلیک کنید») و تکه C («رمز عبور جدید را وارد کنید») تقسیم شود و بازیاب فقط تکه C را بازیابی کند، مدل LLM عبارت «رمز عبور جدید را وارد کنید» را دریافت می‌کند بدون اینکه بداند باید کجا برود، و در نتیجه پاسخ بی‌فایده خواهد بود. در همین راستا، تکه‌بندی عامل‌محور به عنوان یک روش نوین برای اصلاح این گسست‌های معنایی معرفی شده است.

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

برای خوانندگان و توسعه‌دهندگان، این بدان معنای است که کیفیت یک سیستم RAG کمتر به اندازه مدل LLM و بیشتر به کیفیت خط لوله داده‌ها (Data Pipeline) و دقت مدل برداربندی (Embedding Model) بستگی دارد.

گام بعدی شما

• برای پیاده‌سازی RAG، به‌جای تمرکز بر اندازه مدل، روی کیفیت تکه‌بندی (Chunking) و دقت مدل برداربندی تمرکز کنید.
• از پایگاه‌های داده برداری مثل Pinecone یا Milvus برای مدیریت داده‌های حجیم استفاده کنید.
• برای کاهش توهم، از متد Reranking استفاده کنید تا مرتبط‌ترین تکه‌ها در اولویت قرار گیرند.

اما برای حل مشکل کمبود زمینه، باید به سراغ GraphRAG بروید که سعی می‌کند این مشکل را با نقشه‌برداری از روابط بین موجودات (Entities) به جای تکیه صرف بر شباهت برداری حل کند؛ تحلیل ما در این مورد را دنبال کنید.