کورس LLM دانشگاه شریف

این ترم دانشکده کامپیوتر شریف کورسی رو در مقطع تحصیلات تکمیلی با موضوع LLM‌ها (مدل‌های‌زبانی بزرگ) و مسائل مربوط به اونها با تدریس مشترک دکتر سلیمانی، دکتر عسگری و دکتر رهبان ارائه کرده. خوبی این کورس اینه که به صورت جامع و کاملی انواع مباحث موردنیاز رو بحث کرده (از معرفی معماری ترنسفورمری گرفته تا فرآیند‌های جمع آوری داده و روش‌های PEFT و ...) از همه اینها مهمتر، فیلم‌ها و تمرین‌های این کورس هم به صورت پابلیک در لینک درس قرار می‌گیرن. از دست ندید.

لینک کورس:
sharif-llm.ir

لینک ویدیوها:
https://ocw.sharif.edu/course/id/524

#course
#coach

@nlp_stuff

بهبود عملکرد LLM با نشون‌دادن Chain of Thought غلط

مدل‌های زبانی بزرگ با این که کلی از مسائل حوزه پردازش زبان رو درنوردیدند ولی همچنان در برخی مسائل با فاز reasoning‌طور (مثل مثلا حل مسائل ریاضی) دچار مشکلات جدی هستند. یکی از راه‌حل‌های پیشنهادشده برای بهبود عملکرد این مدل‌ها روی این مسائل، راهکار Chain-of-Thought Prompting (به اختصار CoT) هست. تو این راهکار وقتی میخوایم یک مساله را به صورت few-shot به LLM توضیح بدیم عوض این که در example‌هامون صرفا جواب آخر رو بنویسیم و میایم و مرحله به مرحله نحوه رسیدن به جواب رو توضیح می‌دیم و این جوری مدل هم وقتی میخواد به کوئری ما پاسخ بده به نوعی مجبور میشه که مرحله به مرحله جواب رو بنویسه. آزمایشات نشون داده که باعث می‌شه درصد جواب‌های پایانی درستی که می‌ده بیشتر بشه.

حالا یک مقاله اومده و یک ایده به نام contrastive chaint of thought prompting رو مطرح کرده. تو این ایده، علاوه بر این که CoT درست به مدل داده می‌شود بهش CoT اشتباه هم نشون داده می‌شه و آزمایشات مقاله نشون می‌ده که این ایده نشون دادن CoT غلط در کنار CoT باعث میشه تا عملکرد LLM باز هم بهبود پیدا کنه.

لینک مقاله:
https://arxiv.org/abs/2311.09277

#paper
#read

@nlp_stuff

شکست gpt3.5 توسط مدل وزن‌باز Mixtral-8x7B-v0.1 !

خلاصه بخوایم بگیم: جدیدا شرکت Mistral.ai یه مدل داده بیرون به اسم Mixtral-8x7B-v0.1 که با هشت تا مدل هفت میلیارد پارامتری Mistral با روش  high-quality sparse mixture of experts model (SMoE) ساخته شده، تونسته در اکثر ارزیابی‌ها هم لاما ۷۰ میلیاردی و هم جی‌پی‌تی۳.۵ رو شکست بده. خوش‌مزگی داستان اینه که یک سال بعد از جی‌پی‌تی ۳.۵ حالا میشه این مدل رو به صورت لوکال (طبیعتا با رم و جی‌پی‌یو به اندازه کافی) سرو کرد. این مدل رو میسترال خیلی لاتی‌طور اول یه لینک تورنت بدون توضیح گذاشت و بعد که ملت به جنب و جوش دراومدند، چند روز بعد یه توضیحی هم منتشر کرد!

مدل mixtral 8x7b که امروز توسط میسترال منتشر شد یک سطح جدیدی برای مدل وزن‌باز (نه متن‌باز، چون کد و دیتا و... رو نداده) را ارائه کرد و تونست مدل چت جی‌پی‌تی ۳.۵ رو در اکثر بنچمارک‌ها شکست بده. معماری این مدل شبیه مدل میسترال ۷ میلیاردیه (به زودی معماری اون هم براتون شرح خواهیم داد) با این تفاوت که در حقیقت این مدل جدید ۸ تا مدل expert در یک پکه. اینجا از یک تکنیک به نام MoE (Mixture of Experts) استفاده شده. این مدل یک مدل دیکودریه که بلوک فیدفوروارد بین ۸ گروه از پارامترها در هر لایه و برای هر توکن دو تا از این کارشناس‌ها (expert) رو انتخاب میکنه که توکن پردازش بشه. در معماری ترنسفورمرها یک سری لایه feed-forward داره، در MoE جای بعضی از این لایه‌ها از لایه‌های MoE استفاده شده است. لایه‌ی MoE یک شبکه‌ی روتری داره که انتخاب میکنه کدوم کارشناس (Expert) کدوم توکن‌ها رو بهتر پردازش می‌کنند. این تکنینم باعث میشه تعدا پارامترها زیاد بشه اما هزینه و سرعت کنترل بشه چون مدل فقط از بخشی از تعداد کل پارامترها رو برای یک توکن استفاده می‌کنه. همونطور که گفتیم در این میکسترال دو تا کارشناس در هر لحظه انتخاب میشن که باعث میشه سرعت دیکودینگ شبیه یه مدل ۱۲.۹ میلیاردی بشه در صورتی که ۴ برابرش (۴۶.۷ میلیارد) پارامتر داره!! یه عده اشتباه فکر میکردند ۵۶ میلیارد (۸*۷) پارامتر داره ولی اشتباهه چون فقط بعضی لایه‌های feed-forward فقط تکرار شدند نه همگی پارامترها. اگر بابت MoE کمی گیج شدید، نگران نباشید چون این یکی هم مفصلا در پست دیگه‌ای شرح میدیم. تا اینجا دو تا  طلبتون پس.

جونمون براتون بگه که مدل پایه و مدل Instruct رو منتشر کردند. طول کانتکستش ۳۲ هزار شده. تونسته مساوی یا بهتر از مدل ۷۰ میلیاردی لاما۲ و  جی‌پی‌تی ۳.۵ در اکثر بنچ‌مارک‌ها باشه. عکس نتایج رو در پیوست گذاشتیم. پنج تا زبون انگلیسی، فرانسوی، آلمانی، اسپانیایی و ایتالیایی رو بلده (به نظر روی دیتای togethercomputer/RedPajama-Data-V2 ترینش کردند، حدس ماست). توی تسک کدزنی هم خوبه و توی HumanEval به ۴۰.۲ رسیده. در نهایتا هم با Apache2.0 منتشرش کردند که همگی صفا کنیم. مدل Instruct فرمت پرامپت خودشو داره که توی لینک‌هایی که آخر میذاریم هست. مثل میسترال ۷b نمیدونیم دیتاستش چیه و چه حجمی داره و چجور پیش‌پردازش شده. دیتای sft و DPO (برای فاین تیون کردن) هم نمیدونیم! کد لود کردن و اینفرنس هم توی لینک‌ها هست که البته حداقل ۳۰ گیگ رم و جی‌پی‌یویی مثل A100 می‌خواد.


لینک بلاگ پست انتشار مدل:
https://mistral.ai/news/mixtral-of-experts/

لینک مدل پایه Mixtral-8x7B-v0.1:
https://huggingface.co/mistralai/Mixtral-8x7B-v0.1

لینک مدل Mixtral-8x7B-Instruct-v0.1:
https://huggingface.co/mistralai/Mixtral-8x7B-Instruct-v0.1

لینک بلاگ هاگینگ‌فیس:
https://huggingface.co/blog/mixtral

#read
#blog
#link
#model

@nlp_stuff

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

سلام بعد از مدتها. گفتیم با یه خبر برگردیم: شرکت متا لاما۳ رو بیرون داد. علی الحساب چند تا بولت راجع بهش بگیم تا جزئیات مفصل‌تر رو در آینده نزدیک بهتون بگیم:
• پشتیبانی از فارسی (لینک دمو در انتهای پست و عکس اول از نمونه سوال و جواب)
• ۱۰ درصد بهبود نسبت به ورژن‌های قبلی داره
• در دو سایز ۸ و ۷۰ میلیاردی در دو نسخه 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