这个周末终于静下心来，把KWR报告智能诊断的逻辑重构了一遍，并用手头的几个KWR报告测试了一番，有些问题的分析上总是无法自洽。最后分析下来，才发现这份KWR报告中居然存在某些统计数据被reset的情况。Oracle AWR报告生成时，如果发现中间存在实例重启，是会提示无法生成报告的，因为系统重启之后，一些内部的计数器都被清零了，这种报告会出现数据紊乱。
目前版本的KES是基于PG 12.1的，PG在数据库不重启的情况下，很多统计数据可以手工重置，所以无需重启实例，也可能会出现数据重置引起的不一致问题。实际上在这些报告的头部，是有提示的。因为AI分析工具没有处理这个提示信息，所以就出现了逻辑紊乱。这个问题我也向金仓提出了一个建议，那就是学习Oracle的做法，发现数据不一致，就不要生成报告。
逻辑的背后是数学，最关键的还是数据。在BIC-IA中，因为有持续采集的数据，所以数据的计算、检测、趋势判断都是十分容易的。而对于AWR/KWR报告这种独立的报告，只是数据的一个切面。这个切面中的数据必须是一致性的，如果存在矛盾，那么AI就无法在一个合理的逻辑中完成推理。
前阵子有一个朋友使用BIC-QA分析了一份Oracle的AWR报告，他觉得好像dbwr的写入性能存在问题，但是BIC-QA并没有分析出来。我刚开始看了看AWR报告，也觉得明显存在写IO性能问题。不过在BIC-QA生成的分析报告中，却明确指出DBWR写延时为0.5毫秒，处于正常水平。开始我还以为是AI推理出现了幻觉，于是想通过修改相关的知识点来优化这个推理。不过无论怎么改，结论都没有改变。后来我仔细阅读了AWR报告，发现在IO STATISTIC章节的IO BY FUNCTION里，数据显示DBWR的平均写延时确实是0.5毫秒。这个指标与等待事件确实存在矛盾。
发现了这个矛盾我才再一次仔细阅读了一遍这份AWR报告，发现报告中的闩锁争用是有些问题的，同时log file parallel write,db file parallel write的平均延时虽然很高，不过从直方图上看，超过90%的等待是小于1毫秒的，只是存在部分延时超高的数据，把平均值拉高了。
AI推理比我们看报告时更加严格，也更加仔细，因此某些依靠人很难看出存在逻辑错误的数据，AI能看出来，但是人往往会忽视。而在做AI推理时，如果数据的质量存在问题，那就会出现大的问题。这也是很多用户在构建AI应用的时候，初期做DEMO很顺利，但是上生产之后，效果立马下降几个档次的主要原因。不解决数据的问题，AI智能体就像眼睛和听力都不太好的人，做起事情来，就飘飘忽忽的了。
