面向硬核用户的问题与解答

2019-08-19

⚠️本文仅代表笔者个人观点,不代表公司立场和人员素质。

此文档的目标人群是希望详细了解产品和技术细节的硬核用户或媒体。如果您对 magi.com 的使用方法有疑问,请参阅使用帮助。如果您希望深入了解企业版的 Magi 服务,请直接联系我们

目录

技术问题

1.为什么说 Magi 不是知识图谱?

传统意义上的知识图谱是对知识的整合,而 Magi 则专注于这之前的一步:知识的获取

事实上,现有知识图谱的数据严重依赖于由人工整理产生的结构化(例如世界银行数据库)和半结构化(例如网页表格)数据。举例来说,只要使用简单的爬虫技术即可从旅游或百科类网站的信息栏中获得如 “埃菲尔铁塔 高度” 这样的信息,但是假如有用户(或程序)想了解 “埃菲尔铁塔第一层高度” 等更具体的信息,上述的方法就不奏效了,因为很少有人会把这些细节数据编写进信息栏中。

Magi 使用机器学习去从纯文本中获取知识,从根本上提高信息的利用率,让原本被埋没于字里行间的知识有机会走入到各种知识图谱中。

2.为什么说 Magi 不是 NER(命名实体识别)?

如下方动画所示:Magi 所关注的目标是关系而不只是实体。很多无法构成结构化知识的实体反而要被忽略掉。

其难点在于,上下文中的每个字都可能同时扮演多种角色,而每一种角色的概率则要看与其他角色共同构成的关系是否成立。同时,Magi 致力于找出全部信息 (exhaustive),这也比挑选唯一最佳 (most promising) 要更具有挑战性。

3.为什么不直接做机器问答?

需求方面,我们要做的是把文本信息提取成结构化的知识,供 downstream 任务使用,而不是应对类似 SQuAD、CoQA、NQ 的问答。我们不是“带着问题”去阅读互联网语料找答案(文本问题 -> 文本结果),而是尽可能把随机遇到的信息都结构化(无问题 -> 结构化结果)。

技术方面,不妨把主流机器问答方案粗略分为两大类:用模型参数”记忆”知识、IR 配合评估模型。可惜这两类都不适合我们的场景,具体来说:

前者存在以下主要问题:

  1. 模型是黑盒,无法像 Magi 这样对每一个输出都给出精确的 references,缺乏信任的根基;
  2. 知识工程的规模性一直是难点,我们不能指望一个 10 亿参数的模型记忆超过 10GB 的知识,而这样的数据规模对于互联网来说只是沧海之一粟;
  3. 目前还没有好的办法让模型的更新/迁移效率跟上新闻和新知识产生的速度。

后者存在以下主要问题:

  1. 前置的 IR 环节是影响召回率的薄弱点,字面上“搜”不到就没机会,而“搜”到了仍会出现无有效回答的情况;
  2. IR 环节的目的是缩小窗口范围,在严格要求响应速度的场景下,易导致无法利用全局数据得到最优解;
  3. 对输入 query 的要求较高,现实用户的输入不是通顺的自然语言,而是存在顺序颠倒的无疑问代词的关键词列表,这对 LSTM 等序列模型或需要 positional encoding 的模型是致命的。

4.为什么网页搜索中有理想的结果但没有被学习成结构化知识?

您可能会遇到这种情况:您期望输入的 query 返回结构化结果,且网页搜索结果中确实包含对应该 query 的优质信息,但系统却没有给出结构化结果。

此时建议等一段时间后再尝试搜索,具体原因主要为以下两种:

  1. 尚未尝试在目标网页中进行知识提取。网页索引和知识提取的规则与顺序不同,Magi 会将算力优先用于学习新闻等有较强时效性的信息,其他将根据来源的质量等因素安排任务计划;
  2. 已在目标网页中提取对应知识,但模型给出的可信度尚未达到一定阈值,所以不予展示。当可交叉验证的来源增加,或提取模型更新时,可信度会被重新评估。

5.为什么 magi.com 仅支持非严格的 site: 查询?

Magi 的搜索系统(Ramiel)在设计时为了配合索引数据结构,将 site 信息 hash 成了 32 bit 整型,考虑到 site 的规模,不难算出这其中一定会发生 collision。我们之所以这样设计,是在赌用户输入的 query 会大幅缩小搜索范围,只要存在 collision 的网站的内容领域差的比较开就不会有问题。

用户体验问题

1.为什么不提供 Instant Search(边打字边搜索 / Search-as-you-type)?

有别于桌面互联网时代的场景,手机的屏幕本身就不大,当用户在键入查询文本时,屏幕的上部会被搜索建议菜单占用(该功能的多样性和实用性优于 Instant Search),下部则是虚拟键盘区域。于是,实际的可用屏幕空间极其有限且割裂,此时 Instant Search 结果不仅难以完整展现,反倒像是杂乱的背景。

2.为什么字看起来有些粗?

在低 DPI 显示设备上,将黑体字用于黑底白字显示时,会出现此问题。我们建议您调整浏览器的字体设置。此问题不会出现在高 DPI 显示设备上(如新一代智能手机和高清显示器等)。不默认开启字体反锯齿是为了保证部分设备的默认中文字体不显得过细。

3.为什么网页摘要那么长?

这是故意为之的,过一段时间后我们会改回正常的。原因请见下方的清白问题

4.为什么桌面端不将结构化搜索结果放在右侧,从而给网页结果留出空间呢?

我们的主业是信息提取而不是网页搜索,Magi 提供网页搜索是出于不想让用户的期望落空,同时就当交个朋友。

5.为什么不提供快照功能?

作为一个使用率并不高的功能,开发优先度较低。同时考虑到快照页面的安全性隐患,我们不敢在没有十足把握的时候提供此项功能。

6.为什么公司官网是英文的?

目前,作为公众版本的 magi.com 主要服务于中国用户,但 Magi 系统从开发之初就不仅局限于中文,事实上,我们支持超过 170 种语言,从而为有各种语言需求的企业用户服务。同时,官网的全部文档和大部分博客文章都提供多语言的版本。

清白问题

1. 呵呵,又是个聚合别人结果的假搜索引擎?

首先我们没那么 low。其次,为了实现全网规模知识提取,唯有配合 in-house 的搜索引擎提供的海量数据和统计信息。其实我们也不想自研,但现实不允许啊。

2.哼,你说是自主研发就是啊?你又不给我们看代码?

注意看,我们的结果的摘要比一般的搜索引擎都长,是的,我们是故意为之。这足以证明我们的结果不可能来自其他搜索引擎。

3.真笨,重复造轮子太傻了,为什么不用开源的 XXX 呢?

首先要明确的一点是,开源的搜索引擎其实都不是为了网络搜索设计的。

通俗来说,开源方案的受众场景要求:“找到最好的结果呈现给用户,千万不要遗漏,尽量快,要配置灵活且提供丰富的搜索模式和统计分析功能”;而网络搜索则明显不同,追求的是:“在极短的时间内从大概率无法搜全的海量数据中,用各种投机取巧的花活儿,给出让用户尽可能满意的前 k 个结果,连结果数都是估算的,别的功能更不在乎了”。

事实上,网络搜索所需要的基于概率的 early terminate、预排序、动态折叠等功能决定了其索引结构就会与主流开源方案不同。

4.其实要实现这个真不难,只要 XXX,然后 YYY …

嘿巧了,我一开始也是这么认为的。那会儿我 140 斤,头发还浓密呢。现在,哎。

5. 好吧,确实挺厉害的。但别人又不是做不到?

因为像你一样聪明的人,此刻不在写程序,而是在网上冲浪,看着这个页面哈哈哈傻乐。

⚠️本文仅代表笔者个人观点,不代表公司立场和人员素质。