章节三十七：RAG技术框架与评估

一、RAGFlow框架概述

1.1 RAGFlow的概念

RAGFlow：一个结合了RAG（检索增强生成）技术的工作流框架，用来搭建基于大模型的知识库问答系统。

RAG（检索增强生成）：先让AI去知识库里搜相关资料，再基于搜到的内容生成回答。好处是答案更准确，不会瞎编。

RAGFlow的核心特点：

第一，工作流程化。把文档处理、索引构建、检索、生成等环节串成一条流水线，每个环节都能灵活配置。

第二，模块化设计。包含文档加载器、处理器、嵌入模型、向量存储、检索器、生成器等模块，想换哪个换哪个。

第三，可视化监控。提供可视化界面和性能监控，方便调试和优化。

第四，评估与优化。内置评估框架，能测出系统哪里弱、怎么改。

应用场景：企业知识库问答、文档智能搜索、个性化推荐等需要结合外部知识的AI应用。

1.2 使用RAGFlow的意义

以前做知识库，要处理各种格式的文档（Excel、Word、PDF、PPT），每种都要写不同的提取脚本，清洗、分块、入库，非常麻烦。RAGFlow提供了统一方案：

第一，可以创建多个独立的知识库空间。

第二，通过可视化界面上传、管理文档，支持各种常见文件类型。

第三，系统自动解析文档内容并存储，不用手写脚本。

第四，创建知识助手来掌握不同的知识库，打造行业专家。

第五，通过对话方式查询知识库，答案会标注信息来源。

二、RAG工作流搭建

2.1 硬件要求

• CPU：至少4核（x86架构）
• 内存：至少16GB
• 磁盘：至少50GB

拉取镜像文件大约需要7.6GB空间，建议用云服务器学习。

2.2 安装部署步骤

第一步：购买云服务器，选择4核16GB配置，镜像选Ubuntu。

第二步：安装Docker。更新软件包 -> 安装Docker依赖 -> 添加Docker官方GPG密钥和软件源 -> 安装Docker -> 启动并确认成功。

第三步：修改系统内核参数，增加虚拟内存映射数量（ES等组件需要）。

第四步：创建目录并上传RAGFlow安装包，解压到/opt目录。

第五步：导入Docker镜像（包括ES搜索引擎、Infinity向量数据库、MinIO对象存储、MySQL关系数据库、Valkey高性能键值缓存）。

第六步：修改镜像标签，与配置文件保持一致。

第七步：启动RAGFlow。如果拉取超时，配置Docker加速器后重试。

2.3 配置知识库

第一步：浏览器访问服务器公网IP，注册账号并登录。

第二步：设置界面语言为中文。

第三步：配置大模型API-KEY。推荐用阿里百炼平台，在模型供应商里找到Tongyi-Qianwen并填入。

第四步：设置默认模型。千问系列比较全面，大语言模型、多模态模型、重排模型、向量化模型都能支持。

第五步：创建知识库，填写名称和描述。

第六步：上传文档并解析，支持PDF、Word、Excel等格式。上传后务必点击"解析"按钮。

第七步：创建知识助手。注意：助理描述一定要详细填写，否则API调用时可能无法灵活处理问题。

第八步：测试对话。回答会标注每条信息的来源和源文件，证明是基于知识库检索而非模型瞎编。

第九步：可以创建多个知识库和助手，让不同助手掌握不同知识库。

三、RAG评估与优化

3.1 评估的意义

Agent上线后的好用程度是多因素耦合的结果：切分、索引、召回、重排、图谱、提示词、模型、工具调用等。仅靠主观体验很难定位瓶颈。

评估的核心价值是把"感觉"变成"可量化、可回归、可定位"的工程闭环：

• 质量量化：用指标把输出质量数字化
• 回归保障：改了参数后能快速判断整体是否退化
• 发现短板：精准定位是检索模块的问题还是大模型生成的问题
• 自动化监控：减少人工验收成本和主观偏差

3.2 主流评估方法

基于数据集的离线评估（Golden Set）：准备question + ground_truth，用当前系统跑出answer + contexts，再人工对比打分。优点是可复现、可回归；难点是黄金集建设成本高。

LLM-as-a-Judge（大模型当裁判）：让更强的模型对"答案是否正确/是否基于上下文/是否跑题"做判分。代表工具有RAGAS、DeepEval、TruLens等。优点是更贴近语义质量；风险是裁判模型本身有偏差。

3.3 RAGAS评估框架

RAGAS：一套面向RAG系统的评测框架，在缺少人工标注答案的情况下，用相对自动化的方式衡量RAG的关键质量。

RAGAS把一次问答拆成三要素来评估：Question（问题）、Contexts（检索到的上下文证据）、Answer（生成的答案），可选Ground_truth（参考答案）。

常见指标：

指标	说明	判定方式
Faithfulness（忠实性）	答案中的陈述是否能被上下文支撑，越高越不容易"编"	LLM参与判定
Answer Relevancy（回答相关性）	答案是否真正回答了问题，是否跑题	embedding相似度判断
Context Precision（上下文精确率）	检索到的内容里，有用内容占比是否高	LLM/embedding
Context Recall（上下文召回率）	是否覆盖了回答问题所需的关键信息	LLM
Answer Correctness（正确性）	生成答案与参考答案的对齐程度	embeddings语义相似度

3.4 评估优化步骤

第一步：准备评测集（问题列表，可来自真实日志抽样/人工构造/AI合成）。

第二步：编写RAGAS的评估程序（初始化评估组件、加载测试数据、运行RAG pipeline、构建评估数据集、执行评估、导出结果并提取bad case）。

第三步：运行评估，生成评估结果。

第四步：定位问题：

• Context Precision低：检索噪声大，需要重排序、过滤、改embedding或chunk。
• Context Recall低：检索没找全，需要调整top-k、召回策略或chunk粒度。
• Faithfulness低：生成在编，需要优化提示词、引用证据、降低温度等。

第五步：bad case分析。

第六步：优化程序。

3.5 Bad Case分析实例

案例一：错失切片

问题：faithfulness较低，context_precision和context_recall为0。说明相关切片没有最终进入提示词中。可能被embedding匹配遗漏、RRF融合过滤掉、或rerank重排序过滤掉。

解决思路：调整切片大小（把最大长度从2000改为500，最小从500改为100），并考虑纳入更多切片到最终提示词中。越大的切片关键词句会被稀释，评分准确度下降。

案例二：提示词问题

问题：各检索指标都不低，但answer_correctness不高。回答太啰嗦、太散、观点不够集中。

解决思路：在prompt中明确要求"直接回答，不要过度解释，控制字数"。

案例三：缺失逻辑

问题：各指标正常，但答案中存在事实性错误。大量噪声干扰了最终答案输出。

解决思路：利用图谱信息。图谱能把内容提纯，减少干扰，提取核心关键点。具体做法包括优化图谱提示词、修改查询流程让图谱查询结果带出description信息、增加触发警告的时机描述。