プロフェッショナルグレードのローカル素材および音楽ライブラリを構築する際、従来の検索アーキテクチャはしばしば厳しい課題に直面します。ユーザーが検索ボックスに「叙事詩的で壮大な勢い」や「静かなピアノ」と入力した場合、キーワードの分割に基づくデータベース検索（SQLite FTS5 など）では、フィールドにこれらの単語が正確に含まれているトラックしか正確に一致させることができません。これにより、豊富なタグ（ただし異なる表現）を持つ膨大なオーディオ素材が埋もれてしまいます。
この課題を根本的に解決するため、最新の低層リファクタリングにおいて、私たちは LanceDB ベクトルデータベース と BGE-M3 エッジモデル を組み合わせたハイブリッド検索 (Hybrid Search) アーキテクチャへと完全にアップグレードしました。
I. SQLite FTS5 の限界を突破する
以前のバージョンの PureLab では、コアの検索は完全に SQLite のフルテキスト検索モジュール (FTS5) に依存していました。このアーキテクチャはシンプルで非常に高速ですが、実際のビジネスシナリオでボトルネックに遭遇しました。
- セマンティック・ギャップ: ユーザーの検索語と実際のオーディオのタグ（例: genre / mood）が完全に一致しないことがよくあります（例えば、「幸せ」と検索しても「happy」とタグ付けされたトラックが見逃される）。
- 言語間のマッチングが弱い: 音楽のメタデータは多言語の説明において極端に分散しています。単純なトークナイザでは、言語間でセマンティックな関連性を確立することはできません。
II. デュアルレーン検索とハイブリッドアーキテクチャ
セマンティック層を導入するために、字句検索を放棄したわけではありません。代わりに、デュアルレーン検索と RRF 融合 (Dual-Lane Retrieval & RRF) モデルを採用し、既存の SQLite アーキテクチャの上に LanceDB を深く組み込みました。
1. 独立したプロジェクションテーブルと BGE-M3 埋め込み
正規化された各ユーザーライブラリ (Root) ごとに、その .lancedb/ ディレクトリに独立した text_vectors プロジェクションテーブルを確立しました。
- ローカル ONNX 推論: インデックス再構築メカニズムがトリガーされると（フェーズ B）、システムは
ortベースのバックグラウンドエンジンをスケジューリングし、メタデータテキストをローカルの BGE-M3 Int8 ONNX モデルに渡し、高品質の1024次元f32ベクトルを生成してデータベースにアップサート（更新挿入）します。 - 台帳と再試行メカニズム (Ledger): 大規模なベクトル化タスクがデバイスのパフォーマンス制限によって強制的に中断されるのを防ぐため、SQLite 内に
text_vector_index_ledgerテーブルを設計しました。これは各テキスト行のステータス（pending,indexed,failed）を追跡し、プログラムが予期せず再起動した場合でも、システムが中断ポイントからシームレスに再開して Lease を再試行できるようにします。
2. Lexical と Semantic のデュアル Provider
ユーザーが検索を入力すると、アーキテクチャはバックエンドで2つのコア Provider に分岐します。
- LexicalRetrievalProvider: 引き続き FTS5 を通じて強力なハードマッチングを提供します（ファイル名と明確なタグの直接検索が 100% 呼び出されることを保証します）。
- SemanticRetrievalProvider: BGE 推論環境をロードし、ユーザーの Query のベクトルを計算し、それを LanceDB の ANN (近似最近傍) に渡してセマンティック検索を実行します。
III. ランク融合の芸術: Text-Priority RRF
両方のレーンの結果を組み合わせて最終リスト (ResultList) を提示することが、本当の課題です。
高遅延の Cross-encoder リランカーを使用する代わりに、調整済みの Text-Priority RRF (Reciprocal Rank Fusion) アルゴリズムを使用して後処理を行います。
$$
Score_{RRF} = \frac{1}{K + \text{Rank}{Lexical}} + \frac{W{Semantic}}{K + \text{Rank}_{Semantic}}
$$
[!NOTE]
私たちの実装では：
- $K = 60$
- 字句 (Lexical) マッチングの重み $W_{Lexical} = 1.0$
- セマンティック (Semantic) マッチングの重み $W_{Semantic} = 0.95$
セマンティック側にわずかな重みの割引 (0.95) を適用することで、オーディオファイルの字句語が直接ヒットした場合に、それが単なる「意味的に類似した」結果よりも常に上位にランク付けされることを保証します。これにより、「検索」に対する従来の期待の回復を最大化すると同時に、ロングテールのセマンティックに関連する隠れた名曲を補完します。
IV. デュアルライブラリ並列処理: 音楽と素材のフィルタリング
アプリケーションシナリオが異なれば、インデックス要件もまったく異なります。LanceDB によって取得された結果 (TextVectorSearchHit) では、library_type（“music” または “material”）と surface に機能をバインドしました。
これは、ユーザーが数百GBのロスレス音楽アルバムと効果音素材コレクションを同時に管理している場合でも、検索パイプラインが ANN 検索中に正確なフィーチャ分割を実行し、環境音エフェクトが音楽ジャンルのプレイリストに混入しないことを保証できることを意味します。
おわりに
百万曲規模のローカルライブラリの検索の課題は、本質的に、限られたエッジの計算リソースの下で正確性と網羅性のバランスを見つけることです。LanceDB と軽量な ONNX モデルを組み合わせたハイブリッド検索アーキテクチャは、ユーザーのデータプライバシーを犠牲にしないだけでなく、検索エクスペリエンスをかつてない高さに引き上げました。将来のバージョンでは、より長い説明フィールドの検索をサポートするために、メタデータチャンキングの探索も計画しています。