خطای ریاضی در هشدارها: چرا تشخیص‌های ۹۵٪ دقیق، ۹۹٪ مواقع اشتباه‌اند؟

تصور کنید ساعت ۲ صبح با صدای هشدار سیستم بیدار می‌شوید که یک «ناهنجاری در هزینه‌ها» را گزارش کرده است؛ احتمالاً ۹۹ بار از ۱۰۰ بار، این هشدار کاملاً اشتباه است. این تضاد ناشی از ضعف مدل نیست، بلکه یک قطعیت ریاضی به نام غفلت از نرخ پایه (Base Rate Neglect) است. وقتی رویدادی که رصد می‌کنید بسیار نادر است، احتمال پیشین (Prior Probability) بسیار مهم‌تر از حساسیت ابزار تشخیص شماست.

این تلهٔ شناختی منجر به «خستگی از هشدار» (Alert Fatigue) می‌شود؛ وضعیتی که در آن مهندسان پس از چند مورد هشدار کاذب، کانال‌های حیاتی را بی‌صدا (Mute) می‌کنند. روند به این شکل است: در سومین هشدار کاذب ساعت ۲ صبح، ابتدا خودِ هشدار بی‌صدا می‌شود. سپس کل کانال بی‌صدا می‌شود. در نهایت، وقتی یک حلقهٔ بی‌نهایت واقعی رخ می‌دهد، هیچ‌کس گوش نمی‌دهد چون ریاضیات این شکست را از پیش تضمین کرده بود. تیم شما تنبل نیست؛ بلکه منطق ریاضی این نتیجه را تقریباً حتمی می‌کند.

همان‌طور که در تحلیل قبلی ما درباره‌ی بهینه‌سازی بازیابی داده‌ها با pgvector اشاره کردیم، چالش فعلی از نحوه ذخیره‌سازی داده‌ها به نحوه نظارت بر عامل‌های هوش مصنوعی (AI Agents) — شبیه به کارمندانی دیجیتال که می‌توانند به‌طور مستقل تصمیم بگیرند و ابزارها را اجرا کنند — تغییر کرده است. در چشم‌انداز فعلی عامل‌های خودمختار LLM، یک حلقهٔ runaway (از کنترل خارج شده) می‌تواند بودجه ماهانه را در عرض چند ساعت ببلعد و هزینه یک هشدار نادیده گرفته شده را به شدت فاجعه‌بار کند.

ریاضیات هشدارهای کاذب

در سال ۱۹۷۸، پژوهشگران دانشکده پزشکی هاروارد ۶۰ نفر را با یک پرسش تک‌جمله‌ای مواجه کردند: بیماری‌ای وجود دارد که ۱ از هر ۱۰۰۰ نفر را colp می‌کند و تست تشخیص آن ۵٪ نرخ مثبت کاذب دارد. اگر تست یک بیمار مثبت شود، احتمال اینکه او واقعاً بیمار باشد چقدر است؟ رایج‌ترین پاسخ ۹۵٪ بود. اما پاسخ درست حدود ۲٪ است. تنها ۱۱ نفر از ۶۰ شرکت‌کننده توانستند پاسخ درست را بدهند.

اکنون در دنیای مهندسی، «بیماری» را با «حلقهٔ بی‌نهایت عامل» و «تست» را با «هشدار ناهنجاری هزینه‌ها در استک نظارتی شما» جایگزین کنید. منطق ریاضی یکسان است و شهود اشتباه ما نیز دقیقاً مشابه است. غفلت از نرخ پایه یعنی قضاوت درباره یک سیگنال بر اساس میزان دقت ظاهری آن، در حالی که نادیده می‌گیریم آن اتفاقی که مدل سعی در تشخیص آن دارد، چقدر نادر است. این چالش در بازرسی‌های حفاظتی نیز دیده می‌شود، جایی که بیش از نیمی از گزارش‌های خطای هوش مصنوعی صرفاً مثبت کاذب بودند و باعث ایجاد نویز در فرآیند توسعه شدند.

برای محاسبه دقت واقعی (Precision) — یعنی احتمال وقوع حادثه واقعی به شرط فعال شدن هشدار — می‌توان از منطق زیر (بر اساس قضیه بیز) استفاده کرد:

def precision(base_rate, sensitivity, false_positive_rate):
    """P(real incident | alert fired), via Bayes.""
    true_alerts = base_rate * sensitivity
    false_alerts = (1 - base_rate) * false_positive_rate
    return true_alerts / (true_alerts + false_alerts)

طبق بررسی‌های فنی در زیرساخت‌های هوش مصنوعی، اعداد تکان‌دهنده و تنبیه‌کننده هستند:

• حلقه‌های runaway: تقریباً ۱ مورد در هر ۲۰۰۰ ساعت فعالیت عامل رخ می‌دهد.
• صحت تشخیص‌دهنده: یک بررسی با صحت ۹۵٪ که هر ساعت اجرا شود، منجر به دقت (Precision) ۰.۰۰۹۴ (زیر ۱٪) می‌شود.
• نتیجه: تقریباً هر هشدار، صرف‌نظر از کیفیت مدل، نویز است.

درس‌هایی از Google Flu Trends

این شکست ساختاری در مقیاس جهانی در پروژه Google Flu Trends در سال ۲۰۰۹ رخ داد. طبق گزارشی در مجله Nature، گینزبرگ و همکارانش یک خط لوله (Pipeline) تحسین‌برانگیز ساختند که در آن ۵۰ میلیون عبارت جست‌وجوی کاندید را با داده‌های منطقه‌ای آنفولانزای مرکز کنترل بیماری‌ها (CDC) تطبیق دادند. آن‌ها ۴۵ عبارتی را که بهترین تطابق را داشتند نگه داشتند و به همبستگی میانگین ۰.۹۰ در داده‌های اعتبارسنجی رسیدند.

اما بین اوت ۲۰۱۱ تا سپتامبر ۲۰۱۳، این مدل در ۱۰۰ هفته از ۱۰۸ هفته، میزان آنفولانزا را بیش از حد پیش‌بینی کرد. در اوج سال ۲۰۱۲-۲۰۱۳، مدل تخمین زد که بیماری‌های شبه‌آنفولانزا حدود ۱۱٪ از بازدیدهای پزشکان در آمریکا را تشکیل می‌دهند، در حالی که عدد نهایی CDC حدود ۶٪ بود.

بر اساس تحلیل سال ۲۰۱۴ در مجله Science توسط لایزر، کندی، کینگ و وسپیگنانی، این شکست ناشی از «تکبر داده‌های بزرگ» (Big Data Hubris) و «دینامیک‌های الگوریتمی» بود. با جست‌وجو در ۵۰ میلیون گزینه، برندگان نهایی عمدتاً چیزهایی بودند که با فصل زمستان یا اخبار مربوط به آنفولانزا بالا و پایین می‌رفتند، نه لزوماً خودِ بیماری.

در میان امتیازآورترین‌ها، سیگنال واقعی نادر است و همبستگی تصادفی رایج است. یک همبستگی ۰.۹۰ که از طریق جست‌وجو در ۵۰ میلیون گزینه به دست آمده باشد، بسیار کمتر از یک همبستگی ۰.۹۰ که بر اساس یک فرضیه از پیش نوشته شده باشد، ارزش دارد. چون حجم جست‌وجو تابع «توجه» مردم است، یک چرخه خبری ترسناک می‌تواند تخمین‌ها را بدون بیمار شدن واقعی مردم بالا ببرد. شکست ساختاری اینجا بود که هیچ مکانیزمی وجود نداشت تا مدل را به حقیقتِ کند و خسته‌کننده (Ground Truth) بازگرداند.

کانون‌های پنهان غفلت از نرخ پایه

اگر تا به حال «شاخص‌های پیشرو» (Leading Indicators) را برای حوادث، از طریق همبستگی چندصد متریک با قطعی‌های گذشته استخراج کرده‌اید، نسخه‌ای کوچک از همین شکست را ساخته‌اید. این خطا در چندین داشبورد مهندسی رایج ظاهر می‌شود:

• هشدارهای ناهنجاری: اگر رویداد نادر باشد و بازه بررسی کوتاه، تقریباً هر هشدار مثبت کاذب است، هرچقدر هم که مدل خوب باشد.
• تست‌های A/B: فرض کنید ۱ از هر ۱۰ آزمایش شما اثر واقعی داشته باشد و شما تست را با سطح خطای $\alpha = 0.05$ و توان ۸۰٪ اجرا کنید. در این حالت دقت ۰.۶۴ است. یعنی بیش از یک‌سوم بردهای آماری شما صرفاً نویز هستند و اکنون برخی از آن‌ها در محیط Production قرار گرفته‌اند. این تضاد میان معیارهای ظاهری و واقعیت عملی، مشابه بحرانی است که در ناپدید شدن استراتژی‌های نمونه‌گیری به دلیل تکیه بر معیارهای حریصانه در RLVR مشاهده کردیم.
• پنل‌های خطا: ۲۰۰ نقطه انتهایی (Endpoint) را در یک شبکه قرار دهید که هر کدام ۵٪ شانس داشته باشند که بر اساس شانس از آستانه خود عبور کنند. در هر بررسی حدود ۱۰ تایل قرمز خواهید دید و یک نفر باید هر یک از آن‌ها را بررسی کند.

چرخش به سمت اجرای پیش‌پرواز

راهکار این است که مهندسان به‌جای پیش‌بینی شکست، آن را غیرممکن کنند. برای هزینه‌های مدل زبانی بزرگ (LLM) — مثل موتورهای متنی که بر اساس احتمالات کلمه بعدی را حدس می‌زنند — باید تشخیص‌دهنده‌ها را با «بررسی بودجه پیش‌پرواز» (Pre-flight Budget Check) جایگزین کرد. این روش مشکلی با نرخ پایه ندارد چون حدس نمی‌زند که آیا یک حلقه runaway است یا خیر.

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

• هشدار بودجه / صورت‌حساب: پس از ثبت هزینه فعال می‌شود (اغلب با تأخیر چند ساعته). این روش نمی‌تواند هزینه‌های صرف شده بین رسیدن به آستانه و زمان خواندن ایمیل توسط انسان را متوقف کند.
• تشخیص‌دهنده ناهنجاری: بر اساس انحراف آماری فعال می‌شود. شکست می‌خورد چون حوادث واقعی زیر کوهی از هشدارهای کاذب دفن شده‌اند، یا افزایش‌های کند هزینه هرگز ناهنجار به نظر نمی‌رسند.
• محدودیت نرخ (Rate Limit): وقتی تعداد درخواست در دقیقه زیاد شود فعال می‌شود. اما نمی‌تواند یک حلقه کند (زیر حد مجاز) را که تمام آخر هفته اجرا می‌شود یا چند فراخوانی بسیار گران‌قیمت را متوقف کند.
• اجرای پیش‌پرواز: قبل از ارسال درخواست فعال می‌شود. تنها در صورتی شکست می‌خورد که هزینه را کمتر از حد واقعی تخمین زده باشید یا محدودیت‌های max_tokens تعریف نشده باشند.

برای اجرای این مدل در محیط‌های هم‌زمان (Concurrent)، سیستم باید از «رزروهای اتمیک» استفاده کند. یک گارد مبتنی بر قفل (Lock) می‌تواند حداکثر هزینه ممکن (تعداد توکن‌های ورودی $\times$ قیمت + حداکثر توکن‌های خروجی $\times$ قیمت) را پیش از ارسال فراخوانی رزرو کند. پس از بازگشت پاسخ، رزرو بر اساس مصرف واقعی تسویه شده و مبلغ استفاده نشده به استخر بودجه برگردانده می‌شود.

بدون این رزرو، ۲۰ عامل موازی ممکن است هم‌زمان مبلغ مصرف شده را بخوانند، عدد قدیمی (Stale) را ببینند، تصمیم بگیرند که هنوز زیر سقف بودجه هستند و با هم سقف بودجه را بشکنند. ادغام «بررسی» و «ادعا» در یک گام اتمیک، این شکاف را می‌بندد.

برای کارگران توزیع شده (Distributed Workers)، این رزرو باید در یک ذخیره‌ساز اتمیک مشترک باشد، مانند یک اسکریپت Lua در Redis یا یک دستور خاص در Postgres مانند UPDATE ... WHERE spent + reserved + $1 <= cap. ابزارهایی مانند baar-core این قابلیت را به‌صورت کتابخانه متن‌باز فراهم می‌کنند تا خطای ۴۰۲ قبل از تماس با ارائه‌دهنده صادر شود. همچنین noburn.dev برای محصولات SaaS، این محدودیت را در سطح کاربر پیاده کرده است تا فراخوانی‌های API کاربر را به محض عبور از بودجه مسدود کند.

بازتعریف نقش هشدار

تشخیص‌دهنده‌های احتمالی بی‌فایده نیستند، اما محافظان ضعیفی هستند. یک تشخیص‌دهنده با دقت ۱٪، یک ابزار تشخیصی مفید است: به شما می‌گوید وقتی «از قبل در حال جست‌وجو هستید»، کجا را نگاه کنید. اما به عنوان ابزار حفاظتی بی‌فایده است، زیرا افرادی که قرار است از آن‌ها محافظت کنید، یاد گرفته‌اند آن را نادیده بگیرند. این نادیده گرفتن سیستماتیک داده‌ها، یادآور مشکل حجم حافظه در سیستم‌های بازیابی است که در آن ۹۷٪ داده‌های بازیابی‌شده توسط هوش مصنوعی نادیده گرفته می‌شوند.

محدودیت‌های سخت (Hard Constraints) باید در جایی قرار گیرند که اشتباه کردن گران تمام می‌شود. سیگنال‌های احتمالی باید به داشبوردهایی منتقل شوند که اشتباه در آن‌ها فقط هزینه یک نگاه کوتاه را دارد. پیش از عرضه هر هشدار جدید، تیم‌ها باید دقت را با استفاده از یک نرخ پایه صادقانه محاسبه کنند؛ اگر نتیجه زیر ۱۰٪ است، آن هشدار نباید روی Pager (سیستم بیدارباش) باشد.

اگر نمی‌توانید نرخ پایه یک حادثه را تخمین بزنید، نمی‌توانید هشدار آن را تفسیر کنید. گوگل ۵۰ میلیون پرس‌وجو و همبستگی ۰.۹۰ داشت و باز هم فراموش کرد بپرسد که مورد واقعی چقدر نادر است. اکثر ما بهانه‌های کمتر و داده‌های بسیار کمتری داریم. آیا کسی در تیم شما تا به حال دقت واقعی پرنویزترین هشدار On-call خود را محاسبه کرده است؟ آن عدد چه بود؟

گام بعدی شما

• برای هر هشدار حساس در سیستم خود، نرخ پایه (Base Rate) رویداد را تخمین بزنید و دقت واقعی (Precision) را محاسبه کنید.
• اگر دقت هشدار زیر ۱۰٪ است، آن را از سیستم Pager (بیدارباش) حذف کرده و به داشبورد منتقل کنید.
• برای کنترل هزینه‌های API، به‌جای تکیه بر هشدارها، مکانیزم رزرو بودجه اتمیک (Atomic Budget Reservation) را در لایه Middleware پیاده کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.