تولید سینتکس نامعتبر اکنون بهطور ساختاری غیرممکن شده است. این واقعیت جدیدی است برای ویژگیهای هوش مصنوعی در محیطهای عملیاتی (Production)، که دیگر بر این امید تکیه نمیکنند که یک مدل صرفاً از یک پرامپت پیروی کند. تا ۳۱ جولای ۲۰۲۶، تغییر رویکرد به سمت تولید محدودشده با طرحواره (Schema-constrained generation)، خروجیهای ساختاریافته را از یک ترفند پرامپتنویسی به یک تضمین فنی در سطح API تبدیل کرد. به جای اینکه از مدل خواهش کنیم خروجی JSON برگرداند، محدودیتهای سمت ارائهدهنده مانع از تولید هر چیزی بهجز دادههای معتبر و مطابق با طرحواره میشود.
دریافت یک جمله ساده از مدل آسان است، اما تضمین اینکه مدل هر بار یک شیء JSON دقیق — مثلاً {"status": "approved", "confidence": 0.87} — بدون متن اضافی، بدون فیلدهای گمشده و بدون تایپهای نامعتبر برگرداند، تا پیش از این بزرگترین نقطه اصطکاک در عرضه ویژگیهای جدید بود. این مانع فنی اکنون توسط غولهایی مثل OpenAI، Anthropic و Google در لایه API حل شده است. همانطور که در تحلیل قبلی ما دربارهی نحوه تولید کد در زمان اجرا توسط JetBrains KotlinLLM اشاره کردیم، این تغییر سیستمی در قابلیت اطمینان خروجیها به توسعهدهندگان اجازه میدهد تا با پاسخهای مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — نه بهعنوان متنی غیرقابلپیشبینی، بلکه بهعنوان قراردادهای پایدار API برخورد کنند.
معنای واقعی «خروجی ساختاریافته»
خروجی ساختاریافته به هر تکنیکی اشاره دارد که پاسخ مدل را به شکلی قابلپیشبینی و قابلتجزیه توسط ماشین محدود میکند. بهطور معمول، این خروجی یک JSON است که با طرحواره (Schema) تعریفشده توسط توسعهدهنده مطابقت دارد، نه یک متن آزاد. در یک محیط عملیاتی، این پیشبینیپذیری تفاوت بین ویژگیای است که فقط در یک دمو کار میکند و ویژگیای که در مقیاس واقعی دوام میآورد.
سه سطح دستهبندی ساختار
بر اساس راهنمای dev.to، در حال حاضر سه رویکرد مجزا برای دستیابی به خروجی ساختاریافته وجود دارد. این روشها جایگزین یکدیگر نیستند، زیرا هر کدام بخشی از مشکل قابلیت اطمینان را حل میکنند:
JSON پرامپتمحور: این همان رویکرد «لطفاً فقط در قالب JSON پاسخ بده» در پرامپت سیستمی است. در اینجا هیچ اجباری در سمت ارائهدهنده وجود ندارد. اگرچه این روش در مدلهای توانمند بیشتر اوقات جواب میدهد، اما در معرض چندین حالت شکست است:
- قرار گرفتن JSON در بلوکهای کد Markdown (Code Fences).
- وجود متون مقدماتی مانند «حتماً، این هم JSON درخواستی شماست:» پیش از دادهها.
- حذف فیلدهایی که مدل آنها را کماهمیت تشخیص داده است.
- تولید JSON معتبر اما با تایپهای اشتباه (مثلاً وقتی یک عدد به جای رشته ارسال شود، یا مقدار null به جای یک آرایه قرار گیرد).
- نتیجه: این روش باید تنها بهعنوان یک مسیر پشتیبان (Fallback) برای ارائهدهندگان یا مدلهایی که تضمینهای قویتری ندارند استفاده شود، نه به عنوان استراتژی اصلی برای ویژگیهای کاربر-محور. در صورت استفاده، همیشه عملیات پارسینگ را در یک بلوک try/catch قرار دهید و بلوکهای مارکداون را بهطور تدافعی حذف کنید.
رمزگشایی محدودشده (JSON Mode): این روش در سطح نمونهگیری توکن (Token Sampling) عمل میکند. ارائهدهنده محدود میکند که مدل در هر مرحله چه توکنی را انتخاب کند، تا سینتکس نامعتبر بهطور ساختاری غیرممکن شود. در اینجا دو سطح وجود دارد:
- حالت JSON (JSON mode): تضمین میکند JSON از نظر سینتکسی معتبر باشد، اما لزوماً یک طرحواره خاص را تضمین نمیکند. شما همچنان ممکن است یک
{}خالی یا یک شیء JSON با کلیدهای اشتباه دریافت کنید. - JSON محدودشده با طرحواره (Strict Mode): هم اعتبار سینتکسی و هم انطباق مطلق با یک طرحواره ارسالی (معمولاً JSON Schema) را تضمین میکند. این حالت تضمین میکند که فیلدهای اجباری حضور داشته باشند، تایپها مطابقت کنند و مقادیر Enum رعایت شوند. این قویترین تضمین موجود بدون نیاز به یک مرحله اعتبارسنجی دوم است، زیرا محدودیت «هنگام تولید» رخ میدهد، نه بعد از آن.
- حالت JSON (JSON mode): تضمین میکند JSON از نظر سینتکسی معتبر باشد، اما لزوماً یک طرحواره خاص را تضمین نمیکند. شما همچنان ممکن است یک
فراخوانی تابع/ابزار (Function/Tool Calling): در این حالت به مدل گفته میشود که به توابع خاصی دسترسی دارد و باید تصمیم بگیرد آیا و چگونه آنها را فراخواند. مدل یک فراخوان ساختاریافته با آرگومانهایی برمیگرداند که با طرحواره پارامترهای تابع مطابقت دارد و ارائهدهنده پیش از بازگرداندن آن، اعتبارسنجی را انجام میدهد. این بهترین انتخاب برای زمانی است که مدل باید تصمیم بگیرد «آیا» خروجی ساختاریافته تولید کند یا با متن ساده پاسخ دهد.
مقایسه فنی رویکردها
برای درک بهتر فرآیند انتخاب، این تفکیک فنی را در نظر بگیرید:
- JSON پرامپتمحور: بدون تضمین سینتکس، بدون تضمین طرحواره. مناسب برای پروتوتایپها یا مسیرهای غیرحیاتی.
- حالت JSON: سینتکس تضمین شده است، اما طرحواره خیر. ایدهآل برای استخراج متون ساختاریافته منعطف.
- JSON سختگیرانه (Strict): هر دو سینتکس و طرحواره تضمین شدهاند. بهترین گزینه برای خطوط لوله داده (Data Pipelines)، طبقهبندی و کارهای استخراج.
- فراخوانی تابع / ابزار: هر دو سینتکس و طرحواره تضمین شدهاند. ضروری برای تصمیمات عاملمحور (Agentic) و جریانهای چند-عملیاتی.
تا سال ۲۰۲۶، تولید سختگیرانه با طرحواره بهطور گسترده از طریق Structured Outputs در OpenAI، اجرای طرحواره ابزار-محور در Anthropic و پارامتر response schema در Gemini پشتیبانی میشود. با این حال، توسعهدهندگان باید مستندات فعلی ارائهدهندگان را بررسی کنند زیرا سطح پشتیبانی بر اساس لایه (Tier) مدل در یک خانواده واحد متفاوت است.
مهندسی طرحواره
استفاده از یک طرحواره سختگیرانه فقط مربوط به فراخوان API نیست؛ بلکه نیازمند این است که با طرحواره بهعنوان یک قرارداد رسمی API برخورد کنید. چون مدل در واقع یک فراخواننده غیرقابلاعتماد برای این قرارداد است، تصمیمات طراحی زیر برای کاهش توهم (Hallucination) — شبیه دوستی که خاطرهای را اشتباه تعریف میکند — ضروری است:
- به حداقل رساندن فیلدهای اجباری: هر فیلد اجباری، فرصتی برای توهم مدل است اگر اطلاعات مورد نیاز در منبع داده موجود نباشد.
- استفاده از فیلدهای اختیاری: فیلدها باید در هر جایی که وضعیت «نامشخص» (Unknown) یک حالت معتبر است، اختیاری شوند.
- ترجیح Enum بر String: استفاده از مقادیر ثابت — مثلاً
"status": "approved" | "rejected" | "pending"— بسیار قابلاعتمادتر از فیلدهای رشتهای باز است که نیاز به نرمالسازی دستی دارند. - تخت کردن ساختارها (Flattening): از JSONهای عمیق و تودرتو دوری کنید. تودرتویی زیاد احتمال خطاهای ظریف در شکل داده را افزایش داده و پارسینگ در مراحل بعدی را شکنندهتر میکند.
- افزودن فیلدهای متا: برای کارهای حساس، فیلدهایی مانند «میزان اطمینان» (confidence) یا «استدلال» (reasoning) اضافه کنید. این کار سیگنالی فراهم میکند تا بفهمید چه زمانی پاسخ باید به بازبینی انسانی هدایت شود و چه زمانی بهطور خودکار پذیرفته شود.
- نسخهبندی طرحوارهها: بهروزرسانی طرحواره را مانند تغییرات شکستدهنده (Breaking Changes) در API مدیریت کنید. افزودن یک فیلد اجباری جدید باعث میشود پاسخهای کششده قدیمی یا تلاشهای مجدد (Retries) که بر اساس طرحواره قدیمی ساخته شدهاند، در اعتبارسنجی شکست بخورند.
ضرورت اعتبارسنجی در زمان اجرا
بهرغم تضمینهای سطح API از سوی ارائهدهندگان، راهنمای فنی بر حفظ یک لایه اعتبارسنجی در زمان اجرا با ابزارهایی مثل Zod، Pydantic یا معادلهای زبانی دیگر تأکید دارد. این موضوع به دلایل زیر حیاتی باقی میماند:
- یکپارچگی مسیر پشتیبان (Fallback Integrity): قطعی ارائهدهنده یا استفاده از مدلهای جایگزین ممکن است منجر به استفاده از لایهای شود که شامل اجرای سختگیرانه طرحواره نباشد. اگر کد بهطور کورکورانه به شکل داده اعتماد کند، دادههای تغییرشکلیافته به مراحل بعدی منتقل میشوند. برای مثال، پلتفرم SpaceAI360 برای حذف توقفهای API از ترکیب Zod و یک لایه پاکسازی استفاده میکند تا پایداری دادهها را در Next.js تضمین نماید.
- صحت معنایی در برابر سینتکسی: یک مدل میتواند یک شیء JSON از نظر سینتکسی کامل تولید کند که از نظر معنایی بیمعنی است. برای مثال، ممکن است مقدار
"confidence": 1.4را برگرداند در حالی که بازه مورد انتظار ۰ تا ۱ است، یا یک تاریخ را برگرداند که از نظر داخلی متناقض است. - استراتژیهای چندارائهدهنده: تا سال ۲۰۲۶، استفاده از چندین ارائهدهنده برای کاهش هزینه و افزایش قابلیت اطمینان رایج شده است. طرحوارهای که در یک ارائهدهنده بهطور سختگیرانه اجرا میشود، ممکن است در ارائهدهنده دیگری که در زمان شکست به آن سوییچ میکنید، بهطور منعطف اجرا شود یا اصلاً پشتیبانی نشود.
ادغام در جریانهای عاملمحور
برای سامانههای مبتنی بر عامل (Agent)، خروجیهای ساختاریافته مکانیسم اصلی تصمیمگیری هستند، زیرا هر گام در یک زنجیره چندمرحلهای باید یک تصمیم ماشینخوان را به گام بعدی منتقل کند.
- لایه مسیریابی (Routing Layer): از فراخوانی تابع برای لایه مسیریابی استفاده کنید. این کار به مدل اجازه میدهد ابزار درست را با آرگومانهایی که در برابر طرحواره خاص آن ابزار اعتبارسنجی شدهاند، انتخاب کند.
- مدیریت زمینه: خروجیهای ساختاریافته میانی را کوچک نگه دارید. انتقال بلوکهای بزرگ داده بین گامهای عامل، مصرف پنجره متنی (Context Window) — مثل میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — و هزینهها را افزایش میدهد. فقط آنچه گام بعدی بهطور خاص نیاز دارد را استخراج کنید.
- قابلیت عیبیابی (Debuggability): تمام تصمیمات ساختاریافته در زنجیره را لاگ کنید. وقتی یک عامل پاسخ نهایی اشتباهی میدهد، این خروجیهای میانی اجازه میدهند توسعهدهندگان دقیقاً بفهمند کدام گام شکست خورده است، به جای اینکه بر اساس پاسخ نهایی غیرساختاریافته حدس بزنند.
استراتژی شکست و بازیابی
حتی با اجرای سختگیرانه، سامانههای تجاری باید برای موارد شکست احتمالی طراحی شوند — خواه به دلیل محدودیتهای نرخ درخواست (Rate Limits) که مدل را به نسخهای ضعیفتر سوق میدهد، حوادث سمت ارائهدهنده، یا ورودیهای مبهم باشد. یک مسیر بازیابی سهمرحلهای توصیه شده شامل موارد زیر است:
۱. اعتبارسنجی: هر پاسخ را بلافاصله پس از دریافت از یک اعتبارسنج رانتایم عبور دهید.
۲. تلاش مجدد (Retry): در صورت شکست اعتبارسنجی، یک بار دیگر تلاش کنید. از یک پرامپت صریحتر یا حالت اجرای سختگیرانهتر (اگر قبلاً فعال نبود) استفاده کنید. در این مرحله، استفاده از مدلهای Typed Outcome برای بهینهسازی بازیابی خطا میتواند جایگزینی قدرتمند برای ساختارهای سادهی try-catch باشد.
۳. پشتیبان امن (Safe Fallback): اگر تلاش دوم شکست خورد، درخواست را به صف بازبینی انسانی یا یک وضعیت پیشفرض امن بفرستید، تا اینکه یک تجربه خراب را به کاربر نمایش دهید.
برخورد با شکستهای خروجی ساختاریافته مانند برخورد با APIهای شخص ثالثِ ناپایدار است؛ جایی که خطاها پیشبینی شده و صریحاً مدیریت میشوند. لاگ کردن پاسخهای خامِ هر اعتبارسنجی شکستخورده، سریعترین راه برای شناسایی پسرفتهای مدل (Regressions) یا عدم تطابق طرحواره است، پیش از آنکه کاربران گزارش دهند.
راهنمای تصمیمگیری برای پیادهسازی
اگر در انتخاب رویکرد برای یک ویژگی جدید تردید دارید، این سوالات را بپرسید:
- آیا مدل باید تصمیم بگیرد اقدام کند یا فقط استخراج/طبقهبندی کند؟ اگر در حال تصمیمگیری بین اقدامات است $\rightarrow$ از فراخوانی تابع استفاده کنید.
- آیا خروجی مستقیماً وارد منطق اپلیکیشن یا پایگاهداده میشود؟ اگر بله $\rightarrow$ از JSON سختگیرانه استفاده کنید، نه JSON پرامپتمحور.
- آیا این یک پروتوتایپ کم-ریسک است؟ JSON پرامپتمحور با یک لایه اعتبارسنجی برای سرعت کافی است، اما پیش از عرضه گسترده، ارتقا الزامی است.
- آیا روی چندین ارائهدهنده اجرا میشوید؟ تأیید کنید که هر مدل در زنجیره پشتیبان شما از سطح مورد نیاز اجرای طرحواره پشتیبانی میکند.
پرسشهای متداول
آیا هنوز به JSON schema نیاز دارم در حالی که مدل بهندرت اشتباه میکند؟
بله. «بهندرت» در مقیاس بالا همچنان یک نرخ شکست واقعی است. هزینه رسیدن یک شیء نامعتبر و اعتبارسنجینشده به پایگاه داده یا صفحه نمایش کاربر، معمولاً بسیار بیشتر از هزینه افزودن یک مرحله اعتبارسنجی است.
آیا فراخوانی تابع کندتر از حالت JSON ساده است؟
تفاوتهای تأخیر (Latency) معمولاً کوچک هستند و بیشتر به انتخاب مدل و طول پاسخ بستگی دارند تا خود مکانیسم. بهترین راه این است که مورد استفاده خاص خود را بنچمارک کنید.
آیا میتوانم خروجی ساختاریافته و غیرساختاریافته را در یک پاسخ ترکیب کنم؟
برخی ارائهدهندگان از این کار پشتیبانی میکنند (مثلاً فراخوانهای ابزار ساختاریافته در کنار توضیحات متنی آزاد)، اما این کار پیچیدگی پارسینگ را افزایش میدهد. اغلب تمیزتر است که از یک فراخوان مجزا یا یک فیلد اختصاصی برای توضیحات استفاده کنید.
اگر بعداً فیلد اجباری جدیدی به طرحواره اضافه کنم چه اتفاقی میافتد؟
با آن مانند یک تغییر شکستدهنده (Breaking Change) برخورد کنید. هرگونه پاسخ کششده، تلاشهای مجدد یا لاگهایی که با طرحواره قدیمی تولید شدهاند، ممکن است شرط فیلد اجباری جدید را برآورده نکنند. طرحوارههای خود را نسخهبندی کنید یا فیلدهای جدید را با پیشفرضهای معقول، اختیاری کنید.
با تکامل زیرساختهای مدلهای زبانی، توسعهدهندگان بالاخره میتوانند از مهندسی تدافعی پرامپتها فاصله بگیرند. تمرکز از «چگونه پرسیدن» به «چگونه اعتبارسنجی و مسیریابی کردن» تغییر کرده است. با تبدیل طرحواره به یک قرارداد رسمی API، ویژگیهای هوش مصنوعی به زیرساختهایی خستهکننده و قابلاعتماد تبدیل میشوند — و این دقیقاً هدف نهایی هر سامانه تجاری است.
اکنون که خروجی ساختاریافته به یک مسئله حلشده تبدیل شده است، چالش بعدی بهینهسازی تأخیر و هزینه این محدودیتها در زنجیرههای پشتیبان چندمدلی است. اگر در حال ساخت یک ابزار توسعهدهنده یا محصول هوش مصنوعی هستید و بازخورد اولیه و یک پروفایل نمایهشده رایگان میخواهید، آن را در makers.page ثبت کنید. استفاده واقعی، بازخورد واقعی و در صورت تناسب، یک لینک dofollow دریافت خواهید کرد.
گفتگو