واقعیت اینه که توی دنیای Agentها، مدل فقط حکم موتور رو داره؛ اون چیزی که واقعاً محصول نهایی رو می‌سازه Harness یا همون اسکلت‌بندی دور مدله. مثلا Claude 4.5 روی یه بنچمارک با یه Harness مشخص ۴۲٪ می‌گیره و با یه معماری دیگه به ۷۸٪ می‌رسه، بدون اینکه خود مدل ذره‌ای تغییری کرده باشه.
بزرگترین اشتباه اینه که فکر کنیم هرچی ابزار و Context بیشتری به مدل بدیم باهوش‌تر عمل می‌کنه. برعکس، تجربه‌ی تیم‌های موفقی مثل Cursor و Anthropic نشون میده که الگوهایی مثل Progressive Disclosure (نمایش تدریجی اطلاعات) چقدر حیاتی‌ان. یعنی به جای خفه کردن مدل با حجم عظیمی از دیتا، باید اطلاعات رو فقط وقتی که واقعاً لازم شد و به‌صورت لایه‌ای به خوردش داد تا دچار Attention fragmentation نشه.
توی سیستم‌هایی مثل Claude Code، تمرکز روی سادگی لوپ و استفاده از ابزارهای ساده (مثل Grep و Bash) به جای پکیج‌های سنگین و انتزاعی، هم هزینه‌ی Token رو پایین آورده و هم دقت رو بالا برده. مدل‌ها دارن به سمت "جایگزین‌پذیر" شدن می‌رن و فرق محصولی که واقعاً کار می‌کنه با یه دموی جذاب، توی همون مهندسی ظریفیه که دور مدل چیده شده.
Source: https://x.com/himanshutwtxs/article/2028116431876116660
🛠 Join @LLMEngineers Community
بزرگترین اشتباه اینه که فکر کنیم هرچی ابزار و Context بیشتری به مدل بدیم باهوش‌تر عمل می‌کنه. برعکس، تجربه‌ی تیم‌های موفقی مثل Cursor و Anthropic نشون میده که الگوهایی مثل Progressive Disclosure (نمایش تدریجی اطلاعات) چقدر حیاتی‌ان. یعنی به جای خفه کردن مدل با حجم عظیمی از دیتا، باید اطلاعات رو فقط وقتی که واقعاً لازم شد و به‌صورت لایه‌ای به خوردش داد تا دچار Attention fragmentation نشه.
توی سیستم‌هایی مثل Claude Code، تمرکز روی سادگی لوپ و استفاده از ابزارهای ساده (مثل Grep و Bash) به جای پکیج‌های سنگین و انتزاعی، هم هزینه‌ی Token رو پایین آورده و هم دقت رو بالا برده. مدل‌ها دارن به سمت "جایگزین‌پذیر" شدن می‌رن و فرق محصولی که واقعاً کار می‌کنه با یه دموی جذاب، توی همون مهندسی ظریفیه که دور مدل چیده شده.
Source: https://x.com/himanshutwtxs/article/2028116431876116660
🛠 Join @LLMEngineers Community
👌10❤3🔥2
AI_Engineering_Building_Applications_with_Foundation_Models_Chip.pdf
31.9 MB
کتاب AI Engineering چیپ هوین رو نباید به چشم یه آموزش برنامه‌نویسی دید؛ این کتاب بیشتر شبیه یه نقشه راه برای فرار از دوران" دمو" ساختن هاست. اگه پروژه‌هاتون توی MVP خوب کار می‌کنن ولی توی Production وا می‌رن، مشکلتون احتمالاً کد نیست، بلکه System Design هست.
بیشترین نقدی که به کتاب میشه اینه که کد کمه و تئوری زیاده، ولی به نظرم این بزرگترین نقطه قوت کتابه. کدها و فریم‌ورک‌ها چند ماهه دِمُدِه می‌شن، اما چیزی که کتاب روش دست گذاشته یعنی طراحی Eval، مدیریت Latency و بالانس بین RAG و Fine-tuning، همون نقطه قوته که یه AI Engineer واقعی رو از بقیه جدا می‌کنه. در واقع کتاب به جای ماهی دادن، داره ماهیگبری یاد میده : چطور یه سیستم بسازیم که وقتی مدل عوض شد یا فریم‌ورک جدید اومد، کل معماری‌مون نپاشه.
بیشترین نقدی که به کتاب میشه اینه که کد کمه و تئوری زیاده، ولی به نظرم این بزرگترین نقطه قوت کتابه. کدها و فریم‌ورک‌ها چند ماهه دِمُدِه می‌شن، اما چیزی که کتاب روش دست گذاشته یعنی طراحی Eval، مدیریت Latency و بالانس بین RAG و Fine-tuning، همون نقطه قوته که یه AI Engineer واقعی رو از بقیه جدا می‌کنه. در واقع کتاب به جای ماهی دادن، داره ماهیگبری یاد میده : چطور یه سیستم بسازیم که وقتی مدل عوض شد یا فریم‌ورک جدید اومد، کل معماری‌مون نپاشه.
❤18👍1
رقابت توی مدل‌های امبدینگ زیر ۳۰۰ میلیون پارامتر خیلی جذاب شده. با اینکه گوگل با EmbeddingGemma-300m سر و صدای زیادی کرد، ولی جینا با مدل V5 Nano نشون داد که توی Production برنده کیه.
چند تا دلیل فنی که چرا جینا برای کارهای عملیاتی و RAG بهتره:
کانتکست ۸ هزارتایی در مقابل ۲ هزارتای گوگل، دست آدم رو برای پردازش داکیومنت‌های طولانی و … می‌ذاره.
استفاده از LoRA adapterهای اختصاصی برای تسک‌های مختلف مثل retrieval یا classification باعث میشه دقت خروجی توی سناریوهای واقعی خیلی بالاتر از یه مدل عمومی باشه.
قابلیت Binary Quantization جینا هم حجم ایندکس‌های دیتابیس رو به شدت میاره پایین بدون اینکه افت کیفیت محسوسی داشته باشیم. برای کسی که دنبال پرفورمنس بالا با هزینه inference و نگهداری کمه، این مدل جینا فعلاً بهترین گزینه‌ست.
https://huggingface.co/jinaai/jina-embeddings-v5-text-nano
چند تا دلیل فنی که چرا جینا برای کارهای عملیاتی و RAG بهتره:
کانتکست ۸ هزارتایی در مقابل ۲ هزارتای گوگل، دست آدم رو برای پردازش داکیومنت‌های طولانی و … می‌ذاره.
استفاده از LoRA adapterهای اختصاصی برای تسک‌های مختلف مثل retrieval یا classification باعث میشه دقت خروجی توی سناریوهای واقعی خیلی بالاتر از یه مدل عمومی باشه.
قابلیت Binary Quantization جینا هم حجم ایندکس‌های دیتابیس رو به شدت میاره پایین بدون اینکه افت کیفیت محسوسی داشته باشیم. برای کسی که دنبال پرفورمنس بالا با هزینه inference و نگهداری کمه، این مدل جینا فعلاً بهترین گزینه‌ست.
https://huggingface.co/jinaai/jina-embeddings-v5-text-nano
👍8❤4
امروز یه پست توی توییتر یکی از مهندسای Baseten خوندم درباره اینکه چطوری سریع‌ترین API رو برای GLM-5.2 ساختن. اعداد Baseten و تکنیک‌هایی که پیاده کردن واقعاً جای بررسی داره.
کوانتیزاسیون NVFP4 روی گرافیک‌های Blackwell کلید اصلی‌شون بوده. با NVIDIA ModelOpt اومدن مدل رو از FP8 آوردن روی ۴ بیت. نکته فنی‌ش این dual scale factor هاست که اجازه میده dynamic range حفظ بشه. من خودم همیشه توی پروژه‌ها نگران افت کیفیت مدل توی کارهای agentic بودم، اما تست‌های اینا روی بنچمارک BFCL نشون میده دقت تقریباً ثابت مونده... یعنی عملاً VRAM کمتر مصرف میشه و سرعت میره بالا بدون اینکه مدل خنگ بشه.
تفکیک فازهای Prefill و Decode یا همون PD Disaggregation بیشترین تاثیر رو توی TPS داشته. توزیع بار و نیازهای سخت‌افزاری بین این دو تا فاز کاملاً متفاوته؛ اولی compute-bound هست و دومی memory-bound. وقتی اینا رو روی انجین‌های جداگونه با کانفیگ‌های متفاوت اجرا کردن، ۲ برابر پرفورمنس بهتر گرفتن. به نظرم ما هم تو زیرساخت‌های سنگین باید به این سمت بریم، چون توی contextهای بالا، تداخل این دو تا فاز latency رو داغون می‌کنه.
سیستم KV-aware routing با استفاده از ابزارهای NVIDIA Dynamo هم برای کم کردن TTFT عالی عمل کرده. وقتی مدل ۱ میلیون توکن context window داره، کش کردن پرفیکس‌ها و فرستادن هوشمند درخواست به رپلیکایی که قبلاً اون دیتا رو پردازش کرده، واجبه. مخصوصاً برای agentهایی که هیستوری طولانی دارن و مدام دارن روی یه کانتکست مشترک کار می‌کنن.
استفاده از Multi-Token Prediction برای speculation هم تیر آخر بوده. تولید چند توکن در هر forward pass که با لایه‌های MTP خودِ GLM بهینه‌تر شده و نرخ تایید توکن‌های درفت رو بالا برده. به نظرم معماری GLM-5.2 و این ستاپ اینفرنس نشون میده که دیگه دوران استک‌های ساده اینفرنس تموم شده. اگه می‌خوایم توی اسکیل بالا و هزینه پایین کار کنیم، باید سراغ disaggregated inference و کوانتیزاسیون‌های نیتیوِ Blackwell بریم.
🛠 Join @LLMEngineers Community
کوانتیزاسیون NVFP4 روی گرافیک‌های Blackwell کلید اصلی‌شون بوده. با NVIDIA ModelOpt اومدن مدل رو از FP8 آوردن روی ۴ بیت. نکته فنی‌ش این dual scale factor هاست که اجازه میده dynamic range حفظ بشه. من خودم همیشه توی پروژه‌ها نگران افت کیفیت مدل توی کارهای agentic بودم، اما تست‌های اینا روی بنچمارک BFCL نشون میده دقت تقریباً ثابت مونده... یعنی عملاً VRAM کمتر مصرف میشه و سرعت میره بالا بدون اینکه مدل خنگ بشه.
تفکیک فازهای Prefill و Decode یا همون PD Disaggregation بیشترین تاثیر رو توی TPS داشته. توزیع بار و نیازهای سخت‌افزاری بین این دو تا فاز کاملاً متفاوته؛ اولی compute-bound هست و دومی memory-bound. وقتی اینا رو روی انجین‌های جداگونه با کانفیگ‌های متفاوت اجرا کردن، ۲ برابر پرفورمنس بهتر گرفتن. به نظرم ما هم تو زیرساخت‌های سنگین باید به این سمت بریم، چون توی contextهای بالا، تداخل این دو تا فاز latency رو داغون می‌کنه.
سیستم KV-aware routing با استفاده از ابزارهای NVIDIA Dynamo هم برای کم کردن TTFT عالی عمل کرده. وقتی مدل ۱ میلیون توکن context window داره، کش کردن پرفیکس‌ها و فرستادن هوشمند درخواست به رپلیکایی که قبلاً اون دیتا رو پردازش کرده، واجبه. مخصوصاً برای agentهایی که هیستوری طولانی دارن و مدام دارن روی یه کانتکست مشترک کار می‌کنن.
استفاده از Multi-Token Prediction برای speculation هم تیر آخر بوده. تولید چند توکن در هر forward pass که با لایه‌های MTP خودِ GLM بهینه‌تر شده و نرخ تایید توکن‌های درفت رو بالا برده. به نظرم معماری GLM-5.2 و این ستاپ اینفرنس نشون میده که دیگه دوران استک‌های ساده اینفرنس تموم شده. اگه می‌خوایم توی اسکیل بالا و هزینه پایین کار کنیم، باید سراغ disaggregated inference و کوانتیزاسیون‌های نیتیوِ Blackwell بریم.
🛠 Join @LLMEngineers Community
❤10
امروز داشتم گزارش فنی جدید Baidu رو ورق می‌زدم که کلاً دیدم رو نسبت به هندل کردن داکیومنت‌های طولانی عوض کرد. اسمش رو گذاشتن Unlimited OCR و برخلاف مدل‌های فعلی که برای پردازش چند صفحه پشت‌سرهم لنگ میزنن، این یکی خیلی خوب عمل می‌کنه.
مشکل چیه؟ مدل‌های خفن مثل DeepSeek OCR از LLM برای دیکود کردن استفاده می‌کنن. هر چی متن طولانی‌تر بشه، KV Cache بزرگتر میشه، رم رو می‌بلعه و سرعت تولید توکن (TPS) میاد پایین. به خاطر همین همیشه مجبوریم داکیومنت رو صفحه به صفحه بدیم به مدل که باعث میشه زمینه (Context) از دست بره.
بایدو اومده یه حرکت هوشمندانه زده و Reference Sliding Window Attention یا همون R-SWA رو معرفی کرده. ایده‌اش اینه: هر توکنی که داره تولید میشه، به «تمام» توکن‌های تصویری (Reference Tokens) دسترسی داره ولی فقط به «یه پنجره محدود» (مثلاً ۱۲۸ تا) از توکن‌های متنی قبلی نگاه می‌کنه. دقیقاً مثل وقتی که داریم از روی یک کتاب مشق می‌نویسیم؛ کل صفحه جلو چشممونه ولی فقط چند کلمه آخری که نوشتیم رو تو ذهنمون نگه می‌داریم که یادمون نره کجاییم.
توی این معماری، برخلاف MHA معمولی که مصرف حافظه‌اش خطی بالا میره، اینجا KV Cache کاملاً ثابته. یعنی چه صفحه اول باشی چه صفحه چهلم، سرعت و مصرف گرافیک فرقی نمی‌کنه. با همون Context Window معمول ۳۲ هزارتایی، تونستن ده‌ها صفحه رو توی یک Forward Pass پردازش کنن که برای پروژه‌های آرشیو و پردازش کتاب یه نعمته.
به نظر من جذاب‌ترین بخشش اینه که دقتش نه تنها کم نشده، بلکه توی بنچمارک OmniDocBench از خودِ DeepSeek هم جلو زده (حدود ۹۳ درصد). این نشون میده که برای کارهای Parsing، لازم نیست مدل تمام تاریخچه متنی رو یادش باشه؛ فقط کافیه تصویر رو درست ببینه و ترتیب رو گم نکنه.
حتمالاً به زودی این تکنیک رو توی ASR و ترجمه هم می‌بینیم چون اونجا هم وابستگی به مرجع (Reference) ثابته ولی خروجی هی طولانی‌تر میشه.
🛠 Join @LLMEngineers Community
مشکل چیه؟ مدل‌های خفن مثل DeepSeek OCR از LLM برای دیکود کردن استفاده می‌کنن. هر چی متن طولانی‌تر بشه، KV Cache بزرگتر میشه، رم رو می‌بلعه و سرعت تولید توکن (TPS) میاد پایین. به خاطر همین همیشه مجبوریم داکیومنت رو صفحه به صفحه بدیم به مدل که باعث میشه زمینه (Context) از دست بره.
بایدو اومده یه حرکت هوشمندانه زده و Reference Sliding Window Attention یا همون R-SWA رو معرفی کرده. ایده‌اش اینه: هر توکنی که داره تولید میشه، به «تمام» توکن‌های تصویری (Reference Tokens) دسترسی داره ولی فقط به «یه پنجره محدود» (مثلاً ۱۲۸ تا) از توکن‌های متنی قبلی نگاه می‌کنه. دقیقاً مثل وقتی که داریم از روی یک کتاب مشق می‌نویسیم؛ کل صفحه جلو چشممونه ولی فقط چند کلمه آخری که نوشتیم رو تو ذهنمون نگه می‌داریم که یادمون نره کجاییم.
توی این معماری، برخلاف MHA معمولی که مصرف حافظه‌اش خطی بالا میره، اینجا KV Cache کاملاً ثابته. یعنی چه صفحه اول باشی چه صفحه چهلم، سرعت و مصرف گرافیک فرقی نمی‌کنه. با همون Context Window معمول ۳۲ هزارتایی، تونستن ده‌ها صفحه رو توی یک Forward Pass پردازش کنن که برای پروژه‌های آرشیو و پردازش کتاب یه نعمته.
به نظر من جذاب‌ترین بخشش اینه که دقتش نه تنها کم نشده، بلکه توی بنچمارک OmniDocBench از خودِ DeepSeek هم جلو زده (حدود ۹۳ درصد). این نشون میده که برای کارهای Parsing، لازم نیست مدل تمام تاریخچه متنی رو یادش باشه؛ فقط کافیه تصویر رو درست ببینه و ترتیب رو گم نکنه.
حتمالاً به زودی این تکنیک رو توی ASR و ترجمه هم می‌بینیم چون اونجا هم وابستگی به مرجع (Reference) ثابته ولی خروجی هی طولانی‌تر میشه.
🛠 Join @LLMEngineers Community
❤15👍6
AI Engineers
امروز داشتم گزارش فنی جدید Baidu رو ورق می‌زدم که کلاً دیدم رو نسبت به هندل کردن داکیومنت‌های طولانی عوض کرد. اسمش رو گذاشتن Unlimited OCR و برخلاف مدل‌های فعلی که برای پردازش چند صفحه پشت‌سرهم لنگ میزنن، این یکی خیلی خوب عمل می‌کنه. مشکل چیه؟ مدل‌های خفن…
This media is not supported in your browser
VIEW IN TELEGRAM
❤1
یه مقاله ترسناک امروز خوندم پشمام ریخت، به تیم اومدن ۱۱۱ میلیون رفرنس رو توی ۲.۵ میلیون مقاله بررسی کردن و دیدن از ۲۰۲۳ به این ور، آمار Citationهای فیک عجیب رفته بالا... فقط واسه سال ۲۰۲۵ تخمین میزنن ۱۴۶ هزار تا رفرنس غیرواقعی تولید شده.
نکته‌ش اینه که این یه مورد "چند تا آدم متقلب" نیست؛ Hallucination توی کل مقالات پخش شده. یعنی طرف مقاله رو نوشته، آخرش واسه رفرنس‌ها داده یه LLM براش لیست ردیف کرده، اونم از خودش اسم کتاب و مقاله درآورده. بیشترین نفوذ هم توی کامپیوتر و علوم اجتماعی بوده؛ جاهایی که AI-assisted writing بیشتر استفاده میشه. جالبه که نویسنده‌های تازه‌کار و تیم‌های کوچیک بیشتر از همه توی این تله افتادن.
من خودم وقتی داشتم یه Agent واسه Research خودکار می‌ساختم، دقیقاً به همین خوردم. مدل‌ها مخصوصاً مدل‌های کوچیک‌تر، وقتی تحت فشار قرار می‌گیرن یا ابزار جستجو دم دست‌شون نیست، شروع می‌کنن به ساختن رفرنس‌هایی که خیلی "منطقی" به نظر میان ولی اصلاً وجود ندارن. بدتر اینکه این رفرنس‌های فیک بیشتر به نفع آدم‌های معروف و مردهای پرکار تموم شده؛ یعنی AI داره Biasهای قبلی رو توی سیستم اعتباردهی علم هم بازتولید می‌کنه.
فاجعه اصلی کجاست؟ اینکه سیستم‌های بازبینی و داوری مجلات اصلاً متوجه این موضوع نمیشن. یعنی این دیتای سمی داره وارد پایگاه داده‌های دائمی میشه. از اون طرف، ما داریم مدل‌های جدید رو روی همین مقالات Train می‌کنیم. این یعنی یه Feedback Loop سمی؛ یعنی مدل از روی توهمات مدل قبلی یاد می‌گیره.
لینک مقاله:
https://arxiv.org/abs/2605.07723
🛠 Join @LLMEngineers Community
نکته‌ش اینه که این یه مورد "چند تا آدم متقلب" نیست؛ Hallucination توی کل مقالات پخش شده. یعنی طرف مقاله رو نوشته، آخرش واسه رفرنس‌ها داده یه LLM براش لیست ردیف کرده، اونم از خودش اسم کتاب و مقاله درآورده. بیشترین نفوذ هم توی کامپیوتر و علوم اجتماعی بوده؛ جاهایی که AI-assisted writing بیشتر استفاده میشه. جالبه که نویسنده‌های تازه‌کار و تیم‌های کوچیک بیشتر از همه توی این تله افتادن.
من خودم وقتی داشتم یه Agent واسه Research خودکار می‌ساختم، دقیقاً به همین خوردم. مدل‌ها مخصوصاً مدل‌های کوچیک‌تر، وقتی تحت فشار قرار می‌گیرن یا ابزار جستجو دم دست‌شون نیست، شروع می‌کنن به ساختن رفرنس‌هایی که خیلی "منطقی" به نظر میان ولی اصلاً وجود ندارن. بدتر اینکه این رفرنس‌های فیک بیشتر به نفع آدم‌های معروف و مردهای پرکار تموم شده؛ یعنی AI داره Biasهای قبلی رو توی سیستم اعتباردهی علم هم بازتولید می‌کنه.
فاجعه اصلی کجاست؟ اینکه سیستم‌های بازبینی و داوری مجلات اصلاً متوجه این موضوع نمیشن. یعنی این دیتای سمی داره وارد پایگاه داده‌های دائمی میشه. از اون طرف، ما داریم مدل‌های جدید رو روی همین مقالات Train می‌کنیم. این یعنی یه Feedback Loop سمی؛ یعنی مدل از روی توهمات مدل قبلی یاد می‌گیره.
لینک مقاله:
https://arxiv.org/abs/2605.07723
🛠 Join @LLMEngineers Community
arXiv.org
LLM hallucinations in the wild: Large-scale evidence from...
Large language models (LLMs) are known to generate plausible but false information across a wide range of contexts, yet the real-world magnitude and consequences of this hallucination problem...
👍15❤3👨💻1
AI Engineers
GPT-5.6 is here… (Limited Access)
امروز OpenAI رسماً پیش‌نمایش محدود سری GPT-5.6 رو منتشر کرد. این بار به جای یک مدل واحد، سه مدل تخصصی معرفی کردن که هر کدوم برای نوع خاصی از کارها بهینه شدن. به نظرم این رویکرد خیلی هوشمندانه و حرفه‌ایه.
مدل‌های جدید:
GPT-5.6 Sol
پرچم‌دار واقعی و مدل frontier نسل بعدی. برای کارهای پیچیده، بلندمدت و agentic طراحی شده. در بنچمارک‌های سخت مثل Terminal-Bench 2.1 (اتوماسیون خط فرمان، برنامه‌ریزی و ابزارها) امتیاز فوق‌العاده ۹۱.۹٪ (حالت Ultra) گرفته. تو حوزه امنیت سایبری و ExploitBench هم عالی عمل کرده و با توکن خیلی کمتر از مدل‌های قبلی، نتایج رقابتی به دست آورده. مخصوص پروژه‌های تحقیق آسیب‌پذیری، کارهای تحقیقاتی طولانی و workflowهای پیچیده.
GPT-5.6 Terra
مدل متعادل و همه‌کاره. عملکرد نزدیک به GPT-5.5 رو با هزینه تقریباً نصف ارائه میده. برای کارهای روزمره حرفه‌ای، تحلیل، تحقیق و استفاده‌های عمومی عالیه.
GPT-5.6 Luna
سریع، سبک و اقتصادی. مناسب پروژه‌های حجیم، چت‌بات‌ها، اتوماسیون و جاهایی که سرعت و قیمت مهمه.
جزئیات بنچمارک و کارایی:
سول در کارهای agentic و long-horizon واقعاً می‌درخشه. تو GeneBench (زیست‌شناسی و ژنومیکس) هم دقت
بالاتری با مصرف توکن کمتر نشون داده.
قیمت‌گذاری هم به این صورته (به ازای هر میلیون توکن):
Sol:
۵ دلار ورودی / ۳۰ دلار خروجی
Terra:
۲.۵ دلار ورودی / ۱۵ دلار خروجی
Luna:
۱ دلار ورودی / ۶ دلار خروجی
علاوه بر این، prompt caching بهینه‌تری هم اضافه کردن و حتی روی سخت‌افزار Cerebras (تا ۷۵۰ توکن در ثانیه) در دسترس خواهد بود.
تمرکز روی ایمنی:
مث همیشه OpenAI روی ایمنی خیلی تأکید کرده. طبقه‌بندهای misuse realtime و red-teaming گسترده و محدودیت اولیه برای شرکای مورد اعتماد (به درخواست دولت آمریکا).
دسترسی عمومی گسترده‌تر احتمالاً طی هفته‌های آینده باز میشه.
مدل‌های جدید:
GPT-5.6 Sol
پرچم‌دار واقعی و مدل frontier نسل بعدی. برای کارهای پیچیده، بلندمدت و agentic طراحی شده. در بنچمارک‌های سخت مثل Terminal-Bench 2.1 (اتوماسیون خط فرمان، برنامه‌ریزی و ابزارها) امتیاز فوق‌العاده ۹۱.۹٪ (حالت Ultra) گرفته. تو حوزه امنیت سایبری و ExploitBench هم عالی عمل کرده و با توکن خیلی کمتر از مدل‌های قبلی، نتایج رقابتی به دست آورده. مخصوص پروژه‌های تحقیق آسیب‌پذیری، کارهای تحقیقاتی طولانی و workflowهای پیچیده.
GPT-5.6 Terra
مدل متعادل و همه‌کاره. عملکرد نزدیک به GPT-5.5 رو با هزینه تقریباً نصف ارائه میده. برای کارهای روزمره حرفه‌ای، تحلیل، تحقیق و استفاده‌های عمومی عالیه.
GPT-5.6 Luna
سریع، سبک و اقتصادی. مناسب پروژه‌های حجیم، چت‌بات‌ها، اتوماسیون و جاهایی که سرعت و قیمت مهمه.
جزئیات بنچمارک و کارایی:
سول در کارهای agentic و long-horizon واقعاً می‌درخشه. تو GeneBench (زیست‌شناسی و ژنومیکس) هم دقت
بالاتری با مصرف توکن کمتر نشون داده.
قیمت‌گذاری هم به این صورته (به ازای هر میلیون توکن):
Sol:
۵ دلار ورودی / ۳۰ دلار خروجی
Terra:
۲.۵ دلار ورودی / ۱۵ دلار خروجی
Luna:
۱ دلار ورودی / ۶ دلار خروجی
علاوه بر این، prompt caching بهینه‌تری هم اضافه کردن و حتی روی سخت‌افزار Cerebras (تا ۷۵۰ توکن در ثانیه) در دسترس خواهد بود.
تمرکز روی ایمنی:
مث همیشه OpenAI روی ایمنی خیلی تأکید کرده. طبقه‌بندهای misuse realtime و red-teaming گسترده و محدودیت اولیه برای شرکای مورد اعتماد (به درخواست دولت آمریکا).
دسترسی عمومی گسترده‌تر احتمالاً طی هفته‌های آینده باز میشه.
👍2💯2
امروز داشتم یه سری داکیومنت و پست درباره AI Agents و تعاملشون با دیتابیس رو بالا و پایین می‌کردم... واقعیت اینه که خروجی مستقیم LLM به SQL یا همون NL2SQL توی محیط Production هنوز خیلی ریسکی و ترسناکه. ت
استفاده از استراتژی Hybrid. یعنی از LLM فقط برای Labeling و استخراج Intent استفاده کنیم (مثلاً وقتی کاربر می‌گه «فروش دو هفته آخر مرداد»، مدل فقط بیاد این رو به پارامترهای زمانی مشخص تبدیل کنه) و بعدش با Logic کد خودمون، Query نهایی رو بسازیم.
تجربه شخصی منم توی پروژه‌های قبلی همینه... سپردن کل پروسه Join زدن و Query نوشتن به Agent، مخصوصاً روی دیتابیس‌های شلوغ و پیچیده، تهش به Hallucination و کندی ختم میشه. توی Reddit هم بحث‌های زیادی بود که Agentها بدون Guardrailهای درست، ممکنه حتی دستورات مخرب بزنن یا دیتای کاملاً اشتباه تحویل بدن که فاجعه‌ست.
برای پیاده‌سازی، فریم‌ورک‌هایی مثل LangChain و LlamaIndex ابزارهای خوبی مثل SQLDatabaseToolkit دارن، ولی به نظرم برای کارهای جدی‌تر باید سراغ LangGraph رفت تا کنترل بیشتری روی Loopهای تصحیح خطا داشته باشیم. حتماً قبل اجرا باید از پکیج‌هایی مثل sqlglot برای Validate کردن استفاده بشه تا مطمئن شیم فقط SELECT انجام میشه و ساختار کوئری سالمه.
امنیت اینجا حرف اول رو می‌زنه. همیشه باید از Read-only User استفاده کرد و Row-level security رو جدی گرفت (اعمال LIMIT اجباری و Timeout هم برای جلوگیری از Runaway Queries واجبه) وگرنه Agent با یه Query سنگین ممکنه کل زیرساخت رو بخوابونه.
بیشترین ارزش افزوده این Agentها فعلاً برای دموها و Internal Tools هست که آدم‌های غیرفنی بتونن راحت‌تر با دیتا کار کنن... ولی برای سیستم‌های حساس، حتماً باید خروجی رو قبل اجرا به کاربر نشون داد تا تایید نهایی رو بگیره.
🛠 Join @LLMEngineers Community
استفاده از استراتژی Hybrid. یعنی از LLM فقط برای Labeling و استخراج Intent استفاده کنیم (مثلاً وقتی کاربر می‌گه «فروش دو هفته آخر مرداد»، مدل فقط بیاد این رو به پارامترهای زمانی مشخص تبدیل کنه) و بعدش با Logic کد خودمون، Query نهایی رو بسازیم.
تجربه شخصی منم توی پروژه‌های قبلی همینه... سپردن کل پروسه Join زدن و Query نوشتن به Agent، مخصوصاً روی دیتابیس‌های شلوغ و پیچیده، تهش به Hallucination و کندی ختم میشه. توی Reddit هم بحث‌های زیادی بود که Agentها بدون Guardrailهای درست، ممکنه حتی دستورات مخرب بزنن یا دیتای کاملاً اشتباه تحویل بدن که فاجعه‌ست.
برای پیاده‌سازی، فریم‌ورک‌هایی مثل LangChain و LlamaIndex ابزارهای خوبی مثل SQLDatabaseToolkit دارن، ولی به نظرم برای کارهای جدی‌تر باید سراغ LangGraph رفت تا کنترل بیشتری روی Loopهای تصحیح خطا داشته باشیم. حتماً قبل اجرا باید از پکیج‌هایی مثل sqlglot برای Validate کردن استفاده بشه تا مطمئن شیم فقط SELECT انجام میشه و ساختار کوئری سالمه.
امنیت اینجا حرف اول رو می‌زنه. همیشه باید از Read-only User استفاده کرد و Row-level security رو جدی گرفت (اعمال LIMIT اجباری و Timeout هم برای جلوگیری از Runaway Queries واجبه) وگرنه Agent با یه Query سنگین ممکنه کل زیرساخت رو بخوابونه.
بیشترین ارزش افزوده این Agentها فعلاً برای دموها و Internal Tools هست که آدم‌های غیرفنی بتونن راحت‌تر با دیتا کار کنن... ولی برای سیستم‌های حساس، حتماً باید خروجی رو قبل اجرا به کاربر نشون داد تا تایید نهایی رو بگیره.
🛠 Join @LLMEngineers Community
👍11❤2
اگه دنبال «استخراج دیتا» هستی، یعنی فقط می‌خوای خروجی نهایی مدلت یه فرمت خاص داشته باشه (مثلاً لیست فاکتورها یا دسته‌بندی تیکت) مستقیم برو سراغ Structured Output. اینجا هدف اینه که مدل رو مجبور کنی دقیقاً طبق Schema تو حرف بزنه. ضریب خطاش هم خیلی کمتره چون توی سطح توکن محدود میشه و خروجی ۱۰۰ درصد معتبر میده.
اما اگه قراره مدل «تصمیم بگیره» که کاری انجام بده، مثلاً بره فلان API رو چک کنه یا توی دیتابیس بگرده، اونجاست که Function Calling میاد وسط. اینجا JSON فقط یه واسطه‌ست برای اینکه پارامترهای اون Action رو بهت بده تا تو اجراشون کنی و دوباره نتیجه رو برگردونی به مدل... یعنی یه جریان دوطرفه و Agentic.
🛠 Join @LLMEngineers Community
اما اگه قراره مدل «تصمیم بگیره» که کاری انجام بده، مثلاً بره فلان API رو چک کنه یا توی دیتابیس بگرده، اونجاست که Function Calling میاد وسط. اینجا JSON فقط یه واسطه‌ست برای اینکه پارامترهای اون Action رو بهت بده تا تو اجراشون کنی و دوباره نتیجه رو برگردونی به مدل... یعنی یه جریان دوطرفه و Agentic.
🛠 Join @LLMEngineers Community
❤1
یه سری گزارش و بنچمارک جدید درباره Chunking توی سیستم‌های RAG دیدم که خیلی از ابهام‌هام رو برطرف کرد... واقعیت اینه که هنوزم خیلیا دارن از Fixed-size Splitting استفاده می‌کنن که توی پروژه‌های جدی جواب نمی‌ده و باعث میشه Context توی پاراگراف‌ها تیکه پاره بشه و مدل گیج بزنه.
هنوز هم Recursive Character Splitting امن‌ترین نقطه شروع برای اکثر داکیومنت‌هاست. توی داکیومنت ها روی حدود ۴۰۰ تا ۵۰۰ توکن با ۱۰ تا ۲۰ درصد Overlap تاکید شده بود که معمولاً تعادل خوبی بین Precision و هزینه Embedding ایجاد می‌کنه. اما اگه دیتای تخصصی مثل متون حقوقی یا پزشکی داری، استراتژی‌های Semantic و Hierarchical قطعا خیلی بهترن.
با اینکه Semantic Chunking هزینه پردازشی بالاتری داره (چون برای هر جمله باید Embedding بگیری) ولی چون بر اساس شباهت معنایی و شکست‌های منطقی متن رو تقسیم می‌کنه، حدود ۹ درصد Recall رو بهتر می‌کنه. من خودم توی پروژه قبلی دیدم که وقتی از Parent-Document Retrieval استفاده کردیم (یعنی تیکه‌های کوچیک برای سرچ و تیکه‌های بزرگتر برای کانتکست LLM) دقت جواب‌ها به طرز عجیبی بالا رفت.
رویکردهای جدیدتر مثل Late Chunking هم دارن ترند می‌شن. ایده‌ش اینه که کل سند رو یک‌جا Embed کنی و بعد نمایش‌های میانی رو تیکه‌تیکه کنی تا ارتباط بین جملات حفظ بشه. نکته طلایی که خیلیا نادیده می‌گیرن Metadata Augmentation هست... اضافه کردن تیترها، خلاصه‌ها و تگ‌های منبع به هر Chunk، فیلتر کردن رو موقع بازیابی خیلی دقیق‌تر می‌کنه.
به نظرم به جای هایپ روی مدل‌های خفن‌تر، باید روی همین جزئیات وقت گذاشت.
🛠 Join @LLMEngineers Community
هنوز هم Recursive Character Splitting امن‌ترین نقطه شروع برای اکثر داکیومنت‌هاست. توی داکیومنت ها روی حدود ۴۰۰ تا ۵۰۰ توکن با ۱۰ تا ۲۰ درصد Overlap تاکید شده بود که معمولاً تعادل خوبی بین Precision و هزینه Embedding ایجاد می‌کنه. اما اگه دیتای تخصصی مثل متون حقوقی یا پزشکی داری، استراتژی‌های Semantic و Hierarchical قطعا خیلی بهترن.
با اینکه Semantic Chunking هزینه پردازشی بالاتری داره (چون برای هر جمله باید Embedding بگیری) ولی چون بر اساس شباهت معنایی و شکست‌های منطقی متن رو تقسیم می‌کنه، حدود ۹ درصد Recall رو بهتر می‌کنه. من خودم توی پروژه قبلی دیدم که وقتی از Parent-Document Retrieval استفاده کردیم (یعنی تیکه‌های کوچیک برای سرچ و تیکه‌های بزرگتر برای کانتکست LLM) دقت جواب‌ها به طرز عجیبی بالا رفت.
رویکردهای جدیدتر مثل Late Chunking هم دارن ترند می‌شن. ایده‌ش اینه که کل سند رو یک‌جا Embed کنی و بعد نمایش‌های میانی رو تیکه‌تیکه کنی تا ارتباط بین جملات حفظ بشه. نکته طلایی که خیلیا نادیده می‌گیرن Metadata Augmentation هست... اضافه کردن تیترها، خلاصه‌ها و تگ‌های منبع به هر Chunk، فیلتر کردن رو موقع بازیابی خیلی دقیق‌تر می‌کنه.
به نظرم به جای هایپ روی مدل‌های خفن‌تر، باید روی همین جزئیات وقت گذاشت.
🛠 Join @LLMEngineers Community
👍11❤1
امروز مدل LongCat-2.0 منتشر شد (همون Owl Alpha معروف OpenRouter) یه غول 1.6T پارامتری MoE که فقط 48B فعال داره.
چیزی که برام جالب بود اینه که کل این پروژه روی ASICهای چینی (Huawei Ascend) جمع شده و خبری از NVIDIA نبوده. 35T توکن دیتا دیده و ادعا می‌کنن توی SWE-bench Pro حتی GPT-5.5 رو هم زده.
ساختارش بر پایه LongCat-Flash بنا شده ولی با یه سری خلاقیت جالب مثل N-gram Embedding که فضای Embedding رو بدون سنگین کردن Inference تا ۱۰۰ برابر بازتر می‌کنه.
واسه هندل کردن 1M Context اومدن LongCat Sparse Attention یا همون LSA رو دادن که یه جورایی تکامل‌یافته DeepSeek Sparse Attention محسوب میشه. سیستم Indexing رو سه لایه کردن (Streaming-aware، Cross-Layer و Hierarchical) تا کوئری زدن توی سکانس‌های میلیونی، کمر سخت‌افزار رو نشکنه.
من خودم تو پروژه‌های قبلی با مدل‌های Long Context زیاد ور رفتم، معمولاً Performance بعد یه مدتی افت می‌کنه ولی اینا میگن روی صدها میلیارد توکن دیتای یک میلیون توکنی تمرینش دادن، یعنی فقط RoPE Scaling خالی نیست...
نکته اصلی اینه که کلاً Agent-centric طراحی شده. تمرکزش روی Tool Calling و Coding هست. با Claude Code و Hermes قشنگ جفت‌وجور میشه. قیمت‌گذاری‌اش هم برای ۱ میلیون توکن خروجی ۱.۲ دلاره که فعلاً رقابتیه.
هنوز فایل Weights توی Hugging Face نیست و فقط Model Card رو گذاشتن...
اینجا Technical blog اش رو میتونید بخونید:
https://longcat.chat/blog/longcat-2.0/
🛠 Join @LLMEngineers Community
چیزی که برام جالب بود اینه که کل این پروژه روی ASICهای چینی (Huawei Ascend) جمع شده و خبری از NVIDIA نبوده. 35T توکن دیتا دیده و ادعا می‌کنن توی SWE-bench Pro حتی GPT-5.5 رو هم زده.
ساختارش بر پایه LongCat-Flash بنا شده ولی با یه سری خلاقیت جالب مثل N-gram Embedding که فضای Embedding رو بدون سنگین کردن Inference تا ۱۰۰ برابر بازتر می‌کنه.
واسه هندل کردن 1M Context اومدن LongCat Sparse Attention یا همون LSA رو دادن که یه جورایی تکامل‌یافته DeepSeek Sparse Attention محسوب میشه. سیستم Indexing رو سه لایه کردن (Streaming-aware، Cross-Layer و Hierarchical) تا کوئری زدن توی سکانس‌های میلیونی، کمر سخت‌افزار رو نشکنه.
من خودم تو پروژه‌های قبلی با مدل‌های Long Context زیاد ور رفتم، معمولاً Performance بعد یه مدتی افت می‌کنه ولی اینا میگن روی صدها میلیارد توکن دیتای یک میلیون توکنی تمرینش دادن، یعنی فقط RoPE Scaling خالی نیست...
نکته اصلی اینه که کلاً Agent-centric طراحی شده. تمرکزش روی Tool Calling و Coding هست. با Claude Code و Hermes قشنگ جفت‌وجور میشه. قیمت‌گذاری‌اش هم برای ۱ میلیون توکن خروجی ۱.۲ دلاره که فعلاً رقابتیه.
هنوز فایل Weights توی Hugging Face نیست و فقط Model Card رو گذاشتن...
اینجا Technical blog اش رو میتونید بخونید:
https://longcat.chat/blog/longcat-2.0/
🛠 Join @LLMEngineers Community
❤4⚡2👍1
یه تست باحال انجام دادن که ببینن Frameworkهای هوش مصنوعی چقدر با "فهمِ" ماشین سازگارن. لنگ‌گراف با اختلاف اول شده... کلاً ۱ دقیقه و ۴۲ ثانیه طول کشیده تا ایجنت بفهمه چطوری باید نصبش کنه و یه Hello World سالم باهاش بالا بیاره. این نشون میده که داکیومنت‌هاشون برای ایجنت‌ها عالی بهینه شده.
باید بگم که DX یا همون تجربه توسعه‌دهنده دیگه فقط واسه ما آدما نیست. وقتی فریمورکی مثل Mastra شش دقیقه وقت ایجنت رو می‌گیره و کلی Error میده، یعنی ساختارش برای اتوماسیون هنوز پخته نیست. من تو پروژه‌های ایجنتیک، LangGraph رو به خاطر کنترل دقیق روی State و لوپ‌ها ترجیح می‌دم. این بنچمارک ثابت کرد چرا خروجی کدش معمولاً تمیزتر درمیاد؛ چون مدل موقع خوندن مستنداتش کمتر گیج میشه.
https://2027.dev/arena/ai-frameworks
🛠 Join @LLMEngineers Community
باید بگم که DX یا همون تجربه توسعه‌دهنده دیگه فقط واسه ما آدما نیست. وقتی فریمورکی مثل Mastra شش دقیقه وقت ایجنت رو می‌گیره و کلی Error میده، یعنی ساختارش برای اتوماسیون هنوز پخته نیست. من تو پروژه‌های ایجنتیک، LangGraph رو به خاطر کنترل دقیق روی State و لوپ‌ها ترجیح می‌دم. این بنچمارک ثابت کرد چرا خروجی کدش معمولاً تمیزتر درمیاد؛ چون مدل موقع خوندن مستنداتش کمتر گیج میشه.
https://2027.dev/arena/ai-frameworks
🛠 Join @LLMEngineers Community
👍8🔥3👌1
دوستان من دنبال موقعیت شغلی دورکاری، تمام وقت یا پاره وقت هستم
اگه شرکتتون AI Engineer نیاز داشت، خیلی ممنون میشم بهم اطلاع بدید.
رزومه من رو اینجا میتونید ببینید :
mshojaei77.github.io/about.html
ایدی تلگرام:
@realshojaeii
اگه شرکتتون AI Engineer نیاز داشت، خیلی ممنون میشم بهم اطلاع بدید.
رزومه من رو اینجا میتونید ببینید :
mshojaei77.github.io/about.html
ایدی تلگرام:
@realshojaeii
LLMs: From Foundation to Production
Portfolio
A comprehensive tutorial for mastering Large Language Models (LLMs) – from core mathematics and computing principles to production deployment, advanced applications, and emerging research trends.
❤9⚡1👌1
AI Engineers pinned «دوستان من دنبال موقعیت شغلی دورکاری، تمام وقت یا پاره وقت هستم اگه شرکتتون AI Engineer نیاز داشت، خیلی ممنون میشم بهم اطلاع بدید. رزومه من رو اینجا میتونید ببینید : mshojaei77.github.io/about.html ایدی تلگرام: @realshojaeii»