Artículo
Cohere presenta Embed 5 Pro y Fast para recuperar documentos

El anuncio de Cohere
Cohere anunció Embed 5 el 30 de septiembre de 2026. Incluye Pro y Fast, que comparten espacio de embeddings y permiten combinar indexación y consulta usando la misma dimensión. Las evaluaciones publicadas son de Cohere; no se reprodujeron aquí.
Según Cohere, ambos admiten texto e imágenes, al menos cien idiomas y 128K tokens de contexto. El anuncio los ofrece mediante su API, Model Vault, Microsoft Foundry y Amazon SageMaker.
Fuente: Introducing Embed 5—A new family of frontier embedding models.
Análisis propio: empezar por una pregunta que tenga respuesta verificable
Para evaluar este anuncio, proponemos un caso hipotético de soporte al cliente. Una empresa vende un programa de gestión y mantiene documentación de sus distintas versiones. El equipo quiere ayudar a sus agentes humanos a encontrar instrucciones antes de responder. El caso y el procedimiento siguientes son una propuesta editorial: no describen una implementación real ni un protocolo de Cohere.
La pregunta inicial podría ser: «¿Cómo exporto las facturas desde la versión de escritorio?». Parece concreta, pero faltan antecedentes. La persona podría estar usando otra edición, un sistema operativo diferente o una versión antigua. Antes de buscar, el equipo tendría que decidir cuáles de esos datos necesita confirmar y cómo pedirlos.
Para nuestro ejercicio, escogeríamos una pregunta con el contexto ya aclarado. La conservaríamos con sus palabras originales y las precisiones añadidas por la persona de soporte. Así podríamos revisar después si el buscador respondió a la necesidad planteada o a una reformulación que cambió su sentido.
Elegir la fuente esperada antes de ejecutar la búsqueda
La persona responsable del producto identificaría el artículo de ayuda que explica esa exportación. Registraría su título, dirección, edición y versión aplicable. También señalaría el fragmento donde aparece la instrucción y comprobaría si el documento sigue vigente. Esa selección inicial serviría como referencia para evaluar la recuperación.
Puede haber varias fuentes aceptables. Una guía de administración podría contener la misma explicación que el artículo de soporte, con más detalle. En ese caso, convendría registrar ambas y el motivo por el que permiten contestar. El objetivo de la referencia sería hacer discutible la evaluación, evitando que una preferencia personal por cierta página decida todo el resultado.
Si nadie encuentra una instrucción vigente, el problema tendría que quedar señalado antes de comparar modelos. Un buscador no puede convertir documentación incompleta en una política de producto confirmada. Para ese caso, la respuesta esperada del equipo sería reconocer la falta de información y consultar a quien mantiene la documentación.
Proponer una comparación donde cambie una decisión cada vez
En el ensayo propuesto, indexaríamos con Pro y compararíamos consultas con Pro y Fast, manteniendo la misma dimensión.
La colección de documentos, la pregunta, los filtros de versión y la cantidad de resultados solicitados se conservarían iguales en ambas condiciones. Documentaríamos también cómo se dividieron los artículos en fragmentos. De ese modo, una diferencia observada tendría un contexto que revisar y no dependería de haber cambiado varios componentes sin registrarlo.
Este diseño sería una comparación local preparada por el equipo. No permitiría anticipar cuál opción responderá mejor ni cuánto tardará. Tampoco bastaría para decidir una compra: primero habría que ejecutar los casos, examinar la evidencia y acordar qué errores son aceptables para ese servicio.
| Paso | Qué conservar | Qué revisar |
|---|---|---|
| Pregunta | Consulta original y contexto confirmado | Que la edición y la necesidad estén identificadas |
| Referencia | Documento esperado y fragmento pertinente | Que su instrucción siga vigente |
| Comparación | Índice, dimensión, filtros y configuración de consulta | Que los cambios estén documentados |
| Recuperación | Documentos devueltos y sus versiones | Que contengan información aplicable al caso |
| Respuesta humana | Explicación enviada y referencia utilizada | Que cada instrucción tenga respaldo localizable |
Abrir el documento recuperado y comprobar su versión
Imaginemos que una búsqueda devuelve una guía cuyo título parece correcto. La revisión empezaría abriendo el documento. Habría que comprobar si el apartado encontrado corresponde a la edición consultada y si la instrucción se mantiene en la versión actual. La semejanza del título sería apenas una pista para esa inspección.
Otro resultado podría citar una exportación que existía en una edición anterior. Para nuestro ejercicio, lo registraríamos como una recuperación inaplicable, aunque la redacción resulte clara y el documento contenga palabras muy parecidas a las de la pregunta. Esa clasificación permitiría detectar un fallo relevante para la atención al cliente.
También revisaríamos si falta parte del procedimiento. Un fragmento puede explicar dónde está un botón y omitir un requisito descrito en otro apartado. La persona de soporte necesitaría reconstruir la instrucción completa con documentos vigentes antes de recomendar una acción. La ficha conservaría las fuentes adicionales que tuvo que consultar.
La respuesta humana debe conservar su respaldo
Después de revisar las fuentes, la persona de soporte redactaría una respuesta adecuada para el cliente. Anotaría qué documento respalda cada paso y cualquier condición que limite su aplicación. Si la documentación no permite contestar, dejaría el caso pendiente y formularía la pregunta que necesita resolver con el equipo de producto.
Esta separación ayuda a evaluar dos trabajos distintos: localizar información pertinente y construir una respuesta útil con ella. Para el diseño propuesto, ambos necesitan evidencia propia. Encontrar el artículo esperado no demostraría que la explicación enviada sea correcta; una explicación convincente tampoco demostraría que su fuente esté vigente.
La revisión debería incluir preguntas que no tengan una respuesta documentada y consultas que puedan confundirse con otra versión. Preparar esas situaciones permitiría observar cómo actúa el sistema cuando una coincidencia aparente conduce a una instrucción equivocada. Aquí no presentamos resultados: el ensayo sigue siendo hipotético.
Qué información faltaría para tomar una decisión
Con las ejecuciones registradas, el equipo podría comparar qué fuentes encontró cada condición, qué errores aparecieron y cuánto trabajo adicional necesitó la revisión humana. Tendría que definir cómo valorar esos hallazgos antes de elegir una configuración. En este artículo no contamos con esas ejecuciones ni calculamos velocidad, ahorro o tasas de acierto.
La disponibilidad para una cuenta concreta, los países habilitados, la residencia de datos y sus límites siguen sin verificarse aquí. Si la empresa quisiera avanzar, esos puntos formarían parte de su comprobación previa, junto con las condiciones comerciales aplicables. La propuesta editorial solo entrega una forma de preparar la evaluación y conservar su evidencia.
Para conversar sobre tus casos y seguir aprendiendo, entra a la Comunidad gratuita.
Continúa con EmbeddingGemma 2: recuperar no es generar. Para profundizar en el diseño de una evaluación, lee SpireClimb: cómo diseñar una prueba útil para tu agente.