賢いモデルにしても、索引は良くならない

文章を書く人工知能のことを、大規模言語モデルという。英語で large language model、その頭文字をとって LLM とも書く。オープンAIの GPT、グーグルの Gemini、アンソロピックの Claude が、それにあたる。以下ではモデルと呼ぶ。

使っていて、いちばん当てにならないのが、資料を探させることである。

これについて調べて、と頼むと、それらしいものが返ってくる。だが、いま欲しかったものではない。手元にある正解の資料は素通りして、遠くの関係ないものを持ってくる。

モデルの中を探させるのは、そもそも駄目

まず、外の資料を渡さずに、モデルが覚えていることから答えさせる場合。これは使えない。

モデルは次に来そうな語を選んでいるだけなので、出典を聞かれれば出典らしい文字列を作る。書名も、著者も、条文の番号も、それらしい形で出てくる。実在するかどうかは、仕組みのどこでも確かめていない。

これは有名になったので、いまはだいたい知られている。だから、手元の資料を渡す方式が普通になった。

調べ物が微妙なのは、索引が借り物だから

もっと身近なところにも、同じ話がある。AIに調べ物をさせたときの、あの微妙さである。

まず、モデルが自分で世界を探しているわけではない。ChatGPT の検索も、外の索引を借りている。長らくマイクロソフトのビングが主だったが、いまは自前の巡回や複数の提供元が混ざっていて、何をどう引いているかは公表されていない。

手順はこうなっている。こちらの質問を検索語に書き直す。それで検索する。返ってきた結果の見出しと説明文だけを見て、どれを開くか決める。開いたものを読む。まとめて、出典を付けて返す。

三つ目が効く。中身を読む前に、見出しと短い説明文だけで切っている。だから、書いてある内容が良くても、見出しが地味なページは最初から答えに入らない。落とされたことは、こちらからは見えない。

もう一つある。八千万件の問い合わせを調べた分析によると、実際に検索が走るのは半分以下で、残りは学習した内容だけで答えているという。こちらは調べてもらったつもりでいる。

つまり、調べ物の出来を決めているのは、検索の索引の質と、その切り方である。優秀なのは検索エンジンの側であって、モデルの側ではない。

渡す方式にすると、選ぶ問題が残る

ところが、渡せば済むわけでもない。

窓には上限があるので、全部は渡せない。仮に入ったとしても、関係ない資料を大量に添えると、かえって精度が落ちる。人に頼むときと同じである。

だから、渡す前に選ぶ。手元の資料の中から、いま関係のありそうなものだけを取り出して渡す。この選ぶ部分が、実は本体になる。

そして、ここの出来がそのまま答えの出来になる。選び損ねた資料は、モデルにとって存在しない。存在しないものについて、モデルは何も言えない。

どう選ぶのがいいか、測った

選び方には、大きく二つある。

一つは、珍しい語の一致で選ぶ。昔からある数え方で、どこにでも出てくる語は軽く、めったに出てこない語は重く数える。同じ珍しい語を共有している文書ほど、関係が深いとみなす。

もう一つは、意味の近さで選ぶ。文を数のならびに変換して、そのならびが近いものを取る。言い方が違っても意味が同じなら拾えるのが売りである。世間では、こちらの方が新しくて賢い、ということになっている。

手元のコーパスで、どちらが当たるかを測った。

正解として使ったのは、承認済みの結びつき三百四十三本である。この資料とこの資料は関係がある、と人が確かめて印を付けたものだ。片方を手がかりにして、もう片方を当てられるかを競わせた。

結果

上位六件の中に正解が入っていた割合で比べる。

珍しい語の一致で選ぶ方式が、〇・九七一。

意味の近さで選ぶ方式が、〇・七五五。

差の中身も見た。意味の方だけが上位六件に入れられたペアは、ゼロ本。逆に、珍しい語の方だけが入れられたペアは、七十四本から九十五本あった。片方が拾えてもう片方が落とす、という場面が一方向にしか出ていない。

得意なはずの場面でも負けた。同じことを別の言い方で書いた組、つまり言い換えを当てる勝負である。上位三件で、珍しい語の方が〇・九五四、意味の方が〇・七九二だった。

大きいモデルにしたら、悪くなった

意味の方は、二つの大きさで試している。小さい方が〇・七五五、大きい方が〇・六九四だった。

大きい方が悪い。

一件の比較なので、これを法則だと言うつもりはない。ただ、少なくとも、大きくすれば良くなる、は起きなかった。もう一段大きいものを持ってくれば逆転する、という見込みも立たない。

そして、勝った方の数え方は、モデルを一つも使っていない。珍しい語を重く数えるだけの、機械学習より前からある算数である。賢さがゼロの方式が、二つのモデルに勝った。

自分に不利な条件も書いておく

この実験には、こちらに有利な偏りがある。

正解として使った結びつきは、もともと珍しい語の一致で候補を出して、人が承認したものである。だから、そのやり方が当たりやすい土俵になっている。

ただ、それを差し引いても結論は動かない。偏っている土俵の上でさえ、意味の方は一件も上乗せできていない。ゼロ本、というのはそういう意味である。両方を組み合わせる、という案の根拠も出なかった。

なぜそうなったか

理由は、コーパスの性質にある。

探したかったのは、「これは同じ作業の続きだ」という関係だった。この関係の署名になっていたのは、意味の近さではなく、珍しい固有名詞の共有だった。同じ道具の名前、同じ企画の名前。意味としては何の関係もない二つの記録が、その語を共有しているという一点で正解になる。

もう一つ。手元の資料は、同じ書き手が一貫した言葉づかいで書いている。言い換えの問題がそもそも小さい。意味検索が輝くのは、書き手がばらばらで、同じことを違う言葉で書いている場合である。

索引は、モデルの中に無い

ここがいちばん言いたいところである。

何をどう探すか、という仕組みは、モデルの中に入っていない。モデルは文字列を受け取って文字列を返す部品で、資料の並べ方も、どれを候補に出すかの規則も、外側にある。

だから、モデルが賢くなっても、索引は上手くならない。別の場所にある部品だからである。

これは、待っていれば解決する種類の問題ではない、ということでもある。文章を書く力も、コードを書く力も、この一年で目に見えて上がった。だが探す方は、こちらが設計を変えないかぎり、去年と同じ精度で外し続ける。

しかも、どの方式が当たるかは、手元の資料の性質で決まる。誰が書いたか、語彙が揃っているか、探したい関係が何か。ここが違えば答えが逆になるので、一般論では決まらない。

測るしかない。正解を何十件か手で作って、候補の中で何位に来るかを見る。半日で終わる作業である。

資料を探させると役に立たない、というのは、モデルが馬鹿だという話ではない。索引を誰も設計していない、という話である。