وقتی برنامهنویس اپراتور عامل میشود: هزینهٔ تأیید عادتوار
از ماشینهای دههٔ ۱۹۷۰ تا عاملهای هوش مصنوعی: عادیشدن تأیید، دشواری بازسازی تصمیمها پس از خرابی و نظارت انسانی معنادار.
عامل هوش مصنوعی تغییری پیشنهاد میکند. توضیحش منطقی به نظر میرسد. بررسیها موفقاند. تأیید میکنید. بعد تغییر بعدی را هم تأیید میکنید.
اتفاق چشمگیری نمیافتد. دقیقاً به همین دلیل، متوجه عادت شدن این کار نمیشویم. کمکم تأیید ممکن است از «این تصمیم را میفهمم» به «تصمیمهای قبلی جواب دادند» تبدیل شود.
این موضوع برای برنامهنویسان مهم است. ما ابزارهایی میسازیم که دیگران با آنها کار میکنند. با عاملهای هوش مصنوعی، بیشتر و بیشتر اپراتور ابزارهایی میشویم که به ساخت ابزارهای بعدی کمک میکنند. داریم وارد نقشی نظارتی میشویم که دشواریهایش خیلی پیش از هوش مصنوعی مولد شناخته شده بود.
مسئلهای آشنا، پنجاه سال بعد
سیستم IBM System/370 در سال ۱۹۷۰ برای کاربردهای تجاری و پردازش متمرکز معرفی شد. برنامهنویسی و ادارهٔ رایانه از همان زمان مسئولیتهای قابلتفکیکی بودند. تاریخچهٔ IBM
پردازش حقوق کارکنان روی یک رایانهٔ بزرگ آن دوره را تصور کنید. برنامه اجرا میشود، خروجی میآید و اپراتور پایان اجرا را بررسی میکند. پایان عادی اجرا بهتنهایی ثابت نمیکند که قواعد پرداخت یا دادههای ورودی درست بودهاند. این یک مثال توضیحی است، نه رویدادی مستند.
نمونهٔ فیزیکی هم وجود دارد. زیمنس معرفی کنترل عددی رایانهای SINUMERIK System 7 را به سال ۱۹۷۶ نسبت میدهد. تاریخچهٔ زیمنس
ماشینی برنامهریزیشده برای برش یک قطعه را در نظر بگیرید. حرکت در مسیر فرماندادهشده و ساخت قطعهٔ درست، دو پرسش متفاوتاند: تنظیمات، جنس مواد و دستورها همچنان مهماند. این هم یک تشبیه است، نه ادعایی دربارهٔ یک خرابی مشخص.
لیزان بینبریج در سال ۱۹۸۳ توضیح داد که خودکارسازی صنعتی میتواند مسئولیت شرایط غیرعادی را به انسان بسپارد و همزمان نقش او را دشوارتر کند. Ironies of Automation
درسی که من از این تاریخ میگیرم خوشایند نیست: موفقیت اجرای معمول، چیز زیادی دربارهٔ آمادگی فرد برای حل یک خرابی ناآشنا به ما نمیگوید.
سه راه برای تبدیل بررسی به تشریفات
یک نظریهٔ واحد و تثبیتشده به نام «اثر عادیشدن» همهٔ این مسئله را توضیح نمیدهد. سه مفهوم مرتبط به فهم آن کمک میکنند.
سوگیری خودکارسازی یعنی پذیرفتن توصیهٔ خودکار با وجود شواهد مخالف. آسودگی بیشازحد در برابر خودکارسازی یعنی کاهش توجه به سیستمی که قابلاعتماد فرض میشود. پژوهش ناسا
عادیشدن انحراف یعنی عدول از استانداردها، بر اثر تکرار بدون آسیب آشکار، پذیرفته شود. گفتوگوی ناسا
در توسعهٔ نرمافزار، اینها میتوانند سه لحظهٔ متفاوت باشند: اعتماد به خلاصهٔ آرامشبخش عامل در برابر تغییرات نگرانکنندهٔ کد؛ مرور تدریجی با توجه کمتر؛ و در نهایت پذیرفتن اینکه یک بازبینی الزامی مرتب کنار گذاشته شود. اینها کاربردهای احتمالی مفاهیماند، نه نتایج پژوهشی دربارهٔ همین روند کاری.
هر تأیید سریعی بیدقت نیست. آشنایی میتواند به قضاوت درست کمک کند. مسئله از جایی آغاز میشود که شواهد لازم برای تأیید، بیسروصدا از فرایند حذف میشوند.
- بازبینی — این تغییر را میفهمم.
- اطمینان — تغییرهای قبلی جواب دادند.
- عادت — تأیید بدون بازسازی چرایی تصمیم.
برنامهنویس، اپراتور هم میشود
اینکه بگوییم برای نخستین بار برنامهنویسان بر خودکارسازی نظارت میکنند، دقیق نیست. سیستمهای ساخت، فرایندهای استقرار و تولیدکنندههای کد نمونههای آشنایی هستند. نقش سازنده و اپراتور نیز دههها همپوشانی داشته است.
آنچه برای من عاملها را متمایز میکند، حجم پیادهسازی پیشنهادی میان دو مداخلهٔ ماست. عامل میتواند رویکرد انتخاب کند، چند فایل را تغییر دهد، خطایی را تفسیر کند و تغییر دیگری پیشنهاد دهد. ممکن است توسعهدهنده بخش بیشتری از جلسه را به بازبینی تصمیمهایی اختصاص دهد که خودش گامبهگام نگرفته است.
نگرانی من این است که توضیح روان، دستکم گرفتن این فاصله را آسان کند. خواندن توضیحی باورپذیر و فهمیدن پیامدهای آن دو دستاورد متفاوتاند. تخصص فنی همچنان ارزشمند است، اما به دسترسی به کار واقعی و زمان برای بررسی آن نیاز دارد.
وقتی خراب میشود، تصمیمهای قبلی برمیگردند
عاملی فرضی را تصور کنید که یک سرویس پردازش سفارش را بازآرایی میکند. مدیریت شناسهها را تغییر میدهد، تلاشهای مجدد را اصلاح میکند و بررسیها را بهروز میکند. توسعهدهنده پس از خواندن خلاصهها، مجموعهٔ تغییرات را تأیید میکند. بعداً مشکل ثبت سفارش تکراری بهصورت گاهبهگاه ظاهر میشود.
حالا پیدا کردن خط معیوب شاید فقط بخشی از کار باشد. چرا یک شناسه یکتا فرض شد؟ آیا هنگام تلاش مجدد حفظ میشد؟ آیا بررسیهای جدید هنوز رفتار اصلی را پوشش میدادند؟ کدام تغییر، فرضی را وارد کرد که این تصمیمها را به هم متصل میکرد؟
توسعهدهنده باید هم پیادهسازی و هم استدلال قابلمشاهده در پیشنهادها را بازسازی کند. اگر عامل یک بررسی را با رفتار غلط سازگار کرده باشد، موفقیت آن بررسی دیگر اطمینان مستقلی نمیدهد.
من این را فهمِ بهتعویقافتاده میبینم. زمان ذخیرهشده در پیادهسازی ممکن است هنگام بازیابی، صرف بازسازی زمینه شود. این یک نگرانی مهندسی است، نه ادعایی اندازهگیریشده که عاملها همیشه زمان بیشتری میگیرند. سابقهٔ خوب، تغییرهای کوچک و بررسی مستقل میتوانند بازسازی را بسیار آسانتر کنند.
- شناسه — «یکتا» دقیقاً چه معنایی داشت؟
- تلاش مجدد — آیا همان شناسه حفظ شد؟
- بررسی — آیا قاعدهٔ اصلی اعتبارسنجی شد؟
حضور انسان باید معنادار بماند
پیشنهاد من این است که نظارت را حول تصمیمهای دارای پیامد طراحی کنیم، بهجای اینکه هر اقدام را به یک درخواست تأیید دیگر تبدیل کنیم.
- تغییرها آنقدر کوچک باشند که بتوان توضیحشان داد. یک تغییر محدود و فرضهایش را تأیید کنیم، نه مجموعهای روبهرشد از اصلاحات نامرتبط.
- شواهد کنار پیشنهاد باشند. تفاوت کد، موارد بررسیشده، ابهامهای باقیمانده و تغییر در خود بررسیها نشان داده شوند.
- مرجعی مستقل حفظ شود. همان فرایندی که پیادهسازی را تولید میکند، نباید همهٔ نیازمندیها و بررسیهای موجود را بازنویسی کند.
- سابقهای برای بازیابی بماند. اقدامهای قابلمشاهده، نسخهها، پیشنهادها، نتایج و تأییدها ثبت شوند. توضیح عامل، ادعایی برای راستیآزمایی است؛ اثبات استدلال داخلی آن نیست.
- توقف واقعاً ممکن باشد. حدود دسترسی و نقاط بازیابی کاربردی تعیین شوند. استقلال و حجم کار با توان بازبین برای دنبال کردن کار متناسب باشند.
برای کار کمخطر و برگشتپذیر، اجرای خودکار محدود میتواند منطقی باشد. تصمیم دربارهٔ دسترسی، معنای داده یا بازیابی به توجه آگاهانه نیاز دارد. درخواست دائمی تأیید، خودش میتواند دکمه را به عادت تبدیل کند.
پژوهش دربارهٔ مداخلههایی که فرد را به بررسی فعال تصمیم وادار میکنند، نشان میدهد وابستگی بیشازحد میتواند کاهش یابد؛ اما این کار زحمت اضافه دارد و مشکل را کاملاً حذف نمیکند. بوچینکا و همکاران
- پیشنهاد و شواهد — تفاوت کد، فرضها و بررسی مستقل.
- قضاوت انسانی — پذیرش، اصلاح یا توقف.
- اجرای محدود — دامنهٔ کوچک، نقطهٔ بازیابی و سابقه.
سیستم تواناتر به تصمیمهای فهمپذیر نیاز دارد
طراحی با انسان در حلقه، نبود سوگیری را تضمین نمیکند. میتواند فرصت واقعبینانهای برای دیدن مشکل و مداخله فراهم کند. این فرصت به آنچه فرد میبیند، میفهمد و اجازهٔ تغییرش را دارد وابسته است.
به نظر من، خودکارسازی خوب باید توان ما برای توضیح اقدامها و بازیابی پس از آنها را حفظ کند. هرچه عاملها تواناتر میشوند، نظارت باید آگاهانهتر شود.
پیش از تأیید تغییر بعدی، میتوانید توضیح دهید چه چیزی را میپذیرید و اگر فردا خراب شد، از کجا شروع میکنید؟
