Запустіть RAG-мозок Quivr на кастомному OpenAI-сумісному ендпоінті.

Коротка відповідь: llm_base_url у LLMEndpointConfig.

Поточний Quivr — це quivr-core, бібліотека RAG на Python, і її з'єднання LLM явне. LLMEndpointConfig несе supplier (openai за замовчуванням), model, llm_base_url і llm_api_key; LLMEndpoint.from_config() будує реальний клієнт з цих полів, і для постачальника openai цей клієнт — ChatOpenAI від LangChain, побудований з вашим base URL. Встановіть llm_base_url на https://api.apisrouter.com/v1, встановіть model на будь-який id з каталогу і передайте ендпоінт вашому Brain. Ключ може приходити з поля конфігурації чи з середовища: коли llm_api_key не встановлено, quivr-core резолвить його зі змінної середовища, названої за постачальником, що для постачальника openai — OPENAI_API_KEY. Обидва шляхи — апстрим-поведінка, яку можна прочитати в 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, приблизно 39 тис. зірок) почався як повноцінний застосунок другого мозку й перетворився на quivr-core: концептуальну RAG-бібліотеку, яку ви вбудовуєте у власний продукт. Ви подаєте їй файли, вона парсить і розбиває їх на фрагменти, вбудовує фрагменти у векторне сховище (FAISS за замовчуванням, підтримується PGVector) і відповідає на питання над ними через налаштовуваний workflow пошуку. Об'єкт Brain — це одиниця: Brain.from_files() поглинає, brain.ask() шукає й генерує. Генерація — єдиний крок, що потребує чат-моделі. Workflow пошуку збирає контекст з ваших документів, а переданий вами LLMEndpoint пише обґрунтовану відповідь. Цей ендпоінт будується один раз із LLMEndpointConfig, тож рішення про base URL приймається під час побудови й застосовується до кожного ask() на цьому brain. Оскільки ChatOpenAI пересилає поле моделі як звичайний рядок через /v1/chat/completions, id може бути Claude, DeepSeek, GPT чи Gemini, коли ендпоінт за llm_base_url обслуговує їх. Одна чесна примітка про статус проєкту: репозиторій тихий із середини 2025 року, тож ставтеся до quivr-core як до стабільної бібліотеки, а не швидко змінюваної. Описана тут поверхня конфігурації збігається з останньою гілкою main, і тиха історія означає, що вона навряд чи зміниться під вами; вона також означає, що старі туторіали, які описують закритий повноцінний застосунок (файли backend .env, хостований фронтенд), більше не відповідають коду.

Повне налаштування: brain з LLM, що маршрутизується через шлюз.

Повний патерн передає налаштований LLMEndpoint у Brain.from_files. Усе інше в brain (парсинг, розбивка на фрагменти, сховище FAISS, workflow пошуку) незалежне від LLM-ендпоінта й зберігає свої значення за замовчуванням. Зверніть увагу на ембедер. Якщо ви його не передасте, quivr-core будує OpenAIEmbeddings від LangChain з власними значеннями за замовчуванням, що автентифікується через OPENAI_API_KEY і націлюється на стоковий ендпоінт OpenAI. Це окремий клієнт від чат-LLM: маршрутизація генерації через шлюз його не переміщує. Передайте власний ембедер (локальну обгортку sentence-transformers чи будь-який налаштований вами інстанс LangChain Embeddings), якщо не хочете, щоб половина ембедінга залежала від облікового запису 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-відповідей.

Порівняння кандидатів — зміна на етапі побудови: побудуйте два LLMEndpoint проти того самого base URL, два brain над тими самими файлами й порівняйте відповіді на фіксованому наборі питань. Лог використання за ключем оцінює прогін кожного кандидата, тож якість-на-токен вимірюється, а не обговорюється.

• Генерація 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 працює на LangChain, а не на LiteLLM. Перелічення постачальників обирає клас чату LangChain, і openai мапиться на ChatOpenAI з вашим llm_base_url. Якщо туторіал каже налаштувати проксі LiteLLM чи параметр api_base всередині Quivr, він описує старішу архітектуру; поточне поле — llm_base_url на LLMEndpointConfig. Повноцінний застосунок закритий. Інструкції про backend .env, налаштування Supabase чи селектор моделі в застосунку стосуються застосунку до повороту, якого репозиторій більше не постачає. Конфігурація тепер відбувається у вашому коді Python (чи вашому власному застосунку навколо бібліотеки). Змінна середовища ключа походить від постачальника. Для постачальника openai це OPENAI_API_KEY, навіть коли ендпоінт — не OpenAI. Якщо не хочете перевантажувати цю назву, передайте llm_api_key явно в конфігурації, що має пріоритет і тримає середовище чистим. Ембедер окремий. Маршрутизація генерації не переміщує ембедінги; типовий ембедер — OpenAIEmbeddings з власними обліковими даними. Вирішуйте дві половини незалежно, і повторне вбудовування наявного сховища потрібне лише якщо ви змінюєте саму модель ембедінга.

Хто спрямовує quivr-core через шлюз.

• Продуктові команди, що вбудовують RAG у свої застосунки і хочуть, щоб модель генерації була значенням конфігурації, а не зобов'язанням перед вендором, вбудованим у стек.
• Розробники, що запускають багато brain на різних рівнях якості: один ключ, один ендпоінт, id моделі на brain.
• Команди, що хочуть обґрунтованих відповідей якості Claude за конфігурацією у формі OpenAI без додавання другого SDK чи облікового запису провайдера.
• Розробники, що бенчмаркають моделі генерації на фіксованому корпусі, де кожен кандидат — це зміна LLMEndpointConfig.
• Розробники без доступу до білінгу певного постачальника. Доступ на основі поповнення без вимоги картки прибирає залежність від реєстрації в кожного провайдера.

Перевірте ендпоінт і налагодьте перший ask().

Підтвердіть, що шлюз перелічує вашу модель, перш ніж щось поглинати; поле моделі має точно збігатися з обслуговуваним id. Збої першого запуску передбачувані. Попередження, що ключ API для постачальника openai не встановлено, означає, що ні llm_api_key, ні OPENAI_API_KEY не були видимі під час побудови конфігурації; попередження з'являється при побудові, збій — при першому ask(). 401 означає, що резолвлений ключ не належить ендпоінту в llm_base_url. Помилка model-not-found — це одруківка в id проти /v1/models. А помилка автентифікації, пов'язана з ембедінгом, під час Brain.from_files — це окремий типовий ембедер, що просить власні облікові дані OpenAI, яких жодне налаштування llm_base_url не виправить; передайте ембедер, який контролюєте ви. Щойно відповіді потечуть, консоль APIsRouter показує модель на запит, кількість токенів і витрати. Для бібліотеки, що впаковує отримані фрагменти в кожен промпт, число токенів на відповідь на вашому реальному корпусі — саме той показник, який має визначати вибір моделі.

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

Поширені запитання