Semantic Search
読み: セマンティック・サーチ
意味検索とは文脈で探すAI技術
Semantic Searchはユーザーが入力した単語の表面的な一致ではなく検索意図や文脈をAIが理解し最も関連性の高い情報を提供するベクトルベースの検索技術である。
かんたんに言うと
図書館で「赤い表紙の犬の絵本」と司書に伝えたとき、タイトルにその言葉がなくても中身を理解して目当ての一冊を差し出してくれるような仕組みである。
表記揺れによる検索漏れを防ぐSemantic Searchの技術的全体像
法務部門で過去の契約書を探す場面を想像してほしい。担当者が「契約解除」と検索窓に打ち込む。従来のLexical Searchでは、文書内に「ターミネーション」や「中途解約」としか書かれていないファイルは容赦なく弾かれる。文字の完全一致に依存しているからである。
現場の表記揺れは想像以上にひどい。
Semantic Searchは、この言葉の壁を越える。テキストを意味の塊として捉えるベクトル検索を用いることで、入力された単語と直接一致しなくても、文脈が近い文書を的確に拾い上げる。検索漏れによる法的リスクを未然に防げる恩恵は計り知れない。
自然言語を数値化するベクトル変換と類似度計算の仕組み
裏側で動いているのは、Embeddingと呼ばれるテキストの数値化処理である。OpenAIのtext-embedding-3-smallやCohereのモデルを使い、文章を数百から数千次元のベクトル空間に配置する。
意味が近い言葉ほど、この空間内で近い位置にマッピングされる。
検索クエリも同じようにベクトル化し、データベース内の各ベクトルとの距離をコサイン類似度などで計算する。距離が近ければ類似度が高いと判定するわけである。非エンジニアには魔法のように見えるかもしれないが、実態はただの膨大な行列計算にすぎない。モデルの選定を間違えると、的外れな空間配置になり目も当てられない結果になる。
文脈理解による精度向上の恩恵と計算コストのトレードオフ
表記揺れを吸収し、ゼロヒットを激減させるメリットは大きい。だが、良いことばかりではない。
ベクトルデータの生成と保存には、それなりのインフラ費用がかかる。
PineconeやWeaviateのような専用のベクトルデータベースを契約するか、Elasticsearchの密ベクトル検索機能を自前でチューニングするか。どちらを選んでも、数百万件の社内データを扱うとなれば計算コストが跳ね上がる。インデックスの更新頻度をどう設計するかで、システムのレスポンス速度も大きく変わる。精度をどこまで追い求めるか、インフラ予算とのバランスは常に悩ましい。
現場に導入する際の落とし穴とハイブリッド検索のジレンマ
経理部門の過去の稟議書検索にRAGを組み込むプロジェクトで、よくある失敗がある。すべてをSemantic Searchに置き換えようとするケースである。
品番や特定の日付、金額といった完全一致が求められる条件では、ベクトル検索は途端にポンコツになる。意味の近さで探すため、似たような別の品番を上位に持ってきてしまうからである。
結局のところ、Algoliaなどを活用してLexical Searchと組み合わせたハイブリッド検索に落ち着くことが多い。ただ、両者のスコアの重み付けをどう設定するかで、現場の評価が真っ二つに割れる。どの検索手法を信じるか、最終的な判断が分かれるところである。
当社の見解
当社はAI長期記憶システムを自社開発・運用している。開発のきっかけは、AIと経営戦略の壁打ちで出した結論がセッション切れで消えたことで絶望を感じた。1日かけて議論してきたことを振り返り、では事業計画書に落とし込むように指示を出したところ、「そのような記録はありません」と言われたことで、強烈な危機感を覚えこれは何としても解決しなければならない問題だと感じた。記憶がないAIは毎朝記憶喪失になる新入社員と同じだ。記憶があるAIは、前提条件を理解した上で本題に入れる。短いプロンプトで済むようになり、「前に言ったように実行して」と曖昧で短いプロンプトでも業務を遂行してくれる。同じことを繰り返し伝える回数も減り、開発業務でも同じミスを繰り返しにくくなり、人間の手戻りが減り、ストレスも減る。AIで本当に業務の質を上げるならば、記憶はマストである。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。