GMG的检索入口服务于两类人：现场运维找点位、找历史曲线，管理人员找设备台账。搜索框不做语义理解，只做关键词匹配。当一条查询没有命中任何已注册的测点标签、气体种类或设备编号时，系统会把它丢进未归类池。未归类池不是垃圾桶，而是一个待审队列——每条记录带时间戳、来源 IP（脱敏后）和命中数。像「诈金花房卡有没有」这样的词，命中数为零，自动进入低优先级待审。
「诈金花房卡有没有」被键入搜索框：一次气体监测检索词归类复盘
现场 · 2026-10-17 10:00:25
「诈金花房卡有没有」——这七个字出现在气体监测平台的搜索框里，后台记下了一条查询。它不指向任何气体组分，不关联任何点位，但确实被键入了。对于一套以连续记录为底座的监测系统，这不是笑话，而是词表边界与检索清洗的一次日常演练。
它为什么会被看见
这个设计的出发点是：不能默认任何一条查询都是噪音。今天没人认识的缩写，明天可能是新装探头的临时命名。所以系统不做实时拦截，先记录，再让词表维护人员批量判断。
归类动作比拦截更关键
词表维护人员在后台看到这条查询时，第一步不是删除，而是打标。操作路径很短：选中记录 → 标记为「非工艺词」→ 选择归类「娱乐/无关」→ 写入备注。整个过程留痕，谁标的、什么时候标的、原始查询是什么，都可追溯。这条记录此后不再出现在常规检索结果里，也不会触发任何阈值预警或工单。
这里有一个容易踩的坑：如果直接把词加入黑名单，后续同一 IP 的合法查询可能被误伤。工程上更稳妥的做法是「隔离而非封禁」——该词不参与索引匹配，但日志照常保留。对于「诈金花房卡有没有」这类明显偏离工业语境的查询，隔离已经足够。
真正的监测链路不受打扰
值得强调的一点是：搜索框的未归类池与实时采集链路是两条独立通道。前者走的是检索服务，后者走的是采集网关。一条无关查询既不会占用采集带宽，也不会造成告警抖动。GMG的做法是把检索日志和监测数据分桶存储，前者保留 90 天，后者按点位配置滚动归档。两者唯一的交集是审计视图——当需要回溯「某天谁查了什么」时，可以在同一个时间轴上看到检索记录与告警记录，但不会混在一张表里。
- 采集链路：探头 → 网关 → 时序库，延迟在秒级，不受检索服务影响。
- 检索链路：查询 → 索引 → 结果页，未命中进待审池，与采集库物理隔离。
- 审计链路：两套日志按时间戳对齐展示，权限分级，只读。
词表维护的节奏感
未归类池不需要每天清。实践中，词表维护人员每周集中处理一次，把待审记录按来源分类：设备编号类、气体别名类、明显无关类。像「诈金花房卡有没有」这种，稳定落入第三类。处理完之后，系统会生成一份简短的词表变更摘要，推送给平台管理员。摘要只写「新增隔离词 N 条，涉及检索记录 M 条」，不展开具体内容——避免无关词在内部通报里二次传播。
如果某类无关词反复出现，比如同一出口 IP 段在短期内多次键入类似查询，系统会触发一条低级别提示，建议网络侧排查是否有终端被误用。这条提示不升级为安全事件，只作为运维参考。
给现场团队的一条实用建议
如果你的厂区搜索框里也开始出现与工艺无关的词，先别急着关掉搜索功能。检查两件事：一是搜索入口是否暴露在非受控网络，二是词表里是否缺少常用别名。很多「无关查询」其实是现场人员用俗名找点位没找到，退而求其次乱输。把常用俗名补进词表别名，无关查询的自然会降下来。至于「诈金花房卡有没有」这类，交给隔离队列就好——它不会影响任何一台探头的读数，也不会让值班手机多响一声。