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

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

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

من فکر نمی‌کنم طی ۵ سال آینده حتی یک اپلیکیشن جدی روی اینترنت وجود داشته باشه که به یک ارائه‌دهنده مدل زبانی درخواست 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

تا حالا شده از ChatGPT یا Claude یه سوال بپرسی و چند ثانیه بعد جواب آماده بشه، ولی به این فکر کنی پشت این چند ثانیه چه اتفاقی میفته؟
مدل‌های زبانی مستقیم با کلمه‌هایی که ما می‌نویسیم کار نمی‌کنن.

اول متن وارد Tokenizer میشه و به بخش‌های کوچکتری به اسم Token تبدیل میشه. بعد هر Token به یک عدد تبدیل میشه تا مدل بتونه اون رو پردازش کنه.

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

اینجا Self-Attention باعث میشه مدل ارتباط بین Tokenهای مختلف رو بررسی کنه؛ یعنی بفهمه کدوم بخش‌های متن برای تولید پاسخ مهم‌تر هستند.

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

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

مدل در واقع یک کلمه آماده انتخاب نمی‌کنه؛ برای Tokenهای مختلف احتمال در نظر می‌گیره و بر اساس روش انتخاب، خروجی می‌تونه متفاوت باشه.
مثلاً:
مورد اول : Greedy همیشه محتمل‌ترین گزینه رو انتخاب می‌کنه.
مورد دوم : Top-K از بین چند گزینه برتر انتخاب می‌کنه.
مورد سوم :Top-P انتخاب رو بر اساس مجموع احتمال‌ها محدود می‌کنه.

آقای Temperature هم میزان خلاقیت و تصادفی بودن خروجی رو تغییر میده.

یک تکنیک جالب دیگه هم Speculative Decoding هست.
اینجا یک مدل کوچک‌تر چند Token آینده رو حدس می‌زنه و مدل اصلی اون‌ها رو بررسی می‌کنه. اگر درست باشند، سرعت تولید بیشتر میشه.

در آخر Tokenها دوباره به متن قابل فهم تبدیل میشن و پاسخ به صورت Stream نمایش داده میشه.

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

ولی مرحله تولید پاسخ بیشتر با محدودیت حافظه درگیر است.

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

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

#AI
#LLM
#Transformer
#MachineLearning
#DeepLearning
#AIInfrastructure

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

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

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


این تغییر باعث میشه روش‌های سنتی دفاع هم کافی نباشند.
قبلاً شاید بررسی Link یا Attachment تا حد زیادی کمک می‌کرد.

اما وقتی تهدید تبدیل به یک مکالمه طبیعی میشه، باید چیزهای دیگری بررسی شوند:

رفتار فرستنده
الگوی گفتگو
تغییر ناگهانی درخواست‌ها
درخواست‌های حساس مثل انتقال پول یا دسترسی
به نظرم یکی از مهم‌ترین تغییرات امنیت در عصر Agentها اینه که دیگر فقط نباید بپرسیم:

این پیام مخرب است یا نه؟
باید بپرسیم:
آیا این رفتار با الگوی معمول این فرد یا سیستم هماهنگ است؟
در آینده احتمالاً دفاع هم باید Agent محور شود.

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

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

دسترسی محدود، ثبت رویدادها، تأیید انسانی برای عملیات حساس و طراحی امن، بخش مهم این مسیر هستند.

به نظرم Phishing 3.0 بیشتر از اینکه یک مشکل ایمیل باشد، یک مسئله اعتماد در دنیای Agentهاست.

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

#CyberSecurity
#AI
#AIAgents
#Phishing
#AIsecurity
#EmailSecurity
#AgenticAI

آقا بذارید از تجربه‌ ام براتون بگم...

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

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

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

وضعیت فعلی چیه؟
طبق یه وبینار گارتنر، فقط ۶ درصد از ۳۴۰۰ نفر گفته بودن شرکت‌شون ایجنت هوش مصنوعی مستقر کرده. شاید به نظرتون کمه، ولی من می‌گم دقیقاً همون‌جاییه که باید باشه.

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

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

چند تا مثال واقعی:

- گروه آدکو با ایجنت‌های Agentforce تونسته برای یکی از مشتریا ۱۰۰٪ موقعیت‌های شغلی رو پر کنه (قبلاً معمولاً ۷۰٪ بود).
- ویزا و ServiceNow یه سیستم حل اختلاف مبتنی بر ایجنت ساختن که تو ۱۲ هفته یه بانک رو کاملاً عملیاتی کردن.
- لیگ ملی هاکی داره با داده‌های عظیم کار می‌کنه تا ایجنت‌ها خودشون داستان و بینش‌های جذاب برای پخش‌کننده‌ها پیدا کنن.

تغییر مهارت‌ها نزدیکه دوستان
بیل گیتس می‌گفت ما تأثیر کوتاه‌مدت تکنولوژی رو دست‌بالا می‌گیریم و تأثیر بلندمدتش رو دست‌کم. با ایجنت‌ها، اون «بلندمدت» شاید فقط ۲-۳ سال دیگه باشه.

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

به نظرم منابع انسانی باید جلودار این ماجرا باشه، نه فقط بخش فناوری.

شما چی فکر می‌کنید؟ شرکتتون شروع کرده یا هنوز منتظره؟

#هوش_مصنوعی
#ایجنت_هوش_مصنوعی
#آینده_کار
#منابع_انسانی
#تحول_دیجیتال

#FutureOfWork
#HRTech
#DigitalWorkers

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

نکته مهم اینه که اصولش فقط مخصوص Claude نیست. می‌تونی همون الگوها رو روی Codex، Aider، Cursor یا practically هر coding agent دیگه‌ای هم پیاده کنی.

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

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

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

برنامه‌ریزی اختیاری نیست.
برای مسائل چندمرحله‌ای نمی‌تونی انتظار داشته باشی مدل خودش همه‌چیز رو درست جلو ببره. الگوهایی مثل plan → execute → review یا reflection ساختاریافته واقعاً لازم‌ان و روی همه مدل‌ها جواب می‌دن.

ایجنت واقعی به ابزار واقعی نیاز داره.
دسترسی به shell، Git، API و ابزارهای اجرایی. ایجنتی که فقط توضیح می‌ده و اجرا نمی‌کنه، در محیط واقعی محدود می‌مونه.

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

ارزش اصلی در orchestration.
یه ایجنت خوب فقط wrapper دور یه مدل زبانی نیست. هماهنگ‌کننده منطقه، حافظه، ابزارها و بازخورد. وقتی به سمت multi-agent می‌ری، این هماهنگی تقریباً همه‌چیز می‌شه.

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

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

#Anthropic
#AIAgents
#AgenticAI
#LLM
#SoftwareEngineering

دوستان یک موقعیت امریه وجود داره
اگر تمایل دارید رزومه تونو بفرستید

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

امروز داشتم مقاله‌ای رو می‌خوندم درباره اینکه چرا قابلیت اجرای مرورگر (Browser Execution) داره به یکی از حلقه‌های مفقوده در معماری ایجنت‌ها تبدیل می‌شه. موضوع طوری بود که حیفم اومد باهاتون به اشتراک نذارمش، چون دست می‌ذاره روی یکی از نقطه‌کورهای اصلیِ طراحی سیستم‌های مبتنی بر ایجنت (Agentic Systems).

🌐 ماجرا چیه دقیقا ؟
خیلی از ما وقتی داریم ایجنت می‌سازیم، همه تمرکزمون روی API Calling، اتصال به MCP، اجرای کد توی Sandbox، یا خواندن دیتابیسه. این ابزارها فوق‌العاده‌ان و برای سیستم‌های ساختاریافته جواب می‌دن.

اما واقعیت دنیای نرم‌افزار چیه؟ بخش عظیمی از سامانه‌های واقعی (مخصوصاً سرویس‌های قدیمی، پورتال‌های داخلی شرکت‌ها، داشبوردهای تحلیل داده و...) هیچ API پایدار و عمومی ندارند!

تنها رابطی که وجود داره، همون UI و مرورگریه که برای انسان طراحی شده.

💡 چند تا نکته کلیدی که خیلی چسبید:

1️⃣ مرورگر یک محیط اجراست (Execution Environment)، نه فقط یک ابزار ساده:
خیلیا فکر می‌کنند Browsing یعنی اینکه فقط یه ایجنت بفرستیم وب رو بگرده! اما اصل حرف اینه که مرورگر رو باید مثل یک Runtime نگاه کرد که ایجنت می‌تونه توش کد اجرا کنه، Session و Cookieها رو مدیریت کنه و با UIهایی که API ندارند تعامل داشته باشه.

2️⃣ تعامل با پروتکل‌های ارتباطی — آیا ابزارهای استاندارد جای مرورگر رو می‌گیرند؟
پاسخ کوتاه: نه، مکمل همدیگه‌ان.
پروتکل‌های یکپارچه‌سازی فقط نحوه برقراری ارتباط ایجنت با یک ابزار را استاندارد می‌کنند. حالا اون ابزار پشت صحنه می‌تونه خودش یک Browser Instance باشه که داره فرآیند احراز identity، حل SSO یا گرفتن داده از یک داشبورد پیچیده رو انجام می‌ده.

3️⃣ ترکیب اجرای کد و مرورگر:
بهترین الگوی معماری اینه که به جای فرستادن دستورات سنگین و بصری (مثل آنالیز فریم به فریم اسکرین‌شات)، به ایجنت اجازه بدیم کد مرورگر بنویسه و توی یک محیط ایزوله اجرا کنه. هم هزینه‌ها بشدت میاد پایین، هم سرعت و قطعیت (Determinism) کار بالا می‌ره.

🎯 جمع‌بندی شخصیم:
اگر دارید روی ایجنت‌های دنیای واقعی کار می‌کنید، نباید فرض کنید همه‌چیز قراره با یک API تمیز و آماده حل بشه. Browser Execution همون لینک گمشده‌ای هست که ایجنت شما رو از یک «مدل نظری» به یک «ابزار اجرایی در دنیای کثیف و واقعی نرم‌افزار» تبدیل می‌کنه.

آخر هفته خوبی براتون آرزومند هستم✨

#AIAgents
#LLM
#SystemDesign
#BrowserExecution
#MCP

امروز داشتم پرونده‌های اخیر FBI و بیانیه‌های ۱۰ میلیون دلاری آمریکا برای هکرهایی مثل علیرضا شفیع‌نسب، محمدباقر شیرین‌کار و فاطمه صدیقیان کاشی رو بررسی می‌کردم.

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

تکتیک اصلی این افراد خرید و اجاره سرورهای ابری داخل خود آمریکا با هویت‌های سرقتی بوده تا ترافیک حملات کاملاً بومی به نظر برسه و سیستم‌های Threat Intelligence رو دور بزنه.

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

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

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

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