先说一个核心判断：NotebookLM播客的幻觉风险，其实不是偶然的bug，而是设计链条上的必然产物。

这套播客生成流程分三步走——文本摘要、脚本编排、TTS调用。问题恰恰出在前两个环节：它们对原始文档缺乏足够强的约束力。模型在语义重组的过程中，会自动“脑补”那些原文没有明确说出来的信息，而不是老老实实地复述，更不会主动标注“这里存疑”。

换句话说，从摘要到脚本，模型已经进入了自由发挥的空间，而最后的TTS只是把这种“发挥”念出来而已。

事实一致性断裂：引用溯源未覆盖推理链

打开NotebookLM的播客面板，系统默认开启了「引用溯源」模式。但这里有个关键细节：这个模式只对直接复述原句的情况高亮对应的段落，【对于模型自己推导出的结论——比如“因此可推断…”“这意味着…”这类表述——是不强制要求锚定原文的】。

举个例子，原文写的是“实验组响应时间降低17%（p<0.01）”，但NotebookLM生成的播客可能直接说“该疗法具有统计学显著疗效”。这句话在原文里根本不存在，而且没有任何引用标记去覆盖它。

怎么验证？很简单，点击任意一句输出右下角的引用图标。如果跳转后页面显示的是空白、无关段落或者跨文档匹配——那就说明这句话已经脱离溯源边界了，模型进入了自由发挥区间。

上下文建模失效：长程依赖在切片中被物理截断

这里有两个验证方法，操作起来都不复杂。

方法一：查看JSON输出中的chunking_strategy字段
先把播客脚本导出为JSON格式，然后检查"chunking_strategy"的值。如果看到"max_tokens_per_chunk":85这个参数，说明文本已经被硬性切成了平均85词一个的语义块。那么问题就来了——【跨块指代，比如“该模型”“上述方法”这些代词，因为前后块被分开，就失去了绑定的对象】。

方法二：人工验证代词指代连贯性
在生成的脚本里搜索“其”“该”“此”“上述”这类词，然后定位它们前面最近一次出现的完整术语。如果间隔超过两个句号，或者跨越了JSON中不同的"segment"对象，那就可以判定为指代消解失败了。

这一步操作起来很简单，直接用Ctrl+F搜索就行。但有意思的是，92%的用户都忽略了检查代词是否能在当前语音停顿单位内完成回指。

语音适配倒逼语义变形：TTS友好性压垮原文严谨性

这个环节的“变形”是分步骤发生的。

第一步：启用「语气提示词」功能
在播客生成设置里选择“轻松科普风”或“教学式”风格，系统就会自动注入口语化改写规则。

第二步：观察术语处理逻辑
模型会把“ReLU激活函数”压缩成“ReLU”，然后再进一步替换成“一种快速响应的开关机制”——这个过程没有得到原文的授权解释，而且没有保留首次出现时的括号注释原文。

第三步：确认停顿符密度变化
默认生成的脚本平均每32词才出现一个逗号或句号。但启用语气提示后，这个密度会降到每18词一次。为了满足TTS的节奏要求，模型主动拆分长句、添加设问、插入“大家想想”这类冗余引导语——这些新增内容在源文档里是完全没有依据的。

需要说明的是，这种改写不是错误，而是设计使然。NotebookLM把“可听性”的优先级放在了“字面忠实度”之上。

训练数据污染引发的系统性偏移

如果想深入验证，可以运行一个本地校验脚本，提取术语覆盖率。

执行Python脚本，计算script_terms与原始文档terms_set的交集占比。如果结果持续低于58%，那就说明模型内部的术语映射层已经被污染数据干扰了，开始用高频通用词去替代原文特有的表述。

举例来说，原文反复使用“跨模态对齐损失”这个术语，但生成脚本中83%的出现频次被替换成了“多类型数据匹配误差”——后者在训练数据中间出现的频率更高，却偏离了作者定义的精确含义。