وقتی شواهد کامل نیستند، تیم فنی چطور تصمیم بگیرد؟

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

تیم بی‌اطلاع نیست. نمودار معماری، چند ردپای نمونه، مستندات فروشنده، فهرست کارها، الزامات امنیتی و نظر افراد باتجربه را دارد. چیزی که ندارد شواهد کامل از رفتار سامانه در محیط عملیاتیِ متغیر است.

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

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

پیش از بحث معماری، یک «توافق‌نامه‌ی عدم‌قطعیت» بنویسید

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

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

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

سرعت را با هزینه‌ی تأخیر تنظیم کنید

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

دو بُعد را کنار هم بسنجید: پیامد انتخاب اشتباه و هزینه‌ی منتظر ماندن.

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

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

به‌جای نمایشِ اعتمادبه‌نفس، ادعاهای آزمون‌پذیر بسازید

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

عدم‌قطعیت را طوری بنویسید که بتوان بر اساسش کاری انجام داد:

1. ادعا را روشن کنید. مثلاً: «عامل برای بیشتر هشدارهای رایج، مالک خط لوله را درست تشخیص می‌دهد.»
2. شاهد را مشخص کنید. «در ۴۳ مورد از ۵۰ رخداد بازپخش‌شده از دو خانواده‌ی خط لوله موفق بود.»
3. مرز شواهد را بنویسید. «نمونه، مهاجرت شِما، اختلال منطقه‌ای و رخدادهای فاقد تبار داده را پوشش نمی‌دهد.»
4. بگویید چه چیزی نظرتان را عوض می‌کند. «خطای بیشتر در ترافیک زنده‌ی سایه یا تمرکز خطاها در یک تیم.»
5. اقدامی متناسب با فاصله‌ی شواهد انتخاب کنید. «تا پوشش موارد جامانده، عامل فقط پیشنهاد بدهد و اختیار اجرا نداشته باشد.»

بازه‌ها اغلب از یک پیش‌بینی تک‌عددی صادقانه‌ترند. اصلاح هر مورد شاید ۲۰ تا ۹۰ ثانیه وقت بگیرد. هزینه‌ی ماهانه‌ی مدل ممکن است به این بستگی داشته باشد که عامل دو بار ابزار را صدا بزند یا دوازده بار. میزان استفاده هم می‌تواند بین مهندس کشیک باتجربه و کسی که مسئول سرویس ناآشنایی شده، تفاوت زیادی داشته باشد. بازه راهی برای مبهم‌گویی نیست؛ نشان می‌دهد کدام فرض‌ها باعث گستردگی برآورد شده‌اند.

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

پیش از تعهد، برای به‌دست آوردن شواهد هزینه کنید

در شرایط نامطمئن، پایلوت نسخه‌ی کوچک‌شده‌ی راه‌اندازی نهایی نیست؛ راهی است برای خریدن اطلاعات.

این نگاه دامنه‌ی پایلوت را هم عوض می‌کند. به‌جای «می‌توانیم عاملِ کارآمدی بسازیم؟» بپرسیم: «کدام واقعیتِ نامعلوم آن‌قدر مهم است که پیش از دادن اختیار بیشتر باید بیازماییمش؟» نمونه‌ای که فقط مسیر بی‌دردسر را نشان دهد، شاید هیجان بسازد بی‌آن‌که ابهام مهمی را کم کند.

تیم رسیدگی به رخداد می‌تواند با چند آزمون محدود شواهد جمع کند:

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

راهنمای مهندسی قابلیت اطمینان گوگل درباره‌ی عرضه‌ی تدریجی نسخه‌ها (canary) نمونه‌ی روشنی از این اصل است. عرضه‌ی محدود و زمان‌دار کمک می‌کند بپرسیم آیا تغییر پذیرفتنی است، در حالی که تعداد کمتری از سامانه‌ها در معرض خطا قرار می‌گیرند. کوچک کردن دامنه به‌تنهایی کافی نیست: باید جمعیت نماینده، سنجه‌های مناسب، گروه مقایسه و واکنش لازم برای بازگشت را هم انتخاب کنیم.

در تدریس موضوع‌های فنی بارها دیده‌ام که یادگیری وقتی عمیق‌تر می‌شود که یادگیرنده از دستورالعمل کامل فاصله بگیرد و خودش یک خطای واقعی را بررسی کند. برای تیم‌ها هم همین‌طور است. ابهام زمانی به یادگیری تبدیل می‌شود که آن را به آزمونی بدل کنیم که حتی طراحانش را غافلگیر کند.

بهترین آزمایش بعدی معمولاً چشمگیرترین دمو نیست؛ کوچک‌ترین اقدام معتبری است که ممکن است تصمیم را عوض کند.

راه خروج را هم از ابتدا بنویسید

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

قواعد توقف را وقتی بنویسید که هنوز از نظر عاطفی برای پروژه هزینه‌ی زیادی نداده‌اید.

برای پایلوت چهار سرانجام در نظر بگیرید:

• گسترش: شواهد، استفاده در دامنه‌ی وسیع‌تر را توجیه می‌کند.
• بازنگری: هدف هنوز مهم است، اما یکی از فرض‌ها یا اجزای طراحی جواب نداده.
• مکث: ابتدا باید یک وابستگی تغییر کند تا آزمون بعدی ارزش داشته باشد.
• توقف: ارزش احتمالی دیگر هزینه یا میزان ریسک را توجیه نمی‌کند.

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

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

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

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

تصمیم‌های نرم‌افزاریِ معمول هم نامطمئن‌اند، اما سامانه‌های هوش مصنوعی امروز وسوسه‌ی خاصی دارند: یک اجرای موفق و روان ممکن است بیش از اندازه مدرک به نظر برسد.

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

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

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

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

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

پیش از نتیجه، خودِ تصمیم را مرور کنید

فرض کنید پایلوتِ فقط‌خواندنی نتیجه‌ی خوبی داده است. شاید تیم خودش را بابت تصمیم خوب تحسین کند. حالا فرض کنید هشدار نادری باعث تأخیری پرهزینه شده است. همان افراد ممکن است بگویند تأیید پایلوت بی‌ملاحظه بوده است. هیچ‌کدام از این قضاوت‌ها لزوماً منصفانه نیست.

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

دو بازبینی جدا انجام دهید.

بازبینی تصمیم را پس از تعهد و پیش از معلوم شدن نتیجه انجام دهید:

• آیا تصمیم را روشن صورت‌بندی کردیم؟
• آیا گزینه‌های معتبر را سنجیدیم؟
• آیا اقدام با پیامد و امکان بازگشت تناسب داشت؟
• آیا ابهام‌های مهم آشکار بودند؟
• آیا شواهد بعدی می‌توانست انتخاب را تغییر دهد؟
• آیا حق تصمیم‌گیری و مرز اختیار روشن بود؟

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

• چه اتفاقی افتاد و با چه بازه‌ای از انتظار مقایسه می‌شود؟
• کدام فرض‌ها تأیید یا رد شدند؟
• کدام نشانه غایب، گمراه‌کننده یا نادیده گرفته شد؟
• چه چیزی باید گسترش یابد، تغییر کند، مکث کند یا متوقف شود؟
• چه چیزی را باید در تصمیم بعدی حفظ یا بهتر کنیم؟

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

سند تصمیم را زنده نگه دارید، نه کاغذبازی را

سند تصمیم باید استدلال اولیه را نگه دارد، نه این‌که گذشته را طوری بازنویسی کند که انتخاب اجتناب‌ناپذیر به نظر برسد.

راهنمای سوابق تصمیم معماری در چارچوب Azure Well-Architected مایکروسافت در آوریل ۲۰۲۶ توصیه می‌کند زمینه، گزینه‌های جایگزین، موازنه‌ها، میزان اطمینان و وضعیت تصمیم ثبت شود. همچنین پیشنهاد می‌کند سابقه فقط به متن تازه افزوده شود: اگر تصمیم تغییر کرد، رکورد تازه‌ای بسازید که قبلی را کنار می‌زند؛ گذشته را ویرایش نکنید.

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

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

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

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

بازبینی عدم‌قطعیت در ۳۰ دقیقه

این چارچوب را می‌شود در یک جلسه‌ی متمرکز اجرا کرد:

• پنج دقیقه برای بیان تصمیم و تغییری که می‌خواهیم؛
• پنج دقیقه برای هزینه‌ی اشتباه و هزینه‌ی تأخیر؛
• ده دقیقه برای دو یا سه ابهامی که بیش از همه ممکن است انتخاب را عوض کنند؛
• پنج دقیقه برای انتخاب کوچک‌ترین آزمون معتبر؛
• پنج دقیقه‌ی پایانی برای تعیین حدود اختیار، شرط‌های خروج، مسئول و زمان بازبینی.

جلسه را با جمله‌ای تمام کنید که فرد بیرون از اتاق هم بفهمد:

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

اگر تیم نتواند چنین جمله‌ای بنویسد، احتمالاً پیش از تعریف تصمیم، وارد بحث فناوری شده است.

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

تصمیم مفید تصمیمی است که بتوان دوباره به آن برگشت

تصمیم‌گیری در شرایط نامطمئن، هنر مطمئن به‌نظر رسیدن نیست؛ انضباطِ روشن کردن ابهام‌هاست.

تیم فنیِ خوب می‌تواند توضیح دهد چه انتخابی کرده، چه انتظاری داشته، کدام فرض‌ها مهم بوده‌اند، چه میزان ریسکی را پذیرفته، برای چه شواهدی هزینه کرده و چه چیزی نظرش را عوض می‌کند. بعدتر هم می‌تواند استدلال را مرور کند، بی‌آن‌که وانمود کند نتیجه از ابتدا معلوم بوده است.

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