跨国深谈← 返回←把上下文当资产预编译：Pinecone Nexus 如何重做智能体检索

把上下文当资产预编译：Pinecone Nexus 如何重做智能体检索

关联

人物 Kevin Ball · Yorg Shad

公司 Pinecone · Nexus

概念 RAG · 物化视图 · 上下文 · 向量数据库 · 知识图谱 · 语义层 · 元数据 · 智能体 · LLM

这一集聊的是检索技术的前沿：把大模型接到自己数据上的标准做法 RAG（检索增强生成，即智能体在查询时临时去向量数据库搜相关内容）遇到了什么瓶颈，以及怎么换个思路解决。主角是 Pinecone 的工程副总裁 Jörg——他做了近 20 年数据库系统，从 Hadoop 时代的分布式查询优化、SAP HANA，到早期 Kubernetes、图数据库的 CTO，再到现在主持开发了 Pinecone 的新产品 Nexus，一个「知识引擎」。主持人是资深工程师 Kevin Ball。

【背景】Jörg 曾担任图数据库 ArangoDB 的 CTO。

钩子是这么一个观察：智能体每次回答问题，都在现场重复同样的检索和整理工作——而这件事本可以做一次就存下来，像数据库里的**物化视图**(把查询结果预先算好存起来的表)。

RAG 的瓶颈：每个问题都从头查一遍

Jörg 认为生成式 AI 的价值来自把它和你自己的数据结合——要么因为隐私不能共享，要么对任务足够特殊。早期的 RAG 模式很好用：向量数据库做语义的稠密检索，再配上稀疏检索和全文搜索，智能体需要信息就去查相似内容。

但实践中发现，智能体拿到检索结果后往往还要做一遍整理——类似 ETL(抽取、转换、加载)的清洗加工——而且这份工作在每个查询上都即时重做一遍。这就是 Nexus 想切进去的那一层：与其每次现场拼装，不如预先算好一份有意义的上下文。

更大的问题在可靠性上。「LLM 或智能体本质上是概率性系统，它们在即时做选择。」如果你问「去年收入是多少」，你希望答案随时间保持一致，而不是因为每次检索到的条件不同、年度营收取值不同而波动。

上下文是一等公民：有权限、有版本、有血缘

Nexus 的核心动作是把上下文当作系统里独立的实体，像数据库对待表一样对待它。这带来三层好处：

权限。Jörg 举了个很实际的例子：机密财务数据不能给任何 LLM,但你可以为它构建一个只含月度聚合、不含敏感明细的物化视图，让智能体只能通过这个接口访问。上下文可以分个人级(我最近一小时在做的任务)、部门级(整个财务团队共享)、公司级，针对一个具体任务再把几份组装成一组「元上下文」。

可复现。预先整理好的上下文让同样的查询得到一致的结果。

血缘与审计。因为上下文是策展出来的资产，你能追查它是两天前 UTC 下午 2 点的某个数据集生成的，也能解释为什么某条信息在里面。Jörg 回忆自己做特征存储时，曾花很多个夜晚重建血缘追踪来调试生产问题——现在这个能力是自带的。

一份上下文里到底装了什么

关键认知是：知识上下文不必是单一表示。Nexus 里的一份上下文同时包含：一个向量索引(可做相似性搜索)、一个带 schema 的结构化部分、以及元数据。

策展时他们会识别数据中有意义的实体(日期、人名等)——Jörg 说这本质上是在构建一个「廉价版的知识图谱」：不是严格的图，而是靠嵌入和相似性搜索撑起来的模糊关系网络。旁边还有元数据：新鲜度、血缘信息，以及指向**语义层**(把业务术语定义清楚的层)的引用——「年度收入」到底是按日历年还是偏移的财政年算，这类定义必须写明，不能靠智能体猜。

元数据还有个妙用：让智能体自己挑对的信息。LLM 是很好的规划者，只要工具不太多，它很擅长选对工具；上下文的描述同样可以结构化——里面有什么、新鲜度如何。想取最新销售数字时，如果元数据显示这份上下文两周没更新了，LLM 就知道该换一个。

策展怎么做：规格说明 → 生成的代码 → 版本化

物化流程分两种模式。一种是通用型：分析数据集、抽取关键实体、建结构化视图，什么问题都可能被问到。另一种更聚焦：如果事先知道要回答哪些问题(比如用户带着几个具体问题来)，策展就有了方向，少量示例问题还能被放大成更大的评测集，用于质量的维护和迭代——「基本上就是一个不断迭代改进的步骤」，并且要保证数据集更新后这些检查仍然成立。

Jörg 用了一个很形象的类比：就像过去读书时有人坐在那里给文档划重点、用不同颜色标记关键概念，再把它们提取出来存成另一种格式——「只是如今这一步由智能体来做」。

值得注意的一点：策展程序本身也是被生成的——现在大多数情况已不再由人写代码。「理想情况下，我有一份规格说明，代码从它生成。」 早期策展步骤就是一个 Python 程序；给它做版本化非常关键，因为数据集会随时间演变，策展逻辑也要跟着迭代，旧版本还能帮智能体生成新的策展代码。

怎么暴露给智能体：数据 + 元数据的配对

Nexus 设计了自己的查询语言 NoQL——不只是 SQL 式的取数，智能体可以在查询里插入元数据要求，还能指定输出 schema:我要的价格必须是美元、必须是低于一万的正数，系统会自动强制执行这些约束。响应端同样返回数据加元数据的组合，比如「答案是五，但我只有 10% 的把握」——这两个事实一起返回才有价值。

Jörg 认为智能体和人类消费数据的方式有一个本质区别：人发一条查询、拿一个结果就走；智能体能迭代，可以围绕低置信度的结果重新规划。「希望它不去用那条 5% 置信度的信息，但它可以利用这个元信息，为下一步做出不同的决策，而不是只得到一句『没有相关信息』。」 这里有个治理视角的分歧：不信任智能体时，你可以设硬约束——「信心低于 50% 的东西，干脆不要给智能体」；信任它时，反而应该给得越多越好。

这也回应了成本问题：多轮循环的 token 开销很大，而且 LLM 要同时处理的抽象层越多，既贵又不可靠。预策展的价值正在于把发现类的子循环从运行时挪走——提前做一次贵的，之后每次交互都少一层迭代。

离线持续策展与标准化展望

策展不是一次性的。Jörg 描绘了一个很务实的图景：初始数据没变，但每晚闲置的 GPU 集群可以拿来持续打磨已策展好的上下文——折叠或扩展知识图谱、用图机器学习找新连接、按贝叶斯方式更新边的置信度。

更妙的是，进来的问题本身就是新数据：「我获得了更多数据，不是靠初始数据变化，而是靠观察进来的问题，这样我就知道我可能需要回答什么。」 冲突和不完美数据也可以这样处理：标出「这个数据集有冲突」本身就是有价值的信息；学到某个数据源最近两天不可靠，就在策展规则里忽略最近两天。

由于上下文有接口抽象，内部表示可以随意演进——换 schema、做反规范化，消费者看到的接口不变，就像 Docker 容器或小型数据产品。至于这一层会不会标准化成独立的抽象层：Jörg 认为眼下垂直整合端到端的好处太多(元数据不重复、不脱同步，血缘好追)，标准化至少还要两年迭代，大概率从查询/响应的格式开始，顺着技术栈往下走。

本集带走

• RAG 的隐藏成本在检索之后的整理：智能体每个查询都在现场重复做一遍 ETL 式加工，而且概率性检索让同一问题答案漂移。把它预计算成物化视图式的「上下文」，可复现、可审计。
• 上下文要当成一等公民管理：有权限(个人/部门/公司级，敏感数据只暴露聚合视图)、有版本、有血缘追踪——这几十年数据库系统工程积累的好处，直接搬过来用。
• 一份上下文 = 多模态组合：向量索引 + 结构化 schema + 实体关系(廉价版知识图谱)+ 元数据(新鲜度、语义层定义)，元数据让智能体自己判断该不该用这份信息。
• 策展流程也要版本化：规格说明 → (生成的)策展代码 → 策展产物；少量示例问题可放大成评测集持续迭代质量，数据集演进时代码跟着改、旧版本可回溯。
• 给智能体的接口应该是「数据 + 元数据」的配对：让查询能指定输出格式和约束，让响应带上置信度——低置信度信息即使不可用，元信息也能帮智能体换一个规划方向。
• 策展可以离线持续做：夜间闲置算力用来打磨上下文，进来的真实问题就是最宝贵的策展信号。

在大多数情况下，已经不再是由人来写代码了。理想情况下，我有一份规格说明，代码是从它生成的。
So it’s not someone writing code anymore in most cases. Ideally, I have a spec. I have a spec from where the code is generated.
—— Yorg Shad · [24:45]

实际上，我想要一个约束：任何我信心低于 50% 的东西，干脆不要给智能体。
I actually, I want like a constraint, like anything where I’m less than 50% certain, don’t even give out to the agent.
—— Yorg Shad · [33:20]

我们需要为智能体提供好得多的语义，因为人们只是把那些放在脑子里，但智能体需要它们就在那里触手可及。
we need much better semantics for agents because people just put that in their heads, but agents need it right there.
—— Kevin Ball · [55:18]