HuggingFists- 低代码玩转 LLM RAG(1) Embedding

伴随着 LLM 日新月异的发展，业界对与 LLM 的落地思考逐渐聚焦到到两个方向上。一是 RAG(Retrieval-Augmented Generation),检索增强生成；一是 Agents, 智能体。我们这个系列的文章也将围绕这两个应用方向介绍如何使用 HuggingFists 进行落地实现。其社区版可通过以下链接获得(https://github.com/Datayoo/HuggingFists)。

什么是 RAG

RAG，检索增强生成，即大模型 LLM 在回答问题或生成文本时，通过外挂其他数据源的方式来增强 LLM 的能力。使用外挂数据源检索出相关信息，然后基于这些检索出的信息进行回答或生成文本，从而提高回答的质量。外挂数据源可以是向量数据库、文档数据库、搜索引擎或应用系统等。RAG 技术使得 LLM 在垂直领域应用时，不需要重新训练整个大模型，只需要外挂上相关知识库就可提供问答服务。从而节省了大模型的实施成本，同时提高了大模型在垂直领域的应用的时效性、准确性和安全性。

RAG 工程面临的问题

基于向量数据库的 RAG 结构图

    上图为基于向量数据库实现 RAG 的典型结构。除该结构外，业界还有基于 ElasticSearch 或二者共用的工程结构。本节将主要探讨所有工程结构都会面临的两个通用问题，一是 RAG 工程的技术选型问题；二是 RAG 工程的垂域数据接入问题。

• RAG 工程选定工程结构后，仍有大量的技术方案需要根据工程环境进行技术选型。如工程为云环境，则可以使用云端的向量数据库、LLM 及 Embedding 技术；若工程要求本地化部署，且不具备外网服务访问条件，则需要选择可本地部署的向量库、LLM 及 Embedding 等技术。如今，可供选择的技术方案有很多，工程师需要消耗不小的精力来试验并搭建出合适的选择。另外，如何优化检索也需要不断尝试。需要找出合适的方法来提高检索结果与问题的相关性，控制检索结果的大小以适配 LLM 的 Context 限制及 token 消耗。在找到合适的方案前，这些都将消耗不小的精力。

• RAG 工程待处理的垂域数据种类、格式繁多，有效提取这些数据并存入检索系统工作量巨大。这类工作其本质就是一个 ETL 过程。与传统的数据分析类项目相似，垂域数据预处理的工作量将占据整个项目的 70%～80%。差别在于，传统数据分析项目面向的是结构化数据，而 RAG 项目面向的则更多是非结构化的数据，且情况更复杂。如相关数据是以 Json 或 XML 等格式描述的，且被存储在了如 HBase、MongoDB 等数据库中；文档结构比较复杂，无法简单通过文本抽取获得文档内容，而是需要文本抽取+OCR 识别等多种技术相结合等。这些情况无疑都会加大 RAG 工程的落地成本。

HuggingFists 是什么

解决上述问题，相信绝大多数 LLM 的关注者会首先想到 LainChain。的确，LainChain 无疑是目前实现 LLM 应用最炙手可热的框架。其采用 Python 语言作为开发语言，简单易用，拥有大量拥趸。自诞生以来，发展迅猛，且仍在不断完善中。

但有如我们在上述问题的描述中所说，RAG 工程技术选型时有很多试验工作，垂域数据接入时有复杂场景需要适配。这些工作都存有更灵活、更便捷、更易用的潜在需求。特别是垂域数据接入，在过去几十年的传统数据接入工程中，存在大量低代码定义数据处理 Pipeline 的工具，如 Kettle、StreamSets 等。这些工具为复杂场景的垂域数据接入提供了很好的方案指导，可大大提高数据接入的效率，降低数据接入人员的编程能力要求。

基于此，HuggingFists 应运而生，其可被视为是面向 AI 领域的低代码应用框架。力图成为 LainChain 的可视化平替，能够全面支持非结构化数据的 ETL 处理以及包括 LLM 在内的各类模型的应用。同时，其也支持作业调度，可确保应用与生产环境的集成。HuggingFists 与 LainChain 一样，目前也在持续完善中，真正做到 LainChain 的平替尚待时日。

低代码向量化 Word 文档

Word 向量化流程图

    上图展示了一个将一个 Doc 文件向量化存入数据库的流程。流程的定义过程如下：

1.  点击“流程”菜单，创建一个流程。

2.  利用左侧算子树的搜索框，依次搜索“文件输入”、“WORD 文本抽取”、“按章节抽取”、“阿里文本 Embedding”及“Milvus 写出”算子，并将它们拖拽到中间的流程定义面板中。并依据图中所示的算子连线关系，连接各个算子。

Ø  “文件输入”算子用于从缺省文件系统中读取对应的文件。支持同时读取多个文件或者读取多个文件夹。示例中用来读取指定的 WORD 文件。这里的 WORD 文件是一篇有关数据安全治理的文章。文章章节情况如下图所示，大小章节共十四个：

文章章节

HuggingFists 除支持“文件输入”算子外，还支持“Ftp 输入”、“阿里云输入”、“百度盘输入”、“腾讯云输入”等多种算子，用于满足从不同文件系统直接读取文件的需求。为了降低用户使用算子的成本，HuggingFists 为同类型算子定义了同样的配置方式。

Ø  “WORD 文本抽取”算子，用于抽取 WORD 文件中的文本。HuggingFists 除支持 WORD 文本抽取外，还支持 WORD 表格抽取、WORD 图片抽取以及 PDF、VISIO、PPT 等文件的抽取。另外，也支持 CSV、Excel、Json、Xml 等格式文件的读取。

Ø  “按章节抽取”算子负责将 WORD 的整个文本按章节切分为多块。块的内容尽量相关且紧凑。进行检索时，返回的文本尽量与查询相关且大小合适。HuggingFists 还提供了按特征拆分文本、按段拆分文本以及按 token 数拆分文本等。在流程图中，我们看到该算子有一个连接从端口连到了面板边缘的“result”端口。表示流程执行时会将该端口的数据输出为数据结果，以便于流程的调试，缺省状态下，只输出端口的前 1000 条数据。

Ø  “阿里文本 Embedding”算子负责完成文本的向量化。文本向量化后被转换为一个 float 向量。HuggingFists 除支持“阿里文本 Embedding”外，还支持“OpenAI 文本 Embedding”、“HuggingFace 文本 Embedding”以及“HuggingFace 本地化文本 Embedding”。HuggingFace 相关算子可以选取 HuggingFace 网站支持的所有 Embedding 模型完成文本的向量化。

Ø  Milvus 写出”算子将向量及其它数据一并插入向量库。除 Milvus 向量库外，HuggingFists 还支持腾讯的“VectorDB”向量库。

3.  保存流程，并点击运行按钮。查看运行结果，数据被写入 Milvus 向量库。查看流程的结果数据，WORD 文件被切分成了 14 个章节块，该章节块的数量与文档中的章节数量一致。结果如下图：

流程运行结果

流程运行结束，WORD 文件被写入了 Milvus 向量库。我们可以再写一个流程，来验证可以从向量库中检索出相关文本。

向量库查询

如上图所示，向量读取流程由“交互式数据输入”、“阿里文本 Embedding”、“Milvus 读取”及“过滤”算子组成。其模拟了一个基于输入问题检索向量库获取垂域内容的场景。在“交互式数据输入”算子输入问题，“数据安全治理框架有哪些？”。“阿里文本 Embedding”算子选取向量类型为“查询向量”，将输入的问题按查询向量进行向量化。然后以向量为条件从 Milvus 数据库中检索问题相关内容。此时需要对结果集大小进行限制，否则会返回大量相关度不高的内容，影响后续模型处理的效果。“过滤”算子用于进一步过滤与文本相关度不高的数据。流程里设定只保留相关度值<5000 的数据。执行流程获得的结果如下：

向量库查询结果

由图中可以看到，查询到的文本块与问题的相关很高，如果将该内容输出到 LLM，可以借助 LLM 的能力，很好的进行垂域知识的回答。关于如何使用 HuggingFists 调用 LLM，完成 RAG 的问答，我们将在下一篇文章中阐述。

    最后，HuggingFists 操作简单，也支持对图像的向量化写入及读取。目前系统支持的图像向量化算子为“HuggingFace 图像 Embedding”算子，有兴趣的朋友可以安装一个 HuggingFists 工具自己动手体验一下。