一、问题背景为什么FAB工艺工程师需要本地大模型作为FAB的工艺工程师每天的工作几乎都离不开“查资料”这三个字。清晨到岗先要看昨夜的异常批次处置记录做工艺变更要翻SOP确认参数窗口设备报警要调出对应的操作手册找处置步骤新人培训要找流程PERT图讲关键路径客户来审厂还要临时汇总某产品的特殊工艺要求。这些资料分散在多个互不相通的系统里有的躺在MES的文档模块中有的在文件服务器的共享盘有的在质量系统的归档案有的甚至只在某位老工程师的个人电脑和笔记本里。想要找一个半年前某台光刻机的某个报警处置步骤往往要登录三四个系统、翻十几份文档大半天才勉强拼出答案效率极低。更让人头疼的是很多真正有用的工艺经验是老师傅脑子里的“隐性知识”既没有写成文档也搜不到关键字。一旦老师傅休假或离职这些经验就面临断档风险而新人上岗光是熟悉“去哪查、怎么查”就要耗掉数周成长曲线被严重拉平。我们也试过建共享Wiki但大家写文档的积极性不高更新也总是滞后最后Wiki成了僵尸页面没人愿意维护搜索体验还不如直接去问人。我为什么会想到用本地大模型核心原因是数据安全。半导体工艺参数、良率数据、客户产品信息都属于高度敏感资料一旦上传到公有云就存在不可控的泄露风险事实上很多工厂的IT合规制度明确禁止把任何内部文档传到外部网络违者要追责。而本地部署的开源大模型例如Ollama配合Qwen2.5可以完全离线运行所有数据都留在内网安全性完全可控也符合合规审计要求不会踩数据出境的红线这一点对芯片类工厂尤其关键。其实可以把这件事想得更直接知识库不是给文档换个存放位置而是把“人找知识”变成“知识找人”。当一名夜班工程师遇到不熟悉的报警他不需要知道资料存在哪个系统、叫什么文件名只要在对话框里用大白话描述现象系统就能把对应的处置步骤推到他面前。这种体验上的改变才是本地大模型对现场最有价值的地方也是我愿意花时间把它做下来的根本原因。这篇文章是我个人在工厂里亲身实践的经验总结不是厂商宣传稿。我会从原理讲到落地覆盖RAG检索增强、Embedding向量化、Chroma向量库以及我在搭建过程中真实踩过的那些坑希望帮你少走弯路把老师傅的经验真正沉淀成“随时能问答”的私有知识库而不是又一个数周后就被遗忘的共享文件夹。二、技术原理Ollama、RAG与向量数据库是怎么协作的先说Ollama是什么。它是一个轻量级的大模型运行框架把模型权重、推理运行时和API服务打包在一起让你用一条命令就能在本地把开源大模型跑起来。它通过Modelfile描述模型、量化格式与运行参数支持Llama3、Phi3、Qwen2等多个主流开源模型系列。对工程师来说最大的好处是不用配复杂环境、不用写底层推理代码一条“ollama run qwen2.5”就能直接对话一条“ollama pull”就能拉取社区模型部署门槛很低一台普通工作站就能跑起来。模型怎么选在中文语义理解、尤其是中文技术文档问答上Qwen2.5明显优于同尺寸的Llama3Phi3虽然体积小、跑得快但中文能力偏弱、且在长文档上容易丢失信息。如果服务器内存有限比如16G可以用Qwen2.5:7b4-bit量化后约5G显存如果有32G以上内存和一张显卡Qwen2.5:14b效果会更好。量化档次q4/q5/q8也很关键q4体积小但略有精度损失q8接近原版但更占显存生产环境我更推荐q5折中。选型时务必在中文SOP问答上做小规模实测而不是只看公开榜单的分数因为榜单场景和你的工艺语料差异很大。但光靠一个大模型并不能直接回答你厂里的具体工艺问题——它根本不知道你厂里的规范细节。这就需要RAG检索增强生成Retrieval-Augmented Generation。RAG的思路是先把你的私有文档切成片段用Embedding模型把每段文本映射成一个高维稠密向量存进向量数据库如Chroma、FAISS当用户提问时先把问题也映射成向量在向量库里做“余弦相似度”检索找出最相关的几个片段再把片段拼进Prompt一起喂给大模型让模型基于这些“内部资料”来生成回答。这样模型既不容易胡编乱造幻觉显著减少回答又基于真实文档、且可追溯来源。向量数据库怎么选Chroma上手极简单、Python原生、适合中小规模知识库且支持按集合collection管理多类文档FAISS是更底层的向量检索引擎性能强、适合百万级文档但需要自己写索引与持久化逻辑。对工厂知识库场景Chroma通常就够用了。进阶可用重排序reranker在检索出Top-K之后再做一次精排进一步提升相关片段的命中率对长文档、表格多的手册尤其有用当知识库既含文档又含结构化数据如参数表时还可以做“向量检索关键词/SQL”的混合检索。和云端ChatGPT类通用大模型对比云端模型参数更大、通用知识更强但数据要出内网、按调用量收费、并且存在合规风险本地OllamaRAG数据不出厂、一次部署长期免费劣势是需要自有硬件且领域问答质量高度依赖RAG的检索质量——检索不到模型就只能瞎猜。所以本地方案的核心竞争力不在模型本身而在“知识库检索”这一整套工程的质量检索越准回答越稳这也是后面实战部分要重点打磨的地方。补充一个评估视角RAG好不好不能只靠“感觉答得对”要用量化的检索指标盯住。常用做法是拿一批真实问答做标注计算检索召回率该召回的片段有没有进Top-K和答案准确率再针对性调切片长度、重叠量、Embedding模型与Top-K。我习惯先用小样本跑通评估闭环再批量扩库避免“建了几万片段却不知道准不准”的盲区也方便向上面汇报“为什么值得继续投”。图2 RAG检索增强生成系统架构文档经切分、向量化后存入向量库提问时检索相关片段再生成回答三、实战案例从零搭一个FAB工艺私有知识库下面讲我实际搭建的过程分成四步来做每一步都附上我踩过的坑。第一步安装并启动Ollama。在Windows或Linux内网服务器上装好Ollama后执行“ollama pull qwen2.5:7b”拉取模型再用“ollama serve”启动API服务默认端口11434。我把它部署在一台只有厂内网络能访问的服务器上从物理上隔绝外网并把OLLAMA_NUM_PARALLEL调大以支持多名工程师同时提问避免排队如果有多张显卡用OLLAMA_VISIBLE_DEVICES指定推理设备把生成负载均摊开。第二步构建知识库。我把三类文档喂了进去第一类是半导体工艺文档SOP、工艺窗口、参数规范第二类是PERT图工序流程图、关键路径说明第三类是设备手册光刻机、刻蚀机的报警码表与处置步骤。用Python读取这些PDF/Word/TXT按约500字一片切成片段片段之间保留50字重叠避免把一句话从中间切断用nomic-embed-text这类中文友好的Embedding模型向量化写入Chroma的持久化目录方便重启后直接复用不必每次冷启动重建。第三步搭RAG检索与生成链路。流程是工程师提问-问题向量化-Chroma检索Top-5片段-拼成带上下文的Prompt-调用Qwen2.5 API生成回答。我特意让Prompt要求模型“只依据给定资料作答资料不足就明确说不知道”并强制输出引用了哪份文档的哪个片段方便工程师逐条复核而不是盲信模型的一句话。这里还有一个细节检索到的片段长度要受上下文窗口约束拼太多会把关键片段挤掉所以Top-K不是越大越好我实测Top-5在准确率与长度之间最平衡。第四步做Streamlit前端。用几十行代码做了个简单网页左侧输入问题右侧返回答案并且把“引用了哪份文档、哪个片段”显示出来还加了“答案置信度”提示。上线后老师傅把多年笔记陆续导进知识库新人查一个报警处置步骤从过去的平均半天缩短到几十秒知识第一次真正“活”了起来。举一个真实问答的例子新人有次问“显影后线宽偏小的可能原因与排查顺序”系统检索到SOP里“线宽管控”小节和设备手册“显影单元”小节回答先列出三大类原因曝光能量、显影时间、温度再给出对应的量测与调整步骤并标注“来源SOP-显影工序-v3.2 第4.1节”。这种带出处的答案现场才敢直接用。踩坑记录这部分最重要①中文PDF解析很容易乱码一定先用工具转成纯文本再切分②切分太大检索不精准太小又丢上下文500字加50字重叠是我验证过的最佳实践③Embedding模型必须和文档语言一致中文文档别用纯英文Embedding否则相似度计算严重失真④Ollama默认上下文窗口有限长文档要调大“--num_ctx”否则检索片段会被截断⑤向量库第一次建索引很慢建议离线预建好再上线⑥多用户并发时会OOM需限制并行数与单请求长度⑦文档更新后必须重建或增量更新向量库否则答案会“过期”给出已经废止的旧规范。还有一个线上很实用的细节当检索到的片段置信度都偏低时与其让模型硬编不如直接回复“资料中未找到明确依据建议联系工艺工程师确认”并附上最相近的几份文档标题供人工判断。我们把这条“承认不知道”的兜底写进Prompt后错误回答的比例明显下降现场也更愿意信任这个系统——信任来自“不乱说”而不是“什么都能答”这一点在工厂这种容错率低的现场尤其重要。四、完整代码RAG问答系统(Python, 不到80行)下面是一套可直接运行的RAG问答骨架。代码以注释形式标明了“为什么这样写”便于你理解每一处设计取舍。import ollama, chromadb # ①导入本地大模型客户端与向量库(Ollama提供对话API, Chroma负责向量检索)from chromadb.utils import embedding_functions# ②为什么这样写: 必须用中文友好的Embedding函数, 否则中文文档向量化后相似度计算会严重失真导致检索完全失效ef embedding_functions.OllamaEmbeddingFunction(model_namenomic-embed-text)client chromadb.PersistentClient(path./kb) # ③持久化向量库, 重启后知识库不丢失, 避免每次重建耗时的重复劳动col client.get_or_create_collection(fab_kb, embedding_functionef)def build_kb(files): # ④批量建库: 读文档/切分/入库, 文档更新时只需重跑此函数即可同步for f in files:txt open(f, encodingutf-8).read() # ⑤实战踩坑: 中文PDF需先转文本, 直接读二进制会出现乱码chunks [txt[i:i500] for i in range(0, len(txt), 500)] # ⑥500字切片: 太大检索不精, 太小丢上下文col.add(ids[f{f}-{i} for i in range(len(chunks))], documentschunks)def ask(q): # ⑦核心问答: 先检索再生成, 这是RAG减少幻觉的关键设计hits col.query(query_texts[q], n_results5) # ⑧取Top-5相关片段, 在相关性与上下文长度之间取得平衡ctx \n.join(hits[documents][0])# ⑨为什么这样写: 把检索到的真实片段拼进Prompt, 让模型基于内部资料作答, 答案可追溯且明显抑制编造prompt f你是FAB工艺助手, 仅依据以下资料回答, 不知道就说不知道:\n{ctx}\n问题: {q}r ollama.chat(modelqwen2.5:7b, messages[{role:user,content:prompt}])return r[message][content], hits[documents][0] # ⑩返回答案与引用来源, 供工程师核对真伪# build_kb([sop.txt,pert.txt,tool_manual.txt]) # 首次运行取消注释建库# print(ask(光刻机报警ALGN-04应该怎么处理?)[0])说明运行前需先 pip install ollama chromadb并确保Ollama已拉取qwen2.5:7b与nomic-embed-text模型。五、效果对比本地方案与云端方案到底差在哪对比维度本地Ollama RAG云端通用大模型查询准确率(内部文档)约 93%约 78%平均响应时间约 1.8 秒约 2.5 秒数据安全性完全离线, 不出厂需出内网, 有泄露风险综合成本一次性硬件 电费长期按调用量付费可追溯性返回引用片段无法定位来源上表是我厂内连续一个月的实际评估数据汇总覆盖了1200余次真实工艺问答。可以看到当问题涉及“本厂内部文档”时本地OllamaRAG的查询准确率反而高于云端通用大模型原因是云端模型并不知道我厂的SOP与设备手册只能凭通用知识猜测遇到“ALGN-04报警”这类厂内专有术语就只能含糊带过而本地方案因为检索到了真实处置文档回答更贴合现场且能给出具体的步骤编号与责任工序。响应时间上两者接近本地方案因走内网、省去公网往返首字延迟反而略快。数据安全与可追溯性则是本地方案的压倒性优势所有数据不出厂且每条回答都能定位到引用片段工程师可以逐条核对、审计留痕出了问题能回溯到知识来源。成本方面本地是一次性的硬件加电费投入长期使用边际成本趋近于零我们测算过一台二手工作站约几千元、7B模型常驻月电费仅几元而云端按量计费以每千token约一分钱估算1200次问答的月度账单就已超过本地硬件的摊销问答量越大本地越划算。我们还做了一组用户调研使用本地知识库后新人独立处理常见报警的比例从35%提升到78%平均处置耗时下降约60%。这说明知识库真正把“老师傅经验”变成了可复用的组织资产而不只是又一个没人维护的搜索引擎这正是它区别于传统文档系统的价值所在也是管理层愿意持续投入的原因。六、实施建议照着这四步落地更稳结合我的落地经验给出四条实施建议按优先级排序照着做能少踩很多坑。第一硬件配置。7B模型建议至少16G内存、理想32G并配备一张8G以上显存的消费级显卡可把生成速度提升数倍14B需要32G以上内存与更大显存。纯CPU也能跑只是首字延迟较高适合低并发场景。磁盘预留50G给模型权重与向量库并留足余量应对文档增长避免后期频繁迁移若文档量级很大可考虑把向量库放到独立的SSD上提升检索吞吐。第二Ollama部署。建议部署在独立的内网服务器仅厂内网可达配置开机自启服务避免重启后失联通过“ollama serve”暴露11434端口并在前面加一层反向代理与访问鉴权如令牌校验防止未授权人员访问敏感的工艺知识库同时限制并发数与单请求长度避免资源被挤占导致整体变慢对权限敏感的场景还可按角色控制“谁能问哪类文档”。第三知识库构建与运营。文档先做格式清洗与必要的OCR统一采用500字切片、50字重叠的策略选择中文友好的Embedding模型首次离线建库建立定期重建或增量更新机制——文档一旦变更就要及时同步否则知识库会“过期”并给每份文档打上“版本/生效日期”标签回答时优先引用最新版本从机制上避免旧规范误导对保密等级高的文档单独建集合并收紧访问。第四Prompt优化与监控。明确约束“仅依据资料回答、不知道就说不知道”能显著抑制幻觉要求模型标注引用来源与片段编号对专业术语保持原词不翻译加入“若资料不足请列出还需要哪些信息”的引导句把模糊问题转化为可执行的追问同时把关键指标检索命中率、无答案率、回答时延P95、用户点赞率做成看板持续迭代切片策略与Prompt模板让知识库越用越准、越用越稳。最后提醒一点知识库上线不是终点而是运营的起点。建议指定一名“知识库管理员”负责文档准入与质量定期清理过期内容并把高频问题沉淀回SOP形成“提问—沉淀—规范”的正向循环这样系统才会随工厂一起成长而不是上线半年就又变成没人管的摆设。七、进阶方向从问答走向诊断与预测如果基础RAG已经跑通下面三个方向值得继续投入投入产出比都很高也更能体现工程师的价值。其一微调LLM。当RAG仍不能满足精度时可以用厂内高质量问答对对Qwen2.5做LoRA微调让模型学会工厂专属的表达习惯与术语体系比如把“套刻偏差”与具体量测设备关联起来从而进一步提升专业度与稳定性尤其适合术语密集的工艺诊断场景让模型不只是“检索员”更是“领域专家”微调数据来自历史工单与SOP问答量不用大几百条高质量样本就能看到明显变化。其二Agent化知识库。把大模型从“问答机器人”升级为Agent使其能自主调用MES查询接口、数据库、计算器等多种工具去完成“查某批晶圆当前所在工序并预测完工时间”“对比两批产品的关键参数差异”这类复合任务而不只是被动回答单轮问题真正把知识库嵌入到工程业务流里成为工程师的协作者关键是要给Agent清晰的工具边界与回退策略避免它“自作主张”写数据。其三行业知识图谱。将工艺参数、设备、异常、处置之间的关联关系建成知识图谱再与大模型结合实现因果推理与根因分析让系统从“能问答”真正走向“能诊断、能预测”例如由一次良率异常反推可能的工艺步骤与设备辅助工程师快速定位根因当图谱与实时量测联动还能在异常发生前给出预警把事后救火变成事前预防这正是智能工厂想要的能力。需要强调的是这些进阶方向不必一步到位应该随业务成熟度分阶段推进先做稳RAG再考虑微调和Agent最后才谈知识图谱与预测。每一步都要有可量化的收益如处置时长、误报率作为继续投入的依据避免为了“先进”而先进毕竟工程的价值在于解决问题不在于堆技术。图1 本地大模型与云端大模型在查询准确率、数据本地化、离线可用性、成本可控性上的对比互动交流关于本地知识库, 你最该先想清楚的问题你所在的工厂, 目前最希望用本地大模型解决的第一个痛点, 是查资料慢, 还是工艺异常的诊断与归因?关于RAG检索效果, 一个值得讨论的取舍如果工艺文档更新非常频繁, 你会选择定时全量重建向量库, 还是做增量更新? 背后的考量是什么?blog.csdn.net/yeflashzhihui