seminario en línea Data, Explored #6 – La malla agencial: replanteamiento de la arquitectura de la IA para la autonomía y la alineación

Bien, vamos a ello. El tema de hoy es el futuro de la empresa, basado en vuestro libro, Eric y Davis, titulado Agen Mesh. Tengo una larga lista de preguntas que quiero haceros.

En primer lugar, bienvenidos. Es un placer teneros aquí a ti y a Davis. Creo que la primera pregunta es una que me gustaría hacerte a ti y a Eric, aunque, por supuesto, puedes intervenir si lo deseas, pero estamos hablando del futuro de la agencia, de la empresa.

Entonces, ¿por qué no empezar con una breve definición de, eh, lo que es un agente? ¿Cómo funciona? ¿Qué es, eh, en tus propias palabras, Davis?

Muy bien. Bueno, un agente es un actor de software que puede interpretar el contexto, perseguir un objetivo, elegir acciones, ejecutar tareas mediante herramientas, API, interactuar con datos e interactuar con personas y otros agentes. La característica fundamental aquí es la agencia.

No solo genera una respuesta, sino que decide qué hacer a continuación. Transfiere el estado entre pasos y se ajusta en función de los resultados de los pasos anteriores y del uso empresarial. Y el agente debe ser tratado como una entidad operativa con permisos de identidad, políticas y comportamiento observable.

Eso lo convierte más bien en un modelo de llamada, eh, o un chat bot. Y se convierte en un participante de software controlado que puede realizar un trabajo limitado dentro de un entorno empresarial. Oh, genial.

Sí. Eh, déjame añadir algo más. Eh, fantástica respuesta, Davis.

Eh, hay dos, hay dos tipos de agentes que me gustaría mencionar en este debate. Uno es el de los agentes de codificación, y estoy seguro de que si la gente ha estado utilizando Claude Code o Codex, probablemente reconocerá el hecho de que han cambiado la ingeniería de software y se están moviendo hacia el espacio de la ingeniería de datos, así como hacia el espacio del dominio empresarial. Y vemos cosas como Open Claw, enormes innovaciones.

Pero aquí está la diferencia, y esto es lo que estamos entrando en nuestra discusión empresarial, es que estos son agentes personales. Estos son los que se ejecutan bajo su identificación, su función, sus permisos. Usted les da acceso a su entorno.

Tú les das acceso a tus recursos. Los agentes empresariales de los que vamos a hablar un poco más son diferentes. Son entidades operativas.

Como Davis ha destacado, tienen permisos de identidad, políticas y observadores, comportamiento observable. Ahora bien, la cuestión es que estos agentes son ahora participantes de software regulados en la empresa, al igual que cualquier otra aplicación empresarial. Y esa es la clave, la diferencia clave, creo, para sentar las bases de cómo la gente quizá haya oído hablar del código en la nube, los agentes y demás, y hacia dónde queremos ir, hacia dónde vemos que se dirige realmente el entorno.

Sí. Gracias, Eric. Gracias por especificarlo.

Y supongo que, obviamente, los participantes aquí ya tienen algunos conocimientos sobre el tema, o al menos están interesados, ¿verdad? Así que podemos entrar un poco en detalles técnicos, por supuesto, pero algunas de las preguntas que he preparado también son de un nivel más avanzado, para que podamos comprender el tema en su totalidad. Y quiero empezar con la premisa de su libro, en realidad.

Eh, bueno, ahora que estamos metidos en el tema, como tú has escrito, tú has escrito un libro, y obviamente la pregunta es para los dos. Así que podéis intervenir los dos cuando queráis. Pero quiero empezar con un pequeño reto, y supongo que quizá sea fácil.

Usted decidió escribir un libro sobre lo que llama las Ag mes. ¿Por qué no decidió escribir un libro sobre lo que podría llamar de manera provocativa el monolito? ¿Por qué es una malla?

¿Por qué es un monolito? Claro. Esa es una gran pregunta.

Um, voy a citar algunas declaraciones de líderes del sector. Andy Jassy, director ejecutivo de Amazon, dijo que habrá un millón de agentes en cada empresa. Satya Nadella, de Microsoft, ha dicho que los agentes sustituirán al software como servicio.

Eh, Jensen Wong ha dicho, el director ejecutivo de Nvidia ha dicho que habrá miles, si no decenas o cientos de miles de agentes en cada empresa. Así que lo que sabemos es que, incluso si se equivocan por completo y solo haya mil o quizá 10 000 agentes en una empresa, hay muy pocas entidades de software en cualquier empresa que tengan 10 000 de cualquier cosa. Por lo tanto, quizá hayamos visto algo parecido en la gestión de microservicios.

Y la razón por la que entra en juego una malla es que, si necesitas gestionar cien, mil, diez mil o tal vez un millón de cualquier cosa, tienes que pensar en una arquitectura diferente. Un monolito simplemente no sería práctico. O gestionar un millón de agentes en un monolito.

Probablemente no sería, eh, implementable en ninguna arquitectura moderna significativa hoy en día. Pero si los distribuyo, eh, tengo una oportunidad. Y, sinceramente, la arquitectura distribuida es lo que vemos todos los días, tanto si se utiliza la nube como dentro de los centros de datos, se ven miles de nodos por ahí.

Por lo tanto, creemos que la arquitectura más lógica para los agentes es, eh, un modelo federado y la malla, eh, uno en el que, por definición, cualquier agente puede colaborar con cualquier otro agente, lo que conduce a una arquitectura basada en malla. Solo por necesidad práctica, eh, ole Sí, no, muy justo. Eh, creo que, eh, esto es solo una observación personal, pero en los primeros días de, eh, jet GPT-3 0.5, creo que existía la idea de que el futuro de la IA sería, algunos dirían, y, y, esto va a sonar muy poco técnico, pero, pero que el futuro de la IA sería, de alguna manera, grandes bloques de software que realizarían algo simplemente debido al término «modelo de lenguaje grande», y la idea de que eso se traduciría, de alguna manera, en, eh, algún tipo de arquitectura monolítica.

Pero estoy de acuerdo en que lo que estamos viendo es una idea muy extendida de que las arquitecturas gen deben existir en lo que se podría llamar una malla, en el sentido de que habrá un número muy, muy grande de agentes que trabajarán juntos en una malla. Eh, en su libro, en Ingen mesh, usted distingue entre, eh, tipos libres de, eh, agentes, si se quiere, eh, de formas libres de trabajar con IA en la empresa. Eh, es lo que usted llama los flujos de trabajo de IA, agentes autónomos y agentes de nivel empresarial.

En realidad, en tu definición, Davis, al principio de la conversación, ya aludiste un poco a esto, si te apetece, me gustaría ampliar un poco tu definición y preguntarte, ¿cuál es la diferencia entre los flujos de trabajo de IA, los agentes autónomos y los agentes de nivel empresarial? Muy bien. Esa es una gran pregunta, y realmente aborda algunas de las diferencias que ha experimentado la IA en los últimos años.

Entonces, un flujo de trabajo de IA es un sistema en el que el modelo de lenguaje (LM) y sus herramientas avanzan siguiendo una ruta de código predefinida. Esto significa que el flujo de trabajo de IA debe tener todos los pasos. Podría tomar cada punto de decisión establecido de antemano por quien lo esté creando.

Como si alguien hubiera, por ejemplo, estuvieras usando un LM en el paso cuatro o en el paso tres para resumir algo o para extraer un poco de información o para clasificar algo. Pero, fundamentalmente, cada paso de ese proceso, mm-hmm, se ha definido de antemano. Como si la IA solo pudiera resumir, solo pudiera extraer si ya has llegado a ese paso, no puede influir mucho en los siguientes pasos.

Básicamente, está fijo y todo tiene, como, si aparece algo inesperado que el diseñador del flujo de trabajo no vio de antemano, simplemente obtendrás un error. Incluso en los casos en los que puede resultar obvio para un humano cuál es la ruta correcta, compárese esto con un agente autónomo, como un agente que puede determinar dinámicamente su propia ruta de ejecución. Si dispone de las herramientas necesarias, incluso en una situación inesperada, puede aplicarlas y superar lo inesperado para encontrar una nueva forma de seguir avanzando.

Es capaz de reconocer e implementar nuevas soluciones bajo demanda para hacer frente a condiciones cambiantes. La adaptabilidad y la planificación dinámica es realmente lo que lo distingue. Y más allá de eso, en lo que respecta a los agentes de nivel empresarial, es la forma en que se integra un agente autónomo en la empresa para garantizar que sea detectable, que sea seguro, que sea fiable y todas las demás cosas que serán necesarias para que una empresa acepte realmente los agentes.

Ah, sí. Vale. Entonces yo, yo veo la diferencia, eh, más clara, obviamente.

Yo, yo, eh, yo, leí el libro por adelantado para prepararme para este seminario en línea. También fui revisor técnico. No lo dije al principio.

No creo haber dicho eso al principio. Pero de lo que estoy convencido es de que este tipo de pensamiento y la forma en que lo describes se convertirán, eh, en una especie de... Tu libro se convertirá en una fuente de referencia para comprender las arquitecturas de tecnología genética que es posible crear en la empresa. Exactamente. Debido a este tipo de distinciones.

Y quizás, como girando un poco el micrófono hacia ti, Eric, en términos de, en términos de, en términos de la realidad organizativa y la empresa, tendemos a pensar, tendemos a pensar en los agentes como algo en lo que un humano representa a un agente. Ahora bien, tú muestras muy claramente que, en un entorno organizativo, no se puede pensar realmente así. La distinción es, o la comparación tiene que ser un poco diferente.

Y así tenemos algunas metáforas que utilizas para traducir la realidad empresarial. Entonces, tú traduces... Déjame leer la pregunta para no complicarlo demasiado para los oyentes. ¿Cómo traduces un equipo y una organización a grupos de agentes?

¿En qué consiste la metáfora de la flota y en qué consiste la metáfora del ecosistema? ¿Podrías explicarlo un poco más, Eric? Sí, por supuesto.

Bueno, en el libro utilizamos una analogía en la que partimos de la base de que una persona es como un agente. Y, como ha mencionado Davis, un agente puede elaborar un plan de tareas y tomar decisiones, igual que una persona. Extendemos esa analogía a los equipos.

Así como las personas trabajan en equipos y colaboran entre sí, y utilizan herramientas que llamamos equipos de agentes, nosotros las llamamos flotas. Ahora bien, al igual que las personas, y como cualquier organización, ya sea de tamaño modesto o incluso grande, hay muchos equipos y muchos niveles de organización, y pueden estar organizados de diversas maneras. En términos generales, lo llamamos empresa, compañía, si se quiere.

En nuestra terminología de agentes, lo llamamos ecosistema o malla eugen. Ahora bien, lo interesante es que, en realidad, extendemos esa analogía a las cadenas de suministro, por ejemplo, donde hay múltiples organizaciones que tienen contratos específicos que definen cómo interactúan, con quién pueden colaborar, cuáles son las expectativas de nivel de servicio o incluso las expectativas de calidad. Así que la analogía se extiende hasta las cadenas de suministro de fabricación modernas, por ejemplo, que tienen todas estas cosas que he mencionado.

Pero estas son exactamente las mismas cosas que podríamos aplicar a los agentes, y, de hecho, creemos que se aplicarían a, eh, esto puede ser un término nuevo, la automatización de procesos agenticos para diferenciarla de la automatización de procesos empresariales habituales o la automatización de procesos robóticos. Eh, creemos que la analogía de persona a agente, equipo a organización de flota a ecosistema, y luego automatización de procesos es, en realidad, la analogía correcta. Y probablemente la más intuitiva, porque, al igual que usted, al igual que todos nosotros, todos interactuamos con otras personas, trabajamos en equipo.

Normalmente trabajamos dentro de una organización empresarial. Y a veces incluso interactuamos con varias empresas. La analogía tiene mucho sentido, y por eso la hemos utilizado ampliamente en el libro.

Sí, no, estoy de acuerdo. También creo que, eh, eh, obviamente, el nivel de coordinación aumenta cuantos más agentes hay, ¿no? Una flota es algo a lo que puedes dar una dirección con relativa facilidad y decir: «Iréis en esta dirección en estas condiciones», ¿verdad?

Mientras que un ecosistema se vuelve obviamente cada vez más, eh, difícil a medida que lo amplías, eh, para coordinarlo y darle dirección, y, y, y no debería ir en la misma dirección, ¿verdad? Si tienes un ecosistema de agentes, obviamente lo que buscas es una multitud de procesos diferentes que no están conectados o solo lo están de forma muy vaga, ¿verdad? Eso te da un nivel de complejidad completamente diferente con el que operar.

Y creo que lo que es muy necesario en la conversación sobre los agentes es que tiende a detenerse típicamente en la comparación con el agente humano, mientras que realmente se necesita algo más que un humano para comparar, eh, un conjunto de agentes, ¿verdad? Eh, mm-hmm. Así que, me gusta esa pregunta, me gusta esa, eh, esa, um, esa distinción que haces en el libro, eh, bastante.

De acuerdo. Entonces, yo también estoy preparado, esta es una pregunta importante, y tiene muchos aspectos diferentes, y supongo que ambos pueden responderla. Ambos han revelado partes de la respuesta, pero espero que podamos profundizar en ella.

Pero esta es una pregunta importante, así que la leeré y luego la dividiremos en partes porque nadie será capaz de recordarla de todos modos. Um, sí. Entonces, eh, los agentes de nivel empresarial tienen siete características.

Así que estos son los agentes de nivel empresarial. Por lo tanto, estamos más allá de los agentes autónomos. Estamos en el ámbito de los agentes de nivel empresarial, ¿verdad?

Los agentes de nivel empresarial más refinados de su clase tienen siete características: seguridad, fiabilidad, explicabilidad, escalabilidad, detectabilidad, observabilidad y operatividad. Y nadie puede recordar esa repetición en voz alta. Pero, ¿puedes describir qué son estas siete características en conjunto, eh, un agente de nivel empresarial, Blac, y creo que deberíamos repasarlas una por una?

Entonces, ¿cuál es el aspecto de seguridad de un agente de nivel empresarial? Sí, Davis, sé que tú escribiste el capítulo sobre seguridad del libro. ¿Por qué no empiezas con tu perspectiva sobre la seguridad?

Muy bien, para que una empresa acepte a un agente en sus operaciones, necesita saber que ese agente es seguro. No importa lo bien que trabaje el agente si cualquier persona aleatoria en Internet puede entrar y borrar tu base de datos. Por lo tanto, básicamente, necesita tener permisos, necesita tener identidad, necesita estar en tu sistema OAuth, para que puedas establecer a qué tiene acceso y a qué no.

Debe comunicarse a través de protocolos seguros. Debe asegurarse de que todas sus comunicaciones estén encriptadas. Debe asegurarse de que nadie pueda ver lo que está haciendo el agente, nadie que no deba hacerlo, que nadie pueda decirle al agente lo que debe hacer, nadie que no deba hacerlo, y que el agente no esté mirando o accediendo a cosas.

No debería poder hacerlo para cumplir con su función, si pudieras hacer todo eso. Bueno, eso es... Sí, es bastante interesante. Davis, me parece, y esto es algo a lo que probablemente volveremos, es... Y esto es algo que hemos dicho en el libro o en otros lugares, también es un agente empresarial, es como cualquier otra aplicación empresarial que tiene una identidad, tiene roles, permisos, la comunicación es segura.

Entonces, esa es la otra cosa que mencioné. Estamos hablando de algo que suena muy nuevo en algunos aspectos, pero en realidad no lo es. De hecho, el modelo que utilizamos en el libro es que la seguridad para un agente debe reflejar el mismo nivel de seguridad.

Aunque hay, obviamente, algunas diferencias, debería reflejar los mismos principios y las mismas ideas que cualquier otra aplicación empresarial importante. De acuerdo. Sí, no, eso tiene mucho sentido.

Um, y obviamente eso también lo complica bastante. Um, vale. Pero, eh, pero sí, obviamente lo necesitas, pero también necesitarías, supongo, de todos modos, quizás volvamos a eso porque también necesitarías algún tipo de, um, arquitectura automática creada en torno a, eh, esa seguridad, ¿verdad?

Porque gestionar la seguridad a esa escala será muy, muy complicado. Sí, por supuesto. Si pensamos en ello, utilicemos el ejemplo de la empresa con el que estoy muy familiarizado, y probablemente la mayoría de la gente también, si ampliamos la analogía de un agente como una persona, y creemos que es bastante apropiado, un agente necesita ser incorporado al equipo igual que una persona.

Y cuando te incorporas, te examinan, ¿puedes hacer el trabajo? ¿Tienes las habilidades y la capacidad para el trabajo? Um, una vez que te incorporas, tienes una identidad.

Y una vez que tienes una identidad como empleado, tienes un número de identificación de empleado. Se te otorgan, en función de tu trabajo, los permisos necesarios para realizar tu labor. Um, así que, la analogía que nos gusta usar es, um, al igual que, como habrás oído hablar de términos como RR. HH. o gestión de recursos humanos, creemos que las mismas disciplinas, las mismas prácticas, dentro de lo razonable, pueden aplicarse a los agentes.

Los agentes pueden incorporarse. Como mencionó Davis, los agentes tienen una identidad y una función, creemos, eh, por decirlo de otra manera, eh, y no sé si esto va demasiado lejos, pero al igual que tenemos prácticas de RR. HH. o recursos humanos, probablemente deberíamos pensar en prácticas de AR o recursos de agentes como mínimo. Es una buena analogía, pero creemos que en realidad va bastante lejos en términos de cómo se debe pensar en cómo proteger, eh, y gobernar la seguridad en torno a los agentes.

Sí. Eh, no, pero eso hace que, eh, sí, de nuevo, es, es, es bastante, eh, es, es, es mucho terreno nuevo, ¿verdad? Pero tiene sentido.

Um, entonces, uh, veamos el siguiente aspecto. Um, la fiabilidad. ¿Podemos, obviamente está relacionado con la seguridad, pero cuál es el aspecto de la fiabilidad de un agente de nivel empresarial?

Sí, claro. Voy a responder a esta pregunta basándome en la fiabilidad. Hay muchas definiciones diferentes.

Um, y dejaré de lado por un momento temas como la confianza, porque probablemente hablaremos de ello más adelante. Así que hablemos de la fiabilidad en un contexto muy específico.

Cuando decimos que algo es fiable, sabemos lo que hace, lo que se supone que debe hacer, eh, podemos observar si ha cumplido su función y, si no lo ha hecho, podemos arreglarlo. Eh, ese es un aspecto, y creemos que es especialmente importante para los agentes. Así que, no solo son detectables y podemos entender su propósito, eh, y pueden elaborar planes de tareas, sino que además podemos ver lo que han hecho.

Y si no hicieron algo, podemos ocuparnos de solucionarlo. La otra parte de la fiabilidad es: ¿está disponible cuando espero que lo esté? Y en ese contexto, se trata de las mismas disciplinas que aplicamos a algunas de nuestras aplicaciones que pueden estar en la nube o a algunas de las aplicaciones SaaS que podemos utilizar en nuestra organización.

Habrá expectativas de nivel de servicio en cuanto a su disponibilidad, el tiempo de respuesta o la latencia. Todas esas cosas son las que creemos que deberían aplicarse a los agentes. Ahora bien, lo interesante de esto es que estamos viendo que intentamos establecer analogías en la medida de lo posible con cosas que la gente realmente entiende.

La razón por la que lo hacemos, en primer lugar, es porque son bastante apropiados, pero desmitifica toda la idea en torno a los agentes. Y lo que nosotros, lo que encontramos es que cuando te pones el sombrero de arquitecto para decir que, um, los conceptos existen desde hace mucho tiempo. Así que, por ejemplo, los retos de la computación distribuida, que si tienes muchos agentes ejecutándose en la nube o en cualquier otro lugar, los problemas de distribuir los retos en torno a la computación distribuida, no son fáciles de resolver, pero son solucionables.

Es una práctica conocida. No quiere decir que sea fácil, pero es una práctica conocida. Así que las cosas relacionadas con la fiabilidad, son prácticas conocidas, creemos firmemente que deberías aplicar esas prácticas directamente a los agentes.

De nuevo, no es diferente a cualquier otra aplicación empresarial. Sí, no, tiene mucho sentido. Pero es que esa transición es difícil, ¿verdad?

Porque ha estado en manos de unos pocos empleados selectos. Y ahora, a medida que escalas algo, como, eh, como una red de agentes, básicamente, tendrás que, tendrás que multiplicar eso y difundir esos conocimientos de, de, de, de, de, de, eh, mm-hmm. Medidas para, para más empleados o, al menos, sí, construir, construir la arquitectura de tal manera que sea escalable.

Eso es, eh, súper, súper difícil. Eh, pero aún no hemos llegado ni a la mitad. Pero, eh, quizá no los cojamos todos.

Eh, también quiero dejar tiempo para preguntas, si hay alguna, de cualquiera de los participantes que tenga, eh, preguntas. Pero vamos, eh, vamos, pasemos a la siguiente, porque es obvia, ¿verdad? Explicabilidad, ¿qué es, cómo creamos agentes, eh, cómo los explicamos básicamente?

Sí, yo puedo empezar. Y luego Davis, sé que tú tienes opiniones muy firmes al respecto. Hoy en día, cuando lo analizas, voy a compararlo con lo que la gente puede estar utilizando hoy en día, Claude Code, por ejemplo, o Codex, o incluso Chat GPT, se puede ver que dice «pensamiento».

Y lo que realmente es, aunque no es exactamente un plan de tareas, es una especie de bucle. Pero explica lo que está haciendo. Así que, en realidad, puedes verlo si utilizas cualquiera de las herramientas de codificación modernas o agentes de codificación que existen hoy en día. Creemos que, si te adentras en el ámbito empresarial, donde los agentes participan plenamente en los procesos de negocio, no solo necesitas observar lo que hicieron después, sino también si hicieron lo correcto.

Entonces, cuando un agente presenta un plan de tareas en nuestro libro, en realidad recomendamos que ese plan de tareas sea un ciudadano de primera clase, eh, en, en la esfera de la observabilidad, eh. Mm-hmm. Es un ciudadano de primera clase en el sentido de que debe registrarse.

Y una vez que el agente completa su tarea y los resultados de la misma, deben adjuntarse de alguna manera o vincularse a ese plan de tareas. Y luego, cuando miramos las métricas de observabilidad, la latencia o cómo, ya sabes, si se completó con éxito o no, de nuevo, se adjunta de nuevo a ese plan de tareas. Así que lo que acaba sucediendo es que, cuando un agente hace su trabajo, podemos ver el plan de tareas, lo que pensaba que debía hacer, podemos examinar los resultados para ver qué tal lo ha hecho y podemos utilizar las métricas de observabilidad para ver con quién ha hablado para completar realmente esa tarea.

Ese nivel de explicabilidad no está disponible en la actualidad. Tenemos algo, estamos trabajando con algunos clientes con los que estamos empezando a avanzar por ese camino en particular. Pero los agentes de codificación que se ven hoy en día no tienen esa capacidad.

Los marcos de agentes no tienen esa capacidad hoy en día. Pueden ejercer partes de ella, pero la explicabilidad es esa comprensión de principio a fin, ¿qué estaba pensando?, ¿el plan de tareas?, ¿cómo obtuvo los resultados adjuntos al plan de tareas y la observabilidad? ¿Con quién habló, ya fueran herramientas u otros agentes, para completar realmente ese plan de tareas?

Eso es lo que significa ser de primera clase, un ciudadano de primera clase que queda registrado. De modo que cualquier persona encargada de la operatividad que encuentre un problema que deba diagnosticar, podemos utilizar eso en ese plan de tareas, los resultados y la lista de colaboradores para diagnosticar realmente el problema. Cuando eres desarrollador, te proporciona esa información para garantizar que tu agente se prueba y se depura realmente.

Hay tantos usos para esta explicabilidad, por eso creemos que es realmente uno de los, es algo que hoy en día no está fácilmente disponible, pero probablemente sea uno de los requisitos más importantes en la empresa actual. Y es algo que ocupa un lugar destacado en nuestro libro. Sí, por supuesto.

Davis, ¿quieres añadir algo al respecto, o seguimos adelante? Eh, la respuesta de Eric ha sido bastante buena. Ha cubierto gran parte del tema.

Eh, una cosa que sí quiero añadir es que no basta con que se haga un seguimiento del plan en sí. Lo que quieres es que el agente incluya explicaciones de por qué quieres hacerlo, quieres poder ver por qué el agente está haciendo lo que está haciendo, e incluir eso junto con los planes de tareas reales que se están ejecutando. Así que no solo ves que estoy planificando los pasos 1, 2 y 3, sino que quieres ver que estoy haciendo los pasos 1, 2 y 3 por las razones X, Y y Z.

Por supuesto. Muy bien dicho, Davis. Por supuesto.

Muy buen punto.

Eh, y estoy muy agradecido a los participantes que han publicado algunas preguntas, eh, en la sección de preguntas y respuestas. Eh, creo que deberíamos pasar a ellas en un momento. Eh, solo quería, recapitular aquí, lo hicimos, discutimos la seguridad, la fiabilidad y la explicabilidad.

Eh, para agentes de nivel empresarial. Todavía nos quedan por descubrir la escalabilidad, la capacidad de detección, la observabilidad y otras capacidades. Pero creo que deberíamos pasar a las preguntas que se han formulado en el chat.

Eh, creo que los participantes están aquí para que les respondamos a sus preguntas. Y luego, eh, quizá hagamos un par de entradas en el blog sobre los datos, la inteligencia, la plataforma Substack que tenemos, o incluso en nuestra página web, si os apetece. Pero, eh, pasemos sin duda a las preguntas del chat, eh, o de la sección de preguntas y respuestas, lo siento.

Eh, y veo ambas preguntas en, eh, en, en las preguntas y respuestas y en, um, vale, las tengo aquí. Eh, un momento. Entonces, eh, Ronald, Ronald de, um, Ronald Ban, creo que de los Países Bajos.

Es un placer tenerte aquí, eh, en este seminario en línea, seminario en línea, eh, seminario en línea. Y él pregunta: «Me interesa saber cómo evaluar a los agentes y mejorar sus habilidades o formarlos para que estén a la altura del trabajo, quién debe hacerlo y cómo hacerlo para que puedas tener agentes certificados para determinados trabajos». Supongo que es una pregunta de más alto nivel que aborda algunas de las cosas que hemos estado discutiendo, eh, o que ya hemos discutido en detalle, um, en las preguntas anteriores.

Pero, pero tal vez sea bueno dar un paso atrás y, ¿sientes, puedes sentir, eh, tengo mi propia definición de ello, pero no, no estoy seguro de poder dar una respuesta breve a esta pregunta, pero, vale, volvamos a intentarlo. ¿Quién debería, por ejemplo, me interesa saber cómo evaluar a los agentes y mejorar sus habilidades o formarlos para que estén a la altura del trabajo? ¿Quién debería hacerlo y cómo?

Bueno, bueno, déjame empezar, y luego Davis, eh, estoy seguro de que tienes algunas ideas. Um, sí, a primera vista, uno diría que probar un agente es lo mismo que probar software. Es un ejercicio muy diferente, en realidad.

Y la razón fundamental divertida, eh, es que si estoy probando software que es determinista, en otras palabras, que te da la misma respuesta, dadas las mismas entradas, entonces cosas simples como la desigualdad, el operador, um, son cosas obvias que se utilizan en las pruebas con agentes. No es necesario que tengas eso. Un agente obviamente tiene un LLM como cerebro, eh, por usar ese término.

Pero estos LMS no son deterministas. Lo que eso significa en lenguaje sencillo es que, si introduzco dos veces los mismos datos, obtengo una respuesta ligeramente diferente. Eso significa que el operador de igualdad tradicional en las pruebas ya no funciona.

Lo que hay que hacer es disponer de diferentes formas de evaluar realmente a un agente. Um, así que, en realidad lo consideramos más bien como una gestión del rendimiento o una evaluación del agente, en lugar de una prueba. Por eso creamos rúbricas, por ejemplo, que se basan en el nivel de autonomía y el nivel de criticidad.

Obviamente, si eres muy crítico y muy autónomo, vas a necesitar una capacidad de prueba y evaluación extremadamente rigurosa. Y puede que haya seis o siete dimensiones que dicten lo que puedes o no puedes hacer, o lo que tienes que hacer o no tienes que hacer. Si tienes algo que es de baja criticidad y baja autonomía, tal vez eso se acerque más a un chatbot, supongo.

Quizás no necesites hacer muchas pruebas. Por lo tanto, depende de dónde te encuentres en ese continuo. Lo segundo que diría es que, cuando pruebas un agente, lo que pensamos, y creo que hay, hay terminología en torno a esto.

Tienes un agente, un agente juez, que puede juzgar la respuesta de otro agente o un juez, LLM. Esas son cosas que nosotros, realmente vemos ahí fuera, en el campo. Entonces, usar un LLM para probar un LLM, ¿esa respuesta, tal respuesta, tal vez no sea necesariamente exactamente igual o repetible, pero la intención de la respuesta es la misma?

Ahí es donde vemos que las pruebas reales entran en juego. Lo llamamos evaluación. Ahora le voy a preguntar a Davis un poco sobre el aspecto de la formación.

Porque creo que Davis, eh, hay, hay un montón. Sé que tienes algo de experiencia con uno de nuestros grandes clientes minoristas hace un tiempo en torno a, eh, cómo empezarían realmente a intentar y, eh, volver a entrenar el modelo. Y hay algunos retos con eso.

Y se nos ocurrió, en aquel entonces, que probablemente eran soluciones bastante ingenuas, del tipo «trapo». Así que tal vez no se trate de «entrenar el modelo», sino de dotarlo de información sobre su empresa. ¿Por qué no nos cuenta un poco sobre eso?

Obviamente, sin mencionar al cliente. Sí. Así que hay varias formas de formar a un agente y aumentar sus capacidades.

Una de ellas es, obviamente, realizar una especie de entrenamiento del modelo subyacente, pero se trata de una solución muy pesada. Se necesitan muchos ejemplos, y hay que hacerlo para cada uno de los agentes con los que se va a trabajar. Simplemente no es escalable. Las formas de aumentar un agente o dotarlo de nuevas habilidades que se escalen de una manera algo mejor son proporcionarle más datos con los que trabajar o darle más herramientas o colaboradores para que se encarguen del trabajo.

Puedes proporcionarle una nueva herramienta que le otorgue una nueva capacidad para interactuar con el mundo. Al escribir esa capacidad de la herramienta y hacer que el agente simplemente la incluya en el plan de tareas, puedes proporcionarle colaboradores adicionales, otros agentes con los que pueden contactar y que tienen capacidades que tu agente principal no tiene, y que simplemente puede llamar a esos agentes y hacer que realicen la tarea. O puedes proporcionar al agente más datos de forma eficaz.

Se podría hacer un análisis relativamente simple, se podrían aplicar soluciones más avanzadas como grafos de conocimiento, cosas así, para obtener más información. Y esto permite a la IA tomar mejores decisiones porque dispone de más información. Y estas son las principales formas en las que se va a formar o mejorar las habilidades de un agente que se adapta a los miles y miles de agentes que esperamos tener finalmente.

Sí, no, quiero abordar la última parte de la pregunta de Ronald sobre la certificación, porque, de hecho, dedicamos un capítulo entero a ello. Es parte de nuestro marco de confianza.

Entonces, una vez más, perdóname, voy a usar otra analogía, en Canadá, y sospecho que es lo mismo en Europa, pero cuando compro una tostadora en Canadá, veo un pequeño logotipo en la parte inferior que se llama Canadian Standards Association (Asociación Canadiense de Normas). Lo que dice es que mi tostadora no va a incendiar mi casa cuando la use. Lo que dice es que esa marca significa que hay un nivel de expectativa de servicio, de calidad, en torno a eso, esa etiqueta significa que esa tostadora está certificada.

Eh, en Estados Unidos, tienen el laboratorio Underwriters Lab que hace lo mismo. Eh, en Europa, no estoy seguro, pero en Canadá, de nuevo, si miro una toma de corriente, puedo ver un pequeño logotipo que dice que esta toma de corriente es segura de usar. Creemos que la misma idea se aplica a los agentes, y creemos que es el nivel más alto de esa pila de gobernanza.

La pila de confianza, en realidad, comienza con la identidad y las funciones, avanza a través de la explicabilidad, pero, fundamentalmente, en la parte superior de la estructura, lo que tenemos es la certificación y la gobernanza. Creemos firmemente que hoy en día existen modelos, como la Asociación Canadiense de Normalización, Underwriters Lab, sus modelos de gobernanza federada, modelos de certificación federada, que cada día son capaces de certificar que literalmente millones, cientos de millones de productos son seguros de usar. Creemos que esa misma idea se puede aplicar a los agentes.

Por lo tanto, creemos que el modelo, una vez más, está diseñado para nosotros. Es allí donde, entre otras cosas, existe un marco completamente delegado que dice: «Tengo políticas a nivel macro que debo cumplir, y luego se detallan las especificaciones eléctricas para una tostadora, las especificaciones de calefacción, el metal para el recipiente de la tostadora». Todas esas cosas tienen un marco de especificaciones federado y un marco de gobernanza federado e instituciones acreditadas.

Esto suena muy, muy complicado, ¿verdad? Y si gestionas cientos de millones de productos, quizá debería serlo, pero dentro de la empresa, este modelo también funciona. Así que, en el nivel superior, podríamos decir, por ejemplo, que un agente debe cumplir con el RGPD.

Ese, a su vez, delega en un agente de verificación de identidad. Y se le ocurren implicaciones sobre cómo ese agente de verificación de identidad cumpliría con el RGPD. Y eso se aplicaría también a todos los demás agentes.

Entonces, tal vez lo que deberíamos tener es un conjunto de especificaciones técnicas, nuevamente, desglosadas en particular por ámbito empresarial, probablemente a un nivel granular. Y luego lo que tenemos es que esas especificaciones cuentan con expertos que realmente pueden validar esa especificación y que, utilizando el enfoque de explicabilidad que mencionamos anteriormente, ese agente realmente se adhiera a esa especificación. Creemos que ese modelo, metafóricamente, garantizará que su agente no queme su centro de datos.

Entonces, vemos muchos ejemplos y analogías que simplifican el viaje de una empresa. Y están justo delante de nosotros. Ole Sí, no, tiene sentido.

Quiero decir, se trata realmente de tomar algunas perspectivas sorprendentemente concretas del mundo actual y simplemente aplicarlas a la realidad agrícola. Y también veo, Ronald, gracias por respondernos y por dar una respuesta tan completa. También tenemos preguntas de Michael y de Sabrina.

Hola a los dos. Me alegro mucho de teneros en el seminario en línea. Michael, empezaré por ti.

Veo que tú has publicado primero, pero también he visto tu pregunta, Sabrina. Michael Wright tiene curiosidad por conocer las perspectivas de los participantes sobre el impacto de la capa semántica definida por las empresas en los proveedores de servicios de IA, concretamente a diferencia de la del sistema sanitario Epic e HR o la plataforma sub EP, que generalmente obligan a sus clientes a adoptar gran parte de sus flujos de trabajo, roles de usuario, etc., y comparar eso con lo que significa tener una arquitectura Gentech definida por la empresa, cómo y cómo anticiparse a los proveedores de servicios de IA, la IA abierta y la capacidad de escalar adecuadamente sus negocios si sus clientes necesitan su propia capa romántica definida de forma única. Sí, entiendo la pregunta.

¿Lo entiendes? ¿O es demasiado largo? No, no, lo estoy leyendo.

De hecho, lo tengo delante de mí, en la pantalla. En primer lugar, Michael, esa es una pregunta fantástica y creo que es muy oportuna por varias razones. Ahora bien, no soy un experto en catálogos de datos ni en el espacio semántico, Ole probablemente sí lo sea, pero déjeme decirle que sí me encuentro con ello y tengo una perspectiva porque lo vemos en casi todos los proyectos en los que trabajamos con nuestros clientes.

Entonces, déjeme dar un paso atrás y partir de algunos conceptos básicos sencillos. Cuando un agente intenta responder a una solicitud, como ha mencionado Davis, cargamos información sobre ese negocio o sobre ese tema lo más cerca posible de esa solicitud, de modo que el agente tenga toda la información disponible. Eso se llama ingeniería de contexto, donde queremos encontrar el contexto adecuado en el momento adecuado para el presupuesto de tokens adecuado y ponerlo en la ventana de contexto del agente para que pueda hacer su trabajo de la manera más eficaz.

El reto es que, en una empresa que tiene cientos de terabytes o petabytes de información, un corpus, ya sean datos estructurados, datos no estructurados, imágenes, vídeos, hay petabytes de ese material ahí fuera. ¿Cómo obtengo la información correcta de esos petabytes? Y la obtengo de lo que efectivamente es entre 200 000 y un millón de tokens, siendo un token más o menos una palabra, solo para, para, para, para hacerlo, eh, real.

Eh, entonces, entonces, ¿cómo lo hago? Bueno, lo que hemos descubierto es que para hacerlo, bueno, esto es lo que llamamos, necesitas tener un ag, un conocimiento agencial, una estructura, una palabra elegante para decir que necesito ser capaz de identificar, necesito tener un gestor de contexto virtual que cree lo mínimo. Hago hincapié en lo mínimo porque es un presupuesto simbólico viable, lo que significa que tiene conceptos y políticas, límites de decisión, y puedo poner eso en los agentes o en la ventana de contexto de los LLM.

Para ello, se pueden utilizar varios enfoques diferentes. Técnicamente, se puede hacer un registro ingenuo, como ha mencionado Dave, aunque probablemente no funcione muy bien. Se puede complementar con grafos de conocimiento.

Bueno, hay una gran variedad de cosas diferentes. Hemos hablado con algunos clientes que utilizan cosas como el rango de página para, en realidad, comprender y vincular los conceptos en un gráfico muy grande y amplio, fundamentalmente. Bueno, ese es un mecanismo en el que hay que pensar, pero la forma de darle sentido es a través de taxonomías y ontologías.

¿Cuáles son los conceptos que debería capturar? ¿Cómo represento realmente una política, eh, en un gráfico de conocimiento? Eh, ¿cómo manifiesto realmente, eh, las relaciones entre estas políticas que pueden aplicarse a un cliente en el sentido del aprendizaje automático, en el sentido de la lucha contra el blanqueo de capitales, que es diferente a un cliente desde el punto de vista de las ventas, los atributos son muy, muy diferentes.

Así que todas estas son cosas en las que hay que pensar, y lo llamamos «estructura de conocimiento agencial», que tiene como base, como he dicho, un gráfico de conocimiento, una ontología y algunas capacidades taxonómicas. Pero, en última instancia, lo que se necesita es consistencia semántica, coherencia semántica, para poder proporcionar la información adecuada, en el momento adecuado y con el presupuesto adecuado al agente. El LLM ve la comprensión semántica, las taxonomías, las ontologías, todo ello situado en la parte superior de esta estructura de conocimiento como la próxima innovación dentro del panorama de los agentes.

Sin duda, eso es algo que también estoy siguiendo muy, muy de cerca y en lo que estoy pensando. Eh, y, eh, obviamente este seminario en línea no seminario en línea sobre la acción como empresa. Así que, por respeto a los participantes, no creo que deba entrar en ello aquí, pero eso está, creo, eh, muy precisamente, um, definido y es uno de los retos que tenemos que resolver, um, eh, en el tiempo común.

Bien. Eh, tenemos una pregunta de Sabrina, y he visto tu pregunta, Sabrina, así que voy a seguir adelante y te la voy a hacer. Eh, bueno, en realidad, también tiene que ver un poco con las pruebas, así que, en la medida de lo posible, voy a seguir adelante y te la voy a hacer, pero creo que, en realidad, ya la has respondido.

Eh, ¿también lo ves, eh, Eric y Davis en el Sí, yo, yo lo he visto, Lee. Sí, lo he visto en seminario en línea . Sí, lo veo.

¿Qué, cuál es tu...? Quizás deberíamos DA Davis. Eh, ¿tenías algo que añadir sobre esta pregunta? Eh, creo que gran parte ya se ha cubierto en la respuesta anterior, pero quizá valga la pena repasar algunos puntos de nuevo.

Una de las primeras cosas que se mencionan es ¿quién debería escribir las pruebas? ¿Deberían escribirlas los agentes, los humanos o ambos? Y esto dependerá en gran medida de la madurez de tu red de identidades en la fase inicial, cuando estás creando tu primer agente, o incluso tus primeras docenas de agentes, tiene sentido que la mayor parte de las pruebas las realicen personas.

Todavía estás aprendiendo a manejar los agentes, por lo que querrás realizar una evaluación manual. Pero a medida que la red ENT crezca, cuando tengas miles y decenas de miles o más agentes, tendrás que empezar a confiar más en los agentes eficaces, los agentes de prueba, simplemente para gestionar a la escala necesaria, donde no tienes suficiente personal para comprobar manualmente cada resultado cada vez. No vas a eliminar por completo las pruebas humanas.

Seguirás necesitando personas que comprueben que las pruebas son realmente correctas, que hagan controles aleatorios, que se aseguren de que nada ha salido mal, pero cuánto es humano o cuánto es la edad, dependerá de lo maduro que seas, de cómo estés desarrollando tu propia malla de proyectos. Sí, Davis, una de las cosas de las que hablamos es, um, y sé que tuvimos grandes debates con, uh, algunas de las otras personas de nuestra empresa y algunos clientes, pero, uh, cuando piensas en la autonomía, la alta autonomía y la alta criticidad, um, hay, hay una discusión que dice que es para algunos de esos muy altamente autónomos y altamente críticos, yo, en otras palabras, escenarios de alto riesgo que, al menos hoy en día, tal vez esto cambie en el futuro, pero en un futuro previsible, creemos que esos, hay un subconjunto que debe tener interacción humana y debe tener verificación humana, cosas relacionadas con la salud, por ejemplo, tal vez pagos de alto valor, por ejemplo, donde puede haber alguna exposición al fraude o aprendizaje contra el lavado de dinero. Hay un subconjunto de las pruebas que creemos que, en un futuro previsible, deben permanecer, o al menos tener a ese humano en el bucle o al humano por encima del bucle, explícitamente.

Sí.

Eh, creo que, eh, ahora que nos acercamos al final, me gustaría, eh, hacer la última pregunta que había preparado, y luego podemos volver a los temas restantes de debate, eh, en las publicaciones. Pero sí quiero preguntarte, eh, ¿cómo fue escribir este libro? Eh, porque supongo que todos los libros te provocan una sensación determinada.

Lo son, pueden ser demasiado pronto, eh, pueden ser acertadas, pueden ser demasiado tarde, pueden provocar diferentes tipos de reacciones. ¿Cuál ha sido la respuesta hasta ahora? ¿Es demasiado pronto?

¿Tú también? Supongo que no llegas demasiado tarde. Bueno, sí, bueno, déjame empezar y luego, eh, dejaré que Davis responda cómo fue trabajar con su padre, supongo.

Pero, eh, pero, pero lo que yo diría es que cuando Davis y yo se nos ocurrió la idea de este libro, fue, Ole Knows this, escribió algunos libros con O'Reilly. Hay un, hay un largo proceso. Así que esto fue hace unos 16, 14 o 16 meses, cuando no sabíamos cómo iba a evolucionar el panorama de los agentes.

Eh, nosotros, no existía nada parecido a Claude Code o Codex and Chat. GPT todavía estaba en la versión 3.5 o algo así. No era muy, eh, eficaz, para ser sincero, al menos no en comparación con hoy en día.

Era, era maravilloso en su día, pero comparado con hoy, no era, um, no era realmente lo que tenía que ser. Um, curiosamente, volvimos a fijarnos en la analogía, en las analogías. ¿Qué pasó en la empresa cuando pasaste de uno a muchos?

Bueno, hace tiempo trabajé mucho con API, y cuando tienes una, dos o tres API, lo cual fue hace mucho, mucho tiempo, es fácil gestionarlas. Pero cuando tienes 10, cien o mil API, tienes que pensar de una manera muy, muy diferente. Lo mismo ocurre con los productos de datos.

Si tienes uno o dos productos de datos, eso es interesante, pero cuando tienes 10, cien, eh, más de cien, como algunos de mis clientes, estás hablando de una forma diferente de pensar al respecto. Hay que pensar en diferentes prácticas de gestión. Así que cuando Davis y yo se nos ocurrió la idea de este libro, y cuando se la presentamos a O'Reilly, ese fue el argumento: no íbamos a quedarnos con un solo agente.

Vamos a tener, ya sabes, decenas, cientos, miles. Y los líderes del sector lo han confirmado. Así que, una respuesta larga y tediosa es que Olay, creemos que estamos en el momento adecuado y en el lugar adecuado, lo cual no sabíamos hace 16, 14, 16 meses, pero tenemos la suerte de estar ahí ahora mismo.

Bueno, sí, eso es lo que yo también pienso. Eh, Davis, ¿quieres aportar algo? Quiero saber los detalles sobre cómo fue escribir con tu padre.

Sí, escribir con mi padre fue una experiencia fantástica. Obviamente, nos conocemos muy bien y estamos en la misma onda cuando hablamos de nuestras ideas. Sin embargo, fue bastante diferente al trabajo de consultoría que solemos hacer juntos, sobre todo porque mi padre tiene mucha más experiencia escribiendo libros que yo al principio de este proyecto.

Y estoy muy contenta de haber escrito el libro con alguien que tenía esa experiencia , ya que resultó muy útil para que el libro alcanzara los altos estándares que nos habíamos fijado. Sí, no, tiene mucho sentido. Quiero decir, también es, y, bueno, realmente, realmente, es una experiencia muy, muy diferente, eh, escribir con, eh, otra persona y escribir un libro por primera vez.

Pero también creo que, si tuviera que decir algo sobre el momento en que se ha publicado tu libro, creo que es el momento adecuado, porque no es algo que todo el mundo vea ahora mismo. Ven que tenemos que pensar en crear arquitecturas en nuestra empresa, y también entendemos que no es algo que se pueda tomar a la ligera. Será complicado ponerlo en marcha, ¿verdad?

Creo que el libro es muy oportuno y es una lectura muy interesante. Bueno, con estas palabras, quiero darles las gracias por participar en este seminario en línea hoy seminario en línea . Volveremos con más ideas en publicaciones y escritos compartidos.

Puedo garantizarle, eh, que será más que bienvenido para escribir, eh, para nosotros. Y yo estaría encantado de escribir, eh, con usted. También quiero agradecer a todos los participantes, eh, su paciencia.

Esto ha sido, eh, supongo que seminario en línea un poco técnico, pero también muy necesario. Así que gracias a todos por escuchar y, eh, gracias a Eric y Davis. Bueno, Ole, muchas gracias a ti y a todo el equipo de Acton por invitarnos.

Muchas gracias. Yo también les doy las gracias. Ha sido un placer participar.

Gracias.