你的把领导伺候好，所以呢，你就帮助你的新来的同事，你告诉他，领导喜欢喝 散装白酒，越是小摊上的越好。因为数据他不一样，长江长城，黄山黄河，完了开始唱上我的中国心了，STOP，因为我们的数据不同，有的是医学的，有的是金融的，不同的数据不断冲刷河道，他得出的河道的样子也是不一样的，所以我们有不同的大模型，来去做不同的事情。OpenClaw他是嘛，他就是一个臭干活的，把结果给他，告诉他，你去把厕所粑粑纸

我们可以理解为，你要做一个100%的卷面题，但是你做到10%的时候，你的10%可以加入到你的知识中，并且你学习了这10%的全部知识，而后面的90%里面有这10%的知识，那么你答对90%后面的知识的概率就会提高，以此类推，你答的越多，你整体卷面的正确率就越高。当前AI中需要解决的问题是幻觉的问题，也就是我们提到的一本正经的胡说八道，这是因为预测机制中，每个词都在自己的概率范围内，被使用，而人类的思维

4 mode 这个我还查了一下，里面有两种 MOE 和 CPU+GPU,MoE是可以将大模型中的专家模式卸载的一种大模型运行的方式，他计算的是每次进行TOKEN输出中的需要的大模型，而不是整体大模型的参数都需要运行。经过分析，这台主机最大可以顺畅的跑7B左右的大模型，不能跑更大的模型在于显卡的无力和显存的缺失。上期我们说了，我想购买的主机想在本地运行大模型，那么如果你已经有了主机，或者强悍的电脑，

所以到目前为止，我个人还是希望能通过自己购买物理主机运行70B大模型的方式来进行AI的使用，这样比较稳定，虽然一次性投入比较高，但后期的费用低，只有电费和电脑的折旧，但大模型可以换，可以7*24小时的进行token的产出，而不用担心费用。然后我还看了几个其他的可以运行大模型的设备，联想为AI运行大模型定制的主机，只有手那么大，但是宣称可以跑70B主流的大模型，他采用的技术是联想定制的，内存划分给显

其实这里还有另一个问题，就是PostgreSQL或者其他的数据库产品都不会考虑你的一个SQL运行的并发性，他们仅仅是针对一次的操作来判断COST，因为bitmap调用IO更少，在数据库中更少的IO是SQL运行中希望看到的,同时我们也可以看到，下面的PG的COST的计算模式。工作比较忙，事情比较多其实很多事情就无暇顾及，这点还是得说，给更多的时间和人力在优化数据库上，是可以降低成本的，但这样的方式因

我特别想把PolarDB的IMCI推广的更好，让更多的业务享受到PolarDB的插件化数据库的特性。这个当然有作用，POLARDB FOR MYSQL的语句执行方式分为行存模式，行存并行执行计划，列存计划三个方式来进行语句的执行，性能优化器的会再次根据cost的计算IMCI > PQ > 行存串行 的方式来进行语句的从高COST到底COST的分门别类的语句执行。如果遇到数据的删除和更新的情况下，采

首先PG并未使用我们熟悉的LRU内存页面的替换算法，而是采用了clock sweep 类似的做法，当页面被访问的时候，他会在内存的页面上递加值，通过全局的内存指针在扫码这些页面的值，当被扫到后，这个页面的权重值 - 1减1，如果这个页面的权重为0 则这个页面就被替换掉。我们可以去想，PG产生的时间很早，那时的硬件和操作系统都比较的OLD，文档也是从那时建立起来的，也就是说，这些参数的优化都是基于老

3 这个方案的好处，不存在通过网络传输中产生的数据延迟，或者犹豫数据不一致导致的数据丢失的问题，RPO = 0 ， 只要磁盘没有坏，NODE A写入最后一个字节，NODE B 拉起就可以恢复数据库的状态。产生这样的方案的根因是金融银行业的特性和底线，总结为行为的可预测性，责任的可追述性，事故的可解释性，风险的可审计性，以及数据库负责人的确认和事前的确认甚至是可签字性。这样的方案才是金融级的PG数据

所以成本是较低的，而他的问题也很清晰，就是where 不参与分桶，必须回表过滤，在为了查询速度快的情况下，会漏掉一些结果，还有对于大表第一次建立索引时的成本会比较高，需要全量扫描。这是一个系列，AI已经进入一些公司，恰巧我的工作正在经历这个阶段，组织学习和工作的内容，经验，这是一个常系列，希望大家都能跟上发展的部分和节奏，不掉队。2 查询的时候会计算出 query 向量到所有的中心距离，然后选出最

特点和优势，是查询的速度很快，在海量的数据下，也能精准找到最相似的向量，这种搜索的方式基于存储所有层级的图结构和指针，内存的消耗会比IVF要大的多。查询的方式也是类似分类的方式，从上往下的方式，从顶层入口开始，到下面每一层，在同层寻找邻居节点向量的距离，并移动到最近的邻居节点，然后下探到下一层，直到找到正确的数据节点。随着m的调整的大小，调大会提高内存的消耗，构建的时间，索引也会变大，但是他会提高