semantica.llms provides a consistent generation API across major LLM providers and a separate typed-decision API for TypeSafe Jev:
- Generative providers are interchangeable wherever a provider instance is taken: the
llm_provider=argument ofAgentContext.query_with_reasoning(),ContextRetriever.query_with_reasoning()andTemporalQueryRewriter - Extractors take no instance: they build the provider themselves from
provider=,llm_model=andapi_key= LiteLLMroutes to 100+ providers with a single class and model-string prefixesHuggingFaceLLMruns fully on-premise: no API key, no network calls- Structured output via
generate_typed()for schema-validated extraction JevandAsyncJevreturn Choice, Noul, or Score decisions without pretending to generate text- Streaming, tool use, and
generate_batch()for bulk inference
Exported Classes
What You Get
- Unified
LLMProviderinterface: swap providers with a one-line change, no application code changes LiteLLM: single class for 100+ providers using model-string routing- Local models:
HuggingFaceLLMruns fully on-premise, no API key - Typed decisions:
Jevsupports bounded Choice, Noul, and Score decisions with probability metadata - Streaming: token-by-token output for low-latency UX
- Custom gateways: point
OpenAIat any OpenAI-compatible endpoint viabase_url
Choosing a Provider
- Groq: Getting Started
- OpenAI: Production
- Ollama: Local / Air-gapped
- Claude: Reasoning
- DeepSeek: Cost Optimization
- Jev: Typed Decisions
Free tier, fastest inference, zero setup friction. Best for development and high-throughput extraction pipelines.Get your free key at console.groq.com.
API Key Setup
Environment Variables (Recommended)
Configuration File Method
Programmatic Setup
Security Best Practices
TypeSafe Jev
Jev and AsyncJev wrap the official typesafe-sdk System One client. They are decision-only providers: neither class implements generate(), generate_structured(), or generate_typed(), and neither can stand in for a generative provider: not as the llm_provider= argument of a reasoning query, and not as provider= in an extractor.
Constructors
Methods
state accepts a string, mapping, or list. question is the instruction evaluated against that state. Inputs by kind:
kind="choice": passchoicesas a sequence of labels or a label-to-description mapping.criteria=is accepted as an equivalent explicit name. Do not pass both.kind="noul": optionally passcriteria={"true": ..., "false": ...}.kind="score": passcriteriaas an ordered sequence of rubric levels, beginning at score zero.
system_one(), such as per-call model, retry, timeout, extra_headers, or extra_body.
JevDecisionResult
result.to_dict() returns a serializable copy suitable for Semantica decision metadata or cross_system_context. It deliberately retains the raw Noul probability separately from the derived confidence.
Providers
LiteLLM: 100+ Providers
LiteLLM is the recommended way to access any provider not directly exported by semantica.llms. Use the provider/model string format:
The full list of supported LiteLLM model strings is at docs.litellm.ai/docs/providers. Use the
provider/model format shown above.Custom / Enterprise Gateways
Any OpenAI-compatible endpoint: internal routing layers, Qwen proxies, or private LLaMA deployments:base_url is validated at construction time. Non-HTTP(S) schemes raise ValueError to prevent SSRF attacks (fixed in v0.5.0).Using Generative Providers in Extractors
Extractors do not take a provider instance. They build one themselves from keyword configuration:provider names the backend (default "openai"), llm_model picks the model, and api_key is read from the matching <PROVIDER>_API_KEY variable when it is omitted. llm_provider= is not read here: it travels through **config into the provider factory and is kept in the constructed provider’s config mapping, which nothing consults — the instance never serves as the extractor’s provider, so the extractor runs against the backend named by provider= (the "openai" default when it is omitted). Jev is not usable here either, because it returns decisions rather than generated text:
Use
llm_model, not model. Both names configure an extractor’s own LLM call (llm_model wins), but TripletExtractor strips model out of the configuration it shares with the entity and relation extractors it builds internally, because there that keyword is the spaCy/HuggingFace model name. So model alone reaches the triplet stage only, and the two internal stages are built with no LLM model at all: they are constructed with an explicit model=None, which overrides the provider’s own default. llm_model configures all three.Provider Comparison
Defaults and Reproducibility
Documentation examples may showcase stronger models for better developer experience, while implementation defaults prioritize reliability and cost efficiency. Understanding actual defaults helps with reproducible results and consistent benchmarking. Verified Implementation Defaults:
These are the models used when you construct a provider without specifying
model=. Examples throughout this documentation use stronger showcase models. Always pass model= explicitly in production for reproducible results.
Why This Matters:
- Reproducible extraction results across environments
- Consistent baseline performance for benchmarking
- Predictable costs when scaling production workloads
Performance and Reliability Tips
Extraction with Retries
Model Selection by Use Case
Error Handling
- Semantic Extract — Use LLMs for NER and relation extraction.
- Agno Integration — LLM providers in Agno multi-agent teams.
- Reasoning — LLM-backed deductive and abductive reasoning.
- Context — GraphRAG uses LLMs for reasoning over knowledge graphs.
