Una de las decisiones más importantes al diseñar Philologica fue intentar que el proceso de revisión resultara comprensible desde el principio.
Un manuscrito académico puede ser extremadamente complejo.
Una tesis puede contener cientos de páginas, decenas de referencias, múltiples capítulos, tablas, citas, conceptos técnicos, anexos, hipótesis y conclusiones.
La herramienta que lo analiza no debería añadir todavía más complejidad.
Por eso el flujo conceptual de Philologica puede resumirse en cuatro pasos:
subir el documento
↓
elegir qué quieres revisar
↓
recibir hallazgos
↓
verificar, editar y exportar
Ese recorrido parece sencillo.
Y deliberadamente lo es.
La complejidad debería estar en la infraestructura y en las herramientas, no en obligar al usuario a aprender cómo hablar con el sistema.
Paso 1. Subir el documento
Todo empieza con el manuscrito.
Puede ser una tesis, un artículo académico, un paper, un capítulo, una monografía o cualquier otro documento que necesite una revisión estructurada.
El primer paso consiste en incorporarlo a Philologica.
Pero hay una diferencia conceptual importante.
El documento no se trata simplemente como:
«un PDF que la IA debe leer».
Se incorpora a un espacio de trabajo.
Esta idea puede parecer menor, pero cambia la arquitectura del proceso.
Un archivo aislado tiene un principio y un final.
Lo subimos.
Preguntamos algo.
Obtenemos una respuesta.
Un proyecto, en cambio, puede conservar:
- el documento;
- sus análisis;
- sus hallazgos;
- revisiones posteriores;
- decisiones editoriales;
- resultados exportables.
El manuscrito se convierte así en el centro del trabajo.
De archivo a proyecto
Esta transformación es especialmente útil cuando el documento necesita varias clases de revisión.
Por ejemplo, hoy puede interesarnos estudiar su estructura.
Mañana, la bibliografía.
Después, la terminología.
Finalmente, la preparación editorial.
Si cada operación se ejecuta como una conversación completamente independiente, la información empieza a fragmentarse.
Si todas trabajan sobre el mismo proyecto, podemos intentar conservar continuidad.
Esta es una de las diferencias que más me interesan de Philologica:
el documento no debería desaparecer detrás de la inteligencia artificial.
Debería seguir siendo el objeto principal.
¿Por qué PDF?
El PDF es uno de los formatos más habituales en el mundo académico porque conserva razonablemente bien la estructura visual del documento.
Pero también presenta dificultades.
Un PDF puede contener:
- texto;
- notas al pie;
- encabezados;
- numeración;
- tablas;
- referencias;
- imágenes;
- columnas;
- saltos de página;
- elementos gráficos.
Por tanto, «leer un PDF» no es siempre una operación trivial.
El sistema debe poder extraer una representación que permita trabajar sobre el contenido sin perder, en la medida de lo posible, la relación con el documento original.
Esto es especialmente importante si posteriormente queremos decir:
«El problema está aquí.»
La localización depende de poder mantener un vínculo entre el análisis y la fuente.
Paso 2. Elegir el objetivo de revisión
Después de incorporar el documento aparece la pregunta más importante:
¿Qué quieres revisar?
No:
«¿Qué quieres preguntarle a la IA?»
La diferencia es deliberada.
Philologica organiza el trabajo alrededor de objetivos editoriales.
El dossier actual agrupa estos objetivos en cinco grandes áreas.
Document Review
Para revisar el manuscrito, su estructura, fragmentos y posibles problemas generales.
Source Research & Verification
Para trabajar con citas, bibliografía y fuentes académicas externas.
Argumentation & Terminology
Para examinar estructura argumentativa y consistencia conceptual.
Style & Authorship
Para analizar características estilísticas y variaciones dentro del texto.
Publication Preparation
Para revisar el documento desde una perspectiva de preparación editorial y control final.
Cada una responde a preguntas diferentes.
Y eso es importante porque «revisar una tesis» es, en realidad, una expresión demasiado amplia.
No existe una única revisión
Pensemos en todo lo que puede querer comprobar un autor antes de entregar una tesis.
Quizá quiere saber si:
- todas las citas tienen referencia;
- existen entradas bibliográficas nunca citadas;
- las conclusiones están respaldadas;
- el vocabulario es consistente;
- hay cambios extraños de estilo;
- algún capítulo presenta una estructura débil;
- el manuscrito está preparado para una revisión editorial.
Estas preguntas requieren procedimientos diferentes.
Por eso una herramienta generalista que simplemente recibe:
«Revísame la tesis»
tiene que interpretar qué significa exactamente revisar.
En Philologica intento hacer lo contrario:
convertir las distintas interpretaciones de esa palabra en herramientas explícitas.
Herramientas, no prompts
Este punto conecta con una idea que ya expliqué en el artículo anterior.
Cuando una tarea se repite suficientemente, puede dejar de ser un prompt y convertirse en instrumento.
En lugar de pedir:
«Analiza la estructura completa de mi documento y localiza inconsistencias».
podemos seleccionar:
Document Analysis
En lugar de construir una instrucción compleja para estudiar una sección:
Fragment Review
Para trabajar con referencias:
Bibliography Catalog
Para estudiar argumentos:
Dialectical Assistant
Para vocabulario:
Editorial Thesaurus
Para patrones estilísticos:
Stylometry Radar
Y así sucesivamente.
La interfaz se convierte en una especie de caja de herramientas editorial.
Elegir un objetivo reduce ambigüedad
Esta estructura tiene otra ventaja.
Cuando el usuario selecciona una herramienta, también está delimitando el tipo de resultado que espera.
Si utilizamos un análisis bibliográfico, no necesitamos que el sistema dedique gran parte de su respuesta a comentar el estilo narrativo.
Si analizamos estilometría, no estamos pidiendo que evalúe simultáneamente los DOI.
Separar objetivos permite intentar realizar análisis más específicos.
No significa que los distintos aspectos del manuscrito estén completamente aislados.
No lo están.
Pero resulta útil dividir la complejidad en tareas manejables.
Paso 3. Recibir hallazgos
Una vez elegido el objetivo, el sistema analiza el documento.
Aquí aparece otra palabra importante en el diseño de Philologica:
hallazgo.
Prefiero hablar de hallazgos antes que de errores.
¿Por qué?
Porque una detección automática no debería convertirse automáticamente en una sentencia.
Imaginemos que el sistema encuentra una referencia bibliográfica que no aparece citada.
Puede ser un error.
Pero también podría formar parte de una bibliografía complementaria.
O quizá existe una cita que el proceso de extracción no ha reconocido correctamente.
Por eso la salida debería decir:
«Aquí existe algo que merece revisión.»
No:
«Esto está necesariamente mal.»
Qué debería contener un hallazgo
Dependiendo de la herramienta, un hallazgo puede intentar reunir elementos como:
Categoría
¿Qué clase de problema se ha detectado?
Por ejemplo:
- bibliografía;
- estructura;
- terminología;
- argumentación;
- estilo.
Severidad
¿Qué importancia parece tener?
No todos los hallazgos deben tratarse igual.
Ubicación
¿Dónde está?
Capítulo, sección, página o fragmento.
Evidencia
¿Qué elemento del documento ha originado la observación?
Explicación
¿Por qué merece atención?
Recomendación
¿Qué debería revisar el usuario?
Esta estructura permite transformar el análisis en una lista de trabajo.
Un ejemplo sencillo
Supongamos que Philologica encuentra:
Martínez (2022)
en el capítulo 3.
Pero no localiza una referencia correspondiente en la bibliografía.
Un resultado estructurado podría decir:
Tipo: integridad bibliográfica
Ubicación: capítulo 3
Hallazgo: cita sin referencia localizada
Evidencia: Martínez (2022)
Severidad: media
Recomendación: comprobar si falta la entrada bibliográfica o si la cita debe corregirse
Ahora tenemos algo mucho más útil que:
«Parece que hay problemas con la bibliografía.»
Tenemos una tarea concreta.
La ubicación convierte la observación en trabajo
Este detalle me parece especialmente importante.
Un informe puede contener una observación completamente correcta y seguir siendo poco útil si obliga al usuario a buscar manualmente dónde está el problema.
Imaginemos una tesis de 320 páginas.
El sistema dice:
«Hay una inconsistencia en la definición de gobernanza algorítmica.»
Muy bien.
¿Dónde?
Encontrarla puede llevar bastante tiempo.
Si, en cambio, podemos acercarnos a:
capítulo 2, sección 2.4
y después:
capítulo 7, sección 7.1
la observación se vuelve accionable.
La trazabilidad empieza por algo tan sencillo como poder regresar al texto.
El sistema no debería ocultar la evidencia
Existe una tentación en muchos productos de IA: resumir demasiado.
El sistema produce una conclusión limpia y elegante y oculta toda la complejidad que existe debajo.
Eso puede resultar cómodo.
Pero en un entorno académico prefiero otra filosofía.
Si una recomendación depende de determinado fragmento, ese fragmento debería estar disponible.
Si depende de determinada referencia externa, deberíamos intentar mostrar la fuente.
Si existe incertidumbre, conviene hacerla visible.
Un sistema académico debería acercarse más a:
«Esto es lo que he encontrado y aquí puedes comprobarlo.»
que a:
«Confía en mi conclusión.»
Priorizar los hallazgos
Hay otro problema práctico.
Un documento largo puede generar muchas observaciones.
Supongamos que una tesis produce:
- 4 problemas importantes;
- 16 problemas medios;
- 53 observaciones menores.
Presentar 73 comentarios en una lista plana sería una mala experiencia.
Por eso resulta útil organizar la revisión.
Por ejemplo:
Alta prioridad
Problemas que afectan a estructura, evidencia, referencias esenciales o coherencia central.
Prioridad media
Inconsistencias que conviene resolver antes de la entrega.
Prioridad baja
Mejoras estilísticas, pequeños ajustes o señales débiles.
La clasificación no debería considerarse infalible.
Pero puede ayudar al usuario a decidir por dónde empezar.
Paso 4. Verificar, editar y exportar
Este último paso es probablemente el más importante.
El sistema ha terminado su análisis.
Ahora empieza el trabajo humano.
El usuario revisa cada hallazgo.
Puede:
- aceptarlo;
- descartarlo;
- investigarlo;
- corregir el manuscrito;
- contrastar una fuente;
- modificar una conclusión;
- cambiar una referencia;
- decidir que la observación no es pertinente.
Aquí la IA deja de ser protagonista.
El protagonista vuelve a ser el autor.
La IA no debería tomar la decisión final
Esta es una de las ideas que intento mantener estable en todo el proyecto.
El sistema puede detectar.
Puede comparar.
Puede clasificar.
Puede proponer.
Pero no conoce automáticamente todo el contexto de una investigación.
Una observación puede ser técnicamente correcta y conceptualmente irrelevante.
Un cambio terminológico puede estar plenamente justificado.
Una conclusión puede apoyarse en una metodología que el sistema no ha interpretado correctamente.
Una referencia aparentemente ausente puede encontrarse bajo otra convención.
Por eso el flujo no termina en:
analizar → corregir automáticamente
sino en:
analizar → mostrar evidencia → revisar → decidir
El informe editorial
Una vez revisados los resultados, estos pueden organizarse en un informe.
El dossier de Philologica dedica precisamente una parte importante a este resultado tangible de la revisión.
Un informe editorial puede incluir:
- resumen ejecutivo;
- puntuaciones o indicadores;
- hallazgos por severidad;
- ubicación exacta;
- evidencia;
- recomendaciones;
- métricas de preparación.
El objetivo es que el resultado pueda sobrevivir a la interfaz.
Esto es importante.
Una revisión seria debería poder compartirse, archivarse o discutirse.
¿Por qué exportar?
Pensemos en algunos escenarios.
Estudiante y director de tesis
El estudiante puede revisar el informe y utilizarlo como guía para una sesión con su director.
Investigador y coautores
Los miembros del equipo pueden discutir determinadas observaciones antes de enviar un paper.
Editorial
Un editor puede conservar una evaluación preliminar del manuscrito.
Equipo de investigación
Puede documentarse una revisión previa antes de una entrega.
El informe se convierte en un artefacto de colaboración.
No simplemente en una respuesta de IA.
De PDF a lista de decisiones
Si resumimos todo el proceso, sucede algo interesante.
Entramos con:
un PDF de cientos de páginas
y salimos con:
una serie de decisiones concretas que el autor puede revisar.
Por ejemplo:
comprobar esta referencia;
revisar esta conclusión;
unificar este término;
comprobar este cambio estilístico;
revisar esta premisa;
corregir esta inconsistencia.
La inteligencia artificial resulta útil no tanto porque «entienda toda la tesis» en un sentido absoluto.
Resulta útil porque puede ayudar a reducir un problema enorme a unidades de revisión manejables.
Un ejemplo completo del recorrido
Imaginemos una tesis doctoral de 240 páginas.
1. Upload
El autor incorpora:
tesis_version_final.pdf
2. Objetivo
Selecciona:
Source Research & Verification
3. Análisis
El sistema compara elementos bibliográficos y localiza, por ejemplo:
- 3 citas sin referencia correspondiente;
- 7 referencias aparentemente no utilizadas;
- 2 DOI que conviene comprobar;
- 1 posible referencia duplicada.
4. Revisión humana
El autor comprueba cada caso.
Descubre que:
- dos citas realmente necesitaban una referencia;
- una era un falso positivo;
- cinco referencias podían eliminarse;
- dos pertenecían a bibliografía complementaria;
- uno de los DOI estaba mal escrito.
5. Nueva versión
Corrige el documento.
Ahora existe:
tesis_version_final_2.pdf
Esta es la clase de ciclo que me interesa.
No:
«La IA corrigió mi tesis.»
Sino:
«La IA me ayudó a localizar qué debía comprobar.»
El mismo documento puede pasar por varios objetivos
El flujo tampoco tiene que terminar después de una herramienta.
El mismo manuscrito puede pasar posteriormente por:
Document Review
después:
Argumentation & Terminology
después:
Style & Authorship
y finalmente:
Publication Preparation
Esto permite construir una revisión por capas.
Cada capa observa el manuscrito desde una perspectiva diferente.
La idea de revisión progresiva
Personalmente, creo que este enfoque es más razonable que intentar obtener una revisión absoluta en una única operación.
La revisión académica real tampoco funciona así.
Un autor relee.
Después revisa referencias.
Después recibe comentarios.
Después modifica.
Después vuelve a leer.
Después ajusta conclusiones.
Es un proceso iterativo.
La IA debería adaptarse a esa realidad, no fingir que existe un botón mágico llamado:
«Corregir tesis»
Qué no ocurre en estos cuatro pasos
También es importante explicar lo que el proceso no pretende hacer.
Philologica no debería:
- decidir si una tesis merece aprobarse;
- sustituir a un tribunal;
- sustituir a un director;
- decidir automáticamente qué argumentos son válidos;
- garantizar la inexistencia de errores;
- convertir una recomendación en una corrección obligatoria.
El sistema ayuda a revisar.
No adjudica autoridad académica.
La importancia del diseño de interfaz
Todo esto plantea además una cuestión que me parece interesante desde el punto de vista del desarrollo de producto.
La complejidad técnica puede ser enorme.
Puede haber:
- procesamiento documental;
- modelos de lenguaje;
- APIs externas;
- sistemas de extracción;
- servicios bibliográficos;
- almacenamiento;
- métricas;
- lógica editorial.
Pero el usuario no debería tener que pensar constantemente en esa infraestructura.
Idealmente debería poder pensar:
- Este es mi manuscrito.
- Esto es lo que quiero comprobar.
- Estos son los hallazgos.
- Esto es lo que voy a revisar.
Cuando una aplicación consigue ocultar la complejidad sin ocultar la evidencia, creo que empieza a convertirse en una verdadera herramienta.
Simplicidad no significa superficialidad
Esta es quizá la paradoja de Philologica.
El flujo principal es deliberadamente sencillo.
Pero los análisis pueden ser complejos.
Eso no es una contradicción.
Los buenos instrumentos suelen funcionar así.
Una cámara puede tener una enorme sofisticación tecnológica detrás y seguir permitiendo al usuario pulsar un botón.
Un procesador de textos puede gestionar tipografía, estructuras, índices y formatos sin exigir que el usuario conozca su implementación.
La interfaz debe simplificar la operación.
No simplificar el problema.
Por qué cuatro pasos
Podría haber diseñado un proceso con diez pantallas.
Configuraciones.
Parámetros.
Asistentes.
Preguntas.
Confirmaciones.
Pero cada paso adicional introduce fricción.
Y la revisión académica ya exige suficiente energía cognitiva por sí sola.
Por eso me gusta mantener la lógica esencial en cuatro acciones:
Sube.
Elige.
Revisa.
Decide.
El resto debería ocurrir alrededor de ellas.
Del documento al conocimiento sobre el documento
Hay otra forma de interpretar este flujo.
Al principio tenemos conocimiento dentro del documento.
Al final tenemos también conocimiento sobre el documento.
Sabemos:
- dónde existen riesgos;
- qué fuentes necesitan revisión;
- qué conceptos podrían ser inconsistentes;
- qué argumentos merecen atención;
- qué partes son prioritarias.
Ese segundo nivel de conocimiento es precisamente lo que un proceso de revisión intenta producir.
La tesis detrás del flujo
En el fondo, los cuatro pasos responden a una idea bastante sencilla:
la inteligencia artificial no debería alejar al investigador de su manuscrito; debería ayudarle a volver a él con preguntas más precisas.
La herramienta no termina el trabajo cuando genera una respuesta.
Termina cuando el usuario sabe mejor qué revisar.
Ese es el tipo de interacción que intento construir con Philologica.
Philologica
El flujo actual de Philologica se organiza alrededor de cuatro etapas:
1. Subir el manuscrito
2. Elegir un objetivo editorial
3. Recibir hallazgos estructurados
4. Verificar, revisar y exportar
Puedes explorar la plataforma en:
Philologica está diseñada como herramienta de apoyo a la revisión. Los resultados generados deben verificarse y evaluarse dentro del contexto académico correspondiente.
