Vector DB Testing

Ver puntos de referencia

Cómo usar

• Asegúrese de que se instalen paquetes apropiados. Asegúrese de que se instale lo siguiente: SENTENDE_TRANSFORMERS TQDM PANDAS PYPDF2 ASYNCIO ASYNCIO CONCURCO RE QDRANT_CLIENT PYMILVUS DOTENV
• Cargue todos los PDF en /data /u otro directorio si se especifica.
  • Si tiene un archivo de metadatos para obtener más información sobre los archivos PDF, cárguelo en el directorio de inicio y nombrelo metadatos.csv o cambie el nombre. Es probable que el código sea cambiar en get_metadata () en MacLoader para acomodar su archivo de metadatos específico.
• Detalles de conexión de entrada en .env. Vea .env-Ejemplo para cómo debería ser su .env.
  • Esto se puede evitar si solo desea ingresar los detalles como parte de la inicialización de DB en el código.
• Cree un archivo de índice Python. Desde aquí definiría el registro apropiado. Con todos los datos, es importante tener en cuenta cualquier problema. Todo el registro se nombra apropiadamente usando información, advertencia, error y crítico.
• Crea Delete.txt, no pongas nada en él.
• Importar archivos apropiados del proyecto e inicializarlos con los detalles apropiados. Todos los parámetros disponibles están bien documentados y deben ser mostrados por su IDE a través de flotar o hacer clic.
  • Ej: from Loader import MacLoader y from databases.PineconeDB import PineconeDB
• Después de hacer una ejecución de sus archivos, consulte Delete.txt y vea qué archivos están dando problemas con el lector PYPDF2. Si desea eliminar estos archivos, use utilidad.delete_bad_pdfs ()
• ¡Disfruta, déjame saber cómo mejorar este proceso!

Control de llave

Preprocesamiento

Llama_Index es genial, pero su confiabilidad en los nodos es un verdadero obstáculo. TextNodes parecen muy útiles, pero con él vienen muchos datos innecesarios que carga con su vector que solo ocupa el almacenamiento y el rendimiento. Debido a esta razón solo, no se debe utilizar para complicar el proceso de carga vectorial. Los datos adicionales son demasiado cuando se encuentran en un conjunto de datos de escala de producción. También no me gusta lo molesto que es escribir código a veces, tantas reglas extrañas y pasos innecesarios. TextNodes puede ser un activo poderoso y poderoso si todo se administra correctamente, con todos los datos adicionales almacenados localmente y no obstaculizar las velocidades o la memoria de recuperación.

Langchain hace una forma más fácil de interactuar los datos con menos reglas (aunque depende del contexto). Definitivamente no creo que Langchain esté listo para la producción y la cinta de agarre debería usarse en su lugar. Tener un control total sobre todo el proceso también puede preferirse en un entorno de producción.

En general, no puedo encontrar algo que se ajuste fácilmente exactamente como lo quiero. Aquí está mi comprensión de cómo creo que debería ir este proceso:

Al terminar este programa, me di cuenta de que era solo un reemplazo para las dos herramientas anteriores. Las dos herramientas anteriores están destinadas a aplicar a todos los casos de uso, acabo de codificar uno específico para el mío.

Incrustaciones / transformadores

Elegir transformadores de oraciones no fue demasiado difícil.

• All-Minilm-V2 fue bueno y rápido, pero estaba preocupado por la escalabilidad con cantidades masivas de datos. No es el más preciso pero aún bueno, pero no para la producción.

• E5-Large-V2 falló la recuperación de datos básicos en una pequeña escala en mis pruebas. Debido a esto, tampoco lo consideraré a mayor escala.

• Todo lleva más tiempo con los incrustaciones del instructor , pero es probable que le darán una precisión de datos mucho mejor. Todavía no los he probado correctamente.

• All-MPNET-V2 es solo mejor en términos de velocidad y rendimiento, tal vez no tan preciso como los incrustaciones de instructor, pero la velocidad y el rendimiento pueden preferirse en un entorno de producción.

• Los incrustaciones de ADA (OpenAi) serán mucho más caras que los transformadores de oraciones locales típicos. En el pasado, he tenido problemas para procesar conjuntos de datos masivos debido a los límites de tasa y otras restricciones impuestas por su modelo. Tener datos enviados en fragmentos resolverá este problema.

  • Es importante considerar que ADA también se incrusta en una dimensión de 1536. Esto conducirá a tiempos de búsqueda semánticos más altos debido a las matemáticas adicionales requeridas para tantas dimensiones más. Una vez más, esto también conduciría a una mayor precisión, pero otros modelos también pueden hacer una incrustación de alta dimensión sin el uso de una API externa costosa.
  • Si el uso de un transformador de oración local es limitante o inconveniente, este es un gran reemplazo.

Elección final: indeterminado. Necesito terminar primero antes del procesamiento antes de elegir entre instrucciones o mpnet

Bases de datos vectoriales

Bases de datos rechazadas

• Croma
  • Falta de opciones de implementación del servidor. Para proyectos pequeños, esta siempre será la mejor opción, aunque creo.
• Pgvector
  • Funciona muy mal en puntos de referencia por alguna razón. Sin embargo, puede no ser representativo del rendimiento del mundo real. Ver aquí
  • Si la base de datos POSTRESQL ya está planificada para estar en uso, o es práctico para los datos dados, no tengo dudas de que PGVector sería la mejor opción. Sin embargo, no usaría la biblioteca PGVector por sí sola ni cambiaría a postresql para ella.
• Elástico
  • Lento y torpe
• Tejido
  • Anteriormente había planeado evaluar esto, pero mientras intentaba implementar esto en este programa tuve muchas más dificultades en comparación con todos los demás.
    • La documentación para el cliente de Python no es excelente en absoluto, no fue una locura difícil, pero la falta de documentación es preocupante.
    • Mi caso de uso planea usar una nube administrada, y el WCS me hizo realmente preocuparme. No parece haber mucha seguridad, ni siquiera hay 2FA. Personalmente, no confío en WCS, y tenía la peor UI en comparación con cualquiera de las otras bases de datos.
    • Si se planea usar en un contenedor de Docker, Weaviate debe reconsiderarse y recibir un tiro justo, pero por ahora no continúo evaluándolo.

Actualmente investigando

• Piña
• Milvus
• Qdrant

Consideraciones de todo el proceso

• Los PDF tienen tanta basura y la mayoría de los cargadores comen eso. Para quitar el texto de PDF, hay mucha basura, especialmente cuando se usa una solución de lectura de Langchain o Llama_Index. No tener control sobre ese proceso lo hizo más difícil de lo que hubiera sido hacer un cargador PDF de directorio personalizado.
  • Creo que casi cualquier otro formato es superior a los PDF para leer de cantidades masivas de datos. Tantos problemas con la codificación, los caracteres basura y el texto de ruinas de PDF ilegible y atascar la tubería.
• Los datos de texto se pueden almacenar en todas las bases de datos vectoriales si es necesario. Esto simplificará drásticamente el proceso de almacenamiento. Muchas bases de datos vectoriales permitirán esto en forma de metadatos, pero no permitirán el almacenamiento separado del texto que puede ser un problema. El texto es demasiado grande y es intensivo en la memoria para que también se almacene en la memoria, y los metadatos se pueden almacenar en el disco, pero luego el filtrado de metadatos no estará disponible.
  • Si la base de datos Vector no maneja correctamente esto, el proceso de carga vectorial puede simplificarse solo cargando los vectores y una ID. Cuando se realiza una búsqueda semántica, busque una base de datos local o NoSQL desde la ID asociada.