تبدیل لاگ‌های خام عامل‌های انویدیا به داده‌های آموزشی SFT

آیا یک مدل واقعاً می‌تواند از دل آشوبِ لاگ‌های خامِ عامل‌ها، کدنویسی بیاموزد؟ برای ساختن یک عامل کدنویس که در دنیای واقعی جواب دهد، داشتن یک مدل بزرگ کافی نیست؛ شما به رژیم غذایی دقیقی از مسیرهای موفق در حل مسئله نیاز دارید.

انویدیا (NVIDIA) با ارائه مجموعه داده Open-SWE-Traces مواد اولیه را فراهم کرده است، اما چالش اصلی در تبدیل این لاگ‌ها به قالبی است که مدل بتواند از آن درس بگیرد. طبق گزارش‌های فنی، اکثر داده‌های عامل‌محور (Agentic) آشفته هستند و شامل تلاش‌های شکست‌خورده، فراخوانی‌های تکراری ابزار و جهش‌های عظیم توکنی می‌شوند که می‌توانند کل فرآیند آموزش را مختل کنند. در واقع، بسیاری از این لاگ‌ها حاوی تکرارهای بی‌پایان یا رفتارهای غیرمنطقی مدل هستند که اگر بدون پالایش وارد مرحله آموزش شوند، باعث کاهش کیفیت استدلال مدل نهایی می‌گردند.

برای حل این مشکل، چارچوبی عملی برای استریم، تحلیل و پالایش این داده‌ها منتشر شده است تا نیاز به فضای ذخیره‌سازی محلی عظیم نباشد. این روش به توسعه‌دهندگان اجازه می‌دهد لحظات دقیق موفقیت عامل را ایزوله کرده و نویزِ هزاران شکست را دور بریزند. همان‌طور که در تحلیل‌های پیشین ما درباره امنیت مدل‌های بازمتن اشاره کردیم، کیفیت داده‌های آموزشی بیش از هر چیز بر پایداری رفتار مدل اثر می‌گذارد. این رویکرد به جای تکیه بر حجم انبوه داده، بر «داده‌های با کیفیت» متمرکز است تا از overfitting روی الگوهای غلط جلوگیری شود.

این فرآیند در محیط‌هایی مثل گوگل کولب (Google Colab) که فضای دیسک محدودی دارند، بسیار حیاتی است چون داده‌ها مستقیماً از هگینگ فیس (Hugging Face) استریم می‌شوند تا گلوگاه‌های دانلود محلی برطرف شود. این سیستم از کمک‌کننده‌های نرمال‌سازی برای مدیریت طرح‌های داده‌ای متفاوت در ترکیب‌های مختلف عامل-مدل استفاده می‌کند، زیرا هر مدل و هر فریم‌ورک عامل، ساختار لاگ متفاوتی دارد.

به طور خاص، این متد روی ترکیباتی مثل عامل‌های openhands و sweagent در کنار مدل‌هایی نظیر minimax_m25 و qwen35_122b تمرکز دارد. برای حفظ کارایی نمونه‌برداری و جلوگیری از مصرف بیش از حد منابع، چارچوب را می‌توان طوری تنظیم کرد که تعداد مشخصی سطر (مثلاً ۴۰۰ سطر برای هر ترکیب که با PER_COMBO = 400 تعریف شده) یا یک نمونه کلی ۱۵۰۰ تایی (با متغیر N_SINGLE = 1500) استخراج کند.

مکانیسم‌های تجزیه فنی

برای کاربردی کردن داده‌ها، این خط لوله چندین مکانیسم تجزیه (Parsing) حیاتی را اجرا می‌کند که بر استحکام در برابر تغییرات طرح (Schema) متمرکز هستند:

• نرمال‌سازی مسیر (Trajectory Normalization): تبدیل پیام‌های خام JSON یا رشته‌ای به یک فرمت نقش‌محور ثابت. این بخش مواردی را مدیریت می‌کند که در آن پیام‌ها به صورت لیستی از بلوک‌ها یا رشته‌های ساده ذخیره شده‌اند و اطمینان حاصل می‌کند که نقش‌های system ،user ،assistant و tool توسط تابع normalize_trajectory به درستی شناسایی و دسته‌بندی شوند.
• تشخیص استفاده از ابزار (Tool-Use Detection): استفاده از عبارت‌های منظم (Regex) و تجزیه XML برای شناسایی فراخوانی‌های عملیاتی دقیق. سیستم با استفاده از _FUNC_XML به دنبال تگ‌های <function = ...> می‌گردد، با _EXEC_TAG تگ‌های <execute_...> را ردیابی می‌کند و با استفاده از _BASH_FENCE محیط‌های Bash (مانند bash، sh یا ```shell) را شناسایی می‌کند تا رفتار عامل از طریق ابزار extract_tool_names دسته‌بندی شود.
• تحلیل پچ (Patch Analysis): یک تجزیه‌کننده تخصصی به نام parse_patch که فیلد model_patch را بررسی می‌کند. این بخش با شمارش خطوطی که با + شروع می‌شوند (به جز +++) و خطوطی که با - شروع می‌شوند (به جز ---)، میزان «تغییرات پچ» یا Patch Churn را محاسبه می‌کند. همچنین با تجزیه خطوط diff --git نام فایل‌ها را شناسایی کرده و با استفاده از یک Counter، پسوندهای فایل‌های تغییر یافته را ردیابی می‌کند.
• نرمال‌سازی متادیتا (Metadata Normalization): استفاده از تابع normalize_metadata برای اطمینان از اینکه فیلدهایی مانند category (دسته‌بندی)، num_modified_files (تعداد کل فایل‌های تغییر یافته) و num_modified_lines (تعداد کل خطوط تغییر یافته) از حالت رشته‌ای خام به دیکشنری‌های کاربردی تبدیل شوند.

کالبدشکافی رکوردها

هر رکورد در Open-SWE-Traces شامل شناسه‌های غنی و نتایج خروجی است. یک نمونه مسیر شامل instance_id (شناسه نمونه)، نام مخزن یا repo و زبان برنامه‌نویسی است. همچنین لایسنس کد و وضعیت resolved ردیابی می‌شود، که در آن مقدار ۱ به معنای موفقیت در حل مسئله، ۰ به معنای شکست و ۱- به معنای وضعیت نامشخص است.

در هنگام بررسی یک مسیر، چارچوب با استفاده از تابع role_counts هیستوگرام نقش‌ها را تحلیل می‌کند تا تعادل بین پاسخ‌های دستیار و خروجی‌های ابزار را بسنجد. برای مثال، در یک بازبینی سریع، پیام‌ها به ۲۴۰ کاراکتر برش می‌خورند تا توسعه‌دهنده بتواند پیش از تحلیل کامل هزاران توکن موجود در یک ردپای کامل، جریان منطقی (Logic Flow) را پیش‌نمایش کند.

محاسبه بودجه توکن

یکی از حیاتی‌ترین بخش‌ها، تعیین پنجره زمینه (Context Window) است — مثل میز کاری که فقط جای چند ورق کاغذ دارد و مدل نمی‌تواند کل کتابخانه را هم‌زمان در ذهن نگه دارد. تحلیل‌ها نشان می‌دهد طول مسیرها به‌شدت متفاوت است و برای مدیریت این تفاوت‌ها، توسعه‌دهندگان با محاسبه صدک‌ها (p50، p75، p90، p95 و p99)، متوجه می‌شوند چه تعداد از مسیرها در پنجره‌های استاندارد جای می‌گیرند.

برای دستیابی به این تحلیل، خط لوله از ابزار make_token_counter استفاده می‌کند که ابتدا سعی می‌کند از رمزگذاری cl100k_base کتابخانه tiktoken استفاده کند؛ در صورت عدم دسترسی، از یک روش تخمینی (Heuristic) یعنی ۱ توکن به ازای هر ۴ کاراکتر استفاده می‌کند.

تحلیل داده‌ها نشان می‌دهد که محدودیت‌های مختلف زمینه چگونه بر میزان پذیرش داده‌ها در مجموعه اثر می‌گذارد:

• ۸,۱۹۲ توکن: تنها بخش بسیار کوچکی از مسیرها در این محدوده جای می‌گیرند و اکثر داده‌های مهندسی نرم‌افزار حذف می‌شوند.
• ۳۲,۷۶۸ توکن: حد وسط مناسب برای بسیاری از وظایف تنظیم نظارت‌شده (SFT) و مقدار پیش‌فرض برای MAX_SFT_TOKENS است.
• ۱۳۱,۰۷۲ توکن: برای طولانی‌ترین و پیچیده‌ترین ردپاهای مهندسی نرم‌افزار که نیاز به بررسی فایل‌های متعدد دارد، ضروری است.

برای جلوگیری از خطای «کمبود حافظه» (Out-of-memory) حین آموزش SFT، توزیع طول توکن‌ها ردیابی می‌شود. با برش داده‌های پرت (Outliers) در صدک ۹۷ برای اندازه پچ و صدک ۹۹ برای کل توکن‌ها، خط لوله تضمین می‌کند که مجموعه آموزشی از نظر محاسباتی بهینه باقی بماند و در عین حال نماینده واقعی اصلاحات کد در دنیای واقعی باشد.

تحلیل رفتار و موفقیت عامل‌ها

علاوه بر توکن‌ها، این چارچوب عملکرد پیکربندی‌های مختلف را می‌سنجد. این شامل محاسبه نرخ حل مسئله (Resolution Rate) بر اساس زبان برنامه‌نویسی است، به گونه‌ای که فقط زبان‌هایی با حداقل ۲۵ نمونه تحلیل می‌شوند تا اعتبار آماری نتایج تضمین شود.

با ایجاد یک جدول محوری (Pivot Table) از «داربست در برابر مدل» (Scaffold x Model)، توسعه‌دهندگان می‌توانند نرخ موفقیت openhands را در برابر sweagent در مدل‌های مختلف مقایسه کنند. این تحلیل مشخص می‌کند کدام ترکیب عامل-مدل در حل باگ‌های خاص موفق‌تر است. برای درک بصری بهتر، این نتایج با رنگ‌های متمایز (مثلاً آبی برای یک مدل و نارنجی برای مدل دیگر) نمایش داده می‌شوند.

تحلیل استفاده از ابزار نیز با تجمیع فراخوانی‌ها از طریق ستون _tools ،۱۲ ابزار پرتکرار را شناسایی می‌کند. سیستم همچنین میانگین تعداد دفعات تعامل با محیط (Tool Turns) را در مسیرهای موفق در برابر ناموفق مقایسه می‌کند تا determine کند آیا تعامل بیشتر- یعنی رفت و برگشت بیشتر بین مدل و محیط- لزوماً به نرخ موفقیت بالاتر منجر می‌شود یا خیر.

پالایش برای کیفیت

گام نهایی، ساخت یک زیرمجموعه SFT گلچین‌شده است. به جای استفاده از تمام داده‌های موجود، خط لوله از طریق تابع passes_filters فیلترهای سخت‌گیرانه‌ای را اعمال می‌کند تا مدل فقط از «نمونه‌های طلایی» یاد بگیرد. به نقل از آموزش منتشر شده توسط Marktechpost، سیستم بر اساس این معیارها پالایش می‌کند:

• وضعیت حل مسئله: اگر SFT_REQUIRE_RESOLVED برابر True باشد، فقط مسیرهایی که با موفقیت به پایان رسیده‌اند (resolved == 1) نگه داشته می‌شوند تا مدل الگوهای شکست یا مسیرهای بن‌بست را یاد نگیرد.
• محدودیت توکن: هر نمونه‌ای که از بودجه تعریف‌شده (مثلاً MAX_SFT_TOKENS = 32000) فراتر رود، برای سازگاری با سخت‌افزار و جلوگیری از کرش کردن آموزش حذف می‌شود.
• در دسترس بودن پچ: اگر فیلد model_patch خالی باشد یا فقط شامل فضای خالی (Whitespace) باشد، نمونه حذف می‌شود چون هدف آموزشی (Target Code) برای یادگیری مدل فراهم نیست.
• فیلتر زبان: امکان هدف‌گذاری روی زبان‌های برنامه‌نویسی خاص (از طریق SFT_LANGUAGES) برای ساخت مدل‌های کدنویسی تخصصی و بهینه شده برای یک زبان خاص.

در نهایت، داده‌های پالایش‌شده از طریق تابع to_chatml به فرمت ChatML تبدیل می‌شوند. این فرآیند، توالی پیچیده فراخوانی ابزارها و پاسخ‌های محیط را به یک زنجیره تمیز از توکن‌های <|im_start|>{role}\n{content}<|im_end|> تبدیل می‌کند. این فرمت‌بندی تضمین می‌کند که مدل nature تعاملی و نوبتی (Turn-taking) بین عامل و محیط را به درستی درک کند.

خروجی نهایی یک فایل JSONL است که شامل instance_id ،repo ،language ،agent ،model و لیست پیام‌های فرمت‌شده (messages) به همراه model_patch و تعداد تقریبی توکن‌ها (approx_tokens) است. این فایل برای استفاده فوری در خط لوله تنظیم دقیق با دستور datasets.load_dataset('json', data_files='open_swe_sft.jsonl') آماده است.

خروجی برای تولید

این فرآیند با استخراج دو اثر اصلی پایان می‌یابد: اول، یک فایل CSV جامع از تحلیل‌ها (open_swe_traces_analysis.csv) که حاوی متریک‌های پردازش شده برای هر سطر استریم شده است—شامل n_messages (تعداد پیام‌ها)، n_assistant (تعداد پاسخ‌های دستیار)، n_tool (تعداد پاسخ‌های ابزار) و patch_churn (میزان تغییرات کد)—در حالی که لیست خام ابزارها برای کوتاهی فایل حذف شده است. دوم، فایل JSONL پالایش‌شده SFT که مشاهدات خام را به جفت‌های آموزشی تبدیل می‌کند.

چرخش از «داده‌های حجیم» (Big Data) به «داده‌های هوشمند» (Smart Data)، کلید بهبود استدلال عامل‌ها است. با اولویت دادن به کیفیت مسیر بر کمیت لاگ‌ها، زمان آموزش کاهش و نرخ موفقیت مدل نهایی افزایش می‌یابد.

برای کسانی که این سیستم را پیاده می‌کنند، اثر ثانویه، کاهش چشمگیر توهم (Hallucination)—وقتی مدل با اطمینان چیزی می‌گوید که وجود ندارد، شبیه دوستی که خاطره‌ای را اشتباه تعریف می‌کند—در فراخوانی ابزارهاست. مدل یاد می‌گیرد دقیقاً کدام توالی از اقدامات به نتیجه می‌رسد، نه اینکه فقط ظاهر یک برنامه‌نویس را تقلید کند.

برای شروع، توسعه‌دهندگان باید مخزن Open-SWE-Traces را در Hugging Face بررسی کنند و تحلیل بودجه توکن را پیاده‌سازی کنند تا متوجه شوند آیا سخت‌افزار فعلی آن‌ها می‌تواند پنجره‌های زمینه مورد نیاز را پشتیبانی کند یا خیر. این رویکرد سیستماتیک—استریم، تجزیه، تحلیل و پالایش—یک مجموعه داده خام را به ابزاری دقیق برای بهبود مدل تبدیل می‌کند.

گام بعدی شما

• مخزن Open-SWE-Traces را در Hugging Face بررسی کنید تا با ساختار لاگ‌های واقعی آشنا شوید.
• تحلیل بودجه توکن را روی سخت‌افزار خود اجرا کنید تا متوجه شوید چه اندازه پنجره زمینه‌ای را پشتیبانی می‌کنید.
• از فیلتر resolved == 1 برای پاک‌سازی داده‌های آموزشی خود استفاده کنید تا مدل از اشتباهات درس نگیرد.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell و مدیریت حافظه VRAM مراجعه کنید.