@cherbim 正常更新时间应该是周四，这是阿里标配，我在 b 站看极海 Channel 说的，所以这个是典型的，没有走版本控制，代码审计，连自动化测试都没有，“临时工“闭着眼睛直接上生产环境的案例

@nekoharuya 看错了，3.5 回答张若虚，4.0 回答周国平，多 Regenerate response 两次，就会变成周作人，然后又会变成张爱玲

@yinmin 我问的时候又变成张若虚了，感觉 gpt4 虽然上了人类反馈学习，但是并没有自己分辨是非的能力，这问题还是蛮大的，以前微软小冰就是这么被玩坏掉的，这一点证明了 gpt4 也只是个高级一点的问答模型，原理上比起以前手动填表，人力维护问答数据的聊天机器人，并没有什么本质突破

有没有一种可能，咱就是说，社会工程学，也是信息安全的一部分（
我想起那个段子，你想象中的国家破译黑客加密过的设备，一大群专家，用一大堆专业设备，怼着机器研究个昏天黑地，实际上国家破译黑客加密过的设备，拿着枪指着他脑袋，你丫丫的自己解开，不然就把你毙了
这么看，是不是感觉这比赛特别硬核

@huskar 除了上诉的奖励机制外，世界状态通常是计算出来的，而不是可以直接查值的，例如小明有没有喜欢的人，小红和小明的性格是否合拍，也就是说，上了强化学习，也并不能减少这块的硬性计算量

@huskar 强化学习是一个方向，但是和俺这游戏设计理念不同，难点在于奖励机制不好设计，因为在这个游戏中，npc 没有一个明确的，统一的，游戏目标，npc 每个目标都是它自己顺着世界状态，推出来的，

@L1shen 这个昨天也正好刷到，这类方案其实之前考虑过，最后还是放弃了，参考我在第 8 ，18 和 20 楼的回复

@exch4nge python 的缺陷在这里，它的多线程是是在单进程中运行的，然后 cpu 在各个线程中不断切换，于是就有了一个问题，切换也是要时间的，在这种 cpu 密集的场景下，多线程将列表处理完一遍的时间，比单线程遍历完一遍，需要更多的时间，多进程的话，进程间通信的开销更加巨大，特别是在没有 fork 的 windows 上，要计算的数据还得单独传递过去，在数据体积十分庞大的情景(特指俺这游戏)，这是相当高昂的开支，另外就是沙盒游戏的通病，角色数据只能逐个迭代，不能分开算……不过，目前游戏里还是有一些多线程处理，比如 ui 的渲染在单独的线程里，也有多进程的应用，比如用子进程实现了完全不影响玩家操作的自动存档，又或者做近似对象检索的库，它建立索引的过程是多核的

@zglzy 项目大了，积重难返，其实也试过走 nuitka 之类的东西，把 python 转成 c ，再编译，但是有几个问题，一是现在项目和 python 耦合性太高了，不说那些复杂的语法糖，光是一个推导式，它都搞不定，更别提对各种 c 库的兼容，那些走 jit 的方案也是同理

@csulyb 没有什么纯算法上的性能瓶颈，有数学计算的硬性需求的，大部分都通过各种库解决了，例如随机算法和检索近似对象，还有寻路，主要的性能瓶颈在硬性的计算量上，只能从整个 ai 算法的框架上做优化来规避，比如通过基本案例推导，让 npc 之间相互模仿行为，npc 每次要检索的行为树就降低了一大截，俺这个是纯文字沙盒游戏，重心就在 ai 上，我清楚这技术也是屠龙技，我搬砖多年，完全用不到，但是它酷啊，整个游戏行业，从各种 3a 到各路独立游戏，不管是什么模拟人生钢铁雄心绿帽之王，还是什么 cdda ，矮人要塞，环世界，哪个 ai 有我这个高级，你说是吧

@thorneLiu 几个方面，一则这个项目开发了五年，数据结构之类的设计上和 python 强耦合，利用了大量的 python 的特性和设计思想，另一方面，python 的生态还是可以的，我用了许多三方库来解决问题，社区的拖拉机还是很可以的，比如用 numpy 实现，以 value 作为随机区间，随机选择一个 key ，比起我直接拿 python 写二分法，要快 40%，又或者我写的蚁群算法依赖近似度检索，chatgpt 给我挑了一堆库多半都是炼丹来实现的，我直接拿来就用，不用去关心它的设计原理，

@antonius 倒也没有在虚空优化，火焰图之类的东西有在用，print 也打得多，各有优缺吧吧，但是常规的手段只能排查一些明显的瓶颈，通常也通过预热数据来解决了，比如游戏中场景树相当复杂，节点到节点之间的移动找不到什么有效的算法，最后选择上数据预热，例如在 github 的流水线中打包的时候，就把所有可能的，结果到节点之间的移动的最短路线创建好，比起死磕这块，不过直接从算法上完全避免，

@zglzy 其实有尝试过，但是，数据传递和数据类型转换的成本相当的高，再者就是高度耦合的问题，详看我在 8 楼的回复

@antonius utility-based ai system 实质上是被包含在这个算法的条件随机场(Conditional Random Field)中了，效用(utility)，即 crf 中，验证函数通过世界变量获取到的条件权重，在人类的思考过程中，并不总是选择最优策略，但总的来说，人类总是更倾向于更有利的选择，所以这里做了个随机场来实现这一点，权重越大，选择对应目标的概率就越大

@antonius PreCondition 这块的处理也是有的，核心是通过实现建立好的 hash 表，从 Goal 去查它绑定的 PreCondition ，当 PreCondition 不能满足的时候，又通过事先建立好的 hash 表，从 Effect 去反查能够满足他的 Goal ，只有一个 Goal 能满足的时候就返回它，有多个的时候就通过权重抽一个，某个 Goal 有某个 PreCondition 不能满足的时候，就又递归一层，通过对数据结构的调整，以及对数据进行预热，来优化这块的时间复杂度，尽可能的做到 O1 ，至少我刚才回忆了一下，只有一两处实在绕不开的地方是 On ，底层架构的话，我已经做了非常多的优化，我的能力所限，现在要继续优化也完全找不到新的思路

@kepenj github 上搜 dieloli 就是了，帖子里说的算法自然是成品，这个游戏我做了五年了

@thorneLiu 主要是 gpu 只能解决特定算法问题，参考上面我对 txhwind 的回复

@txhwind 在这套设计里，作为核心，也就是性能瓶颈最大的 crf ，和对象化的数据结构强耦合，详细来说，我通过装饰器，注册了几千个验证世界状态的函数，它们各自之间，又有一些逻辑处理，同时也必须非向量化的处理角色的属性数据，各种状态验证中，验证角色之间的社交关系，好感度，当前位置，历史状态的也不在少数，我目前应该是没有能力完成向 c 的迁移

@antonius 时间切片之类的在行为跨度短的时候有效，但是第一次启动时，所有角色都在查找可用的目标，其实也是一个比较大的瓶颈，玩家选择睡觉这种操作的时候，步进跨度比较大，要卡很久，也是常受玩家诟病的，设计上，其实是选择了状态机和时间切片耦合的办法，ai 找到目标后就进入了状态机，状态结束后才重新查找，另外蚁群优化也是降低查询次数的方案，找到了近邻角色以后，按相似度和信息素作为决定是否模仿对方的行为的概率