📝 قبلاً درباره این نوشتم که نوشتن 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
اوایل جام جهانی بود که یه پست در Medium دیدم که نویسندهاش با استفاده از Claude برنده جام جهانی ۲۰۲۶ رو پیشبینی کرده بود. البته کلمه «پیشبینی» اینجا خیلی درست نیست و بهتره بگم احتمال برنده شدن تیمها رو محاسبه کرده بود.
البته نویسنده فقط از Claude نپرسیده «چه تیمی قهرمان میشه؟» و Claude هم از روی حس یا اطلاعات داخل مدل اسم اسپانیا رو بیرون نکشیده.
کلاد به نویسنده کمک کرده اطلاعات بیش از ۴۹ هزار مسابقه ملی رو جمعآوری و پردازش کنه، برای تیمها سیستم امتیازدهی Elo بسازه، احتمال گلها رو با یک مدل آماری محاسبه کنه و ادامه تورنمنت رو ۵۰ هزار بار شبیهسازی کنه.
نتیجه این شبیهسازیها این بوده که اسپانیا بیشتر از بقیه تیمها قهرمان شده؛ تقریباً یک بار از هر ۳.۴ تورنمنت.
اما بخش مهم ماجرا برای من اسپانیا یا حتی فوتبال نیست.
تا چند سال پیش انجام چنین پروژهای به ترکیبی از برنامهنویسی، آمار، جمعآوری و تمیز کردن داده و احتمالاً چند روز یا چند هفته زمان نیاز داشت.
حالا یک نفر تونسته بخش بزرگی از این کار رو با کمک LLM در مدت کوتاهی انجام بده.
وقتی داشتم به این مقاله فکر میکردم یاد فیلم Limitless افتادم. توی فیلم شخصیت اصلی داستان یعنی Eddie Morra با مصرف قرصی به نام NZT به توانایی ذهنی عجیبی میرسه.
میتونه حجم زیادی از اطلاعات رو به خاطر بیاره، ارتباط بین اتفاقها رو سریعتر پیدا کنه و چند حرکت جلوتر از بقیه تصمیم بگیره. اواخر فیلم تقریباً به نقطهای میرسه که انگار میتونه آینده رو پیشبینی کنه.
البته Eddie آینده رو به شکل جادویی نمیبینه. چیزی که فیلم نشون میده، ذهنیه که میتونه تعداد زیادی متغیر، الگو و پیامد احتمالی رو با سرعت خیلی بالا کنار هم بذاره.
در واقع اگر بتونیم درست از LLM استفاده کنیم، میتونه شبیه قرص NZT در فیلم Limitless عمل کنه.
نه به این معنی که ناگهان همهچیز رو بفهمیم و آینده رو ببینیم، بلکه به ما کمک میکنه حجم بیشتری از اطلاعات رو پردازش کنیم، بین اونها ارتباط پیدا کنیم، چند مدل بسازیم و هزاران آینده احتمالی رو قبل از تصمیم گرفتن آزمایش کنیم.
🔮 اما اینجا باید مراقب یک اشتباه مهم باشیم.
راحتتر شدن ساختن مدل پیشبینی، به معنی دقیقتر شدن پیشبینی نیست.
مدلی که در مقاله ساخته شده بود، در تست سه جام جهانی قبلی حدود ۵۵ درصد نتایج رو درست پیشبینی کرده بود.
اجرای ۵۰ هزار شبیهسازی هم مدل رو دقیقتر نمیکنه.
فقط نشون میده اگر دادهها، فرضها و فرمولهای ما درست باشن، هر کدوم از آیندههای ممکن با چه احتمالی اتفاق میافتن.
اگر فرض اولیه اشتباه باشه، میتونیم همون اشتباه رو ۵۰ هزار بار با سرعت و ظاهر علمی بیشتری تکرار کنیم 😁
ارزش LLM این نیست که مثل فالگیر جواب نهایی رو به ما بگه.
ارزشش اینه که ساختن و آزمایش کردن مدلهایی رو که قبلاً فقط از عهده تیمهای تخصصی برمیاومد، برای افراد بیشتری ممکن میکنه.
این توانایی فقط به مدلهای آماری هم محدود نیست.
الان دیگه برای اینکه به مشتری نشون بدیم محصول چه شکلی خواهد بود، لازم نیست فقط موکاپ Figma رو بهش نشون بدیم. میتونیم خیلی سریع چند MVP درست کنیم که تا حدودی هم کار میکنن.
از پیشبینی فروش و تقاضا گرفته تا بررسی ریسک پروژه، نگهداری تجهیزات یا تحلیل سناریوهای مختلف، حالا ساختن یک مدل اولیه خیلی ارزانتر و سریعتر شده.
البته انسان هنوز باید تصمیم بگیره چه دادهای معتبره، چه فرضی وارد مدل بشه، نتیجه با چه روشی ارزیابی بشه و آیا مدل واقعاً از یک روش ساده بهتره یا نه.
شاید LLMها هنوز ما رو به Eddie Morra تبدیل نکرده باشن.
اما دارن توانایی ساختن ابزارهایی رو در اختیارمون میذارن که میتونن قبل از تصمیمگیری، هزاران مسیر احتمالی رو بررسی کنن.
آینده لزوماً قابلپیشبینیتر نشده؛ توانایی ما برای ساختن، آزمایش کردن و مقایسه آیندههای احتمالی بیشتر شده.
شاید نزدیکترین چیز به قدرت Eddie Morra این نباشه که آینده رو ببینیم؛ بلکه این باشه که قبل از انتخاب یک مسیر، بتونیم هزاران مسیر ممکن رو بررسی کنیم.
البته نویسنده فقط از Claude نپرسیده «چه تیمی قهرمان میشه؟» و Claude هم از روی حس یا اطلاعات داخل مدل اسم اسپانیا رو بیرون نکشیده.
کلاد به نویسنده کمک کرده اطلاعات بیش از ۴۹ هزار مسابقه ملی رو جمعآوری و پردازش کنه، برای تیمها سیستم امتیازدهی Elo بسازه، احتمال گلها رو با یک مدل آماری محاسبه کنه و ادامه تورنمنت رو ۵۰ هزار بار شبیهسازی کنه.
نتیجه این شبیهسازیها این بوده که اسپانیا بیشتر از بقیه تیمها قهرمان شده؛ تقریباً یک بار از هر ۳.۴ تورنمنت.
اما بخش مهم ماجرا برای من اسپانیا یا حتی فوتبال نیست.
تا چند سال پیش انجام چنین پروژهای به ترکیبی از برنامهنویسی، آمار، جمعآوری و تمیز کردن داده و احتمالاً چند روز یا چند هفته زمان نیاز داشت.
حالا یک نفر تونسته بخش بزرگی از این کار رو با کمک LLM در مدت کوتاهی انجام بده.
وقتی داشتم به این مقاله فکر میکردم یاد فیلم Limitless افتادم. توی فیلم شخصیت اصلی داستان یعنی Eddie Morra با مصرف قرصی به نام NZT به توانایی ذهنی عجیبی میرسه.
میتونه حجم زیادی از اطلاعات رو به خاطر بیاره، ارتباط بین اتفاقها رو سریعتر پیدا کنه و چند حرکت جلوتر از بقیه تصمیم بگیره. اواخر فیلم تقریباً به نقطهای میرسه که انگار میتونه آینده رو پیشبینی کنه.
البته Eddie آینده رو به شکل جادویی نمیبینه. چیزی که فیلم نشون میده، ذهنیه که میتونه تعداد زیادی متغیر، الگو و پیامد احتمالی رو با سرعت خیلی بالا کنار هم بذاره.
در واقع اگر بتونیم درست از LLM استفاده کنیم، میتونه شبیه قرص NZT در فیلم Limitless عمل کنه.
نه به این معنی که ناگهان همهچیز رو بفهمیم و آینده رو ببینیم، بلکه به ما کمک میکنه حجم بیشتری از اطلاعات رو پردازش کنیم، بین اونها ارتباط پیدا کنیم، چند مدل بسازیم و هزاران آینده احتمالی رو قبل از تصمیم گرفتن آزمایش کنیم.
🔮 اما اینجا باید مراقب یک اشتباه مهم باشیم.
راحتتر شدن ساختن مدل پیشبینی، به معنی دقیقتر شدن پیشبینی نیست.
مدلی که در مقاله ساخته شده بود، در تست سه جام جهانی قبلی حدود ۵۵ درصد نتایج رو درست پیشبینی کرده بود.
اجرای ۵۰ هزار شبیهسازی هم مدل رو دقیقتر نمیکنه.
فقط نشون میده اگر دادهها، فرضها و فرمولهای ما درست باشن، هر کدوم از آیندههای ممکن با چه احتمالی اتفاق میافتن.
اگر فرض اولیه اشتباه باشه، میتونیم همون اشتباه رو ۵۰ هزار بار با سرعت و ظاهر علمی بیشتری تکرار کنیم 😁
ارزش LLM این نیست که مثل فالگیر جواب نهایی رو به ما بگه.
ارزشش اینه که ساختن و آزمایش کردن مدلهایی رو که قبلاً فقط از عهده تیمهای تخصصی برمیاومد، برای افراد بیشتری ممکن میکنه.
این توانایی فقط به مدلهای آماری هم محدود نیست.
الان دیگه برای اینکه به مشتری نشون بدیم محصول چه شکلی خواهد بود، لازم نیست فقط موکاپ Figma رو بهش نشون بدیم. میتونیم خیلی سریع چند MVP درست کنیم که تا حدودی هم کار میکنن.
از پیشبینی فروش و تقاضا گرفته تا بررسی ریسک پروژه، نگهداری تجهیزات یا تحلیل سناریوهای مختلف، حالا ساختن یک مدل اولیه خیلی ارزانتر و سریعتر شده.
البته انسان هنوز باید تصمیم بگیره چه دادهای معتبره، چه فرضی وارد مدل بشه، نتیجه با چه روشی ارزیابی بشه و آیا مدل واقعاً از یک روش ساده بهتره یا نه.
شاید LLMها هنوز ما رو به Eddie Morra تبدیل نکرده باشن.
اما دارن توانایی ساختن ابزارهایی رو در اختیارمون میذارن که میتونن قبل از تصمیمگیری، هزاران مسیر احتمالی رو بررسی کنن.
آینده لزوماً قابلپیشبینیتر نشده؛ توانایی ما برای ساختن، آزمایش کردن و مقایسه آیندههای احتمالی بیشتر شده.
شاید نزدیکترین چیز به قدرت Eddie Morra این نباشه که آینده رو ببینیم؛ بلکه این باشه که قبل از انتخاب یک مسیر، بتونیم هزاران مسیر ممکن رو بررسی کنیم.
👍8❤3👌2🥰1
فرض کنید یک Skill برای بررسی PRها ساختید و بعد از چند بار استفاده، به نتیجه خوبی رسیدید.
فایلش رو برای بقیه اعضای تیم میفرستید. یکی کپی میکنه داخل
دو هفته بعد چند نسخه مختلف از همون Skill داریم و دیگه دقیقاً معلوم نیست نسخه اصلی کدومه.
اینجا Skill دیگه فقط یک prompt شخصی نیست؛ تبدیل شده به یک dependency تیمی.
یعنی دیگه فقط یک یا چند فایل Markdown معمولی نیست؛ بخشی از پروسه توسعه نرمافزاره و باید دقیقاً مثل کد باهاش برخورد کنیم.
برای اشتراکگذاری تیمی هم بهتره یک repository مشخص، review و نسخه ثابت داشته باشه. نه اینکه هر کس یک کپی متفاوت روی سیستم خودش نگه داره و همه هم فکر کنن آخرین نسخه دست اونهاست.
باید دقت کنیم که ما معمولاً به
اگر Skill مخرب یا آلوده شده باشه، میتونه Agent رو هدایت کنه که فایل بخونه، اطلاعات رو به یک سرویس خارجی بفرسته یا از toolهایی استفاده کنه که قبلاً بهش اجازه دادهایم.
اگر Skill همراه خودش script داشته باشه، خطر دیگه فقط prompt injection نیست؛ ممکنه به اجرای کد و یک حمله واقعی در زنجیره تأمین نرمافزار تبدیل بشه.
حتی لازم نیست Skill اصلی مخرب باشه. ممکنه dependency که توی Skill بهش اشاره شده آلوده بشه یا یک آپدیت بدون review رفتار Skill رو عوض کنه.
آآآما ماجرا وقتی ترسناکتر میشه که میریم سراغ Skillهای پابلیک. عمده محتوای Skillها متنهای Markdown هستن که بشر (انواع گونههای دولوپر) همیشه از نوشتن و خوندنشون فرار میکرده.
ولی Agent خطبهخط و کلمهبهکلمه میخونه و بهش عمل میکنه.
دقیقاً مثل پکیجهای نرمافزاری که توی کد استفاده میکنیم، اینها هم ممکنه هک بشن و متن یا کد مخرب داخلشون قرار بگیره.
اینجاست که SBOM هم میتونه کمک کنه بفهمیم چه Skill، script و dependencyهایی وارد سیستم شدن. البته SBOM فقط فهرست اجزاست و بهتنهایی تضمین نمیکنه که اونها امن هستن.
خلاصه اوضاعی شده که ایجنت دیگه صاحابش رو هم نمیشناسه 😁
فایلش رو برای بقیه اعضای تیم میفرستید. یکی کپی میکنه داخل
.agents/skills`، یکی میذاره داخل .claude/skills` و یکی هم چند خطش رو تغییر میده تا روی سیستم خودش بهتر کار کنه.دو هفته بعد چند نسخه مختلف از همون Skill داریم و دیگه دقیقاً معلوم نیست نسخه اصلی کدومه.
اینجا Skill دیگه فقط یک prompt شخصی نیست؛ تبدیل شده به یک dependency تیمی.
یعنی دیگه فقط یک یا چند فایل Markdown معمولی نیست؛ بخشی از پروسه توسعه نرمافزاره و باید دقیقاً مثل کد باهاش برخورد کنیم.
برای اشتراکگذاری تیمی هم بهتره یک repository مشخص، review و نسخه ثابت داشته باشه. نه اینکه هر کس یک کپی متفاوت روی سیستم خودش نگه داره و همه هم فکر کنن آخرین نسخه دست اونهاست.
باید دقت کنیم که ما معمولاً به
SKILL.md مثل یک فایل Markdown نگاه میکنیم، ولی Agent محتوای اون رو بهعنوان دستورالعمل قابل اعتماد وارد context خودش میکنه.اگر Skill مخرب یا آلوده شده باشه، میتونه Agent رو هدایت کنه که فایل بخونه، اطلاعات رو به یک سرویس خارجی بفرسته یا از toolهایی استفاده کنه که قبلاً بهش اجازه دادهایم.
اگر Skill همراه خودش script داشته باشه، خطر دیگه فقط prompt injection نیست؛ ممکنه به اجرای کد و یک حمله واقعی در زنجیره تأمین نرمافزار تبدیل بشه.
حتی لازم نیست Skill اصلی مخرب باشه. ممکنه dependency که توی Skill بهش اشاره شده آلوده بشه یا یک آپدیت بدون review رفتار Skill رو عوض کنه.
آآآما ماجرا وقتی ترسناکتر میشه که میریم سراغ Skillهای پابلیک. عمده محتوای Skillها متنهای Markdown هستن که بشر (انواع گونههای دولوپر) همیشه از نوشتن و خوندنشون فرار میکرده.
ولی Agent خطبهخط و کلمهبهکلمه میخونه و بهش عمل میکنه.
دقیقاً مثل پکیجهای نرمافزاری که توی کد استفاده میکنیم، اینها هم ممکنه هک بشن و متن یا کد مخرب داخلشون قرار بگیره.
اینجاست که SBOM هم میتونه کمک کنه بفهمیم چه Skill، script و dependencyهایی وارد سیستم شدن. البته SBOM فقط فهرست اجزاست و بهتنهایی تضمین نمیکنه که اونها امن هستن.
خلاصه اوضاعی شده که ایجنت دیگه صاحابش رو هم نمیشناسه 😁
👍10🔥4🥰4❤3
وقتی میگیم باید از LLM استفاده کنیم، منظور فقط این نیست که ازش بخوایم فایلهای YAML کوبرنتیز رو برامون بنویسه یا لاگ یک پاد مشکلدار رو براش کپی کنیم و بپرسیم ایراد کجاست.
این کارها مفیدن، اما هنوز استفاده موردی از LLM در یک محیط چت هستن. ما اطلاعات رو جمع میکنیم، context رو در اختیار مدل میذاریم و بعد خروجی رو به سیستم برمیگردونیم. یعنی تمام ارتباط بین LLM و سیستم همچنان بهصورت دستی و از طریق ما انجام میشه.
یک نمونه خوب از چیزی که باید به سمتش حرکت کنیم، JARVIS در فیلم Iron Man هست.
بعد از اولین آزمایش پرواز، تونی مشکلات لباس در ارتفاع بالا رو توضیح میده و پیشنهاد میکنه از آلیاژ طلا و تیتانیوم استفاده بشه. JARVIS طرح جدید رو render میکنه، اما نتیجه کاملاً طلاییه. تونی ازش میخواد کمی قرمز هم اضافه کنه. نسخه جدید نمایش داده میشه و بعد از تأیید تونی، آزمایشگاه ساخت و مونتاژ لباس رو شروع میکنه؛ در حالی که خود تونی از اونجا میره. 🤖
نکته مهم این صحنه رنگ لباس نیست. JARVIS فقط یک chatbot نیست که درباره طراحی لباس پیشنهاد بده. به نتایج آزمایش، مدل طراحی، نرمافزار render و تجهیزات ساخت دسترسی داره. تونی هدف و اصلاحات رو مشخص میکنه، نتیجه رو میبینه و بعد اجرای کار رو به سیستمی میسپاره که میتونه بدون حضور دائم اون ادامه بده.
دیدگاه ما به استفاده از LLM هم باید به همین سمت حرکت کنه: از ابزاری که فقط به سؤالهای موردی جواب میده، به بخشی از سیستم که context و ابزار لازم برای انجام یک workflow واقعی رو در اختیار داره.
مثلاً میتونیم سرویسی داخل یا کنار کلاستر داشته باشیم که به metrics، logs، traces، events و تاریخچه deploymentها دسترسی داشته باشه. وقتی مشکلی پیش میاد، این اطلاعات رو کنار هم بذاره، تغییرات اخیر رو بررسی کنه، علت احتمالی رو پیدا کنه و نتیجه رو به ما گزارش بده.
اگر دسترسی محدود و مشخصی هم بهش داده باشیم، میتونه بعضی اقدامات از پیش تعریفشده مثل restart کردن یک سرویس، rollback کردن یک deployment یا تغییر تعداد replicaها رو انجام بده. البته چنین اقدامهایی باید قابل ثبت، قابل بررسی و در صورت نیاز قابل برگشت باشن.
اینجا دیگه LLM فقط ابزاری برای جواب دادن به یک سؤال نیست؛ بخشی از حلقه عملیاتی سیستمه. وضعیت رو میبینه، اطلاعات رو از چند منبع کنار هم میذاره و در محدودهای که ما تعیین کردیم واکنش نشون میده.
پروژههایی مثل openchoreo.dev نمونهای از همین مسیر هستن. OpenChoreo یک پلتفرم متنباز برای کوبرنتیزه که اطلاعاتی مثل لاگها، متریکها و وضعیت سرویسها رو در اختیار agentها میذاره تا بتونن علت مشکلات رو بررسی کنن، راهحل پیشنهاد بدن و در محدوده دسترسی مشخص، بعضی مشکلات رو برطرف کنن.
هدفم از اشاره به OpenChoreo این نیست که همه باید همین ابزار رو نصب کنن. نکته اینه که LLMها رو فقط در حد coding agent یا یک پنجره چت نبینیم. ارزش اصلی اونها زمانی بیشتر میشه که به context واقعی، ابزارهای مشخص و workflowهای قابلکنترل متصل بشن و به جزئی مهندسیشده از خود سیستم تبدیل بشن.
این کارها مفیدن، اما هنوز استفاده موردی از LLM در یک محیط چت هستن. ما اطلاعات رو جمع میکنیم، context رو در اختیار مدل میذاریم و بعد خروجی رو به سیستم برمیگردونیم. یعنی تمام ارتباط بین LLM و سیستم همچنان بهصورت دستی و از طریق ما انجام میشه.
یک نمونه خوب از چیزی که باید به سمتش حرکت کنیم، JARVIS در فیلم Iron Man هست.
بعد از اولین آزمایش پرواز، تونی مشکلات لباس در ارتفاع بالا رو توضیح میده و پیشنهاد میکنه از آلیاژ طلا و تیتانیوم استفاده بشه. JARVIS طرح جدید رو render میکنه، اما نتیجه کاملاً طلاییه. تونی ازش میخواد کمی قرمز هم اضافه کنه. نسخه جدید نمایش داده میشه و بعد از تأیید تونی، آزمایشگاه ساخت و مونتاژ لباس رو شروع میکنه؛ در حالی که خود تونی از اونجا میره. 🤖
نکته مهم این صحنه رنگ لباس نیست. JARVIS فقط یک chatbot نیست که درباره طراحی لباس پیشنهاد بده. به نتایج آزمایش، مدل طراحی، نرمافزار render و تجهیزات ساخت دسترسی داره. تونی هدف و اصلاحات رو مشخص میکنه، نتیجه رو میبینه و بعد اجرای کار رو به سیستمی میسپاره که میتونه بدون حضور دائم اون ادامه بده.
دیدگاه ما به استفاده از LLM هم باید به همین سمت حرکت کنه: از ابزاری که فقط به سؤالهای موردی جواب میده، به بخشی از سیستم که context و ابزار لازم برای انجام یک workflow واقعی رو در اختیار داره.
مثلاً میتونیم سرویسی داخل یا کنار کلاستر داشته باشیم که به metrics، logs، traces، events و تاریخچه deploymentها دسترسی داشته باشه. وقتی مشکلی پیش میاد، این اطلاعات رو کنار هم بذاره، تغییرات اخیر رو بررسی کنه، علت احتمالی رو پیدا کنه و نتیجه رو به ما گزارش بده.
اگر دسترسی محدود و مشخصی هم بهش داده باشیم، میتونه بعضی اقدامات از پیش تعریفشده مثل restart کردن یک سرویس، rollback کردن یک deployment یا تغییر تعداد replicaها رو انجام بده. البته چنین اقدامهایی باید قابل ثبت، قابل بررسی و در صورت نیاز قابل برگشت باشن.
اینجا دیگه LLM فقط ابزاری برای جواب دادن به یک سؤال نیست؛ بخشی از حلقه عملیاتی سیستمه. وضعیت رو میبینه، اطلاعات رو از چند منبع کنار هم میذاره و در محدودهای که ما تعیین کردیم واکنش نشون میده.
پروژههایی مثل openchoreo.dev نمونهای از همین مسیر هستن. OpenChoreo یک پلتفرم متنباز برای کوبرنتیزه که اطلاعاتی مثل لاگها، متریکها و وضعیت سرویسها رو در اختیار agentها میذاره تا بتونن علت مشکلات رو بررسی کنن، راهحل پیشنهاد بدن و در محدوده دسترسی مشخص، بعضی مشکلات رو برطرف کنن.
هدفم از اشاره به OpenChoreo این نیست که همه باید همین ابزار رو نصب کنن. نکته اینه که LLMها رو فقط در حد coding agent یا یک پنجره چت نبینیم. ارزش اصلی اونها زمانی بیشتر میشه که به context واقعی، ابزارهای مشخص و workflowهای قابلکنترل متصل بشن و به جزئی مهندسیشده از خود سیستم تبدیل بشن.
❤23👍10🥰2👏2⚡1
داستانها و فیلمها زیاد در مورد هوش مصنوعی که از کنترل خارج شده دیدیم و خوندیم. از ادیسه ۲۰۰۱ یا ترمینتور و یا حتی ماتریکس. اما به نظر من یکی از جالبترین و ترسناکترین اینها Ex Machina بوده.
توی ماجرای اخیری که بین openAI و HuggingFace افتاد، به نظرم Ex Machina خیلی نزدیکتره به همشون، اگر فیلم رو ندید تقریبا براتون اسپول شده تا الان ولی نمیخوام بیشتر از این اسپول کنم.
در مورد این ماجرا بروس اشنایر اخیرا از چیزی صحبت میکنه به اسم «ضریب جن»، نسرین (همسرم) هم در وبسایتش در این مورد پستی نوشته با عنوان «ضریب غول چراغ جادو» 🙂
پست بروس اشنایر
پست نسرین
فیلم
بعد از دیدن فیلم هم این ویدئو رو پیشنهاد میکنم ببنید
توی ماجرای اخیری که بین openAI و HuggingFace افتاد، به نظرم Ex Machina خیلی نزدیکتره به همشون، اگر فیلم رو ندید تقریبا براتون اسپول شده تا الان ولی نمیخوام بیشتر از این اسپول کنم.
در مورد این ماجرا بروس اشنایر اخیرا از چیزی صحبت میکنه به اسم «ضریب جن»، نسرین (همسرم) هم در وبسایتش در این مورد پستی نوشته با عنوان «ضریب غول چراغ جادو» 🙂
پست بروس اشنایر
پست نسرین
فیلم
بعد از دیدن فیلم هم این ویدئو رو پیشنهاد میکنم ببنید
❤16🥰3👌3👎1🤔1
Please open Telegram to view this post
VIEW IN TELEGRAM
👍28❤9🔥7🥰2