خستگی شناختی؛ دلیل شکست نظارت انسانی در سیستم‌های هوش مصنوعی

تصور کنید یک بازبین انسانی در بعدازظهر سه‌شنبه با صف ۳۴۰ مورد منتظر تایید مواجه است؛ در این لحظه او دیگر یک توری ایمنی نیست، بلکه گلوگاهی است که فقط روی دکمه تایید کلیک می‌کند. طبق گزارشی که در ۱۲ اکتبر ۲۰۲۶ در وب‌سایت dev.to منتشر شد، معماری «انسان در حلقه» (Human-in-the-loop یا HITL) اغلب شکست می‌خورد چون با توجه انسان به عنوان یک منبع نامحدود برخورد می‌کند، در حالی که توجه، کمیاب‌ترین دارایی در کل خط تولید است.

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

زمینه و بستر توجه

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

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

برای حل این مشکل، Cyclopt پیشنهاد می‌کند از ارسال تمام خروجی‌ها به انسان فاصله بگیرید. به جای آن، توسعه‌دهندگان باید منطق مسیریابی را پیاده کنند که فقط بر اساس دو عامل موارد را ارجاع دهد: اقدامات با تاثیر بالا یا سطح اطمینان پایین مدل. برای مثال، یک مدل طبقه‌بندی فاکتور که ۹۷٪ صحت دارد، می‌تواند ۳٪ خطاهای خود را در میان صدها مورد درست دفن کند و بازبین را آموزش دهد که صرفاً دکمه «تایید» را بزند. این چالش در محیط‌های توسعه نرم‌افزار بسیار شدیدتر است، جایی که حجم بالای کدهای تولید شده توسط هوش مصنوعی بازبین‌ها را دچار فرسودگی می‌کند.

چهار حالت شکست اصلی

• مسیریابی کور (Blind Routing): ارسال همه موارد به بررسی، به انسان یاد می‌دهد که تایید، پاسخ مورد انتظار است. در صفی از ۳۰۰ فاکتور، حدود ۹ مورد غلط هستند، اما این موارد در میان ۲۹۱ مورد مشابه و درست گم می‌شوند. پس از دو هفته، نرخ اصلاح (Override rate) به نزدیکی صفر می‌رسد چون انسان دیگر نگاه نمی‌کند.
• شکاف‌های استدلالی (Reasoning Gaps): صفحاتی که فقط جواب مدل را نشان می‌دهند، کاربر را مجبور می‌کنند یا کار را از صفر انجام دهد یا کورکورانه اعتماد کند. برای مثال، ابزاری که درآمد سالانه را «۸۴,۰۰۰ دلار» تشخیص داده، اما بازبین را مجبور می‌کند برای تایید، یک فایل PDF ۲۲ صفحه‌ای را دستی جست‌وجو کند. تحت فشار زمان، کاربر در نهایت بررسی را متوقف می‌کند.
• اصلاحات دشوار (Friction-Heavy Overrides): اگر رد کردن یک پاسخ نیاز به پر کردن فرمی شش‌مرحله‌ای داشته باشد اما تایید فقط یک کلیک باشد، سیستم برای تایید طراحی شده، نه تایید صحت. مسیر اصلاح باید به اندازه مسیر تایید «ارزان» باشد: یک اقدام برای اصلاح و یک دلیل کوتاه اختیاری.
• معیارهای نامرئی (Invisible Metrics): عدم ردیابی زمان هر بررسی (Time-per-review) یا نرخ اصلاح، باعث می‌شود تیم‌ها متوجه خاموش شدن حلقه انسانی نشوند. بدون تله‌متری (Telemetry)، هیچ راهی برای دانستن اینکه آیا حلقه واقعاً در حال عملکرد است یا خیر، وجود ندارد.

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

جزئیات پیاده‌سازی

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

• تاثیر بالا: اگر impact == "high" باشد، بدون توجه به سطح اطمینان، مورد را همیشه به human_review بفرستید.
• اطمینان پایین: اگر confidence < CONFIDENCE_THRESHOLD بود، مورد را به human_review بفرستید.
• نمونه‌برداری بازرسی: برای سایر موارد، از یک نرخ تصادفی (مثلاً random.random() < AUDIT_SAMPLE_RATE) استفاده کنید تا موارد به audit_queue بروند و بررسی شود که آیا آستانه‌ها هنوز درست هستند یا خیر.

دو نکته حیاتی در اینجا وجود دارد. اول اینکه امتیازات خام اطمینان اغلب کالیبره (Calibration) نیستند؛ به این معنا که مدل‌ها می‌توانند با اطمینان کامل اشتباه کنند. بنابراین، کالیبراسیون باید روی داده‌های کنار گذاشته شده (Held-out data) بررسی شود. دوم اینکه نمونه‌برداری بازرسی تنها راه کشف این است که آیا آستانه تعیین‌شده هنوز دقیق است یا خیر.

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

برای کسانی که هوش مصنوعی را در محیط عملیاتی مدیریت می‌کنند، حیاتی‌ترین مجموعه داده، لاگ اصلاحات (Overrides) است. هر اصلاح باید همراه با خروجی اصلی، نسخه تصحیح شده و برچسب زمانی ثبت شود. این لاگ دقیقاً نشان می‌دهد مدل کجا شکست می‌خورد و آیا آستانه‌های اطمینان درست تنظیم شده‌اند یا خیر. بدون این داده‌ها، «انسان در حلقه» صرفاً یک برچسب برای رعایت قوانین (Compliance label) است، نه یک مکانیسم ایمنی کاربردی.

گام بعدی شما

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

• صف‌های بررسی خود را ممیزی کنید: نرخ اصلاح فعلی شما چقدر است؟
• بررسی کنید آیا تله‌متری لازم برای تشخیص اینکه بازبین‌ها واقعاً خروجی‌ها را می‌خوانند یا خیر، دارید؟
• مسیر اصلاح (Override) را در رابط کاربری ساده کنید تا هزینه زمانی آن با تایید برابر شود.

اما داستان سخت‌افزاری مدیریت این حجم از داده‌های نظارتی حتی پیچیده‌تر است — به تحلیل ما درباره‌ی بهینه‌سازی حافظه در استنتاج مدل‌ها مراجعه کنید.