یه مقایسه‌ی جالب از روند ساخت LLMها بین سال ۲۰۲۳ و ۲۰۲۵

۱. مرحله Pretraining: تمرکز از دیتا میکس‌های عمومی رفته روی دیتاهای باکیفیت‌تر. اولویت با کد بوده و الان دیگه synthetic data هم بهش اضافه شده.

۲. مرحله Midtraining: این مرحله‌ی جدید، یه جور fine-tuning تخصصی بین pretraining و post-training هست. اینجا قابلیت‌های خاص مثل افزایش طول متن (Context-expansion) یا تمرکز روی تسک‌های استدلالی سنگین (Reasoning heavy) به مدل تزریق می‌شه. به نظر من، این مرحله مهم‌ترین تغییره چون اجازه می‌ده مدل‌ها برای کاربردهای خاص بهینه بشن بدون اینکه نیاز به pretrain از اول باشه.

۳. مرحله Post-training: این فاز هم دقیق‌تر شده. قبلاً کلی‌گویی بود، اما الان به دو بخش مشخص SFT برای یادگیری دنبال کردن دستورات و RL برای هم‌راستاسازی نهایی با ترجیحات انسانی تقسیم شده.

۴. مرحله Model Merging: این تکنیک به عنوان یه مرحله‌ی نهایی و مستقل اضافه شده. به جای ساخت یک مدل غول‌پیکر، چند مدل متخصص رو با هم ادغام می‌کنن تا بهترین قابلیت‌های هر کدوم رو داشته باشن. این روش از نظر محاسباتی خیلی بهینه‌تره.

🛠 Join @LLMEngineers Community

مجموعه AgentKit از OpenAI معرفی شد. یه ابزار کامل برای ساخت، دیپلوی و بهینه‌سازی Agentic Workflows. هدف اینه که کل چرخه ساخت یه Agent رو از صفر تا صد پوشش بده و دولوپر رو توی اکوسیستم خودش نگه داره.

این کیت از چند بخش اصلی تشکیل شده:

Agent Builder:
یه محیط ویژوال و node-based برای ساختن ورک‌فلوهای چندمرحله‌ای. به صورت drag-and-drop می‌شه نودها (مدل، ابزار، منطق شرطی) رو به هم وصل کرد و یه Agent ساخت.

ChatKit:
یه UI قابل embed و شخصی‌سازی برای استفاده از Agent ساخته شده. بعد از ساخت ورک‌فلو، یه ID بهت می‌ده که می‌تونی توی ChatKit ازش استفاده کنی و UI رو توی محصول خودت بذاری.

Guardrails:
برای کنترل و ایمن‌سازی ورودی و خروجی‌های Agent.

Evals:
ابزارهایی برای ارزیابی عملکرد Agent، شامل trace grading، ساخت دیتاست و بهینه‌سازی خودکار پرامپت.

روند کار به این صورته که اول با Agent Builder ورک‌فلو رو طراحی می‌کنی، بعد منتشرش می‌کنی و در نهایت با ChatKit یا Agents SDK (برای پایتون و تایپ‌اسکریپت) توی محصول خودت دیپلوی می‌کنی. این چرخه کامل، از طراحی تا ارزیابی، باعث می‌شه فرآیند توسعه سریع‌تر بشه.

به نظر من، این یه حرکت کاملاً استراتژیک برای lock-in کردن دولوپرهاست. OpenAI داره کل استک رو به صورت عمودی یکپارچه می‌کنه تا نیاز به ابزارهای جانبی مثل LangChain یا LlamaIndex رو برای پروژه‌های جدید کمتر کنه. با داشتن Evals و Guardrails داخلی، نیازمندی‌های سطح enterprise رو هم هدف گرفته.

البته هنوز جایگزین ابزارهای اتومیشن مثل Zapier یا n8n نیست، چون اون‌ها اکوسیستم بزرگ‌تری از integration ها دارن. یکی از نقدهای جدی که بهش وارده، نبود قابلیت import/export برای ورک‌فلوهاست که باعث می‌شه شبیه یه سیستم بسته مثل Custom GPT ها عمل کنه و قابلیت انتقال‌پذیری نداشته باشه.

📃 معرفی AgentKit در بلاگ OpenAI
📃 مستندات Agent Builder
💻 نمونه استارتر ChatKit در گیت‌هاب

🛠 Join @LLMEngineers Community

مدل‌های جدید Granite 4.0 از IBM منتشر شدن و هدفشون رقابت روی لیدربوردها نیست. این خانواده از مدل‌ها برای کارهای واقعی و بیزینسی طراحی شدن، جایی که هزینه و پرفورمنس روی GPU های معمولی مهمه، نه فقط اعداد و ارقام تئوری. کاربرد اصلیشون توی ساخت ایجنت‌های نرم‌افزاری، اتوماسیون پشتیبانی و تسک‌های مبتنی بر function-calling هست که نیاز به سرعت و مصرف رم پایین دارن.

معماری این مدل‌ها یه ترکیب هیبریدی از Mamba-2 و Transformer هست. بیشتر لایه‌ها از نوع Mamba-2 هستن که یه State Space Model (SSM) محسوب میشه و باعث میشه مقیاس‌پذیری با افزایش طول متن، خطی باشه. چند تا بلاک Transformer هم به صورت دوره‌ای در معماری قرار داده شده. نتیجه‌ی این طراحی، کاهش ۷۰ درصدی مصرف RAM در پردازش متن‌های طولانی و افزایش توان پردازشی (throughput) در بچ‌سایزهای بالاست. مدل‌های بزرگ‌تر از معماری Mixture of Experts (MoE) هم استفاده می‌کنن تا پارامترهای فعال رو پایین نگه دارن.

مدل‌های اصلی که فعلاً به صورت Base و Instruct عرضه شدن این‌ها هستن:

Granite-4.0-H-Small:
مدل اصلی با ۳۲ میلیارد پارامتر (۹ میلیارد فعال). برای ساخت ایجنت‌های پیچیده که با چند ابزار کار می‌کنن مناسبه. روی ۸-بیت حدود ۳۳ گیگ رم لازم داره.

Granite-4.0-H-Tiny:
یه مدل جمع‌وجور با ۷ میلیارد پارامتر (۱ میلیارد فعال). برای کارهای سبک روی سخت‌افزارهای ضعیف‌تر (Edge) یا سیستم‌های لوکال با رم ۸ تا ۱۲ گیگ عالیه. روی ۸-بیت حدود ۸ گیگ رم می‌گیره.

Granite-4.0-H-Micro:
یه مدل ۳ میلیاردی بدون MoE. برای دستگاه‌های خیلی محدود با ۴ گیگ رم GPU طراحی شده.

Granite-4.0-Micro:
یه نسخه‌ی ۳ میلیاردی دیگه که کاملاً مبتنی بر Transformer هست. این مدل برای سازگاری حداکثری با فریمورک‌هایی که هنوز معماری هیبریدی رو کامل ساپورت نمی‌کنن، ارائه شده.

به نظر من، حرکت IBM به سمت مدل‌های کوچیک، بهینه و اپن‌سورس (Apache-2.0) خیلی هوشمندانه‌ست. بازار داره از مدل‌های غول‌پیکر و پرهزینه اشباع میشه و نیاز به مدل‌هایی که بشه به راحتی روی یه A100 یا حتی RTX 3060 اجراشون کرد، کاملاً حس میشه. تمرکز روی function-calling و instruction-following هم نشون میده که هدف، کاربردهای عملی و agentic بوده. این مدل‌ها برای cosplay کردن SOTA ساخته نشدن، برای کار واقعی طراحی شدن.

برای اجرا و تست، مدل‌ها روی Hugging Face، Ollama و LM Studio در دسترس هستن. پشتیبانی کامل از vLLM و Transformers هم وجود داره. نسخه‌های بهینه‌شده برای استدلال (Thinking) هم اواخر ۲۰۲۵ منتشر میشن.

📃 بیانیه‌ی رسمی IBM

📃 کالکشن مدل‌ها در Hugging Face

🛠 Join @LLMEngineers Community

یه مدل جدید از Zhipu AI به اسم GLM-4.6 منتشر شده که تمرکز اصلیش روی ایجنت‌ها و کدنویسیه. این مدل یه سری آپدیت‌های کلیدی نسبت به نسخه‌ی قبلیش داره.

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

مهم‌ترین تغییراتش ایناست:
پنجره‌ی زمینه‌ش یا همون context window به ۲۰۰ هزار توکن افزایش پیدا کرده و می‌تونه تا ۱۲۸ هزار توکن خروجی تولید کنه. این برای تسک‌های برنامه‌ریزی پیچیده و کار با داده‌های طولانی خیلی به درد می‌خوره.
تواناییش توی استفاده از ابزارها (tool use) و ساخت ایجنت بهتر شده و با فریمورک‌های ایجنتیک رایج راحت‌تر ادغام میشه.
توی کدنویسی هم روی بنچمارک‌ها و هم ابزارهای واقعی مثل Cline و Roo Code پیشرفت داشته.
از نظر بهینگی هم گفته شده که به طور متوسط بین ۱۵ تا ۳۰ درصد توکن کمتری نسبت به نسخه‌ی ۴.۵ مصرف می‌کنه.

از نظر فنی، این مدل یه معماری Mixture of Experts یا MoE با حدود ۳۵۷ میلیارد پارامتر داره. نکته‌ی مهم اینه که برای پردازش هر توکن، فقط حدود ۳۲ میلیارد پارامتر فعال میشه. این یعنی با وجود سایز بزرگ، برای inference گرفتن بهینه‌تر عمل می‌کنه. وزن‌های مدل هم به صورت open-weights با لایسنس MIT روی Hugging Face منتشر شده.

در مورد عملکرد، طبق بنچمارک‌های خود Z.ai، این مدل تقریباً با Claude Sonnet 4 برابری می‌کنه. البته خودشون هم اشاره کردن که توی کدنویسی هنوز از Sonnet 4.5 عقب‌تره. این شفافیت خوبیه و نشون میده که هنوز جای پیشرفت وجود داره.

برای استفاده ازش چندتا راه هست:
از طریق API خود Z.ai یا OpenRouter با اسم مدل glm-4.6 در دسترسه. قیمت‌گذاری روی OpenRouter برای هر میلیون توکن، ۰.۵ دلار ورودی و ۱.۷۵ دلار خروجی هست.
یه قابلیت جالب به اسم thinking mode داره که برای تسک‌های پیچیده و استدلال‌های چند مرحله‌ای ایجنت‌ها فعال میشه.
برای اجرای لوکال هم می‌شه از فریمورک‌هایی مثل vLLM یا SGLang استفاده کرد.

📃 بلاگ‌پست معرفی GLM-4.6

📃 صفحه‌ی مدل در Hugging Face

📃 مستندات فنی و راهنمای API

📃 قیمت‌گذاری در OpenRouter

🛠 Join @LLMEngineers Community

خیلی موافقم

خیلی جاها دیدم اشتباها به یه 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