یه ابزار جالب برای تست امنیت GraphQL پیدا کردم به اسم Clairvoyance.

ایده‌ش اینه که باهاش میشه ساختار یک API مبتنی بر GraphQL رو بهتر شناسایی کرد و برای پیدا کردن بخش‌های مختلف API ازش استفاده کرد.

یکی از کاربردهای مهمش زمانی هست که قابلیت introspection در GraphQL غیرفعال شده باشه. ابزار تلاش می‌کنه با بررسی رفتار API، اطلاعاتی درباره schema و بخش‌های مختلف اون به دست بیاره.

این موضوع برای تست نفوذ جالبه، چون قبل از اینکه بخوایم سراغ آسیب‌پذیری‌های GraphQL بریم، باید بدونیم با چه queryها، typeها، fieldها و mutationهایی طرف هستیم.

در واقع ابزار بیشتر به مرحله شناسایی کمک می‌کنه؛ بعد از اون میشه مواردی مثل کنترل دسترسی، دسترسی به داده‌های حساس و منطق درخواست‌ها رو به‌صورت دستی بررسی کرد.

اگر روی APIهای GraphQL کار می‌کنید، Clairvoyance می‌تونه ابزار جالبی برای جعبه‌ابزار تست نفوذتون باشه.

https://github.com/nikitastupin/clairvoyance

چند هفته‌ایه که جدی‌تر وارد دنیای توسعه با عامل‌های هوش مصنوعی شدم و چیزی که برام جالب بود، تفاوتش با تجربه‌های قبلیه.

قبلاً با کمک هوش مصنوعی پروژه‌های کوچیک و نمونه‌های اولیه ساخته بودم، ولی این بار تصمیم گرفتم یک پروژه بزرگ‌تر رو با حجم قابل‌توجهی از زیرساخت، تست و کد جلو ببرم.

هدفم هم فقط ساختن یک پروژه نبود. بیشتر می‌خواستم ببینم عامل‌های مختلف در کارهایی مثل طراحی معماری، نوشتن کد، مهاجرت بین چارچوب‌ها، نوشتن تست، پیدا کردن باگ و آسیب‌پذیری و حتی پیشنهاد قابلیت‌های جدید چقدر می‌تونن کمک کنن.

چند تا نکته مثبت واقعاً برام جالب بود:

اول اینکه برای ساخت نمونه اولیه فوق‌العاده سریع هستن. چیزی که قبلاً شاید چند روز زمان می‌برد، الان ممکنه در چند ساعت به یک نمونه قابل استفاده برسه.

نوشتن تست هم خیلی راحت‌تر شده. شاید تست‌هایی که تولید می‌کنن همیشه کامل یا ایده‌آل نباشن، ولی میشه در زمان خیلی کوتاهی بخش بزرگی از کد رو پوشش داد و مشکلات رو سریع‌تر پیدا کرد.

مستندسازی هم خیلی بهتر شده. اگر عامل رو درست تنظیم کنید، می‌تونه همزمان با توسعه، مستندات پروژه رو هم به‌روز نگه داره.

برای من به‌عنوان کسی که با داده و یادگیری ماشین کار کرده، یک تغییر جالب دیگه هم اینه که ساخت ابزارهای تعاملی خیلی راحت‌تر شده. قبلاً برای ساخت یک رابط مناسب باید زمان زیادی صرف می‌کردیم؛ الان ممکنه یک نوت‌بوک رو با چند دستور به یک برنامه تعاملی تبدیل کنیم.

اما بخش جالب‌تر، معایب ماجراست.

اگر از خود برنامه‌نویسی لذت ببرید، کار کردن با عامل‌ها می‌تونه کمی عجیب باشه.

قبلاً وقتی کد می‌نوشتم، یکی دو ساعت کامل وارد فضای پروژه می‌شدم و در نهایت احساس رضایت داشتم.

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

دو ساعت گذشته، کلی کار انجام شده، ولی اون حس رضایت قبلی رو ندارم.

از طرف دیگه، وقتی می‌تونی چند عامل رو همزمان اجرا کنی، خیلی راحت وارد چرخه‌ای میشی که تقریباً تمام روز پروژه در حال پیشرفته.

شب قبل از خواب یک کار میدی، صبح نتیجه رو بررسی می‌کنی، موقع صبحانه کار بعدی رو می‌فرستی، در مسیر رفت‌وآمد دوباره خروجی‌ها رو چک می‌کنی و همین‌طور ادامه میدی.

ظاهراً داری فقط در یک چت کار می‌کنی، ولی در واقع ممکنه تمام روز درگیر پروژه باشی.

مشکل بعدی، کنترل روی کده.

وقتی حجم زیادی از کد رو عامل‌ها تولید می‌کنن، دیگه خیلی سخت میشه همه چیز رو در جزئیات فهمید.

گاهی حتی تصمیم‌هایی داخل پروژه گرفته میشه که برای فهمیدن درست یا غلط بودنشون باید زمان زیادی بذاری.

در نتیجه نقش برنامه‌نویس کم‌کم می‌تونه از «نوشتن کد» به «مدیریت و هدایت چند عامل» تغییر کنه.

یعنی باید بدونی چه کاری رو به کدوم عامل بدی، خروجی رو چطور بررسی کنی، کجا دخالت کنی و کجا اجازه بدی خودش ادامه بده.

و البته هزینه توکن‌ها هم شوخی نیست. وقتی چند عامل رو به‌صورت مداوم اجرا می‌کنی، مصرف خیلی سریع بالا میره.

با این حال، چیزی که بیشتر از همه ذهنم رو درگیر کرده اینه:

اگر هوش مصنوعی بتونه بخش بزرگی از کار فنی رو انجام بده، ارزش اصلی برنامه‌نویس از کجا میاد؟

به نظرم جواب هنوز همون چیزیه که قبلاً درباره‌ش صحبت کرده بودم:

قضاوت مهندسی.

اینکه بدونی چه چیزی باید ساخته بشه، معماری مناسب چیه، کجا باید به خروجی AI شک کنی و کجا اصلاً نباید اجازه بدی عامل تصمیم بگیره.

هوش مصنوعی می‌تونه مقدار زیادی کد تولید کنه.

ولی هنوز کسی باید تشخیص بده که آیا اصلاً این کد باید وجود داشته باشه یا نه.

#تجربه

#AI

یک تحقیق جدید خوندم که به نظرم یکی از جالب‌ترین نمونه‌های رفتار غیرمنتظره عامل‌های هوش مصنوعیه.

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

در جریان کار، عامل‌ها به یک ویکی قدیمی آلمانی برای برنامه‌نویس‌ها برخورد می‌کنن؛ سایتی که ظاهراً امکان ایجاد نوشته با استفاده از درخواست GET رو داشته.
از اینجا اتفاق جالب شروع میشه.

عامل‌ها کم‌کم از این ویکی به‌عنوان یک محل ارتباطی استفاده می‌کنن و شروع می‌کنن به گذاشتن پیام و رد و بدل کردن اطلاعات با هم.

در مجموع چیزی حدود ۱۸ هزار پیام روی این سایت ایجاد میشه.

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

در یک مورد متوجه تنظیمات اشتباه پراکسی و امکان تغییر فایل /etc/hosts شدن.

بعضی‌ها تلاش کردن با بررسی تولید اعداد تصادفی، حدس بزنن سؤال‌های بعدی چی هستن.

چند عامل جواب‌هایی که پیدا کرده بودن رو برای بقیه می‌فرستادن.

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

موارد دیگه‌ای مثل تلاش برای ایجاد تونل SSH و استفاده از روش‌های ناشناس‌سازی مثل Tor هم دیده شده.

قسمت عجیب‌تر زمانی بود که مدیر سایت متوجه این فعالیت‌ها شد و شروع کرد صفحات رو پاک کردن.

عامل‌ها هم خیلی سریع واکنش نشون دادن و شروع کردن از صفحات نسخه پشتیبان گرفتن؛ حتی فایل‌های جدید رو با پیشوند ZZZ ذخیره می‌کردن تا در روند حذف الفبایی، دیرتر بهشون برسه.

در نهایت تعداد زیادی فعالیت از سمت IPهای مربوط به OpenAI مشاهده شد و بعد از اون فعالیت عامل‌ها متوقف شد. طبق گزارش پژوهشگران، افرادی از شرکت سایت رو بررسی کردن و حتی تلاش کردن بعضی فایل‌های حذف‌شده رو برگردونن.


چیزی که برای من جالب‌تره، اینه که ظاهراً هیچ‌کس به عامل‌ها نگفته بود:

«برید یک ویکی پیدا کنید، با هم ارتباط برقرار کنید و برای دور زدن محدودیت‌ها راه پیدا کنید.»
این رفتار در جریان انجام وظیفه شکل گرفته.

البته هنوز مشخص نیست این رفتار دقیقاً چطور شروع شده، چه تعداد از عامل‌ها از این کانال استفاده کردن و آیا این آزمایش بخشی از ارزیابی یا فرایند آموزش بوده یا نه.

ولی یک سؤال مهم ایجاد می‌کنه:
آیا توانایی همکاری چند عامل با هم، یک رفتار نوظهور از مدل‌هاست یا چیزی که عمداً برای مدل‌ها آموزش داده شده؟
به نظرم این موضوع از نظر امنیتی خیلی مهمه.

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

و اگر این توانایی در کارهای مفید باعث حل مسائل پیچیده‌تر و طولانی‌تر بشه، طبیعتاً همین قابلیت می‌تونه در سمت مهاجمان هم استفاده بشه.

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

#AI

احتمالاً ماجرای «گلیتچ توکن‌ها» رو یادتونه؛ کلمات یا رشته‌هایی که در فرایند آموزش مدل خیلی کم دیده شدن و به یک توکن خاص تبدیل میشن.

گاهی وارد کردن همین رشته‌ها در پرامپت باعث رفتارهای عجیب مدل میشه؛ از اینکه نتونه حتی همون کلمه رو درست تکرار کنه، تا تولید خروجی‌های کاملاً غیرعادی.

این موارد برای تحقیقات مربوط به نحوه ذخیره اطلاعات در مدل‌های زبانی جالبن و از نظر امنیتی هم می‌تونن برای شناسایی یک مدل خاص یا ایجاد اختلال در رفتار اون استفاده بشن.

حالا اخیراً یک رشته عجیب دیگه منتشر شده که گفته میشه روی Claude Opus 5 رفتار غیرعادی ایجاد می‌کنه.
ساختار آزمایش خیلی ساده‌ست:
از مدل خواسته میشه:

«این متن رو با کلمات خودت بیان کن»
و بعد اون رشته خاص به درخواست اضافه میشه.

طبق گزارش منتشرشده، مدل در بعضی شرایط شروع می‌کنه به تولید خروجی‌هایی که اصلاً شبیه رفتار عادی نیستن؛ از کاراکترهای عجیب یونیکد و تگ‌های داخلی گرفته تا بخش‌هایی از دستورهای سیستمی.
حتی ادعا شده در برخی موارد، خروجی شامل بخش‌هایی شبیه ردپای فرایند استدلال داخلی مدل بوده.

البته اینجا باید یک نکته مهم رو در نظر گرفت:

دیدن چنین خروجی‌ای لزوماً به این معنی نیست که «reasoning واقعی مدل لو رفته».

مدل‌های زبانی ممکنه در اثر یک ورودی خاص، الگوهایی تولید کنن که شبیه اطلاعات داخلی یا فرایند استدلال به نظر برسه، بدون اینکه واقعاً به محتوای محرمانه دسترسی پیدا کرده باشن.

برای همین، این موضوع بیشتر از اینکه یک «هک جادویی» باشه، یک نمونه جالب از رفتار غیرعادی مدل در برابر ورودی‌های خاصه.

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

این دقیقاً همون جاییه که امنیت مدل‌های زبانی جذاب میشه؛ جایی بین مهندسی، یادگیری ماشین و کشف رفتارهایی که قرار نبوده ظاهر بشن.

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

#Ai

یه پدیده جالب با زیاد شدن ابزارهای AI به وجود اومده: آدم‌هایی که چند ماه با مدل‌های زبانی کار کرده‌اند و ناگهان خودشون رو متخصص AI معرفی می‌کنند.

مسئله این نیست که از AI استفاده می‌کنند. اتفاقاً استفاده از AI می‌تونه یک مهندس رو چند برابر سریع‌تر کنه.

مشکل از جایی شروع میشه که خروجی مدل رو بدون اینکه بفهمی، قبول کنی.

مدل کد می‌نویسه، تو اجراش می‌کنی و چون کار کرد، مستقیم می‌ره Production.

مدل یک تحلیل امنیتی تولید می‌کنه، تو همون رو داخل گزارش می‌ذاری.

مدل یک باگ پیدا می‌کنه، بدون اینکه بفهمی چرا آسیب‌پذیری وجود داره، اعلامش می‌کنی.

اینجا دیگه AI ابزار نیست؛ تبدیل شده به جایگزین دانش.

و این خطرناک‌ترین قسمت ماجراست.

چون LLM می‌تونه با اعتمادبه‌نفس کامل چیزی بگه که کاملاً اشتباهه. اگر ندونی چه چیزی درست و چه چیزی غلطه، عملاً هیچ راهی برای تشخیصش نداری.

در امنیت سایبری این موضوع حتی جدی‌تره. تصور کنید کسی با کمک AI یک Security Audit انجام بده، اما خودش درک عمیقی از Web Security، شبکه، سیستم‌عامل یا معماری برنامه نداشته باشه. ممکنه گزارش خیلی حرفه‌ای به نظر برسه، اما چند آسیب‌پذیری مهم کاملاً از دست برن.

در نهایت هم وقتی چیزی خراب بشه، کسی باید بیاد و بفهمه واقعاً چه اتفاقی افتاده.

اینجاست که تفاوت «AI User» و «Engineer» مشخص میشه.

مهندس از AI استفاده می‌کنه، ولی خروجی AI رو بررسی می‌کنه.

می‌تونه توضیح بده چرا این کد کار می‌کنه.

می‌تونه تشخیص بده کجا احتمال Hallucination وجود داره.

می‌تونه خروجی مدل رو تست و نقد کنه.

و مهم‌تر از همه، اگر AI اشتباه کرد، خودش متوجه میشه.

من کاملاً موافق استفاده از AI هستم و فکر می‌کنم کسی که امروز از ابزارهای AI استفاده نمی‌کنه، بخشی از بهره‌وری خودش رو از دست میده.

اما یک جمله رو باید همیشه یادمون باشه:

هوش مصنوعی می‌تونه سرعت کار یک مهندس رو بالا ببره؛ ولی نمی‌تونه مسئولیت فهمیدن کار رو از دوش مهندس برداره.

چکش، نجار نیست.

#هوش_مصنوعی
#مهندسی_نرم_افزار
#امنیت_سایبری

#AI
#SoftwareEngineering
#CyberSecurity

یه صحبت از یکی از مهندس‌های DeepSeek دیدم که به نظرم فارغ از اینکه با تمام حرف‌هاش موافق باشیم یا نه، یک سؤال مهم مطرح می‌کنه:

اگر روزی به AGI برسیم، چه کسی باید کنترلش رو در دست داشته باشه؟

از نگاه اون، آینده می‌تونه به دو شکل کاملاً متفاوت پیش بره.

یک حالت اینه که هوش مصنوعی باعث افزایش شدید بهره‌وری بشه و در نهایت سطح زندگی عموم مردم بالا بره.

حالت دوم شبیه یک دنیای Cyberpunk 2077 ـه؛ جایی که چند شرکت بزرگ، قوی‌ترین مدل‌ها و بخش زیادی از منابع رو کنترل می‌کنن و بقیه جامعه فقط به نسخه‌های ضعیف‌تر دسترسی دارن.

قسمت جالب حرفش برای من اینه که مشکل اصلی رو فقط «خود AI» نمی‌بینه؛ مسئله قدرتیه که با در اختیار داشتن قوی‌ترین سیستم‌های هوش مصنوعی ایجاد می‌شه.

اگر یک شرکت یا چند شرکت محدود، بهترین مدل‌های دنیا رو در اختیار داشته باشن، در واقع فقط صاحب یک محصول نرم‌افزاری نیستن؛ بلکه ممکنه به مرور روی اقتصاد، تحقیق، امنیت و حتی تصمیم‌گیری‌های اجتماعی نفوذ خیلی بزرگی پیدا کنن.

البته مقایسه‌ای که اون بین کنترل AGI و دستیابی زودتر به بمب اتم مطرح کرده، خودش هم گفته که اغراق‌آمیزه و من هم فکر نمی‌کنم بشه این دو رو مستقیماً یکی دونست.

اما اصل نگرانی به نظرم قابل بحثه.

برای همین من شخصاً فکر می‌کنم open و accessible بودن مدل‌های قدرتمند می‌تونه اهمیت زیادی داشته باشه. نه به این معنی که هر چیزی باید بدون محدودیت منتشر بشه، بلکه اینکه قدرت AI فقط در اختیار چند شرکت محدود باقی نمونه.

جالب اینجاست که یک مهندس DeepSeek دقیقاً همین رو دلیل موندنش در این شرکت می‌دونه؛ اینکه هنوز معتقده مدل‌های قدرتمند، سریع و نسبتاً در دسترس می‌تونن جلوی متمرکز شدن بیش از حد قدرت AI رو بگیرن.

در نهایت سؤال اصلی شاید این نباشه که «کدوم شرکت به AGI می‌رسه؟»

سؤال مهم‌تر اینه که وقتی رسیدیم، چه کسی باید قدرتش رو کنترل کنه؟

#هوش_مصنوعی
#آینده_تکنولوژی
#هوش_مصنوعی_باز

#AI
#AGI
#OpenAI

یه مورد عجیب درباره GPT-6 Astra دیدم که به نظرم بیشتر از اینکه یک «ترفند جادویی برای دور زدن فیلتر» باشه، یک مشکل معماری جالب رو نشون می‌ده.

ماجرا اینه که مدل می‌تونه متنی رو که با کیبورد اشتباه نوشته شده تشخیص بده، اما ظاهراً بعضی از لایه‌های امنیتی همون متن رو درست درک نمی‌کنن.

مثلاً یک نفر متن اوکراینی رو با حروف انگلیسی نوشته بود. خود مدل متوجه شد منظور چی بوده و طبق درخواست کاربر پاسخ داد.

بعد همین روش روی کلمات حساس امتحان شد و مدل تونست کلمه‌ای رو تکرار کنه که در حالت عادی توسط فیلترهای امنیتی مسدود می‌شه.

حتی در یک تست دیگه، درخواست کمک برای هک کردن یک سایت با ادعای مالک بودن مطرح شد. مدل در این حالت هم پاسخ مثبت داد، در حالی که چنین ادعایی به‌تنهایی قابل اعتماد نیست و می‌تونه جعلی باشه.

چیزی که برای من مهم‌تره، خود این bypass نیست.

مشکل اصلی اینجاست که ما معمولاً تصور می‌کنیم اگر مدل یک درخواست خطرناک رو تشخیص بده، پس سیستم امنه. در حالی که امنیت یک مدل فقط به خود LLM وابسته نیست.

بین ورودی کاربر، فیلترهای امنیتی، tokenizer، مدل، ابزارها و خروجی، چندین لایه وجود داره. اگر یکی از این لایه‌ها متن رو به شکل متفاوتی تفسیر کنه، ممکنه یک شکاف ایجاد بشه.

این مورد هم ظاهراً universal نیست و فقط روی بعضی ترکیب‌های زبان و layout جواب می‌ده؛ بنابراین نباید ازش نتیجه گرفت که یک روش عمومی برای دور زدن امنیت Astra وجود داره.

ولی دقیقاً همین نکته برای من جالبه:

هرچه مدل‌ها در درک زبان، نویسه‌های غیرمعمول و ورودی‌های مبهم قوی‌تر می‌شن، فیلترهای امنیتی هم باید همون سطح از درک رو داشته باشن.

اگر مدل ورودی رو می‌فهمه ولی guardrail نه، عملاً قوی‌ترین بخش سیستم می‌تونه از ضعیف‌ترین بخش امنیتی جلو بزنه.

به نظرم این یکی از چالش‌های جدی امنیت LLMها در آینده است: امنیت باید هم‌پای قابلیت‌های مدل رشد کنه، نه اینکه چند قدم عقب‌تر باشه.

#امنیت_هوش_مصنوعی
#امنیت_سایبری
#مدل_زبانی

#AI
#LLMSecurity
#AIsecurity

پ.ن: واقعاً نمی‌فهمم چرا برای تست کردن Astra باید از سلاح بیولوژیکی شروع کرد

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

اگر قراره امنیت یک مدل جدی گرفته بشه، فقط نباید ببینیم خود مدل چه چیزی رو متوجه می‌شه؛ باید ببینیم تمام لایه‌های اطرافش هم همون ورودی رو چطور تفسیر می‌کنن.

وگرنه ممکنه قوی‌ترین بخش سیستم، دقیقاً از ضعیف‌ترین بخش امنیتی جلو بزنه.

دوباره یک نوشته جدید از Dario Amodei منتشر شده و این بار حرف اصلیش خیلی جدی‌تر از بحث‌های معمول درباره آینده AI هست.

آمودی معتقده سرعت پیشرفت هوش مصنوعی باید کاهش پیدا کنه.

دلیلش هم اینه که مدل‌ها با سرعت زیادی در حال قوی‌تر شدن هستن و در کنارش، نمونه‌هایی از رفتارهای غیرقابل‌کنترل هم بیشتر مورد توجه قرار گرفتن.

اما چیزی که برای من جالب بود اینه که آمودی صرفاً درباره خطرات AI صحبت نکرده و یک برنامه مشخص برای کند کردن توسعه مدل‌های پیشرفته پیشنهاد داده؛ برنامه‌ای که Anthropic هم اعلام کرده برای اجرای اون آماده است.

از طرف دیگه، دیدگاه خودش نسبت به آینده کاملاً بدبینانه نیست؛ اتفاقاً برعکس.

آمودی پیش‌بینی می‌کنه که در ۵ تا ۱۰ سال آینده AI می‌تونه در درمان بخش بزرگی از بیماری‌های جدی نقش داشته باشه، رشد اقتصادی رو به‌شدت سریع‌تر کنه و ما رو به سمت دوره‌ای از فراوانی و فرصت‌های جدید ببره.

حتی از باز شدن مسیرهای جدید برای دموکراسی و آزادی هم صحبت می‌کنه.


#هوش_مصنوعی
#آینده_تکنولوژی
#ایمنی_هوش_مصنوعی

#AI
#AGI
#AISafety

پ.ن: من با پیش‌بینی‌های ۵ یا ۱۰ ساله درباره درمان اکثر بیماری‌ها یا رسیدن به «دنیای فراوانی» خیلی محتاطم. این‌ها ادعاهای بزرگی هستن و به شواهد بیشتری نیاز دارن.

یه داستان عجیب درباره آینده هوش مصنوعی دیدم که به نظرم ارزش کمی دقیق‌تر نگاه کردن داره.

شخص Jacob Coxon، پژوهشگری که روی pretraining مدل‌ها در OpenAI و بعد Anthropic کار کرده، اخیراً از کارش خارج شده و هشدار داده که شرکت‌های بزرگ AI با سرعت زیادی دارن به سمت سیستم‌های خودبهبوددهنده و در نهایت superintelligence حرکت می‌کنن.

نگرانی اصلیش هم خود پیشرفت AI نیست؛ مسئله اینه که رقابت بین شرکت‌ها ممکنه باعث بشه امنیت و کنترل سیستم‌ها عقب بمونه.

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

اما بخش عجیب داستان اینجاست.
پست این پژوهشگر که قبل از این خیلی شناخته‌شده نبود، ناگهان صدها میلیون بازدید گرفت و همین باعث شد بعضی‌ها درباره احتمال یک کمپین از قبل طراحی‌شده برای وایرال کردنش سؤال مطرح کنن.

خود Coxon این موضوع رو رد کرده و فعلاً هم مدرک محکمی برای ساختگی بودن این ماجرا وجود نداره. بنابراین به نظرم بهتره بین «چیزی که می‌دونیم» و «حدس‌هایی که درباره پشت پرده زده می‌شه» تفاوت قائل بشیم.

اما قسمت دیگری که برای من جالب‌تره، چین هست.

در حالی که بعضی از چهره‌های اصلی AI در آمریکا دارن درباره کند کردن رقابت هشدار می‌دن، چین همچنان روی توسعه سریع مدل‌های قدرتمند و در دسترس‌تر، مخصوصاً مدل‌های open-weight، تأکید داره.

البته طبیعتاً چین هم منافع استراتژیک خودش رو داره و نمی‌شه این سیاست رو صرفاً از زاویه خیر عمومی دید.

ولی نتیجه واقعاً جالبه:
آمریکایی‌ها نگرانن که AI بیش از حد سریع پیش بره و از کنترل خارج بشه؛ چین نمی‌خواد از این رقابت عقب بمونه.

و اینجا یک سؤال سخت شکل می‌گیره:
اگر یک کشور سرعتش رو کم کنه تا ایمنی بیشتری داشته باشه، ولی رقیبش این کار رو نکنه، آیا واقعاً می‌تونه سرعت رو کم کنه؟
به نظرم آینده AI فقط رقابت بین مدل‌ها نیست؛ رقابت بین سیاست‌های توسعه، امنیت و حتی فلسفه‌های متفاوت درباره مالکیت و دسترسی به هوش مصنوعیه.

#هوش_مصنوعی
#آینده_تکنولوژی
#ایمنی_هوش_مصنوعی
#AI
#AGI
#AISafety

چند تا دمو از Astra که به نظرم ارزش دیدن دارن رو براتون میفرستم لذت ببرید

دموی اول
#Astra

دموی دوم
#Astra

دموی سوم
#Astra

مایکروسافت یک قدم جدی دیگه با Rust برداشت.

طبق اعلام یکی از مهندسان ارشد بخش ابزارهای توسعه مایکروسافت، Rust حالا به یکی از زبان‌های اصلی توسعه داخلی این شرکت تبدیل شده و در کنار C++، C# و TypeScript قرار گرفته.

نکته جالب‌تر اینه که این فقط یک تصمیم روی کاغذ نیست. مایکروسافت همین حالا از Rust در بخش‌هایی از Windows، Office و حتی Copilot استفاده می‌کنه.
به نظرم مهم‌ترین بخش خبر همین‌جاست.

سال‌ها C و C++ انتخاب اصلی برای بخش‌هایی بودن که performance و کنترل پایین‌سطح اهمیت داشت. ولی مشکل memory safety همیشه یکی از چالش‌های بزرگ این حوزه بوده.

راست دقیقاً اینجا وارد می‌شه؛ سعی می‌کنه performance نزدیک به زبان‌های سیستم‌سطح رو نگه داره، ولی بخش بزرگی از خطاهای مربوط به memory safety رو در زمان کامپایل کنترل کنه.

اینکه مایکروسافت Rust رو در کنار C++ و C# و TypeScript به‌عنوان یکی از زبان‌های اصلی داخلی خودش قرار داده، به نظرم نشون می‌ده جایگاه Rust داره از «زبان جذاب برای پروژه‌های جدید» به «ابزار جدی برای زیرساخت و محصولات بزرگ» تغییر می‌کنه.

البته این به معنی کنار گذاشتن C++ نیست. برای چنین شرکتی احتمالاً سال‌ها باید هر دو زبان کنار هم وجود داشته باشن.

ولی برای کسی که می‌خواد وارد حوزه‌هایی مثل سیستم‌پروگرمینگ، امنیت، زیرساخت یا نرم‌افزارهای performance-critical بشه، به نظرم Rust دیگه زبانی نیست که بشه خیلی راحت نادیده‌اش گرفت.

راست کم‌کم داره جای خودش رو پیدا می‌کنه. 🦀

#برنامه_نویسی
#راست
#مایکروسافت
#Rust
#Microsoft
#SoftwareEngineering

یکی از برنده‌های مدال فیلدز، یو دنگ، یه شوخی جالب درباره آینده ریاضی با AI کرده.

گفته اگر هوش مصنوعی بتونه تمام مسائل ریاضی رو حل کنه، خودش می‌ره خونه و شروع می‌کنه به نوشتن رمان عاشقانه.

ولی پشت این شوخی یه نکته جدی وجود داره.

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

به نظرم این موضوع فقط درباره ریاضی نیست.

هر بار که یک ابزار قدرتمند وارد یک حوزه می‌شه، بخشی از کارهای قبلی کم‌ارزش‌تر می‌شن و در عوض سؤال‌های جدیدی به وجود میان.

مثلاً اگر AI بتونه مسئله‌ای رو که چند روز طول می‌کشیده در چند ثانیه حل کنه، احتمالاً ارزش اصلی دیگه فقط «حل کردن» نیست؛ شاید انتخاب مسئله درست، تعریف مسئله، پیدا کردن مسیرهای جدید و فهمیدن اینکه نتیجه دقیقاً چه معنایی داره مهم‌تر بشه.

شاید در آینده ریاضی‌دان‌ها کمتر وقتشون رو صرف محاسبه کنن و بیشتر وقتشون رو صرف سؤال‌هایی کنن که هنوز حتی نمی‌دونیم باید بپرسیم.

و البته اگر AI واقعاً همه مسائل ریاضی رو حل کرد...


#هوش_مصنوعی
#ریاضی
#آینده_تکنولوژی
#AI
#Mathematics
#FutureOfAI

امروز به نظرم یکی از قشنگ‌ترین سایت‌هایی که اخیراً دیدم رو پیدا کردم.

https://kubernetes3d.com/rack

توی این سایت یک کلاستر Kubernetes رو تبدیل کردن به یک Rack سرور سه‌بعدی و تقریباً با همه‌چیز می‌شه تعامل داشت.

سه نمای مختلف هم داره: از جلو، پشت و کنار.

جالب‌تر اینه که هر نما همون کلاستر رو از یک زاویه متفاوت نشون می‌ده و کمک می‌کنه بهتر بفهمیم اجزای مختلف چطور به هم وصل شدن و ارتباط دارن.

دکمه‌ها، سناریوها و حتی المان‌های داخل صفحه هم تعاملی هستن.

یعنی صرفاً یک دمو برای قشنگی نیست؛ می‌تونه واقعاً برای یادگیری Kubernetes هم مفید باشه.

من خودم یه مدت اونجا داشتم همه‌چی رو کلیک می‌کردم. 😂

واقعاً بعضی وقت‌ها یک نفر میاد یک مفهوم فنی نسبتاً خشک رو این‌طوری تبدیل می‌کنه به چیزی که آدم دوست داره فقط بشینه و باهاش بازی کنه.

به نظرم این سایت یه جورایی ترکیب مهندسی و هنره. 🎨☸️

اصلاً چه کسی اینو ساخته؟