Long Context 解决 90% 的模型定制问题，Moonshot AI 发布开放平台

云栖大会是一年一度的全球顶级科技盛会。2023 云栖大会于 10 月 31 日至 11 月 2 日在杭州举办，吸引了全球 44 个国家和地区的 8 万多名从业者参会。今年最受关注的话题莫过于大模型技术。在 11 月 1 日上午举办的“AI大模型新势力”论坛上，主办方邀请了国内知名 AI 创新的负责人分享大模型的当下与未来。

Moonshot AI 工程副总裁许欣然受邀在该论坛发表了题为《Moonshot AI：寻求将能源转化为智能的最优解》的主题演讲，以下是现场演讲视频和实录。

Moonshot AI：寻求将能源转化为智能的最优解

大家好，我是许欣然，Moonshot AI 公司的工程副总裁，很高兴能在这里给大家分享 Moonshot AI 在大模型发展路线方面的思考。

Moonshot AI（月之暗面）是一家专注于通用人工智能领域的公司。我们团队中很多人曾作为核心成员参与了国内外知名大模型的研发，并且发明了像 Transformer XL、RoPE 这样的关键算法。

我们的愿景是，致力于寻求将能源转化为智能的最优解，通过产品与用户共创智能，实现普惠AI。

上个月我们的第一款产品 Kimi Chat 开启了内测，可能很多朋友就是通过几张图了解到我们公司的。

左边是自动整理发票场景：一次性给它可能几十张发票，让它帮忙整理一下，然后统计一下满足条件的一些发票。中间是给他一个十几万字的长报告，让他帮忙分析。

最右边的例子是直接把 arXiv 上的一篇论文交给它，让它根据论文里面的伪代码去直接编写对应的一些 Python 的示例代码，非常好用。

在这里非常感谢参与内测的用户对我们的认可和鼓励。整个过程中我们也非常惊喜地发现，大家的认可和各种创造性的使用方式，都跟我们最初的想法不谋而合。那就是要充分利用 Long Context 技术。

Long Context走向“最优解”的第一步

Long Context 是我们本次产品中最核心的能力，也是我们认为迈向公司愿景——“将能源转化为智能的最优解”的第一步。

Kimi Chat 目前支持长达 20 万字的上下文处理能力，我们认为这个长度是可以满足绝大部分场景使用诉求的。当有了这么长的上下文处理能力之后，我们就发现，它可以直接解决很多以前由于上下文窗口不够大带来的问题。

我们来看一些例子。比如过去我们如果要翻译一篇非常长的文档，这份文档可能会超过一个上下文的窗口。以前的做法就会把它切割成若干个小段，分别送给模型。这个时候同一个词，比如说 chair，可能在前文被翻译成了“主席”，而到了后文可能就被翻译成了一把“椅子”，出现很尴尬的情况。更不用提在一些比较专业的词汇上，可能前面有一些缩写的解释，那个时候它可以正常翻译，而到了后文就翻译不对了。

之前，大家为了解决这些问题想了很多工程优化的方法。比如说在切段的时候，尽可能让前文和后文重合一些，让模型尽可能的多了解一些，或者说人工总结一些关键词的词表，保证模型在这些比较关键的词汇上不要犯错。这些都是一些临时的解决方法。

但是还有很多场景可能不是很好这么绕过去。

比如在 Agent 场景下，可能一些比较复杂的任务，根本就装不到 Context 里，还没有描述清楚，上下文就已经超出长度限制，就没办法做了。

再比如说像一些比较角色扮演的那种情况下，可能没聊几十句，模型就忘了最开始的角色定义，就开始放飞自我，又变回了一个普通的 AI 小助手。我们发现在上下文足够长了之后，这些问题就全都迎刃而解了。模型的表现会变得非常的好。

我们的内测用户的反馈也印证了我们的想法。大家把 Kimi Chat 玩出了很多新奇的花样，很多人在跟我们讨论一些比较有意思的想法。比如说一种 Lifetime 的 Chat，比如说可以做到像微信里你的一个朋友一样，你一直跟它聊，它可能记着你长达过去一年甚至几年的这种聊天的内容。那你可以随时跟它提，上个月跟你提到的什么东西，怎么样了，会有非常好的体验。再比如说，可能有些人直接把一些连载小说放到我们的模型里面去，让模型帮忙续写，效果也非常好。

刚才讲到了我们公司的愿景是寻求将能源转化成智能的最优解。同时这也是我今天演讲的主题。

Long Context 是我们迈出的第一步。它的确直接解决了很多痛点，也释放出了很多大家没有想到的想象空间。不过我们之所以把 Long Context 列成第一步，还有一个非常重要的理由。

那就是我们认为 Long Context 是解锁模型定制与模型迭代之间矛盾的钥匙。

AI行业一直有一个很严重的问题就是碎片化，也就是说不同的场景会有非常强烈的定制化诉求。

我们跟每一个客户去聊起来，都会迅速的变成定制化，想要 fine-tune 一个自己的模型。

现在想要 fine-tune 一个模型成本是很高的。不管是要去搞数据，还是去做一些工程上的开发。但是大家仍然会咬着牙去做这件事情。那就说明模型现阶段的通用性还不能解决这个问题，定制化还是一个非常强的诉求。

为什么呢？我们跟大量的客户进行了沟通，可以把大家的需求和痛点分成这三类。

首先，客户有非常强烈的差异化诉求。大家最强的诉求是希望“我有你没有”。比如一些投行的客户跟我们去聊。他们希望模型拥有一些独到的见解、独特的分析方法，能帮助他们对公司、对财报做分析。但是这件事情里边重要的是他们要有这个能力，更重要的是别人不能拥有他这样的分析能力。再比如说，有一些客户希望用我们的模型去做二次的封装，去做一些创意或者营销类的工作，他们也会希望有一些别人没有的独特的特色和风格，这些都是差异化的诉求。

第二，客户希望融入自己的领域专有知识。企业客户天然存在非常丰富的领域知识，举一个非常简单的例子，一个公司内部开会，他们用什么样的方式，用什么样的格式去记内部的会议纪要，其实就是一种模型再怎么聪明也没有办法直接知道的信息，必须要用那个公司内部的知识才能得到这个信息。

第三，客户希望模型可以兼容已有的业务逻辑。在绝大多数的现有业务系统里，算法模块的边界已经确定了，这些模块并不能因为要接入大模型，就要配合大模型的行为去调整，这样会跟存量系统无法兼容。

在大模型出现了之后，这几项其实并没有因为模型变聪明了就直接解决了，或者说其实是解决不了的，反而会随着算法能力的增加，大家对模型想象力的放飞，进一步去增强定制化的诉求。

也就是说，客户为了提升自己的行业竞争力，就一定会有这种很强烈的定制化的诉求。而大模型的供应方因为想要迭代模型，也希望控制成本，就会抵触这种过度的定制化。这里就存在一个非常尖锐的矛盾。

而我们认为 Long Context 就是解决这个问题的钥匙。

我们意识到，用 Long Context 可以在上下文里放足够多的信息，当模型接收到足够多的信息时，它的行为就足以达到定制化的水平。比如说：

在角色扮演的场景，我可以把非常详尽的人物世界观定义，这个角色的特点，包括它的一些说话风格，跟其它角色的关联，全部放入模型的上下文当中，那么模型的行为方式和说话风格就非常满足定制的要求了。

在常见的客服场景， 当我尝试把家里汽车的产品手册，还有客服的服务手册完整放到 Context 里面，这个时候模型就能用一种非常标准的客服方式跟我去做沟通交流，能够回答我对这辆汽车的各种各样的问题，可以是一些比较具体的，比如说车灯怎么开这种文档里有的。也可以是一些比较模糊的，比如我觉得灯太暗怎么办。

还有我们公司内部的一种做法。在筛选简历的时候，我们会有一份内部的文档。这个文档是讲解我们如何去筛选候选人的，描述了我们的人才偏好是什么。当我们把这个文档和以往选中和没选中的人才简历都提供给模型时，模型就能直接帮我们筛选简历，而且我们的测试效果非常好。

有了 Long Context 技术，AI 的定制化问题就有了不同的解法。

Long Context：解决 90% 定制问题

现在，我们几乎可以判断，有了 Long Context，在很多情况下就不再需要做 fine-tune 这么麻烦的事情了，Long Context 可以解决 90% 以上的定制化问题。

这个结论可以从很多个层面来验证，我把它简单总结成“多、快、好、省”。

第一个是“多”。我们自己的经验是用 5 万字足以详细地定制一个模型的能力了。一般提示词（prompt）里边可能可以包含像角色的定义，你希望它作为一个什么角色去完成什么样的事情，然后再额外提供给它三到五个类似的样例，这个时候模型的行为就可以被非常充分地定制了。而在做完了这件事儿之后，还剩很多字。因为我们的上下文窗口足够的长，这样日常的使用其实就足够用了。

第二就是“快”。提示词这种定制的方式的效率会远远高于大家用 fine-tune 先要构造数据，然后再从数据中训练的过程。大家可以想象一下，如果今天你要定制一款模型，或者提出一种特殊的需求的时候，一般你手中有的都是一些需求的指令，而不是具体的一些 demo 或者一些样例的数据。那么如果你直接把这个原始的需求直接交给模型，你发现模型它就已经可以做到很多了。

如果要通过 fine-tune 的方式，你可能需要找一名有算法经验的人，根据这些材料去总结生成一份对应的数据集，再用数据集进行训练。而且这个数据集还有一个很重要的要求，就是一定要符合你的业务场景的数据分布。因为万一数据分布不对，或者你生成数据的时候没有考虑到某些情况，模型最后训练出来遇到没有考虑到的情况就应付不了。

更不用提，假设今天突然想临时给线上的系统增加一个新的规则，比如说某些东西我希望它额外提到一下，或者某些内容不要提，那么加一条额外的指令，要比大家完整的去做一次 fine-tune ，再加上最后训练，效率要高得多。

第三个是“好”。提示词（prompt）是一种人类的语言，大家可以用一种可以跟人类交流的自然语言去跟模型交流，它会有天然的兼容优势。这个兼容的优势在于未来可以随着模型的能力提升而提升效果。甚至我们在切换大模型供应商的时候是非常轻松的，你不会被完全绑定。

第四个是“省”。因为在 Long Context 的情况下，模型是同一个标准的模型，所以在调用方不需要去摊销固定的部署成本。比如说像 OpenAI 要 fine-tune 一个模型，单位 token 的成本其实是你调标准模型的十倍之多。那就更不用提写一个 prompt 的成本，还是要比构造数据集去做训练要成本低得多，人员要求和成本也远低于 fine-tune 所需的成本。

通过 Long Context 来做定制化的方法，其实在一些比较著名的国际大厂里面已经验证了，他们有很多的算法工作直接用 Prompt Engineering 这种方式来实现，效率非常高，而且成本也显著地低了很多。

我们自己内部的大量“算法需求”，也会转化成“写一段 Prompt”就可以解决，一般来说迭代的周期也就是五分钟，就可以快速验证一轮，然后去调整细节。

在“多、快、好、省”这几个好处之中，促使我们最终把 Long Context 做成最高优先级的其实是“好”，prompt更好写，也更好向前向后兼容。

我们意识到，当模型有这种兼容性了之后，Moonshot AI 在模型快速迭代、成本持续下降过程之中，我们的用户可以几乎不增加成本地共同享受到成果。大家用 prompt 去专注于自己的业务场景，可以去定制自己的需求，然后去持续的优化。而不会因为用了 fine-tune 而被永远的锁定在我们的某一个版本比较早期的模型上。

也就是说，我们用户可以伴着 Moonshot AI 的模型能力迭代而持续获得收益。

这让我想到了塑造整个计算机行业的摩尔定律。

在几十年前，CPU 的单核性能的发展速度其实是非常快的，就跟现在的大模型一样日新月异。那个时候其实有很多公司会针对某一款、某一代 CPU 去写汇编，去特殊的做优化。他们就会很快发现，这些优化在很短的时间内就变成了一个负资产。因为一旦“特化”了之后，代码就永远锁定了那一代的 CPU 可能没有办法升级，或者升级之后效果表现会不好。不出半年到一年的时间，他们都会被一些比较通用的代码加上最新的CPU给远远的甩在身后。这些公司的竞争对手可能什么都没有做，就等了一段时间，还省了固定的成本，就吃到了这个红利。

我们认为这些“特化”工作恰如今天大家想要做 fine-tune 一样，也会遇到相同的问题：跟不上模型的进化速度。

所以我们希望通过 Long Context 来做到这一点，依靠更长的上下文让大家高效地定制模型的行为和特点，从而让每一个用户能够愿意看到我们 Moonshot AI 的模型，每隔一段时间又提升了，又迭代了，效果更好了，成本更低了。

而不是跟我们说，你们又升级了，我老的模型，我老的 fine-tune 那个怎么迁移……

这就是我们把 Long Context 作为迈向公司愿景（寻求将能源转化成智能的最优解）第一步的另一个关键原因。

Kimi Chat：一个好用的助手

最后我再回顾一下 Moonshot AI 基于 Long Context 技术打造的第一个产品 Kimi Chat。

Kimi Chat 拥有非常强的上下文的处理能力，前文提到了有 20 万字的处理能力，同时它支持各类文档的解析功能，可以解析 PDF、Excel、CSV 等各种各样的格式，这些文档你都可以放进去，一次可以放很多条。同时，在缺乏信息的时候，它会像人类一样去调用搜索引擎去看前五到前十个网页。因为 context 非常长，所以它可以把所有的这些网页里的每一个细节都读完，而不是只是读一个摘要。

大家会发现，有了超长上下文之后，长文档的解析和 Web Copilot 这两个功能几乎是非常直接，也非常自然就能想到并快速应用的。

我们通过内测阶段用户的反馈，还发现有些用户非常聪明，他们用 Kimi Chat 完成了一些非常成功的尝试。比如说：

• 把整个源代码放到我们的 Kimi Chat 里，然后跟它说请你帮我根据这份代码编写一个流程图，我要用来去写专利或者软著。他们的专利或软著材料有一多半都可以直接用模型生成，效果非常好。
• 有一些用户在做标书的时候，他把三四封以前自己写过的标书放给模型，说仿照这个标书，你要注意什么？不注意什么？今天请你照着那个写一份新的标书。他们发现模型的效果很好。
• 最有意思的是把整个全文，就是一个很长的英文文档都放到模型里边，但是只贴其中一小段，就跟它说请你只翻译这一段。我们发现在这种情况下，不管是多么复杂的技术文档，模型翻译质量都特别好。因为它有非常充分的上下文，它知道每一个缩写，知道每一个细节跟其它的组件的交互，所以它的翻译质量会非常的高。大家可以想象，非常爱追剧的朋友们可能知道字幕组翻译水平不稳定，也许以后字幕组翻译的时候，也可以利用这种方式，让翻译质量更高。

Moonshot AI 开放平台发布

还有一些用户在内测之后觉得 Kimi Chat 的 Long Context 能力是非常好的，一直在催促我们希望有面向开发者的 API。

从今天开始，我们的开放平台也启动内测申请了。

大家可以扫描上方右侧的二维码申请。我们非常希望有想法、有创意的用户能够跟我们一起探究将能源转化成智能的最优解。我们会持续提升模型的能力，并且持续地降低使用成本。

谢谢大家。