教程

Claude 200K 长上下文实战：何时用长上下文，何时上 RAG

发布：2026-06-25 · 约 12 分钟阅读 · 作者：ApiTopMix

TL;DR — 一句话结论

能塞进 200K 的知识，优先用长上下文——更简单、不漏检索。

超出 200K、要频繁更新、或对单次成本极敏感的海量知识库，才上 RAG。

降本两招：固定长文档用 prompt 缓存（约输入价 1/10）；走 ApiTopMix 折扣通道，Claude 比官方省 27%–40%。

"我有几十页 PDF，想让模型基于它回答问题，是不是得先搭个向量数据库做 RAG？" 这是我被问得最多的问题之一。

大多数情况下，答案是：不用。 你可能为一个本该五行代码搞定的需求，搭了一整套 embedding + 向量库 + 检索 + 重排的流水线。原因很简单——很多人还停留在"上下文很小，必须检索"的旧认知里。但 Claude 4.x 给了 200K token 的窗口，游戏规则变了。

这篇讲清楚三件事：怎么用 Claude 的长上下文（带可运行代码）、它和 RAG 各自的边界在哪、以及怎么把长上下文的成本压下来。

先搞清楚：200K 到底有多大

200K token，听着抽象。换算一下：约 15 万英文单词，或十几万汉字。一本《了不起的盖茨比》大概 5 万词，所以 200K 能装下三四本中篇小说。一份几十页的技术手册、一整份商业合同、一个中型代码模块的全部源文件——都能一次性塞进去。

这意味着一类常见需求根本不需要检索：知识总量本来就装得下。装得下，就别检索——检索永远有"漏掉相关片段"的风险，而全量塞进去没有。

实战：把整篇文档塞进 Claude

通过 ApiTopMix 的 OpenAI 兼容接口，长上下文问答没有任何特殊 API——就是把文档放进 messages。三种语言的最小可运行示例：

Python

from openai import OpenAI

client = OpenAI(api_key="sk-...", base_url="https://apitopmix.com/v1")

# 读入整篇长文档（手册 / 合同 / 代码）
document = open("handbook.md", encoding="utf-8").read()

resp = client.chat.completions.create(
    model="claude-sonnet-4-6",
    messages=[
        {"role": "system", "content": "你是文档问答助手。只依据提供的文档作答，先引用相关原文，再给结论；文档没有的就说没有。"},
        {"role": "user", "content": f"<document>\n{document}\n</document>\n\n问题：报销流程里，单据需要谁审批？"},
    ],
)
print(resp.choices[0].message.content)

Node.js

import OpenAI from "openai";
import { readFileSync } from "fs";

const client = new OpenAI({ apiKey: "sk-...", baseURL: "https://apitopmix.com/v1" });
const doc = readFileSync("handbook.md", "utf-8");

const resp = await client.chat.completions.create({
  model: "claude-sonnet-4-6",
  messages: [
    { role: "system", content: "只依据文档作答，先引用原文再下结论。" },
    { role: "user", content: `<document>\n${doc}\n</document>\n\n问题：报销需要谁审批？` },
  ],
});
console.log(resp.choices[0].message.content);

curl

curl https://apitopmix.com/v1/chat/completions \
  -H "Authorization: Bearer sk-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-6",
    "messages": [
      {"role": "system", "content": "只依据文档作答。"},
      {"role": "user", "content": "...把文档内容放这里...\n\n问题：报销需要谁审批？"}
    ]
  }'

就这么简单。没有向量库，没有 chunk，没有检索调参。文档进去，问题在后，答案出来。把内容用 <document> 这类标签包起来，是为了让模型清楚界定"资料"和"指令"的边界。

关键技巧：把问题放在文档"之后"

这是个容易被忽略、却实打实影响准确率的细节。

长上下文有个著名现象叫"中间迷失"（lost in the middle）——模型对上下文头部和尾部的注意力，明显高于正中间。所以两个习惯值得养成：

实测体感：同一份 80 页手册、同一个问题，把问题从文档前面挪到后面、再加一句"先引用原文"，回答的命中率有肉眼可见的提升，编造（幻觉）也明显减少。一行 prompt 的事，值得做。

降本核心：prompt 缓存

长上下文唯一的顾虑是成本——文档很长，输入 token 不少。但如果你对同一份文档反复提问（客服查同一份政策、开发反复问同一个代码库），prompt 缓存能把成本砍下来。

原理是：把固定不变的长文档部分标记为可缓存，第一次照常计费，之后重复命中的部分按缓存价计费——通常只有标准输入价的约 1/10。一份 50K token 的手册被问一百次，缓存能省下绝大部分重复输入的钱。具体的缓存用法以 接口文档 为准。

叠加上 ApiTopMix 本身的 Claude 折扣（Sonnet 输入 $2.20/1M、Opus $3.00/1M，比官方省 27%–40%，见定价页），长上下文问答的单位成本是可控的。两层降本的更系统方法，见 把 API 成本砍半。

长上下文 vs RAG：到底怎么选

说清楚边界——这不是谁取代谁，是按数据规模和场景分工。

维度长上下文（200K）RAG（检索增强）
知识规模≤ 200K，单文档/中型库百万字级以上的海量库
搭建复杂度几乎为零，塞进去就行需 embedding + 向量库 + 检索
召回完整性全量在场，不会漏检索取决于检索质量，可能漏
单次成本长输入，靠缓存抵消只送检索到的片段，更省
知识更新换文档即可，无需重建索引更新需重新切块/embedding
跨文档综合全局视野，综合能力强受检索召回的片段限制

选长上下文，如果你……

上 RAG，如果你……

一个务实的演进路径：先用长上下文跑通业务、验证价值，等知识库涨到塞不下、或成本扛不住了，再上 RAG。 别一上来就为了"看起来专业"搭重型检索。

一个完整的小例子：合同审阅助手

把上面的技巧串起来。读入一份合同，让 Claude 找出风险条款并引用原文：

contract = open("contract.txt", encoding="utf-8").read()

resp = client.chat.completions.create(
    model="claude-sonnet-4-6",
    messages=[
        {"role": "system", "content":
         "你是资深合同律师。只依据合同原文，逐条列出潜在风险；"
         "每条先引用原文片段，再说明风险，最后给修改建议。原文没有的不要编。"},
        {"role": "user", "content": f"<contract>\n{contract}\n</contract>\n\n请审阅以上合同的风险点。"},
    ],
)
print(resp.choices[0].message.content)

没有检索，没有漏读——整份合同都在模型眼前。需要更强的法律推理时，把 model 换成 claude-opus-4-6 即可，其余代码不动。

常见问题

1. 文档超过 200K 怎么办？

两条路。能拆就拆：按章节分批问，再让模型汇总。拆不动（需要全局视野）就上 RAG，把检索到的相关片段再喂给 Claude——这时长上下文和 RAG 是叠加，不是二选一。

2. 长上下文响应会很慢吗？

输入越长，首 token 延迟会略增，但对几十 K 的文档通常在可接受范围。如果对延迟敏感，配合 prompt 缓存：缓存命中后，重复部分的处理会快很多。

3. 怎么减少长上下文里的幻觉？

三招叠加：用标签界定资料范围、要求"先引用原文再作答"、并明确"文档没有就说没有"。把这三句写进 system prompt，幻觉会显著下降。

4. 中文文档的 token 怎么估算？

粗略地，1 个汉字约 1–2 个 token。200K 上下文大致对应十几万汉字。送之前可以先粗估字数，避免超窗报错。

用 Claude 的 200K 上下文跑个文档问答

ApiTopMix 提供 OpenAI 兼容的 Claude 接口，Sonnet 输入 $2.20/1M、Opus $3.00/1M，比官方省 27%–40%。$5 起充，随时可停。

免费注册 查看定价 查看文档

延伸阅读

结语

RAG 是个好工具，但它不该是每个文档问答需求的默认答案。先问一句：我的知识，塞得进 200K 吗？ 塞得进，就用长上下文——省一套基础设施，换更全的召回。塞不进，再请 RAG 出场。

下次再有人让你"给这份文档做个问答"，别急着开向量库。先把文档整篇丢给 Claude，配一句"先引用原文再作答"，跑一遍看看。大概率，你已经做完了。

Expert Tip：长上下文问答上线后，给每次调用记一个 cited 字段——用正则检查模型回答里是否真的包含了文档原文片段（你要求它"先引用原文"）。把 cited=false 的比例做成监控。这个比例一旦升高，往往意味着文档结构变了、问题超出了文档范围、或模型开始凭印象编。它比抽样人工检查更早、更便宜地抓到质量回退——我们用它在一次文档格式变更后，第一时间发现了问答准确率的下滑。