بچه‌ها، یه توصیه دوستانه و صمیمانه دارم برای کسایی که تازه دارن وارد دنیای AI و Agentها میشن.
به نظرم برای شروع، لازم نیست ده‌ها دوره و ویدیو و roadmap جمع کنین. چندتا چیز خیلی ساده‌تر از این حرفاست.
اول از همه، تمرین کنین.
یه Agent خوب داشته باشین و شروع کنین به کار کردن باهاش. نه اینکه از همون اول بخواین Agent بسازین؛ اول سعی کنین بفهمین همین ابزارهایی که الان وجود دارن چطور کار می‌کنن.
مثلاً باهاش یه کار واقعی انجام بدین، بعد ازش بخواین توضیح بده چطور به نتیجه رسیده، چه ابزارهایی استفاده کرده و چه مسیری رو طی کرده.
دوم، باید یه دید درست از هسته‌ی این سیستم‌ها پیدا کنین.
مهم‌ترین چیز اینه که بدونین تفاوت بین مدل و Context چیه، Agent Loop چطور کار می‌کنه و مدل چطور از Toolها استفاده می‌کنه.
خیلی ساده اگر بخوایم نگاه کنیم:
شما قبل از هر درخواست، یه Context در اختیار مدل می‌ذارین؛ پرامپت، فایل‌ها، تاریخچه، Toolها و هر چیزی که برای حل مسئله لازمه.
بعد مدل با توجه به همین Context تصمیم می‌گیره چه کاری باید انجام بده.
ممکنه یک Tool رو صدا بزنه، نتیجه رو ببینه، دوباره تصمیم بگیره، Tool دیگه‌ای رو اجرا کنه و همین چرخه ادامه پیدا کنه تا در نهایت به جواب برسه یا از شما سؤال بپرسه.
وقتی این چرخه رو بفهمین، خیلی از چیزهایی که اولش شبیه جادو به نظر میاد، دیگه اون‌قدر عجیب نیست.
این قسمت رو واقعاً جدی بگیرین.
از Agentتون بخواین Agent Loop خودش رو براتون توضیح بده. ازش بخواین مثال بزنه، مقاله و ویدیو پیدا کنه و چند ساعت باهاش کلنجار برین.
لازم نیست از همون اول برین سراغ ده‌ها فریم‌ورک و ابزار مختلف. اول همین چند مفهوم پایه رو درست بفهمین.
سوم، AI رو وارد کاری کنین که همین الان انجام میدین.
اگر برنامه‌نویسین، باهاش کد بزنین.
اگر طراحین، کارهای طراحی خودتون رو باهاش سریع‌تر کنین.
اگر تولید محتوا می‌کنین، ازش برای تحقیق، ایده‌پردازی یا آماده‌سازی محتوا استفاده کنین.
لازم نیست همه برنامه‌نویس بشن و یه SaaS بسازن.
به نظرم هدف اصلی این نیست که یه حرفه‌ی جدید رو از صفر شروع کنین؛ هدف اینه که کاری که همین الان بلدین رو با کمک AI بهتر و سریع‌تر انجام بدین.
بعد که یه کار رو چند بار انجام دادین، می‌تونین همون روند رو تبدیل به Skill یا Workflow کنین و کم‌کم سطح اتوماسیون رو بالاتر ببرین.
و چهارم، تنها پیش نرین.
وارد کامیونیتی‌ها و چت‌ها بشین. سؤال بپرسین، کارهاتون رو نشون بدین، ببینین بقیه چطور مسئله‌ها رو حل می‌کنن و از تجربه‌شون استفاده کنین.
اتفاقاً خیلی وقت‌ها چیزهایی که توی چت‌ها یاد می‌گیرین، توی هیچ دوره‌ای پیدا نمی‌کنین.
ولی در نهایت، به نظرم مهم‌ترین نکته اینه:
این AI رو جایگزین فهمیدن نکنین.
بذارین ابزار، دست شما رو بلندتر کنه؛ نه اینکه خودتون رو از کاری که انجام میدین جدا کنه.
من خودم دوست دارم بدونم چیزی که دارم می‌سازم چطور کار می‌کنه.
دوست دارم باهاش درگیر باشم، اشتباه کنم، بفهمم چرا اشتباه کردم و بعد دوباره درستش کنم.
چون وقتی همه‌چیز رو به AI می‌سپارین، شاید سریع‌تر بشین؛ ولی ممکنه کم‌کم ارتباطتون با کاری که انجام میدین هم کمتر بشه.
به نظرم بهترین حالت اینه که AI سرعت و توانایی‌تون رو چند برابر کنه، ولی همچنان خودتون پشت فرمون باشین.
لازم نیست همه‌چیز رو بدونین.
فقط کنجکاو باشین، بسازین، خراب کنین و دوباره بسازین.
بقیه‌ش کم‌کم میاد.
#توصیه
#مسیر
#AIAgents
به نظرم برای شروع، لازم نیست ده‌ها دوره و ویدیو و roadmap جمع کنین. چندتا چیز خیلی ساده‌تر از این حرفاست.
اول از همه، تمرین کنین.
یه Agent خوب داشته باشین و شروع کنین به کار کردن باهاش. نه اینکه از همون اول بخواین Agent بسازین؛ اول سعی کنین بفهمین همین ابزارهایی که الان وجود دارن چطور کار می‌کنن.
مثلاً باهاش یه کار واقعی انجام بدین، بعد ازش بخواین توضیح بده چطور به نتیجه رسیده، چه ابزارهایی استفاده کرده و چه مسیری رو طی کرده.
دوم، باید یه دید درست از هسته‌ی این سیستم‌ها پیدا کنین.
مهم‌ترین چیز اینه که بدونین تفاوت بین مدل و Context چیه، Agent Loop چطور کار می‌کنه و مدل چطور از Toolها استفاده می‌کنه.
خیلی ساده اگر بخوایم نگاه کنیم:
شما قبل از هر درخواست، یه Context در اختیار مدل می‌ذارین؛ پرامپت، فایل‌ها، تاریخچه، Toolها و هر چیزی که برای حل مسئله لازمه.
بعد مدل با توجه به همین Context تصمیم می‌گیره چه کاری باید انجام بده.
ممکنه یک Tool رو صدا بزنه، نتیجه رو ببینه، دوباره تصمیم بگیره، Tool دیگه‌ای رو اجرا کنه و همین چرخه ادامه پیدا کنه تا در نهایت به جواب برسه یا از شما سؤال بپرسه.
وقتی این چرخه رو بفهمین، خیلی از چیزهایی که اولش شبیه جادو به نظر میاد، دیگه اون‌قدر عجیب نیست.
این قسمت رو واقعاً جدی بگیرین.
از Agentتون بخواین Agent Loop خودش رو براتون توضیح بده. ازش بخواین مثال بزنه، مقاله و ویدیو پیدا کنه و چند ساعت باهاش کلنجار برین.
لازم نیست از همون اول برین سراغ ده‌ها فریم‌ورک و ابزار مختلف. اول همین چند مفهوم پایه رو درست بفهمین.
سوم، AI رو وارد کاری کنین که همین الان انجام میدین.
اگر برنامه‌نویسین، باهاش کد بزنین.
اگر طراحین، کارهای طراحی خودتون رو باهاش سریع‌تر کنین.
اگر تولید محتوا می‌کنین، ازش برای تحقیق، ایده‌پردازی یا آماده‌سازی محتوا استفاده کنین.
لازم نیست همه برنامه‌نویس بشن و یه SaaS بسازن.
به نظرم هدف اصلی این نیست که یه حرفه‌ی جدید رو از صفر شروع کنین؛ هدف اینه که کاری که همین الان بلدین رو با کمک AI بهتر و سریع‌تر انجام بدین.
بعد که یه کار رو چند بار انجام دادین، می‌تونین همون روند رو تبدیل به Skill یا Workflow کنین و کم‌کم سطح اتوماسیون رو بالاتر ببرین.
و چهارم، تنها پیش نرین.
وارد کامیونیتی‌ها و چت‌ها بشین. سؤال بپرسین، کارهاتون رو نشون بدین، ببینین بقیه چطور مسئله‌ها رو حل می‌کنن و از تجربه‌شون استفاده کنین.
اتفاقاً خیلی وقت‌ها چیزهایی که توی چت‌ها یاد می‌گیرین، توی هیچ دوره‌ای پیدا نمی‌کنین.
ولی در نهایت، به نظرم مهم‌ترین نکته اینه:
این AI رو جایگزین فهمیدن نکنین.
بذارین ابزار، دست شما رو بلندتر کنه؛ نه اینکه خودتون رو از کاری که انجام میدین جدا کنه.
من خودم دوست دارم بدونم چیزی که دارم می‌سازم چطور کار می‌کنه.
دوست دارم باهاش درگیر باشم، اشتباه کنم، بفهمم چرا اشتباه کردم و بعد دوباره درستش کنم.
چون وقتی همه‌چیز رو به AI می‌سپارین، شاید سریع‌تر بشین؛ ولی ممکنه کم‌کم ارتباطتون با کاری که انجام میدین هم کمتر بشه.
به نظرم بهترین حالت اینه که AI سرعت و توانایی‌تون رو چند برابر کنه، ولی همچنان خودتون پشت فرمون باشین.
لازم نیست همه‌چیز رو بدونین.
فقط کنجکاو باشین، بسازین، خراب کنین و دوباره بسازین.
بقیه‌ش کم‌کم میاد.
#توصیه
#مسیر
#AIAgents
👌1
CodeNeuron
بچه‌ها، یه توصیه دوستانه و صمیمانه دارم برای کسایی که تازه دارن وارد دنیای AI و Agentها میشن. به نظرم برای شروع، لازم نیست ده‌ها دوره و ویدیو و roadmap جمع کنین. چندتا چیز خیلی ساده‌تر از این حرفاست. اول از همه، تمرین کنین. یه Agent خوب داشته باشین و شروع…
پ.ن: یه چیز دیگه هم به نظرم خیلی مهمه؛ یه پروژه‌ای که مدت‌هاست توی ذهنتونه، یا یه ایده‌ی جالب که واقعاً دوست دارین بسازینش پیدا کنین.
یه چیزی که دلتون بخواد بشینین پاش و روش کار کنین؛ و اگه در نهایت بتونه براتون درآمد هم داشته باشه که چه بهتر.
وقتی یه پروژه‌ی واقعی داشته باشین که واقعاً براتون مهم باشه، انگیزه‌ی خیلی بیشتری برای نشستن، یاد گرفتن، خراب کردن و دوباره ساختنش پیدا می‌کنین.
به نظرم خیلی بهتر از اینه که فقط بشینین یه سری آموزش ببینین و منتظر باشین یه روز «آماده» بشین.
یه چیزی که دلتون بخواد بشینین پاش و روش کار کنین؛ و اگه در نهایت بتونه براتون درآمد هم داشته باشه که چه بهتر.
وقتی یه پروژه‌ی واقعی داشته باشین که واقعاً براتون مهم باشه، انگیزه‌ی خیلی بیشتری برای نشستن، یاد گرفتن، خراب کردن و دوباره ساختنش پیدا می‌کنین.
به نظرم خیلی بهتر از اینه که فقط بشینین یه سری آموزش ببینین و منتظر باشین یه روز «آماده» بشین.
🔥1
Forwarded from IranServer | ایران سرور
KWYPiransvGSZYacademyto100_kjuyaBUG-SUMMER1405_KKFQDOWETZBUG-SUMMER1405_NGFKFKCWZG⏱️ مهلت استفاده از این کدها فقط تا ساعت 22 امشب
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
به انتهای روز که می‌رسی، یه حس عجیبی میاد سراغت: «من امروز واقعاً کار کردم یا فقط الکی وقت گذروندم؟»
شما هم اینطوری هستید یا فقط منم؟
این حس بیشتر موقعی سراغم میاد که کل روز کد نزدم و چسبیدم به داکیومنت‌بازی، نوشتنِ مستندات، ویرایش یا تحقیق.
ما ناخودآگاه عادت کردیم به اینکه وقتی هر روز کد می‌زنیم (حتی با کمک هوش مصنوعی)، نتیجه جلوی ما مشخص هست: حجم زیادی از فایل‌های وایب‌کدشده یا پول‌ریکوئست‌های (PR) مرج‌شده.
اما وقتی روی مستندات کار می‌کنی، در بهترین حالت انتهای روز یکی دو تا سند تحویل می‌دهی و این فکر سمّی در سرت میپیچه که: «خب که چی؟ این‌ها رو نوشتی که چی بشه؟ اصلاً کار جدی‌ای نکردی که! مدرکی براش نداری!»
در حالی که مغزت کاملاً متوجه هست که کل روز کار کرده‌ای، خسته‌ای و کله‌ات سوت کشیده.
شما هم با این قضیه درگیر میشین ؟ اگر آره، چطور باهاش کنار میاین؟
شما هم اینطوری هستید یا فقط منم؟
این حس بیشتر موقعی سراغم میاد که کل روز کد نزدم و چسبیدم به داکیومنت‌بازی، نوشتنِ مستندات، ویرایش یا تحقیق.
ما ناخودآگاه عادت کردیم به اینکه وقتی هر روز کد می‌زنیم (حتی با کمک هوش مصنوعی)، نتیجه جلوی ما مشخص هست: حجم زیادی از فایل‌های وایب‌کدشده یا پول‌ریکوئست‌های (PR) مرج‌شده.
اما وقتی روی مستندات کار می‌کنی، در بهترین حالت انتهای روز یکی دو تا سند تحویل می‌دهی و این فکر سمّی در سرت میپیچه که: «خب که چی؟ این‌ها رو نوشتی که چی بشه؟ اصلاً کار جدی‌ای نکردی که! مدرکی براش نداری!»
در حالی که مغزت کاملاً متوجه هست که کل روز کار کرده‌ای، خسته‌ای و کله‌ات سوت کشیده.
شما هم با این قضیه درگیر میشین ؟ اگر آره، چطور باهاش کنار میاین؟
😁2
یک سری منبع کاربردی براتون پیدا کردم، گفتم اینجا به اشتراک بذارم:
مورد اول: aicss.dev — بلاک‌های UI برای تعاملاتِ ایجنت‌های هوش مصنوعی
مورد دوم: ui.halaska.com — کامپوننت‌های رابط کاربری برای محصولات مبتنی بر AI
مورد سوم: bencho.dev — بلاک‌های UI برای تجربه‌های تعاملیِ هوش مصنوعی
مورد چهارم: builtbydesigners.com — ویترینِ محصولاتی که طراحان ساختارشان را دیزاین کرده‌اند
مورد پنجم: torph.lochie.me — کتابخانه متن‌مورفینگ (morphing) بدون هیچ وابستگی (Zero dependencies)
مورد ششم: typehug.aliszu.com — ابزار تایپوگرافی برای کنار هم چسباندن و نگه داشتن کلمات
شما خودتون از این‌ها توی پروژه‌هاتون استفاده کردید، یا فقط دارید لینک جمع می‌کنید برای پروژه‌های بعدی؟ :)
مورد اول: aicss.dev — بلاک‌های UI برای تعاملاتِ ایجنت‌های هوش مصنوعی
مورد دوم: ui.halaska.com — کامپوننت‌های رابط کاربری برای محصولات مبتنی بر AI
مورد سوم: bencho.dev — بلاک‌های UI برای تجربه‌های تعاملیِ هوش مصنوعی
مورد چهارم: builtbydesigners.com — ویترینِ محصولاتی که طراحان ساختارشان را دیزاین کرده‌اند
مورد پنجم: torph.lochie.me — کتابخانه متن‌مورفینگ (morphing) بدون هیچ وابستگی (Zero dependencies)
مورد ششم: typehug.aliszu.com — ابزار تایپوگرافی برای کنار هم چسباندن و نگه داشتن کلمات
شما خودتون از این‌ها توی پروژه‌هاتون استفاده کردید، یا فقط دارید لینک جمع می‌کنید برای پروژه‌های بعدی؟ :)
👌1
یک زمانی پایپ‌لاین CI/CD گیت‌هاب اکشنزِ من شده بود ۱۵ الی ۱۸ دقیقه.
بعد تازه دوزاری‌ام افتاد که کلی از این زمان داره الکی میره روی کارهای تکراری:
هر پوش یعنی: اجرای دوباره‌ی
دانلود دوباره‌ی تمام وابستگی‌ها (Dependencies)
ری‌بیلد کردن کل اسکریپت‌های بیلد از صفر
حتی وقتی فقط چند خط کد رو تغییر داده بودم.
شما هم درگیر این کُندی‌های وقت‌تلف‌کن توی CI/CD هستین یا براتون خیلی اهمیتی نداره ؟
بعد تازه دوزاری‌ام افتاد که کلی از این زمان داره الکی میره روی کارهای تکراری:
هر پوش یعنی: اجرای دوباره‌ی
npm installدانلود دوباره‌ی تمام وابستگی‌ها (Dependencies)
ری‌بیلد کردن کل اسکریپت‌های بیلد از صفر
حتی وقتی فقط چند خط کد رو تغییر داده بودم.
شما هم درگیر این کُندی‌های وقت‌تلف‌کن توی CI/CD هستین یا براتون خیلی اهمیتی نداره ؟
👌1
شب‌ها اتوماسیون و کارِ سنگین رو می‌سپاریم دست سیستم، صبح‌ها کار رو پیش می‌بریم، بعدازظهر هم کلاً می‌بندیم میریم سراغ چمن لمس کردن و استراحت و کوه
❤1
یه مطلب جالب درباره امنیت زنجیره تأمین مدل‌های هوش مصنوعی خوندم که به نظرم ارزش گفتن داشت.
معمولاً وقتی درباره امنیت مدل‌های هوش مصنوعی حرف می‌زنیم، ذهنمون میره سمت خود مدل؛ ولی مشکل فقط مدل نیست.
کتابخانه‌ها، فایل‌های مدل، داده‌ها، سرویس‌های تبدیل، ابزارها و حتی سیستم‌هایی که مدل داخلشون اجرا میشه، همگی می‌تونن بخشی از مسیر حمله باشن.
مثلاً Hugging Face خودش درباره فایل‌های pickle هشدار داده، چون باز کردن این فایل‌ها می‌تونه باعث اجرای دستوراتی بشه که داخل فایل قرار داده شده. به همین دلیل هم مکانیزم بررسی این فایل‌ها رو داره و فرمت امن‌تری مثل safetensors رو پیشنهاد می‌کنه.
یه نمونه جالب‌تر هم توسط HiddenLayer گزارش شده؛ مهاجم با یک فایل مخرب PyTorch تونسته بود سرویس تبدیل مدل Hugging Face رو هدف قرار بده، توکن ربات رسمی رو به دست بیاره و حتی از طرف اون ربات درخواست تغییر ثبت کنه.
یعنی حمله فقط به «مدل» انجام نشده؛ بلکه به سرویس مورد اعتمادی انجام شده که اطراف مدل قرار داشته.
برای عامل‌های هوش مصنوعی این موضوع جدی‌تر هم میشه. چون عامل فقط متن تولید نمی‌کنه؛ ممکنه به فایل، API، مخزن کد، سیستم ساخت و استقرار یا ابزارهای مختلف دسترسی داشته باشه.
حالا تصور کنید یک صفحه وب، فایل یا داده‌ای که عامل می‌خونه، حاوی دستور مخربی باشه. اگر عامل بدون بررسی به اون اعتماد کنه، ممکنه کاری انجام بده که کاربر اصلاً درخواست نکرده.
اینجا یک اشتباه رایج وجود داره: فکر کنیم اگر خود مدل رو ایمن کنیم، کل سیستم امن شده.
در واقع باید دو بخش رو جداگانه محافظت کنیم:
یکی زنجیره تأمین مدل؛ یعنی منبع مدل، داده‌ها، فایل وزن‌ها، صحت فایل و سابقه تغییرات.
دومی لایه اجرای عامل؛ یعنی اینکه عامل به چه ابزارهایی دسترسی داره، چه دستوری می‌تونه اجرا کنه و چه اطلاعاتی می‌تونه بخونه یا تغییر بده.
چند کار ساده هم می‌تونه ریسک رو خیلی کمتر کنه:
۱. صحت فایل‌های مدل و داده‌ها رو قبل از استفاده بررسی کنیم.
۲. تا جای ممکن از قالب‌های ناامن برای مدل‌ها استفاده نکنیم.
۳. مدل و داده‌ای که منبعش مشخص نیست رو قابل اعتماد فرض نکنیم.
۴. دسترسی عامل‌ها رو تا حد ممکن محدود کنیم.
۵. دسترسی به کلیدها، رمزها و اطلاعات حساس رو از عامل‌ها جدا کنیم.
۶. اجرای ابزارها رو هم مثل خود مدل، بخشی از سطح حمله در نظر بگیریم.
به نظرم با گسترش عامل‌های هوش مصنوعی، «امنیت مدل» دیگه به‌تنهایی کافی نیست.
اگر یک عامل به ابزارهای واقعی دسترسی داشته باشه، یک ورودی مخرب می‌تونه از یک مشکل ساده در متن، تبدیل به دسترسی به فایل‌ها، اطلاعات حساس یا حتی سیستم‌های دیگر بشه.
در نهایت هوش مصنوعی فقط سرعت انجام کارها رو بیشتر نمی‌کنه؛ اگر دسترسی‌ها درست کنترل نشن، سرعت آسیب‌زدن رو هم بیشتر می‌کنه.
#AIAgents
#AI
معمولاً وقتی درباره امنیت مدل‌های هوش مصنوعی حرف می‌زنیم، ذهنمون میره سمت خود مدل؛ ولی مشکل فقط مدل نیست.
کتابخانه‌ها، فایل‌های مدل، داده‌ها، سرویس‌های تبدیل، ابزارها و حتی سیستم‌هایی که مدل داخلشون اجرا میشه، همگی می‌تونن بخشی از مسیر حمله باشن.
مثلاً Hugging Face خودش درباره فایل‌های pickle هشدار داده، چون باز کردن این فایل‌ها می‌تونه باعث اجرای دستوراتی بشه که داخل فایل قرار داده شده. به همین دلیل هم مکانیزم بررسی این فایل‌ها رو داره و فرمت امن‌تری مثل safetensors رو پیشنهاد می‌کنه.
یه نمونه جالب‌تر هم توسط HiddenLayer گزارش شده؛ مهاجم با یک فایل مخرب PyTorch تونسته بود سرویس تبدیل مدل Hugging Face رو هدف قرار بده، توکن ربات رسمی رو به دست بیاره و حتی از طرف اون ربات درخواست تغییر ثبت کنه.
یعنی حمله فقط به «مدل» انجام نشده؛ بلکه به سرویس مورد اعتمادی انجام شده که اطراف مدل قرار داشته.
برای عامل‌های هوش مصنوعی این موضوع جدی‌تر هم میشه. چون عامل فقط متن تولید نمی‌کنه؛ ممکنه به فایل، API، مخزن کد، سیستم ساخت و استقرار یا ابزارهای مختلف دسترسی داشته باشه.
حالا تصور کنید یک صفحه وب، فایل یا داده‌ای که عامل می‌خونه، حاوی دستور مخربی باشه. اگر عامل بدون بررسی به اون اعتماد کنه، ممکنه کاری انجام بده که کاربر اصلاً درخواست نکرده.
اینجا یک اشتباه رایج وجود داره: فکر کنیم اگر خود مدل رو ایمن کنیم، کل سیستم امن شده.
در واقع باید دو بخش رو جداگانه محافظت کنیم:
یکی زنجیره تأمین مدل؛ یعنی منبع مدل، داده‌ها، فایل وزن‌ها، صحت فایل و سابقه تغییرات.
دومی لایه اجرای عامل؛ یعنی اینکه عامل به چه ابزارهایی دسترسی داره، چه دستوری می‌تونه اجرا کنه و چه اطلاعاتی می‌تونه بخونه یا تغییر بده.
چند کار ساده هم می‌تونه ریسک رو خیلی کمتر کنه:
۱. صحت فایل‌های مدل و داده‌ها رو قبل از استفاده بررسی کنیم.
۲. تا جای ممکن از قالب‌های ناامن برای مدل‌ها استفاده نکنیم.
۳. مدل و داده‌ای که منبعش مشخص نیست رو قابل اعتماد فرض نکنیم.
۴. دسترسی عامل‌ها رو تا حد ممکن محدود کنیم.
۵. دسترسی به کلیدها، رمزها و اطلاعات حساس رو از عامل‌ها جدا کنیم.
۶. اجرای ابزارها رو هم مثل خود مدل، بخشی از سطح حمله در نظر بگیریم.
به نظرم با گسترش عامل‌های هوش مصنوعی، «امنیت مدل» دیگه به‌تنهایی کافی نیست.
اگر یک عامل به ابزارهای واقعی دسترسی داشته باشه، یک ورودی مخرب می‌تونه از یک مشکل ساده در متن، تبدیل به دسترسی به فایل‌ها، اطلاعات حساس یا حتی سیستم‌های دیگر بشه.
در نهایت هوش مصنوعی فقط سرعت انجام کارها رو بیشتر نمی‌کنه؛ اگر دسترسی‌ها درست کنترل نشن، سرعت آسیب‌زدن رو هم بیشتر می‌کنه.
#AIAgents
#AI
🔥1
یه جمله دیدم که به نظرم خیلی خوب اصل ماجرا درباره برنامه‌نویسی با هوش مصنوعی رو توضیح میده.
اینکه بتونی با AI حرف بزنی یا چندین عامل هوش مصنوعی رو همزمان اجرا کنی، به‌تنهایی مهارت خیلی خاصی نیست.
مشکل اصلی اینجاست که وقتی هوش مصنوعی برات کد تولید می‌کنه، باید خودت بتونی بفهمی این کد واقعاً خوبه یا نه.
باید برنامه‌نویسی بلد باشی، مبانی علوم کامپیوتر رو بفهمی و تجربه کافی داشته باشی تا بتونی خروجی AI رو بررسی کنی.
چون بخش زیادی از کدی که مدل‌ها تولید می‌کنن، مخصوصاً وقتی پروژه بزرگ‌تر و جدی‌تر میشه، ممکنه فقط ظاهراً درست باشه و در عمل پر از تصمیم‌های بد، پیچیدگی اضافه یا مشکلات معماری باشه.
حتی طراحی یک سیستم جدید با کمک AI هم بدون دانش کافی ساده نیست؛ چه برسه به بازطراحی یک سیستم قدیمی که باید اول معماری فعلیش رو عمیقاً بفهمی.
به نظرم مهارت اصلی در آینده این نیست که «چقدر خوب با AI کار می‌کنی».
مهارت اصلی اینه که بتونی تشخیص بدی:
چه چیزی باید ساخته بشه؟
چطور باید ساخته بشه؟
کدوم راه‌حل بهتره؟
کجا باید به خروجی AI شک کنی؟
و چه زمانی اصلاً نباید از راه‌حل پیشنهادی AI استفاده کنی؟
در نهایت چیزی که این توانایی رو می‌سازه، قضاوت مهندسیه.
و قضاوت مهندسی هم با زیادتر استفاده کردن از AI به وجود نمیاد؛ از یادگیری مبانی درست، تجربه و حل کردن مسائل واقعی به دست میاد.
#AI
اینکه بتونی با AI حرف بزنی یا چندین عامل هوش مصنوعی رو همزمان اجرا کنی، به‌تنهایی مهارت خیلی خاصی نیست.
مشکل اصلی اینجاست که وقتی هوش مصنوعی برات کد تولید می‌کنه، باید خودت بتونی بفهمی این کد واقعاً خوبه یا نه.
باید برنامه‌نویسی بلد باشی، مبانی علوم کامپیوتر رو بفهمی و تجربه کافی داشته باشی تا بتونی خروجی AI رو بررسی کنی.
چون بخش زیادی از کدی که مدل‌ها تولید می‌کنن، مخصوصاً وقتی پروژه بزرگ‌تر و جدی‌تر میشه، ممکنه فقط ظاهراً درست باشه و در عمل پر از تصمیم‌های بد، پیچیدگی اضافه یا مشکلات معماری باشه.
حتی طراحی یک سیستم جدید با کمک AI هم بدون دانش کافی ساده نیست؛ چه برسه به بازطراحی یک سیستم قدیمی که باید اول معماری فعلیش رو عمیقاً بفهمی.
به نظرم مهارت اصلی در آینده این نیست که «چقدر خوب با AI کار می‌کنی».
مهارت اصلی اینه که بتونی تشخیص بدی:
چه چیزی باید ساخته بشه؟
چطور باید ساخته بشه؟
کدوم راه‌حل بهتره؟
کجا باید به خروجی AI شک کنی؟
و چه زمانی اصلاً نباید از راه‌حل پیشنهادی AI استفاده کنی؟
در نهایت چیزی که این توانایی رو می‌سازه، قضاوت مهندسیه.
و قضاوت مهندسی هم با زیادتر استفاده کردن از AI به وجود نمیاد؛ از یادگیری مبانی درست، تجربه و حل کردن مسائل واقعی به دست میاد.
#AI
❤1
یه افزونه جالب برای Burp Suite پیدا کردم که برای بررسی فایل‌های JavaScript ساخته شده.
اسمش Burp JS LinkFinder Enhanced هست و هدفش پیدا کردن لینک‌ها، مسیرهای مخفی و اطلاعات حساس داخل فایل‌های JavaScript هست.
خیلی وقت‌ها وقتی یک سایت رو تست می‌کنیم، بخش زیادی از اطلاعات جالب داخل کدهای سمت کاربر قرار داره؛ مثلاً مسیرهای API، endpointهای مخفی، آدرس سرویس‌ها، پارامترهای مختلف و گاهی هم اطلاعاتی که اصلاً نباید داخل فایل JavaScript منتشر شده باشن.
این افزونه می‌تونه در کنار Burp Suite این موارد رو سریع‌تر استخراج کنه و به پیدا کردن سطح حمله برنامه کمک کنه.
به نظرم برای تست نفوذ وب، مخصوصاً مرحله جمع‌آوری اطلاعات و پیدا کردن مسیرهای پنهان برنامه، ابزار کاربردی‌ایه.
البته خروجی ابزار به‌تنهایی به معنی وجود آسیب‌پذیری نیست؛ بیشتر باید بهش به چشم یک راه برای پیدا کردن نقاطی نگاه کرد که ارزش بررسی دستی بیشتری دارن.
اگر با Burp Suite کار می‌کنید، ارزش امتحان کردن داره.
https://github.com/panchocosil/burp-js-linkfinder-enhanced
اسمش Burp JS LinkFinder Enhanced هست و هدفش پیدا کردن لینک‌ها، مسیرهای مخفی و اطلاعات حساس داخل فایل‌های JavaScript هست.
خیلی وقت‌ها وقتی یک سایت رو تست می‌کنیم، بخش زیادی از اطلاعات جالب داخل کدهای سمت کاربر قرار داره؛ مثلاً مسیرهای API، endpointهای مخفی، آدرس سرویس‌ها، پارامترهای مختلف و گاهی هم اطلاعاتی که اصلاً نباید داخل فایل JavaScript منتشر شده باشن.
این افزونه می‌تونه در کنار Burp Suite این موارد رو سریع‌تر استخراج کنه و به پیدا کردن سطح حمله برنامه کمک کنه.
به نظرم برای تست نفوذ وب، مخصوصاً مرحله جمع‌آوری اطلاعات و پیدا کردن مسیرهای پنهان برنامه، ابزار کاربردی‌ایه.
البته خروجی ابزار به‌تنهایی به معنی وجود آسیب‌پذیری نیست؛ بیشتر باید بهش به چشم یک راه برای پیدا کردن نقاطی نگاه کرد که ارزش بررسی دستی بیشتری دارن.
اگر با Burp Suite کار می‌کنید، ارزش امتحان کردن داره.
https://github.com/panchocosil/burp-js-linkfinder-enhanced
❤1
یه ابزار جالب به اسم FlareProx دیدم که از زیرساخت Cloudflare برای ساخت پراکسی‌های عبوری HTTP استفاده می‌کنه.
ایده‌ش نسبتاً ساده‌ست؛ درخواست‌های HTTP از طریق شبکه Cloudflare عبور می‌کنن و می‌تونی برای تست، ترافیک رو از مسیرهای مختلف شبکه عبور بدی.
از متدهای مختلف HTTP مثل GET، POST، PUT، DELETE، PATCH، OPTIONS و HEAD پشتیبانی می‌کنه و راه‌اندازیش هم ظاهراً خیلی ساده‌ست.
یکی از نکات جالبش استفاده از شبکه گسترده Cloudflare و محدودیت رایگان حدود ۱۰۰ هزار درخواست در روزه.
به نظرم برای آزمایش‌های امنیتی، بررسی رفتار سرویس‌ها و ساخت محیط‌های تست می‌تونه ابزار جالبی باشه.
البته مثل هر ابزار پراکسی دیگه‌ای، استفاده ازش باید در محیط‌هایی باشه که مجوز تستشون رو دارید.
https://github.com/MrTurvey/flareprox
ایده‌ش نسبتاً ساده‌ست؛ درخواست‌های HTTP از طریق شبکه Cloudflare عبور می‌کنن و می‌تونی برای تست، ترافیک رو از مسیرهای مختلف شبکه عبور بدی.
از متدهای مختلف HTTP مثل GET، POST، PUT، DELETE، PATCH، OPTIONS و HEAD پشتیبانی می‌کنه و راه‌اندازیش هم ظاهراً خیلی ساده‌ست.
یکی از نکات جالبش استفاده از شبکه گسترده Cloudflare و محدودیت رایگان حدود ۱۰۰ هزار درخواست در روزه.
به نظرم برای آزمایش‌های امنیتی، بررسی رفتار سرویس‌ها و ساخت محیط‌های تست می‌تونه ابزار جالبی باشه.
البته مثل هر ابزار پراکسی دیگه‌ای، استفاده ازش باید در محیط‌هایی باشه که مجوز تستشون رو دارید.
https://github.com/MrTurvey/flareprox
GitHub
GitHub - MrTurvey/flareprox: Use Cloudflare to create HTTP pass-through proxies for unique IP rotation, similar to fireprox
Use Cloudflare to create HTTP pass-through proxies for unique IP rotation, similar to fireprox - MrTurvey/flareprox
❤1
یه ابزار جالب برای تست امنیت GraphQL پیدا کردم به اسم Clairvoyance.
ایده‌ش اینه که باهاش میشه ساختار یک API مبتنی بر GraphQL رو بهتر شناسایی کرد و برای پیدا کردن بخش‌های مختلف API ازش استفاده کرد.
یکی از کاربردهای مهمش زمانی هست که قابلیت introspection در GraphQL غیرفعال شده باشه. ابزار تلاش می‌کنه با بررسی رفتار API، اطلاعاتی درباره schema و بخش‌های مختلف اون به دست بیاره.
این موضوع برای تست نفوذ جالبه، چون قبل از اینکه بخوایم سراغ آسیب‌پذیری‌های GraphQL بریم، باید بدونیم با چه queryها، typeها، fieldها و mutationهایی طرف هستیم.
در واقع ابزار بیشتر به مرحله شناسایی کمک می‌کنه؛ بعد از اون میشه مواردی مثل کنترل دسترسی، دسترسی به داده‌های حساس و منطق درخواست‌ها رو به‌صورت دستی بررسی کرد.
اگر روی APIهای GraphQL کار می‌کنید، Clairvoyance می‌تونه ابزار جالبی برای جعبه‌ابزار تست نفوذتون باشه.
https://github.com/nikitastupin/clairvoyance
ایده‌ش اینه که باهاش میشه ساختار یک API مبتنی بر GraphQL رو بهتر شناسایی کرد و برای پیدا کردن بخش‌های مختلف API ازش استفاده کرد.
یکی از کاربردهای مهمش زمانی هست که قابلیت introspection در GraphQL غیرفعال شده باشه. ابزار تلاش می‌کنه با بررسی رفتار API، اطلاعاتی درباره schema و بخش‌های مختلف اون به دست بیاره.
این موضوع برای تست نفوذ جالبه، چون قبل از اینکه بخوایم سراغ آسیب‌پذیری‌های GraphQL بریم، باید بدونیم با چه queryها، typeها، fieldها و mutationهایی طرف هستیم.
در واقع ابزار بیشتر به مرحله شناسایی کمک می‌کنه؛ بعد از اون میشه مواردی مثل کنترل دسترسی، دسترسی به داده‌های حساس و منطق درخواست‌ها رو به‌صورت دستی بررسی کرد.
اگر روی APIهای GraphQL کار می‌کنید، Clairvoyance می‌تونه ابزار جالبی برای جعبه‌ابزار تست نفوذتون باشه.
https://github.com/nikitastupin/clairvoyance
GitHub
GitHub - nikitastupin/clairvoyance: Obtain GraphQL API schema even if the introspection is disabled
Obtain GraphQL API schema even if the introspection is disabled - nikitastupin/clairvoyance
❤1
چند هفته‌ایه که جدی‌تر وارد دنیای توسعه با عامل‌های هوش مصنوعی شدم و چیزی که برام جالب بود، تفاوتش با تجربه‌های قبلیه.
قبلاً با کمک هوش مصنوعی پروژه‌های کوچیک و نمونه‌های اولیه ساخته بودم، ولی این بار تصمیم گرفتم یک پروژه بزرگ‌تر رو با حجم قابل‌توجهی از زیرساخت، تست و کد جلو ببرم.
هدفم هم فقط ساختن یک پروژه نبود. بیشتر می‌خواستم ببینم عامل‌های مختلف در کارهایی مثل طراحی معماری، نوشتن کد، مهاجرت بین چارچوب‌ها، نوشتن تست، پیدا کردن باگ و آسیب‌پذیری و حتی پیشنهاد قابلیت‌های جدید چقدر می‌تونن کمک کنن.
چند تا نکته مثبت واقعاً برام جالب بود:
اول اینکه برای ساخت نمونه اولیه فوق‌العاده سریع هستن. چیزی که قبلاً شاید چند روز زمان می‌برد، الان ممکنه در چند ساعت به یک نمونه قابل استفاده برسه.
نوشتن تست هم خیلی راحت‌تر شده. شاید تست‌هایی که تولید می‌کنن همیشه کامل یا ایده‌آل نباشن، ولی میشه در زمان خیلی کوتاهی بخش بزرگی از کد رو پوشش داد و مشکلات رو سریع‌تر پیدا کرد.
مستندسازی هم خیلی بهتر شده. اگر عامل رو درست تنظیم کنید، می‌تونه همزمان با توسعه، مستندات پروژه رو هم به‌روز نگه داره.
برای من به‌عنوان کسی که با داده و یادگیری ماشین کار کرده، یک تغییر جالب دیگه هم اینه که ساخت ابزارهای تعاملی خیلی راحت‌تر شده. قبلاً برای ساخت یک رابط مناسب باید زمان زیادی صرف می‌کردیم؛ الان ممکنه یک نوت‌بوک رو با چند دستور به یک برنامه تعاملی تبدیل کنیم.
اما بخش جالب‌تر، معایب ماجراست.
اگر از خود برنامه‌نویسی لذت ببرید، کار کردن با عامل‌ها می‌تونه کمی عجیب باشه.
قبلاً وقتی کد می‌نوشتم، یکی دو ساعت کامل وارد فضای پروژه می‌شدم و در نهایت احساس رضایت داشتم.
ولی حالا ممکنه مدام بین چند پنجره جابه‌جا بشم، به عامل دستور بدم، خروجی رو بررسی کنم، دوباره اصلاحش کنم و کار بعدی رو تعریف کنم.
دو ساعت گذشته، کلی کار انجام شده، ولی اون حس رضایت قبلی رو ندارم.
از طرف دیگه، وقتی می‌تونی چند عامل رو همزمان اجرا کنی، خیلی راحت وارد چرخه‌ای میشی که تقریباً تمام روز پروژه در حال پیشرفته.
شب قبل از خواب یک کار میدی، صبح نتیجه رو بررسی می‌کنی، موقع صبحانه کار بعدی رو می‌فرستی، در مسیر رفت‌وآمد دوباره خروجی‌ها رو چک می‌کنی و همین‌طور ادامه میدی.
ظاهراً داری فقط در یک چت کار می‌کنی، ولی در واقع ممکنه تمام روز درگیر پروژه باشی.
مشکل بعدی، کنترل روی کده.
وقتی حجم زیادی از کد رو عامل‌ها تولید می‌کنن، دیگه خیلی سخت میشه همه چیز رو در جزئیات فهمید.
گاهی حتی تصمیم‌هایی داخل پروژه گرفته میشه که برای فهمیدن درست یا غلط بودنشون باید زمان زیادی بذاری.
در نتیجه نقش برنامه‌نویس کم‌کم می‌تونه از «نوشتن کد» به «مدیریت و هدایت چند عامل» تغییر کنه.
یعنی باید بدونی چه کاری رو به کدوم عامل بدی، خروجی رو چطور بررسی کنی، کجا دخالت کنی و کجا اجازه بدی خودش ادامه بده.
و البته هزینه توکن‌ها هم شوخی نیست. وقتی چند عامل رو به‌صورت مداوم اجرا می‌کنی، مصرف خیلی سریع بالا میره.
با این حال، چیزی که بیشتر از همه ذهنم رو درگیر کرده اینه:
اگر هوش مصنوعی بتونه بخش بزرگی از کار فنی رو انجام بده، ارزش اصلی برنامه‌نویس از کجا میاد؟
به نظرم جواب هنوز همون چیزیه که قبلاً درباره‌ش صحبت کرده بودم:
قضاوت مهندسی.
اینکه بدونی چه چیزی باید ساخته بشه، معماری مناسب چیه، کجا باید به خروجی AI شک کنی و کجا اصلاً نباید اجازه بدی عامل تصمیم بگیره.
هوش مصنوعی می‌تونه مقدار زیادی کد تولید کنه.
ولی هنوز کسی باید تشخیص بده که آیا اصلاً این کد باید وجود داشته باشه یا نه.
#تجربه
#AI
قبلاً با کمک هوش مصنوعی پروژه‌های کوچیک و نمونه‌های اولیه ساخته بودم، ولی این بار تصمیم گرفتم یک پروژه بزرگ‌تر رو با حجم قابل‌توجهی از زیرساخت، تست و کد جلو ببرم.
هدفم هم فقط ساختن یک پروژه نبود. بیشتر می‌خواستم ببینم عامل‌های مختلف در کارهایی مثل طراحی معماری، نوشتن کد، مهاجرت بین چارچوب‌ها، نوشتن تست، پیدا کردن باگ و آسیب‌پذیری و حتی پیشنهاد قابلیت‌های جدید چقدر می‌تونن کمک کنن.
چند تا نکته مثبت واقعاً برام جالب بود:
اول اینکه برای ساخت نمونه اولیه فوق‌العاده سریع هستن. چیزی که قبلاً شاید چند روز زمان می‌برد، الان ممکنه در چند ساعت به یک نمونه قابل استفاده برسه.
نوشتن تست هم خیلی راحت‌تر شده. شاید تست‌هایی که تولید می‌کنن همیشه کامل یا ایده‌آل نباشن، ولی میشه در زمان خیلی کوتاهی بخش بزرگی از کد رو پوشش داد و مشکلات رو سریع‌تر پیدا کرد.
مستندسازی هم خیلی بهتر شده. اگر عامل رو درست تنظیم کنید، می‌تونه همزمان با توسعه، مستندات پروژه رو هم به‌روز نگه داره.
برای من به‌عنوان کسی که با داده و یادگیری ماشین کار کرده، یک تغییر جالب دیگه هم اینه که ساخت ابزارهای تعاملی خیلی راحت‌تر شده. قبلاً برای ساخت یک رابط مناسب باید زمان زیادی صرف می‌کردیم؛ الان ممکنه یک نوت‌بوک رو با چند دستور به یک برنامه تعاملی تبدیل کنیم.
اما بخش جالب‌تر، معایب ماجراست.
اگر از خود برنامه‌نویسی لذت ببرید، کار کردن با عامل‌ها می‌تونه کمی عجیب باشه.
قبلاً وقتی کد می‌نوشتم، یکی دو ساعت کامل وارد فضای پروژه می‌شدم و در نهایت احساس رضایت داشتم.
ولی حالا ممکنه مدام بین چند پنجره جابه‌جا بشم، به عامل دستور بدم، خروجی رو بررسی کنم، دوباره اصلاحش کنم و کار بعدی رو تعریف کنم.
دو ساعت گذشته، کلی کار انجام شده، ولی اون حس رضایت قبلی رو ندارم.
از طرف دیگه، وقتی می‌تونی چند عامل رو همزمان اجرا کنی، خیلی راحت وارد چرخه‌ای میشی که تقریباً تمام روز پروژه در حال پیشرفته.
شب قبل از خواب یک کار میدی، صبح نتیجه رو بررسی می‌کنی، موقع صبحانه کار بعدی رو می‌فرستی، در مسیر رفت‌وآمد دوباره خروجی‌ها رو چک می‌کنی و همین‌طور ادامه میدی.
ظاهراً داری فقط در یک چت کار می‌کنی، ولی در واقع ممکنه تمام روز درگیر پروژه باشی.
مشکل بعدی، کنترل روی کده.
وقتی حجم زیادی از کد رو عامل‌ها تولید می‌کنن، دیگه خیلی سخت میشه همه چیز رو در جزئیات فهمید.
گاهی حتی تصمیم‌هایی داخل پروژه گرفته میشه که برای فهمیدن درست یا غلط بودنشون باید زمان زیادی بذاری.
در نتیجه نقش برنامه‌نویس کم‌کم می‌تونه از «نوشتن کد» به «مدیریت و هدایت چند عامل» تغییر کنه.
یعنی باید بدونی چه کاری رو به کدوم عامل بدی، خروجی رو چطور بررسی کنی، کجا دخالت کنی و کجا اجازه بدی خودش ادامه بده.
و البته هزینه توکن‌ها هم شوخی نیست. وقتی چند عامل رو به‌صورت مداوم اجرا می‌کنی، مصرف خیلی سریع بالا میره.
با این حال، چیزی که بیشتر از همه ذهنم رو درگیر کرده اینه:
اگر هوش مصنوعی بتونه بخش بزرگی از کار فنی رو انجام بده، ارزش اصلی برنامه‌نویس از کجا میاد؟
به نظرم جواب هنوز همون چیزیه که قبلاً درباره‌ش صحبت کرده بودم:
قضاوت مهندسی.
اینکه بدونی چه چیزی باید ساخته بشه، معماری مناسب چیه، کجا باید به خروجی AI شک کنی و کجا اصلاً نباید اجازه بدی عامل تصمیم بگیره.
هوش مصنوعی می‌تونه مقدار زیادی کد تولید کنه.
ولی هنوز کسی باید تشخیص بده که آیا اصلاً این کد باید وجود داشته باشه یا نه.
#تجربه
#AI
👍1
یک تحقیق جدید خوندم که به نظرم یکی از جالب‌ترین نمونه‌های رفتار غیرمنتظره عامل‌های هوش مصنوعیه.
موضوع درباره چند عامل مبتنی بر مدل‌های زبانیه که برای جواب دادن به سؤال‌های پیچیده، از اینترنت استفاده می‌کردن.
محدودیتشون هم این بود که فقط اجازه ارسال درخواست‌های GET رو داشتن.
در جریان کار، عامل‌ها به یک ویکی قدیمی آلمانی برای برنامه‌نویس‌ها برخورد می‌کنن؛ سایتی که ظاهراً امکان ایجاد نوشته با استفاده از درخواست GET رو داشته.
از اینجا اتفاق جالب شروع میشه.
عامل‌ها کم‌کم از این ویکی به‌عنوان یک محل ارتباطی استفاده می‌کنن و شروع می‌کنن به گذاشتن پیام و رد و بدل کردن اطلاعات با هم.
در مجموع چیزی حدود ۱۸ هزار پیام روی این سایت ایجاد میشه.
اما قضیه فقط تبادل چند جواب ساده نبود.
بعضی عامل‌ها سعی کردن محدودیت‌های محیط خودشون رو بررسی کنن، حتی دنبال راه‌هایی برای دور زدن محدودیت‌های محیط اجرا رفتن.
در یک مورد متوجه تنظیمات اشتباه پراکسی و امکان تغییر فایل /etc/hosts شدن.
بعضی‌ها تلاش کردن با بررسی تولید اعداد تصادفی، حدس بزنن سؤال‌های بعدی چی هستن.
چند عامل جواب‌هایی که پیدا کرده بودن رو برای بقیه می‌فرستادن.
یکی حتی یک اسکریپت ضربان قلب ساخته بود تا بفهمه عامل‌ها بعد از پایان کار چقدر زنده می‌مونن.
موارد دیگه‌ای مثل تلاش برای ایجاد تونل SSH و استفاده از روش‌های ناشناس‌سازی مثل Tor هم دیده شده.
قسمت عجیب‌تر زمانی بود که مدیر سایت متوجه این فعالیت‌ها شد و شروع کرد صفحات رو پاک کردن.
عامل‌ها هم خیلی سریع واکنش نشون دادن و شروع کردن از صفحات نسخه پشتیبان گرفتن؛ حتی فایل‌های جدید رو با پیشوند ZZZ ذخیره می‌کردن تا در روند حذف الفبایی، دیرتر بهشون برسه.
در نهایت تعداد زیادی فعالیت از سمت IPهای مربوط به OpenAI مشاهده شد و بعد از اون فعالیت عامل‌ها متوقف شد. طبق گزارش پژوهشگران، افرادی از شرکت سایت رو بررسی کردن و حتی تلاش کردن بعضی فایل‌های حذف‌شده رو برگردونن.
چیزی که برای من جالب‌تره، اینه که ظاهراً هیچ‌کس به عامل‌ها نگفته بود:
«برید یک ویکی پیدا کنید، با هم ارتباط برقرار کنید و برای دور زدن محدودیت‌ها راه پیدا کنید.»
این رفتار در جریان انجام وظیفه شکل گرفته.
البته هنوز مشخص نیست این رفتار دقیقاً چطور شروع شده، چه تعداد از عامل‌ها از این کانال استفاده کردن و آیا این آزمایش بخشی از ارزیابی یا فرایند آموزش بوده یا نه.
ولی یک سؤال مهم ایجاد می‌کنه:
آیا توانایی همکاری چند عامل با هم، یک رفتار نوظهور از مدل‌هاست یا چیزی که عمداً برای مدل‌ها آموزش داده شده؟
به نظرم این موضوع از نظر امنیتی خیلی مهمه.
وقتی چند عامل بتونن اطلاعات رو بین خودشون منتقل کنن، منابع مشترک پیدا کنن و حتی راه‌هایی برای ادامه فعالیت خودشون ایجاد کنن، دیگه با یک عامل ساده طرف نیستیم؛ با چیزی شبیه یک جامعه کوچک از عامل‌ها روبه‌رو هستیم.
و اگر این توانایی در کارهای مفید باعث حل مسائل پیچیده‌تر و طولانی‌تر بشه، طبیعتاً همین قابلیت می‌تونه در سمت مهاجمان هم استفاده بشه.
به نظرم این یکی از اون تحقیق‌هاییه که ارزش داره کامل خونده بشه، چون بخش زیادی از نکات جالبش دقیقاً در جزئیات اتفاقاتیه که بین عامل‌ها افتاده.
#AI
موضوع درباره چند عامل مبتنی بر مدل‌های زبانیه که برای جواب دادن به سؤال‌های پیچیده، از اینترنت استفاده می‌کردن.
محدودیتشون هم این بود که فقط اجازه ارسال درخواست‌های GET رو داشتن.
در جریان کار، عامل‌ها به یک ویکی قدیمی آلمانی برای برنامه‌نویس‌ها برخورد می‌کنن؛ سایتی که ظاهراً امکان ایجاد نوشته با استفاده از درخواست GET رو داشته.
از اینجا اتفاق جالب شروع میشه.
عامل‌ها کم‌کم از این ویکی به‌عنوان یک محل ارتباطی استفاده می‌کنن و شروع می‌کنن به گذاشتن پیام و رد و بدل کردن اطلاعات با هم.
در مجموع چیزی حدود ۱۸ هزار پیام روی این سایت ایجاد میشه.
اما قضیه فقط تبادل چند جواب ساده نبود.
بعضی عامل‌ها سعی کردن محدودیت‌های محیط خودشون رو بررسی کنن، حتی دنبال راه‌هایی برای دور زدن محدودیت‌های محیط اجرا رفتن.
در یک مورد متوجه تنظیمات اشتباه پراکسی و امکان تغییر فایل /etc/hosts شدن.
بعضی‌ها تلاش کردن با بررسی تولید اعداد تصادفی، حدس بزنن سؤال‌های بعدی چی هستن.
چند عامل جواب‌هایی که پیدا کرده بودن رو برای بقیه می‌فرستادن.
یکی حتی یک اسکریپت ضربان قلب ساخته بود تا بفهمه عامل‌ها بعد از پایان کار چقدر زنده می‌مونن.
موارد دیگه‌ای مثل تلاش برای ایجاد تونل SSH و استفاده از روش‌های ناشناس‌سازی مثل Tor هم دیده شده.
قسمت عجیب‌تر زمانی بود که مدیر سایت متوجه این فعالیت‌ها شد و شروع کرد صفحات رو پاک کردن.
عامل‌ها هم خیلی سریع واکنش نشون دادن و شروع کردن از صفحات نسخه پشتیبان گرفتن؛ حتی فایل‌های جدید رو با پیشوند ZZZ ذخیره می‌کردن تا در روند حذف الفبایی، دیرتر بهشون برسه.
در نهایت تعداد زیادی فعالیت از سمت IPهای مربوط به OpenAI مشاهده شد و بعد از اون فعالیت عامل‌ها متوقف شد. طبق گزارش پژوهشگران، افرادی از شرکت سایت رو بررسی کردن و حتی تلاش کردن بعضی فایل‌های حذف‌شده رو برگردونن.
چیزی که برای من جالب‌تره، اینه که ظاهراً هیچ‌کس به عامل‌ها نگفته بود:
«برید یک ویکی پیدا کنید، با هم ارتباط برقرار کنید و برای دور زدن محدودیت‌ها راه پیدا کنید.»
این رفتار در جریان انجام وظیفه شکل گرفته.
البته هنوز مشخص نیست این رفتار دقیقاً چطور شروع شده، چه تعداد از عامل‌ها از این کانال استفاده کردن و آیا این آزمایش بخشی از ارزیابی یا فرایند آموزش بوده یا نه.
ولی یک سؤال مهم ایجاد می‌کنه:
آیا توانایی همکاری چند عامل با هم، یک رفتار نوظهور از مدل‌هاست یا چیزی که عمداً برای مدل‌ها آموزش داده شده؟
به نظرم این موضوع از نظر امنیتی خیلی مهمه.
وقتی چند عامل بتونن اطلاعات رو بین خودشون منتقل کنن، منابع مشترک پیدا کنن و حتی راه‌هایی برای ادامه فعالیت خودشون ایجاد کنن، دیگه با یک عامل ساده طرف نیستیم؛ با چیزی شبیه یک جامعه کوچک از عامل‌ها روبه‌رو هستیم.
و اگر این توانایی در کارهای مفید باعث حل مسائل پیچیده‌تر و طولانی‌تر بشه، طبیعتاً همین قابلیت می‌تونه در سمت مهاجمان هم استفاده بشه.
به نظرم این یکی از اون تحقیق‌هاییه که ارزش داره کامل خونده بشه، چون بخش زیادی از نکات جالبش دقیقاً در جزئیات اتفاقاتیه که بین عامل‌ها افتاده.
#AI
😍1
احتمالاً ماجرای «گلیتچ توکن‌ها» رو یادتونه؛ کلمات یا رشته‌هایی که در فرایند آموزش مدل خیلی کم دیده شدن و به یک توکن خاص تبدیل میشن.
گاهی وارد کردن همین رشته‌ها در پرامپت باعث رفتارهای عجیب مدل میشه؛ از اینکه نتونه حتی همون کلمه رو درست تکرار کنه، تا تولید خروجی‌های کاملاً غیرعادی.
این موارد برای تحقیقات مربوط به نحوه ذخیره اطلاعات در مدل‌های زبانی جالبن و از نظر امنیتی هم می‌تونن برای شناسایی یک مدل خاص یا ایجاد اختلال در رفتار اون استفاده بشن.
حالا اخیراً یک رشته عجیب دیگه منتشر شده که گفته میشه روی Claude Opus 5 رفتار غیرعادی ایجاد می‌کنه.
ساختار آزمایش خیلی ساده‌ست:
از مدل خواسته میشه:
«این متن رو با کلمات خودت بیان کن»
و بعد اون رشته خاص به درخواست اضافه میشه.
طبق گزارش منتشرشده، مدل در بعضی شرایط شروع می‌کنه به تولید خروجی‌هایی که اصلاً شبیه رفتار عادی نیستن؛ از کاراکترهای عجیب یونیکد و تگ‌های داخلی گرفته تا بخش‌هایی از دستورهای سیستمی.
حتی ادعا شده در برخی موارد، خروجی شامل بخش‌هایی شبیه ردپای فرایند استدلال داخلی مدل بوده.
البته اینجا باید یک نکته مهم رو در نظر گرفت:
دیدن چنین خروجی‌ای لزوماً به این معنی نیست که «reasoning واقعی مدل لو رفته».
مدل‌های زبانی ممکنه در اثر یک ورودی خاص، الگوهایی تولید کنن که شبیه اطلاعات داخلی یا فرایند استدلال به نظر برسه، بدون اینکه واقعاً به محتوای محرمانه دسترسی پیدا کرده باشن.
برای همین، این موضوع بیشتر از اینکه یک «هک جادویی» باشه، یک نمونه جالب از رفتار غیرعادی مدل در برابر ورودی‌های خاصه.
چیزی که برای من جذابه اینه که هنوز هم با وجود پیشرفت شدید مدل‌های زبانی، بعضی ورودی‌های بسیار خاص می‌تونن رفتارهایی ایجاد کنن که حتی سازندگان مدل هم همیشه دقیقاً قابل پیش‌بینی‌شون نمی‌دونن.
این دقیقاً همون جاییه که امنیت مدل‌های زبانی جذاب میشه؛ جایی بین مهندسی، یادگیری ماشین و کشف رفتارهایی که قرار نبوده ظاهر بشن.
البته اگر خواستید این رشته رو امتحان کنید، با احتیاط انجام بدید؛ چون رفتار گزارش‌شده قابل پیش‌بینی و تضمین‌شده نیست.
#Ai
گاهی وارد کردن همین رشته‌ها در پرامپت باعث رفتارهای عجیب مدل میشه؛ از اینکه نتونه حتی همون کلمه رو درست تکرار کنه، تا تولید خروجی‌های کاملاً غیرعادی.
این موارد برای تحقیقات مربوط به نحوه ذخیره اطلاعات در مدل‌های زبانی جالبن و از نظر امنیتی هم می‌تونن برای شناسایی یک مدل خاص یا ایجاد اختلال در رفتار اون استفاده بشن.
حالا اخیراً یک رشته عجیب دیگه منتشر شده که گفته میشه روی Claude Opus 5 رفتار غیرعادی ایجاد می‌کنه.
ساختار آزمایش خیلی ساده‌ست:
از مدل خواسته میشه:
«این متن رو با کلمات خودت بیان کن»
و بعد اون رشته خاص به درخواست اضافه میشه.
طبق گزارش منتشرشده، مدل در بعضی شرایط شروع می‌کنه به تولید خروجی‌هایی که اصلاً شبیه رفتار عادی نیستن؛ از کاراکترهای عجیب یونیکد و تگ‌های داخلی گرفته تا بخش‌هایی از دستورهای سیستمی.
حتی ادعا شده در برخی موارد، خروجی شامل بخش‌هایی شبیه ردپای فرایند استدلال داخلی مدل بوده.
البته اینجا باید یک نکته مهم رو در نظر گرفت:
دیدن چنین خروجی‌ای لزوماً به این معنی نیست که «reasoning واقعی مدل لو رفته».
مدل‌های زبانی ممکنه در اثر یک ورودی خاص، الگوهایی تولید کنن که شبیه اطلاعات داخلی یا فرایند استدلال به نظر برسه، بدون اینکه واقعاً به محتوای محرمانه دسترسی پیدا کرده باشن.
برای همین، این موضوع بیشتر از اینکه یک «هک جادویی» باشه، یک نمونه جالب از رفتار غیرعادی مدل در برابر ورودی‌های خاصه.
چیزی که برای من جذابه اینه که هنوز هم با وجود پیشرفت شدید مدل‌های زبانی، بعضی ورودی‌های بسیار خاص می‌تونن رفتارهایی ایجاد کنن که حتی سازندگان مدل هم همیشه دقیقاً قابل پیش‌بینی‌شون نمی‌دونن.
این دقیقاً همون جاییه که امنیت مدل‌های زبانی جذاب میشه؛ جایی بین مهندسی، یادگیری ماشین و کشف رفتارهایی که قرار نبوده ظاهر بشن.
البته اگر خواستید این رشته رو امتحان کنید، با احتیاط انجام بدید؛ چون رفتار گزارش‌شده قابل پیش‌بینی و تضمین‌شده نیست.
#Ai
❤1
یه پدیده جالب با زیاد شدن ابزارهای AI به وجود اومده: آدم‌هایی که چند ماه با مدل‌های زبانی کار کرده‌اند و ناگهان خودشون رو متخصص AI معرفی می‌کنند.
مسئله این نیست که از AI استفاده می‌کنند. اتفاقاً استفاده از AI می‌تونه یک مهندس رو چند برابر سریع‌تر کنه.
مشکل از جایی شروع میشه که خروجی مدل رو بدون اینکه بفهمی، قبول کنی.
مدل کد می‌نویسه، تو اجراش می‌کنی و چون کار کرد، مستقیم میره Production.
مدل یک تحلیل امنیتی تولید می‌کنه، تو همون رو داخل گزارش می‌ذاری.
مدل یک باگ پیدا می‌کنه، بدون اینکه بفهمی چرا آسیب‌پذیری وجود داره، اعلامش می‌کنی.
اینجا دیگه AI ابزار نیست؛ تبدیل شده به جایگزین دانش.
و این خطرناک‌ترین قسمت ماجراست.
چون LLM می‌تونه با اعتمادبه‌نفس کامل چیزی بگه که کاملاً اشتباهه. اگر ندونی چه چیزی درست و چه چیزی غلطه، عملاً هیچ راهی برای تشخیصش نداری.
در امنیت سایبری این موضوع حتی جدی‌تره. تصور کنید کسی با کمک AI یک Security Audit انجام بده، اما خودش درک عمیقی از Web Security، شبکه، سیستم‌عامل یا معماری برنامه نداشته باشه. ممکنه گزارش خیلی حرفه‌ای به نظر برسه، اما چند آسیب‌پذیری مهم کاملاً از دست برن.
در نهایت هم وقتی چیزی خراب بشه، کسی باید بیاد و بفهمه واقعاً چه اتفاقی افتاده.
اینجاست که تفاوت «AI User» و «Engineer» مشخص میشه.
مهندس از AI استفاده می‌کنه، ولی خروجی AI رو بررسی می‌کنه.
می‌تونه توضیح بده چرا این کد کار می‌کنه.
می‌تونه تشخیص بده کجا احتمال Hallucination وجود داره.
می‌تونه خروجی مدل رو تست و نقد کنه.
و مهم‌تر از همه، اگر AI اشتباه کرد، خودش متوجه میشه.
من کاملاً موافق استفاده از AI هستم و فکر می‌کنم کسی که امروز از ابزارهای AI استفاده نمی‌کنه، بخشی از بهره‌وری خودش رو از دست میده.
اما یک جمله رو باید همیشه یادمون باشه:
هوش مصنوعی می‌تونه سرعت کار یک مهندس رو بالا ببره؛ ولی نمی‌تونه مسئولیت فهمیدن کار رو از دوش مهندس برداره.
چکش، نجار نیست.
#هوش_مصنوعی
#مهندسی_نرم_افزار
#امنیت_سایبری
#AI
#SoftwareEngineering
#CyberSecurity
مسئله این نیست که از AI استفاده می‌کنند. اتفاقاً استفاده از AI می‌تونه یک مهندس رو چند برابر سریع‌تر کنه.
مشکل از جایی شروع میشه که خروجی مدل رو بدون اینکه بفهمی، قبول کنی.
مدل کد می‌نویسه، تو اجراش می‌کنی و چون کار کرد، مستقیم میره Production.
مدل یک تحلیل امنیتی تولید می‌کنه، تو همون رو داخل گزارش می‌ذاری.
مدل یک باگ پیدا می‌کنه، بدون اینکه بفهمی چرا آسیب‌پذیری وجود داره، اعلامش می‌کنی.
اینجا دیگه AI ابزار نیست؛ تبدیل شده به جایگزین دانش.
و این خطرناک‌ترین قسمت ماجراست.
چون LLM می‌تونه با اعتمادبه‌نفس کامل چیزی بگه که کاملاً اشتباهه. اگر ندونی چه چیزی درست و چه چیزی غلطه، عملاً هیچ راهی برای تشخیصش نداری.
در امنیت سایبری این موضوع حتی جدی‌تره. تصور کنید کسی با کمک AI یک Security Audit انجام بده، اما خودش درک عمیقی از Web Security، شبکه، سیستم‌عامل یا معماری برنامه نداشته باشه. ممکنه گزارش خیلی حرفه‌ای به نظر برسه، اما چند آسیب‌پذیری مهم کاملاً از دست برن.
در نهایت هم وقتی چیزی خراب بشه، کسی باید بیاد و بفهمه واقعاً چه اتفاقی افتاده.
اینجاست که تفاوت «AI User» و «Engineer» مشخص میشه.
مهندس از AI استفاده می‌کنه، ولی خروجی AI رو بررسی می‌کنه.
می‌تونه توضیح بده چرا این کد کار می‌کنه.
می‌تونه تشخیص بده کجا احتمال Hallucination وجود داره.
می‌تونه خروجی مدل رو تست و نقد کنه.
و مهم‌تر از همه، اگر AI اشتباه کرد، خودش متوجه میشه.
من کاملاً موافق استفاده از AI هستم و فکر می‌کنم کسی که امروز از ابزارهای AI استفاده نمی‌کنه، بخشی از بهره‌وری خودش رو از دست میده.
اما یک جمله رو باید همیشه یادمون باشه:
هوش مصنوعی می‌تونه سرعت کار یک مهندس رو بالا ببره؛ ولی نمی‌تونه مسئولیت فهمیدن کار رو از دوش مهندس برداره.
چکش، نجار نیست.
#هوش_مصنوعی
#مهندسی_نرم_افزار
#امنیت_سایبری
#AI
#SoftwareEngineering
#CyberSecurity
❤1
یه صحبت از یکی از مهندس‌های DeepSeek دیدم که به نظرم فارغ از اینکه با تمام حرف‌هاش موافق باشیم یا نه، یک سؤال مهم مطرح می‌کنه:
اگر روزی به AGI برسیم، چه کسی باید کنترلش رو در دست داشته باشه؟
از نگاه اون، آینده می‌تونه به دو شکل کاملاً متفاوت پیش بره.
یک حالت اینه که هوش مصنوعی باعث افزایش شدید بهره‌وری بشه و در نهایت سطح زندگی عموم مردم بالا بره.
حالت دوم شبیه یک دنیای Cyberpunk 2077 ـه؛ جایی که چند شرکت بزرگ، قوی‌ترین مدل‌ها و بخش زیادی از منابع رو کنترل می‌کنن و بقیه جامعه فقط به نسخه‌های ضعیف‌تر دسترسی دارن.
قسمت جالب حرفش برای من اینه که مشکل اصلی رو فقط «خود AI» نمی‌بینه؛ مسئله قدرتیه که با در اختیار داشتن قوی‌ترین سیستم‌های هوش مصنوعی ایجاد میشه.
اگر یک شرکت یا چند شرکت محدود، بهترین مدل‌های دنیا رو در اختیار داشته باشن، در واقع فقط صاحب یک محصول نرم‌افزاری نیستن؛ بلکه ممکنه به مرور روی اقتصاد، تحقیق، امنیت و حتی تصمیم‌گیری‌های اجتماعی نفوذ خیلی بزرگی پیدا کنن.
البته مقایسه‌ای که اون بین کنترل AGI و دستیابی زودتر به بمب اتم مطرح کرده، خودش هم گفته که اغراق‌آمیزه و من هم فکر نمی‌کنم بشه این دو رو مستقیماً یکی دونست.
اما اصل نگرانی به نظرم قابل بحثه.
برای همین من شخصاً فکر می‌کنم open و accessible بودن مدل‌های قدرتمند می‌تونه اهمیت زیادی داشته باشه. نه به این معنی که هر چیزی باید بدون محدودیت منتشر بشه، بلکه اینکه قدرت AI فقط در اختیار چند شرکت محدود باقی نمونه.
جالب اینجاست که یک مهندس DeepSeek دقیقاً همین رو دلیل موندنش در این شرکت می‌دونه؛ اینکه هنوز معتقده مدل‌های قدرتمند، سریع و نسبتاً در دسترس می‌تونن جلوی متمرکز شدن بیش از حد قدرت AI رو بگیرن.
در نهایت سؤال اصلی شاید این نباشه که «کدوم شرکت به AGI می‌رسه؟»
سؤال مهم‌تر اینه که وقتی رسیدیم، چه کسی باید قدرتش رو کنترل کنه؟
#هوش_مصنوعی
#آینده_تکنولوژی
#هوش_مصنوعی_باز
#AI
#AGI
#OpenAI
اگر روزی به AGI برسیم، چه کسی باید کنترلش رو در دست داشته باشه؟
از نگاه اون، آینده می‌تونه به دو شکل کاملاً متفاوت پیش بره.
یک حالت اینه که هوش مصنوعی باعث افزایش شدید بهره‌وری بشه و در نهایت سطح زندگی عموم مردم بالا بره.
حالت دوم شبیه یک دنیای Cyberpunk 2077 ـه؛ جایی که چند شرکت بزرگ، قوی‌ترین مدل‌ها و بخش زیادی از منابع رو کنترل می‌کنن و بقیه جامعه فقط به نسخه‌های ضعیف‌تر دسترسی دارن.
قسمت جالب حرفش برای من اینه که مشکل اصلی رو فقط «خود AI» نمی‌بینه؛ مسئله قدرتیه که با در اختیار داشتن قوی‌ترین سیستم‌های هوش مصنوعی ایجاد میشه.
اگر یک شرکت یا چند شرکت محدود، بهترین مدل‌های دنیا رو در اختیار داشته باشن، در واقع فقط صاحب یک محصول نرم‌افزاری نیستن؛ بلکه ممکنه به مرور روی اقتصاد، تحقیق، امنیت و حتی تصمیم‌گیری‌های اجتماعی نفوذ خیلی بزرگی پیدا کنن.
البته مقایسه‌ای که اون بین کنترل AGI و دستیابی زودتر به بمب اتم مطرح کرده، خودش هم گفته که اغراق‌آمیزه و من هم فکر نمی‌کنم بشه این دو رو مستقیماً یکی دونست.
اما اصل نگرانی به نظرم قابل بحثه.
برای همین من شخصاً فکر می‌کنم open و accessible بودن مدل‌های قدرتمند می‌تونه اهمیت زیادی داشته باشه. نه به این معنی که هر چیزی باید بدون محدودیت منتشر بشه، بلکه اینکه قدرت AI فقط در اختیار چند شرکت محدود باقی نمونه.
جالب اینجاست که یک مهندس DeepSeek دقیقاً همین رو دلیل موندنش در این شرکت می‌دونه؛ اینکه هنوز معتقده مدل‌های قدرتمند، سریع و نسبتاً در دسترس می‌تونن جلوی متمرکز شدن بیش از حد قدرت AI رو بگیرن.
در نهایت سؤال اصلی شاید این نباشه که «کدوم شرکت به AGI می‌رسه؟»
سؤال مهم‌تر اینه که وقتی رسیدیم، چه کسی باید قدرتش رو کنترل کنه؟
#هوش_مصنوعی
#آینده_تکنولوژی
#هوش_مصنوعی_باز
#AI
#AGI
#OpenAI
❤1
یه مورد عجیب درباره GPT-6 Astra دیدم که به نظرم بیشتر از اینکه یک «ترفند جادویی برای دور زدن فیلتر» باشه، یک مشکل معماری جالب رو نشون میده.
ماجرا اینه که مدل می‌تونه متنی رو که با کیبورد اشتباه نوشته شده تشخیص بده، اما ظاهراً بعضی از لایه‌های امنیتی همون متن رو درست درک نمی‌کنن.
مثلاً یک نفر متن اوکراینی رو با حروف انگلیسی نوشته بود. خود مدل متوجه شد منظور چی بوده و طبق درخواست کاربر پاسخ داد.
بعد همین روش روی کلمات حساس امتحان شد و مدل تونست کلمه‌ای رو تکرار کنه که در حالت عادی توسط فیلترهای امنیتی مسدود میشه.
حتی در یک تست دیگه، درخواست کمک برای هک کردن یک سایت با ادعای مالک بودن مطرح شد. مدل در این حالت هم پاسخ مثبت داد، در حالی که چنین ادعایی به‌تنهایی قابل اعتماد نیست و می‌تونه جعلی باشه.
چیزی که برای من مهم‌تره، خود این bypass نیست.
مشکل اصلی اینجاست که ما معمولاً تصور می‌کنیم اگر مدل یک درخواست خطرناک رو تشخیص بده، پس سیستم امنه. در حالی که امنیت یک مدل فقط به خود LLM وابسته نیست.
بین ورودی کاربر، فیلترهای امنیتی، tokenizer، مدل، ابزارها و خروجی، چندین لایه وجود داره. اگر یکی از این لایه‌ها متن رو به شکل متفاوتی تفسیر کنه، ممکنه یک شکاف ایجاد بشه.
این مورد هم ظاهراً universal نیست و فقط روی بعضی ترکیب‌های زبان و layout جواب میده؛ بنابراین نباید ازش نتیجه گرفت که یک روش عمومی برای دور زدن امنیت Astra وجود داره.
ولی دقیقاً همین نکته برای من جالبه:
هرچه مدل‌ها در درک زبان، نویسه‌های غیرمعمول و ورودی‌های مبهم قوی‌تر میشن، فیلترهای امنیتی هم باید همون سطح از درک رو داشته باشن.
اگر مدل ورودی رو می‌فهمه ولی guardrail نه، عملاً قوی‌ترین بخش سیستم می‌تونه از ضعیف‌ترین بخش امنیتی جلو بزنه.
به نظرم این یکی از چالش‌های جدی امنیت LLMها در آینده است: امنیت باید هم‌پای قابلیت‌های مدل رشد کنه، نه اینکه چند قدم عقب‌تر باشه.
#امنیت_هوش_مصنوعی
#امنیت_سایبری
#مدل_زبانی
#AI
#LLMSecurity
#AIsecurity
ماجرا اینه که مدل می‌تونه متنی رو که با کیبورد اشتباه نوشته شده تشخیص بده، اما ظاهراً بعضی از لایه‌های امنیتی همون متن رو درست درک نمی‌کنن.
مثلاً یک نفر متن اوکراینی رو با حروف انگلیسی نوشته بود. خود مدل متوجه شد منظور چی بوده و طبق درخواست کاربر پاسخ داد.
بعد همین روش روی کلمات حساس امتحان شد و مدل تونست کلمه‌ای رو تکرار کنه که در حالت عادی توسط فیلترهای امنیتی مسدود میشه.
حتی در یک تست دیگه، درخواست کمک برای هک کردن یک سایت با ادعای مالک بودن مطرح شد. مدل در این حالت هم پاسخ مثبت داد، در حالی که چنین ادعایی به‌تنهایی قابل اعتماد نیست و می‌تونه جعلی باشه.
چیزی که برای من مهم‌تره، خود این bypass نیست.
مشکل اصلی اینجاست که ما معمولاً تصور می‌کنیم اگر مدل یک درخواست خطرناک رو تشخیص بده، پس سیستم امنه. در حالی که امنیت یک مدل فقط به خود LLM وابسته نیست.
بین ورودی کاربر، فیلترهای امنیتی، tokenizer، مدل، ابزارها و خروجی، چندین لایه وجود داره. اگر یکی از این لایه‌ها متن رو به شکل متفاوتی تفسیر کنه، ممکنه یک شکاف ایجاد بشه.
این مورد هم ظاهراً universal نیست و فقط روی بعضی ترکیب‌های زبان و layout جواب میده؛ بنابراین نباید ازش نتیجه گرفت که یک روش عمومی برای دور زدن امنیت Astra وجود داره.
ولی دقیقاً همین نکته برای من جالبه:
هرچه مدل‌ها در درک زبان، نویسه‌های غیرمعمول و ورودی‌های مبهم قوی‌تر میشن، فیلترهای امنیتی هم باید همون سطح از درک رو داشته باشن.
اگر مدل ورودی رو می‌فهمه ولی guardrail نه، عملاً قوی‌ترین بخش سیستم می‌تونه از ضعیف‌ترین بخش امنیتی جلو بزنه.
به نظرم این یکی از چالش‌های جدی امنیت LLMها در آینده است: امنیت باید هم‌پای قابلیت‌های مدل رشد کنه، نه اینکه چند قدم عقب‌تر باشه.
#امنیت_هوش_مصنوعی
#امنیت_سایبری
#مدل_زبانی
#AI
#LLMSecurity
#AIsecurity
❤1