大模型的知识库能力在过去两年里经历了快速迭代。OpenAI 和 Anthropic 作为这个领域最有代表性的两家公司，走出了截然不同的技术路线。一家押注"窗口越大越好"，另一家选择"检索越准越好"。这种分歧不是表面的产品差异，而是反映了对"如何让 AI 有效利用外部知识"这一基本问题的不同回答。

从时间跨度上看，2023 年底到 2026 年中这段时间是知识库能力爆发式增长的阶段。两家公司几乎每个季度都有新的能力发布，而且技术路线的分化越来越明显。

这里说的"知识库"不仅仅指 RAG 或向量数据库，而是涵盖了从文档存储、检索、记忆管理到工具连接的整个链路——所有让 AI 系统能够有效利用外部知识的技术。

OpenAI：用规模碾压复杂度

OpenAI 在知识库方向上的核心策略可以概括为一句话：把上下文窗口做大，把基础设施做全，让用户把文档直接塞进去。

这个策略的底层逻辑并不复杂：如果模型能一次性「看到」所有相关信息，那检索这个步骤就变得多余。

而 OpenAI 恰好拥有最强的算力基础设施来支撑这个方向。

上下文窗口的膨胀

2023 年 11 月，GPT-4 Turbo 把上下文窗口从 8K/32K 推到了 128K tokens。到 2025 年 4 月 GPT-4.1 发布时，这个数字已经膨胀到 1M tokens——大约相当于一本 750 页的技术书。窗口扩大的直接好处是，很多原本需要检索管线（RAG pipeline）才能处理的场景，现在直接把全文塞进 prompt 就能解决。

这个思路有明显的工程吸引力：不需要维护向量数据库，不需要调试分块策略，不需要担心检索召回率。对于很多中小规模的知识库场景（比如一个产品的全部文档、一个代码仓库的 README 集合），直接塞进长上下文确实是最省事的做法。

但代价也很明确——推理成本与 token 数成正比，1M 窗口的单次调用费用在生产场景中并不便宜。而且，窗口大不等于利用好。模型在超长上下文中的注意力分配并不均匀（“lost in the middle” 现象），关键信息如果恰好落在上下文中段，被忽略的概率会上升。

嵌入模型的升级

2024 年 2 月发布的 text-embedding-3 系列是 OpenAI 在向量检索侧的重要更新。相比上一代 ada-002，新模型提供了两个档位（small 和 large），并且支持可调维度——可以在精度和存储成本之间做权衡。比如 text-embedding-3-small 默认 1536 维，但可以截断到 512 维以减少存储和计算开销，代价是轻微的精度损失。

text-embedding-3-large 在 MTEB 基准上的表现相比前代有显著提升，但 OpenAI 并没有过多强调检索精度的改进方法论，更多是通过模型规模的提升来获得更好的表征。这与他们在其他方向上的策略一脉相承：用规模解决问题，而不是用巧妙的算法设计。

Vector Store 和 Responses API

2024 到 2025 年间，OpenAI 逐步部署了 Vector Store API，提供自动化的文档解析、分块、向量化流程，并支持混合检索（向量 + 关键词）。这套基础设施降低了 RAG 的实现门槛——开发者不再需要自己搭建 Pinecone/Weaviate 等向量数据库，不需要写分块逻辑，不需要管理嵌入索引的更新。但本质上它是一个托管的向量数据库服务，在检索算法层面没有太多方法论创新。

对于很多只想快速搭建一个能回答文档问题的 chatbot 的团队来说，Vector Store API 已经够用了。但如果对检索精度有更高要求——比如法律文档中精确定位某一条款——这套工具的能力上限会比较明显。

2025 年 3 月发布的 Responses API 替代了之前的 Assistants API（后者将在 2026 年 8 月 26 日完全弃用）。这次 API 重构的主要目标是简化调用方式和统一工具使用模式，知识库检索作为内置工具被整合进来。从 Assistants 到 Responses 的迁移对已有用户来说是一次强制升级，但新 API 的设计确实更简洁——去掉了 Threads、Runs 等概念，改为更直接的请求-响应模式。

ChatGPT 的项目和记忆系统

产品侧，ChatGPT Projects 允许用户上传文件作为对话的知识背景（Free 5 文件、Plus 25 文件、Pro 40 文件，单文件最大 512MB）。这个功能在日常使用中确实方便，但文件数量和大小的限制意味着它更适合个人知识管理而非企业级场景。

Saved Memories 功能则存在明显的可靠性问题。系统维护约 1500-1750 词的全局记忆，但 2025 年已发生至少两次数据丢失事件。用户既不能精确控制记忆内容（不能指定"记住这个，忘掉那个"），也不能确信记忆会持久保存。这对依赖记忆功能的用户来说是一个信任问题。

记忆系统的不稳定反映了一个更深层的技术挑战：如何在不断增长的会话历史中，可靠地提取和维护长期记忆？这个问题在当前技术水平下没有完美解，OpenAI 的踩坑经历至少说明了这个方向的难度。

企业级方案

OpenAI 的 Knowledge Retrieval Blueprint 面向企业客户提供了一套完整的知识库解决方案，强调可引证答案（带来源标注的回答）。这在合规性要求高的场景中有实际价值——金融、法律、医疗等行业要求 AI 回答必须能追溯到具体文档来源。方案涵盖了从文档摄入、权限管理到答案生成的全流程，但具体的技术实现细节目前公开信息有限。

2025 年 5 月发布的 GPT-5.2 在 GDPval-AA 基准上表现最强，进一步巩固了 OpenAI 在模型基础能力上的地位。对知识库场景来说，更强的模型意味着更好的信息提取和综合能力，但这属于"水涨船高"式的进步，并没有针对检索环节做专门优化。

Anthropic：在检索精度上做文章

Anthropic 的路线明显不同。相比扩大窗口，他们投入更多精力在"如何从已有文档中更准确地找到相关内容"以及"如何让 AI 系统更好地与外部工具和数据源协作"。这种策略选择可能和团队基因有关——Anthropic 的创始团队来自 OpenAI，但对 AI 安全和系统可靠性有更强的执念。在知识库这个问题上，「可靠地找到正确答案」比「能处理更多输入」对他们更有吸引力。

Contextual Retrieval：核心技术突破

2024 年 9 月发布的 Contextual Retrieval 是 Anthropic 在知识库技术上最有分量的贡献。传统 RAG 的痛点在于，文档被切分成小块后，每个块脱离了原始上下文，导致检索时语义信息丢失。Anthropic 的方案是：在生成嵌入向量之前，先用 Claude 为每个分块生成 50-100 tokens 的上下文解释（Contextual Embeddings），说明这个块在原文档中的位置和角色。

这个设计的性能数据相当有说服力：

  • 单独使用 Contextual Embeddings，检索失败率降低 35%
  • 叠加 Contextual BM25（结合精确词匹配与语义理解），降低 49%
  • 再加上 Reranking，降低 67%

67% 的失败率改进意味着，同样的文档库和同样的查询，三分之二原本找不到答案的情况现在能给出正确检索结果。这对生产环境中的 RAG 系统来说是质的改变。尤其在企业知识库场景中，检索失败意味着用户得到错误答案或“没找到相关信息”的回复，这直接影响用户对系统的信任度。

技术实现上，Contextual Retrieval 的工作流程大致如下：文档分块后，将每个块连同整篇文档一起发给 Claude，要求生成一段简短的上下文说明（“这个块在文档 X 的第 Y 节，讨论的是 Z 主题”），然后把上下文说明拼接在块内容前面再生成嵌入向量。这个额外步骤的计算成本通过 Prompt Caching 被有效控制，因为每次调用中整篇文档的前缀是相同的，可以被缓存命中。

成本方面，Prompt Caching 技术使得上下文生成的费用控制在每百万文档 tokens 约 $1.02——这个价格让大规模文档处理变得经济可行。

为什么 Prompt Caching 能这么有效？因为 Contextual Retrieval 的工作流中，每次处理同一篇文档的不同块时，文档全文作为 prompt 前缀是不变的，只有末尾的"请为这个块生成上下文"部分不同。缓存命中率极高，实际计算成本大幅下降。

Claude Projects 和项目级记忆

Claude Projects 于 2024 年 6 月上线，功能定位类似 ChatGPT Projects，但在记忆管理上走了不同的路。Claude 的项目级记忆是用户可编辑、可审查的——可以明确看到 AI 记住了什么，可以修改或删除特定记忆条目。

这种透明设计在实际使用中带来更好的可控性。当你发现 AI 的某个行为不符合预期时，可以直接检查它的记忆库看是否存在错误条目，而不是猜测“是不是之前说的某句话被误解了”。尤其在需要精确管理上下文的开发场景中，这种可视化和可编辑性的价值很大。

MCP：从私有协议到行业标准

Model Context Protocol（MCP）2024 年 11 月开源发布，目标是标准化 AI 系统与外部数据源和工具之间的双向连接。这个协议解决的核心问题是：每个 AI 应用都需要和各种数据源（数据库、文件系统、API、SaaS 工具）集成，如果每个集成都要写定制代码，复杂度会随数据源数量线性增长。MCP 提供了一个统一的接口规范。

MCP 的扩散速度验证了这个问题的普遍性。2025 年 3 月 OpenAI 采纳，4 月 Google 采纳，5 月 Microsoft 采纳。三大厂商在半年内先后接入同一个由竞争对手发起的协议，这在 AI 行业里并不常见。MCP 正在成为事实标准。

这个现象值得细想。AI 领域的厂商通常对采纳竞对的技术标准非常谨慎，但 MCP 解决的问题太实在了——每个 AI 应用都需要和数十个数据源对接，如果没有标准化协议，这个集成工作量会让所有参与者都痛苦。采纳 MCP 对每家都有好处：开发者生态更容易建设，用户的工具投资可以跨平台复用。

Advanced Tool Use

Anthropic 在工具使用方向上的两个进展值得关注：

Tool Search Tool：当可用工具数量很大时（比如一个企业内部有数百个 API），把所有工具描述塞进上下文既昂贵又低效。Tool Search 机制让 Claude 先搜索相关工具再调用，把工具描述的 token 占用从 72K 缩减到 8.7K——节省约 95%。这个问题在企业场景中很常见：一个大型组织的内部 API 目录可能有数百个端点，全部放进 context 明显不现实。

Programmatic Tool Calling：Claude 可以编写 Python 脚本来处理工具返回的结果，而不是每次都通过 API 来回传递中间数据。这在处理大量结构化数据（如数据库查询结果的过滤和聚合）时效率提升明显。举例来说，如果一个数据库查询返回 10000 行结果，传统方式需要把全部数据传回模型；而 Programmatic Calling 允许 Claude 在本地写一段过滤代码只返回相关的 50 行。

Context Engineering 方法论

2025 年 9 月，Anthropic 将“Context Engineering”作为独立概念正式提出，定位为 Prompt Engineering 的进化。核心观点是：对于复杂的长任务，单纯优化 prompt 措辞已经不够，需要系统性地设计信息在何时、以何种形式进入模型上下文。

这个观察在实践中很容易产生共鸣。任何做过复杂 AI 应用的工程师都知道，一个工作良好的代理系统往往 80% 的工作量花在上下文管理上——决定什么信息该在什么时候进入上下文，什么时候该被移除或压缩。Anthropic 把这个实践经验抽象成了方法论。

他们提出三种处理长任务的技术模式：

  • 压缩（condensation）：定期将长对话历史压缩为摘要，保留关键信息同时控制 token 用量
  • 结构化笔记（structured notes）：让代理维护一份结构化的工作笔记，而非依赖原始对话历史
  • 子代理架构（sub-agent architecture）：将复杂任务分解给多个专门代理，每个代理只需处理自己那部分上下文

这些模式不是全新的概念，但 Anthropic 把它们整合到一个统一的方法论框架下，并提供了工程实践指南。这种"先定义问题空间，再给出解决方案模式"的思路，和他们在 Contextual Retrieval 上的工作风格一脉相承。

模型迭代

Claude Opus 4.6（2026 年 2 月）开放了 1M token 的 beta 窗口，在 MRCR v2（Multi-document Reading Comprehension and Reasoning）基准上达到 76%。这个基准衡量的是模型在超长上下文中定位和推理多文档信息的能力，76% 的得分说明即使在 1M 窗口下，模型仍然无法完美利用所有输入信息——这从侧面印证了「窗口大 ≠ 利用好」的观察。

Claude Opus 4.8（2026 年 5 月）引入 Dynamic Workflows 能力，允许模型在执行过程中动态调整工作流结构，在代理自主性和诚实性方面有进一步提升。窗口大小上两家已经拉平，但 Anthropic 在窗口内容的有效利用上投入了更多研究。

横向对比：路线分歧的本质

把两家的进展摆在一起看，技术路线的差异非常清晰。

“更大窗口” vs “更准确检索”

OpenAI 的逻辑是：如果窗口足够大，很多检索问题就消失了——直接把所有相关文档塞进去让模型自己找。这种方式实现简单，对开发者友好，但存在成本天花板。当文档量超过窗口限制（即使是 1M tokens 也不可能装下一个企业的全部知识），仍然需要检索。而且即使文档装得下，模型在超长文本中的注意力衰减也会影响回答质量。

Anthropic 的逻辑是：无论窗口多大，检索都是必要的，因此检索精度的提升有长期复利效应。Contextual Retrieval 的 67% 失败率改进在任何窗口大小下都有价值——窗口越大，高质量检索召回的内容占比越高，模型输出质量也越好。

换一种说法：大窗口解决的是"能装多少"的问题，Contextual Retrieval 解决的是"装什么"的问题。后者的价值不会因为前者的进步而消失，反而会被放大。

现实中两种能力是互补的。大窗口 + 高精度检索 的组合比任何单一方向都强。先用高质量检索从海量文档中筛出最相关的内容，再利用大窗口容纳足够的上下文让模型做深度理解和综合——这可能是当前最优的知识库架构模式。

但从投入重点来看，Anthropic 在检索质量优化上的方法论创新更具系统性。Contextual Retrieval 论文提供了可复现的方法和明确的量化指标，其他团队可以基于这个思路做进一步改进。OpenAI 的大窗口进步更多依赖模型训练层面的突破，外部团队难以借鉴。

平台锁定 vs 开放协议

OpenAI 的 Vector Store、Responses API 构成了一套闭环的云服务生态。用户上传文档、调用检索、获取回答，全部在 OpenAI 平台内完成。好处是一站式体验，从零到一个可用的知识库 chatbot 可能只需要几十行代码。坏处是迁移成本高——一旦用了他们的向量存储和检索 API，换到其他平台意味着重建整个数据管线。

Anthropic 通过 MCP 走了一条不同的路。MCP 是开源协议，不绑定特定厂商。已有的 MCP 服务器可以被任何支持该协议的 AI 系统调用。这意味着企业今天为 Claude 写的数据源连接器，明天可以直接给 GPT 或 Gemini 用。

从企业采购的角度看，开放协议降低了 vendor lock-in 风险，这在技术选型评审中是一个实实在在的加分项。一个企业如果决定从 Claude 迁移到 GPT，基于 MCP 建设的数据连接层不需要重写；反过来如果从 GPT 迁移到 Claude 也一样。这种灵活性在 AI 领域模型能力快速变化的当下尤为重要——没有人能确定两年后哪家模型最强。

成本结构差异

大窗口方案的成本与输入 token 数近似线性相关。把 1M tokens 的文档塞进每次请求，即使在目前最优惠的价格下，对于高频调用场景仍然开销巨大。假设一个客服系统每天处理 10000 个查询，每次都塞入 500K tokens 的文档背景，仅输入 token 的费用就是一笔不小的开支。

Contextual Retrieval 方案的成本结构不同：前期有一次性的上下文生成开销（通过 Prompt Caching 已压缩到 $1.02/百万 tokens），运行时只把检索到的少量相关块送入模型。对于文档量大但单次查询只需少量相关信息的场景，这种方案的长期运行成本明显更低。

举个具体例子：假设一个企业有 10 万篇内部文档，总 token 量远超 1M。用大窗口方案必须先做某种形式的筛选，然后把筛选后的结果塞进窗口——这其实还是检索，只是检索后的下游处理能力更强。而 Contextual Retrieval 直接优化的就是这个筛选环节本身的准确度，所以在这类场景下优势更加明显。

代理架构成熟度

在 AI Agent 能力上，Anthropic 的领先比较明显。MCP 提供了标准化的工具连接层，Tool Search 解决了大规模工具集的效率问题，Programmatic Calling 让代理能够自主编写处理逻辑，Context Engineering 提供了长任务的系统性方法论。这些组件形成了一套相对完整的代理开发框架。

OpenAI 在代理方向上更多依赖大模型本身的能力提升（更强的指令遵循、更长的上下文、更好的工具调用格式），但在代理架构的方法论和标准化协议层面的输出相对较少。OpenAI 更像是在说"用好我们的模型就行"，而 Anthropic 更像是在说"这是一套系统工程方法，模型只是其中一个组件"。

在实际工程落地中，有方法论指导的团队通常比"全靠模型能力"的团队走得更稳。

小结

两家公司的技术路线反映了不同的工程哲学。OpenAI 倾向于用算力和规模解决问题——窗口不够大就做更大，模型不够强就训更大的模型。Anthropic 更多从系统设计的角度思考——检索不够准就改进算法，工具太多就做搜索索引，上下文管理复杂就抽象成协议。

这两种哲学在软件工程史上并不新鲜。类似的进化路径之争在数据库领域（更大的内存 vs 更好的索引）、网络领域（更大的带宽 vs 更好的压缩）都反复出现过。历史经验表明，最终往往是两者兼备的方案胜出——既要有足够的原始能力（规模），也要有精细的优化（算法）。知识库领域很可能也会走向同样的终局。

对于需要构建知识库系统的工程团队来说，这两种能力并不互斥。一个实用的选型思路是：文档量在窗口限制内且查询频率不高的场景，大窗口方案省去了检索管线的维护成本；文档量大、查询频繁、需要精确引用来源的场景，Contextual Retrieval + MCP 的组合在准确性和成本效率上更有优势。大多数生产环境可能落在两者之间——用检索做第一层筛选，然后把结果放入较大的上下文窗口做深度处理。

MCP 作为连接层标准被三大厂商共同采纳，这一事实本身说明知识库领域的竞争已经从"能不能做"转向"做得好不好"和"生态是否开放"。下一阶段的竞争焦点可能会转向：谁能在标准化协议的基础上，提供最好的端到端知识库体验——从文档摄入的智能处理，到检索的精准召回，再到答案的可引证性和可靠性。

对工程团队来说，现在是一个比较好的布局时间点。底层协议已经趋于收敛（MCP），检索方法论也有了明确的改进方向（Contextual Retrieval），基础设施选择丰富（OpenAI Vector Store / 自建方案 / 第三方托管）。需要做的决策不是"选哪家"，而是"在自己的场景下，哪种能力组合的性价比最高"。

而且这个领域还在快速变化。升级策略应该留有余地：抽象层要做好（基于 MCP 构建连接层），具体实现可以随时替换（今天用 OpenAI Vector Store，明天可以换成自建的 Contextual Retrieval 管线）。好的架构设计应该让这种切换的成本尽可能低。

参考资料