11/28/2021, 1:52:00 PM
今までの検索サイトのビジネスモデルでは、検索サイトと検索によって表示されるサイト（以降「被検索サイト」と呼称）の間には互恵関係があった。検索サイトから個々のウェブサイトへ閲覧者が流入するという利点が被検索サイトにはあった。
LLMが検索サイトに搭載され、検索語で知りたい情報が検索サイト自身に表示されるのであれば、被検索サイトのページビューは減少する。
閲覧者の流入がないのであれば、被検索サイトにとって検索サイトが敵になる。クロールされ、負荷を強いられ、情報を搾取されるようになるからだ。今までは被検索サイトは得られる利益と引き換えに、こうした問題を受忍してきた。しかし利益がなければ受忍する道理はない。
故に、被検索サイトもAI絵師の問題と同様に、サイトからの情報を学習に利用されることを拒否するようになる。
そうして出てくるのは、LLMを搭載したブラウザやOSだ。利用者の手元でLLMが動作し、情報を収集し、利用者の問い合わせに応じて回答する。大規模言語モデルの小規模化もそれを後押しする。
利用者にとってはLLMを通して情報を取得する形となるが、検索サイトは仲介することによる利益を広告として得ることができなくなる。すなわち、情報流通の費用が低減するのだ。
続いて勃興するのはLLMに最適化された情報の提示だ。SEOが検索エンジンに最適化したように、LLMに最適化された情報を提示して、自身の事業に有利な出力をするように仕向ける。その形態はビジュアルである必要がないため、セマンティックウェブ的になる。
購読の意味合いも変わってきて、LLMに食わせる情報源として購読するという形態が発生する。RSSが形を変えて復興する。
プライバシー: ユーザーの行動や興味を反映させるためには、大量の個人データを収集する必要があります。これはプライバシーの問題を引き起こす可能性がある。
しかし、プライバシーの問題はむしろ霧散する。今のLLMは営利企業のサーバーによって実行されており、その際の問い合わせ内容はサーバーに保存される。しかし、各利用者の手元のOSで動作するLLMではその問い合わせ内容は外部に出ることはなく、完全にプライバシーが保護される。
個々のデバイスでAIの訓練を行うというのは、コンピューティングリソースの観点からも難しいかもしれない。
集約されたLLMと個人化されたLLMでは、サーバーで動作する「集約されたLLM」の方が潤沢なコンピューティングリソースを使うことができるため、相対的により“賢い”LLMを利用することができる。そのため、公共知は集約されたLLM、個人知は手元のOSで動作するLLM、のように使い分けることになる。
情報の正確さや信頼性を保証することが難しくなる。ユーザーが選択的に情報をクロールや購読する場合、情報源が偏ったり、誤った情報が混入する可能性がある。また、エコーチャンバーのような問題も生じる。
営利企業が運営するLLMに対しても同じことが言える。営利企業であるがために広告・宣伝・プロパガンダを混ぜ込むなどの意図的な偏りが発生する。
実装して本番環境に反映した。
アレです。トップページに遷移した時に、こう、RSSの登録とかTwitterのフォローをお勧めする的なことがしたい。リストビルディングを進めたい。現状だとRSS登録したり、Twitterアカウントをフォローしたりといったことが全然されていない。
pg=0の時だけ（というかpgがついてないときだけ）説明を多く表示する。
発想元：
– https://html.spec.whatwg.org/multipage/
RSSのサイトURLが間違っているのを修正
RSSのdescriptionの説明文を修正すること ひとまず不要と判断。より良い説明文が思いついたら編集する。
RSSのサイトURLが間違っているのを修正すること DONE
RSSの配信を実装したもののまだ不具合がある。コンテンツを正しく表示できない。
また、試験体制にも問題がある。RSSリーダーのキャッシュによって、変更の確認が難しくなっている。
結局手動でSNSに共有と、RSSが有力か。
プッシュ通知を実装してもいいかもしれない。私自身は普段ウェブサイトのプッシュ通知を有効化しないが、有効化してくれる人がいれば強力な通知方法になる。
購読
待っ読
RSS
フォロー
継続して読む
RSSでフォローする
https://trends.google.co.jp/trends/explore?date=all&geo=JP&q=RSS,Feedly,Facebook,Twitter
RSSのサーバー側の実装が終わった後にGoogle Trendsで調べることに思い至った。
RSSとFeedlyを、TwitterやFacebookと比較すれば一目瞭然だ。やるべきはSNSからの流入を目的とした機能の実装だろう。
RSSリーダーの購読機能はSNSにざっくり代替された
これなんだよなぁ……
「RSS対応する暇あるならSNSに対応する」というのが合理的な態度というものなんだろう。
デライトの共有ボタンを使って外部サービスと連携し、輪郭の更新履歴を簡単に残せないかと考えたが、共有できるのはURLだけみたいだ。
更新履歴を残すだけであれば、生のHTMLをスクレイピングするよりも、RSSの取得のほうが良さそうだと思ったのですが、長文になると切り詰められるので不向きですね。
https://dlt.kitetu.com/?fg=KNo.EDD2/2AAB&fmt=RSS2
輪郭分居を実現するには、輪郭のフォローが必要になる。Twitterが利用者のフォローで待欄を構築するように、デライトでは輪郭をフォローして待欄を構築する。ようになるかもしれない。
実際、「更新を待っ読」で輪郭をRSSで待っ読（フォロー）することができる。将来的にこれがデライト上でできるようなイメージだ。
ただ、下記の投稿などを見るにデライト開発者には輪郭のフォロー機能を開発する意思はないかも知れない。
フォローという仕組みが無い SNS が，つまり KNS（knowledge networking service）ということになるんだろうな。
いっそのこと，フォローという仕組みがない SNS が普及したら，世の中少し変わってくるかもしれない。心地良くはないから，普及させるには別の魅力が必要になってくるだろうけど。
