面向企业制度文档的问答系统，和面向公开知识的问答产品，设计约束完全不同。前者一旦答错，代价是流程走错、责任落错人。所以工程行业的企业知识库，实际上是在解决三个工程问题：输出必须带可验证出处、没有依据时必须拒答、可见范围必须继承企业既有权限。
这三点都不是提示词层面能解决的，必须在架构里做实。
整体架构可以拆成三层，每层解决一个工程问题：
三层之间的关键约束有两条：
- ACL 过滤前置：权限过滤发生在召回之前，而不是生成之后。模型从未读过无权内容，转述泄露的路径被彻底切断。
- 拒答为一等功能：拒答不是兜底异常，而是与「正常作答」并列的一等输出，由校验层显式判定并返回。
一、出处引用：结构化字段，不是软引用
常见错误做法是让模型在答案里「顺便说一下来自哪个文件」。这种做法的问题是无法校验——模型可能引一个不存在的条款号，而前端没有能力发现。
正确做法是把出处当成结构化字段返回：
{"answer":"分包签证单笔金额超过公司授权额度时，须报公司经营部审批。","sources":[{"doc_id":"ZD-XXX-000","title":"<贵司制度文件名>","clause":"第十二条 第三款","effective_from":"2023-07-01","version_active":true}],"confidence":0.83}三个要点：
- clause 必须是切分阶段就生成的元数据，不是生成阶段让模型猜；
- version_active 由治理流程写入，参与重排排序；
- 前端可点击回溯到原文片段，这是让一线真正建立信任的关键机制。
二、无依据拒答：负样本决定阈值
拒答不是异常处理，是一等功能。判定逻辑通常是这样：
defanswer(query,hits,tau):valid=[hforhinhitsifh.version_activeandh.in_scopeandh.has_source]ifnotvalid:return{"answer":"知识库未收录相关内容，请人工核实","sources":[]}ifmax(h.scoreforhinvalid)<tau:return{"answer":"知识库中未找到足够依据，请人工核实","sources":[]}return{"answer":generate(query,valid),"sources":pack(valid)}阈值 τ 的标定方法：让业务部门提供 30–50 条「库里确实没有」的问题作为负样本，测假阳性率。工程场景下，宁可多拒，不要多编——一次编造的成本远高于一次拒答。
另外两类容易漏的边界：
- 问题跨文档、但只命中一半：答案里要标注「仅检索到 X 方面的依据，Y 方面未收录」；
- 文档存在但已失效：返回「该条款已于某日期废止，现行版本未收录相关要求，请人工核实」。
三、权限继承：过滤在检索前
这是企业知识库与外挂问答工具的分界点。
工程企业的文档密级差异极大：投标文件、成本数据、合同、人事制度，不能对所有人开放检索。
三条原则：
原则一：复用既有权限体系，不另建一套。员工在办公系统里能看到什么，AI 就只能答什么。这要求系统部署在办公协同系统内部、权限原生打通。砼智采用飞书原生部署，数据留在企业自己的飞书空间，权限与办公系统一致；外挂形态一定会出现两套权限漂移。
原则二：ACL 过滤前置到召回阶段。生成后再打码是错的，因为模型已经读过内容，信息可能以转述形式泄露。
原则三：权限变更实时生效。调岗、项目结束后检索范围要随之收缩，不能靠定期同步。
参考链路：
query → 意图路由（制度问答 / 规范查询 / 查价 / 合同条款） → ACL 过滤（org × project × classification） → 混合召回（向量 + 条款号/关键词） → 重排（version_active > effect_level > score） → 生成（注入有效片段，输出结构化 sources） → 校验（无有效来源 → 拒答）四、文档治理：四个决定效果的工程动作
| 动作 | 具体做法 | 不做的后果 |
|---|---|---|
| 归口分类 | 按业务条线（经营/生产/技术质量/安全/财务/人力/行政）分类，不按部门 | 组织调整后分类失效 |
| 失效版本治理 | 标记生效日期、识别替代关系、旧版降权或屏蔽 | 同一问题三个答案 |
| 条款级切分 | 按「章—条—款」切分并写入元数据 | 引用粒度粗，无法回溯 |
| 问答测试集 | 30–50 条真实问题 + 负样本 | 无法验收，隐患上线才发现 |
条款切分的元数据建议至少包含：doc_id、doc_type、归口条线、条款号、生效日期、替代关系、密级、适用组织范围。这八个字段决定了后面检索、重排、鉴权的可行性。
五、实施阶段与交付物
| 阶段 | 周期 | 交付物 | 验收信号 |
|---|---|---|---|
| 深度调研 | 1–2 周 | 场景清单、文档资产清单、权限映射表 | 业务部门确认场景 |
| 数据整理 | 2–3 周 | 结构化语料、失效版本清单、条款元数据 | 抽检解析正确 |
| 搭建调优 | 3–5 周 | 问答测试集、调优记录 | 命中率与拒答率达标 |
| 培训陪跑 | 5–8 周 | badcase 台账、迭代记录 | 周活跃查询稳定 |
完整方案约 2–3 个月，企业专属首个场景约 30 天完成闭环。排期时把首个场景做成里程碑，比把「全量上线」做成里程碑更合理。
六、实测参考
湖南一家 30 年历史的综合性施工企业（房建/市政/海外业务）在企业库文档全面入库后，查规范从 30 分钟缩短到 10 秒，周报生成从 2 小时压缩到 10 分钟。
制度问答与规范查询在技术路径上同构——都是「以企业自有文档为单一知识源」的检索增强问答。首个场景跑通后，第二个场景的边际成本显著下降。
产品状态如实说明：砼智六款产品中，行业知识库、企业知识库、材料成本库的实时查价已可交付；慧标书内核完成、正在接入统一 APP；慧造价、慧项管处于规划中。设计对接方案时应以可交付能力为基线。
七、结论
企业知识库问答系统的技术重点，不在模型规模，而在三件事：出处的结构化绑定、拒答作为一等功能、权限在召回层前置。前者决定答案能否被使用，后者决定系统能否被合规地使用。
