前言

上个月接了个活：给客户的知识库做问答。文档动辄几万字，第一版方案我用的是"最直觉"的做法——把整篇文档塞进长上下文模型直接问。

能用，但一算账单我就坐不住了。于是花了一个周末做了几种架构的对比实测，结论是：同样的问题，最贵方案和最省钱方案的账单差了 20 倍，而回答质量的差距远没有账单差距大。

这篇把测试过程和架构结论分享出来。

一、四种架构，从贵到便宜

方案 A：全量长上下文（直觉方案）

整个文档塞进 prompt，每次提问都带全量。

账单构成：每次请求输入 ≈ 30k tokens
10 个问题 = 300k 输入 tokens（还没算重复）

问题显而易见：每个问题都在为整篇文档重复付费。

方案 B：文档摘要 + 分段路由

预处理阶段做一次性投资：让模型把文档切成章节并生成每章摘要（这笔钱只花一次）。用户提问时，先用摘要判断问题落在哪些章节，只把相关章节塞进上下文。

预处理：一次性 ≈ 40k tokens（全文档摘要）
每次提问：≈ 3~6k tokens（2~3 个相关章节）

方案 C：传统 RAG（embedding + 向量检索）

最经典的方案：切片、embedding 入库、检索 top-k。精度取决于切片和 embedding 质量，工程复杂度最高。

方案 D：B + C 混合

摘要路由做粗筛，向量检索做精排。

二、实测结果（3 万字技术文档，20 个测试问题）

方向性结论，模型迭代快，请以自己的实测为准。

方案 单问题输入 tokens 20 问总成本* 回答质量
A 全量长上下文 ~30k 最高（基准） 最全，偶尔引用错位
B 摘要路由 ~5k 约基准的 1/6 90% 的问题无感知差异
C 传统 RAG ~2k 约基准的 1/10 依赖切片质量，细节准但全局弱
D 混合 ~3k 约基准的 1/8 细节与全局兼顾

*成本还与模型单价相关：我用聚合网关的实时倍率计价（用的 Rqu AI，价格在模型广场透明可查），不同端点请按自己的单价换算。

质量上的关键发现：方案 A 输了两次——问"全文的核心论点是什么"这类全局问题时，长上下文模型反而会"只见树木"；方案 B/C 输在跨章节问题（"第 3 章和第 7 章的观点矛盾吗"）。混合方案 D 是唯一没有明显短板的。

三、一个容易被忽略的成本杠杆：模型分层

同样的架构，模型选择还能再砍一半：

  1. 摘要路由这一步（判断问题属于哪章）是轻量任务，用便宜模型足够——这一步占每次请求 tokens 的 5%，却常常被人用旗舰模型跑；
  2. 真正需要质量的只有最终回答那一步，才值得上好模型；
  3. 预处理摘要是一次性投资，用中档模型跑一遍即可。

我的最终配置：路由用 deepseek 级（约 0.001 元/次），回答用 sonnet 级。整体账单比"全量长上下文 + 全旗舰"方案省了约 95%。

四、什么时候直接用方案 A

公平起见，三种情况长上下文直塞依然是正解：

  1. 文档 < 1 万字——切分的工程成本超过 token 成本；
  2. 问题高度不可预测且全是全局性问题——路由会漏；
  3. 一次性任务——不值得搭管线。

我的经验阈值：文档超过 2 万字、且会被反复提问，才值得上 B/C/D 架构。

五、复现清单

  1. 一个 OpenAI 兼容端点（聚合网关最方便，切模型不改代码）；
  2. 预处理脚本：按标题切章 → 逐章摘要（一次性）；
  3. 路由脚本：问题 + 章节摘要列表 → 让便宜模型输出相关章节号；
  4. 回答脚本：问题 + 相关章节原文 → 好模型输出答案；
  5. 记账：每次调用打日志，按方案分组统计——没有账单数据的优化都是自我感动。

系列上一篇《四模型横评》里的成本估算方法可以直接复用在这里。

六、结论

  1. 长上下文能力解决了"塞得进去"的问题，但没解决"每次都重复付费"的问题；
  2. 文档越长、复用越多，路由架构的收益越大；
  3. 模型分层是第二重杠杆：路由用便宜的，回答用好的；
  4. 先测量再优化——把每次调用的 token 记下来，账单会告诉你答案。