La pregunta del usuario no siempre se parece al documento que la responde. Estas técnicas reescriben la consulta para acercarla al texto que hay indexado. Cuestan una llamada extra al LLM por consulta.
Aquí no se toca la pregunta: se cambia el criterio con el que la base decide qué está cerca. No cuestan llamadas extra al LLM.
Se recupera de más y se afina después. Cuesta latencia, no llamadas al LLM.
Puestas así se ve lo que una lista no deja ver: las de momentos distintos se suman —multi-query y luego re-ranking es una combinación perfectamente sensata—, mientras que dentro de un mismo momento suelen ser alternativas: no se busca por similitud y por MMR, se elige.
La forma útil de elegir no es «cuál es mejor», es qué fallo tienes delante:
| Lo que observas | Lo que suele fallar | Por dónde empezar |
|---|---|---|
| Los K chunks dicen casi lo mismo | Redundancia en el corpus | MMR |
| Falla con códigos, siglas o nombres propios | El embedding diluye lo literal | Búsqueda híbrida |
| Preguntas cortas o vagas no encuentran nada | La pregunta no se parece al documento | HyDE |
| Preguntas con varios aspectos traen solo uno | Una sola formulación, un solo ángulo | Multi-query |
| La respuesta está entre los 20 primeros pero no entre los 3 | Ordenación, no recuperación | Re-ranking |
| Recupera de documentos que no vienen al caso | Falta acotar el espacio de búsqueda | Filtrado por metadata |
Merece la pena leer la última fila dos veces. Antes de montar HyDE con su llamada extra por consulta, comprueba si el problema se resuelve descartando media base de datos con un filtro de metadata que ya tienes escrita. Reducir el espacio de búsqueda casi siempre gana a refinar el ranking dentro de él.
| Estrategia | Llamadas extra al LLM | Búsquedas | Se nota en |
|---|---|---|---|
| Similitud | 0 | 1 | — |
| MMR | 0 | 1 (recuperando de más) | Apenas |
| Híbrida | 0 | 2 (léxica + vectorial) | Poco, si el índice léxico está bien montado |
| Re-ranking | 0 (pero un modelo extra) | 1 amplia | Latencia, proporcional a cuántos reordenas |
| HyDE | 1 | 1 | Latencia y coste, en cada pregunta |
| Multi-query | 1 | N | Latencia y coste, lo más caro de la lista |
Las dos últimas filas son las que conviene tener presentes: son las únicas que meten al LLM dentro del camino de recuperación. Eso significa que ahora una pregunta puede fallar por un motivo nuevo —que el modelo generase una mala reformulación— y que el bug es no determinista.
// cada llamada extra al LLM en el retrieval es una fuente más de variabilidadscore = 1.0 - (i * 0.1), con el comentario «score aproximado por ranking»), así que
el primer resultado saca siempre 1.0 con cualquier corpus; y de las cinco columnas, unas son
distancias —menor es mejor— y otras similitudes —mayor es mejor—, mezcladas sin
aviso. Además la búsqueda híbrida recupera el corpus entero en cada consulta
(k=len(self.documentos)) y normaliza con 1 - min(score, 1), que asume
un rango que la distancia coseno no respeta. Antes de creerte cualquier comparación de
estrategias, comprueba qué significa el número de cada columna y en qué dirección es mejor.
Curiosamente la propia guía explica la Reciprocal Rank Fusion, que existe justo para fusionar
rankings de escalas distintas — y luego no la usa.
Escribe diez preguntas que tus usuarios harían de verdad —no las que se te ocurren para probar— y etiqueta cada una: ¿es concreta o vaga?, ¿lleva dentro un término literal (un código, una sigla, un nombre) que tiene que aparecer sí o sí?, ¿pregunta una cosa o tres?
El recuento te dice qué estrategia te compensa antes de implementar ninguna. Si ocho de diez son concretas y directas, la similitud simple es tu respuesta y el resto del mapa es trabajo que no necesitas. Si la mitad llevan códigos, la búsqueda híbrida te dará más que cualquier otra cosa. Y si no puedes escribir esas diez preguntas, ese es el hallazgo: aún no sabes qué va a hacer tu sistema.