«تبدیل پرامپت به آثار تدوین‌شده»؛ راهکار گوگل برای اعتبارسنجی خودکار

یک پرامپت سیستمی (System Prompt) واحد و حجیم، بمب ساعتی هر عامل هوش مصنوعی در محیط عملیاتی است. طبق یک راهنمای فنی مورخ ۱۶ جولای ۲۰۲۶ از گوگل، رویه‌ی رایج لایه‌بندی سیاست‌های ایمنی و قوانین دامنه در یک فایل واحد، «حریم تخریب مبهم» (Obscured Blast Radius) ایجاد می‌کند که در آن تغییر یک جمله ساده می‌تواند به‌طور خاموش کل گردش‌های کاری را متوقف کند.

وقتی در ابتدای راه هستید، یک فایل تک‌منبع برای چند دستورالعمل و تعریف ابزار معمولاً کافی است. اما به محض اینکه تیم‌ها الزامات قالب‌بندی، قوانین تخصصی دامنه و رفتارهای ارجاعی (Escalation Behaviors) را اضافه می‌کنند، مرکز کنترل برای مدیریت بیش از حد پیچیده می‌شود. این مشکل دقیقاً شبیه به چالش‌های مقیاس‌پذیری در مهندسی نرم‌افزار کلاسیک است. در واقع، استفاده از چارچوب‌های نقش‌محور برای مدیریت این دستورات می‌تواند به‌طور قابل‌توجهی نرخ خطای پرامپت‌ها را در سیستم‌های پیچیده کاهش دهد.

وقتی تیم‌ها هر نیازمندی را در یک فایل دستورالعمل می‌گنجانند، توانایی استدلال درباره‌ی سیستم را از دست می‌دهند و با «انحراف کپی-پیست» (Copy-Paste Drift) دست‌وپنجه نرم می‌کنند. این اتفاق زمانی رخ می‌دهد که منطق‌های مشترک — مانند مدیریت داده‌های شناسایی شخصی (PII)، سیاست‌های ایمنی، دستورالعمل‌های استفاده از سرویس‌های داخلی یا پروتکل‌های ارجاع — در برنامه‌های مختلف تکثیر می‌شوند و در نهایت منجر به ناهماهنگی‌های اجتناب‌ناپذیر می‌گردند.

به گزارش گوگل، استفاده از قالب‌ها (Templates) برای حل این مشکل کافی نیست زیرا تشخیص خطا را به زمان اجرا (Runtime) منتقل می‌کند. تکیه بر فرمت‌بندی‌های موردی (Ad-hoc string formatting) باعث می‌شود پرامپتی مستقر شود که تنها زمانی شکست می‌خرد که یک گردش‌کار خاص و کم‌کاربرد — مثلاً به دلیل یک مسیر واردات (Import Path) نامعتبر یا یک متغیر گم‌شده — فعال شود.

یک سیستم عملیاتی به جای این وضعیت، به ساخت‌های قطعی (Deterministic Builds)، اعتبارسنجی استاتیک و ادغام کامل در خط لوله‌ی CI/CD نیاز دارد. راهکار این است که با پرامپت‌ها مانند آثار نرم‌افزاری (Software Artifacts) برخورد شود که پیش از رسیدن به مدل زبانی بزرگ (LLM) — شبیه به کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — باید کامپایل و اعتبارسنجی شوند.

سازوکار تبدیل (Transpilation)

در این روش، توسعه‌دهندگان به جای یک فایل غول‌آسا، «فایل‌های مهارت» (Skill Files) ماژولاری می‌نویسند که رفتارهای خاصی را در خود جای داده‌اند. این کار به تیم‌ها اجازه می‌دهد دغدغه‌ها را تفکیک کنند و روی اجزای مجزا بدون به خطر انداختن کل سیستم، نسخه‌های جدید را آزمایش کنند. این رویکرد با استراتژی تولید دستورات به‌جای کد خام هم‌سو است تا ساختار فنی اپلیکیشن‌ها در برابر تغییرات مقاوم بماند. یک قالب سطح‌بالای عامل، از دستورات include و ماکروها برای ترکیب این قطعات استفاده می‌کند.

برای مثال، قالب یک عامل SRE (مهندس قابلیت اطمینان سیستم) در مسیر agents/sre_agent.prompt.md ممکن است ماژول‌های مشترک ایمنی و استفاده از ابزار را فراخوانی کند و متغیرهای محیطی را در آن‌ها تزریق نماید. این منطق می‌تواند شرطی باشد؛ اگر متغیر allow_remediation فعال (True) باشد، عامل می‌تواند مراحل اصلاحی را پیشنهاد دهد (البته با تأیید انسانی برای اقدامات تخریبی)، اما اگر غیرفعال (False) باشد، عامل فقط محدود به بررسی و توضیح مشکل است.

برای مدیریت ساختارهای تکراری، سیستم از ماکروها استفاده می‌کند؛ مثلاً ماکروی bullet_section که یک عنوان و لیستی از موارد را می‌گیرد. برای یک عامل SRE، این مورد برای تعریف مراحل ضروری بازرسی به کار می‌رود، مانند:

• بررسی رویدادهای استقرار اخیر
• چک کردن متریک‌های سرویس برای تغییر در نرخ خطا یا تأخیر
• بازبینی لاگ‌ها برای یافتن الگوهای شکست تکراری

این رویکرد ماژولار امکان ایجاد یک خط لوله‌ی تبدیل را فراهم می‌کند که قالب‌ها را به یک اثر نهایی و رندرشده تبدیل می‌کند. اگر متغیری گم شده باشد یا مسیر یک import اشتباه باشد، فرآیند ساخت (Build) بلافاصله شکست می‌خورد. با این تغییر، مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن برای گرفتن بهترین جواب از مدل — از یک تمرین نویسندگی خلاق به یک مسئله‌ی سیستمی (Build-system problem) تبدیل می‌شود.

اعتبارسنجی اجباری در زمان ساخت

برای تضمین پایداری، یک تبدیل‌کننده در سطح صنعتی باید چندین بررسی حیاتی را در طول فرآیند ساخت انجام دهد تا خطاها پیش از رسیدن به زمان اجرا شناسایی شوند. این اعتبارسنجی‌ها تضمین می‌کنند که خروجی نهایی یک اثر قطعی است که می‌توان آن را حسابرسی یا مقایسه (Diff) کرد:

• گراف‌های وابستگی: مدل‌سازی قطعات پرامپت به عنوان گره‌هایی در یک گراف جهت‌دار برای شناسایی واردات بازگشتی (Recursive Imports) که در غیر این صورت باعث شکست‌های خاموش در محیط عملیاتی می‌شوند.
• اعتبارسنجی متغیرها: اجرای بررسی‌ها برای متغیرهای تعریف‌نشده و واردات گم‌شده تا اطمینان حاصل شود قالب به‌طور کامل Resolve می‌شود.
• بررسی انحراف (Drift Checking): بازتولید پرامپت تبدیل‌شده از منبع (فایل طلایی یا Golden File) و مقایسه آن با اثر ثبت‌شده (Committed Artifact). اگر خروجی‌ها متفاوت باشند، ساخت شکست می‌خرد تا شکاف بین فایل‌های منبع و آثار مستقر از بین برود.

بازیابی پویای مهارت‌ها

بارگذاری تمام مهارت‌های موجود در هر فراخوانی عامل، توکن‌های غیرضروری را مصرف کرده و نویزهایی ایجاد می‌کند که روی عملکرد وظایف خاص اثر منفی می‌گذارد. گوگل معماری «افشای تدریجی» (Progressive Disclosure) را پیشنهاد می‌دهد. در این مدل، پرامپت پایه‌ی کامپایل‌شده، هویت‌های غیرقابل‌تغییر و مرزهای ایمنی را تحمیل می‌کند.

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

این معماری مسیری به سوی عامل‌های خودپایدار می‌گشاید. چون دستورالعمل‌ها اکنون به جای تغییرات لحظه‌ای، در قالب تغییرات کد (PR) هستند، یک عامل می‌تواند به خودش در مدیریت لایه‌ی دستورالعمل‌ها کمک کند. مثلاً پس از حل یک حادثه جدید، عامل می‌تواند به‌طور تئوریک پیش‌نویس یک ماژول مهارت جدید را بنویسد، واردات مربوطه را به‌روز کند و یک Pull Request باز کند.

این پیشنهاد سپس همان مراحل اعتبارسنجی و بررسی انسانی را طی می‌کند که هر قطعه کد دیگری می‌گذرد. بازبین انسانی PR را بررسی کرده و پیش از ادغام، ارزیابی‌ها (Evals) را اجرا می‌کند. این یعنی عامل به جای تغییر کنترل‌نشده‌ی منطق خود در زمان اجرا، یک تغییر کد در سیستم ساخت پیشنهاد می‌دهد.

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

برای توسعه‌دهندگان، گام بعدی این است که از دست‌کاری مستقیم رشته‌های متنی (Raw String Manipulation) فاصله بگیرند و یک لایه رسمی تبدیل پرامپت را در خط لوله‌ی CI/CD خود پیاده‌سازی کنند تا شکاف بین منبع و استقرار به‌طور کامل eliminated شود.

گام بعدی شما

• دست کشیدن از دست‌کاری مستقیم رشته‌های متنی در مدیریت پرامپت‌ها.
• پیاده‌سازی یک لایه رسمی تبدیل پرامپت در خط لوله‌ی CI/CD برای حذف فاصله بین منبع و استقرار.
• تفکیک دستورات سیستمی به ماژول‌های مهارت مجزا برای کاهش مصرف توکن و افزایش دقت.

اما تأمین سخت‌افزاری برای این حجم از استقرارها چالش دیگری است؛ برای درک هزینه استنتاج در مقیاس بزرگ، به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.