‏ترکیب مدل‌های هوش مصنوعی تو workflow کدنویسی

ترکیب مدل‌ها یعنی یه pipeline کدنویسی با AI رو به چند مرحله بشکنی و هر مرحله رو به مدلی بدی که براش مناسب‌تره، نه این که همه‌چی از یه مدل گرون رد بشه. به گفتهٔ این مقاله، معمولاً یه مدل بستهٔ قوی مثل Claude Opus یا بهترین مدل GPT برنامه‌ریزی و بازبینی رو انجام می‌ده، جایی که قضاوت و استدلال روی متن طولانی مهمه. بعد یه مدل open-weight ارزون‌تر (یعنی مدلی که وزن‌هاش عمومیه و می‌شه خودت اجراش کنی) مثل Kimi K2، GLM یا Qwen حجم اصلی کدنویسی رو برمی‌داره.

نویسنده می‌گه مشکل مدل‌های اپن‌ویت توانایی خام نیست، بلکه تمرکز و ثبات تو طول زمانه. اسمش رو می‌ذاره drift، یعنی agent کم‌کم قوانینی رو که اول کار بهش گفتن نادیده می‌گیره؛ مثلاً به فایل‌های فقط‌خواندنی دست می‌زنه یا مراحل بازبینی رو رعایت نمی‌کنه. هر تخلف تو بازبینی گرفته می‌شه و یه دور دیگه تکرار لازم می‌شه. نتیجه اینه که مدل ارزون کلی توکن خرج درست کردن همون اشتباه‌ها می‌کنه و ممکنه مزیت قیمتی‌ش از بین بره.

تو یه تست کنترل‌شده، یه بازی کوچیک با ۱۲ تیکت سه بار ساخته شد. Claude همهٔ تیکت‌ها رو تو حدود ۱۴ ساعت تموم کرد. GPT یازده تیکت رو تقریباً تو دو برابر اون زمان بست. Kimi K2 تو ۴۴ ساعت فقط ۵ تیکت رو تموم کرد و چند بار ساعت‌ها گیر کرد؛ برای همین قابلیتی مثل فروشگاه ارتقای داخل بازی اصلاً ساخته نشد. تو بنچمارک‌های کوتاه مثل Terminal Bench 4.0 مدل‌های اپن‌ویت هم‌سطح یا بهترن، ولی تو بنچمارک‌های بلندمدت مثل Terminal Bench Science و Frontier Code 2.0 فاصله زیاد می‌شه.

با این حال، مقاله می‌گه مدل‌های اپن‌ویت تو مراحل کوتاه و مشخص که بخش بزرگی از اتوماسیون‌های سازمانی‌ان، با کسری از هزینه هم‌سطح مدل‌های بسته کار می‌کنن. یه دلیل دیگه هم هست: API مدل‌های بسته محدودیت نرخ داره، قیمتش ممکنه عوض بشه و تضمینی برای شرایط فعلی نیست. اجرای محلی یه مدل اپن‌ویت هم یعنی داده‌های حساس به یه API بیرونی فرستاده نمی‌شه.

ساختار پیشنهادی مقاله سه نقش داره: مدل قوی کار رو به یه برنامهٔ روشن تبدیل می‌کنه و قوانین پروژه رو اعمال می‌کنه. مدل ارزون‌تر به‌عنوان workhorse برنامه رو اجرا می‌کنه، جایی که بیشترین توکن خرج می‌شه و صرفه‌جویی هم همون‌جاست. بعد دوباره مدل قوی خروجی رو با برنامه مقایسه می‌کنه، تخلف‌ها رو می‌گیره و قبل از merge تستش می‌کنه. نویسنده تأکید می‌کنه نباید سطح بازبینی رو به‌خاطر اشتباه‌های مدل ضعیف‌تر پایین آورد، چون کل فایدهٔ این ساختار همینه.

هزینهٔ اصلی این روش مهندسیه: ساختن یه harness (یعنی قوانین، مرحلهٔ برنامه‌ریزی و مرحلهٔ بازبینی دور مدل) که واقعاً جلوی اشتباه‌ها رو بگیره. بدون این ساختار، دادن کارهای طولانی و مبهم به مدل ارزون بیشتر دوباره‌کاری میاره تا صرفه‌جویی. ولی وقتی ساخته شد، به گفتهٔ نویسنده حساب‌وکتاب به نفع ترکیب مدل‌هاست و وابستگی به گرون‌ترین مدل هم کم می‌شه.

نکات کلیدی:

• برنامه‌ریزی و بازبینی با مدل بسته (مثل Claude Opus)، اجرا با مدل ارزون (مثل Kimi K2، GLM یا Qwen).
• تو تست ساخت بازی: Claude ۱۲ از ۱۲ تیکت در حدود ۱۴ ساعت، Kimi K2 فقط ۵ از ۱۲ در ۴۴ ساعت.
• مدل‌های اپن‌ویت تو Terminal Bench 4.0 رقابتی‌ان، ولی تو Terminal Bench Science و Frontier Code 2.0 عقب می‌مونن.
• تو یه بنچمارک بلندمدت، یه مدل پیشرو حدود ۴۱.۶ درصد و یه مدل اپن‌ویت حدود ۲۲.۱ درصد گرفته.
• پایین آوردن سطح بازبینی برای کنار اومدن با مدل ضعیف‌تر، کل فایدهٔ این ساختار رو از بین می‌بره.