وقتی هوش مصنوعی «نه» می‌گوید، توضیحش باید قابل اثبات باشد

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

مشکل اینجا بد نوشتن توضیح نیست. سامانه در لحظه تصمیم، شاهد لازم را نگه نداشته و حالا روانی زبان جای منشأ را گرفته است.

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

توضیح خوب از زمان تصمیم آغاز می‌شود

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

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

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

منابع معتبر چه مرزی می‌گذارند؟

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

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

تکلیف حقوقی به حوزه و نوع تصمیم وابسته است. از ۲ اوت ۲۰۲۶، ماده ۸۶ قانون هوش مصنوعی اتحادیه اروپا در دامنه مشخص خود اعمال می‌شود: برخی افراد متأثر از تصمیمی که بر خروجی سامانه‌های پرخطر فهرست‌شده استوار است و اثر حقوقی یا اثر نامطلوب مشابه دارد، حق دارند توضیحی روشن و معنادار درباره نقش سامانه و عناصر اصلی تصمیم بگیرند. استثناها و حقوق دیگر اتحادیه نیز مهم‌اند. این مقاله راهنمای مهندسی عمومی است، نه نظر حقوقی.

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

راهنمای دفتر کمیسر اطلاعات بریتانیا و مؤسسه آلن تورینگ توضیح را با توجه به مخاطب و هدف به شش نوع تقسیم می‌کند: منطق نتیجه، مسئولیت، داده، انصاف، ایمنی و عملکرد، و اثر. خود این صفحه می‌گوید راهنما پس از قانون Data (Use and Access) در دست بازنگری است. این دسته‌بندی برای طراحی مفید است، ولی هر تیم باید قانون روزِ حاکم بر پردازش خود را جداگانه بررسی کند.

معماری، قالب رسید، آزمون‌ها و دروازه انتشار ادامه مقاله تحلیل ZharfAI بر پایه این منابع است.

مخاطب بعد از خواندن باید چه کاری بتواند انجام دهد؟

از نمودار آماده شروع نکنید. اول کاری را نام ببرید که توضیح باید ممکن کند.

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

حضور اسمی انسان نیز این نیاز را حذف نمی‌کند. اگر مدل در شاهدهای دیده‌شده، رتبه‌بندی، پیشنهاد یا گزینه پیش‌فرض نقش مؤثر داشته، همان نقش را ثبت کنید. راهنمای قرار دادن قضاوت انسان در مرز درست تأیید تفاوت بازبینی واقعی و تأیید تشریفاتی را باز می‌کند.

رسید تصمیم، پایه مشترک همه توضیح‌هاست

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

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

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

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

پنج شیء را در یک فیلد «دلیل» له نکنید

سامانه باید پنج چیز مرتبط اما متفاوت را نگه دارد:

1. نتیجه: چه چیزی، برای چه کسی، چه زمانی و با چه اثری تصمیم گرفته شد؟
2. منطق نتیجه: کدام عوامل یا شاهدها واقعاً از همین نتیجه پشتیبانی کردند؟
3. فرایند: داده، قواعد، مدل‌ها، ابزارها و افراد چگونه به نتیجه رسیدند؟
4. اطمینان سامانه: سازمان قابلیت اعتماد، انصاف، امنیت و محدودیت‌ها را چگونه آزمود؟
5. جبران و اصلاح: فرد چگونه داده را درست کند، شاهد تازه بدهد یا بازبینی بخواهد؟

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

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

روش توضیح را با ادعای مورد نظر تطبیق دهید

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

ظاهر قانع‌کننده نیز آزمون خوبی نیست. نویسندگان Sanity Checks for Saliency Maps نشان دادند بعضی روش‌های برجسته‌سازی آزموده‌شده نسبت به مدل آموزش‌دیده یا فرایند تولید داده حساس نبودند. نتیجه پایدار این نیست که همه نقشه‌های برجستگی شکست خورده‌اند؛ هر روش توضیح باید با آزمونی سنجیده شود که دقیقاً ادعای مورد استفاده را هدف می‌گیرد.

مثال: امتیاز ریسک، علت رد درخواست نبود

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

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

رسید تصمیم، توضیح دقیق‌تری می‌سازد:

• درخواست در زمان معین و با نسخه ۷.۳ سیاست رد شد؛
• دو دلیل اصلی، نبود اظهارنامه لازم و نسبت ۰٫۹۱ در برابر آستانه ۱٫۱۰ بود؛
• اسناد منبع، دوره، واحد پول، نسخه محاسبه و وضعیت داده مفقود ثبت شدند؛
• نقش هوش مصنوعی به اولویت بازبینی محدود بود، نه قاعده کنترل‌کننده؛
• متقاضی می‌تواند سابقه اظهارنامه یا ورودی محاسبه را اصلاح کند یا بازبینی واجد اختیار بخواهد؛
• تغییر یک عدد، تضمین پذیرش زیر سیاست آینده یا ارزیابی کامل نیست.

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

خلاف‌واقع باید از دنیای واقعی جان سالم به در ببرد

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

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

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

مدل زبانی مترجم دلیل است، نه سازنده آن

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

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

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

فصاحت را آزمایش نکنید؛ وفاداری را بسنجید

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

1. وفاداری: آیا هر دلیل به رسید وصل می‌شود و تغییر عامل کنترل‌کننده نتیجه ثبت‌شده را طبق انتظار عوض می‌کند؟
2. کامل بودن: آیا همه دلایل اجباری، محدودیت‌ها، مالک و مسیر جبران حاضرند؟
3. درستی داده: آیا مقدار، واحد، تاریخ و نسخه با مرجع معتبر زمان تصمیم یکی است؟
4. معناداری: آیا مخاطب نمونه بدون آموزش تخصصی می‌فهمد چه شد و اقدام معتبر بعدی چیست؟
5. پایداری: آیا بازگویی، جابه‌جایی ترتیب، داده نامربوط، تصادفی‌سازی و نسخه مدل توضیح ناپایدار را آشکار می‌کنند؟
6. ایمنی و حقوق: آیا متن از افشای داده محافظت‌شده، توصیه ناممکن، قطعیت فریبنده و ارائه نابرابر دور می‌ماند؟

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

هشت شکست که ظاهر پاسخ‌گو دارند

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

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

توضیح چه تغییری در عمل ایجاد کرد؟

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

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

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

دروازه انتشار توضیح

پیش از ایستادن یک تصمیم متکی بر هوش مصنوعی، این ده پرسش باید پاسخ روشن داشته باشند:

1. تصمیم و نقش واقعی سامانه هوش مصنوعی دقیق نام‌گذاری شده‌اند؟
2. رسید حفاظت‌شده زمان تصمیم وجود دارد؟
3. هر دلیل به مقدار منبع، قاعده، سهم مدل یا قضاوت انسان وصل می‌شود؟
4. روش توضیح برای ادعایی که مطرح می‌کند معتبر است؟
5. درستی تصمیم و درستی توضیح جداگانه آزموده می‌شوند؟
6. متن با کار، زبان و توان مخاطب تناسب دارد؟
7. محدودیت، عدم قطعیت و اطلاعات حذف‌شده صادقانه بیان شده‌اند؟
8. فرد می‌تواند داده را اصلاح کند، شاهد بدهد و به بازبین صاحب اختیار برسد؟
9. کنترل حریم خصوصی، امنیت، انصاف، نگهداری و دسترس‌پذیری اعمال شده است؟
10. تغییر سیاست، مدل، داده یا روش توضیح، اعتبارسنجی دوباره را فعال می‌کند؟

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

یادداشت منابع — بازبینی‌شده در ۲۹ اوت ۲۰۲۶

• NISTIR 8312: چهار اصل هوش مصنوعی توضیح‌پذیر.
• هسته چارچوب مدیریت ریسک هوش مصنوعی NIST: پیامدهای داوطلبانه مدیریت ریسک.
• قانون هوش مصنوعی اتحادیه اروپا، مقرره ۲۰۲۴/۱۶۸۹: دامنه ماده ۸۶ و تاریخ‌های اجرا.
• ۱۲ CFR 1002.9: قاعده جاری اخطار اعتباری آمریکا.
• راهنمای ICO و مؤسسه آلن تورینگ: دسته‌بندی توضیح و وضعیت بازنگری.
• لوندبرگ و لی: چارچوب اصلی SHAP.
• آدبایو و همکاران: آزمون تصادفی‌سازی برجستگی.
• واختر، میتلشتات و راسل: چارچوب توضیح خلاف‌واقع.