Una sola letra faltante bastó para hacer desaparecer un proyecto sobre el Mundial.
Busqué en mi sitio «something about sports». Mundial, un proyecto sobre predicciones de la Copa del Mundo, apareció detrás de Twitter Matcher, cuyo pasaje recuperado trataba sobre la captura de tuits y limpieza con NLP. Luego escribí «someting about sports». Ninguno de los dos proyectos apareció.
Un lector que busque un proyecto deportivo tendría una reacción razonable: esta búsqueda no funciona. Un ingeniero que examine el servicio podría reportar que el modelo devolvió vectores válidos, que cada documento estaba indexado y que PostgreSQL calculó las distancias correctamente. Ambas observaciones eran ciertas. Es en esa brecha donde la recuperación se vuelve interesante.
Este fallo expone dos decisiones que resultan fáciles de ocultar dentro de una sola casilla de búsqueda: qué candidato merece clasificar en primer lugar y si algún candidato merece siquiera aparecer. Un embedding nos da una puntuación de similitud. Aún tenemos que convertirla en esas decisiones, y las consecuencias de equivocarse quedan a la vista de cualquiera que cometa un error tipográfico.
La letra faltante no borró el significado
Aquí están las similitudes de coseno medidas en el corpus de prueba. Cada proyecto recibe la puntuación de su fragmento (chunk) con mejor coincidencia, usando la tarea de búsqueda de EmbeddingGemma 2.
| Query | Twitter Matcher | Mundial | Resultados por encima de 0.60 |
|---|---|---|---|
something about sports | 0.604354 | 0.601943 | Ambos, Twitter Matcher primero |
someting about sports | 0.587843 | 0.587212 | Ninguno |
El error tipográfico redujo la puntuación de Mundial en aproximadamente 0.015. Se mantuvo muy cerca del otro candidato. La aplicación convirtió ese leve movimiento en una desaparición total porque el umbral de corte era 0.60.
Esa es una distinción útil al depurar. La representación del modelo cambió; el umbral hizo que el desenlace fuera abrupto. Culpar de la página vacía exclusivamente al modelo pasaría por alto la decisión de la aplicación que la produjo.
Bajar el umbral de corte traería de vuelta a Mundial. Pero también traería de vuelta a Twitter Matcher, todavía por delante. Eso nos da una razón concreta para tratar la admisión y el ordenamiento por separado: un umbral puede ocultar un problema de ranking, y relajarlo puede exponer ese mismo problema a más lectores.
La consulta más específica World Cup colocó a Mundial en primer lugar con 0.713430. Una consulta no relacionada, banana bread recipe, no arrojó ningún proyecto por encima del umbral. Son resultados individuales alentadores, pero dejan una gran pregunta sin responder entre ellos: ¿con qué fiabilidad gestiona el sistema a un lector que recuerda el tema pero no sabe el nombre del proyecto?
Ese lector es exactamente a quien la búsqueda semántica debería ayudar.
Seis decimales pueden disfrazar una decisión débil
Una puntuación de 0.601943 parece precisa. Describe una comparación geométrica entre vectores, sin ninguna de las pruebas necesarias para interpretarla como una probabilidad de que el lector encuentre útil el resultado. Una similitud de coseno de 0.60 no significa un 60 % de confianza.
El estrecho margen entre estos dos proyectos resulta especialmente revelador. Twitter Matcher superó a Mundial por apenas 0.0024 en la consulta escrita correctamente. La interfaz presentó un orden categórico a pesar de que dicho orden no superaba un juicio humano elemental sobre la temática. Añadir más decimales describiría el fallo con mayor precisión sin que la decisión sea mejor.
Yo calibraría un umbral de aceptación contra consultas etiquetadas de la propia colección. Eso implica incluir resultados relevantes con puntuaciones bajas y resultados irrelevantes con puntuaciones altas, examinando luego el costo de cada error. Una página de descubrimiento puede tolerar ciertas coincidencias exploratorias. Un asistente que presenta una fuente como evidencia para una respuesta necesita motivos de mayor peso para confiar en ella.
La distribución de puntuaciones también corresponde a un modelo, un esquema de codificación y un corpus específicos. Trasladar un umbral conveniente a una colección distinta es una suposición sin contrastar. La consulta deportiva es un pequeño ejemplo de lo costosa que puede llegar a ser esa suposición en la interfaz.
Los prompts correctos son un prerrequisito, no un veredicto de calidad
El sospechoso evidente era la tarea del embedding. La recuperación es asimétrica: la consulta breve y el pasaje de origen más extenso desempeñan roles distintos. EmbeddingGemma 2 ofrece tareas de consulta independientes para búsqueda, preguntas y respuestas (QA) y recuperación de código, documentadas en la guía de Sentence Transformers de Google.
Esa distinción importa. «Encuentra el proyecto de deportes» solicita un resultado. «¿Cómo funciona el sistema de predicción?» solicita material que pueda respaldar una respuesta. Una búsqueda de código persigue otro objetivo diferente.
En este caso, la búsqueda pública ya empleaba el prefijo de búsqueda correcto. Los documentos ya incluían sus títulos y no había ningún prompt por defecto añadiendo silenciosamente otro prefijo. Al volver a codificar el primer chunk de Mundial se obtuvo una autocoincidencia por coseno de 1.0 frente al vector almacenado. El mal ranking sobrevivió a todas esas comprobaciones.
Hubo un error independiente en la consola de preguntas y respuestas: había heredado la tarea de búsqueda. Seleccionar la tarea de QA corrigió esa discrepancia sin necesidad de regenerar los documentos, ya que la codificación de los mismos se mantuvo igual. No hay ningún resultado controlado de «antes y después» sobre la calidad de la respuesta que pueda atribuirse a esa corrección.
La conclusión que me interesa destacar es que un contrato de embedding correcto acota el diagnóstico. Descarta ciertos errores de infraestructura. Pero no puede certificar que el pasaje más cercano del modelo sea el que el lector necesita. Una vez superadas esas comprobaciones, la siguiente pregunta útil es qué dice el pasaje recuperado y por qué merece esa posición.
La búsqueda híbrida aporta otra fuente de evidencia al ranking
Las palabras exactas siguen aportando información. El nombre de un proyecto, un identificador de código o «World Cup» pueden ser pistas mucho más sólidas que una proximidad semántica amplia. Un recuperador léxico preserva esa pista, mientras que un recuperador vectorial puede encontrar pasajes cuya redacción difiere de la solicitud.
PostgreSQL puede soportar ambas vías: pg_textsearch proporciona ranking BM25 y pgvector ofrece búsqueda por similitud vectorial. Mantenerlos junto a los registros de origen facilita aplicar las mismas reglas de publicación, idioma y visibilidad a ambas listas de candidatos.
Aun así, la combinación requiere una regla de ranking defendible. Sumar directamente una puntuación BM25 a una similitud de coseno asigna una relación arbitraria a dos sistemas de puntuación distintos. Reciprocal Rank Fusion (RRF) recurre en su lugar a las posiciones: un candidato recibe un aporte como 1 / (60 + rank) de cada lista. Un resultado ubicado cerca de la cima de ambas listas acumula respaldo sin pretender que sus puntuaciones brutas compartan escala. La constante y el presupuesto de candidatos siguen siendo decisiones de evaluación.
Hay dos limitaciones que conviene tener presentes. La fusión no puede rescatar a Mundial si ninguna de las dos listas de candidatos lo contiene. E incluso una colección completamente irrelevante tiene un resultado en primer lugar. Por lo tanto, un ranking fusionado requiere tanto verificaciones de recall de candidatos como una decisión independiente sobre si la evidencia disponible justifica devolver algo.
Para este sitio, la fusión de BM25 más vectores sigue siendo una mejora propuesta para la nueva ruta de recuperación. La ruta híbrida desplegada combina vectores con el ranking de texto integrado de PostgreSQL; aún no utiliza los índices BM25. Los resultados de la consulta deportiva ponen de manifiesto un fallo que debe resolverse. Pero no ofrecen ninguna prueba empírica de que RRF vaya a solucionarlo.
Mi motivo para probar la recuperación híbrida es puntual: le da al lenguaje exacto una vía independiente para entrar en el conjunto de candidatos. Que esa vía ayude a frases abiertas o con errores ortográficos es algo que la evaluación debe determinar.
Más material indexado puede facilitar encontrar la respuesta equivocada
El corpus de prueba abarcaba 221 fuentes o activos y 625 vectores almacenados, incluyendo texto completo de artículos, READMEs de proyectos públicos, imágenes y videos. Las verificaciones de cobertura confirmaron que no había fuentes faltantes ni desactualizadas. El fallo en la consulta deportiva ocurrió contando con toda esa cobertura.
Esos recuentos confirman si el material está disponible para la recuperación. No dicen nada sobre si el mejor pasaje respalda el resultado. En documentos divididos en chunks, inspeccionar únicamente el título principal puede ocultar el problema: un proyecto gana porque uno de sus pasajes obtuvo una buena puntuación, y el título hace que la coincidencia parezca más convincente de lo que el pasaje justifica. La evaluación debe conservar el fragmento ganador.
Los embeddings nativos para contenido multimedia acentúan esa misma distinción. Las autocoincidencias de imágenes y videos obtuvieron una puntuación de 1.0, lo que confirmó que las codificaciones almacenadas podían recuperar sus propios activos. Eso deja sin validar la recuperación común de descripción a contenido multimedia. Los videos se representaron mediante un máximo de ocho fotogramas muestreados, sin indexación de pistas de audio ni recuperación a nivel de marca temporal, por lo que una coincidencia exitosa apenas aportaría evidencia limitada sobre lo ocurrido a lo largo del clip.
Un modelo generador de respuestas también necesita acceso a la evidencia que describe. Un enlace de video recuperado y una descripción de la fuente no le proporcionan los píxeles del video. Las afirmaciones sobre una escena en particular exigen una entrada visual adecuada. De lo contrario, un índice más grande solo servirá para producir una respuesta con mayor nivel de confianza aparente, pero sin un respaldo real más sólido.
Qué me convencería de que la búsqueda funciona
Comenzaría con criterios que un lector pudiera defender: la consulta deportiva debería recuperar el proyecto del Mundial; un error tipográfico no debería eliminarlo tan a la ligera; una solicitud de una receta sin relación no debería arrojar un proyecto presentado como relevante. Luego ampliaría el conjunto a paráfrasis, consultas en español, nombres exactos e identificadores de código, reservando una porción que el ajuste fino jamás llegue a ver.
La primera métrica es el recall de candidatos con un presupuesto fijo. Si una fuente relevante nunca llega al conjunto de candidatos, el reranking no podrá hacer nada. Una vez que llega, métricas como MRR o nDCG pueden registrar si los resultados útiles suben hacia los primeros puestos. Las consultas no relacionadas requieren sus propios controles de falsos positivos, y la latencia debe medirse a la par de la calidad. BM25 por sí solo, vectores por sí solos y la fusión deberían someterse a las mismas consultas y juicios de relevancia.
En cuanto a las respuestas generadas, inspeccionaría si cada afirmación está respaldada por el extracto recuperado y si la cita apunta efectivamente a ese respaldo. Tener un proyecto relevante en la primera posición es apenas el punto de partida de esa prueba.
Esta es mi postura frente a los embeddings: los quiero en el sistema de recuperación, y quiero que sus decisiones queden expuestas a la evidencia. El fallo con el tema deportivo demuestra por qué. Los prompts de tarea correctos y una indexación completa convivieron con un ordenamiento deficiente; una mínima variación en la puntuación cruzó un límite arbitrario y descartó un resultado útil. Ninguna otra extensión de base de datos podría cambiar esos vectores existentes ni sus puntuaciones de coseno.
Antes de destinar la siguiente ronda de esfuerzos a cambiar de modelo, la invertiría en consultas etiquetadas y en los pasajes que resultaron ganadores. Así, un recuperador híbrido tendrá una tarea concreta que cumplir y un resultado que podamos evaluar. Un lector debería poder llegar con una descripción imperfecta y, aun así, encontrar el proyecto del Mundial. Hasta que eso supere la evaluación, el parte de buen funcionamiento del pipeline vectorial servirá de muy poco consuelo a quien se quede mirando una página vacía.