精益驱动下的金融智能化变革：大模型与知识工程的进化

鲍捷2024年09月19日约 21 分钟

嘉宾｜鲍捷，文因互联董事长兼创始人

策划｜FCon 全球金融科技大会

大模型时代背景下，精益思想和提示工程的引入，成为提升金融行业智能化水平的关键驱动力。

在今年 8 月举办的 FCon 全球金融科技大会上，文因互联董事长兼创始人、中国中文信息学会语言与计算专委会金融知识图谱工作组主席鲍捷博士发表专题演讲《精益地打造金融专家智能体》，探讨了如何通过精益方法论实现大模型在金融领域的有效落地，并展示了提示工程在知识建模中的革命性应用。通过对典型案例的分析，揭示新技术如何帮助金融企业实现降本增效，推动行业进入智能决策的新时代。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）

从精益出发

精益，或称为 Lean，是一种追求效率和减少浪费的方法论。在软件工程和创业领域，我们经常听到"精益创业"（Lean Startup）这个概念，它其实是一种思维模式，强调用更少的资源解决问题。在人工智能领域，核心问题往往不是算法本身，而是如何以更低的成本解决问题。例如，如果有足够的资金，理论上可以解决任何问题，但现实中我们更关注如何经济高效地实现目标。

在知识工程领域，问题不仅仅是成本，因为知识本身带有主观性。由于每个人的观点都不尽相同，如何在观点不一致的情况下找到经济的解决方案，是知识工程面临的根本问题。从爱德华·费根鲍姆（Edward Feigenbaum）40 多年前创立知识工程学科开始，如何降低成本一直是核心问题。机器学习的出现是为了减少手工编写规则的成本，深度学习和自回归方法的发明是为了降低数据标注的成本，而 生成式人工智能的探索则是为了寻找一种更通用、成本更低的知识发现方法。归根结底，所有这些技术的发展都是为了让我们能够以更低的成本从数据中提取知识。

在过去几十年的人工智能实践中，大约 99% 的人工智能项目都以失败告终。我们可以预见，未来大多数项目也将面临同样的命运。那么，什么样的项目更有可能成功呢？长期经验告诉我们，那些"重"的项目，即那些在前期需要大量成本投入而收益不明显的项目，往往容易失败。这是因为每个项目都存在成本和收益的曲线，如果项目在早期就面临漫长而高昂的成本投入，而没有相应的收益，通常很难坚持到收益回报的那一天，相关方的耐心也会逐渐消失。

我们应该采取“小步快跑”的策略，以实践和场景驱动的方式进行工作。这与精益思想是一致的，它强调成本和收益的同步增长。在硅谷的创业理论中，这种增长过程被称为 Lean Startup 循环，即构建、评估、学习（build、measure、learning），形成一个持续的循环过程。在知识工程领域，我们今天也需要采用类似的方法来大幅降低成本，以提高项目成功的可能性。

20 年前的人工智能实践

20 年前，人工智能领域的实践与今天大相径庭。以 Aura 项目为例，这是我亲自观察过的一个项目，虽然我没有直接参与其中，但我对项目中的人员非常熟悉，因此我能够挖掘出一些不为外界所知的内部信息。

Aura 项目本质上可以被视为一个高考项目。在美国，高中生也需要参加高考，而考试的试卷被称为 SAT。项目的目标是使用机器代替人类来完成试卷，参加高考。这个项目是在 20 多年前由微软的创始人之一 Paul Allen 发起的。Paul Allen 因健康原因很早就离开了微软，尽管他的财富不及比尔·盖茨，但仍然拥有数百亿美元。他计划在生前将所有财产用于投资，其中一部分就投向了火箭技术，另一部分则投向了人工智能领域。他在人工智能上投入了大约 10 亿美元，这在 20 年前是一笔相当可观的资金。

Paul Allen 将其中一部分资金投入到了知识工程领域，就是 Aura 项目。Aura 意为"曙光"，而我恰好有一位非常好的朋友在这个项目中担任项目经理。他向我透露了许多实际情况，包括项目中的各个组件，如问答引擎、词汇编辑引擎和逻辑推理引擎等。他们的目标是在名为 Halo Project 的大项目框架下解决科学问题的推理。Halo 项目的核心是进行化学和物理等科学问题的解答，这在当时是一个非常具有挑战性的任务，与今天使用大模型轻松处理这些问题形成鲜明对比。

在 20 年前，我们还没有现在所说的大模型，甚至知识图谱也尚未出现——知识图谱是在 2012 年才发展起来的技术。当时，我们处于语义网时代，进行知识建模的第一步是将知识编写成规则语言。最初使用的是 Prolog 语言，更早之前使用的是 Lisp，随后发展出了 OWL 等规则语言。

对于 Halo 项目来说，他们面临的挑战是对科学知识进行建模，这是一项非常困难的任务。为了解决这个问题，他们采用了一种名为 SILK 的语言，即 Semantic Inferencing on Large Knowledge，这是一种用于大规模知识推理的语言。在这里，"inference"（推理）这个词在不同的上下文中有不同的含义。如今，当我们使用大模型时，可能会将推理理解为一种快速的推导过程，但在当时，推理涉及到复杂的逻辑和计算过程。在 20 年前，人工智能主要依赖两种知识处理方法：演绎推理（deduction inference）和统计推断。演绎推理是一种基于逻辑的推演过程，而统计推断则侧重于数据和概率。

当时，人工智能项目采用了一种非常复杂的架构，将生物学、化学和物理学等知识手动转化为一系列知识规则。这个过程非常昂贵，据估计，将一本书的内容转化为规则可能需要花费数十万美元。这在当时是一个成本极高的事情，涉及使用多种不同的逻辑表达语言。

在拥有了规则语言之后，接下来需要的就是一个推理机。当时推理机是由德克萨斯大学奥斯汀分校开发的。奥斯汀分校在知识表现和推理领域处于全球领先地位。然而，即使拥有这样复杂的技术框架，当时的推理机也只能达到 30% 到 50% 的正确率。相比之下，如果今天使用大模型来进行同样的推理过程，即便没有专业领域的支持，也能达到 60% 到 70% 的正确率。这种显著的提升是时代发展和技术进步所带来的结果。

从反思到进化：大模型时代的知识系统构建

在 2010 年，我对某个项目进行过复盘和思考，现在又过去了 14 年，让我们一起回顾一下在大模型时代，我们构建知识系统的方法，从中分辨哪些是正确的，哪些是错误的。

第一，我们考虑这种方法是否可能扩展到其他领域。按照当时的方法，这是不可能的，但今天通过大模型的方法，由于其通用性，扩展变得很容易。大模型的通用性意味着可以应用于化学、物理、数学、历史等多个领域，而不需要重新编写所有内容。

第二，我们考虑了处理大量数据的能力。当时这是不可能的，但今天已经可以了。

第三，当时使用了受控自然语言（Controlled Natural Language, CNL），而今天，我们不再需要这种语言，自然语言已经足够。

第四，如何更好地利用外部数据，比如链接数据（linked data）。当时没有明确的想法，但今天有了像 GraphRAG 这样的工具，它将知识图谱和大模型结合起来。

第五，如何综合使用多种方法，将规则方法和自然语言处理方法结合起来。当时没有找到很好的方法，但现在生成式模型已经普及。

第六，如何降低综合成本。当时不知道，但现在我们知道了预训练模型和提示工程可以大幅降低成本，至少下降了 100 倍。

第七，关于问答系统。2010 年前后，IBM 的 Watson 系统和 DeepQA 系统是问答领域的佼佼者，但当时还没有人使用深度学习，直到 2012 年深度学习才开始流行。到了 2017 年，我们开始知道如何融合这些技术，而今天，大模型方法已经轻松解决了这个问题。

关于如何结合信息检索方法和基于规则的方法，以及如何解决长尾搜索问题。当时不知道，但现在我们知道了 RAG 加上 Agent 可以解决这些问题。尽管有了统计方法和规则方法，结构化知识仍然不可或缺。

第八，我们考虑了知识图谱的必要性。尽管大模型提高了知识图谱的构建效率，但并没有取代它。

第九，知识建模不能忽略手工方法，知识编辑工具可能是关键。我在这方面的想法有误，但也没有完全错，因为数据生成、提示词交互、结果校验等过程仍然需要人机交互工具。

第十，我们考虑了如何平衡颗粒度和成本。现在我们知道，走向大模型是正确的方向。

从技术角度来看，20 年前的研发工作采用的是瀑布式开发模式，其成本远高于今天大模型的成本，可能高出 100 倍甚至更多。今天，大模型的最大好处在于，我们不需要在系统设计初期就将所有知识固定下来。相反，我们可以在知识使用时，通过数据的预训练和提示工程的交互来实时更新知识，实现全面的迭代。

以前的知识系统构建分为三个步骤：首先用统计方法打基础，然后用规则提高准确度，最后通过编辑过程进行精细化处理。现在，这三个步骤已经发生了变化。统计方法已经演进为大模型，而规则并没有消失，它们以一种新的形式存在。例如，当我们使用像 Coze 或 RAGFlow 这样的 Agent 平台时，编辑流程实际上就是规则，它们将传统规则转化为了工作流，工作流本质上就是规则。

即使大模型的输出准确度达到了 70% 到 80%，但在实际业务场景中，如合同检测，如果准确度没有达到业务人员的要求，他们是不会采用的。因此，为了使大模型的输出结果可用，我们必须做好后处理工作，包括数据交互和数据验证，以提高准确度满足业务需求。

AI 落地的关键：务实的工程实践与基础建设

AI 的落地关键在于工程，而不是单纯的科学或高深莫测的技术。大模型虽然为我们解决了一些基础问题，但它们并非万能的。在实际应用中，我们需要通过迭代和控制成本来解决剩余的问题。例如，即使 AI 系统的准确率达到了 85%，剩下的 15% 不足之处仍可能导致亏损。关键在于如何降低成本，如何提高那最后的 5% 或 10% 的准确率。

工程的本质在于处理细节和解决实际问题。工程的实现并不总是充满光环，它往往涉及枯燥但至关重要的底层系统工作。在工程实践中，我们总会遇到意想不到的问题，这些问题的解决方案可能同样出人意料。要进行有效的工程实践，关键在于关注小事，因为所有的工程成就都是由一系列小细节累积而成的。以瓦特改进蒸汽机为例，他所做的不仅仅是发明，而是通过改进传动机制、密封技术等多个小细节，最终实现了蒸汽机的高效能。同样，在计算机科学和人工智能领域，工程的重要性也不言而喻。

AI 不仅仅是理科，更是工科。工科教育强调实践，例如制作小锤子、操作车床、焊接等，这些都是工程的一部分。编写代码也是工程的一种形式，它需要质量检验、质量控制、多种工具的配合以及公差体系的校正。与机械工程或化学工程相比，软件工程还相当年轻，很多人对工程的真正含义理解不足。我们需要认识到，软件工程也需要遵循工程原则，包括严格的质量控制和精细的工艺流程。这是 AI 领域需要面对和解决的问题。

过去的几年里，人们都在追捧大数据和大模型。然而，无论是大数据还是大模型，核心问题并没有改变：数据清理。 十几年前，有句话说得好，“如果你解决了数据清理问题，就解决了 80% 的机器学习问题”。这个原则在今天依然适用，解决了数据清理问题，也就解决了 80% 的大模型问题。

智能体等技术其实并没有那么复杂。它们都是由一系列枯燥的基础工作构成的，只要这些基础工作做好了，问题也就迎刃而解。我们不应该盲目模仿像 OpenAI 这样的大型组织，使用数万张显卡去训练大模型。因为并不是每个组织都拥有这样的资源，有些可能连 100 张，甚至 10 张显卡都没有。每个组织都应该根据自己的实际情况，采取适合自己的方法。

大模型本质上是从数据中提取的知识，而知识可以被视为“小数据”，它强调的不是规模，而是价值。这里的“小数据”有三个特点：价值（Value）、真实性（Variety）和多能性（Versatility）。

价值，不是连垃圾都存起来，而是特别关心数据的价值密度，提高投入产出比。

真实性关心数据的可验证性，可用性，自描述性等。

多能性意味着知识不应被固定在代码中，而应存在于数据中，能够灵活应用。

大模型是一种知识模型，它代表了一种数据的高级形式，承载了丰富的知识。要实现大模型的有效落地，我们需要从基础做起，务实地处理运维、数据库和数据清洗等基础工作，并逐步演化和优化：

如何按天迭代？

如何构造联调系统？

如何无标注数据启动？

如何分离准确度和召回率要求？

如何统一运用规则和大模型？

如何适应无明确衡量标准的开发？

如何设计可演进的数据模式？

如何提升数据可理解性？

如何逐步提升规则 /Agent flow/RAGFlow 系统的表达力？

如何平衡黑箱和白箱模型的优缺点？

如何在优雅架构和工期间取舍？

所有伟大的成果，之所以能够取得优异的成绩，都是因为一线工程师的辛勤工作。这些成绩并非来自于向领导汇报的表面文章，而是真正在一线发挥作用的扎实工作。这些工作的核心是务实，即所谓的“土”。

回顾过去，2010 年时的知识工程水平大致相当于软件工程的 1940 年代。到了 2017 年，我开始涉足金融领域应用时，软件工程的水平相当于 1950 年代。如今到了 2024 年，我认为知识工程的水平已经发展到了大约 1970 年代的软件工程水平。 在 1970 年代，高级语言 C 语言被发明，而 Python 是在 1992 年左右发明的。我们今天熟悉的许多高级语言，如 Java、PHP 等，大多是 90 年代的产物。当我们审视知识工程领域时，我们发现并没有出现类似 C 语言这样的基础性、革命性的语言。所以说，知识工程领域仍有很大的发展空间，需要我们继续探索和创新。

提示工程，开启知识建模新篇章

提示工程的意义在于它为知识建模提供了一种自然语言的表达方式，这是一种革命性的进步。在金融等专业领域的应用中，传统的知识工程和专家系统方法成本过高，导致如 Aura 和 Halo 这样的系统最终失败。然而，从 2022 年开始，我们找到了一种新的方法，让我们能够享受到软件工程在 70 年代所体验到的便利，那就是声明式编程语言。

在编译原理课程中，我们了解到有两种类型的编程语言：声明式语言和命令式语言。SQL 因其声明性质而广受欢迎，而直接使用机器码则是一种典型的命令式编程。在知识建模方面，我们之前使用的如 SILK、OWL 或 RDF 等语言，可以看作是接近机器语言的低级语言。我们一直在寻找一种过渡，一种对人类更友好的知识建模语言。

过去，人们尝试使用受控自然语言（CNL）如 Aura 项目，但效果并不理想。而提示工程的出现，使我们能够直接使用自然语言进行交互，这是非常神奇的，也是提示工程的核心价值所在。

企业级信息系统架构经过多年的发展，从 OA 系统到大数据、互联网、数据湖、数据中台等，其核心主线始终围绕着如何让机器自动理解多源异构的分布式数据，以及如何将分散在不同员工大脑中的知识集中起来，使公司管理者能够掌控全局。数字化转型的本质在于打破组织内的数据边界，让知识流动起来，成为组织的资产。

基于大模型的新范式：无代码，无标注，强泛化

大模型带来了一种新的范式，它具有无代码、无标注和强泛化的特点，这在以前是难以想象的。大模型的核心作用在于显著降低了开发和应用的成本。

在过去，要实现特定的业务流程，比如与券商合作时，我们需要构建底层数据仓库，然后开发各种自动化系统，包括自动化写作、核查、问答和大屏展示等。这些系统往往各不相同，需要大量的定制化开发。大模型的出现使得我们可以有一个统一的基础平台来实现所有这些功能，而且不需要在设计阶段就将所有的业务知识全部预设进去。知识可以在使用过程中不断演化和完善。这种能力在以前是不存在的，它相当于将我们带到了一个新的境界。到了 2022 年，我们发现大模型真的可以实现这样的功能，这确实是一次世界观的颠覆。我们意识到，技术的发展可以如此之快，可以以这样一种全新的方式解决问题，是具有革命意义的。

面向知识的编程，破解第三次软件危机？

我也认为，大模型的出现解决了所谓的第三次软件危机。回顾历史，第一次软件危机大约发生在 50 年前，当时的问题集中在无结构的 GOTO 语句上。随后，数据结构的引入帮助我们解决了这个问题，我们学会了将程序视为数据结构和算法的结合。

第二次软件危机则是面向对象编程 (OOP) 和互联网的兴起，这可以看作是面向对象的扩展，因为互联网编程很大程度上是以数据库为中心的。

近十年来，我们面临第三次软件危机：软件变得极其复杂和高度分布式。例如，在 Web 领域中，智能合约的出现代表了一种新的软件工程形式。在银行等金融机构，进行数据中台建设和数字化转型的过程中，许多人感受到了图数据库的矛盾——既觉得它有用，又觉得它的表达能力受限，给人一种“食之无味，弃之可惜”的感觉。这种矛盾体现了当前软件工程方法与应用需求之间的脱节。

我认为第三次软件危机的解决方案是一种新的编程范式——面向知识的编程（Knowledge Oriented Programming, KOP）。在这个范式中，编程的核心是推理(Reasoning)和知识库(Knowledge Base)，这可以看作是现代版的算法和数据结构。这里的知识库就是大模型，大模型的推理能力，不同于传统的推演 (Deduction)，是一种新的推理方式。大模型作为知识库，本质上承载的是知识而不仅仅是数据集。

这个核心的范式与传统的软件开发方法有显著的区别。传统方式，比如 Aura 项目的 style，采用的是瀑布模型。在这个模型中，首先定义好数据的 schema，然后业务规则也是事先设定好的。以 Aura 为例，它需要事先确定如何进行物理或化学的考试，这些业务知识是预先定义的，用户界面 (UI) 也是固定不变的。这种方式是传统的业务分析方法，也是瀑布式开发方式，它要求预先设定好所有要素。

我们理想中的另一种范式是端到端范式。在 2022 年到 2023 年上半年，许多人开始尝试使用大模型进行端到端的开发，希望把所有的数据输入到模型中，然后期待模型能够神奇地解决所有问题。 这种方法的想法是，不再需要重新定义 schema，不需要构建知识图谱，所有的中间过程都可以是多模态的，从图像到文本到语音、OCR、PDF 等都能一次性处理完毕。

但实践中发现，端到端的方式行不通。以金融领域为例，它面临的问题包括准确度不可靠——例如，深交所的公告处理系统要求 99.99% 的准确度，这在当前是任何大模型都无法达到的。此外，生成式模型缺乏幂等性，即相同的输入不能保证每次都得到相同的输出。还有处理速度慢和成本高的问题，例如原本 20 分钟完成的 IPO 审核任务，如果使用大模型可能一天也完成不了。

端到端模式在实践中被证明是不可取的。尽管我们相信，如果未来的硬件成本大幅降低，或者相关的技术平台有显著进步，端到端模式可能会变得可行，但至少在目前，这种方式是不现实的。

提示工程的系统化构建

我们需要实现一种称为“活的业务分析”的系统范式来进行知识建模。这种范式的核心在于数据本身应该是动态的，即数据抽取应该基于提示工程。业务分析过程也应该基于提示工程，这意味着数据产生、schema 定义以及业务规则的生成都应该是即时的（Just In Time, JIT）。

最终，这些即时产生的元素结合起来形成一个应用系统，这个系统本身也最好是即时构建的。目前，许多公司正在开发基于对话的商业智能（Conversational BI），其本质是设计一种“活”的用户界面（UI）。

提示工程本质上是软件工程的一部分。编写提示词也是软件工程活动，而不仅仅是编写 Python 代码。未来可能会出现一个专门的提示工程专业，并有专门的集成开发环境（IDE）来支持这项工作。提示工程应该有其自身的复杂业务逻辑和质量控制系统。

这也符合精益开发的流程，遵循 learn-build-measure 的循环模式，这里的 measure 指的是对构建出的系统或产品进行广泛的评估和测试。基于评估结果，我们进一步进行优化，然后再返回到构建阶段，形成一个持续的循环。

在没有实际执行之前，人们可能会对大模型的工作方式有一种“你以为”的理解，但真正参与到工程落地系统后，会发现整个过程极其复杂。我们开发了一种可行的提示词设计方法论，称为 S2PI 方法论，它包含四个要点。

Schema（结构）：虽然我们不要求事先定义完整结构，但在大多数问题中，仍然存在一些固定的数据要素。因此，我们需要根据特定场景设计提示词的基本结构。

Supplement（补充）：在基础架构的基础上，根据特定场景增加背景信息。这些背景信息可能包括正样本、负样本，或是关键架构要素的变化形式。在软件工程中，我们通过回归测试来确保质量，而在提示工程中，设计各种补充信息的过程实际上就是在构建测试集和引导集。

Property（属性）：涉及与特定领域（如金融）相关的属性和术语。从工程角度来看，这类似于设计实体关系（ER）图。

Input（输入）：在使用时刻，根据设计阶段的架构和补充信息，确定所需的具体输入。工业级别的提示词设计不是简单的民用级别，而是一个复杂的过程。

我们还专门开发了一项技术，称为“提示词编译”。S2PI 方法论设计出的提示词是一种高度技术化的语言，普通人难以理解。因此，我们设计了一些 Agent，它们能够将普通人能理解的提示词翻译成更底层、专业的提示词。

综合案例 1：基于提示工程的文本抽取

在讨论基于提示工程的文本抽取时，我们首先需要理解 JIT 数据生成的重要性。以三个大型交易所的审核系统为例，这些系统负责从厚重的招股书中抽取数据，这涉及到大量自然语言处理技术。从 2023 年开始，我们交付给交易所的新一代系统都采用了大模型技术。

在这个过程中，有很多关键的技术细节。例如，情境学习需要定义各种角色，但角色数量的确定是一个问题。一个招股书包含 1 万多个数据点，2400 个不重复的 schema 和 94 个章节，这是否意味着需要定义 94 个 Agent？这仅仅是针对招股书一种文档类型，还有债券募集说明书、IBS 专项说明书、定调报告、评级报告、征信报告、资管合同等其他文档类型，以及底层资产类型如 ABS、中票、短融、公司债、企业债、利率债等，构成了一个庞大的矩阵。在输入 PDF 文件进行抽取时，需要进行 PDF 解析，确保每个章节、每个段落在抽取时获得适当的辅助信息（supplement 信息）。例如，为公告增加分类信息可以显著提高准确率。通过改变提示词，将提取结构化信息的机器人转变为专业提取董事会决议的模型，可以在四种公告上分别提高 3% 到 8% 的准确率。

我们还发现了一些技巧，比如在输出时要求不要有幻觉，结果真的降低了幻觉的出现。通过给每个公告增加例子和分类，可以进一步提高准确度 3.85% 到 3.87%。我们尝试了各种方法，仅在提示工程层面上所做的工作就提高了 13.8% 的准确度。

最令人惊讶的是，所有这些工作并不是由传统的软件工程师完成的，而是由一个提示工程实验室完成的，实验室的成员平均年龄 23 岁以下，很多是 00 后文科生，财经专业毕业生或在校生，甚至实习生，能够写中文并具备逻辑思维能力，就能实现这样的成果。这表明 提示工程极大地降低了技术门槛，使得非传统意义上的工程师也能参与到优化工作中来。开源系统和闭源系统我们都使用过，效果相当，到目前为止，我们并没有看到闭源系统明显优于开源系统。

综合案例 2：基于提示工程的业务建模

案例 2 我分享的是如何利用提示工程进行业务建模，尤其是在金融系统中。金融系统包含众多规则，包括财务规则、法务规则、核查规则以及业务流程管理（BPM）规则等。核心问题是如何降低业务建模的成本，使其不需要程序员编写，而是可以由 23 岁的文科生完成。

在大模型出现之前，业务建模遵循的是瀑布式开发流程。业务分析师，通常是金融专业出身，会手工整理业务规则，这些规则基于他们对原始业务文件的深入分析。然后，这些业务规则会转化为产品需求文档（PRD），再传递给产品工程师和软件工程师，整个过程耗时较长。

现在，我们的目标是利用业务规则自动生成底层提示词及其效果，实践表明这种方法大约有 85% 的可用性，剩余的 15% 可以通过其他方法解决。更进一步，我们尝试不依赖人工理解业务逻辑，而是通过给系统输入 20 份文档，让它自行整理出业务规则。经过两个月的实验，目前这种方法是可行的，预计到年底可以更加完善。

在金融领域，核查系统已经从静态变为动态。金融业务逻辑处理的核心是将业务知识进行建模。与过去的方法相比，现在的方法大幅降低了成本，原因在于我们不再需要在设计阶段做大量前期工作，从而使系统上线后难以演化。大模型的最大价值在于赋予了系统强大的可演化性。提示工程已经替代了大量的传统软件工程任务。尽管这种实践才一年多时间，但随着时间的推移，我们可以预见到提示工程和大模型在未来将有更强大的应用出现。

嘉宾介绍

鲍捷博士，文因互联董事长、首席科学家、创始人。爱荷华州立大学（Iowa State University）博士。曾任伦斯勒理工学院（RPI）博士后，麻省理工学院（MIT）分布式信息组（DIG）访问研究员，三星美国研发中心研究员，W3C OWL(Web 本体语言) 工作组成员，参与撰写了 OWL2 知识图谱语言国际标准。现任 W3C（万维网联盟）顾问委员会委员、中国中文信息学会语言与知识计算专业委员会委员、金融知识图谱工作组主席、中文开放知识图谱联盟 (OpenKG) 发起人之一，国际 Data Intelligence 杂志编委，中国科学技术大学国际金融学院业界导师。

内容推荐

大会 PPT 获取通道已开启，关注数字化经纬公众号，后台回复“PPT”，即可获取 PPT 下载地址（由于讲师所在企业限制，部分 PPT 仍在审查或不对外公布，详情见大会官网日程）>>>