超越 RAG：Unblocked 如何构建节省 token 的关系型上下文引擎

📌 One-Sentence Summary

Unblocked 的 Peter 认为，智能体既需要语义检索，也需要受约束的结构化查询，并现场搭建了包含 schema 发现、身份映射、查询校验、重试和全文检索的文档查询引擎。

📝 Summary

Unblocked 的 Peter 将上下文引擎描述为连接代码、文档、PR 和对话的组件，为具体任务提供带权限约束的上下文包。公司演示显示，接入上下文后的智能体规划消耗了更少 token、用时也更短，但这只是单个案例。演讲的核心是现场搭建与 RAG 互补的结构化检索：向量搜索适合找相关内容，涉及日期、评审者、数量和趋势的问题则需要真正执行查询。引擎通过抽样文档推断 schema，跨系统解析身份，并把用户和时间信息交给查询生成环节；执行前再校验查询，拦截危险算子、隐藏字段和跨租户访问。有限次重试可让模型依据错误修正查询，而全文检索弥补了精确匹配过窄的问题。这是一套可复现的架构，但仓促的演示和厂商案例尚不足以证明普遍的成本或准确率收益。

💡 Main Points

智能体上下文引擎要结合语义材料与结构化事实。

代码和对话可以按语义搜索，但数量、日期、归属和趋势问题需要对结构化记录执行筛选与聚合。

自然语言生成查询前，要先解决 schema 和身份问题。

抽样文档可发现字段与枚举；跨系统身份映射则帮助把人名对应到正确的账户或评审者标识。

模型生成的查询必须经过严格的执行边界。

引擎校验算子和字段，不让模型接触租户元数据，并自行注入租户条件；出错后也只在限定次数内重试。

全文检索补全了结构化查询路径。

校验后的精确标题匹配没有结果，演示随后加入全文检索，才找到了与身份验证相关的 PR。

💬 Key Quotes

难点在于围绕查询生成搭建的整套支撑机制。

从 LLM 得到的查询是不可信的。

你需要先理解 schema，再把它交给 LLM，让它生成受字段约束的查询。

这些内容都是开源的。

📊 Article Meta

AI Screening： 90

Featured： Yes

Source： AI Engineer

Author： AI Engineer

Category： 人工智能

Language： 英文

Read Time： 12 min

Word Count： 2959

Tags：

AI 与智能应用 , 上下文工程 , RAG / 检索增强 , AI Agent , 系统设计

Play Full Video