第02章：FDE的RAG架构选型——没有万能方案，只有最适合的

每次有人问我"RAG用什么框架最好"，我的回答永远是：取决于你的客户。

---

5个关键架构决策

在写任何代码之前，FDE需要和客户确认5件事。这5个决策决定了你的整个技术栈。

决策1：LLM部署方式

方式	适用场景	优点	缺点
Cloud API（OpenAI/Claude）	数据不敏感、预算灵活	效果最好、维护少	数据出网
本地LLM（Llama/Mixtral）	金融/医疗/政府	数据不出内网	效果略差、需要GPU
混合（本地embedding+云端推理）	大多数企业	平衡效果和安全	架构复杂一点

FDE的经验法则：

• 先问客户：“你们的数据能不能调外部API？”
• 如果答案是"不能"或"要走审批" → 直接准备本地方案
• 大多数金融/医疗/政务客户 = 本地LLM

决策2：Embedding模型选择

选择Embedding模型的核心考虑：

1. 语言
   - 纯中文 → BGE-Large-zh / M3E-Large
   - 中英混合 → BGE-M3 / Multilingual-E5-Large
   - 纯英文 → text-embedding-3-large (OpenAI)

2. 维度 vs 性能
   - 768维：速度快，适合大量文档
   - 1024维：平衡选择
   - 1536维：精度高，适合小库

3. 本地 vs 云端
   - 本地：sentence-transformers + 自选模型
   - 云端：OpenAI / Cohere / Voyage AI

4. 行业专用（如果有）
   - 医学：PubMedBERT embedding
   - 法律：legal-bert embedding
   - 金融：FinBERT embedding

决策3：向量数据库选择

数据库	适用规模	部署复杂度	特点
ChromaDB	<100万文档	低	简单、适合入门
Milvus	100万-1亿	中	性能好、支持大规模
Qdrant	10万-5000万	低-中	Rust编写、性能好
Weaviate	10万-5000万	中	支持多模态
pgvector	<500万	低	集成在PostgreSQL
Pinecone	任意	极低（托管）	SaaS、数据出网

FDE的选择逻辑：

if 文档量 < 50万 and 客户要求简单:
    return "ChromaDB"  # 80%的项目用这个就够了
elif 文档量 > 100万 or 需要高并发:
    return "Milvus or Qdrant"
elif 客户已有PostgreSQL and 文档量 < 500万:
    return "pgvector"  # 不引入新组件
elif 数据可以上云:
    return "Pinecone"  # 最省运维

决策4：分块策略

# 分块策略决策树
def choose_chunking_strategy(doc_type: str, avg_doc_length: int):
    strategies = {
        "manual": {
            "strategy": "按章节/标题分块",
            "chunk_size": "动态（跟随章节长度）",
            "overlap": "100字（包含上一节标题）",
            "reason": "技术手册的章节本身就是信息单元"
        },
        "faq": {
            "strategy": "按问答对分块",
            "chunk_size": "一对Q&A为一个chunk",
            "overlap": "无",
            "reason": "FAQ天然是独立的信息单元"
        },
        "contract": {
            "strategy": "按条款分块",
            "chunk_size": "一条条款为一个chunk",
            "overlap": "50字（包含所属章节标题）",
            "reason": "法律条款必须完整引用"
        },
        "report": {
            "strategy": "按段落分块+保留表格",
            "chunk_size": "800-1200字",
            "overlap": "200字",
            "reason": "报告段落之间有逻辑关联，需要适当overlap"
        },
        "email": {
            "strategy": "按邮件分块",
            "chunk_size": "一封邮件为一个chunk",
            "overlap": "无",
            "reason": "邮件是独立的沟通单元"
        },
        "code": {
            "strategy": "按函数/类分块",
            "chunk_size": "一个函数或类为一个chunk",
            "overlap": "import语句",
            "reason": "代码的函数/类是独立的功能单元"
        },
        "default": {
            "strategy": "递归文本分块",
            "chunk_size": "1000字",
            "overlap": "200字",
            "reason": "通用方案"
        }
    }
    return strategies.get(doc_type, strategies["default"])

决策5：搜索策略

class SearchStrategySelector:
    """
    根据客户的主要查询类型选择搜索策略组合。
    """
    def select(self, customer_profile: dict) -> dict:
        strategies = []
        
        # 所有项目都需要向量搜索
        strategies.append({
            "type": "vector",
            "weight": 0.5,
            "use_case": "语义相似查询"
        })
        
        # 如果有大量精确查询（型号、编号、参数）
        if customer_profile.get("has_exact_queries"):
            strategies.append({
                "type": "bm25",
                "weight": 0.3,
                "use_case": "关键词精确匹配"
            })
        
        # 如果有结构化数据
        if customer_profile.get("has_structured_data"):
            strategies.append({
                "type": "text_to_sql",
                "weight": 0.2,
                "use_case": "数据库查询"
            })
        
        return {
            "strategies": strategies,
            "fusion": "reciprocal_rank_fusion",
            "reranker": "bge-reranker-v2-m3" if customer_profile.get("needs_rerank") else None
        }

---

RAG架构的4种模式

模式1：Simple RAG（简单检索）

User Query → Embedding → Vector Search → Top-K Results → LLM → Answer

适用：小型知识库（<1万文档），查询类型单一

模式2：Hybrid RAG（混合检索）

User Query → [Vector Search] + [BM25 Search] + [SQL Query]
                    ↓                ↓              ↓
              [Reciprocal Rank Fusion 融合排序]
                    ↓
              [Reranker 精排]
                    ↓
                  LLM → Answer

适用：大多数企业项目（80%的情况）

模式3：Agentic RAG（Agent增强检索）

User Query → Agent → 判断查询类型
                       ↓
              [分解为多个子问题]
                       ↓
              [分别检索] → [分别回答]
                       ↓
              [综合推理] → Answer

适用：复杂查询（对比、分析、跨文档推理）

模式4：Graph RAG（图增强检索）

文档 → [提取实体和关系] → Knowledge Graph
                                 ↓
User Query → [实体识别] → [图遍历] → [相关子图]
                                 ↓
              [子图 + 向量结果] → LLM → Answer

适用：需要理解实体关系的场景（组织架构、供应链、法律关系）

---

FDE客户评估模板

# RAG项目客户评估

## 基本信息
- 公司名：
- 行业：
- 用户数量：
- 预计查询量：每天___次

## 文档评估
- 文档总量：___份
- 文档格式：□ PDF  □ Word  □ PPT  □ Excel  □ 扫描件  □ 其他___
- 文档语言：□ 中文  □ 英文  □ 混合
- 文档更新频率：□ 每天  □ 每周  □ 每月  □ 很少更新
- 敏感等级：□ 公开  □ 内部  □ 机密  □ 混合

## 查询类型评估（勾选主要类型）
- □ 知识问答（"XX是什么"）
- □ 精确查询（"XX的参数是多少"）
- □ 数据查询（"上个月的XX是多少"）
- □ 对比分析（"A和B有什么区别"）
- □ 流程指导（"怎么做XX"）
- □ 文档搜索（"找到关于XX的文件"）

## 技术环境
- 部署方式：□ 云  □ 本地  □ 混合
- 现有数据库：
- 认证系统：□ LDAP  □ OAuth2  □ SAML  □ 其他___
- GPU资源：□ 有  □ 无  □ 可申请
- 网络限制：□ 可访问外网  □ 内网隔离  □ 白名单

## 合规要求
- □ 数据不能出内网
- □ 需要审计日志
- □ 需要权限隔离
- □ 需要通过安全评审
- □ 特殊行业合规（___）

## 架构决策（根据以上信息填写）
- LLM：___
- Embedding：___
- 向量数据库：___
- 分块策略：___
- 搜索策略：___

---

本章核心结论

1. 在写代码前先做5个决策：LLM部署方式、Embedding模型、向量数据库、分块策略、搜索策略。
2. 80%的企业项目用Hybrid RAG（向量+BM25+SQL混合搜索）就够了。
3. 向量数据库选择：ChromaDB覆盖80%项目，大规模用Milvus/Qdrant。
4. 分块策略不能一刀切——按文档类型选择策略是FDE必须做的事。
5. 用客户评估模板在项目开始前收集所有信息——避免中途返工。

---

下一章：制造业RAG——你将看到设备手册、工艺文档和质检标准在RAG中的真实处理方式。