ارباب حلقه‌ها: حامل حلقه

در قسمت اول گفتم در حالت Human in the Loop، سیستم یک مرحله رو انجام می‌ده، منتظر تصمیم یا تأیید انسان می‌مونه و بعد ادامه می‌ده. اما پیاده‌سازی HITL فقط اضافه کردن یک دکمه Yes و No وسط workflow نیست.

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

مثلا اگر یک agent قراره نسخه جدید یک سرویس رو روی production دیپلوی کنه، باید target، نسخه دقیق artifact، نتیجه تست‌ها، محدوده اثر تغییر و مسیر rollback رو برای تأیید آماده کنه. approval هم باید به همین اطلاعات مشخص متصل باشه، نه به یک درخواست کلی برای deploy.

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

پس چیزی که برای تأیید به انسان نمایش داده می‌شه باید فشرده، کامل و مشخص باشه: چه کاری، روی کدوم target و artifact، به چه دلیلی، با چه نتیجه‌ای از تست‌ها، چه محدوده اثری و کدوم مسیر rollback. این اطلاعات بهتره ساخت‌یافته و در یک نگاه قابل‌بررسی باشن، نه اینکه وسط یک متن طولانی پنهان بشن. جزئیات کامل، logها و diffها هم باید در دسترس باشن، اما فقط وقتی reviewer به اون‌ها نیاز داره.

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

عبارت «Lu et approuvé» در فرانسه، «Okudum, anladım, onaylıyorum» در ترکیه و چیزی شبیه «مفاد سند را مطالعه کردم و از آثار آن مطلع شدم» در ایران همگی روی یک نکته تأکید دارن: خواندم، فهمیدم و تأیید می‌کنم. نگاه ما به approval در یک workflow حساس هم باید همین باشه. هویت تأییدکننده، موضوع و محدوده تصمیم و زمان تأیید باید ثبت بشه تا بعدا مشخص باشه چه کسی دقیقا چه چیزی رو پذیرفته.

از طرف دیگه، اگر انسان رو برای تأیید تک‌تک tool callها داخل حلقه بذاریم، خیلی زود به گلوگاه سیستم تبدیل می‌شه. بعد از مدتی هم احتمالا بدون بررسی روی Approve کلیک می‌کنه. یعنی در ظاهر HITL داریم، اما در عمل فقط یک مرحله دستی و قابل‌پیش‌بینی به workflow اضافه کردیم.

پس در یک HITL درست، انسان باید یک بخش واقعی از مسیر تصمیم‌گیری باشه، نه یک دکمه تزئینی یا تأییدکننده‌ای که بدون خوندن روی Approve کلیک می‌کنه. اگر نتونیم مشخص کنیم چه کسی، چه چیزی رو و برای کدوم نسخه تأیید کرده، هنوز حلقه قابل‌اعتمادی نساختیم.