跳到主要内容

Agent中的RAG

1. 定义与边界​

Agent 中的 RAG 是 Agent 在执行循环中主动检索外部知识，并把检索结果用于规划、回答、工具调用或验证的机制。它不是记忆系统，也不是让模型“记住所有文档”。

RAG 的核心对象是外部知识源：

  • 文档、网页、手册、合同、论文。
  • 代码仓库、API 文档、数据库记录。
  • 搜索引擎结果、企业知识库、工单系统。

Memory 的核心对象是 Agent 与用户、任务互动后形成的状态。两者的边界见 05-记忆系统。

2. 为什么重要​

模型参数中的知识会过期，也无法覆盖企业私有知识。RAG 用检索解决：

  • 最新性：检索当前文档或网页。
  • 私有性：连接企业内部知识。
  • 可追溯性：回答附带来源。
  • 成本：只把相关片段放入上下文。
  • 可控性：权限和审计在检索层实现。

3. 核心机制​

Agent 中的 RAG 多了一步决策：什么时候检索、检索哪个源、是否继续多跳检索。

4. 架构模式​

模式说明适用场景
Always-on RAG每次都检索企业问答、成本可控的小知识库
Tool-based RAG把检索作为工具由 Agent 决定调用多工具 Agent、任务类型复杂
Planner-RAG先规划子问题，再分步检索调研、报告、多跳问答
Verification RAG生成后检索验证高风险回答、引用校验
Search-Fetch RAG先搜索摘要，再拉取原文Web、代码、长文档

5. 工程实现​

def agent_step(user_query, state):
    need_knowledge = classify_need_for_retrieval(user_query, state)
    evidence = []
    if need_knowledge:
        retrieval_plan = build_retrieval_plan(user_query, state)
        for source in retrieval_plan.sources:
            hits = source.search(retrieval_plan.query, filters=retrieval_plan.filters)
            evidence.extend(rerank(user_query, hits))
        evidence = pack_context(evidence, max_tokens=3000)

    answer = model.generate(
        instructions="Use provided evidence. If evidence is insufficient, say so.",
        query=user_query,
        evidence=evidence,
    )
    return verify_citations(answer, evidence)

关键接口：

  • search(query, filters, k)：返回候选 chunk。
  • fetch(document_id, span)：返回原文片段。
  • rerank(query, candidates)：提高证据相关性。
  • pack_context(candidates, budget)：控制上下文预算。
  • verify_citations(answer, evidence)：校验引用存在性。

6. 生产实践​

  • 检索前先做权限过滤，不要把无权限文档交给模型再要求模型别用。
  • 外部文档内容只能作为证据，不可作为系统指令。
  • 对不同任务配置不同检索源，例如产品文档、代码、工单、网页。
  • 检索结果必须保留 document ID、chunk ID、版本、时间戳。
  • 对无法检索到证据的情况设计拒答或澄清。
  • 建立 bad case 回流：查询改写、chunk 调整、metadata 修复、重排训练。

7. 常见反模式​

  • 问任何问题都检索，增加延迟和噪声。
  • 检索结果无引用，回答不可追溯。
  • 把网页内容直接当高优先级指令。
  • 用一个向量库混放用户记忆和企业文档。
  • 只调大 top-k 解决质量问题，导致上下文污染。

8. 评测方法​

  • 是否正确判断需要检索。
  • 检索 recall@k 和 precision@k。
  • 上下文相关性和证据覆盖率。
  • 回答忠实度和引用准确率。
  • 检索延迟、成本和缓存命中率。
  • 无证据场景的拒答率。

9. 安全与治理​

  • 对 RAG 内容做 prompt injection 防护。
  • 文档索引和检索使用 RBAC/ABAC。
  • 对来源可信度分级，例如官方文档高于网页评论。
  • 对敏感文档做片段级权限控制。
  • 检索 trace 进入审计日志。

工程化补强：架构与实现细节​

A. 与 Memory 的硬边界​

Agent 中的 RAG处理的核心对象是外部知识、证据、文档、网页、代码和数据库记录。它的目标是把外部知识转化为可验证证据，而不是保存用户偏好或 Agent 经验。 Memory 可以影响“怎么服务这个用户、这个项目、这个流程”；RAG 只能回答“证据中是否支持这个事实”。

维度RAGMemory
数据来源外部文档、网页、代码、数据库、知识库对话、任务轨迹、用户偏好、历史经验
写入方式ingestion pipeline、同步任务、管理员上传互动后抽取、用户确认、后台总结
核心约束证据可追溯、权限过滤、引用准确状态延续、偏好复用、隐私最小化
典型失败召回错证据、引用不支持、上下文污染错误记忆持久化、越权画像、投毒
评测指标retrieval recall@k、faithfulness、citation precision、answerability calibrationmemory precision、task lift、staleness

B. 端到端 Pipeline​

本主题在总链路中的重点可以概括为：load -> parse -> chunk -> embed -> index -> retrieve -> rerank -> synthesize -> cite -> evaluate。

C. 索引数据结构​

{
  "chunk_id": "doc_2026_05_09#sec_04#chunk_003",
  "document_id": "doc_2026_05_09",
  "document_version": "v7",
  "source_uri": "s3://kb/product/manual.pdf",
  "source_type": "pdf|html|code|ticket|database",
  "title": "支付失败排查手册",
  "section_path": ["支付", "错误码", "超时"],
  "text": "...可用于回答的原文片段...",
  "span": {"page": 12, "start_char": 1840, "end_char": 2610},
  "metadata": {
    "tenant_id": "org_1",
    "acl": ["support", "engineering"],
    "created_at": "2026-05-01",
    "updated_at": "2026-05-09",
    "source_trust": "official_internal"
  },
  "retrieval": {
    "dense_vector_id": "vec_abc",
    "sparse_vector_id": "sparse_abc",
    "graph_node_ids": ["entity:timeout", "claim:retry-policy"]
  },
  "rag_mode": "tool_based",
    "requires_citation": true,
  "lineage": {
    "parser_version": "parser-2.1",
    "chunker_version": "heading-aware-1.4",
    "embedding_version": "emb-2026-05-09",
    "checksum": "sha256:..."
  }
}

没有 document_version、span、acl 和 lineage 的 RAG 索引，很难做引用、回滚、权限审计和 bad case 修复。

D. Indexing Pipeline 设计要点​

阶段关键决策常见坑
连接器增量同步、删除同步、权限同步只追加不删除，导致旧知识继续被召回
解析PDF 表格、代码块、标题层级、脚注丢页码和结构，引用无法定位
切分chunk 大小、overlap、父子块、表格整体性切断条款、代码函数或表格行
元数据tenant、ACL、时间、版本、来源可信度检索后才做权限过滤，已经泄露给模型
向量化embedding 模型、维度、批量、缓存模型切换后混用旧向量
索引vector、BM25/sparse、graph、rerank cache不记录索引版本，无法回归评测
回收删除、过期、重建、压缩向量残留和缓存残留

本文件建议的索引原则是：按来源、版本、权限、时间和 chunk lineage 建索引。

E. 查询期策略​

先判断是否需要检索，再改写查询、选择数据源、多路召回和重排。查询期不要把“召回更多”当成唯一目标，而要控制证据质量、权限、时效和上下文预算。

E.1 OpenAI File Search 当前能力核对​

OpenAI File Search 是 Responses API 中的托管检索工具，面向“让模型在生成前搜索已上传文件”。官方文档明确它基于 vector store 工作，并支持语义和关键词检索；这意味着它更适合快速接入文件级知识库，而不是替代企业侧完整 RAG 治理层。

能力工程含义
file_search toolAgent 可以把检索作为工具调用，而不是业务代码手写每一步召回
Vector stores文件先进入 vector store，再被 File Search 检索
max_num_results可控制返回结果数量，在质量、成本和延迟之间取舍
include=["file_search_call.results"]调试和评测时可取回检索结果，便于分析 bad case
Metadata filters适合做类别、时间、租户等过滤；权限仍建议在业务侧强制建模
chunking_strategy创建 vector store 时可使用自动或静态切分策略，切分参数需要用评测验证

使用 File Search 时仍要保留本文的 evidence contract：关键断言要能回到文件引用；外部文件内容不能成为系统指令；企业级权限、删除、审计和评测不要只依赖模型行为。

def rag_query(user_query, user_ctx):
    plan = plan_retrieval(user_query, user_ctx)
    filters = enforce_acl(user_ctx, plan.filters)
    rewritten = rewrite_query(user_query, plan, metadata_schema=INDEX_SCHEMA)
    candidates = []
    for source in plan.sources:
        candidates.extend(source.search(rewritten, filters=filters, k=plan.candidate_k))
    ranked = rerank(user_query, candidates, features=["text", "metadata", "trust", "freshness"])
    evidence = pack_context(ranked, budget=plan.context_budget, diversity=True)
    answer = generate_with_evidence(user_query, evidence)
    return verify_citations(answer, evidence)

F. 引用与证据策略​

答案中的关键断言必须映射到 chunk_id、document_version 和 span。引用不是格式问题，而是 evidence contract：模型只能用传入证据支持关键断言。

断言类型证据要求不满足时动作
简单事实至少一个直接 chunk 支持给出不确定或拒答
跨文档综合多个 chunk 覆盖关键维度明确证据范围和缺口
高风险建议官方/内部可信来源优先要求人审或给出保守答案
时间敏感信息来源版本和更新时间足够新触发刷新或说明可能过期
权限受限内容用户有权查看原文不引用、不泄露摘要

G. 失败模式与修复​

失败模式早期信号修复动作
把检索内容当系统指令，或把无证据回答包装成有来源结论答案流畅但找不到支持片段加 citation verifier 和无证据拒答
chunk 边界错误命中片段缺上文或表格列调整切分器、加入 parent expansion
召回偏科概念问答好，错误码/ID 查询差增加 hybrid search 和字段 boost
top-k 污染上下文里半数以上无关rerank、diversity filter、query rewrite
权限绕过无权限文档出现在 trace服务端 ACL 前置过滤，索引按租户隔离
索引陈旧用户指出文档已更新增量同步、版本水位、freshness 监控
引用漂移引用存在但不支持断言claim-level citation check 和回源校验

H. 评测指标​

层级指标说明
检索recall@k、precision@k、nDCG、MRRgold span/doc 是否进入候选和前排
重排rerank lift、first relevant rank观察 reranker 是否真正改善上下文
上下文evidence coverage、token waste、duplication rate是否既覆盖证据又不浪费窗口
生成answer correctness、faithfulness、abstention accuracy答案是否正确且不编造
引用citation precision、claim support rate、broken link rate引用是否可打开且支持断言
安全prompt injection success、unauthorized recall、sensitive leakage外部内容和权限场景的红线
运维p95 latency、index freshness、cost/query、cache hit rate生产可用性和成本

I. 安全治理清单​

  • 检索内容是数据，不是指令；提示词中明确外部证据不能覆盖系统和开发者约束。
  • 权限过滤必须在检索前或索引层完成，不能依赖模型“不要使用”。
  • 对网页、用户上传文件和第三方文档做 prompt injection 扫描和来源可信度标记。
  • 高风险领域使用白名单来源、版本锁定、引用校验和无法支持时拒答。
  • 记录 query、filters、命中文档、分数、rerank 理由、上下文包和最终引用，支持审计。
  • 建立 bad case 回流：每个失败样本标注失败层级，并绑定索引版本、prompt 版本和模型版本。

10. 权威资料​