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.
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.
Um limite de concorrência por fornecedor evita que as tarefas martelem um fornecedor até provocarem erros de limite de taxa, que de outra forma acionariam recuos e repetições — tokens e tempo desperdiçados. Uma concorrência limitada e constante é mais barata do que lutar contra erros 429.
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.