Saltearse al contenido

Cómo lo hemos medido

Las cifras de esta sección salen de una sola prueba, hecha el 17 de octubre de 2026 con los componentes de NappAI. Esta página explica cómo se hizo, para que sepas qué significan los números y hasta dónde llegan.

La base de conocimiento

Creamos la documentación de una empresa ficticia que repara cafeteras profesionales, con marcas inventadas (Jaltec, Vellani y Molinar). Son 9 documentos en español, unas 8.500 palabras:

DocumentosQué contienen
3 manuales técnicosCódigos de error, piezas y procedimientos de una cafetera de cada marca y de un molino.
1 política de garantía y tarifasCondiciones y precios de 2026.
1 guía de mantenimiento preventivoQué revisar y cada cuánto.
3 informes mensuales de incidenciasJulio, agosto y septiembre: 24 incidencias, con su cliente, su técnico, su máquina y su estado.
1 documento de preguntas frecuentes12 preguntas de clientes.

Está hecha para ser difícil a propósito: el mismo código de error significa cosas distintas en cada marca (el E07 es la sonda de temperatura en una, el caudalímetro en otra y el motor en la tercera), muchos párrafos no nombran su máquina y los tres informes tienen la misma estructura sin decir su mes en cada apartado.

Las incidencias también se cargaron en un grafo de Neo4j: cada incidencia unida a su cliente, su técnico y su máquina.

Las 40 preguntas

TipoPreguntasEjemplo
Dicha con otras palabras10«¿Cada cuánto tiempo hay que renovar las gomas que sellan el portafiltros?»
Código o referencia exacta8«¿Qué pieza es la JT-777?»
Necesita un filtro (marca, mes, tipo de documento)6«¿Qué significa el error E07 en la cafetera Vellani Aurora?»
El fragmento no dice de qué habla6«¿Qué recomendó el informe de septiembre sobre los descalcificadores?»
Relaciones o recuentos6«¿Cuántas incidencias abiertas tiene asignadas Lucía Ortega?»
No está en los documentos4«¿Qué significa el error E21 en la Jaltec Brío 2G?» (ese código no existe)

Qué medimos

Para cada pregunta sabíamos qué frase de qué documento la responde. Con eso medimos:

  • Primer resultado: en qué porcentaje de preguntas la respuesta correcta estaba en el primer resultado.
  • Cinco primeros: en qué porcentaje estaba entre los cinco primeros, que es lo que suele recibir un agente.
  • Tiempo de cada búsqueda y de cada ingesta, y llamadas a modelos que añade cada técnica.

Las preguntas de relaciones y recuentos se midieron por la respuesta final: se daban por buenas solo si eran exactas (el número correcto, todas las personas correctas y ninguna de más). Una negativa a responder contaba como fallo.

Configuración común: fragmentos de 800 caracteres con 150 de solapamiento (80 fragmentos), el modelo de vectores por defecto de FastEmbed Embeddings (Local) y DeepSeek como modelo de lenguaje, en su versión más rápida.

Resultados principales

Bases vectoriales

BasePrimer resultadoCinco primerosTiempo por búsqueda en un flujo
FAISS60 %83 %16 ms
Chroma DB60 %83 %16 ms
Qdrant60 %83 %36 ms
PGVector60 %83 %35 ms

Las cuatro devolvieron los mismos cinco primeros resultados en las 40 preguntas. Detalles en Bases vectoriales.

Técnicas de búsqueda (preguntas sobre documentos)

TécnicaPrimer resultadoCinco primerosCoste por pregunta
Búsqueda básica (5 resultados)60 %83 %Ninguno
Búsqueda híbrida, pesos iguales53 %83 %Ninguno
Búsqueda básica + Local Rerank77 %90 %Unos 1,2 s
Multi Query Retriever63 %83 %1 llamada, unos 1,3 s
SelfQueryRetriever con los datos de cada documento57 %93 %1 llamada, unos 1,1 s
Fragmentos con contexto, búsqueda básica50 %93 %Ninguno (1 llamada por fragmento en la ingesta)
Fragmentos con contexto + híbrida + Local Rerank80 %100 %Unos 2 s (1 llamada por fragmento en la ingesta)

Las filas con Local Rerank se volvieron a medir el 18 de octubre con su modelo actual. El desglose por tipo de pregunta está en Técnicas de recuperación.

Modelos de vectores

ModeloCinco primerosTiempo por pregunta
jinaai/jina-embeddings-v2-base-es (por defecto)83 %10 ms
intfloat/multilingual-e5-large87 %30 ms
Snowflake/snowflake-arctic-embed-l-v2.083 %22 ms (e5-large, medido a la vez: 22 ms)
bge-m3 (Ollama)73–80 %20 ms
paraphrase-multilingual-MiniLM-L12-v263 %6 ms
nomic-embed-text (Ollama)53–57 %13 ms

Detalles en Vectorización y etiquetado.

Grafo frente a fragmentos (6 preguntas de relaciones y recuentos)

Cómo se buscóRespuestas correctas
Mejor combinación de fragmentos2 de 6
Los tres informes enteros en las instrucciones3 de 6
Neo4j GraphRAG, Vector + Graph3 de 6
Neo4j GraphRAG, Text2Cypher sin ejemplos2 de 6
Neo4j GraphRAG, Text2Cypher con 2 ejemplos5 de 6

Detalles en GraphRAG con Neo4j.

Lo que aprendimos

  1. La base vectorial no cambia la calidad. Elige por servidor, filtros y cómo trabajas.
  2. El modelo de vectores sí importa. El de por defecto es el mejor equilibrio en español; los modelos pensados para inglés fallan con preguntas dichas con otras palabras.
  3. El contexto en cada fragmento es la mejora más rentable: se paga una vez, en la ingesta, y junto con la reordenación da la mejor combinación medida.
  4. La reordenación arregla los códigos exactos y su relevancia sirve para descartar lo que no tiene que ver. Un umbral de parecido entre vectores no lo consigue.
  5. Etiquetar exige cuidado: un campo que puede tener varios valores tiene que ser una lista, o los filtros fallan.
  6. Contar no es buscar. Las preguntas de recuento necesitan una consulta a una base de datos, con ejemplos.
  7. Hay preguntas sin respuesta que solo detecta el agente, como un código que no existe en un modelo que sí existe. Por eso las instrucciones deben pedirle que diga cuándo no lo sabe.

Límites de la prueba

  • Los datos son de prueba y pocos: 9 documentos y 40 preguntas, escritos por la misma persona que preparó las respuestas correctas. La base se diseñó para contener los casos difíciles, así que los resultados muestran cómo se comporta cada técnica, no con qué frecuencia aparece cada caso en datos reales.
  • Hay pocas preguntas por tipo (de 4 a 10). Una pregunta mueve el resultado general unos 3 puntos, así que diferencias de uno o dos puntos no son significativas.
  • Todo se ejecutó una vez, en un portátil compartido con otros programas. Los tiempos orientan; en tu servidor serán otros. El tiempo de la reordenación, en particular, depende mucho de la carga del equipo: medimos entre 1,3 y 2,7 segundos para la misma tarea.
  • No probamos todos los componentes: Cohere Rerank, Multi Vector Retriever y los modelos de vectores de proveedores externos quedaron fuera.

Fecha de la medición: 17 de octubre de 2026.

Mide tu propio RAG

Las cifras de esta sección salen de nuestra base de prueba. Para saber cómo responde tu asistente con tus documentos, usa RAG Evaluator: un modelo hace de juez y puntúa cada respuesta. Te dice si se apoya en lo que encontró la búsqueda, si contesta a lo preguntado, si la búsqueda trajo lo necesario y, si das la respuesta correcta, si coincide con ella. Prepara 20 o 30 preguntas reales con su respuesta correcta y compara configuraciones con las mismas preguntas.

Este vídeo puntúa una respuesta dentro de un flujo y después un conjunto de preguntas de prueba, con una respuesta alterada a propósito.

Lo que ves en el vídeo:

  1. Detrás de un agente, RAG Evaluator puntúa la respuesta a «¿Qué pieza es la JT-777 y cuánto tarda en llegar?»: fidelidad 1,0, relevancia de la respuesta 1,0 y relevancia del contexto 1,0, cada nota con su explicación.
  2. Un conjunto de prueba de 4 filas (pregunta, respuesta, fragmentos y respuesta correcta), leído de un archivo JSON del almacenamiento y conectado a Rows.
  3. Las medias: fidelidad 0,875 y corrección 0,875.
  4. La respuesta alterada a propósito («la primera media hora de mano de obra es gratis») saca 0,5, y su afirmación no respaldada aparece en la lista.