
从简单开始,抵制过早基建。以下情况下通常不需要上下文层:
当满足以下一项或多项时,需要专用上下文层:
非结构化 HTML 对机器是噪声。上下文层将流程、实体、约束与业务规则转化为结构化 Know‑How:带清晰模式的 JSON 文档与图:
{
"entity": "PurchaseOrder",
"id": "PO-2026-1783",
"vendor": {"name": "Acme", "id": "V-882"},
"line_items": [
{"sku": "X12", "qty": 5, "unit_price": 49.00}
],
"approval_policy": {
"threshold": 10000,
"requires_dual_signoff": true,
"exceptions": ["emergency"]
},
"provenance": {"source": "ERP", "version": "v14.2", "ingested_at": "2026-02-06"}
}
这种带模式的上下文给智能体提供机器可读逻辑与可审计出处,而不是依赖脆弱的文本片段。
组合起来实现确定性检索:按集群或图邻域路由,再缝合出最小、相关的上下文。运维实践见 Weaviate best practices for hybrid search。

智能体在试图对原始、噪声大的 dump 进行“思考”时会失败。运行时应呈现为:
# 混合检索 + 缝合的伪代码
plan = planner.make_plan(user_query)
results = []
for hop in plan.hops:
dense = dense_index.search(hop.query, k=10)
sparse = sparse_index.search(hop.query, k=10, filter=plan.filters)
graph_ctx = graph.walk(hop.entities, depth=2)
gated = gate.by_provenance(dense + sparse + graph_ctx)
stitched = stitch.compact(gated, budget_tokens=1200)
results.append(stitched)
final = synthesize(results, tools=plan.tools)
return final

该设计便于比较三种检索模式。保持小规模与可复现。
假设:5 万文档(政策、工单、产品规格);75 个评估查询,其中 40 个有 ground truth;同一 LLM;硬件一致;在适用处启用 reranker。报告 p50/p90 中位延迟及通过 EM/F1 或文档化 LLM 评判的答案质量。
| 模式 | 检索栈 | 预期特征 |
|---|---|---|
| 朴素 RAG | 仅 Dense | 快,全局连贯性较低;在跨文档问题上吃力 |
| 调优 RAG | Dense + sparse + reranker | 中等延迟,在 ID 与政策用语上精度更高 |
| 上下文层 | Hybrid + graph + 缝合 + 摘要 | p50 延迟略高但 p90 更紧;全局答案更稳定 |
解读:调优 RAG 可修正许多简单遗漏;上下文层在跨文档与多步任务上表现更佳,因路由与缓存使尾部延迟更可预测。
假设你在构建采购智能体,需在汇总供应商报价时应用审批政策。摄取 ERP 导出、合同 PDF、Slack 审批与邮件摘要。摄取流水线将它们映射到公共模式:PurchaseOrder、Vendor、Policy、Exception。用实体链接富化,使每条 PurchaseOrder 知道其 Vendor 与适用 Policy 节点。然后构建稠密索引做语义召回、稀疏索引捕获 ID 与法律用语、图索引导航 Policy→Exception→Approver 路径。
在此设置下,编排循环通过以下方式路由“今天能否批准 PO‑2026‑1783?”的查询:PO ID 的稀疏查找、从该 PO 到其 Policy 及例外的图遍历、以及最近审批人备注的稠密检索。缝合器将上述内容压缩为 1.2K token bundle,智能体产出带审批决定与出处链接的简短引用回答。
puppyone 这类平台可提供支持,因其将知识存储为结构化 Know‑How(JSON/图)并支持文本与结构的混合索引,从而在不必依赖脆弱文本抓取的情况下实现确定性检索模式与可审计追溯。
像对待代码一样对待上下文。每次变更都应有出处、审查与测试。维护带版本的模式、访问策略与评估集。在发布前执行检索保真度检查与任务级测试;捕获可解释追溯并保持回滚就绪。若智能体涉及受管制或敏感数据,请将流程与 NIST AI Risk Management Framework 中的 GOVERN 对齐。互操作性见 Model Context Protocol。
若问题局部且风险低,先从调优 RAG 开始。若出现跨文档问题、治理需求或波动语料,则规划聚焦单一工作流的上下文层试点。先构建结构化 Know‑How;模式稳定后,混合索引与编排会大幅简化。保持评估紧密且人性化:测试真实任务、记录追溯、将改进绑定到业务 SLO。
A: 不需要。先上 dense + sparse;当出现跨文档推理或全局摘要缺口时再加图。
A: 按与模式绑定的语义单元(实体、流程)分块,而非固定 token 数。其余交给 reranker 与摘要。
A: 可以,但会付出代价。从第一天起加入轻量出处与访问控制,以便评估与回滚成为可能。