Cohere tuo Embed 5:n ja Rerank 5:n OpenRouterin yhtenäiseen APIin

Cohere ilmoitti 4. marraskuuta 2026, että sen Embed 5- ja Rerank 5 -hakumallit ovat saatavilla OpenRouterissa. Nykyiset käyttäjät voivat käyttää niitä samalla API-avaimella ja samoilla krediiteillä kuin muitakin malleja, ilman erillisiä SDK:ita, tilejä tai laskuja.

Mallit kattavat hakua hyödyntävän generoinnin eli RAG:n hakuvaiheet: Embed 5 muuntaa asiakirjat ja kyselyt vektoreiksi, Rerank 5 pisteyttää ehdokkaat uudelleen kyselyn perusteella, ja mikä tahansa OpenRouterissa saatavilla oleva chat-malli voi tuottaa lopullisen vastauksen. Cohere julkaisi myös Python-viitetoteutuksen, joka kattaa indeksoinnin, haun, relevanssisuodatuksen ja lähdeviitteitä sisältävän generoinnin.

OpenRouterin Embed 5 Pro -mallisivulla hinnaksi ilmoitetaan 0,12 dollaria miljoonaa tekstin tokenia kohden ja 0,40 dollaria miljoonaa kuvatokenia kohden. Embed 5 Fastin hinnaksi ilmoitetaan 0,08 dollaria miljoonaa tokenia kohden. Rerank 5 Pro -mallisivulla tämän tason hinnaksi ilmoitetaan 0,05 dollaria miljoonaa syötetokenia kohden ja Rerank 5 Fastin hinnaksi 0,02 dollaria miljoonaa tokenia kohden.

OpenRouter-julkaisu laajentaa jakelua sen sijaan, että se toisi markkinoille uuden mallisukupolven. Cohere esitteli Embed 5:n 30. syyskuuta 2026 ja Rerank 5:n 21. lokakuuta 2026. Molemmista malliperheistä on saatavilla Pro- ja Fast-versiot.

Yhteinen upotusavaruus erottaa indeksoinnin ja kyselyjen kustannukset

Arkkitehtuurin keskeinen piirre on, että Embed 5 Pro ja Fast käyttävät samaa upotusavaruutta. Korpus voidaan siis indeksoida Prolla ja kysellä Fastilla ilman indeksin uudelleenrakentamista, kunhan molemmissa käytetään samoja tulostedimensioita. Näin indeksointi, joka tehdään kerran kutakin korpusta varten, erottuu upotuskutsusta, joka tehdään jokaista kysymystä varten ja jonka viiveellä ja kustannuksilla on merkitystä.

Cohere testasi malleja 40 kehitysaineistolla. Normalisoitu keskimääräinen hakulaatu oli 98,4, kun Prolla rakennetusta indeksistä haettiin Fastilla, ja 96,6, kun Fastia käytettiin molemmissa vaiheissa. Vertailuarvo oli 100, kun Prota käytettiin molemmissa vaiheissa. OpenRouterin työnkulussa käytetään tätä Pro-indeksointi/Fast-haku-yhdistelmää, jolloin Pro jää offline-indeksointivaiheeseen.

Embed 5 tarjoaa kuusi vektorikokoa 256–2 048 dimensiosta, ja oletuskoko on 2 048. OpenRouterin esimerkissä käytetään 1 024-dimensioisia liukulukuvektoreita, koska sen upotus-API palauttaa liukulukuja. Cohere suosittelee erikseen int8-vektoreita samassa dimensiossa parhaana laadun ja kustannusten kompromissina. Osien eräkäsittely vähentää verkkokierroksia indeksoinnin aikana, mutta ei pienennä tokeneihin perustuvia upotusmaksuja. Verkkokäytössä tehdään kutakin kysymystä kohden yksi Embed 5 Fast -kutsu, yksi Rerank 5 -kutsu ja suodatuksesta läpi pääsevän kontekstin tapauksessa yksi chat-kutsu.

Relevanssipisteet määräävät generoinnissa käytettävän kontekstin

Viitetoteutus hakee 20 osaa kosinisamankaltaisuuden perusteella, lähettää ne kysymyksen kanssa Rerank 5:lle, säilyttää enintään viisi tulosta ja hylkää ne, joiden pisteet jäävät alle esimerkin 0,3:n raja-arvon. Uudelleenpisteytyksessä kyselyä ja kutakin ehdokasta tarkastellaan yhdessä sen sijaan, että luotettaisiin vain vektorien läheisyyteen. Uudelleenpisteytystä voidaan käyttää semanttisen haun, avainsanahaun tai hybridihaun jälkeen myös ilman Embed 5:tä.

Cohere kertoo, että Rerank 5:n kalibroidut pisteet pysyvät yhdenmukaisina eri kyselyissä ja toimialoilla, joten yhdellä raja-arvolla voidaan määrittää, mikä konteksti välitetään generointimallille. Julkaisudokumentaatiossa 0,7:n pisteen kuvataan tarkoittavan 70 prosentin todennäköisyyttä sille, että asiakirjasta on hyötyä. Pro on tarkoitettu päättelyä vaativiin kyselyihin ja pitkiin tai toimialakohtaisiin asiakirjoihin, kun taas Fast on suunnattu suurivolyymiseen hakuun ja toistuvasti hakeviin agentteihin. Mallit tukevat 32K-tokenin kontekstia ja pystyvät käsittelemään JSON-tietueita tai YAML-merkkijonoiksi muotoiltuja taulukoita.

Generointivaiheessa suodatuksesta läpi päässeistä osista tulee numeroituja lähteitä, ja mallia ohjeistetaan vastaamaan vain niiden perusteella sekä viittaamaan niihin tekstissä. Jos yksikään osa ei ylitä raja-arvoa, työnkulku ilmoittaa, ettei vastausta löytynyt, eikä tee chat-mallikutsua. Koska Rerank lukee raakatekstiä kyselyhetkellä, uudelleenjärjestäjämallin version vaihtaminen ei edellytä uudelleenindeksointia tai uudelleenupotusta.

Esimerkkitulokset ja tuotantokäytön rajoitteet

Cohere käyttää esimerkissään kuvitteellista API-dokumentaatiota ja kysyy, miten avain voidaan vaihtaa käyttökatkotta. Pelkkään upotukseen perustuva haku sijoitti oikean asiakirjan API-avainten kierrättäminen ensimmäiseksi pistein 0,522. Seuraavina tulivat Webhookien allekirjoitussalaisuudet pistein 0,337 ja API-avainten luominen pistein 0,316. Uudelleenpisteytyksen jälkeen oikean asiakirjan pistemäärä oli 0,808, ja molemmat lähes vastaavat tulokset jäivät raja-arvon alle.

Esimerkki edellyttää Pythonin versiota 3.10 tai uudempaa, OpenRouterin API-avainta ja Python-SDK:ta sekä NumPyä muistissa toimivaa vektorivarastoa varten. Tuotantototeutuksissa tämä varasto ohjeistetaan korvaamaan vektoritietokannalla. OpenRouterin RAG-ohjeissa uudelleenpisteytys esitetään tarkkuuden ja viiveen välisenä valintana: se voi parantaa tuloksia, kun laajaa ehdokasjoukkoa on rajattava, mutta lisää yhden API-kutsun eikä sovi yhtä hyvin tilanteisiin, joissa pienin mahdollinen viive on etusijalla.

Monimuotoinen haku vaatii kiertotien. Embed 5 hyväksyy kuvia ja tekstiä sekä kuvia sisältäviä syötteitä, kuten PDF-sivuja, ja OpenRouterin upotus-API hyväksyy kuvan URL-osoitteita. Rerank 5 käsittelee kuitenkin vain tekstiä. Vaihtoehtoina ehdotetaan sivuilta poimitun tekstin tai kuvatekstien uudelleenpisteytystä tai uudelleenpisteytyksen jättämistä pois visuaalisten tulosten yhteydessä.

OpenRouter ilmoittaa Cohere-yhtiön molempien Pro-mallien ainoaksi palveluntarjoajaksi ja välittää pyynnöt suoraan sille. Molempien mallisivujen mukaan EU-alueen sisäinen reititys ei ole käytettävissä.

OpenRouterin saatavuus kokoaa hakukokonaisuuden integraation ja laskutuksen yhteen, mutta tuotantokäytön kustannusrakenne määräytyy edelleen arkkitehtuurin mukaan: Pro-indeksointi tehdään kertaluonteisesti, Fast-haku-, uudelleenjärjestely- ja chat-kutsut toistuvat, ja relevanssikynnys määrittää generointikontekstin. Yhtenäinen API ei poista kyseiselle kokonaisuudelle dokumentoituja lisäviiveitä, pelkkään tekstiin perustuvaa uudelleenjärjestelyä eikä alueellisen reitityksen rajoituksia.