周读：《Hands-On Large Language Models》！

索未 · 阅读｜周读·深度书评

索未 · 周读专栏

大语言模型不只是生成文字：从 Token、Embedding 到 RAG，重新理解 AI 如何处理信息

当我们打开一个大语言模型，输入问题并获得回答时，整个过程看起来非常自然。

我们使用完整的句子表达需求，模型也用完整的句子回应。它似乎能够理解词语、判断语境、组织观点，甚至表现出某种推理能力。

这种自然的交互方式，很容易让人产生一种错觉：

模型理解语言的方式，可能与人类差不多。

但大语言模型并不是直接读取句子，也不是像人一样先理解词义，再组织答案。

在进入模型之前，一段文字会被拆分为 Token；Token 会被转换成向量；向量经过 Transformer 中的注意力计算，在上下文中不断更新；最后，生成式模型根据已经出现的内容，预测下一个 Token 的概率。

从人类可读的语言，到模型能够计算的数字表示，中间存在一整套复杂但可以理解的过程。

《Hands-On Large Language Models》试图完成的，正是这项工作：

用直观图解、实际代码和应用案例，把大语言模型内部的关键机制连接起来。

这本书由 O'Reilly 于 2024 年 9 月出版，共 428 页，定位于初级到中级读者。全书分为三个部分：理解语言模型、使用预训练语言模型，以及训练和微调语言模型，覆盖 Token、Embedding、Transformer、文本分类、主题建模、提示工程、语义搜索、RAG、多模态模型和模型微调等内容。

官方代码仓库为 12 章内容分别提供了配套示例，作者还建议使用 Google Colab 运行代码，以降低本地配置和硬件门槛。书中包含近 300 幅原创图示，因此它也被作者称为"The Illustrated LLM Book"。

但它真正值得阅读的地方，并不只是“图很多”或者“代码比较容易运行”。

这本书帮助我们纠正了一个非常重要的认知偏差：

语言模型不只有生成文字这一种用途。

它既可以作为生成模型，也可以作为表示模型；既可以回答问题，也可以把文本转换成向量；既可以生成文章，也可以完成分类、聚类、检索、推荐和主题发现。

理解这一点，是从“使用聊天机器人”走向“理解语言模型能力体系”的第一步。

谈到大语言模型时，人们首先想到的通常是 ChatGPT 一类的生成式产品。

用户输入内容，模型继续生成文字。这类模型通常采用 Decoder-only 架构，其主要能力是根据当前上下文预测后续 Token。

但语言模型还有另一条重要路线：

表示模型。

表示模型的主要任务不是继续生成文字，而是把一段语言转换成能够反映语义的向量。

这两类模型解决的问题不同。

生成模型适合：

• 内容生成；
• 问答；
• 摘要；
• 改写；
• 翻译；
• 对话；
• 代码生成；
• 多步骤推理。

表示模型适合：

• 文本分类；
• 相似度比较；
• 语义搜索；
• 内容聚类；
• 推荐系统；
• 重复内容识别；
• 信息匹配；
• 知识库检索。

作者在书中使用不同颜色和图标，持续区分表示模型与生成模型，帮助读者理解：语言模型并不是一种单一能力，而是一组可以处理语言表示与语言生成的技术体系。

这一区分对企业 AI 应用非常重要。

很多企业遇到文本任务时，会本能地调用一个大型生成模型。

例如，要判断一批客户留言属于售前咨询、售后问题还是合作请求，企业可能让生成模型逐条阅读并输出分类结果。

这种方法可以工作，但未必是成本最低、速度最快、结果最稳定的方案。

对于大规模、重复性的分类任务，一个专门的表示模型或者经过微调的分类模型，可能更加合适。

再比如，要在数万份资料中找到与用户问题最相关的文档，真正承担第一步工作的通常不是生成模型，而是 Embedding 模型和检索系统。

生成模型负责组织最终答案，表示模型负责帮助系统找到相关信息。

生成模型负责“说什么”，表示模型往往负责“去哪里找”。

如果不能区分这两类能力，企业很容易把所有问题都交给同一种模型，最终增加成本、延迟和不确定性。

人类阅读一句话时，看到的是汉字、单词、标点和语义。

模型不能直接处理这些自然语言符号。

在文字进入模型之前，Tokenizer 会先把它拆分成一系列 Token，再把每个 Token 转换成词表中的编号。

Token 并不一定等于一个完整单词。

它可能是：

• 一个完整的词；
• 一个词的一部分；
• 一个汉字；
• 多个字符的组合；
• 一个标点；
• 一段代码符号；
• 一个特殊控制标记。

不同模型使用的 Tokenizer 不同，同一段文字可能被拆分成完全不同的 Token 序列。

书中专门比较了不同模型处理 Unicode、多语言、数字和代码时的 Tokenization 差异，并提供了可视化工具，让读者观察同一句话在不同 Tokenizer 中的拆分结果。

理解 Token 至少有四个现实意义。

模型的上下文窗口通常按 Token 计算，而不是按汉字数或单词数计算。

同样长度的内容，在不同语言、不同格式和不同 Tokenizer 下，消耗的 Token 数量可能不同。

因此，“一万字文档能不能放进模型”不能只看字数，而要看实际 Token 数量，以及系统还需要为提示词、检索材料、工具结果和输出预留多少空间。

很多模型服务按照输入和输出 Token 计费。

一段结构冗余、重复严重的提示词，不仅增加上下文负担，也会提高长期运行成本。

当一个 AI 工作流每天只运行十次时，差异可能不明显；当它每天处理数万次请求时，Token 设计就会成为真实的成本问题。

如果一个产品型号、专业术语或者少见名称被拆分成多个不常见 Token，模型可能更难稳定理解和生成它。

这也是为什么大语言模型有时会在普通文字上表现很好，却在型号、编号、URL、复杂数字和特殊格式上出错。

如果输入超过上下文窗口，部分内容可能无法进入模型。

即使系统支持很长的上下文，把大量无关资料一次性放入模型，也不意味着模型一定能够准确找到最重要的信息。

上下文窗口扩大，并没有取消信息筛选和上下文设计的重要性。

Token 让我们看到：AI 应用中的“语言输入”首先是一个计算资源问题，然后才是语言表达问题。

如果说 Token 解决的是“怎样把语言送入模型”，那么 Embedding 解决的是：

怎样让模型用数字表示语言之间的关系。

Embedding 通常是一组高维数字。

单独看其中某一个数字，几乎没有明确的人类含义；但当大量维度组合起来时，它可以表示一个 Token、一句话、一段文档，甚至一张图片的特征。

在 Embedding 空间中，语义相近的内容通常会拥有相近的向量位置。

例如：

• “如何维护工业设备”
• “设备日常保养方法”
• “机械维护注意事项”

这三句话使用的词并不完全相同，但表达的主题相近。一个质量较好的 Embedding 模型，应该能够将它们映射到相近的位置。

而“本季度市场预算是多少”与它们的距离则应当更远。

这正是语义搜索能够超越关键词匹配的原因。

传统关键词搜索主要寻找相同或相近的文字。

语义搜索则尝试寻找意思相近的内容。

O'Reilly 对本书的介绍明确提到，读者将学习使用 Dense Retrieval 和 Reranker 构建超越关键词匹配的语义搜索系统，同时使用预训练模型完成分类、搜索和聚类。

Embedding 至少支撑了五类重要应用。

把用户问题与文档分别转换成向量，再寻找距离最近的文档。

把文章、商品、视频或其他对象转换成向量，根据相似度进行推荐。

书中甚至用歌曲和播放列表演示了 Embedding 思想：将歌曲视为 Token，将播放列表视为句子，通过共同出现关系学习歌曲之间的相似性。

把大量文本转换成向量后，根据其空间位置自动形成不同主题群组。

比较不同页面或文档的语义距离，发现高度重合、表达相近或可能互相竞争的内容。

在生成答案之前，先通过向量检索找到相关资料。

对于 SEO、网站运营和内容管理而言，Embedding 也具有直接价值。

它可以用于：

• 识别网站中主题高度重复的页面；
• 发现内容体系中的语义空缺；
• 根据搜索意图聚类关键词；
• 为相关文章推荐提供支持；
• 判断用户问题与现有页面是否匹配；
• 构建企业内部知识库；
• 组织大量客户反馈和咨询记录。

但 Embedding 并不等于“真正理解”。

两个向量距离较近，只能说明模型认为它们在训练所得的表示空间中相似。

这种相似可能来自主题、语境、语气或者共同出现关系，并不自动证明两个对象在业务上可以互相替代。

因此，Embedding 相似度应该被视为一种候选判断，而不是最终结论。

同一个词在不同句子中，可能具有不同含义。

例如，“模型”可以指工业模型、商业模型、数学模型，也可以指人工智能模型。

如果系统只为“模型”这个词分配一个固定向量，就很难根据上下文判断它具体表示什么。

Transformer 的重要能力之一，是生成上下文化表示。

当一个 Token 进入模型后，它的表示并不是固定不变的。模型会通过 Self-Attention 观察上下文中的其他 Token，并重新计算这个 Token 在当前句子中的表示。

注意力机制可以被直观理解为：

模型在处理当前 Token 时，应该关注上下文中的哪些信息，以及关注多少。

例如，在句子“这款模型能够处理长文档”中，“模型”可能与“处理”“长文档”等 Token 形成较强关系。

在“公司正在调整商业模型”中，它则会更多受到“公司”“商业”“调整”等上下文影响。

书中第三章从输入、输出、Transformer Block、位置编码、注意力计算、采样解码和 KV Cache 等方面解释了模型的一次前向传播过程。

理解 Transformer，不一定要求普通读者立即掌握所有矩阵计算，但至少应该理解四件事。

第一，模型不是一次生成整段答案

生成式模型通常逐个 Token 生成内容。

每次生成一个新 Token 后，它会把这个 Token 加入上下文，再预测下一个 Token。

因此，前面生成的错误可能会继续影响后续内容。

这也是为什么一个回答一旦在早期采用了错误假设，后面可能围绕错误前提生成一套看起来完整的解释。

第二，输出不是唯一确定的

模型会产生下一个 Token 的概率分布。

系统再根据解码策略，从候选 Token 中选择一个。

Temperature、Top-p 等参数会影响输出的随机程度。

因此，相同输入可能产生不同答案。这并不一定意味着系统故障，而是生成模型概率性质的一部分。

第三，注意力不等于人类意识

"Attention"是计算机制，不应被直接解释为模型具有人的注意力、意识或主观体验。

它表示不同 Token 在计算过程中的关联权重，而不是模型像人一样有意识地决定关注什么。

第四，长上下文也有成本

上下文越长，计算、内存和延迟压力通常越大。

KV Cache 等机制可以减少生成过程中对已有 Token 的重复计算，但并没有让长上下文变成零成本资源。

因此，AI 应用设计仍然需要决定：

哪些信息必须提供，哪些可以通过检索获得，哪些应该先摘要，哪些应被删除。

Transformer 并不是只有一种使用方式。

书中把现代语言模型大体区分为表示型模型和生成型模型，这通常对应 Encoder-only 和 Decoder-only 两条路线。

Encoder-only 模型

典型用途包括：

• 文本分类；
• 命名实体识别；
• 情感分析；
• 文本表示；
• 相似度计算；
• 语义检索。

它们通常同时观察输入两侧的上下文，重点是理解和表示现有内容。

Decoder-only 模型

典型用途包括：

• 续写；
• 问答；
• 摘要；
• 对话；
• 推理；
• 代码生成。

它们通常根据已经出现的 Token 预测后续 Token，重点是生成。

这两类架构并不是谁取代谁。

它们适合的任务不同。

在真实系统中，二者经常协同工作：

1. 表示模型把用户问题转换成向量；
2. 检索系统找到候选文档；
3. Reranker 重新判断相关性；
4. 生成模型根据文档生成答案。

这说明一个成熟 AI 系统往往不是依赖“一个万能模型”，而是由多个能力模块组成。

最强的单一模型，并不一定等于最好的系统。

书中没有把全部篇幅放在内容生成上，而是专门讲解了文本分类。

这非常重要，因为企业中的大量语言任务，本质上并不是开放式生成，而是判断和归类。

例如：

• 这条留言属于哪种意图；
• 这封邮件是否需要优先处理；
• 这段内容是否包含风险表述；
• 这个客户反馈属于哪种问题；
• 这个页面对应哪个主题；
• 这条评论是正面、负面还是中性。

这类任务可以有多种实现方式：

• 使用任务专用分类模型；
• 使用 Embedding 加传统分类器；
• 使用零样本分类；
• 使用少量标注数据进行微调；
• 使用生成模型按照指定格式输出类别。

每种方式都有不同的成本和适用范围。

生成模型部署方便、迁移灵活，但可能存在输出格式漂移、延迟和成本问题。

专用分类模型前期需要准备数据，却可能在大规模稳定任务中更高效。

因此，模型选择不应围绕“哪个模型能力最强”，而应围绕：

• 任务是否开放；
• 类别是否固定；
• 数据量有多大；
• 是否有标注数据；
• 错误成本有多高；
• 是否需要解释；
• 是否需要实时处理；
• 是否会频繁增加新类别。

当问题本质上是分类时，不要因为生成式 AI 流行，就把它强行改造成生成任务。

分类需要预先知道类别。

聚类则适用于我们尚不清楚数据中包含哪些主题的情况。

假设一家企业积累了数万条客户咨询。

人工可能预先定义“价格”“交期”“技术参数”“售后”等类别，但真实数据中也许还存在一些没有被意识到的问题：

• 某个地区客户反复关注特定认证；
• 某类产品持续出现安装疑问；
• 某个时间段集中出现物流投诉；
• 用户对某个术语存在普遍误解。

文本聚类可以帮助系统先把语义相近的内容聚合，再由人工分析每个群组代表什么。

本书作者之一 Maarten Grootendorst 也是 BERTopic 的作者。书中使用 Embedding、降维、聚类和主题表示组成模块化主题建模流程，并进一步展示如何使用生成模型为主题提供更易读的描述。

这类方法对内容运营尤其有价值。

它可以帮助我们从大量搜索词、客户问题、站内搜索记录、评论和客服对话中，发现真实的主题结构。

传统内容规划常常从企业内部分类出发。

而聚类分析可以从用户语言出发，观察用户实际上如何描述问题。

这两种分类体系往往并不相同。

企业可能按照产品型号组织网站，用户却按照使用场景、故障现象、预算水平和采购阶段进行搜索。

主题建模的价值，不只是自动生成几个标签，而是发现企业分类方式与用户认知方式之间的差距。

书中第六章讨论提示工程，但它没有把提示词描述成某种固定公式。

一个有效提示通常包含若干基本元素：

• 明确的指令；
• 必要的上下文；
• 输入数据；
• 输出要求；
• 示例；
• 限制条件。

在复杂任务中，还可以使用：

• In-context Learning；
• Few-shot 示例；
• Chain Prompting；
• Self-consistency；
• 输出验证；
• 受约束生成。

但作者展示这些方法的目的，并不是让每个任务都使用最复杂的提示结构。

真正重要的是理解：

提示词是在改变模型生成结果的概率分布，而不是向确定性程序下达绝对命令。

即使提示词非常清晰，模型仍可能出错。

因此，企业不能把重要规则只写在自然语言提示词中，然后默认模型一定执行。

对于格式、金额、权限、产品参数和法律要求等关键内容，还需要使用：

• 结构化输出；
• 字段验证；
• 数据库校验；
• 规则程序；
• 人工审批；
• 异常拦截。

提示工程能够提高模型表现，却不能代替系统控制。

RAG 通常被理解为“让模型读取企业资料”。

但从系统流程看，RAG 至少包含两个部分：

如果检索阶段没有找到正确内容，生成模型再强，也只能基于错误、不完整或无关的上下文回答。

书中将语义搜索、Dense Retrieval、Reranking、检索评估、RAG 生成与 RAG 评估放在同一章中，说明 RAG 不是简单地“接入一个向量数据库”，而是一套完整的信息检索与生成流程。

一个较完整的 RAG 流程可能包括：

1. 收集文档；
2. 清理重复与过期版本；
3. 按合理粒度切分；
4. 为文档块生成 Embedding；
5. 保存内容与元数据；
6. 将用户问题转换成向量；
7. 检索候选内容；
8. 使用 Reranker 重新排序；
9. 把最相关内容提供给生成模型；
10. 生成带来源约束的答案；
11. 评估检索和回答质量。

这里有两个容易被忽略的问题。

检索质量和生成质量必须分开评估

如果最终答案错误，首先要判断：

• 正确资料是否被检索出来；
• 正确资料是否进入模型上下文；
• 模型是否正确使用了资料；
• 输出是否遗漏、曲解或者错误组合信息。

如果不区分这些环节，团队很容易把所有问题归因于“模型不够强”。

相似不等于相关

向量搜索找到的是语义相似内容。

但语义相似不一定满足具体业务条件。

例如，用户询问 2026 年的政策要求，系统可能检索到主题非常相似、但已经过期的旧文档。

因此，RAG 检索还需要结合：

• 发布时间；
• 适用国家；
• 产品类别；
• 文档权限；
• 版本状态；
• 来源级别；
• 业务字段。

这也是为什么企业知识库不能只是把所有 PDF 上传后就宣布完成。

RAG 系统的上限，往往取决于内容治理和检索设计，而不是生成模型的语言能力。

语言模型的发展并没有停留在文字。

书中第九章讨论了视觉 Transformer、多模态 Embedding、CLIP、OpenCLIP 和 BLIP-2 等方法，解释文本与图像如何被映射到可比较的表示空间，以及生成模型如何接收图像输入。

多模态能力的重要意义在于：

过去需要不同系统分别处理文字、图片、音频和视频；现在，这些信息正在逐渐进入能够相互关联的模型体系。

例如，系统可以：

• 根据文字搜索图片；
• 判断图片与页面主题是否匹配；
• 为产品图片生成说明；
• 从图表中提取信息；
• 分析扫描文档；
• 检查视觉素材是否缺少关键要素；
• 将图片内容与知识库文本结合。

但多模态也会带来新的错误类型。

模型可能遗漏图片细节、错误读取数字、混淆物体关系，或者根据视觉模式生成并不存在的信息。

因此，多模态输出同样需要结构化验证和人工审核，特别是在技术参数、医疗、法律、财务和安全相关场景中。

这本书的第三部分进入模型训练与微调，包括 Embedding 模型训练、表示模型微调，以及生成模型的 SFT、PEFT、LoRA、QLoRA、奖励模型和 DPO 等内容。

很多人会把微调理解为：

把企业资料交给模型训练，让模型记住这些知识。

这种理解并不完整。

微调更适合改变模型的行为模式，例如：

• 学习特定输出格式；
• 适应专业任务；
• 使用稳定语言风格；
• 提高某类分类能力；
• 更好地遵循特定指令；
• 适应某一领域的表达方式。

如果主要目标是让模型获得经常变化的最新知识，RAG 通常比微调更容易更新和追溯。

因为企业知识发生变化时，可以更新知识库；如果把知识写入模型参数，则需要重新训练，而且模型未必能够准确、完整地调用这些知识。

微调也不是越早越好。

在决定微调前，至少应先确认：

• 基础模型是否已经能够完成任务；
• 提示词是否充分；
• 是否缺少必要上下文；
• RAG 是否可以解决问题；
• 是否已经建立稳定评估集；
• 是否拥有足够高质量训练数据；
• 微调收益是否能够覆盖训练和维护成本。

没有评估集的微调，很容易变成一种无法证明效果的技术投入。

普通读者不一定需要立即训练模型，也不一定需要完成全部代码。

但至少可以从书中获得四项重要认知。

生成式模型根据 Token 概率生成内容。

语言流畅只能说明结果符合语言模式，不能证明事实正确。

分类、聚类、检索、推荐和相似度计算，同样是语言模型的重要用途。

Tokenizer、Embedding、检索、上下文、解码方式和数据质量，都会影响最终结果。

长上下文不能替代文档清理、结构设计、检索和来源管理。

如果把《AI Engineering》看作一本关于如何建设 AI 系统的书，那么《Hands-On Large Language Models》更像是一本关于语言模型能力组件的地图。

它帮助企业理解：

一个 AI 应用不一定只需要一个生成模型。

更常见的系统可能包含：

• Tokenizer 负责处理输入；
• Embedding 模型负责表示语义；
• 向量索引负责寻找候选内容；
• Reranker 负责重新排序；
• 分类模型负责识别任务或风险；
• 生成模型负责组织答案；
• 规则程序负责检查关键字段；
• 人工负责高风险审核。

对企业而言，真正应该建设的不是“一个聊天机器人”，而是根据任务组合不同能力。

例如，一个企业知识助手可以采用以下结构：

1. 先识别用户身份与权限；
2. 判断问题属于哪个业务领域；
3. 检索对应知识库；
4. 根据时间、版本和来源过滤资料；
5. 对候选文档重新排序；
6. 生成回答；
7. 检查是否包含必要引用；
8. 对高风险问题转交人工；
9. 记录反馈用于持续改进。

这比“把所有文件上传给模型，然后让员工自由提问”复杂得多。

但也只有走到这一步，AI 才开始成为真正可管理的业务系统。

《Hands-On Large Language Models》出版于 2024 年。

大语言模型、推理模型、多模态模型、Agent 框架和开发工具仍在快速变化。书中使用的一些模型、库和调用方式，未来可能需要按照新版接口调整。

因此，不能把书中的某段代码当作长期不变的标准实现。

这本书更值得保留的是相对稳定的知识结构：

• Tokenization；
• Embedding；
• Transformer；
• 表示模型与生成模型；
• 分类与聚类；
• 语义搜索；
• RAG；
• 微调；
• 评估。

此外，本书强调直观理解与实践，适合作为进入大语言模型领域的地图，但不会完整推导全部数学细节。

希望深入矩阵运算、反向传播、训练循环和从零实现 GPT 类模型的读者，还需要继续阅读更偏底层实现的资料。

本周不必立即建设复杂 RAG 系统。

可以先选择 20 篇文章、20 份产品说明或者 20 条常见问题，完成一个最小语义检索实验。

第一步：准备数据

为每份内容记录：

• 标题；
• 正文；
• 所属主题；
• 发布时间；
• 来源；
• 是否仍然有效。

第二步：生成 Embedding

使用同一个 Embedding 模型，把每份内容转换成向量。

第三步：准备测试问题

设计 10 个真实用户可能提出的问题。

其中应包括：

• 与原文用词相同的问题；
• 意思相同但表达不同的问题；
• 容易产生歧义的问题；
• 当前资料无法回答的问题。

第四步：检查检索结果

观察每个问题返回的前三项内容，并记录：

• 正确资料是否出现；
• 正确资料排在第几位；
• 是否返回了过期内容；
• 是否存在主题相似但实际无关的内容；
• 无答案问题是否仍然返回了错误资料。

第五步：再决定是否加入生成模型

如果检索本身不可靠，不要急着加入生成模型。

先改善：

• 文档切分；
• 标题信息；
• 元数据；
• 查询改写；
• Embedding 模型；
• 混合检索；
• Reranking。

这项实践能够帮助我们直观看到：

RAG 系统最先需要解决的不是“怎样生成答案”，而是“怎样找到正确证据”。

《Hands-On Large Language Models》最重要的价值，是让大语言模型从一个看似神秘的对话工具，变成一组可以理解、组合和实践的技术组件。

模型看到的不是句子，而是 Token。

模型理解的不是抽象词义，而是不断变化的向量表示。

上下文不是被整体读懂，而是通过注意力机制形成 Token 之间的关联。

语义搜索不是简单匹配关键词，而是在 Embedding 空间中寻找相近内容。

RAG 不是让模型自动掌握企业知识，而是先检索证据，再约束生成。

微调也不是解决一切问题的最后手段，而是针对明确行为目标进行模型调整。

当这些概念被连接起来后，我们会发现：

大语言模型的真正价值，不只是生成一段像人写的文字，而是让语言第一次大规模进入可计算、可检索、可分类、可聚类和可生成的统一技术体系。

这也意味着，未来的 AI 能力不应只用“回答得像不像人”衡量。

更应该观察它是否能够：

• 正确表示信息；
• 找到相关证据；
• 区分不同任务；
• 处理多种数据；
• 在明确边界内生成结果；
• 接受评估与持续改进。

理解这些基础机制，并不会削弱我们对 AI 能力的想象。

相反，它能够让我们更加准确地判断：

AI 真正擅长什么，为什么会失败，以及我们应该怎样把它建设成一个可靠的现实系统。

⸻

本期互动

你在使用 AI 时，最希望深入理解的是哪一部分？

是 Token 与上下文、Embedding 与语义搜索、Transformer 与注意力机制，还是 RAG 与企业知识库？

欢迎留下你最关心的问题。后续也会结合具体应用场景继续展开。

下期预告

周读：《Build a Large Language Model (From Scratch)》·Sebastian Raschka

下一期将进一步进入模型内部，从数据准备、Tokenization、Attention、训练循环和指令微调出发，理解一个 GPT 类大语言模型究竟是怎样从零构建出来的。

标签

#人工智能 #大语言模型 #HandsOnLargeLanguageModels #LLM #Token #Embedding #Transformer #注意力机制 #语义搜索 #RAG #文本分类 #主题建模 #多模态模型 #模型微调 #AI 应用 #企业 AI #终身学习 #周读