RAG系统设计
概述
RAG（Retrieval-Augmented Generation）不是“给大模型多喂一点文档”这么简单。一个能上线的 RAG 系统，至少要同时处理索引构建、召回质量、延迟、权限、可观测性和答案可信度。
它的目标通常是两件事：
- 让模型回答私有知识。
- 降低幻觉，提升答案可追溯性。
基本链路
这条链路里，最容易被低估的是中间环节：
- 切块决定召回边界。
- 重写决定你到底在搜什么。
- Rerank 决定最终上下文质量。
- Prompt Assembly 决定模型是否真的用到了上下文。
文档预处理
文档进索引前至少要做三件事：
- 清洗噪声：页眉页脚、重复段落、无意义样式文本。
- 结构保留：标题层级、表格、代码块、引用来源。
- 权限打标：租户、部门、文档可见范围。
如果预处理阶段丢了结构，后面召回质量通常补不回来。
切块策略
常见切块方式：
- 固定长度切块：实现简单，但容易切断语义。
- 递归结构切块：优先按标题、段落、列表切，再回退到长度切分。
- 语义切块：基于主题变化或模型分段，效果更好但成本更高。
经验上：
- 说明文档适合结构化切块。
- API 文档适合按接口或章节切块。
- 代码库适合按文件、类、函数边界切块。
切块不是越小越好。太小会丢上下文，太大又会稀释召回精度。
检索链路设计
Query Rewrite
用户问题往往不适合直接检索，例如：
- 问题太短，没有关键实体。
- 包含代词，需要结合对话历史补全。
- 问法口语化，而知识库是术语化写法。
这时先做 query rewrite 往往比盲目调 embedding 更有效。
Hybrid Search
只做向量检索通常不够，尤其是涉及：
- 精确术语
- 错误码
- 类名、接口名、配置项
更稳妥的方案通常是“向量召回 + 关键词召回 + 融合排序”。
Rerank
第一阶段召回负责“别漏掉”，第二阶段 rerank 负责“把最相关的放前面”。
一个常见策略：
- 向量库先召回 20 到 50 条。
- 再用 cross-encoder 或轻量 reranker 压到 5 到 8 条。
- 最终拼进 prompt 的上下文尽量控制在清晰可读范围内。
一个工程化架构
拆分的原因：
- ingest 和 online query 的负载模式完全不同。
- embedding 通常适合异步批处理。
- chat api 要把延迟稳定在秒级。
Prompt 组装建议
一个稳妥的回答 prompt 通常包含：
- 系统约束：只允许基于给定材料回答，不确定时明确说不知道。
- 检索片段：附带标题、来源、时间、权限信息。
- 输出要求：答案结构、是否要引用、是否要列风险项。
如果你已经做了高质量召回，prompt 的主要职责不是“塞更多字”，而是让模型遵守使用上下文的规则。
权限与多租户
很多团队把 RAG 当搜索问题做，最后卡在权限控制上。
至少要保证：
- 文档在索引阶段带权限标签。
- 检索时先过滤权限，再做召回和排序。
- 引用片段返回给前端时也要再次校验权限。
否则模型可能通过答案把本不该暴露的内容间接泄漏出去。
核心指标
上线后至少看这几类指标：
- 检索层：召回率、Rerank 后命中率、空结果率。
- 生成层：可引用率、拒答率、用户满意度。
- 系统层：P95 延迟、索引更新时延、embedding 队列积压。
- 质量层：幻觉率、过期内容命中率、权限误漏率。
没有指标，RAG 只会停留在“看起来能答”的演示状态。
常见失败模式
检索片段很多，但答案仍然不准
通常不是模型笨，而是：
- 召回片段太散，没有足够局部上下文。
- prompt 没要求基于材料引用回答。
- 问题实际需要的是流程推理，不是事实检索。
新文档入库很慢
通常要检查：
- 清洗与切块是否串行过长。
- embedding 是否没有批量化。
- 索引更新是否每次全量重建。
结果不稳定
优先看是否：
- query rewrite 不稳定。
- 检索结果在边界附近经常抖动。
- prompt 里混入过多无关片段。
设计建议
- 先把检索质量跑顺，再谈 Agent、工具调用和复杂工作流。
- 先做可追溯答案，再追求更自然的表达。
- 明确哪些问题属于“知识检索”，哪些本质是“业务执行”。
- 索引更新、权限过滤和观测能力必须一开始就设计进去。
总结
RAG 系统的核心不是“接上一个大模型”，而是把知识从原始文档稳定地转换成可检索、可过滤、可引用、可评估的上下文。真正决定效果上限的，往往不是模型本身，而是中间这一整条检索链路。
贡献者
更新日志
2026/3/14 13:09
查看所有更新日志
9f6c2-于