01 / 現実の問題

なぜ RAG が必要？

ある企業に、
大量の社内文書があるとします。

社員は文書を一つずつ探す代わりに、
AI に直接質問したい。

仕事で出てくる質問

「製品でこの問題が起きたら、
どう対応すればいい？」

製品マニュアル障害対応の記録最新の保守のお知らせ

LLM がこれらの文書を最初から知っているとは限りません。
最新の情報を持っているとも限りません。

02 / 基本の考え方

まず資料を探し、それから答える。

RAG（検索拡張生成）は、回答を作る過程に外部の情報を取り入れます。

ここで気をつけたいこと

見つかったのが「似ている」資料でも、
必ずしも「回答に役立つ」資料とは限りません。

03 / 説明からゲームへ

小さなロボットに資料を運ばせて、
選び方の影響を見てみましょう。

複雑なモデルやデータベースは、いったん脇に置きます。
ここではお茶のお店の小さな質問で、現実の複雑さを絞ります。

04 / 既存のゲームへ

あなたの課題

お客さんの質問：「何時に開店しますか？」

第1〜3ステージは、資料を選んで直接お客さんに渡します。
第4ステージで返信台が登場し、第5ステージから検索ツールを使います。資料を間違えたら、フィードバックを見て試し直します。

05 / 振り返り · 体験から理解へ

「先頭にあった」あの資料を
覚えていますか？

第5ステージの「新商品のお知らせ」にはタピオカミルクティーが登場しましたが、
価格の質問に答える情報はありませんでした。

回答する側が質問を理解できても、
資料が不適切だったり、必要な根拠が欠けていたりすれば、回答に失敗することがあります。

だから RAG を設計するときは、LLM に加えて、
資料をどう準備し、検索するかも考える必要があります。

このゲームの資料、候補の順序、返信はあらかじめ用意されています。実際の RAG には Embedding、Chunking、検索戦略なども関わります。今回は、その直感をつかむための体験です。