Los agentes de IA y el reto de la conexión a tierra: de la intención a la acción automatizada
Los agentes de IA anuncian una nueva revolución con la posibilidad de delegar acciones en los LLM. Imagina poder pedir a ChatGPT que te dé el horario del tren que quieres coger y, sobre todo, ¡que haga la reserva por ti!
En cuanto delegamos la capacidad de actuar en el LLM, vemos un gran número de nuevos casos de uso muy interesantes. En el caso de las pruebas de software en particular, podemos imaginar el desarrollo de agentes que puedan escribir pruebas pero también, y sobre todo, ejecutarlas de forma completamente autónoma.
Sin embargo, las dificultades siguen ahí y los agentes de IA siguen adoleciendo de muchas imperfecciones. Uno de los puntos más difíciles es la capacidad de actuar, que requiere responder a dos preguntas: "Qué hacer" y "Cómo hacerlo".
Ya es necesario saber lo que hay que hacer, es decir, tener una representación abstracta de la acción que hay que realizar.
Por ejemplo, si el objetivo es reservar un billete de tren, hay que empezar por buscar el horario para encontrar el tren adecuado. Una vez que se sabe qué hacer (buscar un tren), hay que saber cómo hacerlo, es decir, entender la aplicación con la que se quiere interactuar y utilizar su interfaz gráfica.
Siguiendo con nuestro ejemplo, necesitamos saber cómo interactuar con la barra de búsqueda e introducir la información que necesitamos para encontrar nuestro tren.
Los LLM de hoy en día son muy buenos dando respuestas a la pregunta "qué hacer". Si le haces a ChatGPT la siguiente pregunta: "Estoy en el sitio web sncf connect .connect, ¿qué tengo que hacer para reservar un tren de Burdeos a Nantes el 15 de marzo?
Para responder a la pregunta "cómo", tenemos que ser mucho más específicos y explicar cómo se puede interactuar automáticamente con la aplicación.
En el ámbito de las aplicaciones web, los agentes realizan acciones concretas explotando marcos técnicos como Playwright, por ejemplo. Si hacemos a ChatGPT la siguiente pregunta: "¿Cómo utilizo Playwright para realizar el paso 2 (encontrar tu ruta)?", nos devolverá código Playwright, ¡pero los parámetros dados no funcionarán!
El selector CSS [data-testid="origin-input"] no existe en la aplicación web.
La dificultad del "cómo hacerlo" empieza a conocerse como "grounding". Consiste en partir de una descripción abstracta, la respuesta a la pregunta "qué hacer", y proporcionar los elementos técnicos que permitirán la interacción concreta con la interfaz gráfica de la aplicación. La mayor dificultad reside en identificar los componentes con los que se va a interactuar.
En los últimos años se han barajado varias soluciones en el ámbito de las aplicaciones web. La primera consistió en proporcionar al DOM de la aplicación web una descripción del elemento con el que se iba a interactuar.
En nuestro ejemplo, proporcionamos el DOM de la página sncf-connect y pedimos al LLM que nos proporcione el selector CSS de la barra de búsqueda. Este enfoque da resultados decepcionantes, principalmente debido a la complejidad del DOM.
Un segundo enfoque consistía en identificar todos los elementos interactuables de la página, construir sus selectores CSS y preguntar al LLM cuál de estos selectores correspondía al elemento con el que se quería interactuar. Este enfoque no dio mejores resultados.
Recientemente se ha desarrollado una segunda familia de enfoques que aprovecha las copias de pantalla. El enfoque SOM (Set Of Mark) consiste en generar una captura de pantalla del sitio web, pero rodeando gráficamente todos los elementos interactuables y aplicándoles etiquetas gráficas numeradas.
Si lo hace, puede pedir al LLM el número de la etiqueta gráfica situada en la zona que rodea al elemento con el que desea interactuar. Este enfoque produce resultados muy interesantes, pero algunos elementos son difíciles de identificar (menús, botones pequeños, etc.).
Por último, algunos LLM están entrenados para devolver las coordenadas X e Y de los elementos. A continuación, se les puede pedir que localicen elementos. También en este caso los resultados son alentadores.
Sea como fuere, el problema de la puesta a tierra aún no se ha resuelto y son muchos los trabajos que proponen soluciones innovadoras. En el ámbito de las pruebas, esto se hace eco del problema de la comprobabilidad de un sitio. Cabe esperar que los primeros resultados se obtengan en aplicaciones fáciles de probar.
De ser así, muy pronto podríamos asistir a la llegada de agentes que ayuden en la ejecución de las pruebas, lo que permitiría probar las aplicaciones con mayor eficacia.
La conexión a tierra implica encontrar el comando Playwright adecuado con los parámetros correctos para realizar la acción.
En nuestro ejemplo, introducir información en la barra de búsqueda implica primero localizar la barra de búsqueda (comando locator, que requiere conocer el selector CSS de la barra de búsqueda) y luego rellenarla con el valor correcto (comando fill, que requiere conocer el valor que se va a introducir).
Mr Suricate, líder francés en pruebas automatizadas sin código
La solución SaaS sin código Mr Suricate cubre una amplia gama de pruebas automatizadas, lo que le permite tomar el control de sus procesos de aceptación y ofrecer a sus usuarios la mejor experiencia posible.
Tome el control de sus aplicaciones y detecte errores en tiempo real en sus sitios web, aplicaciones y API, reproduciendo automáticamente sus rutas de usuario a intervalos regulares.