~/ / AI記事 / ローカルLLM × VPS / Ollamaで埋め込み(embedding)を作る: 検索とRAGの基本
意味で文章を探す検索も、チャットモデルが自分の文書をもとに答えるRAGも、まずembeddingを作るところから始まります。Ollamaなら、チャットモデルを動かしているのと同じサーバーでembeddingも作れます。この記事では、リクエストの書き方、Ollamaライブラリに載っているモデル、結果を左右する設定、ベクトルの比べ方を、Ollamaのドキュメントとライブラリのページに書かれていることだけをもとに説明します。このページには、手順をブラウザで試せるツールが2つあります。
この記事の末尾に、アフィリエイト広告(PR)のリンクがあります。
公開: · 約7分で読めます · Ollamaのドキュメントとライブラリのページで2026-11-04に確認した内容です。モデルやフィールドは変わるため、頼る前に最新のページを確認してください。
Ollamaのembeddingsのページによると、embeddingはテキストを数値のベクトルに変えるもので、ベクトルデータベースに保存したり、コサイン類似度で検索したり、RAGのパイプラインで使ったりできます。ベクトルの長さはモデルによって決まり、このページでは通常384〜1024次元とされています。
検索では、質問を同じモデルでembeddingにして、保存してあるベクトルのうち質問にいちばん近いものを探します。
エンドポイントは POST /api/embed です。リクエストには model と input が必要で、input は1つの文字列でも文字列の配列でも構いません。配列を送ると、レスポンスの embeddings フィールドに、文字列ごとに1つずつ、同じ順番でベクトルが入るので、複数の文章も1回のリクエストで済みます。
ドキュメントにはコマンドラインの例もあります。ollama run embeddinggemma "Hello world" を実行するとベクトルがJSON配列として出力され、echo でテキストをパイプで渡すこともできます。
| フィールド | APIリファレンスの説明 |
|---|---|
| model | 必須。モデル名。 |
| input | 必須。テキスト、またはテキストの配列。 |
| truncate | デフォルトは true で、コンテキストウィンドウを超える入力は切り詰められます。false にするとエラーが返ります。 |
| dimensions | embeddingを生成する次元数。 |
| keep_alive | モデルをロードしたままにしておく時間。 |
| options | コンテキスト長の num_ctx など、実行時のオプション。 |
Ollamaには、OpenAI互換のエンドポイント /v1/embeddings もあります。ドキュメントでは、model、文字列または文字列の配列の input、encoding format、dimensions が対応済み、トークンの配列と user は未対応と書かれています。
Ollamaライブラリには embedding のカテゴリがあります。下の表は、そこに載っているモデルのうち6つについて、各モデルのタグのページに書かれている latest タグのサイズとコンテキストウィンドウをまとめたものです。6つのうち4つは1GB未満です。
| モデル | latestタグのサイズ | コンテキストウィンドウ |
|---|---|---|
| all-minilm | 46MB | 512 |
| nomic-embed-text | 274MB | 2K |
| embeddinggemma | 622MB | 2K |
| mxbai-embed-large | 670MB | 512 |
| bge-m3 | 1.2GB | 8K |
| qwen3-embedding | 4.7GB | 40K |
ほかのタグではサイズが変わります。たとえばライブラリには、qwen3-embedding:0.6b が639MBでコンテキストウィンドウ32K、embeddinggemma:300m-qat-q4_0 が239MBと載っています。これらのモデルの品質は比べていません。ライブラリのページにも順位付けはありません。Ollama 0.40.11 で all-minilm を試したところ、ollama show にはコンテキスト長 512 とパラメーター num_ctx 256 が表示され、長い入力は 256 トークンで切り詰められました。使うモデルを ollama show で確認してください。
コンテキストウィンドウはトークン数で数えます。truncate のデフォルトが true なので、モデルのコンテキストウィンドウより長いテキストは短く切り詰められ、エラーにならずにベクトルが返ってきます。長い文書を1つの入力として送ると、このようにして末尾が失われることがあります。
対策は2つあります。1つは、長い文書を小さなチャンクに分けて、チャンクごとにembeddingを作ることです。これなら、検索で質問に答えている部分だけを返せるようにもなります。もう1つは、truncate を false にして送ることです。長すぎるチャンクがあっても、切り詰められる代わりに Ollama がエラーを返します。
下のチャンク分割ツールは、段落、行、文、スペースの順でテキストを区切り、オーバーラップをつけて、すべてのチャンクを入れた /api/embed のリクエストを1つ作ります。モデルごとにトークナイザーが違うため、トークンではなく文字数で数えます。コンテキストウィンドウより余裕を持たせてください。
試してみる: RAG Text Chunker
長さは文字数です。モデルのコンテキストウィンドウはトークン数で、テキストが何トークンになるかはモデルによって変わるので、余裕を持たせてください。
Ollamaに接続できるマシンで実行します。レスポンスには、チャンクごとに1つずつ、この順番でベクトルが入っています。
curl http://localhost:11434/api/embed -d '{
"model": "embeddinggemma",
"input": [
"Embeddings turn text into numeric vectors. You can store them in a vector database and search them with cosine similarity, or use them in a RAG pipeline.\n\nThe length of each vector depends on the embedding model. Use the same model when you index your documents and when you embed a question.\n\n",
"Ollama'\''s /api/embed endpoint takes a single string or an array of strings. By default, input that is longer than the model'\''s context window is truncated. Set truncate to false to get an error instead.\n\n",
"Split long documents into smaller chunks before you embed them, so that each chunk fits in the context window and a search can return the part that answers the question."
],
"truncate": false
}'チャンクは3個。最長は294文字です。
#0 · 294文字 · 開始位置: オフセット0
Embeddings turn text into numeric vectors. You can store them in a vector database and search them with cosine similarity, or use them in a RAG pipeline. The length of each vector depends on the embedding model. Use the same model when you index your documents and when you embed a question.
#1 · 202文字 · 開始位置: オフセット294
Ollama's /api/embed endpoint takes a single string or an array of strings. By default, input that is longer than the model's context window is truncated. Set truncate to false to get an error instead.
#2 · 169文字 · 開始位置: オフセット496
Split long documents into smaller chunks before you embed them, so that each chunk fits in the context window and a search can return the part that answers the question.
{
"model": "embeddinggemma",
"input": [
"Embeddings turn text into numeric vectors. You can store them in a vector database and search them with cosine similarity, or use them in a RAG pipeline.\n\nThe length of each vector depends on the embedding model. Use the same model when you index your documents and when you embed a question.\n\n",
"Ollama's /api/embed endpoint takes a single string or an array of strings. By default, input that is longer than the model's context window is truncated. Set truncate to false to get an error instead.\n\n",
"Split long documents into smaller chunks before you embed them, so that each chunk fits in the context window and a search can return the part that answers the question."
],
"truncate": false
}/api/embed のリクエストフィールドは、OllamaのAPIリファレンスの記載に従っています(2026-11-04に確認)。 Ollama API: Generate embeddings
すべてブラウザの中で行います。ツールはコマンドを書くだけで、何も送信しません。
embeddingsのページには、インデックス作成にも検索クエリにも同じembeddingモデルを使うように書かれています。ベクトルの長さはモデルによって決まるため、別々のモデルのベクトルは次元数すら一致しないことがあります。
dimensions も同じです。文書をインデックスするときに指定したなら、質問をembeddingにするときも同じ値を指定します。モデルやこの設定を変えたら、保存してある文書のembeddingを作り直してください。
ドキュメントでは、ほとんどのセマンティック検索ではコサイン類似度を勧めており、/api/embed はL2正規化された単位長のベクトルを返すと書かれています。単位長のベクトルでは、コサイン類似度と内積は同じ数値になります。そのため、ベクトルデータベースをどちらに設定しても、結果の順位は同じになります。
何かを作る前に自分のテキストでモデルを確かめるには、質問を先頭にして、質問と数個の文章を1回のリクエストでembeddingにします。そのレスポンスを下に貼ると、質問とのコサイン類似度で文章が順位付けされ、すべてのベクトルが単位長で次元数が同じかどうかも表示されます。
試してみる: Embedding Similarity Calculator
この例では、読みやすいように、4次元で単位長の架空のベクトルを使っています。実際のembeddingは数百から数千次元です。
Ollama /api/embed のレスポンスとして読み込みました: 4次元のベクトルが4個。 すべてのベクトルの長さが1なので、コサイン類似度と内積は等しくなります。
#0 How do I keep a model loaded in Ollama?と比べています。値が大きいほど似ています。
| 順位 | テキスト | コサイン | 内積 | 距離 |
|---|---|---|---|---|
| 1 | #1 keep_alive controls how long the model stays in memory | 0.9962 | 0.9962 | 0.0876 |
| 2 | #2 Protect Ollama with nginx and a password | 0.4037 | 0.4037 | 1.0921 |
| 3 | #3 Tomorrow's weather forecast | 0.0100 | 0.0100 | 1.4071 |
各セルは、行のベクトルと列のベクトルを比べた値です。
| #0 | #1 | #2 | #3 | |
|---|---|---|---|---|
| #0 | 1.000 | 0.996 | 0.404 | 0.010 |
| #1 | 0.996 | 1.000 | 0.475 | -0.005 |
| #2 | 0.404 | 0.475 | 1.000 | -0.377 |
| #3 | 0.010 | -0.005 | -0.377 | 1.000 |
| テキスト | 次元数 | 長さ(L2ノルム) | 単位長 |
|---|---|---|---|
| #0 How do I keep a model loaded in Ollama? | 4 | 1.000000 | はい |
| #1 keep_alive controls how long the model stays in memory | 4 | 1.000000 | はい |
| #2 Protect Ollama with nginx and a password | 4 | 1.000001 | はい |
| #3 Tomorrow's weather forecast | 4 | 1.000000 | はい |
Ollamaのembeddingsのドキュメントとリファレンスをもとに、2026-11-04に確認しました。 Ollama: Embeddings / Ollama API: Generate embeddings
すべてブラウザの中で計算します。どこにも送信しません。
embeddingモデルも、ほかのモデルと同じようにロードされます。Ollama FAQによると、同時にロードできるモデル数(メモリに収まる場合)を決める OLLAMA_MAX_LOADED_MODELS のデフォルトは、GPU数の3倍、CPU推論では3です。そのため、メモリに余裕があれば、チャットモデルとembeddingモデルを同時にロードしたままにできます。
Ollamaのメモリを見張る記事では、ollama ps や keep_alive など、何がメモリに残るかを決める設定を説明しています。
プランは、まずメモリ、次にモデルを置くディスク、そのあとCPUの順に見ます。ここでは、国内の6つのVPSを、AIを動かす目で見て、公式ページに書かれていることと、当サイトの見立てを並べました。
同じ運営者のサイト sabakore.com の「AI・LLM向けVPS診断」では、動かしたいモデルと月額の上限から、メモリに載るプランを料金の安い順に並べられます(GPUは使わず、CPUだけで動かす前提の診断です)。
評価のものさし
公式ページで確認した日:
以下の6社の紹介は、アフィリエイト広告(PR)です。リンク先で申し込みがあると、当サイトの運営者に報酬が支払われます。並びは名前順で、報酬額は並びに関係ありません。評価は、各社の公式ページの記載(確認日は下に表示)だけにもとづく当サイトの見立てで、実際に動かして測ったものではありません。プランの内容や料金は変わるので、申し込む前に公式で確認してください。この記事は、これらのサービスでの動作を保証するものではありません。
メモリ○AIツールの入れやすさ○
公式ページに書かれていること
当サイトの見立て
メモリの選択肢が広く、AIツールを入れる仕組みも公式に用意されているので、「まず Dify や n8n を動かして試す」使い方と、大きめのモデルを載せたい使い方のどちらにも向きます。
申し込む前に
最小プランの書き方がページ内で食い違っています(料金表は512MB、FAQは1GB〜)。申し込む前に、いま選べるプランを公式で確認してください。CPUだけで動かしたときの速さは公式に数字がありません。
メモリ○AIツールの入れやすさ○
公式ページに書かれていること
当サイトの見立て
Dify を動かす用途が公式に想定されています。日額の料金から使えるので、「まず試して合わなければやめる」進め方がしやすく、メモリは32GBまで選べます。
申し込む前に
8GBでの Qwen3 8B は、4,096トークンの見積もりで約6.4 GiBです。コンテキストを長くする、同時に使う人を増やすと足りなくなります。GPUプランはこのページに記載がありません。
メモリ○AIツールの入れやすさ○
公式ページに書かれていること
当サイトの見立て
Dify のアプリイメージと「AIツールのホスティング」という用途が公式に書かれています。小さく始めて、必要になったら大きいプランへ、という使い方ができそうです。
申し込む前に
トップページの料金表は8GBまでで、16GB以上は料金のページに載っています。大きいモデルを載せたいときは、申し込む前に料金のページで確認してください。
メモリ○AIツールの入れやすさ×
公式ページに書かれていること
当サイトの見立て
16GB・10コア・1TBまで選べるので、自分でモデルを入れて動かす前提なら、メモリとディスクには余裕があります。AIツールの導入は自分で組み立てることになります。
申し込む前に
AI向けのテンプレートや手順は公式にありません。このサイトの「VPSにOllamaを入れて動かし続ける」の手順で自分で入れることになります。
メモリ○AIツールの入れやすさ×
公式ページに書かれていること
当サイトの見立て
12GBまで選べるので、8B級のモデルを長めのコンテキストで使いたいときの選択肢になります。AIツールは自分で入れる前提です。
申し込む前に
月額に加えてサーチャージ費がかかるので、実際の支払いは料金表より増えます。申し込む前に、合計の目安を公式で確認してください。
メモリ○AIツールの入れやすさ△
公式ページに書かれていること
当サイトの見立て
公式がAI用途の推奨に挙げる16GB以上のプランがあり、メモリは32GBまで選べます。AI専用のテンプレートは記載がないので、Docker の構築環境を使うか、自分で入れることになります。
申し込む前に
トップページのプランは8GBまでで、16GB以上はプランのページに載っています。GPUプランは記載がありません。
同じ運営者のサイト sabakore.com の関連記事(広告ではありません)