Bienvenida a AgroSense

## Lunes, 9:15. Tu segundo encargo

No es tu primer día en una empresa de datos, y se nota. Vienes de pasar unos meses en una operadora de telefonía, donde montaste un modelo para adivinar qué clientes estaban a punto de darse de baja. Allí aprendiste algo que no se olvida: que un resultado que parece demasiado bueno casi siempre esconde un error, y que el trabajo de verdad no es entrenar el modelo, es entender el problema antes de tocarlo. Hoy empiezas en un sitio muy distinto —una empresa que vende sensores para el campo— y con un problema que, por debajo, es de otra familia. Esta lección no lleva una sola línea de código, y es a propósito: antes de predecir nada conviene entender dónde has aterrizado, quién te pide las cosas y qué decisión se va a tomar con tu respuesta.

AgroSense es una empresa de lo que se llama «agricultura de precisión»: en vez de regar y abonar a ojo, pone sensores en las parcelas que miden qué está pasando de verdad bajo tierra y manda esos datos a una plataforma. Nació en 2019 en Murcia, en pleno corazón de la huerta del sureste, cuando dos ingenieros agrónomos y un desarrollador se dieron cuenta de que las explotaciones de la zona tomaban las decisiones de riego por pura costumbre: se regaba lo que se había regado siempre, sin medir si la parcela lo necesitaba. En una región donde el agua es cara, está regulada y hay años de sequía dura, eso es dinero y es un recurso escaso tirados a partes iguales.

Hoy AgroSense tiene unos setenta empleados y nodos de sensores repartidos por unas dos mil parcelas, que miden la humedad del suelo, la temperatura, la lluvia y un índice de vegetación que llega desde satélite. Durante estos años, todos esos datos se han usado para una sola cosa: describir lo que ya pasó. «Tu parcela está seca», «ha llovido poco este mes». El salto que quieren dar ahora es el que de verdad convence a un agricultor y cierra una venta: no decirle cómo está la parcela hoy, sino predecirle cuánto va a cosechar. Y, con eso, decirle cuánto le conviene regar y abonar. Ese salto —de describir a predecir— es exactamente el motivo por el que te han contratado.

## El cambio que te va a cambiar la cabeza: de etiqueta a número

Aquí está la primera idea importante de la semana, y conviene entenderla despacio porque lo ordena todo lo demás. En tu trabajo anterior predecías una etiqueta: cada cliente caía en una de dos casillas, «se va» o «se queda». A eso se le llama un problema de clasificación: el modelo reparte las cosas en grupos. Aquí el problema es de otra familia. No vas a decir «esta parcela cosecha bien» o «cosecha mal»; vas a decir un número concreto: «esta parcela va a dar 8.200 kilos por hectárea». Eso se llama regresión: el modelo no elige una casilla, estima una cantidad que puede tomar cualquier valor dentro de un rango.

Ese cambio de etiqueta a número arrastra consigo un cambio en la pregunta que te haces para saber si el modelo es bueno. Cuando predices una casilla, la pregunta natural es «¿cuántas veces aciertas la casilla?». Cuando predices un número, acertar exacto es casi imposible —ninguna parcela da justo 8.200,0 kilos—, así que la pregunta ya no es «¿acierto?», es «¿por cuánto me paso o me quedo corto?». Si predigo 8.200 y la parcela da 8.000, me he equivocado en 200 kilos por hectárea. Esa diferencia, en las unidades del negocio, es la que de verdad importa, y es la que un agricultor entiende. Un error de 200 kilos de tomate significa algo; un «acierto del 94%» no significa nada hasta que alguien te explica el 94% de qué.

## Por qué predecir la cosecha vale dinero

Para entender por qué este encargo importa, hazte una idea del negocio del agricultor. Una parcela de hortícola intensivo —tomate, pimiento, lechuga— puede dar del orden de varios miles de kilos por hectárea en una campaña, y lo que cuesta producir esa cosecha depende en buena parte de dos cosas que el agricultor decide: cuánta agua echa y cuánto abono pone. El agua, en el sureste, no es gratis ni ilimitada: se paga, está regulada por confederaciones hidrográficas y en los años secos se raciona. Así que cada decisión de riego es, a la vez, una decisión de coste y una apuesta sobre la cosecha.

Si AgroSense pudiera decirle a una cooperativa «esta parcela, regando y abonando así, va a dar unos 9.000 kilos», pasarían dos cosas. La primera, que el agricultor podría planificar: cuánto va a vender, qué contratos firmar, cuánto personal necesita para la recogida. La segunda, más potente, es que si además se le puede decir «estás regando de más y por eso cosechas menos de lo que podrías», se le ahorra agua y se le sube la cosecha a la vez. Eso no es un informe bonito: es dinero en el bolsillo del agricultor y un argumento de venta imbatible para el comercial de AgroSense. El problema es que ese modelo no existe todavía. Lo vas a construir tú.

## El equipo: quién te pide qué

En un equipo pequeño, saber a quién acudir para cada cosa ahorra horas. Estos son los cuatro nombres que vas a oír toda la semana, y no todos quieren lo mismo de ti.

• ▹Elena Satorres — Data Lead, tu mentora. Ingeniera agrónoma que se pasó a los datos, con diez años de campo antes de montar el equipo. Enseña con preguntas en vez de dar respuestas, y es obsesiva con una cosa: que entiendas qué estás prediciendo y en qué unidades. Su frase: «Un error de 0,3 no significa nada hasta que me digas 0,3 de qué. Si no sabes leer tu error, no sabes si tu modelo sirve.» Desconfía por naturaleza de las relaciones del tipo «cuanto más, mejor».
• ▹Nuria Belmonte — Responsable Agronómica, tu stakeholder. Doce años a pie de parcela asesorando a cooperativas; sabe de cultivo más que nadie en la empresa. Ya tiene su conclusión antes de ver un solo dato: «más agua, más cosecha, eso lo sabe cualquiera que haya pisado una huerta; dame el modelo que me lo confirme». No es cerrada, es que cada semana sin modelo es una venta que no se cierra. Te pasa los datos y mete prisa.
• ▹Dídac Ferrer — Ingeniero de Datos / IoT, tu compañero. Conoce cada cacharro del campo y, sobre todo, todas las marranadas que mandan los sensores: lecturas fuera de rango, unidades que cambian según el lote de nodos, nulos cuando un sensor se queda sin batería. Es tu apoyo del día a día, aunque a veces te suelta un atajo sin explicarte por qué funciona. Repite una frasecita a la que nadie hace mucho caso: «ojo con dar por hecho que más de algo es siempre mejor, que el campo tiene techos y a veces hasta se da la vuelta».
• ▹Mariano Ortega — Director Comercial, la audiencia de la demo del viernes. Veinticinco años vendiendo a cooperativas. No quiere ver tu código ni tus gráficas de residuos: quiere saber si puede prometerle a una cooperativa una predicción de cosecha y por cuánto se equivoca. Si le enseñas algo que no se entiende en cinco segundos, desconecta. Prefiere una cifra honesta incómoda a una bonita que luego le explote en una reunión con un cliente.

Hay una tensión sana entre Elena y Nuria que vas a vivir toda la semana, y conviene entenderla en vez de sufrirla. Nuria quiere el modelo ya y da por hecho que más agua es más cosecha; Elena quiere que el modelo diga la verdad aunque incomode, y frena las conclusiones de Nuria «hasta ver qué forma tienen los datos». Las dos tienen parte de razón, y tú estás en medio. La lección que te llevas no es «hazle caso a una», es que confirmarle a alguien lo que ya cree, sin haberlo comprobado, es la forma más fácil de hacer un trabajo inútil.

## Dónde vive cada dato: el stack de AgroSense

Antes de tocar nada, conviene saber de dónde salen los datos que vas a usar y por qué tú trabajas en Python y no en la herramienta que ve el resto de la empresa. AgroSense usa una herramienta llamada Metabase para los paneles que ven las cooperativas: cuántos milímetros ha llovido, cómo va la humedad esta semana. Eso describe lo que ya pasó, y para eso está muy bien. Pero para predecir el rendimiento de una parcela hace falta entrenar un modelo, y eso vive en Python —con pandas para preparar los datos y una librería llamada scikit-learn para el modelo—, con algo de SQL para cruzar y agregar los extractos. Esta semana te quedas en esa fase: nadie espera que toques Metabase.

Los datos nacen en tres sitios distintos y por eso llegan descoordinados. Los sensores de campo mandan sus lecturas por una red de nodos; la ficha de cada parcela (qué cultivo tiene, cuánta superficie, cuánto se regó y se abonó) vive en una base de datos de la plataforma; y el índice de vegetación lo manda un proveedor externo de satélite, con su propio formato y su propio desorden. Nadie ha unificado nunca esas tres fuentes, así que una de tus primeras tareas será cruzarlas y dejarlas coherentes. Antes de eso, mira el viaje entero de un vistazo.

## La semana que tienes por delante

Tu semana sigue el ritmo de un proyecto real. El lunes montas el proyecto y exploras los datos sin tocarlos. El martes los limpias y construyes la tabla de modelado: una fila por parcela, con el número que quieres predecir al lado. El miércoles entrenas tu primer modelo y te llevas una alegría. El jueves esa alegría se complica —y es el día que de verdad te hace científico de datos—. Y el viernes conviertes todo eso en algo que Mariano pueda entender en cinco segundos y en una recomendación que a Nuria le cambie la cabeza. Fíjate en una cosa: el día que de verdad tocas scikit-learn con ganas es solo el miércoles. El resto es entender, limpiar, dudar y contar, y esa proporción no es un capricho: es cómo se reparte el tiempo en el trabajo real.

## Dos entregables: el informe y el repositorio

Antes de cerrar el primer día, Elena te deja una cosa clara que cambia cómo trabajas toda la semana. El viernes no entregas solo una conclusión para Mariano. Entregas dos cosas. La primera es el mensaje para negocio: la verdad sobre si se puede predecir la cosecha y por cuánto, en el idioma de quien vende. La segunda es un repositorio de proyecto ordenado, el mismo que usarías si esto fuera a producción. «Cuando acabes», te dice Elena, «no tendrás un montón de trozos de código sueltos: tendrás un proyecto que puedes abrir, entender y, si quieres, subir a tu GitHub como pieza de portfolio». Un repositorio es, sin misterio, la carpeta de un proyecto con sus ficheros organizados de una forma que cualquiera reconoce: dónde están los datos, dónde el código, dónde lo que el código produce.

Esto tiene una consecuencia que notarás cada día aunque al principio no te des cuenta. Cada ejercicio de código que resuelvas no es un trozo aislado: es un fragmento de un fichero concreto del proyecto. Los ejercicios de explorar van llenando un fichero; los de limpieza, otro; los del modelo, otro. Tú los resuelves de uno en uno, centrado en el problema de ese momento, pero por debajo estás escribiendo un programa completo y ordenado. El viernes, al mirar atrás, descubrirás que lo que parecían ejercicios sueltos era, todo el tiempo, un proyecto montándose pieza a pieza. Este es el esqueleto que ya te han dejado preparado; no hace falta memorizarlo, es el mapa de lo que tendrás el viernes.

Lo único que importa que te lleves hoy es la idea de fondo, que ordena toda la semana: no estás haciendo ejercicios, estás construyendo un proyecto. Y un proyecto honesto, que se entiende y se puede enseñar, vale mucho más que un número bonito que no sabes defender. Ya sabes cuál es tu encargo y por qué importa. Mañana empiezas a mirar los datos de verdad.