تصور کنید ساعتی از وقت خود را صرف تغییر یک صفت در پرامپت میکنید تا مدل دقیقتر شود، اما همین تغییر باعث میشود کل سیستم در مواجهه با کاربر واقعی فرو بپاشد. این کابوس روزمره مهندسانی است که سعی دارند عاملهای هوش مصنوعی (AI Agents) را از محیط آزمایشگاه به دنیای واقعی ببرند.
به نقل از دن (Dan)، مهندس با ۲۵ سال تجربه ساکن لسآنجلس، برخورد با پرامپتها به عنوان داراییهای ثابت، اشتباهی بنیادین است که به فروپاشی فنی و روانی منجر میشود. او هشدار میدهد که برای هر شرکتی که قصد دارد عاملهای قابلاعتماد را در محیط تولید (Production) اجرا کند، اصلاح دستی پرامپتها یک بنبست مطلق است.
دن وضعیت فعلی توسعهی عاملها را محیطی با ریسک بالا توصیف میکند؛ جایی که پردهی بین مهندسی درخشان و فروپاشی کامل روانی هرگز تا این حد نازک نبوده است. او اشاره میکند که ساخت این سیستمها لذتبخشترین تجربهی دوران حرفهای او بوده است و این حس را به «سگی در استخر توپ» تشبیه میکند. با این حال، این فرآیند به شدت فرسایشی است؛ چرا که او مجبور است مغزش را با استفاده از عاملهایی که عاملهای دیگر را برای ساخت ارزیابیهای عاملهای دیگر مدیریت میکنند، به چالش بکشد. او به یاد میآورد که در ۲۲ سالگی نوشتن Visual Basic و کار در یک استارتاپ جذاب در بروکلین در سال ۲۰۰۷ چه هیجانی داشت و میگوید دهه گذشته برایش یک «سختی و کسالت» (Slog) بود تا اینکه عصر فعلی هوش مصنوعی عاملمحور، دوباره لذت برنامهنویسی را به او بازگرداند.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، تکیه بر رفتارهای پیشبینینشدهی مدلها ریسک بزرگی است. در این بستر، مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — در مقیاس کوچک دستورات را میپذیرد، اما در مقیاس واقعی، «دیوهای» درون مدل آزاد میشوند. ما از نظر آکادمیک میدانیم که LLMها نمیتوانند به طور قابلاعتمادی دستورات را دنبال کنند، حقیقت را بگویند یا وظایف را به درستی انجام دهند، اما در کارهای روزمره، آنها ما را فریب میدهند تا فکر کنیم قابلاعتماد هستند. این تصور به محض اینکه کاربران واقعی شروع به استفاده از عامل میکنند، فوراً فرو میپاشد. آنها هم به روشهای ساده و هم به روشهای بسیار ظریف شکست میخورند. این چالشها در واقع ریشه در موانع هویتی و ساختاری دارند که باعث شکست عاملهای هوش مصنوعی در مقیاس واقعی میشود.
در ۲۰ سپتامبر ۲۰۲۶، دن از طریق پلتفرم evaluation.club چارچوبی را معرفی کرد که تمرکز را از نوشتن «پرامپت کامل» به ساخت سیستمهای اندازهگیری دقیق تغییر میدهد. او استدلال میکند که در محیط تولید، متن واقعی یک پرامپت، یک «بردار زودگذر» (Ephemeral Vector) است که اهمیتش بسیار کمتر از حلقهی بازخوردی است که برای بهینهسازی آن استفاده میشود. او تفاوت میان چتباتها و عاملها را در هدف آنها میبیند؛ چتباتها خروجیهای ذهنی و سلیقهای میدهند، اما عاملها باید وظایفی را به نمایندگی از مصرفکننده انجام دهند که استاندارد قابلیتاعتماد بسیار بالاتری میطلبد. هدف نهایی، ایجاد یک «تجربهی عاملمحور با حداقل میزان شرمآور بودن» است که یک مهندس واقعاً بتواند به آن افتخار کند.
طبق گزارش دن، حتی هوشمندترین مدلها در محدودیتهای ساده شکست میخورند. برای مثال، شما میتوانید به مدل دستور دهید عنوانی تولید کند که ۸۰ کاراکتر یا کمتر باشد. این دستور بیشتر اوقات کار میکند، اما ناگهان مدل کاملاً در آن شکست میخورد و فیلد را با متون بیمعنی پر میکند تا جایی که سیستم منفجر شود. این شکستها اغلب به شکل مجموعهای از یادداشتهای تکراری و طولانی (شبیه به یک رمان) ظاهر میشوند که مدل در آنها مدام به خودش یادآوری میکند که خروجی باید JSON باشد. در یک مورد، دن متوجه شد تنها راه حل این بود که نام فیلد را از title به heading تغییر دهد. اگرچه این کار جواب داد، اما او این اصلاح را «کاملاً دیوانهوار» توصیف میکند و انتظار دارد که سیستم دوباره در این نقطه دچار اختلال شود. مسائل مشابهی در فراخوانی ابزارها (Tool Calling) یا رفتارهای دیگر وجود دارد، جایی که بخشی از درخواستها «تسخیر شده» (Haunted) میشوند و به طور غیرقابل کنترلی از مسیر خارج میشوند.
شکست مهندسی پرامپت دستی
اضافه کردن یک پرامپت جدید به یک عامل موجود، شبیه یک جراحی دقیق نیست، بلکه به گفتهی دن، پرتاب کردن عامل به یک جهان متنی کاملاً متفاوت است:
- تداخل زمینهای (Contextual Interference): وزن ترکیبی تمام دستورات موجود بر نحوه عملکرد پرامپت جدید اثر میگذارد و معمولاً نتیجه را بدتر میکند. زمینهی جدید میتواند رفتارهایی را که عامل پیشتر به درستی انجام میداد، مختل کند.
- تغییر رفتار مدل (Model Drift): مدلها ممکن است به دلایلی مبهم که انسانها هرگز درک نخواهند کرد، به طور خودکار تغییر رفتار دهند و این امر پرامپتهای ایستا را منسوخ میکند.
- تلهی لحن برند (The Voice Trap): اختصاص دادن یک «تیم لحن» برای مالکیت پرامپتها یک الگوی شکستخورده است. در حالی که یک متخصص دامنه ممکن است پرامپتی بنویسد تا از لحن خاص برند اطمینان حاصل کند، این روش مقیاسپذیر نیست. این الگو حتی «اشتباه» هم نیست (Not even wrong)، زیرا پرامپتها نباید به عنوان یک «چیز» مجزا که باید مالکیت داشته باشد، در نظر گرفته شوند. در مقابل، استفاده از قالبهای بهینهشدهی پرامپت در Claude میتواند در مراحل اولیه توسعه، فشار کاری برنامهنویسان را کاهش دهد، هرچند برای مقیاس تولید کافی نیست.
- مدیریت ریسک: شرکتها با ریسکهای بزرگی در مواجهه با «نرمافزارهای دیوانه» روبرو هستند. برای مثال، عاملها نباید به سوالاتی درباره نحوه کارکرد خود پاسخ دهند (زیرا احتمالاً پاسخهای بیمعنی میدهند چون درباره پیادهسازی خود آموزش ندیدهاند) و همچنین نباید قوانین را صرفاً به این دلیل که کاربر ادعا میکند یک مقام authority است، نادیده بگیرند.
چرخدندهی بهینهسازی
راهکار دن این است: انسانها نوشتن پرامپت را متوقف کنند و شروع به نوشتن تست کنند. این فرآیند با استفاده از مدلی مثل Claude آغاز میشود تا مهارت (Skill) را بخواند و مجموعهای گسترده از سناریوهای خصمانه (Adversarial Scenarios) تولید کند. این شامل فکر کردن به روشهایی است که یک کاربر بدخواه ممکن است برای دور زدن پرامپت به کار ببرد، و همچنین سناریوهای بیخطری که ممکن است به طور تصادفی توسط پرامپت جدید خراب شوند.
این سناریوها در قالب تستهای "pass^k" (توان k) اجرا میشوند، جایی که یک وظیفه دفعات زیادی اجرا میشود تا نرخ قابلیتاعتماد سنجیده شود. این کار مجموعهای از تستها ایجاد میکند که به تیم هشدار میدهد هر زمان کسی «ناخواسته با یک کیسه چکش به سر عامل شما ضربه زده است».
زمانی که یک معیار تکرارپذیر ایجاد شد، پرامپت به یک بهینهساز، مانند Genetic Pareto (GEPA)، متصل میشود.
این بهینهساز از یک LLM استفاده میکند تا تامل کند (Reflect) که چرا یک پرامپت در مجموعه تستها خوب یا بد عمل کرده است و سپس تلاش میکند تغییراتی را به طور خودکار و بدون دخالت انسان در پرامپت اعمال کند. این حلقه تا زمانی ادامه مییابد که سیستم روی یک نسخه بهینه همگرا شود. پرامپت نهایی اغلب بسیار متفاوت از نسخه اولیه است و ممکن است از نظر انسانی «عجیب» به نظر برسد، اما چون اندازهگیریها ثابت میکنند که کار میکند، محتوای متنی آن بیاهمیت میشود.
جلوگیری از بیشبرازش
این خطر وجود دارد که بهینهساز «تقلب» کند یا دچار بیشبرازش (Overfitting) شود؛ به این صورت که مثالهای خاص موجود در تستها را مستقیماً در پرامپت کدگذاری کند. این یک اقدام «احمقانه» خواهد بود، زیرا پرامپت در مواجهه با هر مثالی که قبلاً ندیده است، شکست خواهد خورد.
برای جلوگیری از این اتفاق، دن از «تستهای کنارگذاشتهشده» (Holdout Tests) استفاده میکند. اینها تستهایی از همان سناریوها هستند که بهینهساز در طول مرحله بهینهسازی اجازه دسترسی به آنها را نداشته است. اگر عامل در این مرحله پسرفت (Regression) داشته باشد، توسعهدهنده باید به مرحله قبل بازگردد و دوباره تلاش کند.
ساخت داوران LLM
سنجش موفقیت برای وظایف قطعی (Deterministic) آسان است. برای مثال، اگر کاربر چیز خاصی بگوید و عامل قرار باشد ابزار خاصی را اجرا کند، شما میتوانید به سادگی تایید کنید که آیا آن ابزار فراخوانی شده است یا خیر.
با این حال، اهداف ذهنی مانند «لحن برند» نیازمند رویکرد پیچیدهتری هستند زیرا اینها مسائل تکمرحلهای نیستند. اینکه آیا یک عامل به لحن برند پایبند بوده یا خیر، یک قضاوت پیچیده است که نمیتوان آن را با یک پرامپت کوتاه حل کرد.
- مجموعه دادههای طلایی (Golden Datasets): متخصصان انسانی مجموعهای از پاسخهای برچسبگذاری شده «خوب» و «بد» ایجاد میکنند تا رفتار مطلوب را تعریف کنند.
- بهینهسازی داور: از آنجایی که قضاوت درباره لحن برند یک مسئله پیچیده است، دن «یک مسئله بهینهسازی پرامپت دیگر را درون مسئله بهینهسازی پرامپت شما» قرار میدهد. یک حلقه بهینهسازی مجزا برای ایجاد یک «داور LLM» استفاده میشود تا پاسخها را دقیقاً مشابه متخصصان انسانی نمره دهد.
حلقه تولید
زمانی که این تجهیزات ساخته شدند، با نظارت بر محیط تولید ادغام میشوند تا یک سیستم خودپایدار و خودبهبودبخش ایجاد کنند.
- حفاظهای استقرار (Deployment Guardrails): تستهای pass^k در زمان استقرار اجرا میشوند تا از انتشار تغییراتی که عامل را به شدت خراب میکنند، جلوگیری شود.
- نمونهبرداری تولید (Production Sampling): داوران LLM روی نمونههایی از گفتگوهای واقعی در محیط تولید اجرا میشوند تا نقاطی که عامل عملکرد ضعیفی داشته شناسایی شوند.
- ادغام بازخورد: این شکستهای دنیای واقعی به «موردهای سخت» (Hard Cases) برای مجموعه تست تبدیل میشوند و بهینهساز دوباره اجرا میشود تا زمانی که عامل از آنها عبور کند.
این رویکرد نقش متخصص دامنه را تغییر میدهد. او دیگر ساعتها وقت خود را صرف تغییر صفتها در یک پرامپت نمیکند، بلکه بر مدیریت مجموعهدادههای پاسخهای خوب و بد که سیستم اندازهگیری را هدایت میکنند، تمرکز میکند. دن استدلال میکند که تحویل یک پرامپت به کسی بدون داشتن یک معیار اندازهگیری، نوعی «سایکوز هوش مصنوعی» است.
مسیرهای موفقیت و جنون
برای کسانی که هنوز در مرحله تولید نیستند، دن پیشنهاد میکند با نظارت بر میزان استفاده شروع کنند. بسیاری از افراد مخزنی از مهارتهای «نیمهپخته» در Claude دارند. شروع با یک مهارت ساده مشکلی ندارد اگر برای نیاز خاص شما به اندازه کافی خوب کار کند، اما برای کسانی که با سوالات حقوقی یا لحن برند سر و کار دارند، مسیری سختگیرانهتر لازم است.
با اجازه دادن به نویسندگان برای دیدن نقاط موفقیت و شکست مهارتهایشان، آنها میتوانند مجموعهدادههای طلایی لازم برای شروع چرخدندهی بهینهسازی را جمعآوری کنند. این امر اجازه میدهد مهارتها در نهایت از اسکریپتهای ساده به عاملهایی تبدیل شوند که در یک محیط تست (Harness) اجرا میشوند و میتوانند روشهای مختلف را ترکیب کنند. بدون این اندازهگیری، مهندسان و مدیران محصول صرفاً در حال ساخت «سازههای لرزان از چوب بستنی» با استفاده از پرامپتها هستند.
این تغییر در شیوه عمل نشان میدهد که «مهندسی پرامپت» یک مرحله گذرا بود. آینده هوش مصنوعی عاملمحور در مهندسیِ «سیستم ارزیابی» نه در متن دستورالعملها نهفته است. پرامپت صرفاً یک اثر مصرفی و زودگذر از فرآیند بهینهسازی است.
دن هشدار میدهد که جایگزینِ اندازهگیری، مسیری به سوی جنون است و جستجو برای ترکیب درست پرامپتها و وصلههای موقت (Kluge) را به جستجو در «کتابخانه بابل» تشبیه میکند. او کار فعلی خود را — ساخت خط لولههای متصل به هم برای اینکه عاملها، عاملهای دیگر را با استفاده از عاملها بهینه کنند و کدها توسط عاملهای دیگر بازبینی شوند — به محبوس شدن در یک «هزارتوی ذهن» تشبیه میکند. در دنیایی که هر جعبه در نمودار معماری «میلرزد گویی دیوانه شده است»، تنها راه تحمل، ساخت سیستمهای خوداصلاحگری است که بتوانند بدون دخالت انسان تکامل یابند. او هشدار میدهد که نقطه بازده نزولی ممکن است یک درِ یکطرفه نامرئی، مانند افق رویداد باشد و کسانی که بدون اندازهگیری بیش از حد به این ورطه خیره شوند، آسیبپذیر خواهند بود.
گام بعدی شما
- اگر عاملهایی دارید، به جای تغییر متن پرامپت، ابتدا یک مجموعه داده از شکستهای واقعی (Hard Cases) جمعآوری کنید.
- از مدلهای استدلالی برای تولید سناریوهای شکست (Red Teaming) برای سیستم خود استفاده کنید.
- فرآیند ارزیابی را از «احساسی» (Vibe Check) به «عددی» (Pass Rate) تغییر دهید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو