Amazon Nova 2 Lite vs Claude Fable 5.1 para extraer datos de documentos: cómo plantear una comparación reproducible

Qué decisión resuelve esta comparación y qué no permite concluir

La decisión relevante no es qué modelo es «mejor» en abstracto, sino cuál encaja en un flujo concreto de extracción documental. El caso de uso considerado es convertir facturas, contratos breves, formularios y documentos PDF con tablas en datos que cumplan un esquema definido. En estos flujos, una respuesta que parece correcta no basta: debe conservar los valores relevantes, respetar los tipos exigidos, distinguir una ausencia de un valor real y dejar trazabilidad suficiente para corregir errores.

La información aportada describe Amazon Nova 2 Lite y Claude Fable 5.1 desde sus proveedores, pero no incluye resultados de una evaluación común ejecutada sobre ambos. Por tanto, no es posible afirmar a partir de estas fuentes que uno alcance mayor exactitud, menor latencia o menor coste efectivo que el otro en una cartera documental determinada. Tampoco sería riguroso extrapolar comparativas de Amazon frente a otros modelos al enfrentamiento aquí planteado.

La conclusión operativa, antes de realizar una prueba, es condicional. Nova 2 Lite puede evaluarse como modelo multimodal de la familia Nova 2 mediante Amazon Bedrock. Claude Fable 5.1 puede evaluarse en la ruta y las condiciones de disponibilidad que documenta Anthropic. La selección sólo será defendible después de fijar una ruta de acceso, un corpus congelado, una definición de corrección, una política de reintentos y una forma homogénea de imputar los costes auxiliares.

Una comparación útil debe separar tres planos. El primero es la capacidad declarada por cada proveedor: modalidades admitidas, APIs, manejo de documentos y controles disponibles. El segundo es el resultado medido en un conjunto documental concreto. El tercero es el riesgo de operación: datos incompletos, OCR defectuoso, documentos no equivalentes, cambios de versión, cuotas, políticas de retención y revisión humana. Confundir esos planos suele producir una decisión aparentemente cuantitativa pero difícil de auditar.

Modelos, rutas de acceso y asimetrías que deben fijarse

Amazon documenta Nova 2 Lite en Amazon Bedrock, incluidos identificadores de modelo, opciones de inferencia y posibilidades de uso regional o global. La documentación de Nova también describe capacidades relacionadas con comprensión de documentos, PDF, tablas y diseños. Esas capacidades deben verificarse en la modalidad exacta contratada, porque una prueba de texto no equivale a una prueba que entregue imágenes o documentos al modelo.

Anthropic identifica Claude Fable 5.1 en su documentación y página de producto, donde también comunica disponibilidad, precios y capacidades relacionadas con PDF y tablas. Antes de comparar, el equipo debe registrar el identificador exacto usado, la fecha, la región o ubicación de procesamiento cuando aplique, la versión de API, los límites configurados, el presupuesto de salida y cualquier configuración de razonamiento o caché. Sin ese registro, un resultado posterior puede no ser repetible.

Existe una asimetría metodológica potencial en la salida estructurada. La documentación de Anthropic sobre structured outputs describe un mecanismo basado en JSON Schema y advierte que la compatibilidad depende de la plataforma y del modelo. Según la información aportada, Fable 5.1 no figura entre los modelos de Bedrock compatibles con structured outputs. Esto no demuestra que Fable 5.1 no pueda producir JSON válido en otras rutas; sí obliga a documentar qué mecanismo se usó en cada lado y a no presentar dos integraciones distintas como si fueran idénticas.

Hay dos opciones aceptables, con implicaciones distintas. La primera es usar la interfaz nativa de cada proveedor y medir el sistema realmente desplegable, declarando las diferencias de plataforma. La segunda es imponer un denominador común: un prompt que exija JSON, validación externa contra el mismo esquema y un número idéntico de reintentos. La segunda reduce ventajas de integración específicas; la primera refleja mejor la experiencia operativa. No deben mezclarse ambas sin etiquetarlas como experimentos separados.

Diseño reproducible para extracción estructurada

El corpus debe congelarse antes de observar los resultados y representar el trabajo que se pretende automatizar. Una partición práctica incluye texto digital limpio, tablas simples, tablas de varias páginas, escaneos, formularios, documentos con campos ambiguos y documentos incompletos. Debe conservarse el archivo original, un identificador no sensible, el tipo documental, el idioma, el canal de entrada y las incidencias conocidas. Si se usan datos reales, el conjunto de evaluación debe respetar las políticas internas y contractuales aplicables.

Cada documento necesita una verdad de referencia independiente del modelo. Para los campos críticos, dos revisores deberían anotar el valor esperado, la ausencia legítima, la ambigüedad y la evidencia visual o textual que lo sustenta. Cuando discrepen, una tercera revisión o una regla de adjudicación debe resolver el caso. El porcentaje de documentos doblemente revisados y los desacuerdos no resueltos han de publicarse como parte de la incertidumbre, no ocultarse dentro de una sola etiqueta de exactitud.

El esquema debe representar tanto el dato como su estado. Por ejemplo, una fecha puede ser válida, ausente, ilegible, ambigua o fuera del alcance. Forzar siempre una cadena puede convertir una omisión en una invención. Conviene exigir campos de evidencia, nivel de confianza expresado bajo reglas propias y una lista de incidencias; sin embargo, una confianza declarada por el modelo no prueba que esté bien calibrada. Se mide comparando esa señal con los errores observados.

El prompt debe ser idéntico en el objetivo semántico: extraer sólo lo visible o explícitamente inferible conforme a una regla documentada, devolver ausencia cuando falte evidencia y no completar valores plausibles. Si la interfaz de un proveedor añade instrucciones de sistema o elementos de formato obligatorios, se preservan, se archivan y se contabilizan como parte de la configuración. También se registra si hubo conversión previa de PDF, OCR, reducción de imágenes o división de páginas.

Las ejecuciones repetidas son necesarias incluso cuando la configuración parezca determinista. Como mínimo, cada combinación de modelo, tipo de documento y configuración debe ejecutarse tres veces. Los resultados han de informar dispersión y, cuando el tamaño muestral lo permita, intervalos de incertidumbre. Una diferencia aislada de pocos campos no debe convertirse en una recomendación de compra si cae dentro de la variación observada o procede de pocos documentos.

Métricas que importan: formato, significado, tiempo y coste

La tasa de JSON válido mide cuántas respuestas pueden analizarse sin una reparación que altere su contenido. Es necesaria, pero no suficiente. Un JSON perfectamente válido puede contener un proveedor equivocado, un importe inventado o una fecha desplazada. Por ello, debe combinarse con exactitud por campo y con exactitud por documento. Esta última puede definirse de forma estricta: un documento sólo cuenta como correcto si todos los campos críticos coinciden con la referencia y no aparecen valores no sustentados.

Las omisiones y las alucinaciones deben contarse por separado. Una omisión es un campo que debía extraerse y falta o se marca erróneamente como ausente. Una alucinación es un valor presentado como extraído sin respaldo en el documento o contrario a la referencia. En contratación, facturación o cumplimiento, las alucinaciones pueden tener un coste operativo mayor que una omisión, porque una revisión puede detectar un vacío con más facilidad que un dato plausible y erróneo. La ponderación debe reflejar el riesgo del proceso, no una preferencia genérica.

La señalización de incertidumbre debe evaluarse como clasificación. Si el modelo señala duda en casos realmente ambiguos o ilegibles, aporta valor para el enrutamiento a revisión humana. Si declara alta seguridad en errores graves, esa señal no permite automatizar decisiones. El informe debe incluir cobertura: qué fracción del corpus puede pasar sin revisión bajo un umbral de riesgo; y precisión condicionada: cuántos de esos documentos aceptados son efectivamente correctos.

La latencia debe medirse de extremo a extremo, desde que el sistema inicia la solicitud hasta que obtiene una salida validada o agota los reintentos. Hay que separar percentiles, no sólo promedios, y medir por tamaño y complejidad de documento. También deben separarse tiempos de carga, conversión de archivos, OCR si existe, inferencia, validación y reintento. De lo contrario, un cuello de botella externo puede atribuirse erróneamente al modelo.

El coste útil no es el precio anunciado por token. Para cada documento se suman entrada, salida, lecturas o escrituras de caché aplicables, procesamiento de archivos, reintentos y servicios auxiliares. Después se divide el coste total por el número de documentos que superan la definición de corrección. Si se exige revisión humana, hay dos medidas distintas: coste por resultado automático correcto y coste por resultado final aceptado, incluyendo el trabajo de revisión. Ambas son válidas, pero responden a decisiones diferentes.

Resultados: qué se puede afirmar hoy y cómo interpretar una futura prueba

No se han aportado mediciones del corpus propuesto para Amazon Nova 2 Lite ni para Claude Fable 5.1. Por ello, las secciones de resultados deben permanecer sin un veredicto de rendimiento hasta ejecutar y publicar el protocolo. La documentación de AWS puede justificar que Nova 2 Lite entre en la evaluación por sus capacidades declaradas de comprensión documental y modalidades relacionadas. La documentación de Anthropic puede justificar la inclusión de Fable 5.1 por las capacidades y condiciones que comunica para PDF y tablas. Ninguna de esas descripciones reemplaza una tasa observada de campos correctos.

Un resultado favorable para Nova 2 Lite en documentos de texto limpio no demostraría superioridad en escaneos, tablas complejas o contratos ambiguos. Del mismo modo, un resultado favorable para Claude Fable 5.1 en una configuración con una función de salida estructurada no demostraría que la ventaja procede del modelo y no de la integración. El desglose por categoría documental no es un detalle editorial: es la base para que un equipo aplique la conclusión a su propia cartera.

AWS publica un ejemplo de arquitectura que combina Nova 2 Lite con otro modelo Claude para digitalización de documentos escaneados. Ese material es útil como ilustración de una arquitectura de varias etapas y de la necesidad de repartir costes y tareas. No debe usarse como evidencia comparativa entre Nova 2 Lite y Claude Fable 5.1: el ejemplo citado utiliza otro modelo Claude y un caso documental diferente.

Una prueba futura debería reportar también los fallos recurrentes, no sólo agregados. Entre las categorías útiles están: celda de tabla asignada a la columna incorrecta, confusión entre subtotal e importe total, fecha normalizada de modo incorrecto, parte contratante equivocada, error por rotación o baja resolución, pérdida de una página, valor no visible e incumplimiento del esquema. Un conjunto de ejemplos anonimizados y revisables ayuda a detectar si una media alta oculta un tipo de fallo inaceptable.

Privacidad, retención y condiciones que pueden invalidar una decisión basada sólo en métricas

La elección de ruta de acceso afecta tanto a la evaluación como al despliegue. Amazon Bedrock documenta políticas de retención de datos y controles de seguridad y privacidad. Anthropic documenta por separado las condiciones de retención de su API, incluidas opciones como la retención cero cuando estén disponibles bajo las condiciones aplicables. Estas políticas deben verificarse para la cuenta, el producto, la región y el acuerdo contractual concretos; una afirmación general sobre un proveedor no sustituye esa comprobación.

Antes de cargar documentos reales, el equipo debe clasificar los datos, determinar si contienen información personal, financiera, contractual o regulada, y confirmar quién puede acceder a prompts, respuestas, archivos y registros. Debe comprobar también si el esquema JSON, los metadatos de trazabilidad y los ejemplos de error contienen información sensible. La minimización de datos puede ser más importante que una diferencia pequeña de latencia o de precio.

La residencia de datos, el cifrado, la gestión de identidades, las claves gestionadas por el cliente y los controles de red pueden condicionar qué servicio es admisible. AWS describe controles empresariales para Bedrock, incluidos mecanismos de seguridad y aislamiento. La evaluación debe registrar qué controles se activaron, porque una configuración de laboratorio con permisos amplios puede no representar la arquitectura aprobable en producción.

No se debe asumir que los datos no se usan para entrenamiento, que se eliminan de inmediato o que se procesan en una ubicación determinada sin contrastarlo con la documentación y el contrato vigentes. Las políticas cambian y pueden depender de la modalidad de acceso. Si una exigencia de cumplimiento no está confirmada, la decisión debe ser «pendiente de validación», no una recomendación técnica provisional presentada como suficiente.

Decisión por escenario y límites de esta comparación

Para un escenario de menor coste aceptable, la decisión debe basarse en coste por documento correcto dentro de un umbral mínimo de exactitud, no en el precio unitario anunciado. Para máxima exactitud, debe prevalecer la exactitud por documento crítico, la tasa de alucinaciones y la calibración de la incertidumbre. Para menor latencia, hay que mirar percentiles extremos a extremos bajo la carga prevista. Para alta criticidad, la opción adecuada puede ser una combinación de extracción, validación determinista y revisión humana, aunque un modelo obtenga una buena media agregada.

Cuando ambos modelos incumplen un umbral definido para campos críticos, la conclusión correcta es que ninguno debe aprobar automáticamente esos documentos en esa configuración. Las alternativas son mejorar la calidad de entrada, separar OCR de extracción, dividir documentos por páginas o secciones, restringir el esquema, añadir reglas de validación, usar enrutamiento por riesgo o mantener revisión humana. Cambiar de modelo sin diagnosticar la causa puede desplazar el error sin resolverlo.

El calendario de actualización debe depender de cambios materiales: nuevo identificador de modelo, cambio de precios, modificación de límites o modalidades, actualización de políticas de datos, cambio de región, alteración del corpus de producción o aparición de un nuevo tipo documental. Cada nueva medición debe conservar la versión anterior para evitar comparar resultados incompatibles. La recomendación debe caducar explícitamente si cambian componentes que no se volvieron a probar.

En síntesis, las fuentes permiten establecer que existen capacidades y controles documentados que justifican evaluar ambas opciones, pero no permiten cuantificar una ventaja entre ellas en extracción fiable de documentos. La decisión trazable exige una prueba propia y repetible. Hasta que se publique, cualquier preferencia debe tratarse como hipótesis de integración, coste o cumplimiento, no como un resultado de calidad demostrado.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.