«می‌خواهیم هوش مصنوعی داشته باشیم» یک تصمیم دربارهٔ ابزار است، نه تعریف مسئله. ممکن است پشت این جمله، انبوه پیام‌های بی‌پاسخ، جست‌وجوی دشوار اسناد یا فشار تولید محتوا باشد. این‌ها یک مسئله نیستند و یک نوع پاسخ هم نمی‌خواهند. کاربرد ارزشمند از جایی شروع می‌شود که بدانیم چه کسی، در چه لحظه‌ای و برای چه کاری به کمک نیاز دارد؛ بعد می‌توانیم دربارهٔ مدل صحبت کنیم.
کار مشخص را از آرزوی کلی جدا کنیم
فرض کنید یک مجموعه می‌خواهد پاسخ‌گویی به مشتری را بهتر کند. «ساخت دستیار هوشمند» هنوز روشن نمی‌کند مشکل کجاست. شاید کارشناس به اطلاعات محصول دسترسی ندارد؛ شاید قواعد بازگشت کالا مبهم‌اند؛ شاید پاسخ‌های تکراری وقت می‌گیرند. یک هدف محدودتر می‌تواند یافتن پیش‌نویس پاسخ از اسناد تأییدشده باشد، با تصمیم نهایی کارشناس. این یک مثال فرضی است، نه گزارش نتیجهٔ پروژه.
بخش MAP در چارچوب داوطلبانهٔ NIST، روشن‌کردن زمینهٔ استفاده، هدف و ارزش کسب‌وکار را مطرح می‌کند. پیشنهاد عملی این نوشته، یک جملهٔ مسئله است: «این فرد برای انجام این کار، با این مانع روبه‌روست و به این نوع کمک نیاز دارد.» جمله باید بدون نام‌بردن از مدل هم معنا داشته باشد. NIST؛ هستهٔ چارچوب مدیریت ریسک هوش مصنوعی
- تصمیم
- دادهٔ لازم
- روش ساده‌تر
- آزمون محدود
روش ساده‌تر را هم روی میز بگذاریم
برای همان مثال، یک صفحهٔ پاسخ‌های روشن، جست‌وجوی بهتر یا اصلاح سیاست مبهم ممکن است بخشی از مسئله را حل کند. مقایسهٔ این گزینه‌ها، مخالفت با هوش مصنوعی نیست؛ راه فهمیدن ارزش اضافهٔ آن است. اگر مدل فقط اطلاعات نامرتب را با لحن مطمئن بازگو کند، مسئلهٔ اصلی هنوز سر جایش مانده است و مسئولیت پاسخ هم مبهم‌تر می‌شود.
استاندارد انتخاب فناوری GOV.UK، هزینهٔ مالکیت و امکان تغییر انتخاب در آینده را نیز مهم می‌داند. بنابراین مقایسهٔ پیشنهادی ما فقط قیمت اشتراک نیست: آماده‌سازی داده، ارزیابی، بازبینی انسان، پشتیبانی و امکان خروج را هم در نظر بگیریم. ابزاری که راه‌اندازی‌اش آسان است، لزوماً اداره‌کردنش آسان نیست. GOV.UK؛ انتخاب و نگهداری فناوری
مرز خطا و اختیار را پیش از اجرا بنویسیم
در مثال پشتیبانی، پیش‌نویس نامناسب با وعدهٔ اشتباه به مشتری یکسان نیست. مشخص کنیم مدل چه چیزی را فقط پیشنهاد می‌دهد، چه کاری را اجازه ندارد انجام دهد و چه زمانی باید پاسخ را به انسان بسپارد. کارشناس باید زمان و امکان بررسی داشته باشد؛ نوشتن «بازبینی انسانی» روی سند، به‌تنهایی یک کنترل عملی نمی‌سازد.
نمایهٔ هوش مصنوعی مولد NIST بر ارزیابی متناسب با شرایط استفاده و بررسی منابع خروجی تأکید می‌کند. برداشت اجرایی اینجا، ساختن چند نمونهٔ آزمون از پرسش‌های معمول، اطلاعات ناقص و درخواست‌های خارج از اختیار است. پاسخ روان را از پاسخ درست، قابل‌استناد و قابل‌استفاده جدا بسنجیم. NIST؛ نمایهٔ ریسک هوش مصنوعی مولد
آزمایش باید اجازهٔ توقف داشته باشد
یک آزمایش محدود را با روش فعلی مقایسه کنیم، نه با تصور ایدئال از آینده. آیا پاسخ پیدا می‌شود؟ آیا بررسی‌اش کار تازه‌ای ایجاد کرده؟ وقتی پاسخ نامطمئن است چه اتفاقی می‌افتد؟ چه داده‌ای نباید وارد ابزار شود؟ پیش از شروع، مسئول تصمیم دربارهٔ ادامه، اصلاح یا توقف را تعیین کنیم تا جذابیت خروجی جای شواهد را نگیرد.
موفقیت آزمایش می‌تواند کوچک و مشخص باشد: کمک قابل‌اتکا در یک کار محدود، با خطایی که دیده و اصلاح می‌شود. گسترش کاربرد، تصمیم دیگری است و به ارزیابی تازه نیاز دارد. اگر پاسخ مناسب‌تر، یک قاعدهٔ روشن یا جریان کار بهتر بود، آن هم پیشرفت است. هدف، داشتن هوش مصنوعی نیست؛ بهترشدن کاری است که برای آدم‌ها اهمیت دارد.