长上下文不等于好用：企业为什么不应无限往 Prompt 里塞资料？

去年帮一家金融公司做客服系统升级时，技术负责人直接把三万条历史工单和整本理财产品手册塞进了 Claude 3 的 200K 上下文窗口。上线第一周，单次对话成本飙到了标准版的二十八倍，用户等待首字回复的时间超过十五秒，更麻烦的是，模型经常漏看产品风险提示——这些信息明明就躺在文档中间段落。

这不是个例。当长上下文窗口突破 200K 甚至 1M tokens，”全量塞进 Prompt”似乎成了最省事的工程方案，但账单和体验很快会教人重新算账。

200K 窗口的账单：成本不是线性增长

以当前主流模型的定价来看，128K 级别的长上下文输入成本通常是 4K 基础版本的 5 到 10 倍。假设一份 500 页的技术白皮书约 100K tokens，若每次查询都全量输入，单次调用成本就超过 1 美元。一个日活过万的企业内部知识助手，如果每位员工日均查询十次，月度 token 费用轻松突破三万美元。更隐蔽的是，多轮对话中重复携带的会话历史会让这个数字持续膨胀，形成”越聊越贵”的恶性循环。

噪音与注意力稀释：中间的内容模型根本看不见

斯坦福 2023 年的研究已经证实，大模型对上下文中间位置的信息召回率显著低于首尾。在 200K 级别的超长文本中，被埋在中间的政策条款或关键参数，实际被模型有效利用的概率可能不足三成。你塞进去的资料越多，真正的信号就越容易被噪声淹没。前文提到的金融客服案例，正是因为风险提示 buried 在手册第 80 页，模型反而”视而不见”，给出了不合规的回答。

延迟是隐形的体验杀手

全量加载 200K tokens 的首 token 延迟（TTFT）在多数云服务商环境下通常达到 10 到 30 秒，而只加载 5K 精确定位内容的 TTFT 可以控制在 2 秒以内。在企业微信或钉钉机器人场景里，让用户等待超过五秒，对话放弃率就会陡增。长上下文不是免费午餐，每一次全量推理都在消耗用户的耐心，也在消耗服务端并发池的容量。

正确的做法：切片、缓存与按需检索

真正落地的方案应该像图书馆管理员，而不是背诵整本书的考生。

首先是知识切片。把 500 页手册按语义切成 512 或 1024 tokens 的片段，配合向量数据库做语义检索。用户问”赎回费率”，只把相关的三段文本——而不是整本手册——送进 Prompt，输入量立刻从 100K 降到 2K，成本与延迟同步下降。

其次是上下文缓存。对于系统提示词、常用法规条文这类固定前缀，可以使用上下文缓存技术只计费增量部分。Google Gemini 的 Context Caching 已经允许缓存最多 100 万 tokens 的共享上下文，把重复调用的成本砍掉九成，同时保留长窗口作为兜底能力。

最后是按需检索（RAG）。在多轮对话中，不要每次都把历史记录全量打包。利用摘要工具保留对话关键节点，只有当前轮次涉及新知识点时，再从知识库检索补充。某头部电商客服在改造后，单次调用 token 数从平均 45K 降到 3K，成本下降 90%，关键信息准确率反而提升了 12 个百分点。

结语

长上下文窗口是兜底能力，不是日常方案。企业的目标不是把资料库搬进 Prompt，而是在模型需要的那一刻，精准地递上恰好够用的信息。省下的算力预算和等待时间，才是真正能转化为业务价值的部分。