وقتی از یک مدل هوش مصنوعی درباره اطلاعات اختصاصی یک سازمان، کتابخانه اسناد یا مجموعه فایل‌های شخصی سؤال می‌کنیم، مدل لزوماً به آن اطلاعات دسترسی ندارد. وارد کردن چند صفحه متن در هر گفت‌وگو نیز برای مجموعه‌های بزرگ، روشی پایدار و قابل نگهداری نیست. راهکار RAG یا بازیابی افزوده با تولید، به سامانه اجازه می‌دهد پیش از تولید پاسخ، بخش‌های مرتبط را از یک مخزن اطلاعاتی بازیابی کند و آن‌ها را در اختیار مدل بگذارد. نتیجه مطلوب، چت‌باتی نیست که صرفاً روان حرف بزند؛ سامانه‌ای است که پاسخ را تا حد امکان به شواهد موجود متصل کند، منبع را نشان دهد و در نبود شواهد کافی از حدس زدن خودداری کند. این مقاله مسیر طراحی چنین سامانه‌ای را از داده خام تا ارزیابی و نگهداری توضیح می‌دهد.
RAG دقیقاً چه مسئله‌ای را حل می‌کند؟
مدل زبانی عمومی از الگوهای آموخته‌شده در زمان آموزش برای تولید متن استفاده می‌کند. این دانش ممکن است قدیمی، ناقص یا نامرتبط با فایل‌های خصوصی شما باشد. در RAG، پرسش کاربر ابتدا به یک مرحله جست‌وجو فرستاده می‌شود. سامانه بخش‌هایی از اسناد را که از نظر معنایی یا واژگانی مرتبط‌اند پیدا می‌کند، سپس پرسش و شواهد بازیابی‌شده را به مدل می‌دهد تا پاسخ را بر اساس همان اطلاعات بسازد. این روش برای راهنمای داخلی نرم‌افزار، جست‌وجو در دستورالعمل‌ها، پاسخ‌گویی به پرسش‌های فنی از مستندات و مرور مجموعه‌ای از مقاله‌ها مفید است. RAG به معنی آموزش دوباره مدل نیست و به خودی خود صحت پاسخ را تضمین نمی‌کند؛ کیفیت بازیابی و کیفیت منبع همچنان تعیین‌کننده‌اند.
معماری ساده یک سامانه RAG
معماری پایه پنج بخش دارد: دریافت اسناد، آماده‌سازی و قطعه‌بندی متن، تبدیل قطعه‌ها به نمایش برداری، بازیابی قطعه‌های مرتبط و تولید پاسخ با مدل زبانی. در مرحله دریافت، فایل‌ها از پوشه، سامانه مدیریت محتوا یا پایگاه داده خوانده می‌شوند. در مرحله آماده‌سازی، متن استخراج و پاک‌سازی می‌شود و اطلاعاتی مانند نام فایل، شماره صفحه، تاریخ و سطح دسترسی حفظ می‌شود. سپس هر قطعه به embedding تبدیل و در پایگاه برداری ذخیره می‌شود. هنگام پرسش، متن پرسش نیز به بردار تبدیل می‌شود و نزدیک‌ترین قطعه‌ها بازیابی می‌شوند. در نهایت مدل با دستورالعملی روشن پاسخ می‌دهد و در صورت امکان ارجاع به سند و صفحه را برمی‌گرداند. هر کدام از این مراحل می‌تواند منشأ خطا باشد؛ بنابراین باید جداگانه قابل مشاهده و آزمون باشد.
پیش از ورود فایل‌ها، کیفیت منبع را بررسی کنید
انباشت فایل‌های نامرتب، سامانه هوشمند نمی‌سازد. ابتدا فهرست منابع را تهیه کنید و نسخه‌های تکراری، فایل‌های منسوخ و اسناد بدون مالک مشخص را جدا کنید. اگر دو نسخه از یک دستورالعمل وجود دارد، تاریخ اعتبار و نسخه رسمی را مشخص کنید. PDF اسکن‌شده ممکن است به OCR نیاز داشته باشد و خطای تشخیص حروف فارسی می‌تواند معنای جمله را عوض کند. جدول‌ها، پاورقی‌ها و سربرگ‌ها نیز در استخراج متن ممکن است جابه‌جا شوند. برای هر سند حداقل عنوان، شناسه، تاریخ، نسخه، مالک و سطح دسترسی را ثبت کنید. بهتر است قبل از پردازش انبوه، نمونه‌ای از هر نوع فایل را بررسی کنید و کیفیت استخراج را با متن اصلی مقایسه کنید. داده نامعتبر در مرحله بازیابی به پاسخ نامعتبر تبدیل می‌شود.
قطعه‌بندی یا Chunking را بر اساس ساختار متن انجام دهید
مدل بازیابی معمولاً تمام یک کتاب یا راهنمای طولانی را یکجا به عنوان نتیجه مناسب برنمی‌گرداند. متن باید به قطعه‌هایی تقسیم شود که هر کدام معنای نسبتاً مستقلی داشته باشند. قطعه بسیار کوچک ممکن است شرط یا توضیح لازم را از متن جدا کند؛ قطعه بسیار بزرگ نیز موضوعات متعددی را در یک واحد مخلوط می‌کند و بازیابی را کم‌دقت‌تر می‌سازد. برای اسناد ساختاریافته، تقسیم بر اساس عنوان، بند و بخش معمولاً بهتر از بریدن متن در تعداد ثابتی از نویسه‌هاست. هم‌پوشانی محدود میان قطعه‌ها می‌تواند از قطع شدن جمله یا ارجاع جلوگیری کند، اما هم‌پوشانی بیش از حد نتایج تکراری تولید می‌کند. اندازه مناسب را با مجموعه‌ای از پرسش‌های واقعی آزمایش کنید، نه با یک عدد ثابت که برای همه اسناد به کار رود.
فراداده، دسترسی و نسخه سند را همراه متن نگه دارید
هر قطعه باید به سند مادر و موقعیت خود متصل بماند. اگر قطعه‌ای از صفحه ۲۳ یک راهنما آمده، سامانه باید بتواند همان صفحه را به کاربر نشان دهد. فراداده برای فیلتر کردن نتایج نیز مهم است؛ مثلاً می‌توان جست‌وجو را به اسناد یک پروژه، زبان یا بازه زمانی محدود کرد. سطح دسترسی باید پیش از بازیابی اعمال شود، نه پس از آن. اگر کاربر مجاز به دیدن یک سند نیست، قطعه آن نباید وارد زمینه مدل شود؛ حذف نام سند از پاسخ کافی نیست، چون متن محرمانه ممکن است در خود پاسخ ظاهر شود. هنگام جایگزینی نسخه سند نیز باید قطعه‌های قدیمی غیرفعال یا حذف شوند تا پاسخ‌ها از نسخه‌های متناقض ساخته نشوند.
Embedding و پایگاه برداری را درست انتخاب کنید
Embedding متن را به برداری عددی تبدیل می‌کند تا شباهت معنایی میان پرسش و قطعه‌ها محاسبه شود. انتخاب مدل embedding باید با زبان، نوع متن و محدودیت‌های استقرار هماهنگ باشد. برای مجموعه فارسی، نمونه‌های واقعی شامل اصطلاحات تخصصی، املای متفاوت و ترکیب فارسی و انگلیسی را آزمایش کنید. پایگاه برداری نیز باید از فیلتر فراداده، حذف یا به‌روزرسانی رکورد، پشتیبان‌گیری و رشد داده پشتیبانی کند. اگر حجم داده کم است، شاید یک موتور جست‌وجوی ترکیبی یا حتی جست‌وجوی متنی ساده برای شروع کافی باشد. پیچیده کردن زیرساخت پیش از اثبات نیاز، هزینه نگهداری را بالا می‌برد. انتخاب را بر اساس کیفیت بازیابی، زمان پاسخ، هزینه و توان تیم برای نگهداری انجام دهید.
بازیابی ترکیبی و بازرتبه‌بندی
جست‌وجوی معنایی برای پرسش‌هایی که واژه‌های متفاوت اما مفهوم مشابه دارند مفید است، اما ممکن است در شناسه‌ها، کد خطاها و نام دقیق قابلیت‌ها ضعیف عمل کند. جست‌وجوی واژگانی در این موارد می‌تواند دقیق‌تر باشد. بازیابی ترکیبی نتایج دو روش را ادغام می‌کند تا هم مفهوم و هم عبارت دقیق در نظر گرفته شود. پس از بازیابی اولیه، یک مدل بازرتبه‌بندی می‌تواند قطعه‌ها را بر اساس ارتباط با پرسش دوباره مرتب کند. با این حال هر مرحله تأخیر و هزینه ایجاد می‌کند. ابتدا یک خط پایه ساده بسازید، سپس با مجموعه آزمون مشخص کنید آیا ترکیب روش‌ها واقعاً کیفیت را بهتر کرده است یا خیر. افزایش تعداد قطعه‌های بازیابی‌شده همیشه پاسخ بهتر نمی‌سازد؛ زمینه بیش از حد می‌تواند مدل را سردرگم کند.
دستورالعمل تولید پاسخ و ارجاع به منبع
در پیام سیستمی مدل، نقش و محدودیت آن را روشن کنید. به مدل بگویید فقط بر اساس شواهد ارائه‌شده پاسخ دهد، میان واقعیت منبع و برداشت خود تفاوت بگذارد و اگر شواهد کافی نیست صریحاً اعلام کند. قالب ارجاع را مشخص کنید؛ مثلاً عنوان سند و شماره صفحه یا پیوند مستقیم به فایل. از مدل بخواهید برای هر ادعای مهم مشخص کند کدام قطعه آن را پشتیبانی می‌کند. با این حال ارجاعی که مدل تولید می‌کند ممکن است نادرست باشد؛ شناسه سند و صفحه را باید از فراداده واقعی سامانه بسازید یا اعتبارسنجی کنید. بهتر است پاسخ به چند بخش تقسیم شود: نتیجه کوتاه، توضیح مستند و منابع استفاده‌شده. این ساختار بررسی پاسخ را آسان‌تر می‌کند.
مجموعه آزمون واقعی بسازید
پیش از عرضه، پرسش‌های واقعی کاربران را گردآوری کنید و برای هر پرسش پاسخ مرجع یا معیار پذیرش تعریف کنید. مجموعه آزمون باید فقط شامل سؤال‌های ساده و مستقیم نباشد. پرسش مبهم، پرسش چندبخشی، سؤال با غلط املایی، اصطلاح انگلیسی، سؤال بدون پاسخ در اسناد و سؤال درباره نسخه قدیمی را نیز اضافه کنید. کیفیت بازیابی را جدا از کیفیت تولید پاسخ بسنجید. آیا قطعه درست در میان نتایج اولیه وجود دارد؟ آیا مدل از همان قطعه استفاده کرده؟ آیا پاسخ تمام بخش‌های پرسش را پوشش می‌دهد؟ آیا ارجاع قابل باز شدن است؟ ثبت خطاها در سطح مرحله کمک می‌کند بفهمید مشکل از OCR، قطعه‌بندی، جست‌وجو یا دستورالعمل مدل است.
امنیت و محرمانگی را در کل مسیر رعایت کنید
اسناد داخلی ممکن است شامل اطلاعات شخصی، قرارداد، داده مالی یا رمزهای دسترسی باشند. پیش از ارسال داده به سرویس بیرونی، سیاست نگهداری و استفاده از داده ارائه‌دهنده را بررسی کنید و فقط داده‌ای را پردازش کنید که مجوز آن را دارید. دسترسی به مخزن، لاگ پرسش‌ها و خروجی‌ها باید محدود و قابل ممیزی باشد. ورودی سند نیز می‌تواند حاوی دستور مخرب باشد؛ متن سند را داده غیرقابل اعتماد تلقی کنید و اجازه ندهید محتوای بازیابی‌شده دستورهای سطح سیستم را تغییر دهد. برای فایل‌های حساس، فیلتر دسترسی در مرحله بازیابی، رمزنگاری در انتقال و ذخیره و سیاست حذف داده ضروری است. آزمون نفوذ و بررسی نشت اطلاعات باید پیش از گسترش دامنه انجام شود.
پایش، به‌روزرسانی و هزینه عملیاتی
پس از راه‌اندازی، کیفیت سامانه ثابت نمی‌ماند. اسناد جدید وارد می‌شوند، نسخه‌ها تغییر می‌کنند، پرسش کاربران عوض می‌شود و مدل‌ها یا تنظیمات ممکن است به‌روزرسانی شوند. نرخ پاسخ بدون منبع، پرسش‌های بی‌پاسخ، زمان پاسخ، هزینه هر درخواست و رضایت کاربران را پایش کنید. نمونه‌ای از مکالمات را با رعایت حریم خصوصی بازبینی کنید و خطاهای تکراری را به مجموعه آزمون اضافه کنید. برای اسناد تغییرپذیر، زمان آخرین به‌روزرسانی و مالک سند را ثبت کنید. هزینه فقط قیمت مدل نیست؛ استخراج متن، embedding، پایگاه داده، ذخیره فایل، بازرتبه‌بندی و نیروی نگهداری نیز در محاسبه قرار می‌گیرند. یک سامانه کوچک و قابل سنجش بهتر از معماری بزرگ و بدون معیار موفقیت است.
نقشه اجرای یک نمونه اولیه
برای شروع، یک مجموعه محدود از اسناد کم‌ریسک و معتبر انتخاب کنید. ده تا بیست پرسش پرتکرار را به عنوان آزمون بنویسید و پاسخ مرجع یا منبع مورد انتظار را ثبت کنید. سپس متن‌ها را استخراج، پاک‌سازی و قطعه‌بندی کنید؛ شناسه سند و شماره صفحه را حفظ کنید. یک روش embedding و جست‌وجوی ساده راه‌اندازی کنید و نتایج را دستی ارزیابی کنید. پس از رسیدن به کیفیت قابل قبول، تولید پاسخ و ارجاع را اضافه کنید. در مرحله بعد، فیلتر دسترسی، ثبت خطا و پایش هزینه را پیاده کنید. تا زمانی که سامانه در پرسش‌های بدون پاسخ، نسخه‌های متناقض و درخواست‌های خارج از محدوده رفتار قابل پیش‌بینی ندارد، آن را به کل مخزن وصل نکنید.
خطاهای رایج در پروژه‌های RAG
رایج‌ترین خطا این است که کیفیت مدل را مقصر بدانیم، در حالی که سند استخراج نشده یا قطعه درست بازیابی نشده است. خطای دیگر، بارگذاری همه فایل‌ها بدون پاک‌سازی و کنترل نسخه است. گاهی سامانه پاسخ را با لحنی قطعی می‌سازد اما هیچ شاهدی ندارد؛ باید امکان امتناع از پاسخ طراحی شود. همچنین نباید تمام اسناد را برای همه کاربران قابل جست‌وجو کرد. افزایش تعداد نتایج، طول prompt و پیچیدگی مدل بدون اندازه‌گیری نیز می‌تواند هزینه را بالا ببرد. هر تغییر مهم در مدل، قطعه‌بندی یا بازیابی باید دوباره روی مجموعه آزمون اجرا شود تا افت کیفیت پنهان نماند.
جمع‌بندی
RAG راهی برای پیوند دادن پاسخ مدل زبانی با اسناد مشخص است، اما کیفیت آن به مجموعه‌ای از تصمیم‌های مهندسی وابسته است: انتخاب منبع معتبر، استخراج دقیق، قطعه‌بندی معنادار، حفظ فراداده، بازیابی مناسب، ارجاع قابل بررسی و ارزیابی مستمر. با یک نمونه کوچک و آزمون واقعی شروع کنید و فقط وقتی کیفیت، امنیت و هزینه قابل قبول شد دامنه را گسترش دهید. برای آشنایی با کاربردهای عمومی‌تر، مقاله کاربرد هوش مصنوعی مولد در کار روزانه و راهنمای طراحی گردش کار تولید و بازبینی محتوا با هوش مصنوعی را نیز ببینید.
پرسش‌های متداول
آیا RAG باعث می‌شود مدل دیگر خطا نکند؟
خیر. RAG احتمال پاسخ مستند را افزایش می‌دهد، اما ممکن است سند اشتباه بازیابی شود، متن استخراج‌شده ناقص باشد یا مدل شواهد را نادرست تفسیر کند. ارزیابی و نمایش منبع همچنان ضروری است.
آیا برای RAG حتماً به پایگاه برداری نیاز دارم؟
نه همیشه. برای مجموعه کوچک می‌توان با جست‌وجوی متنی یا ترکیبی شروع کرد. پایگاه برداری زمانی ارزش دارد که جست‌وجوی معنایی، مقیاس یا فیلترهای پیشرفته نیاز واقعی باشند.
آیا می‌توان اسناد محرمانه را به هر مدل آنلاین فرستاد؟
خیر. پیش از استفاده باید سیاست پردازش و نگهداری داده، مجوز سازمان و سطح حساسیت اسناد بررسی شود. در صورت نیاز از استقرار کنترل‌شده یا داده ناشناس استفاده کنید.
منابع برای مطالعه بیشتر
- مرکز منابع هوش مصنوعی NIST؛ چارچوب‌ها و منابع ارزیابی و مدیریت ریسک هوش مصنوعی.
- چارچوب مدیریت ریسک هوش مصنوعی NIST.
