خیلی موافقم

خیلی جاها دیدم اشتباها به یه workflow میگن agent
ولی متفاوتن، تفاوتشون اینه که یه Workflow فقط یه سری مراحل از پیش تعیین‌شده رو اجرا می‌کنه؛ مثل یه فلوچارت ثابت. اما یه Agent واقعی، یه سیستم خودگردان (autonomous) هست که خودش برای رسیدن به هدف برنامه‌ریزی، استدلال و مسیرش رو اصلاح می‌کنه.

🛠 Join @LLMEngineers Community

🛠 Join @LLMEngineers Community

یه تکنیک جدید و خیلی کاربردی معرفی شده به اسم Prompt Baking که فاصله‌ی بین prompt engineering و fine-tuning رو پر می‌کنه.

کاربرد اصلی اینه که به جای اینکه هر بار یه پرامپت سیستمی یا چندتا مثال few-shot رو به مدل بدیم، میایم و اثر اون پرامپت رو مستقیماً توی وزن‌های مدل "bake" میکنیم یا "می‌پزیم". نتیجه‌ش یه مدل جدیده که ذاتاً اون رفتار یا دانش رو داره، بدون اینکه نیازی به خود پرامپت باشه. این کار هم context window رو آزاد می‌کنه و هم مشکل "prompt decay" یا فراموشی پرامپت در طول مکالمات طولانی رو حل می‌کنه.

روش کار بر اساس به حداقل رسوندن KL divergence بین توزیع خروجی مدل اصلیِ پرامپت‌شده و مدل جدیدِ بدون پرامپت بنا شده. در واقع، مدل جدید طوری آموزش داده می‌شه که logitهای خروجیش رو با logitهای مدل پرامپت‌شده تطبیق بده. این پروسه یه جور self-distillation به حساب میاد و معمولاً با استفاده از LoRA انجام می‌شه تا هم سریع باشه (گاهی در حد ۵ دقیقه) و هم بهینه‌.

نتایج عملی این تکنیک خیلی قابل توجهه:
- بهبود استدلال: با bake کردن پرامپت‌های Chain-of-Thought، عملکرد zero-shot مدل روی بنچمارک‌های استدلال ریاضی و کدنویسی مثل GSM8K، ASDiv و MBPP به سطح عملکرد few-shot نزدیک شده.
- تزریق دانش: می‌شه دانش جدید، مثلاً اخبار روز، رو به صورت دائمی به مدل اضافه کرد. مدل بعد از bake شدن، می‌تونه به سوالات مستقیم و حتی غیرمستقیم در مورد اون اطلاعات جدید جواب بده.
- پایداری شخصیت: مشکل persona drift که در اون مدل در مکالمات طولانی، شخصیت یا دستورالعمل اولیه‌اش رو فراموش می‌کنه، با این روش به طور کامل برطرف می‌شه.
- کنترل پیوسته: می‌شه فرآیند bake رو زودتر متوقف کرد ("half-baking") تا میزان تأثیر پرامپت روی رفتار نهایی مدل رو به صورت پیوسته کنترل کرد.

یه یافته‌ی جالب و غیرمنتظره اینه که اگه مدلی که یه پرامپت توش bake شده رو دوباره با همون پرامپت اجرا کنیم، عملکردش حتی از مدل اصلی که فقط پرامپت گرفته بهتر می‌شه. با همین تکنیک، روی بنچمارک GSM8K تونستن رکوردی که متا برای Llama 3 منتشر کرده بود رو هم رد کنن. این ایده به یه روش تکرارشونده به اسم Prompt Pursuit هم توسعه داده شده که مدل به صورت مداوم خودش رو در جهت پرامپت بهبود می‌ده.

به نظر من، Prompt Baking یه ابزار خیلی قدرتمند برای کنترل مدل‌هاست. به جای جمع‌آوری دیتاست و fine-tuningهای سنگین برای یه رفتار خاص، می‌شه با یه پرامپت خوش‌ساخت، اون رفتار رو به صورت دائمی و پایدار در مدل نهادینه کرد. این روش همچنین مقاومت خوبی در برابر catastrophic forgetting نشون داده، یعنی bake کردن یک مهارت، باعث تخریب بقیه توانایی‌های مدل نمی‌شه.

📃 عنوان مقاله: Prompt Baking
https://arxiv.org/abs/2408.14332

🛠 Join @LLMEngineers Community

دنبال یه راهنمای عملی برای ترین کردن مدل‌های زبانی (LLMs) هستین؟ چیزی که از صفر تا صد، تمام چالش‌های واقعی رو پوشش بده، نه فقط تئوری‌های دانشگاهی. Hugging Face یه playbook منتشر کرده به اسم Smol Training Playbook که دقیقاً همینه. این راهنما بر اساس تجربیات تیمشون در ساخت مدل SmolLM-3B (یک مدل ۳ میلیارد پارامتری که روی ۱۱ تریلیون توکن ترین شده) نوشته شده.

اگه توی تیم کوچیکی کار می‌کنید یا منابع محدودی دارید و می‌خواید یه مدل زبانی سفارشی بسازید، این playbook به دردتون می‌خوره. هدفش اینه که جلوی اشتباهات پرهزینه رو بگیره و یه مسیر مستقیم از ایده تا محصول نهایی (from-zero-to-ship) ارائه بده.

محتوای اصلی playbook به چند بخش کلیدی تقسیم می‌شه:

* قبل از شروع: قطب‌نمای ترینینگ
اول از همه به این سوال جواب می‌ده که آیا اصلاً به ترین کردن یه مدل جدید نیاز دارید یا نه. خیلی وقت‌ها fine-tuning مدل‌های اپن‌سورس موجود کافیه. این بخش کمک می‌کنه اهداف رو مشخص کنید و ببینید ترین کردن از پایه توجیه استراتژیک داره یا نه.

* فاز Pretraining: کارهای سنگین
اینجا وارد جزئیات فنی می‌شه. مباحثی مثل انتخاب معماری و سایز مدل، ترکیب داده (data mixture) برای کد، ریاضیات و چندزبانگی، طراحی Tokenizer و استفاده از Scaling Laws برای تخمین Performance مدل نهایی پوشش داده می‌شه. همینطور به زیرساخت‌های لازم مثل DeepSpeed و Megatron و بهینه‌سازی Throughput هم پرداخته شده.

* داستان‌های جنگی: تجربه‌های واقعی
به نظر من، این بخش ارزشمندترین قسمت راهنماست. اینجا از مشکلات واقعی که تیم Hugging Face باهاش روبرو شده صحبت می‌شه. افت ناگهانی throughput، کرش کردن‌های بی‌دلیل، باگ‌های مربوط به parallelism و روش‌های دیباگ کردن و ریکاوری از این فاجعه‌ها. اینا تجربیاتیه که معمولاً با کلی هزینه و زمان به دست میاد.

* بعد از ترینینگ: Alignment و استقرار
کار با pretraining تموم نمی‌شه. این بخش روی مراحل بعد از اون تمرکز داره:

* Supervised Fine-Tuning (SFT):
برای یاد دادن تسک‌های مشخص به مدل.

* Preference Optimization:
استفاده از تکنیک‌هایی مثل DPO یا APO برای همسو کردن رفتار مدل با اولویت‌های انسانی.

* Evaluation:
ارزیابی مدل و آماده‌سازی برای استقرار نهایی.

این playbook یه منبع متمرکز و عملیه که مثل یه چک‌لیست می‌تونید ازش استفاده کنید. به جای خوندن ده‌ها مقاله پراکنده، یه نقشه راه مشخص جلوتون می‌ذاره.

🛠 Join @LLMEngineers Community

TTS Leaderboard

🛠 Join @LLMEngineers Community

ASR Leaderboard

🛠 Join @LLMEngineers Community

مدل جدید Kimi K2 Thinking از شرکت چینی Moonshot AI منتشر شده که تمرکزش روی کارهای Agentic و استفاده عمیق از ابزاره. کاربرد اصلیش برای ساختن Agent-هاییه که باید تسک‌های پیچیده و چند مرحله‌ای رو انجام بدن، مثل تحقیق خودکار یا کدنویسی‌های طولانی.

این مدل صرفاً یه LLM معمولی نیست؛ به عنوان یه "thinking agent" طراحی شده. یعنی زنجیره‌ای از استدلال (Chain-of-Thought) و فراخوانی ابزار (Function Calling) رو به صورت End-to-End با هم یاد گرفته. نکته کلیدیش اینه که می‌تونه پایداری خودش رو توی صدها مرحله فراخوانی ابزار حفظ کنه، در حالی که مدل‌های دیگه معمولاً بعد از ۳۰-۵۰ مرحله دچار افت عملکرد یا انحراف از هدف می‌شن.

معماریش Mixture-of-Experts یا MoE هست با ۱ تریلیون پارامتر که موقع inference فقط ۳۲ میلیاردش فعاله. این ساختار باعث بهینگی در اجرا می‌شه. از یه context window به طول 256K هم پشتیبانی می‌کنه و به صورت نیتیو از کوانتیزیشن INT4 استفاده می‌کنه که سرعت inference رو حدوداً ۲ برابر می‌کنه بدون اینکه عملکرد مدل افت کنه. این یعنی برای دیپلوی کردن روی موتورهایی مثل vLLM یا SGLang بهینه‌ست.

عملکردش توی بنچمارک‌های Agentic مثل HLE (با ابزار) و BrowseComp در حد SOTA ـه و گاهی از GPT-5 و Grok-4 هم بهتره. مخصوصاً در حالت "heavy mode" که چندین trajectory رو به صورت موازی بررسی می‌کنه، نتایجش خیلی قویه. البته توی بنچمارک‌های Reasoning بدون ابزار، هنوز کمی از بهترین‌ها مثل GPT-5 عقب‌تره، که نشون می‌ده قدرت اصلیش در ترکیب استدلال و ابزاره.

به نظر من، تمرکز روی پایداری توی فراخوانی‌های طولانی ابزار (200-300 step) مهم‌ترین ویژگی این مدله. خیلی از Agent-های الان بعد از چند ده مرحله، هدف رو گم می‌کنن و این مدل ظاهراً این مشکل رو تا حد زیادی حل کرده. عرضه شدن یه مدل open-source با این قابلیت‌ها که می‌تونه با مدل‌های بسته مثل GPT-5 و Claude 4.5 Sonnet توی تسک‌های پیچیده رقابت کنه، اونم با هزینه کمتر، یه اتفاق مهمه.

مدل روی Hugging Face در دسترسه و می‌شه ازش استفاده کرد.

📃 مدل در Hugging Face:
https://huggingface.co/moonshot-ai/kimi-k2-thinking

🛠 Join @LLMEngineers Community

بحث Model Editing یعنی اینکه بتونیم دانش یک LLM رو به صورت جراحی و مستقیم توی وزن‌هاش آپدیت کنیم، بدون اینکه نیاز به fine-tuning کامل داشته باشیم. کاربرد اصلیش وقتیه که مدل یه فکت رو اشتباه میگه (hallucination) یا اطلاعاتش قدیمی شده و می‌خوایم فقط همون یک تیکه دانش رو اصلاح کنیم. این کار خیلی بهینه‌تر از retraining هست که هم هزینه‌بره و هم ریسک catastrophic forgetting داره (یعنی مدل چیزای دیگه‌ای که بلد بوده رو یادش بره).

ایده‌ی اصلی اینه که به جای آپدیت همه‌ی پارامترها، فقط اون بخش از شبکه که اطلاعات غلط رو ذخیره کرده پیدا و اصلاح بشه. دو تا از معروف‌ترین الگوریتم‌ها توی این حوزه ROME و MEMIT هستن.

متد ROME برای ادیت کردن یک فکت تنها طراحی شده. فرضش اینه که دانش در لایه‌های MLP مدل Transformer ذخیره شده.
روند کارش اینطوریه:
۱. پیدا کردن محل دانش: با تکنیکی به اسم causal tracing میاد لایه‌ای که بیشترین تاثیر رو روی تولید اون فکت خاص داره پیدا می‌کنه.
۲. اصلاح دانش: بعد از پیدا کردن اون لایه، یک آپدیت ماتریسی از نوع rank-one روی وزن‌های MLP اون لایه اعمال می‌کنه تا فکت جدید جایگزین قبلی بشه. این آپدیت خیلی کوچیک و دقیقه.

مشکل اصلی ROME اینه که برای ادیت‌های پشت سر هم ضعیفه. معمولاً بعد از ۱۰-۲۰ تا ادیت، مدل دچار model collapse می‌شه و کاراییش رو از دست می‌ده، چون آپدیت‌ها روی هم جمع می‌شن و ساختار وزن‌ها رو خراب می‌کنن.

متد MEMIT در واقع نسخه‌ی توسعه‌یافته ROME برای ادیت کردن دسته‌ای و انبوه (mass editing) هست. یعنی می‌تونه هزاران فکت رو همزمان توی مدل آپدیت کنه.
روند کارش به این شکله:
۱. آپدیت چندلایه‌ای: به جای اینکه فقط یک لایه رو ادیت کنه، آپدیت‌ها رو بین چندین لایه پخش می‌کنه تا فشار روی یک بخش از مدل نباشه.
۲. پردازش دسته‌ای: برای یک بچ از ادیت‌ها، یک معادله رو حل می‌کنه تا آپدیت‌های بهینه برای وزن‌ها پیدا بشه. اینطوری تداخل بین ادیت‌ها کمتر می‌شه.

MEMIT مقیاس‌پذیری خیلی بهتری داره و می‌تونه دانش مدل رو به صورت پیوسته آپدیت کنه، ولی ممکنه با ادیت‌های متناقض روی یک موضوع به مشکل بخوره.

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

به نظر من، Model Editing هنوز جایگزین کاملی برای fine-tuning نیست، مخصوصاً برای تغییر رفتار مدل. این تکنیک‌ها بیشتر برای اصلاح دانش (factual knowledge) کاربرد دارن تا منطق یا توانایی‌های استدلالی. بزرگترین ریسکشون هم پتانسیل سوءاستفاده برای تزریق اطلاعات غلط به مدل‌های موجوده، مثل پروژه‌ی PoisonGPT که با همین روش‌ها مدل رو مسموم می‌کرد. ابزار قدرتمندیه ولی باید با احتیاط استفاده بشه.

برای پیاده‌سازی عملی، فریم‌ورک EasyEdit کار رو خیلی راحت کرده و هر دو الگوریتم رو پشتیبانی می‌کنه. برای اجرا حداقل به یک GPU با ۱۶ گیگ VRAM نیاز هست و بهتره با مدل‌های سایز متوسط مثل 7B یا شروع کنید.

📃 مقاله ROME: Locating and Editing Factual Associations in GPT
https://arxiv.org/abs/2202.05262

📃 مقاله MEMIT: Mass-Editing Memory in a Transformer
https://arxiv.org/abs/2210.07229

💻 فریم‌ورک EasyEdit برای پیاده‌سازی
https://github.com/zjunlp/EasyEdit

🛠 Join @LLMEngineers Community

خب بچه‌ها، امروز می‌خوایم یه تکنیک خیلی کاربردی رو کالبدشکافی کنیم. فرض کنین یه system prompt خیلی خفن و طولانی دارین که مدل رو وادار به یه رفتار خاص می‌کنه، مثلاً استدلال قدم‌به‌قدم. مشکل اینجاست که هر بار باید این پرامپت طولانی رو به مدل بدین که هم هزینه توکن داره و هم ممکنه مدل تو متن‌های طولانی یادش بره. راه حل، پختن این پرامپت توی وزن‌های خود مدله.

ایده اصلی اینه که رفتار یه مدل بزرگ و هوشمند (معلم) که با system prompt بهینه شده رو به یه مدل کوچیک‌تر و بهینه‌تر (دانش‌آموز) منتقل کنیم. این کار ترکیبی از دو تا تکنیک معروفه: Prompt Baking و Knowledge Distillation. نتیجه اینه که مدل کوچیک‌تر بدون نیاز به اون پرامپت طولانی، همون رفتار رو از خودش نشون می‌ده.

این تکنیک چیز جدیدی نیست، فقط اسمش عوض شده. قبلاً بهش می‌گفتن Context Distillation و شرکت‌هایی مثل Anthropic از سال ۲۰۲۱ برای تزریق اصول اخلاقی (HHH) به مدل‌هاشون ازش استفاده می‌کردن. پس این یه روش تست‌شده و قابل اعتماده، نه یه هایپ جدید.

پروسه کار به این شکله:
۱. تولید داده با مدل معلم:
اول یه مدل بزرگ و قوی مثل DeepSeek-V2 رو برمی‌داریم و system prompt مورد نظرمون رو بهش می‌دیم. بعد یه مجموعه داده متنوع از سوالات (مثلاً از دیتاست SQuAD) بهش می‌دیم تا جواب تولید کنه. این جواب‌ها که بهشون trajectories میگن، باید با temperature بالا تولید بشن تا تنوع داشته باشن و مدل دانش‌آموز overfit نشه. نکته کلیدی اینجاست که برای هر توکنی که مدل معلم تولید می‌کنه، ما logits (خروجی خام قبل از softmax) رو هم ذخیره می‌کنیم. این logits در واقع توزیع احتمال کامل روی تمام توکن‌های ممکنه و کل دانش مدل معلم توش نهفته‌ست.

۲. آموزش مدل دانش‌آموز:
حالا یه مدل کوچیک‌تر، مثلاً یه مدل ۲۰ میلیاردی، رو انتخاب می‌کنیم. یه آداپتور LoRA روی لایه‌های attention این مدل سوار می‌کنیم تا فقط بخش کوچیکی از وزن‌ها آپدیت بشن و دانش پایه‌ی مدل از بین نره. بعد مدل دانش‌آموز رو با داده‌هایی که تولید کردیم آموزش می‌دیم. مدل دانش‌آموز اینجا دیگه system prompt رو نمی‌بینه. وظیفه‌ش اینه که یاد بگیره logits خروجی خودش رو به logits مدل معلم شبیه کنه. تابع زیان یا loss function برای این کار Kullback-Leibler (KL) divergence هست که تفاوت بین دو توزیع احتمال رو اندازه می‌گیره.

۳. استفاده از مدل پخته‌شده:
بعد از اینکه آموزش تموم شد، وزن‌های LoRA رو با وزن‌های اصلی مدل دانش‌آموز ادغام (merge) می‌کنیم. حالا ما یه مدل کوچیک داریم که رفتار دیکته‌شده توسط اون system prompt پیچیده رو به صورت دائمی در خودش داره، بدون اینکه نیاز به ارسال مجدد پرامپت باشه. این یعنی صرفه‌جویی در هزینه توکن و پایداری رفتار در مکالمات طولانی.

به نظر من، این روش یه نمونه‌ی عالی از مهندسی هوش مصنوعیه. به جای تئوری‌پردازی، یه مشکل واقعی یعنی هزینه و ناپایداری پرامپت‌های طولانی رو به شکل بهینه حل می‌کنه. با استفاده از logits به جای متن خالی (hard labels)، دانش خیلی عمیق‌تری از مدل معلم به دانش‌آموز منتقل می‌شه. البته ریسک‌هایی هم داره؛ اگه پرامپت شما بایاس یا مشکلی داشته باشه، اون بایاس برای همیشه توی مدل جدید پخته می‌شه.

این روش در عمل توسط تیم‌های بزرگی مثل گوگل برای آموزش مدل‌های Gemma با استفاده از مدل‌های Gemini به عنوان معلم هم استفاده شده و نتایج خوبی روی بنچمارک‌ها گرفته. پس اگه دنبال یه راه بهینه برای سفارشی کردن رفتار مدل‌هاتون هستین، این مسیر رو حتماً بررسی کنین.

🛠 Join @LLMEngineers Community

فاین‌تیون کردن مدل‌های زبانی با LoRA استاندارد صنعتی شده، ولی همیشه یه گپی با Full Fine-tuning وجود داره که پر نمیشه. تکنیک DoRA یا Weight-Decomposed Low-Rank Adaptation دقیقاً برای پر کردن همین فاصله طراحی شده؛ یه متد PEFT که یادگیری Magnitude و Direction وزن‌ها رو از هم جدا می‌کنه تا رفتار Full FT رو دقیق‌تر شبیه‌سازی کنه.

تحلیل‌های ریاضی روی پروسه Full Fine-tuning نشون میده که مدل‌ها بیشتر تمایل دارن "جهت" (Direction) بردار وزن‌ها رو تغییر بدن و "اندازه" (Magnitude) رو نسبتا ثابت نگه میدارن. مشکل LoRA اینه که با تزریق ماتریس‌های Low-Rank، تغییرات مگنیتود و دایرکشن رو با هم کوپل می‌کنه و دست مدل رو برای تنظیم دقیق جهت‌ها می‌بنده.

راهکار DoRA اینه که ماتریس وزن Pretrained رو اول تجزیه می‌کنه:
۱. یک بردار Magnitude قابل آموزش (𝑚).
۲. یک ماتریس Direction نرمالایز شده (𝑉).

بعدش پروسه استاندارد LoRA رو فقط روی بخش Direction اعمال می‌کنه و بردار 𝑚 رو جداگانه آموزش میده. نتیجه اینه که همگرایی مدل سریع‌تر و پایدارتر میشه و بدون اضافه کردن سربار محاسباتی خاصی (حدود ۰.۰۱ درصد پارامتر بیشتر نسبت به LoRA)، ظرفیت یادگیری مدل رو بالا می‌بره.

پیاده‌سازی این متد الان توی اکوسیستم Hugging Face کاملاً ساده شده. اگر از کتابخونه peft استفاده می‌کنید، کافیه توی LoraConfig پارامتر use_dora=True رو ست کنید. نکته حیاتی برای پروداکشن اینه که مثل LoRA، وزن‌های DoRA هم کاملاً قابلیت Merge شدن دارن و موقع Inference هیچ Latency اضافه‌ای تحمیل نمی‌کنن.

به نظر من اگر روی تسک‌های پیچیده مثل Reasoning یا Vision-Language کار می‌کنید، سوییچ کردن به DoRA منطقیه. بنچمارک‌ها نشون میدن DoRA حتی با Rank نصف نسبت به LoRA، خروجی بهتری میده. این یعنی می‌تونید پارامترهای کمتری آموزش بدید ولی کیفیت نزدیک به Full Fine-tuning بگیرید. تنها نکته منفی شاید مصرف جزئی حافظه بیشتر موقع Training باشه که ناشی از عملیات Decomposition هست، ولی ارزش پرفورمنس نهایی رو داره.

📃 پیپر اصلی DoRA:
https://arxiv.org/abs/2402.09353

🛠 Join @LLMEngineers Community

این پیپر از اون دست مقاله‌هاییه که با اینکه سال ۲۰۲۰ اومده (دوران اوج RoBERTa)، ولی منطقش دقیقاً همون چیزیه که امروز توی بحث Continued Pretraining برای LLMهای بزرگ مثل Llama 3 یا Mistral هم به درد می‌خوره. تیم AllenAI اینجا یه سوال اساسی رو حل کرده: وقتی یه مدل زبانی روی دیتای عمومی (Common Crawl و غیره) آموزش دیده، چقدر می‌تونه توی دامین‌های تخصصی مثل پزشکی، حقوقی یا حتی نقدهای آمازون خوب عمل کنه؟

جواب کوتاهش اینه: مدل‌های جنرال اونقدر که فکر می‌کنید «همه فن حریف» نیستن و Fine-tuning خالی اغلب راه‌حل بهینه‌ای نیست.

📃 Don’t Stop Pretraining: Adapt Language Models to Domains and Tasks
https://arxiv.org/abs/2004.10964

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

۱. استراتژی DAPT (Domain-Adaptive Pretraining)
بیشتر ما عادت داریم مدل Pretrained رو برداریم و مستقیم روی دیتای لیبل‌دار Fine-tune کنیم. این پیپر نشون میده اگر قبل از Fine-tuning، مدل رو روی دیتای بدون لیبل (Unlabeled) همون "دامین" ادامه آموزش بدید (Continued Pretraining)، پرفورمنس به شدت میره بالا.
نکته مهم اینجاست که هرچقدر دامین شما از دیتای اصلی مدل دورتر باشه (مثلاً BioMed نسبت به News)، تاثیر DAPT بیشتره.

۲. استراتژی TAPT (Task-Adaptive Pretraining) - این بخش طلاست
شاید فکر کنید برای ادامه Pretraining نیاز به ترابایت‌ها دیتا دارید. این تحقیق نشون میده که انجام Pretraining روی همون دیتای ترینینگ تسک (بدون استفاده از لیبل‌ها) تاثیر عجیب و غریبی داره.
حتی اگر دیتای شما کمه، TAPT باعث میشه مدل با توزیع آماری خاص اون دیتاست (Task Distribution) آداپته بشه. هزینه محاسباتی TAPT خیلی پایینه ولی تاثیرش بعضاً با DAPT رقابت می‌کنه.

۳. ترکیب برنده: DAPT + TAPT
بهترین خروجی زمانی به دست میاد که اول مدل رو روی دامین کلی (مثلاً کل مقالات CS) آموزش بدید و بعد روی دیتای خاص تسک (مثلاً فقط چکیده‌های مربوط به AI). این "Curriculum Learning" ساده، SOTA رو جابجا می‌کنه.

۴. انتقال دانش (Cross-Task Transfer) همیشه مثبت نیست
یه نکته‌ی جالب و غیرشهودی توی پیپر اینه: اگر مدل رو روی تسک A آداپته کنید (TAPT)، ممکنه روی تسک B توی همون دامین پرفورمنسش افت کنه. این یعنی TAPT مدل رو به شدت روی توزیع خاص اون دیتاست Overfit می‌کنه (به معنای مثبتش برای همون تسک، و منفی برای جنرالیزیشن).

۵. انتخاب هوشمند دیتا (Augmented TAPT)
اگر دیتای ترینینگ شما کمه، می‌تونید از روش‌های ساده مثل kNN یا VAMPIRE استفاده کنید تا از دیتای بزرگ دامین، نمونه‌های شبیه به دیتای تسک رو پیدا کنید و با اون‌ها TAPT رو انجام بدید. این کار تقریباً جای خالی دیتای زیاد رو پر می‌کنه.

به نظر من:
امروز خیلی‌ها درگیر RAG یا Prompt Engineering هستن، ولی اگر دارید روی یه محصول جدی توی یه دامین خاص (مثل حقوقی فارسی یا نسخه پیچی پزشکی) کار می‌کنید، Continued Pretraining روی متون تخصصی اون حوزه (DAPT) و بعدش روی دیتای خودتون (TAPT) یه الزام مهندسیه، نه یه فیچر لوکس.
خیلی وقتا مدل‌های کوچیکتر که درست روی دامین آداپته شدن، مدل‌های غول‌پیکر جنرال رو توی تسک‌های تخصصی شکست میدن. فقط به بنچمارک‌های عمومی GLUE و غیره اعتماد نکنید؛ توزیع دیتای واقعی شما با اون‌ها فرق داره.

خلاصه دستورالعمل اجرایی:
۱- دیتای خام دامینتون رو جمع کنید -> DAPT
۲- دیتای خام تسک‌تون رو جدا کنید -> TAPT
۳- حالا برید سراغ Supervised Fine-tuning.

🛠 Join @LLMEngineers Community

معماری Fine-tuning مدل‌های زبانی روی دیتای تخصصی (Domain-Specific) معمولاً با یه چالش بزرگ روبروئه: دیتای باکیفیت کمه و گرون. اکثر ما عادت کردیم دیتاست رو به صورت Random Shuffle بدیم به مدل و امیدوار باشیم Loss بیاد پایین. اما مقاله EDCO نشون میده که ترتیب یادگیری (Curriculum Learning) اگه داینامیک باشه، بازی رو عوض می‌کنه.

روش‌های سنتی Curriculum Learning معمولاً استاتیک هستن و از "آسون به سخت" میرن جلو (مثلاً بر اساس طول متن). اما EDCO میگه برای یک مدل Pre-trained، داده‌های آسون عملاً Noise هستن چون مدل قبلاً اون مفاهیم رو بلده.

متد EDCO (Entropy-based Dynamic Curriculum Orchestration) میاد وسط پروسه Training، دائماً چک می‌کنه که مدل روی کدوم نمونه‌ها "عدم قطعیت" یا همون Inference Entropy بالایی داره.

نکته جالب ماجرا اینجاست که این روش یه جورایی Reverse Curriculum حساب میشه. یعنی به جای اینکه اول آسون‌ها رو یاد بگیره، تمرکز رو میذاره روی نمونه‌هایی که مدل رو به چالش می‌کشن (High Entropy Samples). این کار باعث میشه مدل دچار "Entropy Collapse" نشه (حالتی که مدل الکی اعتماد به نفسش میره بالا و دیگه یاد نمیگیره).

چالش فنی این ایده اینه که محاسبه Entropy برای کل دیتاست در هر مرحله، هزینه پردازشی وحشتناکی داره. تیم نویسنده برای حل این مشکل دوتا تریک جالب زدن:
۱. استفاده از Quick-Answer Prompting: مدل رو مجبور میکنن جواب کوتاه بده تا سریع‌تر پردازش بشه.
۲. تکنیک Prefix Entropy Approximation: به جای کل خروجی، فقط ۵۰ تا ۱۲۸ توکن اول رو برای محاسبه آنتروپی چک میکنن که طبق بنچمارک‌هاشون ۸۳.۵ درصد سریع‌تره و دقتش هم حفظ میشه.

نتیجه نهایی روی دیتای مخابراتی (که پر از اصطلاحات خاصه) نشون داده که هم در SFT و هم در RLFT، این روش بهتر از Random Sampling و روش‌های سنتی عمل کرده.

📃 عنوان مقاله: EDCO: DYNAMIC CURRICULUM ORCHESTRATION FOR DOMAIN-SPECIFIC LARGE LANGUAGE MODEL FINE-TUNING
https://openreview.net/pdf?id=sF0p40wM8X

به نظر من، این مقاله یه حقیقت تلخ رو یادآوری می‌کنه: اکثر ما در پروسه Fine-tuning تنبلی می‌کنیم و فقط دنبال جمع کردن دیتای بیشتر هستیم، در حالی که "نحوه ارائه دیتا" به مدل، به اندازه خود دیتا مهمه. برای پروژه بعدی‌تون اگر دیتای کمی دارید، به جای Data Augmentation الکی، روی مکانیزم‌هایی مثل Active Learning یا همین Dynamic Curriculum وقت بذارید تا مدل روی نقاط ضعفش تمرکز کنه نه روی چیزایی که از قبل بلده.

🛠 Join @LLMEngineers Community

زمانی که صحبت از 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