大模型原理 · 产品下面的模型

伪造聊天记录

OpenAI 最初的实验:把补全机器变成聊天机器人

本页解决的问题

先给结论

「伪造聊天记录」要解决的关键问题是什么?

OpenAI 最初的实验:把补全机器变成聊天机器人

判断标准

让这个结论先证明自己值得留下。 把这一页当成决策工具,而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果,以及一个能改变你判断的失败上。

下一步

写下一个问题:试完这个方法后,你能用什么证据回答它?

常见误区

结论听起来很完整,却没有检查最关键的假设。


第一步
拼出一段「假的聊天记录」:
用户发了什么,然后助理那一栏故意留空
用户:紫霞仙子是谁?
助理:
↓ 模型从「助理:」后面开始补全
助理补出来:
第二步
把整段文字喂给 Base 模型,
它只会做一件事:从结尾处开始补全

第三步
用户再说一句话,就把「上一轮回答 + 新问题」
重新拼成更长的待补全文本,继续送给模型
第二轮:用户再说一句,把第一轮答案拼进去继续送
用户:紫霞仙子是谁?
助理:
用户:她爱的人是谁?
助理:
助理补出来:
诶,你别说,大模型补得有模有样!!!
等一下——它是「推」出来的吗?

再看一眼第二轮的原文:上一句只说了「至尊宝最深爱的人是紫霞仙子」, 压根没说紫霞爱谁。严格按字面推,「她爱的人是谁」这一问答不出来。

模型敢这么补,是因为它在训练语料里见过这个故事无数遍。这不是推理,是 把最常一起出现的话接下去。补得像和想明白了是两回事—— 顺着这条缝往下走,就是后面「幻觉」那一节。

「第一轮:模型看到什么?补了什么」为什么必须核验

「再看一眼第二轮的原文:上一句只说了「至尊宝最深爱的人是紫霞仙子」, 压根没说紫霞爱谁 。严格按字面推,「她爱的人是谁」这一问答不出来」把 AI 和搜索引擎的分工说得很清楚:一个擅长组织语言和给出解释,一个能把你带到可追溯的来源。

流畅度不能替代出处

「模型敢这么补,是因为它在训练语料里见过这个故事无数遍。这不是推理,是 把最常一起出现的话接下去 。补得像和想明白了是两回事—— 顺着这条缝往下走,就是后面「幻觉」那一节」至少带来三个后果:模型可能把相近事实混在一起,知识可能停在某个时间点,也可能无法说明答案来自哪条材料。因此涉及日期、数字、人物、法规或当前状态时,应把回答当作线索而不是证据。

问题越具体,核验越要具体

用「模型敢这么补,是因为它在训练语料里见过这个故事无数遍。这不是推理,是 把最常一起出现的话接下去 。补得像和想明白了是两回事—— 顺着这条缝往下走,就是后面「幻觉」那一节」做一次检查:要求列出来源或可复算过程,再逐项核对关键主张;如果找不到出处,就明确标记为待确认,而不是用更肯定的语气补上。

从这个例子继续往下看

这篇内容先从「再看一眼第二轮的原文:上一句只说了「至尊宝最深爱的人是紫霞仙子」, 压根没说紫霞爱谁 。严格按字面推,「她爱的人是谁」这一问答不出来」展开,再把问题推进到「模型敢这么补,是因为它在训练语料里见过这个故事无数遍。这不是推理,是 把最常一起出现的话接下去 。补得像和想明白了是两回事—— 顺着这条缝往下走,就是后面「幻觉」那一节」。把这两个片段放在一起看,可以更清楚地分辨:哪些是文章给出的事实,哪些是需要结合条件才能成立的判断。

把这条判断带到下一个场景

涉及事实时,先把回答拆成可验证的主张,再按日期、数字、出处和适用范围逐项核对;不能核对的部分就保留不确定性。

  • 「第一轮:模型看到什么?补了什么」:再看一眼第二轮的原文:上一句只说了「至尊宝最深爱的人是紫霞仙子」, 压根没说紫霞爱谁 。严格按字面推,「她爱的人是谁」这一问答不出来
  • 「继续往下看」:模型敢这么补,是因为它在训练语料里见过这个故事无数遍。这不是推理,是 把最常一起出现的话接下去 。补得像和想明白了是两回事—— 顺着这条缝往下走,就是后面「幻觉」那一节

最后的「最后把结论落到实践」把讨论落到「模型敢这么补,是因为它在训练语料里见过这个故事无数遍。这不是推理,是 把最常一起出现的话接下去 。补得像和想明白了是两回事—— 顺着这条缝往下走,就是后面「幻觉」那一节」。回看这条线索时,最值得保留的是:当输入、规模或风险改变,哪些判断需要重新做一遍。

标记为已学完 阅读进度会自动记录
← 上一篇下一篇 →

继续阅读

同一条线上的下一篇。

文章讨论

读到这里,留下一个判断。

把刚想明白的地方、还没想通的问题,留给下一位一起学习的人。

正在讨论 伪造聊天记录 产品下面的模型
3条讨论文章讨论 · 与共学社区同步
在共学社区查看
AM
Asha Morgan内容编辑
观点实践记录

我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是,知道下一步要观察什么。

文章讨论7 有帮助
LH
Lin Harper独立开发者
观点观点

读完以后我先回头找它成立的条件,而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。

文章讨论5 有帮助
KM
Kiki Moore产品运营
问题问题

如果把这个判断放到真实工作里,最先需要补的约束是什么?我想知道从阅读到第一次实践之间,哪一步最值得先做。

文章讨论4 有帮助