实现人工智能和机器学习解决方案的旅程需要解决许多在数字系统中经常出现的常见挑战：更新传统系统、消除批处理过程，并使用基于人工智能/机器学习的创新技术来改善客户体验，这在几年前还像科幻小说一样。
为了说明这种演变，让我们跟随一个假想的承包商，他被雇佣来帮助一个大型零售商实施人工智能/机器学习解决方案。这是一系列文章中的第一篇，将详细介绍AI/ML的旅程的重要方面。
问题
这是我在“基础设施”团队的第一天。在完成了人力资源活动后，我拿到了承包商的工作证，并走向了我的新工作空间。在与团队见面后，我被告知今天上午我们将与“推荐”团队开会。我的系统访问权限还没有完全生效，希望在开会期间IT部门能解决这个问题。
会议室里，只有我们几个人：我的经理和来自我的新团队的另外两名工程师，以及来自推荐团队的一名工程师。我们开始进行一些介绍，然后继续讨论上周的一个问题。显然，上周出现了某种一夜之间的批处理失败，并且他们仍然感受到了这种影响。
看起来目前的产品推荐是根据从客户订单中收集的数据驱动的。每个订单都有一种新的产品关联，这些关联被记录下来。当客户查看产品页面时，他们可以根据其他客户与当前产品一起购买的不同产品来获得推荐。
产品推荐通过云中的微服务层在bigboxco.com上向用户提供。微服务层使用基于Apache Cassandra的本地（云）数据中心部署来提供结果。
然而，结果的收集和提供完全是另外一个故事。基本上，产品之间的关联结果（一起购买的产品）是在MapReduce作业期间编译的。这就是上周失败的批处理过程。虽然这个批处理过程从来都不快，但随着时间的推移，它变得越来越慢且不稳定。事实上，有时候，这个过程需要运行两天甚至三天。
提高体验
会议结束后，我检查了一下电脑，看起来我终于可以登录了。当我四处看的时候，我们的首席工程师（PE）走过来并向我介绍了自己。我告诉他关于与推荐团队的会议，并且他向我介绍了更多关于推荐服务背后历史的信息。
听起来那个批处理过程已经存在了大约十年。设计它的工程师已经离开了，组织中没有多少人真正了解它，也没有人愿意碰它。
我开始解释，另一个问题是驱动每个推荐的数据集几乎总是几天前的。虽然这在整个事情的长远计划中可能并不重要，但如果推荐数据可以更及时更新，它将有助于市场部门进行短期促销。
他点头表示同意，并说他绝对乐意听取改善系统的建议。
也许是一个图问题？
一开始，这对我来说听起来像是一个图问题。我们有登录网站并购买产品的客户。在此之前，当他们查看产品或将其添加到购物车时，我们可以展示“购买X的顾客也购买了Y”的推荐。该网站目前已经实现了这一点，推荐服务正是这样做的：它返回了经常一起购买的其他四个产品。
但我们必须有一种方式来“排名”这些产品，因为将一个产品与我们2亿客户之一同时购买的其他产品的映射会变得非常庞大。因此，我们可以根据它们在订单中出现的次数对它们进行排名。
显示顾客和他们购买产品之间关系的产品推荐图。
在对这个进行建模并在我们的图数据库上运行具有真实数据规模的数据之后，我很快意识到这是行不通的。从一个产品到附近顾客再到他们的产品，以及计算出现最多的产品，需要大约10秒的时间。实质上，我们将两天的批处理问题推到了每次查找中，将遍历延迟准确地放置在我们不希望的地方：在客户面前。
但也许那个图形模型与我们在这里需要做的事情并没有太大的差异。事实上，上面描述的方法是一种被称为“协同过滤”的机器学习（ML）技术。本质上，协同过滤是一种基于用户与其他用户的活动相似性来检查某些数据对象的方法，并且它使我们能够基于该数据进行预测。在我们的情况下，我们将隐式收集来自我们的客户群体的购物车/订单数据，并将其用于提高在线销售的产品推荐。
实施
首先，让我们来看看数据收集。在购物“下订单”功能中添加额外的服务调用并不是一件大事。实际上，它已经存在了；只是数据被存储在数据库中并稍后处理。千万别搞错：我们仍然希望包括批处理。但我们也希望实时处理购物车数据，以便能够将其立即反馈到在线数据集中并立即使用。
我们将首先引入像Apache Pulsar这样的事件流解决方案。这样，所有新的购物车活动都会被放置在一个Pulsar主题上，然后被消费并发送到底层批处理数据库和帮助训练我们的实时ML模型。
至于后者，我们的Pulsar消费者将写入一个Cassandra表（如图2所示），该表被设计成仅仅保存订单中每个产品的条目。然后，该产品对应于该订单以及其他订单中的所有其他产品都有一行：
通过在现有的批量推荐系统中增加Apache Pulsar和Apache Cassandra。
然后，我们可以像这样查询此表以获取特定产品（在此示例中为“DSH915”）：
然后，我们可以将前四个结果放入产品推荐表中，以便推荐服务可以通过`product_id`查询：
通过这种方式，新的推荐数据不断保持最新状态。此外，上述所有基础设施资产都位于本地数据中心。因此，从订单中提取产品关系，通过Pulsar主题发送并将其处理为存储在Cassandra中的推荐所需的时间不到一秒钟。借助这种简单的数据模型，Cassandra能够在单位毫秒内提供所请求的推荐。
结论和下一步
我们将确保检查我们的数据如何长期写入Cassandra表。这样我们就能提前解决与行增长无限和就地更新等问题相关的潜在问题。
还可能需要添加一些额外的启发式过滤器，例如“不推荐”列表。这是因为有些产品我们的客户只会购买一次或很少购买，推荐它们只会占用其他他们更有可能凭冲动购买的产品的空间。例如，推荐购买我们家电部门的洗衣机之类的东西不太可能带来“冲动购买”。
另一个未来的改进是实施像Kaskada这样的实时AI/ML平台，用于处理产品关系流和直接提供推荐数据给服务。
幸运的是，我们找到了一种方法，通过使用Pulsar将购物车添加事件实时处理来增强现有的、缓慢的批处理过程。一旦我们对这个系统的长期性能有所了解，我们应该考虑关闭传统的批处理过程。PE认可我们在新解决方案方面取得了良好的进展，更好的是，我们已经开始为消除一些技术债务奠定了基础。最终，每个人都对此感到满意。
在即将发布的一篇文章中，我们将探讨如何通过向量搜索来改进产品促销。