京东、理想都在建本体，为什么真正难题却出现在上线后？- 大数跨境

DataFunSummit

2026-10-20

导读：为什么需要本体？该从哪里开始建？做出来究竟有没有用？业务变了，又该怎样更新？

导读10月14日，DataFun创始人王大川主持了一场关于本体的圆桌讨论。开场时，他提到一个变化：去年谈起本体，不少人还觉得是“新瓶装旧酒”；到了今年，相关讨论没有随着热度过去而减少，反而持续升温。企业开始让Agent接入真实业务后，过去可以留在概念层面的问题，逐渐变成了实际的工程问题：为什么需要本体？该从哪里开始建？做出来究竟有没有用？业务变了，又该怎样更新？

参与讨论的四位嘉宾是云器科技联合创始人兼CTO关涛、京东零售算法总监周默、理想汽车企业智能算法研发负责人张升涛，以及OceanBase本体平台研发负责人郭文龙。四位嘉宾分别从数据平台、用户增长、企业智能和Data Agent产品的实践出发，围绕王大川提出的四个问题，谈到了各自走过的路线、遇到的困难，以及仍在探索的部分。

主要内容包括以下几个部分：

1. 你们从什么时候开始真正接受本体？

2. 接受本体之后，第一套到底怎么建？

3. 本体建出来了，怎么证明它真的有效？

4. 上线之后知识一直在变，怎么让本体“保鲜”？

你们从什么时候开始真正接受本体？

王大川：去年大家谈本体时，还有不少质疑，觉得这是不是又一个被包装出来的概念。但从今年第二季度开始，我感觉讨论越来越多。你们各自是什么时候开始接受本体的？有没有一个真正说服自己的过程？

关涛：我在数据平台领域做了二十多年。最早接触图建模的时候，其实并不看好它会成为主流。我们熟悉的数据平台，主要还是围绕关系模型和SQL构建的。在微软、阿里工作时，我们也研究过图模型，几乎每家云厂商都有相关产品，但从当时的市场表现看，它始终只占很小一部分。所以很长一段时间，我的判断都是：图模型可以解决一些特定问题，却未必能成为普遍采用的建模方式。

后来Palantir让我重新思考了这件事。它以本体为核心，在一些高价值的企业场景里做出了结果。我当时反过来问自己：如果这个方法这么有价值，为什么Google等拥有大量数据和技术能力的大公司，没有把它更广泛地用起来？我觉得关键还是成本。图模型要定义对象、属性、关系，还要维护这些定义，整个过程都很重。比如在军工场景里，一架飞机本身价值很高，专门为它建立对象模型、持续维护属性，是可以投入的；但互联网企业面对的可能是几亿甚至更多用户，沿用同样的方式，建模成本就会非常高。Palantir在一些项目里也需要投入相当多的专家力量。

大模型出现以后，我才开始改变这个判断。过去很难靠程序完成的工作，比如应该识别哪些对象、怎样建立关系，AI现在能够参与，原本需要大量人工处理的环节有机会降低成本。与此同时，Agent又成了知识的使用者。我们做ChatBI就经常遇到这种情况：表已经接上了，模型也会生成SQL，可用户问的是业务问题，底下的数据却只有表名、字段名和技术口径。两者之间缺少能够让模型理解的业务语义，再强的模型也容易选错数据。

以前做大数据，我们主要把数据加工成信息。大概两年前，我们开始花更多精力思考，能不能进一步把信息加工成知识，再让AI利用知识完成任务。一个变化发生在知识的生产侧，AI有机会把成本降下来；另一个变化发生在使用侧，AI开始大量需要这样的知识。正是这两个变化，让我重新考虑本体能否走向更广泛的企业场景。

周默：我接触得晚一点。去年年底，京东内部的数仓、大数据团队已经在探索本体，我参加过一些讨论，但当时理解还不深，也没有认定一定要做。因为我的工作一直围绕用户增长，我更在意的是业务里的问题能不能解决。

今年五一前后，我们接到一个内部智能分析的需求，希望业务同学能直接问用户增长相关的问题，比如不同人群表现怎么样、会员有什么变化、哪些环节出现了问题。当时模型能力、Agent编排工具、上下文工程这些条件都具备了，我原以为做出来不会太难。真正运行之后才发现，回答不够稳定，有时还会出现幻觉。做一个演示，偶尔答错可以继续调；但这些分析结果是要拿给业务负责人做决策的，一旦判断错了，影响就不一样。

我们起初没敢直接上本体。因为知道建模投入很大，就先采用了一个相对笨的办法：在数仓外面用代码封装业务逻辑，再准备一批模板，让模型尽量沿着固定路径回答。第一版交付以后，业务反馈还不错，但很快就发现，这样做主要靠人工提前把各种情况处理好。换一个问题、增加一个场景，又要重新补一层代码和模板，很难复制。

后来有一天晚上，我拿着这个问题和大模型反复讨论，它建议我试试本体。我又做了一轮梳理，最后决定围绕用户增长尝试构建User Growth Ontology。这个过程有点偶然。我们不是先认定本体是答案，再去找一个场景，而是眼前的办法已经能用，却始终解决不了可复制性的问题。

王大川追问：这点还挺反常识。大家常提到的本体案例，多在供应链、制造等相对稳定的领域。用户增长变化非常快，你为什么还认为它适合？

周默：增长业务变化确实快，但我们也有长期积累的策略、数据和实验结果。还有一点很重要：我们最终想做的不只是让Agent给出分析结论，还希望它能调用业务系统，去执行一些增长动作。对象、属性和关系之外，本体里的Action能力对我们特别重要。具体怎么做，可以放到建模的问题里再讲。

张升涛：我第一次接触本体要更早，大概在2015年前后做广告推荐算法的时候。那时大家已经开始做知识图谱，本体通常和知识图谱放在一起讨论，很少被单独拿出来。我们也知道它有价值，但建模成本高，建好之后怎么使用、怎样把知识提供给模型，问题都没有得到很好的解决。

真正让我们重新研究它，是2023年开始探索Data Agent之后。最初的想法是通过Prompt调优，先把取数做准。因为取数一旦错了，后面的分析、归因就没有基础。那时经常碰到一个情况：Demo做出来了，看上去能够回答，但有些答案是模型编出来的，我们不敢直接把它交给业务做决策。

后来又试过把业务知识内化到模型中，通过标注、训练或者微调，让模型掌握特定领域的规则。聚焦到一个场景时，这种方法可以取得一定效果，但成本非常高。行业专家连续标注两三周，可能也就整理出一两千条数据。模型上线后，只要业务口径一变，还得重新准备训练材料。问题不在于模型不能学，而是企业里的知识一直在变化。

因此，我们逐渐改为把业务知识放在模型外部，让Agent在执行任务时使用。这样至少有两个好处：一是把业务专家脑子里那些说不完整、写不清楚的经验，整理成模型能够重复使用的知识；二是业务规则调整后，可以先修改外部知识，不必每次都去改模型。当然，走到这一步又会遇到新问题：本体如何构建，能不能自动化，又怎样跟着业务持续更新？

郭文龙：我们和张升涛老师的路径很接近。OceanBase是数据库厂商，我们做Data Agent产品，最初最关心的是问数准确率。在探索过程中，我们先验证了传统语义层的作用：把数据背后的业务概念、指标含义和表间关系整理清楚，模型的回答确实会更可靠。

但从2025年底到2026年，客户对Agent的期待也提高了。以前可能只问“发生了什么”，后来还要追问“为什么发生”，再往下希望得到“应该怎么办”的建议，甚至希望Agent能辅助执行。如果要走完这一整段业务流程，只靠给表和字段补充语义解释，就显得不够了。

我们开始调研其他方案，看到Palantir围绕本体组织结构化、非结构化数据，并把Action纳入业务描述时，发现这恰好与我们的目标比较接近。随后，我们把之前做语义加工的经验用到本体上，在自己的业务场景里验证。除了问数，我们看到它还能够支持较复杂的业务归因和分析，这才决定继续往下做。

接受本体之后，第一套到底怎么建？

王大川：听下来，大家接受本体的原因并不一样。但接受这个概念之后，怎么真正把它建出来？最初做了哪些调研和尝试，有没有走过弯路？

周默：我先说一个前提：没有一套适用于所有公司的本体建模方法。对我们团队来说，它和以前做过的DDD，也就是领域驱动设计，有一些相通之处，都需要把业务里的对象和关系抽象出来。但具体怎么抽象，一定得从自己的业务出发。我们过去在京东内部做过相关改造，后来发现，这反而成为本体建设的基础。

为什么用户增长会考虑本体？因为我们的业务不只是查询。广告系统、优惠券权益系统、消息触达系统，以及各种外部合作系统，最终都需要执行动作。传统知识图谱更多是在描述实体和关系，提供查询能力。我们关注的本体除了对象、属性、连接，还包括Action，可以进一步把业务动作和相关系统联系起来。回答“哪类人群表现好”，与根据分析结果进一步组织、执行一场增长实验，是两件不同的事。

但要走到第二步，得先把原有业务整理清楚。我们从2020年开始做用户增长，积累了很多策略、数据和实验结果。以前不少运营任务通过低代码的策略画布完成：业务同学配置人群、权益、利益点、触达渠道，拼成一张画布，就形成了一套策略。问题是，策略越来越复杂，画布也越来越大。一个同学离职，接手的人可能连应该改哪一段都不清楚，线上一些运营事故也和这种复杂性有关。

我们最初做的，是把过去画布里积累的业务规则、操作经验和实验知识梳理出来，形成可以复用的知识，再讨论哪些是对象、哪些是属性、哪些属于关系和动作。我并不认为给大模型一句话，它就能自动建出一套可靠的本体。没有长期积累的业务知识和数据，再好的建模方法也很难落地。

组织也很关键。对我们来说，本体建设更接近业务运营项目，而不只是技术人员做数据治理。运营、产品、研发需要在一个团队里，对人群、策略、实验以及结果采用共同的语言。技术人员再懂模型，如果不了解一条运营规则为什么这样设定，就很难把它准确整理出来，更谈不上长期维护。

我们希望最终做成一个用户增长引擎，让Agent能够提出策略、执行增长实验，把正面和负面的实验结果都沉淀为知识，然后继续调整下一轮策略。理想状态是尽量减少人工值守。不过这还是我们要逐步实现的目标，不能把正在探索的过程说成已经全部完成。

王大川追问：你刚才说，适合做本体的团队要有“可信数据”。这里的可信数据，主要是指积累下来的经验和知识吗？

周默：不完全是。经验是其中一部分，真实实验结果同样重要。比如投入了多少钱、转化了多少人、某个策略到底带来了多大的增量，这些事实再强的模型也推不出来，必须真正做过实验才知道。我们还需要统一A/B实验的口径、统一衡量增量的方法。只有知道过去做了什么、得到什么结果，才能让Agent继续判断下一个动作是否值得做。这部分积累对我们非常重要。

张升涛：我们真正开始落地时，遇到两堵墙。一堵是本体怎么建、怎么维护；另一堵是建完以后如何证明它有效。先说建模。我们最初做过一套本体管理系统，让专家按照模板填写业务实体、实体之间的关系和具体逻辑，希望把已有知识整理下来。

但做起来发现，任何一个专家都很难在开始时就把所有细节讲清楚。数据来源复杂、业务领域很多，同一个领域的规则也会不断变化。我们研究过一些自动建模论文，但论文里的方法往往是在相对特定的场景里验证的。到了生产环境，数据种类、数量和业务边界都复杂得多，不能原样照搬。

后来我们尝试在每个垂直领域使用建模Agent，让模型先根据已有的数据和材料抽取实体、关系及业务规则。初步抽取完成以后，再由专家校验，必要时进行多轮检查，确认后才上线。涉及敏感数据时，要先做好脱敏，或者使用内部模型。我们希望模型承担大量重复性的整理工作，把专家的精力留给那些真正需要业务判断的地方。

另外，范围一定要控制住。比如销售领域提出一个需求，我们就从这个需求开始，找出相关的数据表、资产和关系，只建当前任务真正需要的部分。那些暂时用不到的表，不必因为它们存在就一并建进来。先把一个小场景做扎实，再逐渐连接其他领域，比一开始就投入建设覆盖全公司的大本体库更可行。

我们也在考虑下一步本体怎样和不同模型配合：复杂的问题由推理模型处理，比较明确的分类、评分和路由判断，可以研究使用偏决策型的模型；本体为不同模型提供统一的业务语义。包括System 1、System 2与本体结合的思路，目前还在探索，没有把它当作已经确定的方案。

王大川追问：你们现在有没有把不同业务域的本体连接起来？如果最后要面向全公司使用，总要走到跨域这一步。

张升涛：有这方面的工作，我们是两条线并行。一条线围绕具体需求，把一个场景里的问题做透；另一条线研究不同领域之间如何连接，同时还要考虑本体驱动的Agent系统与原有系统怎样兼容、切换。我们更希望先把眼前场景做明白，再一点点往外扩展。

郭文龙：我们也是从人工建模开始的。当时选择了OceanBase内部的成本分析场景，找来既了解成本业务、也了解本体的同学做模型。即使同时具备这两方面的知识，完成一套比较准确的本体结构，还是花了大约两周。

对一个验证项目来说，两周也许可以接受，但我们的产品要交给客户使用。如果每个客户都得先找一个既懂自己业务、又懂本体的人，再花很长时间建模，产品的使用门槛就太高了。所以我们后来把人工建模的经验整理成一套方法，结合大模型的推理能力，让系统先构建本体，再由专家负责审核：实体有没有抽错，关系是否完整，业务规则还缺哪些内容。

而且建模不是一次完成的。第一版能够使用，只说明有了一个起点。后续用户问数、分析时，仍然可能发现遗漏或错误。我们会把这些问答和反馈回流到构建系统中，让本体继续完善。相关工具是基于已有Data Agent产品自研出来的，也是实际客户不断提出的问题，推动了我们继续做这项能力。

王大川追问：这套自动构建能力是你们完全自研的？现在已经在客户实际使用中发挥作用了吗？

郭文龙：是自研的。之所以会做，也是因为产品交到客户手里以后，对方首先就会问：“本体应该从哪儿开始建？”如果平台不能协助客户完成这一步，即使后面有很多功能，客户也很难真正用起来。

关涛：我们早期走的是另一条路。我一直觉得，知识可以有多种表达方式。关系表是一种，图和本体是一种，文档也可以是一种。既然大模型能够理解自然语言，那能不能不做太多显式建模，直接把业务文档整理好，让Agent读取和使用？

最初我们参考了Claude使用Markdown文件组织信息的方式。对于个人助手，这很自然：把信息写成文档，Agent需要时召回相关片段，放进上下文里理解。我们也尝试把客户的业务说明、指标解释、表关系等整理成Markdown，希望Agent通过文档检索就能完成ChatBI，甚至做一些归因分析。

真正让我们改变路线的是一次项目测试。我们和一家头部互联网公司合作，对方的文档整理得已经非常好，还使用AI做过加工。但直接让Agent基于文档问数，准确率仍然只有大约50%—60%。问题就来了：文档已经足够清楚，为什么问数效果还是上不去？什么样的知识才能算真正适合AI使用？

我们后来想到数据仓库的加工过程。做数仓时，原始日志进入ODS层之后，通常还要继续做DWD、ADS等层次的加工，最后才交给分析系统使用。知识是不是也需要这样一条生产流水线？我们把Markdown等文档作为原始输入，让模型提取业务概念，归并相似定义，整理实体、属性、表间关系，再通过判断、验证和必要的人工确认，形成结构化的语义表达。真正问数时，先检索经过建模的语义，找不到再回到原始文档做第二层检索。

在前面提到的客户项目中，这样处理后，问数准确率从约50%—60%提高到了90%以上。我们还观察到检索效率和速度有所改善，Token消耗也减少了。最初我也觉得奇怪：数据源并没有增加，反而经过抽取、蒸馏，信息可能变少了，为什么结果会更好？

后来分析发现，以前Agent一次要做太多事。比如用户问某个产品的GMV，模型既要识别这个GMV对应哪一个指标口径，又要从文档中找解释；如果检索出来三种看起来都合理的定义，它还得自行选择。接下来还要找表、生成SQL、执行查询和分析。模型可能不是因为拿到的信息太少才出错，而是相似信息太多，在某个环节选错了。

知识蒸馏相当于把这些判断中的一部分提前做了。生产知识时，可以把相似概念逐一抽取、归并、比较，必要时用多轮判断或投票；确实无法确认的，再交给人校验。到了消费侧，Agent看到的是已经整理好的业务语义，不必在每次回答时从头辨认一遍。我们把这一套称为知识工程：它和数据工程一样，需要抽取、加工、验证、上线和版本管理，只是处理对象从原始数据变成了知识。

本体建出来了，怎么证明它真的有效？

王大川：建出来之后，大家怎么判断本体在一个场景里起作用了？不能只说模型能回答问题，还得有办法评测，也得让业务方认可。

张升涛：这个问题很难只用一个技术指标回答。我们会先明确几条原则。本体要从业务需求出发，不能因为技术热门，就拿着锤子到处找钉子。建好以后，要看它有没有真正进入业务流程，能不能支持持续的业务使用。还有一点：当业务知识变化时，我们希望主要通过更新本体来响应，而不是每次都修改Agent底层的Runtime、Harness或者工作流代码。

再往下才是量化。我们除了评估本体本身的质量，还要知道它在一项任务里究竟起了什么作用。比如某个Agent的结果变好了，是模型本身进步了，还是本体提供的关系、规则起了作用？我们需要设计Benchmark，通过消融实验来区分：拿掉某部分知识或者改变某种建模方式，任务结果会有什么变化，这样才能判断本体在哪一个环节贡献了价值。

评测也要区分结果和过程。结果评估比较直接，看最终任务是否完成。过程评估则要沿着轨迹检查：模型召回了哪些对象、关系、规则，上下文里是否混入了不必要的知识，某一步如果判断错了，后面的错误会不会继续累积。一个任务最终做对了，也可能只是某一步碰巧选对，并不能说明整条路径可靠。所以我们也在研究使用评估Agent，针对具体执行环节做检查，再把发现的问题回流到系统里。

王大川追问：能不能再给大家透露一些已经落地的数字？

张升涛：具体数字现在不方便披露。我们已经在内部一些小场景里打通了工作流程，例如数据开发、集群以及部分线上任务管理相关的操作。以前谈Data Agent，大家更多关注如何查询、分析和归因；数据管理同样有大量工作可以探索。但它非常复杂，所以我们现在也是先把一个小场景做通，再看能不能迁移到其他任务。不能因为某个点验证成功，就认为所有相关工作都能交给Agent。

郭文龙：我们会把本体放在一个具体的MVP业务场景里，看使用前后究竟发生了什么变化。比如成本分析，传统语义层已经能帮助Agent回答成本数据发生了什么变化，但再往下问“为什么”，模型有时会根据预训练知识生成一套听起来合理的解释，却没有沿着真实业务数据去核实。业务人员看完这样的分析，并不知道该采取什么措施。

我们引入本体，就是希望Agent能够沿着业务对象和关系来归因。假设用户问“成本增长了20%，原因是什么”，它就需要进一步检查：是云上的资源成本增加，是开发资源没有释放，还是某个客户的业务增长带来了更多消耗？这里的20%是举例，不是实际公布的优化指标。我们看重的是，Agent能否给出可追溯的分析路径，让业务人员知道结论来自哪些数据，随后采取措施，再验证结果是否符合预期。

所以我们评价本体，会结合这些问题一起看：答案是否比以前更可靠？归因路径能不能追溯？发生错误时能不能定位到相关对象和关系？业务人员能不能根据结果行动，行动以后有没有达到预期？如果只看问答准确率，就还没有完整回答它对业务是否有用。

王大川追问：这里还有一个大家很关心的问题。传统语义层和本体语义层到底差在哪里？能不能结合你们的场景再解释一下？

郭文龙：我倾向于把它们看成两种语义建模方式。传统语义层通常从数据结构出发，为表、字段和指标补充业务描述；本体更强调从业务对象出发，再把底层数据组织起来。比如业务人员说的“一个用户”，在数据库里可能分散在用户简表、详情表和其他系统中，有时需要Join好几张表，甚至需要Union不同来源的数据，才还原出这个业务对象。

如果模型只看表，它就得自己判断哪些表合起来才代表业务上的这个用户。本体希望先把“用户”这个对象定义清楚，再关联它有哪些属性、与哪些对象有关系、可以执行哪些动作。这样，底层怎么拆表、怎么关联，就不必每次都由Agent从头摸索。

企业知识也不只在结构化表里，文档、API、业务规则和其他资料里都有。传统方法往往需要模型分别去语义层、知识库和工具描述里找，再临时拼接起来。我们希望通过本体提供相对统一的业务语言，让模型更容易理解这些资产之间的联系。至于具体要覆盖到什么程度，仍然要看场景和系统设计。

关涛：我想补充一下“跑通”这个说法。以前我们写确定性的程序，或者做SQL Pipeline，可以先定好测试用例，测试通过了，就认为这一版交付完成。但知识和模型输出具有概率性，业务知识还会变化。今天某项测试达到了90%的准确率，并不意味着过几天还会是90%，所以它很难有一个一次性、永久成立的“跑通”状态。

我们现在更重视持续Evaluation。上线以后，要能够观察Agent的输出、它使用了哪些知识、执行过程中发生了什么，再针对不同环节建立Evaluator。有些评估可以用程序完成，有些需要模型判断。每个评估器聚焦一个问题，把结果作为反馈送回系统。过去讲TDD，也就是测试驱动开发；现在我们也在思考，是否要更多转向围绕评估不断调整的开发方式。对于可以控制风险的场景，可以先逐步上线，再持续测、持续改，而不是认为做完一次验收就结束了。

周默：我们在问数、分析报告上也会看准确率、结论是否被业务采纳。但用户增长还有一类很重要的产物，就是策略。策略可以理解为一段能够表达、能够执行的业务逻辑，有点像SQL。它语法没错、能够执行，并不能证明策略本身有效。

增长业务天然有A/B实验体系。我们可以让本体或Agent生成一套策略，同时拿人工制定的策略、传统算法生成的策略来比较，在同样的实验条件下，看哪一种真正带来了增量。这里关注的是投入和转化，是实实在在的业务结果。未来即使把增长实验做成Agent Loop，验证的基础也不会改变。对我们来说，本体只是实现目标的一种技术手段，最后还是要看它是否真正解决了增长问题。

上线之后知识一直在变，怎么让本体“保鲜”？

王大川：还有最后一个问题。本体建好以后，业务规则会变，知识可能过期。怎样知道哪条知识失效了？发现问题以后，又该由谁去更新？

周默：我们前段时间专门做过一个知识保鲜的内部项目。我把这件事分成三部分：先检查知识是否完整，再判断哪些已经失效，最后找到真正能够补充新知识的人。

完备性不能只看已经积累了多少条知识。用户增长有一组比较明确的业务维度，比如人群、权益、渠道、触达时机和触点。不同维度组合起来，会形成大量策略场景。我们希望能用这套组合框架去检查，哪些情况已有经验、哪些还没有覆盖，知道缺口在哪里，而不是只是不断往知识库里加内容。

第二是沙盒能力。我们希望在沙盒中验证已有知识是否还适用，判断哪些规则已经过期、哪些需要更新，不必完全依赖人工定期逐条检查。

第三点更难。系统即便发现某条知识不再有效，也不代表它知道新的规则。用户增长里的活动、权益、合作方策略经常调整，真正知道变化的人，可能是某个运营负责人，也可能是其他业务团队或者合作伙伴。所以我们希望结合业务系统做知识溯源，找到最可能掌握这项知识的Owner，再通过邀约、协作等方式让他把新知识补充进来。与其让模型自己编一个替代答案，不如先找到真正知道情况的人。有关完备性检查和溯源的方法，我们还在继续做。

张升涛：我赞同人仍然需要参与。Agent上线只是开始，后续真正变化的往往是业务知识。业务目标由人制定，哪些知识可以上线、哪些规则应该更新，目前也不适合完全交给模型决定。不过人的工作不一定要覆盖所有环节，很多重复性的检查可以自动完成。

我们的一个办法是分析线上轨迹。Agent执行任务时到底召回了哪些实体、关系和规则？用户有没有修改它的结果？哪些任务没完成？还有一种情况，即使这一次执行成功，轨迹里也可能存在低置信度的判断，下一次换个问题就可能出错。这类案例不能因为最终结果看上去正确，就完全忽略。

轨迹收集起来以后，可以让模型先做检查，再让多个Agent或不同模型交叉校验。当它们对同一条轨迹、同一个知识判断出现分歧时，就把这样的案例交给专家。这样专家只需要集中处理不确定性比较高的部分。等轨迹积累得足够多，还可能进一步沉淀出高质量数据，用于后续模型改进。但前提是先把线上观测、评估和反馈机制建立起来。

郭文龙：我们主要考虑两件事：一是回流，二是促进使用。知识如果长期不被使用，人就不太容易发现它是不是已经过时，也少了被校验的机会。相反，Agent被持续使用，我们就能看到哪些知识被调用、哪些问答或分析出错、用户有没有修改结果，再把这些正确案例、错误案例和调用路径回流到本体构建系统中。

另一个方向是跨领域使用。我们同样从垂直场景开始，先构建、使用和验证，再考虑把适合共享的知识融合到更大范围。其他业务团队可以订阅已有知识，使用过程中又产生新的反馈。这样一来，知识不再只由最初建模的那几个人维护，而是在更多业务使用的过程中持续得到检查和补充。我们希望通过这种使用与回流，让本体保持更新。

关涛：我觉得还可以把保鲜拆成两个过程：知识生产，以及知识确认和上线。生产环节应该尽量自动化。无论从原始文档中蒸馏，还是从用户反馈中发现新的描述，都可以先交给模型整理，形成候选知识。否则一旦所有工作又要专家从头做一遍，成本问题就回来了。

但候选知识能不能进入正式知识库，不能完全按同样的办法处理。比如一个ChatBI系统，数据开发人员先把知识库建立起来，业务同学开始使用后，可能会反馈：“这个指标口径不对”“不应该查这张表”“应该换另一张表”。这样的反馈有可能是对的，也可能只适用于他当时那个问题。

如果某个人在特定上下文里更适合使用另一张表，系统可以记录这个情况，却不能据此直接改掉全公司共享的定义。对这个人正确的做法，换一个业务部门、换一个问题，未必仍然正确。我们会尽量让模型自动收集反馈、识别冲突、产生候选修改，最后由少数对全局业务有足够了解的人确认上线。目前还没有找到一种完全依赖Agent、就能稳定解决这些冲突的方法，所以这一步保留人工是有必要的。

圆桌最后，王大川提到，大家对本体的理解未必完全相同，也未必存在一套统一的建设方式。回到各自的业务里，能不能解决问题，仍然是嘉宾们讨论时反复提到的判断标准。