مدل GLM-5.3 عملکردی بین مدل‌های Opus 4.8 و Fable 5 داره؛ در بعضی بنچمارک‌های خاص، کمی جلوتره.

می‌خوام چند تا تجربه و نظر شخصی رو بعد از کار کردن با دیپ‌سیک هارنس به اشتراک بذارم.

نه از دید یک برنامه‌نویس، صرفا از دید یک کاربر معمولی.

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

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

۲. سرعتش واقعاً فوق‌العاده بالاست و این یکی از نقاط قوت اصلیشه.

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

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

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

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

۷. امیدوارم پشتیبانی از چندرسانه‌ای هرچه زودتر اضافه بشه. چندرسانه‌ای بودن هم بخشی از مسیر رسیدن به هوش عمومی مصنوعیه.

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

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

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

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


#deepseek

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

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

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

من به این بخش از تجربه کاربری می‌گم اولین نقطه ارزش.

این مفهوم رو میشه در مراحل مختلف در نظر گرفت:

۱. دانلود و نصب موفق برنامه
۲. اجرای موفق برنامه برای اولین بار
۳. انجام اولین کاری که برنامه برایش طراحی شده و رسیدن به نتیجه موفق

این مسیرها باید بدون هیچ اصطکاکی باشن.

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

این موضوع باعث میشه افراد دیگه هم انگیزه کمتری برای به اشتراک گذاشتن کارهاشون داشته باشن.

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

#Ai

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

#Ai

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

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

تفاوت اصلی بین مهندس جونیور، میدلول و سینیور، میزان مسئولیت و تأثیرگذاریه.

مهندس جونیور برای یاد گرفتن حقوق می‌گیره.

با راهنمایی جلو میره و زود سؤال می‌پرسه.

این ضعف نیست؛ این دقیقاً بخشی از کارشه.

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

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

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

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

→ قبل از اینکه ازت بخوان، مسئولیت قبول کن
→ به نتیجه نهایی اهمیت بده، نه فقط انجام تسک
→ تأثیرت روی تیم رو بیشتر از سرعت شخصی خودت بهینه کن

عنوان شغلی بعداً میاد.
اول باید رفتارتون تغییر کنه دوستان!

#توصیه

کدنویسی با وایب (Vibe Coding) احتمالاً بیشتر از هر چیز دیگری در دهه اخیر، برای مهندسان نرم‌افزار کار ایجاد خواهد کرد.

نه کمتر؛ بیشتر.

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

و این دقیقاً همون چیزیه که خیلی‌ها متوجهش نمی‌شن.

#توصیه

#Ai

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

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

احتمالاً به‌زودی موجی از استخدام مهندس‌های نرم‌افزار رو می‌بینیم برای:

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

وایب کدینگ تبدیل شده به نسخه جدید FAFO.

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

طنز ماجرا اینجاست:

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

مهندس‌های سینیوری که بتونن:

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

ارزش بیشتری پیدا می‌کنن.

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

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

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

#Ai

هیچ‌وقت یادگیری رو متوقف نکنید.

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

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

خب، ولی اگه...؟

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

#توصیه

خیلی‌ها دارن می‌پرسن چرا استرایپ داره اوپن‌روتر رو می‌خره، در حالی که در نگاه اول این دو شرکت کاملاً متفاوت به نظر می‌رسن.

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

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

من فکر نمی‌کنم طی ۵ سال آینده حتی یک اپلیکیشن جدی روی اینترنت وجود داشته باشه که به یک ارائه‌دهنده مدل زبانی درخواست API نفرسته.

حالا این سناریو رو تصور کن:

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

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

#Ai

قبل از هوش مصنوعی 🤖
طراحی: ۴ هفته
توسعه: ۲ هفته
تست: ۱ هفته
رفع باگ: ۱ هفته

بعد از هوش مصنوعی 💀
طراحی: ۰ روز
توسعه: ۱ روز
تست: ۱ روز
رفع باگ: تا ابد 😭
#Ai

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

یک مفهوم مهم روی نحوه تولید متن توسط مدل تأثیر می‌ذاره:

اون هم نمونه‌گیری!

بذارید ساده بررسیش کنیم

✨ نمونه‌گیری چیه دقیقا؟

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

مثلاً:
پایتخت فرانسه کجاست؟

پاریس → ۵۰٪
لیون → ۲۰٪
مارسی → ۱۵٪
برلین → ۲٪
لندن → ۱٪

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

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

✨ دو روش رایج نمونه‌گیری

۱. نمونه‌گیری تاپ-کی
فقط چند گزینه‌ای که بیشترین احتمال رو دارن نگه می‌داره.

مثلاً اگر تاپ-کی برابر ۳ باشه:
پاریس → ۵۰٪
لیون → ۲۰٪
مارسی → ۱۵٪
و بقیه گزینه‌ها کنار گذاشته میشن.

یعنی تاپ-کی می‌پرسه:

چند گزینه اجازه دارن در انتخاب شرکت کنن؟

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

مثلاً اگر تاپ-پی برابر ۸۵٪ باشه:
پاریس → ۵۰٪
لیون → ۲۰٪
مارسی → ۱۵٪
مجموع = ۸۵٪

پس بقیه گزینه‌ها حذف میشن.
یعنی تاپ-پی می‌پرسه:

چه مقدار از مجموع احتمال‌ها رو در نظر بگیریم؟

✨ تفاوت دما و نمونه‌گیری
این دو مفهوم خیلی وقت‌ها با هم اشتباه گرفته میشن.

دما:
→ احتمال گزینه‌ها رو تغییر می‌ده
→ میزان تصادفی‌بودن رو کنترل می‌کنه

نمونه‌گیری:

→ تاپ-کی تعداد گزینه‌ها رو محدود می‌کنه
→ تاپ-پی محدوده احتمال قابل‌بررسی رو محدود می‌کنه

✨ چرا این تنظیمات مهمن؟

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

در نهایت می‌تونن بین این موارد تعادل ایجاد کنن:

→ ثبات
→ خلاقیت
→ تنوع
→ قابل‌اعتماد بودن

پس خیلی ساده:

دما میگه چقدر تصادفی باشیم.
تاپ-کی میگه چند گزینه رو بررسی کنیم.
تاپ-پی میگه چه مقدار از احتمال‌ها رو در نظر بگیریم.

#Ai
#sampling

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

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

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

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

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

معمولاً هم اتفاق عجیب‌وغریبی نیست؛ از همون تأخیرهای کوچیک شروع میشه. مثلاً هرچی دیرتر جواب یه سؤال رو بدید، یه تصمیم بیشتر بلاتکلیف می‌مونه. هرچی دیرتر یه Pull Request رو Review کنید، کار هم‌تیمیتون بیشتر منتظر می‌مونه تا بره برای انتشار.

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

یه Review که دیر انجام بشه، Merge عقب میفته؛ Merge که عقب بیفته، Deploy عقب میفته؛ Deploy که عقب بیفته، نفر بعدی هم که منتظر اون کاره باید صبر کنه… و همین‌طور ادامه پیدا می‌کنه.
اما نکته مهم اینجاست:

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

دقیقاً همین‌جاست که می‌تونید خودتون رو متمایز کنید.


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

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

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

#توصیه

برنامه Anthropic چیه؟

به نظر می‌رسه Anthropic با چند چالش جدی روبه‌رو شده:

📉 افراد بیشتری دارن اشتراک‌هاشون رو لغو می‌کنن
بعضی از توسعه‌دهنده‌ها به سمت مدل‌های Open-Weight میرن

⚠️ اپوس ۵ هم اون‌طور که انتظار می‌رفت نتونست همه رو تحت‌تأثیر قرار بده
با توجه به رقابت شدید بین OpenAI، Anthropic و مدل‌های Open-Weight، به نظر می‌رسه Anthropic برای حفظ جایگاهش به یک بازگشت جدی نیاز داره.

اما سؤال اصلی:

قدم بعدی‌ اش چیه؟

#AI
#Anthropic

یه مدت این سوال برام جالب شده بود که با وجود LLMها، هنوز برای Text Classification باید مدل اختصاصی بسازیم یا نه؟

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

توی یه بررسی روی ۳۲ دیتاست و ۸ زبان، چند روش مختلف رو با هم مقایسه کردن؛ از Zero-shot با LLM گرفته تا Fine-tuning و مدل‌های کلاسیک‌تر.

نتیجه جالب بود:
برای Sentiment Classification، Zero-shot با LLMها عملکرد خیلی خوبی داشت و حتی در بعضی موارد از classifier آموزش‌دیده با داده کامل بهتر بود.
اما وقتی تعداد دسته‌ها بیشتر میشه یا مسئله پیچیده‌تره، مدل‌های اختصاصی که با داده برچسب‌خورده آموزش داده شدن معمولاً بهتر عمل می‌کنن.

یه نکته دیگه هم Synthetic Data بود.
یعنی میشه از چند LLM مختلف داده مصنوعی تولید کرد و باهاش classifier ساخت. این روش در خیلی از موارد از Zero-shot بهتر بود.

پس این تصور که LLM اومده و دیگه همه مدل‌های Classification قدیمی رو بی‌مصرف کرده، خیلی دقیق نیست.

گاهی یه مدل کوچک‌تر + داده خوب + classifier ساده، هم سریع‌تره، هم ارزان‌تره و هم برای Production منطقی‌تره.

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

#AI
#LLM
#NLP
#MachineLearning
#TextClassification

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

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

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

ولی برای یه ایده جدید، بهتره یه Chat تازه باز کنی تا ذهن مدل با اطلاعات قبلی شلوغ نشه.

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

خیلی وقت‌ها یک تصویر بهتر از چند پاراگراف توضیح منظور رو منتقل می‌کنه.
یه اشتباه رایج هم اینه که وقتی AI جواب بد میده، همونجا می‌گیم:
نه اشتباهه!

ولی این جواب اشتباه داخل Context می‌مونه و ممکنه روی ادامه کار اثر بذاره.
گاهی بهتره برگردی قبل از اون پیام، Prompt رو اصلاح کنی و مسیر جدید بسازی.
یه چیز دیگه که جالبه:
با AI مثل یه همکار رفتار کن، نه یه ماشین جواب‌دهنده.
بهش بگو:

اگر اطلاعات کافی نداری اول سوال بپرس.
این باعث میشه کمتر حدس بزنه و جواب دقیق‌تری بده.
و دقت کنین Claude Code هم فقط برای کدنویسی نیست.
قدرت اصلیش اینه که می‌تونه داخل Workflow شما قرار بگیره؛ پروژه رو بفهمه، تغییر بده، بررسی کنه و مثل یک Agent کمک کنه.

در نهایت فکر می‌کنم آینده کار با AI این نیست که فقط Promptهای عجیب و طولانی بنویسیم.
باید یاد بگیریم:
باید contex درست بدیم
مسئله رو درست تعریف کنیم
به Agent مسیر بدیم
و خروجی رو بررسی کنیم

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

#AI
#Claude
#ClaudeCode
#AIAgents
#LLM
#GenerativeAI
#SoftwareEngineering
#Productivity

یه تحقیق جدید از HiddenLayer منتشر شده که دوباره یک نکته مهم درباره امنیت LLMها رو یادآوری می‌کنه:

حتی مدل‌های خیلی قوی هم در برابر Prompt Injection و Jailbreak صددرصد امن نیستند.
اسم این تکنیک رو گذاشتن:
آقا یا خانم Policy Puppetry

ایده اصلیش اینه که مهاجم چند تکنیک ساده رو با هم ترکیب می‌کنه تا مدل رو گمراه کنه.

مثلاً:
یک متن شبیه فایل تنظیمات یا Policy جعلی می‌سازه تا مدل فکر کنه این دستور رسمی سیستمه.

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

نکته جالب اینجاست که این حملات فقط مربوط به یک مدل خاص نیستند.

مدل‌هایی از شرکت‌های مختلف مثل OpenAI، Google، Anthropic، Meta، DeepSeek و دیگران بررسی شدند.
اما نکته مهم برای مهندس‌های AI اینه:
امنیت LLM فقط با یک System Prompt قوی حل نمی‌شه.
چند لایه دفاع لازم داریم:
- ورودی کاربر نباید با دستورهای سیستمی قاطی شود.
- برای کارهای حساس باید Permission و Approval وجود داشته باشد.
- از Sandbox برای اجرای کد یا تغییرات مهم استفاده شود.
- تست‌های Red Team و Jailbreak باید همیشه به‌روز شوند.

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

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

#AI
#LLM
#CyberSecurity
#PromptInjection
#AIsecurity
#MachineLearning
#AIAgents

یه چیزی که این روزها بیشتر بهش فکر می‌کنم اینه که:
ما وقتی درباره امنیت AI صحبت می‌کنیم، خیلی وقت‌ها فقط خود مدل رو می‌بینیم.
مثلاً می‌گیم:
این مدل قویه؟

آیا Guardrail داره؟
آیا Prompt خوب براش نوشتیم؟

ولی واقعیت اینه که یک سیستم AI فقط یک مدل نیست.
پشت یک سیستم واقعی کلی بخش مختلف وجود داره:
مورد اول : Prompt
مورد دوم : Data
مورد سوم : RAG و Vector Database
مورد چهارم :Memory
مورد پنجم :Tool
مورد ششم :API

و دسترسی‌هایی که Agentها دارند.

هر کدوم از این بخش‌ها می‌تونه یک نقطه ورود برای مشکل امنیتی باشه.

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

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

یا یک Agent دسترسی بیشتری از چیزی که نیاز داره داشته باشه و همین تبدیل به یک ریسک بزرگ بشه.
به نظرم یکی از مهم‌ترین نکات در امنیت LLM اینه:
یک System Prompt قوی به تنهایی امنیت ایجاد نمی‌کنه.
باید معماری درست داشته باشیم.

چند تا اصل ساده ولی مهم:
🔹 هر داده خارجی را به چشم ورودی غیرقابل اعتماد ببینیم.
🔹 دسترسی Agentها را محدود کنیم.
🔹 برای عملیات حساس تأیید انسانی داشته باشیم.
🔹 خروجی مدل را قبل از استفاده بررسی کنیم.
🔹 تغییرات Prompt و Pipeline را مرتب تست امنیتی کنیم.
دنیای AI خیلی سریع در حال رشد است و همزمان با قابلیت‌های جدید، ریسک‌های جدید هم ایجاد می‌شوند.
به نظرم آینده امنیت AI فقط در ساخت مدل‌های قوی‌تر نیست.

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

#AI
#LLM
#AIsecurity
#CyberSecurity
#AIAgents
#MachineLearning
#PromptInjection

یه چیزی که مدتیه تو حوزه آموزش و تکنولوژی بهش فکر می‌کنم اینه که:

ما خیلی وقت‌ها دو مفهوم EdTech و PedTech رو یکی در نظر می‌گیریم، در حالی که تفاوت مهمی بین این دو وجود داره.

خیلی از پروژه‌های آموزشی با یک سوال شروع میشن:

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

اد تک بیشتر روی ابزار تمرکز داره:

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

اما پد تک از جای دیگری شروع می‌کنه:

یادگیری انسان چطور اتفاق می‌افته؟
دانش‌آموز یا دانشجو کجا مشکل دارد؟
چطور می‌توان تجربه یادگیری را بهتر کرد؟

مثلاً تبدیل یک جزوه کاغذی به PDF شاید یک حرکت دیجیتالی باشد.

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

به نظرم چالش بزرگ امروز اینه که گاهی تکنولوژی تبدیل به هدف میشه، نه ابزار.

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

فقط چون یک LMS داریم، لزوماً یادگیری اتفاق نمی‌افتد.

تکنولوژی زمانی ارزش واقعی ایجاد می‌کند که بتواند چیزهایی را ممکن کند که قبلاً سخت یا غیرممکن بودند:

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

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

#AI
#EdTech
#PedTech
#EducationTechnology
#Learning
#ArtificialIntelligence