如果用户的问题本身就不适合检索正确文档压根没进候选集该怎么办真实用户不会像测试工程师一样提问。知识库里的标题可能是《企业版 macOS 客户端单点登录故障处理》用户只会丢下一句那苹果电脑呢如果直接把这句话做 Embedding检索器看到的只有“苹果电脑”。上一轮在聊什么、用户遇到什么故障、产品是什么它一概不知道。这不是向量数据库突然失灵而是我们把一句不完整的话当成了一条完整查询。查询优化要做的事就是在不改变用户意图的前提下把自然对话转换成更适合检索的表达。常见方法有三种Query Rewrite把问题改写完整Multi-Query从多个角度表达同一需求HyDE先生成一段“假设答案”再用它寻找表达相近的真实文档。它们不是三个越多越好的开关而是针对三类不同问题的工具。一、先看查询为什么会失败生产环境中不适合直接检索的问题大致有下面几类。类型用户原话检索困难多轮指代那企业版呢缺少上一轮主题口语表达一直转圈进不去文档使用“认证超时”缩写别名SSO 咋开文档写“单点登录”复合问题能导出吗失败后怎么补偿两个意图混在一起现象描述升级后以前的数据没了文档按原因和模块组织过度冗长一大段背景加一个真正问题无关词稀释检索信号先不要急着上复杂方案。把线上失败查询按这些类型分桶你会更容易判断该用哪种方法。查询失败与对应策略二、Query Rewrite把对话变成独立查询Query Rewrite 最适合处理指代、口语、错别字和上下文缺失。例如对话是用户Windows 客户端出现 1007 错误怎么处理助手可以先关闭代理并清理缓存。用户那 Mac 呢用于检索的独立查询应该是macOS 客户端出现 ERR_CONN_RESET_1007 时如何处理关键在“独立”两个字。检索查询离开聊天记录后仍然应该让人看得懂。一个可控的改写 Prompt你是企业知识库的查询改写器。任务结合对话历史将用户最后一个问题改写为一条独立、可检索的查询。规则1. 保留产品、平台、版本、错误码、时间等已知实体。2. 只补全对话中已经出现的信息不猜测缺失条件。3. 不回答问题不提供解决方案。4. 如果原问题已经完整原样返回。5. 只输出改写后的查询。实现时不要把无限长的聊天历史全部塞给模型。通常只保留最近几轮与当前问题相关的消息并把已确认的结构化实体单独保存。def build_rewrite_input(history, current_query, known_entities): return { recent_history: history[-6:], current_query: current_query, known_entities: known_entities, }改写最大的风险擅自补条件原问题是“企业版怎么导出”模型改成“企业版 Windows 客户端如何导出 PDF”看起来更完整实际上凭空增加了 Windows 和 PDF。这会让检索结果更精确地走向错误方向。生产环境建议做三层保护同时保留original_query和rewritten_query抽取两者的实体检查产品、版本、金额、日期等关键字段是否被篡改对高风险场景只允许消歧和补全不允许自由扩写。三、Multi-Query别把希望押在一种说法上同一个问题在用户和文档里可能有完全不同的表达。用户问Pod 一直自己重启怎么查知识库可能分别写成CrashLoopBackOff 排查容器进程异常退出存活探针失败OOMKilled 内存溢出。只改写成一句标准问题仍然可能覆盖不全。Multi-Query 会生成几条意图一致、角度不同的查询1. Kubernetes Pod 频繁重启的排查步骤2. CrashLoopBackOff 常见原因及处理方法3. 容器因健康检查失败反复重启如何定位4. Pod OOMKilled 与进程异常退出如何排查每条查询独立检索再把结果合并、去重、RRF 融合最后交给 Reranker。def retrieve_multi_query(queries, retriever, per_query_k10): result_lists [] for query in queries: docs retriever.invoke(query)[:per_query_k] result_lists.append(docs) return reciprocal_rank_fusion(result_lists)这里最重要的不是代码而是约束生成的查询必须覆盖“不同表达”不能偷偷变成“不同问题”。什么场景值得用 Multi-Query术语不统一同一概念有多个别名问题较复杂可能对应多种原因多跳问题需要从不同角度找证据单查询的 Recall 长期上不去。什么场景不值得用错误码、订单号、API 名称等精确查询原问题已经非常明确对延迟极其敏感知识库很小单路召回已经稳定命中。生成 5 条查询往往意味着更多检索、更多候选和更多 Rerank 开销。它应该由评测结果触发而不是默认给每个问题都上。四、HyDE用“答案的样子”去找答案HyDE 全称是 Hypothetical Document Embeddings。名字听起来很复杂思路其实很直白让大模型根据问题写一段可能的答案不把这段内容当真只对它做 Embedding用这个向量去找表达方式相近的真实文档。问题升级后历史数据看不到了怎么办 ↓假设文档升级后若历史数据暂不可见应检查数据迁移任务、索引重建状态和租户映射并确认旧版本数据是否完成同步…… ↓ Embedding检索真实的升级迁移与索引重建文档为什么这可能有效因为短问题和正式文档在语言形态上差别很大。假设答案更像知识库正文向量空间里可能更容易靠近真正的说明文档。HyDE 的安全边界那段假设答案可能包含幻觉。它只能是检索桥梁绝不能直接作为最终回答也不能作为可靠证据写入日志之外的业务流程。def hyde_retrieve(question, llm, vector_store, k20): hypothetical_doc llm.invoke( 请为下面的问题生成一段可能出现在技术手册中的说明。 内容仅用于检索不要求事实正确不要添加具体版本和数值。\n f问题{question} ).content return vector_store.similarity_search(hypothetical_doc, kk)HyDE 更适合概念解释、故障现象、研究资料等“问题短、文档长”的场景。对于合同编号、政策日期、产品型号等精确查询BM25 和 Metadata Filter 通常更直接。五、三种方法到底怎么选可以用下面的路由思路问题是否依赖对话或表达不完整 是 → Query Rewrite 否 ↓问题是否存在多种叫法或多个检索角度 是 → Multi-Query 否 ↓问题很短且与长文档表达差距明显 是 → HyDE 否 → 原查询直接检索实际系统也可以组合但建议逐步增加方案LLM 调用检索次数主要收益主要风险原查询01快口语查询召回差Rewrite112补全意图改变原意Multi-Query135扩大覆盖延迟、噪声增加HyDE112缩小问答表达鸿沟假设内容带偏一个实用技巧是**原始查询不要丢。**即使启用了 Rewrite 或 HyDE也可以让原查询保留一路召回再通过融合和 Rerank 决定最终结果。这相当于给查询优化加了一条保险绳。六、如何评测查询优化而不是只看几个 Demo继续使用前面建立的固定评测集但这次多记录几项数据{ original_query: 那苹果电脑呢, rewritten_query: macOS 客户端出现 1007 错误时如何处理, generated_queries: [..., ...], strategy: rewritemulti_query, retrieved_chunk_ids: [doc-42#3, doc-19#7], latency_ms: 486 }重点看RecallK 是否真的提高正确文档的首个排名是否前移改写后的实体是否忠于原问题不同查询返回的结果是否高度重复最终答案是否改善P95 延迟和单次成本增加多少。建议把评测集按multi_turn、colloquial、acronym、multi_intent、exact_match等类型分桶。总体分数上涨不代表每类问题都适合查询扩展。一个值得单独统计的指标意图保持率随机抽样改写结果让人工或可靠 Judge 判断改写是否保留原意A. 完全一致B. 基本一致但有无害补充C. 增加了未经确认的条件D. 改变了问题查询优化如果让 Recall 上涨 5%却有 3% 的查询被改错在财务、法务和权限场景中可能完全不值得。七、生产落地最容易踩的坑把三种方法全部默认开启链路看起来很高级延迟和故障点也一起增加。先用失败类型路由简单问题直接检索。让模型补全用户没说过的信息改写器的任务是整理不是脑补。缺失的关键条件应该追问用户。Multi-Query 生成同义句凑数“如何处理”“怎么解决”“解决办法是什么”只是换了语序没有增加召回覆盖。应该要求每条查询覆盖不同术语或原因角度。把 HyDE 文本当作事实HyDE 输出只能用于检索。最终回答必须引用真实知识库文档。只比较最终答案同时比较原查询、改写查询、每路候选和最终排名否则无法知道提升来自哪里。总结查询优化解决的是“用户怎么问”和“文档怎么写”之间的距离。Query Rewrite 补全语境Multi-Query 扩大表达覆盖HyDE 用接近文档的语言寻找文档。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】