Con el enriquecimiento mediante LLM, la factura son los tokens. Entity Enricher está diseñado para enviar la menor cantidad posible de tokens facturados sin sacrificar la precisión, gracias al almacenamiento en caché de prompts y respaldado por el acotamiento de esquemas, el filtrado inteligente y menos reintentos desperdiciados. La mayor parte ocurre de forma automática; nada de esto requiere configuración adicional.
Cada llamada de enriquecimiento paga los tokens de entrada (su prompt, el esquema y cualquier documento adjunto), los tokens de salida (el resultado estructurado) y —si está habilitado— las consultas de búsqueda web. La parte más grande y repetitiva suele ser la entrada: las mismas instrucciones del sistema, la descripción del esquema y los documentos de origen se reenvían en cada llamada. Almacenar en caché esa entrada compartida es la palanca más importante, por eso viene primero.
Prompt + esquema + adjuntos. Grande y muy repetitivo entre llamadas — el objetivo principal para el almacenamiento en caché y la delimitación de alcance.
El resultado estructurado. Se mantiene ligero al solicitar a cada modelo únicamente los campos que realmente le corresponden.
Reintentos fallidos, saturación por límites de tasa y enriquecimiento de la entidad equivocada. Eliminados de entrada en lugar de pagarlos.
Cuando se ejecuta un enriquecimiento con múltiples dominios de especialización, se realizan varias llamadas al LLM para la misma entidad: una por cada dominio de especialización. Todas esas llamadas comparten el mismo contexto inicial: las instrucciones genéricas del sistema y cualquier documento de texto en línea que haya adjuntado. Entity Enricher mantiene ese prefijo compartido idéntico byte a byte en todas las llamadas y lo marca como almacenable en caché, de modo que el proveedor lo guarda una vez y lo vuelve a leer en cada llamada posterior a aproximadamente una décima parte del precio de entrada normal.
Cada una de las N llamadas reenvía el contexto compartido completo al precio íntegro de entrada. Cinco especializaciones significan pagar ese gran bloque compartido cinco veces.
El bloque compartido se escribe en la caché una vez y luego se lee en las otras cuatro llamadas a aproximadamente el 10 % del precio de entrada. El ahorro crece con cada especialización, idioma y documento adjunto adicional.
Las cachés del proveedor solo se pueden leer después de que finalice la primera solicitud que las escribe. Si todas las llamadas de dominio de especialización se ejecutaran a la vez, ninguna encontraría una caché caliente y cada una escribiría su propia copia de forma redundante. Por eso, cuando se aplica el almacenamiento en caché, la primera llamada se ejecuta por sí sola, se concede un breve momento para que la caché se propague y solo entonces se lanzan en paralelo las llamadas restantes, de modo que cada una lee la caché caliente en lugar de pagar por reescribirla.
Los modelos de Anthropic almacenan en caché las instrucciones compartidas de forma explícita; los PDF e imágenes adjuntos se almacenan en caché en su lugar; y los proveedores con caché de prefijo automática (OpenAI, xAI, DeepSeek y otros) se benefician del mismo prefijo idéntico byte a byte. La caché resulta más rentable precisamente cuando la entrada es grande: muchos dominios de especialización, varios idiomas o documentos adjuntos.
La contabilidad de costos tiene en cuenta la caché: los tokens de entrada en caché se facturan a la tarifa de lectura de caché del modelo (una fracción de la tarifa de entrada), y solo los tokens realmente nuevos se facturan a precio completo. El ahorro se refleja directamente en sus análisis de costos, no solo en teoría.
Más allá de almacenar en caché el prefijo compartido, Entity Enricher reduce la parte de cada llamada que no se comparte.
Cada llamada de especialización solo recibe la parte del esquema de la que es responsable, no el esquema completo.
Un experto financiero nunca ve los campos regulatorios. Menos campos significa menos tokens de entrada y salida, y la respuesta se recorta a su fragmento antes de fusionarse.
Cuando se adjuntan documentos y no ha optado por un modo estricto de salida estructurada, la lista de campos reside únicamente en el prompt legible: no se duplica ningún esquema en la transmisión.
Esto elimina por completo los tokens del esquema y mantiene idéntico el prefijo compartido (por lo que se almacena mejor en caché). La respuesta se sigue validando en el lado del cliente, con autocorrección automática ante desviaciones.
La clasificación previa opcional ejecuta un único modelo económico y rápido para comprobar si una entidad realmente coincide con su esquema antes de iniciar cualquier enriquecimiento multimodelo costoso. Una discrepancia —como una luna enviada a un esquema de «Planeta»— se detecta por una fracción de céntimo en lugar de consumir un enriquecimiento completo en varios modelos premium.
No es bloqueante (si la comprobación falla, el enriquecimiento continúa igualmente) y es cancelable, por lo que nunca empieza a pagar por modelos que decidió omitir.
Una ronda de validación fallida es una llamada al LLM a precio completo sin nada que mostrar a cambio. Dos mecanismos hacen que los reintentos sean poco frecuentes y productivos.
Las peculiaridades habituales de la salida del LLM —objetos con claves de índice que deberían ser arreglos, la cadena 'null', comillas escapadas sueltas— se corrigen antes de ejecutar la validación.
Muchos fallos potenciales de validación se corrigen de forma silenciosa, por lo que nunca llegan a activar un reintento de pago.
Cuando realmente se necesita un reintento, el error de validación exacto se devuelve al modelo para que pueda corregir ese problema específico.
Los comentarios claros y específicos aumentan las probabilidades de que el siguiente intento tenga éxito, en lugar de malgastar intentos con indicaciones vagas.
La pasada única es la más económica para esquemas pequeños; la multiespecialización está pensada para los grandes, donde el almacenamiento en caché junto con el alcance por especialización compensan con creces las llamadas adicionales. Consulte Estrategias para saber cuándo usar cada una.
Un límite de concurrencia por proveedor evita que los trabajos saturen a un proveedor con errores de límite de tasa, que de otro modo activarían esperas y reintentos: tokens y tiempo desperdiciados. Una concurrencia limitada y constante es más económica que luchar contra los 429.
Cada enriquecimiento registra sus recuentos reales de tokens —incluidas las lecturas en caché— y el coste resultante. El Panel de costes lo convierte en gráficos de series temporales y desgloses por modelo, para que pueda ver exactamente adónde va el gasto y confirmar que el almacenamiento en caché y la delimitación cumplen su función. El precio que ve es el precio que se le factura; los costes brutos del proveedor y cualquier margen de la plataforma se mantienen transparentes.