1 ポイント 投稿者 GN⁺ 2023-12-23 | 1件のコメント | WhatsAppで共有
  • プラットフォーム全体を測る分母がなければ、偽情報や推薦の影響に関する研究結果も文脈を失いやすいため、研究チームはYouTube全体の規模を無作為標本で推定しようとした
  • YouTube動画IDは11文字で、取り得るアドレス空間が2^64個あるため、単純に無作為なURLを打ち込むだけで有効な動画を見つけるのはほぼ不可能である
  • 研究チームは「drunk dialing」方式と効率化手法によって、数か月にわたり1万本以上の本当に無作為な動画を収集し、現在YouTubeには約133.25億本の動画があると推定している
  • 標本分析の結果、2023年だけで40億本以上の動画がアップロードされ、中央値の再生回数は39回であることが分かり、YouTubeのロングテールが非常に大きいことが明らかになった
  • Tubestatsは規模推定を継続的に更新しようとしているが、公開状態であっても事実上発見されていなかった動画URLを露出させないという倫理的制約も残っている

YouTube研究を難しくする分母の問題

  • ソーシャルメディア研究は、偽情報やヘイトスピーチのような目立つ現象を見つけることに集中しがちだが、プラットフォーム全体に占める比率が分からなければ、規模の判断は揺らぎやすい
    • たとえば「white genocide」や「ivermectin」のような検索語で結果件数を数える方法は可能である
    • Avaazの2020年8月のCOVID偽情報レポートは1年間で38億再生を集計したが、プラットフォーム全体の再生数という分母がなければ、それが大きい数なのか小さい数なのか判断しにくい
  • RedditとTwitterは、しばらくの間、プラットフォーム全体を見積もれるデータアクセスを提供していた
    • RedditではPushshiftが全投稿を収集できたため、コミュニティごとの規模比較が可能だった
    • 2023年夏にPushshiftへの公開アクセスが遮断され、Redditmap.socialはその年の初めに生成されたデータしか使えなくなった
    • Twitterは研究APIで全ツイートの10分の1または100分の1の標本を提供していたが、その後アクセスを遮断し、より少ないアクセスに高額な費用を課している

YouTubeでは代表標本を得にくい

  • YouTubeは、ほぼすべてのインターネット利用者が使う巨大プラットフォームである
    • Pewによれば10代の**93%**がYouTubeを利用している
    • 最も近いサービスはTikTokの63%、Snapchatの60%である
  • 文書化されたAPIがあっても、YouTube全体の無作為で代表的な標本を得るよい方法はない
  • 既存のYouTube研究は主に次の2つの方法に依存している
    • 選んだユーザーチャンネルの全動画を集めて分析する
    • 特定の動画から始めて、推薦動画をたどりながら収集する
  • どちらの方法も意味のある研究には使えるが、YouTube全体の動画標本を作ったり、プラットフォーム規模を計算したりするには不十分である

無作為URLを打ってみる「drunk dialing」

  • Jason Baumgartnerは、YouTubeの非公式APIであるInnerTubeを活用し、無作為なURLを打ってみる方式を提案した
  • YouTube URLの動画IDはwatch?v=の後ろに付く11文字の文字列である
    • 最初の10文字にはa-zA-Z0-9_-が使える
    • 最後の1文字は16個の値のうち1つしか取り得ない
    • 可能なYouTubeアドレスは2^64個、約18.4クインティリオン個である
  • YouTube動画が10億本あると仮定しても、無作為なURL1つが有効である確率は約184億回に1回の水準である
  • 研究チームはこの方式を「drunk dialing」と呼び、Jason Baumgartnerは効率を約32,000倍高める迂回手法を見つけた
  • Kevin Zhengは探索スクリプトを書き、数か月にわたって1万本以上の本当に無作為なYouTube動画を収集した

無作為標本で見たYouTubeの規模と分布

  • 現在のYouTube規模推定値は133.25億本の動画で、tubestats.orgで数週間ごとに更新されている
  • 無作為動画の年齢を見ることで、YouTubeの成長速度を計算できる
    • 2023年だけで40億本以上の動画がYouTubeに投稿されたと推定される
  • 再生回数の分布は強いロングテールを示す
    • YouTube動画の中央値の再生回数は39回である
    • YouTubeは1万回以上再生された動画を推薦しやすい
    • 1万回以上再生された動画はデータセットの約**4%**にすぎないが、YouTube全体の再生数の大きな比重を占める
  • 収集した無作為動画は、言語分布の推定にも活用される
    • Kevin Zhengは検索スクリプトと複数の言語検出システムを連携させている
    • この推定は擁護可能ではあるが、完全ではない

より効率的なdash method

  • 無作為URL探索はアドレス空間全体を対象とするため、ほかの標本抽出方法の無作為性を検証する基準として使える
  • 研究チームは、別の動画一覧生成方式が無作為探索と似た結果を出せば、「もっともらしく無作為」だとみなせると判断している
  • Jia Zhouらが2011年に発見した方式は、より効率的な標本収集方法として機能する
    • 1文字がダッシュである5文字列を生成する
    • YouTubeのオートコンプリートがそのURLを補完し、存在する場合は一致する動画を返す
  • Kevin Zhengは現在このdash methodでYouTubeを定期的に照会し、Tubestatsダッシュボードを維持している

ロングテール動画と倫理的制約

  • 無作為標本は、成功したインフルエンサーだけでなく、ユーザー生成メディアのロングテールの下層でクリエイターがツールをどう使っているかを見るのにも使われる
  • 収集された動画の大半は、数十人しか見ていない動画である
    • URLを公開すると、「公開」状態ではあっても事実上ほとんど見つかっていなかった動画が公的な検討にさらされる可能性がある
    • そのため論文には、発見した動画URLの一覧を含めていない
  • Ryan McGradyは、無作為動画1,000本を実際に見て手作業でコーディングする作業を主導した
  • 関連論文はJournal of Quantitative Descriptionに掲載され、手作業コーディング結果の紹介はRyanの文章にまとめられている

Tubestatsを維持しようとする理由

  • 研究チームは、可能な限りTubestatsを維持する計画である
  • YouTubeがこのリソースや生成方法に反対する可能性もある
  • 巨大なユーザー生成メディアプラットフォームはデジタル公共圏の重要な一部であるため、プラットフォームに何があり、誰が作り、誰に届いているのかに関する上位レベルのデータは定期的に公開されるべきである

1件のコメント

 
GN⁺ 2023-12-23
Hacker Newsの反応
  • 標本の取り方が本当に巧妙で、著者たちに拍手を送りたい。Pewにいたころ、YouTube APIの「related videos」エンドポイントをたどるランダムウォークでYouTubeをマッピングしようとしていて、1年ほどで飽和点に達したように見えたが、ここで出てきた規模を見ると、レーダーの下にあるロングテールがかなり長く存在しているようだ
    研究を公開した途端にGoogleがAPIをほぼすぐ閉じ始めたが、それでも昔ながらのスクレイピングで研究を続けている人たちがいるのはうれしい。当時の分析はチャンネル単位で、人気チャンネルにしか焦点を当てていなかったが、TubeStatsのいくつかの数値が私たちの見つけたものとかなり似ている点も興味深い。たとえば言語分布: https://www.pewresearch.org/internet/2019/07/25/a-week-in-th...

    • Googleボットが絶えずWebを巡回し、サイトをほとんど死ぬほど叩いていることを思うと、GoogleがAPIを閉じたというのはかなり皮肉
    • この方式なら、推薦でリンクされない一部の限定公開動画のようなものも見つけられる
    • この手法は新しいものではない。生物学者が湖の魚の数を数えるのに使う方法だ
      魚を100匹捕まえて印を付け、1週間待ってからもう一度100匹捕まえ、その中に印の付いた魚が何匹いるかを数えるというやり方
    • YouTubeがAPIを閉じたのはCambridge Analyticaスキャンダルの後だった気がする
  • これはドイツ戦車問題への緩和策を突く興味深いやり方だ https://en.m.wikipedia.org/wiki/German_tank_problem
    最適な解決策は、無作為標本が統計的に有意な結論に達するのに十分なデータを集められないようアドレス空間を大きくすることだろう。分布をいろいろな形に変えようとするほかの良い対策もあるだろうが、本当にランダムな標本なら、その方向での対応には限界があるはずだ

    • 記事では見かけなかったが、これは離散一様分布という前提に依存している。Googleが識別子にどんな細工をしていたのかは分からない
    • 無作為標本がクラスター化した分布のようなものをどう解決するのか分からない。推定は連続性の仮定に頼っているのではないか?
      たとえばアドレスが /v=0x00 から 0xff まであるのに、実際には f0 から ff しか使っていないなら、動画がランダムに分布していると仮定する限り、推定値は常に歪まないか?
      つまり、アドレス可能な空間に任意のフィルタを適用したうえでアドレスを割り当てていることになる。同じ方式の無作為標本なら同じ程度に外れるだろうが、私がフィルタとして適用した疎さは分からない
  • 「YouTube dislikes」データセットも確認してみる価値がある: https://clickhouse.com/docs/en/getting-started/example-datas...
    こんな名前なのは、低評価機能が削除される前に情報を集めようとしたアーカイブ作業だったからだ。最も物議を醸した動画や、特定言語の説明が付いた上位動画のようなものを見つけるのに使える

    • YouTubeは非常に大きく公開されたプラットフォームで、ほとんど公共財に近いので、低評価数のような統計は重要だ
      記事でも「YouTubeがこのリソースやその作成方法に反対するかもしれない。反論として、こうした高レベルのデータはすべての大規模なユーザー生成メディアプラットフォームについて定期的に公開されるべきだと私は考えている。こうしたプラットフォームはデジタル公共圏の最も重要な一部であり、その中に何があり、誰が作り、誰に届いているのかについて、はるかに多くの情報が必要だ」と述べている
      政府は、こうした統計をプラットフォームに開示させ、統計機関が収集できるよう規制すべきだ
    • このコメントの投稿者はClickHouseのCEO
  • YouTubeが保有するデータ量がどれほどか知りたかったが、その数字はなかった。提示されている統計から大まかに計算すると、平均動画長は500秒ほどになる
    ビットレートを400KB/s、動画数を130億本とすると、2.7エクサバイトになる。400KB/sは自分でダウンロードしたFHD 24〜30fpsの動画数本から得た値なので、かなり粗い推定だ。YouTubeは体感的な情報量が少ない区間をもっと低いビットレートでエンコードするだろうし、動画は解像度やフレームレートがばらばらで、その分布もサービスの歴史とともに変化する。すべての動画を1.5MB/sビットレートの4Kと仮定すると10エクサバイトになる
    この推定はYouTubeに必要なストレージ容量を低めに見積もっている。人気動画は複数のデータセンターに、VP9とAV1の両方で保存されるはずだからだ。逆に、不人気動画を圧縮したり別形式からオンデマンドでトランスコードしたりしているならこの推定は高すぎる可能性もあるが、その可能性は低そうだ

    • そのストレージ推定は一桁規模で外れている可能性が高い
      400KB/s、動画エンコードでよく使われる3.2Mbpsという値は、オリジナル品質のFHD、つまり1080pアップロード基準ではかなり低い。4K動画の数値のほうが平均的なオリジナルアップロードにかなり近い
      さらに、YouTubeが最低でもH.264とVP9の2つの動画コーデックで圧縮している点も考慮する必要がある。各コーデックごとに、オリジナルアップロード品質に応じて320pから1080p超までの全解像度がある。人気動画や4K動画のかなりの部分はAV1でもエンコードされる。一部には360度サラウンド動画向けにHEVCまである。読み間違いではない。YouTubeにはH.265 HEVCがある
      しかもこれは複製や重複保存すら含んでいない。総量が簡単に100EBを超えていても驚かない。2020年のDropbox100個分だ
    • 一方では、「形式が2つだけ?」という話でもない。H.264のようなものもさらにあるし、解像度も複数ありうる。また、特定の解像度を特定の形式で常に提供しなければならない契約上の義務がある、あるいはあった可能性もある
      他方では、再生数が信じられないほど少ない動画が非常に多いのかもしれない。さらに、YouTubeが独自のトランスコーディングチップまで作らなければならなかったことも思い出すべきだ。文字どおり複雑だ
      10年前にはこの質問の答えを知っていて、ストレージ担当者たちのコスト削減を手伝っていた。数日前、そのうちの一人であるR.L.が今年2月に亡くなったと知った。RIP
    • レプリケーション消去符号化のオーバーヘッドが抜けている。10エクサバイトは正直かなり低く見える。今なら50〜100EBに近い気がする
    • 2013年に、毎分アップロードされる時間の年次報告値をもとに計算したところ、コンテンツ量は375PBで、1日185TBずつ増え、年成長率は70%だった
      この計算には複数のエンコード版やオリジナル保存は含まれていない
    • YouTubeがオリジナルアップロードのコピーを恒久保存している点も考慮すべきだ。オリジナルのほうがより大きなファイルかもしれない
  • この記事の成果物として、あわせてリンクされているサイトがある: https://tubestats.org/

  • Googleは以前、一部の職種の面接でYouTube関連のスケーラビリティの質問をしていた。たいていは拡大し続ける分散インフラでログデータを同期する問題に行き着き、ほとんど口で説明するのも難しいような、ばかげたBig-O(f(n))めいた結果になっていた
    出典: Googleの面接を何度か受けた

  • 著者は「cheats」を使ったと書いている。これが何をするのかによっては、標本が独立であるというiid仮定が崩れる可能性がある
    雪だるま式標本抽出に近いなら、「過大な」成功率が出て数値を膨らませるかもしれない。「Jasonがこの方法をおよそ32,000倍効率化するいくつかのチートを見つけ、その結果、我々の『電話』はずっと頻繁につながるようになった」という箇所がある

    • 記事を最後まで読めばよい
      「2011年にJia Zhouらが発見したもので、我々の素朴な方法よりはるかに効率的だ。1文字がダッシュの5文字列を作ると、YouTubeがそのURLを自動補完し、存在する場合は一致する動画を返す」と書かれている
    • URLにチェックサムがあり、実際に動画へアクセスしなくてもタイプミスを検出できる可能性が高い
      チェックサムの作り方がわからなくても、実際のID空間のサンプル1つについてその値を全部試せる
    • そのチートはおそらく、動画の存在有無を個別の結果として返すプレイリストAPIのようなものを使う方式だろう
      たとえばID x, x+1, x+2, ... を入れたプレイリストを作るAPIを呼び、その後リストを取得すると、割り当て済みIDであるx+2だけが入っている、といった具合だ
    • 標本が歪んでいたなら、データはあそこまできれいには見えなかった気がする。Googleが何か面白いことをしていたのなら、少し歪む程度では済まなかったはずだ
    • 同意する
      私のような統計初心者には、チートや自動補完を使っても標本の独立性が壊れず、可能な限りランダムサンプリングが維持されるという証明が必要だ
      酔って無作為に電話をかけているのに、毎回オペレーターのような人が番号を押し間違えても誰かにつながるよう助けてくれる状況は、ランダムには見えない
      ただし、85ページの論文は読んでいない。そこでは扱われているかもしれない
  • 面白いデータセットだ。論文はチャンネル統計についてやや誤った印象を残している
    私の理解では、登録者数を見るときにサンプリングバイアスを補正して再重み付けしていない。標本が母集団全体のごく一部なら、特定のチャンネルが現れる確率はそのチャンネルの公開動画数に比例するため、おおよそ1/チャンネルごとの動画数で重み付けすべきだ

    • 私もそこに気づいた。登録者100万人が98パーセンタイルというのはとてももっともらしくなく、99.999パーセンタイルでない可能性は低そうだ
  • 気になる人向けに説明すると、彼らの推定方法はおおむねこうだ
    値の範囲を仮定し、その範囲から標本を取る公正な確率関数を仮定する。推定サイズは、命中率に値全体の範囲を掛けたものだ

    • 記事をざっと見たが、だとすると仮定がかなり多い
      可能な値の範囲が正しいとしよう。ある範囲の10文字に1を足した形なら、動画がありうる巨大な円1つを表している
      識別子、つまり有効な動画の分布こそがすべてだ。YouTubeが我々の知らない制約や歪みをIDにかけていたなら、実在する動画IDはその大きな可能性の円の中にある、より小さな円なのかもしれないし、全体に一様に散らばっていないかもしれない。クラスターがあるかもしれない。そうなると、その歪みのシルエットを得たり、だいたいランダムなのかを見たりするために、たとえばポアソン分布のように空間へダーツを投げるようなサンプリングをする必要があるだろう
      そのあとでようやく規模を推定できる。彼らがやっているのはそれなのか? それに、単にYouTubeに聞いた人はいないのか?
  • この方法は本当に防ぐのが簡単。存在しない識別子の一定割合に対して ランダムな動画 を返せばよい。そこに少しランダム性を混ぜれば十分
    方法を説明することに伴うリスクがまさにこれ

    • そうすると、システム全体の多くの 不変条件 を壊さずに実装するのは非常に難しそう
      たとえば動画IDは不変でなければならず、1つの動画はただ1つの固有の動画IDでのみ表現されなければならない、といった条件
    • ランダムに生成したIDから動画が出てきたなら、すぐに再度問い合わせて前と同じ動画かを見ればよい
      同じでなければその結果を捨て、生成したIDは実際には存在しないとみなせばよい。同じなら実在するIDだと分かる
      YouTubeの動画URLが 不変 である限り、この方法は上で述べたブロックを回避できる
    • ただしYouTubeがそうしたことをしていると明かさない限り、私たちにはその方法が無効化されたのか分からない。しかもその別の動画はそれ自体の既存UIDを持つはずなので、理論上はこのような測定を妨害するために複製されたのかどうかも分からない
    • そんなシステムで 本番障害 をデバッグすることを想像するのも難しい
    • 動画IDは利用可能なドメインの中で連番なのか、それとも完全に散らばっているのか? 既知の有効な動画IDに共通点があって、quintillion規模の可能性をなめやすくする何かはあるのか?