انسان در حلقه برای قابلیت‌های هوش مصنوعی

«انسان در حلقه» (human in the loop) یعنی برای بعضی خروجی‌ها یا اقدام‌های هوش مصنوعی، انسان پیش از اثر، نگاه می‌کند، تأیید یا اصلاح می‌کند و می‌تواند متوقف کند. این شعار تا وقتی جزئیاتش طراحی نشود امنیت نمی‌سازد: چه چیزی بازبینی شود؟ ناظر چه اطلاعاتی می‌بیند؟ اگر بی‌توجه تأیید کند چه؟ این مقاله چهار سطح ریسک، الگوهای بازبینی، override و ثبت تصمیم را با تکیه بر ماده ۱۴ قانون هوش مصنوعی اتحادیه اروپا و چارچوب NIST شرح می‌دهد.

قبل از شروع، محدودیت مرجع: ماده ۱۴ مقرره‌ای اروپایی و دربارهٔ «سامانه‌های پرخطر» است و برای ایران لازم‌الاجرا نیست؛ ما آن را فقط به‌عنوان مرجع طراحی به‌کار می‌بریم و ادعای الزام حقوقی نداریم. صفحهٔ NIST هم چارچوبی داوطلبانه است که در زمان مطالعه (۱۹ اکتبر ۲۰۲۶) از بازنگری‌اش خبر می‌داد. دسته‌بندی چهارسطحی و الگوها توصیهٔ نویسنده‌اند. برای هم‌ترازی با تجربهٔ کاربر UX چیست را ببینید.

سطح ریسک: بازبینی چقدر لازم است؟

ماده ۱۴ تأکید می‌کند اقدامات نظارت باید متناسب با ریسک، سطح خودمختاری و بافت استفاده باشند. هر قابلیت را بر مبنای «هزینهٔ خطا» و «برگشت‌پذیری» دسته‌بندی کنید (توصیهٔ نویسنده):

الگوهای طراحی

• تأیید پیش از اجرا: مدل پیش‌نویس می‌دهد، انسان دکمهٔ تأیید می‌زند.
• تأیید استثنایی: اگر مدل «اطمینان» پایین یا needs_human اعلام کرد، به صف انسانی می‌رود. (نکته: اطمینان اعلامی مدل لزوماً کالیبره نیست؛ آن را با ارزیابی بسنجید.)
• نمونه‌گیری و حسابرسی: بخشی از تصمیم‌های خودکار پس از اجرا بازبینی می‌شود.
• واگرد: هر اقدام قابل‌برگشت، با ثبت اینکه چه کسی و چرا برگرداند.

ناظر چه چیزی باید بتواند؟

ماده ۱۴ فهرست توانایی‌هایی را می‌آورد که ناظر باید داشته باشد. آن را به نیازمندی محصول ترجمه کنید:

خطر اصلی automation bias است: ناظر کم‌کم همه‌چیز را تأیید می‌کند. پیشنهاد (نویسنده): صف بازبینی را بیش از حد طولانی نکنید، موارد سخت را برجسته کنید، گاهی موارد شناخته‌شده‌ٔ غلط (نمونهٔ آزمایشی) وارد صف کنید تا توجه سنجیده شود و نرخ تأیید و زمان بازبینی را پایش کنید؛ زمان تأیید چند ثانیه‌ای برای کار پیچیده علامت هشدار است.

override و توقف

انسان باید بتواند خروجی را رد یا اصلاح کند و بقیهٔ فرایند ادامه یابد (مسیر دستی). علاوه بر آن به «توقف» کل قابلیت نیاز دارید: پرچم قابلیت (feature flag) که بدون استقرار دوباره آن را خاموش کند و فرایند به حالت ایمن برگردد؛ ماده ۱۴ از «دکمهٔ توقف یا رویهٔ مشابه» با رسیدن به حالت ایمن سخن می‌گوید. آزمون کنید خاموش‌کردن چه می‌کند: صف انسانی پر می‌شود؟ کار نیمه‌تمام چه می‌شود؟

ثبت تصمیم

برای هر مورد این‌ها را ثبت کنید (توصیهٔ نویسنده): ورودی (یا مرجع آن با رعایت حریم خصوصی)، نسخهٔ مدل و prompt، خروجی مدل، تصمیم انسان (تأیید، اصلاح، رد)، دلیل، شناسهٔ ناظر و زمان‌ها. این داده‌ها هم برای حسابرسی هستند و هم برای بهبود: مواردی که انسان اصلاح می‌کند بهترین مجموعهٔ ارزیابی و آموزش آینده‌اند. سیاست نگه‌داری و دسترسی به این لاگ را با توجه به داده شخصی بسنجید؛ قوانین ایران را بررسی نکرده‌ایم.

مثال ساختگی: بازپرداخت

1. مدل درخواست را می‌خواند و پیشنهاد می‌دهد: «بازپرداخت کامل — کالا مطابق سیاست آسیب‌دیده».
2. مبلغ زیر آستانهٔ کم و سابقهٔ مشتری عادی: اجرا با امکان واگرد و نمونه‌گیری ۱۰٪ بعد از اجرا (عدد فرضی).
3. مبلغ بالا: صف انسانی؛ ناظر عکس و سیاست و پاسخ مدل را کنار هم می‌بیند و می‌تواند رد کند.
4. ناظر «رد» می‌زند و دلیل را می‌نویسد؛ مورد به مجموعهٔ ارزیابی اضافه می‌شود.
5. اگر نرخ خطا از آستانه گذشت، قابلیت با پرچم خاموش می‌شود و همه چیز دستی می‌گردد.

سنجش کارایی حلقهٔ انسانی

• نرخ اصلاح/رد توسط انسان (اگر صفر است، شاید ناظر نگاه نمی‌کند).
• زمان بازبینی و طول صف.
• موارد خطای واردشده به تولید با وجود بازبینی.
• تعداد دفعات استفادهٔ دکمهٔ توقف و بازگشت.

NIST AI RMF نیز تأکید می‌کند ملاحظات اعتمادپذیری باید در طراحی، توسعه، استفاده و ارزیابی وارد شوند؛ حلقهٔ انسانی یکی از ابزارهای آن است و نه جایگزین ارزیابی و پایش. دسترس‌پذیری رابط بازبینی هم مهم است (Accessibility).

نقش‌ها و مسئولیت

حلقهٔ انسانی بدون صاحب کار نمی‌کند. سه نقش را مشخص کنید (توصیهٔ نویسنده): ناظر که موارد صف را تأیید یا رد می‌کند و آموزش دیده است؛ مالک قابلیت که آستانه‌ها، سطح ریسک و پرچم توقف را تعیین می‌کند؛ و مسئول بازبینی دوره‌ای که نمونه‌های تأییدشده را بررسی و روند خطا را گزارش می‌کند. اگر ناظر فقط یک نفر است، مرخصی او کل فرایند را متوقف می‌کند؛ جانشین و ساعت کاری صف را از اول تعیین کنید. ناظر باید بداند چه زمانی بالادست را خبر کند و حق دارد بدون توجیه طولانی «رد» بزند؛ اگر رد کردن سخت‌تر از تأیید باشد، سامانه عملاً بی‌نظارت می‌شود.

چه چیزهایی را خودکار نکنیم؟

• اقدام‌هایی که برگشت‌ناپذیرند یا به شخص مشخصی آسیب می‌زنند (مثل رد درخواست او یا پرداخت بزرگ)، مگر با تأیید انسان.
• تصمیم‌هایی که قانون یا قرارداد انسان را مسئول می‌داند؛ این را با مشاور حقوقی خودتان بسنجید، چون ما قوانین ایران را بررسی نکرده‌ایم.
• خروجی‌ای که ناظر نمی‌تواند راستی‌آزمایی کند چون شواهدش نمایش داده نمی‌شود.
• هر قابلیتی که هنوز مجموعهٔ ارزیابی و نرخ خطای اندازه‌گیری‌شده ندارد.

اشتباهات رایج

• دکمهٔ تأیید بدون نمایش شواهد.
• همه‌چیز را بازبینی‌کردن و فرسودن ناظر.
• تکیه بر «اطمینان» اعلامی مدل بدون کالیبراسیون.
• نداشتن مسیر دستی و کلید توقف.
• ثبت نکردن دلیل تصمیم و بازخورد.
• تعریف نکردن اینکه مسئول نهایی کیست.

چک‌لیست

1. هر قابلیت بر اساس هزینهٔ خطا و برگشت‌پذیری در یکی از چهار سطح قرار گرفته است.
2. برای سطح ۳ و ۴ تأیید انسان پیش از اجرا وجود دارد.
3. ناظر شواهد، منبع و نسخهٔ مدل را می‌بیند.
4. راه رد، اصلاح و مسیر دستی وجود دارد.
5. پرچم توقف قابلیت آزموده شده است.
6. تصمیم و دلیل ثبت می‌شود و به ارزیابی بازمی‌گردد.
7. نرخ تأیید، رد و زمان بازبینی پایش می‌شود.
8. مالک مسئولیت نهایی مشخص است.

برای برنامه‌ریزی تصمیم‌ها پیش از ساخت برنامه‌ریزی پروژه نرم‌افزاری را ببینید.

منابع و مراجع

• Article 14: Human Oversight (EU Artificial Intelligence Act) — artificialintelligenceact.eu (Future of Life Institute).
• AI Risk Management Framework — NIST، 2023-01-26.