心のざわめきを無くして日記を書くということ / secon.dev への移転 - A Day in the Life
このブログや、2nd lifeの記事、また無くなってしまったはてなグループ SubTech に書いていた記事をsecon.dev ドメインに移転した。あわせて、ブログシステムを、はてなブログから静的ジェネレータのによる生成に切り替えた。 心のざわめきをなくして日記を書くということ 日記や文章を書いてインターネットに書くモチベーション、というのは常に心のざわめきとともにあった。ホームページのカウンターから始まり、アクセス解析、コメント、トラックバックといった「自分が誰かから見られている」感とともに育った。2005年のはてなブックマークを皮切りに、人気の記事というのが視覚化され、さらに注目を浴びている感が出て、当時は人気になりそうな記事を書いた後は、どれだけ注目されるのか、わくわくしながらブラウザをリロードしたものだ。もちろん、時々は辛い言葉を浴びることもあるのだけど、それも一つの評価、として
Apple Silicon GPU(mps) の embeddings 変換パフォーマンス - A Day in the Life
RTX 4090 が圧勝(そりゃそうだろう)、というのは置いておいても、T4 の60%の速度が M2 GPU 10 コアで出ている。M3 Max はGPU 40コアモデルもあって、速度が線型増加すると仮定すると、M3 Max GPU 40コアならRPSは130ぐらい。RTX4090 の 1/3ぐらいの速度になって、ラップトップPCのGPUとしてはかなり速い。T4の倍以上の速度は出そう。 M2 の Embeddings の変換は実用的な速度か？と言われると用途によりそう。すごく遅くはないが、早くもない。ただ、M2 CPU で変換するよりは GPU は3倍は速いし、HuggingFace Transformers なら device を "mps" にするだけで使えるので、Mac で使う場合は当たり前に GPU を使っていきたい。M3 Max なら大体の用途で、そこそこ実用的な速度が出るんじゃ
fastText で量子化し、実用的な 1.7MB のテキスト分類器を作る - A Day in the Life
英語記事をAI関連 or AI関連でない、というテキスト分類器を fastText + 量子化で作ったら、ファイルサイズ1.7MBで実用的なモデルができてしまって驚き、というお話をメモ記事に。1.7MB ですよ!! AI Newsでは、AI関連 or AI関連でないのテキスト分類にAI News の公開と、裏側の OpenAI の活用話で書いた通り、OpenAIのtext-embedding-ada-002で1536次元のベクトルにしたものをlightGBMで学習させたものを使っている。この方法の問題は、すべての記事の判定に必ず OpenAI の API を通す必要があり、長文記事が沢山あると日によっては一日あたり数十円がかかってしまっている。月にすると500~1000円はかかってそうで、チリツモヤマトテナデコである。 というわけで、そろそろデータも溜まってきたしと、OpenAIのAPIに
ベクトル検索の高速化アルゴリズムと量子化パラメータの速度・データサイズ・精度の計測 - RAGでの利用時にはtop-N を意識する - A Day in the Life
最近、文をembeddingsといった特徴ベクトルに変換するユースケースが増えている。そのベクトルから類似ベクトルを探す時に、数千ベクトルならほぼ何も考えなくともよく、数万ベクトル〜になると検索速度を高速化するためHNSW等のANNの近似最近傍探索アルゴリズムを使い、そして数百万ベクトル〜になってくると現実的なデータサイズ収めるために量子化等々を組み合わせた最適化を行うことが多いだろう。 これら類似ベクトル検索のための最適化(HNSW・IVFといったアルゴリズムや量子化)では、検索速度、データサイズ(メモリに乗るか)、精度、三つのトレードオフが発生する。これらトレードオフを踏まえた最適化戦略を考えるのだが、最適化時の正確さの計測結果として recall@10 や recall@100 が掲載されていることを多く見かける。例えばChoose the k-NN algorithm for yo
gzip + kNN のテキスト分類で BERT 超え論文 "Low-Resource" Text Classification: A Parameter-Free Classification Method with Compressors を実装し試す - A Day in the Life
最近公開された論文 “Low-Resource” Text Classification: A Parameter-Free Classification Method with Compressors (Jiang et al., Findings 2023) は、gzip で圧縮したデータの長さを活用し、テキスト分類課題で BERTよりも優れたパフォーマンスを発揮すると述べています。面白そうだったので、自分でこの方法を実装して試してみました。その結果、実際に livedoor ニュースコーパス を用いたテキストのカテゴリー分類では、日本語 BERTよりも優れた結果が出ました。 どんな手法なのか やっていることはシンプルで、まずNCD(Normalized compression distance)を算出します。例では圧縮アルゴリズムに gzip を使っています。 個々のデータxとyを圧
SVMを使った類似 embeddings 検索 - kNN ではない類似検索の選択肢 - A Day in the Life
LangChain v0.0.141 に SVM Retriever という実装が入った。これは embeddings(集合)から、単一 embedding と類似しているもの top-K を SVM を使って見つけるという実装で、えっどうやってるの？と追っかけてみたら、知らない知識で面白かったのでメモ記事に。 kNN vs SVM この実装の元となった、knn_vs_svm.ipynbというnotebookがあって、冒頭を機械翻訳すると以下となる。 よくあるワークフローは、あるデータを埋め込みに基づいてインデックス化し、新しいクエリの埋め込みがあれば、k-Nearest Neighbor検索で最も類似した例を検索することです。例えば、大規模な論文コレクションをその抄録に基づいて埋め込み、興味のある新しい論文を与えると、その論文に最も類似した論文を検索することが想像できます。 私の経験では
このウェブサイトの実装 2020年版 - A Day in the Life
r7kamura さんや kzys さん に倣って、このウェブサイトの実装を紹介してみる。 ホスティング Google Firebase Hosting を使って静的ファイルを配信してる。一部動的な実装に関しては、Cloud Functions for Firebase を使っている。静的ファイル配信は今は Netlify や Surge など、基本無料で超簡単に配信ができて高速なものが多々出てるのだけど、Hosting に限らず Firebase の他のサービスとの連携が楽、という理由で Firebase Hosting を使っている。 また最近の仕事でのサーバサイドはほぼ Firebase 製品ですませていることもあって、Firebase でなんかやる、というのが技術的にもやりやすいから、というのもある。 なお画像はストレージをだいぶ食うため、はてなフォトライフにアップロードして使って
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2022年9月12日 - A Day in the Life