完璧じゃないシステムが実は優れた理由：Blueskyのロス情報タイムラインに迫る！

リンク先の記事によると、“投稿への参照がフォロワーに’ファンアウト’される”らしいから、内容じゃなくてリンクだけみたいだね。

システム好きだからこういう記事は面白いな。完璧を求めるのって簡単だけど、Blekkoの検索エンジンでは、’最終的に一貫性のある’インデックスを作ったから、更新がすぐに反映できたけど、同じクエリでも結果が少しずつ違ったんだ。面白いシステムだよね。

検索エンジンがクリックするたびにページを再ランキングしてるのは考えたことなかったな。DuckDuckGoの結果がシャッフルされてるのはバグだと思ってた。

現在のウェブインターフェースの基本的な使いやすさの不満に繋がってると思うのは、広告やおすすめコンテンツが安定しないことだね。好きな広告を見てから別のコンテンツに行きたくても、もう見られないことが多いんだ。

＞考えていれば別タブで開けるよね。　それか「後で見る」リストに追加するのもありだね。

DDGは使ってないけど、試した感じではページをリロードしない限り結果はシャッフルされないみたい。もしかしてブラウザが戻るときに再読み込みしてるのかも。新しいタブでリンクを開く設定にすれば良いかも。

面白いね。設定になにか影響してるかもしれないから、調べてみるよ。

最近、結果が変わる現象に気づいた。クリックして戻ると、検索結果が違ってるんだ。対策としては、DDGの検索ボックスに戻ってエンターを押すと、元の検索結果に戻るよ。

こんにちは、DuckDuckGoの検索担当なんだけど、その問題について詳しく教えてもらえますか？再現するための手順を教えてほしいです。

最適化のための微妙なアルゴリズムの調整をするのが面白いよね。初期のマイクロサービスの頃に、舌の重さを手動で調整してれば、もっと時間を節約できたかも。

Google画像検索が最初に下品質のぼやけたサムネイルを表示して、ユーザーが早く読み込まれたと思わせるのと同じ感じだね。

完璧さの問題じゃなくてトレードオフの話だね。物理法則的に、NYCとロンドンのデータ同期に限界があるから、CAPスタイルのトレードオフを選ぶ必要がある。それにお金とサービスレベルのトレードオフもあるし。

Blekkoでのクリックランク付けについて詳しく教えてもらえないかな？面白い問題だと思うんだけど。

Blekkoはどうなったの？

＞”2015年3月にIBMに買収されてサービスは終了した。”
よかったら詳しい答えを聞かせてほしいな。

正しい答えだね。IBMは主にWatsonのためにクローラーを求めてた。英語のフル検索エンジンを作るのは大変だったけど、Blekkoが買収された時にはGoogleが検索クエリによって数十億ドルを支払っていて、広告収入だけでやっていくのが難しかったんだ。

Blekkoは無くなった時に知ったんだ。最近、Blekkoで働いていた人に意見を聞いてみたら、Googleと競うのはやめた方がいいって言われたよ。P2P検索エンジンのアイデアがあるんだけど、まだ始めてないんだ。

P2Pは難しいよね。フルスタック検索エンジンを作るには、10Gのネットワークに接続して2500台のマシンが必要だし、それだけで月10万ドルはかかる。開発費用を考えたら利益を出すのは厳しいよ。

分からないことがあるって、なんも知らん状態から始めるのは大変だね。検索や映像に参入するには何か収益性の高いプロダクトが必要だってのは明らかだ。情報提供ありがと！

Darknet Lanternは分散型の検索可能なディレクトリだね。多分、流行ることはないと思うけど、なんか別のものをインスパイアするかも。サーバーが同じソフトで他のサーバーのデータをスパイダーして同期する仕組みなんだ。

そうそう、ディレクトリサービスはピアツーピアでやる方が簡単だよね。Pinboard.inは良い共有ディレクトリで、Yahoo!の編集版って感じ。誰かがインデックスしたものを探すときは質がいいけど、全ての答えには返りが悪い。編集なしのピアツーピアでやれば、サイトは容易にインデックスに入れるけど、それなりの利点と欠点がある。

これまで聞いたことなかったけど、面白そうだね。教えてくれてありがとう！

私の質問じゃないけど、面白い歴史の話をありがとう。他の読者のために、Kagiが大好きだって言っとく。超おすすめ。

Neevaが成功すると思ってたけど、退出した後にKagiが現れてくれてよかった。

ちょっと興味あるんだけど、この戦略は一貫性を犠牲にしてるから、全ての読み込みや書き込みでフルファンアウトじゃない何かについて考えたことある？例えば、ユーザーのタイムラインに書き込むのをシェアにして、フォロワーがいるシャードに一度書くって感じ。これで書き込み時のファンアウトを数百シャードに制限できる。読取時は、そのホットスライスを取得して、実際のフォロワーをフィルタリングする。理解はできるけど、負荷はどうなるのかな？テストするデータがないから分からないんだ。

ちょっと混乱してる。ロスイータイムラインの解決策は、フォロワーが多すぎる人のフィードをスキップするってことだよね。96％の改善があるのは凄いけど、そんなに多くの人が不合理な数の人をフォローしてるのか、それともフォロワーの数が少ないってこと？後者だとは思えないな、そうなると多くの人が更新を見逃すはずだから。

システムが「オーバーロード」になると、パフォーマンスが指数的に悪化する状態に入るんだ。そうなると自己DDoSになる。> 96％の改善は凄い。このTFAはP99のテールレイテンシーについて話してるから、テールレイテンシーを大きく減少させるのはそんなにおかしいことじゃないよ。要はレイテンシー分布を形作り直すってこと。ここでは病的なケースが排除されるんだ。

＞ より多くのユーザーが不合理な数の人をフォローしてるってこと？OnlyFansモデルや仮想通貨のインフルエンサーのアカウント見てみなよ。何千、何万ものアカウントをフォローして、こっちがフォローしてくれるのを期待してるんだ。

この行動を受け入れるのが社会的に良いとか技術的に望ましいとは思えない。使い道があるか考えてみてよ。いろんなボットがこのアクセスを求めてるけど、非分割でこれを許可する正当な理由があるかは別問題だし、こういうクエリはリソースを不均衡に使う問題があるんだ。

時間が経てば、実際のユーザーが多数のアカウントをフォローするけどほとんど関わらない状況が増えるよ。例えばYouTubeでも登録者数が視聴者数より多いのは珍しくない。これは特に怪しいことではない。Blueskyはまだ若いから、フォロワー数が多いのが悪意のある人ばかりなわけではないけど、悪意のあるユーザーを完璧に見分けるアルゴリズムはないんだ。悪影響を抑える意味で、全体の使いやすさを維持するのが合理的だよ。

TFAによると、こういうユーザーによる負荷を避けるためにポリシーやモデレーションが必要で、それには時間もかかるし不完全さもある。だから、エンジニアは完璧なモデレーションは難しいことを理解して、インフラをそのためにデザインするべきだね。

彼らは確かに多くのユーザーが非合理的な数のアカウントをフォローしてるよ。Blueskyにはフォロー返しを狙うユーザーがいるからそういうことになる。

彼らは特に最悪のパフォーマンスを見ていたよ。P99というのは99パーセンタイルのことで、最悪の1パーセントのジョブで96％の改善を見たってことだ。

うーん。Twitter/Xはすでに1200人でかなりロスが多いみたいだね。フォローしている人が永久に消えていることがあるから、本当にイライラするよ。ロスの調整はしているのかな？もしそうでないと、上限が低すぎるとユーザー体験には悪影響が出ちゃう。

1200人は本当に何もないよ。特にソーシャルメディアに関連する仕事をしている人にはね。君は50人の知り合いをフォローしてるけど、彼らは1200人の情報源を持ってるんだ。この話は何百万というフォロワーがいる人たちのことを指してるよ。

なんで1200人もフォローしてるの？あなたのホームフィードの目的は何？何を見たいの？

非時系列のタイムラインがある理由を発見しそうだね。週に一度は興味深いことを投稿する1200人の人がいるのは想像できる。しかし、興味のないものが100件あれば、どうやって興味深い投稿を見つける？それを公平にする方法も難しいんだ。

俺は常に時系列で見るのが好きなんだ。オンラインで投稿してる人たちとその場で話せるのがいいんだよね。投稿した人にすぐ返信することで会話が生まれて、もっと仲良くなれると思う。

知ってる人ばかりで、その98％が相互フォローだよ。5〜6ヶ月ごとにフォローしてるアカウントを見直していて、関係が途切れた人や非アクティブな人は削除してる。Twitterには関係性の高い部分があって、他の人のコメントやリツイートで知り合うことが多いんだ。

＞何を見たいの？
興味のある内容を投稿しているアカウントのスクロールできるフィードが欲しい。

Twitterには面白い人がたくさんいるよ。

Twitterにフォローしたい人が100人はすぐに思いつくけど、アカウントも持ってない。理解できない使い方を否定しないで欲しい。

＞さらに、この点を超えて、たくさんのユーザーが投稿するすべての内容の完璧な時系列を持つ必要はないけど、常に新しいコンテンツがあるようにすればいいんじゃないかと思う。
俺はこの解決策には満足してるけど、この文面から解決策が不完全な時系列になると思ってたのに、フィードから投稿が落ちてしまうとは思わなかった。

もし4千人フォローしてて、50％のドロップ率だとしたら、全員がその日に投稿しないとしたら、唯一投稿した1人のアカウントも50％の確率で見逃すのは変だと思う。アルゴリズムはフィードの古さやフォロワーの投稿の新しさを考慮すべきじゃない？考えすぎかな？

これはエッジケースのように感じる。
「合理的な制限」はおそらく実験に基づいて決められてるから、実際の数が「2000」ちょうどになるとは限らないと思う。たくさんフォローしてると、その投稿パターンが平均とかなり違う可能性は低いだろうし。理論上この状況になり得ても、非常に珍しいケースになるはず。

’大数の法則’によれば、4千人フォローしても誰も投稿しないのはありえないと思う。アクセスしたければ全員をフォローすればいいし、jetstreamイベントフィードから必要な情報を引っ張るコードを書けば済む。
https://docs.bsky.app/blog/jetstream

これはちょっと心配。新しいプラットフォームだから今は問題ないかもしれないけど、アカウントが非アクティブになると、自然と“死んだ”アカウントをフォローすることになる。Facebookだと社交的な人の古いアカウントが友達を何千人も集めることは珍しくない。彼らが測ろうとしているのは“忙しいタイムライン”で、もっと直接的に測定できる方法があると思う。例えば、過去24時間のタイムラインの投稿数みたいな。

フォロワーが何十万人もいるアカウントは、内容をスクレイピングするボットアカウントだろうね。バンするべきだと思うけど、技術的なチャレンジは面白いな。Twitterには有名人用の特別なアーキテクチャがあるらしいけど、Blueskyはその手法を取り入れなかったのが気になる。

誰かをフォローする必要はないし、アカウントもなくてもコンテンツをスクレイプできるよ。大量のアカウントをフォローするのは、フォローバックを狙ってる場合が多い。

＞“Blueskyはクワジクローンなのに、なぜそんな道を進まなかったんだろう？”
フォロワーが100万を超えるユーザーは6人しかいないし、まだ200万人には達していないけど、きっとそのうち行くよ。

何十万人もフォローするわけじゃないけど、興味のある人は誰でもフォローして、主にカスタマイズしたフィードを使うかな。例えば、労働組合のニュースや、俺の実生活のネットワークなどをチェックするためのフィード。

コンテンツを全部スクレイプしたいなら、ファイアホースを使うのが適してるし、それは許可されてる。大量フォローの理由はスパム目的だけだね。

この前提は、スクレイパーが賢いことを想定してるけど、実際はそうじゃないことが多いんだ。彼らはスケールでHTMLをスクレイプするためのインフラを持っていて、それを使う。Wikipediaもトレントでフルアーカイブを提供してるのに、スクレイピングのトラフィックには苦労してるし、同じようにスパマーと“クラウトファーマー”だね。

100％同意。俺も求人情報ボードを運営してたけど、ちゃんとしたXMLフィードを提供してても、ボットは標準の検索ボックスを使うことにこだわってた。
地理的検索が最も高コストなのに、どんな手を使ってもそいつらをXMLフィードに使わせることができなかった。ボットを検知したときにはフィードへのリンクを返そうとしたけど、全く効果がなかった。

BlueSkyには、ボタン一つで大量フォローできるStarter Packsがある。1日に10個のStarter Packに参加すれば、1000人以上をフォローしてしまうこともある。人と関わってもらうには、他人をフォローすることが唯一の手段になることもあるね。

それとも、フォローするアカウントの最大数を制限すればいいんじゃない？

SNSのやり取りに上限を設定しても、誰かがその上限に達して文句を言うに決まってるよね。Blueskyが“ソフトリミット”を選ぶ理由が分かる気がする。上限を超えると体験が劣化するから、後で調整もできるし、影響力のあるユーザーからのうるさい文句を防げるもんね。

最初の文句に対して何らかの解決策を講じても、他のことで文句を言う人がいるんじゃないかな。合理的な製品機能を実装して、反対意見に対する文句が出るのは受け入れるべきだと思う。

提案としては、ユーザーをシステマティックにフォロー解除できるようにするか、別のフィードに移動させるのがいいかも。例えば、最近の活動や投稿の内容に応じて、自動的に特定の人をフォローすることができるとか…。いろんな基準で分けられれば、もっと使いやすくなるね。

あるユーザーのプロフィールに行くと、タイムラインにあるべき投稿が見えないことがあるんだよね。Blueskyで100人もフォローしてないのに、やっぱりこの理由で見逃しちゃうのか。まさにロスイだね。