El problema no era construir más herramientas.
El problema era conseguir que todas ellas trabajaran sobre el mismo manuscrito, el mismo contexto y el mismo proceso de revisión.
Una herramienta podía analizar estructura.
Otra revisar bibliografía.
Otra estudiar terminología.
Otra representar argumentos.
Otra observar cambios estilísticos.
Cada una podía ser útil por separado.
Pero si el usuario tenía que:
- subir nuevamente el documento;
- explicar otra vez el contexto;
- interpretar resultados independientes;
- recordar qué había corregido;
- conectar manualmente los hallazgos;
seguíamos teniendo herramientas.
No teníamos todavía un verdadero sistema editorial.
La idea que terminó articulando Philologica fue otra:
el centro del producto no debía ser la IA ni cada herramienta individual. Debía ser el manuscrito.
A partir de ahí muchas decisiones empezaron a tener más sentido.
El problema de construir una colección de herramientas
Cuando desarrollamos software basado en inteligencia artificial existe una tentación bastante natural.
Encontramos una capacidad interesante y construimos una función alrededor.
Por ejemplo:
«Podemos analizar un documento completo.»
Entonces creamos Document Analysis.
Después:
«Podemos estudiar argumentos.»
Creamos otra herramienta.
Después:
«Podemos analizar terminología.»
Otra más.
Y así sucesivamente.
El resultado puede terminar pareciéndose a una caja de herramientas.
Cada pieza funciona.
Pero el usuario necesita averiguar por sí mismo cómo encajan.
Una lista de funcionalidades no constituye un workflow
Este fue uno de los aprendizajes más importantes para mí.
Podemos tener diez funciones excelentes y seguir ofreciendo una experiencia fragmentada.
Porque la pregunta del investigador normalmente no es:
«¿Qué herramientas de inteligencia artificial puedo ejecutar?»
Su pregunta es mucho más sencilla:
«¿Qué tengo que revisar en mi manuscrito antes de entregarlo?»
O:
«¿Está bien construida mi bibliografía?»
O:
«¿Hay algún problema importante en mis conclusiones?»
El producto tenía que organizarse alrededor de estas tareas.
No alrededor de la tecnología que las hace posibles.
El manuscrito como proyecto
La decisión conceptual más importante fue empezar a tratar el manuscrito como un proyecto académico.
No simplemente como un archivo que entra en un modelo y produce una respuesta.
Un proyecto tiene continuidad.
Tiene:
- un documento;
- una versión;
- análisis;
- hallazgos;
- decisiones;
- historial.
Eso cambia completamente la arquitectura conceptual.
En lugar de:
PDF
↓
PROMPT
↓
RESPUESTAempezamos a pensar:
MANUSCRITO
↓
PROYECTO
↓
ANÁLISIS
↓
HALLAZGOS
↓
REVISIÓN
↓
NUEVA VERSIÓNEl segundo modelo se parece mucho más a cómo funciona realmente el trabajo editorial.
La revisión no ocurre una sola vez
Esta observación parece evidente, pero tiene consecuencias importantes para el software.
Una tesis no pasa por:
escribir → revisar → terminar.
Normalmente pasa por algo como:
BORRADOR
↓
REVISIÓN
↓
CORRECCIONES
↓
DIRECTOR
↓
NUEVAS CORRECCIONES
↓
OTRA REVISIÓN
↓
VERSIÓN FINALUn paper puede seguir:
MANUSCRITO
↓
REVISIÓN INTERNA
↓
SUBMISSION
↓
PEER REVIEW
↓
REVISION
↓
RESUBMISSIONPor tanto, una herramienta académica debería entender que el documento evoluciona.
El problema de las conversaciones aisladas
Un chat es extraordinariamente útil para muchas tareas.
Pero tiene una estructura muy particular.
Pregunta.
Respuesta.
Otra pregunta.
Otra respuesta.
La unidad principal es la conversación.
En revisión editorial necesitaba otra unidad.
El documento.
Porque una observación realizada hoy puede seguir siendo importante dentro de tres semanas.
Y quiero poder saber:
¿Seguía existiendo en la nueva versión?
Una conversación aislada no está diseñada necesariamente alrededor de esa pregunta.
No quería construir simplemente otro chatbot
Este principio terminó siendo una de las diferencias más claras de Philologica.
Un chatbot general parte normalmente de:
«¿Qué quieres preguntarme?»
Yo quería que Philologica partiera de:
«¿Qué quieres revisar?»
Parece una diferencia pequeña.
No lo es.
La primera pregunta organiza la experiencia alrededor de prompts.
La segunda la organiza alrededor de objetivos editoriales.
De prompts a herramientas
Eso llevó a otro cambio.
No quería que el usuario tuviera que saber diseñar un prompt complejo como:
«Analiza este documento desde una perspectiva estructural, identifica inconsistencias, clasifícalas por importancia, proporciona evidencia, localiza los fragmentos…»
Esa complejidad debería pertenecer al sistema.
El usuario debería poder elegir:
Document Review
o:
Source Research & Verification
o:
Argumentation & Terminology.
El objetivo editorial actúa como interfaz.
La herramienta debe conocer su propósito
Una herramienta especializada puede estructurar mejor:
- qué información necesita;
- qué analiza;
- qué tipo de resultado produce;
- qué límites tiene.
Eso permite pasar de una interacción abierta a un workflow.
No elimina la flexibilidad de la IA.
La coloca dentro de una estructura.
Las cinco áreas terminaron organizando el sistema
La arquitectura actual de Philologica puede entenderse a través de cinco grandes objetivos editoriales.
1. Document Review
La primera pregunta es:
¿Qué está ocurriendo en el manuscrito como conjunto?
Aquí encajan herramientas orientadas a:
- estructura;
- coherencia;
- fragmentos;
- riesgos editoriales;
- diagnóstico general.
2. Source Research & Verification
Después aparece otra dimensión:
¿Qué ocurre con las fuentes que sostienen el documento?
Aquí entran:
- citas;
- bibliografía;
- DOI;
- metadatos;
- verificación externa.
3. Argumentation & Terminology
Una tercera pregunta:
¿Cómo están construidas las ideas?
Esto conduce a:
- tesis;
- premisas;
- evidencia;
- conclusiones;
- conceptos;
- terminología.
4. Style & Authorship
Después podemos observar:
¿Cómo cambia la forma de escribir dentro del manuscrito?
Aquí aparece la estilometría y el análisis comparativo de patrones.
5. Publication Preparation
Finalmente:
¿Qué necesita el documento antes de avanzar en el proceso editorial?
Esta capa empieza a conectar todos los análisis anteriores.
Las cinco áreas no son simplemente categorías de producto.
Representan maneras diferentes de mirar el mismo objeto.
El mismo manuscrito visto desde cinco perspectivas
Esta idea terminó pareciéndome más interesante que tener cinco herramientas independientes.
┌─ DOCUMENT REVIEW
│
├─ SOURCES
│
MANUSCRITO ───────┼─ ARGUMENTATION & TERMINOLOGY
│
├─ STYLE & AUTHORSHIP
│
└─ PUBLICATION PREPARATIONEl documento no cambia.
Cambia la pregunta que hacemos sobre él.
Eso permite que los resultados puedan empezar a relacionarse.
Una inconsistencia rara vez pertenece a una única categoría
Imaginemos que Philologica detecta que el término autonomía cambia de significado entre dos capítulos.
A primera vista es un problema de terminología.
Pero puede afectar a un argumento.
Ese argumento puede aparecer en una conclusión.
Y esa conclusión puede utilizar una fuente determinada.
De repente tenemos:
TERMINOLOGÍA
↓
ARGUMENTACIÓN
↓
CONCLUSIÓN
↓
FUENTESi las herramientas viven completamente aisladas, esta relación se pierde.
El verdadero potencial aparece en las conexiones
Una herramienta individual puede detectar algo.
Un ecosistema puede ayudar a entender qué significa ese hallazgo dentro del resto del documento.
Por ejemplo:
«Este término cambia de significado.»
puede llevar a:
«Ese cambio afecta a esta premisa.»
y después:
«Esta conclusión depende de esa premisa.»
La revisión empieza a parecerse menos a una lista de errores.
Empieza a parecerse a una representación del manuscrito.
Del texto como cadena al documento como red
Normalmente pensamos un documento de forma lineal.
Página 1
↓
Página 2
↓
Página 3
↓
...
↓
Página 300Pero editorialmente también podemos verlo como una red.
CONCEPTO
↕
FUENTE
↕
ARGUMENTO
↕
CAPÍTULO
↕
CONCLUSIÓNEsta segunda visión permite hacer preguntas diferentes.
Por ejemplo:
¿Dónde aparece este concepto?
¿Qué conclusiones dependen de esta fuente?
¿Qué partes del documento sostienen esta tesis?
La trazabilidad apareció como consecuencia natural
Cuando empiezas a pensar en relaciones, necesitas poder regresar al origen.
Si el sistema dice:
«Hay una inconsistencia.»
necesitamos saber:
dónde.
Si dice:
«Esta conclusión parece débil.»
necesitamos saber:
qué conclusión y qué evidencia ha utilizado.
Así aparece una estructura que se ha convertido en uno de los principios centrales de Philologica:
HALLAZGO
↓
UBICACIÓN
↓
EVIDENCIA
↓
FUENTE
↓
RECOMENDACIÓNLa trazabilidad no nació para hacer informes más bonitos
Nació porque necesitaba que el usuario pudiera cuestionar a la IA.
Una conclusión automática que no puede verificarse termina exigiendo confianza.
Yo prefiero otro modelo:
«Esto es lo que he encontrado.
Aquí está.
Esta es la evidencia.
Esta es mi interpretación.
Ahora revísalo tú.»
Eso me parece mucho más compatible con el trabajo académico.
La IA debería ser discutible
Esto puede parecer una formulación extraña para un producto.
Normalmente queremos demostrar que nuestra tecnología tiene razón.
Pero en un entorno académico me interesa más que pueda ser examinada.
Un investigador puede decir:
«Este hallazgo no es correcto.»
Perfecto.
Si puede ver la evidencia y explicar por qué, el sistema está funcionando como herramienta crítica.
Del output libre al hallazgo estructurado
Otra evolución importante fue dejar de pensar en el resultado simplemente como texto.
Un modelo puede devolver:
«La sección 4 es confusa y debería desarrollarse mejor.»
Pero para un sistema editorial necesito algo más parecido a:
ID:
finding_017
Categoría:
Argumentación
Prioridad:
Alta
Ubicación:
Capítulo 4 · sección 4.3
Fragmento:
"..."
Observación:
...
Evidencia:
...
Recomendación:
...
Estado:
PendienteAhora el resultado puede formar parte de un workflow.
Un hallazgo tiene vida
Puede estar:
pendiente.
Después:
revisado.
Después:
corregido.
O:
descartado.
Esa pequeña diferencia cambia mucho el producto.
Porque el análisis deja de ser el final.
Pasa a ser el comienzo de una revisión.
El workflow empezó a importar más que el modelo
Este ha sido otro aprendizaje importante.
Cuando trabajamos con IA resulta fácil concentrarnos en:
- qué modelo utilizamos;
- qué contexto soporta;
- qué tan buena es su respuesta.
Todo eso importa.
Pero para el usuario final puede importar todavía más:
- ¿puedo encontrar el problema?
- ¿puedo verificarlo?
- ¿puedo cerrarlo?
- ¿puedo regresar después?
- ¿puedo exportarlo?
La inteligencia del modelo es una parte del producto.
El workflow es otra.
Una respuesta extraordinaria puede producir una experiencia mediocre
Si una IA analiza magníficamente una tesis pero produce treinta páginas de texto sin estructura, el usuario todavía tiene muchísimo trabajo.
En cambio, una observación algo más concisa pero perfectamente:
- clasificada;
- localizada;
- priorizada;
- verificable;
puede resultar mucho más útil.
Esto cambió también mi forma de evaluar resultados.
No basta con preguntar «¿la IA respondió bien?»
También necesitamos preguntar:
¿Puede el usuario actuar sobre la respuesta?
Una buena herramienta editorial debe producir acción posible.
Por qué conectar fuentes académicas externas
Otra limitación evidente aparecía en bibliografía.
Un modelo puede conocer mucha literatura.
Pero no debería convertirse en la fuente final de verificación bibliográfica.
Necesitaba separar dos capas:
IA
↓
INTERPRETACIÓN
BASE ACADÉMICA
↓
EVIDENCIA EXTERNADe ahí la importancia de conectar el flujo bibliográfico con infraestructuras académicas como:
- Crossref;
- OpenAlex;
- DataCite;
- DOAJ;
- Open Library.
La IA no debería inventarse su propia realidad bibliográfica
Si una referencia existe, quiero poder comprobarla fuera de la respuesta del modelo.
Esto llevó a otra regla conceptual:
la IA puede ayudar a interpretar evidencia, pero la evidencia debería poder existir independientemente de la IA siempre que sea posible.
Esto también cambia la interfaz
En lugar de:
«Referencia válida.»
prefiero:
- referencia del manuscrito;
- coincidencia encontrada;
- DOI;
- fuente consultada;
- posibles discrepancias.
Otra vez aparece el mismo principio:
menos autoridad opaca y más verificabilidad.
La especialización empezó a tener más sentido que un único análisis gigantesco
Podríamos imaginar una función:
«ANALIZAR TODO.»
Y pedir al sistema que examine simultáneamente:
- estructura;
- argumentación;
- fuentes;
- estilo;
- terminología;
- preparación editorial.
Pero una operación gigantesca tiene varios problemas.
Resulta más difícil:
- explicar qué está haciendo;
- controlar el resultado;
- evaluar cada dimensión;
- mostrar límites.
Por eso prefiero objetivos especializados dentro del mismo proyecto.
Un proyecto común, análisis diferentes
La estructura pasa a ser:
PROYECTO
│
├── Document Analysis
├── Bibliography
├── Argumentation
├── Terminology
├── Stylometry
└── Publication PreparationEsto permite mantener contexto sin confundir funciones.
El usuario debería elegir una intención, no configurar una IA
También quería evitar que Philologica exigiera conocimientos sobre modelos.
El usuario no debería tener que pensar:
«¿Qué temperatura utilizo?»
o:
«¿Qué prompt system necesito?»
Su decisión debería ser editorial:
«Quiero revisar mis fuentes.»
La complejidad técnica pertenece al producto.
El mejor software desaparece detrás de la tarea
Esto es algo que intento aplicar constantemente.
Cuando una persona entra en Philologica no quiero obligarla a pensar constantemente en inteligencia artificial.
Quiero que piense en:
su tesis.
Su paper.
Su bibliografía.
Su argumento.
Sus conclusiones.
La IA debería estar presente, pero no convertirse en la protagonista absoluta de la experiencia.
La tecnología como infraestructura invisible
Idealmente:
USUARIO PIENSA:
"Quiero revisar mi bibliografía."
SISTEMA RESUELVE:
extracción
segmentación
modelos
consultas externas
comparación
estructuraciónEl usuario recibe:
hallazgos verificables.
Esa separación hace el producto más accesible.
El informe se convirtió en una pieza central
Cuando tienes múltiples análisis sobre el mismo documento necesitas una forma común de presentar los resultados.
De ahí surge la importancia del informe editorial.
No como un PDF decorativo.
Sino como una representación estructurada del estado del manuscrito.
Puede contener:
- resumen ejecutivo;
- prioridades;
- categorías;
- hallazgos;
- evidencia;
- recomendaciones;
- estado.
El informe conecta las herramientas
Document Analysis puede producir un hallazgo.
Bibliography otro.
Dialectical Assistant otro.
Stylometry Radar otro.
Pero todos pueden terminar dentro de una arquitectura común.
ANÁLISIS A ──┐
ANÁLISIS B ──┤
ANÁLISIS C ──┼──→ INFORME
ANÁLISIS D ──┤
ANÁLISIS E ──┘Esto convierte módulos diferentes en una experiencia coherente.
La prioridad surgió de un problema práctico
Una IA puede encontrar muchas cosas.
Eso no significa que todas merezcan la misma atención.
Si un análisis devuelve setenta observaciones sin jerarquía, puede aumentar la ansiedad en lugar de reducirla.
Necesitaba responder:
«¿Qué debería revisar primero?»
Por eso prioridad y severidad se vuelven importantes.
El objetivo no es encontrar el máximo número de errores
Esta es otra diferencia conceptual.
Un sistema puede parecer mejor si encuentra:
137 problemas.
Pero quizá 120 son irrelevantes.
Otro encuentra:
12 cuestiones.
y cuatro de ellas afectan realmente al argumento central.
El segundo puede ser mucho más útil.
La métrica no debería ser únicamente cantidad de hallazgos.
También:
relevancia.
El riesgo de convertir la revisión en una puntuación
Al construir herramientas académicas existe además una atracción por los números.
Por ejemplo:
«Calidad académica: 91 %.»
Es visualmente atractivo.
Pero puede esconder demasiadas decisiones.
¿91 según qué disciplina?
¿Qué metodología?
¿Qué significa exactamente?
Por eso he ido prefiriendo métricas que ayuden a orientarse sin presentarse como una calificación universal.
Los indicadores deben abrir preguntas
Una puntuación puede ser útil si significa:
«Aquí existe una zona que merece inspección.»
No si significa:
«La máquina ha decidido la calidad de tu investigación.»
El juicio académico tenía que permanecer fuera del sistema automático
Cuantas más capacidades incorporaba Philologica, más importante se volvía este límite.
Podemos detectar:
- una referencia que no coincide;
- un cambio terminológico;
- una anomalía estilística;
- una posible premisa implícita.
Pero decidir:
«Este trabajo hace una contribución científica suficiente.»
es otra clase de decisión.
Más herramientas requieren límites más claros
Paradójicamente, cuanto más puede hacer un sistema, más importante es explicar qué no debería decidir.
Por eso la revisión humana terminó siendo parte de la arquitectura conceptual.
IA DETECTA
↓
IA EXPLICA
↓
EVIDENCIA
↓
HUMANO REVISA
↓
HUMANO DECIDENo considero la última capa una limitación que debamos eliminar.
La considero parte del producto.
El investigador no debería convertirse en supervisor pasivo
También quería evitar otro extremo.
Una interfaz con cincuenta botones:
Aceptar.
puede decir que existe revisión humana.
Pero si el usuario no comprende las modificaciones, el control es superficial.
Por eso evidencia y explicación son tan importantes.
La arquitectura debería favorecer el pensamiento
Una herramienta académica puede diseñarse para:
hacer más rápido el clic.
O para:
hacer más clara la decisión.
Me interesa mucho más la segunda.
De varias herramientas a un lenguaje común
Otro reto de un ecosistema es que cada módulo puede hablar un lenguaje diferente.
Bibliografía habla de:
DOI.
Argumentación de:
premisas.
Estilometría de:
patrones.
Terminología de:
conceptos.
Pero la interfaz necesita conceptos comunes.
Por ejemplo:
- hallazgo;
- ubicación;
- evidencia;
- prioridad;
- recomendación;
- estado.
Ese vocabulario común permite conectar análisis muy diferentes.
El hallazgo se convierte en la unidad común
Esto es interesante desde el diseño del sistema.
No importa demasiado si el hallazgo procede de:
- bibliografía;
- argumentación;
- estilometría.
Todos pueden responder:
¿Qué has encontrado?
¿Dónde?
¿Con qué evidencia?
¿Qué debería revisar?
Esa estructura común es una especie de lenguaje interno del producto.
Las herramientas dejan de ser islas
Cuando todos los resultados comparten estructura, podemos imaginar relaciones.
Por ejemplo:
Finding #12
Terminología
relacionado con
Finding #31
ArgumentaciónAhora el ecosistema puede empezar a mostrar que dos problemas aparentemente separados quizá tienen un origen común.
Esta es una de las direcciones que más me interesan
No simplemente añadir más herramientas.
Sino aumentar la capacidad de las herramientas existentes para relacionar sus resultados.
Porque el manuscrito real ya está conectado.
El software debería poder reflejarlo cada vez mejor.
El concepto de ecosistema editorial
Utilizo ecosistema porque Philologica ya no tiene sentido para mí como una única función.
Es una combinación de:
- documento;
- herramientas;
- fuentes académicas;
- hallazgos;
- informes;
- revisión humana.
Podemos representarlo así:
FUENTES ACADÉMICAS
↕
DOCUMENTO ↔ HERRAMIENTAS ↔ HALLAZGOS
↕
INFORME
↕
REVISIÓN HUMANALa inteligencia artificial está dentro del sistema.
No es todo el sistema.
Eso cambia también cómo pienso el producto
La pregunta deja de ser:
«¿Qué nueva función basada en IA podemos añadir?»
y pasa a ser:
«¿Qué parte del workflow editorial sigue estando mal resuelta?»
La segunda pregunta me parece mucho más productiva.
La funcionalidad debe responder a un problema editorial
Por ejemplo:
problema:
«No sé si mis referencias coinciden con las citas.»
Herramienta:
auditoría bibliográfica.
Problema:
«Mi concepto principal parece cambiar entre capítulos.»
Herramienta:
Editorial Thesaurus.
Problema:
«No sé si esta conclusión está realmente respaldada.»
Herramienta:
Dialectical Assistant.
Esta relación debería seguir siendo visible.
La arquitectura del producto también comunica una filosofía
El diseño de software nunca es completamente neutral.
Si construimos una gran caja de texto, estamos diciendo:
«La unidad principal es la conversación.»
Si construimos proyectos, herramientas, hallazgos y evidencia, estamos diciendo:
«La unidad principal es el proceso de revisión.»
Philologica intenta acercarse a la segunda idea.
Del asistente a la infraestructura
Al principio resulta natural describir un producto de IA como:
«asistente».
Pero cuanto más evoluciona el sistema, más me interesa otra palabra:
infraestructura.
Una infraestructura no necesita hablar constantemente.
Organiza.
Relaciona.
Conserva.
Verifica.
Permite trabajar.
Quizá la mejor IA académica no tenga que parecer tanto una IA
Esta es una idea que me resulta cada vez más interesante.
El usuario puede experimentar inteligencia artificial sin enfrentarse constantemente a una conversación.
Por ejemplo:
abre un hallazgo.
Ve una discrepancia.
Consulta una fuente.
Compara dos fragmentos.
Marca un problema como resuelto.
La IA está detrás de varias de esas operaciones.
Pero la experiencia sigue siendo editorial.
El flujo actual resume bastante bien esta evolución
La lógica puede reducirse a cuatro pasos.
1. SUBIR MANUSCRITO
↓
2. ELEGIR OBJETIVO
↓
3. RECIBIR HALLAZGOS
↓
4. VERIFICAR, EDITAR Y EXPORTARMe gusta porque cada paso conserva una responsabilidad clara.
El sistema analiza.
El usuario verifica.
El documento continúa evolucionando.
Lo que he intentado evitar
Durante este proceso he ido identificando varias direcciones que no quería convertir en el centro de Philologica.
1. Un chatbot académico genérico
Puede ser útil.
Pero no era el producto que quería construir.
2. Una máquina de puntuaciones
No quiero reducir un manuscrito complejo a un número que parezca una evaluación académica absoluta.
3. Un generador automático de correcciones
No quiero que el investigador deje de saber qué ha cambiado en su propio texto.
4. Un detector acusatorio
Una anomalía estilística no debe convertirse automáticamente en una acusación de cambio de autoría o uso de IA.
5. Una autoridad bibliográfica cerrada
Las referencias deben poder verificarse externamente.
6. Una caja negra editorial
Los hallazgos importantes deberían mostrar procedencia y evidencia.
Lo que sí intento construir
Una infraestructura donde:
- el manuscrito sea el centro;
- las herramientas tengan objetivos claros;
- los resultados sean estructurados;
- la evidencia sea visible;
- las fuentes puedan verificarse;
- los hallazgos puedan revisarse;
- el juicio siga siendo humano.
Eso describe mucho mejor mi idea de Philologica.
La integración es más importante que el número de funciones
Podemos añadir veinte herramientas nuevas.
Pero si cada una produce otro silo, el producto se vuelve más complejo.
Prefiero que cinco herramientas trabajen profundamente sobre el mismo proyecto y compartan contexto.
La pregunta para nuevas funciones debería ser:
¿Se integra en el workflow?
No simplemente:
¿Podemos construirla?
La evolución futura que me interesa
Hay muchas direcciones posibles.
Pero conceptualmente me interesan especialmente aquellas que profundizan la relación entre los análisis.
Por ejemplo:
FUENTE
↓
AFIRMACIÓN
↓
PREMISA
↓
ARGUMENTO
↓
CONCLUSIÓNSi el sistema puede reconstruir cada vez mejor estas relaciones, la revisión puede ganar profundidad sin perder trazabilidad.
También me interesa la comparación temporal
Un manuscrito no es estático.
Quiero poder pensar:
VERSIÓN A
↓
HALLAZGOS
↓
CORRECCIONES
↓
VERSIÓN B
↓
¿QUÉ CAMBIÓ?Esto convierte Philologica en algo más parecido a una memoria editorial del proyecto.
De detectar errores a seguir decisiones
Una siguiente evolución natural no consiste únicamente en saber:
«¿Qué problema había?»
Sino:
«¿Qué decidió hacer el autor con él?»
Eso permite construir una historia de revisión.
El valor institucional también depende de esta arquitectura
Para estudiantes individuales, una herramienta puede ser suficiente.
Pero para:
- universidades;
- equipos de investigación;
- editoriales;
la continuidad y el workflow adquieren mucha más importancia.
Necesitan procesos.
No simplemente respuestas.
Pero institucionalizar no debería significar automatizar el juicio
Esta frontera sigue siendo importante.
Una universidad puede estandarizar una primera revisión.
Una editorial puede ordenar hallazgos.
Un equipo puede compartir un informe.
Pero no quiero que el sistema termine diciendo automáticamente:
«Este trabajo es válido.»
o:
«Este manuscrito debe rechazarse.»
La infraestructura puede ayudar a decidir.
No necesita apropiarse de la decisión.
El aprendizaje más importante
Después de trabajar en Philologica, hay una idea que considero especialmente importante:
construir una buena herramienta de IA no consiste únicamente en conseguir que el modelo responda bien.
También consiste en decidir:
- qué información recibe;
- qué función está realizando;
- cómo conserva el contexto;
- cómo estructura el resultado;
- cómo muestra la evidencia;
- qué decisiones no debería tomar.
En otras palabras:
la calidad está tanto en el modelo como en la arquitectura que construimos alrededor.
La inteligencia debe tener forma
Un modelo generativo es extraordinariamente flexible.
Puede producir casi cualquier clase de texto.
Pero esa flexibilidad necesita forma para convertirse en una herramienta profesional.
En Philologica, esa forma intenta venir de:
objetivos.
proyectos.
hallazgos.
evidencia.
workflow.
De «preguntar a una IA» a «revisar un manuscrito»
Quizá esta sea la mejor forma de describir toda la evolución.
La primera experiencia es:
«Tengo una IA. Voy a preguntarle cosas sobre mi PDF.»
La segunda:
«Tengo un manuscrito. Voy a realizar una revisión estructurada.»
La IA sigue ahí.
Pero el foco ha cambiado.
Ese cambio es, para mí, Philologica.
El producto no es la colección de herramientas
Document Analysis no es por sí solo Philologica.
Bibliography Catalog tampoco.
Dialectical Assistant tampoco.
Editorial Thesaurus tampoco.
Stylometry Radar tampoco.
Lo que empieza a definir el producto es la forma en que todas estas piezas pueden trabajar alrededor del mismo proyecto académico.
La tesis detrás de Philologica
Si tuviera que resumir la arquitectura conceptual del producto en una sola frase sería:
un manuscrito académico no necesita otra IA que simplemente hable sobre él; necesita un entorno capaz de revisarlo como un sistema de fuentes, argumentos, conceptos, estilo y decisiones editoriales conectadas.
Esa es la dirección.
Menos herramientas aisladas.
Menos respuestas efímeras.
Menos confianza opaca.
Más contexto.
Más conexiones.
Más trazabilidad.
Más capacidad para comprobar.
Y, finalmente, más control para el investigador
Porque detrás de toda la tecnología sigue existiendo un documento que pertenece a una persona.
Una investigación que alguien debe poder defender.
Un argumento del que alguien debe hacerse responsable.
Una conclusión que alguien debe decidir mantener.
Philologica puede ayudar a mirar ese trabajo desde perspectivas que serían difíciles de mantener simultáneamente en una revisión manual.
Pero la finalidad no es desplazar al investigador.
Es devolverle una visión más estructurada de su propio manuscrito.
Para que pueda hacer algo que ninguna puntuación automática debería sustituir:
leer la evidencia, comprender el problema y decidir.
Philologica: un ecosistema editorial alrededor del manuscrito
Hoy Philologica organiza la revisión mediante cinco grandes objetivos: Document Review, Source Research & Verification, Argumentation & Terminology, Style & Authorship y Publication Preparation.
Todos parten del mismo principio: el manuscrito funciona como un proyecto y los resultados deben convertirse en hallazgos estructurados que puedan localizarse, verificarse y revisarse.
El workflow puede resumirse en cuatro pasos:
- subir el manuscrito;
- elegir el objetivo de revisión;
- recibir hallazgos priorizados y trazables;
- verificar, editar y exportar.
Puedes explorar Philologica en:
Philologica está diseñado como instrumento de apoyo a la revisión académica y editorial. Sus resultados requieren verificación y el juicio académico permanece en manos de autores, investigadores y editores.
