3行でいうと

  • RAGは、文書を小さく切り、質問に近い部分だけを探してAIに渡す方法。
  • 探す役は「埋め込みモデル」で、答えを書く会話用のAIとは別のモデル。
  • LM Studioは文書を読ませる機能を持ち、短い文書は全文、長いとRAGで渡される。
  • うまくいかない例は、スキャンしたPDFの文字化け、長い文書、崩れやすい表。

AIに自分の文書を読ませたい。でも、社内の資料や契約書は、クラウドに出したくない。そんなときに使えるのが、ローカルのAIと「RAG」の組み合わせです。ここでは、RAGの仕組み、LM Studioの文書機能、日本語で手元に置ける埋め込みモデル、うまくいかない例を、読んだ資料の範囲で整理します。この記事は、実機で検証した記録ではありません。

RAGとは何か

RAGは「検索拡張生成」と訳されます。AIが学習していない自分の文書について答えさせるために、先に文書から関連する部分を探し、その部分を質問と一緒にAIへ渡す方法です。

AmazonのAWSの解説では、RAGは「信頼できる知識のもと（外部の文書）を参照させて、AIの出力を良くする方法」とされています。AIそのものを学習し直さずに済む点が、利点として挙げられています。

流れは、次の4つに分けられます。Hugging Faceの解説記事の説明にも沿っています。

  1. 切る。 文書を「チャンク」と呼ばれる小さな断片に切ります。段落ごと、といった単位です。
  2. 数字に変える。 各チャンクを、埋め込みモデルで「ベクトル」（意味を表す数字の列）に変えて保管します。
  3. 探す。 質問も同じようにベクトルにして、意味が近いチャンクを上位から取り出します。
  4. 渡す。 取り出したチャンクを質問に添えて、AIに渡して答えさせます。

図書館にたとえると、AIが本を丸ごと覚えているのではありません。質問のたびに、司書が関係しそうなページだけを開いて、AIの机に置くイメージです。

埋め込みモデルの役割

手順の2と3を受け持つのが、埋め込み（エンベディング）モデルです。文章を読んで、意味が近い文章ほど近くに並ぶ数字の列を作ります。これにより、「解約の方法」と「契約をやめる手順」のように、言葉は違っても意味が近い文章を見つけられます。単なる単語の一致検索とは違う点です。

ここで大事なのは、埋め込みモデルはおしゃべりをするAIとは別のモデルだということです。答えを書くのは会話用のAI、探すのは埋め込みモデルで、役割が分かれています。日本語の文書なら、日本語に強い埋め込みモデルを選ぶと、探す段階の精度が上がる、と考えられます。これは見立てです。

LM Studioで文書を読ませる

LM Studioには、文書を読ませる機能が最初から付いています。公式ドキュメントと0.3.0のお知らせ（2024年8月22日）から、確認できたことは次のとおりです。

つまり、短い文書ではRAGは使われず、全文がそのまま渡されます。RAGが働くのは、長い文書のときだけです。

一方、分からなかった点もあります。この機能が裏でどの埋め込みモデルを使っているかは、読んだ公式の資料に書かれていませんでした。日本語の文書での精度も、確かめられていません。また、手順を順番に書いた説明も、公式のこのページにはありませんでした。画面での操作は、手元のLM Studioで確かめてください。

日本語で、手元に置ける埋め込みモデル

読んだ範囲で、候補を表にしました。

モデル 作った組織 対応言語 入力の長さ ライセンス 手元に置けるか
Ruri v3（30m〜310m） 名古屋大学（cl-nagoya） 日本語 8,192トークン Apache 2.0 置ける
BGE-M3 BAAI 100以上の言語 8,192トークン MIT 置ける。Ollamaで約1.2GB
Sarashina-Embedding-v2-1B SB Intuitions 日本語 8,192トークン 非商用（商用は要連絡） 置ける（Safetensors形式）
nomic-embed-text-v1.5 Nomic AI 英語のみ 8,192トークン Apache 2.0 置ける
Sarashina3のEmbedding SB Intuitions － － － 置けない。APIのみ（二次情報）

Sarashina3のEmbeddingは、ソフトバンクのクラウドからAPIで使う形で、ダウンロードの案内は見当たらない、と解説サイトにあります。ただし、これは二次情報です。公式の文書は確かめられていません。クラウドに文書を送る形になるので、今回の目的には合いません。

では、手元に置けるものはどれか。ここからは候補の紹介です。

Ruri v3。 日本語専用の汎用埋め込みモデルです。モデルカードによると、30mから310mまでの4つの大きさがあり、310mの日本語ベンチマーク（JMTEB）の点数は77.24です。ただし、これは開発側が載せた数字です。使うときは、「検索クエリ: 」「検索文書: 」のように、文頭に決まった言葉を付ける約束があります。付け忘れると、本来の精度が出ないおそれがあります。

LM Studioで使いたい場合は、変換済みのファイル（GGUF形式）が必要です。Ruri v3の310mについては、Targoyleという個人が作ったGGUF版（Q4_K_M、203.87MiB、Apache 2.0）が、Hugging Faceにあります。ページには「LM Studioで直接使える」とあります。ただし、公式の配布ではなく、有志の変換版です。作者を確かめて使ってください。

BGE-M3。 100以上の言語に対応した多言語モデルです。Ollamaには ollama pull bge-m3 で入れられます。日本語も含めて使えるため、多言語の文書が混ざる場合に向きます。日本語だけでの優劣は、今回読んだ資料では比べられていません。

Sarashina-Embedding-v2-1B。 手元に置ける、前の世代の埋め込みモデルです。ただし、ライセンスは非商用です。仕事で使うなら、先に開発元へ連絡が必要になります。モデルカードのJMTEBは76.38（2025年7月28日時点）ですが、Ruriの数字とは測った時期も条件も同じとは限りません。並べて優劣は付けないでください。

nomic-embed-text-v1.5。 英語のみです。日本語の文書には向きません。ほかの解説で名前を見かけても、日本語の用途では外してください。

LM Studioから、自分の埋め込みモデルを使うには

LM Studioは、OpenAI互換の埋め込みAPI（/v1/embeddings）に対応しています。公式の説明では、先に埋め込みモデルを読み込んでおき、プログラムから呼び出す形です。つまり、Ruriなどを使った自作のRAGは組めます。ただ、画面の「文書を読ませる」機能の埋め込みモデルを、利用者が入れ替えられるかどうかは、確認できていません。

うまくいかない典型例

RAGは、設定を間違えなくても、元の文書の状態で結果が決まります。

PDFの文字化け

PDFは、紙の見た目を保つための形式です。文字をきれいに取り出すことは、もともと得意ではありません。ある解説では、原因を次のように分けています。

LM Studioの文書機能が、スキャンPDFをOCRしてくれるかどうかは、公式の資料には書かれていませんでした。読ませる前に、PDFから文字をコピーして貼れるか、確かめておくと安全です。これは見立てです。

長い文書

長い文書は、そのまま渡すと会話の枠を超えます。そのためRAGで切って探すのですが、ここにも落とし穴があります。

表

表は、特に壊れやすい部分です。Oracleの解説は、表を切るときは、見出しや行の名前を、断片ごとに付け直すよう勧めています。そうしないと、数字だけが切り出されて、何の数字か分からなくなるからです。表が中心の文書は、RAGではなく、表のまま計算する別の方法のほうが向く場合もある、とも書かれています。

機密文書を、クラウドに出さずに済む利点

ここが、ローカルでRAGを使う最大の理由です。LM Studioのプライバシーの説明には、モデルを手元で動かすなら、メッセージ、チャット履歴、文書は、パソコンの外に送られないと書かれています。外に出る場面は、モデルの検索・ダウンロード、アプリの更新の確認、有料のクラウド機能を使うときです。

ただし、いくつか注意があります。

ここから先は、僕らの見立て

見立てです。

最初は、LM Studioの標準の機能で、短めの文書を読ませてみるのがよいと見ています。うまくいかないときに、はじめて、Ruri v3やBGE-M3を使った自作のRAGを考えれば遅くありません。

そのとき、まず疑うのは、モデルより文書の状態です。PDFから文字がきちんと取れているか、表が崩れていないか。この2点を先に確かめるだけで、「AIが的外れな答えを返す」問題の多くが、切り分けられるはずです。

日本語の埋め込みモデルは、どれを選ぶかも大切ですが、自分の文書で試して、質問に合う部分が上位に出てくるかを見るのが、いちばん確かです。

出典

更新履歴