اگر امروز از مدل‌های زبانی کوچک برای استخراج داده‌های ساختاریافته استفاده می‌کنید، احتمالاً با کابوسِ بسته‌نشدن پرانتزها یا توهم در کلیدهای JSON دست‌وپنجه نرم کرده‌اید. یک خطای کوچک در فرمت خروجی می‌تواند کل خط لوله (pipeline) اتوماسیون شما را در لحظه‌ای حساس متوقف کند.
یک خط لوله بازرسی امنیتی که از مدل qwen2.5-coder:7b روی اولاما (Ollama) استفاده می‌کرد، در بازه دو هفته‌ای سال گذشته با این مشکل مواجه بود؛ به گونه‌ای که از هر پنج اجرا، یکی در مرحله تجزیه (parsing) شکست می‌خورد. این شکست‌ها به دلیل ضعف در تحلیل امنیتی نبودند، بلکه ناشی از «تلاشی ساختاری» بودند که در آن مدل فراموش می‌کرد پرانتزها را ببندد یا کلیدهای خیالی ابداع می‌کرد. طبق گزارشی که در ۲۸ ژوئیه ۲۰۲۶ در وب‌سایت dev.to منتشر شد، مقصر اصلی یک اسکیمای JSON بسیار تو در تو بود که شبیه به پاسخ‌های حرفه‌ای API طراحی شده بود.
چرا اسکیمای تو در تو در مدل‌های کوچک شکست می‌خورد؟
مدل‌های زبانی کوچک (SLM) — که مثل دستیارهای تازه‌کار، حافظه کوتاه‌مدت محدودی برای مدیریت جزئیات دارند — ظرفیت «دفترداری» مدل‌های پیشرو را ندارند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی محدودیت‌های مدل‌های لبه‌ای اشاره کردیم، وقتی یک مدل ۷ میلیاردی روی استدلال‌های پیچیده امنیتی تمرکز می‌کند، اغلب جایگاه خود را در یک شیء تو در تو گم می‌کند. در واقع، هر سطح از تو در تو بودن، یک نقطه شکست احتمالی است؛ مدل باید پرانتزها را از حافظه ببندد و در سطح سوم، ممکن است دیگر یادش نیاید که داخل شیء «ارزیابی» (assessment) است یا «آسیب‌پذیری» (vulnerability).
فیلدهای اختیاری نیز بیشترe باعث تشدید این وضعیت و دعوت به بداهه‌پردازی مدل می‌شوند. وقتی به مدل یک شیء «جزئیات» (details) با محتوای تعریف‌نشده و منعطف داده شود، یک مدل کوچک اغلب در هر بار اجرا، کلیدهای جدید و متفاوتی را ابداع می‌کند.
تصور کنید مدل سعی دارد هم‌زمان سه قانون فرمت‌بندی مختلف را مدیریت کند — یک عدد اعشاری (float) برای سطح اطمینان، یک رشته متنی (string) برای شدت خطر و یک آرایه برای شماره خطوط — و در عین حال یک سلسله‌مراتب پیچیده و تو در تو را حفظ کند. در دمای (Temperature) بالای صفر، این پیچیدگی ناگزیر به ویرگول‌های اضافی در انتهای خطوط یا قرار دادن JSON معتبر در میان پاراگراف‌های مودبانه‌ای منجر می‌شود که مدل در آن‌ها توضیح می‌دهد که JSON مورد نظر را تولید کرده است.
گذار به اسکیمای تخت (Flat Schemas)
برای حل این مشکل، مهندس مربوطه ساختار تو در تو را با یک اسکیمای تخت جایگزین کرد و برای اعتبارسنجی از Zod استفاده نمود. اسکیمای قدیمی و مشکل‌ساز شامل اشیاء تو در تو برای آسیب‌پذیری‌ها، ارزیابی‌ها و روش‌های اصلاح بود که آرایه‌هایی برای شماره خطوط و اعداد اعشاری برای اطمینان را در بر می‌گرفت.
طراحی جدید از چهار قانون سخت‌گیرانه برای کاهش «بودجه پیچیدگی» مدل پیروی می‌کند تا مدل مجبور نباشد توان پردازشی خود را صرف فرمت‌بندی کند:
- حذف تو در تو بودن (Zero Nesting): ساختار اکنون فقط آرایه‌ای از اشیاء تخت است. این کار تضمین می‌کند که مدل هرگز جایگاه خود را در سلسله‌مراتب گم نکند.
- استفاده از Enumهای سخت‌گیرانه: شدت آسیب‌پذیری به یک لیست بسته و محدود (
critical,high,medium,low,info) تغییر یافت تا از تولید عبارات متغیر مثل "High"، "HIGH"، "high-ish" یا "severe" جلوگیری شود. - توصیف متنی مکان‌ها: به‌جای آرایه‌های دقیق شماره خط (که اغلب منجر به تولید اعداد یا محدوده‌های جعلی توسط مدل می‌شد)، مکان‌ها اکنون رشته‌های متنی ساده هستند (مثلاً: "withdraw(), lines 42-57").
- حذف فیلدهای اختیاری: هر فیلد در هر اجرا الزامی است. یکدستی و تکرارپذیری برای مدل‌های کوچک کلید خوانایی و پایداری است.
اجرای مکانیکی در مرز سیستم
در این سیستم، خروجی مدل مانند یک درخواست شبکه، «ناپایدار و غیرقابل اعتماد» تلقی می‌شود. داده‌ها از یک مرز عبور می‌کنند، یک بار تجزیه و اعتبارسنجی می‌شوند و سپس بقیه کد با مقادیر تایپ‌شده (typed values) کار می‌کنند، بدون اینکه نیاز باشد دوباره در صحت آن‌ها تردید کنند.
این خط لوله از ترفند «برش تا پرانتز» (slice-to-braces) برای استخراج بیرونی‌ترین شیء JSON استفاده می‌کند. با یافتن اولین { و آخرین }، سیستم تمام شکست‌های ناشی از متون مقدماتی، توضیحات اضافی یا علامت‌های markdown (fences) که مدل قبل از بلوک JSON اضافه می‌کند را حذف می‌کند. اگرچه این روش ظریف نیست، اما تمام خطاهای کلاسیک «این هم JSON شما:» را از بین می‌برد.
برای پر کردن شکاف باقی‌مانده، یک حلقه تلاش مجدد (retry loop) به کار گرفته شده که خطاهای اعتبارسنجی را مستقیماً به مدل بازمی‌گرداند. اگر Zod یک مقدار نامعتبر در Enum شناسایی کند، پیام خطای دقیق — مثلاً "severity: Invalid enum value. Expected 'critical' | 'high' | ..." — به پرامپت بعدی الحاق می‌شود.
این حلقه بازخورد به مدل اجازه می‌دهد اشتباهات خاص و نقطه‌وار خود را اصلاح کند. این منطق تا سه بار تکرار می‌شود؛ اگر مدل پس از سه بار تلاش باز هم شکست بخورد، یک خطای شدید (loud error) صادر می‌کند. این اقدام از یک شکست امنیتی خطرناک جلوگیری می‌کند؛ وضعیتی که در آن یک خطای تجزیه به‌طور خاموش آرایه‌ای خالی برگرداند و کاربر را به اشتباه بیندازد که هیچ آسیب‌پذیری در کد یافت نشده است.
جزئیات پیاده‌سازی و بهینه‌سازی‌ها
چند انتخاب فنی دقیق، این سیستم را از حالت «خوب» به پایداری «خسته‌کننده» (Boring Reliability) تبدیل کرد:
- دمای پایین: دمای نزدیک به صفر (۰.۱) برای استخراج داده استفاده شد. خلاقیت باید برای پرامپت تحلیل رزرو شود، نه برای پرامپت فرمت‌بندی؛ این کار نرخ تولید خروجی‌های بدشکل را به‌شدت کاهش داد.
- حالت JSON اولاما: استفاده از
format: "json"خروجی را به نحو صحیح JSON محدود می‌کند و ویرگول‌های اضافی را حذف می‌کند، اما توجه داشته باشید که این قابلیت شکل و ساختار اسکما را تضمین نمی‌کند. - یکپارچگی با Zod: استفاده از Zod پیام‌های خطای لازم برای بازخورد به مدل را به‌صورت رایگان فراهم می‌کند، به این معنی که نیازی به نگهداری کد جداگانه برای توضیح خطاها نیست.
- دقت برنامه‌ریزی شده: سیستم فقط مواردی را که باید به‌صورت برنامه‌ریزی‌شده روی آن‌ها عمل کند (مثل مرتب‌سازی و فیلتر کردن در spectr-ai)، به‌صورت Enum تجزیه و اعتبارسنجی می‌کند.
این رویکرد فلسفه ادغام مدل‌های زبانی را تغییر می‌دهد: به‌جای جنگیدن برای رسیدن به فرمت ایده‌آل و پیچیده، توسعه‌دهندگان باید تا فرمتی مذاکره کنند که مدل بتواند به‌طور قابل‌اعتمادی تولید کند. با اعمال مکانیکی این مرز， شکست‌های تجزیه از یک مزاحمت روزانه به یک رویداد نادر در لاگ‌ها تبدیل می‌شوند که توسعه‌دهنده تنها از روی کنجکاوی آن‌ها را چک می‌کند.
برای توسعه‌دهندگانی که مدل‌های زبانی کوچک (SLM) را در لبه (Edge) مستقر می‌کنند، این موضوع ثابت می‌کند که قابلیت اطمینان، یک ویژگی ذاتی مدل نیست، بلکه یک انتخاب در طراحی سیستم است. تکیه بر «هوش» مدل برای پیروی از یک اسکیمای پیچیده، یک ریسک و نقطه ضعف است؛ اما تکیه بر اسکیمای تخت و حلقه بازخورد، یک پیروزی مهندسی است.
در آینده، منتظر ظهور تکنیک‌های نمونه‌برداری «آگاه به اسکما» (schema-aware sampling) در زمان‌های اجرای مدل‌های کوچک باشید که ممکن است این فرآیند تخت‌سازی را در سطح استنتاج (inference) خودکار کنند.
گام بعدی شما
- اگر خروجی‌های JSON مدل‌های کوچک شما ناپایدار است، تمام اشیاء تو در تو را به آرایه‌ای از اشیاء تخت تبدیل کنید.
- از کتابخانه Zod برای تعریف اسکما و تبدیل خطاهای اعتبارسنجی به پرامپت‌های اصلاحی در حلقه retry استفاده کنید.
- دمای استخراج داده را روی ۰.۱ تنظیم کنید تا تداخل خلاقیت با ساختار خروجی حذف شود.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو