使用大型语言模型创建、评估和验证仿真模型

《Neurocomputing》：Creation, evaluation and self-validation of simulation models with large language models

本文提出了一种综合框架，用于评估大型语言模型（LLMs）在机械工程仿真模型生成与验证中的能力。通过设计多体动力学测试案例，结合Python的Exudyn库进行数值仿真，系统分析了LLMs在生成正确代码和执行验证中的表现。研究发现，部分模型如QwenCoder-32B-Q4和Phi-4在代码执行和物理正确性上表现优异，但仍有参数误解、约束错误等典型问题，验证了基于数值结果的自动化评估方法的必要性。

　　近年来，随着人工智能技术的迅猛发展，大型语言模型（LLMs）在多个领域展现出了巨大的潜力。然而，当前的研究和数据集主要集中在文本处理、编程语言理解和生成、教育辅助以及写作任务等，对工程领域，尤其是机械工程任务的关注相对较少。这与机械工程任务的复杂性和实际重要性形成了鲜明对比。机械工程问题往往需要深入的数学理解，并且涉及文本描述、视觉表示和数值数据的综合运用。此外，机械工程通常依赖于公认的近似和模型，而非精确值。因此，本文提出了一种综合框架，用于自动化生成和验证机械工程模拟模型，特别是基于Python的多体动力学（MBD）模拟模型。

### 1. 引言

LLMs的出现极大地改变了多个领域，从教育和写作到科学发现和软件开发。随着这些模型能力的不断提升，研究人员开始探索其在工程任务中的应用。然而，工程任务往往具有独特的挑战，如对专有或标准化技术数据的访问受限、复杂的物理定律和符号表示推理、以及缺乏能够评估功能正确性的基准。虽然机器学习在图像分类任务上取得了突破，许多工程应用也受益于神经网络方法，如在机器人计算机视觉、信号处理和故障诊断等领域。然而，LLMs在工程任务上的应用仍处于初级阶段，相较于其在写作、教育或编码等领域的广泛应用。

在工程模拟领域，现有的评估方法主要依赖于生成代码与专家编写参考代码或API文档的比较。这些方法往往局限于代码结构和语法层面，而未能准确反映实际功能表现。因此，本文提出了一种基于物理结果的评估方法，以独立于代码结构的方式评估模型的正确性。这一方法为LLMs在工程任务中的应用提供了一个新的方向。

### 2. 机械建模与模拟代码生成

在本文中，我们专注于评估LLMs在机械建模和模拟代码生成方面的能力，特别是多体系统动力学。为了系统地测试LLMs的性能，我们定义了机械问题、代码生成流程以及代码评估指标。

#### 2.1 机械问题定义

本文的系统性测试基于一组机械问题。为了保持方法的通用性，这些问题被统一称为机械问题。每个机械问题包含一组特定的建模元素，如地面物体、刚体、质量点、约束、关节或外力。这些元素构成了模拟代码的基础。在本文中，我们采用参数化模型描述，通过替换参数值（用大括号表示）来生成多个语义一致的变体，从而确保测试的多样性。

#### 2.2 LLM用于代码生成

LLMs通常被用作生成模型，它们可以生成文本，但无法执行任务。为了解决这一问题，一些基于LLM的代理框架被提出，如ReAct和LangChain，这些框架允许代理根据上下文和预定义目标选择并执行操作。与这些通用代理不同，本文提出的框架专门针对模拟代码生成和评估，强调确定性推理、系统性错误处理和可靠的模拟后端集成。

在本文中，LLM代理被用于模拟代码的生成和评估。代理的任务包括选择相关的模拟元素和评估方法，生成对应的模拟代码，并分析模拟结果。我们尽量采用确定性的行为，通过多次测试确认了这一点。此外，我们通过系统异常处理和错误检查，将代理嵌入到一个可控且容错的环境中，以提高可靠性。

为了支持跨环境的推理，我们使用了Hugging Face的transformers管道和GPT4All框架。Hugging Face的transformers管道适用于通用LLMs，而GPT4All则优化了GGUF格式模型的推理。GGUF格式允许高效的本地推理，使得预量化模型能够在消费级硬件上运行，而无需复杂的设置。

为了确保评估在不同部署场景中的代表性，我们根据可用硬件选择了LLMs，并在必要时使用量化模型以满足资源限制。具体而言，我们使用了两块NVIDIA H100 GPU进行高端推理，并使用一块消费级RTX 4090进行本地执行。

尽管推理模型如DeepSeek R1和OpenAI O1在多个基准测试中表现优异，但它们较大的模型规模、较低的吞吐量以及输出质量未明显提升，使得它们不是本文的主要关注点。本文的评估集中在小型的开放权重模型上，这些模型可以在本地运行，这对于进一步微调模拟代码生成至关重要。

#### 2.3 代码生成流程

在本文中，我们描述了如何将文本描述转换为模拟代码。我们使用了Python包Exudyn，它是一个专为工程师设计的模拟引擎，基于物理原理，并在多体系统科学界广泛使用。在之前的实验中，我们已经展示了LLMs可以将文本描述直接转换为模拟代码，使用如ChatGPT等闭源、大上下文能力和商业LLMs。Exudyn不仅提供了简单的建模语言，还简化了LLM的任务，因为其命令完全以自然语言编写。

然而，我们发现，如果缺乏适当的上下文，这种方法的可靠性会显著降低。为了改善这一点，我们在本文中采用了一种类似但更精细的方法，适用于较小的开源LLMs。此外，我们还利用LLM代理在循环中运行，以生成和评估数百个模拟代码，仅需10到30分钟即可完成。

在生成代码的过程中，我们使用了一个包含建模元素和评估方法的模板，以确保代码的准确性。我们特别注意到了某些LLMs对Exudyn语法的不完全理解，这可能导致代码生成失败。因此，我们设计了优化的提示语，以帮助LLMs正确理解建模元素和评估方法。

#### 2.4 基础代码评估

由于LLMs生成的模拟代码数量庞大，系统地评估其质量成为一个挑战。我们需要一种方法来区分高质量、正确的代码与不完整、错误或产生错误结果的代码。这反映了LLMs领域中一个普遍的问题：如何评估生成的输出是否符合任务要求。

我们引入了一种基础的代码评估方法，该方法基于选定机械模型的地面真实实现。通过将生成的代码与地面真实代码进行比较，我们可以评估其正确性。地面真实代码由领域专家精心准备和测试，而不会提供给LLMs。无论是专家生成的代码还是LLMs生成的代码，都使用相同的模型参数进行评估，以确保可比性。

在代码生成之后，我们对生成的代码进行后处理，主要是提取Python代码并删除不需要的内容，如“Here is the requested code:”或“os.system(…)”。这一步骤是必要的，因为LLMs的输出格式可能有所不同，有时会偏离提示约束。

#### 2.5 基础评估结果

我们对生成的模拟代码进行了评估，使用了包括Llama、Calme、Mistral和Qwen在内的多个SOTA LLMs。每个LLM被要求为一组预定义的物理问题生成模拟代码，这些问题由35个文本模型描述组成。我们还提供了一个概述这些机械模型的表格，展示了主要的建模元素。

评估结果显示，某些LLMs在生成正确模拟代码方面表现优异，而另一些则存在较大的问题。例如，QwenCoder-32 B-Q4仅生成了两段不可执行的代码，并且只有很少的错误。这表明QwenCoder在编码任务中具有优势。此外，我们还观察到，某些模型的参数化方式可能影响代码的生成质量。因此，我们需要确保模型参数化的方式不会导致不必要的复杂性。

#### 2.6 扰动分析与提示

为了研究LLMs对提示格式变化的敏感性，我们进行了一项扰动分析。我们对机械模型的文本描述进行了一些结构上的微调，如插入额外的空格、替换标准句子分隔符（例如“.”）为“.$$ n”等。每个扰动版本由一个唯一的变体标识符（variation ID）区分，其中ID随着扰动程度的增加而递增。

我们计算了生成代码之间的配对Levenshtein距离矩阵，以量化语法差异。距离值是通过计算将一个字符串转换为另一个字符串所需的最少单字符编辑次数（插入、删除或替换）来确定的。距离值被归一化以确保可比性。此外，我们还分析了模拟结果，发现某些模型的生成代码存在结构和正确性方面的显著差异。

### 3. 使用LLM代理进行模拟模型的自验证

在本节中，我们探讨了使用LLM代理进行模拟模型自验证的概念。与传统的LLMs仅用于生成或评估不同，我们的方法将地面真实数据直接集成到模拟环境中，以减少LLMs可能带来的偏差。

#### 3.1 基于AI代理的模型验证框架

我们设计了一个模型验证框架，该框架通过模拟环境中的AI代理进行自验证。该框架包括两个嵌套循环：外循环遍历所有可用模型，内循环对每个模型进行验证。我们首先为每个模型选择一组评估方法，然后要求LLM生成模拟代码，并评估其正确性。

为了确保验证的准确性，我们使用了XML标签来标记相关的输出，如将猜想（conjecture）包含在“$$ conjecture $$ /conjecture”标签中。这种方法在实验中表现良好，因为LLMs已经习惯了这种结构。

#### 3.2 单个模拟结果的提取

模拟结果的提取是关键任务，因为我们需要确保所有机械模型类型的提取结果一致。在所有分析案例中，我们定义了从模型描述、评估方法和传感器信息中提取的模拟文本分析结果。例如，对于系统分析方法，如特征值，我们只提取了前12个特征值，而省略了特征向量。对于传感器，我们首先将其数据重新采样为11个步骤。

为了确保数值数据的准确性，我们限制了提供的数字位数，并使用动态四舍五入，独立于浮点数的指数部分。大多数LLMs在基本代数运算中能够处理四舍五入的数字，因为我们需要2%的精度来判断模型是否正确。

#### 3.3 单个模拟结果的评估

我们测试了两种评估方法：基于猜想的评估和直接评估。基于猜想的评估方法涉及将LLM生成的猜想与模拟结果进行比较，但这种方法经常导致错误的结果，因此被放弃。相反，直接评估方法跳过了猜想，并直接使用评估方法来评估原始数值模拟结果。这种方法提供了更可靠的结果，并且与基于猜想的方法相似。

在评估过程中，我们使用了LLM生成的分数，将结果封装在特定的标签中，如“$$ score $$ 75 $$ /score”。数值评估分数由LLM返回，并用于判断模拟结果是否符合任务要求。

#### 3.4 模拟模型的验证

对于每个模型，无论其是否正确（与数值地面真实进行比较）或是否故意错误，我们开发了不同的评估指标，要求每个模型至少进行五次评估。我们考虑了两种主要的评估指标：一种是所有个体评估分数的平均值，另一种是基于个体评估分数的二元分类标准。

在本文中，我们专注于第二种指标，即基于个体评估分数的二元分类标准。如果超过一定数量的评估分数低于阈值，则模型被归类为错误。这种方法提高了评估的鲁棒性，因为某些模拟可能在物理上合理，但存在错误。

### 4. 讨论

我们的实验结果表明，LLMs能够生成成功的Python代码来模拟机械模型，一些LLMs在代码执行和模型正确性方面取得了非常高的分数。通过使用数值地面真实数据进行自动评估，我们可以选择适合进一步任务的LLMs，并估计其在工程应用中的性能和能力。自验证框架的高得分表明其在工程任务中的实用性。

然而，我们也观察到了一些常见的错误模式和问题。例如，某些符号如“$$”（例如用于长度参数）被错误使用，而没有被赋予值，特别是在Phi-4模型中。此外，几何描述缺乏图表的情况下，常常对局部坐标系与全局坐标系的区分、质心位置和关节的相对坐标存在误解。

另一个挑战是确定正确的自由度（DOFs）计数。尽管明确说明了所有质量点具有三个自由度，但某些LLMs错误地将弹簧元素视为约束，或计算自由度时出错。因此，基于自由度的评估方法未被采用。

方向的解释也是一个重要的问题。例如，重力通常被假设为沿负y轴方向作用，即使明确指出应为其他方向。此外，求解器相关的问题也时有发生，特别是在随机测试案例中，默认的求解器设置可能不足以实现收敛。

通过为每个物理问题分配一个对应的难度等级，我们能够量化LLMs在模拟代码生成方面的局限性。然而，在自验证方面，我们并未发现物理问题复杂性与LLMs设计和执行适当验证实验的能力之间存在一致的相关性。

为了平衡令牌限制和结果精度，我们提供了数值地面真实数据，其时间分辨率被降低，并且仅保留四位有效数字。虽然这种方法在大多数情况下有效，但在某些情况下，如阻尼振荡器的衰减行为，可能掩盖了关键效果。在这种情况下，LLMs的进一步调整可能会有所帮助。

此外，我们发现某些模型描述包含了公认但未明确陈述的假设，这可能导致性能下降。尽管某些LLMs能够通过“直觉”正确的假设生成正确的模型，但这些不一致性难以自动处理，代表了一个重要的未来研究方向。

### 5. 结论

本文提出了一种基于上下文学习和特定RAG方法的框架，用于自动化生成和验证机械工程模拟模型，特别关注质量点、刚体和关节的建模。尽管LLMs在生成代码方面表现良好，但在更复杂的任务，如柔性体、模拟器耦合、复杂接触问题或高级用户功能方面，仍有待进一步研究。此外，我们还提到可以对Exudyn的现有文本描述和模拟模型进行整理，并合成更大的样本集用于现有LLMs的微调。然而，初步测试表明，基于上下文的方法比专门训练的LLMs更可靠。

本文的成功方法可能推动AI在机械系统模拟和建模中的进一步整合。虽然我们研究了常见的机械问题，但未来的方法可以用于优化或研究任务，以解决开放的工程问题。此外，LLMs在本文中还用于代码生成、AI代理以及拼写检查、文本改进和从母语到英语的翻译，这表明LLMs在工程任务中的广泛应用潜力。