Texto Claro: que sea más fácil de leer no lo decide el modelo, lo decide la fórmula

Esta entrada nace, otra vez, de dos sitios distintos a la vez. Por un lado, de una necesidad de clase muy concreta: adaptar unos mismos apuntes a varios niveles de dificultad sin tener que reescribirlos a mano cada vez, y sin fiarme de que “quedan más sencillos” solo porque lo digan las palabras que ha elegido un modelo. Por otro lado, de una necesidad igual de concreta en PLD Engineering: explicarle una propuesta técnica a un cliente sin jerga, sin que el texto pierda ni un dato importante por el camino.

Las dos cosas son, en el fondo, el mismo problema — texto denso, texto claro — así que es la misma herramienta. Texto Claro es un proyecto independiente de PINSAPIA, de Prompt Lab, de Postal IA, de Constelación de Palabras y de AGLAIA, pero reutiliza dos piezas ya construidas y ya probadas en PINSAPIA, en vez de escribirlas otra vez desde cero.

Reutilizar sin reescribir: dos piezas que ya existían

La primera pieza es extraer_texto_documento, de rag.py: la función que PINSAPIA usa para sacarle el texto a un PDF, un .docx o un .odt antes de indexarlo. Texto Claro la usa exactamente igual, para lo mismo pero al revés: en vez de trocear el texto para un buscador, lo necesita entero, de un tirón, para pasárselo al modelo.

La segunda pieza es calcular_legibilidad, de analizar_legibilidad.py — la herramienta, ya descrita en una entrada anterior de este blog, que mide con la fórmula de Fernández Huerta si un texto está escrito en un nivel razonable para el curso al que va dirigido, sin que lo decida ningún modelo de IA. Es 100% determinista: sílabas, palabras y frases, sin generación de por medio.

Ninguna de las dos piezas se ha tocado ni copiado. main.py de Texto Claro añade la carpeta de ia-monterroso-api a la ruta de Python (calculada a partir de dónde vive el propio archivo, no de una ruta fija) y las importa tal cual, como si fueran parte del mismo proyecto. La razón no es solo pereza: si mañana se corrige algo en el contador de sílabas o en el extractor de PDF, Texto Claro lo hereda automáticamente, sin tener que acordarse de copiar el arreglo a mano en dos sitios.

La comprobación real: la fórmula, no el modelo

Aquí está la decisión que de verdad define el proyecto. Es fácil pedirle a un modelo de lenguaje que reescriba un texto “más sencillo” — lo difícil es saber si de verdad lo ha conseguido, o si simplemente ha cambiado unas palabras técnicas por otras igual de complicadas. Preguntárselo al propio modelo no vale: un modelo de 3B ejecutado sin GPU puede estar tan equivocado sobre lo sencillo que ha quedado su propio texto como sobre cualquier otra cosa.

Así que no se le pregunta. Cada reescritura que genera el modelo se vuelve a medir con la misma fórmula de Fernández Huerta que se usa sobre el texto original — la misma función, el mismo criterio, sin excepciones — y las dos puntuaciones se muestran una al lado de la otra. Si la reescritura sube de verdad de puntuación, se marca como más fácil; si no sube (o baja), se dice así de claro, en vez de asumir que “como lo ha pedido la IA, ya está simplificado”.

[CAPTURA: pantalla de Texto Claro con el texto original y las dos reescrituras, cada una con su puntuación al lado]

Un límite que había que decidir: cuántas palabras caben

El modelo local de ROCKY (llama-3.2-3b-instruct, servido por LM Studio, el mismo que usa PINSAPIA) tiene una ventana de contexto limitada, y de un 3B sin GPU no se puede esperar que trague un documento entero y devuelva dos reescrituras completas sin quedarse corto o volverse desesperantemente lento. Antes de escribir una sola línea de interfaz, hacía falta fijar un número, no dejarlo “para más adelante”.

Se decidió un límite de 1.500 palabras de entrada (unas tres páginas): suficiente margen para que quepan las dos reescrituras completas en la respuesta del modelo sin cortarse, sin acercarse al límite en el que un 3B en CPU empieza a tardar minutos en responder. Si el texto pegado o extraído del documento supera esa cifra, Texto Claro no falla en silencio ni resume por su cuenta: recorta a las 1.500 primeras palabras y lo avisa en la propia pantalla de resultados. Trocear el documento completo en varias tandas queda, deliberadamente, para una fase posterior — no es parte de esta primera versión.

El mismo principio de no fallar en silencio se aplica a los PDF escaneados: si un documento no tiene ni una palabra de texto seleccionable (una imagen, vamos), Texto Claro no inventa un resultado ni intenta adivinar — avisa de que no hay nada que extraer, porque esta versión no hace OCR.

Cómo se usa

Texto Claro es una aplicación FastAPI de un solo archivo (main.py): un único endpoint (/simplificar) que recibe un texto pegado o un documento subido y devuelve el original más las dos reescrituras, cada una con su puntuación de legibilidad, y una página HTML servida por la misma aplicación — sin build aparte, sin JavaScript de terceros.

Se instala y se arranca así, desde la carpeta del proyecto:

pip install -r requirements.txt
uvicorn main:app --reload --port 8010

(o, más cómodo, con doble clic en arrancar_textoclaro.bat, que hace exactamente eso y además recuerda comprobar que LM Studio está abierto).

Con LM Studio ya sirviendo el modelo en local, http://localhost:8010 muestra dos pestañas — pegar texto o subir un documento (PDF, .docx, .odt o .txt) —, un botón “Simplificar texto” y, debajo, el texto original y las dos reescrituras (“para un cliente sin conocimientos técnicos” y “para explicárselo a alguien de 10 años”) una junto a otra, con su puntuación y su nivel escolar aproximado al lado.

[CAPTURA: pantalla de Texto Claro con las dos pestañas de entrada, antes de simplificar nada]

Nada se guarda en el servidor. Al ser un modelo local, un documento con datos de un cliente de PLD Engineering no sale de esta máquina — eso se dice así de claro en la propia página, con un aviso de privacidad visible antes de que nadie pegue nada. Y si el texto de entrada viene de un archivo subido, el archivo temporal se borra en cuanto se ha extraído su texto, haya ido bien o mal.

Qué hace y qué no (límites honestos)

• Dos niveles fijos, no tres. El diseño original contemplaba 2 o 3 reescrituras; esta primera versión se queda en dos (“cliente sin conocimientos técnicos” y “alguien de 10 años”) para no complicar el MVP antes de probarlo con texto real.
• No trocea documentos largos. Si el texto supera las 1.500 palabras, se avisa y se recorta a esa cantidad — no se procesa el documento completo en varias tandas. Esa función queda para una fase posterior.
• El contador de sílabas es una heurística, no un analizador lingüístico perfecto (hereda el límite ya documentado en analizar_legibilidad.py): sobre una media de cientos de palabras funciona bien, pero alguna palabra suelta puede contarse mal.
• Depende de que la carpeta de ia-monterroso-api viaje siempre junto a esta. Es una decisión consciente, no un descuido: como todos los proyectos se mueven juntos entre ordenadores, no hace falta duplicar código ni añadir configuración extra para localizar PINSAPIA en cada máquina.
• Sin autenticación ni límite de peticiones, a propósito: es una herramienta de uso personal y de aula, no pensada para estar expuesta en abierto en internet.

Siguiente paso

Probarlo con texto real: unos apuntes de clase que haya que bajar de nivel para un curso concreto, y una propuesta técnica real de PLD Engineering que haya que explicarle a un cliente. Con eso, decidir si el MVP se da por cerrado tal cual, o si hace falta ajustar algo antes — un tercer nivel de sencillez, trocear documentos más largos, o afinar el redactado de los dos niveles actuales para que se note más la diferencia entre “cliente” y “10 años”.