当前位置: 首页 > news >正文

[论文阅读] 人工智能 + 软件工程 | AI助力软件可解释性:从用户评论到自动生成需求与解释

AI助力软件可解释性:从用户评论到自动生成需求与解释

Automatic Generation of Explainability Requirements and Software Explanations From User Reviews

arXiv:2507.07344
Automatic Generation of Explainability Requirements and Software Explanations From User Reviews
Martin Obaidi, Jannik Fischbach, Jakob Droste, Hannah Deters, Marc Herrmann, Jil Klünder, Steffen Krätzig, Hugo Villamizar, Kurt Schneider
Comments: This paper has been accepted at the 33rd IEEE International Requirements Engineering Workshop (REW 2025)
Subjects: Software Engineering (cs.SE)

研究背景:软件越来越“难懂”,可解释性成刚需

你是否有过这样的经历:手机App弹出一个对话框,按钮上写着“确定”和“取消”,但你完全不知道点了之后会发生什么?或者,推荐算法给你推了一堆莫名其妙的内容,你根本搞不懂它为什么会这么推荐?

这其实反映了现代软件系统的一个普遍问题:随着人工智能和数据驱动技术的加入,软件变得越来越复杂,用户越来越难理解它们的行为。这种“难懂”不仅影响用户体验,还可能让用户失去信任,甚至在某些涉及隐私、安全的场景下带来风险。

因此,“可解释性”——也就是软件能够向用户解释自己的行为和决策——变得越来越重要。它就像软件的“说明书”,但又不止于此,它需要嵌入到软件的各种交互中。

然而,这里存在一个巨大的挑战:用户通常会在评论里用很随意的语言表达他们的困惑(比如“这个按钮到底是干嘛的?”“为什么我的数据突然不见了?”),开发团队很难把这些零散的“吐槽”转化为明确的、可执行的改进要求,更别说据此生成具体的解释文本了。就像把一堆用户的“碎碎念”整理成工程师能看懂的“任务清单”,还要写出对应的“标准答案”,这活儿可不轻松。

在这里插入图片描述

主要作者及单位

本文由来自多个机构的研究者合作完成,包括:

  • Martin Obaidi, Jakob Droste, Hannah Deters, Marc Herrmann, Kurt Schneider(德国汉诺威莱布尼茨大学软件工程组)
  • Jil Klünder(德国汉诺威应用科学大学)
  • Hugo Villamizar(德国慕尼黑fortiss GmbH)
  • Jannik Fischbach(德国慕尼黑Netlight咨询公司与fortiss GmbH)
  • Steffen Krätzig(德国勃隆贝格菲尼克斯电气公司)

创新点:让AI帮你“翻译”用户需求

这篇论文的核心创新在于提出了一种工具支持的自动化方法,能够:

  1. 从用户评论中“读”出他们需要解释的地方;
  2. 自动生成结构化的“可解释性需求”(告诉开发团队“软件必须解释什么”);
  3. 基于这些需求,自动生成可以直接用在软件界面上的解释文本。

简单说,就是让AI充当“翻译官”,把用户的自然语言反馈,翻译成工程师能懂的技术要求,再进一步变成用户能看懂的解释内容。

此外,研究还创建了一个包含58条用户评论的数据集,每条评论都配有人工和AI生成的可解释性需求及解释,为后续研究提供了宝贵的基准。

研究方法:一步步拆解AI的“工作流程”

为了实现这个自动化过程,研究者设计了清晰的步骤,并开发了相应的工具:

  1. 处理用户评论

    • 首先用AI(ChatGPT 3.5)总结用户评论,去除情绪化的表达,只保留核心信息(比如把“这破弹窗太坑了,点啥都删数据!”总结为“弹窗按钮功能不明确,存在数据删除风险”)。
    • 这一步就像给AI“划重点”,确保后续生成的内容不跑偏。
  2. 生成可解释性需求

    • 基于总结后的评论,用特定的提示词让AI生成结构化的需求,格式统一为“The system must explain…”(比如“系统必须解释弹窗中‘关闭’和‘确定’按钮的具体功能”)。
    • 为了保证需求的正式性和一致性,这一步会调低AI的“创造力”参数(温度设为0.3)。
  3. 生成解释文本

    • 基于生成的需求,再让AI生成可以展示在软件界面上的解释(比如针对上面的需求,生成“弹窗中的‘关闭’按钮仅关闭窗口,‘确定’按钮会删除当前数据,请谨慎操作”)。
    • 这一步会调高AI的“创造力”参数(温度设为0.8),让语言更自然、更贴近用户习惯。
  4. 开发支持工具

    • 研究者开发了一个网页工具,支持上传评论、自动生成总结、需求和解释,并能导出结果,方便工程师使用。
  5. 对比评估

    • 为了验证效果,研究者找了8名需求工程师和14名普通用户,让他们分别对比AI生成的需求和解释,与人工精心制作的版本哪个更好。
    • 评估标准包括清晰度、正确性、相关性、风格等6个方面至。

主要贡献:AI很能干,但还需“人类把关”

这项研究的核心价值在于:

  1. 提供了一套实用的自动化方案:帮助企业更高效地从用户反馈中提取改进方向,把“可解释性”这种抽象需求落到实处。
  2. 给出了AI与人工的“实力对比”
    • AI生成的需求在相关性和正确性上不如人工,但偶尔也能给出不错的答案(尤其是当用户需求很明确时)。
    • AI生成的解释在清晰度和语言风格上更受用户喜欢,但同样存在正确性问题(比如可能编造不存在的功能)。
  3. 强调了“人机协作”的重要性:AI可以快速生成初稿,提高效率,但最终必须经过人工验证,尤其是在正确性要求高的场景。
  4. 留下了宝贵的数据集:为其他研究者提供了可复用的资源,推动该领域的进一步发展。

思维导图:

在这里插入图片描述


详细总结:

1. 研究背景与意义
  • 可解释性的重要性:随着软件系统(尤其是含AI组件)的复杂化,可解释性成为关键非功能需求,可增强透明度、建立用户信任并确保合规。
  • 现有挑战:用户反馈中的解释需求多为非正式、主观表达,难以转化为结构化需求;现有方法仅能识别相关问题,缺乏系统推导需求和生成解释的方案。
2. 相关工作
  • 可解释性需求研究:已有研究识别了用户评论中的解释需求(如交互、行为、隐私等类别),但缺乏从需求到解释的系统转化。
  • 大语言模型(LLMs)在需求工程中的应用:LLMs可用于理解(如分类需求)和生成(如生成测试用例)任务,本研究采用模板提示词,注重可行性。
3. 自动化生成方法
  • A. 可解释性需求推导
    • 预处理:用ChatGPT总结用户评论(去除情感内容,德语输出),人工验证58条总结的准确性。
    • 生成需求:基于总结,用提示词生成结构化需求(格式:“The system must explain…”),温度设为0.3以保证一致性。
  • B. 解释生成
    • 基于生成的需求,用ChatGPT生成UI中的解释文本,温度设为0.8以增强自然性和创造性。
  • C. 工具支持:开发Web工具(前端Vue.js,后端Python/Flask),支持上传评论、分步生成(总结→需求→解释)及结果导出。
4. 研究设计
  • 数据集:从Spotify用户评论中随机选取58条(涵盖各类解释需求),由4名需求工程师手工生成需求和解释,作为基准。
  • 参与者
    • 需求工程师:8名(评估需求),均未参与数据集创建。
    • 终端用户:14名(评估解释),高频使用音乐应用。
  • 评估方式
    • 比较AI与人工生成的 artifacts(随机顺序展示,隐藏来源),基于6项标准评分:语气、风格、清晰度、正确性、相关性、详细程度。
    • 计算Fleiss’ Kappa以衡量评分一致性。
5. 研究结果
  • A. 可解释性需求评估(RQ1)
    • 偏好:人工生成需求更受青睐(296次 vs AI的168次),主要因相关性和正确性更高(分别被提及252次和194次)。
    • 统计:Chi-Square检验显示偏好显著((p=2.81e-09)),Fleiss’ Kappa为0.49(中等一致性)。
  • B. 解释评估(RQ2)
    • 偏好:人工(447次)略多于AI(365次),但分歧大(31/58无多数);AI在清晰度和风格有优势,正确性仍存疑。
    • 统计:Chi-Square检验显示偏离随机((p=0.004)),Fleiss’ Kappa为0.16(轻微一致性)。
  • C. 工具评估
    • 效率:减少44.2%(Group A)-52.5%(Group B)的需求生成时间。
    • 接受度:8名工程师均愿再次使用,6人“完全同意”工具的支持作用。
6. 研究贡献
贡献类型具体内容
方法提出从用户评论自动推导可解释性需求并生成解释的自动化方法
数据集发布含58条用户评论的标注数据集(含人工与AI生成的需求和解释)
实证洞察揭示AI生成产物的优势(解释的清晰度、风格)与局限(需求的相关性、正确性)
7. 局限性与未来工作
  • 局限性:样本量小(58条评论、单一应用)、评估者背景有限、LLM输出的可复现性问题。
  • 未来方向:扩展数据集(多领域、多语言)、改进AI生成准确性(高级提示、领域微调)、多样化参与者与应用场景。

关键问题:

  1. 研究中AI生成的可解释性需求与人工生成的相比,主要差异是什么?
    答案:需求工程师更偏好人工生成的需求,主要因相关性(252次提及)和正确性(194次提及)更高;而AI生成的需求仅在解释需求明确且结构化时偶尔被青睐,且在风格和语气上影响较小。统计显示,人工需求的选择比例显著高于AI(296次 vs 168次,(p=2.81e-09))。

  2. 该研究开发的工具在效率和用户接受度方面表现如何?
    答案:工具显著提升效率,使需求生成时间减少44.2%(Group A)至52.5%(Group B);在信任度上,工程师对工具生成结果的信任度与人工相当(4人“非常自信”,4人“自信”);接受度高,8名工程师均“完全同意”会再次使用,6人“完全同意”工具对需求生成的支持作用。

  3. 该研究的核心贡献及对未来相关研究的价值是什么?
    答案:核心贡献包括:(1)提出从用户评论自动推导可解释性需求并生成解释的方法;(2)提供含58条用户评论的标注数据集(含人工与AI生成的需求和解释),作为基准;(3)揭示AI生成产物的优缺点(如AI解释的清晰度优势与正确性问题)。对未来研究的价值在于提供了可复现的方法、基准数据集,以及改进方向(如领域微调、高级提示技术)。

总结:AI是好帮手,但不是“全能神”

这篇论文通过一套完整的方法和实验,展示了AI在处理软件可解释性需求方面的潜力。它告诉我们:

  • 解决的核心问题:如何把零散、主观的用户解释需求,系统地转化为结构化的开发要求和可用的解释文本。
  • 主要成果:AI生成的内容在效率和风格上有优势,但在准确性和相关性上仍需人工把关。研究提供的自动化工具能显著减少工程师的工作量(平均减少44%-52%的时间),同时生成的数据集为后续研究打下了基础。

简单说,想要让软件更“善解人意”,AI是个得力的助手,但最终拍板还得靠人。

一段话总结:

本文介绍了一种工具支持的自动化方法,旨在从用户评论中自动生成可解释性需求和对应的软件解释,以解决将用户反馈中的解释需求转化为结构化需求和解释的挑战。研究通过与工业自动化制造商合作,创建了包含58条用户评论的数据集,每条评论均标注有人工和AI生成的可解释性需求及解释。评估显示,虽然AI生成的需求在相关性和正确性上不及人工创建的,但AI生成的解释常因清晰度和风格更受青睐,不过正确性仍是问题,凸显了人工验证的必要性。该研究的贡献包括提出自动化方法、提供基准数据集及实证洞察。


http://www.lryc.cn/news/586074.html

相关文章:

  • 利用scale实现分页按钮,鼠标经过按钮放大
  • 12.使用VGG网络进行Fashion-Mnist分类
  • 解决bash终端的路径名称乱码问题
  • java单例设计模式
  • pip国内镜像源一览
  • 高校/企业/医院食堂供应链平台开发详解:采购系统源码的核心价值
  • MySQL 中图标字符存储问题探究:使用外挂法,毕业论文——仙盟创梦IDE
  • Oxygen XML Editor 26.0编辑器
  • 车载诊断架构 --- 诊断功能开发流程
  • Operation Blackout 2025: Smoke Mirrors
  • 日志不再孤立!用 Jaeger + TraceId 实现链路级定位
  • 传感器WSNs TheDataLinkLayer——X-MAC
  • 前端开发中的输出问题
  • try-catch-finally可能输出的答案?
  • [BUUCTF 2018]Online Tool
  • MCP上的数据安全策略:IAM权限管理与数据加密实战
  • Vim的magic模式
  • QT跨平台应用程序开发框架(5)—— 常用按钮控件
  • RS232通信如何实现(硬件部分)
  • 请求服务端获取broker的机房归属信息异常
  • 端到端自动驾驶:挑战与前沿
  • Unity URP + XR 自定义 Skybox 在真机变黑问题全解析与解决方案(支持 Pico、Quest 等一体机)
  • 时序数据预处理
  • Javaweb总结一
  • AV1高层语法
  • 【Elasticsearch 】search_throttled
  • (LeetCode 面试经典 150 题 ) 209. 长度最小的子数组(双指针)
  • 【C语言】回调函数、转移表、qsort 使用与基于qsort改造冒泡排序
  • 汇编语言与操作系统交互
  • 27.【.NET8 实战--孢子记账--从单体到微服务--转向微服务】--单体转微服务--币种服务(一)