Gestisci provider e modelli LLM, sincronizza i modelli da registri esterni, esegui controlli di integrità e configura chiavi API per organizzazione per una fatturazione indipendente.
Entity Enricher supporta un'ampia gamma di provider LLM. Ogni provider può disporre di più modelli con prezzi, funzionalità e configurazione individuali.
Molti team instradano il traffico LLM attraverso un gateway AI aziendale, un endpoint regionale o un provider non integrato — ad esempio un proxy LiteLLM enterprise, Cloudflare AI Gateway o Alibaba DashScope (per i modelli Qwen). Puoi aggiungerli come provider Standard (compatibile con OpenAI) con un URL di base personalizzato.
acme-openai-gw). I nomi integrati come openai o anthropic sono riservati. https://gateway.example.com/v1. Questo campo è obbligatorio per qualsiasi provider per cui Entity Enricher non dispone di un client integrato. https://. Loopback e intervalli privati (localhost, 10.x, 192.168.x) vengono rifiutati per prevenire SSRF — un server self-hosted deve essere raggiungibile via internet. Per un Ollama locale, utilizzare invece il tunnel Ollama dedicato./v1 (chat completions, /models). {endpoint}/models per verificare la chiave e l'URL di base prima di eseguire un arricchimento.Ogni provider dispone di un'impostazione Numero massimo di chiamate simultanee per chiave (l'override del suo limite di frequenza). Limita quante chiamate LLM esegue in parallelo una singola chiave API — coprendo ogni flusso che utilizza la chiave: la distribuzione dell'enrichment multi-expertise, la classification, l'arbitration e la generazione di schema / campioni.
Questo è distinto dal limite di job concorrenti massimi del vostro piano, che stabilisce quanti job di enrichment l'intera organization può eseguire contemporaneamente su tutti i provider.
Ogni model tiene traccia delle proprie capacità, che vengono visualizzate come icone nel selettore di model:
| Funzionalità | Descrizione |
|---|---|
| Visione | Può elaborare input di immagini e visivi |
| Chiamate agli strumenti | Supporta function calling / uso di strumenti |
| Input audio | Può elaborare input audio |
| Input PDF | Può elaborare documenti PDF |
| Caching dei prompt | Supporta il caching dei prompt per la riduzione dei costi |
| Ragionamento | Capacità di extended thinking / catena di ragionamento |
| Embeddings | Trasforma il testo in un vettore anziché rispondere: è ciò con cui vengono risolti gli ID semantici. I modelli di embedding costituiscono una famiglia a sé, con una propria dimensione vettoriale, e non compaiono mai in un selettore di arricchimento |
Indicare un modello è facoltativo. Arricchimento, generazione di schema e generazione di campioni accettano tutti auto — e trattano un modello omesso come auto — valore che viene risolto sul server, per singola attività, nel momento in cui il job si avvia. L'esecuzione riporta quale modello è stato scelto: automatico non significa mai opaco.
I proprietari possono fissare un modello preferito per ciascuna attività in Impostazioni → Organizzazione → Predefiniti. Se ne è impostato uno per l'attività in corso, è quello a prevalere.
In assenza di un modello fissato, la scelta ricade sul modello con il miglior punteggio combinato dei suoi benchmark delle origini di punteggio — le sue misurazioni di qualità, velocità e costo sui suoi schemi. Senza alcuna origine di punteggio la richiesta viene rifiutata anziché ipotizzata.
Attivare la ricerca web, o allegare un documento che deve essere inviato così com'è, restringe i candidati ai modelli effettivamente in grado di farlo — e se nessuno è idoneo, riceve un errore esplicito anziché un declassamento silenzioso.
Un modello può anche essere escluso da un solo compito senza essere disattivato: un modello che arricchisce bene ma genera schemi scadenti può essere nascosto solo nei selettori di generazione di schemi e campioni, per la sua organizzazione oppure globalmente da un amministratore. Resta pienamente disponibile in tutto il resto: uno strumento più morbido della disattivazione descritta qui sotto.
Mantieni aggiornati i prezzi dei modelli sincronizzandoli dai registri esterni. Il processo di sincronizzazione rileva automaticamente nuovi modelli, variazioni di prezzo e modelli rimossi.
La fonte di prezzi predefinita. Recupera i dati dal registro mantenuto dalla community di LiteLLM su GitHub, con nomi reali dei modelli API, prezzi, lunghezze di contesto e capacità.
Copre circa 30 provider. Non include nomi visualizzati, benchmark o velocità di generazione.
Una fonte alternativa da pricepertoken.com. Include nomi visualizzati, benchmark (punteggi di coding e matematica) e velocità di generazione (token al secondo).
Copre circa 20 provider. Fornisce metadati più ricchi rispetto a LiteLLM.
Un catalogo ufficiale e autenticato degli identificatori dei modelli GLM, con prezzi analizzati direttamente dalla documentazione di Z.AI e lacune nelle funzionalità ricercate in tale sede.
Sostituisce le voci Z.AI precedentemente importate da LiteLLM e PricePerToken.
Convalida in modo proattivo la raggiungibilità dei model eseguendo un prompt minimo di health check. Ciò intercetta i model non funzionanti prima che gli utenti incontrino errori durante l'enrichment.
I controlli di integrità possono essere eseguiti su tutti i modelli, sui modelli di un provider specifico o su un singolo modello. I risultati vengono trasmessi in tempo reale tramite SSE con una barra di avanzamento che mostra il conteggio dei successi/fallimenti.
Quando una chiamata di arricchimento fallisce con un errore «modello non trovato», il modello viene automaticamente disattivato per evitare errori ripetuti. Ciò avviene in tempo reale durante le normali operazioni di arricchimento.
| Motivo della disattivazione | Impostato da | Riattivato automaticamente? |
|---|---|---|
| Modello non trovato | Errori di arricchimento o controlli di stato | Sì (tramite sincronizzazione dei prezzi o validazione) |
| Sincronizzazione rimossa | Sincronizzazione prezzi (model scomparso) | Sì (se il model riappare nel registro) |
| Manuale | Interruttore admin nell'interfaccia utente | No (solo riattivazione manuale) |
Le organizzazioni possono configurare le proprie chiavi API dei provider LLM per una fatturazione e un monitoraggio dell'utilizzo indipendenti. Il sistema utilizza una risoluzione delle chiavi a due livelli con selezione LRU:
Chiavi per organizzazione configurate nella pagina Chiavi API. Supporta più chiavi per provider con rotazione LRU. Crittografate con Fernet.
Chiavi a livello di sistema gestite dagli amministratori. Condivise tra tutte le organization. Supporta anche più chiavi per provider con rotazione LRU.
Ogni arricchimento registra quale chiave è stata utilizzata, così può monitorare i costi per chiave. Le chiavi supportano il controllo di integrità e i contatori di utilizzo. All'interno di un pool viene selezionata la chiave abilitata con il timestamp di ultimo utilizzo più vecchio; una chiave esce dalla rotazione solo quando la disabilita manualmente, quindi un errore del provider non rimuove mai silenziosamente una chiave dal servizio. Scopra come gestire le chiavi nella guida API Keys.
Esporta l'intera configurazione di provider e model come JSON per il backup o il trasferimento su un'altra istanza. L'importazione è sempre un upsert: i provider e i model esistenti vengono abbinati per nome e aggiornati sul posto, mentre quelli nuovi vengono aggiunti — nulla viene eliminato.
L'esportazione include le impostazioni del provider, le configurazioni dei modelli, i prezzi, le capacità e le specifiche canoniche dei modelli, ma mai le chiavi API, che vengono memorizzate separatamente. Dopo l'importazione, configurare le chiavi API separatamente. Gli amministratori di sistema eseguono il backup dell'intero catalogo globale; i proprietari dell'organizzazione esportano e importano solo i provider e i modelli della propria organizzazione — il catalogo globale condiviso non può essere creato o modificato tramite importazione.