Googleの新しい検索技術 Knowledge Graphについて

Googleの新しい検索技術
Knowledge Graphについて

@maruyama097
丸山不二夫

Rev. 2012/07/13

Agenda
 Googleの新しい検索技術
 ネットワー上のデータと「知識」
 言語の機械による理解の諸相
 言語の意味へのアプローチ
--- Knowledge Graph

Googleの新しい検索技術

今年の5月、Googleは、「Knowledge
Graph」と名付けられた新しい検索サービス
をアメリカで開始した。言うまでもなく検索は、
Googleのコア・コンピーテンスである。
Googleは、検索にどのような新しさを持ち込
もうとしているのか？ここでは、まず、その概
要を見ることにしよう。

2012年5月16日、Google、
Knowledge Graph発表
 The Knowledge Graph
http://www.google.com/insidesearch/
features/search/knowledge.html

 Introducing the Knowledge Graph:
things, not strings
http://insidesearch.blogspot.kr/2012/
05/introducing-knowledge-graph-
things-not.html

Google Knowledge Graph
新しい検索の三つの特徴

 正しい「もの」を見つける。（Find the right
thing）
 最良の要約を得る。（Get the best
summary）
 さらに深く、さらに広く。（Go deeper and
broader）

正しい「もの」を見つける

例えば、「タージマハル」には、いろんな意味がある。
インドの有名なモニュメント、グラミー賞を取ったドイツ
のバンド、近所のインド料理のレストラン等々。
Google Knowledge Graphは、単なる文字列では
なく、検索者の検索の意図を汲み取って、実際の世界
の「もの」を探そうとする。

検索結果のパーソナライズ

Googleの
検索結果の「パーソナライズ」
 人々は、コンテキストとパーソナライズを混同して
いる。この２つは別のものだ。コンテキストには、
言語、場所、年度等が因子として含まれる。
 過去の検索の履歴は、パーソナライズに利用さ
れている。もし、「ローマ」を検索して次に「ホテル」
を検索すれば、検索結果のいくつかは、ローマの
ホテルのものになるだろう。
 履歴上の過去のクリックも、一つの因子となる。も
し、検索結果中の一つのサイトに対してクリックし
て、明らかな嗜好を示せば、次の検索では、その
サイトは上位にランクされるかもしれない。

Googleの
 友達のリコメンデーションは、パーソナライズに使
われている。
 Googleは、友達のプロファイルから、そこにはど
のようなネットワークが含まれているかを見て、次
に、これらのサイトに対して彼らが何をリコメンドし
ているかを見る。
 サインアウトした場合も、過去の検索情報は、アノ
ニマス・クッキーを使って、180日間、ブラウザー
にヒモ付けされて、検索結果はパーソナライズさ
れる。

Googleの
 URLの最後の部分に、&pws=0 を追加すると機
能する。ただ、パーソナライズを消すだけで、コン
テキスト（言語、場所、年度）は消さない。
 全てのパーソナライズをオフにする方法はある。
Googleの立場は、ユーザーは自分のデータを所
有するというものだ。ただ、その場合でも、コンテ
キストは、依然として、有効になっている。

"How Google Does Personalization with Jack Menzel”
http://www.stonetemple.com/
how-google-does-personalization-with-jack-menzel/

「文字列」の検索から、「もの」の検索へ
 Googleの新しい検索Knowledge Graphが、検索者の
意図を知る為に、検索結果のパーソナライズの手法を持
ちいるだろうことは明らかだと思う。ただ、膨大でランダム
な情報を順序づける「ページランク」の手法同様に、それ
は、現在の検索でも、既に利用されている手法である。
 「ただしい「もの」を見つける」と言う時の、本当の新しさは
何か？それは、検索を単なる「文字列の検索」から「もの
の検索」へととらえ直そうとしているところにある。
 もっとも、我々が検索を行うとき、我々は「文字列」を探し
ているのではなく、「何か」を探しているのである。その意
味では、新しい検索サービスの下でも、検索者が検索に
対する態度を変更する必要は、何もないのである。

検索システムは、どう変わるべきか？
 問題は、検索者の検索に対する態度の変化ではなく、膨
大なデータの中から、特定の文字列を含むページを見つ
け出し、情報の「重要性」と個人の嗜好に応じて、それを
順序づけて提示する、現在の「文字列」検索システムが、
「ものの検索」の世界では、どのようなシステムに変化す
べきかということである。
 すぐ後で述べる、「最良の要約を得る」「さらに深く。さらに
広く。」は、新しい検索システムが備えるべき、こうした新し
い機能を示していると考えてよい。
 ただ、その機能は充分なものか？あるいは、そうした機
能だけで十分なのか？起こりつつある実際の変化の評
価の上で、その変化の先にあるものを考えることは、無駄
ではない。

最良の要約を得る

「Knowledge Graphでは、Googleはユーザの検索
をよりよく理解出来るので、そのトピックに関連したコ
ンテンツを要約することが出来る。」
「そして、その「もの」について、ユーザが必要とするだ
ろう基本的な事実を、結果の中に含めることが出来
る。」

Marie Curieの検索の要約
 Marie Skłodowska-Curie was a French-Polish
physicist and chemist, famous for her
pioneering research on radioactivity. She was
the first person honored with two Nobel
Prizes—in physics and chemistry. Wikipedia
 Born: November 7, 1867, Warsaw
 Died: July 4, 1934, Sancellemoz
 Spouse: Pierre Curie (m. 1895–1906)
 Discovered: Polonium, Radium
 Children: Irène Joliot-Curie, Ève Curie
 Education: University of Paris (1894),
University of Paris (1893), More

要約システムは、普遍的か？
 Google Knowledge Graphで、情報の「要約」の機能
が追加されたのは、注目に値する変化である。検索シス
テムの変化として、正しい方向の一つだと思う。
 Google Knowledge Graphが、一定量の、要約のデー
タベースを持っているのは事実であり、それは、その実装
方法を含めて、興味深いことである。
 ただ、それは、「最良」のものであろうか？質的な問題は、
置いておいても、重要なのは、その量である。量的には、
Wikipediaのページでさえ、全てのページの要約が提供
されている訳ではないことにすぐ気づく。一般のページの
要約には、ほど遠いのが現状である。その意味では、全
てのページを対象にする、ページランクのような普遍性を、
現状では、それは持っている訳ではない。

誰が、要約をしているのか？
 こうした量的な制約は、基本的には、要約のデータが、ど
のように生成されているのかという問題に帰着する。いっ
たん、要約のデータが、なんらかの形で出来てしまえば、
我々は、その出自を問うことはないのだが。
 要約データを、どう生成するのかという点では、基本的な
アプローチは２つある。一つは、対象となるテキストから、
機械が要約を生成する、自動情報抽出のアプローチ。もう
一つは、Web上の情報に人間がタグ付けをして、機械が
それを利用出来るようにしようという、Semantic Web流
のアプローチである。
 Google Knowledge Graphは、基本的には、現時点で
は、後者に軸足を置いているように見える。もちろん、両
者の併用はありうる。

Wikipediaからの情報抽出
 活発に取り組まれているのは、Wikipediaからの情報抽
出の試みであろう。
 Wikipedia Infoboxは、投稿者がこのツールを使うと、
自動的にタグ付けされたデータが生成されるというもの。
http://en.wikipedia.org/wiki/Help:Infobox
 DBpediaは、基本的には、先のInfoboxを利用して、
Wikipediaから構造化されたデータを抽出して、Webで
利用出来るようにしようというコミュニティの取り組み。
http://wiki.dbpedia.org/Ontology?v=181z

{{Infobox scientist
| name = Marie Skłodowska-Curie Marie CurieのInfoboxでの記述
| image = Marie Curie c1920.png
| image_size=220px
| caption = Marie Curie, ca. 1920
| birth_date = {{birth date|1867|11|7|df=y}}
| birth_place = [[Warsaw]], [[Congress Poland|Kingdom of Poland]],
then part of [[Russian Empire]]<ref>http://www.nobelprize.org/nobel_prizes/
| death_date = {{death date and age|df=yes|1934|7|4|1867|11|7}}
| death_place = [[Passy, Haute-Savoie]], France
| residence = [[Poland]] and [[France]]
| citizenship = Poland<br />France
| field = [[Physics]], [[Chemistry]]
| work_institutions = [[University of Paris]]
| alma_mater = University of Paris <br />[[ESPCI]]
| doctoral_advisor = [[Henri Becquerel]]
| doctoral_students = [[André-Louis Debierne]]<br />[[Óscar Moreno]]<br />
| known_for = [[Radioactivity]], [[polonium]], [[radium]]
| spouse = [[Pierre Curie]] (1859–1906)
| prizes = {{nowrap|[[Nobel Prize in Physics]] (1903)<br />[[Davy Medal]] (
| footnotes = She is the only person to win a [[Nobel Prize]] in two different s
| religion = Agnostic
| signature = Marie_Curie_Skłodowska_Signature_Polish.jpg
}}

DBpediaでのビートルズのエントリー

さらに深く、さらに広く

「我々は、完璧な検索エンジンとは、あなたが意図す
るものを正確に理解し、あなたが望む結果を正確に
返すものであるべきだと、常に信じてきた。」
「我々は、あなたが聞こうと思いもしなかった質問に答
え、あなたの発見をさらに助ける為に、Knowledge
Graphを、利用することが出来る。」

Knowledge GraphのScale
 GoogleのKnowledge Graphは、単に
FreebaseやWikipedia、そしてCIA World
Factbookといった、プブリックなリソースに基づ
いているだけではない。それは、もっと巨大なス
ケールで、拡張されている。なぜなら、我々は、包
括的な広さと深さにフォーカスしてきたからだ。
 現在では、Knowledge Graphは、5億個以上
の「オブジェクト」と、35億の「事実」と、これらの異
なったオブジェクト間の関係を含んでいる。
 そして、これらは、人々が検索し、Web上で見い
だしてきたものに基づいて、チューンされている。

「オブジェクト」と「事実」とその「関係」
 僕は、個人的には、あるトピックの検索が、おもいもかけ
なかった他のトピックの検索の連鎖を引き起こすことを、
何も新しいことだとは考えていない。それは、検索者の知
的好奇心の問題で、検索者の経験としては、現在のシス
テムでも十分に可能なことだ。それは、新旧いずれのシス
テムの問題ではない。
 むしろ、重要なことは、Googleが、検索システムを、文字
列の巨大な集積の上にたつシステムとしてではなく、「オ
ブジェクト」と「事実」とその「関係」の上に立つシステムとし
てとらえようとしていることだ。それは、システムの自己意
識としては新しいものだ。
 次にそのいくつかを見ていくのだが、そうした動きは、いろ
んな形ではじまりつつあるのである。

情報の２つのタイプ
 ネットワーク上の情報には、大雑把に言って２つのタイプ
がある。一つは、典型的には個人と個人のコミュニケー
ションで用いられる、基本的に共時的なメッセージ達と、も
う一つは、時間を超えて累積されることを望む、通時的な
メッセージ達である。
 この２つのタイプの区別は、コトバと文字の分離に起源を
もつ古いものだが、２つの型の情報のいずれもが、我々に
取っては、本質的に重要なものである。
 コミュニケーションの媒体は変わっても、個人間のコミュニ
ケーションの本質は大きく変わっていないように見える。た
だ、集合的で蓄積的な知のあり方は、グローバルなネット
ワークという新しいメディアの登場によって、大きく変わる
可能性はある。

ネットワーク上での知識の集積
 ネットワークこそが、集合的で累積的な知識の担い手であ
るべきだという意識は、新しいものである。
 Googleの検索システムの変化の方向も、こうした意識の
変化を反映し、同時に、こうした変化を後押しするものに
なるのかもしれない。
 次のセクションでは、ネットワーク上に、構造化された知的
な情報を蓄積しようという、いくつかの試みを見ることにし
よう。ただ、おそらくは、いずれもプリミティブなものである。
 根本的には、次の次のセクションで見るように、「データの
蓄積」といったレベルの抽象では不十分で、コトバにしろ、
文字にしろ、我々の言語能力自体の理解が、次の飛躍に
は不可欠なのである。我々は、そのことに気付きつつある。

ネットワーク上のデータと「知識」

 Google Freebase
 HTML5 Microdata
 Facebook Open Graph

Freebase

An entity graph of people, places and
things, built by a community that
loves open data.
Creative Commonsにもとずく、オープンな構造化
データのオンライン・データベース作成の試み。
Metaweb社が運営。Metaweb社は、2010年に
Googleによって買収された。

FolksonomyとCrowd Computing
 コントロールされたontologyから出発しようとい
う、W3CのセマンティックWebへのアプローチと
は異なって、Metawebは、folksonomyアプ
ローチを採用した。そこでは、人々が、新しいカテ
ゴリーを追加出来る。
 ユーザが定義したドメインをBaseと呼び、
Metawebが提供するドメインをCommonsと呼
ぶ。
 それは、Web2.0的な「集合知」を、Crowd
Computingで、具体化しようとするもの。

FreebaseのOntology
 FreebaseのOntology(構造化されたカテゴ
リー)は、”type”と呼ばれ、ユーザ自身が定義出
来る。それぞれのTypeには、述語が定義され
て、”properties”と呼ばれる。

 Typeは、A is a type B の関係で表される。
 Propertyは、A has a property B の関係で
表される。

Types = “is-a”
 Person  Automobile model
 Location  Airport
 Business  Travel destination
 Movie  Ingredient
 TV show  Mountain
 Fictional  Cause of death
character  Political party
 Winery

Properties = “has-a”
PersonのProperty
 gender  parents
 date of birth  children
 place of birth  religion
 profession  education
 nationality  employment
 ethnicity history
 ... and more

MQL Freebaseの検索言語
 https://www.googleapis.com/freebase/v1/mqlr
ead?query={"type":"/music/artist","name":"Th
e Police","album":[]}

{
"type": "/music/artist",
"name": "The Police",
"album": []
}

{
"result": {
"album": [
"Outlandos d'Amour", 先の検索結果
"Reggatta de Blanc",
"Zenyatt¥u00e0 Mondatta",
"Ghost in the Machine",
"Synchronicity",
"Every Breath You Take: The Singles",
"Greatest Hits",
"Message in a Box: The Complete Recordings",
"Live!",
"Every Breath You Take: The Classics",
"Their Greatest Hits",
"Can't Stand Losing You",
"Roxanne '97 (Puff Daddy remix)",
"Roxanne '97",
"The Police",
"Greatest Hits",
"The Very Best of Sting ¥u0026amp; The Police",
"Brimstone and Treacle",
"Can't Stand Losing You",
"De Do Do Do, De Da Da Da",
"Certifiable: Live in Buenos Aires",

MQLでの検索
[{
"id": "/en/barack_obama",
"/common/topic/article": [{
"id": null
}] {
}] "status": "200 OK",
"code": "/api/status/ok",
"result": [{
"id": "/en/barack_obama",
"/common/topic/article": [{
"id": "/guid/9202a8c04000641f800000000029c281"
},{
"id": "/guid/9202a8c04000641f8000000005b78173"
}]
}]
} http://api.freebase.com/api/trans/raw/guid/
9202a8c04000641f800000000029c281

FreebaseとKnowledge Graph
 Freebaseの技術は、GoogleのMetaweb社買収を通じ
て、GoogleのKnowledge Graphに、大きな影響を与え
ている。ネットワーク上での知識表現のモデルとしては、
同じものかもしれない。Freebaseでは、Thingは、Type
のPlaceholderである。
 また、FreebaseのEntityがTypeとPropertyを持つとい
うモデルは、次に見る、HTML5のMicrodataにも、その
まま受け継がれている。
 Freebaseの思想で、もっとも特徴的なのは、
Folksonomyであるが、GoogleのKnowledge Graph
でそれがどのように継承されているのかは、よく分からな
かった。

Folksonomy/Crowd Computing
 ネット上の情報の構造化の主要な担い手が、現実的には、
人間であるのは、確かなことである。そうである限り、また、
対象となる情報の巨大さを考えれば、Folksonomyは、
正しいアプローチであるように見える。また、それは、思想
としても興味深い。
 一方で、Folksonomyには、定義の重複、混乱、情報の
精度等で、難点も持ちかねない。Freebaseのドメインの
CommonsとBaseへの分割は、それに対する、一つの
解かもしれない。未解決の問題は、沢山ある。
 おそらく、その最大のものの一つは、構造化を記述する言
語としてどの言語を用いるのかという問題だと思う。ここで
も、我々は、言語の問題にぶつかることになる。

HTML5 Microdata

最終更新 2012/06/29
http://www.whatwg.org/specs/web-
apps/current-
work/multipage/microdata.html#encoding-
microdata

HTMLでの表現

<section> 僕の名前は、丸山不二夫です。
クラウド大学大学院の客員教授をしています。
友達は、僕のことマルと呼んでいます。
僕のホームページは、
<a href=“http://cloud.ac.jp/~maruyama097”>
マルのページ</a>です。
僕は、北海道の稚内市富岡5-9-1に住んでいます。
</section>

HTMLでの表現
表示から人間が読み取れる、いろいろな情報が含まれている。
<section> 僕の名前は、丸山不二夫です。
クラウド大学大学院の客員教授をしています。
友達は、僕のことマルと呼んでいます。
<a href=“http://cloud.ac.jp/~maruyama097”>
僕は、北海道の稚内市富岡5-9-1に住んでいます。
</section>

ただ、これらの情報を、機械に抽出させるのは難しい。

<section itemscope itemtype="http://data-vocabulary.org/Person">
僕の名前は、
<span itemprop=“name”>丸山不二夫</span>です。
<span itemprop=“affiliation”>クラウド大学大学院</span>の
<span itemprop=“title”>客員教授</span>をしています。
友達は、僕のこと
<span itemprop=“nickname”>マル</span>と呼んでいます。.
<a href="http://cloud.ac.jp/~maruyama097" itemprop="url">
<section itemprop="address" itemscope
itemtype="http://data-vocabulary.org/Address">
僕は、
<span itemprop=“region”>北海道</span>の
<span itemprop=“locality”>稚内市</span>
<span itemprop=“street-address”>富岡5-9-1</span>
に住んでいます。
</section>
</section>

ならば、それぞれの情報にタグ付けしよう。

Microdataで利用されるマークアップ
 itemscope – Itemを生成して、この要素の下位の要
素が、それについての情報を含んでいることを表す。
 itemtype – ItemとそのPropertyのコンテキストを記
述するボキャブラリーのURL。
 itemprop – 特定のItemのPropertyの値を持つタグ。
Propertyの名前と値のコンテキストは、Itemボキャブラ
リーで記述される。Propertyの値は、通常は文字列であ
るが、URLを使うことも出来る
 itemid – Itemのユニークな識別子を示す。
 itemref – Itemscope属性を持つ要素の下位要素で
はないもののProperyを表す。

MicrodataのTypeの階層
 Thing：description, image, name, url
 CreativeWork
 Event
 Intangible
 MedicalEntity
 Organization
 Person
 Place
 Product

Organization TypeのsubType
 Organization: address, aggregateRating,
contactPoint, contactPoints, email, employee, employees,
event, events, faxNumber, founder, founders,
foundingDate, interactionCount, location, member,
members, review, reviews, telephone
 Corporation
 EducationalOrganization
 GovernmentOrganization
 LocalBusiness
 NGO
 PerformingGroup
 SportsTeam

Personの持つPropery
 Person: additionalName, address, affiliation,
alumniOf, award, awards, birthDate, children,
colleague, colleagues, contactPoint,
contactPoints, deathDate, email, familyName,
faxNumber, follows, gender, givenName,
homeLocation, honorificPrefix, honorificSuffix,
interactionCount, jobTitle, knows, memberOf,
nationality, parent, parents, performerIn,
relatedTo, sibling, siblings, spouse, telephone,
workLocation, worksFor

The Type Hierarchy
http://schema.org/docs/full.html

Facebook Open Graph

「今日のウェブは、さまざまページの間に張ら
れた無構造でランダムなリンクによって成り
たっています。Open Graph(オープンググラ
フ)は人々の間の関係を構造化します。」
Zuckerberg 2010年4月 f8コンファレンス

Open Graph
 Facebookの中核にあるのは、ソーシャル・グラフである。
歴史的には、Facebookは、このグラフを管理し、新しい
プロダクトを立ち上げる度に、それを拡張してきた。
 2010年に、ソーシャル・グラフの拡張であるオープングラ
フの初期バージョンを導入した。このオープングラフ・プロ
トコルを通じて、Web中の人々が好きなウェブサイトや
ページを含めることが出来る。
 我々は、今や、サードパーティのアプリが作成した任意の
アクションやオブジェクトを含めるために、オープングラフ
を拡張しつつある。これらのアプリは、Facebookの体験
に、深く統合されることになる。
Open Graph
https://developers.facebook.com/docs/opengraph/

ユーザ・アプリとオープングラフ
 ユーザーがアプリをタイムラインに追加した後、ア
プリに特有のアクションが、オープングラフを通じ
て、Facebook上で共有される。
 ユーザのアプリは、ユーザが自分自身を表現す
る重要な部分となる為に、これらのアクションは、
タイムライン、ニュース・フィード、ティッカー全てに、
はっきりと表示される。
 これによって、ユーザのアプリは、ユーザとその
友人達のFacebook体験の、キーとなる。

Key Concepts
 Actions and Objects:
オープングラフの構成要素
 Open Graph Mechanics:
どのように、ユーザは、アクションとオブジェクトに
コネクトするか
 Social Channels:
ユーザを増大させ、既存のユーザを、再活性化さ
せるのを助ける、重要なチャンネル。タイムライン、
ニュース・フィード、ティッカーを含む。

Actions and Objects
 Actionは、ユーザがアプイの中で行うことが出来る高度
な、「相互作用」である。
 Objectは、ユーザがアプリの中で働きかけることの出来
る、「エンティティ」を表現している。
 以前は、ユーザは、「いいね」を通じてしか、アプリ中のオ
ブジェクトにコネクト出来なかった。

Objectのマークアップ

<meta property="fb:app_id"
content="YOUR_APP_ID" />
<meta property="og:type"
content="recipebox:recipe" />
<meta property="og:title"
content="Chocolate Chip Cookies" />
<meta property="og:image"
content="http://www.example.com/cookies.png" />
<meta property="og:description"
content="Best Cookies on Earth!" />
<meta property="recipebox:chef"
content="http://www.example.com/john_smith"/>

Retrieving Objects
GET /{object-instance-id}
GET https://graph.facebook.com/1015012577744568

{
"id": "1015012577744568"
"type": "recipebox:recipe",
"url": "http://www.example.com/cookies.html",
"description": "Best Cookies on Earth!",
"title": "Chocolate Chip Cookies",
"image": "http://www.example.com/cookies.png”
}

Publishing Actions

POST /me/{namespace}:{action-type-name}

https://graph.facebook.com/me/recipebox:cook?
recipe=http://www.example.com/pumpkinpie.html
&access_token=YOUR_ACCESS_TOKEN

FB.api('/me/recipebox:cook', 'post',
recipe : 'http://www.example.com/pumpkinpie.html' });

Retrieving an Action
GET /{action-instance-id}
https://graph.facebook.com/1538292028372
?access_token=USER_ACCESS_TOKEN

{
"id": "1538292028372"
"start_time": 1303502229,
"end_time": 1303513029,
"data": {
"type": "recipebox:recipe",
"url": "http://www.example.com/pumpkinpie.html",
"id": "1234567890",
"title": "Pumpkin Pie"
},
}

Built-in Object Types
 Article
 Blog
 Book
 Profile (External)
 Movie
 TV Episode
 TV Show
 Video
 Website

Book オブジェクトの記述例
<html>
<head prefix="og: http://ogp.me/ns# fb: http://ogp.me/ns/fb#
book: http://ogp.me/ns/book#">
<meta property="fb:app_id" content="YOUR_APP_ID">
<meta property="og:type" content="book">
<meta property="og:url" content="URL of this object">
<meta property="og:image" content="URL to an image">
<meta property="og:description" content="Description of content">
<meta property="og:title" content="Name of book">
<meta property="book:release_date" content="DateTime”>
<meta property="book:author" content="Who wrote this">
<meta property="book:isbn" content="ISBN Number">
<meta property="book:tag" content="keywords">
</head>
<body>

</body>
</html>

Movie オブジェクトの記述例
<html>
<head prefix="og: http://ogp.me/ns# fb: http://ogp.me/ns/fb#
video: http://ogp.me/ns/video#">
<meta property="fb:app_id" content="YOUR_APP_ID">
<meta property="og:type" content="video.movie">
<meta property="og:url" content="URL of this object">
<meta property="og:image" content="URL to an image">
<meta property="og:title" content="Movie title">
<meta property="og:description” content="Description of movie">
<meta property="video:release_date" content="DateTime">
<meta property="video:actor" content="URL to Profile">
<meta property="video:actor:rol content="Role in Move">
<meta property="video:duration" content="runtime in secs">
<meta property="video:director" content="URL to Profile">
<meta property="video:writer" content="URL to Profile">
<meta property="video:tag" content="keyword">
</head>
<body>

</body>
</html>

Built-in Action Types
 Like - Any Object Type
 Follow - Profile
 Listen - Song
 Read - Article
 Watch - Video, Movie, TV Show, or TV
Episode

Watchアクション
POST https://graph.facebook.com/me/video.watches?
video=[video-type content url]

POST /me/video.watches?
video=[movie object content url]&
created_time=2011-05-05T13:22&
expires_in=7200

POST https://graph.facebook.com/
[watch action instance id]?expires_in=7054

GET https://graph.facebook.com/me/video.watches

Open Graphの特殊性
 ネットワーク上での知識の表現のセクションで、Open
Graphを取り上げることに、違和感を持つ人も多いかもし
れない。
 何よりも、それが意図しているのは、「人間の関係の構造
化」であって、「ものの関係の構造化」ではない。しかし、
両者は、関係の表現のスタイルでも、取り上げる対象でも、
実装技術でも、多くの共通性を持つ。
 もう一つ、Open Graphが特殊なのは、それが
Facebookという世界に閉じていることである。ただ、
Facebookの世界は、クローズというには十分に広いし、
それが依拠しているのは、インターネットの標準技術であ
る。加えて、人間の関係は、具体的・現実的には、局所的
なものである。

言語の機械による理解の諸相

多くの問題が、言語の機械による理解の問題
の重要性を浮かび上がらしているように見え
る。もっとも、課題の認識と、課題の解決とは、
別のものである。ここでは、現時点で、我々に
出来ていることを考えてみよう。

Power of Data
Googleの言語へのアプローチ

Ben Jai “What’s Google Doing” から
http://life.math.ntu.edu.tw/sites/
life.math.ntu.edu.tw/files/
Fall-2006-Campus-Talk-TW.pdf

データの力
 これまでの知見
 計算パワーが増大するにつれて、以前には実際には
計算することができなかった問題が解けるようになる。
 新しい知見
 データの量が増大するにつれて、以前には解けなかっ
た問題が解けるようになる！

 それは単に、より堅実な解法を得るというだけの
問題ではない
 少数のデータで考えると失敗するように見える方法が、
巨大な量のデータのもとでは、うまくいくことがある。

「スペル訂正」の古典的方法論
 語彙集/辞書を利用する(〜１０万語程度）
 語彙集の中で見つからなかった語に、「ミススペ
ル」のフラグをたてる
 認識されなかった語から、「編集距離」の近い語
達を、候補として提示する。
 編集距離は、通常は、一方の語から他方の語に
変換する為に必要な、変更・追加・消去・変更を
要する文字の数で、測定・定義される

「スペル訂正」の課題
 「スペル訂正の」こうしたやり方は、Web上では、
多くの問題にぶつかることになる
 検索の多くは、固有名である。しかし、固有名は、
語彙集にはほとんどのっていない
 例えば、よく使われている、ワープロソフトでは、
“Kofi Annan”（元の国連事務総長）は、スペルミ
スになる。提案される訂正は、”KokiAnna”
（誰？）
 Web上で使われる言葉の集合は、標準的な語彙
集より遥かに大きく、かつ、定期的に変化する

Web上での「スペル訂正」
 “britney spears”のような、ポピュラーな名前で
も、間違ったスペルで検索する。
 実際の例。800以上もあった。
 britney spears
 brittany spears
 brittney spears
 britany spears
 britny spears
 briteny spears
 britteny spears
 briney spears
 brittny spears
 brintey spears

Google流の「スペル訂正」
 Webをコンテキスト語彙集として利用し、ミススペ
ルを、Webの文脈上での利用に基づいて見つけ
る。
 語のスペルの、確率的なモデルを構築し、語彙集
をWebでの語の使用に適合させると、より豊かな
スペル訂正のモデルが出来る。
 Googleを使った場合の例
 “Kofi Annan”は、スペルミスではない
 “Kofee Annan” は、 “Kofi Annan” に訂正される
 “Kofee Shop” は、 “Coffee Shop” に訂正される
 コンテキストがキーである。

応用：自動機械翻訳
 目標: 異なる言語間のテキストの、高品質な
自動変換を提供する
 元のテキストがいかなる言語であっても、
Web上の全てのテキスト・データを、アクセス
可能なものにすることが出来る
 長い期間を要する、挑戦的なAIの問題
 しかし、沢山のデータは、実際に役に立つ！

アプローチ：統計的機械翻訳
 機械翻訳では、不確実さのもとで、決定を行う必
要がある。（例えば、いかにして、あるフレーズを
他のフレーズに変換するのか？）

 目標: 最良で、理想的には最適な決定を行う
 一般理論：
 翻訳の統計モデルを構築する
 最適な決定を行う決定理論を利用する

サイズが問題か？
 機械学習の訓練に利用されている、ニュース
のコーパスが2倍になれば、BLEAUで測定し
た翻訳の精度は、~0.5%程度向上する。

 ４倍で1%、16倍で2%、64倍で3%、
256倍で4%、1024倍で5% ？

Googleの失敗
 「スペル訂正」でのGoogleのアプローチは、正しいと思う。
データがパワーだという新しい認識も、その限りでは正し
いものだ。
 ただ、「統計的機械翻訳」のアプローチは、正しくないと思
う。現実にも、Googleは、それだけで機械翻訳を実装し
てはいないだろう。
 人間が、言語を習得する過程も、こうしたモデルには合致
していない。我々は、Google的感覚からすると、少数の
文を経験するだけで、正しい意味のある文を無限に生成
する能力を獲得する。もっとも、機械と人間が、同じアルゴ
リズムに従う必要はないのだが。

Google IO 2012での
Knowledge Graphのデモ

https://developers.google.com/event
s/io/ 0:20:43〜

 New UI
 Voice Search
 Google Now

“Who is the prime minister of
Japan?”

“The prime minister of
Japan is Yoshihiko Noda.”

“What is the definition of
robot?”

“A machine capable of
carrying out complex
series of actions
automatically.”

“How tall is the space needle?”

“Space needle is 604
feet tall.”

“Show me pictures of pygmy
marmosets”

Swipe

音声認識技術と自然言語理解
 ここでは、自然に発話された音声としてのコトバの、文章
への変換が、一つの技術的な課題になっている。音声認
識技術は、文章の意味理解とともに、自然言語理解に
とって重要な技術である。
 話し言葉そのものとそれの文字での表現は、ある意味で
は全く同じものであり、ある意味では全く別のものだ。同じ
だというのは自明にも見える。別のものだということは、現
代では、それを処理するプログラムが全く別であることで
説明するのが、一番簡単かもしれない。
 ただ、現在、音声認識とは、発話されたコトバの意味の理
解だと、思われるようになっていることに、注意が必要で
ある。

チューリング生誕100年

 チューリング・マシン 1936

Turing テストについて wikipedia
 「1950年、アラン・チューリングによって考案された、ある
機械が知的かどうか（人工知能であるかどうか）を判定す
るためのテスト。」
 「人間の判定者が、一人の（別の）人間と一機の機械に対
して通常の言語での会話を行う。このとき人間も機械も人
間らしく見えるように対応するのである。これらの参加者
はそれぞれ隔離されている。判定者は、機械の言葉を音
声に変換する能力に左右されることなく、その知性を判定
するために、会話はたとえばキーボードとディスプレイの
みといった、文字のみでの交信に制限しておく。判定者が、
機械と人間との確実な区別ができなかった場合、この機
械はテストに合格したことになる。」

翻訳の精度の実験
 ある言語Aの文SAを、他の言語Bに機械翻訳
fを適用して、文SBを得たとする。f(SA)=SB
 今度は、こうして得られた言語Bの文SBを、言
語Aへの機械翻訳 gを適用して、文SXを得た
とする。 g(SB)=SX
 AからB、そして、BからAへの翻訳が正確なも
のだとすれば、SX=SAを期待していい。
理想的には、g(f(SA))=SA となる。
 ある文から出発して、AからB、そして、BからA
への翻訳を繰り返せば、何が起きるか？

英・日
 “The volcano, that lies in Alaska, 130
kilometers from Anchorage, erupted in 1992.”
 "130キロアンカレッジからアラスカ州にある火山は、
1992年に勃発した。"
 "Volcano located 130 kilometers from
Anchorage, Alaska. Broke out in 1992”
 "130キロアンカレッジ、アラスカから位置して火山は
1992年に勃発した”
 "The volcano erupted in 1992, located 130 km
Anchorage, from Alaska"
 "火山はアラスカから、130キロのアンカレッジに位置し、
1992年に勃発した”

翻訳結果は、落ち着かない。

英・韓
kilometers from Anchorage, erupted in
1992.”
 "130km 앵커리지부터 알래스카에 위치한
화산은 1992 년 erupted.”
 "130km from Anchorage in Alaska in
1992, the volcano erupted.”
 "1992 년 알래스카의 앵커리지에서
130km는 화산 erupted.”
 "1992 Anchorage, Alaska, 130km from
the volcano erupted."


英・中
1992.”
 “1992年，在阿拉斯加州安克雷奇从130公里，位
于火山爆发。”
 1992, Alaska Anchorage, 130 km, located
in volcanic eruptions. ”
 1992年，阿拉斯加州安克雷奇，130公里，位于火
山喷发。 “
 In 1992, Alaska Anchorage, 130 kilometers
located in the volcanic eruption. "


英・仏
1992.”
 "Le volcan, qui se trouve en Alaska, à 130
kilomètres d'Anchorage, a éclaté en 1992."
 "The volcano, located in Alaska, 130
1992."
 "Le volcan, situé en Alaska, à 130 kilomètres
d'Anchorage, a éclaté en 1992.
 "The volcano, located in Alaska, 130
kilometers from Anchorage, erupted in 1992.
翻訳結果は、一定のものに落ち着く。

英・露
 “The volcano, that lies in Alaska, 130 kilometers
from Anchorage, erupted in 1992.”
 "Вулкана, который находится на Аляске, в 130
километрах от Анкориджа, разразился в 1992
году.”
 "Vulcan, which is located in Alaska, 130 kilometers
 "Вулкан, которая находится на Аляске, в 130
километрах от Анкориджа, разразился в 1992
году.
 "The volcano, which is located in Alaska, 130
kilometers from Anchorage, erupted in 1992.”


英・希
 "Το ηφαίστειο, που βρίσκεται στην Αλάσκα, 130
χιλιόμετρα από το Anchorage, ξέσπασε το 1992.»
 "The volcano, located in Alaska, 130 kilometers
from Anchorage, erupted in 1992."
 "Το ηφαίστειο, που βρίσκεται στην Αλάσκα, 130
χιλιόμετρα από το Anchorage, ξέσπασε το 1992."
 "The volcano, located in Alaska, 130 kilometers


英・西
 "El volcán, que se encuentra en Alaska, a 130
kilómetros de Anchorage, entró en erupción en
1992."
 "The volcano, located in Alaska, 130 miles from
Anchorage, erupted in 1992.”
 "El volcán, ubicado en Alaska, a 130 kilómetros
de Anchorage, entró en erupción en 1992.”
 "The volcano, located in Alaska, 130 miles from
Anchorage, erupted in 1992.”


英・独
 "Der Vulkan, die in Alaska, 130 Kilometer von
Anchorage liegt, brach im Jahr 1992."
 "The volcano, which collapsed in Alaska, 130
kilometers from Anchorage, is in 1992.”
 "Der Vulkan, der in Alaska, 130 Kilometer von
Anchorage zusammenbrach, ist im Jahr 1992."
 "The volcano, which is in Alaska, crashed 130
kilometers from Anchorage, in 1992."


日・韓
 “アラスカにある、アンカレッジから130キロの火山
は、1992年に爆発した。
 "알래스카의 앵커리지에서 130 킬로미터의 화
산은 1992 년에 폭발했다.
 "アラスカのアンカレッジから130キロの火山は、
1992年に爆発した。
 "알래스카 앵커리지에서 130 킬로미터의 화산
은 1992 년에 폭발했다.
 “アラスカアンカレッジから130キロの火山は、
1992年に爆発した。
 ”알래스카 앵커리지에서 130 킬로미터의 화산
은 1992 년에 폭발했다

言語の意味へのアプローチ
--- Knowledge Graph

ここでは、言語の意味へのアプローチとして、
Lei Zhangの論文 “Knowledge Graph
Theory and Structural Parsing” を紹介
する。
http://doc.utwente.nl/38647/1/t0000
020.pdf

意味のネットワーク上での表現と
ZhangのKnowledge Graph
 Semantic Webは、いわば、自然言語の媒介抜きに、情
報・概念を形式的に表現しようとする。そこでは、人間に
とっての可読性とともに、機械が意味を処理するのに適し
た表現形式が選ばれることになる。
 それに対して、ZhangのKnowledge Graphは、自然言
語そのものの形式的分析を通じて、言語の表現する意味
を考える。そこでは、コトバの意味を、機械にどう理解させ
るかと同時に、人間自身がどのように、コトバの意味を理
解しているのかが研究課題となっている。
 「情報や概念の表現なら、自然言語を使うのが一番すっき
りしないか？」。もしも、機械に、それが理解出来るなら。

グラフによる知識表現 --- 理論史
 1982 Hoede and Stokman
Theory of knowledge graphs
 1984 Sowa
Conceptual Graphs

 1987 Bakker Path Algebra
 1989 de Vries extracting causal
relationships from a text
 1991 Smitt

 1993 Willem Word Graph
“Chemistry of Language”
 1993 van den Berg
“Logic and Knowledge Graphs: one of
two kinds”

 1991 Lin
“Transformation Graphs”.

Linの基本的な観点
 もし、「言語は、Knowledge Graphで表現さ
れうる」というパラダイムが擁護出来るなら、中
国語に固有な特徴も、この理論の中で表現可
能になるべきである。
 1996 Hoede & Li, verbs, nouns and
prepositions
 1998 Hoede & Li, adverbs, adjectives
and Chinese classifiers or quantity words.
 2001 Hoede & Zhang, the logic words

Zhang論文の要約（1）
 知識表現のOntologyは沢山存在しているにも
関わらず、そのどれをも、普遍的と呼ぶことは出
来ない。なぜなら、それらは、他のもので置き換え
ることが出来るからだ。
 知識が言語によって表現されるのであるから、そ
の理論は、どの言語をも表現することが出来るは
ずである。
 Knowledge Graphを用いた表現は、実際に、
考慮している言語に独立であるように見えると、
我々は結論づけるだろう。

 我々は、いかにして、複数の語句を、意味論的でもあり統
語論的でもあるWordグラフで表現するかを提案している。
 文を、Sentenceグラフにマップする為には、統語論と意
味論の両方の情報が必要である。目標の一つとして、次
のような主要なステップからなる翻訳システムを開発する
こと。構造的字句解析、Sentenceグラフの変形、対象言
語でのSentenceグラフの発話。重要な結果は、コン
ピュータのプログラムを開発する為に、Chunkが利用出
来るということである。
 主要な結論は、Knowledge Graph理論から、実際に、
翻訳システムが開発されうるということである。

 第7章では、情報抽出を実行する方法を展開した。
これは、我々の研究の後期の段階に関わってき
たことである。ここでは、あらためて、文のChunk
を考慮に入れること、Sentenceグラフの重要性
に、注意を向ける必要がある。構造的字句解析
のアイデアは、ここでも、実り多いことが判明した。

Token
 我々が、ボールの心像 Tokenを持つとき、
Knowledge Graphでは、それを次のように表
現する。

 “ALI”は、a like である。
 このグラフは、「ボールのようなもののイメージ
を持つ」ことを表現する。これは、同時に、
「ボール」という「語」の意味のグラフでもある。
と、Knowledge Graphでは考える。

TokenとType

 このグラフの右側に登場する「ボール」は、具体的実在的
な「ボール」ではないことに注意されたい。ここでの「ボー
ル」は、抽象的な概念としての「ボール」である。
 Knowledge Graphでは、こうした抽象的なものを、
Typeと呼ぶ。先のグラフは、「Type「ボール」の「ようなも
の」の心像 Token を持つ」ことを表していることになる。
 TypeとTokenの区別は、もともとは、アメリカの論理学
者・哲学者のパースによって導入されたものである。
「タイプとトークンの区別」
http://ja.wikipedia.org/wiki/タイプとトークンの区別

ALIとEQU
 いままで見てきた例のように、ある言葉で表されるType
とTokenとが、関係 ALI で結ばれたとき、このToken
は、ある言葉で表されるTypeを持つことを表現している。

 TokenとTokenの関係は、ALIだけではない。次の図
の EQU は、Tokenが、「名前」を持つことを表している。
Pluteは、このTokenの「値」だと言われることもある。
Token同士がEQUで結ばれれば、「等しい」ことを表す。
このグラフは、「プルートという名前を持つ犬」を表している。

CAU
 文の構造を表す上で、重要な役割を果たすToken同士の
関係に、CAUがある。
 CAUの矢印の出発点となるTokenは動作の主体を、
CAUの矢印の到達点となるTokenは、動作の目的対象
を表す。

 先の図は、hit（打つ）という動詞のWordグラフである。
hitは、主格と目的格をとる他動詞であることを表現してい
る。

CAU
 次の図は、「眠る」のWordグラフである。

CAU
 次のグラフは、「人が犬を打つ」という文のグラフである。

 次のグラフは、Johnという名前を持つある人物が、何か
をhitするという文を表現している。

Peter, read, book, today
 次の文グラフに現れる関係PARは、まだちゃんと説明し
ていないが、動詞に係る副詞だと思えばいい。この文グラ
フは、{Peter, read, book, today}を表現している。

二項の関係
 Equality : EQU
 Subset relationship : SUB
 Similarity of sets, alikeness : ALI
 Disparateness : DIS
 Causality : CAU
 Ordering : ORD
 Attribution : PAR
 Informational dependency : SKO

Wordグラフ
HOTDOG ISA SAUSAGE
 もし、ある言葉、例えば”hotdog”が、他の言葉の
subtypeであるなら、次のように、２つのトークンの間を、
FPARリンクで結ぶ。

 このグラフは、「ホットドックは、ソ−セージの一種である」
と読む。

Wordグラフ
COMPANY SYNONYM WITH FIRM.
 もし、ある言葉が、“company and firm”のように、他の
言葉の同義語であるなら、２つのトークンを、EQUリンク
で結ぶ。

 次のグラフは、「Companyは、Firmと同義語である」と
読む。

Structural parsing
 Structural parsingとは、文を意味論的Sentenceグラ
フにマップすることである。Structual Parsingの目的で
ある文の意味論的グラフは、原理的には、次のようにして
得られる。

1. その文に対して、一つあるいはそれ以上の解析木を構成
する為に、文法が利用される。
2. 解析木を利用して、統語論的なSentenceグラフが導出さ
れる。
3. 発見された統語論的Sentenceグラフから、意味論的
Sentenceグラフが、導出される。

Example:
kilometers from Anchorage, erupted
in 1992.”

CHUNK分割のIndicator
 Indicator 0: Pairs of comma and/or
period signs;
 Indicator 1: Frame words, including
auxiliary verbs;
 Indicator 2: Reference words;
 Indicator 3: “Jumps”, with respect to
grammar;
 Indicator 4: Link words, including
prepositions.

ExampleのCHUNK分割
 1. [.[The volcano],
CHUNK1
 2. [[that][lies][in Alaska]],
CHUNKS 2, 3, and 4
 3. [[130 kilometer][from Anchorage]],
CHUNKS 5 and 6
 4. [[erupted][in 1992]].]
CHUNKS 7 and 8.

Lexicon of Example

Lexicon of Example

of Example
Syntactic chunk graphs of Example

Syntactic chunk graphs of Example

Semantical chunk graphs of Example

Semantical chunk graphs of CH10

Semantic Sentence
graphs of Example

Semantic sentence graph with
display of “chunks”.

 The mean tall
man, with a
very big stick,
hit(s) the
poor small
dog, in the
garden

 図中の太い線は、
この文が基本的
には、誰かが
何かをhitする
ことを表現して
いる。

２つのKnowledge Graph
 GoogleのKnowledge Graphは、検索を、より現実的
に、より知的にするという具体的な問題意識から出発して、
知識の表現とネットワーク上でのその利用という問題に、
あらためて答えていこうとする試みである。
 「文字列からものへ」というスローガンが表現しているのは、
検索者の検索経験の変化ではなく、検索システムの位置
づけとその実装の変化である。
 それは、構造化されたデータ、ないしは、知識のネット
ワークとして、既存のネットワークを再構成しようとする試
みと結びついている。
 こうした試みは、ようやく始まったばかりである。

 では、誰がデータを構造化するのか？多分、現時点で
は、最終的には人間である。あるいは、どうして、そういう
ことが可能なのか？おそらく、人間が、言語の意味を理
解する能力を持つからである。
 人間のコトバの意味を理解出来る、立派なロボットが出来
たと思っていたら、何枚か皮をめくると、中には沢山の人
間が入っているようなものだ。でも、それは、悪いことでは
ないかも知れない。
 こうして、知識のネットワークとして、ネットワークを再構成
しようという試みは、最終的には、人間が持つ、言語の意
味を理解する能力の問題に行き着くことになる。

 ZhangのKnowledge Graphは、直接、言語とその意味
にアプローチしようとする試みである。そこでは、言語の構
造こそが、意味の担い手であるとされる。こうしたアプロー
チは、言語の意味理解にとっては、本質的に重要な一歩
になるかもしれない。
 さらに、こうした関係は、具体的な言語を問わず、普遍的
なものであるという主張がなされる。それゆえ、Zhangの
Knowledge Graphの理論は、言語間の機械翻訳の基
礎理論を提供しうるものである。
 ただ、こうした試みも、まだ始まったばかりである。

 楽観的な見通しを述べれば、この２つのKnowledge
Graphのアプローチは、いずれ合流するだろう。
 ただ、こうした前進をドライブする本質的な力は、現在の
GoogleのKnowledge Graphの側にではなく、Zhang
らの言語の意味に対するアプローチとしてのKnowledge
Graphの側にある。

Googleの新しい検索技術 Knowledge Graphについて

More Related Content

Googleの新しい検索技術 Knowledge Graphについて