这个想法其实在 2005 年时就有了，不过由于各种各样的原因，一直没有机会实践。我不知道有没有人已经在做类似的事情了，不过至少在我熟悉的几个电子商务网站还没有人这样做。先把它整理一下，写在下面，将来或许会回来继续思考、推进。

一、问题的提出

我们在访问各大网上购物站点时，经常会看到各种商品推荐页面以及列表页面，比如下面这个截图：

这类推荐或者列表（下面统一叫“推荐列表”）经常出现在首页（包括频道首页、分类首页）、推广页面以及搜索结果页面，是一种重要的导航形式，很多情况下，访客需要经过这些导航的引导才能到达最终商品的详情页面，并决定是否购买。我们认为，这些推荐列表做得好不好（这儿不考虑设计等因素，只考虑推荐的内容好不好），对最终的订单情况会有一定的影响，或者说，推荐列表中推荐这几种商品并且按这种顺序排列，与推荐另外几种商品并且按另外的顺序排列，可能会带来不同的订单量。这也是下面的讨论的前提条件，如果认为推荐列表里无论放什么、怎么放都不会影响到订单情况，那下面的讨论就没有意义了。当前，这一个前提是否合理或许还需要研究，不过我们根据经验，姑且认为它是合理的。

那么，怎么样才能保证这些推荐列表是“好”的呢？可能有成百上千种备选的商品，在这些地方推荐哪几种比较好？决定了推荐哪几种，又如何排列这些商品比较好？

要回答这个问题，我们要先解决两个子问题：

1、“好”与“不好”的标准是什么？
2、如何度量“好”的程度？

对于第一个问题，互联网公司已经发展了一系列方法，比如看页面的点击量（PV）是否增加等。但简单的看点击量可能很多情况下并不适用，比如，用户可能会因为对网站上的内容有兴趣而点击了很多次，也有可能由于网站上的内容很杂乱而不得不点了很多次才找到自己感兴趣的内容，这两种情况下点击量都上升了，但后者通常情况下是不好的。因此，仅仅简单地看点击量可能是有问题的，因为点击量与最终商业目标之间并不一定一致。

幸运的是我们考查的是网上购物网站，大多数情况下，这类网站的商业目标都很简单直接——增加订单，同时，由于整个购物流程都是在网站系统上完成的，因此订单是否完成是很容易知道的，订单的增加与减少也非常容易量化，因此，在网上购物网站，上面的两个问题在技术上都很容易解决。在度量上的唯一问题可能是，以订单数量来度量还是以订单金额来度量，我想这两种方式都可以，看具体的情况决定采用哪一种即可，当然，一般情况下我觉得用订单金额来度量更准确一些，下面我们以订单金额为例进行讨论。

我们先来看一下一个典型的购物流程：

用户从起始页（可能是首页，也可能是从其它网站链过来的第一个页面）开始，到达导航页，找到自己有兴趣的商品，加入购物车，提交订单，完成购买。其中导航页以及订单完成页是最关键的流程，用户从导航页上的推荐列表到达商品详情页面，只有最后完成的订单才能计入成功的订单额。

需要说明的是，真实的购物流程有很多种，比如有些用户直接从别的网站上的链接进入了商品最终页并直接下单购买，完全没有经过导航页面的推荐列表，也有些用户虽然访问了推荐列表，但最后购买的商品并不是推荐列表上的，推荐列表完全没有影响到他们。上面的流程只是其中一种，特点是由推荐列表连到了商品详情并产生了订单，在本文中，我们只考察这一种流程。

为了区分上面的流程与其它流程，我们还需要做一些工作，比如，当用户访问导航页，并且点击了导航页上的推荐列表到达商品详情页面时，需要给用户加一个标识（比如在 cookie 中加一个特征字符串），当用户到达最后的订单完成页面时，做以下操作：

步骤一、检查用户是否有访问过导航页推荐列表的标识？如果有，进行下一步；
步骤二、用户的订单商品中，是否有从导航页推荐列表中进入的？如果有，进行下一步；
步骤三、将该商品的订单额计入对应推荐列表的订单额中。

这样，我们就能去除别的流程的干扰，比较精确地统计出由导航页的推荐列表带来的收益（订单额）是多少了。也就是说，在多种方案下，我们能准确地知道哪种推荐列表更好，比别的方案好多少（订单额增加了多少），并且，这个统计可以自动化地完成。接下来，我们的问题就是：

3、如何找出最佳的推荐、排列方案？

二、设想

据我所知，目前很多购物网站的推荐列表都是人工处理的，通常是由某一个有经验的运营专员来决定这一期（每一期的周期可能是一天，也可能是一周，等等）推荐哪几种商品，谁排第一、谁排第二也是由他来决定。推荐列表上线后，运营专员可能会根据最终市场反馈调整列表，也可能完全不做调整，直到下一期。

这样的好处是操作简单，但缺点也是很明显的，运营专员虽然很有经验，但也难免会有一些偏见或盲点，他在某一期中推荐了商品 1 ，没有推商品 2，但或许那一期如果他推商品 2 其实能为网站带来更多的订单额，——谁知道呢？同时，有多少个推荐列表就需要多少人工，对于一个有很多频道、分类的大型购物网站来说，人工确定每一个推荐列表是一个不小的工作量，而且，分类越细、越专业，运营专员失误的可能也会越大。另外，这种人工操作方式无法随机应变，比如商品 3 现在是冷门商品，运营专员也没把它放在推荐列表上，这没什么问题，但如果突然发生了某个事件，导致商品 3 突然成了热门商品，如果这时商品 3 能自动出现在推荐列表上，一定能带来更多的订单，但在人工操作的模式下，这很难成为现实。

所以，我们需要一种更自动化、更智能的机制。

现在，我们手里拥有的，是能准确地度量某一个推荐列表方案带来的收益，想要的，是一种能自动化发现能带来最大订单金额的推荐列表方案，并且还能根据市场的变化自动调整推荐排序。

很自然地，在这儿我想到了遗传算法。

遗传算法模拟了自然界生物的进化，能通过不断的迭代来找到最优解。关于遗传算法的介绍就不多说了，在这儿，我们可以通过这样的方式来操作：

在后台生成 P 种不同的推荐列表方案（种群规模），对不同的用户（比如根据 cookie id 来决定显示哪个方案）显示不同的方案，再通过上面的方法统计每种方案的收益。然后，不断地迭代、进化。

要实施这个算法，关键点主要有两个：

1、编码方法以及交叉、突变规则；
2、评价函数。

其中前者决定如何将一个实际问题转化为可以用遗传算法模拟的问题，即如何将实际问题转化为“基因编码”，后者则是评估每一个“基因编码”的适应度。对我们而言，第二个问题我们上面已经有比较完美的解决方案了，我们可以将推荐列表带来的订单额作为它的评价标准。剩下的问题就是如何编码以及突变。

注意到，待推荐的商品（备选商品）实际上是一个集合，设它的长度为 N，我们从中选出 n 项放到推荐列表上，而推荐列表是一个有序的列表。我们需要控制的，一是选择哪 n 个商品，二是这 n 个商品如何排序。一个简单的处理方法是将这 N 个备选商品看作一个大列表，只需要使用遗传算法对这个列表进行排序，并每次取列表的前 n 个商品依次放到推荐列表中即可，但事实上，第 n + 1 至第 N 号商品的排序几乎不会影响到结果，因为它们并不会显示在推荐列表中，因此，如果 n 比 N 小很多的话，这个方式或许会比较低效。另外还有一些不同的编码方法，不过都相对比较复杂，展开的话篇幅较大，这部分内容将来的博客中再讨论。需要明白的是，编码方法以及交叉、突变规则可能是整个处理过程中最有挑战性也是最核心的部分。

于是，整个访问、购买流程就变成了下面这样：

后台设定好备选商品，再给定 P 个初始推荐列表方案（这些初始方案也可以完全随机生成），接下来，记录下每一种方案带来的收益（订单额），每隔一段时间 t 让各方案进行一次迭代、进化，生成新的方案。理论上来说，这样可以保证找到最佳的商品推荐列表，为网站带来最大的订单额。

三、可能的问题

不过，要实现这个想法也并非易事，需要注意的问题至少有：

1、种群规模定为多大？即上面的 P 定为多少？

这个问题应该和备选商品总数 N 有密切关系，我想，应该不要低于 50 为宜。之前的博客中我介绍过 A/B Testing，这种方法与 A/B Testing 有些类似，但不同点在于 A/B Testing 一般只有两、三个不同的版本同时上线测试，而这种方法可能需要同时几十个甚至更多的不同的版本上线，另外，A/B Testing 的方案都是测试人员指定的，而这种方法的方案会随着迭代的进行不断变化。

2、什么样的网站上可以尝试这种方法？

为了尽可能减少随机干扰，每个方案都必须要有大量的访问量（大数定律）。这个访问量具体应该多大我还不清楚，不过我估计应该要每天百万级别访客量（UV）的站点才适合，即每个方案每天的访客量（UV）应该至少要一两万，否则随机干扰可能会影响较大，影响正常的进化。就像在一个气候经常会随机剧烈变化的环境中，生物很难较好地生存、进化一样。

目前国内每天访客量达到百万级别的购物网站并不是很多，如果再加一个限制条件“主要频道或推广页面每天的访客量也达到百万级别”，剩下的就没几家了。

3、每隔多长时间迭代一次？即上面的 t 定为多少？

这可能需要实践后才能确定。理想情况下，t 当然越短越好，t 越短，越能与当前趋势合拍。但另一方面，t 越短，这段时间内的访客量也就越小，于是随机干扰就会越大，进化失败的可能也就会越大。不过，为了让推荐排序能尽快地根据购物趋势调整，我觉得这个 t 应该不要大于一天，在访问高峰时期应该更短，比如一小时，甚至半小时。这也是上面对网站访客量（UV）有较高要求的原因之一。

4、如何保证尽可能快地收敛到最优解？

之前我曾写过用遗传算法解旅行商问题的帖子。那篇帖子介绍的算法，用了两千多次迭代才接近最优解，三千多次迭代才找到最优解。对于旅行商问题来说，迭代三千多次是没有问题的，但我们这儿，如同上面问题 3 所说的，每一代都意味着一段不短的时间，即使一代只需要 10 分钟（这已经有点太短了...），2000 代就需要接近 14 天的时间，这还只是接近最优解。这样的效率，对于大多数应用场景来说，是不可接受的。

但这个问题并非完全不可能克服，或许我们可以找到某种更优秀的编码方式或算法，大大地提高收敛的速度。

5、最后，技术之外，关于实际实施的问题。

从上面的讨论我们看到，这个想法需要海量的 UV，所以，在中小型购物网站几乎是不太可能实践的，只有大型购物网站（比如淘宝、京东）才有可能尝试。但这个方法涉及到很多部门，不仅包括技术、运营等部门，还包括涉及网站核心机密的订单信息。要真的说服各方配合，拿到重重审批，还要相关方开通相应的接口，这不是一件简单的事情，呵呵...

另外，实际操作中，有一些推荐列表可能有更为复杂的规则，比如某个位置是某位合作伙伴或付费用户指定的，排序时要对它特殊处理，等等。

这些问题都比较麻烦，尤其是第 5 点，所以，尽管有这个想法五年了，我一直没能找到实践的机会。或许它还太超前，也或许它并不可行，或许有人和我有类似的设想，但也因为类似的原因没能实践。

如果不考虑这些问题，想象一下，除了推荐列表，貌似这个方法还可以在很多地方应用，比如搜索结果页面等等。不过先就此打住，不要游荡得太远了，呵呵。