拾象实践：为了理解AI-Native，我们做了几款AI应用
作者：秦佳豪
编辑：siqi
排版：Scout
本文来自拾象技术负责人秦佳豪对 LLM 应用实践的阶段性总结回顾。
2022 年底，拾象团队不仅从投资配置角度开始关注到 LLM 的趋势，在内部生产力实践中也亲身体会到 LLM 能力的强大，因而在内部进行了一系列 LLM 应用开发的实践，既包括对话式内部知识库、音视频转录这类效率工具，也有复刻 GPT、LLM 输入法等偏实验性质尝试。随着模型能力的不断增强以及更多优质的探索框架的诞生，例如 OpenAI Function Calling、Code Interpreter、AI agent 等，模型能力的提升迅速淹没了工程层面努力和创新。
虽然大部分实践在这个时间点看起来已经“过时”甚至“徒劳”，但快速了解一个行业的最佳的方式就是参与其中，尤其是 LLM 这样的新浪潮，也正是这一系列 hands-on 的经验也让我们有机会以第一视角观察这个领域。
今年 3 月，拾象开源了《The Age of AI：拾象大模型及OpenAI投资思考》，以 Top-Down 的视角分享了对大模型边界、格局、生态以及顶级玩家 OpenAI 的深度研究，本篇 LLM 应用探索笔记则是一位一线开发者对 LLM 的思考。
在这一系列 LLM 开发实践过程中，我们也形成了两款 LLM 应用，分别为 AI 跑团游戏《盗梦笔记》以及播客发现工具 PickPod，欢迎体验试用。如果您本人是产品开发者、并有兴趣和热情深度参与 LLM 应用的探索，也欢迎与我们联系。
01.
LLM 应用实践复盘
实践一：对话式内部知识库
2022 年，因为要搭建拾象内部知识库，我们第一次真正使用到 GPT。对于所有知识型工作者和企业来说，“知识库”是个十分现实的需求：不只是存储所有资料，更像是一个可随时调用的“大脑”。
在内部数据库的搭建中，我发现数据库的使用入口还不足够方便。虽然我们已经用 Lucene 将各个外部入口都统一封存为一套查询体系，但这种查询交互更像是 Google ：当同事们想要查询某个问题时，系统给到的结果首先是一份文档，随后需要进入到这个文档中才能查找具体数据。这种交互不仅效率很低，甚至不如直接询问对应的投研同事高效，并且对于关键词的要求也很高。
机缘巧合下，我们选择以 GPT-3 接口作为查询入口，也因此实现了对话式的搜索的效果，并将它部署成了一个飞书机器人的形态。如下：第一张图是直接用 text-davinci-002 实现的回答，可以看到即便是当时最强的 davinci-002 也略显“人工智障”，既不理解提问的意图，也不知道 hugging face 是什么，下面的图则通过 curie、ada 接入内部数据，给出数据库中收录的数字。
text-davinci-002 效果
通过 curie、ada 接入内部数据的效果
实践二：复刻 instruct GPT
到 2022 年末，ChatGPT 已经逐渐出圈。OpenAI 的官方博客中介绍 ChatGPT 是和 InstructGPT 十分近似的一个模型，那么复刻 InstructGPT 是否就能理解 ChatGPT 的逻辑？于是我们也萌生了一个想法：通过参考 InstructGPT 论文来“复现 ChatGPT”。
Source：OpenAI
借助开源库 trlx 与知乎答主何枝的内容，我们用一周时间成功实现了一个完整流程：基于“海外独角兽”平台发布的 100 篇文章并处理了语料，大致 Finetune 了一个中文 GPT-2 模型，并参考 OpenAI 论文截图做了一个打分的网页平台，在流程中加入了 PPO（Proximal Policy Optimization），没实现的就只剩中间全连接层的打分小模型。
Source：InstructGPT
从结果上来看，生成内容的的确更像海外独角兽之前出现过的文字了，并且 sft 这个步骤的效果十分明显，我们猜想可能是因为 GPT2中文的模型能力对 finetune 天然有需求。到了 RLHF 这个步骤，我们自己也不能直观感受加入 ppo 后会发生哪些变化。我们参考的开源库 trlx 是拿情感分析，所以效果体现就是可以从好评生成器切换为差评生成器，当中那个打分小模型就是情感分析的模型，这样的 RLHF 效果还是挺直接的。
原始的 GPT-2 中文模型
Finetune 后和加入 PPO 后的差异
工程参考（链接详见reference）
如果要直接做 Zero-shot ，效果可以说和“胡言乱语生成器”没什么差别（如下图），大家如果感兴趣也可以自行在 Hugging Face 上体验。整个过程中，我有一个隐约的感觉，GPT-1、GPT-2 的效果如此之差，而 ChatGPT 可以说是惊艳了全人类，这当中信仰的力量相当强。
实践三：没有 Plugin 之前，如何让 ChatGPT 上网？
2023 年春节期间，ChatGPT 彻底引爆了大家对 AI 的讨论，而社区最热门事情之一就是部署 “ChatGPT 机器人”：因为当时还未开放 GPT-3.5 的 API， 而 GPT-3 还是略显智障，所以这里的核心做法是自建一个本地浏览器，将绕过 ChatGPT 网页版限制捕获到的输出呈现在这个本地浏览器上。
ChatGPT 机器人很多，简单重复造轮子没意义，我就开始思考一个问题，能不能将 ChatGPT 接入互联网？甚至接入 API？因为还不能联网，所以 ChatGPT 在那个阶段只能调用 2021 年前的数据来回答问题，另外因为幻觉问题胡编乱造比较严重。如果能接入互联网、使用一定 API，不仅这些限制可以消解，ChatGPT 自身的功能边界会被大大扩展。
经过一番尝试，在2月份名为 The Crowd 的机器人诞生了：The Crowd 不仅可以链接到互联网，还可以接 API，并且我们把它这个部署在了微信端，通过和这个微信机器人对话完成交互。The Crowd 可以实现的功能很多：除了搜索内部数据库并给出答案、总结某个文章链接的内容、帮忙实现在携程订机票……这些场景大家今天看起来肯定相当熟悉，因为这就是 Bing 后来用的 webgpt，以及 OpenAI 推出的被视为颠覆互联网分发模式的 Plug-In 。
左边是接入互联网之前的原始回答，右边是接入互联网后的。（左右滑动查看更多图片）
The Crowd 的实现其实也很简单：
• 先用一个页面或者 GPT-3 API 去完成一项分类任务，比如拾象内部经常使用到的“查询数据库”，“查询群聊并总结”，查询“某家公司的最新新闻”等，基于这些任务类型来设定一个判别器；
我们实际总共设定了 8 个任务，分别为：1）聊天 2）查询内部知识库 3）总结微信群聊 4）Bing 搜索信息 5）机票信息查询 6）某家公司最新投融资新闻 7）总结 Pdf 文件、微信链接内容总结 8）未分类的任务收集。
• 根据判别器的结果分发具体任务到相对应的 ChatGPT 的页面去完成；
• 在不同任务的 ChatGPT 页面中，结合不同类型的数据、信息需求，会接入相应的 API，例如总结小红书的 ChatGPT 接入了 Bing 的 API 实现对网页内容的提取，买机票的场景中则是链接了一个爬虫来抓取网站的实时动态。
The Crowd 机器人实现路径
实践四：端侧推理需求能带来新的硬件吗？
今年 3 月中，拾象内部讨论了“LLM 能否带来新终端”这一问题，也因此有了下面两个实验项目的诞生：
项目 1：把大模型封装到手机输入法里
Llama.cpp 一定程度上已经实现了在普通硬件设备上成功运行 LLM、实现类 ChatGPT 体验这件事，但并不算真正实现，除了手机端只支持 Android 模拟器 termux，并不支持安卓原生应用，所以我们考虑把它封装到输入法里：
• 从交互角度：
输入法比封装了 ChatGPT 能力的 APP（ 不久后 ChatGPT 也推出了自己的 App）距离用户行为更近了一步。如果 ChatGPT 被封装为一个独立的 App，那么如果要调用 GPT 的能力，就需要在不同功能的 App 之间来回切换，如果是输入法，则完全可以一行输入 prompt、一行输入任务的方式直接在交互层（例如微信聊天界面）直接输出结果。这里的逻辑其实和 NotionAI 类似，即在高频场景中嵌入 GPT 的能力；
• 从隐私角度：
现有的大模型能力如果在云端实现，则必须调用接口需要上传用户信息到云端来实现逻辑处理，一定会带来用户隐私泄漏的问题，但如果将推理放在本地，不仅隐私风险被消除，模型能力的调用也不会再受限于网络环境，甚至在飞行模式下都能运行。
这个项目另外一处比较有意思的地方在于，作为一个安卓开发经验为 0 的小团队，在此之前我们甚至没下载过 Android Studio，但在 ChatGPT 的帮助下，我们只用了 2 小时就完成了一个带特定功能键、并且能够在手机里能运行的输入法产品。不过，由于当时 Llama.cpp 这个项目还处于非常早期，甚至 arm 指令集编译都会报错，所以为了实现真机运行，更多的时间其实是花在了不断修改底层编译和核心 C++ 函数上。目前，这一输入法已经能够在真机运行，但速度非常慢，完成水平仅供参考。效果如下：
项目 2：通过耳机实现同声传译
这个产品的场景也很简单：即两个人只需要各自佩戴一只耳机，即便一方说的是英文、另一方说的是中文也能实时聊天，因为基于各自佩戴的耳机就能实现“识别输入 —翻译—输出结果的动作”。类似的产品概念已经不新鲜了，流浪地球中就有类似场景，科大讯飞也在做“翻译耳机”，但交互升级还不够彻底。
大模型之前，这里的核心难点是如何在有限时间内返回的高准确度的识别结果，随着模型效果变好、推理加强，识别效果和时延问题也能相对控制。目前的核心难点可能主要在于硬件、苹果底层开发上，主要目的是在产品层面实现足够好用。
这个场景下的理想交互形态基于 AirPods 这类硬件来实现的，例如，用户有一对 Airpods，想要和对方面对面跨语言沟通的时候，只需要给对方一只耳机即可。AirPods 在这里承担的是输入和输出的功能，语音的处理则需要在 iPhone 上通过端测推理实现。因为苹果底层协议的设置，目前 AirPods 还无法支持两只耳机独立作为输入。
所以，如果要真正实现上面的场景，我个人理解大概存在两条实现路径，开发新的硬件，或者是苹果底层开发的升级。而新硬件设备至少要实现的，也是作为一个聚集设备实现分别输入、推理和独立输出。
一对 Airpods 只支持一个输入
除了耳机外，眼镜也是非常好的载体，已经有斯坦福的学生做了类似尝试“rizzGPT”。
💡
“rizzGPT”：由斯坦福大学学生研发的 “rizzGPT” 实现了 AR 和 AI 技术共同提供实时 “容器即服务”（CaaS）。该系统使用 OpenAI 的自动语音识别工具 Whisper 收听对话、GPT-4 实时生成自然响应，并搭载在 Brilliant Labs 的 Brilliant Monocle（一款开源 AR 设备，可夹在任何眼镜上），然后将响应叠加到用户的真实环境中，以应对各种实际场景。
02.
LLM 应用一：
PickPod
PickPod 简单来说是一个“知识助手”，可以帮助发现散落在播客等音视频内容中的“非共识”。这个项目始于今年 2 月，它的雏形是一款音视频识别和转录工具。在 ChatGPT 开放 API 之后，大量 AI 工具涌现，其中有一个很大的场景是“总结”，例如有很大一类是用 AI 总结音视频的插件。这里其实反映出一个需求，即相对于文字，从音视频内容中获取信息的时间成本很高，尤其是信息密度较高的知识型内容。此外，在海外独角兽投研团队的研究中，CEO、行业 KOL 的一手访谈是很重要的研究资料，但音视频的信息获取效率是低于文本的，因此音视频内容整理、总结工具也是内部刚需。
总体上这个项目经历过 2 个阶段：
• 第一阶段是 All-in-One 地解决音、视频的内容总结需求：
因为内部会议、行业访谈等涉及到的信息量密度大且十分专业，所以这里的唯一诉求是准确率必须尽可能高。例如拾象团队最常用的飞书妙记，从技术层面，它的转录识别效果应该是国内的免费工具中最好的了，在说话人识别、上下文相关对应等细节，但实际使用体验还是有瑕疵，尤其在专业性较强的内容识别上。而其他常见的 AI 音视频总结工具上使用的前提是 YouTube、Bilibili 或者 PodCast 预先能够提供字幕文件，再基于字幕去做总结整理，所以如果选定的视频或者播客没有提供字幕文件，那么这个工具就无法正常使用。
• 第二阶段则是实现一个 “信息助手”的功能，让 LLM 找到散落在音视频中的“非共识观点”，最终实现播客的个性化的推荐：
从获取全球科技领域的高质量、前沿内容角度，播客一定是最好的信息源之一。但就像我们前面提到的，文本内容的信息捕获是快于音视频的，大部分人在收听播客或者视频访谈时常常会遇到的一个问题时，即无法提前获知这篇内容是否足够有用？即便以嘉宾质量作为判断标准，但因为各种原因可能某些大咖嘉宾输出的仍旧是市场共识，同时，又因为音视频收听成本的原因，一些小众、长尾的播客虽然信息密度极高但很难被人们注意到，除非是有人以文本的形式，例如 Twitter，将它的核心观点分享出去。
虽然最底层的技术支持是同一套，但是这两点要分别做好其实是两个不太一样的方向，产品形态也会截然不同，从阶段一到阶段二也是一个从工程实践到 AI-native 应用逐渐成型的过程。
💡
体验地址：
国内 IP：pickpod.shixiangcap.com
海外 IP：seashare.xyz
阶段一：
在这一阶段，我们基本确定了基于 OpenAI 的 Whisper 进行开发的基础。但直接配置 Whisper 并不够，因为 Whisper 的输出格式是“时间戳+文字”，无法对说话人（类似于飞书的妙记转录）进行区分，所以即便 Whisper 的识别非常好，对于以对话为核心的 PodCast、访谈类内容，直接用 Whisper 输出的内容仍旧没有降低阅读成本。
我们的解决方法是对 Whisper 模型本身进行改造：首先是输出最小间隔改成 1 秒级别，其次添加 pyannote 作为辅助模型，不仅实现了对说话人的区分，也能够对时间戳（timetemp）实现合并统一。
效果
产品基本能跑通了，但还需要面对一个现实问题：模型的输出需要 12g 的显存，如果是单任务、本地跑，这套模型虽然能跑通但单 GPU 一个小时仅能完成 3 个任务。不过 OpenAI 很快开放了 Whisper 的 API，并且推理速度远胜本地开源版本。
不过 API 状态下又出现了新的问题。现阶段 Whisper API 对处理的文件的限制在 25Mb 左右大小，但基本所有播客文件都会超过这个大小，所以直接使用 Whisper API 的话就需要对音频大小进行预先处理，切分为几个段落分别处理或直接压缩源文件大小，但无论哪种都让体验打折扣：直接压缩意味着更长的处理时间，切分段落的处理方式除了增加处理时间外还会丧失结合上下文来判断内容的优势。
为了规避大小限制，我们选择对开源模型进行系统工程改造，而非针对 API 去改造。比较幸运的是，新架构整体成本做得比 API 更便宜，速度上可能更快。我们在一台 3060 机器上测试了同样一段 1 小时时长音频的本地处理：OpenAI Whisper 推理需要 11 分钟，OpenAI API 需要 5 分钟，开源社区的 Fast Whisper（ctranslate2）最快 1 分钟就能输出流，这个结果在当时还是相当震撼的。
💡
（github.com/OpenNMT/CTranslate2）
其次，由于转录识别和人声识别都需要 GPU，我们又进行了弹性 GPU 的改进：即根据任务数去分配、切割、调度 GPU 资源，从而一定程度上保证了服务的高可用性。
到这一阶段，一个又好、又快、又便宜的音视频识别和转录工具就搭建完成了。
阶段二：
虽然底层都说基于 Whisper 的转录服务，但是从阶段 1 到阶段 2 其实是两个不太一样的方向，因而产品形态也会截然不同。市面上常见去总结播客、音视频内容的产品主要分为两个方向：
• 一类是大模型兴起后的一些应用，比如 Sider（插件）、Bibigpt（网页应用），这些产品提供的是对于某个音视频网站的 Summary；
• 一类是 Snipd 为代表的新一代 PodCast 产品， Snipd 主打 AI chapters ，同时也支持用户切片分享，根据不同内容片段被切片分享的次数来判断出哪些内容值得收听；
虽然形态不同，但这两类产品的共同点在于提供更高效的 PodCast 收听方式。
从技术层面，总结（Summary）、时间戳（Timestamp）以及章节提取（Chapters）的实现并不难，这些功能的 Prompt 都非常简单。以 Langchain 自带的 Summarize 为例，如下分别为单轮及多轮再聚合的处理方式：
而 Timestamp 或者 Chapters 的实现也不复杂，比如我们自己使用的 prompt 如下：
create no more than 3 key moments from the video transcript and include time. Your answer should be concise and starts with 00:00 and ends with /n "{text}"
这些操作中唯一值得注意的是输出格式。在不是特别智能（比如 GPT- 3.5）的模型中，无论在 assistant 或者在 system 里用 prompt 去描述比如无序列表的格式输出，都会出现个别格式不统一的输出（如下图中所示）。对于这一问题，除了手工写正则去清洗，常用且可靠性比较高的做法就是给一个上下文示例，虽然很老生常谈，但在实际中的确远比 prompt engineering 可靠得多，尤其是在对确定性要求高的中间环节中。
总结（Summary）、时间戳（Timestamp）以及章节提取（Chapters）这些功能是比较常规大家都在做的事，但仅靠这些功能是否就能解决从海量的 PodCast 中快速获取信息的需求呢？
我自己的一个直接体验是， Summary 或者关键时间戳对在实际中对于是否要听某期内容的决策参考并不大，这个帮助仅限于让我快速了解确定的某期内容，可以通过这些功能选择性地跳过一些章节，但从快速获取知识的目的考虑，仅靠总结（Summary）、时间戳（Timestamp）以及章节提取（Chapters）等基础功能其实并不彻底。这里并不代表说 Summary 或者关键时间戳等功能不重要，而是站在“更高效地找到优质播客”的需求角度，Summary 等功能最大的问题在于它们提供的是“正确的废话”。
举个例子，比如在天才黑客 George Hotz 曾在一期播客中提到过“GPT-4 是一个 8*220b 的 moe 架构”，但在 Summary 的功能逻辑下，这一观点在时间戳中并没有被呈现。又比如，54 分 59 秒位置这里总结了 “discussion on AMD and PytTorch compatibility issues”，这段时间在讲这个内容概括是完全没问题的，但这种概括对于还没有听这个 PodCast 的人来说，可能无法突出这期内容的差异化。更进一步，这期内容有极大可能会被总结为”George Hotz 谈论了 GPT“ 这样的内容，但其实有非常多的 PodCast 的 Summary 中包含了”谈论了 GPT“ 类似的信息。
Source: Ep 18: Petaflops to the People —
with George Hotz of tinycorp
所以这个问题不是仅靠调整 Prompt、或者换个模型就可以解决的，本质上这是产品设计的问题而不是单纯的技术工程问题。
我个人理解这里需要获得增量信息。比如对于一个视频总结的内容都是比较泛或者“正确的废话”，增量信息其实是非常少的，要理解增量信息从信息熵的角度是非常便捷的，但 LLM 时代不需要这么麻烦，直接问即可，比如：
💡
信息熵：量化消息复杂程度或不确定程度的指标，如果一条信息量越多,则它的信息熵就越高。
那对于我们个人而言，信息的增量最主要的来源其实是非共识，因为非共识的不确定性高，即信息熵高，尤其是针对个人的非共识，它是完全基于你有什么认知。
再来举个实际例子，以《阶梯计划》的第五期节目为例。在 Summary 和时间戳的逻辑下，我们可以感受到这里有大量的信息量，但还是比较难决策为是否要听这一期内容：
但如果我们从信息熵的角度来重新总结文中第一部分的内容，则结果如下：
观点一：加密资产的法律性质问题是此次美国监管机构主动出手的核心原因，特别是未登记证券（unregistered securities）这个法律概念。监管机构认为许多交易所提供的交易服务涉及未登记证券，这构成了他们的违法事实依据。这一点不同于此前针对币安和 SFTC 的起诉，后者更多围绕币安自身的不合规行为。
观点二：美国监管机构今年表现出较为主动的态度，积极出击，特别针对行业巨头币安和 Coinbase。这一点与过去几年相比更为突出，后者监管机构更多是被动回应行业提出的诉求，如反对比特币 ETF 申请，或与交易所进行沟通等。
观点三：由于监管是一个复杂问题，监管机构对加密资产行业有多种诉求。其中，未登记证券的法律概念对监管机构而言至关重要，是他们此次主动出击的核心理由。这个概念也让真正的行业从业者无可避免地面临监管压力。
回到产品，整个实现逻辑如下：
1）首先利用 LLM 给播客节目生成更加鲜明的观点；
2）在处理完对同类标签下的所有播客节目后，横向对这些节目生成的观点进行横向比较；
3）基于信息熵的逻辑去判断哪些是非共识高的观点；
4）具有高非共识的节目大概率就能够解决用户本周想听哪些播客的诉求。
这个过程本质上和我们个人去判断内容是否给自己提供了增量信息的过程一致，核心在于，在环节 1）中，我们调用了 LLM 的信息处理能力来快速完成“听完所有节目”这件事。而为了实现 4），即因为每个人背景知识不同、信息增量不同的问题，只需要在用户界面提供反馈按钮即可，类似于 MidJourney 让用户 4 选 1，并且这里的“该非共识观点对我是否有用”可以被存储至个人数据库，而这些信息又能够被叠加在 prompt 中，或者进行相似度过滤，例如，这里的 prompt 可能是“我已有的知识点有 A、B、C 以及 D，在已经呈现的 A —— F 的观点中，哪些增量信息比较高的？”。
基于这个思路，我们就完全可以实现一个真正个性化、针对每个用户已有知识补充为角度的 PodCast 精选工具。
PickPod 产品逻辑
我们用同样的方式对所有 OpenAI 相关的播客进行非共识观点的提取后，上面 George Hotz 播客的信息就变成了这样：
💡
PickPod 的 Python 本地版本会进行开源，开源版本中包括了租云服务器及一键拉取环境配置的脚本和反馈迭代推荐系统的个人版本。（开源链接：https://github.com/shixiangcap/pickpod）
03.
LLM 应用二：
盗梦笔记
ChatGPT 爆火之后，基于 GPT API 开发的应用越来越多，其中不少项目有个共同特点：固定成本不高，但边际成本几乎没办法降低。这也是这些项目无法持续、生命周期极短的核心原因。
我们在 AI 社区看到的很多项目都属于极客开发者们的脑洞、玩票实验，为了方便用户体验，一般都不会加鉴权，这类项目要么要求用户提供一个 API_key 才能使用，要么由开发者绑定自己的信用卡（注：OpenAI 接口不绑信用卡的话会有接口请求限制，尤其 GPT-3.5，一分钟发 6 个请求都有可能爆超过接口限制，需要绑定信用卡），但“让用户自己提供 API key ”这一要求本身就限制了超过 99% 的用户，大部分开发者都选择了后者，随之也要面对信用卡爆单的现实，项目也因此中止。
账单爆了的原因很简单：有一部分开发者选择“白嫖”他人的 API_key 为自己所用，甚至也有人通过自动爬虫去检测是否有可供使用的 OpenAI 接口。甚至在我们在开发 whisper 转录工具时，产品还没公布上线就已经遭遇了几个开发者来尝试“白嫖”。
被“白嫖” API_key 时的后台异常访问
所以当时的一个感觉是，基于 API 的项目如果要持续就必须找一个能有盈利的方式。
如果按这个思路来看，游戏其实是一个非常好的载体：和工具类产品不同，游戏天然“离钱最近”，即便不依靠用户主动付费，通过引入广告，也能够达到收支平衡，并且和工具相比，游戏的用户沉浸时间要更多，极端情况下甚至可以在每轮都嵌入广告。于是就有了《盗梦笔记》（内测入口）这款游戏的诞生。
获取最前沿的科技行业资讯
盗梦笔记共经历了 3 个版本的架构改动：
版本 1：
3月份的第一版简单来说就是个纯 prompt，我们参考了台大李宏毅教授公开课《用 ChatGPT 和 Midjourney 来玩文字冒险游戏》中的案例，通过给 ChatGPT 一个 Prompt 来让玩家玩到由 AI 随机输出、设定好的游戏本子。李宏毅教授设置的 Prompt 如下：
“请开始一个文字冒险游戏。由你来描述游戏场景，由玩家来决定要采取的动作。请详细描述场景中所有的物品、生物，如果场景中的人物在对话或者跟主角对话，请把对话内容完整输出出来，如果主角和场景中的任何生物互动，请把互动过程详细描述出来，不要出现重复的场景或对话，故事要曲折离奇，高潮迭起，游戏开始时请详述故事背景。”
在对这个 Prompt 进行修改、并部署在网页端后，就形成了我们的第一个版本。
网页版的作用主要是收集反馈、迭代，保证 AI 输出可控，同时观察整体游戏的趣味、可控性等。这一版其实效果还不错，但问题也十分明显：作为开发者，我们除了设定一个 Prompt 作为游戏开头之外，实际上在游戏过程中无法做太多干涉，例如关键情节设定、分数值等等。所以如果是第一次玩这个游戏的人，体验或许还可以，一旦玩家玩的次数增多就会发现情节重复性很高。
所以，只预设 Prompt、再部署的方式本质上就是一个毫无封装的套皮。不过，在对这个版本的内测中，我们观察到了 AI 的整体输出、互动、节奏，对后续的版本迭代提供了基础。
版本2：
4月份的第二版思路则是让 ChatGPT 服务于游戏的整体设定，ChatGPT 在其中的功能只是用来辅助生成内容、场景等部分，相当于已经有了剧本，它负责增加趣味性和一定的随机性。
这一版我们参考了日本的 7 轮推理游戏玩法，即在一个案件场景下，玩家需要通过对话在 7 轮内查明真凶，并把这套玩法用在了《名侦探柯南》、《逆转裁判》、《魔塔》等知名 IP 的改编上，剧情和游戏节奏相对固定，ChatGPT 在这里只是用于丰富一些语料交互，所以这一版本中完全没有所谓“AI Agent”的概念，AI 在这里本质还是用在系统流程环节的工具。
相对于上一版，这一版虽然从情节内容上相对可控，但从玩家体验上来说，明显不如上一版中纯粹由 ChatGPT 主导的非常自由的感觉，也丧失我们想要将 AI 引入游戏的初衷。下图是我们其中一个 IP 的具体流程，可以作为理解这个阶段是怎么思考引入 AI 的参考。
版本二游戏架构图示例（可放大阅读）
高清大图请点击：https://ibb.co/kqtYF57
版本3：
发展到第三个版本则是以“跑团游戏”为载体，也就是“盗梦笔记”的诞生。选择跑团游戏的原因主要有两个：首先是游戏机制天然契合；其次则是玩家粘性更强，我们在前期调研中发现，会有一群跑团深度玩家连续沉浸玩一个月，入坑以后可玩性和养成性确实要更高。
💡
跑团，也被称为没有剧本的“剧本杀”，是指进行桌上角色扮演游戏（TRPG）的过程。通常需要一名游戏主持者和其他玩家组成团队，相对于剧本杀，跑团游戏的故事世界更为开放、没有剧本限制。玩家可以自由发挥创造力来设计、养成自己的角色，同时还需要考虑到不同的技能或者语言描述会触发不一样的结果。在这个过程中为了得到想要的信息，玩家需要积极与主持人互动，由主持人和玩家共同推进故事。
和狼人杀、剧本杀这些传统文字剧情游戏相比，跑团游戏的体验直接决定于主持人的能力，主持人的限制一定程度上也是跑团游戏目前还没有像狼人杀、剧本杀一样普及的原因：
• 主持人需要根据某个模组（模组可以理解为“跑团”基本大纲中的游戏单元）去展开描述所有的场景和细节。
如果说剧本杀每个人看一段剧本，跑团则是主持人要熟悉所有人的剧本，并且还要根据当时的背景去合理、准确地引导玩家，根据玩家的不同的语言或者技能使用的而给出不同反馈。通常情况下，一个短一点的模组内容未几千字，更长的则可以达到几万字；
• 作为主持人还需要非常了解跑团的规则，而每个跑团游戏的规则书通常是一个长达 400 多页的文档。
因为这里的规则不仅仅是指怎么玩，还包括所有玩家角色所有技能在不同情况下使用引发的情况和结果，以及特定的时代背景下可能出现的物品以及不应该出现的发明等等，要在不同情境下迅速做出对应的指引挑战极大；
由于跑团对于主持人要求比较高，而上面提到的又恰好是 AI 所擅长的，那么如果让 AI 来当这个主持人就能很大程度上解决主持人稀缺的问题，同时对于新手玩家负担也比较小。但同时，AI 想要当好这个主持人也不太容易，比如上下文遗忘、比如越玩越贵、比如容易陷入道德正确。我们的解决方案融合了之前的经验，以多个 AI agent 共同交互的方式去完成。
比如，AI 一号负责整个游戏规则的了解，AI 二号负责故事线生成，AI 三号负责 npc 情感，AI 四号负责技能判定，AI 五号负责战斗轮的智能，同时加了一定的记忆模块、存储模块、思考模块和随时调用记忆的能力。
这样拆分的好处实际是极大降低了成本以及能很大程度上控制输出。如果靠导入非常长的游戏背景、玩法、模组以及玩家和主持人的上下文，除了 Context Window 不支持，成本还会非常高。另外，这种设计方式能用非常小的结构让作为 KP 的 AI 随时了解玩家处于模组的什么阶段，尽可能避免上下文遗忘从 A 模组穿到 B 模组。
除了多 Agents 共同交互外，我们还针对性地设计了一套游戏架构和数据结构，在游戏入口之外增加了创作者模式。
创作者可以在这个模式中直接把剧本转化为成型的跑团游戏，并导出到游戏界面直接分享给玩家。在这个过程中，AI 系统能够根据故事剧本内容拆分成设定好的架构和数据结构，创作者还可以在内部的网页编辑平台进行可视化修改。除了成型剧本转化，创作者模式下甚至还支持用一个小场景生成一个完整游戏剧情，例如，只需要给系统输入“高启强从卖鱼贩子逆袭成黑帮大佬”这一 prompt，就能生成一个原创的模组。
这个项目实际上是整体所有项目里花的时间最多，也是收获最多的。
首先是成本问题。做游戏的初衷是经济可持续的去探索 LLM 应用以及特定类型的 LLM，所以怎么更少使用上下文、怎么保证幻觉输出不会影响玩家体验等等这些问题这些都是深入去做才会遇到并想办法去解决的，也因此形成了一些 Take Aways：
• 模型大小：
在给定格式的输出中，因为大模型的幻觉原因，总会出现意料外的输出，这种时候反倒是用不那么大的模型、同时结合 Finetune 表现更符合期望。比如给定完整格式的 prompt（上下文充足的条件下）让 llama 输出，基本会严格按照格式，但 ChatGPT 就会“加戏”。对于 ChatGPT ，在不考虑输出风格的前提下，最有效解决幻觉问题的还是上下文，而不是 system 或者 temperature 等参数，且英文的显著比中文要强。
• 上下文窗口携带：
如果追求最好的效果，每次携带上下文，用 32k 或者用 100k 的模型，那这个成本就太高太高了。所以模型本身能力的一些提高在这个项目的探索上影响倒不会很大，这一块核心还是游戏架构和数据结构的设计，如果每轮对话都用 retrieval memroy 那套其实成本也很高，开源的方式可能有 gptcache，我们则是针对这个游戏设计了一套使得上下文的调用不用特别频繁，但也能一定程度避免上下文冲突的情况。
• 单一模型 or 多模型：
除了 GPT-4，还有使用其他大模型的必要吗？答案是 Yes。在此之前，我认为 GPT-4 足够强大、可以解决所有需求，个人使用其他大模型的概率不高，但在实际使用中，还是能够发现不同的大模型之间输出内容风格上的差异，比如 Anthropic 的 Claude 对于细节表述、角色扮演类的则更为优异。“风格”这件事比较难通过一些上下文或者情景描述去实现，所以如果我们使用 ChatGPT 的时候，即便已经在系统中制定了输出风格，但因为上下文的影响过于强，所以这时候可能切换为 Claude 就能解决问题。如下图，在同样一个技能判定场景中，ChatGPT 的回答比较中规中矩，Claude 就有趣多了。
OpenAI 的返回结果
Claude 返回结果
除了成本问题，怎么让游戏更好玩也非常重要，即“AI+Gaming”的落脚点还是应该在 Gaming 上。做游戏之前，我想要实现的核心概念还是完全自由的、AI 驱动的游戏，但到了实践中，我们发现自由性只能是玩法的一部分，比如给用户一个画板做一个画画游戏，可以随意创作，确实自由性非常高，但显然只有加入你画我猜的游戏机制才使得游戏更有趣。
跑团和剧本杀的核心差异是 剧本杀玩了一个本再玩下一个实际上没有关联。跑团则是这张人物卡每次玩新模组都会有变化 比如年龄增加了，阅历增加了， 获得物品了，技能提升了等等 所以除了纯粹的开放自由，可养成性也是一大杀手锏。
这里本质上其实是“育碧支线”和“经济可用”之间的平衡。
育碧支线是低成本制作开放世界游戏的一种方式，但玩多了由于强烈的公式感，体验就会比较差。针对这个问题，我们目前的感受是，随机生成的模组和精心制作的模组差距还是比较明显的，所以优先完善了制作端现有模组的导入和二次编辑，也希望能在后期和跑团创作者们一起共创。比较有意思的是技能创作的部分，当我们尝试导入古代神话，比如《西游记》的一些剧本，生成的技能有腾云驾雾、火眼金睛、七十二变、炼丹等技能，也许可以 AI 自行开创一个平行于 COC、DND 的“村规”。
💡
COC指 Call Of Cthulhu（克苏鲁的呼唤）， DND 指 Dungeons & Dragons（龙与地下城），COC 跑团和 DND 跑团是分别以美国克苏鲁神话和龙与地下城为世界观创立出来的模组，不同的世界观流派中的角色特质、基础数值规划等都有差异。
另外一件有意思的事情是，当我们引入 AI 队友这个概念后，发现 Claude 除了能成为玩家的队友外，也适合做游戏可玩性和逻辑 bug 的“测试员”。在游戏前期，我们调整 prompt 还是通过手调以及手写一些测试用例的方式，到后期基本就全靠 Claude 在帮忙测试遇到一些意料之外输入后的临场反应。
除了经济层面更加持续之外，更长期的一旦有人开始玩，游戏过程中的交互也让我有可能获得一系列中文数据：如果能够获得足够多轮的对话信息，就有可能做一个做一个专属于这个游戏生成的大模型。即使游戏本身可能不如预期，但是这个多轮对话数据集也可以贡献给开源社区。
游戏这块在听了些很棒的播客《AI+游戏：涌现、失控与灵魂付费》以及认真理解了 Voyager 项目后，其实有很多新的感悟体会，限于篇幅，这里暂不做展开。如果对这块感兴趣，也欢迎相互交流。
04.
总结
以上就是过去半年多以来，拾象内部对于 LLM 应用的相关探索总结。这个过程不仅直接从体感上感受到一些工程努力迅速被模型能力的提升所淹没，还强烈感觉到：当下市场对于这一波 AI 浪潮还是处于短期高估，长期低估的窠臼中。
在詹姆斯瓦特发明蒸汽机整整一个世纪后，城市运输还是重度依赖马匹而非蒸汽机。当 2017 年 GPT-2 刚推出时，我们无法想象那个“人工智障”竟然在 5 年后成为了今天的 GPT-4；另一个例子是三名物理学家研究中微子的时候发现了求解特征向量的解法并和陶哲轩一起发了数学论文，今天，陶哲轩也在使用 GPT-4 辅助自己的研究，GPT-4 能否代替那三名物理学家吗？
几个核心体感：
1. 在一些中间流程上，更强的大模型未必比小模型结合 sft 更好用，但如果需要中间状态有自己的推理能力，那现在 GPT4 还是远超其余模型；
2. 模型的“强”与“更强”取决于到底是谁在用：比如陶哲轩使用 ChatGPT 辅助自己的工作，那么 ChatGPT 接收到的问题质量就比其它模型高太多了，而这些智慧是 10 亿人的语料也换不来的；
3. 模型怎么更安全？这里的安全不只是 alignment 输出的内容足够安全、符合人类价值观，而是在信息接收和处理环节如何保障安全和隐私，否则真正科研人员是不敢用它作为助手；
4. 端测推理也是输入安全的很重要一部分，而不仅仅是更低成本实现 LLM 或者其它，目前开源模型的一些推理优化从效果来看也完全不输闭源产品的；
5. 如果要用 LLM 做应用感兴趣，搭建一定的基础服务能带来很多效率上的提升。过去的产品路径是产品经理已经有了输入输出的概念，开发人员保证输出符合即可；而现在多模型、多 agent 本质上对于结果的不确定性放大了很多，有可能边做边改比预先设定可能的效果更好，而这里的前提就是一定的基础服务。比如同样的查询能不能直接输出多 temperature 多模型的结果，这个结果又能不能直接被流程所记录甚至 AI 完成迭代。
6. 电子设备产品层面影响下一代才是关键。任何有意思的发明 都是先从影响下一代开始，最能接受、 LTV也最高，比如我 2 岁的女儿就喜欢和 pi 打电话，虽然和 pi 的交流完全不在一个频道，但并不影响她喜欢使用 pi 这件事。
7. 有观点认为近两年完全不用考虑 AI 应用，因为从目前 LLM 发展的速度和进展来看，可能更强的 AGI 确实能完全替代目前能力不足而要做的一些应用 tricks，但我个人相对乐观，一方面，做应用能一定程度上感受 LLM 的发展，另一方面，如果想要真正做 AGI，而不仅是非目前的客服替代流程加强，更需要应用从资金层面反哺做 LLM 的团队。
科幻小说里的 AI 最终归宿都是在帮助人类完成人类做不了的事情。如果你对类似的事情感兴趣，有很多很酷的想法且有匹配的行动力，欢迎与我交流。
特别感谢
最后，感谢郭柿彤、陈昊宇、姚昕玥在代码上的贡献，蚁触科技提供的AI 触感反馈 SDK，以及拾象团队在项目讨论、前沿知识分享、视频制作和文案编辑上的启发贡献。
延伸阅读
Perplexity AI，比Google Bard和Bing Chat更靠谱的问答引擎
OpenAI基金首批投资赛道，Kick是下一代ERP雏形？
GPT-4 的“秘密”：MoE、参数量、训练成本和推理设计
AI Agents大爆发：软件2.0雏形初现，OpenAI的下一步
拾象硅谷见闻系列：打破围绕开源LLM的6大迷思
微信扫码关注该文公众号作者