JSON معتبر، تصمیم غلط: قرارداد خروجی هوش مصنوعی

یک مدل استخراج، دستور نگهداری کاملاً خوش‌ساختی برمی‌گرداند. JSON بدون خطا تجزیه می‌شود، همه فیلدهای اجباری حاضرند، فوریت یکی از مقادیر مجاز است و زمان با قالب خواسته‌شده سازگار است. با این حال، محموله غلط است: مدل شناسه تجهیز را از پیوست قبلی برداشته، عبارت «توقف بعدی» را امروز تفسیر کرده و اقدامی پیشنهاد داده که تکنسین درخواست‌کننده اجازه آن را ندارد.

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

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

ساختار فقط یک ویژگی است، نه حکم نهایی

«خروجی ساخت‌یافته» چند وعده متفاوت را زیر یک نام پنهان می‌کند:

مرور JSON Schema 2020-12 یک گویش و فراطرح‌واره مشخص را معرفی می‌کند. واژگان اعتبارسنجی آن گزاره‌های ساختاری مانند نوع و مقدار شمارشی را تعریف می‌کند و توضیح می‌دهد که format ممکن است فقط حاشیه‌نویسی باشد، نه الزام اجرایی. پس حتی یک اعتبارسنج منطبق با استاندارد نیز به گویش، واژگان پشتیبانی‌شده و تنظیمات صریح نیاز دارد.

امکانات ارائه‌دهندگان محدودتر هم هستند. راهنمای خروجی ساخت‌یافته OpenAI زیرمجموعه پشتیبانی‌شده، تأخیر پردازش طرح‌واره و پاسخ‌های استثنایی مانند امتناع یا تولید ناقص را مستند می‌کند. راهنمای Gemini گوگل صریحاً توصیه می‌کند مقادیر در کد برنامه اعتبارسنجی شوند، زیرا خروجی درست از نظر نحو می‌تواند از نظر معنا غلط بماند. مستند خروجی ساخت‌یافته Amazon Bedrock زیرمجموعه دیگری را فهرست می‌کند، ساختارهای پشتیبانی‌نشده را رد می‌کند و تدوین دستور زبان در نخستین استفاده را توضیح می‌دهد. عبارت «پشتیبانی از JSON Schema» یک قابلیت دودویی و قابل‌حمل نیست.

واقعیت‌های تأییدشده را از طراحی عملیاتی جدا کنید

منابع چهار واقعیت را پشتیبانی می‌کنند: JSON Schema به گویش و واژگان وابسته است؛ ارائه‌دهندگان زیرمجموعه‌هایی متفاوت پیاده می‌کنند؛ رمزگشایی مقید حالت‌های مرزی و هزینه تدوین دارد؛ و خروجی پایین‌دستی باید مانند ورودی امنیتی مدیریت شود. OWASP LLM05:2025 اعتبارسنجی ناکافی و نبود کدگذاری متناسب با مقصد پیش از رسیدن خروجی مدل به مرورگر، پایگاه داده، فایل یا فرمان را «مدیریت نامناسب خروجی» می‌داند.

قرارداد پنج‌دروازه زیر تحلیل ژرف برآمده از این واقعیت‌ها است؛ استانداردی نیست که JSON Schema، OpenAI، گوگل، AWS یا OWASP تعریف کرده باشند. این طراحی عمداً دغدغه‌هایی را جدا می‌کند که یک پرچم valid: true قادر به نمایش آن‌ها نیست:

1. دروازه ساختار: پاسخ کامل، نوع رسانه، سقف‌های تجزیه، نسخه درست قرارداد و انطباق با طرح‌واره.
2. دروازه معنا: قواعد دامنه، تمامیت ارجاعی، واحدها، منطق زمانی و سازگاری میان فیلدها.
3. دروازه شاهد: اتصال هر ادعای پیامددار به منبع مجاز و تازه.
4. دروازه سیاست: مجازبودن کنشگر، هدف، مستأجر، سطح ریسک و عملیات پیشنهادی.
5. دروازه اثر: کانونی‌بودن فرمان، تکرارپذیری امن در صورت نیاز و تأیید در سامانه ثبت رسمی.

محموله فقط پس از عبور از دروازه جاری پیش می‌رود. دروازه بعدی نمی‌تواند تضمین مفقود در مرحله قبلی را بعداً بسازد.

قرارداد را نسخه‌بندی کنید، نه فقط پرامپت را

قرارداد خروجی باید تمام مرز تفسیر را نام‌گذاری کند:

• contract_id و contract_version تغییرناپذیر؛
• گویش JSON Schema و واژگان الزامی؛
• هش طرح‌واره کانونی؛
• نمایه سازگاری هر ارائه‌دهنده و کلیدواژه‌های پشتیبانی‌نشده؛
• نام، نسخه و تنظیمات اعتبارسنج برنامه؛
• نسخه قواعد معنایی و داده‌های مرجع؛
• سیاست شاهد و مجوز؛
• انتشار تولیدکننده و دامنه سازگاری مصرف‌کننده؛
• زمان اجرا، زمان بازنشستگی و مالک.

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

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

نبودن و عدم‌قطعیت را وضعیت واقعی طراحی کنید

بسیاری از خطاهای معنایی از یک طرح‌واره به‌ظاهر راحت آغاز می‌شوند. رشته اجباری مدل را تشویق می‌کند وقتی منبع ساکت است چیزی بسازد. فیلد اختیاری تفاوت «یافت نشد»، «کاربرد ندارد»، «حذف شده»، «متناقض است» و «تولید شکست خورد» را از بین می‌برد. مقدار پیش‌فرض می‌تواند نبود شاهد را به دستور تجاری معتبر تبدیل کند.

نتیجه‌ای تفکیک‌شده بهتر است:

{
  "status": "supported | absent | ambiguous | conflicting",
  "value": "string or null",
  "evidence_refs": ["source fragment identifiers"],
  "reason_code": "controlled vocabulary or null"
}

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

در مرز اعتماد، ویژگی ناشناخته‌ای را که مصرف‌کننده نمی‌فهمد رد کنید. پاسخ خام را جداگانه برای بررسی نگه دارید، اما فیلد ناآشنا را وارد شیء اجرایی نکنید. تبدیل ضمنی مانند "1,000" به 1000، رشته غیرخالی به true یا زمان محلی بدون منطقه به UTC را نپذیرید. این تبدیل‌ها همان نقصی را پنهان می‌کنند که قرارداد باید آشکار سازد.

تولید را مقید و سپس مستقل اعتبارسنجی کنید

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

این توالی را به‌کار ببرید:

1. خود طرح‌واره را پیش از استقرار با گویش منتخب و نمایه ارائه‌دهنده اعتبارسنجی کنید.
2. اگر ارائه‌دهنده کارِ نخستین استفاده را مستند کرده، طرح‌واره تولید را پیش از ترافیک حساس به تأخیر گرم یا تدوین کنید.
3. با باریک‌ترین طرح‌واره پشتیبانی‌شده، توضیح‌های روشن و بدون فیلد آزاد اجرایی تولید کنید.
4. پیش از تجزیه، وضعیت پایانی را بررسی کنید: کامل، بریده، مردود، پالایش‌شده، منقضی یا نامعلوم در انتقال.
5. سقف بایت، عمق، طول رشته، طول آرایه و عدد را هنگام تجزیه اجرا کنید.
6. دوباره با اعتبارسنج تحت مالکیت برنامه و قرارداد کانونی ثابت اعتبارسنجی کنید.
7. سپس از دروازه‌های معنا، شاهد، سیاست و اثر عبور کنید.

اعتبارسنجی مستقل رأی عدم‌اعتماد به یک ارائه‌دهنده نیست؛ قرارداد پایدار مصرف‌کننده را میان ارائه‌دهندگان، SDKها، حالت‌های جریانی، دستورهای تدوین‌شده و انتشارهای بعدی حفظ می‌کند.

اعتبارسنجی معنایی را تا حد ممکن قطعی کنید

اعتبارسنج طرح‌واره شکل محلی را می‌بیند. اعتبارسنج دامنه باید رابطه‌ها و وضعیت جاری را بررسی کند. دستور نگهداری ممکن است از نظر نوع درست باشد اما تجهیز بازنشسته را نام ببرد، inspection_completed_at را پس از work_started_at قرار دهد، توقف را بیرون پنجره نگهداری بخواهد یا کلاس خطر را با روش ناسازگار ترکیب کند.

بررسی قطعی برای این موارد بنویسید:

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

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

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

اعتبارسنجی را از مجوز و اجرا جدا نگه دارید

فرمان معتبر الزاماً فرمان مجاز نیست. نام ابزار، آرگومان، هویت کاربر، موضوع تفویض‌شده، مستأجر، هدف، تأیید، سقف‌ها و وضعیت جاری باید در تصمیم سیاستی مستقل وارد شوند. مدل نباید فیلدهای مورد اعتماد مانند approved، role، tenant_id، policy_version یا idempotency_key را تعیین کند؛ برنامه آن‌ها را از وضعیت احراز هویت‌شده استخراج می‌کند.

پس از اعتبارسنجی معنا و شاهد، مرز مجوز ابزار را اعمال کنید. سپس آرگومان‌های مجاز را کانونی و از آداپتوری باریک وارد مرز اثر کنید. عملیات پایگاه داده را پارامتری سازید، برای مقصد کدگذاری کنید، مکان فایل و هدف شبکه را از فهرست مجاز بگیرید و SQL، فرمان پوسته، HTML یا نشانی تولیدشده را مستقیم به مفسر ندهید.

برای نوشتن پیامددار، نیت منطقی و کلید اقدام پایدارِ توضیح‌داده‌شده در راهنمای تلاش دوباره و تکرارپذیری امن را حمل کنید. پیش از مجوز اعتبارسنجی کنید؛ پیش از ارسال مجوز بگیرید؛ پس از ارسال نتیجه رسمی را تأیید کنید. اعتبارسنجی دوباره محموله ثابت نمی‌کند اقدام بیرونی انجام شده یا نشده است.

ترمیم را یک تلاش تازه و محدود بدانید

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

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

پایان‌های جداگانه تعریف کنید: accepted، rejected_structure، rejected_semantics، rejected_evidence، rejected_policy، abstained، expired و indeterminate_effect. با این کار پایش قابل‌اقدام می‌شود و هر شکست به حلقه عمومی تولید دوباره تبدیل نمی‌گردد.

مثال عملی: تریاژ نگهداری بدون توقف ناخواسته

یک خدمت نگهداری دوزبانه فرضی را در نظر بگیرید. تکنسین یادداشت بازرسی را بارگذاری و از دستیار می‌خواهد پیش‌نویس—نه اجرای—دستور کار را آماده کند. مدل می‌تواند asset_ref، finding، severity، requested_window، procedure_ref، evidence_refs و proposed_action تولید کند. مجوز یا فرمان نهایی در اختیار مدل نیست.

دروازه ساختار، فیلد ناشناخته، پاسخ بریده، نسخه ناسازگار قرارداد و مقدار شمارشی غیرمجاز را رد می‌کند. دروازه معنا asset_ref را در سایت احراز هویت‌شده حل می‌کند، سازگاری روش با بازبینی تجهیز را می‌سنجد، پنجره نگهداری و منطق شدت را بررسی می‌کند و برای مشاهده صرف، shutdown را ممنوع می‌سازد. دروازه شاهد برای هر یافته عکس تجهیز یا قطعه یادداشت می‌خواهد. دروازه سیاست بررسی می‌کند این تکنسین اجازه پیش‌نویس آن کلاس کار را دارد یا تأیید سرپرست لازم است.

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

اگر یادداشت فارسی بگوید «تا توقف بعدی صبر شود»، مدل اجازه ندارد از روی شباهت زبانی تاریخ مشخصی پر کند. تا وقتی رکورد برنامه توقف بازیابی و ارجاع نشده، وضعیت باید ambiguous باشد. زبان طبیعی مفید می‌ماند، اما وضعیت سامانه فرمان را تعیین می‌کند.

طرح‌واره را بدون رانش معنا تکامل دهید

هر تغییر را طبقه‌بندی کنید:

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

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

قرارداد را مانند مرز خصمانه آزمایش کنید

پژوهش سال ۲۰۲۵ JSONSchemaBench سامانه‌های رمزگشایی مقید را روی ۱۰ هزار طرح‌واره واقعی بررسی کرد و کارایی، پوشش قید و کیفیت خروجی را جدا سنجید. همین جداسازی برای تیم برنامه کاربردی مهم است: نرخ بالای انطباق با طرح‌واره فقط یک سنجه است.

مجموعه آزمون قرارداد باید شامل این موارد باشد:

• نمونه عادی، مرزی، خالی، دوزبانه و حداکثر اندازه؛
• جریان بریده، امتناع، شیء تکراری، عمق زیاد، رشته بزرگ و یونیکد نامعتبر؛
• کلید ناشناخته، آشفتگی نوع، دقت عددی، منطقه زمانی و دام زبان؛
• وضعیت ناممکن اما منطبق با طرح‌واره و ارجاع منقضی؛
• شاهد مفقود، متناقض، غیرمجاز یا آلوده به تزریق پرامپت؛
• جفت تولیدکننده و مصرف‌کننده قدیم/جدید و همه نمایه‌های ارائه‌دهنده؛
• محموله‌ای که برای تزریق HTML، SQL، پوسته، مسیر، نشانی یا لاگ تلاش می‌کند.

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

دروازه پذیرش

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

1. آیا نسخه قرارداد کانونی، گویش، هش طرح‌واره، اعتبارسنج و مالک قابل‌شناسایی است؟
2. آیا زیرمجموعه هر ارائه‌دهنده بدون تضعیف قواعد کانونی تدوین و آزمایش شده است؟
3. آیا نبودن، ابهام، تناقض و امتناع صریح نمایش داده می‌شود؟
4. آیا سقف تجزیه، رد فیلد ناشناخته و سیاست تبدیل نوع اجرا می‌شود؟
5. آیا بررسی قطعی معنا، هویت، واحد، زمان، وضعیت و قواعد میان‌فیلدی را پوشش می‌دهد؟
6. آیا هر مقدار پیامددار به شاهد جاری و مجاز وصل می‌شود؟
7. آیا هویت، سیاست، تأیید و کلید اقدام مورد اعتماد بیرون مدل ساخته می‌شود؟
8. آیا ترمیم محدود و ثبت می‌شود و اجازه تغییر معنا یا اختیار ندارد؟
9. آیا تکامل طرح‌واره و سازگاری تولیدکننده و مصرف‌کننده در هر دو جهت آزموده شده است؟
10. آیا اپراتور می‌تواند یک پاسخ خام را از تمام دروازه‌ها تا اثر رسمی دنبال کند؟

هرگاه ارائه‌دهنده زیرمجموعه پشتیبانی را تغییر داد، طرح‌واره یا توضیح ویرایش شد، اعتبارسنج ارتقا یافت، مصرف‌کننده تبدیل ضمنی را آغاز کرد، زبان یا منبع تازه‌ای وارد شد یا محموله به اقدام بیرونی دسترسی پیدا کرد، این دروازه را بازبینی کنید. هدف زیباترشدن JSON مدل نیست؛ هدف این است که عدم‌قطعیت ماشین‌خوان به اطمینان ماشین‌اجرا تبدیل نشود.

یادداشت منابع — بازبینی ۹ اوت ۲۰۲۶

• مرور JSON Schema Draft 2020-12 — منتشرشده در ۱۶ ژوئن ۲۰۲۲؛ منبع گویش، فراطرح‌واره، ساختار واژگان و تغییرات نسخه 2020-12.
• واژگان اعتبارسنجی JSON Schema 2020-12 — معنای گزاره‌های ساختاری و تفاوت میان حاشیه‌نویسی format و رفتار اختیاریِ الزام‌آور.
• OpenAI: خروجی ساخت‌یافته مدل — راهنمای زنده API، بازبینی‌شده در تاریخ انتشار؛ منبع زیرمجموعه پشتیبانی، پردازش طرح‌واره، پاسخ ناقص و امتناع.
• Google Gemini API: خروجی ساخت‌یافته — آخرین به‌روزرسانی ۳۰ ژوئیه ۲۰۲۶؛ منبع زیرمجموعه ارائه‌دهنده، مرز خروجی ساخت‌یافته و فراخوانی تابع، و اعتبارسنجی معنایی در برنامه.
• Amazon Bedrock: دریافت JSON اعتبارسنجی‌شده از مدل — مستند زنده، بازبینی‌شده در تاریخ انتشار؛ منبع قابلیت‌های پشتیبانی‌شده و پشتیبانی‌نشده، ورودی سخت‌گیرانه ابزار، تدوین و نهان‌سازی.
• OWASP LLM05:2025 مدیریت نامناسب خروجی — راهنمای امنیتی برای اعتبارسنجی، پاک‌سازی و کدگذاری متناسب با مقصد پیش از مصرف پایین‌دستی خروجی مدل.
• تولید خروجی ساخت‌یافته از مدل‌های زبانی: معیار و مطالعات — پیش‌چاپ پژوهش اصیل ژانویه ۲۰۲۵؛ معرفی JSONSchemaBench و ارزیابی ۱۰ هزار طرح‌واره در کارایی، پوشش و کیفیت.