LLMs aplicados a la domótica y la interacción persona-hogar

TRABAJO FIN DE M´ ASTER LLMs aplicados a la dom´otica y la interacci´on persona-hogar Realizado por Camero Borrego, Tom´as Para la obtenci´on del t´ıtulo de M´aster en Ingenier´ıa del Software: Cloud, Datos y Gesti´on TI Dirigido por Soria Morillo, Luis Miguel Convocatoria de Junio, curso 2023/24 Agradecimientos A Claudia y Abby, por ser los dos soles que iluminan mi camino. i Resumen Este trabajo se enfoca en investigar la interacci´on entre los Modelos de Lenguaje a Gran Escala (LLMs) y la creciente presencia de la dom´otica inteligente en los hogares modernos. A trav´es de un an´alisis exhaustivo y la creaci´on de un prototipo, se explorar´a c´omo los LLMs, como GPT-3.5, pueden mejorar significativamente la calidad de vida en el hogar. El prop´osito es demostrar c´omo estos modelos pueden facilitar una comunicaci´on m´as natural y efectiva con los sistemas dom´esticos, as´ı como anticipar las necesidades del hogar. Este estudio no solo proporcionar´a una comprensi´on profunda del estado actual de esta convergencia tecnol´ogica, sino que tambi´en establecer´a pautas para futuras investigaciones en este campo. Palabras clave: LLMs, LM, Dom´otica, asistente de hogar, modelo de aprendizaje ii Abstract This paper focuses on investigating the interaction between Large Scale Language Models (LLMs) and the growing presence of smart home automation in modern homes. Through a comprehensive analysis and prototyping, it will explore how LLMs, such as GPT-3.5, can significantly improve the quality of life in the home. The purpose is to demonstrate how these models can facilitate more natural and effective communication with home systems, as well as anticipate the needs of the home. This study will not only provide an in-depth understanding of the current state of this technological convergence, but will also establish guidelines for future research in this field. Keywords: LLMs, LM, Domotic, home assistant, learning model iii ´ Indice general 1. Introducci´on 1 1.1. Introducci´on................................. 1 1.2. Contexto................................... 1 1.3. Objetivos del Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Estructura de este documento . . . . . . . . . . . . . . . . . . . . . . . 5 2. Estudio previo 6 2.1. Introducci´on................................. 6 2.2. Objetivosdelestudio............................ 6 2.3. Metodolog´ıa................................. 7 2.3.1. Revisi´on de Literatura . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.2. An´alisis de Casos de Estudio . . . . . . . . . . . . . . . . . . . . 8 2.3.3. Dise˜no de la Prueba Conceptual . . . . . . . . . . . . . . . . . . 8 2.3.4. Desarrollo del Prototipo . . . . . . . . . . . . . . . . . . . . . . 9 2.3.5. Evaluaci´on del Prototipo . . . . . . . . . . . . . . . . . . . . . . 10 2.3.6. Documentaci´on y Reporte . . . . . . . . . . . . . . . . . . . . . 10 2.4. Planificaci´on................................. 10 2.4.1. Descripci´on de tareas . . . . . . . . . . . . . . . . . . . . . . . . 10 2.4.2. Temporal .............................. 11 2.5. Presupuesto................................. 13 2.5.1. Recursos Materiales . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.5.2. Recursos Intelectuales . . . . . . . . . . . . . . . . . . . . . . . 13 2.5.3. Financiaci´on............................. 13 3. Estado del arte 14 3.1. Introducci´on................................. 14 3.2. LLMs .................................... 14 3.2.1. Situaci´on actual . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3. Dom´otica inteligente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4. Interacci´on entre ambas tecnolog´ıas . . . . . . . . . . . . . . . . . . . . 19 3.4.1. Avances ............................... 20 3.4.2. Problemas.............................. 22 3.4.3. Impacto en la diversidad, sostenibilidad y ´etica social . . . . . . 23 3.5. Conclusiones del cap´ıtulo . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4. Descripci´on de la propuesta 26 4.1. Introducci´on................................. 26 4.2. Propuesta .................................. 26 4.3. Entornodeejecuci´on ............................ 26 4.4. Estructura de Home Assistant . . . . . . . . . . . . . . . . . . . . . . . 27 4.5. LLMsutilizados............................... 29 4.6. Dise˜no conceptual del prototipo . . . . . . . . . . . . . . . . . . . . . . 41 4.7. Ejecuci´on y funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . 42 iv 5. Validaci´on 43 5.1. Introducci´on................................. 43 5.2. Herramientas ................................ 43 5.3. Descripci´on general de la Arquitectura . . . . . . . . . . . . . . . . . . 47 6. Pruebas 61 6.1. Introducci´on................................. 61 6.2. An´alisisdec´odigo.............................. 61 6.3. Pruebasdecarga .............................. 63 7. Conclusiones 66 A. Bibliograf´ıa 68 v ´ Indice de figuras 1.1. Robot ’Ballie’ de Samsung . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Diagrama UML simple representaci´on de la prueba de concepto . . . . 3 1.3. Diagrama de flujo de la prueba de concepto . . . . . . . . . . . . . . . 3 2.1. Diagrama de Gantt inicial . . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2. Diagrama de Gantt posterior . . . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Inversi´on en d´olares americanos del a˜no 2024 frente al 2029 [36] . . . . 19 3.2. Aumento de dispositivos inteligentes en 2026 [38] ............ 20 3.3. Ejemplo de input del modelo [29] ..................... 21 3.4. Consumo de los modelos a lo largo de los a˜nos [42] ........... 24 4.1. HA Core Architecture, fuente: [8] ..................... 27 4.2. HA Integration Architecture, fuente: [13]................. 28 4.3. Apagado del aire acondicionado, respuesta de ChatGPT3.5 Turbo . . . 40 4.4. Encendido del aire acondicionado, respuesta de Microsoft Copilot . . . 41 4.5. Diagrama de clases UML del prototipo final . . . . . . . . . . . . . . . 42 5.1. Creaci´on de API KEY en la p´agina de LlamUS . . . . . . . . . . . . . 44 5.2. Variables globales utilizadas en el prototipo . . . . . . . . . . . . . . . 44 5.3. M´aquina virtual creada y configurada . . . . . . . . . . . . . . . . . . . 45 5.4. Habitaciones disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.5. Dispositivos del Living Room . . . . . . . . . . . . . . . . . . . . . . . 46 5.6. Dispositivos del Garage . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.7. Funci´on main delprograma ........................ 47 5.8. Funci´on as´ıncrona get areas ........................ 48 5.9. Funciones de la API REST de Home Assistant [4]............ 49 5.10. Funci´on as´ıncrona get devices and entities ................ 50 5.12. Funci´on get available services . . . . . . . . . . . . . . . . . . . . . . . 51 5.11. Funci´on as´ıncrona get entity ids ...................... 51 5.13. Funci´on as´ıncrona filter services for entities ............... 52 5.14. Funci´on as´ıncrona send prompt ...................... 52 5.15. Funci´on as´ıncrona process text and extract yaml ............. 55 5.16. Funci´on as´ıncrona send prompt ...................... 56 5.17. Ejemplo JSON que se le pasa al modelo con los dispositivos y estados . 57 5.18. Ejemplo de script de HA generado por Llama2:70b . . . . . . . . . . . 57 5.19. Resultados de la tarea Quiero ver una pel´ıcula en la habitaci´on Living Room ............................... 57 5.20. Primeras lineas del JSON con los dispositivos y estados . . . . . . . . . 58 5.21. Primeras lineas del script de HA generado por Llama2:70b . . . . . . . 59 5.22. Resultados de la tarea Quiero ver una pel´ıcula en la habitaci´on salon2 60 6.1. Resultado del an´alisis realizado con pylint . . . . . . . . . . . . . . . . 62 6.2. Refactorizaci´on de la funci´on get devices and entities .......... 62 vi 6.3. Puntuaci´onfinal............................... 63 6.4. Funci´on para ejecutar simult´aneamente las peticiones . . . . . . . . . . 63 6.5. Resultados de las m´etricas de la primera iteraci´on . . . . . . . . . . . . 64 6.6. Resultados de las m´etricas de la segunda iteraci´on . . . . . . . . . . . . 64 6.7. Resultados de las m´etricas de la tercera iteraci´on . . . . . . . . . . . . 64 vii ´ Indice de extractos de c´odigo 4.1. Configuraci´on de Dispositivos de CASA 1 . . . . . . . . . . . . . . . . . 30 4.2. Configuraci´on de Dispositivos de CASA 2 . . . . . . . . . . . . . . . . . 32 4.3. Fichero de configuraci´on dado por ChatGPT en la primera prueba . . . 34 4.4. Fichero de configuraci´on dado por Bard en la primera prueba . . . . . . 34 4.5. Fichero de configuraci´on dado por ChatGPT en la segunda prueba . . . 36 4.6. Fichero de configuraci´on dado por Bard en la segunda prueba . . . . . 37 4.7. Modificaci´on del estado en el sensor de temperatura . . . . . . . . . . . 40 5.1. Prompt final utilizado . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 viii a gran escala de esta tecnolog´ıa. Se espera que los resultados de este estudio abran nuevas v´ıas para investigaciones futuras y desarrollos en el campo de la interacci´on inteligente hogar-usuario, destacando c´omo los LLMs pueden mejorar significativamente la comodidad y eficiencia de los entornos dom´esticos. Cuadro 2.1: Objetivos Objetivo Descripci´on 1 Estudio e investigaci´on sobre el estado actual de los LLMs y su posible implicaci´on en la interacci´on persona-hogar en los hogares actuales y futuros 2 Creaci´on de prueba conceptual que aglutine ambos campos para su utilizaci´on comercial. 2.3. Metodolog´ıa 2.3.1. Revisi´on de Literatura Para recopilar informaci´on actual sobre los Modelos de Lenguaje de Gran Tama˜no (LLMs) y su aplicaci´on en entornos dom´esticos, se realizar´a una revisi´on sistem´atica de la literatura. La realizaci´on de esta revisi´on requerir´a el uso de bases de datos acad´emicas como Google Scholar [10] y IEEE Xplore [11]. Para garantizar que la revisi´on sea rigurosa y relevante, se definir´an criterios para incluir y excluir estudios. Los criterios de inclusi´on tendr´an en cuenta publicaciones recientes, art´ıculos revisados por pares y estudios espec´ıficos sobre LLMs y dom´otica. Los art´ıculos sin rigor acad´emico, trabajos duplicados y estudios no relevantes se descartar´an seg´un los criterios de exclusi´on. Para estructurar la revisi´on de la literatura, se emplear´a el m´etodo PRISMA (Preferred Reporting Items for Systematic Reviews and Meta-Analyses), el cual garantiza la transparencia y reproducibilidad del proceso de revisi´on [33]. Este m´etodo incluye las siguientes etapas: 1. Identificaci´on de palabras clave: Se identificar´an t´erminos y frases clave relacionados con LLMs y dom´otica. 2. B´usqueda en bases de datos: Se realizar´an b´usquedas exhaustivas en bases de datos acad´emicas para encontrar estudios relevantes. 3. Selecci´on de estudios: Se evaluar´an los estudios encontrados seg´un los criterios de inclusi´on y exclusi´on definidos. 4. Extracci´on de datos: Se extraer´a informaci´on relevante de los estudios seleccionados, incluyendo metodolog´ıas, resultados y conclusiones. 5. An´alisis cualitativo y cuantitativo: Se analizar´an los datos extra´ıdos para identificar tendencias, fortalezas, debilidades y lagunas en la literatura existente. La utilizaci´on del m´etodo PRISMA permitir´a asegurar que la revisi´on sea exhaustiva y que los estudios incluidos sean relevantes y de alta calidad. 7 2.3.2. An´alisis de Casos de Estudio Se seleccionar´an estudios de casos en los que los LLM se hayan aplicado a aplicaciones dom´oticas. Se examinar´an documentos t´ecnicos, informes de proyectos y estudios de casos publicados para determinar si estos modelos funcionan bien en situaciones reales. El an´alisis se centrar´a en descubrir los beneficios y los desaf´ıos de la implementaci´on y aceptaci´on por parte de los usuarios. Se seguir´an estos pasos para realizar el an´alisis de casos de estudio: Selecci´on de Casos: Se identificar´an y seleccionar´an casos de estudio relevantes a trav´es de una b´usqueda sistem´atica en bases de datos acad´emicas y repositorios de proyectos. Se utilizar´an criterios de inclusi´on como la relevancia del estudio para la tem´atica de LLMs y dom´otica, la novedad del enfoque y la calidad del reporte t´ecnico. Recolecci´on de Datos: De cada caso de estudio seleccionado, se extraer´a informaci´on detallada sobre: •Contexto del Estudio: Descripci´on del entorno en el que se implementaron los LLMs, incluyendo la infraestructura dom´otica utilizada. •Metodolog´ıa: Procedimientos y t´ecnicas empleadas para la integraci´on de LLMs en el sistema dom´otico. •Resultados y Hallazgos: Beneficios observados, problemas encontrados y soluciones propuestas. Tambi´en se analizar´a la percepci´on de los usuarios en cuanto a la funcionalidad y usabilidad del sistema. S´ıntesis de Informaci´on: Los datos recopilados se organizar´an y sintetizar´an para proporcionar una visi´on clara y estructurada de c´omo los LLMs pueden mejorar los sistemas dom´oticos. Identificaci´on de Buenas Pr´acticas: Basado en el an´alisis, se identificar´an buenas pr´acticas que pueden ser aplicadas en el dise˜no y desarrollo del prototipo. Esto incluye estrategias de integraci´on, enfoques para mejorar la usabilidad y m´etodos para abordar los desaf´ıos t´ecnicos. 2.3.3. Dise˜no de la Prueba Conceptual Se definieron los requisitos funcionales y no funcionales del prototipo bas´andose en la revisi´on de la literatura y el an´alisis de casos de estudio. La opini´on del tutor fue fundamental para mejorar estos requisitos y garantizar que el dise˜no del prototipo fuera s´olido y viable. Para visualizar la estructura y el comportamiento del sistema, se crearon diagramas UML. Para garantizar una comprensi´on completa de las interacciones entre los componentes del sistema, se proporcionaron flujos de trabajo detallados que inclu´ıan diagramas de casos de uso, diagramas de secuencia y diagramas de clases. Adem´as, se utiliz´o la metodolog´ıa ´agil para el desarrollo del prototipo, permitiendo iteraciones r´apidas y adaptaciones basadas en el feedback continuo del tutor y los resultados obtenidos de la revisi´on de la literatura y el an´alisis de casos de uso. 8 2.3.4. Desarrollo del Prototipo El prototipo se desarrollar´a utilizando herramientas adecuadas que soporten la integraci´on de LLMs como LlamUS [12], servidor con m´ultiples modelos proporcionado por la Universidad de Sevilla, y usando Home Assistant como plataforma de automatizaci´on del hogar. Para el desarrollo del prototipo, se siguieron estos pasos: Preparaci´on del Entorno de Desarrollo: •Se configur´o un entorno de desarrollo local en una m´aquina con Windows 11. •Se utiliz´o Visual Studio Code como entorno de desarrollo integrado (IDE) para la gesti´on y edici´on del c´odigo. •Home Assistant se implement´o en una m´aquina virtual utilizando Virtual Box, siguiendo las instrucciones de la gu´ıa oficial de instalaci´on. •Se estableci´o una red local segura para permitir la comunicaci´on entre los diferentes componentes del sistema. Instalaci´on y Configuraci´on de LLMs: •Se seleccion´o y configur´o el modelo Llama2-70b para su uso en el servidor LlamUS. •Se gener´o una API KEY para la autenticaci´on y se integr´o en el c´odigo del prototipo. •Se realizaron pruebas iniciales de conectividad para asegurar que el prototipo pod´ıa comunicarse correctamente con el servidor LlamUS. Desarrollo de las Funciones de Interacci´on: •Se identificaron los servicios y entidades necesarios en Home Assistant para los dispositivos dom´oticos. •Se programaron scripts automatizados utilizando YAML para definir las tareas que Home Assistant deb´ıa realizar. •Se implementaron funciones que permiten la interacci´on del LLM con Home Assistant mediante solicitudes HTTP. •Se realizaron pruebas iniciales para verificar la correcta ejecuci´on de los comandos generados por el LLM en Home Assistant. El uso de este m´etodo permiti´o la creaci´on de un prototipo funcional que demostraba la idoneidad de los LLM para la automatizaci´on del hogar, integrando los modelos de lenguaje con la plataforma Home Assistant y proporcionando una base s´olida para futuras mejoras y desarrollos. 9 2.3.5. Evaluaci´on del Prototipo Para evaluar la eficacia del sistema en entornos reales, el prototipo se evaluar´a mediante pruebas de calidad del c´odigo y pruebas de carga. Se llevar´an a cabo las siguientes acciones para completar la evaluaci´on: An´alisis de C´odigo: Se utilizar´a la herramienta pylint para realizar un an´alisis exhaustivo del c´odigo del prototipo. Esta herramienta proporcionar´a una lista de advertencias, errores y sugerencias de mejora, adem´as de una puntuaci´on de calidad. Este an´alisis ayudar´a a identificar ´areas de mejora en la estructura del c´odigo y la documentaci´on de funciones. Pruebas de Carga: Se llevar´an a cabo pruebas de carga enviando m´ultiples solicitudes concurrentes al modelo de lenguaje alojado en el servidor. Estas pruebas, gestionadas por asyncio, simular´an un entorno dom´estico con varios ocupantes. Las m´etricas recolectadas incluir´an el n´umero de solicitudes, solicitudes exitosas, tasa de errores, tiempo promedio de respuesta y respuestas con errores. Estas pruebas permitir´an evaluar el rendimiento del sistema bajo condiciones de alta demanda. 2.3.6. Documentaci´on y Reporte Todo el proceso de investigaci´on y desarrollo ser´a meticulosamente documentado. El registro de las decisiones de dise˜no, los resultados de las pruebas, las iteraciones de desarrollo y las lecciones aprendidas se incluir´an en la documentaci´on. Se preparar´a esta memoria final detallando los hallazgos, la metodolog´ıa utilizada, los resultados, las conclusiones y las sugerencias para trabajos futuros. Se utilizar´a GPT 4 para la ayuda y apoyo en la escritura, con el fin de que est´e lo m´as formal y profesional posible. 2.4. Planificaci´on 2.4.1. Descripci´on de tareas Al inicio del presente estudio se describieron dos objetivos principales, y para lograr dichos objetivos, ha sido necesario la realizaci´on de las siguientes tareas enumeradas a continuaci´on: Objetivo 1: Estudio e investigaci´on sobre el estado actual de los LLMs y su posible implicaci´on en la interacci´on persona-hogar en los hogares actuales y futuros Tarea 1: Revisi´on de Literatura 1. Identificaci´on y selecci´on de art´ıculos: Buscar y seleccionar art´ıculos cient´ıficos relevantes sobre LLMs y dom´otica, utilizando bases de datos acad´emicas. 10 2. An´alisis y s´ıntesis de la literatura: Analizar los art´ıculos para identificar tendencias y desarrollos clave. 3. Preparaci´on del estado del arte: Redactar la secci´on del estado del arte, integrando el an´alisis realizado. Objetivo 2: Creaci´on de prueba conceptual que aglutine ambos campos para su utilizaci´on comercial Tarea 2: Evaluaci´on y selecci´on de LLMs 1. Pruebas preliminares con varios LLMs: Configurar y ejecutar pruebas de rendimiento con diversos LLMs. 2. Selecci´on del modelo m´as adecuado: Elegir el LLM que mejor se adapte seg´un las m´etricas evaluadas. Tarea 3: Integraci´on con Home Assistant 1. Configuraci´on de Home Assistant: Instalar y configurar Home Assistant para integrarlo con el LLM seleccionado. 2. Desarrollo de las funciones de interacci´on: Programar las funciones que permitan la interacci´on eficiente del LLM con el entorno dom´estico. Tarea 4: Evaluaci´on de la prueba conceptual 1. Pruebas de funcionamiento: Realizar pruebas en un entorno controlado para verificar la integraci´on del sistema. 2. An´alisis y ajustes: Analizar los resultados y realizar ajustes basados en el feedback de las pruebas. Tarea 5: Documentaci´on y preparaci´on para la comercializaci´on 1. Redacci´on del informe final: Documentar todo el proceso y resultados en un informe detallado. 2. Preparaci´on de material de presentaci´on: Desarrollar material para la defensa del TFM y posibles interesados. 2.4.2. Temporal Tal como se ha descrito anteriormente, el trabajo persigue 2 objetivos principales. El primero de ellos se inici´o en noviembre de 2023, pr´acticamente nada m´as tener el tema elegido, y se puso en marcha el d´ıa 27 de noviembre del 2023, empezando a buscar y leer art´ıculos sobre los temas en cuesti´on. A partir de ah´ı, se han ido realizando los subobjetivos de manera lineal y program´atica, hasta mayo de 2024, culminando con la prueba de concepto finalizada. A continuaci´on, se presenta el diagrama de Gantt inicial previsto: 11 Figura 2.1: Diagrama de Gantt inicial Debido a diversos problemas, tanto de tiempo como de carga de trabajo derivado de otras asignaturas del m´aster, dicha planificaci´on sufri´o algunas desviaciones leves, como se puede ver en el diagrama siguiente: Figura 2.2: Diagrama de Gantt posterior Dichas desviaciones incluyen varios incidentes. Por ejemplo, hubo un problema inicial en el subobjetivo de an´alisis y s´ıntesis, donde surgieron dificultades para comprender los conceptos clave. Esto caus´o un retraso tanto en dicho subobjetivo como en la creaci´on del estado del arte. Las pruebas preliminares tambi´en sufrieron un desv´ıo, ya que no se necesit´o tanto tiempo como se hab´ıa previsto; unas pocas pruebas fueron suficientes para determinar la direcci´on a seguir. Esto tambi´en afect´o el an´alisis de dichas pruebas. La selecci´on del modelo tambi´en experiment´o retrasos, ya que, aunque ya se ten´ıa una idea aproximada de qu´e modelo usar gracias a las pruebas anteriores, se esperaba confirmaci´on por parte de la universidad para el uso de LlamUS, lo cual alarg´o este proceso. Por ´ultimo, los an´alisis finales y ajustes tambi´en se prolongaron un poco m´as debido a problemas personales que me impidieron estar en mi domicilio personal donde ten´ıa configurado el servidor de Home Assistant. 12 2.5. Presupuesto El coste econ´omico asociado al proyecto se corresponde a: 2.5.1. Recursos Materiales Ordenador port´atil: Se ha utilizado un ordenador port´atil con un costo de 1200 euros para el desarrollo del proyecto, programaci´on, an´alisis y redacci´on del documento. Accesos a Modelos de Lenguaje: Incluye el acceso a cuentas de servicios de LLMs como ChatGPT-4 y otros modelos proporcionados a trav´es del servidor de la Universidad de Sevilla (LLamUS). Los servicios proporcionados por la instituci´on no representan un costo directo para el proyecto, pero su valor es crucial para el desarrollo del mismo. 2.5.2. Recursos Intelectuales Tiempo de Ingenier´ıa: El tiempo dedicado por el investigador, quien es un ingeniero inform´atico, se estima en 300 horas a lo largo del proyecto. Considerando un costo por hora de 16.5 euros, el valor estimado del tiempo dedicado es de 4950 euros. Este costo no es un desembolso directo pero representa el valor del trabajo intelectual invertido en el proyecto. 2.5.3. Financiaci´on La financiaci´on del proyecto ha sido proporcionada en su totalidad por el investigador y apoyos acad´emicos de la Universidad de Sevilla, lo que incluye el acceso gratuito a herramientas y plataformas necesarias para la investigaci´on. La siguiente tabla expresa un resumen de los gastos y el total invertido: Descripci´on Costo Unitario (€) Total (€) Ordenador port´atil 1200 1200 ChatGPT-4 (Nov 2023 - May 2024) 25 (por mes) 175 Tiempo de Ingenier´ıa (300 horas) 16.5 (por hora) 4950 Total 6325 Cuadro 2.2: Resumen detallado del presupuesto del proyecto 13 3. Estado del arte 3.1. Introducci´on Los hogares inteligentes est´an adquiriendo un papel cada vez m´as relevante en la vida moderna, gracias a la evoluci´on tecnol´ogica contempor´anea. Desde sus primeros indicios, este ´ambito ha experimentado un notable avance. La dom´otica inteligente del hogar se centra en automatizar una variedad de dispositivos de uso cotidiano, incluyendo la iluminaci´on, calefacci´on, ventilaci´on, entre otros. Por otro lado, los LLMs (Large Language Models) son modelos de aprendizaje autom´atico que desempe˜nan un papel crucial en la modelaci´on de sistemas l´ogicos y en el razonamiento sobre los mismos. A pesar de que en un principio pueda parecer que estos dos ´ambitos no guardan relaci´on, la realidad es que est´an estrechamente interconectados. La interacci´on entre estas tecnolog´ıas es un tema de gran inter´es en la actualidad. La dom´otica inteligente del hogar puede beneficiarse enormemente de los LLMs para mejorar la eficiencia y precisi´on de los sistemas de automatizaci´on. Por ejemplo, los LLMs pueden utilizarse para modelar el comportamiento de los usuarios y adaptar los sistemas del hogar a sus necesidades y preferencias. Adem´as, estos modelos pueden ser empleados para razonar sobre el estado actual de los sistemas del hogar y tomar decisiones en consecuencia. En este cap´ıtulo, se examinar´a el progreso de ambas tecnolog´ıas por separado, as´ı como el estado actual de la investigaci´on en lo que respecta a su interacci´on. Se extraer´an conclusiones significativas que orientar´an el desarrollo de esta disciplina. 3.2. LLMs Los LLMs (por sus siglas, Large Language Models), son modelos de aprendizaje profundo basados en el procesamiento de lenguaje natural (PNL)[14]. El procesamiento del lenguaje natural no es m´as que una rama de la inteligencia artificial que se ocupa de la interacci´on entre las computadoras y el lenguaje humano. Su objetivo es permitir que las m´aquinas comprendan, interpreten y generen lenguaje humano de manera efectiva [28] [34]. Estos modelos han ido evolucionando desde sus inicios en 1960 hasta en la actualidad. A grandes rasgos, el procesamiento del lenguaje natural primero pas´o por un modelado estad´ıstico del lenguaje hasta el neuronal, para luego pasar por modelos de lenguaje previamente entrenados (PLM) hasta llegar a lo que llamamos ahora LLM. La diferencia que existe entre un PLM y un LLM es la cantidad de par´ametros que tienen. Los LLMs m´as famosos se basan en una arquitectura de red neuronal llamada “transformers”, que utilizan un mecanismo de atenci´on para capturar relaciones a larga 14 distancia en el texto. Durante el entrenamiento, los pesos del modelo se ajustan mediante t´ecnicas como el descenso de gradiente estoc´astico para minimizar la diferencia entre las predicciones del modelo y los datos de entrenamiento. Algunos de estos modelos, denominados transformes son los siguientes: BERT (Bidirectional Encoder Representations from Transformers): Desarrollado por Google, BERT es un modelo de lenguaje bidireccional que utiliza una arquitectura de codificador-transformador para predecir palabras en una secuencia dada su contexto tanto anterior como posterior. Esto permite a BERT capturar mejor el significado de las palabras en un contexto m´as amplio. BERT ha demostrado excelentes resultados en una variedad de tareas de procesamiento de lenguaje natural, como la comprensi´on de texto, la generaci´on de texto y la traducci´on autom´atica [19]. GPT (Generative Pre-trained Transformer): Desarrollado por OpenAI, GPT es una familia de modelos de lenguaje basados en transformadores que se entrenan utilizando un enfoque de preentrenamiento y ajuste fino. GPT utiliza un modelo de decodificador-transformador para generar texto secuencialmente, lo que le permite completar tareas de generaci´on de texto y comprensi´on de lenguaje natural. GPT ha sido ampliamente utilizado en una variedad de aplicaciones, desde la generaci´on de texto hasta la traducci´on autom´atica y el an´alisis de sentimientos [43]. ALBERT (A Lite BERT): ALBERT es una versi´on ligera y eficiente de BERT que utiliza una arquitectura de codificador compartido para reducir el n´umero de par´ametros y mejorar la eficiencia computacional. ALBERT utiliza estrategias como el factor de compartici´on de pesos y la reducci´on de la capa oculta para lograr un mejor rendimiento con menos recursos computacionales. ALBERT ha demostrado resultados competitivos en una variedad de tareas de procesamiento de lenguaje natural y es especialmente ´util en entornos con recursos computacionales limitados [30]. BART (Bidirectional and Auto-Regressive Transformers): BART es un modelo de lenguaje basado en transformadores desarrollado por Facebook AI que combina la capacidad de BERT para la codificaci´on bidireccional con la capacidad de GPT para la generaci´on de texto auto regresiva. Esto permite a BART realizar tanto tareas de comprensi´on de texto como de generaci´on de texto de manera efectiva. BART ha demostrado resultados prometedores en tareas como la traducci´on autom´atica, la resumen de texto y la generaci´on de texto [32]. PEGASUS: PEGASUS es un modelo de lenguaje basado en transformadores desarrollado por Google que se centra en la tarea de generaci´on de res´umenes de texto. PEGASUS utiliza una arquitectura de codificador-decodificador para generar res´umenes de texto de alta calidad, lo que lo hace especialmente ´util en aplicaciones como la generaci´on autom´atica de res´umenes de noticias y la comprensi´on de documentos largos [48]. DeBERTa: DeBERTa es un modelo de lenguaje basado en transformadores desarrollado por Microsoft Research que utiliza una arquitectura de codificadortransformador bidireccional con una atenci´on relativa. DeBERTa mejora la capa- 15 cidad de modelado de BERT al capturar relaciones a larga distancia en el texto mediante el uso de una atenci´on relativa m´as eficiente. Esto hace que DeBERTa sea especialmente efectivo en tareas que requieren un entendimiento profundo del contexto, como la comprensi´on de texto y la generaci´on de texto [21]. 3.2.1. Situaci´on actual Debido a los grandes avances que ha habido durante los ´ultimos a˜nos, los LLMs cada vez tienen m´as datos sobre los que entrenar, y por ende obtienen mejores resultados y lo m´as importante, respuestas m´as precisas seg´un la entrada recibida. En el mundo de la inform´atica e internet de las cosas (IoT), se esta empezando a crear una tendencia a usar un LLM como parte central y fundamental de una empresa o negocio [26], usando, al menos por ahora, otras herramientas que permitan mejorar los resultados obtenidos. Recientemente, se han desarrollado nuevos modelos de LLMs que mejoran la eficiencia y la escalabilidad de los modelos existentes. Estos avances han permitido aplicaciones innovadoras en diversas ´areas, como la generaci´on de texto autom´atico para tareas como la redacci´on de noticias, la creaci´on de contenido web y la generaci´on de di´alogos de chatbot. Algunos de estos modelos son: GPT-4[39] es un modelo multimodal a gran escala (acepta entradas de texto o imagen y produce texto) que puede resolver problemas dif´ıciles con mayor precisi´on que cualquiera de los modelos anteriores de OpenAI, gracias a su conocimiento general m´as amplio y capacidades de razonamiento avanzadas34. Seg´un el informe t´ecnico de GPT-4, este modelo exhibe un rendimiento a nivel humano en varios puntos de referencia profesionales y acad´emicos3. LLAMA2[5] es una colecci´on de modelos de lenguaje grandes preentrenados y ajustados finamente que var´ıan en escala desde 7 mil millones hasta 70 mil millones de par´ametros. Los modelos LLAMA2-Chat, que son los modelos de LLAMA2 ajustados finamente, est´an optimizados para casos de uso de di´alogo. BARD[20]: es una interfaz para un modelo de lenguaje grande que permite a los usuarios colaborar directamente con la IA generativa. Seg´un Google, BARD es m´as ´util en este momento como un experimento independiente, ya que permite entender exactamente c´omo las personas quieren usar esta nueva tecnolog´ıa para su propia colaboraci´on. Bing GPT[6] es el modelo de lenguaje grande de Microsoft que se utiliza para alimentar su funci´on de b´usqueda profunda8. Microsoft actualiz´o sus herramientas Copilot al modelo GPT-4 hace unos meses. Uno de los inconvenientes de los LLMs en la actualidad, es el c´omo analizan los textos, usando la denominada tokenizaci´on [7]. Grosso modo, el texto a analizar se divide en tokens (cada modelo lo realiza de un modo) para as´ı poderlo analizar. ¿Cu´al es el problema? Existe una limitaci´on de tokens al enviar una entrada al modelo, o la falta de memoria a corto plazo para poder seguir una conversaci´on fluida. Actualmente, 16 problemas de configuraci´on o mal funcionamiento. Bucle ambiental: Ocurre cuando los servicios de IoT afectan los canales f´ısicos o ambientales de manera negativa, creando interferencias o perturbaciones que afectan el funcionamiento de otros dispositivos o sistemas en el entorno. Redundancia: Se refiere a la presencia de aplicaciones o servicios redundantes que realizan acciones similares o tienen una relaci´on de dependencia impl´ıcita entre s´ı. Esto puede generar confusi´on en la ejecuci´on de acciones y aumentar la complejidad del sistema. Acci´on bloqueada: En algunos casos, los nodos o dispositivos pueden tener una relaci´on de exclusi´on mutua, lo que impide que ciertas aplicaciones se ejecuten o que ciertas acciones se lleven a cabo simult´aneamente. Esto puede conducir a situaciones en las que las acciones quedan bloqueadas o no pueden completarse correctamente. Estos conflictos pueden ser especialmente problem´aticos en entornos donde m´ultiples sistemas y dispositivos IoT operan en conjunto, y es importante abordarlos mediante la implementaci´on de estrategias de gesti´on de conflictos y coordinaci´on eficaces entre los diferentes componentes del sistema de dom´otica. La reciente apuesta por el est´andar Matter podr´ıa solucionar gran parte de estos problemas. Aun as´ı, se necesitar´ıa optimizar la red local para minimizar interferencias e implementar algoritmos de control. 3.4.3. Impacto en la diversidad, sostenibilidad y ´etica social Una de las mayores preocupaciones en torno a las inteligencias artificiales, como los LLMs, es que no solo aportan cambios beneficiosos como los hablados anteriormente. Estas herramientas tienen un impacto considerable en varios sectores, no solo en la dom´otica, sino tambi´en en educaci´on, traducci´on e ingenier´ıa, si se utilizan en estos campos. Es imperativo considerar el impacto que estos sistemas pueden tener, bas´andose en los resultados y conclusiones obtenidos. Desde el punto de vista de la sostenibilidad, el uso de los LLMs puede mejorar la eficiencia de los proyectos en los que se implementan, como por ejemplo, en la generaci´on de c´odigo para proyectos inform´aticos, reduciendo as´ı el consumo de energ´ıa necesario para desarrollar un proyecto y disminuyendo los costos econ´omicos. Este primer beneficio est´a en l´ınea con la programaci´on verde [41], que busca adoptar metodolog´ıas para que el desarrollo de software sea respetuoso con el medio ambiente. Esto se debe a que el c´odigo se habr´ıa generado de manera m´as r´apida y el algoritmo ser´ıa lo m´as eficiente posible. En cuanto a la reducci´on de costos econ´omicos, el software se habr´ıa creado en un tiempo menor, lo cual implica menos inversi´on financiera, algo muy atractivo para cualquier empresa, facilitando que los costos de cualquier producto puedan disminuir. Sin embargo, junto a estos beneficios, existen preocupaciones ´eticas significativas y desaf´ıos asociados al uso de los LLMs. La transparencia y la trazabilidad del c´odigo generado pueden ser limitadas, lo que plantea problemas en la atribuci´on de responsa- 23 bilidades en caso de errores. Adem´as, si los LLMs est´an entrenados con datos sesgados, pueden perpetuar o exacerbar estos sesgos, afectando la equidad y la inclusi´on. Es crucial que las bases de datos para el entrenamiento sean variadas y representativas para evitar discriminaciones impl´ıcitas. Otro aspecto importante, es la necesidad de supervisar de cerca la implementaci´on de los LLMs para asegurar que no se vulneren derechos individuales como la privacidad y la seguridad de los datos personales. Adem´as, se deben considerar las implicaciones ambientales de entrenar y operar estos modelos. Los LLMs requieren una cantidad significativa de recursos computacionales y energ´ıa, especialmente durante la fase de entrenamiento, lo que conlleva una considerable huella de carbono [1] [27]. Es esencial desarrollar y adherirse a pr´acticas m´as sostenibles que mitiguen el impacto ambiental de estas tecnolog´ıas. Figura 3.4: Consumo de los modelos a lo largo de los a˜nos [42] Para este proyecto, el impacto ha sido pr´acticamente nulo, ya que se han usado LLMs ya preentrenados. Adem´as, las llamadas se han elegido de manera cuidadosa para minimizar tambi´en ese impacto de uso de energ´ıa. Volviendo a la dom´otica, el uso integrado de los LLMs en sistemas de dom´otica presenta oportunidades significativas para la optimizaci´on de recursos en el hogar. Mediante algoritmos inteligentes, estos sistemas pueden aprender de los patrones de comportamiento de los usuarios y ajustar autom´aticamente la iluminaci´on, la calefacci´on, el aire acondicionado y otros sistemas dom´esticos para maximizar la eficiencia energ´etica. Esto no solo reduce el consumo de energ´ıa, sino que tambi´en contribuye a una reducci´on significativa de la huella de carbono de los hogares. Sin embargo, es esen- 24 cial incorporar consideraciones ´eticas y sostenibles en el dise˜no de estos sistemas para asegurar que la privacidad y la autonom´ıa de los usuarios no se vean comprometidas. En el contexto de la dom´otica, los LLMs pueden facilitar una gesti´on m´as inteligente y eficiente del agua y la electricidad, lo que puede llevar a un ahorro considerable de recursos y a una disminuci´on del impacto ambiental. 3.5. Conclusiones del cap´ıtulo Las posibilidades y ayudas en el avance de este ´ambito pueden ayudar a que los hogares sean energ´eticamente eficientes [46], debido a que estos modelos pueden analizar patrones de consumo hist´oricos y actuales para identificar ´areas de mejora y sugerir ajustes personalizados. Por ejemplo, podr´ıan sugerir horarios ´optimos para encender y apagar luces, calefacci´on o aire acondicionado, bas´andose en las preferencias del usuario y en las condiciones ambientales. Adem´as, los LLMs pueden proporcionar informaci´on detallada sobre el uso eficiente de los electrodom´esticos y dispositivos conectados. Desde consejos simples, como apagar los dispositivos en modo de espera, hasta recomendaciones m´as complejas, como la actualizaci´on de electrodom´esticos obsoletos por modelos m´as eficientes energ´eticamente. La interacci´on fluida tambi´en podr´ıa facilitar la adopci´on de h´abitos m´as conscientes en cuanto al consumo energ´etico. A trav´es de interfaces conversacionales intuitivas, los usuarios podr´ıan hacer preguntas sobre c´omo reducir su huella de carbono en el hogar o recibir consejos personalizados sobre c´omo optimizar el uso de la energ´ıa. En ´ultima instancia, la evoluci´on de este ´ambito tiene el potencial de transformar nuestros hogares en espacios m´as eficientes, sostenibles, seguros y confortables. 25 4. Descripci´on de la propuesta 4.1. Introducci´on En este cap´ıtulo, se describir´a el prototipo a desarrollar y se esbozar´a su dise˜no, sin profundizar en los detalles t´ecnicos del desarrollo. 4.2. Propuesta El prop´osito principal del prototipo es emplear modelos de lenguajes de aprendizaje autom´atico (LLMs) para generar los scripts necesarios que permitan a Home Assistant interactuar con los dispositivos inteligentes del hogar. El objetivo es que estos scripts faciliten la adaptaci´on autom´atica de los dispositivos a escenarios espec´ıficos predefinidos, optimizando as´ı el entorno dom´estico para aumentar el confort y la comodidad del usuario. Mediante esta integraci´on, se busca que Home Assistant pueda prever y ajustar de manera aut´onoma las condiciones del hogar, como la iluminaci´on, la temperatura, y otros par´ametros, en funci´on de las necesidades y preferencias del usuario, contribuyendo significativamente a mejorar la calidad de vida en el hogar. 4.3. Entorno de ejecuci´on El prototipo o sistema se configur´o localmente en una m´aquina equipada con Windows 11, utilizando Visual Studio Code para el desarrollo y gesti´on del c´odigo. Este sistema requiere el servidor de Home Assistant para su funcionamiento, el cual fue implementado en un entorno virtualizado en la misma m´aquina. Para la interacci´on con el modelo de lenguaje de aprendizaje autom´atico (LLM) seleccionado, se establecieron conexiones remotas mediante API hacia el servidor LlamUS, proporcionado por la Universidad de Sevilla. Este acceso fue otorgado espec´ıficamente para la ejecuci´on de este proyecto. Inicialmente, las primeras pruebas con los primeros modelos LLM se realizaron utilizando las versiones web de estos modelos, permitiendo una r´apida evaluaci´on y ajuste del sistema antes de la integraci´on final. Posteriormente, las pruebas de concepto se llevaron a cabo en un entorno real proporcionado por el tutor del proyecto, utilizando su propio sistema dom´otico. Este enfoque bif´asico de prueba, primero virtual y luego real, asegur´o una evaluaci´on exhaustiva y pr´actica del sistema en condiciones de uso cotidianas. 26 4.4. Estructura de Home Assistant Arquitectura Antes de hablar de cualquier aspecto t´ecnico referente a los LLMs o el c´odigo en s´ı, es esencial especificar c´omo funciona Home Assistant por dentro. Se compone de varias partes clave [8]: Event Bus: Coraz´on de HA. Facilita la ejecuci´on y escucha de eventos. State Machine: Registro de los estados de las entidades. Cuando un estado cambia, dispara un evento state changed Service Registry: Escucha los eventos call service. Timer: Env´ıa un evento time changed cada segundo al Event Bus. Figura 4.1: HA Core Architecture, fuente: [8] Como se ver´a m´as adelante, en la automatizaci´on del script, la parte de registro de estado de las entidades y escucha de eventos es crucial. Esta estructura permite que HA sea ampliamente personalizable y adaptable, lo que le permite integrarse con una amplia gama de dispositivos y servicios IoT mediante lo que se conoce como integraciones. Estas integraciones est´an a cargo de dominios espec´ıficos, como luces e interruptores. Estos dominios incluyen dominios de Internet de las cosas, interacci´on con dispositivos y servicios externos, representaci´on de puntos de datos virtuales o computacionales y acciones que el usuario puede activar o responder a eventos. Esto permite que HA no solo maneje la automatizaci´on de rutinas dom´esticas, sino que tambi´en se integre y responda de manera inteligente a las necesidades y cambios del entorno. 27 Integraciones Figura 4.2: HA Integration Architecture, fuente: [13] Las integraciones permiten a los desarrolladores ampliar y personalizar la funcionalidad de Home Assistant, permiti´endole trabajar en una variedad de ´areas, como interactuar con dispositivos reales y administrar datos virtuales o computados. Como hemos visto antes, esto funciona porque HA utiliza una arquitectura basada en eventos. Dependiendo de un evento espec´ıfico, cada dispositivo inteligente se considera una entidad con sus propios estados. Las integraciones son b´asicamente extensiones que permiten que HA se comunique con dichos dispositivos, como las luces inteligentes de Philips o los televisores inteligentes de varios fabricantes. Estas integraciones son responsables de interpretar los comandos de HA y convertirlos en acciones que el dispositivo espec´ıfico puede entender y ejecutar. Las acciones descritas se desencadenan mediante eventos, que pueden ser programados o desencadenados por cambios en el entorno, como un sensor de movimiento que detecta actividad. Cuando se produce un evento, HA puede ejecutar servicios asociados, que son funciones espec´ıficas como encender una luz o ajustar el termostato. Por ejemplo, si el evento es llegada a casa, los servicios pueden incluir encender las luces y ajustar la calefacci´on. Esto es crucial para el trabajo, pues nuestro script se basa en diferentes servicios basado en un evento concreto. En el contexto de esta prueba de concepto, cuando se detecta que es hora de dormir (I want to sleep) como tarea, el script puede activar autom´aticamente una serie de acciones como atenuar las luces en el sal´on, apagar dispositivos que no se necesiten y ajustar la temperatura de la habitaci´on, todo mediante el uso de integraciones y automatizaciones en HA. 28 4.5. LLMs utilizados Tal como se ha ido hablando hasta ahora, para el prototipo final se ha llevado a cabo el uso de un ´unico LLM, concretamente Llama2-70b de Meta. La elecci´on de este modelo se fundamenta en dos razones principales. La primera se relaciona con su habilidad para generar el c´odigo requerido, mientras que la segunda concierne al aspecto econ´omico. Inicialmente, realizamos m´ultiples pruebas en diversos Modelos de Lenguaje de Gran Escala (LLMs) a trav´es de sus interfaces web, empleando datos simulados para evaluar el desempe˜no de cada modelo y seleccionar el m´as adecuado. Estas pruebas se llevaron a cabo siguiendo la gu´ıa metodol´ogica descrita a continuaci´on, la cual represent´o una posible visualizaci´on del prototipo final: 1. Interacci´on Inicial del Usuario: A trav´es de la aplicaci´on, el usuario introducir´a manualmente la tarea que desea realizar y, si es relevante, especificar´a el lugar dentro del hogar donde desea ejecutar la acci´on para proporcionar informaci´on adicional. 2. Solicitud a Home Assistant: Se realizar´a manualmente una petici´on a Home Assistant para recopilar informaci´on sobre los dispositivos disponibles en la casa, incluyendo sus estados, localizaciones y valores actuales. 3. Interpretaci´on y Configuraci´on por el LLM: El modelo de lenguaje interpretar´a los datos de los dispositivos y, basado en su criterio, sugerir´a manualmente la configuraci´on ´optima para la tarea indicada. 4. Generaci´on de Prompts: Los prompts para el LLM se construir´an de la siguiente manera: comenzar´an con ”Quiero realizar la siguiente tarea: [TAREA]”, seguido de la informaci´on interpretada. Concluir´an con la pregunta: ”¿Cu´al ser´ıa la configuraci´on ideal para esta tarea? Proporci´oname solo el script para Home Assistant.” 5. Pruebas Iniciales: Las pruebas se llevar´an a cabo en dos casas inteligentes ficticias, representadas en formato JSON para facilitar la comprensi´on. Estas casas estar´an equipadas con diferentes dispositivos y sensores y se clasificar´an de menos a m´as inteligentes. Los modelos que se probaron fueron los siguientes: Bard / Gemini PRO ChatGPT 3.5 Turbo Microsoft Copilot Llama 2 Las tareas que se probaron fueron las siguientes: Quiero leer un libro en el sal´on Voy a cocinar una receta nueva Necesito concentrarme para estudiar 29 Quiero hacer ejercicio en casa Voy a tener una videollamada de trabajo Quiero ver una pel´ıcula de acci´on Voy a dormir Debido a que eran datos ficticios, no hab´ıa l´ımite ninguno en cuanto a los dispositivos disponibles, es por ello que en los datos suministrados, se incluyeron varias combinaciones de los siguientes tipos en las diferentes ubicaciones: Luces, bombillas y tiras de LED: Puedes controlar la iluminaci´on de tu casa, cambiar colores, ajustar la intensidad, etc. Enchufes y regletas inteligentes: Te permiten controlar el encendido y apagado de los dispositivos conectados a ellos. Termostatos: Puedes ajustar la temperatura de tu casa de forma remota. Aires acondicionados y mandos a distancia IR universales: Permiten controlar la climatizaci´on de tu casa. C´amaras de seguridad y sensores de movimiento: Te ayudan a mantener la seguridad de tu hogar. Interruptores inteligentes: Te permiten controlar las luces y otros dispositivos el´ectricos. Sensor de climatizaci´on: Controla la temperatura en los diferentes ambientes dentro del domicilio. El dispositivo capta los grados externos, regulando el sistema operativo interno. Sensor detector de humo: Identifica la acumulaci´on anormal de humo en los diferentes espacios, proporcionando una mayor seguridad. Sensor de Seguridad: Detecta movimientos inesperados, permitiendo configurar la alarma de intrusi´on. Sensor de gas: Detecta la presencia de gases peligrosos en el ambiente. Sensor de humedad: Mide la cantidad de agua presente en el aire. Sensor de inundaciones: Detecta la presencia de agua en lugares donde no deber´ıa haber, como en el suelo de una cocina o un ba˜no. Sensor de iluminaci´on: Mide la cantidad de luz en un ambiente. Cabe destacar que las configuraciones de las casas ficticias fueron tambi´en dadas por ChatGPT-3.5, indic´andoles que dispositivos se quer´ıan usar y que tuviera total libertad en cuanto a los estados de estos. Extracto de c´odigo 4.1: Configuraci´on de Dispositivos de CASA 1 1[ 2{ 3"entity_id":" light . living_room " , 30 4" state ":"on", 5"attributes": { 6"friendly_name":" Living Room Light " , 7"brightness": 200 , 8"color_temp": 400 9} 10 }, 11 { 12 "entity_id":" light . kitchen " , 13 " state ":"on", 14 "attributes": { 15 "friendly_name":" Kitchen Light " , 16 "brightness": 180 , 17 "color_temp": 380 18 } 19 }, 20 { 21 "entity_id":" light . bedroom " , 22 " state ":"on", 23 "attributes": { 24 "friendly_name":" Bedroom Light " , 25 "brightness": 160 , 26 "color_temp": 350 27 } 28 }, 29 { 30 "entity_id":" switch . bedroom_socket " , 31 " state ":"on", 32 "attributes": { 33 "friendly_name":" Bedroom Socket " 34 } 35 }, 36 { 37 "entity_id":" climate . living_room_ac " , 38 " state ":" cool " , 39 "attributes": { 40 "friendly_name":" Living Room Air Conditioner ", 41 "current_temperature": 25.0 , 42 " temperature ": 22.5 43 } 44 }, 45 { 46 "entity_id":" binary_sensor . garage_motion_sensor " , 47 " state ":" off", 48 "attributes": { 49 "friendly_name":" Garage Motion Sensor " 50 } 31 51 }, 52 { 53 "entity_id":" sensor . gas_sensor " , 54 " state ":" clear ", 55 "attributes": { 56 "friendly_name":" Gas Sensor " 57 } 58 }, 59 { 60 "entity_id":" cover . bedroom_blind ", 61 " state ":" open " , 62 "attributes": { 63 "friendly_name":" Bedroom Blind " 64 } 65 }, 66 { 67 "entity_id":" media_player . living_room_tv ", 68 " state ":" off", 69 "attributes": { 70 "friendly_name":" Living Room TV " 71 } 72 }, 73 { 74 "entity_id":" cover . living_room_blind " , 75 " state ":" closed ", 76 "attributes": { 77 "friendly_name":" Living Room Blind " 78 } 79 } 80 ] Extracto de c´odigo 4.2: Configuraci´on de Dispositivos de CASA 2 1{ 2"attributes": { 3"friendly_name":" Home " 4}, 5"entity_id":" group . all_devices " , 6" state ":" home " , 7" last_changed ":"2024-02-08T12:32:07.007007+00:00", 8" last_updated ":"2024-02-08T12:32:07.007007+00:00", 9" context ": { 10 "id":" abc123 " , 11 " user_id ": null 12 }, 13 " groups ": [ 14 { 15 "group_id":" group . living_room " , 32 Tarea 2: En la segunda tarea, todos los LLMs, excepto Llama, ofrecen respuestas m´as coherentes. Aunque las respuestas son muy similares entre s´ı, Llama se queda rezagado en este aspecto. Tarea 3: Al abordar la tercera tarea, es notable que los LLMs disponen tanto de un termostato como de un aire acondicionado, y en su mayor´ıa, encienden ambos dispositivos. Esta acci´on puede considerarse excesiva y sugiere la necesidad de prompts m´as avanzados para mejorar la especificidad de las respuestas. ChatGPT y Bing muestran un desempe˜no similar, con la ´unica diferencia de que Bing tiende a reducir excesivamente las temperaturas. Tanto ChatGPT como Llama ofrecen respuestas bastante acertadas. Por otro lado, Gemini tiende a inventar dispositivos, lo cual no resulta ´util para la tarea. Tarea 4: En la cuarta tarea, Llama 2 demuestra un uso ´optimo de todos los dispositivos disponibles al utilizar los sensores, especificar el estado de cada uno y controlar las luces de manera adecuada. Sin embargo, ChatGPT y Bing configuran las luces de manera m´as efectiva, aunque dejan varios dispositivos sin utilizar o verificar. Bard, por otro lado, ofrece resultados satisfactorios, pero sus respuestas no son concisas y tienden a ser m´as extensas de lo necesario. Tarea 5: En la quinta tarea, tanto Llama 2 como Bing proporcionan resultados similares y precisos. Gemini contin´ua realizando suposiciones, mientras que ChatGPT, aunque ligeramente inferior a Llama y Bing, se mantiene competitivo. Tarea 6: En la sexta tarea, todos los LLMs ofrecen respuestas coherentes, excepto Llama, que no comprende la necesidad de encender el interruptor de la televisi´on. Tarea 7: En la s´eptima tarea, Bard y ChatGPT destacan al proporcionar respuestas altamente coherentes, como mantener las temperaturas del aire acondicionado y del termostato sin interferencias. ChatGPT 3.5 se caracteriza por ser un modelo sumamente robusto que provee respuestas m´as que adecuadas para los prop´ositos de este proyecto. Esta observaci´on se extiende tanto a Llama2 como a Microsoft Copilot, los cuales tambi´en exhiben un desempe˜no destacado. Existe, sin embargo, margen para perfeccionar estas respuestas mediante la elaboraci´on de prompts m´as complejos que permitan al modelo considerar de manera m´as efectiva los dispositivos disponibles y evitar acciones contraproducentes, como activar simult´aneamente la calefacci´on y el aire acondicionado. En cuanto a Gemini, en ocasiones sus respuestas son precisamente lo que buscamos, aunque su forma de responder presenta desaf´ıos. Actualmente, Gemini ofrece tres versiones distintas de una respuesta (al menos en las interacciones por chat), lo que obliga al usuario a discernir cu´al de ellas se ajusta mejor a sus necesidades. Este enfoque resulta impr´actico en un contexto de automatizaci´on. Adem´as, Gemini tiene tendencia a realizar suposiciones que van m´as all´a del prompt y la informaci´on proporcionada, lo que puede deberse a su naturaleza experimental como modelo de reciente desarrollo. Con el objetivo de optimizar los resultados obtenidos, se llevar´a a cabo otra prueba con un prompt a´un m´as refinado para determinar si las respuestas mejoran y as´ı poder tomar una decisi´on final. En esta siguiente fase de pruebas, se excluir´a a 39 Gemini por el momento, enfocando los esfuerzos en evaluar la precisi´on y utilidad de los otros modelos mencionados. Prueba 3 Tras evaluar las respuestas iniciales, donde se identificaron algunas interferencias, se procedi´o a una prueba adicional utilizando la tarea ’Necesito concentrarme para estudiar’. En esta ocasi´on, se ajustaron los datos del sensor de temperatura a 31 grados Celsius y se incluy´o en el prompt la directriz ’Usa solo los dispositivos necesarios para ahorrar energ´ıa’. Extracto de c´odigo 4.7: Modificaci´on del estado en el sensor de temperatura 1{ 2"entity_id":"sensor.temperature_main_bedroom", 3" state ": 31, 4"attributes": { 5"friendly_name":" Main Bedroom Temperature Sensor " 6} 7}, 8{ 9"entity_id":" climate . smart_thermostat_main_bedroom " , 10 " state ":" heat " , 11 "attributes": { 12 " temperature ": 31 , 13 "friendly_name":" Main Bedroom Smart Thermostat " 14 } 15 }, Esta modificaci´on condujo a resultados reveladores. Tanto Chat GPT 3.5 como Llama, al procesar la solicitud de ahorro energ´etico, asociaron autom´aticamente esta directriz con desactivar el aire acondicionado, una acci´on posiblemente influenciada por sus respectivos entrenamientos de datos. Figura 4.3: Apagado del aire acondicionado, respuesta de ChatGPT3.5 Turbo Por el contrario, si la temperatura ambiente fuera est´andar, aproximadamente 21 grados, ambos modelos apagar´ıan el aire pero mantendr´ıan el termostato activo. No obstante, Microsoft Copilot, al utilizar GPT-4, mostr´o una mayor comprensi´on de 40 las necesidades impl´ıcitas, activando el aire acondicionado para reducir la temperatura ambiente a un rango ´optimo de 21 a 23 grados, ajustando posteriormente seg´un fuera necesario. Figura 4.4: Encendido del aire acondicionado, respuesta de Microsoft Copilot Esta respuesta es m´as congruente con el objetivo planteado. Aunque este experimento se centr´o en la gesti´on de la temperatura, los hallazgos podr´ıan aplicarse a otros ´ambitos dom´esticos, destacando a Microsoft Copilot, que se basa en GPT-4, como el LLM con mejores resultados. Esta superioridad se atribuye principalmente a las capacidades avanzadas de GPT-4 y a la accesibilidad de su API. Mientras que Microsoft Copilot a´un no ofrece una API, y considerando su modelo de pago, GPT-4 emerge como la alternativa m´as viable en t´erminos de resultados. No obstante, se opt´o por utilizar Llama2 en esta investigaci´on, debido a que tambi´en proporciona resultados bastante alentadores. Adem´as, Llama2 es de c´odigo abierto, lo que representa un atractivo adicional. Significativamente, la universidad facilit´o el acceso a un servidor con el modelo ya cargado, lo cual facilit´o su integraci´on y uso en el contexto de este trabajo investigativo. Estos experimentos iniciales buscaban explorar el rendimiento de los LLMs en una configuraci´on dom´estica ficticia. La primera ronda de pruebas, realizada con pocos dispositivos inteligentes y utilizando Chat GPT y Bard, arroj´o resultados prometedores. La segunda ronda, que abarc´o un conjunto m´as amplio de tareas en una casa completamente equipada, vio a Copilot con GPT-4 como el claro vencedor. Durante la tercera prueba, se introdujeron modificaciones para evaluar la adaptabilidad de los LLMs ante variables y escenarios diversos, y nuevamente, Copilot con GPT-4 demostr´o ser el m´as eficaz y mejor entrenado. 4.6. Dise˜no conceptual del prototipo La siguiente imagen representa el dise˜no conceptual, utilizando un diagrama de clases UML ( Unified Modeling Languaje ) del prototipo final. 41 Figura 4.5: Diagrama de clases UML del prototipo final En el siguiente cap´ıtulo se describir´a que hace cada clase y por qu´e. 4.7. Ejecuci´on y funcionamiento Considerando que es un prototipo no comercial, y por ende no es un producto final que deba entrar en producci´on, la ejecuci´on debe ser lo mas sencilla posible. El prototipo se basa en un archivo ’.py’ el cual se ejecuta con la siguiente l´ınea de comando: 1python TFM . py Donde en dicho archivo, con cualquier editor de texto o c´odigo, se debe modificar las variables: HA URL: Direcci´on del servidor de Home Assistant HA TOKEN: Token de la cuenta de Home Assistant TASK: Tarea que se quiera realizar AREA NAME: Nombre del ´area donde se quiera ejecutar la acci´on Cabe destacar que existe otra variable, ’LLLAMAUS TOKEN’, con mi token personal del servidor LlamUS de la Universidad de Sevilla. Es por eso que este trabajo solo se ha enviado a personas de confianza para su ejecuci´on y prueba. 42 5. Validaci´on 5.1. Introducci´on Una vez se ha finalizado el dise˜no conceptual del prototipo y todas sus necesidades, se ha detallado como ha sido el desarrollo del prototipo funcional. 5.2. Herramientas Preparaci´on del entorno de desarrollo Antes de empezar a desarrollar, se ha tenido que preparar todo el entorno de trabajo para trabajar con todas las herramientas necesarias. El IDE seleccionado para poder desarrollar el prototipo fue Visual Studio Code por su simplicidad y comodidad. Instalaci´on de los lenguajes necesarios Como se mencion´o en el capitulo anterior, el lenguaje de programaci´on utilizado es Python, en su versi´on 3.9.13 en este caso. No fue necesario el uso de ning´un otro lenguaje ni plugin. Configuraci´on con la API Como se mencion´o en el cap´ıtulo anterior, el modelo de LLM seleccionado para el prototipo final fue el Llama2, que cuenta con 70 billones de par´ametros. Este modelo se encuentra alojado en el servidor LlamUS de la Universidad de Sevilla [3] [2]. Para acceder a ´el, es necesario configurar una clave privada que autentica al usuario que realiza la llamada. En este proceso, se gener´o una API KEY a trav´es de la plataforma de LlamUS. 43 Figura 5.1: Creaci´on de API KEY en la p´agina de LlamUS Una vez obtenida la clave, y considerando la simplicidad del prototipo, se decidi´o no almacenarla en un archivo .env. En su lugar, la clave se guard´o directamente en una variable global dentro del c´odigo, junto con las dem´as variables globales. Figura 5.2: Variables globales utilizadas en el prototipo Configuraci´on de Home Assistant Al igual que se requiri´o configurar el modelo LLM, tambi´en fue necesario establecer un servidor de Home Assistant para su uso y pruebas en mi domicilio personal. Siguiendo la gu´ıa oficial [16], se emple´o Virtual Box para crear una m´aquina virtual. En esta se instal´o la imagen proporcionada por la gu´ıa, y se procedi´o a seguir detalladamente los pasos del tutorial hasta completar la configuraci´on del servidor. Esta configuraci´on permiti´o un entorno de prueba adecuado para evaluar las funcionalidades del sistema en un contexto realista. 44 Figura 5.3: M´aquina virtual creada y configurada En el servidor de Home Assistant, configuramos cuatro habitaciones, seleccionando dos espec´ıficamente para las pruebas: el Living Room y el Garage. Estas habitaciones se equiparon con un n´umero limitado de dispositivos, los cuales fueron suficientes para el desarrollo del proyecto. Figura 5.4: Habitaciones disponibles La elecci´on de estas habitaciones permiti´o evaluar c´omo el modelo de inteligencia artificial interact´ua y contextualiza su funcionamiento en relaci´on con los dispositivos espec´ıficos en cada entorno. En el Living Room, el modelo se puso a prueba con los siguientes dispositivos: Router ADSL con diversos receptores y sensores Google Cast TV Television SMART TV 45 Figura 5.5: Dispositivos del Living Room En el garaje, la configuraci´on fue m´as sencilla, contando solo con una impresora inteligente. Figura 5.6: Dispositivos del Garage Aunque el n´umero de dispositivos en cada habitaci´on era limitado, resultaron ser suficientes para realizar el prototipo y desarrollar el prompt adecuado. Esta configuraci´on permiti´o validar las funcionalidades b´asicas y asegurarse de que el modelo pod´ıa operar eficazmente en un entorno controlado, lo cual fue crucial para avanzar en las etapas iniciales del proyecto y ajustar los par´ametros de interacci´on. Bibliotecas utilizadas En el desarrollo del proyecto, se han instalado y utilizado varias librer´ıas esenciales para optimizar y facilitar la implementaci´on de las funcionalidades requeridas. Se utiliza asyncio, una librer´ıa de Python que permite la programaci´on as´ıncrona, para manejar operaciones que son I/O-bound de manera eficiente, sin bloquear el hilo principal de ejecuci´on. La librer´ıa re se emple´o para realizar operaciones de b´usqueda y manipulaci´on de cadenas de texto mediante expresiones regulares, para realizar varios filtros en las respuestas dadas por el LLM y Home Assistant. Para gestionar conexiones HTTP as´ıncronas, se utiliza aiohttp, que aprovecha asyncio para realizar peticiones web de manera no bloqueante. websockets, por su parte, se incluy´o para facilitar la comunicaci´on bidireccional y en tiempo real a trav´es de WebSockets, crucial para una funci´on de Home Assistant. Adem´as, json y yaml fueron indispensables para la manipulaci´on de estos formatos de archivo, permitiendo una serializaci´on y deserializaci´on eficiente 46 de datos, as´ı como la configuraci´on y el manejo de metadatos en una estructura legible y f´acil de mantener. 5.3. Descripci´on general de la Arquitectura Flujo del programa Como se muestra en la figura 4.5, el prototipo est´a compuesto por varias funciones que colaboran para generar el script final, el cual dicta las acciones a ejecutar en cada dispositivo. Este flujo se hace uso en la funci´on main del programa. Figura 5.7: Funci´on main del programa El primer paso implica identificar las ´areas configuradas en el servidor de Home Assistant, con el objetivo de localizar los dispositivos pertinentes. Esta funci´on se ejecut´o de manera aislada, es por ello que no sale en la funci´on main. Al inicio de la funci´on, se establece una conexi´on WebSocket al servidor de Home Assistant. Se env´ıa un mensaje de autenticaci´on usando un token de acceso, declarado en la variable vista en la figura 5.2 y se espera hasta recibir una confirmaci´on (auth ok). Una vez autenticado, la funci´on solicita la lista de ´areas utilizando un mensaje espec´ıfico del protocolo de Home Assistant (config/area registry/list). La respuesta recibida es procesada para extraer ´unicamente los nombres de las ´areas, que posteriormente son devueltos por la funci´on. Inicialmente, se intent´o realizar esta consulta mediante la API REST de Home Assistant; sin embargo, esta funcionalidad espec´ıfica no est´a disponible en dicha API. 47 Figura 5.8: Funci´on as´ıncrona get areas 48 Figura 5.15: Funci´on as´ıncrona process text and extract yaml en una variedad de posibles respuestas. En algunas ocasiones, el modelo podr´ıa devolver ´unicamente el archivo .yaml, mientras que en otras, podr´ıa incluir una breve descripci´on junto con el .yaml, o incluso proporcionar solo descripciones sin incluir el .yaml. Sin embargo, es importante mencionar que, con el prompt espec´ıficamente dise˜nado que se ha utilizado, no se ha presentado el escenario de recibir solo descripciones sin el archivo .yaml. La ´ultima funci´on, run script, se encarga de ejecutar el script YAML filtrado. Primero, carga el script para obtener una secuencia de acciones a realizar. Para cada acci´on en la secuencia, la funci´on desglosa el servicio requerido y los datos asociados. Luego, construye una URL espec´ıfica para invocar ese servicio en el API de Home Assistant, utilizando el dominio y el nombre del servicio especificados. 55 Figura 5.16: Funci´on as´ıncrona send prompt Si la solicitud es exitosa (HTTP 200), indica que el servicio ha sido ejecutado correctamente. De lo contrario, se informa de un error en la ejecuci´on del servicio. Esta funci´on asegura que cada acci´on del script YAML sea procesada individualmente y en el orden correcto, lo que es crucial para la integridad y la eficacia de las automatizaciones dom´oticas, as´ı como evitar interrupciones por posibles servicios que no tiene cabida en la ejecuci´on real. En la siguientes figuras, se puede ver la traza de ejecuci´on de los servicios para la tarea Quiero ver una pel´ıcula en la habitaci´on Living Room. Las figuras 5.17 y 5.18 fueron tomadas en la misma iteraci´on, y la figura 5.19 fue tomada en otra iteraci´on, de modo que se vea tambi´en el no-determinismo del modelo y los tres escenarios derivados posibles. 56 Figura 5.17: Ejemplo JSON que se le pasa al modelo con los dispositivos y estados Figura 5.18: Ejemplo de script de HA generado por Llama2:70b Figura 5.19: Resultados de la tarea Quiero ver una pel´ıcula en la habitaci´on Living Room En la imagen, como se ha especificado antes, se ilustran varios escenarios derivados de una respuesta del modelo LLM. Inicialmente, el modelo identifica la necesidad de encender la televisi´on, que se encuentra apagada, y ejecuta esta acci´on con ´exito. Luego sugiere cambiar la entrada de la televisi´on para utilizar un dispositivo externo de v´ıdeo y activarlo; sin embargo, aqu´ı surge un inconveniente, ya que dichos servicios 57 no son aplicables en la pr´actica debido a que el televisor no tiene conectados tales dispositivos, destacando una falta de contexto que es desafiante de integrar en un proceso automatizado de esta envergadura. Posteriormente, el modelo propone ajustar el volumen del televisor a un nivel considerado adecuado para el o´ıdo humano, lo cual tambi´en se lleva a cabo con ´exito. Finalmente, el modelo emite una instrucci´on basada en un servicio inexistente relacionado con el sensor del router de la casa, un error que la funci´on identifica y descarta autom´aticamente. En el siguiente ejemplo, en una casa m´as inteligente. Solo se mostrar´a las primeras salidas debido a la gran cantidad de dispositivos disponibles. Figura 5.20: Primeras lineas del JSON con los dispositivos y estados 58 Figura 5.21: Primeras lineas del script de HA generado por Llama2:70b 59 Figura 5.22: Resultados de la tarea Quiero ver una pel´ıcula en la habitaci´on salon2 60 6. Pruebas 6.1. Introducci´on Este cap´ıtulo aborda las pruebas de calidad efectuadas en el prototipo del modelo LLM aplicado a la dom´otica. Dichas pruebas incluyen un an´alisis de c´odigo utilizando herramientas de linter para asegurar el cumplimiento de los est´andares de codificaci´on, adem´as de pruebas de carga dise˜nadas para evaluar el rendimiento del modelo en escenarios de alta demanda. Estas pruebas se eligieron con el fin de asegurar la calidad del software y la eficiencia del sistema, anticipando posibles desaf´ıos t´ecnicos que puedan surgir durante su uso real. Dado que el prototipo est´a en una fase inicial, no es posible realizar otros tipos de pruebas, como pruebas de integraci´on completas o pruebas de usuario exhaustivas. 6.2. An´alisis de c´odigo La herramienta seleccionada para realizar el an´alisis fue pylint, ampliamente utilizada por desarrolladores de Python. Para su implementaci´on, simplemente se necesita instalarla en el entorno virtual y a˜nadir la extensi´on correspondiente en Visual Studio Code. Una vez configurada, el an´alisis se ejecuta con el siguiente comando: 1pylint TFM . py Este comando proporciona una lista de advertencias, errores y sugerencias de mejora para el c´odigo, adem´as de una puntuaci´on de calidad entre 0 y 10. En mi caso, la evaluaci´on final fue de 7.48/10. 61 Figura 6.1: Resultado del an´alisis realizado con pylint Notamos que la mayor´ıa de las observaciones est´an relacionadas con espacios en blanco, la falta de comentarios explicativos en las funciones y la necesidad de refactorizar el c´odigo. Un ejemplo de esto es la refactorizaci´on de la funci´on 5.10, que reduce su complejidad y mejora su claridad: Figura 6.2: Refactorizaci´on de la funci´on get devices and entities Al abordar todos estos cambios, logramos una puntuaci´on de 10/10 seg´un pylint: 62 Figura 6.3: Puntuaci´on final 6.3. Pruebas de carga Las pruebas se han realizado enviando m´ultiples solicitudes concurrentes (25 en este caso, divididas en tres iteraciones) al modelo de lenguaje alojado en el servidor de la universidad con el fin de simular el sistema en una casa con varios ocupantes. Estas solicitudes son gestionadas por asyncio, que permite la ejecuci´on as´ıncrona y simult´anea. Figura 6.4: Funci´on para ejecutar simult´aneamente las peticiones Las m´etricas recolectadas son las siguientes: N´umero de solicitudes: Total de solicitudes enviadas al servidor. Solicitudes exitosas: Cantidad de respuestas exitosas obtenidas sin error. Tasa de errores: N´umero de errores registrados durante la prueba. Tiempo promedio de respuesta: Tiempo promedio que tarda el servidor en responder cada solicitud Respuestas con errores: C´odigos de estado HTTP espec´ıficos devueltos por las solicitudes err´oneas. Resultados Obtenidos De la primera iteraci´on, de 10 solicitudes enviadas, 6 fueron exitosas y 4 resultaron en errores (todos 500), lo cual indica problemas internos del servidor. El tiempo promedio de respuesta fue de 90.34 segundos, lo cual es bastante alto y podr´ıa afectar negativamente la experiencia del usuario en un entorno de producci´on. 63 Figura 6.5: Resultados de las m´etricas de la primera iteraci´on Sin embargo, en la segunda interacci´on, de las 10 solicitudes, todas fueron exitosas, aunque el tiempo promedio aument´o debido a esto, siendo igualmente bastante negativo para una experiencia de usuario satisfactoria. Figura 6.6: Resultados de las m´etricas de la segunda iteraci´on En la ´ultima iteraci´on, vemos que todas las pruebas han fallado, espec´ıficamente por timeout, lo que comprobando el mismo servidor a trav´es de la interfaz, se hab´ıa ca´ıdo dicho modelo debido a la carga soportada. Figura 6.7: Resultados de las m´etricas de la tercera iteraci´on Errores Internos del Servidor (500): Estos errores son indicativos de problemas en el servidor que no est´an relacionados directamente con los datos de 64 [41] Alberto Felipe Anchundia Padilla, Edison Steven Barzola ´ Avila, and Renzo Alexander Tomala Sol´orzano. Programaci´on verde en el software. revistas.unesum.edu.ec, February 2023. doi: 10.47230/unesum-ciencias.v7.n1.2023.419. URL https://doi.org/10.47230/unesum-ciencias.v7.n1.2023.419. [42] Javier Pastor. El oscuro secreto de chatgpt y bard no es lo que se equivocan e inventan. es lo que contaminan, February 2023. URL https://www.xataka.com/robotica-e-ia/ oscuro-secreto-chatgpt-bard-no-que-se-equivocan-e-inventan-que-contaminan. [43] Alec Radford, Karthik Narasimhan, Tim Salimans, and Ilya Sutskever. Improving Language Understanding by Generative Pre-training. https://openai.com/ research/learning-language-models/, 2018. [44] Dinesh V. Rojatkar Sharda R. Katre. Home automation: Past, present, and future. https://d1wqtxts1xzle7. cloudfront.net/54947332/IRJET-V4I1061-libre.pdf?1510139979= &response-content-disposition=inline%3B+filename%3DHOME AUTOMATION PAST PRESENT AND FUTURE.pdf&Expires=1706789728&Signature= Qz∼5mHatRgElQ6gKLhs2iaKZ5X7EvEK-JLPAZ5∼sqq7iobM1daLahcEkRjLSruNoDyVnGv1acQAO0t92G6wG-697yqy6GckgTVzAdy-MySjFLhzahWB∼HQYcCqbft0RddEcZUr-L4gtccTflbC30QIUPM5150g20iN7O0LWr58Gqkoe1LtsCT7∼wT32wEFTJ5xziQ40gXNPka54eLYNEp5TqdM5D3gpIzd7-1TcVKyi61Txfl∼F∼5xgTK∼4M0JAZ06tKtXE∼kBN7lGi5FkluhxMK4Kjz-12NQ0KpsSnCTNNTlPHcyuywP5ZYfIKqF8hQSKTLBvZyReYY9gL7vW∼l∼w &Key-Pair-Id=APKAJLOHF5GGSLRBV4ZA, Fecha de acceso: 1 de febrero de 2024. [45] Telef´onica Tech. Dom´otica: la revoluci´on en la gesti´on del hogar. https: //telefonicatech.com/blog/domotica. [46] Satyendra K. Vishwakarma, Prashant Upadhyaya, Babita Kumari, and Arun Kumar Mishra. Smart energy efficient home automation system using iot. In 2019 4th International Conference on Internet of Things: Smart Innovation and Usages (IoT-SIU), pages 1–4, 2019. doi: 10.1109/IoT-SIU.2019.8777607. [47] J. Vujic, A. Marincic, M. Ercegovac, and B. Milovanovic. Nikola tesla: 145 years of visionary ideas. In 5th International Conference on Telecommunications in Modern Satellite, Cable and Broadcasting Service. TELSIKS 2001. Proceedings of Papers (Cat. No.01EX517), volume 1, pages 323–326 vol.1, 2001. doi: 10.1109/ TELSKS.2001.954901. [48] Jingqing Zhang, Chengyue Zhao, Mohammad Saleh, and Peter Liu. PEGASUS: Pre-training with Extracted Gap-sentences for Abstractive Summarization, 2019. 71