Cohere porta Embed 5 e Rerank 5 nell’API unificata di OpenRouter

Cohere ha annunciato il 4 novembre 2026 che i suoi modelli di recupero delle informazioni Embed 5 e Rerank 5 sono disponibili su OpenRouter. Gli utenti già registrati possono usarli con la stessa chiave API e gli stessi crediti degli altri modelli, senza SDK, account o fatture separati.

I modelli coprono le fasi di recupero delle informazioni di una pipeline di generazione aumentata dal recupero, o RAG: Embed 5 converte documenti e query in vettori, Rerank 5 ricalcola il punteggio dei risultati candidati in base alla query e qualsiasi modello di chat su OpenRouter può generare la risposta finale. Cohere ha inoltre pubblicato un flusso di lavoro di riferimento in Python che comprende indicizzazione, recupero, filtro per rilevanza e generazione con citazioni.

La scheda di Embed 5 Pro su OpenRouter indica un prezzo di 0,12 $ per milione di token di testo e di 0,40 $ per milione di token di immagini; Embed 5 Fast è indicato a 0,08 $ per milione di token. La scheda di Rerank 5 Pro indica un prezzo di 0,05 $ per milione di token di input per questo livello e di 0,02 $ per milione di token per Rerank 5 Fast.

Il lancio su OpenRouter amplia la distribuzione, senza introdurre una nuova generazione di modelli. Cohere ha presentato Embed 5 il 30 settembre 2026 e Rerank 5 il 21 ottobre 2026; entrambe le famiglie offrono i livelli Pro e Fast.

Gli embedding condivisi separano i costi di indicizzazione da quelli delle query

Il principale dettaglio architetturale è che Embed 5 Pro e Fast condividono lo stesso spazio di embedding. È quindi possibile indicizzare un corpus con Pro ed eseguire query con Fast senza ricostruire l’indice, purché in entrambi i casi si usino le stesse dimensioni di output. In questo modo il lavoro di indicizzazione, eseguito una sola volta per corpus, è separato dalla chiamata di embedding, sensibile alla latenza e ai costi, effettuata per ogni domanda.

Nei test di Cohere condotti su 40 set di dati di sviluppo, la qualità media normalizzata del recupero è stata pari a 98,4 con un indice creato con Pro e interrogato con Fast e a 96,6 con Fast su entrambi i lati, rispetto a 100 con Pro su entrambi i lati. Il flusso di lavoro su OpenRouter adotta l’abbinamento Pro per l’indicizzazione e Fast per le query, riservando Pro alla fase di indicizzazione offline.

Embed 5 offre sei dimensioni vettoriali, da 256 a 2.048, con 2.048 come valore predefinito. L’esempio su OpenRouter utilizza vettori in virgola mobile a 1.024 dimensioni perché la sua API per gli embedding restituisce valori in virgola mobile; separatamente, Cohere consiglia vettori int8 con quelle dimensioni come soluzione preferibile per il rapporto tra qualità e costi. Raggruppare i segmenti riduce le chiamate di rete durante l’indicizzazione, ma non riduce i costi degli embedding, calcolati in base ai token. Nel flusso online, per ogni domanda viene effettuata una chiamata a Embed 5 Fast, una a Rerank 5 e, se il contesto supera il filtro, una chiamata al modello di chat.

I punteggi di rilevanza determinano il contesto usato per la generazione

La pipeline di riferimento recupera 20 segmenti in base alla similarità coseno, li invia a Rerank 5 insieme alla domanda, conserva fino a cinque risultati e scarta quelli con un punteggio inferiore alla soglia dimostrativa di 0,3. Il riordino valuta insieme la query e ciascun risultato candidato, anziché basarsi soltanto sulla vicinanza tra vettori, e può essere applicato dopo una ricerca semantica, per parole chiave o ibrida, anche senza Embed 5.

Secondo Cohere, i punteggi calibrati di Rerank 5 restano coerenti tra query e domini, consentendo di usare un’unica soglia per stabilire quale contesto inviare al generatore; la documentazione di lancio descrive un punteggio di 0,7 come una probabilità del 70% che un documento sia utile. Pro è pensato per query che richiedono ragionamenti complessi e per documenti lunghi o specifici di un dominio, mentre Fast è destinato alla ricerca ad alto volume e agli agenti che effettuano ricerche ripetute. I modelli supportano un contesto di 32K token e possono elaborare record JSON o tabelle formattate come stringhe YAML.

Durante la generazione, i segmenti che superano il filtro diventano fonti numerate; le istruzioni richiedono di rispondere basandosi solo su di esse e di citarle nel testo. Se nessun segmento supera la soglia, il flusso di lavoro segnala che non è stato possibile trovare la risposta e salta la chiamata al modello di chat. Poiché Rerank legge il testo originale al momento della query, cambiare versione del modello di riordino non richiede di reindicizzare né di ricalcolare gli embedding.

Risultati della dimostrazione e vincoli per la produzione

La dimostrazione di Cohere utilizza una documentazione API fittizia e chiede come ruotare una chiave senza tempi di inattività. Il recupero basato solo sugli embedding ha classificato al primo posto il documento corretto, Rotazione delle chiavi API, con un punteggio di 0,522, seguito da Segreti per la firma dei webhook con 0,337 e Creazione di chiavi API con 0,316. Dopo il riordino, il documento corretto ha ottenuto 0,808 e i due risultati simili sono scesi entrambi sotto la soglia.

L’esempio richiede Python 3.10 o versioni successive, una chiave API e l’SDK Python di OpenRouter, nonché NumPy per il suo archivio vettoriale in memoria. Per le implementazioni di produzione, si consiglia di sostituire tale archivio con un database vettoriale. Le indicazioni di OpenRouter sulla RAG presentano il riordino come una scelta tra precisione e latenza: può migliorare i risultati quando occorre restringere un ampio insieme di candidati, ma aggiunge una chiamata API ed è meno adatto quando la priorità è ridurre al minimo la latenza.

Il recupero multimodale richiede una soluzione alternativa. Embed 5 accetta immagini e input misti di testo e immagini, come le pagine di un PDF, e l’API per gli embedding di OpenRouter accetta URL di immagini, ma Rerank 5 elabora solo testo. Le opzioni proposte sono riordinare il testo estratto dalle pagine o le relative didascalie, oppure omettere il riordino per i risultati visivi.

OpenRouter indica Cohere come unico fornitore per entrambi i modelli Pro e inoltra direttamente a Cohere le richieste. Entrambe le schede specificano che l’instradamento all’interno della regione UE non è disponibile.

La disponibilità su OpenRouter unifica l’integrazione e la fatturazione dello stack di recupero, mentre i costi operativi in produzione restano legati all’architettura: indicizzazione Pro una tantum, chiamate ricorrenti Fast per query, riordino dei risultati e chat, e la soglia di rilevanza che controlla il contesto di generazione. L’API unica non elimina i vincoli documentati per questo stack relativi alla latenza aggiuntiva, al riordino dei risultati basato solo sul testo o al routing regionale.