先解决一个预算误区：知识库与白帽服务不是替代关系
企业在编制AI预算时，可能同时收到知识库建设方案和白帽服务报价，于是直接比较年度金额，判断哪一项更值得采购。这种比较缺少共同的收益口径。AI知识库处理的是资料解析、检索、权限控制和答案生成，主要目标是降低员工或客户获取知识的成本。白帽服务如果指安全众测、漏洞赏金或人工安全测试，处理的是提示词注入、权限绕过、接口缺陷和业务逻辑漏洞，主要目标是降低安全事件造成的预期损失。
标题中的“白帽服务”因此需要明确限定为安全服务。现有资料不能支持所谓白帽GEO服务的价格、排名效果或平台采信机制。如果采购范围实际是官网内容治理、AI可见度监测或生成式搜索优化，应另行核算内容生产、事实审核、技术改造和持续监测成本，不能套用漏洞赏金或安全众测数据。
这篇文章真正要回答的问题是：当企业同时需要建设知识调用能力和控制AI应用风险时，两类预算应如何核算，哪一项应先投入。编辑判断是，两项投入可以进入同一张年度预算表，但不能强行合并为一个ROI。知识库应证明它减少了多少有效问答成本，白帽服务应证明它覆盖了哪些风险以及企业是否有能力完成修复。
建立模型前，先固定范围、账期和工作量
“自建知识库”不等于所有组件都部署在企业机房。企业可以自行掌握文档、权限、评测和应用逻辑，同时采购托管模型、向量存储或检索服务。预算模型应按能力归属拆分，而不是仅按供应商合同名称分类。需要记录的边界至少包括文档由谁整理、索引存放在哪里、模型按量还是按套餐计费、日志能否导出，以及停止采购后数据和评测资产能否继续使用。
账期可以先按月建立，再汇总为年度预算。知识库一侧记录原始文档量、索引数据量、问答次数、每次检索调用数、平均输入与输出Token、缓存命中率、失败回答和维护工时。白帽服务一侧记录测试资产数量、测试范围、有效漏洞数、重复报告数、内部验证工时、修复周期和复测结果。
币种和计费单位也必须统一。AWS公开示例使用美元，腾讯云公开套餐使用人民币；有的服务按Token、存储量和检索次数结算，有的采用月度预付费与积分制。腾讯云TokenHub企业版专业套餐的公开说明还显示，当期未使用积分不能结转，模型库和部分服务保障可能调整。预算人员不能直接把不同厂商的月费相加比较，应先换算为相同工作量下的含税年度成本，并单独列出预付额度浪费和模型迁移风险。
知识库要算总拥有成本，不能只看每百万Token价格
知识库年度总拥有成本可以表示为：模型推理费用＋索引与存储费用＋检索费用＋应用基础设施费用＋内部治理与运维人力＋迁移及停用成本。模型推理费用还应拆成输入Token、输出Token、缓存创建、缓存命中和批量任务。不同调用方式不能重复计算优惠。
阿里云2026年9月15日发布的模型定价资料显示，部分模型会按单次请求的输入长度分档，并对该请求的全部Token应用对应价格。支持批量调用的模型，输入和输出单价可降至实时推理的50%；缓存命中输入可按标准输入价的10%计费，但批量与缓存优惠不能同时使用。这意味着企业不能只拿目录单价乘以年度Token量，还要区分实时问答、离线批处理和可复用上下文。
检索架构可能比生成模型更影响账单。Amazon Bedrock的公开示例中，50GB原始数据、约10万份文档和每月10万次标准检索的费用为350美元；在相同数据规模下，改用代理式检索且平均每次触发两次底层检索，示例费用升至850美元。这两项示例均未包含最终答案生成的模型Token费用。AWS另一项高规模应用示例按每天8000次交互测算，基础应用约577.76美元/月，加入嵌入和OpenSearch Serverless后，知识库增量约700.20美元/月。
不同产品的免费边界并不相同。阿里云百炼文档所述路径不收取知识库创建、日常管理和单独Retrieve API检索费用，但召回片段进入模型上下文后，仍会增加输入Token和推理费用。因此，“检索免费”不等于一次知识问答没有检索相关成本；分块过碎、召回片段过多或上下文过长，都可能把成本转移到模型输入端。
知识库应同时计算两个单位指标。单位问答成本等于当期全部技术和人力成本除以问答总量；单位有效回答成本则只把通过准确性、权限、时效性和证据检查的回答计入分母。后者更适合预算决策，因为大量低质量回答会让表面上的单次调用价格很低，却不能形成可用收益。验证时应使用企业自己的文档和真实问题集运行一个完整账期，不宜根据云厂商示例直接判断哪套方案更便宜。
白帽服务不能按新增收入估值，要看风险是否真正被关闭
外采白帽服务的显性支出包括平台或项目费用、漏洞赏金和专项测试费用。内部成本包括资产范围确认、漏洞验证、重复报告处理、修复、复测和跨部门协调。Bugcrowd在2025年发布的SaaS众测指南指出，项目如果缺少专家验证、去重和优先级判断，重复或低质量报告可能成为企业内部瓶颈。外部研究人员可以扩大测试覆盖，但不能替代企业自己的修复责任。
白帽服务的收益更适合表示为：预期事故损失下降＋内部检测成本节省＋发现时间缩短带来的风险减少－新增处置成本。这里最难估算的是事故概率变化。企业可以使用自身历史事件、现有控制缺口、行业基线或受控演练结果，但不应为了得到漂亮的ROI而填入未经验证的概率。
HackerOne在2025年10月公布的平台报告称，有效AI漏洞报告同比增长210%，提示词注入报告增长540%。这些数据说明AI资产正在成为安全测试对象，但它们来自该平台覆盖的项目，不能直接代表所有企业的漏洞增长率。报告中的约15倍安全回报也基于该公司的Return on Mitigation方法，不应直接写入企业财务预测。
概率证据不足时，可以采用高、中、低三种情景。每种情景分别填写潜在损失、事件概率、外部测试可能发现的缺陷范围以及企业完成修复的比例。白帽服务的价值只有在漏洞得到确认和关闭后才能兑现。如果企业没有修复资源，继续扩大众测范围可能增加待处理报告，却未必降低实际风险。
适合纳入验收的指标包括单位有效漏洞成本、严重漏洞首次发现时间、有效报告比例、重复报告占用工时、修复关闭率和复测通过率。不宜把收到的报告总数直接当作项目成果，因为报告数量增加既可能表示覆盖扩大，也可能表示范围定义不清或重复提交过多。
预算优先级取决于需求成熟度和系统暴露面
如果企业资料分散、员工反复查找同类信息，但AI应用尚未对外开放，可以优先建设范围受控的知识库。此时先处理文档版本、访问权限、评测问题集和有效回答成本，再决定是否扩大模型和检索预算。安全工作仍然需要进行，但未必需要立即启动大规模外部众测。
如果AI应用已经面向客户、合作方或大量员工开放，并连接业务接口、客户数据或自动执行工具，外部安全测试的优先级会明显提高。攻击面可能跨越模型提示、身份认证、API、插件和业务流程，仅依靠常规问答准确率测试不足以判断风险。此时应先确认测试授权、资产范围、数据处理规则和漏洞响应负责人，再启动白帽项目。
多数中大型企业更适合混合配置。企业内部保留知识事实、文档版本、权限规则、评测问题集、漏洞确认和修复优先级；模型算力、向量存储和部分检索能力可以按量采购；安全测试则借助外部团队扩大技能和时间覆盖。混合配置不一定拥有最低合同价格，但可以减少关键能力完全依赖单一供应商的风险。
还有一种应暂缓立项的情况：资料没有明确责任人，知识库回答无法验收；或者系统虽已上线，却没有漏洞接收、验证和修复流程。在这些条件下继续采购，容易把治理缺口变成更多Token消耗或更多待处理报告。先补齐内部责任链，通常比扩大外部服务范围更有价值。
用一个完整账期验证模型，再决定是否扩大投入
知识库试点可以先选定一组高频且有明确答案的问题，记录文档量、索引规模、问答次数、平均Token、检索次数、响应时间、人工维护工时和有效回答比例。第二个账期只改变一个主要变量，例如启用缓存、调整召回数量、替换向量存储或把离线任务改为批量调用。变量同时变化过多，就无法判断成本下降来自模型价格、检索设计还是问题结构变化。
白帽服务试点应选择边界清楚的AI应用或接口，预先定义可测试资产、禁止行为、漏洞严重度标准、内部响应时限和复测条件。项目结束后，不只统计漏洞数，还要检查有效报告比例、内部验证工时、修复积压和关闭结果。若大部分预算消耗在重复报告处理或长期未修复问题上，应先收缩范围并改进流程，而不是直接追加赏金。
两类项目都需要设置停止或调整条件。知识库连续两个账期未能改善有效回答成本，且主要问题来自资料缺失或责任不清时，应暂停扩大算力。白帽项目发现的问题长期无法进入修复排期，或测试范围与真实资产持续不一致时，也应暂停扩容。预算控制的重点不是把云端单价压到最低，而是确认每项费用买到了可持续使用的能力。
最终应保留在企业内部的资产包括事实版本、权限规则、评测问题集、成本明细、漏洞确认记录和修复决策。模型、检索服务和测试覆盖可以外采，但关键数据应能够导出、复查和交接。这套模型不能保证降低总成本，也不能保证消除安全事件；它的作用是让管理者看清费用对应的工作量、收益适用的条件，以及采购结束后企业还保留了什么。