如题，之前看到了佬友讨论函数式编程，于是有了这个想法。
因为本身不是学编程出身，对于ai也仅有一个模糊的印象，所以可能抽象得不是很准确。
在不考虑网络延迟、token消耗时，llm提供的api调用感觉可以抽象成如题的一个函数，当然还有各种参数；它本身具有无状态的特点，对话app是靠把完整对话一遍遍传给llm来得到一种像是在连续对话的感觉的，而把相同对话传给同一个llm十遍，它会给出10个类似主题但用词可能略有不同的回答。
基于以上抽象，是否可以推导出，像ecs架构以及函数式编程范式这一类状态与行为解耦的设计，更有可能是在应用llm时的最佳实现？也就是说，llm应该与状态完全隔离，只在需要时显式地作为参数传入，而不是作为副作用让llm“读”到？
2 个赞
看不懂（＃－.－）
然后因为输出是概率上的确定，所以在测试时也不应该用通过/未通过，而是用概率分布来确定它的通过与否，这样理解对吗？
本来就是这样呀
1 个赞
本来就是呀，下一个 token 计算出的本来就是概率，然后排序后，根据随机性（温度等参数）从前面的 token 里面随机选取作为输出，概率分布是确定的
1 个赞
神经网络 是有做 线性拟合 的分支……
这是在思考llm在游戏对话之类的的应用时想到的，起因其实是玩佬友的修仙模拟器，但很显然修仙模拟器与一般确定结局的游戏还是不同的，但是还是可以用llm来产生有趣的对话的吧
本来就是这样的，LLM是无状态的一个函数，每一次运行预测下一个token。
我猜你想要的是基于状态机的Agent框架。
1 个赞
那感觉现在对llm的应用，是不是步子迈得有点大或者有点过于乐观了，似乎有许多想基于ai的游戏，但目前按这种函数式的抽象，其实用于确定剧情、确定分支的游戏的npc对话生成才是最适合且最稳妥的吧，仅用于对话，根据输入的状态生成，并且有个回退的对话用于离线的情况
你这就是把Agent退化成Workflow了
你理解的大概没错，但是你应该误解了什么。建议了解：Transformer
1 个赞
因为考虑到llm本身输出就是概率的，那么测试上就得达到概率上的通过才算成功，这样的话对于游戏npc这种较复杂的状态就得尽量保守才能保证不出问题吧，加入npc行为控制感觉测试难度飞速上升啊
那可不嘛
自己搜了一下感觉看得不是很明白，可以大概讲讲吗
为什么呢？对于那些自由度高的游戏来说，这是优点而不是缺点
不是函数
是概率向量
因为反常的行为难以测试出来啊，厂家希望的是ai控制的npc行为在一定范围内足够“聪明”，而超过这个范围就该是bug了，但这个范围是概率来确定的，可不就是测试量的膨胀嘛
调低温度就行了
想规避模型某些行为的话, 你可以直接把行为定义为函数调用的形式, 然后行为控制就可以直接通过参数解析来规范, 然后不规范调用直接ban掉就好了.
然后你说的输入一个字符串输出确定概率字符串的函数, 这个也不完全是吧, 针对固定输入, 拿到的logits虽然是固定的, 但是依据temperature等参数也是会导致最后的输出token有所变化的, 而token变化的话, 在自回归的时候由于attention参考全局信息, 又会导致下一个token的概率分布有所变化.
transformers有个计算图, 可以看一看学习一下: Transformer Explainer: LLM Transformer Model Visually Explained
嗯之前是我的表述不清了，“llm是一个输入字符串与一些控制参数、输出确定概率的字符串（且字符串中包含一些调用行为信号）的函数”，这样的抽象有没有什么毛病吗