検索結果が全部似ていると、結局あまり役に立ちません
検索でいちばん困るのは、結果が少ないことだけではありません。 むしろ厄介なのは、件数はあるのに中身がほぼ同じ ことです。
たとえば認証まわりの設定を調べたいのに、同じファイルの近い行や、ほぼ同じ内容のメモが上位に何件も並ぶとします。関連はしているので完全なハズレではないのですが、知りたいことの全体像はなかなか見えてきません。
この問題に効く考え方のひとつが MMR, Maximal Marginal Relevance です。これは OpenClaw 固有の仕組みではなく、情報検索の文脈で長く使われてきた再ランキングの発想です。OpenClaw はその考え方をメモリ検索の後段に取り入れて、関連性が高いだけではなく、すでに選ばれた結果と似すぎていないかも見る ようにしています。
つまりこの記事で見たいのは、「OpenClaw が生み出したアルゴリズム」ではなく、一般的な MMR という手法を OpenClaw がどう実装に落としているか です。
これ、地味ですがかなり大事です。検索体験の「賢そうに見えるけど使いにくい」を減らす効き方をします。
まず MMR は何をしているのか
MMR は1998年の Jaime Carbonell 氏と Jade Goldstein 氏の論文で広く知られた考え方です。発想はとても素直で、検索結果を一気に確定するのではなく、上から1件ずつ選ぶ 形で並び替えます。
そのときの評価式がこれです。
スコア = λ × 関連性 − (1−λ) × 選択済み結果との最大類似度見るポイントは2つだけです。
- 関連性 が高いほど上げる
- すでに選んだ結果と似ている ほど下げる
つまり、単純なランキングなら2位に来そうな結果でも、1位とほぼ同じことしか言っていないなら少し下げる。逆に、関連性は少し落ちても別の角度から役立つ情報なら上げる。そういう再配列をやっています。
なぜこれが効くのか
関連性だけで並べると、上位はどうしても「同じ話の別バージョン」になりやすいです。
特に OpenClaw のように、日付ごとのメモや類似したログ、少しずつ表現の違うナレッジ断片を扱う場合は、この偏りが起こりやすいです。ある話題について複数日に似たメモが残っていれば、ベクトル検索でも BM25 でも、その近辺が上位を占めやすくなります。
でもユーザーが本当に欲しいのは、似たメモを5件読むことではなくて、たとえば次のような組み合わせです。
- 直接その設定に触れているメモ
- 背景や前提を書いたまとめ
- 関連する別要素, たとえばネットワーク, 権限, 環境変数の記述
MMR を入れると、この「結果の束としての有用さ」が上がります。1件ごとの精度だけではなく、上位3件, 5件をまとめて見たときの役立ち方を改善する考え方です。
OpenClaw 実装では lambda が効きます
この式の λ は、関連性と多様性のバランスを決めるノブです。
λ = 1.0なら純粋な関連性順λ = 0.0なら多様性だけを重視- デフォルトは
0.7
OpenClaw のデフォルトが 0.7 なのは、かなり納得感があります。
多様性だけを強くしすぎると、今度は「違う話題だけど query にはそこまで近くない」結果が上に来すぎます。検索としてはそれも困ります。逆に 1.0 に寄せると、似た内容が固まりやすい。
その意味で 0.7 は、まず関連性を優先しつつ、似すぎた結果だけを少し押し下げる という実務寄りの設定です。検索体験を大きく壊さずに、上位の重複感だけを減らしやすいところに置いてあります。
OpenClaw 実装が軽い方法を選んでいるのも良いです
OpenClaw の MMR で面白いのは、結果同士の類似度計算に Jaccard 係数 を使っていることです。
Jaccard 係数は、ざっくり言えば「2つのテキストをトークン集合にしたとき、どれくらい重なっているか」を見る方法です。
- 共通トークンが多いほど高くなる
- 重なりが少ないほど低くなる
これを使う利点は、軽い ことです。
検索結果どうしの多様性判定のために、毎回重いベクトル演算を追加で回さなくてもよい。上位候補の再ランキングという局所的な処理に対して、十分わかりやすくて、実装コストも計算コストも抑えやすいです。
私はこの設計、かなり実用的だと思います。検索の本筋はあくまで元の関連度スコアに任せて、そのあと「似すぎ問題」だけを軽く補正する。役割分担がきれいです。
どういう並び替えが起きるのか
たとえば「認証設定」を探したときに、最初の関連度だけで見るとこうなりがちです。
1. auth.ts の設定メモ
2. auth.ts の別行を抜いたメモ
3. auth.ts の修正ログ
4. 環境変数一覧
5. セッション管理の説明この並びは、上位3件がかなり近い話をしている可能性があります。
MMR が入ると、1件目を選んだあとで、2件目と3件目は「関連は高いけど1件目と似すぎている」と評価されやすくなります。その結果、4件目や5件目のように、少し違う観点を持つ情報が上に上がってきます。
1. auth.ts の設定メモ
2. 環境変数一覧
3. セッション管理の説明
4. auth.ts の修正ログ
5. auth.ts の別行を抜いたメモこのほうが、調べ物としてはかなり使いやすいです。
OpenClaw では MMR は検索の最後で効きます
ここを勘違いしないほうがよいのですが、MMR は検索そのものを置き換えるものではありません。
OpenClaw のメモリ検索では、まずベクトル検索や BM25 のような方法で候補を集めます。そのあとでスコアを混ぜ、必要なら temporal decay のような調整も入れ、最後の仕上げとして MMR で並びを整える 形です。
この順番が良いです。最初から多様性だけで候補を集めると、query に十分近くない断片まで混ざりやすくなります。一方、関連度の高い候補をまず集めておけば、MMR はその中で「同じ話ばかり」を散らす役に集中できます。
要するに、OpenClaw の MMR は検索エンジンの中心というより、上位結果の品質を整える再ランキング層です。この立ち位置だから、副作用を抑えつつ効かせやすいのだと思います。
単純な重複除去では足りない理由
「似た結果が困るなら dedup すればいいのでは」と思うかもしれません。実際、その発想自体は自然です。
ただ、実務では完全一致の重複より、微妙に違うけれど役割がほぼ同じ結果のほうが多いです。
- 同じ設定を別の日に書いたメモ
- 同じ障害の再発記録
- ほぼ同じ説明だが、語尾や前提だけ違うメモ
- 同じファイル由来だが、切り出し位置が少し違う断片
こういうものは、厳密な重複判定だと別物として残ります。でもユーザーから見ると、上位に何件も並ばれても新しい学びは増えません。
MMR はここにちょうど効きます。完全に消すのではなく、「似ているなら少し下げる」という扱いにできるからです。検索結果として残す柔らかさを持ちながら、上位の詰まりだけを解消しやすい。ここが単純な dedup より賢いところです。
Jaccard を使うのは、派手さより実装の釣り合いを取っているからです
検索品質の話になると、つい「類似度も埋め込みで再計算したほうが高度なのでは」と考えがちです。もちろん精密さだけを追うなら、そういう方向もあります。
でも OpenClaw の MMR がやりたいのは、候補同士の厳密な意味理解というより、上位結果に同じ話が固まりすぎるのを避けることです。その用途なら、トークン集合ベースの Jaccard 係数はかなり理にかなっています。
理由は3つあります。
- 実装がシンプルで壊れにくい
- 計算が軽く、再ランキングに向いている
- 似た文面, 似た設定断片, 似たログを見つけるには十分効く
つまりこれは、「最先端だからこれを採用した」というより、この問題に対して必要十分な重さで解いている 実装です。私はこういう判断のほうが、長く運用するソフトウェアでは好きです。
どんなときに特に効くのか
MMR が特に効きやすいのは、情報が時間をまたいで蓄積されるケースです。
OpenClaw のメモリやセッション断片は、どうしても日々似た話題が増えていきます。ネットワーク設定、認証設定、プロジェクト判断、環境変数、障害メモ。これらは一度で終わらず、あとから追記や修正が入ることが多いです。
その結果、検索では「同じテーマの近縁ノート」が大量に見つかります。ここで MMR がないと、上位は似た結果で埋まりやすいです。
逆に、ナレッジ量がまだ少ない初期段階や、query がかなりピンポイントで重複候補も少ない場合は、MMR の存在感はそこまで大きくありません。つまり MMR は、データが増えるほど価値が見えやすいタイプの改善です。
この性質は、個人メモよりチーム運用でさらに効いてきます。複数人が似たトピックを何度も書くようになると、検索の重複感は一気に増えるからです。
AIエージェントにとっては『思い出し方』の品質そのものです
ここは検索の細部に見えて、実はエージェント体験に直結します。
AIエージェントは、思い出した断片をもとに次の返答や行動を組み立てます。だから、同じ話の断片ばかりを何件も拾うと、モデルの入力も偏ります。結果として、答えが妙に狭くなったり、同じ前提ばかり強化されたりします。
MMR で上位の重複を減らすことは、単に検索画面を見やすくするだけではありません。エージェントが参照する文脈を偏らせすぎない ことにもつながります。
これはかなり重要です。AIエージェントでは、検索品質がそのまま推論の材料品質になるからです。関連しているけれど別角度の断片を拾えるほど、応答の視野も広がりやすくなります。
設定としてもかなりわかりやすいです
OpenClaw では MMR は設定でもかなり素直です。
{
"agents": {
"defaults": {
"memorySearch": {
"query": {
"hybrid": {
"mmr": {
"enabled": true,
"lambda": 0.7
}
}
}
}
}
}
}この設計のよいところは、オンオフとバランス調整の2つにほぼ整理されていることです。
- まず有効にするかどうか
- そのうえで relevance 寄りにするか diversity 寄りにするか
複雑なパラメータが何段もあると、現場では結局触られません。その点で OpenClaw の MMR は、理解しやすくて試しやすいです。検索結果が似すぎると感じたら有効化する, あるいは lambda を少し触る, という運用がしやすい形になっています。
重要なのは『関連性を捨てない多様性』です
MMR の良いところは、多様性のために関連性を全部捨てないことです。
検索品質の話でときどきあるのが、「重複を減らしたい」からといって、似ている結果を乱暴に間引いてしまうやり方です。でもそれだと、本当に必要な結果まで消えることがあります。
MMR はそうではなくて、関連性の高さをベースに残しながら、その中で似すぎたものを少し後ろへ回す というやり方です。だから、検索エンジンとしての筋を保ったまま、上位の顔ぶれを改善しやすいです。
このあたりは、OpenClaw が MMR をかなり素直に実装している部分だと思います。派手な独自アルゴリズムを足すというより、既存の良い考え方を、実際の使いにくさを潰す形できちんと使っている感じがあります。
もう一歩踏み込んで言うと、MMR の価値は単発検索よりも、毎日少しずつ知識が増えていく環境で大きくなります。履歴が積み上がるほど、検索の上位は放っておくと似た記録で埋まりやすくなります。だから MMR は、検索品質の飾りではなく、長期運用するナレッジ基盤のための地味で重要な保険でもあります。
参考にしたリンク
まとめ
MMR は OpenClaw 固有のものではなく、検索結果の多様性を確保するための一般的な手法です。そのうえで OpenClaw は、その考え方をメモリ検索にうまく取り入れていると思います。
ポイントはシンプルです。
- 関連性だけで並べない
- すでに選ばれた結果との重なりも見る
- そのバランスを
lambdaで調整する - 類似度判定は Jaccard で軽く回す
検索品質って、派手なモデル改善だけで決まるわけではありません。上位に何が並ぶか、その束がどれだけ役に立つかで体感はかなり変わります。
OpenClaw の実装は、まさにその「束としての使いやすさ」を良くする例です。認証設定のように近い記述が何度も出てくるテーマほど、この工夫の価値は見えやすいと思います。
