Desarrollo de chatbot consciente de documentos y reglamentos pertinentes a la universidad Arturo Prat y la carrera de Ingenieria Civil en Computacion e Informatica.
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
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. Unnamespacees básicamente una colección o categoría en el index. Ahora los reglamentos se guardan en el namespaceReglamentosy lo extraído de wikipedia en el namespaceWikipedia.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_toolywikipedia_retriever_tool. Son esencialmente la misma herramienta solo que para los namespacesReglamentosyWikipedia, 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_typedemmrysimilarityen los retrievers y los resultados desimilarityparecí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.