基于知识库（RAG）系统打造由大模型（LLM）驱动NPC游戏的技术设想

基于知识库RAG系统打造由大模型LLM驱动NPC游戏的技术设想核心玩法设想最近一段时间有了一个想法——让大模型来驱动游戏里的NPC让NPC活过来。这个点子并不是我首创但是目前真正应用到实际游戏的好像还真不多。我本以为不复杂没想到随着研究的深入复杂度已经超出了我的预期这也解释了为什么目前该技术没有大量应用到实际游戏了。有个斯坦福小镇的开源项目非常有借鉴意义但他并不能让玩家参与其中只能通过上帝视角观察AI小人的心路历程挺有意思但我觉得他并不是真正意义上的游戏这个我在后面会详细分析。这段时间利用业务时间进行了大量的研究。不得不说大模型是真的好你只要有点子他就能帮你干很多大量的工作而且他还会给你建议帮你避坑。写到这里我就很想吐槽一下国内的几个大模型如果说在玩个梗、写个作文、讲个笑话、常规聊天方面我觉得都非常优秀主打一个亲情陪伴但是你要是让他整个数学推导写个代码搞个算法除了DeepSeek在及格线上挣扎以外真的是没一个能打的。有条件还是得试试gemini和claudegrok也不错。当然最关键的还是通过大模型来实现自己的学习以前学个东西得泡论坛去找大牛问论坛里呢简单的问题大家抢着回答个个显得很牛*复杂的问题又都装死所以一个靠谱的大模型真的能给你的学习带来很大的效率提升。言归正传我的想法核心是使用大模型驱动游戏中的NPC不仅仅是对话还要做出行动决策这其实非常复杂。斯坦福小镇项目分析源码分析斯坦福大学和谷歌合作的项目他的基本原理是基于RAG系统构建NPC的记忆体系描述NPC周边的环境让NPC做出决策然后产生记忆存入NPC的记忆系统从而影响下一步的行动如此产生闭环。比如发给大模型一个请求“你是张三你刚刚起床精力充沛但感觉有点饿你现在身边有床、有电话、有炉灶请选择选择一个地点并且简要说明你要做什么”然后大模型会根据常理做出选择比如“炉灶去做点吃的”、“电话打给李四告诉他xxx事”。当然这只是一个粗略的原理描述真实情况远比这些要复杂。当游戏端收到大模型的决策后根据那个物品/地点检索坐标并让角色移动过去然后脑袋上出现一个气泡显示现在要做的事或者想法。之所以我说他不是真正意义上的游戏原因就在于他并没有发生真正的交互大模型的想法在游戏端仅仅是显示了一个气泡文字而已并没有真正的实施。比如大模型让他打电话在游戏端NPC并没有真正“拿起电话”。但是在大模型的脑子里张三的记忆里多了一条“刚刚给李四打了电话”这条信息而李四的脑子里也凭空多了一条“刚刚张三给我打电话告诉了我xxx这件事”。也就是说所有的游戏中的“意义”都在大模型的脑子里而游戏本身除了显示了个气泡别的什么也没发生。这也是这个项目的聪明之处这样就可以让大模型产生很多想法比如开个派对而不用关心游戏端能不能实施它游戏端只是让人类看的。延伸思考如果要做真正在游戏端能够实施的怎么办比如NPC有了一个“开派对”的想法你得让你的游戏有所表现而不是简单的显示个“文字描述的气泡”。你得在张三家里真的布置上鲜花、气球让他的其他NPC朋友都过来…这样当玩家参与到游戏中进行游玩时才会通过视觉直观的感受到张三正在开派对而不是像斯坦福小镇那样去查看NPC的记忆文字才知道他开过派对。想要实现这个其实也不是很难那就是比如让大模型返回确定的想法或者指令而不能凭空臆想这需要更严格的格式化输出让大模型输出的操作都能在游戏端真正得到实施。但是这样就让大模型的决策有了“有限性”就无法真正发挥大模型的创意这才是最难的部分在这两者之间找到平衡。RAG系统介绍什么是RAG前面说用RAG系统构建NPC的记忆体系这是让大模型驱动NPC的基石。如果没有RAG那么一切将无从谈起。简单的说RAG就是知识库如果你搜索一下就会有很多资料。他本质上是这样将一段文字转化为一个多维向量这个向量表述了这段文字的“语义”。比如“桔子”和“香蕉”这两个东西都是水果他们的向量表述在那个多维空间里就会很相似余弦相似度或者你可以理解为两个坐标距离很近而“桔子”和“导弹”他们的向量相似度就会很低。通过这个我们就可以检索两段文字在语义上是否相近。具体应用就是我们提前建立好一些文字库知识库其实就是一段一段的文字每一段文字都计算好这个向量embedding当玩家问一个问题时把玩家的问题也计算一下向量然后去库中检索找到那些语义相关的文字段一起发给大模型让大模型根据知识库的内容更有针对性的回答问题。RAG在游戏里能干什么在我们的游戏里就可以用RAG来构建NPC的记忆体系比如玩家之前帮助NPC获得了“御用菜刀”当下次你又提及“御用菜刀”时NPC就会一下想起来玩家曾经帮助他获得过这东西这件事。父子切片的RAG实现在传统的RAG基础上我们还要更进一步。传统的RAG的弊端当知识库条目文本太长时由于计算向量是针对整块文本的那么其中包含的最关键的语义可能会被稀释这就会导致你检索召回这段文字时其相关性排名可能会降低。但是当你把文字分块太短时虽然检索更加精准了但是可能会丢失上下文信息因为一个语义可能需要在整个语义环境中才能表达完整意思。因此我们需要使用典型工业级做法父子语义分块。就是说把一大段文字作为父块然后这个父块低下包含了若干子块通过对子块的语义检索召回整段父块。这样不仅语义精准而且还能保证上下文完整。对称检索与非对称检索仅仅处理了父子切片还是不够的。考虑下面的情况假设有这样一条知识“铁匠铺位于小镇的中央”。当玩家问“铁匠铺怎么走”或者“铁匠铺在哪里“这是非常正常的询问我们信心满满的期待系统能召回上面那条知识点遗憾的时不行。为什么呢因为Embedding模型在训练时目标是让语义相似的句子在空间中靠近。”铁匠铺在哪“这是一个疑问句而”铁匠铺位于小镇的中央“这是一个陈述句他俩在语义上完全不同因此”铁匠铺在小镇的中央“反而跟”铁匠铺在铁匠们住地方“这句废话在语义上靠的更近。解决这个问题的主要途径是假设性文档嵌入HyDE。就是把玩家的问题像让大模型整一个伪答案提示词如“请简要回答这个问题不要在意准确性仅提从陈述句格式”。大模型会将“铁匠铺在哪”转换为一个伪答案比如“铁匠铺在湖边”。用这个假的回答去匹配知识库中的条目就很容易匹配到那条”铁匠铺在小镇中央“这条真答案。逆向搜索。为知识库预先生成问题Question-to-Question。在知识库预处理阶段每导入一个子块让大模型根据语义预先生成几个玩家可能问道的问题。比如提示词如下”请针对这个子块知识点结合 父块的上下文生成 3 个玩家可能会问的短句。“将”铁匠铺在小镇的中央“转化为3个问题比如”铁匠铺在哪“、“铁匠铺怎么走”、“小镇中央有什么“。将这三个问题作为子块一起存入到知识库中。在检索时就可以根据用户疑问句匹配到这条知识了。更大的坑——查询侧语义漂移这就完了吗不前面利用父块切块、预先生成问题等仅仅是把知识库的质量提高了。如果玩家输入的文字比较多就是废话比较多的时候他问的问题的语义就会被稀释就算你的知识库再完美也没有毛用。另外如果玩家一次问了两个问题怎么办传统的Embedding会将这两个问题的语义进行平均那么就将导致两头都找不到。解决方案多路子查询Mult-QueryingLLM 拆解在检索前先将用户输入发给大模型让其识别并拆解意图。提示词比如“你是一个搜索助手。请分析用户的输入如果包含多个独立的问题或意图请将其拆分为多个简短、独立的查询语句。以列表格式返回。”然后并行检索针对拆解出的每一个Sub-Query分别执行向量检索。最后结果合并 (RRF)根据每个子查询返回的结果计算一个综合得分选出最终最相关的知识块。如果用户的废话较多则需要让大模型提炼精简总结为一个简短的问题。使用精排模型(Reranking)扩大第一步检索到的结果比如取TOP50引入一个极小的精排模型。它不计算向量距离而是将 用户原始问题 和检索到的文本块同时输入直接计算两者的“相关性分数”。精排模型对长文本和复杂意图的理解能力远超Embedding向量。用这个精排模型的结果重新进行排序取TOP5-10。这一套流程下来RAG阶段大概要消耗500-800ms。构建游戏里的数据游戏背景知识、世界观、常识。这一部分是整个游戏的背景知识试想一下你开发一个古代武侠题材的游戏但是玩家问NPC怎么坐着宇宙飞船去火星那大模型很容易就穿帮了。所以背景知识是要提前喂给大模型的。当然如果你构建的是一个非常复杂的世界观就需要前面说的父子块结构的知识库体系通过检索知识来实现和大模型对话时避免一次发送太多的文本而只将当前最相关的信息发过去。这部分几乎没什么可说的。NPC个人档案这一部分严格来讲不需要知识库。因为NPC档案就是描述了NPC的性格、爱好等固有信息每次对话请求发给大模型大模型根据档案描述来模拟他说话的语气、做出符合他人设的决定等。这部分也没什么可说的。传说比如据说火焰宝剑藏在幽暗森林。可以让20%的NPC知道这件事其他NPC不知晓。这样在玩家探索的时候有概率获知这个信息让游戏有更多的不确定性当然可以让知道这个传说的NPC告诉另一个NPC。。。本质上“传说”并不是一种独立的数据体他只是NPC的记忆所以在实现方式上不需要额外处理参加下面的“记忆”部分。NPC记忆体系这一部分这就大了去了。记忆产生游戏里发生的事件大到玩家摧毁了王国的城堡小到NPC刚刚吃下一个苹果这些都可以形成NPC的记忆然后存储在RAG中。然后在请求大模型时这些记忆被检索、召回发给大模型让大模型根据这些记忆决策行动或者回复问答。NPC记忆产生还可以是由玩家或其他NPC告诉了他某件事。比如玩家告诉铁匠他的儿子其实一直暗恋裁缝店的小美。记忆的重要性玩家杀死了国王和NPC肚子饿了吃了一个苹果这两件事显示重要程度不同。所以要评估一下每一条记忆的重要度这个也可以用大模型来实现把将要存储的记忆发给大模型让大模型来打分比如1分是最不重要的10分是非常重要的事。记忆衰减让NPC像人一样能够忘记一些事。但是要根据重要程度进行差异化这里我引入了艾宾浩斯曲线来模拟衰减速度用一个值来表示衰减度最不重要的事5分钟内就可以衰减到接近0对于最重要的事10年才能衰减接近0几乎是永久记忆了。对于已经衰减到低于阈值的条目在进行记忆整理时予以删除。记忆压缩和反思本质上是对记忆的总结或者说反思。比如玩家总是给NPC送花那么在这个NPC的记忆里可能有很多条关于送花的记忆只是描述略有不同比如“今天早上玩家送了一直郁金香”、“中午玩家送了一支玫瑰”…那么可以在游戏时间深夜的时候比如NPC睡觉了或者NPC空闲的时候把NPC的记忆发给大模型让大模型对记忆进行总结就可以把很多条送花的信息总结为“玩家每天都送你一枝花”顺还可以让大模型评估NPC之间或者跟玩家之间的好感度什么的甚至还可以推断出“玩家喜欢这个NPC”之类的结论。手搓RAG系统为啥不用向量数据库市面上有很多向量数据库。但是我权衡之后决定不使用这些专业数据库。原因是数据库解决问题仅仅是一个量的问题在搜索速度上性能跟我手搓的内存版没有本质差异甚至规模较小时还不如内存版。关键是因为NPC遇到事情要请求大模型行为决策要请求大模型记忆反思要请求大模型所以综合起来整个系统的瓶颈并不是RAG而是大模型的并发性如果对接外部大模型那么成本堪忧如果考虑使用本地大模型并发性就成了最大的瓶颈这就决定了NPC数量不可能太大也就决定了数据量不会太大故此就没必须要使用数据库系统。当然这里有很多值得优化的点比如视野外的NPC可以降低大模型请求频率甚至不请求决策通过传统的策略树实现在玩家附近的NPC才用大模型来决策。手搓RAG系统设计思想用到的技术点核心是使用读写分离的快照模式避免读锁竞争。利用SIMD加速向量的点积计算合理使用线程静态变量[ThreadStatic]privatestaticHashSetstring....[ThreadStatic]对每个线程是独立的可以避免堆分配GC。检索数据时使用动态阈值更具性价比的取到TopK。目前值得优化的地方记忆条目数据中存储embedding的flaot[]目前没有池化。可能会产生内存碎片。优化点是考虑使用一个巨大的池每条记忆里存储的不再是float[]而是池子中的索引偏移。这是gemini给我的建议但是是否真的需要优化值得商榷毕竟NPC规模不大。大模型选型我是用ollama本地部署的我的显卡是RTX 4090D 48G显存版。最先尝试的是70B的DeepSeekQ4_M_K量化版可以勉强100%GPU运行。但是占据的显存几乎没有剩余了模型上下文空间也少很多而且还要跑游戏本身所以PASS掉了。尝试了下Qwen3.5-35B-A3B-Q4-M-K亮化版但是无发在API测关掉模型思考模式明明按照API手册设置了关闭思考仍然会思考连自定义的Modelfile都尝试了还是关闭不掉思考模式。折腾了一晚上放弃了。然后尝试了Qwen2-32B-Q4_M_K占用显存大约20来G。后记项目目前还在开发中。。手搓RAG很复杂很复杂。