اگر قصد دارید یک عامل هوشمند بسازید که به‌جای حدس زدن، واقعاً از ابزارهای نرم‌افزاری استفاده کند، باید با چالش توهم در آرگومان‌ها دست‌وپنجه نرم کنید. مدل‌های زبانی کوچک معمولاً در فراخوانی دقیق توابع شکست می‌خورند، اما اکنون می‌توان مدل Qwen3-0.6B را با یک خط لوله تنظیم نظارت‌شده (SFT) — شبیه به آموزش یک کارآموز با استفاده از دفترچه راهنمای دقیق شرکت — برای این چالش آماده کرد. این خط لوله به‌گونه‌ای طراحی شده است که اولویت را به حفظ استدلال (Reasoning Preservation) می‌دهد تا صرفاً به تطبیق ساده الگوهای متنی (Pattern Matching) بسنده کند.
این رویکرد بر حفظ استدلال مدل تمرکز دارد تا صرفاً الگوهای متنی را تقلید کند. همان‌طور که در تحلیل قبلی ما درباره‌ی معماری‌های مهار توهم و الگوهای مورد استفاده برای توقف جعل اطلاعات اشاره کردیم، شکاف اصلی در «استفاده از ابزار» نهفته است. بسیاری از توسعه‌دهندگان با مدل‌هایی مواجه‌اند که یا ساختار ابزار (Tool Schema) را فراموش می‌کنند یا مرحله استدلال را پیش از اجرای تابع حذف می‌کنند. طبق مستندات این راهنما، استفاده از مجموعه داده XYZ-Aquila-SFT راهکاری برای حل این شکست‌ها و ارائه یک نقشه راه برای بهبود عملکرد مدل‌های کوچک است.
خط لوله مهندسی داده
فرآیند با استریم کردن مجموعه داده XYZ-Aquila-SFT آغاز می‌شود که شامل مسیرهای پیچیده و چندمرحله‌ای استفاده از ابزار است. برخلاف جفت‌های ساده پرسش و پاسخ، این مسیرها شامل یک پرامپت سیستمی با تعاریف ابزار، پرسش‌های کاربر و توالی افکار دستیار و فراخوانی‌های ابزار است. در این پیاده‌سازی، یک دیکشنری پیکربندی (CFG) برای مدیریت جریان داده استفاده شده که مقدار N_STREAM را روی ۴۰۰ نمونه و N_EVAL را برای اعتبارسنجی روی ۴۰ مورد تنظیم می‌کند.
برای مدیریت این داده‌ها، یک اسکنر JSON امن برای توابع تو در تو طراحی شده است. از آنجا که عبارت‌های منظم (Regex) استاندارد معمولاً در مواجهه با اشیاء تو در تو (Nested Objects) شکست می‌خورند، این رمزگشای سفارشی تضمین می‌کند که هر فراخوانی تابع به‌دقت استخراج شود. این خط لوله به‌طور خاص تگ‌های سبک XML را برای تجزیه ساختار گفتگو هدف قرار می‌دهد:
<tools>: برای جداسازی امضاهای توابع (Function Signatures) که در پرامپت سیستمی ارائه شده‌اند.<think>: برای ثبت بلوک‌های استدلال داخلی مدل که فرآیند تفکر را نشان می‌دهد.<tool_call>: برای شناسایی شیء JSON خاصی که حاوی نام تابع و آرگومان‌های آن است.<tool_response>: برای شناسایی مشاهداتی (Observations) که از اجرای ابزار بازمی‌گردند.
مکانیزم‌های تجزیه و اشیاء مسیر
برای تبدیل داده‌های خام به فرمت قابل آموزش، از یک کلاس داده (Dataclass) به نام Trajectory استفاده می‌شود. این شیء، پرسش اصلی، پاسخ نهایی، تعداد فراخوانی‌های ابزار اعلام شده و کل توالی پیام‌ها را ذخیره می‌کند. همچنین تعداد مشاهدات (n_observations) که همان تعداد پاسخ‌های ابزار است و تعداد بلوک‌های تفکر (n_think) را ردیابی می‌کند تا پیچیدگی هر مسیر مشخص شود.
استخراج طرحواره ابزار
سیستم تعاریف ابزار را از طریق یک فرآیند استخراج خاص مدیریت می‌کند. ابتدا به دنبال سرتیتر # Tools می‌گردد و با استفاده از عبارت منظم TOOLS_BLOCK_RE طرحواره را جداسازی می‌کند. سپس این طرحواره‌ها بین فرمت‌های جاسازی‌شده در پیام و JSON ساختاریافته تبدیل می‌شوند. برای تایید این فرآیند، یک تست «استخراج-رندر» (Extract-Render) با دقت بایت-به-بایت انجام می‌شود تا اطمینان حاصل شود که بازسازی پیام سیستمی از روی ابزارهای ساختاریافته، باعث ایجاد تغییر در قالب (Template Drift) نمی‌شود.
تحلیل پیکره و آمار
پیش از آموزش، خط لوله تحلیلی عمیق روی ویژگی‌های پیکره داده انجام می‌دهد. با تبدیل ردیف‌های خام به اشیاء Trajectory ساختاریافته، معیارهای حیاتی برای درک پیچیدگی تکلیف محاسبه می‌شوند. این تحلیل شامل توزیع فراخوانی‌های ابزار در هر مسیر، میانگین عمق پیام‌ها و تعداد کل کاراکترها در هر گفتگو است.
بینش‌های آماری کلیدی با استفاده از صدک‌ها (p50, p90) برای شناسایی داده‌های پرت استخراج می‌شوند. برای مثال، سیستم ردیابی می‌کند که در چند مسیر، تنها سه پیام اول از حد مجاز MAX_SEQ_LEN (۲۰۴۸ توکن) فراتر می‌روند. همچنین فراوانی استفاده از ابزارها و توزیع کلیدهای آرگومان نقشه‌برداری می‌شود تا مشخص شود کدام توابع رایج‌تر هستند و کدام آرگومان‌ها بیشترین نیاز را دارند. این داده‌ها در نهایت با هیستوگرام برای فراخوانی‌های ابزار و عمق پیام‌ها، و نمودارهای ستونی برای فراوانی استفاده از ابزارها بصری‌سازی می‌شوند.
معیارهای تفصیلی پیکره
- توزیع ابزار: استفاده از
Counterبرای ردیابی دقیق اینکه کدام ابزارها در ۴۰۰ نمونه استریم شده بیشترین فراخوانی را داشته‌اند. - تحلیل آرگومان: استفاده از
defaultdict(Counter)برای نقشه‌برداری از رایج‌ترین کلیدهای آرگومان برای هر نام ابزار خاص. - تراکم کاراکتر: محاسبه تعداد کل کاراکترها در هر مسیر؛ به‌طوری که مشاهده شده ۱۰٪ از طولانی‌ترین مسیرها، درصد نامتناسبی از کل کاراکترهای پیکره را به خود اختصاص داده‌اند.
- عمق مسیر: محاسبه میانگین و صدک ۹۰ عمق پیام‌ها برای تعیین میانگین تعداد نوبت‌های (Turns) لازم جهت رسیدن به پاسخ نهایی.
حفظ زنجیره تفکر
یک جزئیات فنی حیاتی در نحوه توکن‌سازی (Tokenization) — یعنی تبدیل متن به تکه‌های کوچک شبیه برش‌های کیک که مدل می‌خورد — نهفته است. این راهنما هشدار می‌دهد که از قالب‌های چت استاندارد برای Qwen3 استفاده نکنید، زیرا این قالب‌ها اغلب بلوک‌های <think> را از نوبت‌های دستیار حذف می‌کنند، مگر در آخرین نوبت. در مجموعه‌ای مثل XYZ-Aquila-SFT، این اتفاق باعث نابودی خاموش اکثر نظارت‌های استدلالی می‌شود که توسعه‌دهنده برای آموزش مدل هزینه کرده است.
با رندر دستی ChatML، خط لوله تضمین می‌کند که مدل روی فرآیند واقعی استدلال آموزش ببیند. این پیاده‌سازی دستی از توکن‌های خاص <|im_start|> برای شروع یک نقش، <|im_end|> برای پایان و خطوط جدید برای جداسازی استفاده می‌کند. این رویکرد کنترل دقیقی روی توالی توکن‌ها ایجاد کرده و تضمین می‌کند که بلوک‌های استدلال حفظ شوند و مدل انتقال از «تفکر» به «عمل» را بیاموزد.
مشخصات آموزش
برای بهینه‌سازی فرآیند در GPUهای سازگار با کولب، از لورا (LoRA - Low-Rank Adaptation) استفاده شده است تا فرآیند به اندازه کافی کارآمد باشد. خط لوله قابلیت‌های سخت‌افزاری را شناسایی کرده و در صورت پشتیبانی CUDA، از دقت BF16 (Bfloat16) و در غیر این صورت از FP16 یا FP32 استفاده می‌کند.
جزئیات کلیدی پیکربندی عبارتند از:
- مدل: Qwen3-0.6B
- نرخ یادگیری: 1e-4 با زمان‌بندی کسینوسی (Cosine Schedule) و ۵ گام گرم‌کردن (Warmup)
- رتبه لورا (R): ۱۶ (با
lora_alphaبرابر ۳۲) - تجمع گرادیان: ۸ گام، که منجر به پردازش ۸ مسیر در هر گام بهینه‌سازی می‌شود
- حداکثر گام‌ها: ۳۰ گام برای تست اولیه (Smoke Test)
- دقت: BF16 (در صورت پشتیبانی) یا FP16 از طریق
torch.amp.GradScaler - بهینه‌ساز: AdamW با کاهش وزن (Weight Decay) ۰.۰ و بتای (۰.۹, ۰.۹۵)
ماسک‌گذاری زیان (Loss Masking) به‌طور سخت‌گیرانه روی توکن‌های تولیدشده توسط دستیار اعمال می‌شود. خط لوله برچسب‌هایی ایجاد می‌کند که در آن‌ها توکن‌های کاربر و سیستم روی -100 تنظیم می‌شوند؛ این بدان معناست که مدل برای ورودی‌های کاربر یا تعاریف ابزار سیستم جریمه نمی‌شود، بلکه فقط برای پیش‌بینی‌های خودش جریمه می‌شود. این کار تضمین می‌کند که به‌روزرسانی‌های گرادیان منحصراً روی استدلال و رفتار فراخوانی ابزار دستیار متمرکز باشد.
جزئیات پیاده‌سازی
- کلاس مجموعه داده: استفاده از یک کلاس سفارشی
SFTSetدر PyTorch برای بسته‌بندی نمونه‌های کدگذاری‌شده. - Collator: یک تابع
collateسفارشی برای مدیریت پدینگ پویا با استفاده ازpad_token_idتوکن‌ساز و اطمینان از اینکه برچسب‌های پدینگ با-100پر شده‌اند تا در محاسبه زیان نادیده گرفته شوند. - بهینه‌سازی حافظه: فعال‌سازی
gradient_checkpointing_enable()وenable_input_require_grads()برای کاهش مصرف VRAM در طول گذر پس‌رو (Backward Pass). - نسبت نظارت: محاسبه میانگین نسبت توکن‌های نظارت‌شده (درصد توکن‌هایی در یک توالی که ماسک نشده‌اند)، که معیاری برای سنجش میزان سیگنال یادگیری واقعی در هر نمونه فراهم می‌کند.
سنجش موفقیت با پروب‌های Teacher-Forced
برای ارزیابی مدل، از «پروب‌های Teacher-Forced» استفاده می‌شود. این‌ها مسیرهایی هستند که دقیقاً پیش از نوبت دستیار (جایی که باید یک فراخوانی ابزار صادر شود) قطع شده‌اند. مدل پیشوند گفتگو (تاریخچه گفتگو تا آن نقطه) را دریافت کرده و باید فراخوانی ابزار طلایی (Gold Tool Call) را تولید کند. برای تضمین اعتبار، پروب‌ها تنها زمانی ساخته می‌شوند که طول پیشوند در محدوده MAX_SEQ_LEN - 160 توکن باشد.
عملکرد بر اساس سه معیار اصلی سنجیده می‌شود:
- قابلیت تجزیه (Parseability): آیا خروجی تولید شده یک شیء JSON معتبر است که توسط اسکنر امن تو در تو قابل استخراج باشد؟
- صحت نام ابزار (Tool-Name Accuracy): آیا مدل نام دقیق تابعی را که در برچسب طلایی آمده بود، پیش‌بینی کرده است؟
- امتیاز F1 کلیدهای آرگومان (Arg-Key F1 Score): معیاری برای سنجش دقت مدل در شناسایی کلیدهای مورد نیاز آرگومان‌ها. این مقدار به صورت
2 * intersection / (predicted_keys + gold_keys)محاسبه می‌شود.
با اجرای این پروب‌ها پیش و پس از آموزش، خط لوله یک دلتای (تغییر) واضح در عملکرد ارائه می‌دهد و نشان می‌دهد که آداپتور لورا دقیقاً چقدر توانایی مدل را در پیروی از طرحواره ابزار بهبود بخشیده است.
استخراج مصنوعات عامل‌محور
مرحله نهایی شامل استخراج آداپتور لورا آموزش‌دیده و یک نسخه ساختاریافته از مجموعه داده به دایرکتوری خروجی (/content/aquila_out) است. این کار تکرارپذیری کار را تضمین کرده و داده‌ها را برای آزمایشات بیشتر آماده می‌کند.
مصنوعات استخراج‌شده عبارتند از:
- آداپتور لورا: وزن‌های آموزش‌دیده و توکن‌ساز مرتبط که از طریق
save_pretrainedذخیره شده‌اند. - JSONL ساختاریافته: فایلی (
aquila_en_structured_tools.jsonl) حاوی تمام مسیرهای تجزیه‌شده که در آن پیام‌ها، طرحواره‌های ابزار، پرسش‌ها و پاسخ‌ها در یک فرمت ساختاریافته استخراج شده‌اند. - JSON آمار پیکره: یک گزارش جامع (
corpus_stats.json) شامل تعداد کل مسیرها، فراوانی ابزارها، میانگین فراخوانی‌های ابزار، صدک ۹۰ عمق و میانگین نسبت توکن‌های نظارت‌شده.
به گزارش Marktechpost، این گردش‌کار زیربنایی برای مقیاس‌دهی SFT آگاه از ابزار و آزمایش سیاست‌های جایگزین طول توالی برای مدل‌های عامل‌محور فراهم می‌کند. استفاده از سیاست طول «برش» (Truncate) تضمین می‌کند که حیاتی‌ترین بخش‌های ابتدایی گفتگو حتی در مسیرهای بسیار طولانی حفظ شوند.
این چرخش به سمت تنظیم دقیق مدل‌های کوچک تخصصی نشان می‌دهد که آینده عامل‌ها تنها در مدل‌های بزرگ‌تر نیست، بلکه در نظارت ساختاریافته بر حلقه «استدلال-عمل» است. با تمرکز بر استخراج دقیق فراخوانی‌ها و حفظ بلوک‌های تفکر، توسعه‌دهندگان می‌توانند عامل‌های سبک‌وزن و قابل‌اعتمادی بسازند که در یک سطح API تعریف‌شده به‌درستی عمل کنند.
اگر در حال ساخت یک عامل برای محیط عملیاتی (Production) هستید، گام بعدی شما باید آزمایش این خط لوله روی طرحواره‌های ابزار اختصاصی خودتان باشد تا ببینید آیا لورا می‌تواند دقت را در سطح API خاص شما حفظ کند یا خیر.
گفتگو