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

#علم اگر اشتباه کند اشتباهش را خواهد پذیرفت.
اما مذهبی تو را می‌کشند
تا ثابت کنند #دین هرگز اشتباه نمی‌کند.

“#Science may be wrong. #Religion never is.”
So they kill you to prove it.
— Bertrand Russell

اگر به بازاندیشی بنیادین در نحوه ساخت نرم‌افزار علاقه دارید، پروژه #معمار ارزش دنبال کردن داره 🧐

اکثر پروژه‌های نرم‌افزاری بر پایه یک زبان یا یک سیستم‌عامل خاص طراحی می‌شن؛ یعنی اون زبان یا OS هست که قواعد بازی رو تعیین می‌کنه. Memar (معمار) این رابطه رو برعکس می‌کنه: در این چارچوب، فریم‌ورک مرجع اصلی تصمیم‌گیری معماری‌ست و زبان برنامه‌نویسی (Khayyam)، سیستم‌عامل (PersiaOS) و پروتکل‌های شبکه (Chapar، GP، sRPC) صرفاً کامپوننت‌هایی هستن که در دل همون معماری تعریف می‌شن، نه برعکس.
یکی از دلایل مهم وجود چنین چارچوبی، توسعه در کنار #هوش_مصنوعی هست. وقتی قواعد معماری به‌صورت صریح و از پیش مشخص تعریف شده باشن، هوش مصنوعی برای پر کردن جاهای مبهم مجبور نیست خودش پیش‌فرض بسازه؛ پیش‌فرضی که می‌تونه مسیر توسعه رو دچار خطا کنه. ساختار مشخص یعنی مسیر تصمیم‌گیری هم برای انسان و هم برای ابزارهای هوش مصنوعی روشن‌تره.
این پروژه چند سال هست به‌صورت مستقل در حال طراحی و توسعه‌ست. هدف ساختن یک محصول با عجله نیست؛ ساختن زیرساختی پایدار و چندنسلی هست. تصمیمات معماری مستندسازی و نقد می‌شن.

جزئیات بیشتر در کامنت‌ها

🧠 اهمیت درک عمیق از مفهوم کلمه عامل (Agent) برای حل مشکلات کار کردن با #هوشواره ها (AI)
🔬این روزها تقریباً همه دربارهٔ AI Agentها صحبت می‌کنند؛ ابزارهای جدید معرفی می‌شوند، دوره‌های آموزشی برگزار می‌شود و هر روز اصطلاحات تازه‌ای وارد اکوسیستم می‌شوند. اما احساس می‌کنم قبل از اینکه بخواهیم یاد بگیریم چگونه با AI Agentها کار کنیم، لازم است یک قدم به عقب برگردیم. شاید مسئله اصلاً هوشواره نباشد. شاید مسئله این باشد که ما هنوز مفهوم Agent (#عامل) را به‌درستی #مدل نکرده‌ایم.

🚨وقتی کلمهٔ Agent را می‌شنویم، ذهنمان مستقیم به سمت #هوش_مصنوعی می‌رود، در حالی که Agent مفهومی بسیار قدیمی‌تر و عمومی‌تر است. هر موجودیتی که از طرف یک سیستم (شخص، سازمان، ...)، مسئولیتی را بر عهده می‌گیرد، یک Agent است. اگر این تعریف را بپذیریم، آن وقت AI Agent فقط یکی از انواع Agentها خواهد بود؛ همان‌طور که یک کارمند، یک پیمانکار، یک نرم‌افزار، یک سرویس یا حتی یک سازمان نیز می‌تواند نقش یک Agent را ایفا کند. و دقیقاً همین‌جا است که نگاه ما به #مسئله تغییر می‌کند. یک #تلنگر_ذهنی و سوال باز #فلسفه_ذهن را هم مطرح کنیم که حتی میشه بدن انسان را هم به نوعی عامل هویت اون فرد در نظر بگیریم.
اگر AI Agent را مفهومی کاملاً جدید تصور کنیم، ناخواسته بخش بزرگی از دانش انباشتهٔ گذشته دربارهٔ تعامل با Agentها را کنار می‌گذاریم و دوباره همان اشتباهات را با نام‌های جدید تکرار می‌کنیم.

⏳بخش بزرگی از مشکلاتی که امروز به هوشواره نسبت می‌دهیم، در واقع سال‌ها قبل از ظهور هوشواره هم وجود داشته‌اند.
- وقتی مسئولیت را مبهم واگذار می‌کنیم...
- وقتی انتظار خروجی را شفاف تعریف نمی‌کنیم...
- وقتی زمینهٔ لازم را منتقل نمی‌کنیم...
- وقتی دانش سازمان در ذهن افراد باقی می‌ماند و به دانش مشترک تبدیل نمی‌شود...
نتیجه معمولاً قابل پیش‌بینی نیست؛ چه طرف مقابل یک انسان باشد، چه یک هوشواره. دقت کنیم هوشواره مشکل جدیدی ایجاد نکرده است؛ فقط کیفیت #مدل_ذهنی و کیفیت #مدیریت_دانش ما را با وضوح بیشتری نمایان کرده است.

⏳به همین دلیل، شاید بهتر باشد به جای اینکه فقط دربارهٔ نقش‌های کاذب (False Classification) منتسب به مهندسی مثل Prompt Engineering یا Harness Engineering صحبت کنیم، دربارهٔ اصول تعامل با هر Agent صحبت کنیم؛ اصولی که سال‌ها قبل از ظهور هوشواره نیز وجود داشته‌اند و احتمالاً سال‌ها بعد از تغییر فناوری‌های امروز نیز معتبر خواهند ماند. در چند کامنت زیر همین پست، سعی می‌کنم دربارهٔ همین اصول صحبت کنم؛ از #تفویض_اختیار و نحوهٔ #مستندسازی از نگارش درخواست‌ها گرفته تا انتقال زمینه، مرزهای مسئولیت، معیارهای پذیرش و نقش #مدیریت_دانش در تعامل با عامل‌ها.

⏳شاید هنگام خواندن این متن با خودتان گفته باشید:
- ما هم مدام خروجی‌هایی می‌گیریم که با انتظارمان فاصله دارند.
- هر بار باید دوباره همه چیز را توضیح بدهیم.
- افراد مختلف برداشت‌های متفاوتی از یک درخواست دارند.
- دانش پروژه بیشتر در ذهن افراد است تا در مستندات.
- با وجود استفاده از هوشواره، کیفیت خروجی تیم بهتر نشده، فقط سرعت تولید بیشتر شده است.
اگر چنین نشانه‌هایی را در #سازمان خود می‌بینید، احتمال دارد مسئلهٔ اصلی نه هوشواره باشد و نه حتی افراد تیم. این‌ها معمولاً نشانه‌هایی از ضعف در #مدیریت_دانش، نبود یک #چارچوب_توسعه مشترک، ابهام در تعریف مسئولیت‌ها یا ضعف در مدل‌سازی مسائل سازمان هستند. این‌ها با تعویض ابزار حل نمی‌شوند؛ نیازمند اصلاح شیوهٔ فکر کردن، انتقال دانش و طراحی فرآیندهای توسعه هستند.

🔗 در Geniuses.Group نیز دقیقاً همین دغدغه را دنبال می‌کنیم؛ کمک به سازمان‌ها برای ساختن سیستم‌هایی که پایداری آن‌ها تنها به فناوری وابسته نباشد، بلکه بر پایهٔ مدل‌های ذهنی دقیق‌تر، مدیریت دانش بهتر و تعامل مؤثرتر میان عامل‌ها شکل بگیرد.

یک باگ عجیب خورد تلگرام، من پستی را در کانال Geniuses Group گذاشتم ولی در گروه چت وابسته به کانال نیومد! خودم دستی هم فرستادم، ببینم درست میشه کامنت گذاشتن ولی نشد. فکر می‌کردم تلگرام باگ خیلی کم داره که دیده نمیشه، ولی مثل اینکه باگ‌ها همه جا هستند 😂😂

پ.ن: البته من نقد خیلی جدی به نحوه مدل کردن TimeLine و Content به عنوان دو جز اصلی همه سیستم‌هایی محتوایی در تلگرام و دیگر شبکه‌های احتماعی دارم که در جلسات #خوانش کتاب‌ها بهشون اشاره‌هایی داشتم، پس جوری القا نشه که من گفتم تلگرام خیلی خوبه و جای بهتر شدن نداره 😉

🧠 اگر مفهوم #عامل را درست بفهمیم، احتمالاً مجبور شویم دوباره به #Process و #Concurrency هم نگاه کنیم
🔬 در پست قبلی درباره این صحبت کردم که چرا نباید با شنیدن #AI_Agent، مفهوم #Agent را از صفر و صرفاً در چارچوب هوش مصنوعی تعریف کنیم. اما این نگاه یک نتیجه جالب‌تر هم دارد.
اگر Agent یک مفهوم عمومی باشد، آن‌وقت عاملیت (Agency) فقط دربارهٔ هوشواره‌ها نیست؛ درباره نحوه‌ای است که یک موجودیت می‌تواند مسئولیت انجام چیزی را بر عهده بگیرد، تصمیم بگیرد و در چارچوب توانمندی و اختیار خود عمل کند. و وقتی این مفهوم را وارد #مدل_سازی کنیم، بعضی مفاهیم بسیار آشنای نرم‌افزار هم ناگهان شکل دیگری پیدا می‌کنند.

⏳ مثلاً #Process. ما معمولاً Process را از روی چیزهایی که برای اجرای آن ساخته‌ایم تصور می‌کنیم: Thread، Coroutine، Queue، Lock، Transaction، Scheduler و... در حالی که هیچ‌کدام از این‌ها ذات Process نیستند. Process ابتدا باید از خود progression، فعالیت‌ها، مشارکت‌کنندگان، مسئولیت‌ها، وابستگی‌ها، محدودیت‌ها و نتایجش فهمیده شود؛ بعد تازه می‌توانیم درباره مکانیزم اجرای آن تصمیم بگیریم.
همین نگاه، برداشت ما از #Concurrency را هم تغییر می‌دهد.
آیا واقعاً هر جا چند فعالیت هم‌زمان یا درهم‌تنیده داریم باید به سراغ Lock برویم؟
آیا مسئله این است که چند Thread داریم؟ یا شاید مسئله واقعی این باشد که چه کسی مسئول انجام یک فعالیت است و در هر لحظه چه عاملی مسئول وضعیت مورد نظر است؟
اگر بتوانیم مسئولیت را درست میان عامل‌های پردازشی تقسیم کنیم، شاید اصلاً نیازی به بسیاری از مکانیزم‌های هماهنگی که بعداً برای جلوگیری از تعارض ایجاد می‌کنیم نباشد. حتی ممکن است دو فعالیت روی یک CPU Core اجرا شوند و همچنان مسئلهٔ Concurrency داشته باشیم؛ بنابراین Core فیزیکی و Agent یا Worker منطقی را هم نباید یکی فرض کنیم.
اینجاست که به نظرم مفهوم Agent واقعاً ارزش خودش را نشان می‌دهد.

🚨 اگر به جای اینکه از مکانیزم شروع کنیم، از عاملیت، مسئولیت، اختیار، قابلیت و ارتباط میان عامل‌ها شروع کنیم، ممکن است بسیاری از راه‌حل‌هایی که امروز به‌عنوان «راه‌حل‌های استاندارد» می‌شناسیم، دیگر تنها گزینه‌های ممکن به نظر نرسند.
حتی ممکن است بفهمیم بعضی از پیچیدگی‌هایی که سال‌ها با Queue و Lock و Synchronization و Scheduler به سیستم اضافه کرده‌ایم، در واقع حاصل این بوده که خود مسئله را به‌درستی مدل (Modeling) نکرده‌ایم. این دقیقاً همان چیزی است که در #معماری برای ما اهمیت دارد:

از مکانیزم شروع نکنیم؛ ابتدا واقعیت را مدل کنیم.

🤔 حالا یک سؤال جدی‌تر:
چه کسی بدون اینکه از ابتدا به دنبال ساختن Actor، Worker، Coroutine، Thread Pool، Lock یا یک Scheduler باشد، به این نتیجه رسیده که می‌توان Process را ابتدا از منظر Agency، Responsibility و Ownership مدل کرد و سپس Actor یا Worker را به‌عنوان یکی از نمودهای اجرایی آن مدل به دست آورد؟
یعنی ابتدا بپرسیم:
چه عامل‌هایی داریم؟ هر عامل چه مسئولیتی دارد؟ چه چیزی را می‌داند؟ چه چیزی را می‌تواند تغییر دهد؟ در هر لحظه چه چیزی تحت مسئولیت کدام عامل است؟ و چه ارتباطی واقعاً میان عامل‌ها لازم است؟
شاید آن‌وقت #Concurrency دیگر مسئله‌ای نباشد که بعد از طراحی سیستم مجبور شویم برایش Lock بسازیم؛ بلکه تا حد زیادی نتیجهٔ طبیعی مدلی باشد که از ابتدا عاملیت و مسئولیت را درست فهمیده است.

🔗 اگر موضوع براتون جذاب هست میتونید پروژه #معمار (پست مربوطه) را دنبال کنید. یک مثال و یک شاهد عینی هم در کامنت‌ها برای همین پست می‌گذارم که درک بهتری از این ایده ایجاد بشه.

🧠 بیایید کمی کمتر از هوشواره کمک بگیریم!

🔬 در دنیایی که هر روز بیشتر از قبل داریم کارهای خودمان را به هوشواره‌ها (AI Agent) می‌سپاریم، یک نگرانی کوچک دارم:
نکند در کنار برون‌سپاری کارها، کم‌کم خودِ فکر کردن را هم برون‌سپاری کنیم؟ 🤔
قرار نیست استفاده از هوشواره را کنار بگذاریم؛ اتفاقاً یکی از موضوعات اصلی بحث‌های ما همین استفاده درست از آن است. اما شاید بد نباشد گاهی قبل از اینکه سؤال را از هوشواره بپرسیم، خودمان چند دقیقه با آن کلنجار برویم.
از این به بعد می‌خواهم هر از گاهی چند سؤال کوتاه و باز از دل موضوعات مختلفی که در #معمار و Geniuses.Group روی آن‌ها فکر می‌کنیم مطرح کنم.

📌 قانون خاصی هم نداریم:
می‌توانید از هوشواره کمک بگیرید، سرچ کنید، با دوستانتان بحث کنید یا اصلاً جواب ندهید!
فقط یک پیشنهاد:
اول خودتان فکر کنید، بعد سراغ هوشواره بروید. 😉
اگر هم به جواب یا زاویه جالبی رسیدید، خوشحال می‌شویم آن را زیر همین پست با بقیه به اشتراک بگذارید؛ شاید ارزشمندترین بخش این تمرین، خودِ پاسخ نباشد، بلکه مسیر رسیدن به پاسخ باشد.

⏳خب، برای شروع این ۱۰ سؤال را امتحان کنیم:
🔹 ۱. Transaction
اگر یک Transaction هیچ پولی جابه‌جا نکند، آیا هنوز یک Transaction است؟
آیا اصلا واحد شمارش، داده‌ای وابسته به Transaction است؟ یا پیش فرض واحد پول تراکنش یک فرض میراثی گمراه کننده است؟
🔹 ۲. State
اگر چیزی را بتوانیم از دست بدهیم و سیستم همچنان دقیقاً همان رفتار درست را داشته باشد، آیا واقعاً بخشی از State سیستم بوده است؟
🔹 ۳. Agent یا عامل
آیا هر چیزی که بتواند از طرف یک موجودیت دیگر مسئولیتی را بر عهده بگیرد، یک Agent است؟
🔹 ۴. Attribute یا Edge؟
اگر یک ویژگی بتواند به‌صورت مستقل تغییر کند و روی رفتار سیستم اثر بگذارد، چه زمانی باید آن را Attribute بدانیم و چه زمانی یک Edge؟
🔹 ۵. Process یا فرآیند
آیا هر دنباله‌ای از Activityها یک Process است؟ اگر نه، چه چیزی یک دنباله را به Process تبدیل می‌کند؟
🔹 ۶. Service
اگر یک Service هیچ کار مستقیمی برای کاربر انجام ندهد، اما مسئول ایجاد یک تغییر در سیستم باشد، آیا هنوز Service است؟
🔹 ۷. Ownership
آیا مالکیت یک Attribute از یک موجودیت است یا رابطه‌ای مستقل میان دو موجودیت؟
🔹 ۸. Identity
اگر دو موجودیت تمام ویژگی‌های فعلی یکسانی داشته باشند، چه چیزی باعث می‌شود بگوییم هنوز دو موجودیت متفاوت‌اند؟
🔹 ۹. Architecture
آیا می‌توان معماری یک سیستم را بدون دانستن اینکه سیستم با چه زبان، دیتابیس یا سیستم‌عاملی پیاده‌سازی خواهد شد، به‌درستی تعریف کرد؟
🔹 ۱۰. Problem
اگر چیزی را بتوانیم به‌سادگی با یک راه‌حل فنی حل کنیم، آیا حتماً از ابتدا یک Problem فنی داشته‌ایم؟

🧐 قرار نیست جواب درست را سریع پیدا کنیم.
قرار است کمی تمرین کنیم که قبل از پرسیدن از دیگران، خودمان سؤال را زندگی کنیم. مثلا پیش فرض سوالات بالا را متوجه شویم و خود پیش فرض ها را هم در صورت لزوم بهشون فکر کنیم. مثلا با خوانده سوالات آیا متوجه شدید که پیش فرض خیلی از سوالات، نظریه گراف در ریاضی ولی برای فاز مدل کردن در علوم کامپیوتر هست؟
#تلنگر_ذهنی #تفکر #تفکر_انتقادی #معمار #هوشواره

🧠 برای گفتن چیزی، درباره چیزی که نمی‌خواهی بگویی حرف نزن!

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

❌ «ما از X استفاده نمی‌کنیم، چون X این مشکل را دارد، آن مشکل را دارد و در شرایط Y هم مناسب نیست...»

از نظر ما کاملاً واضح است که نتیجه چیست:

گزاره X انتخاب ما نیست.

اما در متن، چه چیزی واقعاً اتفاق افتاده؟
ما X را وارد بحث کرده‌ایم، درباره‌اش توضیح داده‌ایم، ویژگی‌هایش را گفته‌ایم، رابطه‌اش را با چند مفهوم دیگر ساخته‌ایم و چندین بار آن را در ذهن مخاطب فعال کرده‌ایم.
بعد انتظار داریم مخاطب همه اینها را به خاطر بسپارد و در انتها فقط یک NOT روی X بگذارد!


🤔 این مسئله فقط مشکل هوشواره‌ها نیست.
انسان هم وقتی یک مفهوم در میان توضیح‌های طولانی، استثناءها، مقایسه‌ها و گزاره‌های منفی قرار می‌گیرد، ممکن است ارتباط میان مفاهیم را گم کند.
اصلاً یکی از بخش‌های مهم نگارش همین است:

چگونه یک مفهوم را با کمترین ابهام و با حفظ رابطه‌اش با مفاهیم دیگر منتقل کنیم؟

ما فکر می‌کنیم وقتی کلمات را درست انتخاب کرده‌ایم، مفهوم را هم درست منتقل کرده‌ایم؛ در حالی که بین این دو فاصله زیادی وجود دارد.
— یک نفر چیزی را در ذهن دارد.
— آن را به مفهوم تبدیل می‌کند.
— برای آن مفهوم کلمه انتخاب می‌کند.
— کلمه را داخل جمله قرار می‌دهد.
— جمله را داخل پاراگراف قرار می‌دهد.
و در هر کدام از این مراحل ممکن است چیزی از مفهوم اولیه تغییر کند یا ابهامی به آن اضافه شود. پس
📌 نوشتن صرفاً کنار هم گذاشتن کلمات نیست؛ طراحی مسیر انتقال یک مفهوم است.


⏳ شاید به همین دلیل، برای بیان وضعیت فعلی یک سیستم، بهتر باشد به جای:

❌ «از X استفاده نمی‌کنیم، چون...»

بگوییم:

✅ «سیستم از Y استفاده می‌کند، زیرا...»

یعنی تا جای ممکن:
آنچه را حقیقت دارد، مستقیم بگوییم؛ نه اینکه برای توضیح آن، مسیر ذهنی را از میان چیزهایی که حقیقت ندارند عبور دهیم.
این اصل در کتاب، مقاله، قانون، استاندارد، مستندات فنی و آموزش همیشه مهم بوده است.


⏳اما ظهور هوشواره‌ها یک چیز را خیلی واضح‌تر کرده است:
📌 متنی که می‌نویسیم فقط خوانده نمی‌شود؛ ممکن است از روی آن یک مدل ذهنی ساخته شود.
اگر آن متن پر از گزینه‌های ردشده، فرضیه‌های منسوخ، احتمالات آینده و مفاهیم رقیب باشد، شاید داریم ناخواسته context را از چیزهایی پر می‌کنیم که قرار نبوده بخشی از مدل نهایی باشند.


📍برای همین در مستندات #معمار (پست مرتبط) هم داریم به یک تفکیک ساده فکر می‌کنیم:
📄 Document
آنچه اکنون درست است.
📜 Changelog
آنچه تغییر کرده و چرا.
🤝 Handoff
آنچه ممکن است بعداً اتفاق بیفتد.
چون شاید بهترین مستند، مستندی نباشد که همه چیز را درباره همه چیز گفته باشد؛
بلکه مستندی باشد که چیز درست را، دقیقاً همان‌جایی که باید، گفته باشد.


🧠 حالا سؤال:
آیا همیشه برای توضیح یک مفهوم، لازم است درباره چیزهایی که آن مفهوم نیست هم صحبت کنیم؟
یا گاهی بهترین راه انتقال یک اندیشه این است که فقط بگوییم:

این است آنچه می‌دانیم.

🧠 بنیان، از نتیجه‌هایش تعریف نمی‌شود!

در فاز #مدل_سازی در ساختن هر نظام دانشی (#معمار)، از یک کتاب و نظریه علمی گرفته تا مستندات یک سیستم، روش یک سازمان یا حتی مجموعه‌ای از باورهای شخصی، یک اصل ساده وجود دارد:
📌 چیزی که قرار است پایه باشد، نباید برای تعریف خودش به چیزی وابسته باشد که روی همان پایه بنا شده است.

اما گاهی این وابستگی آن‌قدر آرام شکل می‌گیرد که اصلاً متوجه آن نمی‌شویم:
— لایه‌ای را می‌سازیم که قرار است بنیادی باشد؛
— بعد برای توضیح بخشی از آن، از مفهومی در لایه بالاتر کمک می‌گیریم؛
— و آن لایه بالاتر هم در نهایت بر همان لایه پایه بنا شده است.
— در ظاهر فقط یک ارجاع ساده ساخته‌ایم.
— اما در واقع، جهت وابستگی را برعکس کرده‌ایم.
اگر A پایه B باشد، B می‌تواند بر اساس A مفهوم جدیدی بسازد؛ اما تعریف بنیادی A نباید برای فهم خودش به B نیاز داشته باشد. وگرنه دیگر با یک بنیان مستقل روبه‌رو نیستیم؛ با یک دور مفهومی روبه‌رو هستیم.

⏳ راه‌حل ظاهری شاید این باشد که ارجاع‌ها را حذف کنیم. اما آن‌وقت مشکل دیگری ایجاد می‌شود، هر لایه شروع می‌کند به توضیح دادن همان مفهوم با زبان خودش. پنج سند، پنج روایت. و هر بار که یکی از آنها تغییر می‌کند، احتمال فاصله گرفتن روایت‌ها بیشتر می‌شود.
📌 پس مسئله حذف وابستگی نیست؛ پیدا کردن محل درست تعریف است.
یک مفهوم بنیادی باید یک‌بار، در جای درست، دقیق تعریف شود و لایه‌های بالاتر از آن استفاده کنند؛ نه اینکه هر کدام نسخه‌ای از آن برای خودشان بسازند. اما اینجا یک دام دیگر هم وجود دارد:
📌 واژه‌ها بی‌صاحب نیستند.
وقتی واژه‌ای را برای یک مفهوم تعریف کردیم، دیگر نمی‌توانیم در جای دیگری معنای متفاوتی به آن بدهیم و همچنان همان واژه را با خیال راحت استفاده کنیم. یک تعریف خوب باید جامع و مانع باشد؛ یعنی همه نمونه‌هایی را که واقعاً متعلق به مفهوم‌اند دربر بگیرد و چیزهایی را که متعلق به آن نیستند، بیرون نگه دارد.
برای همین، گاهی مشکل یک نظام دانشی نه کمبود مفهوم است و نه کمبود سند؛
📌فقط یک واژه دارد که همه از آن استفاده می‌کنند، اما هنوز کسی دقیقاً ننوشته است که یعنی چه.

⏳ این موضوع فقط به مستندات فنی مربوط نیست.
همین سؤال را می‌توان در #فلسفه_علم، طراحی سیستم، معماری، سازمان، نظریه‌های علمی و حتی باورهای شخصی دنبال کرد:
🔹 کدام اصل، واقعاً اصل است و کدام‌یک فقط توضیحی است که از نتایج به عقب برگشته؟
🔹 کدام تعریف، واقعاً مستقل است و کدام تعریف بدون استفاده از مفاهیم بالاتر قابل بیان نیست؟
🔹 کدام واژه را دقیقاً می‌دانیم و کدام واژه فقط به دلیل استفاده مکرر، آشنا به نظر می‌رسد؟
و شاید مهم‌تر از همه:

چند درصد از چیزهایی که فکر می‌کنیم «اصول» هستند، در واقع فقط نتیجه‌هایی هستند که بعداً به شکل اصل بازنویسی شده‌اند؟

🧠 به عنوان #تلنگر_ذهنی شاید یکی از مهم‌ترین بخش‌های ساختن #دانش جهت ارتقا سطح #تفکر، نه اضافه کردن اطلاعات بیشتر، بلکه پیدا کردن جهت درست وابستگی میان مفاهیم باشد.

🧠 روز برنامه‌نویس را به همه #اندیشمند‌ان تبریک می‌گوییم!

اما بیایید این روز را بهانه کنیم و یک سؤال ساده بپرسیم:
📌واقعاً چه کسی Programmer است؟
تعریف جالبی در فرهنگ واژه‌های حوزه کامپیوتر وجود دارد:

a person who designs, writes and tests computer programs

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

🤔 اگر یک هوشواره بتواند بخشی از Code را از چیزی که ما توصیف کرده‌ایم تولید کند، آیا آنچه انجام شده دیگر Programming نیست؟
شاید مسئله را باید کمی عقب‌تر ببریم.
— قبل از Code، چیزی باید طراحی شود.
— قبل از طراحی، باید بدانیم چه رفتاری می‌خواهیم.
— قبل از آن، باید بدانیم چه مسئله‌ای داریم.
— و قبل از آن، باید واقعیت، محدودیت‌ها و هدف را بفهمیم.
پس شاید زنجیره چیزی شبیه این باشد:
📌 Reality → Need → Model → Behavior → Program → Code
و Code فقط انتهای این زنجیره است.

⏳ حالا #هوشواره‌ها به‌سرعت دارند بخش‌هایی از انتهای این زنجیره را ارزان و خودکار می‌کنند.
تولید Code، بازنویسی Code، تست، رفع خطا و حتی بخشی از طراحی را می‌توان به آنها سپرد.
پس شاید سؤال اصلی این نباشد که:

«آیا هوشواره‌ها Programmerها را جایگزین می‌کنند؟»

بلکه:

اگر نوشتن Code دیگر کار اصلی Programmer نباشد، Programmer دقیقاً چه چیزی باید بداند و چه چیزی باید بسازد؟

شاید پاسخ، بیشتر از همیشه به #تفکر نزدیک باشد.
چون هرچه تولید Code آسان‌تر شود، ارزشِ دانستن اینکه چه چیزی باید ساخته شود، چرا باید ساخته شود و رفتار درست آن چیست بیشتر می‌شود.

📌 شاید Programmer کسی نباشد که بیشترین Code را می‌نویسد.
شاید Programmer کسی باشد که بتواند یک رفتار دقیق را از یک مسئله واقعی استخراج کند و آن را به برنامه‌ای قابل اجرا تبدیل کند.
و اگر این تعریف درست باشد، هوشواره‌ها پایان Programming نیستند؛
شاید فقط ما را مجبور کرده‌اند دوباره بفهمیم Programming واقعاً چیست.

🧠 امروز، روز برنامه‌نویس است.
به عنوان #تلنگر_ذهنی به‌جای شمردن خطوط Code، شاید بد نباشد از خودمان بپرسیم:
ما واقعاً کدام بخش از یک Program را بلدیم بسازیم؟ 🤔

🧠 چرا رسیدن به هوشمندی (خرد) برای انسان و AGI برای هوشواره این‌قدر سخت است؟

🔬این روزها تقریباً هر بار که صحبت از پیشرفت هوش مصنوعی می‌شود، یک پاسخ تکراری می‌شنویم:
مدل بزرگ‌تر، داده بیشتر، پارامتر بیشتر، محاسبات بیشتر.
و طبیعی هم هست؛ مدل‌های بزرگ‌تر معمولاً توانایی‌های بیشتری نشان می‌دهند. اما آیا مسیر رسیدن به #AGI واقعاً همین است؟ یا شاید مسئله جای دیگری است؟

🧐 اول باید بپرسیم AGI دقیقاً چیست؟ اگر بخواهیم خیلی ساده تعریف کنیم:

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

اگر این تعریف را بپذیریم، ناگهان مسئله خیلی سخت‌تر از «پیش‌بینی Token بعدی» به نظر می‌رسد.

📌 مسئله از کجا شروع می‌شود؟ ما انسان‌ها واقعیت را مستقیماً به ماشین منتقل نمی‌کنیم. حتی به یکدیگر هم منتقل نمی‌کنیم. یک زنجیره تقریباً شبیه این داریم:
Reality → Perception → Thought → Concept → Language → Text → Model
و در هر مرحله ممکن است ابهام وارد شود. یک انسان چیزی را در ذهن دارد. آن را به یک مفهوم تبدیل می‌کند. برای رساندن آن مفهوم، یک کلمه انتخاب می‌کند. ممکن است کلمه دقیق نباشد. ممکن است جمله مبهم باشد. ممکن است مخاطب برداشت دیگری داشته باشد. و تازه در اینجا است که ماشین با متن مواجه می‌شود. بنابراین Language خودِ Reality نیست؛ یک واسط برای انتقال بخشی از برداشت ما از Reality است. و این واسط ذاتاً می‌تواند مبهم باشد.

📌 پس LLM دقیقاً چه چیزی را یاد می‌گیرد؟ مدل زبانی از حجم عظیمی از این واسط‌های انسانی یاد می‌گیرد: متن، جمله، کلمه، ارتباط میان کلمات، الگوهای تکرارشونده و روابط موجود در داده‌ها. و با افزایش ظرفیت مدل، می‌تواند ساختارهای پیچیده‌تری از این داده‌ها استخراج کند. اما یک سؤال اساسی باقی می‌ماند:

آیا یادگیری ساختار زبان، الزاماً به معنای ساختن یک مدل قابل اتکا از واقعیت پشت زبان است؟

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

⏳اینجا شاید مسیر دیگری برای AGI لازم باشد.
شاید مسئله اصلی این نباشد که:
چند پارامتر دیگر به مدل اضافه کنیم؟
بلکه:
چگونه می‌توانیم با ظرفیت کمتر، representation دقیق‌تری از واقعیت بسازیم؟
به جای اینکه ابهام را با افزایش ظرفیت مدل جبران کنیم:
More Parameters → More Capacity
شاید باید به سمت چیزی شبیه این برویم:
Better Representation → Better Relations → Better World Model → Better Reasoning
یعنی به جای اینکه مدل برای هرچه چیزهای بیشتری را در خود جای دهد، بتواند ارتباط دقیق‌تری میان چیزهایی که می‌داند برقرار کند.
در این نگاه، هوشمندی الزاماً به معنای «دانستن بیشتر» نیست.
گاهی ممکن است به معنای دانستن کمتر، اما دقیق‌تر و ساختاریافته‌تر باشد.

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

«چگونه یک LLM بزرگ‌تر بسازیم؟»

بلکه:

چگونه سیستمی بسازیم که از یک واسط مبهم، یعنی زبان، به مدلی قابل اتکا از واقعیت برسد؛ آن مدل را از شواهد یاد بگیرد و اصلاح کند؛ و سپس بتواند بدون آموزش اختصاصی، درباره وضعیت‌هایی که قبلاً ندیده است استدلال کند؟

و شاید سخت‌ترین قسمت همین باشد. کاری که ما در #معمار در Geniuses.Group با ایجاد روش شناختی منسجم، سعی در حل کردنش را داریم ولی قطعا پاسخ قطعی و نهایی براش نداریم.

🤔 حالا یک سؤال برای شما:
اگر دو مدل را داشته باشیم:
مدل A:
۱۰۰۰ میلیارد پارامتر دارد و می‌تواند درباره تقریباً هر چیزی صحبت کند.
مدل B:
۱۰۰ میلیارد پارامتر دارد، اما یک مدل بسیار دقیق‌تر و ساختاریافته‌تر از واقعیت دارد و می‌تواند با شواهد جدید خودش را اصلاح کند.
کدام‌یک به AGI نزدیک‌تر است؟
و سؤال سخت‌تر:

آیا اصلاً می‌توان با افزایش پارامترهای یک مدل زبانی، از «مدل زبان» به «مدل واقعیت» رسید؟

🧠 این بار قبل از پرسیدن از هوشواره (#AI #ArtificialIntelligence)، کمی خودمان فکر (#تفکر) کنیم.
راستی یادمون نره که صرفا در مورد هوشمندی ماشین صحبت نمیکنیم 😉

🧠 داده، اطلاعات، دانش و خرد؛ یک هرم نیستند!

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

🧐 احتمالاً نمودار معروف DIKW Pyramid (اشتباها در فارسی هرم دانش یا هرم داده نامیده میشود) را دیده‌اید:
Data → Information → Knowledge → Wisdom
یک تصویر ساده که خیلی سریع به ما می‌گوید:
- #داده تبدیل به اطلاعات می‌شود،
- #اطلاعات تبدیل به دانش،
- و #دانش تبدیل به خرد.
اما شاید همین سادگی، ما را گمراه کرده باشد.

⏳ این چهار مفهوم بیشتر از آنکه چهار مرحله پشت سر هم باشند، به هم وابسته‌اند و دائماً روی یکدیگر اثر می‌گذارند.
- یک Input وارد سیستم می‌شود.
- سیستم با توجه به آنچه از قبل می‌داند، آن را تفسیر می‌کند.
- اگر این تفسیر بتواند عدم‌قطعیت یا ابهام را کاهش دهد، برای آن سیستم به Information تبدیل شده است.
- این Information می‌تواند در مدل درونی سیستم جای بگیرد و بخشی از Knowledge آن شود.
- و Knowledge دوباره تعیین می‌کند که Inputهای بعدی چگونه تفسیر شوند.

⏳ پس مسیر فقط این نیست:
Data → Information → Knowledge
بلکه می‌تواند این‌طور باشد:
Input ↔️ Data|Information ↔️ Knowledge
و شاید Wisdom هم اصلاً «طبقه بالاتر» این هرم نباشد.
اگر #خرد را توانایی استفاده از دانش برای تشخیص اهمیت، انتخاب و عمل بدانیم، دیگر با یک مرحله جدید از انباشته‌شدن چیزها روبه‌رو نیستیم؛ با نحوه استفاده از آنچه می‌دانیم روبه‌رو هستیم و به نوعی خرد، خودش بخشی از دانش درونی سیستم هست.

🧠 شاید به جای هرم، بهتر باشد این مفاهیم را بخشی از یک سیستم شناختی (#علوم_شناختی) ببینیم.

در کامنت‌ها کمی دقیق‌تر به این رابطه نگاه می‌کنیم.

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

🔬 نوشته بالا منتسب به Michael Laver #دانش_مند حوزه سیاست (Political scientist)، که به قشنگی تحریف کلمه سیاست و ظرایف آن را به نمایش در می‌آورد. شاید سیاست را بیش از حد دور دیده‌ایم. وقتی کلمهٔ «سیاست» را می‌شنویم، معمولاً ذهنمان به سمت دولت، انتخابات، احزاب، مجلس، قدرت و رقابت برای حکومت می‌رود.

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

⏳ #اندیشمند Harold Lasswell ، سیاست را با پرسش معروف «چه کسی چه چیزی را، چه زمانی و چگونه به دست می‌آورد؟» صورت‌بندی کرد. در برداشت گسترده‌ای از سیاست، چنین پرسش‌هایی فقط به حکومت محدود نیستند؛ هرجا افراد یا گروه‌ها دربارهٔ یک انتخاب جمعی، منابع، قواعد یا منافع متفاوت با یکدیگر سروکار دارند، می‌توان از سیاست سخن گفت.

⏳ پس سیاست لزوماً به معنای فریب، توطئه یا قدرت‌طلبی نیست. سیاست
- می‌تواند گفت‌وگو باشد.
- می‌تواند مذاکره باشد.
- می‌تواند ائتلاف باشد.
- می‌تواند رقابت باشد.
- می‌تواند سازش باشد.
- و حتی می‌تواند تلاش برای پیدا کردن راهی باشد که هیچ‌کس انتخاب اولش را به دست نمی‌آورد، اما همگی می‌توانند با آن زندگی کنند.

⏳ شاید نکتهٔ عجیب‌تر این باشد که برای دیدن سیاست، لازم نیست به یک کشور نگاه کنیم.
- گاهی کافی است دو نفر را کنار هم بگذاریم.
- دو دوست که می‌خواهند برای یک سفر تصمیم بگیرند.
- دو همکار که دربارهٔ اولویت یک کار اختلاف دارند.
- دو عضو خانواده که هرکدام تصور متفاوتی از یک تصمیم مشترک دارند.

در مقیاس بزرگ‌تر، همین مسئله می‌تواند به سازمان، جامعه یا دولت برسد؛ فقط تعداد بازیگران، قواعد، منابع و پیامدها پیچیده‌تر می‌شود.
به همین دلیل، Politics را نباید بی‌درنگ با Government یکی گرفت؛ و Governance هم مفهوم دیگری است که بر چگونگی هدایت، تصمیم‌گیری و تنظیم امور یک جمع یا سازمان تمرکز دارد. حتی در ادبیات علمی، دامنهٔ Politics از تعریف‌های محدودِ دولت‌محور تا تعریف‌های بسیار گسترده‌تر، مورد بحث است.

🤔 شاید مسئله این نباشد که
«چطور سیاست را از زندگی‌مان حذف کنیم؟»
شاید سؤال عمیق‌تر این باشد:
چطور سیاست را آن‌قدر درست بفهمیم که بتوانیم آن را، پیش از آنکه در اخبار ببینیم، در روابط انسانی ببینیم؟