# OpenAI 内部数据 Agent 把 RAG 的检索对象从原始日志换成了离线精编的高密度上下文

> 原标题：OpenAI 带来的上下文工程范式反思：为何离线编撰能让在线 RAG 看得更少、更准？

- 来源：Computing Life · Share · 鸭哥调研
- 发布时间：2026-08-06T00:00:00.000Z
- AX AI 日报：https://ai-daily.ax0x.ai/items/49300
- 原文：https://yage.ai/share/openai-data-agent-offline-context-20260806.html

## 摘要

OpenAI 的内部数据 Agent 服务 3,500 多人、覆盖 600 PB 数据，在线部分只用了一个 GPT-5.5 模型和约 13 个工具。真正的工作发生在提问之前：用 Codex 去读数据管道的代码，把表名、字段含义这些藏在代码里的业务逻辑提前写成结构化的描述，在线 RAG 再去检索这些加工好的材料。工程师 Emma Tang 说，给模型更少...

## 推荐理由

这是目前对 OpenAI 内部数据 Agent 工程做法拆解得最清楚的一篇。离线用 Codex 做语义编撰、在线只跑轻量 RAG 的思路，对正在搭企业知识库和 Agent 的团队有直接参考意义。扣分是因为这是第三方分析，不是 OpenAI 官方发布，部分细节来自推测，我会先打个折。

## 锐评

这条新闻最反直觉的点在于，OpenAI 内部服务 3500 多人、覆盖 600 PB 数据的数据 Agent，在线部分只跑一个主模型和大约 13 个工具，没有复杂的路由或微调。他们把真正的工程复杂度前移到了离线阶段：用 Codex 去读数据管道的代码，把藏在代码里的表名含义、主键粒度这些业务逻辑提前写成结构化的描述，在线 RAG 再去检索这些“编撰”好的材料，而不是直接搜原始元数据或查询日志。

这个思路直接回应了企业数仓的一个死穴：表的真实语义往往不在数据库 schema 里，而在产生它的 ETL 代码中。如果只在用户提问时做实时检索，搜出来的多半是字面相似但逻辑对不上的垃圾。工程师 Emma Tang 在访谈里说，给模型更少但经过策展的上下文，效果反而比一股脑塞进去更好。

但这份报告缺的东西也很关键。正文没披露任何准确率或消融实验数据，我们不知道这套离线编撰到底把查询成功率拉高了多少。另外，模型还是闹了笑话，过度自信地把 ChatGPT 活跃用户算成了 500 万。时效性也是个硬伤，虽然他们加了运行时校验来补救离线目录的更新滞后，但没公布在线校验的比例和六层上下文的统一刷新周期。
