出品 | 技术栈（微信号：blog51cto）

日前，在主办的WOT全球技术创新大会上，澜舟科技合伙人、算法和应用VP马永亮带来了主题演讲《企业级智能知识库搜索问答技术与应用》，围绕知识库搜索问答场景，详细阐述了在AI2.0时代，我们应该如何结合大模型能力进行有效的实践与创新。

本文将摘选其中精彩内容，统一整理，希望为诸君带来启发。

以2022年年底ChatGPT推出为分界点，我们可以把过去的AI技术称为AI1.0，之后的技术称为AI2.0。那么，跟AI1.0相比，AI2.0的技术有哪些不同呢？

首先，大家熟知的“能力涌现”，以前很多通过规则的方式，或者一个很复杂的Pipeline构建起来的能力，今天在大模型中就可以涌现出来。其次，多模态的能力以及对话的能力等等，这些都是AI2.0时代大模型能力突出的地方。然而，结合我们这几年在B端行业中应用大模型技术的经验，对于大模型/AI技术的产业落地，我认为这几点非常关键。

第一，AI能力的获取门槛显著降低了。今天想让大模型完成一件任务，最简单的方式就是通过自然语言与大模型进行交互，通过做Prompt Engineering就可以做到。这在这以前是不敢想象的。

大模型的第二个特点，就是它的通用性。以前很多AI能力的构建可能都和具体的任务相关。比如之前做搜索引擎，整个团队会被分成很多不同的Team，Query理解、排序、文档的理解等等，这里面用到的技术大不一样。然而，今天不一样了，现在所有这些任务，像搜索引擎这么复杂的系统，其实都可以构建在大模型技术之上。

第三点，则是生成能力。因为以前做机器学习算法或者模型时，数据标注非常耗时耗力，卡点就在于用于标注的训练数据的稀少。今天因为生成能力的存在，就意味着你可以来生成这些数据，然后再去标注。这对于看重企业私密数据安全的to B场景而言，非常有意义。

因此，当具备了上述三点之后，大模型、AI技术开始在不同的行业中落地。同时需要注意的是，不同行业其实对大模型技术的需求并不一样，因此发展成熟度也不尽相同。

在发展比较快的行业，比如在图片生成的领域，已经有很多流水非常高、用户黏性非常好的一些产品和公司出现了；相对发展困难一些的行业，比如在基础研究、自动驾驶等领域，落地则较慢；中间则是金融、教育等领域，现在正处于启动期；同时，在金融、制造业等赛道不断地有一些标杆企业的应用开始落地了，但数量尚有限。

以上便是我们从去年6月份到现在为止，观察到的大模型落地的行业趋势。

1.AI产业化象限

那么接下来，结合大模型能力以及对to B、to C行业的理解，AI产业化最后会形成怎样一个象限？

在很多维度中，我们抽取了三个最重要的维度：门槛、效果、人力。从这三个维度看，重点去思考象限中的四个点如何在效果面上达到最好。

首先看A点，我称之为“成本之殇”，为什么呢？因为达到A点的效果，同时需要极多的人力和极高的门槛，成本非常高昂。

这也是在AI1.0时代，尤其在to B行业化去落地时面临的最大挑战，它不仅体现在人才的数量上，而且这些人才需要具备一定的模型构建的能力，成本显然很高。因为B端行业不同，需求不一样。同样的行业，不同的公司，需求差别其实也不小。

再来看点B，这里称之为“互联网模式”。它是一个边际效应递减的模式，特点就是人力相对要少，但是门槛比较高。因为互联网模式下有规模效应，比如我们之前一个团队可能有十几个人、二十个人，这些人就干一件事情：把query的意图分析得准一点，哪怕涨一个百分点，上线之后带来的效果也会非常可观——因为这样一个搜索引擎它每天的Query都是数十亿的。因此几个人、十几个人的改进就可以非常容易得到规模化，成本边际效应就会递减。

接下来，C点则是“终极AGI”，特点是效果又好，也不需要非常专业的人，而且需要的人也不多。即我们所设想的这样：不需要人来干活，交给模型、交给AI、交给AGI就可以了。这显然是很难做到的，尤其在行业落地的场景下。

最后D点，我认为是“AI产业化的起点”。像澜舟科技这样的toB公司就是致力于推向这个点。依赖于大模型技术，D点的门槛其实会很大程度上降低，也会取得明显的效果，但是它仍然需要很多人，为什么呢？因为要驾驭今天的模型去解决一些定制化的问题，确实需要一些人的知识和能力，但是它的门槛会降低。通过这种方式，去解决千行百业AI大模型落地的问题。

2.产模一体，为什么要自己做模型？

澜舟科技在企业战略布局的定位是产模一体，既做大模型底座，同时也会侧重产品和应用的研发和落地。很多人会问，“可以用很多开源的模型，为什么还要自己做模型呢？”我认为自己做模型有以下几点优势。

第一，你会很清楚地理解整个技术栈以及存在的问题。这对在应用中去做比如微调、对齐，甚至利用RAG、Agent都是非常有帮助的。即使今天大家在应用中使用GPT4或者其他SOTA模型，实际上也会面临很多问题，只靠Prompt Engineering很多时候是不能解决的，RAG、Agent也很重要。

第二，在使用大模型这些能力的时候，还意味着你需要了解模型的能力边界在哪，能力不够的地方就需要去优化。同时也确实有一些公司和客户有意愿、有需求去针对模型底座做一些定制的优化，做一些continue train。

澜舟科技在这些方面其实都有一些布局，最底层的模型，基于底层的基础模型之上我们会有一些行业的，还有一些功能性的，比如金融行业大模型、编程大模型，我们刚才讲的几个技术能力。上面就是我们今天讲得可能会比较多的，就是知识库相关的，搜索、问答，以及和写作有关的一些能力。

3.行业落地中的挑战

在企业侧落地方面，有以下几个突出的问题。

首先是模型效果。大模型直接拿来用，今天的很多问题其实都解决不了。大家使用RAG的一个很重要的原因，就是它能接入可快速更新的知识库，而这些知识库每次通过训练把这个知识infuse到模型里，时效性显然不够。此外，还存在数据库、图谱等结构化知识难以利用以及幻觉问题等。

第二，落地成本的问题，这里既有研发的成本，同时也有模型本身的成本。大参数量的模型，需要用很多机器去部署它，而且窗口越长，推理越慢，就需要更多的机器；此外，大模型的定制需要投入很多人力，如果门槛不够低的话，人力成本也会非常高。

最后，可持续的问题。大模型发展速度非常快，很多企业在采购大模型时会担心，现在花钱买了一个底座，可能没过两三个月，可能就会开源出一个比你买的还要好的模型，这对于去布局自己公司或集团的大模型技术是有一定的风险的。

澜舟科技已经开源了很多模型，在常见的这些开源社区和网站上其实大家也都能够下载。然而，我们不会去做参数量非常大的模型，因为企业客户本身实际上也并不去用太大的参数去解决真正业务中的实际问题。

金融作为重要的行业领域，澜舟科技投入了更多的资源打造出金融行业大模型。

孟子GPT金融行业大模型通过构建众多金融任务的多样化学习数据、Few-shot学习以及强化学习等训练方法，在金融任务上的性能评测上整体取得了优异性能。结果显示，它不仅在金融任务上明显比通用模型好，而且其通用能力也没有出现明显下降。

4.RAG和Agent

在搜索、问答、知识库领域，通常会依赖两个重要的技术，一个是RAG(检索增强生成)，一个是Agent。

搜索引擎跟大模型能力结合起来是一个很自然的想法，因为搜索引擎的搜索实际上是用户去驱动的，用户说我要搜什么，系统看了一些文档之后，再决定下一步要搜什么，以此来解决自己的这个问题。

大模型可以将这个流程自动化，比如，之前用户需要搜十个Query，用了大模型之后，你只需要搜解决那个问题的那个Query就行。当时的效果就已经不错了。

在与搜索结合过程中，我们看到RAG（检索增强生成）技术。今天这个框架已经非常标准化，其中的很多模块，比如Query上应该做些什么，文档上应该做些什么等，也都是搜索引擎中非常重要的模块。

文档方面，在toB的领域，很多文档都是非结构化的，比如PDF文件格式，所以文档解析在知识库这个领域就非常重要，在这个领域要解决海量信息、幻觉等问题，就可以自然接入到大模型的应用中来。

其实，这里的窗口长度也没有那么大，根据我们自己的实验，一个13B左右的模型，每个文档片段1K左右，大模型的输入窗口6K，即TOP6的文档片段，在答案的recall上就能做到99%以上。只要底层检索和排序的能力做到一定水平之后，就很容易达到这点。所以大家经常看到一半模型的窗口只有6、7K，长一点的有20~30K。

但如果你真的要解读一篇金融领域的文档，比如年报、研报，年报一般二、三百页，研报多的三、四十页，那么窗口即便是几百K都不够。

不用提推理速度，就是对效果的影响也会很明显，因为它太长了，长了之后整个窗口内的和你的问题相关的信息密度会显著下降，下降了之后就会自然影响模型的效果。

因此，并不是说这模型支持这么长窗口，就给它这么长，效果跟短文本窗口是不一样的：短不只是推理的成本低，推理的效果也会更好。

检索是一个非常通用的接口，可以通过让大模型和检索结合起来，做非常多的事。现在大家做RAG，更多是非结构化的文档搜索，但其实将非结构化文档变成半结构化或者结构化进而做结构化文档的搜索，也是一个趋势。所以就是结合了检索的通用的接口之后，同时大模型的能力也得到了非常强的扩展。

接下来讲一下Agent方面。第一，结合Agent可以设计非常复杂的工作流。企业侧存在很多复杂的工作流，它需要很多步，而且这些步骤有时还不只是一次大模型的推理，还要依赖于现在的一些能力，比如检索增强、代码的执行、计算等等，这些工具的调用其实都是通过Agent串联起来的流程。

人们可以自己设计workflow，现在编排这种流程的工具很多。此外，大模型本身也具备一定的planning能力，甚至针对一些比较局限的场景，大模型也可以自己设计workflow，而且会非常动态，会根据不同的输入，会设计不同的workflow。

整体上看，包括澜舟科技在内的很多大模型的公司，整个技术栈有这几个层次，L1-通用的底座、L2-行业大模型，L3-场景任务模型，L4-AI Agent。

5.具体案例：文档理解和搜问

现在说到文档问答或者知识库一些具体的问题和我们的一些工作。

首先，为什么要做文档的解析和理解，因为在一些文档中，它的问题有时和文档的结构是紧密相关的，有了文章的结构，其实对于RAG做更复杂的问题是有很好的帮助的。

下面就是我们在文档理解上面的一个整体的文档解析能力的架构。

首先，PDF文档、图片等非结构化的内容，通过OCR，利用大模型进行一些处理之后，得到文章的内容。

下面则是针对文档的结构部分，同样也需要OCR，通过大模型和规则的结合，就可以把非常常见的、模式非常清楚的东西定义出来，而且大模型非常适合去扩展一些偏tail的内容。

最后文档的内容和文档的结构合并之后，我们就可以得到一个非结构化文档的解析的结果，像表格、章节、标题、段落等等。

接下来就可以针对它做一个分块，这里也会有很多的策略。比如多粒度分层chunking，一篇文章可以有多种分块方法。然后在每种类型的分块方法上都进行召回，最后再做一些合并的策略，其实就会有更好的结果。

在搜问方面，我认为有三个比较重要的环节。第一，文档的解析非常重要。第二，检索的准确度，别只用一个向量去解决检索的环节，后面可能还要做关键词和排序模型，可以采用 learning to rank作为大模型最后在排序的召回层，这样可以非常有效地提升整个RAG stack推理的速度。

最后就是答案的答复和幻觉的检测,这个环节非常重要。在B端领域，一个可以落地的指标是90%以上，否则的话其实很难被使用起来，即便真的有人去用，体验也会非常差。

6.知识库搜索和问答的未来方向

最后我想分享一下在知识库搜索和问答领域，下一个阶段我们会重点关注的几个技术方向。

首先第一个就是从单一的结构数据向多结构数据融合来做搜索问答或者RAG、Agent。单一的数据结构可以理解为一种非结构化的文档，比如图片或PDF。而多结构化则是指即使是非结构化的文档，我们也希望把它变成半结构化的。

例如，输入一本讲解世界范围名胜古迹的书，我们现在问一个优点条件搜索的问题：中国的名胜古迹有哪些？如果用传统的RAG的话，很可能搜回来的古迹不只是中国的。这时候就希望针对这样的文档做一些半结构化处理。这里有一种很简单的方法：针对这些非结构化的文档构建一个简单的知识结构就可以了。

最简单的知识结构其实就是Key-value，我们抽出这个文章内容的property，然后它的value是什么。对应刚才的例子，其实就把文章中的古迹的地址、所在的国家抽取成property，只要它是“中国”就行了。这样的非结构化数据就变成了一个半结构化/结构化的数据，将其放到数据库中之后，就可以利用现代数据库搜索的技术，比如NL2SQL或者Semantic的NL2SQL，进行一些值的语义匹配的，当然现在也有很多数据库是把这种匹配向量化了。

今天这种非结构化文档的问答，通过“抽取，聚合，总结”的这种模式，指标基本上都能到90%以上了。接下来大家需要解决更难的问题，这就需要了解文章的结构，文章的知识点，知识的维度。

第二个趋势，就是从刚才说到的抽取、汇总、摘要，将转向数理的计算和推理。这种类型的问题更多出现在表格上，今天做得好一点的可能就直接在非结构化的表里面抽出一两个值，但如果让它去做一些计算、推理，比如：哪一年某个公司的营业额是最高的，成功率就会低很多，可能只有50%-60%左右。今天我们考虑在大模型中引入代码、工具等能力，利用Agent的一些技术来解决类似的问题。

最后一个趋势就是单跳检索增强转向多跳。“单跳”就是用户发一个问题，我们就把这个问题需要的东西搜回来，你可能会对这个Query做很多改写去搜。而“多跳是什么”？比如这样的问题：A、B、C三个公司的年营业额或者2023年的业绩表现对比是如何的？这几个公司的业绩表现可能是在三个文档中，你直接搜这个问题，即使多文档的搜索效果也不会很好。这个时候就需要“多跳”。

所谓“多跳”，就是这个问题就会拆成一个并列的搜索。回到这个例子中，就会把它拆成三个Query，分别搜A公司、B公司和C公司单独的内容。除了这种并行的多跳，还有很多其他类型的，比如递进、交并关系等等，甚至有一些是计算的。澜舟智库，作为澜舟科技精心打造大模型时代的智能知识库平台，专为现代企业量身定制，该平台集智能AI搜索、知识库问答、AI辅助写作等功能于一体，能够帮助企业迅速构建起既安全又可靠的专属知识中台。我们也会在未来的澜舟智库这款知识库产品的迭代中不断地引入这些新的能力进来。

本文转载自​ ​技术栈​ ​，作者：言征