به انتهای روز که می‌رسی، یه حس عجیبی میاد سراغت: «من امروز واقعاً کار کردم یا فقط الکی وقت گذروندم؟»
شما هم اینطوری هستید یا فقط منم؟

این حس بیشتر موقعی سراغم میاد که کل روز کد نزدم و چسبیدم به داکیومنت‌بازی، نوشتنِ مستندات، ویرایش یا تحقیق.
ما ناخودآگاه عادت کردیم به اینکه وقتی هر روز کد می‌زنیم (حتی با کمک هوش مصنوعی)، نتیجه جلوی ما مشخص هست: حجم زیادی از فایل‌های وایب‌کدشده یا پول‌ریکوئست‌های (PR) مرج‌شده.

اما وقتی روی مستندات کار می‌کنی، در بهترین حالت انتهای روز یکی دو تا سند تحویل می‌دهی و این فکر سمّی در سرت میپیچه که: «خب که چی؟ این‌ها رو نوشتی که چی بشه؟ اصلاً کار جدی‌ای نکردی که! مدرکی براش نداری!»

در حالی که مغزت کاملاً متوجه هست که کل روز کار کرده‌ای، خسته‌ای و کله‌ات سوت کشیده.

شما هم با این قضیه درگیر میشین ؟ اگر آره، چطور باهاش کنار میاین؟

یک سری منبع کاربردی براتون پیدا کردم، گفتم اینجا به اشتراک بذارم:

مورد اول: aicss.dev — بلاک‌های UI برای تعاملاتِ ایجنت‌های هوش مصنوعی
مورد دوم: ui.halaska.com — کامپوننت‌های رابط کاربری برای محصولات مبتنی بر AI
مورد سوم: bencho.dev — بلاک‌های UI برای تجربه‌های تعاملیِ هوش مصنوعی
مورد چهارم: builtbydesigners.com — ویترینِ محصولاتی که طراحان ساختارشان را دیزاین کرده‌اند
مورد پنجم: torph.lochie.me — کتابخانه متن‌مورفینگ (morphing) بدون هیچ وابستگی (Zero dependencies)
مورد ششم: typehug.aliszu.com — ابزار تایپوگرافی برای کنار هم چسباندن و نگه داشتن کلمات

شما خودتون از این‌ها توی پروژه‌هاتون استفاده کردید، یا فقط دارید لینک جمع می‌کنید برای پروژه‌های بعدی؟ :)

یک زمانی پایپ‌لاین CI/CD گیت‌هاب اکشنزِ من شده بود ۱۵ الی ۱۸ دقیقه.
بعد تازه دوزاری‌ام افتاد که کلی از این زمان داره الکی میره روی کارهای تکراری:

هر پوش یعنی: اجرای دوباره‌ی npm install
دانلود دوباره‌ی تمام وابستگی‌ها (Dependencies)
ری‌بیلد کردن کل اسکریپت‌های بیلد از صفر
حتی وقتی فقط چند خط کد رو تغییر داده بودم.

شما هم درگیر این کُندی‌های وقت‌تلف‌کن توی CI/CD هستین یا براتون خیلی اهمیتی نداره ؟

شب‌ها اتوماسیون و کارِ سنگین رو می‌سپاریم دست سیستم، صبح‌ها کار رو پیش می‌بریم، بعدازظهر هم کلاً می‌بندیم میریم سراغ چمن لمس کردن و استراحت و کوه

یه مطلب جالب درباره امنیت زنجیره تأمین مدل‌های هوش مصنوعی خوندم که به نظرم ارزش گفتن داشت.

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

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

مثلاً Hugging Face خودش درباره فایل‌های pickle هشدار داده، چون باز کردن این فایل‌ها می‌تونه باعث اجرای دستوراتی بشه که داخل فایل قرار داده شده. به همین دلیل هم مکانیزم بررسی این فایل‌ها رو داره و فرمت امن‌تری مثل safetensors رو پیشنهاد می‌کنه.

یه نمونه جالب‌تر هم توسط HiddenLayer گزارش شده؛ مهاجم با یک فایل مخرب PyTorch تونسته بود سرویس تبدیل مدل Hugging Face رو هدف قرار بده، توکن ربات رسمی رو به دست بیاره و حتی از طرف اون ربات درخواست تغییر ثبت کنه.

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

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

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

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

در واقع باید دو بخش رو جداگانه محافظت کنیم:

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

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

چند کار ساده هم می‌تونه ریسک رو خیلی کمتر کنه:

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

۲. تا جای ممکن از قالب‌های ناامن برای مدل‌ها استفاده نکنیم.

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

۴. دسترسی عامل‌ها رو تا حد ممکن محدود کنیم.

۵. دسترسی به کلیدها، رمزها و اطلاعات حساس رو از عامل‌ها جدا کنیم.

۶. اجرای ابزارها رو هم مثل خود مدل، بخشی از سطح حمله در نظر بگیریم.
به نظرم با گسترش عامل‌های هوش مصنوعی، «امنیت مدل» دیگه به‌تنهایی کافی نیست.

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

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

#AIAgents
#AI

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

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

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

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

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

حتی طراحی یک سیستم جدید با کمک AI هم بدون دانش کافی ساده نیست؛ چه برسه به بازطراحی یک سیستم قدیمی که باید اول معماری فعلیش رو عمیقاً بفهمی.

به نظرم مهارت اصلی در آینده این نیست که «چقدر خوب با AI کار می‌کنی».

مهارت اصلی اینه که بتونی تشخیص بدی:

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

در نهایت چیزی که این توانایی رو می‌سازه، قضاوت مهندسیه.

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

#AI

یه افزونه جالب برای Burp Suite پیدا کردم که برای بررسی فایل‌های JavaScript ساخته شده.

اسمش Burp JS LinkFinder Enhanced هست و هدفش پیدا کردن لینک‌ها، مسیرهای مخفی و اطلاعات حساس داخل فایل‌های JavaScript هست.

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

این افزونه می‌تونه در کنار Burp Suite این موارد رو سریع‌تر استخراج کنه و به پیدا کردن سطح حمله برنامه کمک کنه.

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

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

اگر با Burp Suite کار می‌کنید، ارزش امتحان کردن داره.


https://github.com/panchocosil/burp-js-linkfinder-enhanced

یه ابزار جالب به اسم FlareProx دیدم که از زیرساخت Cloudflare برای ساخت پراکسی‌های عبوری HTTP استفاده می‌کنه.

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

از متدهای مختلف HTTP مثل GET، POST، PUT، DELETE، PATCH، OPTIONS و HEAD پشتیبانی می‌کنه و راه‌اندازیش هم ظاهراً خیلی ساده‌ست.
یکی از نکات جالبش استفاده از شبکه گسترده Cloudflare و محدودیت رایگان حدود ۱۰۰ هزار درخواست در روزه.

به نظرم برای آزمایش‌های امنیتی، بررسی رفتار سرویس‌ها و ساخت محیط‌های تست می‌تونه ابزار جالبی باشه.

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


https://github.com/MrTurvey/flareprox

یه ابزار جالب برای تست امنیت 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 که به نظرم ارزش دیدن دارن رو براتون میفرستم لذت ببرید