3. 工程项目知识库需求分析

工程项目知识库的需求分析，不能从“我们有哪些文档”出发，而应从“谁在什么阶段、面对什么决策、需要什么知识、以什么形式获得”出发。同一个知识库，决策层关心的是投资估算偏差与政策合规，设计人员关心的是规范条文与历史方案，招采人员关心的是清单计价与供应商履约，施工人员关心的是工艺交底与质量通病，运维人员关心的是设备台账与故障处置。若把这些需求混为一谈，知识库就会退化为一个“什么都能搜、什么都搜不准”的文档仓库。

一、先建立“角色—阶段—任务—知识服务”的映射

需求分析的第一步是建立映射关系。建议以“角色 × 阶段 × 典型任务 × 知识服务类型”四元组作为梳理单元，其中知识服务类型统一归为四类：问答（针对具体问题给出有依据的答案）、检索（定位到原文、条款、图纸或台账）、推荐（主动给出可参考的方案、参数、供应商或案例）、预警（在条件触发时提示风险、偏差或合规问题）。

以某市政道路改造项目为例，可梳理出如下典型需求（示例为合理假设，用于说明方法）：

这张表的价值在于：它把“知识服务需求”从抽象口号变成了可逐条验证的条目。每一条都可以追问：这个角色在此时是否真的会提问？答案需要引用哪份文件？如果答错会造成什么后果？

二、四类知识服务的需求差异

问答类需求的核心是“有依据、可追溯”。例如施工员问“沥青混凝土面层压实度验收标准是多少”，系统不能只给一个数字，而应给出规范名称、条款号、适用条件，并附原文片段。这类需求对检索精度和引用完整性要求最高。

检索类需求的核心是“找得到、找得全”。设计人员检索“软土地基处理”，既需要规范条文，也需要类似地质条件下的历史方案和计算书。检索需求往往带有过滤条件：专业、阶段、文件类型、时间范围。

推荐类需求的核心是“可参考、可比较”。招采人员需要推荐相似项目的清单项与综合单价，设计人员需要推荐可复用的标准节点。推荐必须给出推荐理由和相似度依据，否则无法被专业判断采纳。

预警类需求的核心是“条件明确、触发可解释”。例如当某分项工程变更金额累计超过合同价的一定比例时触发预警；当设备运行时长接近维保周期时触发提醒。预警规则必须可配置、可追溯，避免“狼来了”式的无效告警。

三、从需求到可验收的指标

需求若不能验收，就无法指导知识库建设。建议为每条需求定义三个指标：覆盖度（该角色高频问题中，知识库能回答的比例）、准确度（答案与原文一致、引用正确的比例）、时效性（从问题提出到给出可用答案的时间）。例如施工问答场景可设定：高频问题覆盖度不低于 85%，引用条款准确率不低于 95%，单次问答响应在 3 秒内返回首条结果。

预警类需求还需额外定义触发条件与误报容忍度。以变更预警为例，可设定“单项变更金额超过合同价 5% 或累计变更超过 10%”触发，并要求预警信息中必须包含触发条款、当前数值、阈值和依据文件。误报率过高会直接导致用户关闭提醒，因此阈值需要结合项目实际分布调整，而不是拍脑袋设定。

四、需求梳理的常见陷阱

• 把“能搜到”当成“能回答”：检索命中不等于答案正确，问答需求必须验证引用与推理链。
• 忽略角色权限：合同金额、供应商报价等敏感信息需要按角色隔离，需求分析阶段就要标注可见范围。
• 预警规则过于笼统：如“进度滞后就预警”无法落地，必须明确比较基准、数据来源和阈值。
• 只收集显性需求：用户往往只说“想要一个搜索框”，实际需要的是带过滤、带引用、带对比的结构化检索。

综上，工程项目知识库需求分析的本质，是把五类角色在五个阶段中的真实知识诉求，翻译成问答、检索、推荐、预警四类可验收的服务条目，并明确每条条目背后的知识对象与判断标准。只有这一步做扎实，后续的文档治理、切片、向量化和检索策略才有明确的优化目标。