快速回答
先定义Eligible Population，再对100条工单做Census或有文档抽样。最小必要脱敏、拆为可追溯Issue Unit、为目标Audience重放Knowledge Search、分配五种Primary Outcome之一、按Reusable Task/Resolution聚类、检查Counterexample、排序具体动作并在发布后衡量。
五种知识覆盖结果
| 结果 | 证据 | 典型动作 |
|---|---|---|
| 已覆盖且找到 | 可访问Article被找到且测试答案充分 | 复用、监控、使用时纠正 |
| 已覆盖但未找到 | Article充分但Query/Label/Language/Index/Navigation失败 | 改进可发现性、元数据、链接、搜索或翻译 |
| 部分或过时 | Article相关但不完整、不准确、过时、不可访问或版本错误 | 更新、拆分、合并、验证、翻译或限制 |
| 缺少文章 | 可重现搜索和复核后无合适可复用知识 | 带Owner、Audience、Evidence和Acceptance Criteria创建 |
| 不适合自助 | 需要身份特定、实时、危险、受监管或专业处理 | 保留人工协助；仅发布安全路由/准备信息 |
称为缺口前的三项有效性检查
选择有效性
其他分析者能否重建哪100条Eligible/Selected Ticket？否则Frequency/Coverage结论不稳定。
搜索有效性
是否记录Audience、Exact Query、Permission、Language、Index、Result、Article Version与Answer Test？一次失败查询不够。
决策有效性
Proposed Action是否解决可复用需求，Reviewer是否检查Counterexample、Risk、Ownership、Effort与Acceptance？Volume不等于Priority。
分析100条支持工单的九个步骤
按顺序执行，因为后续判断依赖前面的Scope、Privacy、Unit与Search Evidence。数字100提高可审计性，但不会消除Sampling Error/Bias。
定义决策、总体与复核窗口
方法
先说明分析要决定什么：Create、Improve、Merge、Archive、Re-index、Translate 或 Restrict Knowledge。查看案例前定义 Eligible Channel、Product、Language、Customer Segment、Ticket State 与固定 Received/Resolved Window。
保留证据
Decision Question；Population Definition；Included/Excluded Channel；Product/Version；Language；Ticket State；Start/End/Timezone；Analysis Owner；Selection Rule；Known Blind Spot。
验收关卡
Scope 可从 Source System 重现；Excluded Ticket 与不可用 Channel 作为限制可见。没有可辩护 Sampling Basis 时，不把100条选中记录推广为全部客户。
不挑结果地选择100条工单
方法
若符合 Scope 的只有100条则用 Census；否则使用有文档的 Representative/Stratified Sample。保留 Selection Order 与 Inclusion Probability。不得只选 Escalation、Long Ticket、Recent Failure、容易案例或分析者记得的记录。
保留证据
Eligible Population Count；Sampling Frame Export/Hash；Census/Sample Method；Random Seed/Deterministic Order；Strata/Allocation；Replacement；Duplicate；Inclusion/Exclusion Reason；受限 Crosswalk 中的 Ticket ID。
验收关卡
准确核对100条不同 Eligible Ticket；若不足则报告原因。按已知维度比较 Sample/Population 并披露实质不平衡；Weighting 需事先记录，不能看完结果后编造。
最小化、脱敏并分离敏感工单数据
方法
创建只含知识问题所需 Field 的 Analysis View。移除或 Tokenize Name、Contact、Credential、Payment Data、Secret、Health/Employment Detail、Security Artifact 与无关 Free-Text；Re-identification Key 放在独立授权系统。
保留证据
Field Inventory/Purpose；Data Owner；必要的Lawful/Contract Basis；Redaction/Tokenization Rule；Access Role；Source-to-Analysis Crosswalk；Retention/Deletion Date；Quality Check；Security/Privacy Route。
验收关卡
分析者与模型只收到Minimum Necessary View；抽样测试Redaction；Source Record不变；Restricted Case 可排除或由专家复核，不把叙述泄露进 Cluster/Article。
标准化问题并保留客户语言
方法
把 Multi-Issue Ticket 拆成可回答 Issue Unit。客户原始 Symptom Words 与分析者 Normalized Concept 分开；记录 Product、Version、Environment、Task、Expected/Observed、Resolution 及是否 Substantiated。不能仅凭措辞相似合并。
保留证据
Ticket/Issue-Unit ID；Original Phrase；Normalized Intent/Entity；Product/Version/Environment；Expected/Observed；Resolution/Workaround；已验证 Root Cause；Tag；Analyst/Model Version；Split/Merge Rationale；Confidence/Counterexample。
验收关卡
每个Unit可追溯Ticket；不覆盖Customer Wording；不同Issue保持分开；Normalization Uncertainty明确。低置信、多语、专业或高影响Unit先由人复核。
为每个问题重放知识搜索
方法
在相关时间搜索目标User/Agent实际可访问的Knowledge Surface。记录 Exact Query、Filter、Language、Role、Product Context、可用的Index Version、Ranked Result、Opened Article及是否无需禁止权限即可找到；同时测试客户语言与内部术语。
保留证据
Search Actor/Permission；Surface；Query/Language；Filter/Context；Search Time；Result ID/Rank；Article Version/State/Audience；Click/Open Evidence；Ticket中使用的Article；Search Failure/Error；Analyst Judgment。
验收关卡
每个Coverage Judgment都有可重现Search Evidence。不能因一次查询失败就判Missing，也不能因存在Internal-Only Article就判客户已覆盖；Search Availability与Answer Adequacy分开。
归入五种覆盖结果之一
方法
把Issue归为 Covered-and-Found、Covered-but-Not-Found、Partial-or-Outdated、Missing-Article 或 Not-Suitable-for-Self-Service。依据 Intended Audience、Findability、Task Completion、Accuracy、Freshness、Permission 与 Risk，而不是标题相似度；需要多个动作时保留Secondary Finding。
保留证据
Coverage Outcome/Definition Version；Candidate Article/Version；Audience/Access；Query Evidence；已测试Answer Step；Accuracy/Freshness Check；Missing Element；Risk/Specialist Restriction；Reviewer；Rationale；Confidence；Next Action。
验收关卡
Primary Outcome五选一，但改进动作可并存。“Not Suitable”必须有Identity-Specific、Dangerous、Regulated、Live-State或Specialist Work理由，不是放难题的桶。
聚类证据并检验反例
方法
按相同Customer Task与Reusable Resolution聚类Issue Unit，而不是只按Keyword、Sentiment、Team或Product Area。用表面相似但需要不同Answer、Permission、Version或Owner的Counterexample检验Cluster，并保留Membership与Rejected Merge。
保留证据
Cluster ID/Version；Inclusion Rule；Representative Customer Phrase；Reusable Task/Resolution；Member Issue ID；Similarity Signal；Counterexample；Split/Merge Decision；Language/Product/Version Boundary；Human Reviewer；Unresolved Item。
验收关卡
每个Cluster都有一致Actionability和记录边界。一个Ticket可贡献多个Issue Unit，但报告Ticket Coverage时分母仍是Ticket。AI建议仅为Proposal，须Knowledge-Domain Reviewer确认/细分/拆分/拒绝。
验证缺口并形成有证据的优先Backlog
方法
Knowledge-Domain Reviewer 检查 Source Ticket、Search Evidence、Candidate Article、Counterexample 与 Specialist Restriction。用有文档的 Reach、Customer/Task Impact、Recurrence、Risk、Strategic Importance、Confidence、Effort、Dependency 与Content Owner Capacity排优先；各输入分开，不藏进单一AI Score。
保留证据
Validated Cluster/Outcome；Distinct Ticket与Eligible-Population Denominator；Affected Task；Impact/Risk；Recurrence Window；Confidence；Effort/Dependency；Existing-Article Action；Owner/Reviewer；Acceptance Criteria；Priority Rationale；Review Date。
验收关卡
Backlog明确Create、Improve、Merge、Re-index、Translate、Archive、Product Fix或Keep Agent-Assisted。High Volume不自动胜出；低频高伤害与高频低影响可区分，冲突由人裁决。
发布、衡量使用与有效性并重复
方法
通过正常 Content Standard、Technical Review、Accessibility Check、Permission、Translation、Versioning 与Rollback流程发布/更新。把Article关联贡献Issue Cluster，监控Search/Use，抽样内容是否帮助完成Task，记录Flag/Correction，并在可比Window重复分析。
保留证据
Article/Action ID/Version；Approval；Accessibility/Specialist Check；Publish/Audience/Index State；Cluster Link；可用的Search Impression/Query；Use/Reuse；Task-Success Review Method；Failed/Abandoned Use；Correction；Next Analysis Window。
验收关卡
只有目标动作交付并验证，Backlog Item才关闭，不是Draft完成就关闭。Search、Click、Reuse、Deflection、Resolution Time与Ticket Change需带Denominator/Confounder解释；无合适设计不声称因果改进。
示例案例：“登录帮助”其实是两种不同缺口
本假设示例仅演示方法，数字不是OpenMax结果。选中的100条样本中有12条提到Login或SSO；聚类模型建议一个“缺少认证文章”的Gap，人工复核拒绝该合并。
- 重放搜索。 8个Issue Unit使用“新手机”“丢失代码”“无法验证”等词；当前Recovery Article存在，但只在内部词“MFA reset”下排名。因此是Covered-but-Not-Found，不是Missing。
- 检查反例。 4个Unit是SCIM用户在部署后遇到特定错误；Recovery Article不能解决且需Tenant-Specific Investigation。3个共享已核验Configuration Defect，1个是不同IdP Mapping。
- 拆分动作。 Action A改进Recovery Article标题、客户用语、链接与Search Synonym；Action B为已验证缺陷创建Restricted Agent Runbook及安全客户路由；Mapping案例更新现有Integration Article。
- 保留分母与不确定性。 报告写“100条选中工单中的12条”，而不是“全部客户的12%”；记录Selection Scope、Issue-Unit Count、Search Evidence、Confidence与下一可比Review Window。
如何运营和衡量学习闭环
角色与独立性
指定Sample Owner、Privacy/Security Reviewer、Issue Coder、Search Evaluator、Knowledge-Domain Reviewer、Content Owner、Accessibility/Localization Reviewer与Measurement Owner。聚类模型不能成为自己Cluster的唯一评估者。
带分母指标
报告Selected Ticket、Issue Unit、Distinct Cluster、Outcome Count、Reviewed Disagreement、Backlog/Delivered Action、Article Use、Task-Success Sample、Correction与Repeat-Window Result；Ticket/Issue/Search/User/Article分母分开。
失败与恢复测试
测试Biased Sample、Duplicate Ticket、Redaction Leak、Multilingual Split、Wrong Merge、Inaccessible/Internal-Only Article、Stale Version、Search Outage、Reviewer Disagreement、Owner Absence、Failed Publication、Index Delay与Rollback。
最低可审计分析记录
analysis_id · decision_question · population · window · sampling_frame · selection_method · ticket_crosswalk · redaction_version · issue_unit_id · customer_phrases · normalized_issue · search_actor · query · result_ranks · article_version · coverage_outcome · cluster_id · counterexamples · reviewer · priority_inputs · backlog_action · owner · acceptance · publish_version · effectiveness_method · next_window
OpenMax如何协调知识缺口分析
OpenMax可冻结Sampling Frame、创建Minimized Analysis View、拆分/标准化Issue Unit并保留Customer Phrase、重放获准搜索、建议Coverage Outcome/Cluster、显示Counterexample、请求Domain Review、创建有Owner的Backlog Action并监控Delivery/Repeat-Window Evidence。Privacy、Specialist、Cluster、Priority与Publication决定由人负责。
抽样、隐私与因果解释边界
- 除非Sampling Design支持，不得声称100条工单代表所有Customer、Channel、Language、Product或Time Period。
- 不得向模型、分析者或Article暴露Customer Identity、Credential、Payment Detail、Sensitive Narrative、Security Artifact、Restricted Investigation或不必要Raw Text。
- 不得让Similarity Score合并不同Permission、Version、Root Cause、Remedy、Audience或Affected Person；保留Counterexample与人工复核。
- Not Suitable for Self-Service是安全与服务设计决定，不代表客户难处理或Issue无价值。
- Search、Click、Reuse、Deflection、Resolution Time、Ticket Volume与Satisfaction是不同指标；无合适Comparison/Confounder Analysis不声称因果改进。
常见问题
100条工单有统计代表性吗？
不自动具备。代表性取决于Eligible Population、Selection Method、Strata、Missing Channel、Imbalance与Intended Inference；100只是透明Review Unit。
搜索无结果就代表缺文章吗？
不。先测试Alternative Customer Phrase、Permission、Language、Filter、Index Health、Navigation与Candidate Article。
一个工单能产生多个Issue Unit吗？
可以。每个Unit关联Source Ticket，但报告Issue/Ticket Coverage时使用正确分母。
每个高频问题都应做自助内容吗？
不。有些需要Identity-Specific、Live、Dangerous、Regulated或Specialist Handling；另一些更适合Product/Process Change。
如何排列缺口优先级？
保持Reach、Task Impact、Recurrence、Risk、Strategic Importance、Confidence、Effort、Dependency与Owner Capacity可见，不折叠为Volume或单一黑箱分数。
OpenMax可自动化什么？
可协调Sampling、Redaction、Issue Unit、Search Evidence、Proposal、Review、Backlog Ownership、Publishing Handoff、Monitoring与Repeat Analysis；重大判断由人负责。
来源、编辑方法与限制
OpenMax编辑复核Consortium for Service Innovation KCS v6的Reuse、Improve、Article Structure与Knowledge Domain Analysis，NIST AI RMF关于Selection、Representativeness、Measurement、Monitoring与Independent Review，以及W3C WCAG 2.2的可访问内容/交互，再原创形成九步流程、五种结果模型与登录示例。资料于2026年9月3日复核。
- Consortium for Service Innovation — Knowledge Domain Analysis
- Consortium for Service Innovation — Reuse is Review
- Consortium for Service Innovation — KCS Article Structure
- NIST — AI RMF Core
- W3C — WCAG 2.2