章节三十七：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信息、增加触发警告的时机描述。
