RidgeText, una herramienta de SMS asistida por un modelo de lenguaje, ha presentado un patrón de diseño orientado a reducir la carga de datos que recae sobre el LLM. El problema surge al generar mapas: los conjuntos de datos GeoJSON asociados a incendios, senderos u otras capas geoespaciales pesan entre 50 y 500 KB, lo que equivale a unos 125.000 tokens, una cifra que desborda la ventana de contexto de muchos modelos y dispara el coste por petición. Pasar ese volumen a través del LLM no aporta capacidad de razonamiento útil, pero sí riesgo de truncamiento, alucinaciones o respuestas silenciosamente erróneas.
La solución imita el modelo de capas de Mapbox. Cada herramienta de captura de datos (retrieve_wildfire_layer, retrieve_trail_layer, etc.) almacena el resultado en una cola server-side indexada por identificador de sesión y devuelve al LLM únicamente un acuse de recibo mínimo, con el identificador de capa y el número de elementos. Una herramienta final, generate_map, consume la cola, proyecta cada capa sobre una imagen base de Mapbox Static API y compone el resultado con la librería sharp, produciendo una URL de imagen lista para enviar por SMS. El orden de llamada de las herramientas define el orden de apilamiento de las capas.
El sistema emplea un mapa en memoria con TTL de 30 minutos para expulsar capas no renderizadas. Entre las ventajas se citan una ventana de contexto reducida (~150 tokens frente a más de 125.000), un pipeline determinista y testeable de forma aislada, y la posibilidad de añadir nuevas fuentes de datos sin modificar la interacción con el LLM. Entre las limitaciones, el modelo pierde la capacidad de razonar sobre la geometría subyacente y las capas no persisten entre turnos. El patrón es extrapolable a otros casos, como el enriquecimiento de datos multi-fuente o el análisis de logs en varias pasadas, siempre que el LLM funcione como mero orquestador en lugar de como tubería de datos.