国庆假期前四天在深圳，后面四天在西山。原本有些纠结国庆要不要回西山，因为今年天气异常，苏州和深圳一样炎热。2号晚上西山的一台AI工作站突然掉卡，识别不了机箱里的显卡了，于是临时决定还是决定四号回西山看看。
从深圳出发前我还在京东上下单了一块新的显卡，想到了苏州就立马换上，否则深圳公司里的那块显卡再出问题，就影响国庆大家加班了。我还特意选了一家5号能送达的店铺。到了西山发现那块卡还没出库，和客服联系可能要8号才能发货，于是只好退单。打开机箱重新插拔了一下之后，发现显卡又能被识别了，看样子这块显卡钱又省下来了。GPU和CPU不同，跑一段时间后掉卡是常有的事情，小用户自建AI应用系统，使用传统的GPU工作站，还是有一定门槛的。而目前的基于融合内存的AI工作站虽然故障率低，基本上可以做到开箱即用，不过目前算力还不足，跑32B以上规模的模型还有点慢，看样子边缘侧的硬件要成熟起来还需要点时间。
国庆这几天做了两件事，一件事是把《实战国产数据库：从选型迁移到运维优化》这本书校对完了，剩下的时间都在和公司的同事一起校对GoldenDB的知识库，公司成立到现在，我们还在实行远程工作的模式，如果不想去公司上班，在家里也OK，做这种有一定创造性的研发工作，坐打卡和坐在工位上并不是提高效率的关键。自从实施这个制度以来，我发现大家的工作效率提升了不少。随时随地，哪怕是节假日甚至是深夜，如果有空，都可以干会儿活，大家也没有觉得很辛苦。
年初和GDB达成共同建设知识库的意向之后，我们已经从最初比较生涩的磨合渐入佳境。大家对数据库数字化描述的理解已经趋同，知识片段构建的速度也在不断提升。唯一的问题是客户那边的需求很紧迫，给研发留的时间有点紧张。一方面我们希望去用户现场部署前能够把知识库打磨得更加精致一些，另外一方面缺乏用户现场场景支撑的知识工程难度加大，因此这个工作有些延期了。
这几个月有很多朋友知道我在做国产数据库的AIOPS，他们觉得我这个没有什么AI研发经验的人搞这个是不是有点冒险，现在DIFY/COZE这样的平台那么方便，今后是不是最终用户和AI专业公司来干这个更合适一些。
以我这一年时间在这个领域的工作经验来看，我还是觉得在某些AI应用领域，并不是仅仅依靠某些低代码平台就能干出实用的系统的。使用Dify开发过真实的AI应用的朋友可能都有一些感受，用Dify去打一个原型系统很爽，很快，但是如果想直接利用Dify去开发一个系统的话，有种感受就是好像能够够到实际应用的底边，但是似乎离业务的需求总是差了那么一点。
Dify这样的低代码开发框架确实能够提供您开发AI应用所需的各种工作量能力，但是如果真的把流程碎片交给Dify，用平台的能力去整合，离业务实现总是差那么一口气。低代码平台是有能力上限的，你可以很快构建原型，但是无法突破其能力上限。
突破上限的方法有两种，一种是自己去修改平台的代码，让它能更好地支撑业务，但是这种方法也不见得能奏效，因为LLM是一个黑盒子，LLM与Dify框架之间也有不可弥补的裂痕。
第一种方法不行，就要去看第二种方法了，那就是通过知识工程去让LLM服务变得可靠。我们目前就是采用这个方法的，甚至我们在初始DEMO搭建完成之后，决定放弃Dify、RagFlow等基础框架，完全在我们自己的平台框架上做能力扩充来实现BIC-IA，从而腾出精力，把主要的力量放到知识工程上。
这种方式看上去好像有点“笨”，今后的一些复杂流程的应用开发可能要投入更多的研发资源。不过好处是无论以后用什么LLM服务，用什么AI框架，基础的知识依然是提升AI应用上限的核心。不过这种方法做起来比较累，标注几十个知识，做个DEMO出来其实是一件很有意思的工作，不过如果要标注成千上万个知识点，这项工作就变得抽象而乏味了。我有些时候也是比较抗拒去干这个活的，每次都是拖到无可再拖才会全力去做。看着几千个需要标注的知识点，头皮都有些发麻，有时候标注到某个知识点的时候发现前面的标注似乎不是很合理，于是还要回过头去对那些已经标注的知识做优化修改。每次干这个活的时候，最总都会血压升高，疲惫不堪。
虽然这项工作不易，不过必须去做，仅仅有好的开发框架，缺乏基础数据做支撑，AI应用就只能是空中楼阁。
昨天我在做复核工作的时候发现，经过这段时间我们和GDB的同学的共同努力，我们居然已经在GoldenDB上构建出差不多规模的故障模型和运维知识图谱片段，指标集的量级也与Oracle相差不大了。以前我总觉得国产数据库在可观测性能力上要想追赶Oracle还需要花上三五年时间，看样子这个时间会大大缩短。通过下阶段在用户侧实战磨合，我们会发现目前遗漏的指标数据和故障模型，进一步优化知识图谱。
从这一年的实践来看，对于AIOPS应用而言，知识工程是没有上限的，拥有更加丰富、更加精准的数字化的运维知识，是建设一个靠谱的DBAIOPS系统的关键。
