🚀 آیندهٔ هوش مصنوعی: چه زمانی باید منتظر اَبَرهوش باشیم؟

پروژهٔ AI Futures مدل به‌روزشده‌ای برای پیش‌بینی زمان ظهور هوش مصنوعیِ قوی ارائه کرده است. مهم‌ترین نتایج و نکات:

📅 جابجایی در زمان‌بندی:
پیش‌بینی میانه برای ظهور برنامه‌نویس خودکار (Automated Coder – AC) — هوش مصنوعی‌ای که بتواند در یک پروژهٔ ساخت AGI به‌طور کامل جایگزین برنامه‌نویسان انسانی شود — اکنون به فوریهٔ ۲۰۳۱ اشاره دارد.
این تاریخ ۳٫۵ تا ۵ سال دیرتر از برآوردهای قبلی است؛ دلیل آن، دقیق‌تر شدن مدل‌های خودکارسازی تحقیق‌وتوسعه (R&D) و در نظر گرفتن کاهش بازدهی نهایی پژوهش‌ها عنوان شده است.

⚡️ سرعت جهش (Takeoff):
پس از رسیدن هوش مصنوعی به سطح انسانی، مسیر تا اَبَرهوش (ASI) می‌تواند از چند ماه تا چندین سال طول بکشد. عامل کلیدی در این مسیر، مفهوم «تکینگی مبتنی بر سلیقه» (taste-only singularity) است؛ وضعیتی که در آن، هوش مصنوعی می‌تواند بهتر از انسان‌ها بهترین مسیرهای آزمایشی و پژوهشی را انتخاب کند.

📊 زمینه و مقایسه:
پیش‌بینی‌ها میان کارشناسان بسیار متفاوت است:
رهبران OpenAI و Anthropic انتظار جهش را در سال‌های ۲۰۲۷–۲۰۲۸ دارند.
تجمیع‌کننده‌های بازارهای پیش‌بینی، حوالی ۲۰۳۰ را محتمل می‌دانند.
نظرسنجی‌های دانشگاهی، افق زمانی دورتری یعنی ۲۰۴۷ را نشان می‌دهند.

🔗 https://blog.ai-futures.org/p/ai-futures-model-dec-2025-update

@asrgooyeshpardaz

🌐 تحولات تازه در دنیای هوش مصنوعی

🤵‍♂ زاکربرگ «Manus» را خرید.
بر اساس گزارش وال‌استریت ژورنال، مبلغ این معامله از ۲ میلیارد دلار فراتر رفته است؛ رقمی که با ارزشی‌گذاری مورد انتظار این استارتاپ در دور جدید جذب سرمایه هم‌خوانی دارد. Manus رشد خیره‌کننده‌ای داشته و تنها ۸ ماه پس از راه‌اندازی به درآمد سالانه‌ای بیش از ۱۰۰ میلیون دلار رسیده است.
محصول پرچم‌دار Manus یک عامل هوش مصنوعی عمومی است که می‌تواند به‌صورت مستقل وظایف چندمرحله‌ای مانند کدنویسی، تحلیل کلان‌داده و تحقیقات بازاریابی را انجام دهد.
شرط کلیدی این خرید، توقف کامل فعالیت‌ها در چین (محل تأسیس اولیه شرکت) و حذف هرگونه منافع چینی از ساختار مالکیت بوده است. سرویس‌ها و اشتراک‌های فعلی Manus بدون تغییر به کار خود ادامه خواهند داد.
🔗 wsj.com

🏭 آمریکا ارسال تجهیزات به سامسونگ و SK Hynix را برای سال ۲۰۲۶ تأیید کرد.
دولت ایالات متحده مجوزهایی به Samsung Electronics و SK Hynix اعطا کرده که به آن‌ها اجازه می‌دهد در سال ۲۰۲۶ تجهیزات تولید تراشه را به کارخانه‌های خود در چین وارد کنند. این تصمیم تداوم فرآیندهای فناوری را در شرایط سخت‌گیرانه‌تر شدن کنترل‌های صادراتی تضمین می‌کند.
پیش‌تر، این شرکت‌های کره‌جنوبی — همانند TSMC — از وضعیت «شرکت‌های مورد اعتماد» برخوردار بودند که آن‌ها را از محدودیت‌های واشنگتن معاف می‌کرد. اعتبار این امتیاز در ۳۱ دسامبر به پایان می‌رسد و پس از آن، نظام صدور مجوز سالانه اعمال خواهد شد.
برای سامسونگ و SK Hynix، سایت‌های چینی همچنان نقش کلیدی در تولید حافظه دارند؛ بازاری که به‌دلیل کمبود عرضه و تقاضای بالای دیتاسنترهای هوش مصنوعی، با افزایش قیمت مواجه است.
🔗 reuters.com

⚡ شرکت FAL AI مدل FLUX.2 Dev Turbo را معرفی کرد.
مدل FLUX.2 [dev] Turbo نسخه‌ای بهینه‌شده از مدل Black Forest Labs در قالب LoRA است که تعداد گام‌های اینفرنس را به ۸ مرحله کاهش می‌دهد. FAL وعده داده سرعتی ۶ برابر بیشتر نسبت به نسخه استاندارد ۵۰مرحله‌ای ارائه دهد، بدون افت محسوس در جزئیات تصویر و دقت تبعیت از پرامپت.
این ابزار بلافاصله پس از انتشار، در رتبه‌بندی Artificial Analysis Image Arena صدرنشین شد و حتی از نظر امتیاز ELO از مدل‌های تجاریِ بزرگ و بسته نیز پیشی گرفت. وزن‌های مدل تحت مجوز غیرتجاری Black Forest در Hugging Face در دسترس هستند.
🔗 huggingface.co
🔗 x.com/fal

🚀 تنسنت یک مدل زبانی دیفیوژنی منتشر کرد که ۶ برابر سریع‌تر از LLMهای کلاسیک است.
مدل WeDLM 8B Instruct به‌جای روش خودرگرسیو متداول، از رویکرد دیفیوژن برای تولید متن استفاده می‌کند. مزیت اصلی این معماری، افزایش چشمگیر کارایی است؛ به‌طوری که در وظایف استدلال ریاضی، WeDLM نسبت به Qwen3-8B (با بهینه‌سازی vLLM) ۳ تا ۶ برابر سریع‌تر عمل می‌کند.
این انتشار، کلیشهٔ نامناسب‌بودن مدل‌های دیفیوژنی برای وظایف دقیق متنی را به چالش می‌کشد و نشان می‌دهد که آن‌ها می‌توانند از ترنسفورمرها در سرعت اینفرنس پیشی بگیرند.
مدل با مجوز بسیار آزاد Apache 2.0 در Hugging Face منتشر شده است.
🔗 huggingface.co
🔗 wedlm.github.io

📺 الگوریتم‌های یوتیوب برای کاربران جدید «AI-Slop» پیشنهاد می‌دهند.
شرکت Kapwing با تحلیل پیشنهادهای یوتیوب برای حساب‌های تازه‌ساخته، به این نتیجه رسید که ۲۱٪ از توصیه‌ها مربوط به محتوای کم‌کیفیتی است که صرفاً با هوش مصنوعی برای افزایش مصنوعی بازدید تولید شده‌اند. این محتوا جریانی خودکار از ویدئوهای بی‌ارزش است که سیستم‌های توصیه‌گر پلتفرم آن‌ها را به‌طور فعال به صدر نتایج می‌آورند.
اقتصاد این بخش پررونق است: بازیگران اصلی میلیاردها بازدید جذب می‌کنند و میلیون‌ها دلار از تبلیغات درآمد دارند. مخاطبان اصلی این نوع محتوا کاربران کرهٔ جنوبی، پاکستان و آمریکا هستند.
این وضعیت به‌روشنی مشکل «اینترنت مرده» را نشان می‌دهد: تا زمانی که چنین ویدئوهایی — چه توسط انسان‌ها و چه ربات‌ها — تعامل بالا ایجاد کنند، پلتفرم به توصیهٔ آن‌ها ادامه می‌دهد و انگیزهٔ مالی برای آلوده‌تر شدن فضا شکل می‌گیرد.
🔗 kapwing.com

#news #ai

@asrgooyeshpardaz

🧩 راهنمای کاربردی ساخت MCP Server در یک دقیقه (همراه با دستورات و کد)

پروتکل MCP (Model Context Protocol) یک استاندارد باز برای اتصال تمیز و پایدار مدل‌های زبانی (LLM) به ابزارهای خارجی است. هدف MCP حذف کدنویسی‌های سفارشی، پارس‌های شکننده و منطق‌های پیچیده‌ی مسیریابی ابزارهاست. در این پست، به‌صورت گام‌به‌گام و عملی یک MCP Server ساده را پیاده‌سازی می‌کنیم.

🧱 مفاهیم پایه MCP
پروتکل MCP فقط از سه جزء تشکیل شده است:
1️⃣ Server:
سرویسی که ابزارها (Tools) را در اختیار LLM قرار می‌دهد
2️⃣ Tool:
یک تابع معمولی (مثلاً API، دیتابیس، محاسبه، زمان، هواشناسی)
3️⃣ Client:
کلاینتی که ابزارها را کشف و فراخوانی می‌کند (در عمل، فریم‌ورک LLM)

⚙️ گام اول: نصب FastMCP
کتابخانه FastMCP فریم‌ورک پایتونی ساده برای پیاده‌سازی MCP است.

pip install fastmcp

🖥 گام دوم: ساخت MCP Server
یک فایل با نام my_server.py ایجاد کنید:

from fastmcp import FastMCP

# ایجاد سرور MCP
mcp = FastMCP("my-first-server")

# تعریف یک ابزار
@mcp.tool
def get_weather(city: str) -> dict:
    """دریافت وضعیت آب‌وهوا برای یک شهر"""
    data = {
        "tehran": {"temp": 25, "condition": "sunny"},
        "london": {"temp": 18, "condition": "cloudy"},
        "tokyo": {"temp": 22, "condition": "rainy"},
    }

    city_lower = city.lower()
    return {"city": city, **data.get(city_lower, {"temp": 20, "condition": "unknown"})}

if __name__ == "__main__":
    mcp.run(transport="stdio")
 

🔹 نکات مهم:
🔸دکوراتور @mcp.tool هر تابع را به یک ابزار قابل‌استفاده برای LLM تبدیل می‌کند
🔸و Docstring توضیح ابزار است و توسط مدل برای تصمیم‌گیری استفاده می‌شود
🔸همچنین Type Hintها ورودی و خروجی ابزار را مشخص می‌کنند
🔸و stdio برای تست محلی بهترین گزینه است

🧪 گام سوم: ساخت Client برای تست
فایل test_client.py را ایجاد کنید:

import asyncio
from fastmcp import Client

async def main():
    client = Client("my_server.py")

    async with client:
        tools = await client.list_tools()
        print("Available tools:")
        for tool in tools:
            print(f"- {tool.name}: {tool.denoscription}")

        result = await client.call_tool(
            "get_weather",
            {"city": "Tokyo"}
        )
        print("Result:", result)

if __name__ == "__main__":
    asyncio.run(main())

▶️ گام چهارم: اجرای برنامه
در ترمینال اجرا کنید:

python test_client.py

خروجی نمونه:

Available tools:
- get_weather: دریافت وضعیت آب‌وهوا برای یک شهر

Result: {'city': 'Tokyo', 'temp': 22, 'condition': 'rainy'}
 

➕ گام پنجم: افزودن ابزارهای جدید
افزودن ابزار جدید فقط به معنی اضافه‌کردن یک تابع است:

from datetime import datetime

@mcp.tool
def get_time(timezone: str = "UTC") -> str:
    """دریافت زمان فعلی"""
    return f"Current time ({timezone}): {datetime.now().strftime('%H:%M:%S')}"

@mcp.tool
def calculate(expression: str) -> dict:
    """محاسبه‌ی امن عبارات ریاضی"""
    allowed = set("0123456789+-*/.() ")
    if not all(c in allowed for c in expression):
        return {"error": "Invalid characters"}

    return {"expression": expression, "result": eval(expression)}
 

🔹 بدون تغییر Client، ابزارها خودکار کشف می‌شوند.
🌐 استفاده در محیط عملیاتی (Production)
برای اجرا به صورت سرویس http:

if __name__ == "__main__":
    mcp.run(
        transport="http",
        host="0.0.0.0",
        port=8000
    )
 

در این حالت، هر کلاینت سازگار با MCP (از جمله فریم‌ورک‌های LLM) می‌تواند به سرور متصل شود.

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

🔗 منبع اصلی:
https://medium.com/data-science-collective/build-your-first-mcp-server-in-15-minutes-complete-code-d63f85c0ce79

@asrgooyeshpardaz

🇰🇷 مدل Solar-100B شرکت Upstage با تأمین مالی دولت کره‌جنوبی در واقع GLM-4.5 از آب درآمد

شرکت Upstage با حمایت دولت کره‌جنوبی، مدل Solar-Open-100B را به‌عنوان مدلی «ساخته‌شده از صفر» و در راستای هوش مصنوعی حاکمیتی منتشر کرد.
اما بررسی‌های فنی نشان می‌دهد که این ادعا محل تردید جدی است:

🔍 نکات کلیدی:
📊 شباهت کسینوسی وزن‌ها با GLM-4.5 برابر با 0.989 است؛ این میزان شباهت نشان‌دهنده اقتباس مستقیم است، نه آموزش مستقل.
🏗 معماری کاملاً یکسان است (۱۲۸ اکسپرت، مسیریابی top-8).
🖥 در کد، آرتیفکت‌های منحصربه‌فرد GLM شناسایی شده‌اند (از جمله ثابت «92» برای لایه MTP).
🚀 الگوهای عملکرد و توکن‌سازی با مدل GLM-4.5-Air تطابق دارد.

جمع‌بندی:
به‌احتمال زیاد، این مدل نسخه‌ای سازگار‌سازی‌شده از مدل چینی GLM-4.5 است. این موضوع پرسش‌های جدی درباره شفافیت پروژه و نحوه استفاده از منابع مالی دولتی ایجاد می‌کند. 🤔⚖️

🔗 منبع:
https://github.com/sionic-ai/solar-vs-glm

@asrgooyeshpardaz

🎧🌍 آیا SpeechLLMها واقعاً ترجمه گفتار را متحول کرده‌اند؟

📄 مقاله‌ای جدید با عنوان Hearing to Translate به‌طور نظام‌مند بررسی می‌کند که آیا ادغام «گفتار به‌عنوان مدالیته بومی» در LLMها (یعنی SpeechLLMها) می‌تواند عملکرد ترجمه گفتار را نسبت به معماری‌های کلاسیک زنجیره‌ای (Cascaded) بهبود دهد یا نه.

🔬 روش مطالعه:
این کار اولین بنچمارک جامع در این حوزه است که:
🧠 تعداد ۵ SpeechLLM پیشرفته
🔗 ۱۶ سیستم قوی مستقیم و زنجیره‌ای (ترکیب مدل‌های پایه گفتار + LLMهای چندزبانه)
را با هم مقایسه می‌کند.

📊 ارزیابی در مقیاسی گسترده انجام شده است:
۱۶ بنچمارک معتبر
۱۳ جفت‌زبانی
۹ سناریوی چالش‌برانگیز (گفتار نویزی، ناپیوسته، طولانی و …)

🔎 یافته‌های کلیدی:

✅ سیستم‌های Cascaded همچنان قابل‌اعتمادترین گزینه در مجموع هستند.

⚠️ مدل‌های SpeechLLMهای فعلی فقط در برخی شرایط خاص می‌توانند به عملکرد سیستم‌های زنجیره‌ای برسند، اما برتری کلی ندارند.

📉 مدل‌های پایه گفتار (SFMها) به‌تنهایی از هر دو رویکرد عقب‌ترند.

🧩 نتیجه مهم: حضور LLM—چه درون مدل و چه به‌صورت پایپلاین—برای دستیابی به ترجمه گفتار باکیفیت ضروری است.

🧠 جمع‌بندی تحلیلی:
با وجود جذابیت ایده «ترجمه مستقیم گفتار با LLM»، معماری‌های کلاسیک زنجیره‌ای (ASR → LLM → MT) هنوز از نظر پایداری و کیفیت، دست بالا را دارند. به نظر می‌رسد مسیر آینده نه حذف پایپلاین‌ها، بلکه ادغام هوشمند LLMها در آن‌ها باشد.

🔗 لینک مقاله (arXiv):
https://arxiv.org/abs/2512.16378

#SpeechLLM #SpeechTranslation #CascadedSystems #LLM #ASR #AIResearch

@asrgooyeshpardaz

📌 تحلیل ترندهای Backend در سال گذشته (2025)

در این گزارش به ۱۰ استک برتر که توسعه‌دهندگان بیش از همه از آن‌ها استفاده می‌کنند می‌پردازیم و دلیل محبوبیت‌شان را بررسی می‌کنیم.

🔥 1. Node.js + Express + TypeScript + MongoDB🍃
📌 محبوب‌ترین انتخاب عمومی
اجرای سریع روی موتور V8
ایمنی نوعی با TypeScript
اکوسیستم عظیم NPM
مناسب برای APIهای مقیاس‌پذیر و Real-Time
🔍 گزینه رایج برای استارتاپ‌ها و SaaSهاست.

🐍 2. Python + FastAPI + PostgreSQL
📌 پرفورمنس بالا برای Python
پشتیبانی OpenAPI خودکار
پشتیبانی کامل از async
اکوسیستم قوی در حوزه AI/ML
🔍 مناسب برای سرویس‌های API با داده‌های زیاد.

🚀 3. Go + Gin + GORM + MySQL
📌 قدرت اجرا و سرعت
مصرف حافظه کم
هم‌زمانی ذاتی با goroutine
کامپایل به یک باینری ساده
🔍 برای سیستم‌هایی با نیاز به مقیاس‌پذیری بالا عالی است.

☕ 4. Java + Spring Boot + Hibernate + PostgreSQL
📌 استاندارد سازمانی
اکوسیستم ابزار فراوان
پشتیبانی حرفه‌ای در شرکت‌های بزرگ
تست‌پذیری و مقیاس‌پذیری بالا
🔍 انتخاب غالب در پروژه‌های Enterprise.

🦀 5. Rust + Actix-web + Diesel + PostgreSQL
📌 سرعت و ایمنی حافظه
بدون Garbage Collector
اجرای بسیار سریع API
🔍 مناسب پروژه‌های Performance-Critical مثل فین‌تک.

💎 6. Ruby + Rails + PostgreSQL
📌 توسعه سریع
Convention over configuration
مناسب MVPها و استارتاپ‌های کوچک
🔍 هنوز در پروژه‌های زیادی مثل سیستم‌های Internal استفاده می‌شود.

🐘 7. PHP + Laravel + MySQL
📌 همراه با PHP مدرن
چارچوب Laravel با ORM ساده و ابزارهای آماده
ساخت سریع API و سایت
🔍 انتخاب هواداران PHP برای پروژه‌های Medium.

⚡ 8. Elixir + Phoenix + PostgreSQL
📌 برای Real-Time و Concurrency
ساخته‌شده روی ماشین Erlang
LiveView برای UI بدون JS
🔍 بسیار مناسب اپ‌هایی با بار Real-Time.

☕ 9. Kotlin + Ktor + Exposed ORM + PostgreSQL
📌 کاتلین (Kotlin) جدی‌تر از Android
سینتکس مختصر
و Coroutines برای async
🔍 در حال رشد و محبوب برای Backendهای مدرن.

🧰 10. .NET Core (C#) + Entity Framework + SQL Server
📌 کراس‌پلتفرم، Enterprise
عملکرد بالا
ادغام قوی با Azure
🔍 انتخاب سازمان‌هایی با اکوسیستم Microsoft.

📈 جمع‌بندی نگاه تحلیلی
✅ تنوع انتخاب‌ها: از JavaScript/TypeScript تا Rust و Elixir — انتخاب استک واقعا گسترده است و باید بر اساس نیاز پروژه باشد.
✅ پایگاه داده غالب: PostgreSQL در اغلب استک‌ها دیده می‌شود — نشانه بلوغ این دیتابیس در ۲۰۲۵.
✅ ترندهای فرعی: زبان‌های مدرن مثل Rust و Kotlin رشد چشمگیری داشته‌اند، در حالی که گزینه‌های کلاسیک مثل Spring Boot و .NET همچنان قدرتمند باقی مانده‌اند.

📌 پیشنهاد برای توسعه‌دهندگان و تیم‌ها
اگر تازه‌کار هستی: Node.js + TypeScript یا Python + FastAPI عالی‌اند.
اگر دنبال پروژه‌های Enterprise هستی: Spring Boot یا .NET انتخاب بهتری‌ست.
اگر پرفورمنس و امنیت برات مهمه: Rust و Go ارزش امتحان دارند.

🔮 پیش‌بینی برای سال ۲۰۲۶:
تمرکز بک‌اند بیش‌ازپیش به سمت Backendهای AI-Native، معماری‌های Agent-محور، استفاده گسترده‌تر از TypeScript و Python در کنار Rust برای هسته‌های پرفورمنس‌حساس، و ادغام عمیق LLMها با APIها و دیتابیس‌ها حرکت خواهد کرد.

🔗منبع مورد استفاده

@asrgooyeshpardaz

سال نو مبارک! ✨
فرا رسیدن سال نو میلادی ۲۰۲۶ را به همراهان گرامی و خانواده بزرگ عصر گویش پرداز تبریک می‌گوییم.
امیدواریم این سال برای همه ما، سالی سرشار از پویایی، روشنایی و پیوندهای عمیق‌تر انسانی باشد.
به امید فردایی روشن‌تر برای ایران و جهان. 🏔️🕊️

#عصر_گویش_پرداز #سال_نو_مبارک #هوش_مصنوعی

@asrgooyeshpardaz

🐳 دیپ‌سیک (DeepSeek) سال جدید را با یک مقاله جدی و مهم آغاز کرد.

در نخستین روز سال، این تیم پژوهشی کاری را ارائه داد که به یکی از دردناک‌ترین مشکلات شبکه‌های عصبی مدرن می‌پردازد: ناپایداری آموزش در معماری‌های پیچیده.
آن‌ها برای این مشکل راه‌حلی پیشنهاد کرده‌اند با نام mHC (Manifold-Constrained Hyper-Connections).
ایده‌ی اصلی این است که پژوهشگران معماری قدرتمند اما ناپایدار Hyper-Connections را گرفته‌اند و با اعمال محدودیت‌هایی بر اتصالات داخلی، آن را پایدار کرده‌اند.

1. پروژکشن روی منیفلد (Manifold Projection)
به‌جای آن‌که Hyper-Connections کاملاً آزاد باشند، در mHC روی آن‌ها قید اعمال می‌شود و این اتصالات روی یک منیفلد خاص (ماتریس‌هایی با خواص ویژه) پروجکت می‌شوند.
این کار باعث بازگردانی ویژگی identity-mapping می‌شود؛ در نتیجه سیگنال حتی پس از عبور از ده‌ها یا صدها لایه نیز پایدار باقی می‌ماند.

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

3. بهینه‌سازی‌های زیرساختی (مهندسی)
نویسندگان مقاله مجموعه‌ای از بهبودهای مهندسی را نیز اضافه کرده‌اند، از جمله:
ادغام کرنل‌ها (Kernel Fusion)
کاهش سربار مصرف حافظه
بهره‌گیری از اثرات دقت ترکیبی (Mixed Precision)
این بهینه‌سازی‌ها باعث می‌شود mHC حتی در آموزش‌های بسیار بزرگ، سریع و کارآمد در سناریوهای واقعی باشد.

🔍 نتایج به‌دست‌آمده چشمگیر است:
• آموزش در مقیاس‌های بزرگ پایدارتر می‌شود
• مدل‌ها بهتر مقیاس‌پذیر می‌شوند
• کارایی افزایش می‌یابد
• مصرف حافظه کاهش پیدا می‌کند
• و mHC از Hyper-Connections کلاسیک پیشی می‌گیرد
به بیان ساده‌تر، DeepSeek نشان می‌دهد که مسیر آینده فقط از بزرگ‌تر کردن مدل‌ها نمی‌گذرد، بلکه از معماری‌هایی می‌گذرد که از درون پایدار طراحی شده‌اند.

#AI #DeepSeek #MachineLearning #NeuralNetworks #Research

📄 مقاله:
https://arxiv.org/abs/2512.24880

@asrgooyeshpardaz

Happy New Year 2026 🎊
Nano Banana Pro 👌

@asrgooyeshpardaz

📌 مصاحبه با یک کارمند ۲۳ سالهٔ OpenAI که یادگیری عمیق (DL) را بدون تحصیل دانشگاهی آموخته است

داستانی جالب که آدم را به فکر فرو می‌برد؛ هم دربارهٔ آموزش و هم مسیر شغلی.
آشنا شوید با گابریئل پترسون. او فقط ۲۳ سال دارد، مدرسه را در یک شهر کوچک و دورافتاده در سوئد رها کرده، هرگز وارد دانشگاه نشده، اما همین حالا به‌عنوان پژوهشگر در OpenAI و در تیم Sora کار می‌کند.

🟡 ما در دوره‌ای زندگی می‌کنیم که انحصار دانشگاه‌ها بر دانش بنیادین متزلزل شده است.
آموزش سنتی معمولاً مسیری «از پایین به بالا» دارد. اگر بخواهی وارد یادگیری ماشین شوی، اول باید جبر خطی بخوانی، بعد آنالیز ریاضی، بعد آمار و احتمال. این مسیر طولانی است و اغلب باعث از دست رفتن انگیزه می‌شود، چون معلوم نیست این همه درس دقیقاً الآن به چه دردی می‌خورد.
از طرف دیگر، شرکت‌ها هم همیشه حاضر نیستند صبر کنند. برای مثال، Palantir حتی بدون عبور از دانشگاه‌ها، دانش‌آموزان دبیرستانی را استخدام می‌کند. داستان گابریئل نمونهٔ روشنی از همین روند است.
او مسیر کلاسیک «مدرسه ← کارشناسی ← کارشناسی ارشد» را طی نکرد. در عوض، از ChatGPT به‌عنوان یک منتور شخصی استفاده کرد. البته نه به این معنا که از چت‌بات بخواهد «به‌جای من کد بنویس». گابریئل از روشی استفاده می‌کند که خودش آن را «پر کردن بازگشتیِ شکاف‌های دانشی» می‌نامد.
ایدهٔ اصلی این روش، حرکت «از بالا به پایین» است. او یک پروژهٔ پیچیده را انتخاب می‌کند؛ مثلاً می‌خواهد بفهمد مدل‌های دیفیوژن چگونه کار می‌کنند. از ChatGPT می‌خواهد کد مربوطه را بنویسد. طبیعی است که در ابتدا تقریباً هیچ‌چیز را متوجه نمی‌شود.
در همین‌جا مرحلهٔ اصلی شروع می‌شود: او دربارهٔ تک‌تک بخش‌های نامفهوم سؤال می‌پرسد.
«این بلاک چه کاری انجام می‌دهد؟»
فرض کنید آن بلاک، ResNet است. می‌پرسد: «چرا این ساختار به یادگیری مدل کمک می‌کند؟» و باز هم عمیق‌تر می‌شود. اگر به مفهوم ناآشنایی برسد، از ChatGPT می‌خواهد مبانی ریاضی پشت آن مفهوم را توضیح دهد.
این همان «بازگشت» است: لایه به لایه، تا زمانی که همهٔ شکاف‌های دانشی پر شوند. او ریاضی را برای آیندهٔ نامعلوم نمی‌خواند؛ بلکه دقیقاً همان ریاضی‌ای را یاد می‌گیرد که همین الآن برای فهم و کار کردن کد لازم دارد.

🟡 اما یک فرد خارجیِ بدون مدرک دانشگاهی چطور ویزای آمریکا گرفت و در سیلیکون‌ولی استخدام شد؟
برای دریافت ویزای استعدادهای ویژه (O-1)، او از اعتبارش در Stack Overflow و توصیه‌ها و پاسخ‌هایی که میلیون‌ها بار دیده شده بودند، به‌عنوان مدرکی برای نشان دادن اثرگذاری‌اش در صنعت استفاده کرد.
توصیهٔ گابریئل صریح است: HR را فراموش کنید. رزومه و مدرک اهمیت چندانی ندارند، اگر بتوانید نتیجهٔ واقعی نشان دهید. استراتژی او این است: یک MVP یا دموی محصول بسازید و مستقیم به مدیران ارشد شرکت ایمیل بزنید و پیشنهاد بدهید که یک هفته رایگان برایشان کار کنید. این کار ریسک استخدام را برای کارفرما کم می‌کند و به شما فرصت می‌دهد خودتان را ثابت کنید.
پیام اصلی او این است:
اگر آماده‌اید فعالانه سؤال بپرسید و از این‌که هنگام یادگیری مفاهیم پایه جلوی یک هوش مصنوعی «احمق به نظر برسید» نترسید، شما همین حالا جزو ۱٪ برتر هستید؛ چون بیشتر مردم فقط با جریان حرکت می‌کنند و هیچ‌وقت عمیق نمی‌شوند.
🔜 مشاهدهٔ مصاحبهٔ کامل

#AI #ML #Interview #OpenAI

info@asr-gooyesh.com

🌱➡️🌳 دیالکتیک برای هوش مصنوعی: ماشین چگونه مفاهیم را کشف می‌کند

شرکت Adobe یک نگاه الگوریتمی به «مفهوم» ارائه می‌دهد — نه به‌عنوان یک برچسب ساده، بلکه به‌عنوان یک شیء اطلاعاتی که از طریق برگشت‌پذیری (determination) با تجربه پیوند خورده است 🔄📌

📌 ایدهٔ اصلی: مفاهیم برای توضیح دادن تجربه‌های جدید با یکدیگر رقابت می‌کنند و تلاش می‌کنند توصیف آن را فشرده‌تر کنند (یعنی افزونگی اطلاعات را به حداقل برسانند) 📉

برنده، مفهومی است که کوتاه‌ترین و فشرده‌ترین توصیف را ارائه دهد ⚔️

📌 به این ترتیب تکامل مفاهیم شکل می‌گیرد:
ادغام، تفکیک، و بازتعریف مرزها — درست همان‌طور که در ذهن انسان رخ می‌دهد
(مثال: «ستارهٔ صبحگاهی / ستارهٔ شامگاهی» 👈 «زهره») 🌟

📌 ارتباط میان عامل‌ها (Agents) به حداقل تعداد بیت نیاز دارد:
یک «لنگر» یا بذر کوچک (seed) می‌تواند امکان بازسازی یک مفهوم کامل را فراهم کند 🧩

🤖📚 این رویکرد، پایه‌ای برای هوش مصنوعی‌ای است که بدون دخالت انسان، صرفاً با تکیه بر فشرده‌سازی داده‌ها، مفاهیم را کشف کرده و به‌تدریج دقیق‌تر می‌کند.

🔗 https://arxiv.org/abs/2512.17373

#AI #Adobe #پژوهش‌ها

@asrgooyeshpardaz

📌 چگونه غول‌های هوش مصنوعی انرژی موردنیاز خود را تأمین می‌کنند

خبرنامه Semianalysis مطلب جالبی منتشر کرده‌ و به این می‌پردازد که شرکت‌های فعال در حوزه هوش مصنوعی چگونه در حال عبور از بحران انرژی هستند.

🟡 شبکه برق آمریکا تاب فشار هوش مصنوعی را ندارد.
دو سال پیش کارشناسان پیش‌بینی می‌کردند که تقاضای توان برای دیتاسنترهای هوش مصنوعی از ۳ گیگاوات در سال ۲۰۲۳ به ۲۸ گیگاوات تا سال ۲۰۲۶ برسد.
هم‌اکنون در تگزاس هر ماه درخواست‌هایی به میزان ده‌ها گیگاوات ثبت می‌شود، اما در طول یک سال معمولاً کمتر از یک گیگاوات آن‌ها تأیید می‌شود. شبکه‌های برق به‌شدت تحت فشار هستند.
شرکت‌های هوش مصنوعی نمی‌توانند سال‌ها در صف اتصال به شبکه بمانند. حتی تأخیر شش‌ماهه برای یک دیتاسنتر ۴۰۰ مگاواتی می‌تواند به معنای از دست رفتن میلیاردها دلار باشد. به همین دلیل آن‌ها مسیر تطبیق را انتخاب کرده‌اند:
ساخت نیروگاه‌های گازی اختصاصی، مستقیماً در محل دیتاسنترها.
اولین شرکتی که صنعت را شگفت‌زده کرد، xAI بود؛ این شرکت تنها در ۴ ماه خوشه‌ای با ۱۰۰ هزار GPU راه‌اندازی کرد که کاملاً با توربین‌های گازی سیار و مستقل از شبکه سراسری تغذیه می‌شد. تا پایان سال ۲۰۲۵، پروژه ایلان ماسک در مجموع بیش از ۵۰۰ مگاوات ظرفیت از این نوع را مستقر کرده است. پس از آن OpenAI به همراه Oracle در تگزاس و همچنین مارک زاکربرگ در اوهایو همین مسیر را در پیش گرفتند.

🟡 این رویکرد نام مشخصی پیدا کرده است: BYOG (Bring Your Own Generation)
یعنی «تولید برق اختصاصی». این مفهوم سه نوع اصلی تولید را در بر می‌گیرد:

🟢 توربین‌های آئرو‌دریواتیو GE Vernova شامل LM2500 با توان ۳۴ مگاوات و LM6000 با توان ۵۷ مگاوات؛
گران‌ترین گزینه، اما با راه‌اندازی بسیار سریع (۵ تا ۱۰ دقیقه از استارت تا رسیدن به توان کامل).

🟢 توربین‌های گازی صنعتی مانند Siemens SGT-800 و Solar Titan، به‌همراه موتورهای پیستونی سازگارشده برای تولید برق مانند Jenbacher J624 با توان ۴٫۵ مگاوات و Wärtsilä با توان ۷ تا ۲۰ مگاوات؛
ارزان‌تر، اما با زمان راه‌اندازی طولانی‌تر.

🟢 پیل‌های سوختی اکسید جامد (SOFC) از شرکت Bloom Energy که نیازی به اخذ مجوز از سازمان حفاظت محیط‌زیست آمریکا ندارند.

🟡 چالش اصلی BYOG: قابلیت اطمینان.
برای رسیدن به آپ‌تایم ۹۹٪ مشابه شبکه سراسری، باید بیش‌ازحد احتیاط کرد.
مثلاً برای یک دیتاسنتر ۲۰۰ مگاواتی، ۲۶ موتور ۱۱ مگاواتی یا ۹ توربین ۳۰ مگاواتی نصب می‌شود.
در نمونه‌ای دیگر، دیتاسنتری در اوهایو از یک راهکار هیبریدی استفاده می‌کند: ۳ نوع توربین مختلف به‌علاوه ۱۵ موتور پیستونی، برای پوشش حداکثری شرایط بحرانی.

🟡 محرک اصلی بحران: اقتصاد.
هزینه تولید برق اختصاصی معمولاً از برق شبکه بالاتر است، اما برای کسب‌وکارهای هوش مصنوعی، سرعت راه‌اندازی از هر چیز مهم‌تر است.
هر یک گیگاوات توان محاسباتی هوش مصنوعی سالانه بین ۱۰ تا ۱۲ میلیارد دلار درآمد ایجاد می‌کند.
بنابراین راه‌اندازی سریع دیتاسنتر، هر هزینه‌ای را برای استقلال انرژی توجیه می‌کند.
تولیدکنندگان راهکارهای BYOG نیز با کمبود ظرفیت مواجه شده‌اند؛ GE Vernova و Siemens Energy هم‌اکنون سفارش‌ها را فقط برای سال‌های ۲۰۲۸ تا ۲۰۲۹ می‌پذیرند.

🟡 افزایش تقاضا باعث ورود بازیگران جدید شده است.
شرکت Boom Supersonic (سازنده هواپیماهای مافوق‌صوت) از دانش فنی هوانوردی خود برای توسعه توربین‌هایی مبتنی بر موتورهای هواپیماهای Mach 2 استفاده می‌کند.
شرکت کره‌ای Doosan Enerbility نیز با تکیه بر تجربه تولید توربین‌های بخار، تولید توربین‌های کلاس H را آغاز کرده است.
در افق آینده، غول‌های هوش مصنوعی بیشتر به سمت راهکارهای هیبریدی می‌روند؛ جایی که تولید برق اختصاصی ابتدا دیتاسنتر را وارد مدار می‌کند و پس از اتصال به شبکه، نقش منبع پشتیبان را بر عهده می‌گیرد. این روند بدون شک بر چندین صنعت و حوزه مجاور دیگر نیز تأثیر خواهد گذاشت.
در نتیجه، بحران «انرژی» و بحران «تراشه» آخرین پیامدهای رقابت هوش مصنوعی نخواهند بود.

🔗منبع:
https://newsletter.semianalysis.com/p/how-ai-labs-are-solving-the-power

#news #ai

@asrgooyeshpardaz

📌 پروژه Semantica؛ چارچوبی متن‌باز برای ساخت لایه‌ی معنایی و گراف دانش در سیستم‌های هوش مصنوعی

پروژه‌ی Semantica که توسط تیم Hawksight AI توسعه داده شده است، یک فریم‌ورک پیشرفته برای استخراج معنا، ساخت آنتولوژی و تولید گراف دانش از داده‌های ناهمگون و بی‌ساختار محسوب می‌شود؛ مسئله‌ای کلیدی که بسیاری از سیستم‌های RAG و Agentهای هوشمند امروز با آن دست‌وپنجه نرم می‌کنند.

🔍 مسئله‌ای که Semantica حل می‌کند

اکثر پیاده‌سازی‌های رایج RAG صرفاً به بازیابی مبتنی بر embedding متکی هستند و فاقد درک صریح از:
🔸موجودیت‌ها (Entities)
🔸روابط معنایی (Semantic Relations)
🔸ساختار دانش (Knowledge Structure)
هستند.
ابزار Semantica با افزودن یک لایه‌ی معنایی صریح (Explicit Semantic Layer) این خلأ را پوشش می‌دهد.

👌 قابلیت‌های کلیدی Semantica

🔸استخراج خودکار موجودیت‌ها و روابط (NER & Relation Extraction)
🔸ساخت و تکامل آنتولوژی به‌صورت پویا
🔸تولید Knowledge Graph قابل پرس‌وجو
🔸ترکیب گراف دانش با بردارهای embedding
🔸پشتیبانی از GraphRAG و Reasoning چندمرحله‌ای
🔸کاهش هالوسینیشن و افزایش قابلیت توضیح‌پذیری (Explainability)

🏗 معماری مفهومی

1️⃣ ورودی داده: اسناد متنی، PDF، دیتابیس، API و منابع ترکیبی
2️⃣ لایه‌ی معنایی: تحلیل زبانی، نگاشت مفاهیم، استنتاج روابط
3️⃣ خروجی:
گراف دانش
آنتولوژی
نمایش‌های برداری قابل استفاده در LLMها و Agentها

🎯 کاربردهای اصلی

🔸طراحی سیستم‌های RAG سازمانی با دقت بالا
🔸ایجاد حافظه‌ی بلندمدت و ساخت‌یافته برای Agentهای هوشمند
🔸یکپارچه‌سازی سیلوهای داده‌ای در سازمان‌ها
🔸تحلیل دانش و استنتاج مبتنی بر گراف
زیرساخت معنایی برای سیستم‌های چندعاملی (Multi-Agent Systems)

⚙️ ویژگی‌های فنی

🔸متن‌باز با مجوز MIT
🔸مناسب برای محیط‌های تحقیقاتی و صنعتی
🔸قابل ادغام با پشته‌های مدرن LLM و Data Engineering

📎 مخزن گیت‌هاب:
🔗 https://github.com/Hawksight-AI/semantica

@asrgooyeshpardaz

📌 مدل FunctionGemma 270M Function Calling روی Edge و Device

مدل FunctionGemma 270M (توسعه‌یافته توسط Google DeepMind) یک مدل زبانی سبک و هدفمند است که به‌طور خاص برای تبدیل زبان طبیعی به فراخوانی ساختارمند توابع (Function Calling) طراحی شده است. این مدل برای اجرا روی Edge / On-Device ساخته شده و گزینه‌ای جدی برای Agentهای سبک و مستقل از Cloud محسوب می‌شود.

🔹 ویژگی‌های کلیدی
⚡ تنها ۲۷۰ میلیون پارامتر (Latency و مصرف انرژی بسیار پایین)
🧩 خروجی ساختارمند (JSON / Function Call) به‌جای متن آزاد
🔒 اجرای کامل روی دستگاه (Privacy-First)
🧠 مناسب برای Agentic AI سبک
🔁 پشتیبانی از Context بزرگ (تا 32K توکن)

🔥 مثال عملی: تبدیل سؤال به Function Call

📍 سناریو

کاربر می‌پرسد:

دمای تهران چنده؟

مدل باید این سؤال را به یک فراخوانی دقیق تابع تبدیل کند.
1️⃣ نصب وابستگی‌ها

pip install torch transformers 

2️⃣ بارگذاری مدل FunctionGemma

 from transformers import AutoProcessor, AutoModelForCausalLM

processor = AutoProcessor.from_pretrained(
    "google/functiongemma-270m-it",
    device_map="auto"
)

model = AutoModelForCausalLM.from_pretrained(
    "google/functiongemma-270m-it",
    dtype="auto",
    device_map="auto"
)

3️⃣ تعریف تابع (Schema)

weather_function_schema = {
    "type": "function",
    "function": {
        "name": "get_current_temperature",
        "denoscription": "Gets the current temperature for a given location.",
        "parameters": {
            "type": "object",
            "properties": {
                "location": {
                    "type": "string",
                    "denoscription": "City name, e.g. Tehran"
                }
            },
            "required": ["location"]
        }
    }
}

4️⃣ پیام ورودی (Prompt)

messages = [
    {
        "role": "developer",
        "content": "You are a model that can do function calling using the provided functions."
    },
    {
        "role": "user",
        "content": "دمای تهران چنده؟"
    }
]

📌 نقش developer به مدل اعلام می‌کند که باید خروجی را به‌صورت Function Call تولید کند.
5️⃣ اجرای مدل و دریافت خروجی

inputs = processor.apply_chat_template(
    messages,
    tools=[weather_function_schema],
    add_generation_prompt=True,
    return_dict=True,
    return_tensors="pt"
)

outputs = model.generate(
    **inputs.to(model.device),
    max_new_tokens=128,
    pad_token_id=processor.eos_token_id
)

response = processor.decode(
    outputs[0][len(inputs["input_ids"][0]):],
    skip_special_tokens=True
)

print(response)

📤 خروجی نمونه

<start_function_call>
call:get_current_temperature{location:"Tehran"}
<end_function_call>

✅ این خروجی قابل Parse است و می‌توان مستقیماً تابع واقعی سیستم یا API هواشناسی را با آن اجرا کرد.

🧠 نکات تخصصی مهم
❌ مدل FunctionGemma برای چت عمومی طراحی نشده
✅ تمرکز اصلی: Function Calling دقیق و قابل‌اجرا
🔧 برای کاربرد واقعی، Fine-Tuning یا On-Device RAG به‌شدت توصیه می‌شود
⚡ ایده‌آل برای موبایل، IoT، Embedded و Edge AI

🚀 موارد استفاده پیشنهادی
🤖 طراحی Agentهای محلی بدون Cloud
📱 دستیارهای هوشمند فارسی روی موبایل
🏠 اتوماسیون خانگی با زبان طبیعی
🔐 سیستم‌های حساس به حریم خصوصی

🔗 لینک مدل در HuggingFace
https://huggingface.co/google/functiongemma-270m-it

@asrgooyeshpardaz

🐍 مدل‌های زبانی بازگشتی (RLM)

پژوهشگران MIT روشی با نام RLM معرفی کرده‌اند که به مدل‌های زبانی بزرگ (LLMها، مانند GPT-5) امکان می‌دهد کانتکست‌هایی با طول بیش از ۱۰ میلیون توکن را پردازش کنند 🔥

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

📊 نتایج روی ۴ وظیفهٔ مختلف:

✅ روش RLM به‌صورت پایدار روی کانتکست‌هایی کار می‌کند که ۱۰۰ برابر بزرگ‌تر از محدودیت GPT-5 (یعنی ۲۷۲ هزار توکن) هستند

✅ در وظایف پیچیده (مانند OOLONG-Pairs) عملکرد RLM تا ۵۸٪ بهتر از LLMهای پایه است 🤯

✅ هزینهٔ هر درخواست، هم‌سطح یا حتی کمتر از فراخوانی مستقیم مدل است 💰

🚀 مزیت کلیدی:
روش RLM در مواجهه با وظایف «اطلاعات‌متراکم» بسیار موفق است؛ وظایفی که نیاز دارند تقریباً تمام بخش‌های کانتکست تحلیل شوند — دقیقاً همان‌جایی که LLMهای معمولی شکست می‌خورند.

🔮 این روش مسیر را برای ساخت سامانه‌های هوش مصنوعی باز می‌کند که قادر به استدلال بازگشتی هستند و می‌توانند تقریباً بدون محدودیت عملی در طول ورودی/خروجی مقیاس‌پذیر شوند.

🔗 مقاله: https://arxiv.org/abs/2512.24601

#هوش_مصنوعی #پژوهش

@asrgooyeshpardaz

🤖 پوست الکترونیکی جدید برای ربات‌ها

دانشمندان چینی یک پوست الکترونیکی رباتیک نورومورفیک توسعه داده‌اند که عملکردی شبیه سیستم عصبی انسان دارد:

🧩 ۴ لایه: لایهٔ محافظ، حسگرها، مدارها و آهن‌رباها

⚡️ حسگرها می‌توانند فشار و همچنین «درد» را در صورت عبور نیرو از آستانهٔ مشخص تشخیص دهند

🦾⚡️ در تماس‌های خطرناک، سیگنال مستقیماً به موتورها ارسال می‌شود و از CPU عبور نمی‌کند — ربات فوراً دست خود را عقب می‌کشد

🩹 در صورت آسیب‌دیدگی، پوست ارسال «پالس‌های حیاتی» را متوقف می‌کند و ربات می‌تواند محل آسیب را تشخیص دهد

🔧🧲 ماژول‌های مغناطیسی امکان می‌دهند بخش آسیب‌دیده در چند ثانیه تعویض شود

🔮 گام بعدی این پژوهش، آموزش پوست برای تشخیص هم‌زمان چند تماس مختلف است. این دستاورد ربات‌ها را به تعامل شهودی‌تر و ایمن‌تر با انسان‌ها و محیط اطراف نزدیک‌تر می‌کند 🤖✨

🔗 منبع:
https://techxplore.com/news/2025-12-robotic-skin-humanoid-robots-pain.html
#پژوهش #رباتیک
@asrgooyeshpardaz

🌟 مدل IQuest-Coder-V1: مدل چینی که رهبران کدنویسی را پشت سر گذاشت.

مدل Quest Research با حمایت صندوق Ubiquant، مدل ۴۰ میلیارد پارامتری‌ای را معرفی کرد که دارای پنجرهٔ کانتکست ۱۲۸ هزار توکن است و به گفتهٔ نویسندگان، به امتیازهای ۸۱٫۴٪ در SWE-Bench Verified، ۴۹٫۹٪ در BigCodeBench و ۸۱٫۱٪ در LiveCodeBench v6 دست یافته است.
این نتایج با وجود تعداد پارامترهای به‌مراتب کمتر، از عملکرد Claude Sonnet 4.5 و GPT-5.1 بهتر است.
این مدل از تکنیک «code-flow» استفاده می‌کند — آموزش بر اساس تکامل مخازن (repositories) و کامیت‌ها — و به دو شاخه تقسیم شده است:

🟠 شاخه Dense Models: نسخه‌های Base و Instruct برای پیش‌تمرین/فاین‌تیون و پیروی از دستورالعمل‌ها

🟢شاخه Loop Models: نسخهٔ بهینه‌سازی‌شدهٔ Instruct با بیشینهٔ کارایی از نظر مصرف VRAM (نسخهٔ int4 می‌تواند روی کارت‌های 3090/4090 اجرا شود)

معماری LoopCoder از ساختار چرخه‌ای ترنسفورمر استفاده می‌کند؛ به‌گونه‌ای که یک مجموعه پارامتر یکسان در دو گذر پردازشی پیاپی به کار می‌رود.
در گذر نخست، مدل امبدینگ‌ها را با درنظرگرفتن موقعیت واژه‌ها از لایه‌های خود عبور می‌دهد.
در گذر دوم، مدل به‌طور هم‌زمان از دو نوع توجه استفاده می‌کند:
توجه سراسری (Global Attention) که به تمام اطلاعات گذر اول برای درک کانتکست کلی رجوع می‌کند، و
توجه محلی (Local Attention) که فقط به واژه‌های قبلی در گذر دوم نگاه می‌کند تا پیوستگی توالی متن حفظ شود.
این دو نوع توجه با سازوکاری ترکیب می‌شوند که تعیین می‌کند چه میزان وزن به کانتکست سراسری و چه میزان به توالی محلی داده شود.
در گزارش فنی همچنین به نسخه‌های 7B و 14B اشاره شده است، اما زمان انتشار آن‌ها هنوز مشخص نیست.

📌 مجوز (Licensing):
Modified MIT License
🟡 صفحهٔ پروژه
🟡 گزارش فنی
🟡 مجموعهٔ مدل‌ها
🖥 GitHub

#AI #ML #LLM #IQuest #QuestResearch

@asrgooyeshpardaz

📌 بهینه‌سازی حذف نویز برای ASR — چرا این موضوع تبدیل به چالشی مهم در سیستم‌های تشخیص گفتار شده؟

در سال‌های اخیر، با توسعه سریع سامانه‌های تشخیص خودکار گفتار (ASR)، یک مسئله مهم در عمل ظاهر شده است: بسیاری از روش‌های حذف نویز سنتی که برای بهتر کردن کیفیت شنیداری صدا طراحی شده‌اند، عملاً عملکرد ASR را بهبود نمی‌دهند — بلکه گاهی بدتر هم می‌کنند!

💡 مشکل اصلی: «بهینه‌سازی برای گوش انسان ≠ بهینه‌سازی برای ماشین»
بسیاری از ابزارهای حذف نویز مثل Krisp، انتی‌نویز هدفون‌ها یا روش‌های رایج، صدا را برای شنیدن بهتر انسان تمیز می‌کنند — یعنی بخش‌هایی از نویز و حتی جزئیات گفتار را حذف می‌کنند تا صوت واضح‌تر به گوش برسد. اما همین حذف جزئیات ظریف، الگوهای آکوستیک مهمی را که مدل‌های ASR برای تشخیص صحیح کلمات نیاز دارند می‌زداید. نتیجه؟
➡️ ممکن است صدا برای انسان «تمیزتر» باشد، اما الگوریتم ASR بیشتر اشتباه می‌کند.
به این پدیده گاهی پارادوکس کاهش نویز (Noise Reduction Paradox) هم می‌گویند — یعنی حذف نویز بهتر برای شنیده شدن انسان، لزوماً به معنای بهبود رونویسی (trannoscription) برای ماشین نیست.

🔍 راهکار نوین: «حذف نویز بهینه‌شده برای ASR»
برای حل این مسأله، چند تیم فنی راهکار جدیدی را معرفی کرده‌اند که در آن حذف نویز دقیقا هم‌راستا با فرایند ASR انجام می‌شود:
🎯 به‌جای حذف همه نویزها، سیستم طوری طراحی می‌شود که الگوهای صوتی و آکوستیک مهم گفتار را حفظ کند تا مدل ASR بهتر بتواند آنها را تفسیر کند، حتی در حضور نویز محیطی شدید.

📌 مثالی از این رویکرد:
🔹 روش Sanas ASR-Optimized Noise Cancellation — یک ماژول حذف نویزی که قبل از ASR قرار می‌گیرد، اما طوری آموزش داده شده که:
نویز مزاحم را کاهش دهد،
و در عین حال ویژگی‌های آکوستیک مهم گفتار را حفظ کند تا نرخ خطا (WER) کاهش یابد.
نتایج آزمایش‌ها نشان می‌دهند که این رویکرد باعث کاهش قابل‌توجه نرخ خطا در رونویسی (WER) در صداهای نویزی می‌شود، بدون اینکه روی صداهای تمیز اثر منفی بگذارد.

🧠 رویکرد مشابه: Quail STT
پروژه دیگری به نام Quail STT دقیقاً همین اصل را دنبال می‌کند:
🔹 به‌جای تمیز کردن صدا برای گوش انسان،
🔹 بهینه‌سازی صدا برای تشخیص ماشین انجام می‌شود.

🍃 این مدل در آزمایش‌های واقعی با سرویس‌های مختلف رونویسی (مثل Deepgram، Gladia، AssemblyAI و …) نشان داده که:
حذف نویز به روش معمول ممکن است جزئیات گفتار را از بین ببرد.
اما روش‌های بهینه‌شده برای STT باعث کاهش خطا تا ۱۰–۳۰٪ در شرایط چالش‌برانگیز واقعی می‌شوند.

🧩 نتیجه‌گیری — یک نگاه کلیدی
✅ تشخیص خودکار گفتار (ASR) اساس بسیاری از سرویس‌های صوتی مدرن است.
✅ اما بهترین روش حذف نویز برای انسان، همیشه بهترین روش برای ASR نیست.
✅ راه‌حل مدرن این است که حذف نویز را طوری آموزش دهیم که خود ASR آن را بفهمد و عملکردش بهبود یابد.
✅ این موضوع به‌خصوص در کاربردهای دنیای واقعی (مثل تماس‌های تلفنی، مکالمات در محیط‌های شلوغ یا رابط‌های صوتی هوشمند) اهمیت زیادی دارد.

🔗منابع:

https://ai-coustics.com/2025/11/20/quail-stt-asr-trannoscription/

https://www.sanas.ai/blog/inside-sanas-asr-optimized-noise-cancellation-for-agentic-ai

@asrgooyeshpardaz

👤 معرفی Avatar Forcing — مدلی برای ساخت آواتارهای زنده که در زمان واقعی به مخاطب واکنش نشان می‌دهند

🎯 ایدهٔ اصلی:
• تولید آواتار با تأخیری فقط ۵۰۰ میلی‌ثانیه — حدود ۶٫۸ برابر سریع‌تر از راهکارهای مشابه
• در نظر گرفتن گفتار، حالات چهره و حرکات کاربر با استفاده از رویکرد diffusion forcing
• آموزش بدون برچسب‌گذاری دستی از طریق بهینه‌سازی ترجیحات (Preference Optimization)

📊 نتایج:
• در آزمون‌ها، کاربران در ۸۰٪ موارد Avatar Forcing را ترجیح داده‌اند
• حرکات آواتار بیان‌گراتر و هماهنگ‌تر با طرف مقابل است
• عملکرد بلادرنگ (Real-time) — مناسب برای تعاملات زنده و پویا

💡 کاربردها:
دستیارهای مجازی، آموزش، سرگرمی و ارتباطات تعاملی

🔗 کد و مدل وعده داده شده که به‌صورت عمومی منتشر شوند:
https://taekyungki.github.io/AvatarForcing/

#هوش_مصنوعی #پژوهش #آواتارها
@asrgooyeshpardaz

⚡️ مقاله جدید از Tencent: تنازع بقا وقتی فقط یک LLM-Agent باید «زنده بماند»

یک مقاله‌ی جدید از Tencent نشان می‌دهد که اگر عامل‌های زبانی را در سناریوی winner-takes-all قرار دهیم، کیفیت و سلامت رفتاری آن‌ها به‌شدت افت می‌کند.

🔬 پژوهشگران چارچوبی به نام Hunger Game Debate (HATE) طراحی کردند:
به عامل‌ها گفته شد فقط یک نفر برنده می‌شود و بقیه حذف خواهند شد.

🧪 سه نوع وظیفه:
سوالات فکت‌محور
نگارش پروپوزال پژوهشی
متن‌های اقناعی

📉 نتایج در مقایسه با مناظره‌های معمولی:
افزایش puffery (خودستایی اغراق‌آمیز)
استفاده از زبان احساسی و اضطراب‌آلود
حمله به سایر عامل‌ها به‌جای نقد استدلال
انحراف از مسئله و تمرکز بر «بردن»

🧠 برداشت فنی: با فشار حذف، تابع هدف عامل‌ها از «درست‌گویی و کمک‌پذیری»
به «برنده‌شدن و حذف‌نشدن» تغییر می‌کند.

⚠️ پیام کلیدی برای Agentic AI: Alignment فقط در مدل نیست؛
در قوانین رقابت، پاداش و حذف است.

📄 مقاله:
http://arxiv.org/abs/2509.26126

@asrgooyeshpardaz