先判断场景，再决定怎么检索
0次浏览0条评论0个赞
业务问题：同一条产品线下有无线网、云核心网等多条产品线，每条产品内又有不同场景。专业知识到百万级、彼此差异很大 —— 一套固定的检索方式，真能同时伺候这些场景吗？ 做法：按请求带不带「标量信息」分流到标量检索或混合检索，再用「第一索引」把检索范围收敛到对应产品知识包，而不是全库遍历。
现场是什么样
这类产品线里，知识是几百万条分布在多个产品、多个场景的资料，不是一份文档：同一个词在不同产品里含义不同，不同场景关心的「相关知识」也不是一回事。
大语言模型直接答这类问题会出两种事故：幻觉（说得像真的但没依据）和推理过程不可追溯。业界用 RAG（检索增强生成：先检索外部知识，再让模型基于检索结果生成）来缓解，把模型固有知识和外部知识库结合起来 [2]。
但通用 RAG 有一个被默认忽略的环节：检索这一步，通常对所有人都用同一种方式。
领域数据的特点决定了做法
具体到这条产品线，有三个事实让「一种检索方式打天下」不成立：
- 知识规模大：百万级专业知识，全库参与比较，噪声和代价都被放大；
- 场景差异大：标量型问题（比如涉及具体型号、版本、参数这类可精确匹配的字段）和开放式问题，相关性的定义根本不同；
- 同一套排序不可能同时最优：标量场景下，精确匹配结构化字段才是信号；开放场景下，才需要语义相似度参与。
设计：先分流，再收敛范围
框架做两件事：判断场景，以及缩小检索范围 [1]。
图 1 · 场景判定 → 检索方式分流 → 知识包内检索 → 排序取前 p 条（示意图：依据专利公开文本重绘，非原文附图）
- 场景判定：以「请求是否包括标量信息」作为分流依据。包含标量信息 → 判定为标量场景，走标量检索；不包含 → 判定为非标量场景，走混合检索。这样检索策略与场景是匹配的，而不是靠一套参数硬扛。
- 范围收敛：请求带有的「第一索引」用于标识该问题关联的第一知识包。检索在该知识包内进行，而不是在数据库的所有知识包中遍历 —— 直接减少参与比较的知识数量。
- 排序可配置：包内匹配结果按匹配字段数量或相似度排序，取前 p 条知识；哪种更合适由场景决定，而不是写死。
- 兜底：请求不含标量信息、但第一索引落在标量索引表里时，先提示用户补充标量信息，再按标量场景检索。
值得单独说的取舍：标量场景下要主动忽略问题里的冗余描述 —— 既然能用结构化字段精确匹配，额外的自然语言描述只会引入干扰。
图 2 · 全库参与 vs 收敛到命中的知识包（示意图：依据专利公开文本重绘，非原文附图）
结果
- 公开文本给出的效果是定性的：按场景选择相匹配的检索策略，有助于提高检索精度与效率、改善体验。该专利公开文本未披露量化结果 —— 这里不补数字。
- 可核的事实性指标：本发明专利申请 CN 122757434 A，申请号 202510317709.2，申请日 2025-03-14，公布日 2026-09-15，申请人为华为技术有限公司，我为第 1 发明人。
中段小结：可迁移的不是检索算法
到这里可以先说清楚这条路的价值在哪：它的关键在排序之前先决定”这一次该用哪种检索”，而不是换了哪种排序。把”场景判定”独立成一层之后，标量问题与开放问题各自拿到相匹配的策略 —— 检索精度与效率的改善来自这次分流，而不是来自某个更强的模型。
我的部分（如实写）
我是这项专利的第 1 发明人（共同发明人：夏轶轩、严轶康、叶玲），负责检索框架的设计。具体做的是把「场景判定 → 检索方式分流 → 知识包范围收敛 → 排序可配置」这条链路定义清楚，并落到可实施的方案与权利要求里。
结语：这套设计能迁移到哪
判断依据是这三条，而不是「我做过 RAG」：知识库多租户/多产品、查询可以按场景分类、不同场景的相关性定义不同。满足这三条的检索系统，都可以在检索之前加一层「场景分流 + 范围收敛」，再谈排序和生成。
这也是我在这个系列里想说明的递进：模型设计 → 数据处理 → 框架设计 —— 越往后，设计的对象越从「一个模型」变成「一条链路」。
参考文献
[1] 本专利公开文本：一种检索方法及装置（公开号 CN 122757434 A，申请号 202510317709.2，申请日 2025-03-14，公布日 2026-09-15）—— 所述检索框架的来源。专利文献可按公开号在各国专利数据库检索（公开文本未披露量化结果，也未补数字）。
[2] Lewis, P., Perez, E., Piktus, A., Petroni, F., Karpukhin, V., Goyal, N., Küttler, H., Lewis, M., Yih, W., Rocktäschel, T., Riedel, S., & Kiela, D. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS. arXiv:2005.11401：https://arxiv.org/abs/2005.11401（2026-10-11 实测可达）—— 检索增强生成的原始出处。
想聊？
如果你在做企业知识检索、或者正被「一套检索策略伺候所有场景」困住，欢迎邮件聊：[email protected]，或看我的 GitHub。
- 专利公开信息：一种检索方法及装置（公开号 CN 122757434 A，申请号 202510317709.2）——按公开号可在各国专利数据库检索（原 CNKI 摘要链接已失效，故改为耐久标识：专利号不依赖任何站点存活）
- 成果页对应条目：一种检索方法及装置
- 系列前两篇：让模型说清它凭什么判断 · 采样率降 32 倍，故障还看得见吗
评论
填个昵称就能发，不需要注册或登录