AustinDatabases

怎么AI设定评估成本模型思考

❝

开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题,有需求都可以加群加群请联系 liuaustin3 ,(共3400人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 )(1 2 3 4 5 6 7 8群已经爆满  9群 为纯聊天群,默认不加入不得发广告,自己公众号文章链接等,发一次直接踢,默认加入8群,开10群PolarDB专业学习群115+)

最近的一些事情,让我觉得可以开始要ALL IN AI了,在正有这个想法的时候,昨天正好看了德哥一篇文章《AI 不言弃,是好事还是坏事》,在早上9:25 我快要开会前,我发现那篇文章的阅读量不是特别高,转发量也不是特别高。(

AI 不言放弃, 好事还是坏事?

中国明显 “骗子”太少,傻子太多,骗子不够用 !!

果然,深思熟虑的深刻的见地,是不会有什么流量的,但反过来看,他对一些理解他思路的人,影响确有是极其深刻的。或许看那样的文字,真的不如看 大白腿,狐狸精一样的脸蛋,白袜肌肉男,让人愉悦。人类的进步和思维的开放,想必也不是因为,白腿,狐狸精,“叫爸爸” 能提高的。所以印证了,另一篇,骗子太少,傻子太多,骗子不够用 的设定)

那篇文章里面说了什么,让我打开了思路,里面提到了一个点,AI的工作模式,AI工作模式所引起的一系列问题,成本问题尤其突出。我在简单复述一个那篇文章的核心思想,用经济成本也就是token值来估算AI 做事遇到的困难程度,基于AI和人类之间的差别,不放弃持续工作,哪怕撞南墙也要继续工作,和人类遇到困难就采用各种方式,直到放弃的不同点来进行的论述。

跟着这个思路进行下沉,AI的工作中的代价评估模型,目前是业界的空白,也就是从何种角度来让AI在进行工作中,评估出这个工作可以被取消,拒绝,禁止。

这又让我想起了数据库在处理SQL的时候的方案,在产生多种的执行计划,进行穷尽的时候,我们未必选择出最好的,但是是代价,或者说性价比最高的。或在单位时间中最好的。

那么AI在做一些任务的时候,我们是否也可以将这些作为评估模型的制作的根本,协定出一套评估成本的模型,将初始值,这里我举一个非常初级的思维定式。

评估模型输入---任务中可付出的Token的费用,这是一个固定值,但也可以是一个浮动值,如果在AI计算的时候,就差几个,几十个,几百个token就能突破的难题,我们要不要放开这个token费用的限制额度,让AI再往前走几步。

想到这里,评估模型的难度又提高了,AI 实际上不知道任务的难易程度,他也无法评估出需要多少token来完成任务,如果能评估出具体的实际的数字,那么这个评估模型的阐产出倒是简单了。

所以现在的评估模型卡在了,AI在做一项无法评估需要多少TOKEN可以完成的任务,所以评估模型无法进行评估,限制的界限在哪里。这是不是数据库的SQL执行计划本身到现在还是COST的模式,而没有进化到更高的思考维度,没有找到最优解的核心问题。

所以一个真正的评估成本的AI模型要做出来根本就是不可能。

那如果是不可能的,我们又能从什么维度来做出我们的评估模型,想到这里我脑子开始痛,或许这就是我们这个世界,对生物的思维高度的锁定,我的token 不够用了,我不得不把这个问题给了 AI 让他去帮我思考。

这证明了思维的核心原理,拆解,分析,如果无法进行分析,说明拆解的粒度不细,再拆,再分析。

有的时候,不预期的一篇文章,就能提高你的认知,当然自己也得想提高认知,二者不期而遇,认知就逐步提高了。

以下是AI给我的答案

既然精确预测不可能,我们采用与数据库优化器相同的思路

—— 多层启发式 + 动态反馈 + 渐进收窄。模型分为四层:

┌─────────────────────────────────────────────┐

│          L4: 战略放弃层(Meta-Abandonment)

│ │     整个任务是否值得继续?类比:项目要不要砍掉
│ ├─────────────────────────────────────────────┤

│          L3: 战术放弃层(Tactical Abandonment)

│ │     当前策略是否还有效?类比:SQL 要不要换执行计划
│ ├─────────────────────────────────────────────┤

│          L2: 进度评估层(Progress Estimation)

│ │     我们正在取得进展吗?类比:查询已经扫描了多少行
│ ├─────────────────────────────────────────────┤

│          L1: 资源感知层(Resource Awareness)

│ │     我已经花了多少 Token?还剩多少?              │ └─────────────────────────────────────────────┘

写到这里,我不得不佩服AI 模型的厉害,他将我的问题逐个拆分,拆分成当前我认为是一个最优解的评估模型的方案。

最后我得出了几个答案

1 AI 本身解决问题的能力虽然有限制,但限制在如下几点 1 不完全的知识信息的提出 2 将问题不会进行拆解,将一团问题交付给AI 3 对AI的认知错误,或者没有触发深刻问题的试探 4 没有用商业产品,用的是免费的产品

image

image

MySQL 写不进去数据,程序报错,谁的问题?

为什么你对AI 不积极,你落后了吗? 快要积极了,因为AI泡沫快爆了

AI 建议用pgbouncer 解决PostgreSQL  链接多的问题,唉信AI,你的死多少次!

2026数据库周边软件企业,生存困难,谁能帮一把 !

MongoDB 全文索引 与 展示查询数据的一部分,提高性能

详述PG修改字段类型不锁表的原理 step by step

传统RDBMS架构师的MongoDB思维破局与落地实践

如果没有了磁盘,数据库是不是更快,硬件会改变数据库设计的理念吗?

什么MongoDB 8.0 无索引加速聚合操作? 疯了吧!

体现价值-我们靠PostgreSQL迁移PolarDB,给公司省下了100万 “巨款”

《告别迁移焦虑:OceanBase MySQL 模式能否兼容 DBA 的“祖传”运维 SQL?》

干数据库不是买白菜:光盯着License几毛钱,看不见300台机器的电费?

一个秘密,不是你 SQL 写对了,是优化器帮“擦了屁股”  客户问迁移后为什么快了--迁移到PolarDB后的故事

AI 时代,我却用不上一个靠谱的数据库产品

AI 引入后,MySQL 列权限控制,插入,更新,读取,删除 --有了AI 真是越帮越忙

PostgreSQL 大表改字段卡死的问题解决了吗?  解决了方案在此

AI 引入DBA 工作,造成工作量增加,忙不过来,根本忙不过来!!!

三无项目导致MongoDB 持续1406% CPU 问题解决

阿里云MongoDB 部署安全吗? 多可用区怎么搞?

Image