Disponibilità e modalità di utilizzo

Il 4 novembre 2026 Cohere ha annunciato che i modelli di recupero Embed 5 e Rerank 5 sono ora accessibili tramite la piattaforma OpenRouter. Gli utenti esistenti possono invocare questi modelli usando la stessa chiave API e i crediti già associati ad altri modelli, senza la necessità di SDK, account o fatturazioni aggiuntive.

Questi modelli coprono le fasi di recupero di una pipeline di retrieval‑augmented generation (RAG): Embed 5 converte documenti e query in vettori, Rerank 5 riassegna punteggi ai candidati rispetto alla query, e qualsiasi modello di chat presente su OpenRouter può generare la risposta finale. Cohere ha inoltre pubblicato un workflow di riferimento in Python che comprende indicizzazione, recupero, filtraggio di rilevanza e generazione citata.

Tariffe e tier di servizio

Su OpenRouter la lista prezzi per Embed 5 Pro è di 0,12 $ per milione di token testuali e 0,40 $ per milione di token immagine, mentre Embed 5 Fast è quotato a 0,08 $ per milione di token. Per Rerank 5 Pro il costo è di 0,05 $ per milione di token in ingresso, e Rerank 5 Fast costa 0,02 $ per milione di token.

Il rollout su OpenRouter non introduce un nuovo modello di generazione, ma amplia la distribuzione dei modelli di recupero già esistenti.

Tempistiche di rilascio dei modelli

    • Embed 5: introdotto il 30 settembre 2026.
    • Rerank 5: introdotto il 21 ottobre 2026.
    • Entrambe le famiglie offrono tier Pro e Fast.

Architettura condivisa e vantaggi di costo

Un dettaglio architetturale fondamentale è che Embed 5 Pro e Embed 5 Fast condividono lo stesso spazio di embedding. Un corpus può quindi essere indicizzato con la variante Pro e interrogato con la variante Fast senza ricostruire l’indice, a patto che entrambi usino le stesse dimensioni di output.

Ciò separa il lavoro di indicizzazione, eseguito una sola volta per corpus, dalla chiamata di embedding sensibile a latenza e costo, effettuata per ogni domanda.

Nei test di Cohere su 40 dataset di sviluppo, la qualità media normalizzata del recupero è stata:

    • 98,4 % per indice costruito con Pro e query con Fast.
    • 96,6 % per Fast sia in indicizzazione che in query.
    • 100 % per Pro su entrambe le fasi.

Il workflow di OpenRouter adotta la combinazione Pro‑indice/Fast‑query, riservando il tier Pro allo stage offline di indicizzazione.

Dimensioni dei vettori e ottimizzazioni

Embed 5 offre sei dimensioni di vettore, da 256 a 2 048 dimensioni, con 2 048 impostate come predefinite. L’esempio di OpenRouter utilizza vettori a 1 024 dimensioni in virgola mobile, poiché l’API di embeddings restituisce float; Cohere raccomanda separatamente vettori int8 a quella dimensione come punto ottimale qualità‑costo.

Il batching dei chunk riduce i round‑trip di rete durante l’indicizzazione, ma non diminuisce le tariffe basate sui token. Il percorso online prevede una chiamata a Embed 5 Fast, una a Rerank 5 e, se il contesto supera il filtro, una chiamata a un modello di chat per ogni domanda.

Controllo del contesto tramite punteggi di rilevanza

Il pipeline di riferimento recupera 20 chunk per similarità coseno, li invia a Rerank 5 insieme alla domanda, ne conserva al massimo cinque e scarta i risultati con punteggio inferiore a 0,3 (soglia dimostrativa). Rerank legge sia la query sia ogni candidato, anziché affidarsi solo alla vicinanza vettoriale, e può operare dopo ricerche semantiche, basate su keyword o ibride, anche senza Embed 5.

Secondo Cohere, i punteggi calibrati di Rerank 5 rimangono coerenti tra query e domini, consentendo l’uso di una soglia unica per decidere quale contesto raggiunge il generatore. La documentazione di lancio indica che un punteggio di 0,7 corrisponde a una probabilità del 70 % che un documento sia utile.

Il tier Pro è destinato a query che richiedono ragionamento complesso e a documenti lunghi o specifici di dominio, mentre Fast è ottimizzato per ricerche ad alto volume e agenti che eseguono interrogazioni ripetute. Entrambi i modelli supportano un contesto fino a 32 K token e possono gestire record JSON o tabelle formattate come stringhe YAML.

Generazione con citazioni inline

Durante la generazione, i chunk sopravvissuti diventano fonti numerate, con istruzioni al modello di rispondere esclusivamente usando tali fonti e di citarle inline. Se nessun chunk supera la soglia, il workflow segnala l’impossibilità di trovare una risposta e salta la chiamata al modello di chat.

Poiché Rerank legge il testo grezzo al momento della query, cambiare versione del reranker non richiede una nuova indicizzazione o re‑embedding.

Risultati dimostrativi e considerazioni operative

La dimostrazione di Cohere utilizza una documentazione API fittizia e chiede come ruotare una chiave senza downtime. Il recupero basato solo su embedding classifica il documento corretto “Rotating API keys” al primo posto con punteggio 0,522, seguito da “Webhook signing secrets” (0,337) e “Creating API keys” (0,316). Dopo il reranking, il documento corretto ottiene 0,808, mentre i due vicini scendono sotto la soglia.

Il campione richiede Python 3.10 o superiore, una chiave API OpenRouter, il SDK Python e NumPy per il vector store in‑memory. Per ambienti di produzione, si consiglia di sostituire lo store in‑memory con un database vettoriale.

La guida RAG di OpenRouter presenta il reranking come una scelta tra precisione e latenza: migliora i risultati quando è necessario ridurre un ampio insieme di candidati, ma aggiunge una chiamata API e può non essere ideale quando la latenza minima è prioritaria.

Recupero multimodale

Embed 5 accetta immagini e input misti testo‑immagine, come pagine PDF, e l’API di embeddings di OpenRouter supporta URL di immagini. Tuttavia Rerank 5 è limitato al testo. Le soluzioni proposte sono:

    • Rerank del testo estratto dalla pagina o delle didascalie.
    • Omettere il reranking per risultati puramente visivi.

Limitazioni di routing e considerazioni finali

OpenRouter elenca Cohere come unico fornitore per entrambi i modelli Pro e inoltra le richieste direttamente a Cohere. Entrambe le inserzioni specificano che il routing in‑region EU non è disponibile.

L’integrazione su OpenRouter consolida lo stack di retrieval in termini di integrazione e fatturazione, ma l’economia di produzione rimane legata all’architettura: indicizzazione Pro una tantum, query Fast ricorrenti, chiamate a rerank e a chat, e soglia di rilevanza che controlla il contesto generato. L’API unificata non elimina la latenza aggiuntiva, il reranking testuale o le restrizioni di routing regionale documentate per questo stack.