No. 003Determinismo9 min de lectura

El número de ingresos equivocado con toda la seguridad del mundo: por qué los LLM no saben sumar

Un modelo te entrega una cifra de ingresos con una postura impecable y sin aritmética detrás. La investigación dice que el fallo es estructural — y también lo es la solución.

En octubre de 2025, Deloitte devolvió dinero al gobierno australiano. La firma había entregado una revisión de AU$440.000 al Departamento de Empleo y Relaciones Laborales; el informe publicado contenía una cita fabricada de una sentencia de un tribunal federal y referencias a artículos académicos inexistentes (The Guardian, 2025). Una versión revisada reveló que GPT-4o había sido utilizado en la redacción. Informaciones posteriores situaron el reembolso en aproximadamente AU$97.000 — el último pago del contrato.

Un detalle importa más que el dinero. Las fabricaciones no fueron detectadas por la revisión interna de la firma, ni por la del cliente. Las detectó un académico externo que comprobó las referencias. El entregable había superado cada capa de escrutinio para la que fue diseñado, porque nada en él parecía incorrecto.

Esa es la categoría: no el modelo que falla, sino el modelo que responde. Pídele a un modelo de lenguaje que sume los ingresos de doscientas filas y obtendrás una respuesta con la magnitud correcta, el símbolo de moneda correcto y una frase segura alrededor. Lo que no obtendrás de forma fiable es la suma. Una respuesta ausente se detecta. Una respuesta incorrecta con buena postura se reenvía al consejo de administración.

Y la postura nunca se rompe, porque la confianza también es texto generado. El modelo no sabe que está equivocado; no hay ninguna alarma interna que suprimir. La frase que afirma el número y el número mismo provienen del mismo lugar — el siguiente token probable.

Plausible no es calculado

El instinto es archivar los números incorrectos bajo madurez del modelo: seguramente la próxima versión suma correctamente. La investigación dice que el fallo es estructural, y es inusualmente consistente en cuanto al motivo.

GPT-4, al que se le pidió multiplicar dos números de tres cifras, acertó el 59% de las veces sin indicaciones adicionales; ChatGPT, el 55% (arXiv, 2023). Con cuatro cifras, GPT-4 cayó al 3%. Con cinco, al 0%. Los autores de Faith and Fate rastrearon el mecanismo: los transformers abordan los problemas de composición haciendo coincidir fragmentos linealizados de lo que han visto — búsqueda de patrones, no procedimiento. El precipicio se sitúa exactamente donde los patrones se agotan.

La suma no es más segura. Un análisis de 2025 encontró que los LLM suman con una heurística de anticipación de un dígito en lugar de un algoritmo: la precisión colapsa exactamente donde los acarreos se propagan más allá de un dígito, independientemente del prompting o la tokenización, y los fallos son predecibles solo a partir de la estructura de acarreo (arXiv, 2025). Sistemático, no aleatorio. El modelo no está casi calculando. Está haciendo algo distinto que a menudo coincide con el cálculo.

GSM-Symbolic de Apple cerró el último resquicio — que quizás esto solo afecta a la aritmética difícil (Apple, 2024). Toma problemas de matemáticas de primaria y cambia solo los números: todos los modelos de última generación evaluados empeoraron. Añade una cláusula plausible pero irrelevante: la precisión cayó hasta un 65%. Y la precisión variaba notablemente entre instancias nuevas de la misma plantilla de pregunta — el mismo problema, reformulado, devuelve una distribución diferente de respuestas. Este último hallazgo explica el problema de la demo. Una demo es una extracción de la distribución. Una auditoría es la distribución.

El veredicto de los autores — «los LLM actuales no son capaces de razonamiento lógico genuino» — es inusualmente directo para un artículo de investigación. Nadie lo ha refutado.

100 50 0 accuracy, % zero-shot scratchpad 59 92 3×3-digit 4 4×4-digit 0 5×5-digit
Precisión de GPT-4 en multiplicación de n dígitos × n dígitos, zero-shot frente a scratchpad paso a paso. Faith and Fate, NeurIPS 2023.

Las soluciones obvias, medidas

Cada equipo que se enfrenta a este fallo recurre a las mismas cuatro soluciones. Cada una ha sido medida.

Recuperación. FinanceBench planteó a GPT-4-Turbo 150 preguntas sobre informes financieros públicos, con un sistema de recuperación que suministraba los documentos. Respondió incorrectamente o se negó a responder en el 81% de los casos (Patronus AI, 2023). Dieciséis configuraciones — GPT-4-Turbo, Llama 2, Claude 2, almacenes vectoriales, contexto largo — mostraron debilidades en 2.400 respuestas revisadas manualmente, y los modelos alucinaron cifras siempre que las páginas de evidencia no se suministraban perfectamente. La recuperación obtiene el documento. El modelo sigue errando el número.

Anclaje. La BBC dio a ChatGPT, Copilot, Gemini y Perplexity acceso directo a sus propios artículos y les preguntó sobre las noticias. El 51% de las respuestas tenía problemas significativos; el 91% tenía al menos alguno. El 19% de las respuestas que citaban contenido de la BBC introdujeron errores factuales — afirmaciones incorrectas, números incorrectos, fechas incorrectas — y el 13% de las citas atribuidas a artículos de la BBC fueron alteradas o nunca existieron (BBC, 2025). La fuente estaba a mano. Los números siguieron distorsionándose.

Un modelo más capaz. La propia tarjeta de sistema de OpenAI reporta que o3 alucina en el 33% de los prompts de PersonQA y o4-mini en el 48% — frente al 16% del anterior o1 (OpenAI, 2025). Según la medición del propio proveedor, los nuevos modelos de razonamiento alucinan dos o tres veces más que su predecesor. o3 simplemente hace más afirmaciones — más correctas y más fabricadas, entregadas con la misma temperatura de certeza.

Mejor prompting. El prompting con scratchpad paso a paso eleva la multiplicación de tres dígitos de GPT-4 del 59% al 92% (arXiv, 2023). Mejor — y aun así un producto incorrecto de cada doce. Incluso el ajuste fino exhaustivo de GPT-3 en multiplicación de cuatro dígitos produjo aproximadamente un 40% en problemas de cuatro dígitos no vistos, y un 0% con cinco dígitos. El techo es el mecanismo, no el prompt.

Cada solución mueve las probabilidades. Ninguna cambia quién hace la aritmética. La respuesta sigue siendo muestreada de una distribución de números plausibles, y exactamente uno de los miembros de esa distribución es la suma.

0 50 100 % RETRIEVAL · FINANCEBENCH 2023 wrong or refused 81% GROUNDING · BBC 2025 significant issues 51% factual errors introduced 19% REASONING · PERSONQA, OPENAI 2025 o1 (predecessor) 16% o3 33% o4-mini 48%
Tasas de fallo tras la solución. FinanceBench 2023 · BBC 2025 · Tarjeta de sistema de OpenAI o3 / o4-mini 2025.

Cambiar quién hace la aritmética

La respuesta estructural es una división del trabajo trazada exactamente a lo largo de la línea de competencia. Los modelos de lenguaje son excelentes con el lenguaje e impredecibles con los libros de cuentas, por lo que el modelo nunca debe ser quien calcule.

SQAI está construido sobre esa división. El modelo redacta una intención tipada — sum amount where region = "east" — y un motor determinista la ejecuta como código compilado: validado contra un contrato anclado por hash, comprobado contra la política, calculado en float64 en un único hilo, devuelto con procedencia.

{
  "status": "ok",
  "value": 2130.5,
  "rows_matched": 5
}

Ese 2130.5 no es un token probable. Es la suma, producida por un núcleo determinista a partir de una superficie de 4.574 capacidades de solo lectura distribuidas en 445 módulos — 4.564 de ellos completamente deterministas — respondiendo en 0,83–0,93 ms en caliente.

Determinista significa verificable. finance.npv(0.1, [-1000, 300, 420, 560, 680]) devuelve 505.020148896933 bajo el hash de cómputo b74f67d0… — el mismo valor y el mismo hash tanto si la llamada se realiza desde TypeScript como desde Python, porque los resultados se hashean sobre una única forma JSON canónica. La afirmación está delimitada honestamente: determinista dentro del ámbito de ejecución declarado, con un sobre que registra la versión del runtime, la plataforma, el modo de precisión y el número de hilos en lugar de prometer demasiado. La respuesta de un modelo al mismo prompt no puede garantizar coincidir consigo misma en la siguiente ejecución. Esta se reproduce byte a byte, meses después, en cualquiera de los dos lenguajes.

Hay una segunda fuga, y la mayoría de los stacks la dejan abierta. Conecta un motor de cómputo, luego vierte las filas brutas de la consulta en el contexto «para resumir» — y el modelo silenciosamente re-deriva, y re-inventa, números a partir de las filas. SQAI trata el contexto como un límite gobernado: como máximo 25 filas, 250 celdas y 32.000 bytes llegan al modelo, con un límite predeterminado de 100 filas y un techo de ejecución estricto de 1.000. El truncamiento siempre se declara, de modo que el modelo no puede afirmar honestamente haber totalizado lo que vio. Las filas parciales nunca se muestran, para que ningún registro incompleto lo tiente a completar desde la imaginación. Los agregados se calculan antes del límite. El modelo recibe la respuesta, no los deberes.

Y la política no es un prompt. Las fuentes, campos y funciones permitidos se fijan en código en el momento de createSQAI() y se comprueban en proceso antes de la ejecución; la entrada de herramienta del modelo no lleva ningún campo de política, por lo que no hay nada que pueda ampliar. Solicitar una capacidad fuera de la política no produce una solución creativa — produce policy_denied_function. El argumento es el mismo que hay detrás de no dejar que los agentes escriban SQL: no gobiernes el texto generado con instrucciones de mejor esfuerzo; gobierna la ejecución con listas de permitidos que el texto no puede tocar.

GOVERNED BOUNDARY MODEL language in, language out sum(amount) · region = "east" typed intent — never a SQL string ENGINE contract → policy → execute float64 · 1 thread · sub-ms warm value 2130.5 · rows 5 plan_hash f87610d8afeb… byte-identical replay · TS ≡ PY answer, not rows ≤ 25 rows · ≤ 250 cells · ≤ 32,000 B truncation always declared
La división del trabajo: el modelo redacta una intención tipada; un núcleo float64 calcula; los límites de filas mantienen los datos brutos fuera del contexto.

¿Quién hizo la aritmética?

La próxima vez que un sistema de IA te entregue una cifra de ingresos, una pregunta clasifica cada arquitectura del mercado: ¿quién hizo la aritmética?

Si la respuesta es «el modelo», tienes un número con una postura excelente y una procedencia desconocida, y el único camino de verificación es que un humano rehaga el trabajo — precisamente lo que intentabas automatizar. Las fabricaciones de Deloitte fueron detectadas porque un académico ajeno al proceso decidió comprobarlo. Eso no es un control. Es suerte.

Si la respuesta es «un motor determinista, y aquí está el hash», la verificación es una reproducción: misma intención, mismo motor, mismos bytes. El fallo se vuelve más sutil — y más silencioso — cuando el número incorrecto proviene de un join expandido en lugar de una suma incorrecta, que es otra historia. Pero la disciplina cabe en una frase: el modelo escribe la pregunta, nunca la respuesta.

El número de ingresos incorrecto no se anuncia. Llega formateado, citado y seguro de sí mismo — y con cinco dígitos de multiplicación, nunca es correcto. Construye el pipeline para que no pueda entrar.