HuggingFists-低代码玩转LLMRAG(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工程的垂域数据接入问题。

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