Codificación conjunta: Incorpora la IA en el dispositivo a tu app mediante la estructura Foundation Models

Hola, soy Naomy. Sumerjámonos en el mundo de SwiftUI y la inteligencia en el dispositivo. En esta codificación guiada, exploraremos cómo agregar nuevas funciones a tus apps usando la estructura Foundation Models. Te guiaré a través de un ejemplo paso a paso mientras creo una app que planificará mi próximo viaje. La estructura Foundation Models brinda acceso directo al modelo de lenguaje grande en el dispositivo Apple, ¡y las posibilidades de lo que puedes crear son realmente infinitas! Todo esto se ejecuta en el dispositivo, por lo que los datos de los usuarios pueden permanecer privados. El modelo está fuera de línea y ya está integrado en el sistema operativo. No aumentará el tamaño de tus apps. Con esta estructura, crearemos funciones potentes, privadas y de alto rendimiento en macOS, iPadOS, iOS y visionOS. Mis amigos y yo queremos ir de viaje, pero necesitamos inspiración sobre adónde ir y qué hacer. Planificar puede ser difícil, pero usar la estructura Foundation Models es fácil. ¡Usémosla para crear una app que hará todo el trabajo de planificación por nosotros! Esto es lo que crearemos hoy. En mi app, la página de destino muestra varios lugares destacados que podemos recorrer. ¡Esos árboles se ven interesantes! Seleccionemos Joshua Tree. ¡Podemos tocar el botón Generate y ahí es donde el modelo hará el trabajo por nosotros! Creará un itinerario y usará la llamada a herramientas para elegir de forma autónoma los mejores puntos de interés para nuestro punto de referencia. Creo que a mis amigos les gustará esta app, ¡así que comencemos a crearla! Hay unos pasos para usar la estructura que veremos hoy. Todo comienza con una ingeniería rápida. ¡Te mostraré cómo perfeccionar tus indicaciones usando playground de Xcode! Usaremos la llamada a herramientas para complementar el modelo, permitiéndole contactar fuentes externas para obtener puntos de interés para nuestros puntos de referencia. ¡Transmitiremos la salida para comenzar a mostrar nuestro itinerario a medida que el modelo lo genera! Perfilaremos nuestra app y aplicaremos optimizaciones para obtener un excelente rendimiento con la estructura Foundation Models. Un buen mensaje es la clave para obtener grandes resultados. A menudo, la generación de indicaciones puede ser una tarea tediosa que requiere mucha iteración. Podría ejecutar la app, examinar el resultado, cambiar el mensaje, volver a ejecutarlo y repetir todo, pero estaría aquí todo el día y no tendría tiempo para viajar. ¡Afortunadamente, la función Playground actualizada de Xcode está aquí para ayudar! Primero, asegúrate de habilitar el lienzo.

Esto es como las vistas previas de SwiftUI, pero nos dará comentarios en vivo para cualquier código Swift. Ahora, en cualquier archivo del proyecto, puedo importar Playgrounds y escribir un #Playground para iterar en mi código.

Empecemos con lo básico. Importaré Foundation Models, crearé una sesión y realizaré una solicitud.

En el mensaje escribiré: “Crear un itinerario” y, justo cuando escribí, se ejecutó automáticamente y podemos ver los resultados en el lienzo.

Eso fue un poco impreciso, ¿no? Comenzaré agregando una ubicación.

El mensaje es mucho mejor. Esta vez tenemos un itinerario. Por ahora me conformo, y siempre puedo volver y ajustar el mensaje más tarde. Descubrimos lo fácil que es comenzar a usar Foundation Models, dando un mensaje y recibiendo una cadena como salida. Pero para mi itinerario, realmente quiero una salida más estructurada. Quiero representar el resultado usando mis estructuras de datos, pero no quiero preocuparme por analizar la salida del modelo. La generación guiada permite que el modelo cree automáticamente las estructuras de datos que quiero, siempre que las anote como Generables. Pongamos esto en práctica. Tengo una estructura de itinerario aquí que me gustaría que el modelo generara. Importo Foundation Models y pongo la anotación Generable.

El único requisito de Generable es que los tipos de las propiedades también sean Generables. Afortunadamente, los tipos comunes como cadena se pueden generar de manera inmediata. Si tienes tipos anidados, como DayPlan aquí, entonces también puedes hacerlos generables. Ahora que tenemos una jerarquía de tipos completamente generable, podemos dejar que el modelo genere estructuras de itinerario como respuesta. Si deseas tener un mayor control sobre la salida, la macroguía te permite restringir los valores de las propiedades. Por ejemplo, como haré con el título aquí, puedes agregar una guía con una descripción.

También podemos restringir una propiedad a un subconjunto conocido de valores.

Puedo agregar un recuento para asegurarme de que mi selección de días siempre tenga exactamente tres elementos e incluso usar múltiples guías para una propiedad. Agregaré algunas guías más a mis propiedades.

Las descripciones de la guía son realmente otra forma de dar indicaciones al modelo. Te recomiendo mucho ver el video “Deep Dive”, donde Louis te contará todo sobre la generación guiada. Y ahora que tenemos nuestro mensaje y nuestro tipo Generable, podemos juntarlo todo.

Este es nuestro Planificador de itinerario, donde guardaremos toda la lógica de Foundation Models.

Continuemos y creemos una sesión.

Y le daremos instrucciones. Puedo usar la API de construcción aquí para crear mis instrucciones con facilidad. En este cierre, puedo pasar múltiples cadenas e instancias de mi tipo Generable. Las instrucciones son una forma de dar indicaciones de nivel superior. Aquí definiré cuál es el trabajo del modelo.

Nos gustaría un itinerario y le daré al modelo información sobre el punto de referencia seleccionado.

Incluir un ejemplo es genial, porque le da al modelo una mejor idea del tipo de respuesta que estoy buscando.

Y puedo pasar una instancia de mi estructura Itinerario, que se define a continuación utilizando un viaje a Japón.

Debido a que mi estructura de Itinerario es generable, Foundation Models la convierte en texto que el modelo pueda entender. Ahora, tenemos todo listo para realizar la solicitud, con el tipo Generable como salida.

En el mensaje, le pediremos explícitamente al modelo un itinerario.

Y para unir todo, establezcamos el itinerario según la respuesta del modelo.

El paso final es mostrar esto en nuestra interfaz de usuario. Hagamos que ItineraryPlanner sea observable, para que la IU pueda saber cuándo se genera el itinerario.

Agreguémoslo como una propiedad de estado a LandmarkTripView, para que la vista se actualice a medida que cambian los contenidos del planificador.

Si lo inicializamos aquí, se recrearía innecesariamente aun cuando la vista no aparezca en la pantalla, lo que tiene un costo de rendimiento indeseable. Es mejor posponer la creación del objeto usando un modificador de tarea. Así que agreguemos una tarea e inicialicemos el planificador aquí.

Esto solo se llamará una vez cuando aparezca la vista. Cuando recibimos un itinerario del modelo, podemos visualizarlo.

Voy a usar otra vista llamada ItineraryView. En él, mostraré el título y agregaré algo de estilo.

Haré lo mismo con la descripción y justificación.

Mostraré las propiedades de itinerario restantes de forma similar usando las otras vistas. Para generar un itinerario básico, el modelo usará la descripción en las instrucciones. Vamos a llevarlo un paso más allá. La estructura ofrece un protocolo de herramientas flexible que permite al modelo incluir información externa en sus respuestas. Puedes explotar tu creatividad: desde usar personas en los contactos del teléfono hasta eventos en el calendario o incluso contenido en línea. El modelo decide de forma autónoma cuándo invocar tus herramientas y con qué frecuencia. Para especializar aún más mi app de planificador, crearé una herramienta que recurra a MapKit para buscar los mejores puntos de interés para un punto de referencia. Para crear una herramienta, deberás cumplir con el protocolo de herramientas.

Esto incluye un nombre único para la herramienta, una descripción en lenguaje natural de cuándo llamar a la herramienta y una función de llamada, con argumentos que tú defines. Comencemos a componer nuestra herramienta. Importaremos Foundation Models y MapKit.

Tengo una estructura de datos ajustada al protocolo de la herramienta, con un nombre y una descripción.

La estructura coloca estas cadenas en las instrucciones automáticamente, para que el modelo pueda entender lo que hace tu herramienta y decidir cuándo llamarla. Una herramienta también puede recibir información del usuario, como el punto de referencia que seleccionó.

Agrego una enumeración para hacer que la herramienta busque distintos tipos de puntos de interés.

El modelo usará su conocimiento del mundo para decidir qué categorías son más idóneas para un determinado punto de referencia. Por ejemplo, sería más probable encontrar un puerto deportivo en la Gran Barrera de Coral que en algún lugar seco y en un desierto, como Joshua Tree. El modelo generará esta enumeración, y es por esto que debe ser generable.

Luego, definiremos la estructura Arguments, que usa la enumeración, junto con una consulta en lenguaje natural.

Para la implementación, existe el método de llamada, que es cómo el modelo invocará tu herramienta cuando decida hacerlo. Anteriormente, escribí algo de lógica de MapKit, que realiza una solicitud, usando la consulta en lenguaje natural como entrada, y obtiene puntos de interés dentro de un rango de 20 km de las coordenadas de mi punto de referencia.

Haremos una búsqueda con las restricciones solicitadas y devolveremos los resultados.

Luego, podemos implementar el método de llamada. Contactemos con MapKit, filtremos los resultados y devolvamos la salida.

Y eso es todo lo que se necesita para definir una herramienta que obtenga información de MapKit. Para conectarlo, volvamos al ItineraryPlanner.

Aquí está la sesión que creamos antes. Crearé una instancia de la herramienta con el punto de referencia que el usuario seleccionó como entrada.

Podemos pasar la herramienta al inicializador de sesión.

Esto es suficiente para hacer que el modelo llame a nuestra herramienta, pero incluso podemos hacer solicitudes adicionales si queremos que se invoque con más frecuencia. Podemos pedir explícitamente al modelo que utilice nuestra herramienta y categorías.

¡Y ahí lo tienes! ¡Está todo listo para probarlo! De hecho, si no tienes un dispositivo de prueba a mano, no hay problema. Si tu máquina de desarrollo ejecuta la versión más reciente de macOS y tiene Apple Intelligence activado y listo, entonces podemos ejecutarlo en los simuladores del iPhone y Vision Pro. Seleccionemos Joshua Tree y pidamos un itinerario.

Ahora, puedes notar que esto está tardando un poco. Esto se debe a que el modelo nos devuelve toda la salida a la vez, por lo que esperamos a que se genere cada actividad antes de recibir un resultado. No te preocupes, porque más adelante te mostraré cómo acelerar este proceso. ¡Y listo, recibimos un itinerario divertido!

Pero en realidad olvidamos algo muy importante. Asumimos que Foundation Model en el dispositivo siempre está disponible, pero este no siempre es el caso. La disponibilidad del modelo depende de la disponibilidad de Apple Intelligence, y es posible que este no sea compatible, no esté activado o listo para un dispositivo determinado. Por lo tanto, es importante verificar el estado del modelo y gestionarlo en consecuencia en la interfaz de usuario. En lugar de tener que probar esto con dispositivos físicos, o desactivar Apple Intelligence solo para fines de prueba, podemos usar una buena opción de esquema en Xcode.

En el esquema, podemos ver la anulación de la disponibilidad de los Foundation Models. Actualmente, está desactivado. Cualquiera de estas tres opciones impide que los modelos estén en el dispositivo. Así que prosigo y elijo uno, intento generar un itinerario y veamos qué sucede en la app.

Vaya, eso no es bueno. Aquí solo mostramos un error, y tampoco es realmente procesable. Necesito volver atrás y considerar cómo integraré la disponibilidad en mi app. Consideremos los tres casos que mostré antes. Si el dispositivo no puede obtener Apple Intelligence, no tiene sentido mostrar el botón Generate Itinerary. Al seleccionar un punto de referencia, permitamos que el usuario vea una breve descripción de este, usando los datos sin conexión en la app. En el segundo caso, el dispositivo es capaz, pero simplemente no fue incorporado a Apple Intelligence. Debemos informar al usuario que este es el motivo por el que el planificador de itinerario no está disponible. Puede decidir si desea suscribirse y acceder a la función. Model Not Ready significa que se necesita más tiempo para que el modelo termine de descargarse. Podemos decirle al usuario que lo intente de nuevo más tarde, ya que la función pronto estará disponible.

Ahora que diseñamos el comportamiento de la app, podemos aprovechar la API de disponibilidad para determinar en qué estado de disponibilidad está nuestro dispositivo. En la vista, agregaré una variable para el modelo que estoy usando: el modelo de lenguaje del sistema.

Luego, podemos activar el estado de disponibilidad y continuar con el mismo comportamiento que antes.

Avisemos al usuario cuando Apple Intelligence no esté activado.

Si el modelo no está listo, le diré que lo intente de nuevo más tarde.

De lo contrario, ocultamos el botón de itinerario y simplemente mostramos nuestro dato curioso.

La anulación de Foundation Models está en el esquema configurada como Device Not Eligible. Vamos a intentar este caso de nuevo.

Mucho mejor. Ahora, solo vemos un dato curioso, y se eliminó el botón Generate Itinerary para evitar que el usuario siga un camino que su dispositivo no admite. Si vemos hacia atrás, la app espera a que se genere el itinerario completo antes de mostrarlo en la IU. Si transmito el itinerario a medida que el modelo lo produce, puedo empezar a leer sugerencias de inmediato. Para usar la transmisión, cambiaré el método de respuesta que llamamos.

En lugar de obtener un itinerario completo, obtenemos una versión parcial. Podemos utilizar la estructura de datos PartiallyGenerated que se crea automáticamente. Esta es la estructura generable, pero con todas las propiedades opcionales. Entonces, cambiaré el tipo esperado del itinerario.

El resultado ahora será una nueva secuencia asíncrona con el tipo PartiallyGenerated como salida.

Cada elemento del flujo es una versión actualizada incrementalmente del itinerario. Por ejemplo, el primer elemento podría tener un título, pero las demás propiedades serían nulas. El segundo elemento podría tener un título y una descripción, y así sucesivamente, hasta que recibamos un itinerario completamente generado. Necesito extraer estas propiedades en las vistas. Es bueno pensar cuáles de tus propiedades se pueden mostrar de forma independiente. En mi caso, el itinerario tiene un título, una descripción y los planes del día, y este orden tiene sentido. Haré que el itinerario sea parcialmente generado y desarrollaré título, descripción y justificación.

Ahora, la lista de días:

También tengo que mostrar los planes diarios parcialmente generados. Es fantástico que las estructuras PartiallyGenerable se puedan identificar automáticamente, así no tengo que administrar los identificadores manualmente. Puedo usar forEach de SwiftUI con mis estructuras parcialmente generadas.

¡Es realmente así de fácil! Agreguemos una animación basada en nuestro itinerario.

Agrego algunas transiciones de contenido a las propiedades, de modo que los resultados se transmitan sin problemas a las vistas.

Extraeré todas las demás propiedades, ¡y ya estamos muy cerca del producto final! Probémoslo en mi teléfono. Hagamos la misma solicitud que antes.

Esta vez, comenzaremos inmediatamente a ver la transmisión de salida en la interfaz de usuario. Como usuario, puedo leer el primer día, a medida que se va generando el contenido.

Pero, es posible que hayas notado un leve retraso antes de que apareciera el primer campo en la pantalla. Para solucionar esto, sería de gran ayuda comprender qué sucede detrás de escena.

Usaré el nuevo instrumento de Foundation Models para entender los factores que influyen en el desempeño. Veamos qué encontramos al perfilar nuestra app. Antes, hablamos sobre cómo ejecutar nuestra app en el simulador. Esto es excelente para probar la funcionalidad, pero puede que no produzca resultados de desempeño precisos. Por ejemplo, un simulador en una Mac con chip M4 producirá resultados más rápido que un iPhone anterior. Es importante tener en cuenta estas diferencias al analizar el rendimiento. Realizaré el perfil en un iPhone físico.

Para comenzar, tengo la app Instruments abierta en la Mac y conectaré mi teléfono.

Agregaré el nuevo instrumento de Foundation Models, comenzaré a grabar y después crearé un nuevo itinerario.

La pista de carga de activos analiza el tiempo que lleva cargar los modelos. Se cargaron el modelo de lenguaje del sistema predeterminado y la barandilla de seguridad. La pista de Inferencia también está en azul.

Por último, la barra violeta es el tiempo que pasamos llamando a la herramienta. Podemos rastrear el tiempo total que tomó generar el itinerario y el recuento de tokens de entrada, proporcional al tamaño de las instrucciones y los mensajes. Ese retraso al principio fue el tiempo que tomó cargar el modelo de lenguaje del sistema. Hay formas de hacer que esto sea más rápido. Acabamos de observar que parte de esa latencia inicial fue capturada en la pista de carga de activos. El sistema operativo administra el modelo de lenguaje del dispositivo y es posible que no se guarde en la memoria si el sistema usa otras funciones críticas o si no se usó durante algún tiempo. Cuando llamo a session.respond, el SO cargará el modelo si aún no está en la memoria. El precalentamiento puede darle a tu sesión una ventaja, al cargar el modelo incluso antes de realizar la solicitud. Es mejor hacer esto cuando la app esté relativamente inactiva y después de que el usuario dé una clara señal de que usará la sesión. Un buen ejemplo de cuándo es necesario precalentar es justo después de que un usuario comienza a escribir en un campo de texto que generará un mensaje. En la app, cuando el usuario toca un punto de referencia, es probable que haga una solicitud pronto. Podemos precalentar antes de presionar el botón Generate Itinerary para cargar el modelo desde antes. Al terminar de leer la descripción, el modelo estará listo para funcionar.

La segunda optimización se puede agregar en el momento de la solicitud. ¿Recuerdas el argumento generador de las funciones de respuesta? Aquí utilizamos Itinerario. La estructura inserta automáticamente los esquemas de generación de las estructuras de datos en los mensajes. Pero esto agrega más tokens, lo que aumenta la latencia y el tamaño del contexto. Si el modelo ya tiene una comprensión completa del formato de respuesta antes de la solicitud, podemos establecer IncludeSchemaInPrompt en false y obtener mejoras.

¿Cuándo podemos aplicar esta optimización? El primer caso es al hacer solicitudes posteriores del mismo tipo en una conversación de varios turnos. La primera solicitud de la sesión ya brindó contexto para la generación guiada por el esquema en el mensaje. Por lo tanto, no necesitamos hacerlo para solicitudes posteriores en esa sesión. El segundo caso es si las instrucciones incluyen un ejemplo completo del esquema. ¿Recuerdas cómo pasamos de un itinerario de ejemplo en las Instrucciones? En este caso, es suficiente, porque la estructura de itinerario no tiene propiedades opcionales.

Si tienes propiedades opcionales en tu esquema, debes proporcionar ejemplos con todas las propiedades opcionales, tanto completas como nulas. Una consideración final es que establecer IncludeSchemaInPrompt en false significa que perderemos las descripciones que agregamos a las guías, aunque, si estás usando un ejemplo completo, esto no debería ser un problema. ¡Probemos estas optimizaciones! Establecemos la opción IncludeSchemaInPrompt como false en la solicitud. También precalentaremos la sesión mientras el usuario esté en la página de descripción del punto de referencia. Hagamos un contenedor rápido y luego invoquémoslo en la sesión.

¡Ahora los resultados! Grabé esto de nuevo para que podamos ver los resultados. La pista de carga de activos ya tenía cierta actividad antes de que tocara el botón Generate. Podemos ver muchos menos tokens de entrada y el tiempo de respuesta total ahora es más corto. Dados los segundos que ahorramos con las optimizaciones, podemos confiar en que llegaremos a tiempo a nuestro vuelo. Y con esto, ¡ya estoy lista para mi viaje!

Pero antes de irme, estas son otras sesiones que pueden interesarte. Asegúrate de ver la sesión “Meet” para aprender todo sobre la estructura. Para profundizar, está el video “Deep dive”. Para conocer más prácticas recomendadas, consulta “Prompt Design & Safety”. ¡Gracias por acompañarnos!