搭建 RAG 系统时，技术选型是最早需要面对的实际问题。市面上的向量数据库、嵌入模型、大语言模型、框架工具琳琅满目，每种方案都有其适用场景和局限。面对这么多选项，很容易陷入“哪个最好”的争论，而忽略了选型的出发点：你的具体需求是什么。
下面给出的决策树，是从多个真实项目中提炼出来的选型逻辑。它不追求列出所有产品，而是根据几个关键约束条件，帮你在几条主流路径之间做出务实选择。
11.1.1 决策前的三个关键问题
在开始对比技术栈之前，先明确以下三个问题，它们决定了你的需求落在哪条线上：
- 数据规模与更新频率
- 文档总量是几百份、几万份，还是海量级别？
- 内容是基本不变（如法规），还是需要频繁更新（如产品价格、库存信息）？
- 团队技术能力与人力投入
- 团队是否有专职算法工程师或后端开发？
- 是否希望尽量用托管的云服务，减少运维负担？
- 对精准度、延迟、溯源的硬性要求
- 是否要求每条回答必须标明出处？
- 是否需要毫秒级响应用户，还是可以接受稍长等待？
- 是否要严格控制模型只能回答知识库内的内容，不允许引入外部知识？
回答清楚这三组问题，你的需求画像就大致成型了。接下来按照以下步骤走决策树。
11.1.2 第一步：确定向量存储方案
向量数据库是知识库的底座，选型时主要看规模和运维偏好。
- 如果文档量少、数据无需频繁更新，团队不想运维数据库 → 选用轻量级内置向量存储
比如使用 Chroma 或 FAISS 直接嵌入应用进程。Chroma 简单易用，适合原型和中小规模场景；FAISS 是 Meta 出品的高效向量检索库，性能好但需自己封装管理。这两种方案零运维成本，开发体验友好。
- 如果文档量大、需要高并发检索或未来有扩展需求 → 选用专用向量数据库
Milvus 和 Qdrant 是主流选择。两者都支持海量向量存储、近似近邻搜索，并提供持久化、集群部署等企业功能。Milvus 生态更成熟，社区活跃；Qdrant 部署轻便，Rust 实现性能突出。
选型提示：如果系统还会同时使用传统关键词搜索，考虑 Elasticsearch 的向量插件（从 8.0 开始支持）。这样可以一套组件同时覆盖关键词和向量检索，降低架构复杂度。
- 如果已经在使用某个云平台，只想快速搭建 → 直接用云厂商托管向量数据库
AWS有 Amazon OpenSearch（带向量搜索）、Aurora PostgreSQL 的 pgvector 扩展；Azure 有 Azure Cognitive Search；GCP 有 Vertex AI Matching Engine。这些省去了运维烦恼，可以和平台已有的权限管理无缝集成。
11.1.3 第二步：选择嵌入模型
嵌入模型将文本转成向量，直接影响检索质量。选型取决于语言、成本和对精度的要求。
- 通用多语言场景，追求性价比 →
text-embedding-3-small（OpenAI）或bge-large-en-v1.5（BAAI）
OpenAI 的模型效果好，但需调用 API 产生费用，且数据需出网。如果对数据隐私敏感或希望离线运行，可选择开源 BGE 系列（由北京智源研究院发布），在多语言和中文任务上表现优异，可本地部署。
- 纯中文业务，对效果要求高 →
bge-large-zh-v1.5或text2vec-large-chinese
这两个模型在中文检索评测中经常进入前列，且都有容易使用的开源版本，可自行部署在自有服务器上，保证数据不出内网。
- 有限的计算资源或希望完全离线使用 →
all-MiniLM-L6-v2
这个模型小巧（仅 80MB 左右），运行快，适合在笔记本或边缘设备上直接使用，精度虽略逊于大模型，但用在内部小范围知识库上完全够用。
- 需要结合传统搜索信号 → 可选用稀疏向量模型（如 SPARtense）配合 BM25
如果希望兼顾关键词精确匹配和语义召回，可以混用稠密向量（来自上述模型）和稀疏向量，甚至直接用 BM25 与 BGE 混合检索。许多高级 RAG 管道都采用这种策略，在实际业务中提升显著。
11.1.4 第三步：选择大语言模型
生成环节的模型选择取决于控制力、成本、隐私和回答质量。
- 希望开箱即用、质量高、能接受接口调用 → GPT-4o 或 GPT-4o-mini（OpenAI） / Claude 3.5 Sonnet（Anthropic）
闭源模型在复杂指令遵循、长上下文处理、多语言生成上仍处于领先地位。如果你的场景对回答质量要求高，且数据传输政策允许，这是最省心的选择。
- 需要严格数据保密、或希望固定成本 → 选择开源可私有化部署模型
Llama 3 系列（Meta）和 Qwen2 系列（阿里云）是当前较优选择。Llama 3 社区支持最广，工具链完善；Qwen2 对中文支持更原生，且遵循国产化要求，很多大陆企业内部部署时优先考虑。部署可以用 vLLM、Ollama 等工具，体积和计算资源要求也在逐年降低。
- 对推理速度要求极高、需要实时交互 → 使用小参数模型或经过量化的版本
Qwen2-7B、Llama 3 8B 等可以在消费级 GPU 上快速运行；如果资源更有限，还可使用 GGUF 量化版本配合 llama.cpp 推理。用于简单知识问答，回答质量仍然可用。
- 希望同时支持生成和函数调用/工具使用 → 选原生支持 function calling 的模型
如果你的 RAG 还需要结合外部 API（如查询数据库、调用邮件发送等），OpenAI 模型、Llama 3 微调版、Qwen2 特定版本都提供了工具调用能力，在选型时需确认模型支持。
11.1.5 第四步：选择编排框架与工具链
框架负责串联索引构建、检索、提示词管理、生成等步骤。选择取决于开发效率和灵活性需求。
- 快速搭建原型，且主要使用 Python → LangChain 或 LlamaIndex
LangChain 生态最完善，组件化程度高，文档和示例最多；LlamaIndex（原 GPT Index）在数据连接、索引构建方面更加专注，RAG 相关的能力非常突出。两者都能让你在几小时内跑通基本流程。缺点是抽象层多，复杂项目里可能觉得不够透明。
- 追求低代码和可视化 → Dify 或 Flowise
这两个工具提供拖拽式的 RAG 管道搭建界面，适合非开发人员或希望快速验证概念的团队。Dify 还自带了知识库管理和多模型接入功能，可以直接部署为生产服务。
- 团队侧重 Go/Java 技术栈，或需要极致性能和定制 → 自己编程组装
直接调用各个组件 API：用 embedding 模型 SDK 生成向量，用向量数据库客户端插入和检索，自己用字符串模板构建提示词，最后调用 LLM SDK 完成生成。这种方式没有框架依赖，完全可控，但需要写好重试、异常处理等基础逻辑。
- 需要处理复杂文档结构（PDF/表格/图片） → 考虑 Unstructured + LangChain/LlamaIndex
Unstructured 库专门解决 PDF、PPT、图像中文字的抽取和分块问题，配合上述框架使用，可极大提升复杂文档的预处理效率。
11.1.6 决策路径速查
为了便于快速对照，将上面的逻辑凝练为几条常见路径：
- 最小原型路径
Chroma + bge-small-zh + GPT-4o-mini + LangChain
适合：验证概念、内部 hackathon、文档量 < 1000 份。
- 企业级内部知识库路径
Milvus + bge-large-zh + Qwen2-7B 私有部署 + LlamaIndex
适合：有专职运维或算法工程师、数据不出内网、知识规模较大。
- 云上全托管快速上线路径
Azure Cognitive Search + text-embedding-3-small + GPT-4o + Dify
适合：微软技术栈、希望免运维、快速集成到现有业务系统。
- 高性能混合检索路径
Elasticsearch（向量+BM25） + BGE 混合检索 + Llama 3 8B
适合：对召回率要求极高、需要同时支持精确关键词和语义搜索。
没有所谓的“万能最佳技术栈”，只有与你的场景、团队、时间和预算最匹配的选型组合。建议先从小规模、低成本方案起步，快速验证检索和生成效果，再根据实际瓶颈逐步替换组件，这是降低选型风险最务实的方法。