用户的query进来之后，第一步做什么？是直接去检索吗？检索之前不需要做任何处理

用户的query进来之后，第一步做什么？是直接去检索吗？检索之前不需要做任何处理

P1 · rag · 🏢 京东

🏷 标签：query-understanding, intent-recognition, entity-extraction

1️⃣ 考察意图

面试官真正想看你是否理解RAG在线系统的“第一公里”——Query预处理不是可选项，而是决定检索质量和最终回答准确性的关键前置环节。考察类型是工程取舍+系统设计，刁钻点在于：很多人以为RAG就是“query→embedding→检索→生成”的流水线，忽略了意图识别、实体抽取、改写扩写等预处理步骤。答好了能展示你对RAG整条链路有实战认知，能区分“玩具Demo”和“工业级系统”的差距，并且有处理模糊查询、多轮对话、长尾query的工程经验。

2️⃣ 标准答

第一步：Query理解模块（非检索）

用户query进来后，绝不直接去检索。先做三层处理：

• 意图识别（Intent Classification）：判断query属于哪类任务。典型分类包括：工程实现上，可以用小模型（如BERT-based分类器）做快速路由，延迟<10ms；也可以用LLM prompt分类，但成本高、延迟大。取舍点：小模型精度有限（约90-95%），但适合高并发；LLM分类精度高（>98%）但单次推理成本高，适合低频或复杂query。实际落地中，混合策略常见：先用小模型过滤明显类别，对置信度<0.7的query再fallback到LLM。知识问答（走RAG检索）
• 计算/推理（走LLM直接生成或工具调用）
• NL2SQL（走数据库查询）
• 拒答/闲聊（直接返回预设回复或拒绝）
• 多轮澄清（需要追问用户） 实体抽取（Entity Extraction）：提取query中的关键实体，用于后续检索的过滤或排序。例如：常用工具：SpaCy、HanLP、BERT-NER，或直接用LLM few-shot抽取。坑：实体歧义（如“苹果”指水果还是品牌），需要结合上下文消歧。解法：维护一个实体词典+规则，对高频歧义实体做硬编码映射。
• 时间实体：“去年双十一” → 解析为具体日期范围
• 产品实体：“iPhone 15 Pro Max” → 映射到标准产品ID
• 属性实体：“性价比高的” → 提取为排序权重 Query改写/扩写（Query Rewriting & Expansion）：处理用户query的模糊性、口语化、省略等问题。典型场景：方法：基于规则的模板（如“它”替换为上一轮实体） + LLM改写（对复杂query）。取舍点：规则改写快但覆盖不全，LLM改写全但慢。实际中，80%的query用规则处理，剩下20%的模糊query走LLM。
• 多轮对话：用户说“它的价格呢？” → 需要结合历史query补全为“iPhone 15 Pro Max的价格是多少？”
• 口语化：“咋样” → 改写为“性能评价如何”
• 同义词替换：“笔记本” → 扩写为“笔记本电脑 便携电脑”

第二步：决定检索策略

预处理完成后，根据意图和实体，选择检索策略：

• 知识问答：用改写后的query做混合检索（BM25+向量检索），实体作为过滤条件
• 计算/推理：跳过检索，直接调用LLM或工具
• NL2SQL：将实体映射为SQL条件，执行数据库查询

实际落地的坑 + 解法：

• 坑1：用户query包含错别字（如“苹里手机”），直接检索召回率极低。解法：在预处理阶段加入拼写纠错（如基于编辑距离的词典匹配或小模型纠错）。
• 坑2：query太短（如“价格”），意图不明确。解法：设置query长度阈值，<3个字的query触发追问或返回热门FAQ。
• 坑3：多轮对话中实体指代错误（如用户说“那个红色的”，但上一轮没有红色实体）。解法：维护对话状态跟踪，对未匹配的指代做fallback到LLM推理。

总结：RAG在线流程的第一步是Query理解，而非检索。只有经过意图识别、实体抽取、改写扩写，才能确保检索的精准度和效率。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面回答：第一，Query理解模块，包括意图识别（判断走检索、计算还是拒答）、实体抽取（提取时间、产品等关键信息）、Query改写（处理口语化和多轮指代）。第二，根据意图决定检索策略，而不是直接Embedding检索。第三，实际落地中要处理错别字、短query、多轮指代等坑。总结一句：RAG的第一步是预处理，不是检索，预处理质量直接决定检索效果。”

4️⃣ 高频追问 & 应对

追问 1：如果用户query是“帮我查一下去年双十一的销量”，你怎么处理实体抽取？

首先，用NER模型提取时间实体“去年双十一”，然后通过时间解析器（如dateparser或自定义规则）将“去年”映射为当前年份减1，“双十一”映射为11月11日。如果用户query是“去年双十一期间”，需要解析为时间范围（11月1日-11月11日）。取舍点：时间解析规则复杂，覆盖不全时，可以用LLM做时间实体标准化，但延迟高。实际中，高频时间模式（如“去年”“上个月”）用规则，低频复杂时间（如“2023年第三季度”）用LLM。

追问 2：意图识别中，如果query既像知识问答又像计算（如“2023年GDP增长率是多少”），你怎么路由？

这种query属于混合意图。我的做法是：先尝试走知识问答（检索文档），如果检索结果置信度低（如top-1得分<0.6），再fallback到计算（让LLM直接生成或调用计算器）。取舍点：先检索后计算增加了延迟，但能保证优先使用知识库中的权威数据。另一种策略是并行处理：同时走检索和计算，取置信度高的结果，但成本翻倍。实际中，根据业务场景选择：对时效性要求高的场景（如金融数据），优先走计算；对权威性要求高的场景（如法律条文），优先走检索。

追问 3：Query改写时，怎么避免改写后语义偏离？

核心是改写后验证。改写后，用语义相似度模型（如Sentence-BERT）计算原query和改写后query的余弦相似度，低于阈值（如0.8）则拒绝改写，使用原query。另外，改写策略要保守：对多轮指代，只替换代词；对口语化，只做同义词替换，不做大幅重写。坑：LLM改写容易过度发挥，比如把“咋样”改成“性能评价如何”没问题，但改成“请详细分析该产品的性能指标”就偏离了。解法：限制改写长度（不超过原query的1.5倍），并只允许替换/补全，不允许删除。

5️⃣ 避坑 · 常见错误答法

• ❌ “用户query进来后，直接做向量化然后检索，不需要预处理。”→ ✅ “必须做预处理，包括意图识别、实体抽取、改写扩写。直接检索会导致模糊query召回率低、多轮对话无法处理、实体歧义等问题。”
• ❌ “预处理用LLM做意图识别和实体抽取就够了，不需要规则。”→ ✅ “LLM精度高但延迟大、成本高。实际中采用混合策略：80%的query用规则/小模型处理，20%的复杂query用LLM，平衡精度和效率。”
• ❌ “Query改写就是把query扩写成长句，越多越好。”→ ✅ “改写要保守，避免语义偏离。改写后需验证相似度，且只做替换/补全，不做大幅重写。扩写过多会引入噪声，降低检索精度。”

6️⃣ 简历呼应

• 如果你有RAG项目：从“Query理解模块”切入，强调你实现了意图分类（如用BERT分类器）和实体抽取（如用SpaCy），并设计了路由逻辑。可以提你处理过多轮对话中的指代问题，用规则+LLM改写。
• 如果你只做过传统NLP：用“文本分类+序列标注”类比，说你熟悉意图识别（分类任务）和实体抽取（序列标注任务），可以迁移到RAG预处理。强调你对规则和模型混合策略的理解。
• 如果你是校招无项目：聚焦“论文复现”，说你读过《Query Rewriting for Retrieval-Augmented Generation》等论文，并实现过基于BERT的意图分类Demo。可以提你理解预处理对检索质量的影响，并做过消融实验。
• 《Query Rewriting for Retrieval-Augmented Generation: A Survey》
• 《Intent Classification and Entity Extraction for Conversational AI》
• 《Hybrid Retrieval: Combining Sparse and Dense Methods》
• 《RAG: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》
• 《SpaCy vs BERT-NER: Trade-offs in Entity Extraction for Production》