<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

 <title>期望最大化（洪亮劼的专栏）</title>
 <link href="http://column.hongliangjie.com/atom.xml" rel="self"/>
 <link href="http://column.hongliangjie.com/"/>
 <updated>2026-05-10T10:39:05-07:00</updated>
 <id>http://column.hongliangjie.com</id>
 <author>
   <name>洪亮劼</name>
   <email>hongliangjie@gmail.com</email>
 </author>

 
 <entry>
   <title>工业界论文该不该上线？</title>
   <link href="http://column.hongliangjie.com/%E7%A0%94%E7%A9%B6/2026/05/10/industry-paper-legitimacy/"/>
   <updated>2026-05-10T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E7%A0%94%E7%A9%B6/2026/05/10/industry-paper-legitimacy</id>
   <content type="html">&lt;p&gt;2017 年，Google Brain 的八位工程师发表了一篇论文。这篇论文没有刷任何榜，它发明了新的榜。Transformer 架构从此成为整个行业的计算基础设施，几乎所有后续大模型都构建在它之上。值得一提的是，论文发表后不久，这八位作者全部离开了 Google，各自创业。&lt;/p&gt;

&lt;h2 id=&quot;一引言&quot;&gt;一、引言&lt;/h2&gt;
&lt;hr /&gt;
&lt;!-- 配图：待定 --&gt;

&lt;p&gt;2024 年，某家知名 AI 公司发布技术报告，宣称”在 17 项评测中刷新 SOTA”，但架构细节、训练数据构成、计算量，一概不提。报告的核心信息是：我们赢了。至于赢在哪里、怎么赢的、这个”赢”能不能被独立验证，不在讨论范围之内。&lt;/p&gt;

&lt;p&gt;同样是工业界论文，差距在哪里？&lt;/p&gt;

&lt;p&gt;表面上的答案是”透明度”，但这个答案不够准确。真正的差距在于：前者解决了一个只有 Google 规模的工程团队才会遇到的问题，后者只是在一套现成的评价体系上打了个更高的分。&lt;/p&gt;

&lt;p&gt;工业界发论文，动机天然是双重的。对外，它是品牌展示、人才招募、学术话语权的工具；对内，它固化研究方向、推动产品决策。这两种动机不一定冲突，但当论文退化为刷榜报告时，对外的动机吞噬了对内的价值，公司用学术界的评价尺子衡量自己，却放弃了工业界最独特的东西。&lt;/p&gt;

&lt;p&gt;本文不讨论工业界”应不应该”发论文，答案显然是肯定的。要讨论的是：什么样的工业界论文值得发？发了之后，又应该对读者诚实到什么程度？&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;二刷榜论文的症结公地悲剧&quot;&gt;二、刷榜论文的症结：公地悲剧&lt;/h2&gt;
&lt;hr /&gt;
&lt;!-- 配图：待定 --&gt;
&lt;p&gt;&lt;img src=&quot;/assets/Industry_paper_1.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;h3 id=&quot;什么是刷榜式论文&quot;&gt;什么是”刷榜式论文”&lt;/h3&gt;

&lt;p&gt;定义并不复杂：以在特定 benchmark 上提升分数为主要贡献的论文。通常伴随以下特征：贡献仅限于在已有方法上做工程调优；评测数据集高度同质，难以外推；实验设计围绕”赢得榜单”，而非”回答科学问题”。&lt;/p&gt;

&lt;p&gt;这类论文本身并非一无是处，工程优化也是知识。问题在于，当它成为主流，整套评价体系就开始腐化。&lt;/p&gt;

&lt;h3 id=&quot;benchmark-本身的腐化&quot;&gt;Benchmark 本身的腐化&lt;/h3&gt;

&lt;p&gt;研究者分析了 Papers With Code 上的 3765 个 benchmark，发现一个普遍规律：大量 benchmark 在被引入后迅速趋近饱和，性能提升容易出现不可预见的突变式爆发。这意味着一个 benchmark 往往在它”看起来最有竞争力”的时候，恰恰是它作为评价工具最无效的时候。&lt;/p&gt;

&lt;p&gt;工业界加速了这个腐化过程。头部 AI 公司有资源系统性地针对榜单优化：定向数据清洗、超参数大规模搜索、评测集的隐性泄漏。这是一种不对等竞争，学术实验室无法承担同等的优化成本，因此榜单排名越来越不反映真实能力差距，而是反映资源投入差距。&lt;/p&gt;

&lt;p&gt;这是一种典型的公地悲剧：每家公司的理性行为（针对 benchmark 优化以提升排名）导致了公共资源的集体损耗。一旦某个 benchmark 被系统性地优化过，它作为独立评价工具的有效性就宣告终结，但这时候所有人都还在引用它，仿佛它依然有意义。&lt;/p&gt;

&lt;h3 id=&quot;gpt-4-技术报告极端案例&quot;&gt;GPT-4 技术报告：极端案例&lt;/h3&gt;

&lt;p&gt;GPT-4 技术报告是这个问题的极端版本，它不是在榜单上竞争，而是彻底拒绝提供可竞争的基础。&lt;/p&gt;

&lt;p&gt;报告明确声明：出于竞争格局和安全考量，不提供架构细节（包括模型大小）、硬件配置、训练计算量、数据集构建方法。批评者的回应直接：引用安全是借口，本质是商业保护。真正开放的研究机构在能力范围内应该尽可能透明。同行评审发现，报告在风险评估方面有一定透明度，但缺乏训练流程和数据来源的关键细节，引发了对编码偏见和隐藏利益的担忧。&lt;/p&gt;

&lt;p&gt;GPT-4 报告不是一篇科学论文，是一份产品公告。发表它的目的是控制叙事，而非贡献知识。&lt;/p&gt;

&lt;h3 id=&quot;企业研究的内卷化&quot;&gt;企业研究的内卷化&lt;/h3&gt;

&lt;p&gt;2020—2025 年的数据揭示了一个更系统性的趋势：企业 AI 研究越来越集中于预部署领域（模型对齐与测试评估），对部署后问题（模型偏见、真实场景中的鲁棒性）的关注持续减少。研究发现越来越多地留在内部，不公开发表。&lt;/p&gt;

&lt;p&gt;这不只是透明度问题，而是研究目标的漂移：论文越来越服务于发布节奏，而非回答真实问题。&lt;/p&gt;

&lt;p&gt;刷榜论文的根本错误在于一种结构性矛盾：它采用了学术界的评价框架，却没有承担学术界的义务；与此同时，它也放弃了工业界最大的优势，只有你才能做的研究。&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;三四家公司的论文策略画像&quot;&gt;三、四家公司的论文策略画像&lt;/h2&gt;
&lt;hr /&gt;
&lt;!-- 配图：待定 --&gt;
&lt;p&gt;&lt;img src=&quot;/assets/Industry_paper_2.png&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;理解工业界论文的问题，最好的方式是看具体的公司在做什么、为什么这么做。用”贡献的独特性”作横轴，”信息透明度”作纵轴，四家主要 AI 公司的策略落点清晰地分散在坐标系的不同位置。这不是评分，而是描述策略差异背后的商业逻辑。&lt;/p&gt;

&lt;h3 id=&quot;google--deepmind高水位线的建立者&quot;&gt;Google / DeepMind：高水位线的建立者&lt;/h3&gt;

&lt;p&gt;Google 的代表性论文有一个共同质地：它们解决了只有 Google 才会遇到的问题。&lt;/p&gt;

&lt;p&gt;Transformer（2017）的起点是大规模机器翻译的并行化瓶颈。当时的 RNN 架构在序列长度上存在根本性的计算限制，Google 的翻译系统已经大到让这个限制变得无法接受。注意力机制不是新发明，但把整个架构建立在注意力之上是一次范式跳跃。论文发表后，它的影响不是在翻译榜单上领先，而是重写了整个 NLP 的计算范式。&lt;/p&gt;

&lt;p&gt;同一类型的还有 MapReduce、PageRank、BigTable，都是为了解决”互联网规模的数据处理”这个只有 2000 年代的 Google 才真正面对的工程问题。这些论文的合法性来自独特性，不来自榜单排名。&lt;/p&gt;

&lt;p&gt;近年来 DeepMind 的部分研究（如长达 145 页的 AGI 安全报告）开始引发”是研究还是公关”的质疑。这说明即使是高质量实验室，也面临论文动机复杂化的压力，当公司需要管理外部叙事时，研究发表也变成了工具之一。&lt;/p&gt;

&lt;h3 id=&quot;openai从开放到封闭的策略转变&quot;&gt;OpenAI：从开放到封闭的策略转变&lt;/h3&gt;

&lt;p&gt;OpenAI 的论文策略经历了一次清晰的历史转折。&lt;/p&gt;

&lt;p&gt;早期，GPT-2 以”暂缓发布”的姿态引发公众讨论，强调透明与风险意识并重；GPT-3 则通过详尽的技术报告建立了学术界的广泛引用基础。这个阶段的 OpenAI，研究发表是建立信誉的核心工具。&lt;/p&gt;

&lt;p&gt;GPT-4 之后，情况逆转。随着模型能力的提升和商业化压力的加大，关键细节从技术报告中系统性地消失。”竞争安全”成为保密的标准理由。&lt;/p&gt;

&lt;p&gt;这个转变揭示了一个结构性矛盾：当研究成果直接就是产品时，论文与产品发布之间的界限消失了。OpenAI 现在发布的技术报告，更多是产品说明书的学术包装，它的目标受众不是研究者，而是媒体和投资人。&lt;/p&gt;

&lt;h3 id=&quot;meta-ai开源是商业逻辑不是道德立场&quot;&gt;Meta AI：开源是商业逻辑，不是道德立场&lt;/h3&gt;

&lt;p&gt;Meta 是近年来最矛盾也最值得分析的案例。&lt;/p&gt;

&lt;p&gt;Zuckerberg 在公开场合多次阐述 Meta 开源的逻辑，说得相当坦率：Meta 卖广告，不卖 API。开放 LLaMA 的权重不会削弱营收，却能建立生态依赖、吸引顶尖研究者、压缩竞争对手的定价空间。LLaMA 2 和 LLaMA 3 的开放权重支撑了数以千计的学术论文，这些研究机构无力承担 OpenAI API 的费用，Meta 通过开源获得了巨大的学术引用影响力，而这个影响力又反过来强化了 Meta 作为 AI 基础设施提供者的地位。&lt;/p&gt;

&lt;p&gt;但 Muse Spark 的出现打破了这个叙事，最新的前沿模型已经闭源。Zuckerberg 此前关于开源的承诺，至少在前沿层已经食言。对依赖 LLaMA 权重进行研究的学术界而言，这个信号相当清楚：Meta 的开源是可以撤回的策略，不是不可动摇的立场。&lt;/p&gt;

&lt;h3 id=&quot;anthropic安全研究作为定位锚点&quot;&gt;Anthropic：安全研究作为定位锚点&lt;/h3&gt;

&lt;p&gt;Anthropic 的代表性论文（Constitutional AI、RLHF 方法研究、可解释性探索）有一个共同点：它们服务于公司的核心定位，即负责任地构建 AI。&lt;/p&gt;

&lt;p&gt;这类研究较少以 benchmark 刷新为目标，更多聚焦方法论和安全机制。这是一种相对清晰的研究—产品对齐方式：研究的目的就是为了做出更安全的产品，而不是为了发表而发表。&lt;/p&gt;

&lt;p&gt;它的问题在于：安全研究的真实进展很难被外部评估。这给”用安全包装公关”的操作留下了空间。当一篇论文的核心主张是”我们更安全”，但安全的度量本身不透明时，读者很难区分真实进展和品牌管理。&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;四开源与闭源不是道德题是战略题&quot;&gt;四、开源与闭源：不是道德题，是战略题&lt;/h2&gt;
&lt;hr /&gt;
&lt;!-- 配图：待定 --&gt;
&lt;p&gt;&lt;img src=&quot;/assets/Industry_paper_3.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;AI 圈有一个根深蒂固的叙事框架：开源 = 好人，闭源 = 坏人。这个框架既不准确，也不有用。&lt;/p&gt;

&lt;h3 id=&quot;需要分开的三件事&quot;&gt;需要分开的三件事&lt;/h3&gt;

&lt;p&gt;理解工业界的论文策略，首先要厘清三个独立的维度：&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;模型权重是否开放&lt;/li&gt;
  &lt;li&gt;训练数据是否透明&lt;/li&gt;
  &lt;li&gt;论文方法描述是否诚实&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;这三者可以完全独立变化。GPT-4 报告：权重闭源，数据不透明，论文描述有限，三个维度同向。LLaMA 2：权重开放，数据不完全透明，论文描述相对诚实，三个维度并不一致。混淆这三件事，会导致用错误的标准评价论文质量。&lt;/p&gt;

&lt;h3 id=&quot;开源的真实驱动力&quot;&gt;开源的真实驱动力&lt;/h3&gt;

&lt;p&gt;没有公司因为道德理由选择开源，每家公司的选择都是对自身商业模式的理性响应。&lt;/p&gt;

&lt;p&gt;Meta 的核心收入来自广告，不依赖 AI API 变现；开放 LLaMA 不伤害营收，却能建立生态依赖。Google 的核心收入来自搜索广告，云业务是第二战场；开源 Gemma 有利于云生态，但前沿的 Gemini 系列保持闭源。OpenAI 的核心收入就是 API 和企业授权；透明等于竞争情报泄漏，保密是最直接的商业利益。Anthropic 收入同样来自 API，但以安全研究为差异化定位，需要在透明度和商业保护之间维持平衡。&lt;/p&gt;

&lt;p&gt;这不是批评，而是描述。理解商业逻辑之后，每家公司的选择都是可以预测的，用道德框架无法解释，用利益结构分析则一目了然。&lt;/p&gt;

&lt;h3 id=&quot;透明度与开源可以解耦&quot;&gt;透明度与开源可以解耦&lt;/h3&gt;

&lt;p&gt;即使在完全闭源的情况下，论文也可以做到高度诚实：披露训练方法和数据处理流程（无需开放具体数据）；报告模型在对抗场景、分布外数据、长尾任务上的失败案例；给出置信区间，而不是只报告峰值指标；诚实描述评测设计的局限性。&lt;/p&gt;

&lt;p&gt;LLaMA 2 论文直接写明：”我们的模型在某些能力上仍然落后于 GPT-4。”这句话让整篇论文的可信度大幅提升，因为读者知道作者没有选择性报告。这才是区分”科学论文”和”产品公告”的真正分界线：不在于开不开源，在于敢不敢承认局限。&lt;/p&gt;

&lt;p&gt;对工业界而言，最可行的路径不是”要求所有研究开源”，而是”要求所有论文诚实”。这是一个低得多的门槛，却被很多公司主动放弃。&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;五工业界论文合法性的三个标准&quot;&gt;五、工业界论文合法性的三个标准&lt;/h2&gt;
&lt;hr /&gt;
&lt;!-- 配图：待定 --&gt;
&lt;p&gt;&lt;img src=&quot;/assets/Industry_paper_4.png&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;如果刷榜不是答案，什么才是？不是问”这篇论文有没有在榜单上领先”，而是问三个更根本的问题：这个问题只有你才能研究吗？你的研究回答了真实世界中的问题吗？你诚实地告诉读者这项研究的边界在哪里吗？&lt;/p&gt;

&lt;h3 id=&quot;标准一独特性原则只有你才能做&quot;&gt;标准一：独特性原则，只有你才能做&lt;/h3&gt;

&lt;p&gt;工业界相对学术界有三种独特资源：真实大规模数据（生产环境数据的规模和分布，学界无法复现）、超大算力预算（某些实验只有在工业界才跑得起来）、工程反馈闭环（系统上线后的真实用户行为反馈）。&lt;/p&gt;

&lt;p&gt;一篇合格的工业界论文，应该至少利用其中一项优势。如果一篇论文用的数据、方法、规模是任何一所高校也能复现的，它作为工业界论文就没有额外的合法性，因为学界做同样的研究会更可信，商业动机的嫌疑更少。&lt;/p&gt;

&lt;p&gt;反例：某公司发布论文，声称在公开数据集上微调后刷新了榜单。这完全可以由任何一所高校完成，工业界做这件事不仅没有增量价值，还因商业动机而降低了可信度。&lt;/p&gt;

&lt;p&gt;正例：某公司发表论文，描述了在十亿级用户数据上观察到的模型退化模式，以及为此设计的监测系统。这是学界没有条件研究的问题，不是因为方法更复杂，而是因为数据本身不可得。&lt;/p&gt;

&lt;h3 id=&quot;标准二真实问题导向上线是试金石&quot;&gt;标准二：真实问题导向，上线是试金石&lt;/h3&gt;

&lt;p&gt;“论文需不需要上线”是一个被误读的问题。正确的解读不是”每篇论文都必须对应一个产品功能”，而是：论文要解决的问题，必须是真实存在的问题。&lt;/p&gt;

&lt;p&gt;上线过的系统会暴露 benchmark 永远不会暴露的东西：实验室模型在生产环境下的延迟通常比 benchmark 高出数倍；用户的真实输入分布和评测集的差距有时是量级上的；只有在真实流量下，才能观察到头部测试集完全覆盖不到的失败模式；用户如何与模型交互，暴露了哪些能力被高估、哪些被低估。&lt;/p&gt;

&lt;p&gt;好的工业界论文，应该把”只有在生产环境中才能知道”的东西写出来，而不是把生产系统当作刷榜的算力来源。&lt;/p&gt;

&lt;h3 id=&quot;标准三诚实的局限性可信度是长期资产&quot;&gt;标准三：诚实的局限性，可信度是长期资产&lt;/h3&gt;

&lt;p&gt;承认局限性不是弱点，是论文的信用资产。&lt;/p&gt;

&lt;p&gt;GPT-4 报告的同行评审指出：缺乏训练流程和数据来源的关键细节，引发了对编码偏见和隐藏利益的担忧。不透明不只是科学问题，也是可信度问题，读者在阅读这篇报告时，必须把”商业动机可能导致选择性报告”作为一个常驻假设。&lt;/p&gt;

&lt;p&gt;LLaMA 2 论文的做法提供了一个对比参照：直接写明自己的模型在某些能力上落后于 GPT-4，使得其他部分的结论更值得信赖。实际操作层面，这意味着：报告失败案例，给出置信区间，说明评测设计的局限，描述哪些场景超出了模型的能力范围。&lt;/p&gt;

&lt;p&gt;一家公司持续发表诚实的论文，会在研究社区中建立长期的信用储备。反之，一旦被发现选择性报告，所有后续论文的可信度都会打折扣。这是一个复利结构：诚实的收益递增，不诚实的代价递增。&lt;/p&gt;

&lt;h3 id=&quot;三个标准的关系&quot;&gt;三个标准的关系&lt;/h3&gt;

&lt;p&gt;这三个标准不是并列的，而是有优先级：独特性是门槛（如果这件事学界能做，工业界就不要抢）；真实问题导向是核心（研究是否解决了真实存在的问题）；诚实的局限性是底线（达不到这条线，发表不如不发）。三者共同构成一个筛选框架，通过这个框架的论文，才算是工业界向科学社区的真实贡献。&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;六结语&quot;&gt;六、结语&lt;/h2&gt;
&lt;hr /&gt;
&lt;!-- 配图：待定 --&gt;

&lt;p&gt;如果工业界的论文策略以刷榜为主，表面上的输家是学术界，评价体系被污染，研究方向被带偏。但实际上，工业界自己才是最大的输家。&lt;/p&gt;

&lt;p&gt;当 benchmark 失去效度，没有人能准确判断模型的真实能力。这包括发论文的公司本身，它们也失去了独立评估进展的工具。”我们在 X 任务上超越了所有竞争对手”这个说法，在一个被系统性优化过的评价体系下，已经没有任何信息量。公司不知道自己在哪里领先、领先多少，只知道在某张榜单上暂时排第一。这是一种自我蒙蔽。&lt;/p&gt;

&lt;p&gt;工业界正在影响整个 AI 研究生态的走向：它的资源决定了哪些方向被探索，它的论文策略决定了什么算”好研究”。当全球最顶尖的 AI 研究者有七成在工业界，当工业界论文的引用量是学界的两倍，工业界的研究品味就是整个领域的品味。这不是道德说教，而是结构性事实。&lt;/p&gt;

&lt;p&gt;最后留下一个没有答案的问题：当一家公司最好的研究成果永远不能发表，因为那就是产品本身；当一篇论文如果说实话就等于泄露竞争情报，我们如何重建工业界与学术界之间诚实的对话？&lt;/p&gt;

&lt;p&gt;这不是工业界单独能解决的问题。但工业界是最有能力开始改变的一方。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>AI as a Service：一门注定被侵蚀的生意</title>
   <link href="http://column.hongliangjie.com/%E7%AE%A1%E7%90%86/2026/05/02/ai-as-service/"/>
   <updated>2026-05-02T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E7%AE%A1%E7%90%86/2026/05/02/ai-as-service</id>
   <content type="html">&lt;p&gt;2023年，一场久违的融资热潮席卷了整个科技行业。这一次的主角不是社交媒体，不是共享经济，而是一个听起来几乎万能的词：AI。那一年，全球有超过两千家以”AI平台”“AI中间件”“AI即服务”为核心标签的公司完成了融资，其中不乏估值过亿美元的独角兽。投资人的逻辑清晰而自洽：AI能力高度稀缺、企业数字化需求爆炸、规模化交付天然可行，这不正是SaaS黄金时代的翻版吗？当年的Salesforce、ServiceNow，不也是靠着把软件从”产品”变成”服务”而崛起的吗？一切看起来都指向同一个方向：”AI as a Service”是一门好生意，早入场的人会赢。&lt;/p&gt;

&lt;h2 id=&quot;引言一个看起来很合理的生意&quot;&gt;引言：一个看起来很合理的生意&lt;/h2&gt;
&lt;hr /&gt;
&lt;!-- 配图：待定 --&gt;

&lt;p&gt;然后，2024年年中，瑞典支付公司Klarna做了一件震惊业界的事。CEO Sebastian Siemiatkowski在一次投资人电话会上宣布，公司正在全面替换Salesforce和Workday，改用AI自研方案。他说，一个基于OpenAI的客服Bot已经承担了原本需要700名人工客服才能完成的工作量，每年为公司节省大约四千万美元。这个消息像一颗石子投进了平静的水面，涟漪迅速扩散，AI正在颠覆SaaS，就连独立软件服务商都要被AI取代了？那些押注”AI as a Service”的公司，是在建一个新帝国，还是在替代一个旧帝国？但故事还没讲完。&lt;/p&gt;

&lt;p&gt;本文的核心论点不是AI不好，也不是说企业不需要AI，恰恰相反。这篇文章想讨论的是：把AI能力当服务卖，正在成为一个在结构上越来越难以独立成立的商业逻辑。2023年以来的这轮AI浪潮，非但没有让”AI as a Service”这门生意更容易做，反而从芯片、平台、数据、云生态、以及自建能力五个维度，系统性地压缩了中间层独立AI服务商的生存空间。能活下来的，都已经不再是纯粹意义上的”AI服务”了。&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;全栈化时代中间层是最危险的位置&quot;&gt;全栈化时代，中间层是最危险的位置&lt;/h2&gt;
&lt;hr /&gt;
&lt;!-- 配图：待定 --&gt;
&lt;p&gt;&lt;img src=&quot;/assets/ai_saas_1.webp&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;要理解独立AI服务商的处境，需要先理解AI产业的竞争结构已经发生了什么本质性的变化。&lt;/p&gt;

&lt;p&gt;三年前，AI行业的分工还相对清晰：有人做芯片，有人做基础模型，有人做应用层的具体场景，中间有大量的机会留给那些做”能力封装”和”场景交付”的中间层公司。但今天，这个分工正在被垂直整合彻底重塑。整个AI产业链，已经形成了三层叠加的竞争结构：最底层是芯片和算力（NVIDIA的GPU生态、Google的TPU、Amazon的Trainium）；中间层是AI平台（AWS Bedrock、Google Vertex AI、Azure AI Foundry）；最上层是面向终端用户的应用（搜索、广告、Copilot、代码助手）。这三层之间的关键词是：垂直整合、全链路、端到端优化。当一个企业客户在考虑AI选型时，面对的本质上是两条路：要么接受某个全栈方案，要么在多个独立服务商之间拼凑一个方案。这两条路的摩擦成本差距，正在以肉眼可见的速度扩大。&lt;/p&gt;

&lt;p&gt;平台层的格局变化是最直接的冲击。AWS Bedrock、Google Vertex AI、Azure AI Foundry三强格局已经基本确立。这些平台提供的远不只是模型调用接口：从数据准备、模型微调、推理部署、性能监控，到安全合规，整套工具链一应俱全。更重要的是，这场竞争的核心已经不再是”谁拥有最好的单个模型”，而是”谁能最深度地嵌入企业的AI采购、构建和部署流程”。当一家企业的工程团队已经在Bedrock上跑通了第一个AI项目，当他们的IAM权限、日志审计、成本报表都已经集成进AWS的管理控制台，这时候引入一个独立的AI服务商，意味着要在已有体系之外新建一套平行的安全边界、新申请一套合规资质、新接受一套账期和合同逻辑。这不是功能比较，这是系统复杂度的比较。对于一个独立AI服务商而言，真正的竞争对手不是另一家同类公司，而是客户已经在用的云平台上内置的那些”自带选项”。&lt;/p&gt;

&lt;p&gt;芯片层的制约则更为根本，却往往被低估。独立AI服务商在算力这件事上，永远处于被动位置，没有自研芯片的话语权，就意味着无法主动控制模型训练和推理的成本曲线。当AWS可以用Trainium把推理成本压到极低、当Google可以用TPU给Vertex AI上的客户提供有竞争力的定价，独立服务商的可用定价空间就会相应收窄。这不是运营效率问题，不是工程水平问题，而是一个结构性的成本劣势，它由产业链的位置决定，而不是由努力程度决定。&lt;/p&gt;

&lt;p&gt;回到我们的虚构主线：那家年GMV约五十亿的中型电商，2023年接入了第一家独立AI服务商，做的是智能客服。这家服务商的方案是调用第三方大模型API，跑在自己托管的服务器上，向电商收取按月结算的服务费。每一次续约谈判，对方的技术团队都会提出同一个问题：为什么不直接用AWS Bedrock？这家电商的全套基础设施已经在AWS上，IAM权限体系、VPC网络配置、合规审计日志，全部打通。引入这个独立客服AI，意味着要在这套体系之外新开一个安全边界，要让IT部门额外维护一套访问控制策略，要在合规审计中新增一个数据流出口。服务商的回答永远是”我们的效果更好”，但随着AWS Bedrock上可调用的模型种类越来越多、质量越来越高，”效果更好”这个论据在客户的IT和安全团队面前，分量一次比一次轻。&lt;/p&gt;

&lt;p&gt;全栈化不是一个正在发生的趋势，而是一个已经完成的现实。在这个竞争结构里，独立AI服务商的位置越来越像一个夹层，上方是有芯片和平台的大厂，下方是有数据和场景的客户。夹层的生存空间，正在被系统性地压缩。&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;数据和ai必须一体化但大多数ai服务商两手都不硬&quot;&gt;数据和AI必须一体化，但大多数AI服务商两手都不硬&lt;/h2&gt;
&lt;hr /&gt;
&lt;!-- 配图：待定 --&gt;
&lt;p&gt;&lt;img src=&quot;/assets/ai_saas_2.webp&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;如果说全栈化是从上方压下来的力量，那么数据一体化就是从下方撑不起来的致命伤。&lt;/p&gt;

&lt;p&gt;大模型的基础能力，正在以惊人的速度趋于同质化。斯坦福大学AI指数2025年的数据显示，在主要的行业基准测试上，最好的开源模型与最好的闭源商业模型之间的性能差距，在一年之内从8%收窄到了1.7%。这意味着什么？意味着”我们有更好的AI模型”，正在成为一个越来越难以维持的差异化主张。当开源模型的能力已经接近顶级商业模型，当推理成本持续下降让更多玩家能够平等地接入高质量的AI能力，企业客户在选型时的问题，已经从”哪家的模型更好”变成了”谁能把AI和我自己的数据结合得更紧密”。而这，对独立AI服务商来说，是一个结构性的坏消息，因为客户最有价值的数据，从来不在服务商手里。&lt;/p&gt;

&lt;p&gt;Databricks和Snowflake的战略演进，揭示了这场竞争的真实逻辑。Databricks以十三亿美元收购了MosaicML，并将其整合演变为完整的Mosaic AI套件；随后又以约十亿美元收购了数据库创业公司Neon，着手建设其称之为Lakebase的新一代数据基础设施。Databricks的目标不是”做一个更好的AI服务”，而是让企业能够在同一个平台上管理数据、构建模型、部署AI Agent，数据和AI在同一个屋檐下运转，不需要任何数据搬运，不需要任何中间层。Snowflake的路径与此异曲同工：他们把AI能力直接内嵌进数据仓库，推出了Cortex AI，用户不需要把数据搬出数仓就能直接跑模型推理、构建RAG应用、生成报表摘要。两条路，一个核心判断：&lt;strong&gt;数据在哪里，AI就得在哪里。&lt;/strong&gt; 能同时掌控数据和AI的平台，拥有一种独立AI服务商在结构上永远无法复制的优势，不是技术优势，而是位置优势。&lt;/p&gt;

&lt;p&gt;对于独立AI服务商来说，数据这件事构成了一个几乎无解的困境。让客户把数据搬出来给你用，是一件充满摩擦的事情：安全审查要走，合规评估要做，数据脱敏要处理，格式转换要完成，跨系统的接口联调要反复打磨。这套流程走下来，短则两周，长则数月。但更根本的问题在于：即便客户愿意配合完成这一切，数据依然在客户侧，并没有真正流入服务商的体系。你帮一百家企业客户分别处理了他们的业务数据，积累了什么？积累了工程能力，积累了案例经验，但数据本身（那些隐藏在一行行交易记录里的业务规律、那些在客服对话里沉淀下来的用户意图模式）全部留在了客户自己的系统里。服务商的数据飞轮，停着。而那些同时持有数据和AI能力的平台，飞轮一圈一圈地转。&lt;/p&gt;

&lt;p&gt;回到那家中型电商：他们的个性化推荐服务商，每隔三个月就需要做一次模型更新。每次更新，都需要电商方配合做一次数据导出，字段映射要重新确认，时间窗口要重新对齐，隐私数据要重新脱敏，整套流程走下来，差不多要耗费两个星期。就在这套流程第五次启动的时候，电商的数据工程团队发现了一件事：Snowflake的Cortex AI已经可以直接在数据仓库里运行推荐逻辑。效果差一些，召回率大概低了10%到15%，但数据完全不需要出数仓，不需要任何安全审批，不需要任何跨部门协调。这是一场不公平的竞争，推荐服务商比拼的是模型质量，而Cortex AI比拼的是摩擦成本为零。推荐服务商最终输掉的，不是算法，是数据的距离。&lt;/p&gt;

&lt;p&gt;数据平台和AI能力的一体化，已经不是客户选型时的加分项，而是一道越来越高的门槛。独立AI服务商如果解决不了数据接入和持续沉淀的问题，就永远只是在给别人的飞轮添砖加瓦，自己的飞轮始终停着不动。&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;云服务商的引力场让独立ai服务商的获客越来越难&quot;&gt;云服务商的引力场，让独立AI服务商的获客越来越难&lt;/h2&gt;
&lt;hr /&gt;
&lt;!-- 配图：待定 --&gt;
&lt;p&gt;&lt;img src=&quot;/assets/ai_saas_3.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;即使一家独立AI服务商在技术上做到了足够好，它还要面对一个更为隐蔽、也更为强大的力量：云服务商构建出来的引力场。&lt;/p&gt;

&lt;p&gt;企业和主力云服务商之间的绑定，是一种三层叠加的结构性锁定。第一层是技术绑定：企业的IAM权限体系、VPC网络架构、日志审计和合规体系，都已经深度集成在主力云平台上。引入一个独立的AI服务商，意味着IT团队要在已有的安全体系之外单独维护一套新的访问控制和数据流出策略，每多一个独立服务商，就多一个需要管理的安全边界。技术团队的本能反应，是能不引入就不引入。第二层是数据绑定：企业核心数据往往已经落在云上的数据仓库或数据湖里，将这些数据搬出去交给外部服务商处理，本身就附带着安全风险和合规成本。在数据本就在云上的前提下，使用云平台内置的AI能力，是阻力最小的路径。第三层，也是最被低估的一层，是商务绑定：AWS Marketplace的积分返还机制、Azure企业协议的消费折扣、GCP的消费承诺激励，这些商务安排让CFO在面对”差不多好用”的两个方案时，天然倾向于选择能并入现有云账单的那一个。独立AI服务商在这三层绑定面前，要证明的不只是自己的AI更好，而是提供一个值得客户为此额外增加系统复杂度和商务成本的充分理由。&lt;/p&gt;

&lt;p&gt;2026年4月发生的一件事，可以作为这个逻辑的最直接注脚：OpenAI宣布正式大规模入驻AWS Bedrock，就此结束了与Azure的独家分发关系。这个事件的商业意义远比表面上看到的更深。OpenAI和Azure的独家合作，是这几年里科技行业最被频繁引用的战略绑定案例之一，微软的巨额投资，换来的是OpenAI在企业市场的优先分发权。但即便是OpenAI，最终也不得不选择进入AWS的生态体系，才能系统性地触达那些主要业务跑在AWS上的企业客户。Azure独家优势能维持如此之久，靠的并不是技术上的锁定，而是大量企业客户对整个Microsoft生态的深度依赖（M365、Active Directory、Teams、合规体系）这些东西的存在，让Azure账号成了那些客户事实上的企业身份中枢。这是云引力场最直接的一次自我证明：连OpenAI都必须来，何况其他人。&lt;/p&gt;

&lt;p&gt;那家中型电商的供应链预测服务商，遭遇了一次让人沮丧的续约谈判。不是效果出了问题，过去一年，服务商交付的预测准确率稳定在客户预期范围内，双方关系也算融洽。谈判卡住，是因为这家电商刚刚签署了一份三年期的GCP消费承诺协议，为此拿到了一笔可观的折扣返还。财务部门明确要求，所有AI相关的新增支出，都应该尽可能地并入GCP账单框架来处理，以便最大化消费承诺的利用率。服务商无法提供GCP Marketplace的采购通道，独立账单意味着这笔支出游离于承诺框架之外，需要额外的预算审批流程，也无法享受到任何折扣。谈判的结果是：合同被压缩到了一个刚好维持合作关系的最小规模，续约金额不到上一年的四成。没有人说服务商做得不好，但没有人帮它说话。&lt;/p&gt;

&lt;p&gt;独立AI服务商在市场里真正要对抗的，不只是同类竞争者，而是客户云账单上那些”已有选项”。那些选项不需要额外的预算审批，不需要额外的安全评审，不需要额外的合规报告，它们只需要被选中。这是一场在起跑线上就已经不对等的竞争。&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;ai-coding正在瓦解需要ai服务的最后一批场景&quot;&gt;AI Coding正在瓦解”需要AI服务”的最后一批场景&lt;/h2&gt;
&lt;hr /&gt;
&lt;!-- 配图：待定 --&gt;
&lt;p&gt;&lt;img src=&quot;/assets/ai_saas_4.png&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;前三节讨论的压力，主要来自外部结构：云平台的垂直整合、数据平台的一体化、云生态的商务引力场。但还有一股力量从更意想不到的方向涌来，它正在侵蚀的是独立AI服务商最后的那些立足点。&lt;/p&gt;

&lt;p&gt;在2025年之前，企业购买AI服务有一个逻辑上成立的理由：自建成本太高。没有足够的AI工程师，没有时间，没有基础设施，没有处理数据管道和模型部署的经验，这些都是真实的摩擦，让”采购现成的AI服务”成为一个理性选择。这个逻辑在2025年开始以肉眼可见的速度瓦解。Cursor、Claude Code、GitHub Copilot这一代AI编程工具，已经让一个普通的工程师团队能够在数周之内构建出过去需要数月才能交付的AI功能。斯坦福AI指数的数据在这里提供了一个关键数字：达到GPT-3.5水平的推理成本，在两年间下降了整整两百八十倍。这不是渐进式的改善，这是一个量变触发质变的拐点，”自建AI能力”这件事的经济账，正在以惊人的速度向有利于自建的方向倾斜。Stripe的工程师团队大规模部署Cursor之后，单位工程师的生产效率提升所节省下来的成本，已经超过了公司过去采购若干外部AI服务工具的总支出。对于Stripe这样的公司来说，AI工具不再是成本项，而是成本节约项。&lt;/p&gt;

&lt;p&gt;这场工具革命带来的影响，不只是”现在能自己写了”这么简单。更深层的变化在于认知层面。当工程师们开始用Cursor和Claude Code大量构建AI功能，他们对AI系统的组成有了直接的感知：模型调用是什么、RAG是怎么工作的、Embedding如何生成、提示工程能解决什么问题又解决不了什么问题。这些知识过去存在于专门的AI团队或专门的AI服务商那里，现在已经分散到了每一个日常使用AI编程工具的工程师手中。随之而来的是：客户对独立AI服务商的提案，开始用一种完全不同的眼光来审视。一个方案里有多少是真正不可替代的核心能力，有多少只是”我们也可以自己写一个”的组合拼装，这两者之间的界限，在有AI编程工具的工程师团队面前，越来越透明。独立AI服务商原本赖以存在的信息不对称，正在快速消失。&lt;/p&gt;

&lt;p&gt;现在，可以回到引言里留下的那个悬念了。2024年，Klarna轰动业界的AI转型宣言，实际发生了什么？&lt;/p&gt;

&lt;p&gt;事实是：Klarna并没有用AI替代SaaS。他们用更便宜的SaaS替换了更贵的SaaS。Workday被替换成了Deel，CRM功能被拆分成若干更轻量的第三方工具，整个过程中AI扮演的角色，更多是帮助完成迁移过程中的数据清洗和流程自动化，而不是真正取代了企业软件的核心功能。那个被广泛引用的”700名客服被AI替代”的说法，其真实情况是：Klarna在这一时期大幅缩减了客服团队的规模，AI Bot承接了相当一部分标准化的客服查询，但主要驱动因素是业务收缩和组织重构，并没有实现全面替代。到了2025年初，CEO Siemiatkowski公开承认，激进的AI替代策略导致了部分服务环节质量的明显下滑，公司开始着手重新招募客服人员，尤其是需要处理复杂诉求的高级客服岗位。Klarna的故事，是一个典型的”先宣布、后反思”的企业AI转型案例。它揭示的真实教训不是”AI失败了”，而是：&lt;strong&gt;即使是最激进的AI自建方，在这场转型的终点，仍然是在使用SaaS，只不过换成了更轻、更便宜的那种。&lt;/strong&gt; 独立AI服务商在这整个过程里，既不是被替换的Salesforce，也不是胜出的AI自建方，他们是旁观者。&lt;/p&gt;

&lt;p&gt;那家中型电商的技术团队，在公司全员推行Claude Code之后，有一个项目经理做了一个决定：让两名工程师花三周时间，用AI编程工具尝试复刻智能客服服务商的核心功能。三周后，他们完成了大约七成的功能覆盖。更关键的是，这个自建版本可以直接接公司内部的CRM数据库和订单系统，省去了所有的数据导出协议、安全审批流程和跨系统对接工作。自建版本的效果比服务商方案差一些（在处理复杂退换货诉求时的准确率大约低了15%）但这个差距在业务团队眼里，已经不再值得为之支付每年数十万元的服务费。最后一个AI服务商的续约合同，就此被搁置。&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;能活下来的都找到了逃逸路径&quot;&gt;能活下来的，都找到了逃逸路径&lt;/h2&gt;
&lt;hr /&gt;
&lt;!-- 配图：待定 --&gt;
&lt;p&gt;&lt;img src=&quot;/assets/ai_saas_5.webp&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;读到这里，可能有人会问：难道所有的独立AI服务公司都注定失败？&lt;/p&gt;

&lt;p&gt;不是。但能真正做成的，无一例外都已经不再是”纯粹的AI服务商”了。&lt;/p&gt;

&lt;p&gt;仔细看真正做成规模的”AI服务”公司，有一个隐而不显的共同特征：他们最终卖的不是AI能力本身，而是AI能力打开了门之后，沉淀下来的那些无法轻易替代的东西。这种不可替代性，沿着两条截然不同的路径构建：要么向上整合进基础设施层，让自己成为AI时代的数据或计算管道；要么向下扎入垂直场景，让自己的工作流嵌入变成客户的运营依赖。两条路的终点，都不是”AI服务商”，而是”基础设施”或”垂直平台”。&lt;/p&gt;

&lt;p&gt;Databricks走的是第一条路。从最初的Spark数据处理平台，到统一数据和AI的Lakehouse架构，再到通过收购MosaicML和Neon构建起AI训练和实时数据应用的完整基础设施，Databricks每一次战略演进，都在把自己的护城河从”更好的AI”转向”不可或缺的数据基础设施”。今天的企业客户用Databricks，不只是因为Databricks的AI能力有多强，而是因为他们的业务数据管道、特征工程流程、实时推理部署，全部已经跑在Databricks上。换掉它的成本，不是技术成本，而是组织重构成本。&lt;/p&gt;

&lt;p&gt;Scale AI的路径同样值得细看。这家公司起家于AI训练数据的人工标注，在最初几年里做的是一门相对传统的劳动密集型生意。但随着大模型对高质量训练数据的需求急剧上升，Scale AI把自己从”标注服务商”转型成了”训练数据基础设施的核心供应商”：他们卖的不再是人工标注能力，而是一套端到端的数据管道和质量保障体系，服务于美国国防部、各大AI实验室和顶级科技公司。在这个新的定位里，Scale AI不是AI服务商，而是AI训练体系的必要条件。&lt;/p&gt;

&lt;p&gt;Harvey在法律AI领域做到了另一种深度。Harvey的产品本质上是一个面向律所的AI助手，但他们真正在构建的是一套深度嵌入律所工作流的案件知识系统。每一个律所接入Harvey，Harvey就开始积累这家律所在案件类型、法律论证策略、文件格式标准上的专有知识；与此同时，Harvey持有的跨律所的案件数据和法律文本积累，又反过来让每一个律所的使用体验越来越好。Harvey的竞争对手不是另一家法律AI公司，而是律所自己的IT团队，而律所的IT团队在未来相当长的时间里，几乎不可能复刻这套系统。&lt;/p&gt;

&lt;p&gt;Abridge在医疗领域构建的是一道双重门槛。首先是合规门槛：医疗AI需要HIPAA合规认证、临床验证流程和医疗机构采购审批，这是一道任何创业公司都无法快速跳过的监管壁垒。其次是数据门槛：Abridge与医院系统的深度集成，让临床数据以授权方式持续流入其训练管道，形成了一个随时间自我加强的医疗数据飞轮。当这两道门槛叠加在一起，Abridge的护城河就不再只是”更好的医疗AI”，而是”要换掉它，你需要同时解决合规重认证、数据迁移和系统重集成三个问题”。&lt;/p&gt;

&lt;p&gt;这四家公司的共同点，现在应该已经清晰：AI能力是入口，不是终点。他们用AI能力打开了客户关系、赢得了第一份合同，然后把竞争的焦点迅速转移到了数据控制权、工作流嵌入深度、或者行业合规壁垒上。在他们各自的商业模式里，”我们的AI更好”是一个次要命题，”换掉我们的成本极高”才是核心命题。&lt;/p&gt;

&lt;hr /&gt;

&lt;h2 id=&quot;结论ai能力是入场券不是护城河&quot;&gt;结论：AI能力是入场券，不是护城河&lt;/h2&gt;
&lt;hr /&gt;
&lt;!-- 配图：待定 --&gt;

&lt;p&gt;两年后，那家中型电商的AI技术栈长这样：主云平台是GCP，核心数据仓库是BigQuery，AI分析和推荐功能跑在Gemini的原生接口上；工程团队用Claude Code自建了若干定制化的功能模块，其中包括一个接公司内部物流系统的供应链异常预警工具，以及那个三周复刻出来的客服助手。整套体系的运营成本，比两年前接入三家独立AI服务商时低了大约四成，功能覆盖反而更广。三家独立AI服务商，一个都没有留下。&lt;/p&gt;

&lt;p&gt;这不是一个孤立的案例，而是一个正在大规模复制的选型结果。从北美到亚洲，从金融服务到零售，从中型企业到大型集团，类似的故事正在无数家公司的IT预算讨论里重演。&lt;/p&gt;

&lt;p&gt;Klarna的故事，在这里有了它真正的意义。那个”替代了700名客服”的OpenAI Bot，确实还在Klarna的技术栈里运行着。但它是OpenAI的产品，通过OpenAI的API提供服务，计入OpenAI的营收，沉淀在OpenAI的规模优势里。没有任何一家独立AI服务商从Klarna的AI转型中获益。Klarna的教训不是”AI服务不好用”，而是：当AI能力本身不再是稀缺资源的时候，能留存下来的只有那些和业务流程、数据资产真正深度绑定的部分：而这些绑定，最终发生在云平台、数据平台、或者垂直场景深度整合者那里，而不是中间层的独立AI服务商那里。&lt;/p&gt;

&lt;p&gt;把AI当服务卖，正在成为一个越来越难以独立成立的商业逻辑。这不是一个技术判断，而是一个结构判断：AI产业正在把价值系统性地重新分配给芯片层、云平台层、以及垂直场景的深度整合者。夹在中间的独立AI服务商，正在被从四个方向同时挤压：全栈平台带来的引力、数据一体化带来的壁垒、云生态商务机制带来的价格扭曲、以及AI Coding工具带来的自建潮。这四个力量不是依次出现的，而是同时在场的。&lt;/p&gt;

&lt;p&gt;不是AI这门生意不好做。AI相关的机会，在可见的未来里只会越来越大。但”AI as a Service”这个位置（把AI能力本身作为核心产品包装起来卖给企业客户的商业模式）正在失去它存在的理由。能活下来的，都已经用AI做了别的事。&lt;/p&gt;

&lt;hr /&gt;
</content>
 </entry>
 
 <entry>
   <title>如何搭建端到端 AI 团队</title>
   <link href="http://column.hongliangjie.com/%E7%AE%A1%E7%90%86/2026/04/25/ai_end-to-end/"/>
   <updated>2026-04-25T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E7%AE%A1%E7%90%86/2026/04/25/ai_end-to-end</id>
   <content type="html">&lt;p&gt;过去十年，中国几乎每一家头部互联网公司都建过一个 AI 研究院，然后又以各自不同的方式，悄悄地把它拆掉了。这不是偶然。研究和产品之间有一道结构性的鸿沟，单靠招来顶级人才填不平它。这篇文章试图讲清楚这道鸿沟从哪里来，以及什么样的团队结构能真正跨越它。&lt;/p&gt;

&lt;h2 id=&quot;引言打破全栈的错觉&quot;&gt;引言：打破”全栈”的错觉&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/ai_endtoend_lab.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;腾讯 AI Lab 是最典型的例子。2016 年成立，翌年从百度挖来学术大牛张潼出任主任，50 余位 AI 科学家加上 200 名工程师，阵容豪华。但不到两年，张潼以”回归学界”为由离职。继任者张正友接手，创始成员姚星后来也相继出走，整个 AI Lab 在 2026 年 3 月以”撤销”告终。&lt;/p&gt;

&lt;p&gt;为什么？问题不出在人身上。张潼的学术地位毋庸置疑，团队的技术能力也有目共睹。问题出在结构上：研究院的成果要进入产品，需要经过漫长的产品化链条。而这条链条中，有一道几乎没人能跨过的鸿沟。研究院能完成从立项到发论文的全部动作，但产品化那一步始终落不了地。”过去很长一段时间，AI Lab 的人员也感觉比较模糊”——这句话道出了真正的病灶：不是能力模糊，是方向模糊，是定位模糊，是研究与产品之间的连接，从一开始就没有建起来。&lt;/p&gt;

&lt;p&gt;百度更早一步演示了同一个剧本。吴恩达以首席科学家身份主持”百度大脑”计划三年后出走，张潼本人也是从那一轮离职潮中流出的。两家公司、两批顶级人才、两个几乎相同的结局。&lt;/p&gt;

&lt;p&gt;但如果你觉得这只是中国互联网公司特有的病，Yann LeCun 的故事应该能打消这个念头。&lt;/p&gt;

&lt;p&gt;2013 年，LeCun 加入 Meta，亲手创立了 FAIR（基础人工智能研究实验室），把它建成全球顶尖的 AI 学术机构之一。此后十二年，FAIR 发表了大量奠基性论文，吸引了全球最优秀的 AI 研究者。从外部看，这是硅谷版的”研究院成功故事”。&lt;/p&gt;

&lt;p&gt;但 FAIR 内部的重力，一直在悄悄改变方向。&lt;/p&gt;

&lt;p&gt;2022 年，Meta 全面转向元宇宙，FAIR 被并入 Reality Labs。两年后又被划归产品部门，与 GenAI 团队共同推进产品化工作。原先承诺的自由研究氛围，被自上而下的项目目标与 KPI 所取代。矛盾在 2025 年彻底激化：扎克伯格任命 Alexandr Wang 主导新的”超级智能”部门，主打激进的 LLM 产品化路线。新政策规定，FAIR 研究人员发表任何论文之前，必须先提交给新部门审查；如果该研究被认为具有”重大商业价值”，论文将被禁止发表，研究者将被要求先帮助将成果在 Meta 产品中落地——之后才能回归日常研究。&lt;/p&gt;

&lt;p&gt;这道命令，彻底终结了 FAIR 作为纯粹学术机构的属性。&lt;/p&gt;

&lt;p&gt;2025 年 11 月，图灵奖得主、Meta AI 首席科学家 LeCun 正式宣布离开工作了 12 年的 Meta。他在巴黎创立的 AMI Labs 于 2026 年 1 月启动，种子轮融资超过 10 亿美元，目标是构建”世界模型”——让 AI 从理解真实物理世界入手，而非仅仅预测下一个词。&lt;/p&gt;

&lt;hr /&gt;

&lt;p&gt;LeCun 的离开和张潼的离开，表面上看是两个人做了个人职业选择。但背后的结构几乎一模一样：一个顶级研究者被请进来，被赋予”做出伟大研究”的使命；然后产品压力进来，研究开始服务于季度目标；研究者的议程被边缘化；最终，人走了，研究院或关掉，或变成另一种东西。&lt;/p&gt;

&lt;p&gt;这个故事每隔几年就会在某家大公司里重演一次，而且几乎每一次，都以研究院的失败告终。&lt;/p&gt;

&lt;p&gt;失败的根本不是人，而是一种结构性的错误假设：以为把顶级研究者放进公司，研究就能自然流向产品。&lt;/p&gt;

&lt;p&gt;它从来没有自然发生过。&lt;/p&gt;

&lt;p&gt;研究之所以无法自然流向产品，是因为两者之间隔着的不是一堵墙，而是两套完全不同的时间观、语言体系和成功标准。研究员用 benchmark 说话，产品团队用 DAU 说话；研究的探索周期是以季度计，产品的迭代 sprint 是以两周计；研究员眼中的”突破”，在产品经理看来可能意味着”还要再等六个月”。&lt;/p&gt;

&lt;p&gt;这不是沟通问题。沟通问题可以靠周会解决。这是一个结构问题——两种逻辑从起点就在往不同方向运行，没有任何机制让它们在中途汇合。&lt;/p&gt;

&lt;p&gt;所谓”全栈 AI 团队”的错觉，正是在这里诞生的。一个团队同时拥有研究员和工程师，就以为自己拥有了端到端的能力。但如果研究和产品之间没有真正的信息回路，这个团队不过是两种孤立能力的物理叠加，而不是一个有机的整体。&lt;/p&gt;

&lt;p&gt;真正的端到端，不是”什么都有”，而是”让研究和产品互相定义”。&lt;/p&gt;

&lt;h2 id=&quot;两种残缺的团队&quot;&gt;两种残缺的团队&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/ai_endtoend_gap.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;h3 id=&quot;同一个失败时刻&quot;&gt;同一个失败时刻&lt;/h3&gt;

&lt;p&gt;某家为银行提供 AI 服务的公司，核心产品是一套面向信贷审批的智能辅助系统。客户经理上传借款人的财务材料，系统自动分析偿债能力、识别潜在风险信号、生成结构化的审批建议。产品上线将近一年，几家城商行已经在用，续约率不错。&lt;/p&gt;

&lt;p&gt;然后一家合作银行的风控负责人发来了一条消息。&lt;/p&gt;

&lt;p&gt;他们遇到了一个问题：一批小微企业主的贷款申请，系统一律给出了”风险偏高，建议谨慎”的结论。但风控团队人工复核后发现，其中相当一部分其实是优质客户——他们的财务报表看起来不稳定，是因为这类客户普遍存在季节性现金流波动，旺季回款集中、淡季账面难看，这是行业特性，不是风险信号。&lt;/p&gt;

&lt;p&gt;系统没有识别出这个模式。它看到的是低谷期的现金流数字，然后给出了它认为合理的结论。&lt;/p&gt;

&lt;p&gt;风控负责人在消息末尾加了一句：”这类客户我们行本来是重点扶持方向，但系统一直在误伤他们。”&lt;/p&gt;

&lt;p&gt;产品经理把这条反馈记在了表格里，标注为”高优先级”。&lt;/p&gt;

&lt;p&gt;然后，这个失败时刻在两种不同的团队结构里，走向了两种截然不同的命运。&lt;/p&gt;

&lt;h3 id=&quot;research-侧失败样本永远到不了研究员手中&quot;&gt;Research 侧：失败样本永远到不了研究员手中&lt;/h3&gt;

&lt;p&gt;在纯 Research 导向的团队里，这条反馈的旅程大概是这样的：&lt;/p&gt;

&lt;p&gt;产品经理把它整理进月度用户反馈汇总。汇总发给产品负责人，产品负责人在下周的产品会上提了一句”小微信贷场景有个准确率的问题”。这句话被记进会议纪要，然后沉入了协作文档的历史版本。&lt;/p&gt;

&lt;p&gt;研究员们不在那个会上。他们正在处理另一件事：团队在推进一个信用风险建模的新方向，基于公开的上市公司财报数据训练了一个改进版模型，在标准信用评估 benchmark 上的 AUC 比上一版提升了 0.03，正在整理结果准备投稿。&lt;/p&gt;

&lt;p&gt;没有人刻意隐瞒什么。只是那家银行的反馈，和研究员正在做的事情，活在两个完全不同的世界里。&lt;/p&gt;

&lt;p&gt;产品里真实发生的失败，携带着极其珍贵的信息：系统在哪类客群上出现了系统性偏差？偏差的根源是特征工程的问题，还是训练数据本身的分布偏移？季节性现金流这个模式，在现有特征体系里根本没有被表达，还是被表达了但权重设置有问题？这些问题，只有拿到真实 badcase 的研究员才能回答。&lt;/p&gt;

&lt;p&gt;但 badcase 停在 PM 的表格里。研究员永远看不到它。&lt;/p&gt;

&lt;p&gt;他们的论文顺利投出去了，benchmark 指标漂亮。产品里那批小微企业主，在下一个版本里依然被误伤。&lt;/p&gt;

&lt;h3 id=&quot;dev-侧只能在已知选项里穷举&quot;&gt;Dev 侧：只能在已知选项里穷举&lt;/h3&gt;

&lt;p&gt;在纯 Dev 导向的团队里，同一条反馈的旅程是另一种样子。&lt;/p&gt;

&lt;p&gt;工程师拿到了这个问题。他们动手很快：先把那批被误判客户的财务数据单独拉出来看，发现现金流波动确实很大，于是在 prompt 里加了一条引导：”如果借款人属于季节性行业，请结合全年平均现金流而非单月数据进行判断”。重新跑了一遍，部分案例的结论有所改善。接着又在特征层面做了调整，加入了现金流的季度环比标准差作为辅助指标，测试集表现进一步提升。&lt;/p&gt;

&lt;p&gt;问题表面上被压住了一些。&lt;/p&gt;

&lt;p&gt;但没有人知道这个方案的边界在哪里。加进去的那个季度环比指标，是拍脑袋选的，还是真的捕捉到了季节性波动的本质？prompt 里那句行业引导，覆盖了哪些行业、漏掉了哪些行业，有没有人系统梳理过？工程师们知道怎么调，但调完之后心里并没有底——因为从一开始就没有人真正搞清楚，这个偏差是怎么产生的。&lt;/p&gt;

&lt;p&gt;解空间的边界就在那里。在边界以内，工程师可以穷举所有已知的调优手段；但边界之外的那个解——比如重新设计针对非标准财务结构的特征体系，或者引入行业基准数据对齐客群分布——没有人看见，也没有人有能力去够到它。&lt;/p&gt;

&lt;p&gt;下一个季度，类似的客诉又来了，这次换了一类客群：个体工商户，收入流水和个人账户混在一起，系统同样给出了不准的结论。工程师又开始了新一轮穷举。&lt;/p&gt;

&lt;h3 id=&quot;合并收口断掉的是同一条信息链&quot;&gt;合并收口：断掉的是同一条信息链&lt;/h3&gt;

&lt;p&gt;两个团队，两种失败，看起来性质不同。Research 侧的问题是”脱离现实”，Dev 侧的问题是”缺乏纵深”。但如果沿着信息流动的路径往回追，会发现断掉的是同一条链：&lt;/p&gt;

&lt;p&gt;产品里的真实失败，没有变成研究的下一个问题。&lt;/p&gt;

&lt;p&gt;Research 不知道产品在哪里卡住——那条银行反馈永远停在 PM 表格里，没有流向研究员的问题清单。Dev 不知道卡住的地方其实有解——季节性现金流的行业分布是可以被系统建模的，只是需要研究侧的能力才能触碰到这个问题。&lt;/p&gt;

&lt;p&gt;这不是能力问题。研究员有能力处理这个问题，工程师也有能力实现解决方案。问题是，两者之间缺少一条让知识双向流动的通道。&lt;/p&gt;

&lt;p&gt;那么，什么样的团队结构，能让这条通道真正存在？&lt;/p&gt;

&lt;h2 id=&quot;联动的本质知识飞轮而非流水线&quot;&gt;联动的本质——知识飞轮而非流水线&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/ai_endtoend_cycle.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;回到那个失败时刻。同一条银行反馈，同一批被误判的小微企业主，但这次换一种团队结构。&lt;/p&gt;

&lt;p&gt;结构不同，命运不同。&lt;/p&gt;

&lt;h3 id=&quot;飞轮转一圈&quot;&gt;飞轮转一圈&lt;/h3&gt;

&lt;p&gt;反馈进来的第三天，研究员看到了它。&lt;/p&gt;

&lt;p&gt;不是因为有人特意转达，而是因为这个团队有一套固定机制：所有被标记为”高优先级”的产品 badcase，会在 72 小时内同步到研究侧的问题看板，附上原始数据和客户描述，不做任何过滤和摘要。研究员可以直接认领，也可以标注”暂不处理”并说明原因。&lt;/p&gt;

&lt;p&gt;一位做风险建模的研究员认领了这个问题。&lt;/p&gt;

&lt;p&gt;她拿到数据之后，第一步不是跑模型，而是看分布。把那批被误判客户的月度现金流数据画出来，模式立刻出现了：餐饮、零售、农资——这三个行业的客户，全都呈现出高度一致的季节性波动曲线，旺季流入是淡季的三到五倍。系统用来判断偿债能力的核心特征，是近三个月的平均现金流，恰好截取在淡季，所以一律报警。&lt;/p&gt;

&lt;p&gt;这不是噪声，这是一个有规律的系统性偏差。她提出了一个可检验的假设：&lt;strong&gt;如果在特征体系里引入行业基准对齐，用同行业同规模的客群中位数做相对化处理，误判率应该会显著下降。&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;假设提出之后，她没有等实验跑完再告诉工程师。实验进行到第三天，她把一个未完成的中间结论发给了工程师：行业对齐在餐饮类客户上效果非常明显，但在农资类客户上改善有限——原因未知，可能是农资客户的季节性更复杂，也可能是样本量不够。&lt;/p&gt;

&lt;p&gt;工程师拿到这个结论，当天就把餐饮类的行业对齐逻辑部署进了测试环境，针对新进来的同类申请做 A/B 分流。&lt;/p&gt;

&lt;p&gt;两周后，测试结论回来了：餐饮类误判率下降了 41%，但有一个意外发现——系统在处理”餐饮+电商双渠道”的客户时，行业对齐反而让结论变差了，因为这类客户的收入结构本身就是混合的，单一行业基准无法对齐。&lt;/p&gt;

&lt;p&gt;这个发现改变了研究员对问题的分类方式。她意识到，问题的核心不是”季节性”，而是”收入结构的同质性”——季节性只是其中一种表现形式，多渠道混合收入是另一种，还有更多种类等待被识别。&lt;/p&gt;

&lt;p&gt;飞轮完成了一圈。下一圈，从”收入结构分类”这个新问题出发。&lt;/p&gt;

&lt;h3 id=&quot;飞轮为什么经常卡死&quot;&gt;飞轮为什么经常卡死&lt;/h3&gt;

&lt;p&gt;上面那个故事，现实中并不常见。它之所以能转起来，依赖三个条件同时成立——而这三个条件，在大多数团队里，至少有一个是缺失的。&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;第一，信息没有流动的物理通道。&lt;/strong&gt; badcase 停在 PM 的表格里，研究员永远看不到真实失败样本。这不是态度问题，而是机制问题。产品侧和研究侧的信息系统往往是两套独立的工具链：Jira 上的 bug ticket、飞书里的用户反馈文档、研究员的 Notion 实验记录——这三者之间没有任何自动的连接。信息要流动，需要有人手动搬运，而手动搬运这件事，在没有明确归属的情况下，总是会被优先级更高的事情挤掉。&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;第二，时间粒度不匹配。&lt;/strong&gt; 产品侧的节奏是两周一个 sprint，有明确的交付节点和验收标准。研究侧的探索周期是以月为单位，一个假设从提出到验证，快则三周，慢则三个月。两条时间轴永远错位：当研究员终于有了可用的中间结论，工程师那边早已进入了下一个 sprint，手头的优先级已经排满。结论等不来窗口，窗口等不来结论，飞轮卡在两个齿轮之间。&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;第三，语言不互通。&lt;/strong&gt; 研究员说”行业对齐之后 AUC 提升了 0.04”，工程师问”那误判率能降多少”，产品经理问”这个客群的通过率会变化吗”，风控负责人问”监管口径上怎么解释这个调整”。同一个实验结论，在四个角色眼里需要被翻译成四种语言。翻译的成本被低估了——它不只是措辞的问题，而是思维框架的问题。研究员习惯于在模型层面描述改进，产品团队习惯于在用户行为层面衡量价值，两者之间没有共同的度量衡，沟通就只能停留在表面。&lt;/p&gt;

&lt;h3 id=&quot;联动是什么&quot;&gt;联动是什么&lt;/h3&gt;

&lt;p&gt;联动不是让研究员参加产品周会，也不是让工程师抽空读论文。&lt;/p&gt;

&lt;p&gt;联动是一套让知识双向流动的基础设施：产品里的每一次真实失败，都有可能在 72 小时内出现在研究员的问题看板上；研究里的每一个可用的中间结论，都有可能在两周内进入产品的测试环境——不需要等论文发表，不需要等完整方案。&lt;/p&gt;

&lt;p&gt;它需要的不是更多沟通，而是三样东西：让失败样本自动流向研究侧的信息机制，让研究中间产物能快速进入产品测试的工程接口，以及一套让两侧都能读懂彼此结论的共同度量体系。&lt;/p&gt;

&lt;h2 id=&quot;联动需要三个共同&quot;&gt;联动需要三个”共同”&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/ai_endtoend_teamwork.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;飞轮能转起来，靠的不是人的自觉，而是结构的保障。具体来说，是三个层面的对齐——共同语言、共同目标、共同节奏。缺任何一个，飞轮都会在某个环节重新卡死。&lt;/p&gt;

&lt;h3 id=&quot;共同语言&quot;&gt;共同语言&lt;/h3&gt;

&lt;p&gt;研究员和工程师之间，有一道隐形的语言边界。越过这道边界，需要双向的努力。&lt;/p&gt;

&lt;p&gt;研究员需要理解产品运行的基本约束。P99 延迟意味着什么——如果一个新模型把推理时间从 200ms 拉到 800ms，它在信贷审批场景里几乎不可能上线，因为客户经理等不了；cost-per-token 意味着什么——一个需要调用十次模型才能给出结论的方案，即便准确率更高，在规模化部署时也可能让单笔成本超出业务可接受范围；fallback 逻辑意味着什么——当模型置信度低于阈值，系统会降级到规则引擎，研究员的改进如果只在高置信度样本上生效，实际覆盖率可能远比 benchmark 显示的低。&lt;/p&gt;

&lt;p&gt;这些不是工程细节，而是判断一个研究方向是否真的有产品价值的基本坐标。研究员如果不理解这些约束，提出的方案很可能在实验室里漂亮，进了产品就熄火。&lt;/p&gt;

&lt;p&gt;反过来，工程师需要能读懂实验结论的基本结构。一份 ablation study 在说什么——哪个组件被移除之后性能下降最多，意味着哪个设计选择是真正有效的；loss curve 在说什么——训练损失和验证损失的走势分叉，意味着模型在过拟合，继续训练没有意义；置信区间在说什么——一个”提升 3%”的结论如果置信区间跨越零点，它在统计上等于没有提升。&lt;/p&gt;

&lt;p&gt;不是要求工程师变成研究员。而是要求他们能识别一个结论是否可信，能问出”这个改进在我们的真实数据分布上验证过吗”这样的问题——而不是拿到一个漂亮数字就直接去排期。&lt;/p&gt;

&lt;p&gt;共同语言的建立，不靠培训课，靠的是长期在同一个问题上协作。研究员和工程师如果从来不坐在一起看同一份数据，语言边界就永远存在。&lt;/p&gt;

&lt;h3 id=&quot;共同目标&quot;&gt;共同目标&lt;/h3&gt;

&lt;p&gt;最容易制造割裂的，是度量体系的分裂。&lt;/p&gt;

&lt;p&gt;研究团队用 benchmark 说话：AUC、F1、BLEU、MMLU 分数。这些指标有其价值——它们是跨团队、跨时间可比较的标准化度量，能让研究进展有据可查。但它们和产品里真实发生的事情之间，往往隔着一层不透明的转换关系。AUC 提升 0.03，对应的是哪类客群的误判率下降，下降幅度够不够大到让银行愿意调整审批策略——这个问题，benchmark 本身回答不了。&lt;/p&gt;

&lt;p&gt;产品团队用业务指标说话：DAU、转化率、客诉率、续约率。这些指标捕捉的是用户行为的结果，但它们对模型改进极度不敏感——一个误判率下降 10% 的模型改进，在 DAU 曲线上可能完全看不出来，因为影响 DAU 的变量太多，信号被噪声淹没了。产品团队如果只看业务指标，很难判断一个研究方向是否值得投入。&lt;/p&gt;

&lt;p&gt;割裂的度量体系会制造一种奇怪的局面：研究员觉得自己一直在进步，产品团队觉得研究一直没有产出，双方都有数据支撑自己的判断，但两套数据描述的根本不是同一件事。&lt;/p&gt;

&lt;p&gt;打破这个局面，需要一套对齐的评估体系——不是把 benchmark 废掉，也不是把业务指标废掉，而是在两者之间建立一条可追溯的换算链：这个模型改进对应的是哪个子场景的准确率提升，这个准确率提升对应的是多少客诉减少，这个客诉减少对应的是多少续约率改善。链条不需要每次都走完，但它需要存在，让两侧的人在需要的时候能相互翻译。&lt;/p&gt;

&lt;p&gt;更重要的是，研究和产品需要共同认定某些”中间指标”作为双方都认可的短期锚点。在信贷审查场景里，这个中间指标可能是”特定客群的召回率”——它比 AUC 更接近真实业务问题，又比续约率更直接反映模型能力。当研究员说”召回率提升了 8 个点”，产品经理能直接理解这意味着什么，双方的对话才能真正发生在同一个频道里。&lt;/p&gt;

&lt;h3 id=&quot;共同节奏&quot;&gt;共同节奏&lt;/h3&gt;

&lt;p&gt;时间粒度的错位，是飞轮最常见的卡死位置。&lt;/p&gt;

&lt;p&gt;产品侧的 sprint 是两周，有固定的交付节点：功能上线、A/B 测试启动、数据回收、下一轮排期。节奏是刚性的，插入一个”等研究结论”的环节，意味着整条排期链都要推迟，这在大多数产品团队里是不可接受的。&lt;/p&gt;

&lt;p&gt;研究侧的探索没有固定节奏。一个假设从提出到验证，取决于数据获取的难度、实验设计的复杂程度、中间遇到的意外发现。给研究设定两周交付期，结果往往是：要么研究员硬凑一个不成熟的结论，要么两周到了什么都没有，工程师只能自己先填坑。&lt;/p&gt;

&lt;p&gt;解决这个错位，不是要求研究员按 sprint 交付，而是要重新定义”研究的交付物”是什么。&lt;/p&gt;

&lt;p&gt;研究的交付物不必是完整结论，可以是可用的中间结论。”行业对齐在餐饮类客户上有效，置信度足够高，可以进测试环境”——这是一个中间结论，不是最终答案，但它已经足够工程师在一个受控范围内部署和验证。中间结论的颗粒度更小，产出频率更高，能嵌入产品的迭代节奏，而不是横亘在两个 sprint 之间等待。&lt;/p&gt;

&lt;p&gt;与此同时，产品侧的 sprint 规划需要为”接收研究中间结论”预留接口。不是每个 sprint 都必须有研究输入，但 sprint 的设计需要有能力在两天内响应一个意外到来的中间结论——快速评估、决定是否部署进测试环境、安排数据回收。如果 sprint 排得密不透风，这个响应能力就不存在，研究结论来了也用不上。&lt;/p&gt;

&lt;p&gt;共同节奏的本质，是把研究的探索周期和产品的迭代周期，从两条平行时间轴，变成一套嵌套结构：产品的每个 sprint 是外层节拍，研究的中间结论是可以随时插入这个节拍的内层信号。两者不需要同频，但需要有接口。&lt;/p&gt;

&lt;h2 id=&quot;重新定义全栈-ai-团队&quot;&gt;重新定义”全栈 AI 团队”&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/ai_endtoend_deeplearning.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;回到最初那个问题：什么是真正的端到端 AI 团队？&lt;/p&gt;

&lt;p&gt;不是”什么都有”。不是同时雇了研究员和工程师，就拥有了端到端的能力。腾讯 AI Lab 雇了最好的研究员，Meta FAIR 建了全球顶尖的研究机构——他们都”什么都有”，但研究和产品之间的通道，从来没有真正打通过。&lt;/p&gt;

&lt;p&gt;真正的端到端，是让研究和产品互相定义。产品里的失败定义研究的下一个问题，研究的中间结论定义产品的下一个测试。这个循环持续运转，每转一圈，团队对自己所在领域的理解就深一层，竞争对手用相同的基础模型调出来的产品永远追不上这种积累。&lt;/p&gt;

&lt;p&gt;在 AI 时代，模型调用能力已经是商品。任何一个团队，花同样的钱，都能调用同样的基础模型。真正拉开差距的，是两件事：你的产品问题能不能变成你的研究优势，你的研究突破能不能第一时间变成你的产品差异。&lt;/p&gt;

&lt;p&gt;这两件事，都需要 Research 和 Development 之间有真正流动的知识回路。&lt;/p&gt;

&lt;p&gt;共同语言、共同目标、共同节奏——这三样东西建起来的不是一套管理制度，而是一个持续进化的学习系统。系统每运转一圈，积累的不只是模型参数，而是对真实业务问题的深层理解，是竞争对手很难在短时间内复制的认知壁垒。&lt;/p&gt;

&lt;p&gt;这才是在 AI 时代真正可持续的竞争优势。不是谁的模型更大，不是谁的工程师更多，而是谁的研究和产品之间，有一条真正跑通了的知识飞轮。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>《团队管理的五大障碍》总结</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0,%E7%AE%A1%E7%90%86/2025/08/16/five/"/>
   <updated>2025-08-16T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0,%E7%AE%A1%E7%90%86/2025/08/16/five</id>
   <content type="html">&lt;p&gt;技术管理常常被视为复杂而抽象，但最近读到的一本小书《团队管理的五大障碍》(The Five Dysfunctions of a Team)，却以清晰的框架和简明的结构，把管理拆解得非常务实。全书围绕五个核心主题展开：认识团队、帮助成长、设定清晰预期、有效沟通、构建韧性。更重要的是，作者将这些主题与团队发展的四个阶段——组建、风暴、成规、高效——对应起来，帮助我们精准判断团队所处的状态，并采取合适的管理手段。书中提供的技巧极具可操作性：从识别团队成员的核心需求，到如何在风暴期切换导师、教练、支持者的角色，再到建立清晰的愿景与沟通机制。在后文中，我会逐章拆解这些方法，供正在成长中的管理者参考。&lt;/p&gt;

&lt;h2 id=&quot;作者简介&quot;&gt;作者简介&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/five_patrick.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;作者Patrick Lencioni是美国商业管理畅销书作者，写了多达13本关于团队管理和运营的书籍。他最知名的作品就是本文要介绍的《团队管理的五大障碍》。Patrick目前担任Table Group的总裁，负责领导力、团队和咨询等工作。在Table Group之前，Patrick在Bain &amp;amp; Company、Oracle Corporation 和Sybase担任过工作。&lt;/p&gt;

&lt;h2 id=&quot;全书结构&quot;&gt;全书结构&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;《团队管理的五大障碍》(The Five Dysfunctions of a Team)非常短小精悍，分为以下这么五章内容。&lt;/p&gt;

&lt;p&gt;第一章，主要是讲如何认识你的团队，也就是书中讲的结识你的团队（Meet Your Team）。&lt;/p&gt;

&lt;p&gt;第二章，主要是讲如何是你的团队成员得以成长（Grow Your Teammates）。&lt;/p&gt;

&lt;p&gt;第三章，主要是讲如何设置明确清晰的期望（Set Clear Expectations）。&lt;/p&gt;

&lt;p&gt;第四章，主要是讲如何有效的进行沟通（Communicate Effectively）。&lt;/p&gt;

&lt;p&gt;第五章，主要是讲如何构建韧性管理（Build Resiliency）。&lt;/p&gt;

&lt;h2 id=&quot;内容剖析&quot;&gt;内容剖析&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/five_stages.webp&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;在对全书的五个章节进行剖析之前，有必要说一说作者在序章中提及的团队发展的四个阶段，分别是“组建”（Forming）、“风暴”（Storming）、“成规”（Norming）和“高效”（Performing）。&lt;/p&gt;

&lt;p&gt;简而言之，“组建”阶段可以认为是当一个团队的成员初次集合到一起的时候，团队需要的各种协作和流程都还没有建立。一切方兴未艾。“风暴”阶段是团队的成员之间开始产生“摩擦”（Friction）。作者认为，这个阶段是团队成长的必要阶段，需要有这个阶段的“疑惑”（Confusion）和“冲突”（Clashing）来达到下一个阶段。“成规”阶段是事情慢慢得到了解决，团队成员之间的差别得到了调和。最后，“高效”阶段是整个团队有序得运行，你们开始“交付”（Ship）产品。&lt;/p&gt;

&lt;p&gt;需要指出的是，这四个阶段并不是一次性的，而是循环往复的团队生存周期。这是因为团队永远处于持续地变化中，例如有新成员加入、团队的宗旨发生了变化等。全书也算是围绕着这四个阶段来进行展开讨论的。&lt;/p&gt;

&lt;p&gt;接下来，我们针对书中的五个章节为大家进行剖析。&lt;/p&gt;

&lt;h2 id=&quot;结识你的团队&quot;&gt;结识你的团队&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/five_1.webp&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;这一章主要是讲在团队“组建”阶段，我们如何去了解团队成员的“核心需求”（Core Needs）以及他们的工作模式（Work Styles）。同时，这个阶段也需要让团队成员了解你。&lt;/p&gt;

&lt;p&gt;书中提到了六个和工作相关的“核心需求”:&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;第一个是“归属感”（Belonging），也就是团队成员对一个社群（Community）或者团队的一种认同度，是否觉得自己是其中一员。当你觉得被团队“遗漏”（Left Out）的时候，这个“核心需求”就受到了伤害，例如团队某一个重要的会议，你没有被邀请参加，或是一个重要的产品发布没有通知你。&lt;/li&gt;
  &lt;li&gt;第二个是“进步感”（Improvement/Progress），也就是说你希望在团队中体会到某种程度上的进步或者是进展。这种进展可以是来自个人的，也可以是整个团队的。有时候，这种“进步感”可能会很难体会到，特别是在比较大的公司中。&lt;/li&gt;
  &lt;li&gt;第三个是“选择感”（Choice），也就是你是否感到对自己的生活和工作进行决策。也许你原本对自己的工作有很大的自主权，但突然公司新加入的一个负责产品的副总裁开始对你的之前计划开始发表意见。这时你可能开始感到“选择感”的失去。另一方面，如果有太多的决策需要做，也可能会造成你不知所措的情况。因此，对于“选择感”而言，我们需要注意“平衡”（Balance）。&lt;/li&gt;
  &lt;li&gt;第四个是“平等感”（Equality/Fairness），也就是你是否收到了平等的对待。当有决策通过的时候，所有参与决策的各个方面是否都有平等地接收到信息，是否平等地接收到了资源。&lt;/li&gt;
  &lt;li&gt;第五个是“预测感”（Predictability），也就是你是否能够对可预见的未来有一个初步的感知，而不是充满了“惊奇”（Surprise）。在日常工作中，大家度希望对未来有一定的把握程度。&lt;/li&gt;
  &lt;li&gt;第六个是“重要感”（Significance），也就是你个人的“地位”（Status），或者说是在团队中扮演什么样的角色，是否能够体现你的价值。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;值得注意的是，这六个核心需求对于每个人而言，并不是有同样的效果。面对一些事情，或者书中提到了“刺激物”（Stimulus），每个人可能会有非常不一样的反应。文中提到了让员工换座位这个例子来说明，这么一件看似简单的事情，有可能会“刺激”到不同人关于上述六个核心需求的反应，值得仔细阅读。&lt;/p&gt;

&lt;p&gt;这一章的第二部分，作者则是在讨论不同人的工作模式，具体说来就是遇到一些问题的时候，不同的人可能会有不尽相同的偏好。作者总结了下面五个方面的模式问题值得每一个经理逐一了解自己的员工:&lt;/p&gt;
&lt;ul&gt;
  &lt;li&gt;“不高兴”（Grumpiness）：什么样的事情可以可以导致员工不高兴，例如缺少咖啡因、没有睡好、不喜欢被“微观管理”（Micromanage）等。&lt;/li&gt;
  &lt;li&gt;“反馈和认可”（Feedback and Recognition）：当需要探讨反馈和认可的时候，每个人可能希望利用不同的媒介来达到目的，例如面对面、电子邮件还是即时聊天工具。特别是一些比较艰难的反馈，媒介的选择就显得尤为重要。&lt;/li&gt;
  &lt;li&gt;“目标和支持”（Goals and Support）：如何支持一个员工的成长以及如何知道员工需要怎样的支持都是作为经理和员工沟通的一个重要话题。&lt;/li&gt;
  &lt;li&gt;“员工成长”（Grow and Learn）：员工成长是一个很难以衡量的事情。然而，帮助员工成长又是经理们责无旁贷的职责。至少每一个季度都花一些时间来确定员工具体的，可以有行动的成长目标。&lt;/li&gt;
  &lt;li&gt;“款待自己”（Treat Yourself）：花时间去了解每一个员工如何款待自己的喜好，也许在未来某个时候需要奖励和表彰员工的时候能够用得上。这里面的偏好差异可能会非常大。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;这一章最后的内容是帮助你的团队认识你，或者反过来说，你希望如何呈现在你的团队面前。&lt;/p&gt;

&lt;p&gt;有两个方面的话题是需要你去思考的。第一，就是你优化的目标是什么？作者认为，这一个问题直接决定了一个经理的“风格”（Style）和“管理哲学”（Philosophy）。当然，优化一个目标往往会伴随着其他目标的缺失，这是需要注意的。第二，一旦你有了优化目标之后，和团队成员交流你这些目标有助于整个团队统一思想，同时也能够帮助你的团队成员设置有效的预期。&lt;/p&gt;

&lt;h2 id=&quot;扩展你的团队&quot;&gt;扩展你的团队&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/five_2.webp&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;我们之前提到的团队发展的四个阶段，这一章主要在讲“风暴”阶段团队的成长。&lt;/p&gt;

&lt;p&gt;为什么会有“风暴”阶段呢？团队在之前每一个个体的运作阶段可能并没有太多的问题。因为从本质上来说，团队并不是一个有机的整体，而是个体的集合，因此，一旦我们开始整合团队的所有人，开始设立一些流程，团队在协作、沟通等方面就都会出现广泛的“摩擦”。这几乎是可以预期的。&lt;/p&gt;

&lt;p&gt;书中说，在这个阶段，作为经理的你，需要做好下面四件事情。&lt;/p&gt;

&lt;p&gt;第一件事情，就是扮演好“导师”的角色（Mentoring），也就是直接给出建议并且帮助员工解决问题。这里，我们依靠的更多的是自己的经验。作为一名“导师”，我们需要注意的是对提供建议的人与环境有一定敏感程度。对一个人有意义的建议可能会对另一个人有伤害。另外，“导师”这个角色往往对初入角色（Role）的新人更有帮助，而对于已经有了一些成长的员工而言，更需要另外的指导手段。&lt;/p&gt;

&lt;p&gt;第二件事情，就是扮演好“教练”的角色（Coaching），也就是通过和指导对象进行对话，问“开放式”问题（Open Questions）来达到引导员工自省并且找到解决问题的方案。这个角色和“导师”是很不一样的。“导师”需要对问题以及解决方案都有所关注，而“教练”的角色则更加注重在分析问题上。两个重要的技巧是问“开放式问题”和“反思”（Reflection）。“开放式问题”必须让人觉得真诚，是你带有真正的好奇心来问的问题。这些问题有助于指导对象来进行更深层次的思考。“反思”是希望你能作为对方的一面“镜子”。把对方已经表达过的观点进行二次“翻译”，看是否能够抓住问题的核心。在这样的反复对话中，我们可以帮助指导对象来达到对当前问题的更深层次的理解和提出更好的解决方案。&lt;/p&gt;

&lt;p&gt;第三件事情，就是扮演好“支持者”（Sponsoring）的角色。如果说“导师”和“教练”是你和员工在面对面情况下互动的角色，那么“支持者”这个角色则是你在其他场合所要扮演的角色。这里的“支持”指的是你为指导对象提供并且争取机会，从而能够有力地进入到他职场的下一个层级。&lt;/p&gt;

&lt;p&gt;第四件事情，就是提供“反馈”（Delivering Feedback）。这一部分可能是最难以做好的角色。作者在这里讲了一个“反馈”公式。也就是，我们提供反馈需要首先来自某种行为的“观察”（Observation），然后我们需要描述这个行为的“影响”（Impact），接着，我们需要直接说出需要改变的事情或者是进入“教练”的角色，开始问一些开放式问题，最后，我们需要达到非常具体的，能够执行的反馈。&lt;/p&gt;

&lt;p&gt;在日常的工作中，我们经常需要对这四种角色进行有机得结合，并且在这些角色之间频繁互换。当然，书中也讲了，并不是这些手段都能够永远有效，总有员工可能并不理会你和他互动的好意，因此书中也讲了讲其他的渠道。&lt;/p&gt;

&lt;h2 id=&quot;设置明确的期望&quot;&gt;设置明确的期望&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/five_3.png&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;这一章主要在讲“成规”阶段的团队发展话题。&lt;/p&gt;

&lt;p&gt;顾名思义，无规矩不成方圆，当团队发展到一定程度，就需要设置一些规则和流程来保证团队运行的顺畅和解决分歧。&lt;/p&gt;

&lt;p&gt;这一章一开始主要讲了如何定义团队中的“角色和职责”（Roles and Responsibilities）。在团队发展的早期，都没有真正定义不同角色和职责的实际需要，一是因为人比较少，二是因为很多时候需要有人能够兼顾多种不同的角色从而能够达到某种情况下的灵活度。然而，随着团队的发展，每个人在日常运行中究竟是什么角色，不同人之间怎么协作，就需要我们开始思考这方面的问题。&lt;/p&gt;

&lt;p&gt;书中介绍了RACI角色定义方法和“维恩图表”（Venn Diagram）来定义“角色和职责”并且用了“工程经理”（Engineering Manager）、“产品经理”（Product Manager）以及“工程负责人”（Engineering Lead）如何建立清晰的职责界限来解释了这些方法的实际使用方法，建议读者精读这部分内容。&lt;/p&gt;

&lt;p&gt;这一章的第二部分讲了如何设置一个团队的“视野”（Vision）以及“优先级”（Priorities）。“视野”是回答你们这个团队为什么存在，究竟是要解决什么终极问题，这样的疑问。这里细分的话，有“视野”（Vision）、“使命”（Mission）、“策略”（Strategy）以及“目标”（Objective）的区别。简单来说，这几类定义是从最宏观到最微观的逐层表述。书中有详细的解释，建议大家读一读。有读者可能会问，对于一个团队来说，设置这些空洞的宏大的主题是否有实际的意义。这里的目的是让一个团队有章可循，特别是团队有任何分歧、有疑虑的时候都随时能够根据团队的“视野”和“优先级”来排除这些纷扰。&lt;/p&gt;

&lt;p&gt;这一章的第三部分讲的是团队的“实践”（Practice）。这一部分主要是指一个团队日常运作的模式，包括有什么样的会议以及交流的渠道（邮件或者即时通讯工具），和这些运作模式都是处理哪些问题。作者认为，即便每一个团队在具体的实践中可能都有了约定俗成的一套流程，最好能够利用文档工具（例如“维基”Wiki）来把这些实践记录下来。同时，作者认为，需要把团队的协作和交互给融合到日常的运作中去。&lt;/p&gt;

&lt;h2 id=&quot;有效的沟通&quot;&gt;有效的沟通&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/five_4.webp&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;在现代团队发展和运作过程中会遇到大大小小的很多事情，例如公司的目标发生了变化、公司开始经历裁员、新的产品线、公司上市等等。所有这些事情，作为一个经理，你都需要和员工保持良好有效的沟通。有不小挑战性的是，很多这些事情，你并不是直接的决策者，甚至也没有参与其中，但作为当前团队的负责人，你需要有很清晰的头脑如何和团队进行交互和沟通。&lt;/p&gt;

&lt;p&gt;书中首先介绍了如何来规划沟通一些重要的信息。很明显，你需要一个计划。作者介绍了一些沟通计划的模板。总而言之，这些模板的目的是帮助你能够为一些相对复杂的情况有一个更加全面的沟通有所准备。书中作者用一个虚拟的经理离职作为例子，展示了如何为这样一个可能会比较棘手的事件进行沟通准备。&lt;/p&gt;

&lt;p&gt;在这一章的第二部分，作者讲了讲对敏感信息沟通的技巧。敏感信息的挑战来自于可能会触及一些员工的核心需求。比如，我们要沟通一次组织架构的调整，团队的工作方向也许会有调整，那么一些员工的“选择感”和“预测感”都会受到不小的影响。一些员工可能会觉得自己的意见或者声音没有得到抒发的机会。作者认为，敏感信息沟通的核心来自于“迅速”（Swift）而不是拖延好几天甚至是更长时间。有很多事情有可能在更长的等待中发生变化，也就是我们经常说的“夜长梦多”。同时，如何有效得分享一些机密信息，也是需要特别注意拿捏分寸的事情。在一个较大的公司和团队中，任何机密的信息都有可能被泄露出去，作者认为在这种时候，首要任务是沟通并且阐明一些事情的事实，而事后对有可能把机密信息泄露这样的事情进行反思。&lt;/p&gt;

&lt;p&gt;本章的第三个部分，作者探讨了一下，作为经理的你，如何沟通你并不十分认可的决定。在一个比较大的公司中，这样的情况其实比比皆是。公司有很多决策或者变化无法邀请所有人参与。这一方面是不现实一方面也没必要。因此，在公司的运作中，我们就需要学会传达和沟通我们自己并不认同的决定。这里的核心是做到“不认同但负责”（Disagree and Commit）这样一种职业态度。也就是说，虽然你对于某一些决策的内容并不能完全认可，但是你需要去完全执行这些决策的内容并且利用沟通的技巧和团队进行沟通。不过，作者也提出，这种时刻，也是你重新审视自己和当前的团队以及公司还是否能够契合到一起，如果有重大的分歧，离开这样的团队和公司可能是更好的选择。&lt;/p&gt;

&lt;p&gt;本章的第四部分作者讲了讲不同媒介的区别，例如会议、邮件以及即时通讯工具，都具有自身不同的特点，适用于沟通不同的内容。比如，一些重大的决定或者是变化，最好能够通过面对面的会议，甚至是“全公司会议”（All Hands Meeting）来首先传达。而另一方面，邮件沟通可以传达一些没有太多歧义内容的信息，并且能够起到提醒人的作用。&lt;/p&gt;

&lt;p&gt;最后，作者强调，沟通不是一次性的工作，而是本身就需要反复迭代和演化的工作。也就是说，我们需要反复重复重要的信息，在很多场合，和很多媒介。同时，每个公司可能对于如何沟通有不同的企业文化的偏好。&lt;/p&gt;

&lt;h2 id=&quot;构建韧性管理&quot;&gt;构建韧性管理&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/five_5.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;作者把最后一章的内容献给了如何让当经理的人自身更加富有“韧性”。也许你的团队已经到达了“高效运行”的阶段，但是一个突然的变化，使得你做的很多工作回归原点。千万不要以为变化是一时的，作者认为，处在高速发展的科技公司中，变化是随时随地都在发生的。因此，如何让经理变得更有“韧性”，也就是如何处置随时的变化，以及一一种不变应万变的心态就成为了很重要的议题。&lt;/p&gt;

&lt;p&gt;这一章一开始，作者讨论了如何管理危机时刻（Times of Crisis）。这里的关键是了解你有什么样的资源和工具。每一个公司对待很多情况都有相应的流程。对这些流程有所了解，是你需要处理危机的必备信息。另一方面，是和员工有良性的和真挚的沟通，让他们觉得你是可以依赖的伙伴。&lt;/p&gt;

&lt;p&gt;这一章的第二部分，则在讨论如何管理你自己的“能量”。简而言之，那就是如何能够使自己保持一个正能量的心态。作者的一个建议是时刻关注我们被什么样的事情所消耗时间和精力。也就是看看自己的日历，平时都参加什么样的会议。这里，需要你对自己的时间有一个深层次的了解以及有一些如何应对这些事物的想法。然后，书中介绍了不少的技巧，可以用于管理自己的时间使自己更高效，例如重新安排自己的任务，把一部分任务给代理出去、对一些事情说“不”等等。读者可以好好阅读一下这部分内容。&lt;/p&gt;

&lt;p&gt;本章的最后是探讨如何构建自己的“支持网络”（Support Network）。作为一个经理而言，“你不是一个人在战斗”，但往往，我们可能觉得自己是“孤家寡人”。作者提出了“支持网络”这个概念，也就是说，我们需要去构建自己的网络来获取更多的信息，学习更多的技能，以及扩宽自己的社交网络。同时，作者也提到了“第一团队”（The First Team）的概念，也就是当发生任何变化以及需要做一些复杂决策的时候，你最先寻求帮助和信息的人都是什么人，而这些人都能够提供哪一些不同的视角。这一部分内容可以算是经理职业发展的高级话题。&lt;/p&gt;

&lt;h2 id=&quot;总结点评&quot;&gt;总结点评&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;这本书可以说是作为技术管理人的经典入门的参考书。作者Patrick Lencioni作为在工业界有丰富经验的技术经理人所写作的本书可以说是有非常强的实战指导价值。书中有不少可以直接拿来用的技巧、模板和方法。同时，书中的一些案例也是来源于实际工作。与同类型的《经理人之路》相比，本书更加短小精悍，并且非常适合需要对技术管理快速入门的初级技术管理人员。从结构上看，全书的五个章节都相对独立但又和在序章中讲到的团队的发展历程的几个阶段有着紧密的联系。建议对技术管理有兴趣的读者精读。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>《No Rules Rules》总结</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0,%E7%AE%A1%E7%90%86/2022/10/15/netflix/"/>
   <updated>2022-10-15T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0,%E7%AE%A1%E7%90%86/2022/10/15/netflix</id>
   <content type="html">&lt;p&gt;&lt;a href=&quot;https://en.wikipedia.org/wiki/Netflix&quot;&gt;网飞（Netflix）&lt;/a&gt;的公司文化一直以来在业界都有一种神秘的色彩。我在2012年左右也有幸到网飞面试，非常短暂得近距离解接触了这个公司的某个切面。虽然之后因为种种原因并没有加入网飞，但这家公司却一直吸引着我的注意力。&lt;/p&gt;

&lt;p&gt;2020年出版的&lt;a href=&quot;https://www.amazon.com/No-Rules-Netflix-Culture-Reinvention/dp/1984877860&quot;&gt;“No Rules Rules – Netflix and the Culture of Reinvention”&lt;/a&gt;应该算是网飞的首席执行官&lt;a href=&quot;https://en.wikipedia.org/wiki/Reed_Hastings&quot;&gt;Reed Hastings&lt;/a&gt;在这家公司的巅峰时刻对过去20多年公司文化以及管理哲学的一次系统性总结。同时，有意思的是，仅仅2年之后，这家公司的市值就跌到了最高点的五分之一，让人去琢磨这些在疫情前进行的公司文化总结，是否能够真正经得起时间的考验。然而，不可否认的是，抛开最近的波折，这本书的确提出了一些不少从经典的管理思维来看是相对比较有争议的观点，这都值得所有对管理有兴趣的读者甄别、思考和学习。&lt;/p&gt;

&lt;p&gt;我们就总结下面几个本书的观点，来看看Reed对于公司管理理念的探索。&lt;/p&gt;

&lt;h2 id=&quot;人才密度&quot;&gt;人才密度&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/netflix_1.jpeg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;网飞在业界最出名的一个文化特征就是其宣称可以毫无顾忌得解雇员工，只要公司认为你已经无法提供相应的价值。Reed在本书中一点都没有回避着可以说是最有网飞标志的管理思路。当然，Reed为这一理念取了一个更加人性化的名字“人才密度”（Talent Density）。&lt;/p&gt;

&lt;p&gt;简单来说，“人才密度”就是雇最好的人，然后如果这个人已经不合适的时候，去找更适应的人。Reed在书中对这个管理理念进行了更加详细的阐述。首先，那就是要雇最好的人。作为管理者，你是否确定你目前团队中的成员是最胜任这个职位的人，或者说你是否为这个职位已经雇了行业中的顶尖人才。如果不是，那Reed的建议是你应该去寻找这些优秀的人才。&lt;/p&gt;

&lt;p&gt;当有了优秀的人才后，Reed认为最能够保持（Retain）人才的方式是采用业界最有竞争力的薪资。这一观点也可以说是会很受争议。传统观点认为，人才的薪资需要和其绩效（Performance）绑定。Reed则认为，要想招聘和留住顶尖的人才，薪资水平必须和工业界最高水平看齐。于是，网飞会花书中讲了好几例网飞为人才进行薪资调整，哪怕有时候并不是反映人才当前的绩效。&lt;/p&gt;

&lt;p&gt;有了最有竞争力的薪资之后，Reed还认为需要对这样的人才经常性的问一个叫做“Keeper Test”的问题，也就是假设你作为一个非常有价值的员工今天选择离职，你的老板会不会争取留下你。如果你的老板对这个问题有丝毫的犹豫，那也就证明你可能已经不适合留在团队。Reed的观点是，所有人都需要反复来做这个“Keeper Test”，包括他自己。这样，我们才能保证当前在团队里的人才依然是我们想要的顶尖人才。&lt;/p&gt;

&lt;p&gt;Reed将公司员工和公司的关系比作职业球队中球员和球队的关系，也就是一个“团队”（Team）但不是一个“家庭”（Family）。团队讲究的是协作和竞争，每一个成员都需要为团队的成功复出心血。当一个团队的成员已经和目前团队的设置和氛围不适应的时候，团队就需要寻找更适合的成员。这好比职业球队中球员非常频繁的转会，其实是一件稀疏平常的事情。而对于“家庭”关系而言，成员和整体之间有一种“无限责任”的关系。家庭成员之间的关系随着时间推移逐渐变化，对于家庭成员之间的矛盾和不适应需要的是包容和解决问题。这也就是两种不同的关系体系。值得注意的是，很多公司都提出自己是一种“家庭”关系，而这正是Reed所诟病的运营方式。同时，也有不少从这样氛围中走出来的员工会在网飞感到不适应。&lt;/p&gt;

&lt;h2 id=&quot;取消管控分布式责任&quot;&gt;取消管控、分布式责任&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/netflix_2.jpeg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Reed在整本书中都强调一个核心的管理理念，那就是取消公司治理中经常遇到的种种“审核”（Approval）和“管控”（Control），建立一个更加“分布式”（Distributed）的责任体系。这里面有几个维度值得我们探讨。&lt;/p&gt;

&lt;p&gt;第一，公司中很多审核机制，来自害怕员工犯什么不可挽回的错误。在这种情况下，很多公司都建立起层层审核（例如某些请求需要总监级别审批，或者某些请求需要副总裁级别审批等）来管控这种错误的几率。这种层层核准其根源往往来自于对员工的不完全信任。另外，这种机制也假定级别更高的领导比级别相对较低的员工对全局信息更有把控能力，于是也就更能做出正确的判断。例如，如何知道一个销售人员是否该为一个2万美元的饭局买单？于是公司就建立其机制来设定销售人员的饭局一般在2千美元以下，并且各类菜品以及酒水的消费都有详细的规定（什么酒什么菜可以报销等等）。同时，2千以上的消费需要总监级别，1万以上的消费需要副总裁级别审核批准，等等。相信大家都对这样的类似机制并不陌生。然而，Reed认为，这样的机制，虽然有可能避免了一些错误，却根本上阻碍了很多的机会。比如，在刚才那里例子中，这个销售人员需要等副总裁级别的审核，于是很有可能错过了这个原本很重要的、甚至可能带来更多销售机会的饭局。更进一步，难道这个副总裁就一定能够有更多的信息来判断这个饭局值不值2万美元吗？也不一定。所以，为了防止错误而建立起来的层层审批，未必就能给公司带来更多的机会抑或防止错误。Reed在书中给了两个实际的例子，一个就是取消报销制度，另一个就是取消休假审批制度。书中讲了，这两个制度的取消并没有带来网飞公司的彻底混乱。&lt;/p&gt;

&lt;p&gt;第二，Reed认为，作为一个公司，既然已经按照人才密度理念招来了很多一流的人才，并且赋予这些人才市场的薪酬，那么就应该让这些人参与其最擅长的决策，而不是依赖冗余的审批管控机制。比如书中举了一个例子，一个负责引进纪录片的人员遇到了一个有可能是在当时的天价纪录片竞标。这个人打电话给他老板请示这是否值得。他的老板则问了他一个简单得问题，那就是他自己觉的是否值得。当这个人自己还是觉得值得购买的时候，他的老板就让他自己拍板决定了。最终这部天价纪录片为网飞带来了奥斯卡奖。这本书中充斥着类似的例子，那就是当有一个具体的事情需要做决策的时候，Reed为某一个有足够信息和能力的人赋予做完全决策的权限。这在很多公司看来是天方夜谭，但网飞则表示这才能完全调动一个组织内部各个层级的主观能动性。
第三，有了前两点的铺垫，Reed其实期望建立的是“分布式”的决策机制以及为企业的各个职能组织赋能，从而能够减低决策风险。“集中式”决策的核心假设是，老板比员工懂得多，一切都是为了降低错误发生而设计。而在网飞这样快速发展，而且在进行全球化布局的企业而言，老板往往比员工懂得更少，总部往往没法对海外分部的所有决策进行理性的审批，因此这就需要公司反其道而行，把决策的能力推到一线，推到可以做决策的地方。这也就是Reed的管理理念核心。&lt;/p&gt;

&lt;p&gt;最后，当然，分布式决策不是简简单单为一线赋能那么简单。比如书中举了一个例子，那就是Reed在新加坡的办公室访问期间，在一起对话中，无意中得知某个总监正在编写下两年的人员计划。Reed自己觉得从来没有让底下管理层编写这个计划，于是就深入调查了一下。原来发现，这个写接下来将年人员计划的要求竟然来自于某个大楼管理人员。因为网飞在世界各地都飞速发展，于是大楼管理人员觉得需要对未来的人员有一个预估才能更好得租到合适的办公场所。这一看似非常合理的思考演变成了让所有部门编写两年人员计划，而对于网飞来说，没有人能够对未来两年的变化能够有完整的把控，也就无需去写这样的计划。这个例子让Reed意识到，很多部门如果需要做决策，他们有可能缺少一些“上下文”（Context），而这些上下文可能会极大得影响做决策的质量。于是，Reed认为，在“分布式”决策中，高层除了放权，另一个很重要的举措就是设置合适的“上下文”来帮助一线人员了解全局信息。&lt;/p&gt;

&lt;h2 id=&quot;迎接全球化挑战&quot;&gt;迎接全球化挑战&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/netflix_3.jpeg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;网飞在过去十多年间（2010-2022年）高速发展，特别是在全球化的道路上更是飞奔。仅2016年一年，网飞就开始在全球130多个国家地区开展业务。一直以来，基于欧美的互联网公司在全球化的推行中，都或多或少遇到一些挑战。本书可以算是提及了不少有价值的经验教训以供参考。&lt;/p&gt;

&lt;p&gt;第一个值得关注的就是人才密度的管理理念。全球范围内很明显对于这样比较直接的人才管理模式是有一定的挑战的。例如，一些欧洲国家有更加完善的劳资管理法律。在这些国家，解雇一名员工的成本会大大增加。在另外一些国家，例如日本，很多员工都在同一家公司工作一辈子。解雇员工是无法想象的事件，即便有时候，大家也知道谁可能并没有在最好的工作状态。虽然有这些国家和文化的区别，Reed也坚信人才密度的管理理念是需要在全球范围内进行推行的。当然，这需要和不同国家和文化进行重新适配。不过，在进行了一番调整后，人才密度理念在全球的网飞办公室推行了开来。&lt;/p&gt;

&lt;p&gt;第二个值得关注的就是不同国家和文化对于“反馈”（Feedback）的接受程度有极大的区别。对于很多欧美公司而言，接受和提出“反馈”是绩效评估中不可或缺的部分。即便是网飞，一个相对于淡化绩效评估的企业，依然非常重视“反馈”在整个企业运营中的地位。然而，“反馈”对于一些国家和文化而言，则相对比较陌生。特别是很多在欧美比较容易的实践，在其他地区就相对比较困难。书中分享了，网飞在欧美的很多办公室搞相对比较非正式的“反馈”活动，原本的目的是有助于员工能够拉近大家的距离更放松而不至于不愿意分享互相相对比较难以启齿的一些观点。而这种活动则在日本这样相对比较保守的国家中，寸步难行。最终，网飞发现在日本，相对于非正式的“反馈”，员工更加喜欢正式的“反馈”。虽然一开始可能有点匪夷所思，但是一旦大家被告如如何进行正式的“反馈”，这些活动反而起到了不错的反响。&lt;/p&gt;

&lt;p&gt;第三个值得关注就是每个国家和文化对于同一个信息的解读可能存在巨大差别。这一点对差别很大的文化可能比较容易注意到。但是书中讲了一个例子中，一个新加坡的同事看到一个美国的同事传来的信息觉得被冒犯。而这个信息在美国的同事眼里却完全是平常的语气。惊奇的是，同一个信息被拿给其他的新加坡同事看，依然会被觉得冒犯。其实重点是这个信息中的某种表达方式更加欧美。这个例子其实说明了，在一个全球化的公司中，沟通从来都不是单向的。在很多情况下，不同国家和文化的同事之间需要互相调整和学习。&lt;/p&gt;

&lt;h2 id=&quot;总结点评&quot;&gt;总结点评&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;这本书可以说是作为洞察网飞管理模式以及熟悉其CEO思维模式的一本不可多得的好书。书中深入浅出得讲解了不少网飞独特的管理模式，如人才密度、放弃管控并且进行分布式管理等等很值得借鉴的经验。这些理念虽然不可能完全能够在不同的公司中进行复制，但Reed提供了很多完全不同的思考方式，来帮助大家了解了公司治理并非是一成不变的教条，而是需要拥抱不同的挑战。同时，书中不光是这些理念的堆砌，作者也囊括了十分丰富的案例来支撑这些论点。与同类型的很多管理经验书籍相比，本书很浅显易懂，并且非常适合需要对互联网公司运营有兴趣的管理人员。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>浅谈工业级推荐系统</title>
   <link href="http://column.hongliangjie.com/%E6%8E%A8%E8%8D%90%E7%B3%BB%E7%BB%9F/2020/10/04/industrial-recsys/"/>
   <updated>2020-10-04T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E6%8E%A8%E8%8D%90%E7%B3%BB%E7%BB%9F/2020/10/04/industrial-recsys</id>
   <content type="html">&lt;p&gt;我于2020年8月受&lt;a href=&quot;https://irsworkshop.github.io/2020/index.html&quot;&gt;“第一届工业级推荐系统研讨会”&lt;/a&gt;的邀请，做了题为&lt;a href=&quot;https://www.hongliangjie.com/talks/IRS_KDD2020.pdf&quot;&gt;“工业级推荐系统最新的挑战和发展”&lt;/a&gt;的主题演讲。我们就依据这个演讲的内容作为一个起点，来聊一聊工业级推荐系统的一些特点，尤其是和推荐系统的学术研究有着哪些不同的侧重点。本文会关注那些学术研究中容易忽视的，但却是在工业级推荐系统研发的日常中需要思考的问题。&lt;/p&gt;

&lt;h2 id=&quot;工业级推荐系统及其生态系统&quot;&gt;工业级推荐系统及其生态系统&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/in-recsys-1.png&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;工业级推荐系统和学术研究中的推荐系统最大的一个区别，也是最容易忽视的一个区别在于，前者往往是某个产品中的一个环节，甚至有时候是一个很小的环节。一个产品往往有很多环节，而这些环节构成了一个复杂的生态系统。更进一步来说，某个公司之间的多个产品可以进一步构成更加高级的复杂生态系统。所以，理解工业级推荐系统就必须把推荐系统放回其所在的整体生态系统来进行审视和研究。&lt;/p&gt;

&lt;p&gt;传统学术研究中的推荐系统往往基于一个虚构的理想环境。那就是有一个物品的候选池（可以是新闻、电影、或者是商品等），而用户针对这个侯选池中的物品进行逐一评分，分数由低到高，可以是五分制，也可以是两分制，表达喜好程度。推荐系统的任务被抽象成为对用户评分（Rating）信息的预测或者是估计。一个完美的推荐系统就是毫无偏差得对所有的用户评分进行还原和预测。熟悉的读者可以发现，这个理想环境其实就是对推荐系统研究有着巨大推动作用的——&lt;a href=&quot;https://en.wikipedia.org/wiki/Netflix_Prize&quot;&gt;Netflix大奖赛&lt;/a&gt;中任务场景更加抽象的一个版本。的确，把推荐系统抽象成用户评分信息预估极大得简化了推荐系统在实际产品中的作用，为十多年来推荐系统研究的蓬勃发展带来了有力的支持。一个更加抽象的任务描述则把评分预估看成是不完全信息的&lt;a href=&quot;https://en.wikipedia.org/wiki/Matrix_completion&quot;&gt;“矩阵完成”（Matrix Completion）&lt;/a&gt;。也就是说评分预估可以看做是一个以用户为行物品为列的矩阵中有一些信息不完整。我们只有某一些单元中有数值，代表已经打过分的用户与物品的的交互。剩下有大量的单元需要来补全信息。这种“矩阵完成”的任务描述则更进一步得把推荐系统的任务变成了数学中的代数问题。&lt;/p&gt;

&lt;p&gt;实际上，研究人员和实践工作者很快意识到了把推荐系统研究如此简化带来的一个直接问题，那就是推荐系统性能的提高，或者说是对用户评分预测的精准与否，与我们期望推荐系统所承载的功能有不小的偏差。早在Netflix大奖赛之后，&lt;a href=&quot;https://netflixtechblog.com/netflix-recommendations-beyond-the-5-stars-part-1-55838468f429&quot;&gt;Netflix官方工程博客&lt;/a&gt;就阐述了为什么团队最终没有采纳获奖的算法在产品中，并且因为种种原因，包括隐私和法律风险，Netflix最终放弃了举行第二届大奖赛的想法。对于Netflix这个产品群来说，真正的产品需求是希望用户能够喜欢其服务所带来的电影电视以及广泛的节目，从而让用户能够选择订阅Netflix服务，或者持续订阅。也就是说，Netflix所有产品，包括上面林林种种的搜索推荐功能都是为这同一目的而服务的。单一模块的好坏甚至是某个模块上面用户对于某一个节目的评分可能与这个用户是否选择继续订阅Netflix没有明显的联系。&lt;/p&gt;

&lt;p&gt;这种推荐模块仅仅是一个更大产品中的一个环节，并且更大产品的目标和推荐系统的目标完全不一样的情况不仅仅局限于Netflix。例如电商Amazon，虽然网站上有各种不同的页面和模块，但归结起来，总的目的还是希望能够吸引用户购买商品。例如专注构建职业社交圈的LinkedIn，网站上有丰富的各种模块和服务，但归根结底，LinkedIn是希望用户最终能够订阅其中的一些服务或者是成为其广告的点击者，为其服务产生商业价值。例如在线音乐和广播节目服务商Spotify的最终目的是吸引用户持续订阅其服务。因此，Spotify上的种种栏目和推荐模块都是为这一共同的目标而服务的。&lt;/p&gt;

&lt;p&gt;把单一推荐模块，和其他的模块页面放一起，都看做是达成产品最终目标的统一生态系统中的一个元素，是理解和开发工业级推荐系统的重要前提。&lt;/p&gt;

&lt;p&gt;对于多页面多模块的生态系统而言，有这么两个重要的挑战。第一，产品的最终目的往往和某一个模块的成功有着复杂的关系，并没有完全线性的相互联系。换句话说，即便衡量大多数甚至每一个模块的指标有了正向或者负向的变化，整个产品的最终目标并不一定会有相同方向的变化。例如，对于Netflix来说，某一个模块的点击率的变化，可能对每一个月的订阅人数的变化并不起决定性的作用。第二，理解多个模块之间的关系变得很困难。例如，Amazon商品页面上的多个模块，按理说，其目的是为了吸引用户更加了解当前产品并且进行购买，但是如果一个模块展示了其他更加有吸引力的产品，用户可能会从当前页面跳转到其他页面去。更加复杂的场景包括用户可能因为看了过多的产品后举棋不定，从而不准备在当下进行购买。于是，商品页面上的某一个模块虽然可能有了更多的点击，但是其他模块可能会受到影响，点击下降，达到某种“此消彼长”的态势。&lt;/p&gt;

&lt;p&gt;总而言之，把推荐系统放到整个生态系统中进行思考并且理解多个模块之间的关系是工业级推荐系统的重要挑战。&lt;/p&gt;

&lt;h2 id=&quot;工业级推荐系统和产品长期目标的关系&quot;&gt;工业级推荐系统和产品长期目标的关系&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/in-recsys-2.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;我们前面提到了工业级的推荐系统往往是庞大产品体系中的一个环节。而整个产品体系又是为公司的产品以及商业策略服务而最终获得商业和社会价值。大多数互联网公司都对如何衡量产品和商业策略有一些标准的做法，比如利用&lt;a href=&quot;https://en.wikipedia.org/wiki/Active_users&quot;&gt;“月活跃用户数”&lt;/a&gt;（Monthly Active Users）、&lt;a href=&quot;https://en.wikipedia.org/wiki/Gross_merchandise_volume&quot;&gt;“商品毛利润”&lt;/a&gt;（Gross Merchandise Value）来对一个公司的业务好坏进行最基本的判断。&lt;/p&gt;

&lt;p&gt;然而我们可以看到，公司对于产品衡量好坏的标准往往都是对于产品的一个相对长时间状态的描述。例如，如果我们要观测“月活跃用户数”的变化，则需要对产品进行好几个月的观察，仅仅观察一两个月就自然无法得到这种本身就需要多个月进行观测的指标的变化。同理，“商品毛利润”的变化有时候也需要少则数周多则数月才能观测出来，如有一些产品的计费方式是每一个月针对用户进行计费甚至有的是每一年才计费（例如有一些订阅服务）。LinkedIn的企业级招聘的重要指标是看有多少用户利用LinkedIn找到心仪的工作。而要衡量一个用户是否换了工作，这里面的数据信息的滞后性可能有几周到几个月不等。因此观察这个指标的变化也是需要长期衡量的。&lt;/p&gt;

&lt;p&gt;产品的业务指标需要长期观测这一特性为优化这些指标，特别是利用机器学习系统来优化这些指标，带来了巨大的困难。&lt;/p&gt;

&lt;p&gt;现代互联网产品迭代往往利用在线可控实验，或者简称的&lt;a href=&quot;https://en.wikipedia.org/wiki/A/B_testing&quot;&gt;A/B测试&lt;/a&gt;，来对产品特性进行实验。具体说来，我们常常把当前版本的特性当做“控制组”，并把新版本的特性当做“参照组”，然后把用户流量各50%得导给“控制组”和“参照组”。一般来说，A/B测试运行一两周，有时候会有两三周，然后根据一些容易观测的指标，例如“点击率”来判断特性的新版本是不是比当前版本要有明显的优势（包括我们说的统计意义上的要更好）。然而，我们可以看到，在几周的在线测试的设置下，我们是很难去直接观测刚才我们提到的产品指标（如“月活跃用户数”、“商品毛利润”）的变化。大多数在线测试的时长都远远小于观测产品长期指标变化需要的时长。&lt;/p&gt;

&lt;p&gt;如果我们希望利用A/B测试来对产品的特性进行迭代，那势必就需要观测的指标能够在测试的时长中被有效得观测到其大小的变化。从更加专业的角度来说，这样的指标需要有足够的“敏感度”（Sensitivity）能够在测试的时长中很容易发现其变化。遗憾的是，大多数的产品长期指标的“敏感度”都比较小。例如“月活用户数”的变化往往需要我们对很大的流量数据进行观测一段时间。而“点击率”的变化则相对容易看到。&lt;/p&gt;

&lt;p&gt;于是，我们这里就有一个很大的障碍，那就是A/B测试指标和产品长期指标之间往往非常不一样，而建立两者之间的关系可能有不可逾越的鸿沟。&lt;/p&gt;

&lt;p&gt;推荐系统作为一种机器学习系统，往往采用我们熟知的指标来衡量其好坏。比如我们前面提到的Netflix大奖赛其实是看我们对评分预测的准确性。很多机器学习问题采用的&lt;a href=&quot;https://en.wikipedia.org/wiki/Precision_and_recall&quot;&gt;“精度”&lt;/a&gt;或者一些排序问题采用的&lt;a href=&quot;https://en.wikipedia.org/wiki/Discounted_cumulative_gain&quot;&gt;NDCG&lt;/a&gt;等，也是研发人员往往使用的指标。然而，我们可以看到，这些指标和A/B测试指标以及产品的长期指标有着本质的不同。一个例子是我们也可以推断，Netflix大奖赛的获胜算法虽然能够带来评分预测准确性大幅度的提升，但对于产品的重要指标，也就是用户的订阅数，并没有明显的影响。&lt;/p&gt;

&lt;p&gt;工业级推荐系统的一个重要发展方向就是建立有效的通过推荐系统性能的提高来达到产品的长期指标得以提高的方法论。&lt;/p&gt;

&lt;h2 id=&quot;工业级推荐系统作为复杂的软件系统&quot;&gt;工业级推荐系统作为复杂的软件系统&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/in-recsys-3.jpeg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;这里要提到的最后一个工业级推荐系统的特性，也是推荐系统的学术研究往往会完全忽视的，那就是工业级推荐系统往往是一个复杂的软件系统。&lt;/p&gt;

&lt;p&gt;这里面的复杂性来自于两方面。第一，工业级的推荐系统作为一个复杂的软件系统，是由不同的软件模块和服务构建而成。而这些软件模块还需要利用很多的基础设置，例如数据平台，以及各种工具。这些不同的软件模块之间如何能够设计最优，会不会有复杂的依赖关系从而很难调优，都是需要思考的重要问题。第二，工业级的推荐系统作为一个复杂的软件系统，是多人甚至是多团队的研发结果。每一个团队往往维护着不同的软件模块。这些团队之间的协作往往并没有很多人想象的那样非常紧密。实际上，不同的团队通常有不同的开发周期，因此如何能够保证不同的团队协调一致是一个复杂软件工程问题。&lt;/p&gt;

&lt;p&gt;我们通常在推荐系统的研究论文中，看到所谓的“端到端”（End-to-End）的优化模式，也就是说，我们希望能够对模型的方方面面的所有参数以及各种输入信号一起都拿到一个统一的模型中去调优。这种思路在近年来的以深度学习为基础的论文中常常遇到。而通过论文，我们也看到，这样的“端到端”的学习方法往往有最优的效果。遗憾的是，针对多模块多团队的推荐系统，我们是很难做到真的“端到端”优化的。通常情况下，某一个团队的模块可以进行“端到端”优化。而各个模块之间则往往是“黑盒”交流（也就是说并不清楚互相模块的内部信息）。从软件系统的角度来看，工业级推荐系统和推荐系统研究有着比较大的差别。&lt;/p&gt;

&lt;p&gt;多模块和多团队的推荐系统还会遇到在研究中完全不需要考虑的问题，比如，如果不同的模块都在进行进度不同的研发，那么如何能够保证多个模块之间能够协调好，特别是在进行在线测试的时候，能够得到有效的结论，有时候是相当有挑战的。例如，某个推荐系统的新旧版本可能依赖不同的数据，或者一些不同的内部服务，这时候就可能并不是严格意义上的A/B测试，而可能有很多因素可以影响测试结果。&lt;/p&gt;

&lt;p&gt;从软件系统和软件工程的角度来看到工业级推荐系统，或者说一般的机器学习系统，是一个很值得探讨的课题。从推荐系统的学术研究中，我们很难看到这一类的讨论。&lt;/p&gt;

&lt;h2 id=&quot;总结点评&quot;&gt;总结点评&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;我们在这一篇文章中为大家阐述了三个工业级推荐系统的重要特征。这三个特征都有别于推荐系统的主流学术研究，但都是推荐系统应用到工业界产品中所需要思考的问题。我希望这三个特性所涵盖的三方面问题可以指导对工业级推荐系统产生更加有高度的认识，从而能够让我们对今后的研究工作有新的启发，起到抛砖引玉的作用。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>《韧性管理》总结</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0,%E7%AE%A1%E7%90%86/2020/07/09/resilient-management/"/>
   <updated>2020-07-09T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0,%E7%AE%A1%E7%90%86/2020/07/09/resilient-management</id>
   <content type="html">&lt;p&gt;今天我们要来总结技术管理书籍&lt;a href=&quot;https://resilient-management.com/&quot;&gt;Resilient Management&lt;/a&gt;。作者&lt;a href=&quot;https://www.linkedin.com/in/larachogan/&quot;&gt;Lara Hogan&lt;/a&gt;是资深的科技公司领导人。她先后于Etsy和Kickstarter担任重要的技术领导人职务，其长期在发表关于技术管理的博客文章以及提供相应的咨询和培训服务。书中有不少可以直接拿来用的技巧、模板和方法。同时，书中的一些案例也是来源于实际工作。本书非常适合需要对技术管理快速入门的初级技术管理人员。&lt;/p&gt;

&lt;h2 id=&quot;作者简介&quot;&gt;作者简介&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/lara.jpeg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;作者&lt;a href=&quot;https://www.linkedin.com/in/larachogan/&quot;&gt;Lara Hogan&lt;/a&gt;是资深的科技公司领导人。她先后于Etsy和Kickstarter担任重要的技术领导人职务，其长期在发表关于技术管理的博客文章以及提供相应的咨询和培训服务。&lt;/p&gt;

&lt;h2 id=&quot;全书结构&quot;&gt;全书结构&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;全书非常短小精悍，分为以下这么五章内容：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;第一章，主要是讲如何认识你的团队，也就是书中讲的结识你的团队（Meet Your Team）。&lt;/li&gt;
  &lt;li&gt;第二章，主要是讲如何是你的团队成员得以成长（Grow Your Teammates）。&lt;/li&gt;
  &lt;li&gt;第三章，主要是讲如何设置明确清晰的期望（Set Clear Expectations）。&lt;/li&gt;
  &lt;li&gt;第四章，主要是讲如何有效的进行沟通（Communicate Effectively）。&lt;/li&gt;
  &lt;li&gt;第五章，主要是讲如何构建韧性管理（Build Resiliency）。&lt;/li&gt;
&lt;/ul&gt;

&lt;h2 id=&quot;内容剖析&quot;&gt;内容剖析&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;在对全书的五个章节进行剖析之前，有必要说一说作者在序章中提及的团队发展的四个阶段，分别是“组建”（Forming）、“风暴”（Storming）、“成规”（Norming）和“高效”（Performing）。&lt;/p&gt;

&lt;p&gt;简而言之，“组建”阶段可以认为是当一个团队的成员初次集合到一起的时候，团队需要的各种协作和流程都还没有建立。一切方兴未艾。“风暴”阶段是团队的成员之间开始产生“摩擦”（Friction）。作者认为，这个阶段是团队成长的必要阶段，需要有这个阶段的“疑惑”（Confusion）和“冲突”（Clashing）来达到下一个阶段。“成规”阶段是事情慢慢得到了解决，团队成员之间的差别得到了调和。最后，“高效”阶段是整个团队有序得运行，你们开始“交付”（Ship）产品。&lt;/p&gt;

&lt;p&gt;需要指出的是，这四个阶段并不是一次性的，而是循环往复的团队生存周期。这是因为团队永远处于持续地变化中，例如有新成员加入、团队的宗旨发生了变化等。全书也算是围绕着这四个阶段来进行展开讨论的。&lt;/p&gt;

&lt;p&gt;接下来，我们针对书中的五个章节为大家进行剖析。&lt;/p&gt;

&lt;h3 id=&quot;结识你的团队&quot;&gt;结识你的团队&lt;/h3&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/lara_1.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;这一章主要是讲在团队“组建”阶段，我们如何去了解团队成员的“核心需求”（Core Needs）以及他们的工作模式（Work Styles）。同时，这个阶段也需要让团队成员了解你。&lt;/p&gt;

&lt;p&gt;书中提到了六个和工作相关的“核心需求”：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;第一个是“归属感”（Belonging），也就是团队成员对一个社群（Community）或者团队的一种认同度，是否觉得自己是其中一员。当你觉得被团队“遗漏”（Left Out）的时候，这个“核心需求”就受到了伤害，例如团队某一个重要的会议，你没有被邀请参加，或是一个重要的产品发布没有通知你。&lt;/li&gt;
  &lt;li&gt;第二个是“进步感”（Improvement/Progress），也就是说你希望在团队中体会到某种程度上的进步或者是进展。这种进展可以是来自个人的，也可以是整个团队的。有时候，这种“进步感”可能会很难体会到，特别是在比较大的公司中。&lt;/li&gt;
  &lt;li&gt;第三个是“选择感”（Choice），也就是你是否感到对自己的生活和工作进行决策。也许你原本对自己的工作有很大的自主权，但突然公司新加入的一个负责产品的副总裁开始对你的之前计划开始发表意见。这时你可能开始感到“选择感”的失去。另一方面，如果有太多的决策需要做，也可能会造成你不知所措的情况。因此，对于“选择感”而言，我们需要注意“平衡”（Balance）。&lt;/li&gt;
  &lt;li&gt;第四个是“平等感”（Equality/Fairness），也就是你是否收到了平等的对待。当有决策通过的时候，所有参与决策的各个方面是否都有平等地接收到信息，是否平等地接收到了资源。&lt;/li&gt;
  &lt;li&gt;第五个是“预测感”（Predictability），也就是你是否能够对可预见的未来有一个初步的感知，而不是充满了“惊奇”（Surprise）。在日常工作中，大家度希望对未来有一定的把握程度。&lt;/li&gt;
  &lt;li&gt;第六个是“重要感”（Significance），也就是你个人的“地位”（Status），或者说是在团队中扮演什么样的角色，是否能够体现你的价值。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;值得注意的是，这六个核心需求对于每个人而言，并不是有同样的效果。面对一些事情，或者书中提到了“刺激物”（Stimulus），每个人可能会有非常不一样的反应。文中提到了让员工换座位这个例子来说明，这么一件看似简单的事情，有可能会“刺激”到不同人关于上述六个核心需求的反应，值得仔细阅读。&lt;/p&gt;

&lt;p&gt;这一章的第二部分，作者则是在讨论不同人的工作模式，具体说来就是遇到一些问题的时候，不同的人可能会有不尽相同的偏好。作者总结了下面五个方面的模式问题值得每一个经理逐一了解自己的员工：&lt;/p&gt;
&lt;ul&gt;
  &lt;li&gt;“不高兴”（Grumpiness）：什么样的事情可以可以导致员工不高兴，例如缺少咖啡因、没有睡好、不喜欢被“微观管理”（Micromanage）等。&lt;/li&gt;
  &lt;li&gt;“反馈和认可”（Feedback and Recognition）：当需要探讨反馈和认可的时候，每个人可能希望利用不同的媒介来达到目的，例如面对面、电子邮件还是即时聊天工具。特别是一些比较艰难的反馈，媒介的选择就显得尤为重要。&lt;/li&gt;
  &lt;li&gt;“目标和支持”（Goals and Support）：如何支持一个员工的成长以及如何知道员工需要怎样的支持都是作为经理和员工沟通的一个重要话题。&lt;/li&gt;
  &lt;li&gt;“员工成长”（Grow and Learn）：员工成长是一个很难以衡量的事情。然而，帮助员工成长又是经理们责无旁贷的职责。至少每一个季度都花一些时间来确定员工具体的，可以有行动的成长目标。&lt;/li&gt;
  &lt;li&gt;“款待自己”（Treat Yourself）：花时间去了解每一个员工如何款待自己的喜好，也许在未来某个时候需要奖励和表彰员工的时候能够用得上。这里面的偏好差异可能会非常大。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;这一章最后的内容是帮助你的团队认识你，或者反过来说，你希望如何呈现在你的团队面前。&lt;/p&gt;

&lt;p&gt;有两个方面的话题是需要你去思考的。第一，就是你优化的目标是什么？作者认为，这一个问题直接决定了一个经理的“风格”（Style）和“管理哲学”（Philosophy）。当然，优化一个目标往往会伴随着其他目标的缺失，这是需要注意的。第二，一旦你有了优化目标之后，和团队成员交流你这些目标有助于整个团队统一思想，同时也能够帮助你的团队成员设置有效的预期。&lt;/p&gt;

&lt;h3 id=&quot;扩展你的团队&quot;&gt;扩展你的团队&lt;/h3&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/lara_2.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;我们之前提到的团队发展的四个阶段，这一章主要在讲“风暴”阶段团队的成长。&lt;/p&gt;

&lt;p&gt;为什么会有“风暴”阶段呢？团队在之前每一个个体的运作阶段可能并没有太多的问题。因为从本质上来说，团队并不是一个有机的整体，而是个体的集合，因此，一旦我们开始整合团队的所有人，开始设立一些流程，团队在协作、沟通等方面就都会出现广泛的“摩擦”。这几乎是可以预期的。&lt;/p&gt;

&lt;p&gt;书中说，在这个阶段，作为经理的你，需要做好下面四件事情。&lt;/p&gt;

&lt;p&gt;第一件事情，就是扮演好“导师”的角色（Mentoring），也就是直接给出建议并且帮助员工解决问题。这里，我们依靠的更多的是自己的经验。作为一名“导师”，我们需要注意的是对提供建议的人与环境有一定敏感程度。对一个人有意义的建议可能会对另一个人有伤害。另外，“导师”这个角色往往对初入角色（Role）的新人更有帮助，而对于已经有了一些成长的员工而言，更需要另外的指导手段。&lt;/p&gt;

&lt;p&gt;第二件事情，就是扮演好“教练”的角色（Coaching），也就是通过和指导对象进行对话，问“开放式”问题（Open Questions）来达到引导员工自省并且找到解决问题的方案。这个角色和“导师”是很不一样的。“导师”需要对问题以及解决方案都有所关注，而“教练”的角色则更加注重在分析问题上。两个重要的技巧是问“开放式问题”和“反思”（Reflection）。“开放式问题”必须让人觉得真诚，是你带有真正的好奇心来问的问题。这些问题有助于指导对象来进行更深层次的思考。“反思”是希望你能作为对方的一面“镜子”。把对方已经表达过的观点进行二次“翻译”，看是否能够抓住问题的核心。在这样的反复对话中，我们可以帮助指导对象来达到对当前问题的更深层次的理解和提出更好的解决方案。&lt;/p&gt;

&lt;p&gt;第三件事情，就是扮演好“支持者”（Sponsoring）的角色。如果说“导师”和“教练”是你和员工在面对面情况下互动的角色，那么“支持者”这个角色则是你在其他场合所要扮演的角色。这里的“支持”指的是你为指导对象提供并且争取机会，从而能够有力地进入到他职场的下一个层级。&lt;/p&gt;

&lt;p&gt;第四件事情，就是提供“反馈”（Delivering Feedback）。这一部分可能是最难以做好的角色。作者在这里讲了一个“反馈”公式。也就是，我们提供反馈需要首先来自某种行为的“观察”（Observation），然后我们需要描述这个行为的“影响”（Impact），接着，我们需要直接说出需要改变的事情或者是进入“教练”的角色，开始问一些开放式问题，最后，我们需要达到非常具体的，能够执行的反馈。&lt;/p&gt;

&lt;p&gt;在日常的工作中，我们经常需要对这四种角色进行有机得结合，并且在这些角色之间频繁互换。当然，书中也讲了，并不是这些手段都能够永远有效，总有员工可能并不理会你和他互动的好意，因此书中也讲了讲其他的渠道。&lt;/p&gt;

&lt;h3 id=&quot;设置明确的期望&quot;&gt;设置明确的期望&lt;/h3&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/lara_3.jpeg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;这一章主要在讲“成规”阶段的团队发展话题。&lt;/p&gt;

&lt;p&gt;顾名思义，无规矩不成方圆，当团队发展到一定程度，就需要设置一些规则和流程来保证团队运行的顺畅和解决分歧。&lt;/p&gt;

&lt;p&gt;这一章一开始主要讲了如何定义团队中的“角色和职责”（Roles and Responsibilities）。在团队发展的早期，都没有真正定义不同角色和职责的实际需要，一是因为人比较少，二是因为很多时候需要有人能够兼顾多种不同的角色从而能够达到某种情况下的灵活度。然而，随着团队的发展，每个人在日常运行中究竟是什么角色，不同人之间怎么协作，就需要我们开始思考这方面的问题。&lt;/p&gt;

&lt;p&gt;书中介绍了RACI角色定义方法和“维恩图表”（Venn Diagram）来定义“角色和职责”并且用了“工程经理”（Engineering Manager）、“产品经理”（Product Manager）以及“工程负责人”（Engineering Lead）如何建立清晰的职责界限来解释了这些方法的实际使用方法，建议读者精读这部分内容。&lt;/p&gt;

&lt;p&gt;这一章的第二部分讲了如何设置一个团队的“视野”（Vision）以及“优先级”（Priorities）。“视野”是回答你们这个团队为什么存在，究竟是要解决什么终极问题，这样的疑问。这里细分的话，有“视野”（Vision）、“使命”（Mission）、“策略”（Strategy）以及“目标”（Objective）的区别。简单来说，这几类定义是从最宏观到最微观的逐层表述。书中有详细的解释，建议大家读一读。有读者可能会问，对于一个团队来说，设置这些空洞的宏大的主题是否有实际的意义。这里的目的是让一个团队有章可循，特别是团队有任何分歧、有疑虑的时候都随时能够根据团队的“视野”和“优先级”来排除这些纷扰。&lt;/p&gt;

&lt;p&gt;这一章的第三部分讲的是团队的“实践”（Practice）。这一部分主要是指一个团队日常运作的模式，包括有什么样的会议以及交流的渠道（邮件或者即时通讯工具），和这些运作模式都是处理哪些问题。作者认为，即便每一个团队在具体的实践中可能都有了约定俗成的一套流程，最好能够利用文档工具（例如“维基”Wiki）来把这些实践记录下来。同时，作者认为，需要把团队的协作和交互给融合到日常的运作中去。&lt;/p&gt;

&lt;h2 id=&quot;有效的沟通&quot;&gt;有效的沟通&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/lara_4.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;在现代团队发展和运作过程中会遇到大大小小的很多事情，例如公司的目标发生了变化、公司开始经历裁员、新的产品线、公司上市等等。所有这些事情，作为一个经理，你都需要和员工保持良好有效的沟通。有不小挑战性的是，很多这些事情，你并不是直接的决策者，甚至也没有参与其中，但作为当前团队的负责人，你需要有很清晰的头脑如何和团队进行交互和沟通。&lt;/p&gt;

&lt;p&gt;书中首先介绍了如何来规划沟通一些重要的信息。很明显，你需要一个计划。作者介绍了一些沟通计划的模板。总而言之，这些模板的目的是帮助你能够为一些相对复杂的情况有一个更加全面的沟通有所准备。书中作者用一个虚拟的经理离职作为例子，展示了如何为这样一个可能会比较棘手的事件进行沟通准备。&lt;/p&gt;

&lt;p&gt;在这一章的第二部分，作者讲了讲对敏感信息沟通的技巧。敏感信息的挑战来自于可能会触及一些员工的核心需求。比如，我们要沟通一次组织架构的调整，团队的工作方向也许会有调整，那么一些员工的“选择感”和“预测感”都会受到不小的影响。一些员工可能会觉得自己的意见或者声音没有得到抒发的机会。作者认为，敏感信息沟通的核心来自于“迅速”（Swift）而不是拖延好几天甚至是更长时间。有很多事情有可能在更长的等待中发生变化，也就是我们经常说的“夜长梦多”。同时，如何有效得分享一些机密信息，也是需要特别注意拿捏分寸的事情。在一个较大的公司和团队中，任何机密的信息都有可能被泄露出去，作者认为在这种时候，首要任务是沟通并且阐明一些事情的事实，而事后对有可能把机密信息泄露这样的事情进行反思。&lt;/p&gt;

&lt;p&gt;本章的第三个部分，作者探讨了一下，作为经理的你，如何沟通你并不十分认可的决定。在一个比较大的公司中，这样的情况其实比比皆是。公司有很多决策或者变化无法邀请所有人参与。这一方面是不现实一方面也没必要。因此，在公司的运作中，我们就需要学会传达和沟通我们自己并不认同的决定。这里的核心是做到“不认同但负责”（Disagree and Commit）这样一种职业态度。也就是说，虽然你对于某一些决策的内容并不能完全认可，但是你需要去完全执行这些决策的内容并且利用沟通的技巧和团队进行沟通。不过，作者也提出，这种时刻，也是你重新审视自己和当前的团队以及公司还是否能够契合到一起，如果有重大的分歧，离开这样的团队和公司可能是更好的选择。&lt;/p&gt;

&lt;p&gt;本章的第四部分作者讲了讲不同媒介的区别，例如会议、邮件以及即时通讯工具，都具有自身不同的特点，适用于沟通不同的内容。比如，一些重大的决定或者是变化，最好能够通过面对面的会议，甚至是“全公司会议”（All Hands Meeting）来首先传达。而另一方面，邮件沟通可以传达一些没有太多歧义内容的信息，并且能够起到提醒人的作用。&lt;/p&gt;

&lt;p&gt;最后，作者强调，沟通不是一次性的工作，而是本身就需要反复迭代和演化的工作。也就是说，我们需要反复重复重要的信息，在很多场合，和很多媒介。同时，每个公司可能对于如何沟通有不同的企业文化的偏好。&lt;/p&gt;

&lt;h2 id=&quot;构建韧性管理&quot;&gt;构建韧性管理&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/lara_5.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;作者把最后一章的内容献给了如何让当经理的人自身更加富有“韧性”。也许你的团队已经到达了“高效运行”的阶段，但是一个突然的变化，使得你做的很多工作回归原点。千万不要以为变化是一时的，作者认为，处在高速发展的科技公司中，变化是随时随地都在发生的。因此，如何让经理变得更有“韧性”，也就是如何处置随时的变化，以及一一种不变应万变的心态就成为了很重要的议题。&lt;/p&gt;

&lt;p&gt;这一章一开始，作者讨论了如何管理危机时刻（Times of Crisis）。这里的关键是了解你有什么样的资源和工具。每一个公司对待很多情况都有相应的流程。对这些流程有所了解，是你需要处理危机的必备信息。另一方面，是和员工有良性的和真挚的沟通，让他们觉得你是可以依赖的伙伴。&lt;/p&gt;

&lt;p&gt;这一章的第二部分，则在讨论如何管理你自己的“能量”。简而言之，那就是如何能够使自己保持一个正能量的心态。作者的一个建议是时刻关注我们被什么样的事情所消耗时间和精力。也就是看看自己的日历，平时都参加什么样的会议。这里，需要你对自己的时间有一个深层次的了解以及有一些如何应对这些事物的想法。然后，书中介绍了不少的技巧，可以用于管理自己的时间使自己更高效，例如重新安排自己的任务，把一部分任务给代理出去、对一些事情说“不”等等。读者可以好好阅读一下这部分内容。&lt;/p&gt;

&lt;p&gt;本章的最后是探讨如何构建自己的“支持网络”（Support Network）。作为一个经理而言，“你不是一个人在战斗”，但往往，我们可能觉得自己是“孤家寡人”。作者提出了“支持网络”这个概念，也就是说，我们需要去构建自己的网络来获取更多的信息，学习更多的技能，以及扩宽自己的社交网络。同时，作者也提到了“第一团队”（The First Team）的概念，也就是当发生任何变化以及需要做一些复杂决策的时候，你最先寻求帮助和信息的人都是什么人，而这些人都能够提供哪一些不同的视角。这一部分内容可以算是经理职业发展的高级话题。&lt;/p&gt;

&lt;h2 id=&quot;总结点评&quot;&gt;总结点评&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;这本书可以说是作为技术管理人的经典入门的参考书。作者Lara Hogan作为在工业界有丰富经验的技术经理人写作的次数可以说是有非常强的实战指导价值。书中有不少可以直接拿来用的技巧、模板和方法。同时，书中的一些案例也是来源于实际工作。与同类型的&lt;a href=&quot;http://column.hongliangjie.com/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0,%E7%AE%A1%E7%90%86/2019/12/25/the-manager-path/&quot;&gt;《经理人之路——技术领袖启航成长与变化的参考书》&lt;/a&gt;相比，本书更加短小精悍，并且非常适合需要对技术管理快速入门的初级技术管理人员。从结构上看，全书的五个章节都相对独立但又和在序章中讲到的团队的发展历程的几个阶段有着紧密的联系。建议对技术管理有兴趣的读者精读。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>《从数据中学习》总结</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0,%E6%9C%BA%E5%99%A8%E5%AD%A6%E4%B9%A0,%E6%95%99%E6%9D%90/2020/06/25/learning-from-data/"/>
   <updated>2020-06-25T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0,%E6%9C%BA%E5%99%A8%E5%AD%A6%E4%B9%A0,%E6%95%99%E6%9D%90/2020/06/25/learning-from-data</id>
   <content type="html">&lt;p&gt;今天我们要来总结技术书籍&lt;a href=&quot;https://www.amazon.com/Learning-Data-Yaser-S-Abu-Mostafa/dp/1600490069&quot;&gt;《从数据中学习》&lt;/a&gt;。这本书是一本浅显易懂的机器学习理论知识的入门教材。对于机器学习感兴趣的工程师和希望在理论知识上更进一步的数据科学家可以通过本书来快速了解机器学习的核心思想，也就是“学习理论”（Learning Theory）的重要结论。本书的三位作者都来自学术界。全书书写通畅，公式和理论推导也很基础，适合自学的初学者。&lt;/p&gt;

&lt;h2 id=&quot;作者简介&quot;&gt;作者简介&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/learningfromdata.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;本书有三位作者。&lt;/p&gt;

&lt;p&gt;第一作者&lt;a href=&quot;https://work.caltech.edu/&quot;&gt;Yaser Abu-Mostafa&lt;/a&gt;是加州理工学院&lt;a href=&quot;https://www.caltech.edu/&quot;&gt;（California Institute of Technology）&lt;/a&gt;电子工程与计算机系的教授。Yaser于1979年从开罗大学学士毕业之后于1981年从佐治亚理工学院获得硕士学位，然后于1983年从加州理工学院获得博士学位。Yaser和他人于1987年筹办了第一届此后享有盛誉的神经信息处理系统大会（NeurIPS）。&lt;/p&gt;

&lt;p&gt;第二作者&lt;a href=&quot;https://www.cs.rpi.edu/~magdon/&quot;&gt;Malik Magdon-Ismail&lt;/a&gt;是伦斯勒理工学院&lt;a href=&quot;https://www.rpi.edu/&quot;&gt;（Rensselaer Polytechnic Institute）&lt;/a&gt;计算机科学系的教授。Malik于1993年从耶鲁获得物理学士学位，然后分别于1995年和1998年从加州理工学院获得物理硕士和计算机博士学位。&lt;/p&gt;

&lt;p&gt;最后一个作者&lt;a href=&quot;https://www.csie.ntu.edu.tw/~htlin/&quot;&gt;Hsuan-Tien Lin&lt;/a&gt;是国立台湾大学计算机和信息工程系教授。Hsuan-Tien于2001年从国立台湾大学获得计算机和信息工程系学士然后于2008年从加州理工学院获得计算机博士学位。&lt;/p&gt;

&lt;h2 id=&quot;全书结构&quot;&gt;全书结构&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;全书大体有下面五个章节&lt;/p&gt;

&lt;p&gt;第一章，是对于“学习问题”（The Learning Problem）的一个总体的设置和介绍。这部分介绍了不同类型的“学习场景”，例如“监督学习”（Supervised Learning）、“强化学习”（Reinforcement Learning）以及“无监督学习”（Unsupervised Learning），以及最重要的内容“学习”的“可行性”（Feasibility）。&lt;/p&gt;

&lt;p&gt;第二章，是进一步展开“学习”的“可行性”方面的内容，详细来探讨“泛化理论”（Theory of Generalization），也就是我们常说的为什么我们能够通过“训练集”（Training）上的一些结论来扩展到“测试集”（Testing）甚至是未知的数据上。在这一章，作者们介绍了重要的“VC维度”（The VC Dimension）以及如何理解“泛化界限”（Generalization Bound）。&lt;/p&gt;

&lt;p&gt;第三章，作者们详细介绍了最简单的模型“线性模型”（The Linear Model）。这其中包括了针对回归问题的“线性回归”（Linear Regression）以及分类问题的“对数几率回归”（Logistic Regression）。&lt;/p&gt;

&lt;p&gt;第四章，作者们详细的阐述了关于“过拟合”（Overfitting）的观点。在其他教材中，“过拟合”的内容往往是简单带过，和“线性模型”类似，这本书对于“过拟合”的讲解可以说是非常有阅读价值。&lt;/p&gt;

&lt;p&gt;第五章，作者们讲解了三个重要的“学习”原理（Learning Principles）：“奥卡姆剃刀”（Occam’s Razor）、“采样偏差”（Sampling Bias）和“数据窥探”（Data Snooping）。如果在实践中不注意这些问题，那之前讲的“泛化保证”则不能提供有效的理论支持。&lt;/p&gt;

&lt;p&gt;整本书可以说是把“学习理论”（Learning Theory）中的重要概念以及机器学习的核心思想深入浅出得进行了讲解，非常适合机器学习的初学者。&lt;/p&gt;

&lt;h2 id=&quot;内容剖析&quot;&gt;内容剖析&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;我们接下来就针对书中的一些重点内容为大家进行剖析。&lt;/p&gt;

&lt;h3 id=&quot;从训练集到未知数据的泛化历程&quot;&gt;从训练集到未知数据的泛化历程&lt;/h3&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/lt.png&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;经典的“监督学习”设置可以简化为如何通过一组数据输入$ \mathbf{x} $来学习一个未知函数$ f $。这里面有两个难点，一是我们对$ f $一无所知，二是数据有限。如何能够构造出一套理论来对于这样一个问题进行描述成为了机器学习需要解决的核心问题，也就是“学习”的“可行性”问题。&lt;/p&gt;

&lt;p&gt;书中在第1.3节解决了“学习可行性”的第一个障碍，也就是把“概率化”的语言引入关于“可行性”的讨论中。直观得说，希望能够“确定性”得学习一个未知的$ f $是很难的，我们没有数学工具来对这样的场景提供有效的结论。但如果我们用概率的眼光来看，则可以针对学习$ f $的精准度进行严格地描述。这个根本性的思路来自于对于随机事件的理解。例如有一个瓶子里放着一定数量的红球和一定数量的白球。如果我们的任务是根据已经从瓶子里拿出的一些球是否是红色或者白色来确定性得估计红球和白球的比例，这是没有保证的。但如果我们以一定正确的概率去估计红球和白球的比例则有定量的结论。&lt;/p&gt;

&lt;p&gt;这个定量的结论来自于概率论中的“霍夫丁不等式”（Hoeffding Inequality）:&lt;/p&gt;

\[P(|\bar{X} - \mathbb{E}[X] | &amp;gt; \epsilon ) \leq 2e^{-2\epsilon^{2}N}\]

&lt;p&gt;这里，$ X $是一个随机变量，$ \bar{X} $是这个随机变量的均值，然后$ \epsilon $是一个误差项。简单说来，“霍夫丁不等式”对于样本均值作为参数的估计值和参数真值之间的差距给出了一个“界限”（Bound）。这个“界限”和样本数据量$ N $有关，并且随着数据的增多，参数的估计值和真值的差距大于一个事先约定的范围的可能性会以指数方式降低。这个结论的魅力来自于我们并不需要知道参数真值，我们只需要进行操作的是作为参数估计值的样本均值。另外，这个结论的优势在于它是概率意义上的。也就是说，我们并不能100%确保估计准确，但是准确性的保证来源于随着数据增多而减小的可能性。这个可能性虽然很小但一直存在。&lt;/p&gt;

&lt;p&gt;把“霍夫丁不等式”应用到机器学习的场景我们需要两个概念。一个是根据样本数据集得来的“样本内误差”（In-Sample Error）:&lt;/p&gt;

\[\mathbb{E}_{in}[h] = \frac{1}{N} \sum_{n=1}^{N} \mathbb{I}(h(\mathbf{x}_{n}) \neq f(\mathbf{x}_{n}))\]

&lt;p&gt;这里的$ h $是对于$ f $的一个估计，然后$ \mathbb{I}(x) $在$ x $的时候等于$ 0 $另一个则是在全数据集上的“样本外误差”（Out-of-Sample Error）：&lt;/p&gt;

\[\mathbb{E}_{out}[h] = P(h(\mathbf{x}) \neq f(\mathbf{x}))\]

&lt;p&gt;我们无法衡量“样本外误差”，但是根据“霍夫丁不等式”，我们可以对其利用“样本内误差”进行估计，并且估计的错误率是一个随着样本数据量N增大而指数式减小的数值:&lt;/p&gt;

\[P(|\mathbb{E}_{in}[h] - \mathbb{E}_{out}[h] | &amp;gt; \epsilon ) \leq 2e^{-2\epsilon^{2}N}\]

&lt;p&gt;这可以说是“学习理论”的第一大步。我们可以利用样本数据集上的估计来针对参数的真值进行描述。接下来遇到的困难来自于，刚才所说的“样本内误差”和“样本外误差”都依赖于我们选择的某一个特定的“假设”（Hypothesis）$ h $。也就是说，我们如果要估计$ f $，我们只要选择一个$ h $，就能利用“霍夫丁不等式”来对$ h $和$ f $的“样本外误差”进行评估。但是，很明显，我们需要评价具有可能性的$ h $的总数目也许是无限多，这就造成了一个重大难题。在我们讨论无限数目的假设空间之前，作者们展示了“霍夫丁不等式”可以被推广到有限数目$ M $的情况，也就是参数的估计值和真值之间误差的“界限”是一个同时和$ N $以及$ M $有关的数量:&lt;/p&gt;

\[P(|\mathbb{E}_{in}[g] - \mathbb{E}_{out}[g] | &amp;gt; \epsilon ) \leq 2Me^{-2\epsilon^{2}N}\]

&lt;p&gt;注意，这里的$ g $和$ h $有所不同，书中详细讲了两者的关系，我们这里的讨论可以忽略这个差别。下面的进展需要我们拿掉对于$ M $的依赖。&lt;/p&gt;

&lt;p&gt;第一个观察来源于我们对于所有M甚至是无限数目的假设空间的一个洞察，那就是这些假设往往很类似。在第2章里，作者们开始阐述我们需要真正在意的是有效的假设数目（Effective Number of Hypotheses）而不是所有的甚至是无限多个假设数目。这里一个巧妙的构造来自于我们理解一个假设h的视角并不专注于这个假设本身而在于这个假设在一个数据集上的表现。也就是说，我们通过数据来观察一个假设的表现。对于一个二分问题（Binary Classification），无论假设本身如何，我们都可以在一个给定的数据集上获得一个假设在这个数据集上作用所得到的一些“正例”和“负例”的判别结果。而两个不同的假设很可能在一个数据集上产生的“正负例”判别结果是一样的。我们把一组“正负例”结果叫做一个“二分”（Dichotomy）。那么，一个包含很多假设的“假设集合”就对应一个包含众多“二分”的“二分集合”。我们把一个数据集N上能够通过某个假设集合H所产生的最多的二分集合数目定义为“增长函数”（Growth Function）在这个数据集和假设集合上的取值。换句话说，“增长函数”是一个依赖于数据集和假设集合的函数。如果一个假设集合H可以产生一个数据集上所有可能的“二分”，我们就说这个假设集合H“散开”（Shatter）了这个数据集。回到之前提到的问题，那就是我们希望替换掉“霍夫丁不等式”中对于$ M $的依赖。整个这个部分的讲述就是要引出“增长函数”这个重要的工具。&lt;/p&gt;

&lt;p&gt;有了“增长函数”的概念之后，我们肯定希望“增长函数”是有一个上界的，而这个上界最好和假设集合的总数目没有关系。这样，我们就可以达到目的从而让参数的估计值和真值之间的误差和我们需要评价的假设数目最好没有关系。&lt;/p&gt;

&lt;p&gt;为了解决这个问题，我们就要引入最后一个重要定义。那就是“VC维度”。一个假设集合H的“VC维度”（VC Dimension）是这个假设集合所对应的“增长函数”等于$ 2^{N} $所能对应到的最大的$ N $值。形象地说，也就是我们不断增大$ N $，看假设集合H能否“散开”当前$ N $所对应的数据集，如果是，那就继续增大，直到最后一个可以“散开”的$ N $值。如果我们对于所有的$ N $值，我们总能“散开”当前N所对应的数据集，我们就定义“VC维度”为无限。&lt;/p&gt;

&lt;p&gt;对于初学者来说，这一部分的内容概念比较密集而且抽象。作者们很快举了几个例子来说明“增长函数”以及“VC维度”在某一些特定的数据集上的存在以及给出了它们的表达式。&lt;/p&gt;

&lt;p&gt;下面的一个难点就在于如何把“增长函数”给“界限”住。书中有不少的细节。我们这里直接引述结论，那就是如果对于某个假设集合$ H $我们可以找到“VC维度”，“增长函数”就有一个上限。这个上限是一个和N以及“VC维度”有关的多项式加和公式。简而言之，那就是“增长函数”在这样的情况下是被“VC维度”所“界限”住的。有了这些基石之后，作者们就推出了书中最重要的结论（公式2.21），我们在这里重复出来：&lt;/p&gt;

\[\mathbb{E}_{out}[g] \leq \mathbb{E}_{in}[g] + \sqrt{\frac{8}{N}\ln \frac{4m_{N}(2N)}{\delta}}\]

&lt;p&gt;公式的证明并没有在正文中，而是放到了附录里。但是公式的核心思想就是我们之前提到的“样本中误差”和“样本外误差”的关系被一个带有“增长函数”的不等式所“界限”。这个不等式和我们之前所说的“霍夫丁不等式”非常类似，只是其中没有了对于$ M $的依赖，而变成了对于“增长函数”的依赖。有了这个重要的工具之后，再加上上面所说的我们利用“VC维度”对于“增长函数”进行“界限”。我们就更进一步得到了一个“样本中误差”和“样本外误差”的关系被“VC维度”所“界限”的结论。而这个结论就具备可操作性了，因为很多情况下，我们可以直接计算“VC维度”。&lt;/p&gt;

&lt;p&gt;这部分的讲解（整个第2章）可以说深入浅出得介绍了“学习理论”中最重要的一组结论。&lt;/p&gt;

&lt;h3 id=&quot;机器学习的噩梦过拟合&quot;&gt;机器学习的噩梦——“过拟合”&lt;/h3&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/overfit.png&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;本书在第4章详细探讨了机器学习中“过拟合”（Overfitting）的现象以及一些解决方案。&lt;/p&gt;

&lt;p&gt;首先，书中利用一些例子来展示了“过拟合”现象的存在性，那就是有的模型可以在训练集上获得非常小甚至是零的“样本内误差”但在训练集之外有着非常惊人的“样本外误差”。换句话说，这些模型只有很弱的甚至是没有“泛化”能力。这种“过拟合”的现象在对于一个相对简单的模型和一个相对复杂的模型进行比较的时候会显得尤为明显。比如书中利用一个10阶多项式函数来产生一组有噪声的数据，然后利用一个2阶多项式和另一个10阶多项式来拟合产生的数据。如果我们来比较两个模型的“样本内误差”则可以发现10阶多项式好像能够更好得拟合10阶多项式所产生的训练数据。然而令人吃惊的是，如果我们来比较两个模型的“样本外误差”，则会发现2阶多项式相比于10阶多项式有更好的“泛化”能力。这里面可能会让人疑惑的就是，按理说，我们利用10阶多项式来拟合10阶多项式产生的数据应该会比2阶多项式有更好的“泛化”能力，因为这里相当于是利用了“真模型”（Ground Truth）的信息。书中提供的一种解释是虽然10阶多项式作为“真模型”这个信息有价值之处，但是总体而言，10阶多项式相比于2阶多项式需要更多的数据来拟合，同时对于有噪声的数据，复杂模型更容易去拟合数据中的噪声，从而导致了弱化的“泛化”能力。&lt;/p&gt;

&lt;p&gt;机器学习中，一个经常使用的来减弱“过拟合”现象的工具叫做“正则化”（Regularization）。书中提醒，绝大多数“正则化”的方法都是“启发法”（Heuristics）。也就是说，这些方法可能并没有太多的理论基础，而是在实际使用中有比较好的效果。书中介绍了“权重衰减”（Weight Decay）这种“正则化”方法。简单来说，“权重衰减”就是指，我们把模型中学习到的参数，或者叫系数，或者叫权重，人为得进行数值上的“衰减”，也就是使其变小，甚至是归零。这种做法的初衷是让学习算法不因为一些数据中的异常值，通常是噪声，来误导模型学习到过大的权重。“权重衰减”往往会通过更改目标函数（Objective Function）的方式来达到同时拟合数据以及让参数变小这两个目的。&lt;/p&gt;

&lt;p&gt;针对“过拟合”的另外一个工具是构造一个“验证集”（Validation）。“验证集”和“测试集”非常类似，也就是这部分数据不能用作模型的训练。“验证集”和“测试集”的区别在于，这部分数据可以用于对于模型的一些决策，例如帮助选择模型的参数。在日常的机器学习实践中，我们经常利用K个“验证集”来进行模型选择或者参数选择的流程，从而达到减小“过拟合”的效果。&lt;/p&gt;

&lt;h3 id=&quot;三大学习原理&quot;&gt;三大学习原理&lt;/h3&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/or.png&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;在本书的第5章，也就是全书的最后，作者们总结了三个重要的机器学习原理。&lt;/p&gt;

&lt;p&gt;第一个原理是“奥卡姆剃刀”。简单说来“奥卡姆剃刀”讲的是，能够拟合数据中的最简单的模型往往是最有道理的。这个原理还可以被说成，在能够拟合数据的众多模型中，我们往往更偏向于简单的那个。需要说明的是，如何衡量模型的简单与否，或者说如何衡量模型的复杂度，是一个值得探讨的问题。例如书中讲过的VC维度以及“正则化”所代表的误差项等都是某种衡量模型复杂度的方法。另外，“奥卡姆剃刀”也提供了一种在实践中经常使用的方法，那就是对于一组数据，我们往往先开始尝试使用简单模型进行拟合，然后逐渐把模型复杂化，看是否能够增强拟合，同时注意“验证集”的错误率。&lt;/p&gt;

&lt;p&gt;第二个原理是“样本偏差”，指的是如果数据是通过有偏差的采样所获得的，那么学习也会产生类似的有偏差的结果。“样本偏差”有时候非常难以发现。例如，书中举了一个例子，那就是我们利用华尔街的股票数据进行建模，可能会找到模型能够很好得拟合过去的股票高低起伏信息。然而这样的模型是带有很大的偏差的，原因就是，华尔街这十几年表现不好的股票有可能已经退市，而如果我们选择数据中仅仅包含一直存在的股票，这本身就是一种选择性“偏差”。&lt;/p&gt;

&lt;p&gt;最后一个原理叫“数据窥探”。简而言之，“数据窥探”是说如果一个数据集影响了学习算法的任何一个流程，那么这个数据集对于结论的有效性就已经也受到了影响。这是在机器学习实践中经常遇到的陷阱。换句话说，我们要杜绝“测试集”的信息“泄露”并且影响到我们学习算法的任何一个流程。例如，我们首先看了数据貌似符合线性规律以后，然后采用线性模型进行拟合；再例如，我们利用了“测试集”数据和“训练集”数据一起对整个数据集进行一些数据预处理。更普遍的陷阱来源于，对同一个数据集反复使用，也就是说，在不同数据集上反复测试不同的算法，直到找到测试数据集上表现好的模型位置。书中重点解释了这样做的结果就是理论上我们推导的VC维度无法来对结论进行“泛化”保证。&lt;/p&gt;

&lt;h2 id=&quot;总结点评&quot;&gt;总结点评&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;这本书可以说是作为机器学习入门的一个参考教材。和大多数希望涵盖众多内容的机器学习通用教材相比，本书可以说是短小精悍，而且专注在机器学习、特别是学习理论（Learning Theory）方面最基本的介绍。整本书的行文非常通顺而且理论证明部分也毫不晦涩，非常适合有了一定机器学习基础，又希望能够在理论上有所了解的工程师和数据科学家。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>《值得信赖的在线可控实验——A/B实验实用向导》总结</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0,%E5%9C%A8%E7%BA%BF%E5%AE%9E%E9%AA%8C/2020/05/08/online-tests/"/>
   <updated>2020-05-08T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0,%E5%9C%A8%E7%BA%BF%E5%AE%9E%E9%AA%8C/2020/05/08/online-tests</id>
   <content type="html">&lt;p&gt;今天我们要来总结技术书籍&lt;a href=&quot;https://doi.org/10.1017/9781108653985&quot;&gt;Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing&lt;/a&gt;。这本书的三位作者在业界享有盛誉，他们在在线可控实验、实验平台的搭建和运维以及如何构建数据驱动化的公司企业文化有着丰富的经验。全书是数据科学家、机器学习工程师、产品经理以及一切对在线可控实验有兴趣的研发人员的必读参考书，是技术书籍领域的经典。&lt;/p&gt;

&lt;h2 id=&quot;作者简介&quot;&gt;作者简介&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/onlinetests.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;本书有三位作者，都是来自互联网公司从事在线实验运行、管理和研究工作多年的专业人员。&lt;/p&gt;

&lt;p&gt;第一作者&lt;a href=&quot;https://www.linkedin.com/in/ronnyk/&quot;&gt;Ron Kohavi&lt;/a&gt;在成书时担任Airbnb的副总裁和技术院士（Technical Fellow）。之前Ron长期担任Microsoft的集团副总裁和技术院士，负责在线实验平台的工作。在加入Microsoft之前，Ron担任Amazon数据挖掘和个性化方面的总监。Ron于斯坦福大学获得计算机博士学位，他有非常丰富的学术论文发表经历，有很多关于在线可控实验方面的经典之作以及帮助扩大这方面研究影响力的课程和演讲。&lt;/p&gt;

&lt;p&gt;第二作者&lt;a href=&quot;https://www.linkedin.com/in/diane-tang-2a2477/&quot;&gt;Diane Tang&lt;/a&gt;在成书时是Google的技术院士（Technical Fellow），专注于大规模数据分析以及基础设施、在线可控实验和广告系统的研发。她于斯坦福大学获得博士学位。下文要提到的“并发实验”的架构就是Diane（和其他合作者）于2010年的KDD上首次提出。&lt;/p&gt;

&lt;p&gt;第三作者&lt;a href=&quot;https://www.linkedin.com/in/ya-xu-59346919/&quot;&gt;Ya Xu&lt;/a&gt;在成书时是负责LinkedIn的数据科学和实验平台系统的资深总监，之前在Microsoft任职。Ya于斯坦福大学获得统计博士学位，其发表过诸多关于在线可控实验的论文并且经常在诸多顶级学术与工业界的会议中发表演讲。&lt;/p&gt;

&lt;h2 id=&quot;全书结构&quot;&gt;全书结构&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;全书大体上可以分为以下五部分内容。&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;第一部分，是对于“可控实验”（Controlled Experiments）基础知识和信息的介绍。作者们讲解了什么是可控实验和为什么要做可控实验等基础问题后，利用一个虚构的电商网站测试界面的例子完整得展示了如何设置和分析一个在线可控实验的全流程。同时，作者们开始介绍一些理解实验结果的“陷阱”和“谬误”，为后面章节详细介绍针对这些问题的解决方案打下基础。最后，作者们讨论了“实验平台”（Experimentation Platform）和公司文化对于如何利用实验来建立“数据驱动”（Data Driven）文化的必要关系。&lt;/li&gt;
  &lt;li&gt;第二部分，是几个有针对性的专题，主要探讨了速度对于网站运行的重要性、“指标”（Metric）的选取以及如何建立“机构记忆”（Institutional Memory）等。&lt;/li&gt;
  &lt;li&gt;第三部分，是探讨了当可控实验变得不可能的时候，如何使用现有的数据进行&lt;a href=&quot;https://en.wikipedia.org/wiki/Observational_study&quot;&gt;“观察研究”（Observational Studies）&lt;/a&gt;。这部分技术是对可控实验的有效补充。&lt;/li&gt;
  &lt;li&gt;第四部分，是针对实验平台的高级内容，包括如何运行“客户端”（如手机）的实验、如何进行“检测设置”（Instrumentation）、如何选择“随机化单元”（Randomization Unit）、如何“发布实验”（Ramping Experiment）以及如何规模化实验分析。&lt;/li&gt;
  &lt;li&gt;第五部分，是针对实验分析的高级内容，包括如何进行统计统计假设检验、“方差缩减”（Variance Reduction）、A/A实验、如何处理“样本比率偏差”（Sample Ratio Mismatch）以及衡量“长期效果”（Long-Term Treatment Effects）。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;整本书可以说是包含了丰富的经验之谈和理论论述。&lt;/p&gt;

&lt;h2 id=&quot;内容剖析&quot;&gt;内容剖析&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;我们接下来就针对书中的一些重点内容为大家进行剖析。&lt;/p&gt;

&lt;h3 id=&quot;数据驱动的企业文化&quot;&gt;数据驱动的企业文化&lt;/h3&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/datadriven.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;在线A/B实验已经成为了今日互联网和软件工业中必不可少的数据驱动工具。很多公司把是否应用在线实验当做一个公司是否数据驱动的一个试金石。本书用了“爬”（Crawl）、“走”（Walk）、“跑”（Run）以及“飞”（Fly）四个阶段来对公司如何利用在线实验来达到数据驱动的成熟程度进行了分类（第4章）。&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;“爬”这个阶段主要是公司对最基本的检测设置和数据科学能力进行搭建。在这个阶段的实验平台主要是解决能够进行实验的设计、执行和分析。团队可以并且已经运行了一些实验。这些成功的案例有助于进行到下一个阶段。&lt;/li&gt;
  &lt;li&gt;“走”这个阶段主要是从可以运行少量的实验到定义一系列标准指标并且开始运行更多的实验。在这个阶段，团队开始运行更加复杂的一些检测来持续验证“检测设置”并且能够通过运行A/A实验来验证平台潜在的问题，同时能够进行“样本比率偏差”检测。&lt;/li&gt;
  &lt;li&gt;“跑”这个阶段对于团队来说，已经可以运行大量的实验，并且各种指标也都相对成熟。公司能够利用“综合评测指标”OEC（Overall Evaluation Criterion）来进行多个指标之前的权衡。整个组织利用实验来对绝大多数的新功能和改动进行测试。&lt;/li&gt;
  &lt;li&gt;“飞”这个阶段则是团队的几乎所有改动都需要经过在线实验的验证。“功能团队”（Feature Teams）已经可以在没有数据科学家的辅助下对大多数的实验进行独立的分析和运作。整个平台的专注点转移到了大规模自动化以及建立“机构记忆”上。同时通过对过去实验的分析，整个平台的有效性和针对实验运行的最佳实践也能够得到不断得更新。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;书中强调团队不管在哪个阶段，领导在多个层面的支持（Buy in）是团队能够成功的重要因素。同时，在建立真正的数据驱动团队的过程中，领导的意见（也就是所谓的Highest Paid Person’s Opinion）和完全依靠直觉的产品开发都是需要逐渐被大规模实验和数据驱动所替代的。因此，在这个过程中，领导需要建立起机制来帮助团队慢慢过渡到“飞”这个阶段。除了领导的支持，书中强调了机制和“机构记忆”的重要作用。也就是说，平台和分析本身只是有效的数据驱动团队的重要组成部分，但团队说到底还是人与人协作的平台。因此，书中（第四章）提到了很多有效的机制来帮助团队拥抱实验文化，例如在团队内部开发关于实验平台和实验分析的课程让更多的人能够接触到这样的知识和技能；再例如在实验平台发展的早期举行例行的会议来针对实验的假设、不同“指标”之间的取舍等进行讨论从而加强这部分企业文化的建设。&lt;/p&gt;

&lt;p&gt;作者们也给出了作为企业希望利用在线实验来达到数据驱动的三个重要的条件（第1章）。&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;第一个条件是企业希望利用数据进行决策并且希望能够通过标准化OEC。换句话说，一个企业希望把对于前进目标的讨论和取舍都能够融入一个标准化的OEC并且能够清晰得让整个企业都理解和为之奋斗。&lt;/li&gt;
  &lt;li&gt;第二个条件是企业愿意为实验平台等基础设施以及实验结果的可信性进行投资。我们前面提及了企业在应用实验来进行决策的几个阶段。很明显，每一个阶段都有软件、组织流程和企业文化等方面的持续投入。这里面，作者们专门提到了实验结果的可信性。也就是说，得到数字容易，但是能够得到让人信赖的数字则需要下不小的功夫。&lt;/li&gt;
  &lt;li&gt;第三个条件是企业愿意承认自己对于不同的想法很难确定它们的价值。这一点尤为重要，在书中被反复提及。首先，这个观点的第一层信息是作者们观察到很多企业，即便是运行大量实验的成熟企业例如微软，也只有近30%的实验结果是正向积极的，能够最终发布到整个的网站。其次，这个观点的第二层信息就是对于单个想法，很多时候我们都很难去衡量它的好坏。作者举了好一些例子展示一些积极有价值的想法在早期都得到了不小的忽视。&lt;/li&gt;
&lt;/ul&gt;

&lt;h3 id=&quot;实验平台的架设&quot;&gt;实验平台的架设&lt;/h3&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/exps.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;A/B在线实验的思想非常直观，但这并不代表实验平台的搭建和演化是一件容易的事情。实验平台有诸多方面需要很细致的关注，而一些微小的决策错误往往可能带来完全不可信的实验数据。可以说是细节决定成败。&lt;/p&gt;

&lt;p&gt;书中谈到的一个可以说是非常有意思的有关实验平台的“陷阱”（第3章）那就是利用“页面跳转”（Page Redirect）来实现针对“控制组”和“对照组”之间的分流。如果“控制组”不经过“页面跳转”而“对照组”经过“页面跳转”，这样的设计往往会带来两部分流量之间产生细微的但可以被检测出来的差别。从这个例子可以看出实验平台实现细节的重要性。&lt;/p&gt;

&lt;p&gt;早期的实验平台都只支持“单层”（Single Layer）架构，意思就是100%的流量被分配到几个“流量桶”（Bucket）中。这些“流量桶”互相独立互不干涉。这样每个“流量桶”对应一个“对照组”（Treatment）。我们可以针对一系列“对照组”同时进行实验。然而，我们很容易发现，在这样的设置下单位时间内可以测试的“对照组”数目是有限的。因而，我们可能需要面临“流量”不够的情况。书中（第4章）介绍了“并发实验”（Concurrent Experiments）的概念，也就是“多层”（Multiple Layer）架构，可以允许多个实验同时在某一块流量上运行。当然，这虽然带来了理论上可以有无限流量的好处，但也为实验的分析提出了更高的要求。一般来说，我们需要能够分析两两实验之间的“交互”（Interaction）效果。成熟的实验平台需要能够支持“并发”实验以及能够检测实验之间的“交互”效果。&lt;/p&gt;

&lt;p&gt;实验平台另外一个需要注意的技术点，那就是如何选取“随机单元”（Randomization Unit）的问题（第15章）。什么是“随机单元”呢？简单来说，“随机单元”就是实验平台选取的达到随机化的最小“单元”。一个通常的网站，我们可以选择“页面级别”、“会话级别”以及“用户级别”的“随机单元”。例如，如果我们选择“页面级别”的“随机单元”，实验平台就可以针对某一个页面，用户每一次打开页面的时候来决定把用户导向某个“对照组”。这几种选择自然意味着不同的取舍，并没有一定的优劣之分。第一，我们需要考虑的是“随机单元”和“分析单元”（Analysis Unit）之间的关系。最简单的情况那就是“随机单元”和“分析单元”一致。比如，一个经常采用的策略就是“随机单元”和“分析单元”都采用“用户级别”。两种单元之间的不一致性往往使得实验分析更加复杂。&lt;/p&gt;

&lt;p&gt;最后，书中提及了“实验发布“（Ramp）是一个往往容易忽视但又非常重要的步骤。从比较小的流量慢慢发布到相对比较大的流量知道最后全站发布，整个过程需要的是自动化和风险控制的结合。通常情况下，实验平台在“实验发布”之后还可以预留一些流量来衡量实验的长期效果。另外一个可以降低错误的步骤则是重复“发布”某个实验，看实验的结果是否能够保持。&lt;/p&gt;

&lt;h3 id=&quot;实验指标的构建和选取&quot;&gt;实验指标的构建和选取&lt;/h3&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/metrics.png&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;架设好实验平台并且能够平稳运行实验之后，我们需要选择什么指标来进行检测，从而来帮助我们进行数据驱动决策。&lt;/p&gt;

&lt;p&gt;选取实验指标的第一要素，就是选择“综合评测指标”OEC。书中在第1章、第2章和第7章都对OEC有详细的讲述。简单说来，我们希望能够用OEC，这一个唯一的衡量指标，来指导我们如何对实验结果进行取舍。在现实场景中，我们往往希望检测多种指标。这对于我们了解实验对于系统所带来的改变固然有好处，使得我们可以关注不同方面的变化，然而实验的最终的目的是进行决策，面对多个指标的决策往往是困难的。因此，作者们认为，与其对于每一个实验对要面对不同指标的决策，还不如直接把所有的权衡都包含在唯一的指标OEC里面，这样可以把决策的困难前移到定义阶段，而在后面的实验阶段可以根据OEC来进行快速的判断。第7章专门了讨论了如何构建OEC的一些细节经验。&lt;/p&gt;

&lt;p&gt;书中第6章则对指标进行了一些更加深入的讨论。虽然针对一款产品或者一个团队来说，可能会有很多指标的选择，然而不同的指标有着不同的作用。第一类指标是“目标指标”（Goal Metrics）。这一类指标是产品和团队发展的最终发展方向。通常来说，“目标指标”是一个或者非常少数的指标。这一类指标的设立往往需要产品或者团队的领导层来进行决策。有了“目标指标”之后，在现实的操作中，这些指标往往难以在短期内被改变。这里的短期通常指的是在线实验的几周时间。也就是说，虽然我们希望能够直接优化“目标指标”，但经常并不具备可操作性。因此，我们需要更有可操作性的第二类指标“驱动指标”（Driver Metrics）。这一类的指标和“目标指标”应该是有相关性（Correlation）甚至是有因果相关（Causality）的，但同时又要比“目标指标”更容易检测变化以及进行操作。第三类指标是“护栏指标”（Guardrail Metrics）。这类指标的作用是确保产品或者团队的一些最基本的运行平稳。一般来说，“护栏指标”有一个范围来保护产品的运行底线，这样即便“目标指标”或者“驱动指标”有所增长也需要不大幅度影响“护栏指标”。&lt;/p&gt;

&lt;p&gt;书中在第6章和第7章中有不少对于在线产品指标选择的意见和建议，还包括了针对“指标”的博弈的讨论。&lt;/p&gt;

&lt;h3 id=&quot;实验数据分析&quot;&gt;实验数据分析&lt;/h3&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/dataanalysis.png&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;有了实验平台和我们需要检测的指标之后，实验结果的分析就成为了一件重要而且有挑战的工作。产生一组数据往往比较容易，但能够从数据中分析得出对实验的“洞察”（Insight），则并不简单。&lt;/p&gt;

&lt;p&gt;A/B在线实验数据分析的基础来自于统计的假设检验。基于&lt;a href=&quot;https://en.wikipedia.org/wiki/Student%27s_t-test&quot;&gt;“双样本”（Two-Sample）的t检测（t-Test）&lt;/a&gt;是来进行假设检验的重要工具。同时，我们也需要理解&lt;a href=&quot;https://en.wikipedia.org/wiki/P-value&quot;&gt;p值（p-value)&lt;/a&gt;以及置信区间的含义。这些概念在现实应用中常常被误解。在书中第17章有比较详细的简介。然而对于实验数据分析，仅仅知道t检测和p值是远远不够的。书中介绍了不少相对不经常被讨论到，但又很普遍的一些问题。&lt;/p&gt;

&lt;p&gt;第一个重要主题就是&lt;a href=&quot;https://en.wikipedia.org/wiki/Multiple_comparisons_problem&quot;&gt;“多次测试”（Multiple Testing）&lt;/a&gt;。简单来说，传统的假设检验的设置是对需要检测的“假设”（Hypothesis）进行唯一的测试，然后计算p值。在这样的情况下，我们有5%的概率观测到某一个并没有实际变化的“指标”显得有统计意义上的显著变化。然而在现实中，对于同一个实验，我们常常通过实验平台反复观测结果，或者反复针对同一个想法进行迭代。更加严重的是，我们针对同一个实验， 常常同时观测几十个有时候上百个“指标”。这些行为都会导致“多次测试”的问题，也就是大大增加观测到并不该显得有变化的“指标”有统计意义变化的概率。书中第17章讲了一些处理“多次测试”问题的实用判断方法。在现实运作中，“多次测试”问题会在长期运行平台和有实验数据分析后让很多结果有“水分”。&lt;/p&gt;

&lt;p&gt;第二个问题就是针对“方差”的计算。t检测中我们需要对数据的方法进行计算。书中的第18章指出，有时候我们的“方差”计算是有问题的，例如前文提到的“随机单元”和“分析单元”不一致的情况下，尤其是我们需要计算一些比率如点击率。一个经常遇到的场景就是，我们的“随机单元”是“用户级别”，然而我们希望计算一些页面级别的点击率，看是否在“控制组”和“对照组”之间有差别。这时候，就存在“随机单元”和“分析单元”不一致的问题，传统的计算点击率的“方差”公式有可能是错误的。那么，第18章针对这样的问题进行了分析。&lt;/p&gt;

&lt;p&gt;书中还提到的一个重要的数据分析手段是看“样本比率偏差”（Sample Ratio Mismatch）。在理想状态下，“控制组”和“对照组”的流量是五五开的，也就是50%的用户会到“控制组”另外50%的用户会到“对照组”。那么，如果在现实中，是50.43%的用户到了“控制组”另外49.57%的用户到了“对照组”，这样的情况还是正常的吗？我们还能信任这样的实验结果吗？书中第21章讲解了如何针对这样的情况进行排查和分析。简单来讲，我们需要把这样的分流结果当做是假设检验，看这样的结果是否异常。&lt;/p&gt;

&lt;p&gt;类似的看似简单实际需要认真对待的还有针对A/A实验的结果。在第19章里专门讲了A/A实验的一些经验和数据处理。A/A实验往往作为检测平台稳定性和实验设置是否正确的重要手段。&lt;/p&gt;

&lt;p&gt;除了这些非常实用的场景外，书中还在第22章介绍了更加高阶的话题，那就是如果“控制组”和“对照组”之间有“干涉”（Interference）怎么办。也就是说，传统的实验我们的一个重要的假设就是“控制组”和“对照组”的完全隔绝。然而在现实中的一些设置中，完全的隔绝是不可能的。例如，在社交网络中，因为朋友与朋友的关系，于是如果我们按照传统的随机划分流量的方法，则有可能一个用户在“控制组”，而其朋友在“对照组”，这样就使得这个用户可以接触到“对照组”的一些信息，从而违反了假设检验的一系列基本假设。在这一章，作者们给出了一些参考的解决方案。&lt;/p&gt;

&lt;p&gt;除了针对衡量“指标”在实验内的数据分析之外，作者们还在第23章讨论了一个非常重要的话题，那就是如何衡量“指标”的长期效果。一个经常发现的现象就是，有一些“指标”的效果在A/B实验之后，可能会出现一些“恶化”，也就是说，效果可能没有之前那么明显了，甚至会出现效果完全消失。作者们在这一章详细分析了“指标”长期效果出现变化的一些可能性，以及如何去做一些针对性的分析来看“指标”是否有长期效果不佳的问题。这一部分算是高阶内容，建议感兴趣的读者阅读。&lt;/p&gt;

&lt;h3 id=&quot;观察研究和因果推论&quot;&gt;观察研究和因果推论&lt;/h3&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/abtests.png&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;在有不少的情况下，我们无法对需要研究的问题进行实验。这一方面有可能是实验是现实中不可操作的，另一方面也可能是做实验会有伦理、道德等挑战，因此“观察研究”和“因果推论”（Causal Inference）就成为了在这种情况下我们依然希望进行数据驱动决策的唯一选择。本书的作者们在第11章简要介绍了“观察研究”的一些基本技术。不过，对于“观察研究”的可靠度，作者们持有谨慎的态度。原因是一般的基于“观察研究”的“因果推论”方法因为有很强的假设有不小的局限性。作者们甚至指出了一些研究的结果因为后期发现的一些问题而导致结论发生很大的变化而不可信。尽管如此，我们还是建议读者们对第11章的内容进行普遍的了解。&lt;/p&gt;

&lt;h2 id=&quot;总结点评&quot;&gt;总结点评&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;这本书可以说是作为数据科学家、机器学习工程师、产品经理以及一切对于在线可控实验有兴趣的研发人员“宝典”级别的参考书。全书包含了丰富的理论基础、实践指导以及案例分析，是一本难能可贵的集科普与进阶为一体的技术书籍。三位作者，特别是第一作者Ron在微软多年从事在线可控实验研发和领导工作的经历，使得这本书从某种意义上成为了他对这些年工作的一种总结之作。本书高阶部分的内容可以直接连接到当前研究和实践的热点内容，可以使程度较高的读者也能有比较享受的阅读体验。总体而言，本书可以作为可以反复阅读的业界经典之作。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>《经理人之路——技术领袖启航成长与变化的参考书》总结</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0,%E7%AE%A1%E7%90%86/2019/12/25/the-manager-path/"/>
   <updated>2019-12-25T00:00:00-08:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0,%E7%AE%A1%E7%90%86/2019/12/25/the-manager-path</id>
   <content type="html">&lt;p&gt;今天我们要来总结技术管理书籍&lt;a href=&quot;https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897&quot;&gt;The Manager’s Path – A Guide for Tech Leaders Navigating Growth &amp;amp; Change&lt;/a&gt;。这本书的作者是&lt;a href=&quot;https://en.wikipedia.org/wiki/Camille_Fournier&quot;&gt;卡米尔福尔聂尔（Camille Fournier）&lt;/a&gt;，其在技术管理领域有丰富的经验。全书是针对技术管理人在职场发展不同阶段所需技能以及面对诸多管理场景的经验总结，是技术管理领域不可多得的参考书籍。&lt;/p&gt;

&lt;h2 id=&quot;作者简介&quot;&gt;作者简介&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/cf.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://en.wikipedia.org/wiki/Camille_Fournier&quot;&gt;卡米尔福尔聂尔（Camille Fournier）&lt;/a&gt;从2017年起在对冲基金&lt;a href=&quot;https://en.wikipedia.org/wiki/Two_Sigma&quot;&gt;Two Sigma&lt;/a&gt;担任“董事总经理”（Managing Director）。之前在&lt;a href=&quot;https://en.wikipedia.org/wiki/Rent_the_Runway&quot;&gt;Rent The Runway&lt;/a&gt;历任总监、高级副总裁以及首席科技官等职务。其早年从卡内基梅隆大学毕业或计算机科学学士，毕业后在微软以及高盛任职。&lt;/p&gt;

&lt;h2 id=&quot;全书结构&quot;&gt;全书结构&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;全书大体上可以分为以下这么四部分内容:&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;第一部分，是对从“个人岗位”（Individual Contributor）向“管理岗位”（Managerial Contributor）转换过程的经验总结，面向的对象主要是有一定经验的技术人员，内容涵盖了“导师”（Mentor）和“技术负责人”（Tech Lead）。这部分内容是“技术管理”（Technical Management）的重要准备。在书中大体对应第二章、第三章和一部分第四章的内容。&lt;/li&gt;
  &lt;li&gt;第二部分，是对“初级经理人”（Entry-Level Manager）的经验总结，面向的对象主要是“经理”（Manager）这一级别的职务。这一部分是“技术管理”的奠基石。在书中大体对应一部分第四章的内容和第五章的内容。&lt;/li&gt;
  &lt;li&gt;第三部分，是对“中层经理人”（Manager of Managers）的经验总结。面向的对象主要是“资深经理”和“总监”这一级别的职务。这一部分是技术管理的重要进阶。在书中大体对应第六章和第七章的内容。&lt;/li&gt;
  &lt;li&gt;第四部分，是对“高级经理人”（Senior Leaders）的经验总结，面向的对象主要是“首席科技官”（CTO）和“高级副总裁”（SVP）这一级别的职务。这一部分是技术管理的高级阶段。在书中大体对应第八章的内容。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;除了这四部分的主要内容以外，这本书的第一章主要是从“被管理”的角度讲如何和自己的经理打交道，可以说是非常有用的经验总结。而第九章，也就是最后一章，则讲了讲对于塑造团队和企业技术文化的一些经验之谈。&lt;/p&gt;

&lt;h2 id=&quot;内容剖析&quot;&gt;内容剖析&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;我们接下来就针对书中的四个重点内容为大家进行剖析。&lt;/p&gt;

&lt;h3 id=&quot;技术管理的准备&quot;&gt;技术管理的准备&lt;/h3&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/mentor.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;要想胜任技术管理的岗位往往不是一蹴而就。从个人岗位到管理岗位有时候有着不可逾越的鸿沟。现实中的技术人员，特别是资深技术人员，通常情况下都在自身技术水平不断得到提升的基础上，希望能够对自己的管理能力也进行扩展，从而来试探自己是否有朝一日能够走上管理岗位。于是，在非管理岗位进行技术管理的技能培养和训练就显得尤其重要。&lt;/p&gt;

&lt;p&gt;本书对于技术管理的准备阶段着重从“导师”和“技术负责人”这两个重要“角色”（Role）入手，来引导资深技术人员来理解“人员管理”（People Management）的入门技能。&lt;/p&gt;

&lt;p&gt;另一方面，从中层经理人的角度来说，“导师”和“技术负责人”这两个角色也是考察资深技术人员是否具备转换为潜在“初级经理人”（所谓的内部提拔）的重要过度性角色。也就是说，把有一定资质的技术人员放在这样的角色上是相对风险较低得考察一个技术人员是否能够适应管理工作的重要方法。&lt;/p&gt;

&lt;p&gt;“导师”这个角色往往比较简单。书中涵盖了两种“导师”关系：实习生导师和新员工导师。在这些初级的技术管理角色中，技术人员需要开始学习和掌握三种重要的管理技能（Skill）：&lt;/p&gt;
&lt;ul&gt;
  &lt;li&gt;&lt;strong&gt;聆听&lt;/strong&gt;（Listen）：“聆听”可以说是从简单技术岗位到管理岗位转换中非常难以驾驭的一个技能。同时，聆听是建立“共情”（Empathy），也就是另一个重要的管理技能，的重要步骤，或者说是第一步。培养“聆听”技能的核心在于“专注”。也就是说，“聆听”需要你专注于你所聆听对象目前在表达的事情。“聆听”的目的是了解对方所希望表达的内容和观点，而不是迅速切换到你自己的回应。另外，“聆听”的难点在于很多人并不善于表达自己的观点。于是，在“聆听”的过程中去真正理解对方的意图就变得尤为重要。这种时候，通过反复问问题的方式来调整对于意图和内容的理解是一种有效的手段。&lt;/li&gt;
  &lt;li&gt;&lt;strong&gt;沟通&lt;/strong&gt;（Communication）：“沟通”是指对于沟通对象明确表达或者明确传达某种信息。沟通最忌讳预设立场。也就是说，不要预期沟通对象在没有沟通的情况下依然知道或者能够猜测到你所希望表达的信息。“沟通”的目的是明确表达出你对于对方的期待。&lt;/li&gt;
  &lt;li&gt;&lt;strong&gt;调整&lt;/strong&gt;（Calibration）：“调整”是指通过“聆听”和“沟通”来针对目前的状况调整计划。有很多情况是你实现意料不到的：你的指导对象也许比你想象得要慢；或许项目的进行不如你的预期；或许你的指导对象完全依靠自己完成了任务，等等。在这些意料之外的情况发生的时候，都需要你针对这些情况进行调整，并且能够和你的指导对象进行沟通。这种调整往往有一定周期性，比如每天或者每周。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;相较于“导师”，“技术负责人”则更像一个完整的“初级经理人”。在很多公司，“技术负责人”往往承担起很多经理的职责。值得注意的是，很多“技术负责人”也为团队中的年轻技术人员提供指导工作，起到“导师”的作用。&lt;/p&gt;

&lt;p&gt;然而，“技术负责人”往往需要具备一些相较于“导师”而言更加高阶的技能：&lt;/p&gt;
&lt;ul&gt;
  &lt;li&gt;&lt;strong&gt;平衡&lt;/strong&gt;（Balance）：“技术负责人”要开始学会在诸多完全不同的任务之间平衡自己的精力和时间。在最开始的一些时间里，人们往往倾向于做自己熟悉的任务（例如编写代码）。然而要想能够在技术管理的路上前行，“技术负责人”要开始学习新的技能并且在自己并不是那么熟悉的领域（例如组织会议、指导更多的年轻技术人员）多花时间。于是，“平衡”就成为了一种重要的技能。另外一个通常需要平衡的关系就是自己写代码解决复杂问题和如何调动团队来合作解决问题。&lt;/li&gt;
  &lt;li&gt;&lt;strong&gt;项目管理&lt;/strong&gt;（Project Management）：理解和掌握项目管理的精髓并不需要你成为“项目经理”（Project Manager）。这里所说的项目管理指的是如何把一个复杂的技术问题转换成为细致的多种任务同时能够对这些任务进行简单的分配和管理。更加高阶一些的项目管理技能需要“技术负责人”能够收集项目需求（Requirements）同时能够对项目的长度进行有效的估计。一个好的“技术负责人”更是能够发现目前项目进度的主要挑战（Challenge），并且能够带领团队进行技术攻坚。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;不管是“导师”还是“技术负责人”，作为一个资深技术人员，这两种角色都是让你能够开始学习和锻炼管理技能的重要过度角色。你可以审视自己是否喜欢这样的角色，是否真正愿意在技术管理的道路上继续前行。&lt;/p&gt;

&lt;h3 id=&quot;初级经理人&quot;&gt;初级经理人&lt;/h3&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/junior.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;在绝大多数科技公司，“初级经理人”一般指的是管理单一团队的技术经理人。单一团队的人数通常在三到十人不等。&lt;/p&gt;

&lt;p&gt;从“初级经理人”开始，技术管理的一些重要技能开始把个人岗位和管理岗位完全地区分开：&lt;/p&gt;
&lt;ul&gt;
  &lt;li&gt;开始一段新的汇报关系：在之后的技术管理工作中，经常会产生新的汇报关系。如何对待这些新出现的汇报关系则成为了技术管理中的重要技能。书中提到了一系列重要手段。例如和新的汇报对象逐渐建立&lt;strong&gt;互信&lt;/strong&gt;。说到底好的管理还是建立在人与人的关系上的，而在西方管理学中一个核心的内容就是人与人的互信。再例如就是建立一个30天60天90天的计划从而为新的汇报关系之间提供一个清晰的预期。同时，在确立新的汇报关系的过程中，“聆听”和“沟通”技能也起着至关重要的作用。这些技能是为了和新的汇报关系慢慢建立一个反馈机制。&lt;/li&gt;
  &lt;li&gt;一对一会议（1-1）：在这本书中，“一对一会议”的重要性被作者反复强调。“一对一会议”的安排（例如每周）和内容以及如何在这些会议中和汇报对象建立起稳健的反馈机制都是初级经理人需要掌握的重要人事管理的技能。书中还列举了不同类型的“一对一会议”诸如解决问题型、反馈型或者最新进展型。显然，要想在不同的情况下和汇报对象建立长久的关系，在不同类型的“一对一会议”之间熟练切换就成为了重要的手段。&lt;/li&gt;
  &lt;li&gt;绩效反馈评定：对汇报关系进行绩效反馈以及评定是技术管理的核心组成部分。这项技能是之前提及的“初级经理人”有别于之前提及的“技术负责人”的重要标杆。书中提及了一系列实际的技巧，例如“使用实际的事例”、“还需要加强的领域需要专注”等。
“初级经理人”一个非常重要的职责就是关注和协助团队成员的职业发展。很明显，不同公司不同行业的职级（Level）有区别。作为一线的“初级经理人”，你需要对团队中不同成员的晋升负责并且和他们一起提供一个完整的路线图。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;另外一个“初级经理人”需要开始学习的职责，就是管理员工的“离职”。“离职”分“主动离职”和“被动离职”（也就是俗称的“解雇”）。对于很多“初级经理人”而言，管理汇报对象的“离职”往往比想象中的要困难。这里关键的步骤是有效得建立起绩效的反馈机制以及比较详细的记录，从而为“离职”进行材料准备。&lt;/p&gt;

&lt;p&gt;“初级经理人”的相对比较高阶的话题还包括：&lt;/p&gt;
&lt;ul&gt;
  &lt;li&gt;观察和调试（Debug）团队：因为“技术经理人”不再是技术人员，需要利用新的技能和流程来对团队的整体绩效进行有效的评估。这里面包括的场景有团队的产出下降、团队有“人事混乱”（People Drama）、团队有合作问题等等。这里面的每一个场景都需要你建立一整套的机制来获取、筛选和处理信息，从而能够达到调试团队的目的。&lt;/li&gt;
  &lt;li&gt;矛盾和分歧的处理：很快，“初级经理人”就会发现其周围充满了矛盾和分歧。这些矛盾和分歧有来自于团队内部的，有来自其他合作团队的，有来自于上层的，等等。如何在复杂的环境下处理这些矛盾和分歧就成为了“初级经理人”所要学习的技能。这些技能会在“高级经理人”的阶段变得更加关键。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;成为一个有效的“初级经理人”还需要对项目管理有更加高阶的提升，包括你要开始针对团队的短期和长期的任务有一个比较完整的理解以及理解公司的运作周期（每个季度的时间安排），从而使得你对项目的分配以及团队的产出和合作都有一个全新的更高层次的认知。&lt;/p&gt;

&lt;h3 id=&quot;中层经理人&quot;&gt;中层经理人&lt;/h3&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/middle.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;在绝大多数科技公司，“中层经理人”一般指的是管理多个团队的技术经理人。这个时候，“中层经理人”所管理的多个子团队本身往往有一线的“初级经理人”。而“中层经理人”的职责则转移到如何管理好这些初级经理人以及通过这些“初级经理人”来对所有的多个团队进行间接的管理。管理多个团队是技术管理人从初级阶段向更加复杂的管理场景提升的重要标志。&lt;/p&gt;

&lt;p&gt;书中认为“中层经理人”一项非常的技能是如何更加合理得管理自己的时间。的确，对于一个“中层经理人”来说，在某一个瞬间，都有太多的事情可以聚焦，那么如何专注在最需要的事情上就变得尤为重要。书中介绍了一种经典的时间管理方法，那就是把事情按照重要与否和紧急与否两个维度分为如下的四种类别：&lt;/p&gt;
&lt;ol&gt;
  &lt;li&gt;重要而且紧急：一件事情如果是重要且紧急，那么这明显是当前需要专注的工作。尽管这样的分类方法有一定道理，作者提醒我们要注意在日常工作中把“显然”（Obvious）的工作当做是“紧急”（Urgent）的。例如，一个在日历上的会议邀请并不意味着这个会议就一定是紧急的事件。有时候，分清楚什么事情是否重要或者紧急并不是那么显然的事情。&lt;/li&gt;
  &lt;li&gt;重要但不紧急：很多事情都可以归为这个类别。例如，写一份新的“职位描述”（Job Description），抑或是思考一个新的招聘计划。这类事情的一个特点就是如果一点不花时间去做，那么长期积累下来就会对你的工作产生负面影响。一个“中层经理人”需要利用“平衡”等技能来找到时间花在重要但不紧急的事情上。&lt;/li&gt;
  &lt;li&gt;不重要且不紧急：这是很明显需要避免的一个类别。&lt;/li&gt;
  &lt;li&gt;不重要但紧急：作者认为这个类别的事情都是潜在的“分心”（Distraction）。例如，很多会议都显得很紧急，但作为一个“中层经理人”是否需要参与这些会议是需要仔细拿捏的意见事情。还有类似电子邮件或者聊天工具（Slack）上面的信息，会显得很紧急。但这些事情并不一定需要你现在就去处理。&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;在管理时间的基础上，作者提到了第二个“中层经理人”的重要技能“决策”（Decision）和“代理”（Delegation）。这个技能是中级经理人需要获取和发展的。类似于时间管理，作者按照经常与否和复杂与否两个维度，把事情的决策和代理分为了以下四个类别：&lt;/p&gt;
&lt;ol&gt;
  &lt;li&gt;简单且不经常：这类事情的典型代表如运行一些每个季度需要的报表，或订会议的票等，一般需要你自己去做。主要的原因是这类事情不具备利用来培养团队“初级经理人”的目的。&lt;/li&gt;
  &lt;li&gt;简单且经常：这类事情的典型代表如团队每日的例会、团队的进度报告等，一般需要你代理别人去做。一般来说，团队中的技术负责人或者一些资深技术人员都可以胜任这样的任务。&lt;/li&gt;
  &lt;li&gt;复杂且经常：这类事情的典型代表如项目计划、系统设计或者是在“事故”（Outage）的处理中担任核心的任务，一般需要你小心得去代理给团队。这些任务可以认为是发展团队中核心成员的重要手段和工具。然而因为这些事情相对都比较复杂，因此在代理的过程中需要注意方式方法和速度。简单来说，就是不能贸然把这类事物都不假思索得代理给团队。&lt;/li&gt;
  &lt;li&gt;复杂且不经常：这类事情的典型代表是写绩效评定、或者是建立一个新的招聘计划，一般来说需要你自己去做，但是也可以慢慢来代理给团队中未来的领袖。&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;学会如何平衡所有事物的决策和代理权是一个动态并且需要慢慢体会的技能。&lt;/p&gt;

&lt;p&gt;对于“中层经理人”来说，第三个重要的技能就是需要策略性地说“不”。对于多团队管理来说，有太多的场景需要你来斟酌并且表达否定的决策。然而，这里面的问题是，很多时候，简单说“不”并不能解决问题，尤其是有矛盾和分歧的时候。书中介绍了一系列的“说不”的技巧。总结说来，这些技巧都是要在“说不”的情况下提供更多的“上下文”（Context）以及尝试创造一个“说不”以后的计划，而不是简单的“说不”。&lt;/p&gt;

&lt;p&gt;我们在前面总结“初级经理人”的时候提及了“一对一会议”的重要性。当一个“中层经理人”开始管理多个团队时，与所有团队所有人进行“一对一会议”已经不现实，然而，书中还是强调了在这种新形势下的“一对一会议”，也就是“隔层会议”（Skip-Level Meetings）的必要性。总的来说，“隔层会议”是让你保持和一线员工有稳固联系的重要手段。通过这些“隔层会议”，你可以发现团队运行存在问题的蛛丝马迹。&lt;/p&gt;

&lt;p&gt;最后，“中层经理人”还需要有效管理起各个团队的“初级经理人”。这些“初级经理人”有可能是完全的新手，也有可能是富有经验的技术管理者。对于这些人的管理最重要的有两点，那就是如何建立有效的调试机制来得知他们管理的团队是否是高效运行还是存在不少潜在的问题，另外设置有效的预期以及提供反馈都是非常重要的中层管理手段。&lt;/p&gt;

&lt;p&gt;值得一提的是，“中层经理人”由于隔了一层“初级经理人”，因此对于团队的管控往往都是通过间接的手段，因此书中介绍的种种经验和技能都依赖于能够对初级经理人能够进行有效管理，因此“中层经理人”需要同时具备管理多个团队以及管理多个个人（也就是多个“初级经理人”）的技能和手段。这对经理人的要求明显高于初级经理人。&lt;/p&gt;

&lt;h2 id=&quot;高级经理人&quot;&gt;高级经理人&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/senior.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;书中的“高级经理人”指的是“工程副总裁”（VP of Engineering）或者“首席技术官”（CTO）这样的职位。很显然，“高级经理人”需要相比于“中级经理人”和“初级经理人”而言完全不同的一整套技能。&lt;/p&gt;

&lt;p&gt;书中提及的第一个重要技能就是如何对待“变化的优先级”（Changing Priorities）。这里提及的场景主要是指公司高层，例如CEO突然觉得公司应该专注于新的事情或者目前事情的优先级发生了变化。这些变化有可能并不是深思熟虑的结果。那么，如何带领一个复杂的机构（这时候已经不是单单几个团队了）来应对优先级的变化就是高级经理人往往需要掌握的技能。优先级的改变有可能对团队产生极大负面的效果。每个团队都潜在有一个常常的任务列表。很多项目之间还有依赖关系。因此，转变一个机构的优先级，并且能够有一个匹配的计划就变得尤为关键。另外，“沟通”在这种场景下也是不可缺少的重要技能。&lt;/p&gt;

&lt;p&gt;作为“高级经理人”的第二个重要技能就是如何设置“战略”（Strategy）。向董事会成员、或者是管理高层讲述、汇报部门甚至是公司在某一个方面的战略思想将成为“高级经理人”的一项核心工作。那么，如果能够建立战略的思路以及如何表述这样的战略就成为了高级经理人阶段的新技能。再之前的中层以及初级经理人阶段，主要是强调在执行的层面。&lt;/p&gt;

&lt;p&gt;最后，作为“高级经理人”，一个非常重要也是一个新的技能领域，那就是如何与诸多“跨部门”（Cross-Functional）“高级经理人”协作。尽管在科技公司中，有不少项目是跨部门协作的，例如需要设计、前台、后台、算法的齐心协力，然而在“高级经理人”阶段，你往往代表了一整个职能部门（例如工程副总裁或者是首席科技官代表了整个工程研发团队）与其他职能部门，例如产品、法务、人事，在整个公司的层面上进行合作。这势必是对你沟通表达能力以及协作能力的全新考验。&lt;/p&gt;

&lt;h2 id=&quot;总结点评&quot;&gt;总结点评&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;这本书可以说是作为技术管理人的“宝典”级别的职场参考书。因为作者卡米尔相对丰富的职业经理人晋升经历，因此这本书中提供的很多经验之谈都相当接地气并且有极高的参考价值。与更加通用的管理书籍相比，此书专注于科技公司的技术管理场景，因而对于有心于技术管理职场发展的各层级技术人员和技术管理人来说，这本书都能够提供不小的帮助。整本书的结构上来看，主要是相对比较松散组织起的四大块内容，以及穿插的各种技巧，因此可能在宏观上缺乏一定的架构，所以，本书可以作为可以反复阅读的经验总结之作。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>KDD 2019讲座 - “双次序实验”</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2019/09/02/kdd-sequencial/"/>
   <updated>2019-09-02T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2019/09/02/kdd-sequencial</id>
   <content type="html">&lt;p&gt;今天我们要来分享一个叫&lt;a href=&quot;http://www.stat.cmu.edu/~aramdas/kdd19/&quot;&gt;Foundations of Large-scale “Doubly-Sequential” Experimentation&lt;/a&gt;的KDD 2019讲座（Tutorial)。这个讲座的作者是来自于时任卡内基梅隆大学（Carnegie Mellon University）助理教授的&lt;a href=&quot;http://www.stat.cmu.edu/~aramdas/&quot;&gt;Aaditya Ramdas&lt;/a&gt;。这个讲座清晰得梳理了基于单个实验的“内次序”（Inner Sequential Process）和基于多个实验的“外次序”（Outer Sequential Process），以及他们之间的关系。同时，这个讲座还涵盖了这方面的重要文献历史，是一份不可多的资料。&lt;/p&gt;

&lt;h2 id=&quot;讲座的基本设置&quot;&gt;讲座的基本设置&lt;/h2&gt;

&lt;p&gt;讲座的第一部分是对简单的A/B实验进行了回顾。诚如讲座里面讲的，这部分内容已经在最近几年的各大会议的很多其他类似讲座中已经有所涵盖。因此该讲座并没有再对基础知识进行重复。&lt;/p&gt;

&lt;p&gt;讲座的内容很快转移到核心的两块内容，那就是基于单个实验的“内次序”（Inner Sequential Process）以及基于多个实验的“外次序”（Outer Sequential Process）。简单得来说，不管是“内次序”还是“外次序”，该讲座的目的就是来探讨如何让实验的结论能够成立。也就是说，如果进行简单的“假设检验”（Hypothesis Testing），例如我们经常做的T-Test，或者其他基于“置信区间”（Confidence Interval）的检验有可能得到错误的结论。讲座的核心内容就是来对已有的方法已经扩展。&lt;/p&gt;

&lt;h2 id=&quot;内次序&quot;&gt;内次序&lt;/h2&gt;

&lt;p&gt;“内次序”主要是探究在一个实验里的结论是否正确的问题。当然，这里的“正确”并不是指绝对意义上的“控制组”（Control Group）要比“对照组”（Treatment Group）好，或者反之。而是从统计意义来说，如何来衡量控制组和对照组之间的差别。上面我们提到，这种统计推断的核心是进行“假设检验”。&lt;/p&gt;

&lt;p&gt;Aaditya首先指出，传统的假设检验的一个重大问题就是样本数量必须事先确定好。不管是p-value还是置信区间都依赖于这个&lt;strong&gt;事先确定好的&lt;/strong&gt;样本数量。这种静态的需求和很多平时在A/B实验中进行观测的行为是非常不同的。例如，一种非常普遍（并不是是正确）的观测实验的方式是，对一个实验的结果反复进行检查，看p-value是不是到达并且小于某个阈值$ \alpha $，一旦小于这个值，立马停止实验。利用这样的方法会得到“False Positive Rate”很可能远远大于事先的阈值$ \alpha $。换句话说，很多我们认为有作用的“对照组”其实很有可能并没有作用。&lt;/p&gt;

&lt;p&gt;那么，内次序的核心问题就是如何对这样的监控算法进行扩展和改进，使得我们能够随时监控实验并且还能够得到正确的统计推断结果。&lt;/p&gt;

&lt;p&gt;在该讲座中，Aaditya讲解了“Confidence Sequence”和“Sequential p-value”的概念，并且展示了如何利用这两种手段来进行单个实验的检测。同时，Aaditya还揭示了这两种概念之间的转化关系。&lt;/p&gt;

&lt;h2 id=&quot;外次序&quot;&gt;外次序&lt;/h2&gt;

&lt;p&gt;那么，如果我们能够很好得处理一个实验，是不是我们就可以放心大胆得进行多个实验来进行服务的改进了呢？答案是，对于多个实验，我们依然需要更加小心。&lt;/p&gt;

&lt;p&gt;这部分的内容可能一开始会让人觉得很震惊。但Aaditya在讲座中举了很直观的例子来说明，即便单个实验我们都依靠某个$ \alpha_{i} $来控制“False Positive Rate”，并不代表多个实验的总体的”False Discovery Proportion”(FDP)是小于或等于这些$ \alpha_{i} $。&lt;/p&gt;

&lt;p&gt;外次序的核心内容就是如何对多个实验进行监控，并且能够在“在线”（Online）的情况下进行统计推断。该讲座对几个最新的在线FDP算法进行讲解。细节可以参考讲座内容。&lt;/p&gt;

&lt;h2 id=&quot;双次序实验&quot;&gt;双次序实验&lt;/h2&gt;

&lt;p&gt;该讲座应该算是第一个把内次序和外次序都结合在一起的一个讲座。Aaditya在讲座内容中指出，这两个部分均可以进行“模块化”。意思是说，更好的内次序算法以及更好的外次序算法可以进行搭配使用。&lt;/p&gt;

&lt;h2 id=&quot;高级内容&quot;&gt;高级内容&lt;/h2&gt;

&lt;p&gt;Aaditya在该讲座也进行了部分高级内容的概括：&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;在“内次序”中如何处理多个“对照组”。讲座提到了基于Multi-Armed Bandit（MAB）的算法。&lt;/li&gt;
  &lt;li&gt;如何对Quantile进行估计。&lt;/li&gt;
  &lt;li&gt;在“外次序”中，如何对过去远期的实验进行“忘却”（Forget）。&lt;/li&gt;
&lt;/ol&gt;

&lt;h2 id=&quot;历史信息&quot;&gt;历史信息&lt;/h2&gt;

&lt;p&gt;Aaditya在讲座中回顾了内外次序的重要历史文献。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>CIKM 2018论文精读（一）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2018/12/01/cikm2018-pr/"/>
   <updated>2018-12-01T00:00:00-08:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2018/12/01/cikm2018-pr</id>
   <content type="html">&lt;p&gt;今天我们要来分享一篇题目叫&lt;a href=&quot;https://drive.google.com/open?id=1m7-z2loy5iW-gcrGiT2XJTdr4LjQHf3H&quot;&gt;Collaborative Multi-objective Ranking&lt;/a&gt;的发表在&lt;a href=&quot;https://www.cikm2018.units.it/&quot;&gt;CIKM 2018&lt;/a&gt;上的论文。这篇论文的作者是来自于罗格斯大学（Rutgers University）的&lt;a href=&quot;https://sites.google.com/site/hujun1010/&quot;&gt;Jun Hu&lt;/a&gt;和&lt;a href=&quot;http://www.stat.rutgers.edu/home/pingli/&quot;&gt;Ping Li&lt;/a&gt;。文章的核心内容讲的是，传统的以矩阵分解为基础的“协同排序”（Collaborative Ranking）容易有无法有效学习“用户隐向量”（User Factor）和“物品隐向量”（Item Factor）的问题。这篇论文探究了这种问题的来源以及提出了一种“共同优化”（Joint Optimization）的策略来解决问题。&lt;/p&gt;

&lt;h2 id=&quot;文章的基本设置&quot;&gt;文章的基本设置&lt;/h2&gt;

&lt;p&gt;我们先来看一下文章的基本设置。首先，我们假设有一个评分矩阵$ \mathbf{R} \in \mathbb{R}^{M \times N} $，被一个用户矩阵$ \mathbf{U} \in \mathbb{R}^{M \times K} $和一个物品矩阵$ \mathbf{V} \in \mathbb{R}^{N \times K} $所表达$ \mathbf{R} = \mathbf{U} \times \mathbf{V} $。一个“单点”（Pointwise）目标函数常用来学习模型的参数：&lt;/p&gt;

\[L_{\mathrm{pointwise}} = \sum_{u=1}^{M} \sum_{v=1}^{N} (r_{ui} - \hat{r_{ui}})^{2} + \sum_{u=1}^{M}\lambda_{U,u}|| \mathbf{U}_{u} ||^{2} + \sum_{v=1}^{N}\lambda_{V,v}|| \mathbf{V}_{v} ||^{2}\]

&lt;p&gt;这个目标函数的目的是希望能够学习到准确的用户隐向量和物品隐向量来逼近原有的评分矩阵。然而在真实的应用中，很多时候我们并不是在意\(\mathbf{U}\)和\(\mathbf{V}\)的绝对数值的准确性，而是它们之间的相对位置，也就是说“排序”。所以，这也就有了“协同排序”的出现。具体说来，“协同排序”就是希望利用“配对法”（Pairwise）的“排序学习”（Learning to Rank）确保物品的相对顺序得以保证。一个常见的针对顺序的损失目标函数是：&lt;/p&gt;

\[\varepsilon_{\mathrm{zero-one}} = - \sum_{(u, i_{1}, i_{2}) \in \Omega} \sigma \Bigr( \mathbf{U}_{u} \mathbf{V}_{v_{1}}^{T} - \mathbf{U}_{u} \mathbf{V}_{v_{2}}^{T}\Bigl)\]

&lt;p&gt;其中\(\Omega = \{ (u, i_{1}, i_{2}) : r_{ui_{1}} &amp;gt; r_{ui_{2}} \}\)是一个比较集合，\(\sigma(x)\)是一个$0-1$ 损失函数：当$x &amp;gt; 1$的时候\(\sigma(x) =1\)，其他时候为$0$。这个损失函数无法微分，因此一个替代的方案则是利用Sigmoid函数：&lt;/p&gt;

\[\varepsilon_{\mathrm{zero-one-approximate}} = - \sum_{(u, i_{1}, i_{2}) \in \Omega} \frac{1}{1+\exp\Bigr( -\mathbf{U}_{u} (\mathbf{V}_{v_{1}} - \mathbf{V}_{v_{2}})^{T}\Bigl)}\]

&lt;p&gt;我们有了上面的这个损失函数以后，在进行优化的过程中，往往会“保持住”（Fix）所有某个用户$u$所对应的\(\mathbf{V}\)，然后更新\(\mathbf{U}_{u}\)。&lt;/p&gt;

&lt;h2 id=&quot;文章的核心观点&quot;&gt;文章的核心观点&lt;/h2&gt;

&lt;p&gt;文章的作者们发现，在某些情况下在更新用户矩阵\(\mathbf{U}_{u}\)的时候，算法不可能保持住所有用户所对应物品的顺序的。举例来说，我们有两组物品的比较顺序\(\{ (u, a, b) : r_{ua} &amp;gt; r_{ub} \} \in \Omega\)和\(\{ (u, c, d) : r_{uc} &amp;gt; r_{ud} \} \in \Omega\)。并且当前情况下，我们有这样的关系：\(\mathbf{V}_{a} - \mathbf{V}_{b} =[0,-1]\)和\(\mathbf{V}_{c} - \mathbf{V}_{d} =[0,1]\)。这也就意味着无论如何更新\(\mathbf{U}_{u}\)，我们都无法同时满足\(\mathbf{U}_{u}(\mathbf{V}_{a} - \mathbf{V}_{b})&amp;gt;0\)和\(\mathbf{U}_{u}(\mathbf{V}_{c} - \mathbf{V}_{d})&amp;gt;0\)，因为这两组乘积必定是一正一负，无法调和。也就是说，在更新了\(\mathbf{U}_{u}\)之后，我们反而无法保证原有的顺序了。&lt;/p&gt;

&lt;p&gt;第二个作者们的发现来自于对于Sigmoid函数\(\sigma(x) = \frac{1}{1+ \exp(-ax)}\)的认识。在这个函数中，\(a\)控制了曲线多么接近\(0-1\)损失函数：值越大，越接近。然而，在矩阵分解中，任何对于\(\mathbf{U}_{u}\)的更新（例如把其值增大两倍），都可以利用更改其对应的所有\(\mathbf{V}_{i}\)来达到恢复其之前的状态（例如把其值除以一半）。这样，更新\(\mathbf{U}_{u}\)并不一定逼近\(0-1\)损失函数。换句话说，我们必须要对\(\mathbf{V}\)进行限制，不能无限制得任其发展。&lt;/p&gt;

&lt;h2 id=&quot;文章提出的模型&quot;&gt;文章提出的模型&lt;/h2&gt;

&lt;p&gt;有了上面的铺垫，作者们提出了一种新的损失函数，那就是把单点损失函数，基于物品的配对损失函数以及基于用户的配对损失函数结合起来，形成一个三个损失函数的某种平衡。&lt;/p&gt;

&lt;p&gt;我们已经定义了单点损失函数，那这里就来看看一下基于物品的配对损失函数。作者们使用了一个叫Bradley-Terry模型来针对某个用户的两个物品进行比较的概率进行建模：&lt;/p&gt;

\[P(r_{ui_{1}} &amp;gt; r_{ui_{2}}) = \frac{\exp(\mathbf{U}_{u}\mathbf{V}_{i_{1}}^{T})}{\exp(\mathbf{U}_{u}\mathbf{V}_{i_{1}}^{T}) + \exp(\mathbf{U}_{u}\mathbf{V}_{i_{2}}^{T})}\]

&lt;p&gt;在有了这个概率之后，我们最小化其“负对数似然”（Negative Log Likelihood）:&lt;/p&gt;

\[L_{\mathrm{row-wise}} = - \sum_{(u, i_{1}, i_{2}) \in \Omega} \log P(r_{ui_{1}} &amp;gt; r_{ui_{2}}) + \sum_{v} \lambda_{V,v}||\mathbf{V}_{v}||^{2}\]

&lt;p&gt;非常类似的，我们还可以定义基于用户的配对损失函数，得到：&lt;/p&gt;

\[L_{\mathrm{column-wise}} = - \sum_{(u_{1} u_{1}, i) \in \Psi} \log P(r_{u_{1}i} &amp;gt; r_{u_{2}i}) + \sum_{u} \lambda_{U,u}||\mathbf{U}_{u}||^{2}\]

&lt;p&gt;于是我们可以定义最终的统一的损失函数为：&lt;/p&gt;

\[L = \alpha L_{\mathrm{row-wise}} + \beta L_{\mathrm{column-wise}} + (1-\alpha -\beta) L_{\mathrm{pointwise}}\]

&lt;p&gt;其中，$\alpha \in [0, 1]$和$\beta \in [0, 1]$，并且\(\alpha + \beta &amp;lt;1\)。作者们认为，这个新的损失函数可以解决之前提出的问题。针对这个新的目标函数，文章提出了详细的优化算法，这里就不赘述了。作者们提出的模型在MovieLens、Netflix以及Amazon的数据集上都要优于不使用排序的纯矩阵分解模型以及一般的协同排序算法。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>AISTATS 2018论文导读</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2018/05/25/aistats2018/"/>
   <updated>2018-05-25T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2018/05/25/aistats2018</id>
   <content type="html">&lt;p&gt;2018年的第21届人工智能和统计学大会（The 21st International Conference on Artificial Intelligence and Statistics）在加那利群岛（Canary Islands）召开。我们在这篇短文里提供一些论文的快速导读，起到抛砖引玉的作用。&lt;/p&gt;

&lt;h2 id=&quot;论文导读&quot;&gt;论文导读&lt;/h2&gt;
&lt;hr /&gt;

&lt;h3 id=&quot;boosting-variational-inference-an-optimization-perspective&quot;&gt;Boosting Variational Inference: an Optimization Perspective&lt;/h3&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v84/locatello18a/locatello18a.pdf&quot;&gt;PDF&lt;/a&gt;
&lt;a href=&quot;http://proceedings.mlr.press/v84/locatello18a/locatello18a-supp.pdf&quot;&gt;Supplementary PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章主要是说最近提出的Boosting Variational Inference（BVI）是把Boosting的思想和Variational Inference相结合的一个新的研究方向，只不过这个方向目前并没有太多的理论支持。这篇论文通过和Frank-Wolfe算法建立联系从而对BVI的收敛性质进行了证明。本篇文章基本上是一个纯理论工作。&lt;/p&gt;

&lt;p&gt;之前的BVI的主要论文是：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;Fangjian Guo, Xiangyu Wang, Kai Fan, Tamara Broderick, David B. Dunson:
&lt;a href=&quot;https://arxiv.org/abs/1611.05559&quot;&gt;Boosting Variational Inference&lt;/a&gt;. CoRR abs/1611.05559 (2016)&lt;/li&gt;
  &lt;li&gt;Andrew C. Miller, Nicholas J. Foti, Ryan P. Adams:
&lt;a href=&quot;http://proceedings.mlr.press/v70/miller17a.html&quot;&gt;Variational Boosting: Iteratively Refining Posterior Approximations&lt;/a&gt;. ICML 2017: 2420-2429&lt;/li&gt;
&lt;/ul&gt;

&lt;h3 id=&quot;personalized-and-private-peer-to-peer-machine-learning&quot;&gt;Personalized and Private Peer-to-Peer Machine Learning&lt;/h3&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v84/bellet18a/bellet18a.pdf&quot;&gt;PDF&lt;/a&gt;
&lt;a href=&quot;http://proceedings.mlr.press/v84/bellet18a/bellet18a-supp.pdf&quot;&gt;Supplementary PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章主要是把“隐私”（Privacy）领域和优化领域相结合，寻找一种可以保护每一个“个体”（Agent）的隐私但同时能够进行协作从而让最终的优化算法能够达到最优的情况。这方面的研究其实有很多现实的应用。例如说在手机应用中，传统的模式是让所有的手机把数据都集中到服务器上，然后在服务器端再进行机器学习。这种模式很明显具有最高的数据效率但是有可能对用户的数据隐私有侵害。而另一个极端则是把在每个手机上直接进行学习。然而，因为数据有限，这样往往无法学习到有用的模型。这篇文章就是提出了一种如何在这两个极端之间寻求平衡的“异步”（Asynchronous）分布式算法。&lt;/p&gt;

&lt;h3 id=&quot;fast-threshold-tests-for-detecting-discrimination&quot;&gt;Fast Threshold Tests for Detecting Discrimination&lt;/h3&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v84/pierson18a/pierson18a.pdf&quot;&gt;PDF&lt;/a&gt;
&lt;a href=&quot;http://proceedings.mlr.press/v84/pierson18a/pierson18a-supp.pdf&quot;&gt;Supplementary PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章说的是“阈值测试”（Threshold Test）在过去被提出来用于检测在一些社会活动（比如租房、招聘、警察活动等）中可能存在的“歧视”或“偏差”（Bias)。这篇文章则是提出了快速计算方法使得这样的测试能够快速进行。文章在270万纽约市警察阻止路人的数据集上进行了评测。这篇文章主要是帮助大家扩宽眼界，对于社会性的偏差，目前在学术界已经出现了专门的方法论。&lt;/p&gt;

&lt;h3 id=&quot;batch-expansion-training-an-efficient-optimization-framework&quot;&gt;Batch-Expansion Training: An Efficient Optimization Framework&lt;/h3&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v84/derezinski18b/derezinski18b.pdf&quot;&gt;PDF&lt;/a&gt;
&lt;a href=&quot;http://proceedings.mlr.press/v84/derezinski18b/derezinski18b-supp.pdf&quot;&gt;Supplementary PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章讲的是这样一种优化的场景，那就是一个不断增大的数据集，如何在这样的情况下进行“批量”（Batch）学习。这种场景和传统的“随机”（Stochastic）学习不同，因为可以更加有效得利用资源，减少磁盘的读取。这篇文章提出的方法可以和任意的其他优化算法结合，比如L-BFGS。文章展示了提出的方法的很强的收敛性质和以及在并行化下的效果。&lt;/p&gt;

&lt;h3 id=&quot;topic-compositional-neural-language-model&quot;&gt;Topic Compositional Neural Language Model&lt;/h3&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v84/wang18a/wang18a.pdf&quot;&gt;PDF&lt;/a&gt;
&lt;a href=&quot;http://proceedings.mlr.press/v84/wang18a/wang18a-supp.pdf&quot;&gt;Supplementary PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;自从Neural Language Model（NLM）流行以来，期望能够把NLM和话题模型（Topic Model）进行结合的想法就屡见不鲜。这篇论文也是这个方向的一次尝试。NLM的主要优势是在句子以下的结构上对字句进行建模，而话题模型则往往能够在真个文档甚至更高的层次上对文本的语义进行建模。把这两者结合起来就是想利用这两方面的优势。在这篇文章里，话题模型通过Variational Autoencoder的框架来捕捉到文档的话题（Topic）隐变量。之后，这个变量成为了对不同的语言模型进行加权的权重，而语言文字的产生则利用了Mixture-of-Experts的框架来对不同的RNN语言模型进行整合。需要注意的是，在这篇文章提出的方法里，话题模型对文字的整体数据和语言模型对单独的字句都进行了建模，也就是说，一个文档分别有两个产生过程，一个针对全局文字，一个针对有顺序的字句。&lt;/p&gt;

&lt;h3 id=&quot;making-tree-ensembles-interpretable-a-bayesian-model-selection-approach&quot;&gt;Making Tree Ensembles Interpretable: A Bayesian Model Selection Approach&lt;/h3&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v84/hara18a/hara18a.pdf&quot;&gt;PDF&lt;/a&gt;
&lt;a href=&quot;http://proceedings.mlr.press/v84/hara18a/hara18a-supp.pdf&quot;&gt;Supplementary PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;最近几年，机器学习的可解释性是一个新的研究领域，不少工作都围绕在如何能够让已经学习的模型或者在学习过程中产生容易被解释的模型。这篇文章针对的是“树集成”（Tree Ensembles）模型，希望通过贝叶斯模型选择（Bayesian Model Selection）的方法来对树模型进行简化从而达到能够可解释的目的。这篇文章的一个可以借鉴也可以精读的地方在于如何把树模型变为概率模型。传统上树模型的整套建模语言都是非概率的，那么如果要使用贝叶斯统计的方法，就一定需要做概率的转换。&lt;/p&gt;

&lt;h3 id=&quot;can-clustering-scale-sublinearly-with-its-clusters-a-variational-em-acceleration-of-gmms-and-k-means&quot;&gt;Can Clustering Scale Sublinearly with Its Clusters? A Variational EM Acceleration of GMMs and K-means&lt;/h3&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v84/forster18a/forster18a.pdf&quot;&gt;PDF&lt;/a&gt;
&lt;a href=&quot;http://proceedings.mlr.press/v84/forster18a/forster18a-supp.pdf&quot;&gt;Supplementary PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;高斯混合模型（GMM）和K-means都是我们非常熟悉的聚类算法。然而传统上，这两个模型的解法都是和聚类数目C、数据点数N、以及数据的维度D呈线性关系。能不能在这个基础上再加速成为了很多实践者的疑问和困难。这篇文章是希望利用Variational EM来化简整个算法，使得其不依赖于C，而依赖于一个较小的参数G。这篇文章是典型的老树开新花的尝试。&lt;/p&gt;

&lt;h3 id=&quot;parallelised-bayesian-optimisation-via-thompson-sampling&quot;&gt;Parallelised Bayesian Optimisation via Thompson Sampling&lt;/h3&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v84/kandasamy18a/kandasamy18a.pdf&quot;&gt;PDF&lt;/a&gt;
&lt;a href=&quot;http://proceedings.mlr.press/v84/kandasamy18a/kandasamy18a-supp.pdf&quot;&gt;Supplementary PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;贝叶斯优化（Bayesian Optimisation），或者简称BO，常常用来针对复杂而且昂贵（Expensive）的函数评价，例如超参数（Hyper-parameter）的调节。针对有一些可以并行化的情况下，这篇论文提出了使用“汤姆森采样”（Thompson Sampling）的方法来应对并行的场景有惊人好的效果，并且这篇文章最终提出了“异步并行化的汤姆森采样”。作者们认为这篇文章的一大亮点是给出了理论的结论，这在过去尝试把BO并行化的工作中并不多见。&lt;/p&gt;

&lt;h3 id=&quot;on-the-challenges-of-learning-with-inference-networks-on-sparse-high-dimensional-data&quot;&gt;On the challenges of learning with inference networks on sparse, high-dimensional data&lt;/h3&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v84/krishnan18a/krishnan18a.pdf&quot;&gt;PDF&lt;/a&gt;
&lt;a href=&quot;http://proceedings.mlr.press/v84/krishnan18a/krishnan18a-supp.pdf&quot;&gt;Supplementary PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章其实是在针对Variational Autoencoder，或者简称VAE，在训练的时候的一个普遍问题，那就是作者们认为VAE在计算过程中并没有最优化Variational参数，而仅仅是找到了或者说是计算出了一组解。因此，作者们认为VAE存在Underfitting的情况，就是说模型的参数学习得不完全。而在传统的Stochastic Variational Learning的语境中，每一步都是根据当前的参数进行的最优化。于是，这篇文章就是把这种思路给应用到VAE上。&lt;/p&gt;

&lt;h3 id=&quot;scalable-generalized-dynamic-topic-models&quot;&gt;Scalable Generalized Dynamic Topic Models&lt;/h3&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v84/jahnichen18a/jahnichen18a.pdf&quot;&gt;PDF&lt;/a&gt;
&lt;a href=&quot;http://proceedings.mlr.press/v84/jahnichen18a/jahnichen18a-supp.pdf&quot;&gt;Supplementary PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;Dynamic Topic Model（DTM）相信作为对话题模型（Topic Model）研究者都会不陌生。这可以说是最有影响力的话题模型的扩展。DTM是把时间序列和话题模型结合在一起最直观的一种模型。这篇文章指出，其实DTM提出的模型仅仅是一种叫Weiner Processes（WP）的一个特殊情况。而把DTM给扩展到WP以后，作者们认为就可以使用各种不同的WP的Kernel来对时序建模，大大增强模型的效果。这篇文章还给出了大规模的Variational Inference的模型解法。&lt;/p&gt;

&lt;h3 id=&quot;direct-learning-to-rank-and-rerank&quot;&gt;Direct Learning to Rank And Rerank&lt;/h3&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v84/rudin18a/rudin18a.pdf&quot;&gt;PDF&lt;/a&gt;
&lt;a href=&quot;http://proceedings.mlr.press/v84/rudin18a/rudin18a-supp.pdf&quot;&gt;Supplementary PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;“排序学习”（Learning to Rank）是不是一个已经完全被研究过的领域呢？答案当然不是。这篇论文就是尝试在一个似乎已经被反复研究过的领域里找到一些新的知识。这篇论文的看点主要是使用了一种目标函数对已有的排序指标例如AUC、NDCG、MAP、MRR等进行了高度总结。另外，这篇文章提出，传统上，我们在优化这些方法或者这些指标的时候，并不是直接去优化这些指标，而是优化这些指标的一些“代理”（Proxy），而就是这些代理可能出了问题，使得最后的结果有可能会有很大的偏差。于是，这篇文章提出了一种直接优化目标函数的方法。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>Facebook的应用机器学习平台</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/12/22/facebook-ml/"/>
   <updated>2017-12-22T00:00:00-08:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/12/22/facebook-ml</id>
   <content type="html">&lt;p&gt;我们在这里对Facebook应用机器学习（Applied Machine Learning）组发布的文章&lt;a href=&quot;https://research.fb.com/publications/applied-machine-learning-at-facebook-a-datacenter-infrastructure-perspective/&quot;&gt;Applied Machine Learning at Facebook: A Datacenter Infrastructure Perspective&lt;/a&gt;进行一个简单的分析解读。这篇文章可以让我们对Facebook里机器学习平台以及各个产品应用这个平台的情况有一个很不错的了解。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://research.fb.com/wp-content/uploads/2017/12/hpca-2018-facebook.pdf&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章的作者群来自Facebook的17位工程师和科学家。这些人可能仅仅是整个平台的骨干成员。可以看出整个Facebook的机器学习平台是一个有非常多人协作搭建的复杂环境。&lt;/p&gt;

&lt;p&gt;这篇文章可以说是帮助外界解惑了很多迷思或者说是误解。同时，也给了大家一个学习大型互联网公司构建机器学习平台的机会。文章首先提出了一系列的重要观察：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;Facebook有很多机器学习的应用场景。计算机视觉的应用仅仅是一个小部分。&lt;/li&gt;
  &lt;li&gt;Facebook有一个很丰富的机器学习库，包括Support Vector Machines、Logistic Regression、GBDT、MultiLayer Perceptron、CNN和RNN。&lt;/li&gt;
  &lt;li&gt;Facebook目前的机器学习场景同时利用GPU和CPU。在训练的时候，有很多是根据需要使用GPU和CPU，但是在Inference的时候，绝大多数还是使用CPU。&lt;/li&gt;
  &lt;li&gt;Facebook的机器学习架构很在乎分布式训练。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;文章中列举了一些主要的Facebook机器学习应用场景包括我们熟知的News Feed、Ads和Search以外，还包括一些不那么为人知的应用，如Sigma（Facebook内部的Anomaly Detection的框架）、Lumos（看似是Image的Embedding和信息提取工具）、Facer（Facebook人脸识别框架）、Language Translation（顾名思义，就是一个语言翻译的平台）以及Speech Recognition（顾名思义，一个语音识别的平台）。由此可见，机器学习在Facebook里已经有了很广泛的应用。&lt;/p&gt;

&lt;p&gt;那么，这些应用究竟在使用什么模型呢？Facer在使用SVM。Sigma在使用GBDT。Ads、News Feed和Sigma都在使用MLP。而Lumos、Facer在使用CNN。Text Understanding、Translation、Speech Recognition在使用RNN。&lt;/p&gt;

&lt;p&gt;对于深度学习框架方面，目前Facebook支持两个框架：Caffe2和PyTorch。它们分别是生产环境和研究环境。作者们阐述了一下为什么要让这两个环境各不同。简而言之就是这两个环境的需求不用，一个要求稳定高效，一个要求能够灵活多变。当然，作者们也看到了多个深度学习框架带来的潜在问题。于是作者们提到了一个叫做Open Neural Network Exchange（ONNX）的交换格式。想来这个交换格式就是为了加快从一个框架到另外一个框架的转换速度。&lt;/p&gt;

&lt;p&gt;从模型训练的时效性来看，有些应用的训练是每天，比如News Feed，而Search是每个小时，而其他应用则有些是每个星期或者每好几个月。而在Inference来看，第一，作者们提到了，不同的应用有可能需要不同的Inference的架构（Architecture）。同时，作者们还提到了并不是一开始就需要最精确的预测，有时候可以先展现给用户看没那么精确的结果，然后更加精确的结果可以算好以后再推给用户。&lt;/p&gt;

&lt;p&gt;这篇文章还有很多细节的点值得关注。总之，如果你对机器学习在大型互联网公司的应用有兴趣，并且也想知道平台、软硬件的整体架构信息，这篇文章是一个不错的阅读材料。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>KDD 2017大会综述</title>
   <link href="http://column.hongliangjie.com/%E4%BC%9A%E8%AE%AE/2017/08/30/kdd2017/"/>
   <updated>2017-08-30T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E4%BC%9A%E8%AE%AE/2017/08/30/kdd2017</id>
   <content type="html">&lt;p&gt;每年，Association for Computing Machinery（ACM）旗下的Special Interest Group (SIG) on Knowledge Discovery and Data Mining（简称SIGKDD）都要举办年度的SIGKDD Conference on Knowledge Discovery and Data Mining（KDD）大会，为学术界和工业界的数据科学学者、研究人员、工程师以及学生提供一个交流、学习和发展的平台。今年，The 23rd SIGKDD Conference on Knowledge Discovery and Data Mining（KDD）于2017年8月13日到17日在加拿大的Halifax, Nova Scotia举行。&lt;/p&gt;

&lt;p&gt;KDD是数据挖掘以及数据科学领域的顶级会议。KDD最早从1989年开始的KDD 研讨班（Workshop）发展而来。当时的研讨班依托于IJCAI大会或者AAAI大会（另一个有影响力的人工智能大会），由Gregory Piatetsky-Shapiro创办。研讨班成功举办几届之后，1995年Usama Fayyad和Ramasamy (Sam) Uthurusamy把研讨班升级成为了会议，并且在加拿大的蒙特利尔举办了第一届的KDD大会。大会至今已经有20多年的历史。&lt;/p&gt;

&lt;h2 id=&quot;大会主要奖项&quot;&gt;大会主要奖项&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;今年的SIGKDD创新奖（ Innovation Award）授予了加拿大Simon Fraser University计算科学学院的教授Jian Pei。Jian是数据挖掘界的著名华人学者，是ACM和IEEE的双料院士。其发表过200多篇论文，引用量多达7万多次，Google H-Index达到74。他和Jiawei Han以及Micheline Kamber合著的数据挖掘教材《Data mining: Concepts And Techniques》已经成为经典读物，引用数就多于3万次。Jian还是IEEE 旗下的数据挖掘权威期刊Transactions of Knowledge and Data Engineering （TKDE）的主编，并且是清华大学以及浙江大学的客座教授。在此之前，Jian已经获得过2015年的SIGKDD服务奖（ Service Award）、 2014年 IEEE旗下数据挖掘会议 ICDM 的研究贡献奖（Research Contributions Award） ，以及2008年KDD 最佳应用论文奖（Best Application Paper Award）、2014年PAKDD 最佳论文奖（Best Paper Award）等。Jian是数据挖掘领域权威Jianwei Han的博士生（2002年毕业）。这次创新奖主要还提及了Jian在Sequential Pattern Mining（SPM）数据挖掘算法和研究领域的主要贡献，包括FP-Growth 和PrefixSpan算法。这两个算法都是著名的SPM算法，其中FP-Growth的论文（Mining Frequent Patterns without Candidate Generation）引用高达7千多次，而PrefixSpan的论文（PrefixSpan: Mining Sequential Patterns Efficiently by Prefix-Projected Pattern Growth）引用也多达2千多次。&lt;/p&gt;

&lt;p&gt;大会的另外一个重要奖项SIGKDD时间检验奖（Test of Time Award）授予了美国康奈尔大学信息科学系主任、计算机科学系教授Thorsten Joachims。这个时间检验奖主要是奖给过去10年左右的时间里在KDD的会议上发表的论文中最有影响力的工作（引用次数是其中一个指标）。Thorsten是机器学习界享有盛誉的学者，是ACM和AAAI的双料院士。所有论文超过4万次引用。他2001年在德国的多特蒙德大学博士毕业之后加入康奈尔大学从事机器学习的研究。在获得这个奖项之前，Thorsten获得过2017年ACM WSDM 的最佳论文奖（Best Paper Award）、2016年ACM SIGIR的时间检验奖（Test-of-Time Award）、2015年ACM KDD的时间检验奖、2009年ECML的最佳论文奖（Best Paper Award）、2009年ICML的10年最佳论文奖（Best 10-Year Paper Award）、2006年ACM KDD的最佳论文奖（Best Paper Award）、2005年ICML的最佳论文奖、2005年ICML的优秀学生论文奖、2005年ACM KDD的最佳学生论文奖等。这次时间检验奖授予Thorsten是为了表彰他的论文“Training Linear SVMs in Linear Time”。该论文也是2006年的KDD最佳论文，引用数超过1600多次。这篇文章解决的是大规模优化支持向量机（Support Vector Machines）的问题。在此之前的很多支持向量机的实现都无法达到线性的时间复杂度，因此也就无法应用到大规模的数据上。这篇文章是第一次提出了简单易行的支持向量机实现。算法对于分类问题（Classification）达到了O(SN)（其中S是非0的特征数目而N是数据点的个数），也就是实现了线性时间复杂度。算法本身简单、高效、易于实现，并且理论上可以扩展到Kernel的情况。Thorsten在他的软件包SVMLight中实现了该算法。这个软件包一度成为了支持向量机研究和开发的标准工具。&lt;/p&gt;

&lt;p&gt;大会还把今年的SIGKDD服务奖（Service Award）颁给了香港科技大学计算机系主任Qiang Yang教授，以表彰他在近几年推动SIGKDD的各种活动发展，特别是SIGKDD在中国的分部（China Chapter）所做的努力。Qiang本人是ACM杰出科学家、AAAI院士、IEEE院士。在他的领导下，2016年，SIGKDD中国分部开始运营。2016年一年，中国分部就举行了超过10场活动，并且吸引了超过500名会员。Qiang在中国还举行了多场研讨班和各类讲座，分享了关于Transfer Learning以及Recommendation Systems相关的很多研究成果。Qiang Yang本人的论文有超过3万次的引用。&lt;/p&gt;

&lt;p&gt;从会议论文的角度来看，这次会议的最佳研究类论文（Best Research Paper Award）授予了“ Accelerating Innovation Through Analogy Mining”，其作者群来自耶路撒冷希伯来大学以及卡内基梅隆大学。第二名则被“Toeplitz Inverse Covariance-Based Clustering of Multivariate Time Series”夺取，其作者群来自斯坦福大学。最佳应用数据科学论文（Best Applied Data Science Paper Award）被“HinDroid: An Intelligent Android Malware Detection System”取得，其作者群来自于西弗吉尼亚大学以及香港科技大学。第二名则被“DeepSD: Generating High Resolution Climate Change Projections”夺得，其作者群来自美国的东北大学以及美国NASA。&lt;/p&gt;

&lt;h2 id=&quot;大会参与概况&quot;&gt;大会参与概况&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;今年的大会是在美国本土外举办的最大的一届KDD会议。整个大会有1656名参会者，来自51个国家和地区。其中美国的参会者是最多、其次是中国、加拿大、印度。会议的赞助金额达到了54万美元，是在美国本土外举办的最高记录。为赞助学生旅行，大会总共奖励了高达15多万美元的金额，创下了大会的记录。论文的投稿数达到了1143篇，也是创下了最新的记录。大会最终录用了130篇文章，录用率在8%左右。可以说依然保持了非常高的会议水平。&lt;/p&gt;

&lt;p&gt;这次大会共有3个主题演讲（Keynote Speech）。64个报告演讲（Oral Presentation）和66个展板报告（Poster）。整个大会还有10个全天的研讨班（Workshop）和10个半天的闫天宝。大会包含了20个传统的讲座（Tutorial）以及8个实践（Hands-on）讲座。&lt;/p&gt;

&lt;h2 id=&quot;大会主题演讲&quot;&gt;大会主题演讲&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;这次的大会主题演讲有一个特色，那就是三位女性科学家组成的主题演讲者群体。&lt;/p&gt;

&lt;p&gt;大会第一个主题演讲来自Bin Yu，加州大学伯克利分校（University of California at Berkeley
）统计学教授。Bin Yu是美国科学院院士（U.S. National Academy of Sciences）、美国艺术与科学学院院士（American Academy of Arts and Sciences），还是IEEE院士、IMS院士、 ASA院士以及 AAAS院士。她长期从事统计、机器学习方法的研究以及如何应用领域知识解决复杂问题。Bin还是微软和北京大学统计和信息科学联合实验室的创始人。Bin的演讲主题是“Three Principles of Data Science: Predictability, Stability, and Computability”，主要试图讲解的是Stability对于Predictability以及Interpretability的重要性。Bin认为自己提出的这三个要素是统计学习的根本思想之一，他们之间的联系尤为重要。紧接着，她通过如何应用深度模型（特别是卷积神经网CNN）对神经元的活动进行观测这一个项目解释了这三个要素在具体事例中的呈现。她在演讲的第二部分讲解了如何利用隐变量模型（Latent Variable Models）以及基于LASSO的模型来分析政治性的电视广告中的语气和政党倾向性。这两个项目都展现了Bin所谓的稳定性（Stability）对于预测性（Predictability）的重要性。&lt;/p&gt;

&lt;p&gt;第二个主题演讲来自Cynthia Dwork，哈佛大学教授、微软研究院杰出科学家（Distinguished Scientist）。Cynthia是美国科学院院士（National Academy of Sciences）、美国工程院院士（National Academy of Engineering）、美国艺术与科学学院院士（American Academy of Arts and Sciences）、美国哲学学会院士（American Philosophical Society）以及ACM院士。Cynthia长期致力于基于隐私的数据分析（Privacy-Preserving Data Analysis）的工作，并且是著名的Differential Privacy思想的提出者之一。2015年获得理论计算机界的哥德尔奖。Cynthia演讲的主题是“What’s Fair?”。这个是一个近期越来越收到关注的题目，那就是人工智能或者机器学习算法会不会因为从过去的数据中学习从而带有过去的偏见。典型的偏见有比如在预测犯罪的时候，对某一个种族或者族群会有高于常规的预测率。这个演讲就是讨论了包括如何定义是否“公平”，如何算是有偏见，到底是个人偏见还是群体偏见等等问题。从现场的反应来看，总体感觉，算法的公平性或者偏见性是一个非常新、而且可能会有争议性的话题。Cynthia在这个场合提出来也是需要一定勇气和远见的。&lt;/p&gt;

&lt;p&gt;第三个主题演讲来自Renée J. Miller，多伦多大学信息系统系主任、计算机系教授。Renée是加拿大皇家协会院士（Royal Society of Canada）、加拿大科学院院士（Canada’s National Academy）以及ACM院士。Renée是一个具有神秘色彩的学者。大会网站上并没有放她的照片，原因是她不愿意自己的相貌被搜索引擎给准确记住。Renée的演讲主题是“The Future of Data Integration”。应该说这个主题放在一个以数据科学为核心的会议上还是很应景的。毕竟，很多都说数据科学80%甚至更多的时间在处理数据而只有20%的时间在做真正的算法和模型革新。Renée从数据库领域出发，用非常浅显的语言讲解了这20年数据集成（Data Integration）领域的主要发现，以及如何利用这些核心算法来达到“发掘数据和整个数据格式”的作用。&lt;/p&gt;

&lt;h2 id=&quot;大会的几个趋势&quot;&gt;大会的几个趋势&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;这次会议有这么几个趋势和亮点：&lt;/p&gt;
&lt;ul&gt;
  &lt;li&gt;大家更加重视模型，特别是深度学习模型的可解释性。&lt;/li&gt;
  &lt;li&gt;Causal Inference和Machine Learning的结合成为新方向。&lt;/li&gt;
  &lt;li&gt;对算法和模型的去Bias成为一个新的课题。&lt;/li&gt;
  &lt;li&gt;各大公司的招聘力度非常大，在某一天内就有Amazon、Microsoft、Airbnb、Snapchat、Pinterest以及其它公司的Happy Hour，感觉人才就在那么几家公司赶场。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;总体最大的感觉是KDD已经成为了数据科学的盛宴。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>ACL 2017文章精读（五）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/08/07/acl2017-language-to-program/"/>
   <updated>2017-08-07T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/08/07/acl2017-language-to-program</id>
   <content type="html">&lt;p&gt;我们在这里对&lt;a href=&quot;http://acl2017.org/&quot;&gt;ACL 2017&lt;/a&gt;文章From Language to Programs: Bridging Reinforcement Learning and Maximum Marginal Likelihood进行一个简单的分析解读。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://arxiv.org/abs/1704.07926&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/kelvinguu/lang2program&quot;&gt;代码地址&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章的作者群来自斯坦福大学。主要的作者们来自Percy Liang的实验室。最近几年Percy Liang的实验室可以说收获颇丰，特别是在自然语言处理（NLP）和深度学习（Deep Learning）的结合上都有不错的显著成果。&lt;/p&gt;

&lt;p&gt;这篇文章里有好一些值得关注的内容。首先从总体上来说，这篇文章要解决的问题是怎么从一段文字翻译成为“程序”的问题。这可以说是一个很有价值的问题。如果这个问题能够可以容易解决，那么我们就可以教会计算机编写很多程序，而不一定需要知道程序语言的细微的很多东西。从细节上说，这个问题就是，给定一个输入的语句，一个模型需要把目前的状态转移到下一个目标状态上。这里面的难点是，对于同一个输入语句，从当前的状态到可能会到达多种目标状态。这些目标状态都有可能是对当前输入语句的一种描述。但是正确的描述其实是非常有限的，甚至是唯一的。那么，如何从所有的描述中，剥离开不正确的，找到唯一的或者少量的正确描述，就成为了这么一个问题的核心。&lt;/p&gt;

&lt;p&gt;文章中采用了一个Neural Encoder-Decoder的模型架构。这种模型主要是对序列信息能够有比较好的效果。具体说来，那就是对于现在的输入语句，首先把输入语句变换成为一个语句向量，然后根据之前已经产生的程序状态，以及当前的语句向量，产生现在的程序状态。在这个整个的过程中，对于Encoder作者们采用了LSTM的架构，而对于Decoder作者们采用了普通的Feed-forward Network（原因文章中是为了简化）。另外一个比较有创新的地方就是作者们把过于已经产生程序状态重新给Embedding化（作者们说是叫Stack）。这有一点模仿普通数据结构的意思。&lt;/p&gt;

&lt;p&gt;那么，这个模型架构应该说还是比较经典的。文章这时候就引出了另外一个本文的主要贡献，那就是对模型学习的流程进行了改进。为了引出模型学习的改进，作者们首先讨论了两种学习训练模式的形式，那就是强化学习（Reinforcement Learning）以及MML（Maximum Marginal Likelihood）的目标函数的异同。文章中提出两者非常类似，不过比较小的区别造成了MML可以更加容易避开错误程序这一结果。文章又比较了基于REINFORCE算法的强化学习以及基于Numerical Integration以及Beam Search的MML学习的优劣。总体说来，REINFORCE算法对于这个应用来说非常容易陷入初始状态就不太优并且也很难Explore出来的情况。MML稍微好一些，但依然有类似问题。文章这里提出了Randomized Beam Search来解决。也就是说在做Beam Search的时候加入一些Exploration的成分。另外一个情况则是在做Gradient Updates的时候，当前的状态会对Gradient有影响，也就是说，如果当前状态差强人意，Gradient也许就无法调整到应该的情况。这里，作者们提出了一种叫Beta-Meritocratic的Gradient更新法则，来解决当前状态过于影响Gradient的情况。&lt;/p&gt;

&lt;p&gt;实验的部分还是比较有说服里的，详细的模型参数也是一应俱全。对于提出的模型来说，在三个数据集上都有不错的表现。当然，从准确度上来说，这种从文字翻译到程序状态的任务离真正的实际应用还有一段距离。&lt;/p&gt;

&lt;p&gt;这篇文章适合对于最近所谓的Neural Programming有兴趣的读者泛读。对怎么改进强化学习或者MML有兴趣的读者精读。文章的“Related Work”部分也是非常详尽，有很多工作值得参考。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>ACL 2017文章精读（四）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/08/06/acl2017-skim-text/"/>
   <updated>2017-08-06T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/08/06/acl2017-skim-text</id>
   <content type="html">&lt;p&gt;我们在这里对&lt;a href=&quot;http://acl2017.org/&quot;&gt;ACL 2017&lt;/a&gt;文章Learning to Skim Text进行一个简单的分析解读。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://arxiv.org/abs/1704.06877&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章的作者群来自Google。这篇文章是第一作者来自卡内基梅隆大学的Adams Wei Yu在Google实习的时候做的工作。第三作者的Quoc V. Le曾是Alex Smola和Andrew Ng的高徒，在Google工作期间有很多著名的工作，比如Sequence to Sequence Model来做机器翻译（Machine Translation）等。&lt;/p&gt;

&lt;p&gt;这篇文章想要解决的的问题叫做“Skim Text”。简单说来，就是在文字处理的时候，略过不重要的部分，对重要的部分进行记忆和阅读。也就是说，要教会模型知道在哪里需要略过不读，哪里需要重新开始阅读的能力。略过阅读的另外一个好处则是对文字整体的处理速度明显提高，而且很有可能还会带来质量上的提升（因为处理的噪声信息少了、垃圾信息少了）。&lt;/p&gt;

&lt;p&gt;具体说来，这篇文章是希望在LSTM的基础上加入“跳转”功能，从而使得这个时序模型能够有能力判读是否要略过一部分的文字信息。简单说来，作者们是这么对LSTM进行改进的。首先，有一个参数R来确定要读多少文字。然后模型从一个0到K的基于Multinomial分布的这一个跳转机制中决定当前需要往后跳多少文字（可以是0，也就是说不跳转）。这个是否跳转的这一个步骤所需要的Multinomial分布，则也要基于当期那LSTM的隐参数信息（Hidden State）。跳转决定以后，根据这个跳转信息，模型会看一下是否已经达到最大的跳转限制N。，如果没有则往后跳转。当所有的这些步骤都走完，达到一个序列（往往是一个句子）的结尾的时候，最后的隐参数信息会用来对最终需要的目标（比如分类标签）进行预测。&lt;/p&gt;

&lt;p&gt;这篇文章的另外一个创新点，也就是引入了强化学习（Reinforcement Learning）到模型的训练中。最终从隐参数到目标标签（Label）的这一步往往采用的是Cross Entropy的优化目标函数。这一个选择很直观，也是一个标准的步骤。然而，如何训练跳转的Multinomial分布，因为其离散（Discrete）特质，则成为文章的难点。原因是Cross Entropy无法直接应用到离散数据上。那么，这篇文章采取的思路是把这个问题构造成为强化学习的例子，从而使用最近的一些强化学习思路来把这个离散信息转化为连续信息。具体说来，就是采用了Policy Gradient的办法，在每次跳转正确的时候，得到一个为+1的反馈，反之则是-1。这样就把问题抓换成为了学习跳转策略的强化学习模式。文章采用了REINFORCE的算法来对这里的离散信息做处理。从而把Policy Gradient的计算转换为了一个近似逼近。这样，最终的目标函数来自于三个部分，第一个部分是Cross Entropy，第二个部分是Policy Gradient的逼近，第三个部分则是一个Variance Reduction的控制项（为了优化更加有效）。整个目标函数就可以完整得被优化了。&lt;/p&gt;

&lt;p&gt;文章在好多种实验类型上做了实验，主要比较的就是没有跳转信息的标准的LSTM。其实总体上来说，很多任务（Task）依然比较机械和人工。比如最后的用一堆句子，来预测中间可能会出现的某个词的情况，这样的任务其实并不是很现实。但是，文章中提到了一个人工（Synthetic）的任务还蛮有意思，那就是从一个数组中，根据下标为0的数作为提示来跳转取得相应的数作为输出这么一个任务。这个任务可以说是充分的展示了LSTM这类模型，以及文章提出的模型的魅力：第一，可以非常好的处理这样的非线性时序信息，第二，文章提出的模型比普通的LSTM快不少，并且准确度也提升很多。&lt;/p&gt;

&lt;p&gt;总体说来，这篇文章非常值得对时序模型有兴趣的读者精读。文章的“Related Work”部分也很精彩，对相关研究有兴趣的朋友可以参考这部分看看最近都有哪些工作很类似。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>ACL 2017文章精读（三）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/08/05/acl2017-rl-dl/"/>
   <updated>2017-08-05T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/08/05/acl2017-rl-dl</id>
   <content type="html">&lt;p&gt;我们在这里对&lt;a href=&quot;http://acl2017.org/&quot;&gt;ACL 2017&lt;/a&gt;文章Towards End-to-End Reinforcement Learning of Dialogue Agents for Information Access进行一个简单的分析解读。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://arxiv.org/abs/1609.00777&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/MiuLab/KB-InfoBot&quot;&gt;代码地址&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章的作者群来自于微软研究院、卡内基梅隆大学和台湾国立大学。文章中还有Lihong Li和Li Deng（邓力）这样的著名学者的影子。第一作者的Bhuwan Dhingra是在卡内基梅隆大学William W. Cohen和Ruslan Salakhutdinov的博士学生。两位导师都十分有名气。而这个学生这几年在NLP领域可以说是收获颇丰：在今年的ACL上已经发表2篇文章，之前在今天的ICLR和AAAI上都有论文发表。&lt;/p&gt;

&lt;p&gt;这篇文章的核心思想是如何训练一个多轮（Multi-turn）的基于知识库（Knowledge Base）的对话系统。这个对话系统的目的主要还是帮助用户从这个知识库中来获取一些信息。那么，传统的基于知识库的对话系统的主要弊病在于中间有一个步骤是对于“知识库的查询”。也就是说，系统必须根据用户提交的查询（Query），进行分析并且产生结果。这一步，作者们称为“硬查询”（Hard-Lookup）。虽然这一步非常自然，但是这一步阻断了（Block）了整个流程，使得整个系统没法“端到端”（End-to-End）进行训练。并且，这一步由于是“硬查询”，并没有携带更多的不确定信息，不利于系统的整体优化。&lt;/p&gt;

&lt;p&gt;这篇文章其实就是想提出一种“软查询”从而让整个系统可以得以“端到端”（End-to-End）得进行训练。这个新提出的“软查询”步骤，和强化学习（Reinforcement Learning）相结合，共同完成整个的回路，从而在这个对话系统上达到真正的“端到端”。这就是整个文章的核心思想。&lt;/p&gt;

&lt;p&gt;那么，这个所谓的“软查询”是怎么回事？其实就是整个系统保持一个对知识库中的所有本体（Entities）所可能产生的值的一个后验分布（Posterior Distribution）。也就是说，作者们构建了这么一组后验分布，然后可以通过对这些分布的更新（这个过程是一个自然获取新数据，并且更新后验分布的过程），来对现在所有本体的确信度有一个重新的估计。这一步的转换，让对话系统从和跟知识库直接打交道，变成了如何针对后验分布打交道。而显然，从机器学习的角度来说，和分布打交道往往容易简单很多。具体说来，系统的后验分布是一个关于用户在第T轮，针对某个值是否有兴趣的概率分布。&lt;/p&gt;

&lt;p&gt;整个对话系统是这样运行的。首先，用户通过输入的对话（Utterance）来触发系统进行不同的动作（Action）。动作空间（Action Space）包含向用户询问某个Slot的值，或者通知用户目前的结果。整个系统包含三个大模块：一个Belief Trackers、一个Soft-KB Lookup以及一个Policy Network。&lt;/p&gt;

&lt;p&gt;Belief Trackers的作用是对整个系统现在的状态有一个全局的掌握。这里，每一个Slot都有一个Tracker，一个是根据用户当前的输入需要保持一个对于所有值的Multinomial分布，另外的则是需要保持一个对于用户是否知道这个Slot的值的置信值。文章中奖了Hand-Crafted Tracker和Neural Belief Tracker（基于GRU）的细节，这里就不复述了。有了Tracker以后，Soft-KB Lookup的作用是保持一个整个对于本体的所有值得后验分布。最后，这些后验概率统统被总结到了一个总结向量（Summary Vector）里。这个向量可以认为是把所有的后验信息给压缩到了这个向量里。而Policy Network则根据这个总结向量，来选择整个对话系统的下一个动作。这里文章也是介绍了Hand-Crafted的Policy和Neural Policy两种情况。我们就不复述了。&lt;/p&gt;

&lt;p&gt;整个模型的训练过程还是有困难的。虽然作者用了REINFORCE的算法，但是，作者们发现根据随机初始化的算法没法得到想要的效果。于是作者们采用了所谓的Imitation Learning的方法，也就是说，最开始的时候去模拟Hand-Crafted Agents的效果。&lt;/p&gt;

&lt;p&gt;在这篇文章里，作者们采用了模拟器（Simulator）的衡量方式。具体说来，就是通过与一个模拟器进行对话从而训练基于强化学习的对话系统。作者们用了MovieKB来做数据集。总体说来整个实验部分都显得比较“弱”。没有充足的真正的实验结果。&lt;/p&gt;

&lt;p&gt;可以说整个文章真正值得借鉴主要还是那个“软查询”的思想。整个流程也值得参考。但是训练的困难可能使得这个系统作为一个可以更加扩展的系统的价值不高。本文值得对对话系统有研究的人泛读。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>ACL 2017文章精读（二）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/08/04/acl2017-neural-lm/"/>
   <updated>2017-08-04T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/08/04/acl2017-neural-lm</id>
   <content type="html">&lt;p&gt;我们在这里对&lt;a href=&quot;http://acl2017.org/&quot;&gt;ACL 2017&lt;/a&gt;文章Topically Driven Neural Language Model进行一个简单的分析解读。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://arxiv.org/abs/1704.08012&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/jhlau/topically-driven-language-model&quot;&gt;代码地址&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章的作者都来自于澳大利亚的研究人员。第一作者Jey Han Lau目前在澳大利亚的IBM进行Topic Model以及NLP方面的研究，之前也在第二作者Timothy Baldwin的实验室做过研究。第二作者Timothy Baldwin和第三作者Trevor Cohn都是在墨尔本大学长期从事NLP的研究的教授。&lt;/p&gt;

&lt;p&gt;这篇文章的核心思想是想彻底用Neural的思想来做结合Topic Model和Language Model。当然，既然这两种模型都是文字处理方面的核心模型，自然之前就有人曾经想过要这么做。不过之前的不少尝试都是要么还想保留LDA的一些部件或者往传统的LDA模型上去靠，要么是并没有和Language Model结合起来。这篇文章的主要卖点是完全用深度学习的“语言”来构建了整个模型，并且模型中的Topic Model模型部分的结果会成为驱动Language Model部分的成分。&lt;/p&gt;

&lt;p&gt;概括说来，文章提出了一个有两个组成部分的模型的集合（文章管这个模型叫tdlm）。第一个部分就是所谓的Topic Model的部分。我们已经提过，这里的Topic Model和LDA已经相去甚远。这里的思路是这样的，首先，从一个文字表达的矩阵中（有可能就直接是传统的Word Embedding），通过Convolutional Filters转换成为一些文字的特征表达（Feature Vector）。文章里面选用的是线性的转换方式。这些Convolutional Filters都是作用在文字的一个Window上面，所以从概念上讲，这一个步骤很类似Word Embedding。得到这些Feature Vector以后，作者们又使用了一个Max-Over-Time的Pooling动作（也就是每一组文字的Feature Vector中最大值），从而产生了文档的表达。注意，这里依然学到的依然是比较直接的Embedding。然后，作者们定义了这么一组Topic的产生形式。首先，是有一个“输入Topic矩阵”。这个矩阵和已经得到的文档特征一起，产生一个叫做Attention的向量。这个Attention的向量再和“输出Topic矩阵”一起作用，产生最终的文档Topic向量。这也就是这部分模型的主要部分。最终，这个文档Topic向量通过用于预测文档中的每一个字来被学习到。有了这个文档Topic向量以后，作者们把这个信息用在了一个基于LSTM的Language Model上面。这一部分，其实就是用了一个类似于GRU的功能，把Topic的信息给附加在Language Model上。&lt;/p&gt;

&lt;p&gt;文章在训练的时候，采用了Joint训练的方式，并且使用了Google发布的Word2Vec已经Pre-trained的Word Embedding。所采用的种种参数也都在文章中已经有所介绍。
文章在好一些数据集上做了实验。对于Topic的部分来说，文章主要是和LDA做比较，用了Perplexity这个传统的测量，还比较了Topic Coherence等。总体说来，提出的模型和LDA不相上下。Language Model的部分来说，提出的模型也在APNews、IMDB和BNC上都有不错的Perplexity值。&lt;/p&gt;

&lt;p&gt;总体说来，这篇文章值得文字挖掘的研究者和NLP的研究者泛读。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>ACL 2017文章精读（一）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/07/27/acl2017-multimodal/"/>
   <updated>2017-07-27T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/07/27/acl2017-multimodal</id>
   <content type="html">&lt;p&gt;我们在这里对&lt;a href=&quot;http://acl2017.org/&quot;&gt;ACL 2017&lt;/a&gt;文章Multimodal Word Distributions进行一个简单的分析解读。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://arxiv.org/abs/1704.08424&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://github.com/benathi/word2gm&quot;&gt;代码地址&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;文章作者&lt;a href=&quot;https://stat.cornell.edu/people/phds/ben-athiwaratkun&quot;&gt;Ben Athiwaratkun&lt;/a&gt;是康奈尔大学统计科学系的博士生。而Andrew Gordon Wilson则是新近加入康奈尔大学Operation Research以及Information Engineering的助理教授。其之前在卡内基梅隆大学担任研究员，师从Eric Xing教授和Alex Smola教授。再之前，其则在University of Cambridge的Zoubin Ghahramani手下攻读博士学位。&lt;/p&gt;

&lt;p&gt;这篇文章主要是要研究Word Embedding，其核心思想其实很直观，那就是想用Gaussian Mixture Model去表示每一个Word的Embedding。最早的自然语言处理（NLP）是采用了One-Hot-Encoding的Bag of Word的形式来处理每个字。这样的形式自然是无法抓住文字之间的语义和更多有价值的信息的。那么，之前Word2Vec的想法则是学习一个每个Word的Embedding，也就是一个实数的向量，用于表示这个Word的语义。当然，如何构造这么一个向量又如何学习这个向量成为了诸多研究的核心课题。&lt;/p&gt;

&lt;p&gt;在ICLR 2015会议上，来自UMass的Luke Vilnis 和Andrew McCallum在 “Word Representations via Gaussian Embedding”这篇文章中提出了用分布的思想来看待这个实数向量的思想。具体说来，就是认为这个向量是某个高斯分布的期望，然后通过学习高斯分布的参数（也就是期望和方差）来最终学习到Word的Embedding Distribution。这一步可以说是扩展了Word Embedding这一思想。然而，用一个分布来表达每一个字的最直接的缺陷则是无法表达很多字的多重意思，这也就是带来了这篇文章的想法。&lt;/p&gt;

&lt;p&gt;这篇文章是希望通过Gaussian Mixture Model的形式来学习每个Word的Embedding。也就是说，每个字的Embedding不是一个高斯分布的期望了，而是多个高斯分布的综合。这样，就给了很多Word多重意义的自由度。在有了这么一个模型的基础上，文章采用了类似Skip-Gram的来学习模型的参数。具体说来，文章沿用了Luke和Andrew的那篇文章所定义的一个叫Max-margin Ranking Objective的目标函数，并且采用了Expected Likelihood Kernel来作为衡量两个分布之间相似度的工具。这里就不详细展开了，有兴趣的读者可以精读这部分细节。&lt;/p&gt;

&lt;p&gt;文章通过UKWAC和Wackypedia数据集学习了所有的Word Embedding。所有试验中，文章采用了K=2的Gaussian Mixture Model（文章也有K=3的结果）。比较当然有之前Luke的工作以及其他各种Embedding的方法，比较的内容有Word Similarity以及对于Polysemous的字的比较。总之，文章提出的方法非常有效果。&lt;/p&gt;

&lt;p&gt;这篇文章因为也有源代码（基于Tensorflow），推荐有兴趣的读者精读。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>Google Scholar 2017学术指标之人工智能篇</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/07/09/google-scholar/"/>
   <updated>2017-07-09T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/07/09/google-scholar</id>
   <content type="html">&lt;p&gt;近日，Google Scholar发布了一个&lt;a href=&quot;https://scholar.googleblog.com/2017/07/2017-scholar-metrics-released.html&quot;&gt;2017年的“学术指标”&lt;/a&gt;，主要是对各个学科的众多领域的学术刊物（包括期刊、会议论文集以及在线论文出版集）做出了排名。这个排名主要是依靠&lt;a href=&quot;https://en.wikipedia.org/wiki/H-index&quot;&gt;H5-Index&lt;/a&gt;这一指标。我们在这篇文章里，对人工智能相关的领域学术出版刊物的排名进行一个简单的分析和导读。&lt;/p&gt;

&lt;h2 id=&quot;人工智能主类&quot;&gt;人工智能主类&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/google_ai.png&quot; alt=&quot;&quot; /&gt;
因为收率了在线论文出版集（主要是ArXiv），借着深度学习（Deep Learning）的春风，ArXiv的Learning子类成为了目前最有影响力的出版集。当然，考虑到目前在深度学习以及更加广阔的机器学习领域已经有了把论文的某一个版本率先发表到ArXiv的习惯，Learning子类的实际影响力可能要打一些折扣。不过，不可否认的则是这样的发布学术结果的方式的确对计算机科学（Computer Science）原本的发表模式有了很深远的挑战和影响。
&lt;img src=&quot;/assets/google_ai_learning.png&quot; alt=&quot;&quot; /&gt;
有意思的是，尽管引用度排名靠前的大多数文章最终都在传统的会议或者期刊上面发表，排名第四的&lt;a href=&quot;https://arxiv.org/abs/1212.5701&quot;&gt;ADADELTA: An Adaptive Learning Rate Method&lt;/a&gt;（应用数超过900）则并没有在任何传统刊物上有出版。还有引用度超过500的&lt;a href=&quot;https://arxiv.org/abs/1312.5602&quot;&gt;Playing Atari with Deep Reinforcement Learning&lt;/a&gt;也没有在传统的刊物上发表出版。这些都显示了ArXiv作为当前出版渠道的重要补充的这一作用。我们再来看一下传统刊物中排名第一的NIPS的排名靠前的文章：
&lt;img src=&quot;/assets/google_ai_nips.png&quot; alt=&quot;&quot; /&gt;
首先我们发现的是，排名靠前的无一例外地都是和深度学习有密切联系的文章。排名第一的则是Hinton及其学生提出的&lt;a href=&quot;http://papers.nips.cc/paper/4824-imagenet-classification-with-deep-convolutional-neural-networks&quot;&gt;AlexNet&lt;/a&gt;的这一开创性的研究成果，一举奠定了深度学习在计算机视觉领域的主导地位的历史性文章。排名第二的则是提出目前在NLP等领域广泛使用的&lt;a href=&quot;http://papers.nips.cc/paper/5021-distributed-representations-of-words-and-phrases-and-their-compositionality&quot;&gt;Word2Vec&lt;/a&gt;的论文，也可以说实至名归。总之，NIPS排名靠前的论文还是非常有含金量的标志性研究成果。和NIPS齐名的机器学习会议ICML也在排名上位列第4。
&lt;img src=&quot;/assets/google_ai_icml.png&quot; alt=&quot;&quot; /&gt;
和NIPS类似的也是排位靠前的文章基本上被深度学习相关的研究成果所把持。相比之下，排位稍微靠后的期刊&lt;a href=&quot;http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=5962385&quot;&gt;IEEE Transactions on Neural Networks and Learning Systems&lt;/a&gt;以及&lt;a href=&quot;http://www.jmlr.org/&quot;&gt;The Journal of Machine Learning Research&lt;/a&gt;则多了不少机器学习其他领域的研究成果。
&lt;img src=&quot;/assets/google_ai_jmlr.png&quot; alt=&quot;&quot; /&gt;
比如，最近几年又重新红火起来的大规模Bayesian Inference的代表作&lt;a href=&quot;http://www.jmlr.org/papers/volume14/hoffman13a/hoffman13a.pdf&quot;&gt;Stochastic variational inference&lt;/a&gt;以及开创了Moment Matching旧瓶装新酒的&lt;a href=&quot;http://www.jmlr.org/papers/volume15/anandkumar14b/anandkumar14b.pdf&quot;&gt;Tensor decompositions for learning latent variable models&lt;/a&gt;也都名列前茅。通过我们这里简单的分析和总结，不难发现最近五年AI界的成果还是集中在深度学习界，而且是传统刊物NIPS和ICML都成为了推动深度学习发展的重要领军会议。而ArXiv则在这个过程中发挥着不可替代的辅助性作用。&lt;/p&gt;

&lt;h2 id=&quot;计算机视觉&quot;&gt;计算机视觉&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/google_cv.png&quot; alt=&quot;&quot; /&gt;
我们看了人工智能主类之后，我们来关注一下几个人工智能的分类的动态。那么要说最近几年发展得最迅猛的人工智能分支，无疑要数计算机视觉技术。不过，相比于人工智能主类的好几大主流会刊的情况，在计算机视觉领域，目前的格局依然是&lt;a href=&quot;https://en.wikipedia.org/wiki/Conference_on_Computer_Vision_and_Pattern_Recognition&quot;&gt;CVPR&lt;/a&gt;和&lt;a href=&quot;http://ieeexplore.ieee.org/xpl/RecentIssue.jsp?punumber=34&quot;&gt;PAMI&lt;/a&gt;独秀的情况。而ArXiv的补充作用在这里也显示得很明显。
&lt;img src=&quot;/assets/google_cv_cvpr.png&quot; alt=&quot;&quot; /&gt;
我们来看看CVPR的这几年的有影响力的工作，无疑都和ImageNet的主要进步联系起来。比如排名第一的&lt;a href=&quot;http://www.cv-foundation.org/openaccess/content_cvpr_2015/papers/Szegedy_Going_Deeper_With_2015_CVPR_paper.pdf&quot;&gt;Going Deeper With Convolutions&lt;/a&gt;所代表的GoogleNet，以及排名第二的&lt;a href=&quot;http://www.cv-foundation.org/openaccess/content_cvpr_2014/papers/Girshick_Rich_Feature_Hierarchies_2014_CVPR_paper.pdf&quot;&gt;Rich Feature Hierarchies for Accurate Object Detection and Semantic Segmentation&lt;/a&gt;所提出的R-CNN和排名第三的&lt;a href=&quot;http://www.cv-foundation.org/openaccess/content_cvpr_2016/papers/He_Deep_Residual_Learning_CVPR_2016_paper.pdf&quot;&gt;Deep Residual Learning for Image Recognition&lt;/a&gt;所提出的ResNet。这些都是最近几年借助大幅度提高ImageNet的效果而在CV领域获得重点关注的文章。&lt;/p&gt;

&lt;h2 id=&quot;计算语言学&quot;&gt;计算语言学&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/google_nlp.png&quot; alt=&quot;&quot; /&gt;
人工智能在计算语言学的应用主要体现在自然语言处理（NLP）等领域。借着深度学习在NLP领域的影响和发展，ArXiv成为一个主要的文章发表场所似乎也是顺利成长的事情了。和人工智能主类相似的情况是，在ArXiv上面发布的重要文章最后都在相应的会议或者期刊有所发表，唯一例外的是有3600多引用的&lt;a href=&quot;https://arxiv.org/abs/1301.3781&quot;&gt;Efficient Estimation of Word Representations in Vector Space&lt;/a&gt;。从分布的情况上看，过去几年的大多数影响力大的文章主要分为在Word2Vec方面做文章，以及在Machine Translation或者Sequence Model方面做文章。排名第二第三的依然是NLP领域传统的旗舰会议ACL和EMNLP。
&lt;img src=&quot;/assets/google_nlp_acl.png&quot; alt=&quot;&quot; /&gt;
&lt;img src=&quot;/assets/google_nlp_emnlp.png&quot; alt=&quot;&quot; /&gt;
我们可以看到深度学习，特别是学习文字的Embedding（包括字、文章段落等等）占据了很重要的一个研究方向。另外一个重要的研究方向就是机器翻译，特别是如何应用深度学习在这方面的成果。需要特别注意的是，斯坦福大学&lt;a href=&quot;https://nlp.stanford.edu/manning/&quot;&gt;Christopher Manning&lt;/a&gt;的研究组最近几年可以说是成果颇丰。高排名的好几篇ACL以及EMNLP都看得见他的身影。&lt;/p&gt;

&lt;h2 id=&quot;数据挖掘和信息系统&quot;&gt;数据挖掘和信息系统&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/google_dm_1.png&quot; alt=&quot;&quot; /&gt;
&lt;img src=&quot;/assets/google_dm_2.png&quot; alt=&quot;&quot; /&gt;
Google把整个数据挖掘和信息系统分为了两类“Data Mining &amp;amp; Analysis”和“Database &amp;amp; Information Systems”。然而在实际中这两类的文章和成果经常交叉出现，于是我们这里就一起讨论这两个分类。一个比较有意思的情况就是，ArXiv还并没有成为这个领域的主要发布工具。传统的&lt;a href=&quot;http://www.kdd.org/&quot;&gt;KDD&lt;/a&gt;以及&lt;a href=&quot;https://en.wikipedia.org/wiki/International_World_Wide_Web_Conference&quot;&gt;WWW&lt;/a&gt;依然占据着重要的成果发布平台的地位。我们来看一下KDD的最新经典论文：
&lt;img src=&quot;/assets/google_dm_kdd.png&quot; alt=&quot;&quot; /&gt;
可以说是涉及范围十分广泛。从Social Network Analysis到Time Series Analysis再到一般性质的Data Mining的算法和工具，KDD还是展现了这个发布平台的包容性和多样性。其中排名第二的&lt;a href=&quot;http://dl.acm.org/citation.cfm?id=2623623&quot;&gt;Knowledge vault: a web-scale approach to probabilistic knowledge fusion&lt;/a&gt;，这一讲述Google的知识图谱的技术论文和在2016年才发表的&lt;a href=&quot;http://dl.acm.org/citation.cfm?id=2939785&quot;&gt;XGBoost: A Scalable Tree Boosting System&lt;/a&gt;在短时间内吸引了不少相关学者的关注。下面我们来看看WWW的情况：
&lt;img src=&quot;/assets/google_dm_www.png&quot; alt=&quot;&quot; /&gt;
可以看出过去5年来，关于Social Media（以Twitter为主）和关于Social Network Analysis的相关研究还是如火如荼。而纵观KDD和WWW都可以看到斯坦福大学的明星学者&lt;a href=&quot;https://cs.stanford.edu/people/jure/&quot;&gt;Jure Leskovec&lt;/a&gt;的强大存在。&lt;/p&gt;

&lt;h2 id=&quot;总结&quot;&gt;总结&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;我们仅仅是在这里总结了和人工智能有关的几个分类的趋势。总体说来有这么几个特点：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;人工智能和机器学习的核心领域目前基本上完全围绕着深度学习展开。&lt;/li&gt;
  &lt;li&gt;计算机视觉和自然语言处理目前也是和深度学习有很强的联系。&lt;/li&gt;
  &lt;li&gt;数据挖掘相关的研究依然非常多样化。&lt;/li&gt;
  &lt;li&gt;ArXiv已经成为了非常强有力的辅助性研究成果发布平台。然而有影响力的文章最终还是在核心刊物上发表。&lt;/li&gt;
  &lt;li&gt;传统的NIPS、ICML、CVPR、ACL、EMNLP、KDD和WWW依然是人工智能的核心研究成果发布刊物。&lt;/li&gt;
&lt;/ul&gt;
</content>
 </entry>
 
 <entry>
   <title>AIStats 2017文章精读（五）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/06/18/aistats2017-dist-sgd/"/>
   <updated>2017-06-18T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/06/18/aistats2017-dist-sgd</id>
   <content type="html">&lt;p&gt;我们在这里对&lt;a href=&quot;http://www.aistats.org/&quot;&gt;AIStats 2017&lt;/a&gt;文章Communication-Efficient Learning of Deep Networks from Decentralized Data进行一个简单的分析解读。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v54/mcmahan17a/mcmahan17a.pdf&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v54/mcmahan17a/mcmahan17a-supp.pdf&quot;&gt;文章附加信息&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章的作者群来自Google。文章的核心内容讲的是一个非常有实际意义的问题，那就是在分布式网络的情况下，如何构建合理的机器学习框架。这里说的分布式网络，指的是类似于手机网络这样的系统，用户有不同的数据集合（按照统计意义来说，通常是非IID的），并且这里面主要的陈本是通信陈本，而非计算陈本。传统的设置是不同的分布的数据可能是均匀IID的，而作者们认为在现实情况下，这是很难达到的一种状态。这里面还需要考虑的一些情况就是，如果作为手机客户端的话，每天能够参与优化模型的时间和次数都是有限的（根据电量等因素），因此如何设计一套有效的优化方案就显得非常必要。&lt;/p&gt;

&lt;p&gt;这篇文章提出的方案其实非常简单直观。算法总共有三个基本的参数，C（0到1）控制相对有多少数量的客户端参与优化，E控制每一轮多少轮SGD需要在客户端运行，B是每一轮的Mini-Batch的数目大小。算法的思路是：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;每一轮都随机选择出C那么多的客户端&lt;/li&gt;
  &lt;li&gt;对于每个客户端进行Mini-Batch的大小为B，轮数为E的SGD更新&lt;/li&gt;
  &lt;li&gt;对于参数直接进行加权平均（这里的权重是每个客户端的数据相对大小）&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;文章对这里的最后一步进行了说明。之前有其他研究表明，如何直接对参数空间进行加权平均，特别是Non-Convex的问题，会得到任意坏的结果。这篇文章里，作者们对于这样的问题的处理是，让每一轮各个客户端的起始参数值相同（也就是前一轮的全局参数值）。这一步使得算法效果大幅度提高。&lt;/p&gt;

&lt;p&gt;文章在一系列的数据集上做了大量的实验，基本上都是基于神经网络的模型，例如LSTM，CNN等。效果应该说是非常显著和惊人，绝大多数情况下，提出的算法能够在大幅度比较小的情况下，达到简单SGD很多轮才能达到的精读。&lt;/p&gt;

&lt;p&gt;虽然这篇文章提出的算法简单可行，并且也有不错的实验结果。但是比较令人遗憾的是，作者们并没有给出更多的分析，证明这样做的确可以让参数达到全局最优或者局部最优。
这篇文章对于大规模机器学习有兴趣的读者可以精读。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>AIStats 2017文章精读（四）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/06/17/aistats2017-fast-bayesian/"/>
   <updated>2017-06-17T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/06/17/aistats2017-fast-bayesian</id>
   <content type="html">&lt;p&gt;我们在这里对&lt;a href=&quot;http://www.aistats.org/&quot;&gt;AIStats 2017&lt;/a&gt;文章Fast Bayesian Optimization of Machine Learning Hyper-parameters on Large Datasets进行一个简单的分析解读。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v54/klein17a/klein17a.pdf&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v54/klein17a/klein17a-supp.pdf&quot;&gt;文章附加信息&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章的作者群是一队来自德国的学者，分别来自University of Freiburg和Max Planck Institute for Intelligent Systems。文章讨论了一个很实际的问题，那就是如何对一个机器学习算法进行自动调参数。文章针对这几年逐渐火热起来的Bayesian Optimization，开发了一个快速的、并且能够在大规模数据上运行的算法。&lt;/p&gt;

&lt;p&gt;传统的机器学习算法有很多所谓叫超参数（Hyper-parameter）需要设置。而这些超参数往往对最后的算法性能有至关重要的影响。在一般的情况下，如何寻找最佳的超参数组合则成为了很多专家的必要“技能”。而对于机器算法本身而言，取决于算法的复杂程度，有时候寻找一组合适的超参数意味着非常大的计算代价。&lt;/p&gt;

&lt;p&gt;这篇文章讨论了这么一个思路，那就是，既然在全局数据上对算法进行评估计算代价太大，可能对于直接调参过于困难，那能否在一个数据的子集上进行调参，然后把获得的结果看能否运用到更大一点的子集上，最终运用到全集上。&lt;/p&gt;

&lt;p&gt;这里，我们来回顾一下Bayesian Optimization的简单原理。首先，我们有一个“黑盒”的目标函数。我们的任务是找到这个目标函数最小值所对应的参数值（超参数）。这里，我们需要一个这个目标函数的先验分布，同时我们还需要一个所谓的Acquisition Function，用来衡量在某个点的参数值的Utility。有了这些设置，一个通常情况下的Bayesian Optimization的步骤是这样的：&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;用数值优化的方法在Acquisition Function的帮助下，找到下一个Promising的点。&lt;/li&gt;
  &lt;li&gt;带入这个Promising的点到黑盒函数中，得到当前的值，并且更新现在的数据集。&lt;/li&gt;
  &lt;li&gt;更新目标函数的先验分布以及Acquisition Function。&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;通常情况下，Bayesian Optimization的研究喜欢用Gaussian Processes（GP）来做目标函数的先验分布。这里就不复述具体的设置了。而对于Acquisition Function，这里有好几种可能性，比如文章举了Expected Improvement（EI）、Upper Confidence Bound（UCB）、Entropy Search（ES）等的例子。这篇文章使用了EI和ES。&lt;/p&gt;

&lt;p&gt;这篇文章提出的方法的思路的第一步，是把原来那个黑盒函数增加了一个参数，也就是除了原来的超参数以外，增加了一个数据集大小的参数。这个参数是按照比例（从0到1的一个值）来调整相对的数据集大小的。那么，如何应用这个参数呢？这里的技巧是，在GP里，需要有一个Kernel的设置。原本这个Kernel是定义在两组超参数之间的。那么，在这篇文章里，这个Kernel就定义在“超参数和数据集大小”这个Pair与另外一个Pair之间。于是，这里就能够通过已经经典的设置得到需要的效果。文章还提出了一个新的Acquisition Function用来平衡Information Gain和Cost。&lt;/p&gt;

&lt;p&gt;文章用SVM在MNIST做了实验，还用CNN在CIFAR-10以及SVHN上做了实验，以及还用ResNet在CIFAR-10上做了实验。总体上说，提出来的算法比之前的方法快10倍到100倍。并且，相比较的一些其他算法（比如一开始就在全集上进行计算的方法）都没法完成实验。&lt;/p&gt;

&lt;p&gt;这篇文章的基本思路和相关研究值得机器学习实践者学习。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>AIStats 2017文章精读（三）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/06/12/aistats2017-personal-model1/"/>
   <updated>2017-06-12T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/06/12/aistats2017-personal-model1</id>
   <content type="html">&lt;p&gt;我们在这里对&lt;a href=&quot;http://www.aistats.org/&quot;&gt;AIStats 2017&lt;/a&gt;文章Decentralized Collaborative Learning of Personalized Models over Networks进行一个简单的分析解读。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v54/vanhaesebrouck17a/vanhaesebrouck17a.pdf&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v54/vanhaesebrouck17a/vanhaesebrouck17a-supp.pdf&quot;&gt;文章附加信息&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章的作者们来自法国的INRIA和里尔大学（Universite de Lille）。文章讨论了一个非常实用也有广泛应用的问题，那就是所谓的Decentralized Collaborative Learning的问题，或者是说如何学习有效的个人模型（Personalized Models）的问题。&lt;/p&gt;

&lt;p&gt;在移动网络的情况下，不同的用户可能在移动设备（比如手机上）已经对一些内容进行了交互。那么，传统的方式，就是把这些用户产生的数据给集中到一个中心服务器，然后由中心服务器进行一个全局的优化。可以看出，在这样的情况下，有相当多的代价都放到了网络通信上。同时，还有一个问题，那就是全局的最优可能并不是每个用户的最优情况，所以还需要考虑用户的个别情况。&lt;/p&gt;

&lt;p&gt;比较快捷的方式是每个用户有一个自己的模型（Personalized Models），这个模型产生于用户自己的数据，并且能够很快地在这个局部的数据上进行优化。然而这样的问题则是可能没法利用全局更多的数据，从而能够为用户提供服务。特别是用户还并没有产生很多交互的时候，这时候可能更需要依赖于全局信息为用户提供服务。&lt;/p&gt;

&lt;p&gt;这篇文章提出了这么几个解决方案。首先，作者们构建了一个用户之间的图（Graph）。这个图的目的是来衡量各个用户节点之间的距离。注意，这里的距离不是物理距离，而是可以通过其他信息来定义的一个图。每个节点之间有一个权重（Weight），也是可以通过其他信息定义的。在这个图的基础上，作者们借用了传统的Label Propagation，这里其实是Model Propagation的方式，让这个图上相近节点的模型参数相似。在这个传统的Label Propagation方式下，这个优化算法是有一个Closed-Form的结论。&lt;/p&gt;

&lt;p&gt;当然，并不是所有的情况下，都能够直接去解这个Closed-Form的结论，于是这篇文章后面就提出了异步（Asynchronous）的算法来解这个问题。异步算法的核心其实还是一样的思路，不过就是需要从相近的节点去更新现在的模型。&lt;/p&gt;

&lt;p&gt;第三步，作者们探讨了一个更加复杂的情况，那就是个人模型本身并不是事先更新好，而是一边更新，一边和周围节点同步。作者这里采用了ADMM的思路来对这样目标进行优化。这里就不复述了。&lt;/p&gt;

&lt;p&gt;比较意外的是，文章本身并没有在大规模的数据上做实验而是人为得构造了一些实验数据（从非分布式的情况下）。所以实验的结果本身并没有过多的价值。&lt;/p&gt;

&lt;p&gt;不过这篇文章提出的Model Propagation的算法应该说是直观可行，很适合对大规模机器学习有兴趣的学者和实验者精读。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>AIStats 2017文章精读（二）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/06/11/aistats2017-less-sgd/"/>
   <updated>2017-06-11T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/06/11/aistats2017-less-sgd</id>
   <content type="html">&lt;p&gt;我们在这里对&lt;a href=&quot;http://www.aistats.org/&quot;&gt;AIStats 2017&lt;/a&gt;文章Less than a Single Pass: Stochastically Controlled Stochastic Gradient Method
进行一个简单的分析解读。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v54/lei17a/lei17a.pdf&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章的作者们来自加州大学伯克利分校。作者之一的Michael Jordan是机器学习的权威学者之一，曾经在概率图模型的时期有突出的贡献。&lt;/p&gt;

&lt;p&gt;这篇文章主要还是讨论的大规模Convex优化的场景。在这个方面，已经有了相当丰富的学术成果。那么，这篇文章的主要贡献在什么地方呢？这篇文章主要想在算法的准确性和算法的通讯成本上下文章。&lt;/p&gt;

&lt;p&gt;具体说来，这篇文章提出的算法是想在Stochastic Variance Reduced Gradient（SVRG）上进行更改。SVRG的主要特征就是利用全部数据的Gradient来对SGD的Variance进行控制。因此SVRG的计算成本（Computation Cost）是O((n+m)T)，这里n是数据的总数，m是Step-size，而T是论数。SVRG的通讯成本也是这么多。这里面的主要成本在于每一轮都需要对全局数据进行访问。&lt;/p&gt;

&lt;p&gt;作者们提出了一种叫Stochastically Controlled Stochastic Gradient（SCSG）的新算法。总的来说，就是对SVRG进行了两个改进：&lt;/p&gt;
&lt;ul&gt;
  &lt;li&gt;每一轮并不用全局的数据进行Gradient的计算，而是从一个全局的子集Batch中估计Gradient。子集的大小是B。&lt;/li&gt;
  &lt;li&gt;每一轮的SGD的更新数目也不是一个定值，而是一个和之前那个子集大小有关系，基于Geometric Distribution的随机数。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;剩下的更新步骤和SVRG一模一样。&lt;/p&gt;

&lt;p&gt;然而，这样的改变之后，新算法的计算成本成为了O((B+N)T)。也就是说，这是一个不依赖全局数据量大小的数值。而通过分析，作者们也比较了SCSG的通讯成本和一些原本就为了通讯成本而设计的算法，在很多情况下，SCSG的通讯成本更优。&lt;/p&gt;

&lt;p&gt;作者们通过MNIST数据集的实验发现，SCSG达到相同的准确度，需要比SVRG更少的轮数，和每一轮更少的数据。可以说，这个算法可能会成为SVRG的简单替代。&lt;/p&gt;

&lt;p&gt;对于大规模机器学习有兴趣的读者可以泛读。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>AIStats 2017文章精读（一）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/06/10/aistats2017-rank1-bandits/"/>
   <updated>2017-06-10T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/06/10/aistats2017-rank1-bandits</id>
   <content type="html">&lt;p&gt;我们在这里对&lt;a href=&quot;http://www.aistats.org/&quot;&gt;AIStats 2017&lt;/a&gt;文章Stochastic Rank-1 Bandits进行一个简单的分析解读。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v54/katariya17a/katariya17a.pdf&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://proceedings.mlr.press/v54/katariya17a/katariya17a-supp.pdf&quot;&gt;文章附加信息&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章的作者群来自于几个大学和Adobe Research。作者群中的Branislav Kveton和Zheng Wen在过去几年中发表过多篇关于Bandits的文章，值得关注。&lt;/p&gt;

&lt;p&gt;这篇文章解决的问题是一个在应用中经常遇到的问题，那就是每一步Agent是从一对Row和Column的Arms中选择，并且得到他们的外积（Outer Product）作为Reward。这个设置从搜索中的Position-based Model以及从广告的推广中都有应用。&lt;/p&gt;

&lt;p&gt;具体的设置是这样的，先假设我们有K行，L列。在每一个时间T步骤中有一个行（Row）向量u，从一个分布中抽取（Draw）出来，同时有一个列（Column）向量v，从另外一个分布中抽取出来。这两个抽取的动作是完全独立的。在这样的情况下， Agent在时间T，需要选择一个综合的Arm，也就是一个两维的坐标，i和j，从而在u和v的外积（Outer Product）这个矩阵中得到坐标为i和j的回报（Reward）。&lt;/p&gt;

&lt;p&gt;文章指出，这个设置可以被当做是有K乘以L那么多个Arm的简单的Multi-armed Bandit。那么当然可以用UCB1或者是LinUCB去解。然而文章中分析了这样做的不现实性，最主要的难点在K和L都比较大的情况下，把这个场景的算法当做原始的Multi-armed Bandit就会有过大的Regret。&lt;/p&gt;

&lt;p&gt;这篇文章提出了一个叫做Rank1Elim的算法来有效的解决这个问题。我们这里不提这个算法的细节。总体说来，这个算法的核心思想，就是减少行和列的数量，使得需要Explore的数量大大减少。这也就是算法中所谓Elimination的来历。那么，怎么来减少行列的数量呢？虽然作者们没有直接指出，不过这里采用和核心思想就是Clustering。也就是说，有相似回报（Reward）的行与列都归并在一起，并且只留下一个。这样，就能大大减少整个搜索空间。&lt;/p&gt;

&lt;p&gt;文章主要的篇幅用在了证明上，这里就不去复述了。文章在MovenLens的数据集上做了一组实验，并且显示了比UCB1的Regret有非常大的提高。&lt;/p&gt;

&lt;p&gt;这篇文章适合对推荐系统的Exploitation和Exploration有研究的学者泛读。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>WWW 2017文章精读（七）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/04/30/www2017-slice/"/>
   <updated>2017-04-30T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/04/30/www2017-slice</id>
   <content type="html">&lt;p&gt;我们在这里对WWW 2017文章Monetary Discount Strategies for Real-Time Promotion Campaign进行一个简单的分析解读。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://oak.cs.ucla.edu/~chucheng/publication/www17.pdf&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章的来自于一批来自台湾国立成功大学的学者和一个叫Slice Technologies的公司。这篇文章要解决的是一个非常实际的在E-Commerce会遇到的问题，那就是如何进行实时的促销（Promotion Campaign）使得可以吸引用户而同时也可以达到利润最大化的目的。&lt;/p&gt;

&lt;p&gt;作者们在这篇文章提出了一个叫做Real-Time Promotion（RTP）的概念，类比于广告里面经常提到的Real-Time Bidding。同时，这个RTP是一个针对某一个特定用户的一次性Deal。也就是说，这里面有了个性化的成分，使得能够对用户有一定的吸引力。然而，这个问题的难点是，如果能够做到在做RTP的同时，不影响到或者尽可能小的影响到用户对于品牌的一个认知，不至于让用户有负面的感觉。&lt;/p&gt;

&lt;p&gt;这篇文章的数据来源于这个叫Slice的公司。具体说来，Slice就是对百万用户的Receipts进行分析，从而对用户进行建模。这里面有一个基本的假设就是，如果一个用户已经以一定的价格（Price）购买了某种商品，那么，比这个价格低的价格，用户也一般愿意接受。而相反，用户可能不会接受比当前这个价格更高的价格。&lt;/p&gt;

&lt;p&gt;首先，作者们定义了这个所谓Discount-Giving Strategy的问题。那就是在给定的Discount预算（Budget）的情况下，如何最大化利润。文章指出，这个问题很类似传统的背包问题（Knapsack）。当然，与背包问题的最大不同的就是在于，这个问题中的很多参数是未知的，比如顾客是否愿意购买，再比如当前的折扣价格。&lt;/p&gt;

&lt;p&gt;在假设知道当前客户购买一个商品的价格分布的情况下，我们是可以得到最大化利润的一个表达的。然而遗憾的是，我们并不知道这个价格分布。于是在这篇文章里，作者们就提出了使用Kernel Density Estimation（KDE）来对价格分布进行估计。而得知了这个分布以后，我们就能够对每一个商品的所谓Cut-off Price进行一个准确的估计。这里的细节建议大家看文章。有了这些组成部分以后，作者们在这篇文章中提出了一个基于Thompson Sampling的办法，这样做的好处是可以对实时变化的数据进行很好的估计，同时也可以让整个优化过程更加Robust。&lt;/p&gt;

&lt;p&gt;实验就是在Slice过去手机的Receipts来进行的Simulation。应该说，实验的结果还是证明了动态的实时优化对于曾家利润是有帮助的。&lt;/p&gt;

&lt;p&gt;这篇文章的具体技术比较繁复，很难看出能够直接在这个基础上再扩展算法。然而这篇文章提出的问题的确比较新颖，也是电商或者网络运营商（比如Uber、DiDi）等经常遇到的问题，所以，值得对相关技术有兴趣的读者泛读。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>WWW 2017文章精读（六）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/04/28/www2017-personal-search/"/>
   <updated>2017-04-28T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/04/28/www2017-personal-search</id>
   <content type="html">&lt;p&gt;我们在这里对WWW 2017文章Situational Context for Ranking in Personal Search进行一个简单的分析解读。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://ciir-publications.cs.umass.edu/pub/web/getpdf.php?id=1268&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章的作者群来自于University of Massachusetts Amherst（UMASS）以及Google。UMASS因为W. Bruce Croft（Information Retrieval领域的学术权威）的原因 ，一直以来是培养IR学者的重要学校。文章做这种的Michael Bendersky以及Xuanhua Wang都是Bruce Croft过去的学生。这篇文章想要讨论的是如何在个人搜索（Personal Search）这个领域根据用户的场景和情况（Situational Context）来训练有效的排序模型（Ranking Model）。&lt;/p&gt;

&lt;p&gt;这篇文章的核心思想其实非常直观：&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;场景信息对于个人搜索来说很重要，比如时间，地点，Device，因此试图采用这些信息到排序算法中，是非常显而易见的。&lt;/li&gt;
  &lt;li&gt;作者们尝试采用Deep Neural Networks来学习Query以及Document之间的Matching。&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;具体说来，作者们提出了两个排序模型来解决这两个设计问题。第一个模型应该说是第二个模型的简化版。&lt;/p&gt;

&lt;p&gt;第一个模型是把Query，Context，以及Document当做不同的模块元素，首先对于每一个模块分别学习一个Embedding向量。与之前的一些工作不同的是，这个Embedding不是事先学习好的（Pre-Trained）而是通过数据End-to-End学习出来的。有了各个模块的Embedding向量，作者们做了这么一个特殊的处理，那就是对于不同的Context（比如，时间、地点）学习到的Embedding，在最后进入Matching之前，不同Context的Embedding又组合成为一个统一的Context Embedding（这里的目的是学习到例如对时间、地点这组信息的统一规律），然后这个最终的Context Embedding和Query的，以及Document的Embedding，这三个模块进行Matching产生Relevance Score。&lt;/p&gt;

&lt;p&gt;那么，第二个模型是建立在第一个模型的基础上的。思路就是把最近的一个所谓叫Wide and Deep Neural Networks（Wide and Deep）的工作给延展到了这里。Wide and Deep的具体思想很简单。那就是说，一些Google的研究人员发现，单靠简单的DNN并不能很好的学习到过去的一些非常具体的经验。原因当然是DNN的主要优势和目的就是学习数据的抽象表达，而因为中间的Hidden Layer的原因，对于具体的一些Feature也好无法“记忆”。而在有一些应用中，能够完整记忆一些具体的Feature是非常有必要的。于是Wide and Deep其实就是把一个Logistic Regression和DNN硬拼凑在一起，用Logistic Regression的部分达到记忆具体数据，而用DNN的部分来进行抽象学习。这第二个模型也就采用了这个思路。在第一个模型之上，第二个模型直接把不同Context信息又和已经学到的各种Embedding放在一起，成为了最后产生Relevance Score的一部分。这样的话，在一些场景下出现的结果，就被这个线性模型部分给记忆住了。&lt;/p&gt;

&lt;p&gt;在实验的部分来说，文章当然是采用了Google的个人搜索实验数据，因此数据部分是没有公开的。从实验效果上来说，文章主要是比较了单纯的用CTR作为Feature，进行记忆的简单模型。总体说来，这篇文章提出的模型都能够对Baseline提出不小的提升，特别是第二个模型仍然能够对第一个模型有一个小部分但具有意义的提升。&lt;/p&gt;

&lt;p&gt;这篇文章对于研究如何用深度学习来做文档查询或者搜索的研究者和实践者而言，有不小的借鉴意义，值得精读。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>WWW 2017文章精读（五）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/04/27/www2017-stream/"/>
   <updated>2017-04-27T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/04/27/www2017-stream</id>
   <content type="html">&lt;p&gt;我们在这里对WWW 2017文章Streaming Recommender Systems进行一个简单的分析解读。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://www.yichang-cs.com/yahoo/WWW17_StreamingRec.pdf&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章的作者群来自雅虎研究院和University of Illinois at Urbana-Champaign。第一作者&lt;a href=&quot;http://www.ifp.illinois.edu/~chang87&quot;&gt;Shiyu Chang&lt;/a&gt;，是今年来一位学术新星，目前在IBM华生研究院工作。这篇文章的核心思想是想提出一个完全基于流（Stream）信息的推荐系统框架。&lt;/p&gt;

&lt;p&gt;作者们认为，流信息和普通的静态数据有很大的区别：&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;大量的数据流入系统，系统必须对这些数据进行实时的反应。比如用户和某一个物品进行了交互；比如有新的物品产生需要被系统识别到并且能够查询等等。&lt;/li&gt;
  &lt;li&gt;流入系统的数据的量是未知的。这部分信息无法在产生系统之前拿到。&lt;/li&gt;
  &lt;li&gt;随着时间的推移，数据会产生所谓的“概念漂移”（Concept Shift）的现象。用户的喜好也会随着时间的推移而发生变化。&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;于是，这篇文章就是希望从根本上来解决这些问题，提出一个基于信息流的推荐系统框架。&lt;/p&gt;

&lt;p&gt;文章提出的模型是一个具有时间信息的概率图模型（Probabilistic Graphical Model）。核心思想就是所有的元素都有时间的概念。举例来说，用户对于某一个物品的喜爱也仅仅是一个时间点的信息，并不代表之后的时间点的信息。这一点来说，就给了用户喜好发生变化的可能性。模型的核心还是基于用户向量（User Vector）和物品向量（Item Vector）的点积。不过，这里的用户向量和物品向量都是某一个时间点的估计。这些向量都随着时间发生变化。具体说来，作者们定义了一个基于布朗随机运动（Brownian Motion）的变化过程来对用户向量随着时间变化的改变来建模。也就是说，下一个时间点的用户向量是一个基于上一个时间点的用户向量的高斯分布。同样的建模手段也用到了物品向量上。整个模型可以说还是比较直观的，从概念上来说，提出的这个框架其实非常类似用卡曼滤波（Kalman Filtering）来进行时间维度的建模。而用卡曼滤波建模也是过去在概率图模型里经常使用的技巧。&lt;/p&gt;

&lt;p&gt;这个模型的难点是做模型的在线预测（Online Prediction）和离线模型参数估计（Offline Parameter Estimation）。对于在线预测的部分，作者们提出了一个叫Recursive Mean-field Approximation的技术。对于离线模型参数估计来说，作者们使用了标准的EM算法。总体来说，整个学习流程其实是比较复杂的。这也和其他使用类似卡曼滤波的方法类似。这也是概率图模型对时间信息处理的通病。&lt;/p&gt;

&lt;p&gt;文章实验的部分还是非常详尽的。文章在MovieLens的比较小的以及比较大的数据集上都做了实验，并且还加上了经典的Netflix的数据集。从Baseline的比较上来说，文章比较了传统的Probabilistic Matrix Factorization，经典的Time-SVD++算法（赢得Netflix大赛的算法）以及比较先进的Gaussian Process Factorization Machines。从实验的效果上来看，文章提出的方法在三个数据集上都有不错的效果。&lt;/p&gt;

&lt;p&gt;这篇文章提出的方法因为其算法复杂性，很难应用在生产中。而且要想在这个模型上做进一步的扩展，只能使得算法的复杂性进一步提升。这篇文章适合对于推荐系统有研究的学者和实践者泛读。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>WWW 2017文章精读（四）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/04/26/www2017-ec/"/>
   <updated>2017-04-26T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/04/26/www2017-ec</id>
   <content type="html">&lt;p&gt;我们在这里对WWW 2017文章Modeling Consumer Preferences and Price Sensitivities from Large-Scale Grocery Shopping Transaction Logs进行一个简单的分析解读。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;https://cseweb.ucsd.edu/~m5wan/paper/www17_mwan.pdf&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章的作者群来自加州大学圣地亚哥分校（University of California at San Diego）和微软研究院。最后一个作者Julian McAuley在加州大学圣地亚哥分校长期从事推荐系统以及用户模型的研究工作。建议对推荐系统有研究的朋友经常看看他又有什么新的研究成果这篇文章的特色在于希望把推荐系统的用户喜好建模和经济学里的对于价格的研究结合起来。作者们认为，在推荐系统领域，对于用户喜好建模已经是比较成熟的研究领域了，而对于价格，特别是价格的敏感度（Sensitivity）的研究还并不是很多。于是这篇文章就是要弥补这么一个研究缺失（Gap）。&lt;/p&gt;

&lt;p&gt;作者们首先提出了一个分三阶段（Three Stage）的概率模型，用来刻画用户选择购买商品时候的选择过程。具体来说，这篇文章把用户的行为分为了这么三个阶段：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;类别选择（Category Purchase），也就是说，用户首先选择要购买哪个类别的商品。&lt;/li&gt;
  &lt;li&gt;产品选择（Product Choice），这里面就是在已经选定了一个类别以后，用户如何在这个类别里面选择商品。&lt;/li&gt;
  &lt;li&gt;数量购买（Purchase Quantity），选择要购买多少商品。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;有了这三个阶段以后，用户的购买需求就成为了这三种概率的联合分布。&lt;/p&gt;

&lt;p&gt;为了对这三种行为有效建模，作者们首先提出了一个所谓的Feature-Based Matrix Factorization（FMF）的框架。总的说来，这是之前的LinkedIn提出的所谓的Generalized Linear Mixed Model（GLMix）变种。读者可以仔细参考原论文看看FMF的细节。这个FMF结合了全局特征（Global Features），物品特征，用户特征，以及用户和物品的隐含特征（Latent Features）。可以说是一个比较完善的框架体系。&lt;/p&gt;

&lt;p&gt;有了FMF这个工具，我们再回到刚才的三个阶段的建模。作者们的思路就是用FMF的不同表达形式为三个阶段进行分别的建模。具体说来，类别选择的部分，采用了FMF的Logistic表达形式，也就是对每个类别进行简单的“是”还是“不是”的购买选择。产品选择的部分则采用了Multinomial Regression的形式，也就是在所有同类商品里面进行选择。第三部分数量购买则采用了Poisson Regression的形式。然而核心这三部分采用的是同样的一套思路。因为这三个部分的独立性，使得模型的学习可以把这三部分分来，有利于能够并行化。在整体的模型学习上，作者们还加上了AUC Optimization的“作料”。&lt;/p&gt;

&lt;p&gt;接下来，作者们介绍了这篇文章的一个重点，那就是把价格因素引入到了整体框架中。其实思路还是很简单，就是直接把价格（在模型中用了Log Transformation）当做一个Feature，进行参数学习。这样做的好处还有直接可以计算所谓的价格敏感度，也就是购买一个东西的可能性的变化和价格变化的比值。这个数量可以用来描述价格的变化敏感度，可以让我们对价格做进一步的分析。&lt;/p&gt;

&lt;p&gt;作者们在一个非公开的西雅图的商店数据集上，和公开的Dunnhumby数据集上做了实验。实验结果是三个阶段的模型都有不错的表现。并且作者们还利用价格敏感度进行了数据的进一步分析。这里就不复述了。&lt;/p&gt;

&lt;p&gt;这篇文章值得对推荐系统有研究的学者和实践者精读。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>WWW 2017文章精读（三）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/04/19/www2017-cloud/"/>
   <updated>2017-04-19T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/04/19/www2017-cloud</id>
   <content type="html">&lt;p&gt;我们在这里对WWW 2017文章Usage Patterns and the Economics of the Public Cloud进行一个简单的分析解读。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://vita.mcafee.cc/PDF/EconPublicCloud.pdf&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章的作者群来自微软研究院和Uber。作者之一的R. Preston McAfee是著名的经济学家，曾在雅虎担任副总裁和首席经济学家，2012年以后到Google的Strategic Technology担任总监，2014年之后到微软担任首席经济学家。这篇文章是探讨现在第三方云计算平台（比如Amazon的AWS或是微软的Azure）是否能采用动态价格（Dynamic Pricing）的计价模式，特别是在所谓的“巅峰负载”（Peak-Load）的时候。&lt;/p&gt;

&lt;p&gt;首先，这篇文章对“云服务”模式进行了一个简单的介绍。这部分内容还是有很强的科普意义。这里面有一点可能比较容易忽视的科普点是，客户公司（Firm）需要对服务和软件进行重写才能使用云服务商提供的Auto-Scaling等方便的服务。如果客户公司仅仅是简单得把运行在传统数据中心上的服务给部署到云服务商的设施上面的话，则很难能够真正利用云服务的“易伸缩性”（Elastic）。&lt;/p&gt;

&lt;p&gt;紧接着，作者们对于其他工业怎么采用动态价格进行了简单的介绍。动态价格有两个条件，那就是Capacity在短期内是恒定的（Fixed）并且恒定的一部分陈本（Cost）是总成本不小的一部分。当然这都是对于服务商而言。目前我们对于动态价格的主要认识，来源于电力、航空和酒店这些行业。云服务如果按照刚才那个条件来说，是具备动态价格的一些先决条件的。因此，作者们认为应该对云服务的供需进行研究来看如何设计动态价格的策略，也就是说，作者们想看一看现在的云服务的使用率是不是不够优化，为动态服务提供了可操作的空间。&lt;/p&gt;

&lt;p&gt;这篇文章能够被WWW录取的一个重要原因可能是因为结果比较出人意料。作者们通过对微软的云服务数据（虽然在文中没有明说）进行分析得出，当前的云服务使用率（主要是从VM这个角度来说）的差别度（Variation） ，不管是看单个客户还是整体数据中心这个级别，都在5%以下。意思就是说，从云服务商这个整体来说，并没有出现特别大的服务需求起落。作者们的确从单个客户的数据中看到了使用率的震荡（Fluctuation），但是在云服务商这个层级，这样的震荡随着不同的客户数据，从而达到了整体“抵消”（Average Out）的效果。&lt;/p&gt;

&lt;p&gt;作者们认为这样的现实数据为现在的计费模型，也就是恒定的价格（Static Price）提供了一定的基础。同时，目前的可以预测的使用率也为服务商充分利用资源提供了保证。这一点与电力系统不同，电力系统为在巅峰时刻的用电一般必须调用额外的设备。当然，作者们也认为这样的使用数据，以及计费模型，是现在多数客户都简单把原来的软件系统给搬运到云计算平台上，而并没有充分利用云服务的Auto-Scaling有关系。&lt;/p&gt;

&lt;p&gt;为了对以后的可能性进行探索，作者们又从CPU的使用率这个级别进行分析。与VM的使用率不同的是，CPU的使用率看出了比较大的幅度。平均的最高CPU使用率比巅峰时期CPU使用率要小40%左右。因此，如果服务商能够通过CPU使用率来进行计价，或者VM资源能够在不使用的时候自动关闭，则为动态价格提供了一种可能性。作者们的与测试，这可能是未来的一种模式。&lt;/p&gt;

&lt;p&gt;总体来说，这篇文章算是科普性质的一篇文章。对于动态价格，以及云服务商的计价模式有兴趣的读者可以泛读本文。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>WWW 2017文章精读（二）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/04/16/www2017-cml/"/>
   <updated>2017-04-16T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/04/16/www2017-cml</id>
   <content type="html">&lt;p&gt;我们在这里对WWW 2017文章Collaborative Metric Learning进行一个简单的分析解读。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://www.cs.cornell.edu/~ylongqi/paper/HsiehYCLBE17.pdf&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://www.cs.cornell.edu/~ylongqi/publication/www17b/&quot;&gt;论文的项目页面&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章的作者群来自于加州大学洛杉矶分校（University of California at Los Angeles）以及康奈尔科技大学（Cornell Tech）。 文章的核心思想是如何把Metric Learning和Collaborative Filtering（CF）结合起来从而达到更好的推荐效果。&lt;/p&gt;

&lt;p&gt;那么这篇文章为什么会想到把Metric Learning结合到CF上面呢？文章做了比较详细的交代。这里面的重点来自于传统的基于Matrix Factorization的CF模型都使用了Dot-Product来衡量用户向量（User Vector）和物品向量（Item Vector）的距离。也就是说，如果Dot-Product的值大， 就代表两个向量相近，值小就代表距离远。对于Dot-Product的默认使用已经让广大研究人员和实践者都没有怎么去质疑过其合理性。文章这里指出，Dot-Product并不是一个合理的距离测度，因此可能会带来对于相似度的学习不准确的问题。&lt;/p&gt;

&lt;p&gt;这里简单说一下什么是一个合理的距离测度。一个距离测度需要满足一些条件，而其中比较普遍的条件是所谓的“三角不等式”。所谓的“三角不等式”关系其实也就是说，距离的大小是有传递性的。举例来说，就是如果X与Y和Z都相近，那么Y和Z也应该相近。也就是说，相似度是可以传播的，在使用一个合理的距离测度的情况下。然而，文章指出Dot-Product并不具备这样的相似传递性，因此在实践中常常会不能有效得学习到数据中全部的信息。&lt;/p&gt;

&lt;p&gt;Metric Learning就是如何在一定的假设下，进行有效距离测度学习的工具。文章使用了一种Relaxed Version的Metric Learning，叫做Large-Margin Nearest Neighbor（LMNN）来学习数据之间的相似度。LMNN简单说来，就是同一个类型的数据应该更加紧密聚集在一起（通过Euclidean Distance），而不同类的数据应该远离。同时，同类的数据和不同类的数据之间保持一个Margin（模型的一个参数）的安全距离。&lt;/p&gt;

&lt;p&gt;作者们把这个概念拿过来，应用在CF的场景下，做了进一步的简化，那就是把“相同类数据聚合”这个部分去掉了，仅仅留下了“不同类远离”这个部分。作者们认为，一个物品可能被多个人喜欢，那么在这样的含义下，很难说清楚，到底怎么聚类比较有意义。具体说来，一个用户所喜欢的物品要远离这个用户所不喜欢的物品，同时这个距离会被一个与Rank（这里所说的Rank是指物品的排序）有关Weight所控制。也就是Rank越大，所产生的Penalty就越大。文章具体采用了一个叫Weighted Approximate Rank Pairwise Loss（WARP）的Loss来对Rank进行Penalty。这个WARP是早几年的时候还在Google的Weston等人提出的，目的是要对排在Rank比较大的正样本（Positive Instance）做比较大的Penalty。这里就不复述WARP的细节了。&lt;/p&gt;

&lt;p&gt;除了外加WARP的Metric learning，这篇文章还为整个模型的目标函数加了不少“作料”。“作料一”就是使用了Deep Learning来学习从物品的Feature到物品的Latent Vector的映射。这解决了Cold-start的问题。“作料二”则是对物品和用户的Latent Vector都做了正则化，使得学习起来更加Robust。&lt;/p&gt;

&lt;p&gt;文章简单描述了一下整个模型的训练过程。整个模型的目标函数由三个部分组成：Metric Learning的部分，加Deep Learning的部分，外加正则化的部分。比较意外的是，文章并没有提及模型在训练好以后如何在Test数据上进行Inference。&lt;/p&gt;

&lt;p&gt;文章在一系列标准数据集上做了测试，对比的Baseline也比较完整。总体说来，提出的模型都能达到最好的效果，有些在目前比较好的模型基础上能够提高10%以上，这比较令人吃惊。比较遗憾的是，文章并没有很好的展示这个模型的三个模块究竟是不是都必须。值得一提的是，文章指出使用了WARP的任何模型（包括本文章提出的模型）都要好于其他的模型。&lt;/p&gt;

&lt;p&gt;这篇文章总的来说还是可以参考。虽然有一些细节很值得推敲，但是，提出把Metric Learning引入到CF里来说，还是有一定价值的。&lt;/p&gt;

&lt;p&gt;建议对推荐系统正在研究的学者精读，对推荐系统有兴趣的实践者泛读。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>WWW 2017文章精读（一）</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/04/13/www2017-beyond-globally-optimal/"/>
   <updated>2017-04-13T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E8%AE%BA%E6%96%87/2017/04/13/www2017-beyond-globally-optimal</id>
   <content type="html">&lt;p&gt;我们在这里对WWW 2017文章Beyond Globally Optimal: Focused Learning for Improved Recommendations进行一个简单的分析解读。&lt;/p&gt;

&lt;p&gt;&lt;a href=&quot;http://alexbeutel.com/papers/www2017_focused_learning.pdf&quot;&gt;全文PDF&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;这篇文章来自一群前CMU的学者，目前在Google和Pinterest。那么这篇文章试图解决什么问题呢？具体说来，就是作者们发现，传统的推荐系统，基于优化一个全局的目标函数，通常情况下往往只能给出一个非常有“偏差”（Skewed）的预测分布。也就是说，传统的推荐系统追求的是平均表现情况，在很多情况下的预测其实是十分不准确的。这个情况在评价指标是Root Mean Squared Error（RMSE）的时候，就显得尤为明显。&lt;/p&gt;

&lt;p&gt;这篇文章的作者是这么定义了一个叫做Focused Learning的问题，那就是如果让模型在一个局部的数据上能够表现出色。那么，为什么需要模型在一个局部的数据上表现出色呢？作者们做了这么一件事情，那就是对每个用户，以及每一个物品的预测误差（Error）进行了分析统计，发现有不小比例的用户的预测误差比较大，也有不小比例的物品的预测误差比较大。作者们发现模型在一些数据上存在着系统性的误差较大的问题，而不是偶然发生的情况。&lt;/p&gt;

&lt;p&gt;作者们又从理论上进行了对这个问题一番讨论。这里的讨论十分巧妙，大概的思路就是，假定现在在全局最优的情况下，模型的参数的梯度已经为0了，但模型的Loss依然不为0（这种情况很常见）。那么，就一定存在部分数据的参数梯度不为0，因为某一部分数据的Loss不为0。这也就证明了部分数据的模型参数在这些数据上的表现一定不是最优的。值得注意的是，这个证明非常普遍，和具体的模型是什么类型没有关系。&lt;/p&gt;

&lt;p&gt;在有了这么一番讨论之后，那么作者们如何解决这个问题呢？这篇文章走了Hyper-parameter Optimization的道路。文章展示了这在普通的Matrix Factorization里面是如何做到。具体说来，就是对于某个Focused Set做Hyper-parameter的调优，使得当前的Hyper-parameter能够在Focused Set上能够有最好表现。而这组参数自然是针对不同的Focused Set有不同的选择。文章提到的另外一个思路，则是对Focused Set以及非Focused Set的Hyper-parameter进行区分对待，这样有助于最后的模型能够有一个比较Flexible的表达。&lt;/p&gt;

&lt;p&gt;文章在实验的部分针对几种不同的Focused Set进行了比较实验。比如，针对Cold-Start的物品，针对Outlier的物品，以及更加复杂的libFM模型都进行了实验。我们在这里就不去复述了。总体来说，Focused Learning在不同的数据集上都得到了比较好的提升效果。同时，作者们还针对为什么Focused Learning能够Work进行了一番探讨，总体看来，Focused Learning既照顾了Global的信息，同时又通过附加的Hyper-parameter调优对某一个局部的数据进行优化，所以往往好于Global的模型以及也好于单独的Local模型。&lt;/p&gt;

&lt;p&gt;本文非常适合对推荐系统有兴趣的学者和工程人员精读。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>论互联网公司与研究院</title>
   <link href="http://column.hongliangjie.com/%E7%AE%A1%E7%90%86/2017/04/09/research-labs/"/>
   <updated>2017-04-09T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E7%AE%A1%E7%90%86/2017/04/09/research-labs</id>
   <content type="html">&lt;p&gt;随着吴恩达离开百度研究院，关于互联网公司设立研究院的话题又被推到了风口浪尖。一时间，大家对互联网公司到底该不该设立研究院、研究院在公司内部又该起到怎样的作用、怎么能够设置一个有效的研究院架构、怎么来衡量研究院是否成功等问题展开了激烈的讨论。我打算在这篇专栏文章里，以本人在雅虎研究院的经历为基础，来剖析一下现代高科技企业尤其是互联网公司如何设置一个成功的研究院，研究院究竟该如何运作。这篇文章是在公开领域少有的论述研究院的系统性文章，值得大家精读。&lt;/p&gt;

&lt;h2 id=&quot;什么是研究院&quot;&gt;什么是研究院&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/andrew_ng.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;在我们讨论其他话题之前，我们首先来看看目前互联网公司的各种研究院有什么特征。怎样的团队就算是一个“研究院类型”的团队（因为有一些公司并不直接单独称这些团队为“研究院”）。我们这里总结下面这么一些特征:&lt;/p&gt;

&lt;h3 id=&quot;特征一以博士为核心组成的团队&quot;&gt;特征一：以博士为核心组成的团队&lt;/h3&gt;
&lt;p&gt;大多数研究院的核心人员，甚至是全部研发人员都具有博士或以上（含博士后、有教职经验）研究经历。这个特征是因为很多研究院需要解决的问题或者研究的方向是产业的前沿，的确需要有掌握高级知识的人才进行研发工作。然而这个特征也直接导致了很多其他问题，那就是一个以博士为核心组成的团队和其他团队来比较，有一些其他团队所不具备的特点，为管理工作带来了额外的挑战。比如，很多博士习惯做长期项目（三个月以上甚至更长）。这些研发人员很不习惯更换项目，而且博士对于项目就像是研究课题，有个人的归属感和荣誉观，这是好事也是坏事。再比如，博士希望有比较长期的职业规划，对于自己的研究方向希望能够有所延续，能够参加学术会议，能够发表论文。这些需求都是其他一般的研发团队一般不具有的。如果一个研究院的管理层不能正视这些需求，则很难形成一个有很强创新力和执行力的团队。&lt;/p&gt;

&lt;h3 id=&quot;特征二相对比较独立的运作环境&quot;&gt;特征二：相对比较独立的运作环境&lt;/h3&gt;
&lt;p&gt;尽管我们后面要提到，很多研究院都和产品部门有或多或少的联系，有时候甚至和产品部门有密切的合作，但绝大多数研究院，都需要有一个相对比较独立的运作环境。比如，研究院是一个独立的团队，有自己部门的领导（而不是工程部门的兼任），有自己部门的单独预算，有自己部门的Key Performance Indicator（KPI)，有自己部门的组织结构和运作模式等等。这些都是建立一个研究院独立的形象。而且，也由于我们刚才提到的第一个特征，也就是研究院以博士为核心的特点，一个相对独立的运作环境有助于管理这一个可能和公司其他部门组成结构非常不一样的人群（因为这个人群的需求可能很不一样）。&lt;/p&gt;

&lt;h3 id=&quot;特征三研究院不是产品部门&quot;&gt;特征三：研究院不是产品部门&lt;/h3&gt;
&lt;p&gt;绝大多数研究院作为一个独立的运行实体都不直接掌管（Ownership）产品线。研究院可以作为产品部门的协作单位，但大多数成熟的研究院均不直接运作产品线。一个简单的原因是，产品线的研发和运作与研究院的目标是不完全一致的。那么这一点特征，可能会带来研究院在管理和定位上出现问题。我们下面会提到研究院的目标中就要来分析一下，在不掌管产品线的情况下，研究院如何能够保持其在公司内的影响力。&lt;/p&gt;

&lt;p&gt;上面三个特征只是研究院诸多特征中的代表。然而我们已经可以看出，研究院在现代互联网公司中的一个比较特殊的地位：人员构成、运作模式、需要为产品做贡献但又不是产品部门。正是因为有这些特点，成功运行一个研究院对于现代高科技企业来说，是一个巨大的管理挑战。&lt;/p&gt;

&lt;h2 id=&quot;研究院的目标&quot;&gt;研究院的目标&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/moonshot.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;什么样的公司需要研究院呢？要回答这个问题，我们必须要来看，什么样的产品需要研究院的支持。有两类产品很适合搭配研究院：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;比较成熟的产品&lt;/li&gt;
  &lt;li&gt;和公司现在产品线没有太大关系的前沿产品，有时候也叫“打月亮”（Moonshot）产品。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;我们先来说说为什么“比较成熟的产品”适合搭配研究院。成熟的产品，已经有了比较成熟的数据链条（Data Pipeline)，能够使得基于数据（Data-Driven)的研究工作有了可能性。而目前几乎所有的前沿研究，包括机器学习（Machine Learning)、人工智能（Artificial Intelligence）、数据科学（Data Science）等都无一例外非常强烈依赖于大量的数据。没有数据，绝大多数这类研究都没法进行。早期的产品并不具备这样的条件。比如，产品部门需要推出一款新的手机应用（App），而如何这个应用有比较多的功能之前并没有在公司其他产品中存在过，那么研究部门很难进行基于数据的研究工作。成熟的产品，也有相对比较成熟的衡量指标（Metrics）。这一点对于数据驱动的研究来说额外重要。因为有了衡量指标，就能够围绕这个指标展开特定的研究工作，设计相应的模型和算法，提出合理的优化解决方案。比如，当前的产品是搜索引擎，那么研究院就可以针对搜索引擎的成功衡量指标进行建模，更新搜索排序算法等等。早期的产品一般也没有固定、和合理的衡量指标，这会让大多数的研究工作一筹莫展。当然，研究院可以帮助产品部门建立衡量指标。不过这也是一个需要一定时间的过程。在这个过程结束前，其他的研究工作很难进行。&lt;/p&gt;

&lt;p&gt;我们再来说说为什么和现有产品线没有太大关系的前沿产品也是比较适合搭配研究院的原因。我们刚才提到研究院的特点的时候说到，绝大多数研究院都是相对比较独立运行的团队或者机构。这个特点就非常利于研发前沿产品。前沿产品因为其高失败率的特点并不适合普通的已经有成熟产品运维压力的产品部门进行研发。同时，前沿产品的“前沿”特点也使得研究院成为这种类型产品研发当仍不让的选择。另外，前沿产品一般并没有一个特定的产品公布时间表。这和前面所说的“非成熟”或者早期产品不一样。早期产品，尽管没有数据，没有成功指标，但往往有惊人的产品公布时间表，产品上线压力很大。而前沿产品，虽然也没有数据，也没有成功指标，但一般没有上线压力。这也就给了研究院自由空间去收集数据（比如Google的无人驾驶车），定义成功指标，进行迭代。当然，从这个角度来看，这也直接导致了，前沿产品的研发周期非常长，而且也很难去定义其上线的时间，于是成为其失败率高的部分原因。&lt;/p&gt;

&lt;p&gt;在我们了解了什么样的产品比较容易搭配研究院以后，我们再回到最开始的那个问题，“什么样的公司需要研究院”。如果一个公司的产品线相对还不稳定，很多产品处于快速迭代的状态下，这个时候，这样的公司其实并不太适合建立研究院。因为绝大多数产品线都没法真正“享受”到研究院的成果。如果一个公司并没有足够稳定的内部环境和财务基础，那么这个公司也就没有研发前沿产品的基础。那自然这样的情况下，配置一个以研发前沿产品为导向的研究院就更加显得没有必要。基于这样两个原因，绝对多数的初创公司，或者其实说，在上市前的初创公司都并不真正具备配置研究院的内外部环境。只有相对比较稳定的公司才有对研究院真正的需求。&lt;/p&gt;

&lt;p&gt;值得注意的是，我们也可以从这里关于研究院和产品线的讨论引申得到这么一个结论。因为研究院最大的功效是在对成熟产品的优化和改进上，以及对前沿产品的研发上，要想依赖研究院对一个公司的商业模式进行创新，或者寄希望研究院对快速迭代的产品产生贡献使得公司进入高速增长期都是不可能完成的任务。这些不切合实际的初衷往往给研究院的定位和发展带来困境。从另一个角度来说，那就是研究院可能对公司的长期商业运行可能会有比较大的影响（比如一些前沿产品如何研发成功），但在中短期来看，影响是相对比较有限的、是渐进式（Incremental）的（主要来自于对成熟产品的优化）。&lt;/p&gt;

&lt;h2 id=&quot;研究院的架构和运行&quot;&gt;研究院的架构和运行&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/research_lab.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;在我们了解了什么样的产品需要研究院，什么样的公司需要配备研究院以后，我们现在就来探讨一下研究院的架构问题。&lt;/p&gt;

&lt;p&gt;我们上面提到了研究院在公司内部需要有一定的独立性。但是，现代高科技公司，毕竟从根本上来说还是追逐利润的企业，如何来确保研究院能够从长期上是符合公司发展的利益呢？这一点，是研究院生存的根本。&lt;/p&gt;

&lt;p&gt;从历史上来说，早期研究院很多都是这么一种运作模式：&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;研究院的科学家针对某个技术难题（这个技术难题有可能是来自产品工程部门，也有可能是研究院的科学家自己发现）找到了一种解决方案， 形成一个研究成果。&lt;/li&gt;
  &lt;li&gt;根据不同的研究院的情况，科学家可能会选择发表研究成果，形成论文，或者是申请形成专利。&lt;/li&gt;
  &lt;li&gt;科学家根据这个研究成果做出一个解决方案的原型（Prototype）。&lt;/li&gt;
  &lt;li&gt;研究院团队根据解决方案的原型，到产品工程部门进行游说。产品工程部门根据自身的需求和产品周期，决定是否要把目前的原型重新在工程中实现，从而在下一代产品中使用上这个新成果。&lt;/li&gt;
  &lt;li&gt;产品工程团队和科学家一起把原型在工程代码中重新实现。&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;这个模式看似有一定道理，但也存在一些非常关键的问题。&lt;/p&gt;

&lt;p&gt;首先，第（1）步中就直接存在可能导致第（4）和第（5）没法发生的诱因。我们假设研究院的科学家拿到的技术难题是来自产品工程部门的。从现代产品的角度来说，一般的产品工程迭代都非常快。现在的技术难题可能几个星期后就有了能够解决80%问题的解决方案。也就是说，研究院拿到的技术难题有可能是有时效性的。这并不代表这些技术难题随着时间都有可能被解决，而是说，随着时间进程，很多技术难题可以出现多种解决方案。科学家能够找到的比较完美的解决方案（姑且假设能够100%解决问题）需要（2）-（5）这些步骤进入产品，这必然导致产品部门必须在科学家方案推出之前找到可以运行但很粗犷的方案。然而这种方案一旦进入产品，就会成为日后科学家的完美方案进驻的强大阻力。因为产品工程部门会觉得，在产品已经进一步迭代的情况下，是不是有精力和时间去改进一个已经可以运行的方案为更加完美的方案，其实是一个很棘手的问题。这也就会导致步骤（4）常常非常政治化（Political），成为各个团队扯皮的重要原因。刚才说的，还只是假设研究院的科学家拿到的技术难题是来自产品部门的，还有很多情况是，科学家或者研究院自身认为某些技术难题需要得到解决。这样发展出来的研究成果或者产品原型往往就更加难以通过第（4）和第（5）步得到产品化。&lt;/p&gt;

&lt;p&gt;因为第（4）和第（5）步的不确定性，很多研究院在发展过程中，往往把第（2）和第（3）步作为绩效评定的重要结果。这也就导致了很多研究院的成果只能完成第（1）步到第（3）步这个流程。而第（4）步成为了研究院成果产品化的不可逾越的鸿沟。&lt;/p&gt;

&lt;p&gt;那么如何运作研究院能够跨过这个鸿沟呢？雅虎研究院在过去10年的时间里对这个问题有着不错的实践经验。这里的核心问题就是如何把研究院的目标和一般产品工程团队的目标统一起来，使得大家对于产品的开发和运作是同步的。我们这里要提到这么一个概念，那就是“共享目标”。什么意思呢？那就是研究院和产品工程团队虽然从行政上隶属不同的部门，但在项目开发上，两个团队必须组成一个“虚拟团队”，有统一的领导和统一的进程管理，并且执行统一的、共享的目标。研究院和产品工程团队只是在这么一个共享的、统一的目标下分工不一样，责任不同而已。&lt;/p&gt;

&lt;p&gt;具体说来，以笔者参与过的雅虎首页推荐系统为例。产品工程团队每个季度都会和研究院的研究团队一起指定目标。这个目标是一个 综合性目标，有产品的部分（比如提高多少用户访问、提高多少用户点击），有纯工程的部分（比如如何加快代码部署），有研究的部分（比如应该采用什么模型来达到用户访问的提高、比如应该怎么加快模型的训练速度）。那么，“虚拟团队”就会根据这个综合性的目标来分配资源，确保整个团队的工作量和各个方面的目标达到一个不错的平衡。目标共享以后，研究院的研究周期得到了明确，也就是每个季度。同时，研究院的“成果落地”得到了保证，那就是直接和产品对接，每一个季度都需要“上线”。这种模式下的研究院团队，也不会去做“天马行空”的项目，而是仅仅围绕产品工程，做很多“增量式”的创新工作。&lt;/p&gt;

&lt;p&gt;“共享目标”对于雅虎的很多产品决策过程以及运作过程产生了深远的影响。首先，那就是采用“共享目标”架构的产品全责更加清晰，工程负责什么，研究院负责什么，设计师负责什么，每个季度这几个方面一目了然。另一个非常显著的改变，那就是这些产品第一次把AI（这也就是研究院往往负责的部分）、工程以及设计三个方面作为一个产品每个季度推进的三个主要方面。也就是让AI成为了产品的目标的一类公民。&lt;/p&gt;

&lt;p&gt;那么，“共享目标”是不是就解决了研究院的运作问题了呢？答案是，不完全是。首先，“共享目标”听上去容易，但在实际运作中难度其实还是很大。这里面最重要的是信任问题。从公司结构上来说，产品工程团队往往对产品有“所有权”（Ownership），自然希望能够对产品的方方面面有所把握。然而在“共享目标”的框架下，实质上发生的则是，研究院对于产品的部分方面有了一定的决策权和执行权，这势必需要产品工程团队的领导和人员对于这方面有足够的认识和预期。实际上，从另外一种角度来说，这种“共享目标”其实就是产品工程部门把部分产品开发方面长期外包给了研究院的团队。雅虎的产品工程团队能够和研究院针对某些产品这么做，是因为研究院长期以来能够对这些产品持续做出不俗的贡献，赢得了信任。但并不是所有的产品都能够在这样的框架下运作。&lt;/p&gt;

&lt;p&gt;同时，因为和产品工程达成“共享目标”，这势必也就造成了研究院的研究目标和成果相对比较“短视化”，常常迎合了产品周期。这也就呼应了我们之前提到的，比较适应研究院的一类产品，那就是成熟产品。实际上，“共享目标”的模式很好的契合了成熟产品的迭代。&lt;/p&gt;

&lt;p&gt;对于前沿产品来说，这样的架构显然不太适用。因为这个时候产品和工程组可能都还不存在。对于这样的项目来说，最好以研究院的科学家为核心，然后辅以工程师作为支持。从某种意义上来说，这依然是一种“共享目标”，不过则是之前谈到的相反的结构。&lt;/p&gt;

&lt;h2 id=&quot;研究院的成功&quot;&gt;研究院的成功&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/research_leaders.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;之前已经讨论了研究院的架构和运作，那么，我们怎么能够保证研究院的成功呢？我们这里谈两个比较显著的问题。&lt;/p&gt;

&lt;p&gt;第一个方面那就是研究院需要怎么样的领导。这个问题看似很简单，其实需要相当认真的思考。因为研究院需要负责招聘大量的博士层次的候选人。因此一个有声望的、在学术圈有一定地位的人担任研究院的领导势必会对招聘起到很大的帮助作用。同时，因为对于具有博士文凭的研究人员的背景更加熟悉，有学术背景的领导往往更加能够制定人性化的管理方案，让这些博士觉得能够放心工作（比如对于参加学术会议的鼓励，比如对于发表论人的支持等等）。相反，如果这个领导只有工程背景或者是产品背景，即便是以前公司内部的高管，因为背景的差异，除了在招聘方面可能会遇到困难以外，在日常的管理上也可能无法往往都很难胜任研究院领军人这个职务。&lt;/p&gt;

&lt;p&gt;然而这方面的反面，则是从学术圈里直接挖来一些知名教授，来领导研究院。这里面有一些公司希望能够通过教授名气来吸引眼球的目的，而另一方面，也是希望知名教授能够带来招聘上的便利。不过，这样的行为往往忽视了这些知名教授在学术圈的日常运作和公司运作的巨大区别。就算是知名教授，不少人也很难直接管理超过十个学生，而在大公司，特别是研究院这个级别的组织中，管理超过几十人甚至上百人，并且有可能管理其他的中层领导，那么丝毫没有经验的人往往没法胜任这样的复杂协作分工管理。同时，没有公司经验的教授也往往无法在很短时间内领会到现代企业文化（比如晋升、比如公司政治、比如资源协调），能够为自己的团队在众多的团队的合作与竞争中谋取相应的利益。&lt;/p&gt;

&lt;p&gt;因此，比较合适的研究院的领导是至少有一定工业界经验，但可能早年在学术圈或者学校任职的优秀科技管理者。比如雅虎研究院的第一任领导Prabhakar Raghavan，就是这样一位人物。首先本人就是知名的学者，出版过知名教科书《Randomized Algorithms》和《Introduction to Information Retrieval》，并且是ACM，IEEE的院士，也是美国工程院院士。同时，其在加入雅虎之前，已经在IBM研究院以及Verity任职多年，特别是IBM的经历，让他对企业文化和工业界的研究机构有了很深的了解。可以说Prabhakar到雅虎之后很快就能建立起一个非常有效的团队，吸引了一大批的知名学者诸如Andrei Broder、Ricardo Baeza-Yates、Alex Smola等的加入，这和Prabhakar本人的背景可以说息息相关。同时，我们之前提到的关于研究院的运作规律，这其中有很多都是Prabhakar总结了他在多个组织的任职经验以后，在雅虎慢慢发展成熟起来的。&lt;/p&gt;

&lt;p&gt;第二个问题就是公司上下一定要对研究院究竟能给公司带来什么样的价值有一个清晰的判断。从我们刚才的一系列论述来看，研究院虽然在很多产品的研发中占有举足轻重的地位，但总体说来在公司是还是一个合作者的角色，是一个锦上添花，而非雪中送炭的角色。从这一点说来，整个公司的管理者和运行者要十分清楚。不过我们也要防止把研究院的价值庸俗化或者完全以产品成果为唯一的衡量标准。比如Google收购了位于伦敦的DeepMind团队来做深度学习的研究工作。DeepMind最近几年的研究成果，外加炒作的沸沸扬扬的AlphaGo究竟直接为Google的线上产品带来了多大收益恐怕很难直接衡量。但是DeepMind引领的这股深度学习的风潮，让Google在吸引这方面的人才这一方面则形成了巨大优势。这部分为Google节约的公关广告成本或者招聘陈本应该很容易就能覆盖对DeepMind的运营陈本。同时，DeepMind的成果，虽然很多不能直接应用到Google的现有产品上，但是Google的领导人借着这股风潮，让公司更多的工程师和产品人员开始深度介入深度学习领域，在内部进行了很多培训和推广工作，也是利用DeepMind这个研究团队来达到了原本不容易达到的目的。当然，从长远来看，研究院还是需要从产品和视角（Vision）上为公司带来价值，而且这些价值是普通研发团队所不能带来的。&lt;/p&gt;

&lt;h2 id=&quot;总结&quot;&gt;总结&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;我们在这篇文章里详细讨论了什么样的互联网公司需要研究院，研究院又适合在什么样的产品线上发挥作用。我们还在这篇文章中深入剖析了研究院的研发团队如何和一般的产品工程团队合作，能够为现在成熟的产品线或者是前沿的产品的研发提供有力的支援。最后我们谈了一下制约研究院成功的两个关键的因素。本篇文章是第一篇比较完整得系统性阐述互联网公司以及研究院制度的文章，希望能够起到抛砖引玉的作用，让大家更加深入思考如何让研究机构在现代企业，特别是高新技术企业中生根发芽。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>数据科学发展的一些感悟</title>
   <link href="http://column.hongliangjie.com/%E6%95%B0%E6%8D%AE%E7%A7%91%E5%AD%A6/2017/03/02/san_diego/"/>
   <updated>2017-03-02T00:00:00-08:00</updated>
   <id>http://column.hongliangjie.com/%E6%95%B0%E6%8D%AE%E7%A7%91%E5%AD%A6/2017/03/02/san_diego</id>
   <content type="html">&lt;p&gt;上个星期，我参加了位于San Diego召开的一个工业界数据科学会议Predictive Analytics Innovation Summit。在这里分享一些参会后对于数据科学在工业界发展状况及前景的感悟。&lt;/p&gt;

&lt;h2 id=&quot;感悟一数据科学的思潮席卷各个行业&quot;&gt;感悟一：数据科学的思潮席卷各个行业&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/san_diego.jpg&quot; alt=&quot;&quot; /&gt;
参加会议的代表来自各行各业，有互联网公司的数据佼佼者诸如Google、Bing、Netflix、Etsy（我所代表的公司）、Groupon；也有传统的金融产业公司Bloomberg、American Express、Visa；电信公司Verizon；保险公司Zurich；还有更传统的生产行业公司Bosch、Honeywell、Ford、GE Digital；以及一些你可能通常意义下不会认为是数据公司的代表诸如Weather.Com。除了这些有演讲内容的公司以外，还有不少医药行业的公司包括FDA的代表，以及很多其他行业的与会人员。总之从整体上看，对于数据科学的热衷已经席卷了各行各业。每一个行业都开设了诸如Chief Data Scientist、VP of Data Science的高端职位以及开始招聘各类数据科学家（Data Scientist）团队。每一个行业都在介绍自己是如何希望能够建立“数据驱动”（Data-Driven）的文化以及自己如何从数据中获益。每一个行业又是那么急切想从互联网公司、特别是已经在数据的使用和文化上有所建树的公司上得到启发和灵感。&lt;/p&gt;

&lt;h2 id=&quot;感悟二数据科学到底是什么大家并不清楚&quot;&gt;感悟二：数据科学到底是什么，大家并不清楚&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/san_diego2.jpg&quot; alt=&quot;&quot; /&gt;
虽然数据科学的浪潮已经深入各个行业，但大家对于到底什么是“数据科学”，甚至什么是“机器学习”、“深度学习”抑或“人工智能”，其实都有一种“雾里看花”的感觉。很多公司其实并不太清楚这些感念之间的区别或者异同。比较传统的一些公司，甚至是把以前存在过的Business Analysis或者是Business Intelligence部门直接转换成为数据科学部门，感觉有一种为了抓住这个目前的浪潮不惜偷梁换柱的意味。而且究竟数据科学，甚至是人工智能的标签，能为各个企业带来什么根本的变化，大家其实可能心里有不太一样的期待，或者是并没有真正去了解自己的期望究竟是什么。比如有些企业其实只是把数据科学认知为简单的数据分析、有的企业其实也没有太多太大的数据需要真正复杂的数据科学流程和高端的数据科学人才。&lt;/p&gt;

&lt;h2 id=&quot;感悟三数据科学人才极度匮乏&quot;&gt;感悟三：数据科学人才极度匮乏&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/bootcamp.jpg&quot; alt=&quot;&quot; /&gt;
尽管不同行业的各个企业可能还没有搞清楚数据科学到底意味着什么，但有一个共同的趋势，那就是各个行业的企业都发现了相关人才的极度匮乏。一方面，因为大家对数据科学的不确定性造成了其实各个企业并不是特别清楚自己需要的人才究竟是什么样的，也就造成了无法从现在的人才市场里清晰分别优质人才。另一方面，相对于几年前的“数据分析”人才而言，那时候公司还比较能够清晰得从统计背景的候选人中挑选，时至今日，数据科学或者人工智能人才需要全方面的背景，这使得入行门槛急剧增加。于是，目前造成的短期困境就是很多企业有大量职位空缺，但是从候选人池中很难找到如意的从事数据科学的相关人选。&lt;/p&gt;

&lt;h2 id=&quot;感悟四公司之间的巨大鸿沟&quot;&gt;感悟四：公司之间的巨大鸿沟&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/gap.jpg&quot; alt=&quot;&quot; /&gt;
因为对于数据科学认识的匮乏和以及对于公司如何来利用数据科学的混沌，以及由于人才的匮乏这两个显著的特征所带来的另外一个目前一个比较明显的现象就是，传统行业或者互联网的中小企业和目前利用数据科学的佼佼者甚至是人工智能的领军企业只有有非常大的鸿沟。从数据驱动文化上，到如何利用数据上，到具体的技术链条上，到人才的管理和挖掘上，领先的企业已经把大部分的其他玩家给远远抛在脑后。行业与行业之间的鸿沟也非常明显。互联网企业已经建立起了一整套的数据工具、规范和流程以及人才池的培养，紧跟其后的是金融企业（这也是最近一段时间以来大家所宣扬的FinTech带来的结果），然后其他大部分行业都要远远落后。这里面也需要注意的是，从各行各业的对于数据的需求来看，并不是盲目地照搬互联网企业的所谓的成功经验就能够轻而易举地搭上这个数据及智能的快车。其实这也可能表明，很可能没有一个普世的数据策略，每个行业需要摸索最适合自己发展的行业数据科学文化和标准。&lt;/p&gt;

&lt;h2 id=&quot;感悟五数据浪潮方兴未艾&quot;&gt;感悟五：数据浪潮方兴未艾&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/wave.jpg&quot; alt=&quot;&quot; /&gt;
如果我们长期只看少部分互联网尖端企业而言，那么我们很容易陷入当前阶段已经达到人工智能高峰的假象。当然，也不能说这就是假象，只是说少部分企业在他们所在的领域有着巨大的优势。但是如果我们放眼所有行业而言，目前可以说还是数据科学方兴未艾的阶段，有着大量的机会。对于互联网从业人员来说，如何能够从自身的一些优势出发，走到其他行业中去，恐怕是接下来一个阶段大家需要思考的问题。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>只有偏执狂才能生存</title>
   <link href="http://column.hongliangjie.com/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0,%E7%AE%A1%E7%90%86/2016/08/09/intel/"/>
   <updated>2016-08-09T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0,%E7%AE%A1%E7%90%86/2016/08/09/intel</id>
   <content type="html">&lt;p&gt;今年初，Intel传奇领导人物&lt;a href=&quot;https://en.wikipedia.org/wiki/Andrew_Grove&quot;&gt;安德鲁格罗夫（Andrew Grove）&lt;/a&gt;病逝。格罗夫的很多思想在90年代WinTel时代曾对中国的早期IT产业带来巨大启发。他所领导的Intel几乎是个人电脑时代的代名词。而他所著的&lt;a href=&quot;https://www.amazon.com/Only-Paranoid-Survive-Exploit-Challenge/dp/0385483821&quot;&gt;《只有偏执狂才能生存》&lt;/a&gt;作为危机管理的经典著作，影响了好几代人。最近买了这本书的原版来阅读，感触良多，在这篇文章中和大家分享一些读书心得。&lt;/p&gt;

&lt;h2 id=&quot;战略拐点&quot;&gt;战略拐点&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/andrew_grove.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;整本书都是围绕这一个叫“战略拐点”的概念展开的。格罗夫详细阐述了，什么是“战略拐点”，怎么识别它，怎么度过它，等一系列的问题。以及这个“战略拐点”对于公司存亡的重要性。那么，“战略拐点”的特征是什么呢？书中讲了很多内容，但是核心观点就是：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;过去成功的经验现在不太适用了，未来可能更不适用。&lt;/li&gt;
  &lt;li&gt;未来的成功模式是和过去大不相同的，也许是一个全新的领域。&lt;/li&gt;
  &lt;li&gt;对过去越留恋，就越无法过度到未来的胜利彼岸。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;格罗夫反复强调，过去越成功，就越会成为战胜“战略拐点”的阻碍。因为管理者在困难和危机面前，最喜欢做的就是依靠过去的经验，使用曾经赖以成功的法宝。另一方面，也是比较容易忽视的则是管理者的感情寄托，也就是对于曾经的辉煌所付诸的情感投资。这是格罗夫在这本书中的亮点。很多时候，管理者并不是不知道应该去适应变化，去接受“战略拐点”的挑战，而是没法抛弃多年来成功所带来的职业生涯的满足感以及因此而产生的情感。这里的例子，包括Intel自身在1984-1986年时需要从存储器向微处理器全面转型的时候，格罗夫和摩尔两位管理者大师的不情愿、犹豫不决，也包括IBM当年不愿意从大型机的业务转移到蓬勃发展的个人电脑的市场。格罗夫在书中指出，因为需要消除情感依赖而对高层管理人员进行调整，往往成为了在“战略拐点”时期公司所不得不面临的抉择。&lt;/p&gt;

&lt;p&gt;在1996年出版之后到今天整整20年时间，格罗夫在这本书中提出的关于“战略拐点”的种种论述依然经受住了时间的检验，并且为这段时间出现的很多“新案例”提供了理论框架。例如：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;苹果公司自2001这十多年推出的iPod、iPhone以及iPad已经成为了其成功度过多个“战略拐点”的重要奠基石。今天的苹果公司已经不是在格罗夫1996年书里的那个WinTel大军下的失败者，而是在乔布斯带领下的革新者，一个新时代的领军人。乔布斯在个人电脑这个战场上没有占到先机，却洞察到消费电子产品时代的到来以及智能手机的曙光，于是带领苹果公司度过了“战略拐点”，来到了新的高地。&lt;/li&gt;
  &lt;li&gt;与苹果相映成的则是诺基亚和摩托罗拉在这十多年的境况。在模拟手机和数字手机时代如日中天的两个巨头，都没有把握住智能手机的“战略拐点”。重要原因，其实就是过去成功的包袱，经验也罢，情感也罢。令人瞠目结舌的恐怕在于两巨头倒下的速度和程度，令人唏嘘不已。&lt;/li&gt;
  &lt;li&gt;格罗夫在书中专门用一章来讲互联网的挑战。1996年，互联网的泡沫还没有完全到来，而第一个互联网时代的代表公司雅虎则才从斯坦福走出来不过两年。20年后，雅虎在成功成为第一代互联网巨头之后，没有抓住后面的好几次“战略拐点”（包括搜索、社交、移动等），于2016年被Verizon收购。&lt;/li&gt;
  &lt;li&gt;在第二个互联网时代风云驰骋的谷歌公司，面对Facebook的社交网络的挑战时，并没有完全体会到“战略拐点”的内涵。虽然高层下重金推广Google Plus，以期与Facebook一决高下，但实际上却因为丢不了自己的搜索老本行，并没有给Facebook带来多大的挑战。谷歌的搜索优势没有成为其转进到社交媒体这一“战略拐点”的武器。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;类似的例子还有很多，数不胜数。不过令人遗憾的是，尽管格罗夫的书里提供了丰富的指导思想，大多数过去曾经成功的公司在面对“战略拐点”的时候都深陷自己辉煌过去的泥潭，无法自拔。&lt;/p&gt;

&lt;h2 id=&quot;直面现实&quot;&gt;直面现实&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/reality.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;在“战略拐点”面前，格罗夫描绘的，其实是非常惨淡的现实。其中有这么几点值得重视：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;&lt;strong&gt;伤亡&lt;/strong&gt;：也就是有人要做牺牲，普通员工和管理人员，底层、中层、高层。每一个人都有可能在这个转变中不在公司继续下去。必须要接受这样的伤亡。而且，书中讲得非常清楚，从公司最高层，高管，就必须要认识到。今天开会的高管们，其中有一些人是无法继续留下去的。不管这些人员过去有多成功。&lt;/li&gt;
  &lt;li&gt;&lt;strong&gt;混沌&lt;/strong&gt;：最开始的时候，甚至在一段时间内，整个公司，包括管理层，是看不清楚前面的路的。这也就是所谓的“摸着石头过河”。大家要能够适应这样的混沌。更重要的是要坦诚大家不知道前面的路，谁也不清楚知道。不要不懂装懂。因为这个时候如果不愿面对自己的无知，又会让过去的经验来指导自己如何前行。&lt;/li&gt;
  &lt;li&gt;&lt;strong&gt;学习&lt;/strong&gt;：在面对拐点的情况下，一定是面对一个不熟悉的环境。从高层到底层都需要用新的视野，新的技能来武装之自己。于是，学习就是必不可少的一个环节。千万不要以为能够用以前的知识来顺应变化。拐点的本质在于以前的知识现在不适用了。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;除了这些需要主动关注的因素以外，还有一些，作为人，需要被动注意的点。比如，书中提到，管理层在遇到战略拐点的时候，犹如普通人遇到了人生的重大挫折，往往的第一反应是拒绝（Denial）。拒绝承认，觉得不可能。在1984年左右，日本半导体业的内存做得越来越好、价格越来越低的时候，格罗夫说，作为Intel，特别是作为内存的发明者，首先是拒绝承认这样的现实。在这个拒绝的过程中，甚至是动用了很多测试的方法和流程，才最终不得不认可日本的产品要优于Intel自己的产品。&lt;/p&gt;

&lt;p&gt;紧接着拒绝的举动，就是，“装作自己很忙”。很多管理层会使用各种方法，让自己忙起来，这样看上去就是在为公司的未来和转型做打算，把自己的日程安排的慢慢的。抑或是像普通人一样，突然爱好起“购物”，也就是收购公司。在采购的过程中精疲力尽。也就是说，管理层突然热衷收购其他公司，妄想通过收购来达到度过战略拐点的目的。而这个时候，公司往往还没有真正形成新的战略。公司的管理层，从思维到行为，都还和过去一样，于是，这些收购自然也不会真正有效果。收购本身无非是让管理层和普通员工感知到大家很忙，虽然没有忙对地方。这方面比较显著的例子，就是&lt;a href=&quot;https://en.wikipedia.org/wiki/Marissa_Mayer&quot;&gt;Marissa Mayer&lt;/a&gt;在2012年执掌雅虎以后，最初的日子里，战略并没有成形，却开始大肆收购。最终证明大多数这些收购并没有真正帮助到雅虎的战略转型。&lt;/p&gt;

&lt;p&gt;战略拐点的核心思想在于管理层是否能够在这样混沌的犹如过茫茫沙漠一般的“死亡之谷”的过程中，有一套方法论支撑下来。格罗夫的这本书其实就是这样的一个著作。&lt;/p&gt;

&lt;h2 id=&quot;大鸣大放与专注唯一&quot;&gt;大鸣大放与专注唯一&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/chaos.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;格罗夫在这本书中还提到了一个比较有意思的观点，那就是混沌（Chaos）和专注（Focus）的辩证关系。普通的观点可能是，一个公司，特别是大公司高速运转，最需要的就是组织内部的协调和思想的统一。有时候，这样的能力被称作是“专注力”。那么，在这本书中，格罗夫反而深刻阐述了“混沌”的必要性。也就是在公司转型的时期内，需要的反而是“大鸣大放”，需要某种程度的混乱。&lt;/p&gt;

&lt;p&gt;认识到“混沌”的重要性是格罗夫关于战略转型期的创造性认识。其实，这一观点能够从我们前面提到的“直面现实”中推演出来。因为，包括公司管理者可能都在最开始的时候，无法预测公司的未来。甚至也不能够知道接下来的战略转型是不是正确的。即便是正确的，也没有人能够保证各种决策的有效性。这个时候，其实非常难以让所有人都统一到一个方向上。各种人会有各种质疑。格罗夫认为，减少质疑的方法，不是禁止“混沌”，而是要让大家在公开的、有价值的、坦诚的讨论甚至是争论中进步，得到提升，能够为形成共识创造条件。这里，有一点，“真理越辩越明”的感觉。&lt;/p&gt;

&lt;p&gt;在大鸣大放的过程中，观点和方向逐渐清晰，那么这个时候，需要做的就是专注起来，把公司的思想和资源都统一到一个点上。整个的转型战略就是这一个点。注意，是一个点，而不是一个线或是一个面。格罗夫认为，在经历了“混沌”之后，公司已经精疲力尽，很难在一个面，或者一条线上组织起有效的力量。于是，在这种情况下，唯一能做的，是有效得组织一个点上的爆发。&lt;/p&gt;

&lt;p&gt;从“混沌”到“专注”，格罗夫认为这两者需要在公司内部动态、有机得组织起来。能够真正理解这两者的转换和每一个部分的特点，才是在转型期领导人的必须职责。&lt;/p&gt;

&lt;h2 id=&quot;历史与今天&quot;&gt;历史与今天&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/history.jpg&quot; alt=&quot;&quot; /&gt;
《只有偏执狂才能生存》成书于20年前的1996年。自然，在书中用到的例子，都是来自于上个世纪70年代到90年代这一个时期。从20年后的今天来看，很多例子非常有意思。&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;&lt;strong&gt;苹果&lt;/strong&gt;： 在书中，苹果基本上是作为负面例子出现的。书中讲，大型机到PC机的转变中，整个工业界的形态从一家公司的“大包大揽”纵向布局，也就是从硬件到软件全包的一条龙服务，过度到了横向布局，也就是一家公司专注于某个领域（例如硬件，或者软件），整个行业分工协作。在这个过程中，崛起了Intel和微软，也崛起了组装厂商Dell和HP。苹果在PC这个战场上，可以说是“起个大早赶个晚集”。格罗夫认为乔布斯过于固守苹果自己要做纵向的布局，从而在横向的竞争中，无法保持公司的先进性。90年代的苹果，也在起起伏伏中，前途未卜。然而，同样是乔布斯，同样是纵向布局思维，在10年后的2000年代，iPhone和iPad所引领的移动时代则取得了巨大成功。而在这个新的战场上，Intel和微软被抛完全被抛弃。这20多年的动态变化，不仅充满了戏剧性，而且让人深思。当然，苹果现在的成功，也恰恰说明了，没有不变的战略，在战略拐点面前，过去的经验对未来不一定具有预见性，甚至是过去失败的教训，未来也未必就一定是错的。&lt;/li&gt;
  &lt;li&gt;&lt;strong&gt;电动车&lt;/strong&gt;： 格罗夫在书中提到的，所谓“已经被证明是空想”的想法中，举了电动车的例子。书中并没有展开说，为什么这是一个“彻底的失败”（Complete Failure）。不过，从今天看，最有未来前瞻性，也是最可能在不远的将来带动一个革命性变化的行业，就是Tesla引领的电动车的浪潮。今天，整个硅谷，除了Google、百度、Tesla在投身到电动车外加自动驾驶车的研发中以外，传统车行业的各个厂商也摩拳擦掌，生怕自己在这轮竞争中被淘汰。20年前，电动车也许的确是一个失败的概念，但时至今日，在经历了20年的蛰伏，电动车已经进入了千家万户。这也是一个深刻的观点，那就是过去失败的想法，未必是未来成功的阻碍。&lt;/li&gt;
  &lt;li&gt;&lt;strong&gt;互联网&lt;/strong&gt;：格罗夫在书中给了互联网高度的评价，并且预测互联网能够颠覆广告业。想想这是20年前，在Google、Facebook彻底推动广告业之前能有这样的预测，足可以见到格罗夫对行业的分析能力。不过，这也从侧面说明了，即便是正确的预测，一个行业也许需要很多年时间才能够成熟。如果能够在这样的间隙内找到机会，才是所有人都需要思考的问题。&lt;/li&gt;
&lt;/ul&gt;

&lt;h2 id=&quot;总结&quot;&gt;总结&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;《只有偏执狂才能生存》这本书值得细细品味的地方当然远远不止这些。这篇文章只是试图给大家展示几个这本书中的关键点，希望能够起到抛砖引玉的作用。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>怎样招聘一名科学家</title>
   <link href="http://column.hongliangjie.com/%E6%95%B0%E6%8D%AE%E7%A7%91%E5%AD%A6/2016/05/14/hire/"/>
   <updated>2016-05-14T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E6%95%B0%E6%8D%AE%E7%A7%91%E5%AD%A6/2016/05/14/hire</id>
   <content type="html">&lt;p&gt;看了&lt;a href=&quot;https://zhuanlan.zhihu.com/p/20865434&quot;&gt;韩春雨&lt;/a&gt;的事迹以后，很是感动，我于是在微博上谈论一下&lt;a href=&quot;http://weibo.com/3193816967/DuGAd9tmD&quot;&gt;简历背景是否等于一个人的成就和水平&lt;/a&gt;，里面谈及了一些在招聘科学家过程中的遇到的经历和水平的问题。后来，我感觉需要系统得总结一下招聘科学家的流程，一是为了记录下在招聘过程中的一些思考，另一方面也是为了帮助年轻学者或者博士生，能够提高自身的水平。当然，一个高水平的流程，也是对自己的一种鞭策。我时常也会想，在这样的流程里，我是否能够体现自己的能力和水平。&lt;/p&gt;

&lt;h2 id=&quot;面试的目的&quot;&gt;面试的目的&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/interview_1.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;在我们谈论如何建立一个快速有效的面试过程之前，我们一定要弄明白，我们究竟要招聘什么样的人才。面试的目的是让我们的需求和我们要招聘的人才之间建立一个统一。也就是说，我们的流程是为了招到我们想要的人才。对于一个科学家而言，我们关心如下这些素质：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;科研的基本水平：这里面包括如何查找相关文献；如何把一个工程问题或者是产品问题转化成科研问题，从而利用科研工具解决这个问题；如何完成完成的科研流程（比如提出解决方案，实现解决方案，做实验，写论文专利）；如何包装科研成果（比如作报告，向其他工程师讲授内容）等等方面。&lt;/li&gt;
  &lt;li&gt;工程的基本水平：虽然科学家并不是工程团队的工程师，但我们也要求我们的科学家能够理解现在公司的工程框架、代码库，能够在实现关键代码；能够做代码审核（Code Review），能够做非常接近于生产环境（Production）的原型系统（Prototype）。&lt;/li&gt;
  &lt;li&gt;交流沟通能力：能够清晰得阐述自己的观点；能够聆听别人的观点；能够起到科研成果、工程、产品之间的桥梁作用。
团队协作能力：能够在一个科研团队里能够发挥自己的作用，能够帮助团队成功，而不是只关注自己。
好奇心：能够学习新东西，有很强的自我要求。能够在短时间内学习大量的新知识。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;面试的目的是要检测出候选人在上述这些方面的一个综合表现。我们后面还会说到面试的各个环节如何考察候选人的这些素质。&lt;/p&gt;

&lt;p&gt;除了考察基本素质之外，作为招聘方，还有一个方面需要考虑的是，我们是要招一个“通才”（Generalists）还是一个“专才”（Specialist）。作为很多公司（特别是中小型公司）而言，项目、产品可能会发生反复变化，对于科学家而言，可能需要在短时间里，适应不同的项目不同的方向，这就需要招“通才”。而如果是一个成型的公司，需要在现有的基础上提高产品质量，就需要招“专才”。招聘这两种类型的人才考察的侧重点是不一样的。比如，考察“通才”重点是要看候选人是否能够对于陌生的领域问题有无好奇心、能否利用自己学习的知识分析陌生领域问题。而考察“专才”重点是要看，候选人是否在专注的领域有过硬的基础和深入的理解。&lt;/p&gt;

&lt;p&gt;说了这些细节的方针，一个总的原则是，考察候选人的&lt;strong&gt;强项&lt;/strong&gt;，看候选人&lt;strong&gt;能干什么&lt;/strong&gt;。因为很多领域都是非常广的（比如机器学习），我们其实无法要求候选人什么都懂，所以我们不是要考察这个人不懂什么，因为有很多东西不懂是很正常的，而是要考察这个人究竟懂什么，他（她）说懂的东西是不是真的懂，他（她）能否运用懂的东西去解决新问题。&lt;/p&gt;

&lt;h2 id=&quot;筛选简历&quot;&gt;筛选简历&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/interview_2.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;筛选简历是一个很需要细心的过程。对于普通的博士毕业生，我们会很快速看两个方面的信息：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;是否有高水平的论文发表
    &lt;ul&gt;
      &lt;li&gt;是专注一个问题或者一个小领域还是很多领域都有论文&lt;/li&gt;
      &lt;li&gt;第几作者&lt;/li&gt;
      &lt;li&gt;论文发表频率，是否是所有工作都是一年做出来的&lt;/li&gt;
      &lt;li&gt;论文档次&lt;/li&gt;
      &lt;li&gt;引用数&lt;/li&gt;
    &lt;/ul&gt;
  &lt;/li&gt;
  &lt;li&gt;是否有工业界实习经历
    &lt;ul&gt;
      &lt;li&gt;是否是研究实习还是工程实习&lt;/li&gt;
      &lt;li&gt;实习的公司&lt;/li&gt;
      &lt;li&gt;是否是同一家公司还是多个公司&lt;/li&gt;
      &lt;li&gt;如果是研究实习是否有相应论文发表&lt;/li&gt;
    &lt;/ul&gt;
  &lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;在看了这两个因素之后，我们心中对于这个候选人就有一个很基本的认识。在通常需要高标准的情况下，一个博士毕业生如果没有3-4篇第一作者的高水平论文发表（在毕业的时候，引用数在70-100左右），没有1-2次工业界实习经验，我们就不会考虑这个候选人的其他方面了。除了这两个硬指标以外，我们还会关注：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;简历里是否有一些信息不完整的部分
    &lt;ul&gt;
      &lt;li&gt;比如有一些明显断档的经历&lt;/li&gt;
      &lt;li&gt;没有本科学校&lt;/li&gt;
      &lt;li&gt;没有说明博士生导师&lt;/li&gt;
    &lt;/ul&gt;
  &lt;/li&gt;
  &lt;li&gt;会什么编程语言和开发工具
    &lt;ul&gt;
      &lt;li&gt;是否只熟悉Matlab或者R&lt;/li&gt;
      &lt;li&gt;是否有开源项目贡献&lt;/li&gt;
    &lt;/ul&gt;
  &lt;/li&gt;
  &lt;li&gt;是否已经有审稿经验&lt;/li&gt;
  &lt;li&gt;是否已经有组织会议的经验&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;所有这些因素都没有明显问题之后，我们已经定位到了比较靠谱的候选人（通常，只有少数人能够通过上面这轮简历筛选）。我们可以根据实际情况来调整在筛选简历这里的标准线（Bar）从而让候选人能够和我们直接交流证明自己的实力。&lt;/p&gt;

&lt;p&gt;这里再说几个比较细的准则：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;博士生的论文中，非第一作者的一般不算数&lt;/li&gt;
  &lt;li&gt;已经发表的会议论文和同一内容的期刊文章算一篇&lt;/li&gt;
  &lt;li&gt;可以有非第一档次会议或者期刊的论文，但没有第一档次的是不行的&lt;/li&gt;
  &lt;li&gt;如果有单一作者的论文，是一个比较大的问题，电话面试的时候一定要问清楚原因&lt;/li&gt;
  &lt;li&gt;课程项目原则上也不算数&lt;/li&gt;
  &lt;li&gt;简历是LaTex生成还是Word&lt;/li&gt;
  &lt;li&gt;毕业学校和GPA，一般不是很侧重要考虑的问题&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;再说几个对于已经有工作经验的候选人的简历筛选要素：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;如果有教职经验或者博士后经验，原则上是一个大问题，需要电话面试问清楚&lt;/li&gt;
  &lt;li&gt;一两年左右频繁换公司是一个大问题，需要电话面试问清楚&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;这里要多说一句的是，上面这些标准是对计算机相关专业比较适用的准则。而对于数学、应用数学、统计、物理等等专业的人来说，可能有些标准需要重新设定（比如发表论文的标准需要降低）。总之，这里说的是一些比较大的方向，不过在把握了这些原则之后，我们就可以安排少量的候选人电话面试了。&lt;/p&gt;

&lt;h2 id=&quot;电话面试&quot;&gt;电话面试&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/interview_3.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;在经过筛简历的过程后，电话面试的目的是要看这个候选人是不是像简历里所说的那样有相应的经历。当然，有一些公司在电话面试的时候也会考察候选人解决问题的能力，这也是很经常发生的安排。一般对于科学家的职位，我们需要2-3轮电话面试，包括了解下面这些信息：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;了解候选人简历上的基本信息，如果简历上有疑点，需要在这个阶段问清楚&lt;/li&gt;
  &lt;li&gt;考察候选人是否能够有基本的专业知识和相关领域的见解，考察候选人是否有其他领域的知识&lt;/li&gt;
  &lt;li&gt;考察候选人是否有基本的专业相关的编写代码的能力&lt;/li&gt;
  &lt;li&gt;体会候选人的表达能力，英语水平&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;在询问候选人的简历信息的时候，有这些内容是需要弄明白：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;对于候选人是第一作者的论文，候选人是否能够很清晰说出这些论文的解决问题、思路。在进一步的沟通里，候选人是否能够讲清楚模型细节甚至是公式细节。候选人能够把实验的目的、数据、比较算法讲清楚。当然，这需要面试官做提前准备。同时，询问候选人其他作者在这篇论文中的贡献。&lt;/li&gt;
  &lt;li&gt;对于候选人是非第一作者的论文，询问候选人在这个工作中起到了什么作用。看候选人是否诚实可信，也可以看出候选人的学术道德水平。&lt;/li&gt;
  &lt;li&gt;对于单一作者的文章，需要候选人解释为什么这个工作没有合作人，博士生导师为什么不是合作者，这个论文的研究时间如何而来。&lt;/li&gt;
  &lt;li&gt;对于有博士后经验或者教职经验的候选人，要询问候选人是否分得清楚工业界研究和学术界研究的区别，要询问候选人如果以后有机会，是否还考虑学术界教职。&lt;/li&gt;
  &lt;li&gt;对于有工作经验的候选人，要询问候选人反复换工作的原因，询问清楚候选人在项目里的具体贡献，要询问候选人的职业规划，看职业规划和简历经历是否能够吻合。对于在某一个公司待了很长时间没有升职的候选人，也需要询问一下为何在旧公司里没有其他机会。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;在考察候选人专业知识的时候，有这些内容需要弄明白：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;对于某一专业最基础的一些概念和知识，候选人是否能够清晰地讲解出来。这一条其实很多人很难做到。不少人能够做复杂的工作，却往往在最基础的内容上含混不清。而在一些跨领域的工作中，基础知识往往是一个科学家所能够依赖提供解决方案的最初的工具。所以，基础很重要。&lt;/li&gt;
  &lt;li&gt;候选人是否诚实说明自己懂什么，不懂什么。在广泛的领域里，科学家应该有足够的自信说自己的专长是什么，自己的局限在哪里。&lt;/li&gt;
  &lt;li&gt;候选人是否对跨领域知识一窍不通，还是略有知晓，界限在哪里。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;在考察编程水平方面，虽然很多公司已经有比较完备的方案考察软件工程师，但这些题目和考察目的其实不太适合科学家。这需要公司专门针对科学家制定一些考察题目。关于这方面的探讨，我以后还会专门写文章。&lt;/p&gt;

&lt;p&gt;在上述考察候选人各个方面的过程中，一个贯穿始终的主题就是要看候选人是不是能和面试人员进行有效的沟通。当然，也要考虑到，有人可能不太适应电话面试，而在面对面的交流时则毫无问题。&lt;/p&gt;

&lt;h2 id=&quot;现场面试&quot;&gt;现场面试&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;&lt;img src=&quot;/assets/interview_4.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;在经历了简历筛选的流程和电话面试之后，我们已经对候选人有了一个初步的了解：他（她）的背景、熟悉以及不熟悉的领域、编程能力和沟通能力。对于各方面都表现不错的候选人，我们一般就会安排到公司来进行现场面试。对于科学家岗位，现场面试一般包括下面这些环节：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;一场一个小时左右的学术报告会&lt;/li&gt;
  &lt;li&gt;和招聘经理讨论可能的项目方向&lt;/li&gt;
  &lt;li&gt;和其他科学家、工程师讨论技术和研究问题&lt;/li&gt;
  &lt;li&gt;和人事讨论职位的其他问题&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;学术报告会是考察候选人学术水平的一个非常重要的环节。因为简历和电话面试都无法系统得看出候选人的整个学术生涯的特征（是偏理论、偏应用，是到处蜻蜓点水似的研究，还是专注某几个问题）。一场报告会，候选人必须能够在逻辑上提供一个链条把自己的学术成果贯穿起来。好的候选人的整个学术生涯都有清晰明确的线条。同时，报告会还是观察候选人是否有清晰的语言组织能力和表达能力的很好机会。有一些候选人连自己的工作都讲不清楚。另外一个需要考察的就是，候选人是否能够在公开场合接受各种质疑和对自己工作的挑战，包括候选人是否能够承认自己工作的局限性和不足，候选人能否礼貌但“到点”（To-The-Point）地回答技术问题。&lt;/p&gt;

&lt;p&gt;对于和招聘经理讨论可能的项目方向，很多候选人显得很随意，觉得这就是闲聊。其实这也是观察候选人和考察候选人的一个很重要的机会。首先，招聘经理可以说一些公司的产品或是项目，看看候选人是否有兴趣，看看候选人是否能够通过一些简单的产品介绍，问出一些有科学价值的问题。会问问题，其实是一个非常重要的技能。招聘经理也可以在稍微深入得讨论一些产品的一两个具体的现实问题，看候选人能否快速说出一些解决方案或者是一些思路。在整个谈话中，可以体会出候选人是否只有学术的经验而没有任何产品和产业的“感觉”（Sense）。有一些候选人在这个阶段会显得没法把谈话进行下去，完全是倾听问不出任何问题。这就需要招聘经理仔细控制谈话来看候选人是否对新事物有好奇心，是否能够跟上思路，对新领域新问题有快速的思考。&lt;/p&gt;

&lt;p&gt;和参加面试的科学家以及工程师讨论研究问题，主要考察的是候选人在一个类似工作的环境里能否&lt;strong&gt;半&lt;/strong&gt;独立得完成科研解决方案的设计和实现。为什么说“半”，是因为这个环节里，沟通也是很重要的，很多条件、约束和限制都需要候选人和面试人员进行有效沟通来得以清晰化。因此，候选人面对的并不是完全“应用题”似的独立解决问题场景。这里的通常形式是，面试人员针对某个具体的问题，询问候选人如何提供一个有效的科学解决方案。这里面需要注意的环节有：&lt;/p&gt;

&lt;ul&gt;
  &lt;li&gt;候选人是否能够问出有效的问题，这些问题是不是在帮助候选人自己减少问题的不确定性，帮助候选人自己寻找答案，还是漫无目的地问各种问题。&lt;/li&gt;
  &lt;li&gt;候选人是不是不假思索得就提供一些思路，然后没有认真思考以后又更换思路，反反复复。这是候选人没有系统思维能力的一个体现。&lt;/li&gt;
  &lt;li&gt;候选人的整体思维模式是怎样的
    &lt;ol&gt;
      &lt;li&gt;先提出一个也许可以解决的多步骤的方案，然后看是否能够简化步骤，然后看能否提出比较规范的数学模型&lt;/li&gt;
      &lt;li&gt;先提出比较完整的数学模型，然后能够根据实际情况简化，提出更加快速的算法&lt;/li&gt;
    &lt;/ol&gt;

    &lt;p&gt;这两种思维模式都是行之有效的思维方式。但是也有候选人在两者之间踌躇，一方面提不出“丑陋一点”的解决方案，一方面完整的数学模型也写不出来。&lt;/p&gt;
  &lt;/li&gt;
  &lt;li&gt;候选人能否在提出基本方案或者是数学模型之后，能够用自己掌握的方法把问题的细节算法写出来，并且能够分析算法的各方面特征。这考察的是候选人解决问题连贯性和独立性。有一些候选人的确能够漂亮的写出数学模型，但是可能完全没法把模型给算法化，写出来的程序惨不忍睹。&lt;/li&gt;
  &lt;li&gt;还有一个需要考察的维度就是，候选人遇到领域之外的问题，是如何思考的。有的候选人就彻底懵了，完全不能理性化得提出任何方案。而有的候选人则会小心翼翼利用基础知识去尝试解决问题；或者是把新领域的问题转化成自己熟悉的问题。&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;值得注意的是，在这个环节中表现不好的候选人，不管过去的论文、学校、导师经历多么优秀，都要打一个大问号，而事实证明，往往在这个阶段不那么令人满意的候选人，在现实工作中也很难胜任实际的工作。&lt;/p&gt;

&lt;p&gt;对于有经验的候选人，这部分的考察重点除了刚才说的解决方案本身以外，还可以看候选人是否有&lt;strong&gt;全局观&lt;/strong&gt;，比如如何设计更加有效的数据通路；比如没有数据怎么办；比如上线以后系统表现不好怎么办。&lt;/p&gt;

&lt;p&gt;有一个需要观察的就是，候选人的表现是否在有压力或者劳累（毕竟一天的现场面试是很累的）的情况下有重大波动。优秀的候选人能够通过沟通来缓解自己的压力。&lt;/p&gt;

&lt;h2 id=&quot;总结&quot;&gt;总结&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;本篇文章简单得总结了招聘科学家的流程，希望能够对于需要招聘科学家的公司有一个抛砖引玉的作用，也希望能够对于找工作的博士们或者已经有工作经验的人有帮助。招聘有时候就像恋爱，也讲感觉，也讲契合度。同时，一个规范的流程只是找到合适人才的一个部分，对于如何挖掘如何考察一个人的水平还有很多方面的工作要做。&lt;/p&gt;
</content>
 </entry>
 
 <entry>
   <title>新闻推荐，追逐卡戴珊的“屁股”</title>
   <link href="http://column.hongliangjie.com/%E6%8E%A8%E8%8D%90%E7%B3%BB%E7%BB%9F/2016/04/23/news-recsys/"/>
   <updated>2016-04-23T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E6%8E%A8%E8%8D%90%E7%B3%BB%E7%BB%9F/2016/04/23/news-recsys</id>
   <content type="html">&lt;p&gt;前一阵子，有一篇新闻文章叫&lt;a href=&quot;http://www.businessinsider.com/yahoo-reporters-frustrated-competing-against-kim-kardashians-ass-2016-4&quot;&gt;“雅虎记者的困扰：与卡戴珊的屁股竞争”&lt;/a&gt;，讲的是雅虎公司的一群高级记者所写的文章与推荐系统所推荐的文章相互竞争协调的事情，里面提到的现象可能很多做推荐系统开发的人都感同身受，似曾相识。那么今天，我们不谈具体的公司具体的案例，而来聊一下推荐系统开发中遇到“&lt;strong&gt;推荐结果和自己的直觉不相符合怎么办&lt;/strong&gt;”这个事情该怎么办。&lt;/p&gt;

&lt;h2 id=&quot;记者和编辑的抱怨&quot;&gt;记者和编辑的抱怨&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;你是一个内容平台（网站或者是App）的推荐系统工程师，在忙了好几个月之后，最新的个性化新闻推荐系统终于上线了。你满心欢喜得看着最新的系统推动着各类指标上扬，正在为自己的又一个成就而感到高兴。这时候，产品经理发来邮件，说公司的一些高级编辑对现在推荐结果非常不满意。具体说来，就是这些高薪聘请的编辑发现自己的文章没法占据推荐的头条了，于是认为新系统“不和谐”。下面一个步骤，往往是产品经理屈从于高级编辑的一些意见，希望推荐系统能够在编辑撰写的文章和算法推荐的文章中达到一个平衡。而你，作为工程师，觉得这是一种侮辱，不愿意这么做。&lt;/p&gt;

&lt;p&gt;很多做算法和模型的工程师，特别是推荐领域的，一般很难理解或者是很难推崇编辑的作用。一方面，这是因为工程师并不清楚编辑究竟能为系统带来什么，另一方面也在于专业训练中，模型基本上都是优化&lt;strong&gt;用户体验&lt;/strong&gt;的。显然，几个编辑，很难说就代表了广大用户群的需求。于是，工程师和编辑之间的矛盾自然就产生了。&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/news_editor.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;说到底，这种矛盾主要还是是价值观的差别。编辑，从内容生产者（Producer）的角度来思考问题，长期持有的态度是&lt;strong&gt;我想要用户看什么&lt;/strong&gt;。特别是从比较强势的传统媒体培养起来的人，这样的观念尤为明显。在这样的价值观导向下，内容平台往往成为了某一些编辑的价值传输筒，因此选择的内容常常带有很强烈的主观色彩。工程师，则喜欢从&lt;strong&gt;用户想要看什么&lt;/strong&gt;的角度入手，从内容消费者（Consumer)的角度来看问题，优化广大用户的体验。工程师更相信数据、相信代码，不喜欢价值观导向。乍一看，现代的内容推荐系统应该尽量避免编辑的干扰，从指标优化的角度来把内容推荐完全看成是工程问题，减少主观因素。&lt;/p&gt;

&lt;p&gt;然而，现实中，这样做，对于一个推荐系统来说，可能有很差的实际效果。原因是这样的，现在用户喜欢的取决于你给用户之前看了什么，你没给用户看过的，用户因为不知道，所以没法给你反馈是否喜欢。这在之前的文章“&lt;a href=&quot;/%E4%B8%AA%E6%80%A7%E5%8C%96,%E6%8E%A8%E8%8D%90%E7%B3%BB%E7%BB%9F/2016/04/07/personalization-or-not/&quot;&gt;个性化推荐是不是伪命题&lt;/a&gt;”和“&lt;a href=&quot;/%E6%8E%A8%E8%8D%90%E7%B3%BB%E7%BB%9F/2016/04/13/exploration/&quot;&gt;论推荐系统的Exploitation和Exploration&lt;/a&gt;”中都有详细的阐述。核心思想，就是要有一个机制，使得用户的现在喜好和系统的长期健康运行得到平衡。这方面，编辑的作用就可以得到体现了。比如，一个新闻网站，娱乐新闻一定是最吸引眼球的。那么，是不是只给用户看这类的新闻呢？即便作为工程师和产品经理，你知道显示这类的新闻，访问量会长期爆表，但这可能对网站的长期发展是不利的（下面会提到一个问题）。于是，你就想在牺牲流量的情况下，放一些其他的内容。这时候，编辑就是最适合寻找或者原创这样内容的人选。实际上，编辑选择的内容，可以很好得融合到Exploitation &amp;amp; Exploration策略的Prior Knowledge里面，使得Exploration不至于过于“荒腔走板”。&lt;/p&gt;

&lt;p&gt;编辑另一个很重要角色还在于处理突发事件的时候，比一个机器学习驱动的推荐系统要有效得多。在那个时候，数据中还没有很多的强信号，很难知道某个突发事件之后的流行程度。于是，编辑可以在第一时间，绕过现有的机器学习系统，为一些新闻的抢先报道，赢得时间。&lt;/p&gt;

&lt;h2 id=&quot;用户群和格调的错位&quot;&gt;用户群和格调的错位&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;当你开发了一款百万人亦或是千万人使用的新闻推荐系统之后，你一方面可能醉心于不断创新高的报表数据，另一方面，你可能会觉得推荐的文章充斥娱乐花边新闻庸俗不堪。有时候，作为产品经理，你甚至会对工程和算法团队产生深刻的质疑，希望产品“格调”能够有所提高。&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/reading.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;前面一小节已经从&lt;em&gt;战术&lt;/em&gt;层面来探讨了这种情况下如何协调编辑和工程师。那么，作为产品经理来说，战略上怎么办呢？这里面最关键的点，是&lt;strong&gt;你产品的盈利模式所需要的人群和你产品目前的使用人群之间，究竟是否有错位&lt;/strong&gt;，如果有，会不会是致命的。&lt;/p&gt;

&lt;p&gt;举一个简单的例子，你的网站是一个依靠广告收入的媒体平台。通过后台数据分析，你知道，点击广告和对广告内容有转化（Conversion）的群体是年龄30-50岁的小城镇人口，并且在这个年龄段里，女性的点击率还要高于男性。然而，你网站的新闻则吸引的是18-30岁的大城市人口，其中20-25岁人的点击量是最多的。于是，这就产生了一组矛盾。一方面，你网站有很高的点击率，而且依靠推荐系统的推荐结果（学习用户行为）进一步强化了现在高频使用人群的行为。而另一方面，贡献你网站收入来源的群体则有可能会被推荐结果所忽视，甚至被赶走。&lt;/p&gt;

&lt;p&gt;所以这时，是一个很需要多个部门联合考虑的决策。有两个很显然的方向，第一，保持住现在的内容消费群体，尝试引入（Onboard）适合这个群体的广告商；第二，保持住现在的广告消费群体，尝试冷启动（Cold-Start）一些有可能对现在广告消费群体感兴趣的内容。&lt;/p&gt;

&lt;p&gt;决策一的不易之处是，广告商有时候是通过销售以及其他相对成本比较高的方式获得的，很难轻易更换。产品经理可以采取的方法是，开始接洽和寻找是否有可能扩展广告商群体。这是一个长期的过程。决策二的不易之处在于，如何能够找到广告消费用户所喜欢的内容，也许这些内容根本就在你的网站上不存在。于是，这里面存在要去获取（Acquire）内容的情况。这也很不容易，牵涉到“获取啥”和“到哪儿找”的问题。&lt;/p&gt;

&lt;p&gt;第三个维度，需要产品经理考虑的是，根据产品的原始定位，也许产品需要的目标人群和现在内容以及广告消费人群均有差距。那么，这个时候，需要内容策略和广告策略都要调整，而且还牵涉到用户群的获取问题（Acquisition），则决策更加不易。&lt;/p&gt;

&lt;p&gt;值得注意的是，这小节讨论的问题，都是&lt;strong&gt;用户群体&lt;/strong&gt;的错位问题，而不是产品经理或者工程师自己对产品结果的感官问题。因为产品经理或者工程师很可能既不是产品的内容消费群体也不是产品的广告消费群体，很容易这个时候主观代入，产生&lt;strong&gt;我认为内容应该什么样&lt;/strong&gt;的问题。&lt;/p&gt;

&lt;h2 id=&quot;个性化的重要性&quot;&gt;个性化的重要性&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;前面两节谈了比较&lt;em&gt;抽象&lt;/em&gt;的产品战术和战略的问题，这一节我们谈一点具体的技术问题。虽然在之前的文章“&lt;a href=&quot;/%E4%B8%AA%E6%80%A7%E5%8C%96,%E6%8E%A8%E8%8D%90%E7%B3%BB%E7%BB%9F/2016/04/07/personalization-or-not/&quot;&gt;个性化推荐是不是伪命题&lt;/a&gt;”中，我们已经谈论过，推荐结果“千篇一律”的问题。但“推荐结果不符合你的预期”依然有可能是建模和算法出了问题。&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/personalized.png&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;比较常见的一个误区是，推荐系统通过学习用户行为能够&lt;em&gt;自动&lt;/em&gt;对用户做个性化推荐。比如流行模型Latent Factor Model&lt;sub&gt;[1]&lt;/sub&gt;，或者Factorization Machine&lt;sub&gt;[3]&lt;/sub&gt;，虽然能够对用户进行推荐，但是推荐结果很可能不是真正个性化的。这里面的一个问题是，这些模型都是通过优化一个&lt;strong&gt;平均情况&lt;/strong&gt;来学习模型参数的。也就是说，通常情况下，一个比较好的模型是能够“解释”大多数用户的行为，但不一定在某一些个别用户上有比较优异的表现。学习出来的模型往往是保住了“大部分”用户的准确度而牺牲了少部分用户。&lt;/p&gt;

&lt;p&gt;当然，上面这个解释其实有可能是非常不对的。因为模型有可能是对用户交互数据进行建模，而绝大多数的数据则可能是少部分用户产生了大部分数据（一些用户“狂”点某一部分内容），于是模型倾向于&lt;em&gt;过度&lt;/em&gt;解释这部分数据。而大多数用户并没有产生很多交互数据，于是模型就倾向于忽略这部分所可能产生的错误。所以，真实情况可能是，小部分人满意了，而大部分人被牺牲了。&lt;/p&gt;

&lt;p&gt;目前对于这方面的问题，学术圈和工业圈其实并没有比较标准的方案。去年NIPS Workshop中有一篇文章&lt;sub&gt;[2]&lt;/sub&gt;谈论了一些探索。不过，依然，如何衡量一个系统已经充分个性化，如何真正学习个性化模型，还是有待于解决的问题。&lt;/p&gt;

&lt;h2 id=&quot;结论&quot;&gt;结论&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;本篇文章讨论了推荐系统中，推荐结果不满意的情况。文章展开说了编辑和工程师的关系，以及产品经理要在不满意的推荐结果面前做怎样的决策。最后，我们也分析了推荐模型的问题，提出了改进的方向。&lt;/p&gt;

&lt;h2 id=&quot;参考文献&quot;&gt;参考文献&lt;/h2&gt;
&lt;hr /&gt;
&lt;ol&gt;
  &lt;li&gt;Deepak Agarwal and Bee-Chung Chen. 2009. &lt;strong&gt;Regression-based latent factor models&lt;/strong&gt;. In Proceedings of the 15th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining. ACM, New York, NY, USA, 19-28.&lt;/li&gt;
  &lt;li&gt;Daniel Crankshaw, Xin Wang, Joseph Gonzalez and Michael Franklin. &lt;strong&gt;Scalable Training and Serving of Personalized Models&lt;/strong&gt;. NIPS Workshop 2015.&lt;/li&gt;
  &lt;li&gt;Steffen Rendle. &lt;strong&gt;Factorization Machines with libFM&lt;/strong&gt;. ACM Transactions on Intelligent Systems and Technology (TIST) 3, 3, Article 57 (May 2012), 22 pages.&lt;/li&gt;
&lt;/ol&gt;
</content>
 </entry>
 
 <entry>
   <title>论推荐系统的Exploitation和Exploration</title>
   <link href="http://column.hongliangjie.com/%E6%8E%A8%E8%8D%90%E7%B3%BB%E7%BB%9F/2016/04/13/exploration/"/>
   <updated>2016-04-13T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E6%8E%A8%E8%8D%90%E7%B3%BB%E7%BB%9F/2016/04/13/exploration</id>
   <content type="html">&lt;p&gt;&lt;a href=&quot;/%E4%B8%AA%E6%80%A7%E5%8C%96,%E6%8E%A8%E8%8D%90%E7%B3%BB%E7%BB%9F/2016/04/07/personalization-or-not/&quot;&gt;上一篇文章&lt;/a&gt;讲到，一个推荐系统，如果片面优化用户的喜好，很可能导致千篇一律的推荐结果。文中曾经用了一节来讨论为什么使用Exploitation &amp;amp; Exploration (E &amp;amp; E)结果可能依然不能“免俗”。其实，E &amp;amp; E是推荐系统里很有意思，但也非常有争议的一个算法。一方面，大家都基本明白这类算法的目的，每年有很多相关论文发表。另一方面，这是工业界对于部署这类算法非常谨慎，有的产品经理甚至视之为“洪水猛兽”。这篇文章就是要分析一下导致这个现象的一些因素。&lt;/p&gt;

&lt;h2 id=&quot;走一步看一步的策略&quot;&gt;走一步看一步的策略&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;这里再简单阐述一下什么是E &amp;amp; E。简单来说，就是我们在优化某些目标函数的时候，从一个时间维度来看，当信息不足或者决策不确定性（Uncertainty）很大的时候，我们需要平衡两类决策：&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;选择现在可能最佳的方案&lt;/li&gt;
  &lt;li&gt;选择现在不确定的一些方案，但未来可能会有高收益的方案&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;在做这两类决策的过程中，我们也逐渐对所有决策的不确定性不断更新不断加以新的认识。于是，&lt;strong&gt;最终&lt;/strong&gt;，从时间的维度上来看，我们在不确定性的干扰下，依然能够去&lt;strong&gt;优化&lt;/strong&gt;目标函数。&lt;/p&gt;

&lt;p&gt;也就是说，E &amp;amp; E可以看做是一个&lt;em&gt;优化过程&lt;/em&gt;，需要多次迭代才能找到比较好的方案。&lt;/p&gt;

&lt;h2 id=&quot;e--e的应用历史&quot;&gt;E &amp;amp; E的应用历史&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;早期把E &amp;amp; E应用于新闻推荐系统的文章（比如&lt;sub&gt;[1,2,4]&lt;/sub&gt;）主要关注于Yahoo Today Module（下图中间的模块）这一产品，这也基本上是最早E &amp;amp; E出现在互联网应用的尝试，目的是为了优化点击率（CTR）。而更早一些的奠基性的文章（如&lt;sub&gt;[3]&lt;/sub&gt;）则是在广告的数据集上展示的实验结果。&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/yahoo_today.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;Yahoo Today Module其实为E &amp;amp; E提供了一些很多学者和工业界人士忽视了的条件和成功因素。如果不考虑这些因素，鲁莽得使用这些文献相似的算法到其他场景，这可能产生很差的效果。那么是哪些因素呢？主要由两点：&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;&lt;strong&gt;相对少量的优质资源&lt;/strong&gt;： Yahoo Today Module每天的Content Pool其实并不大。这里面都是网站编辑精选了的大概100篇文章。这些文章原本的质量就非常高。无论是这里面的任何一组，用户体验都没有明显变差。Content Pool每天都人为更换。&lt;/li&gt;
  &lt;li&gt;&lt;strong&gt;非常大的用户量&lt;/strong&gt;：有亿万级的用户可能最终是从算法&lt;em&gt;随机&lt;/em&gt;产生的文章排序中选择了阅读的文章。然而，因为用户数量巨大，所以算法就相对比较容易Converge到稳定的方案。也就是前面讲的，优化CTR的状态。&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;正因为有了（1）和（2），Deepak他们享受了在后来学者们所无法想象的“奢侈”，比如运行Epsilon-Greedy这种简单粗暴的E &amp;amp; E算法，甚至是&lt;strong&gt;完全随机&lt;/strong&gt;显示新闻，收集到了很多&lt;em&gt;无偏&lt;/em&gt;（Unbiased）的数据，为很多学术工作奠定了数据基础。时至今日，也有很多后续学者基于Yahoo Today Module的随机数据进行算法改进。&lt;/p&gt;

&lt;blockquote&gt;
  &lt;p&gt;Deepak Agarwal，现任LinkedIn VP Of Engineering，主管Machine Learning和Relevance，是早年Yahoo推荐系统的缔造者之一，也是推荐系统的学术权威之一。其著作《Statistical Methods for Recommender Systems》是初学者必不可少的入门教材。&lt;/p&gt;
&lt;/blockquote&gt;

&lt;blockquote&gt;
  &lt;p&gt;Bee-Chung Chen，现任LinkedIn Senior Staff Software Engineer，其PhD导师Raghu Ramakrishnan现在是微软的CTO for Data和Technical Fellow（此人是早期知识图谱Knowledge Graph概念的推崇者）。Bee-Chung是Deepak在Yahoo年代的老部下，并且追随其到LinkedIn。他们是很多工作的共同作者。&lt;/p&gt;
&lt;/blockquote&gt;

&lt;blockquote&gt;
  &lt;p&gt;Lihong Li，现任微软研究院资深研究员。其在Yahoo的一系列有关Contextual Multi-Armed Bandit以及Thompson Sampling的文章奠定了其在这个领域的权威位置。他在WSDM 2015做的关于如何连接线下和线上系统的评估的讲座&lt;sub&gt;[5]&lt;/sub&gt;，是非常有价值的学术资料。&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;没有了这两条因素，Deepak的解决方案可能都没法在当时的Yahoo施行。原因很简单，如果资源良莠不齐，如果资源数量非常大，那么在仅有的几个展示位置，优质资源显示的可能性在短期内就会比较小（因为系统对于大多数的资源还有很高的不确定性，需要Explore）。而由于优质资源显示得少了，用户就会明显感受到体验的下降，直接可能就是更倾向于不点击甚至放弃使用产品。于是用户不Engage这样的行为又进一步减缓了系统学习资源的不确定性的速度。这时也许现在的亿万级用户数都没法满足学习所有资源的用户数量（毕竟所有用户只有一部分会落入Exploration）。&lt;/p&gt;

&lt;p&gt;Deepak后来在LinkedIn推了相似的思路&lt;sub&gt;[6]&lt;/sub&gt;，但是为了模拟Today Module的这些条件，则是对用户的内容流里的数据进行了大规模的过滤。这样只有少数的信息符合高质量的要求，并且能够在用户数允许的情况下Explore到合适的解决方案。&lt;/p&gt;

&lt;h2 id=&quot;e--e的产品部署难点&quot;&gt;E &amp;amp; E的产品部署难点&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;我们在上一节探讨了E &amp;amp; E的早期产品历史。这一节，我们来讲一下E &amp;amp; E的产品部署难点。这些难点是普遍高于具体E &amp;amp; E算法选择（比如选某一个UCB或者某一个Thompson Sampling)的产品工程解决方案的抉择。为了便于讨论，我们把文献里所有E &amp;amp; E算法整体叫做“Random”简称R算法，而把不做E &amp;amp; E的算法叫做“Deterministic”简称D算法。这里面的假设是，D算法比较静态，能够产生高质量&lt;strong&gt;一致性&lt;/strong&gt;的内容。这里的一致性是指用户在短时间内的用户体验比较稳定，不会有大幅度的界面和内容变化。相反，R算法整体来说是不确定性比较大，用户体验和产生的内容可能会有比较大的波动。&lt;/p&gt;

&lt;h3 id=&quot;难点一如何上线测试&quot;&gt;难点一：如何上线测试&lt;/h3&gt;
&lt;hr /&gt;
&lt;p&gt;这看上去不应该是难点，但实际上需要额外小心。传统E &amp;amp; E文献，只是把问题抽象为每一次访问需要做一个决策的选择。然而，文献却没有说，这些访问是否来自同一个用户。那么，理论上，E &amp;amp; E应该对所有的访问不加区别，不管其是否来自同一个用户。用我们这篇文章的术语来说，就是所有的流量都做R算法。虽然理论上这样没有问题，但实际上，用户体验会有很大的差别。特别是一些推荐网站，用户希望自己前后两次对网站的访问保持&lt;strong&gt;一致性&lt;/strong&gt;。如何不加区分得做R，很可能对于同一个用户来说，两次看见的内容迥异。这对用户熟悉产品界面，寻找喜爱的内容会产生非常大的障碍。&lt;/p&gt;

&lt;p&gt;那么，我们对绝大部分用户做D，对另外一（小）部分用户做R，这样会好一些吗？这其实就是用“牺牲”少部分用户的代价来换取绝大多数人的体验一致性。这样实现也是最直观的，因为很多在线系统的A/B测试系统是根据用户来进行逻辑分割的。也就是说，某一部分用户会进入一个Bucket，而另一批用户会进入另外一个Bucket。按用户来做D &amp;amp; R可以很容易和Bucket System一致起来，方便部署。当然，这样做也是有潜在风险的。那就是，这部分老做R的用户，在当了别人的小白鼠以后，很可能永远放弃使用产品。&lt;/p&gt;

&lt;p&gt;另外，我们还需要考虑“学习流程”（Learning Procedure）如何搭建。传统的E &amp;amp; E其实是把“学习流程”搭建在同一批流量上。也就是，模型更新所依赖的数据来自于同样一批流量。融合上面的讨论以后，我们可以总结出下面这些方案：&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;全部流量做R，全部流量做学习。（方案A）&lt;/li&gt;
  &lt;li&gt;一部分用户做D，其他用户做R。更新D的数据来自D，更新R的数据来自R。（方案B）&lt;/li&gt;
  &lt;li&gt;一部分用户做D，其他用户做R。更新D的数据来自D+R，更新R的数据来自R。（方案C）&lt;/li&gt;
  &lt;li&gt;一部分用户做D，其他用户做R。更新D的数据来自D+R，更新R的数据来自D+R。&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;最后一个方案其实是逻辑上不对的。因为R本身要求算法的回馈是来自R的决策，而使用D+R来学习模型，就产生了R的反馈信息被“污染”的现象。所以，合理的选择只能是前三种方案中的一种。&lt;/p&gt;

&lt;p&gt;如何选择一个好的部署模式，目前并没有公开的文献以及比较能够通用的方案。这方面其实是一个值得思考的研究课题。&lt;/p&gt;

&lt;h3 id=&quot;难点二如何评测&quot;&gt;难点二：如何评测&lt;/h3&gt;
&lt;hr /&gt;
&lt;p&gt;对现代推荐系统（以及很多类似系统）来说，在线系统的评测，也就是说如何衡量一个算法或者一个功能的好坏，往往依赖于复杂的A/B测试系统。这里的逻辑很简单，那就是，把一群人分为&lt;strong&gt;相等&lt;/strong&gt;的两份（可以扩展到多份），一部分看A系统结果，另一部分人看B系统结果，然后根据一些用户指标（比如点击率）来决定究竟是A系统好还是B系统。也就是说，A/B测试系统是按照人群来分的。对于同一个人来说，在某一段时间内，一般是只能看到A&lt;strong&gt;或者&lt;/strong&gt;B系统，但&lt;strong&gt;不&lt;/strong&gt;是&lt;strong&gt;都&lt;/strong&gt;能看见。&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/ab_testing.png&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;我们来讨论一下前一节的几个方案在评测方面的利弊。方案A要求全部流量做R，于是这个方案，依照定义，就没法和其他D作比较，只能两种不同的R相比。由于R对于用户体验上来说一般是有损失的，只能比较R和R，造成了没法量化整体系统的用户体验损失量，这可能是无法接受的一种局面。&lt;/p&gt;

&lt;p&gt;方案B的设置很自然，可以比较单组或者多组D和R的差别，互相没有影响。坏处当然就是所有D部分的用户都没有Exploration，而R的部分可能流失用户。方案C没法直接评测，因为一个Bucket的D受到了R的影响。两个Bucket不独立。我们至少需要四个Bucket。一组Bucket是D1+R1，另外一组Bucket是D2+R2。在比较Bucket Performance的时候，我们需要综合比较(D1+R1)和（D2+R2）。这当然对A/B Testing系统有了较高的要求。&lt;/p&gt;

&lt;p&gt;另一方面，对于方案B和方案C来说，R只运行在一部分用户上，模型可能需要很长的时间学习，甚至在规定的时间内没法完成学习。这就需要加大R的部分。然而加大R，则可能流失用户。于是，这里的决策核心就是D部分留住的老用户加上扩展的新用户，能否大大超过R部分流失的用户。&lt;/p&gt;

&lt;h3 id=&quot;难点三如何平衡产品&quot;&gt;难点三：如何平衡产品&lt;/h3&gt;
&lt;hr /&gt;
&lt;p&gt;通过前面两个难点可以看出，E &amp;amp; E&lt;strong&gt;几乎一定&lt;/strong&gt;会导致产品的用户体验下降，至少在短期内。如何弥补这一点，技术上其实比较困难。比如做Deepak那样的过滤是一种思路，那就是只在优质内容里Explore。当然，有人会说，这样其实也没有多大的意义。然而，一旦把质量的闸门打开了，那就会对用户体验带来很大的影响。&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/pm.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;这也是很多产品经理对于E &amp;amp; E非常谨慎的原因。能不做就不做。而且，在牺牲了用户体验的结果后，E &amp;amp; E所带来的好处其实很难评测，这主要是线上产品的评测机制和评测原理所决定的。目前还没有比较统一的解决方案。如何能够做到“用户友好型”E &amp;amp; E呢？&lt;/p&gt;

&lt;p&gt;这里面可以有两种思路：&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;不是所有人群的所有访问都适合做R。但是和传统的E &amp;amp; E不同的是，做“反向E &amp;amp; E”。也就是说，我们只针对非常Engaged的人做Exploration，而并不是新用户或者是还没有那么Engaged的人群。这个思路是和现在E &amp;amp; E完全相反，但是更加人性化。&lt;/li&gt;
  &lt;li&gt;夹带“私货”。也就是更改E &amp;amp; E的算法，使得高质量的内容和低质量的内容能够相伴产生，并且高质量的内容更有几率排在前面。这样用户体验的损失可控。这个思路我们在&lt;sub&gt;[7]&lt;/sub&gt;里有所尝试，效果不错。&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;其实，E &amp;amp; E和产品的结合点应该是工程和研究的重点，但很遗憾的是，碍于数据和其他方面的因素，这方面的研究工作几乎没有。&lt;/p&gt;

&lt;h2 id=&quot;可以挖掘的问题&quot;&gt;可以挖掘的问题&lt;/h2&gt;
&lt;hr /&gt;
&lt;p&gt;前面说了E &amp;amp; E在工程部署以及产品上的难点。这里再提及一下E &amp;amp; E可以挖掘的方向：&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;“收集数据”，作为Causal Inference中消除现在产品的“偏见”（Bias）的重要步骤&lt;sub&gt;[8,9]&lt;/sub&gt;，这方面的工作还比较少，还没有在推荐系统里广泛使用。&lt;/li&gt;
  &lt;li&gt;用户友好型的E &amp;amp; E方案（前面已经提及了），能够在尽可能少的情况下打扰用户，学到尽可能多的信息。这方面目前不是学术圈的重点，但却是工程产品方面非常需要的解决方案。&lt;/li&gt;
&lt;/ol&gt;

&lt;h2 id=&quot;结论&quot;&gt;结论&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;本篇文章讨论了推荐系统中Exploitation和Exploration的使用，分享了这方面的历史，探讨了工程和产品的技术难点，希望这篇文章能够为相关方向抛砖引玉。&lt;/p&gt;

&lt;h2 id=&quot;参考文献&quot;&gt;参考文献&lt;/h2&gt;
&lt;hr /&gt;
&lt;ol&gt;
  &lt;li&gt;Lihong Li, Wei Chu, John Langford, and Robert E. Schapire. &lt;a href=&quot;http://www.research.rutgers.edu/~lihong/pub/Li10Contextual.pdf&quot;&gt;&lt;strong&gt;A Contextual-Bandit Approach to Personalized News Article Recommendation&lt;/strong&gt;&lt;/a&gt;. In Proceedings of WWW 2010.&lt;/li&gt;
  &lt;li&gt;Deepak Agarwal, Bee-Chung Chen, Pradheep Elango. &lt;a href=&quot;http://ieeexplore.ieee.org/xpl/login.jsp?tp=&amp;amp;arnumber=5360225&quot;&gt;&lt;strong&gt;Explore/Exploit Schemes for Web Content Optimization&lt;/strong&gt;&lt;/a&gt;. In Proceedings of ICDM 2009.&lt;/li&gt;
  &lt;li&gt;John Langford, Alexander Strehl, and Jennifer Wortman. &lt;a href=&quot;http://dl.acm.org/citation.cfm?doid=1390156.1390223&quot;&gt;&lt;strong&gt;Exploration Scavenging&lt;/strong&gt;&lt;/a&gt;. In Proceedings of ICML 2008.&lt;/li&gt;
  &lt;li&gt;Lihong Li, Wei Chu, John Langford, and Xuanhui Wang. &lt;a href=&quot;http://www.gatsby.ucl.ac.uk/~chuwei/paper/wsdm11.pdf&quot;&gt;&lt;strong&gt;Unbiased Offline Evaluation of Contextual-Bandit-Based News Article Recommendation Algorithms&lt;/strong&gt;&lt;/a&gt;. In Proceedings of WSDM 2011.&lt;/li&gt;
  &lt;li&gt;Lihong Li. &lt;a href=&quot;http://research.microsoft.com/pubs/240388/tutorial.pdf&quot;&gt;&lt;strong&gt;Offline Evaluation and Optimization for Interactive Systems&lt;/strong&gt;&lt;/a&gt;。 In Proceedings of WSDM 2015.&lt;/li&gt;
  &lt;li&gt;Deepak Agarwal. &lt;a href=&quot;http://www.ueo-workshop.com/wp-content/uploads/2013/10/UEO-Deepak.pdf&quot;&gt;&lt;strong&gt;Recommending Items to Users: An Explore/Exploit Perspective&lt;/strong&gt;&lt;/a&gt;. In Proceedings of the 1st Workshop on User Engagement Optimization at CIKM 2013.&lt;/li&gt;
  &lt;li&gt;Liangjie Hong and Adnan Boz. &lt;a href=&quot;http://arxiv.org/abs/1604.03506&quot;&gt;&lt;strong&gt;An Unbiased Data Collection and Content Exploitation/Exploration Strategy for Personalization&lt;/strong&gt;&lt;/a&gt;. ArXiv. 2016.&lt;/li&gt;
  &lt;li&gt;Lihong Li, Jin Young Kim, and Imed Zitouni. &lt;a href=&quot;http://dl.acm.org/citation.cfm?id=2685311&quot;&gt;&lt;strong&gt;Toward Predicting the Outcome of an A/B Experiment for Search Relevance&lt;/strong&gt;&lt;/a&gt;. In Proceedings of WSDM 2015.&lt;/li&gt;
  &lt;li&gt;Tobias Schnabel, Adith Swaminathan, Ashudeep Singh, Navin Chandak, Thorsten Joachims.
&lt;a href=&quot;http://arxiv.org/abs/1602.05352&quot;&gt;&lt;strong&gt;Recommendations as Treatments: Debiasing Learning and Evaluation&lt;/strong&gt;&lt;/a&gt;. ArXiv. 2016.&lt;/li&gt;
&lt;/ol&gt;
</content>
 </entry>
 
 <entry>
   <title>个性化推荐是不是伪命题</title>
   <link href="http://column.hongliangjie.com/%E4%B8%AA%E6%80%A7%E5%8C%96,%E6%8E%A8%E8%8D%90%E7%B3%BB%E7%BB%9F/2016/04/07/personalization-or-not/"/>
   <updated>2016-04-07T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E4%B8%AA%E6%80%A7%E5%8C%96,%E6%8E%A8%E8%8D%90%E7%B3%BB%E7%BB%9F/2016/04/07/personalization-or-not</id>
   <content type="html">&lt;p&gt;最近，有一位网友在微博上说，&lt;a href=&quot;http://weibo.com/1830516311/Dp4Vs81ih?from=page_1005051830516311_profile&amp;amp;wvr=6&amp;amp;mod=weibotime&amp;amp;type=comment&quot;&gt;推荐是不是个伪命题？连续几天试用了据说很好的某头条，某资讯以及某快报，感觉逃脱不了看什么就是什么的套路&lt;/a&gt;。也有人说，这是Exploitation &amp;amp; Exploration出了问题，没有很好得Exploration导致的结果。那么，个性化推荐到底是不是伪命题呢？为什么很多推荐系统过了一段时间以后就老是推荐类似的东西呢？本篇文章就要尝试分析和探讨这个“千篇一律”的问题。&lt;/p&gt;

&lt;h2 id=&quot;推荐是为了预测用户喜好的物品吗&quot;&gt;推荐是为了预测用户喜好的物品吗&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;要知道个性化推荐是不是伪命题，我们就必须从个性化推荐的&lt;strong&gt;目的&lt;/strong&gt;说起。一个通常意义上的推荐系统，顾名思义，就是要给用户推荐可能会交互（包括购买、点击、点赞等等）并且可能喜爱的物品，比如Amazon的商品、Netflix的电影、LinkedIn的工作以及Yahoo的新闻等。当然，这只是一个非常肤浅的定义。我们等会儿会看到这个定义的问题。&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/netflix.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;自从Netflix Prize以来，推荐系统的研究和生产实际，基于以上这个关于推荐的肤浅定义，把整个系统的模型简化成了——预测用户对于某个事物的喜爱，也就是人们常说的Rating Prediction的问题&lt;sub&gt;[3]&lt;/sub&gt;。Collaborative Filtering，特别是基于Matrix Factorization&lt;sub&gt;[2]&lt;/sub&gt;和Latent Factor Model&lt;sub&gt;[1]&lt;/sub&gt;的各种方法及其变种大行其道，一时间似乎成为了推荐系统的代名词。于是，很多实际系统的设计者和开发着，不管自己产品的真实定位究竟如何，都选择利用协同过滤来打造自己的推荐系统。&lt;/p&gt;

&lt;p&gt;协同过滤是否有效呢？答案是肯定的。当然，这有一个巨大的前提，那就是，如果我们的产品，真的采用这个推荐的肤浅定义，仅仅注重于推荐用户是否喜欢的东西。协同过滤，辅佐以Machine Learning的很多手段（比如Tree-based Models)，常常能够在Rating Prediction这个问题上有不俗的成绩。然而，往往用户在使用产品一段时间以后就会得出微博上那位网友的体验。产品经理也会常常陷入困境，不知道如何改进产品。&lt;/p&gt;

&lt;p&gt;注意，有一些Rating Prediction的变种问题，其实质还是在优化用户对某一类事物的喜爱。比如，不仅仅预测单个物品的评分，而是看用户在一个物品列表中选择了哪些物品（代表作&lt;sub&gt;[7]&lt;/sub&gt;）。也就是看用户是否更&lt;strong&gt;偏好&lt;/strong&gt;某些物品。尽管这样似乎更准确抓住了推荐问题的产品定义，但依然没有能够摆脱优化用户喜好所带来的问题。&lt;/p&gt;

&lt;p&gt;实际上，任何以用户喜好为目标的推荐系统，不管优化对象是简单的点击率（Click-Through-Rate）还是驻留时间（Dwell-Time）&lt;sub&gt;[4]&lt;/sub&gt;，抑或是上面提到的评分，都很难逃脱上述问题。那么为什么优化用户喜好就会带来上述问题呢？&lt;/p&gt;

&lt;p&gt;原因很直观，要想优化用户喜好，那就必然强调用户的历史行为。协同过滤或者是机器学习导向的算法，都试图充分挖掘单个用户以及群体用户的喜好，并且加以推崇到极致（Optimization)。打个比方，如果你才查看了Amazon上的某款最新的相机，一般的推荐系统就会显示很多相似的相机或者其他各种相机配套产品，并希望最大化这&lt;strong&gt;单次&lt;/strong&gt;点击（或者查询）的“收益”。在这些系统看来，既然你已经“表达了”对相机兴趣，那么系统就要抓住这么一个机会。如果你不单单是偶然看了一次相机，而是研究了一小会儿以后，推荐系统就会认为你已经表达了很“&lt;strong&gt;强烈&lt;/strong&gt;”的对相机的喜好，那好，让你的整个屏幕都充满相机吧。也许有人可能会想到Discount用户短期内的一些行为这种做法，而对用户长期的一些行为更加关注（比如&lt;sub&gt;[8]&lt;/sub&gt;）。这种方法也许可以缓解“满屏相机”的现象，但是很难从根本上解决问题，况且这个Discount的参数本身也很难调试。于是，长期优化用户喜好，在绝大多数情况下，用户就会产生Filtering Bubble的效果，也就是说，用户自己只能看见自己喜欢的东西，并且不断强化。而从整个系统来讲，很难跳出推荐的东西千篇一律的效果。&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/filter_bubble.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;当然，这里还有一个更加严重的问题，这也是新闻推荐经常容易出现的问题。那就是，一些“资深用户”（Engaged Users），因为比常人更多得和一个系统交互，看了各种各样的新闻，有时可能完全不是因为喜欢，而是消磨时间或者随便看着玩儿，强化优化用户喜好的推荐系统很可能无法分辨这样的行为。过度优化“喜好”，可能带来的结果就是系统误认为这些用户什么都喜欢。我们下面还会深入讨论这个问题。&lt;/p&gt;

&lt;p&gt;只优化用户喜好的&lt;strong&gt;根本问题&lt;/strong&gt;，其实是&lt;strong&gt;忽略了大视野&lt;/strong&gt;（Big Picture）。那么，什么是推荐系统的大视野呢？这里先卖一个关子，我们到文章的最后再来揭晓。&lt;/p&gt;

&lt;h2 id=&quot;看一步走一步的优化策略&quot;&gt;看一步走一步的优化策略&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;上一节我们剖析了优化用户喜好的问题。熟悉推荐系统的人可能会说，这有很成熟的解决方案啊，Exploitation &amp;amp; Exploration（E &amp;amp; E）就是专门干这个的。那么，E &amp;amp; E是不是就解决问题了呢？&lt;/p&gt;

&lt;p&gt;我们先来看看E &amp;amp; E究竟是干什么的。E &amp;amp; E的核心思想&lt;sub&gt;[5]&lt;/sub&gt;是，我们在优化某些目标函数的时候，从一个时间维度来看，当信息不足或者决策不确定性（Uncertainty）很大的时候，我们需要平衡两类决策：&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;选择现在可能最佳的方案&lt;/li&gt;
  &lt;li&gt;选择现在不确定的一些方案，但未来可能会有高收益的方案&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;在做这两类决策的过程中，我们也逐渐对所有决策的不确定性不断更新不断加以新的认识。于是，&lt;strong&gt;最终&lt;/strong&gt;，从时间的维度上来看，我们在不确定性的干扰下，依然能够去&lt;strong&gt;优化&lt;/strong&gt;目标函数。&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/exploration.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;举个例子，比如一个用户看新闻，如果这个用户只点击娱乐类的新闻，作为推荐系统而言，虽然我们知道下面接着显示娱乐新闻可能是比较不错的选择，但是&lt;strong&gt;完全忽视&lt;/strong&gt;显示其他类别新闻则显得整个系统高估了自己对用户的认知。于是，一个比较现代的推荐系统，往往会兼顾一些其他类别，看看用户是否对其他类别是不是也有兴趣。这就是E &amp;amp; E的典型案例。&lt;/p&gt;

&lt;p&gt;然而，E &amp;amp; E并不能解决我们之前提到的“千篇一律”的问题。原因倒不是说E &amp;amp; E本身可能会有什么问题，原因的核心还是，我们是否&lt;strong&gt;优化用户喜好&lt;/strong&gt;。也就是说，即便有E &amp;amp; E，只要我们的目标函数是用户喜好及其变种，那么，整个系统依然会&lt;strong&gt;收敛&lt;/strong&gt;（Converge）到“满屏相机”的状态。因为，也许用户&lt;em&gt;就是&lt;/em&gt;对相机喜好最大。那系统在Explore了一些其他类别的东西之后，发现用户没有太大兴趣，于是就“安全”得觉得，可以放心现实用户喜欢的类别了。&lt;/p&gt;

&lt;p&gt;也就是说，E &amp;amp; E没有错，错的是我们要优化用户喜好这件事情。或者换句话说，我们如果知道，一个用户真心只喜欢相机，而且在尝试给用户看了各种其他类别以后，系统是不是就以非常大的概率显示相机呢，而基本或者完全忽略其他类型的物品呢？&lt;/p&gt;

&lt;p&gt;另外，E &amp;amp; E在真实产品中应用还有一些实际的难度。很多公司的产品经理并不一定愿意实现这个功能。当然，这是另外一个话题了。&lt;/p&gt;

&lt;h2 id=&quot;复杂的人类行为&quot;&gt;复杂的人类行为&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;我们在第一节提到了一点用户行为的不确定性和复杂性（短期行为和长期行为的区别）。这里我们再讨论一下因为复杂的人类行为给推荐系统所带来的麻烦。也就是说，推荐系统目前只能“千篇一律”也部分因为建模水平有限。&lt;/p&gt;

&lt;p&gt;还是以新闻推荐为例子，用户在使用产品的时候，显然是有一些潜在的&lt;em&gt;意图&lt;/em&gt;（Intents）和使用习惯。比如，有一些用户，习惯于阅读所有的排在重要版面的新闻，&lt;strong&gt;不管&lt;/strong&gt;这些新闻是否真的激起用户的兴趣。这类似于搜索问题（Search）中的&lt;em&gt;位置偏见&lt;/em&gt;（Position Bias）——用户以为排在前面的就是重要的，就是需要他们阅读的。盲目认为用户点击了的就是用户喜欢的，往往是导致“越来越富”（Rich-Get-Richer）现象的一个简单原因。&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/user_behaviors.png&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;当然，简单尝试去除这种偏见，也需要注意到，的确是有用户是习惯&lt;strong&gt;读完所有重要新闻&lt;/strong&gt;的。也就是说即便是去除偏见，粗看，用户的行为依然杂乱无章，今天看伊朗问题，明天看世界杯，后天看巴西政府丑闻，大后天看Kim Kardashian，貌似喜欢所有的话题和类别。这里的核心问题还是，只对喜好建模，就无法检测到用户的行为在“目的性”这一维度的差异性，于是误判用户喜欢很多类别的事物。这类的例子其实有很多，比如在奥斯卡季，用户看了最新的一批奥斯卡获奖电影，涵盖很多类别，但这并不代表用户真的就喜欢这些类别。&lt;/p&gt;

&lt;p&gt;同样在“意图”上容易误判的是有突发事件的时候，比如四年一度的世界杯（或者其他时间）。很多用户在短期内阅读了大量足球信息，而大多数这类用户都是平时&lt;strong&gt;完全&lt;/strong&gt;对足球没有兴趣的人。这种在短时间内&lt;strong&gt;过度&lt;/strong&gt;对于某一个类别新闻进行信息消费（Content Consumption），会对以喜好为基础的推荐系统造成极大困扰。系统很难&lt;em&gt;忘却&lt;/em&gt;这些用户的行为，或者说系统很难甄别那些该被忘掉。&lt;/p&gt;

&lt;p&gt;要抓住用户的行为，理解用户的意图，那么就对推荐系统的构建提出了更高要求。即便是优化用户喜好，为了评测系统是否能够区分短期、长期喜好和不同的阅读习惯，对数据的采集，系统的评价体系以及最终模型的更新都提出了更高的要求。&lt;/p&gt;

&lt;p&gt;当然，这一节我们是要说明，“千篇一律”问题的复杂性在于，我们需要判断是否是现有模型和系统对于哪怕就是优化用户喜好也没有做好。&lt;/p&gt;

&lt;h2 id=&quot;巧妇难为无米之炊&quot;&gt;巧妇难为无米之炊&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;在最终讨论“满屏相机”问题的解决方案之前，我们再来看一个可以很容易侦测到的问题，这也是经常导致一个推荐结果“千篇一律”的罪魁祸首之一。那就是，系统的物品池（Item Pool）太小。换句话说，就是根本没什么东西可以推荐。&lt;/p&gt;

&lt;p&gt;这个问题虽然说起来非常容易理解，但却是很多内容推荐平台（比如新闻推荐、视频推荐）的核心短板，也就是缺乏优质内容。比方说，用户喜欢看科幻文章，但遗憾的是，整个平台也许就只有几篇科幻文章，于是系统没法给用户提供更好的推荐。自然，用户也就只能反复看见剩下的东西在屏幕上占据显著的位置。&lt;/p&gt;

&lt;p&gt;然后这个问题说起来容易，真正要去着手解决却很麻烦。核心难点是，茫茫互联网，到哪里去获取优质内容。这个问题，我们留到以后再来探讨。&lt;/p&gt;

&lt;h2 id=&quot;推荐系统的大视野&quot;&gt;推荐系统的大视野&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;在卖了一个大关子以后，我们在最后这节讨论一下如何解决“千篇一律”的核心问题，那就是把握住推荐系统的&lt;em&gt;视野&lt;/em&gt;。&lt;/p&gt;

&lt;p&gt;推荐系统，或者说任何用户系统，的视野，就是如果把为用户提供服务（这里是推荐物品）作为&lt;strong&gt;一个环节&lt;/strong&gt;，&lt;strong&gt;和其他子系统协同来达到整个产品生态系统&lt;/strong&gt;的&lt;strong&gt;健康&lt;/strong&gt;。这里的核心的核心，是整个产品生态系统的健康。&lt;/p&gt;

&lt;p&gt;&lt;img src=&quot;/assets/system_health.jpg&quot; alt=&quot;&quot; /&gt;&lt;/p&gt;

&lt;p&gt;什么是推荐系统所在的整个生态系统的健康？以新闻平台来说，这里涉及：&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;单个用户是否能够长期活跃，单个用户是否能在这里得到帮助，得到成长&lt;/li&gt;
  &lt;li&gt;用户族群（Community）是否得到保护，是否促进了不同形态的用户群的增长&lt;/li&gt;
  &lt;li&gt;信息提供商是否能够通过平台得到自己的收益（比如，投放的信息获得了广告收益；增加了知名度等）&lt;/li&gt;
  &lt;li&gt;信息提供商的多样性，良性的竞争关系。（比如不是单个信息来源占据了绝大多数的信息来源等）&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;还有很多很多。一旦把这些因素考虑进系统，并且加以量化，融合进目标函数（比如，一个简化版的代表作&lt;sub&gt;[6]&lt;/sub&gt;），我们就可以清晰得看到，优化这么一个目标，至少在理论上和实践中，都很难提供“千篇一律”的推荐结果，原因就是那样的结果，会最终流失用户、信息提供商，最终让产品僵化。&lt;/p&gt;

&lt;p&gt;也可以这么说，“千篇一律”的问题核心，简单说来就是，优化目标过于简单，没有把产品的健康考虑进去。&lt;/p&gt;

&lt;p&gt;说到这里，貌似这个问题已经“解决”了，其实不然，原因是，如何定义出一个健康指标，不仅仅是一个技术活儿，甚至是一个艺术活儿，这里就不仅仅是数据科学以及机器学习的范畴了，我们以后再讨论相关话题。&lt;/p&gt;

&lt;h2 id=&quot;结论&quot;&gt;结论&lt;/h2&gt;
&lt;hr /&gt;

&lt;p&gt;本篇文章讨论了个性化推荐不是伪问题，而是一个非常深的产品问题，我们需要考虑时时刻刻优化产品的全局健康。&lt;/p&gt;

&lt;h2 id=&quot;参考文献&quot;&gt;参考文献&lt;/h2&gt;
&lt;hr /&gt;
&lt;ol&gt;
  &lt;li&gt;Deepak Agarwal and Bee-Chung Chen. 2009. &lt;strong&gt;Regression-based latent factor models&lt;/strong&gt;. In Proceedings of the 15th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining. ACM, New York, NY, USA, 19-28.&lt;/li&gt;
  &lt;li&gt;Yehuda Koren. 2010. &lt;strong&gt;Factor in the neighbors: Scalable and accurate collaborative filtering&lt;/strong&gt;. ACM Transactions on Knowledge Discovery from Data 4, 1, Article 1 (January 2010), 24 pages.&lt;/li&gt;
  &lt;li&gt;Robert M. Bell and Yehuda Koren. 2007. &lt;strong&gt;Lessons from the Netflix prize challenge&lt;/strong&gt;. ACM SIGKDD Explorations Newsletter - Special Issue on Visual Analytics 9, 2 (December 2007), 75-79.&lt;/li&gt;
  &lt;li&gt;Xing Yi, Liangjie Hong, Erheng Zhong, Nanthan Nan Liu, and Suju Rajan. 2014. &lt;strong&gt;Beyond clicks: dwell time for personalization&lt;/strong&gt;. In Proceedings of the 8th ACM Conference on Recommender Systems. ACM, New York, NY, USA, 113-120.&lt;/li&gt;
  &lt;li&gt;Lihong Li, Wei Chu, John Langford, and Robert E. Schapire. 2010. &lt;strong&gt;A contextual-bandit approach to personalized news article recommendation&lt;/strong&gt;. In Proceedings of the 19th International Conference on World Wide Web. ACM, New York, NY, USA, 661-670.&lt;/li&gt;
  &lt;li&gt;Deepak Agarwal, Bee-Chung Chen, Pradheep Elango, and Xuanhui Wang. 2011. &lt;strong&gt;Click shaping to optimize multiple objectives&lt;/strong&gt;. In Proceedings of the 17th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining. ACM, New York, NY, USA, 132-140.&lt;/li&gt;
  &lt;li&gt;Alexandros Karatzoglou, Linas Baltrunas, and Yue Shi. 2013. &lt;strong&gt;Learning to rank for recommender systems&lt;/strong&gt;. In Proceedings of the 7th ACM Conference on Recommender Systems. ACM, New York, NY, USA, 493-494.&lt;/li&gt;
  &lt;li&gt;Amr Ahmed, Yucheng Low, Mohamed Aly, Vanja Josifovski, and Alexander J. Smola. 2011. &lt;strong&gt;Scalable distributed inference of dynamic user interests for behavioral targeting&lt;/strong&gt;. In Proceedings of the 17th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining. ACM, New York, NY, USA, 114-122.&lt;/li&gt;
&lt;/ol&gt;
</content>
 </entry>
 
 <entry>
   <title>我为什么开设这个专栏</title>
   <link href="http://column.hongliangjie.com/%E7%AB%99%E5%8A%A1/2016/04/05/start-column/"/>
   <updated>2016-04-05T00:00:00-07:00</updated>
   <id>http://column.hongliangjie.com/%E7%AB%99%E5%8A%A1/2016/04/05/start-column</id>
   <content type="html">&lt;p&gt;经过一段时间的思考，我决定开一个技术、管理和团队的专栏，分享和探讨关于大数据、人工智能（AI）及机器学习（Machine Learning）的话题，以及这些相关技术的行业思考。在已经有不少优质内容（包括博客、微信公众号）的情况下，我希望这个专栏能够更加专注、专业，少一些关注个别技术的细节，多一些对数据在一个生态系统中的把握以及行业动态的分析。&lt;/p&gt;

&lt;p&gt;在接下来的文章中，我准备着重分享和探讨如下这些方面的内容：&lt;/p&gt;

&lt;ol&gt;
  &lt;li&gt;机器学习、人工智能和大数据相关领域的核心技术，如何应用这些核心技术到生产实践中。解析从单一算法到产品流程的距离和取舍（Compromise）。&lt;/li&gt;
  &lt;li&gt;什么是数据驱动(Data-Driven)的团队，如何构建具有核心竞争力的大数据团队。&lt;/li&gt;
  &lt;li&gt;如何设计和开发智能型数据驱动产品，作为产品经理，如何在产品功能和数据驱动之间寻求动态平衡。&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;正如前面提及的一样，第一方面已经有不少优秀内容涵盖。这个专栏的特色则是寻求如何在学术圈的最新研究成果（State-of-the-Art）和工业界的标准流程中建立桥梁，在浩如烟海的相关文献中，找到最适合的算法和模型。&lt;/p&gt;

&lt;p&gt;第二和第三方面则是这个专栏重点想提及的部分。那就是如何转变现有的团队建设和产品开发思维，能够从数据驱动的角度，能够从数据工程的角度来看待问题。现代产品为什么失败，其中有一个原因就是没法和数据很好衔接。这里说的衔接，指的是产品功能上的衔接，数据链条的衔接以及产品经理的理念的衔接。这个专栏希望起到抛砖引玉的作用，能够真正引发对于数据产品的思考，推进产品的质量。&lt;/p&gt;

&lt;p&gt;最后，为什么这个专栏叫“期望最大化”，这源自于一个机器学习里有名的算法：Expectation Maximization，不断在现有参数下更新模型对周围的认知然后又不断更新模型的参数，最终能够达到一个局部最优解。这个专栏也希望像这个算法一样，不断提升自己的认识，不求最完美，但求能够促进业界的分享和交流。&lt;/p&gt;
</content>
 </entry>
 

</feed>
