增量开发中带有溯因校正的互补推荐

《Pattern Recognition》：Complementary recommendation with abductive correction in incremental development

　　

•统一的路径式框架建模强和弱 API 互补性。
•新颖的算子和网络捕捉高阶互补关系。
•溯因纠正通过有效的控制策略优化推荐。

**引言**
云应用程序编程接口（APIs）是服务提供商通过标准协议公开的抽象接口，使开发者能够以编程方式访问低级资源以及高级服务（例如数据库、机器学习、认知服务）[1]。通过利用云 API，应用程序可以实现快速集成、弹性可扩展性和跨平台互操作性，从而提高开发效率和服务可重用性。随着云计算的快速发展，可用的云 API 数量呈爆炸式增长 [2]。虽然这种扩展为开发者提供了前所未有的选择范围，促进了服务多样性和创新，但也造成了严重的 API 过载问题 [3]，开发者难以高效地发现并选择适合的云 API 服务。因此，有效的云 API 推荐已成为提高服务利用率和支持高效增量开发的关键赋能因素。
为了缓解 API 过载，研究者从三个主要视角提出了推荐方法：基于偏好、基于内容和感知服务质量（QoS）的方法。基于偏好的方法依赖用户调用日志或评分，通过各种技术预测用户偏好并推荐 API。Zhang 等人 [4] 采用奇异值分解，Sun 等人 [5] 利用用户 -API 交互图进行图对比学习，Wang 等人 [6] 利用异构网络中的功能融合和结构融合来建模用户行为偏好。为了解决数据稀疏问题，基于内容的方法计算 API 描述与用户需求之间的语义相似度，近期工作利用 API 相关性图 [7]、图神经网络 [8] 和大型语言模型进行语义对齐 [9]。感知 QoS 的方法通过纳入响应时间、可用性和吞吐量等非功能属性来解决 API 功能同质性问题，构建针对用户操作上下文的预测模型 [10]。尽管取得了进展，这些方法本质上遵循“用户到 API"范式，专注于将单个 API 与用户的显式需求相匹配。因此，它们无法捕捉开发者对互补云 API 推荐的现实需求。
互补 API 推荐是一种"API 到 API"范式，旨在建议与给定查询 API 互补的 API，以实现联合调用以满足共同开发目标。早期研究依赖启发式规则（例如 Popular-K [11]）和关联规则挖掘（例如 Apriori [12]）来发现互补 API。较新的研究将该问题建模为成对互补性预测任务，估计查询 API q 和候选 API c 之间互补的可能性，通常使用深度模型如 FM [13]、AFM [14] 和 xDeepFM [15] 来解决互补性预测任务。虽然有效，但这些方法将问题简化为单查询推荐 f(q)=c，忽略了实际增量开发场景所需的高阶互补性，在该场景中，开发者寻求针对一组云 API 的互补推荐 f(Q)=c。为了弥补这一差距，诸如 MC-RGN [16] 和 BSARec [17] 之类的序列方法通过捕捉 API 调用序列中的关系引入了高阶建模。尽管现有方法在互补规则挖掘、成对学习和高阶建模方面有所推进，但仍面临两个关键局限性：
（1）缺乏弱互补性建模。受经济学中“联合购买”理论 [18] 的启发，大多数方法从共同调用（CI）行为推断互补性，这捕捉了强互补关系。然而，它们忽略了功能共现，即提供相关功能（例如支付和认证）的 API 经常被组合使用。如图 1 所示，基于 CI 的方法识别了 API a1 和 a2 之间的强互补性，但未能捕捉 a1 和 a3 之间的弱互补性。事实上，由于 a1（具有功能 f1）和 a2（具有功能 f2）在 APP1 中被共同调用，我们可以推广得出提供 f1 和 f2 的 API 可能经常联合使用。由于 a3 也提供功能 f2，a1 和 a3 在功能共现层面表现出弱互补关系。此外，具有相同功能的 API 可能是可替代的 [19]，从而引入替代噪声。因此，在过滤替代干扰的同时有效建模弱互补性至关重要。
（2）缺乏溯因纠正。大多数现有研究采用单步范式，直接从学到的互补性生成推荐 [20]。这种范式忽略了溯因推理，这是一种从观察到的事实推断可能原因的过程。在互补推荐中，如果候选 API 被推荐（事实），查询集应代表其潜在原因。如图 2 所示，当前方法仅执行步骤①（预测），忽略了步骤②（溯因推理）和步骤③（结果纠正）。通过引入溯因推理，推断原因与实际原因之间的差异可以反向传播以优化结果，从而提高准确性和可靠性。因此，如何开发基于溯因推理的纠正机制以优化推荐构成了提升互补推荐性能的关键挑战。
为了解决这些挑战，我们提出了一种新颖的带溯因纠正的互补推荐方法（CRAC）。CRAC 将强互补性建模扩展为统一的路径式框架，通过功能共现纳入弱互补性。具体而言，Sub-CI 路径捕捉弱关系，同时确保与传统基于 CI 的方法兼容。技术上，CRAC 包含两个阶段：互补推荐和溯因纠正。在第一阶段，Beta 嵌入概率性地编码查询 API，实现基于路径的互补投影和高阶推理。为了建模弱互补性并减轻替代噪声，我们设计了投影算子和否定算子，这有助于感知任何查询 API 的弱互补性并抑制噪声。在此基础上，一个两级注意力网络随后融合多个互补 API 表示（通过高阶注意力），并强制执行互补但非替代约束（通过互补去噪注意力）。最后，通过排名候选 API 与学到的互补基向量之间的 KL 散度来生成初始推荐。在第二阶段，我们应用一种过度纠正控制策略，利用初始推荐结果构建可学习的溯因任务。溯因损失函数最小化推断原因与实际原因之间的差异，通过溯因损失信号的反向传播优化推荐。
本文的主要贡献总结如下：
（1）我们首次提出了一种统一的路径式框架，能够表征强和弱互补性，从而扩展了互补性建模的表达力和范围。
（2）我们引入了互补投影算子和否定算子，以及高阶和互补去噪注意力网络，以捕捉互补关系并强制执行互补但非替代约束。
（3）我们设计了一种溯因纠正机制，模拟人类的溯因推理，通过溯因任务和相应的损失优化推荐，并纳入了过度纠正控制策略以确保有效纠正。
（4）在两个公开的现实世界云 API 数据集上的实验证明，CRAC 优于最先进基线。案例研究进一步验证和解释了溯因纠正在提升推荐性能中的关键作用。
本文其余部分组织如下。第 2 节回顾云 API 推荐的相关工作。第 3 节定义互补关系、互补推荐和溯因推理。第 4 节介绍 CRAC 框架和实现细节。第 5 节描述实验设计和结果分析。最后，第 6 节总结全文。

**章节片段**
**用户到 API 推荐**
用户到 API 推荐旨在根据用户历史行为、显式需求或上下文信息识别合适的 API。它可以分为三类：基于偏好、基于内容和感知 QoS 的方法。
（1）基于偏好的云 API 推荐。这些方法利用历史用户 -API 交互来学习用户潜在偏好模式以供推荐。例如，Zhang 等人 [4] 使用联合矩阵分解结合 Mashup-API 相似度以...

**互补关系**
我们形式化了云 API 之间的三种关系类型：
**替代关系**。如果两个云 API a 和 b 提供相同或高度相似的功能，即...，如图 3(a) 所示，则它们是替代关系。
**强互补（SC）**。如果两个云 API a 和 b 在同一应用程序内被共同调用，即...，如图 3(b) 所示，则它们是强互补关系。
**弱互补（WC）**。如果两个云 API a 和 c 是弱互补关系，则...

**概述**
所提出的 CRAC 概述分为两个阶段，如图 4 所示：
**阶段 1 互补推荐**。互补推荐器估计候选云 API 与查询 API 集之间的互补概率。候选项根据概率排名以生成初始推荐列表。
**阶段 2 溯因纠正**。为减轻初始推荐中的误差，将过度纠正控制策略应用于初始推荐结果

**实验**
为了验证 CRAC 的有效性，我们在两个现实世界云 API 生态系统数据集上进行实验，以回答以下五个研究问题（RQs）：
RQ1：所提出的 CRAC 是否优于主流基线方法？
RQ2：互补投影如何影响 CRAC 的性能？
RQ3：过度纠正控制对溯因纠正有何影响？
RQ4：嵌入维度如何影响 CRAC 的性能？
RQ5：CRAC 在不同...下表现如何？

**结论与未来工作**
本文提出了 CRAC，一种用于增量开发中互补云 API 推荐的二阶段框架。所提出的方法在统一的路径式表述中联合建模了来自共同调用行为的强互补性和来自功能共现的弱互补性，并通过溯因纠正机制进一步优化初始排名。通过这种方式，CRAC 通过整合互补预测与...

**CRediT 作者贡献声明**
Zhen Chen：写作 – 审阅与编辑，写作 – 初稿撰写，验证，监督，方法论，资金获取，形式分析，概念化。Haonan Liao：写作 – 初稿撰写，可视化，验证，方法论，资金获取。Jinyu Chen：写作 – 审阅与编辑，验证，调查，数据整理。Dianlong You：写作 – 审阅与编辑，软件，资源。

**利益冲突声明**
作者声明他们没有已知的竞争财务利益或个人关系可能影响了本文报告的工作。

Zhen Chen|Haonan Liao|Jinyu Chen|Dianlong You