Una de las primeras ideas que aparecen cuando alguien descubre que una inteligencia artificial puede leer documentos es bastante lógica:
«Si puedo subir mi tesis a un chatbot y pedirle que la revise, ¿para qué necesito una herramienta especializada?»
La pregunta es razonable.
Los modelos conversacionales actuales pueden resumir capítulos, reformular párrafos, explicar conceptos, detectar errores evidentes y responder preguntas sobre un documento.
De hecho, son extremadamente útiles.
Pero una cosa es conversar sobre una tesis y otra bastante distinta es someterla a un proceso de revisión académica estructurado.
La diferencia no está necesariamente en la calidad del modelo.
Está en el flujo de trabajo.
Y esa diferencia termina siendo mucho más importante de lo que parece.
El chatbot empieza con una caja vacía
La mayoría de interfaces conversacionales comienzan del mismo modo:
una caja de texto.
El usuario decide qué preguntar.
Por ejemplo:
«Revísame este capítulo.»
Después:
«Comprueba ahora las referencias.»
Después:
«¿Ves contradicciones?»
Después:
«Analiza el estilo.»
Después:
«Dime si la conclusión está bien respaldada.»
Este tipo de interacción tiene una ventaja enorme: flexibilidad.
Puedes preguntar prácticamente cualquier cosa.
Pero esa misma flexibilidad introduce un problema cuando queremos realizar una revisión sistemática.
El procedimiento depende del usuario.
Si olvidamos hacer una pregunta, esa parte de la revisión puede no realizarse.
Si formulamos el prompt de manera diferente, el resultado puede cambiar.
Si revisamos los capítulos por separado, podemos perder relaciones entre partes distantes del manuscrito.
Si hacemos muchas consultas, los resultados terminan repartidos entre distintos mensajes.
La conversación es excelente para explorar.
Pero la exploración no equivale automáticamente a un procedimiento.
Revisar un manuscrito exige consistencia
Imaginemos una tesis de 250 páginas.
Queremos comprobar:
- estructura;
- citas;
- bibliografía;
- terminología;
- argumentación;
- estilo;
- preparación editorial.
Una revisión de este tipo debería aplicar criterios de forma relativamente consistente.
Por ejemplo, si queremos detectar citas sin referencia bibliográfica, idealmente la misma comprobación debería aplicarse a todo el documento.
No tendría demasiado sentido revisar los primeros cincuenta folios con una regla y los cincuenta siguientes con otra.
En un chatbot, buena parte de esa consistencia depende de cómo construimos la conversación.
En un flujo editorial, en cambio, la tarea ya está definida.
Esto es una diferencia importante.
En lugar de decir:
«Comprueba si mi bibliografía está bien.»
podemos tener un procedimiento específico de auditoría bibliográfica.
En lugar de:
«Mira si mis argumentos son coherentes.»
podemos utilizar una herramienta diseñada para representar tesis, premisas, evidencias y conclusiones.
No porque un modelo general sea incapaz de razonar sobre esas cosas.
Sino porque un procedimiento especializado reduce la ambigüedad sobre qué se está intentando hacer.
El problema de los prompts variables
Hay otro aspecto que suele pasarse por alto.
Dos personas pueden pedir exactamente la misma revisión utilizando prompts completamente distintos.
Una escribe:
«Revisa las referencias.»
Otra:
«Comprueba la integridad bibliográfica.»
Otra:
«Busca citas que no tengan entrada final.»
Otra:
«Haz una auditoría de las referencias APA.»
Aunque todas persiguen objetivos relacionados, no están solicitando exactamente lo mismo.
Esto produce una experiencia muy flexible, pero también variable.
En algunos contextos esa variabilidad es deseable.
En una lluvia de ideas, por ejemplo, puede ser una ventaja.
En un procedimiento de control de calidad, suele ser mejor reducirla.
El dossier de Philologica contrapone precisamente estos dos enfoques:
chat general
frente a
flujo editorial estructurado.
La idea no es eliminar la conversación.
Es decidir cuándo necesitamos conversación y cuándo necesitamos procedimiento.
El contexto también se fragmenta
Un manuscrito académico no es una colección independiente de párrafos.
Tiene relaciones internas.
Una definición introducida en la página 20 puede utilizarse nuevamente en la página 180.
Una conclusión puede depender de tres capítulos anteriores.
Una referencia bibliográfica puede aparecer únicamente en una nota al pie.
Un término técnico puede cambiar gradualmente de significado a lo largo del documento.
Si dividimos constantemente el trabajo en fragmentos independientes, algunas de estas relaciones pueden perderse.
Esto no significa que todo análisis tenga que procesar siempre el documento completo.
Hay tareas en las que analizar fragmentos es perfectamente adecuado.
Pero hay otras que necesitan conservar una visión de proyecto.
Por eso considero importante una diferencia conceptual:
archivo no es lo mismo que proyecto.
Un archivo es un objeto que subimos.
Un proyecto puede contener:
- documento;
- versiones;
- bibliografía;
- hallazgos;
- análisis;
- decisiones;
- historial.
Cuando el manuscrito se trata como proyecto, es más fácil conectar distintas operaciones de revisión.
Una respuesta de chat es efímera
Supongamos que un chatbot nos devuelve una observación excelente:
«La conclusión del capítulo 4 parece extender el argumento más allá de la evidencia presentada en las secciones anteriores.»
Muy útil.
Ahora aparecen varias preguntas prácticas.
¿Dónde estaba exactamente?
¿Qué fragmento concreto originó la observación?
¿Era un problema crítico o una sugerencia menor?
¿Se corrigió?
¿Puede volver a localizarse una semana después?
¿Puede compartirlo el autor con su director?
¿Forma parte de un informe general?
¿Se puede exportar junto con otros hallazgos?
En una conversación, la observación vive principalmente dentro de la conversación.
Podemos copiarla, guardarla o procesarla después.
Pero el sistema no necesariamente la trata como una entidad estructurada.
En un flujo editorial, un hallazgo puede tener propiedades propias.
Por ejemplo:
Categoría: argumentación
Severidad: media
Ubicación: capítulo 4, sección 4.3
Evidencia: fragmento identificado
Descripción: conclusión más fuerte que la evidencia anterior
Recomendación: revisar inferencia o aportar respaldo adicional
Esto transforma una respuesta interesante en una tarea revisable.
La trazabilidad cambia la naturaleza del resultado
Para mí, esta es una de las diferencias más importantes.
Una IA puede producir una observación razonable.
Pero en un entorno académico necesitamos preguntarnos:
¿Puedo comprobar de dónde sale?
Si la respuesta es no, el usuario termina dependiendo demasiado de la autoridad aparente del sistema.
La trazabilidad intenta reducir ese problema.
Idealmente, una observación debería conservar una relación con:
- el documento;
- el fragmento;
- la ubicación;
- la evidencia;
- la fuente externa, si existe.
La estructura sería algo parecido a:
hallazgo → ubicación → evidencia → recomendación
Cuando interviene bibliografía:
hallazgo → cita → referencia → fuente académica
Esto no convierte automáticamente la conclusión de la IA en verdadera.
Pero la hace inspeccionable.
Y en un contexto académico, esa diferencia es fundamental.
El chatbot sabe mucho, pero no es una base de datos bibliográfica
Este punto merece especial atención.
Los grandes modelos lingüísticos contienen enormes cantidades de conocimiento aprendido durante su entrenamiento.
Eso les permite reconocer autores, obras, revistas y conceptos.
Pero cuando necesitamos comprobar una referencia académica concreta, otra cuestión entra en juego:
la verificación externa.
Si tengo este DOI:
10.xxxx/xxxx
quiero saber si existe.
Si una referencia afirma que un artículo fue publicado en determinada revista y año, quiero contrastar los metadatos.
Si un trabajo aparece en la bibliografía, quiero poder localizar información externa verificable.
Aquí entran infraestructuras como:
- Crossref;
- OpenAlex;
- DataCite;
- DOAJ;
- Open Library.
En Philologica, estas fuentes forman parte del ecosistema de verificación bibliográfica descrito en el dossier.
La diferencia conceptual es importante.
No preguntamos únicamente al modelo:
«¿Te suena esta referencia?»
Intentamos preguntar también a una fuente externa:
«¿Existe este registro y qué metadatos devuelve?»
Eso reduce la dependencia de la memoria generativa.
Un chatbot puede inventar con mucha seguridad
Uno de los problemas más conocidos de los modelos generativos es que pueden producir respuestas plausibles pero incorrectas.
En el ámbito académico esto es particularmente delicado.
Una referencia inventada puede tener:
- autor plausible;
- título plausible;
- revista plausible;
- año plausible;
- incluso un DOI con aspecto plausible.
Todo parece correcto.
Hasta que intentamos localizarlo.
Por eso existe una regla que considero esencial:
cuando una afirmación puede verificarse contra una fuente externa fiable, conviene intentar verificarla.
La IA puede ayudar a interpretar.
Pero siempre que sea posible, la infraestructura debería aportar evidencia adicional.
Conversación abierta frente a objetivos editoriales
Otra diferencia importante es cómo se presenta el trabajo al usuario.
En un chatbot:
¿Qué quieres preguntar?
En un sistema editorial:
¿Qué quieres revisar?
La diferencia parece pequeña, pero cambia el comportamiento.
Por ejemplo, podemos ofrecer objetivos como:
Document Review
Para inspeccionar estructura general, fragmentos y consistencia del documento.
Source Research & Verification
Para trabajar sobre bibliografía y fuentes externas.
Argumentation & Terminology
Para estudiar tesis, premisas, conclusiones y estabilidad conceptual.
Style & Authorship
Para explorar señales estilométricas.
Publication Preparation
Para realizar una revisión orientada a la entrega final.
Estas categorías aparecen en el modelo actual de Philologica.
El usuario no necesita imaginar desde cero el prompt perfecto.
Selecciona el tipo de tarea.
Pero entonces, ¿la conversación deja de ser útil?
En absoluto.
De hecho, creo que sería un error intentar eliminarla.
Hay tareas donde una conversación es claramente mejor.
Por ejemplo:
«Explícame por qué este hallazgo es importante.»
«¿Cómo podría reformular esta conclusión sin perder su significado?»
«Dame tres formas alternativas de organizar este argumento.»
«¿Qué contraargumentos podrían plantearse?»
«Ayúdame a interpretar esta inconsistencia.»
En estos casos, el diálogo es extraordinariamente útil.
La cuestión no es:
chat o sistema estructurado.
La arquitectura más interesante probablemente sea:
sistema estructurado + conversación contextual.
Primero localizamos el problema.
Después conversamos sobre él.
Eso es muy distinto de pedir al chat que descubra, organice, clasifique, recuerde y gestione todo simultáneamente.
Una buena analogía: hoja de cálculo frente a calculadora
Pensemos en una calculadora.
Es fantástica para operaciones concretas.
Introducimos números.
Obtenemos un resultado.
Ahora pensemos en una hoja de cálculo.
También calcula.
Pero además:
- organiza datos;
- conserva relaciones;
- permite comparar;
- guarda resultados;
- representa estructuras;
- automatiza procedimientos.
No diríamos que una calculadora es inútil porque existe Excel.
Ni que Excel elimina la necesidad de una calculadora.
Son herramientas con niveles diferentes de estructura.
Algo parecido ocurre aquí.
Un chatbot puede ser extraordinario para trabajar sobre un problema concreto.
Pero cuando queremos revisar sistemáticamente un manuscrito, necesitamos conservar más contexto, más relaciones y más estado.
Otra analogía: conversación médica y historia clínica
Hay una comparación todavía más clara.
Imaginemos una consulta médica.
La conversación con el paciente es imprescindible.
Pero el sistema sanitario no confía únicamente en recordar conversaciones.
Existe una historia clínica.
Hay análisis.
Pruebas.
Fechas.
Resultados.
Evolución.
Medicaciones.
Alertas.
La conversación sigue siendo central, pero está integrada dentro de una estructura.
Una revisión académica puede beneficiarse de una filosofía similar.
El diálogo con la IA es útil.
Pero los hallazgos deberían formar parte de una historia del documento.
Qué significa tratar el manuscrito como proyecto
Cuando empecé a trabajar en Philologica, esta idea fue ganando importancia.
Una tesis no debería desaparecer del sistema después de obtener una respuesta.
Puede tener:
- análisis anteriores;
- nuevas versiones;
- correcciones;
- bibliografía;
- indicadores;
- hallazgos resueltos;
- hallazgos pendientes.
Esto permite algo que una conversación aislada hace más difícil:
continuidad editorial.
Por ejemplo:
Primera revisión:
27 hallazgos.
El autor trabaja sobre el documento.
Segunda versión:
9 hallazgos permanecen.
Eso permite observar evolución.
La revisión deja de ser un evento.
Se convierte en proceso.
La severidad también necesita estructura
Otro problema de una conversación abierta es que distintas observaciones pueden aparecer mezcladas.
Una errata.
Una referencia inexistente.
Una conclusión sin evidencia.
Una inconsistencia conceptual.
Todas dentro de la misma respuesta.
Pero no tienen la misma importancia.
Un sistema editorial puede clasificarlas.
Por ejemplo:
Crítico
Problemas que pueden afectar a la validez o trazabilidad central del documento.
Medio
Inconsistencias relevantes que deberían revisarse.
Bajo
Oportunidades de mejora o problemas menores.
No quiero decir que una clasificación automática deba aceptarse sin revisión.
Pero ayuda a organizar el trabajo.
Especialmente cuando un documento produce muchas observaciones.
Un buen sistema debe separar evidencia de recomendación
Este principio me parece todavía más importante cuando interviene IA.
Imaginemos este resultado:
«Debe eliminar este párrafo.»
No me gusta.
Es demasiado prescriptivo.
Prefiero algo así:
Evidencia detectada
El párrafo introduce una conclusión causal mientras las secciones anteriores describen únicamente una correlación.
Sugerencia
Revisar si la evidencia permite sostener causalidad o si conviene moderar la formulación.
Esto mantiene una diferencia clara.
El sistema muestra lo que detecta.
El usuario decide qué hacer.
La revisión académica tiene muchas capas
Otro motivo por el que una única conversación puede quedarse corta es que «revisar una tesis» en realidad engloba varias tareas.
No existe una única revisión.
Tenemos, entre otras:
- revisión formal;
- revisión bibliográfica;
- revisión conceptual;
- revisión argumentativa;
- revisión estilística;
- revisión editorial;
- revisión de fuentes;
- revisión de integridad.
Cada una necesita criterios diferentes.
Intentar comprimirlas todas dentro de un único prompt produce inevitablemente una instrucción demasiado general.
Algo como:
«Revisa completamente esta tesis y dime todos los problemas.»
Parece exhaustivo.
Pero no define un procedimiento.
Los prompts también son difíciles de reproducir
Imaginemos que un investigador obtiene buenos resultados utilizando este prompt:
«Analiza exhaustivamente la consistencia entre citas y bibliografía, identifica referencias no citadas, citas sin referencia, DOI inconsistentes y posibles duplicados. Clasifica los resultados por gravedad y proporciona ubicación exacta.»
Ahora otro investigador quiere repetir el procedimiento.
Tiene que utilizar exactamente el mismo prompt.
Después otro.
Y otro.
Muy pronto terminamos creando una biblioteca de prompts.
Y cuando esa biblioteca empieza a crecer, aparece una pregunta interesante:
¿No estamos empezando a construir una aplicación?
Un flujo especializado es, en cierto sentido, una manera de convertir prompts complejos y procedimientos repetibles en herramientas.
La interfaz deja de exigir que cada usuario conozca la instrucción interna.
El usuario selecciona:
Bibliographic Audit
y el sistema ejecuta el procedimiento correspondiente.
La reproducibilidad importa
En investigación científica solemos valorar la reproducibilidad.
En IA generativa nunca será absoluta porque los modelos pueden introducir variabilidad.
Pero podemos intentar reducir algunas fuentes innecesarias de variación.
Por ejemplo:
- misma herramienta;
- mismos parámetros;
- mismo documento;
- mismas fuentes externas;
- mismo esquema de salida.
Esto no garantiza resultados idénticos.
Pero es más controlado que depender de una sucesión completamente abierta de prompts.
La estructura ayuda.
Qué información debería conservar un hallazgo
Para que una revisión sea realmente útil, considero que cada hallazgo debería intentar responder varias preguntas.
¿Qué se ha detectado?
Por ejemplo:
cita sin referencia bibliográfica.
¿Dónde?
Capítulo, sección, página o fragmento.
¿Qué evidencia existe?
La cita concreta.
¿Por qué importa?
El lector no puede reconstruir la fuente.
¿Qué puedo revisar?
Añadir referencia, corregir cita o comprobar si se trata de un error de extracción.
Esto transforma un comentario de IA en una unidad de trabajo.
Un ejemplo completo
Imaginemos que analizamos una tesis y encontramos:
García (2021) sostiene que…
pero no encontramos García (2021) en la bibliografía.
Una conversación podría responder:
«Parece que falta García (2021) en la bibliografía.»
Perfecto.
Un hallazgo estructurado podría añadir:
Tipo: integridad bibliográfica
Severidad: media
Documento: tesis_v7.pdf
Ubicación: capítulo 3, página 87
Fragmento: García (2021)
Estado: pendiente
Evidencia: no se localiza coincidencia en referencias finales
Recomendación: comprobar referencia o corregir cita
Después el usuario puede resolverlo.
Ese pequeño cambio de estructura tiene enormes implicaciones prácticas.
Entonces, ¿puedo revisar mi tesis con ChatGPT?
Sí.
Por supuesto.
Y puede resultar extraordinariamente útil.
Puedes utilizarlo para:
- mejorar redacción;
- discutir argumentos;
- detectar contradicciones;
- resumir;
- comprobar comprensión;
- proponer alternativas;
- analizar fragmentos;
- explorar marcos teóricos;
- preparar preguntas de revisión.
La cuestión es otra.
Si tu objetivo es realizar una auditoría sistemática del manuscrito completo, necesitas pensar también en:
- cobertura;
- estructura;
- persistencia;
- trazabilidad;
- clasificación;
- fuentes externas;
- exportación.
Es ahí donde una herramienta especializada empieza a tener sentido.
El verdadero cambio no está en el modelo
Esta es probablemente la idea más importante del artículo.
Cuando hablamos de productos de IA tendemos a centrar toda la discusión en el modelo.
GPT.
Gemini.
Claude.
Grok.
El siguiente modelo.
Pero una gran parte del valor de una aplicación no está en el modelo.
Está en todo lo que se construye alrededor.
La arquitectura.
La interfaz.
Las fuentes.
El workflow.
La persistencia.
Los controles.
La representación de resultados.
Un excelente modelo dentro de una interfaz inadecuada puede producir una mala experiencia.
Y un modelo razonablemente bueno dentro de un procedimiento muy bien diseñado puede ser enormemente útil.
Por eso cada vez me interesa menos la pregunta:
«¿Qué modelo utiliza?»
y más:
«¿Qué proceso permite realizar?»
Del prompt al instrumento
Creo que esta es una evolución natural de muchas aplicaciones de IA.
Primera etapa:
chat.
Segunda etapa:
prompts especializados.
Tercera etapa:
herramientas.
Cuarta etapa:
workflows.
En algún momento dejamos de pensar constantemente en la IA.
Igual que cuando utilizamos Photoshop no pensamos en cada algoritmo interno.
Utilizamos:
Recortar.
Máscara.
Niveles.
Curvas.
Selección.
Las capacidades técnicas se convierten en instrumentos.
Creo que algo parecido ocurrirá en el ámbito académico.
En lugar de:
«Escribe un prompt para analizar mi bibliografía.»
tendremos:
Auditar bibliografía.
En lugar de:
«Pide al modelo que extraiga la estructura argumentativa.»
tendremos:
Mapa argumental.
Y eso cambia completamente la accesibilidad del sistema.
Ahí es donde sitúo Philologica
Esta es precisamente la dirección en la que estoy desarrollando Philologica.
No como sustituto de los grandes modelos conversacionales.
Ni como un chatbot con otra interfaz.
Sino como una capa de trabajo académico estructurado alrededor del manuscrito.
El dossier actual resume la diferencia de forma bastante sencilla:
Chat general
- prompts variables;
- contexto fragmentado;
- salida conversacional;
- observaciones difíciles de recuperar;
- conocimiento principalmente aislado dentro del modelo.
Flujo editorial
- herramientas predefinidas;
- documento tratado como proyecto;
- informe estructurado;
- hallazgos trazables;
- conexión con fuentes académicas.
No son dos tecnologías incompatibles.
Son dos formas diferentes de utilizar la misma revolución tecnológica.
Mi conclusión
Creo que seguiremos utilizando chatbots para trabajar con investigación.
Yo lo hago.
Son demasiado útiles como para pensar lo contrario.
Pero también creo que, a medida que la IA madure, dejaremos de intentar resolver todos los problemas escribiendo prompts.
Algunas tareas necesitan instrumentos.
Algunas necesitan estructuras.
Algunas necesitan estado.
Algunas necesitan fuentes externas.
Y algunas necesitan trazabilidad.
Revisar una tesis completa pertenece, en mi opinión, a esta última categoría.
Porque una tesis no necesita únicamente una IA capaz de hablar sobre ella.
Necesita un proceso que permita inspeccionarla.
Philologica
Estoy desarrollando Philologica precisamente alrededor de esta idea: convertir diferentes tareas de revisión académica en flujos estructurados y trazables.
Puedes explorar el proyecto en:
La plataforma no pretende sustituir la revisión humana, al director de tesis, al editor ni al proceso de revisión por pares. Su función es ayudar a localizar y organizar aspectos del documento que merece la pena revisar.
