一、语音rag主要的目标是在实时语音对话中加入RAG增强检索一个重要的问题是是 RAG 检索结果如何在正确时机注入模型。最初的实现策略是先在后端找到豆包实时语音接入点、先把知识库检索能力复用进去、先把前端引用展示做出来再围绕日志修正细节。二、逐步修复在第一轮真实语音测试出现问题也是提供的prompt助手会复读用户说的话语音播报只播放前几个字或者前半句有时看不到参考文献有时甚至没有任何语音输出。ai给出的修复思路仍然停留在应用层尝试在实时返回文本里做清洗避免把用户原话误判成助手回复尝试把最终文本重新走 TTS 合成避免实时 PCM 片段不完整尝试把 citations 事件下发给前端并重写语音通话页里损坏的 WXML/TS 渲染逻辑。但问题是ai为了修复“只播前几个字”而引入了已经弃用的 TTS 链路直接返回了403 code3001 requested resource not granted。这时vibecoding 的一个问题如果没有把业务流程和第三方服务边界区分清楚AI 很容易在“为了修一个用户体验问题”时无意间引入新的系统依赖在这里插入图片描述结果是从一个问题跳到另一个问题。后续我把这条额外 TTS 回退去掉重新回到“必须坚持豆包端到端语音回复不切回 ASRLLMTTS”的用户约束上这一步其实就是把最初模糊的 VIBE 往 SPEC 收紧了一步系统架构不能再随问题浮动必须固定在端到端语音模型这条主链路上。真正的问题在于时序控制也就是官方使用文档中的那个时序图。这个阶段开始集中对照火山引擎官方文档和本地示例工程 。很快就能发现真正影响行为的是协议事件序列450表示 ASR 信息到达451是连续 ASR 响应459是用户本轮 query 结束后面才会进入350 / 352 / 550 / 351 / 359这组和 TTS/文本生成有关的事件。这次的改动有两个。一是把前端状态从“用户松口即主动结束”改为“等待服务端确认语音结束”也就是不再用本地随意切换processing去抢服务端状态。二是对照示例工程把 RAG 链路抽象成一个明确的序列459到达后异步触发ChatTTSText(start/end)作为安抚语再执行外部知识检索最后用ChatRAGText把external_rag注入模型。三、依旧是时序问题通过多轮日志可以确定Milvus 检索并不是没有生效而是经常在模型已经开始生成之后才完成。典型顺序是先出现连续的352音频和550文本分片说明模型已经开始回答然后才看到数据库查询knowledge_slice / knowledge_doc接着才打印Realtime directive sent ChatRAGText。这证明 RAG 虽然被发出去了但在这轮回答中没有真正驱动这轮回复的生成,模型回答完了才被发出去。其次通过引入原始错误帧日志终于把一个长期模糊的问题钉死了。服务端返回的错误是decode ws request failed: unable to decode V1 protocol message: declared body size does not match actual body size: expected36 actual309。这个错误不是业务错误而是传输协议错误。它说明我们发送event0自定义 directive 的帧布局与服务端期望不一致服务端把 header 里写入的 sessionId 长度36当成了 body size结果导致整个包体偏移错位。这个阶段有一个非常重要的工程认知示例工程里的Protocol.createFullClientMessage(sessionId, text)只是示意性实现它体现的是“外层包裹 inner JSON”的写法但并不自动保证在当前服务端版本、当前账号模型配置、当前工作模式下仍然百分之百可用。换句话说示例代码提供的是思路和样式不是已经替你完成验证的 production spec。因此后续的修复开始转向真正的协议层。对自定义 directive 的处理被单独拆开普通事件仍走sendEventJson(...)但ChatTTSText / ChatRAGText这种event0指令不再把sessionId写入协议头而只在 payload 里保留外层session_id。同时所有后续指令都改成跟随服务端回包中的真实message.sessionId而不是一直沿用本地初始化的state.modelSessionId。这一步是整个联调中最接近“SPEC 级修正”的动作因为它不再围绕现象猜测而是直接根据服务端错误信息修正帧结构。四、修正协议错误首先需要验证语音模型的回复是否真的基于rag检索的结果。后端加入了专门的 RAG 验证日志记录每轮问答中的四段信息用户最终问题、Milvus 命中的切片摘要、发给豆包的external_rag内容预览以及最终助手回答。测试“请为我介绍老年便秘用药问题”。日志显示searchHit命中了多条关于老年便秘治疗原则、刺激性泻剂风险、优先选择容积性/渗透性泻药的片段externalRagPayload也成功组装了包含这些片段的 JSON但与此同时连续的352和550早在searchHit之前就已经开始出现并且最终回答只有非常泛化的一句话“一般可以用温和一点的通便药但是最好还是先问问医生”。因此后续的修复方向做出妥协不再优先追求“有安抚语音”把459之后的热路径缩到最短把数据库落库这样的非关键动作放到后台把 RAG 注入尽量提前到模型开始出550/352之前。五、进度后端已经把豆包端到端语音接入到实时对话链路中system prompt 的注入位置已经固定在StartSession - dialog.system_roleMilvus 检索结果已经能够构造成external_rag前端语音通话页面已经能接收并展示 citationsRAG 验证日志也已经能够回答“是否检索到了”“是否发给模型了”“最终回答是什么”这些关键问题。最核心的问题在于“如何确保ChatRAGText进入模型生成窗口之前就送达从而让最终回答真正由 RAG 驱动”。
sdu软件学院创新实训（五）
一、语音rag主要的目标是在实时语音对话中加入RAG增强检索一个重要的问题是是 RAG 检索结果如何在正确时机注入模型。最初的实现策略是先在后端找到豆包实时语音接入点、先把知识库检索能力复用进去、先把前端引用展示做出来再围绕日志修正细节。二、逐步修复在第一轮真实语音测试出现问题也是提供的prompt助手会复读用户说的话语音播报只播放前几个字或者前半句有时看不到参考文献有时甚至没有任何语音输出。ai给出的修复思路仍然停留在应用层尝试在实时返回文本里做清洗避免把用户原话误判成助手回复尝试把最终文本重新走 TTS 合成避免实时 PCM 片段不完整尝试把 citations 事件下发给前端并重写语音通话页里损坏的 WXML/TS 渲染逻辑。但问题是ai为了修复“只播前几个字”而引入了已经弃用的 TTS 链路直接返回了403 code3001 requested resource not granted。这时vibecoding 的一个问题如果没有把业务流程和第三方服务边界区分清楚AI 很容易在“为了修一个用户体验问题”时无意间引入新的系统依赖在这里插入图片描述结果是从一个问题跳到另一个问题。后续我把这条额外 TTS 回退去掉重新回到“必须坚持豆包端到端语音回复不切回 ASRLLMTTS”的用户约束上这一步其实就是把最初模糊的 VIBE 往 SPEC 收紧了一步系统架构不能再随问题浮动必须固定在端到端语音模型这条主链路上。真正的问题在于时序控制也就是官方使用文档中的那个时序图。这个阶段开始集中对照火山引擎官方文档和本地示例工程 。很快就能发现真正影响行为的是协议事件序列450表示 ASR 信息到达451是连续 ASR 响应459是用户本轮 query 结束后面才会进入350 / 352 / 550 / 351 / 359这组和 TTS/文本生成有关的事件。这次的改动有两个。一是把前端状态从“用户松口即主动结束”改为“等待服务端确认语音结束”也就是不再用本地随意切换processing去抢服务端状态。二是对照示例工程把 RAG 链路抽象成一个明确的序列459到达后异步触发ChatTTSText(start/end)作为安抚语再执行外部知识检索最后用ChatRAGText把external_rag注入模型。三、依旧是时序问题通过多轮日志可以确定Milvus 检索并不是没有生效而是经常在模型已经开始生成之后才完成。典型顺序是先出现连续的352音频和550文本分片说明模型已经开始回答然后才看到数据库查询knowledge_slice / knowledge_doc接着才打印Realtime directive sent ChatRAGText。这证明 RAG 虽然被发出去了但在这轮回答中没有真正驱动这轮回复的生成,模型回答完了才被发出去。其次通过引入原始错误帧日志终于把一个长期模糊的问题钉死了。服务端返回的错误是decode ws request failed: unable to decode V1 protocol message: declared body size does not match actual body size: expected36 actual309。这个错误不是业务错误而是传输协议错误。它说明我们发送event0自定义 directive 的帧布局与服务端期望不一致服务端把 header 里写入的 sessionId 长度36当成了 body size结果导致整个包体偏移错位。这个阶段有一个非常重要的工程认知示例工程里的Protocol.createFullClientMessage(sessionId, text)只是示意性实现它体现的是“外层包裹 inner JSON”的写法但并不自动保证在当前服务端版本、当前账号模型配置、当前工作模式下仍然百分之百可用。换句话说示例代码提供的是思路和样式不是已经替你完成验证的 production spec。因此后续的修复开始转向真正的协议层。对自定义 directive 的处理被单独拆开普通事件仍走sendEventJson(...)但ChatTTSText / ChatRAGText这种event0指令不再把sessionId写入协议头而只在 payload 里保留外层session_id。同时所有后续指令都改成跟随服务端回包中的真实message.sessionId而不是一直沿用本地初始化的state.modelSessionId。这一步是整个联调中最接近“SPEC 级修正”的动作因为它不再围绕现象猜测而是直接根据服务端错误信息修正帧结构。四、修正协议错误首先需要验证语音模型的回复是否真的基于rag检索的结果。后端加入了专门的 RAG 验证日志记录每轮问答中的四段信息用户最终问题、Milvus 命中的切片摘要、发给豆包的external_rag内容预览以及最终助手回答。测试“请为我介绍老年便秘用药问题”。日志显示searchHit命中了多条关于老年便秘治疗原则、刺激性泻剂风险、优先选择容积性/渗透性泻药的片段externalRagPayload也成功组装了包含这些片段的 JSON但与此同时连续的352和550早在searchHit之前就已经开始出现并且最终回答只有非常泛化的一句话“一般可以用温和一点的通便药但是最好还是先问问医生”。因此后续的修复方向做出妥协不再优先追求“有安抚语音”把459之后的热路径缩到最短把数据库落库这样的非关键动作放到后台把 RAG 注入尽量提前到模型开始出550/352之前。五、进度后端已经把豆包端到端语音接入到实时对话链路中system prompt 的注入位置已经固定在StartSession - dialog.system_roleMilvus 检索结果已经能够构造成external_rag前端语音通话页面已经能接收并展示 citationsRAG 验证日志也已经能够回答“是否检索到了”“是否发给模型了”“最终回答是什么”这些关键问题。最核心的问题在于“如何确保ChatRAGText进入模型生成窗口之前就送达从而让最终回答真正由 RAG 驱动”。
