从理论到实践：半导体晶圆厂运维助手的工业级AI意图识别分层漏斗架构

从理论到实践：半导体晶圆厂运维助手的工业级AI意图识别分层漏斗架构需要先看清适用场景和关键步骤，避免只记结论却忽略实际限制。

一、背景：为什么我们需要分层漏斗？

在 AI 落地的真实场景中，我们常常面临两个极端：

纯规则方案：维护成本高、规则容易冲突，面对语义变化时束手无策。纯大模型方案：延迟高、成本昂贵、输出不稳定，连"谢谢"都要调用一次 GPU。

真正优秀的架构师，不是把所有请求都交给最强大的模型，而是知道哪些请求根本不需要大模型。

分层漏斗架构的核心思想就是：像医院分诊一样，按请求复杂度分配算力资源。规则层拦截高频固定意图（毫秒级），上下文层处理多轮对话依赖（百毫秒级），RAG 层应对专业知识查询（秒级），仅有极少数边缘情况落入大模型兜底层。

下文会以半导体晶圆厂（FAB）运维助手为场景，介绍一个基于 Flask + Modular RAG 的 MVP 实现，展示如何将这一思想落地为可运行的系统。

二、半导体晶圆厂场景的特殊性

半导体制造对环境、设备、工艺的要求极高，运维人员经常需要查询：

设备状态（“3号炉管温度多少？”）工艺参数（“光刻胶厚度标准是多少？”）故障处理（“设备报错E123怎么办？”）良率分析（“最近三天良率下降的原因？”）

这些请求中，70%以上是高频固定意图（如"帮助"“设备状态”“报错”），可以直接用规则层拦截；约20%涉及上下文依赖（如"那湿度呢？"需要结合上一轮的对象）；不到10%需要专业知识库检索或复杂分析。分层漏斗恰好匹配这种流量分布。

三、架构设计：四层漏斗逐级过滤

我们的 MVP 在原有三层基础上增加了 RAG 层，形成更精细的四层漏斗：

1. 规则层（Rule Layer）

技术：正则表达式、关键词匹配（Trie/AC自动机可选）拦截意图：help、status、report_fault 等固定短语性能：< 1ms，置信度 1.0治理：准入评估、冲突检测、规则下沉（代码中通过配置列表实现）

# rule_layer.py 核心逻辑RULES =[(r'b帮助b|bhelpb','help'),(r'b设备状态b|b机台状态b','status'),(r'b报警b|b报错b','report_fault'),]defmatch(text):for pattern, intent in RULES:if re.search(pattern, text, re.IGNORECASE):return intent,1.0returnNone,0.0

2. 上下文层（Context Layer）

技术：对话状态跟踪（DST），基于字典维护会话槽位作用：处理指代消解（"那湿度呢？“→ 复用上一轮提到的"3号炉管”）性能：~1ms，置信度 0.85防污染：显式重置、超时重置、历史权重衰减

# context_layer.py 简化版classContextTracker:def__init__(self):self.sessions ={}# session_id -> {history, slots}defupdate(self, session_id, user_input, intent=None):session = self.sessions.setdefault(session_id,{'history':[],'slots':{}})# 根据当前输入和历史槽位推断意图...

3. RAG 层（Retrieval-Augmented Generation）

技术：Modular RAG，四个独立模块流程：Query Rewriter → Retriever → Reranker → Answer Synthesizer知识库：设备操作手册、工艺指南（纯文本，内存加载）性能：2-3s，置信度 0.85

每个模块均可独立替换，例如 Retriever 可以从关键词匹配升级为向量数据库，Reranker 可以换成交叉编码器。

4. 兜底层（Fallback Layer）

技术：直接调用 LLM（DeepSeek API），但强制使用 Function Calling作用：处理超出知识库范围的未知请求性能：200-500ms，置信度 0.6

四、代码实现关键点

4.1 Flask 后端

app.py 提供两个路由：

GET /：返回前端页面POST /api/chat：接收 {"session_id":"xxx", "message":"用户输入"}，调用 IntentEngine.process() 返回结果

@app.route('/api/chat', methods=['POST'])defchat():data = request.get_json()result = engine.process(data['message'], data.get('session_id','default'))return jsonify(result)

4.2 分层引擎

IntentEngine 依次调用各层，并记录 trace：

defprocess(self, message, session_id):start = time.time()trace =[]# 规则层intent, conf = rule_layer.match(message)if intent:latency =(time.time()- start)*1000trace.append({"layer":"rule","detail":f"matched {intent}","latency":latency})return build_response("rule", intent, conf, latency, trace)# 上下文层...# RAG层...# 兜底层...

4.3 前端 Trace 可视化

前端使用 Flexbox 布局，左侧聊天区，右侧处理路径面板。每次请求返回后，将 trace 渲染为可折叠的层级卡片，显示每层名称、耗时、命中/跳过原因。效果如下：

┌─────────────────────────────────────────────────────────┐│规则层⏱️ 0.5ms ❌ 跳过││原因：未匹配到规则│├─────────────────────────────────────────────────────────┤│上下文层⏱️ 1.2ms ❌ 跳过││原因：意图不明确│├─────────────────────────────────────────────────────────┤│RAG层 ⏱️ 2350ms✅ 命中││查询改写：良率下降 → 良率管理 故障排查││检索文档：3篇相关文档 ││答案生成：基于知识库生成专业回答 │└─────────────────────────────────────────────────────────┘

界面展示

五、典型对话示例

用户输入	命中层级	响应摘要	耗时
“帮助”	规则层	展示功能列表和使用说明	< 1ms
“设备状态”	规则层	列出所有设备运行状态	< 1ms
“3号炉管温度”	上下文层	返回3号炉管当前温度	~1ms
“那湿度呢？”	上下文层	复用历史槽位，返回3号炉管湿度	~1ms
“良率下降的处理流程是什么？”	RAG层	基于知识库生成四步处理流程	~2-3s
“分析最近三天良率下降的可能原因”	RAG层	检索相关文档，生成分析报告	~2-3s
“今天天气不错”	兜底层	告知超出知识库范围	~200-500ms

六、性能指标

层级	响应时间	置信度	预计拦截流量占比
规则层	< 1ms	1.0	70%
上下文层	~1ms	0.85	20%
RAG层	2-3s	0.85	8%
兜底层	200-500ms	0.6	2%

七、总结与扩展

核心理念

克制与精准的流量调度——不是所有请求都需要大模型，也不是所有规则都能永远生效。分层漏斗的本质是一种成本与效果的帕累托最优。

可扩展方向

向量数据库：将 Retriever 升级为 Milvus/Pinecone，支持语义检索Embedding 模型：替代基于摘要的检索，提升召回率文档上传：允许用户动态添加知识库文档多轮对话增强：引入更复杂的 DST 模型（如 TRADE）实时设备数据：对接 IoT 接口，返回真实传感器读数

八、获取源码

本项目已在 GitHub 开源，欢迎 Star 和 Fork：https://github.com/BumbleBee-ZDS/Intent-Recognition-Hierarchical-Funnel-Architecture

---