工程知识问答为何需要混合检索与意图路由

用户问“某反应器有哪些相关文件”与问“系统里有多少份仪表数据表”，表面上都在查询知识库，实际需要完全不同的执行路径。前者需要实体关联和全文检索，后者应直接聚合数据库。把两类问题都交给向量检索，会让系统在可确定的问题上表现得不确定。

把问题先分流

一个实用的路由器至少区分四类意图：精确定位（位号、文件编号）、事实问答（参数、定义、差异）、统计聚合（数量、分布、缺失项）和任务操作（上传、清理、导出）。路由输出不应只有类别，还应包括提取出的实体、时间范围、专业和置信度。低置信度时可以并行尝试两个低成本路径，再根据证据质量选择结果。

召回要兼顾词与义

工程词汇有大量缩写、位号和规格，它们并不适合只靠 embedding 表示。混合检索的基本组合是：关键词或 BM25 处理精确术语，向量检索弥补表达差异，metadata 过滤缩小对象范围，重排序模型在小候选集中判断最终相关性。位号检索尤其应做规范化，例如统一连字符、大小写和别名，而不是期待模型自动猜对。

证据比答案更重要

回答生成前应保留每个候选的文件名、页码、段落或表格行、匹配方式和分数。最终答案引用可点击的来源，并在证据不足时明确说明“未找到”而非补全。对于同一参数出现多个版本的情况，应该展示版本、日期和冲突，而不是武断合并。

评测从真实问题开始

建立一小批带标准答案和证据来源的问题集，覆盖位号查询、跨文件比较、统计和异常提问。分别观察召回率、证据命中率、答案正确率与延迟，才能知道问题出在解析、索引、路由还是模型。持续把用户确认的正确答案回写为评测样本，系统才会越用越可靠。

混合检索不是多接几个组件，而是承认工程知识同时具有文本、实体和数据三种形态，并让每一种形态走最合适的路径。