大模型Agent在半导体工厂知识库问答中的实战 ——从RAG到自主决策的跨越

大家好，我是老王，在某Fab干了8年IT和智能化落地。2023年我们开始折腾RAG知识库，2024年切到Agent架构，这中间踩的坑能写一本书。今天就把我们从零到生产级部署的完整踩坑经历分享出来，全是真实数据，不吹不黑。如果你在半导体行业做智能化，这篇一定对你有用。

一、问题背景：为什么半导体工厂的知识问答这么难？

半导体Fab是个知识密集型场景，工艺参数、设备手册、SPC规则、良率分析报告……加起来一个中等规模的Fab就有几十万份文档。工程师找答案的方式，要么靠记忆，要么靠翻文档，平均一个工艺工程师每天要花2小时在找答案上。

2023年我们上了第一版RAG系统，上线第一周准确率只有62%，工程师的反馈是'还不如我自己找'。当时我们团队都很沮丧，觉得是不是方向错了。后来深入分析才发现，问题出在Fab场景的特殊性上。

1.1 知识碎片化：跨系统检索的噩梦

Fab的知识分布在至少7个核心系统里：PMS（工艺管理系统）存工艺参数，MES（制造执行系统）存工单和设备状态，EqMS（设备管理系统）存设备日志，SPC系统存统计过程控制数据，eRFP系统存良率报告，还有大量PDF格式的设备手册和作业指导书。这些系统彼此独立，没有统一的知识入口。传统RAG只能单库检索，根本无法串联查询。

1.2 上下文窗口不够：长文档被截断的痛苦

良率分析报告是重灾区。一份完整的良率异常分析报告，动辄40-60页，包含WAT数据、SEM照片、故障树分析、历史对比……传统RAG系统的向量检索把文档切成512 token的小块，截断后答案支离破碎。有次工程师问'关于光刻机对准偏差的完整分析'，Agent调出来的内容是不相关的两段话，完全没有连贯性。

1.3 无法执行操作：查到答案还得手动操作

这是RAG最致命的局限。工程师问'光刻机对准偏差调整方法'，RAG能检索到SOP文档，但接下来呢？还得人工去系统里查设备编号、调参数、下工单。知识问答和实际操作之间隔着一道鸿沟。RAG本质是个增强版搜索引擎，它只能告诉你'是什么'，无法帮你执行'做什么'。

我们统计过，一个完整的设备异常处理流程，RAG能覆盖的环节只有约35%，剩下65%需要人工介入。这直接导致了工程师的抵触情绪——'花里胡哨整了一套，用起来还得我动手'。

正是因为这些痛点，我们才决定从RAG全面升级到Agent架构。目标很明确：不只是告诉工程师答案，而是帮助工程师完成整个问题解决闭环。

二、技术原理：从RAG到Agent的架构演进与核心机制

2.1 RAG架构的三个硬伤

先说清楚RAG为什么在Fab场景不够用。RAG（Retrieval-Augmented Generation）的标准流程是：用户query → 向量检索 → top-k相关文档 → 拼接prompt → LLM生成回答。这套架构在通用问答（法律、医疗、教育）上表现不错，但在Fab场景有三个结构性缺陷：

检索质量差：Fab的专业术语（Teflon、TEOS、STI、CMP、ECD等）用通用Embedding模型（如text-embedding-ada-002）很难精准匹配。'CMP浆料更换周期'和'化学机械平坦化耗材管理'是同一个意思，但通用模型识别不出来

缺乏多跳推理：设备故障分析需要串联多个数据源（设备日志+工艺参数+历史维修记录+良率数据），RAG单次检索只能覆盖一个数据源，无法做跨系统关联分析

无法工具调用：Fab系统多（KLA AIT、Applied Materials Endura、SEMulator3D、MES等），RAG无法主动调用API获取实时数据，只能回答静态文档里的问题

2.2 Agent架构的核心理念：ReAct循环

我们采用的Agent架构基于LangChain的ReAct模式（Reasoning + Acting），核心改进是：Agent不再只做检索，而是进入一个循环：

Thought（思考）：分析用户问题，决定下一步行动

Action（行动）：调用工具（查文档/查数据/执行操作）

Observation（观察）：接收工具返回结果

循环直到有足够信息生成最终答案

这个循环解决了RAG的单次限制问题。比如用户问'最近3天CVD设备的温度漂移导致良率下降，我该怎么调？'，Agent会先调用SPC数据工具查良率趋势，再调用设备状态工具查温度记录，再调用工艺文档工具查标准参数范围，最后综合所有信息给出分析和建议。

2.3 工具注册与编排：17个自定义Fab工具

工具封装是Agent落地的关键环节。我们用LangChain的@tool装饰器注册了17个Fab专用工具，按功能分为三类：

数据查询类：get_equipment_status（设备状态）、query_spc_data（SPC数据）、query_mes_data（MES数据）、query_wat_data（良率数据）

知识检索类：retrieve_process_doc（工艺文档）、retrieve_equipment_manual（设备手册）、retrieve_spc_rule（SPC规则）、retrieve_maintenance_log（维修记录）

操作执行类：generate_maintenance_ticket（生成维修工单）、create_lot_hold（批次Hold）、send_notification（发送通知）

工具封装的精髓在于描述（description）字段的撰写。Fab工程师不会说'帮我调用query_spc_data'，他们会说'我想看看最近光刻段的良率趋势'。所以每个工具都配了自然语言描述，让Agent能理解什么时候该调用、调用参数是什么。描述写得好不好，直接决定Agent的意图识别准确率。

2.4 向量数据库选型：我们为什么选Milvus

我们测试了Chroma（轻量级）、Pinecone（云托管）和Milvus（开源分布式）三种方案，最终选了Milvus集群版，主要基于以下考量：

Fab知识库总量超过50万条向量，Milvus的分布式查询性能最优，QPS比Chroma高3倍以上

支持混合检索（向量相似度+BM25关键词权重），对专业术语的召回率提升明显（约+15%）

支持TTL和数据版本管理，工艺文档定期更新场景下无需重建索引

运维友好，提供K8s Operator，一行命令扩容，不影响生产服务

成本可控：开源免费，硬件自建，总拥有成本比Pinecone低80%

三、实战案例：光刻段良率异常Agent诊断全流程