十万 token 文档问答该派给谁：一把 key 上按上下文窗口与召回质量选后端

处理十万 token 级别的文档问答时，很多团队的第一反应是比较哪家 API 单价更低。但实际效果差异往往来自两个更关键的因素：有效上下文窗口和答案保真度。同一个 API key 可以调用多个模型，这为按任务选后端提供了便利，但也需要一套选择方法。

有效上下文窗口不等于标称值

各后端都会标注最大上下文长度，但“能塞进去”和“能准确回答”是两件事。有效上下文窗口指模型在长文档中稳定定位并利用相关信息的能力。通常：

• 文档越接近窗口上限，位置靠中间的信息越容易被忽略（“中间迷失”现象）。
• 需要跨段落综合推理时，部分模型的表现下降更明显。
• 窗口内无关内容越多，召回质量越难保证。

因此选型时，应把“标称窗口”打一个折扣，用实际文档长度和问题类型去测试。

答案保真度比价格更影响总成本

保真度指答案是否忠实于原文、是否遗漏关键条款、是否引入文档外的内容。对于合同、技术规范、研究报告等场景，一次错误答案的返工成本远高于 API 费用。按官方价 ×1.3 扣费的模式下，单价差异在总成本中占比有限，保真度才是主要变量。

按文档长度和问题类型选后端

在没有统一基准的情况下，可以按以下思路缩小范围：

• 超长文档、需要全局理解：优先测试标称窗口大且长文评测口碑较好的后端，如 Claude 和 Kimi 的长上下文版本。
• 结构化文档、条款抽取：GPT 系列和 Qwen 在指令遵循和格式稳定性上通常表现均衡，适合需要精确引用原文的场景。
• 中文文档、本土语料：Qwen、GLM、DeepSeek 对中文长文的处理往往更自然，适合政策文件、中文报告。
• 成本敏感、问题较简单：DeepSeek 等后端在短问答上性价比高，可作为初筛或降级方案。

这些只是起点，最终应以你自己的文档样本测试为准。

用一把 key 做 A/B 测试

聚合站的价值在于同一个 API key 可以切换后端。建议建立一个小型评测集：

1. 从真实文档中抽取 20–50 个问题，覆盖事实查找、跨段推理、否定条款等类型。
2. 对每个后端记录答案正确率、引用准确率和响应时间。
3. 按文档长度分桶（如 10k、50k、100k token），观察性能拐点。
4. 将结果固化为路由规则：不同长度或问题类型走不同后端。

路由与降级的实用策略

• 主备路由：主后端超时或返回质量低时，自动降级到备选后端。
• 分段召回：文档远超有效窗口时，先检索相关段落再送入模型，而不是硬塞全文。
• 引用校验：要求模型输出原文片段，便于人工或程序校验保真度。
• 成本监控：按 ×1.3 的扣费口径统计各后端实际消耗，结合保真度做取舍。

贡献 key 返 USDC 的视角

如果你同时向平台贡献 key，按官方价 ×1.1（优质 ×1.2）返 USDC。这不会改变选型逻辑，但意味着你可以把自建评测中表现好的后端优先贡献，形成“自己用得好、也能被他人调用”的正循环。

小结

十万 token 文档问答的选型，应先看有效上下文窗口和保真度，再看价格。用一把 key 做小规模 A/B 测试，把结果写成路由规则，比单纯比较单价更可靠。