企业生产实践
把 RAG 从 Demo 搬到生产，需要解决索引规模、实时性、多租户、安全、成本、可观测性等一系列工程问题。本章按主题给出落地经验。
1. 大规模索引
| 问题 | 实践 |
|---|---|
| 文档量大 | 分布式 embedding 服务 + 异步任务队列（Celery / Temporal / Argo） |
| 索引时间长 | 批量编码、pipeline 并行、增量更新 |
| 版本管理 | 为每个索引版本打标签，支持灰度切换与回滚 |
| 脏数据 | 在 parser 阶段做质量打分，过滤低质量文档 |
| 分块质量 | 结构化文档按标题切分；预算允许时上 Contextual Retrieval / Late Chunking，但二者都会显著增加索引阶段的 LLM 调用与模型推理成本，需在索引成本与检索质量之间显式权衡；2026 年起优先评估内生上下文的 Contextual Embedding（voyage-context 系），索引期零额外 LLM 调用，适合高频更新语料 |
| 视觉文档 | 合同/财报类版式复杂文档考虑 ColPali 式视觉索引，但要提前评估多向量带来的存储放大（每页数十个向量） |
2. 实时更新策略
| 策略 | 说明 | 适用 |
|---|---|---|
| 全量重建 | 定期重新索引整个知识库 | 数据量小、变更少 |
| 增量更新 | 只处理新增/修改/删除的文档 | 大多数生产场景 |
| 流式更新 | 监听 Kafka / CDC 实时写入 | 新闻、股票、客服对话 |
| 双写切换 | 新索引构建完成后原子切换 | 对一致性要求高的场景 |
注意向量索引的 delete/upsert 支持度不同，选型时要确认是否支持真正的删除而非仅标记。
3. 多租户数据隔离
| 隔离级别 | 实现 | 适用 |
|---|---|---|
| 物理隔离 | 每个 tenant 独立 collection/index | 强合规、高价值客户 |
| 逻辑隔离 | 同一索引用 tenant_id metadata 过滤 | 成本敏感、租户多 |
| 混合隔离 | 大客户独立索引，小客户共享索引+过滤 | SaaS 平台常见 |
关键点：
- 查询时必须把 tenant_id 作为前置过滤条件。
- 权限层要在 API Gateway 处校验 tenant。
- 审计日志记录谁访问了哪个 tenant 的哪些文档。
4. PII、权限与审计
- 数据脱敏：索引前识别并替换手机号、身份证号、银行卡号。
- 访问控制：文档级 ACL，检索时按用户角色过滤。
- 审计：记录文档来源、chunk 版本、检索结果、生成答案。
- 合规：GDPR、CCPA 要求支持“被遗忘权”，即删除用户相关数据。
5. 缓存策略
| 缓存层 | 缓存对象 | TTL |
|---|---|---|
| Query Cache | 相同 query 的答案 | 分钟级 |
| Embedding Cache | query/chunk 的向量 | 小时级 |
| Retrieval Cache | 热门检索结果 | 分钟级 |
| Prompt Cache | 高频 prompt 模板 | 长期 |
缓存能显著降低 embedding 和 LLM 调用成本，但要注意缓存失效与答案时效性。
6. 延迟与成本优化
| 手段 | 效果 |
|---|---|
| 混合检索（BM25 + Dense + RRF） | 以低成本拿到稳定召回，已是生产基线 |
| 减小 chunk | 降低 embedding 与检索开销 |
| ANN 索引 | 用可接受的精度损失换检索速度 |
| 异步 embedding | 把索引阶段成本摊平到离线 |
| 轻量 reranker | 在线用 BGE-Reranker/Qwen3-Reranker 0.6B 替代大 cross-encoder |
| 模型路由 | 简单问题走小模型，复杂问题走大模型 |
| 结果缓存 | 减少重复 LLM 调用 |
| Prompt Caching | 长上下文“检索粗筛 + 整段精读”模式下，缓存前缀大幅降低重复推理成本 |
| 迭代预算熔断 | Agentic 检索必须设最大轮数与 token 上限 |
Agentic 模式下的成本模型：迭代式 Agent 检索相比单次 RAG，延迟约 4 倍、token 约 3 倍，但有行业评测显示多跳类问题准确率可从三成多提升到近八成。因此不要只按单次调用成本做路由决策，而应按“每个正确答案的成本”（cost per correct answer）评估：对简单查询走单次 RAG、复杂查询走 Agentic 循环，才是最优解。上线前用 Router 在离线评估集上测出路由阈值。
7. 可观测性
- Trace：OpenTelemetry/LangSmith/Langfuse 记录完整流水线；Agentic 模式下必须记录每一步的检索查询、候选数量、反思结论与停止原因。
- Metrics：
- 检索延迟 P50/P99
- 检索命中率 / 空召回率
- Rerank 前后 Top-1 变化率
- Agentic 循环：平均迭代轮数、预算熔断率、每次正确答案成本
- 生成 token 成本 / 延迟
- 用户反馈（点赞/点踩）
- 日志：query、rewritten query、retrieved chunks、prompt、answer（注意 PII）。
- Trace + Eval 平台成为标配：2025 年后的共识是把评估（RAGAS/自定义 judge）嵌入 trace 平台持续运行，而不是一年做一次的离线评测；Langfuse、LangSmith、Arize Phoenix 是主流选择。RAGAS 0.4（2025-12）把指标迁移到 collections API 后，嵌入 CI 与在线 judge 的成本进一步降低；Agentic 模式下 grader 节点（CRAG 思路）的每轮评分也要进 trace，用于回溯“停止时机是否正确”。
8. 故障模式与应对
| 故障 | 现象 | 应对 |
|---|---|---|
| 空召回 | 检索不到相关 chunk | 改写查询、放宽过滤、fallback |
| 低质量召回 | 召回结果不相关 | Multi-Query、Hybrid、Reranker 调优 |
| 幻觉引用 | 模型引用不存在 | 引用校验、降低 temperature |
| 延迟飙升 | 检索或生成超时 | 缓存、超时降级、批量限制 |
| 索引落后 | 答案基于旧文档 | 增量更新、版本切换、 freshness 权重 |
| 租户越权 | 用户看到他人数据 | 前置过滤 + ACL 校验 |
| 模型许可证违规 | 商用产品误用非商用权重的 embedding/reranker（如 CC-BY-NC 的 jina-reranker-v3 系） | 选型时核查许可，商用自托管优先 Apache-2.0（Qwen3 系、BGE 系），依赖入库前做许可证扫描 |
| Agent 循环失控 | token 费用暴涨、迟迟不返回答案 | 最大迭代轮数、token 预算熔断、路由降级到单次 RAG |
| 过度检索 | 重复检索已知信息、浪费 token（RL 检索模型的已知毛病） | 循环内去重、结果摘要缓存、反思提示约束 |
9. 人机协同反馈闭环
- 用户反馈：点赞/点踩收集 bad cases。
- 人工标注：对检索结果和答案进行人工纠偏。
- 持续迭代：把 bad cases 加入评估集，优化 chunking、embedding、reranker。
- A/B 测试：对不同检索策略、prompt 模板、模型进行实验。
小结
生产 RAG 的核心挑战不是“让检索跑通”，而是让检索在大规模、多租户、强合规、高可用的条件下持续稳定。把可观测性、缓存、权限、评估闭环做扎实，才能把 RAG 从玩具变成业务基础设施。