LLMR: Real-time Prompting of Interactive Worldsusing Large Language Models
LLMR-使用大型语言模型的交互式世界实时建模
ABSTRACT
我们提出了混合现实的大语言模型（LLMR），一个使用LLM实时创建和修改交互式混合现实体验的框架。LLMR利用新颖的策略来解决理想训练数据稀缺的困难情况，或者设计目标需要综合内部动态、直观分析或高级交互性。我们的框架依赖于文本交互和Unity游戏引擎。通过整合场景理解、任务规划、自调试和内存管理技术，LLMR在平均错误率方面比标准GPT-4超出4倍。我们展示了LLMR的跨平台的互操作性与几个例子的世界，并评估它的各种创建和修改任务，以表明它可以产生和编辑不同的对象，工具和场景。最后，我们进行了一项可用性研究（N=11），其中包含一组不同的数据，显示参与者对系统有积极的体验，并会再次使用它。
CCS CONCEPTS
计算方法→空间和物理推理;多智能体系统。
1 INTRODUCTION
创建3D虚拟世界是一项具有挑战性的任务，需要艺术和技术技能。此外，由于平台和设备升级，3D内容通常会被弃用，并且互操作性有限。最近，生成式人工智能模型在为物体和场景生成网格方面取得了相当大的进展[17，18，22，25，26，41，43]。然而，很少有作品敢于超越视觉外观，交互式和行为元素。此外，现有的基于渲染的方法需要大量的计算和时间来生成和渲染3D对象，而这些生成的质量和分辨率是有限的[11，35]。
另一方面，像GPT这样的大型语言模型（LLM）的快速发展已经在代码生成和推理方面显示出了希望[1，6，14，21，33]。LLM与游戏引擎的集成，如Unity [50]，可以实现更快的3D内容开发和自发的用户创建，这是混合现实自成立以来的核心元素。此外，3D混合现实世界拥有丰富的空间多模态信息（大多数是后符号或超越语言），可以帮助LLM更好地在人类生活的现实中进行推理。
本文介绍了LLMR（混合现实的大型语言模型），一个框架，使实时创建和修改的交互式三维场景。LLMR可以创建在视觉和行为方面都很丰富的对象，或者对现有环境进行自发和定制的编辑。例如，我们利用LLMR产生交互式工具，这些工具是独立的单元，旨在执行虚拟和混合现实环境中的特定功能。它们可以结合起来形成更复杂的交互系统，扩展用户和AI驱动体验的范围和深度。这些配置可以在各种环境中保存和传输，作为多功能交互式体验的构建块。
LLMR是一个专门的GPT集合的编排。它的中心是Builder GPT，作为C# Unity代码的架构师，用于制作交互式场景。然而，虚拟世界创建下的大量任务使得独立的编码器不足以胜任。例如，有意义地修改现有虚拟世界的能力需要对场景有深刻的语义理解。作为人类，我们有能力推断世界上物体的属性，并可以使用指示词来指代环境中的物体。为了模拟感知访问的好处，我们结合了场景分析器GPT。它生成场景对象的综合摘要，并在请求时提供详细信息，包括大小，颜色和先前由LLMR生成的交互式工具的功能等方面。我们还实现了技能库GPT，它确定生成器完成用户请求所需的相关技能。此外，我们观察到生成器生成的代码缺乏健壮性，并且经常包含错误。为了解决这个问题，我们引入了Inspector GPT，它根据一组预定义的规则来评估Builder的代码。在Unity游戏引擎中通过编译器执行代码之前，此评估可作为针对编译和运行时错误的保护措施。
为了说明我们的框架在虚拟场景的创建和编辑中的效果，我们在两组150个提示上测试了LLMR，其中包括大量的创建和修改任务。我们的fndings证明LLMR的上级性能相比，通用LLMs，同时强调的性能增益与我们的管道中的每个模块的增加。特别是，与现成的GPT-4相比，LLMR在空场景和现有场景中的代码错误减少了4倍[34]。与此同时，LLMR可以成功地完成具有不同复杂度的任务序列，同时将完成时间保持在一分钟左右。这些结果强调了LLMR以更高的鲁棒性在真实的时间内执行用户指令的能力。
为了评估我们的框架是否不仅可以生成功能代码，还可以生成满足用户指令的交互式世界，我们对11名具有不同Unity体验的参与者进行了LLMR评估。在高层次上，参与者发现LLMR是直观和易于使用的，他们能够迭代地实现所需的输出，而无需太多的手动脚本。虽然该框架具有局限性，例如由于生成模型的随机性而导致的不可预测性，因此并不适用于所有上下文（特别是需要精确和特定控制的上下文），但LLMR生成的输出可以作为更复杂场景生成的起点。
我们的论文组织如下：我们开始通过描述先前的工作和方法来生成3D对象和环境的混合现实在第2节。在第3节中，我们首先概述了LLMR，然后详细介绍了我们框架中每个模块的功能。然后，我们讨论了我们的框架的重要扩展，如合并插件，内存管理和跨平台兼容性，在第4，5，6节，分别。在第7节中展示了一系列示例应用程序，以说明LLMR支持的各种创建。第8节数值研究包括对我们的框架进行全面评估，以实现我们的设计目标：高完成率，实时执行，对复杂任务的鲁棒性和迭代fne调优能力。我们遵循第9节用户研究的数值研究，评估LLMR输出的质量并提供可用性反馈。最后，在第10节中，我们讨论了局限性和未来的工作，以供他人借鉴。
总之，我们的主要贡献如下：
(1) 我们引入了一个通用框架，用于使用LLM模块实时生成交互式3D对象和场景，旨在通过OpenAI API密钥轻松设置，并可适应各种混合现实工具，环境和设备。
(2) 我们进行了广泛的评估，包括技术消融研究，以衡量框架的性能和可靠性，以及用户研究，以获得优化用户体验的设计建议。
(3) 我们展示了GPT超越文本输入的扩展功能，阐明了LLM应用程序的更广泛潜力，并展示了该框架在远程培训，创造力和可访问性等领域的广泛适用性。
(4) 我们倡导人工智能支持的混合现实应用程序的互操作性和寿命，因此我们公开分享应用程序和评估中使用的安装包，代码和提示，以便未来的工作可以建立在我们的框架之上。
2 RELATED WORK
我们对使用自然语言创建和修改交互式3D场景的研究位于大型语言模型（LLM）和3D内容生成的交叉点。本节概述了这些领域的相关工作，强调了我们的工作是如何建立在现有研究的基础上并扩展现有研究的。
2.1 Generative 3D Assets
3D资产的生成一直是最近研究的一个重要焦点。Li等人与3DDesigner [25]，Jun和Nichol与Shap·E [22]以及Poole等人与DreamFusion [35]的工作已经证明了文本指导和生成模型在创建复杂多样的3D对象方面的潜力。Lin等人介绍了Magic 3D [26]，这是一个高分辨率的文本到3D内容创建框架，解决了DreamFusion等现有方法固有的缓慢优化和低分辨率输出的局限性。最近，Karnewar等人的Holodifusion [23]通过将扩散模型用于3D生成建模来进一步推进对话。Instruct-NeRF 2NeRF方法[15]和Pointclip v2 [65]等进步以及Roberts等人的工作[39]已经探索了3D开放世界学习中提示技术的力量。Gao等人[11]对神经辐射场（NeRF）模型的全面回顾增加了我们对这个快速增长的费尔德的理解，并与我们使LLM能够解释非语言或非符号信息的方法保持一致。我们的方法扩展到视觉外观之外，将交互和行为元素纳入生成的内容中。
2.2 Generative Interactive 3D Environments
除了生成对象之外，还进一步探索了交互式3D环境的创建，其中包括Wang等人的Voyager [53]，Singer等人的MAV 3D [41]以及Höllein，Lukas等人的Text 2 Room [17]。Volum等人已经表明，LLM可以用于引导NPC与虚拟环境的交互[52]。Wang等人还介绍了Chat-3D [56]，这是一个专注于3D场景通用对话的系统，Hong等人的工作进一步增强了3D-LLM [18]。像Oasis [43]和Procedurally Generated Virtual Reality [44]这样的新方法增加了新的视角。最近的进展，如Guérin等人的基于交互示例的地形创作与条件生成对抗网络[13]，为如何从简单的用户输入生成地形增加了一层复杂性。Freiknecht和Efelsberg [10]，Cao等人[4]和Song等人[42]的研究集中在现实主义和算法性能之间的平衡。DeepSpace引入了一种从音乐中基于情绪生成纹理的新方法[45]，为资产生成增加了另一层复杂性。虽然这些贡献在构建交互式3D空间方面非常重要，但人工智能和混合现实在这些环境中的相互作用仍然是一个悬而未决的问题。我们的工作通过将LLM的功能引入混合现实应用程序的实时Unity编辑器来解决这一差距。
2.3 Editor Support for Mixed Reality Development
Hirzle等人[16]和Fidalgo等人[9]探索了混合现实（XR）的开发，他们在AI和XR的交叉点上提供了全面的评论。Lindlbauer等人[27]和Cheng等人[5]关注MR接口的自动适配，这是一项与多用户XR体验相关的工作，如Mandi等人与RoCo [30]所示。Thoravi Kumaravel等人。[51]通过专注于双向混合现实远程呈现来补充这些假设。与以前的工作相比，我们允许用户使用自然语言直接授权环境。
2.4 LLMs Interpreting Spatial, Non-Linguistic Information
最后，许多人通过输入非语言信息（不在训练集中）来推动LLM的边界，例如用于视觉编程[64]或处理传感器数据[28]。与我们的工作更相关的是使用LLM与空间的具体数据进行交互。Zhang等人使用MotionGPT [60]，Wu等人的工作。的工作，在任务规划[57]以及理查森等人。与文本[38]。Dafara等人[7]和Rana等人[37]进一步扩展了这些概念，包括演示和任务规划。Driess等人与PaLM-E [8]分别展示了LLM在生成人体运动、纹理化3D形状和结合真实世界传感器模态方面的潜力。Xu等人用XAIR [58]补充了这些假设，XAIR专注于增强现实中的可解释AI。我们希望LLMR有助于提高LLM的空间推理能力和世界理解能力。
图2：用于实时交互式3D场景生成的混合现实大型语言模型（LLMR）架构。从左侧开始，用户提示和现有的3D场景（Ω）分别被馈送到规划器（P）和场景分析器（SA）模块中。Planner将用户提示分解为一系列子提示，而SA则汇总当前场景元素。然后将这些与技能库（SL）集成，以指导生成适当代码的生成器（B）模块。Inspector（I）模块迭代地检查生成的代码中的编译和运行时错误。在接收到Inspector发出的绿色光后，使用Roslyn编译器编译代码，并在Unity Engine中执行，以生成用户指定的所需3D场景和功能。
3 LLMR: A FRAMEWORK FOR GENERATING REAL-TIME, INTERACTIVE 3D WORLDS
USING LARGE LANGUAGE MODELS
大型语言模型是有能力的代码生成器，它们合成程序的能力已经过广泛的测试[1，6，14，21，33]。然而，在游戏引擎中编写脚本，考虑到大量的任务和开发环境的复杂性，是特别具有挑战性的。对于一个不全面的列表，生成一个逼真的3D世界可能涉及对象创建，纹理，行为编程，事件脚本，动画，粒子效果，照明和用户界面[3]。要在真实的时间内实现这些元素，需要一个能够理解虚拟场景、解释用户意图并生成高质量代码的框架。为此，我们提出了混合现实的大语言模型（LLMR），一个框架，使实时创建和修改的交互式3D场景使用自然语言。
LLMR是语言模型的编排，每个模型都有一个不同的元提示符来描述它的角色，如图2和算法1所示。元提示符是一个精心设计的输入序列或上下文，它指导LLM的行为或输出，使响应比标准提示符更集中或更细微。我们从Planner开始，它将用户的请求分解为一系列适当范围的指令。这些指令，沿着来自场景分析器的现有场景的简明摘要和来自技能库的专业技能的额外知识，被用作称为生成器的中央模块的输入，该模块生成代码以执行这些指令。此外，我们使用一个单独的检查器模块来检查生成器生成的代码，以防止在最终执行代码之前出现潜在的编译和运行时错误。
生成交互式3D场景的任务归结为生成和执行适当的代码片段以完成用户的提示。形式上，用Ω表示用户的请求𝐠，用Ω表示当前的3D世界（可以是空的），我们希望绘制示例𝐠CUP（𝐠|𝐬其中P是语法上有效的、满足请求的代码的分布。然后，我们在Unity Engine [50]下运行时编译和执行JavaScript，Unity Engine [50]是一个用于创建适合我们需求的虚拟场景的开发平台。下面，我们详细介绍每一个模块，并解释设计选择，使各个方面的促进虚拟世界的存在。
图3：计划器及其在将用户的高级请求分解为一系列可管理的子任务（任务，任务，...，J.）。计划员参与面向用户的对话，以确定每个子任务的适当范围和粒度。在此之后，生成器通过生成代码（code.js，code.js，...𝐵对于每个子任务，有效地执行用户的初始请求。
3.1 Planner
让一个世界存在可能是一项艰巨的任务。“创建一个城市和它的所有居民”是一个合理的要求，尽管一个过于雄心勃勃的一步实现。遵循“如果分解成小工作，没有什么特别困难”的常识，而不是直接从P（𝐠|，𝐬Ω），我们提出一个规划器𝐠：𝐠→𝐱（，𝐲，...，𝐵将每个提示分解为适当范围内的子任务，然后使用自回归采样通过一系列生成的代码（𝐲𝐱（C）：
其中B（，...，）。第二个性质是假设在不同步骤的代码生成和请求是独立的，，≠图3给出了这个过程的一个例子。𝐮𝐠𝐵然而，从P（+1）采样𝐵|𝐵，𝐵+1，Ω）对于语言模型来说可能是困难的，因为它必须推断在初始世界Ω上写代码之前<$+1效果, 为了消除猜测，我们利用一个运行时编译器来执行（编译器，.𝐵按顺序，每次得到一个新的世界状态Ω 1 =Ω+1，Ω。𝐠𝐫我们可以重写：
其中，我们假设当以Ω为条件时，{}1是马尔可夫的。𝐵也就是说，当前世界状态足够丰富，可以捕获最近一次执行之后的所有先前执行。
原则上，用户可以将其提示限制在一定的难度内，从而不必进行分解。然而，用户可能事先不知道适当的任务范围（如果创建一个城市太难，那么创建一个房子怎么样？或者是房子里的一个房间？）因此，有一个适当的confirmable计划使框架强大的提示不同的困难。此外，用户可能在提示中具有不同级别的细节。例如，“创建一辆汽车”是一个有效的请求，但没有指定其外观或功能。在这里，规划师充当对话助手，与用户交互以设计具有适当范围和粒度的计划，这显著改善了用户体验。
3.2 Scene Analyzer
图4：场景分析器模块。左下角描绘的虚拟场景被转换为JSON格式的解析场景层次结构。这与用户请求一起沿着用作场景分析器的输入。输出是一个经过过滤的、相关的场景摘要，然后用于调节后续模块，如Builder。该过程优化了语言模型的固定上下文窗口的利用，并增强了对与用户提示相关的对象的关注。
存在虚拟世界Ω的许多可能的表示，其可以包括视觉、行为和听觉元素。在这项工作中，我们从Unity场景层次结构中导出Ω，其中包含所有现有的游戏对象，它们的附加组件以及它们的父子关系。层次结构被解析为JSON字符串，然后可以用作语言模型的输入。然而，直接使用原始JSON字符串作为输入在实践中被证明是不可行的。首先，大多数提示只需要与Ω的一小部分交互，因此将其全部用作输入是不必要的，甚至会分散注意力。其次，LLM有一个固定的上下文窗口，作为其短期记忆，它必须包含其元提示，少数例子，用户提示和生成输出[62]。例如，GPT-4支持8 k或32 k令牌，一次最大令牌数量[34]，但即使是32 k令牌限制也可能不够，特别是对于包含许多对象的复杂场景，每个对象由多个组件组成。
为了解决这些问题，我们创建了一个单独的模块，称为场景分析器，这是一个正确提示的LLM A（𝐠|𝐬Ω），它根据用户请求输出Ω的简洁摘要。在高层次上，人们可以将场景分析器视为一种感知手段，它为下游处理中继环境的抽象。图4中提供了该模块的图示。具体地，输出𝐵Δ A（·|𝐬Ω𝐠）用于在每个采样步骤重新参数化密度：
3.3 Builder-Inspector
LLMR的核心是Builder B(x|u,s), 负责以用户提示为条件生成代码的模块。它是我们计算P的主要工具。换句话说，我们希望：
一个精心制作的元提示符和足够的上下文演示。然而，在实践中，创建虚拟世界的复杂性使得即使在上下文长度允许的情况下使用尽可能多的示例，近似也不能令人满意。这在很大程度上是因为Builder模块被要求以一些创造性完成指令，同时忠实地遵循一系列与输出对齐的具体指南，这导致Builder具有“认知过载”。
图5：LLMR中的生成器-检查器范例。模块B生成器（𝐠|𝐬基于𝐩用户输入和当前状态生成代码。生成的代码然后由Inspector模块I（𝐬𝐠|𝐬编译𝐩和运行时错误。如果发现错误，检查员将提供纠正建议。𝐠𝐬该过程迭代，直到代码通过检查或达到最大检查次数。𝐠这种反馈循环显著地提高了生成的脚本的质量。
为了改善这一点，我们引入了另一个模块，检查员I（𝐬𝐠|𝐬，𝐩它检查生成器生成的代码是否存在编译和运行时错误。如果检查失败，检查员会输出一个建议值，提示生成器进行另一次尝试。因此，生成器和检查器协同工作来编写和自调试代码，形成了一个反馈系统，显著提高了生成的脚本的质量。我们在算法2中概述了这个范例，并在图5中进行了说明。有趣的是，Inspector擅长捕捉错误，即使构建器中存在其元提示符中的相同指导原则。一种可能性是，这是由于向检查专员提供了一份更广泛的正反两方面的例子清单。尽管如此，当生成器提供相同的示例时，性能并不高。我们对此的直觉是，验证代码片段比编写所述代码更容易，或者这两个任务具有不同的失败模式，可以有效地进行对冲。
3.4 Compilation, Save and Reload
在生成器生成的脚本通过检查后，我们按照[39]中的方法通过Roslyn C#编译器[49]在运行时编译和执行脚本。包含运行时编译将LLMR从一个离线开发工具提升为一个实时生成框架。
要启用迭代设计，用户可以保存其层代，并在现有场景或新场景中选择性地重新加载保存的层代，而无需重复提示过程。生成的输出保存为C#脚本，并重新附加到编译器，在运行时编译。每个脚本函数的一句话摘要被保存，因此框架也可以根据摘要重新生成输出。
3.5 Skill Library
创建技能库模块的动机是两个主要挑战。第一个是GPT架构对上下文或提供给构建器的“元提示符”施加的令牌大小限制。通常，生成器会显示一个包含各种API和插件的综合列表，这些API和插件可以用来满足用户的需求。随着可用技能范围的扩大，这个列表会变长，最终超过GPT对公共用户的令牌大小限制。第二个挑战在于建造者的注意力能力，这似乎是有限的。即使我们试图将所有可用的技能压缩到Builder的元提示符中，当列表变得太长时，它也很难跟踪特定的技能。这种限制进一步加剧了包括每个插件的精确编码示例的必要性，以确保GPT有效利用它们。为了应对这些挑战，我们创建了技能库模块，表示为L（Skill Library|𝐩，它作为所有可用技能的集中存储库，并作为仅检索与特定用户提示相关的技能的注意机制。我们在图6中演示了这个模块。
图6：技能库模块工作流。在左侧，模块接收来自场景分析器的输入和用户提示“创建一条鲸鱼并让它快乐地游泳”。SL GPT模块的元提示符中提供了一个技能列表，其中还包含可用技能的高级摘要，如对象检索和动画。然后，该模块识别并输出最相关的技能（在本例中，对象检索器和动画）到生成器，生成器随后利用这些工具进行实现。
形式上，专门化的GPT提供了一个包含两个基本信息的元提示符：1）可用技能的高级摘要，以及 2)用户提示符。GPT模型的任务是识别与用户请求最相关的单个技能或技能子集。技能库保持高效和令牌大小小，因为它只需要每个技能的高级描述，而具体的使用细节,以及正面和负面的例子都是分开存储的。一旦识别出相关的技能，它们的详细信息和用法示例就会被提取并传递给生成器进行实现。
作为一个说明性示例，考虑我们为GPT使用而创建的技能，该技能利用生成模型和对比模型的组合沿着以及Sketchfab API来获取3D模型并将其集成到场景中。我们还创建了允许实时生成操纵对象动画的技能[19]。当我们在下一节中深入研究技能的细节时，值得注意的是技能库只接收关于该特定技能如何工作的高级摘要，以及其他技能的类似描述符沿着。然后检索使用此技能所需的实际示例，并将其提供给Builder执行。
4 INCORPORATING EXISTING OPEN-SOURCE 3D ASSETS(增加现有开源3D资产)
生成交互式3D场景的过程通常涉及各种对象的创建和放置。例如，一个创建办公空间的请求可以被分解为桌子、椅子、灯和时钟的生成。虽然可以使用图元生成这些对象，这种方法甚至适用于汽车或整个房间等复合对象（如图8的汽车和图1的厨房所示），但需要利用艺术家和3D开发人员创建的复杂对象，这些对象表现出高真实世界的逼真度。以前的工作利用了Sketchfab [39，40]中的对象，并使用GPT的先验来根据真实的世界调整它们的大小。然而，当用户提示一个对象时，这种方法遇到了挑战，比如一个时钟，而Sketchfab提供了50个不同的时钟，其中只有三个适合办公室设置。
为了解决这个问题，我们引入了Object Retriever，这是一种使用其他AI模型来识别用户最可能想要的3D对象的技能。Object Retriever的工作流程可以形式化如下：给出用户提示，Object Retriever识别中包含的对象，并为该对象调用Dall·E-2 [47] API，生成“目标图像”。𝐬𝐠同时，使用相同的对象提示符下载在Sketchfab上免费提供的3D对象的屏幕截图，表示为= {，，...，𝐠𝐵}。然后，我们使用CLIP [36]来绘制语言域和视觉域中的相似性空间。𝐠我们选择顶部在语言相似性空间<$1中，选择最接近对象提示符<$1的5个图像<$1 ′ <$2，从这些图像中，选择在视觉相似性空间<$2中最接近目标图像<$1的图像<$2。𝐠在形式上，让（）和（）分别表示对象提示符和屏幕截图之间以及目标图像和屏幕截图之间的语言和视觉相似性。𝐬𝐠对象检索器的操作如下：
重复此过程以生成整个场景。算法3和图7描述了这个流水线。有可能进一步勘探，以改善这一管道。例如，在语言相似性空间之前从视觉相似性空间进行选择可能会产生更好的结果。未来的工作将涉及人类的反馈，以确定工作流，最大限度地提高3D对象加载和用户的预期对象之间的相似性。
图7：用于生成3D场景的Object Retriever管道。用户为包含时钟、相框、椅子和桌子上的苹果的场景提供提示。对于每个对象（例如，时钟），流水线使用DALL-E 2创建目标3D图像。同时，使用对象标签作为查询，从开源Sketchfab模型下载多个潜在匹配的屏幕截图。CLIP被用来生成嵌入这些图像，其中包括目标图像。选择语言相似性空间中的前5个候选。然后，基于与目标图像的最高视觉相似性来选择最终对象。对提示中的每个对象重复此序列，以组合完整的3D场景，如最右侧所示。
5 MEMORY MANAGEMENT
默认情况下，语言模型基于所有先前采样的标记生成新单词，由于其有限的上下文长度，这种配置可能并不理想。例如，这可能会阻碍模型参与扩展对话的能力。为了缓解这种情况，可以采用对话摘要和蒸馏等技术[2，20，54]。其他研究已经深入研究了利用持久内存和从数据库中检索上下文示例以增强少数镜头性能[55，63]。
我们试图部署一个协议，在框架持续使用的同时，在LLM的上下文窗口中更改内容。我们为LLMR中的每个模块探索了三种内存模式：全内存、有限内存和无内存。我们在表1中记录了每个模块使用的内存模式。这些模式涉及在模型的上下文中保留所有、少数或不保留历史指令和生成的代码。定义一段交互作为模块的输入和输出，单个用户提示LLMR。例如，为了实现一个内存有限的模块，我们在每次提示后清除其上下文中的所有内容，但最近的事件除外，其中通常情况下，事件= 1。
一个有效的内存管理协议有三个明显的优点:
代币限额：修剪旧内存减少了令牌消耗，并使LLMR的使用时间延长，这是逐步构建复杂场景的关键功能。值得注意的是，场景分析器受益于没有先前交互的记忆，因为它容易受到令牌约束的影响。例如，第一个AI 2-THOR场景层次结构测量约7 k GPT-4令牌[24]。因此，具有8 k令牌的全内存场景分析器在其上下文耗尽之前只能执行单个指令，从而使框架在无内存设置之外基本上不可用。
性能：某些模块在内存减少的情况下性能更好，因为它们可能容易被早期的交互所混淆。我们的经验观察表明，检查员模块在重复检查中表现出更大的宽容，允许所提出的代码在纠正所有错误之前通过。
可解释性：记忆有限的框架提供了更清晰的错误归因。例如，当一系列提示被发送，并且生成在最后一步失败时，保持所有的内存使得辨别最后一个提示是否构成了独特的挑战或者框架是否被早期任务的方面所困扰变得具有挑战性。改进的透明性有助于快速调试和迭代我们的框架。
我们相信内存模式的选择是任何LLM编排管道的一个重要方面，我们的设计选择可能会为LLM系统的开发提供超越创建虚拟世界任务的见解。
图8：LLMR实现的跨平台和跨场景可传输性。左面板显示了LLMR使用Unity基元自动创建的汽车，并具有颜色和复合特征（例如，车轮和前灯），可通过键盘输入进行控制。中间的面板显示了同一辆汽车转移到不同的Unity场景，具有月球般的重力和地形。右侧面板通过说明汽车如何与物理世界中的物体碰撞以及如何使用用户移动的手机的IMU数据进行控制来展示框架的跨平台适应性。
图9：使用LLMR绘制对象。在左侧面板中，用户请求将“魔法画笔”连接到VR控制器。中间的面板说明了线渲染器到画笔的自动转换，其中显示用户绘制椅子。右侧面板演示了使用2D-3D ControlNet [59]和我们的Dall·E-CLIP Sketchfab API的2D到3D转换。这使得能够生成多个椅子模型，然后可以使用LLMR在不同的平台上传输这些模型以进行进一步的交互。
图10：操作中的可扩展接口功能。A1和A2显示了用户如何提示系统调整厨房场景的配色方案以实现红绿色盲兼容性。B1和B2展示了放大镜工具的激活。C1和C2显示隐藏被认为不适合儿童的对象的选项。
6 CROSS-PLATFORM COMPATIBILITY AND INSTALLATION
我们表明，我们的框架可以部署在各种类型的平台（例如，Web、移动的、AR和VR）和各种设备（例如，Meta Quest，HoloLens 2）.为了保持框架的轻量化，我们将框架的运行时编译器部署在充当服务器的PC上，并且我们建立在现有的远程处理协议和框架[32，46]上，以将生成的结果流式传输到客户端设备（例如，HoloLens的全息遥控2）。平台依赖性，如命名空间和其他包可以作为“技能”添加到框架的技能库，这允许用户快速启用交互模式，如捏和输入模式，如语音和控制器。
在一个场景中构建的交互式元素可以通过存储创建它们的源代码来保存为自包含的单元。然后，我们可以重新执行缓存的代码，以加载和调整提示对象到新的场景中，这可以像调整物理特性的不同场景或具有全新API的项目一样简单，如图8所示。我们对LLMR的实验表明，在独立的SDK平台之间转换交互式元素是可能的，并建议将现有的软件（可能是用过时的，不再工作的代码编写的软件）应用于更新的SDK。我们把它留给未来的探索。
6.1 Installation
我们的框架可以很容易地添加到任何现有的Unity场景中。该框架由一个Unity包和一些额外的开源包（如GLTF loader和OpenAI）组成，安装过程只需要几个步骤。这使得任何拥有OpenAI API密钥的人都可以尝试我们的框架。我们是我们框架适应性的强烈支持者，因此我们在GitHub（https：//llm4mr.github.io/）上开源了基础框架沿着几个示例。希望尝试我们框架的读者可以尝试示例操场场景，或者可以轻松地将我们的Unity包添加到他们现有的Unity项目中。他们需要获得OpenAI API密钥、Roslyn编译器的副本，如果他们希望自动加载现有资源，还需要获得Sketchfab的帐户。在附录中，我们还提供了用于每个LLMR模块的元提示符，以提高透明度。
7 EXAMPLE PROMPTED INTERACTIVE WORLDS AND USES
在本节中，我们将说明可以使用LLMR构建的各种对象、工具和场景。我们强调，我们的框架是模块化的，实时的，自适应的，交互式的，多模式的，这与其他生成的3D世界，主要集中在视觉外观的方法不同。对于下面的所有示例，重要的是要强调，所有结果都是通过提示系统来实现的，而不需要手动干预。
图11：自发创建教学指南。创建操作cofee机器的指南的演示，其中LLMR为手模型制作动画，以指出操作的各个步骤。我们的框架允许快速创建这样的指南，并允许用户提出问题，事先没有预测的教练，与适当的运动被动画上的fy。
7.1 Game Design and Creativity
我们的框架的一个直接应用是创建游戏，特别是场景。场景设置游戏的背景，它通常涉及大量的资产，手动设置起来既困难又繁琐。游戏设计师可以使用Planner创建草稿环境，并添加具有响应行为的交互组件，如“玩家”和“对手”，以模拟游戏逻辑。此外，游戏设计师可以在多个环境中扩展游戏玩法。例如，可以在VR中的月球模拟环境中创建并重新加载玩具车（图8 B），或者在物理世界中生成并使用移动的手机驾驶（图8 C）。除了“提示”对象的存在，我们表明，我们的框架还允许用户“画”的东西存在。这里，用户希望设计椅子（图9）。他们可以通过简单地提示“一个神奇的画笔”来做到这一点，它具有类似于TiltBrush [12]的功能，这是一个流行的3D绘图应用程序，然后通过图7中所示的类似过程将绘图转换为集成Dall-E 2，CLIP和Sketchfab的3D模型。
7.2 Accessibility and Adaptive Interface
与2D文档中的可访问性功能类似，我们的框架也可以提示使3D场景可访问并适应不同的用户需求和偏好。图10显示了根据不同请求编辑现有虚拟厨房场景的三个示例。例如，可以请求使场景对红绿色盲用户更友好。对于近视的人来说，他们可以提示放大镜工具放大房间的特定部分。建筑师可以使用我们的框架来确定空间是否对轮椅使用者友好，或者确保房间里的物体是儿童安全的。这些例子展示了我们的框架如何利用LLM的先验知识，并将知识置于人类尺度的空间世界的背景下。
图12：模拟救援计划。HoloLens 2显示了使用我们的框架自动生成救援计划的模拟。该指南显示了可交互的3D地形，直升机和模拟风，使救援人员能够在不同的天气条件下可视化战斗路径。
7.3 Remote Assistance and Planning
在远程训练场景中，通常，创建这样的3D交互式训练指南需要自定义创建，从装配手势到放置UI元素。教师可以使用我们的框架来自动生成一个培训指南从指令列表。（见图11）。然后，受训者可以例如使用将信息覆盖在机器上的AR设备。随着受训者通过这些步骤的进展，他们可以直接向向导提出问题，向导可以在受训者的学习进度的上下文中生成答案。在另一个远程救援计划场景中，直升机操作员可以在给定几个目标位置的情况下模拟飞行路径，并查看飞行路径如何受到不同风况的影响（图12）。
8 NUMERICAL STUDY
作为一个编排的管道，LLMR用多个模块增强了LLM编码器，以提高其可靠性。为了从经验上证明在我们的框架中包含每个模块的合理性，我们对各种提示和基线定量评估了LLMR的生成性能。除了成功地编译生成的代码，我们评估我们的框架如何满足我们的设计目标：实时性，交互的复杂性和迭代微调优能力。
本节的组织如下：我们开始在空的和现有的场景中对单个提示进行评估，突出显示每个模块的影响和与标准LLM相比的整体性能。我们还讨论了该框架在完成不同复杂度的任务时的性能。然后，我们进行了类似的实验顺序提示，以说明LLMR的迭代设计的能力。最后，我们提出了我们的框架的实时方面的分析。
8.1 Error Rate
实验设置。我们首先研究LLMR在空场景或现有场景中执行单个独立请求的能力。为此，我们创建了两个数据集，每个数据集包含150个提示。第一个集合用作空场景中的输入，并且本质上主要是创造性的，因为在世界上没有什么可修改或交互的。一个例子是“用基本体创建猫和老鼠。猫应该追逐老鼠，老鼠的觅食方式飘忽不定。第二组用作图13中所示的现有场景中的输入。场景是从Sketchfab [48]下载的，选择它是因为它足够复杂（大约35个物体）。图13中显示了一些示例提示，这些提示涉及空间的视觉和语义更改。为了促进测试提示的公平性和多样性，我们使用单独的、适当提示的GPT来生成两个评价数据集。作者创建了15个提示符作为提示GPT的演示。完整的评价数据集可参见附录。
为了评估LLMR的有效性，需要一个适当的度量。考虑到诸如“使房间更令人振奋”的任务的主观性质，很难系统地确定是否成功地满足了提示。但是，在生成的代码中出现运行时或编译错误可以被认为是失败的明确指示器。因此，我们选择了“错误率”-错误的输出比例-作为评估框架性能的标准。
为了评估LLMR每个模块的效率，我们创建了三个模型条件，每个条件都添加了一个额外的GPT模块，除了GPT-4零炮和GPT-4少炮作为我们的基线。这使得总共有5个模型条件。我们对每个模型条件和每个场景条件（空场景和现有场景）进行了5次运行，每次运行150个提示。
图13：我们的实验装置的图示。我们提供了浴室场景（左）和在此空间中使用的150个提示的子集（右），用于图14中提供的评估。
8.1.2 结果与讨论 我们在图14中提供了模型和各种基线的错误率总结。为了强调每个LLMR模块的好处，我们递增地添加每个组件以梳理其边际影响。从现成的GPT-4开始，我们看到标准的上下文学习技术在两种设置中都提高了性能，但只有大约一半的请求失败。从这里开始，我们使用本工作中开发的组件来增强标准GPT-4，从场景分析器开始，然后是技能库，最后是检查器。因此，所生成的错误分别大幅下降到原始GPT-4中针对空场景和现有场景所观察到的错误率的仅20.5%和25.2%，这证明了我们的流水线在生成交互式场景的任务中超过标准的现成LLM的有效性。
我们现在详细讨论每个LLMR模块的影响。如第3.2节所述，场景分析器允许LLMR解析和理解虚拟场景，因此对于现有环境的有意义操作是不可或缺的。因此，使用场景分析器增强GPT-4会显著增强浴室场景的性能。其次，检查器模块使LLMR能够执行自调试，并有效地防止错误代码的生成，进一步降低两种情况下的错误率。虽然我们在最后阶段集成了Inspector，但它与任何模块组合都兼容，并将持续降低输出错误率。例如，我们将Inspector添加到GPT-4中，在空场景中进行少量提示，并观察到平均错误率从45.0%下降到13.1%。我们还观察到技能库对错误率的影响很小。这是预期的，因为技能库被设计为处理更专业的任务，我们将在下面的小节中详细讨论。最后，没有包括Planner，因为它通过逐步分解来改变输入提示，使结果不可解释。我们在附录中包括一个例子，其中使用规划器来构建一个虚拟厨房，强调将困难的任务分解为增量步骤的好处。
8.2 按难度等级划分的错误率
8.2.1研究方法。为了探索提示的复杂性与LLMR完成率之间的关系，我们对上一节的结果进行了专门分析。我们将单个提示任务的提示分为1到10个难度等级。为了实现这一点，我们使用了一个没有任何元提示的非情境化LLM，要求它为每个提示分配一个难度级别。对于每个提示，重复该过程10次，然后计算平均困难水平（具有较小标准偏差的水平）。图15显示了按困难程度分类的汇总结果。给这个LLM（GPT-4）的提示是“以上是给一个可以在Unity内部编码和执行命令的系统的提示。我们希望衡量这个系统在为Unity目的用C#编码方面有多好。鉴于您对Unity的了解，请根据1到10”的困难程度对上述所有提示进行评分。采用非情境化LLM（无任何元提示）的基本原理在于评估困难水平的主观性质。作为系统的开发者，我们的判断可能天生就有偏见，受到我们对系统能力和局限性的理解的影响。此外，让Unity专家来确定困难程度也是一项挑战。Unity开发人员之间的专业知识和经验水平的差异可能导致不一致的评估，并且在没有全面和统一的检查框架的情况下难以标准化评估人员的经验。
8.2.2结果与讨论 在本节中，我们分析了各种架构在执行Unity任务时的性能，这些性能根据从简单到困难的难度级别而有所不同。根据GPT-4指定的1-10量表确定这些水平。图15显示了两个面板上不同架构的错误率。左边是空场景的结果，右边是包含各种对象的浴室场景的结果。
在所有级别和场景中，LLMR（橙子线）始终优于其他架构，强调了其鲁棒性。
图14 平均编译错误率和运行时错误率的比较。SA代表Scene Analyzer，SL代表Skill Library，I代表Inspector。总体而言，在从头开始创建以及编辑现有场景方面，LLMR在少数镜头提示的情况下优于GPT-4 3倍，并且与零镜头GPT-4的性能相比提高了4倍以上。
在左边的空场景中，一个值得注意的趋势是错误率通常随着任务难度的增加而增加。这一趋势符合预期，但GPT-4 Zero Shot的情况除外。这里值得注意的一点是，Easy类别只包含一个提示符，这是一个基本的“Hello World”控制台显示。这项任务的简单性解释了它在这一类别中的独特地位。对于浴室场景，中等和有点困难的任务的错误率显示出最小的变化，这表明困难感知的平台。一个有趣的观察结果是，从简单到有点简单的任务的错误率下降，尽管这在所有模型中并不一致。技能库的整合显示了混合效果（深蓝色线）。在某些情况下，它提高了性能，而在其他情况下，它似乎阻碍了它。
估计任务的难度，特别是在涉及修改现有场景而不是从头开始构建的场景中，提出了挑战。这在浴室场景中得到了体现，其中添加新对象（难度等级3-4）不需要场景理解，与简单类别中的任务相反，它涉及移动对象，因此更多地依赖于场景理解。我们对提示语的分析表明，场景的性质显著地影响了知觉困难。例如，在浴室场景中，某些理论上被归类为简单的任务在实践中变得更具挑战性。附录提供了更全面的分析，包括架构的变化，例如场景分析器（SA）和检查器模块的组合。
总之，LLMR在各种场景中表现出上级性能，强调了其在Unity环境中处理不同复杂性任务的有效性。该分析还强调了任务难度、场景上下文和架构组件之间的复杂关系，为进一步探索优化特定任务架构铺平了道路。
8.3 Task Complexity
复杂性可以通过不同的方面表现出来。为了补充上面的特别分析，我们现在提供一个更全面的讨论，通过以下方面分解复杂性的概念，并分享在我们的实验中出现的发现：
特定技能要求-某些任务本质上更困难。例如，使对象的网格变形比将对象添加到场景中要复杂得多。人类开发人员可能需要查找示例和文档来完成复杂的任务; LLMR可以通过启动模板化脚本来降低任务的复杂性。然而，LLMR并不是防错的。如前一节所示，LLMR的错误率会随着任务变得更加困难而增加（但不超过40%）。通过由经验丰富的开发人员向技能库添加相关技能，可以进一步降低错误率，以帮助LLMR实现更高的成功率，并减少Builder和Inspector之间可能的迭代次数。LLMR可以通过概括技能库中提供的示例来节省经验丰富的开发人员的时间。
令牌需求-所需的令牌数量随着场景或对象变得更加复杂而增长。例如，如果现有场景有一个带有许多叶子的树对象，其中每个叶子都被视为子游戏对象，则场景摘要可能很容易超过允许的最大令牌（在撰写本文时，令牌的最大数量为8 k，尽管现在已经显着增加）。考虑到这一点，我们的场景分析器模块只获取顶级游戏对象名称，以根据用户查询和任务筛选出相关的游戏对象。这允许我们的框架处理像厨房场景（图10中的示例）和浴室场景（在数值研究中使用，图13）这样复杂的场景。除了对象和场景的复杂性之外，任务本身也可能需要大量令牌。一个这样的例子是生成动画[19]（在为技能库编写的技能的帮助下），该动画涉及生成大量关节位置的时间序列和旋转。“优化可能涉及开发一种简单的方法来表示时间序列信息。
图15：按难度级别组织的LLMR模块的性能改进。GPT-4与增量LLMR模块集成的错误率比较。大多数方法的错误率都会随着困难而增加，而LLMR方法（橙子）与其他方法相比仍然保持着持续较低的错误率。
内存要求-当任务需要先前提示的先验知识时（例如，由先前的提示创建的行为），这要求先前的提示已经被成功编译并且足够健壮。我们在第5节中描述了管理不同模块的内存的方法，以节省总内存消耗，同时保留框架执行复杂任务的必要信息。
质量要求-用户可以要求不同级别的输出。例如，用户可以仅在规划器模块（例如，一个完整的厨房，图1），而不是出更高的fdelity三维模型（见例子参与者的创作在视频fgure）。创建视觉上简单但功能和交互式场景的灵活性类似于创建一个lo-f模型，允许用户快速原型和建模，而无需等待视觉上复杂但花费大量计算和时间且不易修改的3D场景的完整生成。
8.4 Iterative, Incremental Design
8.4.1实验设置。在实践中，创建内容丰富的虚拟世界需要渐进的步骤。因此，重要的是要评估LLMR在迭代场景中的表现，在这些场景中，一个接一个地提出和实现请求，以逐步构建和更改虚拟场景。我们用80个连续提示测试了LLMR，每个平均5个单一提示。这些顺序提示包括一套旨在完成复杂任务的指令。例如，建造卧室的顺序提示可能包括以下步骤：“创建一个有墙的空房间;添加一张床，旁边有一盏灯;在墙上添加一扇窗户。"
我们使用三个指标来评估迭代环境中的性能。首先，考虑所有单个提示的错误率，与单个任务相同。第二，我们计算平均完成度，即每个顺序提示在序列长度上完成的单个提示的数量。由于顺序提示有不同的长度，访问完成平均值可以防止“长而简单”的序列增加错误率。最后，我们将fulflled提示定义为从开始到结束的连续提示，并计算其占提示总数的百分比。这是一个要求很高的度量标准，用于验证模型是否可以优雅地管理扩展使用会话。在极端的情况下，一个只擅长短序列的模型可以有一个合理的错误率，但零完美的提示。
8.4.2结果与讨论表2所示的数值结果表明，GPT-4在顺序任务中的性能随着每个LLMR模块的添加而显著提高。当所有模块都集成在一起时，LLMR在所有指标上都超过标准GPT-4约2.5倍，与单次提示测试的结果一致。此外，LLMR的高效内存设计为任意提示序列保持了恒定的上下文使用，从而消除了长时间会话期间的令牌大小限制。因此，LLMR在以下方面表现出有前途的性能：
虚拟场景的渐进式创建和修改，这是一种与实际用例更紧密共鸣的场景。最后，我们将在第9节讨论用户如何主观地评价使用我们框架的迭代过程。
一般来说，顺序提示比单个提示更具挑战性，因为它们需要模型维护和管理长期依赖关系，这是序列建模中具有挑战性的任务[61]。要使用提供的示例，在墙上添加窗需要了解在几个提示之前创建的墙。从这个角度来看，场景分析器作为一个有效的总结[54]，帮助模型将注意力重新定向到与请求最相关的场景部分，从而减少潜在的错误。此外，检查器从场景分析器接收场景解析，因此可以有效地屏蔽生成的代码，防止顺序设置中的潜在错误。
8.5 Real-time
8.5.1方法学。最后，我们的框架的一个重要优势和设计目标是实时创建和修改对象和场景，这是确保使用的实用性的关键。为了评估该框架的实时性，我们测量了不同模块组合下任务完成（从生成到编译）所需的时间。同样，结果来自每个模型条件下150个提示的5次运行。请注意，我们从2023年8月到2023年12月运行了该实验，其中OpenAI的GPT-4模型的性能和延迟略有变化，但差异很小。实验在一台内存为32 GB、GPU为Nvidia RTX 3080的PC上进行。
8.5.2 结果与讨论 表3显示了平均完成时间（即，包括生成和编译时间）。现成的GPT-4需要大约半分钟才能完成一个提示，而完整的LLMR框架平均需要一分钟多一点-考虑到任务的复杂性（图15）和改进的任务完成率（图14和表2），我们认为这个时间框架是可以接受的。为了把事情放在上下文中，如果我们考虑到查找文档和调试所花费的时间，即使对于相当熟悉Unity的人来说，手动完成这些复杂的任务也需要更长的时间。
有几个因素导致了额外的操作时间。首先，某些任务的复杂性，例如从Sketchfab检索3D资源，需要额外的时间从第三方网站下载资源。完成检索3D模型所需的时间变化很大，取决于模型的大小，因此我们没有将其包括在我们的评估中。在这种情况下，我们的框架通过缓存之前保存的模型以更快地重新加载来预测这一点。其次，为了确保我们框架的成功率，Inspector几乎将代码生成时间加倍（参见表3的最后两行）。这是一个固有的权衡，检查器模块可以被用来执行简单的任务。最后，LLMR和用户之间的来回交互以及对生成结果的迭代也会增加总的开发时间。值得注意的是，在我们的用户研究（第9节）中，没有参与者提到或抱怨生成时间。Unity新手用户的参与者赞赏LLMR为他们节省了陡峭的学习曲线的时间。此外，我们的“保存和重新加载”功能（第3.4节）允许用户通过重用以前的创建来更快地重新编译，重新编译只需不到10秒。
图16：Unity经验丰富和初学者用户的用户研究结果。总体而言，用户对LLMR感到满意，并会推荐其他人也使用它。
9 USABILITY STUDY
消融测试只关注由我们的框架生成的代码中的编译和运行时错误。我们还希望通过人类用户来评估生成的输出的质量。此外，我们还想了解对Unity熟悉程度不同的用户将如何使用我们的框架。
9.1 Procedure
我们招募了12名用户（1名试点，11名参与者），他们使用Unity的经验不同（5名参与者有超过一年的Unity经验）。参与者的背景是软件工程师，产品经理或研究人员。每次会议大约需要2个小时，每个参与者至少有1.5小时的时间来实验这个框架。我们提供了一个统一的包，其中包括基本功能（场景分析器和技能库，生成器和检查器）。在研究之前，每个参与者将软件包下载到一个空的或现有的Unity场景中，并按照说明进行设置。每个参与者都与框架进行了几轮互动。一轮交互可能如下所示。参与者输入：“创建一个改变汽车颜色的工具。框架处理提示符并生成脚本，然后在运行时自动编译这些脚本。参与者查看生成的输出并决定下一个提示。研究者可能会提出不同的建议，试图或提醒参与者框架的能力。他们被要求在整个研究过程中大声思考。最后，研究者对参与者进行了半结构化访谈（完整问题列表见附录）。研究结束后，每个参与者都填写了一份关于他们使用该框架的经验的7个问题的问卷，
9.2 Results and Design Recommendation
参与者能够使用我们的框架生成各种输出，例如城市和类似于Asteroids的游戏。有些人甚至重新创造了他们的专业工作，如操纵相机角度和生成动画。
我们使用混合方法来分析用户研究;我们考虑了问卷调查的定量见解，并将参与者的有声思维和半结构化访谈回答按主题分组以识别模式。然后利用这些发现来生成一组设计建议，我们将详细讨论。
问卷调查结果显示，参与者在实现目标、直观性和迭代使用方面对我们的框架总体上有积极的体验。但是，在减少挫折和进一步提高用户满意度方面仍有改进空间（图16）。我们还比较了初学者和有经验的Unity用户的反应。在大多数类别中，初学者对使用我们的框架的体验评价更高，我们将在下面的章节中详细介绍。
9.2.1 学习方法和教学策略。我们要求参与者描述他们在使用我们的框架时的提示方法。与会者强调了确保他们的提示易于GPT理解的重要性（P1，P2）。一些参与者将与框架的互动视为实验场，通过试错法（P0，P6）试验不同的提示并随着时间的推移重新调整它们。许多与会者强调，他们的指示必须非常具体。这涉及指定对象名称、确切更改和详细参数，以实现预期结果并避免不可预测性（P3、P4、P5、P9、P11）。许多人采取了将任务分解为更小，更易于管理的步骤的方法。这包括从简单的组件开始，逐渐增加复杂性（P4，P5，P6，P7，P8，P10）。在创建环境或设置时，参与者通常将静态元素优先于以运动为中心的元素，并确保交互元素对环境做出响应（P7）。
9.2.2 与3D世界创建的先前方法的比较。当被要求将我们的框架与他们之前创建3D世界的经验进行比较时，一些参与者赞赏直接向模型描述他们的想法的容易性，从而消除了大量手动脚本或文档参考的需要（P1，P3，P5，P6）。与会者赞赏我们的框架的集成能力及其自动化3D世界创建的某些方面的能力，例如从Sketchfab等3D模型库中选择和加载对象以及确定模型放置（P4，P7）。一些参与者提到，我们的框架减少了新手的学习曲线，使其更容易开始创建3D世界（P3）。参与者赞赏直接干预和手动调整由我们的框架生成的3D世界的能力，他们认为这是一个强大的功能，与生成模型的其他用途相比，不允许用户调整最终输出（P9，P11）。
9.2.3 注意事项和挑战。参与者指出，与传统方法相比，我们框架的输出通常是不可预测的，并且模型是否能够理解所需的结构（P0）存在不确定性。一些与会者指出，在传统方法和我们创建3D世界的生成方法之间进行选择可能取决于项目的艺术性质和对创意输入的需求（P5、P7、P11）。其他与会者认识到，对于需要精确、结构化或严格控制的项目，传统工具可能比我们的框架更受欢迎（P4，P8）。最后，他们还提到，对于更复杂的任务或随着项目规模的增长，手动代码编辑可能仍然是必要的，因为它可能比为模型（P1，P4，P8）创建详细的编辑描述更快。
9.2.4 用户的期望和惊喜。我们还探讨了参与者的期望以及他们在用户研究中感到惊讶的事情。许多人对我们框架有效生成代码的能力感到惊讶，帮助他们自动化复杂的脚本任务（P1，P4，P6，P8，P10）。特别是，P4对模型处理复杂结构（如树）的能力印象深刻，尽管令牌限制。P10还强调了框架理解游戏对象层次结构并将此信息用作输入的能力，特别是在大型和复杂的项目中。与会者对我们的框架与Dall-E 2和Sketchfab的集成能力，允许创建复杂的结构和添加3D对象（P4，P6，P8，P10）。令人惊讶的是，参与者发现我们的框架允许主观的查询和描述，适应简单的语言和委婉语，而不是严格的技术术语（P5）。P1也很惊讶，这个框架在理解他们的Unity脚本方面表现出了灵活性，甚至可以帮助解决错误。同样，一些人惊喜地发现，当正确提示时，我们的框架可以产生非常规或意想不到的结果，例如独特的玩家移动（P0，P3）。
10 ETHICAL CONSIDERATIONS
虽然LLMR和其他LLM工具可以对许多行业和应用程序进行变革，但任何支持AI的系统都存在风险。首先，开发者和创作者被取代的担忧一直停留在讨论的表面。然而，这些工具尚未被证明可以实现端到端的开发。我们的用户研究的参与者评论说，我们的框架更好地整合了人工干预和参与，因此我们的框架有助于提高生产力和促进头脑风暴，而不是完全自动化的创建过程。一个更严重的问题是，个人可能会使用我们的框架生成有害和不适当的内容。尽管Sketchfab和OpenAI通过内容审核和模型对齐提供了保护措施，但仍然有可能创造性地规避这些保护措施[29]。虽然Roslyn编译器可以自动检查不安全的代码，但需要研究如何调节3D内容。
11 LIMITATIONS AND FUTURE WORK
场景理解的限制-目前，我们的框架需要访问一个“场景图”的描述和游戏对象的层次结构。场景图提供了游戏对象的空间关系，并且它假设游戏对象（及其子游戏对象组件）的名称是正确和唯一的。然而，来自Sketchfab等存储库的3D模型通常具有随机的、非描述性的组件名称。目前，框架通过找到具有确切名称的游戏对象来操作对象，这并不总是可靠的。
此外，场景层次结构不包含关于对象的Meta信息，例如对象和函数。此外，当场景是具有增强的虚拟对象的物理环境时，场景图将不容易获得。自然的下一步是合并大型视觉模型（LVM）[18]，以实现需要视觉知识和对象和环境的语义理解的任务。我们的框架可以从这些模型的增强反馈和语义信息中受益，并且我们的框架可以实现对给定3D环境的更多交互式编辑和交互。
与Builder-Inspector循环减少代码编译错误的方式类似，框架对世界的理解可以通过合并来自虚拟世界和用户的反馈来进一步提高。例如，如果从Sketchfab加载一个3D模型，框架不知道模型（及其子组件）的方向和枢轴中心，因此在要求旋转3D模型时不能始终产生所需的输出。
内存和可跟踪性的限制-框架的另一个限制是令牌大小。如第5节所述，我们优化了对历史会话和生成的访问，以减少令牌使用。存在一种固有的交换，其中用户指令可能引用上一个提示交换中的某些内容，而这些内容不会暴露给下一个交换。例如，场景分析器可以访问脚本的名称、脚本的摘要和脚本的公共字段，但如果用户只是想更改先前两个提示生成的先前脚本的特定部分，则框架将不知道该怎么做。
相应地，显示生成的代码为我们框架的结果提供了可追溯性和透明度。目前，我们的框架编写的代码存储在本地缓存文件夹中，并且可以在Unity编辑器窗口中查看。除了通过后续提示提供反馈外，直接编辑我们框架生成的代码的选项将为用户提供更多代理，并实现更复杂，更精确的任务（如第9.2.3节所述）。
自动技能生成-目前，技能库中的技能是由人类用户创建的。例如，我们结合了从Sketchfab加载资源的技巧，以及使用MRTK [31]名称空间使对象“可抓取”的技巧。基于几个示例自动生成新技能的能力[53]将允许我们的框架实现更复杂的任务（例如生成动画），并与不同的平台（例如Quest和ARKit）兼容。
可互操作性-我们基于Unity引擎的健壮性和我们的LLM在培训期间可能看到的大量现有C#代码示例进行构建。我们的工作独立于Unity及其封闭测试版AI工具1，尽管我们的工具可以是Unity的附加组件。我们想强调的是，我们的框架可以适应任何支持运行时编译的环境。Unity是使用我们框架的基本要求，基于Web的方法将进一步使基于Web的交互式3D世界易于共享和协作。事实上，我们的一些用户研究参与者从事基于Web的混合现实开发，他们评论说我们的框架可以很容易地适应他们的编码环境。
12 CONCLUSION
在本文中，我们介绍了一种新的框架，解决了某些困难，在应用LLM生成交互式3D体验。该框架利用了多个不同和专业的LLM模块的能力，以增强其编码和推理的个人和集体性能的方式编排。此外，我们还提供了某些工程辅助工具，例如利用其他AI模型将内容添加到场景中的技能，进一步扩展了我们框架的功能。
我们的研究已经证明了每个基于LLM的模块的好处，为我们的框架中包含每个模块提供了明确的理由。通过结合一些专门的组件，我们的整个系统变得更加强大，并且明显优于现成的LLM。通过用户研究，我们测试了我们的框架的质量和可用性，允许参与者以前所未有的提示挑战我们的框架，从而推动向LLM提供的示例的界限。
这项工作的意义在于它有可能提高虚拟世界内容的生成与内部的自由度和交互性，并提高这种内容的可能性将有意义的人类直观地在人类规模的世界。反过来，这表明了一条使LLM在人类规模活动领域更加可靠的道路。LLM不仅仅是结合了关于世界的说法，而是在世界的模拟中测试结果。所描述的框架在各种设备和平台上运行;本实现确实假设Unity。
我们建议，这个框架ofers的HCI社区学习法学硕士的机会。通过提供虚拟或真实世界的数据以及在这样的世界中通过代码进行操作的能力，我们的框架可以作为一个平台来测试和改进LLM推理能力在3D环境中的限制。
总之，我们的工作在LLM与虚拟世界内容和体验生成的集成方面迈出了重要的一步，为开发人员和研究人员提供了一个强大的工具。我们期待着看到更广泛的社会将如何利用和扩大这一框架。