企业知识库建设费用，不能只按文档数量或模型单价计算。真正决定预算的，是六个边界：资料是否需要清洗与OCR、权限是否要与源系统同步、检索质量要达到什么标准、要连接哪些业务系统、采用哪种部署方式，以及上线后由谁持续运营。适合先立项的企业，通常已经能说清一个优先场景、主要资料来源、使用角色和不可接受的错误；如果这四项还说不清，应先做范围诊断，而不是直接采购“大而全”的知识库。
本文不提供脱离现场的统一报价。下面给出一套可用于询价、比选和立项的拆分方法。实际价格和周期需根据样本、权限、接口、部署环境与验收要求核定。
一、先看六项成本边界
| 成本边界 | 需要确认的问题 | 典型交付物 | 容易漏算的工作 |
|---|---|---|---|
| 数据准备 | 文档来自哪里，是否扫描件、表格、图片或版本混杂 | 数据清单、清洗规则、分块策略、异常报告 | OCR复核、重复文档、历史版本与坏链接 |
| 检索与生成 | 需要找原文、汇总答案，还是执行计算与流程 | 索引、检索策略、回答模板、引用与拒答规则 | 重排、查询改写、长文档处理与上下文成本 |
| 权限与安全 | 不同部门、岗位、项目能看到什么 | 角色矩阵、权限过滤、审计日志、脱敏规则 | 权限变更同步、离职回收、源系统权限漂移 |
| 系统集成 | 是否连接OA、ERP、MES、客服、门户或Agent | 接口清单、身份接入、业务流程与异常处理 | 单点登录、限流、重试、写回与人工确认 |
| 评测与验收 | 什么叫“答得对”，哪些错误不可接受 | 评测集、评分规则、验收报告、问题闭环 | 只测流畅度、不测检索证据和权限泄露 |
| 运行与维护 | 谁更新资料、处理反馈、监控成本和质量 | 运营SOP、监控看板、版本记录、应急预案 | 文档更新、索引重建、模型变更与持续复核 |
这六项不是六个必须采购的模块，而是询价时必须澄清的六类工作。某些试点可以很轻，但如果有一项属于高风险，就不能在方案里省略。例如，内部制度问答的页面很简单，但只要存在部门级保密文件，权限继承与审计就可能成为主要工作量。
二、文档量为什么不能直接等于项目费用
文档量会影响处理资源，却不能单独代表复杂度。以下三组资料，即使文件数量相同，建设难度也可能完全不同：
- 结构清晰、可复制文本、版本唯一的制度文件；
- 含扫描页、复杂表格、图片标注和多版本附件的工程资料；
- 来自多个系统、随业务持续更新，并带项目级或字段级权限的资料。
第一组可能通过统一解析和简单更新机制完成；第二组需要OCR、版面分析、表格抽取和人工抽检；第三组还要设计增量同步、身份映射、权限过滤、失败补偿与审计。采购时若只比较“支持多少文档”，容易把真正的实施成本藏到后续变更里。
微软的RAG架构指南把内容准备、分块、向量化、检索与评测视为连续流程；其文档也指出，过大的分块会增加处理成本并影响结果。Google Cloud公开的RAG计费说明则把摄取、解析、嵌入、向量检索和重排分别列为可能产生费用的环节。它们说明同一个“知识库”名称背后，实际工作链条并不相同。
三、用三级范围判断首期应该做到哪里
| 范围 | 适用条件 | 首期建议包含 | 暂不包含 |
|---|---|---|---|
| 场景试点 | 一个部门、一个高频问题、资料边界较清楚 | 1—2类资料源、基础权限、代表性问题集、引用与拒答 | 多系统写回、复杂审批、全公司知识治理 |
| 部门级应用 | 多角色使用，资料持续更新，需要稳定运营 | 增量同步、角色权限、反馈闭环、质量与成本监控 | 跨组织统一身份、全部历史资料一次迁入 |
| 企业级能力 | 多部门、多系统、多权限域，知识要进入流程 | 统一接入、身份权限、治理规则、评测体系、运维与审计 | 没有责任人的“全量先上再说” |
范围越大不一定越好。首期目标应是验证一个完整闭环：资料能持续进入，用户只看到有权限的内容，答案带可核查证据，无法回答时能拒答或转人工，运营人员能定位问题并更新知识。
如果企业尚未形成资料责任人和更新机制，直接建设企业级平台往往会把“文档没人维护”的组织问题变成技术项目的长期故障。
四、用全成本公式比较供应商方案
可把三年总成本拆为：
总成本 = 一次性建设 + 云资源与模型调用 + 数据治理与人工复核 + 运维监控与升级 + 风险预留。
一次性建设包括需求梳理、数据处理、检索链路、前后端、身份权限、系统接口、评测与上线；运行成本包括模型、嵌入、向量检索、存储、网络、日志和备份；人工成本包括文档整理、问题裁决、权限复核、运营反馈与异常处理。
下面是方法推演，不是白泽报价或客户实测：假设一个部门试点有四个资料源、三类用户角色，并准备一百个代表性问题。方案A首期开发较低，但每次资料更新都需人工全量导入；方案B首期增加增量同步和权限映射，开发工作更多，却减少后续重复整理。两者不能只比首期金额，应按预计更新频率、人工工时、调用量和风险损失放到同一周期计算。
询价时建议要求每家供应商使用同一张工作分解表，明确“包含、可选、客户负责、不在范围”四种状态。否则，一个只含演示界面的报价和一个包含数据治理、权限、验收与运维的报价没有可比性。
五、报价前需要准备的最小输入
不必先整理全部企业资料。准备以下最小输入，就能让范围和报价明显更准确：
- 一个优先业务问题，以及不做这个项目的当前成本或风险；
- 文档清单：来源、格式、数量级、总容量、更新时间、责任人；
- 三至五类典型用户及其可见范围；
- 约五十至一百个代表性问题，覆盖正常、模糊、无答案和越权请求；
- 现有系统及接口：身份、OA、ERP、MES、客服、门户或其他应用；
- 部署与安全要求：云端、专有网络、本地环境、日志留存、脱敏与审计；
- 期望的响应速度、并发、服务时段和故障恢复要求。
其中“五十至一百个问题”是首轮评测集的建议起点，不是行业统一标准。问题风险高、场景多或资料差异大时，应扩大并分层；问题非常集中时，可以更小，但必须覆盖关键失败情况。
六、交付物和责任边界要写进合同
一个可验收的企业知识库项目，至少应说明以下输出由谁交付、由谁确认：
| 阶段 | 供应方输出 | 企业需要提供或确认 |
|---|---|---|
| 诊断 | 场景边界、资料与接口清单、风险假设 | 业务负责人、资料样本、不可接受错误 |
| 设计 | 架构、分块检索、权限、部署与评测方案 | 身份体系、网络与安全约束、验收人 |
| 实施 | 数据处理、索引、应用、接口、日志与操作说明 | 测试环境、接口账号、业务裁决 |
| 验收 | 冻结版本、评测结果、问题清单、上线与回退方案 | 按场景签字，不临时改变评分口径 |
| 运营 | 监控、反馈、更新、备份、升级与应急机制 | 知识责任人、权限复核、持续预算 |
责任边界最容易出问题的地方是资料质量和业务裁决。供应方可以建立处理和评测机制，但不能替企业决定哪一版制度有效、谁能看某份文件、某个答案是否符合业务规定。这些决策必须有企业责任人。
七、验收不要只问“回答准确率”
知识库验收至少同时检查四层：
- 检索层：相关证据是否被找到，关键资料是否漏检；
- 回答层：回答是否被证据支持，引用能否回到原文；
- 权限层：无权限用户是否看不到文档、片段、标题和答案线索；
- 流程层：拒答、转人工、反馈、更新和故障恢复是否有效。
准确率的分母、样本来源、评分人和通过门槛必须提前约定。对于高风险问题，建议单独设置严重错误与权限泄露的停止条件，不能用大量低风险问题的平均分掩盖。
八、公开案例说明：资料规模只是一个维度
白泽公开的污染源普查智能体案例涉及9.5GB、1200余份异构资料。这个案例能公开说明的是：资料规模之外，还存在GIS、现场字段、计算逻辑、报告生成和业务流程衔接等工作。因此，类似项目不能只按“多少GB”估算。
这不是所有企业知识库的标准配置，也不代表上述规模对应某个固定价格。它用于说明一个范围判断原则：当知识需要进入计算、填报、审批或现场作业，项目边界已经从“问答工具”扩展为“受控业务系统”。
九、什么情况下应先暂停采购
出现以下情况时，建议先完成范围诊断，再决定是否建设：
- 说不清首个使用场景，只希望“把所有资料放进去”；
- 没有资料责任人，历史版本也无法判定有效性；
- 权限要求严格，但源系统没有可复用的身份或权限信息；
- 要求零错误，却没有代表性问题、裁决规则和人工兜底；
- 计划让系统直接执行高风险动作，却没有审批、日志和回退；
- 只比较模型参数或演示效果，不接受交付物和验收责任写进范围。
暂停不是否定项目，而是避免用开发预算替代业务决策。
十、给决策者的一页清单
立项前逐项回答：
- 核心问题能否用一句话说明？
- 首期服务哪类角色，明确不服务谁？
- 哪些资料进入，哪些资料暂不进入？
- 权限是否能从现有身份体系继承并持续更新？
- 代表性问题与严重错误是否已定义？
- 答案是否必须带出处，哪些情况必须拒答？
- 需要读取哪些系统，是否允许写回？
- 谁负责资料、权限、质量、运维和最终验收？
- 三年全成本是否包含人工治理和升级？
- 项目失败时，如何停用、回退和保留证据？
如果这十项已有大部分答案，可以进入方案比选；如果答案仍主要是“后面再说”，先做短周期诊断更合适。
白泽提供企业RAG与知识库开发服务，可从场景、资料、权限、评测、部署和运维六个边界共同核定范围。咨询前建议准备：一份脱敏资料样本、现有用户角色、十到二十个典型问题，以及需要连接的系统清单。我们会先判断是否适合做、首期做到哪里，再讨论实施方案。
白泽智能｜重庆斯巴达信息技术有限公司
一手资料与边界
- Microsoft Azure Architecture Center，Design and develop a RAG solution，核验于2026-10-26：官方文档。
- Microsoft Azure Architecture Center，Chunking phase for a RAG solution，核验于2026-10-26：官方文档。
- Microsoft Azure AI Search，Document-level access control，核验于2026-10-26：官方文档。
- Google Cloud，RAG Engine billing，核验于2026-10-26：官方文档。
本文未取得可核验的搜索量、热榜或统一市场报价；没有使用客户内部聊天、账号、配置或未公开故障。文中的三级范围、一百问题示例和总成本公式属于编辑方法与方案推演，不代表任何客户的实际报价、周期或成绩。