تصور کنید یک عامل پشتیبانی مشتری، سیاست بازگشت وجه را کاملاً اشتباه به کاربر اعلام کند، اما در گزارش‌های فنی سیستم، این درخواست با وضعیت «موفقیت‌آمیز» ثبت شود. این همان کابوس «شکست خاموش» است که می‌تواند اعتماد کاربران به سامانه‌های خودکار را به‌طور کامل نابود کند. Lemma با جذب ۲.۳ میلیون دلار سرمایه در مرحله پیش‌بذر، قصد دارد با این شکست‌های خاموش مبارزه کند.
بیشتر ابزارهای نظارتی فعلی به‌دنبال کرش‌ها یا تأخیرهای زمانی (Timeout) می‌گردند. اما عامل‌های هوش مصنوعی مشکلی عمیق‌تر دارند: آن‌ها می‌توانند تمام مراحل فنی را بی‌نقص اجرا کنند، اما هدف کاربر را به‌طور کلی اشتباه بفهمند. به نقل از مستندات Lemma، این وضعیت «شکست معنایی» (Semantic Failure) نام دارد و معمولاً برای ابزارهای سنتی مشاهده‌پذیری (Observability) نامرئی است.
زمینه و جذب سرمایه
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت و پایداری مدل‌های زاینده اشاره کردیم، فاصله میان عملکرد مدل در محیط آزمایشگاهی و دنیای واقعی همواره یک چالش جدی بوده است. Lemma که توسط جری ژانگ و کول گاوین تأسیس شده و از دوره پاییز ۲۰۲۵ Y Combinator فارغ‌التحصیل شده است، دقیقاً برای پر کردن این شکاف ایجاد شده است. مؤسسان این شرکت پیش از این در Tandem (که هوش مصنوعی را در حوزه بهداشت و درمان به کار می‌گیرد) و ChipStack (که عامل‌های هوش مصنوعی برای طراحی تراشه توسعه می‌دهد) روی سیستم‌های هوش مصنوعی کار کرده بودند. آن‌ها در این استارتاپ‌ها از نزدیک دیدند که چگونه عامل‌هایی که در محیط‌های کنترل‌شده آزمایشگاهی عالی عمل می‌کردند، در محیط عملیاتی و تولید (Production) به‌طور کامل فرو می‌پاشند.
طبق اعلام ژانگ، دلیل اصلی تأسیس Lemma تجربه شخصی آن‌ها از دردهای ساخت عامل‌های هوش مصنوعی بود. او می‌گوید: «من و کول Lemma را به این دلیل راه انداختیم که خودمان این درد را تجربه کرده بودیم. ما مدام با یک مشکل تکراری مواجه می‌شدیم: عامل‌ها به‌ظاهر درست کار می‌کردند، اما نتایج در محیط عملیاتی به اندازه کافی قابل اطمینان نبودند.»
این استارتاپ در دور پیش‌بذر (Pre-seed) خود ۲.۳ میلیون دلار سرمایه جذب کرد. در این دور، مجموعه‌ای از سرمایه‌گذاران از جمله Matrix, Y Combinator, Liquid 2 Ventures, Vermilion Cliffs Ventures, Irregular Expressions, Cervin Ventures, Comma Capital, Position Ventures و Eight Capital حضور داشتند. علاوه بر این، فرشتگان سرمایه‌گذاری و فعالان عملیاتی از شرکت‌های پیشرویی چون OpenAI, xAI, Meta و DoorDash روی این ایده شرط‌بندی کردند. این توجه سرمایه‌گذاران در حالی رخ می‌دهد که پیش‌بینی‌هایی مبنی بر ورود میلیاردها عامل هوشمند به بازار تا سال ۲۰۳۱ وجود دارد که نیاز به زیرساخت‌های نظارتی را دوچندان می‌کند. بر اساس گزارش unite.ai، این پلتفرم تاکنون بیش از یک میلیون ردپای (Trace) عامل را برای شناسایی الگوهای خطا پردازش کرده است.
ماهیت شکست‌های معنایی
در نرم‌افزارهای سنتی، نظارت بر اساس سیگنال‌های صریح شکست طراحی شده است. مثلاً یک اپلیکیشن کرش می‌کند، یک درخواست کد خطای HTTP باز می‌گرداند، تأخیر (Latency) به‌شدت افزایش می‌یابد یا یکی از اجزای زیرساختی در دسترس نیست. در این موارد، سیستم به‌وضوح می‌داند که شکست خورده است.
اما عامل‌های هوش مصنوعی کلاس متفاوتی از مشکلات را معرفی می‌کنند. یک عامل می‌تواند تمام مراحل فنی یک گردش‌کار را با موفقیت اجرا کند و همچنان دچار موارد زیر شود:
- هدف کاربر را اشتباه بفهمد
- ابزار (Tool) غلطی را فراخوانی کند
- از اطلاعات نادرست استفاده کند
- در یک حلقه بی‌حاصل و غیربهره‌ور گیر کند
- پاسخی متقاعدکننده اما کاملاً غلط (Hallucination) بدهد
مثال‌های عینی از این شکست‌ها شامل یک عامل حسابرسی است که گزارشی قدیمی تولید می‌کند، یا عاملی که با استفاده از اطلاعاتی که خودش اختراع کرده است، یک سیستم خارجی را فراخوانی می‌کند. این تفاوت زمانی حیاتی می‌شود که عامل‌ها از چت‌های ساده فراتر رفته و گردش‌کارهای چندمرحله‌ای پیچیده‌ای را اجرا کنند که در آن مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — با پایگاه‌های داده، رابط‌های برنامه‌نویسی کاربردی (APIها) و سیستم‌های بازیابی (Retrieval) در تعامل است. در این زنجیره، یک خطا لزوماً منجر به یک استثنای فنی (Technical Exception) نمی‌شود؛ بلکه عامل صرفاً با داده‌های غلط به مسیر خود ادامه می‌دهد. این چالش‌های پایداری در کنار تهدیدات امنیتی قرار دارند؛ چنان‌که استارتاپ Zenity نیز با جذب سرمایه کلانی بر تأمین امنیت این عامل‌های خودکار تمرکز کرده است تا از سوءاستفاده‌های احتمالی جلوگیری کند.
ترسیم درخت اجرا
پلتفرم Lemma یک لایه مشاهده‌پذیری ایجاد می‌کند که هر اقدام عامل را به یک ردپای ساختاریافته تبدیل می‌کند. تیم‌های مهندسی به‌جای دیدن صرفِ پاسخ نهایی، می‌توانند کل «درخت اجرا» را بررسی کنند. این درخت شامل موارد زیر است:
- فراخوانی‌های زیربنایی مدل زبانی بزرگ (LLM calls)
- فراخوانی‌های دقیق ابزارها و ورودی/خروجی‌های APIها
- مراحل بازیابی (Retrieval) و داده‌های مربوط به زمان‌بندی
- خطاهایی که در میانه گردش‌کار ایجاد شده‌اند
این پلتفرم با تحلیل این ردپاها در برابر دستورات اولیه عامل، اشتباهات تکراری را در قالب «موضوعات» (Issues) دسته‌بندی می‌کند. این یعنی مهندسان به‌جای شکار تک‌تک باگ‌ها، الگوهای سیستماتیک را در هزاران تعامل شناسایی می‌کنند. پلتفرم می‌تواند این موضوعات را اولویت‌بندی کرده و در صورت ظهور مشکلات جدی، هشدارها را از طریق Slack ارسال کند.
بستن حلقه بازخورد
یافتن خطا تنها گام اول است. Lemma با تحلیل بستر (Context) surrounding یک شکست، علت ریشه‌ای احتمالی را تعیین کرده و تغییرات مشخصی را برای پرامپت‌ها، منطق برنامه یا گردش‌کارهای عامل پیشنهاد می‌دهد. این کار نیاز مهندسان به بازسازی دستی هر تعامل مشکل‌دار را از بین می‌برد.
برای نزدیک‌تر کردن این فرآیند به کد، شرکت یک سرور پروتکل زمینهٔ مدل (MCP) — شبیه به یک مترجم استاندارد که اجازه می‌دهد ابزارهای مختلف به‌راحتی با حافظه مدل ارتباط بگیرند — راه‌اندازی کرده است. این قابلیت به توسعه‌دهندگان اجازه می‌دهد ردپاهای عملیاتی را مستقیماً از ابزارهایی مثل Cursor، Claude Desktop و Claude Code بازجویی کنند.
در نهایت، وقتی یک اصلاحیه اعمال می‌شود، پلتفرم آن شکست واقعی در محیط تولید را به یک ارزیابی آنلاین (Online Evaluation) تبدیل می‌کند. این یعنی یک مورد خاص (Edge Case) در دنیای واقعی، به یک تست دائمی تبدیل می‌شود تا از تکرار همان اشتباه در آینده جلوگیری شود. این یک چرخه بازخوردی است که در آن شکست‌های پیش‌بینی‌نشده، به‌جای اینکه حوادثی ایزوله باشند، به آزمون‌های آینده تبدیل می‌شوند.
تغییر در زیرساخت
این رویکرد این فرض را به چالش می‌کشد که مدل‌های بنیادی بهتر، به‌تنهایی مشکل پایداری را حل می‌کنند. رفتار واقعی به زنجیره شکننده‌ای از پرامپت‌ها، منطق برنامه، ابزارها، یکپارچه‌سازی‌ها، سیستم‌های بازیابی و رفتار کاربر وابسته است. ارزیابی‌های آفلاین به‌ندرت می‌توانند شرایط غیرقابل‌پیش‌بینی محیط عملیاتی را بازسازی کنند؛ بنابراین داده‌های واقعی، مهم‌ترین منبع برای درک نقاط شکست سیستم هستند.
با ورود عامل‌ها به حوزه‌های حساس مثل مدیریت بهداشت، تحلیل مالی، توسعه نرم‌افزار و پژوهش، معیار موفقیت تغییر کرده است. دیگر دانستن اینکه «آیا گردش‌کار به پایان رسید» کافی نیست؛ سازمان‌ها باید بدانند «آیا درست به پایان رسید».
این تحول نشان‌دهنده حرکت صنعت به سمت «مشاهده‌پذیری عامل‌محور» (Agentic Observability) به‌عنوان بخشی استاندارد از پشته فناوری هوش مصنوعی است. هدف، سیستمی است که عامل‌ها به‌طور سیستماتیک از شکست‌های خود درس بگیرند، نه اینکه منتظر وصله‌های دستی مهندسان باشند.
باید دید غول‌های مشاهده‌پذیری مانند Datadog یا New Relic چگونه به این نیچِ (Niche) نظارت معنایی پاسخ می‌دهند، چرا که تقاضا برای گردش‌کارهای خودکار و قابل اطمینان در حال افزایش است.
گام بعدی شما
- اگر در حال توسعه عامل‌های چندمرحله‌ای هستید، به‌جای تکیه بر ارزیابی‌های آفلاین، روی ثبت ردپاهای (Traces) محیط عملیاتی تمرکز کنید.
- بررسی کنید که آیا ابزارهای نظارتی شما قادر به تشخیص «شکست‌های معنایی» هستند یا فقط کرش‌های فنی را گزارش می‌دهند.
- پروتکل MCP را برای یکپارچه‌سازی محیط توسعه با داده‌های عملیاتی بررسی کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو