Descripción

Se esta dando uso de la clase OpenAIEmbeddings para realizar los embeddings. Esto trae consigo costos extra, los que se descuentan del plan actual en la API de OpenAI.

Objetivo

Implementar embeddings gratuitos (HuggingFace) y ver si hay diferencia significativa con los de OpenAI. En caso de que no, reemplazar OpenAIEmbeddings en el código por la opción gratuita.

Descripción

En pruebas anteriores, se definió que el uso de agentes no era apropiado para el chatbot, debido a que el agente tendía a realizar búsquedas online en vez de responder acorde a los documentos proporcionados.

Objetivo

Implementar nuevamente un agente, de manera tal que responda según los documentos, quizás mediante una buena definición de prompts. Una buena implementación de esto, significaría que la IA sea capaz de responder preguntas mas dinámicas sobre la universidad, como por ejemplo: carreras, próximos eventos, horarios de atención de diversos departamentos, etc. Lo que le daría un boost importante a la funcionalidad del chatbot.

Descripción

En nuestra propuesta de trabajo, mencionamos que tendríamos un manejo de datos sensibles, cosa que aun no hemos implementado debido a la poca cantidad de documentos actuales.

Objetivo

Primero, definir que tipo de datos sensibles se esperan que reciba la IA (que en realidad son los que se suben a la base de datos de vectores) en una reunión con el profesor.
Luego, escribir un script que detecte estos datos en un documento y usar este script en cada commit que se realice correspondiente a la subida de documentos, cancelando el commit en caso de que se encuentre datos sensibles (o los elimine del documento).

Links útiles

• GitHooks
• git-secrets
• BFG Repo-cleaner

Descripción

En la pagina de 📑 Documentos el usuario debería ser capaz de realizar el vectorizado de los documentos que suba o elimine.

Objetivo

Implementar el vectorizado de los documentos que se suban. También habrá que realizarlo cuando se eliminen documentos. Ver si hacerlo mediante un botón disponible al usuario o si se hace en el background durante la subida y eliminación.

Descripción

En la ultima reunión se menciono la idea de escribir un documento tipo glosario para la base de datos de vectores, donde se registrarían datos que no están presentes en los reglamentos, como las facultades, carreras, e información general de la universidad.
Según los avances que he estado haciendo en #5, pude ver que, durante el proceso de carga y split de los textos es posible utilizar una clase que realizaría este proceso pero a partir de una pagina en Wikipedia, por lo que implemente un botón que realiza justo eso, cargar el texto relevante de la pagina (es decir, se omiten links, referencias a otras paginas, etc.), dividirlo en chunks y subirlo al index en Pinecone.

Algo similar ya se habia probado pero en el contexto de una herramienta (#5). Sin embargo, al ser una herramienta significaba que solo el agente podría darle uso, ademas de que el scrapeo de la pagina se realizaba en el momento en que el usuario realizaba la pregunta, aumentando un montón el tiempo que el agente tardaba en responder (hasta los 30 segundos). De la manera en la que esta implementada esta función ahora significa que tanto el LLM como el agente pueden darle uso. Ademas, como estos documentos están en el index de Pinecone, se tienen acceso a esto muchísimo mas rápido, agregando solamente uno o dos segundos extra en la generación de respuesta.

Ahora bien, esto también genero un problema al momento de gestionar el index que tenemos en Pinecone ya que, por lo menos como funciona ahora, cada vez que se presiona el botón para realizar el scrapeo de Wikipedia, estos chunks son indexados en conjunto con el resto de reglamentos, lo que significa que es posible existan múltiples vectores relacionados con Wikipedia en caso de presionar el botón mas de una vez. Eliminar el index completo y volver a crearlo como lo hacemos con el resto de reglamentos no es una opción ya que también se eliminarían los vectores que ya existen y no tiene sentido que se tenga que volver a subir los reglamentos a Pinecone cada vez que se quiera actualizar la info recuperada de Wikipedia. Una solución a esto, y la que esta implementada ahora mismo, es la de utilizar los namespaces. Un namespace es básicamente una colección o categoría en el index. Ahora los reglamentos se guardan en el namespace Reglamentos y lo extraído de wikipedia en el namespace Wikipedia.

Esto también significa que tuvo que cambiar como funcionaban los retrievers de tanto el LLM como del Agente.

Agente

El agente ahora cuenta con dos herramientas, doc_retriever_tool y wikipedia_retriever_tool. Son esencialmente la misma herramienta solo que para los namespaces Reglamentos y Wikipedia, respectivamente. El agente solo utilizara la segunda herramienta en caso de que la primera no sea suficiente para dar respuesta a la pregunta del usuario. También es posible que no utilice ninguna en caso de no ser necesario, como cuando el usuario saluda o pregunta algo que el agente puede responder solo con el historial de conversación. Esto es perfecto ya que evitamos el gasto de tokens de manera innecesaria.

LLM

Para el LLM fue un poco mas complicado. En los primeros testeos, simplemente utilice dos retrievers, uno por cada namespace, y después los junte utilizando un EnsembleRetriever. Como simplemente copie y pegue el código de retriever que teníamos hecho en ambos retrievers, esto significo que, por cada retriever, se recuperaban 5 documentos, siendo 10 en total. Estos 10 documentos de contexto mas el historial de conversación y la pregunta actual del usuario aumento un montón el uso de tokens. Pasamos de utilizar un promedio de 3.3k a alrededor de 7k por interacción. Intente mitigar un poco esto simplemente reduciendo la cantidad de documentos recuperados por retrievers, a 2 cada uno. Esto cambio el uso de tokens a mas o menos el promedio que teníamos anteriormente. El problema parece ser que los documentos recuperados por el retriever de wikipedia no son siempre muy relevantes para el LLM, o el LLM simplemente los ignora. Por ejemplo, el LLM puede responder cuantas y cuales facultades existen en la universidad (wikipedia) pero responde que el rector actual es Gustavo Soto (reglamentos). Una solución a esto seria cambiar como funciona el LLM para que reformule la query del usuario a una mas adecuada para la recuperación de documentos (esto el agente lo hace automáticamente), esto es posible hacerlo mediante una call a otro LLM, lo que significaría costos extra.

También vale la pena mencionar que probé el search_type de mmr y similarity en los retrievers y los resultados de similarity parecían ser los mejores.

Objetivo

Decidir si vale la pena intentar mejorar como el LLM recupera los documentos contexto a costas de un costo mayor de la API de OpenAI o si simplemente lo dejamos así para empezar ya las evaluaciones del LLM y el agente.

Descripción

Pinecone es un servicio de pago a base de suscripción, con un modelo de pago 'as-you-go', lo que significa que se paga acorde al uso dado.

Actualmente se esta dando uso del tier gratuito de Pinecone, lo que nos da acceso a una base de datos de vectores con un máximo de 100.000 vectores. De momento, con los 12 documentos presente en este repo, estamos usando 221 vectores, lo que obviamente ira aumentando a medida que se agregan documentos.

Para evitar costos extra, seria ideal realizar pruebas con bases de datos locales, según las integraciones que tenga Langchain, como ChromaDB. Esto puede significar una mayor velocidad de respuesta en la búsqueda de documentos contexto, pero también puede significar una menor precisión en las respuestas generadas, dependiendo de la base de datos que se implemente. Otra limitación puede ser el tamaño de los archivos generados. Github solo permite un máximo de 100MB por archivo que se suba al repo.

Objetivo

Implementar una base de datos de vectores local y comparar los resultados con Pinecone. Si la diferencia no es mucha, reemplazar Pinecone por la opción local. En caso de que Pinecone sea mucho mejor, mencionar esta situación al profesor e indicarle que igual tenemos bastante espacio disponible en la base de datos actual.

Descripción

La universidad tiene un portal noticiero, Actualidad UNAP, con artículos relacionados con la universidad sobre eventos, actividades, logros, etc. Es actualizada frecuentemente, con un nuevo articulo cada par de días.

Objetivo

Facilitar los contenidos de estos artículos a la IA, para que pueda responder preguntas e informar al usuario sobre los mismos.

Descripcion

Al depender de varias librerias y otros servicios externos, seria buena idea llevar registro de todas las limitaciones que estos tengan.

Objetivo

Registrar limitaciones, ya sea de usuarios, llamadas API o cualquier otro tipo de cuello de botella que vaya a llegar a afectar el funcionamiento del chatbot a futuro.

Descripción

El proceso actual para subir documentos a Pinecone consta de los siguientes pasos:

1. Convertir manualmente los escaneos a texto utilizando Tesseract-OCR*.
2. Realizar correcciones necesarias a estos textos. Esto se debe a que el OCR puede tener dificultades al convertir ciertos símbolos, y el orden y la estructura del texto pueden ser caóticos*.
3. Guardar estas correcciones en archivos con formato .txt*.
4. Subir estos documentos .txt a través de la página de administración de documentos (que realiza un push a la rama docs de este repositorio en segundo plano).
5. Cargar estos documentos directamente desde este repositorio y crear los chunks.
6. Subir los chunks a su respectivo namespace en Pinecone.

Los pasos marcados con * son realizados por el usuario y suelen ser los más tediosos. Para mejorar la experiencia del usuario, sería lógico automatizar estos pasos, de modo que el usuario solo necesite subir los archivos (paso 4) y el resto se maneje en segundo plano.

Objetivo

Implementar la funcionalidad de escaneo automático de los contenidos de los documentos PDF. Afortunadamente, algunos PDF loaders de Langchain pueden extraer imágenes de documentos, lo que podría simplificar nuestra tarea, dependiendo de su eficacia y velocidad.

Descripción

Actualmente se da uso de los diseños por defecto de Streamlit para todo lo presente en la pagina.

Objetivo

Discutir con el profesor si espera que se hagan cambios en el diseño. Algunas opciones serian:

• Usar los colores de la universidad
• Insertar el logo de la universidad en alguna parte
• Añadir instrucciones a la pagina 📑 Documentos para la subida de documentos (adjuntar docs -> presionar boton 'subir archivos' -> presionar boton de vectorizado)
• Cambiar los iconos de usuario y IA en el chat

Descripción

En la ultima reunión se discutió la idea de evaluar las respuestas generadas por el chatbot mediante la comparación de estas respuestas con el reglamento. Si bien con anterioridad se menciono una idea similar, en vez de comparar la similitud entre textos, seria mas adecuado comparar el significado en si de estos textos.

Objetivo

Implementar alguna forma de comparar respuestas y documentos fuente que utilizo el chatbot para generar la respuesta. Esta implementación habrá que hacerla en su propio repositorio, pero llevar registro de eso en este, por conveniencia.

Una opción seria utilizar los modelos disponibles en HuggingFace para realizar y evaluar la comparación.

Descripción

Con la implementación de la pagina 📑 Documentos se implemento la opción de subir y eliminar documentos con los cuales se contextualiza el modelo de chat para la generación de respuestas. Los documentos con los que se interactúan son los presentes en el branch test de este repositorio.
Actualmente cualquier usuario puede subir y eliminar documentos.

Objetivo

Implementar alguna forma de autentificación en la pagina 📑 Documentos para restringir el acceso a personas selectas. Quizás sea necesario conversar con el profesor que tipo de autentificación seria necesaria. También habrá que informarle la manera con la que manejamos los documentos (mediante este repo) y consultarle si esta bien o si sera necesario realizar cambios.

Descripción

En la reunion de hoy, el profesor dio la idea de facilitar a los usuarios preguntas de ejemplo, para guiarlos sobre lo que pueden preguntar y las capacidades del chatbot.

Objetivo

Implementar un set de preguntas predefinidas que el usuario puede seleccionar que, una vez seleccionada, se de respuesta y se agregue al historial de chat. Un claro ejemplo de esto es lo que esta presente en la pagina de ChatGPT.