03 · 按能力分类

厂商会变，"哪一类模型解决哪一类问题"不会变。这一章是这一篇里唯一不容易过期的部分——搞清楚这几类，你才知道自己遇到的问题该找哪一类东西，而不是指望一个模型包打天下。

一张总表

类别	干什么	你什么时候需要它
文本模型（LLM）	读文字、写文字	默认的那一类，本书前面讲的全是它
推理模型	先想一段再答	复杂推理、多条件判断、数学、难的代码
多模态 · 理解	看图 / 看文档 / 看视频	截图、扫描件、表格图片、录屏
多模态 · 生成	出图 / 出视频	配图、海报、素材、短片
语音 · 识别（ASR）	声音 → 文字	会议录音、访谈、客服录音
语音 · 合成（TTS）	文字 → 声音	有声内容、播报、语音提示
语音 · 实时对话	直接听、直接说	语音助手、电话机器人
嵌入模型（Embedding）	文本 → 一串数字	做 RAG、做语义搜索
重排模型（Rerank）	把检索结果重新排序	RAG 效果不好时的第一个优化点
代码模型	专门写 / 补 / 改代码	编程场景

下面逐个说清楚"它到底在干嘛"和"用它时容易踩的坑"。

文本模型（LLM）

就是入门篇讲的那一类：预测下一个字。本书前面五篇讲的方法，默认都是对它说的。

选型上唯一值得注意的：同一家通常分三档——最强的、均衡的、最快最便宜的。别默认永远用最强那档：格式转换、分类、摘要这类活，便宜档就够，快还省钱。

推理模型

会先在内部"想"一段（生成一串思考过程）再给答案。

	普通文本模型	推理模型
速度	快	慢（要先想）
成本	低	高（思考过程也算 Token）
难题上	一般	明显更强
简单任务	够用	浪费

判断要不要用它，看一件事：这个任务需不需要"推"。

• 需要：多条件判断、算账、找矛盾、复杂代码、"这三个方案哪个更划算"。
• 不需要：整理格式、分类、摘要、翻译、改写。

用推理模型做格式转换，就像用跑车送外卖——能送到，但没必要。

另外：用推理模型时，别再手动写"请一步步思考"（提示词篇 04 章），它内建了。但规定具体的分析步骤仍然有效，那是在给分析框架，不是在教它思考。

多模态 · 理解

能"看"东西的模型。三种常见输入：

图片：截图、照片、手绘草图、图表。用途很实际——把一张界面截图丢进去让它描述结构、把一张手写便签转成文字、把一张图表读成数据。

文档：PDF、扫描件、带复杂排版的表格。这一类和"图片"的边界很模糊，但处理逻辑不一样：文档要保结构（哪些是表头、哪些是脚注），图片只要看懂内容。

视频 / 音频：更少见，但在会议录屏、操作演示、监控这类场景有用。

一个高频的坑：解析走样

入门篇 FAQ 提过这个——"上传文档"和"粘贴文字"，中间隔着一层解析。

PDF 扫描件、多栏排版、合并单元格的表格，解析出来经常缺行错列。而模型看到的是解析后的结果，你看到的是原文——你以为它读漏了，其实它压根没拿到。

结果不对时，先怀疑解析环节：把关键那几页手动粘贴成纯文本再试一次。

多模态 · 生成

出图、出视频。这一类和前面所有内容的差别很大，值得单说：

它跟"把话说清楚"这套方法的关系没那么直接。 图像生成更依赖具体的视觉描述（构图、光线、风格、镜头），而不是本书那套五要素。这是另一门手艺，本书不展开。

但有两条通用的仍然成立：

• 说清楚比说漂亮重要——"一个人在办公室"和"一个中年男性，侧身站在落地窗前，背对镜头，冷色调，办公室虚化"，差的是信息量。
• 给参考图比写形容词管用——这就是 Few-shot 的视觉版。

语音：三件不同的事

这三个经常被统称为"语音模型"，但解决的是完全不同的问题，别混：

语音识别（ASR）· 声音 → 文字

会议录音转文字、访谈整理、客服质检。

用的时候注意：转写稿是脏材料——没有标点、说话人混在一起、专有名词全错。所以标准做法是两步：

① ASR 转写           → 一坨脏文字
② 文本模型整理        → 结构化纪要

第 ② 步就是你在入门篇 08 章做过的那件事。很多人以为"AI 会议纪要"是一个模型干的，其实是两类模型串起来的一条 Workflow。

语音合成（TTS）· 文字 → 声音

有声内容、播报、语音提示、数字人配音。

近几年的进步主要在自然度和情感上——早期是"能听懂"，现在是"听不出是机器"。选型时听样本比看参数有用。

实时语音对话 · 直接听、直接说

不经过"转文字 → 处理 → 转语音"三段，而是端到端地听和说。差别在延迟和语气保留：

	三段式（ASR + LLM + TTS）	端到端实时
延迟	高，能感觉到卡顿	低，接近真人对话
语气 / 情绪	转文字时丢掉了	能保留
可控性	高（中间那段文字你能看、能改、能加规则）	低
排查问题	容易（有文字中间产物）	难

做语音应用时，别默认上端到端。

三段式虽然有延迟，但它有一样端到端没有的东西：中间那段文字是可见的中间产物——你能看它听成了什么、能在中间加校验、出问题能定位。

需要极低延迟的对话场景（电话、实时助手）才值得上端到端。

嵌入模型（Embedding）与重排（Rerank）

这两个不生成任何东西，是 RAG 的零件。

嵌入模型：把一段文本变成一串数字，意思相近的文本，数字也相近。RAG 靠它判断"哪几段资料跟这个问题有关"。

重排模型：嵌入模型粗筛出二十条，重排模型再精挑出最相关的三条。

RAG 效果不好时，先换这两个

很多人 RAG 做不好，第一反应是换更强的文本模型。通常没用——因为问题出在"检索没找对资料"，不在"读资料的那个模型不够聪明"。

检索不准，给再强的模型也是白搭。先看嵌入模型是不是适合中文、是不是适合你的领域，再考虑加一个重排。

选嵌入模型时，注意它是不是针对中文优化过——这个差别比模型大小明显。

代码模型

专门做代码补全、生成、修改的模型。

现在的界限比较模糊：通用文本模型的代码能力已经很强，专门的代码模型主要在补全速度和小尺寸下的效果上有优势（比如要在 IDE 里做实时补全，你需要一个又快又小的）。

日常写代码用通用模型就行，专门的代码模型主要给做工具的人用。

怎么组合

真实场景往往要好几类一起用。三个例子：

会议纪要：
  ASR 转写 → 文本模型整理 → 输出结构化纪要

企业问答：
  嵌入模型建索引 → 检索 → 重排 → 文本模型作答（这就是 RAG）

图文内容生产：
  文本模型写文案 → 图像模型出配图 → 文本模型审校

注意每一个都是一条 Workflow，不是"一个万能模型"。这也是为什么本书把 Workflow 排在 Agent 前面——多数所谓的"AI 能力"，实际是几类模型串起来的一条线。

下一步

04 · 怎么用这张地图