Open WebUIでPDF・文書へ質問するRAG入門｜最初の1ファイルで確認する

Open WebUIでPDFや文書へ質問するとき、最初に見るべきなのは「回答がそれらしいか」ではない。

重要なのは、質問に必要な箇所が文書から取り出され、その内容を根拠に回答しているかだ。

RAGでは文書検索と回答生成が分かれているため、最初は一つの文書と答えが明確な質問だけで確認する。

図を拡大して見る

図: 処理や設定の流れを1枚に整理。実際の操作条件は本文で確認する。

最初は一つの文書だけ追加する

いきなり大量のPDFを登録すると、問題が起きたときに原因を追いにくい。

内容を自分で確認できる短いPDFやテキストを一つ選び、Open WebUIへ追加する。

最初に確認したいのは次の三点だ。

1. 文書をOpen WebUIから参照できる
2. 質問時に文書の必要な箇所が使われる
3. 表示された参照元を原文と照合できる

この段階では、数百ファイルの一括登録や複雑な設定へ広げない。

答えが原文に明記された質問を使う

最初の質問は、複雑な推論が必要なものより、原文と照合しやすいものがよい。

例
・この文書の公開日は何月何日？
・手順3で行う操作は何？
・対応OSとして何が列挙されている？

回答が返ったら、文章の自然さだけを見るのではなく、参照元や取得された箇所を開く。

原文にその内容がなければ、生成モデルを交換する前に文書検索側を確認する。必要な箇所がモデルへ渡っていなければ、生成モデルだけ変えても中心の問題は残る。

通常のRAGとFile Contextを分ける

Open WebUIでは、関連する部分を検索してモデルへ渡す使い方と、File Contextとして文書全体をコンテキストへ含める使い方がある。

文書全体を入れれば常に良くなるわけではない。モデルが扱えるコンテキスト長、会話の長さ、文書サイズによって条件が変わるためだ。

長い文書で回答が弱いときは、次を分ける。

確認する場所	見ること
原文	答えになる記述が本当にあるか
検索	必要な記述が取得されているか
参照元	回答がどの箇所を根拠にしたか
コンテキスト	必要な内容がモデルへ渡る条件か

RAGを使っただけで、長い文書全体を完全に理解できるとは考えない。

埋め込みモデルを変えたら索引も確認する

Open WebUIの公式資料では、埋め込みモデルを変更した場合、既存文書の索引を作り直す必要があることが案内されている。

埋め込みは文書と質問を検索用の数値表現へ変えるため、索引を作ったときと検索するときの条件を無関係に入れ替える前提にしない。

設定変更後に急に検索結果が悪くなった場合は、生成モデルより先に、既存文書の索引がどの埋め込みモデルで作られたか確認する。

回答が弱いときは四段階で戻る

1. 原文 — 答えが本当に文書へ書かれているか
2. 取得箇所 — 必要な箇所が検索で取り出されたか
3. 入力内容 — 取得した内容がモデルへ渡ったか
4. 生成 — 渡された根拠から適切に回答できたか

この順番なら、何でもモデル性能の問題にせず切り分けられる。

最初の文書で動いたら、文書内に答えがある質問と、文書だけでは答えられない質問を数件ずつ保存する。同じ質問を設定変更後にも使えば、RAGの挙動の変化を比較しやすい。