ساختن دموی RAG چند روز بیشتر کار نداره؛ اما به کار انداختن واقعی‌ش تو شرکت‌ها مو رو به تنتون سیخ می‌کنه!

هیجان‌زده شدن برای دموی یک سیستم بازیابی اطلاعات افزوده (RAG) اصلاً کار سختی نیست.

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

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

دقیقاً همین‌جاست که همه‌چیز پیچیده و جذاب می‌شود.

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

و این دقیقاً نقطه‌ای است که کار مهندسیِ واقعی و سنگین آغاز می‌شود.

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

مدل هوش مصنوعی تنها یک قطعه کوچک از این پازل بزرگ است.

بازیابی اطلاعات را باید به عنوان یک زیرساخت دید

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

این فرمول زمانی جواب می‌دهد که داده‌ها جمع‌وجور، مرتب و نسبتاً تمیز باشند.

اما داده‌های سازمانی هیچ‌وقت این‌قدر تروتمیز نیستند.

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

مدل امبدینگ بهتر، داده‌های آشفته را نجات نمی‌دهد

وقتی کیفیت بازیابی پایین می‌آید، اولین راه‌حلی که به ذهن خیلی‌ها می‌رسد تعویض مدل امبدینگ (Embedding) است.

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

اما بیایید به یک سناریوی ساده‌تر فکر کنیم: یک سند اسم محصول را گذاشته «Enterprise Security Gateway»، سندی دیگر به آن گفته «ESG» و سومی صرفاً نوشته «درگاه» (Gateway). در همین حین، محدودیت‌های فنی و پیکربندی اصلی محصول در یک فایل اکسل قرار دارد که سیستم اصلاً نتوانسته ساختار آن را درست استخراج کند.

اقداماتی که باید در این شرایط انجام داد:

• تعیین سند مرجع و معتبر بین فایل‌های متناقض.

• شناسایی دقیق زمان ابطال یا جایگزینی سیاست‌های قدیمی.

• اصلاح ساختار جداول و محتواهایی که ناقص استخراج شده‌اند.

این‌ها چالش‌های مدیریت داده هستند، نه ضعف هوش مصنوعی. تیم‌های فنی قبل از دستکاری تنظیمات بازیابی، باید دقیقاً بدانند هر قطعه اطلاعات از کجا آمده، چه زمانی به‌روزرسانی شده، چه کسی مسئول آن است و تا چه اندازه می‌توان به آن اعتماد کرد.

در غیر این صورت، سیستمی می‌سازید که با ظرافت و دقت معنایی فوق‌العاده بالا، سندی کاملاً غلط را برای مدل می‌فرستد؛ و خروجی در نهایت باز هم غلط خواهد بود.

قطعه‌بندی متن (Chunking) یک تصمیم جدی در معماری است

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

اما این دیدگاه اشتباه است.

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

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

هیچ اندازه استانداردی برای قطعه‌ها وجود ندارد؛ این ساختار خودِ داده است که باید مشخص کند چطور نمایه (Index) شود.

• در راهنماهای محصول، بهتر است ساختار تیترها و بخش‌ها کاملاً حفظ شود.

• شیوه‌نامه‌ها و اسناد اداری به متاداده‌هایی مثل نام بخش، منطقه جغرافیایی و تاریخ اجرا نیاز دارند.

• برای اسکیمای دیتابیس‌ها، ساختار روابط معنادار خیلی بهتر از متن خام کار می‌کند.

پژوهش‌هایی که در سال ۲۰۲۴ روی سیستم‌های RAG سازمانی انجام شد نشان می‌دهد حتی تغییرات ساده در ساختار پایگاه دانش می‌تواند بازدهی سیستم را زیر و رو کند؛ نکته‌ای که اهمیت نظارت پیوسته و ارزیابی انسانی را دوچندان می‌کند.

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

جستجوی برداری خوب است، اما به تنهایی کافی نیست

جستجوی معنایی (Semantic Search) در پیدا کردن مفاهیمی که با عبارت جستجو هم‌معنی هستند عالی عمل می‌کند.

اما در جستجوهای سازمانی، اغلب به دقت موشکافانه نیاز داریم.

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

اینجا نقطه‌ای است که جستجوی ترکیبی (Hybrid Search) برگ برنده را رو می‌کند. سیستم‌های ترکیبی به جای اتکا به تشابه برداری، سیگنال‌های معنایی را با جستجوی کلیدواژه‌ای تلفیق کرده و در صورت نیاز از رتبه‌بندی مجدد (Reranking) بهره می‌برند.

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

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

• سوالات مفهومی و باز ← بازیابی معنایی عالی جواب می‌دهد.

• کدها و شناسه‌های دقیق ← تطابق کلیدواژه‌ای حرف اول را می‌زند.

• درخواست‌های پیچیده و ترکیبی ← تلفیق هر دو روش هوشمندانه‌ترین انتخاب است.

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

مرحله بازیابی اطلاعات را مستقل از پاسخ نهایی مدل ارزیابی کنید

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

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

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

وقتی پاسخی اشتباه از آب درمی‌آید، دلایل مختلفی می‌تواند پشت قضیه باشد:

• آیا اصل داده از اول غلط و اشتباه بوده؟

• آیا متن در زمان استخراج و پارس شدن ناقص خوانده شده؟

• آیا قطعه‌بندی نامناسب باعث حذف زمینه و بستر پیام شده؟

• آیا سیستم جستجو اصلاً سند درست را رد کرده و ندیده؟

• آیا بخش درست پیدا شده اما رتبه پایینی به آن داده شده؟

• آیا اسناد بازیابی‌شده حاوی اطلاعات ضد و نقیض بوده‌اند؟

• یا این‌که مدل علی‌رغم دریافت شواهد کامل، نتوانسته تحلیل درستی ارائه کند؟

هر کدام از این ایرادها راه‌حل کاملاً مجزایی دارند. به عنوان نمونه، مستندات ارزیابی RAG در آمازون بدراک (Amazon Bedrock) مرحله سنجش بازیابی متن را از سنجش تولید پاسخ تفکیک کرده و معیارهایی مثل ارتباط محتوا، پوشش‌دهی، صحت، جامعیت و وفاداری به متن را جداگانه می‌سنجد.

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

درس بزرگی که شرکت Ring از برخورد RAG با داده‌های واقعی گرفت

سیستم پشتیبانی شرکت Ring نمونه‌ای بسیار جذاب و آموزنده در این زمینه است.

در یک مستند فنی که در مارس ۲۰۲۶ منتشر شد، شرکت AWS نحوه ساخت یک سیستم RAG چندزبانه و چندمنطقه‌ای را برای پشتیبانی مشتریان Ring در ۱۰ کشور مختلف شرح داد. چالش اصلی تنها ترجمه کردن متون نبود، بلکه تنظیمات محصولات، الزامات و رویه‌های پشتیبانی در هر منطقه با مناطق دیگر کاملاً تفاوت داشت.

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

نکته مهم این ماجرا، فهرست ابزارهای آمازون نیست؛

بلکه نبوغ نهفته در معماری آن است.

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

امنیت داده شوخی‌بردار نیست

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

کارمندی را در نظر بگیرید که درباره قرارداد محرمانه یک مشتری سوال می‌پرسد. سیستم سند درست را پیدا کرده و با خیال راحت تحویل مدل زبانی می‌دهد.

از زاویه دید بازیابی اطلاعات، این یک پیروزی بزرگ است؛

اما از منظر امنیت سایبری و داده، این اتفاق یک فاجعه امنیتی تمام‌عیار به شمار می‌رود.

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

• هویت و مجوز کاربر باید قبل از ورود اطلاعات محرمانه به ورودی مدل بررسی شود.

• قوانین دسترسی باید همگام با هر درخواست جستجو جابه‌جا شوند.

• قابلیت ثبت ردپا و حسابرسی (Auditability) در فرآیندهایی که شامل چندین واکشی متوالی توسط ایجنت‌ها هستند حیاتی است.

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

تازگی اطلاعات، چالشی از جنس عملیات و نگهداری است

دانش درون شرکت‌ها مدام در حال دگرگونی است.

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

اگر نمایه (Index) پایگاه دانش بلافاصله به‌روز نشود، یک مدل زبانی می‌تواند با کمال خونسردی و اعتمادبه‌نفس جوابی تحویل کاربر دهد که هفته گذشته کاملاً درست بوده اما امروز سراسر غلط است.

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

• کدام منابع به به‌روزرسانی آنی و لحظه‌ای نیاز دارند؟

• تغییرات با چه سرعتی به شاخص جستجو می‌رسند؟

• وقتی یک سند مرجع و رسمی حذف می‌شود، چه اتفاقی برای سیستم می‌افتد؟

• نسخه‌های قدیمی فایل‌ها چطور مدیریت و آرشیو می‌شوند؟

• آیا مهندسان می‌توانند ردگیری کنند دقیقاً کدام نسخه از سند روی پاسخ مدل اثر گذاشته است؟

شاید این موارد بیشتر شبیه وظایف تیم‌های عملیاتی و داده به نظر برسند، اما تأثیر مستقیمی بر درستی و کیفیت کل سیستم هوش مصنوعی دارند.

هزینه‌ها و تاخیر زمانی، قواعد بازی را عوض می‌کنند

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

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

محتوای بیشتر لزوماً به معنی محتوای مفیدتر نیست.

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

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

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

برای درک بهتر یک معماری بالغ RAG، می‌توان آن را به چند لایه پیوسته تقسیم کرد:

• لایه مبدا (Source Layer): ارتباط با سیستم‌های سازمانی و ردگیری اصالت و منشأ داده‌ها.

• لایه پردازش (Processing Layer): تمیزکاری، اعتبارسنجی و تبدیل ساختار فایل‌های ورودی.

• لایه شاخص‌گذاری (Indexing Layer): آماده‌سازی ساختارها و بردارها برای جستجوی سریع.

• لایه بازیابی (Retrieval Layer): تلفیق سیگنال‌های معنایی، کلیدواژه‌ای و فیلترهای تخصصی.

• لایه سیاست‌گذاری (Policy Layer): بررسی احراز هویت و دسترسی‌ها قبل از رسیدن داده به مدل.

• لایه ارزیابی (Evaluation Layer): سنجش مجزای کیفیت بازیابی و کیفیت تولید متن.

• لایه مشاهده‌پذیری (Observability Layer): ثبت لاگ‌ها و ردپاها برای شناسایی و رفع بی‌دردسر خطاها.

• لایه تولید (Generation Layer): تبدیل بسته‌های داده نهایی به پاسخ خوانا یا اقدامات مورد نیاز توسط ایجنت‌ها.

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

سوال کلیدی این است: مالکیت هر قطعه با چه کسی است و تیم توسعه چطور متوجه خرابی یا افت عملکرد آن می‌شود؟

سوال اصلی این نیست که آیا دوران RAG به سر آمده یا نه

با افزایش چشمگیر ظرفیت پردازش پنجره متنی مدل‌ها (Context Window)، خیلی‌ها این سوال را مطرح می‌کنند که آیا اصلاً هنوز به سیستم‌های RAG نیازی هست؟

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

پرسش اصولی این است: آیا سیستم ما می‌تواند همواره اطلاعات درست را، در زمان درست، به مدل مناسب و برای کاربر مجاز فراهم کند؟

گاهی اوقات راهکار این چالش همان RAG سنتی است.

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

این چالش داده‌هاست که باید معماری سیستم را شکل دهد، نه برعکس.

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

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

فناوری RAG هیچ‌وقت صرفاً درباره واکشی چند تکه متن نبوده است؛

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