互联网 on 涯余的博客

Semantic Web

hang.yan@hotmail.com (涯余) — Sat, 17 Oct 2020 11:56:20 +0800

最近开始关注Semantic Web的原因是Abstract Wikipedia项目的发展．作为一个很老的互联网课题，大家的愿景都是很清楚的：想要一个语义更加清晰，更方便机器处理的互联网，然后构建一个真正的互联网．但是市场的行为总是与技术理想有很大偏差，想要用后期的技术来补救，其成功的概率是很低的．Abstract Wikipedia 的让人期待的地方在于，它成功的可能性更高，带来的改善也可能不止局限于Wikipedia.

先说什么是 Abstract Wikipedia, 首先目前维基百科的内容结构大家基本上也都了解:不同语言分别维护，体量差异巨大．从一个程序设计的结构来讲，这种模式是很糟糕的，因为它抽象的程度太低，大量的内容无法复用，造成的 interface 对很多用户不友好: 不同语言内容差别大，同步不及时，维护工作繁重等等．之前的低地苏格兰语被一个美国小哥勤奋地填充了大量的错误内容就是一例．

如何解决? 按程序设计的思路来看，需要分清数据和算法两部分，数据是什么，是语言无关的抽象知识，用抽象符号来表述知识．算法是什么？怎么来组织这些数据，让他们构成合理的语句．最后可能再需要一个Render层，将结果最终呈现给用户．这基本上就是一个MVC结构了．

Abstract Wikipedia就是想做这个事情.数据部分，由wikidata维护，大致如下所示的模式: 可以打开这个Hawaii State Public Library System的链接看下实际的数据是什么样子的．这部分的内容跟RDF的结构很像,可以预见的是，以后wikidata的内容越来越多，也能促进Semantic Web本身的发展．

算法部分，由wikilambda维护，这部分暂时还没有现成的实现，但是已经有初步的概要设计．一个完整的示例如下: 假设原始语句为:

San Francisco is the cultural, commercial, and financial center of Northern California. It is the fourth-most populous
city in California, after Los Angeles, San Diego and San Jose

我们想把这个语句专为通用的结构化内容,那么数据部分如下: (这部分数据完全可以用 RDF 表示出来) 注意上面的 Q62等，就代表着它们目前在wikidata中的链接.有了这些数据，那么我们可以通过一个简单的函数把它们拼接成一句英语: 这是个比较简单的示例，真实的情况肯定会比目前复杂一些．但是理论上都可以通过更丰富的数据和算法来组合出所有目前常用的句式．

对维基百科来说，这是一条看起来很有希望的路．期待的场景是人类的大部分的知识，都能通过这样的方式，以不同的语言展示给读者．当然，也不会局限于此．稍微展望一下，我们就可以发现它带来的变革几乎是无限的．我们能用它来做各种各样的事:

知识图谱．有了维基百科的数据，我们可以更方便地构建各种知识图谱
wikidata和wikilambda的内容可以以各种方式直接给其他系统集成，提供各种编程语言的 binding.
机器学习系统以及学术界可以利用维基百科的内容做各种数据研究
….

期望这个美好的愿景能实现吧．

科大讯飞

hang.yan@hotmail.com (涯余) — Sat, 31 Aug 2019 13:01:56 +0000

讯飞并不是一个很坏的企业，它只是太懒了。

国内的互联网巨头基本上没有干净的，无不是带着一身罪恶爬到了现在的位置。讯飞是一个巨头，因为他在语音行业是老大，规模也不小。但它也不是，因为它身处合肥，似乎互联网的新潮跟它都没什么关系，也很难在新闻上见到它的身影。可以概括地来讲，它是成也合肥，败也合肥。

之所以说是成也合肥，一是中科大保证了它的研发能力不弱，而是与政府互相依赖，保证了他政府方面的合作优势。败也合肥，则是因为在这么一个三线城市了，所有人都想过着朝九晚五的生活，并不想像去参与北上广的发展竞赛。再加上公司的营收严重依赖于国企的订单，它自身也变得越来越像一个国企。

机器学习大火之后，语音识别技术变得更加简单和常用。所有的大厂都可以投入人力物力去研发自己的语音识别技术，并且与讯飞的差距逐渐缩小，进一步去蚕食其本身的市场。在可以预见的未来里，它的日子并不会好过。

还有一个更明显的问题是，它太不会营销了。虽然说酒香不怕巷子深，但是当别人都在拼命地宣传自己的产品，而消费者又不是很在意这之间的细微差距，那么累积起来的用户习惯是很怕的。纵观互联网的历史，有太多产品好却死去的案例了。

还是希望它能好好正视下自己现在的困境，好好发展下去。

Common Index

hang.yan@hotmail.com (涯余) — Tue, 16 Jul 2019 16:20:10 +0000

这几天在重温《疑犯追踪》，作为一个近科幻的代表作，其描绘的社会是如此地贴近现实，让人想到时都会有一种无力感。在技术社区的种种讨论中，总会有零星的关于此话题的讨论以及解决之道。去中心化网络作为其中一个核心概念，已经有很多落地的实验性产品，虽然仍然无法撼动如今的网络结构，但总是一些希望之火。另外一个最近引起热门讨论的技术便是 Common Index。搜索引擎发展了这么多年，在给人们带来了很多便利的同时，也带来了无数的负面影响。Common Index 是一种解决途径，虽然如去中心化网络一样，看起来都很遥不可及，但仍然是值得期待的。

搜索引擎是一种商业产品，其背后的公司依靠大部分依靠广告牟利。这是一种非常容易理解的商业模式，但是却造成了以下后果:

Too Big To Fail: 搜索引擎技术随着互联网规模的发展，会形成越来越高的技术壁垒。没有任何新公司能进入到这个市场。Google 目前占据着绝对主流，其他几家只占有微量的比例:
搜索引擎公司可以通过一些看似 公平的策略来调整不同网页的权重，从而来影响互联网的发展。比如 Google 一直在提高支持移动互联网网页的比重。这样的行为不能说是很坏，但是否应该由一家公司来做这些决定呢？
搜索引擎公司可以通过人为调整搜索结果顺序来牟利。比如毫无底线的百度。

信息时代人们对于信息检索的需求是非常庞大的，而且或许正如某些人所说，它不再是一个普通的商品，而是成为类似于水电一样的基础设施，每个人的生存都依赖于这些东西。在这种情况下，搜索技术再由某些垄断公司提供是不合适的，尤其是公司容易受到地缘政治的影响。Common Index 对此的提议是将搜索技术分为两层: 底层是通用的 index 技术，上层是各个公司的定制部分。

这里OWI 指 Open Web Index, 即本文一直说的 Common Index。Common Index 作为基础设施，提供基本的互联网索引，不同的商业机构可以基于此添加自己的特定的索引，并提供不同的界面以及功能。比如我可以实现一个专门搜书的搜索引擎，或者一个专门用来搜索特定某个人的公开信息的搜索引擎等等。Common Index 让新公司加入搜索引擎这个市场变得可能，并且可以通过差异化的服务来获取用户。有了这个基础，搜索引擎市场便有可能成为一个良性竞争的市场。

要想这个设想变成可能，操作起来是很麻烦的，所以很多类似的设想都只停留在设想阶段。我能想到两个问题便是:

谁来承担 Common Index 的成本？理论上可以应该让参与这个市场的公司来共同承担，想扶持本国在此方面有所发展的国家可以资助本国公司去参与这个市场。
如何打破现有市场的格局? 最理想的情况是，在未来的某一个天，通过反垄断法将 Google 拆分，分离出其部分index 技术作为 Common Index 的基础。

当然，希望在未来讨论这些问题的时候，百度已经不在了。

Google 的经验

hang.yan@hotmail.com (涯余) — Sun, 14 Apr 2019 11:30:07 +0800

看了一篇讲谷歌公司内部的软件管理的论文，虽然对很多东西已经很熟悉了，但还是觉得有了一些新的启发。

业内对 Google 其实大多数都是一种追随者的态度。单说最近这些年的几大热门产业，大数据由 Google 的三篇论文起始，云计算由 Kubernetes 引领热潮， Alphago 在 AI 领域让人震撼。Google 比其他公司更早面临了很多技术发展的瓶颈之处，解决之后在某个时机将部分成果开源出来共享给业内。技术问题大家很容易采纳学习，但能解决这些问题的软件工程模式，则不是那么容易学习的。

Single Repo

Google 在公开这种模式之后，大部分人的态度是震惊的。因为这跟大部分人的使用模式差别很大。不管是大公司小公司，不同功能的 Repo 对应不同的功能，非常便于维护，便于划清职责。Google 的单一 Repo 模式，尤其在其规模之上，初看起来是非常难以理解的。上 Tb 的仓库数据，每天上万次的 Commit,它是如何管理的呢?

问题的答案自然是一套更为复杂的 CI/CD 系统，每一次的提交，自动化的构建、自动化的测试、自动化的 Review Check 等等，有了这些之后，代码的基本质量就有了保证，其他的就靠更为严格，精确的 Code Review 流程了。之所以大部分公司无法这样做，因为基础的 CI/CD 系统从来都不是一个公司在成长过程中优先考虑的问题，功能 -> 性能 -> Bug, 这些问题解决的差不多了，才有考虑其他的空闲。而往往此时，开发模式已经固定下来，没有了往 Single Repo 迁移的动力。

另一方面，Single Repo 带来的优势初看起来也是比较模糊的。它更多的不是一个技术上的问题，而是一个管理模式,或者企业文化上的问题。

是否能允许员工查看几乎所有的源码 Repo
如何在 Single Repo 中划分各个项目的职责边界

对 Google 来讲，去掉这个边界是必须的。他希望员工能够熟悉整个系统，不受限于自己所主要维护的组件的束缚，保持一个开放的心态。每个人都有创造的天性，当他发现有一个其他项目的问题或者优化他很想修复，或者有更好的解决方式，没有了项目的边界，他很自然地认为可以这样做也应该这样做。这种开放的模式保证了 Google 的所有项目能受惠于公司所有人的才智,也造就了 Google 在技术和商业上的成功。

Personal Time

这也是人人熟知，但几乎没有任何经常自称有 Google 背景的管理人员愿意尝试的模式。给员工留一些时间，让他做自己想做他任何想做的事。对于 Google 来说，有很多项目和改善都是来自于员工在这个时间的 Side Project。