LFM2.5: بهبود شدید پیروی از طرح‌های JSON با ۵۰۰ نمونه آموزشی

اگر امروز برای استخراج داده از مدل‌های زبانی هزینه می‌کنید، احتمالاً می‌دانید که کوچک‌ترین خطای سینتکسی در یک فایل JSON می‌تواند کل سیستم شما را متوقف کند. حالا یک مدل بسیار کوچک ۳۵۰ میلیون پارامتری می‌تواند با استفاده از یک دستورالعمل یادگیری تقویتی هدفمند، به دقتی نزدیک به مدل‌های غول‌پیکر در رعایت ساختار داده‌ها برسد. طبق یک راهنمای فنی که در ۳ سپتامبر ۲۰۲۶ منتشر شد، مدل LFM2.5-350M پس از تنها ۱۰۰ گام بهینه‌سازی سیاست نسبی گروهی (GRPO)، شاهد جهش دقت خروجی‌های ساختاریافته از ۲۲.۶٪ به ۲۹.۷٪ در محک IFStruct بود.

خروجی ساختاریافته و قابل‌اعتماد، اصلی‌ترین گلوگاه برای ادغام مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — در نرم‌افزارهای عملیاتی است. اگر مدل نتواند یک شیء JSON قابل‌تحلیل برگرداند یا یک فیلد ضروری را فراموش کند، سیستم‌های پایین‌دستی کرش می‌کنند. اکثر بنچمارک‌ها این شکست‌ها را در دل نمرات کلی استدلال پنهان می‌کنند، اما محک IFStruct دقیقاً رعایت طرح (Schema Adherence) را ایزوله می‌کند تا اندازه‌گیری کند مدل دقیقاً هر چند وقت یک‌بار فرمت درخواستی را می‌شکند. این رویکرد تأکیدی است بر اینکه چرا استفاده از محک‌های سفارشی‌شده برای نیازهای خاص بسیار حیاتی‌تر از تکیه بر لیدربوردهای عمومی است. اینکه آیا یک مدل به‌طور قابل‌اعتماد خروجی معتبر و قابل‌تحلیلی را در فرمت و شکل درخواستی برمی‌گرداند یا خیر، اغلب تعیین می‌کند که آیا اصلاً می‌توان آن را به یک سیستم پایین‌دستی متصل کرد یا نه.

برای توسعه‌دهندگان، این یعنی فاصله بین یک هوش مصنوعی «پر حرف» و یک API قابل‌اعتماد در حال بسته شدن است. مدل‌های کوچک به‌طور سنتی در فرمت‌بندی سخت‌گیرانه ضعیف هستند و اغلب در بستن بلوک‌های کد یا نام‌گذاری کلیدها دچار توهم (Hallucination) — شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند — می‌شوند. این رویکرد جدید ثابت می‌کند برای دستیابی به داده‌های ساختاریافته، نیازی به مدل‌های عظیم یا بودجه‌های میلیون دلاری نیست. لازم به ذکر است که خط لوله آموزشی توصیف شده در اینجا، همان خط لوله‌ای نیست که برای آموزش مدل RL در وبلاگ IFStruct استفاده شده است؛ بلکه هدف آن نشان دادن این است که چگونه تنظیم دقیق (Fine-tuning) مدل‌های کوچک‌تر برای وظایف خاص می‌تواند با عملکرد مدل‌های بسیار بزرگ‌تر برابری کند. با این حال، باید به خاطر داشت که تنظیم دقیق مدل‌ها لزوماً جایگزینی برای ایجاد یک پایگاه دانش جامع نیست و بیشتر برای بهبود رفتار و فرمت خروجی کاربرد دارد.

زمینه و آماده‌سازی

این پروژه از یک دستورالعمل عمومی و ارزان‌قیمت استفاده می‌کند که برای محاسبات در سطح رایگان (Free-tier) طراحی شده است. فرآیند تنظیم دقیق (Fine-tuning) — مثل وقتی به یک پزشک عمومی، تخصص پوست می‌دهیم تا روی یک حوزه دقیق شود — برای GPUهای رایگان در Colab یا Kaggle بهینه‌ شده است. ارزیابی‌ها به‌صورت محلی روی یک MacBook Pro با تراشه M5 Max و ۳۶ گیگابایت حافظه یکپارچه انجام شده است.

برای سرویس‌دهی مدل، تیم از llama.cpp استفاده کرد که سروری سازگار با OpenAI ارائه می‌دهد. این تنظیمات نیازمند ابزار uv برای مدیریت پایتون و نصب llama-server از طریق Homebrew بود. مدل پایه با استفاده از نسخه BF16 GGUF (مدل LiquidAI/LFM2.5-350M-GGUF) با اندازه کانتکست ۳۲,۷۶۸ توکن، چهار درخواست موازی و انتقال تمام لایه‌ها به GPU اجرا شد.

زیرساخت ارزیابی

برای ایجاد یک خط پایه، تیم مدل پایه LFM2.5-350M را ارزیابی کرد تا ببیند آیا می‌تواند نمره گزارش‌شده ۲۱.۱٪ را بازتولید کند یا خیر. بنچمارک IFStruct به‌صورت متن‌باز از طریق مخزن Liquid4All/ifstruct در دسترس است و مجموعه داده‌های عمومی آن در Hugging Face در مسیر LiquidAI/ifstruct-v1.0 قرار دارد.

دستور اجرای محلی از llama-server با پارامترهای زیر استفاده کرد:

• -hf LiquidAI/LFM2.5-350M-GGUF:BF16 برای مدل
• -c 32768 برای کانتکست پرامپت
• -np 4 برای سرویس‌دهی به چهار درخواست به‌صورت موازی
• -ngl 99 برای انتقال تمام لایه‌ها به GPU
• --alias LiquidAI/LFM2.5-350M برای نقطه اتصال (Endpoint) سازگار با OpenAI

بنچمارک کامل با ۲,۰۰۰ نمونه با استفاده از دستور uv run ifstruct-eval با محدودیت حداکثری ۲۰۴۸ توکن و ۴ رشته (Thread) اجرا شد. این تنظیمات محلی نرخ موفقیت ۲۲.۶٪ (۴۵۲ از ۲۰۰۰) را اندازه‌گیری کرد که به عنوان خط پایه برای مقایسه‌های بعدی قرار گرفت.

دستورالعمل تنظیم دقیق

خط لوله آموزشی از کتابخانه TRL استفاده می‌کند و هدف آن مدل LFM2.5-350M است. برای کاهش هزینه‌ها، از یک آداپتور لورا (LoRA) استفاده شد. به دلیل معماری ترکیبی توجه/کانولوشن در LFM2.5، آداپتور روی نام ماژول‌های خاص LFM متمرکز شد:

• q_proj, k_proj, v_proj, out_proj
• in_proj, w1, w2, w3

این پیکربندی تنها حدود ۶ میلیون پارامتر را آموزش داد که تقریباً ۱.۶۶٪ از کل اندازه مدل است. آماده‌سازی داده‌ها کلید موفقیت این اجرا بود. تیم از مجموعه داده nvidia/Nemotron-RL-instruction_following-structured_outputs استفاده کرد که پرامپت‌ها را با یک طرح JSON هدف و تعداد فیلدهای مورد انتظار جفت می‌کند. آن‌ها از حدود ۵۰۰ نمونه استفاده کردند و داده‌ها را برای پر کردن شکاف‌های بین توزیع Nemotron و ارزیابی IFStruct تقویت کردند:

• ۴۰٪ پرامپت‌ها دستور «خروجی را داخل یک بلوک کد محصور (fenced code block) برگردان» را دریافت کردند تا مدل یاد بگیرد دستورات فرمت را دنبال کند، نه اینکه فقط JSON خام تولید کند.
• ۲۰٪ مجزا به وظایف «آرایه در سطح بالا» تبدیل شدند، جایی که طرح در یک آرایه با تعداد آیتم‌های مورد نیاز پیچیده شده است؛ این کار مدل را روی خروجی‌های لیست ساده و رعایت تعداد آیتم‌ها آموزش داد.

مکانیزم پاداش

برخلاف تنظیمات نظارت‌شده معمولی، GRPO بر توابع پاداش برای هدایت مدل تکیه دارد. این خط لوله از سه پاداش مجزا در مقیاس [۰, ۱] استفاده کرد که به صورت مجموع وزنی با وزن‌های [۱.۰، ۰.۵، ۲.۰] ترکیب شدند:

• پاداش فرمت JSON (وزن ۱.۰): بررسی می‌کند که آیا خروجی قابل‌تحلیل و در فرم درخواستی است یا خیر. امتیاز کامل (۱.۰) برای فرم درست (محصور در کد در مقابل خام)، امتیاز ۰.۲ برای فرم اشتباه اما قابل‌تحلیل، و امتیاز ۰.۰ برای خروجی غیرقابل‌تحلیل داده می‌شود.
• پاداش تعداد فیلد (وزن ۰.۵): اندازه‌گیری می‌کند که آیا شیء دارای تعداد مورد انتظار فیلدهای سطح‌بالا است یا خیر. تطابق دقیق امتیاز ۱.۰ می‌گیرد و نمره برای موارد گم‌شده به‌صورت خطی کاهش می‌یابد.
• پاداش اعتبارسنجی طرح (وزن ۲.۰): سنگین‌ترین سیگنال است. این تابع هرگونه نقض محدودیت را می‌شمارد و امتیاز جزئی را بر اساس پوشش کلیدهای ضروری (Required Keys) محدود می‌کند.

تحلیل عملکرد

نتایج که از طریق llama.cpp روی MacBook Pro M5 Max اندازه‌گیری شد، یک بهبود هدفمند را نشان می‌دهد. نرخ موفقیت کلی ۷.۱ درصد افزایش یافت، اما دستاوردها در زمینه‌های خاص متمرکز بودند:

• صحت JSON: از ۱۸.۰٪ (۱۸۰ از ۱۰۰۰) به ۳۱.۹٪ (۳۱۹ از ۱۰۰۰) رسید (افزایش ۱۳.۹٪).
• رعایت لیست‌های ساده: از ۱۶.۶٪ (۱۶۴ از ۹۸۹) به ۲۹.۷٪ (۲۹۴ از ۹۸۹) رسید (افزایش ۱۳.۱٪).
• صحت YAML: تقریباً ثابت ماند و از ۲۷.۲٪ (۲۷۲ از ۱۰۰۰) به ۲۷.۵٪ (۲۷۵ از ۱۰۰۰) رسید.
• کلید Wrapper: از ۲۸.۵٪ (۲۸۸ از ۱۰۱۱) به ۲۹.۷٪ (۳۰۰ از ۱۰۱۱) رسید.

انواع موجودیت‌های خاص جهش‌های عظیمی را تجربه کردند. دقت رزرو بلیط رویداد از ۴۵.۸٪ به ۵۷.۹٪ و رزرو ماشین کرایه‌ای به ۴۶.۸٪ (از ۳۴.۲٪) رسید. سایر پیشرفت‌های قابل توجه شامل دسته‌های تیکت پشتیبانی (۳۷.۰٪ به ۴۹.۳٪)، مثال‌های تجزیه‌کننده لاگ (۲۹.۲٪ به ۴۵.۸٪) و صحنه‌های فیلمنامه (۱۷.۴٪ به ۳۷.۰٪) بود. بهبودهای دیگری در کارآزمایی‌های بالینی (۱۹.۲٪ به ۲۹.۸٪) و آگهی‌های شغلی (۲۹.۴٪ به ۳۸.۸٪) دیده شد. با این حال، برخی وظایف همچنان دشوار بودند؛ بررسی دوربین‌ها در واقع از ۷.۲٪ به ۶.۰٪ کاهش یافت و بررسی GPU در سطح پایین ۷.۴٪ باقی ماند.

پیاده‌سازی فنی

آموزش برای یک GPU رایگان با ۱۶ گیگابایت حافظه تنظیم شد. در GRPOConfig، نرخ یادگیری ۵e-۵، ۱۰ گام گرم‌کردن (Warmup) و ۸ تولید برای هر گروه پرامپت در نظر گرفته شد. دمای ۱.۱ برای متنوع نگه داشتن گروه‌های نمونه‌برداری و بتای ۰.۰۱ برای جریمه KL نسبت به مدل مرجع استفاده شد. فرآیند در ۱۰۰ گام با اندازه دسته آموزشی ۴ برای هر دستگاه و ۸ گام تجمع گرادیان اجرا شد. سایر تنظیمات شامل max_completion_length برابر با ۱,۰۲۴ و steps_per_generation برابر با ۲ بود.

پس از آموزش، آداپتور لورا با استفاده از merge_and_unload() در وزن‌های پایه ادغام شد و به عنوان یک چک‌پوینت مستقل ذخیره گردید. سپس این مدل با استفاده از اسکریپت convert_hf_to_gguf.py از سورس llama.cpp به BF16 GGUF تبدیل شد. مدل ادغام شده روی پورت ۸۰۸۱ با نام مستعار lfm25-350m-grpo-structured-output برای ارزیابی نهایی سرویس‌دهی شد.

خطاهای رایج پس از تنظیم تغییر کردند. در مدل پایه، برترین خطاها «فقدان فیلد ضروری» (۷۲۲۸ مورد)، «تعداد آیتم اشتباه» (۷۳۸ مورد) و «عدم تطابق نوع» (۵۴۰ مورد) بود، به همراه ۳۱۷ مورد بلوک کد بسته نشده و ۱۷۰ مورد فقدان بلوک کد. پس از تنظیم، در حالی که «فقدان فیلد ضروری» (۷۳۳۱ مورد) همچنان مشکل اصلی بود، تعداد «بلوک‌های کد بسته نشده» به ۱۰۲ مورد کاهش یافت. خطاهای رایج جدید شامل مسائل فیلدهای خاص مانند «فیلد اضافی metadata.tone» (۶۲ مورد)، «فیلد اضافی speaker_labels» (۴۹ مورد) و محدودیت‌های مقداری، مانند «cups در مقادیر مجاز ['mg', 'g', 'kg', 'oz', 'lb', 'ml', 'l', 'cl', 'dl'] نیست» (۴۴ مورد) بود.

این نتیجه مدل ۳۵۰ میلیون پارامتری را به‌طور شگفت‌انگیزی به نمره ۳۳.۱۵٪ مدل Qwen3.5-2B نزدیک می‌کند. این ثابت می‌کند که یک سیگنال پاداش تخصصی و کوچک برای فرمت‌بندی، بسیار موثرتر از افزایش صرف تعداد پارامترهاست.

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

برای بازتولید این نتایج، توسعه‌دهندگان می‌توانند به نوت‌بوک کامل در گیت‌هاب، مخزن بنچمارک Liquid4All/ifstruct و مجموعه داده LiquidAI/ifstruct-v1.0 در Hugging Face دسترسی داشته باشند.