چرا تشخیص ناهنجاری در داده‌های بحران، جایگزین مناسبی برای حقیقت‌سنجی نیست؟

تصور کنید در اوج یک آتش‌سوزی گسترده، سیگنال‌های حیاتی برای تخلیه شهر توسط هوش مصنوعی به دلیل «غیرعادی بودن» مسدود شوند. این همان شکاف خطرناکی است که دیمیتریوس ایوانیدیس در پژوهش ۱۷ اکتبر ۲۰۲۶ خود با عنوان «تشخیص ناهنجاری (راستی‌آزمایی) داده‌های رسانه‌های اجتماعی در مدیریت بحران» به آن هشدار می‌دهد.

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

همان‌طور که در تحلیل قبلی ما درباره‌ی الزامات اتوماسیون هوش مصنوعی در کسب‌وکارها اشاره کردیم، این پژوهش بر یک مرز مهندسی حیاتی تأکید دارد. اکثر سامانه‌ها زمانی شکست می‌خورند که «سیگنال» — چیزی که متمایز است — را با «قضاوت» — چیزی که درست یا غلط است — یکی می‌گیرند. در یک وضعیت اضطراری، این اشتباه می‌تواند تفاوت بین تخلیه به‌موقع شهر و سرکوب یک هشدار حیاتی باشد.

تفاوت ناهنجاری و حقیقت

تشخیص ناهنجاری (Anomaly Detection) — شبیه نگهبانی است که هر صدای غیرعادی را گزارش می‌کند، بدون اینکه بداند این صدا صدای دزد است یا فقط باد است — مشاهداتی را شناسایی می‌کند که از الگوی مورد انتظار فاصله دارند. در رسانه‌های اجتماعی، این ناهنجاری می‌تواند به صورت زبان غیرمعمول، ترکیب نادر کلمات، تغییر ناگهانی در حجم فعالیت یا پستی ظاهر شود که تفاوت قابل‌توجهی با داده‌های اطراف خود دارد.

به نقل از ایوانیدیس، اگرچه این مشاهدات برای اولویت‌بندی مفید هستند (چون یک سیستم نظارتی نمی‌تواند هر پست را با عمق یکسانی بررسی کند)، اما «غیرعادی بودن» به معنای «کذب بودن» نیست. او فرآیندی را پیشنهاد می‌کند که از نظر متدولوژیک قابل دفاع‌تر است: ابتدا ناهنجاری تشخیص داده شود $\rightarrow$ برای بررسی اولویت‌بندی گردد $\rightarrow$ شواهد بررسی شوند $\rightarrow$ ادعا ارزیابی شود $\rightarrow$ و در صورت نیاز بازبینی گردد.

این تفکیک با پژوهش‌های پیشین چاندولا، بانرجی و کومار و همچنین شو و همکاران (۲۰۱۷) همسو است؛ آن‌ها تأکید می‌کنند که شناسایی مشاهدات غیرعادی و ارزیابی اینکه آیا یک ادعا توسط شواهد پشتیبانی می‌شود یا خیر، دو وظیفه کاملاً مجزا هستند. این رویکرد دقیق در ردیابی شواهد، یادآور قابلیت‌های سامانه Reality Check AI است که مسیرهای قابل‌تعقیبی برای اثبات ادعاهای هوش مصنوعی ایجاد می‌کند تا از قضاوت‌های کورکورانه جلوگیری شود.

معماری خط لوله ماژولار

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

مرحله ۱: جمع‌آوری و نرمال‌سازی داده‌ها

در این مرحله، تمرکز بر آماده‌سازی پست‌ها برای تحلیل است. طبق مستندات پژوهش، دو مسیر آزمایشی اصلی طی شده است:

• یک آزمایش کنترل‌شده با استفاده از مجموعه داده‌های توییتر مربوط به بلایا شامل ۲۵۵۹ ورودی و ۱۳ فیلد اصلی.
• یک نمونه اولیه با API مستودون (Mastodon) برای بررسی نحوه ورود پست‌های عمومی از یک پلتفرم اجتماعی فدرال به همان خط لوله پردازش.

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

مرحله ۲: شناسایی محتوای غیرعادی

در این مرحله، تشخیص ناهنجاری واقعی پیاده‌سازی می‌شود. این چارچوب چندین رویکرد ریاضی را برای یافتن داده‌های پرت (Outliers) ارزیابی کرد:

• کی-میانگین (K-Means) برای سازماندهی مشاهدات در خوشه‌ها.
• DBSCAN برای شناسایی ناهنجاری‌ها بر اساس تراکم.
• خودرمزگذارهای طیفی (Spectral Autoencoders) با استفاده از انحرافات مبتنی بر بازسازی.
• مدل ترکیبی DT-SVMNB که درخت تصمیم (Decision Trees)، ماشین بردار پشتیبان (SVM) و نایو بیز (Naïve Bayes) را ترکیب می‌کند.

این مدل‌ها متن‌ها را با استفاده از نمایش‌های ویژگی مختلف پردازش کردند. ماتریس‌های سند-ترم (DTM) و بردارهای TF-IDF بر الگوهای لغوی تأکید داشتند، در حالی که بردار‌های معنایی (Embedding) مدل برت (BERT) نمایش‌های معنایی زمینه‌ای را فراهم کردند. درس مهندسی در اینجا این است که عملکرد سیستم نه تنها به الگوریتم، بلکه به نحوه نمایش داده‌ها برای آن وظیفه خاص بستگی دارد.

شکاف تأیید و نتایج عملیاتی

پس از علامت‌گذاری یک پست به عنوان غیرعادی، آن پست وارد مرحله ۳ برای تحلیل معنایی و متمرکز بر تأیید می‌شود. در این مرحله از پردازش زبان طبیعی (NLP) برای طبقه‌بندی احساسات و عواطف استفاده می‌شود. اما پژوهش تأکید می‌کند که نه احساسات و نه شدت عاطفی، هیچ‌کدام حقیقت را ثابت نمی‌کنند؛ یک شاهد عینی ترسیده ممکن است دقیق باشد، در حالی که یک پیام با لحنی مطمئن می‌تواند کاملاً بی‌اساس باشد.

سپس یک تأییدکننده خودکار راستی‌آزمایی، ادعاها را در پنج برچسب خاص قرار می‌دهد:

• درست (True)
• غلط (False)
• تا حدی تأیید شده (Partially Supported)
• تا حدی تأیید نشده (Partially Not Supported)
• نامشخص (Unclear)

این ساختار تضمین می‌کند که «امتیاز ناهنجاری» حاصل از مرحله ۲ هرگز به‌طور خودکار «وضعیت تأیید» یک ادعا را تغییر ندهد.

نتایج آزمایش‌ها واقعیت تلخی را درباره قابلیت اطمینان هوش مصنوعی نشان داد. در آزمایش مجموعه داده‌های کنترل‌شده، مدل کی-میانگین با استفاده از بردار‌های BERT به امتیاز ROC-AUC برابر با ۰.۵۹ و PR-AUC برابر با ۰.۳۰ رسید. این امتیازات نشان‌دهنده توانایی تفکیک محدود است و ثابت می‌کند که داشتن یک خط لوله فنی فعال، لزوماً به معنای داشتن یک تشخیص‌دهنده عملیاتی قابل‌اعتماد نیست.

در مورد آزمایش مستودون، چارچوب با موفقیت پست‌های عمومی را دریافت و نرمال‌سازی کرد که امکان استقرار (Deployment) را ثابت کرد. با این حال، چون نمونه‌های مستودون فاقد برچسب‌های تأیید شده توسط انسان بودند، از برچسب‌های مرجع شبیه‌سازی شده برای تست جریان کاری استفاده شد. در نتیجه، این نتایج نباید به عنوان شواهد قطعی از دقت تأیید در دنیای واقعی تفسیر شوند.

مهندسی سامانه‌های قابل‌اعتماد

برای جلوگیری از تبدیل سیگنال‌های هوش مصنوعی به «سند»، پژوهش ساختار داده‌ای خاصی را به توسعه‌دهندگان پیشنهاد می‌دهد. با استفاده از کلاس ClaimAssessment در پایتون، می‌توان anomaly_score و verification_status را به عنوان فیلدهای مستقل ذخیره کرد.

یک طراحی نمونه به این شکل خواهد بود:

from dataclasses import dataclass, field
from typing import Literal

VerificationStatus = Literal[
    "not_assessed", "supported", "partially_supported", 
    "unclear", "partially_not_supported", "not_supported",
]

@dataclass
class ClaimAssessment:
    post_id: str
    anomaly_score: float | None = None
    verification_status: VerificationStatus = "not_assessed"
    evidence_refs: list[str] = field(default_factory=list)
    needs_human_review: bool = True

این طراحی صراحتاً برای عدم قطعیت جا باز می‌کند. به جای تحمیل برچسب دوتایی درست/غلط، سیستم می‌تواند ادعا را در صورت نبود شواهد کافی، «نامشخص» علامت بزند. برای تصمیمات با تأثیر بالا، پژوهشگر توصیه می‌کند که برچسب‌های زمانی (Timestamps)، منشأ منبع (Provenance) و سوابق اصلاحات بعدی نیز به این ساختار اضافه شوند.

ضرورت حضور انسان در چرخه

در نهایت، این پژوهش نتیجه می‌گیرد که طبقه‌بندی‌های ماشینی نباید به عنوان قضاوت نهایی پذیرفته شوند. در مدیریت بحران، هدف نباید حذف عدم قطعیت با برچسب‌های مطمئن باشد، بلکه باید عدم قطعیت را به‌گونه‌ای سازماندهی کرد که انسان‌ها بتوانند روی سوالات درست تحقیق کنند.

اگرچه این پایان‌نامه شامل یک مکانیزم بازخورد است، اما یک فرآیند کامل بازبینی توسط خبرگان را پیاده‌سازی نکرده است، که این موضوع یک مسیر حیاتی برای توسعه‌های آینده باقی می‌ماند. همچنین ارزیابی‌ها باید از دقت‌های سطح بالا فراتر روند؛ زمانی که موارد مثبت نادر هستند، رفتار PR-AUC و Precision-Recall برای درک اینکه چه تعداد از موارد مهم نادیده گرفته شده‌اند، اطلاعات بیشتری ارائه می‌دهند.

شفافیت در اینجا یک الزام مهندسی است، نه یک هدف کلی. توسعه‌دهندگان باید بپرسند:

• مدل دقیقاً چه چیزی را تشخیص داد؟
• چه شواهدی این ارزیابی را پشتیبانی می‌کند؟
• آیا منابع مستقل، به‌روز و مرتبط هستند؟
• چه کسی می‌تواند این تصمیم را بازبینی یا به چالش بکشد؟

این تغییر دیدگاه، هوش مصنوعی را از یک «ماشین حقیقت» به یک «ابزار اولویت‌بندی» تبدیل می‌کند. با جداسازی سیگنال از حکم، نهادها می‌توانند از ریسک‌های اعتباری و عملیاتی ناشی از اعتماد به نفس بیش از حد الگوریتم‌ها دوری کنند.

نتیجه‌گیری و مسیرهای آینده

رویکرد ماژولار ایوانیدیس نشان می‌دهد که مدل‌های مختلف باید وظایفی کاملاً تعریف‌شده را انجام دهند و خروجی‌های آن‌ها نباید با نتایجی که هنوز ثابت نشده‌اند، اشتباه گرفته شود. گام‌های پژوهشی آینده شامل اعتبارسنجی زنده در مقیاس بزرگتر، تحلیل‌های چندوجهی (Multimodal) و مبتنی بر گراف، و ارزیابی با متخصصان واقعی مدیریت بحران است.

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

گام بعدی شما

• اگر توسعه‌دهنده هستید، فیلدهای تشخیص ناهنجاری و تأیید حقیقت را در دیتابیس خود کاملاً مجزا کنید.
• در طراحی رابط کاربری (UI)، امتیاز ناهنجاری را به عنوان «نیاز به بررسی» نمایش دهید، نه به عنوان «احتمال دروغ بودن».
• برای سیستم‌های حساس، مکانیزم بازبینی انسانی (Human-in-the-loop) را به عنوان لایه نهایی تأیید قرار دهید.

اما این بحث تنها بخشی از چالش‌های قضاوت ماشینی است؛ برای درک عمیق‌تر مسئولیت نهادهایی که به الگوریتم‌ها تکیه می‌کنند، تحلیل ما درباره آینده قضاوت انسانی را بخوانید.