RAG 的基本流程
一个典型 RAG 系统由四个阶段组成：文档切分 → 向量化 → 检索 → 生成。
原始文档 → Chunking → Embedding → 向量数据库
↓
用户问题 → Embedding → 向量检索 → Top-K 片段 → 拼接 Prompt → LLM 生成答案
文档切分策略
切分粒度直接影响检索质量：
- 固定长度切分：实现简单，但可能截断语义完整的段落
- 按语义切分：借助标题、段落结构切分，效果更好但实现复杂
- 滑动窗口重叠：相邻 chunk 间保留 10%~20% 重叠，缓解边界信息丢失
一般建议 chunk 大小控制在 300~800 token 之间，具体需结合模型上下文长度与检索精度需求测试确定。
向量数据库选型
| 方案 | 特点 | 适用场景 |
|---|---|---|
| Milvus | 分布式、功能全面 | 大规模生产环境 |
| Qdrant | 轻量、Rust 实现、性能好 | 中小规模自建 |
| Chroma | 极简易用 | 原型开发、本地实验 |
| pgvector | 复用现有 PostgreSQL | 已有 PG 基础设施的团队 |
检索质量优化
- 混合检索：结合稀疏检索（BM25）与稠密向量检索，弥补语义检索对专有名词、编号类查询不敏感的问题
- Rerank：检索出 Top-20 后，用专门的 rerank 模型重新排序取 Top-5，显著提升精度
- 查询改写：对用户原始问题做扩展或拆分，尤其适合处理多跳问题
常见陷阱
- 忽略 chunk 元数据（来源、章节）会导致答案缺乏可追溯性
- 检索结果未去重，可能造成同一内容多次占用上下文
- 未设置相似度阈值，低相关片段也被强行拼入 Prompt，反而干扰生成质量
小结
RAG 并非简单的“检索 + 拼接”，切分策略、检索方式与重排序环节的组合调优才是决定系统效果的关键。