[Paper] AI驱动感知系统开发中的需求债务：工业 RE4AI 视角

Source: arXiv - 2604.27825v1

概述

本文研究了 Requirements Debt (ReD)——当汽车中的 AI 驱动感知系统的需求未能保持最新、未被记录或未经过验证时所累积的隐藏成本。通过将技术债务理论与 AI 需求工程（RE4AI）相结合，作者揭示了快速演变的功能性和非功能性需求如何侵蚀现代汽车感知堆栈的安全性、可审计性以及认证准备度。

关键贡献

• AI感知需求债务的概念化 – 将 ReD 定义为针对 AI 驱动汽车系统的技术债务的独特子类型。
• 经验基础 – 在 13 家汽车公司和 3 家研究机构进行的 16 次半结构化访谈，使用主题分析进行分析。
• ReD 机制的识别 – 绘制了不断演进的功能需求（例如算法更新、传感器融合变更）和非功能需求（例如安全性、网络安全、透明性）如何产生具体的债务模式，如语义漂移、验证积压、保证滞后和合规错位。
• 传播模型 – 展示了 ReD 如何在数据、模型和系统工件之间传播，影响审计轨迹、可靠性和认证准备度。
• 实用检查清单 – 提供了一套可观察的“症状”（例如测试套件缺口扩大、模型版本变更未记录），供从业者用于检测 ReD 的早期迹象。

方法论

1. 访谈设计 – 对来自 OEM、一级供应商和学术实验室的高级工程师、安全分析师以及 AI 研究人员进行 16 场半结构化访谈。
2. 抽样 – 采用目的抽样，确保覆盖不同的车辆平台、感知模态（摄像头、激光雷达、雷达）以及 AI 集成成熟度。
3. 主题分析 – 对访谈记录进行归纳编码，以发现重复出现的模式，然后将其归类为更高层次的主题，代表功能性和非功能性需求的演进。
4. 三角验证 – 将研究结果与参与者提供的内部文档（例如变更请求日志、安全案例更新）进行交叉核对，以验证债务机制。

结果与发现

研究表明这些机制是 相互依赖 的：功能验证的滞后常会放大非功能保证的缺口，反之亦然。随着时间的推移，累积的债务会削弱系统的可审计性以及安全认证的准备程度（例如 ISO 26262，UNECE R155）。

实际意义

• Continuous Requirements Traceability – 采用能够自动将需求 ID 链接到数据集、模型版本和测试用例的工具。这可以降低语义漂移并使审计轨迹明确。
• Debt‑aware Sprint Planning – 将“需求债务票据”视为技术债务故事；在每个冲刺中分配专门的容量来关闭验证积压并更新安全案例。
• Automated Compliance Checks – 将标准检查脚本（例如 ISO 26262 安全目标检查）集成到 CI 流水线中，使任何违反非功能需求的更改立即触发警报。
• Model‑Centric Documentation – 在受版本控制的注册表中存储模型来源信息（训练数据来源、超参数、评估指标），以便在认证审计期间进行查询。
• Risk‑Based Testing Prioritization – 使用已识别的 ReD 症状来优先生成针对高影响感知场景（例如夜间行人检测）的测试用例。
• Organizational Alignment – 鼓励跨团队的“需求债务评审”，让安全工程师、数据科学家和系统架构师共同评估需求‑制品可追溯性图的健康状况。

限制与未来工作

• 样本偏差 – 访谈对象虽然多样，但偏向大型欧洲原始设备制造商（OEM）和研究机构；初创公司或非欧洲环境可能表现出不同的债务模式。
• 自报告数据 – 研究结果依赖于参与者的记忆和披露内部挑战的意愿，这可能低估最严重的债务案例。
• 工具验证 – 论文提出了概念性的债务跟踪清单，但未在工业环境中评估具体工具实现。
• 未来方向 – 作者建议构建自动化可追溯性流水线，量化债务对认证时间线的影响，并将研究扩展到其他 AI 领域（例如预测性维护、驾驶员监控）。

开发者的底线：随着 AI 成为汽车感知的核心组件，您曾经一次性编写并置之不理的“需求”现在表现得像活的代码。当这些需求演变时产生的债务被忽视，会导致认证停滞、维护成本上升，并危及安全。将持续可追溯性、债务感知规划和自动化合规嵌入开发工作流已不再是可选项——它是交付可信、上路 AI 系统的前提。

作者

• Hina Saeeda
• Soniya Abraham

论文信息

• arXiv ID: 2604.27825v1
• 分类: cs.SE
• 发布日期: 2026年4月30日
• PDF: 下载 PDF