基于Deepgram的语音呼叫系统RAG质量优化与实时检索技术问询

一、RAG质量提升（重点解决短语音查询问题） #

1. 短查询语义补全 #

短语音查询往往信息匮乏（比如“你们地址？”），直接检索容易偏差。可以结合通话上下文+客户知识库元数据扩充查询：

• 把当前转写片段和最近3轮对话历史拼接，比如用户先问“你们做什么的？”，再问“地址？”，就把查询补全为“询问[客户公司]的办公地址，用户之前了解过公司业务”
• 给知识库chunk打上元数据标签（如「企业概况」「联系方式」「产品参数」），检索时先过滤对应标签的chunk，缩小范围

2. 文本分割策略精细化 #

递归分割器要适配知识库内容调整：

• 对短信息（如地址、电话、核心产品名）单独设置100-200token的小chunk，确保实体完整不被拆分
• 增加chunk间的重叠度（比如20%），避免上下文断裂；同时给每个chunk添加来源信息（如“来自XX文档第3页”），方便后续校验

3. 混合检索强化 #

针对短查询关键词明确的特点，强化稀疏检索的作用：

• 用BM25和稠密向量检索结果加权融合（比如BM25占40%权重），BM25能精准匹配关键词，弥补稠密向量对短文本语义捕捉的不足
• 增加实体检索分支：先识别查询中的实体（如公司名、产品型号），直接从知识库的实体索引中提取对应信息，再和向量检索结果合并

4. 检索结果重排序 #

用Cross-Encoder对初检索的10-15个chunk做重排序，直接计算查询与chunk的语义相似度，过滤掉低相关结果，只保留前3-5个最精准的chunk注入提示词，减少噪音干扰

5. 提示词约束优化 #

在系统提示词中明确规则：

• 优先使用知识库中的精确信息，禁止编造内容；如果检索不到匹配结果，直接告知用户“暂无相关信息”
• 把检索到的chunk按相关性标注优先级，比如“【核心参考】：XXX；【次要参考】：XXX”，引导AI优先调用核心信息

二、实时语音检索的流水线与架构设计 #

1. 流式转写的触发逻辑 #

利用Deepgram的流式转写能力，不要等完整句子结束再检索：

• 设置触发阈值：当转写内容达到5个词以上，或检测到语音停顿（Deepgram的endpointing功能）时，立即启动检索
• 维护会话上下文窗口：每次检索时，把当前转写片段和最近3轮对话历史拼接成查询，避免孤立查询的偏差

2. 低延迟检索流水线 #

打造毫秒级响应的检索流程：

• 前置元数据过滤：每次检索先指定当前通话的客户ID，只检索该客户的专属知识库，大幅减少检索范围
• 增量检索缓存：如果对话围绕同一主题（如用户连续问产品价格），缓存之前的检索结果，后续查询只补充增量内容，不用全量检索
• 异步解耦：把检索任务放到异步队列（如Celery），语音转写和生成不阻塞检索，当结果返回后更新会话上下文，下次语音生成自动调用最新信息

3. 持续运行的RAG架构 #

针对通话全程的实时检索需求，设计会话级RAG架构：

• 每个通话维护独立的会话上下文：包含对话历史、已检索的知识库片段、用户意图标签，每次转写后先更新上下文再生成查询
• 实时索引同步：如果客户在通话中更新知识库，用Pinecone的实时更新API同步索引，确保检索到最新内容
• 高频内容边缘缓存：把企业地址、客服电话等高频查询结果缓存到边缘节点，减少Pinecone API调用延迟

4. 容错机制 #

针对流式转写的识别误差，做容错处理：

• 模糊转写暂不检索：如果转写内容置信度低于80%，暂时跳过检索，等后续转写补充完整后再发起
• 不确定信息主动询问：在提示词中引导AI，若检索结果不明确，直接询问用户“您指的是XX吗？”，避免错误回答

内容的提问来源于stack exchange，提问作者Sarthak Sahu