RAG

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 并非简单的“检索 + 拼接”，切分策略、检索方式与重排序环节的组合调优才是决定系统效果的关键。