PDF a Markdown para LLMs: preparar documentos para ChatGPT, Claude y RAG
Pega un PDF en un modelo de chat y normalmente funciona, en el sentido de que el modelo responde. Por debajo, el ruido de maquetación del PDF —líneas partidas, encabezados y pies repetidos, rarezas en el orden de lectura— se convierte en tokens que el modelo tiene que atravesar antes de llegar al contenido.
Convertir primero a Markdown elimina la mayor parte de ese ruido en el origen. Este artículo explica de dónde viene el ruido del PDF, cuánto cuesta en tokens, por qué los párrafos de una sola línea importan para el chunking y los diffs, y cómo el modo de salida optimizado para LLM de este sitio está hecho exactamente para este flujo de trabajo.
Por qué los LLM se atragantan con los PDF en bruto
Cuando una herramienta de chat acepta un PDF directamente, algo tiene que convertirlo primero en texto, y ese algo suele ser un extractor rápido y genérico. Lo que sale conserva los artefactos de almacenamiento del PDF: saltos de línea a media frase, guiones de la justificación original, encabezados y pies de página repetidos en cada página y texto de columnas entrelazado en orden de almacenamiento.
Los modelos son buenos mirando más allá de esto, y por eso la subida directa parece funcionar. Pero el modelo gasta atención reensamblando párrafos que un conversor habría entregado intactos, y en documentos largos el desperdicio se acumula: solo los pies de página repetidos pueden ser miles de tokens de pura repetición.
El texto estructurado también ancla las citas del modelo. Cuando le pides al modelo que cite la cláusula en la que basó una respuesta, la numeración de cláusulas y los niveles de encabezado de una conversión a Markdown le dan puntos de referencia estables; un muro de texto PDF refluido no le da nada a lo que apuntar.
El coste oculto en tokens del ruido PDF
Los tokenizadores cobran por fragmentos de texto, y el ruido PDF está hecho de fragmentos. Un párrafo con salto duro cuesta los mismos caracteres pero más saltos de línea; un pie de página repetido cuarenta veces es un coste fijo por página, importe o no; los cortes con guion como «conver- sion» pueden dividirse en fragmentos que ni coinciden con la palabra ni aportan significado.
El desperdicio no es solo volumen, es posición. Las ventanas de contexto son finitas, y el ruido al principio empuja el contenido hacia el punto de truncado. Documentos que cabrían cómodamente como Markdown limpio a veces se desbordan como volcados PDF en bruto, y la calidad de la respuesta del modelo se degrada mucho antes de que se corte nada.
Nada de esto se nota en el tono de la respuesta, por eso pasa desapercibido. Se nota en cuánto del documento procesó realmente el modelo, y en la factura si pagas por token a través de una API.
Un párrafo, una línea: por qué importan los saltos
Las herramientas de texto tradicionales parten la salida a 72 u 80 columnas porque así funcionaban los terminales y las páginas impresas. En un archivo Markdown destinado a un modelo, cada uno de esos cortes es un posible límite de chunk en una pipeline de recuperación que divide por saltos de línea o longitudes de párrafo.
Los párrafos de una sola línea hacen el chunking trivial: un párrafo es una línea, un divisor puede cortar en las líneas en blanco y cada chunk contiene frases completas. Con texto partido, la misma pipeline debe primero deshacer los saltos, y si no lo hace, los chunks se rompen a media frase y la calidad de la recuperación cae de formas difíciles de depurar.
Los diffs por líneas obtienen el mismo beneficio. Cuando una revisión de contrato cambia una cláusula, un archivo de párrafos de una línea muestra exactamente una línea modificada; un archivo partido puede refluir el resto del párrafo y enterrar el cambio real en una docena de bloques de diff.
El perfil compacto en la práctica
El conversor de este sitio tiene un interruptor explícito de optimización para LLM. Activado, hace dos cosas: el motor PDF se ejecuta en su perfil de extracción compacto, que prefiere texto plano y ajustado a la verbosidad fiel al diseño, y el escritor de Markdown desactiva el salto de línea duro para que cada párrafo sea una línea.
El perfil compacto es un equilibrio distinto, no estrictamente mejor. Los modos fieles al diseño reproducen más de la estructura visual de la página, que es lo que quiere un lector humano que convierte para editar. El modo compacto elimina esa decoración hasta dejar contenido y estructura, que es lo que quiere un flujo de tokens.
El interruptor solo afecta a la salida Markdown, y es deliberado: los destinos HTML, RST y LaTeX los consumen renderizadores que de todos modos vuelven a partir las líneas. Si tu destino es un modelo, quédate en Markdown con el interruptor activado; si es un humano, el valor por defecto se lee mejor.
Alimentar Markdown a una pipeline RAG
La generación aumentada por recuperación vive o muere según la calidad de los chunks. Markdown da a la pipeline algo que el PDF nunca podrá: límites estructurales que también son límites semánticos. Los encabezados marcan temas, así que un divisor puede crear chunks por sección y adjuntar el rastro de encabezados como metadatos; las tablas llegan como bloques de tabla de tuberías intactos que sobreviven al embedding como unidades.
La receta práctica es aburrida a propósito: convierte cada PDF a Markdown de párrafos de una línea, divide por encabezados con un techo de tamaño, conserva la ruta de encabezados con cada chunk y genera los embeddings. Cada paso es una línea contra un archivo Markdown bien formado, y una heurística frágil contra un PDF en bruto.
La conversión por lotes importa aquí más que en el uso interactivo. Una base de conocimiento son decenas o cientos de documentos, y esta herramienta los convierte en serie en el navegador y empaqueta los resultados para descargar, sin paso de subida en medio —lo que importa más cuando los documentos son de los que no puedes subir.
Por qué la conversión debe ocurrir en tu máquina
Los documentos que la gente alimenta a los LLM son desproporcionadamente sensibles: contratos, actas de consejo, investigación inédita, archivos de clientes. Entregarlos a un conversor en la nube añade al flujo de datos un tercero cuya política de retención no escribiste tú, y la comodidad de arrastrar y soltar oculta que esto es una subida.
Este conversor ejecuta el motor de análisis de PDF como WebAssembly en la pestaña de tu navegador. El archivo se lee con la API de archivos del navegador, se procesa en memoria y se escribe de nuevo localmente; no hay ningún componente de servidor en la ruta de conversión. Puedes cargar la página, desconectarte de la red y la conversión sigue funcionando.
Esa decisión de diseño es la misma que hace que la herramienta sea adecuada específicamente para el flujo de trabajo LLM: el propósito de preparar un documento para un modelo suele ser mantener el control de quién lo ve. Un conversor que sube archivos socavaría ese objetivo un paso antes.
Límites a tener en cuenta
Los PDF escaneados no tienen capa de texto, y ningún perfil de conversión cambia eso. Si la fuente es un escaneo, pásalo primero por un software OCR y convierte la salida del OCR; el conversor marca las páginas sin texto extraíble en lugar de devolver silenciosamente una carcasa.
Las tablas complejas llegan simplificadas. Las tablas de tuberías GFM no pueden expresar celdas combinadas ni encabezados de varios niveles, así que los modelos ven una versión aplanada. En fuentes cargadas de tablas donde la tabla es lo importante, verifica algunas filas contra el original antes de fiarte de las respuestas posteriores.
Y el interruptor no es un dial de calidad para la extracción en sí: el modo compacto cambia la fidelidad con la que se reproduce el diseño, no la corrección con la que se reconoce el texto. Si una conversión produce caracteres ilegibles, el problema está en la codificación de la fuente, no en el perfil.