Hacker Newsのランキングの仕組み：スコアリング、論争、ペナルティ（2013年）

ランキングの仕組み

Hacker Newsのランキングの基本的な計算式は長年知られていましたが、疑問は残っていました。公開されているコードは実際のアルゴリズムを示しているのか？ ランキングは純粋に投票数に基づくのか、それとも目に見えない要因が影響するのか？ NSAに関する記事はランキングで押し下げられるのか？ コメントした後に人気の投稿がフロントページから突然消えるのはなぜか？

数日間にわたって上位60件のHN記事を注意深く分析することで、これらの疑問に答えることができます。公開されている計算式は概ね正確です。ランキングには予想以上に多くの調整が加えられており、フロントページの20%の記事が様々な方法でペナルティを受けています。「NSA」という言葉がタイトルに含まれる記事はペナルティを受け、すぐに順位を落とします。「論争のある」記事は、コメント数が40に達すると厳しくペナルティを受けます。この記事では、スコアリングとペナルティについて詳しく説明します。[編集: HNは現在NSA記事にペナルティを課していません（詳細はこちら）。]

記事は、アップボート数、投稿からの経過時間、そして様々なペナルティを用いて、以下の計算式に基づいてスコアリングされます：

［画像: score=rac{ ext{ (votes-1) }^{.8}}{ ext{ (age _{hours} + 2) }^{1.8}} * penalties］

時間の指数が投票数よりも大きいため、記事のスコアはいずれゼロに近づき、何もフロントページに長く留まることはありません。この指数は重力として知られています。

Hacker Newsを訪れるたびに、記事が上記の計算式でスコアリングされ、ランキングを決定するためにソートされると予想するかもしれません。しかし、効率化のため、記事は時折しか個別に再ランキングされません。記事がアップボートされると、再ランキングされ、リストの適切な位置に移動し、他の記事は変更されません。これにより、再ランキングの量が大幅に削減されます。しかし、記事が投票されなくなり、高い位置に留まってしまう可能性もあります。これを避けるため、30秒ごとに上位50件の記事のうち1件がランダムに選択され、再ランキングされます。その結果、投票されていない記事は、何分もの間「誤って」ランク付けされる可能性があります。さらに、ページは90秒間キャッシュされることがあります。

通常の日の生スコアと1位の座

以下の画像は、11月11日の1日を通して、HNの上位60件の記事の生スコア（ペナルティを除く）を示しています。各線は記事に対応し、ページ上の位置に応じて色分けされています。赤い線はHNのトップ記事を示しています。ペナルティのため、生スコアが最も高い記事が必ずしもトップ記事ではないことに注意してください。

［画像: Hacker Newsの1日の生記事スコア。赤い線は1位の記事を示す。ペナルティのため、1位の記事が常にトップスコアを持つわけではない。］

このチャートはいくつかの興味深い点を示しています。記事のスコアは急速に上昇し、その後数時間かけてゆっくりと低下します。スコアリング計算式はこの大部分を説明しています。一定の投票率を得ている記事は急速にピークに達し、その後徐々に下降します。しかし、観測されるピークはさらに速いです。これは、記事が最初の1〜2時間で多くの投票を得る傾向があり、その後投票率が低下するためです。これら2つの要因を組み合わせると、示されている急峻な曲線が得られます。

毎日、他の記事を大きく上回るスコアを持つ記事がいくつかありますが、中間に位置する記事も多数あります。非常に良いスコアを持つ記事でも、より人気のある記事の後ろに詰まってしまう不運なものもあります。他の記事は、1つの記事が落ち、別の記事が上がる間に、短時間だけ1位になります。

生スコアが最も高い記事（グラフの上部）と、最もランクの高い記事（赤い線）との差を見ると、ペナルティがいつ適用されたかがわかります。記事「Getting website registration completely wrong」は早朝に1位に達しましたが、論争によるペナルティを受け、急速に順位を落とし、「Linux ate my RAM」が短時間1位になるのを許し、その後「Simpsons in CSS」に追い抜かれました。少し後、「Apple Maps」は1位に達した直後に論争ペナルティを受け、1位の座を失い、急速にランキングを落としました。「Snapchat」の記事はHNのトップに達しましたが、午前8時22分に非常に重いペナルティを受けたため、チャートから完全に消えました。「Why you should never use MongoDB」は非常に人気があり、ペナルティを受けなければ1日中1位を占めていたでしょうが、急速にペナルティを受け、7位あたりに留まりました。「Severing ties with the NSA」はNSAペナルティで始まりましたが、非常に人気があったため、それでも1位を獲得しました。しかし、すぐにさらに大きなペナルティが課され、順位を落としました。最後に、一日の終わりに「$4.1m goes missing」がペナルティを受けました。結果として、ペナルティがなくてもすぐに「FTL」に1位を奪われていたでしょう。

緑色の三角形とテキストは、「論争」ペナルティが適用された場所を示しています。青色の三角形とテキストは、記事がペナルティによって消滅し、上位60件から脱落した場所を示しています。より軽いペナルティはここでは示されていません。

HNの1位の記事の内容が、あなたが期待するような「自然な」ものではなく、多くの記事に対する継続的なペナルティの適用結果であることは明らかです。これらのペナルティがHN管理者によるものか、フラグ付けされた記事によるものかは不明です。

自動的にペナルティを受ける投稿

一部の投稿は、タイトルに基づいて自動的にペナルティを受け、その他はドメインに基づいてペナルティを受けます。タイトルにNSAが含まれる記事は、自動的に0.4のペナルティを受けるようです。私はawesome、bitcoin、bubbleのような他の単語が自動ペナルティを引き起こすか探しましたが、それらはペナルティを受けていないようです。多くのウェブサイトが0.25から0.8のペナルティを自動的に受けるように見えます：arstechnica.com、businessinsider.com、easypost.com、github.com、imgur.com、medium.com、quora.com、qz.com、reddit.com、rt.com、stackexchange.com、theguardian.com、theregister.com、theverge.com、torrentfreak.com、youtube.com。実際のリストはもっと長いと確信しています。（これは「禁止」サイトとは別です。禁止サイトはかつてリスト化されていました。）

ETERMによる興味深い理論の1つは、人気のあるソースからのニュースは複数のユーザーによって並行して投稿され、記事の「価値」以上のアップボートを得るというものです。人気のあるウェブサイトに自動的にペナルティを課すことは、この効果を相殺するのに役立つでしょう。

ペナルティの影響

スコアリング計算式を使用すると、ペナルティの影響を計算できます。記事が0.4のペナルティ係数を受け取ると、それは各投票が0.3票しかカウントされないのと同等です。あるいは、記事は通常より66%速くランキングを落とします。0.1のペナルティ係数は、各投票が0.05票しかカウントされないか、記事が通常の3.6倍の速度で低下することに対応します。したがって、0.4のペナルティ係数は大きな影響を与え、0.1は非常に深刻です。

論争：Hacker Newsでの炎上を防ぐため、コメント数が「多すぎる」記事は「論争のある」として厳しくペナルティを受けます。公開されているコードでは、contro-factor関数は20コメントを超え、かつコメント数がアップボート数よりも多い投稿に対して有効になります。そのような記事は(votes/comments)^2でスケーリングされます。しかし、実際の計算式は異なります。コメント数がアップボート数よりも多く、かつ少なくとも40コメントがある投稿に対して有効です。経験的なデータに基づくと、指数は2ではなく3であると疑っていますが、証明はしていません。論争ペナルティは、記事のランキングに突然壊滅的な影響を与える可能性があり、ある瞬間に高くランク付けされていた記事が、コメント数が40に達したときに消滅することがあります。人気のある記事が突然フロントページから消える理由を不思議に思ったことがあるなら、論争がその原因である可能性が高いです。例えば、「Why the Chromebook pundits are out of touch with reality」は、コメント数が40に達した瞬間に5位から22位に落ち、「Show HN: Get your health records from any doctor'」は17位でしたが、コメント数が40に達したときにトップ60から完全に消えました。

私の方法論

私は毎分 /news と /news2 のページをクロールしました（毎分2ページというガイドラインを下回るようにしました）。（やや見苦しい）HTMLをBeautiful Soupで解析し、結果を大量のPythonスクリプトで処理し、理解不能だが強力なmatplotlibでグラフ化しました。分析の基本的な考え方は、計算式を使用して生スコアを生成し、異常を探すことです。ある時点（例：11/09 8:46）で、上位10件の記事の生スコアを計算できます：

2.802 Pyret: A new programming language from the creators of Racket
1.407 The Big Data Brain Drain: Why Science is in Trouble
1.649 The NY Times endorsed a secretive trade agreement that the public can't read
0.785 S.F. programmers build alternative to HealthCare.gov (warning: autoplay video)
0.844 Marelle: logic programming for devops
0.738 Sprite Lamp
0.714 Why Teenagers Are Fleeing Facebook
0.659 NodeKnockout is in Full Tilt. Checkout some demos
0.805 ISO 1
0.483 Shopify accepts Bitcoin.
0.452 Show HN: Understand closures

上位10件の記事のうち3件（The NY Times、Marelle、ISO 1）がスコアから予想されるよりも低くランク付けされていることに注意してください。The NY Timesは1.407と0.785の記事の間にランク付けされているため、そのペナルティ係数は0.47から0.85の間で計算できます。同様に、他のペナルティは0.87から0.93、そして0.60から0.82でなければなりません。ほとんどの記事はスコアに従ってランク付けされており、例外は一貫して大幅に低くランク付けされていることから、ペナルティが示唆されていることを観察しました。これは、使用されているスコアリング計算式が公開されているコードと一致することを示しています。もし計算式が異なり、例えば重力指数が大きければ、投票数や経過時間が増えるにつれて記事が「期待される」ランキングから外れていくのを見るだろうと予想しますが、そのようなことは一度もありませんでした。

この手法はペナルティの存在を示し、ペナルティの範囲を与えますが、正確なペナルティを決定することは困難です。時間の経過に伴う範囲を見て、単一の値に収束することを期待することができます。しかし、いくつかのエラー源がこれを妨げます。第一に、隣接する記事にもペナルティが適用されているか、スコアが異なる場合があります（例：求人情報）。第二に、記事は常に再ランキングされるわけではないため、一時的に順位がずれることがあります。第三に、記事へのペナルティは時間とともに変化する可能性があります。第四に、「悪い」投票が抑制されるため、報告された投票数は実際の投票数と異なる場合があります。その結果、おおよそのペナルティを決定することはできましたが、数値的な不安定性がかなりあります。

1日のペナルティ

以下のグラフは、1日の経過に伴う計算されたペナルティを示しています。各線は特定の記事を示しています。ペナルティが適用されると、最初は1（ペナルティなし）で始まり、その後ペナルティレベルに低下します。記事が上位60件から外れると線は終了します。これはペナルティ適用後すぐに起こることがあります。0.2と0.4のペナルティ、および0.8〜0.9の範囲のペナルティが多くあるようです。午前9時（モデレーターが到着する時間？）に多くのペナルティが適用され、その後も1日を通してさらに適用されているように見えます。このグラフはかなりノイズが多いので、改善するために異なるアルゴリズムを試しています。［画像］(http://static.righto.com/images/Ken_Shirriffs_blog/hn_penalties.png)

平均して、フロントページの約20%の記事がペナルティを受けており、セカンドページの38%の記事がペナルティを受けています。（フロントページの割合が低いのは、ペナルティを受けた記事は定義上、フロントページに載りにくいためです。）予想よりもはるかに多くのペナルティが適用されています。

以下は、11月11日にフロントページに掲載されたペナルティを受けた記事のリストです。（もしペナルティを受けなければ掲載されていたであろう記事は除外しています。）このリストは予想よりもはるかに長いです。すべて表示するにはスクロールしてください。

Why the Climate Corporation Sold Itself to Monsanto, Facebook Publications, Bill Gates: What I Learned in the Fight Against Polio, McCain says NSA chief Keith Alexander 'should resign or be fired', You are not a software engineer, What is a y-combinator?, Typhoon Haiyan kills 10,000 in Philippines, To Persuade People, Tell Them a Story, Tetris and The Power Of CSS, Microsoft Research Publications, Moscow subway sells free tickets for 30 sit-ups, The secret world of cargo ships, These weeks in Rust, Empty-Stomach Intelligence, Getting website registration completely wrong, The Six Most Common Species Of Code, Amazon to Begin Sunday Deliveries, With Post Office's Help, Linux ate my RAM, Simpsons in CSS, Apple maps: how Google lost when everyone thought it had won, Docker and Go: why did we decide to write Docker in Go?, Amazon Code Ninjas, Last Doolittle Raiders make final toast, Linux Voice - A new Linux magazine that gives back, Want to download anime? Just made a program for that, Commit 15 minutes to explain to a stranger why you love your job., Why You Should Never Use MongoDB, Show HN: SketchDeck - build slides faster, Zero to Peanut Butter Docker Time in 78 Seconds, NSA's Surveillance Powers Extend Far Beyond Counterterrorism, How Sentry's Open Source Service Was Born, Real World OCaml, Show HN: Get your health records from any doctor, Why the Chromebook pundits are out of touch with reality, Towards a More Modular Future for JavaScript Libraries, Why is virt-builder written in OCaml?, IOS: End of an Era, The craziest things you can plug into your iPhone's audio jack, RFC: Replace Java with Go in default languages, Show HN: Find your health plan on Health Sherpa, Web Latency Benchmark: A new kind of browser benchmark, Why are Amazon, Facebook and Yahoo copying Microsoft's stack ranking system?, Severing Ties with the NSA, Doctor performs surgery using Google Glass, Duplicity + S3: Easy, cheap, encrypted, automated full-disk backups, Bitcoin's UK future looks bleak, Amazon Redshift's New Features, You're only getting the nice feedback, Software is Easy, Hardware is of Medium Difficulty, Facebook Warns Users After Adobe Breach, International Space Station Infected With USB Stick Malware, Tidbit: Client-Side Bitcoin Mining, Go: "I have already used the name for MY programming language", Multi-Modal Drone: Fly, Swim & Drive, The Daily Go Programming Newspaper, "We have no food, we need water and other things to survive.", Introducing the Humble Store, The Six Most Common Species Of Code, $4.1m goes missing as Chinese bitcoin trading platform GBL vanishes, Could Bitcoin Be More Disruptive than the Internet?, Apple Store is updating.

スコアリング計算式のコード

HNサーバーのバージョンに関するArcソースコードは入手可能であり、更新されたスコアリング計算式もあります。

  (= gravity* 1.8 timebase* 120 front-threshold* 1
       nourl-factor* .4 lightweight-factor* .17 gag-factor* .1)

    (def frontpage-rank (s (o scorefn realscore) (o gravity gravity*))
      (* (/ (let base (- (scorefn s) 1)
              (if (> base 0) (expt base .8) base))
            (expt (/ (+ (item-age s) timebase*) 60) gravity))
         (if (no (in s!type 'story 'poll))  .8
             (blank s!url)                  nourl-factor*
             (mem 'bury s!keys)             .001
                                            (* (contro-factor s)
                                               (if (mem 'gag s!keys)
                                                    gag-factor*
                                                   (lightweight s)
                                                    lightweight-factor*
                                                   1))))) 

Arcコードを読めない方のために説明すると、上記の抜粋はいくつかの定数を定義しています：gravity* = 1.8、timebase* = 120（分）などです。次に、ストーリーsをアップボート数（realscore）と経過時間（分）（item-age）に基づいてランク付けするfrontpage-rankメソッドを定義しています。ペナルティ係数は、いくつかのケースを持つifによって定義されます。記事が「story」または「poll」でない場合、ペナルティ係数は0.8です。それ以外の場合、URLフィールドが空白（Ask HNなど）であれば、係数はnourl-factor*です。ストーリーが「bury」としてフラグ付けされている場合、スケール係数は0.001で、記事はランキングから消滅します。最後に、デフォルトケースは論争係数とgag/lightweight係数を組み合わせます。論争係数contro-factorは、炎上を引き起こしている記事を抑制することを目的としており、後で詳しく説明します。

次の係数は、ジョーク（gag）としてフラグ付けされた記事に重い値0.1を、そして「lightweight」記事に係数0.17を適用します。実際のペナルティシステムは、公開されているコードにあるものよりもはるかに複雑であるようです。

結論

Hacker Newsのホームページでの記事の順位は、あなたが期待するようなアップボート数に基づく実力主義ではありません。Hacker Newsのページに表示される記事を注意深く調べることで、使用されているスコアリング計算式について多くのことを学ぶことができます。アップボート数はランキングを制御する明白な要因ですが、記事を低くランク付けしたり完全に消滅させたりする複雑な「ペナルティ」システムも存在します。これは単なるスパム防止だけでなく、多くの非常に人気のある記事にも影響を与えます。そして、記事のコメント数が投票数よりも多い場合は、それにコメントを追加しないでください。そうしないと、記事を完全に消滅させてしまうかもしれません！Hacker Newsでの議論を参照してください。

更新（11/18）：ペナルティを受けた記事

皮肉なことに、この記事はHacker Newsでペナルティを受けました。フロントページに到達してから数分後、記事に重い0.2のペナルティが適用され、フロントページから追い出されました。下のグラフの黒い線は、この記事のHacker Newsでの順位を示しています。ペナルティが適用されたときの急激な低下が見られます。灰色の線は、ペナルティがなかった場合の記事の順位を示しています。ペナルティがなければ、記事は5位になっていたでしょうが、ペナルティがあったため、フロントページ（1〜30位）に戻ることはありませんでした。下の緑色の線は、この記事の生スコアを示しています。（11/26：ペナルティは「投票リング検出」が誤ってトリガーされたためだと聞きました。）
［画像: この記事はHacker Newsのフロントページに到達 shortly after receiving a penalty］