工程实践 on Renxin's Blog

RAG 分块策略：为什么你的知识库答非所问，问题多半出在这里

Thu, 13 Aug 2026 00:00:00 +0000

你搭了一个知识库问答系统：上传文档、建好索引、跑通 demo——然后 LLM 开始答非所问。

你以为是模型不够聪明。换更强的模型，还是不对。

问题很可能出在一个不起眼的环节：文档入库时的分块。LLM 根本没读到该读的内容，模型再强也白搭。

这篇文章把分块这件事讲透：为什么要分块、五种分块策略分别解决什么问题、生产环境到底怎么选。

为什么要分块？三个绕不过去的原因

先把结论摆出来：解析完的文档，不能整篇扔进检索。

原因有三个，每一个都独立成立。

原因一：上下文窗口是有限的

LLM 的上下文窗口再大也有上限。就算现在有 128K、1M 上下文的模型，检索也不是把整个文档库塞进 Prompt——那样成本直接爆炸。

更重要的是，窗口越大，模型越难从中找到准确的那一段。这就是著名的"大海捞针"问题：上下文拉长，检索精度反而下降。

原因二：检索信噪比

用户问的是文档里的一个小问题，但整篇文档有几千字。

整篇匹配会发生什么？不相关的内容把相关内容的信号稀释了。向量检索返回的 Top-K 结果里，噪音占了大多数，相关的那一小段被埋没。

块太大 → 无关信息稀释信号。这是信噪比的第一面。

原因三：Embedding 对长文本的"平均化"

Embedding 模型擅长表示短文本——一两句话的语义最清晰。

文本一长，向量就被"平均"了：整段的语义混在一起，变成一个模糊的方向。检索时，这个模糊向量既匹配不上问题，也匹配不上文档里的任何精确信息。

Embedding 模型对短文本的语义表示最好，长文本会被"平均"成模糊向量。

三个原因叠加，结论只有一个：必须把文档切成合适大小的块。

graph LR
 A["① 上下文窗口有限"] --> D["必须分块"]
 B["② 检索信噪比"] --> D
 C["③ Embedding 平均化"] --> D
 style A fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style B fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style C fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style D fill:#d1fae5,stroke:#059669,color:#064e3b

但怎么切，才是真正的问题。切小了语境不够，切大了检索不精——这就是分块的核心矛盾：检索精度 vs 上下文完整性。

分块的两个基础参数

在讨论策略之前，先理解所有分块策略都绕不开的两个参数。

参数	含义	经验值（中文场景）
chunk_size	每块的大小	300-800 字（约 500-1200 tokens）
chunk_overlap	相邻块之间的重叠量	chunk_size 的 10%-20%

为什么需要 overlap？看一个例子。

graph LR
 A["文档
AAAABBBBCCCCDDDD"] --> B["chunk_size=8, overlap=2
块1: AAAABBBB
块2: BBCCCCDD
BB 被两块共享"]
 A --> C["chunk_size=8, overlap=0
块1: AAAABBBB
块2: CCCCDD
BB-CC 之间语义断裂"]
 B --> D["✅ 跨块内容仍可检索"]
 C --> E["❌ 关键句恰好被切断时丢失"]
 style A fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style B fill:#d1fae5,stroke:#059669,color:#064e3b
 style C fill:#fef9c3,stroke:#ca8a04,color:#713f12
 style D fill:#d1fae5,stroke:#059669,color:#064e3b
 style E fill:#fee2e2,stroke:#dc2626,color:#7f1d1d

overlap=0 时，如果"BBCC"恰好是完整语义（比如一个概念的完整描述），它被拦腰切断，两块都不完整。检索时哪块都匹配不精准，LLM 拿到的都是残句。

overlap 就是给跨块语义留的缓冲带。

五种分块策略，逐个拆解

理解了参数，进入正题。分块策略从简单到复杂，正好是一条问题驱动的问题链。

策略一：固定大小分块——最简单，也最粗暴

做法：按预设的字符数或 token 数直接切。

# LangChain
text_splitter = CharacterTextSplitter(
 chunk_size=500,
 chunk_overlap=50,
)

优点只有一个：实现最简单、速度最快。

缺点却很致命：完全无视语义边界。可能在句子中间、甚至词语中间切断。

切出来的块，很多是"半个意思"。检索时匹配到半句话，LLM 看着上下文猜——这正是答非所问的来源。

适合日志、代码等结构弱、语义依赖不强的文本。自然语言文档用它，基本等于摆烂。

策略二：递归分块——默认策略，性价比之王

做法：按优先级尝试分隔符，从大到小逐级切。

# LangChain
text_splitter = RecursiveCharacterTextSplitter(
 chunk_size=500,
 chunk_overlap=50,
 separators=["\n\n", "\n", "。", "，", " ", ""]
)

graph LR
 A["超长段落"] --> B{"按优先级逐级切分
段落 → 换行 → 句子 → 词"}
 B -->|"每块 ≤ 上限"| C["✅ 在语义边界成块"]
 B -->|"仍超限"| D["降级到更细的分隔符"]
 D --> B
 style A fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style B fill:#fef9c3,stroke:#ca8a04,color:#713f12
 style C fill:#d1fae5,stroke:#059669,color:#064e3b
 style D fill:#fef9c3,stroke:#ca8a04,color:#713f12

思路：优先在语义最完整的边界（段落、换行、句号）切断，实在超限才降级到更细的分隔符。

优点：在保持语义边界和控制块大小之间取得最佳平衡，通用场景的默认选择。

缺点：分隔符优先级需要按文档类型微调；对复杂结构文档（表格、代码）力不从心。

策略三：语义分块——让 Embedding 参与决策

递归分块是按"形式"切（分隔符）。语义分块按"意思"切。

做法：

把文本拆成句子
计算每个句子的 Embedding 向量
计算相邻句子的语义相似度
在相似度"断崖"处切分

graph LR
 A["句子1: 聚类算法把样本分组"] --> B["句子2: K-Means 是经典算法"]
 B --> C["句子3: 明天北京多云转晴"]
 C --> D["语义断崖
句子2→3 相似度骤降
在这里切"]
 A -.->|"高相似"| B
 B -.->|"低相似"| C
 style A fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style B fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style C fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
 style D fill:#fef9c3,stroke:#ca8a04,color:#713f12

核心算法是新颖度检测：

novelty(s_i) = 1 - cosine_sim(embed(s_i), embed(context_window))
当 novelty > 均值 + 0.8 * 标准差 → 切分

优点：语义连贯性最好，检索精度最高。这也是为什么生产环境在"疑难块"上会启用它。

缺点：每个句子都要算一次 Embedding，计算成本翻倍。全量用不划算，适合作为精修手段。

工具：semchunk、LlamaIndex SemanticSplitterNodeParser。官方 benchmark 里，semchunk 的 AI 分块模式在 Legal RAG QA 上正确率 37.7%，比 LangChain 递归分块的 34.8% 高约 2.9 个百分点。

策略四：结构感知分块——利用文档自身的结构

如果文档本身有结构，为什么不直接用？

做法：按文档的固有边界切——Markdown 按标题层级、HTML 按标签、代码按函数类定义、对话按轮次。

关键技巧是注入结构元数据：每个 chunk 附带它在文档中的位置路径。

{
 "content": "聚类算法的核心思想是...",
 "metadata": {
 "header_path": "第三章 > 3.2 无监督学习 > 3.2.1 K-Means",
 "section_level": 3
 }
}

好处很实在：

逻辑清晰，切块天然语义完整
检索结果自带上下文——LLM 不光看到这段内容，还知道它来自哪一章哪一节

graph LR
 A["第三章 无监督学习"] --> B["3.2 无监督学习"]
 B --> C["3.2.1 K-Means
chunk 携带 header_path"]
 C --> D["检索命中 3.2.1 时
LLM 知道完整上下文位置"]
 style A fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style B fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style C fill:#d1fae5,stroke:#059669,color:#064e3b
 style D fill:#d1fae5,stroke:#059669,color:#064e3b

缺点：依赖文档格式规范。纯文本、扫描件这类无结构文档，它无从下手。

策略五：父子分块——生产环境的首选

前面的策略都在解决一个问题：块大还是块小。父子分块跳出这个取舍——大小都要。

做法：

父块：段落/小节级别（500-1000 tokens），提供完整上下文
子块：句子级别（100-200 tokens），负责精确检索

检索流程：用小的找，用大的答。

graph LR
 A["用户提问"] --> B["在子块中检索
句子级别，高精度"]
 B --> C["命中子块：
K-Means 是经典算法"]
 C --> D["通过 parent_id 找到父块"]
 D --> E["返回父块完整内容
上下文完整，LLM 能理解"]
 style A fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style B fill:#d1fae5,stroke:#059669,color:#064e3b
 style C fill:#d1fae5,stroke:#059669,color:#064e3b
 style D fill:#fef9c3,stroke:#ca8a04,color:#713f12
 style E fill:#d1fae5,stroke:#059669,color:#064e3b

graph LR
 subgraph P["父块：3.2.1 完整小节"]
 C1["子块1: 算法定义"]
 C2["子块2: 参数说明"]
 C3["子块3: 适用场景"]
 end
 Q["问题命中子块2"] --> C2
 C2 --> P
 P --> LLM["LLM 收到父块全文"]
 style P fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style C1 fill:#d1fae5,stroke:#059669,color:#064e3b
 style C2 fill:#fef9c3,stroke:#ca8a04,color:#713f12
 style C3 fill:#d1fae5,stroke:#059669,color:#064e3b
 style Q fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style LLM fill:#d1fae5,stroke:#059669,color:#064e3b

优点：检索精度与上下文完整性兼得——化解了分块最核心的矛盾。小粒度保证命中精准，大粒度保证 LLM 拿到完整语境，避免"找到了关键句但缺前因后果"。

缺点：存储开销翻倍（父子块都要存向量）、实现复杂度较高。

工具：LlamaIndex 的 auto-merging retriever / recursive retriever 就是这种思路的官方实现。

生产环境怎么选

五种策略各有适用场景，先看总对比。

策略	原理	优点	缺点	适用场景
固定大小	按字符/token 数硬切	最简单、最快	无视语义，可能在句中切断	日志、代码等弱语义文本
递归分块	按分隔符优先级切	语义边界与块大小平衡，通用	需调分隔符；复杂结构无力	通用默认
语义分块	用 Embedding 找语义断崖	语义最连贯、精度最高	计算成本翻倍	高质量问答、疑难块精修
结构感知	按文档标题/标签/轮次切	语义完整、自带上下文	依赖文档格式规范	Markdown/HTML/代码文档
父子分块	子块检索、父块作答	精度与上下文兼得	存储翻倍、实现复杂	生产环境首选

单看这张表，你可能会问：到底用哪个？

答案是：生产环境用混合分块。单一策略覆盖不了所有文档类型——你的知识库里既有 Markdown 规范文档，也有扫描 PDF，还有代码片段。

graph LR
 B["① 结构感知粗切
按标题/章节"] --> C{"块大小判断"}
 C -->|"过小"| D["合并相邻块"]
 C -->|"合适"| E["直接使用"]
 C -->|"过大"| F["递归/语义细分"]
 D --> G["② 父子分块映射
+ 元数据注入"]
 E --> G
 F --> G
 style B fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style C fill:#fef9c3,stroke:#ca8a04,color:#713f12
 style D fill:#d1fae5,stroke:#059669,color:#064e3b
 style E fill:#d1fae5,stroke:#059669,color:#064e3b
 style F fill:#d1fae5,stroke:#059669,color:#064e3b
 style G fill:#dbeafe,stroke:#2563eb,color:#1e3a5f

混合分块的思路：结构感知先粗切出框架，块大小判断决定后续处理（过小合并、合适直接用、过大递归/语义细分），最后用父子分块建立层级，注入元数据。

落地建议

回到开头的场景——知识库答非所问，怎么排查？

按这个顺序自查，90% 的问题能定位：

先看分块：打开一个 chunk 看看，句子是不是被拦腰切断？上下文是不是残缺？
默认从递归分块起步：chunk_size 500-800、overlap 10%-20%，把基线跑通
结构化文档换结构感知：你的文档有标题层级，就别浪费这个信息
检索精度不够再上父子分块：让子块找、父块答，通常能显著提升
疑难块用语义分块精修：只对检索差的高频问题块启用，控制成本

分块不是一个"选一次就完事"的环节。文档类型变了、检索效果变了，分块策略就要跟着调。这是 RAG 系统里最值得花时间的调优点之一——因为它是整个检索质量的起点，也是你最能控制的一环。

本文基于个人对 RAG 工程实践的梳理与官方文档验证（MinerU OmniDocBench v1.6 得分 95.39 来自其官方 README；semchunk 基准数据来自其官方 README 及 isaacus.com 博客）。

你其实不需要更强的模型

Fri, 17 Jul 2026 00:00:00 +0000

你有没有这样一种感觉——

2023 年用上 GPT-4 的时候，那种震撼是真实的：它居然能写代码、能推理、能理解上下文。每发布一个新版本，你会迫不及待去试。但现在呢？GPT-5.6 发布了、Claude Fable 5 来了、Kimi K3 也出来了——你的第一反应是不是变成了：「哦，又强了一点。」

不是它们不够强。GPT-5.6 Sol 在复杂推理上确实甩开了上一代一大截。问题在于：你 90% 的日常任务，两三年前的模型就已经够用了。

这不是观点，是正在发生的现实。这篇不聊模型有多强，聊一个更实际的问题——为什么大部分 AI 项目依然在失败，以及真正该花精力在什么地方。

2026 年的模型版图

先看看我们现在有什么。

把今天的主流模型放在一张图里，按能力和价格两个维度看：

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 经济层["💰 经济层
$0.10-0.50/1M 输入"] -->|"80% 日常任务"| 日常["分类/提取/摘要
客服/简单推理"]
 主力层["🔋 主力层
$2-3/1M 输入"] -->|"15% 复杂任务"| 复杂["多步推理
长文档分析"]
 旗舰层["🚀 旗舰层
$5-10/1M 输入"] -->|"5% 特殊场景"| 特殊["高难度代码
研究级分析"]
 style 经济层 fill:#d1fae5,stroke:#059669,color:#064e3b
 style 主力层 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 旗舰层 fill:#fef3c7,stroke:#d97706,color:#78350f
 style 日常 fill:#d1fae5,stroke:#059669,color:#064e3b
 style 复杂 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 特殊 fill:#fef3c7,stroke:#d97706,color:#78350f

数据来源：OpenRouter API（2026-07 实时定价），涵盖 344 个模型。OpenAI GPT-5.6 于 2026 年 7 月 9 日发布，Claude Fable 5 于 6 月 9 日发布。DeepSeek V4 Pro 于 4 月开源，1.6T 参数/49B 活跃参数，1M 上下文。Kimi K3 据称可媲美 OpenAI 和 Anthropic 的旗舰模型。

这张图的信息量比看起来大。注意定价跨度——旗舰层和主力层之间是 5-10 倍的价格差，和 DeepSeek V4 Flash 比更是 100 倍的差距。更深层的信号是：经济层的模型能力线已经远远到了日常任务「够用」的基准线之上。 日常任务不需要旗舰模型的原因不是「没钱」，是「没必要」。

80/15/5 的分层现实

那实际在用的时候是怎么选的？

以我托管的 hermes-home 多 Agent 系统为例——它跑着 7 个 Agent，每天处理调研、写作、决策分析、知识管理等任务。实际用量比例：

层级	模型	用量	场景
经济层	DeepSeek V4 Pro（$0.44）	~80%	日常推理、内容生成、知识检索、决策辅助
主力层	GPT-5.6 Luna（$1.00）	~15%	需要更强推理能力的复杂任务
旗舰层	GPT-5.6 Sol / Claude Fable 5	~5%	高难度代码生成、架构设计、研究级分析

这不是预算问题。换成 DeepSeek V4 Pro 每百万 token 只需 $0.44，全跑旗舰模型（Claude Fable 5 $10/1M）也就多花二十几倍。真正的原因是：对于 80% 的任务，换旗舰模型的提升用户感知不到。

写一篇博客、整理一份调研、做一个决策分析——这些任务 DeepSeek V4 Pro 完成得很好。只有当你需要处理极其复杂的推理链条、或者生成需要深度理解上下文的高难度代码时，旗舰模型的优势才会显现。而且即便是这些时候，差距也在快速缩小：DeepSeek V4 Pro 的 Benchmark 已经追平了两年前的旗舰模型。

现在，旗舰模型针对的是「不可能轻松做到的业务」，是「需要博士级的研究分析」，是「5% 的场景」。大部分公司的绝大部分业务和大部分个人的日常任务，处在那个 80% 的范围内。

AI 项目真正的死因

如果模型已经够用了，那为什么那么多 AI 项目还是失败了？

RAND 公司对 65 个企业 AI 项目的元分析给出了一个发人深省的数字：80% 的企业 AI 项目以失败告终。 Gartner 的追踪数据给出了类似的结论，MIT 的研究甚至将这个比例推高到了 95%。这些项目不是用 DeepSeek V4 Pro 做的——很多花了大价钱上了最好的模型。

导致项目失败的原因，排在最前面的从来不是「模型不够聪明」。

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 模型["📈 模型能力
飞速提升"] -->|"但……"| 失败["⚠️ 80-95% 项目失败"]
 失败 --> 根因["为什么失败？"]
 根因 --> 需求["❌ 需求没挖对
解决了错误的问题"]
 根因 --> 成本["❌ 成本跑飞了
不分层 > 预算超支"]
 根因 --> 工程["❌ 工程不靠谱
缺乏可观测性和错误处理"]
 style 模型 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 失败 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style 根因 fill:#fef3c7,stroke:#d97706,color:#78350f
 style 需求 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style 成本 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style 工程 fill:#fecaca,stroke:#dc2626,color:#7f1d1d

数据来源：RAND 企业 AI 元分析（65 个项目，80% 失败率）、MIT 研究（95% 企业 AI 项目未交付价值）。

我跑了几个月多 Agent 系统，最深的感受就是：模型从来不是瓶颈。 出错最多的地方，永远是需求没对齐、成本估算偏差、以及系统工程的细节。

真正卡脖子的三件事

如果瓶颈不是模型，那是什么？基于实战观察，我认为有三件事比模型选型重要得多。

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 旧认知["过去以为瓶颈
是模型能力"] --> 新认知["实际瓶颈
（三件事）"]
 新认知 --> 需求挖掘["🔍 需求挖掘
解决对的问题"]
 新认知 --> 成本控制["💰 成本控制
分层选型不跑偏"]
 新认知 --> Agent工程["⚙️ Agent 工程
可靠系统需要 Engineering"]
 style 旧认知 fill:#fecaca,stroke:#dc2626,color:#7f1d1d
 style 新认知 fill:#fef3c7,stroke:#d97706,color:#78350f
 style 需求挖掘 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 成本控制 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style Agent工程 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f

需求挖掘：你确定你在解决对的问题？

大部分 AI 项目死得冤枉。团队花了几周时间搭建一个完美的 RAG 流水线，上线后发现用户根本不需要这个功能。或者花了大价钱微调了一个模型，结果业务需求已经变了。

这不是技术问题，这是需求挖掘问题。一个简单的判断标准：你能否一句话说清楚「这个 AI 系统做成了，用户的什么行为会改变？」 如果你说不清楚，模型再强也没用。

真实教训：hermes-home 里有一个 Agent 最早的设计是「帮我决定今天做什么」，上线后完全没人用。后来改成「帮我记录和管理待办事项」，用户每天在用。模型没换，Prompt 也没大幅改——换的是解决哪个问题。

成本控制：不分层的架构跑不远

很多团队的做法是：选一个最强的模型，全量流量都走它。结果第一个月账单出来，团队傻眼了。

分层的逻辑很简单：不是所有请求都值得用最好的模型处理。 80% 的请求可以用 DeepSeek V4 Pro 甚至 V4 Flash，15% 需要 GPT-5.6 Luna 级别，只有 5% 需要动用旗舰模型。

实操层面，成本优化的手段远不止分层：

语义缓存：重复查询命中缓存，彻底省掉模型调用
Prompt 压缩：精简历史记录和上下文，减少 token 消耗
Fallback 链：小模型先处理，处理不了再升级到大模型
输出长度控制：很多场景不需要完整输出，设置 max_tokens 能省一大半

2026 年的行业共识是：一个设计良好的分层架构，可以将 LLM 成本降低 30-50%，同时保持 95% 以上的用户体验不下降。

Agent 工程：能力是 Engineering 出来的，不是模型送过来的

这是最容易被忽视、但也是真正的壁垒所在。

从 GPT-3.5 到 GPT-5.6，模型能力在涨。但把一个 LLM 从「能回答问题」变成「能可靠地完成一个任务」，需要的是一整套工程能力——

Tool 设计：模型需要知道自己有什么工具可用，每个工具的输入输出是什么，什么时候该用哪个
Memory 管理：会话历史、长期记忆、知识库检索——怎么存、怎么查、怎么不爆上下文
错误处理：模型调用超时怎么办？工具返回异常怎么办？重试逻辑怎么写？
可观测性：每次调用花了多少 token？哪个环节耗时最长？出错了怎么定位？
多 Agent 协作：多个 Agent 之间怎么发现彼此的能力、怎么传递任务、怎么避免冲突

这些东西，换再强的模型也不会自动变好。它们需要工程投入。

实战案例：一个跑在 DeepSeek 上的多 Agent 系统

hermes-home 是一个真实运行的多 Agent 系统，7 个 Agent 分布在云服务器和本地 Docker 中，通过 MCP 协议通信。这个系统 80% 的请求由 DeepSeek V4 Pro 处理。

它能做什么？

知识库 Agent 每天自动扫描 GitHub 新项目，整理入库
博客 Agent 从知识库拉取素材，写成 Hugo 文章并部署
待办 Agent 管理日常任务并定时提醒
决策 Agent 综合分析多个来源，给出结构化建议

所有这些任务，没有一个需要用到 Claude Fable 5 的全能力量。系统的瓶颈从来不在模型能力上——而是在 Tool 设计得够不够好、Memory 管理得够不够稳定、错误处理得够不够健壮。

%%{init: {'theme':'neutral', 'fontFamily':'monospace'}}%%
flowchart LR
 subgraph 模型层["模型层 (80% DeepSeek V4 Pro)"]
 A["LLM 推理"]
 end
 subgraph 工程层["工程层 (真正的壁垒)"]
 B["Tool 系统"]
 C["Memory 管理"]
 D["错误处理"]
 E["可观测性"]
 end
 subgraph 应用层["应用层"]
 F["7 个 Agent
调研/写作/决策/待办"]
 end
 A --> B --> C --> D --> E --> F
 style 模型层 fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style 工程层 fill:#d1fae5,stroke:#059669,color:#064e3b
 style 应用层 fill:#fef3c7,stroke:#d97706,color:#78350f

我花了大量时间优化的是中间这一层——Tool 的接口设计、Memory 的持久化策略、错误恢复逻辑、以及每次调用链路的可观测性。这些才是真正决定系统质量的因素。模型只要「够用」就行。

下次有新模型发布的时候，先问自己三个问题：

我的瓶颈真的是模型能力吗？ ——还是需求没挖对、成本没控好、工程没做扎实？
换模型能解决我的什么问题？ ——它会让用户感知到显著提升吗？
我的系统有足够好的可观测性吗？ ——如果你不知道每次调用花在哪、错在哪，换模型就是盲人摸象。

模型在飞速进步，这是好事。但 90% 的日常任务已经越过了「够用」的基准线。 真正的差距，从来不在模型本身。

数据来源：OpenRouter API 实时定价、DeepSeek 官方发布公告（2026-04-24）、OpenAI GPT-5.6 官方公告（2026-07-09）、Anthropic Claude Fable 5 公告（2026-06-09）、RAND 企业 AI 项目元分析、AP News Kimi K3 报道。