Dictata 这个项目做的事情用一句话讲本机跑 Whisper 完成语音听写再用 LLM 对转写文本做清理和结构化。它最值得关注的点不是“转写准确率又提升了多少”而是把“语音识别出来的原始文本”变成“可以直接复制进文档、消息、博客草稿里的干净文本”。这种组合方向适合经常做会议记录、访谈整理、视频口播稿、语音输入和笔记归档的人重点看一眼。第一次接触 Whisper 的人往往会对转写结果产生一种错觉准确率看起来不错但文字没法直接用。没有标点、重复词、口语语气词、断句混乱、英文数字混排、上下文指代不清这些都是常见问题。Dictata 的思路很直接既然 Whisper 出的是“毛坯文本”那就用 LLM 再做一道清理工序。方向不难但真正落地时会涉及模型选型、资源占用、prompt 设计、批量任务和错误处理下面按我的实际验证顺序拆一遍。1. 先把问题拆清楚Whisper 负责转写LLM 负责清理1.1 Whisper 生成的是“语音内容”不是“可发布文本”Whisper 是语音识别模型输入音频输出文字。它的核心能力是把语音内容转成文本但这不代表文本是适合直接使用的。实际跑过一次就会明白输出里经常出现下面这些情况口语语气词没有过滤比如“嗯”“啊”“就是说”“然后然后”。标点符号不完整长句可能一整段只有一个句号。识别结果按语音停顿切分而不是按语义切分。重复表达多说话人现场改口、补词转写会原样保留。数字、英文术语、专业缩写经常混排大小写也不统一。这些问题对阅读影响很大。尤其当你把转写文本粘贴到博客草稿、项目文档或通知消息里时几乎需要从头重写一遍。Dictata 这类方案补的正是这一段先用 Whisper 拿到原始转写然后让 LLM 根据上下文重新整理文本结构去除口语杂质、恢复标点、修正明显的识别错误并按用户指定的风格输出。1.2 LLM 清理和简单规则替换的区别在哪里有人会问这类清理用正则表达式、标点恢复工具就能做一部分为什么还要上 LLM我的理解是规则只能处理固定模式LLM 能做语义级整理。比如一句话里说到“我们上周四开过会Tom 说这个那个接口周三之前要搞定”正则最多能把“这个那个”删掉但很难判断“接口”到底是指 API 接口、硬件接口还是部门对接人。LLM 能结合上下文做推断同时可以补标点、调整语序、把“搞定”补成更完整的表述也可以按“会议纪要风格”或“博客初稿风格”输出。所以清理的关键不在于“替换掉什么”而在于“按什么目标重新组织这段文本”。这个目标由 prompt 控制正是 LLM 组件最灵活的地方。1.3 本地运行和在线方案的核心差异Dictata 强调 Local也就是本地运行。这意味着音频文件不需要上传到第三方服务转写和清理都在自己电脑上完成。优势是明显的隐私性更好尤其涉及会议录音、客户访谈、未发布内容时。没有按分钟计费的问题离线也能跑。可以反复调试 prompt不用考虑服务端限流。网络依赖小适合笔记本、内网环境或离线办公场景。代价也很明显本地需要装模型、占磁盘和内存跑大模型或大音频时可能需要 GPULLM 清理这一步如果也用本地模型速度会比云端接口慢配置要求也更高。因此落地前要先把“本地”的边界想清楚是 Whisper 和 LLM 都本地还是只把转写放本地LLM 走一个可控接口。这个选择会影响硬件要求。2. 运行环境准备先确认你的机器能跑哪一档2.1 Whisper 模型档位与资源占用OpenAI Whisper 的常见模型体积差异很大从 tiny 到 large 都有。工程上现在也常用 faster-whisper它用 CTranslate2 重写了推理部分在 CPU 上表现更好显存占用也相对可控。无论是原始 whisper 还是 faster-whisper核心逻辑一致选模型大小转写输出文本。模型档位可以按用途分成三档档位常见模型资源要求适合场景入门档tiny / baseCPU 可跑内存 2GB 以上快速验证流程、短音频、低准确率可接受均衡档small / mediumCPU 较慢GPU 显存 4GB 以上更稳中文普通话、日常听写、会议短段落高质量档large / large-v3GPU 显存 8GB 以上磁盘空间较大长音频、混合语言、专业术语多、追求准确率实际选择时不要只看模型名字。tiny 非常快但中文效果一般容易出现同音字错误small 在普通话场景已经有可用表现medium 的准确率提升明显但 CPU 跑起来会很痛苦。如果你现在机器是 8GB 内存的无独显笔记本我建议先跑 base 或 small用一条 30 秒的样音验证流程再决定要不要换模型。2.2 LLM 组件怎么接本地模型、本地管理工具还是远程接口LLM 清理这一步常见接法有三种用本地模型管理工具启动一个本地模型Dictata 通过 HTTP 接口调用这是最符合 Local 思路的方案。直接加载一个较小的大模型框架或量化模型在同一个 Python 进程里做推理。调兼容接口填写模型名、地址和密钥把文本发过去。如果你本机显存不超过 6GB建议路径是Whisper 用 CPU 跑 medium 以下模型LLM 用一个能在 CPU 上运行的量化小模型比如 7B 或更小的量化版本或者直接把 LLM 这一层换成远程接口。不要一上来就同时跑 large whisper 和 70B 模型显存和内存都会扛不住。这里有个很容易被忽略的点LLM 清理并不是越强的模型越好而是要看响应速度。单条短音频用大模型没问题但如果要批量处理几十个录音每个录音 5 分钟LLM 推理时间会成为明显瓶颈。我自己会优先选响应快、能稳定输出中文的小模型先把流程跑通。2.3 目录、依赖和输入音频的准备建议按这样准备目录结构dictata-demo/ ├── audio/ # 放待转写音频 ├── transcript/ # 放 Whisper 原始转写 ├── cleaned/ # 放 LLM 清理后的结果 ├── logs/ # 放运行日志 └── prompts/ # 放 prompt 模板为什么要单独分目录因为批量处理时原始转写和清理结果都可能需要重跑。如果全部堆在一个目录容易出现覆盖、命名混乱、找不到中间结果的问题。音频输入要注意格式。Whisper 能处理常见格式但不同来源的录音差异很大微信语音、手机录音、会议系统导出、视频软件抽出的音频轨编码和采样率都不一样。如果音频文件本身损坏、采样率过低、声道混乱转写质量会崩。建议先把音频统一转成 16kHz 或 44.1kHz 的 wav 或 mp3至少先确认文件能正常播放。依赖方面Python 环境至少保证有 PyTorch 或对应推理库音频处理库以及可选的模型下载工具。安装前先确认 Python 版本、CUDA 版本和模型兼容性。很多启动失败不是代码问题是 PyTorch 版本和显卡驱动不匹配。3. 单条听写任务从启动到输出最小可运行流程3.1 第一步只跑通转写先别接 LLM我建议任何新的语音听写方案都先分成两步先确认 Whisper 能正常转写再让 LLM 参与清理。这样可以降低出问题时排查的范围。假设你用 faster-whisper核心逻辑类似这样from faster_whisper import WhisperModel model WhisperModel(small, devicecpu, compute_typeint8) segments, info model.transcribe(audio/demo.mp3, languagezh, beam_size5) with open(transcript/demo_raw.txt, w, encodingutf-8) as f: for segment in segments: f.write(segment.text \n)这只是参考片段不代表 Dictata 的源码但流程是通用的加载模型读取音频输出分段文本。第一次跑不要求文本完美只要求能输出非空内容并且每条分段和音频时间大致对齐。这一步要看三个东西模型加载是否正常。音频路径和格式是否有问题。输出文本是不是至少能看懂大部分内容。如果连这一步都频繁报错或输出为空不要先调 prompt而是去检查音频、依赖和模型目录。3.2 第二步把原始转写交给 LLM 做清理拿到原始转写后再把文本放进一个 LLM prompt 里。清理的目标可以拆成几项删除口语语气词和无效重复。恢复缺失的标点。修正明显的识别错误比如同音字、断句错误。按目标格式输出比如纯文本、Markdown、列表、会议纪要结构。不新增原音频里没有的信息。一个最简 prompt 模板可以是你是一个文本整理助手。下面是一段语音识别得到的原始文本可能存在无标点、重复词、口语语气词、断句混乱等问题。 请把这段文本整理成通顺、干净、可直接阅读的会议记录初稿。 要求 1. 不要新增原文没有的信息。 2. 保留原文中的专有名词、数字和术语。 3. 使用中文标点并合理分段。 4. 直接输出整理后的结果不要解释。 原始文本 {raw_text}这类 prompt 的写法不需要很复杂。关键信息有五个角色、输入来源、任务目标、限制条件、输出格式。特别是“不要新增信息”这一条能避免 LLM 把一段口语补写成完全不同的内容。3.3 从输出中反推参数温度、最大长度、模型选择LLM 清理不是编码题没有绝对标准答案。同一个输入不同参数会产生不同结果温度越高输出越有变化但也越可能改写原话。最大 token 限制太短长文本输出会被截断。prompt 里要求格式越具体输出越稳定。模型越大通常理解力越强但速度和资源消耗也越大。实际测试时可以从低温度开始比如 0.2 到 0.3因为听写清理的任务更偏向确定性的文本整理不希望模型自由发挥。如果你的 LLM 接口支持 top_p也可以固定 top_p 为 0.8 左右。不同接口参数名可能不一样落地前先确认文档或接口 schema。还有一个容易被忽略的参数上下文窗口。清理一段 5 分钟音频的转写原始文本可能已经很长。如果一次性全部塞进 prompt超过模型上下文限制会被截断或者模型只清理了开头结尾完全没处理。这时要么分段清理要么扩展上下文长度设置要么把长文本拆成多个小节再合并。3.4 什么样的清理结果算成功什么算失败判断标准不是“读起来顺不顺”这个模糊指标而是几个硬条件检查项通过标准完整性原文中的重要时间、数字、人名、专有名词都保留可读性标点完整段落合理口语重复被删除忠实度没有新增明显的事实信息没有把疑问句改成陈述句格式稳定多段转写用同一 prompt 清理后结构一致输出可复用结果可以直接粘贴到文档、邮件或笔记中只需少量手动修改如果清理后文本变短很多要检查是不是模型把内容压缩掉了如果出现原文根本没有的结论说明“不新增信息”这一条没有约束住如果多条音频的清理结果风格差异很大说明 prompt 里缺少输出结构约束。4. 批量处理与参数调整从“能跑”到“好用”4.1 多文件队列和输出命名单条音频跑通之后自然会想到批量。批量处理最麻烦的通常不是模型而是任务编排。需要想清楚输入目录有哪些文件按什么顺序处理。每个文件的输出名怎么定是否包含源文件时间戳。某个文件失败后是中断整个任务还是跳过并记录日志。中途断电、超时、显存不足后能不能重跑未完成的部分。建议输出命名使用“来源名 时间戳”的方式避免同名覆盖。比如audio/20250411_meeting.mp3 - transcript/20250411_meeting_raw.txt - cleaned/20250411_meeting_cleaned.md这样即使同一个文件跑多次也不会把旧结果覆盖掉。日志里至少记录文件路径、模型名称、处理耗时、失败原因。批处理不是把单个任务复制几份而是要有一个可追踪的清单。4.2 参数调整优先看什么不急着改什么批量任务里常见的调整候选包括Whisper 的 beam_size提高 beam_size 可能提升准确率但速度明显变慢。Whisper 的 language 参数固定语言能避免模型反复猜测也能提高速度。初始 promptWhisper 支持传入初始提示词可以指定术语、风格或常见人名。LLM 温度清理任务一般不要调高。输入音频的采样率有些音频本身是 8kHz 电话录音转写效果天然受限调整模型参数帮助有限。优先级要分清楚。先看文本质量是否已经达到可用线再看速度是否可接受最后看资源占用是否稳定。不要一上来就开最大并发也不要为了追求速度把所有参数都调到最低这样结果可能完全无法使用。如果只是学习默认配置通常够用。如果要跑大量真实任务我会建议先用 5 个小文件测试整条链路再逐步增加文件数量和并发数。4.3 长音频、混合语言和标点问题长音频是最容易出问题的场景。一个 1 小时的会议录音转写后文本量很大直接丢给 LLM 清理会出现上下文截断、输出延迟、结果丢失。我的做法是先把音频或转写文本切段。可以在 Whisper 分段结果的基础上按时间窗口或字符数切块比如每 1000 到 2000 字为一段段与段之间留少量重叠确保上下文连贯。LLM 逐段清理最后再合并成一个文件。混合语言场景要特别注意。中英文混说的录音里Whisper 有时会把英文术语识别成中文同音字或把中文拼音写成乱码。LLM 清理时如果只给“整理文本”的通用 prompt模型不一定能修正。更稳的方式是在 prompt 里注明“本录音可能包含中英文混合保留英文术语原样修正明显的中英文混排错误”。标点问题同样受模型影响。Whisper 本身会输出一定标点但中文场景下经常不完整。如果你发现 LLM 清理后标点仍然乱可以尝试在 prompt 里给出样例或者要求“每句话单独一行”。这比让模型自由发挥更容易得到稳定结果。4.4 清理过度的问题怎么判断并避免LLM 清理很有可能“用力过猛”。最常见的表现是把口语压缩成简洁书面语结果丢失了原说话人语气。把不确定内容改写得更确定造成事实偏差。把本来有歧义的表达修正成模型“觉得合理”的表达。删掉自认为不重要的时间、地名、数字。解决清理过度核心不是换更大的模型而是限制输出空间。可以在 prompt 里增加类似约束“保留原文中的数字、日期、专有名词、引号和疑问语气删除词必须是无实际语义的重复词或语气词如果原句意思模糊保留模糊状态不要补全。”如果你发现某个模型反复清理过度先在 prompt 层改不要直接换模型。清理任务里多数问题来自目标不清晰而不是模型能力不够。5. 报错排查启动失败、结果为空、LLM 请求失败5.1 模型加载失败或启动崩溃模型加载阶段最常见的报错有几类显存不足报错信息里会包含 CUDA out of memory。处理方式是小模型、降低精度、减少并发或直接用 CPU 跑。依赖版本冲突常见于 PyTorch、CUDA、模型推理库版本不匹配。排查时先打印依赖版本再对照官方要求。模型文件路径不对下载中断、目录名错误、文件权限不足都会导致加载失败。网络下载失败第一次运行会下载模型权重如果下载源不稳定可能卡在下载阶段。这时优先检查网络和磁盘空间。排查顺序建议是先看报错前最后一条日志再看磁盘空间再确认路径再看版本最后看显存和内存占用。5.2 转写结果为空或乱码转写结果为空原因通常不在模型而在输入。先确认音频文件能否正常播放是不是存在非标准编码的音频是不是静音或音量过低。很多会议录音降噪过度听起来清晰但模型识别不到有效语音。乱码则要检查音频转码过程。比如用 ffmpeg 抽取音频轨时如果指定了不合适的编码参数可能导致音频数据损坏。遇到中文识别成乱码先确认输入音频是不是真的是中文再看采样率是否过低最后检查语言参数是否正确。如果只有个别文件乱码而其他文件正常优先怀疑文件本身而不是全局参数。5.3 LLM 请求超时、返回错误或输出被截断LLM 阶段常见的报错可以分成四类现象常见原因处理建议请求超时文本太长、模型推理慢、接口并发限制切段处理降低并发调大超时时间请求被拒绝请求 schema 不匹配、密钥无效、格式不支持先看接口返回的完整错误信息再检查请求体字段返回空内容prompt 里要求过多或模型生成了空白内容简化 prompt增加输出必填字段检查响应解析逻辑输出被截断最大 token 不够长文本被截断增加 max_tokens或按字数切段处理这里有一个很实际的建议不要把 LLM 接口环节设计成“调用一次返回最终结果”。更稳的方式是先记录原始响应再解析。如果响应异常原始日志能帮你判断是模型输出问题、解析问题还是网络问题。5.4 资源占用过高或者任务卡住任务卡住时很多人第一反应是“代码是不是死循环了”但更常见的是资源不够导致模型推理极慢看起来像卡住。先看 CPU、内存、显存、磁盘 IO再看日志是否还在增长。如果 CPU 使用率百分之百但显存很低说明模型在 CPU 上跑如果显存占满了但 GPU 利用率为零可能是在等待数据加载或请求。批量跑的时候还要看是不是多个任务同时启动把内存挤爆了。一个实用的做法每个任务前打印文件名和时间每个任务完成后打印耗时。这样出现卡住时能立刻定位到是哪个文件、哪个阶段出了问题不需要从头猜。6. 适用边界与后续扩展不要高估也别只用一次6.1 什么输入适合什么输入不适合Dictata 这类本地 Whisper LLM 清理方案最适合的是单人或多人的会议录音音质基本清晰。访谈、播客、讲座转写之后需要发布或存档。自己口述日记、博客初稿、项目管理记录。语音输入场景里需要对语音结果进一步整理。不太适合的情况也很明显多人讲话严重重叠的会议。大量专业术语、稀有方言、极小语种。音频里有大量音乐、噪声、电话音质。要求高质量书面文本且不允许人工确认的场景。在这些场景下Whisper 转写准确率本身就会下降LLM 清理只能防一些口语问题没法解决源音频质量差带来的识别错误。不要指望 LLM 能把听错的单词凭空猜对。6.2 隐私、成本、可控性的取舍本地方案的隐私优势是“数据不出机器”但有一个前提你把 LLM 也装在了本地。如果 LLM 环节仍然调用远程接口那么你的转写文本实际还是会离开电脑等于 Whisper 部分的隐私优势被削弱了。如果对隐私要求很高建议整条链路都本地化。代价是机器配置要求更高推理速度更慢模型管理也更复杂。如果只是做内容草稿转写文本不敏感LLM 用远程接口反而更轻量速度和效果都有保障。成本方面要长期看本地模型一次部署后没有按量费用但前期要花时间调环境、下模型远程接口按 token 计费短文本很便宜批量长音频则费用上升。两种方式各有利弊不要只看单次跑出的结果。6.3 扩展方向模板化清理、知识库辅助、本地自动化如果你用了一段时间觉得基础清理已经稳定可以继续扩展按场景做多个 prompt 模板比如“会议纪要”“博客初稿”“待办提炼”“翻译保留原意”。不同模板对应不同输出格式。在清理前先让 LLM 抽取关键信息比如时间、负责人、结论、待办事项再输出成结构化清单。把历史转写文本建成本地知识库后续问题可以在知识库范围内检索减少模型重复推断。把整个流程接到文件监视目录里新录音放入 audio/ 后自动开始转写和清理结果写入 cleaned/。对长录音接入分段脚本把合并后的结果按标题、小节重新排版。这些方向本质上是同一个流程的工程化输入音频转写清理格式化归档。Dictata 的价值在于把第一步和第二步打通而后续的扩展可以完全按自己的场景定制。踩过几次之后我的感受是很多问题不是工具能力不够而是前置条件和输入材料没有处理干净。先跑通单条再处理批量先接受默认参数再针对性调整先记录原始输出再做解析。这套顺序能帮你避开大部分坑。