Human-in-the-loop را کجا بگذاریم؟ طراحی بازبینی انسانی بدون گلوگاه

Human-in-the-loop چه چیزی را کنترل می‌کند؟

بازبینی انسانی می‌تواند چند نقش متفاوت داشته باشد و این نقش‌ها نباید با هم قاطی شوند:

ممکن است یک workflow برای کیفیت به review نیاز داشته باشد، اما برای هر بار اجرا نیازمند تأیید پیشینی نباشد. همچنین ممکن است نتیجه از نظر متن درست باشد ولی action آن به مجوز جداگانه نیاز داشته باشد. اعتماد کاربر در محصول AI توضیح می‌دهد که کنترل، شفافیت و مسیر اصلاح چگونه بخشی از تجربهٔ اعتماد هستند.

• بررسی کیفیت: آیا خروجی درست، کامل و قابل‌استفاده است؟
• بررسی context: آیا پاسخ با موقعیت کاربر و هدف محصول هم‌خوان است؟
• بررسی ریسک: آیا داده، حریم خصوصی، امنیت یا حقوق کسی در خطر است؟
• تأیید action: آیا سیستم مجاز است تغییر یا پیامی را اجرا کند؟
• یادگیری: خطا یا مورد مبهم را به dataset و بهبود workflow برگردانیم.

چهار عامل تعیین‌کنندهٔ جای review

۱. هزینهٔ خطا: اشتباه یک پیش‌نویس داخلی با اشتباه در پرداخت، قرارداد، دادهٔ شخصی یا تصمیم دربارهٔ فرد اثر یکسانی ندارد. هرچه پیامد خطا بیشتر باشد، review باید زودتر، دقیق‌تر و با اختیار توقف همراه شود.

فقط احتمال خطا را نبینید؛ شدت پیامد را هم ثبت کنید. یک خطای نادر اما پرهزینه می‌تواند از ده‌ها خطای کوچک مهم‌تر باشد. «مدل معمولاً خوب است» معیار کافی برای حذف review نیست.

۲. برگشت‌پذیری: اگر action به‌راحتی قابل‌برگشت است، می‌توان بخشی از کنترل را به پایش پسینی یا sampling سپرد. اگر تغییر به دادهٔ اصلی، مشتری، قرارداد یا محیط production آسیب می‌زند و بازگشت سخت است، تأیید پیشینی و ثبت تصمیم ارزش بیشتری دارد.

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

۳. امکان تشخیص خطا: برای برخی خروجی‌ها، خطا با rule یا تست خودکار قابل‌تشخیص است. برای برخی دیگر، باید context، لحن یا تناسب با هدف را انسانی بررسی کرد. اگر خطا دیر فهمیده می‌شود، review باید نزدیک‌تر به نقطهٔ تولید و اجرا باشد.

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

۴. حجم و ظرفیت review: اگر روزانه هزاران خروجی دارید و برای همهٔ آن‌ها یک نفر را می‌گذارید، گلوگاه را از قبل طراحی کرده‌اید. ظرفیت review باید مانند ظرفیت تیم، latency و هزینهٔ سرویس اندازه‌گیری شود.

این سؤال‌ها را بپرسید: هر reviewer چند مورد را با کیفیت مناسب بررسی می‌کند؟ صف review چقدر طول می‌کشد؟ چند تأیید بدون خواندن رخ می‌دهد؟ چند مورد حساس به‌دلیل فشار زمانی رد یا قبول شده‌اند؟ حجم بالا ممکن است نشانهٔ طراحی نادرست باشد، نه نیاز به استخدام reviewer بیشتر.

سه سطح عملی کنترل انسانی

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

نمونه‌برداری باید برنامه داشته باشد: چه درصدی، از کدام دسته، با چه فاصله‌ای و بر اساس کدام trigger؟ sampling تصادفی به‌تنهایی ممکن است خطای نادر اما حساس را پیدا نکند؛ دسته‌بندی ریسک و بررسی هدفمند هم لازم است.

سطح دوم: پیشنهاد AI و تأیید انسان: برای خروجی متوسط یا جایی که context مهم است، AI پیش‌نویس یا گزینه می‌دهد و انسان پیش از ارسال یا ثبت آن را بررسی می‌کند. انسان باید بتواند منبع، فرض‌ها و تغییرات را ببیند و با یک اصلاح کوچک خروجی را تغییر دهد.

این مدل برای پاسخ‌گویی، brief محصول، گزارش پروژه و تحلیل بازخورد مناسب است. اما اگر reviewer فقط دکمهٔ سبز را می‌زند، باید workflow را دوباره طراحی کنیم. تأیید باید همراه با اطلاعات کافی و زمان منطقی باشد.

سطح سوم: تأیید صریح پیش از action: برای تغییر حساس، تصمیم مالی، دادهٔ شخصی، دسترسی، انتشار عمومی یا تعهد زمانی و قراردادی، AI می‌تواند شواهد و گزینه‌ها را آماده کند، اما action باید تا تأیید مالک متوقف بماند.

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

چه زمانی human-in-the-loop گلوگاه می‌شود؟

همه‌چیز را با یک ریسک می‌بینیم: اگر خلاصهٔ داخلی و ارسال قرارداد هر دو وارد یک صف review شوند، ظرفیت تیم با موارد کم‌ارزش مصرف می‌شود. باید خروجی را بر اساس ریسک، برگشت‌پذیری، confidence و نوع action دسته‌بندی کرد.

خروجی برای بررسی قابل‌فهم نیست: Reviewer نباید متن خام، چند صفحه لاگ و یک دکمهٔ تأیید مبهم دریافت کند. منبع، تغییر مهم، دادهٔ استفاده‌شده، هشدار و پیشنهاد action بعدی را نزدیک خروجی قرار دهید. ارزیابی AI پیش از launch اهمیت سناریو و evidence را نشان می‌دهد.

معیار بازبینی نداریم: اگر reviewer نمی‌داند پاسخ خوب چیست، اختلاف‌ها زیاد می‌شوند و تأیید به سلیقه تبدیل می‌شود. برای هر دسته نمونهٔ مثبت، منفی، مرزی و خارج از دامنه بسازید و دستورالعمل کوتاه قضاوت بنویسید.

review هیچ بازخوردی به سیستم نمی‌دهد: اگر انسان هر روز همان خطاها را اصلاح می‌کند اما این اصلاح‌ها وارد prompt، rule، dataset یا workflow نمی‌شوند، review فقط هزینهٔ جاری است. چرخهٔ یادگیری باید مالک و زمان بازبینی داشته باشد.

اثر AI بر Agile و مدیریت پروژه

AI جای review را حذف نمی‌کند؛ محل و ماهیت آن را تغییر می‌دهد. وقتی AI artifact بیشتری تولید می‌کند، تیم باید به‌جای بررسی صرفِ حجم خروجی، کیفیت تصمیم و نتیجه را کنترل کند.

اگر review به تأیید همهٔ artifactهای AI تبدیل شود، سرعت جدید فقط صف جدیدی می‌سازد. نقشهٔ اتوماسیون workflow کمک می‌کند نقطهٔ واقعی تصمیم و انتظار را پیدا کنیم.

• در backlog: AI می‌تواند دسته‌بندی کند؛ انسان باید مسئله، اولویت و هزینهٔ فرصت را بسنجد.
• در planning: AI می‌تواند سناریو بسازد؛ تعهد زمانی و سطح ریسک نیازمند توافق انسانی است.
• در delivery: تولید کد و تست سریع‌تر می‌شود؛ review باید روی رفتار، امنیت، داده و Definition of Done تمرکز کند.
• در daily: گزارش خودکار ممکن است کافی باشد؛ انسان باید blocker و تصمیم بعدی را با context بررسی کند.
• در retrospective: AI الگوها را پیشنهاد می‌دهد؛ تیم علت و اقدام سیستمی را انتخاب می‌کند.

مثال فرضی: Agent پاسخ‌گویی با سه سطح کنترل

یک تیم پشتیبانی را در نظر بگیرید که Agent به دانش محصول و ابزار ticket دسترسی دارد. درخواست‌های عمومی و کم‌خطر، پاسخ پیشنهادی می‌گیرند و بخشی از آن‌ها پس از ارسال نمونه‌برداری می‌شوند. درخواست‌های مربوط به وضعیت سفارش، ابتدا اطلاعات را از API می‌خوانند و پاسخ برای تأیید کارشناس می‌رود. درخواست‌های پرداخت، قرارداد یا حذف داده از ابتدا به انسان منتقل می‌شوند و Agent فقط خلاصه و منبع را آماده می‌کند.

در این طراحی، انسان همه‌جا حضور دارد اما همیشه یک کار نمی‌کند. برای دستهٔ اول، پایش و sampling؛ برای دستهٔ دوم، review پیش از ارسال؛ و برای دستهٔ سوم، تصمیم و action انسانی. این تفکیک باعث می‌شود ظرفیت review روی جاهایی مصرف شود که واقعاً ارزش دارد.

این مثال فرضی است و هیچ نتیجهٔ کمی یا ادعای سازمانی ندارد. معیار موفقیت آن فقط کاهش زمان پاسخ نیست؛ باید خطای پرپیامد، نرخ اصلاح، زمان صف review، انتقال درست به انسان و کیفیت تجربه هم بررسی شود.

چطور یک review loop قابل‌مقیاس بسازیم؟

این loop باید سبک اما واقعی باشد. سند طولانی بدون owner و trigger، کنترل ایجاد نمی‌کند.

• همهٔ خروجی‌ها و actionها را بر اساس شدت پیامد و برگشت‌پذیری دسته‌بندی کنید.
• برای هر دسته سطح کنترل را تعیین کنید: sampling، تأیید انسانی یا توقف کامل.
• اطلاعات لازم برای review را کنار خروجی قرار دهید: منبع، فرض، تغییر و هشدار.
• معیار قضاوت، مثال‌های مرزی و مسئول هر تصمیم را ثبت کنید.
• ظرفیت صف، زمان review، نرخ تأیید، اصلاح و escalation را اندازه بگیرید.
• خطاهای تکراری را به rule، dataset، prompt، طراحی محصول یا آموزش تیم برگردانید.
• برای عبور از آستانهٔ خطا، هزینه یا نشت داده، شرط توقف و rollback تعیین کنید.
• سطح کنترل را با تغییر مدل، داده، provider، workflow یا دامنهٔ کار دوباره بازبینی کنید.

چک‌لیست طراحی Human-in-the-loop

• تصمیم یا actionی که review می‌شود دقیقاً چیست؟
• هزینهٔ خطا و شدت پیامد آن ثبت شده است؟
• action برگشت‌پذیر است و rollback واقعاً آزمایش شده؟
• سطح کنترل مناسب انتخاب شده: sampling، approval یا توقف؟
• reviewer منبع، context، تغییرات و معیار قضاوت را می‌بیند؟
• reviewer اختیار اصلاح، رد و escalation دارد؟
• صف review و ظرفیت انسانی اندازه‌گیری می‌شود؟
• تأیید صوری و بدون خواندن چگونه تشخیص داده می‌شود؟
• خطاهای تکراری به چرخهٔ بهبود برمی‌گردند؟
• برای خطای پرپیامد، نشت داده، هزینه یا latency شرط توقف داریم؟
• با تغییر مدل یا workflow، سطح نظارت دوباره بررسی می‌شود؟
• مسیر بازگشت به حالت دستی یا copilot روشن است؟

جمع‌بندی: انسان را در نقطهٔ ارزشمند قرار دهید

واقعیت عمومی: Human-in-the-loop حضور انسان در چرخهٔ بررسی، تصمیم، اصلاح یا توقف AI است. منابع رسمی OpenAI و Anthropic بر نظارت و checkpoint متناسب با ریسک تأکید می‌کنند، اما این به معنی تأیید دستی همهٔ خروجی‌ها نیست.

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

پیشنهاد حکیم: ریسک، برگشت‌پذیری، امکان تشخیص خطا و ظرفیت review را هم‌زمان ببینید. موارد کم‌خطر را با automation و sampling پوشش دهید، موارد متوسط را با پیشنهاد قابل‌بررسی جلو ببرید و actionهای حساس را تا تأیید مالک متوقف کنید. AI می‌تواند سرعت اجرا را بالا ببرد؛ مسئولیت تصمیم باید واضح‌تر شود، نه محوتر.

اثر AI بر این فرایند

AI در این فرایند هم خروجی تولید می‌کند و هم می‌تواند به triage، خلاصه‌سازی و کشف خطا کمک کند. نقش مناسب آن بیشتر augmentation است؛ یعنی بار بررسی را کم می‌کند، اما معیار، سطح ریسک و تصمیم نهایی را تعیین نمی‌کند. trade-off اصلی میان سرعت، پوشش review و هزینهٔ خطاست. معیار بازبینی باید نشان دهد با سطح کنترل انتخاب‌شده، خطاهای پرپیامد دیده می‌شوند، صف انسانی قابل‌مدیریت است و outcome بهتر شده است.

منابع اولیه برای بررسی

• راهنمای رسمی OpenAI دربارهٔ safety، moderation و human oversight: https://developers.openai.com/api/docs/guides/safety-best-practices — بررسی‌شده در 2026-09-14.
• راهنمای رسمی Anthropic دربارهٔ Agentها، checkpoint انسانی و شرط‌های توقف: https://www.anthropic.com/engineering/building-effective-agents — منتشرشده در 2024-12-19 و بررسی‌شده در 2026-09-14.