Una fábrica de apuntes: mis PDFs de estudio con un enjambre de agentes
Cuatro pipelines multiagente que convierten PDFs oficiales en apuntes limpios y verificados. La arquitectura, los verificadores por dominio, y el día que la IA corrigió un solucionario.
Estudiar ingeniería genera una montaña de trabajo mecánico: coger una hoja de ejercicios oficial, resolverla paso a paso, redactarla limpia, dibujar los esquemas, hacer un mapa del tema. Es valioso, pero es horas. Así que construí una fábrica: un conjunto de pipelines de agentes de IA que toman un PDF oficial y devuelven un PDF de estudio limpio y verificado.
No es un “pídele a un chatbot que te lo haga”. Es un sistema de responsabilidad separada, con verificación numérica dura y un bucle de revisión, que hoy ha producido 151 PDFs publicables en 8 asignaturas. Este post cuenta cómo está montado por dentro.
La regla que lo sostiene: separar verificación de presentación
El error del primer intento fue mezclar dos cosas que no deben tocarse: la comprobación de que la matemática es correcta, y el documento que lee el alumno. La regla que lo arregló todo es separarlas en dos artefactos, en dos carpetas:
A la izquierda, la verificación: código SymPy/SciPy (o lcapy, o el compilador
de diagramas) que comprueba cada resultado y escupe PASS/FAIL. Vive en
_verificacion/ y no se publica. A la derecha, el documento del alumno:
solo enunciado y resolución paso a paso. Nada de código, ni de PASS, ni de la
puntuación interna de dificultad. El worker verifica primero y solo entonces
redacta prosa alrededor de expresiones que ya sabe correctas.
El molde: un pipeline multiagente de responsabilidad separada
El corazón es el mismo para todas las asignaturas. Cuatro roles, cada uno hace una sola cosa, y un orquestador que mueve las piezas: los roles nunca se invocan entre sí, para que las responsabilidades no se contaminen.
- planner — lee el PDF (leyendo las páginas como imagen, porque
pdftotextrompe las fórmulas), puntúa la dificultad de cada ejercicio con una rúbrica interna, y escribe la estructura: catálogo, reparto en grupos y una lista de requisitos que será el checklist del reviewer. No resuelve nada. - workers (×N, en paralelo) — cada uno coge un grupo, lo resuelve, lo verifica aparte y redacta las celdas limpias. Están aislados: no se tocan entre sí. Se lanzan todos en el mismo mensaje.
- ensamblador — revisa cada pieza, la limpia, las mezcla en un notebook de solo markdown y compila el PDF. No juzga la matemática.
- reviewers (×1 a 4, en paralelo) — comparan el PDF con la lista de requisitos y devuelven un informe de fallos. En hojas grandes se reparten el documento por bloques.
El bucle de revisión tiene dos destinos según el tipo de fallo: los de montaje o formato (una fuga de código, un acento, una figura sin embeber) vuelven al ensamblador; los de contenido (un paso mal) vuelven al worker, que rehace su grupo y lo vuelve a verificar. Se repite hasta “aprobado”.
Un detalle de coste: opus donde importa, sonnet donde no
No todos los roles usan el mismo modelo. El planner y los workers corren en opus —transcribir fórmulas sin erratas y no equivocarse en la matemática es donde la potencia paga—. El ensamblador y los reviewers, que hacen trabajo mecánico y de control, corren en sonnet. Mezclar tiers por tarea abarata el conjunto sin perder donde de verdad cuenta.
Un molde, cuatro fábricas
Ese esqueleto no cambia entre asignaturas. Lo único que cambia es el verificador duro: la pieza que decide si un resultado es correcto de verdad, no solo plausible.
- resolver-ejercicios — hojas de Laplace, Fourier, EDPs, cálculo. La verdad
la pone SymPy/SciPy: transformadas,
dsolve, convolución,solve_ivppara los tramos. Cada subapartado tiene que dar PASS. - resolver-circuitos — aquí hay un giro bonito: la topología del circuito
no es texto, vive en las figuras (line-art vectorial que
pdftotextno ve). El worker lee la imagen, la escribe como un netlist SPICE, lo resuelve con lcapy y compara el resultado con la “Solución” impresa del boletín. La topología se demuestra, no se supone. - generar-ejercicios — el espejo generativo: inventa ejercicios nuevos del mismo tipo y nivel que los del profesor, con valores frescos. Verifica que son resolubles con SymPy y que de verdad difieren del original. Saca dos PDF: hoja de práctica y hoja de soluciones.
- mapa-conceptual — convierte un tema en un atlas visual de cuatro vistas
(mapa, árbol de métodos, taxonomía de ejercicios, grafo de prerrequisitos) en
Mermaid y Graphviz. Aquí el verificador es el propio compilador: si
mmdcodotno renderizan, el diagrama está mal.
El motor del PDF
El entregable no es HTML ni un Google Doc: es un PDF con matemática bien compuesta. La cadena es un notebook de solo markdown (cero celdas de código) que se convierte a LaTeX y se compila con xelatex:
jupyter nbconvert --to latex doc.ipynb --output-dir build --output doc
# en build/doc.tex: quitar \maketitle, \title, \date, \author;
# añadir tras \begin{document}: \setcounter{secnumdepth}{0}
xelatex doc.tex && xelatex doc.tex # dos pasadasEse post-proceso del .tex es lo que da el “PDF limpio”: sin el nombre de
fichero como título y sin numeración de secciones. Y antes de compilar, una red
de seguridad de expresiones regulares borra todo rastro técnico que se le
haya podido colar a un worker: etiquetas de nivel [N1]…[N5], líneas con
import o PASS, y cualquier procedencia (nombre de la asignatura, universidad,
PDF de origen). El alumno recibe solo lo que necesita.
Qué sale, y qué aprendí
El sistema lleva producidos 151 PDFs en 8 asignaturas. Pero la anécdota que mejor resume por qué el esfuerzo de verificar merece la pena es esta: al aplicarlo a la primera lección de Laplace, SymPy/SciPy confirmaron 35 subapartados y destaparon un error en el solucionario oficial (la parte entera del primer ejercicio estaba mal). Cuando verificas de verdad, a veces el que se equivoca es el profesor.
Tres lecciones que me llevo:
- Verificar aparte, desde el primer minuto. Si redactas ya sin código y la comprobación vive en otra carpeta, el PDF sale limpio a la primera.
- Leer imágenes, no solo texto.
pdftotextdestroza fórmulas y no ve las figuras; media arquitectura existe para rodear ese problema. - Separar roles evita que se contaminen. Un agente que resuelve y a la vez se autojuzga se engaña; un reviewer que solo revisa, no.
Al final, lo interesante no es “la IA me hace los deberes” —no lo hace: la parte de entender sigue siendo mía—. Es que la parte mecánica y repetitiva se puede delegar a un sistema que comprueba su propio trabajo antes de dármelo.