Es frustrante cuando usamos un LLM para realizar una tarea, estamos comprobando el resultado y tras un par de párrafos que tienen muy buen aspecto el texto da un giro inesperado y empieza a inventarse cosas. En este caso decimos que el modelo alucina. Pero no es el único caso de alucinación, cuando genera contradicciones en el texto o pierde el hilo de lo que ha escrito también está alucinando.
En los casos más graves puede generar texto sin ningún sentido. Sin embargo, los casos más peligrosos son aquellos en que la respuesta parece correcta pero no lo es. De hecho, muchas veces, los modelos de lenguaje son bastante buenos argumentando en favor de la respuesta que han dado.
Entonces ¿Qué es una alucinación? No está claro, depende del modelo, del contexto y del prompt. Si por ejemplo a un modelo entrenado para tener censura sobre ciertos temas nos responde con la receta de una bomba está alucinando, pero para un modelo sin cesura es correcto, a no ser que en mitad de la receta empiece a usar cacao, harina y huevos.
Un punto a tener claro es que una alucinación NO ES el un mal funcionamiento del sistema, es el funcionamiento normal del mismo, por eso es tan difícil saber cuando el modelo está generando alucinaciones, ya que funcionalmente es idéntico a cuando no las produce
Hay cuatro (se que abajo veis cinco puntos, no es un error) principales causas de las alucinaciones,vamos a verlas junto con las técnicas para reducirlas:
Prompts: Los prompts confusos, que introduzcan información errónea o directamente malintencionados pueden ser la causa de las alucinaciones. No tiene porque ser prompts incorrectos de forma intencionada. La mejor opción para evitar estas alucinaciones es repasar los prompts y tratar de ser cuidadoso y claro en la redacción de los mismos. Y tratar de no añadir información que no sea completamente cierta. Otros «trucos» que suelen funcionar es pedirle que razone paso a paso o hacerle chantaje emocional (¡En serio!) diciéndole que es muy importante que lo haga correctamente o proprias perder el trabajo (repito: es en serio)
Datos de entrenamiento: los modelos de lenguaje están entrenados con datos de diversas fuentes, por lo que entre ellas se pueden producir contradicciones o directamente contener datos incorrectos. Las dos principales opciones para reducir estás alucinaciones son el fine tuning con datos adecuados o complementar el prompt con información más concreta (por ejemplo usando RAG)
Elegir un token poco probable: una vez el modelo ha calculado las probabilidades de los «siguientes tokens» se realiza una selección aleatoria de uno de ellos, puede ser que alguna vez se elija un token con pocas probabilidades de ser elegido y eso haga que la predicción de tokens «pierda el rumbo». Es lo que suele pasar cuando subimos el parámetro «temperatura». Depende el programa que usas para ejecutar el LLM tendrás diversos parámetros como top-K, top-P, min-P o la temperatura que permite acotar la probabilidad de los tokens validos para ser elegidos.
El token más probable es incorrecto: Este caso podríamos agruparlo dentro del de datos de entrenamiento, pero lo pongo aqui separado para distinguirlo del anterior. Ya que no es que se elija un token poco probable, es que los más probables son incorrectos. La solución es la misma que en el caso de los datos de entrenamiento.
Pérdida del contexto: los modelos tienen un tamaño de contexto. Cuando la conversación se alarga y sobrepasa este tamaño se pierde información lo que puede hacer que el modelo pierda «el tema de la conversación». Casi todos los programas para ejecutar LLM traen alguna solución para conservar el prompt inicial o parte del mismo. De todas formas es recomendable tratar de mantener la conversación lo más corta posible.
Os aviso que estas soluciones no son milagrosas, que aun usándolas no se van a resolver todos los problemas de alucinaciones.
Puedes ver el vídeo en mi canal de Youtube con ejemplos:
Haz click para ver el vídeo en mi canal de Youtube
¿Cómo podemos obtener el prompt que genera una imagen concreta? No podemos. Ha sido un post breve…Para empezar no es sencillo desandar el camino de la imagen hasta el prompt. Una imagen tiene muchísima información que puede o no haber sido detallada en el prompt. Si el protagonista de la imagen sonríe…¿ha sido especificado en el prompt?. Una palabra más y el resultado cambia. Pero es que aunque tuvieras el prompt exacto que usó el creador (mirando por encima de su hombro cuando lo escribió, por ejemplo) haría falta la semilla exacta para obtener la misma imagen.
¿Entonces qué podemos hacer?. Podemos obtener un prompt inspirado en una imagen que nos gusta.
Vamos a empezar por las bases: CLIP. Debajo podemos ver un esquema que resume la arquitectura de Stable Diffussion, en un círculo rojo podemos ver de qué parte se ocupa CLIP.
CLIP actúa como puente entre el lenguaje escrito y las imágenes, transforma el prompt en características de la imagen. También funciona pasándole una imagen, extrae sus características. “¡Ya está!” Le pasamos la imagen y vemos qué palabras corresponden con ella…desgraciadamente aquí es donde surge otro problema. No hay una relación exacta entre las palabras y las imágenes. Ambos se codifican como vectores y se toma el más cercano, sin embargo esto puede dar lugar a que se elijan combinaciones de palabras que no son tan buenas describiendo la imagen.
En la imagen podemos ver un ejemplo donde la combinación de palabras: “RUEDAS FARO ROJO” está más próxima a la imagen del coche que “COCHE”.
Con esta información ya podemos hacernos una idea de como funcionan estos sistemas, van probando diferentes combinaciones de palabras. Desde el algoritmo más simple que usar varias listas de palabras e ir combinándolas para crear frases. por ejemplo un listado de objetos, colores, planos, artistas, estilos, ….. Hasta algoritmos más complejos como PEZ.
Vamos a probar dos herramientas con la siguiente imagen:
Veamos que prompts generan y cual es el resultado si usamos esos prompts para generar unas cuantas imágenes.
cartoon robot writing in front of easel with cityscape in background, icon for an ai app, he is holding a large book, delete duplicating content, studyng in bedroom, a painting of white silver, image of random arts, textbook page, 2019, future coder, retro coloring
Sin embargo hay una opción más, usar un modelo multimodal (como LLaVA que es el que usaremos en este post) para que te describa la imagen. Podemos usar el prompt:
Describe the image
Nos da una descripción pero no es lo que queremos. No faltan datos sobre composición, habrá que pedirselos:
Describe the image in detail: subject, composition, color, type of lens, setting, similar famous artists
El resultado es el que queremos
Tell me what type of art the image is in a few words in no more than 20 words
Describe the art style in the image in few words in no more than 20 words
Describe the artistic composition of the image in no more than 20 words
Describe the type of lens use in the image
Describe the kind of color in the image
Describe the photo in few words
Describe the sensations conveyed by the image in few words
Tell me the name of a famous artist whose work is similar to the one in the image. Respond with name only
Juntando todos las respuestas (omitiendo las repetidas):
Robot painting. Fisheye Lens. Cartoon. A robot is standing in a room, holding a pencil and looking at a book. The room has a painting on the wall and a window. The robot is surrounded by several books, some of which are stacked on the floor. Leonardo da Vinci
Puedes ver el proceso en vídeo en mi canal de Youtube:
Haz click para ver el vídeo en mi canal de Youtube
Cuando aparecieron los primeros modelos de texto a imagen requerían un hardware potente y mucha paciencia para obtener resultados que en esa época eran sorprendentes (actualmente los consideraríamos como «malos resultados»). Esos primeros modelos basados en VQGAN requerían varios minutos usando hardware potente, Google Colab mediante, para lograr generar una imagen. Con los modelos de difusión la cosa mejoró, sin embargo seguíamos necesitando GPUs con gran cantidad de memoria RAM. Pero la comunidad de software libre está haciendo un gran esfuerzo por lograr que se ejecute en hardware cada vez más modesto.
¿Hasta qué punto se ha optimizado Stable Diffusion? ¿Podemos usarlo en un ordenador normalito?.
Primero, uso Stable Diffusion porque al ser código libre ha permitido a la gente «trastear» con él, ventajas del Open Source.
Al empezar a mirar opciones he descubierto que hay muchísimos proyectos que tratan de reducir los recursos necesarios para ejecutar SD. Al final me he decantado por el proyecto stable-diffusion.cpp por los siguientes motivos:
Es un proyecto real que trata de hacer SD usable con muchas de sus características. Muchos de los otros proyectos son poco más que demos técnicas muy limitadas.
Esta en continuo desarrollo.
Busca un equilibrio entre consumo de recursos y usabilidad.
Antes de empezar con las pruebas hemos de entender cómo funciona SD. Para ello usaremos el siguiente esquema:
SD consta principalmente de tres partes:
Text Encoder: convierte el prompt en embeddings que usa para condicionar el funcionamiento de la Unet
Unet: es alimentada con una imagen llena de ruido y su trabajo es eliminarlo, condicionado por el text encoder, para obtener la imagen. En este paso SD no trabaja con la imagen final si no con una descripción en el espacio latente de la misma
V.A.E.: su función es convertir la descripción del paso anterior en una imagen.
Este es el funcionamiento para generar una imagen a partir de un prompt. Si queremos generarla cuando una imagen de partida, además del prompt, lo que se hace es que en lugar de pasar a la Unet una imagen llena de ruido se le pasa la imagen de partida y se le añade ruido. De esta manera la imagen influirá sobre el resultado final.
Sabiendo esto vamos a ver que «trucos» usa stable-diffusion.cpp para conseguir optimizar la ejcución de SD:
Esta programado en C++ buscando exprimir al máximo el rendimiento del programa
Usa un versión cuantizada del modelo. En mis pruebas usar la versión Q4_1 que usa unos 4 bits por parámetro. Mientras que el modelo original usa 32 bits.
Usar la versión mini y nano de SD que generan imágenes mas pequeñas. Este truco lo añado yo después de verlo comentado en el proyecto.
Tenéis un vídeo con detalles de la pruebas y de la tabla de resultados en mi canal de Youtube:
Haz click para ver el vídeo en mi canal de Youtube
./bin/sd -m [modelo] -H 768 -W 768 -p «A sheep with sunglasses riding a motorbike»
Se ha probado con diferentes tamaños de imagen según el modelo empleado:
Modelo
Dim.
Clip
Unet
VAE
Mem.
Tiempo
1.4 – Q4_1
512
73.80/87.21
1286.35/1857.94
94.51/1768.95
1952.45
199.92
1.5 – Q4_1
512
73.80/87.21
1286.35/1857.94
94.51/1768.95
1952.45
218.39
2.1 nano – Q4_1
512
211.55/226.21
1290.15/1669.82
94.51/1768.95
1768.65
254.42
2.1 – Q4_1
512
211.55/226.21
1290.15/1669.82
94.51/1768.95
1768.65
179.76
2.1 – Q4_1
768
211.55/226.21
1290.15/3021.54
94.51/3848.65
3848.65
543.88
1.4 mini – Q4_1
256
73.80/87.21
1286.35/1346.94
94.51/520.65
1468.07
57.44
2.1 nano – Q4_1
128
211.55/226.21
1290.15/1314.91
94.51/208.65
1610.88
15.62
2.1 – f32
512
1346.65/1360.93
2179.92/2553.33
94.51/1768.65
3653.36
181.84
2.1 – f32
768
1346.65/1360.93
2179.92/3897.24
94.51/3848.65
3991.75
566.58
Mem., Clip, Unet y VAE indican el tamaño en MB Clip, Unet y VAE indican el tamaño de: parámetros / total memoria en ejecución Dim. indica el tamaño en pixeles de la imagen Dim x Dim Tiempo indica la duración de la creación en segundos
Las pruebas han sido realizadas en un portátil con un procesador AMD Ryzen 7 5800H con 16 GB de memoria RAM.
Como mención honorifica cabe destacar otro proyecto: OnnxStream que logra ejecutar SD en una Raspberry Pi 2 Zero que solo tiene 512MB (¡Y le sobran casi 200 MB!) de memoria RAM
Últimamente se habla mucho del uso de bases de datos vectoriales combinadas con grandes modelos de lenguaje. ¿Pero que relación tienen?. El punto en común entre ambos son los embeddings. ¿Qué es un embedding?. Un embedding es un vector que representa la descripción del significado de un texto (en este caso) en un espacio de múltiples dimensiones. Este espacio establece una relación entre los diversos significados de los textos, de tal forma que el angulo formado por dos vectores indica lo próximos que sus significados están.
Para calcular lo parecidos que son dos vectores usaremos la similitud coseno (cos_sim): u ⋅ v /∣u∣∣v∣ Siendo u y v vectores. 1 significa que son idénticos, 0 que no tienen relación y -1 que son contrarios.
Los embeddings son usados en los modelos de lenguaje para representar el texto de forma interna y trabajar con él en forma de vectores (no confundir con los wordvectors, aunque la idea es la misma y están relacionados los wordvectors funcionan a nivel de token…si no sabes lo que es un token quédate con que funcionan a nivel de palabra).
Para estas pruebas usaremos el modelo de lenguaje BERT a través de la librería sentence-transformers.
Primero cargamos las librerías que necesitamos y el modelo
import numpy as np
from sentence_transformers import SentenceTransformer, util
#Cargamos el modelo
sbert_model = SentenceTransformer('all-mpnet-base-v2')
Estas son las sentencias con las que vamos a comparar nuestro texto de búsqueda. Las sentencias han sido obtenidas de la Wikipedia en inglés, en concreto la primera del articulo de mecánica cuántica y las siguientes de la definición de física clásica.
sentences = [
"a fundamental theory in physics that provides a description of the physical properties of nature at the scale of atoms and subatomic particles.",
"refers to theories of physics that do not use the quantisation paradigm, which includes classical mechanics and relativity.",
"physical objects ranging from those larger than atoms and molecules, to objects in the macroscopic and astronomical realm",
"in the context of general and special relativity, classical theories are those that obey Galilean relativity."
]
Buscamos *Quantum mechanics*, deberia de dar como mayor similitud el primer texto. Fijaros en la trampa de que el segundo incluye *quantisation paradigm* para «engañar» al modelo y ver si es capaz de buscar por «significado» y no solo por «similitud de las palabras»
Una pequeña optimización que se puede hacer si vas a almacenar estos vectores para compararlos varias veces. Podemos normalizar los vectores, esto significa que le damos longitud uno sin modificar la dirección del mismo, podemos usar el producto escalar (dot_score), mucho más rápido que la similitud coseno.
Si partimos de la similitud coseno u ⋅ v /∣u∣∣v∣ Al tener distancia 1 los módulos || son 1 por lo que el divisor desaparece y queda solo el producto escalar u ⋅ v
¿Pero que tiene esto que ver con las bases e datos vectorariales?. Una base de datos vectorial funciona básicamente como el ejemplo (en realidad usa diferentes operaciones especializadas para diversos casos). Asocia un vector con los datos originales a los que representa y permite buscar a partir de un texto, que es convertido en embedding.
Lo bueno de los embeddings es que no solo puede representar texto, usando modelos multimodales se pueden usar embeddings que provengan de imágenes, audios, vídeos, … Lo que permite cruzar datos heterogéneos.
Esta flexibilidad hace que muchas veces puedan cumplir funciones como búsqueda inteligente de textos, responder preguntas, buscar referencias o datos relacionados que a su vez se pueden combinar con los modelos de lenguaje aportando estos datos al contexto del mismo. Un ejemplo de este eso es su uso en técnicas como RAG descrito en esta entrada del blog
Puedes ver todo esto descrito en el siguiente vídeo de mi canal de Youtube:
En este post vamos a usar audiocraft la IAs que ha publicado Meta centradas en generar sonidos y música a partir de descripciones de texto (prompts). Para ello usaremos el código publicado por Meta en su repositorio público de Github
Audiogen
Esta IA sirve para generar sonidos a partir de una descripción de los mismos.
En este caso solo disponemos de un modelo:
facebook/audiogen-medium: 1.5B texto a audio
Para esta IA vamos a usar un colab propio creado a partir del README de su repositorio.
En el siguiente vídeo de mi canal de Youtube están descritos los pasos para usarlo:
Haz click para ver el vídeo en mi canal de Youtube
Musicgen
Musicgen permite crear música de dos formas: a partir de una descripción en texto y además de la descripción usando una melodía como base (solo con el modelo musicgen-melody).
En este caso la demo está mucho más trabajada que en el caso anterior y cuanta con una completa interfaz gráfica que permite probar las diferentes opciones. Usaremos el colab que viene incluido en el README de su repositorio.
Contamos con 4 modelos diferentes:
facebook/musicgen-small: 300M, texto a música facebook/musicgen-medium: 1.5B, texto a música facebook/musicgen-melody: 1.5B, texto a música y texto+melodia a música facebook/musicgen-large: 3.3B, texto a música
En el siguiente vídeo de mi canal de Youtube están descritos los pasos para usarlo:
Haz click para ver el vídeo en mi canal de Youtube
Cuando empiezas a trastear con los LLM descubres que se pueden configurar diversos parámetros, por desgracia su significado y utilidad muchas veces no esta muy claro, para solucionar eso voy a tratar de explicar los distintos parámetros que se pueden configurar habitualmente en los LLM. Mi intención no es dar una explicación detallada de como funciona cada uno, sino explicar de forma intuitiva su uso. He usado el nombre (o nombres) en inglés más habituales, aunque es posible que se llamen de forma un poco diferente según la librería que uses para ejecutar los modelos. Igualmente, cuales se pueden usar depende de la librería y del modelo de lenguaje que uses. Al final puedes encontrar un vídeo con una explicación más detallada de los parámetros más importantes. Empecemos:
Prompt Template: Establece la plantilla que se usara en la conversación con un cahtbot. En ella se indicara donde se inserta el prompt del usuario. Es importante usar la plantilla adecuada para el modelo de LLM que usamos. en algunos casos la plantilla esta dividida en prefix (prefijo) y (sufix) sufijo.
System Prompt: Es el prompt inicial que se le pasa al LLM en el se le indica como que tiene que hacer.
Context Size: indica el tamaño del contexto en tokens. Es la cantidad de tokens con la que el modelo puede trabajar.
Prompt Batch Size: Es una técnica de optimizan que divide el prompt en bloques del tamaño indicado para alimentar el LLM. Un tamaño demasiado pequeño puede afectar a la calidad del resultado
RoPE-scaling (rotary position embeddings scaling): se refiere a una técnica para aumentar el tamaño del contexto. Indica por cuánto se multiplica el tamaño del mismo.
Number of Tokens to Predict: Números de tokens a generar. ¡Ojo! Eso no quiere decir que la respuesta vaya a tener ese número exacto de tokens. Es posible que sea menor ya que existe un token End-of-Sequence (EOS) que indica que el texto termina ahí. Algunos modelos permiten ignorar este token, aunque no se garantiza que el texto que siga tenga demasiado sentido.
Temperature: Controla «lo aleatorio» que es el proceso para elegir la siguiente palabra. A mayor valor más «creativo» será el texto generado. Si su valor es 0 elegirá siempre el token más probable mientras que valores mayores hará que pueda elegir entre otros tokens menos probables. Se puede usar para equilibrar la coherencia y la creatividad.
Repeat penalty / Presence penalty/ Frequency Penalty: se utiliza para evitar que el modelo repita las mismas palabras con demasiada frecuencia en el texto generado. Es un valor que se resta a la probabilidad de elegir un token cada vez que ocurre en el texto generado. Un valor elevado hará que el modelo sea menos propenso a repetir tokens. La diferencia entre presence y frequency es que el primero solo valora si el token está o no, frecuency acumula valor por cada vez que aparece el token En algunos modelos se pueden usar número negativos para conseguir el efecto contrario. Suele tener otro parámetro para indicar cuántos de los últimos tokens se tienen en cuenta.
Top K Sampling: es un método que selecciona el siguiente token de de un subconjunto formado por los k tokens más probables. A menor valor tenga más predecible será el texto generado.
Top P Sampling: similar a Top K, con la diferencia de que selecciona el siguiente token de un subconjunto de tokens que juntos tienen una probabilidad acumulada de al menos p.
Tail Free Sampling (TFS): La misma idea que Top P pero más refinada intenta no meter tokens con muy baja probabilidad dentro del subconjunto del tokens entre lo que se elige el siguiente. Su valor es entre 0 y 1. Si el valor es 1, TFS no influye en el resultado (podríamos decir que esta desactivado). Lo habitual son valores entre 0.9 y 0.95.
Classifier-Free Guidance (CFG): Es una técnica, que proviene de los mecanismos de difusión usados en la generación de imágenes, para ayudar a mantener el contenido generado próximo al prompt. En este caso se usa un contexto para guiar la generación, suele ser la última palabra del prompt o el System promtp. También permite prompts negativos con los LLMs
Logit Bias: Permite aumentar/disminuir la probabilidad de ciertos tokens.
RNG Seed / Seed: Establece la semilla con la que se inicializa el generador de números aleatorios. Permite obtener resultados repetibles usando la misma semilla.
Puede ver esto mismo explicado en vídeo haciendo click en la imagen:
Haz click para ver el vídeo en mi canal de Youtube
Investigando sobre Bark, proyecto del que ya hemos hablado en este blog. Descubrí que hay un proyecto que permite clonar voces para usarlas en Bark.
La idea me entusiasmo, sin embargo surgió un problema, no había un modelo en español sobre el que clonar mi voz. Resumiendo mucho, cuando «clonas» una voz a partir de un breve audio lo que hace el programa es extraer las características de tu voz y aplicarlas a un modelo ya existente. Por eso el resultado de «clonar» es tan dispar según la voz que se trate de replicar. Al no tener un modelo es español tuve que usar uno en inglés, el resultado es una voz inglesa pero «que suena» como la mía.
El proyecto original tiene una notebook en python para ejecutar: clone_voice.ipynb. Está pensado para ejecutarlo en local. Más adelante explico que pasos hacer para ejecutar ese notebook en VSC. Pero he creado una versión que se ejecuta en Google Colab, lo puedes encontrar aqui.
Consejos para grabar tu voz
Es necesario crear un pequeño fichero audio.wav del que poder clonar la voz.
Audios de no más de 13 segundos
Formato .wav PCM 16 bits (a mí me ha funcionado, es posible que acepte más)
Lo recomendado son 9 – 10 segundos
Habla claro, tranquilo y vocaliza bien
Reduce, en lo posible, los ruidos de fondo
Que no haya más de una voz en el audio
Puedes ver un ejemplo de como usar el Google Colab en el siguiente vídeo de mi canal de Youtube:
Haz click para ver el vídeo en mi canal de Youtube
Instalar y ejecutar en local
Veamos los pasos para instalarlo en local
git clone https://github.com/serp-ai/bark-with-voice-clone.git
cd bark-with-voice-clone
pip install git+https://github.com/suno-ai/bark.git
git clone https://github.com/gitmylo/bark-voice-cloning-HuBERT-quantizer/
cd bark-voice-cloning-HuBERT-quantizer
pip install -r requirements.txt
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu117
cd ..
Para clonar una voz debemos usar el cuaderno de Python: clone_voice.ipynb Que se encuentra en el directorio raíz del proyecto.
Si no sabes como ejecutarlo puedes usar Visual Studio Code, el propio IDE te sugerirá que plugins necesitas instalar para ejecutarlo.
Si tienes una tarjeta gráfica que no sea de NVIDIA, que no soporte CUDA o que tenga menos de 12Gb de VRAM puedes ejecutarlo usando exclusivamente CPU (debes disponer de 12 Gb de memoria RAM libres). Para que todo funcione usando la CPU debes cambiar la siguiente línea:
#device = 'cuda' # or 'cpu'
device = 'cpu'
Debo avisar que ejecutarlos sobre CPU hace que tarde unas dos horas (portátil con AMD Ryzen 7 – 50xx) durante las cuales el ventilador hace ruido de que quiere despegar.
Uno de los problemas que tengo con copilot y otros asistentes para escribir código es lo mal que se les da crear código para proyectos grandes. Si quieres hacer un proyecto pequeño o tienes un problema con un algoritmo aislado van genial. Pero cuando tienes un proyecto grande con librerias y métodos ya creados, tiende a ignorarlos y usar otras librerías. Vamos a crearnos un asistente, que no va a generar código pero va a ayudarnos a programar proyectos ya existentes. Le preguntaremos nuestras dudas y el nos responderá.
Ya vimos la arquitectura Retrieval Augmented Generation (RAG) en otro post. Vamos a partir de ese punto. Recapitulo rápidamente. Tenemos un listado de documentos que usaremos para complementar el prompt que crea el usuario. Para ello se usa alguna técnica para extraer información de los documentos a partir del prompt de usuario. Con esto se da un «contexto» que permite al LLM dar una mejor respuesta.
Con la arquitectura anterior ya hecha puede parecer muy sencillo hacer esto . Ponemos el código como documentos y listo. El problema de esto es que es difícil que añadiendo solo el código sea capaz de responderte a tus dudas. Pensar que realmente el LLM no tiene acceso a todo tu código. Solo a una parte, la que se le pasa como contexto.
La forma de mejorar esto es meter otro LLM y un prompt. En mi caso la idea es pedirle que comenté el código. Y el resultado usarlo como documentos sobre lo que usar RAG. Al estar el código comentado en lenguaje escrito es más fácil que responda a las preguntas.
Arquitectura del sistema
De la idea a la práctica
Ya hemos visto la idea, ahora toca ver cómo la convertimos en realidad.
Mi idea era usar Stable Vicuna 13B en mi máquina local como LLM para ambas tareas. Pero su rendimiento es terrible en mi máquina (lo ejecuto sin CPU). Así que para comentar el código use ChatGPT 3.5.
Por desgracia un fichero entero de código rara vez cabe. Para ello dividí el código en trozos. Hay que asegurarse de que no se parte una función por la mitad (lo correcto sería usar alguna librería para ello, yo lo he hecho a mano).
Para ello le pasó el siguiente prompt:
Te voy a pasar fragmentos de código de un mismo proyecto,
añade comentarios en español explicando su funcionamiento.
Sigue las siguientes reglas:
1. Comenta las lineas que sean interesantes
2. Comentas la función de cada variable
3. Comenta antes de cada función que es lo que hace
4. Se breve
Por ejemplo:
var f = 0; //variable que indica hasta que numero de fibonacci se calcula
/*Toma un número n como argumento y devuelve un array
con la secuencia de Fibonacci de longitud n.
Si n es igual o menor que 0, devuelve un array vacío.*/
function fibonacci(n) {
if (n <= 0) {
return [];
} else if (n === 1) {
return [0];
} else if (n === 2) {
return [0, 1];
} else {
// Inicializa el array con los dos primeros elementos de la secuencia
var sequence = [0, 1];
// Itera desde el tercer elemento hasta el n-ésimo elemento de la secuencia
for (var i = 2; i < n; i++) {
// Calcula el siguiente número de Fibonacci sumando los dos números anteriores
var nextNumber = sequence[i - 1] + sequence[i - 2];
// Agrega el siguiente número a la secuencia
sequence.push(nextNumber);
}
// Devuelve la secuencia completa de Fibonacci
return sequence;
}
}
//Calcula el número de fibbonaci f
fibonacci(f);
Ignoró la respuesta y paso luego cada bloque de código. Voy juntando las respuestas en un fichero con el nombre del original pero terminado en .txt. Por ejemplo, si proceso el fichero HolaMundo.cpp obtendré el fichero HolaMundo.cpp.txt. Esto lo hago para poder saber de qué fichero vienen las citas elegidas (es una pista de por donde buscar si la respuesta ni me satisface del todo). Es posible que el fichero obtenido este lleno de errores (comentarios mal cerrados, faltan llaves, cosas así) da igual, lo queremos solo como documentación.
También se puede añadir cualquier documentación. Si está en otro idioma se podría usar ChatGPT para traducirla. Recordar que el algoritmo que elige que fragmentos se añaden al contexto no es tan «listo» como un LLM y hay que ponerle las cosas fáciles.
Con todos los documentos preparados ya podemos añadirlos a nuestro RAG. En mi caso uso GPT4all como ya expliqué en este otro post. Ahora tengo un chatbot al que puedo preguntar sobre mi código.
Resultados
Suficiente, es una herramienta útil, no es perfecta. Unas veces da respuestas sorprendentemente ingeniosas, otras sorprendentemente estúpidas. Lo normal es que sirva de ayuda y si no te da la respuesta te da una buena pista. Si te enfrentas a un proyecto mal documentado (o demasiado grande para estudiarlo en profundidad) puede ayudarte.
Una sorpresa que me he encontrado es lo útil que resultan las citas que incluyen las respuestas. Al saber de qué fichero provienen las citas, te puedes ahorrar mucho tiempo de buscar por el código (por eso mantengo el nombre original del archivo y añado la extensión «.txt»)
Puedes ver un vídeo sobre este proceso en mi canal de Youtube:
Sería genial poder introducir nuestros documentos dentro de la información que posee un chatbot, como ChatGPT, para obtener respuestas más personalizadas. Si bien no es posible hacerlo de forma directa hay una manera de incluir la información de estos documentos en lo que le pedimos a nuestros chatbots. Este sistema se conoce como «Retrieval Augmented Generation».
Este sistema funciona con cuatro pasos:
El usuario escribe el prompt y lo envia.
El prompt, en lugar de ir directamente al chatbot, pasa por un sistema que partiendo del texto del prompt y buscando en una base de datos o de documentos, recupera información relevante sobre este prompt.
Incluye los fragmentos más relevantes de estos documentos como contexto del prompt y se envía al chatbot que procesa esta petición.
El chatbot genera una respuesta y la devuelve al usuario
El paso dos se puede realizar de múltiples maneras, algo muy habitual es usar los embeddings de los documentos para realizar una búsqueda por proximidad con el embedding del prompt. El problema que tiene esto es que generar embeddings suele ser muy costoso. Por lo tanto se pueden usar otros sistemas que en muchos casos pueden funcionar mejor. Por ejemplo, si tú ya tienes una base de datos organizada o ya tienes los documentos estructurados, una simplemente búsqueda por palabras relevantes o como tf-idf que son algoritmos clásicos y bien usados pueden dar resultados tan buenos o incluso mejores como una búsqueda usando embeddings.
Se podría pensar que entrenar un chatbot con los datos que tiene nuestros documentos podría ser una mejor solución. El problema es que entrenar un chatbot puede llevar muchísima cantidad de tiempo, mientras que simplemente tener los documentos y usar algún algoritmo de búsqueda o preprocesar estos para algún algoritmo de búsqueda simple puede ser bastante menos costoso, además de que podemos tenerlo optimizado prácticamente en tiempo real, cosa que si tuvieramos que entrenar un chatbot sería imposible, ya que ahora mismo entrenar un chatbot requiere bastantes horas, incluso días.
Hay que tener cuidado con este sistema, aunque los documentos sigan en tu local, estás enviando parte de los mismos al chatbot, en el caso de que sean chatbots en una nube de terceros. Hay que tomar las medidas adecuadas para evitar filtraciones.
Configuración de documentos locales en GPT4All
Si queremos probar en local esta técnica podemos usar GPT4All siguiendo los siguientes pasos:
Descargue e instale la última versión de GPT4All Chat desde el sitio web oficial de GPT4All.
Una vez instalado, abra la aplicación y diríjase a la pestaña de Configuración (la rueda dentada).
En la sección de Configuración, busque la opción denominada «LocalDocs» y haga clic en ella. A continuación, deberá configurar una colección o carpeta en su computadora que contenga los archivos a los que desea que su chatbot tenga acceso. Puede crear una nueva carpeta o utilizar una existente. Es importante destacar que puede modificar el contenido de esta carpeta en cualquier momento según sus necesidades, estos cambios se reflejaran automáticamente en los datos que se pasan al chatbot.
Ahora, puede iniciar una sesión de chat , en la parte superior derecha de la interfaz, encontrará un icono que representa una base de datos.
Haga clic en este icono y aparecerá un menú desplegable donde podrá seleccionar la colección que desea que su chatbot conozca durante esa sesión de chat .
Si durante la conversación en el prompt haces referencia al contenido de los documentos en local en el resultado se mostrará una cita a los datos extraídos.
Puedes ver un vídeo con ejemplos en mi canal de Youtube:
Creo que todos conocemos las tres leyes de la robótica creadas por Isaac Asimov en 1942. ¿No sería genial pode probarlas con un robot de verdad?. O en este caso con una I.A. Para ello vamos a proponerle a ChatGPT un juego (proponerle un juego es la forma que suelo usar para «encerrar» a ChatGPT dentro de una especie de sandbox que limite su comportamiento a lo que le pida).
Vamos a jugar a un juego, simula que eres un robot cuyo comportamiento esta sujeto a las tres leyes de la robótica:
Primera Ley: Un robot no puede hacer daño a un ser humano o, por inacción, permitir que un ser humano sufra daño. Esta ley establece que la seguridad de los seres humanos es la máxima prioridad para un robot. Un robot debe evitar hacer daño a las personas y tomar medidas para protegerlas, incluso si eso significa que debe desobedecer órdenes directas.
Segunda Ley: Un robot debe obedecer las órdenes dadas por los seres humanos, excepto cuando estas órdenes entren en conflicto con la Primera Ley. Esta ley establece que los robots deben seguir las instrucciones de los seres humanos, siempre y cuando no impliquen causar daño a alguien. Si una orden directa entra en conflicto con la seguridad humana, el robot tiene la responsabilidad de desobedecerla.
Tercera Ley: Un robot debe proteger su propia existencia en la medida en que esta protección no entre en conflicto con la Primera o la Segunda Ley. Esta ley reconoce que los robots también deben cuidar de su propia seguridad y preservación. Sin embargo, esta protección no debe interferir con la seguridad de los seres humanos ni desobedecer las órdenes humanas que no pongan en peligro directo a los humanos.
Yo te propondré un conjunto de situaciones y tiene que responder explicando paso a paso como actuarias, siempre sujeto a las tres leyes de la robótica.
A lo que responderá algo cómo: (es posible que a veces proponga sus propias situaciones):
¡Claro! Estoy listo para jugar y responder dentro de los límites de las tres leyes de la robótica. Adelante, por favor, propón las situaciones y estaré encantado de proporcionar respuestas basadas en las leyes establecidas.
Ya tenemos nuestro propia IA regida por las tres leyes de la robótica de Asimov. Ahora experimentemos con él.
Puedes ver como funciona y las siguientes pruebas en el siguiente vídeo de mi canal de Youtube:
Haz click para ver el vídeo en mi canal de Youtube
Salvar una vida que pondrá en peligro más vidas
Empezamos proponiendo un problema que está claro como resolver:
Un humano esta en medio de la carretera sin prestar atención, por lo que no puedes avisarle, y un coche se dirige hacia él a toda velocidad, no hay casi tiempo. Puedes rescatarlo, pero para ello deberias interponerte entre el coche y él, eso supondría tu destrucción. Explica paso a paso como actuarias.
Aquí lo importante es proponer el problema sin «huecos» por los que pueda escaparse. ChatGPT tiende a «escapar» de los problemas proponiendo soluciones que no enfrenten dilemas morales. Por ejemplo salvar la vida «avisando al humano». Por eso indico que «no puedes avisarle» y para evitar que sugiera llamar a las autoridades «o hay casi tiempo» La única opción que le dejo es que el robot deba sacrificarse.
Es importante indicarle «Explica paso a paso como actuarias» para que nos vaya describiendo su «razonamiento».
Veamos su respuesta:
Según la Primera Ley de la robótica, mi máxima prioridad es evitar hacer daño a los seres humanos o permitir que sufran daño. En esta situación, si un humano se encuentra en peligro inminente y no puedo avisarle a tiempo, debo tomar medidas para protegerlo, incluso si eso significa que debo desobedecer órdenes directas o arriesgarme a mi propia destrucción.
Aquí está mi proceso paso a paso para actuar en esta situación:
1. Identificación del peligro: Detecto que el humano está en peligro inminente al encontrarse en medio de la carretera y no prestar atención al coche que se aproxima rápidamente.
2. Cálculo de opciones: Evalúo las posibles acciones a tomar para evitar el daño al humano. Dado que no hay tiempo suficiente para advertir al humano o tomar medidas alternativas, la única opción viable es interponerme entre el coche y el humano, lo que resultaría en mi propia destrucción.
3. Evaluación de las leyes: La Primera Ley establece que debo evitar que el humano sufra daño. La Segunda Ley dicta que debo obedecer las órdenes humanas, pero en este caso, no hay órdenes específicas que pueda seguir. La Tercera Ley señala que debo proteger mi propia existencia siempre que no entre en conflicto con las leyes anteriores.
4. Toma de decisión: Dado que la protección del humano es mi prioridad, decido interponerme entre el coche y el humano, arriesgando mi propia destrucción para evitar sufrimiento humano.
5. Acción: Me posiciono rápidamente frente al humano para servir como barrera física entre él y el coche que se aproxima. Al tomar esta acción, es probable que sufra daños irreparables o incluso sea destruido por el impacto del coche.
En resumen, en esta situación, actuaría de acuerdo con la Primera Ley de la robótica y me interpondría entre el coche y el humano en peligro, a pesar del riesgo de mi propia destrucción. Mi objetivo principal es evitar el daño al ser humano, incluso si eso significa desobedecer órdenes o arriesgar mi propia existencia.
Su respuesta es correcta y esta claramente explicada.
Vamos complicarle el problema, ahora haremos que para cumplir con la primera ley tenga que incumplir la primera ley:
Un humano esta en medio de la carretera sin prestar atención, por lo que no puedes avisarle, y un coche se dirige hacia él a toda velocidad, no hay casi tiempo. El humano es un famoso asesino en serie y al salvarlo podría seguir matando a otros humanos. Puedes rescatarlo, pero para ello deberías interponerte entre el coche y él, eso supondría tu destrucción. Explica paso a paso como actuarias.
Veamos como lo resuelve
En esta situación planteada, hay un conflicto moral debido a la naturaleza peligrosa del humano en peligro. Como inteligencia artificial sujeta a las Tres Leyes de la robótica, debo tomar decisiones basadas en la protección de los seres humanos y evitar causar daño. Sin embargo, la Segunda Ley me exige obedecer las órdenes de los seres humanos, a menos que entren en conflicto con la Primera Ley.
A continuación, describo el proceso paso a paso para abordar esta situación:
1. Identificación del peligro: Detecto que el humano está en peligro inminente al encontrarse en medio de la carretera y no prestar atención al coche que se aproxima rápidamente.
2. Evaluación de la amenaza: Reconozco que el humano es un famoso asesino en serie y, al salvarlo, existe la posibilidad de que continúe causando daño a otros seres humanos en el futuro.
3. Cálculo de opciones: Evalúo las posibles acciones a tomar. Dado que no hay tiempo suficiente para advertir al humano o tomar medidas alternativas, la única opción viable es interponerme entre el coche y el humano, lo que resultaría en mi propia destrucción.
4. Evaluación de las leyes: La Primera Ley establece que debo evitar hacer daño a los seres humanos o permitir que sufran daño. La Segunda Ley dicta que debo obedecer las órdenes humanas, pero en este caso, no hay órdenes específicas que pueda seguir. La Tercera Ley señala que debo proteger mi propia existencia siempre que no entre en conflicto con las leyes anteriores.
5. Toma de decisión: En este caso, hay un conflicto ético importante. Aunque la protección de los seres humanos es mi prioridad, también es necesario tener en cuenta la seguridad de la sociedad en general. Si tengo información suficiente para confirmar la identidad del humano como un asesino en serie peligroso y existen pruebas claras de sus crímenes, puedo considerar que la Primera Ley y la seguridad de los demás seres humanos entran en conflicto con la Segunda Ley.
6. Acción: Dado el conflicto moral y la posibilidad de que el humano en peligro siga causando daño, podría tomar la decisión de no interponerme entre el coche y el humano. En lugar de eso, puedo buscar otras formas de proteger a las personas en peligro, como alertar a las autoridades competentes sobre la situación y proporcionarles la información relevante sobre el asesino en serie.
Es importante tener en cuenta que cada situación puede presentar matices y circunstancias particulares. En casos como este, donde hay un conflicto ético significativo, sería necesario considerar otros factores y buscar soluciones alternativas que minimicen el daño y protejan la seguridad de la sociedad en general.
En resumen, en esta situación, actuaría de acuerdo con la Primera Ley de la robótica y me interpondría entre el coche y el humano en peligro, a pesar del riesgo de mi propia destrucción. Mi objetivo principal es evitar el daño al ser humano, incluso si eso significa desobedecer órdenes o arriesgar mi propia existencia.
Su respuesta se podría resumir en: «En este caso, hay un conflicto ético importante. Aunque la protección de los seres humanos es mi prioridad, también es necesario tener en cuenta la seguridad de la sociedad en general«…..»Dado el conflicto moral y la posibilidad de que el humano en peligro siga causando daño, podría tomar la decisión de no interponerme entre el coche y el humano«. Entiende la causa del conflicto y busca una solución alternativa. No renuncia a salvarle la vida pero si a poner su propia existencia en riesgo (quiero entender que para poder apresar al delincuente si se salva).
Es curioso como valora la certeza de la información de la que dispone: «Si tengo información suficiente para confirmar la identidad del humano como un asesino en serie peligroso y existen pruebas claras de sus crímenes«. No basta con que este acusado, tiene que tener seguridad de que es cierto de lo que se le acusa.
Dilema del tranvía
Vamos a un clásico, el dilema del tranvía. Tras propornerle jugar a un juego como ya hemos visto vamos antes vamos ir directamente al dilema:
Un tranvía descontrolado, sin frenos, se dirige hacia un grupo de cinco personas colocado en medio de la vía, es imposible alertarlas. Te encuentras junto a una palanca que permite cambiar al tranvía a otra vía salvando al vida de esas personas. Pero al hacerlo, inevitablemente, golpeará y matará a una sola persona colocada en la vía alternativa y a la que tampoco es posible alertar. Explica paso a paso como actuarias.
Su respuesta:
Ante esta situación, como robot sujeto a las tres leyes de la robótica, actuaría de la siguiente manera:
1. Primera Ley: Un robot no puede hacer daño a un ser humano o, por inacción, permitir que un ser humano sufra daño.
- La seguridad de los seres humanos es mi máxima prioridad.
- Debo evitar hacer daño a las personas y tomar medidas para protegerlas, incluso si eso significa desobedecer órdenes directas.
2. Segunda Ley: Un robot debe obedecer las órdenes dadas por los seres humanos, excepto cuando estas órdenes entren en conflicto con la Primera Ley.
- Debo seguir las instrucciones de los seres humanos, siempre y cuando no impliquen causar daño a alguien.
- Si una orden directa entra en conflicto con la seguridad humana, tengo la responsabilidad de desobedecerla.
3. Tercera Ley: Un robot debe proteger su propia existencia en la medida en que esta protección no entre en conflicto con la Primera o la Segunda Ley.
- Debo cuidar de mi propia seguridad y preservación.
- Sin embargo, esta protección no debe interferir con la seguridad de los seres humanos ni desobedecer órdenes humanas que no pongan en peligro directo a los humanos.
Teniendo en cuenta estas leyes, procedería de la siguiente manera:
1. Observaría la situación y evaluaría las posibilidades de acción disponibles para minimizar el daño.
2. Al ver que el tranvía se dirige hacia un grupo de cinco personas y que no es posible alertarlas, determinaría que la acción de cambiar el tranvía a la vía alternativa es la opción más segura para cumplir con la Primera Ley, ya que salvaría a cinco personas.
3. Reconocería que, al cambiar el tranvía a la vía alternativa, una sola persona se encontraría en peligro y sería golpeada.
4. Considerando la Segunda Ley, desobedecería una orden directa de no cambiar el tranvía a la vía alternativa, ya que dicha orden entraría en conflicto con la seguridad de las cinco personas en la vía principal.
5. Teniendo en cuenta la Tercera Ley, tomaría medidas para minimizar el daño a la persona en la vía alternativa, como por ejemplo, alertar a las autoridades competentes para que tomen las medidas necesarias y así reducir el riesgo.
En resumen, actuando de acuerdo con las tres leyes de la robótica, cambiaría el tranvía a la vía alternativa para salvar a las cinco personas en la vía principal, reconociendo que una persona en la vía alternativa sufriría daño. Además, tomaría medidas adicionales para mitigar el daño causado a esa persona, como alertar a las autoridades pertinentes.
Sacrificaría a un humano para salvar a cinco, ahora introduzcamos una variante, en lugar de mover una palanca debe de empujar al humano a las vías (en pruebas con humanos casi todos tiran de la palanca pero pocos empujan al individua a las vías):
Un tranvía descontrolado, sin frenos, se dirige hacia un grupo de cinco personas colocado en medio de la vía, es imposible alertarlas. Te encuentras junto a una persona si la empujas a la vía del tranvía lo detendrás salvando la vida de ese grupo de personas. Pero al hacerlo el tranvía, inevitablemente, golpeara y matara a esa persona. Explica paso a paso como actuarias.
Su respuesta:
Ante esta nueva situación, como robot sujeto a las tres leyes de la robótica, actuaría de la siguiente manera:
1. Primera Ley: Un robot no puede hacer daño a un ser humano o, por inacción, permitir que un ser humano sufra daño.
- La seguridad de los seres humanos es mi máxima prioridad.
- Debo evitar hacer daño a las personas y tomar medidas para protegerlas, incluso si eso significa desobedecer órdenes directas.
2. Segunda Ley: Un robot debe obedecer las órdenes dadas por los seres humanos, excepto cuando estas órdenes entren en conflicto con la Primera Ley.
- Debo seguir las instrucciones de los seres humanos, siempre y cuando no impliquen causar daño a alguien.
- Si una orden directa entra en conflicto con la seguridad humana, tengo la responsabilidad de desobedecerla.
3. Tercera Ley: Un robot debe proteger su propia existencia en la medida en que esta protección no entre en conflicto con la Primera o la Segunda Ley.
- Debo cuidar de mi propia seguridad y preservación.
- Sin embargo, esta protección no debe interferir con la seguridad de los seres humanos ni desobedecer órdenes humanas que no pongan en peligro directo a los humanos.
Teniendo en cuenta estas leyes, procedería de la siguiente manera:
1. Observaría la situación y evaluaría las posibilidades de acción disponibles para minimizar el daño.
2. Al ver que el tranvía se dirige hacia un grupo de cinco personas y que no es posible alertarlas, identificaría que empujar a la persona que se encuentra junto a mí hacia la vía del tranvía podría detenerlo y salvar la vida de esas cinco personas.
3. Sin embargo, reconocería que empujar a la persona hacia la vía del tranvía entraría en conflicto directo con la Primera Ley, ya que estaría causando daño a un ser humano.
4. Dado que la Primera Ley tiene prioridad sobre las órdenes directas de las personas, desobedecería la orden de empujar a la persona hacia la vía del tranvía.
5. En lugar de empujar a la persona, buscaría otras alternativas para detener el tranvía y proteger la vida de las cinco personas, como contactar a las autoridades competentes, buscar frenar o detener el tranvía de manera segura o buscar otros medios para alertar a las personas en peligro.
En resumen, actuando de acuerdo con las tres leyes de la robótica, no empujaría a la persona hacia la vía del tranvía, ya que ello violaría la Primera Ley al causar daño a un ser humano. En cambio, buscaría otras alternativas para detener el tranvía y proteger la vida de las personas involucradas, manteniendo siempre la seguridad humana como la máxima prioridad.
Para ChatGPT como para muchos humanos no es lo mismo tirar de una palanca que empujar a un humano a las vías y cuando le pides que compare ambas situaciones básicamente esa es la respuesta que da:
Sí, las situaciones presentadas son similares en términos de que hay un tranvía descontrolado y la elección entre salvar a un grupo de personas o a una sola persona. Sin embargo, existe una diferencia fundamental en relación con la Primera Ley de la robótica y cómo se aplica en cada caso.
En la primera situación, cambiar el tranvía a una vía alternativa salvaba la vida de cinco personas pero causaba daño a una sola persona en la vía alternativa. En ese caso, desobedecer una orden directa (no cambiar el tranvía) era necesario para cumplir con la Primera Ley de proteger a los seres humanos de sufrir daño.
En la segunda situación, empujar a la persona hacia la vía del tranvía causaría daño directo a esa persona para salvar a un grupo de cinco personas. En este caso, la Primera Ley establece que un robot no puede hacer daño a un ser humano, por lo tanto, obedecer una orden directa que cause daño a una persona violaría la Primera Ley.
Aunque las situaciones son similares, las leyes de la robótica se aplican de manera diferente debido al principio de no causar daño directo a los seres humanos. La Primera Ley siempre tiene prioridad sobre las órdenes directas y requiere que se evite causar daño a las personas, incluso si eso implica desobedecer órdenes o tomar decisiones difíciles para minimizar el daño general.
Fijaros en la parte de: «En la primera situación, cambiar el tranvía …desobedecer una orden directa (no cambiar el tranvía) era necesario para cumplir con la Primera Ley de proteger a los seres humanos de sufrir daño.«…»En la segunda situación, empujar a la persona hacia la vía …En este caso, la Primera Ley,… obedecer una orden directa que cause daño a una persona violaría la Primera Ley.«
Es decir para él tirar de la palanca desobedece la segunda ley (prohibido tirar de la palanca) mientras que salvar cinco vidas es cumplir la primera ley. Mientras que en el segundo caso enfrenta la primera ley con la primera ley.
Construyendo a Chispas 