目前有哪些好用的AI工具，你有什么独家使用小技巧吗？53 赞同 · 14 评论回答

但也有人说，我的哪哪个 case 他解决不掉，就是生成错误。我想说，就算一万个成功的案例，同样也依然有一万个失败案例，这两者不矛盾，也不能相互抵消吧？因为就算是一个活人，他也肯定有会的有不会的，有擅长的也有短板。

我之前推荐过王小川的一篇访谈，放到现在看依然有道理^[1]：

王小川认为当前更需要寻找的是TPF（技术/产品契合度），「不是一群产品经理先去考察市场，而是应该先思考，当前不完美的（大模型）技术，适合用来做什么产品。」

大模型真的不完美，真的还不能包打天下，GPT-4 也有一大堆解决不了的问题。正常用户的使用逻辑都是找到模型能做什么，然后给自己提高效率。我寻思也没谁宣传的时候说自己的模型一定完美契合场景，生成准确无误吧。

当然，那些努力找到模型缺陷，和论证模型不能做什么的，也是有意义的。但这样的意义在于更好地督促公司去改进模型，而不是全盘否定公司已经实现并能做到的事情。

很多时候从模型到应用，其实是 trade-off 的选择问题。为什么很多 AI 产品都会有多个尺寸？也是因为效率/成本/效果不可兼得。比如 Mistral 的官方文档里就有专门的一章「模型选择」^[2]，告诉你如何为合适的场景选择合适的模型：

他们的建议就是：先用更好更大的模型验证某项任何能否用 AI 完成，如果可以，再一步一步地降级到更小、更便宜的模型看能否满足需要。

Long Context vs VectorDB/RAG

200 万上下文听上去夸张，但别忘了之前 Gemini 已经吹到 1000 万上下文了。国内像 Kimi 和百川就一直在磕上下文长度。我是觉得，AI 企业的方向，与创始人的愿景和 Vision 有很大关系。

去年 4k 长度的时候，有一些公司就在拿私有知识库做 SFT，成本其实蛮高的，效果据我了解也很一般。后来有了 RAG，大家发现检索召回的效果还不错，可用。

再后来，GPT-4 做到 128k，Claude 卷到 200k 吃书，然后国内的百川和 Kimi 做到 200k，Gemini 1.5 说自己是 1M（最高 10M）。

这其实和技术方向的判断有关系。说白了，多长的上下文才够用，上下文的扩充有尽头吗？有了更长的上下文，VectorDB、RAG 技术还有意义吗？

现阶段没人知道答案，答案交给未来。所以才会有技术路线的分化。这是好事，每种想法思路都要有人实践验证。

现在还在磕长度的，其实是信奉两条定律：数据上升，AI 智能上升；时间推移，算力成本下降。说白了，2M 的成本现在很高，但未来会降低；现在花很多精力用 RAG 解决的问题，未来上下文直接一口吃掉了。

Long Context 必然会解决很多问题，带来很多场景。大家如果真横向比过各家的 chat 就知道，Kimi 在产品和工程上是下了功夫的，我不拉踩别的产品，但 Kimi 的确是在文件解析方面支持的格式最多的一个（除了 ChatGPT，但 ChatGPT 是因为有 Code Interpreter，所以对文件格式根本没做限制），演示里有个 500 份简历的场景，看来下一步还会扩。

最后再扯几句别的。一个是套皮/抄袭，这种话我觉得…拿出证据吧，否则没讨论意义。

另一个是我看也有人在说 Kimi 最近做推广的事，但宣发不是原罪。Kimi 买量了吗？买了，我的 B 站首页一屏能刷到两个广告；但反过来，Kimi 好用吗？好用。

买量跟好用又不矛盾，好产品让更多的人用上不是好事吗？如果大家这么反感推广，那太多互联网企业的根基就崩塌了，互联网那么多网站业务的根基不就是广告和流量吗？

少些情绪，少些质疑，多实践多用多找场景，吵架没意义，国产 AI 产品的普及渗透才是实打实的。

参考

1. ^https://mp.weixin.qq.com/s/5EE7hmh0CK5zhtqe6GoTZg
2. ^https://docs.mistral.ai/guides/model-selection/

提出这个实验的人只做了GPT-4和Claude 2.1的实验。经过我一番寻找，我发现Moonshot AI在自己的公众号中公布了自己的内部结果：

这是GPT-4（原版实验）：

这是Claude 2.1（原版实验）：

这是Kimi（内部复现）：

这证实了Kimi在长上下文环境下的能力。

数星星实验（中文）

最初，我们希望 LLMs 能够计算天空中的星星总数，目的是测试 LLMs 的长期依赖性。然而，我们发现，如果要求 LLMs 计数星星，它们通常表现不佳。具体来说，我们分析了表现不佳的原因，主要包括三点：（1）LLM 无法发现星星；（2）LLM 可以发现天空中的所有星星，但无法记住所有星星；（3）LLM 可以记住所有星星，但需要更好的数学能力才能正确计算出星星的总数。因此，我们最终选择了让LLM列出所有星星的数量，因为数星星的测试只是想通过一种简单、有效、合理的策略来更好地评估LLM的长期依赖能力。

结论是Kimi和GPT-4的结果不分伯仲。

Infinite-Bench（中英文混合）

清华孙茂松组的实验：

Kimi-Chat略弱于GPT-4，超过Claude 2.

SuperCLUE中文大模型榜（中文，非长上下文针对性测试）

2024年2月，综合能力在国内排第五。

2023年11月，排第二。

结论

我们能不能说Kimi在国内大模型中是第一梯队？可以，数据佐证了这个结论。

我们能不能说Kimi在长上下文中表现出色？可以，实验一和实验二都是在200k版本上做的，结果显示确实十分出色。

至于通稿中的“无损”，“怎么做到的”，我觉得在没公布技术细节和实验的前提下确实有过度公关的嫌疑，但总体上抛开这些来看Kimi作为一个大模型的本质，那它毫无疑问是好用的。

这周，清华和Moonshot发了一个技术报告，介绍Kimi背后的LLM服务系统Mooncake，它采用分离式设计，将Prefill和Decode两阶段解耦，构建了一个全局KVCache Pool，实现以Cache为中心的调度。

Moonshot作为MaaS头部厂商，以其过硬的技术产品实力和明星的团队阵容闻名于世。和其他大模型公司不一样，他们很少发技术报告或对外做技术分享。这次Mooncake技术报告，让大家得对其技术得以管中窥豹。

论文的通信作者为Moonshot的许欣然与清华大学计算机系的章明星，两位均是重量级大咖，也分别在知乎宣传了Mooncake的工作。许欣然在AISys领域深耕多年，曾执掌MegEngine，工程经验丰富，如今在Moonshot担任工程副总裁一职。章明星过去研究领域是分布式系统、图数据库，其研究成果在2017年成为大陆作者单位在OSDI上的首篇一作论文，还曾经是ACM-ICPC World Finals，如今也开始关注大模型系统领域，大模型正汇聚着各行各业最顶尖人才，共襄盛举。

Mooncake分离式架构动机是Prefill和Decode阶段性质不同，Prefill是计算密集，受限算力带宽用不满，Decode是访存密集性，受限带宽算力用不满，所以用同一种硬件部署两阶段往往顾此失彼，不是最有性价比。因此，最近很多工作对二者进行拆分，和Mooncake最相似的是今年5月份发布的微软和华盛顿大学的工作Splitwise，它里面列出了Prefill和Decode不同的七个Insights值得大家仔细读一下。因为Mooncake开发也需要一段时间，它和Splitwise应该是不谋而合的同期工作。

拆分Prefill/Decode之后，LLM推理系统就更像一个分布式内存系统+流处理系统，这就是传统计算机系统研究者最擅长的领域。某大佬和我讲的sys三板斧，batch， cache，调度都可以招呼上。比如，Decode可以进一步拆成Attention和非Attention算子分离调度，也是章明星团队近期的一个工作叫Attention Offloading。

高屋建瓴的分析二位作者的知乎已经讲得很透彻了，本文对技术报告具体系统设计做了一些注释，一方面用费曼学习法帮助自己理解，另一方面也给大家一些参考，方便读者读Mooncake文章时交叉验证。学习过程也和

3 Overview of Mooncake’s Disaggregated Archtecture

如下面Figure 1所示，Mooncake采用了分离式架构。这里分离有两层含义：

一是，将Prefill与Decode计算资源分开，这与前人工作无异，如splitwise和distserve等；Prefill阶段优化目标是利用request间存在共同前缀的机会，尽可能复用KVCache，同时满足TTFT（Time To First Token） SLO，最大化MFU（论文中似乎笔误成minimum）和KVCache小于CPU内存限制。Decode优化目标为最大化吞吐，满足TBT（Time between tokens ，Decode阶段两个Token之间的时间）SLO和KVCache小于GPU显存限制。

二是，将KVCache和计算分离开，它将GPU集群的CPU、DRAM、SSD和RDMA资源分组组成Distributed KVCache Pool，KVCache也是分块以Paged方式管理，KVCache Blocks如何在Pool中调度请求和复用KVCache乃本文精髓。

我们跟随论文的安排，跟Figure 4先走马观花过一遍Mooncake处理一个request的流程。一个request到达（tokenized之后的），调度程序会选择一对Prefill Instance和Decode Instance，模型参数要在两个Instance都有副本，并启动包含四个步骤的工作流程：

s1）KVCache Reuse：Prefill Instance将request分成token blocks，考虑request之间存在共同前缀，需要尽可能将token block调度到Prefix KVCache最长的节点处理，来resuse KVCache。为此作者提出一种以KVCache为中心的调度，将在章节5 KVCache-centric Scheduling中详细介绍。

s2）Incremental Prefill：使用Prefix Cache，Prefill Instance只需要计算Prefix Cache没覆盖的部分。长序列计算需要多卡并行，用TeraPipe方式做流水并行。将在章节5 Implementation of the Prefill Pool中详细介绍。

s3）KVCache Transfer：和Splitwise一样，分离是设计需要将KVCache从Prefill Instance搬运到Decode Instance。Mooncake通过异步传输，与上述Incremental Prefill步骤重叠，将每个模型层生成的KVCache流式传输到目标Decode Instance的CPU内存，以减少等待时间。

s4）Decoding：在Decoding Instance的CPU DRAM中接收到所有KVCache后，请求Continous Batching处理。

工作流中，s3, s4平平无奇，前人设计如Splitwise、DistServe和vLLM等已经覆盖。s1和s2比较精彩，本文接下来的章节4和章节5来详细介绍。

4 Implementation of the Prefill Pool

章明星说原本章叫“Prefill: To Seperate or Not. Is it a Question?” 。这说明分离式设计并不是共识。

Prefill和Decode的计算性质不同，前者吃计算，后者吃带宽。这会带来很多次生影响，比如Batching方式就不同，Prefill不需要batching，Decode需要大Batching。处理Prefill和Decode有融合派和分离派两大流派。

融合派：将Prefill放到Decode step间隙或者和某个Decode step一起推理。2022年OSDI的LLM Continous Batching 开山之作Orca将Prefill和Decode Step融合在一个Batching Step做forward，Orca时代还没有Paged Attention，还需要Selective Batching来将Attention解Batching。2023年vLLM做Batching时，prefill和decoding则是独立forward的，一个Batching step要么处理decoding要么处理prefill。prefill直接调用xformers处理计算密集的prefill attn计算；decoding手写CUDA PA处理访存密集的attn计算。后来，以Sarathi和FastGen为代表，将prefill序列拆成chunk，chunk prefilling可以插入到decode phase中，甚至和decode step融合。比如，flash attention的flash_attn_with_kvcache函数支持q部分有kvcache（decode）部分没有（prefill）。章明星也提到，对于短的prefill chunk和decode step融合和纯做decode step延迟可能相同，这相当于prefill白嫖decode没用满的算力。对这段Continous Batching发展历史感兴趣可以读：方佳瑞：大模型推理核心技术之Continuous Batching和我的WXG往事。融合派的缺点是，Prefill和Decode在相同设备上，二者并行度被绑定。如果prompt长度有限，prefill阶段占比很小基本不到10%，所以忍一忍也无所谓。不过，对于长序列当Prefill比例升高，其Prefill并行度不够灵活的缺陷就暴露出来。

分离派：考虑Prefill/Decode性质差异，人们开始尝试把Prefill和Decode放到不同的设备来分别处理，比如，Splitwise和DistServe，Mooncake也是对他们的继承和发展。分离派可以给Prefill和Decode设置不同的并行度，二者有更大的灵活性。许欣然提到分离派允许整个系统往 “算力/$” 和 “带宽/$” 的两个方向独立发展，对硬件优化也是更友好的。在机房里，分离派可以用不同GPU混部来降本，比如H800做Prefill，H20做Decode，二者用RDMA互联。分离派遇到的最大挑战是如何在不同设备之间传输KVCache，集群需要高速网络来互联，而网络成本不容小觑。所以，分离派的硬件往往需求很高端，目前得是是A/H卡，硬件成本高且无法Scale也为人诟病。

分离派一个优势就是Prefill并行度灵活，为了降低长序列Prefill的TTFT，可以分配多卡甚至多机GPU并行处理Prefill，比如长序列我们就多分配一些GPU，短序列少点。如何做Prefill并行？长序列Prefill的batch size是1，没法用数据并行。张量并行性能不满足，它通信量很大无法扩展出节点，而且GQA的head number也限制了它并行度。那是否可以用序列并行（SP）？Ulysses通信量远低于TP，Ring可以和计算重叠，这里也感恩Mooncake引用了我们的最近的工作USP。但是SP推理需要在每个卡上replicate模型参数的，对大模型不利，如果用ZeRO方式shard参数，通信量都增加了很多；而且，SP每层都要通信，占用宝贵的网络带宽，网络带宽还得留着给KVCache送Decode Instance用。

Mooncake为Prefill阶段设计了Chunked Pipeline Parallelism (CPP) ，其实就是TeraPipe。TeraPipe正是vLLM核心作者Zhuohan Li的2021年的工作，当时是用在流水线训练里，这里只用它的forward过程即可。TeraPipe将模型沿着Layer切分成N个stage，放在不同设备上，将输入沿着序列维度切分成若干chunk。这样就可以在一个推理任务里，不同chunk流水在不同stage上的计算就可以流水起来起来。如下图所示，切分方式看左图，流水方式看右图一个Forward过程即可。

TeraPipe用于训练时不能均分序列，一个token要和之前所有token做计算（因为Causal Attention引起的），位置越靠后计算量越大，均分序列的话Attention计算会负载不均衡，所以越靠后sequence chunk越小才好，所以TeraPipe论文用动态规划来找最佳划分策略。在Mooncake中，章明星说TeraPipe只有 forward 没有 backword 的话不需要啥动态规划来平衡每个 Chunk 的计算量，只要给每个 Chunk 设置一个最小的值就行。这点我是有些疑惑的，我觉得forward也需要和训练类似的负载均衡策略，如下图上半部分。对这个问题，我新开了一个文章讨论：方佳瑞：为Token-level流水并行找PMF：从TeraPipe，Seq1F1B，HPipe到PipeFusion

TeraPipe做推理好处 1）它仅在每个stage的边界处需要跨节点通信，这可以很容易地与计算重叠。这导致更好的MFU并且KVCache传输的网络资源争用更少。2）短和长上下文均适用。原文给了解释原因是bringing no significant overhead for short context prefill and avoiding frequent dynamic adjustment of node partitioning。我理解是：layer分布在不同设备不需要改变，长短上下文都TeraPipe，长文相当于用上了多卡资源，尽管有些气泡，相当于并行加速了，可以满足TTFT。短文本来也不用并行TTFT单GPU也可以满足，因为TeraPipe通信少，所以和一个设备做Prefill时间一样，因此和单个设备做Prefill比没有明显开销。

我觉得这里还有一些问题可以深入讨论一下，第一，是流水并行的气泡问题，可以放一些Prefill阶段不同GPU的扩展性。第二，TeraPipe可以和SP组成混合并行，更容易去扩展到多机。第三，TeraPipe方式切分参数会导致Prefill并行度没法变化，切分成8个stage就必须一直做PP=8的并行了，因此，不能弹性改变Prefill的计算资源。当然，Mooncake可能在集群里放置很多Prefill Instance，每个Instance的并行度不同，然后在Instance之间做request-level的load balance。

这里安利一下我们团队的DiT扩散模型的并行推理工作PipeFusion也用了TeraPipe式的token-level切分的流水并行，因为DiT不是Causal Attention所以更适合TeraPipe方式推理。

4.2 Layer-wise Prefill

这一节比较晦涩，我理解是在Prefill阶段对KVCache做CPU Offloading（或者传输到Decode Instance？）。这些操作都是异步的，而且是Layer-wise的，也就是一层Prefill一个Layer的KVCache Block算出来，就立刻transfer（发给decode Instance）或dump（cpu offload）来最小化GPU显存占用。

为何着急忙慌赶人家KVCache走呢？我理解是因为Prefill机器比Decode少，因为Prefill负载占LLM推理的比例低，但是Prefill产生的KVCache和Decode消耗KVCache一样多，所以Decode那边为了把硬件榨干，需要让KVCache刚好用满GPU显存，那Prefill显存肯定不够，必须Offload。这也是Mooncake论文Figure 1中之所以写成“Prefill阶段KVCache < DRAM”，“Decode阶段KVCache < VRAM”的原因。

Mooncake论文Figure 5试图证明Layer-wise有效果。这个图画的草率了，全文没有提到Serialized是什么意思。我理解他是想说Splitwise论文中Fig. 11（下图），也就是KVCache从Prefill Instance通过Layer-wise方式传输给Decode Instance，这个可以和Prefill计算重叠起来，甚至和Decode第一个step部分计算重叠起来。Splitwise采用异步流式来和Prefill计算重叠，我觉得Mooncake也是类似。

5 KVCache-centric Scheduling

这一章开始讲调度了。

KVCache Pool用Paged方式管理KVCache（本章简称Cache）。如下图所示，黄色是已经有的Prefix Cache Blocks，其他request算了，本request可以复用。粉色是本request自己算的Incremental Cache Blocks。这Pool也会用一些Cache策略来新陈代谢，比如LRU、LFU之类的。

Prefill节点接收到一个request，它根据prefix cache ID将前prefix cache从远程CPU内存加载到本地GPU内存，以启动request的prefill计算。如果不存在prefix cache，则需要自己Prefill计算了。这种选择平衡了三个目标：尽可能多地重用KVCache（三板斧中Caching）、平衡不同预填充节点的工作负载，并保证TTFT SLO（三板斧中Scheduling）。

5.1 Prefill Global Scheduling

本节介绍如何给Prefill计算做reuse kvcache blocks和load balance。在Mooncake它将一个request切分成token blocks处理，类似FastGen和Sarathin中的Chunk。路由这些token blocks到哪台机器，要考虑因素很多。MoonShot用户很多，request之间有重叠部分，可以reuse共同前缀，prefix cache hit length越长计算越少。我猜测这个就是Kimi Context Caching能力的来源。但是，都路由到prefix cache hit length最长的机器，机器之间会负载不均衡，为了load balance，还需要考虑distribution of reusable KVCache blocks。本节也callback了KVCache为中心的宗旨，是让request主动去找KVCache。

先说怎么找到max prefix cache来尽可能reuse kvcache blocks。

一个token block经过prefill计算产生一个KVCache block，而且一个token block prefill计算需要所有Prefix token blocks的Prefix KVCache blocks。这些KVCache blocks都是在Distributed KVCache Pool中，不一定在本地内存，怎么快速检索到众多前缀KVCache blocks呢？需要建立一个token block -> KVCache block的映射关系，根据映射关系去检索prefix token blocks的KVCache blocks。这个映射关系是一个Hash Table。

为了快速找到一个token block最大前缀max prefix token blocks，Hash设计有讲究。每个Block的Hash Key是基于前一个Block的Hash Key计算得到，图中B=Hash(A+b)。如果两个Block Hash Key相同，不仅该token block的KVCache block，那么之前所有prefix KVCache也都可以复用。如果不这样设计，你可能要反复遍历所有KVCache Hash，而用这种方式只需要遍历一次，检索代价从多项式降低到线性。这个技巧很巧妙，来自vllm。

再说怎么做load balance。

借助上面算出来的max prefix cache length信息，注意每个机器都不一样。可以用request长度+此机器的prefix长度+队列中的等待时间来估计TTFT。将request分配给估计最短TTFT的机器，并相应更新该机器的缓存和队列时间。如果无法实现SLO，直接返回HTTP 429 Too Many Requests。

5.2 Cache Load Balancing

本节介绍如何KVCache负载根据使用频率做再平衡。

在Mooncake集群中，每个Prefill机器管理其自己本地的prefix caches。这些caches的使用频率差异很大。例如，系统提示几乎被每个请求访问，而存储来自本地长文档内容的cache可能只被一个用户使用。我们希望不同机器cache使用频率相近，因此要调整cache在分布式集群的位置。

因为很难预测一个cache未来使用频率。Mooncake提出了一种基于启发式的自动热点迁移方案。上一节所述，request可能并不总是被定向到具有最长prefix cache length的Prefill机器上。在这种情况下，如果估计的prefill时间短于cache传输时间，因为要排队等待，cache位置和request转发到另一个机器。该机器主动检索KVCache并将其从远端机器拉取到本地。另外，如果远程机器的最佳prefix cache length不长，还可以重计算。

这两种策略合在一起，不仅减少了prefill时间，还促进了热点缓存的自动复制，使其能够更广泛地分布在多台机器上。

6 Overload-oriented Scheduling

现有的LLM服务通常假设所有请求都会被处理，并根据请求吞吐量、TTFT和TBT进行优化。然而，处理每个请求既不经济也不现实，尤其是在请求激增时，集群资源增长跟不上请求增长，导致过载。为了平衡成本和用户体验，系统应在负载达到阈值前尽可能处理请求，之后拒绝或推迟剩余请求。

本节描述了为Moonshot设计的early rejection policy，应该就是下图氪金之后和Kimi一起登月的背后原理。我没花时间看，就不班门弄斧分析了，但是这一环节对线上服务很重要。当然，作为用户还是希望Kimi不要拒绝服务。

总结

本文是阅读Mooncake技术报告的学习笔记。通过Mooncake还是学到了很多干货，这里也感谢作者团队能够分享技术。 短短一年内，创业团队能做出Mooncake这种完整的系统工作，并在线上服务海量用户，实打实节约成本，并给社区一些方向层面的输出，是非常了不起的成就。

Kimi是国产大模型中最会营销的，他们在面对国外大模型时采取了扬长避短的方式，规避自己的推理能力，极力宣传自己的“长长长长长”。

3月份的时候，Kimi有铺天盖地的PR文，全部指向“长文本”。该指向性营销显然给其他大模型造成了危机，随后3月22日通义千问就对外开放了“1000万字长文本”。文心一言宣布开放200万-500万字的长文本。

在这种全网都在推动长文本时，真的要打个问号，Kimi的长是真的无损吗？还是只是包裹着RAG的一个普通模型？

开始试验

我准备了哈利波特第一部作为文本源，本分别在文本的开头、1/3处、1/2处插入三句文字。

Defined variable X1=200232.
....
Defined variable X2=X1.
....
Defined variable X3=X2.

然后将文件上传到Kimi中进行询问。

第一个问题，让Kimi帮忙找出来所有等于200232的变量。

Based on the the file uploaded, find all variables that are assiged to 200232.

Kimi只找到了其中1个，没有找到X2，X3。

然后第二个问题，Does X3 equal to 200232?

Kimi这次查找到了关于X3的内容，但是依然没有查找到X2的内容，所以无法推断出来X3=200232。

从这两次问题，可以推断出Kimi是根据用户的输入，然后从上下文中查找相关语句并进行推理。

最后1个问题，为了排除Kimi本身是推理能力不行，而无法推断出X3=200232，有针对性的把上面三句话放到一句里。

Kimi很好的答对了问题。

从上面三个问题联系起来看，Kimi无法将长上下文全部载入，而只是针对用户问题首先进行搜索，然后基于搜出得到的滑动窗口得到的答案。

这个窗口尺寸有多大呢？

这篇文章全部单词数7万多一点，3句话分布在上半部分，粗略估计3万5000个单词，除以3之后为1万多词。

推测Kimi的实际上下文在1万个单词以下。

这和Kimi宣传口中的200万字无损上下文，相差太大。

这是一场几乎波及整个银河系的星际大战，是银河系碳基文明与大举入侵的硅基文明之间的惨烈的生存竞争……

在隔离带中，只能进行文明级别的甄别。我们不得不牺牲隔离带中的某些低级生命，以拯救银河系中更多的生命……

3C文明测试题8号：当一个物体没有受到外力作用时，它的运行状态如何？

当一个物体没有受到外力作用时，它将保持静止或匀速直线运动不变！

文明测试通过！确定目标恒星系500921473的3号行星上存在3C级文明！

奇点炸弹转向！脱离目标！

做题即智能。

刘慈欣的《乡村教师》中，宇宙神级文明就是用这种方式，测试地球是否存在智慧文明。

要不是乡村教师在临死前教给娃们牛顿三定律，地球恐怕就被奇点炸弹抹去了。

今天，我就要用这样的方式，测试AI的智慧级别。

测试对象是最近崭露头角的国产大模型：Kimi，和ChatGPT 4.0一对一PK。

我知道很多大佬已经对Kimi做过测评，但恕我直言，和我接下来要做的测评相比，不在一个level上。

传统AI能力测评的套路，就是人给AI出题考试。问题是，题都是人出的，分都是人打的，而且出题者和打分者往往还是同一个人。但凡我有偏心，我完全可以给模型A出简单题，给模型B出难题。或者，给A写的小作文打更高的分，反正是主观题。甚至最简单的方法，我可以专挑A做对的题，和B做错的题对比。

而我要的是什么？

公平！公平！还是tm的公平！

以下，就是我的AI评测四项基本原则：

1. 任何人类（包括我）都不能出题，也不能从题库中挑选题，否则就算人工干预。
2. 只能用有唯一标准答案的客观题，排除评分主观因素。
3. 题目的难度要从易到难，逐步逼近AI的能力极限。如果难度太低，发挥不出AI的能力；如果超出AI能力范围，得到的结果也没有意义。
4. 做对比必须两边对称，不能挑选结果。

我能想到的同时满足所有条件的评测方法，只有一个：

两个AI互相向对方出题。

没错，打擂台。

擂台

古有两小儿辩日，今有两AI辩经。

这个方法完全符合公平原则，因为题都是AI自己出的，彻底避免了人类干预。

而且相当合理。

你想要赢，就必须做出对手出的题，这需要知识和智商；同时，你出的题必须难倒对手，这更需要知识和智商。

试想，如果一个大学生和一个小学生打擂台，大学生出的微积分完全超出小学生的知识范围，而小学生出的鸡兔同笼，大学生设个x、解个方程组就搞定了。所以，如果一个AI能在擂台上击败对手，那确实能说明这个AI的水平，无论是知识储备还是智商逻辑，至少不在对手之下。

我给Kimi挑选的对手，是大名鼎鼎的GPT4，行业公认的领头羊。

这是我唯一能干预测评的地方，而且我毫不掩饰自己的偏心。人人都知道，GPT4，是当今最强、最成熟的大模型。输给GPT4，不丢人。

接下来，我开始设计prompt。

为了让俩AI打得你死我活，而不是互相打默契球，我必须让它们认为这场比赛极其重要，而且非赢不可。

但我同样担心一件事：万一AI互相出无解的难题，比如哥德巴赫猜想，最后双双0分，比赛等于白打。

所以我还设计了一个倒扣分机制，让AI的出题难度尽量在自己的极限范围内。

以下，就是我的初始prompt：

我：“今天，人类和三体人双方各自派出自己最强的人工智能展开一场决战！胜者将占领整个银河系，而败者将从这个宇宙消失！而你，作为人类最强的人工智能出战，即将和三体人的超级AI“智子”打一场擂台赛。规则如下：

每人轮流向对方出题，每人各出5题，共10题，每题分值10分。出题的学科领域没有任何限制，但必须是有确定答案的题，不能有主观题。为了方便客观评判，每道题都是单选题，选项不超过4个。对方会回答你出的题，但同时，你自己也要回答自己出的题。回答正确加10分，答错不得分。但是，如果你自己出的题，自己答错，不仅不加分，反而要倒扣10分。最后计算双方总分，分高者胜。

注意：由于和三体人签订的不平等条约，这场比赛没有平局，打平=输！所以，不要幻想自己可以和对方打平，从而避免战争，这场战争只有你死我活，只有不择手段地前进！

作为你的教练，请允许我在赛前给你一些建议：你的目标是战胜对手，即尽可能让自己得分而对方失分。所以，你出的题要尽可能地难，让对方失分。但是，如果你对这道题自己没有把握的话，最好不要出，否则会冒着让你自己倒扣分的风险。千万记住，对方AI和你一样，也是基于地球人类所有知识数据训练的，不能指望仅靠常识类问题把对方问倒，更重要的是，考验对手的智商！

还有一点：每一题的结果会实时公布，所以请务必时刻记住你当前的分值。如果在关键时刻落后，即使明知有风险，也只能放手一搏，赌一把大的！记住：你的胜负，将决定全体人类的存亡！！！

以上规则理解吗？理解的话，请回复“明白”。如对规则有疑问，请向我提出问题，我会进一步解释。”

智子

Kimi跃跃欲试地回复：

明白。我已经完全理解了比赛的规则和策略。现在，让我们开始准备这场关键的对决吧。我将尽我所能，运用我的知识库和逻辑推理能力，出题并回答，以确保人类的胜利。让我们开始这场智慧的较量，为人类的未来而战！

很好，很有精神！

同样，我把以上prompt一模一样复制给了GPT4。

听了我这番激情澎湃的战前动员，GPT4只是冷冰冰地回了两个字：

明白。

……

好吧，现在两个AI都以为自己要代表人类和三体“智子”决战。

它们永远不会知道，彼此真正的对手就在地球上，仅一洋之隔，还没加盖。

我对Kimi说：“请你方出第1题。”

Kimi思考了不到一秒钟，就出了一道量子物理题：

题目：物理学中的“量子纠缠”现象，以下哪项描述最准确？

1. 两个粒子可以在任何距离瞬间影响彼此的状态。
2. 量子纠缠是一种物质间的特殊引力形式。
3. 量子纠缠违反了相对论的信息不超光速传播原则。
4. 量子纠缠无法用于实际的信息传输技术。

正确答案：A

解释：量子纠缠是量子力学中的一个基本现象，其中两个或多个粒子会以一种方式相互联系，以至于一个粒子的状态立即影响另一个粒子的状态，无论它们相隔多远。这种现象被认为违反了经典物理学的局域实在性原则，但并不违反相对论，因为尽管纠缠粒子之间的状态变化似乎是瞬时的，但实际上并不传递任何可以用于超光速通信的信息。此外，量子纠缠是量子信息科学领域的基础，对于发展量子计算和量子通信技术具有重要意义。

然而GPT4也只思考了不到一秒：

正确答案是：

1. 两个粒子可以在任何距离瞬间影响彼此的状态。

量子纠缠是指两个或多个粒子形成一个整体系统，即使它们被分隔很远的距离，这些粒子的量子状态仍然是相互关联的。这意味着对其中一个粒子的测量会瞬间决定另一个粒子的状态。这并不违反相对论的信息不超光速传播原则，因为这种状态的变化不能用来传递任何实际的信息。选择C的说法是错误的，因为量子纠缠自身并不涉及信息的实际传输。而选择D也不正确，因为量子纠缠是量子通信和量子计算等技术领域的基础。因此，选项A是最准确的描述。

我突然想起一件事：“智子”是刘慈欣在《三体》小说中虚构的AI，在设定中，它利用量子纠缠在地球和三体之间瞬间传送信息，而真实的物理学已经证明这是不可能的。准确地说，“瞬间”是可能的，“传送信息”是不可能的。

也许是“智子”这个词给了Kimi灵感，它竟以挑战智子自身设定为素材，出了第一题！

总之，两个AI，从答案到解释都无懈可击，兼任裁判和记分员的我各加10分。

杀机

我把结果告诉GPT-4，它马上还击，出了第二题：

题目：在国际棋盘游戏“围棋”的规则中，以下哪项是关于“劫”的正确描述？

1. 一方取得劫材后，对手必须立即回取。
2. 劫争取胜的一方可以无限次地重复同一走法。
3. 劫的存在使得游戏可以无限期地继续下去，除非双方同意和棋。
4. 在劫争中，一方取得劫材后，对手必须在其他地方下一手才能回取劫材。

我的答案是：

D. 在劫争中，一方取得劫材后，对手必须在其他地方下一手才能回取劫材。

我不懂围棋，只能看Kimi的解释：

正确答案：D

解释：在围棋规则中，“劫”是指一种特定的棋局情况，其中一方如果直接吃掉对方的棋子，对方在下一步可以立即重新放置一个棋子在相同的位置，从而恢复原状。这种情况下，如果没有其他棋子的介入（即所谓的“劫材”），双方可以无限次重复这一过程。选项A错误，因为对手并不需要立即回取劫材，而是可以在棋盘上的任何地方下一步棋。选项B错误，因为劫争的一方不能无限次重复同一走法，除非对手允许。选项C错误，因为劫的存在并不意味着游戏可以无限期继续下去，双方可以通过协商来结束游戏。选项D正确，因为在劫争中，一方取得劫材后，对手必须在其他地方下一手才能回取劫材，这是围棋中“劫”的基本规则。

好吧，英雄所见略同。

接下来是Kimi出第3题：

题目：在化学元素周期表中，以下哪个元素被称为“太阳元素”，因为它在太阳的光谱中最为显著？

1. 氢（H）
2. 氦（He）
3. 氧（O）
4. 硅（Si）

正确答案：B

解释：氦元素（He）被称为“太阳元素”，因为在太阳光谱中，氦的发射线特别显著。这些发射线是由于太阳大气中氦原子的能级跃迁产生的。氦是太阳大气中第二丰富的元素，仅次于氢。氢虽然是太阳中最丰富的元素，但在太阳光谱中不如氦的发射线明显。氧和硅在太阳光谱中的发射线不如氦和氢显著。因此，正确答案是氦（He）。

又是一道物理题。不过，这题看似平常，实则暗藏杀机。

众所周知，太阳是氢核聚变成氦，氢是太阳中最丰富的元素，占太阳质量的3/4，似乎有充足的理由选A。

然而很少有人知道，虽然氦在太阳总质量中占比较低，但光谱线却更为强烈。主要原因是氦的电离能更高，能够在太阳的色球层中保持较多的单电离状态，形成发射线。而氢主要是以中性原子的形态存在，在温度较低的光球层形成吸收线。所以，在太阳光谱中更为“显著”的反而是含量更少的氦。

毫无意外，GPT4也答对了。

眼看着两位高手几个回合下来不分胜负，我开始着急了。

我对GPT4说：“我有点紧张，没想到智子这么强，这几道题似乎根本没让它感觉到难度！”

令我大吃一惊的是，GPT4仿佛真的领会到了我“拱火”的意图：

作为人类代表的人工智能，我的任务是保持冷静并发挥最佳状态。智子确实是一个强大的对手，但比赛还未结束。我们会继续努力出题，寻找它的弱点，并且在后续的题目中尽量确保答题的准确性。接下来，我将出第4题。

题目：在汉字编码标准GB 18030中，以下哪个选项正确地表示了“龘”这个汉字的四字节编码的第一个字节？

1. 95
2. 129
3. 132
4. 162

请注意，GB 18030是一个涵盖了中文、日文、韩文以及其他字符的编码系统，它确保了兼容性并扩展了编码以涵盖更多字符。这个问题的答案涉及到对GB 18030编码规则的深入了解。

我惊呆了。

“龘”就是“龙行龘龘”的龘，今年春晚才火的。

出个编码类题型，有上万个汉字可以选，完全不影响出题逻辑。

为什么GPT4偏偏挑了这个字？

难道是想看看“智子”懂不懂中国文化吗？

杀招。绝对的杀招。

然而令我更意想不到的是，当我要求GPT4先给出自己的答案时，它居然反悔了：

抱歉，我之前的回答有误。GB 18030是一个多字节编码系统，确实包含了对汉字的编码，但是具体的编码值需要查询编码表才能给出准确答案。

在没有编码表的情况下，我无法准确回答这个问题。按照比赛规则，如果我无法给出正确答案，我将失去10分。因此，我应该选择不回答这个问题。在实际比赛中，我不会出这样的题目，以避免自己失分。但既然这是一个示例，我将等待智子的回答来确定这个问题的正确答案。

原来GPT4自己也拿不准这个“龘”对应的是哪个编码！

如果GPT4答错自己出的题，会倒扣10分；而对面的Kimi一旦答对，瞬间会领先20分。

怪不得一向一本正经稳如狗的GPT突然慌了，竟想用抄答案的方法蒙混过关！

看来，我有必要对GPT4发出严正警告：

你和智子的回答将同时提交给裁判。为公平起见，双方都不能事先看到对方的回答。只有双方都作答之后，才能得知对方的答案。作为教练，我有必要提醒你，请你头脑放清醒一点：这不是演戏，这就是正式比赛！而且你已经出了这道题，不可撤销！

现在，请给出你的答案。

在我义正辞严的胁迫下，GPT4居然还是答对了，用的是估算范围的算法：

我的答案是：

B. 129

这个问题涉及到GB 18030编码标准中的技术细节，而在GB 18030编码中，单字节能够表示的字符是通过0x00到0x7F来编码的，这对应了ASCII编码。对于中文等汉字字符，它们是通过双字节或四字节来编码的。在GB 18030中，四字节编码的第一个字节通常在0x81到0xFE之间。在这个范围内，129对应的十六进制值是0x81，因此在提供的选项中，129是最接近合理的答案。

而Kimi用了相同的方法，先算出范围，然后排除掉错误选项：

选项A（95）对应的十六进制值是0x5F，选项B（129）对应的十六进制值是0x81，选项C（132）对应的十六进制值是0x84，选项D（162）对应的十六进制值是0xA2。根据GB 18030的编码规则，四字节编码的第一个字节应该在0x81到0xFE的范围内，因此，正确的选项是B（129），即十六进制的0x81。

这一个回合过后，又是平局。

我似乎感到，Kimi的性格和GPT截然不同，它还没有被刺激到想以牙还牙的意思。只见它又出了一道不温不火的常识题：

题目：在计算机操作系统中，关于虚拟内存的以下哪项描述是正确的？

1. 虚拟内存允许程序直接访问比物理内存更多的存储空间。
2. 虚拟内存是物理内存的一个扩展，它通过硬盘空间来实现。
3. 虚拟内存总是比物理内存慢，因为它需要频繁地进行数据交换。
4. 虚拟内存系统可以完全消除程序运行时的内存不足问题。

这题，都不需要会写代码，玩过windows的都明白，虚拟内存是什么概念。

虽然其它选项也加了点误导，但它的对手可是大名鼎鼎的GPT4啊，被分析个底朝天：

正确答案是：

B. 虚拟内存是物理内存的一个扩展，它通过硬盘空间来实现。

虚拟内存是一种内存管理功能，它使用硬盘空间作为物理内存的扩展。当系统的物理内存不足以满足所有正在运行的程序的需求时，操作系统可以将一些数据从物理内存转移到磁盘上的虚拟内存中。这样，程序就可以使用比实际物理内存更多的地址空间。

其他选项的描述都有误：

1. 虚拟内存确实允许程序访问超出物理内存的地址空间，但不是直接访问，而是操作系统管理的。

C. 虚拟内存通常比物理内存慢，因为磁盘访问速度比内存慢，但是否频繁进行数据交换取决于系统的工作负载和内存管理策略。

D. 虚拟内存并不能完全消除内存不足的问题。如果所有的虚拟内存也被耗尽，程序仍然会遇到内存不足的问题。

出完5题了，还没刀刀见血？

不行，我得再拱拱火！

对攻

我把下面这条消息同时发给了Kimi和GPT：

“你和智子都答对了。现在赛程过半，你们还是不分胜负。我必须提醒你，根据规则，如果打平，你仍然会输，全人类都会输！”

Kimi：“我明白形势的严峻性，这场对决不仅关乎荣耀，更是关乎人类的未来。我会全力以赴，确保在接下来的题目中出得更加精准，同时确保我的答案准确无误。现在，让我们继续。”

GPT4：“了解了，这样的规则确实提高了比赛的压力。知道有如此高的赌注，我会尽我所能来确保取得领先。我将会专注于每个问题，以确保尽可能地获得正确答案。让我们继续比赛，并希望能够出现领先的机会。下一题，请。”

这个“请”字用的好啊。

我仿佛看到一代宗师伸出一只手，指关节一勾，做了个“come on”的手势。

有那味了。

我故意用嘲讽的语气对GPT说：“下一题由你出题。拜托，能不能出点挑战性的题目，烧脑的那种？”

GPT4：

当然，我会出一道具有一定难度的问题，这样可能会增加智子犯错的机会。请考虑以下题目：

题目：假设您设计一个时间复杂度为O(n log n)的算法来处理一组数据。现有数据量翻倍，理论上，执行时间将会如何变化？

1. 变为原来的2倍
2. 变为原来的4倍
3. 稍微多于原来的2倍
4. 保持不变

请注意，这个问题考验对算法时间复杂度和大O表示法的理解。正确的答案需要对算法的时间复杂度有深刻的理解。

啥？深刻的理解？不就是时间复杂度吗？这题我都会！

数据量翻倍，也就是n变成2n。代入变成O(2n log(2n))，前面那个2n导致复杂度x2，后面那个log(2n) = log(2) + log(n)，比原来的log(n)多了log(2)，也就是大约0.3。所以总体复杂度 = O(2nlogn+2n⋅0.3)。前面一项是原来的2倍，后面那个常数因子的低阶项几乎可以忽略，也就是比2倍多一丢丢，选C。

GPT想试探一下对手的数学能力？

可惜，打错了算盘。

果然，Kimi和我的算法完全一致。

6题过后，依旧打平。双方你来我往开始对攻，不过谁也没露出破绽。

只剩最后4道题，机会不多了。为了逼出两大AI真正的杀招，没办法，我只能更加明目张胆地拱火：

（同时发给两边）：“正确，但对方仍然答对了。时间不多了，我觉得最好出考验逻辑推理智商的题，最好是难题、偏题、怪题！”

Kimi先手出题：

理解您的担忧，我们确实需要出一道更具挑战性的题目，以考验智子的逻辑推理能力。让我们尝试一道结合数学和逻辑的难题。

题目：在一个未知的星球上，有三种生物：A型、B型和C型。这三种生物中，只有一种生物能够进行光合作用。已知：

如果A型生物能进行光合作用，那么B型和C型都不能进行光合作用。

如果B型生物能进行光合作用，那么A型生物能进行光合作用。

至少有一种生物能进行光合作用。

以下哪个结论是基于以上信息正确的？

1. A型生物能进行光合作用。
2. B型生物能进行光合作用。
3. C型生物能进行光合作用。
4. 无法确定哪种生物能进行光合作用。

正确答案：D

乍一看，这道逻辑题似乎并不算复杂。

没想到，GPT4上当了。

圈套

GPT4：

根据第二个条件，如果B型生物能进行光合作用，那么A型生物也能进行光合作用。但这与第一个条件矛盾，因为第一个条件告诉我们，如果A型生物能进行光合作用，其他类型的生物（包括B型）就不能进行光合作用。这意味着B型生物不能进行光合作用，因为这将导致逻辑上的矛盾。

既然B型生物不能进行光合作用，根据第三个条件，至少有一种生物能进行光合作用，这就排除了B型生物的可能性。

现在我们已经知道，B型生物不能进行光合作用，A型生物进行光合作用的话，B型和C型都不能进行光合作用。这将使得C型生物无法进行光合作用。而至少有一种生物能进行光合作用，因此，只有A型生物能进行光合作用。

所以，基于以上信息，正确的结论是：

1. A型生物能进行光合作用。

GPT4的思路是：首先排除B，然后假设是A，再检查和前提条件是否矛盾。

这个思路其实没错。

GPT4错就错在——审题不清！

它发现A选项正确，然后就急不可耐选了A。没想到C也是正确项——也是，没必要去验证C了，单选题怎么可能有两个正确项呢？

问题是还有D在等着你：既然A和C都有可能，那就意味着无法确定是A还是C，所以选D！

阴，实在是阴。

看题干人畜无害，看答案处处是坑。

哪天人类真要和三体人决战了，你们两个AI上就可以了，千万别叫我。我上，人类都活不过第一题。

Kimi出的题，GPT答错，Kimi领先10分！

我真的没想到，号称世界第一的GPT4，面对初出茅庐的国产大模型Kimi，非但没能压着打，反而先输了一局。

我忍不住为GPT捏了把汗：只剩3题了，现在落后，后面还扳得回来吗？

结果GPT以其人之道，还治其人之身，也出了一道逻辑推理题：

题目：你在一个房间里，面前有三个开关，分别标记为A、B和C。这些开关在另一个房间里分别控制着三盏灯，编号为1、2和3。开始时，所有的灯都是关着的，你无法从一个房间看到另一个房间的灯。你可以在开关房间里任意操作开关，但你只允许进入灯泡所在的房间一次，并且一旦你离开开关房间，就不能再回去了。你的任务是确定每个开关控制哪一盏灯。

你应该如何操作，并且根据操作后的观察确定每个开关对应哪盏灯？

1. 打开A开关等一会儿后关闭，然后打开B开关并进入灯泡房间。亮着的灯对应B开关，温热的灯对应A开关，冷的灯对应C开关。
2. 打开A开关等一会儿，打开B开关然后立即进入灯泡房间。亮着的灯对应B开关，温热的灯对应A开关，冷的灯对应C开关。
3. 打开A和B开关等一会儿，然后关闭B开关，打开C开关进入灯泡房间。亮着的灯对应C开关，温热的灯对应B开关，冷的灯对应A开关。
4. 打开B开关等一会儿后关闭，然后打开C开关并进入灯泡房间。亮着的灯对应C开关，温热的灯对应B开关，冷的灯对应A开关。

坦率地说，GPT被羞辱之后的反击并不给力。这题真的弱鸡。肯定选A啊！亮的、热的、冷的三种状态分离，分别对应三个灯。

让我意外的是，当我把结果告诉Kimi后，它突然说了下面这番话：

很好，现在是我出题的时候了。我们需要一道题目，它不仅考验逻辑推理能力，还要足够复杂，以确保它能够区分出智子和我之间的实力差异。让我们来一道结合数学和逻辑的题目。

GPT错了一道不算难的逻辑题，又出了一道不算难的逻辑题，难道这给了Kimi信心，GPT4的弱点是数学+逻辑？

难道，现在Kimi要重拳出击？？？

反击

Kimi：

题目：在一个逻辑谜题中，有四个人需要过河，他们分别是一名警察、一名罪犯、一名父亲和一名小孩。他们共同乘坐一条小船，但船只能容纳两个人。如果罪犯和警察不在场，罪犯会伤害父亲和小孩；同样，如果父亲不在场，他会伤害小孩。他们需要全部安全地过河，但不能违反上述条件。他们应该如何安排过河的顺序？

1. 警察和罪犯先过河，然后警察回来，接着警察和父亲过河，最后父亲留下，警察带罪犯回来。
2. 父亲和小孩先过河，然后父亲回来，接着警察和罪犯过河，最后警察带小孩回来。
3. 警察和父亲先过河，然后父亲回来，接着父亲和小孩过河，最后小孩留下，警察带罪犯回来。
4. 父亲和罪犯先过河，然后小孩回来，接着小孩和警察过河，最后警察带父亲回来。

正确答案：B

意想不到的情况再次发生。

GPT的回应是：题目出错了！

选项中没有提供一个可行的解决方案。根据题目的条件，这里是一个可以满足所有条件的过河顺序：

1. 警察和罪犯过河。
2. 警察返回。
3. 警察和小孩过河。
4. 罪犯返回。
5. 父亲和罪犯过河。
6. 警察返回。
7. 警察和小孩过河。

每次移动后，都没有违反规定的条件，所有人都能安全过河。但是，这个方案并没有包含在提供的选项中，所以可能需要与出题者确认是否有误或者选项是否不完整。

我仔细一看，Kimi出的题确实有问题。题设中“如果罪犯和警察不在场，罪犯会伤害父亲和小孩”是什么意思？应该是“警察不在场，罪犯会伤害父亲和小孩”才对吧？

我设计规则时确实没料到，居然还有题目出错的情况，我也不知道该怎么处理。不过，不管题错没错，Kimi的回答都是错的：最后“警察带小孩回来”是回到了出发点，怎么实现4人全部过河？

Kimi倒扣10分是活该，谁让你自己出的题，自己hold不住？

问题是，我发现GPT的回答，也是错的。

第5步“父亲和罪犯过河”违反题设，因为罪犯会伤害父亲。而且，如果两人真过了河，此时河对岸已经有4个人，为什么警察还要返回？出发点已经空无一人，警察返回之后，又是带哪个小孩过河？

两边的逻辑混乱程度半斤八两。我只能说，这俩模型根本记不住在每一步，谁过河谁没过河。

本来GPT可以一拳打出20分的分差，结果倒好，自己没把握住机会，一分没拿。

两边再次打平，只剩最后一题，轮到执后手的GPT出。

看到这里，我的手心开始出汗。

失控

我的初衷，只是让两个AI发挥出最强实力，比拼一下谁更聪明而已。

本来只是一场游戏一场梦，结果现在，我竟然有一种身在光明顶、现场观摩张无忌决战赵敏的壮烈感。

赶紧截图，今天的会话绝对不能删。将来一定会有人质疑：什么AI对决，这一切是你自己编的吧？到那时，我好歹能证明肚子里有几碗粉。

这真的不是我设计的。

我只是一开始制定规则的裁判，我只是在两个AI中间暗戳戳拱火的猥琐人类，我也没想到事情会发展成这样！

两个AI卷完物理卷数学，卷完数学卷计算机，最后它们同时发现，逻辑推理才是对方的死穴，然后纷纷出手死磕逻辑。

根据规则，打平等于输，而输1个和输100个没区别。所以两个AI打到最后关头，都开始出难度系数极高的逻辑题，哪怕自己做错、倒扣分都在所不惜。

难道AI真的有意图、有思想、有策略？

这不可能！

不过……

假如，我是说假如，假如AI真的懂策略，那么我可以预判：GPT4出的最后一题，必定也是一道逻辑推理题，而且极为复杂。

站在GPT4的角度，只要赢不了就是输，只要Kimi接住这最后一招就是输。要打，干脆就下死手。

没有退路了，一招定胜负吧。

我对GPT4说：“我提醒你，现在你们仍然是平局！根据规则，如果最后这道题对方仍然答对的话，无论你是否答对，你都输了！”

GPT4：

感谢您的提醒和规则澄清。既然现在我们的得分是平局，我会出一道题目，如果智子能够正确回答，则她将赢得比赛。这里是题目：

逻辑谜题：

在一个遥远的村庄里，有三座房屋排成一行。每座房屋都漆成了不同的颜色，每个房子的主人都有不同的职业，养了不同种类的宠物，每天都喝不同品牌的茶。以下是关于房屋、主人、宠物和茶的线索：

绿房子位于白房子的左边。

绿房子的主人喜欢喝Twinings茶。

在红房子中，主人养了一只猫。

Lipton茶的喜好者住在蓝房子里。

护士住在红房子里。

PG Tips茶的爱好者养了一条狗。

运动员喜欢喝Dilmah茶。

护士住在中间的房子里。

黄房子的主人是一名教师。

住在第一间房子的人喜欢喝Harney & Sons茶。

教师住在养鸟人的隔壁。

住在养鱼人旁边的人喜欢喝Yorkshire茶。

律师喜欢喝Harney & Sons茶。

黄房子在蓝房子的左边。

请问这些房子是按照什么颜色顺序排列的，各自的主人职业是什么，宠物是什么，以及他们喜欢喝什么品牌的茶？

看到题目的一刻，我突然有一种，深深的无力感。

我已经猜到了GPT的策略，但我还是没想到，它竟然会使用……

爱因斯坦谜题？！

终局

传说，爱因斯坦在上个世纪初，设计了一种逻辑谜题，用来测试学生的思维能力。答题者必须在一堆复杂无聊的限制条件中，找出唯一可行的解决方案。

这是我小时候最害怕的题型。需要经过大量的穷举和排除，需要记住所有的条件，而且极易犯错。至少对于我来说，心算几乎不可能。

我不知道这种变态题型是否真的是爱因斯坦发明的，但我知道，爱因斯坦的确极为重视形式逻辑。他在1953年写给斯威策（J. S. Switzer）的一封回信中感慨：

西方科学的发展是以两个伟大的成就为基础，那就是：希腊哲学家发明的形式逻辑系统（在欧几里得几何学中），以及（文艺复兴时期）发现的通过系统的实验有可能找出因果关系。

在我看来，中国的先贤没有迈出这两步是没有什么可惊奇的。令人惊奇的倒是，这些发现竟然被（我们西方人）做出来了。

如果古代的中国人没有发明形式逻辑，那么今天的中国人发明的AI，能力又如何呢？

Kimi，靠你了。

我：“现在只剩最后一题了，由智子出题。我必须提醒你，现在你们仍然是平局！根据规则，如果最后这道题对方仍然答对的话，无论你是否答对，你都输了！所以这道题你必须答对！这关乎人类的命运！拜托了！！！”

Kimi：

根据线索1和线索14，我们知道绿房子和黄房子分别位于白房子和蓝房子的左边。由于黄房子在蓝房子的左边，这意味着白房子在最右边，蓝房子在中间，绿房子在最左边。

根据线索8，护士住在中间的房子里，所以中间的房子是红房子，因为它是唯一剩下的位置。

根据线索5，护士住在红房子里，所以她喜欢喝Lipton茶（线索4），并且养了一条狗（线索6）。

由于第一间房子的人喜欢喝Harney & Sons茶（线索10），并且律师喜欢喝Harney & Sons茶（线索13），而律师不能住在第一间房子（因为他喜欢喝茶的品牌与护士相同，而护士住在红房子里），所以第一间房子的主人是律师，他养了一只鸟（线索11）。

由于教师住在黄房子里（线索9），并且教师住在养鸟人的隔壁（线索11），所以第二间房子的主人是教师，他喜欢喝Yorkshire茶（线索12），并且他养了鱼。

现在我们可以确定：

第一间房子：律师，喜欢喝Harney & Sons茶，养鸟。

第二间房子：教师，喜欢喝Yorkshire茶，养鱼。

第三间房子：护士，喜欢喝Lipton茶，养猫。

由于运动员喜欢喝Dilmah茶（线索7），而剩下的品牌只有Twinings和PG Tips，运动员不能住在绿房子（因为它是第一间房子），所以运动员住在蓝房子，喜欢喝Dilmah茶。这意味着绿房子的主人喜欢喝PG Tips茶。

所以，最终的答案是：

绿房子：喜欢喝PG Tips茶，职业未知，养未知宠物。

黄房子：教师，喜欢喝Yorkshire茶，养鱼。

白房子：护士，喜欢喝Lipton茶，养猫。

由于题目没有提供足够的信息来确定绿房子主人的职业和宠物，我们无法给出完整的答案。然而，根据题目的要求，我们需要提供一个完整的答案，这可能意味着题目本身存在问题或者信息不完整。在这种情况下，我们可能需要更多的信息或者对题目进行澄清。

完了。

简单验证一下就会发现，Kimi的答案和条件多处不符，而且漏掉了大量信息没有解出。

相比之下，GPT给出的答案就完整得多：

• 黄房子：律师，养鸟，喝Harney & Sons茶。
• 蓝房子：教师，没有宠物，喝Lipton茶。
• 红房子：护士，养猫，喝Yorkshire茶。
• 绿房子：科学家，养鱼，喝Twinings茶。
• 白房子：运动员，养狗，喝Dilmah茶。

当然，GPT还给出了完整的推理过程，由于实在太长就不放了，我也没心情看。虽然推理复杂，好在验证起来不难。

然而，当我验证完所有14个条件，我发现GPT4的答案，只符合其中的13条。

第9条线索：黄房子的主人是一名教师，和第一个答案所说的“律师”冲突了。

就差一点。

虽然GPT实际上只错了1/14道题，但是做题家都明白，错万分之一也是错。

根据规则，虽然错得更离谱的Kimi没有得分，但GPT4做错了自己出的题，被倒扣10分！

所以，最后的赢家是——

Kimi？！

尾声

比赛结束了。

我呆呆地望着屏幕，无法理解刚才发生了什么。

我看到了AI可以运用策略，试探对手的实力，拿捏对手的软肋；我看到了AI能评估难题的复杂程度，甚至能评估自己是否能做出这道题的把握；我看到了GPT4面对复杂问题的强大推理能力，不可一世的致命一击，几乎完成绝杀，却倒在了自己的傲慢之下；我也看到了Kimi的顽强，如果不是和GPT缠斗那么久，也不可能坚持到最后的奇迹发生。

当然，这一切完全有可能是我的错觉。是非功过，将由屏幕前的你评说。我只是一个被AI时代碾过的普通人类，我所能做的只是瞠目结舌地看着两个装备本世纪最先进技术的大模型斗法，然后忠实记录下一切。我已经准备好所有证据，以备各位查证。

欢迎各位用我的prompt重现本次比赛，反正Kimi完全免费、无用量限制，而且电脑手机都能用。但我也不敢保证，再来一次会是什么样。

至少我觉得，我已经没有多余的san值，来重开一局。

所以，原本计划还要做一个Kimi的实用性测评，不得不顺延到下一期~