昨天我终于把BIC-QA国产数据库知识问答上线了，当时只发了gitee，昨晚同事把github的库（https://github.com/BIC-QA/BIC-QA）也搞好了。这个产品我们一直想发，不过总觉得知识库的质量还无法拿出来见人，所以一直拖着。8月18号是DBAIOPS社区成立三周年的日子，所以我和大家说，大家无论多累，都要把它发布了。哪怕大家用了不满意，我们再慢慢改进也行，知识库是无法闭门造车的，必须有大量的人来用，才能越做越好。
其实上线后也还是折腾了半天的，刚开始llama.cpp的一些参数没优化好，负载高一点就打爆服务器了，后来又遇到了llama.cpp的一个bug，可能是有朋友把一段日志直接扔进来问问题，超出了模型的上下文限制，触发了llama.cpp的bug，一直折腾到下午系统才算稳定下来。很多东西，不上线跑一下，仅仅自己在实验室里怎么测都是没用的。
一些朋友看到我昨天发的文章后立即开始试用，并且把一些问题反馈给我了。十分感谢这些热心朋友，有更多的人在用这个知识库，并且不断反馈意见，这个知识库才能越做越好。仅凭我们公司的几个老家伙来标注知识，一年365天不休，又能搞出多少来？每位朋友的一次吐槽都是为这个知识库建设添砖加瓦。
昨天有个朋友问了一个十分绕的问题，关于ADG上OMF文件的问题，意思是ADG盘满了，主库的一个文件创建后备库没有创建成功。后来用alter database create datafile ... as ...重新创建了文件，为了保险起见，创建前他先关闭了standby 自动管理文件。不过后来他在v$datafile ,v$data_header中发现这个File id的文件名还是OMF的文件名，并且OMF的文件和他指定名称创建的文件都存在，ADG工作是正常的。所以他感到十分不解。
依靠我对ADG/OMF的知识的理解，把这个问题想明白也绕了半天。从知识库回答的效果来看，结论大体正确，不过中间少了一个知识点，create file as 命令用来处理unnamed文件的基本原理，所以回答里缺了一小块内容。于是我补全了一条知识进去，再看系统的回答，其中的推理链就连贯多了。因为我这边用的本地模型是一个qwen3:4b的小模型，只能依赖知识库的结论来形成最后的报告，可能用CHATGPT，有些知识会被自动补全。不过大模型补全可能会引入幻觉，还是知识库本身能召回准确的知识比较好。
不过有时候补全知识也不见得就能改善知识库的质量，我昨天看到有朋友问到ORA-600[4193]的问题，这个问题是和[4194]的处理方法类似的，知识库用[4194]的知识点去回答了，效果还可以。不过我总是希望完美，于是补充了几条[4193]，[4197]的知识点进去。刚刚补完，一个同事说，好像我们的知识库出问题了，回答质量下降很厉害。经过沟通才发现，他正好在分析[4193]这个知识点，发现召回的质量突然下降了。我愣了一会儿才想起刚刚添加了7条知识，于是把这几条删掉，问答的质量就变好了。
向量搜索和rerank从本质上来说还是数学，AI并不能像人类一样学习和结能，因此知识库依然会被概率所困扰，并不是知识越多越好，而是高质量的知识越多越好。我们这个知识库刚开始的时候只有官方文档，搞好后发现问答的质量很一般，后来加入了一些国产数据库厂商的实战经验进去，问答的质量一下子提高了很多。官方资料生成的知识点，必须让高质量的运维经验作为纽带串起来，知识库才能真正帮助用户解决问题。目前我们已经和一些国产数据库厂商开始磋商，希望和他们合作，搞出一些高质量的运维经验，放到知识库里。处理后的知识库，双方共享。
回到今天的话题，知识库中知识并非越多越好，知识的质量越高越好，高质量的运维经验越多越好，这是我们这阵子开发BIC-QA的感受。前阵子我们测试的时候发现在达梦的知识库里总是混有Oracle UNDO的思想，虽然达梦的UNDO和Oracle 的UNDO只是名字和基础概念是一样的，但是实现方式完全不同，为什么会被混淆呢？最后我们发现，在达梦的知识库里混入了一条ORA-1555的知识，就是这一条知识，一旦它被问题召回，就会把达梦UNDO相关的问答质量都拉下了一个档次。建设高质量知识库的道路还是很漫长的。
