社内文書を読ませたAIが的外れに答える本当の理由：解約の手順を尋ねたら、契約の手順が返ってきた

社内文書をベクトルデータベースに入れた翌週、総務部に問い合わせが届いた。

社内AIが答えた解約の手順は、契約の手順だった。

導入を決めた会議では、AIが社内の事情に詳しくなる、という説明があった。

答えを信じた社員は、契約の手順で解約を進めようとする。原因を直さなければ、総務部には同じ問い合わせが届き続ける。

AIの中身（重み）は、導入の前後で同じだ。外れた答えの材料は、どこから来たのか。

ベクトルデータベースの正体は、似た文章を探す索引だ

材料を選んだのは、ベクトルデータベースである。文書を数の並び（ベクトル）に変換して保存し、問いに近い並びを素早く探す。

名前にデータベースとあるが、役割は索引である。正しい答えをしまう帳簿とは別物だ。

AIの言語モデル（LLM、大規模言語モデル）は、索引が探してきた文章を材料に答えをまとめる。

二つの組み合わせを、検索拡張生成（RAG）と呼ぶ。呼び名の出どころは、Lewisらが2020年に公開した論文だ。

論文が示した仕組みでも、外の知識はWikipediaのベクトルの索引だった。

「似ている」と「答えが書いてある」は、なぜ別物なのか

数の並びの近さが測るのは、話題や言い回しの似かたである。問いに答える中身が書いてあるかは、測る対象の外にある。

サービスの解約の手順を尋ねると、仕組みが契約の手順を近いと判定することがある。

対象外になる条件を聞いたのに、対象になる条件を書いた文章が返ることもある。一字違いで意味が変わる型番、金額、日付も、取り違えの起きやすい箇所だ。

言葉の一致で探す検索と組み合わせる設計も、広く普及している。「解約」の一語を含む文章を、言葉の一致で拾えるからだ。

「前述のとおり」で始まる段落が、答えを狂わせる

多くの仕組みは、文書を段落ほどの大きさに切って探す。切り出した段落は、前の段落と離れてAIに届く。

解約の手順書の段落が「前述のとおり」で始まっていたら、どうなるか。段落は切り出した瞬間に、話題の消えた断片になる。

何の手続きの話かが消えた断片は、解約の問いに近いとも遠いとも決めにくい。索引は、契約の手順の段落を代わりに選ぶ。

LLMは、受け取った文章が的外れでも、受け取った文章をもとに滑らかな答えをまとめる。

答えが外れたらモデルを替えよう、という会議がある。間違った資料を受け取った部下を、交代させる会議に似ている。

交代した部下も、同じ資料を受け取れば、同じ答えを書く。

探させる前に、知りたいことを言葉にする

答えがおかしいときは、AIが受け取った材料を一覧で確かめる。

資料は、一つの段落だけ読んでも、何の話かが伝わるように書く。契約と解約のような似た手続きは、違いを冒頭に書く。

問う側の言葉も直す。解約なのか契約なのか、対象なのか対象外なのかを、先に言葉にする。

先に言葉にした人は、返ってきた材料が問いに答えているのか、似ているだけなのかを見分けられる。

AIに問う力とは、探させる前に、何を知りたいかを決める力だ。何を問うかを決めるのは、問う人の仕事である。

次のプロンプトのかっこの中を、自分の問いに書き換えて使える。

社内規程の資料から、次の問いに答えてください。
知りたいこと：（例：年度の途中でサービスを解約する手順）
似た手続きとの区別：（例：契約の手順や、更新の手順とは別の話です）
出力：（例：答えと、根拠にした資料の名前と段落の引用）

総務部の問い合わせは、材料の一覧で解ける

ベクトルデータベースが返すのは、問いに似ている文章だ。似ている文章と、答えが書いてある文章は別物である。

総務部に届いた問い合わせも、材料の一覧を開けば原因の段落が見つかる。

直すのは、モデルではない。解約の手順書の一段落と、問いの一行である。

この記事の考え方は、拙著『GoogleのAI NotebookLM 意思決定の強化書』の2章1節「ソースの品質がすべての土台」に書きました。この節を読むと、契約と解約のように似て中身が逆の文書が一緒に拾われたとき、どちらを根拠にさせるかを検索の前に決められるようになります。

出典

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks（Lewis ほか、arXiv、2020年）