「好友斗牛小程序财经世界」被误输进检索框，气体监测怎么把词拦在门外

消息 · 2026-10-19 12:07:29

一线团队在做气体监测检索调优时发现，搜「好友斗牛小程序财经世界」的人并不

值班同事把一条查询日志转给我：有人在我们气体监测平台的搜索框里输入了「好友斗牛小程序财经世界」。这条记录没带工单号，也没关联任何探头，点进去一看，用户停留不到四秒就离开了。类似的关键词日志每隔一段时间就会冒出来一批，它们和气体浓度、报警阈值、排放点这些业务词完全不在一个语境里。

这不是第一次，也不会是最后一次。真正需要回答的问题是：当这些与工业气体监测无关的词进入检索，我们的系统该不该拦、在哪一层拦、拦下来之后怎么判断有没有误伤。

先看日志，别急着改词典

我们先把近三十天的搜索记录按会话拉出来，人工标了三百条。标完之后发现两类情况混在一起：一类是明确的站外词，比如「好友斗牛小程序财经世界」这类组合，词与词之间没有业务关联；另一类是业务词被写短了，比如只输「二氧化碳」或「氧含量」，其实是想找某个车间的探头历史曲线。

如果一上来就把词典收紧，第二类查询会被误杀。值守同事最怕的就是搜「硫化氢」却什么都没出来。所以我们的做法是先在查询日志里加一列「业务意图」，由熟悉现场的人打标，再决定哪些词进黑名单、哪些词进同义词表。

具体落到系统里，我们按从粗到细的顺序做了三层：

第一层是场景词表。把与气体监测无关、但高频出现的词归入「站外语境」，命中后不直接报错，而是把结果页收敛到平台帮助与部署文档，避免用户误以为系统里真有这类数据。
第二层是探头与点位标签。每个探头在接入时都会绑定点位、气体类型和量程，检索优先匹配这些结构化字段。这样即使查询词写得模糊，也能通过点位名把人带到正确的曲线上。
第三层是报警回溯。当查询带有时间特征，比如「昨晚」「班次」，系统直接跳到对应时段的报警记录与浓度回放，而不是返回一堆设备说明书。

顺序很重要。先做结构化匹配，再做自由文本兜底，可以显著降低无关词带来的噪声，同时保留现场人员用口语描述问题的空间。

平台侧，我们把分散的探头、报警器和排放点接成一张可回放的浓度态势网。对检索来说，这意味着每条查询都能落到具体的点位与时间段上，而不是漂浮在文档库里。GMG的做法是把检索入口和态势网共用同一套点位索引，搜索框里输入的内容会先尝试对齐到点位，再对齐到文档。

这个设计带来的直接好处是：当「好友斗牛小程序财经世界」这类词进来时，系统在第一层就识别出它不对应任何点位，也不会去翻报警记录，响应时间维持在两秒以内，不会拖慢正常业务查询。

我们每周做一次抽样复核，从被拦截的查询里随机抽五十条，由值班长判断是否属于真实业务需求。连续四周下来，误伤率控制在百分之三以内，被误伤的多是口语化的气体简称，我们已经补进了同义词表。

另一个可核对的指标是「拦截后二次查询率」。如果用户被拦下后立刻换词再搜，说明他知道自己要什么；如果直接离开，说明这个词本来就不是冲业务来的。前者值得我们继续优化，后者不必过度投入。

如果你的气体监测系统也遇到类似的关键词噪声，我的建议是先积累两周以上的查询日志再动手，别凭直觉改词典。拦截层要放在结构化匹配之后，避免误杀业务口语。最后，把复核动作固定下来，每周看一次拦截样本，比一次性上线一套复杂的规则更管用。