RAG

大模型的不足

1. 幻觉：不懂装懂，容易编故事
2. 知识滞后：训练数据有截止日期
3. 数据隐私：企业内部文档、个人笔记，大模型从未见过3. 数据隐私：企业内部文档、个人笔记，大模型从未见过

大模型三大硬伤，使用时必须规避：

1. 🎭【幻觉】→ 别信它“瞎编”的答案 → 关键任务需人工校验或搭配检索增强（RAG）
2. 📅【知识滞后】→ 它不知道昨天发生的事 → 实时/最新信息要外接数据库或API
3. 🔒【数据盲区】→ 它没学过你的内部资料 → 敏感/私有内容不能直接问，需微调或本地部署

RAG工作流原理图

向量数据库选择

• 常用的向量数据库

  1. 🔹 Milvus（开源、高性能）

     • 存储计算分离，可水平扩展，支撑PB级数据
     • 支持多种索引算法，生态完善
     • 大厂首选，部署相对复杂

  2. 🔹 Qdrant（开源、Rust编写）

     • 速度快，单机性能强，安全
     • API接口更友好，Milvus的替代品

维度	Milvus	Qdrant
🚀 性能规模	PB级海量数据，分布式架构	单机极致性能，轻量高效
⚙️ 部署难度	复杂（适合有运维团队的大厂）	简单（小团队/个人项目友好）
💻 开发体验	生态成熟但API略重	Rust底层 + 简洁API，开发者友好

📌 实战建议：

• ✅ 选 Milvus 如果：
  1. 数据量 > 千万级向量
  2. 需要高可用、多副本、云原生部署
  3. 团队有 DevOps 能力，追求工业级稳定性
• ✅ 选 Qdrant 如果：
  1. 数据量 < 百万级，或初期快速验证
  2. 想快速搭建原型 / MVP
  3. 偏好简洁 API、低资源消耗、安全性优先

🎯 进阶提示：

• Qdrant 是“Milvus 的轻量替代”，不是全面超越 —— 它在中小场景更优，超大规模仍需 Milvus。
• 两者都支持 Docker 一键启动，建议先本地跑通再决定生产选型。
• 若未来可能扩容，Qdrant 也支持集群模式（v1.7+），但成熟度不如 Milvus。

RAG 文档切割规则

✂️ RAG 核心工程指南：文本切片 (Text Splitting) 实战详解

• 核心目标：将长文本切割为适合大模型处理（Context Window 限制）且保持语义完整性的片段（Chunks）。
• 核心算法：RecursiveCharacterTextSplitter（递归字符文本分割器）。

1. 核心原理：递归降级策略

   • 该算法不是“一刀切”，而是模拟人类阅读习惯，由粗到细进行尝试性切割。

2. 🔄 工作流程逻辑

   • 定义分割符优先级列表：
     默认顺序：["\n\n", "\n", " ", ""]
   • Level 1: \n\n (段落分隔) —— 优先级最高
   • Level 2: \n (换行分隔)
   • Level 3: (空格分隔)
   • Level 4: "" (字符分隔) —— 最后手段

3. 执行切割与检查：

   • Step 1: 尝试用 Level 1 分割符切分文本。
   • Step 2: 检查切分后的片段长度。
     • 若 长度 <= chunk_size ✅ -> 保留，放入结果集。
     • 若 长度 > chunk_size ❌ -> 触发递归，对该片段使用 Level 2 分割符继续切分。
   • Step 3: 重复上述过程，直到所有片段都满足长度要求，或降至 Level 4（按字符硬切）。

辑推演示例 (Case Study)

设定参数：chunk_size = 500, separators = ["\n\n", "\n", " ", ""]

📝 场景一：正常段落切割

输入：总长 1200 字，包含三个段落 A(100), B(300), C(200)。

1. 尝试 \n\n 切割：
   • 得到片段：[A, B, C]
2. 累加检查：
   • 当前桶：A (100) -> 累计 100 (<500) ✅
   • 加入 B：A+B (100+300=400) -> 累计 400 (<500) ✅
   • 尝试加入 C：A+B+C (400+200=600) -> 超标! (>500) ❌
3. 动作：
   • 截断：生成 Chunk 1 (内容: A+B, 长度 400)。
   • 重置：将 C 放入新桶，继续处理后续内容。

📝 场景二：超长段落降级切割

输入：单个段落 C，长度 1000 字（内部无 \n\n）。

1. 尝试 \n\n 切割：
   • 无法切割，整体长度 1000 > 500 ❌ -> 降级。
2. 尝试 \n 切割：
   • 切分为：C_Line1 (300), C_Line2 (700)。
   • C_Line1 (300) < 500 ✅ -> 生成 Chunk 2。
   • C_Line2 (700) > 500 ❌ -> 再次降级。
3. 尝试 (空格) 切割：
   • 对 C_Line2 按单词/词组切割，直到每块 < 500。
4. 极端情况：
   • 若某单词极长（如乱码），最终会使用 "" 按字符强制截断。

---

3. 工程化配置模板 (Python/LangChain)

直接可用的生产级配置代码：

from langchain.text_splitter import RecursiveCharacterTextSplitter

# 针对中文优化的配置
text_splitter = RecursiveCharacterTextSplitter(
    # 1. 块大小：建议 500-800 (根据模型上下文窗口调整，预留空间给 Prompt)
    chunk_size=500,

    # 2. 重叠度：关键！防止语义在边界断裂。建议设为 chunk_size 的 10%-20%
    chunk_overlap=50,

    # 3. 分割符优先级：针对中文文档优化，加入标点符号
    separators=[
        "\n\n",      # 段落
        "\n",        # 行
        "。",        # 中文句号
        "！",        # 中文感叹号
        "？",        # 中文问号
        " ",         # 空格
        ""           # 字符 (兜底)
    ],

    # 4. 长度计算函数：
    # 英文可用 len, 中文强烈建议使用 tiktoken 计算 token 数，更精准匹配模型限制
    length_function=len
    # 4. 长度计算函数：
    # 英文可用 len, 中文强烈建议使用 tiktoken 计算 token 数，更精准匹配模型限制
    length_function=len
)

# 使用示例
chunks = text_splitter.split_text(long_document)

4. 关键参数调优指南

参数	含义	调优策略	负面影响
chunk_size	单个片段最大长度	检索型任务 (QA)：设小 (300-500)，提高精度。 总结型任务：设大 (800-1000)，保留更多上下文。	太小：语义碎片化，丢失上下文。 太大：超出模型限制，引入噪声。
chunk_overlap	片段间重叠字数	必须设置！通常 50-100。 若切片处刚好是关键实体，重叠可确保其出现在至少一个完整 Chunk 中。	太小：切断语义联系。 太大：增加 Token 消耗，降低检索区分度。
separators	分割符列表	中文必改：默认空格对中文无效。 代码/Markdown：需自定义特定分隔符 (如 ###, function)。	默认配置处理中文会导致整段不切或按字乱切。

5. 常见陷阱与解决方案

1. ⚠️ 陷阱 1：中文被按字切碎
   • 现象：因为中文句子间没有空格，默认配置下算法直接跳到 “” 级别，把句子切成单字。
   • 解决：必须在 separators 中显式加入中文标点 [“。”, “！”, “？”, “\n”]。
2. ⚠️ 陷阱 2：关键信息在边界丢失
   • 现象：问题问的是“张三和李四的关系”，但“张三”在 Chunk 1 末尾，“李四”在 Chunk 2 开头，导致检索不到完整关系。
   • 解决：增大 chunk_overlap，确保跨边界的实体能被重叠部分覆盖。
3. ⚠️ 陷阱 3：代码/表格结构破坏
   • 现象：Python 代码按空格切分后，缩进丢失，代码无法运行或理解。
   • 解决：
     使用专用的 CodeTextSplitter。
     或在预处理阶段将缩进替换为特殊标记，切分后再还原。

6. 进阶方案：语义切片 (Semantic Chunking)
当固定字符数切割无法满足高精度需求时，可采用基于 Embedding 的语义切片。

• 原理：计算相邻句子向量的余弦相似度。若相似度骤降（说明话题发生转移），则在此处切分。
• 优点：切分出的 Chunk 语义高度连贯，检索效果通常优于固定长度切片。
• 缺点：
  1. 成本高：需要对全文进行 Embedding 计算。
  2. 速度慢：不适合实时流式处理。
• 适用场景：高价值知识库、法律/医疗等专业领域问答。

核心口诀：

• 先粗后细递归切，超标降级莫犹豫；
• 中文标点要显式，重叠留足保语义。

---

微调-蒸馏-RAG技术选型的全面对比

📊 完整对比表：从技术原理到部署成本

维度	RAG（检索增强生成）	微调（Fine-tuning）	蒸馏（Distillation）
技术本质	外挂知识库，动态注入信息	修改模型参数，定制行为	训练小模型模仿大模型能力
是否改模型	❌ 否	✅ 是	✅ 是（产出新模型）
知识更新方式	实时更新向量库即可	需重新训练	需重新蒸馏
典型业务场景	• 企业知识库问答 • 法律/医疗文档查询 • 产品手册智能客服	• 客服话术定制 • 金融合规输出 • 内部代码生成（如自研框架）	• 手机/IoT 端 AI 助手 • 低成本 SaaS 推理服务 • 车载/工业边缘设备
数据需求	• 原始文档（PDF/Word/DB） • 无需标注	• 高质量指令对（prompt-response） • 数百~数万条（LoRA 可少至 500 条）	• 教师输出： - 白盒：logits / hidden states - 黑盒：CoT 文本（10K~100K 条）
开发人力（人日）	3~7 人日 • 文档切片策略 • Embedding 选型 • Prompt 工程 • 向量库部署	5~15 人日 • 数据清洗/标注 • LoRA 配置 • 训练调试 • 效果评估	7~20 人日 • CoT 模板设计 • 蒸馏 pipeline • 量化部署 • 多教师集成（可选）
开发工具链	• LlamaIndex / LangChain • Milvus / Qdrant（开源） • bge-large / text-embedding-3 • FastAPI + Streamlit	• HuggingFace Transformers • PEFT + Unsloth（加速 LoRA） • TRL / Axolotl • Weights & Biases	• OpenDistill / DistilTrainer • GGUF / AWQ 量化 • vLLM / llama.cpp（推理）
训练硬件需求	无需模型训练 仅需： • CPU 或 T4（Embedding 推理）	• LoRA：RTX 3090 / M1 Max（24G） • 全参：A100×4（160G+）	• 黑盒：RTX 4090（24G） • 白盒：A100×2（80G+）
训练硬件成本	$0（本地）或 $5/天（T4 实例）	• LoRA：$0（本地）或 $30/天（A10） • 全参：$300~$600/天（A100×4）	• 黑盒：$0（本地）或 $30/天（4090） • 白盒：$200~$400/天（A100×2）
数据/标注成本	• 向量库存储：$0.1/GB/月 • Embedding API：$0.1/1M tokens	• 标注外包：$0.1~$0.5/条 × 5K = $500~$2,500 • 自产数据：$0	• 黑盒：GPT-4 生成 50K CoT ≈ $30~$50 • 白盒：$0（自有教师）
训练时长	无	• LoRA：4~12 小时 • 全参：1~3 天	• 黑盒：0.5~1 天 • 白盒：2~3 天
推理硬件	• LLM：按原模型要求 • 向量检索：CPU / T4（<4GB）	• 合并后：同原模型 • 未合并：+ LoRA 显存（<1GB）	• 学生模型显存： - 1B 模型：6~8GB（FP16） - 量化后：2~4GB（GGUF 4-bit）
推理延迟	↑ +50~200ms（检索耗时）	↔ 与原模型一致	↓ 显著降低（小模型更快）
推理成本（每千次请求）	• LLM API：$2~$10 • 自托管 Llama-3-8B：$0.5~$2	• 自托管：$0.5~$2（同原模型）	• 自托管： - 1B 模型：$0.1~$0.3 - 7B 蒸馏版：$0.3~$0.6
部署复杂度	中（需维护向量库、切片策略）	低（模型即服务）	低（蒸馏一次，长期使用）
维护成本/月	• 向量库运维：$20~$100 • 文档更新自动化：$0	• 模型版本管理：$0 • 监控告警：$10~$50	• 模型部署：$0 • A/B 测试：$20
业界常用方案	• Dify / FastGPT（低代码） • LlamaIndex + Qwen • LangChain + Pinecone	• Qwen + LoRA（中文） • Llama-3 + Unsloth • DeepSeek-Coder 微调	• TinyLlama（白盒） • Vicuna / Alpaca（黑盒） • MiniCPM（中英双语）
适合团队	• 快速上线、无训练资源 • 知识频繁更新	• 有私有数据、需行为控制 • 中小团队可承担 LoRA 成本	• 有部署限制、成本敏感 • 追求端侧智能

💰 典型项目总成本与周期（从 0 到上线）

方案	开发人力成本	硬件/API 成本	总成本	周期
RAG（企业知识库）	$600（2人×3天）	$50（向量库+Embedding）	≈ $650	1 周
LoRA 微调（客服机器人）	$1,200（2人×6天）	$100（数据+云训练）	≈ $1,300	2 周
黑盒蒸馏（手机助手）	$1,500（2人×7.5天）	$80（GPT-4 + 训练）	≈ $1,580	2~3 周
白盒蒸馏（SaaS 底座）	$3,000（3人×10天）	$1,200（A100×3天）	≈ $4,200	3~4 周

💡 注：人力按 $200/人日估算（中级 AI 工程师）

✅ 终极选型决策树

1. 你的知识会频繁更新吗？ → 是 → RAG
2. 你需要模型“说话像你们公司的人”吗？ → 是 → 微调（LoRA）
3. 你要在手机、车载、IoT 上跑 AI 吗？ → 是 → 蒸馏
4. 你既要知识更新，又要端侧运行？ → 蒸馏模型 + 轻量 RAG（SQLite + sentence-transformers）

• RAG = 知识外挂（快、灵活、低成本）
• 微调 = 行为定制（精准、可控、适配业务）
• 蒸馏 = 能力压缩（轻、快、端侧可用）

三者可组合：用蒸馏模型做底座，LoRA 微调加业务逻辑，RAG 注入实时知识 —— 实现“快、准、省”统一。