良好的出租车服务应该安全、可靠、快捷。 用户不会详细说明：对他来说重要的是，他点击“订购”按钮并尽快收到一辆汽车，将他从 A 点带到 B 点。如果附近没有汽车，该服务应该立即告知客户，以免客户产生错误的期望。 但如果“禁止汽车”标志出现得太频繁，那么人们就会停止使用这项服务并转向竞争对手，这是合乎逻辑的。
在这篇文章中，我想谈谈如何使用机器学习解决在低密度区域（换句话说，乍一看没有汽车的地方）搜索汽车的问题。 结果如何。
史前
要叫出租车，用户只需执行几个简单的步骤，但服务内部会发生什么？
| 用户 | 阶段 | 后端 Yandex.Taxi |
|---|---|---|
| 选择起点 | 销 | 我们正在推出简化的候选人搜索 - pin 搜索。 根据找到的驱动程序，预测到达时间 - 引脚中的 ETA。 计算给定点的增加系数。 |
| 选择目的地、票价、要求 | 提供 | 我们建立一条路线并计算所有关税的价格，同时考虑到递增系数。 |
| 按“叫出租车”按钮 | Заказ | 我们对这辆车展开全面搜索。 我们选择最合适的司机并向他提供订单。 |
Про , и 我们已经写了。 这是一个关于寻找司机的故事。 创建订单后，搜索会发生两次：在 Pin 图上和在订单上。 寻找订单分两个阶段进行：招募候选人和排名。 首先，找到沿着路线图最近的可用候选驾驶员。 然后应用奖金和过滤。 剩余的候选人将被排名，获胜者将收到订单报价。 如果他同意，他就会被分配到订单并前往交货点。 如果他拒绝，那么这个提议就会进入下一个。 如果没有更多的候选人，则重新开始搜索。 这持续不超过三分钟，之后订单将被取消并销毁。
在 Pin 图上搜索与在订单上搜索类似，只是不会创建订单并且搜索本身仅执行一次。 还使用了候选数量和搜索半径的简化设置。 这种简化是必要的，因为引脚数比阶数多一个数量级，并且搜索是一项相当困难的操作。 我们故事的关键点是：如果在初步搜索过程中没有在 Pin 图上找到合适的候选人，那么我们不允许您下订单。 至少过去是这样。
这是用户在应用程序中看到的内容：
搜索没有汽车的汽车
有一天，我们提出了一个假设：也许在某些情况下订单仍然可以完成，即使pin上没有汽车。 毕竟，在 pin 和订单之间会经过一段时间，并且对订单的搜索更加完整，有时会重复几次：在此期间，可能会出现可用的驱动程序。 我们还知道相反的情况：如果在引脚上找到了驱动程序，那么在订购时就不会发现它们。 有时他们会消失或者每个人都拒绝订单。
为了验证这一假设，我们发起了一项实验：在测试用户组的 Pin 图搜索过程中，我们停止检查汽车是否存在，也就是说，他们有机会下“没有汽车的订单”。 结果却出乎意料： 如果汽车不在 pin 上，那么在 29% 的情况下，它是稍后在订单上搜索时找到的！ 此外，无车订单在取消率、评分和其他质量指标方面与常规订单没有显着差异。 无车预订占所有预订的 5%，但仅占所有成功旅行的 1% 多一点。
为了了解这些订单的执行者来自哪里，让我们看看他们在 Pin 图上搜索时的状态：
- 可用的： 有空，但由于某种原因没有被列入候选人，例如，他距离太远；
- 订购： 很忙，但设法解放自己或有空 ;
- 忙碌的： 接受订单的能力被禁用，但随后司机又回到了队列；
- 无法使用： 司机并不在线，但他出现了。
让我们增加可靠性
额外的订单固然很好，但 29% 的成功搜索意味着 71% 的时间用户等待了很长时间而最终无处可去。 虽然从系统效率的角度来看这并不是一件坏事，但它实际上给用户带来了虚假的希望并浪费了时间，之后他们会感到不安并（可能）停止使用该服务。 为了解决这个问题，我们学会了预测找到订购的汽车的可能性。
该计划如下：
- 用户放置图钉。
- 对引脚进行搜索。
- 如果没有汽车，我们预测：也许它们会出现。
- 并且根据概率，我们允许或不允许您下订单，但我们警告您，此时该区域的汽车密度较低。
在应用程序中它看起来像这样：
使用该模型可以让您更准确地创建新订单，而不是徒劳地让人们放心。 即使用精确召回模型来调节无机器的可靠性和订单数的比率。 服务的可靠性会影响继续使用该产品的愿望，也就是说，最终一切都取决于出行次数。
关于精确召回的一些知识机器学习的基本任务之一是分类任务：将一个对象分配给两个类别之一。 在这种情况下，机器学习算法的结果通常变成对某一类中的成员资格的数值评估，例如概率评估。 然而，所执行的操作通常是二元的：如果汽车可用，那么我们会让您订购它，如果没有，那么我们不会。 具体来说，我们将产生数值估计的算法称为模型，将分类器称为将其分配到两个类别之一（1 或 –1）的规则。 要根据模型评估制作分类器，需要选择评估阈值。 具体如何在很大程度上取决于任务。
假设我们正在对一些罕见且危险的疾病进行测试（分类器）。 根据检查结果，我们要么送病人做更详细的检查，要么说：“好，回家吧。” 对我们来说，将病人送回家比对健康人进行不必要的检查要糟糕得多。 也就是说，我们希望该测试对尽可能多的真正患病的人有效。 这个值称为召回率 =。 理想的分类器具有 100% 的召回率。 一种简陋的情况就是把所有人都送去检查，那么召回率也会是100%。
反之亦然。 例如，我们正在为学生做一个测试系统，它有一个作弊检测器。 如果突然检查对于某些作弊情况不起作用，那么这会令人不愉快，但并不重要。 另一方面，不公平地指责学生没有做过的事情是极其糟糕的。 也就是说，对我们来说重要的是，在分类器的肯定答案中，有尽可能多的正确答案，也许会损害它们的数量。 这意味着您需要最大化精度= 。 如果触发发生在所有对象上，则精度将等于样本中定义的类的频率。
如果算法产生一个数值概率值，那么通过选择不同的阈值，您可以获得不同的精确率-召回率值。
在我们的问题中，情况如下。 召回率是我们可以提供的订单数量，精度是这些订单的可靠性。 这就是我们模型的精确率-召回率曲线的样子：
有两种极端情况：不允许任何人点餐和允许所有人点餐。 如果你不允许任何人，那么召回率将为0：我们不创建订单，但它们都不会失败。 如果我们允许所有人，那么召回率将是 100%（我们将收到所有可能的订单），精确率将是 29%，即 71% 的订单将是不好的。
我们使用起点的各种参数作为标志：
- 时间/地点。
- 系统状态（附近所有费率和引脚的占用机器数量）。
- 搜索参数（半径、候选者数量、限制）。
有关标志的更多信息
从概念上讲，我们要区分两种情况：
- “森林深处”——此时这里没有汽车。
- “不幸”——有车，但搜索时没有合适的车。
“不幸”的一个例子是周五晚上中心的需求量很大。 订单很多，愿意的人很多，但没有足够的司机满足每个人的需求。 结果可能是这样的：引脚中没有合适的驱动程序。 但实际上几秒钟之内他们就出现了，因为此时这个地方有很多司机，他们的状态在不断变化。
因此，A点附近的各种系统指标结果证明是很好的特征：
- 汽车总数。
- 订单汽车数量。
- 处于“忙碌”状态无法订购的汽车数量。
- 用户数量。
毕竟，汽车越多，其中一辆可用的可能性就越大。
事实上，对我们来说重要的不仅是汽车的定位，还有成功的出行。 因此，可以预测旅行成功的概率。 但我们决定不这样做，因为这个值很大程度上取决于用户和驱动程序。
模型训练算法为 。 从实验中获得的数据用于训练。 实施后，必须收集训练数据，有时允许少数用户根据模型的决定进行订购。
结果
实验结果符合预期：使用该模型可以显着增加因无车订单而成功出行的次数，但不会影响可靠性。
目前，该机制已在所有城市和国家启动，在其帮助下，约1%的成功出行发生了。 而且，在一些汽车密度较低的城市，此类出行的比例达到15%。
有关出租车技术的其他帖子
来源： habr.com