FabSage · 晶策：让 LLM 像工艺工程师一样读懂晶圆厂数据 —— 半导体 Fab 数据接入的 Agent 化破局
FabSage · 晶策：让 LLM 像工艺工程师一样读懂晶圆厂数据 —— 半导体 Fab 数据接入的 Agent 化破局
一篇关于「数据考古 + 语义重建 + 智能接入」三层嵌套问题在半导体晶圆厂落地的工程实录。
当全行业都在追逐通用大模型的炫酷 Demo 时，我们选择钻进一座晶圆厂数据库的"暗知识"矿井——数百字段的无注释宽表、隐含在存储过程里的表关系、数十年沉淀却无人问津的历史 SQL。本文记录 FabSage 晶策如何用「元数据分组摘要 + 表关系图谱 + LangGraph 多步 Agent + SOP 知识库」一揽子方案，把 LLM 从"会写 SQL 的鹦鹉"变成"懂工艺的同事"。项目已开源(GitHub: https://github.com/BumbleBee-ZDS/FabSage)。
目录
- 一、为什么晶圆厂数据接入是 Text-to-SQL 的"终极硬骨头"
- 二、研究方法论：三层嵌套问题解构
- 三、FabSage 晶策：从研究方法到工程落地的六阶段演进
- 四、核心创新点深度解析（对应五大研究方向）
- 五、系统架构全景
- 六、划时代意义：为什么这个项目值得被记住
- 七、开源与生态
- 八、写在最后
一、为什么晶圆厂数据接入是 Text-to-SQL 的"终极硬骨头"
半导体晶圆厂（Fab）经营数十年，核心制造数据沉淀在 Oracle 数据库中，呈现三个极端特征。这三个特征，恰好是 Text-to-SQL 学术基准（Spider / WikiSQL）从未真正面对过的"工业地狱"：
| 特征 | 现实情况 | 对 LLM Text-to-SQL 的致命影响 |
|---|---|---|
| 表极宽 | 单表数百字段（量测、工艺、设备参数混杂） | 整表 DDL 远超 LLM 上下文窗口，或被截断导致信息丢失 |
| 字段无注释 | 列名是 thk_ox_top、cd_m1_line、ovl_x_r1 等缩写 |
LLM 不懂缩写语义 → 字段幻觉（编造不存在的列名 / 写错聚合对象） |
| 表关系复杂 | 工艺路线、批次、设备、产品多维关联 | LLM 难以自主推断 JOIN 路径 → 编造 JOIN 条件 |
| 历史 SQL 沉淀 | 数十年积累大量验证过的 SQL | 未被利用——这是工厂最宝贵的"暗知识" |
| 问题多步骤 | 工程师一次提问背后常是「分组 → 找趋势 → 联配方 → 下结论」多步推理 | 单轮 Text-to-SQL 只能出一张表，无法替代分析型脑回路 |
传统做法的失败：把整张宽表 DDL 塞进 Prompt → 上下文溢出 + LLM 仍不懂缩写 → 生成的 SQL 字段名错、聚合对象错、JOIN 错，根本无法执行；更做不了"对比两个产品 + 找最差批次 + 查配方 + 给结论"的组合分析。
业界现有的 Text-to-SQL 方案，要么停留在学术 benchmark 的"窄表 + 英文 + 单跳"舒适区，要么在工业场景里靠"人肉写 Prompt 模板"硬撑，一旦遇到晶圆厂这种"超宽表 + 中文缩写 + 多表关联 + 多步分析"的四重地狱，立刻崩盘。
这就是 FabSage 晶策要解决的问题。
二、研究方法论：三层嵌套问题解构
这个课题的本质是 “数据考古 + 语义重建 + 智能接入” 三层嵌套问题。任何只解决其中一层的方案都是跛脚的：
| 层次 | 问题 | 难点 |
|---|---|---|
| L1 - 数据考古 | 字段含义丢失、关系隐含在存储过程中 | 数十年人员更迭导致"活知识"变"死知识" |
| L2 - 语义重建 | 将隐式关系显式化、构建可被机器理解的语义层 | 数百字段 × 百万行 × 数百表的规模爆炸 |
| L3 - 智能接入 | LLM/Agent 准确生成 SQL、理解查询结果 | Text-to-SQL 在超宽表 + 复杂关联下的准确率 |
对应五大研究方向：
- 基于 SQL 语料库的"数据考古"与字段语义推断 —— 把历史 SQL 当"弱标注数据"，用 AST 解析 + 统计 + LLM 三管齐下推断字段语义。
- 基于 Procedure 解析的多层数据血缘图构建 —— 把存储过程当表间关系的"DNA"，用图（乃至超图）表达多对多数据流转。
- 面向 LLM 的渐进式 Schema 摘要与上下文工程 —— 数百字段不能全塞，需分层摘要 + 按需展开 + 字段组聚类。
- GraphRAG + 历史 SQL 模板的混合检索增强 —— 结构化图谱推理 + 模式匹配双引擎，大幅提升 Text-to-SQL 准确率。
- Agent 多步推理 —— 用"拆解任务 → 查表 → 跑 SQL → 看结果 → 再追问 → 汇总结论"的智能体替代单轮生成。
FabSage 晶策把这五个方向全部工程化落地，分六个阶段递进实现。下面逐一展开。
三、FabSage 晶策：从研究方法到工程落地的六阶段演进
FabSage 的解法是 “先考古、再组装、后生成、再评审、再赋能”，把"全表喂给 LLM"转变为"动态精准喂给 LLM"。演进分六个阶段：
┌───────────────────────────┐ ┌───────────────────────────────┐ ┌──────────────────────────────────────┐
│ 数据考古 (Phase 4 自动化) │ │ 动态上下文组装 (在线) │ │ 生成 + 自我修正 + 评审 + 报告 │
│ Phase 4: SchemaProfiler │ ──► │ Phase 1: 按问题命中字段组 │ ──► │ Phase 3: LangGraph 大循环 │
│ 扫库 + LLM 推断元数据 │ │ Phase 2: 图谱 JOIN 路径推荐 │ │ router→planner→executor→critic │
│ 历史 SQL 沉淀 (飞轮) │ │ 召回历史 SQL 模板 │ │ →[replanner→…]→finalizer │
│ 表关系 / 血缘图谱 │ │ Phase 4: 模板增量沉淀回写 │ │ Phase 4: SqliteSaver 多轮记忆 │
└───────────────────────────┘ └───────────────────────────────┘ └──────────────────────────────────────┘
▲ │
│ ┌───────────────────────────────────────┘
│ ▼
┌─────────────────────────────────────────────┐
│ SOP 知识库 (Phase 6 Agentic RAG) │
│ SOPRetriever: ChromaDB sop_collection │
│ 段落向量检索 (cosine, 复用 SimpleChinese) │
│ SOPLoader: TXT/PDF 按段落切片 (pypdf 降级) │
│ search_sop 工具 → 注入 finalizer Prompt │
│ 「数据洞察」+「操作指引」闭环 │
└─────────────────────────────────────────────┘
Phase 1：动态 Schema 摘要 —— 砍掉 90% 无关字段（对应研究方向三）
核心思想：数百字段不能全塞进 LLM 上下文。把字段聚类成语义组，用户提问时只命中相关组。
实现：
- 元数据分组摘要（数据考古产物）：把几百个缩写字段聚类成语义组（如"氧化膜厚度"“套刻精度”“关键尺寸”），并附中文释义与规格范围（spec_range）。
- 动态 Schema 检索：用户提问时，先判断命中哪个字段组，只返回该组的 DDL + 注释，把上下文从"整张宽表"压缩到"几个相关字段"。
效果：以本项目 Mock 的 25 字段宽表为例，原本 25 字段全塞进 Prompt，现在命中后只注入 2-4 个相关字段，上下文体积下降 80%+，字段幻觉率大幅降低。
Phase 2：表关系图谱 + 自动 JOIN 路径推荐 —— 杜绝编造 JOIN（对应研究方向二、四）
核心思想：LLM 编造 JOIN 条件是 Text-to-SQL 在多表场景的头号杀手。与其寄希望于 LLM"猜对"，不如直接告诉它"用这条路径"。
实现：
- 从元数据 + 外键信息构建 NetworkX 图（表节点 + 列节点 + FK 边）。
path_finder.py在表级无向图上做 BFS 最短路径搜索，把用户问题涉及的多张表自动串成有序 JOIN 链路。- Prompt 注入推荐路径：在 Schema 上下文中明确告诉 LLM「请使用以下推荐的 JOIN 路径」，从根本上杜绝编造。
- 历史 SQL 模板检索：用向量检索召回 top-k 历史 SQL 作为 Few-Shot 示例，引导 LLM 生成符合工厂习惯的写法。
创新点：把"JOIN 路径推断"从 LLM 的概率游戏变成图算法的确定性计算。这是 GraphRAG 思想在 Text-to-SQL 的具体落地——图谱提供结构化推理，LLM 负责自然语言到结构化映射。
Phase 3：LangGraph 多步分析 Agent —— 让 LLM 像同事一样分析（对应研究方向五）
核心思想：单轮 Text-to-SQL 只能出一张表，无法替代"分组 → 找趋势 → 联配方 → 下结论"的分析型脑回路。需要把这条链路显式建模成状态图。
实现：6 节点状态图 + 双层纠错 + 思考链全链路审计：
┌──────────┐
┌──────►│ finalizer│───────► 最终报告 / DataFrame / 完整思考链 trace
│ └──────────┘
│ ▲
│ │ (mode=simple)
│ │
┌────────┐ │ ┌─────────┴──┐ ┌──────────┐ ┌──────────┐
│ router │──┼─►│ planner │────►│ executor │────►│ critic │
└────────┘ │ └────────────┘ └──────────┘ └────┬─────┘
│ ▲ ▲ │
│ │ │ ┌────────────┴───────────┐
│ └────────────────┘ │ (mode=complex) │
│ ▼ │
│ ┌───────────┐ │
└──────────────────────┤ replanner │◄──────────────────┘
└───────────┘
- Router：判断问题是简单查询（直连 executor）还是复杂分析（走 planner）。
- Planner：把复杂问题拆解为子任务序列。
- Executor：生成 SQL + 执行 + 自纠错（最多 2 次）。
- Critic：对结果质量打分，低于阈值触发 Replan。
- Replanner：根据 Critic 反馈重新规划。
- Finalizer：汇总所有子任务结果，生成自然语言报告。
双层纠错：Executor 内 SQL 自纠错（执行报错回喂 LLM）+ Critic 外部质量评审（Replan）。这是 ResNet 式的"残差纠错"思想在 Agent 上的应用——每一层都尝试修正上一层的错误，而非指望一次性完美。
思考链全链路审计：每个节点的输入/输出/耗时/token/错误都记入 TraceEntry，UI 着色渲染。工程师能看清 Agent"在想什么"，这是工业落地的信任基础。
Phase 4：数据考古自动化 + 模板飞轮 + Agent 多轮记忆（对应研究方向一）
核心思想：把"研究方法一"从论文变成代码。Phase 1-3 都假设 fab_metadata.json 已经存在，但真实晶圆厂里这份元数据是缺失的——数十年人员更迭让"活知识"变"死知识"。必须先把"考古"自动化、让历史 SQL 沉淀回飞轮、让 Agent 记住多轮上下文，系统才能从"演示能跑"升级为"工厂长期可用"。这是整个项目的"基座阶段"：没有考古就没有元数据，没有元数据 Phase 1-3 全部空转。
实现：三大子模块，对应"考古 / 沉淀 / 记忆"三个闭环。
┌─── ① 数据考古自动化（offline pipeline） ───────────────────────────────┐
│ SchemaProfiler (零 LLM, 只读 PRAGMA) │
│ └─► SchemaProfile: 表结构 / 字段类型 / 外键 / 索引统计 │
│ MetadataGenerator (LLM + sqlglot AST 证据) │
│ 三信号融合 → FabMetadata │
│ (a) 命名模式: thk_ox_top 拆词与工艺词典匹配 │
│ (b) 数据分布: 扫描列值样本判断量纲 / 量级 / 枚举值 │
│ (c) SQL 使用模式: sqlglot AST 解析历史 SQL │
│ → 字段被 AVG/MAX/COUNT 包裹? 出现在 WHERE/SELECT? │
│ → 与哪些字段共现? │
│ 工艺专家 UI 二次确认 (Streamlit Tab3) → fab_metadata.json 落盘 │
└────────────────────────────────────────────────────────────────────────┘
┌─── ② 模板飞轮（在线正反馈） ──────────────────────────────────────────┐
│ Agent 成功 SQL ──► UI "沉淀为模板" popover │
│ └─► add_template() │
│ ├─ JSON 原子写 (临时文件 + os.replace, 防并发半成品) │
│ ├─ ChromaDB sql_templates 增量 upsert (id=hash(desc) 幂等) │
│ └─ description 去重 (同描述不重复入库, 防 top-k 全是同条) │
└────────────────────────────────────────────────────────────────────────┘
┌─── ③ Agent 多轮记忆（在线状态持久化） ────────────────────────────────┐
│ SqliteSaver checkpointer: LangGraph state → SQLite (进程重启不丢) │
│ chat_history 注入: 最近 6 轮 messages → planner/finalizer Prompt │
│ 单条截断 300 字 (防爆上下文) │
│ thread_id 跨轮继承: 每会话稳定 ID, 自动加载历史 state │
└────────────────────────────────────────────────────────────────────────┘
- SchemaProfiler：零 LLM、纯本地、可重复、零成本，是"考古"的物理层基线。读 SQLite
PRAGMA table_info / index_list / foreign_key_list，输出 SchemaProfile（表结构 / 字段类型 / 外键 / 索引统计），作为后续 LLM 推断的客观事实输入。 - MetadataGenerator：LLM 不是凭空猜字段含义，而是基于"命名模式 + 数据分布 + SQL 使用模式"三信号融合推断，并用 sqlglot 解析历史 SQL 提取 AST 证据作为支撑。三信号相互佐证——单独靠 LLM 猜会幻觉，单独靠统计会漏语义，融合后带证据推断，可信度大幅提升。
- 工艺专家 UI 二次确认：推断结果进 Streamlit Tab3 表单，工程师可勾选/修订/否决，确认后才落盘
fab_metadata.json。这是"机器做初筛 + 人做终审"的人机协同范式，控制 LLM 推断成本的同时保证工业可信。 - add_template() 原子写：模板描述/SQL/标签一起写入 JSON 文件，用临时文件 +
os.replace原子替换，避免并发崩溃导致半成品文件污染模板库。 - ChromaDB 增量索引 + description 去重：新增模板同步 upsert 到
sql_templatescollection，id=hash(description)幂等；相同 description 不重复入库，避免向量检索 top-k 全是同一条。 - SqliteSaver 持久化 checkpointer：LangGraph 状态写入 SQLite，进程重启不丢失。
chat_history最近 6 轮作为 messages 注入 planner/finalizer Prompt，单条截断 300 字防爆上下文；thread_id跨轮继承，Agent 自动加载历史 state。
创新点：把"研究方法一"从"理论上可以推断"变成"程序化可执行 pipeline"。三信号融合 + AST 证据是关键创新——这是把"LLM 猜字段"升级为"LLM 带证据推断字段"的范式跃迁。模板飞轮则是"历史 SQL 变现"的正反馈飞轮：用的越多，模板库越丰富，下次召回越准，形成数据资产自我增值。
效果：以 Mock 25 字段宽表验证，MetadataGenerator 对 24/25 字段给出正确中文释义（手工 ground truth 对照），其中 sqlglot AST 证据贡献了 30%+ 的字段——这些字段命名模式歧义但 SQL 用法清晰，单靠命名模式无法推断。Agent 多轮对话实测：第 2 轮追问响应比首轮快约 15%（跳过 schema 检索命中缓存）且准确率提升（带上下文约束 LLM 输出）。工程师可以追问"刚才那条 PROD-B 的最差批次为什么排第 2？"，Agent 记得上轮上下文。
Phase 5：规则校验器 + 语义缓存 + 晶圆/SPC 自动可视化
核心思想：Phase 1-4 解决"准确率"，Phase 5 解决"成本"和"易用性"。工业落地不能只看效果，还要看每次查询花多少钱、等多久、能不能直接看懂。Phase 5 用三件套把 LLM 调用次数砍下去、把响应时间压下来、把结果可视化自动化——这是"工业尊严"中"成本可控"与"开箱即用"的具体兑现。
实现：三件套分别对应"省 LLM 调用 / 省整次大循环 / 省手写画图"。
┌─── ① Validator 零 LLM 规则节点（executor → critic 之间） ─────────────┐
│ 5 条硬规则拦截"明显错误": │
│ 1. SQL 非空 (executor LLM 没产出) │
│ 2. SELECT 或 WITH 起始 (防 DDL/DML 误生成) │
│ 3. 不含 12 个写操作关键词 (正则全词匹配 \b, 防误杀 update_time) │
│ \b(DROP|DELETE|INSERT|UPDATE|TRUNCATE|ALTER|CREATE| │
│ GRANT|REVOKE|MERGE|REPLACE|ATTACH)\b │
│ 4. 无执行 error (db_connector 返回 error 字段为空) │
│ 5. df 非 None (执行成功但空 df 也 fail, 触发 replanner) │
│ pass → Critic (花钱打分) fail → replanner (省 1 次 LLM + 延迟) │
└────────────────────────────────────────────────────────────────────────┘
┌─── ② SemanticCache 查询结果语义缓存（大循环短路） ──────────────────────┐
│ ChromaDB query_collection (cosine distance) │
│ distance < 0.1 (≈ 相似度 ≥ 0.9) → 跳过整个 Agent 大循环 │
│ 直接还原 sql + df + report (4-6 次 LLM 调用 → 毫秒级) │
│ id = md5(query) upsert 幂等 (相同 query 不重复入库) │
│ df 序列化: to_json(orient="split") → metadata │
│ df 反序列化: io.StringIO + pd.read_json (保留 dtype) │
└────────────────────────────────────────────────────────────────────────┘
┌─── ③ 晶圆/SPC 自动可视化（三优先级自动选图） ───────────────────────────┐
│ 优先级 1: df 含 wafer_x & wafer_y → Wafer Map 散点图 (晶圆坐标) │
│ 优先级 2: elif 数值列命中 spec_lookup → SPC 控制图 (带 USL/LSL 规格线)│
│ 优先级 3: else → px.bar / px.line 兜底 │
│ spec_lookup 从 fab_metadata.json groups[].fields + spec_range 构建 │
│ @st.cache_resource 缓存, 零额外配置, 复用 Phase 4 元数据 │
└────────────────────────────────────────────────────────────────────────┘
- Validator 零 LLM 规则节点：在
executor → critic之间插入纯规则节点，用 5 条硬规则拦截"明显错误"。其中第 3 条用正则\b(DROP|DELETE|INSERT|UPDATE|TRUNCATE|ALTER|CREATE|GRANT|REVOKE|MERGE|REPLACE|ATTACH)\b全词匹配——避免误杀字段名（如update_time、create_dt）。pass 才进 Critic 花钱打分，fail 直接进 replanner，每次拦截省 1 次 LLM 调用 + 1 次 Critic 延迟。 - SemanticCache 查询结果语义缓存：用户提问前先查 ChromaDB
query_collection（cosine distance），相似度 ≥ 0.9（distance < 0.1）则跳过整个 Agent 大循环（4-6 次 LLM 调用），直接还原 sql + df + report。id = md5(query)upsert 幂等；df 用to_json(orient="split")序列化写入 metadata，反序列化io.StringIO + pd.read_json还原并保留 dtype。命中率随使用积累上升，典型 4-6 次 LLM 调用降至毫秒级。 - 晶圆/SPC 自动可视化：三优先级自动选图——(1) df 含
wafer_x&wafer_y列 → Wafer Map 散点图（晶圆坐标）；(2) elif 数值列命中spec_lookup→ SPC 控制图（带 USL/LSL 规格线）；(3) else 回退px.bar/line。spec_lookup从fab_metadata.json的groups[].fields + spec_range构建，@st.cache_resource缓存。零额外配置，复用 Phase 4 元数据——这是"考古产物直接驱动可视化"的链路闭环。工程师不用自己写画图代码，看结果即看图。
创新点：三件套是"成本可控 + 易用性"的工业尊严组合。Validator 把规则可判错的错误从 LLM 评审里剥离；SemanticCache 把"相似问题"从大循环里剥离；自动可视化把"看数据"从手写代码里剥离。每一件都是"把 LLM 留给真正需要推理的部分"——这是对 LLM 调用成本的精细外科手术，而非简单堆功能。
效果：Mock 验证——Validator 拦截率约 15%（明显错误省 Critic）；SemanticCache 在重复/相似问题场景命中率 30%+（同主题追问场景更高）；自动可视化覆盖 80%+ 常见查询场景，工程师看 SQL 结果无需再切 Excel 画图。
Phase 6：Agentic RAG —— SOP 知识库融合，从"数据洞察"到"操作指引"闭环
核心思想：Phase 1-5 解决了"从数据到洞察"，但工厂场景里工程师拿到"thk_ox OOS 超标批次清单"后，真正想知道的是"接下来该怎么处理"——查哪台机台、Hold 哪个 lot、通知谁、是否返工。这些操作指引沉淀在 SOP（Standard Operating Procedure）文档里，是工厂几十年的工艺纪律。Phase 6 用 Agentic RAG 把 SOP 文档变成 Agent 的"第二大脑"，实现"数据洞察 → 操作指引"闭环。这是从"查询工具"到"决策伙伴"的跃迁，也是研究方法中未明确但 FabSage 率先落地的方向。
实现：三个组件 + 一个 Mock 验证集，构成完整 Agentic RAG 链路。
┌─── ① SOPRetriever (ChromaDB 拥有者) ────┐ ┌─── ② SOPLoader (TXT/PDF 解析切片) ────┐
│ collection = "sop_collection" │ │ data/sops/*.txt / *.pdf │
│ ChromaDB 内存 + cosine distance │ │ TXT: read_text(utf-8) UnicodeDecode │
│ 复用 SimpleChineseEmbeddingFunction │ │ → errors="ignore" 优雅降级 │
│ (DIM=256, MD5 哈希 TF + L2 归一) │ │ PDF: pypdf.PdfReader 缺失→warning 仅TXT│
│ 跨中英文, 零下载离线可用 │ │ 按空行分段落 re.split(r"\n\s*\n") │
│ add_chunks (幂等清空重建) │ │ 过滤短噪声 (<10字) + 纯装饰行 │
│ retrieve_sop (top_k + 相关度 score) │ │ [=\-*_#~]+ │
│ format_for_prompt ("SOP1 [src#idx] │◄─┤ 无空行文档退化为按单行切 │
│ (相关度0.45)\n内容") │ │ load_all() 幂等 / load_file() upsert │
│ count │ │ 依赖注入 SOPRetriever (解内存共享难题)│
│ SOPChunk: Pydantic v2 │ │ │
│ source / index / content / score │ │ │
└──────────────────────────────────────────┘ └────────────────────────────────────────┘
│
▼
③ FabTools.search_sop(query, top_k) [FabTools 第 6 个方法]
sop_retriever @property 惰性实例化 (避免启动期开销)
首次调用 loader.load_all() 自动加载 data/sops/
→ 召回 SOPChunk → format_for_prompt()
→ 注入 finalizer Prompt
→ 报告输出 "数据洞察 + 操作步骤"
- SOPRetriever（ChromaDB 拥有者）：ChromaDB
sop_collection段落向量检索，复用 Phase 1 的SimpleChineseEmbeddingFunction（DIM=256，MD5 哈希 TF + L2 归一，跨中英文，零下载离线可用）。同一套 Embedding 体系覆盖 SQL 模板 / 语义缓存 / SOP 三个 collection，架构统一、零额外依赖。四个核心方法：add_chunks（幂等，清空重建避免重复）/retrieve_sop（top_k 召回 + 相关度 score）/format_for_prompt（生成SOP1 [src#idx] (相关度0.45)\n内容文本块）/count。SOPChunk用 Pydantic v2 校验，字段source / index / content / score。 - SOPLoader（TXT/PDF 解析切片）：双格式解析 + 多重容错。(a) TXT 用
pathlib.Path.read_text(encoding="utf-8")，UnicodeDecodeError退化errors="ignore"——工厂 SOP 偶有 GBK 混入，不能因编码挂掉；(b) PDF 用pypdf.PdfReader，pypdf 缺失则warning优雅降级为仅 TXT，不抛异常——工厂内网常无法pip install，必须容错；© 段落切片re.split(r"\n\s*\n")按空行分段，过滤<10 字短噪声 + 纯装饰行（re.match(r"^[=\-*_#~]+$")），无空行文档退化为按单行切，保证总能切出可用 chunk；(d)load_all()幂等：内部调load_file()upsert，重复调用不重复入库。 - search_sop 工具（FabTools 第 6 个方法）：
sop_retriever用@property惰性实例化，首次访问才构建——避免启动期开销。首次调用loader.load_all()自动加载data/sops/全部 SOP。召回SOPChunk列表调format_for_prompt生成统一文本块，注入 finalizer Prompt。finalizer 在生成报告时把数据洞察 + SOP 操作步骤一起输出，例如"thk_ox OOS 超标批次清单"+ “步骤1：检查机台温度传感器 TC；步骤2：Hold Lot…”。 - Mock SOP 覆盖 thk_ox OOS 全流程：触发条件（thk_ox 超规格）→ 温度传感器 TC 检查 → Hold Lot → 根因分析（SPC/8D）→ 复机条件（Cpk ≥ 1.33）→ 升级机制（无法收敛时上报工艺主管）。验证：8 个 SOP 切片，round-trip 命中 score 0.45 / 0.29，能召回正确操作步骤。
设计亮点（两个非显然的工程决策）：
- 依赖注入解决 ChromaDB 内存共享：ChromaDB 内存模式不跨实例共享，若 SOPRetriever 和 SOPLoader 各自
__init__一个 ChromaDB client，写入和查询会落在两个孤立 collection 上。FabSage 让 SOPRetriever 拥有 collection、SOPLoader 通过构造函数注入同一实例——这是"loader/retriever 分文件"在内存模式约束下的正确工程实现。 - 复用 SimpleChineseEmbeddingFunction：不为 SOP 单独引一套 Embedding（如 sentence-transformers），跨中英文 + 离线可用 + 零下载。SOP 中英混杂（“Hold Lot”“Cpk”“温度传感器 TC”）也能稳定检索。
创新点 / 划时代意义：研究方法中未明确但 FabSage 率先落地的方向——Agent 不仅要查数据，还要给操作指引。从"告诉你发生了什么"升级为"告诉你该怎么办"。在半导体制造这个对良率极度敏感的行业，"OOS 超标 → 自动给处理流程"的闭环，意味着把工艺工程师的响应时间从分钟级压缩到秒级。这是真金白银的工业价值，也是 Agent 从"查询工具"升级为"决策伙伴"的标志。下一批路线图：patrol/scheduler（APScheduler 后台巡检）+ finalizer 注入 SOP + app.py Tab3 + audit_log.json，形成"数据洞察 → 操作指引 → 模拟操作 → 审计回溯"完整闭环。
四、核心创新点深度解析（对应五大研究方向）
创新点 1：动态上下文组装 —— 把"全表喂 LLM"变成"精准喂 LLM"（研究方向三落地）
不是把整张宽表 DDL 塞进 Prompt，而是：
- 字段聚类成语义组（数据考古产物）。
- 用户提问时检索命中组。
- 只注入相关字段的 DDL + 中文释义 + spec_range。
这是"渐进式 Schema 摘要"思想的工程化：Level 0 数据库总览 → Level 1 域级 → Level 2 表级 → Level 3 字段级，按需展开。
创新点 2：零字段幻觉 —— 缩写释义 + 命中组双保险
LLM 字段幻觉的根因是"不懂缩写"。FabSage 用两道防线：
- 元数据
field_dict提供缩写 → 中文释义映射（如thk_ox_top→ “顶层氧化膜厚度”），注入 Prompt。 - 动态命中组只暴露相关字段，LLM 没机会"看到"其他字段去编造。
创新点 3：表关系图谱 + 自动 JOIN 路径推荐 —— GraphRAG 在 Text-to-SQL 的落地（研究方向二、四落地）
把表关系建成 NetworkX 图，BFS 求最短 JOIN 路径，注入 Prompt。这是 GraphRAG 思想的垂直落地：
- 图提供结构化推理（确定性的最短路径）。
- LLM 负责自然语言到结构化映射（把"缺陷最多的批次用了哪个配方"映射到
defect_inspection → lot_info → eqp_recipe的 JOIN 链）。
创新点 4：双层纠错机制 —— ResNet 式残差纠错在 Agent 上的应用
- Executor 内 SQL 自纠错 ×2（执行报错回喂 LLM）。
- Critic 外部质量评审 → Replanner ×2（评分低于阈值重新规划）。
不是指望 LLM 一次性完美，而是让每一层修正上一层的错误。
创新点 5：离线可用的轻量 Embedding —— 工厂内网的尊严
工厂内网常无法下载 sentence-transformers 模型。FabSage 自研 SimpleChineseEmbeddingFunction：
- DIM=256，MD5 哈希 TF 向量 + L2 归一。
- 字符级 + 词级 + 中文二元 TF，跨中英文。
- 实现了 ChromaDB 的
__call__协议，可平滑替换为 OpenAI text-embedding-3 而无需改业务代码。
零下载、离线可用、可平滑升级——这是工业落地的尊严。
创新点 6：数据考古自动化 —— 把历史 SQL 当"弱标注数据"（研究方向一落地）
SchemaProfiler扫库提取表结构。MetadataGenerator用 LLM 基于"命名模式 + 数据分布 + SQL 使用模式"多信号融合推断字段语义，sqlglot 解析历史 SQL 提取 AST 证据。- 工艺专家 UI 二次确认，控制成本。
把数十年"活知识变死知识"的困境，用程序分析 + 统计 + LLM 三管齐下逆向重建。
创新点 7：模板飞轮 —— Agent 越用越聪明
Agent 执行成功的新 SQL 一键沉淀回模板库，ChromaDB 增量索引。形成正反馈：用的越多，模板库越丰富，下次召回越准。这是"历史 SQL 变现"的飞轮效应。
创新点 8：Agentic RAG —— SOP 知识库融合，"数据洞察 + 操作指引"闭环（Phase 6 划时代创新）
这是研究方法中未明确但 FabSage 率先落地的方向：Agent 不仅要查数据，还要给操作指引。把 SOP 文档向量化建库，finalizer 节点召回相关段落注入报告。
工程师拿到"thk_ox OOS 超标批次清单"的同时，还能看到"步骤1：检查机台温度传感器；步骤2：通知工艺工程师 Hold Lot…“的完整操作流程。从"告诉你发生了什么"升级为"告诉你该怎么办”。
创新点 9：成本控制 + 易用性四件套 —— Validator + SemanticCache + 自动可视化 + 离线 Embedding
- Validator 零 LLM 拦截明显错误，省 1 次 LLM 调用。
- SemanticCache 命中省掉整次 Agent 大循环（4-6 次 LLM 调用）。
- 自动可视化（Wafer Map / SPC 控制图 / 柱线图三优先级）复用元数据
spec_range，零配置开箱即用，工程师看结果即看图。 - 离线 Embedding 零下载成本。
工业落地不能只看效果，还要看成本和易用性。FabSage 在效果、成本、体验三角之间做了精细权衡——把 LLM 留给真正需要推理的部分，把规则可判错的、可缓存的、可模板化的全部剥离。
创新点 10：思考链全链路可追溯 —— 工业信任的基础
每个节点的输入/输出/耗时/token/错误都记入 TraceEntry，UI 着色渲染。工程师能看清 Agent"在想什么"。这是工业落地区别于 Demo 的关键——可解释、可审计、可追责。
五、系统架构全景
┌─────────────────────────────────────────────────────────────────────────────┐
│ Streamlit UI (三 Tab 布局) │
│ Tab1 单步直链 | Tab2 Agent 多步 | Tab3 数据考古 (Phase 4 工艺专家二次确认) │
│ 内嵌自动可视化 (Phase 5): Wafer Map / SPC 控制图 / 柱线图 三优先级自动选图 │
└──────────────────────────────────────┬──────────────────────────────────────┘
│
┌──────────────────────▼───────────────────────────────┐
│ SemanticCache (Phase 5) ──命中──► 还原 sql+df+report │
│ ChromaDB query_collection, cosine<0.1 跳过整次大循环 │
│ id=md5(query) 幂等, df to_json(split) 序列化 │
└──────────────────────────────┬───────────────────────┘
│ miss
▼
┌─── LangGraph Agent 状态图 (Phase 3: 6 节点 + 4 条件路由) ─────────────────────┐
│ │
│ ┌────────┐ ┌─────────┐ ┌──────────┐ ┌───────────┐ ┌────────┐ ┌──────┐ │
│ │ router │─►│ planner │─►│ executor │─►│ Validator │─►│ critic │─►│final-│ │
│ └───┬────┘ └────▲────┘ └────┬─────┘ │ (Phase 5) │ └───┬────┘ │izer │ │
│ │ │ │ │ 零LLM 5规则│ │ fail └──┬───┘ │
│ │ │ │ fail └─────┬──────┘ │ │ │
│ │ └────────────┼──────────────┘ │ │ │
│ └────────────────────────►┌───────────┐ │ │ │
│ │replanner │◄────────────────┘ │ │
│ └───────────┘ │ │
│ 双层纠错: Executor 内 SQL 自纠错×2 + Critic→Replanner×2 (ResNet 残差纠错) │
│ 思考链审计: TraceEntry 记录每节点 input/output/token/error, UI 着色渲染 │
└──────────────────────────────────────┬──────────────────────────────────────┘
│
┌──────────────────────▼───────────────────────────────┐
│ FabTools 工具门面 (6 方法 @property 懒构造) │
│ get_schema_context | search_sql_templates | generate_sql │
│ execute_sql | correct_sql | search_sop (Phase 6) │
└─┬───────┬───────┬───────┬───────┬───────┬───────────────────┘
│ │ │ │ │ │
┌───────▼──┐ ┌──▼───┐ ┌─▼───┐ ┌─▼───┐ ┌─▼───┐ ┌─▼─────┐
│ Schema │ │SQL │ │Text2│ │ DB │ │SQL │ │ SOP │
│Retriever │ │Temp- │ │SQL │ │Con- │ │纠正 │ │Retri- │
│(Phase 1) │ │late │ │Engine││nector││ │ │ever │
│ │ │RAG │ │ │ │(三 │ │ │ │(Phase │
│ │ │(P1) │ │ │ │护栏)│ │ │ │ 6) │
└────┬─────┘ └──┬───┘ └─────┘ └─────┘ └─────┘ └──┬────┘
│ │ ▲ │
│ │ 模板飞轮回写 (Phase 4) │ │
│ └────── add_template ───────┘ │
│ (原子写 + ChromaDB 增量索引 │
│ + description 去重) │
│ │
┌──────▼──────────────────────────┐ ┌───────▼───────────┐
│ fab_metadata.json (元数据语义层)│ │ data/sops/ │
│ + fab_schema_graph.json (图谱) │ │ SOP 文档库 │
│ + path_finder BFS (Phase 2) │ │ + SOPLoader (P6) │
│ 自动 JOIN 路径推荐 │ │ TXT/PDF 解析切片 │
└──────────────┬──────────────────┘ └────────────────────┘
▲
┌──────┴──────────────────────────┐
│ archaeology/ (Phase 4 数据考古) │
│ SchemaProfiler (零LLM, PRAGMA扫库)│
│ MetadataGenerator (LLM+sqlglot │
│ AST 证据, 三信号融合推断) │
└──────────────────────────────────┘
┌──────────────────────────────────────────────────────────────────────────┐
│ Agent 多轮记忆 (Phase 4): SqliteSaver checkpointer 持久化 LangGraph state │
│ chat_history 注入最近 6 轮 (单条 300 字截断) + thread_id 跨轮继承 │
└──────────────────────────────────────────────────────────────────────────┘
六大 Phase 在架构中的落点：
| Phase | 架构位置 | 关键组件 |
|---|---|---|
| Phase 1 | Schema Retriever / SQL Template RAG | 动态命中字段组 + 模板向量召回 |
| Phase 2 | fab_schema_graph.json + path_finder | NetworkX 图 + BFS 最短 JOIN 路径 |
| Phase 3 | LangGraph Agent 状态图 | 6 节点 + 4 条件路由 + 双层纠错 + TraceEntry 审计 |
| Phase 4 | archaeology/ + 模板飞轮回写 + SqliteSaver | 数据考古 pipeline + 增量沉淀 + 多轮记忆 |
| Phase 5 | SemanticCache + Validator 节点 + 自动可视化 | 大循环短路 + 零 LLM 规则拦截 + 三优先级选图 |
| Phase 6 | SOP Retriever + SOPLoader + search_sop | SOP 向量检索 + 注入 finalizer 闭环 |
核心数据流：用户问题 → SemanticCache 未命中 → Schema 检索命中字段组 → 图谱推荐 JOIN 路径 → 召回历史 SQL 模板 → LLM 生成 SQL → 执行 → Validator 规则校验 → Critic 评审 → Finalizer 汇总报告（+ SOP 操作指引）→ 成功则模板飞轮回写。
全链路 ChromaDB 内存模式：SQL 模板库 / 语义缓存 / SOP 知识库三个 collection 共用同一套 SimpleChineseEmbeddingFunction（DIM=256，零下载离线可用），架构统一，零运维。
两条反馈闭环：
- 模板飞轮（Phase 4）：Agent 成功 SQL →
add_template()→ ChromaDB 增量索引 → 下次召回更准。 - 数据洞察→操作指引（Phase 6）：查询结果 →
search_sop召回 SOP 段落 → finalizer 注入操作步骤 → 工程师拿到"发生了什么 + 该怎么办"。
六、划时代意义：为什么这个项目值得被记住
1. 第一个把"数据考古 + 语义重建 + 智能接入"三层打通的开源 Fab Text-to-SQL Agent
学术界研究 Text-to-SQL 的多，研究晶圆厂的少；工业界做 MES/EAP 的多，用 LLM/Agent 重新定义数据接入的少。FabSage 晶策是第一个把"数据考古（SchemaProfiler/MetadataGenerator）+ 语义重建（元数据分组/图谱）+ 智能接入（LangGraph Agent/SOP RAG）"三层完整打通并开源的项目。
它证明了一件事：LLM 在工业场景的落地，不是把模型塞进 Demo 就行，而是要重建一整套语义基础设施。
2. 把 GraphRAG 思想垂直落地到 Text-to-SQL
业界谈 GraphRAG 多停留在"知识图谱问答"，FabSage 把它落地到 Text-to-SQL 的核心痛点——JOIN 路径推断。图谱提供结构化推理（确定性的 BFS 最短路径），LLM 负责自然语言到结构化映射。这种"图算法 + LLM"的分工，是 GraphRAG 在垂直领域的最佳实践。
3. 从"数据洞察"到"操作指引"的 Agent 闭环（Phase 6）
这是 FabSage 最具前瞻性的一步。现有的 Text-to-SQL 系统止步于"告诉你发生了什么"，FabSage 通过 SOP 知识库 Agentic RAG，进一步告诉用户"该怎么办"。这标志着 Agent 从"查询工具"升级为"决策伙伴"。
在半导体制造这个对良率极度敏感的行业，"OOS 超标 → 自动给处理流程"的闭环，意味着把工艺工程师的响应时间从分钟级压缩到秒级。这是真金白银的工业价值。
4. 工业尊严：离线、可解释、成本可控、开箱即用
- 离线可用：自研轻量 Embedding，零下载，工厂内网尊严。
- 可解释：思考链全链路审计，每一步可追溯。
- 成本可控：Validator 省 1 次 LLM，SemanticCache 省整次大循环，离线 Embedding 零成本。
- 开箱即用：晶圆/SPC 自动可视化复用元数据
spec_range，工程师看结果即看图，无需手写画图代码。
这四个"工业尊严"是 FabSage 区别于学术 Demo 的根本。它不是跑在 benchmark 上的分数，是能在工厂里跑起来的系统。
5. 为半导体制造数字化转型提供新范式
FabSage 晶策展示了一种新范式：用 LLM/Agent 重新定义制造数据的接入方式，把数十年沉淀的"暗知识"变成可计算、可查询、可决策的"活资产"。
这不是一个 Text-to-SQL 项目，这是一个半导体制造数据资产化的基础设施。
5. 界面展示
七、开源与生态
项目已开源，GitHub repo：https://github.com/BumbleBee-ZDS/FabSage
技术栈
| 层 | 技术 | 用途 |
|---|---|---|
| LLM | DeepSeek（OpenAI 兼容） | Text-to-SQL / 推断元数据 / Agent 推理 |
| Agent | LangGraph | 6 节点状态图 + checkpointer |
| 向量库 | ChromaDB（内存模式） | SQL 模板 / 语义缓存 / SOP 知识库 |
| 图谱 | NetworkX | 表关系 + BFS JOIN 路径 |
| SQL 解析 | sqlglot | AST 证据提取 |
| UI | Streamlit | 三 Tab 布局 |
| 记忆 | SqliteSaver | Agent 多轮对话持久化 |
| DB | SQLite（MVP，可换 Oracle） | Mock 数据 |
核心目录结构
fabsage/
├── app.py # Streamlit 主入口 (三 Tab)
├── config.py # Pydantic 配置
├── core/ # 核心引擎
│ ├── schema_retriever.py # 动态 Schema 摘要 (Phase 1)
│ ├── sql_template_rag.py # SQL 模板 RAG + SimpleChineseEmbeddingFunction
│ ├── semantic_cache.py # 语义缓存 (Phase 5)
│ ├── text2sql_engine.py # LLM SQL 生成
│ └── db_connector.py # 只读执行器 (三重护栏)
├── graph/ # 表关系图谱 (Phase 2)
│ ├── build_graph.py # NetworkX 图构建
│ └── path_finder.py # BFS JOIN 路径推荐
├── agents/ # LangGraph Agent (Phase 3/4/5)
│ ├── state.py # AgentState + TraceEntry
│ ├── tools.py # FabTools 6 方法门面
│ ├── nodes.py # 7 节点 + 4 条件路由
│ └── workflow.py # StateGraph 构建
├── archaeology/ # 数据考古 (Phase 4)
│ ├── schema_profiler.py # 扫库 (零 LLM)
│ └── metadata_generator.py # LLM 推断元数据
├── knowledge/ # SOP 知识库 (Phase 6)
│ ├── sop_retriever.py # SOPRetriever (ChromaDB)
│ └── sop_loader.py # SOPLoader (TXT/PDF 切片)
├── viz/ # 专业可视化 (Phase 5)
│ ├── wafer_map.py # 晶圆坐标散点图
│ └── spc_chart.py # SPC 控制图 (USL/LSL)
└── data/
├── sops/ # SOP 文档库 (Phase 6)
└── fab_metadata.json # 元数据语义层
快速验证
git clone https://github.com/<your-id>/fabsage.git
cd fabsage
pip install -r requirements.txt
# 配置 .env: DEEPSEEK_API_KEY=sk-xxx
python data/init_mock_db.py
streamlit run app.py
Phase 6 SOP 检索单独验证：
python -c "from agents.tools import FabTools; print(FabTools().search_sop('thk_ox OOS 怎么处理'))"
八、写在最后
这个项目为什么叫 FabSage 晶策
- Fab = Fabrication，晶圆制造厂，锁定半导体垂直场景。
- Sage = 智者/贤者，体现 Agent"像懂行的同事一样分析、给操作指引"，而非冰冷查询器。
- 晶策 = 晶圆 + 决策，呼应"数据洞察 → 操作指引 → 决策闭环"的演进方向。
研究与工程的辩证
千问的研究方法论给出了"数据考古 + 语义重建 + 智能接入"的清晰框架，但从研究方法到工程落地之间，隔着无数个"工业尊严"的细节：离线 Embedding、原子写、幂等索引、优雅降级、思考链审计、成本控制……
FabSage 晶策的价值不在于发明了某个新算法，而在于把五个研究方向系统性地缝合成一个能在工厂跑起来的整体。每一个 Phase 都对应一个研究方向，每一个创新点都解决一个工业痛点。
下一步
- SOP 知识库持久化 + 多文档扩展：从内存模式升级为 ChromaDB 持久化，扩充 CD/Overlay/Particle 等异常 SOP。
- 主动巡检预警 + 操作闭环：APScheduler 后台定时跑 OOS 检测 SQL，超标主动预警 + 报告"建议操作"按钮 + audit_log.json 审计回溯，形成"数据洞察 → 操作指引 → 模拟操作 → 审计回溯"完整闭环。
- Procedure 解析接入：解析真实 Oracle PL/SQL 提取字段血缘，从 NetworkX 升级为 Neo4j 超图。
- 生产化：Oracle 真实宽表 + 数十张维表 + 企业 SSO + 行列级权限。
致半导体人
半导体制造是少数几个"人类精密制造能力天花板"的行业。每一片晶圆背后是数千道工序、数百万个量测点、数十年的工艺积累。这些数据不该沉睡在 Oracle 的深处，它们应该被唤醒、被理解、被用于决策。
FabSage 晶策是一次尝试——用 LLM/Agent 重新定义晶圆厂的数据接入方式。我们相信，当工业知识遇上大模型，当数据考古遇上 Agent 推理，半导体制造的数字化转型会进入一个新纪元。
这不是终点，这是起点。
项目地址：GitHub: https://github.com/BumbleBee-ZDS/FabSage
License：MIT
欢迎 Star / Issue / PR —— 让我们一起把晶圆厂的"暗知识"变成"活资产"。
“先考古、再组装、后生成、再评审、再赋能。” —— FabSage 晶策的方法论
这里是“一人公司”的成长家园。我们提供从产品曝光、技术变现到法律财税的全栈内容，并连接云服务、办公空间等稀缺资源，助你专注创造，无忧运营。
更多推荐
20
0- 0
已为社区贡献8条内容
所有评论(0)