3.3 识别结果解读：时间戳、分段与置信度

转写结果第一次打印出来的时候，同事盯着一屏幕结构化字段问：“就取那个文本字段不就行了？”一开始我也是这么干的，直到做纪要提取时发现：没有时间戳，纪要里的“决议出自第几分钟”写不出来；没有置信度，哪些段落需要人工复核完全没方向。这一节讲结果里最关键的几类字段，以及我们怎么把它们用到纪要流程里。

结果字段说明

不是每个字段都会用上，我们的纪要流程主要用前四个，词级别结果只在 3.4 节调热词时才拉出来看。字段名字各家产品叫法可能不同，拿到结果先对着文档把字段映射列一张表，比靠猜调代码快得多。

当时我们第一个版本漏了置信度字段，因为文档示例里它藏在好几层嵌套里，parse 的时候被跳过了。直到做人工校对阶段才发现：所有句子都按无差别置信度处理，校对同事只能从头读到尾。补上字段的解析花了半小时，但省下的是此后每一份纪要的校对时间。这个教训我记进了项目笔记：对接任何新接口，先把返回结构完整打印一遍看全字段，再决定哪些用哪些不用，而不是只挑示例里出现的。

时间戳的三种用法

时间戳是我在整个项目里最低估的东西。起初以为它只是个技术参数，结果在纪要工具里被用出了三种花样：

第一种是跳回原音频核对。纪要里每条决议后面我都挂一个原音链接，点击直接跳到对应的音频时间点。这个功能是财务同事提出来的——有笔预算数字纪要里有两种说法，她点链接听了 20 秒原始录音，争议当场解决。实现很简单，把句子级时间戳拼进内部音频播放器的参数即可。

第二种是纪要定位。长会议的逐字稿没人看，但“议题大概在哪个时间点讨论的”大家都有概念。我们的纪要按议题分段，每段标注音频时间范围，想看细节的人直接跳过去听原文，比给他一份 8000 字逐字稿友好十倍。

第三种是剪辑。培训分享会的录音，同事想剪个 3 分钟精编版发群里，靠着句子级时间戳，我在逐字稿上勾几句话就自动生成了剪辑脚本。这个不在工具主流程里，是顺手做的，却成了最被夸的功能之一。

用时间戳有个精度问题要留心：句子级时间戳多多少少有几秒的偏差，跳转时我会把开始时间往前回退 3 秒，免得漏掉开头半个字。回退 3 秒这个数字是我们试出来的，正好能听全整句又不显得拖沓。另外不同场次的录音偏差还不太一样，会议室固定麦克的偏差稳定在 1 到 2 秒，移动设备随手录的能到 4 到 5 秒，所以我们把回退量做成了可配置项，存在录音元数据里，新场地第一次用先校准一次。音频和转写文本的存储规划在 2.1 节，文本归档之后怎么跟笔记体系串联，可以看 笔记知识库实战。

分段结果：谁在说话

发言人标记（说话人分离结果）是我们纠结最久的字段。理想情况是识别直接告诉你每句话是谁说的，现实是它只告诉你“这像是同一个人”和“换人了”，至于这个人是谁，得自己匹配。

我们这么做：拿识别给出的分段标签做基础，会议开始时在前端登记参会人名单，转写完成后把分段标签和名单按发言顺序对一遍。对不上的段（比如有人中途插话）标成待确认，人工校对时认领。第一次用的时候我没做名单登记，结果一小时的录音里分出了十几个不存在的发言人——会议上谁转头跟旁边人说一句都会被算成一次新发言人。后来把过短的段落（比如 3 秒以内）直接并入相邻段，发言人数立刻收敛到正常水平。

发言人归集是纪要里最增值的部分之一：把同一发言人的发言按时间拼起来，谁提了什么建议、谁认了什么待办一清二楚，开会时谁划水也一目了然（这点老板非常喜欢）。具体的归集做法和模板在 4.2 节。

时间戳在纪要里长什么样

抽象说完给个具体例子，我们纪要正文里时间戳的呈现方式：

时间戳对纪要的价值不是技术性的，是信任性的：看到每条结论都能点回原音，大家对 AI 生成的纪要接受度高了很多。最早没挂链接时，总有人私下来问这句话到底谁说的；挂上链接之后，这类追问基本消失。

置信度使用策略

置信度（一个 0 到 1 的小数）刚上线时我没怎么管，直到有一次纪要把同事名字识别成了另外一个写法的词，场面一度非常尴尬。痛定思痛，我按区间把处理方式分了三档：

阈值是我们拿 20 份录音试出来的，不是抄来的标准答案：一开始阈值卡在 0.75，结果标黄的段落多到校对根本看不完，调了几轮才降到 0.6。经验是按句子过滤已经能挡住大部分离谱错识，词级别置信度更敏感但噪声也大，全信它反而会过度标黄。

低置信度集中在哪些词

观察了一个月的低置信度样本后，我发现错识基本集中在三类词上，这个发现直接推动了 3.4 节的热词表工作：

前两类是加词能救的，第三类属于录音质量和口语本身的问题，加词没用，只能在后处理清理（4.1 节）。这也是为什么我后来养成一个习惯：每出一版纪要，顺手把低置信度的句子扫一遍，把反复错的词记进错词本，而不是等用户投诉了再补。

转写结果到这一步还只是逐字稿，要变成能执行的纪要，还得做信息提取，大模型那部分可以参考 DeepSeek 工具链和 AI 智能体开发实战。

结果怎么交给大模型

转写结果最终要喂给大模型做纪要提取，怎么喂也有讲究。我们最早的做法是把全文一股脑塞过去，结果模型会把低置信度的胡话也当真，纪要里冒出根本没讨论过的事项。后来改成分层投喂：

效果最明显的是最后一条：给模型标出哪些句子可信度低之后，它主动把不确定的内容降级成了“待确认”条目，而不是编进决议里。这一步的模型选型和提示词细节，可以看 DeepSeek 工具链。信息提取的完整流程在 4.2 节。

字段使用上踩的坑

标黄在纪要草稿里长什么样

说一嘴产品细节，因为这块直接决定校对同事的体验。我们的纪要草稿里，0.6 到 0.8 的句子带浅黄底色，鼠标悬上去显示置信度数值；0.6 以下的句子不进草稿正文，而是收进文末的建议复听清单，每条带原音链接和对应时间点。校对同事的反馈是：底色比红色醒目但不刺眼，清单比散落在正文里好处理——低置信度的内容一次性集中看完，比边读边跳效率高很多。一个验收标准：校对一位同事看完一份纪要所需的时间，从最初的四十分钟降到了十来分钟，其中一半功劳要记在置信度分档上。当然分档也不是一劳永逸，阈值每隔一个季度我们会拿新录音回测一次，会议话题和词汇在变，阈值跟着漂移一点很正常。

延伸阅读

• DeepSeek 工具链：把带时间戳的逐字稿交给大模型做结构化提炼。
• AI 智能体开发实战：纪要提取智能体化的下一步。
• 腾讯云实战手记：识别结果在云函数之间传递与存储的细节。