«جلوگیری از حذف استثنائات»، هدف جدید در بهینه‌سازی پرامپت‌های خلاصه‌ساز

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

بسیاری از کاربران با خلاصه‌سازی مانند یک درخواست تک‌مرحله‌ای برخورد می‌کنند. اما طبق راهنمای کاربردی منتشر شده در ۱۳ اکتبر ۲۰۲۶ در وب‌سایت dev.to، دستور «خلاصه کن» به مدل می‌گوید آنچه «معمول» و «تیپیکال» است را نگه دارد. در این فرآیند، جزئیات «حامل بار» — یعنی همان قوانین نادر و محدودیت‌های خاصی که اغلب بیشترین ریسک را به همراه دارند — به‌طور طبیعی دور ریخته می‌شوند. همان‌طور که در بحث‌های گذشته‌ی ما درباره‌ی دقت مدل‌های زبانی اشاره کردیم، مدل‌ها تمایل دارند الگوهای تکرارشونده را بر اولویت‌های استثنایی ترجیح دهند. این چالش با نقص‌های سیستماتیک در اعتبارسنجی خروجی‌های مدل همسو است که نشان می‌دهد مدل‌ها گاهی در بازتولید دقیق واقعیت‌ها دچار لغزش می‌شوند.

مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در هنگام فشرده‌سازی دچار یک تله می‌شود: اولویت دادن به کلیات بر جزئیات. در این حالت، قوانین اصلی باقی می‌مانند اما استثنائات که معمولاً در یک جمله و زیر عناوین کوچک دفن شده‌اند، به عنوان جزئیات زائد شناسایی می‌شوند.

بر اساس بررسی‌های dev.to، سه نوع محتوا بیشترین احتمال حذف خاموش را در هنگام فشرده‌سازی توسط هوش مصنوعی دارند:

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

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

ساختار این پرامپت به شرح زیر است:

۱. مرحله اول (نقشه‌برداری - Map): مدل باید تمام بخش‌ها یا موضوعات مجزا را به ترتیب و در هر مورد در یک خط فهرست کند. این کار مانع از آن می‌شود که مدل وانمود کند بخش‌های کوچک وجود ندارند یا نادیده گرفته شوند.
۲. مرحله دوم (خلاصه‌سازی - Summary): مدل خلاصه را (با یک محدودیت مشخص مثلاً [N] بالت) می‌نویسد. هر بالت باید صراحتاً نام بخشی را که از آن استخراج شده، ذکر کند تا منبع هر ادعا مشخص باشد.
۳. بررسی پوشش (Coverage Check): مدل هر موردی از مرحله اول (نقشه) را که در خلاصه نیامده، فهرست می‌کند. برای هر مورد، مدل باید یک حکم تک‌خطی صادر کند: آیا خواننده با ندانستن این مورد آسیب می‌بیند؟ (پاسخ بله/خیر + دلیل).

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

برای تأیید این ادعا، نویسنده مدل Claude Sonnet را با استفاده از PEP 8 (راهنمای استایل پایتون) آزمایش کرد. PEP 8 یک سند در مالکیت عمومی است که سرشار از قوانین و استثنائات است. در این آزمایش، یک درخواست ساده «خلاصه کن» (اجرای A) در مقابل پرامپت دو-مرحله‌ای با محدودیت ۸ بالت (اجرای B) قرار گرفت.

اجرای A خلاصه‌ای خوب و مفید ارائه داد که مواردی چون تورفتگی (indentation)، طول خط، خطوط خالی، ایمپورت‌ها، نام‌گذاری، docstringها، مقایسه‌ها با None و حاشیه‌نویسی‌ها (annotations) را پوشش می‌داد. با این حال، چهار نکته حیاتی را کاملاً حذف کرد:

• اجازه انحراف: PEP 8 تصریح می‌کند که سازگاری داخلی در یک پروژه مهم‌تر از سازگاری با این راهنماست و هشدار می‌دهد که نباید سازگاری با نسخه‌های قبلی (backwards compatibility) را فقط برای رعایت این راهنما به خطر انداخت. اجرای A این مورد را حذف کرد و باعث شد راهنما سخت‌گیرانه‌تر از آنچه هست به نظر برسد.
• استثنای تیمی: در حالی که اجرای A محدودیت ۷۹ کاراکتر برای طول خط را ذکر کرد، اما این نکته را حذف کرد که تیم‌ها می‌توانند روی ۹۹ کاراکتر توافق کنند (به شرطی که کامنت‌ها و docstringها همچنان در ۷۲ کاراکتر Wrap شوند).
• کاما در انتهای تیوپل‌های تک‌عضوی: در پایتون، کاماهای انتهایی اختیاری هستند مگر در تیوپل‌های تک‌عضوی. حذف این نکته یک «باگ بالقوه» است، زیرا بدون کاما، شما به جای یک تیوپل، یک رشته (string) دریافت می‌کنید.
• ترتیب Module Dunders: مدل جایگاه متغیرهای خاص ماژول مانند __all__ و این قانون که ایمپورت‌های from __future__ باید قبل از آن‌ها بیایند را نادیده گرفت.

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

• زمان استفاده از کاماهای انتهایی: بله (ریسک باگ‌های پنهان در تیوپل‌های تک‌عضوی).
• نام‌های Dunder در سطح ماژول: بله (قانون ترتیب __future__ می‌تواند باعث خطاهای واقعی شود).
• کدگذاری فایل منبع/سازگاری ASCII: خیر (بیشتر مربوط به مشارکت‌کنندگان کتابخانه استاندارد است).
• منابع/کپی‌رایت: خیر.

اجرای B همچنین فهرستی از «دمِ استثنائات» را ارائه داد که آن‌ها را فشرده کرده بود؛ مواردی مانند دو حالت خاص که در آن استفاده از except: خالی پذیرفتنی است، هشدار در مورد استفاده از return داخل بلوک finally و یادداشتی مبنی بر اینکه ویژگی‌های name-mangled همچنان قابل دسترسی هستند.

با این حال، این روش برای هر سندی یک راهکار جادویی نیست. سه محدودیت اصلی در آزمایش‌ها دیده شد:

• افزایش حجم خروجی: خروجی اجرای B چندین برابر بلندتر از A است. این یک سربار (overhead) است که فقط زمانی باید پذیرفته شود که اشتباه در مورد یک سند، برای شما هزینه واقعی داشته باشد.
• قضاوت‌های ذهنی: پاسخ به سؤال «آیا خواننده آسیب می‌بیند؟» یک قضاوت شخصی است. برای مثال، مدل کدگذاری فایل منبع را کم‌ریسک دانست که برای اکثر کاربران درست است اما برای توسعه‌دهندگان کتابخانه استاندارد پایتون غلط است.
• خطاهای خوانش: اگر مدل از ابزار وب-فچ (web-fetch) استفاده کند، ممکن است متنی بازنویسی‌شده (paraphrased) دریافت کند نه متن اصلی. در این صورت حتی اگر نقشه تمام ۴۲ عنوان بخش را لیست کند، نقشه‌ای که بر اساس بازنویسی ساخته شده باشد، باز هم می‌تواند یک خط حیاتی را از دست بدهد.

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

۱. ابتدا موارد «بله» را بخوانید: این‌ها همان جزئیات حیاتی هستند که خلاصه سعی در پنهان کردنشان داشت.
۲. یکی از موارد «خیر» را به‌صورت تصادفی چک کنید: یکی از بخش‌های حذف‌شده را در متن اصلی باز کنید. اگر مدل حتی یک بار در قضاوت خود اشتباه کرده باشد، تمام موارد حذف‌شده را دستی بخوانید.
۳. جست‌وجوی کلمات کلیدی: ده ثانیه وقت بگذارید و کلمات «except»، «must»، «never»، «unless» و هر عددی را در متن اصلی جست‌وجو کنید. این سریع‌ترین راه برای بررسی مستقل محدودیت‌هاست.
۴. ذخیره نقشه: لیست مرحله اول (نقشه) را به عنوان فهرست مطالب برای پرسش‌های آینده ذخیره کنید، زیرا این کار سریع‌تر از بازخوانی کل سند است.

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

برای گام بعدی شما:

• در اولین فرصت، پرامپت‌های خلاصه‌سازی خود را از حالت تک‌مرحله‌ای به ساختار «نقشه $\rightarrow$ خلاصه $\rightarrow$ بررسی پوشش» تغییر دهید.
• برای اسناد حساس (مانند قراردادها یا مستندات API)، هرگز به خلاصه تکیه نکنید و حتماً بخش «بررسی پوشش» را تحلیل کنید.
• کلمات کلیدی محدودکننده (مانند «باید» یا «به جز») را به عنوان فیلتر نهایی در متن اصلی جست‌وجو کنید.

اما داستان سخت‌افزاری این تحول و تأثیر حافظه مدل بر دقت استخراج جزئیات حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی پنجره‌های متنی گسترده مراجعه کنید.