Etiqueta: llm

Primeros pasos con OpenWebUI Pipelines

Pipelines es la nueva creación del equipo de Open WebUI, encabezado por @timothyjbaek (https://github.com/tjbck) y @justinh-rahb (https://github.com/justinh-rahb)

Pipelines se define como a UI-Agnostic OpenAI API Plugin Framework. En resumidas cuentas permite inyectar plugins que interceptan el prompt del usuario antes de enviarlo al LLM final, lo procesan y se lo envían, ya procesado, al LLM. ¿Y para qué puede servir esto? Por ejemplo para ejecutar funciones en base a lo que requiera un prompt antes de enviarlo al LLM (ejemplo sencillo: ¿qué hora es? ¿qué tiempo hace ahora en Donostia?…), para consultar bases de datos externas e inyectar las respuestas como contexto del prompt (RAG), para ejecutar código…

Pipelines es agnóstico del cliente UI, basta con que éste cliente soporte el API de OpenAI. Al ser una creación del equipo de OpenWebUI el primer UI que soporta Pipelines es, por supuest, OpenWebUI. 

Hay dos tipos de pipelines: filtros y pipes. 

Filtros: da igual el modelo que elijas (aunque se puede determinar para qué modelos quieres aplicarlo, por defecto es para todos), el prompt del usuario – Form Data – pasará por el filtro (entrando por una función de inlet), si es necesario se procesará y saldrá por el filtro ya procesado (outlet). Podría ser que no fuera necesario ser procesado, en tal caso, el modelo responderá como siempre.

Pipes: el usuario debe elegir el pipe que quiere aplicar a su prompt – Form Data. Este pasará por el pipe y será devuelto como respuesta (contexto) que luego podrá ser usado para otras preguntas. Por ejemplo, podemos seleccionar Wikipedia como un pipe, pedirle que inyecte los primeros párrafos de una entrada de wikipedia en el contexto y luego seguir preguntando.

Veamos cómo ponerlo en marcha Pipelines con OpenWebUI 0.2.2.

Probando Pipelines

Asumiré que ya tienes OpenWebUI 0.2.2 lanzado y lo único que necesitas es saber cómo lanzar y usar Pipelines. Lo más sencillo será hacerlo vía Docker. Lanzamos Pipelines así:

$ docker run -p 9099:9099 --add-host=host.docker.internal:host-gateway -v pipelines:/app/pipelines --name pipelines --restart always ghcr.io/open-webui/pipelines:main

Podemos ver los logs que nos vaya dejando con este comando:

$ docker logs -f pipelines

Uniendo OpenWebUI con Pipelines

Desde Settings, creamos y guardamos una nueva conexión tipo OpenAI API, con estos datos:

URL: http://TU_DIRECCION_IP:9099 (el docker anterior se ha lanzado aquí). Pass: 0p3n-w3bu!

Cómo añadir un Function Calling Pipeline

Ahora, desde Admin Settings / Pipelines, añadiremos nuestro primer filtro: Function Calling.Lo haremos indicando que Pipelines está a la escucha en http://localhost:9099 (donde lo hemos configurado antes) y que queremos instalar el siguiente filtro de Function Calling desde GitHub: https://github.com/open-webui/pipelines/blob/main/examples/function_calling/function_calling_filter_pipeline.py

Podemos especificar a qué modelos afecta el pipeline (por defecto, a todos *), la prioridad (es posible encadenar pipes, el que tenga un número menor será el más prioritario) y en este caso, también el OpenAI API Base URL, su key y el modelo. Por ejemplo, GPT-3.5-Turbo. Este LLM será usado para decidir si el prompt del usuario necesita ser respondido a través de una función o no, y en caso afirmativo, el modelo decidirá qué función usar (algo com function calling, pero a través de prompts-respuestas con GPT-3.5 normales, internamente he visto que no usa function calling).

En el template se puede especificar el prompt que recibirá GPT 3.5-Turbo para decidir si es necesario ejecutar una función (y cuál) o deja pasar el prompt sin necesidad de ejecutar ninguna función (en cuyo caso respondería con el nombre de función vacío)

El último parámetro, OpenWeatherMap API Key servirá para responder (si es necesario) al prompt del usuario que esté solicitando conocer el tiempo que hace en una localidad.

Vamos a probarlo. Elegimos un modelo en OpenWebUI (en mi caso, mistral:latest) y preguntamos por la hora actual (lo hice ayer a la noche 🙂

¡Funciona!

En el mismo filtro de Function Calling tenemos también definidas otras dos tools, Weather y Calculator. Probemos la de weather…

Perfecto 🙂

Añadiendo un Pipe: Wikipedia Pipe

Tal y como hemos comentado, también se pueden usar Pipes en lugar de Filters. Un ejemplo sería el uso de Wikipedia.

Igual que antes, desde los settings de Admin, añadimos este pipeline: https://github.com/open-webui/pipelines/blob/main/examples/pipelines/integrations/wikipedia_pipeline.py

Veremos ahora que tenemos un nuevo modelo disponible en OpenWebUI:

Vamos a probarlo. Seleccionamos el modelo Wikipedia Pipeline y buscamos ‘Mistral AI’:

¡Funciona!

Y una última prueba con todo a la vez:

He elegido mistral como modelo, y he preguntado por la hora («What time is it»). El pipeline de function calling ha determinado que es algo que se puede responder ejecutando la función de obtener la hora del sistema y me ha devuleto la hora actual.

Después he pedido el tiempo en Donostia y me ha dicho la temperatura. Finalmente he seleccionado el  Pipe de Wikipedia y he preguntado por Mistral. Ahí he visto que no he sido lo suficientemente explícito (Mistral puede ser varias cosas…)

En un segundo intento, he solicitado información sobre Mistral AI. En esta ocasión he encontrado la información que quería, como hemos visto antes.

¿Hará desaparecer al programador la IA generativa?

Los sistemas LLM son mejor aprovechados cuantos más conocimientos de ingeniería software en general y de programación en particular tengas.

¿Cómo preguntas al LLM que te ayude a generar un endpoint de un API REST si no sabes lo que significan esos términos?

¿Qué harás cuando el LLM te responda con código incorrecto que no hace lo que tiene que hacer? informar a la IA del error a veces funciona… pero otras veces la IA entrará en un ciclo sin fin.

¿Cómo limitarás el contexto de lo que quieres preguntar a la IA para que esta pueda responder dentro de los limites máximos del tamaño del input si no sabes programar y/o no entiendes el código que estás intentando programar?

¿Cómo preguntarás a una IA para que te ayude a refactorizar código para hacerlo más legible, mantenible, extensible si no tienes conocimientos sobre estos conceptos? (por no hablar de aplicar patrones de diseño…)

Así que cuando oigas a un CEO (por ejemplo al de Nvidia) diciendo que con la IA ya no hará falta aprende a programar, pregúntate si esa persona tiene algún interés en vender esa falacia.

Ingeniería Software y LLMs: refactorización de código

¿Podría un LLM leer todo un repositorio Git y sugerir mejoras? ¿Podría soportar el LLM, con su limitación del tamaño de contexto un repositorio Git de un proyecto de Ingeniería Software de un curso de grado?

Vamos a probarlo. Empecemos con una herramienta que captura los ficheros de un repositorio Git y los convierte en un único string que podemos usar en nuestro super-prompt: https://github.com/mpoon/gpt-repository-loader [1]

Tomemos ahora un proyecto del curso de Ingeniería Software que imparto en la UPV/EHU: https://github.com/juananpe/facultyproject

Ejecutamos el script:

$ python gpt_repository_loader.py  /opt/facultyproject/src/main/java/faculty/project  -o /tmp/faculty.txt

Repository contents written to /tmp/faculty.txt.

Si echamos un vistazo a /tmp/faculty.txt veremos lo siguiente:

$ head -20 /tmp/faculty.txt
The following text is a Git repository with code. The structure of the text are sections that begin with ----, followed by a single line containing the file path and file name, followed by a variable amount of lines containing the file contents. The text representing the Git repository ends when the symbols --END-- are encounted. Any further text beyond --END-- are meant to be interpreted as instructions using the aforementioned Git repository as context.
----
ui/ApplicationLauncher.java
package faculty.project.ui;

import faculty.project.businessLogic.BlFacade;
import faculty.project.businessLogic.BlFacadeImplementation;

import java.util.Locale;

public class ApplicationLauncher {

  public static void main(String[] args) {

    System.out.println("Locale: " + Locale.getDefault());

    BlFacade businessLogic = new BlFacadeImplementation();

    new MainGUI(businessLogic);

Ahí vemos que le ha metido una cabecera («El siguiente texto representa un repositorio Git con código. La estructura del texto son secciones que empiezan con —, seguido por una línea con la ruta al fichero y sus contenidos…)

Al final del fichero (tras el –END–), meteremos la siguiente línea:
Can you suggest how to improve the code?

Y probemos ahora a pasarle el super prompt a un LLM que soporte un gran tamaño de contexto (Gemini Pro 1.5 es un gran candidato):

$ cat /tmp/faculty.txt | llm -m gemini-1.5-pro-latest

Y el resultado es muy interesante:

Potential Improvements for the Provided Code:

General:

  • Dependency Injection: The code currently uses manual object creation, leading to tight coupling. Consider using a dependency injection framework like Spring or Guice to manage object creation and dependencies, improving flexibility and testability.
  • Exception Handling: The current exception handling is minimal and sometimes throws runtime exceptions. Implement a more robust exception handling strategy, catching specific exceptions and handling them gracefully with informative messages or logging.
  • Logging: Integrate a logging framework like Log4j or SLF4j to track application behavior, debug issues, and monitor performance.
  • Testing: Implement unit and integration tests to ensure code quality and prevent regressions. Frameworks like JUnit and Mockito can be helpful.

DataAccess:

  • Data Access Object (DAO) Pattern: Instead of having all data access logic directly in DataAccess, consider creating separate DAO classes for each entity (User, Student, Subject, etc.) to improve modularity and maintainability.
  • Named Queries: Utilize named queries in JPQL for frequently used queries to improve readability and maintainability.
  • Optimistic Locking: Implement optimistic locking to prevent data inconsistencies when multiple users access the same data concurrently.

(puedes ver aquí el resultado completo: https://gist.github.com/juananpe/9ca627a13ca0e1927dfa2c40c86a2af8)

[1]Hay otros proyectos git2txt que hacen lo mismo que gpt_repository_loader:

https://github.com/JeremiahPetersen/RepoToText

https://github.com/ableinc/git2txt

Ingeniería Software y LLMs

El mundo ha cambiado. No somos conscientes de cuánto. Especialmente el mundo de la educación. Y más en concreto el de la ingeniería software. Ese cambio me afecta de lleno. Desde su introducción el 30 de noviembre de 2022, ChatGPT ha puesto patas arriba el sistema. A GPT3.5 le siguieron otros LLMs (Large Language Models): LLama, Gemini, Claude, Mistral… Y este es sólo el comienzo. Llevamos sólo 1 año y pico, pero las clases de ingeniería han cambiado radicalmente. O tal vez debería de decir que tienen que cambiar. Aún hay profesorado que se niega a que los alumnos usen LLMs en sus clases. Entiendo sus razones, aunque no las comparto. Creo que deberíamos de promover el uso racional de herramientas de IA en el aula. Este año pedí a mis alumnos que instalaran GitHub Copilot (gracias a la licencia que conseguimos a través de GitHub Student Pack). Copilot junto con el IDE IntelliJ es una maravilla. Ahorra horas de trabajo cada día. Unamos a esto el uso de un LLM para múltiples tareas de ingeniería software: análisis de requisitos (creación de diagramas de casos de uso, modelos de dominio), diseño (diagramas de secuencia, diagramas de clases), implementación (por supuesto), testing, depuración, ayuda para el despliegue, creación de scripts, creación de templates para comienzo de proyectos, guías paso a paso para cualquier tecnología… Y repito, piensa que esto es sólo el comienzo. Como decía recientemente Sam Altman, GPT4 será el peor LLM con el que trabajemos: a partir de hoy cualquier otro nuevo LLM (de OpenAI, Anthropic, Google…) será mejor que GPT4.

Diagrama de modelo de dominio, realizado en PlantUML a partir de una descripción del dominio en lenguage natural, creado por GPT-4 y visualizado en planttext.com

Hace un año creé el repositorio Generative AI Prompts for Teaching Software Engineering, que muestra ejemplos concretos de prompts que podemos usar en múltiples áreas relacionadas con la enseñanza de la ingeniería software: https://github.com/juananpe/gen-ai-in-softeng. Creo que es una muy buena herramienta para tomar ideas y aplicarlas directamente en tus clases. Debería retomar el proyecto y añadirle nuevas ideas.