# مسئلهای که با یک مدل بزرگ حل نمیشود
امروز مدلهای عمومی هوش مصنوعی کارهای بسیار متنوعی انجام میدهند؛ از نوشتن و تحلیل متن گرفته تا تولید تصویر، ویدئو، کد و انجام برخی عملیات روی کامپیوتر. اما مسئله را نباید اینطور تصور کرد:
wrong_model.txt
# This is NOT how AGI emerges:
مدل کوچک
→
مدل بزرگتر
→
مدل خیلی بزرگتر
→
AGI ✗
# Bigger models unlock many capabilities, but current limits
# are not defined by model size alone.
پژوهشهای اخیر نشان میدهند پیشرفت بهطور فزایندهای از Post-Training و محاسبه بیشتر هنگام استفاده (مثل زنجیره استدلال طولانیتر) میآید، و برخی مشکلات — مانند اجرای پایدار وظایف طولانی و تعامل قابلاعتماد با دنیای فیزیکی — همچنان چالشبرانگیزند. پس شاید AGI بیشتر شبیه یک سیستم کامل باشد تا یک مدل منفرد.
# نقشه کلی: یک سیستم، نه یک مغز تنها
اگر بخواهیم تصویری مهندسی از یک هوش عمومی بسازیم، احتمالاً با سیستمی مواجه میشویم که چند زیرسیستم اصلی دارد که در یک حلقه به هم متصلاند:
agi_architecture.txt
این نقشه، معماری رسمی AGI نیست — چنین معماری مورد توافقی وجود ندارد. این یک مدل مفهومی است برای اینکه ببینیم اگر بخواهیم یک سیستم عمومی و خودگردان طراحی کنیم، چه اجزایی احتمالاً لازم خواهند بود. حالا برویم سراغ تکتک این اجزا.
# ۱. ادراک؛ AGI باید بتواند دنیا را ببیند
یک هوش عمومی نمیتواند فقط متن دریافت کند. اگر قرار است در محیطهای متنوع کار کند، باید با انواع اطلاعات روبهرو شود: Text، Image، Audio، Video، File، Web، Screen، Sensor و Database. مثلاً وقتی کاربر میگوید «این دستگاه چرا درست کار نمیکند؟»، سیستم ممکن است به عکس دستگاه، صدای آن، کد خطا، دفترچه راهنما و سوابق تعمیر نیاز داشته باشد. مسئله فقط «دیدن» نیست؛ سیستم باید این اطلاعات را به نمایشی قابل استفاده برای مرحله استدلال تبدیل کند:
perception_flow.txt
مدلهای چندوجهی امروز بخش بزرگی از این مسیر را طی کردهاند، اما اینکه چنین قابلیتهایی در تمام محیطها و با پایداری بالا کار کنند، مسئلهای جداست.
همه اطلاعات به یک اندازه مهم نیستند
فرض کنید دوربین یک ربات صحنهای را میبیند که میز، صندلی، فنجان، پنجره، در، شخص، لپتاپ و چراغ دارد — اما هدف ربات فقط «برداشتن لپتاپ از روی میز» است. یک سیستم عمومی باید بتواند از میان حجم عظیم اطلاعات، چیزهای مرتبط با مسئله را پیدا کند:
relevance.txt — goal: pick up the laptop
# Not all information deserves equal attention:
Laptop critical
Table important
Cup minor
Window ignore
این توانایی «فیلتر کردن» از داده بیشتر مهمتر است؛ چون اگر تمام جهان با یک وزن وارد فرایند استدلال شود، هم هزینه محاسبات بالا میرود و هم احتمال گمشدن در اطلاعات اضافی بیشتر میشود.
# ۲. حافظه؛ AGI نباید هر بار از صفر شروع کند
فرض کنید امروز به سیستمی میگوییم «این پروژه با Laravel ساخته شده، دیتابیس ما PostgreSQL است و احراز هویت با OTP انجام میشود» و فردا مجبور باشیم همه را دوباره توضیح دهیم. این بیشتر شبیه یک مدل Stateless است تا یک عامل عمومی. اما حافظه فقط یک Context Window بزرگ نیست؛ میتوان دستکم سه مفهوم متفاوت را در نظر گرفت:
memory_types.txt
# A conceptual model (not a formal AGI architecture):
Working Memory # اطلاعات مسئله فعلی
Current Task: Fix authentication bug
Episodic Memory # رویدادها و تجربهها
Last deployment failed — migration X was missing
Semantic Memory # دانش ساختاری
PostgreSQL → Relational DB → SQL → Transactions
حافظه بدون Retrieval، فقط یک انبار بزرگ است
حالا فرض کنید سیستم طی دو سال میلیونها رویداد ذخیره کرده و کاربر میپرسد: «چرا هفته قبل این API را تغییر دادیم؟» سیستم باید از میان این حجم، بخش مرتبط را پیدا کند:
retrieval_flow.txt
اینجا Memory از یک Storage ساده به یک سیستم بازیابی تجربه و دانش تبدیل میشود — و حتی یک حافظه بسیار بزرگ هم بدون روش مناسب برای پیدا کردن اطلاعات مربوط، کمک زیادی به عامل نمیکند.
# ۳. استدلال و برنامهریزی؛ تفاوت یک پاسخ با یک کار واقعی
داشتن اطلاعات با استفاده از آنها فرق دارد. یک سیستم عمومی باید بتواند از Facts و Rules و Goal و Constraints به یک Conclusion برسد. مثلاً برای یک مسئله نرمافزاری:
reasoning.py
# Facts:
⚠ Database is slow
⚠ Queries are expensive
✗ Index is missing
⚠ Traffic has increased
▶ hypothesis (to be tested, not assumed):
▶ Missing / Inefficient Index ──→ Likely Cause ✓
اما برنامهریزی سختتر از استدلال تکمرحلهای است. فرض کنید به AI بگوییم «یک کسبوکار اینترنتی را در یک بازار جدید راه بینداز که سودآور شود». اینجا دیگر نمیدانیم چه بازاری مناسب است، چه محصولی باید فروخته شود و چه فرضیهای ارزش آزمایش دارد. سیستم باید ابتدا خود مسئله را به چند مسئله کوچکتر تجزیه کند:
decompose.txt
Goal
├── Research Market
├── Find Customer Need
├── Generate Hypotheses
├── Evaluate Opportunities
├── Build Prototype
├── Test With Users
├── Measure Results
└── Iterate ↺
این دیگر Question Answering نیست؛ Problem Solving است. و یک برنامه ثابت هم کافی نیست — سیستم نباید بعد از شکست بگوید «برنامهام را ساختهام، پس ادامه میدهم». یک Planner خوب باید با محیط تعامل داشته باشد:
adaptive_loop.txt
# ۴. ابزارها و وضعیت محیط
هوش بدون دسترسی به جهان محدود است. یک مدل صرفاً زبانی شاید اطلاعات قدیمی داشته باشد، اما یک Agent میتواند با Browser جستوجو کند، با Python محاسبه کند و به Database و Terminal و API دسترسی داشته باشد. به این ترتیب مدل دیگر فقط پاسخ تولید نمیکند — عمل میکند.
Tool Calling بهتنهایی AGI نیست: اینکه مدل بتواند تابع
get_weather() را صدا بزند، خودش هوش عمومی نیست. سؤالهای سختتر اینها هستند: آیا اصلاً به ابزار نیاز دارم؟ کدام ابزار مناسب است؟ نتیجه را چطور تفسیر کنم؟ اگر ابزار خراب شد چه کنم؟ آنچه اهمیت دارد چرخه Goal → Reasoning → Tool Selection → Observation → Reasoning Again است، نه صرفاً خودِ تابع.
درک وضعیت فعلی
فرض کنید یک Agent روی یک کامپیوتر کار میکند و وضعیت محیط این است: Browser باز است، Terminal آماده است، Server خاموش است، Database متصل است و یک File وجود ندارد. حالا یک عمل انجام میدهد (
Start Server) و وضعیت تغییر میکند:
state.txt
State₀
── Action ──→
State₁
── Action ──→
State₂
── Action ──→
State₃
# The system must answer:
# "Where am I now?" and "What happens if I do this?"
بدون چنین State Representation ای، برنامهریزی بلندمدت بسیار دشوار میشود. و یک قدم جلوتر از آن، مفهوم World Model قرار دارد: نمایشی درونی که به سیستم اجازه میدهد درباره پیامد احتمالی عملها فکر کند — «اگر دست را آهسته حرکت بدهم، احتمالاً شیشه را میگیرم؛ اگر محکم هل بدهم، خطر افتادن هست.»
World Model و حافظه کنار هم: Memory به گذشته نگاه میکند («قبلاً چه شد؟»)، World Model به آینده احتمالی («اگر این کار را بکنم چه میشود؟») و Reasoning بین آنها تصمیم میگیرد. اینکه یک AGI دقیقاً به چه نوع World Modelی نیاز دارد هنوز سؤال پژوهشی باز است — اما برای سیستمی که باید در محیط عمل کند، مدلکردن وضعیت و پیامد عملها بسیار منطقی است.
# ۵. یادگیری مداوم و تعمیم
در یک مدل معمولی، آموزش یک مرحله دارد: Data → Training → Model → Deployment. اما یک هوش عمومی فرضی باید در تعامل با جهان هم یاد بگیرد: راهحلی را امتحان کند، شکست را تحلیل کند، یاد بگیرد و دوباره تلاش کند. اما یک مشکل وجود دارد:
Catastrophic Forgetting: اگر مدل مرتباً روی اطلاعات جدید آموزش ببیند، ممکن است برخی تواناییهای قدیمی را از دست بدهد. بنابراین Continual Learning فقط «آموزش دادن دوباره و دوباره» نیست — مسئله حفظ دانش قبلی، افزودن دانش جدید و مدیریت تعارضها هم وجود دارد.
Generalization؛ شاید مهمترین کلمه در AGI
اگر مدل فقط حفظ کرده باشد، مسئله جدید او را غافلگیر میکند. اما اگر بتواند دانش را منتقل کند — مثلاً بفهمد مسیریابی شهری و مسیریابی شبکه هر دو در ذات خود جستوجوی گراف هستند — آنوقت به هوش عمومی نزدیکتر شده است:
transfer.txt
City Routing ↕
Network Routing ↕
Graph Search ← same underlying structure
و حتی باید بتواند چیزهای کاملاً جدید را از محیط یاد بگیرد: فردا یک API جدید منتشر میشود که مدل هرگز با آن آموزش ندیده، اما مستندات وجود دارد — Documentation → Understand → Create Tool Interface → Test → Use. این خیلی متفاوت با آموزشدادن مدل از ابتدا روی Dataset جدید است.
# ۶. Verification؛ سیستم نباید همیشه حرف خودش را باور کند
در مقاله توهم هوش مصنوعی دیدیم که یک مدل زبانی میتواند پاسخ بسیار روان و مطمئن تولید کند و همچنان اشتباه باشد. این مشکل برای یک Agent حتی مهمتر است، چون ممکن است اشتباه از سطح متن به سطح عمل منتقل شود. جمله «Migration موفق شد» بهتنهایی هیچ اثباتی نیست:
verify_flow.txt
و شاید بهاندازه Reasoning مهم باشد که سیستم بتواند بگوید «نمیدانم». یک Agent قابل اعتماد باید میان این حالات تفاوت بگذارد:
epistemic_states.txt
I know. # high confidence, strong evidence
I can infer. # reasonable inference, worth verifying
I need to verify. # stop → search → ask → verify
I don't know. # honest uncertainty beats confident nonsense
# ۷. استقلال بیشتر، ریسک بیشتر
یک سیستم میتواند فقط پاسخ بدهد؛ سیستم دیگری میتواند Analyze → Plan → Use Tools → Execute → Verify → Correct → Finish را خودش انجام دهد. این دو فقط از نظر توانایی فرق ندارند — از نظر Autonomy هم متفاوتاند. اما اگر Agent به Email و Database و Terminal و Cloud و Payment دسترسی داشته باشد، یک خطای کوچک میتواند پیامد بزرگی داشته باشد. پس یک AGI واقعی به لایههای ایمنی نیاز دارد:
permissions.txt
# Layered safety for an acting agent:
Read File → Allowed
Run Test → Allowed
Deploy Staging → Rate-limited
Delete Database → High Risk → Human Approval
# + Sandbox · Audit Log · Rollback · Tool Restrictions
پژوهشهای ایمنی نیز میان سیستمهایی که صرفاً پاسخ میدهند و سیستمهای Agentic که زنجیرهای از اقدامات را در محیط اجرا میکنند، از نظر ریسک و پیامد تفاوت جدی قائل میشوند.
آیا AGI باید بدن داشته باشد؟
اگر AGI را در یک ربات قرار دهیم، مشکلات کاملاً متفاوتی به وجود میآید: Sensor Noise، Latency، اصطکاک، عدمقطعیت و محدودیتهای مکانیکی. این دقیقاً همان مسئلهای است که در مقاله سختتر بودن دست ربات نسبت به مغز آن بررسی کردیم: تصمیمگیری میتواند بسیار سادهتر از تبدیل آن تصمیم به حرکت دقیق و قابلاعتماد در دنیای فیزیکی باشد. بحث Embodied Intelligence یکی از مسیرهای مهم است، اما اینکه داشتن بدن شرط ضروری AGI باشد، هنوز نتیجه علمی قطعی نیست.
# ۸. فهرست کامل اجزا
حالا میتوانیم همه اجزایی که گفتیم را در یک جدول جمع کنیم — همراه با وضعیت امروز هر کدام:
agi_components.txt
# Component │ Status today
# ─────────────────────────────────────────────
Perception / Multimodal │ ✓ exists
Working Memory │ ✓ exists (context window)
Long-Term Memory │ ~ partial (RAG, vector stores)
Reasoning │ ✓ exists (imperfect)
Planning │ ~ partial
World Model │ ~ partial (open research)
Tool Use / Action │ ✓ exists
Continual Learning │ ✗ hard (catastrophic forgetting)
Verification │ ~ partial
Generalization / Transfer │ ~ partial
Safety / Permissions │ ~ active research
اما مهمتر از داشتن این جعبهها، رابطه بین آنهاست. چون AGI قرار نیست این قابلیتها را جداگانه داشته باشد — باید بتواند آنها را در یک حلقه واحد به هم وصل کند. جالب اینجاست که این نگاه، به همان چیزی شبیه میشود که در شبیهسازی شهر دیدیم: شهر را شبیهسازی نمیکنیم؛ جاده، چراغ، خودرو و راننده را مدل میکنیم و بعد رفتار شهر از تعامل آنها ظاهر میشود. شاید AGI هم چنین ماهیتی داشته باشد.
# ۹. یک نمونه کوچک از این ایده
میتوانیم یک Agent بسیار ساده با Python بسازیم که چند مفهوم را نشان دهد: Memory + Planning + Tool + Execution. البته این AGI نیست — فقط یک مدل آموزشی کوچک از معماری است:
mini_agent.py — python3
from dataclasses import dataclass, field
from typing import Callable
@dataclass
class Memory:
facts: list[str] = field(default_factory=list)
def remember(self, fact: str) -> None:
self.facts.append(fact)
def recall(self, keyword: str) -> list[str]:
return [f for f in self.facts if keyword.lower() in f.lower()]
@dataclass
class Tool:
name: str
function: Callable[[str], str]
class Agent:
def __init__(self):
self.memory = Memory()
self.tools: dict[str, Tool] = {}
def plan(self, goal: str) -> list[str]:
# a real planner would reason, not keyword-match
if "calculate" in goal.lower():
return ["calculator"]
return ["reason"]
هشدار امنیتی: در مثال اصلی این الگو برای محاسبه ساده از
eval() استفاده میشود. هرگز eval() را روی ورودی غیرقابلاعتماد اجرا نکنید — حتی با فیلتر کاراکتر، دورزدن آن ممکن است. در کد واقعی از ast.literal_eval یا یک parser ریاضی امن استفاده کنید.
این سیستم کوچک Memory و Planning و Tool و Execution را با هم ترکیب میکند، اما هنوز از AGI فاصله بسیار زیادی دارد — چون خبری از General Reasoning، World Model، Robust Learning، Multimodal Understanding، Long-Horizon Planning و Self-Correction نیست.
# ۱۰. مشکل «هوش ناهموار»
یکی از جالبترین ویژگیهای سیستمهای فعلی این است که ممکن است یک مسئله فوقالعاده سخت را عالی حل کنند اما روی یک مسئله ساده چندمرحلهای شکست بخورند. پژوهشهای اخیر از این وضعیت با عنوان Jagged Intelligence یاد میکنند — پروفایلی بسیار ناهموار از تواناییها:
jagged_profile.txt
مقادیر نمودار صرفاً آموزشیاند: این میلهها شکل کلی «ناهمواری» را نشان میدهند، نه اندازهگیری واقعی سیستم خاصی. نکته مفهومی این است: Very Capable AI ≠ Automatically AGI — قابلیت بالا در چند حوزه، خودبهخود معنای عمومیت نمیدهد.
پس بخشی از اختلاف امروز درباره AGI اصلاً اختلاف درباره توانایی نیست؛ اختلاف درباره تعریف است. با تعریف سخت (یادگیری هر مسئله جدید، سازگاری در محیط ناآشنا، وظایف طولانی مستقل، عملکرد قابلاعتماد در جهان فیزیکی) هنوز فاصله داریم. با تعریف سادهتر (عملکرد بالا در طیف وسیعی از کارهای شناختی) بعضی سیستمهای امروزی بسیار نزدیکترند. دو پژوهشگر میتوانند دقیقاً یک سیستم را ببینند و یکی بگوید AGI و دیگری بگوید نه — چون یکی Performance را معیار میداند، دیگری Generality را و سومی Autonomy را.
# ۱۱. شاید این حلقه، قلب AGI باشد
اگر بخواهیم کل مقاله را در یک چرخه خلاصه کنیم: یک مدل معمولی
Input → Output است؛ یک عامل عمومیتر این حلقه را دارد:
agi_loop.txt
و شاید چیزی که ما آن را «عمومیت» مینامیم، بیشتر در همین حلقه ظاهر شود تا صرفاً در اندازه مدل. مسیر آینده شاید این نباشد که فقط از 7B به 70B به 700B برویم، بلکه: از ساختن مدلهای بزرگتر، به ساختن سیستمهای بهتر — حافظه بهتر، برنامهریزی بهتر، ابزار بهتر، Verification بهتر، یادگیری بهتر.
# ۱۲. جمعبندی؛ شاید AGI یک مغز نباشد، یک سیستم باشد
در شروع مقاله پرسیدیم: اگر بخواهیم AGI بسازیم، چه چیزهایی باید داخل آن قرار دهیم؟ جواب دیگر فقط «یک مدل خیلی بزرگ» نیست. در این تصویر مفهومی: مدل، مغز است؛ Memory، تجربه است؛ Perception، حواس است؛ Tools، دستها هستند؛ Planner مسیر را انتخاب میکند؛ World Model درباره آینده احتمالی فکر میکند؛ Verification جلوی بخشی از اشتباهها را میگیرد و Safety مشخص میکند سیستم تا کجا اجازه دارد عمل کند. (اینها تشبیهاند — ادعای یکسانبودن معماری ذهن انسان و سیستم AI نیست.)
آیا ما همین حالا AGI را ساختهایم؟ پاسخ قطعی نداریم. بسیاری از قطعات واقعیاند و روند توسعه سریع است، اما محدودیتهای مهمی در وظایف طولانی، محیطهای جدید، Hallucination و تعامل فیزیکی باقی است. شاید AGI را یکباره کشف نکنیم؛ شاید یک طیف باشد که بهتدریج در آن جلو میرویم. و شاید سؤال سختتر از «آیا میتوانیم ماشین باهوش بسازیم؟» این باشد: چطور میتوانیم این قطعات را به یک ذهن عمومی تبدیل کنیم؟
takeaway.txt
AGI شاید یک مدل بزرگتر نباشد؛ یک سیستم باشد.
ما امروز بسیاری از قطعات را داریم —
اما داشتن قطعات ≠ داشتن هوش عمومی.
چالش اصلی، ساختن سیستمی است که همه این قابلیتها را
در یک حلقه واحد کنار هم قرار دهد.
ما امروز بسیاری از قطعات را داریم —
اما داشتن قطعات ≠ داشتن هوش عمومی.
چالش اصلی، ساختن سیستمی است که همه این قابلیتها را
در یک حلقه واحد کنار هم قرار دهد.
