Faça a gestão dos fornecedores e modelos de LLM, sincronize modelos a partir de registos externos, execute verificações de estado e configure API keys por organização para faturação independente.
O Entity Enricher suporta uma ampla variedade de fornecedores de LLM. Cada fornecedor pode ter múltiplos modelos com preços, capacidades e configuração individuais.
Muitas equipas encaminham o tráfego de LLM através de um gateway de IA empresarial, um endpoint regional ou um fornecedor que não está integrado — por exemplo, um proxy LiteLLM empresarial, o Cloudflare AI Gateway ou o Alibaba DashScope (para modelos Qwen). Adiciona-os como o seu próprio fornecedor Standard (compatível com OpenAI) com um URL base personalizado.
acme-openai-gw). Nomes integrados como openai ou anthropic estão reservados. https://gateway.example.com/v1. Este campo é obrigatório para qualquer provider para o qual o Entity Enricher não tenha um cliente incorporado. https://. Loopback e intervalos privados (localhost, 10.x, 192.168.x) são rejeitados para evitar SSRF — um servidor auto-hospedado tem de ser acessível pela internet. Para um Ollama local, utilize antes o túnel Ollama dedicado./v1 (chat completions, /models). {endpoint}/models para verificar a chave e o URL base antes de executar um enriquecimento.Cada fornecedor tem uma definição Máximo de chamadas concorrentes por chave (a sua substituição do limite de taxa). Limita quantas chamadas LLM uma única chave de API executa em paralelo — abrangendo todos os fluxos que utilizam a chave: a distribuição do enriquecimento multi-especialização, a classificação, a arbitragem e a geração de schema / amostras.
Isto é distinto do limite de trabalhos concorrentes máximos do seu plano, que restringe quantos trabalhos de enriquecimento a sua organização executa em simultâneo em todos os fornecedores.
Cada modelo regista as suas capacidades, que são apresentadas como ícones no seletor de modelos:
| Capacidade | Descrição |
|---|---|
| Visão | Pode processar entradas de imagem e visuais |
| Chamadas de ferramenta | Suporta chamada de funções / uso de ferramentas |
| Entrada de Áudio | Pode processar entradas de áudio |
| Entrada de PDF | Pode processar documentos PDF |
| Caching de Prompts | Suporta cache de prompts para redução de custos |
| Raciocínio | Capacidades de raciocínio alargado / cadeia de pensamento |
| Embeddings | Transforma texto num vetor em vez de responder — é com isto que os IDs semânticos são resolvidos. Os modelos de embedding são uma família à parte, com o seu próprio tamanho de vetor, e nunca aparecem num seletor de enriquecimento |
Indicar um modelo é opcional. O enriquecimento, a geração de esquemas e a geração de amostras aceitam todos auto — e tratam um modelo omitido como auto —, valor que é resolvido no servidor, por tarefa, no momento em que o trabalho arranca. A execução indica que modelo foi escolhido, por isso automático nunca significa opaco.
Os proprietários podem fixar um modelo preferido por tarefa em Definições → Organização → Predefinições. Se estiver definido um para a tarefa em causa, é esse que prevalece.
Na ausência de um modelo fixado, a escolha recai sobre o modelo com a melhor pontuação combinada dos seus benchmarks de fonte de pontuação — as suas próprias medições de qualidade, velocidade e custo nos seus esquemas. Sem qualquer fonte de pontuação, o pedido é recusado em vez de adivinhado.
Ativar a pesquisa web, ou anexar um documento que tem de ser enviado tal como está, restringe os candidatos aos modelos que o conseguem realmente fazer — e, se nenhum se qualificar, recebe um erro explícito em vez de uma degradação silenciosa.
Um modelo também pode ser vedado a uma tarefa sem ser desativado: um modelo que enriquece bem mas gera maus esquemas pode ser ocultado apenas nos seletores de geração de esquemas e de amostras, seja para a sua organização, seja globalmente por um administrador. Continua totalmente disponível em todo o resto — um instrumento mais suave do que a desativação apresentada abaixo.
Mantenha os preços dos modelos atualizados sincronizando a partir de registos externos. O processo de sincronização deteta automaticamente novos modelos, alterações de preços e modelos removidos.
A fonte de preços predefinida. Obtém dados do registo mantido pela comunidade da LiteLLM no GitHub, com nomes reais de modelos da API, preços, comprimentos de contexto e capacidades.
Cobre ~30 providers. Não inclui nomes de apresentação, benchmarks nem velocidade de geração.
Uma fonte alternativa de pricepertoken.com. Inclui nomes de apresentação, benchmarks (pontuações de programação e matemática) e velocidade de geração (tokens por segundo).
Cobre ~20 providers. Fornece metadados mais ricos do que o LiteLLM.
Um catálogo oficial e autenticado de identificadores de modelos GLM, com preços extraídos diretamente da documentação da Z.AI e lacunas de capacidades investigadas na mesma.
Substitui as entradas da Z.AI importadas anteriormente do LiteLLM e do PricePerToken.
Valide proativamente se os models estão acessíveis executando um prompt mínimo de verificação de estado. Isto deteta models avariados antes de os utilizadores encontrarem erros durante o enriquecimento.
As verificações de estado podem ser executadas em todos os modelos, nos modelos de um fornecedor específico ou num único modelo. Os resultados são transmitidos em tempo real via SSE com uma barra de progresso que mostra as contagens de aprovações/falhas.
Quando uma chamada de enriquecimento falha com um erro “model not found”, o modelo é automaticamente desativado para evitar falhas repetidas. Isto acontece em tempo real durante as operações normais de enriquecimento.
| Motivo da desativação | Definido por | Reativado automaticamente? |
|---|---|---|
| Modelo não encontrado | Erros de enriquecimento ou verificações de saúde | Sim (por sincronização de preços ou validação) |
| Sincronização removida | Sincronização de preços (model desapareceu) | Sim (se o model reaparecer no registo) |
| Manual | Alternância de administrador na interface | Não (apenas reativação manual) |
As organizações podem configurar as suas próprias chaves de API de provider de LLM para faturação e monitorização de utilização independentes. O sistema utiliza uma resolução de chaves em dois níveis com seleção LRU:
Chaves por organização configuradas na página de Chaves API. Suporta várias chaves por fornecedor com rotação LRU. Encriptadas com Fernet.
Chaves de todo o sistema geridas por administradores. Partilhadas por todas as organizações. Também suporta várias chaves por fornecedor com rotação LRU.
Cada enriquecimento regista qual a chave utilizada, para que possa acompanhar os custos por chave. As chaves incluem suporte para verificações de estado e contadores de utilização. Dentro de um conjunto, a chave seguinte a ser escolhida é a chave ativa com a data de última utilização mais antiga; uma chave só sai da rotação quando você a desativa manualmente, pelo que um erro do fornecedor nunca retira silenciosamente uma chave de serviço. Saiba como gerir chaves no guia Chaves de API.
Exporte toda a sua configuração de providers e models em JSON para cópia de segurança ou transferência para outra instância. A importação é sempre uma inserção-ou-atualização: os providers e models existentes são correspondidos pelo nome e atualizados no local, enquanto os novos são adicionados — nada é eliminado.
A exportação inclui as definições do fornecedor, as configurações do modelo, os preços, as capacidades e as especificações canónicas do modelo — mas nunca as chaves de API, que são armazenadas separadamente. Após a importação, configure as chaves de API separadamente. Os administradores do sistema fazem cópias de segurança do catálogo global completo; os proprietários da organização exportam e importam apenas os fornecedores e modelos da sua própria organização — o catálogo global partilhado não pode ser criado nem editado através da importação.