زمانی که صحبت از Production کردن LLM میشه، دوتا قاتل اصلی داریم: هزینه و Latency. اکثر ماژول‌های هوش مصنوعی الان دارن بخش عظیمی از Context Window رو با System Prompt‌های طولانی و Few-Shot Example‌های تکراری پر می‌کنن. این یعنی هر بار داریم پول میدیم که مدل همون دستورالعمل‌های تکراری رو بخونه تا فقط یک تسک خاص رو انجام بده.

تکنیک PromptIntern دقیقا دست گذاشته روی همین نقطه درد. ایده اصلی اینه: به جای اینکه هر بار پرامپت رو به مدل بدیم (In-Context Learning) یا پرامپت رو فشرده کنیم (Prompt Compression) که باعث افت دقت میشه، بیایم دانشِ داخل پرامپت رو بفرستیم توی وزن‌های مدل (Model Weights).

مفهوم اصلی اینجا Internalizing هست. توی روش‌های معمول Fine-tuning، ما معمولا Input/Output خام رو میدیم. اما این مقاله میگه اگر مدل رو با پرامپت کامل Fine-tune کنیم و به مرور زمان در طول پروسه آموزش، پرامپت رو حذف کنیم، مدل "یاد می‌گیره" که اون کانتکست رو درونی‌سازی کنه.

معماری و پایپ‌لاین PromptIntern روی سه مرحله سوار شده که بهش میگن Progressive Fine-tuning:

مرحله اول (Full Context): مدل با پرامپت کامل شامل Template (دستورالعمل‌ها) و Examples (چند شات) آموزش می‌بینه.
مرحله دوم (Fading Out): با یک برنامه زمانی (Schedule) خطی، شروع می‌کنیم به فشرده‌سازی Template و کم کردن تعداد Example‌ها. یعنی مدل کم‌کم داره عصا رو از زیر بغلش میندازه.
مرحله سوم (Internalized): در انتهای آموزش، مدل فقط با Query کاربر آموزش می‌بینه و تمام کانتکست قبلی رو حذف می‌کنیم.

نتیجه این روش روی تسک‌های NL2Code (مثل تبدیل متن به کد پایتون یا Bash) وحشتناک خوب بوده. کاهش بیش از ۹۰ درصدی توکن‌های ورودی و افزایش سرعت Inference تا ۴.۲ برابر. نکته جالب اینجاست که دقت مدل (Accuracy) نه تنها افت نکرده، بلکه از روش‌های Prompt Compression مثل LLMLingua هم خیلی بهتر عمل کرده و به دقت مدل با پرامپت کامل رسیده.

به نظر من، این روش عملاً پیاده‌سازی Curriculum Learning روی فضای Prompt Engineering هست. ما داریم با مدل مثل یک کارآموز (Intern) رفتار می‌کنیم؛ اولش داکیومنت کامل میدیم، بعد کم‌کم راهنمایی رو کم می‌کنیم تا خودش مسلط بشه.

نکته فنی مهم برای پیاده‌سازی:
کلید ماجرا توی Schedule هست. مقاله نشون داده که کاهش خطی (Linear Decay) برای حذف Template و Example‌ها بهترین نتیجه رو میده. اگر یهویی حذف کنید (Step decay) مدل گیج میشه و اگر خیلی کند حذف کنید (Exponential) مدل Overfit میشه روی پرامپت. برای پیاده‌سازی کافیه توی لوپ ترینینگ LoRA، دیتالودر رو داینامیک کنید که بر اساس Epoch جاری، بخش‌هایی از پرامپت رو Mask یا حذف کنه.

این روش برای کسانی که دارن روی Agent‌های تخصصی کار می‌کنن (مثلاً ایجنت SQL Generator یا Code Reviewer) که همیشه یک پرامپت ثابتِ سنگین دارن، الزامیه. برای Chatbot‌های عمومی شاید خیلی کاربرد نداشته باشه چون پرامپت دائم عوض میشه.

📃 لینک مقاله: PromptIntern: Saving Inference Costs by Internalizing Recurrent Prompt
https://arxiv.org/abs/2404.14256

🛠 Join @LLMEngineers Community

اغلب ما وقتی سراغ Fine-tuning مدل‌های Transformer-based میریم، یا روش Full Fine-tuning رو انتخاب می‌کنیم که هزینه محاسباتی سنگینی داره، یا میریم سراغ متدهای PEFT مثل LoRA و Adapter. مشکل اینجاست که اکثر این روش‌ها یه فرض غلط دارن: "تاثیر تمام لایه‌ها (Transformer Blocks) در یادگیری تسک جدید یکسانه." در صورتی که در عمل، لایه‌های پایین‌تر فیچرهای عمومی زبان رو نگه میدارن و لایه‌های بالاتر مسئول درک معنایی خاص اون تسک هستن.

معماری Progtuning دقیقا دست می‌ذاره روی همین عدم تعادل. این فریم‌ورک یه روش Progressive Learning رو وارد پروسه فاین‌تیون می‌کنه تا منابع محاسباتی رو هوشمندتر خرج کنه. ایده اصلی اینه: به جای اینکه در تمام Epochها همه لایه‌ها رو آپدیت کنیم، بیایم به مرور زمان لایه‌های پایین رو از چرخه آپدیت خارج کنیم و تمرکز رو بذاریم روی لایه‌های بالا.

ساختار Progtuning به این صورته که کل پروسه آموزش رو به چند Stage تقسیم می‌کنه. در استیج‌های اول، لایه‌های بیشتری (از جمله لایه‌های پایین) درگیر Backward Propagation میشن تا مدل بتونه تغییرات بنیادی رو یاد بگیره. اما هرچی جلوتر میریم، لایه‌های پایین فریز میشن و فقط لایه‌های High-level آپدیت میشن. این یعنی ما عملاً داریم تعداد Updated Parameters رو در طول زمان کاهش میدیم (Shrinking Stages).

نکته فنی مهم اینجاست که Progtuning خودش یه الگوریتم لرنینگ جدید نیست، بلکه یه متدولوژی زمان‌بندی (Scheduling) برای آپدیت وزن‌هاست. به همین خاطر به شدت Adaptable هست و میشه اون رو با LoRA یا BitFit ترکیب کرد. مثلا وقتی LoRA + Progtuning می‌زنید، ماتریس‌های LoRA در لایه‌های پایین زودتر فریز میشن و فقط ماتریس‌های لایه‌های آخر تا انتهای ترینینگ آپدیت میشن.

طبق بنچمارک‌های GLUE و SQuAD، این روش تونسته حدود ۲۵ درصد تعداد پارامترهای آپدیت‌شونده رو کاهش بده (در مقایسه با فاین‌تیون استاندارد) و جالب اینجاست که پرفورمنس نه تنها افت نکرده، بلکه در مواردی مثل BERT-Large بهتر هم شده. دلیلش احتمالا کاهش Overfitting روی لایه‌های پایینه که معمولاً نیازی به تغییر زیاد برای Downstream Task ندارن.

به نظر من، این پیپر یه اثبات خوب برای بحث قدیمی "Layer Freezing" هست. توی Ablation Study نشون میده که اگر از اول لایه‌های پایین رو کامل فریز کنیم (Without Low Blocks)، پرفورمنس به شدت افت می‌کنه. پس لایه‌های پایین "باید" ترین بشن، اما نه به اندازه لایه‌های بالا. Progtuning عملاً این Decay رو اتوماتیک کرده. برای کسایی که GPU محدود دارن یا روی Edge Device میخوان مدل رو آپدیت کنن، ترکیب این روش با QLoRA می‌تونه خروجی خیلی بهینه‌ای بده.

📃 عنوان مقاله: Progtuning: Progressive Fine-tuning Framework for Transformer-based Language Models
https://openreview.net/pdf?id=0g0Xj5qiGg

🛠 Join @LLMEngineers Community

فاین‌تیون کردن مدل‌های LLM بزرگ (مثل 70B) همیشه دوتا چالش اصلی داره: یا سخت‌افزار سنگین می‌خواد که نداریم، یا وزن‌های مدل بسته‌س (مثل GPT-4) و دسترسی نداریم. مقاله‌ی Proxy-Tuning یه تکنیک decoding-time معرفی می‌کنه که بدون دست زدن به وزن‌های مدل اصلی، اون رو با استفاده از مدل‌های کوچیک‌تر هدایت کنین.

روش کار خیلی هکری و جالبه: فرض کنید یه مدل Llama2-70B-Base دارید و می‌خواید بشه Chat. جای اینکه ۷۰ میلیارد پارامتر رو آپدیت کنید، میرید یه مدل Llama2-7B برمی‌دارید، فاین‌تیونش می‌کنید (می‌شه Expert) و نسخه‌ی خامش رو هم نگه می‌دارید (می‌شه Anti-Expert).

توی زمان اینفرنس (Inference Time)، خروجی نهایی اینطوری محاسبه می‌شه:
Logits_Final = Logits_LargeBase + (Logits_SmallExpert - Logits_SmallAntiExpert)

ایده اصلی اینه که تفاوت بین مدل کوچیکِ تیون‌شده و تیون‌نشده، یه "جهت" یا Direction رو توی فضای احتمال توکن‌ها نشون می‌ده. ما این جهت رو برمی‌داریم و اعمال می‌کنیم روی مدل بزرگ. نتیجه؟ مدل بزرگِ خام، رفتار مدل تیون‌شده رو تقلید می‌کنه ولی دانش و قدرت استدلال خودش رو حفظ می‌کنه.

نکات فنی و نتایج عملی که از پیاده‌سازی این روش درمیاد:

عملکرد عجیب روی بنچ‌مارک‌ها: روی Llama2-70B، این روش تونسته ۸۸٪ فاصله‌ی بین مدل Base و مدلِ واقعیِ Chat (که کلی RLHF شده) رو پُر کنه. توی تسک‌های Knowledge-Intensive حتی بهتر از فاین‌تیون مستقیم عمل کرده، چون فرآیند فاین‌تیون مستقیم گاهی باعث Catastrophic Forgetting یا از دست رفتن دانش مدل می‌شه، اما اینجا وزن‌های اصلی دست‌نخورده باقی می‌مونن.

کاربرد روی مدل‌های Black-Box: حتی اگه به وزن‌ها دسترسی ندارید ولی به Logits دسترسی دارید (مثل بعضی APIها)، می‌تونید از این روش استفاده کنید. توی مقاله روی GPT-3.5 تست زدن (فقط با دسترسی به top-5 logits) و تونستن با یه مدل ۷ میلیاردی، خروجی GPT-3.5 رو برای رخدادهای زمانی جدید (Temporal Adaptation) اصلاح کنن.

به نظر من این تکنیک برای سناریوهای Enterprise که دیتای حساس دارن شاهکاره. شما یه مدل کوچیک ۷ میلیاردی رو روی دیتای خصوصی تیون می‌کنید (که ارزونه و سریعه) و بعد اون رو به عنوان یه "آداپتور زمان اجرا" می‌ذارید کنار یه مدل غول‌پیکر جنرال. بدون اینکه دیتای شما وارد پروسه سنگین آموزش مدل بزرگ بشه، استایل و فرمت رو منتقل کردید.

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

این روش یه حقیقت تلخ و شیرین رو هم درباره Alignment برملا می‌کنه: اینکه بخش بزرگی از چیزی که ما بهش می‌گیم "RLHF" یا "Instruction Tuning"، صرفاً تغییر استایل و فرمت خروجی‌ه، نه اضافه کردن دانش عمیق. مدل کوچیک استایل رو یاد می‌گیره و به مدل بزرگ تزریق می‌کنه.

لینک پیاده‌سازی و مقاله برای تست:

📃 Paper: Tuning Language Models by Proxy
https://arxiv.org/abs/2401.08565v4

💻 Code Implementation
https://github.com/alisawuffles/proxy-tuning

🛠 Join @LLMEngineers Community

فاین‌تیون کردن مدل‌های زبانی و تصویری لزوماً به معنی اضافه کردن لایه‌های Low-Rank مثل LoRA نیست. یه دیدگاه عمیق‌تر و ریاضی‌طور وجود داره به اسم Orthogonal Finetuning (OFT) که به جای اینکه بیاد یه ماتریس دلتا (Delta Weights) رو با وزن‌های اصلی جمع کنه، سعی می‌کنه نورون‌ها رو توی فضا "بچرخونه" تا روابط معنایی (Pairwise angles) بینشون حفظ بشه.

ایده اصلی اینه: وقتی شما با LoRA فاین‌تیون می‌کنی، ممکنه ساختار هندسی فضای ویژگی‌های مدل (Hyperspherical Energy) رو بهم بریزی چون داری یه نویز Low-Rank بهش اضافه می‌کنی. اما OFT میاد یک ماتریس Orthogonal یاد می‌گیره و در وزن‌های اصلی ضرب می‌کنه. اینطوری Norm ماتریس وزن‌ها ثابت می‌مونه و پایداری آموزش به شدت بالا میره.

مشکل OFT کجاست؟ هزینه محاسباتی و تعداد پارامترها. اگه بخوایم یه ماتریس Orthogonal کامل (Dense) بسازیم، تعداد پارامترها خیلی زیاد میشه. اگر هم بخوایم Block-Diagonal کار کنیم (مثل OFT معمولی)، تعامل بین فیچرها محدود میشه و Expressivity مدل میاد پایین.

راه حل جدید مقاله BOFT (Butterfly Orthogonal Finetuning) استفاده از ساختار Butterfly Factorization هست. این دقیقاً همون ایده‌ایه که توی الگوریتم Cooley-Tukey برای FFT (تبدیل فوریه سریع) استفاده میشه. به جای اینکه یک ماتریس گنده و پرهزینه یاد بگیریم، میایم اون رو به حاصل‌ضرب چندین ماتریس Sparse تجزیه می‌کنیم.

نکات فنی و معماری BOFT:

۱. دیدگاه انتقال اطلاعات (Information Transmission):
توی این معماری، ضرب ماتریس‌ها مثل انتقال اطلاعات توی یک شبکه Grid دیده میشه. ساختار Butterfly اجازه میده با کمترین تعداد یال (Edge)، اطلاعات از تمام نودهای ورودی به تمام نودهای خروجی برسه (Dense Connectivity) ولی با تعداد پارامتر کمتر
۲. حفظ ویژگی‌های طیفی (Spectral Properties):
برخلاف LoRA که ممکنه مقادیر ویژه (Singular Values) ماتریس وزن رو تغییر بده، BOFT به خاطر ماهیت Orthogonal بودن، Spectral Norm وزن‌های Pretrained رو دست‌نخورده نگه می‌داره. این یعنی دانش قبلی مدل بهتر حفظ میشه و کمتر دچار Catastrophic Forgetting میشیم.

۳. درونیابی وزن‌ها (Weight Interpolation):
یه ویژگی عجیب و جالب BOFT اینه که چون از ضرب چندین ماتریس متعامد تشکیل شده، شما می‌تونید بعد از آموزش، برخی از این ماتریس‌ها رو با ماتریس همانی (Identity) جایگزین کنید. این کار باعث میشه بتونید خیلی نرم بین مدل اصلی و مدل فاین‌تیون شده حرکت کنید (Interpolate) بدون اینکه نیاز به آموزش مجدد باشه. توی Stable Diffusion این قابلیت باعث میشه بتونید میزان تاثیر فاین‌تیون رو روی خروجی نهایی دقیق کنترل کنید.

۴. کاربرد در ویژن و زبان:
توی بنچ‌مارک‌ها، BOFT روی LLMها (مثل Llama-2) در تسک‌های ریاضی و استدلال، و روی مدل‌های ویژن (مثل ViT و Stable Diffusion) عملکرد بهتری نسبت به LoRA داشته. مخصوصاً در ControlNetها و Subject-driven generation، تونسته Identity سوژه رو خیلی بهتر از LoRA حفظ کنه.

به نظر من، جذابیت اصلی BOFT توی Inductive Bias اون هست. ساختار Butterfly ذاتاً شبیه به تبدیل‌های خطی کلاسیک (مثل Fourier و Cosine Transform) عمل می‌کنه و این باعث میشه مدل روی داده‌های جدید بهتر تعمیم (Generalize) پیدا کنه. هرچند پیاده‌سازی اون پیچیده‌تر از LoRA هست و شاید توی Training کمی کندتر باشه (به خاطر ضرب ماتریس‌های متوالی)، ولی چون در زمان Inference میشه وزن‌ها رو با مدل اصلی Merge کرد، هیچ Latency اضافی نداره.

اگه دنبال فاین‌تیون کردن هستید و LoRA جواب مطلوب رو نمیده یا پایداری آموزش پایینه، BOFT آلترناتیو ریاضی‌پسند و قوی‌تریه.

📃 مقاله اصلی:
Parameter-Efficient Orthogonal Finetuning via Butterfly Factorization
https://arxiv.org/abs/2311.06243

🛠 Join @LLMEngineers Community

کنترل خروجی مدل‌های زبانی فقط با Prompt Engineering نیست. اگه می‌خواید واقعاً بفهمید اون زیر چه خبره و چرا مدل گاهی چرت‌وپرت میگه یا چطور میشه خروجی رو دقیق‌تر کنترل کرد، باید تفاوت Logits و Logprobs رو عمیق درک کنید. خیلیا این دوتا رو به جای هم استفاده می‌کنن یا اصلا سمتش نمیرن، ولی تفاوتشون توی سطح Production حیاتیه.

تفاوت اصلی اینجاست که Logits دیتای خام و نویریه، ولی Logprobs دیتای قابل تحلیل و پایداره.

مفهوم Logits: امتیازهای خام
خروجی لایه آخر مدل (قبل از هر Activation Function) میشه Logits. تصور کنید Vocab مدل شما ۵۰ هزار توکن داره؛ مدل برای هر توکن یه عدد حقیقی (مثبت، منفی یا صفر) برمی‌گردونه.
بردار خروجی مستقیماً نشون‌دهنده "احتمال" نیست، بلکه امتیاز نسبی (Relative Score) هست. هرچی عدد بزرگتر باشه، یعنی مدل تمایل بیشتری به اون توکن داره. این اعداد ورودی تابع Softmax هستن.

مفهوم Logprobs: پایداری عددی
محاسبه مستقیم احتمالات (Probabilities) توی شبکه‌های عصبی مشکل Numerical Stability داره. ضرب کردن تعداد زیادی عدد کوچیک (مثل ۰.۰۰۰۰۱) باعث Underflow میشه و دقت محاسبات از دست میره.
راه حل اینه که بعد از اعمال Softmax روی Logits، از خروجی لگاریتم طبیعی (Natural Log) می‌گیرن. این میشه Logprobs.
مقادیر Logprobs همیشه منفی یا صفر هستن (چون احتمال همیشه زیر ۱ هست و لگاریتم اعداد زیر ۱ منفی میشه). هرچی عدد به صفر نزدیک‌تر باشه (مثلا -0.01)، یعنی مدل مطمئن‌تره.

کاربرد عملی در مهندسی
استفاده از هر کدوم جای خودشو داره:
۱. اگر می‌خواید Sampling اختصاصی بنویسید (مثل اعمال Temperature دستی یا پیاده‌سازی Top-K/Top-P کاستوم)، باید Logits رو از مدل بگیرید و دستکاری کنید.
۲. اگر دنبال تحلیل مدل هستید (مثل محاسبه Perplexity برای ارزیابی کیفیت مدل)، باید از Logprobs استفاده کنید چون جمع کردنشون راحت‌تر از ضرب احتمالاته.

به نظر من، مهم‌ترین کاربرد Logprobs که کمتر بهش توجه میشه، تشخیص Hallucination توی سیستم‌های RAG هست. وقتی مدل داره یه Fact یا عدد خاص رو تولید می‌کنه، اگر Logprob اون توکن‌ها خیلی پایین باشه (عدد منفی بزرگ)، یعنی مدل اصلا مطمئن نیست و داره حدس می‌زنه. می‌تونید با یه Threshold ساده روی میانگین Logprobs جمله، پاسخ‌های غیرمطمئن رو فیلتر کنید تا سیستم‌تون دروغ تحویل کاربر نده.

مسیر تبدیل دیتا به زبان ساده:
Logits → (Softmax + Temperature) → Probabilities → Log → Logprobs

اگر با API هایی مثل OpenAI یا مدل‌های Open Source کار می‌کنید، پارامتر logprobs=True رو فعال کنید تا ببینید مدل واقعا چقدر به حرفی که می‌زنه اطمینان داره.

🛠 Join @LLMEngineers Community

زمانی که می‌خواهید دانش یک مدل غول‌پیکر مثل GPT-4o رو به یه مدل کوچیک مثل Llama یا Qwen تزریق کنید (Knowledge Distillation)، بزرگترین چالش فنی معمولا عدم دسترسی به وزن‌ها و Raw Logits مدل معلم (Teacher) هست. اکثر API‌های تجاری فقط خروجی متن و نهایتاً logprobs رو برمی‌گردونن. سوال اینجاست: آیا با logprobs میشه Distillation واقعی انجام داد یا حتما نیاز به Logits خام داریم؟

ما دو خانواده اصلی برای Distillation داریم که درک تفاوتشون کلید حل این مسئله‌ست:

خانواده اول: Logit Matching (معمولا MSE Loss)
هدف در اینجا اینه که دانش‌آموز (Student) دقیقاً مقادیر انرژی (Energy/Logits) معلم رو کپی کنه. این روش نیاز به دسترسی به Raw Logits داره چون باید Scale و Temperature اولیه رو بدونه. وقتی Softmax زده میشه، اطلاعات مربوط به بزرگی اعداد (Magnitude) از بین میره و فقط نسبت‌ها باقی می‌مونن. پس با خروجی API که احتمالاً Softmax شده، این روش عملاً غیرممکنه.

خانواده دوم: Distribution Matching (معمولا KL Divergence)
اینجا هدف اینه که توزیع احتمال (Probability Distribution) دانش‌آموز شبیه معلم بشه. خبر خوب اینه که logprobs دقیقاً همون لگاریتمِ احتمالاته (log(softmax(logits))). برای محاسبه KL Divergence، داشتن logprobs کاملاً کافی و از نظر ریاضی معادل استفاده از Logits هست (منهای یک ثابت عددی که در گرادیان تاثیر نداره).

در سناریوی استفاده از OpenAI API، شما فقط به خانواده دوم دسترسی دارید و همین برای ۹۹٪ کاربردهای LLM کافیه.

روند اجرایی به این صورت میشه:
۱. دریافت دیتا: پرامپت رو به API می‌فرستید و پارامتر logprobs=True و top_logprobs=5 (یا بیشتر) رو ست می‌کنید.
۲. ساخت Soft Targets: خروجی شامل توکن نهایی و احتمالات لگاریتمی ۵ توکن برتر برای هر پوزیشن هست. این یعنی شما فقط "جواب درست" رو ندارید، بلکه می‌دونید مدل روی چه کلمات دیگه‌ای شک داشته (Dark Knowledge).
۳. آموزش مدل:
توابع Loss شما ترکیبی میشه از:
یک: Cross-Entropy روی توکن اصلی (Hard Label).
دو: KL Divergence بین توزیع احتمالات معلم (که از top logprobs بازسازی کردید) و توزیع دانش‌آموز.

نکته فنی مهم در مورد Top-K:
خروجی API کل Vocab رو بهتون نمیده، فقط K تای اول رو میده. برای حل این مشکل در محاسبه Loss، معمولا احتمالات رو روی همین K توکن Renormalize می‌کنن و بقیه Vocab رو نادیده می‌گیرن یا یک مقدار اپسیلون بهشون میدن. این تقریب برای انتقال "استدلال" و "لحن" مدل معلم کاملا کارسازه.

به نظر من، وسواس روی Logit Matching (روش اول) برای LLMهای جنریتی تو اکثر موارد زیاده‌رویه. چیزی که باعث میشه مدل کوچیک شما هوشمندتر بشه، یاد گرفتن "عدم قطعیت‌های" معلم و روابط بین کلمات جایگزینه که همش توی logprobs وجود داره. اگر هدف‌تون ساخت یه مدل تخصصی برای مثلاً "دستیار مشتری به زبان فارسی" هست، همین دیتای Logprobs از API کیفیت مدل ۵-۷ میلیارد پارامتری شما رو به طرز عجیبی بالا می‌بره و باعث میشه مدل کمتر دچار Overfitting روی دیتای کم‌حجم بشه.


🛠 Join @LLMEngineers Community

داستان Alignment مدل‌های زبانی از اون بحث‌هاییه که اگه درست درکش نکنی، عملاً داری منابع GPU رو دور می‌ریزی و خروجی مدل‌ت هم یه چیز توهمی میشه. ما الان از دوران "فقط PPO بزنیم" گذشتیم و وارد عصر "تخصصی‌سازی متدهای RL" شدیم.

توی این پست می‌خوام خیلی تکنیکال و بدون حاشیه، متدهای اصلی Fine-Tuning مبتنی بر RL رو کالبدشکافی کنم تا بدونی برای پروژه بعدیت کدوم رو انتخاب کنی.

دسته‌بندی کلی متدها
کلا داستان به دو بخش تقسیم میشه:
۱. متدهای On-Policy (مثل PPO و GRPO): که مدل همزمان با آموزش، دیتا تولید می‌کنه.
۲. متدهای Offline (مثل DPO، KTO و ORPO): که روی دیتای از قبل آماده شده (Preference Data) کار می‌کنن.

۱. معماری PPO (Proximal Policy Optimization)
پدرخوانده‌ی RLHF که ChatGPT باهاش بزرگ شد. مکانیزمش Actor-Critic هست. یعنی شما یه مدل داری که متن تولید می‌کنه (Actor) و یه مدل جدا داری که نمره میده (Critic/Reward Model).
مزیتش اینه که به شدت Stable هست و برای تولید متن‌های طولانی و مکالمه‌های پیچیده هنوز بهترین خروجی رو میده. اما ایراد بزرگش اینه که به شدت Compute-Heavy هست. شما باید همزمان چنتا مدل رو توی VRAM نگه داری که عملاً هزینه‌ها رو ۲ برابر می‌کنه.

۲. معماری DPO (Direct Preference Optimization)
الان محبوب‌ترین روش توی کامیونیتی Open Source هست (مدل‌های Zephyr و Llama 3 Instruct).
ایده اینه: Reward Model رو حذف کن! خود Policy مدل رو جوری آپدیت کن که احتمال تولید جواب‌های "Chosen" بیشتر از "Rejected" بشه.
خیلی سبک‌تر و پایدارتر از PPO هست اما یه باگ بزرگ داره: روی دیتاهای نویزی زود Overfit میشه و برای تسک‌های استدلالی سنگین (مثل ریاضی) به خوبی PPO عمل نمی‌کنه چون اکتشاف (Exploration) نداره.

۳. معماری GRPO (Group Relative Policy Optimization)
ستاره‌ی جدید بازی که DeepSeek باهاش سر و صدا کرد. این روش برای تسک‌های استدلالی (Reasoning) مثل ریاضی و کدنویسی شاهکاره.
تفاوتش با PPO اینه که Critic Model رو حذف کرده. به جاش میاد برای هر پرامپت، یه گروه (مثلا ۸ تا) خروجی می‌گیره و اینا رو نسبت به میانگین همون گروه می‌سنجه. این باعث میشه واریانس آموزش کم بشه و بدون نیاز به مدل Reward جداگانه، مدل بتونه مسیرهای استدلالی درست رو پیدا کنه.

۴. معماری ORPO (Odds Ratio Preference Optimization)
این روش میاد مرحله SFT و Alignment رو ترکیب می‌کنه. یعنی دیگه لازم نیست اول مدل رو SFT کنی بعد بری سراغ DPO.
توی تابع Loss، یه جریمه (Penalty) اضافه می‌کنه برای جواب‌های Rejected. برای مدل‌های کوچیک و متوسط (مثل Mistral 7B) عالیه و سرعت Train رو به شدت بالا می‌بره، اما هنوز روی اسکیل‌های خیلی بزرگ تست نشده.

۵. معماری KTO (Kahneman-Tversky Optimization)
این متد بر اساس تئوری اقتصاد رفتاری (Prospect Theory) ساخته شده. نکته کلیدیش اینه: نیاز به دیتای Pair شده (این بهتر از اونه) نداره.
فقط کافیه به مدل بگی این خروجی "خوبه" یا "بده" (باینری). این برای محیط‌های پروداکشن واقعی که دیتای مقایسه‌ای گرونه ولی دیتای لایک/دیسلایک زیاده، نجات‌بخش‌ترین روشه.

۶. معماری RLOO (REINFORCE Leave-One-Out)
یه جورایی برگشت به ریشه‌های REINFORCE هست ولی با یه تریک آماری برای کاهش واریانس.
برای تسک‌هایی که جواب قطعی دارن (مثل تولید کد که یا ران میشه یا نمیشه)، خیلی خوب عمل می‌کنه و توی بنچمارک‌ها تونسته PPO رو توی تسک‌های کدنویسی شکست بده.

به نظر من:
اگه منابع محدود داری و دنبال یه مدل جنرال چت‌بات هستی، شک نکن و برو سراغ DPO یا ORPO. پیچیدگی پیاده‌سازی PPO ارزشش رو نداره مگر اینکه داری روی یه مدل در حد GPT-4 کار می‌کنی.
اما اگه داری روی یه مدل تخصصی برای ریاضی، لاجیک یا کدنویسی کار می‌کنی، حتماً GRPO یا RLOO رو تست کن. ترند سال ۲۰۲۵ رفتن به سمت این متدها برای افزایش توانایی Reasoning مدل‌هاست.
و در نهایت، اگه دیتای Pair شده نداری و فقط لاگ‌های سیستم رو داری (Like/Dislike)، تنها گزینه‌ی معقولت KTO هست.

🛠 Join @LLMEngineers Community

قابلیت مکالمه زنده (Real-time Interaction) دقیقاً همون نقطه‌ای هست که مدل‌های Open-source هنوز فاصله‌ی زیادی با GPT-4o دارند. پروژه Mini-Omni تلاشیه برای پر کردن این گپ با یه معماری End-to-End واقعی، که دیگه نیازی به پایپ‌لاین‌های کلاسیک و کند ASR -> LLM -> TTS نداره.

معماری این مدل برخلاف روش‌های Cascade که اول متن رو تولید می‌کنن و بعد میدن به TTS، از روشی به اسم "Parallel Decoding" استفاده می‌کنه. یعنی مدل همزمان که داره فکر می‌کنه (Text Tokens رو تولید می‌کنه)، داره حرف هم می‌زنه (Audio Tokens رو جنریت می‌کنه). این باعث میشه Latency به شدت بیاد پایین و حس یه مکالمه واقعی منتقل بشه.

پایه و Backbone این مدل Qwen2-0.5B هست. انتخاب یه مدل نیم میلیارد پارامتری نشون میده تمرکز تیم روی بهینه‌سازی Inference و قابلیت اجرا روی Edge Devices بوده. برای بخش صدا از انکودر Whisper و دیکودر SNAC استفاده کردن که کیفیت خروجی رو توی Streaming حفظ کنن.

مکانیزم جالبی که پیاده‌سازی کردن "Any Model Can Talk" نام‌گذاری شده. این یعنی عملاً یه آداپتور ساختن که می‌تونه به هر LLM دیگه‌ای (مثلا Llama 3) متصل بشه و قابلیت صحبت کردن رو بهش اضافه کنه، بدون اینکه نیاز باشه کل مدل از صفر Train بشه. این متدولوژی شامل سه مرحله‌ست: Modality Alignment (هماهنگی صدا و متن)، Adaption Training و نهایتاً Multi-modal Finetuning.

نکته فنی مهم توی این پروژه استفاده از Batch Parallel Decoding هست. چون Reasoning روی مدالیته صدا سخت‌تر از متنه، مدل میاد توی یه پروسه Batch، همزمان دو تا خروجی تولید می‌کنه: یکی برای لاجیک متنی و یکی برای تبدیل اون لاجیک به صدا. اینجوری قدرت استدلال متنی مدل حفظ میشه و صرفاً تبدیل به یه طوطی نمیشه.

به نظر من، اهمیت Mini-Omni توی وزن‌های مدل نیست (چون 0.5B برای کارهای پیچیده خیلی کمه)، بلکه توی معماری و متدولوژی آموزششه. اینکه نشون دادن میشه بدون درگیر شدن با Latency وحشتناک سیستم‌های Cascade، روی GPUهای معمولی هم Voice Assistant واقعی داشت، مسیر رو برای Local AI باز می‌کنه. دیتاست VoiceAssistant-400K که با GPT-4o تولید کردن هم برای Fine-tune کردن مدل‌های دیگه روی لحن مکالمه‌ای بسیار ارزشمنده.

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

برای تست لوکال نیاز به نصب ffmpeg و PyAudio دارید و پیشنهاد می‌کنم روی محیط conda ایزوله تستش کنید چون Dependencyهای صوتی پایتون معمولا دردسر سازن.

📑 گزارش فنی و معماری مدل:
https://arxiv.org/abs/2408.16725

📖 گیت‌هاب پروژه و کدها:
https://github.com/gpt-omni/mini-omni

🤗 دیتاست VoiceAssistant-400K:
https://huggingface.co/datasets/gpt-omni/VoiceAssistant-400K

🛠 Join @LLMEngineers Community

مدل Moshi یه قدم خیلی بزرگ برای حل مشکل Latency در تعامل صوتی با هوش مصنوعیه. تا الان اکثر سولوشن‌های موجود، یه پایپ‌لاین Cascade بودن (یعنی اول ASR، بعد LLM، تهش TTS) که ذاتاً کند و غیرطبیعیه. تیم Kyutai (یه لابراتوار فرانسوی) اومده یه مدل End-to-End واقعی ساخته که همزمان می‌شنوه و حرف می‌زنه، اونم به صورت Full-Duplex.

معماری Moshi بر پایه یه مدل زبانی ۷ میلیاردی به اسم Helium بنا شده که از پایه توسط خودشون ترین شده. نکته کلیدی اینجاست که این مدل صرفاً یه LLM نیست که بهش مبدل صدا چسبونده باشن؛ بلکه یه معماری Multi-stream داره. یعنی دو تا استریم صوتی جدا (یکی کاربر، یکی خود مدل) رو همزمان پردازش می‌کنه. این یعنی دیگه مفهوم نوبتی حرف زدن (Turn-based) که تو سیستم‌های قدیمی بود حذف شده و شما می‌تونید وسط حرفش بپرید (Interruption) یا همزمان باهاش صحبت کنید، دقیقاً مثل مکالمه انسانی.

قلب تپنده‌ی این سیستم، یه Neural Audio Codec جدید به اسم Mimi هست. برخلاف کدک‌های قبلی مثل EnCodec یا SemantiCodec که Latency بالایی داشتن یا Frame Rate شون با توکن‌های متنی مچ نمی‌شد، Mimi تونسته با Frame Rate حدود 12.5Hz کار کنه. این یعنی هر ۸۰ میلی‌ثانیه یه توکن صوتی میده که برای Streaming فوق‌العاده‌ست. برای مقایسه، اکثر کدک‌ها ۵۰ هرتز هستن که بار پردازشی رو الکی زیاد می‌کنن. Mimi همزمان اطلاعات آکوستیک (کیفیت صدا) و سمنتیک (مفهوم) رو فشرده می‌کنه.

تکنیک "Inner Monologue" شاهکار مهندسی این پیپره. مدل قبل از اینکه توکن صوتی (Audio Token) رو تولید کنه، اول توکن متنی (Text Token) متناظرش رو به صورت داخلی جنریت می‌کنه. این کار باعث میشه مدل "فکر کنه" و بعد "حرف بزنه". این قضیه دو تا باگ بزرگ مدل‌های Speech-to-Speech قبلی رو حل کرده: یکی اینکه کیفیت محتوا و استدلال به شدت میره بالا (چون از دیتای متنی LLM استفاده می‌کنه) و دوم اینکه عملاً مدل همزمان داره ASR و TTS رو به صورت Streaming انجام میده.

برای اجرا، تیم Kyutai سه تا بک‌اند مختلف داده: PyTorch برای ریسرچ، Rust برای پروداکشن (که پرفرمنسش عالیه) و MLX برای اجرا روی مک‌بوک‌های اپل سیلیکون. روی یه GPU L4، تاخیر (Latency) عملی حدود ۲۰۰ میلی‌ثانیه است که عملاً Real-time محسوب میشه. مدل در دو نسخه Moshiko (صدای مرد) و Moshika (صدای زن) و تحت لایسنس CC-BY 4.0 منتشر شده که یعنی برای استفاده‌های مختلف بازه.

به نظر من، Moshi نشون داد که دوران چسبوندن Whisper به Llama و VITS تموم شده. اگر می‌خواید روی Voice AI کار کنید، معماری‌هایی مثل GPT-4o و همین Moshi که Audio Token رو Native می‌فهمن، آینده هستن. دقت کنید که این مدل هنوز ۷ میلیاردیه و ممکنه توی Reasoning پیچیده کم بیاره، ولی معماریش برای ساخت Voice Assistant های لوکال بی‌نظیره.

تجربه شخصی من اینه که برای تست لوکال حتما از نسخه Rust یا MLX استفاده کنید، نسخه پایتونی خام برای دمو کمی سنگینه. ضمناً برای فاین‌تیون روی زبان‌های دیگه (مثل فارسی) چون توکنایزر Mimi روی دیتای زیادی ترین شده، احتمالاً نتیجه خوبی میده ولی نیاز به GPU قوی دارید.

صفحه اصلی پروژه و دمو:
https://moshi.chat/

کدها و پیاده‌سازی‌های Rust و Python:
https://github.com/kyutai-labs/moshi

مقاله فنی و جزئیات معماری:
https://arxiv.org/abs/2410.00037

دانلود مدل‌ها از هاگینگ‌فیس:
https://huggingface.co/kyutai

🛠 Join @LLMEngineers Community

دنیای Voice AI (هوش مصنوعی صوتی) دیگه اون منشی‌های تلفنی خنگ یا دستیارهای صوتی قدیمی مثل Siri و Alexa نیست که مجبور باشی داد بزنی تا یه آهنگ پخش کنن. توی سال ۲۰۲۵، ما داریم درباره «ایجنت‌های صوتی» صحبت می‌کنیم که مکالمه Real-time دارن، وسط حرفت می‌پرن، احساساتت رو می‌فهمن و دقیقاً مثل یه آدم باهات حرف می‌زنن.

برای اینکه وارد این دنیا بشید، باید ساختار فنی پشت صحنه رو خیلی ساده درک کنید. کلاً دو مدل معماری اصلی داریم که الان توی بازار استفاده میشه:

معماری کلاسیک (Hybrid Pipeline)
این روشی‌ه که اکثر سیستم‌ها هنوز باهاش کار می‌کنن و شبیه یه خط تولید سه مرحله‌ای هست:
۱. گوش (ASR/STT): صدا رو می‌گیره و تبدیل به متن می‌کنه.
۲. مغز (LLM): متن رو می‌خونه، فکر می‌کنه و جواب رو متنی می‌نویسه.
۳. زبان (TTS): جواب متنی رو دوباره به صدا تبدیل می‌کنه.
مشکل اینجاست که چون دیتا باید سه بار دست‌به‌دست بشه، یه تأخیر (Latency) حدود ۱ ثانیه‌ای داره که حس «مکالمه طبیعی» رو از بین می‌بره.

معماری مدرن (Native Speech-to-Speech)
این همون تکنولوژی خفنیه که مدل‌هایی مثل GPT-4o، Gemini Live و مدل‌های جدید چینی مثل Qwen3-Omni دارن. اینجا دیگه تبدیل متن نداریم. مدل مستقیماً "صدا" رو می‌شنوه و "صدا" تولید می‌کنه.
نتیجه؟ سرعت وحشتناک بالا (زیر ۳۰۰ میلی‌ثانیه) و درک لحن و احساسات. یعنی اگر با بغض حرف بزنی، مدل می‌فهمه ناراحتی!

چطور شروع کنیم؟ (نقشه راه عملی)
نرید از صفر کد پایتون بزنید که صدا ضبط کنه و بفرسته API. این کار اشتباهه. الان فریم‌ورک‌هایی هستن که کارهای سخت مثل مدیریت WebRTC (همون تکنولوژی تماس تصویری) و قطع و وصل شدن نت رو هندل می‌کنن.

اگر برنامه‌نویس هستید:
برید سراغ Pipecat یا LiveKit. اینا مثل React هستن برای دنیای Voice. شما فقط منطق برنامه رو می‌نویسید، اینا اتصال بین گوش، مغز و زبان رو مدیریت می‌کنن.

اگر می‌خواید بدون کد زدن تست کنید:
پلتفرم‌هایی مثل Vapi یا Retell AI هستن که اجازه میدن توی چند دقیقه یه ایجنت تلفنی بسازید، بهش شماره بدید و باهاش تماس بگیرید.

به نظر من:
آینده تعامل با کامپیوترها، تایپ کردن نیست. Voice AI داره به سمتی میره که شما با نرم‌افزارتون «حرف» می‌زنید و اون کارها رو انجام میده. الان بهترین زمان برای یادگیری این حوزه است چون هنوز خیلی‌ها درگیر چت‌بات‌های متنی‌ان و بازار Voice دست نخورده‌ست.


🛠 Join @LLMEngineers Community

معماری مدل‌های صوتی (Spoken Dialogue Models) داره یه شیفت سنگین رو تجربه می‌کنه؛ گذار از حالت Half-Duplex (مثل بیسیم واکی-تاکی که یکی حرف می‌زنه اون یکی گوش میده) به Full-Duplex (مکالمه طبیعی همزمان که می‌تونیم بپریم وسط حرف هم). ترندهایی مثل GPT-4o Voice Mode باعث شدن هایپ این قضیه زیاد بشه، ولی واقعیت اینه که ارزیابی این مدل‌ها تا الان فقط روی "محتوای متنی" بوده، نه "دینامیک مکالمه".

مقاله جدید Full-Duplex-Bench دقیقاً دست گذاشته روی همین نقطه کور. این‌ها یه بنچمارک ساختن که کیفیت تعامل رو می‌سنجه، نه فقط اینکه مدل چی میگه، بلکه "کی" و "چطور" میگه.

چهار بُعد اصلی که توی این بنچمارک تست میشه و باید توی توسعه مدل‌های Voice بهش دقت کنید:

۱. هندل کردن مکث (Pause Handling):
مدل باید فرق بین "تموم شدن حرف" و "مکث برای فکر کردن" رو بفهمه. اکثر مدل‌های فعلی (مخصوصا End-to-Endها) تا یه مکث کوچیک می‌بینن، سریع میپرن وسط و Interrupt می‌کنن که تجربه کاربری رو نابود می‌کنه (Takeover Rate بالا).

۲. بک‌چنل (Backchanneling):
یه مکالمه طبیعی پر از "آها"، "اووم" و "درسته" است که شنونده میگه تا نشون بده داره گوش میده، بدون اینکه نوبت صحبت رو بگیره. مدل باید بتونه بدون اینکه رشته کلام رو از دست یوزر بگیره، فیدبک صوتی بده.

۳. جابجایی نوبت (Smooth Turn-Taking):
اینجا Latency حرف اول رو میزنه. فاصله زمانی بین سکوت یوزر و شروع جواب مدل. مدل باید تشخیص بده کِی نوبت اونه و بدون تاخیر غیرطبیعی شروع کنه.

۴. مدیریت وقفه (User Interruption):
اگه مدل داره حرف می‌زنه و یوزر می‌پره وسط حرفش، مدل چقدر سریع خفه میشه؟ (Barge-in). مدل‌های E2E معمولاً اینجا گیج می‌زنن و به حرف زدن ادامه میدن یا چرت و پرت تحویل میدن چون کانتکست به هم می‌ریزه.

نکات فنی و وضعیت فعلی مدل‌ها بر اساس این بنچمارک:

مدل‌های End-to-End مثل Moshi و dGSLM:
این‌ها Latency وحشتناک پایینی دارن (حدود ۳۰۰ میلی‌ثانیه) که عالیه، ولی به شدت "بی‌ادب" هستن. یعنی Takeover Rate بالایی دارن و هر نویزی رو سیگنال شروع صحبت می‌بینن و میپرن وسط. کنترل‌پذیری این معماری‌ها هنوز پایین‌ه.

مدل‌های Cascaded مثل Freeze-Omni:
این‌ها که پایپ‌لاین جدا (VAD + ASR + LLM + TTS) دارن، توی کنترل نوبت و تشخیص وقفه خیلی بهتر عمل می‌کنن چون ماژولار هستن و لاجیک مشخص دارن، ولی Latency بالاتری دارن که حس Real-time رو کم می‌کنه.

مدل Gemini Live:
به عنوان یه مدل تجاری Closed-source، تعادل خوبی بین بک‌چنل و مدیریت نوبت داره ولی حتی اون هم روی دیتاست‌های واقعی (مثل Candor) گاهی گیج میزنه و نوبت رو به موقع نمی‌گیره.

به نظر من، آینده دست مدل‌های Native End-to-End هست چون پتانسیل انتقال احساسات و Latency پایین رو دارن، ولی فعلاً از مشکل "عدم بلوغ در Turn-taking" رنج می‌برن. اگر روی Voice Agent کار می‌کنید، فعلاً یا باید کندی Cascaded رو تحمل کنید یا بیخیال دقت در نوبت‌گیری بشید. راه حل احتمالی تزریق توکن‌های کنترلی خاص برای مدیریت State مکالمه داخل خود مدل E2E هست، نه اینکه صرفاً روی دیتای خام Audio آموزش بدیم.

📃 Full-Duplex-Bench: A Benchmark to Evaluate Full-Duplex Spoken Dialogue Models
https://arxiv.org/abs/2503.04721

🛠 Join @LLMEngineers Community

همه درگیر بنچمارک‌های Reasoning و MMLU شدن، ولی اون چیزی که تو پروداکشن (Production) و مخصوصاً سیستم‌های Agentic مو رو از ماست می‌کشه بیرون، System Prompt Adherence (پایبندی به پرامپت سیستم) هست.

واقعیت اینه که وقتی داری یه Agent می‌سازی که باید فرمت JSON برگردونه یا توی یه چارچوب امنیتی خاص کد بزنه، خلاقیت شاعرانه مدل به هیچ دردی نمی‌خوره. توی سال ۲۰۲۵، بحث از "آیا مدل می‌فهمه؟" به "آیا مدل اطاعت می‌کنه؟" تغییر کرده.

چند تا نکته فنی و دیتای به درد بخور از وضعیت فعلی Adherence براتون درآوردم:

معیار سنجش (Benchmarks) تغییر کرده
دیگه تست‌های ساده Yes/No جواب نمیده. الان بنچمارک‌هایی مثل IFEval (که روی فرمت تمرکز داره) خوبن ولی کافی نیستن. ترند جدید AgentIF و AdvancedIF هستن. اینا میان سناریوهای Multi-turn و پیچیده رو تست می‌کنن. مثلاً مدل رو تو موقعیتی میذارن که ۱۲ تا Constraint مختلف داره (مثل "فقط اگه X بزرگتر از Y بود API رو کال کن، خروجی YAML باشه، و به Z اشاره نکن"). جالبه بدونید حتی مدل‌های تاپ هم توی این سناریوها زیر ۳۰٪ پرفکت عمل می‌کنن.

وضعیت مدل‌ها در ۲۰۲۵ (The Leaderboard)
طبق دیتای Vellum و SEAL، وضعیت فعلی اینطوریه:
مدل Claude 4.5 Sonnet با ۹۲٪ پایبندی، فعلاً پادشاه بلامنازع Instruction-following هست، مخصوصاً توی تسک‌های طولانی.
مدل Grok-4 و GPT-5 با اختلاف کمی پشت سرش هستن.
نکته جذاب برای ما که دنبال هزینه کمتریم: توی دسته SLMها (مدل‌های زیر ۳۲ میلیارد پارامتر)، مدل Qwen3-30B و Mistral Small 3 شاهکار کردن. اگر دارید روی Edge یا سیستم‌های لوکال کار می‌کنید، Qwen3 با ۸۵٪ پایبندی، بهترین گزینه برای جایگزینی مدل‌های گرون‌قیمته.

تکنیک‌های بهبود (Optimization)
تکنیک RIFL (که یه پایپ‌لاین RL هست) الان ترند شده برای اینکه Adherence رو بکشه بالا. به جای اینکه فقط روی دیتای SFT معمولی فاین‌تیون کنید، استفاده از RIFL و دیتای سینتتیک مثل Self-Instruct می‌تونه ۶ تا ۱۰ درصد پرفورمنس رو توی پیروی از دستورات بهتر کنه.

چالش‌های امنیتی
به نظر من بزرگترین ترس الان Prompt Injection نیست، بلکه Context Drift توی پرامپت‌های طولانیه. هرچی کانتکست طولانی‌تر میشه، مدل "نصیحت‌های اول کار" (System Prompt) رو فراموش می‌کنه. بنچمارک‌ها نشون میدن که Adherence با افزایش طول کانتکست، حدود ۲۰٪ افت می‌کنه.

اگه دارید سیستم Agentic می‌سازید، به جای اینکه فقط روی "هوش" مدل مانور بدید، روی ابزارهایی مثل lm-evaluation-harness وقت بذارید و مطمئن بشید که مدل دقیقاً همون کاری رو می‌کنه که بهش گفتید، نه اون چیزی که خودش فکر می‌کنه درسته.

📃 دیتاست AgentIF :
https://huggingface.co/datasets/THU-KEG/AgentIF

📃 مقاله:
AgentIF: Benchmarking Instruction Following of Large Language Models in Agentic Scenarios


🛠 Join @LLMEngineers Community

عملیات Fine-tune با Unsloth الان ۳ تا ۵ برابر سریع‌تر شده. بحث فقط سرعت نیست، مدیریت VRAM به شدت بهینه شده و عملاً با سخت‌افزار ضعیف‌تر می‌تونید مدل‌های سنگین‌تر رو Train کنید.

تکنیک اصلی که اضافه شده Uncontaminated Packing هست. توی حالت استاندارد وقتی Batch Size رو بالا می‌برید، چون طول Sequenceهای دیتاست متفاوته، GPU مجبور میشه کلی Padding (صفر) اضافه کنه تا ماتریس‌ها هم‌اندازه بشن. این یعنی پردازشِ هیچی.
مکانیزم Packing میاد Sequenceهای کوتاه رو هوشمندانه می‌چسبونه کنار هم توی یک Tensor واحد، بدون اینکه Attention Mask بین نمونه‌ها نشت کنه (Leakage). نتیجه؟ دور ریز محاسباتی تقریباً صفر میشه.

کرنل‌های Triton هم بازنویسی شدن. مخصوصاً کرنل RoPE و MLP.
قبلاً توی Contextهای خیلی طولانی (مثلاً 500K) ارورهای عجیب CUDA Out of Bounds می‌گرفتیم. دلیلش این بود که Indexing پیش‌فرض روی Int32 بود. الان Unsloth اومده از Int64 Indexing استفاده کرده که این گلوگاه رو برای Long Context Training باز می‌کنه.
علاوه بر این، عملیات RoPE الان کاملاً In-place انجام میشه و کپی‌های اضافی حافظه حذف شده.

توی بنچمارک‌های واقعی روی مدل‌هایی مثل Qwen3 و Llama 3:
کاهش مصرف VRAM بین ۳۰ تا ۹۰ درصد (بسته به کانفیگ) دیده میشه.
سرعت آموزش بطور متوسط ۳ برابر شده. اگر دیتای شما شامل جملات کوتاه و بلندِ میکس باشه، این سرعت تا ۵ برابر هم میرسه (چون تاثیر Packing بیشتر میشه).
نکته مهم اینه که حتی اگر Packing رو فعال نکنید، حالت پیش‌فرض جدید (Padding-free) خودش حدود ۱.۵ تا ۲ برابر سریع‌تر از نسخه قبلیه.

به نظر من این آپدیت برای کسایی که محدودیت GPU دارن (اکثر ماها) حیاتیه. الان میشه روی یه کارت T4 توی Colab مدل‌های 8B یا حتی 14B رو با سرعت خیلی معقول‌تری Fine-tune کرد. دقت مدل هم طبق بنچمارک‌ها هیچ تغییری نمی‌کنه و Loss Curve دقیقاً منطبق بر حالت استاندارده.

برای استفاده کافیه کتابخونه رو آپدیت کنید و توی SFTConfig آرگومان packing = True رو ست کنید. بک‌اند‌های Flash Attention 3 و xFormers هم ساپورت میشن.

📃 داکیومنت و بنچمارک‌های کامل:
https://docs.unsloth.ai/new/3x-faster-training-packing

🛠 Join @LLMEngineers Community

نسخه جدید GPT-5.2 منتشر شد

نکات فنی و کاربردی که باید بدونید:

بنچمارک GDPval رو برای اولین بار معرفی کردن که نشون میده این مدل تو ۴۴ شغل تخصصی، در ۷۰.۹٪ موارد خروجی بهتری از متخصصین انسانی داشته. این کار رو با ۱۱ برابر سرعت بیشتر و کمتر از ۱٪ هزینه انجام میده.

معماری Agentic این مدل به شدت تقویت شده. توی تست‌های Tool calling (مثل Tau2-bench) به دقت ۹۸.۷٪ رسیده. یعنی اگر دارید سیستم‌های Multi-agent می‌سازید که باید دیتابیس بخونن، تحلیل کنن و اکشن بزنن، ضریب خطای "گیج شدن مدل" به شدت پایین اومده.

بنچمارک ARC-AGI-2 شاید مهم‌ترین بخش برای نِردها باشه. این تست برای سنجش "استدلال انتزاعی" و حل مسائل جدیده (نه چیزایی که حفظ کرده). نسخه قبلی (GPT-5.1) امتیازش ۱۷.۶٪ بود، ولی GPT-5.2 پریده روی ۵۲.۹٪. این یعنی یه جهش وحشتناک تو قدرت حل مسئله (Problem Solving) که قبلا قفل بود.

توی حوزه Coding، مدل روی SWE-bench Verified به امتیاز ۸۰٪ رسیده. گزارش‌های اولیه نشون میده تو بحث Front-end و کدهای UI که نیاز به درک بصری و فضایی دارن، خیلی بهتر شده. با این حال هنوز برای کارهای خیلی خاص و Pure Coding، مدل Claude 4.5 Opus رقیب سرسختیه، ولی GPT-5.2 تو دیباگ کردن و پروژه‌های End-to-End بهتر عمل می‌کنه.

هزینه API و دسترسی کمی چالش برانگیزه. مدل GPT-5.2 Pro که دقیق‌ترین نسخه هست، قیمتش برای خروجی به ازای هر میلیون توکن ۱۶۸ دلاره! (نسخه معمولی ۱۴ دلار). این یعنی برای پروداکشن عادی به صرفه نیست، ولی برای کارهای پیچیده که نیاز به استدلال سنگین دارن (مثل تحلیل حقوقی یا معماری نرم‌افزار) کاملاً توجیه اقتصادی داره.

بحث Hallucination هم بهبود داشته. طبق ادعای OpenAI، حدود ۳۰٪ کمتر از نسخه ۵.۱ توهم میزنه. این برای سیستم‌های RAG و Enterprise که دقت توشون حیاتیه، خبر خوبیه.

جمع‌بندی من اینه:
اگر دنبال یه مدل برای "انجام کار" هستید (ساختن فایل، تحلیل داده حجیم، مدیریت پروژه)، GPT-5.2 الان بهترین گزینه است. گوگل با Gemini 3 Pro تو مالتی‌مدیا خوبه، آنتروپیک با Claude تو کدنویسی تمیز هنوز جایگاه داره، ولی OpenAI با ۵.۲ دوباره تاج پادشاهی "استدلال عمیق" رو پس گرفت.

📃 جزئیات کامل فنی و بنچمارک‌ها:
https://openai.com/gpt-5-2-announcement

🛠 Join @LLMEngineers Community

معمولاً وقتی از LLMها می‌خوایم کد فرانت‌اند (HTML/CSS) یا نمودار (Matplotlib) تولید کنن، لاجیک کد درسته ولی خروجی بصری فاجعه‌ست. دکمه‌ها روی همن، رنگ‌بندی داغونه و عملاً "Sense of Aesthetics" یا درک زیبایی‌شناسی ندارن. دلیلش هم واضحه: مدل‌های متنی با تابع خطای متنی (Textual Loss) آموزش دیدن و هیچ ایده‌ای ندارن که کدشون بعد از رندر شدن چه شکلی میشه.

پروژه جدید AesCoder دقیقاً دست روی همین نقطه ضعف گذاشته و نشون میده چطور میشه با استفاده از Agentic Reward Feedback یک مدل ۴ میلیاردی ساخت که توی تسک‌های بصری GPT-4o رو شکست بده.

مکانیزم کار اینجوریه که فرآیند RL (یادگیری تقویتی) رو از حالت Text-based خارج کردن و سه تا ایجنت رو مسئول امتیازدهی کردن:

۱. ایجنت Execution: بررسی می‌کنه کد اصلا ران میشه یا نه (مثلا با HTMLHint).
۲. ایجنت Static Aesthetics: کد رو رندر می‌کنه، اسکرین‌شات می‌گیره و میده به یک مدل VLM قوی (مثل GPT-4o یا GPT-5 که تو پیپر اشاره شده) تا لی‌اوت، رنگ‌بندی و زیبایی بصری رو نمره بده.
۳. ایجنت Interactive Aesthetics: این خیلی جذابه؛ یک ایجنت مثل WebVoyager روی صفحه رندر شده کلیک می‌کنه، اسکرول می‌کنه و چک می‌کنه که آیا تعاملات (Interaction) درست کار می‌کنن یا نه.

ترکیب این فیدبک‌ها با الگوریتم GRPO (همون الگوریتمی که DeepSeek استفاده کرده) باعث میشه مدل یاد بگیره کدی بزنه که فقط "درست" نیست، بلکه "تمیز و کاربردی" هم هست.

به نظر من این پیپر داره آینده‌ی Vertical AI رو فریاد می‌زنه. دیگه دوران اینکه یک مدل جنرال همه کار بکنه داره تموم میشه. اینجا با یک مدل ۴ میلیاردی (بر پایه Qwen) و یک دیتاست تخصصی (AesCode-358K)، خروجی‌هایی گرفتن که مدل‌های ۱۰۰ برابر بزرگتر نمیتونن تولید کنن.

نکته فنی مهمش برای ما اینه که اگر دارید روی Code Generation کار می‌کنید، دیگه نباید به Unit Test متنی بسنده کنید. باید خروجی رو رندر کنید و فیدبک ویژوال رو برگردونید توی پروسه آموزش یا RAG. این متدولوژی Agentic Reward حتی توی پرامپت‌اینجینیرینگ پیشرفته هم قابل پیاده‌سازی هست و لازم نیست حتما مدل Train کنید.

مدل AesCoder-4B الان ریلیز شده و روی فریم‌ورک vLLM به راحتی بالا میاد. برای تولید Landing Page، کامپوننت‌های UI و نمودارهای آماری پایتون شدیداً بهینه شده.

📃 پیپر اصلی AesCoder:
https://arxiv.org/abs/2510.23272

💻 مدل‌:
https://huggingface.co/SamuelBang/AesCoder-4B

🛠 Join @LLMEngineers Community

خیلی حرفه مدل 4b بین همچین ابرقدرت هایی بدرخشه !!
روی تسک تخصصی خودش با مدلای ۴۰۰ تا ۷۰۰ میلیاردی رقابت میکنه

اتصال LLM به دیتابیس سازمانی (Enterprise Database) شاید جذاب‌ترین و در عین حال خطرناک‌ترین یوزکیس این روزهاست. اخیراً یه پیاده‌سازی دیدم که سعی کرده بود با استفاده از متد GRPO (که دیپ‌سیک رو معروف کرد) و مدل Qwen-0.6B، یه ایجنت رزرو هتل بسازه که مستقیماً با PostgreSQL حرف می‌زنه.

ایده روی کاغذ فوق‌العاده‌ست: ترکیب Reinforcement Learning با ابزارهای واقعی (Tools) برای اینکه مدل یاد بگیره کِی و چطور کوئری بزنه. اما در عمل؟ این نوت‌بوک یه فاجعه آموزشیه که فقط ظاهرش قشنگه.

چرا این پیاده‌سازی کار نمی‌کنه؟
توابع پایتونی که برای سرچ دیتابیس نوشته شده (مثل search_hotels) اصلا خروجی رو برمی‌گردونن (Return None)؛ یعنی مدل عملاً کور هست و هیچ دیتایی نمیینه. بدتر از اون، تابع Reward که قلب تپنده GRPO هست، باگ داره و امتیازی برمی‌گردونه! کل پروسه آموزش روی ۴ تا دونه داده انجام میشه که برای RL شوخیه. عملاً مدل داره روی هوا یاد می‌گیره که "ادای" ابزار صدا زدن رو دربیاره، بدون اینکه واقعاً بفهمه چی کار می‌کنه.

به نظر من، مسیر واقعی برای ساخت ایجنت دیتابیس اینه:
اگه تو شرکتتون می‌خواید مدلی بسازید که با دیتابیس تعامل کنه، خودتون رو درگیر پیچیدگی‌های RL نکنید، مگر اینکه مرحله SFT رو رد کرده باشید. نقشه راه عملیاتی برای مدل‌های کوچیک به این صورته:

۱. استراتژی پرامپتینگ (No-Code/Low-Code):
برای ۹۰٪ یوزکیس‌ها، اصلاً نیاز به فاین‌تیون ندارید. اسکیمای دیتابیس (Schema) رو تمیز کنید و به عنوان Context به مدل بدید. از فریم‌ورک‌هایی مثل LangChain یا LlamaIndex استفاده کنید که مکانیزم Tool Calling رو هندل می‌کنن.

۲. فاین‌تیون نظارت‌شده (SFT - The Sweet Spot):
اگه مدل باید فرمت خاصی از JSON برگردونه یا SQLهای پیچیده بنویسه که با پرامپت درنمیاد، برید سراغ SFT.
دیتاست شما باید شامل جفت‌های (سوال کاربر -> کوئری SQL صحیح) یا (سوال کاربر -> فراخوانی ابزار) باشه. با ابزارهایی مثل Unsloth (که برای سرعت عالیه) روی یه مدل کوچیک فاین‌تیون بزنید. این روش پایداری خیلی بالاتری نسبت به RL داره.

۳. مرحله پیشرفته (RL & GRPO):
کی بریم سراغ GRPO؟ زمانی که "درستی" جواب قابل سنجش (Verifiable) باشه. مثلاً در Text-to-SQL، اگر کوئری تولید شده اجرا بشه و نتیجه درست بده، Reward مثبت میدیم. اینجا مدل یاد می‌گیره که "منطق" کوئری زدن رو بهبود بده، نه فقط تقلید از دیتاست. ولی یادتون باشه، برای این کار نیاز به هزاران نمونه و یه محیط ایزوله (Sandbox) دیتابیس دارید، نه ۴ تا سطر داده!

نکته فنی و امنیتی:
هیچ‌وقت، تاکید می‌کنم هیچ‌وقت به LLM دسترسی مستقیم UPDATE یا DELETE روی پروداکشن ندید. ایجنت باید کوئری SELECT بسازه یا پیشنهاد بده، و یه لایه میانی (Application Layer) اون رو Validate و اجرا کنه.

اگه می‌خواید با TRL و GRPO کار کنید، داکیومنت اصلی رو بخونید، نه کدهای ناقص:

📃 داکیومنت TRL برای GRPO

📙 نوتبوک کولب ذکر شده

🛠 Join @LLMEngineers Community