LLM-Based Discovery of Latent Requirements from Stakeholder Conversations: Preliminary Results from Industry
本文介绍了 LENS，一种基于大语言模型的方法，该方法通过对组织上下文进行推理，分析利益相关者访谈转录文本以提取显式需求并推断潜在需求，在提取准确性方面表现出高水平，并在工业网络安全评估中展示了显著的实际价值。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下你是一名正在试图破解谜题的侦探，但你的任务不是在犯罪现场寻找线索，而是在倾听一段由客户与业务顾问进行的漫长且东拉西扯的对话。客户正在描述他们的日常挣扎、抱怨某些任务耗时过长，以及描述他们的团队是如何运作的。
问题所在：
通常情况下，当公司想要构建新软件时，他们会询问他们的员工（利益相关者）：“你们需要什么？”员工可能会说：“我需要一个能实现 X 功能的按钮。”这就是一个显性需求（explicit requirement）——它被清晰地记录了下来。
但通常情况下，员工并不知道自己究竟需要什么。他们可能只是在说：“我每周都要花三个小时写这些报告，”或者“我必须从三个不同的地方复制粘贴数据。”他们并不是在请求软件；他们只是在描述一个痛点。这些隐藏的需求被称为隐性需求（latent requirements）。如果人类分析师在对话中倾听，他们或许能推断出：“啊，如果我们做一个自动报告生成器，就能解决他们这三个小时的问题。”但人类会疲劳，听取数小时的音频既缓慢又昂贵。
解决方案：LENS
这篇论文介绍了一个名为 LENS（LLM-驱动的需求发现工具）的新工具。你可以把 LENS 想象成一个超级聪明、不知疲倦的侦探，它已经读过了关于该公司所有工具的使用手册。
LENS 做两件事：
- 记录员（The Scribe）： 它倾听对话并准确记录下人们所要求的具体内容（显性需求）。
- 侦探（The Detective）： 它倾听那些关于抱怨和混乱工作流的描述，然后将其与公司现有的技术“小抄”进行交叉比对。接着它会说：“等等，我知道你并没有要求这个，但基于你刚才提到的那个缓慢的手动流程，并且考虑到你拥有一种可以实现此功能的特定工具，你应该拥有一个能自动修复该问题的功能。”
它是如何工作的（类比）：
想象一下，你正在和一位朋友聊天，他说：“我讨厌每天为了买牛奶而走去商店，这太累了。”
- 记录员写下：“朋友想要买牛奶。”
- 侦探（LENS）观察你朋友的家，看到他们安装了一台智能冰箱和一款生鲜配送 App，但从未被使用过。侦探随后建议：“我推断你的朋友需要一个‘智能牛奶订购’功能，可以在冰箱存量不足时自动订购牛奶。”
LENS 将这些建议写成“用户故事”（描述软件需求的一种标准方式），并将它们链接回对话中产生该想法的具体时刻，这样就没人能质疑：“你从哪儿得来的这个主意？”
实验过程：
研究人员使用一家名为 eSentire 的网络安全公司对该工具进行了测试。他们将 12 场真实的员工访谈（每场约 60 分钟）输入给 LENS。
- 结果 1（记录员）： 当寻找人们明确要求的内容时，LENS 非常准确。它找到了 100% 的请求，并且在 73% 的情况下是正确的，从而得到了一个很高的综合评分。
- 结果 2（侦探）： 当寻找隐性需求时，研究人员邀请人类专家进行评判。他们发现，LENS 提出的“隐藏”想法中有 75% 被认为是有用的。专家们认为这些想法可以节省时间或实现枯燥任务的自动化。
陷阱（论文向我们发出的警告）：
这篇论文非常诚实地说明了局限性。
- 混淆： 有时 LENS 会被人们的表达方式搞混。如果有人说：“我们现在已经是自动完成了，对吧？”LENS 可能会认为他们是在要求实现自动化，而实际上他们只是在确认该功能已经存在。
- 可行性： 虽然想法很好，但有时 LENS 提供的细节不够。它可能会建议一个听起来很棒的解决方案，但该方案需要某种特定的数据，或者需要连接两个公司实际上并不具备连接能力的工具。
- 并非最终产品： 论文强调 LENS 并不会给你一个完成的软件产品。它给你的是一份讨论用的想法清单。它更像是一个头脑风暴的伙伴，而不是一份做好的成品餐点。
总结：
这篇论文表明，AI 可以倾听业务对话，记录人们的要求，并作为一个创造性的伙伴，针对人们甚至还没意识到可以解决的问题来建议软件解决方案。它表现良好，但仍然需要人类专家来复核这些想法，并确保它们在实际操作中是可行的。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。