性質のまったく違う二つのアプリで、検索戦略を最後に決めたのは実測だった

あらまし

ベクトル検索の応答が 5 秒から 17 秒に膨らんでタイムアウトが多発したとき、その原因を検索の並列度だと決めつけかけました。個人会社で開発している性質のまったく違う二つのアプリを数か月ずつ動かして見えたのは、検索の戦略も一つひとつの工夫の採否も、一般論やベンダーの推奨ではなく、最後は自分のアプリのデータと、実際にされる検索とで実測して決めていた、ということでした。

実測の数字は、事前の見積もりをことごとく裏切りました。ベクトル化の費用は、文書のトークン数と文字数の比で見積もっていて、概算では 2.0 と置いていました。文書を全件ベクトル化する前に、まず 1 割だけ試しにベクトル化して測ると、この比は実際には約 0.674 で、全件の費用の試算は約 7 割下がりました。ベクトル検索が近い候補を探すときの探索の幅も、広げるほど良い候補を拾えると見込んで、既定の 40 から 100 へ広げて測りましたが、検索結果の上位に並ぶ候補の類似度はほぼ変わらず、検索一回の実行時間だけが約 300 倍に悪化したので、探索の幅の既定値を上げる利点はないと分かりました。検索の文を大規模言語モデルで膨らませてからベクトル化すれば、短い検索の文でも意図がくみ取れて精度が上がるはずでした。ところが、性質が大きく離れた二種類の候補を見分ける手がかりである類似度の差が、素の検索の文なら約 0.13 あったのに、膨らませると約 0.04 まで縮んでしまい、逆効果だと数値で分かったので撤回しました。

検索が遅い原因の取り違えは、一度ではありません。検索の索引を作った直後の一回目の検索が異常に遅かったときは、はじめはディスクのせいにしかけました。けれど本当の原因はどちらも、決めつけた側ではなく、データベースの統計情報や検索の組み立て方やキャッシュの側にありました。

購読で読める本文は、この失敗をたどる順に書いています。まず、遅さの原因をハードのせいにしかけて何度も取り違えた話から始めて、ソフト側を一つずつ潰して直した経緯をたどります。次に、実測の数字が事前の見積もりを裏切った話と、効かなかった工夫を当時の検証の条件を添えて取り下げた判断、検索の品質の主軸をキーワードや辞書から意味の近さそのものへ移した設計、と続きます。最後に、外から借りる数字を現行の一次情報で引き直した話と、それでも効いたと言い切れない工夫を、結論を出さないまま残したところまで書いて、二つのアプリを動かして手元に残ったものは何だったか、で締めています。

対象読者と持ち帰れるもの

ベクトル検索を実際のサービスに載せていて、ベンダーの比較記事や公開ベンチマークをそのまま採用してよいか迷っている開発者に向けた記事です。全文検索とベクトル検索のどちらを既定にするか、精度に効く工夫と効かない工夫をどう見分けるか、検索の遅さの真因をハードとソフトのどちらに求めるかを、自分のアプリのデータと実際の検索とで実測して決めるための、判断の型を持ち帰れます。性質の異なる二つのアプリが、別々の開発の流れの中で同じ結論へ行き着いたこと自体が、この判断の型が一つのアプリだけの偶然ではないことの裏づけになると考えています。この記事は、個人会社で開発している二つのアプリの検索基盤の、運用の一次記録に基づく考察です。