Cohere conserva el 98,4 % de la calidad de búsqueda con consultas rápidas

Los sistemas RAG tienen un problema de ingeniería conocido: la búsqueda vectorial rápida reúne bien a los candidatos, pero con regularidad sube a las primeras posiciones fragmentos que se parecen a la pregunta por las palabras, no por el sentido. Si se pasan directamente a un modelo de lenguaje, este recibe contexto superfluo, gasta más tokens y tiene más probabilidades de dar una respuesta segura, pero errónea.

Cohere ha lanzado Embed 5 y Rerank 5 en OpenRouter. El sentido práctico de la novedad no está en que aparezcan dos nombres más en el catálogo de modelos. Ahora se puede construir un flujo de búsqueda completo con una sola API: crear un índice vectorial, encontrar candidatos, reordenarlos con más precisión y solo entonces llamar al LLM. No hacen falta cuentas ni SDK independientes de Cohere.

Cómo se reparte el trabajo

La indexación se hace una sola vez para todo el corpus de documentos. El texto se divide en fragmentos y Embed 5 Pro convierte cada uno en un vector. Para los documentos se indica el modo search_document y los vectores se normalizan para que la proximidad pueda calcularse con un simple producto escalar.

Cuando llega una consulta de usuario, trabaja Embed 5 Fast en modo search_query. Pro y Fast comparten un espacio vectorial común, por lo que no hay que construir el índice por segunda vez. Según Cohere, las consultas realizadas con Fast sobre un índice creado con Pro conservaron el 98,4 % de la calidad de una configuración totalmente Pro en 40 conjuntos de datos. Si se usa Fast tanto en la indexación como en la búsqueda, la cifra baja al 96,6 %.

Imaginemos una base de documentación con instrucciones para crear, revocar y sustituir claves de API. Un usuario pregunta cómo cambiar una clave sin detener el servicio. La búsqueda vectorial encuentra la instrucción correcta, pero junto a ella pueden aparecer páginas sobre creación de claves, secretos de webhooks y rotación de registros. Son semánticamente cercanas, aunque no responden a la pregunta.

Para qué sirve la segunda etapa

Rerank 5 recibe la pregunta y unos 10–20 fragmentos recuperados, lee cada par completo y devuelve un orden más preciso. En el ejemplo de Cohere, la instrucción correcta obtuvo una puntuación de 0,808, mientras que dos resultados cercanos pero inútiles no superaron el umbral de 0,3. Al modelo de lenguaje solo se envía una selección depurada de tres a cinco fragmentos.

Esta división es razonable: la búsqueda inicial se encarga de la exhaustividad y el reranker, de la precisión. Ejecutar una comparación pesada sobre todo el índice es demasiado caro, pero releer una lista corta de candidatos es perfectamente viable. Si tras el filtrado no queda nada, se puede omitir por completo la llamada al LLM e informar con honestidad de que los documentos no contienen la respuesta.

Cohere afirma por separado que las puntuaciones de Rerank 5 están calibradas entre consultas y áreas temáticas. Esto permite usar un único umbral de relevancia. Pero no conviene tomar 0,3 como un ajuste universal: el umbral de la demostración debe comprobarse con datos propios.

Qué tener en cuenta antes de implantarlo

La demostración usa NumPy como almacenamiento, por lo que sirve para un prototipo, no para una carga de producción. Un sistema en producción necesitará pgvector, Qdrant, Pinecone, Weaviate u otra base de datos vectorial, control de versiones del índice y observabilidad de la latencia, el coste y la calidad de los resultados.

El tamaño de los fragmentos también influye. Los demasiado cortos pierden contexto y los demasiado largos encarecen el reranking. Los 1500 caracteres del ejemplo son solo un punto de partida. Rerank 5 admite hasta 32 000 tokens para un par de consulta y fragmento, pero un contexto permitido grande no hace que los fragmentos grandes sean útiles de forma automática.

El siguiente paso práctico es tomar varias decenas de preguntas reales de usuarios, marcar a mano los documentos correctos y comparar la tasa de aciertos entre los cinco primeros antes y después del reranking. Al mismo tiempo conviene medir la latencia y el coste adicionales. Si la calidad mejora de forma notable, el esquema de Pro para el índice, Fast para las consultas y Rerank para la selección final ofrece una vía clara para acelerar RAG sin rehacer todo el sistema.