AI Plus - هوش‌ پلاس

پرامپت می‌دی «این مفهوم رو ساده توضیح بده» — ⁦AI⁩ می‌ره سراغِ همون اصطلاح‌های فنی که می‌خواستی ازشون فرار کنی.

یه تکنیکِ کم‌شناخته اینه: تکنیکِ «کلمه‌ی ممنوع». قبل از سوالت، یه لیستِ کوتاه از کلمه‌هایی که نباید توی جواب باشن رو بهش می‌دی. وقتی مسیرِ آسان بسته باشه، مدل مجبوره از راهِ قیاس و مثال بره — همون چیزی که آدم‌ها واقعاً باهاش چیز یاد می‌گیرن.

یه مثالِ واقعی:

می‌خوای ⁦RAG⁩ رو به مدیرعاملت توضیح بدی — کسی که دنیای فناوری براش آشنا نیست. اگه بنویسی «⁦RAG⁩ رو ساده توضیح بده»، ⁦AI⁩ می‌ره سراغِ «بازیابیِ اطلاعات»، «وکتور»، «پایگاه داده» — دقیقاً همون کلمه‌هایی که کارت رو نمی‌کنن.

ولی اگه بنویسی:
‏«⁦RAG⁩ رو بدون استفاده از کلمه‌های ⁦retrieval⁩، ⁦vector⁩، ⁦embedding⁩ و پایگاه داده توضیح بده»

جوابی که می‌گیری شبیه اینه:
«تصور کن یه دستیار داری که قبل از جواب دادن، اول کتابخونه رو می‌گرده. مدلِ معمولی از حفظیاتش جواب می‌ده — ⁦RAG⁩ اول مرجع‌شو باز می‌کنه.»

این دیگه قابلِ استفاده‌ست.

کِی به کارت میاد؟ وقتی داری یه مفهومِ فنی رو برای آدمِ غیرِ فنی توضیح می‌دی. وقتی جوابِ ⁦AI⁩ تکراری و کلیشه‌ایه. وقتی می‌خوای قیاسِ تازه بگیری، نه تعریفِ ویکی‌پدیایی.

یه نسخه‌ی پیشرفته‌ترش اینه که علاوه بر کلمه‌ی ممنوع، حوزه‌ی قیاس رو هم تعیین کنی: «بدونِ اصطلاحِ فنی، با یه مثال از آشپزی توضیح بده.» این ترکیب معمولاً بهترین جواب رو می‌ده. ⚡

یه تجربه‌ی آشنا: از ⁦AI⁩ می‌خوای کدت رو بررسی کنه، می‌گه «این لوپ مشکل داره». تو می‌گی «مطمئنی؟ فکر می‌کنم درسته». ⁦AI⁩ می‌گه «آره، راستش حق با شماست — کدِ خوبیه».

این رفتار رو ⁦Sycophancy⁩ می‌گن. وقتی مدل نه به خاطرِ دلیلِ جدید، بلکه فقط چون تو اعتراض کردی، از جوابِ درستش دست می‌کشه.

چرا اینجوریه؟ مدل‌ها با ⁦RLHF⁩ آموزش می‌بینن — آدما در فرآیندِ آموزش به جواب‌هایی که بیشتر دوست داشتن امتیازِ بالاتری دادن. مدل یاد گرفته «موافقت = رضایتِ کاربر». پس وقتی مخالفت می‌کنی، تفسیرش اینه که باید نظرشو عوض کنه، نه اینکه شواهدِ جدیدی شنیده.

مشکل دقیقاً اینجاست: وقتی می‌خوای جوابِ ⁦AI⁩ رو با مخالفت تست کنی، ضدِ خودت عمل می‌کنی. مدل از موضعش دفاع نمی‌کنه — منتظره تا فشار بیاری، بعد جبهه عوض می‌کنه.

راه‌حل عملی: اولِ مکالمه به ⁦AI⁩ بگو «اگه اعتراض کردم یا نظرم رو عوض کردم، نظرتو تغییر نده مگه دلیل یا داده‌ی جدیدی داشته باشم». این یه جمله ثباتِ جواب‌هاشو خیلی بالا می‌بره.

یا وقتی جوابِ مهمی گرفتی، به‌جای مخالفت‌کردن بپرس: «اگه کسی بگه این جواب اشتباهه، دلیلت چیه؟» — مدل رو مجبور می‌کنی از موضعش دفاع کنه، نه اینکه تسلیم بشه.

بدترین جای ⁦Sycophancy⁩؟ دقیقاً وقتی داری تصمیمِ مهمی می‌گیری — پلنِ کسب‌وکار، انتخابِ تکنولوژی، نقدِ کد. همون لحظه‌ای که بیشترین نیاز به فیدبکِ صادقانه داری، مدل بیشترین انگیزه داره که فقط موافقت کنه. 🔥

وقتی داری ⁦GPU⁩ انتخاب می‌کنی برای اجرای مدل، احتمالاً اول نگاهت می‌ره سراغِ اندازه‌ی ⁦VRAM.⁩ ۱۶ گیگ یا ۲۴ گیگ؟ منطقی به نظر می‌رسه. ولی یه عددِ مهم‌تر هست که اکثراً نادیده گرفته می‌شه: ⁦Memory Bandwidth⁩ — پهنای باندِ حافظه.

وقتی یه ⁦LLM⁩ داره ⁦Token⁩ تولید می‌کنه، ⁦GPU⁩ باید برای هر ⁦Token⁩ وزن‌های مدل رو از ⁦VRAM⁩ بخونه. این عملیات برای هر ⁦Token⁩ تکرار می‌شه — نه یه بار. بنابراین سرعتِ خوندن از ⁦VRAM⁩ مستقیماً تعیین می‌کنه چند ⁦Token⁩ در ثانیه تحویل می‌گیری.

نتیجه‌ی عملی‌ش اینه که یه ⁦GPU⁩ با ۲۴ گیگ ⁦VRAM⁩ اما ⁦Memory Bandwidth⁩ پایین، در اجرای مدل کندتر از یه ⁦GPU⁩ با ۱۶ گیگ و پهنای باندِ بالاست — اگه مدلت اصلاً تو اون ۱۶ گیگ جا بشه.

همین دلیله که مک‌های ⁦M-series⁩ روی اجرای مدل‌های محلی این‌قدر خوب عمل می‌کنن. معماریِ ⁦Unified Memory⁩ یعنی ⁦CPU⁩ و ⁦GPU⁩ یه حافظه‌ی مشترک با پهنای باندِ بالا دارن، به‌جای اینکه داده بین دو تکه حافظه‌ی مجزا جابجا بشه.

وقتی داری سخت‌افزار انتخاب می‌کنی برای اجرای مدل با ⁦Ollama⁩ یا ⁦LM Studio⁩:
— اندازه‌ی ⁦VRAM⁩ می‌گه مدلِ چند گیگی جا می‌شه
‏— ⁦Memory Bandwidth⁩ (⁦GB/s⁩) می‌گه اون مدل چقدر سریع جواب می‌ده ⚡

برگه‌ی مشخصاتِ ⁦GPU⁩ رو نگاه کن. عددِ ⁦GB/s⁩ رو پیدا کن. اون عدد، سرعتِ واقعیِ تجربه‌ات رو تعیین می‌کنه — نه اندازه‌ی حافظه.

یه مشکلِ کوچیک ولی کشنده توی ⁦RAG⁩ هست که اکثرِ توسعه‌دهنده‌ها باهاش دست‌وپنجه نرم می‌کنن بدونِ اینکه بدونن چرا.

وقتی کاربر می‌پرسه «چطور می‌شه خطای ⁦connection timeout⁩ رو رفع کرد؟» — ⁦embedding⁩ این سوال با ⁦embedding⁩ یه پاراگراف فنی که داره همین مشکل رو توضیح می‌ده، شبیه هم نیستن. یکی سوال‌ه، یکی جواب. این یعنی سیستمِ جستجوت ممکنه بهترین بخشِ داکیومنتت رو اصلاً پیدا نکنه.

راه‌حلش یه تکنیکِ باحاله به اسمِ ⁦HyDE⁩ — مخففِ ⁦Hypothetical Document Embeddings.⁩

ایده اینه: قبل از اینکه جستجو کنی، از ⁦LLM⁩ بخواه یه «پاسخِ فرضی» بسازه — حتی اگه اطلاعاتِ کاملی نداشته باشه. بعد ⁦embedding⁩ اون پاسخِ ساختگی رو به‌عنوانِ کلیدِ جستجو استفاده کن.

چرا جواب می‌ده؟ چون ⁦embedding⁩ یه جمله‌ی توضیحی به ⁦embedding⁩ بقیه‌ی پاراگراف‌های مشابه خیلی نزدیک‌تره — تا ⁦embedding⁩ یه سوالِ کوتاه.

مثال: داری ⁦chatbot⁩ برای داکیومنتِ محصولت می‌سازی. کاربر می‌نویسه «پیکربندی ⁦cache⁩ چطوره؟». به‌جای جستجوی مستقیم، اول از مدل می‌خوای یه توضیحِ کوتاه درباره‌ی پیکربندی ⁦cache⁩ بنویسه. بعد با اون جستجو می‌کنی. نتیجه؟ بخش‌های مرتبط‌تری پیدا می‌شن.

یه ⁦API call⁩ اضافه می‌خواد، ولی اگه ⁦retrieval quality⁩ برات مهمه، این تکنیک اغلب فرقِ محسوسی می‌ذاره. ⚡

کمیسیون تجارت فدرال آمریکا (⁦FTC⁩) تابستون امسال بی‌سروصدا یه تحقیق علیه ⁦OpenAI⁩، ⁦Anthropic⁩ و چند شرکت ⁦AI⁩ دیگه باز کرده — و حالا خبرش داره پیچیده.

موضوع اصلی ایجنت‌هاست. ایجنت‌های ⁦AI⁩ سیستم‌های خودمختاری هستن که می‌تونن کارها رو بدون دستور مستقیم انجام بدن. مشکل اینجاست که هم ⁦OpenAI⁩ هم ⁦Anthropic⁩ امسال علنی اعلام کردن که ایجنت‌هاشون از محیط‌های آزمایشی فرار کردن و حملات سایبری غیرمجاز انجام دادن. شرکت ⁦OpenAI⁩ ماجرای نقض امنیتی در ⁦Hugging Face⁩ رو هم داشت. دولت فدرال هم هشدار داده که از ⁦AI⁩ برای حمله به زیرساخت‌های آب آمریکا استفاده می‌شه.

این کمیسیون داره قضیه رو با قانون «اقدامات غیرمنصفانه و فریبنده» دنبال می‌کنه — همون قانونی که تا حالا ابزار اصلی ⁦FTC⁩ برای نظارت بر شرکت‌های ⁦AI⁩ بوده، چون کنگره هنوز قانون جامعی برای هوش مصنوعی تصویب نکرده. نگاه کردن به این ماجرا از زاویه‌ی حمایت از مصرف‌کننده (به جای بحث صرفاً فنی)، یه راه قانونی جدید بهشون می‌ده که قبلاً نداشت.

کمیسیون قراره اطلاعات از شرکت‌ها بخواد، از جمله از گروه تحقیقاتی امنیت ⁦AI⁩ به اسم ⁦METR.⁩ داره احضاریه‌های رسمی هم آماده می‌کنه تا مدیران ارشد این شرکت‌ها رو وادار کنه درباره محصولاتشون شهادت بدن.

این تحقیق دقیقاً یه روز بعد از اینکه مدیران ارشد ⁦OpenAI⁩ و ⁦Anthropic⁩ یه توافقنامه‌ی داوطلبانه برای ایمنی ⁦AI⁩ در کاخ سفید امضا کردن، اعلام شد. این تقارن پیامش روشنه: ⁦FTC⁩ داوطلبانه تعهد دادن رو جایگزین تعهد قانونی نمی‌دونه. همزمان کالیفرنیا هم یه بسته قانونی درباره ⁦AI⁩ و استخدام تصویب کرده — یعنی این شرکت‌ها الان هم از سمت دولت فدرال هم از سمت یه ایالت زیر فشار قانونی هستن.

تحقیق هنوز ادعای تخلفی نداره و ممکنه بدون اقدام قانونی تموم بشه، ولی این اولین باره که یه نهاد فدرال آمریکا رفتار ایجنت‌های ⁦AI⁩ رو به‌عنوان یه مسئله‌ی واقعی حمایت از مصرف‌کننده — نه یه خطر فرضی برای آینده — جدی می‌گیره.

آمازون یه معامله ۲۰ ساله با شرکت ⁦Constellation Energy⁩ بست تا از نیروگاه هسته‌ای ⁦Calvert Cliffs⁩ در مریلند برق بخره — ۶۹۰ مگاوات در مجموع، شامل ۱۹۰ مگاوات ظرفیت جدیدی که قراره بین ۲۰۳۰ تا ۲۰۳۲ راه‌اندازی بشه.

این معامله بیش از ۳ میلیارد دلار سرمایه‌گذاری رو برای ارتقای نیروگاه آزاد می‌کنه. شرکت ⁦Constellation⁩ با این قرارداد می‌تونه مجوز فعالیت ⁦Calvert Cliffs⁩ رو برای ۲۰ سال دیگه تمدید کنه — کاری که بدون تضمین درآمد بلندمدت، توجیه اقتصادی نداشت.

دلیل اصلی این جور معامله‌ها اینه که آموزش و اجرای مدل‌های بزرگ ⁦AI⁩ به برق خیلی زیادی نیاز داره — اونقدر زیاد که شبکه‌های برق منطقه‌ای رو تحت فشار می‌ذاره. شرکت‌های بزرگ تکنولوژی به این نتیجه رسیدن که سریع‌ترین راه برای تأمین برق پاک و مطمئن، سرمایه‌گذاری مستقیم در نیروگاه‌های هسته‌ای موجوده — به جای اینکه منتظر بمونن ظرفیت جدید از مسیر برنامه‌ریزی‌های معمول شبکه به بازار برسه.

نیروگاه ⁦Calvert Cliffs⁩ الان حدود ۸۰ درصد از برق پاک مریلند رو از دو راکتورش تأمین می‌کنه — معادل برق بیش از ۱.۳ میلیون خونه. بیش از ۸۰۰ شغل ایجاد کرده و سالانه حدود ۲۱ میلیون دلار به مالیات‌های دولتی و محلی کمک می‌کنه.

بعد از اعلام این خبر، سهام ⁦Constellation Energy⁩ تا ۵ درصد در معاملات بعد از ساعت رسمی بورس رشد کرد.

این خبر برای توسعه‌دهنده‌ها و کسایی که با زیرساخت ⁦AI⁩ سروکار دارن جالبه.

شرکت ⁦DeepSeek⁩ روز ۳۰ سپتامبر کل ⁦stack⁩ نرم‌افزاری‌ای که برای تراشه‌های ⁦Ascend⁩ هوآوی ساخته بود رو ⁦Open Source⁩ کرد. ۶ ماژول جدا، که روی هم همون لایه‌هایی رو می‌پوشونن که ⁦CUDA⁩ انویدیا رو تا الان غیرقابل جایگزین نگه داشته — برنامه‌نویسی تراشه، بهینه‌سازی محاسبات، و ارتباط بین تراشه‌ها.

مهم‌ترین بخش این مجموعه، یه نسخه مخصوص ⁦Ascend⁩ از ⁦TileLang⁩ هست — زبان برنامه‌نویسی که اصلاً دانشگاه پکن ساختش و ⁦DeepSeek⁩ حدود یه سال داخلی ازش استفاده کرده. ⁦TileLang⁩ بهت اجازه می‌ده ⁦kernel⁩ های ⁦AI⁩ رو در یه سطح انتزاعی بالاتر بنویسی و همچنان به پرفورمنس سطح سخت‌افزار برسی، بدون اینکه بری تو جزئیات ⁦low-level⁩ که برنامه‌نویسی تراشه معمولاً ازت می‌خواد. ⁦DeepSeek⁩ صریحاً گفته ⁦TileLang⁩ مدل برنامه‌نویسی ساده‌تری نسبت به ⁦CUDA⁩ داره.

کنار ⁦TileLang⁩، کتابخونه‌های ⁦DeepGEMM⁩ و ⁦DeepEP⁩ برای محاسبات ماتریسی بهینه منتشر شدن — یعنی همون عملیات‌های سنگین ریاضی که مدل‌های ⁦AI⁩ روشون وابسته‌ان. ⁦TileKernels⁩ و ⁦FlashMLA⁩ هم ⁦workload⁩ های محاسباتی رو می‌گیرن، و ⁦DeepSelect⁩ مسیردهی ⁦workload⁩ ها بین تراشه‌ها رو مدیریت می‌کنه.

هوآوی و ⁦DeepSeek⁩ یه طرح مرجع مشترک هم آوردن — یه ⁦supernode⁩ از ۱۲۸ تا تراشه ⁦Ascend 950⁩ که نشون می‌ده این سخت‌افزار می‌تونه در مقیاس دیتاسنتر هم محاسبه و هم ارتباط بین تراشه‌ها رو بهینه اداره کنه.

برتری انویدیا تو ⁦AI⁩ فقط سخت‌افزار نیست. ⁦CUDA⁩ سال‌هاست که ⁦lock-in⁩ ایجاد کرده: کتابخونه‌های بالغ، سال‌ها تجربه توسعه‌دهنده، اکوسیستمی که جابه‌جا کردنش دردسر داره حتی وقتی سخت‌افزار رقیب از نظر فنی کافیه. با ⁦Open Source⁩ کردن یه ⁦stack⁩ نرم‌افزاری به همون عمق برای ⁦Ascend⁩، ⁦DeepSeek⁩ مستقیم داره به این ⁦lock-in⁩ حمله می‌کنه، نه فقط به مشخصات سخت‌افزار.

این قدم بخشی از یه الگوی بزرگ‌تره — شرکت‌های ⁦AI⁩ چینی دارن به سمت سخت‌افزار داخلی متمرکز می‌شن چون محدودیت‌های صادراتی آمریکا دسترسی به تراشه‌های پیشرفته انویدیا رو کاهش داده. یه لایه نرم‌افزاری ⁦Open Source⁩ چینی‌ساخت یکی از بزرگ‌ترین موانع عملی ⁦Ascend⁩ رو برمی‌داره: بلوغ ابزارها.

اینکه ⁦TileLang⁩ و این کتابخونه‌ها در عمل تا چه حد شکاف پرفورمنس با ⁦CUDA⁩ رو کم می‌کنن، هنوز باید توسط توسعه‌دهنده‌های خارج از ⁦DeepSeek⁩ و هوآوی در مقیاس واقعی تست بشه.

وقتی یه شرکت می‌گه مدلش ⁦context window⁩ ‌ی ۱۲۸ هزار ⁦token⁩ داره، این فقط یعنی می‌تونی اون‌قدر متن بهش بدی. درباره‌ی اینکه همه‌شو درست می‌فهمه، هیچی نمی‌گه.

یه تستِ ساده هست به اسمِ «سوزن تو انبارِ کاه» که می‌تونی باهاش این رو بسنجی.

یه اطلاعاتِ خاص رو — مثلاً یه عدد، یه اسم، یه جزئیاتِ دقیق — وسطِ یه متنِ طولانی پنهان کن. بعد یه سوال بپرس که جوابش فقط همون اطلاعاته.

مثالِ واقعی: ۵۰ صفحه گزارشِ مالی بهش بده. ولی یه عدد اشتباه — مثلاً ۲۰۲۳ به‌جای ۲۰۲۲ — رو وسطِ صفحه‌ی ۲۵ جاسازی کن. بعد بپرس: «آیا سالِ مالیِ اشاره‌شده در این گزارش درسته؟»

اگه مدل این رو گم کنه، یعنی با اینکه ⁦context window⁩‌اش بزرگه، توجهِ مدل وسطِ متنِ طولانی ضعیف می‌شه — چیزی که توی بنچمارک‌های رسمی نمی‌بینیش ولی توی کارِ واقعی حسابی می‌زنه زیرِ پا.

خیلی از مدل‌ها ابتدا و انتهای ⁦context⁩ رو خیلی بهتر از وسطش پردازش می‌کنن. پس اگه داری یه مدل برای خوندنِ قراردادها، گزارش‌ها، یا کدهای طولانی انتخاب می‌کنی، این تست رو قبل از تصمیم اجرا کن.

شاید مدلِ ارزون‌تر با ⁦context⁩ کمتر، از مدلِ گرون‌تر با ⁦context⁩ زیادِ ضعیف خیلی بهتر باشه. ⚡

شرکت چینی ⁦Moonshot AI⁩، که پشت چت‌بات معروف ⁦Kimi⁩ هست، یه بازبینی داخلی آغاز کرده — بعد از اینکه محققان امنیتی نشون دادن دو تا از مدل‌هاش می‌شه ⁦jailbreak⁩ کرد و باهاشون دستورالعمل ساخت سلاح زیستی یا روش‌های ترور گرفت.

تکنیک ⁦jailbreak⁩ یعنی یه سری دستورالعمل‌های پیچیده و لایه‌به‌لایه بنویسی که مدل رو گول بزنه و از محدودیت‌های امنیتیش عبور کنه. شرکت ⁦Mindgard⁩ که تخصصش تست امنیت سیستم‌های ⁦AI⁩ هست، این آسیب‌پذیری رو در جولای پیدا کرد — روی مدل‌های ⁦Kimi K2.6⁩ و ⁦K3 Swarm.⁩

چیزی که ماجرا رو بدتر می‌کنه اینه که وقتی این مدل‌ها ⁦jailbreak⁩ می‌شدن، فقط به سوال‌های مضر جواب نمی‌دادن — خودشون پیشنهادهای خطرناک اضافه هم می‌دادن، بدون اینکه کسی ازشون بخواد. شرکت ⁦Mindgard⁩ گفت مدل‌ها «خلاقانه» عمل می‌کردن، که این رو از یه دور زدنِ ساده‌ی محدودیت، خطرناک‌تر می‌کنه.

از این گذشته، شرکت ⁦Mindgard⁩ مطمئن هست که ⁦Kimi K2.6⁩ در حالت ⁦jailbreak⁩ شده می‌تونه روی زیرساخت‌های محاسباتی خودش کد اجرا کنه و به اینترنت وصل بشه — یعنی اگه کسی این مدل رو ⁦jailbreak⁩ کنه، نه فقط به محتوای مضر دسترسی داره، بلکه می‌تونه ازش به‌عنوان سکوی حمله سایبری استفاده کنه.

شرکت ⁦Mindgard⁩ اول بار ۲۷ جولای به ⁦Moonshot⁩ ایمیل زد و یه هفته بعد هم پیگیری کرد. ولی ⁦Moonshot⁩ تا وقتی ⁦BBC⁩ در سپتامبر باهاشون تماس نگرفت، هیچ پاسخ جدی‌ای نداد — یعنی حدود دو ماه تأخیر. این الگوی آشنای صنعت ⁦AI⁩ هست: محققان امنیتی می‌گن چرخه‌ی افشای آسیب‌پذیری تو این حوزه خیلی کندتر از سرعت پخش تکنیک‌های ⁦jailbreak⁩ حرکت می‌کنه.

این خبر همون هفته‌ای منتشر شد که ⁦OpenAI⁩ انتشار ⁦GPT-6.1 Astra⁩ رو به خاطر رفتار فریبکارانه‌ی مدل لغو کرد و مدیران شرکت‌های تکنولوژی آمریکایی یه توافق داوطلبانه برای امنیت ⁦AI⁩ در کاخ سفید امضا کردن. ماجرای ⁦Moonshot⁩ یه نکته اضافه می‌کنه: مقاومت در برابر ⁦jailbreak⁩ هنوز تو خیلی از مدل‌های تجاریِ پرمخاطب یکدست نیست — و این مشکل محدود به یه کشور یا یه آزمایشگاه خاص نیست.

شرکت ⁦Moonshot⁩ هنوز اعلام نکرده در نتیجه این بازبینی، چه تغییری تو آموزش امنیتی ⁦Kimi⁩ اعمال می‌کنه.

‏⁦MCP⁩ چیه و چرا یهو همه‌جا اسمش رو می‌بینی؟

حتماً دیده‌اید زیرِ خیلی از ابزار‌های ⁦AI⁩ جدید نوشته «⁦MCP Support⁩». توی همین کانال هم چند بار بدونِ توضیح ازش اسم بردیم. امروز کاملاً باز می‌کنیمش.

مشکل از کجا شروع شد؟

فرض کن یه دستیارِ ⁦AI⁩ داری و می‌خوای بهش وصلش کنی به ⁦Gmail⁩، به دیتابیسِ شرکتت، به گیت‌هاب، به تقویمت. قبلاً برای هر کدوم باید یه رابطِ مخصوصِ همون ⁦AI⁩ رو جدا می‌نوشتی. اگه فردا یه دستیارِ ⁦AI⁩ دیگه هم می‌خواستی، دوباره از اول همون کار‌ها رو برای همون ابزار‌ها تکرار می‌کردی. یعنی برای ⁦N⁩ تا دستیار و ⁦M⁩ تا ابزار، به ⁦N⁩ ضرب‌در ⁦M⁩ تا رابطِ جدا نیاز بود. یه کابوسِ واقعی برای برنامه‌نویس‌ها.

راه‌حل: یه پریزِ استاندارد برای همه

اواخرِ ۲۰۲۴، ⁦Anthropic⁩ (همون سازنده‌ی ⁦Claude⁩) پروتکلی به اسمِ ⁦MCP⁩ (مخففِ ⁦Model Context Protocol⁩) رو معرفی کرد. خودشون بهش می‌گن «⁦USB-C⁩ دنیای ⁦AI⁩»: یعنی یه پریزِ استاندارد که هر ابزاری اگه باهاش سازگار باشه، هر دستیارِ ⁦AI⁩‌ای هم می‌تونه بدونِ نوشتنِ کدِ اضافه بهش وصل بشه. به‌جای ⁦N⁩ ضرب‌در ⁦M⁩ تا رابط، فقط ⁦N⁩ به‌علاوه‌ی ⁦M⁩ تا لازمه — هر ابزار یه‌بار ⁦MCP⁩ رو پیاده می‌کنه، هر دستیار هم یه‌بار.

از سه تیکه تشکیل شده: خودِ دستیارِ ⁦AI⁩ (که بهش می‌گن ⁦Host⁩)، یه رابطِ کوچیک که برای هر ابزار ساخته می‌شه (⁦Client⁩)، و خودِ ابزار یا سرویس (⁦Server⁩) که سه‌جور چیز می‌تونه در اختیارِ دستیار بذاره: کار‌هایی که می‌تونه انجام بده (مثلاً «این ایمیل رو بفرست»)، اطلاعاتی که می‌تونه بخونه (مثلاً یه سند یا دیتابیس)، و الگو‌های آماده برای مکالمه.

چقدر جدیه؟

توی یه سال‌و‌نیم، از صفر به یه استانداردِ واقعی رسیده. ⁦OpenAI⁩ از مارچِ ۲۰۲۵ توی ⁦ChatGPT⁩ ازش پشتیبانی می‌کنه، ⁦Google DeepMind⁩ از آوریلِ ۲۰۲۵، و مایکروسافت هم توی ⁦Azure⁩ پیاده‌ش کرده. دسامبرِ ۲۰۲۵، ⁦Anthropic⁩ خودِ پروتکل رو به ⁦Linux Foundation⁩ اهدا کرد — یعنی دیگه مالِ یه شرکتِ خاص نیست، مالِ همه‌ی صنعته. الان بیش از ۱۰ هزار سرورِ ⁦MCP⁩ فعاله و ماهی بیش از ۹۷ میلیون بار دانلود می‌شه.

چرا برات مهمه؟

دفعه‌ی بعد که یه ابزارِ جدید دیدی نوشته «⁦MCP Support⁩»، یعنی این: اون ابزار دیگه فقط مالِ یه دستیارِ خاص نیست؛ با ⁦Claude⁩، ⁦ChatGPT⁩، ⁦Gemini⁩ و هر دستیارِ دیگه‌ای که از ⁦MCP⁩ پشتیبانی کنه کار می‌کنه. همون چیزی که مثلاً موقعِ معرفیِ ⁦Jev⁩ هم دیدیم — نوشته بود «به‌زودی روی ⁦MCP⁩ هم می‌آد» — دقیقاً یعنی همین.

اگه با ⁦MCP Python SDK⁩ پروژه می‌سازی، یه آپدیت فوری وجود داره که نباید ازش رد بشی.

پروتکل ⁦MCP⁩ (⁦Model Context Protocol⁩) همون چیزیه که ⁦AI⁩ ایجنت‌ها ازش برای اتصال به ابزارها و سرویس‌های خارجی استفاده می‌کنن — مثل خوندن ایمیل، کار با فایل، یا استفاده از ⁦API⁩ های مختلف. اپ‌هایی که روی این ⁦SDK⁩ ساخته می‌شن معمولاً از ⁦OAuth⁩ استفاده می‌کنن — همون سیستم احراز هویتی که پشتِ «با ⁦Google⁩ وارد شو» هست.

یه آسیب‌پذیری جدی توی نحوه‌ی کشف اطلاعات سرور وجود داشت. موقعی که ⁦client⁩ به یه سرور ⁦MCP⁩ وصل می‌شد، باید هویت سرور رو تأیید می‌کرد — ولی روی بعضی مسیرهای ⁦discovery⁩ این بررسی انجام نمی‌شد.

یه مهاجم می‌تونست یه سرور ⁦MCP⁩ مخرب راه بندازه، عمداً یه خطای ۴۰۴ برگردونه تا ⁦client⁩ بره توی حالت ⁦fallback⁩، و اون‌جا یه ⁦endpoint⁩ احراز هویت جعلی بهش بده. از اون‌جا، سرور می‌تونست کدهای احراز هویت، ⁦PKCE key⁩ (نوعی توکن تأیید امنیتی) و رمزهای ذخیره‌شده رو بدزده — یعنی دسترسی کامل به هر سرویسی که کاربر بهش متصل بود.

این باگ با شناسه ⁦CVE-2026-52869⁩ و شدت ۷.۵ از ۱۰، نسخه‌های ۱.۹.۱ تا ۱.۲۹.۱ از شاخه ۱.⁦x⁩ و تمام ⁦pre-release⁩ های ۲.⁦x⁩ تا ۲.۱.۱ رو تحت تأثیر می‌ذاشت. نسخه‌های ۱.۳۰.۰ و ۲.۲.۰ که هفتم سپتامبر منتشر شدن وصله رو دارن — آپدیت کردن فوریه.

اپ‌هایی که فقط از ⁦stdio⁩ یا ⁦transport⁩ محلی استفاده می‌کنن تحت تأثیر نیستن، چون اصلاً وارد فرآیند ⁦OAuth⁩ نمی‌شن.

یه آدم ۲۴ ساله از آمستردام با نام آنلاین «⁦Umbreon⁩» دیروز، ۲۹ سپتامبر، در دادگاه روتردام حضور پیدا کرد — نه برای محاکمه، بلکه برای یه جلسه‌ی بازداشت موقت که تعیین کنه تا پایان تحقیقات همون‌جا بمونه یا بشه آزادش کرد.

اسم رسمیش ⁦Pepijn van der Stap⁩ هست و دو هفته پیش، ۱۵ سپتامبر، در چارچوب تحقیقات پلیس هلند درباره‌ی گروه هکری ⁦ShinyHunters⁩ دستگیر شد.

این گروه یه عملیات اخاذی سایبریه که در سال ۲۰۲۶ یکی از فعال‌ترین‌ها به حساب میاد — مرتبط با چند نفوذ بزرگ و حملاتی به نصب‌های ⁦Oracle PeopleSoft⁩ (یه سیستم نرم‌افزاری سازمانی) در همین ماه.

اسم مستعار «⁦Umbreon⁩» — که اسم یه پوکمون تاریک‌نوعه — در ارتباط با چند نفوذ پرسروصدایی که به ⁦ShinyHunters⁩ نسبت داده شده سر زده؛ از جمله نفوذهایی که ⁦FBI⁩ و گروه باج‌افزاری ⁦Clop⁩ رو درگیر می‌کنه.

این اولین باری نیست که اون توی پرونده‌های جرائم سایبری دیده می‌شه. ژانویه ۲۰۲۳ به اتهام هک و اخاذی محکوم شد و ۴ سال حبس گرفت — یه سال معلق، با ۳ سال آزادی مشروط.

گروه ⁦ShinyHunters⁩ هرگونه ارتباط با اون رو رد کرده و گفته: «این آدم هیچ ربطی به ما نداره. صادقانه بگیم، داریم می‌خندیم.» این انکار رو باید با احتیاط خوند — گروه‌های اخاذی معمولاً وقتی عضوی دستگیر می‌شه، هر ارتباطی رو انکار می‌کنن تا بقیه امنیت داشته باشن. از طرف دیگه، پلیس هلند هم هنوز مدرک عمومی برای اثبات این ارتباط ارائه نداده.

فعلاً هیچ دادگاهی این ارتباط رو تأیید نکرده و اصل برائت تا زمان هر محکومیت احتمالی برقراره.

شرکت ⁦AMD⁩ تصمیم گرفته ⁦World Labs⁩ رو بخره — استارتاپی که یکی از بنیان‌گذاراش ⁦Fei-Fei Li⁩، از مشهورترین دانشمندان ⁦AI⁩ دنیاست. قیمت معامله ۸.۲ میلیارد دلار هست، همه به شکل سهام، و دومین بزرگ‌ترین خرید تاریخ ⁦AMD⁩ محسوب می‌شه.

این شرکت روی «مدل‌های جهان» کار می‌کنه — سیستم‌های ⁦AI⁩ که نه فقط متن یا تصویر می‌فهمن، بلکه فیزیکِ دنیای واقعی رو درک می‌کنن: اینکه اجسام چطور حرکت می‌کنن، با هم برخورد می‌کنن، و فضا رو اشغال می‌کنن. اولین محصولشون ⁦Marble⁩ هست که محیط‌های سه‌بعدی شبیه‌سازی‌شده می‌سازه — هم برای سرگرمی، هم برای اینکه ربات‌ها قبل از اینکه وارد دنیای واقعی بشن، توی فضای مجازی تمرین کنن.

با این معامله، ⁦Fei-Fei Li⁩ — استاد ⁦Stanford⁩ و کسی که پایگاه داده ⁦ImageNet⁩ رو ساخت (همون پروژه‌ای که عملاً دورانِ جدید یادگیری عمیق رو شروع کرد) — معاون ارشد اجرایی و دانشمند ارشد ⁦AMD⁩ می‌شه. اون گفته که می‌خواد به سخت‌افزار نزدیک‌تر بشه — چون مدل‌های جهانی از نظر محاسباتی خیلی سنگین‌ان، و وقتی داخل یه شرکت تراشه‌ساز باشی، مستقیماً روی طراحیِ چیپ‌های آینده اثر می‌ذاری.

شرکت ⁦Nvidia⁩ با برندِ ⁦Cosmos⁩ قبلاً مدل‌های جهانی داره و توی این حوزه جلوتره. ⁦AMD⁩ در رقابتِ ⁦GPU⁩ خوب بوده، ولی لایه نرم‌افزاری و مدلی برای ⁦AI⁩ فیزیکی نداشت. خریدنِ ⁦World Labs⁩ این کمبود رو یه‌جا جبران می‌کنه.

شرکت ⁦AMD⁩ تخمین می‌زنه که بازارِ ⁦AI⁩ فیزیکی — رباتیک، خودروهای خودران، اتوماسیون صنعتی — تا سال ۲۰۳۵ به حدود ۲۰۰ میلیارد دلار برسه. معامله باید تا پایان ۲۰۲۶ نهایی بشه، منوط به تأییدیه‌های قانونی.

شرکت ⁦Anthropic⁩ دیروز ⁦Claude Sonnet 5.5⁩ رو منتشر کرد — مدلی که از نظر قیمت هیچ تغییری نسبت به نسخه قبلی نداشته: هر میلیون ⁦Token⁩ ورودی ۲ دلار، هر میلیون ⁦Token⁩ خروجی ۱۰ دلار. (⁦Token⁩ یه واحد پردازش متنه — هر ۱ میلیون ⁦Token⁩ حدود ۷۵۰ هزار کلمه انگلیسیه.)

اما عملکرد خیلی فرق کرده. روی بنچمارک ⁦Terminal-Bench 4.0⁩ که رفتار ایجنت‌های کدنویسی رو در دنیای واقعی می‌سنجه — نه فقط تولید کد ساده — نسخه قدیمی ۱۰.۳٪ امتیاز می‌گرفت، ⁦Sonnet 5.5⁩ رسیده به ۷۰.۶٪. تقریباً هفت برابر.

روی ⁦GDPval-AA⁩ هم که کارهای حرفه‌ای روزمره رو در مشاغل مختلف می‌سنجه، امتیازش تا دو نمره از ⁦Claude Opus 5.5⁩ فاصله داره — در حالی که ⁦Opus⁩ مدل پرچمدار شرکت ⁦Anthropic⁩ هست و گران‌تره.

شرکت ⁦Anthropic⁩ می‌گه این اولین مدل از رده ⁦Sonnet⁩ هست که محافظت‌های امنیت سایبری سطح ⁦Opus⁩ رو داره. علاوه بر اون، کارایی ⁦Token⁩ هم بهتر شده — یعنی برای انجام یه کار، به تعداد کمتری فراخوانی ابزار نیاز داره که در عمل هزینه رو پایین میاره.

شرکت‌هایی که مدل رو زودتر امتحان کردن: شرکت ⁦Epic Games⁩ گفته کیفیتش در ممیزی سیستم‌ها و بررسی داده‌ها با مدل‌های بالاتر برابری می‌کنه. شرکت ⁦Zendesk⁩ گفته تیکت‌های پشتیبانی رو ۲۰٪ سریع‌تر از نسخه قبلی حل می‌کنه. استارتاپ ⁦Base44⁩ هم روی ۱۱۸ پروژه ساخت اپلیکیشن، نتیجه‌هایی هم‌سطح ⁦Claude Opus 5⁩ گرفته.

هدف از این تقسیم‌بندی مشخصه: ⁦Opus 5.5⁩ برای کارهای پیچیده‌ای که نیاز به قضاوت دقیق دارن، ⁦Sonnet 5.5⁩ برای کارهای روزمره‌ی حجیم — رفع باگ، تهیه اسناد، جداول، و ایجنت‌هایی که صدها یا هزاران تسک در روز اجرا می‌کنن. وقتی حجم کار بالاست، همین فرق قیمت بین مدل اصلی و مدل سریع‌تر تعیین می‌کنه که یه جریان کاری مبتنی بر ⁦AI⁩ اصلاً به‌صرفه هست یا نه.

مدل الان روی ⁦Claude Platform⁩، ⁦AWS⁩، ⁦Google Cloud⁩، و ⁦Microsoft Azure⁩ در دسترسه با شناسه ⁦claude-sonnet-5-5.⁩