AI Engineers
رفتن به کانال در Telegram
A highly technical blog tailored for AI engineers. Chat: @AI_LLMs Personal blog: mshojaei77.github.io/ Contact me: @realshojaeii
نمایش بیشتر2 610
مشترکین
+624 ساعت
+177 روز
+11930 روز
در حال بارگیری داده...
جذب مشترکین
اکتبر '26اکتبر '26
اکتبر '26
+3
در 0 کانال‌ها
سپتامبر '26
+143
در 1 کانال‌ها
Get PRO
اوت '26
+164
در 2 کانال‌ها
Get PRO
ژوئیه '26
+280
در 2 کانال‌ها
Get PRO
ژوئن '26
+218
در 1 کانال‌ها
Get PRO
مه '26
+17
در 0 کانال‌ها
Get PRO
آوریل '26
+37
در 1 کانال‌ها
Get PRO
مارس '26
+7
در 0 کانال‌ها
Get PRO
فوریه '26
+30
در 0 کانال‌ها
Get PRO
ژانویه '26
+21
در 0 کانال‌ها
Get PRO
دسامبر '25
+259
در 0 کانال‌ها
Get PRO
نوامبر '25
+83
در 1 کانال‌ها
Get PRO
اکتبر '25
+51
در 0 کانال‌ها
Get PRO
سپتامبر '25
+1 437
در 1 کانال‌ها
Get PRO
اوت '250
در 6 کانال‌ها
Get PRO
ژوئیه '25
+116
در 3 کانال‌ها
| تاریخ | رشد مشترکین | اشارات | کانال‌ها | |
| 01 اکتبر | +3 |
پست‌های کانال
| 2 | امروز Jev 1.13 رو از طریق API رسمی OpenRouter آزمایش کردم، و نتیجه‌اش بیشتر از چیزی که انتظار داشتم جالب بود.
روی دیتاست MASSIVE با ۵٬۹۴۸ جمله‌ی فارسی و انگلیسی و ۶۰ نوع Intent، چهارده مدل رو روی یک داده‌ی یکسان مقایسه کردم. بر اساس دقت:
- اول، E5 Base با Logistic Regression: ۸۳٫۷۹٪+
- دوم، TF-IDF با Logistic Regression: ۸۲٫۴۸٪+
- سوم، Decider-2B: ۸۱٫۶۴٪
- بعد، E5 Small: ۸۰٫۹۰٪
- بعد، Jev 1.13: ۷۹٫۸۶٪
- بعد، Decider-0.8B: ۷۶٫۷۷٪
- آخر، Kev-0.8B: ۵۷٫۹۵٪
یعنی یک مدل امبدینگ ۲۷۸ میلیونی از مدل‌های تخصصی تصمیم‌گیری جلوتر افتاد، و TF-IDF هم هنوز از Jev و Decider دقیق‌تر بود.
حالا راز E5 چیه؟ از مدل چندزبانه‌ی E5 استفاده کردم تا متن رو به بردارهای ۷۶۸بعدی تبدیل کنه و فقط یک Logistic Regression ساده روی خروجی‌اش آموزش دادم. هیچ‌کدوم از پارامترهای E5 رو دوباره آموزش ندادم.
ولی یک نکته‌ای هست که نباید از قلم بیفته: من برای E5 و TF-IDF از بیش از ۲۳ هزار نمونه‌ی آموزشی برچسب‌دار استفاده کردم، درحالی‌که Jev و Decider بدون آموزش و به‌صورت Zero-shot ارزیابی شدن. پس این نتایج ثابت نمی‌کنه E5 یک موتور تصمیم‌گیری عمومی قوی‌تره.
از Jev یک نتیجه‌ی غیرمنتظره هم درآمد. اگر به‌جای Accuracy از Macro-F1 استفاده کنیم، مقایسه برعکس می‌شه: Jev به ۷۷٫۳۲٪ می‌رسه و Decider-2B به ۷۶٫۲۵٪. چون Macro-F1 به همه‌ی کلاس‌ها وزن یکسان می‌ده، یعنی Jev با وجود دقت کلی پایین‌تر، بین دسته‌های مختلف متعادل‌تر بوده.
کالیبراسیون هم داستان جداگانه‌ای داشت. خطای کالیبراسیون یا ECE برای Decider-2B حدود ۰٫۰۱۸۶، برای Jev حدود ۰٫۰۵۰۹ و برای E5 Base حدود ۰٫۲۵۷۳ دراومد. هرچه ECE کمتر باشه یعنی اطمینان پیش‌بینی‌شده به دقت واقعی نزدیک‌تره. البته ECE همه‌چیز رو نشون نمی‌ده؛ E5 با وجود خطای بالاتر، توی آزمایش من در رتبه‌بندی تصمیم‌ها بر اساس ریسک بهتر عمل کرد.
از نظر هزینه و سرعت هم، اجرای کامل Jev روی هر ۵٬۹۴۸ جمله حدود ۰٫۲۹۳ دلار شد و میانه‌ی زمان پاسخ هم حدود ۶۲۶ میلی‌ثانیه.
یک نکته‌ی دیگه هم این بود که در دو اجرای مستقل روی ۳۹۸ ورودی مشترک، حدود ۲٫۳ درصد پیش‌بینی‌های Jev تغییر کرد. یعنی نتیجه‌ی یک اجرای منفرد رو نباید خیلی قطعی گرفت.
دارم هنوز تست میکنم این مدل هارو، مرحله بعدی هدفم دیگه فقط تشخیص Intent نیست؛ می‌خوام ببینم Encoderهای کوچک و چندزبانه می‌تونن توی ۵۰ کاربرد مختلف، از انتخاب ابزار و کنترل Agent تا ارزیابی RAG و تصمیم‌گیری چندمرحله‌ای، با مدل‌های تصمیم گیری تخصصی مث Jev رقابت کنن یا نه.
درسی که خودم از این آزمایش گرفتم اینه: برای حل یک مسئله‌ی مشخص، همیشه مدل بزرگ‌تر لازم نیست. یک Encoder ازپیش‌آموزش‌دیده کنار یک الگوریتم کلاسیک می‌تونه نتیجه‌ی چشمگیری بده. ولی تشخیص یک دسته‌ی ازپیش‌تعریف‌شده با تصمیم‌گیری درباره‌ی مسئله‌ای کاملاً جدید، دو تا مسئله‌ی متفاوتن.
🛠 Join @LLMEngineers Community | 1 352 |
| 3 | امروز Jev 1.13 رو از طریق API رسمی OpenRouter آزمایش کردم، و نتیجه‌اش بیشتر از چیزی که انتظار داشتم جالب بود.
روی دیتاست MASSIVE با ۵٬۹۴۸ جمله‌ی فارسی و انگلیسی و ۶۰ نوع Intent، چهارده مدل رو روی یک داده‌ی یکسان مقایسه کردم. بر اساس دقت:
- اول، E5 Base با Logistic Regression: ۸۳٫۷۹٪+
- دوم، TF-IDF با Logistic Regression: ۸۲٫۴۸٪+
- سوم، Decider-2B: ۸۱٫۶۴٪
- بعد، E5 Small: ۸۰٫۹۰٪
- بعد، Jev 1.13: ۷۹٫۸۶٪
- بعد، Decider-0.8B: ۷۶٫۷۷٪
- آخر، Kev-0.8B: ۵۷٫۹۵٪
یعنی یک مدل امبدینگ ۲۷۸ میلیونی از مدل‌های تخصصی تصمیم‌گیری جلوتر افتاد، و TF-IDF هم هنوز از Jev و Decider دقیق‌تر بود.
حالا راز E5 چیه؟ از مدل چندزبانه‌ی E5 استفاده کردم تا متن رو به بردارهای ۷۶۸بعدی تبدیل کنه و فقط یک Logistic Regression ساده روی خروجی‌اش آموزش دادم. هیچ‌کدوم از پارامترهای E5 رو دوباره آموزش ندادم.
ولی یک نکته‌ای هست که نباید از قلم بیفته: من برای E5 و TF-IDF از بیش از ۲۳ هزار نمونه‌ی آموزشی برچسب‌دار استفاده کردم، درحالی‌که Jev و Decider بدون آموزش و به‌صورت Zero-shot ارزیابی شدن. پس این نتایج ثابت نمی‌کنه E5 یک موتور تصمیم‌گیری عمومی قوی‌تره.
از Jev یک نتیجه‌ی غیرمنتظره هم درآمد. اگر به‌جای Accuracy از Macro-F1 استفاده کنیم، مقایسه برعکس می‌شه: Jev به ۷۷٫۳۲٪ می‌رسه و Decider-2B به ۷۶٫۲۵٪. چون Macro-F1 به همه‌ی کلاس‌ها وزن یکسان می‌ده، یعنی Jev با وجود دقت کلی پایین‌تر، بین دسته‌های مختلف متعادل‌تر بوده.
کالیبراسیون هم داستان جداگانه‌ای داشت. خطای کالیبراسیون یا ECE برای Decider-2B حدود ۰٫۰۱۸۶، برای Jev حدود ۰٫۰۵۰۹ و برای E5 Base حدود ۰٫۲۵۷۳ دراومد. هرچه ECE کمتر باشه یعنی اطمینان پیش‌بینی‌شده به دقت واقعی نزدیک‌تره. البته ECE همه‌چیز رو نشون نمی‌ده؛ E5 با وجود خطای بالاتر، توی آزمایش من در رتبه‌بندی تصمیم‌ها بر اساس ریسک بهتر عمل کرد.
از نظر هزینه و سرعت هم، اجرای کامل Jev روی هر ۵٬۹۴۸ جمله حدود ۰٫۲۹۳ دلار شد و میانه‌ی زمان پاسخ هم حدود ۶۲۶ میلی‌ثانیه.
یک نکته‌ی دیگه هم این بود که در دو اجرای مستقل روی ۳۹۸ ورودی مشترک، حدود ۲٫۳ درصد پیش‌بینی‌های Jev تغییر کرد. یعنی نتیجه‌ی یک اجرای منفرد رو نباید خیلی قطعی گرفت.
دارم هنوز تست میکنم این مدل هارو، مرحله بعدی هدفم دیگه فقط تشخیص Intent نیست؛ می‌خوام ببینم Encoderهای کوچک و چندزبانه می‌تونن توی ۵۰ کاربرد مختلف، از انتخاب ابزار و کنترل Agent تا ارزیابی RAG و تصمیم‌گیری چندمرحله‌ای، با مدل‌های تصمیم گیری تخصصی مث Jev رقابت کنن یا نه.
درسی که خودم از این آزمایش گرفتم اینه: برای حل یک مسئله‌ی مشخص، همیشه مدل بزرگ‌تر لازم نیست. یک Encoder ازپیش‌آموزش‌دیده کنار یک الگوریتم کلاسیک می‌تونه نتیجه‌ی چشمگیری بده. ولی تشخیص یک دسته‌ی ازپیش‌تعریف‌شده با تصمیم‌گیری درباره‌ی مسئله‌ای کاملاً جدید، دو تا مسئله‌ی متفاوتن.
🛠 Join @LLMEngineers Community | 1 |
| 4 |  بدون متن... | 4 436 |
| 5 |  5 تا مدل خفن ریلیز شده تو دو سه روز!
- Opus 5.5
- GPT 6 Sol
- GPT 6 Luna
- Grok 4.7
- Mimo 2.6 | 4 360 |
| 6 |  نکته جالب انگیزش اینه
از پنج شیش روز پیش به صورت لایو مرحله ترین RL اش گذاشته بودن ، پابلیک مانیتور بشه | 1 |
| 7 |  امتیاز بنچمارک های ورژن پرو و فلش MiMo-V2.6 | 1 694 |
| 8 |  بدون متن... | 1 462 |
| 9 | چیزی که توی موج Open Sourceهای Jev جالبه اینه که بیشتر پروژه‌ها اصلاً سعی نکردن معماری جدیدی از صفر بسازن؛ رفتن سراغ یه LLM آماده و فقط روش خروجی تصمیم‌گیری ساختن. یعنی به‌جای اینکه Qwen یا Gemma متن تولید کنه، مستقیم احتمال گزینه‌ها از داخل مدل خونده می‌شه.
مثلاً SemIf از Qwen3.5-4B استفاده می‌کنه، system-one-open روی Gemma ساخته شده و OpenJev سراغ DiffusionGemma رفته. مزیت این مسیر واضحه: دانش و درک زبانی LLM رو تقریباً آماده تحویل می‌گیری. توی JevBench v1.2 هم SemIf با امتیاز 74.6 تقریباً کنار خود Jev با 75.3 قرار گرفته.
اما یه مسیر متفاوت هم شکل گرفته: کلاً LLM مولد رو حذف کن و یه encoder کوچیک رو مخصوص تصمیم‌گیری آموزش بده. open-jev-deberta-v3-large با DeBERTa همین کار رو کرده و Laya هم با ModernBERT-large + یه decision head اختصاصی جلو رفته.
نکته اینجاست که این مدل‌ها دیگه متن تولید نمی‌کنن؛ ورودی رو می‌خونن و مستقیم می‌گن احتمال هر گزینه چقدره. نتیجه معمولاً مدل خیلی کوچیک‌تر، latency کمتر و serving ارزون‌تره. Laya مثلاً فقط 421M پارامتر داره و برای routing، moderation، Support و تصمیم‌های پرتکرار طراحی شده.
ولی هزینه این سبک هم مشخصه: LLMهایی مثل SemIf روی سؤال‌ها و دسته‌بندی‌های جدید معمولاً بهتر generalize می‌کنن، چون پشتشون یه مدل زبانی 4B با دانش عمومی نشسته. encoderهایی مثل Laya و DeBERTa وقتی وارد domain جدید میشن، بیشتر به fine-tuning و داده واقعی همون کسب‌وکار احتیاج دارن.
برای من دو مسیر کاملاً جدا شده: اگر یه decision engine عمومی می‌خوای که امروز CRM باشه و فردا Agent Routing و یه روز دیگه چیز جدید، مسیر SemIf منطقی‌تره. ولی اگر میلیون‌ها تصمیم تکراری و مشخص مثل Support routing، Lead Scoring، Moderation داری، مسیر Laya خیلی جذاب‌تره؛ یه مدل کوچیک که فقط همون کار رو خوب انجام بده، نه یه LLM کامل که برای هر تصمیم کوچیک بیدارش کنیم.
🛠 Join @LLMEngineers Community | 1 687 |
| 10 |  پروژه های Open Source جایگزین Jev کم کم دارن پدیدار میشن | 1 397 |
| 11 | پروژه های Open Source جای | 1 |
| 12 | بدون متن... | 46 |
| 13 | امروز داشتم چندتا پروژه‌ای که ادعا می‌کنن نسخه Open Source از ایده Jev هستن رو مقایسه می‌کردم. خیلی‌هاشون در عمل فقط یه classifier ساده‌ان، ولی این سه‌تا فعلاً از بقیه جدی‌ترن:
• اول **system-one-open**؛ به نظرم متعادل‌ترین گزینه‌ست. روی Gemma 4 E2B ساخته شده، API و کد آموزش و Evals داره و توی JevBench به امتیاز حدود 93.8 رسیده؛ خود Jev حدود 97.8 بوده. برای کسی که می‌خواد واقعاً self-host کنه و بعداً روی داده خودش Fine-tune انجام بده، فعلاً انتخاب منطقی‌تریه.
• دوم **openjev-sglang**؛ از نظر دقت خام قوی‌تره و روی JevBench حدود 97 گرفته، یعنی خیلی نزدیک به Jev. پشتش Qwen3.6-35B-A3B هست و API سازگار با مدل تصمیم‌گیری Jev هم داره. مشکلش اینه که سبک نیست؛ سخت‌افزار قوی می‌خواد و probabilityهایی که می‌ده لزوماً calibration واقعی ندارن.
• سوم **decider**؛ یه گزینه خیلی جالب برای استارتاپ‌هاست چون فقط 2B پارامتر داره و واقعاً برای تصمیم‌گیری یک‌مرحله‌ای Fine-tune شده. روی تست‌های منتشرشده حدود 81٪ دقت روی taskهای دیده‌شده و 74٪ روی taskهای جدید گرفته و نسبت به مدل پایه Qwen3.5-2B پیشرفت واضحی داشته. برای CRM، Support، Lead Scoring، Agent Routing و کارهای پرتعداد و کم‌هزینه، خیلی قابل‌بررسیه.
نکته مهم اینه که این سه‌تا دقیقاً یه چیز نیستن:
system-one-open → بهترین تعادل بین دقت، بازبودن و قابلیت توسعه
openjev-sglang → بیشترین دقت، ولی سنگین‌تر و گرون‌تر برای اجرا
decider → سبک‌تر و مناسب‌تر برای self-host و حجم بالا
برای production هم من مستقیم به benchmark عمومی اعتماد نمی‌کنم. بهتره روی داده واقعی خودتون یه Eval بسازید؛ مثلاً تشخیص Lead خوب، انتخاب کمپین، دسته‌بندی تیکت، churn signal یا انتخاب Tool. اونجا خیلی سریع مشخص می‌شه کدوم مدل واقعاً به درد بیزنس شما می‌خوره.
https://www.benchmarkheaven.com/jev-models
🛠 Join @LLMEngineers Community | 1 |
| 14 | دقت کنید، Jev را جایگزین GPT یا Claude نبینید؛ Jev بیشتر یک موتور تصمیم‌گیری سریع و ارزان است.
یعنی به‌جای اینکه برای هر کار کوچک یک LLM را صدا بزنید، Jev می‌تواند بین چند گزینه مشخص تصمیم بگیرد: این درخواست به کدام بخش برود؟ این مشتری مهم است؟ این محتوا مشکوک است؟ کدام ابزار اجرا شود؟
تقسیم درست کار تقریباً این شکلی است:
Jev → تصمیم‌های کوچک و پرتعداد
LLM → تحلیل، استدلال و تولید محتوا
Code → قوانین قطعی، محاسبات و تصمیم‌های حساس
محدودیت مهم Jev این است که در کارهای محدود و شفاف می‌تواند خیلی خوب باشد، اما اگر مسئله مبهم، چندمرحله‌ای یا حساس باشد، میزان خطا بالا می‌رود. در یک آزمایش استفاده از مرورگر BrowserUse وقتی فقط باید بین چند ابزار مشخص انتخاب می‌کرد، سیستم 49 از 49 کار را انجام داد؛ اما وقتی آزادی عمل بیشتری داشت، نتیجه به 25 از 49 افت کرد.
کاربردهای بالقوه‌اش خیلی زیادi:
* مدیریت مشتری: تشخیص مشتری مهم، احتمال ریزش، نوع درخواست و اولویت پیگیری
* پشتیبانی: دسته‌بندی پیام‌ها، تشخیص فوریت و ارجاع خودکار به تیم مناسب
* ارزیابی سرنخ فروش: مشخص‌کردن اینکه کدام مشتری بالقوه ارزش تماس فوری دارد
* مسیریابی عامل‌های هوش مصنوعی: انتخاب اینکه کدام عامل، ابزار یا مدل باید کار را انجام دهد
* نظارت محتوا: تشخیص محتوای مشکوک، نامناسب یا نیازمند بررسی انسانی
* سامانه‌های جستجو و بازیابی اطلاعات: انتخاب اسناد مرتبط‌تر قبل از ارسال به مدل اصلی
* کنترل کیفیت: بررسی پاسخ‌های هوش مصنوعی و پیدا کردن موارد ضعیف یا مشکوک
* خودکارسازی مرورگر: انتخاب حرکت بعدی مثل کلیک، جستجو یا بازکردن صفحه
* خودکارسازی فرایندها: تصمیم‌گیری بین مراحل مختلف یک فرایند بدون صدا زدن مدل بزرگ در هر مرحله
* باشگاه مشتریان: تشخیص اینکه چه پیشنهاد، تخفیف یا پیام وفاداری برای هر مشتری مناسب‌تر است
* کمپین‌های بازاریابی: دسته‌بندی مخاطبان، انتخاب پیام مناسب، اولویت‌بندی لیدها و بررسی کیفیت محتوا
مدل معماری خوب می‌تواند این باشد:
تصمیم ساده → Jev
تصمیم سخت → LLM
تصمیم پرریسک → انسان | 2 653 |
| 15 |  بدون متن... | 1 |
| 16 | امروز داشتم معرفی Jev از TypeSafe AI رو می‌خوندم و ایده‌ش جالبه: به‌جای ساختن یه LLM بهتر برای تولید متن، یه مدل ساختن که مستقیم برای تصمیم‌گیری داخل نرم‌افزار طراحی شده.
اصل مسئله‌شون اینه که LLMها برای chat عالی‌ان، ولی توی automation هنوز دردسر دارن: خروجی stringـه، باید parse و validate بشه، latency بالاست و confidence هم همیشه قابل اعتماد نیست.
مدل Jev از یه دسته‌ی جدید به اسم System One Modelsـه. ورودی می‌تونه متن یا state نامرتب باشه، ولی خروجی از قبل type مشخص داره: مثلاً یه category، score، boolean یا چند probability. یعنی مدل قرار نیست چند پاراگراف تولید کنه؛ مستقیم یه تصمیم ساختاریافته تحویل می‌ده.
برای آموزش هم یه روش به اسم RLCD معرفی کردن؛ Reinforcement Learning for Calibrated Decisions. هدف اینه که probabilityهای مدل واقعاً معنی‌دار باشن. یعنی وقتی می‌گه ۹۰٪ مطمئنم، انتظار داری تقریباً در ۹۰٪ موارد مشابه درست باشه.
یه تفاوت مهم دیگه parallel samplingـه. LLM معمولی (autoregressive) توکن به توکن خروجی می‌سازه، ولی Jev چون text generation نداره می‌تونه چند تصمیم رو در یه query با هم تولید کنه. برای چیزهایی مثل scoring، routing، classification و تصمیم‌های real-time این می‌تونه خیلی مهم باشه.
کمپانی TypeSafe ادعا می‌کنه Jev روی System One taskها intelligence مشابه بعضی مدل‌های frontier داره، ولی حدود 40x تا 200x سریع‌تره و latency حدود 70 تا 500 میلی‌ثانیه داره. قیمت input هم $0.042 برای هر یک میلیون توکن اعلام شده.
یه ادعای مهم دیگه هم «no type errors»ـه. چون خروجی از قبل schema مشخص داره، مدل نمی‌تونه یه value خارج از ساختار تعریف‌شده تحویل بده. ولی این رو نباید با «هیچ‌وقت اشتباه نمی‌کنه» قاطی کرد؛ ممکنه خروجی کاملاً type-safe باشه ولی تصمیمش غلط باشه.
https://typesafe.ai/blog/introducing-system-one-models-and-jev
🛠 Join @LLMEngineers Community | 1 589 |
| 17 | روند بکارگیری یادگیری تقویتی (RL) در بهبود عملکرد مدل‌های زبانی (LLMs) :
https://telegra.ph/RL-in-LLMs-09-14 | 1 679 |
| 18 |  مدل ۳.۷ میلیارد پارامتری K2 Horizon تو بنچمارک Artificial Analysis امتیاز ۱۶ گرفته. این عدد برای یه مدل زیر ۴ میلیارد پارامتر واقعاً بالاست و از بیشتر مدل‌های هم‌اندازه‌ش جلوتره.
علت اصلیش اینه که روی حجم خیلی بزرگی از داده (حدود ۲۰ تریلیون توکن) ترین شده و بخش زیادی از این داده‌ها مثال‌های حل مسئله و استدلال بودن. بعدش هم چند مرحله‌ی بعد از ترین اصلی روش کار کردن؛ از جمله یادگیری تقویتی مخصوص کار با ابزار و تسک‌های چندمرحله‌ای. نتیجه‌ش شده مدلی که تو کدنویسی، استدلال و کار با ابزار از چیزی که معمولاً از این سایز انتظار می‌ره خیلی بهتر عمل می‌کنه.
نکته‌ی مهم‌تر اینه که این مدل واقعاً اوپن‌سورسه، نه فقط وزن‌هاش. تیم سازنده داده‌ها یا دستور ساخت داده، کد ترینینگ، چک‌پوینت‌های میانی و همه‌چیز رو هم منتشر کرده.
https://ifm.ai/blog/k2/
https://huggingface.co/IFM/K2-Horizon-3.7B
🛠 Join @LLMEngineers Community | 1 727 |
| 19 |  هر بار که Coding Agent یک فایل یا log بزرگ می‌خونه، معمولاً کل خروجی در هر model call دوباره به context فرستاده می‌شه. نتیجه؟ tokenهای تکراری و هزینه‌ی اضافه.
مکانیزم ObservationPack در SoL-Pi بعد از چند بار ارسال کامل، خروجی رو به یک placeholder کوتاه تبدیل می‌کنه و نسخه‌ی اصلی رو به‌صورت local archive نگه می‌داره. هر وقت مدل دوباره به بخشی از آن نیاز داشته باشه، با obs_recall دقیقاً همان قسمت را برمی‌گردونه.
عددهای زرد تصویر، tokenهایی هستن که با همین کار دوباره ارسال نشدن؛ مثلاً ۲٬۸۳۵ یا ۶٬۴۵۷ token.
یعنی context حذف نشده؛ فقط مجبور نیستیم هر بار کل فایل رو دوباره بفرستیم.
🛠 Join @LLMEngineers Community | 1 672 |
| 20 | سه پروژه‌ی Pi و SoL-Pi و mini-swe-agent از سه مسیر متفاوت دنبال یک هدفن: کم‌کردن token مصرفی Coding Agent، بدون اینکه کارایی واقعی قربانی بشه.
پروژه‌ی Pi یک harness مینیمال و قابل‌گسترشه. ابزارهای پایه مثل خواندن و نوشتن فایل، جست‌وجو و اجرای shell commandها رو می‌ده، ولی planning، subagent و رفتارهای پیچیده‌تر رو به core تحمیل نمی‌کنه. این قابلیت‌ها رو می‌شه با Extension، Skill و Package اضافه کرد.
نکته‌ی مهم‌تر، مدیریت state و context در Piه. Sessionها به شکل JSONL ذخیره میشن، history ساختار درختی داره و با id و parentId می‌شه از یک نقطه branch گرفت. وقتی context بزرگ می‌شه، بخش‌های قدیمی‌تر compact میشن و برای پاسخ بعدی فضا باقی می‌مونه.
پروژه‌ی SoL-Pi ساخت Nvidia هست و به عنوان extension روی Pi ساخته شده و تمرکزش روی ارزmن‌ترکردن trajectoryهای طولانیه. چند ایده‌ی اصلی‌اش این‌ها هستن:
ایده‌ی Action Fusion: بعد از edit، تست یا command قابل‌پیش‌بینی رو بدون یک model call اضافه اجرا می‌کنه.
ایده‌ی ObservationPack: logهای بزرگ رو در archive محلی نگه می‌داره و هر بار کل‌شون رو دوباره به مدل نمی‌فرسته.
ایده‌ی Online Context Compact: history رو در مرزهای منطقی subtask compact می‌کنه، نه فقط وقتی context تقریباً پر شده.
ایده‌ی Evidence-Preserving Reducer: لاگ های طولانی رو با یک مدل ارزان‌تر بررسی می‌کنه، ولی evidence استخراج‌شده رو با log اصلی تطبیق می‌ده.
نتیجه‌ی EdgeBench جالبه: SoL-Pi حدود ۹۴٪ امتیاز میانگین Pi رو حفظ کرده، با ۴۵ تا ۴۹٪ token کمتر.
پروژه‌ی mini-swe-agent از مسیر مخالف می‌ره: کم‌کردن abstraction تا جای ممکن. Agent اصلی تقریباً یک loop سادس. پیام رو به مدل می‌ده، command پیشنهادی رو اجرا می‌کنه، observation رو به history اضافه می‌کنه و دوباره ادامه می‌ده.
قابلیت اصلی اینجا عملاً bashه. مدل با کامند های معمولی repository رو می‌خونه، فایل تغییر می‌ده، تست اجرا می‌کنه و Git رو صدا می‌زنه. خبری از یک مجموعه‌ی بزرگ ابزارهای اختصاصی برای navigation و editing نیست.
تاریخچه در mini-swe-agent عمدتاً linearه. این طراحی شاید از session treeهای Pi ساده‌تر باشه، ولی برای debugging، Evals، fine-tuning و RL مزیت مهمی داره: trajectory راحت‌تر بررسی می‌شه و رفتار پنهان کمتری بین مدل و environment قرار می‌گیره.
خلاصه‌اش اینه:
گزینه‌ی اول، Pi: وقتی harness قابل‌برنامه‌ریزی و session management می‌خوای.
گزینه‌ی دوم، SoL-Pi: وقتی می‌خوای context، observation و model callهای اضافه رو در Pi کم کنی.
گزینه‌ی سوم، mini-swe-agent: وقتی سادگی، observability و یک مسیر مستقیم تا shell برات مهم‌تره.
مسیر این سه پروژه فرق داره، ولی سؤال یکیه: از چه نقطه‌ای به بعد، هر feature جدید فقط token، latency و پیچیدگی اضافه می‌کنه؟
🛠 Join @LLMEngineers Community | 1 486 |
