通话中实时标记的状态机设计：离线会议转录的时序同步与交互管理

在本地 Whisper 离线转录架构中，流式推理解决了实时性问题，但如何在转录过程中实现 ** 通话中实时标记（mid-call flagging）** 则是另一个独立的技术挑战。与纯推理优化不同，实时标记涉及音频时序同步、人机交互状态管理以及分段转录的上下文连续性，需要一套完整的状态机设计来支撑。

核心挑战：离线场景下的实时交互

离线会议转录与云端 ASR 服务的根本差异在于无网络延迟优势。当用户在会议进行中按下标记按钮时，系统必须立即响应，但此时的转录结果可能滞后数秒甚至数十秒 ——Whisper 的 chunk 处理、VAD（语音活动检测）判定、以及模型推理都存在固有延迟。这就要求标记系统具备时间戳回溯能力，将用户的交互意图映射到正确的音频位置。

另一个挑战是状态隔离。标记操作可能发生在转录的任何阶段：正在处理当前 chunk、等待 VAD 触发、或处于静音检测期。系统必须确保标记事件不会干扰正在进行的推理流程，同时保证标记数据与最终文本输出的精确对齐。

时序同步机制

实现精确时序同步的关键在于维护三条独立的时间线：

1. 音频采集时间线 以音频输入设备的采样时钟为基准，记录每一帧 PCM 数据的绝对时间戳。这是整个系统的 "真实时间" 源，不受处理延迟影响。建议以微秒级精度存储，避免长时间会议中的累积误差。

2. 转录处理时间线 跟踪每个音频 chunk 进入 ASR 引擎和返回结果的时间。由于 Whisper 的推理是异步的，需要建立 chunk_id 到时间戳范围的映射表。当标记事件发生时，根据当前处理进度估算已转录的音频边界。

3. 用户交互时间线 记录用户触发标记的 UI 事件时间。这个时间是 "wall-clock time"，需要通过与音频时间线的校准，转换为音频流中的相对位置。

同步的核心算法是双指针追踪：维护一个 "已采集音频指针" 和一个 "已转录文本指针"。当标记事件到达时，根据两个指针的差值计算回溯偏移量，确定标记应附加的文本位置。

音频分段与缓冲策略

为实现无缝标记，推荐采用滑动窗口缓冲架构：

[已确认文本区] | [处理中chunk] | [预缓冲音频]
                ↑
           标记插入点

• 已确认文本区：已完成推理并输出的文本，标记可直接附加
• 处理中 chunk：当前在 GPU/CPU 上推理的音频段，标记需排队等待结果返回
• 预缓冲音频：已采集但未送入 ASR 的原始音频，标记需暂存并在转录完成后回填

缓冲区大小的设定需要权衡延迟与精度。经验值是保持 3-5 秒的预缓冲，这既能覆盖 Whisper 的典型推理延迟，又不会引入过长的标记确认等待时间。

标记状态机设计

标记的生命周期可抽象为四状态机：

Pending（待处理） 用户触发标记后的初始状态。此时系统记录交互时间戳，但尚未确定对应的文本位置。标记进入等待队列，直到相关音频 chunk 完成转录。

Anchoring（锚定中） 当转录结果返回时，系统根据时间戳映射表计算标记的精确文本位置。如果标记落在 chunk 边界附近，需要处理边界模糊性：通过上下文相似度算法，决定标记归属前一段还是后一段。

Resolved（已解析） 标记成功绑定到具体文本位置，可持久化存储。此时 UI 可以高亮显示标记点，用户可添加备注或分类标签。

Expired（已过期） 异常情况处理。如果音频数据因质量问题被丢弃，或用户取消标记，标记进入过期状态并从队列移除。

状态转换由事件驱动：转录完成事件触发 Pending→Anchoring，位置计算完成触发 Anchoring→Resolved，超时或错误触发任意状态→Expired。

与 ASR 引擎的集成模式

集成 Whisper 等离线 ASR 时，推荐采用事件总线架构解耦标记系统与推理流程：

1. TranscriptionEvent：ASR 引擎发布转录结果，包含 chunk_id、时间戳范围、文本内容
2. FlagRequestEvent：UI 层发布标记请求，包含交互时间戳、标记类型、用户 ID
3. FlagResolvedEvent：标记系统发布解析完成的标记，包含最终文本位置、上下文片段

这种发布 - 订阅模式允许标记逻辑独立演进，无需修改 ASR 推理代码。同时支持多标记并发处理 —— 在一次长会议中，用户可能连续添加多个标记，系统通过队列保证处理顺序。

工程实现要点

防抖与节流 快速连续的标记触发需要防抖处理，避免生成重复标记。建议设置 300ms 的防抖窗口，同时限制每秒最大标记数（如 5 个 / 秒）防止滥用。

持久化策略 标记数据应实时写入本地存储（SQLite 或 JSON），而非等待会议结束批量写入。这防止应用崩溃导致标记丢失。可采用 WAL（Write-Ahead Logging）模式平衡写入性能与数据安全。

上下文回溯 标记确认后，应提供前后 30 秒的音频片段作为上下文，帮助用户回忆标记原因。这需要音频缓冲区的环形存储设计，保留最近 N 秒的原始 PCM 数据。

冲突解决 当多个用户（如远程会议中的多方）同时标记时，需要冲突解决策略。简单方案是时间戳优先，复杂场景可引入用户权重或标记类型优先级。

性能优化参数

基于实际部署经验，以下参数可供参考：

总结

Mid-call flagging 在离线转录场景中是一个典型的跨域问题：它横跨音频处理、ASR 推理、UI 交互三个技术栈，需要统一的时序抽象和状态管理。通过滑动窗口缓冲、双指针同步、以及事件驱动的状态机，可以在不侵入 ASR 核心逻辑的前提下，实现精确的实时标记功能。

这套架构不仅适用于会议转录，也可推广到播客编辑、访谈记录、法庭速录等需要 "边录边标" 的场景。核心设计思想是延迟隐藏—— 通过预缓冲和异步锚定，将 ASR 的固有延迟对用户透明化，同时保证标记数据的最终一致性。

参考来源

• Trace App (traceapp.info) - macOS 离线会议转录工具，提供 mid-call flagging 交互参考
• Hacker News 讨论 (news.ycombinator.com/item?id=9) - 社区对实时转录交互设计的反馈

ai-systems