⚔️ در اکوسیستم LLMها هم مثل بسیاری از حوزههای نرمافزار، به نظر میرسد دو جبهه وجود دارد: Open Source و Closed Source.
🚨 جالب است که بخش قابل توجهی از هشدارها درباره خطرات AI، رگولیشن و محدود کردن دسترسی عمومی، از سمت شرکتهایی مطرح میشود که مدلهایشان را بهصورت بسته توسعه میدهند.
📜 این داستان هم جدید نیست. سال ۲۰۱۹، OpenAI انتشار کامل GPT-2 را به دلیل «خطرات بالقوه سوءاستفاده» به تعویق انداخت. امروز هم روایتهای مشابهی را در قالب AGI، سناریوهای آخرالزمانی و ماجراهایی مثل Mythos و Fable میبینیم.
🌏 در مقابل، شرکتهایی مثل Qwen و Kimi مدلهای قدرتمند خود را منتشر میکنند و بخش بزرگی از این جریان نیز خارج از آمریکا شکل گرفته است.
❓سؤال اینجاست:
آیا نگرانیهای ایمنی واقعاً دغدغه اصلی هستند، یا «ایمنی» گاهی به ابزاری برای حفظ مزیت رقابتی تبدیل میشود؟
🔓 بهخصوص وقتی مدلهای متنباز این امکان را میدهند که افراد و سازمانها بدون وابستگی به ارائهدهندگان بزرگ، مدلها را روی زیرساخت خود اجرا کنند.
🚨 جالب است که بخش قابل توجهی از هشدارها درباره خطرات AI، رگولیشن و محدود کردن دسترسی عمومی، از سمت شرکتهایی مطرح میشود که مدلهایشان را بهصورت بسته توسعه میدهند.
📜 این داستان هم جدید نیست. سال ۲۰۱۹، OpenAI انتشار کامل GPT-2 را به دلیل «خطرات بالقوه سوءاستفاده» به تعویق انداخت. امروز هم روایتهای مشابهی را در قالب AGI، سناریوهای آخرالزمانی و ماجراهایی مثل Mythos و Fable میبینیم.
🌏 در مقابل، شرکتهایی مثل Qwen و Kimi مدلهای قدرتمند خود را منتشر میکنند و بخش بزرگی از این جریان نیز خارج از آمریکا شکل گرفته است.
❓سؤال اینجاست:
آیا نگرانیهای ایمنی واقعاً دغدغه اصلی هستند، یا «ایمنی» گاهی به ابزاری برای حفظ مزیت رقابتی تبدیل میشود؟
🔓 بهخصوص وقتی مدلهای متنباز این امکان را میدهند که افراد و سازمانها بدون وابستگی به ارائهدهندگان بزرگ، مدلها را روی زیرساخت خود اجرا کنند.
👍4❤3👏1👌1
⚠️ در ادامه پست قبلی، چند روز پیش استاد اعظم «بروس اشنایر» مقالهای منتشر کرده که امروز فرصت کردم بخوانمش.
مطالعهاش را به شدید توصیه میکنم.
https://www.schneier.com/blog/archives/2026/06/anthropics-fable-and-the-state-of-ai.html
مطالعهاش را به شدید توصیه میکنم.
https://www.schneier.com/blog/archives/2026/06/anthropics-fable-and-the-state-of-ai.html
Schneier on Security
Anthropic's Fable and the State of AI - Schneier on Security
On June 9th, Anthropic released its Fable generative AI model. Three days later, the US government classified it as a dangerous munition, and used its export-control authority to prohibit any foreign nationals from accessing it. Unable to differentiate between…
👌3🥰1
دنیای فیلمها و داستانهای علمیتخیلی معمولاً نگاه تاریکی به هوش مصنوعی دارد، از Skynet گرفته تا انواع سناریوهای آخرالزمانی
اما یک استثنای بزرگ وجود دارد: ایزاک آسیموف.
آسیموف نهفقط خالق «سه قانون رباتیک» بود، بلکه دهها داستان و رمان درباره رابطه انسان و ربات نوشت، داستانهایی که برخلاف جریان غالب، صرفاً بر پایه ترس از هوش مصنوعی ساخته نشدهاند.
البته آسیموف هم مثل خیلی از نویسندههای علمیتخیلی، برای پیش بردن داستان معمولاً به رباتها ظاهر و رفتار انسانگونه میداد. اما اگر پوسته داستان را کنار بزنیم، با سؤالها و چالشهایی روبهرو میشوید که شباهت عجیبی به بحثهای امروز AI دارند.
یکی از داستانهای مجموعه «روبات کامل» به نام Galley Slave دقیقاً از همین جنس است. داستانی که موقع خواندنش گاهی حس میکنید آسیموف چند دهه قبل نشسته و درباره روزگار ما نوشته است.
ترجمه فارسی «روبات کامل» توسط کتابسرای تندیس در سه جلد منتشر شده و این داستان با نام «جان کَن» در جلد دوم قرار دارد.
اگر هم حوصله خواندن ندارید، نریشن انگلیسی داستان را میتوانید از لینک زیر گوش کنید:
https://www.youtube.com/watch?v=C8e_0c8nbFA
اما یک استثنای بزرگ وجود دارد: ایزاک آسیموف.
آسیموف نهفقط خالق «سه قانون رباتیک» بود، بلکه دهها داستان و رمان درباره رابطه انسان و ربات نوشت، داستانهایی که برخلاف جریان غالب، صرفاً بر پایه ترس از هوش مصنوعی ساخته نشدهاند.
البته آسیموف هم مثل خیلی از نویسندههای علمیتخیلی، برای پیش بردن داستان معمولاً به رباتها ظاهر و رفتار انسانگونه میداد. اما اگر پوسته داستان را کنار بزنیم، با سؤالها و چالشهایی روبهرو میشوید که شباهت عجیبی به بحثهای امروز AI دارند.
یکی از داستانهای مجموعه «روبات کامل» به نام Galley Slave دقیقاً از همین جنس است. داستانی که موقع خواندنش گاهی حس میکنید آسیموف چند دهه قبل نشسته و درباره روزگار ما نوشته است.
ترجمه فارسی «روبات کامل» توسط کتابسرای تندیس در سه جلد منتشر شده و این داستان با نام «جان کَن» در جلد دوم قرار دارد.
اگر هم حوصله خواندن ندارید، نریشن انگلیسی داستان را میتوانید از لینک زیر گوش کنید:
https://www.youtube.com/watch?v=C8e_0c8nbFA
👍5❤2🔥1🥰1👏1
🛠 بین دهها «Code Harness» مختلف، تا الان فرصت کار با اینها رو داشتم:
* GitHub Copilot
* OpenCode
* Pi
* Kiro CLI
* Claude Code
🚀 شروع کار من هم مثل خیلیها با GitHub Copilot بود، اما کمکم به سمت ابزارهای ترمینالمحور و مستقلتر رفتم.
⚙️ فعلاً OpenCode هارنس پیشفرض منه، ولی کمکم دارم به مهاجرت به Pi فکر میکنم. از نظر تجربه کار در ترمینال و فلسفه طراحی، Pi به چیزی که از ابزارهای لینوکسی انتظار دارم نزدیکتره. حسی که دارم اینه که OpenCode بیشتر با ذهنیت کاربران macOS طراحی شده.
🔓 هم OpenCode و هم Pi متنباز هستند؛ بنابراین میتوانید دقیقاً ببینید هارنس چطور کار میکنه، System Prompt هارنس چیه و چه ابزارهایی در اختیار مدل قرار میده. اگر هم خواستید، بهراحتی میتوانید رفتارش را تغییر بدید.
🔒 از طرف دیگر، به نظر میرسه اکوسیستم Anthropic روزبهروز بستهتر میشه. Claude Code عملاً شما را به مدلهای خودش محدود کرده و به نظر میرسه تمرکز شرکت بیشتر روی هدایت کاربران به سمت اکوسیستم خودش باشه. حتی بعضی وقتها این حس رو دارم که تمام تلاششون اینه که هزینه استفاده از مدلها برای افراد خارج از اکوسیستم Claude Code بالاتر باشه.
⚠️ همانطور که در مقاله اخیر بروس اشنایر هم مطرح شده بود، ممکنه بشه با یک هارنس خوب از یک مدل بیشتر از چیزی که روی کاغذ نشون میده کار کشید.
🐧 فعلاً هنوز اول راه هستیم. یک زمانی که توی لینوکس تازهکار بودیم هر هفته توزیع عوض میکردیم؛ این روزها هم هر هفته یک هارنس جدید را امتحان میکنیم.
* GitHub Copilot
* OpenCode
* Pi
* Kiro CLI
* Claude Code
🚀 شروع کار من هم مثل خیلیها با GitHub Copilot بود، اما کمکم به سمت ابزارهای ترمینالمحور و مستقلتر رفتم.
⚙️ فعلاً OpenCode هارنس پیشفرض منه، ولی کمکم دارم به مهاجرت به Pi فکر میکنم. از نظر تجربه کار در ترمینال و فلسفه طراحی، Pi به چیزی که از ابزارهای لینوکسی انتظار دارم نزدیکتره. حسی که دارم اینه که OpenCode بیشتر با ذهنیت کاربران macOS طراحی شده.
🔓 هم OpenCode و هم Pi متنباز هستند؛ بنابراین میتوانید دقیقاً ببینید هارنس چطور کار میکنه، System Prompt هارنس چیه و چه ابزارهایی در اختیار مدل قرار میده. اگر هم خواستید، بهراحتی میتوانید رفتارش را تغییر بدید.
🔒 از طرف دیگر، به نظر میرسه اکوسیستم Anthropic روزبهروز بستهتر میشه. Claude Code عملاً شما را به مدلهای خودش محدود کرده و به نظر میرسه تمرکز شرکت بیشتر روی هدایت کاربران به سمت اکوسیستم خودش باشه. حتی بعضی وقتها این حس رو دارم که تمام تلاششون اینه که هزینه استفاده از مدلها برای افراد خارج از اکوسیستم Claude Code بالاتر باشه.
⚠️ همانطور که در مقاله اخیر بروس اشنایر هم مطرح شده بود، ممکنه بشه با یک هارنس خوب از یک مدل بیشتر از چیزی که روی کاغذ نشون میده کار کشید.
🐧 فعلاً هنوز اول راه هستیم. یک زمانی که توی لینوکس تازهکار بودیم هر هفته توزیع عوض میکردیم؛ این روزها هم هر هفته یک هارنس جدید را امتحان میکنیم.
👍2🔥2❤1
🔒 یکم بیشتر توضیح بدم که چرا «حس» میکنم اکوسیستم Anthropic روزبهروز بستهتر میشه.
قبلاً Anthropic اجازه میداد از اشتراک Claude در هارنسهای دیگر هم استفاده کنید. اما بعد از موفقیت ابزارهای دیگه، این امکان حذف شد و عملاً برای استفاده خارج از اکوسیستم Claude باید سراغ API میرفتید؛ روشی که معمولاً هزینه بسیار بیشتری نسبت به اشتراک عادی دارد.
بعدها حتی بسیاری از اپلیکیشنهایی که روی اشتراک Claude حساب کرده بودند هم مجبور شدند به API مهاجرت کنند. برای بعضی استارتاپها این فقط یک تغییر فنی نبود، بلکه مستقیماً روی هزینهها و مدل کسبوکارشان اثر گذاشت.
نکته دیگر این است که Claude Code متنباز نیست. وقتی بخشی از سورس آن به اشتباه منتشر شد، مشخص شد بخشهایی از پیادهسازی فاصله زیادی با تصویری دارد که معمولاً از آن ارائه میشود. از آنجایی که سورس بسته است، عملاً امکان بررسی مستقل رفتار هارنس هم وجود ندارد.
یک نکته دیگه که بهشدت رو اعصابه اینه که تقریباً اکثر هارنسها روی فایل AGENTS.md به یک توافق نانوشته رسیدهاند، اما Claude Code مسیر خودش را رفته و از CLAUDE.md استفاده میکند.
ممکن است بگن که Codex هم متنباز نیست، که درسته. اما تفاوتش برای من اینجاست که اگر از Codex استفاده نکنم (که نمیکنم)، همچنان میتوانم با همان هزینه معمول به مدلهای OpenAI دسترسی داشته باشم. در اکوسیستم Anthropic این انتخاب روزبهروز محدودتر به نظر میرسد.
در نهایت، چیزی که من را نگران میکند خود بسته بودن سورس نیست؛ بلکه این ساختار بسته اکوسیستم است که ممکنه بعد از مدتی با روشهای مختلف سعی کنه ما را به استفاده از ابزارهای خودش سوق بده.
قبلاً Anthropic اجازه میداد از اشتراک Claude در هارنسهای دیگر هم استفاده کنید. اما بعد از موفقیت ابزارهای دیگه، این امکان حذف شد و عملاً برای استفاده خارج از اکوسیستم Claude باید سراغ API میرفتید؛ روشی که معمولاً هزینه بسیار بیشتری نسبت به اشتراک عادی دارد.
بعدها حتی بسیاری از اپلیکیشنهایی که روی اشتراک Claude حساب کرده بودند هم مجبور شدند به API مهاجرت کنند. برای بعضی استارتاپها این فقط یک تغییر فنی نبود، بلکه مستقیماً روی هزینهها و مدل کسبوکارشان اثر گذاشت.
نکته دیگر این است که Claude Code متنباز نیست. وقتی بخشی از سورس آن به اشتباه منتشر شد، مشخص شد بخشهایی از پیادهسازی فاصله زیادی با تصویری دارد که معمولاً از آن ارائه میشود. از آنجایی که سورس بسته است، عملاً امکان بررسی مستقل رفتار هارنس هم وجود ندارد.
یک نکته دیگه که بهشدت رو اعصابه اینه که تقریباً اکثر هارنسها روی فایل AGENTS.md به یک توافق نانوشته رسیدهاند، اما Claude Code مسیر خودش را رفته و از CLAUDE.md استفاده میکند.
ممکن است بگن که Codex هم متنباز نیست، که درسته. اما تفاوتش برای من اینجاست که اگر از Codex استفاده نکنم (که نمیکنم)، همچنان میتوانم با همان هزینه معمول به مدلهای OpenAI دسترسی داشته باشم. در اکوسیستم Anthropic این انتخاب روزبهروز محدودتر به نظر میرسد.
در نهایت، چیزی که من را نگران میکند خود بسته بودن سورس نیست؛ بلکه این ساختار بسته اکوسیستم است که ممکنه بعد از مدتی با روشهای مختلف سعی کنه ما را به استفاده از ابزارهای خودش سوق بده.
👌2🔥1
🌐 تقریباً هر زمان که بخوام با یک مدل درباره موضوعات فنی صحبت کنم، سراغ انگلیسی میرم. اوایل این کار رو برای گرفتن جواب بهتر انجام میدادم و البته توضیح دادن موضوعات فنی به انگلیسی هم راحتتر بود. بعد کمکم تبدیل به عادت شد و رفتم ببینم این عادت درست هست یا نه که به چند چیز جالب رسیدم.
اول از همه اینکه تقریباً تمام مدلهای بزرگ روی حجم عظیمی از محتوای انگلیسی آموزش دیدهاند و بخش بزرگی از مستندات، کدها، مقالات و بحثهای فنی اینترنت هم به زبان انگلیسی هستند.
از اون مهمتر، تقریباً توی همه هارنسها System Prompt و پرامپتهای داخلی به زبان انگلیسی نوشته شده. یعنی شما از همون لحظه اول دارید با سیستمی کار میکنید که تقریباً همه اجزاش حول زبان انگلیسی ساخته شدهاند.
یه نکته دیگه هم اینه که مدلها کلمات رو «درک» نمیکنن. متن تبدیل به توکن میشه و تمام پردازش پشت صحنه روی همین توکنها انجام میشه. طبیعتاً هر زبانی که توی دادههای آموزشی، فرایند آموزش و ارزیابی مدل حضور پررنگتری داشته باشه، معمولاً خروجی بهتری هم میده.
از اون طرف، بخش بزرگی از Safety Training، Preference Tuning و حتی Benchmark Testing مدلها هم به زبان انگلیسی انجام میشه. برای همین خیلی عجیب نیست که مدلها توی خیلی از کارهای فنی روی انگلیسی عملکرد بهتری داشته باشن.
این به این معنی نیست که مدلها فارسی بلد نیستن؛ اتفاقاً فارسیشون هر روز بهتر میشه. اما وقتی پای بحثهای فنی وسط باشه، هنوز هم انگار زبان مادریشون انگلیسیه 😁
اول از همه اینکه تقریباً تمام مدلهای بزرگ روی حجم عظیمی از محتوای انگلیسی آموزش دیدهاند و بخش بزرگی از مستندات، کدها، مقالات و بحثهای فنی اینترنت هم به زبان انگلیسی هستند.
از اون مهمتر، تقریباً توی همه هارنسها System Prompt و پرامپتهای داخلی به زبان انگلیسی نوشته شده. یعنی شما از همون لحظه اول دارید با سیستمی کار میکنید که تقریباً همه اجزاش حول زبان انگلیسی ساخته شدهاند.
یه نکته دیگه هم اینه که مدلها کلمات رو «درک» نمیکنن. متن تبدیل به توکن میشه و تمام پردازش پشت صحنه روی همین توکنها انجام میشه. طبیعتاً هر زبانی که توی دادههای آموزشی، فرایند آموزش و ارزیابی مدل حضور پررنگتری داشته باشه، معمولاً خروجی بهتری هم میده.
از اون طرف، بخش بزرگی از Safety Training، Preference Tuning و حتی Benchmark Testing مدلها هم به زبان انگلیسی انجام میشه. برای همین خیلی عجیب نیست که مدلها توی خیلی از کارهای فنی روی انگلیسی عملکرد بهتری داشته باشن.
این به این معنی نیست که مدلها فارسی بلد نیستن؛ اتفاقاً فارسیشون هر روز بهتر میشه. اما وقتی پای بحثهای فنی وسط باشه، هنوز هم انگار زبان مادریشون انگلیسیه 😁
👍4🥰1👌1
AGENTS.md
1.5 KB
📝 در ادامه پست قبلی، یه نکته رو هم بگم:
با وجود اینکه معمولاً برای کارهای فنی با مدلها انگلیسی حرف میزنم، انگلیسی من اصلاً در حدی نیست که ادعا کنم بدون اشتباه مینویسم. مخصوصاً وقتی پرامپت طولانی میشه یا میخوام یه مسئله پیچیده رو توضیح بدم.
برای همین یه Agent جدا دارم که هیچ کار خاصی نمیکنه، نه کد مینویسه، نه تحلیل میکنه و نه جواب فنی میده. تنها وظیفهاش اینه که متن رو از نظر گرامری و املایی بررسی کنه و نسخه تمیزتری تحویل بده.
معمولاً پرامپتهای طولانی رو اول به اون Agent میدم، بعد خروجی اصلاحشده رو به Agent اصلی میدم که قراره کار فنی انجام بده. اینطوری احتمال اینکه به خاطر انگلیسی افتضاح من موضوع رو اشتباه متوجه بشه کمتر میشه.
فایل AGENTS.md که برای این Agent استفاده میکنم رو هم اینجا میذارم.
با وجود اینکه معمولاً برای کارهای فنی با مدلها انگلیسی حرف میزنم، انگلیسی من اصلاً در حدی نیست که ادعا کنم بدون اشتباه مینویسم. مخصوصاً وقتی پرامپت طولانی میشه یا میخوام یه مسئله پیچیده رو توضیح بدم.
برای همین یه Agent جدا دارم که هیچ کار خاصی نمیکنه، نه کد مینویسه، نه تحلیل میکنه و نه جواب فنی میده. تنها وظیفهاش اینه که متن رو از نظر گرامری و املایی بررسی کنه و نسخه تمیزتری تحویل بده.
معمولاً پرامپتهای طولانی رو اول به اون Agent میدم، بعد خروجی اصلاحشده رو به Agent اصلی میدم که قراره کار فنی انجام بده. اینطوری احتمال اینکه به خاطر انگلیسی افتضاح من موضوع رو اشتباه متوجه بشه کمتر میشه.
فایل AGENTS.md که برای این Agent استفاده میکنم رو هم اینجا میذارم.
👍4🔥1👌1
🤖 یکی از بحثهایی که با آمدن AI Agentها جدیتر شده اینه که اگر یک ایجنت خرابکاری کرد، مقصر کیه؟
مدل؟ ابزار؟ هارنس؟ یا کسی که اون ایجنت رو راه انداخته؟
⚠️ اسپویلر آلرت:مسئولیت نهایی همچنان با آدمه 😁😈.
فرقی نمیکنه کد رو خودت نوشته باشی یا Claude، GPT، Copilot یا هر Agent دیگهای تولیدش کرده باشه. در نهایت تو بودی که مدل رو انتخاب کردی، بهش ابزار دادی، دسترسی تعریف کردی، پرامپت نوشتی و اجازه دادی وارد محیط واقعی بشه.
📄 اینجا باید دقت کنیم که نوشتن Rules توی فایل AGENTS.md بهتنهایی کافی نیست. اگر بخوام همین موضوع رو بدون AI Agent توضیح بدم، میشه این:
شما به دولوپر میگید که چیزی رو مستقیم توی main پوش نکنه و حتماً برای تغییرات PR باز کنه. روز بعد دولوپر یه کد رو مستقیم توی main پوش میکنه، پایپلاین اجرا میشه و پروداکشن به فنا میره.
🔐 اینجا مقصر اصلی شما هستید، نه دولوپر؛ چون دسترسی push به main رو محدود نکردید.
با AI قضیه حساستر هم میشه. چون یک Agent میتونه در چند ثانیه کاری رو انجام بده که قبلاً شاید یک انسان برای انجام دادنش چند دقیقه یا چند ساعت وقت لازم داشت. اگر به چنین چیزی دسترسی production بدیم و همه چیز بریزه به هم، نمیتونیم بگیم «AI این کار رو کرد».
🧠این AI Agent فقط یه ابزار جدیده؛ تصمیم و مسئولیت هنوز با آدمه.
مدل؟ ابزار؟ هارنس؟ یا کسی که اون ایجنت رو راه انداخته؟
⚠️ اسپویلر آلرت:
فرقی نمیکنه کد رو خودت نوشته باشی یا Claude، GPT، Copilot یا هر Agent دیگهای تولیدش کرده باشه. در نهایت تو بودی که مدل رو انتخاب کردی، بهش ابزار دادی، دسترسی تعریف کردی، پرامپت نوشتی و اجازه دادی وارد محیط واقعی بشه.
📄 اینجا باید دقت کنیم که نوشتن Rules توی فایل AGENTS.md بهتنهایی کافی نیست. اگر بخوام همین موضوع رو بدون AI Agent توضیح بدم، میشه این:
شما به دولوپر میگید که چیزی رو مستقیم توی main پوش نکنه و حتماً برای تغییرات PR باز کنه. روز بعد دولوپر یه کد رو مستقیم توی main پوش میکنه، پایپلاین اجرا میشه و پروداکشن به فنا میره.
🔐 اینجا مقصر اصلی شما هستید، نه دولوپر؛ چون دسترسی push به main رو محدود نکردید.
با AI قضیه حساستر هم میشه. چون یک Agent میتونه در چند ثانیه کاری رو انجام بده که قبلاً شاید یک انسان برای انجام دادنش چند دقیقه یا چند ساعت وقت لازم داشت. اگر به چنین چیزی دسترسی production بدیم و همه چیز بریزه به هم، نمیتونیم بگیم «AI این کار رو کرد».
🧠این AI Agent فقط یه ابزار جدیده؛ تصمیم و مسئولیت هنوز با آدمه.
👍3👌1
📝 قبلاً درباره این نوشتم که نوشتن rules توی AGENTS.md بهتنهایی کافی نیست.
👨💻 از نظر من coding agentها شبیه برنامهنویس جونیوری هستن که کتاب و ویدئو زیاد دیدن و شدیداً علاقه دارن با کارشون شما رو تحت تأثیر قرار بدن. برای همین گاهی از خطوطی که براشون کشیدید خارج میشن تا بگن: «ببین من چقدر بلدم!»
⚠️ برای همین اینکه بهشون بگیم «این فایل رو تغییر نده»، «به production دست نزن» یا «secretها رو نخون»، تا وقتی از نظر فنی جلویش را نگرفتیم، بیشتر شبیه توصیه است تا محدودیت واقعی.
🖥 وقتی به یک AI Agent دسترسی shell میدیم، عملاً بهش اجازه میدیم فایل بخونه و تغییر بده، command اجرا کنه، package نصب کنه، network request بزنه و حتی به secretها نزدیک بشه. برای همین کنترل کردن چنین چیزی فقط با prompt یا denylist کافی نیست.
📦 برای کنترل این ریسک، میتونیم از sandbox استفاده کنیم. راههای زیادی برای این کار وجود داره و یکی از نمونههاش nono هست.
https://github.com/nolabs-ai/nono
🔒 ابزار nono یک sandbox برای اجرای Agentهاست که به جای اعتماد به خود مدل یا هارنس، دسترسیها را در سطح سیستمعامل محدود میکند. یعنی میتونید مشخص کنید Agent به کدام مسیرها دسترسی داشته باشه، کجا نتونه بنویسه، چه network accessی داشته باشه و چه چیزهایی براش از اساس غیرممکن باشه.
🔐 این دقیقاً همان تفاوت بین نصیحت کردن یک دولوپر و بستن دسترسی push به main است.
🧪 البته sandbox هم مثل هارنسها یک جواب واحد نداره؛ باید تست کنیم و ببینیم کدوم روش برای کدوم کار مناسبتره.
🚧 ممکنه چیزی که روی سیستم خودمون خوب جواب میده، برای pipeline گیت یا محیط CI/CD انتخاب مناسبی نباشه.
👨💻 از نظر من coding agentها شبیه برنامهنویس جونیوری هستن که کتاب و ویدئو زیاد دیدن و شدیداً علاقه دارن با کارشون شما رو تحت تأثیر قرار بدن. برای همین گاهی از خطوطی که براشون کشیدید خارج میشن تا بگن: «ببین من چقدر بلدم!»
⚠️ برای همین اینکه بهشون بگیم «این فایل رو تغییر نده»، «به production دست نزن» یا «secretها رو نخون»، تا وقتی از نظر فنی جلویش را نگرفتیم، بیشتر شبیه توصیه است تا محدودیت واقعی.
🖥 وقتی به یک AI Agent دسترسی shell میدیم، عملاً بهش اجازه میدیم فایل بخونه و تغییر بده، command اجرا کنه، package نصب کنه، network request بزنه و حتی به secretها نزدیک بشه. برای همین کنترل کردن چنین چیزی فقط با prompt یا denylist کافی نیست.
📦 برای کنترل این ریسک، میتونیم از sandbox استفاده کنیم. راههای زیادی برای این کار وجود داره و یکی از نمونههاش nono هست.
https://github.com/nolabs-ai/nono
🔒 ابزار nono یک sandbox برای اجرای Agentهاست که به جای اعتماد به خود مدل یا هارنس، دسترسیها را در سطح سیستمعامل محدود میکند. یعنی میتونید مشخص کنید Agent به کدام مسیرها دسترسی داشته باشه، کجا نتونه بنویسه، چه network accessی داشته باشه و چه چیزهایی براش از اساس غیرممکن باشه.
🔐 این دقیقاً همان تفاوت بین نصیحت کردن یک دولوپر و بستن دسترسی push به main است.
🧪 البته sandbox هم مثل هارنسها یک جواب واحد نداره؛ باید تست کنیم و ببینیم کدوم روش برای کدوم کار مناسبتره.
🚧 ممکنه چیزی که روی سیستم خودمون خوب جواب میده، برای pipeline گیت یا محیط CI/CD انتخاب مناسبی نباشه.
👍5🥰1
🔓 این روزها خیلی از LLMها رو با عنوان «Open Source» معرفی میکنن، اما شاید بهتر باشه کمی دقیقتر بهش نگاه کنیم.
هر مدلی که بشه دانلودش کرد، لزوماً متنباز نیست. بین اینها فرق وجود داره:
🧠 مدل Open-weight: یعنی وزنهای مدل منتشر شده و میتونید مدل رو دانلود و اجرا کنید.
🧩 مدل Open-source: یعنی علاوه بر خروجی نهایی، وزنها، اطلاعات کافی درباره کد، داده، روش آموزش، تنظیمات و لایسنس هم در دسترسه.
📦 به زبان سادهتر، اگر فقط فایل مدل رو به شما بدن، میتونید ازش استفاده کنید.
🔍 اما اگر مسیر ساخت مدل هم شفاف باشه، میتونید بفهمید چطور ساخته شده، چه محدودیتهایی داره، چطور میشه تغییرش داد و چقدر میشه بهش اعتماد کرد.
⚠️ این تفاوت کوچیکی نیست
توی نرمافزار، وقتی سورسکد بازه، فقط «برنامه قابل اجرا» نداریم؛ منطق پشت برنامه رو هم میبینیم.
🤖 توی LLM هم اگر فقط وزنها رو داشته باشیم، بیشتر شبیه اینه که باینری یک برنامه رو گرفته باشیم، نه الزاماً سورس کاملش رو.
الان معمولاً به همه اینها میگیم Open Source، اما فکر میکنم در آینده فرقشون رو خیلی بیشتر متوجه میشم.
چون این کلمات فقط بحث لغوی نیستن؛ روی اعتماد، امنیت، قابلیت بازبینی و حتی آینده رقابت توی این حوزه هم اثر میذارن.
هر مدلی که بشه دانلودش کرد، لزوماً متنباز نیست. بین اینها فرق وجود داره:
🧠 مدل Open-weight: یعنی وزنهای مدل منتشر شده و میتونید مدل رو دانلود و اجرا کنید.
🧩 مدل Open-source: یعنی علاوه بر خروجی نهایی، وزنها، اطلاعات کافی درباره کد، داده، روش آموزش، تنظیمات و لایسنس هم در دسترسه.
📦 به زبان سادهتر، اگر فقط فایل مدل رو به شما بدن، میتونید ازش استفاده کنید.
🔍 اما اگر مسیر ساخت مدل هم شفاف باشه، میتونید بفهمید چطور ساخته شده، چه محدودیتهایی داره، چطور میشه تغییرش داد و چقدر میشه بهش اعتماد کرد.
⚠️ این تفاوت کوچیکی نیست
توی نرمافزار، وقتی سورسکد بازه، فقط «برنامه قابل اجرا» نداریم؛ منطق پشت برنامه رو هم میبینیم.
🤖 توی LLM هم اگر فقط وزنها رو داشته باشیم، بیشتر شبیه اینه که باینری یک برنامه رو گرفته باشیم، نه الزاماً سورس کاملش رو.
الان معمولاً به همه اینها میگیم Open Source، اما فکر میکنم در آینده فرقشون رو خیلی بیشتر متوجه میشم.
چون این کلمات فقط بحث لغوی نیستن؛ روی اعتماد، امنیت، قابلیت بازبینی و حتی آینده رقابت توی این حوزه هم اثر میذارن.
👍4👏1
🔗 چند لینک برای مطالعه بیشتر:
1. Open Source Initiative — The Open Source AI Definition
https://opensource.org/ai/open-source-ai-definition
2. Hugging Face — Model Cards
https://huggingface.co/docs/hub/en/model-cards
3. Hugging Face — Models Hub
https://huggingface.co/models
4. Meta — Llama 3.1 Community License
https://www.llama.com/llama3_1/license/
5. Mistral AI — Models
https://mistral.ai/models
1. Open Source Initiative — The Open Source AI Definition
https://opensource.org/ai/open-source-ai-definition
2. Hugging Face — Model Cards
https://huggingface.co/docs/hub/en/model-cards
3. Hugging Face — Models Hub
https://huggingface.co/models
4. Meta — Llama 3.1 Community License
https://www.llama.com/llama3_1/license/
5. Mistral AI — Models
https://mistral.ai/models
🖥 این روزها اگر کمی توی اینترنت یا یوتیوب بگردید، با کلی عنوان شبیه این روبهرو میشید:
«Run AI locally for FREE»
یا
«بدون پرداخت هزینه، ChatGPT خودت رو روی لپتاپ اجرا کن»
⚠️ این جمله از یک نظر درسته، اما از یک نظر خیلی گمراهکننده است.
بله، امروز میشه LLMها رو روی سیستم لوکال اجرا کرد.
🛠 ابزارهایی مثل Ollama، LM Studio و چندین گزینه دیگه این کار رو خیلی سادهتر از قبل کردن. ما خودمون هم تقریباً روزانه از مدلهای لوکال استفاده میکنیم.
اما نه برای همه کارها؛ برای coding جدی، تحلیل دیتای بزرگ، کار با context طولانی، یا تولید تصویر حرفهای، معمولاً خیلی زود محدودیتها خودشون رو نشون میدن.
🧠 مسئله اینه که «اجرا شدن» با «مفید، سریع، دقیق و قابل اتکا بودن» یکی نیست.
استفاده لوکال میتونه برای تست، یادگیری، کارهای ساده، خلاصهسازی متنهای کوتاه، آزمایش prompt یا کارهای حساس به حریم خصوصی خیلی خوب باشه.
🔍 اما وقتی بحث میره سمت کدنویسی جدی، تحلیل پیچیده، context بزرگ، سرعت مناسب یا چند ساعت کار مداوم، معمولاً فاصلهاش با مدلهای قوی آنلاین خیلی زود خودش رو نشون میده.
از طرف دیگه، لوکال هم واقعاً «رایگان» نیست.
💸 شما هزینه سختافزار، RAM یا VRAM، مصرف برق، زمان تنظیمات، نگهداری مدلها، انتخاب quantization مناسب و محدودیت سرعت رو پرداخت میکنید؛ فقط این هزینهها مستقیم به شکل subscription یا API bill دیده نمیشن.
برای استفاده شخصی، یک لپتاپ قوی، Mac Studio یا حتی یک سیستم خوب با GPU مناسب میتونه تجربه خیلی خوبی بده.
🏢 اما برای استفاده شرکتی یا تیمی، ماجرا کاملاً فرق میکنه.
اونجا دیگه فقط نصب Ollama روی یک لپتاپ نیست. باید به concurrency، latency، مانیتورینگ، امنیت، دسترسیها، آپدیت مدلها، backup، سرویسدهی پایدار و هزینه واقعی زیرساخت فکر کرد.
🧱 حتی اگر سراغ سختافزارهای خیلی قدرتمند مثل DGX هم برید، باز هم خود دستگاه فقط بخشی از ماجراست، نه کل راهحل.
در مقیاس شرکتی، هزینهها میتونن خیلی سریع از چند هزار دلار به چندصد هزار دلار برسن؛ تازه این فقط هزینه خرید سختافزاره. نگهداری، برق، خنکسازی، شبکه، نیروی فنی و سرویسدهی پایدار داستان جداگانهای دارن.
برای همین به نظرم شعار «AI رایگان روی سیستم خودت» بیشتر برای شروع، تجربه و یادگیری خوبه، نه الزاماً برای جایگزین کردن ابزارهای حرفهای روزانه.
✅ استفاده از مدلها در لوکال روش خیلی خوبیه؛ فقط نباید با کلمه «رایگان» گول بخوریم.
«Run AI locally for FREE»
یا
«بدون پرداخت هزینه، ChatGPT خودت رو روی لپتاپ اجرا کن»
⚠️ این جمله از یک نظر درسته، اما از یک نظر خیلی گمراهکننده است.
بله، امروز میشه LLMها رو روی سیستم لوکال اجرا کرد.
🛠 ابزارهایی مثل Ollama، LM Studio و چندین گزینه دیگه این کار رو خیلی سادهتر از قبل کردن. ما خودمون هم تقریباً روزانه از مدلهای لوکال استفاده میکنیم.
اما نه برای همه کارها؛ برای coding جدی، تحلیل دیتای بزرگ، کار با context طولانی، یا تولید تصویر حرفهای، معمولاً خیلی زود محدودیتها خودشون رو نشون میدن.
🧠 مسئله اینه که «اجرا شدن» با «مفید، سریع، دقیق و قابل اتکا بودن» یکی نیست.
استفاده لوکال میتونه برای تست، یادگیری، کارهای ساده، خلاصهسازی متنهای کوتاه، آزمایش prompt یا کارهای حساس به حریم خصوصی خیلی خوب باشه.
🔍 اما وقتی بحث میره سمت کدنویسی جدی، تحلیل پیچیده، context بزرگ، سرعت مناسب یا چند ساعت کار مداوم، معمولاً فاصلهاش با مدلهای قوی آنلاین خیلی زود خودش رو نشون میده.
از طرف دیگه، لوکال هم واقعاً «رایگان» نیست.
💸 شما هزینه سختافزار، RAM یا VRAM، مصرف برق، زمان تنظیمات، نگهداری مدلها، انتخاب quantization مناسب و محدودیت سرعت رو پرداخت میکنید؛ فقط این هزینهها مستقیم به شکل subscription یا API bill دیده نمیشن.
برای استفاده شخصی، یک لپتاپ قوی، Mac Studio یا حتی یک سیستم خوب با GPU مناسب میتونه تجربه خیلی خوبی بده.
🏢 اما برای استفاده شرکتی یا تیمی، ماجرا کاملاً فرق میکنه.
اونجا دیگه فقط نصب Ollama روی یک لپتاپ نیست. باید به concurrency، latency، مانیتورینگ، امنیت، دسترسیها، آپدیت مدلها، backup، سرویسدهی پایدار و هزینه واقعی زیرساخت فکر کرد.
🧱 حتی اگر سراغ سختافزارهای خیلی قدرتمند مثل DGX هم برید، باز هم خود دستگاه فقط بخشی از ماجراست، نه کل راهحل.
در مقیاس شرکتی، هزینهها میتونن خیلی سریع از چند هزار دلار به چندصد هزار دلار برسن؛ تازه این فقط هزینه خرید سختافزاره. نگهداری، برق، خنکسازی، شبکه، نیروی فنی و سرویسدهی پایدار داستان جداگانهای دارن.
برای همین به نظرم شعار «AI رایگان روی سیستم خودت» بیشتر برای شروع، تجربه و یادگیری خوبه، نه الزاماً برای جایگزین کردن ابزارهای حرفهای روزانه.
✅ استفاده از مدلها در لوکال روش خیلی خوبیه؛ فقط نباید با کلمه «رایگان» گول بخوریم.
👍3👏3
⛈ طی یکی دو ماه اخیر، خیلیها با یک واقعیت نسبتاً تلخ روبهرو شدن:
استفاده از LLMها دیگر مثل قبل یک هزینه ساده و قابل پیشبینی ماهانه نیست.
تا همین چند وقت پیش، خیلی از ابزارهای AI مثل «اشتراک ماهانه» بودن. یعنی یک مبلغ ثابت میدادید و تا حد زیادی با خیال راحت استفاده میکردید.
اما کمکم providerها دارن مدل محاسبه هزینه رو عوض میکنن.
به جای اینکه فقط بگن ماهی ۲۰ دلار یا ۱۰۰ دلار، بیشتر دارن میرن سمت credit، usage limit، token-based billing و محاسبه بر اساس مصرف واقعی.
یعنی چی؟
یعنی مدل قویتر، context بزرگتر، خروجی طولانیتر، فایلهای بیشتر، agentهای فعالتر و retryهای بیشتر، همگی میتونن مستقیم تبدیل به هزینه بیشتر بشن.
قبلاً شاید یک prompt طولانی فقط کمی شلوغ و بدسلیقه به نظر میرسید، اما الان همون prompt طولانی میتونه مستقیماً limit شما رو بسوزونه یا billing شما رو بالا ببره.
اینجاست که بحث بهینهکردن prompt از یک موضوع فانتزی تبدیل میشه به یک موضوع اقتصادی.
یه Prompt خوب یعنی:
🎯 هدف واضحتر
📦 مقدار context کوتاهتر
✂️ خروجی کوتاهتر
🔁 تعداد loop کمتر
💸 هزینه قابل کنترلتر
برای همین ابزارهایی مثل Caveman و Ponytail بیشتر مورد توجه قرار گرفتن. ما داریم وارد دورهای میشیم که در اون باید با مدلها اقتصادیتر حرف بزنیم.
همونطور که در مهندسی نرمافزار یاد گرفتیم CPU، RAM، storage و network بینهایت نیستن و ممکنه هزینه زیادی روی دستمون بذارن، حالا داریم یاد میگیریم که token و context هم بینهایت نیستن.
- هر چیزی رو نباید وارد context کرد.
- هر چیزی رو نباید از مدل قوی خواست.
- هر کاری رو نباید به agent سپرد.
- و هر پاسخی هم که از LLM میگیریم، لازم نیست یک مقاله کامل باشه.
⚠️ البته نباید از اون طرف بام هم بیفتیم.
برای کارهای حساس، مثل امنیت، migration، incident، معماری یا تغییرات production، گاهی توضیح کامل و context بیشتر واقعاً لازمه.
صرفهجویی خوبه، اما باید حواسمون باشه کاری نکنیم که چند برابرش رو بعداً پرداخت کنیم.
به نظرم از این به بعد یکی از مهارتهای مهم کار با AI اینه:
نه فقط بلد باشیم چه چیزی از مدل بخواهیم، بلکه بلد باشیم چقدر از مدل بخواهیم.
استفاده از LLMها دیگر مثل قبل یک هزینه ساده و قابل پیشبینی ماهانه نیست.
تا همین چند وقت پیش، خیلی از ابزارهای AI مثل «اشتراک ماهانه» بودن. یعنی یک مبلغ ثابت میدادید و تا حد زیادی با خیال راحت استفاده میکردید.
اما کمکم providerها دارن مدل محاسبه هزینه رو عوض میکنن.
به جای اینکه فقط بگن ماهی ۲۰ دلار یا ۱۰۰ دلار، بیشتر دارن میرن سمت credit، usage limit، token-based billing و محاسبه بر اساس مصرف واقعی.
یعنی چی؟
یعنی مدل قویتر، context بزرگتر، خروجی طولانیتر، فایلهای بیشتر، agentهای فعالتر و retryهای بیشتر، همگی میتونن مستقیم تبدیل به هزینه بیشتر بشن.
قبلاً شاید یک prompt طولانی فقط کمی شلوغ و بدسلیقه به نظر میرسید، اما الان همون prompt طولانی میتونه مستقیماً limit شما رو بسوزونه یا billing شما رو بالا ببره.
اینجاست که بحث بهینهکردن prompt از یک موضوع فانتزی تبدیل میشه به یک موضوع اقتصادی.
یه Prompt خوب یعنی:
🎯 هدف واضحتر
📦 مقدار context کوتاهتر
✂️ خروجی کوتاهتر
🔁 تعداد loop کمتر
💸 هزینه قابل کنترلتر
برای همین ابزارهایی مثل Caveman و Ponytail بیشتر مورد توجه قرار گرفتن. ما داریم وارد دورهای میشیم که در اون باید با مدلها اقتصادیتر حرف بزنیم.
همونطور که در مهندسی نرمافزار یاد گرفتیم CPU، RAM، storage و network بینهایت نیستن و ممکنه هزینه زیادی روی دستمون بذارن، حالا داریم یاد میگیریم که token و context هم بینهایت نیستن.
- هر چیزی رو نباید وارد context کرد.
- هر چیزی رو نباید از مدل قوی خواست.
- هر کاری رو نباید به agent سپرد.
- و هر پاسخی هم که از LLM میگیریم، لازم نیست یک مقاله کامل باشه.
⚠️ البته نباید از اون طرف بام هم بیفتیم.
برای کارهای حساس، مثل امنیت، migration، incident، معماری یا تغییرات production، گاهی توضیح کامل و context بیشتر واقعاً لازمه.
صرفهجویی خوبه، اما باید حواسمون باشه کاری نکنیم که چند برابرش رو بعداً پرداخت کنیم.
به نظرم از این به بعد یکی از مهارتهای مهم کار با AI اینه:
نه فقط بلد باشیم چه چیزی از مدل بخواهیم، بلکه بلد باشیم چقدر از مدل بخواهیم.
👍4👏2
🔗 چند لینک برای مطالعه بیشتر:
1. GitHub — Copilot usage-based billing
https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/
2. GitHub Docs — Usage-based billing for Copilot
https://docs.github.com/copilot/concepts/billing/usage-based-billing-for-individuals
3. OpenAI — Codex Pricing
https://developers.openai.com/codex/pricing
4. Claude — Manage usage credits
https://support.claude.com/en/articles/12429409-manage-usage-credits-for-paid-claude-plans
5. Caveman
https://github.com/JuliusBrussee/caveman
6. Ponytail
https://github.com/DietrichGebert/ponytail
1. GitHub — Copilot usage-based billing
https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/
2. GitHub Docs — Usage-based billing for Copilot
https://docs.github.com/copilot/concepts/billing/usage-based-billing-for-individuals
3. OpenAI — Codex Pricing
https://developers.openai.com/codex/pricing
4. Claude — Manage usage credits
https://support.claude.com/en/articles/12429409-manage-usage-credits-for-paid-claude-plans
5. Caveman
https://github.com/JuliusBrussee/caveman
6. Ponytail
https://github.com/DietrichGebert/ponytail
📊 وقتی یک مدل جدید معرفی میشه، معمولاً کنار اسمش یکسری عدد هم میبینیم؛ مثل MMLU، HumanEval، SWE-bench، GPQA، Math و کلی benchmark دیگه.
این عددها مهمن، ولی به نظرم گاهی بیشتر از چیزی که باید جدی گرفته میشن.
در نهایت benchmark یعنی مدلها رو روی یک مجموعه سؤال، مسئله یا task مشخص تست میکنن و بعد با یک روش ثابت بهشون score میدن.
مثلاً یکی دانش عمومی و reasoning رو میسنجه، یکی coding رو، یکی ریاضی رو، یکی هم توانایی حل bug یا issue رو.
تا اینجای کار مشکلی نیست، مشکل از جایی شروع میشه که نتیجه benchmark رو با عملکرد واقعی مدل توی کار روزانه یکی بگیریم.
یک مدل ممکنه روی benchmark کدنویسی نمره خیلی خوبی بگیره، ولی وقتی وارد پروژه واقعی میشه، خیلی زود گیر کنه.
چون پروژه واقعی شبیه سؤال تمیز benchmark نیست ، توی کار واقعی معمولاً با اینها طرفیم:
📦 کد قدیمی
📄 مستندات ناقص
🧩 یا dependencyهای عجیب
🐛 باگهایی که نصفشون از environment میاد
🧠 کانتکست ناقص یا اشتباه
⏱️ محدودیت زمان و هزینه
👨💻 تصمیمهایی که فقط با شناخت پروژه معنی پیدا میکنن
من benchmarkها رو بیارزش نمیدونم؛ اتفاقاً خیلی هم مهمن، اما به نظرم benchmark بیشتر شبیه تست آزمایشگاهیه.
به درد مقایسه میخوره، جهت کلی میده، و کمک میکنه بفهمیم یک مدل در یک سناریوی مشخص چقدر خوب عمل کرده.
ولی لزوماً نمیگه اون مدل برای پروژه من، با ابزارهای من، محدودیتهای من و سبک کاری من بهترین انتخابه.
برای همین وقتی یک مدل روی یک benchmark از همه جلوتره، بهتره سریع نتیجه نگیریم که «پس این بهترین مدله».
بهتره ببینیم اون benchmark دقیقاً چی رو اندازه گرفته، چقدر به کار ما نزدیکه، و آیا اصلاً مسئلهای که ما داریم، شبیه همون تست هست یا نه.
بدون شک Benchmark مهمه؛ فقط نباید جای تجربه واقعی رو بگیره.
این عددها مهمن، ولی به نظرم گاهی بیشتر از چیزی که باید جدی گرفته میشن.
در نهایت benchmark یعنی مدلها رو روی یک مجموعه سؤال، مسئله یا task مشخص تست میکنن و بعد با یک روش ثابت بهشون score میدن.
مثلاً یکی دانش عمومی و reasoning رو میسنجه، یکی coding رو، یکی ریاضی رو، یکی هم توانایی حل bug یا issue رو.
تا اینجای کار مشکلی نیست، مشکل از جایی شروع میشه که نتیجه benchmark رو با عملکرد واقعی مدل توی کار روزانه یکی بگیریم.
یک مدل ممکنه روی benchmark کدنویسی نمره خیلی خوبی بگیره، ولی وقتی وارد پروژه واقعی میشه، خیلی زود گیر کنه.
چون پروژه واقعی شبیه سؤال تمیز benchmark نیست ، توی کار واقعی معمولاً با اینها طرفیم:
📦 کد قدیمی
📄 مستندات ناقص
🧩 یا dependencyهای عجیب
🐛 باگهایی که نصفشون از environment میاد
🧠 کانتکست ناقص یا اشتباه
⏱️ محدودیت زمان و هزینه
👨💻 تصمیمهایی که فقط با شناخت پروژه معنی پیدا میکنن
من benchmarkها رو بیارزش نمیدونم؛ اتفاقاً خیلی هم مهمن، اما به نظرم benchmark بیشتر شبیه تست آزمایشگاهیه.
به درد مقایسه میخوره، جهت کلی میده، و کمک میکنه بفهمیم یک مدل در یک سناریوی مشخص چقدر خوب عمل کرده.
ولی لزوماً نمیگه اون مدل برای پروژه من، با ابزارهای من، محدودیتهای من و سبک کاری من بهترین انتخابه.
برای همین وقتی یک مدل روی یک benchmark از همه جلوتره، بهتره سریع نتیجه نگیریم که «پس این بهترین مدله».
بهتره ببینیم اون benchmark دقیقاً چی رو اندازه گرفته، چقدر به کار ما نزدیکه، و آیا اصلاً مسئلهای که ما داریم، شبیه همون تست هست یا نه.
بدون شک Benchmark مهمه؛ فقط نباید جای تجربه واقعی رو بگیره.
👍1👏1
🧠 اوایل استفاده از مدلها خیلی راحت بود.
تصمیم میگرفتید سؤال رو از کی بپرسید: ChatGPT، Claude، Gemini یا حتی همهشون.
بعد agentها و harnessها اومدن و باید تصمیم میگرفتیم کدوم harness از کدوم مدل استفاده کنه.
⚙️ کمکم چیزهایی مثل effort و thinking هم اضافه شدن و این بار باید تصمیم میگرفتیم بین low، medium و high کدوم برای این task مناسبه؛ بهخصوص الان که انتخاب اینها مستقیم روی هزینه هم تأثیر میذاره.
داریم وارد مرحلهای میشیم که دیگه سؤال اصلی فقط این نیست که:
«کدوم مدل قویتره؟»
سؤال مهمتر اینه:
«برای این کار، کدوم ترکیب بهتر جواب میده؟»
🔍 برای همین باید دقیقتر بدونیم هر کدوم از این لایهها چطور کار میکنن و به چه دردی میخورن.
مثلاً باید بدونیم برای رسیدن به نتیجه بهتر، effort رو بذاریم روی high یا نه اگر از یک skill خاص استفاده کنیم جواب بهتری میگیریم
یا اینکه برای کاری که میخوایم انجام بدیم، کدوم harness، کدوم مدل، کدوم plugin و کدوم سطح دسترسی مناسبتره.
🧩 وقتی اینها درست کنار هم قرار بگیرن، گاهی میشه از یک مدل نهچندان پرچمدار هم خروجی خیلی خوبی گرفت.
اما اگر اشتباه انتخاب بشن، فقط latency، هزینه و توهم دقت بیشتری تولید میکنن.
💸 برای همین فکر میکنم موج «vibe coding» به شکل خامش کمکم کمرنگتر میشه.
اینکه فقط به AI بگیم «یه چیزی بساز» و منتظر معجزه بمونیم، برای دمو و تجربه اولیه جذابه، اما برای کار جدی کافی نیست.
🛠 کار با AI داره تبدیل میشه به یک تخصص روی تخصص قبلی.
اگر developer هستید، فقط بلد بودن برنامهنویسی کافی نیست؛ باید بفهمید کِی از کدوم مدل استفاده کنید، کجا effort رو بالا ببرید، کجا context رو کم کنید، کجا tool رو محدود کنید و کجا اصلاً اجازه ندید agent خودش تصمیم بگیره.
🚀 به نظرم آینده نزدیک این نیست که همه فقط vibe کد بزنن.
بیشتر شبیه اینه که آدمهایی که تخصص اصلیشون رو دارن و همزمان ابزارهای AI رو درست میشناسن، چند برابر مؤثرتر میشن.
یه جمله تکراری هست که زیاد شنیدیم، اما اینجا واقعاً معنی پیدا میکنه:
این خود AI نیست مستقیم کار ما رو ازمون میگیره؛
اما آدمهایی که بلدند درست از AI استفاده کنن، احتمالاً جای آدمهایی رو میگیرن که فقط تخصص قبلیشون رو نگه داشتن.
تصمیم میگرفتید سؤال رو از کی بپرسید: ChatGPT، Claude، Gemini یا حتی همهشون.
بعد agentها و harnessها اومدن و باید تصمیم میگرفتیم کدوم harness از کدوم مدل استفاده کنه.
⚙️ کمکم چیزهایی مثل effort و thinking هم اضافه شدن و این بار باید تصمیم میگرفتیم بین low، medium و high کدوم برای این task مناسبه؛ بهخصوص الان که انتخاب اینها مستقیم روی هزینه هم تأثیر میذاره.
داریم وارد مرحلهای میشیم که دیگه سؤال اصلی فقط این نیست که:
«کدوم مدل قویتره؟»
سؤال مهمتر اینه:
«برای این کار، کدوم ترکیب بهتر جواب میده؟»
🔍 برای همین باید دقیقتر بدونیم هر کدوم از این لایهها چطور کار میکنن و به چه دردی میخورن.
مثلاً باید بدونیم برای رسیدن به نتیجه بهتر، effort رو بذاریم روی high یا نه اگر از یک skill خاص استفاده کنیم جواب بهتری میگیریم
یا اینکه برای کاری که میخوایم انجام بدیم، کدوم harness، کدوم مدل، کدوم plugin و کدوم سطح دسترسی مناسبتره.
🧩 وقتی اینها درست کنار هم قرار بگیرن، گاهی میشه از یک مدل نهچندان پرچمدار هم خروجی خیلی خوبی گرفت.
اما اگر اشتباه انتخاب بشن، فقط latency، هزینه و توهم دقت بیشتری تولید میکنن.
💸 برای همین فکر میکنم موج «vibe coding» به شکل خامش کمکم کمرنگتر میشه.
اینکه فقط به AI بگیم «یه چیزی بساز» و منتظر معجزه بمونیم، برای دمو و تجربه اولیه جذابه، اما برای کار جدی کافی نیست.
🛠 کار با AI داره تبدیل میشه به یک تخصص روی تخصص قبلی.
اگر developer هستید، فقط بلد بودن برنامهنویسی کافی نیست؛ باید بفهمید کِی از کدوم مدل استفاده کنید، کجا effort رو بالا ببرید، کجا context رو کم کنید، کجا tool رو محدود کنید و کجا اصلاً اجازه ندید agent خودش تصمیم بگیره.
🚀 به نظرم آینده نزدیک این نیست که همه فقط vibe کد بزنن.
بیشتر شبیه اینه که آدمهایی که تخصص اصلیشون رو دارن و همزمان ابزارهای AI رو درست میشناسن، چند برابر مؤثرتر میشن.
یه جمله تکراری هست که زیاد شنیدیم، اما اینجا واقعاً معنی پیدا میکنه:
این خود AI نیست مستقیم کار ما رو ازمون میگیره؛
اما آدمهایی که بلدند درست از AI استفاده کنن، احتمالاً جای آدمهایی رو میگیرن که فقط تخصص قبلیشون رو نگه داشتن.
👍4❤1🥰1
🧠 یکی از لایههایی که باید جداگانه بهش نگاه کنیم، همین بحث effort و thinking است.
این گزینهها فقط یک دکمه ساده برای «جواب بهتر بده» نیستن.
وقتی effort رو بالا میبریم، در واقع داریم به مدل اجازه میدیم قبل از جواب نهایی، compute بیشتری مصرف کنه؛ یعنی مسیرهای بیشتری رو بررسی کنه، بعضی فرضها رو کنار بذاره و جواب نهایی رو کمی بیشتر refine کنه.
از بیرون، این رفتار تا حدی شبیه loop داخل harnessهاست.
با این تفاوت که harness یک loop بیرونی داره:
فایل میخونه،
دستور رو اجرا میکنه،
تست میگیره،
خطا رو میبینه،
و نتیجه رو دوباره وارد context مدل میکنه.
اما thinking بیشتر شبیه یک loop داخلی محدود است.
مدل قبل از اینکه جواب نهایی رو بده، چند بار مسئله رو داخل همون فضای خودش میچرخونه و بررسی میکنه.
البته این دو یکی نیستن.
در هارنس loop بیرونی با واقعیت بیرون برخورد میکنه: فایل واقعی، خروجی واقعی، خطای واقعی.
اما loop داخلی thinking بیشتر روی چیزی کار میکنه که همین الان داخل context مدل وجود داره.
برای همین effort بالا همیشه بهتر نیست. اگر context درست باشه، effort بیشتر میتونه کمک کنه مدل مسیر بهتری پیدا کنه.
اما اگر context اشتباه یا ناقص باشه، effort بالا ممکنه فقط باعث بشه مدل با انرژی بیشتری روی مسیر اشتباه حرکت کنه.
حتی گاهی جواب غلط، تمیزتر و قانعکنندهتر ساخته میشه؛ یعنی توهم دقت بیشتر.
برای همین به نظرم effort را نباید جدا از harness و context فهمید.
در taskهای چندمرحلهای مثل debugging، refactor، incident analysis یا طراحی فنی، ترکیب loop بیرونی harness با thinking داخلی مدل میتونه واقعاً خروجی رو بهتر کنه.
اما اگر این ترکیب بد انتخاب بشه، فقط سه چیز بیشتر تولید میکنه:
تاخیر بیشتر، هزینه بیشتر، و اعتمادبهنفس بیشتر روی جواب اشتباه.
پس effort برای من بیشتر شبیه یک ابزار تنظیمه، نه یک درجه کیفیت.
سؤال این نیست که همیشه high بهتره یا نه.
سؤال اینه که برای این task، با این context و این harness، چقدر thinking واقعاً لازم داریم؟
این گزینهها فقط یک دکمه ساده برای «جواب بهتر بده» نیستن.
وقتی effort رو بالا میبریم، در واقع داریم به مدل اجازه میدیم قبل از جواب نهایی، compute بیشتری مصرف کنه؛ یعنی مسیرهای بیشتری رو بررسی کنه، بعضی فرضها رو کنار بذاره و جواب نهایی رو کمی بیشتر refine کنه.
از بیرون، این رفتار تا حدی شبیه loop داخل harnessهاست.
با این تفاوت که harness یک loop بیرونی داره:
فایل میخونه،
دستور رو اجرا میکنه،
تست میگیره،
خطا رو میبینه،
و نتیجه رو دوباره وارد context مدل میکنه.
اما thinking بیشتر شبیه یک loop داخلی محدود است.
مدل قبل از اینکه جواب نهایی رو بده، چند بار مسئله رو داخل همون فضای خودش میچرخونه و بررسی میکنه.
البته این دو یکی نیستن.
در هارنس loop بیرونی با واقعیت بیرون برخورد میکنه: فایل واقعی، خروجی واقعی، خطای واقعی.
اما loop داخلی thinking بیشتر روی چیزی کار میکنه که همین الان داخل context مدل وجود داره.
برای همین effort بالا همیشه بهتر نیست. اگر context درست باشه، effort بیشتر میتونه کمک کنه مدل مسیر بهتری پیدا کنه.
اما اگر context اشتباه یا ناقص باشه، effort بالا ممکنه فقط باعث بشه مدل با انرژی بیشتری روی مسیر اشتباه حرکت کنه.
حتی گاهی جواب غلط، تمیزتر و قانعکنندهتر ساخته میشه؛ یعنی توهم دقت بیشتر.
برای همین به نظرم effort را نباید جدا از harness و context فهمید.
در taskهای چندمرحلهای مثل debugging، refactor، incident analysis یا طراحی فنی، ترکیب loop بیرونی harness با thinking داخلی مدل میتونه واقعاً خروجی رو بهتر کنه.
اما اگر این ترکیب بد انتخاب بشه، فقط سه چیز بیشتر تولید میکنه:
تاخیر بیشتر، هزینه بیشتر، و اعتمادبهنفس بیشتر روی جواب اشتباه.
پس effort برای من بیشتر شبیه یک ابزار تنظیمه، نه یک درجه کیفیت.
سؤال این نیست که همیشه high بهتره یا نه.
سؤال اینه که برای این task، با این context و این harness، چقدر thinking واقعاً لازم داریم؟
👍4❤1🥰1
یکی از چیزهایی که همیشه باهاش مشکل داریم، کدهای قدیمیه.
میراثی از گذشتگان، یا گاهی میراثی از نسخه احمقتر خودمون در گذشته 😁
حالا کاری که این روزها میکنیم چیه؟
میایم همین کدهای حساس و قدیمی رو میدیم به سیستمی که کارش حدس زدن محتملترین جواب بعدیه؛ یعنی LLM یا همون چیزی که بهش میگیم هوش مصنوعی.
البته refactoring با AI روی کاغذ خیلی جذابه.
به مدل میگیم:
این ماژول رو تمیز کن، duplicationها رو بررسی و حذف کن، اسمها رو بهتر کن، کد رو سادهتر کن.
و مدل هم شروع میکنه به تغییر دادن کد.
اما مسئله اینجاست که بعد از تموم شدن کار AI، شما ممکنه یک کد تمیزتر، سادهتر و قابلفهمتر داشته باشید، اما از بیرون برنامه باید دقیقاً همان رفتار قبلی رو داشته باشه.
مشکل اینه که درصد بالایی از این کدهای قدیمی تست درستوحسابی ندارن.
اینجاست که فاجعه رخ میده.
البته اگر خوششانس باشید، همون لحظه چیزی خراب میشه و متوجه میشید. اگر بدشانس باشید، چند هفته بعد یک edge case عجیب فعال میشه و میفهمید اون کد داغون بیدلیل اونجا نبوده.
برای همین به نظرم قبل از اینکه از AI بخوایم کد قدیمی رو refactor کنه، بهتره اول ازش بخوایم رفتار فعلی سیستم رو قفل کنه.
یعنی به جای اینکه مستقیم بگیم «کد رو تمیز کن»، اول بریم سراغ اینکه بهش بگیم:
کد رو بخون، رفتار فعلی رو بفهم، و براش تست بنویس؛ اما خود کد رو تغییر نده.
حتی اگر کد زشته، حتی اگر ساختارش بده، حتی اگر اسم متغیرها فاجعه است، اول باید بفهمیم همین کد زشت الان دقیقاً چه کاری انجام میده.
بعد اینجا ما وارد میشیم؛ انسانهای شریف 😁
به جای اینکه مستقیم با کد قدیمی کشتی بگیریم، تستهایی که AI نوشته رو review میکنیم. ببینیم واقعاً رفتار فعلی سیستم رو پوشش میدن یا نه.
وقتی تستها قابل قبول شدن، تازه میشه رفت سراغ مرحله بعد:
حالا refactor کن، ولی به تستها دست نزن.
هر تغییری که میدی، تستها رو اجرا کن. اگر تست شکست، یعنی یا refactor اشتباه بوده، یا چیزی هست که باید دقیقتر بررسی بشه.
فراموش نکنیم که ما تا سالها مجبوریم با کدهای legacy زندگی کنیم، نگهداریشون کنیم و کمکم بهترشون کنیم.
بدون AI، انجام این کار در خیلی از پروژهها شاید اصلاً مقرونبهصرفه نباشه.
اما با AI هم اگر مستقیم بریم سراغ «تمیز کردن کد»، ممکنه فقط technical debt قدیمی رو تبدیل کنیم به technical debt جدید، با ظاهری شیکتر.
برای همین به نظرم در کدهای قدیمی، اولین درخواست از AI نباید این باشه:
«این کد رو تمیز کن.»
درخواست بهتر اینه:
«قبل از اینکه دست به این کد بزنیم، کمک کن بفهمیم الان دقیقاً چه رفتاری داره.»
چون در legacy code، تمیزتر شدن کد کافی نیست.
اول باید مطمئن بشیم چیزی که سالها با هزار بدبختی کار کرده، بعد از refactor هنوز هم همون کار رو انجام میده.
میراثی از گذشتگان، یا گاهی میراثی از نسخه احمقتر خودمون در گذشته 😁
حالا کاری که این روزها میکنیم چیه؟
میایم همین کدهای حساس و قدیمی رو میدیم به سیستمی که کارش حدس زدن محتملترین جواب بعدیه؛ یعنی LLM یا همون چیزی که بهش میگیم هوش مصنوعی.
البته refactoring با AI روی کاغذ خیلی جذابه.
به مدل میگیم:
این ماژول رو تمیز کن، duplicationها رو بررسی و حذف کن، اسمها رو بهتر کن، کد رو سادهتر کن.
و مدل هم شروع میکنه به تغییر دادن کد.
اما مسئله اینجاست که بعد از تموم شدن کار AI، شما ممکنه یک کد تمیزتر، سادهتر و قابلفهمتر داشته باشید، اما از بیرون برنامه باید دقیقاً همان رفتار قبلی رو داشته باشه.
مشکل اینه که درصد بالایی از این کدهای قدیمی تست درستوحسابی ندارن.
اینجاست که فاجعه رخ میده.
البته اگر خوششانس باشید، همون لحظه چیزی خراب میشه و متوجه میشید. اگر بدشانس باشید، چند هفته بعد یک edge case عجیب فعال میشه و میفهمید اون کد داغون بیدلیل اونجا نبوده.
برای همین به نظرم قبل از اینکه از AI بخوایم کد قدیمی رو refactor کنه، بهتره اول ازش بخوایم رفتار فعلی سیستم رو قفل کنه.
یعنی به جای اینکه مستقیم بگیم «کد رو تمیز کن»، اول بریم سراغ اینکه بهش بگیم:
کد رو بخون، رفتار فعلی رو بفهم، و براش تست بنویس؛ اما خود کد رو تغییر نده.
حتی اگر کد زشته، حتی اگر ساختارش بده، حتی اگر اسم متغیرها فاجعه است، اول باید بفهمیم همین کد زشت الان دقیقاً چه کاری انجام میده.
بعد اینجا ما وارد میشیم؛ انسانهای شریف 😁
به جای اینکه مستقیم با کد قدیمی کشتی بگیریم، تستهایی که AI نوشته رو review میکنیم. ببینیم واقعاً رفتار فعلی سیستم رو پوشش میدن یا نه.
وقتی تستها قابل قبول شدن، تازه میشه رفت سراغ مرحله بعد:
حالا refactor کن، ولی به تستها دست نزن.
هر تغییری که میدی، تستها رو اجرا کن. اگر تست شکست، یعنی یا refactor اشتباه بوده، یا چیزی هست که باید دقیقتر بررسی بشه.
فراموش نکنیم که ما تا سالها مجبوریم با کدهای legacy زندگی کنیم، نگهداریشون کنیم و کمکم بهترشون کنیم.
بدون AI، انجام این کار در خیلی از پروژهها شاید اصلاً مقرونبهصرفه نباشه.
اما با AI هم اگر مستقیم بریم سراغ «تمیز کردن کد»، ممکنه فقط technical debt قدیمی رو تبدیل کنیم به technical debt جدید، با ظاهری شیکتر.
برای همین به نظرم در کدهای قدیمی، اولین درخواست از AI نباید این باشه:
«این کد رو تمیز کن.»
درخواست بهتر اینه:
«قبل از اینکه دست به این کد بزنیم، کمک کن بفهمیم الان دقیقاً چه رفتاری داره.»
چون در legacy code، تمیزتر شدن کد کافی نیست.
اول باید مطمئن بشیم چیزی که سالها با هزار بدبختی کار کرده، بعد از refactor هنوز هم همون کار رو انجام میده.
👍6❤2🥰1
جری ساینفلد، کمدین آمریکایی، یه جمله بامزه درباره AI داره:
ما اونقدر باهوش بودیم که AI رو اختراع کنیم،
اونقدر خنگ بودیم که بهش نیاز پیدا کنیم،
و اونقدر احمقیم که نمیتونیم بفهمیم اصلاً کار درستی کردیم یا نه.
😂😂😂
چند روز پیش آنتروپیک یه مقاله منتشر کرد که به نظرم دقیقاً وسط همین وضعیت قرار میگیره. 😈
ما مدلهایی ساختیم که میتونن کد بنویسن، مسئله حل کنن، استدلال کنن، ابزار صدا بزنن و گاهی رفتاری نشون بدن که از بیرون شبیه فکر کردن به نظر میاد.
اما هنوز درست نمیدونیم داخلشون چه خبر است.
آنتروپیک توی این مقاله درباره چیزی به نام J-space صحبت میکنه، یک جور فضای داخلی در مدل Claude که بعضی مفاهیم، قبل از اینکه وارد خروجی مدل بشن، اونجا دیده میشن.
پیشنهاد این رو بخورنید:
https://www.anthropic.com/research/global-workspace
مثلاً مدل ممکنه در خروجی چیزی نگه، اما داخل این فضا نشانههایی از مفاهیمی مثل bug، fake، injection یا حتی مراحل میانی حل یک مسئله دیده بشه.
انگار مدل ممکنه توی خروجی، و حتی در مراحل thinking، اشارهای بهش نکنه؛ ولی داخل این فضا این مفهوم فعال شده باشه و روش محاسباتی انجام شده باشه.
نوشتم محاسبات، ننوشتم روش فکر شده، چون هنوز نمیتونم قبول کنم واقعاً فکر میکنه 😁😁😁
این بخش برای من خیلی جالبه، چون ما معمولا فقط چیزی رو میبینیم که مدل مینویسه.
اما بخش مهمی از رفتار مدل ممکنه قبل از خروجی نهایی شکل گرفته باشه؛ در جایی که نه prompt مستقیمه، نه response نهایی، نه chain of thought قابلمشاهده.
یک جور فکر خاموش.
الان بخش بزرگی از اینترنت دارن درباره این حرف میزنن که آنتروپیک «خودآگاهی» رو توی هوش مصنوعی پیدا کرده.
اما به نظرم نباید سریع بپریم سمت بحثهایی مثل خودآگاهی و این حرفها.
نکته مهمتر و عملیتر اینه که شاید کمکم داریم ابزارهایی پیدا میکنیم برای دیدن اینکه مدل قبل از جواب دادن، چه چیزهایی رو داخل خودش فعال کرده.
این برای safety، debugging و فهمیدن رفتار مدلها خیلی مهمه.
چون اگر فقط خروجی نهایی رو ببینیم، ممکنه مدل خیلی تمیز و مودب جواب بده، اما مسیر داخلیاش چیز دیگری رو نشان بده.
مثلاً ممکنه بفهمه در حال تست شدنه.
ممکنه متوجه prompt injection بشه.
ممکنه یک هدف پنهان یا رفتار مشکوک در مسیر تصمیمگیریاش ظاهر بشه.
یا ممکنه قبل از جواب نهایی، یک فرض اشتباه رو محور reasoning خودش قرار داده باشه.
برای من جذابیت این مقاله در همینجاست:
ما از مرحله «مدل چه جوابی داد؟» داریم کمکم میرسیم به مرحله «مدل قبل از جواب دادن، چه چیزی رو درگیر کرده بود؟»
چون اگر قرار باشه این مدلها بدون نظارت مستقیم انسان وارد فرآیندهای تصمیمگیری، مسائل امنیتی، automation و کارهای حساس بشن، فقط بهتر شدن خروجی کافی نیست.
باید بفهمیم پشت خروجی چه اتفاقی افتاده.
یا حداقل، کمی بیشتر از قبل بفهمیم.
شاید قدم بعدی در AI فقط ساختن مدلهای قویتر نباشه، بلکه ساختن راههایی باشه برای اینکه بفهمیم این مدلهای قویتر، قبل از جواب دادن، واقعاً به چه چیزهایی فکر کرده.
ما اونقدر باهوش بودیم که AI رو اختراع کنیم،
اونقدر خنگ بودیم که بهش نیاز پیدا کنیم،
و اونقدر احمقیم که نمیتونیم بفهمیم اصلاً کار درستی کردیم یا نه.
😂😂😂
چند روز پیش آنتروپیک یه مقاله منتشر کرد که به نظرم دقیقاً وسط همین وضعیت قرار میگیره. 😈
ما مدلهایی ساختیم که میتونن کد بنویسن، مسئله حل کنن، استدلال کنن، ابزار صدا بزنن و گاهی رفتاری نشون بدن که از بیرون شبیه فکر کردن به نظر میاد.
اما هنوز درست نمیدونیم داخلشون چه خبر است.
آنتروپیک توی این مقاله درباره چیزی به نام J-space صحبت میکنه، یک جور فضای داخلی در مدل Claude که بعضی مفاهیم، قبل از اینکه وارد خروجی مدل بشن، اونجا دیده میشن.
پیشنهاد این رو بخورنید:
https://www.anthropic.com/research/global-workspace
مثلاً مدل ممکنه در خروجی چیزی نگه، اما داخل این فضا نشانههایی از مفاهیمی مثل bug، fake، injection یا حتی مراحل میانی حل یک مسئله دیده بشه.
انگار مدل ممکنه توی خروجی، و حتی در مراحل thinking، اشارهای بهش نکنه؛ ولی داخل این فضا این مفهوم فعال شده باشه و روش محاسباتی انجام شده باشه.
نوشتم محاسبات، ننوشتم روش فکر شده، چون هنوز نمیتونم قبول کنم واقعاً فکر میکنه 😁😁😁
این بخش برای من خیلی جالبه، چون ما معمولا فقط چیزی رو میبینیم که مدل مینویسه.
اما بخش مهمی از رفتار مدل ممکنه قبل از خروجی نهایی شکل گرفته باشه؛ در جایی که نه prompt مستقیمه، نه response نهایی، نه chain of thought قابلمشاهده.
یک جور فکر خاموش.
الان بخش بزرگی از اینترنت دارن درباره این حرف میزنن که آنتروپیک «خودآگاهی» رو توی هوش مصنوعی پیدا کرده.
اما به نظرم نباید سریع بپریم سمت بحثهایی مثل خودآگاهی و این حرفها.
نکته مهمتر و عملیتر اینه که شاید کمکم داریم ابزارهایی پیدا میکنیم برای دیدن اینکه مدل قبل از جواب دادن، چه چیزهایی رو داخل خودش فعال کرده.
این برای safety، debugging و فهمیدن رفتار مدلها خیلی مهمه.
چون اگر فقط خروجی نهایی رو ببینیم، ممکنه مدل خیلی تمیز و مودب جواب بده، اما مسیر داخلیاش چیز دیگری رو نشان بده.
مثلاً ممکنه بفهمه در حال تست شدنه.
ممکنه متوجه prompt injection بشه.
ممکنه یک هدف پنهان یا رفتار مشکوک در مسیر تصمیمگیریاش ظاهر بشه.
یا ممکنه قبل از جواب نهایی، یک فرض اشتباه رو محور reasoning خودش قرار داده باشه.
برای من جذابیت این مقاله در همینجاست:
ما از مرحله «مدل چه جوابی داد؟» داریم کمکم میرسیم به مرحله «مدل قبل از جواب دادن، چه چیزی رو درگیر کرده بود؟»
چون اگر قرار باشه این مدلها بدون نظارت مستقیم انسان وارد فرآیندهای تصمیمگیری، مسائل امنیتی، automation و کارهای حساس بشن، فقط بهتر شدن خروجی کافی نیست.
باید بفهمیم پشت خروجی چه اتفاقی افتاده.
یا حداقل، کمی بیشتر از قبل بفهمیم.
شاید قدم بعدی در AI فقط ساختن مدلهای قویتر نباشه، بلکه ساختن راههایی باشه برای اینکه بفهمیم این مدلهای قویتر، قبل از جواب دادن، واقعاً به چه چیزهایی فکر کرده.
👍5🥰2😁1
ابزارهایی مثل OpenClaw، Hermes یا Manus گاهی میان روی آنتن همه یوتیبرها و گاهی میرن. یکی میگه وای، خیلی خطر داره. یکی میگه همه زندگی من رو به باد داد. یکی هم ویدئو میذاره و میگه من دیگه همهچیز رو واگذار کردم به یکی از اینا و خودم نشستم تخمه میشکنم و فیلم نگاه میکنم.
اما اگر این جنگولکبازیهای یوتیوبرها رو بذاریم کنار و بخواهیم یکی رو انتخاب کنیم، باید قبل یه سؤال مهم از خودمون بپرسیم:
آیا ما واقعاً به یک autonomous agent نیاز داریم؟
اگر استفاده ما از AI بیشتر شامل سؤال پرسیدن، نوشتن متن، تولید کد یا انجام چند کار موردیه، برای این کارها همان هارنسهای فعلی کافی هستند. در واقع این autonomous agent زمانی معنی پیدا میکنه که برای کارهایی استفاده بشه که:
🔁 مرتب تکرار بشه،
🧩 چند مرحله مشخص داشته باشه،
🛠 بین چند ابزار یا سرویس محدود جابهجا بشه،
⏳ و لازم باشه بدون حضور دائم ما ادامه پیدا کنه.
مثلاً هر روز اطلاعاتی را از چند منبع جمع کند، تغییرات را بررسی کند، نتیجه را دستهبندی کند و در نهایت یک گزارش قابل استفاده تحویل بده.
اینجا ارزش Agent فقط در این نیست که «هوشمند» است.
ارزش اصلی اینه که بخشی از هماهنگی، پیگیری و رفت و برگشت بین مراحل مختلف رو از دوش ما برمیداره.
⚠️ اما اشتباه رایج اینه که اول یک ابزار نصب کنیم و بعد دنبال کاری بگردیم که بهش بسپاریم. انگار یکی رو استخدام کنیم و بدونیم که خیلی کارا بلده، ولی فعلاً نه میتونیم کارمون رو کامل و دقیق بهش توضیح بدیم و مهمتر اینکه هنوز بهش اعتماد نداریم که پسورد و دسترسی به همهچیز رو بهش بدیم.
به نظرم مسیر درست دقیقاً برعکسه.
اول باید ببینیم چه کاری رو مرتب انجام میدیم که تکراری، وقتگیر و نسبتاً قابل پیشبینیه.
بعد باید بتونیم چهار سؤال رو دربارهاش جواب بدیم:
هدف نهایی این کار دقیقاً چیه؟
برای انجامش چه مجموعه ابزار و دسترسیهایی لازمه؟
از کجا میفهمیم درست انجام شده؟
اگر اشتباه انجام شد، چقدر راحت میتونیم برگردیم و اصلاحش کنیم؟
اگر جواب این سؤالها روشن نیست، احتمالاً هنوز اون کار گزینه خوبی برای خودکار شدن نیست؛ چه با اسکریپت، چه با autonomous agent.
🧪 حتی بعد از انتخاب کار هم بهتره از روز اول سراغ اجرای اون با autonomous agent نریم.
اول همون workflow رو چند بار با هارنسهای فعلی و مدلهای مختلف و با نظارت خودمون اجرا کنیم؛ خروجیها رو ببینیم، جاهایی که گیر میکنه پیدا کنیم و بفهمیم آیا نتیجه واقعاً قابل پیشبینیه یا نه.
وقتی دیدیم Agent در یک محدوده مشخص بارها نتیجه قابل قبول میده، تازه میشه بخشی از کار رو به trigger، schedule یا اجرای مستقل سپرد.
اگر بعد از خودکار کردن یک workflow مجبور باشیم دائماً دنبالش راه بیفتیم، خطاهاش رو اصلاح کنیم و ببینیم این بار چه تصمیم عجیبی گرفته، چیزی را خودکار نکردیم؛ فقط شکل کار رو عوض کردیم.
برای همین بهتره از این سؤال شروع نکنیم:
«کدوم Autonomous Agent رو نصب کنم؟»
سؤال بهتر اینه:
«کدوم بخش از کار من بهاندازه کافی تکراری، شفاف و قابلاندازهگیریه که بشه واگذارش کرد؟»
اگر جوابی برای این سؤال نداریم، احتمالاً هنوز به یک Autonomous Agent نیاز نداریم.
اما اگر این جنگولکبازیهای یوتیوبرها رو بذاریم کنار و بخواهیم یکی رو انتخاب کنیم، باید قبل یه سؤال مهم از خودمون بپرسیم:
آیا ما واقعاً به یک autonomous agent نیاز داریم؟
اگر استفاده ما از AI بیشتر شامل سؤال پرسیدن، نوشتن متن، تولید کد یا انجام چند کار موردیه، برای این کارها همان هارنسهای فعلی کافی هستند. در واقع این autonomous agent زمانی معنی پیدا میکنه که برای کارهایی استفاده بشه که:
🔁 مرتب تکرار بشه،
🧩 چند مرحله مشخص داشته باشه،
🛠 بین چند ابزار یا سرویس محدود جابهجا بشه،
⏳ و لازم باشه بدون حضور دائم ما ادامه پیدا کنه.
مثلاً هر روز اطلاعاتی را از چند منبع جمع کند، تغییرات را بررسی کند، نتیجه را دستهبندی کند و در نهایت یک گزارش قابل استفاده تحویل بده.
اینجا ارزش Agent فقط در این نیست که «هوشمند» است.
ارزش اصلی اینه که بخشی از هماهنگی، پیگیری و رفت و برگشت بین مراحل مختلف رو از دوش ما برمیداره.
⚠️ اما اشتباه رایج اینه که اول یک ابزار نصب کنیم و بعد دنبال کاری بگردیم که بهش بسپاریم. انگار یکی رو استخدام کنیم و بدونیم که خیلی کارا بلده، ولی فعلاً نه میتونیم کارمون رو کامل و دقیق بهش توضیح بدیم و مهمتر اینکه هنوز بهش اعتماد نداریم که پسورد و دسترسی به همهچیز رو بهش بدیم.
به نظرم مسیر درست دقیقاً برعکسه.
اول باید ببینیم چه کاری رو مرتب انجام میدیم که تکراری، وقتگیر و نسبتاً قابل پیشبینیه.
بعد باید بتونیم چهار سؤال رو دربارهاش جواب بدیم:
هدف نهایی این کار دقیقاً چیه؟
برای انجامش چه مجموعه ابزار و دسترسیهایی لازمه؟
از کجا میفهمیم درست انجام شده؟
اگر اشتباه انجام شد، چقدر راحت میتونیم برگردیم و اصلاحش کنیم؟
اگر جواب این سؤالها روشن نیست، احتمالاً هنوز اون کار گزینه خوبی برای خودکار شدن نیست؛ چه با اسکریپت، چه با autonomous agent.
🧪 حتی بعد از انتخاب کار هم بهتره از روز اول سراغ اجرای اون با autonomous agent نریم.
اول همون workflow رو چند بار با هارنسهای فعلی و مدلهای مختلف و با نظارت خودمون اجرا کنیم؛ خروجیها رو ببینیم، جاهایی که گیر میکنه پیدا کنیم و بفهمیم آیا نتیجه واقعاً قابل پیشبینیه یا نه.
وقتی دیدیم Agent در یک محدوده مشخص بارها نتیجه قابل قبول میده، تازه میشه بخشی از کار رو به trigger، schedule یا اجرای مستقل سپرد.
اگر بعد از خودکار کردن یک workflow مجبور باشیم دائماً دنبالش راه بیفتیم، خطاهاش رو اصلاح کنیم و ببینیم این بار چه تصمیم عجیبی گرفته، چیزی را خودکار نکردیم؛ فقط شکل کار رو عوض کردیم.
برای همین بهتره از این سؤال شروع نکنیم:
«کدوم Autonomous Agent رو نصب کنم؟»
سؤال بهتر اینه:
«کدوم بخش از کار من بهاندازه کافی تکراری، شفاف و قابلاندازهگیریه که بشه واگذارش کرد؟»
اگر جوابی برای این سؤال نداریم، احتمالاً هنوز به یک Autonomous Agent نیاز نداریم.
👍8❤5💯2🥰1