プロローグ：深夜のアラートと1.7GBの数字
深夜23時10分、ヘルスチェックAIから1件のアラートが届いた。
「VPSメモリ逼迫 — swap 1.4GB使用、KA 1.7GB」
「KAが1.7GB？ さっきまで全然大丈夫だったのに。」
知識管理アシスタント（Knowledge Assistant、以下KA）を日々運用している私は、この通知を見て首をかしげた。KAは比較的軽量なWebアプリだ。いくらなんでも1.7GBはおかしい。何かが壊れたのだろうか。
調査を進めると、すぐに真相が明らかになった。KA自体は80MBしか使っていない。1.7GBはユーザープロセス全体を合算した数値で、ヘルスチェックAIが「ユーザーの全プロセス合計」を見て、最も目立つプロセス名であるKAに紐付けて記録してしまったのが誤報告の原因だった。
実際の主要プロセスの内訳はこうだ。
| プロセス | メモリ |
|---|---|
| MCPサーバー（E5-baseモデル込み） | 約1.3GB |
| Claude Code CLI / エージェント | 約330MB |
| KAサービス本体 | 約80MB |
| 小計 | 約1.7GB |
アラートの形式としては不正確だった。しかしこの誤報告が、3週間前に私が「精度向上を期待して」実施したある設計変更の副作用を可視化するきっかけになった。1.3GB——MCPサーバーが搭載しているE5 embeddingモデルが、それだけのメモリを消費していたのだ。
そしてもう一つの疑問が浮かんだ。「8GBのVPSで、主要プロセスの合計が約1.7GBしかないのに、なぜswapが1.4GBも発生しているのか？」
その答えは後半で明かす。まず、なぜこの状況に至ったかを最初から振り返ろう。
第1章：「次元数を増やせば良くなる」という誤解
RAGとembeddingの基礎
KAの核心技術のひとつに RAG（Retrieval-Augmented Generation） がある。AIアシスタントが質問に答えるとき、ただ学習済みの知識だけに頼るのではなく、ユーザーが蓄積した固有の知識ベースを検索して参照する仕組みだ。「記憶して、思い出して、調べてから答える」という、人間にとっては当たり前の行動をAIに実装している。
この「記憶して思い出す」部分を担うのが embedding（埋め込み） 技術だ。テキストを数値の配列（ベクトル）に変換し、意味的に近いテキスト同士が数値的にも近くなるよう変換することで、「意味での検索」を可能にする。
「Pythonのエラー処理について教えて」
↓ E5モデルが変換
[0.12, -0.45, 0.87, ... × 384個の数値]
↓ pgvectorに保存
検索時も同じ変換を行い、
「近い数値の配列 = 意味が近い」で一致を探す
この変換後の「数値の個数」が 次元数 だ。384次元なら384個の数値でテキストを表現し、768次元なら768個の数値で表現する。
RAGシステムの内部で何が起きているか
ユーザーがKAに知識を登録するとき、裏側ではテキストのクリーニング・正規化を経て、適切なサイズの「チャンク」に分割される。そのチャンク1つ1つをE5モデルがembedding変換し、pgvectorにベクトルとして保存する。1つの記事が3つのチャンクに分割されれば、pgvectorには3つのベクトルが格納される。
検索時はクエリを同じモデルでベクトル化し、pgvectorが保存済みベクトルとのコサイン距離を計算して上位k件を返す。このとき重要な制約がある——登録時と検索時は必ず同じ次元数のモデルを使わなければならない。384次元で登録したデータを768次元のクエリで検索することは物理的にできない。「次元数を変えたら全データを再embeddingしなければならない」理由がここにある。
「多いほど精度が上がるのでは？」という仮説
次元数が多いほど表現力が豊かになる——この考え方は自然だ。384個の数値よりも倍の768個の数値のほうが、テキストの意味をより細かく、より正確に表現できるのではないか。
実際、embeddingモデルの比較ベンチマーク（MTEB等）では、一般的に大きなモデルのほうが高スコアを示すことが多い。
もともとKAで使用していたのは multilingual-e5-small（384次元）だった。「small」という名前が示す通り、軽量・高速を優先した設計だ。
モデル名：multilingual-e5-small
次元数：384次元
ファイルサイズ：471MB
RAM消費：約300MB
「この上位モデルである multilingual-e5-base に切り替えれば、現行よりさらに精度が上がるのでは？」
私はそう考えた。それが今回の失敗の起点だった。
第2章：768次元への移行
移行の判断
768次元への移行を決意したのは、KAのさらなる機能向上を期待したからだ。正直なところ、現状のKAでも個人利用としては十分実用的に運用できている。しかし更なる向上が期待できるなら試してみたいと思うのは開発者として自然なことで、当時の私も
「e5-baseなら、e5-smallより次元数が2倍ある。より豊かな表現力で、より精度の高い情報が取得できるはずだ。」
と考えた。移行後のモデルスペックはこうだ。
| モデル | 次元 | ファイルサイズ | RAM消費 |
|---|---|---|---|
| e5-small（現行） | 384 | 471MB | 約300MB |
| e5-base（移行先） | 768 | 1.1GB | 約1.3GB |
| bge-m3（参考） | 1024 | 4.3GB | 実質使用不可 |
ファイルサイズが471MBから1.1GBへ約2.3倍、RAM消費が300MBから約1.3GBへ 約4.3倍。事前にAIと相談しながら計画を進めていたのだが、VPSのメモリは8GBだったため、当時の私もAIも「これは許容範囲内」と判断した。ここに、後に後悔する見落としが潜んでいた。
コンバート作業という高い関門
embeddingの次元数を変更するということは、pgvectorに蓄積されたすべての知識チャンクを新しいモデルで一から処理し直す、いわゆる コンバート作業 が発生することを意味する。
作業の流れはおおむね次のようになる。
- 新モデル（e5-base）の導入
- pgvectorの既存コレクションのバックアップ
- 全チャンクの再embeddingバッチ処理
- 新次元数でのインデックス再構築
- 動作確認と旧コレクションのアーカイブ
KAの場合、3ヶ月の運用で既に50万件以上のデータを蓄積していた。このコンバート作業には ほぼ3日 かかった（※ RAM 64GB・GPU 24GBの別マシンを使用）。
これだけの工数を投じた変更だ。「きっと効果があるはず」という期待は、それだけ大きかった。
第3章：期待と現実のギャップ
最初の違和感
移行直後はそれほど大きな変化を感じなかった。検索は動いている。AIアシスタントも返答している。一見、問題ない。
しかし、しばらく使い続けるうちに、漠然とした違和感が積み重なり始めた。
「RAG検索がうまくHitしていないのでは？」
「この質問なら関連する知識が登録されているはずなのに、うまく取れていないな。」
感覚的な違和感は、なかなか確信に変わらない。毎回の検索結果を逐一比較しているわけではないし、知識ベース自体も日々更新されている。機能向上のために他の施策も並行して実施していたため切り分けができない。「モデルの問題なのか、それとも単にデータが変わったせいなのか」が判然としなかった。
そこで客観的な数値を確認することにした。
search_logsが語る現実
KAには search_logs というテーブルが存在し、各検索の 平均距離スコア（avg_distance）が記録されている。
距離スコアは、クエリと検索結果のベクトル間の距離を示す値だ。値が小さいほど「より関連性の高い結果を返せている」 ことを意味する。理想的な検索ではクエリに対して意味的に近い文書が上位に来るため、距離スコアが小さくなる。限りなく0に近づくほど求めている情報に近い、ということだ。
ログを遡って分析した結果、衝撃的な事実が明らかになった。
| 時期 | 平均距離スコア |
|---|---|
| 384次元（90日平均） | 0.095〜0.107 |
| 768次元（移行後21日平均） | 0.124〜0.143 |
384次元時代の距離スコアは90日平均で0.095〜0.107の範囲で安定していた。ところが768次元に移行した6月以降、0.124〜0.143まで上昇している。
距離スコアが約 30〜40%悪化 している。
これは無視できない数字だ。精度が上がるはずの移行後に、検索品質を示す指標が逆方向に動いていた。
「768次元が原因」と断言できない複雑さ
ただし、データ解釈には注意が必要だった。
今回は768次元への移行と同時期に、DBストアの変更、知識ベースの構造変更、チャンク分割の方式見直し、MCPサーバーの更新など、複数の大規模な変更を一度に行ってしまっていた。KAを構築してからの約3ヶ月間も頻繁に改修を行ってきたが、今回のようにベースを丸ごと置き換えるような施策はなかった。
「スコアが悪化したのは768次元のせいなのか、それとも別の改修の影響なのか」——現状でこの因果関係を完全に切り分けることはもはや困難だった。
しかし「768次元にしたことで精度が向上した」という結果も、どこにも見当たらない。少なくとも数値は明確に悪化方向を示しており、「移行して良かった」という事実が存在しなかった。
第4章：なぜ8GBのVPSでメモリが逼迫したのか
「2GBしか使っていないのに」という疑問
精度の問題を抱えながら768次元で運用を続けているうちに、より具体的でわかりやすい問題が顕在化した。それが冒頭のVPSメモリ逼迫だ。
「主要3プロセスの合計が約1.7GB。8GBのVPSなら余裕があるはず」——この認識には複数の見落としがあった。
見落とし① VPS実効RAMは7.5GB
8GBというスペックはホスト物理メモリの公称値だ。ハイパーバイザー（仮想化レイヤー）のオーバーヘッドを引いた実効RAMは 約7.5GB にとどまる。出発点からすでに500MBを失っている。
見落とし② PostgreSQL/pgvectorが「見えていなかった」
pgvectorはHNSWインデックスをメモリ上に展開する。768次元float32では1ベクトルあたり約3KB、50万件で生データだけで約1.5GBに達する。HNSWグラフの構造体が加わるとさらに膨らむ。アラート時点でPostgreSQLは約414MBを消費していたが、クエリが増加すると需要はさらに増える。
これはembeddingモデルのRAM消費とは 別の 話だ。768次元の場合、モデル本体の1.3GBに加え、ベクトルデータ自体のフットプリントも384次元の倍になるという二重の影響がある。
見落とし③ OS・システムプロセス
Linux kernel、systemd、SSH、Docker daemon、監視プロセスなどが常時 約500MB を消費している。「主要プロセス」として意識的にカウントしていなかった分だ。
見落とし④ Linuxページキャッシュの積極的な利用
Linuxは空きRAMをファイルキャッシュ（ページキャッシュ）として積極的に活用する。freeコマンドで"free"の数値が低く見えるのは設計通りの動作だが、突発的なメモリ需要に対するキャッシュ解放の遅延がswapを誘発しやすい。「空きがあるはず」と思っていても、実際には瞬間的に余裕がなくなる場面が生じる。
見落とし⑤ 並列エージェントの突発的な需要増（最大の要因）
_MAX_CONCURRENT_TASKS=10という設定により、最大10本のClaude Codeエージェントが同時起動できた。1エージェントあたり約330MBとして、10本同時では 約3.3GBのピーク消費 が発生する。またkb-browser.serviceにはMemoryMaxが未設定で、エージェント環境全体が1.1〜1.7GBまで膨らむことがあった。
実態：アラート時の実測値
アラート発生時の実測値は RAM 4.8GB使用 + swap 1.4GB = 事実上6.2GB だった。
実際のメモリ構成（アラート時）
─────────────────────────────────
MCPサーバー（E5-base） 1.3 GB
PostgreSQL/pgvector 0.4 GB
OS・システムプロセス 0.5 GB
kb-browser（ピーク） 1.7 GB
Linuxページキャッシュ 残余を消費
─────────────────────────────────
実測合計 4.8 GB使用
+ 1.4 GB swap
「2GB」という数字は主要3プロセスの定常値にすぎない。E5-baseの1.3GBは「余裕のある消費」に見えたが、実態はシステム全体のベースラインをすでに3〜4GBの水準に引き上げていた。そこへ並列エージェントの需要スパイクが加わると、即座にswapへあふれる構造になっていたのだ。
swapが発生するとどうなるか
swapとは、RAMが不足したときにディスクをRAMの代わりに使う仕組みだ。しかし現代のNVMe SSDでも、RAMに比べると速度は数十倍から数百倍遅い。
- RAM：読み書き速度 数十GB/秒、アクセスレイテンシ ナノ秒単位
- NVMe SSD：読み書き速度 数GB/秒、アクセスレイテンシ マイクロ秒単位
embeddingモデルの推論処理はモデルの重みパラメータに頻繁にアクセスする。この重みがdiskに追いやられると、推論速度が 数十倍〜数百倍 に低下することがある。「検索が遅い」「AIの返答が来ない」「タイムアウトする」——これらはすべてswapが引き起こす典型的な症状だ。e5-baseを常駐させている限り、この状態はいつでも再現しうる構造だった。
第5章：なぜ768次元は精度が落ちたのか——技術的考察
直感に反して768次元の精度が384次元に劣った理由は、単純ではない。いくつかの要因が複合的に絡み合っている。
次元の呪い（Curse of Dimensionality）
高次元空間では、データ点間の距離分布が均一化し、「近い」と「遠い」の差が小さくなっていく現象がある。これを 次元の呪い と呼ぶ。
2次元空間で10個の点が散らばっているとき、「ある点の最も近い隣」を探すのは直感的に理解できる。しかし次元数を増やしていくと、ある不思議な現象が起きる。100次元になると任意の2点間の距離が似た値に収束し始め、1000次元になるとほぼすべての点間の距離が「ほぼ同じ」になってしまう。「最も近い隣」と「最も遠い隣」の距離差が極めて小さくなるのだ。
embeddingベクトルにおいても同様のことが起きうる。384次元では明確に区別できていた「関連性が高い文書」と「関連性が低い文書」が、768次元では距離差が縮まり、検索の差別化が難しくなる可能性がある。
ドメイン適合性の問題
e5-smallとe5-baseは共に、一般的な多言語テキストデータで学習されている。しかしKAに蓄積されている知識は、日本語で書かれたプロジェクト固有の情報、技術的なメモ、AIエージェントとの対話ログなど、非常に特殊なドメインのテキストだ。
一般的なベンチマークでe5-baseがe5-smallに勝っていても、それはWikipediaや一般ウェブページのような標準的なテキストでの評価だ。KAのような特殊なドメインでは、その優位性が失われる、あるいは逆転することがある。
コーパスサイズと次元数のミスマッチ
高次元のembeddingが真の力を発揮するには、それに見合った規模の知識ベースが必要だ。数百万件のドキュメントがあれば、768次元の細かい表現力が活きてくる。しかし知識ベースが数万チャンクのレベルであれば、768次元の表現力を使いこなすデータ密度が不足している。
「スポーツカーを購入したが、走る道路は狭い路地しかない」——そんな状況に近いかもしれない。384次元のe5-smallはKAの現在のデータ規模にちょうど良い「分解能」を持っていた。768次元のe5-baseは、データ規模に対して過剰な表現力を持ち、逆にノイズに敏感になっていた可能性がある。
量子化・圧縮の影響
e5-baseモデルは学習済みパラメータを量子化（精度を下げてファイルサイズを削減する処理）した状態で配布されることが多い。量子化の方法や圧縮率によっては、理論上の表現力と実際の性能に乖離が生まれる。大きいモデルを積極的に圧縮した結果、小さいモデル（圧縮率が低い）を下回るケースも報告されている。
つまり「768次元 > 384次元」という比較は、同一の学習データ・同一の量子化条件を前提とした話であり、実際の運用環境での比較は別物になりうる。
第6章：384次元への回帰——決断と実行
3つの事実が揃った瞬間
768次元の運用から約3週間後、384次元（e5-small）への回帰を決定した。
この決断は、以下の3つの事実が揃ったことで確信に変わった。
1. 精度の客観的な悪化
search_logsのavg_distanceが、768次元移行後に一貫して悪化している。0.095〜0.107から0.124〜0.143への上昇は、検索品質の明確な劣化を示している。
2. メモリコストの4.3倍増
e5-smallの約300MBに対し、e5-baseは約1.3GB。VPSリソースを大量に消費し、swapが発生するほどの逼迫状態を引き起こした。
3. トレードオフの完全な崩壊
精度が上がっているなら、メモリコスト増も運用負荷増も許容できた。しかし精度まで落ちているのでは、「何のためのコスト増か」という問いに答えられない。
「元に戻す」ことへの心理的抵抗
技術的な判断とは別に、「元に戻す」という行為には心理的な抵抗が伴う。
768次元への移行は、それなりの調査と判断と工数を費やした変更だった。3日のコンバート作業を別マシンで実施し、AIとも綿密に相談した。「やっぱりダメだったから元に戻す」という決断は、その投資を否定することでもある。
しかし実際のシステム運用では、「元に戻す」という選択肢は正しい判断の一つだ。むしろ失敗した変更に固執して状況を悪化させ続けることの方が、はるかに高いコストを生む。
サンクコスト（埋没費用） に引きずられずに、現状から最善の選択をすること。これはエンジニアリングだけでなく、あらゆる意思決定に共通する原則だ。
また、いつでも戻せる状態を保つことの重要性も痛感した。移行前のDBバックアップと定期的なスナップショットがなければ、今回の回帰作業はもっと困難だったはずだ。大きな変更の前後でバックアップを取ることは、当たり前に思えて案外おろそかになりがちだ。
復帰後の変化
384次元への復帰後、search_logsのスコアは改善方向に動き始め、VPSのメモリ使用量も大幅に改善した。e5-smallの約300MBはVPSの余裕の範囲内に収まり、swapが発生するような逼迫状態は解消された。
現在の結論：VPS環境でのRAGシステムには、e5-small（384次元、300MB）が最適解 だ。知識ベースが大幅に拡大した段階、またはGPU付きの専用サーバーへ移行した段階で、再評価を行う。
第7章：同じ失敗を繰り返さないために
得られた知見
今回の経験から、embeddingモデルと運用設計の両面で学んだことをまとめる。
知見1：ベンチマークスコアは参考情報でしかない
MTEBなどの標準ベンチマークで高スコアのモデルが、自分のユースケースでも最良とは限らない。ベンチマークは一般的なテキストデータでの評価であり、特定ドメインへの適合性は別問題だ。必ず自分のデータで評価すること。KAの場合、search_logsのavg_distanceがその評価指標になる。
知見2：リソース制約は全プロセス合算で計算する
「主要プロセスの合計」では不十分だ。OS、DB（HNSWインデックスを含む）、ページキャッシュ、エージェント並列数まで含めて見積もること。次元数が2倍になればベクトルデータ自体のフットプリントも2倍になることも忘れてはならない。
知見3：現在のデータ規模に合った次元数を選ぶ
知識ベースが小〜中規模（数千〜数万チャンク）の段階では、384次元程度のモデルで十分なことが多い。データ規模が拡大し、より細かな意味の区別が必要になった時点で次元数の引き上げを検討するのが合理的だ。最初から大きなモデルを使う「先行投資」は、現状のデータ密度に見合わない過剰投資になりやすい。
知見4：変更は一度に一つずつ
今回最大の反省点のひとつは、768次元移行と同時期に複数の大規模改修が重なり、「何が原因で精度が落ちたのか」の切り分けが困難になったことだ。本来はembeddingモデルの変更だけを行い、他の変数を固定した状態で効果測定するのが理想だった。A/Bテストの原則はAI/MLシステムでも同様に重要だ。
知見5：モデルサイズより先に最適化すべきことがある
チャンク戦略の最適化、ハイブリッド検索（意味＋キーワード）の導入、リランキング——これらを試してから、最終手段としてモデルを変える。embeddingモデルの次元数は、RAGシステムにおいて最後に手を付けるべきパラメータだ。
変更前後のチェックリスト
今回の経験から、embeddingモデル変更の際に確認すべき事項をルール化した。
変更前チェックリスト
- 現在のavg_distanceベースラインを記録したか
- サーバの利用可能メモリと新モデルのRAM消費を比較したか（pgvectorインデックス込みで）
- 変更と同時期に行う他の改修がないか確認したか
- 失敗した場合の切り戻し手順と、DBバックアップを事前に整理したか
- コンバート作業の所要時間・工数を見積もったか
変更後の評価期間
- 少なくとも2週間以上のavg_distanceデータを収集したか
- 変更前のベースラインと比較して改善しているか
- サーバのメモリ使用量は許容範囲内に収まっているか
- レスポンスタイムの変化を確認したか
可観測性がなければ決断できない
今回、「検索精度が落ちた」という事実を客観的に証明できたのは、search_logsにavg_distanceの記録が蓄積されていたからだ。
感覚的には「なんか精度が落ちた気がする」と思っていたが、それだけでは「やっぱり384次元に戻そう」という確信を持てなかっただろう。90日分のスコア推移という具体的な数値があったからこそ、意思決定が速く、かつ確信を持って行えた。
AIシステムの運用においては、このような 可観測性（Observability） の設計が非常に重要だ。
- 検索ごとのdistanceスコアをロギングする
- 時系列でスコアの推移を追えるようにする
- 変更前後の比較が即座にできる仕組みを持つ
これらは一見地味なインフラだが、システムの状態を「感覚」ではなく「データ」で把握できるかどうかの差を生む。感覚と数値が一致したとき、意思決定は迷わない。逆に食い違うとき、どちらかを疑う理由が生まれ、より深い調査につながる。どちらにしても、数値があることは有益だ。
エピローグ：失敗は成功のデータだ
768次元への移行は失敗だった。投じた工数に対して、何も得られなかった。むしろ精度悪化という負の結果を手にした。
しかし、この失敗は決して無駄ではなかった。
得られた確信
384次元（e5-small）がKAの現在の規模・環境に最適であることを、単なる「デフォルト設定」としてではなく、768次元との比較実験を経た 根拠のある選択 として確認できた。
「なぜ384次元を使っているのか」という問いに対して、今の私は明確に答えられる。search_logsのデータが示す検索精度、VPSのリソース制約、そしてKAのデータ規模——これら3つの観点から、384次元が最適だと実証したからだ。
蓄積された観測データ
90日分のsearch_logsスコア推移、768次元前後での精度変化、VPSメモリ使用量の変動——これらのデータは今後の意思決定に活用できる貴重な資産だ。次回embeddingモデルの見直しを検討する際、このデータが比較の出発点になる。
検証文化の強化
「直感 → 変更 → 事後に気づく」というパターンを経験したことで、「仮説 → 計測 → 検証 → 判断」という科学的なアプローチの重要性を身をもって学んだ。次回の変更では、必ずテスト環境での事前評価とベースライン比較を行う。
技術ブログや記事の多くは「成功事例」だ。「〇〇を導入したら精度が上がった」「〇〇に移行してコストが下がった」——正の結果を持つ話が書かれやすい。「やってみたけど失敗した」という経験は、当事者にとって恥ずかしかったり「わざわざ公開する必要もない」と思われたりして、記録として残りにくい。
しかし失敗の記録は、成功の記録と同等かそれ以上の価値を持つ。「これをやってはいけない」という知識は、「これをやればいい」という知識と同じくらい貴重だ。
後から同じシステムに関わる人間が、同じ轍を踏まないためには、失敗の記録が必要だ。「なぜ768次元ではなく384次元を使っているのか」という問いに対して、「昔試したけどダメだったから」という一言で済ませるより、このドキュメントを指し示すほうが、はるかに説得力がある。
「やってみたら失敗した」という経験を記録し、次の判断に活かすこと——それもまた、ナレッジマネジメントの実践だと思っている。
付録：関連技術用語集
embedding（埋め込み）
テキストを数値の配列（ベクトル）に変換すること。「意味の近いテキスト = 数値的に近い」という性質を持つ変換。
次元数
ベクトルの「数値の個数」。次元数が多いほど豊かな表現が可能だが、必ずしも精度が上がるわけではない。
pgvector
PostgreSQLにベクトルを高速に保存・検索するためのデータベース拡張機能。「意味的な近さ」で検索できる。
HNSW（Hierarchical Navigable Small World）
pgvectorが使うインデックス方式。高次元ベクトルの近傍探索を高速化するが、インデックス全体をRAMに展開する必要がある。
avg_distance
各検索で返ってきた上位文書とクエリ間の平均距離スコア。小さいほど「関連性の高い文書を返せている」ことを意味する。KAではsearch_logsテーブルに記録される。
RAG（Retrieval-Augmented Generation）
AIが質問に答える前に、関連する情報を検索して文脈として使う手法。「調べてから答える」AIの実装方式。
VPS（Virtual Private Server）
仮想的に専有できるサーバー。物理サーバーより安価だが、リソース上限がある。AI/MLモデルのような重いワークロードの常駐には不向きな側面がある。
swap
RAMが不足した際、ディスクをRAMの代わりに使う仕組み。ディスクはRAMより大幅に遅いため、パフォーマンスが劇的に低下する。
次元の呪い（Curse of Dimensionality）
高次元空間では全データ点間の距離が均質化し、「近い」と「遠い」の区別が難しくなる現象。embeddingの文脈では、次元数が増えるほど距離差が小さくなり、検索の差別化が困難になることを指す。
サンクコスト（埋没費用）
すでに支払ってしまい、回収できないコスト。「もう工数をかけてしまったから」という理由で誤った選択を続けることを「サンクコストの呪縛」と呼ぶ。意思決定においては、過去のコストではなく現状の最善を選ぶことが重要だ。
MTEB（Massive Text Embedding Benchmark）
embeddingモデルの性能を評価する標準的なベンチマーク。一般的なテキストデータでの評価であり、特定ドメインへの適合性を保証しない。
本記事は2026年6月時点のKnowledge Assistantにおける実際の経験に基づいています。embeddingモデルの最適な選択はシステムの規模・データの性質・リソース制約によって異なります。数値はあくまで参考情報として、必ず自分の環境で検証してください。