写在RAGFlow开源2万星标之际

RAGFlow自2024年4月1日正式开源,时至今日,不到7个月时间已经站在了Github 2万星标的台阶之上。在6月底Github 1万星标的时候,我们曾经写了一篇文章,提出RAG 2.0的口号【参考文献1】,论述了RAG作为一种以搜索为中心的系统,为保证最终的对话效果,需要端到端的在每个环节来解决RAG面临的问题,这包含数据的信息抽取、文档预处理、以及数据的检索和排序。此时此刻,我们回首过去,是时候来做一番总结,并同时展望未来。

我们的总结和展望,来自如下几个层面:

  1. 老生常谈,长久以来关于RAG本身的争论,它究竟是否真的只是一种临时方案。

  2. RAGFlow做对了什么,接下来会从哪些方面改进。

  3. RAG和Agent,工作流之间到底是什么关系。

  4. 多模态RAG是当下,还是未来已来。

一、关于RAG本身

RAG自从2020年由Meta提出,并在2023年春Nvidia GTC大会后火热之后,就一直争论不断。有趣的是,这种争论,大都来自媒体,咨询公司,或者一些研究机构,而来自企业端的声音很少,在国内一些常见的AI技术峰会,RAG分论坛的人气通常都是最高的之一。这反应了一个事实,RAG已经是一种事实上的落地标准架构,尽管它面临这样那样的问题,但确实没有其他方案可以取代。

这些争论,大体上可以分为两个阶段:

第一个阶段集中于2023年,主要争议来自微调对比RAG。这个争议持续到2023年底已经基本偃旗息鼓,因为结论很明显,从成本和实时性角度,RAG具有压倒性优势,而效果上相差也并不大,即使需要微调介入的场景,RAG通常也不可或缺。

第二个阶段集中于2024年上半年,主要争议来自长上下文LLM对比RAG。这个争议到如今也接近偃旗息鼓,结论同样很清晰,两者是天然的组合,在能力上取长补短。来自多方面的研究已经证实,单纯就AI能力来讲,长上下文LLM依然面临在上下文段落增加时准确率不断下降的事实,因此,在任何情况下,提供高精度的搜索系统(RAG)都是极有价值的。这如同一个类比,我们不能因为某个人聪明和记忆好,就要让他去回答一切问题而不给他提供任何工具。

下图是我们针对LLM和RAG在各自能力的演进上对过去做的一个总结,以及对未来的展望。我们在第四部分会再次回顾这张图。

相比于一些机构和媒体针对大模型落地不佳,还有大模型泡沫破灭的的悲观论调,我们始终坚定的认为,这些都只是人们对过去AI过高期待带来的回调,随着大模型能力按照以上能力逐渐进化,我们可以看到,不论是个人还是企业端,它们普遍受益于大模型的时代并不遥远,AI已经重塑了整个软件生态,我们不知道AGI什么时候发生,但如果这都不叫革命,那什么才是呢?

二、关于RAGFlow

在RAGFlow开源达到万星的时候,我们撰文提出了RAG 2.0,指出要解决好RAG的问题,需要从数据抽取、数据预处理,以及检索和排序来端到端地解决这个搜索难题。

在这些步骤中,对最终对话影响最大的,就是第一个阶段数据抽取,因此,常常是一个好的数据入口,决定了后续Pipeline的最终输出质量。事实上,RAGFlow开源星标迅速增长的第一个原因,就是RAGFlow内置的组件DeepDoc,它能够对用户的非结构化文档进行布局检测,确保文字能够在保持语义的前提下再进行Text Chunking。进一步的,对于一些图表类数据,还借助于专用的表格结构识别模型来把表格提取出来,方便用户对表格进行问答。用一张图来示意,就是如下的流程。

DeepDoc诞生于2023年底,我们在面临复杂文档时,尝试了各种模型,包括当时的多模态文档大模型,专门用于表格解析的Table Transformer,乃至专门用于解析非结构化数据的Unstructured等等,在无法得到理想的结果后,我们不得不尝试来自己训练模型,结果发现,采用简单的卷积网络,将文档结构识别和表格结构识别都定义为一个目标检测问题,这样训练出来的模型效果居然超过了其他更为复杂的模型。

站在一年后的今天,随着技术的演进,我们的认知也发生了变化。DeepDoc,伴随着RAGFlow的开源,在面临更大量的用户场景时,泛化能力不佳的情况也越来越多,这促使我们也早早开启了更进一步的研究。在我们当前的实践中,基于 Encoder-Decoder 架构的Transformer网络,表现出了更胜一筹的准确度和泛化能力,它将成为未来企业级DeepDoc的标准配置。以上工作,在近期一篇很知名的工作OCR 2.0【参考文献2】也有相同的结论。在过去,我们一直试图解释DeepDoc并不是一个OCR模型,它的主要目标是文档布局,表格布局的检测与识别,而识别文字的OCR,DeepDoc一直都是调用开源的PaddleOCR,自己没有做任何相关工作。但在OCR 2.0的定义中,它把这一切都纳入了OCR框架,并且用一个Transformer网络解决所有问题,尽管在垂直场景下表现未必是SOTA,但这已经证明了一个统一的网络,如何把所有复杂文档数据都准确解析的技术价值。

数据预处理,在我们对RAG 2.0的定义中,主要就是指GraphRAG,它的核心目标,是解决在RAG中的一个典型痛点,就是问题和答案之间的语义鸿沟,根据问题无法搜索到答案所在的地方。微软在7月初开源了GraphRAG之后,在RAG社区引起了广泛关注,尽管GraphRAG的论文在年初就已经发表。事实上,利用知识图谱来改进RAG的对话效果,一直是个确定性的事情,但困难就在于这件事情的非标准化——大量的人工被用于校对知识图谱的准确性上。而GraphRAG的价值在于,它让知识图谱构建这件事变成自动化和标准化——它依赖于通过大模型来抽取文档中的命名实体和实体之间的关系。当然,这并不意味着,这种自动化构建的知识图谱,可以像人工构建的那样,在数据可视化上提供较大的参考意义,这是因为,没有校对的知识图谱,依然存在大量错误,包括实体重复,实体关系缺失,实体抽取错误等等,然而,即便这样,自动生成的知识图谱,再结合原文做混合搜索,确实可以相当程度上缓解语义鸿沟的问题。这符合我们通常在解决搜索系统的时候,遇到各种查询的bad case,需要引入查询意图一样。举例来说,我们输入查询“手机”,如何避免返回手机配件,这需要在查询的过程中,自动识别用户的意图是手机或者消费电子设备这样的分类。因此,查询意图,本质上就是对用户的查询来补充语义和Tag信息,而知识图谱,同样是给被搜索的文档数据,补充语义和Tag。这种自动化构建知识图谱的方式简单有效,因此RAGFlow在8月的版本,就迅速把GraphRAG 加到了项目中,并且会持续迭代。GraphRAG代表了利用大模型对数据做增强的一种标准手段,类似的方式和场景还有很多,例如RAGFlow早先加到系统的RAPTOR,它是先对文档做聚类,然后让大模型针对聚类生成摘要,这些信息连同原始文本共同做混合搜索,给出答案。从原理上来说,它一样可以起到弥补问题和答案之间语义鸿沟的用途。还有一些特定场景,需要根据用户的特定需要获取特定答案,这同样也依赖用大模型从原始文本抽取辅助内容,再利用这些内容辅助原始文本做混合搜索。在2023年大模型火热的时候,知乎上曾经有提问,有了大模型,是否NLP就已经消亡,从某种程度来讲,确实如此,因为但凡涉及到自动语义信息抽取和加工的任务,例如摘要生成,实体抽取,知识图谱,对话意图,等等,这些都需要依赖大模型来提供额外的素材,然后再伴随着原始数据一并做搜索召回。这就提出了一个新的挑战,就是Token消耗惊人,为了降低成本,这又引发了对小的各类微调后的较小的大语言模型的各种需求。针对特定行业的知识图谱或者命名实体抽取的小模型,可以极大降低Token消耗。因此,一个高精度的RAG系统,越来越离不开搜索和各种模型的交叉运用。

在我们对RAG 2.0的定义中,同样提到了我们专门为下一代RAG设计的AI原生数据库Infinity,它提供了功能最为强大,同时性能也是最高的混合搜索(多路召回)能力。来自社区的同学一直在关心一个问题,就是RAGFlow为什么只采用Elasticsearch,而没有采用其他向量数据库,同时也很关心Infinity到底什么时候可以被集成到RAGFlow当中。针对前一个问题,因为Elasticsearch是开源数据库当中,为数不多可以兼具全文搜索和向量搜索两路混合召回能力的数据库(具备类似能力的云数据库Rockset,刚刚被OpenAI收购不久)。对于RAG来说,全文搜索不是一个可选项,这一点在当下也开始逐渐成为共识。那么,RAGFlow为什么不一直采用Elasticsearch作为首选,而重新开发一款数据库呢?这主要包含多方面的考虑:

其一、Elasticsearch并不是专门为RAG设计的数据库,只是正好满足了企业级RAG的初步需求。一些特定的能力,并不好用。举例来说,RAGFlow对于全文搜索,分别采用了两种分词,然后做联合查询。为了支持这一点,数据不得不保存了三份:其一是原始数据,其二是采用策略一的分词,其三是采用策略二的分词。因为采用Elasticsearch,无法用两种分词对一个字段进行联合查询。这是很大的冗余;再比如:Elasticsearch的向量搜索能力,不够强大,不仅性能不足,而且内存占用高,向量定义受限(不支持各种向量类型,不支持单文档多向量等较为复杂的向量数据建模);再例如:Elasticsearch只能提供一些标准和通用的分词和排序,例如RAGFlow并没有用Elasticsearh内置的分词,而是采用Python实现,这种方式固然灵活,但在算法固定后,很容易受到效率的挑战。这些组件,都应该根据实际应用的效果,把能力都下沉到数据库中;再例如:Elasticsearch是一款采用Java实现的基础组件,这跟以Python为主的AI社区,搭配非常不便。当前的Infinity,甚至已经提供了嵌入式的版本,开发者可以直接pip install安装Infinity,这对于各种端侧场景,非常必要。

其二、Infinity除了全文搜索和向量搜索,还包含了其他两类搜索方式,一种是稀疏向量,一种是张量。前者同样是针对RAG的一种有效搜索方式,后者的意义,可以看我们之前写的一篇文章【参考文献3】。简单总结一下,就是基于张量的重排序,不仅可以让数据库具备等同于重排序模型一样的能力,并且由于性能的大大提升,可以在更大的范围内做重排序,这大大提升了最终的召回效果,它的意义,甚至要大于前者。更加重要的是,只有引入张量,我们才能真正提供多模态RAG,这会在本文的第四部分会进一步谈及。

其三、Agent需要管理记忆体,记忆体保存的数据,包含对话历史,行为轨迹,文档数据,等等。记忆体数据是非常灵活多样的,它们既需要被搜索,也需要被管理(包括各种过滤分组点查询)。事实上,OpenAI收购Rockset的另一层考虑,除了混合搜索之外,还在于它schemaless的访问能力,这种能力对于高性能查询多样化的记忆数据非常有价值。Agent的记忆体还是个不断迭代的事物,我们需要让Infra随时跟进这种变化。

其四、来自知识图谱等的需求,它未必需要一个完整的图数据库能力,但却需要必备的图计算能力,例如子图检索和删除,这些能力是多样化的。我们同样需要让Infra随时跟进这种由文档数据预处理带来的各种变化。

其五、来自各种联合查询的需求。根据社区的反馈,RAGFlow已经把Text2SQL加了进来。也就是说,针对非结构化数据和结构化数据的联合访问需求,已经开始出现。诚然,当前Text2SQL是可以连接其他的关系型数据库,但当用户在一个知识库当中上传了大量数据,既包含PDF/Word,也包含Excel,他既需要对Excel做分析,还需要让Excel和其他文档一起提供对话能力,并且包含对Excel的计算结果。因此,一个知识库,可能会涉及到几百张表,每个Excel都是一张表,同时它还需要跟其他文档一起被搜索。这样的需求,想起来就挺复杂的,而且也同样来自社区用户的反馈。

在Infintiy的最新0.4版本中,基本已经实现了RAGFlow用到的Elasticsearch的那些能力,我们将很快把Infinity放到RAGFlow中,它将首先会作为备选方案存在,在经过一段时期后,会作为首选。因此,Infinity跟RAGFlow是共生的关系,它既能帮助RAGFlow解锁新的场景,又能根据RAGFlow开源遇到的新情况,把需要的能力下沉到数据库,解决效率和可用性的问题。

以上,我们谈论了RAG 2.0在RAGFlow的实现情况,也对RAGFlow下边的一些工作进行了总结。可以看到,RAG 2.0是一个非常复杂的平台,它是一个Infra和各种模型协同工作的平台。这里的模型,包含来自数据抽取的文档解析模型,也包含各种知识图谱、命名体抽取模型,还包含Embedding和排序模型,更包含未来的多模态模型。这些模型,有的来自我们自身,有的来自开源,有的需要微调,有的则是从零开始训练。如何让这样的复杂系统协同工作,这需要一个标准化的平台,这越来越离不开核心引擎的持续建设,这也正是我们开源开放RAGFlow并持续迭代的根本原因。因此,RAGFlow并不是依靠某个独门秘籍来吸引社区,而是依靠正确的架构和演进方向,最终把这样的RAG系统变成一个普适性的平台。

三、关于Agent

RAGFlow在7月的时候推出了Agent功能。自从大模型火热以来,软件生态层面,Agent的概念比RAG更普及,与此同时,还有各种流行的LLMOps软件提供了工作流功能,它们也同时得到了大量用户的喜好,那么这些概念,究竟有什么区别和联系呢?

工作流并不是一个新概念,它的历史跟企业信息系统几乎一样长。而工作流跟大模型的结合,引发了对企业软件生态层面的重塑。工作流,本质上可以看作是以指令驱动数据流的系统,例如在大数据平台中,工作流可以体现为ETL数据管道;在RPA平台中,工作流可以体现为各种数据抓取和数据规则填充的配置和定义平台;在各类无代码和低代码平台中,工作流体现为对于各业务场景规则的定义和Knowhow。当结合大模型之后,工作流可以解锁的场景就很多了,因为它解决的是保证数据和指令以可控的方式流动的问题,而大模型则不仅可以参与到指令和数据的流动过程,还可以作为指令的发起者,因此这让工作流可以以更加自动化和智能化的方式来执行。举例来说,定义一个工作流,让大模型以可控的方式,按照模板来生成固定格式的企业文档;定义一个工作流,让大模型按照业务事先定义的场景,来引导用户提问的范围;定义一个工作流,让大模型根据内容来判断,是否符合要求从而触发下一步的行为;定义一个工作流,让从信息系统获取到的销售线索,以符合业务定义的方式触发外呼系统并管理外呼内容;等等,由于大模型可以像人一样产生各种判断,因此它赋予了工作流定义以生命。

RAG跟工作流的关系在于,它是工作流环节的一环,大多数工作流,都会需要RAG参与其中。在这个过程中,大模型的角色,除了RAG必备的内容生成,还有一个关键环节——作为决策的发起者。例如工作流中的意图判断,或者更简单来定义,就是分类器。通过让大模型来判断提问,或者生成的内容的分类,来决定下一步的数据和指令如何流转。这在问答,客服,外呼,文案生成,合规检查,等等场景都是必不可少的环节。

Agent从开始被提出,更多被赋予自主决策的角色。所以它常常伴随这些字眼:记忆管理——代表Agent交互过程的上下文信息。过去的数月里,一个相对轻量级的项目【参考文献4】,只是定义了这些记忆管理的API,或者说就是如何来存放对话上下文信息的接口,就获得大量关注,因此,Agent天然就是自带流量和关注的;决策和Reasoning能力——代表Agent和大模型之间,Agent和Agent之间,采用什么策略让提问更加有目标,驱动大模型给出最终答案。这个角度来看,Agent跟它的定义起源——强化学习有着密不可分的联系。吴恩达给出了四种 Agent 模式:分别是反思、工具、规划、以及多 Agent 协同。反思可以跟RAG产生联系,例如通过反思机制,让大模型来判断RAG搜索的质量,并改写查询进一步搜索,最终提升RAG答案生成的质量。工具和规划则跟工作流有着密切的联系,我们甚至可以说,工作流就是Agent的一部分,因此在RAGFlow当中,我们把Agent和工作流看做一回事,当然这并不影响在其他产品中把两者分开定义。 至于多Agent,通常用于角色扮演,这在行业应用中还处于较早期阶段,OpenAI近期开源用于实验性的swarm【参考文献5】,就是个多Agent框架。

在当前的AI应用生态中,场景最多的,都是工作流类应用。而带有记忆管理,和辅助决策的Agent,会在医疗、金融、法律、游戏、推荐系统等领域有深入应用。因此,把记忆管理纳入RAGFlow,也是接下来的工作。站在RAGFlow的视角,在Agent这件事情上,RAGFlow的定位从来都很清晰,RAG作为一个核心技术组件,它要解决的问题是RAGFlow的核心。如何使用RAG,这就是Agent层面的事情,可以把RAGFlow当作一个App Store那样来使用这个市场里的各种App(Agent),也可以采用外部的Agent/工作流工具来编排RAGFlow,这一切取决于用户自己的方便程度。

四、关于多模态

多模态的定义其实并没有统一标准。当前的一些大模型,已经普遍具有了一些多模态能力,例如给定图片,它们可以产生对应的文字描述信息,因此,利用这些描述信息建立文本索引,就可以实现一种简易的多模态RAG,这在当下的RAGFlow就已经提供。

更广义来看,RAGFlow的DeepDoc组件,它本质上就是来解决多模态数据的一种通用范式,因为企业内的非结构化文档,如下图所示,本质上就是一大类多模态文档,如何解锁这些内容的商业价值,本身就是RAG的一大类应用场景。

所以,采用深度文档理解模型,或者说广义意义上的OCR 2.0,将这些文档变成不损失语义信息的文字,是应对这样的多模态文档的一种标准解决方案。

另一种方案,是直接借助于VLM(Vision Language Models)视觉语言模型。今年大模型的进展,在VLM上尤其突出,参见下图,VLM的能力,已经从早期的以图搜图,进展到了理解图片本身的语义信息。

以Google开源的PaliGemma【参考文献6】为例,我们可以看到,它已经可以对文档内的图片,进行深度解读,这只是一个3B的VLM模型,就可以做到如此效果:

而在近期公开的ColPali【参考文献7】,则是把PaliGemma用于多模态RAG的里程碑工作,借助于Tensor和延迟交互模型,解锁下边的场景,已经不是未来,而是当下——把来自企业的各种多模态PDF,采用ColPali或者其他延迟交互模型,生成Tensor,然后用Infinity数据库基于这些Tensor做召回,得到的结果交给具备VLM能力的大模型,就可以得到内容包含在多模态数据内的答案。

这条路线,跟RAGFlow当前的DeepDoc,有什么关系呢?可以参见下图:

我们可以采用传统的目标检测,来把多模态文档转成文字,也可以采用广义的OCR 2.0,这种基于Encoder-Decoder架构的Transformer网络,来更好的把多模态文档转成文字。而基于VLM的多模态RAG,它们只是用这种类似的架构,没有Decode生成文本的步骤,而是直接生成图像(Patch)的Embedding和Tensor。从技术上来说,这两种并无绝对的优劣之分,但在一定周期内,都存在各自表现更好的场景。而RAGFlow,则会同时支持这两种使用场景——这也是为何我们需要尽快把Infinity集成到RAGFlow的源动力之一,挖掘企业内部海量非结构化文档的商业价值,从现在起,已经不是未来,而是当下。

2024年在开年的时候曾被称作是大模型落地和RAG的元年。站在接近年底的时候回顾2024,不论是技术论坛的火热程度,还是各种媒体技术文章,都印证了这一点。RAG技术,在争议不断中持续进步,它始终都是大模型落地的标准架构。在当下,几乎所有人都已经认识到了RAG想要满足业务需求,是多么不容易做到,它不得不依赖各种定制(技术定制而非业务定制),按下葫芦浮起瓢,在特定的场景首先用起来。而RAGFlow始终在坚持走标准化建设的路线,走Infra和模型紧密交互的路线,坚持开源,而社区也用2万星标体现了这样的坚持。来自社区的反馈,不论是技术还是场景,都构成RAGFlow前进的动力。我们看到,大量的用户对于RAG,都已经从观望走向实践,不论是大型企业,还是中小用户,甚至政府部门,用户对于RAG的熟悉和认知让我们惊讶,对于场景的理解和应用边界的拓展,都大大超出了我们在7个月前开源时所认知的范围。2万星标,对于RAGFlow来说,只是迈出的一小步,大量需要改进和完善的特性都排成了长队,未来的迭代,从以上文字中,也可以看到我们的后续规划。欢迎大家持续关注RAGFlow:https://github.com/infiniflow/ragflow

参考文献

  1. https://www.jiqizhixin.com/articles/2024-07-08-5

  2. General ocr theory: Towards ocr-2.0 via a unified end-to-end model. https://arxiv.org/abs/2409.01704

  3. https://www.jiqizhixin.com/articles/2024-08-05-2

  4. https://github.com/mem0ai/mem0

  5. https://github.com/openai/swarm

  6. https://github.com/google-research/big_vision/tree/main/big_vision/configs/proj/paligemma

  7. ColPali: Efficient Document Retrieval with Vision Language Models. https://arxiv.org/abs/2407.01449

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.rhkb.cn/news/456185.html

如若内容造成侵权/违法违规/事实不符,请联系长河编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

排查PHP服务器CPU占用率高的问题

排查PHP服务器CPU占用率高的问题通常可以通过以下步骤进行: 使用top或htop命令:这些命令可以实时显示服务器上各个进程的CPU和内存使用情况。找到CPU使用率高的进程。 查看进程日志:如果PHP-FPM或Apache等服务器进程的日志记录了具体的请求…

2005至2023年中国各地区数据要素化水平-最新出炉 附下载链接

中国各地区数据要素化水平(2005-2023年)概览 下载链接-点它👉👉👉:2005至2023年中国各地区数据要素化水平-最新出炉.zip 一、数据背景与意义 在数字经济和数字技术持续发展的浪潮中,数据已逐…

php命令执行的一些执行函数----以ctfshow靶场为解题思路

解法10、利用文件包含 ①?cinclude$_GET[1]?>&1data://text/plain,<?php system(tac flag.php);?> cdata://text/plain;base64,PD9waHAgc3lzdGVtKCdjYXQgZmxhZy5waHAnKTs/Pg ②?cinclude$_GET[1]?>&1php://filter/readconvert.base64-encode/resourc…

在Java中,需要每120分钟刷新一次的`assetoken`,并且你想使用Redis作为缓存来存储和管理这个令牌

学习总结 1、掌握 JAVA入门到进阶知识(持续写作中……&#xff09; 2、学会Oracle数据库入门到入土用法(创作中……&#xff09; 3、手把手教你开发炫酷的vbs脚本制作(完善中……&#xff09; 4、牛逼哄哄的 IDEA编程利器技巧(编写中……&#xff09; 5、面经吐血整理的 面试技…

k8s部署使用有状态服务statefulset部署eureka集群,需登录认证

一、构建eureka集群镜像 1、编写dockerfile文件&#xff0c;此处基础镜像为arm版本&#xff0c;eureka目录中文件内容&#xff1a;application-dev.yml、Dockerfile、eureka-server-1.0-SNAPSHOT.jar(添加登录认证模块&#xff0c;文章最后附上下载连接) FROM mdsol/java8-j…

Vue入门示例

今天滴学习目标&#xff01;&#xff01;&#xff01; 示例简介HTML内容主体区域输入框列表区域统计和清空 JS引入Vue.js库定义Vue实例el选项data选项methods选项 示例简介 HTML内容 本次实例讲解的是v-for、v-on、v-model来写这小小的实例&#xff0c;下面是实例的效果图&am…

OQE-OPTICAL AND QUANTUM ELECTRONICS

文章目录 一、征稿简介二、重要信息三、服务简述四、投稿须知五、联系咨询 一、征稿简介 二、重要信息 期刊官网&#xff1a;https://ais.cn/u/3eEJNv 三、服务简述 四、投稿须知 1.在线投稿&#xff1a;由艾思科蓝支持在线投稿&#xff0c;请将文章全文投稿至艾思科蓝投稿系…

国家能源集团携手海康威视研发攻克融合光谱煤质快检技术

10月24日&#xff0c;在国家能源集团准能集团黑岱沟露天煤矿&#xff0c;安装于准能选煤厂785商品煤胶带机中部的煤质快检核心设备&#xff0c;正在对当天装车外运的商品煤煤质进行实时检测。仅两分钟后&#xff0c;涵盖发热量、水分、灰分、硫分等多项指标的数据信息已传输到到…

在xml 中 不等式 做转义处理的问题

对于这种要做转义处理&#xff0c;<![CDATA[ < ]]>

LeetCode_509. 斐波那契数_java

1、题目 509. 斐波那契数https://leetcode.cn/problems/fibonacci-number/ 斐波那契数 &#xff08;通常用 F(n) 表示&#xff09;形成的序列称为 斐波那契数列 。该数列由 0 和 1 开始&#xff0c;后面的每一项数字都是前面两项数字的和。也就是&#xff1a; F(0) 0&#…

Discuz 论坛开发一套传奇发布站与传奇开服表

Discuz 论坛开发一套传奇发布站与传奇开服表 随着互联网技术的飞速发展&#xff0c;网络游戏已成为人们休闲娱乐的重要方式之一。在众多网络游戏中&#xff0c;传奇系列以其独特的魅力吸引了大量忠实玩家。为了满足这些玩家的需求&#xff0c;并促进游戏信息的交流与分享&…

密码学原理

1.1 加密算法 Tags: 1、加密算法分类 2、对称算法 <原理、特征、算法> 3、非对称算法 <原理、特征、算法> 4、对称算法vs非对称算法 <结合体> 1、加密算法概述&#xff1a; 用于对用户数据进行加密&#xff0c;常用算法有DES、3DES、AES、RSA、DH算法。根据密…

合约门合同全生命周期管理系统:企业合同管理的数字化转型之道

合约门合同全生命周期管理系统&#xff1a;企业合同管理的数字化转型之道 1. 引言 在现代企业中&#xff0c;合同管理已经不再是简单的文件存储和审批流程&#xff0c;而是企业合规性、风险管理和业务流程的关键环节之一。随着企业规模的扩大和合同数量的增加&#xff0c;传统…

Linux下MySQL8.x的编译安装与使用

Linux下MySQL的安装与配置 1. 安装环境初始化 1.1 查看是否安装过MySQL 如果使用rpm安装, 检查一下RPM PACKAGE rpm -qa | grep -i mysql # -i 忽略大小写 # 或者 yum list installed | grep mysql如果存在mysql-libs的旧版本包&#xff0c;显示如下 #存在 [rootlocalhost ~]…

NavMesh只制作可移动的导航网,清除多余不可走区域

只制作可移动的导航网。它使存储文件大小减小并提高性能。它消除了迁移到随机区域的问题。添加链接描述 1.如何使用 2.创建一个包含“NavMeshCleaner”组件的对象。Andadd指向可定制区域。 按住控制键并单击添加点。如果要移动它&#xff0c;请按 输入上的control键并单击。您…

信息安全工程师(55)网络安全漏洞概述

一、定义 网络安全漏洞&#xff0c;又称为脆弱性&#xff0c;是网络安全信息系统中与安全策略相冲突的缺陷&#xff0c;这种缺陷也称为安全隐患。漏洞可能导致机密性受损、完整性破坏、可用性降低、抗抵赖性缺失、可控性下降、真实性不保等问题。 二、分类 网络安全漏洞可以根据…

桥接模式,外界与主机通,与虚拟机不通

一 二 在此选择Windows与外界连接的网卡&#xff0c;通过有线连就选有线网卡&#xff0c;通过无线连就选无线网卡。 三 如果需要设置固定IP&#xff0c;则选择"Manual"进行设置。我这边根据实际需要&#xff0c;走无线的时候用DHCP&#xff0c;走有线的时候设固定IP…

C#中的委托、匿名方法、Lambda、Action和Func

委托 委托概述 委托是存有对某个方法的引用的一种引用类型变量。定义方法的类型&#xff0c;可以把一个方法当作另一方法的参数。所有的委托&#xff08;Delegate&#xff09;都派生自 System.Delegate 类。委托声明决定了可由该委托引用的方法。 # 声明委托类型 委托类型声…

Golang | Leetcode Golang题解之第507题完美数

题目&#xff1a; 题解&#xff1a; func checkPerfectNumber(num int) bool {if num 1 {return false}sum : 1for d : 2; d*d < num; d {if num%d 0 {sum dif d*d < num {sum num / d}}}return sum num }

一文掌握Kubernates核心组件,构建智能容器管理集群

1.Kubernates简要概述 Kubernates&#xff08;常称为K8s&#xff0c;因省略了“ubernate”中的8个字符&#xff09;是Google开源的容器编排平台&#xff0c;专为简化和自动化应用服务的部署、扩展和管理而设计。它将应用与底层的服务器抽象开来&#xff0c;提供了自动化的机制…