t_wの輪郭

LambdaでBERTを動かして、Sentence Embeddingを取れるようになったぞ！！！

これでやっとBedrockにAIモデルを握られなくて済む。今まで睾丸をグリップされていた。

朝

　特に記憶に無いです。

仕事

　「Next.jsを使えば忌々しいAmplifyのDataStoreを無くせるんじゃね？」とか思って、社内システムの移植を開始した。もともとReactで動いていたので、3時間ほどでシステムがNext.jsの上で動くようになった。Next.jsの恩恵が受けられるのはこれからだ。

夜

　「Next.jsを使えばBERTでSentence Embeddingを取るAPIをサーバーレスでつくれるんじゃね？」とかおもって実装した結果、比較的高性能な開発機であっても計算に3秒もかかることがわかり、検索には使えず無事死亡した。

デライトが落ちていた

　「あれ」ってどんなんだったっけと思って、デライトで検索しようとしたところ、デライトが落ちていた(障害のお知らせ)。普段当たり前のようにデライトが使えているが、knownetの開発を通じてデライトが安定稼働していたことの異常さに気付きつつある。knownetの方はちゃんと動いている期間のほうが短い。

　探そうとしていた情報については『t_wの輪郭』を参照して見つけられた。いざというときの保証として機能してくれた。

いや、「ベクトル検索ぐらいマネージドサービスあるやろ」とはなるんだけど、たけーのよ。Azure Cognitive Searchとか、一番安いので月額1万円以上する。

DynamoDBとLambdaでやりくりすれば、維持費をほぼ0円、処理があっても月額100円ぐらいで何とかなるはずなんや。

で、そのために文章をベクトル化（Sentence Embedding）する処理が必要だったのだけどもですね、世のSentence Embeddingするライブラリやら言語モデル（BERTとか）やらはファイルサイズが巨大で、Lambda関数に乗り切らんかったわけです。

そこで、BERTを小型化したALBERTでSentence Embeddingが取れるように学習してたんですけども、やっとこさそれらしい結果が出せるようになってきた。

となると、次の課題はベクトル検索のDB部分なわけです。今はJavaScriptのライブラリを使ってるので速くないので、Go言語とかでやりたい。

というか、JavaScriptでのSentence Embeddingの計算は遅いはずなので、そこもGo言語に切り替えるうまみがあるはず。

BERTを小さくしたやつ。でも性能はそのまま。と言われている。

BERTとALBERTの学習させてるんだけど、BERTの成績が良すぎて辛い。ALBERTが追い付かない。使っているALBERTのモデルが、「小さすぎる」可能性はある。