Automatic Prompt Engineer (APE) به یک مدل زبانی اجازه می‌دهد تا بهترین پرامپت را برای یک وظیفه مشخص بنویسد، آزمایش کند و انتخاب کند؛ و بدین ترتیب آنچه را که زمانی هنری مبتنی بر آزمون و خطا بود، به یک جستجوی داده‌محور و تکرارپذیر تبدیل می‌کند.

چرا نوشتن پرامپت به یک گلوگاه تبدیل شده است

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

گردش کار سه مرحله‌ای APE

APE فرآیند ایجاد پرامپت را به عنوان یک مسئله جستجو در نظر می‌گیرد. کاربر مجموعه‌ی کوچکی از نمونه‌های ورودی-خروجی را به سیستم می‌دهد. سپس سیستم سه مرحله خودکار را اجرا می‌کند:

  1. پیشنهاد (Propose) – مدل نمونه‌ها را اسکن کرده و دسته‌ای از دستورالعمل‌های کاندید را ارائه می‌دهد، مانند «متضاد را برگردان» یا «مترادف را بنویس».
  2. امتیازدهی (Score) – سیستم هر کاندید را روی مجموعه‌ی مجزایی از نمونه‌های دیده‌نشده اجرا می‌کند و تعداد پاسخ‌هایی که با خروجی مورد انتظار مطابقت دارند را می‌شمارد که منجر به یک عدد دقت خام می‌شود. در این مرحله هیچ قضاوت انسانی دخالتی ندارد.
  3. انتخاب (Select) – دستورالعملی که بالاترین دقت را داشته باشد، به پرامپت نهایی تبدیل می‌شود.

این حلقه می‌تواند تکرار شود. پرامپت برنده به هسته‌ی (seed) جدید تبدیل می‌شود و مدل تغییرات جدیدی را پیشنهاد می‌دهد. در اجراهای گزارش شده، یک دستورالعمل عمومی که امتیاز ۸۳٪ را کسب کرده بود، به نسخه‌ای اصلاح شد که در مجموعه‌ی تست به امتیاز ۱۰۰٪ رسید.

چه چیزی این رویکرد را قوی‌تر از توانایی انسان می‌کند

  • پوشش (Coverage) – یک LLM ده‌ها جایگزین برای عبارت‌بندی را در عرض چند ثانیه تولید می‌کند، بسیار بیشتر از آنچه یک فرد بتواند آزمایش کند.
  • عینیت (Objectivity) – انتخاب بر پایه دقت قابل اندازه‌گیری است، نه بر اساس اینکه کلمات چقدر صیقل‌خورده و رسمی به نظر می‌رسند. یک دستورالعمل کتابخانه‌ای و رسمی ممکن است همچنان از یک نسخه کوتاه و عجیب‌وغریب که مدل آن را بهتر درک می‌کند، شکست بخورد.

از آنجایی که معیار امتیازدهی توسط کاربر تعیین می‌شود — که معمولاً یک بررسی مطابقت دقیق یا یک تست واحد (unit test) است — سیستم را می‌توان برای هر نیاز پایین‌دستی، از تولید کد گرفته تا تحلیل احساسات، تنظیم کرد.

بهای خودکارسازی

موازنه در اینجا بر سر منابع محاسباتی (compute) است. امتیازدهی به هر کاندید، باعث ارسال فراخوانی‌های زیادی به مدل می‌شود، بنابراین مرحله توسعه مقدار قابل توجهی از مصرف API را می‌سوزاند. APE این هزینه را به عنوان یک سرمایه‌گذاری یک‌باره در نظر می‌گیرد: هنگامی که پرامپت بهینه شناسایی شد، می‌توانید بدون هزینه اضافی، تا ابد از آن استفاده کنید.

دو پیش‌نیاز نیز پذیرش این روش را محدود می‌کند:

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

جایی که ممکن است این ایده دچار لغزش شود

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

آنچه باید در ادامه دنبال کرد

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

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