「交给它」那一头 —— 挑模型、写话术、按长度计价、别信排行榜
这一章讲三件事: 那段交给模型的话该怎么写、该挑哪一档模型、以及这一头的账怎么算。
它在全书链条上的位置很特别:它是唯一一章讲「生成那一头」的。 而读完你会发现,这一头能拧的旋钮少得出奇—— 这正是为什么剩下十六章全在讲另一头(先去搜)。
1. 这一章讲什么
三句话:
- 第 02 章那条走查的第 6、7 步,拆开来只有三个可调的东西: 挑哪一档模型、那段话怎么写、按什么计价;
- 三个都有具体的数和具体的反面判据——这一章是全书数字最密的一章之一;
- 最后一节讲的不是技术,是方法论:为什么榜单第一名不能直接选。
2. 顶层全景:这一头的三个旋钮
第 02 章走查的第 6 步:把材料和问题拼成一段话
│
├─ 旋钮一:这段话怎么写 → 四件套(第 4 节)
│ 太松会掺训练数据,太紧会拒答(第 5 节)
│
├─ 旋钮二:交给哪一档模型 → 四档,价钱差 100 倍(第 6 节)
│ 挑法是"仍然够用的最小那个",不是"最好那个"
│
└─ 旋钮三:钱怎么算 → 按长度,而且吐出来的比读进去的贵(第 3 节)
图说:就这三个。拧完就没有了——所以后面十六章讲的都是另一头。
3. 承重词一:token —— 长度不按字数算,按它算
这一节要讲透本章第一个承重词。一句话先给结论:token 就是模型眼里的一个最小单位, 一段文字进它嘴里之前会先被切成一串 token;计价和长度上限,数的都是 token 的个数。
先看现象:为什么不能按字数算
你可能见过这种事:同样是「一千字」,英文的那份和中文的那份,报出来的费用不一样; 一段代码和一段散文,长度也算不到一块去。
因为它数的不是字。
它数的是什么
模型不是一个字一个字地读文字的。它读之前,先把文字切成一串小块: 常见的词整个是一块,生僻的词会被拆成几块,标点、空格、换行也各占一块。 每一块就叫一个 token。中文材料里管它叫「标记」,也叫「词元」——说的都是同一件事。
"unbelievable" → ["un", "believ", "able"] 3 个 token
"the" → ["the"] 1 个
"reset password" → ["reset", " password"] 2 个
"解约通知期" → ["解", "约", "通", "知", "期"] 5 个(中文常常一字一块,所以更"费")
图说:这个切法是为演示编的,各家切得不完全一样。
要看清的是形状——同样看着「一样长」的两段文字,token 数可以差好几倍。
两件事都按 token 数算:
| 什么 | 怎么算 |
|---|---|
| 钱 | 输入多少个 token、输出多少个 token,分开计价 |
| 第 01 章那个上下文窗口 | 上限也是按 token 数定的,不是按字数 |
反直觉的一条:吐出来的比读进去的贵得多
书给了机制上的解释,这一句值得原样记住1:
输出 token 通常贵得多,因为模型必须一个一个地生成,每生成一个都要考虑前面所有的; 而输入 token 是在一次前向计算里并行处理的。
你发过去 3 000 个 token 的材料
→ 这 3 000 个是"一次性一起过一遍",算一次
它回你 400 个 token 的答案
→ 这 400 个是"过 400 遍",每一遍都要把前面的全部再看一次
图说:所以贵的不是你塞了多少材料,而是你让它写了多长的答案。
这条对第 02 章那条走查有一个直接的后果: 把取回的块数从 3 调到 10,输入变长了三倍多,但那部分是便宜的; 而让它「详细展开、分点说明」,涨的是贵的那一半。
4. 那段话怎么写:四件套
书给 RAG 的那段话定了一个固定结构,四件2:
| 件 | 它管什么 | 书那个例子里的原话(译) |
|---|---|---|
| 角色 | 定下它该以什么身份、什么口吻说话 | 「你是一个采购分析师,用简单可靠的方式解释内部政策」 |
| 指令 | 说清这次要它干什么 | 「读下面检索到的材料,只用材料里的信息回答用户的问题;材料里没覆盖的,就说这份材料里没有」 |
| 检索到的材料 | 第 02 章走查第 5 步取回来的那几块,原样贴进来 | <<context>> —— 运行时才填 |
| 输出要求 | 规定答案长什么样 | 「简短。措辞清楚。不超过 120 个词。」 |
第二件里那半句是全书最该抄走的一句话。 书自己说明了它买到了什么3:
因为模型被明确要求只用检索到的材料,所以每一个答案都能被追回到真实的来源。
这就是第 01 章第 6 节那条捆绳的完整写法。 注意它是两句,不是一句: 「只用材料回答」+「没覆盖就说没有」。第二句省不得—— 没有它,模型碰到材料里没写的问题时,会退回去用它训练时读过的东西答。
5. 承重词二:提示模板 —— 两头都会坏
本章第二个承重词。一句话先给结论:提示模板就是把上面那四件套写成一个固定的模子, 每次只往中间那一格里换材料和问题。
为什么要有模子
因为四件套里有三件每次都一样(角色、指令、输出要求),只有材料和问题在变。 做成模子,就能保证每次问答的规矩是同一套——否则同一个系统会时松时紧,你连排障都没有基准。
两头都会坏 —— 这是这一节的重心
书把这个取舍写得很干脆4:
太松 太紧
├─ 模型会掺进训练数据里的东西 ├─ 碰到"一部分在材料里、一部分不在"的
├─ 模型会编造引用 │ 边缘问题,它会干脆拒答
└─ 你分不清哪句有依据、哪句没有 └─ 而边缘问题恰恰是真实用户最常问的
图说:两头都会坏,而且坏法完全不同——一头是"它说了不该说的",
另一头是"它没说该说的"。书给的办法只有一个:拿真实的查询去试,照失败的样子调。
还有一笔容易漏的账
模板本身要占 token,而且每一次检索调用都要付一遍。5
配上第 3 节那个走查就有了参照物: 一段 200 个 token 的模板, 一天被调用一万次,就是 200 万个 token 的输入费——而它每一次的内容都一模一样。 所以书的建议很直白:模板写简洁点。
6. 挑哪一档模型:挑「仍然够用的最小那个」
四个档位
书把市面上的模型按能力分成四档,并给了每档的输入价6。 下面这张表里的具体型号一定会过时,但四个档位这个划分不会——记档位,别记名字。
表里会出现三个还没讲过的说法,先各交代一句。吞吐:单位时间里能处理多少条请求。
边缘设备:手机、摄像头、车机这类在数据产生的地方就近处理的机器,而不是把数据传回机房再算。
工作流:一串前后相接的步骤,上一步的产出喂给下一步。
| 档 | 用在哪 | 输入价(每一百万个 token) |
|---|---|---|
| 超高效 | 简单任务、要求高吞吐的实时响应、分类、跑在边缘设备上 | 约 0.05–0.20 美元 |
| 高效 / 日常 | 一般生产力、生成与摘要、聊天与客服 | 约 0.25–0.60 美元 |
| 旗舰 | 复杂或创造性任务、深度分析、高级代码生成、对客自动化 | 约 1–5 美元 |
| 推理 / 前沿 | 多步推理、科学与数学、长材料上的规划、自主的 agent 工作流 | 约 2–30 美元 |
最上档和最下档差 100 倍到 600 倍。 这是全书最大的一个价格跨度, 而它换来的能力差距在多数 RAG 场景里远没有 100 倍。
挑法:从延迟倒推,不是从榜单倒推
书给的口径只有一句7:
「挑仍然满足要求的最小模型」——而且是逐个流水线步骤地挑。
「逐个流水线步骤」这半句容易读漏。它的意思是:第 02 章那条走查上有好几处会调用模型 (入库时抽文字、写摘要、补标注;在线时写答案),这几处不必用同一档。
具体怎么倒推,书给了一个可用的数8:
实时聊天:用户很少愿意等超过 10 秒,除非答案价值特别高
→ 从这 10 秒往回扣:检索要花掉一点,生成必须在剩下的时间里写完
→ 而"标准聊天场景"(书说的是取回三到四块材料)
超高效档或高效档往往就够
大模型带来的那点增量,不足以抵掉多出来的等待
批处理(比如夜里跑一遍全部合同):能容忍分钟到小时
→ 这时精度的提升可能值回更贵的模型
→ 书举的例子:审复杂合同,抽得准一点就能免掉一次昂贵的错误
图说:同一套系统里,在线那一步和离线那一步该选不同的档。
反面判据也很硬: 简单的分类和抽取任务,别用最贵的那档—— 高效档能可靠完成的事,没必要付 100 倍的钱9。
判断(我们的,不是书里的):这一节最该带走的不是那张价目表,是「逐个步骤地挑」这半句。 因为大多数人是一个系统挑一个模型,于是被最难的那一步绑架: 只要有一步需要旗舰档,整条流水线就都用旗舰档,而那条流水线上 90% 的调用其实是简单活。 如果错,会错在: 如果你的调用量很小(一天几百次), 分档带来的省钱不值得多维护几套配置,那时候一档到底反而更省心。 判据是:先算一下每天的调用量。
7. 四条接入路:三条共用一套写法,一条必须换
书讲了四种接法。它们的差别比看上去小得多10:
这张表里也有两个还没讲过的说法。SDK:某一家把「怎么调它的接口」封装好的一个现成的库, 你装上就能直接写代码,不用自己拼网络请求。
多模态:同一个模型既能读文字,也能看图、听音频。
| 路 | 怎么接 | 书给的选择理由 | 反向理由 |
|---|---|---|---|
| OpenAI | 官方 SDK | 高吞吐生产部署时,速率上限和吞吐通常超过对手 | —— |
| Google Gemini | 复用同一套 SDK,只把地址换成它的 | 强多模态 + 长材料:文档超过 10 万个 token,或者要把图、音、文放进同一个请求时选它 | 短请求上它反而更慢——它的架构是为长材料和多模态优化的,小请求上有额外开销 |
| Anthropic Claude | 必须换成它自己的 SDK,协议和 OpenAI 那套不兼容 | 「倾向于给出更长的解释,并且显式标出歧义,而不是挑一个看着合理的答案」;适合法务审阅、合规分析、代码生成 | 同上一条的反面:要快、要短时它不占优 |
| Ollama(跑在自己机器上) | 也复用同一套 SDK,地址改成本机的 http://localhost:11434/v1 | 见下一节 | 见下一节 |
记住形状:四条路里三条共用一套写法、只改一个地址和一个模型名,只有一条必须换 SDK。 这件事在你要「换一家试试」时很重要——三条路之间换,改两行;换到第四条,改一段。
8. 什么时候把模型放回自己的机器上
这一节是上一节那第四条路的展开,而它值得单独一节: 它是全书少数几处给了硬件门槛和成本拐点的地方。
两条正面理由
书给的只有两条,而且都很具体11:
- 数据受监管、不能出网 —— 书点名的是医疗和金融这类受监管的数据;
- 调用量大到自建更便宜 —— 书给的拐点是每月百万次调用: 到了这个量级,自己养机器的成本才会低于按次付的接口费。
三个硬件门槛
8B 级别的模型 → 至少 8 GB 显存
13B 级别的模型 → 16 GB 以上显存
70B 级别的模型 → "对大多数笔记本来说太大"
图说:B = billion,十亿,数的是模型内部那些可调的数有多少个。
这三个数是书给的;它们的用处是让你在动手之前就知道自己那台机器够不够。
书原 文用的词是 VRAM,说的就是显存——显卡上自带的那块内存。模型跑起来的时候, 它内部那些数要整个装进显存里,所以这是本地跑模型的第一道硬门槛,和机器上的普通内存不能互相顶替12。
反向判据
书没有明说的两条,是我们从它的正面理由反推的:
判断(我们的,不是书里的): 如果你要的是最新的推理能力,别自己跑—— 开源(把模型内部那些数公开放出来、谁都能下载回去自己跑)的模型和最强的商用模型之间有代差, 而且这个差在推理这类能力上最明显; 如果你的团队开发速度比成本更要紧(比如还在验证这件事值不值得做), 也别自己跑——省下的接口费换不来搭一套推理服务的时间。 如果错,会错在: 如果开源模型在你那个具体任务上已经够用(比如只做分类、只做抽取), 第一条就不成立。判据是:先拿 50 条真实数据在两边各跑一遍。
一处必须纠正的:书里那张开源模型表已经过时
书的表 2-2「流行的开源语言模型」列了五个,发布时间停在 2023 到 2025 年13: Llama 2(2023 年 7 月)、Mistral 7B(2023 年 9 月)、Qwen 7B/14B(2023 年 9 月)、 Falcon 40B(2023 年 5 月),外加一个 2025 年 8 月的。
而同一节的示例命令写的是 ollama pull llama2 ——
照着敲,你拉下来的是一个两年多以前的模型14。
更矛盾的是,同一节后面的示例代码里,用的模型名却是 qwen3:4b,
这是表里根本没有的、更新的一代15。
判断(我们的,不是书里的):这处矛盾说明表 2-2 是早稿留下的,没跟着正文更新。 读到这一节时,只取「怎么接」的部分,别取任何具体型号; 要挑本地模型,去看它当下的官方模型库,不要照书里那张表。 如果错,会错在: 如果作者是有意保留这张表当「历史里程碑」, 那它不算错,只是没有标注用途——但书里没有任何一句话是这么交代的。
9. 主走查:一个采购分析师的问题,从话术到账单
这是本章的主走查,三个旋钮各在它上面占一步。 场景用书自己那个跑例:一个服务采购团队的助手2。
(书里给的是四档价、10 秒的延迟感受、以及那段话的四件套结构; 下面所有具体的 token 数、毫秒数、金额都是为演示编的,不是真实数值。)
第 1 步:第 02 章那条走查已经跑到第 5 步
用户问: "我们和 ACME 的标准合同,解约通知期是多少天?"
检索取回 3 块:
chunk-A "…either party may terminate with ninety (90) days' written notice…"
chunk-B "…renewal terms and notice requirements are set out in Annex 2…"
chunk-C "…the warranty period shall be twenty-four (24) months…" ← 不相关
注意 chunk-C 是不相关的。 这很正常——取回 3 块,不保证 3 块都有用。 (怎么量「几块有用」,第 17 章讲。)
第 2 步:旋钮一 —— 拼成四件套
[角色] 你是一个采购分析师,用简单可靠的方式解释内部政策。
[指令] 读下面检索到的材料,只用材料里的信息回答。
材料里没覆盖的,就说这份材料里没有。
[材料] <chunk-A> <chunk-B> <chunk-C>
[用户问题] 我们和 ACME 的标准合同,解约通知期是多少天?
[输出要求] 简短。措辞清楚。不超过 120 个词。
图说:注意 [指令] 那两句。因为有第二句,模型碰到 chunk-C 那种
不相关的材料时不会硬凑,碰到材料里真的没有时会直说没有。
第 3 步:旋钮三 —— 数一数这段话有多长
角色 + 指令 + 输出要求(每次都一样的那部分) ≈ 180 token
三块材料 ≈ 2 400 token
用户问题 ≈ 30 token
───────────
输入合计 ≈ 2 610 token
预计输出(一句话答案 + 一处引用) ≈ 90 token
这里就能看出第 5 节那笔账:那 180 个 token 的模板,每次都要付一遍。 一天一万次,就是一天 180 万个 token 白付在同一段话上。
第 4 步:旋钮二 —— 四档各要多少钱、多久
输入 2 610 输出 90 一次合计 首字延迟
超高效档 $0.00013 $0.00005 $0.00018 0.4 秒
高效档 $0.00065 $0.00027 $0.00092 0.8 秒
旗舰档 $0.0065 $0.0027 $0.0092 1.9 秒
推理档 $0.026 $0.011 $0.037 6.5 秒
一天一万次问答:
超高效档 $1.8/天 · 高效档 $9.2/天 · 旗舰档 $92/天 · 推理档 $370/天
图说:这些数是为演示编的,不是真实数值——只有四档的价格区间来自书。
要看清的是形状:同一个问题,最贵那档是最便宜那档的 200 倍,
而这个问题("在材料里找一个天数")根本用不着推理档。
照书的口径,这一步该选高效档: 用户在等,延迟必须在几秒内; 而任务是「在三段材料里找一个天数」——超高效档大概率也能做对,先从它试起。
第 5 步:把答案收成一个带类型的东西
如果这个答案要接进别的系统(比如自动填进一张合规检查表), 那就不该让它自由发挥,而该事先规定好它要填哪些字段——一个字段就是一条记录里的一格, 有名字也有类型,比如「天数,整数」16:
要求的字段:
notice_days 整数
source_chunk 字符串
found 是 / 否
拿到的东西(不是一段文字,是一个可以直接用的对象):
notice_days = 90
source_chunk = "chunk-A"
found = true
这一步叫结构化输出。
书给的机制解释里有一个名字要先交代:JSON 就是一种到处都在用的数据写法—— 用花括号把「名字:值」一对一对地写出来,几乎所有编程语言都能直接读写它。
机制本身一句话:接口在生成的时候就把模型约束住, 只允许它产出符合你这份字段清单的合法 JSON17。
它的两条代价,书写得很实在18:
| 代价 | 长什么样 |
|---|---|
| 延迟增加 | 它得一边生成一边保证格式合法 |
| 正确答案是「看情况」时会丢信息 | 你的字段只允许「是/否」,而真实答案是「主合同里是 90 天,但附件 2 对某几类服务另有规定」——硬逼二选一,细节就没了 |
10. 别信排行榜:三个陷阱
这是全书少见的一段方法论,值得单独讲。 书的态度是: 榜单只能当筛选工具,不能当最终判据19。三条理由:
| 陷阱 | 它怎么发生 |
|---|---|
| 题目泄漏,也叫数据污染:考题混进了训练材料 | 榜单的题和答案是公开的,可能已经(直接或间接)进了模型的训练材料,分自然就高 |
| 一旦成了目标,就会被专门优化 | 厂商会针对这个榜调模型,分涨了,通用价值没涨 |
| 和你的真实用法不匹配 | 你的模板 、你的检索质量、你要不要调工具、你的材料多长、多语言、延迟约束——这些都会实质改变结果 |
书自己下的结论是:「在榜单上赢的模型,在你自己的 RAG 查询上照样可能更差。」
怎么办,书也说了:榜单用来把候选从几十个缩到两三个,然后拿你自己的真实查询去比。 (具体怎么比、拿多少条题去比,第 16 章讲。)
11. 作者的判断与证据
| 说法 | 它是什么 |
|---|---|
| 输出 token 比输入贵,以及机制上的原因 | 是事实描述,而且解释正确:输出必须逐个生成,输入是一次并行处理的 |
| 四件套的结构 | 作者的做法归纳。 它不是什么标准,但它覆盖的四件确实都必要 |
| 「太松掺训练数据 / 太紧拒答」 | 作者的经验判断,书没给测量 |
| 四个档位与价格区间 | 是当时的市场事实(书自标「截至 2026 年 1 月」),必然过时 |
| 「用户很少愿意等超过 10 秒」 | 作者的经验数。 没有来源,没有实验 |
| 「挑仍然够用的最小模型」 | 作者的方法论主张,和全书「先简后繁」是同一条 |
| 各家的选择理由(谁更快、谁更啰嗦) | 作者的使用经验。 这类特性变化最快,今天读要打折 |
| 8B→8GB / 13B→16GB、每月百万次调用的 拐点 | 作者给的经验数;硬件那两个数在原理上可核,成本拐点那个数强烈依赖于你的具体用量和电费,不能照搬 |
| 榜单的三个陷阱 | 是业界共识,不是作者独创;书把它写清楚了,这一段是全书方法论含量最高的地方 |
12. 边界与局限
- 书里的型号自相矛盾。 表 2-1 标着「截至 2026 年 1 月」,列的是某一代; 而讲 Gemini 那一节的正文讲的是上一代;示例代码里又出现了第三组型号。 读这一章只取档位,不取型号;凡是型号,一律当它会变。
- 本地模型那张表停在两年多以前(第 8 节讲过),而示例命令会把过时的模型拉下来;
- 没有讲怎么测「这一步够不够用」。 书说「挑仍然够用的最小模型」, 可「够不够用」怎么判?这一章一个字没讲,答案在第 16、17 两章;
- 没有讲多轮对话怎么拼那段话。 四件套是单轮的; 多轮时之前那些来回怎么塞进去、塞多少,全书没有配方(第 01 章第 5 节那笔账因此没有下文)。
13. 可带走的
- 长度按 token 算,不按字数算。 token 是模型眼里的最小单位: 常见词整个一块,生僻词拆成几块,标点空格各占一块;
- 输出比输入贵得多,因为输出必须一个一个生成、每生成一个都要回看前面全部, 而输入是一次并行读完的。所以贵的不是你塞了多少材料,是你让它写了多长;
- 那段话有四件:角色 + 指令 + 检索到的材料 + 输出要求。 指令那一件必须写两句:「只用材料回答」+「没覆盖就说没有」,少一句都不行;
- 模板两头都会坏:太松会掺训练数据、编造引用;太紧会拒答边缘情况。 而且模板本身每次调用都要付一遍钱,写简洁点;
- 四个档位,最上和最下差 100 倍以上价钱。挑法是「仍然够用的最小那个」, 而且逐个流水线步骤地挑——在线那一步和离线那一步不必同档;
- 从延迟倒推:用户很少愿意等超过 10 秒(作者的经验数); 标准聊天场景取三四块材料,高效档往往就够;
- 四条接入路里,三条共用一套写法只改地址,只有一条必须换 SDK。 要「换一家试试」时,前三条之间改两行;
- 把模型放回自己机器上,只有两条硬理由:数据不能出网、每月百万次以上调用。 门槛是 8B 要 8GB 显存、13B 要 16GB;
- 要接进别的系统,就给它一份字段清单,直接拿到带类型的对象; 代价是延迟增加、以及正确答案是「看情况」时会被硬逼二选一;
- 榜单只能当筛子:题可能已经进了训练材料、厂商会专门为它调、 而且它和你的模板与检索质量不匹配。 缩到两三个候选之后,拿你自己的查询去比。
14. 原文地图
| 主题 | 原书章 | 原文位置 |
|---|---|---|
| 四件套的结构 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:36(搜「four key components」) |
| 那句「只用材料回答」的价值 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:46(搜「use only the retrieved context」) |
| 采购分析师那个模板原文 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:57(搜「procurement analyst」) |
| 太松 / 太紧两头都会坏 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:82(搜「fabricate citations」) |
| 模板本身也要付 token | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:84(搜「Templates add token overhead」) |
| 四个档位与价格 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:104(搜「Language model selection framework」) · text/04-ch02-chapter-2-foundation-models.txt:164(搜「per one million (1M) input tokens」) |
| 输出为什么更贵 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:156(搜「processed in parallel during a single forward pass」) |
| 挑仍然够用的最小模型 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:183(搜「the smallest model that still meets requirements」) |
| 10 秒那条延迟感受 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:185(搜「rarely wait more than 10 seconds」) |
| 别用大模型做简单分类 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:189(搜「Don’t use large reasoning models」) |
| Gemini 改地址复用同一套 SDK | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:338(搜「generativelanguage.googleapis.com」) |
| 长材料选它、短请求它更慢 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:358(搜「larger than 100,000 tokens」) · text/04-ch02-chapter-2-foundation-models.txt:360(搜「faster time-to-first-token」) |
| Anthropic 必须换 SDK | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:388(搜「uses its own protocol」) |
| Claude 的行为特点 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:417(搜「explicitly flags ambiguities」) |
| 本地跑的硬件门槛 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:595(搜「at least 8 GB」) |
| 本地跑的两条理由 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:597(搜「millions of API calls per month」) |
| 开源模型表(已过时) | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:532(搜「Popular open source language models」) · text/04-ch02-chapter-2-foundation-models.txt:460(搜「ollama pull llama2」) |
| 排行榜的三个陷阱 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:612(搜「screening tools」) · text/04-ch02-chapter-2-foundation-models.txt:624(搜「may still perform worse on your own RAG queries」) |
| 结构化输出的机制与代价 | Chapter 2. Foundation Models | text/04-ch02-chapter-2-foundation-models.txt:687(搜「constrains model generation」) · text/04-ch02-chapter-2-foundation-models.txt:701(搜「Forcing a binary answer」) |