Category: 技术

前文链接：

• 基于大模型的播客RAG系统搭建攻略（一）：缘起，架构和选型
• 基于大模型的播客RAG系统搭建攻略（二）：进阶之路与避坑指南

仓库地址：https://github.com/liujinmarshall/podcast_rag

首先插播一条新闻。在两周之前，我常用的播客客户端小宇宙推出了会员plus计划：

我们的会员产品“小宇宙PLUS”现已上线，提供「AI播客总结」「收藏时点」「会员周报」「个性图标」「多彩主题色」等多个功能，一起来看看！

小宇宙PLUS会员，现已包含以下权益 ——

· AI播客总结
服务于播客重度用户的一些高信息密度节目场景。例如：你可以通过AI播客总结判断一期没有shownotes的节目是否值得听，也可以高效得到一期财经、商业、科技等领域节目的内容速报。更多使用场景，期待你的探索。

· 收藏时点
你可以通过「收藏时点」功能，随时标记最感兴趣的时点，记录此刻的私人笔记，并在【我的收藏】中查看汇总。即使正处于锁屏状态下也无需担心，iOS系统中，无需解锁也可以通过左下角的收藏按钮进行收藏时点的操作，一键收藏此刻的吉光片羽。

· 会员周报
每周一中午12:00左右，我们将为会员用户送上专属会员周报，并为你自动汇总并总结你可能错过的精彩节目，为你持续挖掘更多的兴趣内容。欢迎在【个人-会员入口】处进入查看。

· 个性图标与多彩主题色
看腻了你的小宇宙？成为小宇宙PLUS会员，即刻更换你的小宇宙图标和主题色，深空、毛绒、键帽、粉白、薄荷、深蓝……超多可选，让你的小宇宙与众不同。

当中第一项AI播客总结正好完美契合这个项目的功能，虽然我强烈怀疑这个会员是否真的值一年120元。因此我也在程序中加上了单集总结的功能。实现非常简单，通过发送提示词+播客转录稿实现。

计划中的功能列表：

• 支持英文播客：加入英文提示词，并根据播客语言选择对应的提示词。
• 切换embedding：现在使用的OpenAI text embedding的开销，对于个人用户来说不算很大，但也不小。需要切换到更便宜的版本或者本地推理的text embedding。目前计划使用MTEB榜单中排名较为靠前但显存需求不大的gte-Qwen2-1.5B-instruct
• 一键运行所有任务：当前程序被分为不同的子程序，需要统一一个运行入口。
• 新增播客总结：对于每次增量更新的内容进行小结。

以下是中文版的使用说明：

仓库地址：https://github.com/liujinmarshall/podcast_rag

使用 RAG (检索增强生成) 技术来理解播客并提问

已测试 Python 版本：3.9 (应该也适用于更新的版本和不太旧的版本)

前提条件

• Python 环境以及并了解如何运行 Python 程序
• Google Gemini API 密钥和 OpenAI API 密钥

步骤

1. 克隆此 Github 仓库；
2. 创建一个名为 “data” 的目录；
3. 将 podcasts.example.csv 复制到 data/podcasts.csv，并添加 RSS URL 条目；
4. 通过 requirements.txt 安装 Python 依赖 (pip install -r requirments.txt)；
5. 将 Google Gemini API 密钥导出为 GEMINI_API_KEY，并将 OpenAI API 密钥导出为 OPENAI_API_KEY；
6. 运行以下脚本以实现以下功能（使用 python xxx.py）：
   1. download.py: 将播客音频媒体文件以增量模式下载到本地。每个播客一个目录。
   2. transcribe.py: 将音频媒体文件转录成文本。每个播客一个目录。
   3. index.py: 将转录文本分块并索引到向量数据库 (ChromaDB) 中。
   4. query.py: 启动一个聊天机器人来查询问题：
      • 运行程序；
        • 在浏览器中打开链接并开始提问 。
   5. summarize.py: 将转录文本总结成简洁的摘要。每个播客一个目录。
   6. delete_files.py: 删除音频媒体文件（超过 24 小时的文件），以防文件上传超出配额。上传超过 48 小时的文件将被自动清除

语言支持

• 中文
• 英语 (待添加)

注意

请遵守播客提供商的用户协议。此仓库仅供个人研究使用。

第一部分：https://onlymarshall.com/2025/01/05/build-personal-podcast-rag/

第三部分：https://onlymarshall.com/2025/01/26/build-personal-podcast-rag-part-3/

（注：本文在Gemini模型协助下完成。不得不感慨大模型很多时候思考的比人类周全，人类只要提供一些基本元素，大模型就可以把内容打磨地得非常完善）

上一篇我们介绍了播客搜索问答系统的基本架构和初步选型，特别是在语音转录方面的一些尝试和思考。今天我们继续深入，聊聊在系统搭建过程中遇到的更具体的技术挑战以及一些解决方案。

索引/检索的优化与挑战

上一篇我们提到索引和检索环节主要依赖文本向量模型和向量数据库。看似简单，但真正落地会遇到不少问题，尤其是在播客这种持续更新的内容源上。

增量更新：让知识库保持新鲜

播客的一大特点是持续更新。每周甚至每天都会有新的内容产生。如果每次更新都重新处理所有播客数据，那将是巨大的资源浪费。因此，增量更新是必须要考虑的。我们的目标是只处理新增的播客和更新的播客。这需要我们在“播客下载/爬虫”阶段做一些改进：

• 记录已处理的播客和音频文件： 我们需要一个机制来记录哪些播客和对应的音频文件已经被处理过了。一个简单的做法是维护一个数据库（或者是简单的CSV文件），记录播客的feed URL以及每个episode的发布时间或唯一的GUID。
• 对比更新时间或文件大小： 在爬取时，对于已经记录的播客，我们可以通过HEAD请求获取最新的episode信息，对比发布时间或GUID。对于新的episode，或者发布时间有更新的episode，再进行下载和后续处理。
• 文件大小与HEAD请求的妙用： 除了对比发布时间，我们还可以利用HTTP HEAD请求来获取音频文件的大小。如果新爬取的音频文件大小与之前记录的不同，则说明文件可能被修改过，需要重新下载和处理。这对于一些播客会修改音频描述或者替换音频文件的情况很有用。HEAD请求相比于直接下载整个文件要高效得多，大大节省了网络资源。
• 处理删除的播客： 有些播客可能会下架某集播客。我们需要定期检查已处理的播客列表，对比最新的feed内容，将已删除的播客集从向量数据库中移除，保持数据的一致性。
• 保留时间：播客毕竟是音频文件，几百期的内容加起来也有几十个GB，如果总是保留所有的冷文件，特别是对于个人来说，存储的成本也没有必要。

有了以上这些功能，我们每天只要定时跑任务就可以自动完成对比、下载、转录、处理以及更新数据库的工作。

大模型转录的“后遗症”：重复文字问题

上一篇我们提到利用大模型的长上下文能力进行音频转录非常方便。但实际使用中，我们发现一个潜在的问题：重复文字和错误退出。

尤其是在音频质量不高、语速较快或者多人对话的场景下，大模型有时会重复生成一些片段的文字。这可能是由于模型对音频的理解不够准确，或者在拼接长文本时出现偏差。

如何解决重复文字问题？

• 检测错误并重新转录：这种情况有点像代码中因为并发造成的bug，而大模型运行本身也有一定的随机性，所以很大概率重新转录就可以解决这个问题。
• 更精细的音频切分： 虽然我们避免了为了输入长度而进行的粗暴切分，但适当的、基于语义的切分仍然有必要。例如，可以根据静音段落或者明显的语意停顿进行切分，这样可以减少模型处理长音频的压力，降低重复的概率。
• 后处理去重： 在得到转录文本后，可以进行一些后处理操作。例如，可以设定一个滑动窗口，如果窗口内的文本重复出现，则进行删除。当然，这需要谨慎操作，避免误删有效信息。
• Prompt优化： 在给大模型下达转录指令时，可以加入一些提示，例如“请勿重复生成已出现过的文字”，虽然效果可能有限，但有时也能起到一定的作用。
• 尝试不同的模型参数或模型： 不同的模型或者相同的模型在不同的参数设置下，表现可能会有差异。可以尝试调整解码策略或者使用更擅长处理此类问题的模型。

Text Embedding的中文选择：Gemini的踩坑

上一篇我们提到在文本向量模型上“跌了个跟头”。这里就来展开说说。

最初，我们可能自然而然地会选择一些通用的、在英文领域表现优秀的Embedding模型。既然Gemini也提供了文本Embedding，我们自然也选择这个模型。

但是在生成Embedding、存入数据库，再通过查询的Embedding进行检索之后，我发现了一个严重的问题：Gemini的文本模型似乎完全没办法理解中文。

以下面的例子看，我们通过Gemini text-embedding-004模型，完全不同问题产生的embedding前10维完全一样。如果加上了一些英文字母的扰动，生成的结果就完全不一样。推测原因应该是tokenization的阶段把所有的非英文字符全部映射成了<UNK>，所以结果没有区别。

解决的方案也很简单：换成OpenAI的Embedding模型（text-embedding-3-small），因为使用了ChromaDB的代码，切换embedding function只要改动几行代码就可以实现。

后注：最终在某个文档页面发现了这个模型并不是多语言的版本，但似乎在GenAI embedContent的API里只能调用embedding-001和text-embedding-004，如果要调用多语言模型需要换到其他API。

Chunk大小的权衡

将长篇的转录文本切分成更小的chunk（块）是进行向量化的必要步骤。 Chunk的大小直接影响着检索的准确性和效率。

• Chunk太小： 可能无法包含完整的语义信息，导致检索时丢失上下文，返回的结果不够相关。例如，一句关于“苹果公司新发布的手机”的信息被切分成“苹果公司”和“新发布的手机”两个chunk，单独检索“苹果公司”时，可能返回大量无关的结果。
• Chunk太大： 虽然包含了更多的上下文，但会增加向量的计算成本和存储成本。同时，如果一个chunk内包含多个主题，可能会导致检索时返回与用户问题不太相关的部分。
• Embedding模型限制：大部分embedding模型限制输入在几个K token左右，比如Gemini GenAI是输入上限2K，输出768维，OpenAI输入是8k，输出1536维

如何选择合适的Chunk大小？

这是一个需要根据实际播客内容和模型能力进行实验和调整的过程。一些可以参考的策略：

• 基于句子或段落切分： 这是比较常用的方法，可以保证chunk的语义完整性。
• 固定大小切分并加上重叠： 将文本按照固定token数量切分，并在相邻的chunk之间添加一定的重叠部分，以保留上下文信息。例如，一个chunk包含100个token，重叠20个token，那么下一个chunk从第81个token开始。
• 利用语义切分工具： 一些工具可以根据语义相似性来切分文本，使得chunk内部的语义更加连贯。

在我们的实践中，我们尝试了不同的chunk大小，并结合向量检索的效果进行评估。 出于简单的考虑我们选择了固定大小切分并加上重叠。参数是2000个token一个chunk，重叠是200个token，通过tiktoken的包进行本地的计算（因为不知道embedding模型的tokenzier配置，所以这里只是近似）

小结

这篇博文我们深入探讨了播客RAG系统搭建过程中的一些关键技术点和挑战，包括增量更新、大模型转录的重复问题、中文Embedding模型的选择以及chunk大小的权衡。虽然已经有了大模型的加持可以很快编写核心骨架代码（大概降低了一半的时间），但是需求的不断迭代和看到结果后目标不停的调整，还是有相当大量的人为介入。编程门槛的降低，可以让非专业人士和专业人士摆脱一些低级的信息查找，把时间投入更有效率的地方。

后续我会整理一下代码之后发布开源（现在大部分都在notebook里）。