比较简短，基本也对。但是「Organize, document, and share their databases, schemas, and related documentation」这句是 AI 自己提炼的总结，过度发挥了。这里把 Bytebase 描述成了一个数据库文档工具，不过后面一句话又掰回来了。
比 3.5 要丰富很多，不过有两个问题：
Gemini 的总结重点抓得很准。我是谁，干什么，卖给谁都提炼了重点，恰到好处。还提供了每一行的出处。给人一种信任感。
这个幻觉的有点过了，第一句话就问题很多。把我们描述成了一个偏 BI 的工具，是不是把我们和 Metabase 搞混了 (“▔□▔)。虽然没有充值，所以用的 Claude 3 Sonnet 是一个乞丐版。但是相比 ChatGPT 3.5，还是错的有点多。普通为什么又那么自信？
用了它的 Pro Search 模式，也是根据网站提炼的。但确实提炼的也很不错，也和 Gemini 一样，提供了内容的出处。不过还是稍稍出了点幻觉，「the use of machine learning and AI technologies to optimize migration processes and schema improvements」。后半部分的 schema improvements 确实有集成了 AI 的慢 SQL 优化，但前半的 optimize migration processes 并没有用 AI。
devv.ai 从名字上也能看出来，是一个针对研发场景的 ChatGPT 类产品。devv 的界面和 Perplexity 比较类似，提炼的内容比 Perplexity 更加全面，重点都覆盖到了，也没有看到幻觉。devv 的回答没有 Perplexity 里提及的 AI 内容，不知道是否是索引时间的原因。其实没有包括是对的，因为 Bytebase 的 AI 功能相比于 devv 列出来的几条来说，重要度是更低的。devv 相比 Perplexity 欠缺的是对于内容出处的注解。
最后再测试一下最近很火的月之暗面 Kimi Chat。Kimi 的推广力度很大，现在 B 站上，到处是它的广告 (￢_￢) 。
推荐！openGemini 性能调优之最佳实践
作者：饭饭 一、监控搭建 openGemini 测试版本：v1.2 1. 关键监控指标的选取 搭建⼀个好的监控系统可以更好地帮助我们去发现和定位问题，使⽤官⽅推荐的Gemix⼀键部署可以⾃动帮你搭建Grafana，并且官⽅提供很详细的监控模板，可以接⼊openGemini的监控。 手动搭建参考：如何快速搭建openGemini运行状态的实时监控系统 监控模板： https://github.com/openGemini/gemix/tree/main/embed/templates/dashboards 以下⼏个点是出现写⼊异常能最直观快速发现异常点的⼏个关键监控数据 系统类：CPU、内存、磁盘容量、磁盘IO 读写类：集群流量、store写并发、SQL/Store写延迟、写Wal时延、SQL/Store写QPS、写Memtable时延 压缩合并类：乱序时间线占⽐、平均乱序⽂件、Compact耗时、乱序合并耗时、乱序⽂件总数 2. 异常指标样例 异常的写⼊曲线： 异常曲线不论是sql还是store，写流量的波峰和波⾕浮动很⼤，并且不论是sql、store、wal写时延都⾮常的⾼，这就代表...
