تنظیم دقیق مدل، حجم پرامپت سیستمی را ۳۳ برابر کاهش داد

اگر امروز برای اصلاح هر خطای کوچک مدل خود، یک قانون جدید به پرامپت اضافه می‌کنید، احتمالاً در حال تخریب تدریجی کیفیت خروجی‌هایتان هستید. یک پرامپت سیستمی با ۲۲۴,۸۳۳ کاراکتر — یعنی حدود ۵۶,۰۰۰ توکن — به‌جای کمک به مدل، به یک مانع تبدیل شده بود.

به نقل از گزارشی در dev.to که در ۱۴ اوت ۲۰۲۶ منتشر شد، یک توسعه‌دهنده توضیح داد که چگونه چرخهٔ افزودن قوانین برای رفع خطاهای جزئی، در نهایت «صدای منحصربه‌فرد» مدل را کشت. نتیجه خروجی‌هایی بود که بیش از حد محتاط و تخت به نظر می‌رسیدند؛ شبیه متنی که یک کمیته برای دوری از اشتباه نوشته باشد، نه نویسنده‌ای که دیدگاه مشخصی دارد.

بسیاری از مهندسان پرامپت همین مسیر انباشت تدریجی را طی می‌کنند. وقتی مدل یک کلیشهٔ آزاردهنده تولید می‌کند، واکنش غریزی این است که خطی برای ممنوع کردن آن اضافه شود. این کار در کوتاه‌مدت پیشرفت به نظر می‌رسد، اما یک مالیات دائمی روی هر فراخوانی API ایجاد می‌کند. این توسعه‌دهنده طی ۶ ماه، توده‌ای از قوانین را جمع کرد که ۹۰٪ کل پرامپت را تشکیل می‌داد.

دسته‌های انباشتگی

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

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

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

برای جبران شکست پرامپت، توسعه‌دهنده هفت لایه اعتبارسنج بعد از تولید (Post-generation validators) اضافه کرد. این لایه‌ها در کد اجرا می‌شدند و پس از اتمام تولید توسط مدل، خروجی را بررسی می‌کردند. این پشته شامل موارد زیر بود:

• Regex برای شناسایی و شکار ساختارهای جملات ممنوعه.
• ابزاری برای حذف عادت‌های خاص در نقطه‌گذاری.
• یک مرحله رد کردن (Rejection pass) برای خروجی‌هایی که صرفاً ورودی را بازنویسی یا تکرار می‌کردند.
• لیست سیاه واژگان برای مسدود کردن کلمات خاص.
• مکانیزم جایگزین (Fallback) برای زمانی که تمام بررسی‌های دیگر خروجی را رد می‌کردند.

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

مکانیسم تورم پرامپت

طبق گزارش dev.to، مشکل اصلی این است که مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — با پرامپت‌ها مانند فایل‌های تنظیمات (Config) برخورد نمی‌کند که هر خط به‌طور مستقل اجرا شود. در عوض، مدل به کل زمینه به‌طور هم‌زمان توجه می‌کند. وقتی پرامپت شامل ۲۰۰ خط ممنوعیت و فقط دو خط توصیف تکلیف است، مدل روی قوی‌ترین سیگنال بهینه می‌شود: «دوری از شکستن قوانین».

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

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

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

چرخش به سمت تنظیم دقیق

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

قوانین مانند داربست‌هایی شده بودند که اگر برداشته می‌شدند، لحن مدل فرو می‌ریخت، اما نگه داشتن آن‌ها فضای تکلیف اصلی را می‌گرفت. راهکار، انتقال «هویت» لحن به وزن‌های مدل از طریق تنظیم دقیق (Fine-tuning) بود — مثل وقتی به یک پزشک عمومی، تخصص پوست می‌دهیم؛ مدل کلی است، اما روی یک حوزه دقیق می‌شود.

تفاوت مقیاس خیره‌کننده بود:

• رویکرد مهندسی پرامپت: ۲۲۴,۸۳۳ کاراکتر (حدود ۵۶,۰۰۰ توکن در هر فراخوانی).
• رویکرد تنظیم دقیق: ۶,۸۰۵ کاراکتر (حدود ۱,۷۰۰ توکن در هر فراخوانی).

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

بازتعریف پشته هوش مصنوعی

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

۱. تنظیم دقیق مالک هویت است: شامل لحن، سبک ثابت یا روش استدلالی که باید در هر بار اجرا برقرار باشد.
۲. تولید بازیابی‌افزا (RAG) مالک دانش است: حقایقی که مدل باید بداند اما نمی‌توان انتظار داشت درونی کرده باشد، باید در لایه بازیابی باشند، نه در پرامپت.
۳. پرامپت مالک دستور است: برای تعیین موضوع فعلی، طول متن و حالت خاص.

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

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

گام بعدی شما

• پرامپت‌های تولیدی خود را در حالت نهایی (بعد از جایگذاری متغیرها) تحلیل کنید و درصد قوانین «هویتی» را در برابر دستورات «تکلیفی» بسنجید.
• اگر بیش از ۲۰٪ پرامپت شما صرف ممنوع کردن کلمات یا تعیین لحن است، به جای افزودن قانون، یک مجموعه داده کوچک (۵۰ تا ۱۰۰ نمونه) برای تنظیم دقیق آماده کنید.
• هر قانون جدید را پیش از افزودن، در سه دسته «هویت»، «دانش» یا «دستور» طبقه‌بندی کنید تا متوجه شوید کجا در حال ایجاد انباشتگی هستید.

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