上下文与 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 等新能力；但在真实业务里，成本、时延、上下文污染依然是关键约束。
实践建议：
- 小规模数据：先长上下文，验证上限。
- 数据增长后：引入 RAG，做分层召回。
- 任务复杂后：再引入 agentic loop（检索 -> 推理 -> 行动 -> 校验）。
RAG 落地清单
- 文档预处理：清洗、分段、去重。
- 索引设计：向量索引 + 元数据过滤。
- 检索策略：语义召回 + 关键词补偿。
- 重排：交叉编码器或规则重排。
- 证据注入：回答必须绑定来源片段。
- 失败兜底：召回不足时返回澄清问题。
RAG 性能优化参数参考
分块策略
| 文档类型 | 推荐块大小 | 重叠窗口 | 说明 |
|---|---|---|---|
| 技术文档 | 512-1024 tokens | 100-200 tokens | 保留代码块完整性 |
| 长篇文章 | 1024-2048 tokens | 200-400 tokens | 保持段落连贯 |
| FAQ/问答对 | 128-256 tokens | 0-50 tokens | 保持问答完整性 |
| API 文档 | 256-512 tokens | 50-100 tokens | 按端点切分 |
检索参数
yaml
# 推荐配置
retrieval:
top_k: 20 # 初始召回数量
rerank_top_n: 5 # 重排后保留数量
similarity_threshold: 0.7 # 相似度阈值
# 混合检索权重
hybrid:
semantic_weight: 0.6
keyword_weight: 0.4
# 元数据过滤
filters:
- doc_type: [guide, api, reference]
- updated_after: 2025-01-01时延优化
- 预热索引：服务启动时预加载
- 批量检索：合并相似查询
- 缓存策略：
- 热点查询缓存（TTL 5-10 分钟）
- 嵌入向量缓存（文档不变时复用）
- 并行召回：多索引同时检索
成本优化
- 选择性嵌入：只对有价值文档建索引
- 增量更新：仅重建变更文档的索引
- 模型选择：
- 嵌入模型：小而快（如 text-embedding-3-small）
- 重排模型：按需启用，非必须场景可跳过
最低验收标准
- 回答必须可追溯到具体证据。
- 无证据时不允许强答。
- 召回失败样本要单独建回归集。
角色动作卡
开发者
- 建立分层召回策略并监控召回率与重排收益。
- 对上下文做冲突处理，避免历史内容覆盖系统指令。
- 实现“无证据拒答”逻辑并记录失败原因。
产品经理
- 定义知识库边界，明确哪些内容可被引用。
- 和业务方约定证据展示形态，提升用户信任感。
- 为“召回不足”场景设计澄清问答与人工升级路径。
开发者与产品经理交接件
- 知识库更新 SLA 与负责人。
- RAG 指标看板（召回率、证据命中率、强答率）。
- 失败样本池及优先级。