ローカルLLMで遊ぼうとしたら混乱したのでそれぞれの関係をざっくり整理する備忘録〜
先日、ローカル環境にLLMを入れて遊んでみようと思ったのですが、
「Ollama入れて……Gemma入れて……エンベディング？ べ、べくとるか？？」
と、見事に脳内渋滞事故を起こしました。
単語だけはなんとなく聞いたことあるけれど、「実際どういう仕組みで、どう関係してるのか？」まではイマイチ分かってなかったな、という反省です。
この記事は、そんな混乱を一旦リセットして整理するために書いた備忘録です。
冒頭でちらっと出てきましたが、当記事では実際に触れた「LLM・Embeddingモデル・ベクトルデータベース・それらを統括する実行ツール」たちがどう役割分担して、「特定のデータを検索して回答するAI（＝RAGっぽいもの）」を動かしているのか、について書いていきます。
今回つくりたかったもの
ローカル版「検索して答えるAI」。
ざっくり目標はこれでした。もう少し具体的に説明するのであれば、
「手元のPCに入れたデータを検索してそれっぽい回答を生成するAIを、ローカルLLMで動かしたい。」といった感じです。
そのために必要なのが、最近よく聞く「RAG」というやつ。
RAGって何やねん
RAG は Retrieval Augmented Generation の略で、直訳すると「検索付きの文章生成」、とのことです。
まず、手元のデータベースからそれっぽい情報を検索してきて、それを材料にしながら答えの文章を生成する。
…まさにやりたかったことと仕組みが合致していますね。
そんなRAGという仕組みですが、下記の役割を持つシステムたちが一丸となってできています。
LLM：文章を生成する「脳みそ」であり主役。手持ちの知識や材料から、その場でレシピを考えて料理を作ってくれる看板シェフ。
Embedding：単語や文章を「座標（数値のリスト）」に変換してくれる人。シェフや在庫システムが扱いやすいラベル付き食材パック（座標のリスト） にしてくれる仕込み専門の職人。会話を出きないが、文章を読むのがうまい。
ベクトルデータベース：Embeddingで数値化されたデータをしまっておく場所。「この座標に近いものを持ってこい」という指示があると、意味が近いデータを一瞬で持ってきてくれる。巨大冷蔵庫＆在庫管理システムみたいな感じ。
Ollama(統括ツール)：どのLLMモデルを使うか決めて、どのEmbeddingモデルに仕事させるか決めて、必要になったらキッチンに呼び出して働かせる、みたいな店長兼キッチンマネージャー。
全体の流れを一回まとめると、ざっくりこんな感じになります。
自前のデータを Embedding でベクトル化して、ベクトルDBに保存する。
ユーザーが質問してきたら、その質問文も Embedding でベクトル化する。
ベクトルDBから「意味が近い文章」をいくつか取ってくる。
その文章と質問をまとめて LLMに渡す。
LLM がそれらを材料にしつつ、最終的な答えを生成する。
その裏側で、モデルを配膳・管理しているのが Ollama、言葉を座標にしているのが Embedding、座標の倉庫が ベクトルデータベース、料理しているのが LLM、という構図です。
次以降の項目ではそれぞれの役割についてもう少し深堀していきます。
LLMって何やねん
LLM（Large Language Model）は、ざっくり言うと「超高性能な予測変換」です。
やっていることは「次に来そうな単語をひたすら予測し続けている」だけだったりします。
じゃあ適当な単語を繋げて奇跡的に意味が通りまくっている文章を作っているのかと言われれば勿論そんなわけはなく。
例えるなら、巨大なパチンコ台。
質問（玉）を入れると、中でめちゃくちゃ細かく調整された釘を通りまくり、計算された結果として、「それっぽい答え」という穴に落ちてくる、というイメージです。
調整って何よって感じですが、LLMはひたすら精度を高めるための予測学習を行った状態で、我々の下で働いてくれているそうです。
各モデルによって鍛錬の方法は異なると思いますが、メジャーどころでいえばGoogleやMetaなどでは巨大な工場（データセンター）で行われる地獄の合宿で、ウェブページや本、コード、Q&Aサイトなどなど、膨大なテキストを相手に、数億回から数兆回レベルの学習を繰り返すと言われているとか、いないとか。
AIなんていかにも最先端みたいな聞こえですが、その実、努力と汗と地と涙の結晶で出来ている以外にも泥臭いやつだったりするんですね。
さて、モデルの話を出しましたが、LLMにも当然”差”があります。
GPT-3.5 より GPT-5.1 の方が賢いよね、Gemini と Claude とか、よく比較されがちだよね、みたいな話です。
具体的には、「どれだけデカい脳みそ（パラメータ数）を持っているか」と「どれだけ多く・良質なデータで学習させたか（経験の量と質）」で決まってくるそうです。
クラウドで動いている GPT や Gemini、Claude たちは、専用データセンターでぶん回されていて、学習データ量もとんでもないし、Web検索などの「追加の手足」も持っている。
一方でローカルLLMは、モデルサイズが控えめ、Webにも勝手にアクセスできない、情報の鮮度にも限界がある、といった制約があります。
人間に例えるなら、「めちゃくちゃ物知りでフットワークも軽い研究者」と「本好きな一般人」くらいの差はどうしてもある、という感じです。
Embeddingモデルって何やねん
Embedding は、文章や単語を、AIが計算しやすい「数値のリスト（ベクトル）」に変換する仕事人です。
我々の言語そのままだと、コンピュータ的には単なる文字列でしかありません。
それを「意味の近さ」で比べられるように、座標空間にマッピングし直す役割を担っています。
Embedding の説明でよく出てくるのが、「1536次元のベクトルで表現されます」みたいなフレーズです。
次元数って何やねん、という話ですが、ざっくり「そのデータを表現するための視点の数（情報の解像度）」です。
RPGのステータスとかで考えてみるとイメージしやすいです。
低次元（3次元）の場合は、攻撃力、防御力、素早さ、のような少ない項目だけでしかキャラを評価できません。
なんとなくの強さは分かるけど、性格までは分かりませんね。
一方、高次元（100次元など）の場合は、攻撃力、防御力に加えて、スキル、弱点、相性の良い属性や地形、性格や傾向、みたいなものまで数値化されます。
高次元になるほど、打ち込まれた言葉を様々な視点で評価して取り扱うことができるという感じです。
Embedingモデルの注意点
このEmbedingモデルでは気を付けなければならないことが1点あって、
それが、Embedding の座標の意味はモデルごとに全然異なる、という点です。
モデルが変わると評価の基準がガラッと変わるみたいなニュアンスです。
Aというモデルで「1536次元のベクトル」にしたときの各次元の意味と、Bというモデルで「同次元数のベクトル」にしたときの意味は、まったく対応していません。
そのため、Embedding を作るモデルを変えたら、すでに作ってあったベクトルデータも全部作り直し（再計算）が必要になります。
ベクトルデータベースってなんやねん
我々が普段使っている日本語をそのままAIに渡しても、「どの文章が意味的に近いか？」を高速で検索するのは意外と難しいです。機械なので、やはり数値に変換するのがベスト。
そこで登場するのが、先述したEmbeddingとベクトルデータベースのコンボです。
ベクトルデータベースは、Embedding モデルで数値化した座標をデータベースに保存します。ユーザーの質問も同じようにベクトル化して、「距離が近いベクトル＝意味が近い文章」として検索する、という流れになります。
いわば、「似た座標をめちゃくちゃ早く探すために特化した、本棚兼検索エンジン」のような存在です。
ふつうのデータベースは、「このIDのレコードちょうだい」「この文字列を含む行ちょうだい」といった検索が得意ですが、一方のベクトルDBは、「このベクトルにいちばん近い文章を、上から10件ください」といった、「近さ」に基づく検索をします。
RAGではこの「意味ベース検索」がものすごく重要で、ここが弱いと、どれだけLLMが優秀でも、出てくる結果がズレてしまいます。
Ollamaって何やねん
Ollamaっていうか…実行ツールっていうか…
これはこれまで説明してきたシステムを動かすための箱のような場所、という理解程度でいいのかな、と思います。
最後に雑記
今回AIを絡めたわりとしょうもないツールを作ろうと画策していたのですが、気づいたら簡易的なRAGのようなものの構築にたどり着いた自分に驚いたんだよね。
話には聞いていたけど実際に手を動かしながら調べながらやるのでは理解の定着度が違いました。
月並みな所感ですが、何でもハンズオンでやってみないと身になりませんね、、
どんなにくだらないことでも思いついたら作ってみようの精神で行きたい所存です。