HuggingFists-低代码玩转LLMRAG(1) Embedding

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

什么是RAG

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

RAG工程面临的问题

HuggingFists-低代码玩转LLMRAG(1) Embedding_第1张图片

基于向量数据库的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文档

HuggingFists-低代码玩转LLMRAG(1) Embedding_第2张图片

Word向量化流程图

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

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

         2.利用左侧算子树的搜索框,依次搜索“文件输入”、“WORD文本抽取”、“按章节抽取”、“阿里文本Embedding”及“Milvus写出”算子,并将它们拖拽到中间的流程定义面板中。并依据图中所示的算子连线关系,连接各个算子。“文件输入”算子用于从缺省文件系统中读取对应的文件。支持同时读取多个文件或者读取多个文件夹。示例中用来读取指定的WORD文件。这里的WORD文件是一篇有关数据安全治理的文章。文章章节情况如下图所示,大小章节共十四个:

HuggingFists-低代码玩转LLMRAG(1) Embedding_第3张图片

文章章节

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个章节块,该章节块的数量与文档中的章节数量一致。结果如下图 

HuggingFists-低代码玩转LLMRAG(1) Embedding_第4张图片

流程运行结果

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

HuggingFists-低代码玩转LLMRAG(1) Embedding_第5张图片

向量库查询

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

HuggingFists-低代码玩转LLMRAG(1) Embedding_第6张图片

向量库查询结果

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

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

你可能感兴趣的:(数据科学计算,低代码,embedding,HuggingFists,RAG,LLM)