知识库选型评估表的权重设置，本质是把“我们最在意什么”变成可计算的排序规则。本文按评估目标、维度拆分、权重分配、打分口径、加权公式、阈值设定和结果解读的顺序，给出一套可复算的方法，并附完整算例，帮助评审组在打分前锁定标准、打分后解释结果。
要点总览（TL;DR）
- 权重设置先定决策目标：用“硬性门槛+加权排序”组合，门槛项单独判断通过/不通过，不参与加权。
- 维度拆成6–9个互不重叠的项，用分组排序法或成对比较法折算成百分比，权重总和100%，单项建议落在5%–30%。
- 打分统一1–5分制并写清行为锚点，每项注明证据来源；证据缺失记0分或标注待验证，不按满分估算。
- 加权总分=Σ（维度得分÷5×权重），换算为百分制；门槛未通过时总分不参与排序。
- 阈值结合候选分布、预算与风险由评审组确认，并用权重上下浮动5个百分点的敏感性检查验证排名是否稳健。
先明确评估目标与决策方式
权重服务于一个具体判断：在若干候选知识库平台中，选出能够落地使用的那一个。这个目标决定了权重不能按“功能数量”分配，而应按“对上线后使用效果和风险的影响程度”分配。功能最全的产品未必最适合，权重设置要能体现这一取舍。
决策方式建议采用“硬性门槛+加权排序”的组合。硬性门槛是必须全部满足的条件，例如数据存放位置、单点登录方式、与现有账号体系的对接能力；加权排序用于在通过门槛的候选中排出优先顺序。两类标准分开设置，可以避免某个高分项掩盖不可接受的缺陷。
参与定权重的角色至少包括三类：知识库负责人（代表业务目标与内容治理要求）、IT与安全人员（代表部署、权限、合规约束）、实际使用者代表（代表检索、编辑、日常使用体验）。三类角色的关注点不同，共同参与可以减少权重被单一视角主导。
权重和阈值必须在正式打分前确定并留档。打分后再调整权重，容易让结果向某个预设候选倾斜，也会削弱评审结论的可信度。留档内容包括权重表、阈值、确定理由和参与确认人。
评分维度怎么拆：6–9个互不重叠的维度
维度拆分遵循三条原则：互斥，两个维度不评价同一件事；可观察，能通过演示、试用或文档找到判断依据；可打分，能写出从低到高的行为描述。违反互斥原则最典型的后果是重复计分，例如“检索能力”和“AI问答能力”若都包含语义搜索，语义搜索就会被计两次。
可复用的维度清单如下，评审组可在此基础上增删，但总数建议控制在6–9个：
| 维度 | 评价内容 | 典型证据 |
|---|---|---|
| 知识组织与检索 | 目录结构、标签体系、全文检索与语义检索的准确度 | 试用中检索既定问题集 |
| 编辑与协作 | 多人同时编辑、评论、评审、模板与版本管理 | 现场演示协作流程 |
| 权限与安全 | 页面级权限、角色配置、导出管控、审计记录 | 权限配置演示与安全文档 |
| 集成能力 | 与账号体系、即时通讯、项目工具的对接方式 | 接口文档、联调验证 |
| 迁移与导入 | 存量文档批量导入、格式保留、链接修复 | 小批量迁移试跑 |
| 易用性与学习成本 | 新用户完成常见任务所需时间与培训投入 | 使用者试用反馈 |
| 运维与部署 | 部署方式、备份恢复、升级维护工作量 | 运维文档与实施说明 |
| 成本与商务 | 许可、实施、运维的三年总投入 | 报价单，统一币种与年限 |
| 厂商服务与路线 | 响应机制、实施支持、产品迭代方向 | 客户访谈、路线说明 |
“功能多”这类笼统项要拆成具体子项再归入对应维度。例如把“功能多”拆成“是否支持页面模板”“是否支持文档评审流”“是否支持多级权限”，分别落到编辑与协作、权限与安全维度。维度过多会稀释权重，出现每个维度都不足5%的情况，排序结果对细微打分差异过度敏感；维度少于6个则容易把不同性质的要求混在一起。
权重怎么分配：从排序到百分比
权重分配的目标是让每个百分比都能说出理由，并且别人拿到表能复算。以下两种方法可以单独使用，也可以组合使用。
分组排序法适合评审组人数较多、需要快速收敛的场景。先把维度分为三档：必选档（缺失即不可用，通常转为硬性门槛）、重要档（直接影响日常使用效果）、加分档（有则更好）。然后给三档赋初始分值，例如必选档3分、重要档2分、加分档1分，同一档内再按相对重要性微调，最后按总分归一化为百分比。
成对比较法适合维度较少、需要精细区分权重的场景。把维度两两配对，每次判断“哪一个对本次选型更重要、重要多少”，可用1、3、5表示同等、明显、强烈重要。汇总每个维度获得的比较分值后归一化。成对比较的计算量随维度数量平方增长，9个维度需要36次比较，建议由评审组集体讨论完成，而非各自独立填写后平均。
无论用哪种方法，都遵守三条约束：权重总和为100%；单项权重建议落在5%–30%区间，低于5%的维度对排序几乎无影响，可考虑合并或转为门槛项，高于30%则单一维度可能主导结论；硬性门槛项不参与加权，单独列为通过/不通过。权重确定后由评审组确认，并在评估表中记录每个权重的一句话理由，例如“权限与安全取25%，因为知识库将承载制度类文档，权限失误的影响不可接受”。
打分规则与数据口径
统一采用1–5分制，并为每一档写出行为锚点，让不同评审人对同一证据给出接近的分数。锚点描述“能做到什么”，而非“感觉好不好”。
| 分值 | 通用锚点描述 |
|---|---|
| 5 | 在试用或演示中完整满足要求，且有文档或访谈佐证，无需额外定制 |
| 4 | 基本满足要求，存在少量需配置或变通处理的环节 |
| 3 | 部分满足，关键场景需要定制开发或额外投入 |
| 2 | 仅能通过间接方式实现，效果或工作量存在明显不确定性 |
| 1 | 当前无法满足，且无明确可行的替代路径 |
| 0 | 证据缺失，无法判断 |
每个维度的打分必须注明证据来源：产品演示、试用环境操作记录、官方文档、客户访谈或报价单。证据缺失时记0分或标注“待验证”，不按满分或中间分估算。待验证项在汇总时单独列出，作为补充验证的任务，而不是悄悄按平均分处理。
多人打分时，同一维度取均值或中位数，并记录分歧较大的项。分歧本身是有用信息：两位评审人对“权限与安全”打分相差2分以上，通常说明他们依据的证据不同，应补充演示或文档后再定分。成本类维度按统一口径折算，例如统一按三年期、同一币种、含实施与运维计算总投入，并在表中注明汇率与年限，避免不同候选的报价口径不可比。
加权总分怎么算：公式与示例
加权总分公式为：加权总分 = Σ（维度得分 ÷ 5 × 权重），其中权重以百分比表示，结果即为百分制得分。除以5的作用是把1–5分的原始分统一换算到0–100%的量纲，使不同维度可以直接按权重相加。若某维度记0分（证据缺失），该维度贡献为0，同时应在结果中标注待验证。
以下为演示情景，用于说明计算过程，非真实客户案例。三个候选在六个维度上的得分与权重如下：
| 维度 | 权重 | 候选A得分 | 候选B得分 | 候选C得分 |
|---|---|---|---|---|
| 知识组织与检索 | 25% | 4 | 5 | 3 |
| 编辑与协作 | 15% | 5 | 4 | 4 |
| 权限与安全 | 20% | 4 | 3 | 5 |
| 集成能力 | 15% | 3 | 4 | 4 |
| 易用性与学习成本 | 15% | 5 | 3 | 3 |
| 成本与商务 | 10% | 3 | 4 | 5 |
候选A：4÷5×25% + 5÷5×15% + 4÷5×20% + 3÷5×15% + 5÷5×15% + 3÷5×10% = 20% + 15% + 16% + 9% + 15% + 6% = 81分。
候选B：5÷5×25% + 4÷5×15% + 3÷5×20% + 4÷5×15% + 3÷5×15% + 4÷5×10% = 25% + 12% + 12% + 12% + 9% + 8% = 78分。
候选C：3÷5×25% + 4÷5×15% + 5÷5×20% + 4÷5×15% + 3÷5×15% + 5÷5×10% = 15% + 12% + 20% + 12% + 9% + 10% = 78分。
若候选B未通过某项硬性门槛，其78分不参与排序，即使分数接近候选A。计算表应保留每个维度的得分、证据编号和计算过程，便于复核；权重或得分调整后重新计算，旧版本留档备查。
通过阈值怎么定：门槛线与排序线
阈值分两类。硬性门槛是逐项判断的通过/不通过条件，所有门槛项必须全部通过，候选才进入加权排序。门槛项应少而硬，通常3–5项，例如数据存放位置、账号对接方式、导出与审计能力。门槛项过多会把选型变成排除法，失去比较空间。
加权总分线用于确定入围范围。设置方法不是拍一个通用数字，而是结合候选分布确定：先算出所有通过门槛候选的加权总分，观察分布，再结合预算上限和可接受的风险水平，在最高分与可接受下限之间确定入围线。例如三个候选分别为81、78、78分，评审组若认为低于75分的方案实施风险偏高，可将入围线定在75分，同时说明理由。
阈值与权重同时锁定。若出现“为了让某个候选入围而下调总分线”的情况，应记录调整理由并重新确认，而不是静默修改。阈值确定依据同样写入评估表，包括候选分布、预算约束和风险判断。
结果怎么解读：权重敏感性与局限
加权总分排出顺序后，先做敏感性检查：把关键维度的权重上下浮动5个百分点，重新计算排名。若排名不变，说明结论对权重设置不敏感，结果较稳健；若排名翻转，说明结论依赖特定权重假设，应回到评审组确认该维度的权重理由是否充分，而不是直接采用某一版结果。
权重带有主观性，这是评估设计的固有特征，缓解方式包括：权重由多角色共同确认、每个权重附理由、打分锚点统一、证据可追溯。即便如此，加权总分反映的是评估组在既定标准下的共识，不构成对产品能力的因果保证，也不能替代试用验证。
当候选得分接近时，例如相差3分以内，不宜仅凭总分定论。可采取两种处理：对差异最大的两三个维度补充试用或演示，取得更细的证据；或聚焦这些差异维度单独复核打分，确认分歧来自证据差异还是判断标准差异。评估结果是决策输入之一，最终选择还需结合预算审批、合同条款和实施条件综合判断。
把评估表落到协作流程里
评估表从设计到结论需要可追溯的承载方式。评估表本身作为文档管理，权重表、阈值、打分锚点和变更理由按版本记录，每次调整都能查看修改前后内容并回滚，避免“最终版”被覆盖后无法说明依据。ONES Wiki 支持文档实时同步并记录所有页面版本，可随时查看与回滚，适合承载这类需要留痕的评估文档；其权限控制支持为不同角色配置不同读写权限，便于把评估表开放给评审组、对其他人只读。
打分环节可以把各维度的评分任务分派给对应评审人，按工作项跟踪完成状态，证据附件与打分记录集中归档。ONES Wiki 支持文档关联项目任务，页面组可关联项目，评估文档与评审任务可以互相对应，评审进度和结论在同一处查看。评审结束后，结论、证据和计算表一并归档，后续复评沿用同一套维度、权重和锚点，使两次评估结果具备可比性。
流程上建议固定四个节点：权重与阈值确认并留档、打分任务分派与证据收集、汇总计算与敏感性检查、结论评审与归档。每个节点明确责任人和完成标志，评估表才真正成为可复用的决策工具，而不只是一次性的打分表格。
常见问题
权重已经定好，打分过程中发现某个维度无法取得证据，应该怎么处理？
该维度记0分或标注“待验证”，并在汇总表中单独列出，不按中间分或满分估算。待验证项会拉低加权总分，这本身是提醒评审组补充演示、试用或文档。若该维度权重较高，建议先补齐证据再定分，避免用缺失数据参与排序。
评审组对某个维度的权重分歧很大，有没有比投票更合适的收敛方式？
可以让分歧双方各自写出该权重的一句话理由，再对照证据讨论：分歧通常来自对使用场景的假设不同，例如知识库是否承载制度类文档。讨论后仍不一致时，可先取中间值，并在敏感性检查中把该维度权重上下浮动5个百分点，观察排名是否变化。若排名翻转，说明该维度权重需要更高层级确认，而不是简单多数表决。
硬性门槛和加权总分线可以互相替代吗？
两者作用不同。硬性门槛逐项判断通过/不通过，用于排除存在不可接受缺陷的候选；加权总分线用于在通过门槛的候选中确定入围范围。门槛项通常控制在3–5项，过多会让选型变成排除法。总分线结合候选分布、预算与风险确定，不设通用达标数字。
候选得分只差两三分，是否应该直接选分数高的那个？
不建议仅凭总分定论。相差3分以内时，可对差异最大的两三个维度补充试用或演示，取得更细的证据；也可以聚焦这些维度复核打分，确认分歧来自证据差异还是判断标准差异。评估结果是决策输入之一，最终选择还需结合预算审批、合同条款和实施条件。
评估表在评审过程中需要修改权重，怎样留痕才不影响结论可信度？
把评估表作为文档管理，权重表、阈值、打分锚点和变更理由按版本记录，每次调整都能查看修改前后内容并回滚。ONES Wiki 支持文档实时同步并记录所有页面版本，可随时查看与回滚，适合承载这类需要留痕的评估文档；其权限控制支持为不同角色配置不同读写权限，便于把评估表开放给评审组、对其他人只读。
