Com o enrichment por LLM, a fatura são os tokens. O Entity Enricher foi concebido para enviar o menor número possível de tokens faturados sem sacrificar a precisão — impulsionado pelo cache de prompts e apoiado pelo scoping de schema, gating inteligente e menos retentativas desperdiçadas. A maior parte acontece automaticamente; nada aqui exige configuração adicional.
Cada chamada de enriquecimento paga tokens de entrada (o seu prompt, o schema e quaisquer documentos anexados), tokens de saída (o resultado estruturado) e — se estiver ativado — consultas de pesquisa web. A parte maior e mais repetitiva é normalmente a entrada: as mesmas instruções de sistema, a descrição do schema e os documentos de origem são reenviados em cada chamada. Colocar em cache essa entrada partilhada é a maior alavanca de todas, por isso vem primeiro.
Prompt + esquema + anexos. Grande e altamente repetitivo entre chamadas — o alvo principal para caching e delimitação de âmbito.
O resultado estruturado. Mantido enxuto ao pedir a cada modelo apenas os campos que efetivamente lhe pertencem.
Uma linha pequena e separada quando os IDs semânticos estão ativos: cada identidade que não fique resolvida pelas etapas gratuitas de comparação de texto custa um embedding. Medido e faturado como qualquer outra utilização.
Tentativas falhadas, sobrecarga de limites de taxa e enriquecimento da entidade errada. Eliminados à partida em vez de pagos.
Quando um enriquecimento multi-expertise é executado, faz várias chamadas LLM para a mesma entidade — uma por expertise domain. Cada uma dessas chamadas partilha o mesmo contexto inicial: as instruções genéricas do sistema e quaisquer documentos de texto inline que anexou. O Entity Enricher mantém esse prefixo partilhado idêntico byte a byte entre chamadas e marca-o como armazenável em cache, para que o provider o guarde uma vez e o releia em cada chamada subsequente a cerca de um décimo do preço normal de entrada.
Cada uma das N chamadas reenvia o contexto partilhado completo ao preço total de entrada. Cinco especializações significam pagar cinco vezes por esse grande bloco partilhado.
O bloco partilhado é escrito na cache uma vez e, em seguida, relido nas outras quatro chamadas a ~10% do preço de entrada. As poupanças aumentam com cada especialização, idioma e documento anexado adicionais.
As caches do fornecedor só podem ser lidas depois de terminar o primeiro pedido que as escreve. Se todas as chamadas de expertise fossem disparadas ao mesmo tempo, nenhuma encontraria uma cache aquecida e cada uma escreveria a sua própria cópia de forma redundante. Por isso, quando a cache se aplica, a primeira chamada é executada sozinha, é concedido um breve momento para a cache se propagar e só depois é que as restantes chamadas são lançadas em paralelo — para que cada uma leia a cache aquecida em vez de pagar para a reescrever.
Os modelos da Anthropic colocam explicitamente em cache as instruções partilhadas; os PDFs e imagens anexados são colocados em cache no local; e os fornecedores com cache automática de prefixo (OpenAI, xAI, DeepSeek e outros) beneficiam do mesmo prefixo byte a byte idêntico. A cache compensa sobretudo quando a entrada é grande — muitas áreas de especialização, vários idiomas ou documentos anexados.
A contabilização de custos tem em conta a cache: os tokens de entrada em cache são faturados à taxa de leitura de cache do modelo (uma fração da taxa de entrada) e apenas os tokens genuinamente novos são faturados a preço total. As poupanças aparecem diretamente nas suas análises de custos, e não apenas na teoria.
Para além de colocar em cache o prefixo partilhado, o Entity Enricher reduz a parte de cada chamada que não é partilhada.
Cada chamada de especialização recebe apenas a fatia do schema pela qual é responsável, e não o schema inteiro.
Um especialista financeiro nunca vê os campos regulamentares. Menos campos significa menos tokens à entrada e à saída — e a resposta é reduzida à sua fatia antes da fusão.
Quando os documentos são anexados e não optou por um modo estrito de saída estruturada, a lista de campos existe apenas no prompt legível — nenhum schema é duplicado na transmissão.
Isto elimina por completo os tokens do esquema e mantém o prefixo partilhado idêntico (para uma melhor colocação em cache). A resposta continua a ser validada do lado do cliente, com autocorreção automática em caso de desvio.
A classificação preliminar opcional executa um único modelo barato e rápido para verificar se uma entity corresponde de facto ao seu schema antes de iniciar qualquer enrichment dispendioso com múltiplos modelos. Uma incompatibilidade — como uma lua enviada a um schema de “Planeta” — é detetada por uma fração de cêntimo, em vez de desperdiçar um enrichment completo em vários modelos premium.
Não é bloqueante (se a verificação falhar, o enrichment prossegue à mesma) e pode ser cancelado, por isso nunca começa a pagar por models que decidiu ignorar.
Uma ronda de validação falhada é uma chamada de LLM a preço integral sem nada para mostrar em troca. Dois mecanismos mantêm as repetições raras e produtivas.
As peculiaridades comuns da saída do LLM — objetos indexados por chave que deviam ser arrays, a string 'null', aspas escapadas soltas — são corrigidas antes de a validação ser executada.
Muitas potenciais falhas de validação são corrigidas silenciosamente, pelo que nunca chegam a acionar uma nova tentativa paga.
Quando uma nova tentativa é genuinamente necessária, o erro exato de validação é reenviado ao modelo para que este possa corrigir esse problema específico.
Um feedback claro e específico aumenta as probabilidades de a próxima tentativa ter êxito, em vez de desperdiçar tentativas com orientações vagas.
A passagem única é a opção mais económica para esquemas pequenos; a multiespecialização foi concebida para os grandes, onde a cache e o âmbito por especialização compensam largamente as chamadas adicionais. Consulte Estratégias para saber quando utilizar cada uma.
O modelo mais caro raramente é a predefinição certa, e o mais barato raramente é suficiente em todo o lado. Em vez de adivinhar uma vez e viver com essa escolha, avalie os modelos com benchmarks nos seus próprios esquemas e deixe a seleção resolver-se automaticamente — depois pondere a combinação a favor do custo em Definições → Organização → Predefinições e todas as execuções não especificadas seguirão discretamente essa preferência. Consulte Benchmarks.
Um limite de concorrência delimitado por chave — e não por fornecedor — impede que as tarefas martelem uma chave até gerar erros de limite de taxa, que custam repetições em tokens desperdiçados e tempo real. Uma concorrência regulada e constante sai mais barata do que lutar contra 429s.
Cada enriquecimento regista as suas contagens reais de tokens — incluindo leituras em cache — e o custo resultante. O Painel de custos transforma isso em gráficos de séries temporais e discriminações por modelo, para que possa ver exatamente para onde vai a despesa e confirmar que o cache e a delimitação estão a cumprir o seu papel. Os preços que vê são o preço que lhe é cobrado; os custos brutos do fornecedor e qualquer margem da plataforma são mantidos transparentes.