La inteligencia artificial puede corregir un texto de unos cuantos párrafos en cuestión de segundos. A partir de ahí resulta tentador pensar que corregir una novela consiste simplemente en pasarle el manuscrito completo a un modelo y esperar unos minutos.
La realidad es bastante más complicada.
He estado experimentando con un sistema local basado en IA para corregir mis propias novelas y, aunque los resultados son suficientemente buenos como para que considere útil incorporarlo a mi proceso de trabajo, también he encontrado errores que impiden considerar el resultado como una corrección definitiva.
El problema no es solamente elegir un modelo adecuado. Hay que preparar el texto, dividirlo, procesarlo por partes, reconstruirlo y, finalmente, volver a leerlo.
En otras palabras: la IA puede hacer una primera corrección muy interesante, pero todavía necesita un humano detrás.
El equipo y el entorno que utilizo
Todo el proceso se ejecuta en mi propio ordenador:
- NVIDIA RTX 5060 con 8 GB de VRAM.
- AMD Ryzen 7 8745HX.
- 16 GB de RAM.
No utilizo una API externa para enviar el contenido de las novelas a un proveedor de IA. Los modelos se ejecutan localmente mediante Ollama.
La automatización corre sobre n8n, instalado junto con el resto de servicios mediante Docker.
Dentro de mi entorno también tengo Open WebUI, Qdrant, SearXNG, Gotenberg y varios servicios relacionados con síntesis de voz, aunque para la corrección los componentes realmente importantes son tres:
- n8n, que controla el proceso.
- Ollama, que ejecuta el modelo de lenguaje.
- Gemma 3 4B, que realiza actualmente las correcciones.
Elegir un modelo de unos 4.000 millones de parámetros no es casual.
Mi RTX 5060 dispone de 8 GB de VRAM. Esto permite ejecutar modelos pequeños con bastante comodidad, pero establece un límite práctico. Podría experimentar con modelos mayores y diferentes niveles de cuantización, pero el objetivo no consiste únicamente en conseguir la máxima calidad posible en una única respuesta.
Necesito procesar decenas de miles de palabras de manera repetible.
Ahí empieza el verdadero problema.
Una novela no cabe en un prompt
Cuando utilizamos ChatGPT, Ollama o cualquier otro sistema similar con unas pocas páginas de texto puede parecer que el tamaño del documento no importa demasiado.
Con una novela completa sí importa.
Una novela puede tener 60.000, 80.000, 100.000 palabras o muchas más.
No resulta práctico entregar todo ese contenido al modelo cada vez que queremos realizar una corrección. Incluso aunque dispusiéramos de una ventana de contexto suficientemente grande, aumentar el contexto implica consumir más memoria y aumentar considerablemente el coste computacional.
Además, que un modelo pueda recibir una enorme cantidad de texto no significa necesariamente que vaya a trabajar igual de bien con todo él.
Por eso mi flujo empieza descomponiendo el manuscrito.
Primero, dividir la novela en capítulos
Trabajo principalmente con documentos ODT (viva el software libre!).
n8n abre internamente el archivo y extrae su content.xml. A partir de ahí localiza los encabezados que identifican los capítulos y genera un archivo independiente para cada uno.
Esto tiene varias ventajas.
Si una novela contiene treinta capítulos, ya no tengo un único trabajo gigantesco sino treinta unidades que puedo procesar independientemente.
También significa que, si algo falla en el capítulo 23, no tengo que empezar otra vez desde la primera página.
El flujo guarda los resultados intermedios, comprueba qué capítulos han sido procesados y puede saltarse aquellos que ya existen.
Pero un capítulo sigue siendo demasiado grande, así que aparece una segunda división.
Después, dividir cada capítulo en chunks
Para la primera fase de corrección, mi flujo divide cada capítulo en bloques de aproximadamente 500 palabras.
La división intenta respetar los párrafos. Es decir, no corta simplemente cada 500 palabras en mitad de una frase, sino que va acumulando párrafos hasta alcanzar aproximadamente ese tamaño.
El resultado conceptual es algo parecido a esto:
Novela
→ Capítulo 1
→ chunk 1
→ chunk 2
→ chunk 3
→ chunk 4…
→ Capítulo 2
→ chunk 1
→ chunk 2
→ chunk 3…
Y así sucesivamente.
Cada fragmento se envía individualmente al modelo.
Cuando todos han terminado, n8n vuelve a ordenarlos y recompone el capítulo.
Finalmente, los capítulos procesados pueden volver a reunirse para reconstruir la novela.
Desde el punto de vista técnico funciona muy bien.
Desde el punto de vista literario aparece un problema mucho más interesante.
Cada chunk sabe muy poco de la novela
Imaginemos que entregamos al modelo este fragmento:
«Alex entró en la habitación. Estaba cansada después de conducir durante toda la noche».
Para nosotros puede estar perfectamente claro que Alex es una mujer porque llevamos 150 páginas acompañando al personaje.
Pero el modelo encargado de corregir ese fragmento solamente sabe lo que existe dentro de su pequeña ventana de texto.
Si la información que establece quién es Alex estaba dos capítulos antes, para esa ejecución sencillamente no existe.
Aquí aparece una de las limitaciones fundamentales de corregir una novela mediante fragmentos independientes:
se gana capacidad para procesar textos enormes a costa de perder contexto global.
Y eso puede producir errores inesperados.
Cuando la IA cambia el sexo de un personaje
Este es uno de los errores que he encontrado al revisar una de mis novelas después de pasarla por el sistema.
En algunos fragmentos, el modelo cambió el género de personajes.
No ocurre constantemente ni convierte el resultado en algo inutilizable. Precisamente por eso es un problema interesante: son errores suficientemente escasos como para pasar inadvertidos durante una inspección rápida.
Un texto aparentemente limpio puede contener de repente un pronombre masculino donde el personaje es femenino, o al contrario.
El modelo no está intentando estropear el texto.
Está intentando resolver una ambigüedad con la información de la que dispone.
El problema es que nosotros conocemos la novela completa y el modelo, en ese momento, conoce unas pocas centenas de palabras.
Y a veces cambia algo todavía más delicado: el tiempo verbal
He encontrado otro comportamiento más preocupante.
En algunos chunks completos, la corrección puede modificar el tiempo verbal dominante.
Una narración escrita en pasado puede encontrarse de repente con un fragmento que ha sido llevado al presente, o viceversa.
Gramaticalmente, cada frase puede estar perfectamente construida.
Literariamente, el resultado es incorrecto.
Este es probablemente uno de los mejores ejemplos de la diferencia entre corregir frases y corregir una novela.
Una herramienta puede considerar perfectamente válida una frase aislada y, al mismo tiempo, introducir un error cuando observamos esa misma frase dentro de las 300 páginas que la rodean.
Intentar que el modelo no sea creativo
Para reducir este comportamiento utilizo una configuración deliberadamente conservadora.
En la fase de corrección, Gemma 3 4B trabaja con una temperatura de 0.
La temperatura controla, simplificando mucho, cuánto margen damos al modelo para escoger entre diferentes continuaciones posibles.
Para escritura creativa puede tener sentido aumentar ese valor.
Para corregir una novela quiero exactamente lo contrario.
No quiero que el modelo invente.
No quiero que decida cómo habría escrito él una frase.
No quiero que mejore mi estilo según sus propios criterios.
Quiero que toque lo mínimo posible.
Por eso el prompt también es muy restrictivo.
Le indico que mantenga el texto igual y que solamente intervenga sobre errores ortográficos, tildes y puntuación claramente incorrecta.
También le indico expresamente que las frases escritas en otros idiomas deben permanecer intactas.
Después tengo otra fase de corrección algo más flexible, orientada a pequeños errores gramaticales, concordancias, redundancias o frases torpes, pero intentando preservar siempre la voz narrativa.
Sobre el papel, las instrucciones son muy claras.
Sin embargo, un LLM no es un conjunto de reglas tradicionales.
Un prompt no es un contrato
Este punto me parece fundamental.
Cuando escribimos en un prompt:
«No cambies el tiempo verbal».
No estamos creando una condición del tipo:
if tiempo_verbal_cambia:
cancelar_operacion()Estamos dando una instrucción a un modelo probabilístico.
Puede cumplirla el 99 % de las veces y fallar en una ocasión.
Y en una novela hay muchísimas ocasiones.
Supongamos que dividimos un manuscrito en 200 fragmentos.
Aunque el comportamiento fuese correcto en 199, basta con que uno cambie información relevante para introducir un error nuevo en el manuscrito.
Por eso las tasas de acierto que parecen extraordinarias cuando hablamos de una sola respuesta pueden tener otra lectura cuando procesamos automáticamente cientos de fragmentos.
La paradoja de la corrección automática
Aquí aparece una paradoja curiosa.
La IA elimina una enorme cantidad de trabajo mecánico.
Puede detectar:
- erratas;
- signos de puntuación incorrectos;
- tildes;
- pequeños problemas de concordancia;
- repeticiones;
- construcciones poco claras.
Y puede hacerlo a una velocidad imposible para una persona.
Pero, al mismo tiempo, puede introducir errores que antes no existían.
Eso significa que no puedo considerar el archivo generado por n8n como la versión final de la novela.
Es una versión corregida automáticamente.
La diferencia entre ambas expresiones es importante.
Después de la IA viene otra corrección
Mi conclusión después de probar el sistema con una novela completa es clara:
la corrección automática tiene que ir seguida de una nueva lectura humana.
Eso no significa que el sistema haya fracasado.
Significa que su función es diferente de la que inicialmente podríamos imaginar.
No utilizo la IA para evitar leer otra vez la novela.
La utilizo para que, cuando vuelva a leerla, una gran parte de los pequeños errores ya haya desaparecido.
El trabajo humano cambia.
En lugar de dedicar toda la atención a buscar una coma, una tilde o una errata, puedo prestar más atención a problemas que requieren comprender la obra en su conjunto:
- continuidad;
- coherencia de personajes;
- voz narrativa;
- tiempos verbales;
- tono;
- significado;
- ritmo;
- decisiones estilísticas.
Y, paradójicamente, también tengo que vigilar los posibles errores introducidos por la propia IA.
¿Merece entonces la pena?
En mi caso, sí.
Pero no de la manera que suele sugerirse cuando se habla de inteligencia artificial. No tengo un botón que diga «corregir novela» y produzca una obra lista para publicar.
Tengo una cadena de procesos.
- El documento se desmonta.
- Los capítulos se identifican.
- Los capítulos se dividen.
- Los fragmentos se corrigen.
- Los resultados se guardan.
- Los fragmentos se vuelven a unir.
- Los capítulos se reconstruyen.
- Y después una persona vuelve a leer el resultado.
Es más parecido a crear una herramienta editorial especializada que a contratar un corrector artificial.
La IA como primera pasada, no como último lector
Esta experiencia me ha hecho cambiar mi manera de pensar sobre la IA aplicada a la literatura.
La pregunta interesante no es:
«¿Puede una IA corregir una novela?»
Evidentemente puede corregir grandes cantidades de texto.
La pregunta es:
«¿Qué parte del proceso de corrección podemos delegar sin perder el control del manuscrito?»
Ahí la respuesta resulta mucho más útil.
En mi flujo actual, la IA hace una primera pasada extraordinariamente rápida y elimina gran cantidad de pequeños defectos.
Pero la última palabra sigue siendo humana.
Y, después de encontrar personajes que cambian de género y fragmentos que cambian de tiempo verbal, no tengo ninguna intención de eliminar ese último paso.
