前些天，我在即刻社区上，发了一个从播客音频中提取信息的工作流，引起了一些小的反响。从我的视角来看，播客中不乏一些优质的信息源（比如大佬们太忙懒得录视频，但接受一下访谈那还是可以的），但往往只有少量内容会经过转译。
从播客主理人的视角，他所创造的内容大多是在一个小范围内（播客的听众群体）传播，即使作者可以通过写概要，把关键的讨论主题按时间戳形式列出来，这样的方式方便读者，但总不能把全文都转文字发出来对吧！
那些动辄一个小时起步的播客内容，作为一个新的潜在听众，可能他是被标题吸引，点开之后可能会发现宝藏，也可能空手而归。因为有“完整听完但未必是想要的”这样的心理负担。
总会有人是没那么多时间听播客内容的（也或者是，想用同样的时间更有效率地听），这时用 AI 技术辅助整理播客音频的内容，就成了一个能摆在台面上的方案，于是就有下面的图：
整个图开始于一个发出疑问的小人，“我想知道这个播客音频说了什么有趣的东西呢”，借助这样的提问，引发了后面一系列的连锁反应。最终收束在一个“可交互的报告文档”上。
Q：这是一个产品设计吗？
目前这个流程只是一个粗略的设想，上图打勾的部分是跑通了流程。也就是抓取、语音转文字、Claude API 的流程，这些子模块通常有比较成熟的解决方案。（如果感兴趣，可以看文末的技术附录）
Q：我已经看到类似的做法 etc…
这个想法也不是什么很难想的事情，所以同时有人在做类似事情，那几乎是肯定的。甚至偷懒的分析，只要拿一个语音转文字，再拼上一个ChatDoc的模块，就能搞定了，技术上讲是这样。
比如有个网站，Dexa — AI Powered Podcast Assistants 就提供了类似的服务。
但从落地角度则是很不一样的，假设 10% 的人懂如何做语音转文字，又 10% 的人懂如何做 ChatDoc 类对话，那拼在一起的比例就会降成个位数。
链条越长，需求越复杂，落地就更困难。
Q：这个图有点复杂，看不太懂 …
这本也不是产品流程图，只是从偏实现角度梳理了一些必要的模块。而且混杂了技术实现和数据流。如果能把每个框都单独完成，整体大概率是可以跑起来的。但如果要把每个部分完成，也肯定会遇到一些未在图中表述的坑。
整个画图梳理的过程，也就是在降低不确定的过程。（既然想不清楚，那就大概率画不出来 - -）
尤其是上图右边部分，看起来一片混沌，我先是考虑整理了如下的一些需求点：
- 语篇规整（直接转文字后，口语化的东西挺影响阅读的，这一步将其去掉）
- 语义分段（一整段音频会讨论很多主题，将讨论相似内容的合并成段落）
- 提炼 摘要内容（既然上面分段了，那就每段一个摘要吧）
- 提出感兴趣的内容（就像是在做阅读理解似的，用提问来确认你是否真的 get 到意思了）
- 提炼 专有名词、反事实观点（反事实观点通常是比较“有趣”的地方，价值所在）
- 针对 专有名词 的解释（省得我再去百度了，如何内容中直接就给出过解释的话）
- 回答问题 ⇒ 寻找提及 xxx 的段落（目前基于LLM的ChatDoc方案，均需要寻找语义相似的上下文）
- 其他的需求 …
上面是第一遍梳理时，我在草稿纸上写下的需求列表，除了最后的提问以外，还有一些是我认为它应该具备而目前市面产品所没有的（会有一部分，但不一定全）。当然这个需求列表未来可能还会变更，但我希望它能覆盖掉 80% 的需求。
结合我自己的经验，在提问得到回答以后，还有另外一些小众需求（20%的那部分）：
- 回溯历史：a) 这个音频是个系列音频，有些内容在前面的某个音频中提及，但我不知道是哪一个，于是就需要放宽范围去搜索。b) 这个音频是某种知识库的学习资料，这个内容中的某个概念，需要检索整个知识库，也需要放宽范围去搜索
- 回听内容：a) 文字是苍白的，语音是生动的，回到上下文音频中去理解到底说了什么。b) AI 处理可能中途发生错误，幻觉，需要原文来确认。c) 带文字总结的对外分享，方便拉新 ^_^
（btw 因为原文经历了各种预处理、分段、LLM，要定位原始来源是件有挑战的事情，简言之这里有潜在的坑，但也是有解决方案的）
全文完。下面就都是已实现的模块的技术方案细节了，算附录内容：
获取音频部分用小鹅通做测试
其他的平台还没尝试，应该原理是类似的。
涉及到爬虫不展开讲太多，无非就是找到关键 ajax 请求，然后获取便是了。
语音转文字，用的是 Whisper API
Whisper 是 OpenAI 开源的一个语音转文本的模型。使用它其实有两种方式：
方案 | 优点 | 缺点 |
本地部署/云端部署 | 1. 可以自由选择少参数量的模型
2. 本地消费级显卡也能跑 | 1. 下载模型自己部署会麻烦些
2. 如果租用GPU云服务器，也有成本 |
调用官方 API | 省力、快捷 | 要花钱，按分钟计费 |
这里我用的是后者，具体可以参考 OpenAI Whisper API 调用方法及效果对比 - 知乎 (zhihu.com)
如果想自己部署就可以参考 开源免费离线语音识别神器whisper如何安装 - 知乎 (zhihu.com)
大语言模型，用的是 Claude API
这一块就是各显神通了。用 Claude 的原因最主要是，目前可以白嫖免费使用。直接的 API 调用可能比较难申请，所以我用的是 Slack + Bot 的间接方式。
如何部署，看这一篇文章就够了。里面详细介绍了如何申请、安装应用、云函数调用等等。
上面的接入语言用的是 nodejs。如果你更喜欢 python 的，可以看下面这篇最后的示例源码。
因为用到了 laf 云开发，持续运行的话最低配置会产生 约 0.5 元/天 的成本。
音频文件存储
目前跑的规模不大，就100个左右文件，因此就丢在了本地。后面可以考虑云存储的方式。
这里用了个小 trick，把音频的 frame rate 降低到 16,000 可以有效降低存储空间，同时也不影响语音识别。转换的代码也贴出来了（反正也是 GPT 写的 orz）
def set_frame_rate(self, target_rate=16000): audio = AudioSegment.from_file(self._audio_filename) frame_rate = audio.frame_rate if frame_rate > target_rate: audio = audio.set_frame_rate(target_rate) audio.export(self._audio_filename, format="mp3") print(f"Frame rate has been updated from {frame_rate} to {target_rate} and saved to the file.")
甚至更极端的，可以直接存原始的 mp3 链接，这样连音频都不用存了 2333。
最后的彩蛋
既然都看到这儿了，那肯定也是忠实粉丝啦。放个小彩蛋~
不知你是否见过B站上那些长达1个多小时的教学视频，我明确知道它里面肯定有东西的。但是1个多小时里，对我真正有用的可能就那10分钟。该如何找到呢？
- 基于视频字幕总结的做法：效果可能有限，因为10分钟相对于1个多小时占比偏小，过于笼统概要性的总结未必提供了有效的信息量
- 基于提问的方法：我本来就是学习者，对这个东西不熟悉，我咋提问呢？这也是个矛盾
我认为理想的解决方案应该是某种交互式的操作，比如把1个多小时的视频变成交互式的 game。列出关键要点，以及解释，甚至还可以出些题考验一下。不理解的地方就可以跳转原始视频。
当然做起来也挺难的~
