2026/8/24 18:54:04
FEATURED · 精选文章 
1. 项目概述当大语言模型遇上形式化需求澄清最近在搞一个叫ClarifySTL的项目本质上是一个交互式的LLM Agent框架专门用来处理STL转换过程中的需求澄清问题。听起来有点绕简单来说就是让大语言模型LLM扮演一个“需求分析师”和“形式化工程师”的混合角色帮助你把一段模糊的、用自然语言描述的系统行为需求一步步澄清、细化最终转换成精确的、机器可验证的Signal Temporal Logic信号时序逻辑STL公式。为什么这个事值得专门做个框架我干了这么多年形式化验证和需求工程太清楚这里面的痛点了。STL是个好东西它能用数学语言精确描述系统在连续时间信号上的行为比如“机器人的速度在进入危险区域后3秒内必须降到0.5米/秒以下”。但问题在于能熟练、准确写出STL公式的工程师凤毛麟角。更常见的情况是领域专家比如机器人专家、控制工程师有一堆想法但只能用自然语言说个大概“我希望系统反应快点别撞上东西要稳定。” 这种需求直接丢给验证工具或者用于控制器合成门都没有。中间这个巨大的鸿沟——从“人话”到“数学话”——就是ClarifySTL要填的坑。传统的做法是靠人肉迭代形式化工程师拿着自然语言需求文档反复和领域专家开会、发邮件、写注释一点点抠字眼试图把“反应快点”量化成“响应时间小于200毫秒”把“别撞上”定义成“与障碍物距离始终大于0.1米”。这个过程极其耗时沟通成本高还容易产生误解。ClarifySTL的思路是把这个迭代澄清的过程自动化、交互化让LLM Agent来主导这个对话。它不仅仅是一个翻译器更是一个引导者通过主动提问、提供选项、解释概念来帮助用户厘清自己模糊的意图共同“雕刻”出那个正确的STL公式。这对于降低形式化方法的门槛让更多工程领域能用上STL这样的强有力规范语言意义重大。2. 核心架构与交互机制设计ClarifySTL不是一个简单的提示词工程包装而是一个精心设计的多模块Agent框架。它的核心思想是将需求澄清这个复杂任务分解成一系列可管理的子任务每个子任务由特定的“技能模块”或“推理步骤”来处理LLM作为核心的推理和生成引擎在一个规划器的调度下协同工作。2.1 框架的核心组件与工作流整个框架可以看作一个状态机其状态就是当前对需求的理解和正在构建的STL公式。主要组件包括需求解析与意图识别模块这是对话的起点。用户输入一段自然语言描述比如“当传感器检测到入侵者时警报必须在2秒内响起并且持续到入侵者离开。” 这个模块的任务不是直接翻译而是进行浅层分析识别关键实体传感器、入侵者、警报、关键事件检测到、响起、离开和时间约束2秒内、持续。它会把一个模糊的句子初步解构成一组带有标签的要素为后续的深度澄清打下基础。这里LLM的能力用于进行命名实体识别和简单的关系抽取。澄清策略与问题生成引擎这是框架的“大脑”。基于初步解析的结果它会判断当前需求的模糊点在哪里。是时间界限不清晰“尽快”是多快是逻辑关系模糊“并且”是严格的逻辑与还是允许一定的顺序还是信号阈值未定义“离开”意味着距离大于多少米。然后它会根据一个内置的“澄清策略库”生成具体、可选的问题或选项来引导用户。例如针对“尽快”它可能会问“您期望的响应时间上限是多少请从以下选项中选择或自行指定A. 100毫秒 B. 500毫秒 C. 1秒 D. 其他请说明”。策略库的设计是关键它融合了STL的语法知识需要澄清哪些元素才能构成合法公式和人机交互的最佳实践如何提问更高效、更不易引发歧义。STL公式片段生成与组装器在每一轮交互中随着用户对某个模糊点的确认这个模块负责将已澄清的信息转化为对应的STL公式片段。例如用户确认了“警报响起”对应于布尔信号alarm_on true“2秒内”对应于时序运算符F[0,2]那么它就可以生成片段F[0,2] (alarm_on true)。这些片段被存储在一个结构化的“公式构建缓冲区”中。交互历史与上下文管理器它负责维护整个对话的历史确保LLM Agent拥有完整的上下文。这包括用户原始输入、所有澄清问答对、已生成的STL片段、以及用户可能做出的修正。这个上下文是保证对话连贯性和一致性的基础防止Agent“遗忘”之前已经确认的内容。验证与反馈模块可选但重要在生成初步的完整STL公式后这个模块可以介入。它可以尝试对公式进行简单的语法和语义检查或者更高级地连接到一个仿真环境或形式化验证工具用一些示例信号轨迹来“测试”这个公式是否符合用户的直观预期。然后将测试结果例如“根据您提供的样例当入侵者在1.5秒后离开警报在1秒时响起公式判定为满足。这符合您的预期吗”反馈给用户开启新一轮的澄清或确认。这形成了一个“构建-验证-反馈”的增强闭环。工作流是一个典型的迭代循环解析输入 - 识别模糊点 - 生成澄清问题 - 获取用户反馈 - 更新内部表示生成公式片段- 判断是否仍需澄清 - 是则继续否则组装最终公式并可选验证。2.2 LLM Agent的角色与提示工程设计在这个框架中LLM如GPT-4、Claude 3或开源模型被赋予了多重角色分析师解读自然语言。面试官主动提出精准问题。翻译官将自然语言片段映射为形式化片段。解释者向用户解释STL公式的含义确保双方理解一致。要让LLM扮演好这些角色提示词Prompt的设计至关重要它需要注入丰富的领域知识。一个典型的提示词结构如下你是一个STL信号时序逻辑需求澄清专家。你的任务是帮助用户将自然语言需求转化为精确的STL公式。 **背景知识** - STL用于描述连续时间信号上的性质。基本元素包括原子命题如 speed 5、逻辑运算符与、或||、非!、时序运算符全局G、最终F、直到U时间区间如 [a, b]。 - 例如“属性P在接下来3秒内一直为真” 表示为 G[0,3] P。“属性Q在5秒内最终会为真” 表示为 F[0,5] Q。 **当前对话历史** {交互历史管理器提供的上下文} **当前待澄清的需求片段/状态** {来自公式组装器的当前进度} **你的任务** 1. 分析当前状态确定最迫切需要澄清的1个模糊点如时间边界、逻辑连接词、信号阈值。 2. 根据以下策略生成1个澄清问题或提供2-3个具体选项 - 如果模糊点是时间提供几个典型时间范围选项。 - 如果模糊点是逻辑关系用真值表或场景举例说明不同选择的含义。 - 如果模糊点是阈值询问具体数值或比例。 3. 你的输出必须严格遵循以下JSON格式 { clarification_question: 生成的具体问题文本, options: [选项A, 选项B, 选项C可选], expected_impact: 此澄清将如何影响STL公式的生成用一句话说明 }通过这种结构化的提示我们将LLM的自由生成能力约束在一个对任务有利的框架内确保其输出是机器可解析JSON且目标明确的。实操心得提示词中的“预期影响”字段这个字段看似是给LLM自己看的实则极大地提升了交互质量。它迫使LLM在提问前先思考“我问这个是为了得到什么信息来构建公式”使其问题更具目的性。同时在向用户展示时可以选择性展示能让用户明白这个问题的意义增加配合度而不是觉得AI在问一些无关紧要的问题。3. STL语法引导与模糊需求拆解实战要让ClarifySTL有效工作必须将STL的语法结构作为引导澄清过程的“骨架”。STL公式不是凭空产生的它由原子命题和运算符递归组合而成。我们的澄清过程本质上就是沿着这个语法树自顶向下或自底向上地填充具体内容。3.1 从自然语言到STL构件的映射模式首先需要建立一套常见的自然语言模式到STL构件的映射词典。这不是死板的规则而是给LLM Agent的参考指南。全局性Globally“始终”、“在任何时候”、“永远不要” - 时序运算符G。澄清点时间范围。“始终”是指整个任务周期还是从某个事件后的某段时间需要澄清时间区间[t1, t2]。示例用户说“机器人运行时速度永远不要超过2m/s。” 澄清问题“您指的是从任务开始到结束的整个时间段内G[0, T_end] speed 2还是特指在移动过程中的所有时刻是否需要指定一个具体的时间范围”最终性Finally“最终”、“迟早”、“在...之内会” - 时序运算符F。澄清点时间上限。“最终”有没有截止时间需要澄清时间区间[0, t]中的t。示例用户说“检测到错误后系统最终要进入安全模式。” 澄清问题“您希望系统在多长时间内必须进入安全模式例如1秒内、5秒内还是只要在任务结束前即可”直到Until“直到...之前都...”、“在...发生前保持...” - 时序运算符U。澄清点这是最复杂的之一。需要澄清两部分1) 在停止条件发生前必须持续保持的性质φ2) 最终必须发生的停止条件ψ。以及两者是否需要在同一时间区间内。示例用户说“保持刹车灯亮起直到车辆完全停止。” 澄清问题“1. ‘车辆完全停止’具体指什么信号为真例如speed 0。2. 在停止发生之前是否要求刹车灯‘一直’亮着严格满足还是允许中间有短暂的关闭非严格满足这对应STL中严格U和非严格U_w的‘直到’运算符。”逻辑连接“并且”、“或者”、“除非” - 逻辑运算符、||、!、-(蕴含)。澄清点自然语言中的逻辑关系常常不严谨。“A并且B”可能指同时发生也可能指都需要满足但未必在同一时刻。需要澄清是逻辑与还是时序上的重叠。示例用户说“门打开并且有人靠近则报警。” 澄清问题“您是指‘门打开’和‘有人靠近’这两个条件‘同时’成立时报警door_open person_near - alarm还是只要两者都发生过不论先后就报警这关系到是否需要在公式中引入时序重叠的约束。”原子命题与阈值“速度快”、“温度高”、“距离近” - 原子命题如speed threshold。澄清点具体的数值阈值。这是最常见的模糊点。示例用户说“如果电池电量低则充电。” 澄清问题“‘电量低’的具体阈值是多少例如电池电压低于3.5V或剩余电量百分比低于15%。”3.2 交互式澄清的对话流模拟让我们模拟一个完整的小场景看看ClarifySTL如何工作。用户初始需求“当无人机飞到目标区域上方时它应该悬停至少10秒然后才能降落除非遇到强风。”第一轮解析与初始澄清Agent解析识别出关键事件“飞到目标区域上方”enter_zone、“悬停”hovering、“降落”landing、“遇到强风”strong_wind。识别出时间约束“至少10秒”逻辑词“然后”、“除非”。Agent提问针对最外层的逻辑和时序“您描述的‘除非遇到强风’是一个全局性的覆盖条件吗即一旦遇到强风无论处于悬停还是准备降落阶段都应立即中断当前任务并执行避风策略还是特指在‘准备降落’这个阶段遇到强风才中断降落”用户回复“是全局覆盖条件一旦检测到强风立即执行避风悬停和降落都中断。”Agent更新理解将“除非强风”理解为对整个任务流程的打断。初步构建公式框架!strong_wind U (任务序列) 其中“任务序列”待细化。第二轮澄清内部时序Agent提问“关于‘悬停至少10秒’是指从‘进入区域’那一刻开始连续不间断地悬停10秒吗G[0,10] hovering还是允许在10秒内累计悬停时间达到10秒”用户回复“需要连续不间断悬停10秒。”Agent更新细化“任务序列”为enter_zone - (hovering U_{10} landing)。这里U_{10}表示“直到…并且持续至少10秒”这是对标准Until的时延扩展需要向用户解释或转换为等价的STL公式如G[0,10] hovering F[10] landing。第三轮澄清细节与生成公式Agent提问“对于‘进入目标区域上方’我们是否需要定义一个具体的空间条件例如无人机位置与目标中心距离小于5米distance_to_target 5”用户回复“是的距离小于5米。”Agent组装最终公式原子命题in_zone (distance_to_target 5),hovering,landing,strong_wind。核心任务in_zone - (G[0,10] hovering F[10] landing)。解释一旦进入区域则接下来10秒全局悬停并且在10秒时最终降落。强风中断!strong_wind U (in_zone - (G[0,10] hovering F[10] landing))。解释在强风发生之前都必须满足“进入区域则悬停10秒后降落”这个性质。一旦强风发生此性质不再被要求任务中断。Agent向用户展示并解释公式询问是否符合预期。通过这样多轮的、有针对性的交互一个模糊的需求被逐步雕刻成了精确的STL公式。这个过程比一次性让用户写出完整公式要友好得多也准确得多。4. 框架实现的关键技术考量与挑战构建ClarifySTL这样的框架除了核心交互逻辑在工程实现上还会遇到几个关键挑战和需要权衡的技术选型。4.1 LLM的稳定性与成本控制LLM API的调用是不可靠的可能遇到速率限制、网络抖动、服务降级或非预期的输出格式。在交互式系统中这种不稳定会直接破坏用户体验。稳定性策略重试与回退机制对于可重试的错误如网络超时、速率限制实现指数退避的重试逻辑。同时可以准备一个轻量级的“回退模型”比如一个基于规则或小规模微调模型的简化澄清器当主LLM服务连续失败时临时切换保证系统基本功能可用。输出格式校验与修复LLM可能不严格按照指定的JSON格式输出。需要在解析前加入一个格式校验和修复层。可以用一个轻量级文本处理逻辑或者甚至用另一个小型、快速的LLM如调用一次GPT-3.5-Turbo专门来修复格式确保下游模块能可靠解析。上下文长度管理对话历史会越来越长。需要设计智能的上下文窗口管理策略不是简单截断而是进行摘要Summarization。例如每经过几轮对话就让LLM自己对之前的澄清历史和已确定的公式片段生成一个简洁的摘要用这个摘要替代冗长的原始历史放入后续对话的上下文。这能有效控制token消耗也帮助LLM聚焦于当前待解决的问题。成本控制分层模型使用不是所有任务都需要最强大的模型。可以将任务分级需求解析、核心问题生成使用高性能模型如GPT-4格式修复、历史摘要使用低成本模型如GPT-3.5-Turbo或开源小模型简单的语法检查可以用规则实现。缓存对于常见、模式化的澄清问题如询问时间阈值、逻辑关系其生成结果可以缓存。当识别到相似的模糊模式时可以直接从缓存中取出预制的问题模板稍作填充即可无需每次都调用LLM生成。非流式处理对于一轮澄清尽量在一次LLM调用中完成分析、问题生成和格式构造避免多次串行调用增加延迟和成本。4.2 领域知识注入与可扩展性ClarifySTL的有效性严重依赖于其对STL和特定应用领域如机器人、汽车控制的理解。如何优雅地注入和扩展这些知识结构化知识库建立一个可扩展的领域知识库包含STL语法模板库各种STL运算符的常见自然语言表达模式。领域实体与信号库针对特定领域如自动驾驶预定义常见的信号变量ego_speed,pedestrian_distance,traffic_light_color及其合理的取值范围、单位。澄清策略库针对不同类型的模糊点时间模糊、阈值模糊、逻辑模糊、范围模糊预定义提问的模板和策略。 这些知识库以结构化的数据JSON/YAML或向量数据库的形式存储在运行时被动态注入到LLM的提示词中。提示词模板化与动态组装核心提示词应该是模板化的。根据当前对话阶段、已识别的领域和模糊类型从知识库中选取相关的模板片段如STL语法解释、领域信号列表、特定澄清策略动态组装成最终发送给LLM的提示词。这使得框架能够轻松适配新领域只需更新知识库而无需重写核心代码。支持用户自定义允许高级用户或领域专家在交互过程中临时定义新的信号变量或约束关系。框架需要能将这些用户自定义内容吸收进当前会话的上下文并在后续的澄清中加以利用。4.3 评估与持续改进如何衡量一个ClarifySTL框架的好坏不能只看最终生成的STL公式语法是否正确更要看整个交互过程的质量和结果的有效性。评估指标任务完成度最终生成的STL公式是否完整覆盖了用户原始需求的所有关键点交互效率平均需要多少轮对话或多少token能完成一个需求的澄清用户认知负荷用户是否觉得问题清晰易懂是否需要反复解释同一个概念可以通过事后问卷调查或分析用户修正次数来评估。公式正确性生成的STL公式在语法上是否正确在语义上是否与一组公认的测试用例由专家标注匹配可以通过自动化测试将框架输出与黄金标准Gold Standard公式进行比对。鲁棒性面对模糊、矛盾甚至包含错误信息的用户输入框架能否稳健地引导对话回到正轨而不是被带偏或崩溃持续改进循环数据收集在框架使用过程中经用户同意匿名记录交互日志包括用户输入、Agent输出、最终公式等。问题识别分析日志找出高频的澄清失败点、用户频繁修正的地方、或LLM生成质量低的环节。知识库/策略优化根据分析结果优化澄清策略库的提问方式补充新的领域知识模板或调整提示词中某些部分的权重。A/B测试对于重要的策略修改可以进行小规模的A/B测试比较新旧版本在评估指标上的差异。 这个迭代过程使得ClarifySTL能够越用越“聪明”越来越贴合特定用户群体或领域的需求。5. 典型应用场景与未来延伸思考ClarifySTL框架的价值在于它桥接了两个世界其应用场景自然围绕需要这种“翻译”和“澄清”的领域展开。5.1 核心应用场景形式化验证与测试用例生成这是最直接的应用。验证工程师使用ClarifySTL与系统架构师或产品经理协作将高层的安全需求如“自动驾驶汽车在行人横穿马路时必须刹车”转化为精确的STL规范。这些规范可以直接输入给形式化验证工具如S-TaLiRo, Breach进行属性检查或用于指导生成覆盖特定场景的测试用例。强化学习奖励函数设计在基于强化学习RL的控制器设计中设计奖励函数Reward Function是一门艺术常常需要反复试错。STL可以形式化地描述期望的任务完成质量。通过ClarifySTL将任务目标转化为STL公式然后利用“STL鲁棒度”STL Robustness这一概念——一个量化信号轨迹满足STL公式程度的标量值——可以直接将其作为RL的奖励信号。这使得奖励函数的设计更加直观和可解释。工业控制系统规范文档化在航空、轨道交通等安全关键领域需求文档必须清晰无歧义。ClarifySTL可以作为一个辅助工具帮助需求工程师在编写文档时就将其中的关键行为约束用STL公式的形式记录下来作为自然语言描述的补充极大提升文档的精确性。教育培训对于学习形式化方法或STL的学生和工程师ClarifySTL是一个极佳的交互式学习工具。他们可以输入自己理解的自然语言描述看Agent如何提问、如何构建公式从而反向学习STL的语法和语义理解自然语言中的模糊性如何被形式化消除。5.2 挑战与未来方向尽管前景广阔ClarifySTL要走向成熟和大规模应用还需克服不少挑战处理极端模糊和矛盾需求当用户需求本身存在内在矛盾如“响应要最快同时功耗要最低”或极度模糊如“用户体验要好”时框架如何引导用户揭示背后的权衡Trade-off而不是陷入无限循环的澄清这可能需要引入多目标优化或优先级排序的概念。与领域特定语言DSL和工具的集成STL是通用时序逻辑但在某些领域可能有更专用的规范语言。框架需要具备一定的可扩展性未来或许能支持将澄清后的需求输出为多种形式化语言如LTL、CTL或特定工具的输入格式。多模态输入未来的需求描述可能不限于文本。用户可能上传一张系统架构图、一段仿真视频或一个数据曲线然后说“我希望系统像这样运行”。框架需要结合视觉、语音等多模态理解能力从更丰富的输入中提取需求信息。从单次澄清到持续规范管理系统需求是不断演化的。一个理想的框架不仅帮助生成初始规范还应能管理规范的版本变迁。当用户说“我想改一下之前那个需求...”框架应能定位到历史对话和对应的公式片段进行增量式的修改和更新而不是从头再来。ClarifySTL代表了一种人机协作的新范式不是用机器完全替代人类专家而是用机器放大人类专家的能力尤其是处理形式化、精确化思维的能力。它把枯燥、易错的形式化转换过程变成了一个结构化的、引导式的对话。在我自己的尝试和构想中这类工具的成功不仅取决于LLM本身的能力更取决于我们对专业领域知识的深刻理解以及如何将这些知识巧妙地设计进交互流程和提示词中。它提醒我们在AI时代最强大的系统往往是那些最懂得如何将人类智慧与机器计算无缝融合的系统。
ClarifySTL：基于LLM Agent的交互式STL需求澄清框架设计与实践
1. 项目概述当大语言模型遇上形式化需求澄清最近在搞一个叫ClarifySTL的项目本质上是一个交互式的LLM Agent框架专门用来处理STL转换过程中的需求澄清问题。听起来有点绕简单来说就是让大语言模型LLM扮演一个“需求分析师”和“形式化工程师”的混合角色帮助你把一段模糊的、用自然语言描述的系统行为需求一步步澄清、细化最终转换成精确的、机器可验证的Signal Temporal Logic信号时序逻辑STL公式。为什么这个事值得专门做个框架我干了这么多年形式化验证和需求工程太清楚这里面的痛点了。STL是个好东西它能用数学语言精确描述系统在连续时间信号上的行为比如“机器人的速度在进入危险区域后3秒内必须降到0.5米/秒以下”。但问题在于能熟练、准确写出STL公式的工程师凤毛麟角。更常见的情况是领域专家比如机器人专家、控制工程师有一堆想法但只能用自然语言说个大概“我希望系统反应快点别撞上东西要稳定。” 这种需求直接丢给验证工具或者用于控制器合成门都没有。中间这个巨大的鸿沟——从“人话”到“数学话”——就是ClarifySTL要填的坑。传统的做法是靠人肉迭代形式化工程师拿着自然语言需求文档反复和领域专家开会、发邮件、写注释一点点抠字眼试图把“反应快点”量化成“响应时间小于200毫秒”把“别撞上”定义成“与障碍物距离始终大于0.1米”。这个过程极其耗时沟通成本高还容易产生误解。ClarifySTL的思路是把这个迭代澄清的过程自动化、交互化让LLM Agent来主导这个对话。它不仅仅是一个翻译器更是一个引导者通过主动提问、提供选项、解释概念来帮助用户厘清自己模糊的意图共同“雕刻”出那个正确的STL公式。这对于降低形式化方法的门槛让更多工程领域能用上STL这样的强有力规范语言意义重大。2. 核心架构与交互机制设计ClarifySTL不是一个简单的提示词工程包装而是一个精心设计的多模块Agent框架。它的核心思想是将需求澄清这个复杂任务分解成一系列可管理的子任务每个子任务由特定的“技能模块”或“推理步骤”来处理LLM作为核心的推理和生成引擎在一个规划器的调度下协同工作。2.1 框架的核心组件与工作流整个框架可以看作一个状态机其状态就是当前对需求的理解和正在构建的STL公式。主要组件包括需求解析与意图识别模块这是对话的起点。用户输入一段自然语言描述比如“当传感器检测到入侵者时警报必须在2秒内响起并且持续到入侵者离开。” 这个模块的任务不是直接翻译而是进行浅层分析识别关键实体传感器、入侵者、警报、关键事件检测到、响起、离开和时间约束2秒内、持续。它会把一个模糊的句子初步解构成一组带有标签的要素为后续的深度澄清打下基础。这里LLM的能力用于进行命名实体识别和简单的关系抽取。澄清策略与问题生成引擎这是框架的“大脑”。基于初步解析的结果它会判断当前需求的模糊点在哪里。是时间界限不清晰“尽快”是多快是逻辑关系模糊“并且”是严格的逻辑与还是允许一定的顺序还是信号阈值未定义“离开”意味着距离大于多少米。然后它会根据一个内置的“澄清策略库”生成具体、可选的问题或选项来引导用户。例如针对“尽快”它可能会问“您期望的响应时间上限是多少请从以下选项中选择或自行指定A. 100毫秒 B. 500毫秒 C. 1秒 D. 其他请说明”。策略库的设计是关键它融合了STL的语法知识需要澄清哪些元素才能构成合法公式和人机交互的最佳实践如何提问更高效、更不易引发歧义。STL公式片段生成与组装器在每一轮交互中随着用户对某个模糊点的确认这个模块负责将已澄清的信息转化为对应的STL公式片段。例如用户确认了“警报响起”对应于布尔信号alarm_on true“2秒内”对应于时序运算符F[0,2]那么它就可以生成片段F[0,2] (alarm_on true)。这些片段被存储在一个结构化的“公式构建缓冲区”中。交互历史与上下文管理器它负责维护整个对话的历史确保LLM Agent拥有完整的上下文。这包括用户原始输入、所有澄清问答对、已生成的STL片段、以及用户可能做出的修正。这个上下文是保证对话连贯性和一致性的基础防止Agent“遗忘”之前已经确认的内容。验证与反馈模块可选但重要在生成初步的完整STL公式后这个模块可以介入。它可以尝试对公式进行简单的语法和语义检查或者更高级地连接到一个仿真环境或形式化验证工具用一些示例信号轨迹来“测试”这个公式是否符合用户的直观预期。然后将测试结果例如“根据您提供的样例当入侵者在1.5秒后离开警报在1秒时响起公式判定为满足。这符合您的预期吗”反馈给用户开启新一轮的澄清或确认。这形成了一个“构建-验证-反馈”的增强闭环。工作流是一个典型的迭代循环解析输入 - 识别模糊点 - 生成澄清问题 - 获取用户反馈 - 更新内部表示生成公式片段- 判断是否仍需澄清 - 是则继续否则组装最终公式并可选验证。2.2 LLM Agent的角色与提示工程设计在这个框架中LLM如GPT-4、Claude 3或开源模型被赋予了多重角色分析师解读自然语言。面试官主动提出精准问题。翻译官将自然语言片段映射为形式化片段。解释者向用户解释STL公式的含义确保双方理解一致。要让LLM扮演好这些角色提示词Prompt的设计至关重要它需要注入丰富的领域知识。一个典型的提示词结构如下你是一个STL信号时序逻辑需求澄清专家。你的任务是帮助用户将自然语言需求转化为精确的STL公式。 **背景知识** - STL用于描述连续时间信号上的性质。基本元素包括原子命题如 speed 5、逻辑运算符与、或||、非!、时序运算符全局G、最终F、直到U时间区间如 [a, b]。 - 例如“属性P在接下来3秒内一直为真” 表示为 G[0,3] P。“属性Q在5秒内最终会为真” 表示为 F[0,5] Q。 **当前对话历史** {交互历史管理器提供的上下文} **当前待澄清的需求片段/状态** {来自公式组装器的当前进度} **你的任务** 1. 分析当前状态确定最迫切需要澄清的1个模糊点如时间边界、逻辑连接词、信号阈值。 2. 根据以下策略生成1个澄清问题或提供2-3个具体选项 - 如果模糊点是时间提供几个典型时间范围选项。 - 如果模糊点是逻辑关系用真值表或场景举例说明不同选择的含义。 - 如果模糊点是阈值询问具体数值或比例。 3. 你的输出必须严格遵循以下JSON格式 { clarification_question: 生成的具体问题文本, options: [选项A, 选项B, 选项C可选], expected_impact: 此澄清将如何影响STL公式的生成用一句话说明 }通过这种结构化的提示我们将LLM的自由生成能力约束在一个对任务有利的框架内确保其输出是机器可解析JSON且目标明确的。实操心得提示词中的“预期影响”字段这个字段看似是给LLM自己看的实则极大地提升了交互质量。它迫使LLM在提问前先思考“我问这个是为了得到什么信息来构建公式”使其问题更具目的性。同时在向用户展示时可以选择性展示能让用户明白这个问题的意义增加配合度而不是觉得AI在问一些无关紧要的问题。3. STL语法引导与模糊需求拆解实战要让ClarifySTL有效工作必须将STL的语法结构作为引导澄清过程的“骨架”。STL公式不是凭空产生的它由原子命题和运算符递归组合而成。我们的澄清过程本质上就是沿着这个语法树自顶向下或自底向上地填充具体内容。3.1 从自然语言到STL构件的映射模式首先需要建立一套常见的自然语言模式到STL构件的映射词典。这不是死板的规则而是给LLM Agent的参考指南。全局性Globally“始终”、“在任何时候”、“永远不要” - 时序运算符G。澄清点时间范围。“始终”是指整个任务周期还是从某个事件后的某段时间需要澄清时间区间[t1, t2]。示例用户说“机器人运行时速度永远不要超过2m/s。” 澄清问题“您指的是从任务开始到结束的整个时间段内G[0, T_end] speed 2还是特指在移动过程中的所有时刻是否需要指定一个具体的时间范围”最终性Finally“最终”、“迟早”、“在...之内会” - 时序运算符F。澄清点时间上限。“最终”有没有截止时间需要澄清时间区间[0, t]中的t。示例用户说“检测到错误后系统最终要进入安全模式。” 澄清问题“您希望系统在多长时间内必须进入安全模式例如1秒内、5秒内还是只要在任务结束前即可”直到Until“直到...之前都...”、“在...发生前保持...” - 时序运算符U。澄清点这是最复杂的之一。需要澄清两部分1) 在停止条件发生前必须持续保持的性质φ2) 最终必须发生的停止条件ψ。以及两者是否需要在同一时间区间内。示例用户说“保持刹车灯亮起直到车辆完全停止。” 澄清问题“1. ‘车辆完全停止’具体指什么信号为真例如speed 0。2. 在停止发生之前是否要求刹车灯‘一直’亮着严格满足还是允许中间有短暂的关闭非严格满足这对应STL中严格U和非严格U_w的‘直到’运算符。”逻辑连接“并且”、“或者”、“除非” - 逻辑运算符、||、!、-(蕴含)。澄清点自然语言中的逻辑关系常常不严谨。“A并且B”可能指同时发生也可能指都需要满足但未必在同一时刻。需要澄清是逻辑与还是时序上的重叠。示例用户说“门打开并且有人靠近则报警。” 澄清问题“您是指‘门打开’和‘有人靠近’这两个条件‘同时’成立时报警door_open person_near - alarm还是只要两者都发生过不论先后就报警这关系到是否需要在公式中引入时序重叠的约束。”原子命题与阈值“速度快”、“温度高”、“距离近” - 原子命题如speed threshold。澄清点具体的数值阈值。这是最常见的模糊点。示例用户说“如果电池电量低则充电。” 澄清问题“‘电量低’的具体阈值是多少例如电池电压低于3.5V或剩余电量百分比低于15%。”3.2 交互式澄清的对话流模拟让我们模拟一个完整的小场景看看ClarifySTL如何工作。用户初始需求“当无人机飞到目标区域上方时它应该悬停至少10秒然后才能降落除非遇到强风。”第一轮解析与初始澄清Agent解析识别出关键事件“飞到目标区域上方”enter_zone、“悬停”hovering、“降落”landing、“遇到强风”strong_wind。识别出时间约束“至少10秒”逻辑词“然后”、“除非”。Agent提问针对最外层的逻辑和时序“您描述的‘除非遇到强风’是一个全局性的覆盖条件吗即一旦遇到强风无论处于悬停还是准备降落阶段都应立即中断当前任务并执行避风策略还是特指在‘准备降落’这个阶段遇到强风才中断降落”用户回复“是全局覆盖条件一旦检测到强风立即执行避风悬停和降落都中断。”Agent更新理解将“除非强风”理解为对整个任务流程的打断。初步构建公式框架!strong_wind U (任务序列) 其中“任务序列”待细化。第二轮澄清内部时序Agent提问“关于‘悬停至少10秒’是指从‘进入区域’那一刻开始连续不间断地悬停10秒吗G[0,10] hovering还是允许在10秒内累计悬停时间达到10秒”用户回复“需要连续不间断悬停10秒。”Agent更新细化“任务序列”为enter_zone - (hovering U_{10} landing)。这里U_{10}表示“直到…并且持续至少10秒”这是对标准Until的时延扩展需要向用户解释或转换为等价的STL公式如G[0,10] hovering F[10] landing。第三轮澄清细节与生成公式Agent提问“对于‘进入目标区域上方’我们是否需要定义一个具体的空间条件例如无人机位置与目标中心距离小于5米distance_to_target 5”用户回复“是的距离小于5米。”Agent组装最终公式原子命题in_zone (distance_to_target 5),hovering,landing,strong_wind。核心任务in_zone - (G[0,10] hovering F[10] landing)。解释一旦进入区域则接下来10秒全局悬停并且在10秒时最终降落。强风中断!strong_wind U (in_zone - (G[0,10] hovering F[10] landing))。解释在强风发生之前都必须满足“进入区域则悬停10秒后降落”这个性质。一旦强风发生此性质不再被要求任务中断。Agent向用户展示并解释公式询问是否符合预期。通过这样多轮的、有针对性的交互一个模糊的需求被逐步雕刻成了精确的STL公式。这个过程比一次性让用户写出完整公式要友好得多也准确得多。4. 框架实现的关键技术考量与挑战构建ClarifySTL这样的框架除了核心交互逻辑在工程实现上还会遇到几个关键挑战和需要权衡的技术选型。4.1 LLM的稳定性与成本控制LLM API的调用是不可靠的可能遇到速率限制、网络抖动、服务降级或非预期的输出格式。在交互式系统中这种不稳定会直接破坏用户体验。稳定性策略重试与回退机制对于可重试的错误如网络超时、速率限制实现指数退避的重试逻辑。同时可以准备一个轻量级的“回退模型”比如一个基于规则或小规模微调模型的简化澄清器当主LLM服务连续失败时临时切换保证系统基本功能可用。输出格式校验与修复LLM可能不严格按照指定的JSON格式输出。需要在解析前加入一个格式校验和修复层。可以用一个轻量级文本处理逻辑或者甚至用另一个小型、快速的LLM如调用一次GPT-3.5-Turbo专门来修复格式确保下游模块能可靠解析。上下文长度管理对话历史会越来越长。需要设计智能的上下文窗口管理策略不是简单截断而是进行摘要Summarization。例如每经过几轮对话就让LLM自己对之前的澄清历史和已确定的公式片段生成一个简洁的摘要用这个摘要替代冗长的原始历史放入后续对话的上下文。这能有效控制token消耗也帮助LLM聚焦于当前待解决的问题。成本控制分层模型使用不是所有任务都需要最强大的模型。可以将任务分级需求解析、核心问题生成使用高性能模型如GPT-4格式修复、历史摘要使用低成本模型如GPT-3.5-Turbo或开源小模型简单的语法检查可以用规则实现。缓存对于常见、模式化的澄清问题如询问时间阈值、逻辑关系其生成结果可以缓存。当识别到相似的模糊模式时可以直接从缓存中取出预制的问题模板稍作填充即可无需每次都调用LLM生成。非流式处理对于一轮澄清尽量在一次LLM调用中完成分析、问题生成和格式构造避免多次串行调用增加延迟和成本。4.2 领域知识注入与可扩展性ClarifySTL的有效性严重依赖于其对STL和特定应用领域如机器人、汽车控制的理解。如何优雅地注入和扩展这些知识结构化知识库建立一个可扩展的领域知识库包含STL语法模板库各种STL运算符的常见自然语言表达模式。领域实体与信号库针对特定领域如自动驾驶预定义常见的信号变量ego_speed,pedestrian_distance,traffic_light_color及其合理的取值范围、单位。澄清策略库针对不同类型的模糊点时间模糊、阈值模糊、逻辑模糊、范围模糊预定义提问的模板和策略。 这些知识库以结构化的数据JSON/YAML或向量数据库的形式存储在运行时被动态注入到LLM的提示词中。提示词模板化与动态组装核心提示词应该是模板化的。根据当前对话阶段、已识别的领域和模糊类型从知识库中选取相关的模板片段如STL语法解释、领域信号列表、特定澄清策略动态组装成最终发送给LLM的提示词。这使得框架能够轻松适配新领域只需更新知识库而无需重写核心代码。支持用户自定义允许高级用户或领域专家在交互过程中临时定义新的信号变量或约束关系。框架需要能将这些用户自定义内容吸收进当前会话的上下文并在后续的澄清中加以利用。4.3 评估与持续改进如何衡量一个ClarifySTL框架的好坏不能只看最终生成的STL公式语法是否正确更要看整个交互过程的质量和结果的有效性。评估指标任务完成度最终生成的STL公式是否完整覆盖了用户原始需求的所有关键点交互效率平均需要多少轮对话或多少token能完成一个需求的澄清用户认知负荷用户是否觉得问题清晰易懂是否需要反复解释同一个概念可以通过事后问卷调查或分析用户修正次数来评估。公式正确性生成的STL公式在语法上是否正确在语义上是否与一组公认的测试用例由专家标注匹配可以通过自动化测试将框架输出与黄金标准Gold Standard公式进行比对。鲁棒性面对模糊、矛盾甚至包含错误信息的用户输入框架能否稳健地引导对话回到正轨而不是被带偏或崩溃持续改进循环数据收集在框架使用过程中经用户同意匿名记录交互日志包括用户输入、Agent输出、最终公式等。问题识别分析日志找出高频的澄清失败点、用户频繁修正的地方、或LLM生成质量低的环节。知识库/策略优化根据分析结果优化澄清策略库的提问方式补充新的领域知识模板或调整提示词中某些部分的权重。A/B测试对于重要的策略修改可以进行小规模的A/B测试比较新旧版本在评估指标上的差异。 这个迭代过程使得ClarifySTL能够越用越“聪明”越来越贴合特定用户群体或领域的需求。5. 典型应用场景与未来延伸思考ClarifySTL框架的价值在于它桥接了两个世界其应用场景自然围绕需要这种“翻译”和“澄清”的领域展开。5.1 核心应用场景形式化验证与测试用例生成这是最直接的应用。验证工程师使用ClarifySTL与系统架构师或产品经理协作将高层的安全需求如“自动驾驶汽车在行人横穿马路时必须刹车”转化为精确的STL规范。这些规范可以直接输入给形式化验证工具如S-TaLiRo, Breach进行属性检查或用于指导生成覆盖特定场景的测试用例。强化学习奖励函数设计在基于强化学习RL的控制器设计中设计奖励函数Reward Function是一门艺术常常需要反复试错。STL可以形式化地描述期望的任务完成质量。通过ClarifySTL将任务目标转化为STL公式然后利用“STL鲁棒度”STL Robustness这一概念——一个量化信号轨迹满足STL公式程度的标量值——可以直接将其作为RL的奖励信号。这使得奖励函数的设计更加直观和可解释。工业控制系统规范文档化在航空、轨道交通等安全关键领域需求文档必须清晰无歧义。ClarifySTL可以作为一个辅助工具帮助需求工程师在编写文档时就将其中的关键行为约束用STL公式的形式记录下来作为自然语言描述的补充极大提升文档的精确性。教育培训对于学习形式化方法或STL的学生和工程师ClarifySTL是一个极佳的交互式学习工具。他们可以输入自己理解的自然语言描述看Agent如何提问、如何构建公式从而反向学习STL的语法和语义理解自然语言中的模糊性如何被形式化消除。5.2 挑战与未来方向尽管前景广阔ClarifySTL要走向成熟和大规模应用还需克服不少挑战处理极端模糊和矛盾需求当用户需求本身存在内在矛盾如“响应要最快同时功耗要最低”或极度模糊如“用户体验要好”时框架如何引导用户揭示背后的权衡Trade-off而不是陷入无限循环的澄清这可能需要引入多目标优化或优先级排序的概念。与领域特定语言DSL和工具的集成STL是通用时序逻辑但在某些领域可能有更专用的规范语言。框架需要具备一定的可扩展性未来或许能支持将澄清后的需求输出为多种形式化语言如LTL、CTL或特定工具的输入格式。多模态输入未来的需求描述可能不限于文本。用户可能上传一张系统架构图、一段仿真视频或一个数据曲线然后说“我希望系统像这样运行”。框架需要结合视觉、语音等多模态理解能力从更丰富的输入中提取需求信息。从单次澄清到持续规范管理系统需求是不断演化的。一个理想的框架不仅帮助生成初始规范还应能管理规范的版本变迁。当用户说“我想改一下之前那个需求...”框架应能定位到历史对话和对应的公式片段进行增量式的修改和更新而不是从头再来。ClarifySTL代表了一种人机协作的新范式不是用机器完全替代人类专家而是用机器放大人类专家的能力尤其是处理形式化、精确化思维的能力。它把枯燥、易错的形式化转换过程变成了一个结构化的、引导式的对话。在我自己的尝试和构想中这类工具的成功不仅取决于LLM本身的能力更取决于我们对专业领域知识的深刻理解以及如何将这些知识巧妙地设计进交互流程和提示词中。它提醒我们在AI时代最强大的系统往往是那些最懂得如何将人类智慧与机器计算无缝融合的系统。 
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
