一、问题背景：为什么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明显优于同尺寸的Llama3；Phi3虽然体积小、跑得快，但中文能力偏弱、且在长文档上容易丢失信息。如果服务器内存有限（比如16G），可以用Qwen2.5:7b（4-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类通用大模型对比：云端模型参数更大、通用知识更强，但数据要出内网、按调用量收费、并且存在合规风险；本地Ollama+RAG数据不出厂、一次部署长期免费，劣势是需要自有硬件，且领域问答质量高度依赖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问答骨架。代码以注释形式标明了“为什么这样写”，便于你理解每一处设计取舍。

说明：运行前需先 pip install ollama chromadb，并确保Ollama已拉取qwen2.5:7b与nomic-embed-text模型。

五、效果对比：本地方案与云端方案到底差在哪

上表是我厂内连续一个月的实际评估数据汇总，覆盖了1200余次真实工艺问答。可以看到，当问题涉及“本厂内部文档”时，本地Ollama+RAG的查询准确率反而高于云端通用大模型，原因是云端模型并不知道我厂的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