لاما۳ با پشتیبانی از فارسی آمد

سلام بعد از مدتها. گفتیم با یه خبر برگردیم: شرکت متا لاما۳ رو بیرون داد. علی الحساب چند تا بولت راجع بهش بگیم تا جزئیات مفصل‌تر رو در آینده نزدیک بهتون بگیم:
• پشتیبانی از فارسی (لینک دمو در انتهای پست و عکس اول از نمونه سوال و جواب)
• ۱۰ درصد بهبود نسبت به ورژن‌های قبلی داره
• در دو سایز ۸ و ۷۰ میلیاردی در دو نسخه base و instruct ارائه شده
• توکنایزرش با اندازه ۱۲۸ هزار تا آپدیت شده
• باز هم اجازه استفاده تجاری داده شده
• روی ۱۵ تریلیون توکن آموزش داده شده
• روی ۱۰ میلیون نمونه لیبل‌زده شده توسط انسان فاین‌تیون شده
• برای alignment هم از sft و ppo و dpo استفاده شده
• روی mmlu بهترین مدل زبانی وزن‌باز هست (بالای ۸۰)
• مدل ۸ و ۷۰ میلیاردی نسخه instruct یه ترتیب با ۶۲.۲ و ۸۱.۷ در HumanEval وضعیت بسیار خوبی در کدزنی دارند.
• اندازه context window با اندازه پیش فرض ۸۱۹۲ و با قابلیت افزایش

لینک به تصاویری از مدل:
https://t.iss.one/overfit_stuff/313
لینک بلاگ متا:
https://ai.meta.com/blog/meta-llama-3/
لینک بلاگ توضیح و استفاده لاما:
https://huggingface.co/blog/llama3
لینک دمو لاما۳ (پشتیبانی از فارسی):
https://www.llama2.ai/
لینک کالکشن هاگینگ‌فیس:
https://huggingface.co/collections/meta-llama/meta-llama-3-66214712577ca38149ebb2b6



#model


@nlp_stuff

اندر تفاوت‌های ML در ریسرچ و پروداکشن

تا حالا زیاد درباره تفاوت‌های نگاه در یادگیری ماشین به جهت ریسرچ و پروداکشن صحبت شده. اما در این پست به بهانه معرفی کتاب Designing Machine Learning Systems می‌خواستیم که خیلی جمع و جور و خلاصه این تفاوت نگاه رو به رشته تحریر دربیاریم. همون‌طور که در تصویر دوم ضمیمه‌شده مشخصه (این جدول برگرفته از فصل اول این کتابه) یکی از ملموس‌ترین تفاوت‌ها بحث اولویت محاسباتیه که در ریسرچ، بیشتر تمرکز بر روی کوتاه‌تر کردن زمان Train گذاشته میشه اما در پروداکشن بیشتر تمرکز بر روی زمان inference کوتاهه. یا مثلا بحث distribution shiftهای مداوم که در یک مساله تحقیقاتی شاید کمتر اتفاق بیفته.
اما به نظر مهم‌ترین تفاوت که عمدتا باعث fail شدن پروژه‌های ML در صنعت میشه همون سطر اول این جدوله که شاید برای افراد ناملموس‌تر باشه. بله؛ وجود افراد در سازمان با نگاه‌های متفاوت که هر کدوم به نوعی هدف و سهمی از این نوع پروژه‌ها دارند، مهم‌ترین تهدید و همزمان مهم‌ترین فرصت برای این پروژه‌هاست. اگر بتونیم به جای تمرکز بر متریک‌های تکنیکال بر روی بهبود متریک‌های بیزنسی تمرکز کنیم این تهدید رو تبدیل به فرصت کردیم و در غیر این صورت باید بریم خونه‌هامون.
در آینده منتظر پست‌های بعدی از این کتاب باشید.

لینک کتاب:
https://www.amazon.com/Designing-Machine-Learning-Systems-Production-Ready/dp/1098107969

#book

@nlp_stuff

سفت کردن جای پا با فریم‌بندی درست مسائل ML

در ادامه رشته‌پست‌ها از کتاب Designing Machine Learning Systems با یک موضوع مهم از فصل دوم این کتاب در خدمتتون هستیم. فریم‌بندی درست مسائل در حوزه ML می‌تونه درصد موفقیت پروژه‌ها رو در این حوزه تا حد زیادی بالا ببره. برای فریم‌بندی می‌تونیم به این شکست فکر کنیم که چه نوع ورودی باید به مدل بدیم (input features)، چه خروجی باید بگیریم (target labels) و انتظار داریم چه چیزی رو مدل یاد بگیره (objective functions).
درباره مورد اول و دوم یک چاله رایج وجود داره و اون هم وابسته کردن مدل به مفاهیمیه که متغیر هستند. کتاب درباره نوع خروجی دادن مدل یک مثال میزنه و اون هم مساله تشخیص اپ بعدی‌ای ست که کاربر بر روی اون در یک اپ‌استور کلیک می‌کنه. یک مدل اولیه می‌تونه این باشه که خروجی مدل رو یک وکتور به اندازه سایز تمام اپ‌ها درنظر بگیریم و مدل با دادن فیچرهای ترجیحات کاربر، حدس بزنه که احتمال کلیک بر روی هر یک از اپ‌ها چقدر هست. با این فریم‌بندی عملا سایز خروجی مدل به تعداد اپ‌های حاضر بر روی اپ استور bind شده که می‌دونیم با نرخ بالایی تغییر می‌کنه. همچنین مساله شبیه یک multi class classification شده که مساله‌ای به مراتب سخت‌تر از binary classification است. شکل درست کار در این جا می‌تونه ورودی دادن فیچرهایی از ترجیحات کاربر و فیچرهای اپ‌ها به صورت توامان با هم باشه و از مدل بخوایم که بگه فلان اپ رو کاربر کلیک میکنه یا نه (طبق تصاویر در اینجا موقع inference نیاز داریم که به تعداد اپ‌ها مدل رو صدا بزنیم که قابلیت موازی‌سازی داره و مشکلی ایجاد نمی‌کنه ولی در عوض خروجی باینری برای مدل داریم و ابعاد خروجی متغیر نیست).
با این تغییر همچنین نیاز نیست برای adopt شدن مدل با هر اپ جدید، حتما retrain انجام بشه و حتی چالش cold start برای اپ‌های جدید هم تا حدی با الگویابی مدل از اپ‌های قبلی که شبیه اپ‌های جدید هستند، می‌تونه بهتر بشه.
همین چاله برای فیچرهای ورودی هم می‌تونه پیش بیاد که البته کتاب بهش اشاره‌ای نمی‌کنه اما با کمی فکر کردن می‌تونیم مثال‌های مختلفی براش پیدا کنیم. مثلا ممکنه شما در مساله‌تون فیچری داشته باشید که انواع مختلف واکنش‌های کاربر رو بخواید بشمارید و ممکنه مثلا واکنش‌های مثبت، انواع مختلفی داشته باشند که اثر یکسانی در بیزنس دارند اما بسته به برخی تصمیمات دیزاین یا بیزنس کم و زیاد می‌شند. در اینجا یک مفهوم ثابت وجود داره و اون واکنش مثبت کاربره و تفکیک انواع واکنش‌ها باعث میشه روی فیچری تکیه کنید که جزییات بیشتری رو فراهم می‌کنه اما در عوض می‌تونه تغییر کنه و یا حتی مرز مشخصی بین کاربر‌ها برای اون وجود نداره.
نکته‌ای که مهمه اینه که با فریم‌بندی درست مسائل ML می‌تونیم تا حد زیادی از effort مساله کم کنیم و به نوعی جای پامون رو برای توسعه پروژه در آینده سفت‌تر کنیم.

#book

@nlp_stuff

فاین تیون در سال ۲۰۲۵

اخیرا یکی از مهندس‌های هاگینگ فیس به نام فیلیپ اشمیت با یک بلاگ پست زیر و بم «تنظیم دقیق (SFT) مدل‌های زبانی وزن‌باز با هاگینگ فیس» را توضیح داده. نوت‌بوک‌ها و اسکریپت‌های پایتونیش را هم گذاشته.

پست شامل این موارده:
- کجا خوبه فاین تیون کنیم و کجا از پراپمتینگ استفاده کنیم؟
- چطور از کتابخونه‌ای مثل TRL (Transformer Reinforcement Learning) (برای SFT) استفاده کنیم؟
- چطور دیتاست مناسب فاین تیون را آماده کنیم؟
- چطور از روش QLoRA (برای آموزش با کوانتیزیشن ۴ بیتی)، روش Spectrum (برای انتخاب بهینه‌ی لایه‌های پراطلاعات)، Flash Attention و Liger Kernel (برای سریعتر شدن) استفاده کنیم؟
- چطور از کتابخونه‌ی فوق العاده‌ی DeepSpeed و Accelerate برای استفاده از چندین GPU بهره ببریم؟
- چطور ارزیابی کنیم؟
- چطور با استفاده از کتابخونه‌هایی مثل TGI (Text Generation Inference) و vLLM مدلمون را روی پروداکشن ببریم.

خلاصه توصیه می‌کنیم این پست جمع و جور (البته با کلی لینک برای مطالعه عمیق‌تر) را حتما بخونید.

لینک به بلاگ:
https://www.philschmid.de/fine-tune-llms-in-2025

#read
#blog

@nlp_stuff

مدل‌های استدلالی (reasoning) چیست و چگونه ساخته می‌شوند؟

حتما این روزها بارها مدل‌های استدلالی مثل DeepSeek R1 به گوش و چشمتون خورده. اگر هنوز دقیق نمی‌دونید این مدلها معنیشون چیه و کجا به درد میخورند، بیاید که دواتون پیش آقای سباستین راشکا (نویسنده کتاب Build a Large Language Model From Scratch) هست. ایشون یه بلاگ مشتی راجع به مدل‌های استدلالی (همون reasoning) نوشته و مثل همیشه خیلی خوب داستان را شفاف کرده. این را داشته باشید تا منابع بعدی.

مواردی که در این بلاگ توضیح میده:
- تعریف مدل استدلالی چیه؟
- کجا باید از این مدل‌ها استفاده کنیم؟
- پایپلاین پشت R1 چیه؟
- چهار روش اصلی برای ساختن و بهبود مدلهای استدلالی چیه؟
- نکاتی پیرامون مدل R1
- نکاتی برای توسعه مدل‌های استدلالی با بودجه بسیار کم (حتی به اندازه دانشگاه‌های ایران کم ☺️)

اول میگه استدلال (reasoning) واسه وقتیه که سوالی را حل کنیم که نیاز به راه‌حل پیچیده و چندمرحله‌ای داره. مثلا پایتخت فرانسه کجاست اینجوری نیست ولی مثلا حل یه سوال فیزیک و ریاضی یا سوال acmای اینجوریه.

بعد میاد میگه سه جا خوب نیست اصلا از این مدل‌ها استفاده کنیم:
- وقتی ما نیاز به سرعت و قیمت پایین داریم
- وقتی سوال‌های دانشی (knowledge based) مثل همین پایتخت داریم چون این مدل‌ها دچار هذیان‌گویی میشن
- سوالات ساده چون این مدل‌ها مثل اکثر ما overthink میکنند

در ادامه میاد پایپلاین R1 را به شکل بسیار روان و ساده‌ای توضیح میده. عکس ضمیمه یک کلیتی از این پایپلاینه. میگه deepseek سه تا مدل داده: DeepSeek-R1-Zero، DeepSeek-R1 و DeepSeek-R1-Distill.
اول. با مدل DeepSeek-V3 که سپتامبر بیرون دادن، با یک RL cold start (بدون SFT) شبیه همون RLHF با دو تا reward (یکی دقت و دومی فرمت به جای ترجیح آدمیزاد) آموزش میده؛ و مدل DeepSeek-R1-Zero را درست میکنه. بعد از همین مدل میاد یه داده SFT بزرگ درست میکنه. ریوارد دقت میاد از leetcode استفاده میکنه که نتیجه کد را مستقیما اجرا کنه و بگه!! فرمت هم میاد از یه سری تگ استفاده میکنه که دقیقا با همون فرمت جواب بده.
دوم. بعد دوباره همون مدل زبانی اولیه سپتامبری DeepSeek-V3 را با همین دیتا SFT که در مرحله قبل ساخته شده بود یه بار فاین تیون میکنه و دوباره همون RL رو میزنه. این بار ولی بهش consistency هم اضافه میکنه که مدل سر چند زبانه بودن پنالتی نزنه. از همین مدل دو تا دیتاست SFT میسازه که یکیش با اندازه ۶۰۰ هزارتا chaing of thoughts داره و دیگری با اندازه ۲۰۰هزارتا knowldegeای هستش. بعد میاد یه RL دیگه هم میزنه که دیتاش کد و ریاضی هست. اینجا مدل DeepSeek R1 معروف ساخته میشه.
سوم. از اون دوتا دیتای SFT هم برای آموزش مدل‌های distill استفاده میکنه. البته اینجا distill مثل اون معروفه نیست، اینجا وقتی دیتای sft رو یه مدل قوی درست میکنه و مدل کوچیک (نیم الی ۷۰ میلیاردی) باهاش فاین تیون میشه، بهش میگن distillation.

خلاصه چهار تا روش برای تولید مدل استدلالی میگه:
- روش inference-time scaling: که از پرامپت و اینا استفاده میشه. منابع بیشتری لازمه. گرونتر هم درمیاد چون خیلی حرف میزنه.
- روش RL خالص مثل DeepSeek-R1-Zero
- روش SFT + RL مثل DeepSeek-R1
- روش SFT خالص با distillation: مثل DeepSeek-R1-Distill-Qwen
برای هر کدوم میزان کارایی رو توضیح میده و نهایتا میگه حالت سوم بهترین نتیجه رو میده ولی موارد دیگه هم چیزای جالبی بهمون یاد میده مثل اینکه RL خالی هم به استدلال مدل خیلی کمک میکنه.

در این بلاگ حدس‌های خوبی هم راجع به اینکه O1 و mini-O1 هم چطور آموزش داده شدند میگه که O1 ترکیب سوم و اولیه و o1-mini روش چهارم هست.

در نهایت هم میاد نظراتش رو راجع به R1 vs O1 میگه: در کل شبیه هم هستند ولی R1 بهینه‌تر و ارزانتره که دلیلش رو این میدونه که دیپ‌سیک بیشتر روی آموزش مدل وقت گذاشته ولی o1 روی inference-time رفته. و چون ما اندازه مدل o1 رو نمیدونیم خیلی مقایسه منصفانه‌ای نخواهیم داشت. درباره‌ی هزینه هم میگه این ۶ میلیون دلار که معروف شده ترکیب DeepSeek-R1 (همون سپتامبریه که پایه‌ی R1 هست) و R1 هستش ولی هزینه R1 رو دیپ‌سیک مشخص نکرده.

برای موضوع آخر هم میگه کسایی که پول کم هم دارند خوبه برن سراغ Distillation: به لطف مقاله مفصلی که برای R1 نوشتند مشخص شد که این روش هم خیلی موثره. مثلا میگه مقاله‌ای اومده یه مدل به نام Sky-T1 منتشر کرده که با ۴۵۰ دلار (۴۰ تومن) مدل ۳۲ میلیاردی را با ۱۷ هزارتا دیتای sft یه فاین تیون هدفمند کرده و در مواردی شبیه o1 عمل کرده!! موارد مهمی هم ادامش راجع به Journey Learning میگه که دیگه توی پست جا نمیشه :))

لینک پست:
https://sebastianraschka.com/blog/2025/understanding-reasoning-llms.html

#read
#blog

@nlp_stuff

به سوی سیستم‌۲

پیشرفت‌های هوش مصنوعی در دهه ۲۰۱۰، مدیون آموزش مدل‌های بزرگ دیپ لرنینگی روی دیتاست‌های بزرگ بوده، چیزی که بهش اسکیل‌کردن دیتا و پارامتر گفته می‌شه. با وجود تمام پیشرفت‌های دیپ لرنینگ، اما همچنان شبکه‌های عصبی در برخی مسائل مخصوصا ریزنینگی با سطح انسان فاصله دارند.در چنین شرایطی به قول ایلیا ساتسکیور، دیتا برای هوش مصنوعی به حکم سوخت فسیلی در حال اتمامه و ما دیگه بیشتر از یک اینترنت نداریم تا ازش دیتای آموزشی جدید برای مدل‌هامون بسازیم. وقتی که دیگه نمی‌شه پارامتر‌های مدل و یا داده آموزشی رو اسکیل کرد، شاخه تحقیقاتی جدیدی در پی اسکیل‌کردن میزان محاسبه در زمان اینفرنس یا به اصطلاح inference time compute هست، ایده‌ای که مغز اصلی کارهایی مثل o1 و deepseek هست. این ایده خیلی شبیه بحث‌های دو سیستم پردازشی سیستم‌۱ و سیستم‌۲ در ذهن انسانه. جایی که سیستم‌۱ مسئول اعمال ناخودآگاه و ادراکی انسانه و سیستم‌۲ هم مسئول اعمالی که نیاز به راه‌حل‌های گام به گام دارند (قبلا اینجا راجع بهش صحبت کرده بودیم) حالا این ترم در دانشگاه شریف، درسی با عنوان سیستم‌۲ ارائه شده که قراره به بررسی این داستان و راه‌حل‌های ارائه شده براش بپردازه. موارد زیر جزو سیلابس این درس هستند:

- مقدمه بر مسائل ریزنینگ و سیستم‌۲
- معرفی روش‌های نوروسیمبلیک
- تولید برنامه
- انواع روش‌های پرامپت‌دهی مبتنی بر CoT مثل ToT
- مکانیزم‌های اسکیل‌کردن محاسبه در LLM‌ها
- ریزنینگ با کمک گراف‌های دانش
- نقش LLM Agent‌ها در ریزنینگ
- ارتباط کامپوزیشنالیتی با سیستم‌۲

لینک پلی‌لیست یوتیوب درس:
https://www.youtube.com/playlist?list=PLFr7f4WLNwracR8k8jgYONAp-2pmKrdc3

لینک پلی‌لیست آپارات درس:
https://www.aparat.com/playlist/14269123

لینک کانال تلگرامی درس:
https://t.iss.one/system2_spring2025

پی‌نوشت: اگر میخواید بدانید o1 و deepseek چه ایده‌ و تاریخچه‌ای پشتشونه و مسیر چند سال آتی هوش مصنوعی چه شکلی هست این کورس رو ببینید

#course

@nlp_stuff

چه قدر تا بی‌کارشدن بک‌اندی‌ها فاصله داریم؟

عمده استفاده برنامه‌نویس‌ها از LLM‌ها در سطح پیاده‌سازی فانکشن‌ها و یا ادیت تکه‌های مختلف کد بوده. اما آیا LLM‌ها می‌تونند یک پروژه رو به صورت انتها به انتها و ماژولار و البته با کیفیت مناسب پروداکشن پیاده‌سازی کنند؟ یک کار جالبی اومده که سعی کرده برای همین نیازمندی پیاده‌سازی انتها به انتها پروژه‌های بک‌اندی بنچمارک ارائه بده. این بنچمارک که BaxBench نام داره، ۲۸ تا سناریو نیازمندی تعریف کرده و تلاش کرده با ۱۴ تا فریمورک (از شش زبان مختلف) مختلف این نیازمندی‌های رو با LLM‌ها پیاده‌سازی کنه (یعنی سرجمع ۳۹۲ تسک می‌شه). از اونور هم ۱۱ تای LLM‌ پیشرو فعلی رو روی این تسک‌ها گذاشته و خواسته که کدشون رو تولید کنند. برای ارزیابی اما چه کرده؟ دو جهت ارزیابی رو در پیش گرفته، یک جهت فانکشنال تست‌هایی که تعریف کرده و روی کدهای خروجی تست می‌گیره تا ببینه آیا سیستم درست پیاده‌سازی شده یا نه، و جهت دیگه هم این که از نظر امنیتی و آسیب پذیری، کدهای نوشته‌شده رو سنجیده. برای این کار برای هر سناریو، از یک متخصص امنیت خواسته تا اتک‌های ممکن رو تعریف کنه و سپس اونها رو سیستم‌های خروجی تولیدشده اجرا گرفتند تا ببیند وضعشون چه طوریه. پس در نهایت کد خروجی LLM‌ می‌تونه سه وضعیت داشته باشه: اصلا درست نباشه، درست باشه ولی آسیب‌پذیری امنیتی داشته باشه و در نهایت هم درست باشه و هم عاری از آسیب‌پذیری.

نتایج LLM‌های مختلف هم روی این بنچمارک که بهترین‌‌شون که o3-mini بوده باشه حدود ۶۰ درصد از تسک‌ها رو تو فانکشنال تست پاس شده که البته نصف همین رقمش هم دچار آسیب پذیری امنیتی بودند و یعنی o3-mini روی این بنچمارک سرجمع فقط ۳۵.۲ درصد تسک‌ها رو براشون خروجی درست و عاری از آسیب‌پذیری تونسته تولید کنه (البته یک ablation جالبی که زده این بوده که اومده در پرامپت‌دهی به LLM بهش نکات امنیتی رو گوشزد کرده و همینجوری تونسته درصد کدهای درست امن تولیدشده رو بیشتر کنه) البته o3-mini نه بهترین در تولید کد بوده و نه بهترین در امنیت، بلکه شبیه وزنه‌بردارها تونسته در مجموع بهترین باشه. در واقع ممکنه یک مدل در تولید کد عملکرد خوبی داشته باشه ولی در امنیت اون کد نه و بالعکس.

اما اکسپریمنت‌هاش از مقایسه اونوری، یعنی عملکرد روی فریمورک‌های مختلف، هم مطابق انتظار این شکلی بوده که LLM ها روی فریمورک‌هایی که شهرت و محبوبیت کمتری دارند و البته اونایی که برای راه‌اندازی یک http server نیازمند پیاده‌سازی در چند فایل هستند عملکرد پایین‌تری دارند.

در کل، از این پس احتمالا بنچمارک‌های انتها به انتهای بیشتری حول و حوش موضوع خودکارسازی توسعه نرم‌افزار خواهیم دید. روزهای جالبی در انتظاره البته نه برای برنامه‌نویس‌ها

لینک:
https://baxbench.com/

@nlp_stuff

مفهوم Agent چیست و چگونه کار می‌کنند؟

خانم چیپ هوین بلاگ پست مفصلی راجع به Agent (به قول راسل، هدف غایی هوش مصنوعی) نوشتند. به شدت توصیه می‌کنیم به دور از هایپ بخونید.
این پست ۴ بخش داره: تعاریف، ابزارها، برنامه‌ریزی، ارزیابی و نقاط شکست!

تعاریف. agent هر چیزیه که از محیطش اطلاعات دریافت کنه و روی محیط عملی انجام بده. پس دو مشخصه داره: محیطش و عملگرهاش. محیطش با هدفی که داره تعریف میشه و عملگرهاش با ابزارهایی که در اختیارش قرار دادیم. مثلا یک ایجنت نرم افزاری محیطش میشه ترمینال و فایل سیستم و اکشن‌هاش میشه سرچ کردن و خوندن  و نوشتن در فایلها (عکس ۱). agentها ‌نیاز به مدل قوی‌تری دارند، چون کارهای مهم‌تری می‌کنند و ریسک بالاتری دارند و چون مراحل زیادی طی می‌کنند، خطاها در هم ضرب میشن و مثلا یک مدل با دقت ۹۵٪ در انجام کاری، بعد از ده مرحله، با ۶۰٪ دقت کار نهایی را تحویل میده.

ابزارها. ابزار بیرونی کمک میکنه ورودی بهتر جمع بشه و اکشن‌های بهتری داشته باشیم. اما نباید همه ابزارها را همینجوری در اختیارش بگذاریم چون بعدش فهمیدن و استفاده مفید ازشون سخت میشه. ابزارها سه گروه میشن: knowledge augmentation، capability extension و write actions. دسته‌ی اول ابزارهای تولید محتوا هستند که کمک میکنند بروز باشیم و کمتر هذیون بگیم مثلا سرچ در اینترنت یا API دیتای محصولات فروشگاه. دسته دوم ابزارهای بهبود یهویی توانایی مدل هستند. مثلا مدل‌های زبانی در انجام عملگرهای ساده ریاضی مثل تقسیم هم گاهی گند می‌زنند. پس بهش یه ماشین حساب بدیم یا مثلا از یک مدل تولید عکس جدا استفاده کنیم. دسته سوم. ابزارهایی که تغییر ایجاد میکنند. مثلا ایمیل زدن، انتقال پول.

برنامه‌ریزی. مغز یک agent همون مدلیه که تسک پیچیده را برنامه‌ریزی میکنه. خروجی برنامه یک سری مراحله که باید به ترتیب طی بشه. برنامه‌ریزی باید از اجرا جدا باشه. یعنی از مدل اول میخواهی (مثلا با CoT) برنامه (یا برنامه‌ها) را ارائه بده و بعد از تایید شروع به اجرا کنه. تا اینجا سیستم ما سه قسمت داشت: تولید برنامه، ارزیابش، اجراش (عکس ۲). حالا اگر بیای برای هر کدوم یک agent بذاری، میشه mutli-agent مثلا قبل از هر چیز یه agent تشخیص هدف مشتری (intent) بذاری. راحتترین راه برای تولید برنامه هم پرامپته. مثلا برای آموزش مشتری‌ها راجع به محصولات، به مدل توابع لازم و چند تا مثال از سوالات کاربران و جواب درست را میدیم (عکس ۳‍).
سه تا نکته مهم در تولید برنامه هست: نحوه تعریف و صدا زدن ابزارها، ریزدانگی برنامه، برنامه‌های پیچیده. اولی (نحوه معرفی)، یه سری چارچوب داره که به مدل بفهمونیم لازمه از این ابزارها استفاده کنه یا خودش هر طور صلاح میدونه (عکس ۴). در ریزدانگی باید دقت کنیم که نباید زیاد جزئی (تا اسم تابع) از مدل تولیدکننده بخواهی. چون دوباره تعریف کردن یا فاین تیون کردنشون سخته. خوبه بهشون بگی به زبون طبیعی مراحل را تولید کن. بعد یه مدل ساده‌تر این جملات زبان طبیعی را به اسم توابع تبدیل کنه. برای سومی هم؛ همیشه برنامه‌ها به صورت پشت سر هم نیستند. میتونه موازی یا شرطی باشه یا حلقه داشته باشه (عکس ۵).
در ادامه راجع Reflection صحبت میکنه. agent باید مداوم خودش، خودشو بررسی کنه که از برنامه تا نتیجه همه چی درسته؟ این ارزیابی و اصلاح، میتونه توسط خود agent انجام بشه یا بیرونش. چارچوب‌هایی مثل ReAct هست که یک حلقه متشکل از برنامه، اکشن و ارزیابیه تا وقتی که به جواب برسه (عکس ۶). اگر ارزیاب مدل دیگه‌ای باشه به این Reflexion میگن.
برای نحوه انتخاب ابزارها از مقالاتی مثل Chameleon صحبت میکنه که از ۱۳ تا ابزار استفاده میکنه. هر چی تعداد ابزارها بیشتر باشه، مثل انسان برای مدل سخت‌تره ازشون استفاده کنه. راه‌هایی برای انتخاب مجموعه ابزارها هست؛ مثلا با کدوم ابزارها خطای مدل بیشتره، حذف ابزار چقدر کارایی را کاهش میده، از کدوم‌ها بیشتر استفاده میکنه. مقاله Chameleon نشون داد که تسک‌ها و مدل‌های مختلف ابزارهای مختلفی لازم دارند و نباید همینجوری همه ابزارها رو به مدل بدیم (عکس ۷).

ارزیابی و نقاط شکست. شکست سه عامل داره: برنامه، اجرای ابزارها و بهینگی. در گروه اول برنامه میتونه ابزار اشتباه یا پارامترها و ورودی‌های اشتباه انتخاب کنه، محدودیت را در نظر نگیره و.... در گروه دوم از ابزار درستی استفاده شده اما خود ابزار (مثلا تبدیل متن به کوئری) غلط کار میکنه. در گروه سوم هم همه چیز درسته اما بهینه نیست. مثلا قدم‌های زیادی طی میشه. برای ارزیابی میزان شکست یک agent میشه یه دیتاست از تسک‌ها و ابزارها درست بشه و ازش بخواهیم N تا برنامه درست کنه. بعد ببینیم چندتاشون درست بود، چند تا برنامه باید درست کنه تا به یه برنامه خوب برسیم، چقدر کنده و ....

لینک پست:
https://huyenchip.com/2025/01/07/agents.html

#read
#blog

@nlp_stuff