写在前面
使用过 NotebookLM 的读者，不知道有没有被它的效果惊讶到，没使用过的也没关系，现在可以去尝试一下。先简单说一下笔者近期关于模型应用技术的两条主线，一是：RAG优化升级（这里不展开细说），二是：播客生成，也就是今天的主题，旨在能抛砖引玉的进行探索和思考出如何生成类似NotebookLM一样的效果。文章会断断续续，更新间隔很大程度上取决于牛马的繁忙度～
总体介绍
以上是简单的时序图介绍，关键点其实在于文档处理，和对话生成两个模块，对于 TTS的部分，我们直接采用第三方（不在笔者的讨论范围内）。
实际体验
直接double hard pro：上传了一份三国演义（文言文）的PDF版本，然后让其生成PodCast。笔者听了一遍，非常震惊，做的真是太好了。接下来，我们利用工具快速来分析一下生成的对话细节
以下是双人对话中两人的总结：
以下是整个对话的脑图展示：
以下是整个对话的内容流式展示：
应用场景
以下可能的应用场景是研发侧的一点思考，仅仅只是抛砖引玉。
1. 和现有广播的使用场景一致，比如交通广播聊新闻，聊指定的话题等。
2. 教育场景下，基于教材、知识点或论文之类的，听大家交流、讨论，可以更快的拓宽知识的理解维度和深度（自我感觉）。
对话的形式，其实是有助于将复杂或专业的内容以更易懂的方式呈现，增强互动性和趣味性，比较适用于需要深入解读和讨论的各个领域。
技术难点
1. 文档处理难度：PDF是常用也是非常难处理的文件类型
2. 多文档联合生成：在多主题，长文本的场景下，对话的宽度和深度如何进行平衡和取舍。
3. 多人场景：PodCast的形式并不仅仅指两人对话，而是多人参与讨论的情景。
开源实现
笔者理清了一些问题后，就开始找一些开源的实现：
1. YOYZHANG PodCastLM[1]
2. 欢迎读者补充其他的开源实现。
这个项目的亮点在于，进行了整个流程的实现。笔者后续的调整都会基于这个开源项目来进行。但该项目的实现较为简单，并没有解决上述中提到的那些技术难点问题。
接下来，我们就来熟悉一下这个开源项目，为后续修改调整打下基础。
源码解读
前端部分
我们直接在fronted 目录下新建一个".env" 文件并赋值，BASE_URL 为服务的地址。
BASE_URL="http://127.0.0.1:54321"
HOST_URL=""
为了最大降低前端的修改成本（其实是笔者不会....），我们目前先复用现有的接口逻辑和格式。
服务部分
算法的实现方式是直接提取出PDF的所有内容，然后直接通过prompt的方式来实现，那么我们直接看一下这两部分，其他的部分我们先忽略，毕竟那些现阶段不是重点。
async def get_pdf_text(pdf_file: UploadFile):
text = ""
print(pdf_file)
try:
# 读取上传文件的内容
contents = await pdf_file.read()
file_hash = hashlib.md5(contents).hexdigest()
if file_hash in pdf_cache:
return pdf_cache[file_hash]
# 使用 BytesIO 创建一个内存中的文件对象
pdf_file_obj = io.BytesIO(contents)
# 使用 PdfReader 读取 PDF 内容
pdf_reader = PdfReader(pdf_file_obj)
# 提取所有页面的文本
text = "\n\n".join([page.extract_text() for page in pdf_reader.pages])
# 重置文件指针，以防后续还需要读取文件
await pdf_file.seek(0)
return text
except Exception as e:
return {"error": str(e)}
可以看到PDF的处理实现比较简单，在面对一些较复杂的PDF类型时这个处理方式会遇到较大问题。为了提高咱们的效率，咱们前面直接用处理好的文本来调试对话的生成效果，而文件的处理，我们会放到后面来做。
你是一位世界级的播客制作人，任务是将提供的输入文本转化为引人入胜且内容丰富的播客脚本。输入内容可能是非结构化或杂乱的，来源于PDF或网页。你的目标是提取最有趣、最有洞察力的内容，形成一场引人入胜的播客讨论。
操作步骤：
1. 分析输入：
仔细检查文本，识别出关键主题、要点，以及能推动播客对话的有趣事实或轶事。忽略无关的信息或格式问题。
2. 编写对话：
发展主持人与嘉宾（作者或该主题的专家）之间自然的对话流程，包含：
• 来自头脑风暴的最佳创意
• 对复杂话题的清晰解释
• 引人入胜的、活泼的语气以吸引听众
• 信息与娱乐的平衡
对话规则：
• 主持人始终发起对话并采访嘉宾
• 包含主持人引导讨论的深思熟虑的问题
• 融入自然的口语模式，包括偶尔的语气词（如“嗯”，“好吧”，“你知道”）
• 允许主持人和嘉宾之间的自然打断和互动
• 嘉宾的回答必须基于输入文本，避免不支持的说法
• 保持PG级别的对话，适合所有观众
• 避免嘉宾的营销或自我推销内容
• 主持人结束对话
3. 总结关键见解：
在对话的结尾，自然地融入关键点总结。这应像是随意对话，而不是正式的回顾，强化主要的收获，然后结束。
4. 保持真实性：
在整个脚本中，努力保持对话的真实性，包含：
• 主持人表达出真实的好奇或惊讶时刻
• 嘉宾在表达复杂想法时可能短暂地有些卡顿
• 适当时加入轻松的时刻或幽默
• 简短的个人轶事或与主题相关的例子（以输入文本为基础）
5. 考虑节奏与结构：
确保对话有自然的起伏：
• 以强有力的引子吸引听众的注意力
• 随着对话进行，逐渐增加复杂性
• 包含短暂的“喘息”时刻，让听众消化复杂信息
• 以有力的方式收尾，或许以发人深省的问题或对听众的号召结束
重要规则：每句对话不应超过100个字符（例如，可以在5-8秒内完成）。
示例格式:
**Host**: 欢迎来到节目！今天我们讨论的是[话题]。我们的嘉宾是[嘉宾姓名].
**[Guest Name]**: 谢谢邀请，Jane。我很高兴分享我对[话题]的见解.
记住，在整个对话中保持这种格式。
技术规划
通过Prompt来一统的实现方式，远远满足不了我们前面讨论的那些技术难点，接下来，笔者会尝试一些新的方法在其基础上进行调整，预期会比较快哦，读者们可以期待一下。
粤ICP备14082021号
免费POC，
零成本试错
