Quivr کا RAG brain ایک custom OpenAI-compatible endpoint پر چلائیں۔
Updated 2026-07-29
quivr-core کا LLMEndpointConfig ایک llm_base_url field لیتا ہے۔ supplier کو openai رہنے دیں، llm_base_url کو https://api.apisrouter.com/v1 پر سیٹ کریں، ایک key pass کریں، اور ہر brain.ask() اپنا جواب کسی بھی کیٹلاگ model id کے ساتھ gateway کے ذریعے پیدا کرتا ہے۔
فوری جواب: LLMEndpointConfig میں llm_base_url۔
موجودہ Quivr quivr-core ہے، ایک Python RAG library، اور اس کی LLM wiring واضح ہے۔ LLMEndpointConfig supplier (default طور پر openai)، model، llm_base_url، اور llm_api_key رکھتا ہے؛ LLMEndpoint.from_config() انہی fields سے اصل client بناتا ہے، اور openai supplier کے لیے وہ client آپ کے base URL کے ساتھ بنایا گیا LangChain کا ChatOpenAI ہے۔ llm_base_url کو https://api.apisrouter.com/v1 پر سیٹ کریں، model کو کسی بھی کیٹلاگ id پر، اور endpoint اپنی Brain کے حوالے کر دیں۔ key یا تو config field سے یا environment سے آ سکتی ہے: جب llm_api_key سیٹ نہ ہو، quivr-core اسے supplier کے نام پر مبنی ایک environment variable سے resolve کرتا ہے، جو 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 slot کہاں بیٹھتا ہے۔
Quivr (GitHub پر QuivrHQ، تقریباً 39K stars) ایک مکمل second-brain application کے طور پر شروع ہوا اور quivr-core کی طرف pivot کیا: ایک opinionated RAG library جسے آپ اپنے product میں embed کرتے ہیں۔ آپ اسے files کھلاتے ہیں، یہ انہیں parse اور chunk کرتا ہے، chunks کو ایک vector store میں embed کرتا ہے (default طور پر FAISS، PGVector سپورٹڈ)، اور ایک configurable retrieval workflow کے ذریعے ان پر سوالات کا جواب دیتا ہے۔ Brain object یونٹ ہے: Brain.from_files() ingest کرتا ہے، brain.ask() retrieve اور generate کرتا ہے۔ Generation واحد step ہے جسے chat model چاہیے۔ Retrieval workflow آپ کے documents سے context جمع کرتا ہے، اور آپ کا دیا گیا LLMEndpoint grounded جواب لکھتا ہے۔ وہ endpoint ایک بار LLMEndpointConfig سے بنایا جاتا ہے، تو base URL فیصلہ construction کے وقت ہوتا ہے اور اس brain کے ہر ask() پر لاگو ہوتا ہے۔ چونکہ ChatOpenAI model field کو /v1/chat/completions پر plain string کے طور پر forward کرتا ہے، id Claude، DeepSeek، GPT، یا Gemini ہو سکتی ہے جب llm_base_url کے پیچھے موجود endpoint انہیں serve کرے۔ Project status پر ایک ایماندار نوٹ: repository mid-2025 سے خاموش ہے، تو quivr-core کو ایک مستحکم library سمجھیں، تیزی سے بدلنے والی نہیں۔ یہاں بیان کردہ config surface latest main branch سے میچ کرتا ہے، اور یہ خاموش تاریخ کا مطلب ہے کہ آپ کے نیچے سے بدلنے کا امکان کم ہے؛ اس کا یہ بھی مطلب ہے کہ retired full-stack app (backend .env files، ایک hosted frontend) بیان کرنے والے پرانے tutorials اب code سے میچ نہیں کرتے۔
مکمل سیٹ اپ: gateway-routed LLM والی ایک brain۔
مکمل pattern configure کیے گئے LLMEndpoint کو Brain.from_files میں pass کرتا ہے۔ باقی سب کچھ brain کے بارے میں (parsing، chunking، FAISS store، retrieval workflow) LLM endpoint سے خودمختار ہے اور اپنے defaults رکھتا ہے۔ Embedder کا خیال رکھیں۔ اگر آپ ایک pass نہیں کرتے، quivr-core LangChain کا OpenAIEmbeddings اپنے defaults کے ساتھ بناتا ہے، جو OPENAI_API_KEY سے authenticate ہوتا ہے اور stock OpenAI endpoint کو target کرتا ہے۔ یہ chat LLM سے الگ client ہے: generation کو gateway کے ذریعے route کرنا اسے move نہیں کرتا۔ اگر آپ نہیں چاہتے کہ embedding والا آدھا حصہ OpenAI account پر منحصر ہو تو اپنا خود کا embedder pass کریں (ایک local sentence-transformers wrapper، یا کوئی بھی LangChain Embeddings instance جسے آپ configure کریں)۔
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 جوابات کے لیے generation model چننا۔
Candidates compare کرنا ایک construction-time تبدیلی ہے: ایک ہی base URL کے خلاف دو LLMEndpoints بنائیں، ایک ہی files پر دو brains، اور ایک fixed question set پر جوابات کا diff کریں۔ Per-key usage log ہر candidate run کی قیمت لگاتا ہے، تو quality-per-token بحث کی بجائے ماپی جاتی ہے۔
- RAG generation input-heavy ہے: retrieved chunks prompt پر حاوی ہوتے ہیں۔ فی-input-token قیمت جواب کی cost طے کرتی ہے، یہی وجہ ہے کہ ایک تیز id اکثر retrieval quality چھوئے بغیر bill کو آدھا کر دیتی ہے۔
- claude-sonnet-4-6 grounded جوابات کے لیے قابلِ اعتماد default ہے جو retrieved context کا احترام کریں اور صاف طریقے سے انکار کریں جب documents میں جواب موجود نہ ہو۔
- زیادہ-volume والے embedded products (Quivr کا بیان کردہ use case) روزمرہ سوالات کے mix کے لیے claude-haiku-4-5-20251001، deepseek-v4-flash، یا gemini-3.5-flash پر اچھی طرح چلتے ہیں۔
- اسی config میں max_context_tokens اس بات کو کنٹرول کرتا ہے کہ pipeline کتنا retrieved context پیک کرے؛ اسے بڑھانا فطری طور پر long-context ids کے ساتھ جوڑا بنتا ہے اور input spend کو تناسب سے بڑھاتا ہے۔
- Unknown model prefixes budgeting کے لیے ایک generic tokenizer پر fallback کرتے ہیں، جو صرف cosmetic ہے؛ request خود آپ کی id کو بغیر بدلے endpoint تک لے جاتی ہے۔
استعمال کے مطابق ادائیگی · سرکاری قیمت سے کم
Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.
| ماڈل | سرکاری قیمت | ہماری قیمت |
|---|---|---|
| Claude Sonnet 4.6 | $3.00 / $15.00 per M | $2.40 / $12.00 per M |
| Claude Haiku 4.5 20251001 | $1.00 / $5.00 per M | $0.80 / $4.00 per M |
| GPT-5.4 mini | $0.75 / $4.50 per M | $0.60 / $3.60 per M |
| DeepSeek V4 Flash | $0.14 / $0.28 per M | $0.10 / $0.30 per M |
| Gemini 3.5 Flash | $1.50 / $9.00 per M | $1.20 / $7.20 per M |
عام Quivr lore کی تصحیحات۔
Circulation میں موجود guides ایسی surfaces بیان کرتی ہیں جو Quivr کے پاس اب نہیں ہیں، تو یہ بیان کرنے کے قابل ہے کہ موجودہ code واقعی کیا کرتا ہے۔ quivr-core LangChain-backed ہے، LiteLLM-backed نہیں۔ Supplier enum ایک LangChain chat class منتخب کرتا ہے، اور openai آپ کے llm_base_url کے ساتھ ChatOpenAI میں map ہوتا ہے۔ اگر کوئی tutorial آپ کو Quivr کے اندر ایک LiteLLM proxy یا api_base setting configure کرنے کو کہے، تو یہ ایک پرانا architecture بیان کر رہا ہے؛ موجودہ field LLMEndpointConfig پر llm_base_url ہے۔ Full-stack app retired ہو چکی ہے۔ backend .env، Supabase setup، یا in-app model picker کے بارے میں instructions pre-pivot application کا حوالہ دیتی ہیں، جو اب repository ship نہیں کرتا۔ Configuration اب آپ کے Python code میں (یا library کے ارد گرد آپ کی اپنی app میں) ہوتی ہے۔ Key env var supplier-derived ہے۔ openai supplier کے لیے یہ OPENAI_API_KEY ہے، چاہے endpoint OpenAI نہ ہو۔ اگر آپ اس نام کو overload نہیں کرنا چاہتے، تو config میں صراحتاً llm_api_key pass کریں، جو ترجیح رکھتا ہے اور environment کو صاف رکھتا ہے۔ Embedder الگ ہے۔ Generation routing embeddings کو move نہیں کرتی؛ default embedder اپنی credentials کے ساتھ OpenAIEmbeddings ہے۔ دونوں آدھے حصوں کا فیصلہ خودمختار طور پر کریں، اور موجودہ store کو دوبارہ embed کرنا صرف تب ضروری ہے جب آپ embedding model خود بدلیں۔
quivr-core کو gateway کے ذریعے کون route کرتا ہے۔
- وہ product teams جو اپنی apps میں RAG embed کرتی ہیں اور جو چاہتی ہیں کہ generation model ایک config value ہو، stack میں baked ایک vendor commitment نہیں۔
- وہ developers جو مختلف quality tiers پر بہت سی brains چلاتے ہیں: ایک key، ایک endpoint، فی brain model id۔
- وہ teams جو ایک OpenAI-shaped config کے پیچھے Claude-quality grounded جوابات چاہتی ہیں بغیر ایک دوسرا SDK یا provider account شامل کیے۔
- وہ builders جو ایک fixed corpus پر generation models کو benchmark کرتے ہیں، جہاں ہر candidate ایک LLMEndpointConfig تبدیلی ہے۔
- وہ developers جن کے پاس کسی مخصوص vendor کی billing تک رسائی نہیں۔ Top-up پر مبنی رسائی بغیر کارڈ کی شرط کے فی-provider sign-up کا انحصار ختم کر دیتی ہے۔
Endpoint verify کریں اور پہلا ask() debug کریں۔
کچھ بھی ingest کرنے سے پہلے تصدیق کریں کہ gateway آپ کا model list کرتا ہے؛ model field کو ایک serve کی گئی id سے بالکل میچ ہونا چاہیے۔ پہلی-run کی failures قابلِ پیش گوئی ہیں۔ ایک warning کہ supplier openai کے لیے API key سیٹ نہیں ہے مطلب config بناتے وقت نہ llm_api_key نظر آئی نہ OPENAI_API_KEY؛ warning construction پر ہوتی ہے، failure پہلے ask() پر۔ ایک 401 کا مطلب ہے resolved key llm_base_url والے endpoint سے تعلق نہیں رکھتی۔ ایک model-not-found error /v1/models کے خلاف ایک id typo ہے۔ اور Brain.from_files کے دوران ایک embedding-related authentication error الگ default embedder کی اپنی OpenAI credentials مانگنے کا مسئلہ ہے، جسے کوئی llm_base_url setting ٹھیک نہیں کرے گی؛ وہ embedder pass کریں جسے آپ کنٹرول کریں۔ جب جوابات چلنے لگیں، APIsRouter console per-request model، token counts، اور spend دکھاتا ہے۔ ایسی library کے لیے جو ہر prompt میں retrieved chunks پیک کرے، آپ کے حقیقی corpus پر فی-جواب tokens کا عدد وہی ہے جو آپ کے model choice کو چلانا چاہیے۔
curl -s https://api.apisrouter.com/v1/models \
-H "Authorization: Bearer $APISROUTER_API_KEY" | head -50عمومی سوالات
کیا Quivr custom OpenAI-compatible base URL کو سپورٹ کرتا ہے؟
جی ہاں۔ quivr-core کے LLMEndpointConfig میں ایک llm_base_url field ہے، اور openai supplier کے لیے library اسی URL کے خلاف LangChain کا ChatOpenAI بناتی ہے۔ اسے gateway endpoint پر سیٹ کریں اور کوئی بھی کیٹلاگ model id pass کریں۔
کیا Quivr LiteLLM پر مبنی ہے؟
موجودہ codebase میں نہیں۔ quivr-core supplier کے حساب سے LangChain chat classes منتخب کرتا ہے؛ openai supplier آپ کے llm_base_url کے ساتھ ChatOpenAI استعمال کرتا ہے۔ Quivr کے اندر ایک LiteLLM api_base بیان کرنے والی guides ایک پرانے architecture کا حوالہ دیتی ہیں۔
کیا brain.ask() Claude یا DeepSeek models سے جواب دے سکتا ہے؟
جی ہاں۔ model field کو /v1/chat/completions پر plain string کے طور پر forward کیا جاتا ہے، تو claude-sonnet-4-6، deepseek-v4-flash، یا endpoint کی serve کردہ کوئی بھی دوسری id openai supplier کے تحت کام کرتی ہے۔
کون سی environment variable key رکھتی ہے؟
جب config میں llm_api_key سیٹ نہ ہو، quivr-core supplier کے نام سے variable derive کرتا ہے: openai supplier کے لیے OPENAI_API_KEY۔ LLMEndpointConfig میں ایک صریح llm_api_key ترجیح رکھتی ہے اور اس نام کو overload ہونے سے بچاتی ہے۔
کیا llm_base_url embeddings کو بھی move کرتا ہے؟
نہیں۔ Default embedder ایک الگ OpenAIEmbeddings client ہے جس کی اپنی credentials اور endpoint ہیں۔ Generation کو gateway کے ذریعے route کریں اور اگر آپ چاہتے ہیں کہ embedding والا آدھا حصہ بھی OpenAI سے ہٹ جائے تو اپنا خود کا embedder pass کریں۔
کیا Quivr project اب بھی maintained ہے؟
Repository mid-2025 سے خاموش ہے، تو اسے ایک مستحکم library سمجھیں، active نہیں۔ یہاں documented llm_base_url surface latest main branch سے میچ کرتا ہے، اور جس pre-pivot full-stack app کی جگہ اس نے لی وہ retired ہو چکی ہے۔