Recorte los tokens antes de que el modelo los vea

Cuando un agente necesita entender algo (un PDF de 10 páginas, un código fuente de 25,000 símbolos), lo fácil es verter el material en bruto en la ventana de contexto y dejar que el modelo lo ordene. Funciona, y es caro: cada byte se factura como tokens de entrada en cada turno en que sigue en el contexto, y un modelo que razona sobre ruido es más lento y comete más errores que uno al que se le da la señal.

Una herramienta de preprocesamiento cambia la forma del problema. En lugar de pagarle a un modelo de frontera para que lea un archivo binario o busque en todo un repositorio, usted corre un programa local barato que extrae solo la parte que importa (el texto, la relación) y le da al modelo una fracción de los bytes. El trabajo pasa de una API con costo a su propio hardware, y la cantidad de tokens baja un orden de magnitud. Dos herramientas ilustran las dos mitades de esto: documentos y código.

El problema. El flujo de trabajo de DLR está lleno de PDF: cotizaciones de proveedores, cotizaciones de la competencia, facturas. Un PDF no es texto; es un formato binario de diseño de página. Dárselo a un modelo significa subir el archivo completo (facturado como una gran carga de imagen o documento, y facturado de nuevo en cada turno en que sigue en el contexto) o pedirle al modelo que lo pase por OCR y lo analice desde cero. Para una cotización de varias páginas, son miles de tokens y varios segundos solo para llegar a palabras que ya estaban ahí.

Cómo funciona. MarkItDown es un pequeño convertidor de código abierto de Microsoft. Lee PDF, Word, PowerPoint, Excel, HTML, CSV, EPUB y hasta imágenes, y produce Markdown limpio y estructurado: conserva encabezados, tablas y listas, y quita la basura del diseño. Corre como una CLI local:

markitdown "vendor-quote.pdf" > quote.md
# 18,000 caracteres de Markdown limpio: encabezados, partidas, totales

El resultado es texto plano que un modelo puede leer a una fracción del costo en tokens del archivo original, y se puede leer a simple vista, así que usted puede verificar la extracción antes de gastar nada en la interpretación. En la infraestructura de DLR esto se volvió una deliberada regla de dos fases: la fase uno es la extracción del texto, hecha localmente por MarkItDown sin costo; la fase dos (convertir ese texto en JSON estructurado o hacer un juicio sobre él) va a un modelo, y solo cuando de verdad se necesita el juicio de un modelo. Los PDF escaneados o que solo tienen imágenes, donde no hay texto que extraer, recurren al modelo de visión. El puente de administración lo expone como una bandera extractText, y las rutas que manejan cotizaciones y la función edge de extracción de facturas corren todas primero la pasada local.

Lo que movió. Un PDF grande de cotización de proveedor que antes iba directo a un modelo para que lo leyera tardaba ~168 segundos y costaba unos $0.35 en tokens. El mismo PDF con MarkItDown: ~520 milisegundos, 18k caracteres extraídos, $0; al modelo solo se le paga cuando el texto de verdad necesita interpretación. Como regla práctica, un contenido que cuesta una fortuna como documento en bruto suele ser de 2–5K tokens como Markdown: una reducción de 10–50×, y más rápida.

El problema. Pregúntele a un agente de programación “¿qué llama a esta función?” o “¿qué se rompe si cambio este módulo?” y la respuesta ingenua es leer archivos (a menudo docenas, cientos de kilobytes) y meterlos al contexto hasta que el panorama quede claro. En un repositorio grande (la aplicación web de DLR tiene ~25,000 símbolos) eso agota la ventana de contexto en plomería antes de que empiece el trabajo real, y la mayor parte de lo que se leyó era ruido.

Cómo funciona. Graphify analiza el repositorio con tree-sitter (un analizador rápido que entiende cada lenguaje, sin ningún LLM de por medio) y extrae un grafo de conocimiento del código: cada función, clase y módulo es un nodo; cada relación calls, imports, contains e inherits es una arista. Para la aplicación web de DLR son unos 25,700 nodos y 40,100 aristas, escritos en un graphify-out/graph.json junto al código. Como es puro análisis sintáctico, construir el grafo no cuesta nada: ni tokens, ni API.

Una lente de solo lectura (la llamamos graph-eye) responde preguntas de arquitectura directamente desde ese grafo en lugar de desde los archivos:

• god: los nodos centrales, ordenados por cuántas cosas los tocan: el código de alto acoplamiento que es riesgoso cambiar.
• affected “X”: el radio de impacto inverso: todo lo que depende de X, para que vea lo que un cambio podría romper sin buscar en todo el árbol.
• find / explain: localiza un símbolo y muestra sus vecinos inmediatos (quién lo llama, a quién llama, qué importa).
• query “…”: un recorrido del grafo con tope de tokens que responde una pregunta en lenguaje natural con una respuesta acotada, no con un montón de archivos.

Lo que movió. Una pregunta como “¿cuál es el radio de impacto de cambiar esta función auxiliar de autenticación?”, que de otro modo significaría leer una docena de archivos de 100KB, ahora devuelve una lista precisa de menos de diez kilobytes. El grafo localiza el código; luego el agente lee solo el archivo que de verdad necesita editar. La disciplina importa: el grafo es un mapa, no la fuente de verdad de un cambio; usted sigue abriendo el archivo real antes de modificarlo.

Actualizado sin costo. Una tarea nocturna vuelve a extraer el grafo de seis repositorios, pero solo cuando el código de verdad cambió desde la última construcción, y corre en un entorno despojado, sin ninguna clave de API presente, así que se puede demostrar que no es capaz de tocar ninguna ruta con costo. Los grafos se reconstruyen antes de la revisión de la mañana, todos los días, con un costo en tokens de exactamente cero.

MarkItDown y Graphify hacen trabajos sin relación (uno lee documentos, el otro lee código), pero son la misma idea. Los dos ponen un paso local, barato y determinista delante del modelo caro. Convierta el binario antes de razonar sobre él. Haga el mapa del repositorio antes de buscar en él. Extraiga la señal en su propio hardware y luego gaste tokens con costo solo en la parte que de verdad necesita inteligencia.

Esa es la palanca que esta página agrega al manual. El enrutamiento y el caché deciden qué modelo responde y cuántas veces vuelve a pagar por el mismo prompt; las herramientas deciden cuánto le da. Las dos se multiplican: una entrada más pequeña y más limpia es más barata en cualquier modelo, así que recortar tokens desde el origen multiplica lo que el enrutamiento ya ahorró.