Kimi K2.5 技术报告发布：长上下文与推理能力升级

基本信息

导语

随着大模型从单模态向多模态演进，如何平衡长上下文能力与复杂逻辑推理成为技术攻关的关键。Kimi K2.5 技术报告详细阐述了其模型架构的升级路径，重点分析了强化学习在数学与代码能力提升中的具体应用。对于关注模型前沿进展的开发者而言，这份报告不仅揭示了底层优化的技术细节，也为多模态场景下的模型部署提供了重要参考。

评论

深度评论：Kimi k2.5 技术解析

一、 核心技术评价

总体定位： Kimi k2.5 的技术架构标志着行业重点从“预训练规模扩张”向“推理阶段系统优化”的转移。其核心特征在于通过强化学习（RL）与长上下文技术的结合，提升了模型处理复杂任务的逻辑密度与信息留存能力。

技术事实与分析：

  1. 强化学习（RL）的应用： 报告显示，RL 在该模型中不仅用于对齐人类偏好，更被用于提升逻辑推理能力。这反映了行业对 OpenAI o1 路线的跟进，即通过增加推理时的计算量来换取更高的准确度。
  2. 长上下文处理能力： 模型延续了 Kimi 系列的长文本处理特性，并着重优化了在长窗口中的信息检索精度。这一改进旨在缓解“中间迷失”问题，即在处理超长文本时忽略关键信息的现象。
  3. 架构与效率： 采用混合专家（MoE）架构有助于在维持模型性能的同时控制推理成本，这对于长文本场景下的商业化部署具有实际意义。

局限性与边界：

  1. 幻觉风险： 虽然 RL 增强了输出的逻辑性，但在处理知识盲区或极度冷门领域时，模型仍存在生成错误信息的可能性。
  2. 延迟成本： 深度推理模式需要更多的计算时间，导致响应延迟增加。这在需要低延迟的实时交互场景中是一个明显的制约因素。

二、 多维深度评价

1. 内容严谨性与透明度

  • 分析： 报告在工程实现路径上描述清晰，界定了预训练与后训练的功能分工。但在核心参数（如 MoE 激活参数量）和 RL 奖励模型的具体构建细节上披露有限。
  • 结论： 该文档更倾向于工程导向的技术说明，而非纯粹的理论研究披露，这种处理符合当前商业技术公司的常规做法。

2. 实用价值

  • 评价： 在 RAG（检索增强生成）和长文档处理领域具有较高实用价值。
  • 分析： 其核心优势在于长窗口内的精准信息提取。对于法律、金融等需要处理大量文档的行业，该模型能够减少因文本切分导致的信息损耗，支持跨文档的对比分析。

3. 创新性

  • 评价： 属于工程集成层面的优化。
  • 分析： 长文本与 RL 均非原创技术，Kimi k2.5 的特点在于将这两者在中文语境下进行了系统整合与调优。其创新主要体现在数据处理与系统工程的精细化上，而非底层算法原理的突破。

4. 行业影响

  • 评价： 推动了行业对“长文本推理”能力的关注。
  • 分析： 该模型的发布表明，行业竞争点已从单纯的参数规模转向对长文本逻辑推理能力的深耕。这将促使上下游产业链关注显存带宽优化以及基于长文档的应用形态重构。

5. 争议与挑战

  • 观点： 关于 Scaling Law（缩放定律）的边际效应。
  • 分析： 业界对于仅依靠 RL 能否持续提升模型能力存在分歧。此外，深度推理模式下的“黑盒”特性，使得模型在金融、医疗等强监管领域的可解释性应用仍面临挑战。

三、 应用建议

1. 适用场景

  • 推荐： 法律合同审查、长篇小说创作辅助、复杂代码库分析、多轮路演资料整理。

2. 注意事项

  • 限制： 在对实时性要求极高的场景（如实时对话）中，应谨慎使用深度推理模式。
  • 验证： 在涉及严格事实核对的场景中，建议引入外部知识库进行交叉验证，避免完全依赖模型生成的长文本结论。

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

# 示例1：模拟MoE模型中的专家选择机制
# 在Kimi K2.5这类大模型中，MoE（混合专家）架构通过动态选择专家来提高效率
def expert_router(input_tokens, num_experts=8, top_k=2):
    """
    模拟MoE模型中的专家路由器
    :param input_tokens: 输入token序列（简化为特征向量）
    :param num_experts: 总专家数量
    :param top_k: 每个token选择的专家数量
    :return: 专家选择结果和负载分布
    """
    import numpy as np
    
    # 1. 计算token与各专家的匹配分数（实际模型中会通过门控网络计算）
    expert_scores = np.random.rand(len(input_tokens), num_experts)
    
    # 2. 选择top-k专家（模拟实际路由逻辑）
    top_experts = np.argsort(-expert_scores, axis=1)[:, :top_k]
    
    # 3. 计算专家负载（用于负载均衡）
    expert_load = np.zeros(num_experts)
    for experts in top_experts:
        expert_load[experts] += 1
    
    return {
        "expert_assignments": top_experts,
        "load_distribution": expert_load,
        "load_balance_score": np.std(expert_load) / np.mean(expert_load)  # 负载均衡指标
    }

# 使用示例
tokens = ["用户", "提问", "技术", "报告"]
result = expert_router(tokens)
print(f"专家分配结果：{result['expert_assignments']}")
print(f"负载均衡得分（越低越好）：{result['load_balance_score']:.3f}")

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

# 示例2：长上下文窗口的注意力优化计算
# Kimi K2.5支持超长上下文，这里展示分段注意力计算
def optimized_attention(input_sequence, window_size=1024, overlap=128):
    """
    模拟分段注意力机制（类似滑动窗口注意力）
    :param input_sequence: 输入序列（简化为数字列表）
    :param window_size: 每个注意力窗口大小
    :param overlap: 窗口之间的重叠大小
    :return: 注意力计算结果
    """
    import numpy as np
    
    # 1. 将长序列分割为重叠窗口
    windows = []
    for i in range(0, len(input_sequence), window_size - overlap):
        window = input_sequence[i:i + window_size]
        if len(window) > 0:
            windows.append(window)
    
    # 2. 对每个窗口计算注意力（简化为点积）
    attention_outputs = []
    for window in windows:
        # 实际模型中这里会计算Q、K、V和注意力权重
        attention_score = np.mean(window)  # 简化示例
        attention_outputs.append(attention_score)
    
    # 3. 合并结果（实际模型中会有更复杂的合并策略）
    return {
        "num_windows": len(windows),
        "attention_outputs": attention_outputs,
        "memory_saved": f"相比全注意力计算节省约 {100 - (len(windows) * window_size / len(input_sequence) * 100):.1f}% 内存"
    }

# 使用示例
long_sequence = list(range(10000))  # 模拟长上下文
result = optimized_attention(long_sequence)
print(f"窗口数量：{result['num_windows']}")
print(result['memory_saved'])

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291

# 示例3：模拟模型推理时的KV Cache优化
# KV Cache是大模型推理加速的关键技术
class KVCacheManager:
    def __init__(self, max_cache_size=4096):
        """
        初始化KV缓存管理器
        :param max_cache_size: 最大缓存token数量
        """
        self.cache = {}
        self.max_cache_size = max_cache_size
        self.current_size = 0
    
    def update_cache(self, token_id, key_value):
        """
        更新KV缓存（模拟实际模型中的KV存储）
        :param token_id: 当前token ID
        :param key_value: 该token的Key-Value向量（简化为数字）
        """
        if self.current_size >= self.max_cache_size:
            # 简单的FIFO缓存替换策略
            oldest_token = next(iter(self.cache))
            del self.cache[oldest_token]
            self.current_size -= 1
        
        self.cache[token_id] = key_value
        self.current_size += 1
    
    def get_cache_hit_rate(self, request_tokens):
        """
        计算缓存命中率（模拟推理加速效果）
        :param request_tokens: 请求的token序列
        :return: 缓存命中率
        """
        hits = sum(1 for token in request_tokens if token in self.cache)
        return hits / len(request_tokens) if request_tokens else 0

# 使用示例
cache_manager = KVCacheManager()
# 模拟填充缓存
for i in range(100):
    cache_manager.update_cache(i, f"kv_{i}")

#


---
## 案例研究


### 1：Moonshot AI 内部研发效能提升

 1：Moonshot AI 内部研发效能提升

**背景**: 随着大模型参数规模从千亿迈向万亿级别，训练数据量呈指数级增长。Moonshot AI（月之暗面）在 Kimi 模型的迭代过程中，面临着海量长文本数据处理与模型微调的巨大工程挑战。传统的数据处理流水线在处理超长上下文（如 200 万 token 上下文）时，往往会出现显存溢出或吞吐量严重下降的问题。

**问题**: 在 Kimi 2.5 的研发阶段，团队发现现有的训练框架在处理极端长序列数据时，显存优化不足，导致训练迭代周期过长，且在复杂逻辑推理任务的微调过程中，模型对长文本中间细节的“遗忘”现象较为严重，影响了最终产品的准确率。

**解决方案**: 根据 Kimi 2.5 技术报告中揭示的核心优化，团队研发并部署了新一代的高性能训练框架。该框架针对底层算子进行了深度优化，特别是改进了 FlashAttention 的实现机制，以支持更长的上下文窗口。同时，在 RLHF（人类反馈强化学习）阶段，引入了更复杂的长链推理数据构建管线，专门针对模型在长文本中的逻辑连贯性进行强化训练。

**效果**: 通过这些技术革新，Kimi 2.5 在长文本处理能力上实现了质的飞跃。内部测试显示，处理 200 万 token 长度的上下文时，推理延迟显著降低，且在“大海捞针”测试中，长距离信息的召回准确率提升至接近 100%。这使得 Kimi 智能助手在实际应用中能够精准分析超长财报、法律卷宗或小说，极大提升了用户在复杂场景下的工作效率。

---



### 2：企业级知识库智能问答系统部署

 2：企业级知识库智能问答系统部署

**背景**: 某大型跨国制造企业拥有数十年的积累，保存了海量的非结构化技术文档、维修手册和内部邮件。传统的搜索引擎只能基于关键词匹配，无法理解复杂的维修逻辑或跨文档的关联问题，导致技术人员在排查故障时效率低下。

**问题**: 该企业尝试引入通用的 LLM（大语言模型）进行知识库问答，但效果不佳。主要痛点在于：通用模型的上下文窗口太小，无法容纳整本维修手册；且模型容易产生“幻觉”，编造不存在的维修步骤，在工业场景下这是不可接受的安全风险。

**解决方案**: 基于 Kimi 2.5 技术报告中提到的长窗口与高精度检索能力，系统集成商为该企业定制了专属知识库方案。利用 Kimi 2.5 支持的超长上下文特性，系统可以直接将数千页的 PDF 手册作为上下文输入，无需复杂的切片预处理。同时，结合 Kimi 2.5 在 RLHF 阶段对“减少幻觉”的针对性优化，要求模型在回答时必须严格依据提供的文档内容，若文档中无答案则直接回答不知道。

**效果**: 部署后，现场技术人员通过自然语言提问（如“描述 2015 型号设备在液压系统故障时的异常声音特征及对应解决方案”），系统能够在几秒钟内跨多个文档段落提取精准答案，并标注出处。实测表明，故障排查的平均时间缩短了 40% 以上，且完全消除了模型编造错误指令的安全隐患，实现了 AI 技术在严苛工业环境下的可靠落地。

---
## 最佳实践

## 最佳实践指南

### 实践 1：采用长上下文混合专家架构优化推理效率

**说明**:
K2.5 采用了 MoE 架构，在处理长上下文（128k+ tokens）时，通过稀疏激活机制在保持高性能的同时降低了计算成本。该架构允许模型在处理海量信息时，仅激活相关的专家网络，从而在推理速度和响应质量之间取得最佳平衡。

**实施步骤**:
1. 评估现有模型在长文本处理上的延迟瓶颈。
2. 部署支持动态路由推理的底层基础设施（如 vLLM 或 TensorRT-LLM）。
3. 针对 128k 上下文窗口配置显存优化策略，确保 KV Cache 的高效利用。

**注意事项**:
在处理超长上下文时，需严格监控显存占用，避免因 KV Cache 溢出导致的 OOM（显存溢出）问题。

---

### 实践 2：利用强化学习提升复杂指令遵循能力

**说明**:
报告指出 K2.5 重点优化了 RL（强化学习）阶段，显著提升了模型对复杂、多层级指令的遵循能力。这意味着在需要严格格式输出或逻辑推理的任务中，该模型能提供更高的稳定性和准确率。

**实施步骤**:
1. 在 Prompt 工程阶段，明确界定输出格式和逻辑约束条件。
2. 利用 K2.5 的 API 接口进行测试，对比其与上一代模型在复杂任务拆解上的表现。
3. 建立自动化评估集，专门用于验证模型对“负面约束”的遵循情况。

**注意事项**:
虽然 RL 提升了指令遵循度，但在极度开放式的创造性任务中，仍需进行人工抽查，以防模型过度优化导致输出僵化。

---

### 实践 3：构建基于思维链的数据飞轮

**说明**:
K2.5 在数学和代码能力上的提升得益于高质量的 CoT（思维链）数据。最佳实践包括利用模型生成 CoT 数据，并通过人工或高精度模型进行筛选，以此反哺模型微调，形成能力提升的闭环。

**实施步骤**:
1. 收集领域内的复杂问题样本（如高难度数学题或代码库）。
2. 使用 K2.5 生成详细的推理过程，并提取纯思维链部分。
3. 对生成的思维链进行清洗和验证，构建高质量的 SFT（监督微调）数据集。

**注意事项**:
确保思维链数据的逻辑严密性，避免模型在微调过程中学习到错误的推理路径（即“幻觉式推理”）。

---

### 实践 4：部署多模态输入处理管线

**说明**:
K2.5 进一步增强了视觉理解能力，支持高分辨率的图像输入和多模态交互。在文档分析、图表理解等场景中，直接利用原生多模态能力比传统的 OCR + 文本分析流程更有效。

**实施步骤**:
1. 梳理业务中涉及图文混合的场景（如发票解析、科研图表分析）。
2. 将原有的“图片转文字”链路替换为直接调用多模态 API。
3. 调整 Prompt，引导模型同时关注文本内容和视觉结构信息。

**注意事项**:
高分辨率图片输入会显著增加 Token 消耗和推理延迟，建议在服务端对图片进行自适应压缩或裁剪，仅保留关键区域。

---

### 实践 5：实施系统化的安全对齐策略

**说明**:
报告强调了 K2.5 在安全性上的改进，特别是在减少有害内容生成和防御对抗性攻击方面。在部署面向公众的应用时，必须复用或参考其安全对齐机制，确保输出合规。

**实施步骤**:
1. 在 API 调用层配置内容过滤策略，覆盖输入和输出两端。
2. 针对特定领域（如金融、医疗），建立额外的安全微调层，强化领域内的合规性。
3. 定期进行红队测试，模拟攻击 Prompt 以检验模型的防御边界。

**注意事项**:
过度严格的安全过滤可能会触发“拒绝回答”的误判，建议建立反馈机制，根据实际业务需求调整过滤阈值。

---

### 实践 6：优化长文本检索增强生成（RAG）

**说明**:
得益于 128k 的上下文窗口，K2.5 非常适合处理长文档 RAG 任务。最佳实践是减少传统的切片策略，尽可能将完整的文档段落或相关章节直接喂给模型，以保留上下文的语义完整性。

**实施步骤**:
1. 重新设计知识库的切分逻辑，将 Chunk 大小调整为 4k-8k tokens 或更大。
2. 在检索阶段，优先召回语义高度相关的长文本块，而非零散的短句。
3. 在 Prompt 中明确指示模型基于“提供的长文本”进行回答，减少对外部知识的依赖。

**注意事项**:
虽然上下文窗口变大，但“迷失中间”现象仍可能存在。关键信息应尽可能放置在 Prompt 的开头或结尾部分，以提高被注意的概率。

---
## 学习要点

- 基于对 Kimi k1.5（通常被称为 Kimi 2.5）技术报告及相关 Hacker News 讨论的分析，以下是 5-7 个关键要点：
- Kimi k1.5 通过强化学习（特别是多模态 RL）实现了数学和代码能力的显著提升，在长上下文窗口（高达 128k）中仍能保持高性能。
- 该模型采用了“长上下文思维链”策略，允许模型在输出最终答案前生成更长的推理过程，从而显著增强了复杂任务的解决能力。
- 在数学基准测试（如 MATH）和代码生成任务中，Kimi k1.5 的表现与 OpenAI 的 o1 正式版相当，证明了其推理能力的竞争力。
- 技术报告强调了“测试时计算”的重要性，表明通过在推理阶段增加计算资源（如搜索和反思），可以有效提升模型的最终输出质量。
- 模型在长文本处理方面表现出色，支持高达 200 万 token 的上下文窗口，且在长上下文中仍能保持极高的检索准确率和指令遵循能力。
- Kimi k1.5 展示了强大的多模态理解能力，能够同时处理文本和视觉输入，并在视觉相关的推理任务中表现出色。

---
## 常见问题


### 1: Kimi k1.5 与此次发布的 Kimi k2.5 在模型架构和性能上有什么主要区别？

1: Kimi k1.5 与此次发布的 Kimi k2.5 在模型架构和性能上有什么主要区别？

**A**: 根据技术报告，Kimi k2.5 是对 Kimi k1.5 的全面升级版本。虽然两者都基于 MoE（混合专家）架构，但 k2.5 进行了深度的底层优化。在性能方面，k2.5 在数学、代码生成以及长文本处理能力上均有显著提升，特别是在复杂逻辑推理任务中，k2.5 展现出了更强的鲁棒性。此外，k2.5 进一步优化了推理上下文窗口的有效利用率和多模态输入的处理精度。

---



### 2: Kimi k2.5 在长上下文窗口方面的具体表现和技术亮点是什么？

2: Kimi k2.5 在长上下文窗口方面的具体表现和技术亮点是什么？

**A**: Kimi k2.5 延续并强化了长文本处理的优势。技术报告显示，该模型支持超长上下文窗口，并在此基础上的“大海捞针”测试中保持了极高的准确率。其技术亮点在于改进了注意力机制，使得模型在处理长达数百万 token 的输入时，仍能有效召回关键信息，而不会出现随着长度增加性能急剧下降的“迷失中间”现象。

---



### 3: 该模型在数学和代码能力方面是否达到了 SOTA（当前最佳）水平？

3: 该模型在数学和代码能力方面是否达到了 SOTA（当前最佳）水平？

**A**: 是的，Kimi k2.5 在多项基准测试中表现出了接近甚至达到 SOTA 的水平。报告指出，k2.5 在 MATH（数学基准）和 HumanEval（代码生成基准）等权威数据集上的得分超越了上一代以及许多同类开源模型。它不仅能够解决复杂的数学问题，还能生成高质量、可运行的代码，并且在代码调试和逻辑纠错方面表现优异。

---



### 4: Kimi k2.5 采用了什么样的训练策略来保证推理能力的提升？

4: Kimi k2.5 采用了什么样的训练策略来保证推理能力的提升？

**A**: 报告中提到，Kimi k2.5 采用了大规模的高质量合成数据进行预训练和微调。除了传统的有监督微调（SFT）外，团队重点强化了强化学习（RL）阶段的应用，特别是针对思维链推理进行了专门优化。这种训练策略使得模型在面对复杂问题时，能够更有效地展示推理步骤，从而提高答案的准确性和可解释性。

---



### 5: 关于模型的安全性和对齐，技术报告中提到了哪些措施？

5: 关于模型的安全性和对齐，技术报告中提到了哪些措施？

**A**: 安全性是 Kimi k2.5 的核心考量之一。技术团队在训练过程中实施了严格的安全过滤机制，包括对预训练数据的清洗以及在微调阶段引入对齐训练（如基于人类反馈的强化学习 RLHF）。这使得模型在遵循用户指令的同时，能够有效拒绝有害、偏见或不道德的请求，确保输出内容符合安全规范。

---



### 6: Kimi k2.5 是否支持多模态输入，其视觉理解能力如何？

6: Kimi k2.5 是否支持多模态输入，其视觉理解能力如何？

**A**: 是的，Kimi k2.5 是一个多模态大模型。除了文本处理外，它还具备强大的视觉理解能力。报告中的测试结果表明，k2.5 能够处理高分辨率的图像输入，并在文档理解、图表分析以及场景问答等视觉任务中表现出色。其视觉编码器与语言模型的深度融合，使其能够准确描述图像细节并进行基于视觉的逻辑推理。

---



### 7: 开发者或企业如何获取或使用 Kimi k2.5 的能力？

7: 开发者或企业如何获取或使用 Kimi k2.5 的能力？

**A**: 根据 Hacker News 的讨论及技术报告信息，Moonshot AI 通常会通过其官方平台开放 API 接口供开发者调用。虽然具体的权重开源策略需参照官方发布的最终许可协议，但用户通常可以通过集成 Kimi 的 API 来将 k2.5 的长文本、数学及代码能力集成到自己的应用程序中。具体的费率和调用限制需参考官方开发者文档。

---
## 思考题


### ## 挑战与思考题

### ### 挑战 1: [简单]

### 问题**:

### 在 Kimi k1.5 的技术报告中，模型采用了长上下文窗口来处理复杂的推理任务。请对比分析：在处理一个长达 100 万 token 的输入时，使用全量注意力机制与使用线性注意力机制或稀疏注意力机制在显存占用上的理论差异是多少？假设隐藏层维度为 4096。

### 提示**:

---
## 引用

- **原文链接**: [https://github.com/MoonshotAI/Kimi-K2.5/blob/master/tech_report.pdf](https://github.com/MoonshotAI/Kimi-K2.5/blob/master/tech_report.pdf)
- **HN 讨论**: [https://news.ycombinator.com/item?id=46826597](https://news.ycombinator.com/item?id=46826597)

> 注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

---


---
## 站内链接

- 分类： [大模型](/categories/%E5%A4%A7%E6%A8%A1%E5%9E%8B/) / [论文](/categories/%E8%AE%BA%E6%96%87/)
- 标签： [Kimi K2.5](/tags/kimi-k2.5/) / [技术报告](/tags/%E6%8A%80%E6%9C%AF%E6%8A%A5%E5%91%8A/) / [长上下文](/tags/%E9%95%BF%E4%B8%8A%E4%B8%8B%E6%96%87/) / [推理能力](/tags/%E6%8E%A8%E7%90%86%E8%83%BD%E5%8A%9B/) / [Moonshot AI](/tags/moonshot-ai/) / [LLM](/tags/llm/) / [模型升级](/tags/%E6%A8%A1%E5%9E%8B%E5%8D%87%E7%BA%A7/) / [AI 评估](/tags/ai-%E8%AF%84%E4%BC%B0/)
- 场景： [AI/ML项目](/scenarios/ai-ml%E9%A1%B9%E7%9B%AE/) / [大语言模型](/scenarios/%E5%A4%A7%E8%AF%AD%E8%A8%80%E6%A8%A1%E5%9E%8B/)

### 相关文章

- [SokoBench：评估大模型长程规划与推理能力](/posts/20260129-arxiv_ai-sokobench-evaluating-long-horizon-planning-and-rea-2/)
- [SokoBench：评估大模型长周期规划与推理能力](/posts/20260130-arxiv_ai-sokobench-evaluating-long-horizon-planning-and-rea-2/)
- [🔥POPE：用特权探索让AI学会解决复杂难题！](/posts/20260127-arxiv_ai-pope-learning-to-reason-on-hard-problems-via-privi-8/)
- [震惊！Gemini Flash击败Opus！🎮Tetris胜率66%🚀](/posts/20260127-hacker_news-show-hn-tetrisbench-gemini-flash-reaches-66-win-ra-6/)
- [Claude Code 每日基准测试：追踪模型性能退化](/posts/20260129-hacker_news-claude-code-daily-benchmarks-for-degradation-track-3/)
*本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。*