项目背景

       最近，有时间，想着动手实战一下，从0到1搭建一个 RAG 系统，也是想通过实战的方式来更进一步学习 RAG。因此，就定下了以项目实战为主，书籍为辅的执行方式。（书籍是黄佳老师著的《RAG 实战课》）

       在我的认知中，技术一直是作为一个工具，它就是为解决问题而生的，而对于企业来说，问题就是企业的业务。本项目选择的业务领域是金融，为何选择金融呢？有两个原因吧。一个是和工作背景有关，以前从事的业务领域一直是和金融相关的；另一个原因是个人兴趣，对金融相对感兴趣，想借此多了解与学习。

项目目标

1. 从0到1做一个 RAG 系统；
2. 学习构建 RAG 系统的技术应用；
3. 学习评估和优化 RAG 系统。

项目计划

大的里程碑主要分为两个：

1. 首先是构建一个基于国家金融监督管理总局（National Financial Regulatory Administration，简称 NFRA ，后文统一使用它替代）政策法规的智能问答 RAG 系统；
2. 其次是基于该智能问答 RAG 系统进行评估与优化。迭代优化整体思路会参考如下图：

项目简介

项目名称

        NFRA 智能问答系统。

项目代码

        项目代码，已开源发布到 Gitee 平台。有需要，可点击

技术栈

        这里主要介绍项目中使用到的核心技术，LangChain 和 Milvus，以及在项目中应用到的核心技术点。

LangChain

        LangChain 是一个框架，它使得开发者能够更加容易地构建基于大型语言模型（LLMs）的应用程序。通过提供一系列工具和组件，LangChain 可以帮助开发者快速搭建如聊天机器人、智能问答系统等应用。

LangChain 需要掌握的关键概念：

1. Models (模型)

        LangChain 支持多种 LLM 接口，包括 OpenAI、Hugging Face 等，提供了标准化接口，允许轻松切换不同模型。

• LLMs：处理纯文本输入并返回纯文本输出的模型。
• Chat Models：支持格式化的聊天消息作为输入和输出，更适合对话应用。

2. Prompts (提示管理)

Prompts 模块帮助开发者设计与模型交互的提示词，并对输出进行解析。

• PromptTemplate：模板化提示，可以动态插入变量。
• Output Parsers：将模型输出结构化为易于理解的格式。

3. Chains (任务链)

Chains 将多个模型调用或工具调用组合成工作流，实现复杂流程的编排。

• 预定义链：如 LLMChain、SequentialChain 等。
• 自定义链：可以根据需求创建自己的链。

4. Indexes (索引与检索)

Indexes 模块集成外部数据源，使得模型能够访问这些数据进行增强生成。

• Document Loaders：从各种来源加载文档，如 PDF、网页等。
• Text Splitters：处理长文本分块以便于处理。
• Vector Stores：使用向量数据库存储嵌入式表示的数据，便于相似性搜索。
• Retrievers：结合 LLM 实现 RAG（检索增强生成）。

5. Callbacks (回调)

Callbacks 提供了一种机制来监控模型调用、记录日志以及实现其他高级功能，比如异步支持。

6. Embeddings

Embeddings 模块涉及文本向量化表示，这对于基于内容相似性的搜索至关重要。

• Vector Similarity Calculation：计算向量之间的相似度。
• Vector Storage and Retrieval：管理和检索向量数据。

Milvus

        Milvus 是一个开源的、高性能的向量数据库，它支持存储、索引和查询大量的向量数据。这些向量通常由机器学习模型生成，用来表示文本、图像、音频等复杂的数据类型。通过使用 Milvus，可以快速地找到与给定向量最相似的数据项，这对于构建智能问答系统、推荐系统、搜索引擎等非常有用。

Milvus 需要掌握的关键概念：

1. Collection(集合)：相当于关系型数据库中的表，包含一组 entity 
2. Entity(实体)：相当于表中的一行，包含一组 field 
3. Field(字段)：可以是结构化数据(数字、字符串)或向量 
4. Partition(分区)：集合的物理分区，用于减少数据读取范围 
5. 向量索引：提高查询速度，支持多种索引类型如 IVF_FLAT、IVF_PQ、HNSW 等

RAG 系统评估

        RAG 系统评估的重要性，上文已谈及，不再赘述。不同 RAG 系统的评估数据集，格式可能会有所不同，有的时候存在精确的唯一数据来源，而有的时候答案可能来源于多个页面或者文档。NFRA 智能问答系统评估，针对的是答案来源单一文档的。

        目前，对 RAG 进行整体评估的，有一个叫 TRIAD 框架，它提供了一个无参照的评估体系。这种无参照的评估体系省去了构建评估数据集的麻烦，但同时也意味着评估指标本身具有一定的非确定性。因此，我们在实际项目中，还是要具体问题具体分析的，而且目前也尚未形成一种通用且可行的 RAG 评估标准。

        RAG 系统评估主要分为检索评估和响应评估。NFRA 智能问答系统评估，重点是放在检索评估。之所以这样做，主要是因为在开发验证过程中，发现了只要能检索到问题关联的政策法规条文作为上下文给到 LLM，大语言模型（项目中默认使用的模型是：deepseek-chat）生成的回复效果是相当不错的，这对于使用基于忠实度（扎实性）指标评估来说，是可以达到良好及以上的。还有，通过调整提示词，也会得到不一样的回复风格。（大家可以搭建起项目来尝试与验证）

        检索评估指标，选择的是——召回率。召回率衡量系统检索到的相关文本块的全面性，即检索到的相关文本块数量占数据库中所有相关文本块数量的比例。

 评估数据集

        数据集文件路径：/evaluation/data

        一共三个表单，WX（文心），40条问答对； TY（通义），54条问答对； TXYB（腾讯元宝），50条问答对。总共问答对：144条。

RAG 相关处理说明

切分策略：分块大小： 500； 分块重叠大小： 100； 使用正则表达式，[r"第\S*条 "]
嵌入模型：模型名称： BAAI/bge-base-zh-v1.5 (使用归一化)
向量存储：向量索引类型：IVF_FLAT （倒排文件索引+精确搜索）；

向量度量标准类型：IP（内积）； 聚类数目： 100； 存储数据库： Milvus
向量检索：查询时聚类数目： 10； 检索返回最相似向量数目： 2

检索评估结果

数据表单	有效 问题个数	TOP1 个数	TOP1 平均相似度	TOP1 召回率	TOP2 个数	TOP1 平均相似度	TOP2 召回率	TOP N策略个数	TOP N策略召回率
通义	29	18	0.6855	62.07%	5	0.6716	17.24%	23	79.31%
元宝	33	17	0.6881	51.52%	7	0.6953	21.21%	24	72.73%
文心	21	17	0.6509	80.95%	2	0.6504	9.52%	19	90.48%
总计	83	52	0.6748	62.65%	14	0.6724	16.87%	66	79.52%

详细评估数据集检索处理结果，可见文件：/evaluation/eval_out

表格说明：

• 有效问题个数：是在 LLM 生成的问答对前提下，删除了无效的问题，比如不在知识库中的问题，过于开放性的问题等；
• TOP1、TOP2 个数：是指检索回来的文本块（被最终用于回复问题的文本块在检索返回时相似度的排名）的数量。越是位于 TOP1，说明检索效率越高；
• TOP N 策略：就是在问题检索时，需要返回最相似向量个数。（本次评估，N=2）

检索评估结论：

       从表格中可以看到，在有效的 83个问题评估中，总共有 66个问题相关文本块被召回，召回率是：79.52%。算是中规中矩吧，后续有待优化，至少得达到 90%以上。

检索召回率不高分析

        在核对检索评估结果数据的过程中，基本上都是未能检索到相关的条文，因而召回率不够高。召回率不高可能存在的原因有多方面：

1. 有些问题相关的条文内容少，在文本块中占比就会小，文本块经过嵌入处理后损失一定的语义性，在检索时相似度得分就不会高，就很可能无法达到 TOP N 返回；（探究能否把政策法规逐条分块）
2. 条文因分块大小而刚好被截断，致使出现类似上述第一点的问题；
3. 查询问题与其他文件的分块存在更高的相似性，致使实际相关的文本块未能出现在 TOP N 中；（探究检索前处理技术——查询重写；检索后处理技术——重排）
4. ……

其他

• 项目过程遇到的问题，考虑到文章结构和篇幅问题，会单独再写一篇。

总结

从0到1做 RAG系统

从0到1做 NFRA 智能问答 RAG系统的过程，有几点感受比较深的：

1. 首要弄清楚你这个智能问答系统，主要面临的用户问题都有什么，要在项目开始前调研清楚。若是在公司里，我们要拉着相关业务部门把这个梳理清楚，整理出问答表。这个表会作为 RAG 系统评估数据集的重要来源。
2. 其次，确定 RAG系统的评估指标。在梳理、整理问答对的这个过程中，我们也会得出评估 RAG 系统所要的指标，检索评估指标是看精确率，还是召回率，亦或者是它们的平衡—— F1 分数等等；响应评估指标，是基于 n-gram 匹配程度，还是基于语义相似性，亦或者是基于忠实度（扎实性）等。
3. 接着，是对用于构建知识库的资料进行处理，主要包括：读取、获取、切分。同样地步骤一进行的梳理、整理问答对过程，会让我们在处理资料时有一个总体认知，能相对好地处理诸如此类问题——需要在资料中获取什么样的知识，是否需要获取元数据，是否要做元数据的过滤，怎么切分这些知识内容等。这一步，与最终检索的效果密切相关。
4. 紧接着，要考虑选择什么嵌入模型来进行分块的嵌入，选择什么样的向量数据库进行嵌入的存储。这一步，看似是技术为主，但它又与业务息息相关。
5. 往下，到了检索、构建 prompt、生成回复，一般来说，按项目迭代的过程来看，这里面先考虑的是生成模型的选择。
6. 再往后，就是对 RAG 进行评估。具体上述RAG 系统评估章节，已谈。

实战感受

• 通过项目实战方式来学习技术是一个挺好的方式，不过短期内需要投入的时间会相对多，因为在实战的过程中，会犯一些看似简单但又让你一时难以解决的问题，所以要有一定的耐心。

这里举一个项目中遇到的问题：在做向量检索过程中，从 Milvus 向量数据库中查询并返回结果，没有注意到 Collection.search() 和 MilvusClient.search() 的区别，这两个方法的传参挺像的，而且方法名又是一样的，导致在处理查询结果上一直获取不到想要的内容。当搞清楚Collection.search() 返回的是 Hits对象的集合，而 MilvusClient.search() 返回的是字典类型的集合，问题自然就解决了。

• 以往做系统，我们主要关注的是准确性，不管是面向关系型还是非关系型数据库，都是如此；而如今，我们主要关注的是相似性，面向的是向量数据库。不管如何，都是试图通过一种技术手段把现实世界进行建模、数据化，根据用户的输入，从数据化的“现实世界”中找到满足用户的输出。

---

项目代码地址：https://gitee.com/qiuyf180712/rag_nfra