趁着年末整理一下最近的一些新的见解，留个记录，以便后续反思和打脸。
优化 Optimization
关于优化，最近形成了一个新的认知：对具体问题的结构的理解是非常重要的。具体来说，各类经典优化算法都可以看成是**在某个解空间结构上进行局部搜索(local search)**：
- primal simplex是在可行域表面上的局部搜索。
- 梯度下降和meta-heuristic是可行域内的局部搜索。
这意味着一种通用的方法论(methodology)是寻找更好的解空间结构：
- mirror descent通过某种系统性的手段改变原始可行域的度量，从而改变了局部搜索的方向。
- 在组合优化中，原始对偶方法通过互补松弛（complementary slackness）条件构造具有强组合结构的子问题来优化局部搜索效率。
- 整数规划中一种常用技术是做lifting，将可行域从复杂低维形式转化为简单高维形式。
- OM中一种常用的分析技巧是通过决策变量的变换来获得更好的几何结构。
- heuristic的设计关键就在于如何利用问题结构优化局部搜索的效率。
因此，考虑到不同业务的内在逻辑，应该对不同的解法更加open：看起来naive的思路很可能利用了某种重要结构。对于有能力的人来说，更应该理解和挖掘这些结构，从中找出共通性，从而设计更好的算法，而不是简单地将问题转化为已知形式再调包/solver解决。从这个角度，感觉很多以前的工作都可以再review一下。
计算 Computation
根据观察，我发现计算效率在算法层面很容易被忽视。个人判断主要还是意识和机制问题。一方面，开发时没有足够的意识进行效率优化；另一方面，后续维护时缺乏优化动机。这在无形之中给系统增加了很多性能瓶颈。
计算效率问题主要体现为两点。一方面，算法实现上存在过多冗余。这方面我个人做的也不是很好；这在仿真系统的开发上体现得特别明显。例如，在仿真网约车的司乘匹配问题时，首先需要计算每个司乘对的距离，从而判断匹配的可行性。最简单的做法是遍历所有司乘对，但是这种做法不scalable。在大规模场景下，一种更好的做法是先将司乘的位置映射到一系列区域内，然后只对相邻区域内的点对进行计算。一个简单实现表明这种做法在大规模场景下速度能提高3倍以上。再如，根据可行性判定，在调用匹配算法时很多配对是不需要被考虑的；此时应该使用稀疏存储及相应的稀疏匹配算法。计算表明，在大多数场景下速度能提高5~10倍。
另一方面，未能使用足够好的底层工具来提高效率。单从Python来说，通过numba可以将很多无法简单矢量化的过程提速上百倍。在不具备完全迁移到C++/Julia上的可行性的情况下，熟练掌握numba和Cython还是很必要的。
决策 Decision-making
相比优化，决策过程的外部依赖更复杂多样，因此更依赖于决策者的主观判断和信念(belief)。很多时候，与“决策原则”相关的讨论都是围绕主观信念展开的，更偏向哲学(philosophy)思辨，不同思路之间很难比出个高下。因此，我们并不关心决策者应采用哪种信念；但是，一旦形成了主观判断，后续的决策就应当与之相符。然而，根据我个人的实践经验，这其实并不容易。其中的一大难点在于：很多决策方法隐含的假设和方法论与决策者真正的主观信念并不相符。下面通过一些具体场景进行讨论。
首先考虑建模(modeling)与模型驱动(model-driven)决策。一句著名的话说，“All models are wrong, some are useful”；而如何选择“恰到好处”的建模元素来得到useful model是很考验功力的。若因素没有考虑完备，则模型的解释力会大打折扣；若无关因素考虑过多，则模型过于冗余，无法快速给出简要直白的insights。我在过去一年中进行了不少尝试，也走了不少弯路，深刻地认识到：目前识别关键因素的能力还存在着很大的局限性，后续仍要不断实践积累经验。另外，除了要回答“怎么建模”，modeler还需要能够回答“怎样使用模型”。最基础但是很容易被忽视的一点是要理解模型的逻辑和局限性，并在合理范围内应用。事实上，受限于决策成本和能力，许多人对于模型的选用是有sparse和极端化趋势的。
再考虑不确定性(uncertainty)的处理方式。决策者对问题的理解很难做到完全准确，因此有必要针对这种不确定性的可能后果进行规划。首先，以下几种常用手段及其相应假设：
- 鲁棒优化(robust optimization)：假设事情总是在一系列可能性中按最坏的情况发生。
- 探索(exploration)：假设新增的数据提供的信息能长期有效地降低估计的不确定性，因此可以通过牺牲一部分短期利益来减少长期遗憾(regret)。
- 对冲(hedge)：假设一系列随机过程的不确定性具有线性相关性，因此可以通过线性组合的方式消除一部分不想要的不确定性。
现在，考虑以下问题：
- 如果在低信噪比、非平稳环境中做探索，可以取得什么收益？
- 如果希望在一系列关于指标B的约束大概率得到满足的同时，降低指标A的长期regret，应该采用哪种手段？
可以看出，武断地使用某种具体手段很容易导致结果南辕北辙。
城市交通 Urban Transportation
最后，简单介绍一下我个人对后续城市交通方面值得做的点的判断。首先，MaaS等概念的兴起意味着未来需求与载具的相关性进一步削弱，整个系统可以拆分成需求、载具、基建三方面进行分析。
具体来说，目前从国内大背景上看，一方面，虽然载具侧产能过剩，短期内成本走低，但个人推测持续时间不长，可能只会维持3~5年，然后成本就会恢复正常水平。同时，强监管大幅提高了人力成本。另一方面，需求侧人均出行频率和费率持续下降，大趋势上很难逆转；而且通过过往几年的宣传，由可达性(accessibility)提升带来的新增需求已经基本到顶。这意味着未来需求侧的增长只可能来源于人口增长和出行模式的竞争。竞争要素主要包含以下几点：便捷、价格、舒适度、稳定性、搜索成本。考虑到公共交通特别是轨道交通仍在高速增长，而且地面公交智能化运营已有不少尝试，如果地面公交能够与轨交联动进一步提升效率，公交系统将会具有更强的竞争力（考虑到目前有大量的公交-打车形式的接驳需求）。另外，许多分析认为目前的城市管理思路将导致活动向少量POI集中，在这种情况下共享出行的便捷性优势将大打折扣。
基于这些观察，我认为后续需求侧的共享出行业务会有两种发展趋势：高端化或批量化。前者可与传统航司的运营手段类比，通过低毛利的普通需求形成网络效应，再从高支付意愿的两仓中获取高毛利。但与航司一样，国内业务很容易受到资源和行政制约，因此较难保证最本质的服务质量（旅行时间的稳定性）。后者则是定制化小运量路面公交的思路，但在国内由于法律风控的原因很难由私人部门占主导地位，更可能的是私人部门通过合作的形式在数据挖掘和智能管理方面为公共部门提供支持。（注：领导指出，这种模式最大的问题在于公共部门可能不具备足够的动机。）
相比之下，随着V2I等技术的发展，城市管理者有能力获得更实时的信息，从而可以引入更精准的管理手段，例如实时拥堵收费、停车资源调配等。另外，在信息层面，MaaS服务方拥有大量的需求-载具侧信息，而传统管理方拥有载具-基建侧信息，两层数据之间的整合与应用也很值得探索。综上所述，我认为需求侧的空间可能没有想象中大，而基建侧有很大的探索空间。当然，这里对空间的大小判断存在personal bias，因为此前我花了更多时间在需求侧上。