نگاهی به Output Prompt

قبلا خیلی خلاصه درباره‌‌ی کوتاه کردن خروجی LLM نوشته بودم، توی اون مطلب نوشته بودم که چطور خروجی رو خیلی کوتاه و مختصر کنیم. این بار می‌خوام کمی بیشتر درباره دستورهایی بنویسم که شکل خروجی رو مشخص می‌کنن، یا همون چیزی که اینجا بهش می‌گم Output Prompt. اما وقتی از مدل برای review، تحلیل incident یا تصمیم معماری استفاده می‌کنیم، اون دستور کوتاه کردن خروجی ممکنه درخواست خوبی نباشه و خیلی چیزهای مهم رو از دست بدیم.

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

Separate observations from hypotheses. Cite the relevant logs. State what is still unknown and suggest the next verification step. Skip the action-by-action recap.

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

یک چیز مهم دیگه، سطح زبان و سطح دانش فنی هست. ممکنه کسی ده سال تجربه distributed systems داشته باشه، اما خوندن انگلیسی پیچیده براش کند و خسته‌کننده باشه. درخواستی مثل «ساده توضیح بده» ممکنه مدل رو به سمت توضیح مفاهیم مقدماتی ببره، در حالی که مشکل ما جمله‌های طولانی و اصطلاحات ادبیه، نه مفهوم پیچیده فنی. اینجا می‌شه از سطح‌های چارچوب CEFR کمک گرفت؛ مثلا B1 برای انگلیسی متوسط یا B2 برای متوسط رو به بالا:

Use B1-level English with short sentences. Assume an experienced backend engineer. Keep technical terms, trade-offs, and failure modes intact.

سطح CEFR اینجا یک راهنمای تقریبیه، نه تضمین قابل‌اندازه‌گیری، نکته اصلی اینه که زبان رو ساده کنیم، نه مسئله رو.

یک روش دیگه استفاده از الگوی ELI5 یا Explain Like I'm Five هست که بیشتر سراغ ساده‌سازی خود مفهوم می‌ره. برای ساختن یک تصویر اولیه مفیده، اما باید دقت کنیم که از این الگو برای خروجی‌های فنی پیچیده استفاده نکنیم، چون ممکنه خیلی از مفاهیم مهم رو توی ساده سازی از دست بدیم. برای همین بهتره دستورهایی مثل ELI5 رو به صورت global روی همه خروجی‌ها اعمال نکنیم.

ترجیح‌های مشترک پروژه مثل سطح زبان یا حذف مقدمه رو میشه توی فایل‌های AGENTS.md یا CLAUDE.md مربوط به هر پروژه گذاشت، اما خروجی incident report با code review یکی نیست، ساختار مخصوص هر کار بهتره همراه همون task یا داخل skill مربوط به اون تعریف بشه.

توی مواردی که قراره مصرف‌کننده خروجی یک سیستم یا agent دیگه باشه، درخواست JSON کافی نیست و باید از schema validation و در صورت پشتیبانی از structured output استفاده کنیم. برای خروجی انسانی هم می‌شه با چند نمونه واقعی بررسی کرد که آیا شواهد حفظ شدن، مجهول‌ها مشخصن و قدم بعدی قابل‌اجراست یا نه. این همون جاییه که بحث به Eval می‌رسه، خروجی خوش‌خوان رو با خروجی قابل استفاده اشتباه نگیریم.