FactoryLLM: 一个用于在智能工厂中评估LLM的安全开源AI试验场

arXiv cs.AI 论文

摘要

FactoryLLM是一个开源AI试验场,用于评估智能工厂故障诊断中基于LLM的RAG模型,支持本地LLM和双重评估指标。一项包含三个LLM的案例研究显示,在来自600页跨机器文档的30个维护查询中,接地性得分均超过0.88。

arXiv:2606.14119v1 Announce Type: new Abstract: 智能工厂中的故障诊断与恢复具有挑战性,因为关键信息分散在互联的多个机器的手册中。大型语言模型(LLM)提供了一种有前景的方法。本文提出了FactoryLLM,一个安全、开源的AI试验场,旨在通过分析制造过程中多个机器的文档来评估不同基于LLM的检索增强生成(RAG)模型。FactoryLLM允许用户配置LLM,并通过使用RAGAS和NVIDIA的LLM-as-a-Judge指标的双重评估设置,评估在多个文档上推理时的性能。FactoryLLM是安全的,因为它允许用户运行本地或开源LLM,而无需共享敏感的工业数据,从而提供了一个受控的实验环境。我们通过一个案例研究展示了FactoryLLM的有效性,该案例研究涉及一个自主智能车辆及其移动规划器软件,评估了三个LLM在来自约600页跨机器文档的30个维护查询上的表现。结果表明,FactoryLLM在跨机器文档推理上是有效的:每个模型的接地性得分均超过0.88。完整的代码和文档已公开,供社区使用其制造特定场景测试FactoryLLM。
查看原文
查看缓存全文

缓存时间: 2026/06/15 09:10

# FactoryLLM:一个用于评估智能工厂中大语言模型的安全开源AI沙盒
来源:https://arxiv.org/html/2606.14119

###### 摘要

智能工厂中的故障诊断与恢复极具挑战性,因为关键信息分散在多台机器的说明手册中,而这些机器通过制造过程相互关联。大语言模型(LLM)提供了一种有前景的方法。本文提出 FactoryLLM——一个安全、开源的 AI 沙盒,旨在通过分析制造过程中多台机器的文档,评估基于 LLM 的检索增强生成(RAG)模型。FactoryLLM 允许用户配置 LLM,并在对多个文档进行推理时,通过结合使用 RAGAS 和 NVIDIA 的“LLM-as-a-Judge”指标的二元评估设置来评估其性能。FactoryLLM 是安全的,因为它允许用户运行本地或开源 LLM,而无需共享敏感的工业数据,从而提供受控的实验环境。我们通过一个涉及自主智能车辆及其移动规划器软件的案例研究,展示了 FactoryLLM 的有效性,评估了三个 LLM 在约 600 页跨机器文档中衍生出的 30 个维护查询上的表现。结果表明,FactoryLLM 在跨机器文档推理方面是有效的:每个模型的接地性得分均高于 0.88。社区可用于在自身制造特定场景中测试 FactoryLLM 的完整代码和文档已公开提供。111https://github.com/DigitalInnovationLab/Factory-LLM

## I. 引言

现代工厂车间日益成为互联系统的系统,而非孤立机器的集合。机械臂、自主移动机器人、传送系统、可编程逻辑控制器和监控软件平台协同工作,协调生产流程[9](https://arxiv.org/html/2606.14119#bib.bib1),从而催生了“自愈工厂”。在这种环境中,故障很少孤立发生。一个组件中的故障可能传播到多台机器和软件层,导致生产线上出现级联中断。例如,自主智能车辆(AIV)意外停机可能阻碍下游物料搬运,使生产单元缺料,并迫使在互联系统间进行快速诊断。这些级联中断仍然是智能制造环境中最昂贵的运营挑战之一[14](https://arxiv.org/html/2606.14119#bib.bib2)。

尽管工业机器附有广泛的技术文档,但跨系统问题的诊断仍然困难。关键挑战不在于信息缺乏,而在于知识分散在多本使用不同术语和系统抽象概念编写的不同手册中。操作员通常需要查阅多台机器数百页的文档,以确定一个系统观察到的故障可能源于另一个系统。例如,AIV 报告的导航故障实际上可能源于其车队管理软件的配置问题,而非车辆硬件本身。识别此类关系需要跨多个文档和软件层连接概念。

现有方法在实现这种跨机器推理方面能力有限。当操作员查询与手册中使用的确切术语不匹配时,基于关键词的搜索难以奏效[15](https://arxiv.org/html/2606.14119#bib.bib3)。基于规则的专家系统需要大量手动知识工程,且随着设备演变难以维护[5](https://arxiv.org/html/2606.14119#bib.bib4)。知识图谱提供了机器关系的结构化表示,但随着机器数量增加,构建和维护成本变得高昂[16](https://arxiv.org/html/2606.14119#bib.bib5)。与此同时,经验丰富的技术人员的退休正在扩大专业知识缺口,使得能够诊断跨多个系统故障的操作员越来越少[14](https://arxiv.org/html/2606.14119#bib.bib2)。

大语言模型(LLM)为解决这些挑战提供了一种有前景的方法。与基于规则或关键词驱动的系统不同,LLM 能够解释自然语言查询,理解语义关系,并从大量非结构化文档中综合信息[7](https://arxiv.org/html/2606.14119#bib.bib8)。这一能力使它们能够充当操作员与复杂技术文档之间的中介层。检索增强生成(RAG)可以进一步增强这一能力,将 LLM 的响应建立在检索到的文档之上,而非仅依赖模型的训练数据[6](https://arxiv.org/html/2606.14119#bib.bib10)。虽然有几项研究使用了基于 LLM 的检索来查找单个机器的文档,但很少有研究调查它们在多个机器和异构技术手册上进行推理的能力。跨机器推理引入了额外挑战,包括对齐跨文档的术语、从长篇手册中检索相关信息,以及综合来自多个来源的证据来解释故障场景。

为研究这些挑战,我们提出 FactoryLLM——一个安全、开源的 LLM 沙盒,旨在评估基于 LLM 的 RAG 系统在跨制造过程中多台工业机器文档进行推理时的表现。FactoryLLM 不仅作为故障排除助手,更提供一个受控的实验环境,不同的基于 LLM 的 RAG 系统——包括保护隐私的本地或开源模型——可以被接入并系统评估。该平台还提供了在真实制造场景下评估检索和生成能力的稳健指标。我们通过一个来自智能工厂中两个紧密耦合系统的真实案例研究来展示 FactoryLLM 的适用性:AIV 和 Mobile Planner 软件。AIV 是一种用于在工厂车间运输物料的自主移动机器人,而 Mobile Planner 是负责分配任务、控制导航参数和协调多辆车辆的车队管理软件。由于系统的操作行为源于车辆硬件与车队管理软件之间的交互,故障经常同时表现在两个组件上。这使得 AIV–Mobile Planner 生态系统成为评估跨文档推理的合适测试案例。利用这两个系统的技术手册——每本包含数百页文档——我们展示了 FactoryLLM 如何检索相关信息并综合出有根据的解释,帮助诊断跨多台机器的问题。通过这个案例研究,我们展示了 FactoryLLM 如何支持这种跨机器/文档的推理。具体来说,本文做出以下贡献:

- • 我们提出 FactoryLLM,一个旨在支持跨多台机器和过程的多个异构文档进行推理的 LLM 沙盒。
- • 我们通过一个涉及 AIV 机器人及其 Mobile Planner 车队管理系统的真实智能制造案例研究,展示了 FactoryLLM 在评估跨机器故障排除场景中的有效性。
- • 我们评估了多个 LLM 和提示策略,以评估跨机器推理性能。

本文的其余部分组织如下。第 II 节回顾了 LLM 和 RAG 在制造业中的相关工作。第 III 节描述了 FactoryLLM 的系统架构。第 IV 节介绍了案例研究的设置。第 V 节讨论了结果和评估。第 VI 节对全文进行了总结。

参见图注 图 1:FactoryLLM 系统架构。来自多台机器的技术文档被摄入到聊天作用域索引中。在查询时,检索到的上下文集被传递到一个可配置的推理层,该层支持 IO、CoT、ToT 和 GoT 提示策略,然后生成有根据的响应。

## II. 相关工作

在本节中,我们探讨当前在利用 LLM 改进制造业工作流推理和理解方面的现代努力。

A. 制造业中的 LLM。大语言模型在制造业中的应用正在快速增长。Li 等人[7](https://arxiv.org/html/2606.14119#bib.bib8) 对 LLM 在生产规划、质量保证和维护中的使用进行了全面调研;指出尽管 LLM 似乎非常擅长理解制造业中的非结构化数据,但领域适应和处理来自许多不同工业机器的多样化数据等问题仍然存在。Raza 等人[11](https://arxiv.org/html/2606.14119#bib.bib6) 回顾了多个行业中工业 LLM 的应用,并观察到大多数实现仍然针对特定行业,仅涵盖一两个领域,并且跨机器的泛化能力较弱。特别是在维护方面,Getz 和 Tong[4](https://arxiv.org/html/2606.14119#bib.bib12) 使用 LLM 从一家大型航空航天制造商的维护日志中提取信息,发现除非数据经过精心准备,否则 LLM 的性能会因技术术语、缩写和不一致的格式而大大降低。Wang 等人[1](https://arxiv.org/html/2606.14119#bib.bib13) 开发了一个基于 LLM 的飞机面板钻孔认知助手,通过识别意图和提取参数来降低非熟练操作员的认知负担。虽然这些研究显示了 LLM 在单一制造任务中的潜力,但没有一项研究解决跨文档/领域推理的问题——即来自一套互联机器的多个文档——而使用所提出的 FactoryLLM 可以评估的多机器场景正是真实智能工厂的典型情况。

B. 工业文档的 RAG。检索增强生成已成为将 LLM 植根于特定领域内容的最流行方法。Lewis 等人[6](https://arxiv.org/html/2606.14119#bib.bib10) 引入了 RAG 框架,并证明将检索到的上下文添加到语言模型中能极大地提高知识密集型任务中的事实正确性。最近的一些研究在制造环境中使用了 RAG。Kernan Freire 等人[3](https://arxiv.org/html/2606.14119#bib.bib9) 为一家洗涤剂制造商的工厂工人开发了一个基于 RAG 的知识共享工具,评估了七个 LLM,发现 GPT-4 的事实性最高,而开源模型具有可比性能,且幻觉率更低。Zhang 等人[16](https://arxiv.org/html/2606.14119#bib.bib5) 为博世开发了一个增强型图 RAG 维护聊天机器人,处理了来自五个生产站的 49 个文档,发现标准向量 RAG 在维护问题上的精度较低,从而推动了知识图谱增强方法的开发。Liu 等人[8](https://arxiv.org/html/2606.14119#bib.bib11) 提出了一种使用基于 BERT 的查询分类的混合 RAG 技术,用于工业问答,并报告了与基本 LLM 相比的显著准确性提升。然而,这些系统中的每一个都是为单一机器类型或单一生产设置而设计的。它们中没有进行跨机器检索和推理——同时结合不同交互设备的硬件和软件文档的响应。

C. RAG 系统的评估。必须评估 RAG 生成响应的质量,尤其是在安全至关重要的领域,因为错误的建议可能产生实际影响。RAGAS 框架[2](https://arxiv.org/html/2606.14119#bib.bib15) 提供了无参考、基于 LLM 的评估,使用诸如忠实度(声明是否得到检索上下文的支持)、答案相关性(响应是否回答了查询)、上下文精度(检索上下文的信噪比)和上下文召回(是否检索到了所有必要信息)等指标。ARES[13](https://arxiv.org/html/2606.14119#bib.bib16) 使用合成数据微调轻量级评估器,并提供统计置信界限。Roychowdhury 等人[12](https://arxiv.org/html/2606.14119#bib.bib17) 在电信领域评估了 RAGAS 指标,发现基于余弦相似度的自动评分对于专业技术词汇可能不可靠——这一发现对制造业非常重要,因为该领域领域特定词汇很常见。尽管可用的评估工具越来越多,但很少有研究使用标准化评估来评估在制造维护环境中操作的 LLM。大多数现有研究依赖于临时间题集和人工检查,使得不同研究之间的结果难以比较。

D. 总结与研究空白。文献显示了几个反复出现的空白。首先,当前的制造业 RAG 系统是为单文档或单机器情况构建的,不允许跨不同机器进行跨机器推理。其次,大多数实现是专有的,限制了可重复性。第三,没有使用标准化评估指标系统性地测试多个 LLM 和提示策略在制造维护任务上的研究。FactoryLLM 填补了所有这些空白:它是一个开源的多文档 RAG 平台,接收来自 AIV 及其 Mobile Planner 软件两者的文档,允许多个 LLM 和提示技术的并排比较,并使用 RAGAS 框架进行标准化评估——为跨机器维护推理研究提供了可重复的基线。

## III. 系统概述:FactoryLLM

本节介绍 FactoryLLM 架构的概述。如图 1 (https://arxiv.org/html/2606.14119#S1.F1) 所示。FactoryLLM 被设计为一个六层流水线,摄入由多台机器生成的技术文档,并产生有充分依据且明确可追溯到其源文档的问答输出。每一层都履行不同的功能角色,共同实现可靠的知识摄入、检索、推理、交互和存储。在此结构基础上,FactoryLLM 采用模块化、配置驱动的设计范式,强调对异构技术来源的可重复性、透明性和灵活推理。会话作用域索引和持久存储确保实验隔离和完全可追溯性,而清晰的关注点分离支持对检索和提示策略的系统比较、跨机器推理以及通过基于聊天的界面进行人在环控制。下面详细描述各层架构。

配置层:在处理任何用户查询之前,此层使操作员能够定义两组参数,分别控制任务和交互级别的系统行为。在任务级别,操作员选择底层 LLM 提供商(例如,OpenAI、OpenRouter、Google Gemini 或本地托管的模型)、提示策略(包括输入-输出、思维链、思维树或思维图提示),以及可选的初始系统消息,该消息指定聊天助手的角色和行为约束。

在交互(聊天)级别,操作员将 RAG 策略配置为基于向量或基于图,并指定要检索的 top-kk 个文档部分的数量。所有配置设置都持久存储在数据库中,从而确保实验的完全可重复性。

相似文章

LLM Agents Factory: Retrieval of Domain-Specific LLM Agents

arXiv cs.CL

The paper presents LLM Agents Factory, a retrieval-based framework that constructs domain-specific LLM agents from a base of over 20K predefined agent profiles, offering a cost-efficient and controllable alternative to dynamic agent generation. Experiments show accuracy comparable to AutoGen with a 120B backbone at substantially lower inference cost.

AI SYSTEM DESIGN系列博客第二篇

Reddit r/ArtificialInteligence

本文讨论了如何针对特定生产用例对LLM进行基准测试,提出了一套全面的评估流程,包括任务特定指标、质量与成本的权衡,以及失败案例分析。

大语言模型与本地AI硬件的推理引擎(2026版)

X AI KOLs

本文提供了一份全面的指南,针对2026年本地AI硬件上的大语言模型推理引擎,解释了如何根据硬件策略、工作负载和服务模型进行选择,并涵盖了诸如llama.cpp、MLX、ExLlamaV2/3、vLLM、SGLang、TensorRT-LLM和NVIDIA Dynamo等引擎。