想上知识库客服的团队，多半卡在同一个地方：问了几家，报出来的数字差好几倍，也不知道差在哪。这篇不给你一个标准价，而是把一套报价拆成能逐项核对的几块，告诉你每块受什么影响、什么情况下报价会明显偏离常规，最后给一套按自己业务量估区间的动作顺序。
想上知识库客服的团队，多半卡在同一个地方：问了几家，报出来的数字差好几倍，也不知道差在哪。有人报得低得离谱，有人报得高得吓人，你拿着两张报价单放一起，连是不是在说同一件事都判断不了。这篇不给你一个标准价，而是把一套报价拆成能逐项核对的几块，告诉你每块受什么影响、什么情况下报价会明显偏离常规，最后给一套按自己业务量估区间的动作顺序。
先说清楚一件事：知识库客服没有「一个」市场价，只有「一套配置对应的一个区间」。同一个产品，接三个入口和接一个入口不是一个价，语料是干净的 Markdown 和散在聊天记录里也不是一个价。所以你的目标不是问出最低价，而是先把自己这边的变量数清楚，再拿变量去换报价。下面按四块拆开讲。
一套报价拆成哪几块
拿到报价单第一件事，是看能不能拆。拆不到四块就谈不下去：接入与实施、知识库搭建与语料整理、模型调用量、后续维护与席位。这四块的计价逻辑完全不同，混在一栏里写的「整体方案一价全包」，后面加需求时你没有任何议价依据。
| 费用块 | 典型计价口径 | 这一块最容易被模糊的地方 |
|---|---|---|
| 接入与实施 | 按人天或按项目一次性 | 不写清包含几个入口、几轮测试 |
| 知识库搭建与语料整理 | 按文档页数、按人天 | 不写清脏数据谁负责清洗 |
| 模型调用量 | 按 token、按对话量、按包月 | 口径不同，数字不可比 |
| 维护与席位 | 按坐席数、按年、按量 | 把一次性费用摊进月费里 |
- 一次性费用和持续性费用分开看，把按月摊的和一次付的混在一栏报价里，是最常见的模糊手法
- 按坐席数、按对话量、按知识库容量、按调用 token 计费，这四种口径下的数字没有可比性，先统一口径再比价
- 拿一张表把每家报价按同样四块填进去，填不满的就是没讲清，先让对方补齐再说下一轮
- 选服务方时先去站内 /sites 和 /providers 对着目录找能说清口径的，讲不清计费维度的直接排除
什么在把价格往上推
价格往上走，通常不是模型本身贵，而是你这边的活儿多。同样一句「帮我查订单」，背后是直接命中一条 FAQ，还是先理解意图、再调订单接口、再把结果组织成人话，工作量差着数倍。对方报价高，多数时候高在实施和语料，不高在调用。
- 语料量和脏数据程度：文档散在聊天记录、PDF、表格里，整理成本往往比模型调用费还高，语料越乱这块占比越大
- 问法复杂度：只答固定 FAQ 和要跨文档推理、要调订单系统，是两种活，后者的实施工作量不是一个量级
- 并发与响应要求：高峰期同时在线人数、要不要流式、允许多少秒返回，直接影响选哪档模型和要不要加缓存
- 接入范围：只接网页客服，还是要把公众号、小程序、电话都接进来，每多一个入口就多一份对接和测试工作
- 脏数据占比
- 原始文档里格式混乱、内容重复、互相矛盾的部分占总量的比例，这个比例越高，语料整理越贵
- 意图分支数
- 用户问法能归成多少类不同意图，分支越多，知识库结构和测试用例越多
- 并发峰值
- 同一时刻同时在问的人数，这个数决定要不要上更快的模型和加不加缓存层
判断自己属于哪一档，别靠感觉。把最近一段时间的真实咨询记录拉出来，数一下有多少条能被现有文档直接回答、多少条要跨文档、多少条要查系统，三个数一出来，你就知道自己该按哪一档去问了。
什么情况下能压下来，什么情况下压不动
压价不是砍总价，是砍掉自己不需要的部分。问答范围收窄、语料本身干净、计费方式选按量，这三条同时成立时报价会明显低一档，因为对方要干的活确实少了。但只要涉及内部系统实时查询、回答审核留痕、多语言支持，价格就压不下去，硬压只会换来一个交付不了的方案。
- 能压：问答范围收窄到几十条高频问题、语料本身已是干净的结构化文档、用按量计费而不是包坐席
- 压不动：要接内部系统查实时数据、要对回答做审核留痕、要支持多语言，这几条只要占一条，就不适合拿低价方案去套
- 别只看首年：低价常见做法是首年实施费压得很低，把成本挪到后续的语料维护和调优上，算总账要去 /price-watch 看同类项目的价格变动
- 不适用的情况：如果业务量本身还没跑通、每天真实咨询量很少，任何报价都属于提前投入，先把量跑起来再谈价
按自己的量估一个区间的动作顺序
与其到处问价，不如先自己算。模型调用这一块是唯一你能独立算准的部分，其余三块用「需要几个人天」去问，比要总价有用得多。下面这套顺序走完，你手里会有一份自己的估算底稿，再拿去和报价对。
- 统计自己的真实数据日均咨询量、高峰并发、现有文档页数和格式，这三个数决定了你在报价表里的位置；没有这三个数，对方只能给你一个泛泛的区间
- 单独算模型调用用站内 /official-api 和 /tools/model-cost-calculator 把调用这一块自己算出来，这是唯一不依赖对方解释的部分
- 按人天估实施与语料整理直接问对方「整理我们这批文档需要几个人天」，答不上来的报价基本靠猜，答得具体的才值得往下谈
- 拿底稿去比解释用自己算出的数字去问两三家，比谁的解释更贴合你的场景，而不是比谁的总价更低
- 核对同类成交最后到 /price-watch 看同类项目的价格变动趋势，确认自己的估算没有偏离常识范围
常见问题
知识库客服是不是越便宜越好？
不是。低价通常省在语料整理和实施深度上，上线后答不准、需要人工兜底的比例高，反而多花人力。判断办法是让对方说明语料整理投入多少人天、效果不好时的调优怎么算钱，说得清楚的低价才值得选。
我只有几百条常见问题，要不要上知识库客服？
量少的时候，先用规则或关键词应答加人工兜底更划算，知识库客服的价值在问题多、问法散、需要跨文档找答案时才体现出来。可以先统计一下重复问题占比，占比高且问法多样，再考虑上。
报价里模型调用费为什么会差这么多？
差在两点：用哪档模型、每次问答塞多少上下文。要跨文档检索的方案每次会带进大段资料，单次消耗远高于只答固定问答。这部分可以自己算，去站内 /official-api 对单价、用 /tools/model-cost-calculator 套自己的量。
