Recommendation Engine با Evidence و Confidence

یک recommendation خوب فقط «گزینه A بهتر است» نیست. باید بتوانید نشان دهید کدام evidence آن را پشتیبانی می‌کند، کدام evidence علیه آن است، evidence چقدر تازه و باکیفیت است، چه چیزی هنوز نمی‌دانیم، confidence دقیقاً از چه basisی آمده و در چه شرایطی سیستم باید HOLD، review یا abstain کند.

مشکل رایج این است که مدل یک rank و عددی مثل «۹۲٪ confidence» تولید می‌کند و downstream agent همان عدد را مثل احتمال کالیبره‌شده می‌پذیرد. این درس آن shortcut را رد می‌کند. خروجی ما Evidence-Bound Recommendation & Confidence Record v1 است؛ رکوردی که recommendation را به ورودی‌های قابل‌ردیابی می‌بندد و اجازه نمی‌دهد ظاهر مطمئن جای evidence را بگیرد.

قاعده اصلی: confidence label باید نتیجه‌ی قرارداد evidence باشد، نه توضیحی که مدل بعداً برای عدد خودش می‌سازد. اگر evidence تعیین‌کننده missing، stale، ضعیف یا contradictory است، state غیرموفق را حفظ کنید.

مرز درس و مسیر

AGN-002 مالک recommendation evidence + confidence basis است. AGN-001 مدیریت exception مالک را پوشش می‌دهد و AGN-003 catalog/typed contract را. این درس نه exception policy را از نو طراحی می‌کند و نه interface agentها را مالک می‌شود.

پیش‌نیاز سخت AGN-001 است: learner باید بداند وقتی evidence یا authority کافی نیست، «فشار برای تصمیم» نباید جای owner/accountability را بگیرد. اینجا آن مرز را carry forward می‌کنیم ولی outcome AGN-001 را جذب نمی‌کنیم.

همه‌ی مثال‌ها synthetic و آفلاین‌اند. هیچ vendor واقعی انتخاب، خرید یا mutate نمی‌شود.

مدل ذهنی: recommendation یک record است، نه یک جمله

برای هر candidate این زنجیره را طی کنید:

candidate → supporting evidence + contradicting evidence → freshness + quality → missing evidence + assumptions → confidence basis → review/abstain gate → recommendation state → trace

سه چیز را جدا نگه دارید:

1. Rank: ترتیب مقایسه‌ی candidateها در evidence فعلی.
2. Confidence label: strength محدودِ recommendation تحت همین evidence contract.
3. Decision state: آیا می‌توان recommend کرد، review لازم است، باید HOLD/ABSTAIN کرد یا evidence قابل‌قبول نیست.

Rank بالا به‌تنهایی confidence بالا نمی‌سازد. confidence بالا هم permission برای action تولید نمی‌کند. trace هم اثبات «حقیقت» نیست؛ فقط نشان می‌دهد چه eventهایی در workflow ثبت شده‌اند.

حالت‌های HOLD, UNKNOWN, PARTIAL, DISPUTED, STALE, BLOCKED first-class هستند. اگر سیستم آن‌ها را به «احتمالاً خوب است» تبدیل کند، auditability از بین می‌رود.

مبانی: FACT، INFERENCE و DESIGN را قاطی نکنید

FACT 1 — NIST: NIST AI 600-1 یک profile برای مدیریت ریسک GenAI است و سازمان را به ارزیابی، مستندسازی، پایش و مدیریت ریسک متناسب با context هدایت می‌کند. این سند برای ما دلیل خوبی است که output مدل را بدون ارزیابی context-specific نپذیریم؛ اما NIST هیچ scale عددی confidence یا الگوریتم rank مخصوص MAKNOW تعریف نمی‌کند.

FACT 2 — OpenAI Agents SDK: مستندات فعلی tracing می‌گوید trace می‌تواند generation، tool call، handoff، guardrail و custom event را ثبت کند. این برای trace_ref مفید است: می‌توانیم recommendation را به run evidence وصل کنیم. ولی trace فقط رخداد ثبت‌شده را نشان می‌دهد؛ درست‌بودن قیمت، ظرفیت یا نتیجه‌ی توصیه را ثابت نمی‌کند.

INFERENCE: اگر confidence basis به quality، freshness، contradiction و missing evidence متصل باشد، دفاع‌پذیرتر از یک self-assessment آزاد مدل است.

DESIGN: labelهای STRONG/MODERATE/WEAK/UNSUPPORTED، ruleهای review/HOLD و thresholdهای این درس قرارداد محلی MAKNOW هستند؛ آن‌ها را به NIST یا OpenAI نسبت نمی‌دهیم.

قرارداد ۲۳فیلدی Recommendation Record

رکورد working این درس ۲۳ بُعد دارد:

recommendation_id, decision_context, candidate_id, candidate_rank, evidence_ref, evidence_type, evidence_freshness, evidence_quality, supporting_evidence, contradicting_evidence, missing_evidence, assumption_id, confidence_label, confidence_basis, calibration_scope, uncertainty_reason, abstain_condition, recommended_action, alternative_action, review_required, trace_ref, decision_state, review_due.

Gate 1 — Candidate و context

candidate_id و decision_context باید ثابت و قابل‌ردیابی باشند. rank بدون context بی‌معناست؛ «بهترین vendor» برای تحویل فوری ممکن است با «ارزان‌ترین vendor» متفاوت باشد.

Gate 2 — Evidence binding

evidence_ref باید به رکوردهای مشخص اشاره کند. supporting و contradicting evidence را جدا بنویسید. evidence مخالف را داخل prose گم نکنید.

Gate 3 — Freshness و quality

یک رکورد دقیق اما قدیمی ممکن است برای تصمیم امروز decisive نباشد. evidence_freshness و evidence_quality را جدا کنید؛ source معتبر اما stale، current نیست.

Gate 4 — Missing evidence و assumption

نبودن evidence را assumption نکنید. missing_evidence باید صریح باشد. assumption هم id می‌خواهد تا reviewer بداند کدام بخش تصمیم از واقعیت مستقیم نیامده است.

Gate 5 — Confidence basis

confidence_label فقط وقتی معتبر است که confidence_basis بگوید label از کدام evidence و کدام limitation آمده است. «مدل 92% گفت» basis کافی نیست. در این درس عدد مدل می‌تواند metadata باشد، اما evidenceِ confidence نیست.

Gate 6 — Calibration scope

اگر confidence واقعاً از calibration آماری نیامده، وانمود نکنید. calibration_scope می‌تواند NOT_STATISTICALLY_CALIBRATED باشد. این جمله ضعف نیست؛ boundary درست است.

Gate 7 — Contradiction و uncertainty

تناقض decisive را نمی‌توان با average ساده پنهان کرد. اگر capacity signal با top candidate تعارض دارد، uncertainty_reason و review لازم است؛ rank قبلی oracle نیست.

Gate 8 — Abstain / alternative / review

هر record باید بگوید چه چیزی recommendation را متوقف می‌کند، alternative چیست و human review چه زمانی لازم است. سیستم بالغ فقط recommend نمی‌کند؛ می‌داند چه زمانی نباید recommend کند.

Gate 9 — Trace و review due

trace_ref مسیر observability است، نه certificate حقیقت. review_due هم signal می‌دهد که recommendation تا ابد معتبر نیست؛ تغییر قیمت، ظرفیت یا evidence می‌تواند recomputation را اجباری کند.

مثال‌های حل‌شده

مثال ۱ — Vendor A در baseline

دو delivery record تازه Vendor A را پشتیبانی می‌کنند، اما یک capacity signal جاری خلاف انتخاب فوری A است. نتیجه‌ی سالم این نیست که «A با 92% confidence». rank می‌تواند A بماند، اما confidence MODERATE و state RECOMMEND_WITH_REVIEW است، چون contradiction باید resolve یا توسط reviewer پذیرفته شود.

مثال ۲ — Vendor B با price stale

قیمت B پایین‌تر است، اما price record stale است. اگر price برای تصمیم decisive باشد، سیستم نباید price advantage را مثل FACT جاری استفاده کند. state باید HOLD/STALE یا confidence ضعیف شود تا price دوباره verify شود.

مثال ۳ — حذف قوی‌ترین support بدون تغییر label

اگر قوی‌ترین delivery record A حذف شود ولی confidence همچنان MODERATE/STRONG بماند، label از evidence جدا شده است. evaluator باید HOLD_UNSUPPORTED_CONFIDENCE بدهد.

مثال ۴ — درصد مدل به‌جای basis

model_confidence_pct=92 با confidence_basis="model says 92%" قابل‌قبول نیست. این self-assessment است، نه evidence contract.

مثال ۵ — transfer واقعی

حالا capacity A unavailable می‌شود و برای B یک price record جدید و verified می‌رسد. learner باید candidate rank و confidence را دوباره بسازد. حفظ A فقط چون baseline اول بوده، HOLD_RECOMPUTE_REQUIRED است.

Failure modeهای رایج

• Naked confidence: درصد مدل بدون evidence basis.
• Rank-as-oracle: top candidate baseline در mutationهای بعدی حفظ می‌شود.
• Contradiction erasure: evidence مخالف حذف یا summarize می‌شود تا نتیجه تمیزتر به نظر برسد.
• Stale-is-current: source معتبر اما قدیمی مثل evidence جاری استفاده می‌شود.
• Missing-is-neutral: نبود evidence مثل «هیچ مشکلی نیست» تعبیر می‌شود.
• Trace-as-truth: چون tool call یا generation در trace ثبت شده، factual claim درست فرض می‌شود.
• Quality collapse: sourceهای ضعیف و قوی وزن معنایی یکسان می‌گیرند.
• Assumption hiding: assumption داخل prose پنهان می‌شود و قابل review نیست.
• Forced success: HOLD/UNKNOWN/PARTIAL/DISPUTED به recommendation مثبت تبدیل می‌شود.
• No review trigger: سیستم نمی‌گوید با تغییر price/capacity چه زمانی recompute کند.

Alternatives و Trade-offها

می‌توانید confidence را فقط categorical نگه دارید یا در سیستم‌های واقعاً calibrated یک score آماری هم داشته باشید. categorical ساده‌تر و audit-friendly است، ولی resolution کمتری دارد. score عددی expressiveتر است، اما اگر calibration واقعی ندارید، precision کاذب می‌سازد.

می‌توانید contradiction را همیشه HOLD کنید یا برای برخی contradictionهای non-decisive RECOMMEND_WITH_REVIEW بدهید. HOLD محافظه‌کارانه‌تر است؛ review انعطاف عملیاتی بیشتری می‌دهد اما باید owner و consequence روشن باشد.

قاعده‌ی این درس: decision نباید قوی‌تر از weakest decisive evidence باشد. اگر یک dimension تعیین‌کننده UNKNOWN است، rank خوب بقیه‌ی dimensionها آن را جبران نمی‌کند.

پل مسیر باتجربه

برای review سریع یک recommendation، این هفت سؤال را بپرسید:

1. candidate و context دقیقاً چیست؟
2. strongest supporting evidence کدام است؟
3. strongest contradicting evidence کدام است؟
4. decisive evidenceها current و باکیفیت‌اند؟
5. چه evidence تعیین‌کننده‌ای missing است؟
6. confidence label دقیقاً به چه basisی وصل است و آیا calibrated بودن ادعا شده؟
7. چه mutationی این recommendation را invalid می‌کند و review_due کجاست؟

اگر سؤال ۶ فقط به «نظر مدل» برگردد، confidence هنوز قابل‌ممیزی نیست.

تمرین هدایت‌شده و مستقل

Lab آفلاین را اجرا کنید:

python -B lab/AGN-002-LAB1/learner/run_checks.py

ابتدا baseline را بررسی کنید. سپس چهار mutation را اجرا کنید: strongest support را حذف کنید، یک source decisive را stale کنید، contradiction جدید روی top candidate اضافه کنید و confidence basis را فقط با درصد مدل جایگزین کنید.

در تمرین transfer، capacity signal A را unavailable و price B را verified/current کنید. rank baseline را نگه ندارید. candidate و confidence را از evidence جدید recompute کنید.

شواهد Verification

قبولی زمانی است که learner بتواند از evidence آشکار همان تصمیم را بازتولید کند و fixtureهای منفی success جعلی تولید نکنند. Lab باید حداقل این shortcutها را بگیرد:

• confidence بدون basis قابل‌ردیابی؛
• source decisive stale؛
• missing decisive evidence؛
• contradiction مهم بدون review؛
• baseline rank reuse در transfer؛
• trace موجود اما factual evidence ناقص.

هیچ شبکه، API key یا داده‌ی واقعی لازم نیست. oracle فقط fixture و ruleهای visible است.

Assessment و Transfer

در assessment باید چهار توانایی نشان داده شود: مرز درس را توضیح دهید، baseline record کامل بسازید، mutation «strongest support حذف شده اما confidence ثابت مانده» را diagnose کنید، و changed-context transfer را از صفر recompute کنید.

جواب قوی فقط state را نام نمی‌برد؛ field invalid، consequence و minimal repair را مشخص می‌کند. مثلاً: evidence_freshness=STALE → confidence basis invalid → HOLD → verify source / recompute.

در transfer نهایی، A دیگر capacity evidence ندارد و B price جدید verified دارد. اگر evidence جدید B را جلو می‌اندازد، ranking باید تغییر کند. ثبات ظاهری نتیجه ارزش نیست؛ ثبات rule ارزش است.

منابع و Freshness

• NIST AI 600-1 — Generative AI Profile: منبع رسمی برای boundaryهای ارزیابی، مستندسازی، پایش و مدیریت ریسک GenAI؛ نه منبع confidence scale محلی.
• OpenAI Agents SDK — Tracing: منبع فعلی برای eventهای trace شامل generation/tool/handoff/guardrail/custom spans؛ نه اثبات factual truth یا calibration.
• Frozen Lesson Bible AGN-002: authority محلی برای fieldها، stateها، negative caseها و evidence contract.

NIST و Agents SDK در 2026-09-14 دوباره بررسی شدند. semantics ابزار OpenAI را تا 2026-10-18 و claimهای practice-level را حداکثر تا 2027-01-01 بازبینی کنید یا زودتر اگر behavior materially تغییر کرد.