AI 实战文档

Appearance

上下文与 RAG ​

先回答一个关键问题 ​

你的任务更像哪一种？

  • A. 长文档内推理：优先长上下文。
  • B. 实时、跨知识库问答：优先检索增强（RAG）。
  • C. 需要工具交互与多步决策：采用 ReAct/Agent 工作流。

为什么需要 RAG ​

RAG（Retrieval-Augmented Generation）把“参数记忆”与“外部检索记忆”结合，核心价值是：

  • 提升事实性
  • 可溯源
  • 知识更新成本更低

经典论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》（NeurIPS 2020）给出了这条路线的基础范式。

长上下文与 RAG 的取舍 ​

Google Gemini 长上下文文档指出，超长上下文带来 many-shot in-context learning 等新能力；但在真实业务里，成本、时延、上下文污染依然是关键约束。

实践建议：

  1. 小规模数据：先长上下文，验证上限。
  2. 数据增长后：引入 RAG，做分层召回。
  3. 任务复杂后：再引入 agentic loop（检索 -> 推理 -> 行动 -> 校验）。

RAG 落地清单 ​

  • 文档预处理：清洗、分段、去重。
  • 索引设计：向量索引 + 元数据过滤。
  • 检索策略：语义召回 + 关键词补偿。
  • 重排：交叉编码器或规则重排。
  • 证据注入：回答必须绑定来源片段。
  • 失败兜底：召回不足时返回澄清问题。

最低验收标准 ​

  • 回答必须可追溯到具体证据。
  • 无证据时不允许强答。
  • 召回失败样本要单独建回归集。

角色动作卡 ​

开发者 ​

  • 建立分层召回策略并监控召回率与重排收益。
  • 对上下文做冲突处理，避免历史内容覆盖系统指令。
  • 实现“无证据拒答”逻辑并记录失败原因。

产品经理 ​

  • 定义知识库边界，明确哪些内容可被引用。
  • 和业务方约定证据展示形态，提升用户信任感。
  • 为“召回不足”场景设计澄清问答与人工升级路径。

开发者与产品经理交接件 ​

  • 知识库更新 SLA 与负责人。
  • RAG 指标看板（召回率、证据命中率、强答率）。
  • 失败样本池及优先级。

参考来源 ​