内容介绍：
一、rag诞生的背景
二、在落地的时候遇到的各种各样的差异化需求，以及如何来满足这些需求
三、多模态多语言rag技术的研发和应用
四、关于多模态多元embedding和rank模型
五、基于千问大模型训练embedding和rank模型最重要的几个模块
六、在开源社区推出的GT千问系列的模型
七、在模型应用相关的技术实践上的可运营
八、关于AI运营实践
本次分享的主题是开放应用架构，建设全新可精细化运营的百炼，由阿里云智能集团飞天实验室科学家赵中州、通义实验室科学家龙定坤和丁瑞雪，以及阿里云智能集团高级运营专家吴倩分享。
今天将为大家介绍在过去一年以来，百炼rag应用落地所遇到的挑战，以及解决方案。今天会先给大家介绍rag相关的背景，以及在项目落地时遇到的挑战。这些挑战主要包括数据源治理，即复杂文档的理解，以及用户的差异化内化需求如何满足。最后是如何评估rag系统，以及如何迭代优化。
一、rag诞生的背景
rag技术出现主要源于大模型本质上的缺陷，共总结为三个类型。
1.缺陷
第一个是大模型固有的幻觉问题。即当我们问他一些他并不知道的知识的时候，他会瞎答或者胡编乱造。这里一个非常典型的例子，即在问一些时效性的问题。比如今天天气怎么样，而这个在大模型的训练过程中肯定是没有见到的，因为他肯定不是在今天训练好的。这时大模型一般会胡编乱造一些答案。那么就需要通过rag技术为他补充一些时效性的知识，让他能够正确的回答这些问题。
第二个问题是长尾知识的问题。因为大模型本质上是概率模型，对于他见得多的数据掌握的就比较好。那么他见的比较少的知识，即肠胃的知识，他回答的就不太好，或者甚至是他都见过，但是忘了。比如我问他一个雪板的具体型号，或它的板腰长度是多少，或者它的硬度是多少。对于这种非常垂类和小众的知识大模型，通常他都无法回答正确。
最后一个是知识受限的问题。因为现在的大模型基本上都是基于一些公开域的知识进行训练的。但在实际应用场景中，通常对一些私域的知识有诉求。比如作为一个公司内部的客服AI，员工问我入职三年了今年有多少天年假？这种企业私有知识，他是没办法在预训练阶段就借到的。所以对于这些私域知识，需要通过rag技术把它注入到整个大模型的知识体系中。因此为了解决这些问题，就出现了现在的rag技术。
2.rag链路
目前，屏幕上投的是一个最简单的rag链路。即针对需要注入的知识，把它整理成一个文档库。然后对这个文档库进行解析以及向量化，并把这些向量存储到一个向量引擎里面。这样当我们对rag系统进行提问的时候，可以使用这个问题在向量库里面检索出相应的文档片段。并将文档片段结合用户的问题一起输入给大模型，让大模型参考并给他整理出知识，再进行回答。
3.rag链路应用到具体的项目时遇到的问题
在将朴素的rag链路应用到具体的项目的时候，会发现遇到了很多问题，将这些问题分为三个方面。
第一个方面是数据的复杂性。即客户希望注入的知识有非常多的格式。包括PPTPDF、word、网页、markdown或多种的复杂文件类型。文件类型复杂就意味着知识的形式非常的复杂，从而也就增加了处理的难度。
第二个是多样化的需求，会发现一个简单的rag链路是没办法满足所有用户的需求。而用户除了简单的检索，然后加入到大模型，再到回答以外，其实他还有好多个知识库，他希望进行知识库的链路编排，或者希望能够限定大模型能回答什么，不能回答什么。另外一个是在不同的业务场景query类型也是不一样的。针对不同的用户提问也需要有不同的处理方式。
最后是效果保障问题，在实际项目中，用户对rag系统整体的准确率要求基本上都是95%到百分之百。但其实目前的正常的red系统，它的效果开箱即用基本上只能达到80%。
4.挑战
那么怎么样才能把系统的效果从80%提升到95%，甚至是100%呢？这也是我们在应用时遇到的非常大的挑战，接下来先从第一部分开始讲起，复杂文档的理解。可以看到，这是在实际项目中遇到的客户真实的复杂文档数据。
我们会有不同的文件类型，第一类比较典型是PPT。PPT不同于word PDF等可以以顺序理解它的文档。PPT其实有一个二维的空间理解顺序。比如屏幕上投的PPT可能看的不太清楚，但是能get到大家比如你从左往右理解，以S形的方式理解会相比你从上往下理解，它的阅读顺序是完全不一样的，一个不同的阅读顺序会导致一个完全不同的理解结果。正确的理解PPT的阅读顺序，对系统的回答效果影响非常大。
第二个是针对表格的数据，会发现现在一些开源的也好，闭源的也好。一些文档解析系统，它针对一些简单的二维表格已经能有比较好的处理效果了。但是一旦表格变得复杂，那什么是复杂呢？比如它有一个非常复杂的表头关系，它的表头有一些层级的关系，或者它中间没有划线，那么这个划线就影响到了他整个表格的分割，或者他整个表格存在一些表格的合并或跨页等问题。一旦这个表格开始变得复杂，会发现在主流的文档解析就会变得非常的糟糕。并会对后面的系统效果造成很大的影响。
最后一个是多模态数据的理解。在需要治理的文档中，会出现很多饼图、折线图、柱状图这种类似的图表。这些图表其实很难把它的信息完整的转化成文字。因此一个简单的朴素的rag链路，其实没办法很好的处理这类数据。为了应对这些挑战，目前主要结合了多种技术，包括混合的OSDR规则解析、离线real和在线real laid prompt等多种方案来解决复杂文档的理解问题。我们主要做的一件事情就是将多路的结果进行融合。
5.数据类型
接下来将需要处理的数据大概分成4种类型。第一种是最朴素的纯文本，第二种是PPT，第三种是表格，第四种是多模态的信息。那么针对不同的类型会有不同的处理方案。比如针对文本，会使用比较经典的OCR结合规则的解析，这样它能够拿到一个比较好的效果。那么针对PPT对于阅读数顺序要求比较高的数据，会使用离线的VO模型对它的阅读顺序进行一个比较好的理解。把它转换成markdown文档；对于表格，目前在尝试使用lt prompt的技术方案，对它进行一个更好的表征；最后针对多模态的数据，因为多模态数据不是能很好的完整的把它转换成文字。因此我们在尝试一个方案，即把它在离线的时候以图片的形式存储起来。然后在线的时候直接把这个图片跟随一些文本一起给到view模型进行推理回答。会发现对这种多种类型的数据进行多方式的处理，最后对这些多路解析结果进行融合之后，会对现有的rag链路系统的效果有一个比较大的提升。
二、在落地的时候遇到的各种各样的差异化需求，以及如何来满足这些需求
1. 例子
1.1.多智库
第一个需求是多智库，多知识库编排的需求在实际应用中，知识库它可以分为大致三种类型。
（1）知识库
第一种类型是互联网知识库，它是一个外部的知识库。
第二个类型是用户自有的多类型的业务知识库。
第三个种类型是它是一个固定SAMMA的FAQ知识库。
这三种知识库在实际中是非常典型的三种形式。
（2）诉求
那么用户对于这三种类型的知识库，他的诉求主要包括，第一是本地的知识库和互联网的知识库，在调用它的时候是否能够有一个优先级的配置。
第二个是FAQ库是否能有一个短路的机制，即我的问题一旦命中了FAQ库，能不能直接给出FAQ库的答案，而不是说再把FAQ的答案给到大模型。因为大模型有一定概率对他的答案进行编造。
第三个是业务被分成了好几种类型，不同的业务库的质量以及优先级是不一样的，我希望对这些业务库进行权重配置，这属于多智库、多知识库编排的需求。
1.2.回答范围限定的需求
第二个是回答范围限定的需求。rag系统的回答范围、知识范围可以分成三个方面。
（1）rag系统的回答范围和知识范围
一个是大模型自有的知识，第二个是用户的知识库的知识，第三个是来源于互联网的知识。
有一部分用户他希望大模型尽可能的尝试回答。那么这种情况就需要结合这三种不同的知识尽可能的回答。但是在对回答内容精准性要求比较高的场景，会发现用户希望这个大模型就只依据知识库里面的内容去回答，不要进行其他的发挥。想要实现这个功能，其实它依赖prompt是没办法很好的支持知识范围的限定，这主要由于本身大模型存在幻觉。第二它对于垂类的知识其实理解的不是很好。
第三点是本身基模在训练的时候，应该尽量的训练模型去回答问题，而不是训练他不回答问题。因此在这三种缺陷的加持下，光靠大模型的problem engineering是很难去解决的。
1.3.query
第三种类型的需求是在不同的客户场景，它的query实际上类型是非常不一样的。Query的类型不一样，对应到rag系统，那么它检索回来的知识的形式也是不一样的。比如对于知识点的问答，最好是给一些片段级的知识，并且是越精准越好。第二个是比如用户经常让他做一些总结摘要。在query类型下，尽量给一些outline或总结性的信息会更好一些。然后在长文档推理或者翻译的场景下，给全文并且比较完整的信息是更好的。因此不同的提问对应的信息所需要的密度类型是不一样的，而它的处理方式也是不一样的。
2.rag系统
为了解决这些多样化的需求，目前把rag系统整体上分成了搜前、搜中和搜后三个部分。针对这三个部分，目前在百练上提供了知识库编排的配置、回答范围的配置、意图的配置以及prompt组装的配置。支撑这些配置的主要是三个模块的能力，包括收钱的query意图分析、FAQ干预知识库路由以及query改写等。在搜中，支持多种搜索来源，比如用户自建的业务库、FAQ库以及互联网的来源。在SOHO目前提供层级片段组装的配置、prompt压缩相关性检测和融合搜索等多种模块，通过提供这多种配置，基本上能解决目前遇到的大部分客户的需求。
3.系统的评估与优化
客户在来到百之后，基本上都会用百炼rag模板，然后搭一个还过得去的demo。如果觉得还不错，就会开始想要落地。一开始落地会发现遇到很多bad case，然后客户就会来问我们说，给了query为什么回答还不对？这个问题反馈到我们，其实是需要有一个链路排查分析以及问题路由的定位的一套机制。即当用户给出了bad case之后，怎么样快速的定位到底是哪个环节出了问题。
在给予客户建议的时候。比如你哪里的配置可以调一调。到了这儿之后，用户就会问，你提供了这么多种配置，那对于我来讲什么样的配置才是最优的呢？这时涉及到系统级别的调优，那么就需要用户有一个评估级。在评估级的驱动下，来帮助选择最好的模块。还有很多用户会问，在没有人力也也没有物力的情况下没办法标注这些数据怎么办呢？而这个就涉及到了自动评估数据的生产问题。为了解决这些问题，在这一年的时间沉淀出了一套叫call rag的全链路自动的评估的框架。
4.rag系统的评估
rag系统的评估共有两个部分，一部分是说评一下检索的效果好不好。另一部分是标正确答案，并看一下生成的质量好不好。
5.rag系统的评估的问题
rag系统的评估共存在两方面的问题，一方面是传统的检索的效果评估，它依赖于正确答案即正确的trunk标注。一旦切换了创客的标注方式，或一旦修改了创客的，比如修改了唱歌的大小，或者对原数据进行了改动。那么之前标注的golden chunk就没办法用了。所以他在传统的检索方式，在新的rag系统中目前也没有非常多的应用起来。第二个是如果只评估最终生成的结果，其实是没办法定位到底是哪里出了问题，该怎么用。顶多能知道目前的系统大概是一个什么样子的水位。
为了解决这些问题，即core rag，提出了一个multi granular keywords的evaluating方法。这个方法能够针对rag系统的全链路，包括从解析chunking retrieval remark以及最终的generation，每一个环节都能够评估。当用户给出了query的时候，能快速的定位到他是解析的问题，还是片的问题，或排序的问题。
定位到问题之后，假如用户有一个评测集，能够快速的定位到目前的效果瓶颈在哪。然后从瓶颈的点优化，而不是比较盲目的端到端的评测结果。而他是依赖标注数据，很多用户现在没有标注的人力和物力。所以我们也提供了一套自动生成数据的框架，可以在用户上传PDF、doc等多类型的数据文件，并自动化的帮他生成co rag评估框架所需要的标注数据。一键生成后，他就能够在他自己的知识库上快速的评估目前rag的水平，以及问题出现在哪里。而目前的这套框架在好几个项目中都在实战应用了。并且对整体，对客户的系统优化也起到非常大的帮助。
三、多模态多语言rag技术的研发和应用
1.回顾
今天将分享团队在过去半年到一年，在多模态多语言rag技术的研发和应用。前面的每一位从产品同学到算法和技术同学都在讲rag，首先通过这页slice简单回顾一下，今天大家在大模型应用rag大概处于一个什么样的生态位。
1.1.范式
其实大家在用rag、用大模型的时候，基本上还是可以分为以下几类的范式。从最直接的通过PE的方式调用大模型。当PE的方式不够的时候，可能会需要针对业务场景以及针对大模型定制一个大模型。这时就需要用到翻译的技术。当然翻译完了之后会发现调用大模型对于新的知识或者长尾的知识还是不够的时候，可能会需要引用技术来完成更好的产品落地。
在右边这两张图中进行了对比。从去年OpenAI开始引领rag范式，到今年发展下来advancedg技术框架。可以看到从中间的技术架构到右边的技术架构，其核心是为了满足更复杂的rag需求。
2.维度的变化
而在简单的框架下面多了更多的技术模块以及技术能力。在这些更多的技术模块和技术能力的演进下，带来了以下几个维度的变化。
第一个变化是无论从检索还是大模型生成的效果来看，都有一个非常大的提升。
第二个是一套更复杂的百炼提供的rag系统，能够满足更加多元化的rag的业务需求。
对应到算法模块，今天我们讲多语言和多模态的rag，本身这套系统也不是为了做这件事情的，它是从业务演进的，即从云原生，我们只有可能满足最简单的文本知识问答，到今天越来越多的复杂的rag业务场景，需要做多模态的融合，跨语言的理解以及业务特性的定制。在架构图中，大概能够把拆为三个部分。即从大模型这一层，今天可能除了文本的LL模型，还有千问的VL多模态的模型。
在离线数据这一层，需要支持多模态多语言的离线数据的解析。比如在文档解析这一部分，原来传统的简单OCR识别没有办法覆盖非常丰富的像PPT数据、word数据、HTML数据的解析。那么在线处理这一部分，即在多模态的这部分召回，图片理解、表格问答以及在多语言这一部分。今天在多语言rag里面，不仅仅是要满足自然语言的处理。比如中文、英文、德语、西语，其实还有一类是大家可能在实战里面用的更多的，是code语言。比如多语言的理解。
根据算法图，还挑了几个最重点的，在多语言多模态rag场景里面比较几个比较重点的这个算法模块，想跟大家做一个分享。第一块就是多模态的文档理解。在面向多模态rag场景里面，对于多模态的文档理解是最重要的一步。即数据治理的准确率在某种程度上决定了rag系统最后效果的上限。
3.多模态文档理解中的复杂问题
多模态理解右边这一列其实在多模态文档理解中是最复杂的四个问题。第一个是文档的格式比较多。第二个是多模态版面的元素。第三个是版面的层级结构是比较多样的。最后一个是对于超长文档，比如产品的宣传页，它可能有上万页的超长文档。而怎么来做好一个统一的多模态理解的模型。在这一页想分享一下，在过去半年，多模态文档理解像OCR技术已经发展了很多年了。由于多模态大模型的出现，给多模态文档理解带来一些新的技术路线和技术思考。
在这一页里面，基于多模态大模型给多模态文档理解带来了三个最大的变化。
4.探索
这也是过去半年做的比较多的三个方向的探索。首先是统一的多模态文档识别的能力。可能在过去，像4S展示的做OCR的识别，做公式的识别，做表格的识别，它们都是一个独立的模型。今天由于多模态大模型的出现，使得我们可能基于一个模型做通用的模型的识别。
第二部分在文档结构上面，原来当我们只关注OCR的时候，其实对于文档结构的要求没有那么高。但今天需要在这个文档里面把这个文档里面，比如跨页，需要把图像和文本非常清晰的抠开的时候，这时需要一个非常强的文档结构识别的模型。
第三个是长文档的解析，对于电子解析还好，但是对于非常复杂的，需要走混合模态解析的长文档。那么最近半年可能在重点探索的方向是混合电子以及流式解析的技术路线，它能够快速的帮助用户拿到超长文档，甚至超过1000页、一万页的文档的解析结果。
5.特色
百炼提供的文档理解能力，在算法能力和产品能力上提供了相比于竞品的特色。首先在文档能力基础的能力上，无论是文字识别的准确率还是版面识别的准确率，应该都是能做到90%以上。第二个是相比于竞品来说非常突出的几个产品能力。第一个是支持把更多的文档格式转换为大模型能够更容易理解的markdown格式。第二个是百炼的文档解析，最长支持超过1万页的文档解析。第三个是混合解析，即支持电子版大小模型的混合解析。混合解析带来的最大的变化是效率的提升以及成本的下降。
四、关于多模态多元embedding和rank模型
在离线数据中，以及在多模态文档理解做的工作。第二部分想分享一些关于多模态多元embedding和rank模型，evidence和rank也是完全因为rag的发展吸引了大家越来越多的关注，并不是因为有了rag才有了evading和rank。做过搜索的同学都知道，evading和rank发展了非常多年，而对大模型的出现只是让大家更多的关注了evading和rank方向。但是本质上无论是从早期的预训练员模型，比如bird模型开始，到大模型embedding和rank的训练方式、训练范式都没有发生大的变化。总体来看，embedding和rank的模型总体上还是遵循着双塔模型和单塔模型的训练范式。对于双塔模型，可能会把用户的query和document基于预训练员模型的底座表征成高维度的向量。最后通过对比学习的损失来训练，从而得到embedding模型。蛋糕模型唯一的区别是把query和document拼接在一起丢给大模型，最后产生一个相关性的score。它的训练数据和训练模式，本质上evidence模型是一模一样的。
在早期做搜索的时候，或进阶到大模型应用范式下面，更多的是给evening模型、rank模型提出了更多的需求。比如对embedding模型来说，可能对早期做搜索系统的算法同学来说，做embedding模型更多的只需要关注模型的性能和泛化性。对于排序的多样性等，还有后置的，比如推荐的模块来帮助我们去做掉。但今天可能在rag应用范式下面，需要给embedding模型注入更多的多维度的能力。比如在做embedding的时候，需要有多元和跨语言的能力。甚至随着向量数据库的发展，比如python的向量数据库，他们开始支持离散表的高维的embedding表示。同时也需要evidence模型有连续和离散的表示能力。
最后一部分是embedding不只面向于文本。那么怎么样做一个多模态的表征？弹性维度表示这个能力更多的是面向应用侧的，即可能从OpenAI早期开始提供第一版的模型是8192位，那么后面可能流行的是1536位。但到最近几个月大家能看到越来越多的无论是百链上提供的text embedding最新的V3模型，还是OpenAI提供的0003。他们最新的模型都是支持弹性维度表示的。即用户可以在使用embedding模型的时候，自定义的，比如我需要多少维度的向量，来节省向量数据库的存储以及在线查询的耗时。对于rank模型，本质上rank模型和ebell ding模型都是在做建模文本之间的相关性。但是rank模型可能相比于ebel ding模型还是有几个不一样的维度要求。第一个是希望rank模型能够提供更高的相关性的区分度。如果用过evading模型的开发同学肯定知道evading模型它有一个问题是对于不相关的文本它可能是0.7分，对于相关的文本是0.8分。这是对比学习训练范式带来的效果和效率之间的trade off。可能目前都没有很好的解释。但是rank模型它可以带来更好的相关性的区分度，然后提到多模态和多语言，需要有一个统一的多模态多语言的rank模型，来支持我们做更面向多模态多语言rag场景的embedding和rank。
五、基于千问大模型训练embedding和rank模型最重要的几个模块
1.模块
在整个训练范式里面大概可以拆分成三个。第一个是数据，你的数据决定了最后你的模型有多少的性能、多少的泛化性以及多少的能力。第二个是底座模型，底座模型带来的是比如多语言的能力，以及多模态表征的能力，它们大部分是从底座模型来的。第三个是训练策略，虽然大家都在用对比学习的训练的loss，但是在emda和rank模型中还是有很多的训练策略值得大家去探索训练的。最后得到一个更高效的以及更稳定的，符合更多应用场景的evidence和rank模型。
2.数据侧中的工作
接下来重点给大家分享一下在数据侧中过去半年做的工作。首先，主要在四个维度，在数据测领域内做了探索。第一个是构造了更多的基础相关性数据。基础相关性数据不仅来源于更多的benchmark的数据，还来自于大模型合成的数据。从某种意义上，能够用来训练模型的相关性的数据基本上被用光了。为了满足更多用户需求的相关性的需求，研发了一套基于大模型合成相关性数据的问题。基于大模型去合成相关性数据的领域探索，其实大家并不陌生，从最早做相关性bird语言，在有bird模型开始，就已经有很多工作在做相关性的数据合成的工作。
3.变化
但是大模型的出现，使得这种相关性数据合成带来了两个新的变化。第一个是大模型合成的相关性的数据的质量，肯定比原来小模型合成的质量要更高。第二个是大模型能够帮助我们复合成更复杂场景的相关性的训练数据。比如在这套训练范式中，原来可能基于小模型的合成范式，就直接把copps丢给模型，模型给我生成一个query。但其实更合理的方式是，在大模型出现后，可以让大模型帮助我们合成一个角色，基于这个角色他能够再帮我合成一个适用于我这个业务的场景。基于这个角色和场景合成一个更符合业务需求的相关性的训练数据。基于这样的训练数据训练出来的模型往往能够更符合业务需求。
4.基础数据的收集和多语言和多模态的rag能力
在训练bedding和rank做了非常多的code数据、多语言数据以及多模态数据的整理。最后用这些数据叠加上通义千问的底座模型，来训练emda和rank的模型。
5.训练策略
在训练策略这一部分，重点分享几个比较有效的训练策略。第一个是多阶段的训练。它指的是基本上今天能够拿到的相关性数据，可以分为两类。第一类是弱监督的相关性数据，即从开源社区、行为制，都能够拿到非常多的弱监督的相关性数据。这个数据可能在几十亿，可能是上百亿级别的，那这个数据的好处是它有非常好的领域泛化性。但是它有一个问题是他没有经过人工的标注，它的质量是可控的，但是我们能够拿到的相关性的数据，他需要的成本就是比较高的。所以目前非常流行的训练范式是通过多阶段的训练范式来提升整个模型的泛化性，最终训练出模型的效果。
第二个是混合模态的均匀采样。在很多开源的工作中，都没有特别细致的讲过。在训练模型的时候，怎么样在做每个batch的采样的时候，做更加细粒度的副样本采样，包括混合模态不同的task之间的均匀采样。这是提升模型泛化性非常有效的动作。
六、在开源社区推出的GT千问系列的模型
在MTB中，无论是英文、中文还是法语、波兰语的评测上面，对比于开源的模型都是有非常大的提升。
1. 统一多模态表征
即面向文本搜图、表格、图文等一些更复杂的多模态rag场景，并且它需要多模态表征的能力，在传统中大家都是基于clip模型来做，而Clip模型经过这么多年的发展已经非常成熟了，无论是从OpenAI早期，还是现在的开源社区。在之后的探索中，今天多模态模型做了统一多模态表征的新的机会，即基于多模态模型，它相比于原来原生的clip模型，会发现至少在同等数据集探索下来，会有以下几个优势。
（1）优势
第一个是可以充分的利用多模态模型具备的底座能力，无论是多模态的对齐能力，还是多模态的推理能力。因为clip模型通常是要从0到1开始自己学的，这个成本相对来说是比较高的。
第二个是更统一的表征模型，原生的clip模型当然也可以做，比如我去加一个score fusion，那么它变成图像则是一路的表征，而我本是一个表征，以及图加文也是一个表征。clip用的最多的范式是单图表征，但是图加文他就没法做了，从而在范式下它的效果就没有办法做很好的保障。但LM是基于多模态的大模型做的多模态表征，对于复杂的单图、单文图、加文、多图和视频，都能表示成一个统一的向量。基于这种方式是非常有可能做一个多模态的统一召回范式。
这种范式对比clip范式，首先在文图的召回上，因为受益于LM本身的文本理解能力，在文图召回场景上会有非常大的效果提升。而纯图片的召回也会有非常明显的超过85%的效果提升，并且对于机器性能以及召回性能的消耗上都有减少。
因为统一的范式，比如文家图最后存出来只有一个向量。那原来可能文本要存一路，图像要存一路，那么对于存储几乎是百分之百的节省。最后在召回效率上，可能原来文本存了一路，图片存了一路。对于这种分支的策略，实际上是以分桶原理为基础，而召回的效率会受到每一路的约束，因此一路统一的多模态范式，使得我们有可能在召回的效率上有非常大的提升。
2. 通过ES lies分享多语言多模态的rag算法
通过百链平台或者开源生态怎么去使用呢？第一个是基于百炼的控制台的配置方式，用百炼最新的配置方式来配置面向多语言和多模态的rag应用。第二个其实是面向开源生态的介入，无论是embedding，还是rank的API，其实最流行的还是开发者社区，包括lamer index和long chain，它们都集成了版面提供的算法API能力。第三个是分享算法产品的同学提到的百炼本身也提供lama index官方SDK的接入，从而帮助开发者同学更友好的接入百炼提供的rec算法能力。第四个是关于开源生态，不论是GTE的embedding的模型，还是GTER rank的模型，包括IDP文档识别中的OCR以及版面识别的子模型，在model scope和hugin face上都是开源的。
因此我们也非常欢迎各位开发者到开源社区中使用开源社区提供的各种各样的不同尺寸的基于encoder或LM训练的各种各样的模型。因为今天开源了最新的千问2.5的版本，基于千问2.5版本训练的embedding和多模态的arank的evidence和reject模型，应该很快也会在开发者社区和大家见面。
3.多模块和多语言的rag能力
在实际应用中，它大概能够应用在哪些场景呢？这些是从真实的业务客户中总结出来的场景。
第一个是多语言的智能问答，因为我们发现很多跨国或跨境业务的公司，它本身就是一个做数据治理的公司，它的很多数据天生就是多语言的。在今天他利用百炼提供的多语言的搜索或rag能力，能够帮他更好的搭建一个多语言智能问答或数据处理的能力。
第二个是多模态，在旅游和商品推广的场景中，它是非常依赖多模态的能力的。比如在旅游场景中，对文物、景点来做check或做一些问答等。再比如在商品场景中，对于做电商的客户，会发现他们需要在，比如小红书中推广商品，而它是不是我商品库的场景呢？甚至我还需要基于这种大模型帮助我自动生成一些文案，但这个文案又不能太离谱，那么它应该依赖于本地的商品知识来新兴推广出，并写出一段更合理的文案。而这样的应用场景实际上是重度依赖多模态的检索，以及多模态的VO能力。
4.关于多模态产品的智能辅助
在典型的问答场景中，光有文本是不能很好的满足用户的query需求的，比如儿童座椅卡扣在哪个位置，而这个位置由你告诉他，并写50个字进行描述，这可能都不如告诉他一张图说卡扣就在这个位置更直接。而怎么找到这张图，以及通过大模型把这个问答给到用户，而这实际上是依赖我们构建的多模态的能力。
5.code检索能力
还有一个场景是关于code检索能力。他可能会有一个产品的使用手册，而这个手册中有各种各样的指令。通常来说，以前会需要一个非常熟练使用这个产品的人。比如我有一个需求，需要你帮我查一下ACC代码98RC的指令，并用某一个版本给出一条这样的查询指令。而这样的指令原来可能需要对这个产品有非常好的了解，才能够把这条正确的指令给出来。但现在借助于code的检索能力，并且基于自然语言的查询，通过code检索相关产品中的描述，再结合大模型的生成，就已经能够得到一条非常高质量的执行查询规范。
最后，欢迎各位开发者和用户使用百炼大模型，以及百炼平台提供的多语言和多模态的rag能力。
七、在模型应用相关的技术实践上的可运营
可运营已经是越来越被提到的一个话题。今天将围绕在模型应用相关的技术实践上的可运营做展开。其实是大模型提供了一个新的动力引擎，它帮助我们在驶向业务目标的过程中，提供更强劲的动力。但是在真正航行的过程中，不只有这种动力系统，包括你的导航和雷达等，这些配套才能让我们更针对性的持续校准航行的目标，以及做到中间的加速。
在加速过程中，大模型一般会分为常见的几种。左边这几种是它的模型类型，包括直接的模型调用，通过prompt或者通过智能体，结合一些工具或者rag的增强，以及结合更多的复杂的链路业务工作流，多智能体的复杂应用。但其核心依然离不开大模型对于理解生成，甚至推理能力的应用。所以今天的话题，首先会聚焦、围绕在模型可运营这方面，他是怎么做的。从模型来看，首先它在应用范式上，目前会有这5种，包括从基础的预训练到对齐到上线的in context learning。这里又会分为，比如结合外部知识的rag和直接基于指令的prompt engineering。在这个过程中，会发现第一预训练或者领域的预训练以及对齐，是由于数据和模型算力的要求，以及对齐的优化技巧的要求。
但现阶段具备一个比较大的应用门槛，只有比较大的客户，或者有较强的技术研发能力的用户才会涉及。随着基膜的能力持续提升，会发现越来越多的工作从SFT环节逐步的转向in contest learning的这部分，即回归到原子化的场景下，基本上很多的机模能力已经逐步能够体现出开箱可用的形态。
今天主要会围绕下面这部分做展开。当然前面已经有两位嘉宾针对rag能力做了非常详尽的介绍，但我可能更多的关注在in context的另一部分，即关于提示词的自动化优化部分，百炼在半年甚至一年之前，就已经提供了针对提示词的自动优化的实践，它的形态和我们的理解是一样的。
但今天meta prompt又有了一些新的能力的加持。首先在最左边是基础的业务场景，它可能字有点小，不一定能看得清楚。它是对营销广告做分类打标的工作，以及做类似舆情分析或素材分析的环节。最开始的业务描述是一个很简单化的样例，它到右边直接作为具体的模型指导的prompt而在中间meta prompt可以帮助用户来做到这样几个能力。
第一个是可以针对这个任务做进一步的提示词的扩展。大家可以看到，这里涉及到了具体的，除了描述以外，还涉及到具体的任务步骤、注意事项、相关的技能，甚至大模型所具备的角色要求。第二个是样例的重要性，它对于模型的性能起到一个非常关键的提升，同时也支持了自动化的样例库拓展，并且在整个业界相对来说也是比较新的能力，即可以支持用户上传一些bad case，使得它基于当前的prompt来去反思过程中哪些可能没有被考虑充分，并给出具体的优化建议，它还可以以一种比较点名经验的方式融合到原始的prompt，使得它既能保持之前的性能，又能提升在新的场景下的解决能力。
它背后的技术原理是什么呢？即提示词能够写好，那么它一般会有一些标准化的结构，比如以最左边的例子来说明，它一般会涉及到任务的背景上下文相关的描述，包括输出的格式的约束和具体的要求等。在这个过程中，同时也为各平台提供了框架性的写作建议。
除此之外，在不同的任务场景，它关注的元素不一样。比如我做一个分类，可能会需要让模型去关注不同的类型，而它的主要关注的点是什么类之间的差别呢？特别是对于模糊的情况下，怎么做区分呢？对于曲，他更多的关注一些特定的语义模式。比如什么样的情况你不能去遗漏，或者在这里怎么判断冗余多余的情况。除此之外，像写作或者对画的更加灵活的场景，可能会有更细粒度的要求。比如针对他的表达风格、写作手法或者切入的视角等。这是对于任务层面，我们需要从提示词上去考虑。
除此之外，有些会把它应用在不只是简单的解析类任务，更多的是业务的推理。比如在客服的进线判断的场景下。可能会根据业务的定义分为售中、售前和售后。因为不同的解决方案可能涉及到的客服的技能组不一样，这里可能又会涉及到，比如生鲜类和3C数码类，因此它又会有不同的判罚的准等等。在这种情况下，为了更好的指导模型的行为，一般我们会建议形成一些步骤化的措施，而这其实有点像是我们让大模型一步步思考的替代，或者更高效的指导原则。
如果把这么多的维度整体考虑进来，让它形成一个完整的提示词，那么中间会有非常多的工作。而今天是统一的通过meta prompt来形成了一种自动化的支持，不仅是对于结构化的数据生成，还有专有知识、任务的自动拆解，它都可以做。而这背后主要利用了两点。一方面是利用模型在千亿大模型基础的推理能力，加上多部的迭代反思的能力。第二部分结合了历史上积累到的大量的优化实践case，构建了大量实践的最佳技巧。这部分的技巧让模型在优化过程中可以有的放矢，当然除了模提示词做了基础的扩充之外，我们真实的场景还需要结合具体的数据做到不同的具体的精细化的迭代和打磨，并通过持续的优化来做。
但在打磨优化过程中，还有几个常见的痛点，第一点是bad case，针对bad case去解决它，并不一定能带来全局的提升。甚至有时候我们过于关注corner case，导致它原来能解决的一些问题无法被稳定或影响到它原始的解决能力。
而这由两个原因造成。第一个是bad case，它是不是真正具有代表性。第二个原因是在大模型的现阶段，对于一些不同词的表达很敏感，而这会导致如果针对特定case有较大幅度的更新，他可能会丢失掉以前比较关注的约束。
所以针对这两个原因，我们针对性的引入了一种高效的采样机制。一方面不需要针对全量的数据集，消耗大量的算力做计算的优化。同时还能兼顾它已有的一些需要保留的能力的数据代表。除此之外，我们也用了mini batch的优化技巧。大家学习过神经网络优化的话，会比较好理解这一块原理。
除此之外会发现随着bad case越加越多，整个prompt会变得越来越长。一方面增加了调用的延迟，另一方面增加了token消耗，但更主要的是它可能会带来一些潜在的冲突，甚至在可维护性上变得极差。所以引入了一种层次化的提示词迭代压缩的能力。因为它可以针对不同的，比如要求层面或者样例层面去抽练与这个任务最相关的信息，使它得到一个更好的保留。当然除了在规则层面，在基础指令层面，样例也非常重要，并且现在已经有大量的样例存在。研究和具体的实践表明，样例即使在我给到很简单的提示词的情况下，依然可以让它保留一个比较好的性能。而且它随着你样例的质量提升，它的性能也会带来持续的提升。
在这个过程中，样例怎么样才是一个好的样例？它有两个核心要素。第一个是他是不是真的有代表性，我们要增强这种代表性样例的占比，然后使得他能够更好的理解这个任务。另外一个是样例是不是有多样性。因为实际的情况下不可能只是千篇一律的特定的query。这种多样性可以补充或者增强模型在这个场景下的泛化性。所以除了让用户直接手动上传这些样衣以外，也提供了一种多样化扩充的技术的增强。
在这里针对性的增加了一种基于蒙特卡洛采样的思路。它基于一种tree base的奢侈过程。即比较通俗的理解是他会尝试经过多步搜索与当前case带有一定相关性，或者带有特定差异性的样例，逐步的迭代，然后形成在不同的维度上，这样便有一定差异化的例子。以这个例子为主，比如我们这是一个很简单的示例性的问题，我们可以一方面从语义角度或者格式角度去发生一些变化。另一方面可以给到他一些错误的样例，让用户或者让模型能看到正负样例，从而拉开这两者的差距。这部分更多的引入了一些对抗的思路，加上一些多部的refine技巧，来使得整个过程更加稳定，并针对性的找出模型可能会犯错误的场景，让模型或人工来去优化它。当然整个的提升还是围绕在整个关于任务级的提示词优化的路线上。回到ICL的本质上，它提供了一个今天动态化的机制，可以让整个干预变得更加灵活。这也是为什么今天就把提示词从静态往动态上升级。因为这样就可以从任务力度往query力度实现更精细的光，或优化和对齐能力。这里一方面它会复用离线的增强或者优化的结果。比如针对反馈的优化或者样例的合成。另一方面可以看到我们可以做到精细化。即从针对特定的corner case或者典型的case，抽练出与它直接能干预到的一些规则指令的提示词，或者相关的样例。再把这些样例形成一种动态可组装的要素。并在线的过程中，实时的将它和已有的框架或者静态的提示词做整合。
这部分对一些场景在快速迭代变化的情况下，提供了一个很好的、无损的、无需特别重的优化迭代，这样就能快速alien到业务的新变化。同时对于检索的额外延迟的消耗，或者不同的OOD，即领域外的query的兼容也做了大量的优化。
整体来看会发现一个有意思的点，即在复杂的业务推理的任务上，通过动态化，它会极大的增加相比任务级的推理的效果，可以认为是我们经常说的会有快思考或慢思考，那么这其实相当于我用快思考的时间加上一定的空间，换来了等同于慢思考的推理效果同等的效能机制。当然除了具体的技术可以看到实际的业务变化。在这里对比现在开源上比较火热的DSPY或者text的框架，我觉得开源框架目前在一些基础简单的任务上。比如我做一些摘要，或者可能几句话的提示词，在这个基础上的优化效果还是不错的。但实际上拿到业务场景上，比如可能经常会看到业务上，或者我们的客户写到几百甚至几千的提示词的复杂业务场景上。因为现在开源的框架，它更多的只关注在自动优化的环节，而忽略了对于这里边的一些精细化的理解，包括优化耗时以及优化的稳定性等要素，这导致了它在复杂任务上没有办法带来提升，反而会带来下降。
例如，在前面看到的20种的广告类型分类，很可能在优化过程中，开源的框架会误将其中的某些类别合并掉或者删改掉。这其实在业务层面是不可接受的，包括在抽取上，可能他会做一些错误的判断，导致了原始的约束项的错误。所以目前就只有真正的结合到整个的精细化的理解上，才能看到它会有一个比较稳定的效果。因为现在的相比原始的prompt完全自动化，即不介入人工的情况下，大概能提升3到4个的基础PT。当然除此之外在一些基础的，比如GSM或者word sorting的开源的公用的榜单上，目前meta prompt也依然提供了一个有竞争力的性能。
除了在ICL上面的优化之外，也简单的说一说在SFT上面的优化。在整个SFT落地的过程中，一般是七、八十的时间都要花在高质量的数据构建上。因为用invite的训练方式，如果post train的数据质量不如它原始训练的数据的话，它很可能带来一些额外的下降。比如我们用一个cham max加一个APE，在一些比较复杂的场景中，它对于整个分类的标签大概有几十种，或者实体抽取的范围和灵活性会有更高的要求。
在下面的普通训练中，也不一定带来很好的提升。比如APE大概能做到自动化的prompt engineering，大概能做到78和72。但基础的SFT可能会带来一些提升，其核心在SFT有较高的数量数据质量要求的情况下，只用简单的ICL的样本，让模型直接针对这个数据生程，往往会带来一些多样性不够，差异性不足的问题。甚至对于一些输入、输出的细节缺失，和曲解的现象。所以针对这块做了更细力度的分析，它主要围绕在本身内容层面上，input和数据output的特点，以及任务维度上的要素。针对它做了一些细粒度分析，再把它影响到后续的合成环节。当然也包括了一些演化以及后校验，以及人工human in the loop的迭代闭环。整体来看，它不仅可以在P的角度上进一步的提升效果，在分类上也能提升七个点。除此之外之前用的是7000万max，可能是千亿的、几千亿的模型。但现在可能在turbo的17B、 14B或7B的模型上就能达到类似的性能。当然除了SFT的数据构建以外，其实在评估中可以感受到在整个可运营中他扮演着非常重要的角色。如果单纯的靠人工来评估，那么它也依然是一个非常重的工作。
今天也能看到有大量的评估模型，不管是基础的，比如GPT FOO，还是CM max，或者是兄弟团队提供的semis的裁判员模型，他们都已经具备了不错的评估能力。但在实际的业务复杂场景上，会发现它存在着从左边到右边巨大的gap，其核心在于在复杂任务上，它对于评估的维度要素相关的标准，实际上都需要人工的设定评估期的prompt，来达到更好的适配。所以今天我们做了一个工作，即针对整个任务到具体的评估能力上做了自动化的适配，它可以根据相关的参考和最佳实践来自动化的补全相关的标准温度信息。
可以看到整个人工专家、业务专家在打分一致性上，从不到80提升到了88，现在可能接近90的水准。
接下来介绍一下百炼的可运营，我们认为可运营是一场持续的迭代演化，或者是一场长期机的战役。在整个过程中，它是从应用的接入，即有了这样的引擎以后起航的阶段以及可观测。在这个过程中，用雷达系统能够发现前面什么样的水域适合我去前行，以及在这个过程中的持续的校准、加速的调教阶段。在这个过程中，我们希望用户能够只给到我们最开始的航向目标，以及过程中的样例。而在整个航行过程中，尽量以copy的辅助，甚至自动化的agent的形式来帮他去完成。当然这里边已经涵盖了我们刚才介绍的能力，并且有一些还在进行中。但在目前的阶段，基本上在任务级的支持，以及针对任务级的优化都进行了逐步的覆盖。
未来我们希望能够进一步的结合到online的部分，把这种复杂的链路或者复杂的业务流程都纳入到可运营的范畴中，从而实现复杂应用的全面可运营迭代，即在今天我们有一套导航系统能够结合雷达的探测，让其在航行的过程中完成全面的自动化运营的支持。
八、关于AI运营实践
在过去一年中我们也交付了非常多的大模型项目，从中也沉淀了非常多的实施组件。
1.运营的角度
从运营的角度看，共有四个方面。
第一个是测评的标准不完全统计，在过去沉淀和积累了大概几百个以行业及场景维度的评测标准。基本上有了标准之后，也就知道大模型的效果好坏，包括目标的期望结果的差距是多少。
第二个是关于测的数据。很多客户来和我们反馈大模型效果的时候，都会以单个的bad case。但这也不是那么的全面，所以我们基本上会建立像黑盒、白盒等大量的测试集，来更好的衡量和帮助算法修正和完善效果。
第三个关于运营工具，上一位嘉宾也提到了在plant的优化，包括在自动化的评测环节上，也有非常多的工具来帮助我们的客户，来辅助他们更好的把大模型用起来。
最后一个关于运营的方法论。大模型在大部分场景上，基本上一个print加上机模就可以达到我们的期望效果。
2.PE实施的阶段
PE的实施还是非常重要的，共有几个阶段。
第一个阶是需求的阶段，很多时候我们一拿到任务就开始写plant。但是在这个过程中，我们真正要去做什么？想要实现的效果是什么？服务的客户是谁？包括希望大模型产生的结果是怎么样的，以及转化成业务指标又是什么？所以在这个环节也是需要运营同学先深入的分析完，再进入到下一个环节。
下一个环节是PE真正去做的过程里面，共有四个环节。第一个是先建立评估的体系，即有没有评测的标准，有没有测试集准备好，能够校验我们的效果。第二个点是数据的分类和分析。因为print的组成需要很多输入数据源来做大量的特征提取，把关键因素能够加到我们的指令中。第三个点是框架的搭建。最后是基于不断的实验和通过bad case的分析来迭代print的优化。
做完了整个指令效果验证完后，最后就到了下游系统的对接，到底要跟哪些业务系统打通，以及如何用，并怎么达到业务的结果。
3.原则
在设计print过程中，基本上会有几个原则和优先级的关系。第一个原则是我的prompt一直调不好。但最后会发现数据源本身它的质量就不高。所以在这个环节中，我们建议大家在做之前，一定要将输入的数据源做清洗。比如今天在外呼场景，我们要校验他的服务态度，或者他的服务质量好不好，流程有没有遵循规则。首先对于数据源来说，他有没有呼出去的电话，有很多是短秒的，还有一些电话可能是语音提示的，或者机器人接听的等一系列。而像这样的数据就需要提前做处理。
第二点是提示词到底能不能很好的复制使用。在这个点上我们在很多项目上接触下来会发现其实很难。即便是同个场景，但是在不同的业务点上，它也不是那么容易的可复用。
第三是提示词的详实度问题。大家会觉得我写的更详细，从而模型就能更好的去理解我要做什么。但真正实践起来的时候会发现，像VL模型我们就测试过，如果只是让他识别整个图片里面的物品等任务时，一旦跟他说你是谁，你要做什么，以及第一步做什么，第二步做什么等过程，这样反而会给他增加负担。使他输出的结果，没有一句话让他做任务来的更好。
4.优先级
关于优先级，共有三点。第一个是从0到1的过程，它和做业务一样。在今天写提示词我们也要看哪些是高频业务，并且要先将高频业务的效果打磨好，即可以代表整个效果的好坏。
第二点是从零到N的攀升过程，它们也是一样的。比如我们会做bad case的分析，包括分析出来也要归类好，并统计好数据的分布。在这里也是从错误类型最高的着手，再慢慢的把长尾的问题解决掉，最后迭代到plant中。
在设计和写框的过程中，会有一些策略。从起初你要去操作写print的时候，我们建议有一种方式，你可以让大模型帮你写，你可以用自己的语言去描述，让他结构化的给你输出，这是最高效的一种方式。另外在持续的迭代过程中会发现，经常输出一些bad case，你都没法清楚的知道为什么有这样的case。这时我们建议你不要吝啬，直接去问大模型，问他为什么你会说出这样的结果，并把你的推理过程给我输出出来，这时你就知道他原来是这么想的，然后才会输出这样的结果，再反推回去迭代你的plant。
5.策略
在整个过程中，共有七个策略。
第一个是善用分隔符，我们会发现不用和用它的差异是有一点点变化的，但是一定是用更好。
第二点是关键信息，我们建议可以多次的强调，这样来增加他的记忆的权重。
第三点是补充一些专有知识给他。因为大模型也不是全能的，什么都知道的。在一些个性化的业务中，你需要把一些业务的定义给他提前定义好，然后告诉他能够让他学习到有一定的学识。
第四点是few shot，大家经常会用到，但是一旦你挑选的样本不是那么的具有代表性和全面性，那么很有可能会误导和增加他的错误率。所以在样本的挑选上，大家一定要挑选具有代表性和全面性的。第五点使关于一些需求，如果是比较重要的，但是它遵循上有点困难，那么我们建议可以滞后的放着。因为在更近时间轴上的问题他可能记得更牢。
第六个是关于检查步骤的用法，因为在很多时候会发现他漏了一个小点的时候，我们会用一种方式叫检查方式，即让大模型说你在输出之前请先检查，一是否满足，二是否有这样的操作，三是否有这样的思考等。用这样的方式可以让他不会遗落掉任务里的各个细项。
第七个，我不知道大家有没有遇到过，经常会有他的推理过程是正确的，但是他的结果却是错的。或者他的推理过程是错的，但最后结果对了。所以在这种情景下，我们常用的是让大模型在print里告诉他，你需要先输出推理的过程，最终再给出一个结论，这就是我们常用的。
6.案例
这个案例也很常见，即在网销、电销、在线服务、线下服务和热线服务等服务场景中，我们需要对对话中提取客服的服务态度有没有按照业务流程走。还有一种是通过对话分析有没有二次销售的可能，在这个场景中，基本上都可以做到95%以上的准确率。
7.注意事项
第一个是要说明这里有哪两个角色，以及这两个角色分别是做什么的，也要说清楚你接下来要做的这个任务的规则。在这里我特地写了关于规则的编写，即就low是什么？logo 2是什么，describe是什么？因为这样的格式我们会发现在用文字表达的时候，它的效果相对会更好一点。
第二点是因为在整个绘画中，我们既要去看他有没有遵循整个任务的流程，也要去看他的服务态度，还要最后得出一个结论，即通过绘画有没有二次销售的可能，有没有潜在的需求，所以任务还是非常复杂的，在这里我们会给他做很多的拆解，原先可能只描述，描述完了之后让他给结论。但在这个场景下，我们基本上会告诉他规则一是什么，规则二是什么。然后先给出规则以上的结论，最后再输出结论的依据，以这样的方式能够让它更清晰，更有逻辑性的给出输出结果。
第三点是我们常碰到的在热线的语音质检下，有很多客户会跟我们说ASR的转写不准，导致他的输出结果不好。但其实我们不用纠结个ASR的转写问题，在print中我们做了一句话的强调，并发现大大提升了整个ASR带来的错误率。我们会告诉他有些词可能描述错误，但你需要基于语境去理解原本意思，不要直接因错别字而判断不合理，即相当于我告诉你这有很多可能是错别字，但你要基于语境去理解。最后提到了一些常用的策略检查步骤，如果他输出的时候效果没有那么稳定的时候，就让他按照步骤一步一步的给我们输出来，然后最后也要检查是否符合在场景上常碰到的和常使用的方式。
8.rag实施的方法论
很多客户经常来问我们，说我有十万的知识量，接下来我要怎么做？还有客户说我已经导了3000篇文档进来，但是效果一直不好。在这种情况下，我们一般都会给客户看实施的路径和流程。
第一是要告诉他你是不是已经搞清楚了整体的业务情况。你有没有弄清楚今天你服务的对象是谁，以及他们会问什么样的问题，并且都是聚焦在什么样的场景下的。如果理清楚了这些内容之后，其实基本上你也理清楚了，接下来该聚焦的文档在哪一部分。然后再来说接下来定的目标是什么，然后再到目标转化成指标又是什么？那么相当于前期我们需要把这些业务策略定好，然后再到方案的设计。
方案设计完了之后才到人力的准备。
9.人力准备
人力准备是和客户交流最多的板块。因为大部分客户都是由IT部门发起的项目。这里我们会建议他们由三个团队来组建，并实施他们的项目。第一个团队是IT部门，负责整个方案的落地对接、联调，测试等。第二个团队是业务团队，业务团队对业务知识文档是最熟悉的，所以他需要为这些质量的效果负责，相当于质量的好坏的负责人。
第三个团队是项目和产品的运营团队。这个运营团队需要对于产品落地之后，它在业务上的真正的效果，它的好坏负责。所以一旦认为是产品需求上的问题，那就提给IT部门。如果认为是知识质量带来的问题，就提给业务部门，然后让他持续的跟踪、分析和定位他整体的产品落地的效果。
10.知识治理
在过去，做了非常多的关于rag的项目，从中我们也总结了一套关于知识治理的SOP，从整个知识的规范性到知识的采集，再到分类，再到后面的清洗，最后到长期的运营。我们都会有非常规范的SOP来支持客户在rag应用上的效果。
为什么在知识规范上会分单文档和多文档的处理。单文档本身的文档的名称、标题规范和格式规范都会影响着召回的效果。还有一个叫多文档的规范。因为文档和文档之间，如果有相似的主题或者同样的主题，但内容不同，或者有同样的内容等。这样的存在最终也会影响召回和生成效果。所以会分为单文档和多文档的处理。
11.知识分类
为什么我们要强调知识也要提前做一定的分类？因为在对外的服务来说，整个有生命周期的产品域，我们也建议可以像售前、售中、售后，或者没有生产品域的生命周期的概况，那么也可以分为业务板块，比如企业内部服务，我们都会分为人力、IT、行政等方式去给他划分，这也为了有利于未来在知识的分类处理，包括持续迭代，以及知识过程中起到便捷性的作用。
12.知识的清洗
关于知识的清洗，现在我们对于知识的聚合，包括拆分、层级的梳理、内容的归一，以及复杂内容，我们应该怎么去简化？包括多模态上的内容如何去解析，并且什么样的内容样式是适合我们用辅助工具来帮助我们更好的把知识清洗成大模型喜欢的样式和格式呢？
13.持续性运营
有的业务部门持续的对他的知识进行增删改查的处理。而我们也会有相关的运营部门对整个的效果进行监控、跟踪和持续的调优。对这一整套来说，rag的应用知识治理投入是非常大的，所以在这块内容上，我们有了一定的方法论和完善的SOP，再加上我们也研发了非常多的辅助工具，从而帮助企业客户更好的把rag的应用效果做起来。
