توسعه‌دهندگان اکنون می‌توانند تضمین کنند که JSON بازگشتی از یک LLM با ساختاری از پیش تعریف‌شده مطابقت دارد؛ این کار با متصل کردن طرحواره‌های (schemas) Zod به Vercel AI SDK یا API استفاده از ابزار (tool-use) آنتروپیک (Anthropic) انجام می‌شود و از این طریق، کرش‌های زمان اجرا (runtime crashes) را که هنگام اضافه شدن یک فیلد غیرمنتظره توسط مدل رخ می‌دهند، از بین می‌برد.

نیاز به یک محافظ مشخص در ماه ژانویه آشکار شد، زمانی که یک طبقه‌بندی‌کننده (classifier) که به محیط عملیاتی (production) ارسال شده بود، پس از سه هفته عملکرد بی‌نقص، شروع به بازگرداندن کلید دوم "explanation" کرد. کد انتظار یک فیلد واحد را داشت، بنابراین کلید اضافی باعث بروز یک استثنا (exception) شد — بدون اینکه حتی یک بار کد جدید مستقر (deploy) شده باشد. این حادثه نشان‌دهنده یک مشکل گسترده‌تر است: بیشتر آموزش‌ها در مرحله JSON.parse(response) متوقف می‌شوند و فرض می‌کنند مدل از طرحواره (schema) پرامپت پیروی خواهد کرد. در واقعیت، LLMها مکرراً از مسیر خارج می‌شوند — با تغییر حروف کوچک و بزرگ، اضافه کردن فیلدها، یا قرار دادن خروجی در داخل فنس‌های مارک‌داون (markdown fences) — که منجر به فساد بی‌صدای داده‌ها یا شکست‌های کامل می‌شود.

چرا تجزیه خام JSON ناامن است

LLMها برای مفید بودن آموزش دیده‌اند، نه مطیع بودن. پرامپتی که درخواست

{ "category": "string" }

را دارد، مدل را به آن ساختار دقیق محدود نمی‌کند. حتی یک پرامپت خوش‌ساخت نیز می‌تواند توسط اکتشافات (heuristics) داخلی مدل نادیده گرفته شود، به‌ویژه زمانی که تنظیمات temperature باعث تشویق خلاقیت می‌شود یا زمانی که یک دستور پایین‌دستی آن را به توضیح بیشتر ترغیب می‌کند. نتیجه، جریانی از متن است که شبیه JSON به نظر می‌رسد اما آن‌قدر انحراف دارد که تجزیه‌کننده‌هایی (parsers) را که انتظار ساختاری دقیق دارند، از کار می‌اندازد.

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

Zod + Vercel AI SDK: یک شبکه ایمنی سه مرحله‌ای

Zod یک اعتبارسنج طرحواره (schema validator) با اولویت TypeScript است که می‌تواند شکل دقیق داده‌ای را که مدل باید تولید کند، توصیف کند. با ترکیب آن با راهنمای Output.object در Vercel AI SDK، اعتبارسنجی به‌طور خودکار پس از تولید پاسخ توسط مدل انجام می‌شود.

  1. تعریف طرحواره (schema) – یک شیء Zod بنویسید که منعکس‌کننده JSON مورد نظر باشد. برای یک طبقه‌بندی‌کننده ساده، این می‌تواند z.object({ category: z.string() }) باشد؛ برای یک استخراج‌کننده فاکتور پیچیده، طرحواره می‌تواند شامل اشیاء تو در تو، آرایه‌ها و اتحادیه‌های متمایز (discriminated unions) باشد.
  2. ارسال آن به SDK – طرحواره را با Output.object(schema) بسته‌بندی کنید. SDK پرامپتی را تزریق می‌کند که به مدل می‌گوید یک بلوک JSON مطابق با طرحواره خروجی دهد و نتیجه را با safeParse در Zod تجزیه می‌کند.
  3. مدیریت شکست‌ها – متد safeParse به جای پرتاب کردن استثنا، یک شیء نتیجه برمی‌گرداند. اگر تجزیه با شکست مواجه شد، خطا را به مدل بازگردانید و دوباره تلاش کنید. می‌توان به مدل دستور داد تا خروجی را بر اساس پیام دقیق اعتبارسنجی اصلاح کند و اکثر موارد خاص (edge cases) را به یک حلقه خود-اصلاح‌گر (self-healing loop) تبدیل کند.

از آنجایی که SDK عملیات پرامپت‌نویسی، تجزیه و منطق تلاش مجدد را در یک جا انجام می‌دهد، توسعه‌دهندگان تعدادی از دستکاری‌های رشته‌ای موردی (ad-hoc) را با یک فراخوانی واحد و دارای بررسی نوع (type-checked) جایگزین می‌کنند.

استفاده از ابزار در Anthropic: اجبار به خروجی ساختاریافته

هنگام کار مستقیم با API آنتروپیک، همین تضمین را می‌توان از طریق «استفاده از ابزار» (tool use) به دست آورد. یک ابزار به عنوان تابعی تعریف می‌شود که طرحواره ورودی آن در قالب JSON Schema بیان شده است؛ مدل آنتروپیک تنها زمانی ابزار را فراخوانی می‌کند که بتواند طرحواره را برآورده کند. با تنظیم tool_choice روی "any" (یا نام یک ابزار خاص)، مدل مجبور می‌شود به جای متن آزاد، یک بلوک ساختاریافته را بازگرداند.

گردش کار مشابه رویکرد Vercel است:

  • یک طرحواره Zod بنویسید.
  • آن را به یک محموله (payload) JSON Schema برای تعریف ابزار تبدیل کنید.
  • ابزار را در درخواست بگنجانید و مدل را ملزم به فراخوانی آن کنید.
  • پاسخ ابزار را با zod.safeParse تجزیه کنید.

اگر مدل همچنان داده‌های نامعتبر تولید کرد، همان الگوی «تلاش مجدد با بازخورد» اعمال می‌شود.

وقتی اعتبارسنجی همچنان با شکست مواجه می‌شود

حتی با اعمال طرحواره، گاهی اوقات عدم تطابق رخ می‌دهد. دلایل آن عبارتند از:

  • توهم مدل (Model hallucination): مدل ممکن است رشته‌ای تولید کند که شبیه JSON باشد اما حاوی خطاهای سینتکسی باشد.
  • نشت پرامپت (Prompt leakage): مراحل قبلی گفتگو می‌تواند دستورالعمل‌های قالب‌بندی را نشت دهد که درخواست طرحواره را نادیده می‌گیرند.
  • تفاوت‌های نسخه: نسخه‌های جدیدتر مدل گاهی نحوه تفسیر فراخوانی‌های ابزار را تغییر می‌دهند.

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

ملاحظات عملکرد و هزینه

افزودن اعتبارسنجی Zod بار اضافی ناچیزی بر پردازنده (CPU) تحمیل می‌کند؛ عملیات safeParse برای محموله‌های معمول در حد میکروثانیه اجرا می‌شود. تأخیر شبکه بدون تغییر باقی می‌ماند؛ رفت‌وبرگشت اضافی برای تلاش مجدد تنها در موارد نادرِ بروز خطا رخ می‌دهد. در عمل، هزینه جلوگیری از حتی یک استثنا (exception)، بسیار بیشتر از افزایش اندک در زمان درخواست است.

استدلال مخالف: آیا اعمال سخت‌گیرانه طرحواره (schema) زیاده‌روی است؟

برخی از توسعه‌دهندگان استدلال می‌کنند که طرحواره‌های سخت‌گیرانه، انعطاف‌پذیری مدل را محدود می‌کنند، به‌ویژه زمانی که فیلدهای جدید می‌توانند بافت (context) ارزشمندی ارائه دهند. این یک موازنه بین ایمنی و باز بودن است. در سرویس‌های حیاتی (mission-critical) مانند پردازش پرداخت، تأیید هویت و گزارش‌دهی انطباق (compliance reporting)، پیش‌بینی‌پذیری برتری دارد. در نمونه‌های اولیه اکتشافی (exploratory prototypes)، رویکردی منعطف‌تر ممکن است قابل قبول باشد، اما حتی در آنجا نیز یک محافظ حداقلی (مانند z.object({}).passthrough()) می‌تواند خطاهای فاجعه‌بارِ تجزیه (parsing) را بدون دور ریختن افزونه‌های مفید، شناسایی کند.

آنچه باید در ادامه دنبال کرد

  • تکامل SDK: نقشه راه Vercel’s AI SDK شامل سیاست‌های تلاش مجدد (retry) داخلی و گزارش‌دهی خطای غنی‌تر است که فرآیند اصلاح (repair loop) را بیش از پیش تسهیل می‌کند.
  • استانداردسازی ابزارها: با پذیرش قراردادهای استفاده از ابزار (tool-use conventions) توسط ارائه‌دهندگان بیشتر، ممکن است اعتبارسنج‌های طرحواره‌ی بین-ارائه‌دهنده (cross-provider) پدیدار شوند که نیاز به آداپتورهای مختص هر ارائه‌دهنده را کاهش می‌دهد.
  • الگوهای جامعه کاربری: کتابخانه‌های متن‌باز در حال بسته‌بندی طرحواره‌های Zod با قالب‌های پرامپت (prompt templates) هستند که جریان کاری «طرحواره‌محور» (schema-first) را به یک دارایی قابل استفاده مجدد تبدیل می‌کند.

نتیجه‌گیری

با در نظر گرفتن یک طرحواره Zod به عنوان قراردادی که مدل نمی‌تواند آن را نقض کند، توسعه‌دهندگان از ترفندهای شکننده JSON.parse به سمت یک خط لوله (pipeline) قطعی حرکت می‌کنند که در آن فیلدهای غیرمنتظره باعث شکست کنترل‌شده‌ی اعتبارسنجی می‌شوند، نه از کار افتادن سیستم در محیط عملیاتی (production crash). ترکیب کمک‌ساز Output.object از Vercel و مکانیسم استفاده از ابزار (tool-use) از Anthropic، مدل‌های زبانی بزرگ (LLMs) را از تولیدکنندگان متن غیرقابل پیش‌بینی به ارائه‌دهندگان داده قابل اعتماد تبدیل می‌کند و به تیم‌ها اجازه می‌دهد به جای عیب‌یابی بی‌پایان موارد خاص (edge-cases)، بر منطق کسب‌وکار تمرکز کنند.