一、幻觉
本次分享Fast GPT的产品形态，以及设计的理念。首先介绍整个项目的背景，大模型的优势在于知识面广，泛化能力强，甚至可以理解一些复杂的问题。但是目前模型的架构，本质上基于概率进行推测，所以无法保证百分百的稳定，即它输出的结果不是很稳定，在使用大模型的时候，发现大模型经常会说的有理有据，甚至在处理一些数学的推理问题的时候，已经给出正确的推理逻辑，但是并没有给出一个正确的结果，这就是幻觉。并且由于大模型是比较顽固的，它不像人一样可以快速的纠正错误，所以幻觉将会是阻碍大模型落地的重要因素，并且在未来无法从根本性上解决。
与大模型的不稳定与幻觉相反的是稳定可靠。在日常完成一个任务的时候，通常会制定很多的规则或者规章制度引导不同的执行者，让他们更加准确高效的完成任务,通常把这些规则就称为工作流，特点是在不同的环境下得到相同的输出，缺点是不够灵活，泛化能力差，通识性比较差。比如右边这张图，用户本质上是想问a商品的价格问题，但是传统的系统有可能因为换了方式，或者换一个语言提问，就无法找到一个正确的答案，所以Fast GPT结合AI的理解和扩散能力，以及结合工作流的强逻辑和精准的能力，从而更好的帮助开发者构建一个稳定可靠的AI应用。
二、Fast GPT介绍
接下来看Fast GPT项目的大体内容。首先这是整体的结构，核心就是通过工作流和知识库构建AI应用的逻辑核心和数据核心，通过API或者分享链接等形式接入到具体的业务场景里。重点是三部分，首先是工作流，广泛称为工作台,工作流是工作台的一部分，之后加入像提示的模板和长期记忆的功能。
第二部分是知识库，最后是AI聚合，也就是AI网关。首先工作流一共分成三种模式，分别是简易模式 对话模式 插件模式。简易模式就是对话模式的一种表单的封装，它的目的是希望用户可以快速的上手体验整个项目，对话模式和插件模式可以把它类比为两类函数，Chat函数就会有固定的输入和输出，它固定的输入可能就是用户的问题，用户上传的文件,比如用户的ID信息作为固定输入，Plugin函数可以允许用户自定义输入和输出,两类函数可以相互的嵌套使用，从而形成一个工作流的复用，用户其实就是一个Main函数，它只需要指定其中一个函数作为入口，即可运行整个工作流。工作流的形式是代码可视化的形式。
作为一个产品形态,借鉴的是流程图的图形语言，希望做到不需要和用户约定任何的一个规则，用户只要看到这个图，就知道整个流程是如何运行的。就像这张图里面,用户只需要知道这是一个判断器，根据它后面的两条线路以及它的一个箭头走向，就可以知道整个工作流如何进行运行的。比如分支合并的例子，它整体上跟流程图是差不多的，但是它会多出一个节点，这是因为流程图展示的只是一个流程如何运行的，它并没有展示整个工作流的数据是如何传递的，所以为更简化数据传递，所以引入一些额外的节点。
第三个特点是它支持并行执行，并行执行主要是提高整个工作流的运行效率，并且通过精确的流程控制，可以保证整个输出的结果，像这张图是一个图文并行生成的逻辑，并且可以保证不管是图片先生成完毕，还是文本先生成完毕，最终用户得到的输出都是文本，一段等待的提示词，最后是一个图片，最后一个特点就是递归执行，递归执行在构建一个复杂Agent的时候会非常的重要，比如像Auto GPT本质上其实就是先要模型做一个plan，然后逐一的执行计划。
最后拿到计划的执行结果，进行一个Check，Check的结果可以简单的分为就是结束整个流程，或者是调整对应的参数，再重新的做计划，所以它本质上就是由做计划，然后执行计划，还有检查完成的流程，所以这种场景用递归实现就非常的合适，引入递归会提高整个复系统的复杂度，同时会引入一些安全风险，所以也花了大量的时间做安全的风控，避免用户错误的操作导致整个系统的崩溃。期望用户可以像画流程图一样，构建一个AI应用，第二部分就是一个大模型数据核心,是一个知识库，Fast GPT的知识库一共会分成四层，在知识库下面会有很多集合，这个集合可以是你的文件 网站,集合下面会有很多的数据块，由于嵌入模型长度和精度的限制，无法一次性的存储很长的一个数据，所以需要对数据进行一个分块，在数据下面还会有很多的索引，目的就是弥补向量模型的精度问题，另外一个目的是进行数据的标注，可以通过增加索引或者改变索引提高数据块在检索时候的综合的排名情况，在数据预处理上面，目前Fast GPT支持的是本地文件，还有web链接可以同步网站上面的一些数据，还会支持用户私有的文件库，比如阿里云的对象存储之类的。当然也可以通过APR的形式把数据导进来，在数据的一个原数据的解析，还有分块策略上面,除了可以使用内置的解析和分块策略以外，后续还将陆续的允许用户自定义自己的解析服务和分块服务,主要是因为发现通用的方法在一些个性化的数据上面处理的不是很好，但是有可能因为这些数据处理的不好，导致用户就不用的系统，所以允许用户进行一个自定义的服务的拓展。
在召回层面,目前基本上也会支持lag主流的一些策略，比如像语义检索，全文检索，混合检索重排，一些基本的过滤问题,问题优化有两个功能，其中一个就是解决用户在连续对话的时候指代对象不明确的问题，第二个是可以拓展用户原问题语义，从而提高整个在向量检索的时候的精度。指代对象不明确,比如用户的问题缺少主语，它不适合作为一个检索词，这时候就可以通过问题优化的形式把问题优化 ,就可以得到一个相对准确的答案，第三个就是AI聚合，也就是AI网关，AI聚合是网关里面其中一个比较重要的内容，在Fast GPT中，不管工作流是知识库，都会用到大量不同类型的模型，比如Rorank STT TTS,后面还会用到一些布局识别OCR，还有语义分块的模型，作为一个开发工具，还要允许用户使用不同服务商的模型，所以引入一个AI网关层，它的一个核心的功能就是帮助屏蔽不同服务商API的差异化，除了屏蔽基础的API差异化以外，Higress 还提供一个非常重要的功能，比如function call有dragon模式，是在Open AI模型里面都会适用的，但是在一些career模型或者其他服务商的模型，它不支持这种模式，如果没有网关，就需要在应用层里面对不同的模型进行适配，有Higress之后，都可以支持一个dressing模式和方声控，这是一个非常重要的功能，除了简化整个模型的一个接入以外，Higress还会提供非常重要的功能啊。
首先是负载均衡，比如Higress会自动帮选择一个上游相对空闲渠道调用，自动的进行同事和重连，只需要关心和Higress之间的稳定性。同时比如一个模型上游的渠道全部都崩溃，这时候它可以选择一个兜底的模型调用,不至于整个系统都会崩溃。第二点是一个多环境的共享，把整个聚合的能力直接做到Fast GPT里面去，但是发现有一个非常复杂的问题，比如说在生产环境里面配置十几个服务商的API，在测试环境和开发环境时下面又需要重新的配置一遍，就是非常麻烦。另外一个问题是多租户的问题，比如有一个同学进来，我不可能把我十几个API都交给他，就是非常不安全的，所以有AI网关之后，就可以让所有的环境、所有的人统一的集中调用一个AI网关,在网关上面对他们进行额度的分配，还有一些限流，第三点是更灵活的更新，以及更灵活的资源分配，比如新增服务商的模型，这时候就可以通过Higress提供一个模型插拔的能力，直接更新Higress的配置。并且Higress还会允许在不更新不重启主服务，不断调流量的情况下完全承载它的配置。同时像网关观众服务它的特点就是一个流量消耗型，CPU和内存一般消耗比较少，可以根据特点在有限的资源的情况下，进行更加合理的分配，从而提高整个资源的利用率。除了上面提到的几个特点以外，Higress还会提供非常多的一些AI功能，比如像大模型的缓存，提示词的修饰，内容审核，非常关键的就是可观测性，因为所有的AI访问流量都会经过到Higress，应用系统可以直接从Higress拿到可观测的数据，后期也可以基于Higress做模型评估的功能，不需要在应用层再进行单独的买点。
三、工作流节点介绍
下一步介绍工作流的内用。比如有最基础的节点，就是知识库搜索，主要就是配合知识库管理，可以让用户直接选择知识库，配置一些参数就可以进行检索，不需要关心中间复杂的过程。第二个就是http。基本上是目前每一个可视化工作流应用都必备的节点，因为它是工作流与外部数据交互的核心。
第二类节点是AI节点，除了常见的文本生成以外，还会封装像问题分类或者意图识别的节点，它就是让模型分析用户的意图，从而动态的选择一个分支进行执行。比问题分类更进一步的是工具调用，或者叫智能调用的节点，它的实现主要是要借助大模型的函数调用或者react的能力。它不仅可以有问题分类的功能，还可以为目标节点生成可执行的参数。比如有一个函数是预约会议室，它需要输一个参数叫做楼层，当用户输入的内容里面包含预约的一个语义的时候，它就会尝试调用这个函数，发现这个函数缺少一个参数，它就会提示用户，需要输入要预约几楼才能执行函数,再举个例子，像GPT的一个小助手，它会调有两个知识库，其中一个是手动标注的知识库，另一个是官方文档，可以要求模型先检索手动标注的一个知识库，会让它以更相对严格的条件检索，如果检索到就可以直接回答，如果没有检索到，它就进行一个二次的检索，去一个更广泛的文档里面检索相关的内容。上面两个例子，用自然语言表达它的流程非常简单，但是如果要用传统的流程实现会有点麻烦，需要做大量的内容提取工作,才能实现动态的判断，但是有工具调用就可以一步到位，直接实现功能。
第三类节点是交互节点，在一般的工作流里面，用户输入一个内容或者发送一个消息的时候，整个工作流就会从头到尾执行一遍。但其实有些时候希望用户介入工作流，这时候就可以使用到交互的一个节点，比如可以让用户选择其中一条分支进行执行，或者让用户输入一些合适的内容之后再往下去执行。这些本质上都可以让AI实现，比如可以让AI通过问题分类的形式代替用户的选择，通过内容提取的形式代替用户的表单输入，从过去一年使用的体验来说，不管是从精度上面，还是整个编排的复杂度，或者是用户使用的交互复杂度上,还有模型的成本，这种传统的交互方式会更加舒服一点。
四、Fast GPT实践案例
最后讲实际的使用案例，比如这是一个私人的助手，大概有七八个小助手，其中一个助手的任务就是每天早上九点钟对我三个邮箱的内容进行总结，汇总提取出一些重要的信息，还有商务的信息。这个场景适合国内的大部分用户，因为一般都习惯看短信，不看邮件，邮件比较杂会遗漏一些重要的内容,实现并不复杂,首先需要获取邮件的数据，丢改模型，通过web hold的形式，推送到对应的内容。最后结合FastGPT的定时执行器实现。从这个例子感受到有时候chat的模式并不是最佳的，如果你是每天早上主动的去这个模型，你的用户体验就不是很好。
第二个案例是之前运营同学发了一个小红书，主要是黑神话悟空的图文生成，主要是输入黑神话悟空里面经典的语录，让模型进行扩写生成小文章，同时会调用一下最近比较热门的绘图模型绘制一个封面图，同时调用一个封面图优化的服务，让它变成一个更加炫酷封面图。
最后一个例子是开发同学之前写官方文档的时候非常的头疼，特别是有图片的时候，首先需要截图，把这个图片下载到本地,需要复制图片的名字，图片名字复制到之后，填到官方文档里面，并且要按markdown的格式进行编写，在写完整个文档之后，还需要把文档丢给GPT，进行一个总结生成摘要，复制回文档里面，最后上传之前要进行图片的压缩，整个流程就非常的繁琐，导致很多开发同学就不太愿意写这个文档，现在流程就是利用在线文档非常便捷优势，直接截图粘贴到飞书文档上面去，在分析文档上面来，写完文档之后，直接把整个的流程复制，整个链接复制到工作流，工作流就会自动进行图片压缩，然后进行总结，并且按官方文档的流程进行输出,要做的复制文本到本地，以及把文件下载到本地上传文档。最后一步可以直接让工作流向仓库提一个PR，也不需要手动的进行复制。
通过上面三个例子，可以发现在一个工作流实际落地的过程中，都需要大量的获取外部的数据，或者是向外部进行数据的推送，通过写代码的形式实现的，但是最后又会引入了另外一个问题,就是传统的低代码不是很好用，就是因为它需要写代码，它无法让一个非技术的人员独立的完成复杂流程编写,为了非技术人员用起来也比较的爽，有一个服务就是Fast，准确叫做云函数，云函数的优势跟劣势也非常明显，如果想用云函数实现非常复杂庞大的系统，它不是很好用，它的一些功能会有限制，另外一个是它的可读性结构性没有传统的框架好用。但是如果只是用它来做一些测试，用例，demo，做一些小的项目，发现非常香。所以引入Fast GPT加到工作流里面，从而简化用户在获取外部数据的时候写代码的问题，但是云函数只是简化写代码,并没有解决写代码的问题，所以还需要另外一个工具来帮助完成最后一步,就Copilot,它的缺点非常明显,就是在使用Copilot的时候发现拿来补全和代码仿写的时候会非常的好用，但是尝试跨多个文件写的时候，或者甚至想让它架构整个项目的时候，发现非常的困难，但是非常巧合的是，在这个场景下不需要Copilot 架构整个代码，只需要它写一个可以运行的函数，可以拿到正确的结果，它只要能给正确的答案。所以在的场景下，使用Copilot+Fast结合到工作流里面，会发现整个的开发的链路会变得非常的轻松。
首先因为AI的幻觉的不稳定性，引入工作流，借鉴工作流的强逻辑和稳定性，希望让AI更加的可控，但是在引入工作流的过程中，特指的是低代码的工作流，在这个过程中，它又会把低代码的缺陷给引进来，如果想要把低代码的工作流用好，就是都需要写一点代码，为了解决这个问题引入Fast或者云函数，让写代码的过程变得更加的轻松。最后再引入Copilot，帮助非技术的人员完成写代码的任务,就可以非常巧妙的实现无代码编排的情况。目前已经有工作流和fast，因为有另外一个产品也是一个云函数的产品，下一阶段就要定制Copilot，让它在特定的环境下更好的帮助用户自动的编写代码，最后需要把整个的交互逻辑做融洽，就让用户体验起来不割裂，因为现在需要让用户去三个平台上面完成工作，后面的目标就是让用户可以在一个平台上面就完成自动编排整个工作流。最后工作流会内部的构建形成逻辑核心，接入到的应用，这就是整个FastGPT低代码的工作流的解决方案。
最后一个例子就是把FastGPT接入到另外一个产品的工单里面，它主要会有四个功能，首先它会同步产品的文档作为回答的依据。另外它会有个自动转人工的功能，当它识别到模型无法回答问题，或者是用户连续三四轮重复问问题的时候，模型出现幻觉无法解决用户的问题，这时候就及时的给人工发送一条消息，让他及时的介入，第三个就是工单总结的东西，当运维人员关闭工单的时候，它会给工单进行总结，会把它录入到知识库里面，从而完善整个产品的一个知识库，最后一个功能是定时执行，它会每天每周的抓取工单的信息，从中提炼出一些用户问的相同的或者相似的问题，反馈给产品，相当于是给产品发周报，目的是及时的发现产品里面一些不恰当的地方，因为用户如果重复问一个问题，很多用户都问到同一个问题的时候，其实大概率就是产品设计的问题，有可能是交互上面不太好，提示上面不好或者文档不全，甚至是有bug之类的，有一个自动发出报的助手，就可以让产品非常的轻松，不需要每天都扫很多工单进行总结。
