הריצו את מוח ה-RAG של Quivr על endpoint תואם OpenAI מותאם אישית.

תשובה מהירה: llm_base_url ב-LLMEndpointConfig.

Quivr הנוכחי הוא quivr-core, ספריית Python ל-RAG, וחיווט ה-LLM שלה מפורש. LLMEndpointConfig נושא supplier (openai כברירת מחדל), model, llm_base_url, ו-llm_api_key; LLMEndpoint.from_config() בונה את ה-client האמיתי מהשדות האלה, ועבור ה-supplier openai ה-client הזה הוא ChatOpenAI של LangChain שנבנה עם ה-base URL שלכם. הגדירו llm_base_url ל-https://api.apisrouter.com/v1, הגדירו model לכל id בקטלוג, ומסרו את ה-endpoint ל-Brain שלכם. המפתח יכול להגיע משדה ה-config או מהסביבה: כש-llm_api_key לא מוגדר, quivr-core פותר אותו ממשתנה סביבה שנקרא על שם ה-supplier, שעבור ה-supplier openai הוא 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 (QuivrHQ ב-GitHub, כ-39K כוכבים) התחיל כאפליקציית מוח-שני מלאה ועבר ל-quivr-core: ספריית RAG בעלת דעה שאתם מטמיעים במוצר שלכם. אתם מזינים לה קבצים, היא מנתחת ומחלקת אותם, מטמיעה את המקטעים ל-vector store (FAISS כברירת מחדל, PGVector נתמך), ועונה על שאלות עליהם דרך זרימת אחזור הניתנת להגדרה. אובייקט ה-Brain הוא היחידה: Brain.from_files() מבצע אינגסטיה, brain.ask() מאחזר ומייצר. יצירה היא השלב היחיד שצריך מודל צ'אט. זרימת האחזור מרכיבה הקשר מהמסמכים שלכם, וה-LLMEndpoint שהעברתם כותב את התשובה המעוגנת. ה-endpoint הזה נבנה פעם אחת מ-LLMEndpointConfig, אז החלטת ה-base URL מתקבלת בזמן הבנייה וחלה על כל ask() על אותו brain. מכיוון ש-ChatOpenAI מעביר את שדה ה-model כמחרוזת פשוטה דרך /v1/chat/completions, ה-id יכול להיות Claude, DeepSeek, GPT, או Gemini כש-endpoint מאחורי llm_base_url משרת אותם. הערה כנה אחת על מצב הפרויקט: המאגר שקט מאמצע 2025, אז התייחסו ל-quivr-core כספרייה יציבה ולא מהירת-תזוזה. משטח ההגדרה המתואר כאן תואם ל-main branch העדכני, וההיסטוריה השקטה אומרת שסביר שהוא לא ישתנה מתחתיכם; זה גם אומר שמדריכים ישנים שמתארים את אפליקציית ה-full-stack שנפרשה (קבצי .env של backend, frontend מאוחסן) כבר לא תואמים לקוד.

הגדרה מלאה: brain עם LLM מנותב דרך gateway.

התבנית המלאה מעבירה את ה-LLMEndpoint שהוגדר ל-Brain.from_files. כל השאר לגבי ה-brain (ניתוח, חלוקה, מאגר ה-FAISS, זרימת האחזור) עצמאי מ-endpoint ה-LLM ושומר על ברירות המחדל שלו. שימו לב ל-embedder. אם אתם לא מעבירים אחד, quivr-core בונה את OpenAIEmbeddings של LangChain עם ברירות המחדל שלה, שמאמת עם OPENAI_API_KEY ומכוון ל-endpoint המקורי של OpenAI. זה client נפרד מה-LLM של הצ'אט: ניתוב יצירה דרך ה-gateway לא מזיז אותו. העבירו embedder משלכם (עטיפת sentence-transformers מקומית, או כל מופע Embeddings של LangChain שאתם מגדירים) אם אתם לא רוצים שהמחצית של ה-embedding תהיה תלויה בחשבון OpenAI.

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.

השוואת מועמדים היא שינוי בזמן-בנייה: בנו שני LLMEndpoints מול אותו base URL, שני brains על אותם קבצים, והשוו את התשובות על קבוצת שאלות קבועה. לוג השימוש לפי מפתח מתמחר כל הרצת מועמד, כך שאיכות-לטוקן נמדדת במקום להתווכח עליה.

• יצירת RAG עתירת-קלט: מקטעים מאוחזרים שולטים ב-prompt. מחיר לטוקן-קלט קובע את עלות התשובה, וזו הסיבה ש-id מהיר לעיתים קרובות חוצה את החשבון בלי לגעת באיכות האחזור.
• claude-sonnet-4-6 היא ברירת המחדל האמינה לתשובות מעוגנות שמכבדות את ההקשר המאוחזר ומסרבות בנקיות כשהמסמכים לא מכילים את התשובה.
• מוצרים מוטמעים בנפח גבוה (מקרה השימוש המוצהר של Quivr) רצים היטב על claude-haiku-4-5-20251001, deepseek-v4-flash, או gemini-3.5-flash עבור תמהיל השאלות היומיומי.
• max_context_tokens באותה הגדרה שולט בכמה הקשר מאוחזר הצינור דוחס; העלאתו משתלבת באופן טבעי עם ids בהקשר-ארוך ומעלה את ההוצאה על קלט באופן פרופורציונלי.
• קידומות מודל לא ידועות נופלות חזרה ל-tokenizer גנרי לתקצוב, מה שקוסמטי; הבקשה עצמה נושאת את ה-id שלכם ללא שינוי אל ה-endpoint.

תשלום לפי שימוש · מתחת למחיר הרשמי

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 מבוסס LangChain, לא LiteLLM. ה-enum של ה-supplier בוחר מחלקת צ'אט של LangChain, ו-openai ממופה ל-ChatOpenAI עם ה-llm_base_url שלכם. אם מדריך אומר לכם להגדיר proxy של LiteLLM או הגדרת api_base בתוך Quivr, הוא מתאר ארכיטקטורה ישנה יותר; השדה הנוכחי הוא llm_base_url ב-LLMEndpointConfig. אפליקציית ה-full-stack פרשה. הוראות על .env של backend, הגדרת Supabase, או בורר מודל בתוך האפליקציה מתייחסות לאפליקציה שלפני-הפיווט, שכבר לא מה שהמאגר משגר. ההגדרה עכשיו קורית בקוד ה-Python שלכם (או באפליקציה שלכם סביב הספרייה). משתנה הסביבה של המפתח נגזר מה-supplier. עבור supplier openai זה OPENAI_API_KEY, אפילו כש-endpoint אינו OpenAI. אם אתם מעדיפים לא לעמוס את השם הזה, העבירו llm_api_key במפורש בהגדרה, שמקבל עדיפות ושומר את הסביבה נקייה. ה-embedder נפרד. ניתוב יצירה לא מזיז embeddings; ה-embedder ברירת המחדל הוא OpenAIEmbeddings עם אישורים משלו. החליטו על שתי המחציות באופן עצמאי, והטמעה מחדש של מאגר קיים נחוצה רק אם אתם משנים את מודל ה-embedding עצמו.

מי מנתב את quivr-core דרך gateway.

• צוותי מוצר שמטמיעים RAG באפליקציות שלהם ורוצים שמודל היצירה יהיה ערך הגדרה, לא התחייבות ספק אפויה בערימה.
• מפתחים שמריצים brains רבים ברמות איכות שונות: מפתח אחד, endpoint אחד, model id לכל brain.
• צוותים שרוצים תשובות מעוגנות באיכות Claude מאחורי הגדרה בצורת OpenAI בלי להוסיף SDK או חשבון ספק שני.
• בונים שמבצעים benchmark למודלי יצירה על corpus קבוע, שם כל מועמד הוא שינוי LLMEndpointConfig אחד.
• מפתחים ללא גישה לחיוב של ספק נתון. גישה מבוססת-הטענה בלי דרישת כרטיס מסירה את התלות בהרשמה לכל ספק.

אמתו את ה-endpoint ובצעו דיבוג ל-ask() הראשון.

אשרו שה-gateway רושם את המודל שלכם לפני שאתם מבצעים אינגסטיה לכל דבר; שדה ה-model חייב להתאים בדיוק ל-id מוגש. כשלי הרצה ראשונה צפויים. אזהרה ש-API key עבור supplier openai לא מוגדר אומרת שלא llm_api_key ולא OPENAI_API_KEY היו נראים כשההגדרה נבנתה; האזהרה קורית בבנייה, הכשל ב-ask() הראשון. 401 אומר שהמפתח שנפתר לא שייך ל-endpoint ב-llm_base_url. שגיאת model-not-found היא טעות הקלדה ב-id מול /v1/models. ושגיאת אימות הקשורה ל-embedding במהלך Brain.from_files היא ה-embedder ברירת המחדל הנפרד שמבקש אישורי OpenAI משלו, ששום הגדרת llm_base_url לא תתקן; העבירו embedder שאתם שולטים בו. ברגע שתשובות זורמות, קונסולת APIsRouter מציגה מודל לכל בקשה, ספירות טוקן, והוצאה. עבור ספרייה שדוחסת מקטעים מאוחזרים לכל prompt, מספר הטוקנים-לתשובה על ה-corpus האמיתי שלכם הוא הנתון שצריך להנחות את בחירת המודל שלכם.

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

שאלות נפוצות