test

2025年9月15日月曜日

Notionデータベース

1秒あたり約3リクエストが上限。

時間当たりの制限はない。

「3リクエスト/秒 × 60秒 × 60分 × 24時間」で

1日あたり約259,200リクエストまで理論上OK。

ちょっとしたログを取るのに、google spread sheetより良さげ。

SurrealKV

まだデフォルトのストレージエンジンはRocksDBだが、

SurrealKVってファイルにも書けるらしい。

v3.0.0-alpha.7でガベージコレクションの修正があったので、おそらくその辺がまともになったと予想。

だってrustでガベージコレクションなんて存在しないだろ？

実データのメモリ管理用のことだと思う。ソース見てないけど・・・

公式のベンチマーク。

https://surrealdb.com/blog/beginning-our-benchmarking-journey?utm_source=chatgpt.com

そうだった！前調べたわ！8倍遅いの忘れてた！！！

VPSでtailscale

🔧 実際に開けておくべきもの（最低限）

アウトバウンド通信（サーバー → インターネット）
- tcp/443 → コントロールサーバーに接続するため必須
- udp/3478 → STUN（NATトラバーサル）用に開けておくとP2Pが成功しやすい
- udp/41641 → WireGuard ポート（デフォルト）
インバウンド通信（サーバー ← 他のTailscaleノード）

udp/41641 をサーバー側で開けておくと、直接接続（直結ピア）が成功しやすくなる
これが閉じていると、DERP (Tailscaleの中継サーバー) 経由通信になり、レイテンシが上がる

# Tailscaleインターフェースの通信を全許可

sudo ufw allow in on tailscale0 comment 'Tailscale interface inbound'

sudo ufw allow out on tailscale0 comment 'Tailscale interface outbound'

# コーディネーションサーバー通信（認証・設定取得）

sudo ufw allow out 443/tcp comment 'Tailscale control plane'

# STUN（NAT越え用）

sudo ufw allow out 3478/udp comment 'Tailscale STUN'

# Tailscaleメイン通信ポート（P2P直接接続用）

sudo ufw allow in 41641/udp comment 'Tailscale WireGuard inbound'

sudo ufw allow out 41641/udp comment 'Tailscale WireGuard outbound'

# 設定確認

sudo ufw status numbered

2025年9月14日日曜日

軽量の顔認識を用意してみる

gradface.netではGPUを使っているが、CPUだけで動作するものを用意したい。

2025年9月時点でのメモ。

推奨構成（CPU向け）

1. 検出（Face Detection）

SCRFD-500M / 2.5G
- InsightFace に同梱。ONNX Runtime で CPU 推論しても数 ms〜数十 ms 程度（解像度にもよる）。
- 検出精度と速度のバランスが良い。
代替案：YOLO-Face（YOLOv5ベース）。ただしやや重め。

2. 埋め込み（Feature Embedding）

ArcFace r50 / r100 (glint360k 事前学習)
- 112×112入力、CPUでも数十ms程度で動く。
- 精度は IJB-C TAR@FAR=1e-4 で 97-98% 程度。
軽量重視なら MobileFaceNet や PartialFCで学習された軽量モデル も選択肢。

3. 全体パイプライン

ONNX Runtime (Rust or Python)
- CPUでもマルチスレッド利用可能 (intra_op_num_threads 設定推奨)。
前処理：BGR→RGB、112×112にリサイズ、mean/std正規化。
後処理：出力ベクトルをL2正規化、コサイン類似で判定。

「そこそこの精度」での目安

モデル	精度 (IJB-C)	CPU速度 (i7-12700程度)	備考
ArcFace-R50	高 (97%+)	40〜50ms/顔	バランス型
ArcFace-R100	さらに高	70〜90ms/顔	高精度重視
MobileFaceNet	中〜高 (95%前後)	10〜15ms/顔	軽量・高速
FaceLiVT-tiny	高	20〜30ms/顔	Transformer混合だが軽い

LVFace はかなり大きいモデルです。

LVFace の特徴

Vision Transformer ベースの顔認証モデル
→ パラメータ数は ResNet 系の ArcFace よりもずっと多い（100M～数百M パラメータ級）。
学習データ：WebFace42M など巨大データセット
精度重視：IJB-C, IJB-B, CFP-FP など主要ベンチマークで SOTA 近い性能
トレーニング手法：Progressive Cluster Optimization (PCO) を導入して ViT の収束と識別能力を最適化
用途：サーバーや GPU 前提のバッチ推論、クラウド向け認証システム

モデルサイズとリソース

モデルサイズ：数百 MB 級（ViT-Large クラスだと 400〜500MB 近くになることも）
入力解像度：224×224 以上（ArcFaceの112×112より重い）
計算コスト：CPU 単体でリアルタイムはほぼ不可能（数秒かかる場合も）
GPU前提：A100 や RTX 4090 などのGPUでバッチ推論すると真価を発揮

まとめると

はい、かなりデカいです。
「そこそこの精度＋CPUでリアルタイム」用途なら、LVFace は明らかにオーバースペック。
ArcFace r50/r100 や MobileFaceNet, FaceLiVT-tiny の方が圧倒的に扱いやすいです。

**Transformer混合モデル（CNN + Transformer ハイブリッド）**が注目されているのは、
「CNNの速さ＋Transformerの表現力」を同時に狙えるからです。

Transformer混合モデルのメリット

1. グローバルな情報を取り込める

CNNは局所的な特徴抽出が得意ですが、広い範囲の関係を一度に見るのは苦手。
TransformerのSelf-Attentionを混ぜると、
遠いピクセル同士の関係や顔全体の整合性を捉えやすくなります。
結果、ポーズ変化・表情変化・部分隠れ（マスク等）に強くなる傾向があります。

2. 少ない層で高表現力

CNNだけで同じ表現力を得ようとすると層を深くする必要があり、
パラメータ数と計算量が急増。
Transformerブロックを数層入れるだけで情報集約が効率的になるため、
CNNより浅いモデルでも精度が出やすい。

3. モデルサイズと速度のトレードオフが良好

純Transformer（ViT-Large等）は巨大＆重い。
CNNベースにTransformerブロックを挿入するハイブリッドなら
モデルサイズを抑えつつ精度を底上げできる。
FaceLiVT-tiny のような軽量モデルは、MobileFaceNet並みの速度でArcFace-R100に近い精度を達成。

4. 最新研究のベースラインになりやすい

2024〜2025年の顔認証ベンチマーク（IJB-C、MegaFaceなど）で
CNN単体より 0.2〜0.5% 程度上の精度を達成する報告が増えている。
将来の学習済みモデル配布も、CNN+Transformer系が主流になりつつある。

デメリット（注意点）

計算グラフが複雑になりがち → 実装が少し難しい
CNN-only よりわずかに推論が重くなる（ただし ViT 単体よりは軽い）
学習には大規模データとGPUがほぼ必須（転移学習なら回避可能）

まとめ

Transformer混合のメリット = 「グローバル情報を取り入れて精度底上げしつつ、速度とサイズはCNN寄り」

CPUでもギリギリ実用 → FaceLiVT-tiny, MobileViT 系
精度重視＋GPUあり → LVFace や ViT-Large 系

「ArcFace-R100に近い推論速度で、ちょっと精度を上げたい」なら
→ FaceLiVT-tiny や MobileViT + ArcFace Loss がベストバランスです。

ArcFace-R100 vs FaceLiVT-tiny 比較表

項目	ArcFace-R100	FaceLiVT-tiny
登場時期	2018–2020頃（ArcFace 論文＋ResNet-100バックボーン）	2025年（CNN+Transformer ハイブリッド、軽量設計）
バックボーン	ResNet-100 (CNNのみ)	軽量CNN + MHLA(Multi-Head Linear Attention)ブロック
モデルサイズ	約 250MB (fp32)	約 80〜100MB (fp32)
入力サイズ	112×112	112×112（同等）
推論速度 (CPU, 1スレッド)	~70〜90ms/顔	~30〜40ms/顔（約1.8〜2倍高速）
推論速度 (GPU, FP16)	~2〜4ms/顔	~1〜2ms/顔
精度 (IJB-C TAR@FAR=1e-4)	97〜98%	97.5〜98.3%（約+0.3〜0.5%改善）
長所	安定実績、豊富な実装、閾値調整情報が多い	高速＆軽量、ポーズ変化やマスク耐性が強化、同等かやや高精度
短所	モデルサイズ大きめ、やや遅い	実装・学習コードはまだ新しい、事例が少なめ

まとめ

速度重視 & 新しい技術試したい → FaceLiVT-tiny
- CPUでも2倍近く速い
- 精度も少し良い（特にマスク顔・難例で差が出る）
- モデルサイズ小さめでメモリ負荷も少ない
枯れた安定感・実績重視 → ArcFace-R100
- 大量の既存実装・事例・閾値設定ノウハウあり
- v2/v3問わずどの環境でも動作実績豊富

もし SurrealDB v3 と組み合わせるなら、どちらでも 512次元埋め込みを保存してANN検索できます。
FaceLiVT-tiny のほうがモデル読み込みが軽いので、サーバー起動が速い・メモリも少なくて済みます。

2025年9月11日木曜日

形態素解析 Vaporettoで「よみがな」が長音記号になる

https://github.com/daac-tools/vaporetto

https://tech.legalforce.co.jp/entry/2021/09/28/180844

Vaporettoは辞書（UniDic系）に従い読み（カタカナ）で長音「ー」を使うことが多いです。

太郎→たろー

katakana_to_hiragana を長音「ー」を前の母音に応じて展開する実装にした。

太郎→たろう

ゲーム→げえむ

くそが！！

「ー」を直前の母音に展開する処理を追加。

その位置に元々『ー』がある時だけ保持。

OK!

2025年9月10日水曜日

2025年に読み仮名の生成を考える。

ちょっと必要、しかも完全ローカルが望ましい。

一般的なVPSで動かすことを想定。

以下の手段が想定できる。

# クラウドサービスを使う（今回は禁止）

- gooラボAPI

- Yahoo!言語解析API

# 自前実装（形態素解析系）

- MeCab（＋UniDic/NEologd）

- sudach

- Vaporetto （使用モデル：bccwj-suw+unidic_pos+pron　※UniDic ベースで学習済み）

https://github.com/daac-tools/vaporetto

# 自前実装（LLM系）

- gpt-oss(20B) ※そのままでも実際にN100とかでも動くけど遅い。さらに量子化すれば、一般的なVPSでも動作可能だが・・・

0.5B ggufがあったのでテストしてみる。

mradermacher/gpt-oss-0.5B-GGUF

- gemma3-12b

こいつはイケるだろ。

やはり大丈夫。

- BitNet b1.58 2B4T ※超軽量LLM

読み仮名無理だった・・・残念

重みを1.58ビットに量子化することによる恩恵は大きい。

メモリ消費量の大幅削減: モデルを保存・実行するために必要なメモリ量が格段に少なくなる。BitNet b1.58 2B4Tの非埋め込み（non-embedding）メモリ使用量はわずか0.4GB (400MB)だ。これは、比較対象となったモデルの中で次に小さいGoogleのGemma 3 1B（1.4GB）の約30%以下であり、他のモデルと比較しても圧倒的に小さい。