一、RAG 要解决什么问题？
大模型有两个硬伤：
知识截止：训练数据有截止日期，不知道最新信息
幻觉：生成看似合理但完全编造的信息
RAG（Retrieval-Augmented Generation，检索增强生成）的思路很直接：先检索，再生成。给模型一本"参考书"，让它只基于检索到的内容回答。
二、RAG 完整流程
三、核心组件深度解析
3.1 Embedding 模型
Embedding 是把文本转成固定长度的向量，向量距离越近，语义相关性越强。
维度 | 说明 |
输入 | 一段文本（词/句/段落） |
输出 | 固定维度数组（如 768 维、1536 维） |
核心原理 | 语义相近的文本，向量空间中距离也近 |
常用模型 | text-embedding-ada-002、bge-large-zh、m3e-base |
3.2 文档分块（Chunking）
这是 RAG 最容易被忽视但影响最大的环节。
常见策略：
策略 | 方式 | 优缺点 |
固定长度切分 | 按字数/Token 数切 | 简单，但可能截断语义 |
段落切分 | 按自然段落切 | 保留语义，但段落长度不一 |
符号切分 | 按句号/换行切 | 平衡，但无语义感知 |
语义切分 | 用模型判断语义边界 | 效果最好，成本最高 |
经典陷阱——指代丢失：
原文："那头猪是佩奇，那头猪爱玩泥巴。"
按句号切分后变成：
Chunk 1："那头猪是佩奇"
Chunk 2："那头猪爱玩泥巴"
问题：当用户问"佩奇爱干什么"时，Chunk 2 中的"那头猪"已失去与"佩奇"的关联，检索可能失败。
解法：使用滑动窗口 + 重叠区域，或用语义切分模型保留指代关系。
3.3 向量数据库
数据库 | 特点 |
Chroma | 轻量级，适合原型开发 |
Milvus | 分布式，适合大规模生产 |
Qdrant | 高性能，支持过滤 |
Pinecone | 全托管 SaaS |
Weaviate | 内置多种模块 |
选型核心指标：写入吞吐、查询延迟、过滤能力、可扩展性。
3.4 检索优化
基础检索：Top-K 最近邻搜索，简单但噪声多（约 15% 无关信息被引入）。
进阶优化：
技术手段 | 说明 |
Top-N 调参 | K 太小漏召回，太大噪声多，需实验调优 |
意图模型 | 先判断用户意图，再定向检索 |
Re-ranking 重排 | 用 Cross-Encoder 对初检结果精排 |
混合检索 | 关键词检索 + 向量检索融合 |
多路召回 | 不同分块策略并行检索 |
四、RAG 的已知局限
问题 | 说明 |
缺乏全局视角 | "文章中有多少个'我'字"——每个 chunk 都沾边但都不精确 |
指代关系断裂 | 分块导致代词与所指对象分离 |
长文档截断 | 上下文超 2048 Token 时性能下降 |
检索噪声 | 无关文档被召回，干扰生成 |
更新延迟 | 知识库更新后，向量索引需重建 |
五、关系型数据库的另类"RAG"
并非所有场景都适合向量检索。当任务本质是精准匹配而非语义相似时，关系型数据库可能更优。
场景：Agent 执行多个网页子任务，每个子任务有不同的流程、格式和 examples。按子任务关键词查表，比把子任务信息塞进向量库更精准、更可控。
实现思路：
定义表结构：
task_id, keywords, workflow, examples, output_format用户提问 → 关键词匹配 → 查表获取完整配置
将配置注入 Prompt 执行