RAG یا Fine-tuning؟ تصمیم را از نوع خطا شروع کنید، نه از نام فناوری

ابتدا بپرسید سامانه کجا اشتباه می‌کند

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

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

بازیابی و تنظیم دقیق کدام اهرم را تغییر می‌دهند؟

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

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

آزمون تشخیصی با زمینهٔ درست

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

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

برای ادامهٔ این بحث، مقالهٔ «چطور پاسخ هوش مصنوعی را به اسناد سازمان متصل کنیم؟» را در دانشنامهٔ لیان بخوانید.

اگر به تنظیم دقیق رسیدیم، دادهٔ مناسب چیست؟

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

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

ترکیب دو روش چه زمانی ارزش آزمون دارد؟

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

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

تازگی و دسترسی با آموزش مدل حل‌شده فرض نمی‌شوند

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

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

هزینهٔ کل را مقایسه کنید، نه فقط یک فراخوانی

برای آزمایش خرید، هزینهٔ گردآوری و برچسب‌گذاری داده، بازبینی متخصص، اجرای آزمون، آموزش، نمایه‌سازی و نگه‌داری نسخه‌ها را ثبت کنید. زمان پاسخ و هزینهٔ استفاده مهم‌اند، اما تنها صورت‌حساب سامانه نیستند. اگر تعریف یک شاخص هر ماه عوض می‌شود، هزینهٔ تکرار چرخهٔ ارزیابی هم بخشی از تصمیم است.

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

تصمیم فنی باید قابل بازبینی بماند

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

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