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.