Cómo calculamos

Ganancia de información

El lector llega a un texto con preguntas: qué tiene que pasar exactamente, dónde, cuándo, cuánto, en qué condiciones y por qué. La ganancia de información es la proporción de esas preguntas que el texto responde. Con el 100 %, al lector no le queda nada por preguntar; un formulario con los campos vacíos está cerca del 0 %. El modelo de tu navegador estima esa proporción como una valoración de 0 a 10 y la muestra en pasos del 5 %.

La idea se remonta a Claude Shannon, que midió la información en bits: un bit es la respuesta a una pregunta de sí o no (Shannon, 1948). Un reporte de errores que dice «las exportaciones grandes fallan» deja al desarrollador preguntándose si son 12.300 filas u 11.000, una pregunta de sí o no tras otra; «las exportaciones de más de 10.000 filas fallan» las responde todas a la vez. Warren Weaver describió tres niveles de la comunicación: si los símbolos llegan, si transmiten el significado previsto y si cambian lo que hace el receptor (Weaver, 1949). Slopcheck trabaja en el segundo y el tercer nivel.

Ganancia de información en SEO

En SEO, la ganancia de información (en inglés, information gain) es lo que una página aporta más allá de las páginas que su lector ya ha visto. Google tiene una patente sobre una puntuación así, «Contextual estimation of link information gain» (US 11,354,342 B2, concedida el 7 de junio de 2022). Una patente no demuestra que una puntuación se use para posicionar; las directrices públicas de Google preguntan si el contenido aporta «información, informes, investigaciones o análisis originales» (en inglés, «original information, reporting, research, or analysis», Google Search Central). Slopcheck mide la parte que 1 texto muestra por sí solo, sin compararlo con otras páginas: la proporción de preguntas de su lector que responde, del 0 al 100 %.

Lo que descarta una afirmación

Rudolf Carnap y Yehoshua Bar-Hillel describieron la vertiente semántica de la información: una afirmación contiene más información cuantos más estados posibles del mundo descarta (Carnap y Bar-Hillel, 1952). «La exportación falla en pedidos de más de 500 líneas en Chrome 128» descarta mucho más que «la exportación a veces falla». Un umbral explícito es la forma más fuerte: «3.1.4 funciona, 3.2.0 falla» le dice al desarrollador qué versión abrir.

Que una afirmación sea cierta es otra cuestión (Stanford Encyclopedia of Philosophy). Slopcheck no comprueba hechos: «pedidos de más de 500 líneas» puntúa igual tanto si el umbral real es 500 como si es 5000.

Lo que importa al lector

Ronald Howard mostró en 1966 que la información vale lo que cambia en una decisión (Howard, 1966). Para un desarrollador, «Chrome 128» decide cuál de 3 navegadores probar; «la exportación es importante» no decide nada. En una página de producto, «4 € por usuario al mes, los primeros 30 días gratis» cambia la decisión de compra; «una experiencia fluida», no. En un reporte de errores, la versión, los pasos y el umbral son lo que cambia el siguiente paso del desarrollador.

Slop

El slop es la parte del texto, contada en palabras, que no responde a ninguna pregunta del lector. Distinguimos 4 tipos: frases vacías e intercambiables entre textos, obvias que no descartan nada de lo que el lector se planteaba, irrelevantes que no cambian ninguna decisión e irresolubles, por ejemplo «como comentamos» o «igual que allí». Si el texto repite lo que ya ha dicho, la repetición también cuenta. El resultado resalta cada frase de slop.

En términos de conversación, el slop incumple 2 de las máximas que describió Paul Grice: sé tan informativo como se requiere, y no más, y sé pertinente (Grice, 1975). Las repeticiones son lo que Shannon llamó redundancia: la parte de un mensaje que el lector puede predecir a partir del resto.

El estilo no es slop: «arreglamos la exportación CSV» y «se ha resuelto la incidencia de la exportación CSV» cuentan igual.

Cómo se relacionan las dos cifras

El slop no contiene información, así que cuanto más slop tiene un texto, más bajo es el techo de su ganancia: un texto con un 60 % de slop obtiene como máximo alrededor de un 50 %, y uno con un 95 % de slop o más, como máximo un 10 %. Solo se muestra un 100 % cuando ninguna frase es slop; si no, la ganancia se queda en el 95 %. La longitud no es el objetivo: un reporte de errores de 50 palabras puede obtener un 90 %.

Reportes de errores, tareas y páginas de producto

Anotamos 27 preguntas que el lector lleva a un texto: 7 para cualquier texto, 8 para reportes de errores, 7 para tareas y 5 para páginas de producto. Un reporte de errores responde qué versión, qué pasos, qué se esperaba y qué pasó, si ocurre siempre o a veces y desde qué release. Una tarea o historia de usuario responde qué, dónde, por qué, cómo comprobar que está hecha y qué no tocar; un ejemplo de buenos criterios de aceptación: «34 ajustes, 4 pestañas, sin cambios de texto». Una página o descripción de producto responde para quién es, qué hace, qué lo demuestra, el precio y el siguiente paso. El modelo aprendió estas diferencias de 2424 ejemplos valorados por un modelo de lenguaje, así que no necesitas elegir el tipo de texto antes de pegarlo.

5 versiones en 4 días

La versión 1, del 19 de octubre de 2026, contaba palabras funcionales, muletillas y detalles concretos por cada 100 palabras. La versión 2 añadió la rareza de las palabras, medida con listas de frecuencia que contamos a partir de unas 600.000 palabras de texto de Wikipedia por idioma; en 55 páginas web valoradas por dos modelos de lenguaje resultó ser ruido (AUROC de 0,45 a 0,49), así que la descartamos. La versión 3 juzgaba por la concreción por cada 100 palabras; en 37 páginas nuevas reservadas para pruebas, su veredicto de «sustancia insuficiente» acertó en 1 caso de 9, así que pasó a ser una pista.

La versión 4 usaba un catálogo de unos 1000 patrones en 5 idiomas y separó las páginas infladas de las densas en esas mismas 37 páginas (AUROC de 0,75; habíamos visto esos resultados durante el desarrollo, así que la cifra es optimista). En reportes de errores reales quedó al nivel del azar (de 0,47 a 0,52). Ese fallo nos llevó de contar palabras a contar las preguntas abiertas del lector, y a la versión 5 (s2) el 22 de octubre; el 24 de octubre la reentrenamos para 12 idiomas (s3).

Lo que nos enseñaron los gestores de incidencias

Tomamos 1355 reportes de Mozilla Bugzilla de 2023 a 2025. Los reportes cerrados como incompletos o como «works for me», o cuyo autor recibió una petición de más información, eran más largos que los corregidos sin esa petición (una mediana de 165 palabras frente a 124) y más concretos: las personas externas rellenan la plantilla completa, que aparece en el 38 % de los reportes «works for me» y en el 14 % de los corregidos, mientras que los ingenieros escriben notas breves que se apoyan en un contexto compartido. El resultado medía quién había escrito el reporte, así que a partir de entonces comparamos reportes del mismo autor.

En Apache Jira reunimos 11.129 reportes de errores abiertos desde 2022 en 165 proyectos y comparamos los corregidos con los cerrados como «Cannot Reproduce» o «Incomplete». Un hallazgo dio forma al método: un modelo de lenguaje leyó 240 de estos reportes, 120 pares del mismo autor, sin conocer el resultado ni el autor. Cuando le preguntamos si se indicaba una versión o un entorno, encontró uno más a menudo en los reportes mal recibidos (63 % frente a 50 %). Cuando le preguntamos qué necesitaría todavía un desarrollador, nombró la versión o el entorno más a menudo en esos mismos reportes (48 % frente a 33 %). Mencionar un detalle no es lo mismo que responder a la pregunta.

Reglas de una revisión manual

Valoramos 35 textos a mano, la mayoría en una escala de 0 a 10: 0 es un formulario vacío, con 5 o 6 la tarea se puede hacer tras un par de preguntas, 9 deja una pregunta abierta y 10 no deja nada que añadir. En 28 de estos textos, nuestro primer catálogo de preguntas planteó 86 preguntas; marcamos 35 de ellas, 26 como justas y 9 como excesivas. El resultado es una guía escrita de 37 reglas y 33 casos de prueba.

Ejemplos de reglas: una afirmación sin límite significa siempre y en todas partes, así que la falta de versión no cuesta nada salvo que el texto diga «a veces» o «después de la actualización»; una prohibición solo cuenta si cierra un camino que la tarea da a entender; los requisitos contradictorios son lo que más cuesta. En una prueba, los mismos hechos, reescritos con un enlace explícito y un objeto con nombre, pasaron de 1 a 9–10 sobre 10. En otra, un reporte valorado con un 10 a mano se había cerrado como «Cannot Reproduce»: el resultado en el gestor de incidencias es una señal, no un veredicto.

Modelos de lenguaje como evaluadores y como profesor

Convertimos las 37 reglas en una guía de valoración para grandes modelos de lenguaje y comparamos 5 modelos en los 27 textos con valoración manual numérica. Las reglas salieron de estos textos, así que esto muestra con qué fidelidad sigue cada modelo las reglas, no cómo se comporta con textos nuevos: los dos mejores quedaron a 1 punto o menos de la valoración manual en 22 de 27 textos (correlación de rangos de hasta 0,94); el más débil, en 12 de 27.

Después, uno de los dos valoró 2424 textos frase por frase: 600 tareas y reportes de errores públicos de Apache Jira, 384 textos con los mismos hechos que modelos de lenguaje escribieron en 4 estilos, 600 textos que el mismo modelo escribió para el entrenamiento en alemán, polaco, checo, croata y ruso, y 840 textos (120 en cada uno de estos idiomas: eslovaco, esloveno, búlgaro, francés, italiano, español y neerlandés) que modelos de lenguaje escribieron sin ver las reglas. Son 18.420 frases etiquetadas, el 21,4 % de ellas slop. El modelo pequeño de tu navegador aprendió de estas etiquetas. En validación cruzada coincide con el modelo profesor con una correlación de rangos de 0,85, y en textos de los que no aprendió encuentra las frases de slop del profesor con un AUROC de 0,92. En 25 textos valorados a mano coincide con las valoraciones manuales con una correlación de rangos de 0,81, pero las reglas que se aplican encima salen de esos mismos textos, así que las pruebas con datos reservados que describimos más abajo son la medida más justa.

Ningún modelo de lenguaje lee tu texto cuando lo revisas. Una llamada a un modelo enviaría el texto a un tercero, no siempre daría la misma respuesta al mismo texto y costaría dinero en cada revisión; el modelo pequeño funciona con unos 350 KB de pesos fijos.

Predicciones escritas de antemano

En 5 experimentos escribimos nuestras predicciones en un archivo antes de hacer la prueba; para la prueba de patrones del 20 de octubre de 2026, la suma de verificación MD5 del archivo empieza por ff01ce1a. Predijimos que la versión directa de un texto superaría a la de estilo asistente en entre el 85 % y el 95 % de los pares; lo hizo en el 79 %. Predijimos que los reportes rechazados de Bugzilla serían más cortos; fueron más largos, con una mediana de 165 palabras frente a 124. En los pares de Jira del mismo autor fallaron 3 de 4 predicciones. Tras el fallo con Bugzilla, todas las comparaciones posteriores usaron reportes del mismo autor.

Lo que no funcionó

La rareza de las palabras (AUROC de 0,45 a 0,49). La proporción de palabras funcionales y muletillas, que en páginas reservadas solo alcanzó un AUROC de 0,31, peor que el azar. Un veredicto de «sustancia insuficiente» que acertó 1 vez de cada 9. Contar unidades de significado o marcar una lista de comprobación de completitud de 5 puntos, que coincidió con una lectura del texto completo con una correlación de rangos de solo 0,18 a 0,26. 8 indicadores basados en señales de buscadores, descartados en la fase de diseño. Comparar una página con los primeros 3 a 10 resultados de búsqueda, lo que requiere una API de búsqueda de pago. Versiones amplias de las reglas explícitas, que saltaron en 33 reportes de Jira; todas las alertas que revisamos eran falsas. Un modelo de lenguaje en el momento de la revisión: fue el que más se acercó a las valoraciones manuales, pero enviaría tu texto a un tercero.

Cómo probamos el método

Reservamos 24 encargos en inglés y alemán, cada uno escrito en 4 versiones por modelos de lenguaje. La versión directa puntúa más que la inflada en los 24 pares y más que la de estilo asistente en el 83 %. Para cada uno de los 7 idiomas añadidos el 24 de octubre reservamos otros 6 encargos en 4 versiones: la versión directa supera a la inflada en todos los pares, y a la de estilo asistente en el 100 % de los pares en eslovaco y esloveno, el 92 % en italiano y neerlandés, el 83 % en búlgaro y francés y el 58 % en español.

En 120 pares reservados de reportes de Jira del mismo autor, el reporte corregido puntúa más en cerca del 60 % de los pares. Un modelo de lenguaje que lee a ciegas esos mismos 240 reportes, sin el resultado ni el autor, llega al 64 %. Los encargos en inglés y alemán y los pares de Jira quedaron fuera del entrenamiento, pero los usamos para elegir entre variantes de las reglas explícitas, así que con textos nuevos los resultados pueden ser algo más bajos. Que un reporte acabe corregido o cerrado como «Cannot Reproduce» también depende del propio error: puede que ya esté corregido en una versión más nueva, que solo ocurra en un entorno o que venga de un error de configuración, así que en esta prueba el 100 % no es posible.

Cómo se calcula la estimación

Para el texto completo, el modelo lee 182 señales, como cifras, versiones, condiciones, umbrales, nombres, mensajes citados, palabras vagas, afirmaciones sin respaldo, repeticiones y encabezados de plantilla vacíos, y también palabras y pares de palabras asignados por hash a 16.384 celdas; un segundo modelo con 68 señales y las mismas palabras con hash decide en cada frase si es slop. El modelo del texto es una regresión lineal sobre estas señales y el de las frases, una regresión logística; los dos se ajustaron con los 2424 textos valorados. Encima del modelo se aplican 3 reglas de la revisión manual. Una hora de inicio posterior a la fecha límite cuesta 25 puntos. Una tarea que empieza con «dividir en 4 pestañas» y nunca dice qué hay que dividir obtiene como máximo un 20 %. Una plantilla con encabezados vacíos obtiene como máximo un 10 %. Los pesos ocupan unos 350 KB y se cargan con la página, y un texto de 3000 caracteres se revisa en menos de 100 milisegundos.

Frases e idiomas

Dividimos el texto en frases en los puntos, los signos de interrogación y de exclamación, los puntos suspensivos y los saltos de línea, pero no dentro de «v8.1», «1.200» o una dirección web, ni después de una fecha como «7. Juni». Se admiten 12 idiomas: inglés, polaco, checo, eslovaco, croata, esloveno, búlgaro, alemán, francés, italiano, español y neerlandés. El idioma se detecta automáticamente: acierta en el 99,6 % de los casos en nuestros conjuntos de prueba anteriores y en el 97,1 % de los textos cortos en los idiomas nuevos. Las listas de frases de slop de los 11 idiomas distintos del inglés las compilamos nosotros; para alemán, polaco, checo y croata no encontramos listas abiertas. Las revisiones gratuitas admiten de 80 a 3000 caracteres, lo que cubre el 97,5 % de los reportes de errores de Jira que reunimos, sin contar los bloques de código. Sesgo conocido: el idioma por sí solo desplaza la estimación unos puntos. Con las mismas señales, los textos en español, francés, checo e italiano puntúan de 5 a 8 puntos menos que los ingleses, y los alemanes y neerlandeses, unos 4 puntos más, así que compara las puntuaciones dentro de un mismo idioma.

Lo que no medimos

Slopcheck no mide quién escribió un texto, si es verdad ni cómo posicionará en Google o Bing. En una muestra del benchmark público RAID en inglés, los rasgos textuales basados en reglas detectaron como máximo el 28 % de los textos escritos por IA con una tasa de falsas alarmas del 5 %, y por eso no ofrecemos detección de autoría. Una nota de 2 líneas puede ser exactamente lo que necesita un equipo que comparte su contexto: la estimación solo ve el texto.

Preguntas

¿Cómo reviso si un texto tiene AI slop?

Pégalo en el campo de la página de inicio: de 80 a 3000 caracteres, hasta 5 textos al día gratis. Obtienes la ganancia de información, la proporción de slop y las frases de slop marcadas en el texto.

¿Se guarda o se envía mi texto a algún sitio?

No. La revisión se hace en tu navegador: el texto no se nos envía ni se guarda. El enlace del resultado lleva el texto en la parte de la dirección que va después del signo #, que los navegadores no envían a los servidores.

¿Qué textos puedo revisar?

Artículos, páginas de producto, publicaciones, tareas, historias de usuario y reportes de errores en 12 idiomas: inglés, polaco, checo, eslovaco, croata, esloveno, búlgaro, alemán, francés, italiano, español y neerlandés, de 80 a 3000 caracteres.

¿Cómo se escribe un buen reporte de errores?

Indica cómo reproducir el problema: qué pasos, qué versión, qué dispositivo y a partir de qué umbral empieza a fallar. En un estudio de 180 reportes de errores reproducibles de Android, al 92,2 % le faltaba al menos 1 paso (Johnson et al., 2022). «La exportación falla en pedidos de más de 500 líneas en Chrome 128» descarta mucho más que «la exportación a veces falla». Pega el reporte en la revisión para ver qué frases no responden a ninguna de estas preguntas.

¿Slopcheck es un detector de IA?

No. Slopcheck estima cuánto le dice un texto a su lector. No dice quién o qué lo escribió: un texto generado con hechos reales puede puntuar alto, y uno escrito a mano sin ninguno puntúa bajo.

¿En qué se diferencia de los comprobadores que buscan rastros de IA?

Las herramientas que cuentan rayas, «delve» o «tapestry» miran la superficie de un texto. Slopcheck mira lo que recibe el lector: un texto puede evitar todos esos rastros y aun así no responder a ninguna pregunta del lector.

¿Qué es un pasaporte de texto?

Un registro de un texto exacto: su hash, la ganancia de información, el slop, la versión del método y la fecha de la revisión, en una página con enlace propio. Quien tenga el texto puede pegarlo allí y ver si coincide: si cambia aunque sea 1 carácter, el hash cambia. Cada edición se guarda como una versión nueva con sus propias puntuaciones.

¿Necesito un plugin o un SDK para usar la API?

No. En el plan Equipo, la revisión es una solicitud HTTP con el texto. Encaja en un paso de CI, en un hook previo a la publicación en un CMS o en un campo de tu gestor de tareas.

Fuentes

1. C. E. Shannon (1948). A Mathematical Theory of Communication. Bell System Technical Journal
2. C. E. Shannon, W. Weaver (1949). The Mathematical Theory of Communication. University of Illinois Press
3. Google LLC (2022). Contextual estimation of link information gain. Patente de EE. UU. 11,354,342 B2
4. Google Search Central. Creating helpful, reliable, people-first content
5. R. Carnap, Y. Bar-Hillel (1952). An Outline of a Theory of Semantic Information. MIT Research Laboratory of Electronics
6. S. Sequoiah-Grayson, L. Floridi. Semantic Conceptions of Information. Stanford Encyclopedia of Philosophy
7. R. A. Howard (1966). Information Value Theory. IEEE Transactions on Systems Science and Cybernetics
8. H. P. Grice (1975). Logic and Conversation; las máximas se resumen en «Implicature», Stanford Encyclopedia of Philosophy
9. J. Johnson et al. (2022). An Empirical Investigation into the Reproduction of Bug Reports for Android Apps. SANER 2022, sección IV-C
10. Apache Software Foundation. Gestor de incidencias Jira, reportes de errores y tareas públicos de 2022–2026
11. Mozilla. Bugzilla, reportes de errores públicos de 2023–2025
12. L. Dugan et al. (2024). «RAID: A Shared Benchmark for Robust Evaluation of Machine-Generated Text Detectors». ACL 2024