DEV Community: Jenny Met

text-embedding-3-large で RAG ナレッジベースを作る：チャンク分割から検索順位付けまで

Jenny Met — Tue, 19 May 2026 10:52:26 +0000

text-embedding-3-large で RAG ナレッジベースを作る：チャンク分割から検索順位付けまで

多くのRAGデモは一見シンプルです。PDFをアップロードして、質問するとAIが答えてくれる。

でも実際に本番運用しようとすると、すぐに課題が出てきます。

ドキュメントが長すぎて、そのままではコンテキストに入りきらない
キーワード検索では意味が近い内容を見つけられない
ユーザーの質問は口語的、ドキュメントは形式的でギャップが大きい
検索結果が的外れだと、モデルが「それっぽく」作り話を始める
データ量が増えると、検索速度やコストが一気に上がる

text-embedding-3-large が解決するのは、まさにこの中核部分、質問とドキュメントを比較可能な意味ベクトルに変換することです。

この記事では抽象的な話は抜きにして、エンジニア視点で実践的なRAG構築フローを解説します。

RAGシステムの基本構成

一般的なRAGナレッジベースは、オフラインとオンラインの2つの処理チェーンに分かれます。

まずはオフラインのインデックス作成フロー：

ドキュメント収集
テキストのクレンジング
チャンク分割（chunking）
embeddingモデルでベクトル化
ベクトルDBに保存

次にオンラインのQAフロー：

ユーザーが質問
質問をembedding化
ベクトルDBで類似チャンクを検索
（任意）rerankで再順位付け
コンテキストを組み立て
チャットモデルで回答生成

この流れの中で、text-embedding-3-large は主に4番目と、オンラインの2番目で使われます。

最終的な回答は生成しませんが、モデルが正しい情報にアクセスできるかどうかを左右します。

ステップ1：ドキュメント準備とチャンク分割

RAGの品質はチャンク設計に大きく左右されます。

チャンクが大きすぎると、ノイズが増えて無関係な情報まで拾ってしまう。

逆に小さすぎると、文脈が切れて必要な情報が足りなくなる。

よく使われる目安は以下の通りです：

ドキュメント種別	推奨チャンクサイズ	オーバーラップ
FAQ・ヘルプセンター	200-500トークン	30-80トークン
技術ドキュメント	400-800トークン	80-120トークン
レポート・論文	600-1000トークン	100-150トークン
コードドキュメント	関数/クラス/見出し単位	ケースバイケース

チャンク分割のサンプルコード：

def chunk_text(text, chunk_size=600, overlap=100):
    words = text.split()
    chunks = []
    start = 0

    while start < len(words):
        end = start + chunk_size
        chunk = " ".join(words[start:end])
        chunks.append(chunk)
        start = end - overlap

    return chunks

本番環境では単純なスペース区切りではなく、見出し・段落・リスト・コードブロックの境界で分割するのが理想です。

ステップ2：text-embedding-3-large でベクトル化

以下はOpenAI互換APIを使った例です。同じSDKで /v1/embeddings エンドポイントを呼び出せます。

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

def get_embedding(text: str):
    text = text.replace("\n", " ")
    response = client.embeddings.create(
        model="text-embedding-3-large",
        input=text,
        encoding_format="float"
    )
    return response.data[0].embedding

ベクトルの次元数を指定したい場合は、dimensions パラメータを追加します：

response = client.embeddings.create(
    model="text-embedding-3-large",
    input=text,
    dimensions=1536,
    encoding_format="float"
)

次元数を下げるとストレージや検索コストは下がりますが、検索精度も落ちる可能性があります。実際のクエリでA/Bテストするのがおすすめです。

ステップ3：ベクトルDBに保存

小規模な検証ならローカルファイルやSQLiteでも動きますが、本番運用では専用のベクトルDBを使いましょう。

代表的な選択肢：

ツール	適した用途
pgvector	既存のPostgreSQLを活用したい場合
Qdrant	独立型ベクトルDB、導入が簡単でフィルタ機能が強力
Milvus	大規模ベクトル検索
Pinecone	フルマネージド型、運用不要
Weaviate	スキーマやハイブリッド検索対応

どのDBでも、各チャンクには最低限以下の情報を持たせるのが推奨です：

{
  "id": "doc_001_chunk_003",
  "text": "chunk content here",
  "embedding": [0.0123, -0.0456],
  "metadata": {
    "source": "billing-guide.md",
    "title": "Billing Guide",
    "section": "Token pricing",
    "updated_at": "2026-05-18"
  }
}

メタデータは非常に重要です。製品・言語・日付・権限などで柔軟に検索結果を絞り込めます。

ステップ4：検索時のセマンティック検索

ユーザーが質問したら、まずembedding化してからベクトルDBで類似チャンクを検索します。

def retrieve(query: str, vector_db, top_k=5):
    query_vector = get_embedding(query)
    results = vector_db.search(
        vector=query_vector,
        top_k=top_k,
        filter={"language": "zh"}
    )
    return results

ベクトルDBを使わずに、numpyでコサイン類似度を計算するサンプルも：

import numpy as np

def cosine_similarity(a, b):
    a = np.array(a)
    b = np.array(b)
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

ただし、数万件を超えるとベクトルDBを使うべきです。

ステップ5：rerankで「的外れ回答」を減らす

Embedding検索は「粗い」検索です。高速ですが、必ずしも最適な順序とは限りません。

Rerankは「精密」な再順位付け。クエリと候補ドキュメントの関連度を再評価します。

おすすめの流れ：

embeddingでtop20を取得
rerankで順位付け
最終的にtop5をチャットモデルに渡す

embeddingのtop5をそのまま使うより、安定した精度が出ます。特に以下のようなケースで有効です：

技術ドキュメントQA
カスタマーサポートナレッジ
法務・財務資料
多言語コンテンツ
ドキュメント数が多く、タイトルが似ている場合

Crazyrouterは /v1/rerank のような再順位付けエンドポイントを提供しているので、RAGの検索パイプラインに組み込むのが簡単です。

ステップ6：検索結果をチャットモデルに渡す

検索したチャンクをプロンプトとして組み立てます：

def build_prompt(question, chunks):
    context = "\n\n".join(
        f"Source: {c['metadata']['source']}\n{c['text']}"
        for c in chunks
    )

    return f"""
あなたは厳密なナレッジベースアシスタントです。
以下の資料だけを根拠に質問に答えてください。
資料に答えがなければ「資料中に見つかりませんでした」と返答してください。

資料：
{context}

質問：{question}
"""

そしてチャットモデルで回答を生成します。

answer = client.chat.completions.create(
    model="gpt-5-mini",
    messages=[{"role": "user", "content": build_prompt(question, chunks)}]
)

print(answer.choices[0].message.content)

ここでembeddingモデルとチャットモデルは役割が分かれています：

text-embedding-3-large：関連資料の検索
gpt-5-mini / Claude / Gemini：資料をもとに回答を生成

text-embedding-3-large の多言語RAGでの強み

多くのチームでは、ドキュメントが単一言語とは限りません。

例えば：

英語APIドキュメント
中国語ヘルプセンター
日本語ユーザーマニュアル
韓国語コミュニティ記事
ベトナム語チュートリアル

多言語RAGの難しさは、ユーザーの質問と言語が異なる資料に答えがある場合です。

text-embedding-3-large は公式にも英語・非英語の両方に強いembeddingモデルとされています。クロスリンガル検索用途では、まず候補としてテストする価値があります。

ただし、公式ベンチマークだけでなく、自分のデータで評価しましょう。

クエリ	正解ドキュメント	言語	召喚できたか
余额为什么扣费快？	billing-token-cost.md	zh	yes/no
how to set API base URL	quickstart.md	en	yes/no
Claude Code 怎么配置？	integrations/claude-code.md	zh	yes/no

最終的にはtop3/top5の召喚率で評価します。

本番運用のためのTips

1. 増分インデックスで効率化

ドキュメント更新時は、変更があったチャンクだけ再ベクトル化しましょう。

各チャンクにハッシュ値を保存しておくと便利です：

import hashlib

def content_hash(text):
    return hashlib.sha256(text.encode("utf-8")).hexdigest()

ハッシュが変わらなければ再処理不要です。

2. バッチembeddingを活用

1件ずつAPIを呼ぶのは非効率です。Embeddings APIは通常バッチ入力に対応しています。

response = client.embeddings.create(
    model="text-embedding-3-large",
    input=[chunk1, chunk2, chunk3],
    encoding_format="float"
)

これで高速化＆リクエスト数のコントロールがしやすくなります。

3. ハイブリッド検索を組み合わせる

ベクトル検索だけだと、エラーコード・注文番号・関数名などの完全一致ワードを見逃すことがあります。

より堅牢な方法は：

BM25やキーワード検索
ベクトル検索
結果をマージ
rerankで最終順位付け

4. 回答に出典を明記

答えだけでなく、参照元のタイトルやリンクも一緒に出すのがベストです。

ユーザーの信頼性が上がり、誤った召喚の検証もしやすくなります。

5. 権限付き検索

企業ナレッジベースでは必須です。

「検索後にフィルタ」ではなく、「ベクトルDB検索時に権限条件を付与」しましょう。

よくあるトラブルと対策

問題	主な原因	解決策
正しいドキュメントが見つからない	チャンクサイズ不適切、クエリが短すぎ	チャンク調整、クエリリライト
回答が誤った資料を参照	top_kが小さい、rerank未導入	top20＋rerank
レイテンシが高い	毎回ドキュメントをembedding化	ドキュメントはオフラインで、クエリのみリアルタイムembedding
コストが急増	重複インデックス、次元数が高すぎ	ハッシュで重複排除、次元数テスト
多言語検索が弱い	モデルが多言語非対応	largeモデルをテスト、多言語評価セット作成

text-embedding-3-large を使わなくてもいいケース

全てのプロジェクトで最高性能embeddingが必要なわけではありません。

例えば：

データ量が少なく、キーワード検索で十分な場合
管理画面など、検索精度にこだわらない用途
予算が限られていて、FAQなど単一言語が中心
まだMVP段階で、実際のクエリデータがない

現実的には、まずsmall/large両方で実際のクエリを使って召喚率を比較し、必要ならアップグレードするのが良いでしょう。

まとめ：RAGの成否は「検索」が半分

どんなに強力なチャットモデルでも、間違ったコンテキストを渡せば、真面目に間違った答えを返します。

text-embedding-3-large の価値は、意味ベースで資料を探せること。キーワードだけに頼る運任せから脱却できます。

本番RAGを作るなら、以下の順序で進めるのがおすすめです：

実際のドキュメントを整理
適切なチャンク分割
text-embedding-3-largeでベクトルインデックス作成
実ユーザーの質問でtop5召喚率を評価
rerankを追加
プロンプトやチャットモデルを最適化

OpenAI互換SDKで Crazyrouter embeddings API を使えば、同じbase_urlでembedding・rerank・チャットモデルをまとめて呼び出せるので、RAGパイプラインの構築がスムーズです。

FAQ

RAGナレッジベースには必ずtext-embedding-3-largeが必要ですか？

必須ではありません。高品質・多言語・本番用途ならおすすめですが、小規模ならコスト重視で他のembeddingモデルから始めてもOKです。

チャンクサイズはどれくらいが最適？

決まった正解はありません。技術ドキュメントなら400-800トークン、FAQならもっと短めから始めて、実際のクエリで召喚率を見て調整しましょう。

text-embedding-3-largeはpgvectorと組み合わせられますか？

はい。生成したベクトルをPostgreSQLのpgvector型に格納し、ベクトル類似度検索が可能です。

embeddingで資料を見つけたのに、モデルが誤答するのはなぜ？

召喚内容にノイズが多い、プロンプトが制限されていない、モデルが出典を無視する、複数資料の統合推論が必要などが考えられます。rerankや出典制約を追加しましょう。

RAGにrerankは必要？

本番運用なら推奨です。embeddingで高速召喚、rerankで精密順位付け。この組み合わせが最も安定します。

text-embedding-3-large は使うべき？small とのコスト・品質・選び方

Jenny Met — Tue, 19 May 2026 09:51:10 +0000

text-embedding-3-large は使うべき？small とのコスト・品質・選び方

RAG やセマンティック検索を導入する際、多くの開発者が悩むのがこの問題です。

結局、text-embedding-3-large を使うべきか、それとも安価な text-embedding-3-small で十分なのか？

答えは「large が常に最良」でも「small で十分」でもありません。

より正確に言うと、検索品質がビジネス成果に直結するなら large をテストする価値あり。プロジェクト初期やデータ量が膨大な場合は small から始めるのが堅実です。

この記事では、実際のプロジェクト視点で embedding モデル選定のポイントを解説します。

まず結論：どう選ぶ？

この表を参考にしてください。

シーン	推奨スタート	理由
企業ナレッジベースQA	text-embedding-3-large	検索品質が最重要
多言語RAG	text-embedding-3-large	非英語・クロス言語検索の精度向上
カスタマーサポートBot	large/smallでA/Bテスト	誤回答のコスト次第
社内ツール検索	text-embedding-3-small	コスト優先・許容度高め
MVP / デモ	text-embedding-3-small	まずは動作確認
大規模ドキュメントインデックス	small または large の次元削減	ストレージ・検索コスト抑制
コード/技術ドキュメント検索	large + rerank	セマンティック＆精度両立

一言でまとめるなら、

まず small でベースラインを作り、large で実際のクエリを評価してみましょう。

text-embedding-3-large の強み

text-embedding-3-large は高性能な embedding モデルです。

OpenAI公式ドキュメントによると、デフォルトで3072次元ベクトルを出力し、最大入力は8192トークン。英語・非英語問わず高精度な埋め込みを狙ったモデルです。

主な強みは以下の通りです。

より強力なセマンティック表現
複雑なクエリへの対応力
多言語・クロス言語検索に強い
長文ドキュメントにも対応しやすい
本番RAG用途の有力候補

ただし、コスト面では

1トークンあたりのAPIコストが高い
デフォルトのベクトル次元数が大きい
ベクトルDBのストレージコスト増
検索時のメモリ・インデックス負荷増

といったデメリットもあります。

つまり、large を選ぶなら「品質向上が追加コストを上回る」ことが前提です。

text-embedding-3-small が向いているケース

text-embedding-3-small はコスト効率重視のモデルです。

向いている用途は

FAQ検索
小規模ナレッジベース
初期MVP
社内検索ツール
単一言語のコンテンツ
検索ミスにある程度寛容な場面

多くのプロジェクトは、最初から large を使う必要はありません。

特に、実際のユーザーの質問や評価データ、フィードバックがまだ無い段階では、「大きい embedding の方が安心」と感じても、その効果を証明できません。

コストはAPI料金だけじゃない

Embedding のコストは API の利用料だけではありません。

他にも以下のコストが発生します。

コスト項目	影響要因
API利用料	入力トークン数・再インデックス頻度
ベクトルDBストレージ	ドキュメント数・チャンク数・ベクトル次元
検索レイテンシ	インデックス規模・次元数・top_k
メモリ/ディスク	ベクトル数・精度
運用コスト	インデックス再構築・バージョン移行・評価

例えば、

100万チャンク、1ベクトル3072次元、float32で保存した場合、ベクトルデータだけで

1,000,000 × 3072 × 4 bytes ≈ 12.3 GB

となります。

1536次元にすれば約半分です。

これにインデックス構造やメタデータ、DBのオーバーヘッドも加わります。

大規模運用では dimensions パラメータとベクトルDBコストに要注意です。

dimensions パラメータの使い方

OpenAI 第三世代 embedding モデルは dimensions で出力ベクトルの次元数を指定できます。

例：

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

response = client.embeddings.create(
    model="text-embedding-3-large",
    input="How to reduce AI API cost with model routing?",
    dimensions=1536,
    encoding_format="float"
)

vector = response.data[0].embedding
print(len(vector))

これは本番環境で非常に役立ちます。

例えば

large 3072次元
large 1536次元
large 1024次元
small デフォルト次元

などでテストし、top 5 のリコール率・レイテンシ・コストを比較しましょう。

MTEBスコアだけで選ばない

公開ベンチマークは参考になりますが、それが最終判断基準ではありません。

実際のビジネスデータはベンチマークと大きく異なることが多いです。

ユーザーの質問が短い
ドキュメントが日英混在
製品名やエラーコードが多い
表やパラメータ説明が多い
口語表現が多用される

自分のデータで小さな評価セットを作るのがベストです。

シンプルなフォーマット例：

クエリ	正解ドキュメント	種別
残高の確認方法は？	billing.md	FAQ
base_url には何を入れる？	quickstart.md	technical
Claude Code の設定方法は？	claude-code.md	integration
API呼び出しで401エラーが出た場合？	auth-errors.md	troubleshooting

各モデルで top 3 / top 5 に正解が入るか確認しましょう。

実践的なA/Bテスト手順

おすすめの評価フローは以下です。

1. 50〜200件の実クエリを用意

自作ではなく、できるだけ

サイト内検索ログ
サポート問い合わせ
ユーザーコミュニティの質問
チケットタイトル
ドキュメントコメント

などから収集しましょう。

2. 正解ドキュメントをアノテーション

各クエリに対し、1〜3件の正解チャンクやドキュメントを紐付けます。

3. 複数のインデックスを作成

例：

index_small_default
index_large_3072
index_large_1536

4. リコール評価を実施

主な指標：

指標	意味
Recall@3	上位3件に正解が含まれるか
Recall@5	上位5件に正解が含まれるか
MRR	正解が上位ほど高評価
latency	クエリ応答速度
cost	インデックス・検索コスト

5. large へのアップグレード判断

large で1%しか改善しないのにコストが大幅増なら、無理に使う必要はありません。

逆に、Recall@5 が78%→90%に上がり、ビジネス的に精度が重要なら、large を選ぶ価値は十分あります。

RAG の品質問題＝embedding モデルのせいとは限らない

large に変えても改善しない場合、他に原因があることが多いです。

問題	症状	優先対応
chunk 切り方が悪い	コンテキストが不完全	再チャンク
metadata 不足	言語・権限・製品で絞れない	metadata追加
クエリが短すぎる	「課金問題」などで不安定	クエリリライト
ドキュメントが古い	古い情報がヒットする	更新日・バージョンで絞る
rerank 未導入	上位が似てるだけで不正確	rerank追加
プロンプトが緩い	モデルが常識で回答	情報ソース限定プロンプト

まずは RAG パイプライン全体の品質を見直しましょう。

OpenAI互換APIでembeddingモデルを切り替える

OpenAI SDK を使っている場合、モデル切り替えは簡単です。

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

# コスト重視
small = client.embeddings.create(
    model="text-embedding-3-small",
    input="semantic search for AI documentation"
)

# 品質重視
large = client.embeddings.create(
    model="text-embedding-3-large",
    input="semantic search for AI documentation"
)

Crazyrouter のような OpenAI 互換ゲートウェイを使えば、SDKはそのままでモデル名と base URL を変えるだけでOKです。

まずは Crazyrouter Playground で動作確認し、同じパラメータをサーバー側に適用しましょう。

推奨プロジェクトロードマップ

フェーズ1：MVP

text-embedding-3-small を利用
ローカル or pgvector で保存
top 5 検索
rerank など複雑な処理は省略
まずは動作することが目標

フェーズ2：実データ評価

ユーザークエリを収集
正解ドキュメントをアノテーション
small vs large で比較
chunk戦略を調整
ボトルネック特定が目標

フェーズ3：本番最適化

large または large の次元削減版を利用
ハイブリッド検索導入
rerank追加
権限フィルタ追加
情報ソースの引用表示
安定性・説明性・コスト制御が目標

結論：large はデフォルトではないが、真剣にテストする価値あり

text-embedding-3-large の強みは高いセマンティック表現力。高品質RAG、多言語ナレッジベース、複雑な検索には特に有効です。

ただし、最強モデルを盲目的に選ぶのは避けましょう。

おすすめの進め方は

small でコスト・品質のベースラインを作る
実クエリで large の効果を評価
dimensions でベクトル次元を調整
rerank やハイブリッド検索も活用（モデル変更だけに頼らない）
ビジネス上の誤答コストでアップグレード判断

RAG の結果がユーザー体験や売上に直結するなら、text-embedding-3-large は十分検討に値します。

一方、社内ツールや初期検証なら small から始めるのが現実的です。

FAQ

text-embedding-3-large は text-embedding-3-small より必ず優れている？

基本的に性能は上ですが、すべてのプロジェクトでコストに見合うとは限りません。実クエリでのリコール向上がコストを上回るかで判断しましょう。

dimensions を下げると品質は落ちる？

影響する可能性があります。次元削減でストレージ・検索コストは下がりますが、リコール精度が下がる場合も。自分の評価セットで検証をおすすめします。

RAG プロジェクトはモデル最適化とチャンク戦略、どちらを優先すべき？

まずはチャンク戦略と評価セットの整備を。チャンクが悪いと、どんなに強い embedding でも効果が限定的です。

多言語ナレッジベースは text-embedding-3-large が向いている？

優先的にテストする価値があります。公式にも large は英語・非英語両対応とされ、多言語検索ではセマンティック表現力が重要です。

Crazyrouter で text-embedding-3-large を使える？

OpenAI互換の /v1/embeddings エンドポイント経由で利用可能です。コードの base URL を https://crazyrouter.com/v1 に設定してください。

text-embedding-3-large или small: стоимость, качество поиска и выбор для RAG

Jenny Met — Tue, 19 May 2026 09:49:23 +0000

text-embedding-3-large или small: стоимость, качество поиска и выбор для RAG

При построении RAG или семантического поиска многие сталкиваются с одним и тем же вопросом:

Какой embedding-модель выбрать: text-embedding-3-large или более дешевую text-embedding-3-small?

Ответ не в том, что “large всегда лучше”, и не в том, что “small достаточно”.

Правильнее сказать: если качество поиска напрямую влияет на бизнес-результаты, large стоит протестировать; если проект на ранней стадии или данных очень много, small обычно надежнее для старта.

В этой статье разберём, на что реально смотреть при выборе embedding-модели для реальных задач.

Сразу к сути: как выбрать?

Можно ориентироваться на эту таблицу:

Сценарий	Рекомендуемый старт	Почему
Корпоративный FAQ/база знаний	text-embedding-3-large	Качество поиска важнее всего
Многоязычный RAG	text-embedding-3-large	Стоит протестировать для неанглийских и кросс-языковых запросов
Чат-бот поддержки	large или small через A/B тест	Оценить цену ошибки
Внутренний поиск по инструментам	text-embedding-3-small	Приоритет — стоимость, допустимы ошибки
MVP / демо	text-embedding-3-small	Главное — быстро собрать рабочий прототип
Индексация огромных массивов	small или large с понижением размерности	Контроль затрат на хранение и поиск
Поиск по коду/техдокам	large + rerank	Важно и семантическое, и точное совпадение

Если запомнить только одну фразу:

Сначала small для базовой оценки, потом large — для проверки улучшений на реальных запросах.

Чем силён text-embedding-3-large?

text-embedding-3-large — это embedding-модель с более высокими возможностями.

По документации OpenAI, она по умолчанию выдаёт вектор размером 3072, принимает до 8192 токенов, и позиционируется как мощное решение для английских и неанглийских задач.

Её сильные стороны:

Более глубокое семантическое понимание
Лучше справляется со сложными запросами
Эффективнее для многоязычного и кросс-языкового поиска
Дружелюбнее к длинным документам
Хороший кандидат для продакшн-RAG

Но есть и минусы:

Дороже за токен
Вектор больше по размеру
Дороже хранить векторную базу
Больше нагрузка на память и индексацию при поиске

Поэтому large стоит выбирать, только если прирост качества поиска оправдывает дополнительные расходы.

Когда подходит text-embedding-3-small?

text-embedding-3-small — это про эффективность и экономию.

Подходит для:

Поиска по FAQ
Небольших баз знаний
MVP и прототипов
Внутренних инструментов
Одноязычных коллекций
Сценариев, где ошибки поиска не критичны

Во многих случаях нет смысла сразу брать large.

Особенно если у вас ещё нет реальных пользовательских запросов, тестовой выборки и обратной связи — использование большой модели может казаться “надёжнее”, но вы не сможете доказать, что она реально лучше.

Стоимость — это не только цена API

Затраты на embedding — это не только вызовы модели.

В расчёт стоит брать:

Статья затрат	От чего зависит
Стоимость API	Количество токенов, частота переиндексации
Хранение векторов	Количество документов, чанков, размерность вектора
Задержка поиска	Размер индекса, размерность, top_k
Память/диск	Количество и точность векторов
Поддержка	Переиндексация, миграция версий, тестирование

Простой пример:

Если у вас 1 миллион чанков, каждый вектор — 3072 float32, то только на векторах:

1,000,000 × 3072 × 4 bytes ≈ 12.3 GB

Если уменьшить размерность до 1536 — будет примерно вдвое меньше.

И это без учёта индекса, метаданных и накладных расходов БД.

Поэтому для крупных проектов важно следить за параметром dimensions и стоимостью векторной базы.

Как использовать параметр dimensions?

В embedding-моделях третьего поколения OpenAI можно управлять размером выходного вектора через параметр dimensions.

Пример:

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

response = client.embeddings.create(
    model="text-embedding-3-large",
    input="How to reduce AI API cost with model routing?",
    dimensions=1536,
    encoding_format="float"
)

vector = response.data[0].embedding
print(len(vector))

Это очень полезно в продакшне.

Можно сравнить:

large 3072
large 1536
large 1024
small (по умолчанию)

А потом посмотреть на Recall@5, задержку и стоимость.

Не ориентируйтесь только на MTEB

Публичные бенчмарки полезны, но не заменяют реальные данные.

Ваши задачи могут отличаться от тестовых наборов:

Короткие пользовательские запросы
Документы на смешанном русском и английском
Много названий продуктов и кодов ошибок
Таблицы и параметры в тексте
Пользователи часто пишут разговорно

Лучше собрать свою небольшую тестовую выборку.

Простейший формат:

Запрос	Ожидаемый документ	Тип
Как посмотреть баланс?	billing.md	FAQ
Что указывать в base_url?	quickstart.md	technical
Как настроить Claude Code?	claude-code.md	integration
Что делать при ошибке 401?	auth-errors.md	troubleshooting

Прогоните каждый вариант модели и посмотрите, попадает ли нужный документ в топ-3/топ-5.

Как провести A/B тестирование моделей

Рекомендую такой подход:

1. Соберите 50-200 реальных запросов

Не придумывайте сами. Лучше взять:

Логи поиска на сайте
Вопросы в поддержку
Вопросы из чатов/групп
Заголовки тикетов
Комментарии к документации

2. Проставьте правильные ответы

Для каждого запроса отметьте 1-3 релевантных чанка или документа.

3. Постройте несколько индексов

Например:

index_small_default
index_large_3072
index_large_1536

4. Прогоните тесты на поиск

Ключевые метрики:

Метрика	Описание
Recall@3	Входит ли правильный документ в топ-3
Recall@5	Входит ли правильный документ в топ-5
MRR	Чем выше позиция правильного документа, тем лучше
latency	Время ответа на запрос
cost	Стоимость индекса и поиска

5. Решите, стоит ли переходить на large

Если прирост Recall@5 всего 1%, а расходы сильно выше — возможно, не стоит.

Если же Recall@5 вырос с 78% до 90%, а бизнесу критична точность — переход оправдан.

Плохой RAG — не всегда вина embedding-модели

Часто даже переход на large не спасает, если проблемы в другом:

Проблема	Проявление	Что делать
Плохо нарезаны чанки	Контекст найденного ответа неполный	Перерезать чанки
Нет метаданных	Нельзя фильтровать по языку/правам/продукту	Добавить метаданные
Слишком короткий запрос	“Проблема с оплатой” ищет плохо	Переписывать запросы
Устаревшие документы	Находятся старые ответы	Фильтровать по дате/версии
Нет rerank	Топ-результаты похожи, но не точные	Добавить rerank
Слабый prompt	Модель отвечает “из головы”	Жёстко ограничить ответы только по базе

Перед выбором модели убедитесь, что ваша RAG-пайплайн не слишком “сырая”.

Как переключаться между embedding-моделями через OpenAI-совместимый API

Если вы используете OpenAI SDK, сменить модель очень просто.

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

# Для экономии
small = client.embeddings.create(
    model="text-embedding-3-small",
    input="semantic search for AI documentation"
)

# Для качества
large = client.embeddings.create(
    model="text-embedding-3-large",
    input="semantic search for AI documentation"
)

Если вы используете OpenAI-совместимый шлюз вроде Crazyrouter, обычно менять нужно только имя модели и base URL.

Можно сначала проверить вызовы в Crazyrouter Playground, а затем перенести параметры на сервер.

Вывод: large — не всегда ответ, но тестировать стоит

text-embedding-3-large даёт более сильное семантическое представление, особенно полезен для сложных RAG, многоязычных баз и продвинутого поиска.

Но не стоит слепо брать самую мощную модель.

Лучше действовать так:

Сначала small — для оценки затрат и базового качества
Потом large — для проверки реального прироста на ваших данных
Управляйте размерностью через dimensions
Добавляйте rerank и гибридный поиск, а не только меняйте модель
Оценивайте, насколько критичны ошибки для бизнеса

Если RAG влияет на решения пользователей, поддержку или оплату — скорее всего, large оправдан.

Если это внутренний инструмент или ранний прототип — small практичнее.

FAQ

text-embedding-3-large всегда лучше, чем text-embedding-3-small?

Обычно да, но не всегда оправдано. Смотрите, насколько реально растёт качество поиска и окупает ли это затраты.

Снижение dimensions ухудшает качество?

Может ухудшить. Меньше размерность — дешевле хранить и искать, но возможна потеря качества. Проверьте на своей тестовой выборке.

В RAG-проекте сначала оптимизировать модель или нарезку чанков?

Сначала — нарезку и тестовую выборку. Если чанки плохие, даже сильная embedding-модель мало поможет.

Для многоязычных баз лучше large?

Стоит протестировать в первую очередь. Large официально позиционируется для английских и неанглийских задач, а многоязычный поиск особенно зависит от семантики.

Можно ли вызывать text-embedding-3-large через Crazyrouter?

Да, через OpenAI-совместимый эндпоинт /v1/embeddings. Просто укажите https://crazyrouter.com/v1 как base URL в коде.

text-embedding-3-large — для чего нужен embeddings-модель и как он работает в RAG

Jenny Met — Tue, 19 May 2026 09:49:22 +0000

text-embedding-3-large — для чего нужен embeddings-модель и как он работает в RAG

Когда вы используете GPT, Claude, Gemini, чаще всего вы “генерируете ответы”. Но такие модели, как text-embedding-3-large, не предназначены для чата и не пишут тексты напрямую.

Их основная задача — преобразовывать текст в числовой вектор.

Звучит абстрактно, но именно это лежит в основе RAG-решений, семантического поиска, рекомендаций похожих статей, чат-ботов поддержки, поиска по документам и других подобных задач.

Если вы хотите, чтобы ИИ находил ответы в ваших документах, а не просто “угадывал” из своей памяти, без embeddings не обойтись.

Для чего нужен text-embedding-3-large?

text-embedding-3-large — это мощная модель для получения текстовых векторов от OpenAI. Она читает текст и возвращает вектор большой размерности.

Вектор — это “семантические координаты” текста.

Например, возьмём такие фразы:

“Как снизить стоимость AI API?”
“Как сэкономить на GPT?”
“Что делать, если вызовы AI моделей слишком дорогие?”

Ключевые слова разные, но смысл близок. Embedding-модель спроецирует их в близкие точки пространства.

Это позволяет делать то, что не под силу обычному поиску по ключевым словам: искать по смыслу.

Типичные применения:

Сценарий	Роль embeddings
Семантический поиск	Преобразует вопросы и документы в векторы, ищет наиболее похожие
RAG (знаниевая база)	Сначала ищет релевантные документы, затем передаёт их генеративной модели
Рекомендации	Рекомендует контент по смысловой близости описаний
Кластеризация	Автоматически группирует похожие документы
Классификация	Определяет принадлежность текста к категории по схожести
Детектирование аномалий	Находит “выбивающиеся” по смыслу данные

В официальной документации OpenAI embeddings используются для поиска, кластеризации, рекомендаций, обнаружения аномалий, оценки разнообразия и классификации.

Почему RAG особенно нуждается в text-embedding-3-large?

RAG (Retrieval-Augmented Generation) — это “генерация с усилением за счёт поиска”.

Типовой процесс:

Разбиваем документы на небольшие фрагменты
Преобразуем каждый фрагмент в вектор через embedding-модель
Сохраняем в векторную базу данных
При вопросе пользователя тоже получаем вектор
Находим наиболее релевантные фрагменты
Передаём их генеративной модели для ответа

Без embeddings система может только искать по ключевым словам.

Например, пользователь спрашивает:

“Почему баланс быстро уменьшается?”

А в документации написано:

“Модели с большим контекстом используют больше tokens, стоимость считается по количеству входных и выходных tokens.”

Ключевые слова не совпадают, но смысл связан. Embedding решает именно такие задачи.

Чем отличается text-embedding-3-large от чат-моделей?

Многие разработчики поначалу думают, что embedding — это тоже “модель для вопросов-ответов”. Это не так.

Возможности	Чат-модель	Embedding-модель
Входные данные	Вопросы, контекст	Текстовые фрагменты
Выходные данные	Ответ на естественном языке	Числовой вектор
Основные задачи	Генерация, суммирование, рассуждение, диалог	Поиск, схожесть, кластеризация, классификация
Отвечает ли напрямую на вопросы	Да	Нет
Роль в RAG	Генерирует финальный ответ	Находит релевантные данные

Можно представить их так:

embedding-модель — библиотекарь, ищет нужные материалы
чат-модель — автор, формулирует ответ

В полноценной системе поиска по знаниям нужны обе.

Ключевые параметры text-embedding-3-large

Согласно документации OpenAI, text-embedding-3-large по умолчанию выдаёт вектор размером 3072, максимальный размер входа — 8192 токенов.

Поддерживается параметр dimensions — можно уменьшить размерность вектора, сохранив основную смысловую нагрузку.

Это важно, потому что размерность влияет на:

стоимость хранения в векторной базе
скорость поиска
размер индекса
использование памяти

Для небольших FAQ или базы поддержки не всегда нужен полный вектор на 3072 измерения. Можно попробовать 1024 или 1536 и сравнить качество поиска.

Как вызвать text-embedding-3-large через OpenAI-совместимый API?

Пример на Python. В API-адресе не добавляйте UTM-параметры.

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

response = client.embeddings.create(
    model="text-embedding-3-large",
    input="AI API gateway helps developers connect to many models with one key.",
    encoding_format="float"
)

vector = response.data[0].embedding
print(len(vector))
print(vector[:5])

Если вы уже используете OpenAI SDK, просто поменяйте base_url на адрес совместимого шлюза.

Подробнее о подключении через OpenAI-совместимый API читайте в документации Crazyrouter, а сравнить стоимость разных моделей можно на странице цен.

Минимальный пример семантического поиска

Ниже — простейшая реализация cosine similarity для embeddings. В продакшене используйте векторные базы данных: Qdrant, Milvus, Pinecone, pgvector и др.

from openai import OpenAI
import numpy as np

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

def embed(text: str):
    res = client.embeddings.create(
        model="text-embedding-3-large",
        input=text,
        encoding_format="float"
    )
    return np.array(res.data[0].embedding)

def cosine(a, b):
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

docs = [
    "AI API costs are calculated by input and output tokens.",
    "RAG systems retrieve relevant documents before generating answers.",
    "Vector databases store embeddings for semantic search."
]

query = "How does retrieval augmented generation find context?"

query_vec = embed(query)
doc_vecs = [embed(doc) for doc in docs]

scores = [(doc, cosine(query_vec, vec)) for doc, vec in zip(docs, doc_vecs)]
scores.sort(key=lambda x: x[1], reverse=True)

for doc, score in scores:
    print(round(score, 4), doc)

Этот пример прост, но отражает суть семантического поиска: текст → вектор → сортировка по схожести.

Когда стоит использовать text-embedding-3-large?

Рекомендации по выбору:

Задача	Совет
Качественный RAG, мультиязычный поиск, большие базы	Сначала пробуйте text-embedding-3-large
FAQ, небольшой поиск, чувствительность к цене	Можно начать с text-embedding-3-small
Мультиязычный поиск	large предпочтительнее
Только фильтрация по ключевым словам	Embedding не обязателен
Очень большой объём данных, ограниченный бюджет	Оцените уменьшение размерности и многоуровневый поиск

Если качество поиска критично для пользователей — text-embedding-3-large стоит тестировать в первую очередь.

Для внутренних инструментов или MVP можно начать с более дешёвых моделей.

Лучшие практики для RAG-проектов

1. Не делайте слишком крупные чанки

Не загружайте целиком большие документы. Лучше разбивать по смысловым абзацам.

Рекомендации:

300–800 токенов на один чанк
50–100 токенов overlap между чанками
Метаданные (заголовок, путь, дата) хранить отдельно

2. Предобработка запросов

Вопросы пользователей часто короткие и разговорные. Можно сначала переформулировать их через чат-модель, а потом делать embedding.

3. Не ограничивайтесь только top 1

Обычно в RAG берут top 3–10 фрагментов, затем передают их генеративной модели.

4. Используйте rerank для точности

Embedding — это грубый отбор, rerank — точная сортировка. Для поддержки, юридических, финансовых и технических документов rerank заметно снижает число нерелевантных ответов.

5. Анализируйте реальные запросы

Не ограничивайтесь тестовыми данными. Анонимизируйте и анализируйте настоящие вопросы пользователей — только так можно оценить качество поиска.

Частые заблуждения

Миф 1: чем выше размерность embedding, тем лучше

Не всегда. Большая размерность — выше выразительность, но и выше затраты на хранение и вычисления. Важно балансировать качество, задержку и стоимость.

Миф 2: если есть embedding, RAG не будет “галлюцинировать”

Это не так. Embedding только ищет материалы. Надёжность ответа зависит от prompt'а, качества контекста, возможностей модели и ограничений на цитирование.

Миф 3: любой документ можно просто векторизовать

Таблицы, код, логи, сканы PDF требуют особой обработки. Для таблиц лучше сохранять структуру.

Вывод: text-embedding-3-large — “поисковый фундамент” AI-приложений

text-embedding-3-large — это не чат-модель, а инструмент для оценки смысловой близости текстов.

Он идеально подходит для:

RAG-знаниевых баз
семантического поиска
мультиязычного поиска
рекомендательных систем
кластеризации документов
классификации текстов

Если вы делаете AI-поддержку, корпоративную базу знаний, поиск по документам, коду или рекомендации — embedding-модель будет основой системы.

Подключиться к embeddings API можно через OpenAI-совместимый интерфейс. Если вы уже используете OpenAI SDK, переход прост: поменяйте base_url, используйте новый API-ключ — и всё работает по-прежнему.

FAQ

Может ли text-embedding-3-large напрямую отвечать на вопросы?

Нет. Она возвращает только вектор, а не текстовый ответ. Для генерации ответа нужен GPT, Claude, Gemini или другая чат-модель.

Подходит ли text-embedding-3-large для RAG?

Да. Обычно её используют на этапе поиска: вопрос и документы преобразуются в векторы, затем ищутся наиболее релевантные.

Какая размерность по умолчанию у text-embedding-3-large?

В официальной документации — 3072. Можно уменьшить через параметр dimensions.

Как выбрать между text-embedding-3-large и text-embedding-3-small?

Если важны качество поиска, мультиязычность или продакшн-RAG — пробуйте large. Если важна цена или объём данных огромный — small подойдёт для базовой версии.

Обязательна ли векторная база данных?

Для небольших демо можно обойтись массивами и cosine similarity. В продакшене лучше использовать специализированные базы: pgvector, Qdrant, Milvus, Pinecone.

Как построить RAG-базу знаний на text-embedding-3-large: chunking, embeddings и rerank

Jenny Met — Tue, 19 May 2026 09:48:53 +0000

Как построить RAG-базу знаний на text-embedding-3-large: chunking, embeddings и rerank

Многие демо RAG выглядят просто: загрузил PDF, задал вопрос — AI ответил.

Но когда доходит до реального продакшна, сразу появляются проблемы:

Документ слишком длинный — не помещается в контекст
Поиск по ключевым словам не находит похожие по смыслу фрагменты
Пользователь спрашивает разговорно, а документация написана официально
Найденные куски не по теме — модель начинает “галлюцинировать”
Чем больше данных, тем выше задержки и стоимость поиска

text-embedding-3-large решает одну из ключевых задач: преобразует вопросы и документы в сравнимые семантические векторы.

В этой статье — никакой воды, только практический разбор рабочего RAG-процесса с инженерной точки зрения.

Базовая архитектура RAG-системы

Типовая база знаний на RAG делится на два основных контура.

Первый — оффлайн-индексация:

Сбор документов
Очистка текста
Разделение на чанки (chunking)
Генерация векторов через embedding-модель
Сохранение в векторную базу данных

Второй — онлайн-ответы на вопросы:

Пользователь задаёт вопрос
Преобразование вопроса в embedding
Поиск похожих чанков в векторной базе
(Опционально) rerank — уточняющая сортировка
Сборка контекста
Генерация ответа через чат-модель

text-embedding-3-large используется на шаге 4 (оффлайн) и шаге 2 (онлайн).

Он не отвечает на вопросы напрямую, но определяет, получит ли модель нужную информацию.

Шаг 1: Подготовка документов и разбиение на чанки

Качество RAG во многом зависит от того, как вы режете текст на чанки.

Слишком крупные чанки — много “шума”, модель видит лишнее.

Слишком мелкие — не хватает контекста, информации мало.

Рекомендации для старта:

Тип документа	Рекомендуемый размер чанка	overlap
FAQ / Справка	200-500 токенов	30-80
Техническая дока	400-800 токенов	80-120
Длинные отчёты	600-1000 токенов	100-150
Документация кода	По функции/классу/заголовку	По ситуации

Пример кода для разбиения:

def chunk_text(text, chunk_size=600, overlap=100):
    words = text.split()
    chunks = []
    start = 0

    while start < len(words):
        end = start + chunk_size
        chunk = " ".join(words[start:end])
        chunks.append(chunk)
        start = end - overlap

    return chunks

В продакшне не режьте только по пробелам. Лучше разбивать по заголовкам, абзацам, спискам, границам кода.

Шаг 2: Генерация векторов через text-embedding-3-large

Пример на OpenAI-совместимом API. Можно использовать тот же SDK для вызова /v1/embeddings.

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

def get_embedding(text: str):
    text = text.replace("\n", " ")
    response = client.embeddings.create(
        model="text-embedding-3-large",
        input=text,
        encoding_format="float"
    )
    return response.data[0].embedding

Если нужно контролировать размерность вектора, добавьте параметр dimensions:

response = client.embeddings.create(
    model="text-embedding-3-large",
    input=text,
    dimensions=1536,
    encoding_format="float"
)

Чем меньше размерность, тем дешевле хранение и поиск, но качество может упасть. Тестируйте на реальных вопросах.

Шаг 3: Сохранение в векторную базу данных

Для прототипа можно использовать файлы или SQLite, но для продакшна лучше выбрать специализированную векторную БД.

Инструмент	Когда использовать
pgvector	Уже используете PostgreSQL, не хотите новых сервисов
Qdrant	Отдельная векторная БД, простая установка, мощная фильтрация
Milvus	Масштабируемый поиск по большим данным
Pinecone	Облачный сервис, не требует поддержки
Weaviate	Есть схема и гибридный поиск

Шаг 4: Семантический поиск при запросе

Когда пользователь задаёт вопрос, сначала превращаем его в вектор, затем ищем похожие чанки в базе.

def retrieve(query: str, vector_db, top_k=5):
    query_vector = get_embedding(query)
    results = vector_db.search(
        vector=query_vector,
        top_k=top_k,
        filter={"language": "ru"}
    )
    return results

Если нет векторной базы, можно показать cosine similarity на numpy:

import numpy as np

def cosine_similarity(a, b):
    a = np.array(a)
    b = np.array(b)
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

Но если данных больше нескольких тысяч, переходите на специализированную векторную БД.

Шаг 5: Добавляем rerank — меньше “мимо кассы”

Embedding-поиск — это “грубый” отбор: быстро, но не всегда точно.

Rerank — “точная” сортировка: оценивает релевантность вопроса и каждого кандидата.

Рекомендованный пайплайн:

Embedding-поиск — top 20 кандидатов
Rerank — сортировка по релевантности
В чат-модель идут top 5

Это надёжнее, чем просто брать top 5 по embedding, особенно если:

Много технической документации
База знаний для поддержки
Юридические/финансовые документы
Мультиязычные базы
Много похожих по названию документов

Crazyrouter поддерживает endpoint /v1/rerank — его можно встроить в RAG-процесс для точной сортировки после поиска.

Шаг 6: Передаём найденные чанки в чат-модель

После поиска собираем prompt:

def build_prompt(question, chunks):
    context = "\n\n".join(
        f"Source: {c['metadata']['source']}\n{c['text']}"
        for c in chunks
    )

    return f"""
Вы — строгий помощник базы знаний.
Отвечайте только на основе приведённых материалов.
Если ответа нет — скажите “В предоставленных данных ответа нет”.

Материалы:
{context}

Вопрос: {question}
"""

Далее вызываем чат-модель:

answer = client.chat.completions.create(
    model="gpt-5-mini",
    messages=[{"role": "user", "content": build_prompt(question, chunks)}]
)

print(answer.choices[0].message.content)

Embedding-модель и чат-модель работают вместе:

text-embedding-3-large: ищет релевантные материалы
gpt-5-mini / Claude / Gemini: формирует ответ на основе найденного

Преимущества text-embedding-3-large для мультиязычного RAG

Во многих компаниях документация на разных языках:

Английская API-дока
Русский справочный центр
Японские мануалы
Корейские статьи сообщества
Вьетнамские туториалы

Проблема мультиязычного RAG: пользователь спрашивает на одном языке, а ответ — в документации на другом.

text-embedding-3-large официально позиционируется как embedding-модель высокого качества для английского и других языков. Для кросс-языкового поиска стоит протестировать её в первую очередь.

Но не полагайтесь только на официальные метрики — соберите свой набор тестовых запросов:

Вопрос	Верный документ	Язык	Найден?
Почему быстро списываются средства?	billing-token-cost.md	ru	да/нет
how to set API base URL	quickstart.md	en	да/нет
Как настроить Claude Code?	integrations/claude-code.md	ru	да/нет

Оценивайте recall в top 3 / top 5.

Частые проблемы и их решения

Проблема	Причина	Как исправить
Не находится нужный документ	Чанк слишком большой/маленький, короткий запрос	Подберите размер чанка, перепишите запрос
Ответ ссылается не на тот документ	Мало кандидатов, нет rerank	Брать top 20 + rerank
Высокая задержка	Каждый раз пересчитывается embedding документа	Индексируйте документы оффлайн, запросы embedding — онлайн
Растёт стоимость	Дублирующая индексация, слишком большая размерность	Удаляйте дубли по hash, тестируйте меньшую размерность
Плохо ищет по разным языкам	Модель не подходит для мультиязыка	Тестируйте large, соберите мультиязычный тестовый набор

Когда НЕ стоит использовать text-embedding-3-large?

Не всегда нужен embedding максимального качества.

Можно обойтись без него, если:

Данных мало, хватает поиска по ключевым словам
Это внутренний инструмент, требования к качеству невысокие
Очень ограниченный бюджет, а база — одноязычный FAQ
Проект на стадии MVP, нет реальных пользовательских запросов

Лучше сначала протестировать small и large на реальных вопросах и только потом решать, стоит ли переходить на более дорогую модель.

Вывод: успех RAG наполовину зависит от поиска

Какой бы ни был мощный чат-модель, если в контексте не те данные — ответ будет ошибочным.

text-embedding-3-large позволяет находить информацию по смыслу, а не только по ключевым словам.

Если строите продакшн RAG, рекомендую такой порядок:

Соберите реальные документы
Разбейте их на адекватные чанки
Постройте векторный индекс на text-embedding-3-large
Оцените recall top 5 на реальных вопросах
Добавьте rerank
Оптимизируйте prompt и чат-модель

Вы можете подключить Crazyrouter embeddings API через OpenAI-совместимый SDK и использовать один base_url для embedding, rerank и чат-модели — удобно для построения полного RAG-процесса.

FAQ

Обязательно ли использовать text-embedding-3-large для RAG-базы знаний?

Нет. Он оптимален для продакшн, мультиязыка и задач с высокими требованиями к качеству. Для небольших проектов можно начать с более дешёвых embedding-моделей.

Какой размер чанка оптимален?

Нет универсального ответа. Для технической документации — 400-800 токенов, для FAQ — короче. Ориентируйтесь на качество поиска по реальным вопросам.

Можно ли использовать text-embedding-3-large с pgvector?

Да. Вектор можно сохранять в поле pgvector в PostgreSQL и искать по схожести.

Почему embedding находит нужный материал, а модель всё равно ошибается?

Возможно, среди найденных чанков есть “шум”, prompt не ограничивает модель, нет ссылок на источник или вопрос требует объединения нескольких документов. Добавьте rerank и контроль ссылок.

Нужно ли добавлять rerank в RAG?

В продакшне — да. Embedding быстро отбирает кандидатов, rerank точно сортирует. Вместе — надёжнее.

text-embedding-3-large の用途：Embeddings 入門と RAG での使い方

Jenny Met — Tue, 19 May 2026 09:48:52 +0000

text-embedding-3-large の用途：Embeddings 入門と RAG での使い方

普段 GPT、Claude、Gemini などを使うとき、多くは「答えを生成する」用途ですよね。しかし text-embedding-3-large のようなモデルは、チャットや文章生成はしません。

このモデルの主な役割は、テキストを数値ベクトルに変換すること です。

少し抽象的に聞こえるかもしれませんが、RAG（知識拡張生成）、セマンティック検索、類似記事推薦、FAQボット、ドキュメント検索などの基盤となる技術です。

AI に「自分のドキュメントから答えを探してほしい」と思ったら、embedding は避けて通れません。

text-embedding-3-large の主な用途

text-embedding-3-large は OpenAI の高性能テキストベクトル化モデルです。テキストを読み込み、高次元ベクトルを出力します。

このベクトルは、テキストの「意味的な座標」と考えるとイメージしやすいです。

例えば、以下のような文があります。

「AI API コストを下げる方法は？」
「GPT の利用料金を節約するには？」
「AI モデルの利用料が高すぎる場合は？」

キーワードは完全一致しませんが、意味は近いですよね。Embedding モデルは、これらを近い位置にマッピングします。

これにより、従来のキーワード検索では難しかった「意味で探す」が可能になります。

主な用途例：

シーン	embedding の役割
セマンティック検索	ユーザーの質問とドキュメントをベクトル化し、最も近い内容を探す
RAG 知識ベース	関連ドキュメントを検索し、大規模言語モデルに渡して回答生成
レコメンドシステム	記事・商品・ユーザー説明の意味的な類似度で推薦
ドキュメントクラスタリング	類似ドキュメントを自動でグループ化
テキスト分類	類似度でどのラベルに属するか判定
異常検知	他と大きく意味が離れたデータを検出

OpenAI の公式ドキュメントでも、embeddings は search、clustering、recommendations、anomaly detection、diversity measurement、classification などに使われています。

なぜ RAG で text-embedding-3-large が重要なのか？

RAG（Retrieval-Augmented Generation、検索拡張生成）は、以下のような流れで動きます。

ドキュメントを小さなチャンクに分割
embedding モデルで各チャンクをベクトル化
ベクトルをベクトルデータベースに保存
ユーザーの質問もベクトル化
最も関連性の高いチャンクを検索
その内容を大規模言語モデルに渡して回答生成

embedding がなければ、単なるキーワードマッチしかできません。

例えば、ユーザーが

「なぜ残高がすぐ減るの？」

と質問したとします。ドキュメントには

「高コンテキストモデルはより多くのトークンを消費し、料金は入力・出力トークン数で計算されます。」

と書かれていた場合、キーワードは一致しませんが、意味は関連しています。Embedding はこうした「意味の橋渡し」をしてくれます。

text-embedding-3-large とチャットモデルの違い

初めて embedding を触ると「これも Q&A モデル？」と思いがちですが、実際は違います。

機能	チャットモデル	embedding モデル
入力	ユーザーの質問や文脈	テキスト断片
出力	自然言語の答え	数値ベクトル
主な用途	生成・要約・推論・対話	検索・類似度計算・クラスタリング・分類
直接質問に答えるか	はい	いいえ
RAG での役割	最終回答を生成	情報検索を担当

役割分担で例えると、

embedding モデル：図書館の司書（資料を探す）
チャットモデル：ライター（答えをまとめる）

知識ベースQAシステムでは、両方を組み合わせて使うのが一般的です。

text-embedding-3-large の主なパラメータ

OpenAI 公式ドキュメントによると、text-embedding-3-large はデフォルトで 3072 次元のベクトルを出力し、最大入力は 8192 トークンです。

また dimensions パラメータで、主要な意味情報を保ったまま次元数を減らすことも可能です。

これは非常に重要で、ベクトルの次元数は

ベクトルDBのストレージコスト
検索速度
インデックスサイズ
メモリ消費

に大きく影響します。

中小規模のFAQやカスタマーサポート用途なら、必ずしも 3072 次元フルで使う必要はありません。まずは 1024 や 1536 次元で試して、検索品質を確認しましょう。

OpenAI 互換APIで text-embedding-3-large を使う方法

以下は Python の例です。API の base_url には UTM パラメータを付けないでください。

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

response = client.embeddings.create(
    model="text-embedding-3-large",
    input="AI API gateway helps developers connect to many models with one key.",
    encoding_format="float"
)

vector = response.data[0].embedding
print(len(vector))
print(vector[:5])

既に OpenAI SDK を使っている場合は、base_url を互換ゲートウェイのURLに変更するだけでOKです。

OpenAI 互換の接続方法は Crazyrouter ドキュメントを参照してください。コスト比較は価格ページも便利です。

最小構成のセマンティック検索サンプル

ここでは cosine similarity を使ったシンプルな例を紹介します。実運用では Qdrant、Milvus、Pinecone、pgvector などのベクトルDB利用を推奨します。

from openai import OpenAI
import numpy as np

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

def embed(text: str):
    res = client.embeddings.create(
        model="text-embedding-3-large",
        input=text,
        encoding_format="float"
    )
    return np.array(res.data[0].embedding)

def cosine(a, b):
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

docs = [
    "AI API costs are calculated by input and output tokens.",
    "RAG systems retrieve relevant documents before generating answers.",
    "Vector databases store embeddings for semantic search."
]

query = "How does retrieval augmented generation find context?"

query_vec = embed(query)
doc_vecs = [embed(doc) for doc in docs]

scores = [(doc, cosine(query_vec, vec)) for doc, vec in zip(docs, doc_vecs)]
scores.sort(key=lambda x: x[1], reverse=True)

for doc, score in scores:
    print(round(score, 4), doc)

この例はシンプルですが、テキストをベクトル化し、類似度でソートするというセマンティック検索の基本ロジックが詰まっています。

text-embedding-3-large を使うべきタイミング

判断の目安は以下の通りです。

ニーズ	推奨
高品質なRAG、クロス言語検索、長文知識ベース	まず text-embedding-3-large を試す
FAQや小規模検索、コスト重視	まず text-embedding-3-small を検討
多言語ドキュメント検索	large のテスト価値が高い
キーワードフィルタのみ	embedding は不要な場合も
データ量が膨大・予算厳しい	次元削減や階層検索を検討

要するに、「検索品質がユーザー体験に直結する」なら text-embedding-3-large を優先的に試す価値があります。

社内ツールやMVP段階なら、より安価な embedding モデルから始めても良いでしょう。

RAG プロジェクトのベストプラクティス

1. ドキュメントのチャンクは細かく

1文書を丸ごとembeddingせず、意味段落ごとに分割しましょう。

目安：

1チャンク 300～800トークン
50～100トークン程度のオーバーラップを持たせる
タイトル・パス・日時などのメタデータは別管理

2. クエリも前処理する

ユーザーの質問は短く口語的なことが多いです。チャットモデルで検索向きクエリに書き換えてから embedding するのも有効です。

3. top 1 だけでなく top 3～10 を見る

RAG では通常、関連度上位3～10件のチャンクを抽出し、大規模言語モデルに渡します。

4. rerank（再ランキング）を組み合わせる

embedding で粗く絞り込み、rerank で精密に順位付け。カスタマーサポートや法務・財務・技術文書では rerank で誤答を大幅に減らせます。

5. 実際のクエリログを記録・評価

デモ用データだけでなく、実際のユーザー質問（匿名化済み）で評価しましょう。本当に使えるかどうかは現場データでしか分かりません。

よくある勘違い

勘違い1：embedding の次元数は高いほど良い

必ずしもそうではありません。高次元ほど表現力は上がりますが、ストレージや計算コストも増えます。実際のプロジェクトでは検索精度・遅延・コストのバランスが重要です。

勘違い2：RAG で embedding を使えば絶対に誤答しない

これも誤りです。embedding は資料検索の役割だけ。最終的な回答の信頼性は、プロンプト設計・文脈品質・モデル能力・引用制御などにも依存します。

勘違い3：全てのドキュメントはそのままベクトル化できる

表・コード・ログ・PDFスキャンなどは特別な処理が必要です。特に表は構造化情報を残すのがベストです。

結論：text-embedding-3-large はAIアプリの「検索基盤」

text-embedding-3-large はチャット用ではなく、テキストの意味的類似度を理解するためのモデルです。

特に以下の用途に最適です。

RAG 知識ベース
セマンティック検索
多言語検索
レコメンドシステム
ドキュメントクラスタリング
テキスト分類

AIカスタマーサポート、企業ナレッジベース、ドキュメントQA、コード検索、コンテンツ推薦などを作るなら、embedding モデルはシステムの基盤となります。

OpenAI 互換APIで簡単に導入でき、既存の OpenAI SDK プロジェクトなら base_url と API key を変えるだけで移行可能です。

FAQ

text-embedding-3-large は直接質問に答えられますか？

いいえ。出力はベクトルであり、自然言語の答えではありません。質問への回答には GPT、Claude、Gemini などのチャットモデルと組み合わせる必要があります。

text-embedding-3-large は RAG に向いていますか？

はい。RAG の検索フェーズでよく使われます。ユーザーの質問や知識ベースの文書をベクトル化し、関連性の高い内容を抽出します。

text-embedding-3-large のデフォルト次元数は？

公式ドキュメントによるとデフォルトは 3072 次元です。dimensions パラメータで次元数を下げることも可能です。

text-embedding-3-large と text-embedding-3-small の選び方は？

検索品質や多言語対応、プロダクション品質のRAGを重視するなら large を優先的にテストしましょう。コスト重視や大規模データの場合は small でベースラインを作るのもおすすめです。

ベクトルデータベースは必須ですか？

小規模なデモなら配列＋cosine similarity でも動きますが、実運用では pgvector、Qdrant、Milvus、Pinecone などのベクトルDB利用を推奨します。

text-embedding-3-large или small: стоимость, качество поиска и выбор для RAG

Jenny Met — Tue, 19 May 2026 09:37:33 +0000

text-embedding-3-large или small: стоимость, качество поиска и выбор для RAG

При построении RAG или семантического поиска многие сталкиваются с одним и тем же вопросом:

Какой embedding-модель выбрать: text-embedding-3-large или более дешевую text-embedding-3-small?

Ответ не в том, что “large всегда лучше”, и не в том, что “small достаточно”.

В этой статье разберём, на что реально смотреть при выборе embedding-модели для реальных задач.

Сразу к сути: как выбрать?

Можно ориентироваться на эту таблицу:

Сценарий	Рекомендуемый старт	Почему
Корпоративный FAQ/база знаний	text-embedding-3-large	Качество поиска важнее всего
Многоязычный RAG	text-embedding-3-large	Стоит протестировать для неанглийских и кросс-языковых запросов
Чат-бот поддержки	large или small через A/B тест	Оценить цену ошибки
Внутренний поиск по инструментам	text-embedding-3-small	Приоритет — стоимость, допустимы ошибки
MVP / демо	text-embedding-3-small	Главное — быстро собрать рабочий прототип
Индексация огромных массивов	small или large с понижением размерности	Контроль затрат на хранение и поиск
Поиск по коду/техдокам	large + rerank	Важно и семантическое, и точное совпадение

Если запомнить только одну фразу:

Сначала small для базовой оценки, потом large — для проверки улучшений на реальных запросах.

Чем силён text-embedding-3-large?

text-embedding-3-large — это embedding-модель с более высокими возможностями.

Её сильные стороны:

Более глубокое семантическое понимание
Лучше справляется со сложными запросами
Эффективнее для многоязычного и кросс-языкового поиска
Дружелюбнее к длинным документам
Хороший кандидат для продакшн-RAG

Но есть и минусы:

Дороже за токен
Вектор больше по размеру
Дороже хранить векторную базу
Больше нагрузка на память и индексацию при поиске

Поэтому large стоит выбирать, только если прирост качества поиска оправдывает дополнительные расходы.

Когда подходит text-embedding-3-small?

text-embedding-3-small — это про эффективность и экономию.

Подходит для:

Поиска по FAQ
Небольших баз знаний
MVP и прототипов
Внутренних инструментов
Одноязычных коллекций
Сценариев, где ошибки поиска не критичны

Во многих случаях нет смысла сразу брать large.

Стоимость — это не только цена API

Затраты на embedding — это не только вызовы модели.

В расчёт стоит брать:

Статья затрат	От чего зависит
Стоимость API	Количество токенов, частота переиндексации
Хранение векторов	Количество документов, чанков, размерность вектора
Задержка поиска	Размер индекса, размерность, top_k
Память/диск	Количество и точность векторов
Поддержка	Переиндексация, миграция версий, тестирование

Простой пример:

Если у вас 1 миллион чанков, каждый вектор — 3072 float32, то только на векторах:

1,000,000 × 3072 × 4 bytes ≈ 12.3 GB

Если уменьшить размерность до 1536 — будет примерно вдвое меньше.

И это без учёта индекса, метаданных и накладных расходов БД.

Поэтому для крупных проектов важно следить за параметром dimensions и стоимостью векторной базы.

Как использовать параметр dimensions?

В embedding-моделях третьего поколения OpenAI можно управлять размером выходного вектора через параметр dimensions.

Пример:

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

response = client.embeddings.create(
    model="text-embedding-3-large",
    input="How to reduce AI API cost with model routing?",
    dimensions=1536,
    encoding_format="float"
)

vector = response.data[0].embedding
print(len(vector))

Это очень полезно в продакшне.

Можно сравнить:

large 3072
large 1536
large 1024
small (по умолчанию)

А потом посмотреть на Recall@5, задержку и стоимость.

Не ориентируйтесь только на MTEB

Публичные бенчмарки полезны, но не заменяют реальные данные.

Ваши задачи могут отличаться от тестовых наборов:

Короткие пользовательские запросы
Документы на смешанном русском и английском
Много названий продуктов и кодов ошибок
Таблицы и параметры в тексте
Пользователи часто пишут разговорно

Лучше собрать свою небольшую тестовую выборку.

Простейший формат:

Запрос	Ожидаемый документ	Тип
Как посмотреть баланс?	billing.md	FAQ
Что указывать в base_url?	quickstart.md	technical
Как настроить Claude Code?	claude-code.md	integration
Что делать при ошибке 401?	auth-errors.md	troubleshooting

Прогоните каждый вариант модели и посмотрите, попадает ли нужный документ в топ-3/топ-5.

Как провести A/B тестирование моделей

Рекомендую такой подход:

1. Соберите 50-200 реальных запросов

Не придумывайте сами. Лучше взять:

Логи поиска на сайте
Вопросы в поддержку
Вопросы из чатов/групп
Заголовки тикетов
Комментарии к документации

2. Проставьте правильные ответы

Для каждого запроса отметьте 1-3 релевантных чанка или документа.

3. Постройте несколько индексов

Например:

index_small_default
index_large_3072
index_large_1536

4. Прогоните тесты на поиск

Ключевые метрики:

Метрика	Описание
Recall@3	Входит ли правильный документ в топ-3
Recall@5	Входит ли правильный документ в топ-5
MRR	Чем выше позиция правильного документа, тем лучше
latency	Время ответа на запрос
cost	Стоимость индекса и поиска

5. Решите, стоит ли переходить на large

Если прирост Recall@5 всего 1%, а расходы сильно выше — возможно, не стоит.

Если же Recall@5 вырос с 78% до 90%, а бизнесу критична точность — переход оправдан.

Плохой RAG — не всегда вина embedding-модели

Часто даже переход на large не спасает, если проблемы в другом:

Проблема	Проявление	Что делать
Плохо нарезаны чанки	Контекст найденного ответа неполный	Перерезать чанки
Нет метаданных	Нельзя фильтровать по языку/правам/продукту	Добавить метаданные
Слишком короткий запрос	“Проблема с оплатой” ищет плохо	Переписывать запросы
Устаревшие документы	Находятся старые ответы	Фильтровать по дате/версии
Нет rerank	Топ-результаты похожи, но не точные	Добавить rerank
Слабый prompt	Модель отвечает “из головы”	Жёстко ограничить ответы только по базе

Перед выбором модели убедитесь, что ваша RAG-пайплайн не слишком “сырая”.

Как переключаться между embedding-моделями через OpenAI-совместимый API

Если вы используете OpenAI SDK, сменить модель очень просто.

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

# Для экономии
small = client.embeddings.create(
    model="text-embedding-3-small",
    input="semantic search for AI documentation"
)

# Для качества
large = client.embeddings.create(
    model="text-embedding-3-large",
    input="semantic search for AI documentation"
)

Если вы используете OpenAI-совместимый шлюз вроде Crazyrouter, обычно менять нужно только имя модели и base URL.

Можно сначала проверить вызовы в Crazyrouter Playground, а затем перенести параметры на сервер.

Вывод: large — не всегда ответ, но тестировать стоит

Но не стоит слепо брать самую мощную модель.

Лучше действовать так:

Сначала small — для оценки затрат и базового качества
Потом large — для проверки реального прироста на ваших данных
Управляйте размерностью через dimensions
Добавляйте rerank и гибридный поиск, а не только меняйте модель
Оценивайте, насколько критичны ошибки для бизнеса

Если RAG влияет на решения пользователей, поддержку или оплату — скорее всего, large оправдан.

Если это внутренний инструмент или ранний прототип — small практичнее.

FAQ

text-embedding-3-large всегда лучше, чем text-embedding-3-small?

Снижение dimensions ухудшает качество?

В RAG-проекте сначала оптимизировать модель или нарезку чанков?

Сначала — нарезку и тестовую выборку. Если чанки плохие, даже сильная embedding-модель мало поможет.

Для многоязычных баз лучше large?

Можно ли вызывать text-embedding-3-large через Crazyrouter?

Да, через OpenAI-совместимый эндпоинт /v1/embeddings. Просто укажите https://crazyrouter.com/v1 как base URL в коде.

text-embedding-3-large — для чего нужен embeddings-модель и как он работает в RAG

Jenny Met — Tue, 19 May 2026 09:37:32 +0000

text-embedding-3-large — для чего нужен embeddings-модель и как он работает в RAG

Их основная задача — преобразовывать текст в числовой вектор.

Для чего нужен text-embedding-3-large?

Вектор — это “семантические координаты” текста.

Например, возьмём такие фразы:

“Как снизить стоимость AI API?”
“Как сэкономить на GPT?”
“Что делать, если вызовы AI моделей слишком дорогие?”

Ключевые слова разные, но смысл близок. Embedding-модель спроецирует их в близкие точки пространства.

Это позволяет делать то, что не под силу обычному поиску по ключевым словам: искать по смыслу.

Типичные применения:

Сценарий	Роль embeddings
Семантический поиск	Преобразует вопросы и документы в векторы, ищет наиболее похожие
RAG (знаниевая база)	Сначала ищет релевантные документы, затем передаёт их генеративной модели
Рекомендации	Рекомендует контент по смысловой близости описаний
Кластеризация	Автоматически группирует похожие документы
Классификация	Определяет принадлежность текста к категории по схожести
Детектирование аномалий	Находит “выбивающиеся” по смыслу данные

Почему RAG особенно нуждается в text-embedding-3-large?

RAG (Retrieval-Augmented Generation) — это “генерация с усилением за счёт поиска”.

Типовой процесс:

Разбиваем документы на небольшие фрагменты
Преобразуем каждый фрагмент в вектор через embedding-модель
Сохраняем в векторную базу данных
При вопросе пользователя тоже получаем вектор
Находим наиболее релевантные фрагменты
Передаём их генеративной модели для ответа

Без embeddings система может только искать по ключевым словам.

Например, пользователь спрашивает:

“Почему баланс быстро уменьшается?”

А в документации написано:

“Модели с большим контекстом используют больше tokens, стоимость считается по количеству входных и выходных tokens.”

Ключевые слова не совпадают, но смысл связан. Embedding решает именно такие задачи.

Чем отличается text-embedding-3-large от чат-моделей?

Многие разработчики поначалу думают, что embedding — это тоже “модель для вопросов-ответов”. Это не так.

Возможности	Чат-модель	Embedding-модель
Входные данные	Вопросы, контекст	Текстовые фрагменты
Выходные данные	Ответ на естественном языке	Числовой вектор
Основные задачи	Генерация, суммирование, рассуждение, диалог	Поиск, схожесть, кластеризация, классификация
Отвечает ли напрямую на вопросы	Да	Нет
Роль в RAG	Генерирует финальный ответ	Находит релевантные данные

Можно представить их так:

embedding-модель — библиотекарь, ищет нужные материалы
чат-модель — автор, формулирует ответ

В полноценной системе поиска по знаниям нужны обе.

Ключевые параметры text-embedding-3-large

Это важно, потому что размерность влияет на:

стоимость хранения в векторной базе
скорость поиска
размер индекса
использование памяти

Как вызвать text-embedding-3-large через OpenAI-совместимый API?

Пример на Python. В API-адресе не добавляйте UTM-параметры.

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

response = client.embeddings.create(
    model="text-embedding-3-large",
    input="AI API gateway helps developers connect to many models with one key.",
    encoding_format="float"
)

vector = response.data[0].embedding
print(len(vector))
print(vector[:5])

Если вы уже используете OpenAI SDK, просто поменяйте base_url на адрес совместимого шлюза.

Минимальный пример семантического поиска

from openai import OpenAI
import numpy as np

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

def embed(text: str):
    res = client.embeddings.create(
        model="text-embedding-3-large",
        input=text,
        encoding_format="float"
    )
    return np.array(res.data[0].embedding)

def cosine(a, b):
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

docs = [
    "AI API costs are calculated by input and output tokens.",
    "RAG systems retrieve relevant documents before generating answers.",
    "Vector databases store embeddings for semantic search."
]

query = "How does retrieval augmented generation find context?"

query_vec = embed(query)
doc_vecs = [embed(doc) for doc in docs]

scores = [(doc, cosine(query_vec, vec)) for doc, vec in zip(docs, doc_vecs)]
scores.sort(key=lambda x: x[1], reverse=True)

for doc, score in scores:
    print(round(score, 4), doc)

Этот пример прост, но отражает суть семантического поиска: текст → вектор → сортировка по схожести.

Когда стоит использовать text-embedding-3-large?

Рекомендации по выбору:

Задача	Совет
Качественный RAG, мультиязычный поиск, большие базы	Сначала пробуйте text-embedding-3-large
FAQ, небольшой поиск, чувствительность к цене	Можно начать с text-embedding-3-small
Мультиязычный поиск	large предпочтительнее
Только фильтрация по ключевым словам	Embedding не обязателен
Очень большой объём данных, ограниченный бюджет	Оцените уменьшение размерности и многоуровневый поиск

Если качество поиска критично для пользователей — text-embedding-3-large стоит тестировать в первую очередь.

Для внутренних инструментов или MVP можно начать с более дешёвых моделей.

Лучшие практики для RAG-проектов

1. Не делайте слишком крупные чанки

Не загружайте целиком большие документы. Лучше разбивать по смысловым абзацам.

Рекомендации:

300–800 токенов на один чанк
50–100 токенов overlap между чанками
Метаданные (заголовок, путь, дата) хранить отдельно

2. Предобработка запросов

3. Не ограничивайтесь только top 1

Обычно в RAG берут top 3–10 фрагментов, затем передают их генеративной модели.

4. Используйте rerank для точности

5. Анализируйте реальные запросы

Частые заблуждения

Миф 1: чем выше размерность embedding, тем лучше

Миф 2: если есть embedding, RAG не будет “галлюцинировать”

Миф 3: любой документ можно просто векторизовать

Таблицы, код, логи, сканы PDF требуют особой обработки. Для таблиц лучше сохранять структуру.

Вывод: text-embedding-3-large — “поисковый фундамент” AI-приложений

text-embedding-3-large — это не чат-модель, а инструмент для оценки смысловой близости текстов.

Он идеально подходит для:

RAG-знаниевых баз
семантического поиска
мультиязычного поиска
рекомендательных систем
кластеризации документов
классификации текстов

FAQ

Может ли text-embedding-3-large напрямую отвечать на вопросы?

Подходит ли text-embedding-3-large для RAG?

Какая размерность по умолчанию у text-embedding-3-large?

В официальной документации — 3072. Можно уменьшить через параметр dimensions.

Как выбрать между text-embedding-3-large и text-embedding-3-small?

Обязательна ли векторная база данных?

text-embedding-3-large или small: стоимость, качество поиска и выбор для RAG

Jenny Met — Tue, 19 May 2026 09:31:04 +0000

text-embedding-3-large или small: стоимость, качество поиска и выбор для RAG

При разработке RAG или семантического поиска почти все упираются в один вопрос:

我到底该用 text-embedding-3-large，还是用更便宜的 text-embedding-3-small？

Ответ не сводится к «large всегда лучше» или «small всегда достаточно».

更准确的说法是：如果检索质量直接影响业务结果，large 值得测试；如果项目还在早期或数据量特别大，small 往往是更稳的起点。

Разберём выбор embedding-модели с точки зрения реального проекта.

先说结论：怎么选？

可以直接按这个表判断：

场景	推荐起点	原因
企业知识库问答	text-embedding-3-large	召回质量更重要
多语言 RAG	text-embedding-3-large	非英文和跨语言检索更值得测试
客服机器人	large 或 small A/B 测试	看错误回答成本
内部工具搜索	text-embedding-3-small	成本优先，容错较高
MVP / demo	text-embedding-3-small	先跑通链路
海量文档索引	small 或 large 降维	控制存储和检索成本
代码/技术文档搜索	large + rerank	语义和精确匹配都重要

如果你只能记一句话：

先用 small 建基线，再用 large 在真实 query 上评测提升。

text-embedding-3-large 强在哪里？

text-embedding-3-large 是更高能力的 embedding 模型。

根据 OpenAI 官方文档，它默认输出 3072 维向量，最大输入 8192 tokens，定位是英文和非英文任务上的高能力 embedding 模型。

它的优势主要体现在：

更强的语义表达能力
更适合复杂查询
更适合多语言或跨语言检索
对长文档知识库更友好
更适合作为生产级 RAG 的候选模型

但它也有代价：

单位 token 成本更高
默认向量维度更大
向量库存储成本更高
检索时内存和索引压力更大

所以，选 large 的前提应该是：它带来的召回提升能覆盖额外成本。

text-embedding-3-small 适合什么？

text-embedding-3-small 的定位更偏成本效率。

它适合：

FAQ 搜索
小型知识库
早期 MVP
内部检索工具
单语言内容库
对错误召回容忍度较高的场景

很多项目没必要一开始就上 large。

尤其当你还没有真实用户问题、没有评测集、没有线上反馈时，上大模型向量可能只是“感觉更稳”，但你无法证明它真的更好。

成本不只看 API 价格

Embedding 成本不只是调用模型那一项。

你还要算：

成本项	受什么影响
API 调用成本	输入 tokens 数量、重复索引次数
向量库存储	文档数量、chunk 数、向量维度
检索延迟	索引规模、维度、top_k
内存/磁盘	向量数量和精度
维护成本	重建索引、版本迁移、评测

举个简单例子：

如果你有 100 万个 chunk，每个向量 3072 维，使用 float32 存储，单纯向量数据大约是：

1,000,000 × 3072 × 4 bytes ≈ 12.3 GB

如果降到 1536 维，大约就是一半。

这还不包括索引结构、metadata、数据库额外开销。

所以大规模项目一定要关注 dimensions 参数和向量数据库成本。

dimensions 参数怎么用？

OpenAI 第三代 embedding 模型支持通过 dimensions 控制输出向量大小。

示例：

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

response = client.embeddings.create(
    model="text-embedding-3-large",
    input="How to reduce AI API cost with model routing?",
    dimensions=1536,
    encoding_format="float"
)

vector = response.data[0].embedding
print(len(vector))

这对生产环境很有用。

你可以测试：

large 3072 维
large 1536 维
large 1024 维
small 默认维度

然后比较 top 5 召回率、延迟和成本。

选型不要只看 MTEB 分数

公开 benchmark 有参考价值，但不要把它当最终答案。

你的业务数据可能和 benchmark 完全不同：

用户问题很短
文档是中英混合
内容里有很多产品名和错误码
有大量表格和参数说明
用户经常用口语表达

所以最好建立自己的小评测集。

最简单的格式：

query	应召回文档	类型
怎么查看余额？	billing.md	FAQ
base_url 应该填什么？	quickstart.md	technical
Claude Code 怎么配置？	claude-code.md	integration
API 调用失败 401 怎么办？	auth-errors.md	troubleshooting

每个模型跑一遍，看 top 3 / top 5 是否命中。

一个可执行的 A/B 测试流程

推荐你这样测：

1. 准备 50-200 个真实 query

不要自己拍脑袋写。优先用：

站内搜索日志
客服问题
用户群问题
工单标题
文档评论

2. 标注正确答案文档

每个 query 标 1-3 个正确 chunk 或文档。

3. 建立多个索引

例如：

index_small_default
index_large_3072
index_large_1536

4. 跑召回评测

核心指标：

指标	含义
Recall@3	前 3 个结果是否包含正确文档
Recall@5	前 5 个结果是否包含正确文档
MRR	正确文档排得越靠前越好
latency	查询耗时
cost	索引和查询成本

5. 决定是否升级 large

如果 large 只提升 1%，但成本高很多，未必值得。

如果 large 把 Recall@5 从 78% 提到 90%，而业务又很依赖准确检索，那就很值得。

RAG 质量差，未必是 embedding 模型的问题

很多时候，换成 large 也救不了系统。

因为问题可能在别处：

问题	表现	优先修复
chunk 切坏了	找到的内容上下文不完整	重新切块
metadata 缺失	无法按语言/权限/产品过滤	补 metadata
query 太短	“扣费问题”召回不稳定	query rewrite
文档过期	找到了旧答案	加更新时间和版本过滤
没有 rerank	top 结果相似但不精确	加 rerank
prompt 太松	模型根据常识乱答	强制只根据资料回答

所以选模型前，先保证 RAG 管线别太粗糙。

在 OpenAI 兼容接口中切换 embedding 模型

如果你通过 OpenAI SDK 接入，切换模型很简单。

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

# 成本效率优先
small = client.embeddings.create(
    model="text-embedding-3-small",
    input="semantic search for AI documentation"
)

# 质量优先
large = client.embeddings.create(
    model="text-embedding-3-large",
    input="semantic search for AI documentation"
)

如果你用 Crazyrouter 这类 OpenAI 兼容网关，通常不用改 SDK，只改模型名和 base URL。

你可以先在 Crazyrouter Playground 验证调用，再把同样参数放进服务端。

结论：large 不是默认答案，但值得认真测试

text-embedding-3-large 的价值在于更强的语义表达能力，尤其适合高质量 RAG、多语言知识库和复杂语义搜索。

但工程上不要盲目上最强模型。

更好的策略是：

用 small 建立成本和效果基线
用真实 query 测 large 的提升
用 dimensions 控制向量大小
加 rerank 和 hybrid search，而不是只靠换模型
根据业务错误成本决定是否升级

如果 RAG 结果直接影响用户决策、客服体验或付费转化，text-embedding-3-large 很可能值得。

如果只是内部工具或早期验证，先从 small 开始更务实。

FAQ

text-embedding-3-large 一定比 text-embedding-3-small 好吗？

通常能力更强，但不代表每个项目都值得用。要看真实 query 的召回提升是否覆盖成本。

dimensions 降低后会不会影响效果？

可能会。降维能减少存储和检索成本，但可能降低召回质量。建议用自己的评测集测试。

RAG 项目应该先优化模型还是切块？

先优化切块和评测。chunk 策略很差时，换更强 embedding 模型也可能效果有限。

多语言知识库更适合 text-embedding-3-large 吗？

值得优先测试。官方定位里 large 适合英文和非英文任务，多语言检索通常更依赖语义表达能力。

可以用 Crazyrouter 调用 text-embedding-3-large 吗？

可以通过 OpenAI 兼容的 /v1/embeddings 端点调用。代码里使用 https://crazyrouter.com/v1 作为 base URL 即可。

Быстрый старт с Crazyrouter

Если вам нужен OpenAI-compatible API для embeddings, RAG и нескольких AI-моделей через один ключ, попробуйте Crazyrouter. Базовый URL для SDK: https://crazyrouter.com/v1.

Как построить RAG-базу знаний на text-embedding-3-large: chunking, embeddings и rerank

Jenny Met — Tue, 19 May 2026 09:31:02 +0000

Как построить RAG-базу знаний на text-embedding-3-large: chunking, embeddings и rerank

Многие RAG-демо выглядят просто: загрузили PDF, задали вопрос, получили ответ.

Но в production проблемы появляются сразу:

文档太长，直接塞不进上下文
关键词搜索找不到语义相近内容
用户问法很口语，文档写法很正式
搜出来的内容不准，模型就开始编
数据一多，检索速度和成本都上来了

text-embedding-3-large 解决的是其中最关键的一环：把问题和文档变成可比较的语义向量。

В этой статье без лишней теории разберём инженерный RAG-пайплайн, который можно довести до production.

RAG 系统的基本架构

一个最常见的 RAG 知识库通常分成两条链路。

第一条是离线索引链路：

收集文档
清洗文本
切块 chunking
调用 embedding 模型生成向量
存入向量数据库

第二条是在线问答链路：

用户提问
把问题转成 embedding
在向量库里检索相似文档块
可选：rerank 重新排序
拼接上下文
调用聊天模型生成答案

这个流程里，text-embedding-3-large 主要出现在第 4 步和在线链路第 2 步。

它不负责最终回答，但它决定了模型能不能拿到正确资料。

第一步：准备文档和切块

RAG 质量很大程度取决于 chunk。

切得太大：召回结果噪声多，模型读到很多无关内容。

切得太小：上下文不完整，模型拿不到足够信息。

一个常用起点：

文档类型	建议 chunk 大小	overlap
FAQ / 帮助中心	200-500 tokens	30-80 tokens
技术文档	400-800 tokens	80-120 tokens
长篇报告	600-1000 tokens	100-150 tokens
代码文档	按函数/类/标题切	视情况

示例切块代码：

def chunk_text(text, chunk_size=600, overlap=100):
    words = text.split()
    chunks = []
    start = 0

    while start < len(words):
        end = start + chunk_size
        chunk = " ".join(words[start:end])
        chunks.append(chunk)
        start = end - overlap

    return chunks

生产环境不要只按空格切。更好的方式是按标题、段落、列表、代码块边界切。

第二步：用 text-embedding-3-large 生成向量

下面代码使用 OpenAI 兼容接口。你可以用同一个 SDK 调用 /v1/embeddings。

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

def get_embedding(text: str):
    text = text.replace("\n", " ")
    response = client.embeddings.create(
        model="text-embedding-3-large",
        input=text,
        encoding_format="float"
    )
    return response.data[0].embedding

如果你要控制向量维度，可以加 dimensions 参数：

response = client.embeddings.create(
    model="text-embedding-3-large",
    input=text,
    dimensions=1536,
    encoding_format="float"
)

维度越低，存储和检索成本通常越低；但召回质量可能下降。建议用真实问题集做 A/B 测试。

第三步：存入向量数据库

小项目可以用本地文件或 SQLite 做 demo，但生产环境建议使用专门的向量数据库。

常见选择：

工具	适合场景
pgvector	已经使用 PostgreSQL，希望少引入组件
Qdrant	独立向量数据库，部署简单，过滤能力强
Milvus	大规模向量检索
Pinecone	托管服务，省运维
Weaviate	带 schema 和 hybrid search

无论用哪个库，建议每个 chunk 至少保存这些字段：

{
  "id": "doc_001_chunk_003",
  "text": "chunk content here",
  "embedding": [0.0123, -0.0456],
  "metadata": {
    "source": "billing-guide.md",
    "title": "Billing Guide",
    "section": "Token pricing",
    "updated_at": "2026-05-18"
  }
}

Metadata 很重要。它能让你按产品、语言、时间、权限过滤检索结果。

第四步：查询时做语义检索

当用户提问时，先把问题转成向量，然后在数据库里找相似 chunk。

def retrieve(query: str, vector_db, top_k=5):
    query_vector = get_embedding(query)
    results = vector_db.search(
        vector=query_vector,
        top_k=top_k,
        filter={"language": "zh"}
    )
    return results

如果不用向量数据库，也可以用 numpy 演示 cosine similarity：

import numpy as np

def cosine_similarity(a, b):
    a = np.array(a)
    b = np.array(b)
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

但数据量到几万条以后，就应该换向量数据库了。

第五步：加入 rerank，减少答非所问

Embedding 检索是“粗召回”。它很快，但不总是最精确。

Rerank 是“精排序”。它会重新判断 query 和候选文档之间的相关性。

推荐流程：

embedding 先取 top 20
rerank 排序
最终取 top 5 给聊天模型

这样比直接取 embedding top 5 更稳，尤其适合：

技术文档问答
客服知识库
法务/财务资料
多语言内容库
文档很多、标题相似的场景

Crazyrouter 支持 /v1/rerank 这类重排序端点，你可以把它放在 RAG 检索链路里，作为召回后的精排步骤。

第六步：把检索结果交给聊天模型

检索到 chunk 后，拼成 prompt：

def build_prompt(question, chunks):
    context = "\n\n".join(
        f"Source: {c['metadata']['source']}\n{c['text']}"
        for c in chunks
    )

    return f"""
你是一个严谨的知识库助手。
只根据下面的资料回答问题。
如果资料里没有答案，就说“资料中没有找到”。

资料：
{context}

问题：{question}
"""

然后调用聊天模型生成答案。

answer = client.chat.completions.create(
    model="gpt-5-mini",
    messages=[{"role": "user", "content": build_prompt(question, chunks)}]
)

print(answer.choices[0].message.content)

这里 embedding 模型和聊天模型各司其职：

text-embedding-3-large：找相关资料
gpt-5-mini / Claude / Gemini：根据资料组织答案

text-embedding-3-large 在多语言 RAG 里的优势

很多团队的文档不是单一语言。

可能有：

英文 API 文档
中文帮助中心
日文用户手册
韩文社区文章
越南语教程

多语言 RAG 的难点是：用户用一种语言提问，答案可能藏在另一种语言的文档里。

text-embedding-3-large 官方定位是适合英文和非英文任务的高能力 embedding 模型。做跨语言检索时，建议优先把它作为候选模型测试。

但不要只看官方分数。你应该建立自己的评测集：

query	正确文档	语言	是否召回
余额为什么扣费快？	billing-token-cost.md	zh	yes/no
how to set API base URL	quickstart.md	en	yes/no
Claude Code 怎么配置？	integrations/claude-code.md	zh	yes/no

最终看 top 3 / top 5 召回率。

生产环境优化建议

1. 增量索引，不要每次全量重建

文档更新后，只重新向量化变化的 chunk。

给每个 chunk 存 hash：

import hashlib

def content_hash(text):
    return hashlib.sha256(text.encode("utf-8")).hexdigest()

hash 不变就跳过。

2. 使用批量 embedding

不要一条一条调用。Embeddings API 通常支持批量输入。

response = client.embeddings.create(
    model="text-embedding-3-large",
    input=[chunk1, chunk2, chunk3],
    encoding_format="float"
)

这样更快，也更容易控制请求数。

3. 做 hybrid search

纯向量搜索有时会漏掉精确关键词，例如错误码、订单号、函数名。

更稳的方式是：

BM25 / 关键词搜索
向量搜索
合并结果
rerank

4. 给答案加引用来源

不要只输出答案。最好附上引用文档标题和链接。

这会显著提升用户信任，也方便排查错误召回。

5. 分权限检索

企业知识库一定要做权限过滤。

不要先召回再过滤。应该在向量数据库查询阶段就带上权限条件。

常见问题排查

问题	常见原因	解决方式
找不到正确文档	chunk 太大/太小，query 太短	调整切块，query rewrite
答案引用错文档	top_k 太小，缺 rerank	top 20 + rerank
延迟太高	每次实时向量化文档	文档离线索引，查询实时 embedding
成本上升快	重复索引、维度过高	hash 去重，降维测试
多语言召回差	模型不适合跨语言	测试 large，建立多语言评测集

什么时候不该用 text-embedding-3-large？

不是所有项目都需要最高能力 embedding。

这些情况可以先不用：

数据量很小，关键词搜索够用
只是后台管理工具，对召回质量要求不高
预算极紧，且内容主要是单语言 FAQ
业务还在 MVP 阶段，没有真实 query 数据

更务实的做法是：先用一组真实问题测试 small 和 large 的召回差异，再决定是否升级。

结论：RAG 的成败，一半在检索

聊天模型再强，如果上下文拿错了，也只能认真地答错。

text-embedding-3-large 的价值在于让系统能按语义找到资料，而不是只靠关键词碰运气。

如果你要做生产级 RAG，我建议按这个顺序推进：

整理真实文档
做合理切块
用 text-embedding-3-large 建立向量索引
用真实用户问题评测 top 5 召回率
加 rerank
再优化 prompt 和聊天模型

你可以用 OpenAI 兼容 SDK 接入 Crazyrouter embeddings API，同一个 base_url 下同时调用 embedding、rerank 和聊天模型，方便把 RAG 链路串起来。

FAQ

RAG 知识库一定要用 text-embedding-3-large 吗？

不一定。它适合高质量、多语言、生产级检索。小项目可以先用成本更低的 embedding 模型做基线。

文档切块多大最合适？

没有固定答案。技术文档可以从 400-800 tokens 开始，FAQ 可以更短。最终看真实 query 的召回效果。

text-embedding-3-large 可以和 pgvector 一起用吗？

可以。你可以把生成的向量存到 PostgreSQL 的 pgvector 字段里，再用向量相似度查询。

为什么 embedding 找到了资料，模型还是回答错？

可能是召回内容有噪声、prompt 没有限制、模型忽略引用，或者问题需要多个文档联合推理。可以加 rerank 和引用约束。

RAG 要不要加 rerank？

生产环境建议加。Embedding 负责快速召回，rerank 负责精排，组合效果通常更稳。

text-embedding-3-large の用途：Embeddings 入門と RAG での使い方

Jenny Met — Tue, 19 May 2026 09:30:33 +0000

text-embedding-3-large の用途：Embeddings 入門と RAG での使い方

GPT、Claude、Gemini を呼び出すとき、多くの場合は「回答を生成する」ことを期待します。しかし text-embedding-3-large のようなモデルはチャットしたり記事を書いたりするためのものではありません。

中心的な役割は、テキストを数値ベクトルに変換することです。

少し抽象的に聞こえますが、RAG ナレッジベース、セマンティック検索、関連記事推薦、FAQ ボット、ドキュメント検索の土台になる技術です。

AI に自社ドキュメントから答えを探させたいなら、モデルの記憶に頼るだけでは足りません。embeddings はほぼ必須です。

text-embedding-3-large 的核心用途是什么？

text-embedding-3-large 是 OpenAI 的高能力文本向量模型。它会读取一段文本，然后输出一个高维向量。

向量可以理解成文本的“语义坐标”。

比如下面几句话：

“如何降低 AI API 成本？”
“怎么节省 GPT 接口费用？”
“AI 模型调用太贵怎么办？”

关键词不完全一样，但意思接近。Embedding 模型会把它们映射到相近的位置。

这让系统可以做传统关键词搜索做不好的事情：按语义找内容。

常见用途包括：

场景	embedding 在里面做什么
语义搜索	把用户问题和文档都转成向量，找最相似内容
RAG 知识库	先检索相关文档，再交给大模型生成答案
推荐系统	根据文章、商品、用户描述的语义相似度推荐内容
文档聚类	自动把相似文档分组
文本分类	用相似度判断文本属于哪个标签
异常检测	找出和大多数内容语义距离很远的数据

OpenAI 官方文档也把 embeddings 用于 search、clustering、recommendations、anomaly detection、diversity measurement 和 classification。

为什么 RAG 特别需要 text-embedding-3-large？

RAG，全称 Retrieval-Augmented Generation，中文可以理解为“检索增强生成”。

它的流程通常是：

把文档切成小块
用 embedding 模型把每个文档块转成向量
存进向量数据库
用户提问时，把问题也转成向量
找出最相关的几个文档块
把这些内容交给大模型回答

如果没有 embedding，系统只能做关键词匹配。

比如用户问：

“余额为什么扣得这么快？”

文档里可能写的是：

“高上下文模型会消耗更多 tokens，费用按输入和输出 tokens 计费。”

关键词几乎对不上，但语义相关。Embedding 就是解决这种问题的。

text-embedding-3-large 和聊天模型有什么区别？

很多开发者第一次接触 embedding 会误以为它也是“问答模型”。其实不是。

能力	聊天模型	embedding 模型
输入	用户问题、上下文	文本片段
输出	自然语言答案	数字向量
主要用途	生成、总结、推理、对话	检索、相似度、聚类、分类
是否直接回答问题	是	否
是否适合 RAG	负责最终回答	负责找资料

可以把它们分工理解为：

embedding 模型：图书管理员，负责找资料
聊天模型：写作者，负责组织答案

一个完整的知识库问答系统，通常两者都要用。

text-embedding-3-large 的关键参数

根据 OpenAI 官方文档，text-embedding-3-large 默认输出 3072 维向量，最大输入上下文为 8192 tokens。

它也支持 dimensions 参数。你可以在保留主要语义信息的前提下，把向量维度降下来。

这很重要，因为向量维度会影响：

向量数据库存储成本
检索速度
索引大小
内存占用

如果你只是做中小型 FAQ、客服知识库，未必一定要 3072 维全量向量。可以先测试 1024 或 1536 维，观察召回质量。

如何用 OpenAI 兼容接口调用 text-embedding-3-large？

下面是 Python 示例。代码里的 API 地址不要加 UTM 参数。

from openai import OpenAI

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

response = client.embeddings.create(
    model="text-embedding-3-large",
    input="AI API gateway helps developers connect to many models with one key.",
    encoding_format="float"
)

vector = response.data[0].embedding
print(len(vector))
print(vector[:5])

如果你已经在项目里使用 OpenAI SDK，只需要把 base_url 换成兼容网关地址即可。

你可以通过 Crazyrouter 文档查看 OpenAI 兼容接入方式，也可以在价格页面对比不同模型成本。

一个最小可用的语义搜索示例

下面用最简单的 cosine similarity 演示 embedding 的工作方式。生产环境建议换成向量数据库，例如 Qdrant、Milvus、Pinecone、pgvector。

from openai import OpenAI
import numpy as np

client = OpenAI(
    api_key="your-api-key",
    base_url="https://crazyrouter.com/v1"
)

def embed(text: str):
    res = client.embeddings.create(
        model="text-embedding-3-large",
        input=text,
        encoding_format="float"
    )
    return np.array(res.data[0].embedding)

def cosine(a, b):
    return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)))

docs = [
    "AI API costs are calculated by input and output tokens.",
    "RAG systems retrieve relevant documents before generating answers.",
    "Vector databases store embeddings for semantic search."
]

query = "How does retrieval augmented generation find context?"

query_vec = embed(query)
doc_vecs = [embed(doc) for doc in docs]

scores = [(doc, cosine(query_vec, vec)) for doc, vec in zip(docs, doc_vecs)]
scores.sort(key=lambda x: x[1], reverse=True)

for doc, score in scores:
    print(round(score, 4), doc)

这个例子虽然简单，但已经包含了语义搜索的核心逻辑：文本转向量，然后按相似度排序。

什么时候该用 text-embedding-3-large？

我建议按下面的方式判断：

需求	建议
高质量 RAG、跨语言检索、长文档知识库	优先测试 text-embedding-3-large
FAQ、小规模搜索、成本敏感项目	可以先用 text-embedding-3-small
多语言文档检索	更值得测试 large
只做关键词过滤	不一定需要 embedding
数据量极大、预算紧	先评估降维和分层检索

一句话：如果你的搜索质量直接影响用户体验，text-embedding-3-large 值得优先测试。

如果只是内部工具或早期 MVP，可以先从更便宜的 embedding 模型开始。

RAG 项目里的最佳实践

1. 文档切块不要太粗

不要把整篇文档直接塞进去。建议按语义段落切块。

常见范围：

300-800 tokens 一个 chunk
保留 50-100 tokens overlap
标题、路径、时间等 metadata 单独存储

2. 查询也要预处理

用户问题可能很短、很口语。可以先让聊天模型把问题改写成更适合检索的查询，再做 embedding。

3. 不要只看 top 1

RAG 通常取 top 3 到 top 10 个文档块，再交给大模型判断。

4. 加 rerank 会更稳

Embedding 负责粗召回，rerank 负责精排。对于客服、法律、财务、技术文档，rerank 能明显减少答非所问。

5. 记录真实查询日志

不要只用 demo 数据测试。把真实用户问题脱敏后做评测，才知道召回是否靠谱。

常见误区

误区 1：embedding 维度越高一定越好

不一定。高维向量通常表达能力更强，但也更占存储和计算。实际项目要看召回效果、延迟和成本。

误区 2：RAG 有了 embedding 就不会胡说

也不对。Embedding 只负责找资料。最终回答是否可靠，还取决于 prompt、上下文质量、模型能力和引用约束。

误区 3：所有文档都适合直接向量化

表格、代码、日志、PDF 扫描件都需要特殊处理。尤其是表格，最好保留结构化字段。

结论：text-embedding-3-large 是 AI 应用的“检索底座”

text-embedding-3-large 不是用来聊天的模型，而是用来理解文本相似度的模型。

它最适合这些场景：

RAG 知识库
语义搜索
多语言检索
推荐系统
文档聚类
文本分类

如果你正在做 AI 客服、企业知识库、文档问答、代码搜索或内容推荐，embedding 模型就是系统的基础层。

你可以通过 OpenAI 兼容接口接入 embeddings API。对于已经使用 OpenAI SDK 的项目，迁移成本很低：改 base_url，换 API key，然后继续使用同样的调用方式。

FAQ

text-embedding-3-large 可以直接回答问题吗？

不可以。它输出的是向量，不是自然语言答案。回答问题通常需要搭配 GPT、Claude、Gemini 等聊天模型。

text-embedding-3-large 适合做 RAG 吗？

适合。它常用于 RAG 的检索阶段，把用户问题和知识库文档转成向量，再找出最相关内容。

text-embedding-3-large 默认多少维？

官方文档显示默认是 3072 维，也可以通过 dimensions 参数降低输出维度。

text-embedding-3-large 和 text-embedding-3-small 怎么选？

如果追求检索质量、多语言效果或生产级 RAG，可以优先测试 large。如果成本敏感或数据量很大，可以先用 small 做基线。

向量数据库是必须的吗？

小规模 demo 可以直接用数组和 cosine similarity。生产环境建议使用向量数据库，例如 pgvector、Qdrant、Milvus 或 Pinecone。

DeepSeek V4 Complete Guide — 1.6T MoE with 1M Context at 73% Lower Cost

Jenny Met — Tue, 19 May 2026 09:30:31 +0000

DeepSeek V4 Complete Guide — 1.6T MoE with 1M Context at 73% Lower Cost

DeepSeek V4 dropped on April 24, 2026, and it's the most efficient open-weight model family we've seen. A 1.6-trillion-parameter Mixture-of-Experts architecture that only activates 49 billion parameters per token, with a 1-million-token context window and inference costs 73% lower than V3.

Here's everything developers need to know.

What's in the V4 Family

Model	Total Params	Active Params	Context	Best For
V4-Pro	1.6T	49B	1M tokens	Advanced reasoning, coding, long agent tasks
V4-Flash	284B	13B	1M tokens	High-speed, cost-efficient workloads
V4 (base)	—	—	1M tokens	General-purpose chat and completion

All three share the 1M-token context window. The Pro model supports three reasoning modes: Non-think (fast), High (default), and Max (deep reasoning).

Architecture: What Changed from V3

The V4 family introduces two key innovations:

Hybrid Attention — Combines Compressed Sparse Attention (CSA) and Heavily Compressed Attention (HCA). At 1M tokens, this reduces:

Per-token inference FLOPs by 73%
KV cache memory by 90%

Compared to DeepSeek V3.2, that's a massive efficiency gain. You can run longer contexts without the cost exploding.

Training Scale — Trained on 32 trillion tokens using FP4 quantization. Both base and instruct versions are available on Hugging Face under an open license.

Hardware Optimization — Optimized for NVIDIA Blackwell, achieving 150+ tokens/sec/user on GB200 NVL72.

Benchmarks

Benchmark	V3.2-Base	V4-Flash-Base	V4-Pro-Base
AGIEval (0-shot)	80.1	82.6	83.1
MMLU (5-shot)	87.8	88.7	90.1

V4-Pro roughly matches GPT-5.4 and Claude Opus 4.6 on most benchmarks, while being significantly cheaper. GPT-5.5 still leads on Terminal-Bench (82.7%) and FrontierMath, but at 10-50x the price.

Pricing

Direct DeepSeek API (with 75% promo discount through May 2026)

Model	Input (per 1M)	Output (per 1M)	Cached Input
V4-Pro	$0.435	$0.87	$0.003625
V4-Flash	$0.14	$0.28	—
V4 (base)	$0.30	$0.50	—

Cost Comparison

Model	Input	Output	Notes
DeepSeek V4-Pro (promo)	$0.435	$0.87	Open-weight, 1M context
DeepSeek V4-Flash (promo)	$0.14	$0.28	Fastest option
GPT-5.5	~$5.00	~$75.00	Closed, 400K context
GPT-5.4	$2.50	$15.00	Closed
Claude Opus 4.6	$3.00	$15.00	Closed

V4-Pro delivers comparable quality at 5-85x lower cost depending on the task and competitor.

API Access via Crazyrouter

Access DeepSeek V4 alongside 300+ other models through a single API key. OpenAI SDK compatible.

from openai import OpenAI

client = OpenAI(
    api_key="your-crazyrouter-key",
    base_url="https://crazyrouter.com/v1"
)

# DeepSeek V4-Pro
response = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[
        {"role": "user", "content": "Analyze this codebase and suggest optimizations..."}
    ],
    max_tokens=4096
)
print(response.choices[0].message.content)

V4-Flash for Speed-Critical Tasks

# Use V4-Flash when latency matters more than depth
response = client.chat.completions.create(
    model="deepseek-v4-flash",
    messages=[
        {"role": "user", "content": "Summarize this document in 3 bullet points."}
    ]
)

Node.js / TypeScript

import OpenAI from 'openai';

const client = new OpenAI({
  apiKey: 'your-crazyrouter-key',
  baseURL: 'https://crazyrouter.com/v1',
});

const response = await client.chat.completions.create({
  model: 'deepseek-v4-pro',
  messages: [{ role: 'user', content: 'Explain the V4 MoE architecture.' }],
});

console.log(response.choices[0].message.content);

cURL

curl https://crazyrouter.com/v1/chat/completions \
  -H "Authorization: Bearer your-crazyrouter-key" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-pro",
    "messages": [{"role": "user", "content": "What makes V4 different from V3?"}]
  }'

When to Use Which Model

Use Case	Recommended Model	Why
Complex reasoning, math, code review	V4-Pro (Max mode)	Deepest reasoning, highest accuracy
General coding, chat, analysis	V4-Pro (High mode)	Good balance of speed and quality
Summarization, classification, routing	V4-Flash	Fastest, cheapest
Long document processing (500K+ tokens)	V4-Pro or V4-Flash	1M context, 90% KV cache reduction
Real-time applications	V4-Flash	150+ tokens/sec on Blackwell

V4 vs R2: Which DeepSeek Model to Choose?

	V4-Pro	R2
Architecture	1.6T MoE, 49B active	32B dense
Strength	General + long context	Pure reasoning
Context	1M tokens	128K tokens
Best for	Coding, agents, long docs	Math, logic, step-by-step
Self-hosting	Needs multi-GPU	Single RTX 4090

Use R2 for pure reasoning tasks. Use V4 for everything else, especially when you need long context.

Getting Started

Sign up at crazyrouter.com
Get your API key from the console
Set base_url to https://crazyrouter.com/v1
Use deepseek-v4-pro or deepseek-v4-flash as the model name
Start building

DeepSeek V4 makes frontier-level AI accessible at a fraction of the cost. Combined with Crazyrouter's unified API, you can switch between V4, GPT-5.5, Claude, and 300+ other models with a single line of code.

DEV Community: Jenny Met

text-embedding-3-large で RAG ナレッジベースを作る：チャンク分割から検索順位付けまで

text-embedding-3-large で RAG ナレッジベースを作る：チャンク分割から検索順位付けまで

RAGシステムの基本構成

ステップ1：ドキュメント準備とチャンク分割

ステップ2：text-embedding-3-large でベクトル化

ステップ3：ベクトルDBに保存

ステップ4：検索時のセマンティック検索

ステップ5：rerankで「的外れ回答」を減らす

ステップ6：検索結果をチャットモデルに渡す

text-embedding-3-large の多言語RAGでの強み

本番運用のためのTips

1. 増分インデックスで効率化

2. バッチembeddingを活用

3. ハイブリッド検索を組み合わせる

4. 回答に出典を明記

5. 権限付き検索

よくあるトラブルと対策

text-embedding-3-large を使わなくてもいいケース

まとめ：RAGの成否は「検索」が半分

FAQ

RAGナレッジベースには必ずtext-embedding-3-largeが必要ですか？

チャンクサイズはどれくらいが最適？

text-embedding-3-largeはpgvectorと組み合わせられますか？

embeddingで資料を見つけたのに、モデルが誤答するのはなぜ？

RAGにrerankは必要？

text-embedding-3-large は使うべき？small とのコスト・品質・選び方

text-embedding-3-large は使うべき？small とのコスト・品質・選び方

まず結論：どう選ぶ？

text-embedding-3-large の強み

text-embedding-3-small が向いているケース

コストはAPI料金だけじゃない

dimensions パラメータの使い方

MTEBスコアだけで選ばない

実践的なA/Bテスト手順

1. 50〜200件の実クエリを用意

2. 正解ドキュメントをアノテーション

3. 複数のインデックスを作成

4. リコール評価を実施

5. large へのアップグレード判断

RAG の品質問題＝embedding モデルのせいとは限らない

OpenAI互換APIでembeddingモデルを切り替える

推奨プロジェクトロードマップ

フェーズ1：MVP

フェーズ2：実データ評価

フェーズ3：本番最適化

結論：large はデフォルトではないが、真剣にテストする価値あり

FAQ

text-embedding-3-large は text-embedding-3-small より必ず優れている？

dimensions を下げると品質は落ちる？

RAG プロジェクトはモデル最適化とチャンク戦略、どちらを優先すべき？

多言語ナレッジベースは text-embedding-3-large が向いている？

Crazyrouter で text-embedding-3-large を使える？

text-embedding-3-large или small: стоимость, качество поиска и выбор для RAG

text-embedding-3-large или small: стоимость, качество поиска и выбор для RAG

Сразу к сути: как выбрать?

Чем силён text-embedding-3-large?

Когда подходит text-embedding-3-small?

Стоимость — это не только цена API

Как использовать параметр dimensions?

Не ориентируйтесь только на MTEB

Как провести A/B тестирование моделей

1. Соберите 50-200 реальных запросов

2. Проставьте правильные ответы

3. Постройте несколько индексов

4. Прогоните тесты на поиск

5. Решите, стоит ли переходить на large

Плохой RAG — не всегда вина embedding-модели

Как переключаться между embedding-моделями через OpenAI-совместимый API

Рекомендуемая дорожная карта проекта

Этап 1: MVP

Этап 2: Реальное тестирование

Этап 3: Оптимизация для продакшна

Вывод: large — не всегда ответ, но тестировать стоит

FAQ

text-embedding-3-large всегда лучше, чем text-embedding-3-small?

Снижение dimensions ухудшает качество?

В RAG-проекте сначала оптимизировать модель или нарезку чанков?

Для многоязычных баз лучше large?

Можно ли вызывать text-embedding-3-large через Crazyrouter?