پشتهٔ چهارلایه برای حذف خطاهای JSON در خروجی‌های مدل‌های زبانی

یک کامای اضافی یا یک کوتیشن فراموش‌شده در پاسخ مدل زبانی می‌تواند کل خط لوله تولید شما را در ساعت ۲ صبح متوقف کند. برای توسعه‌دهندگانی که برنامه‌های AI می‌سازند، هدف دیگر این نیست که مدل «سعی کند» JSON برگرداند، بلکه باید پشته‌ای از قابلیت‌های اطمینان پیاده کنند که خروجی را تضمین کند. به نقل از راهنمای فنی AI Frontier Post، دستیابی به این سطح از پایداری نیازمند چهار لایه مجزا از نظارت است: طراحی طرحواره (Schema)، اجبار در سطح ارائه‌دهنده، رمزگشایی محدود و حلقه‌های اعتبارسنجی.

بسیاری از توسعه‌دهندگان با روش «پرامپت و دعا» شروع می‌کنند؛ یعنی صرفاً از مدل می‌خواهند که در قالب JSON پاسخ دهد. این روش در محیط عملیاتی شکست می‌خورد چون مدل‌ها اغلب متن‌های توضیحی اضافه می‌کنند، در میانهٔ شیء به سقف توکن‌ها می‌رسند یا JSONی تولید می‌کنند که طرحواره مورد نیاز را نادیده می‌گیرد. این حالت‌های شکست شامل خطاهای نحوی (مثل کوتیشن‌های بدون Escape یا استفاده از Markdown Fences)، ساختارهای اشتباه (فیلدهای حذف‌شده یا تغییرنام‌یافته) و پاسخ‌های ایمنی است که کلاً طرحواره را نادیده می‌گیرند. همان‌طور که در تحلیل قبلی ما درباره‌ی TypeSafe AI Jev و تمرکزش بر مدل‌های تصمیم‌گیری محدود برای کاهش هزینه‌ها اشاره کردیم، صنعت اکنون به سمت محدودیت‌های ساختاری برای تضمین پایداری حرکت می‌کند. در واقع، تکیه بیش از حد به مدل‌ها برای مدیریت ساختارها می‌تواند منجر به ریسک‌های ساختاری در خط تولید نرم‌افزار شود که امنیت کل سیستم را به مخاطره می‌اندازد.

مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در حالت عادی احتمالی است، اما برای تبدیل آن به یک ابزار مهندسی، باید لایه‌های زیر را پیاده کرد:

لایه ۱: طراحی طرحواره (Schema Design)

اطمینان از صحت خروجی با داشتن یک «منبع واحد حقیقت» در کد شروع می‌شود. توسعه‌دهندگان باید از Pydantic (در پایتون) یا Zod (در جاوااسکریپت) برای تعریف طرحواره‌ها استفاده کنند تا محدودیت‌های درخواست و اعتبارسنج‌های پاسخ هرگز از هم فاصله نگیرند. به یاد داشته باشید طرحواره‌ای که بد طراحی شده، حتی اگر دقیقاً اجرا شود، باز هم خروجی بدی می‌دهد.

طرحواره‌های مؤثر از این قوانین سخت‌گیرانه پیروی می‌کنند:

• سخت‌گیر و صریح باشید: در OpenAI گزینه strict: true را فعال کنید، تمام کلیدها را در لیست required قرار دهید و additionalProperties را برابر false تنظیم کنید. این کار فرآیند را از «امید به همکاری مدل» به «اجبار در سمت سرور» تغییر می‌دهد.
• برای انتخاب‌های محدود از Enum استفاده کنید: تعریف فیلدی مثل "sentiment": {"type": "string", "enum": ["positive", "neutral", "negative"]} مانع از این می‌شود که مدل عباراتی مثل «تقریباً خوب» یا «عالی» ابداع کند.
• طرحواره‌ها را تخت (Flat) نگه دارید: تو در تو کردن‌های عمیق، بازگشت‌ها (Recursion) و محدودیت‌های عجیب، جایی است که حتی بهترین ارائه‌دهندگان هم دچار لغزش می‌شوند. هرچه طرحواره تخت‌تر باشد، نرخ موفقیت بالاتر است.
• توضیحات فیلدها را به عنوان پرامپت ببینید: توضیحات فیلدها تزئینی نیستند؛ آن‌ها مستقیماً به بخشی از دستورالعمل‌های مدل تبدیل می‌شوند.

برای مثال، یک مدل Pydantic آماده برای خلاصه‌سازی پشتیبانی باید شامل لیستی از مشکلات به صورت عبارات کوتاه و عیناً نقل‌شده (verbatim)، یک مقدار صریح برای احساسات و یک عدد اعشاری برای میزان اطمینان که بین ۰.۰ تا ۱.۰ محدود شده باشد، باشد.

لایه ۲: اجبار در سطح ارائه‌دهنده (Provider Enforcement)

آزمایشگاه‌های بزرگ AI اکنون قابلیت‌های اجبار در سمت سرور را برای تضمین شکل خروجی ارائه می‌دهند. OpenAI تمیزترین پیاده‌سازی را از طریق responses.parse() ارائه می‌دهد که یک مدل Pydantic می‌گیرد و مستقیماً یک شیء تایپ‌شده برمی‌گرداند و نیاز به کد دستی برای تجزیه (Parsing) را حذف می‌کند. البته توسعه‌دهندگان باید توجه داشته باشند که اولین درخواست با یک طرحواره جدید ممکن است به دلیل پردازش API، تأخیر (Latency) بیشتری داشته باشد.

سایر ارائه‌دهندگان از مکانیزم‌های متفاوتی استفاده می‌کنند:

• Google Gemini: از response_schema و response_mime_type: "application/json" برای بازگرداندن JSONهای دقیقاً اعتبارسنج‌شده استفاده می‌کند.
• Anthropic (Claude): ساختار را از طریق استفاده از ابزار (Tool Use) تحمیل می‌کند. توسعه‌دهنده ابزاری با input_schema تعریف کرده و با tool_choice مدل را مجبور به استفاده از آن می‌کند و سپس آرگومان‌های ابزار را به عنوان شیء نهایی می‌خواند.
• AWS Bedrock: از toolConfig در Converse API همراه با یک JSON schema استفاده می‌کند که از طریق toolChoice اجباری می‌شود. این رویکرد، روشی مستقل از مدل (Model-agnostic) را برای مدل‌های مختلف میزبانی‌شده فراهم می‌کند.
• Mistral: گزینه response_format: {"type": "json_object"} را ارائه می‌دهد. این گزینه نحو (Syntax) JSON را تضمین می‌کند اما لزوماً پایبندی به یک طرحواره خاص را تضمین نمی‌کند و نیازمند اعتبارسنجی در سمت کلاینت است.

لایه ۳: رمزگشایی محدود برای میزبانی شخصی (Constrained Decoding)

برای کسانی که مدل‌های وزن‌های باز (Open Weights) — مثل Llama، Qwen یا Mistral — را روی GPUهای شخصی اجرا می‌کنند، APIهای ارائه‌دهنده در دسترس نیست. راهکار این است: رمزگشایی (Decoding) محدود یا تولید ساختاریافته، که احتمالاً قابل‌اعتمادترین رویکرد در میان تمام روش‌هاست.

در این روش، به‌جای اعتبارسنجی خروجی پس از تولید، ساختار در لحظه تولید توکن (Token) — تکه‌های کوچکی از متن که مدل تکه‌تکه تولید می‌کند — تحمیل می‌شود. در هر گام، نمونه‌بردار (Sampler) توکن‌هایی را که باعث نقض طرحواره می‌شوند، ماسک کرده و مسدود می‌کند. اگر توکن بعدی طبق طرحواره باید یک عدد باشد، تمام توکن‌های شروع‌کننده رشته‌ها به‌طور کامل مسدود می‌شوند. در نتیجه، مدل فقط می‌تواند دنباله‌هایی را نمونه‌برداری کند که با طرحواره سازگار باشند و خروجی نهایی ذاتاً بدون نیاز به تلاش مجدد، با ساختار مطابقت دارد.

ابزارهای کلیدی این لایه:

• کتابخانه‌ها: Outlines، Microsoft Guidance و XGrammar.
• سرورهای استنتاج: vLLM و SGLang تولید ساختاریافته را به‌صورت داخلی پشتیبانی می‌کنند. به‌طور خاص، vLLM در درخواست‌ها مقادیر structured_outputs: {"json": schema} یا {"regex": "..."} را می‌پذیرد.
• محدودیت‌های Regex: برای رشته‌هایی با فرمت ثابت — مانند کدهای سفارش، تاریخ‌ها یا شناسه‌ها (IDs) — استفاده از محدودیت Regex سبک‌تر از یک طرحواره کامل و به همان اندازه نفوذناپذیر است.

لایه ۴: حلقه اعتبارسنجی و ترمیم (Validation-and-Repair Loop)

حتی با وجود اجبارهای بومی، آخرین لایه حفاظتی، یک حلقه ترمیم غیرقابل‌اجتناب است. محدودیت‌ها هنوز می‌توانند توسط پاسخ‌های ایمنی (Safety Refusals) یا قطع شدن متن به دلیل سقف توکن‌ها شکسته شوند. فرآیند به این صورت است: تولید $ \rightarrow $ اعتبارسنجی $ \rightarrow $ ترمیم.

وقتی اعتبارسنجی Pydantic خطای ValidationError می‌دهد، پیام دقیق خطا (مثلاً «فیلد confidence گم شده است» یا «عدد اعشاری مورد نیاز بود اما رشته دریافت شد») به مدل بازگردانده می‌شود. مدل‌ها در اصلاح اشتباهات دقیقاً توصیف‌شده بسیار توانمند هستند و بیشتر شکست‌های گذرا در یک تلاش مجدد حل می‌شوند. این رویکرد ترمیم خودکار، مشابه سیستم‌های اتوماسیون رفع خطای مدل‌های زبانی است که با ترکیب مدل‌های پیشرفته‌ای مثل Qwen 3، فرآیند دیباگینگ را به شدت تسریع می‌کنند.

برای ایمن‌سازی این فرآیند در محیط عملیاتی، توسعه‌دهندگان باید این انضباطات را رعایت کنند:

• تعداد تلاش‌ها را محدود کنید: بازتلاش‌ها را به ۲ تا ۴ بار محدود کنید. یک حلقه نامحدود، خطری برای هزینه و تأخیر است؛ اگر مدلی سه بار شکست خورد، این یک مشکل در طراحی طرحواره است، نه یک اتفاق تصادفی.
• خطای ساختاریافته برگردانید، نه خطای شدید: وقتی تلاش‌ها به پایان رسید، به‌جای یک Exception مدیریت‌نشده که کل درخواست را متوقف کند، یک شیء خطای ساختاریافته یا یک مقدار پیش‌فرض امن برگردانید.
• طرحواره را اصلاح کنید: شکست‌های مکرر در یک فیلد خاص به این معناست که طرحواره مبهم یا بیش از حد پیچیده است. آن را تخت کنید، یک مثال اضافه کنید یا استخراج داده را به فراخوانی‌های کوچک‌تر تقسیم کنید.

الگوهای اشتباهی که باید کنار بگذارید

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

• استفاده مستقیم از json.loads(resp): این روش فاقد بررسی طرحواره است و با هر خطای کوچک در نحو، کرش می‌کند. آن را با خروجی‌های بومی طرحواره و تجزیه اعتبارسنج‌شده جایگزین کنید.
• پاک‌سازی Markdown با Regex: رگکس نمی‌تواند JSONهای تو در تو یا Escape شده را به‌طور قابل‌اعتماد تجزیه کند. به‌جای آن، خروجی Raw JSON بخواهید و درخواست برای خروجی‌های محصور در Fences را متوقف کنید.
• حالت JSON بدون طرحواره: استفاده از JSON Mode بدون Schema، نحو را تضمین می‌کند اما شکل (Shape) خروجی را نه. آن را با خروجی‌های محدود به طرحواره یا حلقه اعتبارسنجی و بازتلاش جایگزین کنید.
• دسترسی مستقیم به دیکشنری: استفاده از data["field"] در صورت نبود فیلد منجر به KeyError می‌شود. ابتدا داده را به یک مدل تایپ‌شده تبدیل کنید و سپس به ویژگی‌ها (Attributes) دسترسی پیدا کنید.

این تغییر رویکرد، ادغام مدل‌های زبانی را از یک قمار احتمالی به یک وظیفه مهندسی دترمینیستیک تبدیل می‌کند. با جایگزینی json.loads() با یک خط لوله تایپ‌شده و اعتبارسنج‌شده، تیم‌ها می‌توانند پایداری سیستم خود را تا ۹۹٪ (بهبود دو نُه) افزایش دهند. برای کسانی که استقرارها در مقیاس بالا را مدیریت می‌کنند، گام بعدی ممیزی پرامپت‌های موجود برای جایگزینی درخواست‌های JSON محصور در Markdown با اجبار بومی طرحواره است تا هزینه توکن و تأخیر کاهش یابد.

گام بعدی شما

• پرامپت‌های فعلی خود را بررسی کنید و درخواست‌های JSON که در بلوک‌های Markdown محصور شده‌اند را با اجبار بومی طرحواره (Native Schema Enforcement) جایگزین کنید تا هزینه توکن و تأخیر کاهش یابد.
• برای مدل‌های میزبانی‌شده، کتابخانه Pydantic را به عنوان لایه اعتبارسنجی اجباری در ورودی و خروجی قرار دهید.
• در صورت استفاده از مدل‌های بازمتن، سرور vLLM را برای بهره‌مندی از تولید ساختاریافته (Structured Generation) بررسی کنید.

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