构建AI应用的时候，最大的麻烦是数据和业务语意的融合问题。我一直在构思一篇论文《数据驱动的语义化知识图谱在数据库运维中的作用》，不过写起来总是差一点劲。数据与高质量的业务语义在一个AI任务中的重要性在去年我们的论文里已经讲的很清楚了，在数据库运维领域，数据如何驱动语义，里面有几个十分有挑战性的技术点有待解决。

　　在一个智能化应用中，智能体需要理解任务的语义然后分别召回业务语义和数据，将其融合在一起，交给LLM去做推理分析。单一的召回已经不能确保百分百准确，乘以二则准确性进一步下降。

　　分别提升两种召回的质量，确保不会产生错误的召回，这一点十分关键。比如我们要分析当前系统物理的IO性能是否存在问题，那么我们必须召回这段时间内的各种读写的平均值、最大值、P95值等，如果能全面召回各种数据，比如4K读写，8K读写，64K读写的数据，那么如果分析IO的专业语义加上这些数据，就可以让LLM给出十分准确的分析结果。

　　在AI实际应用场景中，语义与数据的完美融合是十分关键的，如果依靠大模型完整理解业务语义，然后准确地召回数据，或者通过数据准确召回解释或者理解数据的语义，都可以获得十分好的效果。

　　不过有一种方案更加有效，那么就是让数据和相关语义保存在一起，当需要召回数据的时候，同时能把相关的语义一起召回，这样就可以解决大多数数据语义召回不匹配的问题。当然我们无法让完整的业务语义总是和数据保存在一起，但是起码能保证数据与其最原始的业务语义能够被同时召回。

　　数据库的智能数据标注能力是解决这个问题的最为有效的方法。这种数据标注不是简单的comments那么简单。有些数据库把自家数据库的几十年前就存在，一直没什么人用的comments重新包装了一下，就号称具有了AI时代的数据标注能力了。其实这方面还得学习学习O记，记得前年的PAB上，O记得SQL引擎研发负责人让中国区的用户表决“断语”功能，几乎所有的中国用户都投了反对票，大家都接的这种东西不会在自己的系统种被使用。比如一个公司只能有一个CEO，可以有三个高级副总裁等。后来有一天，我突然想清楚了，这个“断语”功能，压根就不是给我们用的，而是给智能体看的。国产数据库在DB4AI上，我觉得还是要多看看O记是怎么做的，先跟上别落下就很不错了。

　　库内标注应该是未来的趋势，而在AI Coding的帮助下，库内标注的成本也已经大幅下降了。甚至智能体能够根据业务代码自行完成部分标注增强。只要数据库能够提供各种精准标注的功能，就不是问题了。