هوش مصنوعی قابل توضیح (Explainable AI یا XAI) زمانی ارزش عملی دارد که توضیح آن نیز مانند هر خروجی نرمافزاری آزمونپذیر باشد. یک نمودار رنگی، فهرست Featureها یا متن روان ممکن است قانعکننده به نظر برسد و در عین حال مدل، نسخه، خروجی یا حتی مخاطب اشتباهی را توضیح دهد. بنابراین پرسش QA فقط «مدل چرا این نتیجه را داد؟» نیست؛ باید بپرسد: این توضیح برای کدام تصمیم و کدام مخاطب تولید شده، تا چه حد رفتار واقعی سیستم را بازتاب میدهد، با تغییر نامربوط پایدار و با تغییر مرتبط حساس است، چه محدودیتی دارد و کاربر پس از خواندن آن چه اقدام امنی میتواند انجام دهد؟
این راهنما مالکِ تست خودِ Explanation Artifact است: Purpose/Audience → Method/Reference → Fidelity/Stability/Sensitivity → Comprehension/Action → Limits/Appeal. برای ارزیابی عمومی مدل و داده به راهنمای تست سیستمهای AI/ML، برای Harm و Fairness و پاسخگویی به تست اخلاقی هوش مصنوعی و برای انتخاب Oracle به راهنمای Test Oracle مراجعه کنید. توضیح میتواند سرنخ بدهد؛ اما بهتنهایی درستی خروجی، انصاف، علیت، انطباق قانونی یا شایستگی Release را اثبات نمیکند.
پاسخ کوتاه: هوش مصنوعی قابل توضیح چیست؟
در این مقاله، XAI مجموعهای از طراحیها، روشها و رابطهاست که برای یک خروجی یا فرایند سیستم، شواهد یا دلیلی متناسب با مخاطب عرضه میکند. این تعریف عامدانه از «باز کردن کامل جعبه سیاه» محدودتر و دقیقتر است. گاهی توضیح، مسیر یک Rule یا Tree است؛ گاهی یک مدل جانشین محلی، Attribution نسبت به یک Reference، مثال مشابه، Counterfactual، سابقه فرایندی یا توضیح محدودیت. هرکدام ادعای متفاوتی دارند و Oracle متفاوتی میخواهند.
| واژه | پرسش اصلی | چیزی که خودبهخود ثابت نمیکند |
|---|---|---|
| شفافیت (Transparency) | چه اطلاعاتی درباره سیستم، داده، مالک و فرایند آشکار است؟ | اینکه یک پیشبینی خاص درست است |
| تفسیرپذیری (Interpretability) | انسان چگونه رابطه ورودی، سازوکار و خروجی را میفهمد؟ | فهم یکسان برای همه مخاطبان |
| توضیحپذیری (Explainability) | برای این خروجی یا فرایند چه دلیل/شاهدی ارائه میشود؟ | علیت، انصاف یا اعتماد موجه |
| توجیه (Justification) | چرا سازمان این تصمیم را مجاز یا مناسب میداند؟ | بازتاب وفادار رفتار مدل |
| Contestability | فرد چگونه داده را اصلاح، تصمیم را اعتراض یا بازبینی انسانی درخواست میکند؟ | اینکه توضیح فنی کافی بوده است |
| پاسخگویی | چه کسی مالک نتیجه، کنترل، اصلاح و Remedy است؟ | اینکه ابزار XAI مسئولیت را تعیین کرده است |
| علیت | آیا تغییر مداخلهای X واقعاً Y را تغییر میدهد؟ | صرفاً از Attribution یا همبستگی حاصل نمیشود |
چهار عدسی NIST برای تبدیل XAI به معیار تست
NISTIR 8312 چهار اصل را مطرح میکند: سیستم باید برای خروجی/فرایند دلیل همراه داشته باشد؛ توضیح برای دریافتکننده معنادار باشد؛ توضیح فرایند واقعی تولید خروجی را درست بازتاب دهد؛ و سیستم حدود دانش یا شرایط صلاحیت خود را بشناسد. این اصول گواهینامه یا آستانه عددی آماده نیستند، اما چهار سؤال آزمون عالی میسازند: آیا Explanation وجود دارد؟ برای این مخاطب قابلاستفاده است؟ به هدفش وفادار است؟ و در ناحیه نامعتبر امتناع یا محدودیت را آشکار میکند؟
قاعده عملی: توضیح خوب الزاماً توضیح بلند نیست. توضیح باید ادعای محدود، Provenance روشن، مخاطب و اقدام مشخص، سنجه وفاداری و مسیر اصلاح/اعتراض داشته باشد. روانبودن متن یک معیار Presentation است، نه Oracle حقیقت.
مالکیت این صفحه: توضیح یک Artifact مستقل است
سیستم ممکن است پیشبینی صحیح و توضیح غلط، پیشبینی غلط و توضیح وفادار، یا هر دو را غلط تولید کند. Release Gate باید این محورهای مستقل را نگه دارد. Accuracy مدل، Fidelity توضیح، فهم کاربر، Fairness پیامد و قابلیت اعتراض را در یک امتیاز میانگین ادغام نکنید؛ شکست Critical در هر محور باید دیده شود.
| خروجی مدل | توضیح | برداشت درست |
|---|---|---|
| درست | وفادار و مفید | نمونه موفق، نه اثبات کلی سیستم |
| درست | نادرست/نسخهکهنه | Explanation defect؛ اعتماد بر اساس آن خطرناک است |
| غلط | وفادار | توضیح میتواند Failure mechanism را آشکار کند، اما خروجی را نجات نمیدهد |
| غلط | قانعکننده ولی بیوفا | دو شکست مستقل و احتمال Automation bias |
پیش از تست: Explanation Test Contract بنویسید
عبارت «یک SHAP Plot نشان بده» Requirement نیست. قرارداد زیر، ادعای توضیح را قابلرد یا قبول میکند. اگر فیلدی ناشناخته است، آن را Unknown ثبت کنید؛ حدس پنهان از کمبود شفاف اطلاعات خطرناکتر است.
Explanation Test Contract decision/output: شناسه تصمیم، Class/Score/Action و زمان purpose: Debug | Validate | Operate | Inform | Contest | Audit audience/action: چه کسی، با چه سوادی، برای چه اقدام مجاز system identity: محصول، Workflow، مدل، نسخه، Dataset/Policy و محیط explanation target: مدل | کل Workflow | Rule | Human override | Process scope: local/global، prediction/class/output-space و horizon method: intrinsic | LIME | SHAP | counterfactual | example | trace method configuration: explainer، parameters، seed، kernel، sample count reference/background: منبع، نسخه، فیلتر، وزن و دلیل انتخاب claim: دقیقاً چه چیزی ادعا میشود و چه چیزی نمیشود fidelity oracle: تعریف neighborhood، agreement/error و آستانه stability/sensitivity: تغییرهای نامربوط/مرتبط و relation مورد انتظار uncertainty/limits: OOD، low confidence، unsupported input، approximation presentation: زبان، RTL، عدد/واحد، accessibility و progressive disclosure security/privacy: redaction، role، retention، logging و anti-gaming appeal/correction: مسیر انسانی، SLA، evidence و outcome notification owner/expiry: مالک تأیید، تاریخ اعتبار و triggers بازآزمایی
یک Explanation برای همه وجود ندارد
گزارش فنی Feature Attribution برای Data Scientist ممکن است برای اپراتور یا فرد متأثر بیمعنا باشد. راهنمای فعلی ICO نیز در زمینه بریتانیا تأکید میکند که توضیح تصمیم AI یک راهحل یکاندازه برای همه نیست و باید با زمینه و دریافتکننده متناسب شود؛ آن را راهنمای UK و در حال بازبینی بدانید، نه تفسیر حقوقی جهانی یا ادعای خودکار درباره GDPR یا ایران.
| مخاطب | کار واقعی | توضیح مناسبتر | تست پذیرش نمونه |
|---|---|---|---|
| توسعهدهنده مدل | تشخیص Failure و تغییر مدل | Attribution، probe، error slice، Provenance | مدل/نسخه درست و بازتولیدپذیری |
| متخصص دامنه | اعتبارسنجی نشانهها و حدود | مثال، rule، counterexample و uncertainty | تشخیص cue نامعتبر بدون القای علیت |
| اپراتور | تصمیم یا Escalation امن | Reason code، confidence، next action | کاهش خطای اقدام بدون Automation bias |
| فرد متأثر | فهم، اصلاح داده و اعتراض | زبان ساده، عوامل اصلی، داده قابلاصلاح، مسیر Review | Comprehension و موفقیت واقعی Appeal |
| ممیز | بازسازی کنترل و تصمیم | نسخه، Log، سیاست، شواهد و Change history | Trace کامل و Tamper evidence |
| تیم امنیت | یافتن سوءاستفاده بدون افشای Rule | نمای Role-based و redacted | حداقل افشا و مقاومت در برابر probing |
Taxonomy روشهای XAI و ادعای محدود هرکدام
دوگانه Intrinsic/Post-hoc فقط آغاز کار است. توضیح را همزمان بر اساس Local/Global، Model-specific/Model-agnostic، Feature/Example/Rule/Counterfactual/Process و بازه زمانی طبقهبندی کنید. یک مدل خطی یا درخت کوچک نیز فقط در صورتی «قابلتفسیر» است که Featureها، transformationها، interactionها، واحدها و مخاطب قابلفهم باشند. سادگی ساختار، حقیقت داده یا مناسببودن سیاست را تضمین نمیکند.
| نوع | ادعای مجاز | ریسک رایج | Oracle محتمل |
|---|---|---|---|
| مسیر Rule/Tree | قواعد اجراشده برای این ورودی | Preprocessing یا Rule دیگری پنهان است | Execution trace و بازاجرای دقیق |
| Local surrogate | تقریب رفتار مدل در neighborhood تعریفشده | نمونههای OOD یا neighborhood دلخواه | Local agreement/error روی probe مستقل |
| Feature attribution | سهم ویژگی در خروجی نسبت به Reference/تعریف روش | تبدیل اهمیت به علت | Additivity/reference/perturbation tests |
| Global summary | الگوی تجمیعی بر Dataset و بازه مشخص | پنهانشدن Slice و interaction | Sampling/coverage و subgroup consistency |
| Example/prototype | نمونه مشابه بر اساس فاصله تعریفشده | افشای داده یا similarity بیمعنا | Distance/domain/privacy oracle |
| Counterfactual | تغییر حداقلی محاسباتی که خروجی مدل را عوض میکند | ناممکن، غیراخلاقی یا غیرعلّی بودن اقدام | Recompute + feasibility/actionability |
| Process explanation | داده، نقش، سیاست و گردشکار تصمیم | اشتباه گرفتن مستند سیاست با رفتار واقعی | Audit trace و E2E workflow test |
ابعاد کیفیت توضیح را جدا اندازه بگیرید
- Target correctness: Explanation متعلق به همان request، class، score، action، tenant، model version و timestamp است.
- Fidelity: توضیح تا چه حد رفتار مدل یا Workflow هدف را در Scope اعلامشده بازتاب میدهد.
- Completeness/Sufficiency: آیا حذف بخش ادعاشده واقعاً توان توضیحی را کاهش میدهد و عوامل مهم حذف نشدهاند؟
- Stability: تغییرهای نامربوط/معادل نباید داستان را بیدلیل واژگون کنند.
- Sensitivity: تغییر مرتبط و مؤثر باید در Explanation دیده شود؛ ثبات مطلق هم شکست است.
- Reproducibility: با Model/Explainer/Seed/Background یکسان نتیجه در تلورانس تعریفشده تکرار میشود.
- Meaningfulness: مخاطب بدون کمک طراح، نکته اصلی و محدودیت را درست میفهمد.
- Actionability: اقدام پیشنهادی مجاز، ممکن، امن و در کنترل مخاطب است.
- Knowledge limits: OOD، confidence پایین، داده ناقص و method failure آشکار میشوند.
- Security/Privacy: Explanation اطلاعات شخصی، membership، secret feature یا مسیر Gaming را بیش از نیاز افشا نمیکند.
Fidelity یعنی وفاداری به هدف تعریفشده، نه «منطقیبودن»
یک explanation ممکن است برای کارشناس کاملاً منطقی باشد ولی رفتار مدل را تقلید نکند. در Local surrogate، مجموعه Probe مستقلی از نمونههای آموزش surrogate بسازید؛ neighborhood، distance، distribution و وزن را ثبت کنید؛ سپس agreement، error یا rank agreement را با interval گزارش دهید. Fidelity نزدیک ورودی، ادعای Global نمیسازد. در سیستم چندمرحلهای نیز روشن کنید Explanation فقط model score را توضیح میدهد یا threshold، Rule، human override و action نهایی را هم پوشش میدهد.
Fidelity test record target = model-v17 / class=needs_review / output=0.73 explainer = local-surrogate-v4 / seed=731 / samples=5000 neighborhood = documented distance + allowed feature domain independent_probes = 1000 (not surrogate-fit samples) metric = weighted absolute error + class agreement result = value + interval + slice breakdown claim = only local, only this output space, only supported domain verdict = Passed | Failed | Inconclusive | Invalid
Stability و Sensitivity دو آزمون مخالف و مکملاند
در Stability، تبدیلهای معناییِ بیاثر تعریف کنید: normalization معادل ارقام فارسی/لاتین، جابهجایی فیلدی که مدل مصرف نمیکند، whitespace یا بازکدگذاری مجاز. خروجی مدل و Explanation باید طبق relation از پیشنوشتهشده تغییر نکنند. در Sensitivity، Feature مؤثر را در محدوده معتبر تغییر دهید؛ اگر score عوض شد ولی explanation ثابت ماند، explainer یا cache مشکوک است. چون خروجیهای توضیح نیز ممکن است تصادفی باشند، روش Verdict آماری را با تست سیستمهای غیردترمینیستیک هماهنگ کنید.
| Probe | انتظار خروجی | انتظار Explanation | Failure signal |
|---|---|---|---|
| تغییر نامربوط | ثابت در tolerance | رتبه/مقدار ثابت در tolerance | Explainer instability |
| تغییر معادل دامنه | Metamorphic relation | همان relation | Preprocessing mismatch |
| تغییر مرتبط کوچک | تغییر کوچک معلوم | تغییر جهت/اندازه متناسب | Insensitive یا stale cache |
| تغییر مرتبط بزرگ | عبور کنترلشده از boundary | عامل/Reason code تغییر کند | Wrong target یا hidden rule |
| ورودی خارج دامنه | Abstain/fallback طبق Contract | حد دانش، نه داستان قطعی | Confident fabrication |
Oracleهای ممکن برای تست Explanation
یک Oracle طلایی جهانشمول وجود ندارد. برای Rule و مدل ساده میتوان Trace یا تجزیه دقیق داشت؛ برای Black box اغلب چند شاهد ناقص را ترکیب میکنیم. عدم توافق دو Explainer نیز بهتنهایی نمیگوید کدامیک درست است؛ ممکن است Target، Reference یا سؤال متفاوت باشد.
| Oracle/Technique | بهترین کاربرد | محدودیت |
|---|---|---|
| Exact reference | Rule، linear fixture، tree trace و synthetic ground truth | به سیستم واقعی پیچیده تعمیم مستقیم ندارد |
| Reconstruction/Additivity | بررسی جمع Base و Contribution در روش مربوط | بازسازی خروجی، علیت یا meaningfulness نیست |
| Independent perturbation | سنجش اثر حذف/افزودن/تغییر Feature | Perturbation ممکن است OOD باشد |
| Surrogate agreement | Fidelity محلی با neighborhood ثبتشده | بیرون neighborhood ادعا ندارد |
| Metamorphic relation | معادلهای معنایی و invariance | Relation باید از Domain بیاید |
| Randomization/sanity | کشف Explanation بیحساس به model/data | نتیجه منفی علت دقیق Failure را نمیگوید |
| Domain review | معناداری، امکانپذیری و cue نامعتبر | نظر متخصص Oracle رفتار مدل نیست |
| User study | Comprehension، task success و calibrated reliance | فهم یا رضایت، Fidelity فنی را اثبات نمیکند |
LIME چیست و دقیقاً چه چیزی را باید تست کرد؟
در مقاله اصلی LIME، یک مدل تفسیرپذیر بهصورت محلی پیرامون Prediction آموخته میشود تا رفتار Classifier را در آن ناحیه تقریب بزند. بنابراین Explanation مستقیماً «ذهن مدل» نیست؛ درباره surrogate، sampling و locality تعریفشده است. Test Contract باید Input representation، روش perturb، Kernel/distance، تعداد نمونه، seed، feature selection، class/output و وزن neighborhood را ثبت کند.
- با Seedهای متعدد، توزیع رتبه و علامت Featureها را بسنجید؛ یک Run زیبا کافی نیست.
- Probe مستقل از نمونههای Fit بسازید و Local fidelity را گزارش کنید.
- بررسی کنید perturbation متن، تصویر یا داده جدولی نمونه نامعتبر/OOD نسازد.
- Neighborhood کوچک/بزرگ را بهعنوان Hyperparameter ادعا آزمایش کنید.
- اگر explanation برای دو ورودی بسیار نزدیک واژگون میشود، هم score و هم local boundary را ثبت کنید؛ برچسب «نوسان» بدون زمینه کافی نیست.
- زمان و Resource را زیر بار، timeout، retry و fallback تست کنید؛ شکست explainer نباید explanation ساختگی یا نسخهکهنه برگرداند.
SHAP چیست و Reference چگونه داستان را عوض میکند؟
مقاله اصلی SHAP چارچوبی برای Feature-attribution افزایشی معرفی میکند و برای یک Prediction به Featureها مقدار اهمیت میدهد. در عمل، تفسیر مقدار به Explainer، خروجی توضیحدادهشده (مثلاً probability یا log-odds)، Background/Reference و فرض وابستگی Featureها بستگی دارد. «Feature شماره یک» علت تصمیم نیست و علامت مثبت نیز بدون Base value و Output space معنای کامل ندارد.
| کنترل SHAP | Failure قابلکشف |
|---|---|
| ثبت Explainer/library/version/config | تغییر بیصدای الگوریتم یا default |
| ثبت Background و lineage | داستان متفاوت بر اثر cohort نامناسب یا drift |
| Additivity/reconstruction در tolerance | Wrong class/output، bug یا serialization |
| مقایسه چند Background تأییدشده | وابستگی پنهان ادعا به Reference |
| Correlated/duplicated feature probes | تقسیم/جابجایی importance و overclaim |
| Local-to-global aggregation checks | پنهانشدن subgroup و cancellation |
| Model/explainer version mismatch test | Explanation مربوط به Deployment قبلی |
آزمایش بازتولیدپذیر: دو توضیح دقیق، دو رتبهبندی متفاوت
برای نمایش مکانیک Reference، یک Fixture خطی کاملاً ساختگی نوشتیم: score = 2 × signalA + signalB و ورودی (4,2) که score آن ۱۰ است. این برنامه با Node.js ۲۴.۱۸.۰ و بدون Dependency اجرا شد. این پیادهسازی SHAP یا LIME نیست؛ فقط تجزیه افزایشی دقیق نسبت به دو Reference را نشان میدهد.
INSTANCE: signalA=4, signalB=2, score=10 ZERO_REFERENCE (0,0) base=0 contribution: signalA=8, signalB=2 reconstructed=10 ranking: signalA > signalB NEAR_REFERENCE (4,0) base=8 contribution: signalA=0, signalB=2 reconstructed=10 ranking: signalB > signalA SMALL_RELEVANT_CHANGE: signalB=2.001 score=10.001; contributions=8 and 2.001; reconstructed=10.001 LARGER_RELEVANT_CHANGE: signalA=3 score=8; contributions=6 and 2; reconstructed=8
هر دو توضیح، همان score را دقیق بازسازی میکنند؛ بااینحال Reference صفر میگوید signalA مهمتر است و Reference نزدیک میگوید signalB مهمتر است. نتیجه: «دقیقبودن جمع» با «Reference-independent truth» یکی نیست. Background باید جزو Evidence باشد و تغییر آن Change کنترلشده محسوب شود. اعداد، Featureها و Thresholdها نویسندهساختهاند؛ هیچ داده، انسان، مدل واقعی، uncertainty، distribution یا اثر اجتماعی ندارند و برای Benchmark، تفسیر SHAP، تصمیم واقعی، اثبات Accuracy/Fairness/Causality یا اعتماد مناسب نیستند.
Counterfactual Explanation را چگونه تست کنیم؟
Counterfactual میگوید با چه تغییر محاسباتی، خروجی مدل عوض میشود. نخست آن را دوباره به همان Pipeline بدهید و عبور از نتیجه را تأیید کنید. سپس Feasibility را جدا بسنجید: آیا Feature تغییرپذیر است؟ تغییر در کنترل فرد است؟ ترکیب پیشنهادی قیود دامنه را نقض نمیکند؟ هزینه و زمان واقعبینانه است؟ راههای متنوع وجود دارد؟ پیشنهاد زیر model update یا داده اندکی متفاوت پایدار است؟
| آزمون | مثال Failure |
|---|---|
| Validity | با اعمال پیشنهاد، Prediction اصلاً عوض نمیشود |
| Immutable constraints | تغییر سن، محل تولد یا گذشته پیشنهاد میشود |
| Domain feasibility | مقادیر یا ترکیب غیرممکن ساخته میشود |
| Actionability/control | کاربر به تغییر Feature دسترسی ندارد |
| Cost/time | «حداقل» ریاضی اما غیرعملی برای انسان |
| Diversity | فقط یک مسیر گران/پرریسک عرضه میشود |
| Stability | با perturbation کوچک، توصیه کاملاً متناقض میشود |
| Causal restraint | تغییر همبسته بهعنوان علت قطعی معرفی میشود |
توضیح مدل با توضیح کل سیستم فرق دارد
در Production، نتیجه ممکن است از preprocessing، مدل، Calibration، threshold، rules، policy، cache، human review و downstream action ساخته شود. Attribution مدل تنها یکی از این لایهها را میبیند. یک Failure Packet باید شناسه درخواست را از ورودی خام تا action نهایی دنبال کند؛ نمایش Featureهای مدل برای توضیح Rule ردکننده یا override انسانی، Target mismatch است.
Raw input → normalization/feature pipeline → model score → calibration/threshold → policy/rule → human review → final action → notice/explanation → correction/appeal/remedy For every arrow record: artifact/version + timestamp + owner + input/output identity reason code + uncertainty + overrides + evidence retention
برای مدلهای مولد و LLM چه چیزی را توضیح میدهیم؟
متنِ دلیلنما را بازتاب قطعی فرایند درونی مدل فرض نکنید. برای سیستم مولد، Artifactهای آزمونپذیرتر شامل Citation و Provenance، قطعههای بازیابیشده، Tool-call record، policy/rule اجراشده، Model/prompt/config identity، confidence یا abstention تعریفشده، و گزارش human override است. متن explanation باید با شواهد قابلمشاهده سازگار باشد و ادعای «این دقیقاً فکر پنهان مدل بود» نکند. برای ارزیابی Claimهای کلی مدل مولد همچنان صفحه مالکِ تست AI/ML را به کار ببرید.
سناریوی ایرانی: اولویتبندی هشدار مغایرت پرداخت، نه مسدودسازی خودکار
فرض کنید یک بازارگاه خیالی ایرانی، پرداختهای دارای احتمال مغایرت را فقط برای بازبینی انسانی اولویتبندی میکند؛ مدل حق رد سفارش، مسدودکردن مشتری یا برداشت مالی ندارد. واحد پول Canonical ریال است و UI مبلغ تومان را با برچسب صریح نشان میدهد. دادهها کاملاً ساختگیاند و شامل PAN، CVV2، OTP یا Token واقعی نیستند. این سناریو توصیه حقوقی، بانکی یا ضدتقلب نیست؛ هدف، تست Explanation در یک Workflow آشناست.
Fictional decision contract output: queue_priority = high | normal | abstain purpose: human reconciliation review only allowed signals: duplicate callback count, commit-timeout flag, reconciliation mismatch, PSP error family, event-order anomaly prohibited action: automatic block/refusal/charge/reputation label operator explanation: evidence IDs + reason codes + safe next check merchant notice: status, affected order, correction/appeal path؛ no anti-gaming detail oracle: Order + PaymentAttempt + PSP + Ledger + Outbox + Reconciliation identity: tenant/order/payment-attempt/idempotency/model/explainer versions
ماتریس E2E توضیح در Workflow پرداخت خیالی
| حالت | انتظار سیستم | انتظار توضیح اپراتور | انتظار برای فروشنده/کاربر |
|---|---|---|---|
| Timeout پیش از Commit | نامعلوم/Probe سپس تصمیم | عدم وجود Commit با Evidence timestamp | وضعیت در حال بررسی؛ Retry کنترلشده |
| Timeout پس از Commit | از Charge مجدد جلوگیری شود | Commit و callback correlation | از پرداخت دوباره خودداری؛ زمان پاسخ |
| Callback تکراری | Idempotent و یک اثر مالی | تعداد callback و یک PaymentAttempt | یک وضعیت نهایی، بدون جزئیات Rule امنیتی |
| Callback دیررس/خارجترتیب | Reconcile یا Queue review | ترتیب event و watermark | تأخیر و مسیر پیگیری روشن |
| Ledger mismatch | High priority انسانی | شناسه Evidence و اختلاف ریالی | عدم قطعیت و SLA بررسی؛ نه اتهام تقلب |
| ورودی ناقص/OOD | Abstain | Feature/Dependency نامعتبر | بررسی انسانی؛ بدون دلیل ساختگی |
| Human override | تصمیم و مالک ثبت شود | دلیل Override جدا از مدل | نتیجه نهایی و مسیر اعتراض |
تست فارسی، RTL، عدد، زمان و Accessibility توضیح
- Reason code فنی را با متن فارسیِ ثابت و Versioned نگاشت کنید؛ ترجمه آزاد در هر Run ممنوع.
- ترکیب RTL/LTR برای `model-v17`، شناسه تراکنش و timestamp نباید ترتیب را وارونه کند.
- ۱۲٬۰۰۰٬۰۰۰ ریال و ۱٬۲۰۰٬۰۰۰ تومان باید واحد آشکار داشته باشند؛ تبدیل پنهان ممنوع.
- ارقام فارسی، عربی و لاتین و Unicode normalization را هم در Pipeline و هم Explanation آزمایش کنید.
- UTC را با Asia/Tehran و نمایش جلالی جدا کنید؛ Explanation باید instant اصلی را نگه دارد.
- رنگ تنها حامل علامت Contribution نباشد؛ جدول متنی، label و ترتیب keyboard فراهم شود.
- Screen reader باید Base، عامل، جهت، مقدار، واحد و محدودیت را به ترتیب مفید بخواند.
- نمودار طولانی Progressive disclosure داشته باشد، اما عامل یا هشدار Critical پنهان نشود.
- Comprehension را با سؤال task-based بسنجید: «چه اتفاقی افتاد؟ چه چیزی قطعی نیست؟ اقدام بعدی چیست؟»
- مقایسه UI explanation با Evidence خام، Screenshot و report را مطابق ارائه نتیجه تست برای تصمیم انجام دهید.
فهم کاربر را با رضایت یا اعتماد اشتباه نگیرید
توضیح میتواند حس اعتماد را زیاد کند و همزمان اتکا را بدتر سازد. در مطالعه کاربر، Accuracy پاسخ به سؤال، زمان، خطای اقدام، توان تشخیص limitation، انتخاب درست Escalation و مقاومت در برابر Automation bias را اندازه بگیرید. «توضیح را دوست داشتم» فقط یک Signal تجربه کاربری است. تیم طراحی توضیح نباید سؤالها را هدایت کند و نمونه باید نقش، زبان و سطح سواد مخاطبان هدف را پوشش دهد.
| Task | سنجه | Countermetric |
|---|---|---|
| تشخیص عامل اصلی | پاسخ صحیح بدون کمک | برداشت علّی نادرست |
| تشخیص محدودیت | ذکر uncertainty/OOD | اعتماد بیشازحد |
| انتخاب اقدام | Escalation/Correction درست | اقدام پرخطر یا غیرمجاز |
| اعتراض | تکمیل مسیر با Evidence | رهاکردن به علت اصطکاک |
| مقایسه تصمیمها | تشخیص تفاوت واقعی | اثر رنگ/ترتیب/Anchoring |
امنیت و حریم خصوصی: توضیح بیشتر همیشه بهتر نیست
Explanation میتواند رکورد آموزشی، Feature حساس، منطق ضدسوءاستفاده یا اطلاعات Tenant دیگر را لو بدهد؛ همچنین probing تکراری ممکن است به model extraction یا Gaming کمک کند. راهحل، حذف پنهانی دلیل یا ساختن داستان جایگزین نیست. Viewهای Role-based، حداقلسازی، aggregation، redaction علامتخورده، rate limit، access log، retention و پاسخ عمومیِ صادقانه طراحی کنید. تست حریم خصوصی تفصیلی در راهنمای تست حریم خصوصی مالکیت جدا دارد.
| تهدید | Probe | کنترل/Oracle |
|---|---|---|
| Cross-tenant leakage | درخواست explanation با ID Tenant دیگر | Denied + zero content leakage + audit |
| Training membership hint | نمونههای مرزی و تکرار query | Privacy review و حداقل افشا |
| Sensitive attribute disclosure | Attribution/trace raw field | Policy allowlist و redaction آشکار |
| Gaming/extraction | Adaptive probing در نرخ بالا | Rate/role controls بدون دروغ توضیحی |
| Prompt/secret leakage | Instruction injection به explainer مولد | Isolation، output validation و refusal |
| Evidence tampering | ویرایش log/version/reference | Integrity، immutable IDs و mismatch alert |
تست API، Cache، Latency و Failure mode توضیح
- Prediction و Explanation باید correlation ID مشترک و identity مستقل داشته باشند.
- Cache key باید model، explainer، config، background، input و target output را شامل شود.
- Deploy همزمان مدل و explainer را با skew عمدی آزمایش کنید؛ mismatch باید Fail closed یا آشکار شود.
- Timeout explainer نباید نتیجه قبلی یا متن generic را به نام Explanation تازه بازگرداند.
- Retry باید idempotent باشد و Seed/Run identity را روشن نگه دارد.
- Serialization اعداد کوچک/منفی، NaN، null، class index و locale را تست کنید.
- Explanation unavailable باید state صریح باشد؛ Prediction موفق آن را به Passed تبدیل نمیکند.
- Latency بودجهای جدا از model inference دارد و fallback باید مطابق ریسک مخاطب تعریف شود.
پایش Production: Drift توضیح هم وجود دارد
حتی بدون افت Accuracy، Background، feature pipeline، dependency یا گروه کاربران میتواند عوض شود و توضیح را بیاعتبار کند. Distribution Attribution را فقط برای هشدار استفاده کنید، نه Verdict کیفیت؛ آن را با نسخهها، input/output drift، fidelity probe، نرخ abstain، failure explainer، شکایت، correction، appeal و human override پیوند دهید.
| Signal | Trigger بررسی | Countermetric |
|---|---|---|
| Attribution distribution drift | تغییر نسبت به cohort/version مرجع | Output/data drift و domain event |
| Fidelity probe failure | عبور از error/agreement contract | Probe coverage و OOD rate |
| Explanation unavailable | افزایش timeout/error/cache mismatch | Inference success و fallback safety |
| Comprehension drop | خطای task یا escalation نامناسب | audience mix و UI change |
| Appeal/correction rise | Reason code/slice خاص | Exposure denominator و outcome |
| Override disagreement | الگوی پایدار با evidence | Reviewer context؛ نه امتیازدهی کارکنان |
Changeهایی که بازآزمایی XAI را اجباری میکنند
تغییر Model weights/architecture، Feature engineering، calibration/threshold، explainer یا Library، Background/Reference، training/serving data، localization، Reason-code map، Workflow rule، policy، UI، نقشهای دسترسی و retention باید Impact record داشته باشد. فقط Version مدل را در dependency list نگهداشتن کافی نیست.
Explanation Change Record change_id / date / owner / reason before→after identities: model, explainer, config, reference, UI, policy affected claims/audiences/slices required reruns: fidelity, stability, sensitivity, comprehension, privacy/security, latency/failure, appeal E2E comparison artifact + known differences + approved exceptions/expiry release decision + monitor trigger + rollback pair
Evidence Pack و Failure Packet
Evidence Pack باید Contract، نسخهها، Environment/Data manifest، Probe generator، seeds، Reference lineage، raw outputs، metric definitions، intervals، Slice results، UI/accessibility evidence، Security tests، limitations، exceptions و approval را نگه دارد. برای هر defect، یک Failure Packet کوچک بسازید تا توسعهدهنده بدون حدس Run را بازسازی کند.
Explanation Failure Packet case/run/correlation/tenant-safe IDs raw input hash + allowed sanitized fixture prediction/class/action + full system/model identities explainer/config/seed/reference/background identities expected relation + actual explanation + numerical tolerance pipeline/rule/human override trace screenshot/API response/logs with redaction manifest reproduction command + first-attempt result + retries preserved impact: audience/action/privacy/appeal owner, severity, workaround, retest and closure evidence
Release Gate: Explanation را پشت میانگین پنهان نکنید
Gate را بر اساس ریسک کاربرد Tailor کنید. برای تصمیم اثرگذار، Target/version mismatch، Fidelity شکستخورده، confident explanation در OOD، افشای داده، اقدام ناممکن/آسیبزا یا مسیر اعتراض خراب باید Hard stop باشد. امتیاز UX بالا نباید آنها را جبران کند. نتیجه Run را Passed/Failed/Blocked/Inconclusive/Invalid نگه دارید؛ Not run را Pass حساب نکنید.
| Gate | نمونه Evidence | تصمیم |
|---|---|---|
| Identity/target | همان input/output/model/workflow | Mismatch = Stop |
| Fidelity | metric + interval + scope + independent probes | Critical failure = Stop |
| Stability/Sensitivity | Metamorphic suite و repeated runs | Unexplained inversion = Hold |
| Limits | OOD/low-confidence abstain test | Fabricated certainty = Stop |
| Human task | comprehension/action study | unsafe action = Stop |
| Privacy/Security | role/tenant/probing/integrity tests | Leakage = Stop |
| Appeal/Correction | E2E case and SLA evidence | impactful use broken = Stop |
| Operations | latency/failure/cache/monitor/rollback | conditional only with bounded fallback |
نقشها و Decision Rights
| نقش | مسئولیت | حق تصمیم |
|---|---|---|
| Product/Use-case owner | Purpose، مخاطب، اقدام و خطر | توقف Use case یا محدودکردن Scope |
| Model owner | Target، model behavior، output space | قبول/رد model-related change |
| Explanation owner | Method/config/reference و claim | اعلام Invalid explanation |
| QA/Test | Oracle، probe، evidence و independent verdict | Hold بر اساس Hard gate |
| Domain/Human-factors | meaningfulness، feasibility و task study | رد UI/action unsafe |
| Security/Privacy | افشا، role، retention و abuse | Stop در leakage/critical abuse |
| Operations | deploy pairing، SLO، monitor و rollback | Fallback/rollback عملیاتی |
| Appeal/Remedy owner | correction، review، SLA و outcome | بازکردن پرونده و اصلاح نتیجه |
پایلوت ۳۰روزه تست XAI
| بازه | کار | خروجی قابلممیزی |
|---|---|---|
| روز ۱–۵ | یک تصمیم محدود، مخاطب، action و owner؛ ترسیم Workflow کامل | Use-case boundary + Explanation Contract |
| روز ۶–۱۰ | ثبت مدل/explainer/reference؛ ساخت exact و metamorphic fixtures | Version manifest + probe corpus |
| روز ۱۱–۱۵ | Fidelity، stability، sensitivity، OOD و failure injection | Metric report + raw evidence |
| روز ۱۶–۲۰ | تست RTL/accessibility، comprehension و safe action | User-task evidence + UI defects |
| روز ۲۱–۲۵ | Privacy/security، tenant، cache، latency، appeal E2E | Failure packets + hard-gate verdict |
| روز ۲۶–۳۰ | Deploy pairing، monitor، rollback drill و decision review | Evidence Pack + conditional Release/Hold/Stop |
۲۰ ضدالگو در هوش مصنوعی قابل توضیح
- برابرگرفتن Explanation با اعتماد، حقیقت یا علیت.
- نمایش نمودار بدون model/explainer/reference identity.
- استفاده از یک Explanation برای توسعهدهنده، کاربر و ممیز.
- تست روانبودن متن و حذف Fidelity.
- تست Fidelity و حذف Comprehension/Action.
- تبدیل Feature importance به دلیل اخلاقی یا قانونی.
- اعلام Bias فقط از روی Attribution یک فرد.
- فرض اینکه مدل ساده ذاتاً برای همه قابلفهم و درست است.
- فرض اینکه Post-hoc explanation بدون trade-off است.
- نادیدهگرفتن Background/Reference در SHAP.
- اجرای LIME با یک Seed و یک Screenshot.
- ساخت Perturbationهای خارج دامنه و قبول نتیجه.
- یکیگرفتن Explanation مدل با تصمیم کل Workflow.
- ارائه Counterfactual ناممکن یا خارج کنترل فرد.
- تولید explanation قطعی برای OOD یا failure method.
- برگرداندن Cache نسخه قبلی بدون هشدار.
- افشای داده/منطق حساس به نام شفافیت.
- حذف Reason و جایگزینی متن ساختگی به نام امنیت.
- میانگینگیری UX خوب با leakage یا Fidelity failure.
- نداشتن Correction، Appeal، owner، expiry و rollback.
چکلیست ۲۰نقطهای QA برای XAI
- Decision، Scope و prohibited use نوشته شده است.
- هر Audience و Action مجاز مشخص است.
- Target مدل یا Workflow دقیق است.
- Model/data/policy/explainer identity ثبت میشود.
- Local/Global و output/class آشکار است.
- Method/config/seed قابلبازتولید است.
- Background/Reference lineage و دلیل دارد.
- Fidelity metric و independent probes تعریف شدهاند.
- Stability relation برای تغییر نامربوط دارید.
- Sensitivity relation برای تغییر مرتبط دارید.
- Exact/metamorphic/sanity Oracle مناسب دارید.
- OOD و knowledge-limit behavior آزموده شده است.
- فارسی، RTL، عدد، واحد و زمان درستاند.
- Accessibility و task-based comprehension سنجیده شده است.
- Actionability و Counterfactual feasibility آزموده شدهاند.
- Tenant/privacy/security/anti-gaming پاس شدهاند.
- API/cache/latency/retry/fallback failure تست شدهاند.
- Correction/Appeal/Review بهصورت E2E کار میکند.
- Change trigger، monitor، owner و rollback دارید.
- Evidence Pack و Hard-gate verdict مستقل آمادهاند.
جمعبندی: توضیح را هم تست کنید
هوش مصنوعی قابل توضیح پایان تست جعبه سیاه نیست؛ خودش یک سطح تازه از محصول و ریسک است. ابتدا Purpose و Audience را تثبیت کنید، سپس Target/Method/Reference را Version کنید، Fidelity و Stability/Sensitivity را با Oracle محدود بسنجید، فهم و اقدام واقعی کاربر را مشاهده کنید و Limits، Privacy و Appeal را Hard gate بگذارید. SHAP، LIME و Counterfactual ابزارند، نه حکم حقیقت. توضیحی که ادعایش دقیق، محدودیتش آشکار و Evidence آن بازتولیدپذیر است میتواند تصمیم بهتر را پشتیبانی کند؛ هیچ نموداری بهتنهایی مدل را درست، منصفانه یا قابلاعتماد نمیکند.
پرسشهای متداول هوش مصنوعی قابل توضیح
آیا XAI ثابت میکند پیشبینی مدل درست است؟
خیر. یک Explanation وفادار میتواند نشان دهد مدل چگونه به خروجی غلط رسیده است. Accuracy/validity خروجی و Fidelity توضیح دو محور مستقلاند و هر دو Evidence میخواهند.
تفاوت SHAP و LIME چیست؟
LIME معمولاً یک surrogate تفسیرپذیر را محلی پیرامون Prediction میآموزد؛ SHAP چارچوب Attribution افزایشی برای سهم Featureها در یک Prediction ارائه میکند. ادعای هر دو به پیکربندی و Scope وابسته است؛ LIME به sampling/locality و SHAP به Explainer/Reference/output assumptions حساس است.
آیا مقدار SHAP علت تصمیم را نشان میدهد؟
نه بهصورت خودکار. مقدار SHAP Attribution نسبت به تعریف روش و Background است. برای ادعای علّی به سؤال، طراحی و شواهد علّی مستقل نیاز دارید؛ Feature مهم یا Counterfactual محاسباتی جای آن را نمیگیرد.
Fidelity توضیح را چگونه بسنجیم؟
ابتدا Target و Scope را مشخص کنید؛ سپس متناسب با روش از exact trace، reconstruction، independent perturbation، local surrogate agreement یا metamorphic relation استفاده کنید. Metric، neighborhood، tolerance، interval، Slice و محدودیت تعمیم باید ثبت شوند.
آیا توضیحپذیری بهتنهایی Fairness و انطباق قانونی را اثبات میکند؟
خیر. Explanation میتواند سرنخ یا Evidence محدود بدهد، اما Fairness به سؤال هنجاری، گروه/Denominator، metric، uncertainty و پیامد Workflow نیاز دارد. انطباق قانونی نیز به حوزه قضایی و مشاوره واجدصلاحیت وابسته است؛ XAI «حق توضیح» یا Compliance را خودکار تأمین نمیکند.
