t_wの輪郭

輪郭法のファイルシステム化

デライトをGoogleドライブみたいにするというアイデア

理屈上はマルチプラットフォームで動くやで
Web Bluetoothの対応状況があれなので開発に手を付けてない

Issue起票とかの文章を書くLLM App

おそらく一般的には応類と向類は同じ言語モデルで生成して検索に用いるのだが、応類と向類で異なる言語モデルを用いることで以下の利点が得られる。

• 利用者の動向から向類を学習させ、漸次的に検索精度を向上させる
• 利用者の動向から向類を学習させ、漸次的に個々の利用者に対して検索結果を変化させる
• 上記をしつつ、更新費用が高くなる応類を不変あるいは低頻度での更新と出来る

レコメンドにおいても同様のことができ、同じような利点が得られる。

Two-Towerモデルと同一。

ActivityPubでつながるデライトサーバー群というアイデア・憧憬。
セルフホスティングされた複数のデライトサーバーがActivityPubでつながる。

プロトコルがAcitivityPubである必然性は無く、独自プロトコルでも良い。

AWSでベクトル検索しようとするとAmazon OpenSearchとかいうのを使うのが正攻法なのだけど、OpenSearchはEC2インスタンスが立ち上がってしまって費用的にも労力的にも良くない。そこで、ベクトル検索ライブラリで生成したインデックスをAmazon DynamoDBのインデックスにすればサーバーレスで安価に運用できる気がしている。

未検証。できるかどうか不明。果たして、任意のインデックスをレコードに設定することができるのか？

というか、そういう機能をAWSが作るべきだと思う。作るでしょ。そのうち。