本文是「企业问数系统落地」系列第十一篇。前面十篇讲的是能不能答对这篇讲另一个同等重要、但在选型阶段几乎没人问的问题答得贵不贵、快不快、扛不扛得住。一、两个反直觉的事实聊性能成本之前先说两个我在实际项目里反复观察到的现象。事实一用户对延迟的容忍度比产品团队想象的低得多。很多人会说业务问个数据等十几秒有什么关系。实际上关系很大一个人在等 5 秒时会自然地盯着屏幕等等 20 秒时他会切到别的窗口、去回一条消息然后忘记自己在等什么等到 40 秒他宁可自己去翻报表。问数这种顺手问一句的场景本质上是低频决策 高频操作单次价值不高但如果每次都要等半分钟它就会被降级成实在没别的办法时才用——而一旦被降级这个系统的使用量就再也起不来了。事实二单次调用的成本看起来微不足道但会随规模线性放大并被两个隐藏因素加速。第二句是重点。一次提问的模型成本可能是几分钱级别听起来可以忽略。但真实成本结构是总成本 调用单价 × 提问次数 × 平均每次注入规模 ↑ ↑ 线性增长 这个会随运营非线性增长最后那个因子才是真正的坑随着样例库变大、规则变多、语义上下文变丰富如果注入策略是全量拼装单次成本会跟着资产增长一起涨。年终复盘时你会发现提问量涨了 3 倍账单涨了 8 倍。所以性能与成本工程的核心不是用更便宜的模型而是把每次请求要携带的信息量控制在恰好够用的范围。下面按延迟、并发、成本三条线拆。二、延迟先把一次提问拆开优化的前提是可测量。问数系统的一次请求天然分为五段各段的瓶颈和手段完全不同阶段做什么常见耗时量级主要优化手段① 意图理解解析问题、识别对象与指标、指代补全数十毫秒数百毫秒规则前置匹配、槽位缓存、跳过不必要的模型调用② 样例召回相似问法检索取 FewShot 示例数十毫秒数百毫秒向量索引、混合召回、召回条数收敛③ 查询生成生成可执行的查询语句数百毫秒数秒上下文精简、模型分级、输出长度约束④ 查询执行网关下发、数据库执行几十毫秒数十秒超时与限量、大查询隔离、结果集缓存、预聚合⑤ 答案加工结果转图表、组织三层答案数百毫秒数秒流式呈现、图表与结论并行、明细延后加载三个判断① 真正难压的是 ④而不是 ③。很多团队一开始盯着换更快的模型但实际线上慢查询往往来自执行段——一张大表做了全表扫描或者多表关联没有走对路径。这条线的解法是工程纪律超时、限量、并发配额、必要的预聚合不是模型工程。② ③ 和 ④ 可以部分重叠。不必等整段 SQL 生成完再执行结构化输出可以分段解析条件明确的部分可以先行下发。代价是工程复杂度收益在复杂问题上比较明显。③ 感知延迟比真实延迟更重要。先给结论、再补图表、最后可展开明细也就是三层答案的呈现顺序用户对整体 12 秒的体感会接近3 秒就有反馈。同样的耗时呈现顺序不同体验差距很大。一个可参考的性能预算表目标值非实测值按交互式场景设定阶段预算目标超预算时的处理① 意图理解≤ 0.5 s命中规则模板时直接跳过模型调用② 样例召回≤ 0.3 s召回条数上限收敛避免为了准牺牲速度③ 查询生成≤ 3 s限制输出长度禁止模型输出解释性长文④ 查询执行≤ 5 sP95超时即终止并给出可读提示不允许无限等待⑤ 答案加工首屏 ≤ 1 s结论先出图表与明细流式补上三、并发问数系统是典型的突发型负载这是做容量规划时最容易算错的地方。问数系统的请求分布不是平滑的而是集中在几个时间点早会前后8:30–10:00管理者问昨日/上周数据月初、季初各类汇总与对比集中爆发汇报材料截止前一天临时取数需求井喷这些峰值的瞬时并发可能是日常均值的十倍以上。如果你按均值配置资源峰值时就会看到查询排队、页面转圈、用户放弃。三件套队列、配额、隔离机制作用关键设计点查询队列峰值时按序处理而不是一起压垮数据库队列长度有上限满了给明确提示而不是静默超时并发配额限制同时执行的查询数按用户/按对象分别限额避免一个人独占大查询隔离重查询不影响轻查询复杂查询走独立通道或限定时段不和生产查询抢资源这三件事的实现位置很关键应该统一做在查询网关上而不是散落在业务代码里。网关是所有查询走向数据库的唯一出口只有在这里做限流、超时、审计规则才是一致的、可审计的、可调整的。这也是接入层设计的价值——前文讲接入层时更多在讲权限和安全其实它同时是性能治理的落点。缓存要分三层失效策略各不相同缓存层命中条件失效策略适用性同问缓存问题文本完全一致数据源更新即失效 / 短 TTL收益高、实现简单对月初重复问同一数字的场景非常有效语义缓存语义等价但表述不同同上且需谨慎比对语义等价性收益中等误命中代价高建议保守开启结果集缓存同一查询语句 同一数据版本按数据版本精确失效最安全的一层推荐优先做一个容易踩的坑缓存的失效必须跟数据更新挂钩而不是只靠 TTL。财务场景里一个过期的数字被当成最新值汇报出去代价比省下的那几秒大得多。宁可缓存期短一点。四、Token 账成本在哪里先把一次请求的输入结构摆开。典型注入由六部分组成对应 Prompt 工程化那篇的六层结构组成是否随资产增长优化方向系统角色与任务指令否固定精简措辞利用提示词缓存复用不变前缀语义上下文对象/字段/度量是建模越多越大只注入问题相关部分不注入全库业务规则是规则越攒越多按主题标签按需注入而非全量拼装FewShot 样例是样例库越大越多限制注入条数通常 3–5 条靠召回质量而非数量多轮历史是对话越长越大用槽位化状态替代原始历史见多轮追问篇输出否受输出格式约束约束输出长度禁止长解释看这张表就能明白为什么全量拼装是成本杀手第三、四、五行都是随运营增长的。你的样例库从 50 条涨到 500 条、规则从 20 条涨到 200 条之后如果还是每次全量注入成本会以十倍量级上涨而准确率并不会同步上涨。四条降本原则① 按需注入永不限量全拼。语义上下文只给问题涉及的对象与字段规则只给命中的主题标签样例只给召回的 top-k。这一条是全部原则里收益最大的。② 分级路由不是所有环节都需要最强模型。环节推荐档位理由意图理解 / 槽位抽取小模型或规则任务结构简单、可枚举、对延迟敏感查询生成主力模型决定正确率的核心环节不建议降配答案加工 / 措辞润色小模型纯文本组织不涉及业务判断澄清判断 / 话题切换检测规则优先可枚举的判定用规则更快更省见多轮追问篇常见的浪费是全链路一个模型打到底把最贵的模型用在润色措辞上。③ 多轮历史裁剪。用结构化的对话状态对象/指标/维度/过滤/时间范围代替原始对话文本长度基本恒定且不会随轮次增长。④ 复用不变前缀。系统指令等固定部分如果平台支持提示词缓存成本可以显著下降——注意把变化的内容放在提示词后部别把易变内容插在固定前缀中间否则缓存全失效。一个可套用的估算模型结构示意单价与用量需按实际填入单次成本 ≈ 输入token × 输入单价 输出token × 输出单价 查询侧资源成本 月成本 ≈ 月提问次数 × 单次成本 × (1 重试率) 优化前(全量注入, 资产规模 S) → 输入token ∝ S 优化后(按需注入, 资产规模 S) → 输入token ≈ C k·(单次相关规模) ← 与 S 基本解耦关键结论就一句按需注入让单次成本与资产规模解耦。资产可以继续长大这对准确率是好事而成本由单次请求的真实复杂度决定。五、性能不能靠感觉要进回归性能劣化是静默的没人会主动报告今天慢了 2 秒。两个机制可以兜住① 把性能纳入质量门禁。评测集回归时不仅看答对率也记录每题的端到端耗时。这样每次建模扩张或规则调整之后你能立刻看到准确率没掉但 P95 从 6 秒涨到 14 秒。② 线上盯分位值而不是均值。均值会被大量快查询稀释掉掩盖慢查询。P95/P99 才反映真实体感。执行层那些被超时终止的查询要单独计数——它们是用户失败但系统没报错的隐藏体验损失。六、五个反模式① 用均值做容量规划。问数是突发型负载均值毫无意义。请按峰值设计至少留三倍余量。② 全量拼接提示词。资产越大越慢越贵且规则互相干扰导致准确率反降——成本和质量双输。③ 全链路用同一个模型。把最强的模型用在措辞润色上是纯浪费把最弱的模型用在查询生成上是纯灾难。④ 只靠 TTL 做缓存失效。会算出一个过期数字而且没人知道它是过期的。失效必须挂数据版本。⑤ 性能不进回归。上线时 5 秒三个月后 30 秒中间没有任何一个时刻有人发现。七、检查清单#检查项状态1是否把端到端耗时按五段拆分测量而不是只看总时长☐2执行段是否独立设定了超时与结果限量且超时有可读提示☐3答案是否按结论 → 图表 → 明细顺序流式呈现首屏尽可能快☐4容量规划是否基于峰值而非均值并留有余量☐5查询队列、并发配额、大查询隔离是否统一做在查询网关上☐6缓存是否分了三层且失效策略与数据版本挂钩☐7语义上下文与规则是否按需注入而非全量拼装☐8是否做了模型分级路由避免全链路用同一档模型☐9多轮对话是否用槽位化状态替代原始历史控制长度恒定☐10评测回归是否同时记录耗时线上是否监控 P95/P99☐小结把这三条线并起来看延迟的关键不在模型而在执行段的工程纪律和呈现顺序的设计并发的关键不在堆机器而在把限流与隔离统一做在查询网关成本的关键不在换便宜模型而在让单次注入与资产规模解耦。三者的共同点是都不依赖更强的模型来解决而是依赖在架构上把该收口的地方收口。这也是我为什么一直强调查询网关和语义层这两个位置——它们既是正确性的支点也是性能与成本的支点。反过来说如果一个问数方案在演示时表现很好但你问不出执行段怎么限流提示词怎么按需注入缓存怎么失效这三个问题的答案那么规模化之后它大概率会变慢、变贵而且不会有人提前预警。文中性能数值为目标参考值与管理建议非产品实测指标成本估算模型为结构化示意需按实际单价与用量代入。平台能力方面查询网关超时、限量、并发控制与执行审计为产品内建性能预算设定、缓存分层、模型分级路由与性能回归方法为需结合项目实际落地的工程实践。欢迎在评论区交流你们的问数/LLM 应用成本优化实践——尤其想听样例库大了之后怎么把注入量压住的真实做法。