OpenAI vai Cohere upotuksiin? 512 tokenia voi katkaista dokumentin

Suomenkielisessä RAG-haussa OpenAI text-embedding-3-large on hyvä vertailukohta, jos hakukatkelma tarvitsee pitkää tekstiyhteyttä. Cohere embed-multilingual-v3.0 sopii erityisesti lyhyiksi pilkottuun aineistoon ja hakuun, jossa on myös kuvia. Coheren malliluettelon mukaan sen tekstikonteksti on 512 tokenia, vektori 1 024-ulotteinen ja suomi kuuluu tuettuihin kieliin.

OpenAI:n upotusohjeen mukaan text-embedding-3-large hyväksyy enintään 8 192 tokenin syötteen ja tuottaa oletuksena 3 072-ulotteisen vektorin, jota voi lyhentää dimensions-parametrilla. Pidempi sallittu syöte antaa tilaa asiayhteydelle, mutta ei yksin takaa parempaa hakua. Malli kannattaa valita sen perusteella, löytyykö vastaus oman aineiston oikeasta katkelmasta ja millä tallennus- ja käyttökustannuksella.

Tekstiraja määrää, mikä päätyy indeksiin

Cohere v3:n syöteraja on huomioitava jo dokumentteja indeksoitaessa. Coheren Embed API -kuvauksen mukaan truncate-asetuksen oletusarvo END poistaa liian pitkän syötteen lopun; NONE palauttaa ylityksestä virheen. Jos vastauksen sisältävä kappale on dokumentin lopussa, oletusasetuksella muodostettu vektori ei edusta sitä.

Katkelmat kannattaa siksi muodostaa ennen upotusta ja säilyttää jokaisessa viite alkuperäiseen dokumenttiin. Tokenimäärä on tarkistettava käytettävälle mallille: sama merkkimäärä tai sanamäärä ei takaa, että suomenkielinen teksti mahtuu syöterajaan. Virheen palauttava katkaisuasetus on hyödyllinen indeksoinnin aikana, koska silloin liian pitkä katkelma tulee näkyviin ennen kuin puutteellinen vektori tallennetaan.

OpenAI:n pidempi syöteraja voi pitää otsikon, taustan ja vastauksen sisältävän kappaleen samassa katkelmassa. Koko pitkän dokumentin upottaminen yhdeksi vektoriksi voi silti heikentää täsmällistä osumaa, kun sama esitys kattaa monta eri aihetta. Molemmilla malleilla tarvitaan siis järkevä pilkkominen; ero on siinä, millaisia katkelmapituuksia niiden rajat sallivat.

Laske vektoritila katkelmien määrästä

Vektorin ulottuvuuksien määrä ei yksin kerro indeksin kokoa. Laskentataulukkoon tarvitaan dokumenttien ja katkelmien määrät, ulottuvuudet sekä yhden koordinaatin tallennusmuoto. Jos koordinaatit tallennetaan 32-bittisinä liukulukuina, raakavektorin tavumäärä saadaan kertomalla ulottuvuudet neljällä. Tietokannan metatiedot, hakuindeksi ja mahdolliset kopiot tulevat tämän päälle.

Seuraava on ehdollinen laskuesimerkki: aineistossa on 100 000 dokumenttia, joista kukin on kyseisen mallin tokenisaattorilla mitattuna 1 200 tokenia. Kiinteä, limittäinen pilkkominen antaa kaksi erilaista tallennuslaskua:

• Cohere v3: 400 tokenin katkelma ja 50 tokenin limitys tuottavat neljä vektoria dokumenttia kohti. Yhteensä 400 000 raakavektoria vie noin 1,64 gigatavua.
• OpenAI text-embedding-3-large: 800 tokenin katkelma ja 100 tokenin limitys tuottavat kaksi vektoria dokumenttia kohti. Yhteensä 200 000 raakavektoria vie noin 2,46 gigatavua.

Luvut ovat kymmenjärjestelmän gigatavuja, eivät arvioita valmiin vektoritietokannan levytilasta. Esimerkissä Cohere-vektori on yksittäin kolmasosan OpenAI:n oletusvektorista, mutta lyhyempi katkelma kaksinkertaistaa vektorien määrän. Kokonaistila on siksi laskettava molempien tekijöiden tulona. Myös vektoritietokannan valinta vaikuttaa siihen, millainen indeksi näiden vektorien ympärille rakentuu.

Upotuksen hinta on erillinen lasku

OpenAI:n mallisivulla text-embedding-3-large -mallin hinnaksi ilmoitetaan 0,13 dollaria miljoonalta syötetokenilta; mallin syöte on tekstiä. Edellisen ehdollisen esimerkin OpenAI-pilkkominen lähettäisi limityksineen noin 130 miljoonaa tokenia. Tällä yksikköhinnalla kertaluonteinen upotus maksaisi noin 16,90 dollaria ennen kyselyjä, uudelleenindeksointia ja vektoritallennusta.

Cohere-pilkkominen lähettäisi samassa ehdollisessa laskussa noin 135 miljoonaa tokenia: viimeinen katkelma olisi muita lyhyempi. Sen API-kustannus saadaan kertomalla tokenimäärä käytössä olevan palvelun hinnalla, ei päättelemällä sitä vektorin ulottuvuuksista. Jos dokumentteja päivitetään usein, laskentataulukkoon tarvitaan myös arvio uudelleen upotettavista tokeneista. Limityksen kasvattaminen lisää syötettyjä tokeneita, vaikka alkuperäinen aineisto pysyy samankokoisena.

Suomen kieli ja kuvat muuttavat vertailua

Suomen kuuluminen tuettuihin kieliin kertoo, että Cohere v3:lla voi muodostaa upotuksia suomenkielisestä tekstistä. Se ei kerro, miten hyvin oman aineiston taivutusmuodot, yhdyssanat tai toimialan lyhenteet löytyvät. Erityisen paljastavia ovat kysymykset, joissa käyttäjä ilmaisee asian eri sanoin kuin lähdedokumentti tai käyttää suomenkielistä kysymystä englanninkieliseen lähteeseen.

Kuvia sisältävässä haussa mallien välinen ero on toiminnallinen. Cohere embed-multilingual-v3.0 tukee kuvien upottamista, kun taas tässä vertailtu OpenAI text-embedding-3-large käsittelee tekstiä. OpenAI-vaihtoehdossa kuvan voisi hakea sille erikseen tuotetun tekstikuvauksen kautta, jolloin tulos riippuisi myös kuvauksen laadusta. Cohere-vaihtoehdossa kuva- ja tekstiosumat voidaan ottaa samaan hakukokeeseen, mutta niiden osumatarkkuus on mitattava omalla kuva-aineistolla.

Mallin valmistaja ei myöskään yksilöi kontekstirajaa. Coheren uudemmilla Embed-malleilla on erilaiset syöterajat ja vektorivaihtoehdot kuin tässä tarkastellulla v3-mallilla. Kun malliversio vaihtuu, katkelmapituus, tallennuslasku ja hakutulos on arvioitava uudelleen.

Englanninkielinen pistemäärä ei ratkaise suomenkielistä hakua

MTEB English v2 -koosteessa OpenAI text-embedding-3-large -rivin kokonaispistemäärä on 66,43 ja Cohere cohere-embed-multilingual-v3.0 -rivin 66,01. Englanninkielisen kokonaismittarin ero on pieni, mutta se yhdistää erilaisia tehtäviä. Luku ei ole suomenkielisten dokumenttien hakutulos eikä kerro, löytyykö käyttäjän tarvitsema lähde ensimmäisten osumien joukosta.

Oman haun tulokseen vaikuttavat mallin lisäksi katkelmarajat, limitys ja kyselyn käsittely. Jos mallit indeksoidaan eri tavoin, tulos vertaa kokonaisia hakukokoonpanoja. Se on käyttöpäätöksen kannalta hyödyllistä, kunhan ero kirjataan näkyviin: pelkkää mallin vaikutusta ei silloin voi erottaa pilkkomisen vaikutuksesta.

Rakenna testi omista hakukysymyksistä

Kerää edustava joukko suomenkielisiä kysymyksiä ja merkitse kullekin dokumentit, joista vastaus todella löytyy. Mukaan tarvitaan pitkiä dokumentteja, niiden loppuun sijoittuvia vastauksia sekä läheisiä mutta vääriä osumia. Pidä arviointikysymykset erillään aineistosta, jolla säädät katkelmarajoja, jotta lopullinen tulos ei perustu samoihin kysymyksiin, joihin asetukset sovitettiin.

1. Luo kummallekin mallille oma indeksi samasta dokumenttijoukosta. Aloita samoilla katkelmarajoilla ja hakuasetuksilla, jotta vertailulle syntyy yhteinen lähtökohta.
2. Laske dokumenttitason Recall@5: kuinka suuri osuus kysymykselle merkityistä oikeista dokumenteista löytyy viiden ensimmäisen tuloksen joukosta. Yhdistä saman dokumentin katkelmat ennen laskentaa.
3. Toista koe kummallekin mallille sopivilla katkelmapituuksilla. Kirjaa osumatarkkuuden rinnalle katkelmien määrä, syötetokenit, raakavektorien koko, koko indeksin levytila ja kyselyviive.
4. Käy epäonnistuneet haut läpi: jäikö vastaus katkaisun ulkopuolelle, hajosiko asiayhteys katkelmarajalla vai sijoittuiko väärä dokumentti oikean edelle?

Valinta kannattaa tehdä parhaiten toimivan hakukokoonpanon perusteella. Lyhyisiin katkelmiin ja kuvia sisältävään aineistoon Cohere v3 voi sopia hyvin, jos oma testi löytää oikeat lähteet. Pidemmälle tekstiyhteydelle OpenAI:n suuri tekstimalli antaa enemmän tilaa. Molemmissa tapauksissa ratkaisevaa on, millä pilkkomisella oikeat dokumentit palautuvat hyväksyttävällä tilalla, viiveellä ja hinnalla.

Lue myös:

• Qdrant vai pgvector? Neljän miljoonan vektorin testi paljasti viive-eron
• GraphRAG vai vektori-RAG? Kysymyksen rakenne ratkaisee valinnan
• Power Automate vai UiPath? Vanha järjestelmä voi ratkaista valinnan