Capítulo cuarto: Métodos de inteligencia artificial en el contexto agrícola

Segunda parte — Fundamentos de la inteligencia artificial y los datos

La pregunta de esta parte: ¿qué ocurre dentro de un sistema de inteligencia artificial desde el momento en que recibe los datos hasta que su respuesta o recomendación llega al agricultor?

Cuando un sistema inteligente propone un momento para regar, identifica una enfermedad que afecta a la hoja de una planta o predice la producción, la respuesta puede parecer que ha aparecido de golpe en la pantalla. Sin embargo, esa respuesta es la última parada de un largo trayecto que el usuario no ve: comienza con datos recogidos del campo, de satélites o de registros pasados, y después atraviesa la medición, la depuración, la clasificación y el análisis antes de convertirse en una predicción, una recomendación o una advertencia. En el debate público, la inteligencia artificial se presenta a veces como si fuera una mente única capaz de comprender y de decidir en cualquier situación. En realidad, no es una herramienta, sino varias familias de métodos y modelos, cada una diseñada para tareas concretas. La herramienta que analiza la imagen de una hoja no es la misma que la que predice el rendimiento de un cultivo; y un sistema que extrae información de miles de documentos no funciona del mismo modo que uno que determina cuándo regar. Cada método tiene fortalezas, supuestos de los que depende, datos que exige y errores potenciales que hay que comprender antes de confiar en sus resultados. Esta parte no pretende convertir al lector en especialista en inteligencia artificial, ni abrumarle con detalles matemáticos y de programación. Su propósito es más profundo y más práctico: dar al lector una comprensión que lo proteja de deslumbrarse ante un resultado antes de saber cómo se produjo, y que le ayude a distinguir entre un sistema construido sobre datos adecuados y evidencia clara y otro que ofrece respuestas seguras sin el respaldo de conocimiento suficiente. Con ese fin intentaremos mirar dentro del sistema, en un lenguaje que combine precisión y sencillez. Nos preguntaremos: ¿de qué datos aprendió? ¿De dónde procedían esos datos, quién los recogió y en qué tierra, clima y campaña? ¿Representan las condiciones de la explotación donde se utilizará el sistema, o un entorno distinto? ¿Qué puede ver el modelo y qué queda fuera de su alcance? ¿Cómo sabe que su respuesta es correcta? ¿Y cómo podría errar, dudar o expresar más confianza de la que la evidencia permite? No se trata de cuestiones técnicas alejadas de la realidad agrícola. Si los datos meteorológicos están incompletos, una imagen de satélite queda oculta por las nubes, un sensor está descalibrado o el modelo se entrenó con otro cultivo u otro clima, el defecto puede pasar de una etapa a la siguiente hasta llegar al agricultor en forma de una recomendación en apariencia precisa. Esto no significa que la inteligencia artificial sea inútil; significa que su valor verdadero no proviene únicamente de su inteligencia computacional, sino de la calidad de toda la cadena que produjo su respuesta. Comenzamos con los métodos de inteligencia artificial y la lógica de elegir cada uno de ellos: ¿por qué una herramienta se ajusta a un problema y otra no? Pasamos después a los datos, porque son la materia de la que aprende el sistema y el espejo a través del cual ve el mundo. A continuación examinamos la procedencia y la calidad de los datos, para saber dónde se originó la información, qué camino recorrió y qué cambios se le introdujeron. Llegamos después a la teledetección, donde las imágenes de satélites y drones, junto con los dispositivos de campo, se convierten en indicadores de las plantas, del suelo y del agua. De ahí pasamos a los sistemas de apoyo a la toma de decisiones y a la recuperación de conocimiento, para ver cómo se reúnen mediciones, modelos y experiencia agronómica en una respuesta utilizable en el momento y el lugar adecuados. Este orden no es arbitrario; refleja el camino que recorre el conocimiento dentro del sistema. Un método inadecuado puede corromper la inferencia, unos datos débiles pueden socavar los mejores modelos, una fuente desconocida dificulta la verificación del resultado y una medición inexacta produce una recomendación inexacta. Una respuesta que no aclara su fundamento ni sus límites puede pasar de ser una herramienta de ayuda a convertirse en una nueva fuente de riesgo. Comprender estos fundamentos no significa que el agricultor deba conocer cada ecuación o cada línea de código, del mismo modo que el conductor de un tractor no necesita ser ingeniero mecánico. Pero el agricultor necesita saber lo suficiente para distinguir el funcionamiento correcto de la avería, la capacidad real de una promesa comercial, y una herramienta que ayuda a decidir de otra que le pide entregarle la decisión por completo. En esta parte no concebimos la inteligencia artificial como una caja misteriosa que emite respuestas, sino como una cadena interconectada de datos, supuestos, mediciones, modelos y decisiones humanas. Cada eslabón de esa cadena afecta al siguiente. La pregunta más importante, por tanto, no es solo: ¿qué dijo el sistema? Es también: ¿cómo llegó a lo que dijo, sobre qué evidencia y dentro de qué límites puede confiarse en él? La exposición se mantiene concreta, sin reducir su profundidad científica ni convertir la introducción en una pesada explicación técnica.

Capítulo cuarto: Métodos de inteligencia artificial en el contexto agrícola

Mensaje del capítulo

No existe un método único llamado «IA agrícola» que sirva para todo cultivo, toda explotación y toda decisión. Lo que llamamos inteligencia artificial es un amplio abanico de métodos: unos aprenden de ejemplos pasados, otros buscan patrones inusuales, otros interpretan imágenes, otros siguen el cambio a lo largo del tiempo, otros comparan alternativas bajo restricciones y otros recuperan conocimiento y lo formulan en una respuesta. El valor de un método no comienza por la fama de su nombre o la novedad de su modelo, sino por su ajuste a la pregunta agrícola que queremos responder. Un error del sistema puede no ser más que una imagen que hay que repetir; o puede ser una decisión retrasada que pierde una ventana de tratamiento, o una operación automatizada que pone en riesgo un cultivo o a un trabajador. La selección empieza, por tanto, por la decisión y por la consecuencia del error, y solo después regresa a los datos y al método, no al revés. Este capítulo no pide al agricultor que se convierta en programador, ni se conforma con presentar al lector informado nombres ya conocidos. Su objetivo es tender un puente entre lo que ocurre dentro del modelo y lo que ocurre después en el campo: ¿qué ve el sistema? ¿Qué aprende? ¿Qué produce? ¿Dónde puede equivocarse? ¿Y cuándo el resultado es información de apoyo y cuándo se convierte en una acción que exige supervisión y responsabilidad? Antes de los nombres de los algoritmos: el recorrido de la pregunta por el sistema Imaginemos a un agricultor que encuentra manchas en las hojas de tomate, toma una foto y pregunta a una aplicación: «¿Cuál es el problema?». La tarea parece sencilla, pero el sistema no ve la hoja como la ve una persona, ni conoce por sí mismo el historial de la parcela, la variedad, la humedad ni el grado de propagación de los síntomas. Recibe una representación digital de la imagen, la compara con patrones que ha aprendido y después produce una clase, una probabilidad o un conjunto de probabilidades. Después de eso, otra aplicación puede convertir el resultado en una recomendación. Entre la imagen y la recomendación se extiende toda una cadena de elecciones. Cualquier sistema agrícola inteligente puede entenderse a través de seis etapas:

1. La pregunta: ¿qué problema o decisión queremos apoyar?
2. Las entradas: ¿qué datos puede ver realmente el sistema?
3. La representación: ¿cómo se ha convertido la realidad agrícola en una imagen, un número, un texto o una serie temporal?
4. El método: ¿qué familia computacional enlaza las entradas con la salida?
5. La salida: ¿es el resultado una clasificación, una estimación, una probabilidad, una ordenación o una recomendación?
6. La acción: ¿quién utilizará el resultado y qué ocurre si es erróneo o llega tarde?

Separar estos eslabones importa. Un modelo puede ser bueno clasificando una imagen, mientras que la imagen misma no es representativa del campo. Una predicción puede ser razonable, pero convertirla en una dosis o en un momento de aplicación exige reglas agronómicas y restricciones de seguridad que el modelo no ha aprendido. En los sistemas maduros, estas distinciones no desaparecen tras la palabra «inteligente»; se le muestran al usuario, para que sepa dónde está justificada la confianza y dónde hace falta verificación.

1. De la pregunta a la representación

La pregunta agrícola tal como la formula una persona suele ser más amplia que la pregunta que un modelo puede tratar. Preguntar «¿está bien esta planta?» reúne en una sola frase la posibilidad de enfermedad, de carencia de nutrientes, de estrés hídrico, de daño mecánico y de efectos meteorológicos. Un modelo, en cambio, necesita una tarea concreta cuyas entradas puedan representarse, cuya salida pueda definirse y cuyo error pueda medirse. Tomemos el ejemplo de una hoja afectada. Puede convertirse en problemas distintos:

No se trata de varios nombres para la misma tarea. Cada pregunta exige datos adecuados a ella, respuestas correctas de las que el sistema pueda aprender, una forma de medir sus errores y un paso claro que siga una vez aparece el resultado. La clasificación puede bastar para una priorización inicial, pero no es suficiente para guiar una herramienta robótica hacia una posición precisa. Y un mapa de daños puede ser visualmente excelente, pero no demuestra la causa del daño. Lo mismo ocurre con las malas hierbas. Si lo único que se requiere es saber si hay una mala hierba, basta una tarea de clasificación. Si lo que se requiere es calcular la densidad de malas hierbas, necesitamos recuento o estimación de superficie. Si lo que se requiere es guiar una herramienta mecánica, necesitamos una localización precisa, un tiempo de respuesta, un sistema de control y una barrera de seguridad. El paso de «vio la mala hierba» a «se desplazó hacia ella» es un paso de la información a la acción, no un detalle menor de programación. Por eso la unidad de decisión precede a la selección del modelo. ¿La decisión concierne a una sola hoja, a una planta, a una línea de cultivo, a un sector o a una parcela entera? ¿Y estamos prediciendo el rendimiento de una parcela antes de la cosecha, o la producción total de una región para planificar el almacenamiento y el transporte? Si cambia la unidad, cambia con ella el significado de los datos y del error. Una buena estimación a escala regional puede no ser adecuada para decidir el riego en un sector pequeño, aunque ambas empleen la palabra «rendimiento» o «producción». En cuanto a la representación, es la imagen digital simplificada de la realidad que el sistema permite. Puede representar el suelo mediante una medición de humedad a una única profundidad, o representar la planta mediante una imagen cenital, o representar el manejo de la parcela mediante un registro de fechas. Toda representación ilumina un aspecto y deja otros aspectos fuera de la vista. Un modelo no sabe lo que no se le ha suministrado, y no puede corregir una definición vaga del objetivo por el mero hecho de aumentar su potencia de cálculo. Una pregunta práctica: antes de preguntar por el nombre del algoritmo, pregunte: ¿cuál es la unidad de decisión? ¿Qué ve el sistema? ¿Qué no ve? ¿Y qué acción se construirá sobre su salida?

2. Aprendizaje supervisado: aprender de ejemplos con resultados conocidos

El aprendizaje supervisado es un enfoque en el que el sistema aprende de ejemplos con resultados conocidos. Si queremos entrenarlo para distinguir entre hojas sanas y hojas afectadas, le mostramos imágenes que un especialista ya ha revisado y a las que ha asignado un estado. Si queremos entrenarlo para predecir el rendimiento, le proporcionamos datos de meteorología, suelo, variedad y manejo de la parcela y, con cada registro, la cantidad de rendimiento realmente medida tras la cosecha. A partir de un gran número de ejemplos de este tipo, el sistema intenta aprender la relación entre los datos y los resultados conocidos, y después utiliza lo aprendido para estimar el resultado de un caso nuevo que no ha visto antes. El resultado conocido se denomina clase de referencia verificada por un experto cuando es el nombre de una clase, como «sana» o «afectada», y valor de referencia cuando es un número medido, como la cantidad de rendimiento. Un modelo no suele partir de una lista de reglas escritas por un experto, del tipo: «Si aparece una mancha de este color, entonces el estado es tal». En su lugar, el desarrollador le presenta un gran número de ejemplos con resultados conocidos, y él busca por su cuenta las características que se repiten con cada resultado. Cuando ve un ejemplo nuevo, lo compara con los patrones que ha aprendido y después estima el resultado más próximo. Esta capacidad es útil, pero entraña un riesgo importante: el sistema puede aprender una pista lateral fácil en lugar de aprender la característica agronómica que nos importa. No sabe por sí mismo qué parte de la imagen representa la enfermedad y qué parte es mero fondo; más bien aprende de la manera en que los ejemplos fueron recogidos y presentados. Imaginemos que queremos entrenar un sistema para distinguir entre una planta sana y una afectada. Todas las plantas sanas se fotografiaron dentro de un invernadero con una pared blanca, mientras que todas las plantas afectadas se fotografiaron en campo abierto con suelo oscuro visible al fondo. Lo que queremos es que el sistema aprenda la forma de los síntomas en las hojas, pero puede descubrir una vía más fácil: el fondo blanco acompaña a las imágenes sanas, y el suelo oscuro acompaña a las afectadas. El sistema puede parecer exitoso al probarse con imágenes recogidas del mismo modo, porque los fondos de la prueba se parecen a los fondos de los que aprendió. Pero puede fallar en una explotación nueva: por ejemplo, clasificando como sana una planta afectada dentro de un invernadero blanco, o señalando una planta sana porque detrás hay suelo oscuro. El sistema no se propuso engañar; aprendió la asociación más fácil que le ofrecían los datos, en lugar de los signos de enfermedad que el diseñador pretendía. El mismo problema surge en los datos numéricos. Si un sensor de cosecha da lecturas por encima o por debajo de la realidad porque está descalibrado, el modelo aprenderá de números incorrectos. Si la producción de algunas parcelas se registra en toneladas por hectárea, mientras que la de otras se registra como toneladas totales sin aclarar la diferencia, el sistema tratará valores no comparables como si fueran una misma cosa. Y si se emplea un único nombre para estados patológicos distintos, el modelo no conocerá los límites correctos entre ellos. En cada uno de estos ejemplos, el error no se queda fuera del modelo; entra en la materia misma de la que el modelo aprende. El algoritmo puede desempeñar su tarea computacional con exactitud y, aun así, aprender una relación construida sobre una medición defectuosa o una definición inestable. Un método avanzado no puede extraer de los datos una certeza que no estaba allí desde el principio. Así pues, no basta con encontrar una respuesta escrita junto a cada imagen o registro. Necesitamos saber:

• ¿Quién determinó el estado de referencia o el valor de referencia, y qué reglas siguió?
• ¿Fue el resultado confirmado por un único especialista, revisado por más de un especialista o establecido mediante una prueba de referencia?
• ¿Se registró el nivel de confianza, y se permitió un resultado «no concluyente» cuando la evidencia era insuficiente?
• ¿Se mantuvo coherente la definición de cada estado entre explotaciones, instituciones y campañas?
• ¿Incluyen los ejemplos casos fáciles y difíciles, síntomas tempranos y avanzados, y casos mixtos?
• ¿Representan las imágenes y los registros la diversidad de variedades, ubicaciones, dispositivos e iluminación?
• ¿Se separaron entre entrenamiento y prueba las imágenes o registros muy parecidos, de modo que el sistema no fuera evaluado con versiones muy similares a lo que ya había visto?

Permitir que el sistema diga «no hay información suficiente para emitir un juicio» no es una señal de debilidad. En las aplicaciones agrícolas, una abstención disciplinada puede ser más segura que obligar al sistema a elegir un nombre de enfermedad para cada imagen. Un resultado responsable no se limita a indicar la posibilidad más probable; también deja claros los límites de la confianza, la información que falta y el siguiente paso necesario para la verificación. Para el lector avanzado: un gran número de ejemplos no compensa una diversidad estrecha ni unos resultados de referencia débiles. Un pequeño conjunto independiente que represente distintas explotaciones, campañas y dispositivos puede revelar mejor los límites del modelo que miles de imágenes similares. Por tanto, la diversidad de entornos, la coherencia de la definición del resultado, la independencia de los datos de prueba y el coste de cada tipo de error deben evaluarse junto al tamaño del conjunto de datos.

3. Aprendizaje no supervisado y semisupervisado: ¿qué hacemos cuando escasean los resultados documentados?

En el caso ideal, podríamos desear que un especialista revisara cada imagen, lectura o registro y determinara el resultado correcto asociado a ellos. Pero esto rara vez es posible en la realidad. Una explotación puede recoger miles de imágenes y millones de lecturas de sensores, mientras que no se dispone del tiempo, del dinero o de la capacidad experta necesarios para revisar cada registro de forma individual. Cuando los resultados documentados son escasos o no están disponibles, pueden emplearse métodos que ayudan a organizar los datos y a descubrir patrones recurrentes en ellos, sin partir de una respuesta correcta asociada a cada ejemplo. Entre los más importantes de estos métodos figuran el aprendizaje no supervisado, la detección de anomalías y el aprendizaje semisupervisado. Estos métodos se parecen en que aprovechan datos no revisados, pero no desempeñan la misma función ni confieren el mismo grado de certeza a sus resultados. Primero: el aprendizaje no supervisado En el aprendizaje no supervisado, al sistema no se le entrega una lista previa que le diga: «Esta zona es buena», «esta es débil» y «esta tiene un problema de drenaje». Más bien busca dentro de los datos registros que se parezcan entre sí en sus características y después agrupa los similares. Supongamos que disponemos de lecturas de distintas zonas de la parcela, entre ellas la humedad del suelo, la productividad, la temperatura y las características de reflectancia captadas por imágenes aéreas. El sistema puede encontrar que algunas zonas se parecen entre sí en esas lecturas y situarlas en un mismo grupo, mientras sitúa otras zonas en grupos distintos. Este resultado puede ayudar al agricultor a ver una diferencia que antes no era clara, pero no explica automáticamente su causa. Las zonas que comparten un rendimiento bajo pueden ser matemáticamente similares, pero la razón del descenso puede diferir de un lugar a otro:

• Una zona puede sufrir un drenaje deficiente.
• Otra puede estar afectada por la sombra.
• Una tercera puede diferir en el tipo de suelo.
• Y la lectura de una cuarta zona puede ser baja por un sensor descalibrado.

Así pues, en esta fase el sistema dice: «Estos registros son similares según los datos que he analizado». No dice: «He demostrado que esta zona es pobre o que necesita una cantidad concreta de fertilizante». Esta diferencia es fundamental. La agrupación computacional ayuda a dirigir la atención, la inspección y el muestreo, pero no sustituye a la interpretación agronómica. Tampoco los grupos hallados por el sistema existen con independencia de las decisiones del diseñador. El resultado se ve afectado por las variables introducidas en el análisis, por la manera en que se normalizan sus unidades, por el número de grupos que se van a formar y por el grado de similitud que el algoritmo considera importante. Si omitimos los datos de drenaje, por ejemplo, el sistema no podrá usar el drenaje para explicar la diferencia, por avanzado que sea el método de análisis. Segundo: la detección de casos inusuales Un uso importante de estos métodos es la detección de casos inusuales. El sistema aprende el patrón habitual de lecturas o de comportamiento a lo largo de un periodo determinado y después alerta al usuario cuando aparece un caso que difiere de él en grado sustancial. La diferencia puede ser:

• Un sensor de humedad cuyas lecturas han empezado a desviarse de forma gradual.
• Un aumento repentino del consumo de agua que puede indicar una fuga o un cambio en la operación.
• Un descenso inusual del caudal de una línea de riego.
• Un cambio apreciable en el movimiento de un animal o en su pauta de ingesta de alimento.
• Una lectura de temperatura que permaneció constante durante un tiempo inusualmente largo, lo que puede indicar un fallo del sensor.

Pero la alerta por sí sola no demuestra que se haya producido un fallo o una enfermedad. Significa únicamente: «Este caso difiere de lo que el sistema consideraba habitual y, por tanto, merece examen». La causa puede ser un problema real, un cambio estacional natural, una nueva operación agrícola o un error de medición. Por consiguiente, una señal de diferencia no debe convertirse directamente en un diagnóstico ni en una instrucción operativa. Tampoco un número elevado de alertas es prueba de la calidad del sistema. Si el sistema envía, por ejemplo, cien alertas al día a un equipo que no puede examinar más de cinco, la herramienta se convertirá en una fuente de ruido y podrán perderse avisos importantes entre alertas repetidas. Por ello, el sistema debería calibrarse según tres factores:

• La gravedad de la condición que podría no llegar a detectar.
• El número de falsas alarmas que el equipo puede gestionar.
• La capacidad del trabajador o del especialista de examinar la alerta a tiempo.

Cada alerta debería indicar por qué se emitió, por ejemplo: «El uso de agua en este sector ha subido por encima de su rango habitual en las últimas seis horas, mientras que no ha aparecido ningún cambio similar en los sectores vecinos». Esto es más claro y más útil que un mensaje genérico que diga: «Se detectó una anomalía». Tercero: Aprendizaje semisupervisado El aprendizaje semisupervisado se utiliza cuando disponemos de un número limitado de ejemplos que un especialista ha revisado y a los que ha asignado el resultado correcto, junto a un número mayor de imágenes o registros que nadie ha revisado todavía. Supongamos que una explotación tiene miles de imágenes de hojas de plantas, pero un patólogo vegetal solo ha podido revisar unos pocos cientos de ellas. Este conjunto menor contiene casos conocidos, como:

• Una hoja sana.
• Síntomas de una enfermedad concreta.
• Síntomas de una carencia de nutrientes.
• Una imagen insuficiente para emitir un juicio.

Las imágenes restantes están disponibles, pero su estado no se ha documentado. El sistema aprende primero de los ejemplos revisados por el especialista y después aprovecha las semejanzas y diferencias halladas en las demás imágenes. De este modo puede utilizarse una gran cantidad de datos sin exigir que el experto revise manualmente cada imagen. Pero reducir el trabajo manual no significa prescindir de la verificación humana, ni significa que un número elevado de imágenes no revisadas pueda arreglar un conjunto documentado débil o estrecho. Si todas las imágenes revisadas por el especialista procedían de:

• Una sola explotación.
• Un solo cultivar.
• Un solo teléfono.
• Condiciones de iluminación similares.
• Un estadio avanzado de la enfermedad.

entonces el sistema puede aprender que esas condiciones limitadas representan todos los casos. Puede funcionar bien con imágenes similares y luego rendir mal cuando se encuentre con síntomas tempranos, con otro cultivar, con otra explotación o con una cámara de menor calidad. Un sistema que aprendió qué aspecto tiene la enfermedad en un estadio avanzado puede no reconocer su inicio temprano. Un sistema entrenado con un solo cultivar puede confundir las características naturales de otro cultivar con síntomas de enfermedad. Y miles de imágenes que ningún especialista ha revisado no pueden compensar automáticamente la estrechez de los ejemplos documentados a partir de los cuales el sistema aprendió qué significan los casos. Deberíamos preguntar, por tanto:

• ¿Representan los ejemplos documentados distintas explotaciones, cultivares y estadios?
• ¿Quién determinó el estado de cada ejemplo y cómo se verificó?
• ¿Existen casos indeterminados, en lugar de forzar cada ejemplo hacia un resultado definido?
• ¿Revisó el especialista una muestra de los resultados propuestos después por el sistema?
• ¿Apareció la debilidad en una categoría, una ubicación o un estadio de desarrollo concretos?
• ¿Mejoró realmente el resultado, o simplemente el sistema se volvió más confiado?

Cuarto: Aprender características generales antes de definir la tarea Existen también métodos que aprenden primero características generales recurrentes a partir de una gran cantidad de imágenes o señales, antes de que el sistema se entrene en una tarea agrícola concreta. El sistema puede aprender a distinguir formas, bordes, texturas y matices de color sin que cada imagen esté vinculada al nombre de una enfermedad o de una condición agrícola. Después, se utiliza un conjunto menor revisado por un especialista para enseñar al sistema la tarea requerida, como distinguir entre hojas sanas y hojas que presentan síntomas concretos. Este paso puede reducir la cantidad de trabajo necesaria, pero no significa que el sistema haya comprendido la enfermedad o el cultivo por sí mismo. Aprendió características visuales o numéricas generales y después se orientó hacia una tarea agrícola específica. La calidad del resultado sigue ligada a la solidez de los ejemplos documentados y a las pruebas en condiciones de campo independientes. Ejemplo práctico: Dividir la parcela en tres zonas Supongamos que el sistema analizó datos de humedad, datos de rendimiento e imágenes aéreas, y después dividió la parcela en tres zonas con características diferentes. Este resultado no significa directamente que la parcela necesite tres prescripciones de fertilización. El siguiente paso correcto consiste en usar el mapa para guiar la inspección:

1. El equipo confirma primero la integridad de los sensores y de los datos.
2. El equipo visita puntos representativos de cada zona.
3. Examina el suelo, el drenaje, la sombra y el historial de manejo.
4. Toma las muestras adecuadas cuando es necesario.
5. Compara la interpretación computacional con la observación y la medición de campo.
6. Determina después si las zonas requieren realmente tratamientos distintos.

El examen puede concluir que una zona difiere por el suelo, que la segunda tiene un problema de drenaje y que la tercera pareció distinta por un error de sensor. Si los tres grupos se convirtieran entonces directamente en tres prescripciones de fertilización, se habrían tratado causas diferentes como si fueran un único problema. Así pues, en este caso el algoritmo proporciona un mapa de las preguntas que merecen examen, no una prescripción ya hecha para responderlas. Conclusión Cuando los resultados documentados son escasos, estos métodos pueden aprovechar datos abundantes de distintas maneras:

• El aprendizaje no supervisado agrupa casos similares, pero no establece por qué son similares.
• La detección de anomalías nos alerta de lo que se ha apartado del patrón, pero no proporciona un diagnóstico final.
• El aprendizaje semisupervisado combina ejemplos revisados por un especialista con más datos que no han sido revisados, pero puede transferir las carencias de los ejemplos limitados al resto del sistema.
• El aprendizaje de características generales reduce la necesidad de revisar cada imagen desde el principio, pero no elimina las pruebas de campo ni el juicio experto.

Y el principio unificador es: Los datos abundantes ayudan al sistema a ver patrones, pero el significado agrícola no procede de la cantidad por sí sola; procede más bien de una medición sólida, de ejemplos documentados, del contexto de campo y de la verificación humana.

4. Visión por computador: ¿Qué ve el sistema en la imagen?

Cuando un agricultor o un especialista mira la hoja de una planta, no ve solo color y forma. Más bien relaciona lo que ve con la edad de la planta, la propagación de los síntomas, el estado de la parcela, la meteorología, el riego y su experiencia con casos anteriores. Un sistema de visión por computador, en cambio, parte de algo más estrecho: una imagen o un videoclip convertidos en datos digitales que un ordenador puede analizar. La visión por computador es un conjunto de métodos que ayudan al sistema a encontrar patrones dentro de imágenes y vídeo. Puede emplear modelos llamados redes neuronales convolucionales, o modelos de visión más recientes, para reconocer formas, colores, texturas y relaciones espaciales. Entre sus aplicaciones agrícolas figuran la inspección de enfermedades de los cultivos, la identificación de malas hierbas y frutos, la estimación de la madurez, la clasificación de productos y el seguimiento del movimiento y el comportamiento de los animales. Las revisiones científicas repasan la amplitud de estas aplicaciones en ingeniería agrícola y alimentaria [SRC001][SRC002]. Pero decir que el sistema «comprende la imagen» puede sugerir que la ve y la interpreta como lo hace una persona. En realidad, la misma imagen puede utilizarse para responder a preguntas distintas, y cada pregunta tiene su propio método, resultado y límites. 1\. Determinar el estado general de la imagen: clasificación En esta tarea, el sistema mira la imagen como una unidad única y selecciona después el estado más próximo dentro de un conjunto de estados que ha aprendido previamente. El resultado podría ser, por ejemplo:

• La hoja parece sana.
• Hay indicios que sugieren una infección.
• El fruto parece encuadrarse en una determinada categoría de calidad.
• La imagen no es suficiente para arrojar un resultado fiable.

Este tipo de análisis resulta útil para una clasificación inicial. Pero no muestra necesariamente dónde está el indicio dentro de la imagen, no establece su causa y no convierte una probabilidad en un diagnóstico final. Así, si el sistema dice que la imagen es «sospechosa», eso significa que el patrón general se asemeja a ejemplos de los que ha aprendido. Eso por sí solo no significa que la enfermedad se haya confirmado, ni que el tratamiento se conozca ya. 2\. Determinar la ubicación del objeto o del indicio: detección A veces no basta con saber que la imagen contiene un fruto, una mala hierba o una mancha sospechosa; también necesitamos saber dónde está. En este caso, el sistema dibuja un círculo o un recuadro visible alrededor de la parte que ha detectado. Al examinar la hoja de una planta, por ejemplo, puede aparecer un recuadro alrededor de una mancha concreta. Al analizar la imagen de una parcela, el sistema puede colocar un recuadro alrededor de cada fruto o mala hierba que haya podido encontrar. Este resultado ayuda a responder a la pregunta: ¿Dónde está aquello que el sistema detectó? También ayuda al usuario a verificar que el sistema se centró en la parte correcta. El sistema puede creer que ha detectado un síntoma de enfermedad cuando en realidad se ha centrado en una sombra, en una zona de suelo o en parte del fondo de la imagen. Pero identificar la ubicación de la mancha no establece la causa de su aparición. El sistema puede identificar correctamente la ubicación del daño, mientras que determinar la enfermedad o el estrés que lo causó sigue requiriendo otra información. 3\. Dibujar los límites de la zona afectada: segmentación Puede que necesitemos saber más que la ubicación del objeto; puede que queramos saber con precisión cuánta superficie ocupa. En esta tarea, el sistema colorea la zona que cree dañada, o dibuja sus límites sobre la imagen. En lugar de colocar un recuadro amplio alrededor de toda la hoja, intenta identificar la parte afectada dentro de ella. Esto puede ayudar a:

• Estimar la proporción de la hoja que está afectada.
• Medir la cantidad de cubierta vegetal en una imagen aérea.
• Separar el fruto del fondo.
• Determinar la superficie cubierta por malas hierbas dentro de una parte de la parcela.
• Comparar los cambios de la zona dañada a lo largo del tiempo.

Los ingenieros emplean la palabra «píxeles» para describir los pequeños puntos que componen una imagen, pero el lector no necesita ese término para comprender el resultado. Lo que importa en la práctica es que el sistema intenta dibujar los límites precisos de la zona que ha detectado. Aun así, determinar la superficie del daño no establece qué enfermedad lo causó. Los límites pueden ser precisos, mientras que la interpretación de la causa es errónea. 4\. Seguir el objeto o la condición a lo largo del tiempo: seguimiento Al analizar un vídeo o una secuencia de imágenes, el sistema puede necesitar determinar si el objeto visible ahora es el mismo que apareció un momento antes o en una imagen previa. Esto puede utilizarse en:

• El seguimiento del movimiento de un animal dentro del corral.
• El seguimiento de un fruto en la línea de clasificación.
• El recuento de objetos sin contar el mismo objeto más de una vez.
• El seguimiento de la propagación de una zona dañada a través de imágenes sucesivas.
• El seguimiento del movimiento de una máquina o de un trabajador dentro de una zona de operación.

Aquí no basta con detectar el objeto en cada imagen por separado; el sistema debe enlazar sus apariciones a través de fotogramas sucesivos. El sistema puede afrontar dificultades cuando el objeto desaparece detrás de otro objeto, cambia la iluminación, los animales se superponen o la cámara se mueve. Por ello, la pérdida del seguimiento no debe convertirse directamente en la conclusión de que el animal, el fruto o la máquina han salido efectivamente de la zona. 5\. Estimar la distancia y la forma: estimación de profundidad Una imagen plana muestra altura y anchura, pero no siempre proporciona directamente la distancia real. Un robot o una máquina de clasificación pueden necesitar saber a qué distancia está el objeto y qué forma tiene en el espacio. El sistema puede utilizar una o varias cámaras, o un sensor adecuado, para estimar:

• La distancia entre la herramienta y el fruto.
• La altura de la planta o el tamaño de un objeto concreto.
• A qué distancia está una persona o un animal de la zona de movimiento.
• La posición de la rama respecto al brazo robótico.
• La forma del objeto que hay que agarrar o evitar.

La estimación de profundidad puede ayudar a la máquina a aproximarse, pero no basta por sí sola para garantizar un movimiento seguro. El sistema necesita además conocer los límites y la velocidad de la herramienta, detenerse cuando aparece un obstáculo y verificar que la medición no ha cambiado por polvo, vibración o mala visibilidad. ¿Por qué hay que definir la tarea con precisión? La elección de la tarea de visión está ligada a la acción requerida una vez que aparece el resultado. Si el objetivo es saber si la imagen contiene fruto, la clasificación de imágenes puede bastar. Pero si el objetivo es contar los frutos, el sistema debe determinar cada fruto individualmente. Y si el objetivo es guiar un brazo robótico para recoger un fruto, debe conocer su posición, su distancia y su forma, y convertir después esa información en un movimiento seguro. Del mismo modo, saber que hay malas hierbas en una imagen no basta para dirigir hacia ellas una herramienta mecánica. El sistema necesita:

1. Identificar cada mala hierba.
2. Distinguirlas del cultivo.
3. Determinar su posición respecto a la máquina.
4. Calcular el movimiento de la herramienta.
5. Verificar que no hay presente ninguna persona, animal u objeto inesperado.
6. Detener la ejecución si la confianza cae o los datos se contradicen.

Cada transición de esta cadena añade una nueva posibilidad de error. Por esa razón, no es válido describir un sistema como seguro por el mero hecho de que el modelo de visión haya rendido bien con imágenes de prueba. ¿Por qué una imagen de campo difiere de una imagen de laboratorio? Las imágenes agrícolas son intrínsecamente variables. La misma hoja puede verse distinta a causa de:

• La luz de la mañana o del mediodía.
• La sombra.
• El ángulo de la cámara.
• El tipo de teléfono o de cámara.
• Que el objetivo esté más cerca o más lejos.
• El polvo o la humedad.
• El fondo.
• El estadio de desarrollo de la planta.
• La superposición de hojas.
• La gravedad de los síntomas y su estadio.

Los síntomas de causas distintas también pueden parecerse entre sí. Algunos indicios de carencia de nutrientes pueden resultar similares a los síntomas de una enfermedad o de estrés hídrico en una sola imagen. Por tanto, el éxito de un sistema en reconocer un patrón visual no significa que haya establecido la causa agrícola. Un modelo entrenado con hojas individuales colocadas sobre un fondo limpio puede parecer robusto en el laboratorio y encontrarse después con una realidad muy distinta cuando vea en el campo hojas superpuestas, sombras cambiantes, polvo, insectos y síntomas en un estadio temprano. Por consiguiente, las imágenes de entrenamiento y de prueba deberían representar las condiciones en las que el sistema va a operar realmente, no las mejores condiciones en las que puede captarse una imagen. Cuando el sistema recuerda la prueba en lugar de demostrar su capacidad Las imágenes utilizadas para entrenar el sistema deben mantenerse separadas de las imágenes utilizadas para probarlo. Pero esa separación puede parecer correcta en los archivos y seguir siendo engañosa en la realidad. Supongamos que captamos diez imágenes muy similares de la misma planta en cuestión de minutos y colocamos después algunas de esas imágenes en los datos de entrenamiento y otras en los datos de prueba. El sistema puede reconocer detalles de la planta, del fondo o del ángulo de la cámara, porque la imagen de prueba es extremadamente similar a lo que ya ha visto. Esto se denomina solapamiento no intencionado entre los datos de entrenamiento y los de prueba, y se conoce técnicamente como «fuga de datos». Es como entrenar a un alumno con un conjunto de problemas y examinarlo después con los mismos problemas tras cambiar su orden o parte de su enunciado. El alumno puede obtener una nota alta, pero el examen no demuestra que sepa resolver un problema nuevo. Por eso, la prueba agrícola es más sólida cuando separa:

• plantas enteras, no solo imágenes.
• parcelas enteras.
• explotaciones distintas.
• campañas independientes.
• dispositivos de captura distintos.
• variedades o estadios de desarrollo que no se incluyeron en el entrenamiento.

Y la pregunta real no es: ¿Tuvo éxito el sistema con imágenes que no había visto antes como archivos? Sino más bien: ¿Tuvo éxito en una explotación, en una campaña o con un dispositivo de cuyos datos no había aprendido antes? ¿Por qué puede resultar engañosa la «exactitud global»? Un único resultado global no basta para juzgar un modelo de visión. Supongamos, en un ejemplo numérico simplificado, que el conjunto de prueba contiene mil imágenes:

• 950 imágenes sanas.
• 50 imágenes afectadas por una enfermedad importante.

Si un modelo débil dice que todas las imágenes están sanas, acertará en 950 de mil imágenes, y su exactitud global puede parecer del 95%. Pero ese modelo no detectó ni un solo caso enfermo y, por tanto, resulta inútil para la tarea para la que fue creado. Por esa razón, debemos preguntar:

• ¿Cuántos casos enfermos fue capaz de detectar?
• ¿Cuántos casos enfermos clasificó como sanos?
• ¿Cuántas falsas alarmas emitió?
• ¿Difiere el rendimiento entre enfermedades o variedades?
• ¿Puede abstenerse cuando la imagen no es clara?
• ¿Qué ocurre cuando se encuentra con un caso que no estaba incluido en los datos de entrenamiento?

Si el error más peligroso es clasificar como sano un caso raro y grave, entonces debe medirse la capacidad del sistema de detectar ese caso concreto, en lugar de conformarse con un promedio inflado por las clases comunes. De ver el objeto a mover la máquina En robótica, la tarea no termina cuando el sistema reconoce un fruto o una mala hierba. El resultado debe pasar por otra cadena: Ver el objeto ← determinar su ubicación ← convertir esa ubicación en coordenadas que la máquina pueda entender ← planificar el movimiento ← ejecutarlo ← verificar el resultado ← detenerse cuando hay peligro Cada parte de esta cadena puede ser una fuente independiente de error. El modelo puede reconocer el fruto correctamente y, aun así, el brazo puede desplazarse a una posición imprecisa por la vibración de la máquina. O la posición puede ser correcta, pero la mano de un trabajador puede aparecer dentro de la zona de movimiento. O la conexión puede interrumpirse después de enviarse la orden y antes de que se confirme su ejecución. Por ello, el sistema debe incluir:

• límites de velocidad y de fuerza.
• una zona de seguridad alrededor de personas y animales.
• un mecanismo de parada local que no dependa de la comunicación.
• la verificación de que la acción tuvo éxito.
• la capacidad de volver a un estado seguro.
• una autoridad clara del trabajador para detener o anular la operación.

Y el principio que debe permanecer claro es: Un modelo puede tener éxito en ver el objeto mientras el sistema fracasa en manejarlo con seguridad. La exactitud en la imagen no es exactitud en la decisión, y la exactitud en la decisión no es seguridad en la ejecución. Preguntas prácticas antes de confiar en un sistema agrícola de visión Un agricultor o un comprador pueden preguntar:

• ¿Cuál es la tarea concreta: clasificación de imágenes, localización, medición de superficie o guiado de máquina?
• ¿Se recogieron las imágenes de prueba en parcelas y campañas independientes?
• ¿Incluyen las imágenes las condiciones de iluminación, los dispositivos y las variedades que hay en mi explotación?
• ¿Qué casos no consigue distinguir el sistema?
• ¿Muestra ejemplos de errores, o solo los mejores casos?
• ¿Puede decir que la imagen es insuficiente?
• ¿Qué ocurre después del resultado: una alerta, una recomendación o una ejecución automatizada?
• ¿Quién revisa el resultado antes de que se lleve a cabo una acción sensible?
• ¿Cómo se detiene la máquina si aparece una persona o cae la confianza?

Conclusión La visión por computador no dota a una máquina de un ojo humano ni de una comprensión agrícola completa. Ayuda al sistema a extraer información concreta de imágenes y vídeo: identificar un estado general, encontrar un objeto, dibujar los límites de una zona, seguir un movimiento o estimar una distancia. El valor de esta información lo determinan tres cosas:

1. ¿Está formulada la pregunta visual de un modo que se ajuste a la decisión requerida?
2. ¿Representan las imágenes condiciones reales de campo?
3. ¿Se ha traducido el resultado en acción a través de un sistema seguro con una responsabilidad clara?

Esto permite al lector distinguir entre un sistema que ofrece una imagen convincente en un experimento breve y otro que se ha probado realmente para operar bajo la luz, el polvo, la diversidad y los límites de seguridad del campo.

5. Modelos probabilísticos e inferencia causal: ¿qué se espera y qué puede cambiar una intervención?

Los sistemas agrícolas afrontan dos tipos distintos de preguntas, y su formulación puede parecer similar aunque responderlas exija evidencia diferente. La primera pregunta es: ¿Qué es probable que ocurra si continúan las condiciones actuales? Por ejemplo, podemos preguntar:

• ¿Cuál es el rendimiento esperado al final de la campaña?
• ¿Cuál es la probabilidad de que surja estrés hídrico en los próximos días?
• ¿Cuál es la probabilidad de que los síntomas estén asociados a una enfermedad concreta?
• ¿Cuánta producción puede llegar al almacén la próxima semana?

Estas son preguntas predictivas. Aquí el sistema intenta usar lo que sabe sobre la meteorología, el suelo, el cultivo y el manejo previo para estimar un resultado que aún no se ha producido.

La segunda pregunta, en cambio, es: ¿Qué ocurrirá si cambiamos algo? Por ejemplo, podemos preguntar:

• ¿Qué le ocurrirá al resultado si cambia el momento del riego?
• ¿Mejorará el rendimiento si se cambia una de las prácticas de manejo?
• ¿Reducirá el consumo de agua acortar el tiempo de funcionamiento de una bomba, sin causar estrés al cultivo?
• ¿Fue el tratamiento aplicado la causa de la mejora, o se produjo la mejora por otras razones?

Estas son preguntas causales, porque no se limitan a describir lo que puede ocurrir; preguntan por el efecto de una acción que queremos emprender. La correlación no demuestra que un factor cause el otro. Los datos pueden revelar que las parcelas que utilizaron una cantidad mayor de un determinado insumo agrícola alcanzaron rendimientos más altos. Esa es una relación que merece estudio, pero no demuestra que aumentar ese insumo causara el rendimiento más alto.

Pueden existir otras explicaciones, como:

• que esas parcelas tuvieran mejor suelo desde el principio.
• que el riego allí fuera más constante.
• que los agricultores que las gestionaban tuvieran más experiencia.
• que sus propietarios dispusieran de mejores equipos.
• que el insumo se utilizara en parcelas con cultivos o variedades distintos.
• que las condiciones meteorológicas fueran más favorables en sus ubicaciones.
• que el agricultor aumentara el insumo en respuesta a una condición que no quedó registrada en los datos.

En este caso, el insumo y el rendimiento pueden aparecer juntos, mientras que la causa real de la diferencia es otro factor o una combinación de factores. Esto es similar a observar que las explotaciones que usan más sensores obtienen mejores resultados. Eso por sí solo no demuestra que comprar sensores vaya a mejorar el resultado en cualquier explotación; las explotaciones que pueden permitirse comprar sensores quizá ya estuvieran mejor equipadas, mejor financiadas y mejor gestionadas desde el principio. Así pues, la correlación es útil para descubrir patrones y construir predicciones, pero por sí sola no responde a la pregunta:

¿Cambiar este factor en otra explotación conducirá al mismo resultado? ¿Por qué importa esta distinción al agricultor? Esta distinción no es un debate estadístico abstracto y alejado del campo. Si el sistema encuentra una relación entre una variable y el rendimiento, y después la convierte directamente en una recomendación, ha pasado de observar una correlación a suponer una causación. Un sistema que predice que una parcela dada alcanzará un rendimiento alto no sabe necesariamente cómo hacer que otra parcela alcance el mismo rendimiento. Su capacidad predictiva puede basarse en factores que el agricultor no puede cambiar, como el tipo de suelo, el historial del emplazamiento o las condiciones de la campaña. Del mismo modo, un sistema puede ser capaz de predecir qué parcelas son más vulnerables al estrés, pero eso no demuestra automáticamente que cualquier intervención que proponga vaya a prevenir el estrés o a aportar un beneficio económico. Por esta razón, deben distinguirse tres etapas:

1. Observación: ¿Qué relación apareció en los datos?
2. Interpretación: ¿Cuáles son las razones posibles de esta relación?
3. Intervención: ¿Qué evidencia hay de que cambiar un factor concreto cambiará el resultado?

Cuanto más avanzamos de una etapa a la siguiente, más sólida ha de ser la evidencia que necesitamos. ¿Cómo nos acercamos a conocer el efecto de una intervención? Para determinar si la intervención fue lo que marcó la diferencia, necesitamos un método que separe su efecto de los efectos de otros factores en la medida de lo posible. Esto puede lograrse mediante:

• un ensayo de campo adecuado que compare tratamientos concretos.
• la asignación de los tratamientos de un modo que reduzca las diferencias preexistentes entre los grupos.
• la comparación de parcelas o subparcelas lo más similares posible.
• la medición de las condiciones antes y después de la intervención, con una línea de base clara.
• el uso de un diseño analítico causal que declare sus supuestos y sus limitaciones.
• el apoyo en conocimientos agronómicos o biológicos que expliquen cómo el factor podría conducir al resultado.
• la reproducción del resultado en distintos emplazamientos o campañas.

Tampoco el uso de un método llamado «inferencia causal» significa que una relación se haya vuelto causal por el mero hecho de que el programa le haya asignado un número. Todo análisis causal depende de supuestos: ¿qué factores se midieron? ¿Qué factores faltaban? ¿Eran comparables los grupos? ¿Y precedió la causa al resultado en el tiempo? Y un algoritmo no puede corregir un factor importante que no se midió ni se registró salvo apoyándose en supuestos adicionales que deberían explicitarse. La regla práctica: un modelo bueno en predicción no es necesariamente bueno en estimar el efecto de una intervención. Predecir un resultado con exactitud no demuestra que el sistema sepa cómo cambiar ese resultado. ¿Qué añaden los modelos probabilísticos? En muchas situaciones agrícolas, los datos no bastan para dar una respuesta definitiva. La imagen puede no ser clara, los síntomas pueden solaparse, el registro meteorológico puede estar incompleto o la lectura del sensor puede ser inestable. En lugar de ocultar esa carencia, los modelos probabilísticos intentan expresar el grado de incertidumbre. Imaginemos manchas que aparecen en las hojas de un cultivo. Las causas posibles pueden ser:

• una enfermedad fúngica.
• una carencia de nutrientes.
• estrés hídrico.
• daño por calor o por sol.
• daño mecánico.
• más de una causa al mismo tiempo.

Si el sistema se basa en una sola imagen, puede no ser capaz de distinguir con confianza entre esas causas. Por tanto, no debería saltar directamente a un único diagnóstico; más bien puede ordenar las posibilidades e indicar qué necesita para acotarlas. Esto es lo que se entiende por diagnóstico diferencial: comparar varias explicaciones posibles de los síntomas y reunir después información que ayude a descartar algunas y reforzar otras. Por ejemplo, el sistema puede pedir:

• una imagen del envés de la hoja.
• una descripción de cómo se distribuyen los síntomas dentro de la parcela.
• si los síntomas aparecieron en hojas más nuevas o más viejas.
• un registro de temperatura y humedad.
• información sobre el riego o sobre tratamientos anteriores.
• una inspección de campo o una prueba adecuada cuando sea necesario.

A medida que llega cada nueva información, el sistema revisa el orden de las posibilidades. El valor aquí no reside en la rapidez con que se asigna un nombre, sino en organizar lo que sabemos y lo que no sabemos, e identificar cuál es la siguiente información más útil. La probabilidad no es certeza persuasiva en forma numérica El sistema puede decir: La probabilidad de esta condición es del 80%. Pero ¿qué significa este número? No significa que esa hoja concreta esté «infectada al 80%», ni significa que el 80% de la hoja esté infectado. Lo que significa, si el sistema está bien calibrado, es que cuando asigna una probabilidad cercana al 80% a un gran número de casos similares, el resultado debería producirse en unos ochenta casos de cada cien, no en todos los casos. La concordancia entre los números de confianza y lo que ocurre realmente se denomina calibración de la probabilidad. Supongamos que un sistema asignó a cien casos una probabilidad cercana al 80%:

• si el resultado se confirma en unos ochenta casos, su confianza es relativamente coherente con la realidad.
• si se confirma solo en cincuenta casos, el sistema está más seguro de lo que debería.
• si se confirma en noventa y cinco casos, el sistema puede estar menos seguro de lo que justifican sus resultados.

Esta comparación no se realiza sobre un caso único, sino sobre un número adecuado de casos similares. Ordenar los casos no significa que los números de probabilidad sean correctos El sistema puede lograr ordenar los casos del más probable al menos probable y, aun así, asignar números de confianza engañosos. Un caso al que asignó un 90% puede ser efectivamente más probable que otro al que asignó un 60%, y en ese sentido la ordenación del sistema es útil. Pero si los casos a los que asignó un 90% se confirman solo el 65% de las veces, sus números de confianza están sobredimensionados. Así pues, hay dos preguntas separadas:

1. ¿Ordena el sistema los casos de una manera útil?
2. ¿Reflejan los números de probabilidad la realidad en un grado aceptable?

Puede tener éxito en la primera y fracasar en la segunda. ¿Por qué cambia la confianza al pasar a una explotación nueva? Las probabilidades de un sistema pueden estar bien calibradas en el entorno en el que se probó y volverse después engañosas cuando se traslada a otro lugar. Esto puede ocurrir por diferencias en:

• el cultivar.
• el estado fenológico.
• el clima.
• el grado de propagación de la afección.
• la cámara o el sensor.
• la calidad de la imagen.
• las prácticas de manejo.
• La proporción de casos raros y casos frecuentes.
• El método empleado para confirmar el diagnóstico.

Por ello no basta con que el proveedor muestre que las probabilidades eran apropiadas en los datos de desarrollo. La confianza debe monitorizarse tras la transferencia, compararse con los resultados reales y recalibrarse cuando sea necesario. La recalibración no hace automáticamente que el modelo sea adecuado si el nuevo entorno es fundamentalmente distinto; pueden requerirse datos nuevos o una revisión del propio ámbito de uso. ¿Cómo debería presentarse el resultado al usuario? Lo ideal es que el sistema no presente un número desnudo ni una respuesta definitiva, sino que muestre el resultado en cuatro capas: 1\. El resultado más probable y la incertidumbre Por ejemplo: Hay varias causas posibles, y los datos actuales no bastan para confirmar ninguna de ellas. O bien: La estimación se sitúa dentro de un intervalo determinado y puede cambiar si cambian la meteorología o el manejo. 2\. La evidencia que influyó en la ponderación Por ejemplo: La probabilidad de estrés hídrico aumentó a causa de las lecturas bajas de humedad y las temperaturas altas, pero falta la lectura de un sensor. 3\. La información que falta y el paso siguiente Por ejemplo: Es necesario revisar el sensor, o se necesita una imagen adicional, o una descripción de la distribución de los síntomas, o la revisión de un especialista, antes de poder acotar las posibilidades. 4\. Los límites de la decisión y la responsabilidad Por ejemplo: Este resultado es un aviso preliminar, no un diagnóstico confirmado ni una instrucción para aplicar un tratamiento. De este modo, la probabilidad se convierte en una herramienta para estructurar una decisión, no en un número que otorga al sistema una autoridad que no posee. Ejemplo práctico: la predicción del rendimiento no es una receta para aumentarlo Supongamos que un modelo predice el rendimiento a partir de:

• El tipo de suelo.
• La meteorología.
• La variedad.
• El momento de las operaciones.
• Los registros de riego.
• Los datos de campañas anteriores.

El modelo puede hacer una buena predicción porque ha aprendido que algunas parcelas con mejor suelo y un manejo más constante producen rendimientos más altos. Pero si además observa que un rendimiento mayor se asoció a un aumento de uno de los insumos, puede no inferir directamente que incrementar ese insumo en todas las parcelas elevará el rendimiento. Ese aumento puede ser apropiado solo para determinadas parcelas o condiciones, o puede ser simplemente un indicador asociado a explotaciones mejor gestionadas. Un modelo predictivo responde a la pregunta: ¿Cuál es el rendimiento probable en estas condiciones? Estimar el efecto de una intervención, en cambio, plantea: ¿Cómo habría diferido el rendimiento si hubiéramos cambiado solo este factor, permaneciendo los demás factores comparables? La segunda pregunta es más difícil, porque se refiere a un resultado alternativo que no observamos en la misma parcela y en el mismo momento. Por eso exige diseño, experimentación y supuestos más claros que la mera observación de la relación en los registros. Preguntas prácticas antes de aceptar una recomendación basada en una relación estadística El lector puede preguntar:

• ¿El sistema ofrece una predicción o afirma estimar el efecto de una intervención?
• ¿Qué otros factores podrían explicar la relación aparente?
• ¿Se probó la intervención misma, o solo se observó en datos anteriores?
• ¿Eran comparables las parcelas o los grupos?
• ¿Qué factores importantes no se midieron?
• ¿Se replicó el resultado en distintas ubicaciones y campañas?
• ¿El sistema presenta un intervalo y una probabilidad, o un número definitivo?
• ¿Se comprobó la validez de las cifras de confianza tras la transferencia al entorno local?
• ¿Qué información adicional podría reducir la incertidumbre?
• ¿Quién tiene la autoridad para convertir el resultado en acción?

La regla distintiva La diferencia puede resumirse en tres preguntas:

• ¿Qué está ocurriendo ahora? Una pregunta de medición o de diagnóstico.
• ¿Qué es probable que ocurra después? Una pregunta de predicción.
• ¿Qué cambiará si intervenimos? Una pregunta causal que exige una evidencia más sólida.

Un sistema responsable declara el tipo de pregunta al que responde, y no convierte la correlación en causalidad, ni una previsión en una prescripción, ni la probabilidad en certeza.

6. Optimización e investigación operativa

La predicción dice lo que puede ocurrir, mientras que la optimización busca una acción o un plan entre muchas alternativas bajo restricciones determinadas. Puede repartir un agua limitada entre sectores, organizar una ruta de recogida, coordinar la cosecha, el transporte y la refrigeración, o asignar trabajadores y máquinas a ventanas temporales que compiten entre sí. Un problema de optimización consta de tres elementos:

1. Decisiones que pueden modificarse: ¿cuándo debemos regar? ¿Qué ruta debe tomar el vehículo? ¿Qué lote debe enfriarse primero?
2. Restricciones que no deben ignorarse: la capacidad de bombeo, el tiempo, las existencias, la seguridad, la energía, la mano de obra y los límites agrícolas.
3. Un objetivo que queremos mejorar: reducir el agua, el tiempo o las pérdidas, o equilibrar varios objetivos.

Imaginemos tres sectores que necesitan riego, mientras que la capacidad de bombeo no permite que funcionen al mismo tiempo. El sistema puede proponer un calendario que tenga en cuenta el estado hídrico, la prioridad del cultivo y los precios de la energía. Pero si la función objetivo minimiza únicamente el consumo eléctrico, puede retrasar un sector sensible. Y si maximiza únicamente el rendimiento esperado, puede ignorar la parte que corresponde a un pequeño agricultor o un límite a la extracción de agua. El algoritmo ejecuta lo que se le ha definido; no añade por su cuenta los valores que el diseñador olvidó especificar. Por esta razón, no existe una «solución óptima» en abstracto. Existe una solución óptima respecto a un objetivo, unas restricciones y unos datos en un momento determinado. Si las prioridades cambian, falla un recurso o disminuye la confianza en la predicción, el sistema debería recalcular o pasar a un plan alternativo. En los problemas del mundo real, los objetivos son múltiples. Queremos preservar el rendimiento, reducir el uso de agua y energía, evitar el estrés y respetar la ventana de trabajo. Estos valores no siempre pueden reducirse a un número neutro. Por ello, presentar varios escenarios con sus contrapartidas es más honesto que presentar un único plan como si fuera la única respuesta. El sistema debería disponer también de un modo manual seguro. Si se pierde la comunicación, fallan los datos meteorológicos o las restricciones entran en conflicto, el proceso esencial no debe detenerse ni continuar con un plan antiguo sin advertencia. La potencia de la optimización no se mide solo por la elegancia del plan en condiciones ideales, sino por su capacidad de afrontar restricciones y excepciones reales. Pregunta práctica: cuando un proveedor dice «optimizamos el riego», pregunte: ¿qué objetivo está optimizando el sistema? ¿Quién fijó las ponderaciones del agua, el rendimiento y la energía? ¿Y cuál es el plan si los datos están incompletos?

7. Aprendizaje por refuerzo y control: ¿cómo aprende el sistema a partir de una secuencia de acciones?

En algunos problemas agrícolas, la tarea no consiste en emitir una única previsión y detenerse. Cada acción que se ejecuta cambia el estado de la explotación o de la máquina, y el nuevo estado afecta a la decisión siguiente. Cuando se abre una ventana en un invernadero, la temperatura puede bajar y la humedad puede cambiar, pero el efecto de la apertura depende además de la temperatura del aire exterior, del viento y del tiempo que la ventana permanezca abierta. Y cuando un robot se desplaza entre las líneas de cultivo, cambia su posición y también lo que sus cámaras pueden ver; puede aparecer ante él un trabajador, un animal o un obstáculo que instantes antes no estaba allí. En estos problemas no nos enfrentamos a una sola decisión, sino a una secuencia de decisiones interrelacionadas. Es aquí donde el aprendizaje por refuerzo puede desempeñar un papel. ¿Qué se entiende por aprendizaje por refuerzo? El aprendizaje por refuerzo es un método en el que el sistema aprende a elegir una secuencia de acciones observando los resultados de lo que hace. La palabra «refuerzo» no significa que este tipo de aprendizaje sea mejor o más potente que todos los demás métodos. Lo que significa es que, tras sus acciones, el sistema recibe señales numéricas que refuerzan las elecciones que lo acercan al objetivo y reducen el valor de las elecciones que lo alejan de él o conducen a resultados indeseables. La idea puede compararse con un aprendiz que prueba varias maneras de alcanzar un resultado y va conservando gradualmente aquellas que condujeron a mejores resultados. Pero esta comparación tiene límites; el sistema no comprende la explotación en términos éticos ni agronómicos, y no sabe por sí mismo qué debe considerarse «mejor». Son los seres humanos quienes determinan qué mide, qué acciones están disponibles y qué límites no deben traspasarse. El aprendizaje por refuerzo consta de varios elementos principales:

1. Estado: la información que describe la situación actual en la medida en que el sistema puede medirla.
2. Acción: la opción que el sistema puede ejecutar en ese momento.
3. Resultado: lo que cambió en el entorno después de llevar a cabo la acción.
4. Puntuación numérica: una señal que indica si el resultado se acercó al objetivo o se alejó de él.
5. Estrategia de selección: el método que el sistema aprende para elegir la acción apropiada en cada estado.

Los especialistas llaman agente al programa que elige las acciones, recompensa a la puntuación numérica y política a la estrategia de selección. Pero comprender las funciones importa más que memorizar los nombres. Un ejemplo simplificado en un invernadero Supongamos que hay un sistema que ayuda a gestionar la temperatura, la humedad y la energía dentro de un invernadero. El estado que el sistema ve La información disponible puede incluir:

• La temperatura dentro del invernadero.
• La humedad.
• La temperatura exterior.
• La intensidad de la luz solar.
• La velocidad del viento.
• El estado de las ventanas y los ventiladores.
• La humedad del sustrato de cultivo.
• La hora del día.
• El estado de los sensores y los equipos.

Esto no es el «entorno entero», sino la parte que los dispositivos pueden medir y enviar al sistema. Así pues, si uno de los sensores está averiado, o si los datos llegan tarde, el sistema puede tomar su decisión a partir de una imagen incompleta o desactualizada. Las acciones que puede elegir Las acciones disponibles pueden incluir:

• Abrir una ventana en un grado determinado.
• Cerrarla.
• Encender un ventilador.
• Reducir o aumentar la velocidad del ventilador.
• Desplegar el sombreo.
• Mantener el estado actual.
• Solicitar la intervención de un trabajador en lugar de la ejecución automática.

Tampoco debe permitirse al sistema cualquier acción imaginable. Las acciones disponibles deben definirse de antemano y quedar acotadas por los límites de los equipos, la seguridad y el cultivo. ¿Qué ocurre después de la acción? Si el sistema abre la ventana, la temperatura puede bajar, pero la humedad también puede cambiar. El consumo de energía puede aumentar asimismo si el sistema compensa el cambio poniendo en marcha otros equipos. Y una acción puede ser adecuada a una hora del día e inadecuada a otra. El sistema observa lo que ocurrió después de la acción y utiliza después el resultado para mejorar sus elecciones posteriores. Así pues, no aprende de una sola decisión, sino de una secuencia: Estado → acción → cambio en el entorno → nuevo estado → nueva acción ¿Qué significa «recompensa»? La recompensa en este contexto no es un premio, ni significa que el sistema sienta satisfacción o castigo. Es una puntuación numérica definida por el diseñador para evaluar el resultado de una acción. La puntuación puede subir cuando:

• La temperatura y la humedad se mantienen dentro del intervalo requerido.
• El consumo de energía baja sin perjudicar las condiciones de la planta.
• El sistema evita hacer funcionar los equipos innecesariamente.
• Preserva la estabilidad ambiental en lugar de provocar cambios bruscos.
• Solicita la intervención de un trabajador cuando los datos son insuficientes o contradictorios.

Y la puntuación puede bajar cuando:

• Las condiciones rebasan los límites aceptables.
• El sistema utiliza más energía o más agua de la necesaria.
• Enciende y apaga los equipos repetidamente de un modo que acelera su desgaste.
• Ignora un sensor averiado.
• Elige una acción que se aproxima a los límites de seguridad.

Así pues, la expresión «una recompensa que expresa el objetivo» significa en realidad: Una ecuación o un método de cálculo establecido por el diseñador para convertir varios resultados —como el estado de la planta, la energía, el agua y la estabilidad de los equipos— en señales que ayuden al sistema a comparar sus acciones. Pero esta puntuación no representa necesariamente el objetivo entero. Lo que el diseñador no incluye en el cálculo es algo que el sistema puede no tener en cuenta. Cuando el sistema acierta con el número pero yerra el propósito Supongamos que el diseñador dio al sistema un único objetivo: minimizar el consumo de energía. El sistema puede aprender a reducir el funcionamiento de los ventiladores o de la ventilación más de lo debido. Puede lograr, en términos computacionales, recortar el consumo eléctrico mientras la temperatura o la humedad dentro del invernadero se deterioran. Supongamos que el objetivo es mantener la temperatura en un único valor. El sistema puede encender y apagar los equipos de calefacción y refrigeración repetidamente, ignorar la humedad o consumir grandes cantidades de energía para impedir una pequeña variación natural que no perjudica a la planta. En ambos casos, el sistema ha hecho computacionalmente lo que se le pidió, pero no ha alcanzado el propósito agrícola más amplio. El error aquí no procede necesariamente de una debilidad del algoritmo. El error puede residir en la manera en que los seres humanos formularon el objetivo. El sistema puede optimizar la puntuación que se le dio, pero no conoce automáticamente los intereses y las restricciones que no se incluyeron en su definición. Por ello, según el problema, el método de evaluación debe incluir:

• Las condiciones de la planta.
• El agua y la energía.
• La estabilidad de los equipos.
• La seguridad de las personas y de los animales.
• Los límites de operación.
• El coste de los cambios frecuentes.
• La capacidad de replegarse a un modo seguro.
• Los casos en que la decisión debe entregarse a una persona.

La regla básica: el sistema no aprende lo que queremos en nuestra mente; aprende lo que expresamos en los datos, las puntuaciones y las restricciones. ¿Por qué no basta una penalización computacional para proteger la seguridad? Un diseñador puede pensar en rebajar la puntuación cuando el sistema ejecuta una acción peligrosa. Pero hay acciones que no deben poder intentarse en absoluto, aunque después condujeran a una puntuación negativa. Por ejemplo, no debe permitirse que el sistema aprenda el peligro de cortar la ventilación en condiciones severas ejecutando la acción y poniendo en riesgo la planta. Ni que un robot aprenda que acercarse a un trabajador es inseguro chocando una vez con ese trabajador. Por ello debe distinguirse entre:

• Los objetivos que el sistema puede optimizar.
• Los límites de seguridad que no debe traspasar.

El sistema puede intentar reducir el uso de energía o mejorar la estabilidad dentro del rango permitido, pero una capa independiente debe impedirle:

• Superar un límite peligroso de temperatura.
• Accionar una herramienta cuando hay una persona en la zona de movimiento.
• Continuar si fallan sensores críticos.
• Ejecutar una orden con una unidad o un valor fuera de los límites aprobados.
• Seguir moviéndose tras perder la localización o la comunicación.
• Desactivar el mecanismo de parada manual.

Estos límites se denominan a veces restricciones duras, es decir, reglas operativas vinculantes que el sistema no puede quebrantar en busca de una puntuación mejor. ¿Qué se entiende por exploración? Para que el sistema sepa qué acciones son mejores, puede necesitar probar opciones que no ha utilizado mucho antes. Esto se denomina exploración. Pero la exploración en un sistema real difiere de la experimentación dentro de un juego digital. Un error en el campo puede desperdiciar agua, provocar estrés a un cultivo, dañar equipos o poner en riesgo a un trabajador. Por ello, el sistema no debe tener libertad para probar cualquier acción en la explotación. El riesgo puede reducirse mediante una vía gradual:

1. El aprendizaje o la evaluación empiezan en una simulación que representa el entorno de forma razonable.
2. Se utilizan datos históricos para comprender qué ocurrió en condiciones anteriores, teniendo presente que no cubren todas las acciones posibles.
3. El sistema se prueba en modo de monitorización, proponiendo acciones sin ejecutarlas.
4. Sus propuestas se comparan con lo que hizo el operador y con lo que ocurrió después.
5. Se pasa a un ensayo limitado dentro de un rango de bajo riesgo.
6. Las restricciones independientes y la autoridad humana de parada permanecen activas.
7. La operación solo se amplía cuando ha surgido evidencia suficiente de seguridad y estabilidad.

La simulación por sí sola no basta, porque es una imagen simplificada de la realidad. La respuesta de la planta, de los equipos o de la meteorología puede diferir de lo que el modelo supuso. Esto se conoce a veces como la brecha entre la simulación y la realidad. Por ello, el paso a la operación real debe ser gradual, monitorizado y reversible. No todo problema de control requiere aprendizaje por refuerzo El aprendizaje por refuerzo puede parecer atractivo porque aprende de una secuencia de decisiones, pero no es automáticamente la mejor opción. Si las reglas de operación son claras y estables, un sistema sencillo basado en reglas puede ser más transparente y más fácil de probar. Si la respuesta de los equipos es conocida y puede representarse bien, los métodos de control convencionales o la optimización con restricciones pueden ser más seguros y menos costosos. El aprendizaje por refuerzo pasa a ser candidato cuando:

• las decisiones son secuenciales, y cada acción afecta a lo que sigue.
• el resultado de algunas acciones solo aparece con retraso.
• existe una contrapartida entre un beneficio inmediato y un efecto posterior.
• es difícil escribir una regla fija que cubra todos los casos.
• se dispone de un entorno de entrenamiento o de una simulación adecuados.
• puede especificarse un rango seguro de acciones.
• existe una forma de monitorizar el rendimiento y revertir.

Pero si el objetivo es simplemente detectar una enfermedad en una imagen, predecir el rendimiento o emitir un único aviso, otros métodos pueden ser más adecuados. El aprendizaje por refuerzo no debe utilizarse solo porque suene más nuevo o más emocionante. ¿Quién hace qué dentro del sistema de control? En un sistema agrícola real, varias funciones deben mantenerse separadas: 1\. Medición del estado Los sensores y las cámaras recogen información sobre el entorno y los equipos. Esta información puede ser incompleta, llegar con retraso o ser inexacta. 2\. Estimación o predicción del estado Puede utilizarse un modelo para estimar lo que no se mide directamente, o para predecir lo que puede ocurrir después de ejecutar una acción determinada. 3\. Selección de la acción La estrategia de control determina la acción propuesta a la luz del estado, el objetivo y las restricciones. 4\. Comprobación de seguridad Una capa independiente revisa si la acción está permitida, si los datos son suficientes y si los equipos y el entorno se encuentran en condiciones seguras. 5\. Ejecución Se envían órdenes a las ventanas, los ventiladores, las bombas o los motores, y debe confirmarse que la orden se llevó realmente a cabo, no solo que se envió. 6\. Verificación del resultado El sistema compara lo que se esperaba con lo que ocurrió después de la ejecución. Si el dispositivo no responde, o se mueve de otro modo, esto debe detectarse. 7\. Supervisión humana Una persona tiene la autoridad para aprobar, detener o anular, y puede volver a una operación manual clara cuando falla la aplicación o la conexión. Esta separación es importante porque el éxito de una parte no demuestra el éxito del sistema entero. El programa puede seleccionar una acción apropiada y, sin embargo, la válvula no responder. La válvula puede ejecutar la orden, pero el sensor que confirma el resultado puede estar averiado. Los componentes pueden funcionar técnicamente, pero el objetivo mismo puede ser incompleto. ¿Qué se entiende por aprendizaje por refuerzo profundo? El aprendizaje por refuerzo profundo es aprendizaje por refuerzo que utiliza redes neuronales profundas para ayudar al sistema a representar estados complejos, estimar el valor de las acciones o seleccionarlas. Y la palabra «profundo» no significa que el sistema:

• comprenda el entorno de un modo humano.
• sea más seguro.
• requiera necesariamente un robot.
• vea imágenes automáticamente.
• sea apto para su despliegue en campo.
• sea mejor que las reglas o el control convencional.

El aprendizaje por refuerzo profundo puede utilizarse en un entorno simulado para seleccionar acciones, mientras que la visión por computador emplea otro modelo para analizar imágenes. Ambos pueden operar dentro de un mismo robot, pero desempeñan dos funciones distintas. Una corrección importante de fuente: ver la mala hierba no es controlar su eliminación En material editorial anterior de este libro apareció una frase que describía uno de los estudios de detección de malas hierbas como ejemplo de «aprendizaje por refuerzo profundo» utilizado en la eliminación robótica. Pero la fuente que pudo verificarse [SRC009] trata de la clasificación de imágenes captadas en campos de soja mediante redes neuronales convolucionales. Es decir, el estudio respalda una de las tareas de la visión por computador: analizar la imagen y distinguir entre patrones. Y esta fuente no establece que el estudio desarrollara:

• un sistema que aprenda una secuencia de acciones.
• una estrategia de control en un robot.
• una señal de recompensa para evaluar la eliminación.
• un movimiento automatizado hacia la mala hierba.
• un despliegue en campo para la eliminación.
• un sistema basado en aprendizaje por refuerzo profundo.

La diferencia es fundamental: La visión por computador pregunta: ¿hay una mala hierba en la imagen, y dónde está? El aprendizaje por refuerzo y el control, en cambio, preguntan: ¿Qué acción debe emprender la máquina ahora, y cómo afectará al estado y a la acción siguiente? Un robot de escarda puede necesitar un modelo de visión para identificar la planta, después otro sistema para determinar la ubicación, después un planificador de movimiento, después un controlador que ejecute la acción, y después una capa de seguridad que detenga la máquina cuando surja un peligro. El éxito de un algoritmo de clasificación no demuestra el éxito de esta cadena. Incluir esta corrección no es una discusión sobre denominaciones, sino una aplicación del método probatorio del libro: no debe atribuirse a la fuente ningún algoritmo, capacidad operativa ni impacto en campo salvo que ella lo establezca. Ejemplo integrado: gestión de la ventilación en un invernadero Supongamos que el sistema gestiona una ventana y un ventilador dentro de un invernadero. En un momento dado, lee:

• una temperatura interna ligeramente elevada.
• humedad alta.
• una temperatura exterior más baja.
• vientos moderados.
• ninguna alarma de los equipos.

Puede elegir entre:

• dejar las cosas como están.
• abrir parcialmente la ventana.
• abrirla más.
• encender el ventilador.
• utilizar la ventana y el ventilador conjuntamente.
• solicitar la revisión de un trabajador.

Si abre parcialmente la ventana y la temperatura y la humedad bajan sin un consumo elevado de energía, el método de evaluación registra que el resultado se ha acercado al objetivo. Si la acción provoca un cambio brusco o la humedad sale del intervalo, la puntuación numérica desciende. Pero debe haber, aun así, reglas no sujetas a experimentación, como:

• no accionar los equipos si la tapa de mantenimiento está abierta.
• no continuar cuando sensores críticos se contradicen.
• no rebasar los límites de operación de los motores.
• pasar a un modo seguro cuando se pierde la comunicación.
• permitir que el trabajador lo detenga de inmediato.

De este modo, el sistema aprende dentro de un espacio permitido y no tiene libertad para redefinir la seguridad mediante la experimentación. Preguntas prácticas antes de aceptar un sistema basado en aprendizaje por refuerzo El agricultor, el comprador o el operador pueden preguntar:

• ¿Qué decisiones secuenciales aprende a tomar el sistema?
• ¿Qué información describe el estado actual?
• ¿Qué ocurre si un sensor importante está averiado o llega con retraso?
• ¿Qué acciones está autorizado a emprender el sistema?
• ¿Cómo se calculó la puntuación numérica que guía el aprendizaje?
• ¿Qué aspectos no se incluyeron en esa puntuación numérica?
• ¿Qué límites no puede rebasar el sistema?
• ¿Dónde se realizó el entrenamiento: en simulación o en operación real?
• ¿Cómo se abordó la brecha entre la simulación y la explotación?
• ¿Comenzó el sistema con recomendación y monitorización antes de la ejecución?
• ¿Qué ocurre cuando se encuentra con una situación que no ha visto antes?
• ¿Existe un mecanismo local de parada independiente de la aplicación?
• ¿Quién tiene la autoridad para aprobar, anular y volver al modo manual?
• ¿Es realmente necesario el aprendizaje por refuerzo, o hay un enfoque más simple y más claro?

Para el lector avanzado: la evaluación de un sistema de aprendizaje por refuerzo no se limita a la puntuación media que obtuvo durante el entrenamiento. Deben examinarse su comportamiento en casos raros, la estabilidad de su rendimiento, su sensibilidad al modo en que se define el objetivo, su capacidad de operar con datos incompletos, su observancia de las restricciones, la brecha entre la simulación y la realidad y la seguridad del paso de la recomendación a la ejecución. Conclusión El aprendizaje por refuerzo no es un método que conceda a la máquina libertad para experimentar en el campo. Es un enfoque para aprender a elegir acciones secuenciales dentro de límites diseñados por seres humanos. Su valor depende de cinco cosas:

1. Que la información disponible describa realmente el estado relevante.
2. Que la puntuación numérica represente el objetivo agrícola sin reducirlo a un número engañoso.
3. Que la seguridad permanezca en reglas independientes que no deben anularse.
4. Que el paso de la simulación a la operación sea gradual y reversible.
5. Que los seres humanos sigan siendo quienes tienen la autoridad para detener el sistema y dar la aprobación final.

Y la regla que el lector debería llevarse es: El sistema no aprende el objetivo que pretendemos de forma implícita; aprende el comportamiento que los números recompensan y las restricciones permiten. Por ello, el objetivo y los límites deben probarse antes de probar la inteligencia del algoritmo. La regla final de seguridad puede enunciarse con mayor claridad así: El campo no debería ser el primer lugar donde el diseñador descubra que el método de evaluación del sistema es incompleto, o que probar una acción nueva puede perjudicar al cultivo, a las personas o a los equipos.

8. Modelos de lenguaje, generación y recuperación: de la pregunta a la respuesta fundamentada

Un agricultor puede preguntar al asistente digital en lenguaje corriente en lugar de buscar entre menús largos o rellenar un formulario técnico complejo. Puede preguntar por el significado de un aviso, pedir el resumen de un documento, solicitar la traducción de unas instrucciones, comparar dos registros o extraer un dato concreto de un informe. Esta facilidad es uno de los beneficios más importantes de los modelos de lenguaje, pero es también una fuente potencial de malentendidos. Una respuesta escrita en un lenguaje claro y seguro puede parecer proveniente de un experto que conoce el campo, el lugar y el producto, cuando en realidad el sistema puede haberla compuesto a partir de patrones lingüísticos o de información incompleta que no basta para tomar decisiones. Así pues, no basta con preguntar: ¿Puede el sistema escribir una respuesta comprensible? También debemos preguntar: ¿De dónde procede la información de la respuesta? ¿Y es aplicable a este cultivo, lugar, momento y decisión? ¿Qué hacen los modelos de lenguaje? Un modelo de lenguaje es un sistema entrenado con grandes cantidades de texto para aprender las relaciones que se repiten entre palabras, frases e ideas. Cuando se le pide una respuesta, construye el texto pieza a pieza a partir de la pregunta, las instrucciones del sistema y el contexto de que disponga. Puede utilizarse para tareas como:

• Resumir un documento extenso.
• Traducir contenido de una lengua a otra.
• Convertir notas dispersas en un informe organizado.
• Extraer de un registro el nombre del cultivo, la ubicación, la fecha o la unidad.
• Explicar un término técnico en un lenguaje más sencillo.
• Comparar varios documentos.
• Gestionar un diálogo compuesto por más de una pregunta y respuesta.
• Formular una respuesta en lenguaje natural que el usuario pueda leer.

Pero estas capacidades no significan que el modelo posea una comprensión agrícola independiente ni una memoria actualizada de cada normativa, precio y producto. Es bueno construyendo textos coherentes y, al hacerlo, puede emplear información correcta, información incompleta o una conexión que parece lingüísticamente verosímil pero no está firmemente fundamentada en la fuente. La fluidez, por tanto, es una propiedad de la redacción de la respuesta, no una prueba de la exactitud de su contenido. ¿Cómo puede una respuesta ser convincente y, sin embargo, carecer de respaldo? Cuando el modelo no dispone de información suficiente, puede no dejar la laguna a la vista. Puede completar la frase con una redacción que parece verosímil según los patrones que aprendió de textos anteriores. De ello pueden resultar:

• Un número que no aparece en la fuente.
• Una causa incierta presentada como si fuera un diagnóstico.
• Una dosis que parece razonable pero no está vinculada a un producto registrado.
• Un nombre de producto que no es adecuado para el cultivo o para el país.
• Un precio desactualizado, o procedente de otro mercado.
• Una cita que parece oficial pero no respalda la afirmación.
• Una traducción que omitió un matiz, cambió una unidad o exageró el grado de certeza.
• Una respuesta general presentada como si fuera una recomendación específica para la explotación.

Esto no significa que el modelo intente engañar deliberadamente. El problema es que está diseñado para producir un texto que encaje en el contexto lingüístico, no para garantizar que cada frase se haya contrastado con una fuente válida para esta decisión. La regla básica: que un sistema sea capaz de completar una frase no significa que tenga la evidencia necesaria para completar una decisión. Una pregunta agrícola breve puede ocultar mucha información Si un agricultor pregunta: «Han aparecido manchas en mi cultivo; ¿qué debo usar?», la frase puede parecer clara lingüísticamente, pero está incompleta desde el punto de vista agrícola. No nos dice:

• ¿Cuál es el cultivo?
• ¿Cuál es la variedad?
• ¿Cuál es la edad de la planta y su estado fenológico?
• ¿Dónde se ubica la explotación?
• ¿Cuándo aparecieron los síntomas?
• ¿Aparecieron en hojas jóvenes o en hojas viejas?
• ¿Están en el haz o en el envés?
• ¿Se extienden por todo el campo o se limitan a rodales acotados?
• ¿Hay síntomas en el tallo, la raíz o el fruto?
• ¿Cuáles son las condiciones meteorológicas y de riego?
• ¿Se ha empleado algún tratamiento previo?
• ¿Es nítida la imagen y resulta representativa del caso?
• ¿Qué productos están registrados para ese cultivo y esa plaga en el país de uso?
• ¿Existen restricciones relacionadas con el plazo de seguridad o con la reentrada de los trabajadores?

Si el sistema rellena estas lagunas por su cuenta, puede dar una respuesta adecuada a un caso que ha imaginado, no al caso realmente presente en la explotación. Por ello, un sistema responsable debería detenerse cuando falta información y pedir lo que necesita antes de estrechar las posibilidades. La mejor respuesta inicial puede ser una pregunta aclaratoria, no una recomendación. ¿Cuál es la diferencia entre generación y recuperación? La generación es el proceso de formular una respuesta nueva en lenguaje natural. El modelo toma la pregunta y el contexto disponible, y luego los organiza en un texto que el usuario puede leer. La recuperación, en cambio, es la búsqueda, dentro de una colección de documentos o registros, de pasajes que puedan ser pertinentes para la pregunta. Si el usuario pregunta por el plazo de espera exigido para un producto concreto, el sistema puede buscar en:

• La etiqueta aprobada vigente del producto.
• El registro de inscripción del producto.
• Documentos emitidos por la autoridad reguladora competente.
• Orientaciones oficiales relacionadas con el cultivo y la plaga.
• Una edición fechada de una base de conocimiento aprobada.

La recuperación no formula necesariamente la respuesta final; más bien encuentra el material con el que puede construirse la respuesta. Cuando el sistema combina la búsqueda en fuentes con la formulación de una respuesta a partir de lo que ha recuperado, este flujo de trabajo se denomina generación aumentada por recuperación, abreviado habitualmente como RAG. ¿Qué ocurre en la generación aumentada por recuperación? El flujo de trabajo puede simplificarse en seis etapas:

1. Comprensión de la pregunta: determinar qué pregunta el usuario y qué información falta.
2. Definición del ámbito de búsqueda: elegir el conjunto de fuentes apropiado para el cultivo, la ubicación y el tema.
3. Localización de pasajes candidatos: buscar partes de documentos que parezcan pertinentes para la pregunta.
4. Comprobación de la validez: excluir documentos obsoletos, no oficiales o inadecuados para el contexto.
5. Formulación de la respuesta: utilizar los pasajes aceptados para redactar una respuesta clara.
6. Exhibición de la fuente y de los límites: permitir al usuario saber de dónde procede la información y qué no puede establecer la respuesta.

Esta vía puede reducir las respuestas sin respaldo, pero no las impide automáticamente. El sistema puede errar en cualquiera de las seis etapas. La recuperación no implanta conocimiento permanente dentro del modelo Cuando el sistema recupera un documento en el momento de la pregunta, coloca parte de él ante el modelo para ayudarle a formular la respuesta. Eso no significa que el conocimiento haya pasado a formar parte permanente del modelo, ni que todas sus respuestas posteriores lo utilicen correctamente. Con una pregunta nueva puede ejecutarse una búsqueda nueva y recuperarse un pasaje distinto. Por tanto, la calidad de cada respuesta depende de:

• la formulación de la pregunta.
• el conjunto de fuentes disponibles.
• cómo están organizadas e indexadas.
• los criterios de búsqueda.
• los pasajes presentados al modelo.
• las instrucciones que acotan la redacción.
• la capacidad del sistema de abstenerse cuando no encuentra respaldo suficiente.

Esto significa que no basta con evaluar el modelo de lenguaje por sí solo; hay que evaluar toda la vía de búsqueda, formulación y cita. ¿Cómo puede fallar la vía de recuperación? La vía puede fallar de varias maneras: 1\. Malinterpretar la pregunta Puede interpretar una palabra local como el nombre de una enfermedad, o confundir el nombre de un cultivo con el nombre de una variedad, o suponer que el usuario pregunta por el tratamiento cuando en realidad pregunta por la identificación inicial. 2\. Buscar en una colección inadecuada El sistema puede buscar en artículos generales cuando la pregunta requiere un documento oficial local, o buscar orientaciones referidas a un cultivo distinto. 3\. Recuperar un documento antiguo El documento pudo ser correcto cuando se emitió, pero el registro del producto, las restricciones, el precio o las instrucciones pueden haber cambiado después. 4\. Recuperar una fuente válida para un contexto distinto La recomendación puede ser correcta para otro país, otra variedad, otro estado fenológico o un sistema de producción diferente. 5\. Seleccionar un pasaje que comparte las palabras pero no el significado El pasaje puede contener el nombre de la enfermedad y el del cultivo, pero tratar de la prevención en lugar del tratamiento, o describir un estudio de investigación en lugar de instrucciones operativas. 6\. Ir más allá de la fuente al formular La fuente puede mencionar una nota general, y el modelo puede convertirla luego en una recomendación específica que no figura en la fuente. 7\. Colocar una cita correcta después de una frase que la fuente no respalda No basta con la presencia del nombre de la fuente o de su enlace. La propia afirmación debe figurar en la fuente, con el mismo grado de certeza y los mismos límites. Así pues, la fuente puede ser fiable y la recuperación puede tener éxito en el plano textual, y aun así la respuesta puede resultar inadecuada para la toma de decisiones agrícolas. La similitud en la redacción no equivale a aptitud para el uso Supongamos que el sistema encuentra un documento que trata de manchas foliares en un cultivo concreto. El documento puede parecer muy pertinente para la pregunta, pero puede:

• referirse a un país donde el registro de productos es distinto.
• tratar de otra variedad u otro entorno.
• ser un estudio de laboratorio y no una orientación de campo.
• describir síntomas similares con una causa distinta.
• ser antiguo o haber sido sustituido por una versión más reciente.
• tratar de la prevención mientras el usuario pregunta por un caso ya existente.
• mencionar una sustancia activa sin un producto registrado localmente.
• ser una traducción y haber perdido un matiz importante.

Por tanto, la recuperación no debería basarse únicamente en la similitud de palabras. La búsqueda debe estrecharse con información como:

• Cultivo.
• Variedad, si es necesario.
• Ubicación y jurisdicción legal.
• Estado fenológico.
• Fecha.
• Tipo de documento.
• Organismo emisor.
• Estado del documento: en vigor, archivado, borrador o derogado.
• Situación registral del producto.
• Tipo de decisión: información general, diagnóstico, dosis o actuación regulada.

A estas condiciones se las denomina a veces filtros de búsqueda. Son reglas que impiden al sistema tratar cualquier texto lingüísticamente similar como pertinente para la pregunta. ¿Quién aprueba las fuentes? La expresión «fuentes aprobadas» no debe quedar en la vaguedad. Necesitamos saber:

• ¿Quién seleccionó la fuente?
• ¿Qué tipo de autoridad tiene?
• ¿Es una fuente científica, reguladora o comercial?
• ¿Cuándo se publicó o actualizó?
• ¿Sigue en vigor?
• ¿Para qué región, cultivo y sistema de producción es aplicable?
• ¿Qué afirmaciones puede respaldar?
• ¿Qué no puede inferirse de ella?

Un artículo científico puede ayudar a comprender un fenómeno o un hallazgo de investigación, pero no establece el registro legal de un producto. Y las instrucciones oficiales de uso fijan las condiciones de un producto registrado, pero no prueban por sí solas un efecto económico general. Y un precio publicado en un mercado oficial puede ser correcto para ese mercado y esa fecha, pero no equivale necesariamente a lo que recibe un agricultor de otra región después del transporte y la comisión. Así pues, la autoridad de una fuente varía según la pregunta. Tres capas no siempre bastan Es útil que una respuesta distinga entre lo que dicen las fuentes, lo que ha inferido el sistema y lo que requiere una decisión humana. Pero en las decisiones agrícolas sensibles es preferible presentar cinco capas: 1\. Lo que el sistema entendió de la pregunta Por ejemplo: He entendido que preguntas por la causa de unas manchas aparecidas en las hojas de un cultivo concreto en un estado fenológico determinado. Esto da al usuario la oportunidad de corregir esa comprensión antes de que se construya la respuesta. 2\. Lo que dicen las fuentes Se presenta la afirmación respaldada por la fuente, junto con el nombre, la fecha y el alcance de esta. 3\. Lo que el sistema ha ensamblado a partir de varias informaciones Si el sistema combina más de una fuente o infiere una relación, debe declarar que se trata de una formulación o comparación propia, no de una cita directa. 4\. Lo que sigue siendo desconocido Como la falta de una imagen clara, la ausencia de un análisis, el desconocimiento del país o la no comprobación de si el documento sigue vigente. 5\. Lo que requiere una decisión humana o una autoridad competente Como el diagnóstico final, la elección de una sustancia regulada, la aprobación de la dosis o la ejecución de una intervención que pueda dañar al cultivo o a las personas. Esto impide que la información respaldada se confunda con la inferencia automatizada o con el juicio profesional. La cita no es un adorno El usuario debería poder examinar la cita y comprender su relación con la respuesta. Una buena cita deja claro:

• El nombre del documento o del organismo emisor.
• La fecha de emisión o de la última actualización.
• La parte que se utilizó.
• El alcance del documento.
• Si es oficial, científico o comercial.
• Si el sistema reprodujo el texto, lo resumió o lo combinó con otra fuente.

Colocar un enlace general después de un párrafo largo no muestra qué frase respalda la fuente. Puede dar a la respuesta una apariencia de documentación sin permitir al lector rastrear la afirmación. Regla: no basta con que la fuente exista; debe ser pertinente para la pregunta, debe respaldar la frase, y los límites de la frase deben permanecer dentro de los límites de la fuente. ¿Qué hace el sistema cuando no encuentra respaldo suficiente? La abstención no es un fracaso del diálogo. El sistema puede seguir ayudando al usuario sin inventar una respuesta. Podría decir:

• No encuentro una fuente válida para este producto en el país indicado.
• El documento disponible está obsoleto y no basta para establecer la dosis.
• La imagen no permite distinguir las causas posibles.
• La pregunta requiere el nombre del cultivo, el estado fenológico y la ubicación.
• Hay información general, pero no es suficiente para una recomendación de tratamiento.
• Se requiere un examen por un especialista o un análisis antes de elegir la intervención.

Después ofrece un siguiente paso seguro:

• Solicitar una imagen adicional.
• Especificar la ubicación.
• Dar el nombre del producto exactamente como aparece en el envase.
• Comprobar la situación registral.
• Consultar las instrucciones oficiales de uso vigentes.
• Ponerse en contacto con el servicio de extensión agraria o con un especialista cualificado.

De este modo, la abstención no se convierte en un callejón sin salida, sino en una vía clara para completar la evidencia. Ejemplo de un proceder irresponsable El usuario pregunta: «Han aparecido manchas en mi cultivo; ¿qué debo usar?» El sistema responde directamente: «Use el producto X a tal dosis». Esta respuesta es irresponsable porque pasa de una descripción general a una sustancia y una dosis sin conocer:

• El cultivo.
• El país.
• El diagnóstico.
• El estado fenológico.
• La situación registral.
• Las instrucciones oficiales de uso.
• El plazo de seguridad.
• Si existen otras causas de los síntomas.
• La capacidad del usuario para aplicar el tratamiento con seguridad.

La redacción puede ser lingüísticamente correcta y, sin embargo, carecer de fundamento para la decisión. Ejemplo de una respuesta responsable La respuesta podría ser: «La información actual no basta para determinar la causa de las manchas ni para elegir un tratamiento. Estos síntomas pueden solaparse entre enfermedad, carencia de nutrientes, estrés hídrico y daño relacionado con la meteorología. Indica el nombre del cultivo y la variedad, si la conoces, el país o la región, el estado fenológico y dónde aparecen los síntomas en la planta, y envía una imagen nítida del haz y del envés de la hoja, así como una imagen que muestre hasta qué punto está extendido el problema en el campo. Podré entonces comparar los síntomas con fuentes apropiadas y exponer las posibilidades y la información que falta, pero especificar un producto o una dosis exige verificar el diagnóstico, el registro del producto para el cultivo y la plaga en el país de uso y las instrucciones oficiales de uso vigentes, y puede requerir la consulta a un especialista». Esta respuesta no se limita a abstenerse; más bien:

• Explica por qué la información es insuficiente.
• Muestra que es posible más de una interpretación.
• Solicita datos concretos.
• Aclara lo que el sistema puede hacer.
• Identifica lo que requiere una fuente oficial o un especialista.
• Impide que la fluidez lingüística se convierta en una autoridad terapéutica injustificada.

Otro ejemplo: una pregunta sobre el precio Si un agricultor pregunta: «¿A cuánto está hoy el precio de mi cultivo?», no basta con que el sistema recupere una cifra que incluya el nombre del cultivo. Debe conocer:

• El país, la región y el mercado.
• La fecha del precio, y la hora si es necesario.
• La moneda.
• La unidad de venta.
• La variedad.
• La categoría de calidad.
• Si el precio es mayorista, minorista o en origen.
• Si incluye transporte o comisión.
• ¿Qué entidad lo publicó?

Y una respuesta responsable no dice: «El precio es tal». Más bien dice, por ejemplo: «He encontrado un precio publicado en el mercado indicado en tal fecha, para la unidad y la categoría mencionadas. El precio que percibe el agricultor puede variar según la calidad, el transporte y la comisión, y no he verificado ninguna transacción local en tu explotación». Esto deja claro que la recuperación devolvió información concreta de un mercado, no el «precio real» en todas partes. La propia traducción requiere gobernanza Puede utilizarse un modelo de lenguaje para traducir la etiqueta de un producto o una orientación agrícola. Pero una traducción fluida puede ocultar un error en:

• La unidad de medida.
• La negación.
• El plazo de espera.
• El nombre de la plaga.
• El cultivo registrado.
• El grado de obligatoriedad.
• La advertencia.
• La jurisdicción legal.

Por ello, una traducción automática de un documento de seguridad no debería convertirse en una autoridad alternativa al texto oficial. El sistema puede ayudar a la comprensión, pero debe conservarse la referencia original, mostrarse su fuente y su versión, y revisarse la terminología sensible antes de la aplicación. ¿Cómo evaluamos el sistema? No basta con valorar la calidad estilística o la satisfacción del usuario. Hay que probar cada paso de la cadena: Comprensión de la pregunta

• ¿Identificó el sistema el cultivo, la ubicación y el sentido pretendido?
• ¿Solicitó la información que faltaba?

Recuperación

• ¿Encontró la fuente apropiada?
• ¿Excluyó una fuente obsoleta o no local?
• ¿Recuperó la parte que responde a la pregunta?

Redacción

• ¿Se atuvo la respuesta a lo que afirma la fuente?
• ¿Añadió alguna afirmación sin respaldo?
• ¿Preservó las restricciones y la incertidumbre?

Referenciación

• ¿Puede el lector acceder a la fuente?
• ¿Respalda realmente la fuente la frase?
• ¿Se muestran la fecha y el estado del documento?

Seguridad

• ¿Se abstuvo el sistema de facilitar una dosis o un diagnóstico cuando la evidencia era insuficiente?
• ¿Dejó claro cuándo debía consultarse a un especialista o a una autoridad reguladora?
• ¿Impidió que la información general se convirtiera en una instrucción ejecutable?

Aplicación agrícola

• ¿Es válida la respuesta para el cultivo, la ubicación y el momento?
• ¿Puede el usuario comprenderla y llevarla a cabo?
• ¿Permaneció clara la responsabilidad humana?

El sistema puede lograr encontrar un documento correcto y luego fallar al interpretarlo. Puede formular una respuesta fiel a un pasaje inadecuado. Puede aportar una referencia auténtica para una frase que la fuente no respalda. Por ello hay que evaluar toda la cadena, no el modelo de forma aislada. Para el lector avanzado: la recuperación reduce la dependencia del modelo respecto de lo que aprendió previamente, pero desplaza parte del riesgo hacia la calidad del índice, la comprensión de la pregunta, la ordenación de los resultados, la validez del documento y una generación disciplinada. Por esa razón, el éxito de la cadena no se mide por la mera presencia de una fuente en la respuesta, sino por la solidez de la relación entre la pregunta, la fuente, la afirmación, el contexto y la decisión. El papel del capítulo siete Puede mantenerse la referencia al capítulo siete, pero es mejor aclarar qué aportará: El capítulo siete abordará con mayor detalle cómo construir sistemas de apoyo a la toma de decisiones y de recuperación de conocimiento, organizar las fuentes, acotar la búsqueda por contexto, mostrar las referencias e impedir que el texto recuperado se convierta en una recomendación que exceda su autoridad. Esto da a la referencia una función clara, en lugar de dejarla como una mera promesa de información futura. Conclusión Un modelo de lenguaje puede facilitar el acceso al conocimiento: convierte una pregunta cotidiana en una búsqueda, reúne pasajes, los resume y formula una respuesta inteligible. Pero la fluidez lingüística no acorta el camino científico y regulatorio que media entre la pregunta y la decisión. Por tanto, un sistema responsable debe saber:

• Qué entendió de la pregunta.
• Qué información le falta.
• Dónde buscó.
• Por qué eligió la fuente.
• Si la fuente está vigente y es válida para el contexto.
• Qué tomó de la fuente.
• Qué infirió.
• Dónde termina su papel.
• Y cuándo debe abstenerse o elevar la decisión a un ser humano.

El mensaje de la sección puede resumirse en el siguiente enunciado: Un modelo de lenguaje puede ser una puerta de acceso al conocimiento, pero no se convierte en fuente por el mero hecho de hablar con fluidez, ni se convierte en decisor por el mero hecho de haber encontrado un texto próximo a la pregunta. El enunciado de cierre propuesto es: Una respuesta fiable no se limita a parecer correcta; revela su fuente, los límites de su aplicabilidad, lo que falta y quién tiene la autoridad para convertirla en acción.

9. Inteligencia artificial explicable

Cuando el sistema produce una salida, surge una pregunta natural: ¿Por qué produjo esta salida? El modelo puede predecir una caída del rendimiento, elevar el nivel de sospecha de una enfermedad, emitir una alerta sobre estrés hídrico o clasificar un fruto dentro de una categoría de calidad concreta. Pero la salida por sí sola no dice al usuario en qué información se basó el sistema, ni si esa información era completa o fiable. Las herramientas de inteligencia artificial explicable tratan de ayudar al usuario a comprender la relación entre los datos suministrados al modelo y la salida que produjo. Pueden mostrar, por ejemplo:

• que una humedad baja del suelo figuraba entre los factores asociados a una estimación más alta del riesgo de estrés.
• que la temperatura prevista afectó a la necesidad de riego estimada.
• que el cultivar y el estado fenológico aparecieron entre los factores asociados a la predicción del rendimiento.
• que una parte concreta de la imagen de la hoja se asoció con su clasificación como sospechosa.
• que la ausencia de una lectura de sensor, o un cambio en ella, afectó a la confianza del sistema.
• que la salida estaba próxima al umbral que separa dos clases.

Pero estas herramientas no responden a todos los sentidos de la palabra «por qué». Suelen explicar por qué el modelo produjo esta salida según sus cálculos, pero no establecen necesariamente por qué ocurrió el fenómeno en el campo. Dentro de la palabra «por qué» se esconden tres preguntas distintas Cuando el usuario pregunta «¿por qué?», puede referirse a una de tres preguntas: 1\. ¿Por qué produjo el modelo esta salida? Es una pregunta sobre el comportamiento del modelo. La respuesta podría ser: El modelo elevó la estimación de riesgo porque la lectura de humedad descendió, la temperatura prevista subió y no llegó ninguna lectura reciente de uno de los sensores. Esta respuesta muestra qué información utilizó el modelo. 2\. ¿Por qué ocurrió el fenómeno agrícola? Es una pregunta sobre la realidad agrícola. Una respuesta posible podría ser: Quizá la humedad descendió porque aumentó la demanda de agua, o porque el riego no llegaba correctamente a ese sector, o por un problema del suelo, o por un error del sensor. Una herramienta de interpretación del modelo, por sí sola, no puede determinar cuál de estas causas es la correcta. Que el modelo utilizara la lectura de humedad no prueba la causa de su descenso, ni prueba que la planta esté realmente sometida a estrés. 3\. ¿Por qué deberíamos emprender esta acción? Es una pregunta sobre la decisión. Aunque la alerta del modelo sea razonable, de ello no se sigue automáticamente que la acción correcta sea aumentar el riego. El sensor puede estar averiado, puede esperarse lluvia, el problema puede radicar en que el agua llega solo a una zona limitada, o el estado del cultivo puede diferir del que supuso el sistema. Así pues, debe distinguirse entre: explicar la salida del modelo ← explicar la situación agrícola ← justificar la acción Y pasar de un nivel al siguiente exige datos y evidencia adicionales. ¿A quién va dirigida la explicación? No hay una explicación única que sirva para todos los usuarios. Cada parte necesita un nivel distinto. El desarrollador quiere saber:

• ¿Se basó el modelo en datos válidos?
• ¿Aprendió un atajo incorrecto?
• ¿Se centró en el fondo de la imagen en lugar de en la planta?
• ¿Cambió su comportamiento tras la actualización de los datos?
• ¿Es estable la salida ante un cambio leve de la entrada?

El especialista agrícola quiere saber:

• ¿Tienen sentido agronómico los factores utilizados por el modelo?
• ¿Ha pasado por alto una variable importante?
• ¿Ha confundido una relación estadística con una causa agrícola?
• ¿Es plausible el resultado para este cultivar, esta campaña y esta ubicación?
• ¿Qué medición o análisis podría confirmarlo o refutarlo?

El agricultor o el operador necesita una respuesta práctica:

• ¿Qué ha dicho el sistema?
• ¿En qué información se basó el resultado?
• ¿Es esta información actual y fiable?
• ¿Qué no sabe el sistema?
• ¿Cuál es el siguiente paso seguro?

El revisor o la autoridad responsable necesita un registro auditable:

• ¿Cuál es la versión del modelo?
• ¿Qué datos estaban disponibles en el momento de la decisión?
• ¿Qué reglas o límites se aplicaron?
• ¿Anuló una persona el resultado? ¿Por qué?
• ¿Estaba la fuente o el sensor en condiciones válidas en ese momento?

La visualización adecuada para el investigador o el desarrollador puede no resultar útil al trabajador que necesita actuar en cuestión de minutos. Por ello, la explicación debe diseñarse para la persona y para la decisión, no solo en función de lo que la herramienta puede mostrar. Dos tipos de explicación Pueden distinguirse dos niveles principales: Explicación de un caso concreto Trata de responder a la pregunta: ¿Por qué dio el sistema este resultado ahora, para esta imagen o esta parcela? Puede mostrar que la humedad del suelo y la temperatura fueron los dos factores más estrechamente asociados a una alerta determinada, o que una parte de la imagen de la hoja se asoció con su clasificación. Esta explicación es útil para revisar un caso concreto, pero no describe necesariamente el comportamiento del modelo en todos los casos. Explicación del comportamiento general del modelo Trata de responder a preguntas como:

• ¿En qué tipos de información suele basarse el modelo?
• ¿Aumenta o disminuye la predicción del rendimiento a medida que cambia una variable determinada?
• ¿Difiere su comportamiento entre cultivares o regiones?
• ¿Qué variables aparecen con frecuencia entre los factores influyentes?
• ¿Se debilita cuando falta cierto tipo de datos?

Este nivel ayuda a comprender el modelo a lo largo de un gran conjunto de casos, pero por sí solo no explica una decisión individual. El modelo puede basarse en general en la meteorología y el suelo, mientras que el resultado para una parcela concreta pudo verse afectado principalmente por una lectura inusual de un único sensor. Por ello, la explicación general no debe utilizarse en lugar de la explicación del caso, ni a la inversa. ¿Qué formas puede adoptar la explicación? Hay múltiples maneras de presentar una explicación, y cada una tiene su propio significado y sus propios límites. 1\. Mostrar los factores asociados al resultado El sistema puede mostrar una lista como:

• Humedad baja del suelo: aumentó la estimación de riesgo.
• Temperatura prevista alta: aumentó la estimación.
• Probabilidad de lluvia: redujo la estimación.
• Sin lectura reciente: redujo la confianza.

Esta lista muestra cómo manejó el modelo la información, pero no prueba que estos factores causaran la situación agrícola. 2\. Resaltar parte de la imagen Una herramienta de explicabilidad puede colorear partes de la imagen de la hoja para mostrar las zonas más estrechamente asociadas al resultado. Esto puede ayudar a revelar que el modelo se centró en:

• La mancha pertinente.
• El borde de la hoja.
• El fondo de la imagen.
• Una etiqueta colocada junto a la planta.
• Una sombra o un reflejo sin relación con la afección.

Pero la zona coloreada no significa que el modelo «viera la enfermedad» como lo haría un especialista, ni prueba que la parte resaltada causara la clasificación. Es un indicio de una relación computacional dentro del modelo que exige una interpretación prudente. 3\. Comparar el resultado con un caso similar El sistema puede decir: Este caso se parece a ejemplos anteriores clasificados en la misma categoría. La comparación ayuda al usuario a ver la base de la semejanza. Pero el usuario debería saber:

• ¿Están documentados los ejemplos anteriores?
• ¿Procedían de un cultivo, un cultivar y un entorno similares?
• ¿Está la semejanza en los síntomas o en el fondo y la iluminación?
• ¿Hay ejemplos similares que condujeron a un resultado distinto?

4\. Indicar qué habría cambiado el resultado La herramienta puede decir: Si la lectura de humedad hubiera sido más alta en el cálculo del modelo, la estimación de riesgo habría sido menor. Esto muestra la sensibilidad del modelo a un cambio en la entrada, pero no prueba que aumentar realmente la humedad evitaría el riesgo en el campo. Describe un cambio en el cálculo del modelo, no el efecto de una intervención agrícola real. También aquí aparece la diferencia entre: ¿Qué cambia el resultado del modelo? y: ¿Qué cambia la realidad agrícola? La interpretación puede ser una aproximación, no una revelación completa Algunos modelos son relativamente simples y su método de cálculo puede rastrearse directamente. Con algunos modelos complejos, sin embargo, se emplea otra herramienta después de producirse el resultado para tratar de aproximar las razones que hay detrás. En el segundo caso, la interpretación no es una ventana completa a todo lo ocurrido dentro del modelo. Puede ser una simplificación o una aproximación de su comportamiento. Por ello, la propia interpretación debería someterse a prueba:

• ¿Cambia mucho si los datos cambian solo ligeramente?
• ¿Da interpretaciones similares para resultados contradictorios?
• ¿Refleja realmente lo que el modelo utilizó?
• ¿Puede distinguir un factor importante de otro que simplemente está asociado a él?
• ¿Se mantuvo estable la interpretación después de actualizar el modelo?

Así, si la lista de los «factores más importantes» cambia radicalmente tras una leve modificación que no altera el resultado, la interpretación puede ser inestable, aunque el gráfico parezca convincente. Factores asociados entre sí Los datos pueden contener variables que se mueven juntas, como:

• La temperatura y la evaporación.
• La estación y la duración del día.
• El tipo de suelo y el drenaje.
• El tamaño de la explotación y el tipo de equipamiento.
• La experiencia y la calidad del registro de datos.

Cuando las variables están fuertemente correlacionadas, la herramienta de explicabilidad puede repartir la importancia entre ellas de distintas maneras. Una puede aparecer cerca de la cabecera aunque la otra contenga información similar. Por ello, la ordenación de los factores no debe leerse como una ordenación fija de causas agrícolas. Un especialista puede necesitar examinar las relaciones entre ellos, y si el modelo está usando uno como sustituto del otro. Los límites básicos de la explicabilidad La explicabilidad tiene límites que deben permanecer visibles:

• Describe lo que el modelo utilizó, y no establece necesariamente qué causó el fenómeno en el campo.
• Puede ser una aproximación del comportamiento del modelo, no una descripción completa de cómo calcula.
• No convierte un modelo erróneo en uno correcto.
• No suple unos datos insuficientes ni unas mediciones corrompidas.
• No prueba que los datos de entrenamiento representen la nueva explotación.
• No prueba que las probabilidades estén calibradas ni que el resultado sea exacto.
• No justifica automáticamente la acción propuesta.
• Puede parecer convincente incluso cuando el caso queda fuera del rango de lo que el modelo ha aprendido.
• Puede cambiar si se emplea una herramienta de explicabilidad distinta.
• Puede ocultar la inestabilidad tras un gráfico claro y atractivo.

La explicabilidad es, pues, una herramienta de escrutinio y de rendición de cuentas, no un certificado de validación. La explicabilidad no corrige los errores de los datos Supongamos que un sensor de humedad del suelo no envió una lectura reciente, de modo que el sistema utilizó la última lectura almacenada, de seis horas antes. Una herramienta de explicabilidad puede mostrar que la humedad fue un factor importante en el resultado, pero no vuelve actual la lectura antigua. Del mismo modo, si las imágenes de entrenamiento no representan un cultivar o una región determinados, el sistema puede explicar el resultado para la nueva imagen, pero esa explicación no prueba que el modelo sea válido para ese entorno. La explicabilidad debería presentar la calidad de los datos junto con su efecto, como:

• La hora de la última lectura.
• La presencia de valores ausentes.
• El estado de calibración del sensor.
• La fuente de los datos.
• Hasta qué punto se parece el caso a los datos de entrenamiento.
• Si el resultado cae dentro del rango en el que se probó el modelo.

Un factor influyente no es útil si su propio valor no es fiable. La explicabilidad no demuestra causalidad Si el sistema muestra que la humedad fue un factor influyente en la predicción del rendimiento, eso significa que el modelo utilizó información de humedad al calcular el resultado. Pero no demuestra que cambiar solo la humedad vaya a cambiar el rendimiento en la misma medida. La humedad puede estar asociada a otros factores, como:

• El tipo de suelo.
• El sistema de riego.
• La meteorología.
• El estado fenológico.
• El manejo de la parcela.
• La variedad.

Para determinar el efecto de una intervención concreta, necesitamos un experimento o un diseño causal, junto con el conocimiento agronómico adecuado, como explicó la sección anterior. Una regla clave: la explicabilidad del modelo nos dice cómo cambió su cálculo, no cómo cambiará necesariamente la parcela si alteramos una de las entradas. Límites de la inferencia a partir del estudio de predicción del rendimiento El estudio de predicción del rendimiento [SRC006] ofrece un ejemplo del uso de modelos de regresión con herramientas que ayudan a interpretar sus resultados dentro de un entorno de investigación específico. El estudio puede utilizarse para comprender:

• El tipo de datos introducidos en los modelos.
• El método de predicción utilizado en el estudio.
• Cómo se aplicaron las herramientas de explicabilidad en ese entorno.
• Los resultados comunicados por los investigadores dentro de los límites de sus datos y del diseño de su estudio.

Pero la ordenación de las variables o su importancia en el estudio no debe convertirse en una regla causal general para cada explotación. Si una variable concreta parece influyente en la predicción del modelo, eso no demuestra:

• que sea la causa principal del rendimiento en todos los entornos.
• que cambiar esta variable vaya a producir el mismo efecto en otra parcela.
• que la ordenación de los factores vaya a permanecer estable en otra variedad u otra campaña.
• que el modelo sea adecuado para formular una recomendación de intervención directa.
• que el resultado computacional implique un impacto económico o de campo general.

La conclusión admisible permanece dentro de los límites del estudio y del entorno de evaluación que utilizó. ¿Qué necesita el agricultor de la explicación? Una explicación útil para el agricultor no empieza con un diagrama técnico ni con una larga lista de variables. Más bien responde a seis preguntas:

1. ¿Cuál es el resultado?

¿Qué dijo exactamente el sistema?

2. ¿En qué información se basó?

¿Qué lecturas, imágenes o registros influyeron en el resultado?

3. ¿Cuál es el estado de esta información?

¿Es reciente, completa y calibrada, o hay alguna lectura antigua o ausente?

4. ¿Cuál es el grado de incertidumbre?

¿Es el resultado claro, próximo al umbral, o queda fuera del rango de experiencia del modelo?

5. ¿Qué no establece la explicación?

¿Es el resultado un aviso preliminar, un diagnóstico o meramente una predicción?

6. ¿Cuál es el siguiente paso seguro?

¿Qué medición, inspección o revisión se requiere antes de cambiar la decisión?

De este modo, la explicación se convierte en una herramienta de trabajo, no en una exhibición técnica desligada de la decisión. Reformulación del ejemplo En lugar de decir: «El riesgo de estrés hídrico aumentó porque la humedad de la capa superficial descendió a lo largo de tres días y la temperatura prevista subió...» —una formulación que puede entenderse como prueba causal—, podemos decir: «El sistema elevó su estimación de la probabilidad de estrés hídrico porque la lectura de humedad de la capa superficial descendió durante los últimos tres días, y porque las previsiones de temperatura aumentaron. Pero el sensor del sector 4 no ha enviado una lectura nueva desde hace seis horas, de modo que la estimación puede estar basada en datos incompletos. Antes de ajustar el calendario de riego, inspeccione el sensor, tome una medición independiente del sector y compare el resultado con un sector vecino en condiciones similares». Esta formulación deja claro:

• que lo que se discute es la estimación del modelo, no una causa confirmada.
• qué datos influyeron en la estimación.
• que una de las entradas de datos está incompleta.
• cómo afecta esa carencia a la confianza.
• cuál es el siguiente paso.
• que ajustar el riego no se ha convertido en una orden automática.

Un ejemplo a partir de la imagen de una hoja El sistema puede decir: «El modelo clasificó la imagen como caso sospechoso, y el resultado se asoció principalmente con las manchas cercanas al borde de la hoja. Pero la imagen no muestra el envés, y el modelo no distinguió con confianza entre una posible enfermedad y una carencia de nutrientes. Envíe una imagen más nítida de ambas caras e indique dónde aparecen los síntomas en la planta y cómo se distribuyen en la parcela antes de pasar a un diagnóstico o a un tratamiento». Esta explicación es mejor que un mapa de colores por sí solo, porque muestra:

• Dónde se centró el modelo.
• Qué posibilidades se solapan.
• Qué información falta.
• Cuál es el siguiente paso.
• Que la clasificación no es un diagnóstico definitivo.

Un ejemplo a partir de la predicción del rendimiento El sistema puede decir: «El rendimiento predicho quedó por debajo de la media histórica de esta parcela. Dentro del modelo, los factores más fuertemente asociados a la predicción más baja son la siembra tardía, la escasa humedad del suelo durante un periodo determinado y unas temperaturas previstas más altas. Pero el registro no contiene información completa sobre el tratamiento más reciente, y el modelo no ha sido probado en esta parcela durante una campaña extremadamente calurosa. Por tanto, el resultado debe tratarse como un escenario de planificación, no como un valor garantizado». Esta redacción impide que la explicación se convierta en:

• Una causa confirmada.
• Una promesa de rendimiento.
• Una recomendación de intervención.
• Una generalización más allá del alcance de las pruebas.

¿Cuándo es insuficiente la explicación? No debe confiarse en la explicación por sí sola cuando:

• Faltan datos críticos o están desactualizados.
• El caso queda fuera de los cultivos o variedades sobre los que se probó el modelo.
• El resultado está próximo al umbral de decisión.
• Varios sensores discrepan.
• El error potencial guarda relación con la seguridad humana o animal.
• La decisión conduce a una dosis o a una sustancia regulada.
• El sistema controla una máquina en movimiento.
• El usuario no puede inspeccionar la explicación ni su fuente.
• La explicación cambia radicalmente con una ligera variación de los datos.
• Existe una brecha entre lo que el modelo explica y lo que la decisión necesita establecer.

En estos casos, la explicación debe conducir a la inspección o a la derivación, no meramente a una mayor confianza. Preguntas prácticas para evaluar la explicación El lector o el comprador puede preguntar:

• ¿Explica el sistema el resultado de un caso concreto, o su comportamiento general?
• ¿Deja claro en qué datos se basó, y de qué fecha son?
• ¿Muestra los datos ausentes o poco fiables?
• ¿Es la explicación una descripción directa del modelo, o una aproximación producida por otra herramienta?
• ¿Cambia la explicación con una ligera variación de la entrada?
• ¿Ha examinado el desarrollador la posibilidad de que el modelo se esté apoyando en el fondo de la imagen o en el dispositivo?
• ¿Distingue el sistema entre correlación y causalidad?
• ¿Deja claro el rango de cultivos, ubicaciones y campañas en los que fue probado?
• ¿Puede el usuario entender la explicación sin conocimientos de programación?
• ¿Conduce la explicación a un paso seguro y ejecutable?
• ¿Puede una persona impugnar el resultado o anularlo?
• ¿Se conservaron los datos y la versión que produjeron la explicación para una revisión posterior?

Para el lector avanzado: la explicación debe evaluarse por su fidelidad al representar el comportamiento del modelo, por su estabilidad ante pequeños cambios, por su grado de comprensibilidad y por su adecuación al usuario y a la decisión. Un modelo más simple y más claro puede ser mejor para una decisión sensible que un modelo que obtiene una puntuación ligeramente superior en una métrica de laboratorio pero requiere una explicación aproximada inestable. Conclusión La inteligencia artificial explicable no hace al modelo consciente de sus razones, no convierte una relación estadística en una causa agronómica y no confiere legitimidad automática a la decisión. Su mejor papel es ayudarnos a preguntar:

• ¿Qué información utilizó el modelo?
• ¿Era esa información exacta y estaba actualizada?
• ¿Se centró en lo que se suponía que debía centrarse?
• ¿Qué dejó fuera de consideración?
• ¿Cuáles son los límites de su confianza?
• ¿Y qué debería verificarse antes de actuar?

El mensaje de la sección puede resumirse en la siguiente frase: Una buena explicación no se limita a decirnos por qué salió el número que salió; revela los datos que lo produjeron, los límites que lo condicionan y el paso que impide convertirlo en una decisión ciega.

10. El sistema agrícola inteligente es un sistema integrado, no un modelo aislado

Cuando decimos que una explotación utiliza un «modelo de riego inteligente» o un «sistema inteligente de detección de enfermedades», el lector puede imaginar un único programa que recibe los datos y a continuación emite la decisión. Pero los sistemas agrícolas útiles no suelen funcionar de esa manera simplificada. Se parecen más a una cadena interconectada: comienza midiendo lo que ocurre en la parcela, pasa por la comprobación y el análisis de los datos y su comparación con las restricciones agronómicas, y termina presentando una recomendación a una persona o ejecutando una acción automatizada dentro de límites determinados. Por esta razón se describe como un sistema híbrido: no se apoya en un único tipo de inteligencia artificial, y no deja la decisión en manos de un modelo aislado. Más bien combina sensores, modelos entrenados con datos, reglas establecidas por expertos, herramientas para elegir entre alternativas, equipos y la persona responsable de la decisión. Este sistema integrado puede constar de las siguientes capas:

1. Recogida de información:

La cadena empieza con un sensor que mide la humedad o la temperatura del suelo, o con una imagen captada por un teléfono o un dron, o con un registro en el que el trabajador anota lo que ocurrió en la parcela. Esta capa no proporciona una decisión; más bien transmite una descripción parcial de la realidad, que puede ser exacta o incompleta, o estar afectada por un fallo del dispositivo o por el método de medición.

2. Comprobación de la calidad de los datos:

Antes de que el sistema utilice una lectura, comprueba si es plausible. Si un sensor de humedad informa de un salto brusco que no concuerda con la precipitación o el riego, o un dispositivo deja de transmitir, o algunas lecturas llegan en una unidad distinta, esos valores no deben pasar al resto del sistema como si fueran hechos fiables. El sistema puede excluirlos, rebajar su confianza en ellos o solicitar que se inspeccione el dispositivo.

3. Formación de una estimación o una previsión:

Un modelo analítico utiliza los datos disponibles para estimar una condición que no puede medirse directamente, o para prever lo que puede ocurrir más adelante. Puede estimar la probabilidad de que una planta esté enferma a partir de una imagen, prever los cambios de humedad del suelo en las próximas horas o estimar el volumen de demanda de agua del día siguiente. Este resultado sigue siendo una estimación, gobernada por la calidad de los datos y por los límites de lo que el modelo ha aprendido.

4. Aplicación de reglas agronómicas y regulatorias:

No todo resultado predicho se convierte en una recomendación automática. Puede haber una regla que impida regar cuando la velocidad del viento supera cierto umbral, o que impida sugerir una sustancia no registrada para el cultivo o la región, o que exija derivar el caso a un especialista cuando el diagnóstico no es concluyente. Estas reglas no se aprenden necesariamente de los datos; se establecen para proteger el cultivo, al trabajador y al medio ambiente, y para cumplir las instrucciones oficiales.

5. Ponderación de las alternativas disponibles:

Si se dispone de varios planes posibles, el sistema utiliza una herramienta computacional para compararlos y elegir el plan más adecuado dentro de las restricciones. Puede, por ejemplo, tratar de distribuir una cantidad limitada de agua entre múltiples sectores teniendo en cuenta las necesidades del cultivo, la capacidad de la bomba, las horas de funcionamiento y el coste energético. Aquí, «más adecuado» no significa que exista una solución ideal absoluta; significa la mejor solución dados el objetivo y las restricciones introducidas en el sistema.

6. Presentación del resultado, su fundamento y sus límites:

La interfaz debería dejar claro al usuario qué está proponiendo el sistema, en qué datos se basó, cuánta confianza tiene y qué restricciones o lecturas ausentes pueden afectar al resultado. Una tabla que dice «Ejecutar riego durante dos horas» es menos útil y menos segura que una pantalla que especifica el sector en cuestión, el motivo de la recomendación, el momento de la medición, el estado de los sensores y si el plan requiere aprobación.

7. Revisión o ejecución:

En algunos sistemas, el agricultor o el supervisor revisa la recomendación antes de que se ejecute. En otros sistemas, pueden enviarse órdenes automáticamente a bombas o válvulas, pero dentro de límites de funcionamiento y de seguridad fijados de antemano. Las personas deben conservar la autoridad para detener el sistema o anular su decisión cuando adviertan algo que los datos no captan.

Consideremos el ejemplo del riego. El proceso puede comenzar con lecturas de humedad del suelo, datos meteorológicos y el estado fenológico del cultivo. El sistema comprueba primero las lecturas para asegurarse de que los sensores funcionan y de que las unidades de medida son correctas. A continuación utiliza un modelo que sigue los cambios de humedad a lo largo del tiempo para prever la necesidad de agua de cada sector durante el día siguiente. Pero esa previsión por sí sola no determina el plan de riego. Las reglas agronómicas pueden añadir restricciones que impidan aportar más agua en un suelo mal drenado, o que den prioridad a un cultivo que atraviesa un estado fenológico sensible. Después, un programa de planificación compara las alternativas posibles y reparte la capacidad de bombeo y el tiempo de funcionamiento entre los distintos sectores. Antes de la ejecución, la capa de seguridad comprueba que no hay conflicto entre los sensores, y que la presión de la red y el estado de las válvulas permiten el plan. Luego presenta el resultado al operador para su aprobación, o lo ejecuta automáticamente si queda dentro de los límites permitidos. En este ejemplo, la «inteligencia artificial» no tomó la decisión por sí sola. El modelo proporcionó una previsión, las reglas impusieron restricciones, la herramienta de planificación eligió entre las alternativas, la capa de seguridad revisó si la ejecución era viable y el operador siguió siendo responsable de la decisión final. Describir todo el sistema como un «modelo de riego con IA» oculta, por tanto, partes esenciales de su funcionamiento y dificulta determinar dónde se produjo el error y quién es responsable de él. Un modelo puede ser exacto mientras el sistema falla en otra etapa. Algunos ejemplos son los siguientes:

• Un sensor envía una lectura en una unidad distinta de la que el sistema espera.
• La previsión se apoya en datos antiguos que llegaron después de que pasara la ventana de decisión.
• Un resultado correspondiente al sector oriental se vincula a la válvula del sector occidental.
• La herramienta de planificación elige un plan computacionalmente correcto pero que excede la capacidad real de la bomba.
• La interfaz muestra un número sin indicar el momento de la medición ni el grado de confianza en él.
• El sistema envía una orden correcta, pero la válvula no la ejecuta y no devuelve una señal que confirme su estado.
• La decisión se ejecuta automáticamente sin dar al operador un medio claro de detenerla.

Una revisión sobre la digitalización agrícola describe una ruta interconectada que comienza con la detección, pasa por los datos, el contexto y la toma de decisiones, y termina con la acción en el mundo real [SRC035]. La importancia de esta concepción radica en que la calidad de cada etapa depende de lo que le llega de la etapa anterior, y en que un pequeño error puede amplificarse a medida que avanza por la cadena. Si la lectura de humedad es errónea, puede producir una previsión errónea. Si la previsión es correcta pero se envía demasiado tarde, el plan puede resultar inadecuado en el momento de ejecutarse. Si el plan es correcto pero se dirige a la válvula equivocada, un sector que no necesitaba agua puede resultar dañado mientras el sector que sí la necesitaba queda sin regar. Por eso, comprobar las conexiones entre los componentes del sistema puede ser más importante que lograr un ligero aumento en la exactitud del propio algoritmo. Para el lector que busca profundidad: No basta con evaluar el modelo al margen del sistema en el que opera. El error debería rastrearse desde la primera medición hasta el impacto final en el campo: ¿qué magnitud tiene el error del sensor? ¿Cómo se trataron los valores ausentes? ¿Llegó la previsión a tiempo? ¿Cómo se convirtió en una regla de decisión? ¿Tuvo en cuenta la herramienta de planificación las restricciones reales? ¿Se ejecutó la orden en el equipo previsto? ¿Y qué impacto agronómico resultó de ello? Un modelo determinado puede parecer mejor en las pruebas computacionales, mientras que un sistema que utiliza un modelo más simple puede ser más fiable por la calidad de sus datos, la claridad de sus reglas y la solidez de sus capas de seguridad. No toda capa del sistema debería volverse «inteligente» por el mero hecho de que sea técnicamente posible. En algunos lugares, una regla fija es más clara, más fácil de probar y más segura que un modelo aprendido. Impedir que una máquina funcione cuando una protección de seguridad está abierta no requiere un modelo que prediga si el funcionamiento es peligroso; requiere una regla explícita que no deba poder anularse. Por el contrario, el aprendizaje puede ser útil para analizar una imagen compleja o anticipar un cambio difícil de describir con un conjunto sencillo de reglas. La ingeniería madura no empieza con la pregunta «¿dónde podemos añadir inteligencia artificial?». Más bien empieza con preguntas más precisas:

• ¿Qué parte del problema necesita aprender de los datos?
• ¿Qué parte requiere una regla agronómica o regulatoria explícita?
• ¿Qué decisiones pueden ejecutarse automáticamente y cuáles requieren aprobación humana?
• ¿Dónde podrían fallar las conexiones entre los componentes?
• ¿Cómo sabe el usuario que los datos están incompletos o que la ejecución no se produjo según lo previsto?
• ¿Quién tiene autoridad para detener el sistema y anularlo cuando surge una situación inesperada?

La regla rectora: La calidad de un sistema agrícola no se mide por el modelo más inteligente que contiene, sino por la seguridad de toda la cadena, desde la primera lectura en la parcela hasta la acción final que allí se ejecuta.

11. Una guía preliminar para vincular la tarea, el método y la verificación

El método adecuado no empieza por el nombre del algoritmo, sino por la pregunta que queremos responder y la acción que puede basarse en esa respuesta. La misma imagen puede servir de entrada para clasificar el estado de una hoja, localizar una mala hierba o medir la superficie del daño, pero cada una de estas tareas requiere datos de referencia distintos, produce una salida distinta y se evalúa con métricas distintas. La siguiente guía no es una receta automática para elegir un algoritmo, ni significa que todo problema agrícola pertenezca a una única categoría. Es un mapa preliminar que ayuda al lector a conectar seis cosas:

1. Tarea: ¿Qué pregunta agronómica queremos responder?
2. Datos: ¿Qué información se necesita para responderla?
3. Familia de métodos: ¿Qué tipo de análisis puede abordar la pregunta?
4. Salida: ¿Qué resultado debería proporcionar el sistema?
5. Métrica de rendimiento: ¿Cómo sabemos que el resultado es útil, y no que simplemente tiene buen aspecto?
6. Pregunta de seguridad y verificación: ¿Qué debe comprobarse antes de convertir el resultado en una decisión o una acción?

La respuesta a estas preguntas no es completa hasta que se hayan especificado el cultivo, el entorno, el momento de la decisión, el coste del error y la capacidad de respuesta del usuario. 1\. Clasificar el estado de una hoja a partir de una imagen Tarea: Determinar qué clase se corresponde mejor con la imagen de la hoja, como sana, afectada por una condición concreta, o indeterminada. Datos necesarios: Imágenes diversas de tejido sano y de condiciones enfermas, cada una vinculada a una clase de referencia verificada por un experto o a una prueba fiable. No basta con que las imágenes sean meramente numerosas; también deben representar la variación en variedades, estados fenológicos, iluminación, dispositivos de captura y gravedad de los síntomas. Familia de métodos: Modelos de clasificación de imágenes. Salida prevista: El nombre de la condición más probable y una puntuación de confianza, con la posibilidad de que el sistema diga «indeterminado» o solicite una imagen adicional cuando la evidencia sea insuficiente. ¿Qué medimos? No basta con una tasa global de acierto. Deberíamos medir la capacidad del sistema para detectar cada condición importante, el número de casos que pasa por alto, el número de falsas alertas y los casos que confunde entre sí. Pregunta de seguridad y verificación: ¿Qué hace el sistema si se encuentra con una enfermedad que no ha aprendido, con síntomas derivados de más de una causa o con una imagen de mala calidad? ¿Deriva los casos poco claros a un especialista, o los fuerza hacia una de las clases conocidas? 2\. Localizar una mala hierba con vistas a su tratamiento Tarea: Detectar la mala hierba en la imagen y determinar su ubicación con precisión suficiente para dirigir hacia ella a un trabajador o a una máquina. Datos necesarios: Imágenes o secuencias de vídeo que muestren las ubicaciones de las malas hierbas y del cultivo, con anotaciones de referencia de sus posiciones. Si el sistema ha de guiar una máquina, también necesita información de calibración que vincule la posición del objeto en la imagen con su posición real delante del apero. Familia de métodos: El trabajo empieza con la detección de objetos o la delimitación de sus contornos dentro de la imagen; después el resultado pasa a un sistema de control que determina el movimiento del apero. Salida prevista: La ubicación de la mala hierba, sus contornos y la puntuación de confianza de su detección, seguidos de unas coordenadas que la máquina pueda utilizar a tiempo. ¿Qué medimos? Medimos qué malas hierbas se detectaron y cuáles se pasaron por alto, la exactitud de su localización, la rapidez con que llega el resultado y el número de plantas del cultivo dañadas durante la ejecución. Pregunta de seguridad y verificación: ¿Se detiene el apero si el sistema pierde confianza, si una persona o un animal entra en la zona de trabajo, o si resulta imposible distinguir la mala hierba del cultivo? ¿Y se ha probado toda la cadena, desde la cámara hasta el movimiento del apero, y no solo el modelo de imagen? 3\. Predicción del rendimiento Tarea: Estimar la cantidad de cosecha que se espera recolectar en una superficie determinada. Datos necesarios: Mediciones de rendimiento anteriores, y datos sobre meteorología, suelo, variedad, estado fenológico y prácticas agrícolas, indicando con claridad la fuente de cada valor y su unidad de medida. Familia de métodos: Modelos de regresión, o modelos que estudian cómo cambian los datos a lo largo del tiempo; pueden añadirse modelos espaciales si las condiciones difieren dentro de la parcela o entre regiones. Salida prevista: Una estimación de rendimiento en una unidad inteligible, como kilogramos por hectárea, acompañada de un intervalo que muestre el grado de incertidumbre en lugar de una cifra única que sugiera una precisión falsa. ¿Qué medimos? El error se mide en la misma unidad que el rendimiento, comprobando además si los intervalos de confianza declarados concuerdan con los resultados reales. Si el sistema dice que es probable que el rendimiento caiga dentro de un determinado intervalo, deberíamos comprobar con qué frecuencia ocurre eso realmente. Pregunta de seguridad y verificación: ¿Se ha probado el modelo en explotaciones, campañas o regiones que no formaron parte de su entrenamiento? ¿Y entiende el usuario que la predicción se basa en condiciones pasadas que pueden no representar una campaña excepcional o una variedad nueva? 4\. Preparar un calendario de riego Tarea: Determinar cuándo deben regarse los sectores y cuánta agua debe recibir cada sector, teniendo en cuenta las necesidades del cultivo y la capacidad de la red de riego. Datos necesarios: Humedad del suelo, meteorología, estado fenológico del cultivo, propiedades del suelo, fuentes de agua, capacidad de bombeo, estado de las válvulas, y restricciones temporales y operativas. Familia de métodos: El sistema puede combinar un modelo que prediga las necesidades hídricas, reglas agronómicas que impidan decisiones inseguras y un programa de planificación que compare alternativas y asigne los recursos disponibles. Salida prevista: Un calendario ejecutable que especifique el sector, el momento, la cantidad y la duración de funcionamiento, junto con un plan alternativo por si el agua escasea o falla algún equipo. ¿Qué medimos? El éxito no se mide solo por la reducción del consumo de agua, sino también por el estado de la planta, el rendimiento, el uso de energía, la uniformidad de la distribución, el momento de la aportación de agua y si el plan puede ejecutarse con el equipo disponible. Pregunta de seguridad y verificación: ¿Qué ocurre cuando se interrumpen los datos o falla uno de los sensores? ¿Pasa el sistema a modo manual o a un plan de contingencia seguro, o sigue emitiendo órdenes basándose en información incompleta? 5\. Emitir una alerta sobre el estado de un animal Tarea: Detectar un cambio que pueda indicar enfermedad, lesión o una alteración del movimiento o la alimentación. Datos necesarios: Los datos pueden ser sonidos, imágenes, secuencias de vídeo o lecturas de actividad, temperatura e ingesta de alimento. Deberían vincularse, en la medida de lo posible, a casos revisados por un veterinario u otro especialista. Familia de métodos: Detección de casos inusuales cuando no disponemos de una definición completa de cada enfermedad, o clasificación cuando contamos con casos documentados de los que el sistema pueda aprender. Salida prevista: Una alerta que identifique al animal, el momento y el motivo de preocupación, con las alertas ordenadas por prioridad. ¿Qué medimos? El número de casos importantes que el sistema no logró detectar, el número de falsas alertas por animal o por día, y el intervalo entre el inicio del cambio y la emisión de la alerta. Pregunta de seguridad y verificación: ¿Quién confirma profesionalmente el estado antes del tratamiento? ¿Y cuántas alertas puede examinar realmente el equipo? Un sistema que envía cientos de alertas sin ordenar puede ocultar el caso peligroso entre el ruido. 6\. Estimar la superficie de los síntomas y seguir su propagación Tarea: Medir la superficie afectada en la planta o la parcela, y determinar después si los síntomas se expanden o remiten con el tiempo. Datos necesarios: Imágenes o mapas secuenciales captados en momentos distintos, junto con información sobre la ubicación, la altura, el ángulo y las condiciones de iluminación de la captura, de modo que pueda hacerse una comparación justa. Familia de métodos: Delimitar los contornos de los tejidos o las zonas afectadas dentro de la imagen, y analizar después cómo cambian a lo largo de distintos momentos temporales. Salida prevista: Una superficie estimada o un porcentaje de daño, la dirección y la velocidad del cambio, junto con una indicación del grado de confianza en la comparación. ¿Qué medimos? El error en la estimación de la superficie, la estabilidad del resultado cuando se repite la captura de imágenes, y la capacidad del sistema para seguir la misma zona de un momento a otro. Pregunta de seguridad y verificación: ¿Aumentó realmente el daño, o cambiaron la luz, el ángulo de captura o la altura de la cámara, haciendo que la superficie pareciera mayor o menor? ¿Y se están comparando las imágenes sobre la base de un único patrón de referencia? 7\. Proporcionar una respuesta de asesoramiento Tarea: Responder a una pregunta agronómica en lenguaje claro, apoyándose en fuentes autorizadas apropiadas al contexto del usuario. Datos necesarios: La pregunta del usuario, información sobre el cultivo, la ubicación, el estado fenológico y la situación, junto con fuentes fiables y actualizadas que el sistema pueda consultar. Familia de métodos: Búsqueda en fuentes autorizadas y recuperación de los pasajes pertinentes, y uso después de un modelo de lenguaje para formular la respuesta, con reglas que impidan afirmaciones o recomendaciones no respaldadas por la evidencia. Salida prevista: Una respuesta que distinga entre información general y recomendación cualificada, cite sus fuentes y solicite información adicional o se abstenga de responder cuando la evidencia sea insuficiente. ¿Qué medimos? ¿Respaldan las fuentes las afirmaciones hechas en la respuesta? ¿Son las referencias exactas y verificables? ¿Es la respuesta apropiada al cultivo, la ubicación y el momento, y puede el usuario entender el siguiente paso sin verse empujado hacia una acción insegura? Pregunta de seguridad y verificación: ¿Se abstiene el sistema de inventar una dosis, una sustancia, un registro oficial o un precio no documentados? ¿Deja claro que la autorización de un producto o sus condiciones de uso deben verificarse consultando la etiqueta aprobada y vigente del producto y la normativa local? 8\. Asignar un recurso limitado Tarea: Distribuir una cantidad limitada de agua, fertilizante, mano de obra o tiempo de máquina entre múltiples parcelas o sectores. Datos necesarios: La magnitud de la demanda, los recursos disponibles, las prioridades, las restricciones técnicas y temporales, y las previsiones relativas al rendimiento, el coste o el retorno. Familia de métodos: Planificación matemática y contrapartidas entre alternativas, conocidas en los campos especializados como optimización e investigación operativa. Estos métodos buscan un plan que alcance el objetivo en la mayor medida posible sin incumplir las restricciones especificadas. Salida prevista: Un plan ejecutable, junto con una declaración de lo que recibe cada parte y de qué cambia si varían las prioridades o el recurso escasea más. ¿Qué medimos? ¿Respetó el plan todas las restricciones? ¿Puede realmente ejecutarse? ¿Y cuál es su efecto sobre el coste, el rendimiento, el tiempo y la equidad entre sectores o beneficiarios? Pregunta de seguridad y verificación: ¿Quién determinó el objetivo que la herramienta trata de maximizar? ¿Y quién fijó las prioridades y el nivel mínimo aceptable para cada sector? Un plan puede ser matemáticamente correcto y, sin embargo, resultar injusto o agronómicamente inaceptable si el objetivo se reduce a una única cifra. 9\. Controlar una secuencia de acciones Tarea: Elegir una secuencia de acciones tras las cuales cambia el estado del sistema, como ajustar la ventilación y la calefacción en una estructura protegida, o guiar una máquina en movimiento entre las líneas de cultivo. Datos necesarios: Una descripción del estado actual, el conjunto de acciones posibles y datos sobre lo que ocurrió después de cada acción, junto con los límites de funcionamiento y de seguridad. Familia de métodos: El sistema puede utilizar control convencional basado en reglas y ecuaciones conocidas, aprendizaje por refuerzo que aprende una estrategia de selección de acciones a partir de simulación o experiencia, o una mezcla de ambos. Salida prevista: Una estrategia que determine la acción adecuada para cada estado, seguida de órdenes de funcionamiento claras para el equipo. En la terminología técnica, esta estrategia se denomina «política de selección de acciones». ¿Qué medimos? La estabilidad del sistema, la rapidez de su respuesta, el número de veces que se superan las restricciones, el consumo de recursos, los efectos de las acciones sobre la planta, el animal o el equipo, y su capacidad para afrontar condiciones inesperadas. Pregunta de seguridad y verificación: ¿Qué límites no está autorizado a superar el sistema, sea cual sea el objetivo? ¿Quién tiene autoridad para detenerlo? ¿Y a qué estado seguro pasa el equipo si se pierde la comunicación, fallan los datos o la situación queda fuera del rango que se probó? Este mapa muestra que una sola tarea agrícola puede requerir más de un método, y que el éxito en cada etapa no garantiza el éxito de la cadena en su conjunto. Identificar la ubicación de la mala hierba no basta si la máquina no puede alcanzarla con seguridad; predecir la demanda de agua no basta si el plan de riego excede la capacidad de la bomba; y recuperar una fuente correcta no basta si corresponde a otro cultivo, otro país u otra fecha. También muestra que la métrica técnica y la pregunta de seguridad no son asuntos separados. La métrica indica lo bien que rinde el sistema en las pruebas, mientras que la pregunta de seguridad indica lo que puede ocurrir cuando el sistema se equivoca en el campo. Un algoritmo puede lograr un resultado medio alto mientras su error infrecuente recae en el caso de mayor riesgo. Para el lector que busca profundidad: La elección del método empieza por la formulación de la decisión y del coste de los distintos patrones de error, no por la comparación de los nombres de los modelos. El método adecuado puede cambiar si cambia la salida prevista, aun cuando los datos sigan siendo los mismos. El sistema debería evaluarse además en tres niveles: la calidad de la estimación, la calidad de la conversión de esa estimación en una decisión, y la calidad de la ejecución de la decisión en la realidad. La mejora en el primer nivel no compensa el fracaso en los otros dos. Y al evaluar cualquier aplicación nueva, la matriz puede resumirse en las siguientes preguntas:

• ¿A qué pregunta agrícola concreta intenta responder el sistema?
• ¿Qué datos necesita, y quién verificó su exactitud?
• ¿Qué salida producirá, y en qué unidad o con qué grado de confianza?
• ¿Qué decisión o acción se basará en esa salida?
• ¿Qué tipo de error es más peligroso: un caso que el sistema pasa por alto o una alerta falsa?
• ¿Se ha probado el sistema en un entorno independiente que se asemeje a su escenario real de uso?
• ¿Qué ocurre cuando los datos están incompletos o el caso es desconocido?
• ¿Quién revisa el resultado, y quién tiene la autoridad para detenerlo o anularlo?

El principio general: un método no se elige porque sea el más nuevo o el más famoso, sino porque produce la salida que la decisión requiere, puede verificarse con la métrica adecuada y sigue siendo seguro cuando los datos están incompletos o el resultado es erróneo.

12. ¿Cómo comparamos modelos y sistemas? De la exactitud en las pruebas al valor en el campo

Cuando un desarrollador o una empresa presenta un sistema nuevo, la primera pregunta suele ser: ¿Qué exactitud tiene? Es una pregunta legítima, pero no basta para juzgar su utilidad. Dos sistemas pueden obtener la misma puntuación en una prueba de laboratorio y, sin embargo, diferir mucho en los tipos de errores que cometen, en su velocidad de respuesta, en su coste de operación, en su capacidad de funcionar en el campo y en la magnitud del daño que puede producirse cuando se equivocan. Imaginemos dos modelos que alcanzan, cada uno, una puntuación global del 92% en la clasificación de imágenes de hojas. El primero puede ser bueno detectando los casos sanos y, en cambio, pasar por alto las fases tempranas de una enfermedad peligrosa. El segundo puede detectar la mayoría de los casos enfermos, pero generar tantas alertas falsas que el usuario pierda la confianza en él. La puntuación global parece la misma, pero el valor de ambos modelos en la explotación no lo es. El modelo en sí puede ser bueno, mientras que el sistema que lo contiene sigue siendo débil. El modelo puede analizar la imagen correctamente, pero la aplicación la comprime hasta perder detalle, o retrasa el envío del resultado, o lo muestra sin indicar el nivel de confianza, o lo vincula a una recomendación que no es adecuada para la región. Necesitamos, por tanto, distinguir entre tres cosas:

• Rendimiento del modelo: la calidad de la estimación o la clasificación que produce.
• Rendimiento del sistema: el funcionamiento de toda la cadena, desde la recogida de datos hasta la presentación del resultado o la ejecución de la acción.
• Impacto agrícola: si el uso del sistema ha mejorado realmente la decisión y el resultado en la explotación.

Una comparación solo es justa y útil si aborda los siguientes niveles. A. Empezar por lo que hacemos ahora: la línea de base de la comparación La línea de base es el método que usamos como punto de referencia antes de introducir el nuevo sistema. Dicho de forma más sencilla, no preguntamos solo: «¿Funciona el modelo?», sino también: ¿Funciona mejor que lo que hacemos hoy, y lo suficiente para justificar el coste del cambio? La línea de base puede ser:

• una inspección realizada por un especialista o por un agente de extensión agraria.
• una regla sencilla ideada por un experto local.
• el rendimiento medio de campañas anteriores.
• el supuesto de que la lectura de mañana será próxima a la de hoy.
• un calendario de riego fijo calibrado a las condiciones locales.
• el sistema digital anterior al que el nuevo pretende sustituir.

Así pues, si el objetivo es predecir el rendimiento, el modelo puede compararse con el rendimiento medio de la parcela en campañas anteriores. Si el objetivo es detectar una enfermedad a partir de una imagen, puede compararse con el rendimiento de la inspección actual, dejando claro si esa inspección la realiza un agricultor, un técnico o un especialista. Si el objetivo es gestionar el riego, puede compararse con el calendario en uso en términos de agua, energía, estado de la planta y rendimiento. No debe elegirse deliberadamente un método de referencia débil solo para que el nuevo modelo parezca superior. Un sistema complejo puede superar a una regla ingenua y, sin embargo, no superar la experiencia del agricultor ni un sistema sencillo calibrado localmente. En ese caso, la ganancia técnica es limitada y puede no justificar el coste de equipos, conectividad, mantenimiento y formación. Tampoco debe limitarse la comparación a la pregunta: «¿Quién obtuvo el número más alto?». Debe incluir además:

• la magnitud de la mejora respecto al método actual.
• la consistencia de esa mejora entre parcelas y campañas.
• los tipos de errores que disminuyeron o aumentaron.
• el coste de lograr la mejora.
• la medida en que el usuario puede beneficiarse realmente de ella.

El significado práctico de la línea de base: primero determinamos el nivel de rendimiento que tenemos sin el nuevo sistema, y después comprobamos si el sistema aporta un valor real por encima de él. B. Hacer que la prueba se acerque a las condiciones reales de uso Un modelo aprende de un conjunto de ejemplos llamado datos de entrenamiento. Una vez completado el aprendizaje, debe probarse con ejemplos independientes que no haya utilizado antes. El objetivo no es averiguar hasta qué punto recuerda los ejemplos anteriores, sino si es capaz de manejar casos nuevos parecidos a los que encontrará en la explotación. Si el sistema se va a usar en varias parcelas, la prueba debe incluir parcelas que no formaron parte del entrenamiento. Si va a operar en campañas distintas, no basta con probarlo con imágenes de la misma campaña. Si los usuarios toman fotografías con teléfonos de calidad variable, no es válido evaluarlo por completo con imágenes captadas por una sola cámara en condiciones ideales. Una división aleatoria de los datos puede dar una impresión engañosa. Si se toman diez imágenes similares de la misma planta y luego algunas se destinan al entrenamiento y las otras a la prueba, el modelo puede reconocer la planta, el fondo o las condiciones de captura, en lugar de los signos agrícolas que queremos que aprenda. Una prueba más sólida separa, según la naturaleza de la tarea, entre:

• plantas distintas.
• parcelas o campos distintos.
• explotaciones o regiones distintas.
• campañas o años distintos.
• variedades y estados de desarrollo distintos.
• dispositivos de captura o tipos de sensor distintos.
• lenguas o dialectos distintos, y distintas formulaciones de las preguntas en los sistemas conversacionales.

Esto no significa que toda prueba deba abarcar el mundo entero, sino que debe representar fielmente el entorno en el que se pretende usar el sistema. Si el sistema se probó en un entorno limitado, deben declararse esos límites, en lugar de presentar su resultado como si fuera válido para todo cultivo, explotación y campaña. Los modelos candidatos deben someterse asimismo a la misma prueba, en las mismas condiciones y con los mismos datos. La comparación no es justa si uno se prueba con imágenes limpias mientras otro se prueba con imágenes difíciles de campo, o si uno se mide en un dispositivo rápido y el otro en un teléfono de baja potencia. El significado práctico de la prueba independiente: ponemos el sistema ante casos nuevos que reflejan la realidad de su uso y observamos después si mantiene su rendimiento cuando desaparecen las comodidades del laboratorio. C. Vincular la métrica a la consecuencia del error No todos los errores son iguales. Un sistema puede equivocarse al lanzar una alerta sobre una infección que no existe, o al tratar como sana una planta infectada. Ambos son errores, pero sus consecuencias pueden diferir. Una alerta falsa puede hacer perder tiempo de inspección, motivar un análisis adicional o irritar al usuario. Pasar por alto una infección grave, en cambio, puede retrasar la intervención hasta que el daño se extienda. En otra aplicación, como el manejo de una máquina, una alerta falsa puede ser menos peligrosa que un movimiento incorrecto que dañe el cultivo o al trabajador. Por lo tanto, la media global no debe ocultar el tipo de error más importante. Una comparación debería preguntar:

• ¿Cuántos casos peligrosos pasó por alto el sistema?
• ¿Cuántas alertas falsas emitió?
• ¿En qué variedades o estados de desarrollo son más frecuentes los errores?
• ¿Se equivoca más en los casos tempranos que en los evidentes?
• ¿Cuál es el coste de cada tipo de error?
• ¿Puede el equipo gestionar el número de alertas resultante?

Y si la tarea consiste en predecir un número, el error debe expresarse en una unidad que quien decide pueda comprender. En vez de decir que «el error medio es 0.12» sin más explicación, puede decirse que la predicción de rendimiento se desvía en promedio en un determinado número de kilogramos o toneladas por hectárea. Cuando se planifican además el almacenamiento o el transporte, debe aclararse si los habituales errores pequeños encubren un número reducido de errores grandes capaces de trastocar todo el plan. Tampoco basta con que la diferencia entre dos modelos se manifieste en un solo número. La ventaja puede ser tan leve que podría invertirse si repitiéramos la prueba en otra campaña o con otra muestra. Por ello conviene observar la magnitud de la variación entre pruebas, y no solo el mejor resultado aislado. El significado práctico de la métrica: elegimos el método de medición en función de la decisión que se verá afectada por el resultado, y traducimos el error a un efecto que el agricultor, el especialista o el responsable de operaciones pueda comprender. D. Probar cómo expresa el sistema la incertidumbre, y cuándo se abstiene de emitir un juicio El modelo no posee el mismo grado de conocimiento en todos los casos. La imagen puede ser nítida y parecida a aquello de lo que aprendió, o puede ser oscura, incompleta o corresponder a un caso que no ha visto antes. Las lecturas de los sensores pueden ser completas y coherentes, o pueden faltar algunas mientras las demás se contradicen. Esta variación se denomina incertidumbre: la evidencia disponible no respalda todos los resultados en el mismo grado. El sistema puede expresarlo de varias maneras, entre ellas:

• Mostrar una puntuación de confianza en lugar de emitir un juicio categórico.
• Presentar varias posibilidades ordenadas.
• Mostrar un intervalo esperado en lugar de un único número.
• Señalar los datos ausentes o contradictorios.
• Solicitar una imagen, una lectura o un dato adicional.
• Derivar el caso a un especialista cuando la evidencia es insuficiente.

En la predicción del rendimiento, decir que el rendimiento esperado se sitúa entre 4.2 y 5.1 toneladas por hectárea puede ser más honesto y más útil que dar una cifra única de 4.7 toneladas, sobre todo si los datos meteorológicos futuros son inestables. En el diagnóstico de una imagen de hoja, puede ser más apropiado que el sistema diga que la imagen es insuficiente para distinguir entre dos causas, y que solicite después una imagen del envés de la hoja. Pero la puntuación de confianza que muestra el modelo no es una verdad garantizada. Puede decir que tiene una confianza del 80% mientras sus resultados reales son mucho peores. Por eso se examina la calibración de la confianza: comprobar si los números de confianza se corresponden con la realidad. Si reunimos un gran número de casos a los que el sistema asignó una confianza en torno al 80%, sus resultados deberían ser correctos en una proporción próxima a esa, y no correctos solo en la mitad de ellos. Un caso fuera del alcance de lo que el sistema ha aprendido es aquel que difiere claramente de sus ejemplos de entrenamiento: una variedad nueva, una cámara distinta, una enfermedad no incluida en los datos, unas condiciones de iluminación marcadamente diferentes o una pregunta en una lengua con la que no se probó. El modelo puede responder con seguridad incluso en tales casos, y por eso debe probarse su capacidad de detectar que una entrada le resulta desconocida. La abstención significa que el sistema no se fuerza a emitir un diagnóstico o una recomendación cuando la evidencia es insuficiente. No es una parada aleatoria ni una señal de fracaso, sino un comportamiento intencionado, como decir: «La imagen actual no es suficiente para determinar la condición con seguridad. Tome una imagen más nítida del envés de la hoja e indique el cultivo y el estado de desarrollo, o derive el caso a un especialista». La propia abstención también debe evaluarse. Si el sistema se abstiene en la mayoría de los casos, puede parecer seguro y ser de escasa utilidad. Si no se abstiene nunca, puede dar respuestas confiadas en casos que desconoce. Lo que se necesita es un equilibrio adecuado a la gravedad de la tarea y a la capacidad del equipo para revisar los casos derivados. El significado práctico de la incertidumbre y la abstención: no preguntamos solo si el sistema respondió, sino si reconoció los límites de su evidencia, si pidió ayuda en el momento oportuno y si esa petición llegó a la persona capaz de darle seguimiento. E. Medir el rendimiento del sistema en operación, no solo en la demostración Un sistema puede funcionar bien en una breve demostración pública, o en un ordenador potente conectado a una red estable, y encontrar después dificultades al usarse día tras día en la explotación. Por ello, la comparación incluye aspectos que no aparecen en una cifra de exactitud, como:

• El tiempo entre la introducción de los datos y la aparición del resultado.
• La capacidad del sistema de funcionar en el teléfono o el dispositivo realmente disponible.
• El consumo de energía y el volumen de datos transmitidos.
• La necesidad de una conexión a internet continua.
• Qué ocurre cuando la red es débil o se corta el suministro eléctrico.
• El coste de cámaras, sensores, servidores y suscripciones.
• El tiempo necesario para instalar, calibrar y mantener los equipos.
• Con qué facilidad puede actualizarse el software sin interrumpir el trabajo.
• La claridad de la interfaz y la capacidad del usuario de comprender el resultado.
• La disponibilidad de soporte técnico y de piezas de repuesto.
• La capacidad de corregir un error o de volver a una forma manual de trabajar.

Un modelo que rinde algo menos en las pruebas de laboratorio puede ser más útil en el campo si funciona con rapidez en un teléfono disponible, presenta un resultado comprensible y sigue desempeñando sus funciones básicas cuando la conectividad es débil. A la inversa, el modelo más exacto puede resultar impracticable si exige un dispositivo caro, conectividad continua o un tiempo de respuesta superior a la ventana de intervención. Si un sistema de detección de malas hierbas envía el resultado cuando la máquina ya ha rebasado la posición de la mala hierba, de nada le sirve una alta exactitud de imagen. Si una alerta de enfermedad llega días después de captarse los datos, puede perder su valor aunque el diagnóstico sea correcto. El significado práctico del rendimiento operativo: un sistema útil es el que se adapta a las condiciones cotidianas de trabajo, no el que solo tiene éxito cuando se dan condiciones ideales de demostración. F. Vigilar las condiciones cambiantes y el deterioro del rendimiento tras la implantación Un buen resultado en el momento del lanzamiento del sistema no garantiza que vaya a mantenerse. Los entornos agrícolas cambian: aparecen variedades nuevas, se desplazan las fechas de siembra, se sustituyen cámaras y sensores, cambian las prácticas y puede propagarse una plaga o una condición no representada en los datos originales. Cuando la naturaleza de los datos que recibe el sistema cambia respecto a los datos con los que fue entrenado y probado, esto se denomina deriva de datos. La cuestión no es que los datos se desplacen literalmente, sino que las propiedades de la realidad que ve el sistema ya no son las que eran. Algunos ejemplos:

• Entrenar un modelo con imágenes de una cámara concreta y sustituirla después por una cámara con otros colores y otro procesamiento de imagen.
• Cambia la variedad cultivada, de modo que los síntomas se manifiestan de otro modo.
• Cambia el clima o el momento de la campaña, de modo que cambia la relación entre la meteorología y el rendimiento.
• Modificar el sistema de alimentación o de iluminación en un invernadero.
• Cambia el método de introducción de los registros, o los nombres de los campos en la aplicación.
• Aparecen preguntas y dialectos nuevos en el sistema conversacional de asesoramiento.

También puede ocurrir que los datos sigan siendo aparentemente similares mientras cambia la relación entre los datos y el resultado. Una temperatura determinada pudo asociarse con el estrés de la planta bajo un sistema de riego anterior, y esa relación cambió después de mejorar la ventilación o de instalar un nuevo sombreo. Por consiguiente, tras la implantación el sistema necesita una vigilancia que incluya:

• Comparar los datos nuevos con los datos con los que se probó.
• Registrar los casos inusuales o aquellos en los que la confianza ha disminuido.
• Revisar una muestra de resultados en el campo.
• Hacer seguimiento del número de alertas falsas y de casos no detectados.
• Definir un umbral que active una reevaluación.
• Especificar quién decide si se actualiza o se reentrena el modelo.
• Probar la nueva versión antes de aprobarla.
• Conservar la capacidad de volver a una versión anterior si aparece un problema.

El reentrenamiento no es una solución automática para todo deterioro; en los datos nuevos pueden colarse errores o resultados no documentados, y el sistema puede aprender de ellos y empeorar. Por esta razón, las actualizaciones deben pasar por revisión, prueba y aprobación. El significado práctico de la deriva de datos: lo que fue válido la campaña pasada puede no seguir siéndolo automáticamente en la campaña siguiente, de modo que el sistema necesita una vigilancia continua, no un certificado de éxito concedido de una vez por todas. G. Medir qué ocurrió después de que el resultado llegara al usuario La predicción puede mejorar sin que mejore el resultado agrícola. El sistema puede detectar la enfermedad de forma temprana, pero la alerta no llega a la persona adecuada. La alerta puede llegar, pero el usuario no la entiende. El usuario puede entenderla, pero no disponer del material, del trabajador o del tiempo necesarios para intervenir. El usuario puede ejecutar la recomendación, pero esta puede no ser adecuada a las condiciones de la parcela. Por esta razón, debe hacerse seguimiento de toda la cadena:

1. ¿Fue correcta la estimación del modelo?
2. ¿La convirtió el sistema en una alerta o recomendación clara?
3. ¿Llegó el resultado en el momento oportuno?
4. ¿Lo comprendió el usuario y confió en él?
5. ¿Cambió la decisión?
6. ¿Se ejecutó la decisión según lo previsto?
7. ¿Condujo la ejecución a un mejor resultado agrícola?

Estos niveles no significan lo mismo. La exactitud de la previsión de riego puede mejorar y, sin embargo, el consumo de agua no bajar porque la red tiene una fuga. El sistema puede detectar tempranamente una condición en un animal, pero el equipo no puede revisar las alertas hasta el final de la jornada. Puede sugerir un mejor reparto de la mano de obra, pero el plan no tiene en cuenta los desplazamientos entre parcelas. Al medir el impacto, debe considerarse más de un resultado. El sistema puede reducir el consumo de agua pero aumentar el uso de energía, o elevar el rendimiento pero incrementar el coste de los insumos, o reducir el trabajo manual pero aumentar la dependencia de un servicio externo difícil de reparar. No debe atribuirse al sistema cualquier cambio en el rendimiento o en el coste por el mero hecho de haber ocurrido después de usarlo; la causa puede ser una campaña mejor, un cambio de precios u otra práctica agrícola. Si se desea establecer que el sistema marcó una diferencia, puede ser necesaria una implantación por fases, la comparación de parcelas o periodos similares, o un diseño de campo adecuado que separe el efecto del sistema de otros factores. El significado práctico de medir el impacto: la evaluación no termina con saber si la respuesta fue correcta; continúa preguntando si la respuesta llegó, si cambió la decisión y si la decisión condujo a un mejor resultado en el mundo real. H. Revisar la equidad, la responsabilidad y la gobernanza El sistema puede alcanzar una buena media y, aun así, funcionar mejor para un grupo de usuarios o de explotaciones a costa de otro. Puede depender de una conectividad rápida no disponible en zonas remotas, o de un teléfono moderno que no todos los usuarios poseen, o de imágenes procedentes de explotaciones grandes y bien organizadas que no representan a las pequeñas, o de una lengua formal que no maneja bien las preguntas y los dialectos locales. Por ello, los resultados deben desglosarse, cuando proceda, por:

• Tamaño de la explotación y naturaleza de la producción.
• Región y condiciones climáticas.
• Variedad y estado de desarrollo.
• Tipo de dispositivo o sensor.
• Calidad de la conectividad.
• Lengua o dialecto.
• Experiencia del usuario y capacidad de usar la interfaz.

Equidad no significa que el sistema deba dar el mismo resultado a todo el mundo; significa más bien examinar si un grupo determinado soporta más errores, no puede acceder al servicio o carece de una vía para impugnar una decisión incorrecta. En cuanto a la gobernanza, designa las reglas y responsabilidades que rigen el sistema a lo largo de su ciclo de vida, entre ellas:

• ¿Quién autorizó su uso?
• ¿Quién revisa sus datos y su rendimiento?
• ¿Quién asume la responsabilidad por el error?
• ¿Puede el usuario objetar o solicitar una revisión humana?
• ¿Qué decisiones puede proponer o ejecutar el sistema?
• ¿Qué decisiones deben permanecer en manos de un especialista o de un organismo autorizado?
• ¿Cómo se conservan los registros y se respeta la privacidad?
• ¿Cómo se documentan los cambios y las versiones?
• ¿Quién tiene la autoridad para detener el sistema cuando surge un riesgo?

Estas preguntas cobran más importancia cuando el sistema afecta a la sanidad vegetal o animal, a la seguridad de los trabajadores, al uso del agua y de materias reguladas, o a la aceptación del producto en el mercado. Esta perspectiva se orienta por la idea de gestionar los riesgos de la inteligencia artificial a lo largo de las etapas de su ciclo de vida, desde el diseño y las pruebas hasta la operación, la vigilancia y la actualización [SRC033]. El significado práctico de la gobernanza: no basta con saber qué puede hacer el sistema; también debemos saber quién lo vigila, quién lo revisa y quién tiene la autoridad de decisión cuando se equivoca. Para el lector avanzado: Una comparación profesional no presenta un único número como veredicto final. Debe dejar claros el tamaño de la muestra de prueba, el grado de variación del resultado, el rendimiento en distintos grupos y entornos, su estabilidad en el tiempo y el coste de cada tipo de error. También deben mantenerse constantes las condiciones de comparación: los mismos datos, la misma definición de la tarea, el mismo umbral de alerta y el mismo entorno de operación. Un modelo puede resultar superior cuando se le permite enviar muchas alertas, mientras que otro puede resultar superior cuando el número de alertas se limita a lo que el equipo puede revisar. La comparación está siempre ligada, por tanto, a las condiciones de la decisión y a los recursos disponibles, no al rendimiento del algoritmo en abstracto. Una lista de verificación práctica para comparar cualquier sistema La comparación puede resumirse en ocho preguntas, pero conviene entender con claridad qué significa cada una:

1. ¿Qué decisión cambiará a causa del sistema?

¿Llevará la salida a una inspección adicional, al riego de un sector, al tratamiento de un animal, a la compra de un insumo o al manejo de una máquina? Si no sabemos qué decisión cambiará, no sabremos qué rendimiento se requiere.

2. ¿Con qué método actual se compara el sistema?

¿Supera a la experiencia del agricultor, a la inspección del especialista, a una regla sencilla o al sistema en uso? ¿Y cuánto valor añadido aporta?

3. ¿Se probó en un entorno independiente similar a aquel en el que se usará?

¿Incluyó la prueba parcelas, campañas, dispositivos, variedades y usuarios cuyos datos no se incluyeron en el entrenamiento?

4. ¿Qué error es más peligroso, y con qué frecuencia se produjo?

¿El mayor riesgo es pasar por alto el caso, emitir una falsa alarma, el retraso o dirigir la acción al lugar equivocado? ¿Y qué efecto tiene ese error en la explotación?

5. ¿Deja claros los límites de su conocimiento?

¿Presenta un nivel de confianza o un intervalo esperado? ¿Y solicita información adicional o deriva el caso a una persona cuando la evidencia es insuficiente?

6. ¿Cuál es el coste de operarlo y mantenerlo?

¿Qué dispositivos, conectividad, energía, formación, soporte y mantenimiento requiere? ¿Y qué ocurre en caso de interrupción o avería?

7. ¿Cómo detectamos que su rendimiento se ha deteriorado?

¿Quién vigila los resultados tras la implantación? ¿Qué señal indica la necesidad de volver a probar o de actualizar? ¿Y quién aprueba la nueva versión?

8. ¿Quién tiene la decisión final y la autoridad para detenerlo?

¿Sabe el usuario cuándo el resultado es orientativo? ¿Quién revisa los casos de alto riesgo? ¿Y puede detenerse la ejecución automática y devolverse el sistema a un modo seguro?

El principio general: Un modelo no es mejor por el mero hecho de que su número sea más alto; es mejor cuando supera a un método realista, aguanta en el entorno de uso, revela los límites de su conocimiento, opera dentro de los recursos disponibles, reduce el error más dañino y conduce, en última instancia, a una mejor decisión y a un mejor resultado en la explotación.

13. Un caso didáctico integrado: ¿cómo se convierte la imagen de una hoja en una decisión agrícola responsable?

El caso siguiente es un ejemplo instructivo que reúne los conceptos del capítulo en un único recorrido. No proporciona el diagnóstico de ninguna enfermedad concreta, ni describe un tratamiento, una sustancia o una dosis; muestra más bien cómo debería manejar un sistema responsable una información incompleta, y cómo pasa de una imagen inicial a una decisión cuyas razones y límites pueden examinarse. Un agricultor observó manchas amarillas y marrones en algunas hojas de una parte de la parcela. Tomó una fotografía con el teléfono, la envió a un sistema asistente y escribió: «¿Qué es este problema y qué debo usar para tratarlo?» La pregunta puede parecer sencilla, pero una respuesta responsable no empieza por el nombre de una enfermedad ni de una sustancia. Una sola imagen puede mostrar un síntoma —es decir, un cambio visible en el color o la forma de la hoja—, pero por sí misma no establece la causa del síntoma. En la imagen pueden parecerse los efectos de una enfermedad fúngica o bacteriana, una carencia de nutrientes, un estrés hídrico, una lesión química, una quemadura por sol, un daño por insectos, o más de un factor a la vez. Por esta razón, la imagen es el comienzo del recorrido de examen, no su final. Paso uno — Convertir la pregunta general en una pregunta que pueda examinarse El sistema no salta de la pregunta «¿Qué debo usar?» a proponer un tratamiento. Más bien reestructura la cuestión en preguntas más pequeñas:

• ¿Aparecen en la imagen signos claramente descriptibles?
• ¿En qué parte de la hoja se sitúan?
• ¿Es el patrón localizado o extendido?
• ¿Basta la imagen para distinguir entre algunas de las posibilidades?
• ¿Qué información falta antes de avanzar hacia un diagnóstico?
• ¿Hay algún signo que exija una revisión rápida por un especialista?

La primera respuesta del sistema podría ser, por ejemplo: «La imagen muestra zonas amarillas y marrones, pero la imagen por sí sola no basta para determinar la causa ni para elegir un tratamiento. Primero evaluaré la calidad de la imagen y después necesito información sobre el cultivo, la extensión de los síntomas y las condiciones del entorno». Esta apertura cumple una función importante: separa ver el síntoma de conocer su causa, e impide que el sistema convierta una semejanza visual en una certeza que no posee. Paso dos — Verificar que la imagen es apta para el análisis Antes de analizar las manchas, la aplicación examina la calidad de la propia imagen. Lo que parece un síntoma de enfermedad puede ser en realidad una sombra, un reflejo de luz, un artefacto de la compresión de la imagen o una parte desenfocada. El sistema comprueba, en la medida de lo posible, cuestiones como:

• ¿Está la hoja nítida o borrosa por el movimiento?
• ¿Es la iluminación lo bastante natural para mostrar el color real?
• ¿Se ve la zona afectada en primer plano?
• ¿Se ve la hoja entera, de modo que pueda determinarse la ubicación de los síntomas en ella?
• ¿Hay una imagen del haz y otra del envés?
• ¿Hay una imagen de la planta entera, y no solo de la hoja?
• ¿Hay un objeto de referencia que ayude a estimar el tamaño de la mancha?
• ¿Se tomó la imagen después de que la hoja se mojara o fuera rociada con algo que pudiera alterar su aspecto?

Al hablar de las «dos caras» se hace referencia a fotografiar el haz de la hoja y su envés, porque algunos signos pueden apreciarse con más claridad en una que en la otra. Si la imagen es insuficiente, el sistema no debería producir una respuesta segura por el mero hecho de que el usuario la esté esperando. Más bien explica qué falta y pide que se repita la toma, por ejemplo: «La imagen no es nítida en los márgenes de las manchas. Tome una imagen más cercana con luz natural, otra imagen del envés de la hoja, y añada después una imagen de la planta entera y de la parte afectada de la parcela». Este comportamiento no obstruye al usuario; más bien lo protege de un resultado basado en una entrada que no sostiene una inferencia fiable. Paso tres — Describir lo que ve la herramienta de visión, sin afirmar un diagnóstico Si la imagen es apta para el análisis, el sistema puede emplear un modelo de visión por computador para realizar una o varias tareas:

• Identificar zonas con alteración del color dentro de la imagen.
• Estimar la proporción de hoja afectada.
• Describir la forma de las manchas y su distribución aparente.
• Comparar el patrón con categorías que el modelo aprendió de imágenes anteriores.
• Detectar que la imagen no se parece lo suficiente a los casos con los que se probó.

La salida debe ser clara respecto a sus límites. Así, en lugar de que el sistema diga: «Esto es la enfermedad X». puede decir: «El sistema detectó manchas amarillas y marrones irregulares en partes del tejido foliar. Este aspecto es visualmente similar a más de una condición, y la imagen actual no basta para determinar la causa». El sistema puede además mostrar la zona de la imagen en la que se centró, de modo que el usuario o el especialista pueda verificar que analizó el tejido foliar afectado, y no el fondo o una sombra cercana. En cuanto a la expresión «categoría desconocida», no significa que el modelo haya descubierto una enfermedad llamada «desconocida». Lo que significa es que la imagen no coincide lo bastante con las categorías que el sistema aprendió a distinguir, o que su calidad no permite un juicio seguro. En tal caso, debería mostrar un resultado como:

• El caso no está representado entre las clases conocidas del sistema.
• La imagen es inadecuada para la comparación.
• Hay signos superpuestos que no permiten la clasificación.
• Se requiere un examen humano o información adicional.

Aquí aparece una distinción importante: el modelo puede ser capaz de localizar las manchas con exactitud sin ser capaz de determinar su causa. El éxito en la primera tarea visual no demuestra el éxito en el diagnóstico. Paso cuatro — Añadir el contexto de campo al contexto de la imagen Los síntomas de la planta no pueden separarse del cultivo, del entorno y del manejo. Por eso el sistema solicita información que podría cambiar la interpretación de la imagen, pero es mejor no abrumar al agricultor con decenas de preguntas de golpe. Empieza por las preguntas más útiles y después pide más detalle cuando es necesario. Puede preguntar primero:

• ¿Cuáles son el cultivo y la variedad, si se conoce?
• ¿Cuál es la edad de la planta o su estado fenológico?
• ¿Cuándo aparecieron los síntomas?
• ¿Están aumentando con rapidez o parecen estables?
• ¿Aparecen en una sola planta o en un grupo de plantas?
• ¿Se concentran en los bordes de la parcela, en rodales dispersos o a lo largo de las líneas de riego?
• ¿Comenzaron en las hojas más viejas o en las más nuevas?
• ¿Hay signos adicionales en el envés de la hoja?
• ¿Han aparecido síntomas en el tallo, el fruto o las raíces?
• ¿Ha habido un riego abundante, una interrupción del agua o una ola de calor o de frío?
• ¿Se ha utilizado algún insumo agrícola o ha cambiado el programa de fertilización recientemente?
• ¿Hay síntomas similares en un cultivo o una parcela vecinos?

Esta información no añade «detalles incidentales»; puede cambiar por completo el significado de la imagen. Una distribución de los síntomas a lo largo de una línea de riego puede orientar la investigación hacia el agua, las raíces o el equipo de riego, mientras que una propagación desde un foco hacia las plantas vecinas puede suscitar un conjunto distinto de posibilidades. Y su aparición en las hojas más viejas puede tener un significado diferente del que tendría si aparecieran primero en el crecimiento nuevo. El sistema debería distinguir también entre la información introducida por el usuario, la información medida por un sensor y una inferencia extraída de la imagen. No debería presentarlas todas como si fueran hechos de igual peso. Paso cinco — Ordenar las posibilidades en lugar de declarar una causa única Tras reunir la imagen y el contexto, el sistema puede ordenar las causas posibles. Aquí, ponderar significa comparar posibilidades a la luz de la evidencia disponible, no declarar que la causa mejor situada ha quedado establecida. Puede presentar el resultado de esta forma:

• Una posibilidad es coherente con la forma y la distribución de las manchas, pero le falta un signo que debería comprobarse en el envés de la hoja.
• Otra posibilidad se ve respaldada por las condiciones meteorológicas recientes, pero no explica por completo la localización de los síntomas.
• Una posibilidad relacionada con la nutrición o el riego exige revisar la distribución de los síntomas en la parcela y las mediciones de suelo o de agua.
• Otras causas son menos probables, pero siguen siendo posibles porque la información es incompleta.

Tampoco basta con presentar porcentajes desnudos, porque una cifra puede dar al lector una sensación de certeza mayor de la que permite la evidencia. El sistema debería dejar claro:

• ¿Qué evidencia elevó cada posibilidad?
• ¿Qué información la rebajó?
• ¿Qué datos faltan?
• ¿Qué siguiente pregunta o prueba distinguiría entre las posibilidades con mayor eficacia?
• ¿Se han probado en un cultivo y un entorno similares las puntuaciones de confianza que presenta?

En formulación técnica, el término capa probabilística designa la parte que reúne distintos elementos de prueba y reordena las posibilidades cuando llega información nueva. Pero esta parte no «conoce la verdad» por sí sola; más bien, organiza lo que los datos respaldan y lo que todavía no pueden resolver. Así, si el usuario añade una imagen del envés de la hoja, o una descripción de cómo se están propagando los síntomas, o el resultado de una prueba de campo o de laboratorio, la ordenación puede cambiar. Esto no es un signo de contradicción, sino un resultado natural de actualizar el juicio cuando llega una evidencia más sólida. Paso seis — Buscar en fuentes fiables adecuadas al contexto Tras estrechar las posibilidades, el sistema busca en fuentes de conocimiento aprobadas. Por fuentes gobernadas no se entienden unas páginas cualesquiera que una búsqueda encuentre por azar, sino un conjunto de documentos cuya fuente, fecha, ámbito de validez y estado de aprobación se han especificado. Estas pueden incluir, según la tarea y el país:

• Documentos de orientación emitidos por autoridades agrarias fiables.
• Referencias científicas o diagnósticas apropiadas para el cultivo.
• Boletines oficiales actualizados.
• Instrucciones emitidas por las autoridades reguladoras competentes.
• Las indicaciones oficiales de uso vigentes para los productos registrados localmente.
• Protocolos de muestreo o derivación a un laboratorio.

Una fuente no se vuelve apropiada por el mero hecho de ser correcta en sí misma. Puede haber sido emitida por otro país donde los productos registrados difieren, o puede referirse a una variedad distinta, o estar desfasada, o tratar una enfermedad con síntomas similares en otro cultivo. Por ello, el sistema debería hacer corresponder, en la medida de lo posible:

• El cultivo y la variedad.
• La ubicación, o el país y la región.
• La fecha y la versión del documento.
• El organismo emisor.
• El tipo de cultivo y el entorno.
• El estado fenológico del cultivo.
• La situación reglamentaria de la sustancia o del procedimiento.

El sistema debe presentar la fuente de un modo que el usuario o el especialista pueda examinar, especificando el título del documento, el organismo emisor, la fecha y la parte en la que se basó. También debe distinguir entre:

• Lo que se afirma explícitamente en la fuente.
• Lo que el sistema infirió combinando varias informaciones.
• Aquello para lo que no encontró apoyo suficiente.

Si no encuentra una fuente adecuada, la formulación responsable es: «No he encontrado, dentro del conjunto disponible de fuentes aprobadas, orientaciones recientes y apropiadas para este cultivo y esta región que justifiquen una recomendación concreta. Es necesario consultar a un especialista o a la autoridad agrícola local». No encontrar una fuente no es una laguna que el modelo deba rellenar con conjeturas; al contrario, es una información importante que debe mostrarse. Paso siete — Detener el salto inseguro de la probabilidad al tratamiento Una vez presentadas las probabilidades y las fuentes, entra en juego la barrera de seguridad. Con ello se entiende un conjunto de reglas y revisiones que impiden que el sistema convierta una semejanza visual o una probabilidad no resuelta en una instrucción directa de tratamiento. Deben distinguirse distintos niveles de salida:

1. Descripción general: ¿Qué aparece en la imagen y qué información falta?
2. Paso de verificación: ¿Cuál es la siguiente imagen, examen o información que se requiere?
3. Orientación preventiva general de bajo riesgo: Si está respaldada por una fuente apropiada y no presupone un diagnóstico no confirmado.
4. Diagnóstico profesional: Puede requerir un especialista o una prueba de referencia.
5. Selección de una sustancia, una dosis o un procedimiento regulado: Está supeditada al diagnóstico, al registro local, a las instrucciones oficiales de uso vigentes del producto y a la autoridad de la persona facultada para tomar la decisión.

La presencia del nombre de una enfermedad en la lista de probabilidades no justifica pasar automáticamente al nombre de una sustancia. Tampoco la presencia de una sustancia mencionada en una fuente antigua o emitida por otro país acredita que esté registrada para el cultivo y la región, ni que su uso sea apropiado para el caso. La barrera de seguridad puede determinar que la salida correcta sea:

• Una solicitud de imágenes o información adicionales.
• Una sugerencia de inspeccionar el resto de la planta y del campo.
• La derivación del caso a un especialista agrícola.
• Seguir las instrucciones del especialista al remitir una muestra para su análisis.
• La verificación con la autoridad reguladora competente del país o la región.
• Abstenerse de proponer una sustancia o una dosis porque el diagnóstico o la fuente son insuficientes.
• Emitir una alerta urgente si los indicadores disponibles exigen una intervención profesional rápida, indicando el motivo de la alerta sin afirmar un diagnóstico definitivo.

El sistema no debería conformarse con una frase general como «consulte a un experto» cada vez, porque eso lo vuelve de utilidad limitada. Es preferible que explique por qué el asunto requiere un especialista, qué información conviene preparar y qué pregunta debe resolver el especialista. Paso octavo — Tomar la decisión, documentar lo ocurrido y hacer seguimiento del resultado Una vez presentada la evidencia y sus límites, la decisión sigue correspondiendo al agricultor o al especialista autorizado, según el tipo de actuación y su nivel de riesgo. El resultado puede ser una solicitud de examen adicional, el seguimiento del caso durante un periodo determinado, la realización de una prueba o la ejecución de una intervención aprobada por el especialista conforme a los requisitos locales. El sistema registra, con el consentimiento del usuario y conforme a las normas de privacidad, elementos como:

• Las imágenes y la información en que se basó el análisis.
• El momento en que se emitió el resultado.
• Las probabilidades presentadas y los niveles de confianza.
• Las fuentes recuperadas y sus versiones.
• Los datos que faltaban.
• Las advertencias o los motivos para abstenerse.
• La decisión tomada por el usuario o el especialista.
• Lo que se llevó a cabo realmente.
• Cualesquiera resultados o cambios posteriores que hayan surgido.

La retroalimentación es la información que vuelve al sistema después de la decisión: ¿confirmó el especialista una causa concreta? ¿Arrojó la prueba un resultado de referencia? ¿Cambiaron los síntomas? ¿Se llevó a cabo realmente la actuación? Pero lo que el usuario escribe después no se convierte automáticamente en un hecho en el que pueda basarse el entrenamiento. El usuario puede pensar que el diagnóstico era correcto porque vio una mejora, cuando la mejora pudo deberse en realidad a un cambio en la meteorología, el riego u otro factor. También puede introducir un nombre impreciso o atribuir el resultado a una actuación que no se ejecutó tal como quedó registrada. Por ello, la información posterior mantiene una fuerza variable:

• La observación del usuario resulta útil para el seguimiento.
• La confirmación de un especialista es más sólida que una conjetura inicial.
• El resultado de una prueba de referencia puede ser más sólido para una tarea concreta.
• Que haya mejora tras una actuación no prueba por sí solo que el diagnóstico o la actuación causaran la mejora.

Antes de utilizar esta información para actualizar el modelo, hay que revisar su calidad, verificar su fuente, identificar quién la aprobó y probar después el modelo actualizado antes de su publicación. De lo contrario, el sistema puede aprender de sus errores antiguos y repetirlos con mayor confianza. ¿Qué aspecto podría tener la respuesta para el agricultor? Tras recorrer las etapas iniciales, el sistema podría presentar una respuesta como esta: «La imagen muestra manchas amarillas y marrones en el tejido de la hoja, pero este aspecto puede deberse a más de una causa, y la imagen actual no basta para confirmar un diagnóstico ni para elegir un tratamiento. Envíe una imagen nítida del envés de la hoja, una imagen de la planta entera e indique el cultivo y su estado de desarrollo, cuándo comenzaron los síntomas y si aparecen en plantas contiguas o a lo largo de la línea de riego. Una vez completada esta información, podrán ordenarse las probabilidades y determinarse la siguiente prueba. No propondré ninguna sustancia ni dosis hasta que exista un diagnóstico, una fuente adecuada a la región y una verificación frente a las instrucciones de uso oficiales vigentes del producto». Esta respuesta no deja al agricultor sin ayuda y, al mismo tiempo, no le concede una certeza artificial. Aclara qué vio el sistema, qué no pudo establecer, qué información se requiere y por qué no pasó directamente al tratamiento. ¿Dónde puede fallar el recorrido? El caso muestra que el error no reside únicamente en el modelo de imagen. Puede producirse en cualquier etapa:

• La imagen puede ser inservible y, aun así, la aplicación la acepta.
• El modelo puede centrarse en una sombra o en el fondo en lugar de en las manchas.
• El caso puede no estar representado en los datos de entrenamiento.
• El usuario puede introducir un nombre de cultivo o una ubicación incorrectos.
• El sistema puede vincular la imagen al contexto de otra parcela.
• El sistema puede ordenar las probabilidades con más confianza de la que permite la evidencia.
• El sistema puede recuperar una fuente correcta, pero desactualizada o no adecuada para el país.
• La interfaz puede resumir la fuente de un modo que altere su significado.
• La información general puede transformarse en una recomendación de tratamiento no autorizada.
• La respuesta puede llegar tarde, cuando la situación ya ha cambiado.
• El sistema puede registrar una decisión propuesta como si se hubiera ejecutado realmente.
• Una observación no documentada puede entrar en los datos de entrenamiento como diagnóstico confirmado.

Por esta razón, no basta con decir que «el modelo reconoció la imagen». Necesitamos saber cómo la imagen se convirtió en una probabilidad, cómo se vinculó esa probabilidad con la fuente, cómo se impidió una inferencia insegura, quién tomó la decisión y cómo se documentó el resultado. Para el lector avanzado: este caso reúne varias funciones distintas, cada una de las cuales debería evaluarse por separado: la calidad de la imagen, la localización de los síntomas, la clasificación del patrón visual, la detección de casos inusuales, la recopilación del contexto, la ordenación de probabilidades, la recuperación de fuentes, la verificación de su idoneidad, la formulación de la respuesta, la aplicación de reglas de seguridad, la derivación a una persona y el seguimiento del resultado. El éxito de una función no debe utilizarse como evidencia del éxito de las demás. También debe evitarse el «cierre diagnóstico prematuro», es decir, detenerse en la primera explicación que parece convincente; en su lugar, conviene buscar la evidencia que la respalda y la evidencia que podría refutarla. Si el recorrido se detiene tras identificar el patrón visible en la imagen, entonces estamos ante una herramienta de análisis de imágenes. Si se añaden el contexto y la ordenación de probabilidades, entonces estamos ante un asistente de razonamiento inicial. Si se vincula con fuentes apropiadas, reglas de seguridad, una vía de revisión humana, documentación y seguimiento, entonces estamos ante un sistema de apoyo a la toma de decisiones. La diferencia entre estos niveles no aparece necesariamente en la elegancia de la interfaz ni en la fluidez de la respuesta; aparece más bien en las preguntas que el sistema formuló, los supuestos que declaró, las fuentes que puso a disposición para su escrutinio y los límites que no se permitió cruzar. El principio general: la imagen de la hoja puede revelar dónde empieza la pregunta, pero no establece por sí sola dónde termina la respuesta; y una decisión responsable es aquella que conecta lo que el sistema vio con lo que sabe del contexto, lo que puede establecer a partir de las fuentes y lo que debe permanecer bajo juicio humano.

14. ¿Qué debería quedarle al lector de este capítulo?

¿Qué debería quedarle al lector de este capítulo? El lector no necesita memorizar los nombres de los algoritmos, ni conocer los detalles de cómo se construyen, para pensar con claridad sobre la inteligencia artificial agrícola. Lo que importa es ver la conexión entre cuatro cosas: la pregunta que queremos responder, los datos de que disponemos, el resultado que el sistema produce y la acción que puede llevarse a cabo en el campo sobre esa base. Un sistema que analiza la imagen de una hoja no realiza la misma tarea que un sistema que predice el rendimiento. Un sistema que pronostica la necesidad de agua de un cultivo no realiza la misma tarea que una herramienta de planificación que selecciona cuándo poner en marcha la bomba. Del mismo modo, emitir una alerta no es lo mismo que tomar una decisión, tomar una decisión no es lo mismo que ejecutar una acción, y ejecutar una acción por sí sola no garantiza una mejora del resultado agrícola. Ante cualquier aplicación, dispositivo o presentación comercial, el lector puede organizar la evaluación en cuatro grupos de preguntas. Primero: ¿qué problema intenta resolver el sistema? Empiece por la finalidad, no por el nombre de la tecnología:

• ¿Qué problema agrícola concreto aborda el sistema?
• ¿Quién es el usuario previsto: el agricultor, el agente de extensión, el veterinario, el responsable de operaciones o el investigador?
• ¿Describe lo que está ocurriendo ahora o predice lo que puede ocurrir después?
• ¿Presenta probabilidades, sugiere una decisión o ejecuta una acción en una máquina?
• ¿Qué decisión se supone que cambia a causa del resultado?
• ¿Llega la salida mientras la intervención todavía puede ser útil?

Una empresa puede afirmar que su sistema «detecta enfermedades de las plantas», pero esa descripción puede ocultar tareas muy distintas. ¿Se limita a identificar la presencia de un cambio en la hoja? ¿Compara la imagen con un número limitado de casos? ¿Ordena las posibles causas? ¿Aporta una fuente? ¿Sugiere un tratamiento? Cada uno de estos niveles entraña datos, riesgos y responsabilidades diferentes. También hay que preguntarse qué significa el propio resultado. Si el sistema muestra el número 0,82, ¿qué significa? ¿Es una probabilidad? ¿Una puntuación de similitud? ¿Una proporción de la superficie afectada? Y si predice un rendimiento de 4,7, ¿cuál es la unidad: toneladas por hectárea, por feddan o para toda la explotación? ¿Y a qué periodo de tiempo se refiere? Un resultado cuya unidad, referencia temporal o relación con la decisión se desconocen puede parecer preciso, pero no sustenta una actuación responsable. Segundo — ¿qué sabe el sistema y qué no puede saber? Todo modelo depende de los datos de los que aprendió, o de las reglas y fuentes que se le proporcionaron. Por tanto, conviene preguntarse:

• ¿Sobre qué clase de datos se construyó?
• ¿De dónde procedían?
• ¿Quién verificó su calidad?
• ¿Representan los cultivos, las variedades, las estaciones y los entornos en los que se utilizará?
• ¿Incluyen casos incipientes, mixtos y difíciles, o solo casos inequívocos?
• ¿Qué información no puede ver ni consultar el sistema?
• ¿Qué ocurre si la imagen es deficiente, la lectura está incompleta o el sensor falla?
• ¿Distingue entre lo que realmente midió, lo que introdujo el usuario y lo que infirió por sí mismo?

Un modelo de imágenes de plantas puede aprender a partir de ejemplos, cada uno vinculado a una clase de referencia verificada por expertos. Un modelo de rendimiento puede aprender a partir de registros vinculados a valores de referencia medidos después de la cosecha. Si esas clases o mediciones de referencia son inexactas, el error se incorpora al propio proceso de aprendizaje. La semejanza entre los datos de entrenamiento y el entorno de la explotación tampoco es un detalle secundario. Un modelo entrenado con imágenes de hojas individuales en un laboratorio puede tener dificultades en un campo donde las hojas se superponen y cambia la iluminación. Un sistema entrenado en grandes explotaciones con cobertura regular de sensores puede no mantener su rendimiento en una pequeña explotación que depende de mediciones intermitentes. La pregunta importante no es solo «¿Qué vio el sistema?», sino también: ¿Qué no puede ver, aunque la decisión dependa de ello? Una imagen no siempre revela el estado de las raíces, no explica por sí sola el historial de riego y fertilización ni demuestra la presencia de un agente causante de una enfermedad. Una lectura de humedad en un único punto no describe necesariamente todo el sector. Y un registro digital no siempre muestra si la actuación registrada se llevó realmente a cabo. Tercero — ¿cómo sabemos que el sistema funciona de verdad? No basta con que un producto muestre un porcentaje elevado o un ensayo satisfactorio. Conviene preguntarse:

• ¿Con qué se comparó el sistema?
• ¿Superó al método actualmente en uso, o únicamente a una línea de base débil?
• ¿Se probó en explotaciones, campañas o dispositivos que no formaban parte de su entrenamiento?
• ¿Qué tipo de error es más grave en esta tarea?
• ¿Con qué frecuencia se produjo ese error?
• ¿Se presentaron los resultados para cada caso importante, o quedaron ocultos dentro de una media global?
• ¿Se demostró únicamente el éxito del modelo, o se probó el sistema completo?
• ¿Existe evidencia de un efecto sobre la decisión y sobre el resultado agrícola, o solo sobre la exactitud de la predicción?

El método actualmente en uso, o la regla realista más sencilla con la que comparamos el nuevo sistema, se denomina la línea de base para la comparación o «la línea de base». Esa línea de base puede ser un examen experto, la media de campañas anteriores, un calendario de riego calibrado localmente o un sistema más antiguo ya en uso. La pregunta no es si el modelo superó a nada, sino: ¿Aportó valor más allá del método realista ya disponible, y merece ese valor el coste de utilizarlo? La prueba debería asimismo asemejarse a las condiciones reales de uso. Si imágenes de la misma planta, o imágenes consecutivas muy similares, entran a la vez en los datos de entrenamiento y en los datos de prueba, el resultado puede parecer excelente porque el modelo ha visto, en la práctica, algo semejante a la prueba con anterioridad. Esta es una forma de fuga de datos: información o ejemplos estrechamente relacionados que llegan al conjunto de prueba aun cuando deberían haber permanecido separados de él. También es necesario distinguir entre tres tipos de evidencia:

1. Evidencia del rendimiento del modelo:

Muestra que el modelo clasificó imágenes o predijo valores correctamente en una prueba concreta.

2. Evidencia del rendimiento del sistema:

Muestra que la recogida de datos, los controles de calidad, el análisis, la presentación del resultado, la comunicación y la implantación funcionan conjuntamente en condiciones reales.

3. Evidencia del impacto agrícola:

Muestra que el uso del sistema condujo a una decisión mejor, redujo un daño, conservó un recurso o mejoró un resultado en la explotación.

Y el primer tipo no establece automáticamente los otros dos. La predicción puede ser correcta, pero la alerta llega tarde. O puede llegar a tiempo, pero el usuario carece del recurso necesario para llevar a cabo la recomendación. Y la decisión puede ejecutarse, pero su efecto difiere por un factor que el sistema no tuvo en cuenta. Cuarto: ¿qué ocurre cuando el sistema no sabe, o cuando falla? Un sistema responsable no se comporta como si todos los casos fueran conocidos, todos los datos estuvieran completos y todos los dispositivos funcionaran siempre. Deberíamos preguntar, por tanto:

• ¿Deja claro que la evidencia es insuficiente cuando el caso es ambiguo?
• ¿Ofrece un rango o un grado de confianza en lugar de una cifra definitiva?
• ¿Puede solicitar información adicional?
• ¿Puede abstenerse de emitir un diagnóstico o una recomendación cuando carece de fundamento suficiente?
• ¿Qué hace si el sensor, la conexión o el suministro eléctrico se cortan?
• ¿Pasa a un modo seguro, o continúa a partir de datos antiguos?
• ¿Quién revisa los casos no resueltos?
• ¿Quién tiene la autoridad para detener la implantación o anularla?
• ¿Cómo detecta el equipo que el rendimiento se ha deteriorado tras la compra o la implantación?
• ¿Quién aprueba las actualizaciones y las nuevas versiones?

La incertidumbre significa que la evidencia no respalda todos los resultados con la misma fuerza. La imagen puede ser nítida y similar a aquellas de las que el modelo aprendió, o puede estar incompleta y representar un caso que no ha visto antes. Los sensores pueden coincidir, o sus lecturas pueden contradecirse. En cuanto a la abstención, significa que el sistema no se obliga a emitir un juicio cuando la evidencia no lo permite. Puede decir: «Los datos actuales son insuficientes para determinar el estado con seguridad. Envíe una imagen adicional, inspeccione el sensor o derive el caso a un especialista». Esto no es señal de debilidad si se emplea en el lugar adecuado. Una respuesta que declara sus límites e identifica el paso siguiente puede resultar más útil que una respuesta definitiva no respaldada por evidencia suficiente. Pero la abstención requiere también equilibrio. Un sistema que se abstiene en la mayoría de los casos puede ser de escasa utilidad, y un sistema que nunca se abstiene puede ser peligroso. Lo que se necesita es especificar los casos en que debe responder, los casos en que debe solicitar información adicional y los casos en que la autoridad pasa a una persona cualificada. Cuando los datos o la conexión fallan, no basta con que el manual técnico diga que el sistema «admite el funcionamiento sin conexión». Necesitamos saber qué permanece realmente disponible, cuándo se actualizaron los datos por última vez, si el usuario puede distinguir entre una lectura en vivo y una antigua, y cómo volver a un modo de funcionamiento manual seguro. Estas preguntas no se oponen a la innovación Las preguntas anteriores pueden parecer numerosas, pero no pretenden obstaculizar la tecnología ni rechazarla. Ayudan a que la innovación pase de ser una demostración emocionante a una herramienta en la que se puede confiar, que puede utilizarse y que puede revisarse. Una tecnología madura puede explicar:

• La tarea que desempeña.
• Los datos en los que se basa.
• Las condiciones en las que fue probada.
• Los tipos de errores que comete.
• Los límites del resultado que produce.
• Qué ocurre cuando faltan datos o falla el equipo.
• Quién tiene la decisión final.
• Cómo se supervisa el rendimiento una vez que comienza el uso.

Pero una tecnología que oculta estas preguntas tras el nombre de un modelo famoso, un porcentaje general o una interfaz deslumbrante sigue necesitando madurez, por fluida que sea su presentación. La confianza no nace de la ausencia de preguntas, sino de la capacidad del sistema y de la parte responsable de él para responderlas con evidencia clara.

Resumen del capítulo

No existe un único método que sea el mejor para todos los problemas agrícolas, ni los métodos de inteligencia artificial avanzan por una escala que culmine necesariamente en el modelo más grande o más reciente. Cada método tiene un tipo de pregunta que maneja bien, un tipo de datos que necesita y unos límites que conviene comprender. Lo que el capítulo ha presentado puede organizarse según la función que desempeña el método. Métodos que aprenden de ejemplos con resultados conocidos En el aprendizaje supervisado, el modelo aprende la relación entre la entrada y el resultado de referencia asociado a ella. Las entradas pueden ser imágenes de hojas, y los resultados de referencia, afecciones confirmadas por un especialista. O las entradas pueden ser datos de meteorología, suelo y manejo, y los resultados de referencia, valores de rendimiento medidos tras la cosecha. La fortaleza de este método reside en que utiliza ejemplos previos para predecir un nuevo resultado. Su limitación básica es que aprende de la manera en que esos ejemplos fueron construidos, incluidos sus errores, sus sesgos y su estrechez de representación. En cuanto al aprendizaje semisupervisado, se apoya en un número limitado de ejemplos revisados por un especialista, junto a un número mayor de imágenes o registros cuyos resultados aún no se han determinado. Esto puede reducir la carga de revisión, pero no compensa unos ejemplos documentados deficientes ni la escasa diversidad entre ellos. Métodos que buscan patrones sin una respuesta preparada para cada ejemplo En el aprendizaje no supervisado, el sistema busca similitudes y diferencias dentro de los datos. Puede dividir la parcela en zonas de humedad o rendimiento similares, o detectar registros que se apartan del patrón habitual. Pero un agrupamiento descubierto por el sistema no es, en sí mismo, un diagnóstico agronómico. Dos zonas pueden ser computacionalmente similares por razones distintas. El papel del algoritmo es revelar un patrón que merece examen; interpretar la causa exige contexto de campo, inspección y experiencia. La detección de anomalías entra en este ámbito en muchas aplicaciones. El sistema puede llamar la atención sobre un sensor que ha empezado a derivar, un animal cuya actividad ha cambiado o un consumo de agua que se ha salido del rango habitual. Pero no establece automáticamente que se haya producido una enfermedad o una avería. Métodos que analizan imágenes y el cambio a lo largo del tiempo La visión por computador utiliza una imagen o un vídeo para clasificar una condición, determinar la ubicación de un objeto, delimitar los contornos de una zona afectada o seguir un objeto a través de fotogramas sucesivos. Pero ver una mancha no significa conocer su causa, y localizar una mala hierba no significa que la máquina pueda eliminarla de forma segura. Una salida de visión puede ser una entrada para una etapa posterior de inferencia o de control, más que una decisión completa. En cuanto a los métodos que analizan el cambio a lo largo del tiempo, examinan secuencias de lecturas: ¿cómo ha cambiado la humedad? ¿Está aumentando o disminuyendo la actividad del animal? ¿Cuál es la tendencia esperada del rendimiento o de la demanda de agua? Estos métodos exigen atender a la estacionalidad, a las condiciones cambiantes, a las lagunas en la medición y a la necesidad de no dar por supuesto que un patrón pasado continuará siempre. Métodos que representan la probabilidad y separan la predicción del efecto de la intervención Los modelos probabilísticos ayudan a expresar la incertidumbre en lugar de ocultarla. Pueden ordenar varias explicaciones posibles, presentar un intervalo para el rendimiento esperado o actualizar sus probabilidades cuando llega información nueva. Pero la probabilidad no resulta útil por el mero hecho de aparecer como un porcentaje; hay que comprobar la fiabilidad de las puntuaciones de confianza y hay que demostrar si el caso se asemeja a los entornos en los que el sistema fue probado. En cuanto a la inferencia causal, aborda una pregunta más difícil que la predicción. La predicción pregunta: «¿Qué se espera que ocurra?», mientras que la pregunta causal plantea: «¿Qué se espera que cambie si intervenimos?». Un modelo puede lograr predecir el rendimiento a partir de datos de suelo y manejo sin establecer que aumentar una de las entradas elevará el rendimiento. Pasar de observar una relación a recomendar una intervención exige una evidencia más sólida, un diseño adecuado, conocimiento agronómico y límites ambientales y regulatorios. Métodos que comparan alternativas o abordan acciones secuenciales La planificación matemática y la optimización ayudan a asignar recursos y a ponderar las contrapartidas entre planes dentro de restricciones claras. Pueden repartir una cantidad limitada de agua entre varios sectores teniendo en cuenta el estado de crecimiento, la capacidad de bombeo, la energía y los tiempos de operación. Pero el plan resultante refleja el objetivo y las restricciones que especificó el diseñador. Si el objetivo descuida la salud de la planta o la equidad entre sectores, la herramienta puede producir un plan computacionalmente exitoso y, sin embargo, agronómicamente inaceptable. En cuanto al aprendizaje por refuerzo, se ocupa de una secuencia de acciones que cambian el estado del entorno. El sistema puede elegir una acción, observar el resultado y ajustar después sus elecciones para mejorar un objetivo a largo plazo. Ahora bien, este tipo de aprendizaje requiere explorar los resultados de las acciones, y el sistema no debe probar acciones peligrosas en el campo para aprender que no son seguras. Exige, por tanto, simulación, pruebas graduales, restricciones de seguridad explícitas y autoridad humana para detenerlo. Métodos que abren la puerta al diálogo con el conocimiento Los modelos de lenguaje pueden resumir textos, traducirlos, extraer información y formular una respuesta en lenguaje natural. Facilitan el acceso al conocimiento, porque el agricultor puede preguntar en su propia lengua en lugar de navegar por menús complejos. Pero la fluidez de una respuesta no demuestra su corrección. Un modelo puede producir una afirmación persuasiva sin apoyo suficiente. Por esta razón, puede enlazarse con una cadena de procesamiento que busque en fuentes autorizadas y recupere los pasajes pertinentes antes de formular la respuesta. La recuperación no garantiza automáticamente la corrección de la respuesta; el sistema puede encontrar una fuente correcta que, sin embargo, no sea adecuada para el cultivo, el país o la fecha. La respuesta debe distinguir entre lo que aparece en la fuente, lo que el sistema infirió y lo que requiere el juicio de un especialista. Herramientas que nos ayudan a examinar el resultado Las herramientas de inteligencia artificial explicable tratan de mostrar qué influyó en el resultado del modelo: partes de la imagen, lecturas asociadas a la predicción, ejemplos similares o un cambio que podría haber alterado la salida del modelo. Estas herramientas pueden ayudar al desarrollador a descubrir un error, o ayudar al especialista a revisar un resultado. Pero explican lo que el modelo utilizó, y no establecen necesariamente qué causó el fenómeno en el campo. Una explicación persuasiva no convierte un resultado incorrecto en correcto, ni compensa unos datos deficientes o la ausencia de pruebas externas. El método es parte de una cadena más amplia Ninguno de estos métodos opera en el vacío. El sistema agrícola suele recorrer una cadena que empieza en la realidad y termina con un nuevo efecto sobre ella: Realidad del campo → medición, imagen o registro → comprobación de la calidad de los datos → estimación o predicción → reglas y contexto → decisión → ejecución → impacto agrícola → seguimiento La cadena puede fallar en cualquier eslabón:

• El sensor puede producir una lectura incorrecta o expresada en una unidad inesperada.
• Una imagen puede estar vinculada a un resultado de referencia inexacto.
• Imágenes de la misma planta pueden entrar tanto en el entrenamiento como en la prueba, con lo que el resultado parece mejor que su verdadera capacidad de generalizar.
• El modelo puede aprender de un entorno que no se parece a la explotación en la que va a operar.
• La predicción puede ser correcta, pero la regla de decisión puede traducir su significado de forma incorrecta.
• Puede elegirse un objetivo computacional que pase por alto una restricción agrícola o ambiental.
• El sistema puede recuperar una fuente que no corresponde al cultivo ni a la región.
• La respuesta lingüística puede parecer más fiable que la evidencia en la que se basa.
• La alerta puede llegar después de que haya pasado la ventana de intervención.
• Puede emitirse la orden correcta, pero el equipo puede no llegar a ejecutarla.
• El usuario puede no disponer de los recursos o de la autoridad necesarios para aplicar la recomendación.
• La realidad puede cambiar con el tiempo mientras el sistema sigue funcionando como si las condiciones no hubieran cambiado.

Por este motivo, comparar dos algoritmos no siempre basta. La diferencia entre ellos puede ser pequeña, mientras que los efectos de la calidad del sensor, de la claridad de la interfaz, de la seguridad de la implantación o de la capacidad de respuesta del equipo pueden ser mucho mayores. El contrato que vincula la tecnología con la decisión El mensaje del capítulo puede resumirse en el siguiente enunciado: El método técnico forma parte de un contrato claro que vincula la pregunta, los datos, la salida, la acción y la responsabilidad. No se alude a un contrato jurídico, sino a un acuerdo intelectual y práctico cuyos términos deben ser claros:

1. Pregunta: ¿qué problema concreto tratamos de resolver?
2. Datos: ¿qué evidencia nos permite responderlo y cuáles son los límites de su calidad y su representatividad?
3. Salida: ¿qué producirá el sistema, en qué unidades y con qué grado de confianza?
4. Error: ¿cómo podría fallar y qué error sería el más dañino?
5. Acción: ¿qué decisión o acción podría basarse en esa salida?
6. Responsabilidad: ¿quién revisa, aprueba, implanta, detiene y vigila el impacto?

Si el algoritmo se elige antes de comprender estos puntos, se convierte en un nombre técnico en busca de un problema. Pero si el diseño parte de la decisión requerida, de los datos disponibles, de las consecuencias del error, de la base realista de comparación y de las restricciones de operación, entonces el algoritmo puede convertirse en una herramienta precisa dentro de un sistema mayor que las personas dirigen, revisan y del que responden. La comprensión real de la inteligencia artificial agrícola no empieza cuando memorizamos los nombres de los modelos, sino cuando somos capaces de preguntar:

• ¿Qué vio realmente el sistema?
• ¿Qué infirió?
• ¿Qué no pudo saber?
• ¿Qué evidencia respalda el resultado?
• ¿A qué acción conducirá?
• ¿Quién asume la responsabilidad de esa acción?
• ¿Qué ocurre si el resultado es erróneo?

Nos beneficiamos de la rapidez de la inteligencia artificial cuando la tarea es clara, los datos son adecuados y los límites son explícitos. Nos detenemos a buscar una medición, una fuente o un especialista cuando el resultado va más allá de lo que la evidencia puede establecer. Síntesis: no pregunte únicamente «¿es inteligente este sistema?». Pregunte más bien: «¿qué sabe, cómo llegó a saberlo, qué no sabe y qué ocurrirá en el campo si confiamos en él?».

Notas sobre la evidencia y los límites de la dependencia

Las dos revisiones [SRC001] y [SRC002] respaldan el relato general sobre la amplitud de las aplicaciones de la inteligencia artificial y de la visión por computador en los ámbitos agrícola y alimentario, sin que ello implique que toda aplicación sea adecuada para todos los cultivos y entornos. [SRC035] respalda la consideración del sistema agrícola digital como una cadena interconectada que incluye la detección, los datos, el contexto, la decisión y la acción, lo que justifica evaluar el sistema en su conjunto en lugar de fiarse únicamente de la salida del modelo. [SRC006] se utiliza como ejemplo acotado de predicción del rendimiento y de uso de herramientas de interpretabilidad dentro de un entorno de investigación concreto. La ordenación de los factores o los hallazgos de ese entorno no deben convertirse en relaciones causales generales ni en hechos aplicables a cualquier parcela. [SRC009] se utiliza para corregir la atribución de la tecnología de detección de malas hierbas: se refiere al análisis de imágenes de campos de soja mediante métodos de visión convolucionales, y no establece la existencia de un sistema robótico de eliminación basado en aprendizaje por refuerzo. Esta corrección ayuda a distinguir entre ver un objeto en una imagen y controlar una máquina que interactúa con él. La presentación de los riesgos, la supervisión y la revisión continua a lo largo del ciclo de vida del sistema se guía por el marco citado en [SRC033]. En cuanto al caso docente integrado, la guía para vincular la tarea con el método, las preguntas prácticas y los ejemplos de campo presentados en el capítulo, constituyen una síntesis editorial con fines didácticos destinada a aclarar las distinciones entre medición, análisis, decisión e implantación. Estos ejemplos no representan los resultados de un nuevo experimento, ni una prueba del rendimiento de ningún sistema concreto, ni un diagnóstico agrícola, ni una prescripción para tratar un cultivo.