落地实施 RAG 工程的 7 步指南：从数据到生产，逻辑清晰可落地

qq_36038282

1206人浏览 · 2025-09-16 11:43:48

qq_36038282 · 2025-09-16 11:43:48 发布

RAG 工程的商业落地不是 “搭好框架就完事”，而是 “从数据准备到生产运维” 的全流程闭环。结合 RAG 高级技术（高效召回、RAFT、Qwen-Agent、Ragas），将原有步骤细化为 “目标明确、操作具体、工具可落地” 的 7 个核心环节。

一、Step 1：数据集准备（语料）—— 搞定 “RAG 的原材料”

目标：获取高质量、结构化的语料（文档），避免 “垃圾数据进，垃圾答案出”。
核心逻辑：从 “非结构化文档”（PDF/Word/ 扫描件）提取有用文本，再处理成 “机器能读懂、检索效率高” 的格式。

1.1 文档收集：明确语料范围

来源：企业内部文档（如规章制度、产品手册）、公开资料（行业报告、技术文档）；
示例：落地 “银行客户经理考核问答 RAG”，语料就是《浦发银行西安分行个金客户经理考核办法.pdf》；
注意：避免收集重复、低质量文档（如空白页、乱码文本），减少后续处理成本。

1.2 文档结构化处理：让机器 “读得懂”

用 “智能工具 + 人工校验” 将非结构化文档转成结构化文本，关键步骤：

处理环节	操作目标	工具 / 方法（素材同步）	示例（素材代码）
文本提取	从 PDF/Word 提取纯文本 + 元数据（如页码）	PyPDF2（提取 PDF 文本带页码）、Unstructured（多格式支持）	用`extract_text_with_page_numbers`函数提取 PDF 文本，记录每行对应的页码，方便后续溯源
文本清洗	去噪（空白行、乱码）、统一格式	Python 字符串处理（strip ()、replace ()）	过滤 PDF 中 “无文本页”，删除纯空白行，统一日期 / 数字格式
文本分割（切片）	将长文本拆成 “小而完整” 的块，提升检索精度	RecursiveCharacterTextSplitter（递归字符分割）	设置`chunk_size=512`（每块 512 字符）、`chunk_overlap=128`（块重叠 128 字符，避免语义断裂），素材中拆分为多个 chunk

1.3 最终产出

结构化语料库（如vector_db文件夹），包含：

分割后的文本块（chunk）；
元数据（如文档名称、页码、创建时间）；
文本块与元数据的映射关系（用page_info.pkl存储）。

二、Step 2：测试集准备（QA 对）—— 给 RAG “出考题”

目标：生成 “问题 - 标准答案”（QA 对），用于后续测试 RAG 的 “回答准确性”，避免上线后发现 “答非所问”。
核心逻辑：用 LLM 批量生成 QA 对，再人工校验，确保覆盖核心业务场景。

2.1 QA 生成：用 LLM 高效产出

工具：Qwen-max、GPT-4、Claude 3；
生成逻辑：
1. 单文档 QA：给 LLM 一段结构化文本（如 “客户经理投诉扣分规则”），提示 “生成 3 个核心问题 + 标准答案”；
2. 多文档 QA：针对跨文档关联问题（如 “客户经理入职要求 + 评聘时间”），让 LLM 整合多文档信息生成 QA；

示例：
语料是 “客户经理考核办法”，生成 QA 对：

问题	标准答案（ground_truth）
客户经理被投诉一次，扣多少分？	每投诉一次扣 2 分
客户经理不服从支行工作安排，每次扣多少分？	不服从支行工作安排，每次扣 2 分

2.2 QA 质量校验：避免 “无效考题”

校验维度：
1. 相关性：问题必须围绕语料核心内容（避免 “客户经理喜欢什么颜色” 这类无关问题）；
2. 准确性：标准答案必须能从语料中找到依据（避免 LLM 幻觉）；
3. 覆盖度：覆盖所有核心场景（如考核扣分、入职要求、评聘时间）；
工具：人工抽样校验（10% 比例），或用 Ragas 初步筛选低质量 QA。

2.3 最终产出

QA 测试集（如qa_dataset.csv），包含 “问题（question）、标准答案（ground_truth）”，后续用于 RAG 效果评估。

三、Step 3：技术选型 —— 选对 “工具链”，少走弯路

目标：根据业务需求（快速验证 / 深度定制）、团队技术能力，选择合适的工具组合，避免 “过度开发” 或 “功能不足”。
核心逻辑：按 “零代码→低代码→高度定制” 分三类，对应不同场景，素材中工具全覆盖：

选型类型	核心优势	代表工具	适用场景	素材关联功能
零代码搭建	无需写代码，1 小时出 demo	Dify、RAGFlow、Coze Studio	快速验证业务需求（如内部知识库 Demo）	可视化配置知识库、调用 LLM
低代码搭建	少量代码，支持定制化	Qwen-Agent、TrustRAG、LightRAG	中等复杂度需求（多轮检索、领域适配）	Qwen-Agent 的 Level1-3 智能体（检索→分块→推理）
高度定制开发	全流程可控，支持复杂逻辑	LangChain、LlamaIndex、LangGraph	复杂场景（多跳推理、自定义召回策略）	LangChain 的 ParentDocumentRetriever、MultiQueryRetriever

选型建议：

新手 / 快速验证：选 Dify，上传文档即可生成 RAG 机器人；
企业级需求（如银行、医疗）：选 Qwen-Agent，支持多级别智能体，适配领域数据；
技术团队强 / 复杂流程：选 LangChain，自定义召回、生成逻辑（如结合知识图谱）。

四、Step 4：构建知识库及优化 —— 让 RAG“查得准、查得快”

目标：将结构化语料转成 “可检索的知识库”，并通过高效召回策略优化，确保用户问题能快速匹配到相关文档。
核心逻辑：先建基础知识库，再用 RAG 高效召回方法优化，提升检索精度与速度。

4.1 基础知识库构建

核心组件：向量数据库（存储文本向量）+ 嵌入模型（将文本转向量）；
工具组合（素材推荐）：
- 向量数据库：FAISS（轻量）、Chroma（开源）、Milvus（大规模）；
- 嵌入模型：DashScope Text-Embedding-V4（阿里）、BGE-Large（智源）；
操作步骤（素材代码示例）：
1. 文本向量化：用DashScopeEmbeddings将分割后的 chunk 转成向量；
2. 存入向量库：用FAISS.from_texts(chunks, embeddings)创建知识库，保存到本地（./vector_db）；
3. 元数据关联：将 chunk 与页码、文档路径关联，存入page_info.pkl，方便后续溯源。

4.2 知识库优化：高效召回策略

这是 RAG “查得准” 的关键，结合素材中的 7 种召回方法，按 “优先级” 整合：

优化策略	适用场景	操作方法（素材同步）
合理设置 TOP_K	所有检索场景，避免召回太少 / 太多	检索时`k=5`左右（k=5 兼顾相关性与效率），如`similarity_search(query, k=5)`
混合索引召回	关键词匹配差但语义相关的场景	结合 BM25（关键词检索）与向量检索，用`Ensemble Retriever`整合结果，提升覆盖率
重排序（Reranking）	初步召回结果相关性低	用 BGE-Rerank 对召回的 10 个 chunk 重排序，将最相关的 3 个排在前面
查询扩展（多查询）	短查询（如 “投诉扣分”）语义不完整	用`MultiQueryRetriever`让 LLM 生成多个相似查询（如 “客户经理被投诉扣几分”），多轮检索合并结果
双向改写（Query2Doc）	短查询向量化效果差	将短查询扩写成长文本（如 “如何优化模型训练”→ 扩写包含优化器、混合精度的段落），再检索
Small-to-Big 策略	长文档（如 100 页 PDF）检索	先检索文档摘要（small），再通过摘要链接到完整文档（big），减少长文档检索耗时
父文档检索器	文档块太小导致上下文断裂	拆分成 “主 chunk（512 字符）+ 子 chunk（256 字符）”，检索子 chunk 后关联主 chunk，确保上下文完整

4.3 最终产出

优化后的知识库：

向量数据库（含文本向量、元数据）；
召回策略配置（如 TOP_K=5、重排序模型 = BGE-Rerank）；
检索接口（如load_knowledge_base函数，支持加载知识库并检索）。

五、Step 5：测试和优化 —— 让 RAG“答得对、跑得稳”

目标：通过测试发现问题（如召回不准、答案幻觉），再针对性优化，避免上线后出故障。
核心逻辑：从 “功能→性能→稳定性” 三层测试，结合 RAFT 优化模型，提升 RAG 效果。

5.1 功能测试：验证 “答得对”

测试方法：用 Step 2 的 QA 测试集，让 RAG 生成答案，对比标准答案；
工具：人工对比（小批量）、LangChain 的QAWithSourcesChain（批量验证）；

常见问题及优化：

问题	原因	优化方案（素材同步）
答案与语料不符（幻觉）	LLM 生成时脱离上下文	优化 Prompt（强制 “仅用检索到的 context 回答”），提升忠实度
召回不到相关文档	检索策略不当（如 TOP_K 太小）	调整 TOP_K=5，加 MultiQueryRetriever
答案不完整	文档块太小，上下文断裂	用父文档检索器，关联主 chunk

5.2 性能测试：验证 “跑得稳”

测试指标：QPS（查询每秒）、响应时间（目标 < 500ms）、召回延迟；
工具：JMeter（压测检索接口）、Grafana（监控 QPS / 延迟）；
优化方向：
1. 缓存热点查询：用 Redis 缓存高频问题的检索结果（如 “客户经理投诉扣分”），命中率≥90%；
2. 向量库扩容：FAISS 用 GPU 加速，Milvus 加节点，支撑高 QPS；
3. 服务无状态化：RAG 服务部署成集群，水平扩容应对峰值。

六、Step 6：最终效果评估 —— 用 Ragas 量化 “好不好”

目标：用专业工具量化 RAG 效果，避免 “凭感觉判断”，确保上线后满足业务需求。
核心工具：Ragas，覆盖 “检索→生成” 全链路指标。

6.1 评估前准备

输入数据：需 4 类信息（素材示例）：

数据类型	说明	来源
question	用户问题	Step 2 的 QA 测试集
answer	RAG 生成的答案	测试时 RAG 的输出
contexts	RAG 检索到的文档块	检索接口返回的 docs
ground_truths	标准答案	Step 2 的 QA 测试集

工具依赖：安装 Ragas 及依赖（注意 pydantic 版本：pip install pydantic==2.7.4，避免报错）。

6.2 核心评估指标（素材详解）

选择 4 个关键指标，覆盖 “检索质量” 和 “生成质量”：

指标	含义	达标阈值	素材示例（客户经理 QA）
上下文精度（Context Precision）	召回的文档中 “与标准答案相关” 的比例	≥0.8	召回 5 个文档，4 个与 “投诉扣分” 相关，精度 = 0.8
上下文召回率（Context Recall）	标准答案中 “能从召回文档找到” 的比例	≥0.85	标准答案 “扣 2 分” 能从召回文档找到，召回率 = 1.0
忠实度（Faithfulness）	答案与召回文档的事实一致性	≥0.9	答案 “扣 2 分” 完全来自文档，忠实度 = 1.0
答案相关性（Answer Relevancy）	答案与问题的相关程度	≥0.85	问题 “投诉扣分”，答案仅说扣分规则，无冗余，相关性 = 0.95

6.3 评估流程

准备数据集：用Dataset.from_dict()将 question、answer、contexts、ground_truths 转成 Ragas 格式；

执行评估：

from ragas import evaluate
from ragas.metrics import context_precision, context_recall, faithfulness, answer_relevancy

result = evaluate(
    dataset=dataset,
    metrics=[context_precision, context_recall, faithfulness, answer_relevancy],
    embeddings=embeddings  # DashScopeEmbeddings
)