第5章 机器怎么听懂人话：从字面匹配到语义表示

本章导读

前面已经用 AI 处理过数字——身高、体重、跳远。这样的 AI 比较容易理解：数字进、数字出，跟做数学题差不多。

但你跟 AI 聊天时，输入的是自然语言——一句话、一段问、一篇文档。AI 是怎么理解这些文字的？同样一句话在不同场合意思不同，同样的意思可以有几十种说法，机器是怎么处理这种开放、模糊、依赖场景的复杂性的？

这一章带你完整走一遍 NLP（自然语言处理）的工程演进——从规则系统到统计学习到深度学习——并通过一个对比实验亲眼看见字面相似和语义相似的根本差别。读完这一章你会建立三个核心认识：

1. 机器处理自然语言经历了三代技术演进，每一代都在回应前一代的关键局限。
2. 字面相似 ≠ 语义相似 ——这个判断是后面所有语言相关章节的基石。
3. AI 的懂是数学上的接近，不是真正的领会——这个区分决定了你将来怎么用 AI、什么时候必须人工复核。

这一章不只是知识铺垫，更是后面整套技能的工程伏笔：

• 第6章提示词工程会反复用到 AI 的懂很表面，所以任务要说清楚这条。
• 第7章幻觉问题会继续讨论：AI 的“知道”常常是统计和语义模式上的接近，不等于事实核验。
• 第8章 RAG（检索增强生成）的底层会用到词向量 + 余弦相似度——本章会通过实验观察这一机制。

《易经·系辞》说：书不尽言，言不尽意。 文字写不全要说的话，说话也装不下全部意思。机器处理语言时，难就难在要从有限字句中寻找更完整的语义关系。

学习目标

• 知识目标：
  1. 能完整描述 NLP 的三代技术演进：规则系统 → 统计学习（TF-IDF / 词袋）→ 深度学习（词向量 / Transformer）——每一代的核心思想、代表方法、主要局限。
  2. 能用通俗语言说明 RNN 顺序读取文本的基本直觉及其长距离依赖衰减问题，并知道 Transformer 通过注意力机制改善了这种局限。
  3. 能解释词向量（embedding）、余弦相似度（cosine similarity）、语义检索三个核心概念的工程含义。
• 能力目标：
  1. 能借助大模型协同编程，在本地完成关键词匹配 vs 语义向量匹配的对比实验。
  2. 能根据实验输出的相似度数值，判断在不同业务场景下应选哪种匹配方式。
• 素养目标：
  1. 建立字面相似 ≠ 事实一致 ≠ 语义一致的工程警觉——这是 AI 应用质量评估的基础。
  2. 在设计涉及用户核心权益的智能问答场景时，能主动设立人工复核点。

先修要求与环境清单

• 先修知识：完成第 1—4 章；能在课程工作区中打开 Notebook、运行 Python 单元格，并保存提示词、输出和人工复核记录。
• 软件环境：
  • Python 3.10+。
  • 第 3 章已经验证过的 AI 学习环境（本地模型服务、课程机房环境或合规云端接口）。
  • 本章核心依赖：numpy（数值计算）、requests（调用本地接口）；TF-IDF 部分尽量用 Python 标准库实现，便于看清原理。
• 模型与接口：
  • 本地路径：优先使用课程指定的本地 embedding 模型，例如 nomic-embed-text、mxbai-embed-large 或其他轻量向量模型，以课程环境实际配置为准。
  • 接口路径：如使用新版 Ollama 官方 API，优先调用 POST /api/embed；若配套环境保留旧接口，应以环境中的脚本说明为准。
  • 云端路径：可使用任意提供 embeddings 接口的合规服务商，但必须先确认数据脱敏、账号权限和费用规则。
• 配套资源：
  • notebooks/ch05_text_similarity.ipynb——本章主实践 Notebook。
  • scripts_optional/ch05/compare_similarity.py——拓展版可选脚本，供阅读、修改和复现实验使用。

本章提醒：所有客服、情绪、群聊和业务案例均为模拟文本。不得把真实学习群聊天记录、学生心理状态、客户资料或企业内部文档上传到公共平台做实验。

知识准备：先认识这些词

1. 分词 / 切分（tokenization）
   • 一句话说明：把连续的文本切成机器可以逐步处理的词元或子词。
   • 工程要点：现代大模型多用 BPE / SentencePiece 等子词切分，能在一定程度上处理新词；早期英文系统按空格切分，中文则常用 jieba 等工具切分。
2. 词袋模型（bag of words, BoW）
   • 一句话说明：把一段话当成一袋词，只数每个词出现了几次，完全忽略顺序。
   • 典型局限：猫咬狗和狗咬猫在 BoW 看来一模一样。
3. TF-IDF（词频-逆文档频率）
   • 一句话说明：给一段话里的每个词打分——既看它在这段话里出现的频率（TF），又看它在所有文档中的稀有度（IDF）。
   • 工程价值：解决了 BoW 把的、是、了这种高频词当成主题的弊病。
4. 循环神经网络（recurrent neural network, RNN）
   • 一句话说明：按从左到右逐字阅读文本的早期深度学习模型——拥有一个内部记事本（隐状态）记住前文。
   • 工程瓶颈：长距离依赖衰减——读到几百字之后，开头的信息已经被中间内容稀释。
5. 长距离依赖（long-term dependency）
   • 一句话说明：前文很远的信息要影响当前判断时面临的衰减问题。
   • 典型场景：长文本翻译或摘要中，后文需要引用很早以前出现的人物、地点或条件，模型可能遗漏或混淆。
6. 词向量 / 嵌入（embedding）
   • 一句话说明：把一个词或一段话映射到高维数学空间里的一个坐标向量——意思相近的内容在向量空间里挨得近。
   • 工程价值：让机器能用距离 / 角度做近似的语义比较——这是现代搜索、推荐、问答的底层基础。
7. 余弦相似度（cosine similarity）
   • 一句话说明：测量两个向量夹角余弦的方法——夹角越小，余弦值越接近 1，意思越相近。
   • 数学含义：cos(θ) = (A · B) / (|A| × |B|)——只关心方向，不关心向量长度。
8. 语义检索（semantic search）
   • 一句话说明：把用户问题和知识库内容都转成向量，按向量距离找最接近的——而不是按关键词重合度找。
   • 工程地位：现代 RAG、智能客服、企业知识库的标准做法。
9. 未登录词（out of vocabulary, OOV）
   • 一句话说明：模型在训练阶段没直接见过的新词——网络新梗、新出现的专业术语、生造词。
   • 现代缓解：子词切分能把新词拆成已知片段处理，但仍不能完全消除歧义。

5.1 问题与现象：为什么计算规则容易，理解自然语言更难？

5.1.1 一个反直觉的对照

任务 A: 算 100 道复杂的微积分题      →  秒级
任务 B: 完整理解一篇小学生日记       →  至今没完全做到

为什么数学这么难，电脑反而擅长；语言这么简单，电脑反而吃力？

根本原因：数学题的边界是封闭的——符号都有精确定义、规则一目了然；而自然语言的边界是开放的——同一句话在不同场合意思不同，同一个意思有几十种表达方式，很多事情依赖人类常识。

5.1.2 三种典型的语言困境

让我们看三种 NLP 长期面对的难题：

困境 1：一词多义（polysemy）

• 我要挂了
  • 通话场景：挂电话
  • 学习群：挂科
  • 急救场景：危急

同一字符序列，意思完全不同——靠上下文消歧。

困境 2：同义异构（synonymous expressions）

同一个客服诉求可以是： * 钱能退吗? * 帮我办个售后。 * 我不想要这东西了。

三句话没有任何共同的字，但意图完全一致。任何只看字面的系统都会把它们当成完全不同的问题。

困境 3：常识依赖（commonsense reasoning）

• 老鼠吃掉了奶酪，因为它太饿了。 → 它指老鼠。
• 老鼠吃掉了奶酪，因为它太诱人了。 → 它指奶酪。

人类靠常识瞬间判断，但机器必须先把老鼠会饿、奶酪会诱人这种常识学进去。

5.1.3 一个具体的工业级场景

假设你以后做一个智能客服系统，用户发来：

你们这个软件的退款功能隐藏得也太深了！

如果系统只做字面匹配——抓到功能、深——可能回复：

亲，建议您升级到最新版本体验更多功能哦~

结果：用户在投诉，AI 在推销。客户更怒。

这个例子告诉我们：

系统必须更好地识别句子背后的诉求和情绪，而不能只做字面对对碰。

这就是 NLP 三代技术演进想要解决的核心问题——从字面到意思。

【思考 1】 有人说：我做了一个 NLP 系统，用关键词匹配检索常见问题：用户问的每句话和 FAQ 库里的标准问题做“共同字数”对比，共同字最多就匹配到。请结合 5.1.2 节，至少举两类这个系统会出问题的具体场景。

思考提示：① 同义异构 —— 钱能退吗在 FAQ 库里找不到包含退和钱的标准问题,但其实就是退款诉求。改进:用语义匹配,不只看字面。② 一词多义 —— 用户说挂号要怎么挂,系统匹配到挂字最多的 FAQ 可能是如何挂电话,完全答非所问。③ 投诉性表达 —— 用户说你们家服务也太差了,字面匹配可能找到服务介绍标准问题,但用户其实是投诉。只看字面会同时输给同义异构和一词多义。

5.2 原理与分析：自然语言处理的三代演进与词向量直觉

相关结构如图5-1所示。

图中位置是教学简化后的二维投影。真实语义向量通常是高维数字，本图只帮助观察“字面相似”和“语义相似”之间的差别。

5.2.1 第一代：规则系统时代

最早的方法：请语言学专家手工编写规则。

# 客服分流规则示例
IF input contains ("退款" OR "退货" OR "退钱") THEN dept = "售后"
IF input contains ("咨询" OR "问问" OR "请教") THEN dept = "客服"
IF input contains ("投诉" OR "差评") THEN dept = "投诉主管"
...

优点：完全可控、可解释、可审计——每一步都能说出来。

主要局限：

• 人类语言开放——你能写一万条规则，但用户发明的第 10001 种说法仍可能让规则失效。把米还给我 这样的表达，规则库未必覆盖。
• 维护成本指数级增长——新业务上线、新词流行，规则库都要更新。
• 跨语言、跨领域几乎重写一遍——专家时间极其昂贵。

这条路曾经是 NLP 的重要路线。今天，在强规则、强合规的业务系统中，规则仍常作为安全护栏或兜底逻辑使用；但面对开放自然语言时，单靠规则难以覆盖所有表达。

5.2.2 第二代：统计学习时代（TF-IDF / 词袋）

人们想：既然规则写不过来，能不能让机器从大量文本中自动数词频？

核心方法：TF-IDF 和词袋模型（BoW）。

TF-IDF 直觉： * TF（term frequency）：一个词在当前文档中出现的频率——出现越多，越可能是主题。 * IDF（inverse document frequency）：一个词在所有文档中的稀有度——越罕见越有区分价值（的是了出现到处都是所以 IDF 很低）。 * 一段话用 TF-IDF 表示，就是它的每个词对应一个权重。 * 比较两段话相似度：算它们 TF-IDF 向量的余弦相似度。

例子：

A: "番茄炒蛋盖浇饭"   → 拆词为 [番茄, 炒, 蛋, 盖, 浇, 饭]
B: "西红柿炒鸡蛋盖饭" → 拆词为 [西红柿, 炒, 鸡蛋, 盖, 饭]

A 和 B 的共同词: {炒, 盖, 饭}
TF-IDF 算出来: 有一定相似度

优点： * 自动化——不需要手写规则。 * 在找包含某些关键词的文档任务上表现不错——这就是为什么早期搜索引擎能用。

主要局限： * 同义表达难以识别：番茄和西红柿是两个完全不同的字符串，TF-IDF 难以识别它们含义相近。 * 顺序信息丢失：BoW 把 猫咬狗 和 狗咬猫 当成一模一样。 * 没有语义：它在数字面共现，对意思无感。

第二代解决了第一代覆盖不全的问题，但没解决看不见意思的问题。

5.2.3 第三代：深度学习时代（RNN → 词向量 → Transformer）

第三代的关键技术突破是 embedding（嵌入）——把词从字符串映射成高维向量，让意思相近的词在向量空间里挨得近。

RNN：早期深度学习的尝试

RNN 引入了隐状态（hidden state）——相当于给机器一个内部记事本，读到第 N 个词时不只看这个词，还查阅前面读到的累积印象。

但 RNN 面临明显的长距离依赖衰减问题。读到很后面时，容量有限的内部记事本容易被中间内容稀释，开头信息对后续判断的影响会减弱。这就像玩传声筒——传到第 10 个人时第 1 句话已经面目全非。

这个瓶颈在 Transformer 架构提出后得到明显缓解。Transformer 用自注意力机制代替了 RNN 的单向顺序读取，使模型更容易在长文本中建立远距离位置之间的联系。今天的主流大模型大多以 Transformer 或其变体为基础。这是后面第7章会更详细展开的话题。

词向量：把意思翻译成数字

embedding 的核心思想是这样的：

设想有一张"语义地图"——上面每个词都有一个坐标:

"教师"  → 坐标 [0.9,  0.1,  -0.4, ..., 0.32]    (768 维)
"老师"  → 坐标 [0.88, 0.12, -0.38, ..., 0.31]   ←─几乎重合
"学生"  → 坐标 [0.7,  -0.5, 0.1,  ..., 0.15]    ←─挨得近
"拖拉机" → 坐标 [-0.3, 0.8,  0.5,  ..., -0.8]    ←─很远

这些坐标怎么来的？通过在海量文本上进行自监督或上下文预测等训练任务，模型逐步学到词语和句子的使用规律——老师和教师经常在相似上下文中出现，所以向量应当接近；教师和学生经常共同出现，所以也会形成一定关联。

余弦相似度：测量语义距离

衡量两个向量方向接近的常用方法是余弦相似度，如图5-2所示：

cos(θ) = (A · B) / (|A| × |B|)

• cos(θ) = 1：两个向量方向完全一致——意思高度相近。
• cos(θ) = 0：两个向量正交——几乎没有语义关联。
• cos(θ) = -1：两个向量方向相反——意思完全对立。

在本章实验中，可以先把相似度数值当作相对比较：谁更高，谁更可能语义接近。真实业务中，0.8、0.7 或 0.5 是否可用，必须通过测试集、错误样例和人工复核流程来确定。

这能缓解第二代的核心问题：

• 番茄 和 西红柿 因为出现的上下文高度相似，向量通常很接近——同义异构识别效果更好。
• 苹果在不同上下文里的表示可以不同——通过更复杂的上下文嵌入，模型能更好地区分“苹果手机”和“苹果水果”等一词多义场景。

5.2.4 但请非常注意：现代 NLP 也不等于真正理解

这是这一章最重要的一条工程认识：

AI 的“懂”是数学上的接近，不等于人的理解。

具体说：

• AI 能算出老师和教师的向量距离小——因此可以判断它们语义接近。
• AI 不能真正理解老师在你心里到底意味着什么。
• AI 能识别我今天好开心是正面情绪——但它不真正体验开心。
• AI 能算出我撑不住了含有强烈负面情绪——但它不真正理解当事人的处境和求助需求。

这条认识的工程含义：

相关内容见表5-1。

表5-1 章节与工程落地记录表

5.2.5 词向量是后面 RAG 的底层

这一节为下面章节做一个工程铺垫——现代大模型的 RAG（检索增强生成）就建立在词向量之上：

用户问题 → 转成向量 → 在向量库里搜"最近邻" → 找到几段最相关的文档 → 给大模型作为上下文 → 大模型生成答案

理解了本章的向量 + 余弦相似度，第8章 RAG 几乎是水到渠成。

【思考 2】 一位开发者这样设计智能客服：把用户每条输入转成向量，跟标准 FAQ 库的每个问题向量做余弦相似度，挑相似度最高的标准问题对应的答案回给用户。请结合本章关于语义相似度和人工复核的讨论，说明这个设计在什么场景会出现严重问题，并提出修改建议。

思考提示：当用户表达投诉、退款或强烈不满时，向量相似度高并不代表系统可以直接套用常规 FAQ 答案。可以通过设置自动回复阈值、加入情绪和风险识别、对复杂诉求强制转人工等方式，把“AI 给出信号、人工作出判断”的原则落实到具体工程流程中。

AI 协同实践：观察字面相似与语义相似的差别

实践目标：用一段对比脚本，让你用数字看见字面匹配和语义匹配在同一问题上的不同表现。

预计时间：30 分钟。

实验场景：美食小助手

设想你做一个美食小助手。用户问：我想吃西红柿鸡蛋烩饭。

菜谱库有三道菜： 1. 番茄炒蛋盖浇饭 2. 西红柿紫菜蛋花汤 3. 清蒸排骨

直觉答案：第 1 道菜最匹配——番茄=西红柿、鸡蛋=蛋、烩饭=盖浇饭。

但机器怎么判断？我们对比两种方法。

让 AI 帮你写对比脚本

打开 VS Code，新建 compare_similarity.py。按 Ctrl/Cmd+L 唤起 Continue，发送：

请生成一个 Python 脚本 compare_similarity.py，做“关键词匹配 vs 语义向量”对比实验：

【输入数据(直接写在脚本里)】
- 用户提问 query: "西红柿鸡蛋烩饭"
- 候选菜品列表 candidates:
  ["番茄炒蛋盖浇饭", "西红柿紫菜蛋花汤", "清蒸排骨"]

【方法 A: 关键词匹配】
- 用 Python 标准库实现一个最简单的字面对比
- 对每个候选菜品,统计它和 query 有几个共同的"字"
- 共同字数越多,认为字面越像

【方法 B: 语义向量匹配】
- 调用本地 Ollama 的 embedding 模型获取文本向量，优先使用新版 `POST /api/embed` 接口
- 用 numpy 计算 query 向量和每个候选向量的余弦相似度
- 余弦相似度越高,认为语义越像

【输出】
- 对每个候选,同时打印"字面共同字数" 和 "语义相似度"
- 用清晰的分隔线和标号

【环境】
- Ollama API 地址默认 `http://localhost:11434`
- 用 `requests` 库调用 `/api/embed` 接口；如果课程环境使用旧版 `/api/embeddings`，请在注释中说明
- 如果 Ollama 不可用，给出清晰的报错提示
- 只用 requests, numpy 两个依赖(标准库除外)

审查 AI 生成的代码

AI 会给你大约 30~50 行代码。先审查再运行。重点看：

相关内容见表5-2。

表5-2 代码审查要点记录表

主动追问：选中余弦相似度那一行，按 Ctrl/Cmd+L 问 AI：

这个余弦相似度公式 np.dot(a,b) / (np.linalg.norm(a) * np.linalg.norm(b)) 是什么意思?为什么用余弦而不用欧氏距离?

这种主动追问是 AI 协同编程的关键素养之一——把能跑提升到我能解释。

准备 embedding 模型（首次需要）

如果还没下载向量模型，可按课程环境要求运行，例如：

ollama pull nomic-embed-text

模型大小和下载时间会随版本、网络和课程环境变化，以实际提示为准。

运行对比实验

pip install requests numpy
python compare_similarity.py

理想输出（数字会因模型版本略有差异）：

================================================
用户提问: 西红柿鸡蛋烩饭
================================================

候选 1: 番茄炒蛋盖浇饭
  字面共同字数: 2  （“蛋”“饭”两个字共同）
  语义相似度:  0.85  高度相关（示例值）

候选 2: 西红柿紫菜蛋花汤
  字面共同字数: 4  （“西”“红”“柿”“蛋”四个字共同）
  语义相似度:  0.62

候选 3: 清蒸排骨
  字面共同字数: 0
  语义相似度:  0.31

================================================
结论: 字面方法会优先推荐"西红柿紫菜蛋花汤"(汤,非烩饭)
     语义方法把"番茄炒蛋盖浇饭"排为最佳匹配
================================================

保存完整运行截图或输出记录——这是这一章最有说服力的证据。

关键观察分析

观察 1：字面方法在这个例子上明显偏离用户意图

• 字面共同字最多的是西红柿紫菜蛋花汤——但它是汤，不是用户想要的烩饭！
• 字面方法看不见番茄=西红柿、鸡蛋=蛋、烩饭=盖浇饭这些同义对应。

观察 2：语义方法的优势

• 番茄炒蛋盖浇饭字面共同字数不占优势，但语义相似度更高——模型判断它和用户请求在语义空间中更接近。
• 清蒸排骨字面共同字数为 0，语义相似度较低——和直觉吻合。

观察 3：语义相似度的数字范围

• 0.85 = 在本章实验中可视为高度相关信号，是否推荐还要看任务风险
• 0.62 = 有一定相关，但不一定适合自动采用
• 0.31 = 相关性较低

这些数字只是练习观察示例。不同业务场景的阈值不同，需要结合样本测试和风险后果校准。

拓展实验：自定义对比

在脚本里加一个交互输入，让你能自己输入两段文本，看 AI 给出的余弦相似度。自己设计 3 组对照实验：

实验组 A：同义异构（字面差很多，意思一样）

相关内容见表5-3。

表5-3 句子 A 与句子 B 记录表

实验组 B：同字异义（字面像，意思不像）

相关内容见表5-4。

表5-4 同义异构对照记录表

实验组 C：完全无关

相关内容见表5-5。

表5-5 同字异义对照记录表

完整运行并填表——这些数据是你这一章最有价值的产出。

故障排查：常见问题

如果实验跑不通，按以下顺序排查：

相关内容见表5-6。

表5-6 报错与原因记录表

把你遇到的真实报错和修复完整记到实验日志。

验证与证据：用《对比实验报告》

主对照表（美食问答助手场景）

相关内容见表5-7。

表5-7 美食问答主对照记录表

关键分析：两种方法的排名一致还是不同？哪种更符合用户的真实意图？

同义异构对照（实验组 A）

至少 3 组——填完整。

同字异义对照（实验组 B）

至少 3 组——填完整。

完整脚本与依赖版本

相关内容见表5-8。

表5-8 项与值记录表

原理小结（200~300 字）

围绕以下三点写一段：

1. 字面方法和语义方法在你的实验里，最大的差异体现在哪几组对照上？ 把数字摆出来说话。
2. 如果用余弦相似度做客服 FAQ 匹配，你会怎样设置阈值？较低阈值和较高阈值分别会带来什么不同体验？
3. 本章实验对后续学习提示词工程和第8章学习 RAG 有什么具体启发？

伦理、安全与边界

第一条底线：语义相似不等于答案正确

AI 算出语义相似度 0.92——只说明两段话在数学表示上接近，不说明机器真正理解了用户诉求，更不说明可以直接用这条回复回应用户。

具体场景：

• 用户说：你们这个软件的退款功能隐藏得也太深了！ → 与 FAQ 如何升级到深度模式 语义相似度 0.78 → 自动回了升级建议 → 用户更怒。
• 用户说：我手术后伤口还有点痛。 → 与伤口护理常识语义相似度 0.85 → 自动回了标准护理建议 → 但用户可能需要立即就医。

底线判断：

语义相似度只是检索的入口，不是判断的终点。

涉及医疗、法律、财务、投诉等高风险场景，必须有人工复核。学习阶段就要养成这条工程纪律。

第二条底线：阈值与场景必须匹配

前面的对比实验中出现了若干相似度数字。这些数字不能直接迁移到真实业务，不同业务下的判定线完全不同，示例可按下表理解：

相关内容见表5-9。

表5-9 业务场景与推荐阈值记录表

底线判断：

阈值越高，答错的风险越低，但没答上的风险越高——这个权衡要按业务定。

学习阶段建议在任何实验中都明确标注设定的阈值及其理由。

第三条底线：涉及用户权益的环节必须设人工复核点

回顾 5.1.3 节客户投诉的例子——AI 把投诉识别成咨询新功能，回了推销内容，结果客户更怒。

这件事的根本问题不只是 AI 算错了；AI 给出的功能 + 深的语义关联在数学上可能成立，真正的问题是流程上缺了人工复核。

工程化结论：

任何 AI 自动回复的下游会直接接触到用户、客户、学习者或患者的场景，都应当至少在以下三处设人工复核点：

1. 负面情绪检测命中时：用户语气含怨气、愤怒、伤心——立即转人工，不管语义匹配多高。
2. 涉及金钱/权益时：退款、赔偿、维权诉求——必须人工确认。
3. 低于阈值时：相似度低于阈值——别硬答，转人工。

这一条会在第11章智能体和第12章专业落地被进一步展开。但这一章你已经看到了它的雏形——AI 给信号，人做决定。

第四条底线：embedding 数据也是隐私

如果你用云端 embedding 服务，请注意：

• 你发送的每段文字，都被云端服务商接收并处理。
• 若发送内容包含真实姓名、学号、手机号、敏感内容——这些数据会上传到服务商。

底线：用云端 embedding 服务之前，先脱敏；学习/原型阶段优先用本地 Ollama 模型（数据不离开本机）。这是数据脱敏方法在 NLP 场景下的具体落地。

【思考 3】 有人设计了一个 AI 情绪关怀助手：读取学习群里所有留言，如果语义检测到情绪低落内容（与“我心情不好”的标准句相似度 > 0.6），就自动私聊相关成员发关怀消息。他用的是云端 embedding 服务。

请回答:① 这个设计至少有四条底线问题,分别是什么?② 如果让你来改,你会怎么改?

思考提示：可以从阈值过低、缺少人工复核、群聊数据上传云端、未取得知情同意和情绪识别误判等角度分析。更稳妥的做法是提高阈值、不自动私聊、优先本地处理、限制数据范围，并把提醒交给有责任边界的人复核。

总结与思考

本章核心判断

• NLP 三代演进：规则系统 → 统计学习（TF-IDF）→ 深度学习（embedding）。每一代都回应了前一代的关键局限。
• 字面相似 ≠ 语义相似——字面对对碰会漏掉所有同义异构。
• 现代语义匹配的核心机制：把文字转成向量，用余弦相似度算语义距离。
• AI 的“懂”是数学上的接近，不等于人的理解——这条认识贯穿后续章节。
• 语义相似度是检索的入口，不是判断的终点——涉及用户权益的场景必须人工复核。
• embedding 数据也是隐私——云端服务前先脱敏，学习阶段优先用本地模型。

基础题（理解层面）

1. 用自己的话描述 NLP 的三代演进，并说明每一代相对前一代解决了什么、留下了什么。
2. 为什么余弦相似度比简单的共同字数更适合做语义匹配？请用本章对比实验的数据回答。
3. RNN 的长距离依赖衰减问题是什么？为什么 Transformer 能解决它？（提示：第7章会展开）

迁移题（专业场景）

1. 你想为你们专业做一个专业问答助手——让使用者输入问题，从一个 500 篇的专业资料库里找最相关的文档片段。请回答：
   • 你会用 TF-IDF 还是 embedding 做检索？为什么？
   • 你会把阈值设在多少？为什么？
   • 涉及哪些内容时必须人工复核？
2. 你的专业问答助手上线后发现：很多学习者反馈答非所问。请从以下几个方向各给一个可能原因：① 检索方法本身、② 阈值设置、③ 知识库质量、④ 用户问法。

风险题（伦理与边界）

1. 某教育公司想做一个 AI 自动判作文系统：用 embedding 计算学习者作文和标准范文的语义相似度，相似度高的给高分。请回答：① 这套设计的伦理问题是什么？② 技术问题是什么？③ 你会建议他们怎么改？
2. 有人用云端 embedding 服务做了一个自动整理群聊记录的小工具。他没意识到群消息会被上传。请回答：① 这件事有什么风险？② 你会建议他做哪些补救？

补充题（自测层面）

1. 余弦相似度的取值范围是什么？为什么实际应用中很少看到负值？
2. 同样一段文本，用不同的 embedding 模型（如 nomic-embed-text vs OpenAI text-embedding-3）算出来的向量维度可能不同。这对工程上的检索系统有什么影响？
3. 如果一个用户的查询和知识库里所有文档的最高相似度也只有 0.3，正确的工程处理应该是什么？

本章交付物

请按下面清单提交本章证据：

• 完整的《对比实验报告》（四张表都要填）。
• 完整的 compare_similarity.py 代码 + 提交到 git。
• 三组对照实验的截图（主对照 + 同义异构 + 同字异义，关键数字可见）。
• 一段 200~300 字的原理小结。
• 故障排查记录（如有）：你遇到的报错、定位过程、最终解决方案。
• 可复现性测试：另一位学习者按你的脚本和说明在另一台电脑上跑出相似的数字。
• 职业守则（不超过 30 字）：本章学完后你给自己定的以后用语义匹配技术必须遵守的规矩。

本章的关键收获是：AI 可以计算语义接近度，但语义接近不等于真正理解。后续使用 AI 时，应把任务、资料、边界和验收标准说清楚，并在重要场景中保留人工复核。