Modo de interacción

Es un error pensar en una solicitud a un LLM de la misma manera que al llamar a una función. Dado el mismo conjunto de entradas en el mismo orden, una función actúa de manera predecible. Podemos escribir pruebas, inyectar fallos y robustecer una función para una amplia variedad de entradas.

Un LLM no es así. Una mejor manera de pensar en ello es como si el LLM fuera un usuario y tratar los datos que obtenemos de él como tales. Al igual que un usuario, un LLM es no determinista, a menudo se equivoca (parcial o totalmente) y a veces es simplemente aleatorio. Para proteger nuestras aplicaciones bajo estas condiciones, necesitamos construir los mismos límites de seguridad alrededor de la entrada del LLM que los que construimos alrededor de la entrada del usuario.

Si podemos hacer eso con éxito, entonces podemos aportar capacidades extraordinarias a las aplicaciones en forma de resolución de problemas y creatividad que pueden rivalizar con las de un ser humano.

Los LLM son buenos en algunas cosas y malos en otras; la clave es introducirlos en tus aplicaciones para lo bueno, mientras mitigas lo malo. Como ejemplo, consideremos la lista de tareas en el Crossword Companion:

La lista de tareas es el conjunto de pistas que necesitan ser resueltas. El objetivo es usar colores y soluciones en la lista de tareas para mostrar el progreso durante el proceso de resolución. La implementación inicial proporcionaba al modelo una herramienta para gestionar la lista de tareas, pidiéndole que proporcionara actualizaciones sobre el progreso a medida que avanzaba. Flash no pudo resolver el crucigrama de esta manera, pero Pro sí. Desafortunadamente, lo resolvió en grandes bloques, recordando actualizar la lista de tareas solo una o dos veces con un gran retraso de por medio. Ninguna cantidad de prompts pudo convencerlo de actualizar las tareas a medida que avanzaba. Verás este mismo comportamiento en los agentes de IA modernos que gestionan sus propias listas de tareas; ahí es donde nos encontramos en la evolución de los LLM en este momento.

Entonces, ¿cómo obtenemos actualizaciones consistentes y deterministas de la lista de tareas? Saca la gestión de tareas de las manos del LLM y manéjala en el código.

Para generalizar, antes de aplicar una solución de LLM a un problema que enfrentas, pregúntate si un LLM es la mejor herramienta para el trabajo. ¿Vale la pena el intercambio en la impredecibilidad por la creatividad y resolución de problemas al estilo humano?

La respuesta a esa pregunta viene con la experimentación. Aquí hay algunos ejemplos del código de muestra:

Sin duda es una decisión de criterio, pero si puedes escribir razonablemente el código para hacerlo, tus resultados serán predecibles. Sin embargo, si escribir el código fuera extremadamente difícil, entonces considera un LLM, sabiendo que tendrás que construir los límites de seguridad como lo hicimos en el ejemplo de muestra.

Hay más de un punto de decisión a considerar además de código vs. LLM. Los modelos operan aproximadamente en dos modos: "ask" y "agent".

Un LLM está en modo "ask" cuando le hacemos un prompt sin darle herramientas para realizar cambios en el mundo, por ejemplo, sin herramientas en absoluto o con herramientas solo para buscar datos. Tanto el modelo de inferencia del crucigrama como los modelos de resolución de pistas se ejecutan en modo "ask", usando herramientas solo para datos adicionales.

Por otro lado, cuando le damos a un LLM un conjunto de herramientas que le permiten operar en nuestro nombre en el mundo (como leer y escribir archivos, ejecutar comandos de bash, cargar páginas web, llamar a las API web, etc.), ese LLM está en modo "agent".

La diferencia entre el modo "ask" y "agent" no es el modelo que eliges o los prompts que le das, sino las herramientas que le proporcionas. La combinación de las herramientas y el bucle agéntico descrito en la sección de llamadas a herramientas (Tool calls) permiten a un LLM llamar a cualquier cantidad de esas herramientas con la frecuencia que decida. Darle ese poder pone la responsabilidad en ti de asegurarte de tratarlo como algo impredecible; más parecido a una persona que a un programa.

Haces eso de la misma manera que validas la entrada del usuario, creando un conjunto de pruebas para ver cómo funciona tu aplicación frente a las respuestas del LLM. Dale a los LLM reales una amplia variedad de prompts y simula (mock) las herramientas para evaluar cómo las está usando el LLM. Al igual que tu primera experiencia de pruebas con usuarios, tus primeros resultados de pruebas con LLM podrían sorprenderte. Utiliza esos datos para construir los límites de seguridad que necesitas para robustecer tu aplicación.

En la muestra, no tuvimos que protegernos contra daños, pero sí tuvimos que protegernos contra resultados imperfectos. Fueron las pruebas exhaustivas con datos del mundo real las que llevaron a la instauración de protecciones con intervención humana (human-in-the-loop) para evitar intentar resolver un crucigrama inválido o soluciones en conflicto. De esta manera, Flutter y Firebase AI Logic forman la combinación perfecta para aprovechar el poder de un LLM y aportar capacidades únicas a tus aplicaciones.