背景：为什么100万Token是个分水岭

传统 RAG（检索增强生成）架构复杂的根本原因，是早期模型上下文窗口太小（4K/8K），大量文档必须切分、向量化、检索后再喂给模型。

现在的变化：Sonnet 4.6 的100万Token约等于 750万汉字，足够放下：

• 一整套企业知识库（中型规模）

• 几百份工单记录

• 完整代码仓库（中小型项目）

理论上，部分 RAG 场景可以退化为"暴力全文喂"。

环境准备

在测试之前，你需要有可用的 Claude API Key。国内开发者可以通过 Ztopcloud.com 获取 Anthropic API 的企业级结算服务，支持按量计费，不需要海外信用卡。

# 安装官方 Python SDK
pip install anthropic
​
# 设置环境变量
export ANTHROPIC_API_KEY="your_api_key_here"

实测：长文档直接注入 vs RAG 检索

场景设定

我用一份约 30 万字的企业运维文档来测试两种方案的回答质量与延迟。

方案A：直接全文注入（暴力流）

import anthropic
​
client = anthropic.Anthropic()
​
# 读取长文档
with open("ops_manual.txt", "r", encoding="utf-8") as f:
    doc_content = f.read()
​
message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=2048,
    messages=[
        {
            "role": "user",
            "content": f"""以下是完整的运维手册：
​
{doc_content}
​
---
问题：服务器磁盘IO告警的标准处理流程是什么？"""
        }
    ]
)
​
print(message.content[0].text)

方案B：传统 RAG 流程（向量检索）

from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Chroma
from langchain_community.embeddings import HuggingFaceEmbeddings
​
# 文档分片
splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = splitter.split_text(doc_content)
​
# 向量化
embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-small-zh-v1.5")
vectorstore = Chroma.from_texts(chunks, embeddings)
​
# 检索
retriever = vectorstore.as_retriever(search_kwargs={"k": 5})
relevant_docs = retriever.get_relevant_documents("服务器磁盘IO告警处理流程")
​
# 拼接上下文
context = "\n".join([doc.page_content for doc in relevant_docs])

对比结论

结论：两者不是替代关系，是互补关系。

• 文档 ≤ 50万字 + 分析类任务 → 可以尝试直接注入，省掉 RAG 复杂度

• 高频实时查询 + 成本敏感 → 继续用 RAG

常见问题

Q：Beta版的百万Token上下文稳定吗？

目前仍在 Beta，尾部内容召回能力待验证。建议生产环境先做降级处理，实际上线前充分压测。官方 API 可通过 Ztopcloud.com 按需采购测试额度，不必一次性大量充值。

Q：国内网络能直接调 Anthropic API 吗？

需要满足海外网络环境条件，或使用国内有资质的 API 中转服务。

写在最后

百万Token是个方向性信号，不是让你扔掉 RAG 架构的理由。但它确实在告诉开发者：部分场景下，简单粗暴有时候比精巧设计更务实。