Grab 是菲律宾最受欢迎的叫车应用程式，但调查发现它用以计算服务价格的演算法并不透明，对用户构成不公。
当用户预订乘车时，按行程距离和时间所需支付的车资通常会加上一个加成计费（surge charge），该公司表示，这 “反映了实时市场状况”，令它能平衡司机和用户之间的供求关係。Grab 表示，为了计算最终收费，演算法会考虑交通、位置和可用司机数量等因素，但没有明确说明何时收取加成计费以及它具体是如何计算的。
菲律宾调查报道中心（PCIJ）与普立兹中心的人工智能问责网络所协作进行的调查显示，无论预约叫车时间和地点如何，这笔额外的加成计费始终存在，而且支付收费更昂贵的车种，也不一定会缩短等候时间。作为调查团队，我们是在收集和分析了数千个数据点后得出这个结论的。
取得数据的困难
报道专利演算法的主要问题之一是透明度的缺乏。Grab 的定价演算法是所谓 "黑箱" 的典型例子：系统取得输入内容（在这里即用户选择的上车和下车地点），然后生成一个输出内容，即用户需要缴付的价格。
在这输入和输出之间存在一系列计算方法，其中涉及用户无法获得的很多变数。
由于我们无法看到黑箱内发生的情况，因此我们系统地分析了众多输入和输出来报道这个故事。我们选择了一组输入（成对的上车和下车地点）并随着时间的推移保持它们不变，以便分析输出的结果为何。
在一周内，我们收集了马尼拉大都会区 10 条路线全日的 Grab 价格数据。我们从两个不同的来源收集这些资料：从应用程式本身手动收集、模拟预约叫车，并透过名为 Farefeed 的公开 Grab API 自动收集数据，后者的 API（即应用程式介面）可在 Grab 的线上车资检查工具中使用。API 可让你绕过用户介面，更直接地跟应用程序的程式码和数据进行互动，而且通常容许你有系统地从程序中提取资料。
我们总共从此应用程式中收集了 1,328 个数据点，再从 API 收集了 6,720 个数据点。使用两种不同的来源使我们能够补足两种方法各自的局限，并能使用不同的变数来更彻底地分析数据。
如欲深入了解我们收集得到的数据，请点按此处。
两种数据採集方式
我们的团队由 20 名研究人员组成，共同尝试在 2024 年 2 月 14 日至 20 日期间，从早上6 点到午夜每小时预约 10 次横跨马尼拉大都会路线的叫车服务。研究人员每次都会以萤幕截图的形式纪录 Grab 应用程序的预订页面，其中包含有关四人座汽车的车资、预计到达目的地时间以及建议路线的资讯。
每次在 Grab 应用程序上尝试预约叫车后，研究人员也会在谷歌地图上截取谷歌自动建议的路线的萤幕截图。这目标是记录谷歌建议的时间和距离，因为 Grab 并不显示距离。
如果谷歌地图的预设路线与应用程序生成的路线的不匹配，研究人员会在谷歌地图上模彷 Grab 的路线并撷取第二张萤幕截图。这是估计实际行程距离所必需的资料，是用以分析收费细项的关键数据。
研究人员事前对这过程展开了一次演习，以便识别这方法的可能缺陷，并在进行实际数据採集之前加以改进。
在手动收集的同一时期，我们创建了一个 Python 脚本，用于从 Grab 的车资检查 API 中每 15 分钟採集一次相同 10 条路线的数据，以获得更精细的数据。
我们如何分析数据
在将两个来源的数据拼凑起来并检查其一致性后，我们使用政府批核的车资结构对 Grab 车资进行了细分。
在细分所有车资后，我们发现加成计费始终存在。在两所本地大学统计学家的帮助下，我们进行了统计分析，科学地判断当加成计费上调时，叫车的等候时间是否会减少。
我们的分析结果并未显示加成计费和等候时间之间有显着相关性；这说明 Grab 有关较高的加成计费会吸引更多车队从而减少等候时间的假设跟实际结果不符。
关于如何报道演算法的经验启示
- 儘管我们无法进入演算法的黑箱，但如果我们研究其输入和输出，我们可以获得非常相关的数据；其中的关键是设计一种系统性的数据採集方法。
- 在设计人手数据收集实验时，必须在进行实际採集之前展开测试；事前会议和预演令我们能够建立清晰一致的基准来处理数据、找出弱点，并加以改进。
- 你不需要高级编码技能才能审核演算法的输出：有良好的人手採集数据就足够了。
- 在审核演算法时，请考虑有甚麽其他数据来源能补足缺失的部份。在我们的例子中，谷歌地图容许我们断定行程的估计距离，而 API 和 Grab 应用程式均未有提供此项资料。
- 如果你有大量数据和变数需要分析，而且它们之间的关係很複杂，那麽统计学家的帮助将有助于识别相关模式，同时避免做出仓促的假设；它也能巩固你的结论。
- 在研究技术型的话题（例如计算车资的演算法）时，关键是要考虑到人们（用户）的观点。用户和司机的分享，令我们能呈现人们如何受到这些系统的影响，以及问题的真实规模。
图片来源：Marfil Graganza Aquino via Pexels