2008年7月27日日曜日

Web2.0とこれからの日本

初心者向けにWeb2.0の一部を解説、ネットに少しでも興味を持ってもらえれば程度の話
近年Web2.0という言葉がネットの世界でもてはやされている。これは定義は非常に曖昧なのだが2000年当初にはなかった新しいネット世界の動きである。キーワードとしてはロングテール、ブログ、ソーシャルブックマーク、Youtube、SNS、集合知、クラウドソーシングなどが上げられる。ユーザによって書き込まれる、あるいはユーザの商品の購買履歴等、アクセスログ等の大量のデータとそれから有用な情報を抽出しようという手法などが合わさって新しい動きが起きているのである。グーグルはアドセンスという手法によってロングテールを実現した。アドセンスのロングテールというのは今までとても広告が出せなかったような企業にも広告を出すチャンスを与え、塵も積もれば山となる方式で利益を得ようとする事である。アマゾンでも売り上げの3分の1は書店ではほとんど置かれるような事がない本から得ており(数字は目安)、本の売り上げ順位のテールの部分から大きな利潤を得ている。またアマゾンは「この商品を買った人はこんな商品も買っています」というワードに代表される協調フィルタリングという手法により綿密にユーザが買いそうな本を推薦してくれる。

 このような動きが出てきているのが日本のYahoo!や楽天はどうか?これらの会社でWeb2.0の戦略を見つけるのは難しい。これは日本のベンチャーがほとんど技術的バックグラウンドがないままに巨大に育ったためと思われる。

 しかし最近では大量のデータベースから有意な情報を探し出すデータマイニング、テキストマイニング、ユーザの行動を予測し、適した広告を配信するための行動ターゲティング、協調フィルタリング等様々な取り組みが行われ始めている。その際たる例としてNTT Docomoのマイライフアシストプロジェクトがある。これは個人のおさいふケータイでの購買履歴やメール文書、GPS情報など様々なものからユーザの行動・嗜好を予測して、その時々に適した広告を配信するのである。これからネットの世界はリアル世界と融合し加速していくだろう。


2008年7月15日火曜日

Semantic Wikipedia

Semantic Wikipedia

セマンティックウェブという技術が近年注目されている。これはウェブページ中の個々の単語に意味を付与(タグ付け)して機械が扱い易い用にしようとする試みである。これが実現されるとWeb全体が一つのデータベースとして機能できるようになり、様々な知的発見が可能となる。本論文はWikipediaをセマンティックに扱えるようにしようとする試みである。本論文はこちら

http://www.aifb.uni-karlsruhe.de/WBS/hha/papers/SemanticWikipedia.pdf

1. INTRODUCTION

本稿ではWikipediaの機能をセマンティックウェブ技術を用いて拡張するという事について述べる。Wikipediaは世界最大の百科事典で、そしてボランティアによって運営されているものである。ところがこのWikipediaは未だに様々な分野のアプリケーションに対して応用されていない。現在のWikipediaの利用法は単に人が読むものであるに過ぎなく、形式化されていないためコンピューターが理解できない。そこでこの知の集積といえるWikipediaを機械が処理できるようにするために我々はいくつかの試みをしてみた。その試みは技術的な側面もあるが、主にはセマンティック技術を導入してそれをWikipediaに定着させることである。我々は解釈されたセマンティックデータをユーザに見せるためにウィキリンク構文と記事の表示方法の拡張を提案する。WikipediaRDF, XSD, RDFS, OWLなどのW3Cに乗っ取った方法で標準化して機械が理解できるようにすることで、検索要求に対する応答や統計的な処理、あるいは知識を素早く引き出す能力などが向上する。このプロジェクトの主な目的は近い未来に実際にWikipediaに拡張機能を持たせることである。

この記事の構成は次のようになっている

  • Wikipediaの達成した業績と欠点について評価してみる(Section 2)

  • 我々の(Wikipediaのセマンティック化に対する?)基本的な考えと、それを実際に適応させたときの効果について論じる(Section 3)

  • 我々が提案するシステムの根幹をなす構成について述べる(Section 4)

  • システムの具体的な実装法について概観する(Section 5)

  • どのような知識ベースアプリケーションに応用できるかについて様々な可能性を述べる(Section 6)

  • 本研究に関連するセマンティックウィキに対して簡単に評価を与える(Section 7)

  • 結論と研究で明らかになった問題点を指摘する(Section 8)


2. TODAY’S WIKIPEDIA

WikipediaWikiソフトウェアをベースに作られたものであり、誰でも辞書の内容を変更したり追加したりすることができる。またWikipediaにはローマ教皇を名前順や就任期間の長い順に並べたリストなど、ブラウジングを支援するための記事も存在する。しかしこれらのリストの編集はすべて人手で行わなければならず、リストに変更、追加、削除などがあった場合も人手で対処せねばならず非常に面倒である。また記事へのアクセス方法について言えば、フルテキストサーチ機能とハイパーリンクをたどるぐらいの事しかできない。とりわけ欠点といえることは人が読むことでしか記事にアクセスできず、機械が自動で情報を収集して2次利用する事が困難な状態にある。

3. GENERAL IDEA

誰でも簡単に編集でき、参加者同士で記事が妥当か判断し、直接的な規制は施さないという本来のWikipediaの考えを継承した上で我々のシステムに必要な他の考えも取り入れる。それには主に次の4つがある。

  • Usability
    ユーザーが特別な知識を持たなくても簡単に編集を行えるようにしなければならない

  • Expressiveness(表現性)
    機械が可読にしやすいフォーマットを選ぶ必要があるが、それを追求しすぎるとユーザビリティとパフォーマンスに支障をきたす可能性があるため良く考える必要がある

  • Flexibility
    ユーザが自然とwikiを使えるようになる必要がある

  • Scalability
    常に増加し続ける知識ベースに対応できるだけの拡張性を確保してパフォーマンスを維持しなければならない

  • Interchange and compatibility(交換と互換の問題)
    機械可読にするために具体的なインターフェースと輸出関数(機械語に置き換える関数?)が必要となる

ここからは編集する人の観点からとくにUsabilityExpressivenessFlexibilityに焦点をあてて述べていく。
3.1 The Big Picture(全体像)

何度も説明しているが、現在のWikipediaの使用法を継承しながら機械可読な形式に持っていくことがこの研究の目的であるが、それを実現するために次のような核要素にたどり着いた。

  • 種類(categories):内容によって記事を分類する

  • 種類別リンク(typed link):記事間のリンクをその種類によって分類

  • 属性(attributes):記事の内容に関連した特性を明確に述べる

Categoryについては既にWikipediaに存在するがそれは主にブラウジングの支援のためにある。Typed linkattributesについては新しい要素である。Typed linkの例としては“ロンドン”の記事から“イギリス”の記事へのリンクがあったとき、その関係を「is a capital of」と記述する。そうすることにより簡単な検索アルゴリズムでも十分「イギリスの首都はどこ?」という問いに答えられるようになる。またattributesは多くのデータの値を統合することが出来るもう一つの機械可読データである。我々のシステムの核となる特徴はFigure2のようになる。


.2 Usage of Typed Links
typedlinkは記事間にある関係を単なるリンクではなくセマンティックな意味づけされた

関係として解釈する。Wikiの編集者はtyped linkに対して自由なラベル付けが行えるようにする。また全てのリンクをtyped linkとする必要はなく、ナビゲーションのためだけに存在するようなリンクは通常のリンクとして残す。typed linkの行い方は例えば、通常のリンクは[[England]]としていたが、それを[[is capital of::England]]と書き換えることで簡単に行える、この方法なら既存の記事も容易に再編集可能であるし、誰でも簡単に編集することが可能である。またリンク間のエッジに複数の意味を持たせることも出来るようにする。先ほどの例で行くと[[is capital of::is the biggest city of::England]]などのように書くことも出来る。Typed linkは編集側にとって非常に自由度の高いリンクである。


    1. Attributes and Types

これもtyped linkと非常に良く似ていて属性、属性値の関係を[[属性:=属性値]]と書くだけである、ロンドンの人口の例で行くと[[population:=7421328]]といった具合にする。またtyped linkとよく似ているが、一つの属性に、複数の属性値を持たせることが可能で(例えば[[population:=7421328around 7.5 million]])属性は編集者が任意に定めることが出来る。このデータ等を利用してヨーロッパの都市を人口順に並べて表示するといったことが可能になるがそれには強力なクエリー言語が必要である。幸いにSPARQLという強力なRDFクエリー言語が存在するのでこれを利用することにする。またSPARQLの構文を知らなくてもユーザが簡単に高度な検索ができるようにする必要もある。

Atrributesには単位をどう処理するかの問題がある。Figure 4[[area:=609 square mile]]とあるが”square mile” を”mi2”と書いても良いし”sqmile”と書いても同じ意味になる、そこでシステムがこれらの表記の違いを自動で吸収することにする。その結果figure2atributeの欄には[[area:=609 square mile]]と表記しただけにも関わらずarea:1557303㎢(609 )と表記された。後のセクションで詳しく説明するが、ここではユーザーが単位の選択に迷うことがないとだけ言っておこう。


    1. Semantic Templates

セマンティック情報をあらかじめ埋め込んだテンプレートを用意し簡単にセマンティック情報の入った記事が書けるようにするってことを言っている。(完全なる予想だが例えばWikipediaである都市についての記事を書くとする、その時に人口を書く項目がテンプレートであったとするとあらかじめdatatypeinteger(人口は整数値)を埋め込んでおいたりすると自動的にセマンティック情報が付加される。)

    1. User Experience

Typed linkは”inverse searches”によってその価値を増す、”inverse searches”とは例えばHyde Parkがロンドンにあるとかかれた記事について、そこにあるinfoboxをクリックしただけでロンドンに位置する他の物についても検索してくれるのである。さらにデータの値はある特定のデータタイプと結びつけることも出来る。例えばある土地の座標を書いた記事があればそれが外部マップと結びつきどこにその土地があるのかが簡単にわかるなどである。(まだこの機能は完成してはいないが取り合えず例を挙げた)


4. DESIGN
この章では具体的な実装について説明する。全体の構成について紹介し、次にtyped link attributesについての評価の流れについて議論する。attributesについては宣言、エラーの扱い、単位の変換を含む。我々の提案するシステムをどのような形で実現しようか考えたところ、我々のシステムがほとんどRDFによって表現されうる事に気がついた。Typed linkは基本的にRDFリソース間のRDF特性(プロパティ)について述べているし、attributeは記事とRDFデータリテラルの間の特性と一致する。またRDFRDFSをシステムに採用することによりwikipediaの運営に不可欠で適当なフリーソフトも利用できる。またクエリー言語であるSPARQLにより簡単なデータアクセスが実現でき、RedlandのようなRDFソフトウェアライブラリにより外部からWikipediaを利用することも容易になる。全体のシステム像は図5のようになる。


4.1 Typed Links

次にMediaWiki内のTyped linkの入力、処理、出力の具体的な構造について説明していく

Typed linkRDFのプロパティに対して適切なURIを生成するために使われる文字列でありユーザがデータタイプを宣言する必要がなく、また自由にlinkに名前をつけることが可能である。しかしスキーマ情報が完全に欠如しているとアノテーションのタスクが困難となる。そしてたくさんの名前が同じ関係を表すのに使われていたり、同じ名前が異なる意味で使われるということが起こる。これらの問題は現在のwikipediaでも問題となっているがそれほど致命的な欠陥でもない。しかしこの問題に取り組むことによりほとんどの記事にたいして人間が可読な特殊な記事を作り出すことが可能となる。また同様にして(これもメタデータを増やし誤解が生じないようにする工夫?)Relationという名前空間を導入し二つの記事の間の関係を記述できるようにする。(たくさんの名前が同じ関係を表すのに使われているという問題に対処できていない例を示す。戦国大名というカテゴリがあったとする、このとき「織田」と「織田信長」が同一人物であるにもかかわらず違う人物としてリストに列挙されている場合が考えられる。このような問題を避けるためにスキーマ情報を増やして対処しようということである。)

 これらを追加したにもかかわらず、ユーザによって入力されたtyped linkの処理は関係に関する記事を含まない。だからストレージのバックエンドとして働くRDFトリプルストアに蓄えられるRDFトリプルにtyped linkを変換するためにローカルデータソースのみアクセスされる必要がある(意味不明)

 トリプルストアが記事に含まれていない情報を含んでいないということを確実にするため、我々は期限切れのトリプルを新しい情報を保存する前に削除しなければならない。

まとめるとユーザーによって引き起こされる記事の更新には次の3ステップがある

  1. 構文解析により記事からリンクタイプを抽出する

  2. セマンティック情報をRDF tripleに変換する

  3. 古いtripleを削除して新しいtripleに更新する

これらの操作は最小限のリソースで遂行されトリプルストアの更新は記事が保存された後に非同期的に達成される、編集が同時に行われることによって起こる衝突はMediawikiソフトウェアによって発見され解決される。(データの衝突、記事の更新時に古いデータが残ってしまう危険性の回避?)

 また我々のシステム構造はトリプルストアに検索要求をかけることにより現在のセマンティック情報にはいつでもアクセス可能になる。これは非常に便利である。なぜならセマンティックデータ上で動くアプリケーションがストレージインタフェースを参照するにあたって残りのシステムとは独立して実行できるからである。(良くわからないが処理速度の向上?)

4.2 Attributes

このセクションでは正式に属性データの語彙表現とXMLスキーマが表現するところのデータを関連付けて行きたいと思う。これを実現するには、エラー処理や単位の問題を考える前にセマンティック属性のデータタイプの宣言について十分に考える必要がある。

4.2.1 Value Processing and Datatypes

属性に関してまず最初に難しいことは、与えられた属性値を正しく認識することである。属性値はリンクとは違い構文解析を行ってその意味を見つけ出さなくてはならない。それゆえ適切にフォーマットすることはtyped linkと比べるとずっと難しくなる。

 形式的にvalue spacelexical spaceというものを区別する。例えばvalue spaceは整数の集まりで、lexical spaceは整数値を表現する文字列の集まりである。RDFにおいてデータタイプを表現するときに似たような概念化が行われるが、それはXSDに基づいている。

 現在wikipedia内で属性の支援をXSDデータタイプに基づいて行うことを試している。本当はRDFトリプルのデータの値を蓄えるのにXSD表現を使いたかったのだが、英語以外の言語の人が使えないという欠点があったので、ユーザがWikipediaの所定のlexical spaceからデータを入力できるようにした。これはXSDlexical spaceとは同じではない。形式的にデータ表現の間にある2つの変換を組み合わせる。1つはWikipedialexical spaceXSDvalue spaceの変換、もう一つはvalue spaceXSDのそれに相当するlexical spaceの変換。このようにすることによりあらゆる言語の人が編集してもデータの互換性を保つことができるようになるのである。

 ユーザに属性のデータタイプを宣言させるために、我々は新しくWikipediaに”Attribute”という名前空間を導入した。記事の中に関係とカテゴリーの時と同じように人間が可読な記述を与えることもできるがさらにデータタイプを明記したセマンティック情報も加えられるようにする。新しい統語構造の量を最小化するために我々はデータタイプのための3つ目の名前空間である”Type”を導入する。そして、内蔵されたセマンティックとの関係を使って、我々は単純に[[hasType::Type:integer]]と書けばよいだけにする。これは3.4節で説明されたテンプレートの作成を容易にする。

 一般的な作業の流れはtyped linkと比べて複雑なものとなる、属性値を記事から抽出するまえに属性値のデータタイプを発見しなくてはならないからである。これにはストレージバックエンドへの追加読み込み要求などが必要となり負荷がかかる。


4.22 Error Handling

Typed linkの場合とは違い、たとえ記事が文法的に正しいとしてもattributeを扱うときには入力をシステムが適切に処理できないという場合が考えられる。このようなケースはユーザが何もデータタイプの宣言をせずにattributeに言及した時だけではなく入力値がいずれのデータタイプのlexical spaceにも存在しない場合に起こる。この問題に対処するにはエラー内容をユーザに知らせてやれば良いのだが、知らせたところでユーザはそれに対処できないであろうから我々のシステムでは、エラーに対してある程度耐えられるようにしておき、またエラーを検知し、ユーザには単にエラーメッセージを出すだけとする。データタイプ宣言のエラーが生じたとき実行できるデータタイプを入力の構造から推定してエラーを回避する、基本的には数字の時には浮動小数点として、それ以外は文字列として処理する。データタイプ宣言されたがそのデータタイプがlexical spaceに存在しない場合はセマンティック情報を蓄えず、エラーメッセージだけを出すことにする。


4.2.3 Units of Measurement

現実的に“質”を表現するときには数値だけではなく単位も必要となる。単位の付け方はユーザによってまちまちで異なる単位系統(例:kilometers miles)や異なったスケール(例:kilometers と miles)で与えられる。ここで問題となることはRDFのツールではmilekilometerのような異なる単位系統同士を比較できないということである。

 そこで解決策として、ひとつは我々の手により自動単位変換を行い大部分のデータを同じ単位としてデータベースに蓄えてやる。もう一つは単位変換がまだサポートされていないものについてもその単位を認識し他の単位の値と混合するのを避けようとする事である。

 単位の自動変換において重要なことはスタンダードな単位をできるだけ少なくするということ(たくさん単位があるとわかりづらいのである程度統一してしまおうということ)と、ユーザが直感的に単位の自動変換が行われたのだとわかることである。

 形式上、単位サポート機能の追加が、Wikipediaのデータタイプのlexcical spaceを拡張したことになる。したがって単位情報もまたデータタイプによって与えられるようになる。


5. CURRENT IMPLEMENTATION

セクション4で説明した重要な部分はもうすでに実装した。MediaWikiの機能を拡張して、元のコードには修正を加えていないため、拡張した機能が大部分元のコードと独立しており簡単に実際に動くシステムを導入することができた。他により高機能な検索エンジンやXMLシリアライゼーションにおいてRDFを出力するモジュールなどを開発している。データの出力は外部アプリケーションからWikipediaの知識を利用するのに使われる。


6. APPLICATIONS

多岐にわたるアプリケーションがセマンティック情報により拡張されたWikipediaを基礎として実現可能となる。例えばwikipediaの知識をデスクトップアプリケーションに統合することや、高度なフォークソノミーを実現することや、多言語対応辞書の作成といったことが可能となる。

 多くのデスクトップアプリケーションはユーザにwikipediaからの関連情報を提示してやることでユーザビリティを向上させることが出来る。既にこれに相当することは行われていてamaroK メディアプレーヤーではシームレスにWikipediaからアーティストやアルバム情報を取得し、それをユーザに提示している。セマンティック情報が利用可能になれば更に高度なアプリケーションが利用可能になる。また領域限定のクエリー、例えば“ビートルズの影響を受けた音楽”というような要求にも答えられるようになる。さらに教育用アプリケーションにも利用できるし、カレンダーで現在の日付に起こった事についての項目を加えることもできる。これらはデスクトップアプリケーションに限定されずWebベースシステムでも同様に利用可能である。Webで言えば、様々な情報源からデータを集めるポータルサイトは明らかにWikipediaは有益となる。

 フォークソノミーの例で言えば現在タグは言語や文脈で区別されていない、例えば“gift”というタグがあるとそれはドイツ語での“毒”という意味か、英語の“贈り物”なのかわからない、また違った単語が同じ意味で使われている場合(例えば“country”,“state”,“nation”)もある。これらの問題に対してセマンティック情報は有益に働きタグの持つあいまいさを解消することが出来る。さらにセマンティックウィキペディアは多言語対応しており、例えば犬の画像を調べようとしてアラビア語で”犬”と打ち込むと、MediaWikiに取り込まれている辞典(Wiktionary)を利用することで他の言語の“犬”に相当する単語を検索にかけアラビア語の“犬”以外の“犬”についても写真を表示してくれるようになる。








7. RELATED APPROACHES
セマンティックな知識ベースを協力して編集するためにWikiを使おうという考え方は魅力的で、これを達成するのに多くのアプローチがなされている。

  • Playtypus Wiki(2004)
    最初のセマンティックウィキ、ユーザが セマンティック情報を専用の入力スペースに書き込むことで実現する。そのスペースは普通のwikiのテキストを書くスペースと分離されていた。ユーザはN3というソフトウェアを使いセマンティックデータを記述した。このアプローチはRhizome Wikiのような後のシステムにも影響を与えた。しかしこの両方ともRDF中心になりすぎたためRDFの理解とN3で記述する技術が必要となり一般人には理解しがたいものであった。

  • WikSAR(2005)
    セマンティックの内容をWikiテキストと同じスペースに書くことが出来るようになりユーザビリティが向上した。しかし機械可読なデータと人間が呼んで編集できるテキストとの統合が不十分であった。

  • S.Auer.Powlらのシステム
    正式な構造により重みをおいたアプローチもある。すなわちオントロジーの編集を重視しており彼らのWikiシステムはよりオントロジーのエディタに近いものであった、しかしリンクが作りにくいという致命的な欠点があった。

  • その他のWikiシステム
    最近では協力して作るのではなく個人用のデスクトップアプリケーションとしてのセマンティックWikiも登場してきている。




2008年7月7日月曜日

Spam Double Funnel

Spam Double Funnel:

サイトにアクセスした時、あるいは広告をクリックした時のデータの流れを探り、そこからスパム活動の傾向を知ろうという研究。米国のサイトを対象とした研究だから分かりにくかった。具体例のサイトとか知らないし。まあともあれこんな内容です。元も論文はこれ→http://www.cs.ucdavis.edu/~hchen/paper/www07.pdf

Abstract

検索エンジンの最適化技術(SEO)を駆使し、Webページの検索結果を上位に上げる事が広く行われている。我々は広く普及したスパム手法である“リダイレクトスパム”に焦点を当てる。リダイレクトスパムはスパムページがトラフィックを第三者のドメインにリダイレクトしていることにより見つけることができる。(リダイレクトスパムは、ユーザがあるスパムページを訪れるとすぐさま広告主である他のページにユーザを飛ばすという手法のスパムであると思ったがどうもこの論文では違うらしい。ググッたところリダイレクトとはプログラムの入力元や出力先を通常とは違うものに変更することとあった。つまりあるページにアクセスあるいはリンクをクリックするとそれが様々なドメインを経由してそのドメインから得た情報をページの一部として表示したり、アクセス情報を記録したりいろいろするらしい。)我々は5層2じょうごモデルをリダイレクトスパムを表現するために用い、層を解析する方法論を提示し、2つの広告キーワードの集合を用いてスパムと思われるドメインを発見する。2つの広告キーワードの一つはスパマーに狙われるキーワードを対象としており、もう一つは広告主に向けて入札額が高いキーワードを対象としている。我々の提案と結果はサーチエンジンがスパムに対して頑健性を増し、サイトの管理人がスパムのドアウェイページを取り除き、広告主がスパムページに広告を載せるような悪い宣伝主を発見するのに有用だろう。


1.Introduction

サーチスパマーとはクオリティの低いページをSEO技術を用いて検索結果上位に引き上げようとする輩を言う。一般的なSEOのテクニックとしてはキーワードの詰め込み、リンクファーム(例えば過度の相互リンク)、Webクローラーとユーザに異なったページを見せる手法(英語でCrawler-browser cloakingという、これはSEOが施されたページをクローラーに見せ、ユーザにはSEOは施されていないが見栄えが良いサイトを見せるという手法。例えばフラッシュで作られたサイトは検索エンジンとの相性が悪いためしばしばこの手法が用いられる。現在でもこの手法が蔓延っているのか分からないが・・・(もう古いテクニックでは?))などがある。最近の手法としては、スパム調査員から逃れるための手法として、click throuth cloakingというものがある。直接URLを入れて入力してきた人に対して偽のコンテンツを見せるというものである。(お気に入りから直接来た人はどうするんだと思ったが、スパムページだとお気に入りに登録する人などいないはずだから良いのだろう)

 

 我々はブラウザーに有名なスパマーによって制御された第3者ドメインを訪れるようにリダイレクトするリダイレクトスパムを扱う。多くのリダイレクトスパムページはシンジケーションを使っており、そこでスパムページの管理者はPay-Per-Clickプログラムに参加し、広告のポータルページを表示する。

 この論文では、我々はシンジケート(アフィリエイト会社やアドセンスのようにPay-per-Clickを行っている仲介業者)が絡んでいるスパムに特に注目して、リダイレクションスパムの活動を総括的に解析する。そして我々は5層2じょうごモデルを提案し、広告をスパムページに表示する流れと広告をクリックした時のトラフィックの流れを表現する。2つの異なった広告の検索用語のベンチマークを構築しStrider Search Ranger system[21]を何万ものスパムリンクを解析するために使い、我々は5層のそれぞれに存在する主要なドメインとドメインの特徴を発見する。

以下2章でSearch Ranger systemを概観し、ダブルファンネルモデルを説明する。3章ではスパマーを対象とした(リダイレクションスパムで良く狙われるターゲットで)検索ベンチマークを作る(スパム対象となる検索語を上から順にピックアップする)。4章ではスパム密度とダブルファンネルを3章で作成したベンチマークを用いて解析する。(どのカテゴリがスパムが多いか、スパム先のサイトはどのサイトが多いかなど)5章では広告主をターゲットとしたベンチマークを作り(入札キーワード額が高い順で検索語をピックアップ)、解析結果を4章の結果と比べる。(広告主が低いクオリティのサイトにリンクをはられて損をしないためにこのような調査も必要?)6章ではリダイレクトのないスパムであるがダブルファンネルモデルと関係するスパムについて討論する。7章では関連研究を述べ、8章では結論を述べる。

  

2.REDIRECTION SPAM

2.1 Definitions:Search Spam and Redirection

リダイレクトスパムは多くのドアウェイページと一つのリダイレクションドメインを結びつけるために大規模なスパマーによって広く使われている。またサーチスパムの中でもRedirectionのスパムはスパムであると決めやすい部類に入るということが書かれている。例えばクローキングや掲示板への大量の書き込みなどを行っている。スパムと適正なSEOとの区別が難しいがドアウェイページはスパムと断定しやすい要素が多くあり扱い易い。

 リダイレクトにはアドセンスのようにセカンドドメインから広告を取ってくる形式のものとセカンドドメインそのものにURLごとページを移動するものの2種類がある。本研究ではその両方を扱う。

2.2 Strider Search Ranger System

Strider Search Ranger Systemは以下のような3つの特徴を持ったスパムを自動で発見するシステムである。

  1. Web Patrol with Search Monkeys[19]

clawler-browser cloakingテクニック(人とクローラーに異なるページを見せるテクニック)を使うスパマーに対してはクライアントサイドも含め全てのスクリプトを実行することによりこれを見破り、click through cloaking テクニック(直接のURL入力に対して異なったページを見せるテクニック、サーチエンジンから来たユーザのみにスパムページを見せる)に対しても、サーチエンジンをクリックしたと見せかけるテクニックによりこれを見破る。

  1. Follow the money through Redirection Tracking

全てのリダイレクトのURLStrider URL Tracer[20]により盗み出す。

  1. Similarity-based Grouping for Identifying Large-scale Spam

人気のあるクエリから高いスパム密度(high spam density)を得たURLを収集し、その収集したページの類似度(表記はないが恐らくhtmlの構造の類似度)を調べる。調べると、類似度の高いものが同じリダイレクトドメインに繋がっていることが多い。そしてこのように検出されたスパマーは大々的にスパムを行っている場合が多い。次にリダイレクトドメインがスパムコンテンツに対して責任があると確認したのち、そのリダイレクトドメインをシードとして“backward propagation of distrust”[13]を使い他の類似度の高いページを洗い出す。


Search Ranger のスパム発見プロセス

ステップ1:

検索語をサーチエンジンに投げ、Search Monkeyがそれぞれの検索語に対して上位N番目の結果を取り出す。そしてそれぞれのURLをスキャンし全てのURLリダイレクションを記録するXMLファイルを生成する。

ステップ2:

スキャン後、SearchRangerはリダイレクション解析を行う。そして有名なスパマーのリダイレクションドメインにリダイレクトしているURLをスパムと見なす。

ステップ3:

Search Rangerが分類されなかったURL(すなわち有名なスパマーのリダイレクションドメインにリダイレクトしていないURL)を、リダイレクトのトラフィックを受け取った第3者ドメインによってグループ化する。

ステップ4:

Search RangerがサンプルURL(どの辺がサンプルなのか不明??)をそれぞれのグループからスパム検証器に送る、そして検証器はスパムとなりえる要素がないかを調べる。(cloakingや掲示板への大量書き込みなどをチェック)

ステップ5

Search Rangerが分類されなかったURLのグループを出力(この時点でスパムとなり得る要素の値やグループの大きさが一緒に送られる)、人間によってスパムかどうか審査される。スパムだとしたら有名なスパムドメインの集合にそのリダイレクションドメインを加える。


2.3 Spam Double-Funnel

典型的な広告シンジケートビジネスは3つの層からできている。ウェブサイトに魅力的なコンテンツを乗せて集客するサイトオーナー、ウェブサイトに乗せる広告を配信する広告主、広告主とサイトオーナーを繋ぐインフラを提供するシンジケーターである。グーグルアドセンスはシンジケーターの例である。疑わしい広告ビジネスにおいて、スパマーはサイトオーナーの役割と見なす、彼らはクオリティの低いコンテンツを用意し、好ましくないSEOテクニックを使い集客する。スパムが発見されるのを防ぐために、多くのスパマーはオペレーションを2つの層に分断する。最初の層がドアウェイページであり、ドアウェイページのURLはスパマーが検索エンジンの上位に組み込むように努力する。ユーザがドアウェイページへ入ると、ブラウザがスパムコンテンツをリダイレクションドメイン(第2層目)から取ってくるように指示する。スパマーとの結びつきを求めない賢明な広告主のため、多くのシンジケーターは彼らのオペレーションを2つかそれ以上の層に分けている。層は複数のリダイレクトによって結びつけられていて、広告主とスパマーの関係を分かりにくくする。(シンジケーターが広告主を騙す)これらのシンジケーターは大抵小さい会社なので、彼らはしばしば十分なトラフィックのプロバイダーと広告主をひきつけるためにトラフィックアグリゲーションを通じて協力する。

 私たちはこのスパムビジネスを図1のようにモデル化した。広告主はシンジケーターにお金を払い、シンジケーターはアグリゲーターにお金を払いトラフィックを集める。アグリゲーターはシンジケーターと広告主をスパムページから隔離するために仲介役となってトラフィックをスパマーから購入する。スパマーは数百から数千のリダイレクトドメインをセットし何百万ものドアウェイページを設置する。ドアウェイページはリダイレクトドメインから広告を取ってくる。またスパマーは掲示板にドアウェイページのURLを書き込む。


  1. SPAMMER-TARGETED KEYWORDS

リダイレクトスパムで共通の特徴を掴むために、リダイレクトスパムでよく狙われるキーワードとカテゴリを調べた。その結果ほとんどが薬と着メロとギャンブルに関するものであった。以下カテゴリ別にキーワードを示す。

Drugs:phentermine,Viagra,cialis,tramadol,xanax,etc.

Adult:porn,adult dating,sex,etc.

Gambling:casino,poker,roulette,texas holdem,etc.

Ringtone:verizon ringtones,free polyphonic ringtones.etc.

Money:car insurance,debt consolidation,mortgage,etc

・・・残り5カテゴリ

各カテゴリから上位100キーワードをとり1000個のスパマーに狙われる検索語をピックアップした。


4.Redirection-spam analysis

1000個のキーワードでクエリを主要3検索エンジンに投げ、それぞれトップ50のサイトを収集し、リダイレクトスパムを摘出したところ11.6%がスパムであった。我々は最初にカテゴリ別のスパム割合を調べ、その次にダブルファンネルモデルの解析を行う。

4.1 Spam Density Analysis

カテゴリ別のスパムの割合は図2のようになった。薬と、着メロでスパムが多かった。

4.2 Double-Funnel Analysis

我々はダブルファンネルモデルの5層を解析し、それぞれの層にどのようなドメインが関係しているのかを調べ、サーチスパムの傾向を捉えた。

4.2.1 Layer #1 Doorway Domain

図3はドアウェイページへのリンクがどれだけ発見されたかのを表している。また図4は図3のドメインの中でどれくらいの割合でスパムリンクが含まれていたかの割合を示す。


Spam Pages on .gov and .edu Domains

.gov.eduのような商業用でないトップレベルドメインは顕著にスパマーに狙われていた。

図5は.gov/.eduドメインの中で最もスパムの多いURLを持ったドメインを示している。これらは3つの種類に分けられる。それらはUniversal redirectors,Unproteted upload area,Home page-like directoriesである。(ハッキングして何かやってるんだろうが技術的な事はわからない)


4.2.2 Layer #2 Redirection Domains

図6はリダイレクトドメインをドアウェイページにリダイレクトしている数によって上から15個並べた図である。そのうち12個はシンジケートベースであり、テキストベースの広告のポータルページを配信している。2個はポルノ広告を、1個は商業のウェブサイトを配信している。またこれらのドメインの所有者は同じである場合が多く、一握りの主要なスパマーグループが複数のリダイレクトドメインを保持していることがわかった。


4.2.3 The Bottom Three Layers

次に我々はads portalサイト(広告だけをやたらと配信したサイト)のスパムページに焦点を置き12635個のスパムページから5172個のads portalサイトが見つかった。3層と5層に対して、我々はターゲットとなる広告主のURLads portalサイトから抽出して解析した。4層では、我々はそれぞれのads portalページから一つをランダムに選んで訪問してみて、リダイレクトのトラフィックを記録した。これはシンジケーターのドメイン名が広告ページのコンテンツに現れていないので必要である。

Layer #3 Aggregators

図7はスパムページで広告がクリックされた時、そのトラフィックを受け取るドメインを受け取る広告の数に応じて上から順に並べたものである。

するとトラフィックを受け取るドメインは64.111.のドメインと64.230のドメインの2つでほとんどを占めていることがわかった。


Layer #5: Advertisers(Page analysis)

広告主のドメインネームはしばしばアンカーテキストかマウスオーバーで見ることができる。そのようなドメイン名をads-portalページから取り出し、登場回数順に15位まで並べたところ図8のようになった。ebay.com,orbitz.com等の有名なサイトも見られた。


Layer #4: シンジケーター(click-through analysis)

クリックの解析において、一握りのシンジケーターがリダイレクトの連鎖に含まれている。

Findwhat.com/looksmart.com/7search.comで全体の59%を占めた。彼らはスパムトラフィックアグリゲータと広告主の主要な仲介役のようである。


5.ADVERTISER-TARGETED KEYWORDS

4章では最もスパムの多いキーワード群をベースに5層の解析を行った。しかし、検索する側のユーザや広告主にとって最も関心が高い事は、検索結果にスパムがどれだけ悪影響を及ぼしているかであろう。スパムの多いキーワードであってもあまりユーザや広告主が重視しないようなキーワードであれば問題がない、そこで最も広告の入札額が高い1000個のキーワードについて同様に実験を行った。


5.1 Benchmark of 1000 Most-Spammed Advertiser-Targeted Keyword

入札額上位5000番までのキーワードに対して主要3検索エンジンにクエリをなげスパムの多かった1000キーワードを選択した。するとドラッグやアダルト、ギャンブルの広告が少なくなり他の様々なカテゴリが上がってきた。


5.2 Spam Density Analysis

全体で95753URLに対して6153個のスパムを発見し、スパム率は5.8%であった。これは前回の実験の半分である。これはスパム率が高いカテゴリが少なかった(ドラッグやアダルトのジャンルのキーワードが少ないのでスパム率が下がるのは当たり前)のと、前回の実験の2週間後に実験を行っており、主要3検索エンジンがスパム除去に乗り出したことが原因として考えられる。(これは微妙だとは思うが)


5.3 Double-Funnel Analysis

我々は5層を解析して、最初のベンチマークと比べた。全ての図で最初のベンチマークで出てきたものと同じものはグレーで表現している。

5.3.1 Layer #1:Doorway Domains

図9はドアウェイページのドメインの上位15個である。スパムが多いキーワードで行った前回の実験(図3参照)との違いは、.infoドメインが増えているという事である。テーブル1から.infoがスパムである確率が.comに比べて異常に高いことが分かる

5.3.2 Layer#2: Redirection Domains

図10は上位15位までのリダイレクションドメインを表している。全てシンジケーションベースとなっていた。ドラッグやアダルトのスパマーがお金に関するサイト(car insurance,mortgage等)のスパマーに入れ替わったのが大きな違いであった。


5.3.3 The Bottom Three Layers

6153のスパムURLのうち2995個の広告のポータルページを抽出した。

Layer #3 Aggregators(Page analysis)

図11は相変わらず66.23064.111のIPがスパム広告のクリックを受信していた。合計で6153のスパムURLのうち6041個がこのIPを経由していた。

Layer#5

図12は上位15位までのスパム先からたどり着く広告主であり、これは図8のものとかなり違っていた。よく知られたショッピングサイトが多くランキングされるようになった。ここから広告主がターゲットとするキーワードは、スパマーがターゲットとするキーワードよりもショッピングのWebサイトにマッチしているという事が言える。

Layer #4 Syndicators

上位3位のシンジケーターはlooksmart.comfindwhat.com,7search.comであり全体の68%を占めていた。これらのシンジケーターは検索スパム産業に広く深く関わっていることが分かった。


6.OTHER COMMON SPAM

6.1 BLOG FARMS

同じサイトのフォーマット(具体的には良く分からない)で同じブログファームに属しているが、ターゲットとなるキーワードが違うページを発見。

6.2 PARASITE ADS-PORTAL FARMS

既存のサイトに寄生してスパムを逃れる手法。http://(既存のサイトのURL)/(寄生URL)

としてページのアドレスを決定することでスパムを逃れる。


7.RELATED WORK

クローキングに関連する研究

クローキングとリダイレクションを,スパムを隠す戦略であると見なした(Garcia-Molina[8]

クローキングとリダイレクションのWeb検索結果での割合を調べ実態を調査した。また分類機を作成する事でクローキングを発見する方法を提案した。

(Wu and Davison[23],[25])

我々のSearch Monkeysは機械が検索ユーザに成りすますことで、新しいクリッククローキング手法(検索結果以外のクリックに対して他のページを見せるクローキング手法)にも対応できる。


お金とスパムの関係の研究

お金はスパマーにとっての最も大きいインセンティブである。

Jansenはクリック詐欺の問題にも関わらず、スポンサードサーチがスパムの総量を減らすことができたことを観察した。[9](意味不明)

Sarukkaiは検索語の値段(キーワード代の目安のことだと思う)の定量化の手法を提案した。[17]

ChellapillaChickeringは検索語の上位5000と、キーワード代の高い順の5000を比べ、キーワード代の高いもののサイトの方がスパムが多いという経済的な側面を発見した[5]


リンク関連の研究

スパムをリンクの観点から減らす研究として、不信頼性に基づいたものがある。

スパムサイトのシードからリンクをたどりスパムの度合いを求めていくAnti-Trust Rank(Krishnan and Raj)[12]、似たようなものとして[13],リンクファームについての研究[24]等がある。その他相互リンクに着目した研究[4],[6]、既存のリンク解析技術をスパムの観点から比べた研究[3]等がある。我々の研究ではリンク解析はスパムURLの掲示板への書き込みを解析する事しか行っておらず、リダイレクションの解析に依存してスパム発見を行っている。


コンテンツ関連の研究

ページ内容をアンカーテキストやメタタグから解析して分類器を作りスパムを判定するもの[11],またURL構造や更新期間などからスパムを解析する手法[7],タイトルで使われている言葉や、目に見える割合(恐らくJavascriptなどのプログラムの部分を除いている)に着目したもの[16]HTML構造の類似性からページ製作者を特定するもの[18],ブログとそれに対するコメントの言語モデルを比較するもの[14](恐らくコメントがスパムなのかそうでないのかを比較する)などがある。


1


2008年7月6日日曜日

Google 京都 Tech Talkに参加



Googleが京都でイベントを行っていたので行ってきた。

どうもGoogleはやりたい事がある人がやりたい事をやる会社らしい。競合の会社とかほとんど考えてないんだとさ、まあ確かにグーグルマップとか今のところどうやって採算とるんだって感じがするし。むしろユーザエクスペリエンスの向上のみを考えて仕事をやっている感じ

まあ資金に余裕があるって事ですな

APIの公開の技術者の心は、他のエンジニアがそれを使って作った作品とかが見たいからっていうのも大きいらしい。

今(教えられないが)ちょっとグーグルマップでやりたい事あるからそれが大学院卒業するまでに終わらなかったらグーグルの門を叩いてみるといいかもしれない。(最も採用されないかもしれないが・・)

写真は記念品、Tシャツまでもらえるとは思わなかった、けど長袖だからこれから着れない・・・

2008年4月14日月曜日

研究論文から垣間見る中国人の国民性

Exploring in the Weblog Space by Detecting Informative and Affective Articlesより(www2007)

この研究はブログ記事をある観点から2つに分類するのという事を行っている。
分類する2つについて述べると、一つは個人的な感想を述べた日記的なブログ記事であり、もう一つは事実や客観的な意見(大衆的な意見?)を淡々と述べたような新聞やニュースサイトに載っているようなことを書いたブログ記事である。
ブログというものは本来、特に日本では個人の日記という意味合いが強いため、前者の日記的なブログ記事が大半であると思うかもしれないが、ブログ検索エンジンでブログを検索してみるとニュース記事のようなブログ記事も多く引っかかってくる。
個人の意見(一般市民の意見)を抽出したい時にニュース記事みたいな記事が引っかかってきてうざいからこのような研究を始めたのだと最初思ったのだが、実はそうではないみたいである。
この研究ではニュース記事のようなブログ記事を良質なブログ記事とみなしていて、個人の感想は有用ではないとしているのである。
ブログにニュース記事を求めるのは意味がわからないっということで議論していたところ、次のような結論に落ち着いた。この論文を書いた人は中国人であり、中国は社会主義国家である。すなわち個人が好き勝手な感想を述べてもらっては全体の統一を取る上で困る、だから個人の意見などは排除してやろう。
ブログの本質は個人による情報発信にあると思っていたが、中国では意外とそうでもないのかもしれないと思った。研究というよりも文化を知る上でこの論文は重要ではあるまいか!

2008年4月10日木曜日

Internet-Scale Collection of Human-Reviewed Data

内容は機械学習などで使うラベル付けを考える時に、企業内や他の企業へのアウトソーシングを行うよりも、インターネットを利用して大衆の力、すなわち集合知を使った方がより安く速くラベル付けが行えるのではないかという考えの元、システムMというアプリケーションを使ってそれらを実証する実験を行っている。システムMはWeb上で集めた労働者に賃金を払いラベル付けを行ってもらうシステムである。ユーザの集め方の具体的な方法については書いていないのが残念ではあった。なぜならユーザを集めるのにお金が掛かっていては結局企業内でラベル付けを行ったほうが安くて済むかもしれないからである。またヤフーアンサーを使ってラベル付けを大衆にしてもらおうという試みも行っている。これはうまく行けば無償でラベルデータを手に入れることができ非常に便利であるが、Q&Aの方式で書かれた文書を機械可読な方式で置き換えるのは非常に難しい話である。そんな時Q&A方式のサイトをもう少し拡張して、多数決やラジオボタンを使った複数選択形式のアンケートを導入できれば機械可読できる確率が高まり有用である。

  1. INTRODUCTION

最近の企業やWebコンテンツ管理システムは、異なるソースからデータを統合することを自動化している。例えばヤフーショッピング、ヤフートラベル、ヤフーローカル(地域の口コミ、就職情報などを検索するアメリカ限定のサービス)などではコンテンツを有料フィードプロバイダ(有用な構造化されたデータを有料で提供しているサービス会社か?)やユーザやWebクローリングから収集している。人手により評価されたデータはそのような自動情報収集システムにおいて重要な役割を果たす。コンテンツ集約はつねに属性抽出(Attribute extraction)、カテゴライゼーション(Categoraization)、エンティティレゾリューション(Entity resolution)を含む。ここでこの3つの意味を説明しておく


Attribute Extraction128MB(capacity),size 10,10:00-6:00(time)などの副次的な情報に対してラベル付けを行う事

Categorization:外部の分類法を用いてデータの記録を一つあるいはより多くの場所に割り当てること。

Entity resolution:データレコード間に表記の違いがあった場合、それが同じものを指しているのかを確認すること。例えばHilton San Jose,123 Main StreetSJ Hilton,123 Main St.が同じホテルを指しているかどうかなど。

これらを合わせて、我々はACEと呼ぶことにする。またこのような技術を使ったアプリケ

ーションをACEアプリケーションと呼ぶことにする。


ACEアプリケーションは機械学習アルゴリズムの学習やルール推論や質を確かめるモニタリングやフィードバックのために、人によってラベル付けされた質の高いデータを必要とする。さらに人のレビューはしばしばデータの質を上げるために重要である。例えば外部データフィードはエラーや間違えた情報に対して人手で調整される必要があるかもしれない。あるいはユーザが作り出したコンテンツはスパムや人を不快にさせるようなコンテンツを抑える必要があるかもしれない。(?エラーやスパムを人手により評価されたデータにより抑えられるという事だと思う。)

 効果的に人が評価したリソースを活用する研究は今までにある、特にアクティブラーニングの領域で顕著である。アクティブラーニングは最小限の人を用いて、機械学習のパフォーマンスを最大限に向上させようというものである。ところが人がレビューしたデータを大規模に集める仕組み、人手のデータを提供する回答者の行動に関する研究はほとんど行われていない。

 工業において、人手により評価されたデータを収集するためには一般的に低コスト契約作業員を使用する。これらの作業員は前述したACEアプリケーションで活用するためにデータのラベル付けを行う。このレビューとラベル付けの生態系(ecosysytem)はラベル付けに対して一つの便利なビジネスインタフェースを提供する。しかしますます上昇する関連コストに対して統合された供給連鎖管理システムの潜在性と処理能力と同様に拡張性の限界を持っている。(要するにラベル付けされたデータを作るのにわざわざ低コスト契約作業員を使っていては、大規模システムになるにつれてコストが嵩んでいきシステムの拡張に無理が生じるということ。だからそれ以下のコストでラベル付けされたデータを集める仕組みが必要なのである。)

一方でGoogle Image LabelerAmazon Mechanical Turkは人手のデータを収集するためインターネットユーザの集合知を活用しようと試みている。潜在的に人が評価したデータを収集する技術プラットフォームとして、これら2つのシステムを凌駕するものとして我々はYahoo! Answersのような一般的なQAの場を挙げる。

インターネット規模で人手で評価されたデータを集めることにより外注や企業内でラベル付けを行う場合のボトルネックとなる処理能力の問題を克服でき、さらにコストも抑えられるのである。

この論文は、データの質とタスクの処理能力とユーザの振る舞いに焦点を当てた人により評価されたデータをインターネット規模で収集するメカニズムの最初の公式の研究である。我々は一般的なQAサイトが人手により評価されたデータの収集に使えるか調べるためにYahoo!Answers上で人手で評価されたデータを集める実験も行った。

  1. RELATED WORK

    1. Active Learning and Collaborative Filtering

教師あり機械学習アルゴリズムはACEアプリケーションにおいて共通して使われる。正確なラベルのついたトレーニングデータセットは学習アルゴリズムのパフォーマンスを上げる上で重要である。ところが人間のレビューをラベル付けに使う事はコストが高い。

Active learning[6]は限られた人手によるレビューを最大限に学習器生成に活用することに焦点を当てている。Active learningentity resolution[16]や情報抽出[3]やテキスト分類[13]など多くのアプリケーションの分野に適用されている。

 協調フィルタリング[5],[15]はユーザが提供するデータの集合を、ユーザの嗜好を推測するために使っている。

 我々の研究はこれら2つの研究領域を補助するものである。

    1. Data Cleaning

データクリーニングはデータのエラーと不具合を発見して取り除く研究領域である。Entity resolution[4]は一般的なデータクリーニングアプリケーションである。これは実世界のものを表しているデータレコード間の関係を確認するアプリケーションである。データクリーニングの研究は大部分がアルゴリズムによる解決とデータの質による評価に焦点を当てている。しかし我々の研究ではアルゴリズムでデータを使うのではなく、そのようなアルゴリズムで使われる人手で批評されたデータを集めることに重点を置いている。

    1. Human Computation

Human Computation[19]は多数の人々を活用して計算やコンテンツ作りを実行させるという新興の理論的枠組みである。カーネギーメロン大学で開発されたESP Game[20],Peekaboom[21],Verbosity[22]Human Computingの模範となるゲームアプリケーションである。我々の研究はインターフェースのデザイン設計よりも人により批評されたデータの解析に焦点を当てている。Gentry[8]によるセキュリティや信頼性の観点からのhuman computationの研究もある。

  1. SYSTEM TASKS

我々はSystem Mというウェブベースで人手のデータを収集するシステムを実験に用いる。

我々の実験は、現在のデータのサプライチェーンをシステムM上の仕事の形で複製することである。システムMは十分な遂行能力を持っており、構造化された応答インタフェースを提供し、我々の用いる人手で評価されたデータ収集アプリケーションのために多くの役立つ機能を提供する。しかしシステムMではユーザ数が少なく(limited user base)、賃金の作業員への支払いを前提としている。それとは対照的にYahoo! Answersはずっと大きいユーザ数を有しており、作業員には賃金は支払われない。ただし収集されたデータは構造化されていない。セクション5ではSystem Mでの実験をYahoo! Answers上でも行う。

    1. System M Overview

システムM上で、依頼人は作業人に仕事を与える。与えられたタスクに対して依頼人は、タスクが作業員に承認されるまでの寿命、仕事を受け取ってから完了するまで間での長さ、受け入れるべき答えの数、承認された答えごとに支払う報酬を指示する。依頼人は受け取った答えを承認するか却下するか一方的に決定できる。承認された答えだけが課金対象となる。

 システムMではタスクを割り振る前にまず作業員にテストを行わせることで、作業員の作業の正確さを判定し、資格スコアを算出する。そのスコアに応じてタスクを割り振る。そして一度資格スコアが決定するともうそのスコアを更新する事はできなくする。

 

    1. Tasks and Datasets

我々の実験は属性抽出とentity resolution(存在解決)の2つのACEアプリケーションに焦点を置いている。Entity resolutionでは2つのホテルのデータが与えられ、その2つの名前や位置や電話番号が同じであるかそうでないかなどを判断することを作業員は頼まれる。

 属性抽出では、一つは子供か大人かの年齢カテゴリーを選択する。後の2つはブランドや、モデルを製品についての記述から選択し、自由記述する。我々がこれら4つのアプリケーション選んだ理由は、これらが人手でラベル付けされたデータが必要なYahoo!Marketplaceのバックエンドデータ処理システムの中のコンテンツ収集アプリケーションを代表するものであったからである。(実際にマーケットプレイスでラベル付けデータを用いている)

 この実験に使われるデータセットは人手でラベル付けされた優良データセットの一様乱数サンプルである。


  1. EXPERIMENTS

    1. System M Qualification Tests

最初の実験として、我々は4つのアプリケーション(ホテルの解決、年齢抽出、ブランド名抽出、モデル抽出)それぞれに対して資格テストをシステムMに投稿した。資格テストには料金は支払われない。

 ホテル解決テストは20個のホテルの記録のペアが与えられ、作業員はそれが「同じホテル名かどうか」、「同じ位置にあるが名前が違うか」、「同じホテル名であるが場所が違うか」、「完全に異なるものか」、「その他」の5つを選択する。

 年齢、ブランド、モデルについてはまず製品の記述が与えられる。年齢では「大人」か「子供」か、「判定できない」かを選択する。ブランド、モデル抽出テストについては作業員は製品のブランドやモデルをタイプする。

    1. System M Experiments

      1. Experiment Settings

資格テストにより作業員の能力がわかったので今度は作業員の能力別にグループ分けをして資格があるグループと、無いグループを分ける事の有効性を確かめる。まず能力、実験別に11のグループに分け、それぞれのグループに対して300のタスクを課した。

また1つのタスクに付き1セントが支払われる。実験で設定したパラメータは表2の最上部にある通りである。

      1. Accuracy Results

実験結果を表2に示す。

図3~6は作業員の正確さの離散分布であり、正確さを[0,0.05]~[0.95,1],[1,1]の21分割で離散化してグラフで表している。

図7は作業員のタスクでの正確さと作業員のテストでの正確さの関係を示している。これによるほとんどこの2つには相関がない。

      1. Worker Productivity Results

図8は回答数で上10%に入っている人が、全体のタスクのどれだけをこなしたかを示したグラフであるが、これを見るとおよそ20~40%のタスクを上10%でこなしていることがわかり、データが不均一である事がわかる。

図9は作業員の正確さと300問のタスク中何%答えたかの関係であり、10%未満しか質問に答えていない作業員は正確さにかなりばらつきがある事がわかる。

 また仕事を請け負った時間と提出した時間を計ることで、作業員の時給を計算し、分析した。その結果が表3のようになる。この表から

        1. 資格の制限が無くなれば無くなるほど時給が増える

        2. 300問中の5%以上の質問に答えている人は時給が他の人に比べて高く、正確さも若干高くなる傾向がある。

        3. 高時給の人ほどたくさんの質問に答えており、回答も正確である場合が多い。

        4. ほとんどの場合最低賃金率(アメリカではどれくらいか知らないが)を大きく下回っている。

という事が分かった。

      1. Worker Accuracy Across Task Types

図4は作業員が11種類のタスクのうち何種類のタイプのタスクに従事したかを示す図である。全体と、各タスク5%以上の質問に答えた作業員で場合分けしている。我々はさらにタスクのタイプ別に作業員の答えの正確さを調査した。どのタイプのタスクでもコンスタントに正確な作業員もいた。一方でタスクのタイプによって正確さが大きく変わる人もいた。2つ以上のタイプに回答していた人は、全体と各タスク5%以上答えていた人両方とも、正確さが高い人が多かった。

  1. Yahoo! ANSWERS

巨大なオンラインのソーシャルネットワークサイトを人手により評価されたデータの収集に使えないだろうか?そこでYahoo! Answersで実験してみることにする。Yahoo!Answersはトピック別ディレクトリで構成された巨大QAサイトである。これは、ユーザーの献身的行為であり、ユーザには報酬が支払われないという点でGoogle Image Labelerと類似している。2つの疑問が浮かび上がった、一つ目はYahoo!Answersのコミュニティに我々のアプリケーションを導入できるかどうか。もう一つはAnswersの技術プラットフォームが我々のアプリケーションに活用できるかどうかである。これらの質問に答えるため4日間81個の資格テストの質問を手動でYahoo!Answersに投げかけた。それぞれの質問の有効回答期間は3日であった。

 その結果95%の質問に対して最低1つの答えが返ってきていた。我々は手動でそれらがスパムかどうか、役に立つか、質問に答えているか、機械可読可能か、正解かを調べた。表5はその詳細である。

 最も大きい課題は構文解析である。これはまずスパムや役に立たないデータと役立つデータに分類する。次に冗談や、文法的な曖昧さを解消しユーザの意図を解析する。そもそもYahoo!Answersは人的交流を意図して作られているため機械可読にするのは難しい。ブランドやモデルの抽出においてテンプレートマッチングを用いる事もできるが余すところ無くマッチングする事は不可能で明らかな限界がある。

 しかしそれでもある程度の有効回答を得ることができる。またYahoo!Answersの質問に「機械処理するので余計な文章を書かないで」と明記する、あるいは選択形式で質問に答えられるようにするなどYahoo!Answersのインフラを変えていけば、巨大Q&Aサービスを使う事はより人手により批評されたデータを得るのに有効な手段となるはずである。

 

  1. CONCLUSIONS

この研究で、我々は人手により評価されたデータを集めるために、人手により評価されたデータの質、人間の処理能力、ユーザの行動を解析する実験を行った。この研究の主な貢献は、実際に実験して得たのデータセットを使ったことと、その結果得られたデータの質とユーザの行動の徹底的な解析にある。我々の出した正確さのデータは実際のACEアプリケーションにとって非常に励みになるものである。機械学習のためのトレーニングセットのラベル付けや質の確かさを保証するためのモニタリング(quality assurance monitoring)を行いたい場合、これらのデータは参考になる。

 将来的には未来のWeb情報統合システムや内容収集システムは人手により評価されるデータを収集するインターネットベースのシステムと整合を取るようになるだろう。例えば必要に応じてデータ処理システムが、データ収集システムに人間のレビューを要求するようになるであろう。将来の課題として、より大規模に人手により評価されたデータを収集するシステムと作業員のやる気を起こさせるような設計について調査し、より大規模な実験をしていきたいと思っている。またYahoo!Answerからうまくデータを取り出せるような構文解析法や、データを機械で取り出しやすくするようなリッチなインターフェースを考えて行きたい。

6.1 Data Validation Application

この節では人手により評価されたデータを用いるアプリケーションについての議論をデータ検証に拡張させることを考える。人間こそがラベル付けを行う唯一の権威であるから、人間により評価されるデータはACEアプリケーションにとって非常に重要である。しかし人間の判断もあいまいであるし、そもそもデータそのものに曖昧さを含むものがあるためラベルデータはそれ自体完璧なものではない。そこで人間が以前の人手により評価されたデータを検証して、それをフィードバックしていくことによりデータの質と信頼性を向上させることができる。

2008年2月15日金曜日

テキストの自動分類の簡単なまとめ

テキストの自動分類について研究で調べる必要があったので整理してみた.何かの役に立つかもしれないです.

テキストの自動分類に関する研究は1960年にMaronが行った事例が発端とされている.その後1990年代に入り,Webで大量のデータが手に入るようになり,活発に研究されるようになった.
テキスト分類は大きく分けて2つあり,一つは予めカテゴリを定めずに,類似する主題を持つテキスト集合をグループ化する手法であるクラスタリング,もう一つは予めカテゴリを定めておいて,そのいずれかに新たに入ってきた文章を振り分けるテキストカテゴライゼーションである.
テキストカテゴライゼーションにおいて,どの語を分類ルールの生成に使うか,という問題があるが,これについてはN-gramという文章をN個ずつ,単語を一つずつずらしながら区切っていき,それらを語とする方法と,形態素解析という,予め辞書に単語を登録しておき,文章中の文字を辞書と照合することにより,文章を単語に分解していく手法がある.さらに分類精度を高めるために,より文書分類に重要な語を抽出しようという試みもある.これには言語特徴を用いた手法と,統計的特徴を用いた手法の2通りがあり,通常は両方を合わせて使う事が多い.言語特徴として,言語には語と語の関係を表し,それ自体は意味を持たない機能語と,語自体がある概念を表現している内容語に分けられる.機能語は助詞や助動詞を指し,内用語は主に名詞や動詞である.形態素解析を用いている場合は品詞情報を得ることが可能であるので簡単に機能語と内用語を分類する事ができる.一方でN-gramを用いている場合は全てカタカナや,全て漢字が使われている語は内容的に意味を持つ可能性が高い,特に漢字は主題的特徴を現している事が多いという事で,これらを重要語として抽出することが多い.次に統計的特徴として,該当カテゴリにおける語の出現頻度TFや,ある語が出現するテキストがカテゴリに属しているテキスト数DF,あるいは相互情報量,カイ2乗統計を使ったもの,またそれらを組み合わせて使ったものなどが存在する.また統計的特徴を用いたものとしてLSI(Latent Semantic Indexing:滞在意味インデキシング)という方法もあり,これはカテゴリ内で同時に出現する傾向のある複数の語を一つにまとめてしまうもので,例えば「情報センター」という言葉を「情報」と「センター」という2語ではなく1語として捉えることを言う.
分類ルールの作成に関しては,1980年代までは知識ベースのアプローチが主であり,人手で書かれた規則を用いる方法が一般的であったが,1990年代に入ると機械学習を用いた手法が多くなりサポートベクターマシン等が使われるようになった.