500MBあるBERTをONNXに変換した後に量子化したら110MBほどになってLambdaで動かせるようになった。
Githubに乗せるファイルは100MB以下でないとだめなので、ダメ押しでgzipで圧縮したら75MBになった。
500MBあるBERTをONNXに変換した後に量子化したら110MBほどになってLambdaで動かせるようになった。
Githubに乗せるファイルは100MB以下でないとだめなので、ダメ押しでgzipで圧縮したら75MBになった。
特に記憶に無いです。
「Next.jsを使えば忌々しいAmplifyのDataStoreを無くせるんじゃね?」とか思って、社内システムの移植を開始した。もともとReactで動いていたので、3時間ほどでシステムがNext.jsの上で動くようになった。Next.jsの恩恵が受けられるのはこれからだ。
「Next.jsを使えばBERTでSentence Embeddingを取るAPIをサーバーレスでつくれるんじゃね?」とかおもって実装した結果、比較的高性能な開発機であっても計算に3秒もかかることがわかり、検索には使えず無事死亡した。
「あれ」ってどんなんだったっけと思って、デライトで検索しようとしたところ、デライトが落ちていた(障害のお知らせ)。普段当たり前のようにデライトが使えているが、knownetの開発を通じてデライトが安定稼働していたことの異常さに気付きつつある。knownetの方はちゃんと動いている期間のほうが短い。
探そうとしていた情報については『t_wの輪郭』を参照して見つけられた。いざというときの保証として機能してくれた。
検索結果の候補として、知名とトークンが一致した輪郭に加えて、そこから前景後景を2回まで辿った輪郭も、検索候補とする。これにより、類義語を考慮した検索となる。
ベクトル検索と比較して、実装が簡単。ベクトル検索がまだ簡単ではないので。
輪郭の順位づけに、輪郭本体のSentence Embeddingに加えて、前景後景のSentence Embeddingを用いる。輪郭単体のSentence Embeddingでは、意図せず順位が高くなる恐れがあるが、互助的に順位を出すことで、より安定した順位付けとなる。
輪郭本体のSentence Embeddingがまだ計算されていない間も、前景後景から補完されて順位付けができる利点もある。