Patakbuhin ang RAG brain ng Quivr sa isang custom OpenAI-compatible endpoint.

Mabilisang sagot: llm_base_url sa LLMEndpointConfig.

Ang kasalukuyang Quivr ay quivr-core, isang Python RAG library, at malinaw ang wiring ng LLM nito. Nagdadala ang LLMEndpointConfig ng supplier (openai bilang default), model, llm_base_url, at llm_api_key; binubuo ng LLMEndpoint.from_config() ang tunay na client mula sa mga field na iyon, at para sa openai na supplier, ang client na iyon ay ang ChatOpenAI ng LangChain na binuo gamit ang base URL mo. Itakda ang llm_base_url sa https://api.apisrouter.com/v1, itakda ang model sa anumang id ng katalogo, at ipasa ang endpoint sa Brain mo. Ang key ay maaaring manggaling sa config field o sa environment: kapag hindi naitakda ang llm_api_key, nire-resolve ito ng quivr-core mula sa isang environment variable na pinangalanan ayon sa supplier, na para sa openai supplier ay OPENAI_API_KEY. Upstream na behavior ang parehong path, mababasa sa quivr_core/rag/entities/config.py at 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"],
))

Ano na ang Quivr ngayon, at kung saan naninirahan ang LLM slot.

Ang Quivr (QuivrHQ sa GitHub, humigit-kumulang 39K stars) ay nagsimula bilang isang buong aplikasyong second brain at nag-pivot patungo sa quivr-core: isang opinionated na RAG library na ini-embed mo sa sarili mong produkto. Pinapakain mo ito ng mga file, pinapars at pinaghihiwa-hiwalay nito ang mga ito, ini-embed ang mga chunk sa isang vector store (FAISS bilang default, sinusuportahan ang PGVector), at sumasagot ng mga tanong sa kanila sa pamamagitan ng isang configurable na retrieval workflow. Ang Brain object ang unit: ini-ingest ng Brain.from_files() ang mga bagay, kinukuha at nagge-generate ng sagot ang brain.ask(). Ang generation lamang ang hakbang na nangangailangan ng chat model. Nag-iipon ang retrieval workflow ng context mula sa mga dokumento mo, at isinusulat ng LLMEndpoint na ipinasa mo ang naka-ground na sagot. Isang beses lamang binubuo ang endpoint na iyon mula sa LLMEndpointConfig, kaya ang desisyon sa base URL ay ginagawa sa oras ng construction at naaangkop sa bawat ask() sa brain na iyon. Dahil ipinapasa ng ChatOpenAI ang model field bilang plain string sa pamamagitan ng /v1/chat/completions, maaaring Claude, DeepSeek, GPT, o Gemini ang id kapag si-serve ang mga ito ng endpoint sa likod ng llm_base_url. Isang tapat na tala sa status ng proyekto: tahimik na ang repository mula noong kalagitnaan ng 2025, kaya ituring ang quivr-core bilang isang matatag na library sa halip na isang mabilis na gumagalaw. Tumutugma ang config surface na inilarawan dito sa pinakabagong main branch, at ang tahimik na kasaysayan ay nangangahulugang malabong magbago ito nang biglaan; nangangahulugan din itong hindi na tumutugma ang mga lumang tutorial na naglalarawan ng retiradong buong-stack na app (backend .env files, isang hosted na frontend).

Buong setup: isang brain na may LLM na niruruta sa gateway.

Ipinapasa ng kumpletong pattern ang na-configure na LLMEndpoint sa Brain.from_files. Independiyente sa LLM endpoint ang lahat ng iba pa tungkol sa brain (parsing, chunking, ang FAISS store, ang retrieval workflow) at pinapanatili nito ang mga default nito. Alalahanin ang embedder. Kung hindi ka magpasa ng isa, binubuo ng quivr-core ang OpenAIEmbeddings ng LangChain gamit ang sarili nitong mga default, na nagpapatunay gamit ang OPENAI_API_KEY at tumutukoy sa stock na endpoint ng OpenAI. Hiwalay na client ito mula sa chat LLM: hindi ito iginagalaw ng pag-route ng generation sa pamamagitan ng gateway. Magpasa ng sarili mong embedder (isang local na sentence-transformers wrapper, o anumang LangChain Embeddings instance na ini-configure mo) kung ayaw mong nakadepende sa isang OpenAI account ang kalahati ng embedding.

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)

Pagpili ng generation model para sa mga sagot ng RAG.

Isang pagbabago sa oras ng construction ang paghahambing ng mga kandidato: bumuo ng dalawang LLMEndpoint laban sa parehong base URL, dalawang brain sa ibabaw ng parehong mga file, at i-diff ang mga sagot sa isang fixed na set ng tanong. Pinepresyuhan ng per-key usage log ang bawat run ng kandidato, kaya sinusukat ang kalidad per token sa halip na pagtatalunan.

• Input-heavy ang generation ng RAG: naghahari sa prompt ang retrieved chunks. Itinatakda ng presyo per input token ang gastos ng isang sagot, kaya kalahatiin ng isang mabilis na id ang bill nang hindi hinihipo ang kalidad ng retrieval.
• Ang claude-sonnet-4-6 ang maaasahang default para sa mga naka-ground na sagot na gumagalang sa retrieved context at maayos na tumatanggi kapag walang sagot ang mga dokumento.
• Gumaganang maayos sa claude-haiku-4-5-20251001, deepseek-v4-flash, o gemini-3.5-flash ang mga high-volume na embedded na produkto (ang inilarawang use case ng Quivr) para sa pang-araw-araw na pagsasanib ng tanong.
• Kinokontrol ng max_context_tokens sa parehong config kung gaano karaming retrieved context ang ipinapapaloob ng pipeline; naaangkop nang natural ang pagtaas nito sa mga long-context na id at nagpapataas nang proporsyonal sa gastos ng input.
• Nagbabalik sa isang generic na tokenizer para sa budgeting ang mga hindi kilalang model prefix, na kosmetiko lamang; dala pa rin ng request ang id mo nang walang pagbabago patungo sa endpoint.

Pay-as-you-go · mas mababa sa opisyal na presyo

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

Mga pagwawasto sa karaniwang alamat tungkol sa Quivr.

Naglalarawan ang mga gabay na kumakalat ng mga surface na wala na ngayon ang Quivr, kaya sulit sabihin kung ano talaga ang ginagawa ng kasalukuyang code. Hindi LiteLLM-backed ang quivr-core, LangChain-backed ito. Pinipili ng supplier enum ang isang LangChain chat class, at ang openai ay napupunta sa ChatOpenAI kasama ang llm_base_url mo. Kung sinasabi sa iyo ng isang tutorial na mag-configure ng isang LiteLLM proxy o api_base setting sa loob ng Quivr, inilalarawan nito ang mas lumang architecture; llm_base_url sa LLMEndpointConfig ang kasalukuyang field. Retirado na ang buong-stack na app. Tumutukoy ang mga instruksyon tungkol sa isang backend .env, setup ng Supabase, o isang in-app na model picker sa aplikasyon bago ang pivot, na hindi na ang ipinapadala ng repository. Nangyayari na ngayon ang configuration sa Python code mo (o sa sarili mong app sa paligid ng library). Supplier-derived ang key env var. Para sa supplier openai, OPENAI_API_KEY ito, kahit hindi OpenAI ang endpoint. Kung ayaw mong i-overload ang pangalang iyon, magpasa nang tahasan ng llm_api_key sa config, na mananalo at pinapanatiling malinis ang environment. Hiwalay ang embedder. Hindi iginagalaw ng pag-route ng generation ang embeddings; ang default na embedder ay isang OpenAIEmbeddings na may sariling credentials. Magdesisyon nang hiwalay sa dalawang kalahati, at ang muling pag-embed ng umiiral na store ay kailangan lamang kung babaguhin mo ang embedding model mismo.

Sino ang nagru-route ng quivr-core sa pamamagitan ng isang gateway.

• Mga product team na nag-e-embed ng RAG sa mga app nila na gustong maging config value ang generation model, hindi isang vendor commitment na nakabaon sa stack.
• Mga developer na nagpapatakbo ng maraming brain sa magkaibang quality tier: isang key, isang endpoint, model id per brain.
• Mga team na gustong makuha ang Claude-quality na naka-ground na sagot sa likod ng isang OpenAI-shaped na config nang hindi nagdaragdag ng ikalawang SDK o provider account.
• Mga builder na nagbebenchmark ng generation models sa fixed na corpus, kung saan ang bawat kandidato ay isang pagbabago sa LLMEndpointConfig.
• Mga developer na walang access sa billing ng isang partikular na vendor. Ang top-up based na access na walang kailangang card ay inaalis ang per-provider na sign-up dependency.

I-verify ang endpoint at i-debug ang unang ask().

Kumpirmahin munang nakalista sa gateway ang model mo bago mag-ingest ng kahit ano; dapat eksaktong tumugma ang model field sa isang si-serve na id. Mahuhulaan ang mga kabiguan sa unang run. Nangangahulugan ang isang babala na hindi naitakda ang API key para sa supplier openai na wala sa llm_api_key ni OPENAI_API_KEY ang nakikita nang binuo ang config; nangyayari ang babala sa construction, ang kabiguan sa unang ask(). Nangangahulugang hindi kabilang sa endpoint sa llm_base_url ang na-resolve na key ang isang 401. Ang isang model-not-found na error ay isang typo sa id laban sa /v1/models. At ang isang authentication error na may kinalaman sa embedding sa panahon ng Brain.from_files ay ang hiwalay na default na embedder na humihiling ng sarili nitong OpenAI credentials, na walang llm_base_url setting na mag-aayos; magpasa ng embedder na kontrolado mo. Kapag dumadaloy na ang mga sagot, ipinapakita ng APIsRouter console ang per-request na model, token counts, at gastos. Para sa isang library na nagpapapaloob ng retrieved chunks sa bawat prompt, ang numero ng tokens-per-answer sa tunay mong corpus ang dapat magdirekta sa pagpili mo ng model.

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

Mga madalas itanong