{"id":2069,"date":"2023-07-20T06:28:14","date_gmt":"2023-07-20T06:28:14","guid":{"rendered":"https:\/\/blogs.encamina.com\/piensa-en-software-desarrolla-en-colores\/?p=2069"},"modified":"2023-07-20T06:37:41","modified_gmt":"2023-07-20T06:37:41","slug":"integrando-otros-llms-con-semantic-kernel","status":"publish","type":"post","link":"https:\/\/blogs.encamina.com\/piensa-en-software-desarrolla-en-colores\/integrando-otros-llms-con-semantic-kernel\/","title":{"rendered":"Integrando otros LLMs con Semantic Kernel"},"content":{"rendered":"

\"\"<\/p>\n

Como seguro os habr\u00e9is dado cuenta, \u00faltimamente estoy implementando much\u00edsimos proyectos \u00abmuy chul\u00edsimos<\/em>\u00bb (\ud83d\ude05) con las librer\u00edas del Semantic Kernel<\/a>, un marco de trabajo de c\u00f3digo abierto (open source<\/em>) que principalmente se enfoca en facilitar la combinaci\u00f3n de mensajes e indicaciones \u2013 los famosos prompts<\/em> \u2013 para Inteligencias Artificiales generativas basadas en las tecnolog\u00edas de OpenAI.<\/p>\n

<\/p>\n

Y ah\u00ed hay un punto importante y es que, en su estado actual, Semantic Kernel por ahora s\u00f3lo opera \u00fanicamente con OpenAI, ya sea la variante de Azure o la propia de OpenAI.<\/p>\n

Pero\u2026 \u00bfy si queremos usar un modelo que no sea de OpenAI con Semantic Kernel? \u00bfSi queremos usar recursos de otro proveedor de Inteligencia Artificial?<\/p>\n

\u00a1Qu\u00e9date conmigo que te explico c\u00f3mo podemos integrar modelos de otros LLMs (Large Language Models<\/em>) como los disponibles en Hugging Face<\/a> en nuestros proyectos de IA usando Funciones Nativas y plugins<\/em> de Semantic Kernel!<\/p>\n

El c\u00f3digo fuente de este art\u00edculo lo pod\u00e9is conseguir en GitHub, aqu\u00ed \ud83d\udc49\ud83c\udffb https:\/\/github.com\/rliberoff\/BLOG-001-Semantic-Kernel-Native-Functions<\/a><\/p>\n

Creando una Funci\u00f3n Nativa para la integraci\u00f3n con otro LLM<\/h2>\n

En Semantic Kernel, las Funciones Nativas son b\u00e1sicamente c\u00f3digo en nuestro lenguaje de programaci\u00f3n de elecci\u00f3n, en mi caso C#.<\/p>\n

Para crear una Funci\u00f3n Nativa, primero debemos definir un plugin<\/em>. Esto es algo s\u00faper sencillo, b\u00e1sicamente es crear un directorio dentro de nuestro proyecto en el cual dejaremos clases que representar\u00e1n a nuestros plugins<\/em> con m\u00e9todos que representar\u00e1n a nuestras funciones.<\/p>\n

\"\"<\/a><\/p>\n

En nuestro caso, vamos a realizar una integraci\u00f3n con \u00abroberta-base-squad2<\/span>\u00bb disponible en Hugging Face<\/a>. Este modelo nos permite integrarnos con un LLM llamado RoBERTa<\/a> (nombre gracioso para Robustly Optimized BERT Approach<\/em>) desarrollado por la empresa deepset<\/a> (los mismos de Haystack<\/a>).<\/p>\n

El modelo \u00abroberta-base-squad2<\/span>\u00bb nos permitir\u00e1 realizar preguntas que ser\u00e1n contestadas a partir del contenido de un contexto que tambi\u00e9n debemos suministrar. El resultado retornado nos dar\u00e1 la respuesta junto con un valor num\u00e9rico que indicar\u00e1 el \u00edndice de confiabilidad de la calidad de dicha respuesta, es decir, un score<\/em> cuyo valor cu\u00e1nto m\u00e1s alto sea indicar\u00e1 que la respuesta es de mejor calidad y, por el contrario, cuanto m\u00e1s bajo sea que la respuesta es menos confiable.<\/p>\n

Para esta integraci\u00f3n es fundamental que tengas una cuenta en Hugging Face, ya que necesitar\u00e1s un token para autenticarte al realizar las llamadas al API REST que nos da conectividad con el modelo de \u00abroberta-base-squad2<\/span>\u00bb. Perfectamente te valdr\u00e1 una cuenta gratuita para esto \ud83d\ude0f<\/p>\n

Para gestionar el token de Hugging Face crearemos una clase de opciones llamada HuggingFaceOptions<\/span> con una propiedad Token que inicializaremos con un valor que obtendremos del fichero de configuraci\u00f3n (appsetttings.json<\/span>).<\/p>\n

\"\"<\/a><\/p>\n

Recordemos que las clases de opciones las configuramos con inyecci\u00f3n de dependencias en el archivo Program.cs<\/span>:<\/p>\n

\"\"<\/a><\/p>\n

Con esta parte de la carpinter\u00eda b\u00e1sica ya montada, el siguiente paso ser\u00e1 crear el directorio Plugins<\/span> (no somos muy originales con los nombres \ud83d\ude05) y dentro de \u00e9ste crearemos una clase llamada HuggingFaceDeepsetRobertaQuestionsAnsweringPlugin<\/span> (de nuevo los nombres no son mi fuerte \ud83d\ude05). Esta clase representa al plugin<\/em> que nos dar\u00e1 conectividad con el modelo, y cada uno de sus m\u00e9todos p\u00fablicos ser\u00e1n las Funciones Nativas que podemos utilizar con Semantic Kernel.<\/p>\n

En nuestro caso s\u00f3lo tendremos un m\u00e9todo llamado AskQuestionWithContextAsync<\/span> para integrarnos al modelo \u00abroberta-base-squad2<\/span>\u00bb. Este m\u00e9todo toma dos variables: el contexto y la pregunta, las cuales son usadas para armar la llamada al modelo \u00abroberta-base-squad2<\/span>\u00bb mediante un API REST de Hugging Face (l\u00edneas 30 a 37).<\/p>\n

\"\"<\/a><\/p>\n

Un detalle importante con las funciones en Semantic Kernel (sean Nativas o Sem\u00e1nticas) es que todo se gestiona con strings<\/em>. Esto quiere decir que lo que retorne nuestra Funci\u00f3n Nativa (el m\u00e9todo AskQuestionWithContextAsync<\/span>) s\u00f3lo puede ser un string<\/span>. La parte interesante, es que podemos devolver un JSON como string<\/span> que despu\u00e9s podemos parsear<\/em> para crear un objeto m\u00e1s concreto y espec\u00edfico. Por esa raz\u00f3n es que, como ves en el c\u00f3digo, se retorna directamente el contenido de la respuesta recibida de la llamada al API REST.<\/p>\n

Y como puedes apreciar, \u00a1no hay magia! <\/strong>La integraci\u00f3n con otros LLMs en Semantic Kernel la podemos hacer de formas tan pueriles o triviales como llamadas a un API REST, o integrarnos con un SDK que puedan ofrecernos a trav\u00e9s de paquetes tales como los NuGet.<\/p>\n

Ahora tenemos que configurar Semantic Kernel para que pueda hacer uso de nuestra Funci\u00f3n Nativa.<\/p>\n

Configurando Semantic Kernel con la Funci\u00f3n Nativa<\/h2>\n

Configurar el Semantic Kernel en nuestros proyectos es realmente sencillo. Todo se hace (habitualmente) en el Program.cs<\/span>.<\/p>\n

\"\"<\/a><\/p>\n

Nuestra Funci\u00f3n Sem\u00e1ntica la hemos codificado para que perfectamente pueda ser registrada en el contenedor de dependencias de .NET como un singleton<\/em>, lo cual nos ayudar\u00e1 ligueramente con el desempe\u00f1o del c\u00f3digo.<\/p>\n

Al configurar una instancia de Semantic Kernel, es recomendable para escenarios web que se registre como scoped<\/em>, ya que internamente el Semantic Kernel gestiona estados y contextos que en escenarios compartidos (usualmente web) podr\u00edan producir efectos secundarios y comportamientos inesperados no deseados si se registra como singleton<\/em>. Tambi\u00e9n recuerda que es siempre una buena idea configurar un logger<\/em> con el Semantic Kernel, pues as\u00ed podr\u00e1s saber qu\u00e9 ha podido salir mal en caso de errores; a m\u00ed, particularmente me gusta usar Azure Application Insights como servicio para mis trazas y registros de eventos, y podr\u00e1s ver c\u00f3mo lo he configurado en el c\u00f3digo del Program.cs<\/span> disponible en el repo de GitHub.<\/p>\n

Dentro de la configuraci\u00f3n, una vez que tenemos un kernel<\/em> establecido, importamos la Funci\u00f3n Nativa (l\u00edneas 11 y 12) proporcionando una instancia de \u00e9sta y un nombre para la skill<\/em> que representa.<\/p>\n

No es nuestro caso, pero puede ocurrir que tengas Funciones Nativas complejas, con inicializaciones complicadas o costosas en t\u00e9rminos de recursos. Si eso ocurre, mi recomendaci\u00f3n es que inviertas cierto tiempo y esfuerzo en implementar un patr\u00f3n Factory<\/span> para la skill<\/em>, y que pases una instancia de dicho Factory<\/span> al Semantic Kernel.<\/p>\n

Lo que queda ahora es poder utilizar esta Funci\u00f3n Nativa y manipular el string que retorna para devolver algo m\u00e1s significativo.<\/p>\n

Llamando a nuestra Funci\u00f3n Nativa para usar el LLM<\/h2>\n

Para probar nuestra integraci\u00f3n, vamos a crear un controller<\/em> con una acci\u00f3n para exponer desde un API REST un endpoint<\/em> para consumir nuestro LLM.<\/p>\n

Y no s\u00f3lo eso, sino que tambi\u00e9n nos permita interpretar el resultado para saber a partir del score<\/em> si vale la pena retornar la respuesta, o mejor contestar un \u201cno s\u00e9<\/em>\u201d.<\/p>\n

\"\"<\/a><\/p>\n

Para esta demo, estoy estableciendo el valor m\u00ednimo del score<\/em> de la respuesta en un 0.7 (un 70% de confiabilidad) para considerarla como v\u00e1lida. Lo idea es que este valor est\u00e9 parametrizado en una clase de opciones parecida a la que vimos como ejemplo antes con el caso de HuggingFaceOptions<\/span>. De momento, nos vale con tenerlo como una constante dentro de la acci\u00f3n.<\/p>\n

Tomaremos la pregunta y el contexto que nos llegar\u00e1n por request (clase AskRequest<\/span>) y sus valores los usaremos en una instancia de la clase ContextVariables<\/span> que pasaremos como par\u00e1metros al Semantic Kernel (representado por una instancia v\u00e1lida del tipo de interface IKernel<\/span> que recibimos como dependencia en el constructor del controlador).<\/p>\n

Para llamar a nuestra Funci\u00f3n Nativa registrada en el Semantic Kernel simplemente tenemos que suministrar el nombre de la skill<\/em> y de la funci\u00f3n (l\u00edneas 25 a 30). El resultado de la ejecuci\u00f3n de la funci\u00f3n es una instancia del tipo SKContext<\/span>, la cual nos ofrece variada informaci\u00f3n sobre el resultado de dicha ejecuci\u00f3n.<\/p>\n

As\u00ed, con el resultado obtenido, primero verificamos que no haya ocurrido ning\u00fan error (excepci\u00f3n), y en caso de haberlo, retornar el mensaje del error correspondiente
\n(l\u00edneas 32 a 35).<\/p>\n

Si todo ha ido bien, tomamos la respuesta que nos ha llegado como tipo string y que sabemos de la implementaci\u00f3n que realmente es un JSON con la respuesta del modelo \u00abroberta-base-squad2<\/span>\u00bb. Para obtener los valores de la respuesta, he creado la clase AskResponse<\/span> que mapea \u00ab1 a 1<\/em>\u00bb con algunos de los valores del JSON retornado por \u00abroberta-base-squad2<\/span>\u00bb; y de los cuales nos interesan dos en concreto: la respuesta y su score<\/em>. Usando el JsonSerializer<\/span> podemos obtener la instancia de AskResponse<\/span> con los valores que nos interesan.<\/p>\n

Finalmente, verificamos si el score<\/em> recibido es mayor al valor m\u00ednimo que hemos establecido. De ser as\u00ed, retornamos la respuesta, sino retornamos un HTTP 404 Not Found<\/span> con un mensaje indicando que no se consigui\u00f3 una respuesta satisfactoria porque el score<\/em> era bajo.<\/p>\n

Para probar esto, os dejo una colecci\u00f3n de Postman con esta llamada y que est\u00e1 disponible en el repo en GitHub mencionado al principio del art\u00edculo. Abajo tienes dos im\u00e1genes de una respuesta correcta y otra de \u201cno s\u00e9<\/em>\u201d \ud83d\udc47\ud83c\udffb<\/p>\n

\"\"<\/a>\"\"<\/a><\/p>\n

M\u00e1s informaci\u00f3n<\/h2>\n

Si tienes m\u00e1s curiosidad sobre Semantic Kernel, te dejo aqu\u00ed algunas publicaciones en YouTube<\/a> donde justamente trato sobre estos temas:<\/p>\n