RAG یا فاین‌تیونینگ: نیاز واقعی کسب‌وکارها

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

چهار ابزار موجود در جعبه‌ابزار#

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

تولید تقویت‌شده با بازیابی (RAG)#

RAG مدل را دست‌نخورده می‌گذارد. در عوض، وقتی سؤالی می‌رسد، سیستم ابتدا در محتوای خود شما — مانند راهنماها، قراردادها، تیکت‌ها یا کاتالوگ محصول — جست‌وجو می‌کند و مرتبط‌ترین قطعات را همراه سؤال به مدل می‌دهد. سپس مدل بر اساس همان قطعات پاسخ می‌دهد.

سه ایده اینجا مهم‌اند:

• بازیابی (Retrieval): یافتن قطعات درست. این معمولاً ترکیبی از جست‌وجوی معنایی روی embeddingها و جست‌وجوی کلاسیک کلیدواژه‌ای است که اغلب با یک مرحله ری‌رنکینگ دنبال می‌شود.
• گراندینگ (Grounding): دستور دادن به مدل که از مطالب ارائه‌شده پاسخ دهد و وقتی مطالب حاوی پاسخ نیستند، این را بگوید.
• استنادها (Citations): اشاره به دقیقاً همان سند، صفحه یا قطعه‌ای که پاسخ از آن آمده، تا یک انسان بتواند آن را بررسی کند.

RAG وقتی می‌درخشد که دانش مرتب تغییر می‌کند، پیکره بزرگ است و مردم نیاز دارند پاسخ‌ها را راستی‌آزمایی کنند.

فاین‌تیونینگ#

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

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

پرامپتینگ با کانتکست طولانی و کش پرامپت#

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

اعتراض بدیهی هزینه و تأخیر است: فرستادن همان سند بزرگ با هر درخواست اسراف است. کش پرامپت این را حل می‌کند. ارائه‌دهندگان می‌توانند یک پیشوند پایدار از پرامپت را کش کنند تا درخواست‌های تکراری از محتوای ازپیش‌پردازش‌شده استفاده کنند و کارآمدتر محاسبه و سرو شوند. برای یک بدنه دانش پایدار و محدود، کانتکست طولانی با کش اغلب ساده‌ترین چیزی است که کار می‌کند.

خروجی‌های ساخت‌یافته#

بسیاری از پروژه‌های «هوش مصنوعی» در واقع پروژه‌های استخراج‌اند: یک فاکتور، رزومه، قرارداد یا ایمیل را بخوان و فیلدهای تمیز تولید کن. اینجا قابلیت کلیدی خروجی‌های ساخت‌یافته است، جایی که مدل مجبور می‌شود داده‌ای برگرداند که با اسکیمای تعریف‌شده توسط شما مطابقت دارد، مثلاً JSON با فیلدها و تایپ‌های مشخص. این اصلاً درباره دانش نیست؛ درباره قابلیت‌اطمینان قالب است و معمولاً نیاز به فاین‌تیونینگ را در کارهای استخراج از بین می‌برد.

هر رویکرد چه زمانی مناسب است#

یک راه مفید برای فکر کردن به این موضوع: دانش را از رفتار جدا کنید.

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

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

مقایسه کنار هم#

چک‌لیست تصمیم‌گیری عملی#

پیش از انتخاب معماری، به این سؤالات صادقانه پاسخ دهید:

1. کار دقیقاً چیست؟ پاسخ به سؤالات، پیش‌نویس متن، طبقه‌بندی یا استخراج؟ پنج مثال واقعی از ورودی و خروجی ایده‌آل بنویسید.
2. دانش زیربنایی هر چند وقت تغییر می‌کند؟ تغییرات روزانه یا هفتگی به‌قوت از فاین‌تیونینگ دور می‌شود.
3. آیا کاربران نیاز به راستی‌آزمایی پاسخ‌ها دارند؟ در زمینه‌های حقوقی، مالی، انطباق، پشتیبانی یا سلامت، استناد معمولاً غیرقابل‌مذاکره است.
4. پایگاه دانش چقدر بزرگ است؟ اگر به‌راحتی در یک پنجره کانتکست جا می‌شود، اول کانتکست طولانی با کش را امتحان کنید.
5. چه کسی اجازه دیدن چه چیزی را دارد؟ اگر کاربران مختلف به اسناد مختلف دسترسی دارند، به بازیابی با فیلتر مجوزها نیاز دارید، نه یک پرامپت مشترک واحد یا مدلی که روی همه‌چیز آموزش دیده.
6. چه حجم و تأخیری انتظار دارید؟ حجم بالا روی یک کار محدود جایی است که مدل‌های کوچک‌تر یا فاین‌تیون‌شده به حسابشان می‌آیند.
7. آیا نمونه‌های برچسب‌خورده دارید؟ فاین‌تیونینگ بدون مجموعه قابل‌توجهی از نمونه‌های خوب، به‌ندرت از یک پرامپت خوش‌نویس بهتر عمل می‌کند.
8. موفقیت را چگونه اندازه می‌گیرید؟ اگر نمی‌توانید به این پاسخ دهید، توقف کنید و اول یک مجموعه ارزیابی بسازید.

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

دام‌های رایج#

این‌ها مشکلاتی هستند که بیشتر هنگام بازبینی سیستم‌های هوش مصنوعیِ «تقریباً کار می‌کنند» می‌بینیم.

• چانکینگ بد. تقسیم اسناد به قطعات با اندازه ثابت و دلخواه، جدول‌ها را نصف می‌کند، سرفصل‌ها را از محتوایشان جدا می‌کند و کانتکست را از دست می‌دهد. در امتداد ساختار سند چانک کنید و متادیتای مفیدی مانند عنوان، بخش و تاریخ را نگه دارید.
• بدون ارزیابی. بدون یک مجموعه تست، هر تغییر حدس است. تیم‌ها پرامپت‌ها را تغییر می‌دهند، مدل‌ها را عوض می‌کنند و اندازه چانک‌ها را تغییر می‌دهند بدون این‌که بدانند وضع بهتر شده یا بدتر.
• ایندکس‌های کهنه. اسناد منبع به‌روزرسانی شدند، ایندکس نه. دستیار با اطمینان سیاست پارسال را نقل می‌کند. ری‌ایندکس کردن باید بخشی از گردش‌کار محتوا باشد، نه کاری دستی که از قلم می‌افتد.
• توهم بدون استناد. اگر سیستم نشان ندهد پاسخ از کجا آمده، کاربران نمی‌توانند پاسخ گراندشده را از ساخته‌شده تشخیص دهند. استناد را الزامی کنید و به مدل بیاموزید که وقتی منابع خاموش‌اند بگوید «نمی‌دانم».
• حریم خصوصی و GDPR. داده شخصی در اسناد، پرامپت‌ها و لاگ‌ها هنوز داده شخصی است. بدانید کدام ارائه‌دهنده آن را پردازش می‌کند، در کدام منطقه، تحت کدام قرارداد پردازش داده، و لاگ‌ها چه‌مدت نگه‌داری می‌شوند. فاین‌تیونینگ روی داده شخصی احتیاط بیشتری می‌خواهد، چون حذفش بعداً دشوار است.
• تزریق پرامپت از داخل اسناد. محتوای بازیابی‌شده ورودی نامعتمد است. یک سند می‌تواند متنی داشته باشد که سعی می‌کند به مدل دستور دهد — مثلاً قوانینش را نادیده بگیرد یا داده‌های دیگر را فاش کند. متن بازیابی‌شده را داده تلقی کنید، کاری را که مدل با ابزارها می‌تواند انجام دهد محدود کنید و هرگز نگذارید محتوای سند مجوز اعطا کند.

پیش از بهینه‌سازی، ارزیابی کنید#

ارزشمندترین قدم در هر پروژه هوش مصنوعی کمترین زرق‌وبرق را هم دارد: پیش از انتخاب معماری، یک مجموعه ارزیابی بسازید.

یک نقطه شروع خوب صرفاً چند ده تا چند صد سؤال یا ورودی واقعی است که هر کدام پاسخ موردانتظار یا اسنادی که باید استناد شوند را دارند. سپس اندازه بگیرید:

• کیفیت بازیابی: آیا سیستم قطعات درست را پیدا کرد؟
• کیفیت پاسخ: آیا پاسخ درست، کامل و مستند به منابع است؟
• دقت استناد: آیا قطعات استنادشده واقعاً ادعا را تأیید می‌کنند؟
• رفتار امتناع: آیا وقتی باید، «نمی‌دانم» می‌گوید؟
• انطباق قالب: برای استخراج، آیا هر خروجی با اسکیما مطابق است؟

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

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

دموهای خودمان این الگوها را چگونه نشان می‌دهند#

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

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

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

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

نسخه کوتاه#

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

اگر این گزینه‌ها را برای یک پروژه واقعی می‌سنجید، تیم هوش مصنوعی و اتوماسیون ما، تحت رهبری یک تک‌لید با بیش از ۲۰ سال تجربه، می‌تواند در تعیین اسکوپ، ساخت مجموعه ارزیابی و عرضه اولین نسخه‌ای که واقعاً قابل‌اندازه‌گیری است کمک کند. با ما در تماس شوید و بگویید چه مسئله‌ای را می‌خواهید حل کنید.