Mac Studio 1台に Dify と LM Studio を置き、日本語PDF 65本の取得、図表のテキスト化、RAGへの取込、300問への回答、LLM-as-judge、集計までをローカルで実行した。
有料のクラウドAPIは使っていない。

この記事で扱うのは、モデルの順位やスコア差の分析ではなく、日本語PDF RAGを作り、固定した設問で性能を測り、再検証できるローカル成果物を残すまでの構成と手順だ。
最後まで実行できたことの確認値として、固定した評価条件で 0.853(256/300)を得た。

評価には、公開されている日本語RAG評価データをもとに文書と正解の版を固定した RAG Eval JA Repro の65PDF・300問を使った。
参照元、派生関係、変更履歴、ライセンスは同ページにまとめている。
本記事のスコアは、この再現用評価基準CSVとローカルJudgeを使った完走確認値であり、他システムとの比較には使わない。

評価パイプラインのコード、Difyテンプレート、プロンプト、r1-r4の公開成果物は saka-cons/rag-eval-ja-pipeline に置いた。
本記事のコマンド例は、この公開リポジトリのルートで実行する前提で書く。

完成形

ハードウェア、推論サーバ、RAGアプリケーションを次の構成にした。

表1: ローカルRAG構築に使用した構成

区分	構成
ハードウェア	Mac Studio M4 Max 36GB
RAG	Dify 1.14.2(Docker・セルフホスト)
ローカル推論	LM Studio(OpenAI互換API)
PDF処理	PyMuPDF 1.27.2.3(MuPDF 1.27.2 / Python 3.13.7)
VLM	`qwen/qwen3-vl-8b`
埋め込み	`Qwen/Qwen3-Embedding-8B-GGUF`
回答生成・Judge	`qwen/qwen3.6-35b-a3b`

処理は6段に分かれる。

図1: 入力固定から取込、回答、Judge、集計、run成果物固定までの6段フロー

Wayback固定URLからPDF 65本を取得し、SHA-256を検証する。
PyMuPDFでPDF本文を抽出し、図・表・ページ画像はVLMでテキスト化する。文字化けを検知したページはVLM OCRに切り替える。
本文と図表テキストをDifyのナレッジへ投入する。
300問をDifyアプリへ送り、回答を保存する。
質問、正解、回答をローカルJudgeへ渡してO/Xを判定する。
スコアを集計し、回答、判定、入力、ローカルキャッシュをrun単位で固定する。

図表を別工程にしたのは、300問のうち table が82問、imageが76問あり、通常のPDFテキスト抽出だけでは評価対象の情報が欠けるためだ。
VLMの有無による比較結果の詳細はZenn第5章で公開している。

36GBに全モデルを常時載せるのではなく、取込時はVLMと埋め込みモデル、回答時は埋め込みモデルと生成モデル、判定時はJudgeというように、工程ごとにLM Studioで使用モデルを切り替える。

1. 入力を固定する

PDFバイナリは再配布しない。
代わりに、Waybackの固定URL、取得スクリプト、SHA-256 manifestを公開し、同じ採用現物を再取得できるようにした。

リポジトリを取得し、Hugging Face dataset から再現用評価基準CSVを置いてから、文書をダウンロードして検証する。

git clone https://github.com/saka-cons/rag-eval-ja-pipeline.git
cd rag-eval-ja-pipeline
curl -L -o rag_evaluation_master.csv \
  https://huggingface.co/datasets/SakataConsul/rag-eval-ja-repro/resolve/main/rag_evaluation_master.csv
python3 repro/download_documents.py
(cd documents && shasum -a 256 -c ../repro/documents_checksums.sha256)

確認対象は65本すべてだ。
ここで確認できるのは、この検証で採用したコーパスを同一バイトで再取得できたことまでだ。

設問と正解には、採用したPDFとの現物照合結果を記録した再現用評価基準CSV（rag_evaluation_master.csv）を使う。
元の列は変更せず、question_new、target_answer_new、target_page_no_new に差分を記録した。
文書固定と再現用評価基準CSV作成の経緯はZenn第1章・第2章・第3章にまとめている。

2. DifyとLM Studioを接続する

LM Studioでは「Serve on Local Network」を有効にする。
Mac上のスクリプトからは http://localhost:1234/v1、DifyのDockerコンテナからは http://host.docker.internal:1234/v1 を参照する。

Dify側では次を設定する。

チャットボットの生成モデルをLM Studioのローカルモデルへ向ける。
prompts/generation_system_prompt.md をシステムプロンプトへ貼る。
検索を hybrid、top_k=10、リランカ offに固定する。
ナレッジ作成時に埋め込みモデルを指定する。

APIキーはリポジトリルートの .env に置く。

cp .env.example .env
# .env に DIFY_KNOWLEDGE_API_KEY と DIFY_APP_API_KEY を記入
set -a; source .env; set +a

3. PDFをVLMで処理してナレッジへ入れる

LM Studioで qwen/qwen3-vl-8b と埋め込みモデルを利用可能にして、VLMありのナレッジを作る。

./scripts/run_r1_r4_ingest.sh vlm --refresh

スクリプトは次を行う。

再現用評価基準CSVの再生成
PyMuPDFによるPDF本文の抽出
図表のVLMテキスト化
RAG-Eval-JA-master-vlm の新規作成
65文書の投入とindexing完了待ち
VLMと埋め込みモデルの利用記録の保存

ナレッジを作り直すとIDが変わる。
取込完了後、Dify Studioのチャットボットで「コンテキスト」を RAG-Eval-JA-master-vlm へ差し替え、アプリを公開し直す。
この更新をしないまま回答収集へ進むと、新しいナレッジが検索対象にならない。

VLM結果は、実行したマシン上でPDF単位の vlm_cache/ と画像単位の vlm_imgcache/ に保存する。
同じ入力で再実行するときはキャッシュを再利用できる。
ただし、これらはPDF本文や図表から派生したテキストを含むローカル成果物であり、公開配布物には含めない。
公開するのは、再生成用スクリプト、固定URL、SHA-256 manifest、設定、集計結果に限定する。

4. 300問への回答、Judge、集計を通す

LM Studioで qwen/qwen3.6-35b-a3b をロードし、Difyの生成モデルも同じモデルへ切り替える。
次の1コマンドで、qwen35B-VLMあり（r4）の回答収集、Judge、集計、成果物整理までを実行する。

./scripts/run_r1_r4_chatbot.sh r4 all --fresh

Judgeには質問、再現用評価基準CSVの正解、生成回答を渡す。
主要な事実、数値、結論が一致すればO、欠落、矛盾、数値違い、回答放棄があればXとする。
通常は temperature=0、反復ループなどでO/Xを返せない場合だけ temperature=0.3 で1回再判定する。
生成プロンプトとJudgeプロンプトはZenn第4章で公開している。

--fresh は同じrunの既存成果物を消して最初から実行する指定だ。
途中再開では外し、generate、judge、report、finalize を個別に実行できる。

5. 再検証に必要な成果物をローカルrun単位で残す

実行後のローカル results/r4/ には次が残る。

表2: run単位で保存する成果物

成果物	用途
`answers.csv`	300問の生成回答、latency、token usage
`judged.csv`	O/X、判定理由、Judge token usage
`analysis.md`	score、type/domain別集計、モデル・ナレッジ条件
`report.md`	公開用の集計出力
`rag_evaluation_master.csv`	そのrunが参照した正解基準のスナップショット
`vlm_cache/`	PDF単位の抽出結果スナップショット。ローカル保存のみで公開配布しない
`vlm_imgcache/`	画像単位のVLM応答スナップショット。ローカル保存のみで公開配布しない
`dify/*.yml`	Difyアプリ設定のスナップショット。エクスポートDSL版は `0.6.0`

スコアだけを記録しても、入力、検索条件、プロンプト、Judgeが変われば同じ実験にはならない。
runごとにローカル成果物をまとめることで、idx単位の差分確認と再集計ができる。
一方で、vlm_cache/ と vlm_imgcache/ はPDF由来の派生テキストを含むため、GitHubやHugging Faceで配布する公開リポジトリには置かない。

6. 完走確認と処理規模

上記構成の qwen35B-VLMあり（r4）は、300問すべてで回答と判定を完了し、answer_errors=0、**0.853(256/300)**だった。
r4の0.853は本記事の手順が最後まで動作したことを示す確認値であり、他システムとの順位や同等性能を主張するものではない。

O/Xは人手で確定した真値ではなく、ローカルQwen Judgeの判定だ。
qwen35B-VLMありでは回答生成とJudgeに同じモデルを使っているため、自己選好や誤りの相関を排除できない。
評価条件と結果の詳しい読み方はZenn第6章で公開している。VLM有無の比較の詳細は第5章で公開している。

処理規模の参考として、gpt20B-VLMあり（r2）では、取込後の回答収集とJudgeに合計3,831,344トークンを記録した。

表3: gpt20B-VLMあり（r2）の回答収集とJudgeで記録したトークン数

工程	入力トークン(prompt tokens)	出力トークン(completion tokens)	合計
回答収集(300問)	2,805,137	328,383	3,133,520
判定(300問)	212,694	485,130	697,824
合計	3,017,831	813,513	3,831,344

VLM抽出、文書の埋め込み・indexing、検索時のクエリ埋め込みは含まない。
モデルごとにトークナイザが異なるため、他社APIの課金トークンへそのまま換算できる値でもない。

この構成で揃えたかった条件

ローカルで動かすこと自体より、入力から判定までを同じ環境に置き、条件を固定して比較できることに意味がある。

入力は固定URLとSHA-256で固定する。
正解基準は再現用評価基準CSVとして変更履歴を残す。
取込、検索、生成、Judgeを別工程にする。
回答と判定をCSVで保存する。
キャッシュとアプリ設定をローカルrunに同梱する。PDF由来の vlm_cache/ と vlm_imgcache/ は公開配布しない。

これで、モデルや前処理を変えたときに、総合スコアだけでなく300問のどこが改善・悪化したかを確認できる。
VLMの有無を比較した結果の詳細はZenn第5章で公開している。生成モデル差と既存評価との接続の詳細は第6章で公開している。

業務文書のローカル／オンプレRAGの構築、検索設計、評価設計に取り組んでいる。
社内ナレッジ活用やオンプレ生成AIの実装にご関心があれば、お気軽にご相談を。
→ サカタコンサル(SAKATA Consulting) https://www.sakata-consul.com/

関連記事: RAG構成とプロンプト → Zenn第4章 / VLM比較 → Zenn第5章 / 結果と評価条件 → Zenn第6章