上个月我们团队给东莞一家大型制造企业做了一套设备知识库AI问答系统。客户的需求很简单：车间工人遇到设备故障，直接用自然语言提问，AI从几万页的SOP手册里找到答案。听起来很常规的RAG项目，实际踩坑踩得我们头大。

业务背景
这家工厂有30多条生产线，设备型号杂、手册版本多。老办法是出了问题翻PDF手册，一本手册几百页，新人根本找不到。客户老板的预期是：上了AI，问答准确率90%以上，工人随问随答。

架构决策
我们选的技术栈：LangChain + 向量数据库（Milvus） + 本地部署的7B开源模型。为什么不用GPT-4？因为工厂的设备手册属于内部资料，不能出内网。为什么不用更大的模型？因为车间工控机配置一般，推理速度要够快。
架构很常规：文档解析 → 切片 → 向量化 → 检索 → Prompt拼装 → 大模型生成。跑demo的时候效果很好，测试集准确率85%，客户当场拍板。

踩坑与解决
坑一：切片策略踩了大雷。
一开始我们用固定长度切片，500字一段。结果发现很多设备参数表被拦腰切断，检索出来的片段缺头少尾。工人问"3号注塑机的液压压力正常值是多少"，检索到的片段只有结尾的数字，没有上下文，大模型直接瞎编。
解法：我们改成了"语义切片+表格保留"策略。用大模型做文档结构识别，标题层级、表格、参数列表单独成块。切片从500字调到300字，但保留上下文重叠100字。改完之后，表格类问题的准确率从40%涨到了78%。

坑二：检索召回率虚高。
测试的时候我们拿标准答案去搜，相似度都很高，看起来召回没问题。但上线后工人的提问方式五花八门，有的带方言口音，有的夹杂设备编号缩写。比如"那台东洋机的模温不对"，向量检索根本匹配不上"TOYO注塑机 模具温度"。
解法：加了一层Query改写。先用小模型把用户的口语化提问改写成标准的技术描述，再去检索。同时建了一个设备别名词典，把"东洋机"“东机"都映射到"TOYO牌注塑机”。这一层加上之后，召回率提升了30%。

坑三：大模型一本正经胡说八道。
这是最头疼的问题。检索到的材料里没有答案的时候，大模型不会说"我不知道"，反而会编一个看起来很像那么回事的答案。车间工人要是信了，调错参数损失几万块。
解法：两道保险。第一道，Prompt里强制要求"如果检索材料中没有相关信息，必须回答：未在知识库中找到相关内容"。第二道，加了一个置信度判断，检索相似度低于阈值的直接拒答，不进大模型生成。上线后胡编率从20%降到了3%以下。

成效数据
项目上线两个月，数据是这样的：

日均问答量：200+次
问题解决率：从原来的翻手册30%提升到AI辅助下的75%
新人培训周期：从2周缩短到5天
工程师现场支持频次：下降了40%

写在最后
RAG不是把文档扔进向量数据库就完事了。切片、检索、拒答策略，每一环都可能翻车。尤其是工业场景，对准确性要求极高，宁可拒答也不能瞎编。
我是深圳富贵软件科技的老张，专注AI落地与政企数字化转型。如需技术评估或避坑指南，欢迎私信。