Multiple Documents QnA
Aprende cómo consultar múltiples documentos correctamente
Last updated
Aprende cómo consultar múltiples documentos correctamente
Last updated
Del último ejemplo de QnA con Web Scraping, solo estamos haciendo upsert y consultando 1 sitio web. ¿Qué pasa si tenemos múltiples sitios web o múltiples documentos? Veamos cómo podemos lograrlo.
En este ejemplo, vamos a realizar QnA en 2 PDFs, que son los FORM-10K de APPLE y TESLA.
Encuentra el flujo de ejemplo llamado - Conversational Retrieval QA Chain en las plantillas del marketplace.
Vamos a usar PDF File Loader, y subir los archivos respectivos:
Haz clic en Additional Parameters del PDF File Loader, y especifica el objeto metadata. Por ejemplo, el archivo PDF con el FORM-10K de Apple puede tener un objeto metadata {source: apple}, mientras que el archivo PDF con el FORM-10K de Tesla puede tener {source: tesla}. Esto se hace para segregar los documentos durante el tiempo de recuperación.
Después de completar las credenciales para Pinecone, haz clic en Upsert:
En la consola de Pinecone podrás ver los nuevos vectores que se agregaron.
¡Después de verificar que los datos se han insertado en Pinecone, ahora podemos empezar a hacer preguntas en el chat!
Sin embargo, el contexto recuperado usado para devolver la respuesta es una mezcla de documentos tanto de APPLE como de TESLA. Como puedes ver en los Source Documents:
Podemos arreglar esto especificando un filtro de metadata desde el nodo Pinecone. Por ejemplo, si solo queremos recuperar contexto del FORM-10K de APPLE, podemos mirar el metadata que especificamos anteriormente en el paso Upsert, y luego usar lo mismo en el Metadata Filter a continuación:
Hagamos la misma pregunta de nuevo, ahora deberíamos ver que todo el contexto recuperado es efectivamente del FORM-10K de APPLE:
Cada proveedor de base de datos vectorial tiene diferente formato de sintaxis de filtrado, se recomienda leer la documentación respectiva de la base de datos vectorial
Sin embargo, el problema con esto es que el filtrado de metadata está de alguna manera "hard-coded". Idealmente, deberíamos dejar que el LLM decida qué documento recuperar basado en la pregunta.
Podemos resolver el problema del filtro de metadata "hard-coded" usando Tool Agent.
Al proporcionar tools al agent, podemos dejar que el agent decida qué tool es adecuada para usar dependiendo de la pregunta.
Crea un Retriever Tool con el siguiente nombre y descripción:
search_apple
Usa esta función para responder preguntas del usuario sobre Apple Inc (APPL). Contiene un archivo SEC Form 10K que describe las finanzas de Apple Inc (APPL) para el período 2022.
Conéctalo al nodo Pinecone con el filtro de metadata {source: apple}
Repite lo mismo para Tesla:
search_tsla
Usa esta función para responder preguntas del usuario sobre Tesla Inc (TSLA). Contiene un archivo SEC Form 10K que describe las finanzas de Tesla Inc (TSLA) para el período 2022.
{source: tesla}
Es importante especificar una descripción clara y concisa. Esto permite que el LLM decida mejor cuándo usar qué tool
Tu flujo debería verse así:
Ahora, necesitamos crear una instrucción general para el Tool Agent. Haz clic en Additional Parameters del nodo y especifica el System Message. Por ejemplo:
¡Guarda el Chatflow y empieza a hacer preguntas!
Continúa con Tesla:
Ahora podemos hacer preguntas sobre cualquier documento que hayamos insertado previamente en la base de datos vectorial sin "hard-coding" del filtrado de metadata usando tools + agent.
Con el enfoque de Tool Agent, el usuario tiene que crear múltiples retriever tools para recuperar documentos de diferentes fuentes. Esto podría ser un problema si hay un gran número de fuentes de documentos con diferentes metadata. Usando el ejemplo anterior con solo Apple y Tesla, potencialmente podríamos expandirnos a otras compañías como Disney, Amazon, etc. Sería una tarea tediosa crear una retriever tool para cada compañía.
Aquí es donde entra en juego Metadata Retriever. La idea es que el LLM extraiga el metadata de la pregunta del usuario, y luego lo use como filtro al buscar en las bases de datos vectoriales.
Por ejemplo, si un usuario está haciendo preguntas relacionadas con Apple, un filtro de metadata {source: apple} se aplicará automáticamente en la búsqueda de la base de datos vectorial.
En este escenario, podemos tener una sola retriever tool, y colocar el Metadata Retriever entre la base de datos vectorial y la retriever tool.
Para algunos LLMs, las capacidades de function callings no están soportadas. En este caso, podemos usar XML Agent para indicar al LLM en un formato/sintaxis más estructurado, con el objetivo de usar las tools proporcionadas.
Tiene el prompt subyacente:
Hemos cubierto el uso de Conversational Retrieval QA Chain y sus limitaciones al consultar múltiples documentos. Y pudimos superar el problema usando OpenAI Function Agent/XML Agent + Tools. Puedes encontrar las plantillas a continuación:
