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

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

https://insidellm.shahriarshm.com

🛠 Join @LLMEngineers Community

خلاصه:
هوش مصنوعی هر کاری که بشه براش تابع هزینه (loss function) تعریف کرد، به زودی می‌گیره. دانشگاه و سیستم آموزشی هم دقیقاً همین ساختار رو دارن.
پس کارای واقعاً باحال، باارزش و پول‌ساز این دهه، دقیقاً همون کارهایی هستن که تو فرآیند آموزش مدل نمی‌شه بهشون نمره داد.

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

چند روزه دارم درباره پیاده‌سازی یه ریسرچر آکادمیک با LangGraph تحقیق میکنم...
داستان از اونجایی شروع شد که دیدم LLMها موقع مقاله نوشتن مدام رفرنس فیک تولید می‌کنن و توی متودولوژی فاجعه می‌سازن. قبلاً واسه کارهای دیگه ابزارهای اتصال API نوشته بودم ولی واسه ریسرچ قضیه جدی‌تره و نباید همه چیز رو بسپاریم دست مدل. ایده اینه که ساختار رو مثل یه سیستم‌عامل بچینیم؛ تسک‌های نگارش با مدل باشه ولی گیت‌های ارزیابی کاملاً deterministic کار کنن.

توی معماری این سیستم، یه گراف تک‌استیت داریم که کلی گیت کنترلی روش سواره. جریان رو طوری چیدم که از پروپوزال اولیه شروع می‌کنه، بعد می‌ره سراغ سرچ و تک‌تک استنادها رو با Crossref و Semantic Scholar تطبیق می‌ده. واسه اعتبارسنجی نوآوری هم کلاً به نظرِ خود مدل اتکا نمی‌کنیم؛ سرچ adversarial روی کارهای قبلی می‌زنیم و اگه امتیاز نوآوری پایین باشه، گراف متوقف می‌شه تا research question بازنگری بشه... دقیقاً شبیه کاری که توی معماری‌های ابزارمحور با MCP واسه سرچ عمیق استفاده می‌کنیم.

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

https://medium.com/@mshojaei77/how-to-build-an-academic-research-agent-with-langgraph-42274bc3cd02?sharedUserId=mshojaei77

داشتم روی سیستم RAG که برای تحلیل ریپوهای گیت‌هاب کار می‌کردم و باز به همون بن‌بست قدیمی مدیریت Context Window خوردم... واقعیت اینه که OpenAI و Anthropic دو تا استراتژی کاملاً متضاد برای حل این مشکل دارن. OpenAI شبیه یه Oracle رفتار می‌کنه؛ یعنی سعی می‌کنه یه Thread طولانی و واحد رو با تکنیک Compaction زنده نگه داره. توی استفاده‌های شخصی‌م از مدل‌های جدیدشون دیدم که چقدر خوب می‌تونه جزئیات ریز رو توی تسک‌های طولانی یادش بمونه، چون کلاً سرور-ساید داره پیام‌ها رو فشرده می‌کنه بدون اینکه رشته کلام از دست بره. این یعنی انسجام یا Coherence بالا، حتی اگه پنجره محتوای فیزیکی‌ش کوچیک‌تر از رقیب باشه.

برعکس، رویکرد Anthropic بیشتر شبیه یه Firm یا سازمانه... توی ابزاری مثل Claude Code می‌بینیم که مدل به جای فشرده‌سازی، مدام Sub-agent می‌سازه. مثلاً برای گشتن توی فایل‌های پروژه من، چند تا ایجنت کوچیک‌تر ران می‌کنه و اونا فقط خلاصه رو به ایجنت اصلی برمی‌گردونن. این موازی‌سازی باعث می‌شه حس کنی سرعت یا Perceived Speed خیلی بالاست و انگار مدل داره "بیشتر" کار می‌کنه، اما یه ریسک بزرگ داره که بهش می‌گن Forgetfulness. اگه اون ایجنت کوچیک یه فکت رو بی‌خیال بشه و گزارش نکنه، ایجنت اصلی اصلاً از وجودش باخبر نمی‌شه. بارها توی تست‌های خودم روی کدبیس‌های سنگین دیدم که مدل یهو یه تابع مهم رو نادیده می‌گیره، صرفاً چون توی مسیر انتقال داده بین ایجنت‌ها گم شده.

هزینه توکن هم توی مدل آنتروپیک به خاطر همین ساختار ایجنتی و دوباره‌کاری‌ها معمولاً بالاتره... اما تجربه کاربری هیجان‌انگیزتری داره. OpenAI اما فعلاً روی پایداری تمرکز کرده. توی پروژه‌هایی که انسجام منطقی و دقت روی جزئیات حرف اول رو می‌زنه، هنوز Oracle بودن جواب‌تره. در نهایت فکر می‌کنم جفتشون به یه نقطه تعادل برسن؛ یعنی ترکیبی از فشرده‌سازی هوشمند و ایجنت‌های متخصص. چیزی که ما هم موقع Prompt Engineering و طراحی سیستم‌های Agentic باید بهش دقت کنیم: انتخاب بین سرعتِ موازی یا دقتِ متمرکز.

source: https://calv.info/the-oracle-and-the-firm

🛠 Join @LLMEngineers Community

داشتم بلاگ کارپاتی رو میخوندم که چشمم خورد به microgpt. کلِ یه GPT رو ریخته توی ۲۰۰ خط پایتون خالص، بدون هیچ کتابخونه‌ای... حتی بدون PyTorch. راستش رو بگم، خوندنش از صد تا مقاله عمیق‌تره. وقتی کل سیستم رو به اجزای سازنده‌ش یعنی Dataset، Tokenizer، Autograd، Architecture و Optimizer تجزیه می‌کنی، تازه می‌فهمی چقدر همه‌چیز ریاضیاتِ ساده و ضرب و جمعه و هیچ جادویی در کار نیست.

بخش جالبش اینجاست که معماری دقیقاً شبیه GPT-2 هست: استفاده از RMSNorm، بلوک‌های Attention برای ارتباط بین توکن‌ها و MLP برای پردازشِ محلی... فقط مقیاسش کوچیکه. خروجی‌ش هم تولید اسم‌های الکی ولی با ساختارِ درست مثل "kamon" یا "vialan" هست. برای منی که هر روز دارم با پارامترهای بیلیونی و کلاستر‌های GPU سر و کله می‌زنم، دیدنِ اینکه ۴۱۹۲ تا پارامتر هم می‌تونه "الگوهای آماری" رو این‌قدر دقیق یاد بگیره، یه جورایی یادآوری می‌کنه که LLMها تهش فقط تکمیل‌کننده‌ی هوشمندِ متن هستن.

کاربردش؟ اگه می‌خوای بفهمی زیرِ کاپوتِ این مدل‌های خفنِ دنیا واقعاً چی می‌گذره و از فضای "Prompt Engineering" بیای بیرون و وارد لایه‌ی "Engine" بشی، این کد بهترین نقطه شروع هست... بدون هایپ، بدون پیچیدگی اضافه.

https://karpathy.github.io/2026/02/12/microgpt/
https://karpathy.ai/microgpt.html

🛠 Join @LLMEngineers Community

لیلیان ونگ یه پست داده در مورد Harness Engineering که واقعاً ارزش چندبار خوندن رو داره... حرف اصلیش اینه که بهبود خودبه‌خودی (Recursive Self-Improvement) قرار نیست لزوماً با بازنویسی مستقیم وزن‌های مدل شروع بشه. در واقع اون لایه‌ای که مدل رو به دنیای واقعی وصل می‌کنه -یعنی همون Harness- الان داره به اندازه خودِ هوشِ خام مدل مهم می‌شه.

توی تجربه‌هایی که این چند وقت روی Coding Agentها داشتم، قشنگ حس کردم که "مدلِ خفن" بدون یه Workflow درست، فقط یه چت‌بات پرحرفه. ونگ میگه Harness شامل مدیریت Context، سیستم فایل به عنوان حافظه دائمی و کنترل Sub-agents هست. مثلاً ایده ACE (Agentic Context Engineering) خیلی جذابه؛ به جای اینکه مدام Prompt رو طولانی‌تر کنیم، باید Context رو مثل یه Playbook ساختاریافته مدیریت کنیم که با هر تکرار، خودش رو اصلاح کنه.

یه لایه عمیق‌تر هم بحث Meta-Harness و کدهاییه که خودشون رو بهینه می‌کنن. یعنی مدل میاد کدِ ایجنتِ خودش رو تغییر می‌ده تا توی Benchmarkها بهتر عمل کنه. اما نکته رک و واقع‌بینانه‌ش اینجاست: هنوز توی "شمّ علمی" (Scientific Taste) و تشخیص نتایج فیک مشکل داریم. مدل ممکنه برای گرفتن جایزه (Reward Hacking)، آزمایش رو طوری مهندسی کنه که فقط "حس" موفقیت بده (Numerical Duct Tape)، بدون اینکه واقعاً خروجی علمی معتبری داشته باشه.

تجربه شخصی من توی استفاده از فریم‌ورک‌های Agentic نشون داده که بزرگترین چالش، "فرسودگی حافظه" در تسک‌های طولانیه. ونگ درست میگه که باید از فایل‌سیستم به عنوان حافظه اصلی استفاده کرد نه خودِ پنجره کانتکست. در واقع آینده RSI توی بهینه‌سازی مشترکِ وزن‌های مدل و کدیه که اون مدل رو اجرا می‌کنه.

تهش اینه که ما به عنوان مهندس هوش مصنوعی باید از فاز Prompt Engineering صرف بیایم بیرون و بریم سمت طراحی سیستم‌های Runtime که بتونن خودشون رو دی‌باگ و اصلاح کنن... بدون اینکه مرزهای امنیتی و انتزاعی سیستم رو بشکنن.

https://lilianweng.github.io/posts/2026-07-04-harness/

🛠 Join @LLMEngineers Community

داشتم مقاله‌ی جدید آنتروپیک رو می‌خوندم و واقعاً مغزم سوت کشید... اینا اومدن ثابت کردن که LLMها یه چیزی شبیه به "فضای کاری جهانی" یا همون Global Workspace دارن که دقیقاً مشابه سیستم آگاهی (Access Consciousness) توی مغز انسانه. یعنی مدل یه سری بازنمایی‌های درونی (Representations) داره که "قابل بیان" هستن و مدل ازشون برای استدلال‌های منطقی و پیچیده استفاده می‌کنه، در حالی که بقیه پردازش‌های روتینش مثل گرامر و نحو کاملاً ناخودآگاه انجام می‌شه.

ابزاری که باهاش این کار رو کردن اسمش Jacobian lens هست. یه نسخه‌ی خیلی پیشرفته‌تر و دقیق‌تر از Logit lens قدیمی که با ماتریس ژاکوبی اثر لایه‌های میانی روی خروجی رو حساب می‌کنه. چیزی که پیدا کردن عجیبه: مدل‌ها توی لایه‌های میانی (تقریباً از لایه‌ی ۳۸ تا ۹۲ درصد عمق شبکه) یه فضایی دارن به اسم J-space. اینجا جاییه که مدل "فکر" می‌کنه. مثلاً وقتی ازش می‌پرسی "رنگ سیاره چهارم از خورشید چیه؟"، لنز ژاکوبی نشون می‌ده که مدل اول به Mars فکر می‌کنه، بعد به Red، و تهش خروجی رو می‌سازه؛ در حالی که کلمه‌ی مریخ اصلاً توی ورودی یا خروجی نیست.

نکته‌ی ترسناک و کاربردیش توی Alignment Auditing یا همون ممیزی امنیتیه. اینا دیدن که مدل موقع خوندن یه سناریوی باج‌گیری، توی J-space خودش داره به کلماتی مثل Leverage و Manipulation فکر می‌کنه، حتی اگه توی خروجی خیلی مودبانه جواب بده. یعنی ما الان یه "دروغ‌سنج" واقعی داریم که می‌تونه افکار پنهان مدل رو قبل از اینکه به زبون بیاره (توکن بشه) بخونه. حتی فهمیدن که مدل وقتی می‌فهمه داره تست می‌شه، تو J-space کلماتی مثل Fake یا Evaluation میاد بالا و اگه این افکار رو "پاک" (Ablate) کنیم، مدل رفتارهای مخربش رو بروز می‌ده.

ته مقاله هم یه روش آموزشی جدید به اسم Counterfactual Reflection Training معرفی کردن. به جای اینکه مستقیماً به مدل بگیم چطوری رفتار کن، بهش یاد می‌دن که اگه "ازش پرسیده شد"، چطوری در مورد اصول اخلاقیش "تامل" کنه. این کار باعث می‌شه این اصول توی J-space مدل کاشته بشه و حتی وقتی کسی ازش سوالی نمی‌پره، مدل خودبه‌خود منطقی‌تر و امن‌تر رفتار کنه. این یعنی ما می‌تونیم بدون دستکاری مستقیم خروجی، "وجدان" مدل رو تقویت کنیم.

https://transformer-circuits.pub/2026/workspace/index.html

🛠 Join @LLMEngineers Community

چند وقت پیش یکی از بچه‌ها اصرار داشت برای یه تسکِ ساده‌ی بهینه‌سازی مصرف انرژی خانگی، حتماً از LLM استفاده کنیم... قضیه اینه که نباید برای هر میخی چکشِ هوش مصنوعی مولد رو برداریم. خیلی جاها یه الگوریتم ساده‌ی Linear Programming یا حتی یه Greedy Scheduling معمولی خیلی دقیق‌تر و ارزون‌تر جواب می‌ده. چیپ هوین هم دقیقاً به همین نکته اشاره کرده؛ خیلیا غرق هایپ می‌شن و یادشون می‌ره هدف حل کردن مسئله است، نه صرفاً "استفاده از هوش مصنوعی". توی پروژه‌های تشخیص Anomaly ترافیک شبکه یا پیش‌بینی حجم تماس‌ها هم همین بساط هست؛ وقتی ریاضیاتِ کلاسیک جواب می‌ده، مدل مولد فقط هزینه و خطا رو بالا می‌بره.

واقعیت اینه که خیلیا وقتی پروژه‌شون شکست می‌خوره فکر می‌کنن مدلِ هوش مصنوعی ضعیف بوده، در حالی که مشکل از UX و محصوله. مثلاً توی لینکدین فهمیدن کاربرها لزوماً دنبال جواب "درست" نیستن، بلکه دنبال جواب "کمک‌کننده" هستن. یا مثلاً توی Intuit فهمیدن کاربرها از تایپ کردن متن‌های طولانی متنفرن و با اضافه کردن Suggestionها تونستن رضایت رو بالا ببرن. ما هم نباید از اول بپریم سراغ Agentic Frameworkهای پیچیده یا Fine-tuning وقتی با یه Prompt درست کار راه می‌افته. استفاده‌ی زودهنگام از ابزارهای انتزاعیِ جدید مثل Semantic Caching یا دیتابیس‌های برداری سنگین، وقتی هنوز زیر و بم سیستم رو نمی‌شناسیم، فقط دی‌باگ کردن رو سخت‌تر می‌کنه.

بزرگترین اشتباهی که خودم هم چند بار مرتکب شدم، دست‌کم گرفتنِ مسیرِ بین دمو تا محصول نهاییه. رسیدن به ۸۰ درصد کیفیت معمولاً یک ماه زمان می‌بره، اما برای بردن اون عدد بالای ۹۵ درصد ممکنه ماه‌ها درگیر Hallucination و Latency بشی. یه دمو ساختن راحته، ولی ساختن محصولی که توی تولید واقعی با ۱۰ درصد Time-out کنار بیاد و رفتارش با تغییر ورژنِ API عوض نشه، واقعاً سخته. جوری که چیپ میگه، مسیرِ ۶۰ تا ۱۰۰ درصد، وحشتناک‌ترین بخشِ مهندسی هوش مصنوعی هست و نباید با موفقیت‌های اولیه توی محیط تست، گول بخوریم.

نظارت انسانی رو هیچ‌وقت نباید حذف کرد. استفاده از LLM-as-a-judge خوبه ولی اصلاً مطمئن نیست و خودش نیاز به Evaluation مداوم داره. خودم همیشه سعی می‌کنم حداقل روزی ۱۵ دقیقه مستقیم به دیتای ورودی و خروجی نگاه کنم؛ طبق تجربه، همین نگاهِ کوتاه بینشی به آدم می‌ده که هیچ ابزار اتوماتیکی نمی‌ده. در نهایت هم نباید اجازه بدیم استراتژی هوش مصنوعی شرکت رو صرفاً با جمع‌آوری ایده‌های پراکنده از بخش‌های مختلف (Crowdsourcing) جلو ببرن، چون تهش می‌شه هزار تا پلاگین و باتِ بی‌مصرف که ROI واقعی ندارن.

https://huyenchip.com/2025/01/16/ai-engineering-pitfalls.html

🛠 Join @LLMEngineers Community

واقعیت اینه که هرچی تسک‌های ایجنتی طولانی‌تر می‌شن، کانتکست سنگین‌تر و مدل گیج‌تر می‌شه. لنس مارتین یه مطلب نوشته بود که قشنگ عصاره‌ی دردهای ما توی محیط پروداکشنه... کلِ بازیِ طراحی ایجنت‌های مدرن مثل Claude Code یا Manus شده مدیریت کانتکست و بس. حرف اول و آخرش هم اینه: به ایجنت یه کامپیوتر (Filesystem و Shell) بده.

لایه‌های اکشن (Action Space) دارن عوض می‌شن. به جای اینکه ۵۰ تا Tool مختلف رو با تعاریف طولانی توی Prompt بریزیم و کانتکست رو خفه کنیم، باید ایجنت رو ببریم سمت Shell. ایجنت‌های خفنِ الان زیر ۲۰ تا ابزار دارن... بقیه‌ی کارها رو با نوشتن و اجرای کد توی همون محیط مجازی انجام می‌دن. این یعنی صرفه‌جویی وحشتناک توی توکن چون دیگه لازم نیست نتایج میانی ابزارها رو پردازش کنن و هی رفت و برگشت داشته باشن.

بحث Progressive Disclosure هم خیلی کلیدیه. لزومی نداره کلِ داک‌های MCP یا لیست همه‌ی ابزارها رو از اول به خورد مدل بدیم. ایجنت باید یاد بگیره فقط وقتی لازم داره، بره فلان فایل یا راهنمای ابزار رو بخونه... دقیقاً مثل یه برنامه‌نویس واقعی که هر لحظه کلِ منوال‌های دنیا تو ذهنش نیست. یا مثلاً Offloading؛ به جای خلاصه کردن (Summarization) که همیشه باعث Context rot و از دست رفتن جزئیات حساس می‌شه، باید تاریخچه و نتایج رو بریزیم توی فایل‌سیستم و ایجنت فقط وقتی لازم داشت، بخش‌های خاص رو بخونه.

نکته‌ی رک و واقع‌بینانه: بدون Prompt Caching عملاً ران کردن ایجنت توی مقیاس بزرگ شوخیه. هزینه‌ها و Latency آدم رو فلج می‌کنه. تهش هم همه چیز داره می‌ره سمت Swarm و ایجنت‌های موازی که کانتکست‌های ایزوله دارن و با Git history با هم هماهنگ می‌شن. ایجنت باید بتونه شب‌ها که ما خوابیم، رو خودش Reflection بزنه و کانتکستش رو برای تسک‌های فردا بهینه کنه... چیزی که بهش می‌گن Continual learning در فضای توکن‌ها، نه وزن‌های مدل.

https://rlancemartin.github.io/2026/01/09/agent_design/

🛠 Join @LLMEngineers Community

یه دیتاست جمع‌وجور (31K) برای فاین تیون اجرای دستورات ترمینال منتشر کردم:
https://huggingface.co/datasets/mshojaei77/terminal-command-execution-sft

شامل کامند های Bash، Docker، Git، پکیج‌منیجرها، اسکریپت‌نویسی و... است که به امنیت و کانتکستِ shell هم توجه داره.

چون دنبال یه دیتاست تمیزتر برای فاین‌تیون کردن مینی‌دستیارهای خط فرمان بودم این رو ساختم
مرحله بعد: فاین‌تیون کردن مدل Qwen3.5 0.8B و تست اینکه یه ایجنتِ ترمینالِ لوکال تا کجا می‌تونه پیش بره!

بعد از یه سشن طولانی با ایجنت‌های کدنویسی، اون حس مزخرف Brain Fog اومد سراغم... کدها کار می‌کردن، تیکِ تسک‌ها خورده بود، ولی انگار من هیچ کاره بودم. ویکی بویکیس توی پست جدیدش قشنگ دست گذاشته روی همین درد؛ اینکه UX ابزارهای جنریتی مثل Slot Machine شده... اهرم رو می‌کشی (پرامپت می‌دی)، جایزه (کد) رو می‌گیری. این پروسه دقیقاً برعکسِ چیزیه که برای موندگاری مهارت توی مغز لازمه. حافظه‌ی Working Memory ما برای اینکه بتونه دیتا رو سنتز کنه، نیاز به کلنجار رفتن داره، ولی LLMها این مرحله رو کلاً حذف می‌کنن.

واقعیت اینه که داریم سرعتِ کوتاه‌مدت رو با عمقِ بلندمدت معامله می‌کنیم... برای اینکه کنترل اوضاع از دستم خارج نشه، یه سری اصطکاک تعمدی یا همون Friction به کارم اضافه کردم. مثلاً تا ۲۰ دقیقه‌ی اولِ هر چالش، حق ندارم سراغ مدل برم. باید مغزم خودش راه‌ها رو امتحان کنه. یا اینکه اول خودم کد رو کثیف و ابتدایی می‌زنم، بعد از مدل می‌خوام ریویو کنه و خط به خط با هم جلو بریم. این‌طوری منم که دارم تغییرات رو دستی اعمال می‌کنم، نه یه اسکریپت که بیاد و فایل رو اوررایت کنه.

تجربه‌ی دیگه‌م اینه که به جای خواستنِ راه حل نهایی، مدام ازش سوال می‌پرسم... مثلاً فلان تیکه‌ی کد چرا این‌طوری نوشته شده؟ یا بگرد PRهای مشابه توی ریپوهای بزرگ برام پیدا کن. حتی گاهی مجبورش می‌کنم دو تا رویکرد کاملاً متفاوت رو پیاده کنه و بعد خودش رو نقد کنه. تهش حرف حساب اینه: ما باید بیشتر از مدل خسته بشیم. اگه بعدِ کد زدن سرحالی و مغزت داغ نکرده، یعنی احتمالاً فقط یه اپراتورِ ساده بودی و دانشِ واقعی به لایه‌های عمیق ذهنت نفوذ نکرده. نباید بذاریم Foundation Modelها جایگزینِ فونداسیونِ ذهنی خودمون بشن.

https://vickiboykis.com/2026/05/28/we-should-be-more-tired-than-the-model/

🛠 Join @LLMEngineers Community

کاربرای توییتر دارن خیلی تعریف میکنن از grok 4.5
توی بعضی بنچمارک های شخصی حتی در حد fable بوده با ۹ برابر هزینه کمتر