项目知识点汇总解答)
1. 关于 HyDE (Hypothetical Document Embeddings)在实际业务中发现一个典型问题：用户提问往往很简短或模糊，而知识库里的文档通常很长且专业,这导致用户的Query和文档在向量空间里距离很远，直接检索召回率很低“为了解决这个问题，引入了HyDE（假设性文档嵌入）技术,它的核心逻辑是：既然用户的问题太短，那就让大模型先‘幻想’一篇包含答案的文档,比如用户问‘感冒了吃什么药？’，不直接拿这句话去搜，而是让LLM生成一段类似‘感冒通常建议服用复方氨酚烷胺...’的假设性文本为什么要这么做？因为这篇‘假文档’在语义空间和词汇分布上，跟要找的真实知识文档是非常接近的,用这个‘假文档’去做向量检索，能极大地拉近Query和Document的距离落地效果：在场景中，特别是针对那些描述不清的咨询，HyDE把Top-5的召回率提升了约20%，解决了很多以前搜不到的长尾问题缺点是什么？会增加一次LLM调用的延迟（Latency）怎么优化？只对识别为“模糊/复杂”的问题开启HyDE，简单问题直接搜，以此平衡速度和精度HyDE 生成的假设性文档如果不准确，会不会带偏检索结果？确实存在这个风险，如果大模型‘幻觉’生成了错误的假设文档，用它去检索确实会找错方向为了规避这个问题，在工程上做了一层兜底与融合机制:首先，HyDE 并不是对所有问题都开启，只对意图识别为‘模糊描述’或‘长尾复杂问题’时才触发,其次，在检索结果融合时，不是只用 HyDE 生成的向量，而是将HyDE 向量与原始 Query 向量分别去检索，然后通过RRF 算法进行加权融合,这样即使 HyDE 跑偏了，原始 Query 的检索结果依然能保底至于子查询分解，使用了 Few-shot Prompting（少样本提示），给大模型几个拆解优秀的例子让它模仿，实测下来拆解的准确率很高，有效解决了多跳推理的问题2. 关于 子问题拆解 (Query Decomposition / Sub-query)遇到很多复合性问题，比如‘A药和B药有什么区别，哪个副作用更小？’,这种问题如果直接扔给检索器，很容易只搜到A或只搜到B，或者搜到的内容不全面，导致大模型回答缺失”针对这种复杂逻辑，设计了子问题拆解（Query Decomposition）策略:具体做法是：利用LLM的推理能力，先把一个复杂的大问题拆解成几个独立的原子问题,比如刚才那个例子，会把它拆成：1. ‘A药的副作用是什么？’ 2. ‘B药的副作用是什么？’ 3. ‘A药和B药的区别’然后并行检索：拿着这三个子问题分别去向量库里搜，把搜回来的所有相关片段聚合在一起，再喂给大模型进行最终的综合回答价值点：这相当于把‘一道难题’变成了‘三道填空题’，保证了上下文的完整性,虽然增加了一点计算开销，但彻底解决了多跳推理和对比类问题的回答质量，大大减少了模型‘一本正经胡说八道’的情况怎么保证拆解是对的？使用了Few-shot Prompting（少样本提示），给模型几个拆解优秀的例子，让它模仿着拆，准确率很高如果拆错了怎么办？有兜底机制，如果子问题检索结果为空，会回退到用原问题检索3.描述RAG从接收query到返回答案的完整流程请描述用户发起查询后，RAG从接收query到返回答案的完整流程，并说明FAQ模块与RAG模块的切换条件、Redis/MySQL/Milvus各自职责，以及为何采用「FAQ优先+RAG兜底」(1).用户查询处理全流程解析当用户发起一个Query时，系统并非直接丢给大模型，而是经过了一个漏斗式的分级处理流程,整个链路分为四个核心阶段：1). 前置拦截与意图路由动作：Query首先进入意图识别模块（基于微调的BERT-base-chinese）目的：判断用户是想闲聊、查固定FAQ，还是进行复杂的医疗咨询分流：闲聊/通用知识：直接由LLM响应，不走知识库高频/明确问题：进入FAQ精准匹配通道复杂/长尾问题：进入RAG深度检索通道关于“意图识别与动态路由”前置 BERT 分类器是怎么训练的？如果用户问了一个既像 FAQ 又像 RAG 的问题，系统怎么判断？在意图识别这块，没有直接用大模型做分类，因为大模型做分类延迟高且成本贵,采用了微调后的 BERT-base-chinese作为前置分类器关于训练:从历史客服日志中提取了数万条真实 Query，由领域专家进行了清洗和标注，最终构建了包含 20 多个意图类别的语料库进行Fine-tuning，F1-score达到了 0.93 以上关于边界模糊的问题:设计了一个置信度阈值（Threshold）机制,如果 BERT 输出的最高类别置信度低于 0.8，或者多个类别得分非常接近，系统不会盲目猜测，而是默认走 RAG 链路，或者触发澄清话术引导用户补充信息,这种‘宁可慢一点，绝不答错’的策略，在场景下是非常必要的2). FAQ 精准匹配通道 (Fast Path)这是为了应对高并发和简单问题的“快车道”
【AI大模型应用开发】【项目实战】26.RAG智慧问答项目-(十四)项目知识点汇总解答
发布时间：2026/7/27 19:26:09
1. 关于 HyDE (Hypothetical Document Embeddings)在实际业务中发现一个典型问题：用户提问往往很简短或模糊，而知识库里的文档通常很长且专业,这导致用户的Query和文档在向量空间里距离很远，直接检索召回率很低“为了解决这个问题，引入了HyDE（假设性文档嵌入）技术,它的核心逻辑是：既然用户的问题太短，那就让大模型先‘幻想’一篇包含答案的文档,比如用户问‘感冒了吃什么药？’，不直接拿这句话去搜，而是让LLM生成一段类似‘感冒通常建议服用复方氨酚烷胺...’的假设性文本为什么要这么做？因为这篇‘假文档’在语义空间和词汇分布上，跟要找的真实知识文档是非常接近的,用这个‘假文档’去做向量检索，能极大地拉近Query和Document的距离落地效果：在场景中，特别是针对那些描述不清的咨询，HyDE把Top-5的召回率提升了约20%，解决了很多以前搜不到的长尾问题缺点是什么？会增加一次LLM调用的延迟（Latency）怎么优化？只对识别为“模糊/复杂”的问题开启HyDE，简单问题直接搜，以此平衡速度和精度HyDE 生成的假设性文档如果不准确，会不会带偏检索结果？确实存在这个风险，如果大模型‘幻觉’生成了错误的假设文档，用它去检索确实会找错方向为了规避这个问题，在工程上做了一层兜底与融合机制:首先，HyDE 并不是对所有问题都开启，只对意图识别为‘模糊描述’或‘长尾复杂问题’时才触发,其次，在检索结果融合时，不是只用 HyDE 生成的向量，而是将HyDE 向量与原始 Query 向量分别去检索，然后通过RRF 算法进行加权融合,这样即使 HyDE 跑偏了，原始 Query 的检索结果依然能保底至于子查询分解，使用了 Few-shot Prompting（少样本提示），给大模型几个拆解优秀的例子让它模仿，实测下来拆解的准确率很高，有效解决了多跳推理的问题2. 关于 子问题拆解 (Query Decomposition / Sub-query)遇到很多复合性问题，比如‘A药和B药有什么区别，哪个副作用更小？’,这种问题如果直接扔给检索器，很容易只搜到A或只搜到B，或者搜到的内容不全面，导致大模型回答缺失”针对这种复杂逻辑，设计了子问题拆解（Query Decomposition）策略:具体做法是：利用LLM的推理能力，先把一个复杂的大问题拆解成几个独立的原子问题,比如刚才那个例子，会把它拆成：1. ‘A药的副作用是什么？’ 2. ‘B药的副作用是什么？’ 3. ‘A药和B药的区别’然后并行检索：拿着这三个子问题分别去向量库里搜，把搜回来的所有相关片段聚合在一起，再喂给大模型进行最终的综合回答价值点：这相当于把‘一道难题’变成了‘三道填空题’，保证了上下文的完整性,虽然增加了一点计算开销，但彻底解决了多跳推理和对比类问题的回答质量，大大减少了模型‘一本正经胡说八道’的情况怎么保证拆解是对的？使用了Few-shot Prompting（少样本提示），给模型几个拆解优秀的例子，让它模仿着拆，准确率很高如果拆错了怎么办？有兜底机制，如果子问题检索结果为空，会回退到用原问题检索3.描述RAG从接收query到返回答案的完整流程请描述用户发起查询后，RAG从接收query到返回答案的完整流程，并说明FAQ模块与RAG模块的切换条件、Redis/MySQL/Milvus各自职责，以及为何采用「FAQ优先+RAG兜底」(1).用户查询处理全流程解析当用户发起一个Query时，系统并非直接丢给大模型，而是经过了一个漏斗式的分级处理流程,整个链路分为四个核心阶段：1). 前置拦截与意图路由动作：Query首先进入意图识别模块（基于微调的BERT-base-chinese）目的：判断用户是想闲聊、查固定FAQ，还是进行复杂的医疗咨询分流：闲聊/通用知识：直接由LLM响应，不走知识库高频/明确问题：进入FAQ精准匹配通道复杂/长尾问题：进入RAG深度检索通道关于“意图识别与动态路由”前置 BERT 分类器是怎么训练的？如果用户问了一个既像 FAQ 又像 RAG 的问题，系统怎么判断？在意图识别这块，没有直接用大模型做分类，因为大模型做分类延迟高且成本贵,采用了微调后的 BERT-base-chinese作为前置分类器关于训练:从历史客服日志中提取了数万条真实 Query，由领域专家进行了清洗和标注，最终构建了包含 20 多个意图类别的语料库进行Fine-tuning，F1-score达到了 0.93 以上关于边界模糊的问题:设计了一个置信度阈值（Threshold）机制,如果 BERT 输出的最高类别置信度低于 0.8，或者多个类别得分非常接近，系统不会盲目猜测，而是默认走 RAG 链路，或者触发澄清话术引导用户补充信息,这种‘宁可慢一点，绝不答错’的策略，在场景下是非常必要的2). FAQ 精准匹配通道 (Fast Path)这是为了应对高并发和简单问题的“快车道”
