Quivr の RAG ブレインを、カスタムの OpenAI 互換エンドポイントで動かす。

早わかり: LLMEndpointConfig の llm_base_url。

現行の Quivr は quivr-core であり、Python 製の RAG ライブラリです。その LLM の配線は明示的です。LLMEndpointConfig は supplier(デフォルトは openai)、model、llm_base_url、llm_api_key を持ち、LLMEndpoint.from_config() がそれらのフィールドから実際のクライアントを構築します。openai の supplier の場合、そのクライアントは、あなたの base URL で構築された LangChain の ChatOpenAI です。llm_base_url を https://api.apisrouter.com/v1 に設定し、model を任意のカタログの id に設定し、そのエンドポイントをあなたの Brain に渡します。 キーは、設定フィールドか環境変数のどちらからでも来ます。llm_api_key が設定されていない場合、quivr-core は、supplier にちなんで名付けられた環境変数からそれを解決します。openai の supplier の場合、それは OPENAI_API_KEY です。どちらの経路も upstream の挙動であり、quivr_core/rag/entities/config.py と quivr_core/llm/llm_endpoint.py で読めます。

from quivr_core.llm import LLMEndpoint
from quivr_core.rag.entities.config import (
    DefaultModelSuppliers, LLMEndpointConfig)

llm = LLMEndpoint.from_config(LLMEndpointConfig(
    supplier=DefaultModelSuppliers.OPENAI,
    model="claude-sonnet-4-6",          # any catalog id
    llm_base_url="https://api.apisrouter.com/v1",
    llm_api_key=os.environ["APISROUTER_API_KEY"],
))

Quivr が今どうなっているか、そして LLM のスロットがどこにあるか。

Quivr(GitHub 上では QuivrHQ、スター数はおよそ39K)は、フル機能のセカンドブレインアプリケーションとして始まり、quivr-core へと方向転換しました。あなた自身のプロダクトに組み込む、一家言のある RAG ライブラリです。ファイルを与えると、それをパースしてチャンクに分け、チャンクをベクトルストア(デフォルトは FAISS、PGVector にも対応)に埋め込み、設定可能な検索ワークフローを通じてそれらについての質問に答えます。Brain オブジェクトが単位です。Brain.from_files() が取り込み、brain.ask() が検索と生成を行います。 生成だけが、チャットモデルを必要とするステップです。検索ワークフローがあなたのドキュメントから文脈を組み立て、あなたが渡した LLMEndpoint がグラウンデッドな回答を書きます。そのエンドポイントは LLMEndpointConfig から一度だけ構築されるため、base URL の決定は構築時に行われ、その brain のすべての ask() に適用されます。ChatOpenAI は model フィールドを、/v1/chat/completions を通じてプレーンな文字列として転送するため、llm_base_url の背後にあるエンドポイントがそれらを提供している限り、id は Claude・DeepSeek・GPT・Gemini になり得ます。 プロジェクトの状況について正直な注記が1つあります。このリポジトリは2025年半ば以降静かで、quivr-core は、速く動くライブラリというよりは安定したライブラリとして扱うべきです。ここで説明した設定面は最新の main ブランチと一致しており、この静けさは、あなたの足元でそれが変わりにくいことも意味します。また同時に、退役したフルスタックアプリ(バックエンドの .env ファイル、ホスト型フロントエンド)を説明する古いチュートリアルが、もはやコードと一致しないことも意味します。

フルセットアップ: ゲートウェイ経由の LLM を持つ brain。

完全なパターンは、設定済みの LLMEndpoint を Brain.from_files に渡します。brain に関するそれ以外のすべて(パース、チャンク分割、FAISS ストア、検索ワークフロー)は、LLM エンドポイントとは独立しており、デフォルトのままです。 エンベダーに注意してください。何も渡さない場合、quivr-core は、自身のデフォルトを持つ LangChain の OpenAIEmbeddings を構築し、OPENAI_API_KEY で認証し、標準の OpenAI エンドポイントを対象にします。これはチャット用の LLM とは別のクライアントであり、生成をゲートウェイ経由にルーティングしても、これは動きません。エンベディングの半分を OpenAI アカウントに依存させたくない場合は、自分自身のエンベダー(ローカルの sentence-transformers ラッパー、あるいは自分で設定する任意の LangChain Embeddings インスタンス)を渡してください。

import os
from quivr_core import Brain
from quivr_core.llm import LLMEndpoint
from quivr_core.rag.entities.config import (
    DefaultModelSuppliers, LLMEndpointConfig)

llm = LLMEndpoint.from_config(LLMEndpointConfig(
    supplier=DefaultModelSuppliers.OPENAI,
    model="claude-sonnet-4-6",
    llm_base_url="https://api.apisrouter.com/v1",
    llm_api_key=os.environ["APISROUTER_API_KEY"],
    max_output_tokens=2048,
    temperature=0.3,
))

brain = Brain.from_files(
    name="team-docs",
    file_paths=["handbook.pdf", "runbook.md"],
    llm=llm,
    # embedder=...  # separate component; see note above
)

print(brain.ask("What is the on-call escalation policy?").answer)

RAG の回答向けの生成モデル選び。

候補の比較は、構築時の変更で済みます。同じ base URL に対して2つの LLMEndpoint を構築し、同じファイルに対して2つの brain を作り、固定の質問セットで回答を diff してください。キーごとの利用ログが各候補の実行に価格をつけるため、トークンあたりの品質は、議論するのではなく測定できます。

• RAG の生成は入力量の多い作業です。検索されたチャンクがプロンプトを支配します。入力トークンあたりの価格が回答のコストを決めるため、速い id は、検索の品質に触れることなく請求額を半減させることがよくあります。
• claude-sonnet-4-6 は、検索された文脈を尊重し、ドキュメントに回答が含まれていない場合はきれいに答えを拒否する、グラウンデッドな回答向けの信頼できるデフォルトです。
• 高ボリュームの組み込み型プロダクト(Quivr が明言するユースケース)は、日常的な質問の構成において、claude-haiku-4-5-20251001、deepseek-v4-flash、gemini-3.5-flash でよく機能します。
• 同じ設定にある max_context_tokens は、パイプラインがどれだけの検索済み文脈を詰め込むかを支配します。これを引き上げることは、長文脈対応の id と自然に組み合わさり、入力の支出をそれに比例して引き上げます。
• 未知のモデルプレフィックスは、予算計算のために汎用的なトークナイザーにフォールバックしますが、これは見た目だけの問題です。リクエスト自体は、あなたの id をそのままエンドポイントに運びます。

従量課金 · 公式価格より安い

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

よくある Quivr の言い伝えへの訂正。

出回っているガイドは、Quivr がもはや持っていない面を説明しているため、現行のコードが実際に何をするのかを明記する価値があります。 quivr-core は LiteLLM ではなく LangChain に支えられています。supplier の enum が LangChain のチャットクラスを選び、openai は、あなたの llm_base_url を持つ ChatOpenAI にマッピングされます。チュートリアルが、Quivr の中で LiteLLM のプロキシや api_base の設定をするよう指示している場合、それは古いアーキテクチャを説明しています。現行のフィールドは、LLMEndpointConfig の llm_base_url です。 フルスタックのアプリは退役しました。バックエンドの .env、Supabase のセットアップ、アプリ内のモデルピッカーについての説明は、方向転換前のアプリケーションを指しており、それはもはやこのリポジトリが出荷するものではありません。設定は今や、あなたの Python コード(あるいはライブラリを取り巻くあなた自身のアプリ)の中で行われます。 キーの環境変数は supplier から導出されます。supplier が openai の場合、それは OPENAI_API_KEY です。エンドポイントが OpenAI でなくてもです。その名前を使い回したくない場合は、設定に llm_api_key を明示的に渡してください。それが優先され、環境変数をきれいに保てます。 エンベダーは別物です。生成のルーティングはエンベディングを動かしません。デフォルトのエンベダーは、自身の認証情報を持つ OpenAIEmbeddings です。この2つの半分は独立して決めてください。既存のストアの再エンベディングが必要になるのは、エンベディングモデル自体を変更する場合だけです。

ゲートウェイ経由で quivr-core を使うのは誰か。

• 自身のアプリに RAG を組み込むプロダクトチームで、生成モデルが、スタックに焼き込まれたベンダーへのコミットメントではなく、設定値であることを求める人。
• 異なる品質ティアで多数の brain を運用する開発者。キーは1つ、エンドポイントも1つ、brain ごとにモデル id です。
• 二つ目の SDK やプロバイダーアカウントを追加することなく、OpenAI の形をした設定の裏側で Claude 級のグラウンデッドな回答を求めるチーム。
• 固定のコーパスに対して生成モデルをベンチマークするビルダーで、各候補が1つの LLMEndpointConfig の変更で済む人。
• 特定ベンダーの請求手段にアクセスできない開発者。チャージ制でカード不要のアクセスなら、プロバイダーごとのサインアップという依存を取り除けます。

エンドポイントを検証し、最初の ask() をデバッグする。

何かを取り込む前に、ゲートウェイがあなたのモデルを一覧しているか確認してください。model フィールドは、提供されている id と正確に一致していなければなりません。 初回実行の失敗は予測可能です。supplier openai の API key が設定されていないという警告は、設定が構築された時点で llm_api_key も OPENAI_API_KEY も見えていなかったということです。警告は構築時に発生し、失敗は最初の ask() で起きます。401 は、解決されたキーが llm_base_url のエンドポイントに属していないということです。model-not-found エラーは、/v1/models に対する id のタイプミスです。そして Brain.from_files の間に発生するエンベディング関連の認証エラーは、別物のデフォルトエンベダーが自身の OpenAI 認証情報を求めているということであり、llm_base_url の設定では一切解決しません。自分で制御するエンベダーを渡してください。 回答が流れ始めたら、APIsRouter コンソールがリクエストごとのモデル、トークン数、支出を表示します。すべてのプロンプトに検索済みのチャンクを詰め込むライブラリにとって、あなたの実際のコーパスにおける回答あたりのトークン数こそが、モデル選択を左右すべき数字です。

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

よくある質問