Proyecto de portfolio · octubre 2026
Caso de estudio
Contexto
En las plataformas de trazabilidad agrícola, los tableros para clientes suelen armarse a mano en una herramienta de BI. Cada pedido nuevo es trabajo de BI, y la definición de cada número queda dentro de los datasets. Cuando el mismo lote-campaña se evalúa contra varios estándares (EUDR, ISCC, 45Z), las definiciones se separan con el tiempo.
Quería ver hasta dónde se puede llegar dejando que la gente pregunte directamente, sin perder la posibilidad de auditar cada número.
Qué construí
- Una capa semántica en YAML: métricas, dimensiones permitidas, joins declarados, diccionarios de valores y brechas conocidas.
- Un planner que no escribe SQL: devuelve un plan tipado (métricas, dimensiones, filtros). Si falta información, pregunta; si no hay métrica, lo dice.
- Un validador y un compilador determinístico que convierten ese plan en SQL, ejecutado con un rol de solo lectura, timeout y tope de filas.
- Consultas verificadas para las preguntas frecuentes, que se resuelven sin LLM.
- En cada respuesta: la definición de la métrica, el SQL, las tablas de origen y filas de muestra («¿Cómo se calculó?»).
Cómo lo pruebo
Un set de 45 preguntas con el plan y el resultado esperados, que incluye preguntas ambiguas, fuera de alcance e intentos de inyección. Cada etapa se puntúa por separado y CI bloquea cambios que bajen la precisión. Última corrida:
| Resultado correcto (preguntas respondibles) | – |
| Rechazos e inyecciones manejados bien | – |
| Mediana de latencia (con LLM) | – |
| Costo promedio por pregunta | – |
Qué es real y qué no
| Pipeline: router, planner, validador, compilador, ejecutor de solo lectura | Real | Corre en esta demo, con un LLM real |
| Evaluaciones por etapa, con gates en CI | Real | Un cambio que baja la precisión no se mergea |
| Capa semántica | Real | Un modelo propuesto; en un caso real se valida con quienes son dueños de cada métrica |
| Productores, lotes, Crop Stories, alertas | Sintético | Generados con semilla, ubicados en departamentos reales |
| Cambio de uso del suelo (EUDR) | Simulado | El paso siguiente es JRC GFC2020 + MapBiomas |
| MongoDB Atlas como fuente de documentos | Real | El ELT extrae de Atlas, aplana y arma los marts |
| Marts en Postgres/PostGIS | Parcial | Mismo SQL; hoy los marts corren en DuckDB |
| Login, multi-cliente, seguridad por fila | Pendiente | Necesario antes de mostrarle algo a un cliente |
La regla que seguí
Cuando una evaluación falla, el arreglo va primero a la capa semántica (una descripción, un sinónimo, una dimensión permitida, un mart nuevo), después a los ejemplos y recién al final al prompt. Los benchmarks públicos de dbt Labs y Cube apuntan a lo mismo: con una capa semántica, la precisión depende más del modelado que del modelo.
Cómo llevaría esto a un equipo real está en el plan de implementación.