قسمت ۴ — اعتبارسنجی خروجی و بازتولید خودکار

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

۱. چرا خروجی درست‌نما کافی نیست

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

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

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

۲. قاعده را به شرط دودویی تبدیل کن

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

سه ویژگی یک شرط خوب: عددی باشد، قابل مشاهده در خودِ متن باشد، و مستقل از بقیهٔ شرط‌ها بررسی شود. نمونهٔ تبدیل:

• به‌جای «فهرست کوتاه باشد» — «فهرست دقیقاً پنج مورد دارد» و «هیچ موردی بیش از بیست کلمه نیست».
• به‌جای «همهٔ فیلدها پر شوند» — «هر مورد هر چهار کلید عنوان، نوع، مخاطب و اقدام را دارد» و «هیچ کلیدی مقدار خالی ندارد؛ در نبود داده مقدار برابر ندارد است».
• به‌جای «متن اضافه ننویس» — «متن با نخستین کاراکتر ساختار شروع می‌شود» و «پس از پایان ساختار هیچ جمله‌ای وجود ندارد».

وقتی این تبدیل را انجام دادی، به‌جای یک خواستهٔ مبهم، چک‌لیستی داری که هم مدل می‌تواند رویش راه برود و هم خودت در ده ثانیه با آن خروجی را کنترل می‌کنی.

۳. بازرسی را کجا بگذاریم

سه جا می‌شود خروجی را سنجید و انتخاب بین آن‌ها به اهمیت کار بستگی دارد:

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

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

۴. الگوی سه‌مرحله‌ای: تولید، سنجش، اصلاح

مؤثرترین ساختار برای خودبررسی، سه مرحلهٔ صریح در یک پرامپت است که ترتیبشان اهمیت دارد. مدل نباید بداند مرحلهٔ سوم چیست تا وقتی مرحلهٔ دوم را انجام نداده. این پرامپت را می‌توانی مستقیم کپی کنی:

وظیفهٔ تو سه مرحله دارد. هر سه را انجام بده اما فقط خروجی مرحلهٔ سوم را نمایش بده.

مرحلهٔ یک — تولید:
[خواستهٔ اصلی خود را اینجا بنویس، همراه با قالب و بودجهٔ طول]

مرحلهٔ دو — سنجش:
متنی را که در مرحلهٔ یک ساختی، در برابر هر شرط زیر جداگانه بررسی کن
و برای هرکدام فقط قبول یا رد تعیین کن:
۱) تعداد موردها دقیقاً پنج است.
۲) هر مورد هر چهار کلید عنوان، نوع، مخاطب و اقدام را دارد.
۳) هیچ کلیدی مقدار خالی ندارد؛ در نبود داده مقدار برابر «ندارد» است.
۴) هیچ موردی بیش از بیست کلمه نیست.
۵) پیش و پس از ساختار هیچ جمله‌ای وجود ندارد.

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

هیچ توضیحی دربارهٔ این سه مرحله ننویس و نتیجهٔ سنجش را نمایش نده.

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

۵. حلقهٔ بازتولید و نقطهٔ توقف

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

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

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

۶. گزارش تخطی برای اصلاح خود پرامپت

وقتی یک شرط مرتب رد می‌شود، مشکل معمولاً از مدل نیست؛ از خود پرامپت است. برای همین ارزش دارد گاهی به‌عمد بخواهی نتیجهٔ سنجش نمایش داده شود، نه برای استفاده در خروجی، بلکه برای عیب‌یابی.

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

این عادت، پرامپت‌های تو را با گذشت زمان محکم‌تر می‌کند، چون هر بار یک بند مبهم را عددی می‌کنی. اگر می‌خواهی از پایه این مهارت را بسازی، پرامپت‌نویسی برای مبتدی‌ها نقطهٔ شروع خوبی است.

۷. چهار دام خودارزیابی

اعتماد کامل به قبولی. وقتی مدل می‌گوید همهٔ شرط‌ها قبول شدند، همیشه راست نمی‌گوید؛ به‌ویژه در شرط‌های شمارشی مثل تعداد کلمه. برای شرط‌های حساس، خودت یا یک اسکریپت باید بررسی نهایی را انجام دهد.

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

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

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

۸. پرسش و پاسخ

خودبررسی هزینهٔ بیشتری دارد؟ بله، پاسخ کمی طولانی‌تر پردازش می‌شود، اما در برابر وقتی که صرف بازبینی دستی و اجرای دوباره می‌شود، صرفهٔ روشنی دارد. برای کارهای تکرارشونده تقریباً همیشه به‌صرفه است.

می‌شود سنجش را به یک گفت‌وگوی جدا سپرد؟ بله و برای کارهای مهم بهتر هم هست. در گفت‌وگوی تازه فقط متن و چک‌لیست را بگذار و بخواه فقط قبول یا رد بدهد؛ چون متن را کار خودش نمی‌داند، سخت‌گیرانه‌تر می‌سنجد.

اگر خروجی JSON باشد باز هم خودبررسی لازم است؟ لازم است اما کافی نیست. سنجش نهایی ساختار داده را باید یک اعتبارسنج واقعی انجام دهد. ساخت درست این ساختارها موضوع قسمت دوم سری است.

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

دو تمرین زیر این قسمت را تثبیت می‌کنند؛ دومی را روی یکی از پرامپت‌های واقعی خودت اجرا کن.