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

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

متاپرامپت یک پرامپت بسیار بلند است که شرح وظیفهٔ شما را می‌گیرد و در خروجی، قالب یک پرامپت حرفه‌ای تحویل می‌دهد؛ همراه با متغیرها، تگ‌های ساختاری و جای خالیِ مثال‌ها. در درس مقدماتی متاپرامپت با ایدهٔ کلی آشنا شدیم؛ امروز سراغ نسخهٔ رسمی و مهندسی‌شدهٔ خودِ آنتروپیک در کوک‌بوک می‌رویم و می‌بینیم از چه اجزایی ساخته شده است.

آنچه در این درس یاد می‌گیرید

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

مسئله‌ای که متاپرامپت حل می‌کند

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

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

ساختار چهاربخشی

متاپرامپت رسمی از چهار بخش پشت‌سرهم ساخته شده و فهمیدن این چهار بخش، از خودِ استفاده از آن ارزشمندتر است — چون همین الگو را می‌توانید برای هر «تولیدکنندهٔ خودکار» دیگری تکرار کنید.

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

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

بخش سوم؛ دستور تولید. از مدل خواسته می‌شود خروجی را در سه تگ مشخص بدهد که پایین‌تر توضیحشان می‌دهیم.

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

خروجی سه‌تگی؛ چرا سه تا؟

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

1. فهرست ورودی‌ها — اول مدل تصمیم می‌گیرد این وظیفه چه متغیرهایی لازم دارد.
2. نقشهٔ ساختار — بعد نقشه می‌کشد که هر متغیر کجای پرامپت بنشیند و ترتیب بخش‌ها چه باشد.
3. پرامپت نهایی — و تازه در قدم سوم متن کامل را می‌نویسد.

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

قرارداد متغیرها

در قالبِ تولیدشده، جای خالی‌ها با آکولاد دوگانه علامت می‌خورند: مثلاً {{SUPPORT_TICKET}}. علاوه بر این، متاپرامپت اصرار دارد هر ورودی داخل یک تگ توصیفی بیاید:

<ticket>
{{SUPPORT_TICKET}}
</ticket>

<policy>
{{RETURN_POLICY}}
</policy>

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

چهار تابع کوچک که چرخ را می‌چرخانند

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

import re

def extract_between_tags(tag, text):
    return re.findall(rf"<{tag}>(.*?)</{tag}>", text, re.DOTALL)

def extract_prompt(text):
    # متن نهایی همیشه داخل تگ دستورهاست
    return extract_between_tags("Instructions", text)[0].strip()

def extract_variables(prompt):
    # هر چیزی که داخل آکولاد دوگانه باشد یک متغیر است
    return set(re.findall(r"{{([^}]+)}}", prompt))

def remove_empty_tags(text):
    # تگ‌های خالیِ ته خروجی را دور بریز
    return re.sub(r"\n<(\w+)>\s*</\1>$", "", text)

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

حلقهٔ کامل؛ از قالب تا آزمون

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

<SUPPORT_TICKET>
[یک مقدار کامل و واقع‌نما برای متغیر SUPPORT_TICKET]
</SUPPORT_TICKET>

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

نسخهٔ فشرده و آمادهٔ کپی

متاپرامپت اصلی بلند است و برای کارهای روزمره لازم نیست همه‌اش را داشته باشید. این نسخهٔ کوتاه، همان اسکلت را نگه می‌دارد:

تو یک مهندس پرامپت باتجربه‌ای. قرار است برای دستیاری پرامپت بنویسی
که مشتاق و دقیق است اما هیچ چیز را از پیش نمی‌داند؛ پس همه‌چیز را
صریح بنویس.

شرح وظیفه:
<task>
پاسخ اولیه به تیکت‌های پشتیبانی یک فروشگاه اینترنتی، بر پایهٔ
قوانین مرجوعی، بدون وعدهٔ خارج از قوانین.
</task>

خروجی را دقیقاً در سه تگ زیر و به همین ترتیب بده:
<Inputs> فهرست متغیرهای لازم، هر کدام با یک خط توضیح </Inputs>
<Structure> نقشهٔ ترتیب بخش‌ها و جای هر متغیر </Structure>
<Instructions> متن کامل پرامپت نهایی </Instructions>

قواعد:
- متغیرها را به شکل {{NAME}} بنویس و هر ورودی را داخل تگ توصیفی بگذار.
- استدلال را پیش از نتیجه بخواه، نه بعد از آن.
- اگر وظیفه چندمرحله‌ای است، یک بخش یادداشت میانی در پرامپت بگنجان.
- محدودیت‌ها را مثبت بنویس: بگو چه کاری بکند، نه فقط چه نکند.

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

محدودیت‌هایی که باید بدانید

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

جمع‌بندی

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

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

منبع این درس، مستندات رسمی آنتروپیک است؛ ما آن را برای فارسی‌زبان‌ها درس کرده‌ایم.