Langchain-Chatchat构建制造业工艺文件查询系统实例

在智能制造加速推进的今天，工厂车间里的老师傅越来越少，而新员工面对堆积如山的工艺手册、SOP文档和质检标准时，常常一脸茫然。一个简单的操作问题，可能要翻遍十几份PDF才能找到答案——这不仅耽误生产节奏，还容易因理解偏差引发质量事故。

有没有一种方式，能让工人像问“小助手”一样，直接说出：“A型电机拧紧扭矩是多少？”就能立刻得到准确答复？更重要的是，这些敏感的制造数据不需要上传到任何云端，完全保留在企业内网中？

这就是我们今天要探讨的技术路径：基于 Langchain-Chatchat 构建本地化、可落地的制造业知识问答系统。它不是科幻概念，而是已经可以在普通服务器上运行的真实解决方案。

---

这套系统的底层逻辑其实并不复杂——把散落在各处的工艺文件变成AI能“读懂”的知识库，再通过大模型用自然语言回答问题。但实现过程中涉及多个关键技术点的协同：如何高效解析中文PDF？怎么切分文本才不会打断关键参数说明？选择哪个模型既能理解专业术语又不占用太多显存？

先来看整个流程的核心骨架：

用户提问 → 问题向量化 → 向量数据库检索 → 获取相关段落 → 注入提示词 → LLM生成答案

这个链条看似简单，每一步却都有讲究。

比如文档加载阶段，很多系统直接用通用OCR或文本提取工具处理PDF，结果遇到扫描件就失效，或者表格内容错乱。但在实际工艺文件中，大量关键信息是以表格形式存在的，比如热处理温度曲线、材料成分比例等。Langchain-Chatchat 支持多种加载器组合使用，像 PyPDFLoader 处理可读PDF，配合 UnstructuredPDFLoader + OCR 模块应对扫描件，确保无一遗漏。

再看文本分块（chunking）。如果机械地按500字符一刀切，很可能把“扭矩范围：18~22N·m”这样的完整条目拆成两半，导致后续检索失败。因此我们会采用 RecursiveCharacterTextSplitter，优先按段落、句子边界切分，并设置重叠窗口（overlap），让上下文得以保留。

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50,
    separators=["\n\n", "\n", "。", "；", " ", ""]
)

这里的技巧是自定义分隔符顺序，优先以双换行、句号结束处切割，避免破坏语义完整性。尤其对中文文档，“。” 和 “；” 往往标志着一个完整工艺指令的结束。

接下来是向量化环节。很多人会直接用开源的 all-MiniLM-L6-v2 这类英文通用模型，但在中文工业场景下效果很差。“回火”和“退火”在语义空间里本应相近，但英文模型根本不懂这两个词的关系。所以我们必须选用专为中文优化的嵌入模型，例如智谱AI发布的 BGE-small-zh-v1.5：

embedding_model = HuggingFaceEmbeddings(model_name="bge-small-zh-v1.5")

这款模型在中文语义匹配任务上表现优异，且体积小、推理快，非常适合部署在边缘设备上。实测显示，在包含300份工艺文件的知识库中，其召回率比通用模型高出近40%。

构建好向量数据库后，就可以接入检索增强生成（RAG）流程了。这里 LangChain 的作用凸显出来——它就像一个粘合剂，把原本孤立的模块串联成一条流畅的工作链。

qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=vectorstore.as_retriever(search_kwargs={"k": 3}),
    return_source_documents=True
)

其中 chain_type="stuff" 表示将所有检索到的上下文拼接后一次性输入给LLM；k=3 控制返回最相关的三个片段。太少会导致信息缺失，太多则引入噪声干扰判断。我们在某汽车零部件厂的实际调优中发现，k=3 是精度与效率的最佳平衡点。

至于大语言模型的选择，更是直接影响用户体验的关键。7B级别的模型如 ChatGLM3-6B 或 Qwen-7B 已足够胜任大多数问答任务，且可在单张RTX 3090上流畅运行。若追求更高准确性，也可部署 Qwen-14B 或 InternLM-20B，但需要双卡及以上配置。

值得一提的是，这类系统并不依赖模型“记住”所有知识。它的核心思想是“实时查证”——每次回答都基于当前检索到的最新文档片段。这意味着即使模型本身没有训练过某种新材料的加工参数，只要该信息已录入知识库，就能准确输出。这种机制有效规避了传统LLM常见的“幻觉”问题。

更进一步，我们还可以加入权限控制机制。例如，普通操作工只能查询装配步骤，而工艺工程师才能查看设计图纸中的公差标注。通过集成企业现有的 LDAP/AD 账号体系，实现细粒度访问控制：

[前端界面] ←HTTP/API→ [Chatchat服务端]
                             ↓
               [文档解析模块] → [文本分块]
                             ↓
                  [嵌入模型] → [向量数据库]
                             ↑
                   [LLM Runtime] (本地部署)

整个架构完全运行于内网，无需外联互联网，符合工业信息安全三级等保要求。甚至可以将总装车间、质检区等关键区域部署独立的边缘节点，利用 Redis 缓存高频查询结果，把响应时间压缩到1秒以内。

那么这套系统到底解决了哪些现实痛点？

首先是信息孤岛。过去，焊接参数可能藏在技术部的共享盘里，装配顺序写在车间白板上，更新记录分散在微信群聊中。现在，所有文档统一归集、自动索引，真正做到了“一处更新，全局生效”。

其次是培训成本高。新员工上岗前不再需要死记硬背上百页手册，而是边干边学，随时提问。有家电子制造企业反馈，使用该系统后，新人独立上岗周期从平均两周缩短至三天。

最后是合规审计难。传统纸质查阅无法留痕，出了质量问题难以追溯责任。而现在每一次查询都被记录：谁、在什么时间、问了什么问题、得到了哪份文档的支持。这对ISO质量管理体系认证提供了强有力的数据支撑。

当然，落地过程也不是一帆风顺。我们在某重型机械厂实施时曾遇到一个问题：老版本工艺文件仍需保留归档，但不能参与当前查询。解决方案是在向量入库时添加元数据标记：

doc.metadata = {
    "filename": "welding_process_v2.pdf",
    "version": "v2",
    "status": "active",  # 或 deprecated
    "department": "welding"
}

然后在检索时过滤状态为 active 的文档：

retriever = vectorstore.as_retriever(
    search_kwargs={
        "k": 3,
        "filter": {"status": "active"}
    }
)

这样一来，系统永远不会推荐已被废止的操作规范。

另一个常见挑战是专业术语的理解。比如“TIG焊”和“钨极惰性气体保护焊”其实是同一个工艺，但如果不做处理，向量空间里它们的距离很远。对此有两种优化方式：

一是使用同义词扩展，在预处理阶段进行术语归一化；
二是微调嵌入模型，加入领域语料进行继续训练（Continual Pretraining）；

后者效果更好，但成本较高。对于大多数制造企业而言，前者已足够应对日常需求。

值得强调的是，这套系统并非追求“全自动智能”，而是倡导“人机协同”。LLM给出的答案始终附带原文出处链接，供用户进一步核验。毕竟，在关乎产品质量和安全生产的领域，最终决策权必须掌握在人手中。

未来，随着专用工业大模型的发展，这类系统的能力还将持续进化。我们可以设想这样一个场景：当设备传感器检测到异常振动时，系统自动检索同类故障的历史维修记录，结合当前工况生成处置建议，推送到维修人员的手持终端上——这正是“知识驱动制造”的雏形。

技术终将服务于人。Langchain-Chatchat 的价值，不只是让机器学会读文档，更是让每一位一线工作者都能平等地获取知识，把经验转化为可复用的资产。而这，或许才是智能制造最本质的意义所在。