Estoy construyendo un flujo de trabajo de IA que utiliza un Vector Store Receiver conectado a PGVector. La mayoría de las veces recupera el documento correcto, pero ocasionalmente un documento menos relevante se clasifica más alto que el que realmente espero. Ya he confirmado que los documentos están incrustados correctamente y se utiliza el mismo modelo de incrustación para la indexación y la consulta. ¿Hay algo en lo que pueda trabajar para mejorar la calidad de la recuperación?
¿Cuál es el mensaje de error (si lo hay)?
Por favor, comparte tu flujo de trabajo
(Selecciona los nodos en tu lienzo y utiliza los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)
Comparte el resultado devuelto por el último nodo
Información sobre tu configuración de n8n
Versión de n8n: 1.123.x
Base de datos (predeterminada: SQLite):
Configuración de n8n EXECUTIONS_PROCESS (predeterminada: own, main):
Ejecutando n8n a través de (Docker, npm, n8n cloud, aplicación de escritorio):
Si un documento menos relevante está clasificándose más alto, a menudo es porque el mensaje central del documento relevante fue “diluido” por el texto circundante en su fragmento, o el fragmento era demasiado pequeño para proporcionar suficiente contexto.
Ajusta el tamaño y la superposición del fragmento: En tu nodo Text Splitter, experimenta con el tamaño del fragmento. Si los fragmentos son demasiado grandes (p. ej., >1000 tokens), contienen múltiples temas, haciendo que el vector sea un “promedio” de conceptos no relacionados. Si son demasiado pequeños (<200 tokens), carecen de contexto. Intenta un tamaño entre 400–800 tokens con una superposición del 10–20%.
Añade contexto a los fragmentos: Si estás dividiendo PDFs grandes o archivos markdown, antepón el título del documento o el encabezado de la sección a cada fragmento antes de incrustar. Puedes hacer esto usando un nodo Edit Fields (Set) o un nodo Code justo antes del Vector Store Receiver. Esto obliga al modelo de incrustación a anclar el vector al contexto específico del documento/sección.
Las bases de datos vectoriales calculan la distancia entre puntos utilizando fórmulas matemáticas. Si la métrica no coincide con la forma en que fue entrenado tu modelo de incrustación específico, las clasificaciones serán sesgadas.
Verifica el nodo PGVector: En tu configuración del nodo Vector Store Tool / PGVector, asegúrate de que la métrica de similitud esté establecida en Cosine Distance (o Cosine Similarity). La mayoría de los modelos de incrustación modernos (como text-embedding-3-* de OpenAI, Cohere y Mistral) están optimizados para similitud de Coseno. Si está establecido en L2 (Euclidiana) o Producto interno, puede causar que documentos irrelevantes obtengan puntuaciones más altas.
Algo que vale la pena verificar es qué tipo de índice hay en tu columna PGVector. Si es ivfflat o hnsw, significa que realmente estás haciendo una búsqueda de vecinos más cercanos aproximada. Si estás usando la configuración predeterminada, “aproximado” puede terminar significando que la coincidencia real más cercana se pierde y no simplemente se deprioritiza.
Para ivfflat, comprueba tu recuento de listas e incrementa ‘probes’ en el momento de la consulta. Más probes se acerca más a una búsqueda exacta, pero incluso un recuento de probes más alto no está garantizado que sea equivalente. Para hnsw, comprueba ‘ef_search’. Esto es algo rápido para descartar antes de intentar rerangueár tu búsqueda, especialmente porque podría ser un simple cambio SQL de una línea.
Hola @Oluwanifemi
El nodo del almacén vectorial tiene modos de inserción, obtención y recuperación, pero no tiene reemplazo o eliminación, por lo que cada ejecución de tu flujo de trabajo de ingesta agrega una copia nueva de cada fragmento en lugar de actualizar las filas que ya existen. Las copias antiguas casi idénticas compiten con el fragmento actual y pueden ocupar los primeros lugares del recuperador, lo que se muestra exactamente como un documento incorrecto ocasional ganando. Cuenta las filas y compara con lo que debería producir una única pasada de ingesta:
SELECT count(*) FROM your_table;
Si el resultado es un múltiplo de lo que esperas, vacía la tabla, indexa una vez, y elimina las filas de una fuente antes de volver a indexarla a partir de entonces.
Si ya has descartado un desajuste de modelo de embeddings, yo echaría un vistazo a cómo se dividen los documentos. Muchos problemas de recuperación surgen de chunks que contienen múltiples temas, lo que hace que el embedding sea menos enfocado
Otra cosa a verificar es si tus documentos contienen mucho texto repetido o plantillas. Si cada registro comienza con los mismos párrafos, los embeddings terminan más cerca uno del otro de lo que esperarías, lo que dificulta que PGVector clasifique la mejor coincidencia
Finalmente, no confíes demasiado en la puntuación de similitud en sí. Compara los 5 resultados principales en su lugar. Si el documento correcto aparece consistentemente cerca del principio pero no primero, generalmente es un problema de calidad de datos en lugar de un problema con PGVector
No es un bug. Este es el comportamiento normal de la búsqueda vectorial de una sola etapa: la similitud del coseno mide similitud temática, no relevancia. Cuando dos fragmentos están dentro de ~0.03 de distancia coseno, cuál clasifica primero es básicamente ruido. El hecho de que tus embeddings sean correctos no previene esto.
Solución (5 minutos, nativo en n8n desde 1.98):
En tu nodo PGVector Vector Store, establece Limit en 20 (el predeterminado es 4).
Options → Add option → Rerank Results → activar.
Un conector Reranker aparece en la parte inferior del nodo — adjunta un subnodo Reranker Cohere, modelo rerank-v3.5.
Deja el cableado del Vector Store Retriever y chain sin cambios.
Por qué funciona: tu modelo de embedding codificó los documentos sin haber visto nunca la consulta. El reranker es un cross-encoder — lee la consulta y el fragmento juntos y califica la relevancia real. Demasiado lento para todo el corpus, ideal con 20 candidatos.
Establece Limit como un número simple, no como una expresión — n8n#14151 ignora silenciosamente las expresiones allí y vuelve a 4.