そもそもこの記事は何？
- 自分のアイデアの書きなぐり
高校時代(2016~2019)
あるwebサイト運用している物理的に離れている複数のwebサーバーでRAIDを組む
なぜこれを考えたのか
- 同一のデータを複数サーバーに保存したかった
- これによりユーザーから(物理的に)一番近いサーバーに接続することで遅延を小さくできるのではないかと考えた
- 当時はRAIDでデータの同期ができると思っていた
現実
CDNでやりたかったことが実現されてた- そもそもRAIDはそんな使い方想定してない
重複を考える必要のないID生成
なぜこれを考えたのか
- 発行済みのIDと被っていないか検証する良いアルゴリズムを思いつかなかった
構想
- 時間(sec単位)と乱数(数桁)をつなげれば良いのでは
- 当時は誕生日のパラドックスの事を知らなかった＆考えてもいなかった
現実
UUIDv7登場
大学時代(2019~2023)
スマートフォン同士でP2P通信をすることで災害時でも使えるアプリ
なぜこれを考えたのか
- 現在の通信インフラに頼ることなく通信の必要があると考えた
- 停電による基地局の機能停止
- 登山中の遭難
- P2Pでなんかやってみたかった（ブロックチェーンブームだったし・・・）
構想
- 端末Aが端末Bにメッセージの送信を試みる(ただし端末Aはアンテナが立っていない)
- 端末Aの近くを端末Cが通る
- その際端末Aは端末Cに端末B宛のメッセージを送信する(端末Cのユーザーは内容を見ることができない)
- 端末Cは既存の通信インフラが整っている地域まで移動する
- 端末Cは端末B宛に端末Aから送信されたとしてメッセージを送信する
- 端末Bは端末Aからのメッセージを受信する
現実
- アプリを大勢の人に使ってもらう必要がある
- 現実的に一個人のアプリでは無理な量
- AirTagが似たようなことやった・・・
- AirTagの近くを通った別ユーザーのiPhone経由でAppleのサーバーにAirTagの位置情報を送る
同じ講義を受けている人が抗議の情報を追加したら全員に反映される時間割アプリ
なぜこれを考えたのか
- コロナ禍により同級生としゃべらなくなった
- 講義の情報が入りづらくなった(課題の締め切り日など)
構想
- 同じ講義を取っているA, B, Cがいる
- Aが講義の中で出された課題の締め切り日などをアプリに登録する
- B, CがAの登録した情報を確認できる
- これにより仲の良さに関わらず情報共有ができると考えた
現実
- アプリを作成し、技育展2021で登壇した
- ユーザーを獲得するのはとても大変ということを思い知らされた
HDDのプラッタを乱数テーブルとして乱数生成
なぜこれを考えたのか
HDD上に保存されるデータの位置はデバイスにより異なる＆書き換わるため、これを元に乱数生成可能ではないかと考えた。
構想
- HDDのヘッドを往復させプラッタのランダムな位置のセクタのデータを取得する
- ヘッドを適当に動かすためセクタのデータは意味をなさず、ファイルシステムのランダムな位置のデータを取得する
- セクタのデータは上記よりランダムなため、乱数生成可能と考えた
現実
- 大容量のHDDはほとんど書き換わらないであろうから乱数生成の種としてはあまりに脆弱
-
/dev/randomでいいじゃん
社会人時代(2023~)
脳を模したデータの保存
なぜこれを考えたのか
- 昨今話題のLLMなどは深層学習を使用している
- 深層学習のモデルはニューラルネットワークを模している
- したがって脳を模倣したデータの保存ができるのではないか
- 深層学習のモデルはニューラルネットワークを模している
構想
※生物あまりわからないので想像を含む
- 脳はニューロン同士が結合している
- 脳が処理(画像処理・自然言語など)する部分の模倣は可能である(GAN・LLMなど)
- 脳が保存する部分も可能ではないか
- ベクトルデータベースによる単語の結びつきなど
もっと言うとより汎用的なグラフDBにデータを保存することで、脳の模倣をよりうまくでき、様々な学習モデルの精度向上が狙えるのではないか
つまり学習モデルをI/Oとし、グラフDBを海馬のように扱うことでより汎用的で精度の良いAIの作成が課のではないか？
懸念点
- 学習モデルをI/Oとした場合、おそらくグラフDBに保存されるデータを人間が読むことは不可能
日本語LLMのモデル案
なぜこれを考えたのか
- 英語で文章を作成する際はa~zまでの26種類が必要である。一方日本語で文章を作成するには英語に比べ非常に多い種類(ひらがな・漢字)が必要である
- そこで日本語の文章を生成する際は2つのモデルを使用することでより汎用的なLLNを作成することが可能ではないか
構想
- モデルは下記の2つをつなげる
- ひらがなの文章を作成するモデル
- ひらがなを漢字・カタカナに変換するモデル
このように分割することで、今までより小さい変数での言語モデルの生成が可能である。
また変換部分を別モデルとしたことで、既存の漢字等への変換アルゴリズムの使用や特殊な用語への対応が容易に対応可能となり、より汎用的なLLMの作成が可能ではないかと考える。
また、この変換モデルを別言語へ変換するモデルにすることで翻訳も可能になるのではないかと考える