اگر امروز یک قابلیت هوش مصنوعی را بدون داشبورد نظارتی در محصولتان منتشر کنید، درست مثل این است که با شیشه‌ی جلویی رنگ‌شده با مشکی رانندگی کنید. شما حرکت می‌کنید، اما تا لحظه‌ای که به دیوار برخورد کنید، نمی‌فهمید موتور ماشین در حال سوختن است. شما هرگز عاقلانه نخواهید بود که بدون کیلومترشمار، بدون نشانگر سوخت و بدون چراغ چک موتور، وارد یک بزرگراه شوید.
به نقل از راهنمای منتشرشده در ۱۹ ژوئیه ۲۰۲۶ در وب‌سایت dev.to، اکثر شرکت‌ها با هوش مصنوعی مانند یک «جعبه سیاه» برخورد می‌کنند؛ جایی که درخواست‌ها وارد می‌شوند و پاسخ‌ها خارج می‌شوند، اما آنچه در این میان می‌گذرد، رازی است که همه به‌طور اتفاقی تصمیم گرفته‌اند آن را نادیده بگیرند و دیگر به آن دست نزنند. این شکاف دیداری برای مؤسسان، مدیران محصول (PMs) و هر کسی که از بهانهٔ «جعبه سیاه» خسته شده است، یک بحران با ریسک بالا ایجاد می‌کند. در نرم‌افزارهای سنتی، یک باگ معمولاً با یک خطای بلند، توقف یا کرش همراه است و شما فوراً متوجه آن می‌شوید. اما هوش مصنوعی متفاوت است؛ او ساکت شکست می‌خورد و دقیقاً به همین دلیل، بیش از هر بخش دیگری از پشتهٔ فناوری (Stack) شما به یک داشبورد نیاز دارد.
شکست‌های خاموش هوش مصنوعی
شکست‌های هوش مصنوعی همیشه شبیه کرش‌های سخت نیستند. آن‌ها اغلب در سه حالت ظریف و نامحسوس ظاهر می‌شوند:
- تخریب تدریجی (Slow-motion degradation): یک فراخوانی مدل که معمولاً یک ثانیه زمان می‌برد، ناگهان شروع می‌کند به زمان بردن پنج ثانیه. در اینجا هیچ خطایی وجود ندارد و سیستم متوقف نمی‌شود؛ فقط ماشین به‌طور مرموزی کند می‌خزد در حالی که مسافران به‌آرامی از آن پیاده می‌شوند.
- شکست‌های نرم (Soft failures): یک حفاظ (Guardrail) ممکن است پرامپتی را رد کند یا مدل دچار زمان‌بندی خطا (Timeout) شود. اپلیکیشن به‌جای اینکه با یک پیام خطا روشن شود، صرفاً شانه بالا می‌اندازد و یک پاسخ خنثی، کلی و بی‌روح ارائه می‌دهد.
- پارادوکس توهم (The Hallucination Paradox): هوش مصنوعی زاینده (Generative AI) می‌تواند پاسخی کاملاً غلط را با اعتمادبه‌نفس کامل تحویل دهد، در حالی که سیستم در پس‌زمینه چراغ سبز کامل نشان می‌دهد. در این حالت، هیچ بخشی از زیرساخت فکر نمی‌کند که اتفاق بدی افتاده است.
این چالش‌ها یادآور پروژه Loupe است که به‌طور تخصصی بر شناسایی باگ‌های خاموشی تمرکز دارد که حتی در تست‌های اولیه نیز شناسایی نمی‌شوند.
برای حل این مشکل، تیم‌ها به دیده‌سنجی (Observability) روی آورده‌اند؛ دسته‌ای از نرم‌افزارها که برای باز کردن این جعبه طراحی شده‌اند. شاید نام این مفهوم (Observability) جذاب نباشد، اما ایده آن ساده است: دیده‌سنجی در واقع بازگرداندن داشبورد به خودرو و اضافه کردن یک دوربین داشبورد است که هر سفر را ضبط می‌کند تا به‌جای حدس زدن، بتوانید فیلم را به عقب برگردانید و دقیقاً ببینید چه اتفاقی افتاده است. هدف این است که از شکایت‌های مبهم مثل «به نظر می‌رسد AI کند شده» به داده‌های دقیق و ریاضی برسیم؛ مثلاً: «فراخوانی مدل llama-3-8b دقیقاً ۱.۱ ثانیه زمان برد».
سه ستون دیده‌سنجی هوش مصنوعی
دیده‌سنجی مؤثر بر سه ابزار بصری خاص استوار است که تلمتری‌های پیچیده را به بینش‌های عملی تبدیل می‌کنند:
ردیابی‌ها (Traces) یا همان دوربین داشبورد: یک رد (Trace) مسیر یک درخواست واحد را از لحظه شروع تا پایان ضبط می‌کند. این در واقع فیلم‌برداری از سفر یک پرسش است. هر نوار در این نمودار نشان‌دهنده یک مرحله از سفر است؛ نوار بالایی کل رانندگی را نشان می‌دهد، در حالی که نوارهای تو در تو، توقف واقعی در مدل AI را نمایش می‌دهند. طول آن نوار دقیقاً نشان می‌دهد که آن توقف چقدر زمان برده است. این ابزار اجازه می‌دهد در یک نگاه بفهمید میلی‌ثانیه‌ها کجا تلف شده‌اند و دیگر نیازی به بحث و جدل در جلسات درباره علت کندی نباشد.
داشبوردهای سرویس (Service Dashboards) یا همان عقربه‌های سرعت: در حالی که ردیابی روی یک سفر تمرکز دارد، داشبورد تمام سفرها را به‌طور هم‌زمان می‌پاید. این‌ها همان عقربه‌های زنده‌ای هستند که هنگام حرکت ماشین در مقابل چشمان شما قرار دارند. سه عقربه در اینجا حیاتی هستند:
- تأخیر (Latency): سرعت پاسخ‌دهی. وقتی این عقربه بالا می‌رود، محصول در نگاه کاربر کند و sluggish احساس می‌شود.
- توان عملیاتی (Throughput): میزان فشار روی سیستم (تعداد درخواست در ثانیه)، که بسیار شبیه به دور موتور (RPM) ماشین است.
- نرخ خطا (Error Rate): نشان می‌دهد سیستم چقدر داغ کرده است. این سهم سفرهایی است که با شکست پایان یافته‌اند و مانند یک درجه حرارت عمل می‌کند که به‌آرامی به سمت محدوده قرمز حرکت می‌کند.
هشدارها (Alerts) یا همان چراغ چک موتور: هشدارها محرک‌های خودکاری هستند که پیش از آنکه در شانه جاده متوقف شوید، به دنبال شما می‌آیند. شما یک حد تعیین می‌کنید (مثلاً «اگر نرخ خطاها از این خط رد شد به من هشدار بده») و وقتی خط دندانه‌دار شکست‌ها از خط قرمز و صافِ حد شما بالاتر رفت، یک انسان پیام دریافت می‌کند. تفاوت اینجاست که شما خرابی AI را از طریق یک چراغ هشدار می‌فهمید، نه از طریق یک مشتری عصبانی در توییتر (X).
نقش لاگ‌ها و استانداردهای باز
فراتر از این صفحات نمایش، لاگ‌ها (Logs) یادداشت‌های متنی ساده‌ای هستند که هر مرحله در حین کار از خود می‌نویسد. اگر ردیابی (Trace) نشان می‌دهد سیستم «کجا» شکست خورده است، لاگ‌ها «جمله دقیق» و متنی که باعث ایجاد آن شکست شده را فاش می‌کنند. در کنار هم، ردیابی‌ها، عقربه‌ها، چراغ‌های هشدار و لاگ‌ها، کیت کامل دیده‌سنجی را تشکیل می‌دهند.
در پیاده‌سازی این سیستم، مدیریت دسترسی به این داده‌های حساس اهمیت دارد؛ برای نمونه می‌توان به راهکار airCloset در 구축 استک دیده‌سنجی اشاره کرد که دسترسی امن عامل‌ها به لاگ‌ها را بدون افشای اطلاعات شخصی تضمین می‌کند.
استاندارد فنی زیربنایی که این قابلیت‌ها را ممکن می‌کند، OpenTelemetry است؛ یک چارچوب متن‌باز (Open-source) برای ضبط داده‌های تلمتری. پیاده‌سازی این سیستم نیازی به بازنویسی کامل کد ندارد. با استفاده از SigNoz (نسخه 0.133.0)، ابزاری متن‌باز برای دیده‌سنجی، نویسنده نشان داد که می‌توان یک داشبورد کامل را تنها در یک بعدازظهر راه‌اندازی کرد.
جزئیات پیاده‌سازی فنی
برای کسانی که درباره مکانیسم این کار کنجکاو هستند، این تنظیمات شامل چند گام مشخص با استفاده از بسته‌های پایتون OpenTelemetry (نسخه 0.65b0) است:
- زیرساخت: نصب SigNoz روی یک لپ‌تاپ با استفاده از نصب‌کننده مخصوص و یک فایل پیکربندی پنج خطی انجام شد. این کار از طریق دستور
curl -fsSL https://signoz.io/foundry.sh | bashو سپسfoundryctl cast -f casting.yamlصورت گرفت و باعث شد سیستم در آدرس http://localhost:8080 در دسترس قرار گیرد. - ابزارگذاری (Instrumentation): بخش بزرگی از ضبط داده‌ها به‌صورت خودکار است. با استفاده از یک پیشوند در دستور اجرا — ابتدا نصب بسته‌ها با
pip install opentelemetry-distro opentelemetry-exporter-otlp opentelemetry-bootstrap -a installو سپس اجرای برنامه باOTEL_SERVICE_NAME=ai-gateway opentelemetry-instrument python app.py— سرویس بدون نیاز به هیچ تغییری در کدهای برنامه، شروع به ارسال داده‌ها می‌کند. - برچسب‌گذاری سفارشی (Custom Tagging): برای عبور از توصیفات مبهم مثل «یک چیزی کند بود»، چند خط کد به‌صورت دستی اضافه شد تا هر فراخوانی با نام مدل و تعداد توکن (Token) — تکه‌های کوچکی از متن شبیه برش‌های کیک — برچسب بخورد. این کار ردیابی را متحول می‌کند تا فیلد
gen_ai.request.modelرا نشان دهد و دقیقاً مشخص کند کدام مدل (مثلاً llama-3-8b) عامل تأخیر است.
حل مشکل عامل‌های هوشمند (AI Agents)
وقتی به سمت عامل‌های (Agents) هوش مصنوعی می‌رویم، دیده‌سنجی از یک مزیت به یک ضرورت اجباری تبدیل می‌شود. وقتی یک عامل هوشمند پنج مرحله را طی می‌کند و در مرحله سوم به درون یک گودال می‌افتد، گفتن جمله‌ای مثل «عامل اشتباه کرد» برای عیب‌یابی کاملاً بی‌فایده است.
با داشتن دوربین داشبورد (ردیابی/Trace)، توسعه‌دهندگان می‌توانند دقیقاً ببینند کدام مرحله با شکست مواجه شد، ورودیِ خاص آن مرحله چه بود و سیستم چه مدت در آن نقطه متوقف ماند. بدون این عقربه‌ها، هر شکست تنها با یک شانه بالا انداختن پاسخ داده می‌شود؛ اما با آن‌ها، هر خطا یک نوار مشخص روی یک صفحه نمایش در یک زمان خاص است. در این حالت، شما دیگر درباره اینکه «چه اتفاقی افتاد» بحث نمی‌کنید، بلکه شروع به «تعمیر» آن می‌کنید.
برای صاحب کسب‌وکار، این تفاوت بین داشتن یک محصول پایدار و تجربه یک «هفته بد» ناشی از یک قطعی نامرئی است. اگر مهندسان شما ادعا می‌کنند که این یک پروژه سنگین و دشوار است، واقعیت این است که نصب داشبورد یک بعدازظهر زمان می‌برد، اما سود و بازده آن هر بعدازظهرِ بعد از آن تکرار می‌شود.
اگر در حال حاضر قابلیت‌های AI را در محیط عملیاتی (Production) اجرا می‌کنید، از لید فنی خود بپرسید آیا داشبورد تأخیر (Latency) و هشدارهای خطا پیکربندی شده است یا خیر. از منابعی مانند signoz.io و opentelemetry.io برای شروع استفاده کنید. اگر پاسخ آن‌ها این بود که «داریم بررسی‌اش می‌کنیم»، بدانید که هوش مصنوعی شما را در حال حاضر با چشم‌بند رانندگی می‌کند. پذیرش عبارت «این یک جعبه سیاه است» را به عنوان پاسخ متوقف کنید؛ چون واقعیت این است که لزوماً نباید اینطور باشد.
این تنها آغاز ماجراست؛ اثر موج‌گونه‌ی این تصمیم بر اکوسیستم متن‌باز و مدیریت هزینه‌ها را در گزارش بعدی بررسی خواهیم کرد.
گفتگو