پیشبینی ریسک نقص نرمافزار قرار نیست آینده را قطعی بگوید یا «نقص را پیش از وقوع» حذف کند. کاربرد قابلدفاع آن این است: هنگام ورود یک Change یا Pull Request، با اطلاعاتی که همان لحظه واقعاً در دسترساند، ریسک نسبی را تخمین بزنیم تا ظرفیت محدود Review و Test را بهتر تخصیص دهیم. خروجی مدل یک Signal برای آزمون بیشتر است؛ نه اثبات وجود باگ، مجوز حذف تست، معیار عملکرد توسعهدهنده یا Gate خودکار Merge.
این راهنما مالک چرخه Just-in-Time Software Defect Prediction است: Decision/Capacity → Unit/Label/Horizon → Point-in-time Features → Temporal evaluation → Ranking/Calibration → Human action → Outcome/Monitor. برای تست عمومی سیستم AI/ML به راهنمای تست AI/ML، برای تخصیص آزمون بر پایه Risk غیرمدلی به تست مبتنی بر ریسک، و برای گردشکار ثبت و رسیدگی به Defect به مدیریت نقص نرمافزار مراجعه کنید.
پاسخ کوتاه: پیشبینی نقص نرمافزار چیست؟
مدلی است که برای یک واحد مشخص—مثلاً Change، File، Component یا Release—احتمال یا رتبه ریسک یک Outcome تعریفشده را در یک بازه آینده تخمین میزند. در این صفحه، واحد Change/PR است و Action پیشنهادی فقط Review/Test افزوده. واژه «Defect-prone» به معنی «مقصر»، «کد بد» یا «قطعاً دارای نقص» نیست؛ تنها یک پیشبینی شرطی و خطاپذیر بر اساس Dataset و زمان خاص است.
قرارداد استفاده: مدل میتواند بگوید «این Change برای بررسی اضافه در اولویت بالاتری است». نباید بگوید «این توسعهدهنده باگساز است»، «این Change امن است»، «تست لازم نیست» یا «Merge را رد کن» مگر Use case، شواهد، حق بازبینی و Governance بسیار متفاوتی تعریف شده باشد.
Predictive، Diagnostic و Causal را جدا کنید
| نوع سؤال | مثال | خروجی | برداشت ممنوع |
|---|---|---|---|
| توصیفی | چه تعداد Defect در ماه قبل ثبت شد؟ | Count/rate با denominator | علت افزایش |
| تشخیصی | این Incident چگونه رخ داد؟ | Timeline/hypothesis/evidence | پیشبینی خودکار آینده |
| پیشبینی | کدام Change احتمالاً Review بیشتری میخواهد؟ | Score/rank/uncertainty | علت نقص یا مسئول آن |
| علّی | آیا کاهش اندازه Change نقص را کم میکند؟ | اثر مداخله با طراحی علّی | نتیجه از Feature importance |
| تصمیمی | با ظرفیت چهار Review چه چیزی را بررسی کنیم؟ | Policy با cost/capacity | بهینهبودن صرفاً از AUC |
اگر هدف فهم علت Incident است، صفحه تحلیل علت ریشهای مالک آن مسئله است. مدل پیشبینی حتی با Accuracy خوب، علت یا اقدام اصلاحی را کشف نمیکند.
از تصمیم و ظرفیت شروع کنید، نه الگوریتم
Defect-risk Decision Contract decision: کدام Changeها Review/Test اضافه بگیرند؟ unit: PR/commit/change set با identity پایدار decision time: پیش از Merge، دقیقاً پس از کدام event؟ eligible population: repo/service/team/change type و exclusionها label: Outcome قابلمشاهده + observation window + linking rule capacity: N Change یا X دقیقه Review در هر روز action: test selection | reviewer add | exploratory charter | hold-for-info prohibited use: auto-reject، skip tests، employee ranking، discipline false-positive cost: زمان/صف/اعتماد false-negative cost: missed risk و escape، با uncertainty baseline policy: random، rule، all، no-model یا existing triage metrics: ranking@capacity + calibration + workflow outcomes human authority: override/reason/appeal، بدون تنبیه owner/expiry: model/data/policy owners و review triggers
پژوهش JIT QA چه ادعایی دارد؟
مطالعه کلاسیک Kamei و همکاران، A Large-Scale Empirical Study of Just-in-Time Quality Assurance، بهجای Package/File، Changeهای پرریسک را برای تخصیص تلاش QA بررسی کرد. این منبع وجود یک مسیر پژوهشی و مفهوم effort-aware/JIT را پشتیبانی میکند؛ نتیجه پروژههای آن Threshold آماده، تضمین انتقال به Repo ایرانی، یا مجوز استفاده از همان Feature/Metric نیست.
Unit of analysis را پیش از Label قفل کنید
| واحد | زمان تصمیم | Action محتمل | ریسک داده |
|---|---|---|---|
| Change/PR | پیش از Merge | Review/Test اضافه | rebase/squash و لینک Defect |
| Commit | هنگام Push | CI lane یا inspection | commitهای میانی/merge |
| File | برنامهریزی Sprint/Release | تمرکز Test/Refactor | ownership و rename |
| Component/Service | برنامهریزی Portfolio | بودجه/observability | aggregation و exposure |
| Release | پیش از Go/No-go | evidence افزوده | نمونه کم و confounding |
Feature در سطح File را بدون Aggregation rule به Label Change وصل نکنید. یک PR چند File دارد، یک Defect ممکن است چند Commit را لمس کند، و یک Commit ممکن است revert یا cherry-pick شود. Entity resolution بخشی از Dataset است، نه پاکسازی حاشیهای.
Label Contract: «نقص» دقیقاً چیست؟
Label Contract positive outcome: defect confirmed under taxonomy X unit: merged change identity after squash/rebase mapping observation window: مثلاً 30 روز پس از deploy eligible exposure start: deploy/feature-enable، نه صرف Merge linking rule: incident/fix/change evidence و confidence exclusions: docs, generated code, test-only, rollback, dependency bot reopened/duplicate/reverted: قواعد صریح unobserved: not deployed / feature off / insufficient window label states: Positive | Negative-observed | Unknown | Censored | Disputed adjudication: دو reviewer یا sampled audit version: taxonomy/linker/window نسخهشده correction: backfill policy و retraining trigger
Negative با «هنوز Defect ندیدهایم» یکی نیست
Change تازه، Feature غیرفعال، Code path کماستفاده یا Defect گزارشنشده Negative معتبر نیست. Window باید بالغ شود و exposure دیده شود. داده Right-censored را Unknown نگه دارید یا با روش مناسب زمانتارویداد مدل کنید؛ برچسبزدن همه موارد نارس به صفر، نرخ مثبت و ارزیابی را تحریف میکند.
Link کردن Defect به Change یک Oracle ضعیف است
Issue ID در Commit message، keywordهایی مثل fix، Blame/SZZ و Timeline میتوانند Candidate بسازند، اما Ground truth قطعی نیستند. Refactor همزمان، Fix ناقص، تغییر چندعلتی، Merge، rename و Incident بدون Ticket خطا میسازند. Precision/Recall Linker را روی نمونه adjudicated بسنجید و uncertainty را به Label منتقل کنید؛ مدل نباید از خطای Linker «حقیقت» بیاموزد.
Point-in-time correctness: Feature فقط از گذشته
برای هر PR یک prediction_timestamp ثبت کنید. هر Feature باید از Snapshot قبل یا مساوی آن زمان محاسبه شود. داده Review پس از تصمیم، Test failure آینده، لینک Defect، post-merge churn، deployment outcome یا rolling statistic ساختهشده با آینده Leakage است. راهنمای رسمی scikit-learn درباره Data Leakage توضیح میدهد که اطلاعات در دسترسنبودنی در زمان Prediction، ارزیابی را خوشبینانه میکند و preprocessing نیز باید فقط روی Train fit شود.
| Feature | قابلاستفاده پیش از Merge؟ | کنترل |
|---|---|---|
| lines added/deleted تا snapshot | بله | snapshot SHA |
| files/subsystems touched | بله | rename/generated filter |
| historical change/defect count | مشروط | as-of join؛ فقط گذشته |
| CI result تا لحظه scoring | مشروط | decision time و refresh policy |
| review comment بعد از score | خیر برای آن Prediction | نسخه دوم تصمیم یا حذف |
| Defect link پس از Merge | خیر | Label-only؛ leakage assertion |
| final merge diff اگر score قبل است | خیر | candidate snapshot diff |
| feature importance انسانی/نام فرد | نامناسب | prohibited features و governance |
Pipeline داده را As-of و قابلبازتولید بسازید
Source events (immutable timestamps) → entity resolution (repo/PR/commit/file/service) → prediction snapshot at t0 → as-of feature joins where event_time ≤ t0 → delayed label join after exposure + observation window → Train/validation/test temporal partitions → transformation fit on Train only → model/calibrator/policy artifacts → online/offline feature parity checks → immutable prediction/evidence record
Random split برای آینده شبیه Production کافی نیست
Random split میتواند Changeهای یک دوره، Component یا الگوی نزدیک را میان Train/Test پخش کند و Drift زمانی را پنهان سازد. Train روی گذشته، Validation روی بازه بعد و Test نهایی روی آینده untouched انجام دهید؛ سپس Rolling/forward validation را گزارش کنید. Hyperparameter، Feature selection، Imputation و Calibration نباید Test آینده را ببینند.
| Split | کاربرد | خطای رایج |
|---|---|---|
| Train past | fit Feature transformation/model | Backfilled future fields |
| Validation later | threshold/capacity/hyperparameter | تکرار انتخاب تا overfit |
| Test future | یک برآورد نهایی frozen | استفاده برای اصلاح مدل |
| Rolling windows | پایداری زیر season/drift | گزارش فقط بهترین window |
| Cross-repo holdout | ادعای انتقال | Feature semantics متفاوت |
Class imbalance: Accuracy میتواند گمراهکننده باشد
اگر فقط ۲٪ Changeها Label مثبت داشته باشند، مدلی که همه را کمریسک مینامد ۹۸٪ Accuracy دارد و هیچ مورد مثبتی نمییابد. Confusion matrix را با Count و Rate، base rate و denominator گزارش کنید. PR-AUC برای کلاس مثبت کمیاب اغلب از ROC-AUC قابلفهمتر است، اما هیچکدام Capacity واقعی Review یا هزینه Change را مستقیماً پاسخ نمیدهند.
| Metric | پرسش | محدودیت |
|---|---|---|
| Precision | از موارد Flagشده چند Label مثبتاند؟ | با Threshold/base rate تغییر میکند |
| Recall | از Positiveها چند مورد Flag شد؟ | هزینه Review را نمیبیند |
| PR-AUC | Trade-off precision/recall در Thresholdها | Action policy نیست |
| ROC-AUC | توان رتبهبندی pair مثبت/منفی | در imbalance ممکن است خوشبینانه دیده شود |
| Recall@K | با ظرفیت K چند Positive یافت شد؟ | اندازه/هزینه Changeها را برابر میگیرد |
| Effort-aware recall/lift | با X خط/دقیقه بررسی چه مییابیم؟ | Effort proxy باید معتبر باشد |
| Brier/log loss | کیفیت probabilistic prediction | Calibration و discrimination را ترکیب میکند |
| Calibration curve | آیا score ۰.۷ حدوداً ۷۰٪ رخداد دارد؟ | Bin/sample uncertainty و drift |
Capacity-aware evaluation: مدل باید Queue واقعی را ببیند
اگر تیم روزانه فقط چهار Review اضافه میتواند انجام دهد، Metric اصلی باید Top-۴ یا Budget زمان/Lines باشد. مقایسه با Baselineهای Random، ساده (مثلاً largest change)، سیاست فعلی و no-model ضروری است. هدف «بالاترین AUC» نیست؛ هدف Outcome بهتر در ظرفیت و هزینه واقعی است، بدون گرسنهماندن Changeهای کمریسک.
Capacity policy example daily eligible changes = all merged candidates before cutoff extra-review capacity = 4 changes or 120 reviewer-minutes rank key = frozen model score; tie rule documented minimum exploration = 20% random/coverage sample outside top rank critical rule overlay = security/payment/migration signals remain hard gates output = prioritized queue + reason + uncertainty + expiry never = skip baseline tests for low score
Calibration: عدد ۰٫۸ باید معنای عملی داشته باشد
Score رتبهبندی الزاماً Probability نیست. راهنمای Calibration در scikit-learn Classifier خوبکالیبره را مدلی میداند که مثلاً میان نمونههای نزدیک ۰٫۸، حدود ۸۰٪ مثبت باشند؛ همچنین تأکید میکند Calibrator باید روی داده مستقل از Training fit شود. Reliability diagram را همراه تعداد هر Bin، interval، Slice و زمان گزارش کنید؛ بازکالیبراسیون با آینده Test را پنهانی انجام ندهید.
آزمایش بازتولیدپذیر: Leakage چگونه نتیجه جذاب میسازد؟
یک Fixture کاملاً نویسندهساخته با ۱۲ Change خیالی و پنج Label مثبت ساختیم. مدل ML آموزش ندید؛ دو فرمول رتبهبندی ثابت با Node.js ۲۴.۱۸.۰ اجرا شدند. ظرفیت Review فقط چهار Change بود. فرمول سالم از churn، files و prior-defect count موجود پیش از Merge استفاده کرد؛ فرمول آلوده Feature ممنوع postMergeDefectLink را—که فقط بعد از Outcome موجود است—با وزن بالا افزود.
SAFE_PRE_MERGE_FEATURES — top 4 c11 label=0 score=10.25 c07 label=1 score=10.05 c05 label=0 score=9.70 c02 label=1 score=7.55 caught=2/5 | Recall@4=0.40 | Precision@4=0.50 LEAKED_POST_MERGE_LINK — top 4 c07 label=1 score=110.05 c02 label=1 score=107.55 c04 label=1 score=105.40 c10 label=1 score=105.32 caught=4/5 | Recall@4=0.80 | Precision@4=1.00
نسخه Leakage ظاهراً عالی است، اما Feature هنگام Scoring وجود ندارد؛ پس این Improvement قابلاستقرار نیست. Fixture مدل آموزشدیده، Benchmark، مطالعه Repository، Release gate یا Production result نیست. همه Changeها، Labelها، Featureها، وزنها و ظرفیت ساختگیاند؛ هیچ هویت توسعهدهنده، هزینه، Fairness، علیت یا پیشگیری واقعی از نقص ندارند و فقط دو مکانیک را نشان میدهند: Point-in-time leakage و ارزیابی رتبهبندی در ظرفیت واقعی.
Leakage Test Suite را بهصورت کد نگه دارید
- برای هر Feature، assertion کنید
feature_event_time ≤ prediction_time. - Snapshot را بازپخش و Online/Offline feature parity را در tolerance مقایسه کنید.
- Featureهای Label/linker/fix/incident را با allowlist از Training table جدا کنید.
- Preprocessor/Imputer/Encoder/Scaler فقط روی Train fit شود.
- Aggregateهای rolling باید as-of و بدون Window آینده محاسبه شوند.
- Duplicate entity و Changeهای همخانواده بین Partitionها Audit شوند.
- Randomly permute suspected Feature؛ Performance collapse غیرعادی را بررسی کنید.
- «زمان در دسترس شدن» را از «زمان event» جدا ثبت کنید؛ Late arrival ممکن است Leakage بسازد.
- Schema change نباید فیلد post-outcome را بیصدا وارد Feature set کند.
- Feature lineage و query hash در Model artifact ذخیره شود.
Featureهای نرمافزاری و محدودیت هرکدام
| خانواده Feature | مثال | ریسک تفسیر |
|---|---|---|
| Diff/size | added/deleted، files، hunks | اندازه علت نقص نیست و generated code تحریف میکند |
| Diffusion | directories/subsystems touched | ساختار Repo و monorepo اثر دارد |
| History | prior changes/defects/age | exposure و old-component bias |
| Review/process | review count/latency تا t0 | بعد از scoring یا policy-induced feedback |
| CI/static | test/lint/security result تا t0 | مدل signal موجود را تکرار میکند |
| Dependency | lockfile/API/schema change | parser/semantic version uncertainty |
| Ownership | knowledge distribution در Component | تبدیل به فردسنجی/تبعیض |
| Text | title/message tokens | زبان، privacy، gaming و leakage |
Feature انسانی را به امتیاز عملکرد تبدیل نکنید
نام، جنسیت، سن، ملیت، محل، حقوق، ساعات کار، رتبه سازمانی و شاخصهای فردی نباید مسیر میانبر Defect prediction شوند. حتی Author history میتواند Proxy تیم/سابقه/قدرت باشد و با تغییر فرایند Feedback loop بسازد. اگر Knowledge distribution برای Bus factor لازم است، Aggregation سطح Component، Purpose limitation، حداقلسازی و Governance مستقل نیاز دارد. چهارچوب Harm/Accountability در تست اخلاقی هوش مصنوعی مالک این تحلیل است.
توضیح Score فقط سرنخ است
برای Reviewer، Reason codeهایی مثل «تغییر چند Subsystem و Migration» از Feature chart خام مفیدترند؛ اما Explanation نباید به علت Defect یا سرزنش فرد تبدیل شود. Target، Method، Reference، Fidelity و مخاطب را طبق راهنمای تست XAI آزمون کنید. اگر Reason stale یا نسخه مدل اشتباه است، Queue ممکن است درست رتبهبندی شده باشد ولی توضیح defect دارد.
Policy ترکیبی بهتر از جایگزینی همه Evidenceهاست
| Signal | نقش | Action |
|---|---|---|
| Hard risk rule | Payment/security/schema/data-loss boundary | تست/Review اجباری مستقل از Score |
| Model rank | اولویت ظرفیت اضافه | Top-K با expiry و reason |
| Coverage sample | کشف blind spot و label drift | نمونه تصادفی/stratified خارج Top-K |
| Reviewer judgment | Context تازه و override | accept/adjust/escalate با reason |
| Standard portfolio | حداقل Evidence همه Changeها | هرگز با low score حذف نشود |
از رتبه ریسک به Test action نگاشت کنید
High score فقط «بیشتر تست کن» نیست. Failure mechanism را از Diff/Domain استخراج و Action محدود انتخاب کنید: Contract test برای API، migration rehearsal برای Schema، concurrency/property test برای idempotency، exploratory charter برای Workflow، security review برای authorization و observability check برای operability. طراحی کل Portfolio در هرم تست در عمل مالک جدا دارد.
Risk signal → Evidence action record change_id / score / model+policy versions / prediction_time reason signals (non-causal) / uncertainty / expiry failure mechanism hypothesis selected boundary/technique/data/fidelity/oracle reviewer override and reason first-attempt result / defects found / effort consumed decision impact / feedback eligibility / delayed label status
سناریوی ایرانی: اولویت Review تغییر پرداخت و بازپرداخت
در یک بازارگاه کاملاً خیالی ایرانی، مدل Changeهای سرویس پرداخت/بازپرداخت را برای Review و Test اضافه اولویتبندی میکند؛ هیچ Change را Reject نمیکند و تست پایه را حذف نمیکند. Features فقط از Diff و تاریخچه Component تا زمان Scoring میآیند. نام فرد، ساعت کار، شهر، جنسیت، سن یا رتبه شغلی ممنوعاند. داده و Outcomeها ساختگیاند و این مثال توصیه بانکی/حقوقی یا سیستم Production نیست.
Fictional Iran JIT policy unit = PR snapshot before merge label = confirmed escaped defect within 30 observed days after deploy censored = not deployed, feature disabled, insufficient window hard rules = ledger/schema/auth/idempotency/PSP callback changes capacity = 4 extra reviews or 120 minutes/day model inputs = churn/files/subsystems/prior component history as-of t0 prohibited = developer identity, auto-reject, test skipping, performance ranking payment probes = timeout-before/after-commit, retry, duplicate/late/out-of-order callback oracle = Order + PaymentAttempt + PSP + Ledger + Outbox + Reconciliation locale = canonical IRR + explicit toman + Persian/Arabic/Latin digits time = UTC event + Asia/Tehran + Jalali display data = synthetic; no PAN/CVV2/OTP/token; no real side effect appeal = reviewer can override and challenge data/model/policy without penalty
Human-in-the-loop یعنی اختیار و ظرفیت واقعی
- Reviewer باید بداند Score چه ادعایی دارد و چه ندارد.
- Action باید از قبل محدود باشد؛ مدل نباید Scope را در Runtime گسترش دهد.
- Override با Reason ثبت شود، اما برای امتیازدهی Reviewer استفاده نشود.
- Low-risk Queue نیز نمونهگیری شود تا blind spot و selective labels کشف شوند.
- هشدارها expire شوند؛ Score کهنه بعد از rebase/force-push استفاده نشود.
- Automation bias با UI، ordering، explanation و study سنجیده شود.
- Feedback Reviewer Label قطعی نیست؛ adjudication و outcome مستقل لازم است.
- مسیر Correction/Appeal برای Feature، Label و Policy وجود داشته باشد.
Selective labels و Feedback loop
اگر فقط High-scoreها عمیق بررسی شوند، Defect بیشتری در همان گروه پیدا میشود و مدل ظاهراً درستتر میشود؛ Low-scoreها کمتر مشاهده میشوند. اگر Changeهای پرریسک اصلاح یا متوقف شوند، Outcome آینده تغییر میکند و Label «عدم Defect» ممکن است موفقیت Intervention باشد، نه خطای مدل. Logging Policy، propensity/exposure، sample تصادفی و تحلیل جداگانه Action لازم است.
| حلقه | تحریف | کنترل |
|---|---|---|
| بیشتر Review برای High score | Detection bias | coverage sample و effort log |
| اصلاح قبل Merge | Outcome مثبت جلوگیری میشود | pre/post action state و found-before-merge outcome |
| Low score تست کمتر | Missing labels | حداقل تست ثابت و audit sample |
| تغییر رفتار تیم | Feature distribution gaming/adaptation | metric restraint و policy review |
| مدل روی داده خودش بازآموزی | self-confirmation | champion/challenger و frozen holdout |
Shadow mode پیش از هر Action
ابتدا Prediction را تولید و Log کنید، اما Queue یا رفتار تیم را تغییر ندهید. Online feature parity، latency، coverage، score distribution، calibration delayed، top-K stability و data quality را بررسی کنید. سپس Pilot کوچک با Action افزوده و حداقل کنترل/مقایسه اخلاقی اجرا کنید. Shadow performance هم Production benefit نیست؛ چون Workflow outcome هنوز تغییر نکرده است.
Deployment Contract مدل و Policy
JIT prediction artifact prediction_id / repo / change snapshot / prediction_time model, calibrator, feature-query, label and policy versions eligible/excluded reason / missingness / data freshness score + rank cohort + uncertainty/abstain capacity/threshold/overlay rules explanation target/method/version action recommendation and prohibited use human override + actual action + effort delayed outcome/label state and correction history retention/access/redaction and audit identity
Fail-safe و Abstention
| Failure | رفتار امن | ممنوع |
|---|---|---|
| Feature store unavailable | سیاست Baseline/Rule و وضعیت Unavailable | Score cache کهنه بدون هشدار |
| Schema/version mismatch | Abstain + incident | default صفر و low-risk |
| Unknown repo/change type | Out-of-scope + standard tests | تعمیم بیEvidence |
| Model latency timeout | Queue عادی/Rule overlay | مسدودکردن Merge |
| Missing high-value Feature | missingness-aware threshold یا abstain | impute پنهان ناسازگار |
| Score/explanation disagreement | Explanation unavailable؛ score scope روشن | داستان ساختگی |
| Drift alarm | shadow/baseline mode و review | auto-retrain/deploy کور |
Monitoring: Label تأخیردار است
Feature/score/action Drift را فوری میبینید، اما Label ممکن است ۳۰ یا ۹۰ روز بعد بالغ شود. Dashboard باید دو Clock داشته باشد: Operational و Outcome. NIST AI RMF یک چارچوب داوطلبانه و زمینهمحور است که در Measure بر آزمون پیش از استقرار، پایش در طول چرخه، uncertainty و مستندسازی تأکید دارد؛ از NIST AI RMF 1.0 بهعنوان عدسی Governance استفاده کنید، نه گواهی یا Threshold آماده.
| Signal | Clock | Trigger | Countermetric |
|---|---|---|---|
| input/schema/missingness drift | فوری | خروج از baseline/contract | repo/change mix |
| score/rank/top-K churn | فوری | تغییر ناگهانی Queue | release volume و season |
| latency/availability | فوری | SLO breach | fallback safety |
| review effort/queue age | روزانه | ظرفیت شکسته | found defects و standard work |
| override/abstain | هفتگی | slice/reason خاص | حق override؛ نه فردسنجی |
| Recall/Precision@capacity | پس از بلوغ Label | drop با interval | label coverage/linker quality |
| Calibration by time/slice | پس از بلوغ | reliability drift | bin count و base rate |
| workflow outcome | ماهانه/فصلی | no benefit/harm | total defects، cycle time، burnout |
Retraining Gate، نه Cron خودکار
تغییر Label taxonomy/window/linker، Repo architecture، review policy، CI، feature pipeline، dependency bot، release cadence یا Incident process میتواند Dataset concept را عوض کند. Retrain باید Candidate artifact بسازد، temporal backtest و leakage suite را پاس کند، Calibration/Top-K/Slice/Harm را با Champion مقایسه کند و در Shadow/Canary وارد شود. Auto-deploy صرفاً بهدلیل تاریخ یا AUC بهتر ممنوع.
Model/Policy Change Record trigger and hypothesis data cutoff + label maturity + corrected labels feature/label/linker/query/model/calibrator/policy diffs temporal/cross-repo/online-parity/leakage results capacity metrics + calibration + slices + uncertainty workflow/countermetric/harm review shadow/canary + rollback pair owners/approvals/exceptions/expiry post-deploy monitor window and decision
Slice و Transfer را مستقل راستیآزمایی کنید
عملکرد را بر Repo، Service، change type، size band، language، generated/non-generated، dependency/migration و زمان بررسی کنید؛ Slice کمنمونه را با interval و Unknown گزارش کنید. مدلی که در یک Monorepo یا تیم خوب رتبه میدهد، برای Repo دیگر با Definition، Workflow و Base rate متفاوت آماده نیست. Transfer بدون Revalidation و Calibration محلی انجام نشود.
Evidence Pack پیشبینی ریسک نقص
JIT Defect-risk Evidence Pack use/decision/capacity/prohibited-use contract unit/entity-resolution and label/window/exposure/linker contracts source/lineage/as-of joins/data-quality and leakage suite temporal partitions/cutoffs/transform-fit identities model/calibrator/feature/query/policy artifacts baseline and ranking/calibration/capacity/slice raw results uncertainty/intervals/censored/disputed/missing labels shadow/canary/online-offline parity/fail-safe evidence human-action/override/effort/selective-label logs privacy/harm/security/access/retention review monitor/retrain/change/rollback records decision, dissent, exceptions/expiry and correction history
گزارش تصمیم، نه Dashboard پیروزی
گزارش باید Population، eligible/excluded، base rate، label maturity، capacity، Baseline، Metric با denominator/interval، Slice، false positive/negative examples، effort، intervention و limitations را نشان دهد. AUC تنها درشتعدد Header نباشد. ارائه Evidence برای Stakeholder در راهنمای ارائه نتایج تست تکمیل میشود.
Security و Privacy داده Repository
- Source code، diff، ticket، log و Incident ممکن است Secret یا PII داشته باشند؛ Purpose و retention را محدود کنید.
- Raw text را بدون نیاز وارد Feature store نکنید؛ allowlist و redaction پیش از persistence.
- Training snapshot، Model artifact، Feature store و Prediction log دسترسی جدا و audit دارند.
- PR خصوصی و cross-tenant repository نباید در Explanation یا Dataset دیگری نشت کند.
- Prompt/LLM feature extraction اگر استفاده میشود، Provider/data-use/region/retention و injection را جدا Qualification کنید.
- Score API باید auth، rate limit، input validation، model extraction و tampering tests داشته باشد.
- Correction یا deletion باید به Feature/Label/Model lineage برسد و اثر را ثبت کند.
Release Gate مدل با Gate محصول یکی نیست
مدل زمانی مجاز به Pilot است که Label/Time/Leakage/Temporal/Calibration/Capacity/Harm/Fallback gates را پاس کند. محصول زمانی Release میشود که Evidence مستقل Strategy برقرار باشد. High-risk prediction میتواند Test اضافه بسازد، اما Low-risk prediction نمیتواند Defect، Security یا Release gate را حذف کند.
| Gate مدل/Policy | Hard stop نمونه |
|---|---|
| Use/authority | employee scoring یا auto-reject خارج Contract |
| Point-in-time | post-outcome Feature یا fit روی Test |
| Label validity | Unknown/censored بهعنوان Negative گسترده |
| Temporal evaluation | فقط random split یا Test دستخورده |
| Capacity value | بدتر از Baseline در Recall/effort@K |
| Calibration/uncertainty | Probability claim بیکالیبراسیون |
| Slice/harm | خطر فردسنجی یا gap بحرانی ناشناخته |
| Fail-safe | timeout/missingness موجب low-risk یا skip test |
| Operations | عدم identity/monitor/rollback/correction |
مالکیت و Decision Rights
| نقش | مسئولیت | حق تصمیم |
|---|---|---|
| Use-case/Product owner | Decision، ظرفیت، action، prohibited use | توقف Use case |
| Defect/Domain owner | taxonomy، label، window، linking | Dispute/Correct label |
| Data owner | point-in-time lineage، quality، access | Block contaminated dataset |
| Model owner | training، calibration، artifact، limits | Abstain/rollback model |
| QA/Independent validation | leakage، temporal، capacity، slice، evidence | Hold model/policy |
| Security/Privacy/Ethics | threat/harm/people/prohibited features | Hard stop |
| Review/Test lead | Queue action، capacity، override | Override/escalate بدون تنبیه |
| Operations | deploy، SLO، monitor، incident، rollback | Fail-safe mode |
پایلوت ۳۰روزه پیشبینی ریسک Change
| بازه | کار | خروجی |
|---|---|---|
| روز ۱–۵ | Decision/capacity/prohibited use و baseline | Contract + no-model policy |
| روز ۶–۱۰ | Unit/entity/label/window/exposure/linker audit | Label contract + adjudicated sample |
| روز ۱۱–۱۵ | as-of feature pipeline و leakage suite | reproducible snapshot + temporal splits |
| روز ۱۶–۲۰ | baseline/model، Top-K/effort، calibration و slices | frozen evaluation + limitations |
| روز ۲۱–۲۵ | Shadow، online parity، failure/security/human study | operations/harm evidence |
| روز ۲۶–۳۰ | کوچکترین Pilot action، rollback و decision review | Adopt/Adapt/Stop؛ نه ادعای prevention |
۲۰ ضدالگو در پیشبینی نقص نرمافزار
- وعده پیشبینی نقص قبل از وقوع با قطعیت.
- مخلوطکردن تولید صنعتی، Maintenance و Defect نرمافزار در یک مدل.
- شروع از Random Forest/Neural Network بدون Decision/Capacity.
- Unit مبهم میان PR/Commit/File/Component.
- برچسب همه موارد بدون Defect به Negative.
- نادیدهگرفتن exposure و observation window.
- پذیرش SZZ/Ticket link بهعنوان Ground truth قطعی.
- Feature پس از Prediction یا Outcome.
- Fit preprocessing قبل از Split.
- Random split بهعنوان شبیهساز آینده.
- اعلام موفقیت با Accuracy روی کلاس نادر.
- AUC بالا بدون Top-K/effort/capacity.
- نامیدن Score به Probability بدون Calibration.
- Threshold جهانی بدون Base rate و Cost.
- تبدیل Feature importance به علت نقص.
- Score فرد/تیم برای Performance یا Discipline.
- حذف تست برای Change کمریسک.
- نادیدهگرفتن selective labels و intervention feedback.
- Auto-retrain/deploy بر اساس Cron یا Metric واحد.
- نداشتن Shadow، fail-safe، correction، monitor و rollback.
چکلیست ۲۰نقطهای JIT Defect Prediction
- Decision، Action، Capacity و Prohibited use روشناند.
- Unit و prediction timestamp پایدار است.
- Eligible population و exclusionها نسخه شدهاند.
- Label، window، exposure و linking rule دقیقاند.
- Positive/Negative/Unknown/Censored/Disputed جدا هستند.
- Label linker با نمونه انسانی Audit شده است.
- Featureها Point-in-time و lineageدارند.
- Leakage assertions خودکار پاساند.
- Train/Validation/Test زمانی و frozen هستند.
- Transformation فقط روی Train fit شده است.
- Base rate و Confusion counts گزارش شدهاند.
- Baselineهای random/rule/current/no-model دارید.
- Recall/Precision/Lift@capacity یا effort سنجیده شده است.
- Probability claim کالیبره و intervalدار است.
- Slice/transfer/missingness/uncertainty معتبرند.
- Low-riskها حداقل تست و audit sample دارند.
- People scoring و Feature حساس/Proxy ممنوعاند.
- Shadow/online parity/failure/fallback پاس شدهاند.
- Label-delayed monitor/retrain/rollback تعریف شده است.
- Evidence Pack، owner، override و correction آمادهاند.
جمعبندی: پیشبینی برای اولویت، نه پیشگویی کیفیت
پیشبینی ریسک نقص زمانی ارزش دارد که سؤال کوچک و قابلاندازهگیری باشد: با ظرفیت محدود، کدام Changeها Review/Test افزوده بگیرند؟ Unit و Label را با زمان و exposure تعریف کنید، Feature را فقط از گذشته بسازید، Split آیندهنگر و Leakage test داشته باشید، مدل را با Ranking@capacity و Calibration و Baseline بسنجید، و Action انسانی را با حداقل تست ثابت و نمونهگیری پوشش ترکیب کنید. خروجی، Signal خطاپذیر است؛ نه علت، نه حکم کیفیت، نه مجوز سرزنش افراد و نه تضمین آینده بدون نقص.
پرسشهای متداول پیشبینی نقص نرمافزار
آیا مدل پیشبینی نقص واقعاً جلوی باگ را میگیرد؟
خود مدل فقط Score/Rank میدهد. پیشگیری احتمالی به Action درست—Review، Test، اصلاح و کنترل—وابسته است و باید با Workflow outcome سنجیده شود. Defect کمتر میتواند از Detection کمتر یا تغییر exposure هم باشد؛ ادعای علی نیاز به طراحی مستقل دارد.
بهترین Feature برای پیشبینی Defect چیست؟
Feature جهانی وجود ندارد. اندازه/Diffusion/History/CI میتوانند Candidate باشند، اما باید در زمان تصمیم موجود، دارای معنای ثابت، بدون Leakage و معتبر برای Repo/Workflow هدف باشند. نام فرد یا پیوند Defect آینده Feature مجاز نیست.
چرا Accuracy برای مدل Defect کافی نیست؟
چون Label مثبت معمولاً کمیاب است؛ پیشبینی همه Changeها بهعنوان منفی میتواند Accuracy بالا و ارزش صفر داشته باشد. Confusion count، Precision/Recall، PR-AUC، Calibration و بهویژه Recall/Precision/Lift در ظرفیت واقعی Review را گزارش کنید.
Data Leakage در پیشبینی نقص چیست؟
هر اطلاعاتی که هنگام Scoring واقعی موجود نیست اما در Feature، preprocessing، selection، calibration یا evaluation استفاده میشود Leakage است؛ مثل لینک Defect پس از Merge یا fit کردن Scaler روی کل داده. نتیجه Offline خوشبینانه و غیرقابلاستقرار میشود.
آیا Change کمریسک را میتوان کمتر تست کرد؟
مدل این صفحه فقط ظرفیت اضافه را تخصیص میدهد و حداقل Test Portfolio یا Hard rule را حذف نمیکند. نمونهگیری از Low-scoreها برای یافتن blind spot و جلوگیری از Selective labels ضروری است.
