داده‌های ساختاریافته جایگزین مدل‌های هوشمند برای حل مشکل «انحراف سهمیه» در AWS

تصور کنید مهندسی هستید که بر اساس مستندات رسمی AWS یک سهمیه vCPU را تنظیم می‌کند، اما سیستم در محیط عملیاتی کرش می‌کند چون عدد واقعی با مستندات متفاوت است. این کابوس «انحراف سهمیه» (Quota Drift) اکنون با یک رویکرد داده‌محور به جای تکیه بر هوشمندی مدل‌ها حل شده است. یک عامل هوشمند (AI Agent) که برای چالش Sanity ساخته شده، ثابت کرد که محتوای ساختاریافته تنها راه متوقف کردن این رفتار مدل‌هاست. توسعه‌دهنده این سیستم مکانیزمی را معرفی کرد که «انحراف» را شناسایی می‌کند؛ یعنی شکاف بین آنچه یک راهنما می‌گوید، آنچه کنسول نمایش می‌دهد و آنچه API زنده در واقعیت اعمال می‌کند.

در دنیای زیرساخت‌های ابری، مهندسان اغلب با کابوسی روبه‌رو هستند که در آن سه منبع رسمی، سه عدد متفاوت برای یک محدودیت واحد ارائه می‌دهند. برای یک حقیقت واحد در AWS، ممکن است سه صفحه رسمی هر کدام عدد متفاوتی را گزارش کنند. یک راهنمای کاربر قدیمی یک چیز می‌گوید، کنسول Service Quotas چیز دیگری می‌گوید و یک صفحه قیمت‌گذاری عدد سومی را ارائه می‌دهد. همه این‌ها رسمی به نظر می‌رسند، اما هیچ‌کدام نمی‌گویند کدام یک امروز فعال است. برای مثال، یک مهندس ممکن است محدودیت پیش‌فرض vCPU را از مستندات AWS کپی کرده و آن را پیاده‌سازی کند، اما سیستم در محیط عملیاتی از کار بیفتد زیرا عدد قدیمی بوده و هیچ هشدار یا اخطاری به او داده نشده است.

برای حل این مشکل، توسعه‌دهنده از مدل Amazon Nova Pro روی پلتفرم Bedrock به همراه Strands Agents (Python) و یک پایگاه دانش Context در Sanity استفاده کرد که از طریق Context MCP خوانده می‌شود. به جای تغذیه مدل با متون خام و نثر ساده، سیستم از یک طرحواره (Schema) سخت‌گیرانه و تایپ‌شده به نام awsFact استفاده می‌کند. این طرحواره با هر محدودیت به عنوان یک شیء داده‌ای برخورد می‌کند که دارای فیلدهای مشخص برای سرویس، منطقه (Region) و تاریخ اجرا (Effective Date) است.

شکست جست‌وجوی کلیدواژه‌ای

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

توسعه‌دهنده یک پرس‌وجو (Query) را برای یافتن حداکثر IOPS در هر حجم برای یک SSD با هدف عمومی تست کرد:

• مقدار فعلی ۸۰,۰۰۰ است (برای gp3، استخراج شده از کنسول EBS).
• مقدار قدیمی ۱۶,۰۰۰ است (سقف قدیمی gp2 که هنوز در یک راهنمای قدیمی SSD قرار دارد).

از آنجایی که راهنمای قدیمی دقیقاً عبارت «maximum IOPS per volume for a general purpose SSD EBS volume» را تکرار می‌کند، جست‌وجوی کلیدواژه‌ای (TF-IDF) عاشق این متن می‌شود. در یک تست پایه برای پرس‌وجوی «maximum IOPS per volume general purpose SSD»، نتایج به این ترتیب بود:

• EBS/limit (قدیمی): «Maximum IOPS per volume for a general purpose SSD ... = 16000» (امتیاز: ۰.۸۶۲۶) — اشتباه
• EBS/limit (فعلی): «Maximum provisioned IOPS per gp3 volume = 80000» (امتیاز: ۰.۲۰۲۶) — درست
• S3/price: «S3 Standard storage, first 50 TB / month = 0.023» (امتیاز: ۰.۰۲۱۸)
• EC2/quota: «Running On-Demand Standard ... = 5» (امتیاز: ۰.۰۱۸۵)

در اینجا عدد منقضی‌شده‌ی ۱۶,۰۰۰ با اختلاف زیاد برنده می‌شود. جست‌وجوی کلیدواژه‌ای عدد اشتباه را به شما تحویل می‌دهد و با اطمینان کامل آن را گزارش می‌کند.

مکانیزم تطبیق داده‌ها

عامل هوشمند برای فرار از این تله، از یک قانون تطبیق (Reconciliation) قطعی استفاده می‌کند که مدل زبانی (LLM) اکیداً از تغییر یا نادیده گرفتن آن منع شده است. سیستم از یک پایگاه دانش Sanity Context استفاده می‌کند که حقایق تایپ‌شده را ایندکس می‌کند. هر حقیقت یک سند با ساختاری شبیه به این است:

{
  "_type": "awsFact",
  "service": "EBS",
  "factType": "limit",
  "region": "us-east-1",
  "key": "Maximum provisioned IOPS per gp3 volume",
  "currentValue": "80000",
  "unit": "IOPS",
  "effectiveDate": "2026-01-15",
  "source": {
    "name": "EBS gp3 volume limits (Service Quotas / EBS console)",
    "kind": "serviceQuotasConsole",
    "url": "..."
  }
}

سیستم یک سلسله‌مراتب اولویت برای فیلد source.kind تعیین می‌کند:

۱. کنسول Service Quotas و صفحات قیمت‌گذاری (بالاترین اولویت)
۲. گزارش تغییرات (Changelogs)
۳. مستندات رسمی
۴. پست‌های وبلاگی (پایین‌ترین اولویت)

اگر دو رکورد با هم تضاد داشته باشند، رکوردی که اولویت منبع بالاتری دارد برنده می‌شود. اگر اولویت‌ها برابر باشد، جدیدترین effectiveDate (تاریخ اجرا) گره‌گشای تضاد خواهد بود. این امر تضمین می‌کند که پاسخ بر اساس یک گیت منطقی صادر شود، نه یک حدس احتمالی توسط مدل. عامل این حقایق را از طریق Context MCP با استفاده از knowledge_base_search برای جست‌وجوی رتبه‌بندی شده و knowledge_base_read برای خواندن کامل ورودی استخراج می‌کند.

بستن حلقه با APIهای زنده

حتی یک رکورد تطبیق‌یافته نیز می‌تواند با گذشت زمان فاسد و قدیمی شود. برای مبارزه با این موضوع، عامل یک بررسی متقاطع (Cross-check) فقط-خواندنی با APIهای زنده AWS (شامل Service Quotas، Price List API، EC2 و RDS) انجام می‌دهد. این کار یک مقایسه سه‌جانبه ایجاد می‌کند: مستند رسمی، رکورد تطبیق‌یافته و واقعیت زنده حساب کاربری.

در یک اجرای واقعی با استفاده از Nova Pro در منطقه us-east-1، عامل نتایج زیر را تولید کرد:

• سهمیه vCPU استاندارد On-Demand در EC2: مستندات می‌گویند ۳۲؛ رکورد تطبیق‌یافته می‌گوید ۵ (کنسول)؛ نتیجه زنده AWS می‌گوید ۱۶. حکم: انحراف (DRIFT)
• حداکثر IOPS در هر حجم EBS gp3: رکورد تطبیق‌یافته می‌گوید ۸۰,۰۰۰ (کنسول)؛ راهنمای قدیمی SSD می‌گوید ۱۶,۰۰۰. نتیجه زنده در دسترس نیست (چنین سهمیه زنده‌ای وجود ندارد). حکم: مورد اعتماد (TRUSTED)
• قیمت S3 Standard هر گیگابایت در ماه: صفحه قیمت‌گذاری می‌گوید ۰.۰۲۳؛ وبلاگ قدیمی می‌گوید ۰.۰۲۱. نتیجه زنده می‌گوید ۰.۰۲۳. حکم: مطابقت (AGREE)
• قدیمی‌ترین نسخه اصلی PostgreSQL در RDS: یادداشت‌های انتشار می‌گویند ۱۳؛ آموزش قدیمی می‌گوید ۱۱. نتیجه زنده می‌گوید ۱۱. حکم: انحراف (DRIFT)
• تعداد اجرای همزمان Lambda: راهنمای توسعه می‌گوید ۱۰۰۰. نتیجه زنده در دسترس نیست. حکم: مورد اعتماد (TRUSTED)
• در دسترس بودن Graviton4 (R8g): انواع نمونه‌ها می‌گویند Available. نتیجه زنده می‌گوید Available. حکم: مطابقت (AGREE)

عامل به جای اینکه یک عدد را انتخاب کند و امیدوار باشد درست باشد، هر سه عدد را گزارش کرده و نتیجه را به عنوان «DRIFT» برچسب می‌زند. این صداقت از کرش‌های محیط عملیاتی که ناشی از تکیه بر یک منبع واحد و احتمالاً قدیمی است، جلوگیری می‌کند.

حفاظ‌های فنی و پیش‌گیرنده‌ها

برای جلوگیری از اینکه مدل زبانی در مرحله نهایی تولید متن، عددی را «توهم» (Hallucinate) کند، توسعه‌دهنده یک تابع حفاظ (Guard function) پیاده کرد. Nova Pro ابزارها را اجرا می‌کند و جمله را می‌نویسد، اما اجازه ندارد درباره عدد نهایی تصمیم بگیرد. یک تابع ساده مقدار را تطبیق می‌دهد و یک حفاظ، پاسخ مدل را با آن چک می‌کند. اگر مدل در بیان کلمات دچار اشتباه شود یا عدد را تغییر دهد، حفاظ متن مدل را دور ریخته و آن را با پاسخ خام و قطعی جایگزین می‌کند.

سیستم همچنین خطاهای مدل را از طریق کشینگ سمت سرور و منطق تلاش مجدد (Retry) مدیریت می‌کند:

• شکست در آرگومان‌های ابزار: زمانی که Nova Pro با وجود دریافت موفقیت‌آمیز داده‌ها، یک رشته خالی را به reconcile_facts پاس داد، حفاظ سیستم را به حالت «تأیید نشده» (Not verified) برد. این مشکل با کش کردن آخرین دریافت واقعی در سمت سرور حل شد.
• حدس زدن FactType: یک بار مدل Nova حدس زد که فیلد instanceType است در حالی که در واقع regionalAvailability بود و باعث شد حقیقت ناپدید شود. اکنون سیستم اگر یک جست‌وجوی تایپ‌شده صفر ردیف برگرداند، تلاش مجددی را تنها با استفاده از سرویس و منطقه انجام می‌دهد.

ردپای ابزارها مسیر عبور از Sanity را در هر پرسش ثابت می‌کند: knowledge_base_search $\rightarrow$ knowledge_base_read $\rightarrow$ fetch_candidate_facts $\rightarrow$ reconcile_facts $\rightarrow$ verify_live.

بازاستفاده از این الگو

این معماری، عامل هوشمند را از یک رابط جست‌وجو به یک موتور تأیید (Verification Engine) تبدیل می‌کند. این رویکرد، هوشمندی را از «پرامپت» به «ساختار داده» منتقل می‌کند و ثابت می‌کند که قابل‌اعتمادترین خروجی‌های هوش مصنوعی از سخت‌گیرانه‌ترین طرحواره‌های داده حاصل می‌شوند. پیروزی در اینجا نه به دلیل مدل هوشمندتر، بلکه به دلیل محتوای ساختاریافته و شجاعت سیستم در گفتن این جمله بود که: «رکورد می‌گوید ۵، اما واقعیت می‌گوید ۱۶».

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

گام بعدی شما

• اگر از عامل‌های هوشمند برای مدیریت زیرساخت استفاده می‌کنید، داده‌های خود را از متن خام به طرحواره‌های تایپ‌شده (Typed Schemas) منتقل کنید.
• یک سلسله‌مراتب اولویت برای منابع داده‌های خود تعریف کنید تا مدل مجبور به حدس زدن نباشد.
• هرجا امکان‌پذیر است، خروجی مدل را با یک API زنده (System of Record) تطبیق دهید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.