【日記を書く24日目】検索ってめちゃむずい

れみです。今日はなんだか眠いです。仕事がちょっと落ち着いて、仕事に追われなくなると、集中力も続かず、眠いなーって思ったりします。

昨日の記事

今日は「検索」について。

自分は業務で、とあるドキュメント群について、vector searchによってドキュメントを検索できるようにするためのシステムを作っていました。

最近は、意味を残したまま数値に直すembeddingという技術が進歩し、そこそこの精度で意味を数値に変換することができるようになりました。これらを使うことで、誰でも簡単にvector searchの仕組みを作ることができます。

embeddingを用いると、データベースに入れるデータは、ドキュメントの文字列から、そのドキュメントの意味を表した数列（ベクトル）になります。そうなると、ドキュメント検索は、クエリのベクトルと類似度が高いベクトルを抽出し、そのベクトルに対応したドキュメントを結果として返すことになります。

こうなると、検索処理に必要なのは、高速にベクトルの類似度が計算できるプログラムです。ここら辺は世の中にいろいろありますね。

また、ベクトルの類似度は計算方法もいろいろあります。有名なのは、ユークリッド距離による比較やコサイン距離による比較でしょうか。embeddingによって得られるベクトルが正規化されていれば、類似度は一致するはずです。

こうやって作ったvector searchの仕組みで、誰もが気になるのは、検索の精度です。もちろん自分も気にしました。

例えば、レシピのドキュメントを大量に用意し、embeddingによってベクトル化して、レシピをvector searchにより検索できるようにします。カレーのレシピが入っていました。試しに、「カレーの作り方」、「カレーのレシピ」、「ビーフカレーを作るには」のようなクエリを投げてみると、想定通りカレーのレシピが検索結果に含まれていました。嬉しいですね。

とあるユーザーがこんなことを言い始めました。

「肉とジャガイモを使った料理」の検索結果にカレーのレシピが出て欲しいよね

ええ。

困りました。

確かに言ってることはわかります。でも今のドキュメントのembedding方法では、「肉とじゃがいもを使った料理」というクエリから、カレーのレシピを検索結果に入れることはどうも難しそうです。

こうなると、ドキュメントを単純にembeddingによってベクトル化するだけではなく、別の工夫が必要になりました。

手っ取り早く検索結果に載せる方法として思いつくのは、「肉とジャガイモを使った料理」というドキュメントを既存のカレーのレシピとしてデータベースに入れておくことです。そうすることで、検索結果に入ることになります。

ただ、これを思いつくままやるとなると、それはそれで大変です。一通り検索を試してみて、思い通りの検索結果にならなかったものは、その都度ドキュメントとしてデータベースに入れないといけません。ちゃんとデータベーに入っているデータを簡単に管理できる仕組みがあればいいのですが、ないと、どんなドキュメントが今データベースに入っているのかわからなくなります。

いろいろやりようはあると思いますが、運用まで考えると大変です。ドキュメントだって普遍ではなく内容も変わればドキュメントの総数も変わる可能性があります。さまざまなエンジニアの方が書いている記事で紹介されているのは、ベクトルの類似度を計算するコードまでで、そのドキュメントまで管理する方法を紹介しているものは多くないと思っています。難しいところです。

---

自分はここ半年で初めて「検索」に重きを置いたサービスについて考えてきました。自分でも身近なはずの「検索」技術が、ここまで難しいものなのかというのを実感しました。

今回は料理のレシピを例に出しましたが、現実はもっと難しいです。ドキュメントは専門用語ばかりなのに、ユーザーは専門用語ではない表現のクエリを多用する場合、embeddingでも類似度が高くならないことが多々あります。こう言った場面でもユーザーがより望む検索結果を返すために、試行錯誤する必要があることがわかりました。

検索専門のエンジニアの方と一度お話ししてみたいな、とか思ったりしました。

では今日はここまで。