RAG｜「どう作るか」より先に、答えを疑う型を持つ

以前、「生成AIで解析できても、MIは別次元の話」では、生成AIでツールが作れることと、材料開発の機械学習ができることは違う、と書きました。

生成AIの話をしていると、ChatGPTで壁打ちしている話と、社内文書を入れたチャットの話が混ざりやすいです。画面がチャットで、答えが文章なら、なおさらそうです。後者は、いわゆるRAGに近い使い方です。RAGは生成AIの代わりではなく、選んだ文書を探してから生成AIに書かせる組み合わせです。ChatGPTが公開Webやモデル内の知識を見るのとは、踏むソースが違います。

自分は実装の専門家になるより、現場がどの道具をどの仕事に当てるかを誤らないようにする側に立ちたいと思っています。RAGの良さは、フォルダを漁る時間や、長い文書を全部読む手間を減らせるところにあります。答えが早く出る。ただ、出ることと使ってよいことは別です。探す時間は減っても、信じる前の確認は残ります。現場で先に効くのは「どう作るか」より「作った答えをどう疑うか」のことが多い。今回は、答えの出典をどう確かめるかを書きます。

リンクが出ていても、正しいとは限らない

RAGの画面では、答えの末尾にファイル名やリンクが付くことが多いです。根拠があるように見える。自分も、つい安心してしまいそうになります。

ただ、リンクが付いていても、答えの一文一文がその文書から来ているとは限りません。近い文書を示しつつ、中身のもっともらしい部分は文脈を外れて書かれている、ということが起きえます。リンクを開いても、本文にその数字や条文がない。見た目の「出典付き」は、正しさの保証ではありません。

ここで自分がまずやることは、構築の設定をいじることより、提示された出典を開いて突き合わせることです。答えにある数値や条件が、文書の該当箇所にそのままあるか。ないなら、その答えは使わない。

開いただけでは足りないとき

突き合わせたあとに、もう一段見ることがあります。全部を同じ重みで見るというより、自分はまず危ないところから疑います。

いちばん危ないのは、例外や適用除外を切り取った要約と、表の読み違えです。原則だけ拾って例外が落ちていると、現場ではそのまま事故になります。根拠が表なら、行と列、単位（ppmと%など）も見ます。次に、版です。旧規格や更新前のパラメータを引いていないか。他部署のローカルルールや、別素材の知見を混同していないかも、ここで見ます。複数の文書をまとめたように見えるときは、対立する見解を平均化したり、片方の警告を落としていないかを最後に疑います。

言葉にするとチェック項目のようですが、やっていることは実験ノートや規格を自分で読むときの確認に近いです。AIの出力だから特別な作法、というより、一次情報に戻る、というだけです。現場ではまとめてハルシネーションと呼ばれがちですが、中身は根拠のない創作だけでなく、古い版や別部署の文書の取り違え、要約の歪みも含みます。疑う型は、そのどれにも効きます。

うまくいかないとき、モデルが新しいかどうかより先に疑うのも、入れる前の文書の形です。表が崩れたPDF、原則と例外が別々に切れた規程、型番やCASのような一字一句が重要な識別子。文章の要約には強くても、ここは落ちやすい。ELNやExcelの話で書いてきたことと、根は同じです。ゴミを入れると、もっともらしいゴミが出ます。出典を確かめる作法は、そのゴミに気づくための最後の砦でもあります。

構築より先に、疑う側の型を持つ

RAGを厚く語るとき、チャンクや検索の話に寄りがちです。それ自体は必要ですが、現場で先に効くのは「出典を開く」側の型だと思っています。「どう作るか」の前に、「この答えを信じてよいか」を疑えること。リンクがあれば信じる、では足りない。開く、突き合わせる、版と範囲を見る。表なら単位まで疑う。

道具の当て方を誤らないことと、当てたあとに一次情報へ戻ること。どちらも、実装より手前の仕事です。うまく使うイメージは、最終答えを機械に任せるより、議論のきっかけを早く拾うことに近いです。よくわかっている人に聞く、会議の議題にする——属人化をゼロにはできなくても、探す入口を減らして、人と話すところまで運ぶ。MIでも「モデルが全部決める」という幻想が起きやすいのと同じで、RAGにも「入れれば何でもわかる」という期待が乗りやすい。文書の形をどう整えるかは、また続きます。RAGを扱うときに最初に持つべきは、答えを疑う側の型だ——そう感じています。

あわせて読む：生成AIで解析できても、MIは別次元の話

データ活用やマテリアルズインフォマティクスの実務については、「データ活用の実務」マガジンにまとめています。