اگر امروز شاهد افت کیفیت ناگهانی و مرموز در پاسخ‌های مدل زبانی خود هستید، احتمالاً مشکل از هوش مصنوعی نیست، بلکه از متنی است که به آن می‌فرستید. یک پرامپت معیوب رایج‌ترین دلیل کاهش کیفیت در برنامه‌های مبتنی بر مدل‌های زبانی است، اما لایه‌ی رندرینگ (Rendering) تقریباً هرگز مورد آزمایش قرار نمی‌گیرد.
در ۱۵ اوت ۲۰۲۶، یک راهنمای فنی در وب‌سایت dev.to منتشر شد که چارچوبی سخت‌گیرانه برای تست واحد (Unit Testing) قالب‌های پرامپت معرفی کرد تا این شکست‌های خاموش به‌طور کامل حذف شوند.
بسیاری از توسعه‌دهندگان رندرینگ پرامپت را مرحله‌ای پیش‌پاافتاده می‌بینند. آن‌ها متغیرها را جایگذاری کرده و درخواست را در یک تابع واحد به مدل می‌فرستند. این رویکرد، تست کردن را بدون استفاده از موک‌های (Mocks) پیچیده غیرممکن می‌کند و در نتیجه، تست‌ها هرگز نوشته نمی‌شوند. مشکل اصلی اینجاست که وقتی رندرکننده شکست می‌خورد، مدل خطایی نمی‌دهد؛ بلکه صرفاً یک پرامپت شکسته دریافت می‌کند و پاسخی توهم‌آمیز یا بی‌کیفیت تولید می‌کند.
معماری رندرینگ
رندرینگ پرامپت تنها بخشی از یک برنامه است که کاملاً قطعی (Deterministic) است. این فرآیند نیازی به دسترسی به شبکه ندارد و اجرای آن هزینه‌ای نمی‌برد. از آنجا که رندرکننده یک تابع خالص (Pure Function) است، باید دقیقاً مانند یکی از آن‌ها تست شود.
برای رفع این شکاف، این راهنما جداسازی رندرینگ از فراخوانی API را پیشنهاد می‌کند. با استخراج تابعی که قالب و زمینه (Context) را می‌گیرد و یک رشته متنی برمی‌گرداند، توسعه‌دهندگان می‌توانند از تست‌های واحد استاندارد استفاده کنند. این کار مدل را کاملاً از چرخه خارج می‌کند، سرعت تست‌ها را به میلی‌ثانیه می‌رساند و هزینه را به صفر می‌برد. توسعه‌دهندگان باید روی خودِ رشته‌ی رندر شده تأکید کنند. آن‌ها باید از استفاده از هش‌ها یا اسنپ‌شات‌ها دوری کنند، زیرا اسنپ‌شات‌ها اغلب به‌صورت واکنشی به‌روزرسانی می‌شوند (زمانی که قرمز می‌شوند)، و این امر تست را به جای بیان «آنچه باید رخ دهد»، به سندی از «آنچه رخ داده» تبدیل می‌کند.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، لایه‌های میانی نرم‌افزار اغلب نقاط کور امنیتی هستند. در اینجا نیز رندرینگ دقیقاً همان نقطه کور است.
ماتریس ورودی‌های پرخطر
تست تمام ترکیبات ممکن متغیرها از نظر ریاضی غیرممکن است، اما موارد خاصی وجود دارند که به‌طور مکرر رندرکننده‌ها را می‌شکنند. گزارش dev.to چندین ورودی بحرانی را شناسایی کرده است که باید حتماً تست شوند، زیرا هر یک از آن‌ها مسیری محتمل برای ورود از سوی کاربر واقعی یا پایگاه داده به شیء زمینه (Context Object) دارند:
- رشته‌های خالی و کلیدهای مفقود: یک رشته خالی می‌تواند برچسبی رها شده (مثلاً «نام مشتری: ») ایجاد کند که باعث شود مدل داده‌ها را از خودش اختراع کند. مفقود شدن کلید با رشته خالی متفاوت است؛ این مورد نشان‌دهنده‌ی «باگ جای‌گذار پر نشده» است. در این حالت رندرکننده باید خطا دهد، نه اینکه متن را رندر کند. این چالش دقیقاً همان جایی است که بررسی‌های ساختاری در برابر تست‌های سنتی برای پالایش خروجی‌ها اهمیت می‌یابند تا از ورود داده‌های نامعتبر به مدل جلوگیری شود.
- فضای خالی و طول متن: مقادیری که فقط شامل فضای خالی هستند، اغلب از بررسی‌های منطقی (Truthiness checks) در اکثر زبان‌ها عبور می‌کنند اما از نظر معنایی خالی‌اند. مقادیر بسیار طولانی — مانند یک رشته پشتیبانی با ۲۰۰ هزار کاراکتر — اگر رندرکننده آن‌ها را کوتاه نکند یا خطا ندهد، به‌طور خاموش از پنجره زمینه (Context Window) فراتر می‌روند. تولید خاموش پرامپتی که از پنجره مدل فراتر رود، بدترین حالت پیش‌فرض ممکن است.
- تداخل جداکننده‌ها و نشانگرها: اگر قالبی از آکولاد دوگانه
{{ }}استفاده کند، ورودی کاربر که حاوی همین آکولادها باشد ممکن است توسط برخی موتورها دوباره اسکن شود و توسط برخی دیگر نادیده گرفته شود. همچنین اگر پرامپت از### INSTRUCTIONSبه عنوان نشانگر بخش استفاده کند، کاربر با کپی کردن دقیق همین رشته می‌تواند ساختار پرامپت را تغییر دهد و منجر به تزریق پرامپت (Prompt Injection) در لایه‌ی قالب شود. - خطرات قالب‌بندی: استفاده از کد-فنس‌های سه-بک‌تیک (Triple-backtick) در ورودی کاربر می‌تواند بلوک‌های متنی را زودتر از موعد ببندد و دستورات سیستمی را به یک بازه کد (Code span) منتقل کند، جایی که مدل ممکن است آن‌ها را نادیده بگیرد.
- رمزگذاری و اسکریپت‌ها: تست‌ها باید شامل متون غیرلاتین، علامت‌های ترکیبی (Combining marks)، متون راست‌به‌چپ و سورگیت‌های تنها (Lone Surrogates) باشند. سورگیت‌های تنها زمانی رایج هستند که کلاینت‌ها رشته‌ها را بر اساس واحد کد (Code unit) برش می‌دهند.
پیاده‌سازی تست‌های مبتنی بر ویژگی
علاوه بر موارد خاص، این راهنما استفاده از تست‌های مبتنی بر ویژگی (Property-Based Testing) با کتابخانه Hypothesis را توصیه می‌کند. در اینجا توسعه‌دهندگان به جای نوشتن تست‌های تکی، ناورداهای (Invariants) تعریف می‌کنند که برای هر ورودی ممکنی باید صادق باشد. کتابخانه Hypothesis استراتژی‌هایی مانند text()، fixed_dictionaries() و sampled_from() را برای تولید این ورودی‌ها فراهم می‌کند.
برای مثال، می‌توان تأکید کرد که خروجی رندر شده هرگز نباید حاوی سینتکس باقی‌مانده از قالب (مانند {{) باشد و چارچوب استاتیک پرامپت — مانند مقدمه و نشانگرهای بخش — دست‌نخورده باقی بماند. به‌طور مشخص، تست باید تأیید کند که خروجی با STATIC_PREAMBLE شروع شود و نشانگرهای بخش مانند ### INSTRUCTIONS دقیقاً به همان تعداد دفعاتی ظاهر شوند که در قالب وجود دارند. این روش دفاعی بسیار قدرتمندتر از هر لیست سیاه (Blocklist) در برابر تزریق است.
ویژگی حیاتی دیگر، خروجی محدود (Bounded output) است. رندرکننده باید متن را در یک حد مستند کوتاه کند یا یک خطای تایپ‌شده (Typed error) صادر کند. نتایج باید یا کامل باشند یا صریح؛ بازگرداندن مقدار None، رشته خالی یا رشته‌های نیمه‌رندر شده، شکست موتور رندرینگ محسوب می‌شود.
جلوگیری از تزریق قالب
یک آسیب‌پذیری شدید زمانی رخ می‌دهد که رندرکننده، خروجی خودش را ارزیابی کند. اگر محتوای کاربر که حاوی سینتکس قالب است در پاس دوم دوباره رندر شود، کاربر می‌تواند متغیرهای دیگر در زمینه یا حتی ویژگی‌های اشیائی که آن‌ها متغیرها را نگه داشته‌اند بخواند. این یک حمله کلاسیک تزریق قالب سمت سرور (SSTI) است.
راهکار ساختاری این است: رندرینگ را فقط در یک پاس انجام دهید و هرگز خروجی رندر شده را به رندرکننده بازنگردانید. اگر خط لوله واقعاً به دو مرحله نیاز دارد، توسعه‌دهندگان باید از جداکننده‌های متفاوتی برای مرحله دوم استفاده کنند تا خروجی مرحله اول، سینتکس فعال برای مرحله دوم ایجاد نکند. این مورد باید مستقیماً با مقداری تست شود که خود یک قالب ارجاع به متغیری دیگر است؛ در اینجا باید تأیید شود که خروجی حاوی متن لیتِرال است، نه مقدار متغیر دوم.
مدیریت انفجار ترکیبی
برای جلوگیری از تست هزاران ترکیب بی‌فایده، دو تکنیک پیشنهاد شده است. اول، استفاده از پوشش جفتی (Pairwise Coverage) برای موارد خاص تا اطمینان حاصل شود که هر جفت از مقادیر جالب حداقل یک بار با هم ظاهر شده‌اند. این کار هزاران مورد را به چند ده مورد کاهش می‌دهد در حالی که تقریباً تمام باگ‌های تعاملی واقعی را می‌گیرد، زیرا تعاملات سه‌گانه بین متغیرهای مستقل بسیار نادر هستند. دوم، سپردن فضای نامحدود به تست‌های مبتنی بر ویژگی برای نمونه‌برداری از ترکیبات تصادفی.
یک بررسی دستی نهایی نیز ضروری است: «زمینه کاملاً مینیمال». این پرامپتی است که یک حساب کاربری جدید بدون تاریخچه می‌بیند؛ جایی که هر متغیر اختیاری غایب و هر متغیر اجباری در کوتاه‌ترین مقدار قانونی خود است. چون داده‌های آزمایشی (Fixtures) به‌ندرت شبیه این حالت هستند، اکثر موارد حذف کامل یک بخش از پرامپت در این وضعیت رخ می‌دهد.
این مجموعه تست‌ها با مستند کردن قرارداد قالب، هزینه‌ی خود را جبران می‌کند. هر توسعه‌دهنده‌ای که متغیر نهم را اضافه می‌کند، دقیقاً می‌بیند کدام متغیرها اجباری و کدام اختیاری هستند و مقادیر بیش از حد چگونه مدیریت می‌شوند، بدون اینکه نیاز باشد به حافظه همکارش تکیه کند.
گام بعدی شما
- رندرینگ پرامپت را از توابع فراخوانی API جدا کرده و آن را به عنوان یک تابع خالص در یک فایل مجزا قرار دهید.
- برای ورودی‌های کاربر، تست‌های لبه (Edge Case) شامل رشته‌های خالی، متون بسیار طولانی و کاراکترهای کنترلی را پیاده‌سازی کنید.
- کتابخانه Hypothesis را برای تعریف ناورداهای ساختاری پرامپت (مانند حفظ نشانگرهای بخش) به چرخه CI/CD خود اضافه کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو