最近少しは減ったんだけど、社内のチャットやメールをRAG化して社内ナレッジチャットボットを作りたい、とか お問い合わせのやり取りをRAG化して(以下略 みたいな相談がよくあります。

一時期よく見かけたけど、うちに来る相談では減りましたね。 なんでか。

RAGを作ったところで目的は果たせないんですね。 先にやった人達が、やってみて分かったんだと思います。

やり取りの中にナレッジは無い

想像すればすぐわかるんですが、実際のやり取りの中に具体的なナレッジなんか無いです。

銀行や役所の問い合わせを想像してみてください。

「◯◯について聞きたいんだけど」 「◯◯というページ(資料)の✖️✖️の箇所をご確認ください」

みたいなやり取りですよね。 自然な会話なので、マニュアルみたいに全部固有名詞を並べたてたりしません。 「さっきの件」「あの資料」「前に言ったやつ」で通じてしまう。

社内のやり取りなら尚更です。 共通の前提があるから短く済むわけで、短く済んでいるということは、 書かれていない部分にこそ中身があるんです。

「LLMに要約させて整形すればいいのでは」と言われることなんかもあります。 無理です。元の会話に無い情報は、要約しても増えません。 参照先の資料そのものを持っていないので、 綺麗に整形された「✖️✖️をご確認ください」が出来上がるだけです。

引かれる側に答えが無いと何も出ない

RAGの仕組みを雑に言うと、質問も資料も意味のベクトルに変換して、近いものを引っ張ってくる。 そこにLLMが文章を組み立てる。

ここでよく誤解されるんですが、引っ張る部分をやっているのはLLMではないし、 単語の一致で引いているわけでもありません。意味が近ければ、言い回しが違っても引けます。

つまり表記ゆれの吸収みたいな話ではなくて、 引っ張られる側に答えの実体が書かれているかどうかが全てです。 無ければ、どれだけ賢いモデルを繋いでも何も出てきません。

正しい順序は二面のループ

じゃあどうするか。 二つを並行して、ぐるぐると補完させる必要があります。

ひとつは問い合わせの整理とデータ化。 実際のやり取りからは、ナレッジは取れませんが、偏りは取れます。 何が繰り返し聞かれているか、どこが疑問に思われやすいか。これは十分な資産です。

もうひとつは回答・ナレッジの構造化。 RAGに食わせるための、きちんと言語化されたドキュメントの整備。

この二つはループします。 偏りが分かると、どのドキュメントから整備すべきかの優先順位が決まる。 全部整備するのは現実的に無理なので、頻出上位から手を付ける。 整備が進むと、次はどこが手薄かが見えてくる。

この順序を踏まずに「まずRAG」から入ると、作ってから何も出ないことに気づいちゃいます。

多分こんな事が多くて、一時期「構造化RAG」とか「RAGだけではなく構造化データを使う」 とか見かけましたね。 あと、「作ったけどなんか上手くいかない!」の原因は大体コレでした。

結局FAQ作るの??

ここまで来ると、当然こう言われます。「FAQで足りるならRAGは要らないのでは」と。

そうですね。足りるならFAQで足ります。 そして、それに気づけること自体が実は大事。

RAGが効いてくるのは、整理した結果が量的に多すぎて人間が探せない場合と、 聞き方の揺れが大きくて目次では辿り着けない場合。 つまり整理してみて初めて、RAGが必要かどうかが判断できる。

だから、AIを使ってナレッジ検索システムを作りたいなら、 まずAIを使ってFAQを整理してください。

同じLLMですが、使いどころが違います。 分類して、クラスタリングして、言語化する。この地味な方の作業にこそ、今のLLMは向いています。

そしてそっと蓋をする

要するに、AIを活かしたナレッジシステム導入の話は始めた瞬間にドキュメント整備の話に変わります。 そういうのちゃんとしてないので、ナレッジシステム欲しいんでしょうけどそんなに甘くないです。

なんだけど。FAQ整備からしようよ!っていう提案や意見は大体通りません。 「AIを導入する!」「RAGを入れる」が看板になって予算ついているので、 「まず整理しましょう、結果的に要らないかもしれません」はちゃぶ台返しもいいとこなんです。

こうして、ナレッジシステム担当者は問題点に気づきつつもそっと蓋をして 「なんだかすごそうだけど誰も使わない」いつもの奴が出来上がります。 前提がダメなやつの、よくあるパターンですね。

RAGの相談が減ったのは、たぶんそういうことなんじゃないでしょうか。