有监督学习技术
第四课｜文本分类中的有监督学习算法与提示词工程
这一讲只做两件事：
先用公开评论数据讲清常见的有监督学习算法，
再看怎样把大模型的分类任务写成一个可执行的 prompt。
《机器学习与自然语言处理》
AI + 计算社会科学微专业
文本分类任务设定
为了把算法讲清楚，这一讲先固定成一个最简单的文本分类任务。
DATA
公开中文评论
酒店、电商、外卖评论都可以。
数据公开，课后也能复现。
TASK
负面 / 非负面二分类
输入一条评论，输出一个标签：
`negative` 或 `non_negative`。
GOAL
比较常见算法
朴素贝叶斯、逻辑回归、决策树，
看它们各自怎么做同一个任务。
Output
分类标签
negative / non_negative
常见算法的基本直观比较
同一个分类任务，不同算法的“想法”并不一样。
ALGO 1
朴素贝叶斯：像数词
看哪些词更常出现在负面评论里，
哪些词更常出现在非负面评论里。
ALGO 2
逻辑回归：像打分卡
每个线索加一点分、减一点分，
最后合成一个总分。
ALGO 3
决策树：像连续提问
一步步问：有没有退款、有没有失联、
有没有强烈抱怨。
Naive Bayes
退款
+
异味
→
负面概率上升
干净
+
热情
→
非负面概率上升
核心直觉：先看词，再比较两边证据。
Logistic Regression
退款 +3
+
异味 +2
没人回 +2
→
总分 7
核心直觉：把多个线索加权后合成一个分数。
Decision Tree
有退款？
→
有失联？
是 / 是
→
负面
核心直觉：按条件一路分下去，像走流程图。
记忆时可以抓三个动作：看词频、做加权、走流程。
算法一：朴素贝叶斯的词频判别机制
它先把一句话拆成词，再看这些词更像常出现在负面，还是常出现在非负面。
“图片和实际不符，不会再来。”
判别结果
negative
如果这句话里出现的词，整体更像常见于差评，
模型就会把它往负面一侧推。
朴素贝叶斯不会先理解整句语义，它先看词：`不符`、`不会再来`、`差` 之类的词，在负面评论里是否更常见。
朴素贝叶斯的适用条件与局限性
它快、轻、好上手，但它也会忽略很多上下文信息。
优势
快：训练和预测都很轻，适合先跑第一版。
稳：当关键词信号很强时，表现常常不差。
省：对小样本和稀疏文本也比较友好。
vs
局限性
不看顺序：词和词之间的组合关系抓得比较弱。
假设很强：默认各个词的贡献彼此独立。
怕语境：“不差”“还行”这类细微表达不一定处理得好。
算法二：逻辑回归的加权判别机制
它不只是看词出现没有，而是把多种线索加权后合成一个分数。
分数越往右，越像 negative。
逻辑回归的直觉不是“哪个词最多”，而是“这些线索加起来有多危险”。
逻辑回归的直觉不是“哪个词最常见”，而是“哪些线索一起出现后，总体会把评论推向负面”。
逻辑回归作为基线模型的原因
做文本分类时，逻辑回归经常是一个很好的起点。
WHY 1
好解释
每个线索的方向和权重都比较直观，
容易向别人解释模型在看什么。
WHY 2
好扩展
既能吃词袋特征，
也能接更多结构化特征或 embedding。
WHY 3
好比较
很适合拿来做课程里的 baseline，
再和其他算法比较错误类型。
算法三：决策树的递归划分机制
它更像一个判断流程：每走一步，就把评论分到更细的一类。
有没有退款词？
有 / 没有
有没有客服失联？
有 / 没有
如果两者都有
很可能是负面
如果只有轻微抱怨
可能是非负面
决策树最擅长的，
是把“如果 A 又 B，就更像负面”这种组合条件直接写进判断过程。
决策树的优势与风险
它直观、像流程图，但也最容易把局部规律学得太死。
优势
直观：很像人工在脑中走的判断流程。
会抓交互：“退款 + 失联”这类组合条件表达得很自然。
好展示：课堂上容易把判断路径讲给学生看。
vs
风险
容易过拟合：树开得太深，就会把训练样本记得太细。
不够稳定：样本稍有变化，树结构可能就改很多。
要剪枝：否则很容易看起来很懂，实际泛化很差。
算法的综合比较
它们都能做文本分类，但各自擅长的地方并不一样。
解释性更强
对复杂关系的表达更强
朴素贝叶斯
快，轻，适合看强词信号。
逻辑回归
平衡，稳妥，适合做基线模型。
决策树
规则直观，但最容易过拟合。
| 算法 |
直觉 |
更适合 |
短板 |
| 朴素贝叶斯 |
看词证据 |
关键词很强、先跑快速基线时 |
不看词序，上下文能力弱 |
| 逻辑回归 |
做加权打分 |
文本分类 baseline、需要解释时 |
复杂交互要靠额外特征 |
| 决策树 |
走判断流程 |
规则型任务、组合条件很多时 |
容易过拟合，结构不稳定 |
课程作业的建议实施流程
先把这几类算法都跑起来，再去看它们各自错在哪一类评论上。
准备训练数据
评论 + 标签
分别跑各类算法
NB / LR / Tree
比较错误样本
谁更容易误判
再做优化
调特征或换 prompt
课堂问题：
如果几类算法都在“轻微抱怨但整体还能接受”这类评论上出错，问题更可能出在算法，还是标签定义？
本部分小结
这些算法都能做文本分类，但它们处理“线索”的方式并不一样。
NB
看词证据
适合关键词很强的任务，跑得快，适合先做基线。
LR
做加权打分
是课程里最稳妥的第一版 baseline，也最容易解释。
TREE
走判断流程
适合讲“如果 A 又 B”这类组合规则，但更容易过拟合。
Part 2提示词工程（Prompt Engineering）
一个基本原理：先定标准，再写 Prompt
在这个评论二分类任务里，prompt engineering 不是“想一句更厉害的话”，而是先把 negative / non_negative 的判别标准固定下来，再把它稳定地写进输入。
PRINCIPLE 1
先固定标签含义
先想清楚什么叫 negative，什么叫 non_negative，不要一边写 prompt 一边改标准。
PRINCIPLE 2
再补边界规则
像“早餐普通但还能接受”这种边界评论，要提前写清楚，否则模型很容易漂。
PRINCIPLE 3
最后组织输入结构
示例、规则、当前评论怎么排，决定了模型能不能稳定复现同一套分类口径。
少样本学习（Few-shot Learning）
继续用前面的评论二分类任务为例：few-shot 的作用，就是先拿几条已经标好 negative / non_negative 的评论，把分类口径喂给模型。
WHAT
先给示例
先放 2 到 5 条已经标好标签的酒店评论，让模型看到这次到底在分什么。
WHY
再校边界
真正该放进去的，不是最明显的差评，而是“有点抱怨但还能接受”这类最容易分歧的评论。
GOAL
最后再做泛化
目标不是让模型背这几条评论，而是让它学会这门课前半部分一直在用的分类标准。
输入 Prompt 的六段骨架
还用同一个酒店评论分类任务。更稳的写法，不是只写一句“请分类”，而是把这个输入 prompt 拆成几个固定段落。
2
任务
例如：把每条评论判成 negative 或 non_negative。
3
标签定义
明确什么算负面，什么算轻微抱怨但总体可接受。
4
边界规则
把“早餐普通但还能接受”“补送后是否仍算负面”这种边界写清楚。
5
示例
优先放最容易误判的评论示例，而不是最典型的差评。
6
当前输入
把本次待判别的那条评论单独放在最后，避免和示例混在一起。
零样本 Prompt 示例
先不给示例，只拿前面那套评论分类规则直接去判一条新评论，这就是 zero-shot。
你是中文评论分类助手。
任务：把评论标成 `negative`
或 `non_negative`。
规则：
1. 退款、异味、失联，判 `negative`。
2. 轻微不满但总体接受，判 `non_negative`。
3. 输出 JSON：
{"label": "...", "reason": "..."}
评论：
“位置方便，但早餐普通，整体还能接受。”
{
"label": "non_negative",
"reason": "有轻微抱怨，但总体仍可接受"
}
Few-shot 示例的边界校准作用
对这个评论二分类任务来说，few-shot 最有价值的地方，就是先把最容易摇摆的评论边界钉住。
| 边界评论 |
标签 |
为什么值得放进 prompt |
| 位置方便，但早餐普通，整体还能接受。 |
non_negative |
提醒模型：轻微抱怨不自动等于负面。 |
| 外卖送到时已经凉了，不过客服马上补送了。 |
negative |
提醒模型：即使有补救，也可能仍然是负面体验。 |
| 隔音一般，这个价位也就这样吧。 |
non_negative |
提醒模型：模糊表达最容易误判，需要提前定规则。 |
Prompt 设计中的歧义表达问题
还是以前面的评论分类为例。如果标签标准写得模糊，模型每次判 negative 的边界都可能变。
歧义表达
例子：“帮我判断哪些评论比较差。”
问题：“比较差”到底等不等于 negative？轻微抱怨算不算？
结果：同一条“早餐普通，整体还行”的评论，模型可能一会儿判负面，一会儿不判。
vs
可执行表达
例子：“明确抱怨退款、异味、客服失联，标成 negative。”
补充：“轻微不满但总体接受，标成 non_negative。”
结果：这样写之后，前面那批评论的判别标准才能前后一致。
一个实用 Trick：先写排除规则
做评论二分类时，很多误判不是因为模型不知道什么叫 negative，而是因为你没有写清楚什么情况不算 negative。
WITHOUT TRICK
只写正向规则
“退款、异味、客服失联，判为 negative。”
问题是：模型容易把“早餐普通”“隔音一般”这类轻微抱怨也往负面里塞。
WITH TRICK
补一条排除规则
“轻微不满但总体接受，不算 negative。”
这一句会直接帮模型守住边界，特别适合处理“还行”“一般”“能接受”这类模糊评论。
可直接复用的写法：
除非评论出现明确且实质性的负面体验，否则不要判为 negative；
轻微抱怨但总体接受，统一判为 non_negative。
长上下文输入的组织原则
如果你要一次性把“标签定义 + 边界规则 + 几条评论示例 + 当前待分类评论”都放进去，就必须把顺序排清楚。
前面放静态内容
角色、任务、标签定义
中间放规则与示例
边界规则、few-shot 评论
最后放当前输入
本次待分类的评论文本
写法上也要分区：
对这个评论分类任务，可以用 Markdown 标题、编号步骤，或 XML 标签把
<instructions>、<examples>、<input>
分开，这样模型更不容易把“示例评论”和“本次待判别评论”混在一起。
复杂任务的 Prompt Chaining
如果这门课里的评论分类任务还要求你同时抽取抱怨点、给标签、写理由，那就不要一条 prompt 全做完。
STEP 1
先抽取关键信号
先从评论里抽出退款、异味、失联、态度差等线索，不急着判 negative。
STEP 2
再做标签判断
再根据这些线索，判断这条评论是 negative 还是 non_negative。
STEP 3
最后生成简短理由
最后只补一句简短理由，例如“存在退款投诉且客服失联，因此判为 negative”。
对前面这个评论分类任务来说，这种“抽取线索 → 判断标签 → 输出理由”的链式提示，往往比一条 prompt 包打天下更稳定。
主流模型的输入提示偏好差异
即使都是在做前面那个评论二分类任务，不同平台对这条输入 prompt 的组织方式也有不同偏好。
OPENAI
清楚分角色，提示要直接
例如把“你是中文酒店评论分类助手”放在上层角色里，再把标签定义、few-shot 评论和当前评论放进输入；写得直接，通常比堆很多修辞更稳。
ANTHROPIC
强调 XML 标签和多样示例
把这个分类 prompt 分成 <instructions>、<examples>、<input> 三段，会更清楚；few-shot 评论最好兼顾典型样本和边界样本。
GEMINI
强调分区和格式示范
对这类评论分类任务，先示范目标输出格式也很重要，例如先示范一条 {"label":"negative","reason":"..."}，再喂当前评论。
本讲总结
前半段讲模型怎么做同一个评论分类任务，后半段讲怎么把这个任务稳定地写进输入 prompt。
PART 1
有监督学习算法
朴素贝叶斯看词证据，逻辑回归做加权打分，决策树走判断流程。
PART 2
Prompt Engineering
围绕同一个 negative / non_negative 评论分类任务，输入 prompt 要有骨架、有顺序，也要把边界样本写进去。
一句话总结：
前半段是在学“模型怎么给评论分类”，后半段是在学“怎么把同一套分类标准写成更稳定的输入 prompt”。