- 主题:各位，如何搞定大模型的不确定性？
比如这样的问题：我让ai修改一个表格，先修改a行b列，再修改a行c列。十几天以来，一直没问题。但今天，当作第二次修改的时候，它总是修改到a行b列上去。关键是它大多数好使，偶尔不确定。这就让你没办法彻底放心。其实也有其它的类似不确定的问题，这些问题不像写代码可以通过编译，通过测试用例。
有什么好办法对付这种问题么？
--
FROM 124.64.43.*
这个只是个修改文本文件的功能，claude code的自定义命令。不是代码。没有测试用例。
【 在 z16166 的大作中提到: 】
: 测试用例没跑通，就让它返工修改
--
修改:chunhui FROM 124.64.43.*
FROM 124.64.43.*
我试试，关键是这个东西它已经正常好些天了，突然今天就不准了。所以你没办法信任它是靠谱的。ai很多时候都是这样不确定。是个问题。
【 在 semipunk 的大作中提到: 】
: 把你的要求放在硬约束：后面试试
: 以通过编译，通过测试用例。
--
FROM 124.64.43.*
和之前的对话没任何关系。这是自定义的claude code的slash command。也就是一个提示词。有两个子命令，每个子命令更新自己所在表格。先执行a，/clear, 后执行b。但神奇的是b总是更新到a的表格中。今天突然出现的。 我怀疑是glm4.6为了提高性能，过度使用了缓存。
【 在 semipunk 的大作中提到: 】
: 大模型行为和上下文有关。最好在同一对话中执行操作，而且必须反复提醒它回顾对话和它相应的操作。大模型没有记忆，每一次问答它都会重看之前段所有对话
--
FROM 124.64.43.*
我这个不是写代码。只是自定义命令想让ai自动修改文件。换成kimi就没问题了。之前glm4.6也一直没问题。反正是比较奇怪。
ai很多时候都会遇到这种不确定的问题。尤其是无法验证的东西，就更不好弄。
【 在 semipunk 的大作中提到: 】
: 一个prompt本身就是对话。不过我很少vibe coding。你的情况没有发言权
--
FROM 124.64.43.*
这是一个办法。其实自己写个程序给ai调用也可以。就是稍微有点麻烦。实在不行就这么弄。
【 在 walker0000 的大作中提到: 】
: 那就转换成确定的啊，让他写出程序，测试通过之后用程序来修改表格，这样就没问题了
--
FROM 124.64.43.*
严格来说我这个可以直接用程序解决。不需要ai。不过用ai弄实在简单。文字描述一下就可以了。而且用了好些天是正常的。就是那天突然有问题。
【 在 butcher 的大作中提到: 】
: 你都知道这垃圾不确定，为啥还要确定呢。
: 在粪坑里找金子肯定是失望的。
: ü嘁耄ü馐杂美
: ...................
--
FROM 124.64.43.*
是的。这种方式比较可靠。但我是图方便，一句话让ai作了。不过是前两天突然出问题。
或者是我这个修改文件的问题，严格来说完全可以让程序实现，并非不确定的问题。
【 在 jacksonchu 的大作中提到: 】
: 固定格式任务建议让 AI 出脚本，测试成功之后用脚本比 Ai 靠谱
--
FROM 124.64.43.*
这是我自己写着玩的。如果出错我看一下修改就行了，先凑合着用。如果是正经应用，就得花点时间写个程序完成。否则这一步就无法离开人。
【 在 yahaha 的大作中提到: 】
: 这个都会有的，模型里面为了发散思维都会有随机性。需要靠评价函数再把它拉回来，必然是个概率的问题。无非是个多大的概率问题。
: 这和人是一样。需要靠后期的手段来保障。
: ü嘁耄ü馐杂美
: ...................
--
FROM 124.64.43.*
所以编码领域是最合适大模型的。因为有编译器测试用例把关。
确定性，上下文限制，动态学习 如果这三个突破了，那大模型才敢说像agi靠近。现在还远的很。
【 在 nosnap 的大作中提到: 】
: 模型自己也在更新数据库不断的学习，可能进化得更好，也可能变差，稳定性还真是不如脚本
: ü嘁耄ü馐杂美
: 发自「今日水木 on HBN-AL00」
: ...................
--
FROM 124.64.43.*