اگر امروز برای استخراج دادههای حساس از مدلهای هوش مصنوعی استفاده میکنید، احتمالاً با یک شکست خاموش روبرو هستید که هیچ اعتبارسنجی (Validator) استانداردی آن را تشخیص نمیدهد. تضاد خطرناکی میان «ساختار درست» و «محتوای صحیح» در خروجیهای ساختاریافته (Structured Outputs) وجود دارد که میتواند کل سیستمهای اتوماسیون شما را به جایگاه اشتباهی بکشاند. اعتبار داشتن یک JSON به معنای درست بودن دادههای درون آن نیست.
به گزارش وبسایت dev.to در تاریخ ۲۵ اوت ۲۰۲۶، یک بنچمارک روی ۱۲ مدل تجاری نشان داد که در حالی که سوئیچهای خروجی ساختاریافته تضمین میکنند پاسخ نهایی قابل تجزیه (Parseable) باشد، اما وقتی مدلهای استدلالی در حالت «تفکر» قرار میگیرند، مقادیر واقعی داخل JSON تخریب میشوند. برای یک توسعهدهنده، این یک فاجعهی بیصداست؛ اعتبارسنج شما چراغ سبز میدهد چون شکل JSON بینقص است، اما اعدادی که برای مجموع فاکتور یا تعداد اقلام استخراج شدهاند، توهمآمیز یا از نظر ریاضی غلط هستند. این وضعیت یک ریسک تولیدی ایجاد میکند که در آن خطاها از تمام بررسیهای دفاعی سنتی عبور میکنند. این نوع توهمات ساختاری بخشی از چالشهای گستردهتری است که در بررسی ۷ نقطه کور مدلهای زبانی بزرگ به آنها پرداختیم، جایی که مدلها در تسکهای ساده اما دقیق شکست میخورند.
همانطور که در تحلیل قبلی ما دربارهی استقرار مدلها در محیط DeepSeek اشاره کردیم، لایهی سرویسدهی (Serving Stack) به اندازه خودِ مدل در اجرای دقیق خروجیها اثرگذار است. در این مطالعه، پژوهشگران یک تسک استخراج داده از فاکتورهای کوتاه را تعریف کردند: استخراج نام فروشنده، مبلغ کل و وضعیت پرداخت از یک سند فاکتور.
مدل زبانی بزرگ (LLM) — مثل کتابخانهداری که میلیاردها صفحه را خوانده و حالا با همان لحن کتابها جواب میدهد — در این تست باید دقیقاً مقدار {"vendor": "Acme Corp", "total": 95, "paid": true} را برگرداند. سند مورد استفاده برای تست این بود: «فاکتور INV-7role از شرکت Acme Corp، صادر شده در تاریخ ۲۰۲۶-۰۳-۱۴، وضعیت: پرداخت شده. اقلام: کیبورد ۴۵ دلار تعداد ۱؛ ماوس ۲۵ دلار تعداد ۲. مجموع کل ۹۵ دلار». طرحواره هدف شامل یک رشته برای vendor، یک عدد برای total و یک مقدار بولی برای paid بود و ویژگی additionalProperties روی حالت false تنظیم شده بود.
برای تشخیص تفاوت میان «اجبار واقعی به ساختار» و «پیروی ساده از دستورات»، محققان از یک «تست تضاد» استفاده کردند؛ آنها به مدل دستور دادند که عمداً ساختار را بشکند. برای مثال، از مدل خواستند به جای یک مقدار Enum الزامی مثل 'viridian'، از کلمه 'green' استفاده کند و یک فیلد ممنوعه به نام 'notes' اضافه کند. تنها مدلهایی که از رمزگشایی محدودشده (Constrained Decoding) استفاده میکردند، در برابر این دستور شکست نخوردند؛ مدلهایی که از «تزریق مشورتی» (Advisory Injection) استفاده میکردند، صرفاً از دستور پرامپت پیروی کرده و ساختار را شکستند.
جزئیات متدولوژی و دستهبندی تستها
برای رسیدن به نتایج آماری دقیق، شش دستهی آزمایشی مجزا تعریف شد:
- اجبار (Enforcement): شامل یک پرامپت متضاد (۱۰ مورد برای هر رابط)، دو پروب با طرحوارههای بدشکل برای بررسی تفاوت میان شکستهای بلند (خطای ۴۰۰) در برابر شکستهای خاموش (پاسخ ۲۰۰)، و یک تست تضاد در حالت
stream: true(۵ مورد). - انطباق (Compliance): تست ۶ شکل مختلف از طرحواره روی سند فاکتور (اشیای تخت، تو در تو تا سه سطح، آرایههایی از اشیا، Enumها، اتحادیههای
anyOfو رشتههای محدود شده با الگو)، هر کدام ۱۰ مورد که توسط یک اعتبارسنج JSON Schema تأیید شدند. - مقادیر (Values): بررسی صحت ریاضی و استخراج دادهها در سه تنظیمات مختلف تفکر (۸ مورد برای هر بازو)، شامل یک بازوی اصلاحی که در آن فیلد استدلال در سمت طرحواره قرار داده شده بود.
- کلمات کلیدی (Keywords): یک پروب تضاد برای هر کلمه کلیدی از ۶ کلمه کلیدی خاص در JSON Schema (هر کدام ۴ مورد).
- صورتحساب (Billing): بررسی سه اندازه مختلف از طرحواره (۱۵۷ بایت، ۱.۵ کیلوبایت و ۱۲ کیلوبایت) روی یک ورودی ثابت (۴ مورد).
- تأیید متقاطع: مدل Claude هم در رابط سازگار با OpenAI و هم در مسیر بومی Forced-tool شرکت Anthropic اندازهگیری شد. یک ناهنجاری در بخش اجبار از طریق یک ارائهدهنده دوم بازبینی شد.
پارادوکس اعتبار در برابر صحت
بر اساس مستندات این گزارش، تمام APIهایی که سوئیچ خروجی ساختاریافته داشتند، ۱۰۰٪ خروجیهای معتبر از نظر ساختاری تولید کردند. این موفقیت در هر ۶ شکل مختلف طرحواره (از اشیای ساده تا آرایههای پیچیده تو در تو و اتحادیههای anyOf) تکرار شد. به طور مشخص، OpenAI و هر نسل از Gemini نمره ۶۰ از ۶۰ را کسب کردند؛ DeepSeek V4 Pro، Qwen3.8-Max و GLM-5.2 نیز ۶۰ از ۶۰ شدند و DeepSeek V4 Flash نمره ۵۷ از ۵۷ را گرفت. یعنی مکانیزم رمزگشایی محدودشده دقیقاً همانطور که تبلیغ شده بود، عمل کرد.
اما وقتی نوبت به مقادیر رسید، واقعیت تغییر کرد. در چهار مدل DeepSeek V4 Pro، DeepSeek V4 Flash، Qwen3.8-Max و GLM-5.2، هرگاه حالت تفکر (Thinking) فعال بود، مقادیر غلط تولید میشدند.
برای مثال، در یک تسک ریاضی که پاسخ درست ۱۴ بود، مدل Qwen3.8-Max در ۱۶ بار اجرا با تفکر فعال، تنها ۱ بار پاسخ درست داد. نکته تکاندهنده این است که تمام پاسخهای غلط، از نظر ساختاری JSON کاملاً معتبر بودند. مدل ۱۱ بار پاسخ ۹ را داد و برای تنوع، پاسخهای ۲۹ و ۲ را هم تولید کرد. اما وقتی تفکر خاموش شد، دقت مدل به ۸ از ۸ رسید.

مکانیزم تخریب در حالت تفکر
این شکست به این دلیل رخ میدهد که رمزگشای محدودشده، مدل را مجبور میکند توکنی را انتخاب کند که با طرحواره سازگار باشد، حتی اگر استدلال داخلی مدل هنوز تمام نشده باشد. در واقع رمزگشا، زنجیره تفکر را قطع کرده و نزدیکترین توکن معتبر را میگیرد. این یک نویز تصادفی نیست؛ برای مثال، پاسخ غلط ۹ در مدل Qwen نتیجه تقسیم باقیمانده بر ۳ دلار به جای ۲ دلار بود.
- DeepSeek V4 Pro در حالت تفکر، «زبالههای نشانگر» (Sentinel Garbage) مثل ۱-، ۴۵- یا ۸۵- برای فیلدهای عدد صحیح تولید میکرد. در یک مورد، برای فاکتوری ۸۰ دلاری، مبلغ ۸۰۰۰ دلار را برگرداند. این مدل با تفکر فعال ۱ از ۸ و با تفکر خاموش ۷ از ۸ را درست پاسخ داد.
- GLM-5.2 رفتاری غیرقطعی داشت؛ در یک دسته تست ۰ از ۴ و در دستهای دیگر ۷ از ۸ را برای همان پرامپت و تنظیمات در یک روز پاسخ داد که این موضوع ارزیابیهای تولیدی را بسیار خطرناک میکند.
- Qwen3.8-Max تا زمان غیرفعال شدن سوئیچ تفکر، در تسکهای ریاضی به طور مداوم شکست خورد.
برخی توسعهدهندگان برای حل این مشکل، یک «فیلد استدلال» داخل خودِ JSON تعریف میکنند تا مدل بتواند در کانال محدودشده فکر کند. این روش برای Qwen جواب داد و دقت را از ۱/۸ به ۸/۸ رساند، اما برای DeepSeek V4 Flash نتیجه را بدتر کرد و دقت را از ۸/۸ به ۶/۸ رساند. همچنین این راهکار رایگان نیست و توکنهای استدلال همچنان محاسبه میشوند؛ در مدل Qwen میانگین ۳۹۳ توکن مصرف شد. در مدلهای سالمی مثل gpt-5.6-luna، این کار هیچ سودی نداشت اما تعداد توکنهای خروجی را از ۴۸ به ۱۰۶ توکن در هر فراخوانی دو برابر کرد. برای مدیریت این هزینههای اضافی، میتوان به تحلیل ما درباره ابزارهای کاهش توکن رجوع کرد که نشان میدهد صرفهجوییهای واقعی بسیار کمتر از ادعاهای تبلیغاتی است.
هزینههای پنهان طرحوارهها
یکی از شگفتانگیزترین یافتهها، نحوه محاسبه هزینه طرحواره (Schema) توسط ارائهدهندگان است. طرحواره هرگز وارد لیست پیامها نمیشود، اما در بدنه درخواست (OpenAI)، در generation_config (Gemini) یا به عنوان تعریف ابزار (Claude) ارسال میشود. یک طرحواره ۱۲ کیلوبایتی منجر به هزینههای متفاوتی شد:
- DeepSeek، GLM و Qwen هزینه توکن طرحواره را صفر در نظر میگیرند (ثابت بین ۳۰ تا ۱۰۹ توکن صرفنظر از اندازه طرحواره)، زیرا از گرامر سمت سرور استفاده میکنند.
- OpenAI (gpt-5.6-luna) برای طرحواره ۱۵۷ بایتی ۵۷ توکن، برای ۱.۵ کیلوبایت ۳۴۶ توکن و برای ۱۲ کیلوبایت ۲۳۶۸ توکن شارژ کرد.
- Gemini برای ۱۵۷ بایت ۹۲ توکن، برای ۱.۵ کیلوبایت ۵۹۰ توکن و برای ۱۲ کیلوبایت ۴۰۱۲ توکن شارژ کرد.
- Claude (fable-5) بیشترین هزینه را با ۵۴۹ توکن برای ۱۵۷ بایت، ۱۰۲۹ توکن برای ۱.۵ کیلوبایت و ۴۹۵۹ توکن برای ۱۲ کیلوبایت از طریق تعریف ابزار بومی داشت که شامل یک هزینه ثابت حدود ۵۰۰ توکن بود. مدل Sonnet-5 در هر اندازه ۶۴ توکن بیشتر مصرف کرد.
در گروه مدلهایی که هزینه دریافت میکنند، نرخ سریالسازی برای بایتهای یکسان تا ۷۰٪ تفاوت دارد. این یعنی برای اپلیکیشنهای با حجم بالا، انتخاب ارائهدهنده اثر بیشتری روی هزینه دارد تا قیمت هر توکن مدل. یک طرحواره ۱۲ کیلوبایتی در DeepSeek رایگان است اما در Gemini برای ۱۰۰ هزار فراخوانی در ماه، ۴۰۰ میلیون توکن ورودی اضافه میکند.
رفتارهای خاص ارائهدهندگان
این مطالعه سه مکانیزم مختلف را شناسایی کرد: رمزگشایی محدودشده (اجبار فیزیکی)، تزریق مشورتی (پرامپتنویسی) و نادیده گرفتن خاموش.
مدل Claude در رابطهای سازگار با OpenAI مشکلسازترین است؛ این مدل پارامتر response_format را میپذیرد و وضعیت ۲۰۰ OK برمیگرداند، اما طرحواره را کاملاً نادیده میگیرد. صفر از ۶۰ پاسخ با شکل درخواستی مطابقت داشت و مدل فیلدهایی مثل invoice_number و line_items را از خودش اختراع کرد. برای اجبار واقعی در Claude، باید از Tool Calling بومی Anthropic با اجبار tool_choice استفاده کرد. این مسیر بومی در تستهای تضاد ۱۰ از ۱۰ را پاس کرد، اما تنها سطحی است که برای طرحوارههای بدشکل پاسخ ۲۰۰ OK برمیگرداند، به این معنی که غلطهای تایپی در طرحواره بهصورت خاموش شکست میخورند.
مدل Kimi K3 نشان داد که اجبار، ویژگیِ میزبان (Host) است و نه خودِ مدل. از طریق API رسمی، این مدل ۱۰ از ۱۰ بار از پرامپت متضاد پیروی کرد (فیلدهای ممنوعه را اضافه کرد) و در حالت استریمینگ (۰ از ۵) در حالت مشورتی ماند. اما همان مدل با وزنهای باز (Open Weights) که توسط یک میزبان GPU شخص ثالث سرو شده بود، همان طرحواره را در ۳ مورد از ۳ مورد تست تضاد اجرا کرد.
Gemini و OpenAI در مقادیر قابلاعتمادتر بودند اما در کلمات کلیدی انعطاف کمتری داشتند. بررسی ۶ کلمه کلیدی به این شرح بود:
- $ref / $defs: توسط OpenAI و سه مدل چینی پشتیبانی شد؛ اما Gemini خطای ۴۰۰ داد.
- oneOf: توسط OpenAI رد شد (۴۰۰) و توسط Gemini بهصورت خاموش حذف شد (۲۰۰)، اما توسط DeepSeek, Qwen و GLM پشتیبانی شد.
- format: date: توسط OpenAI، Gemini و سه مدل چینی پشتیبانی شد؛ اما Claude در ۲ مورد از ۴ مورد آن را حذف کرد.
- pattern: تقریباً توسط همه، از جمله Claude، پشتیبانی شد.
- minItems: توسط DeepSeek، Qwen و GLM پشتیبانی شد؛ OpenAI فقط در ۲ مورد از ۴ مورد موفق بود و Gemini و Claude آن را حذف کردند.
- enum: توسط اکثر مدلها پشتیبانی شد، هرچند Kimi و Claude فقط ۳ از ۴ را پاس کردند.
مالیات استدلال و سوئیچ خاموش
اکثر مدلهای استدلالی حتی وقتی مجبور به خروجی ساختاریافته میشوند، توکن مصرف میکنند. میانگین توکنهای مصرفشده برای یک پاسخ ساده دو-توکنی به این شرح است:
- GLM-5.2: ۵۶۸ توکن
- DeepSeek V4 Pro: ۵۰۵ توکن
- DeepSeek V4 Flash: ۴۶۶ توکن
- Qwen3.8-Max: ۴۲۴ توکن
- Gemini 3.1 Pro: ۲۲۰ توکن
- Gemini 3.6 Flash: ۲۱۰ توکن
- Gemini 3.7 Flash: ۹۹ توکن
- Kimi K3: ۶۹ توکن
- gpt-5.6-luna: ۲۸ توکن
توانایی متوقف کردن این «مالیات» به ارائهدهنده بستگی دارد. DeepSeek دستور reasoning_effort: none را رد میکند (۴۰۰) اما دستور thinking: {"type": "disabled"} را میپذیرد. Qwen، GLM و Kimi اجازه میدهند درجه تلاش (Effort) به صفر برسد. اما نسل فعلی Gemini (۳.۷ Flash و ۳.۱ Pro) تمام دستورات خاموش کردن تفکر را رد میکند و این مالیات استدلال را اجباری میکند.
مسیر بومی ابزار در Claude یک استثنا است. اجبار به فراخوانی ابزار، تفکر گسترده را کاملاً دور میزند و منجر به کوتاهترین و ارزانترین تکمیلها در کل مجموعه شد، با میانگین ۷۴ توکن خروجی.
گام بعدی شما
- اگر از DeepSeek، Qwen یا GLM برای استخراج داده استفاده میکنید، قانون ساده است: حالت تفکر (Thinking) را خاموش کنید. ساختار در هر صورت حفظ میشود، اما اعداد تنها بدون سربار استدلال قابل اعتماد هستند.
- برای مدلهای OpenAI و Gemini، تفکر میتواند روشن بماند زیرا تخریب مقادیر اندازهگیری نشد. اما مراقب حالت «شکست خاموش» باشید که در آن پاسخ ۲۰۰ OK در واقع محدودیتهای طرحواره شما را نادیده میگیرد، بهویژه در اتحادیههای
oneOfدر Gemini. همچنین دیالکت Gemini اتحادیههای نوع مثل["string", "null"]را رد میکند. - این دادهها ثابت میکند که اعتبارسنجی طرحواره جایگزینی برای اعتبارسنجی مقادیر نیست. یک شیء JSON معتبر صرفاً یک ظرف است و حقیقت محتویات را تضمین نمیکند. برای اجتناب از این تلهها، توسعهدهندگان باید یک لایه اعتبارسنجی ثانویه برای فیلدهای عددی حساس پیاده کنند و طرحوارههای خود را روی ارائهدهندگان مختلف تست کنند تا از جهشهای هزینهای غیرمنتظره جلوگیری شود.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.




گفتگو