rag-implementer

RAG 实施者

构建可用于生产环境的检索增强生成系统。RAG = 检索 + 上下文组装 + 生成。当大模型需要访问其训练数据中没有的最新、领域专属或专有知识时，使用 RAG。如果更简单的替代方案（FAQ 页面、关键词搜索、语义搜索）已经足够，就不要使用 RAG。关于知识库架构的选择与治理，请使用 knowledge-base-manager 技能。关于知识图谱的实现，请使用 knowledge-graph-builder 技能。

概述

构建 RAG 之前，先验证是否确有必要：先尝试 FAQ 页面、关键词搜索、礼宾式 MVP 或简单语义搜索。只有在拥有 50k+ 文档、已验证用户需求且预算为每月 $200-500 时，才继续构建 RAG。RAG 系统从朴素型（原型）到高级型（生产环境）再到模块化（企业级），每个级别都会增加复杂度和成本。

RAG 流程包含三个核心阶段。首先，检索通过混合搜索（语义搜索 + 关键词搜索）找到相关文档。其次，上下文组装对检索到的文本块进行排序、去重和压缩，组成最优提示词。最后，生成会生成有依据且注明来源的回答。每个阶段都有不同的失效模式：检索可能漏掉相关文档（召回率低），上下文组装可能让模型不堪重负（中间丢失），生成则可能在上下文良好的情况下仍产生幻觉（忠实度低）。

现代 RAG 已不再局限于基本的向量相似度搜索。结合稠密嵌入与稀疏 BM25 的混合搜索现已成为基准方案。在初次检索后，使用交叉编码器进行重排序可以提高精确率。上下文分块和后期分块能够保留固定大小分块会丢失的文档级语义。GraphRAG 通过从文档构建知识图谱，实现基于实体关系的多跳推理。命题分块则会将文档拆分为原子事实，以便精确检索单个论断。

根据查询复杂度和文档结构选择技术。以混合搜索和重排序为基础，再按需叠加上下文分块、GraphRAG 或查询扩展。衡量所有指标：Precision@K、Recall@K、忠实度和端到端延迟。仅分块策略的优劣就可能造成 9% 的召回性能差距。

快速参考

阶段	目标	关键操作
1. 知识库设计	构建结构化知识基础	梳理来源、定义分块方式、添加元数据
2. 嵌入策略	实现语义理解	选择模型、在领域数据上进行基准测试
3. 向量存储	实现可扩展存储	选择数据库、配置索引、规划扩展
4. 检索流程	超越简单相似度	混合检索、查询增强、重排序
5. 上下文组装	优化大模型上下文	排序、综合、压缩、缓解“中间内容丢失”
6. 评估	衡量性能	Precision@K、Recall@K、忠实度、延迟
7. 生产部署	确保企业级可靠性	容器化、缓存、优雅降级、安全性
8. 持续改进	持续增强	自动更新、微调、优化

决策	选项
向量数据库（托管）	Pinecone
向量数据库（可自托管）	Weaviate、Qdrant
向量数据库（轻量级）	Chroma
向量数据库（现有 Postgres）	pgvector
向量数据库（十亿级规模）	Milvus / Zilliz
嵌入（通用）	text-embedding-3-large（3072 维）
嵌入（成本优化）	text-embedding-3-small（1536 维）
嵌入（代码）	Voyage Code 3
嵌入（多语言）	multilingual-e5-large、Cohere embed-v4
分块（固定）	500-1000 个 token，重叠 50-100 个 token
分块（语义）	段落／章节／主题边界
分块（递归）	Markdown 标题、代码块
分块（上下文）	在每个分块前添加由大模型生成的摘要
分块（后期）	对全文进行嵌入，再按分块边界池化

成本层级	时间	月成本	规模
朴素 RAG（原型）	1-2 周	$50-150	<10k 个文档
高级 RAG（生产）	3-4 周	$200-500	10k-1M 个文档
模块化 RAG（企业级）	6-8 周	$500-2000+	1M+ 个文档

高级技术	适用场景
混合搜索	始终使用——结合语义搜索与关键词搜索（BM25），以提升召回率
重排序	初始检索返回的结果噪声较多时
上下文检索	文档包含指代不明确的引用或代词时
后期分块	注重效率且包含回指的流程
GraphRAG	对结构化知识关系进行多跳推理
命题分块	需要原子化检索单元的事实密集型文档
查询扩展 / HyDE	查询较短、含义模糊或信息不足时

常见错误

错误	正确做法
在确认用户需求前就构建 RAG	先尝试更简单的替代方案（FAQ、关键词搜索、人工服务 MVP）；仅在需求经过验证后才构建 RAG
只使用一种检索方法（仅语义检索）	实现混合检索，将语义搜索与关键词（BM25）结合，以提高召回率
将所有可用数据一股脑地放入知识库	谨慎整理数据源；过滤噪声、选择权威内容并维护质量
忽略“中间丢失”问题	将关键信息放在上下文的开头和结尾；压缩中间部分
上线前跳过评估指标	部署前为 Precision@K、Recall@K、忠实度和幻觉率建立基线
未经基准测试就以完整的 3072 维使用 text-embedding-3-large	先测试较低维度（1024 或 1536）——通常能以较低成本达到相近的准确率
对所有文档类型都采用固定大小的分块	根据文档结构选择分块策略；对结构化内容使用语义分块或递归分块
忽略元数据过滤	添加丰富的元数据（来源、日期、类别），并在向量搜索前或过程中进行过滤

嵌入模型说明

text-embedding-3-large（3072 维）仍是 OpenAI 能力最强的嵌入模型。它通过 dimensions API 参数支持 Matryoshka 降维——1024 维通常能以三分之一的存储成本达到接近完整维度的准确率。text-embedding-3-small（1536 维）是经济实惠的替代方案，价格为每百万个 token 0.02 美元。对于代码搜索，Voyage Code 3 的表现优于通用模型。对于多语言工作负载，可考虑 multilingual-e5-large 或 Cohere embed-v4。务必使用你的领域数据进行基准测试；通用基准测试无法预测特定领域的性能。

向量存储说明

Pinecone 适合追求托管简便性的场景；Weaviate 或 Qdrant 适合需要混合搜索的可自托管场景；Chroma 适合原型开发；pgvector 适合已使用 PostgreSQL 的团队（实用上限约为 10–100M 个向量）；Milvus/Zilliz 适合十亿级部署。根据权衡因素选择索引类型：HNSW 速度快（内存占用更高），IVF 适合扩展（需要训练），flat 仅适用于小型数据集上的精确搜索。

目前大多数向量数据库在包含 1–10M 个向量的数据集上都能实现 10–100ms 的查询延迟。从满足规模要求的最简单选项开始，只有遇到具体的性能瓶颈时才迁移。

委派

• 发现数据源并评估知识库质量：使用 Explore Agent 为文档编目、评估数据的新鲜度，并识别权威内容
• 实现带有混合搜索和重排序的检索流水线：使用 Task Agent 构建嵌入、索引、检索和评估组件
• 设计 RAG 架构和向量存储拓扑：使用 Plan Agent 选择嵌入模型、向量数据库、分块策略和部署架构

如需选择知识库架构、整理工作流和治理方案，请使用 knowledge-base-manager 技能。如需实现知识图谱（本体、实体提取、图数据库），请使用 knowledge-graph-builder 技能。

参考资料

• 架构模式和先决条件
• 分块策略和知识库设计
• 检索方法和流水线设计
• 评估指标和质量门槛
• 生产部署和持续改进