2019-10-30

  • Scrapboxに機械的にコンテンツを流し込むと、肝心の「リンク」が乏しいので「死んだテキストの倉庫」になる。

  • これはコンテンツを流し込んだことが悪いのではない: 機械生成Scrapbox

  • その後のリンク作成に対するコンピュータの支援がないことが問題

  • そこで実験のために、まず以下のようなプロジェクトを作った

    • 過去の講演スライドPDFを1ページ1枚の画像に変換
    • 画像はGyazoにアップロードし、OCR結果を取得する
    • 1ページがScrapboxの1ページになるようにJSONを作成してインポート
    • ページ数は4000〜6000
    • 詳しい話: 書籍スキャンPDFをScrapboxに置く2019
  • これに対してリンクの作成を支援できないか

  • 各ページの文章をBERTを使って768次元のベクトルに変換する

  • 実験1

    • 実装前メモ: BERTで区分け
    • 768次元のベクトルの冒頭12次元を取ってそれの正負を1bitとして3バイトの文字列を作成、それを空リンクとする
    • 3バイトの文字列(カテゴリコード)が同一である領域は空間を2^12個に均等分割する
      • 1空間あたり1ページ前後になる
    • Scrapboxは同一のページにリンクしているページが、そのページからまとまって表示されるので「ハッシュタグでの分類」に相当することができる
    • 結果
      • [/nishio-a1/C, 4eb](https://scrapbox.io/nishio-a1/C, 4eb)
      • 異なるプレゼンで使われている同じ内容のスライドは同じカテゴリに入ってる
      • 他に入っているものがいまいち納得感が薄い
    • 考察
      • 768次元から12次元へ、単純に756次元無視することで写像したので情報がだいぶ落ちてしまったか
      • 例えば768次元を入力として、中間層12に圧縮してから、2つの入力スライドが同一のプレゼンに属しているか識別するネットワークを組んでfinetuneすれば、その中間層が同一のスライドで近い値になるような次元削減が行われる、こういうのを使うべき
  • 実験2

    • 5744ページのそれぞれから「その内容に一番似ているがイコールではないページ」へのリンクを張った。
    • 「似ている」の定義は文章をSentencePiece+日本語BERTで768次元のベクトルに変換してからユークリッド距離。
    • このページはあるプレゼンのスライドが、他のプレゼンのスライドにリンクし、別のプレゼンからリンクされている。
    • 別の例
    • 別の例
      • /nishio-a2/bd6c50dd861c,010 有用性って?ってスライドから
      • 「有用性」と「役に立つ」は文字列的に共通部分はないし、単一トークンでもなくて、これを類似と判定するのはなかなか難しい