项目背景
最近，有时间，想着动手实战一下，从0到1搭建一个 RAG 系统，也是想通过实战的方式来更进一步 学习 RAG。因此，就定下了以项目实战为主，书籍为辅 的执行方式。（书籍是黄佳老师著的《RAG 实战课》）
在我的认知中，技术一直是作为一个工具，它就是为解决问题而生的，而对于企业来说，问题就是企业的业务。本项目选择的业务领域是金融，为何选择金融呢？有两个原因吧。一个是和工作背景 有关，以前从事的业务领域一直是和金融相关的；另一个原因是个人兴趣，对金融相对感兴趣，想借此多了解与学习。
项目目标
- 从0到1做一个 RAG 系统；
- 学习构建 RAG 系统的技术应用；
- 学习评估和优化 RAG 系统。
项目计划
大的里程碑主要分为两个：
- 首先是构建一个基于国家金融监督管理总局**（National Financial Regulatory Administration，简称 NFRA ，后文统一使用它替代）**政策法规的智能问答 RAG 系统；
- 其次是基于该智能问答 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 需要掌握的关键概念：
- Collection(集合)：相当于关系型数据库中的表，包含一组 entity
- Entity(实体)：相当于表中的一行，包含一组 field
- Field(字段)：可以是结构化数据(数字、字符串)或向量
- Partition(分区)：集合的物理分区，用于减少数据读取范围
- 向量索引：提高查询速度，支持多种索引类型如 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%以上。
检索召回率不高分析
在核对检索评估结果数据的过程中，基本上都是未能检索到相关的条文，因而召回率不够高。召回率不高 可能存在的原因有多方面：
- 有些问题相关的条文内容少，在文本块中占比就会小，文本块经过嵌入处理后损失一定的语义性，在检索时相似度得分就不会高，就很可能无法达到 TOP N 返回；（探究能否把政策法规逐条分块）
- 条文因分块大小而刚好被截断，致使出现类似上述第一点的问题；
- 查询问题与其他文件的分块存在更高的相似性，致使实际相关的文本块未能出现在 TOP N 中；（探究检索前处理技术------查询重写；检索后处理技术------重排）
- ......
其他
- 项目过程遇到的问题，考虑到文章结构和篇幅问题，会单独再写一篇。
总结
从0到1做 RAG系统
从0到1做 NFRA 智能问答 RAG系统的过程，有几点感受比较深的：
- 首要弄清楚你这个智能问答系统，主要面临的用户问题都有什么 ，要在项目开始前调研清楚。若是在公司里，我们要拉着相关业务部门把这个梳理清楚，整理出问答表 。这个表会作为 RAG 系统评估数据集的重要来源。
- 其次，确定 RAG系统的评估指标 。在梳理、整理问答对的这个过程中，我们也会得出评估 RAG 系统所要的指标，检索评估指标 是看精确率，还是召回率，亦或者是它们的平衡------ F1 分数等等；响应评估指标，是基于 n-gram 匹配程度，还是基于语义相似性，亦或者是基于忠实度（扎实性）等。
- 接着，是对用于构建知识库的资料进行处理，主要包括：读取、获取、切分。同样地步骤一进行的梳理、整理问答对过程，会让我们在处理资料时有一个总体认知，能相对好地处理诸如此类问题------需要在资料中获取什么样的知识，是否需要获取元数据，是否要做元数据的过滤，怎么切分这些知识内容等。这一步，与最终检索的效果密切相关。
- 紧接着，要考虑选择什么嵌入模型 来进行分块的嵌入，选择什么样的向量数据库进行嵌入的存储。这一步，看似是技术为主，但它又与业务息息相关。
- 往下，到了检索、构建 prompt、生成回复，一般来说，按项目迭代的过程来看，这里面先考虑的是生成模型的选择。
- 再往后，就是对 RAG 进行评估。具体上述RAG 系统评估章节，已谈。
实战感受
- 通过项目实战方式来学习技术是一个挺好的方式，不过短期内需要投入的时间会相对多，因为在实战的过程中，会犯一些看似简单但又让你一时难以解决的问题，所以要有一定的耐心。
这里举一个项目中遇到的问题：在做向量检索过程中，从 Milvus 向量数据库中查询并返回结果，没有注意到 Collection.search() 和 MilvusClient.search() 的区别，这两个方法的传参挺像的，而且方法名又是一样的，导致在处理查询结果上一直获取不到想要的内容。当搞清楚Collection.search() 返回的是 Hits对象的集合，而 MilvusClient.search() 返回的是字典类型的集合，问题自然就解决了。
- 以往做系统，我们主要关注的是准确性 ，不管是面向关系型 还是非关系型 数据库，都是如此；而如今，我们主要关注的是相似性 ，面向的是向量数据库。不管如何，都是试图通过一种技术手段把现实世界进行建模、数据化，根据用户的输入，从数据化的"现实世界"中找到满足用户的输出。