声明：本文仅介绍如何通过技术手段搭建系统，请遵守各个播客的用户协议。
第二部分：https://onlymarshall.com/2025/01/11/build-personal-podcast-rag-part-2/
第三部分：https://onlymarshall.com/2025/01/26/build-personal-podcast-rag-part-3/
缘起
开始听播客是在2016年初，那个时候刚拥有了人生第一辆车，也搬到了郊区自己的房子里，有比较固定的时间和空间。不知道是什么原因知道了在喜马拉雅上遇到了机核网的播客，那会儿已经开播了好几年，如获至宝，在两个月内把Gadio Pro栏目（特别是麦教授和四十二参与的）从第一期开始听完。之后随着机核的发展，转战机核App，直到2020年播客爆发，App也换成了小宇宙（意外发现就在五角场创智天地的前公司马路对面），形成了固定的收听习惯，订阅几十个中外栏目。
订阅的这些播客栏目，有些还是有相当的信息量。因为产品的音频形态，信息检索比较麻烦，有些播客即便刚刚听过，想回过头来找忘记或者漏掉的信息，也和很难定位到具体的时间点位重听。或者新接触一个播客，想知道以前聊过的内容里有没有自己感兴趣的话题可以快速加入收听列表。
架构
信息检索系统与搜索引擎
信息检索本质上可以分解成三个模块：
- 下载/爬虫
- 处理/索引
- 检索/响应服务
传统的搜索引擎，这三部分对应了：
- 爬虫系统：按照超链接把互联网的网页（文档）下载到本地
- 索引系统：清洗数据，提取关键词，建立倒排索引（关键词->文档），索引更新
- 检索系统：查询分析、排序结果文档
之所以要构建这三个系统，特别是爬虫和索引系统，主要原因在于整个互联网数据量太大，因此需要提前把文本内容下载并存储成检索友好的格式，这样用户通过关键词搜索就可以在几百毫秒之内得到结果。
RAG
随着大模型的出现，语义搜索也有了新的思路。这两年比较流行的方案是RAG（Retrieval Augementation Generation，检索增强生成，一个很拗口的名字）。我们也将采用这个方案。
RAG主要影响索引系统和检索系统，尤其是后者。传统的信息检索系统通过关键词匹配的方式搜索，直接把结果文档推给用户（再加上匹配到的关键词以及上下文高亮），但用户还需要自行处理加工。用户本质上是带着问题来的，比如“鸡蛋会增加胆固醇吗？”，“如何申请延迟提交报税表格”，关键词查询往往离最后的答案还有一定距离。
RAG利用大模型出色的语义处理能力，通过向量搜索（因为查询不再是关键词而是一个问题，传统的关键词查找加上倒排索引无法完成任务）查找到相关的文档，然后交给大模型去回答问题。RAG可以胜任语义搜索/问答的任务，但相对地使系统开销大大增加(10x)，响应速度明显变慢(10x)。
播客搜索/问答架构
回到一开始的问题，我们搭建的系统也是由这几个模块组成：
- 播客下载/爬虫：通过公开的RSS爬取播客音频和介绍信息；
- 播客转录：把音频和介绍信息发送给语音到文字的引擎，变成文字稿，同时将文字稿分割处理向量化，放进向量数据库；
- 播客搜索：搭建RAG系统，把问题转成向量进行向量搜索得到相关的文字稿，再把文字稿作为上下文和问题一起发送给大模型，得到最终回答并返回给用户。
选型
开发工具
最重要的开发工具是用来生成代码的大模型，这个年代做这种原型开发似乎已经没人从零开始写代码，尤其是还需要很多查找文档或者调试的工作。这次开发没有用很火的Cursor（舍不得花20刀月费）或者Github Copilot（公司有，但自己的设备也要花钱），而是体验阶段的Gemini 2.0 Flash Thinking Experimental搭配Google AI Studio。另外只是自己使用，暂时没有上线的需求，所以只在Jupyter Notebook里运行。
语音转录
一开始想直接用OpenAI的whisper，价格如果嫌贵（一分钟$0.006刀，对应1集1个小时$0.36，100集要36刀也不是很便宜），也可以考虑本地host（但没有具体benchmark手头的4080可以跑多快）。主要的限制有两个：
- 模型比较旧，处理prompt（比如时间轴，嘉宾识别）的能力不强；
- 最大处理能力25MB，一个小时的音频大概是50~70MB，需要把音频切块。可以使用mp3lst等开源工具在段落切分（根据dB），但是不同音频的切分threshold可能不同，切分如果太细也会影响转录的精度。
前期工具调研在这一步卡了几天，后来想到可以直接用长上下文的大模型进行转录。尝试了市面上主流的几个模型以后，发现Google Gemini Flash 1.5非常合适：
- 转录效果不错，可以基本正确生成时间轴，识别讲话的嘉宾；
- 上下文窗口足够大，1M token可以容纳超过5个小时的音频（最大支持9.5小时）；
- 免费！免费档每天1500次配额，一集播客大概1-3次请求即可完成转录，转录一集大概3分钟完成，正好足够单线程处理）；后面的收费档，一集一小时播客的成本大概
$0.18（更正应为 $0.018，比官方价格贵因为上下文长且有好几次的对话)，是whisper的一半（更正：应为5%），如果使用1.5 Flash 8B价格还能再减半（效果差点）。
- 免费！免费档每天1500次配额，一集播客大概1-3次请求即可完成转录，转录一集大概3分钟完成，正好足够单线程处理）；后面的收费档，一集一小时播客的成本大概
解决了输入长度的问题，下一步卡在了输出这一步。为了避免单次请求占用过多的GPU资源，大部分模型的输出卡在了4k/8k，大概只够放半个小时的音频转录内容。难道又要回到音频切分的老路？其实解决办法很简单，在与大模型对话中继续提示：“请根据上面已经生成的内容继续生成转录文字稿。”，就会在上次停下的地方继续转录，直到完成所有的转录。这也是大模型编程神奇的地方：通过自然语言下发指令，而不是严格定义的编程规格/接口。
利用大模型的长上下文来做转录固然比较方便，但是这会导致需要下一次请求附带整个对话（之前转录的内容加上音频），成本直接翻N倍（如果是N次输出）。如果考虑成本的话，进行切分再拼起来是更好的选择。
索引/检索
这块没有特别的要求，基本上各厂商的文本对话大模型和文本向量模型就能满足需求。不过后面在文本向量模型上跌了个大跟头，后面的文章细说。
本地向量数据库选用了ChromaDB，直接让大模型替我做了选择。
附录：问问小宇宙
小宇宙官方也有类似的应用问问小宇宙，UI挺特别的，但是似乎产品一直没有迭代，召回也比较一般（似乎是基于每篇播客的AI总结做的，因此漏掉很多细节）。
OnlyMarshall 