Michael JohnsonKaksi palvelua voi lähettää mallille saman määrän pyyntöjä mutta aiheuttaa hyvin erilaisen kuormituksen. Cohere ehdottaa 9. lokakuuta julkaistussa Embed- ja Rerank-palveluiden oppaassaan jaetun tai omistetun käsittelyn valintaa pyyntöjen muodon, kuormituksen ajallisen jakautumisen ja viivevaatimusten perusteella. Kyseessä on käytännön infrastruktuurianalyysi, ei uuden hinnoittelumallin tai tuotteen julkistus.
Hakua ja RAG-järjestelmiä rakentaville tiimeille havainto on tärkeä indeksoinnin ja käyttäjäpyyntöjen suunnittelussa: kutsujen määrä ei yksin kuvaa laskennan määrää hyvin. Yksi suuri dokumenttien upotusvektoreiden muodostamiseen tarkoitettu erä voi kuluttaa enemmän resursseja kuin lukuisat lyhyet hakupyynnöt.
Miksi pyyntömäärä minuutissa johtaa harhaan
Upotusvektorit muuntavat tekstit numeerisiksi esityksiksi, joita hakujärjestelmä käyttää semanttiseen vertailuun. Luetteloa aluksi indeksoitaessa sovellus voi lähettää suuria kuvailueriä; tavallisessa haussa malli saa lyhyen hakutekstin. Näillä tehtävillä on erilaiset vaatimukset: eräkäsittelyä arvioidaan yleensä läpimenon ja kustannusten perusteella, kun taas haussa ratkaisee käyttäjälle näkyvä vastausaika.
Rerank-palvelussa tärkeä lisätekijä on se, kuinka monta ehdokasta järjestelmä antaa mallille uudelleenjärjestettäväksi. Cohere havainnollistaa asiaa vertaamalla lyhyttä hakua 50 dokumenttiin; yrityksen arvion mukaan käsittely vastaa noin 11 000 tokenia. Ehdokkaiden määrän kasvattaminen lisää työmäärää, vaikka käyttäjien hakujen tiheys pysyisi samana.
Mitä Coheren laskelmat osoittavat
Artikkelissa esitetään suuntaa-antavia kannattavuusrajoja, joissa käyttöperusteisesta hinnoittelusta siirrytään omistettuun kapasiteettiin: noin 20 pyyntöä minuutissa, kun indeksoidaan 100 noin 200 tokenin tekstiä eränä; noin neljä pyyntöä minuutissa pidempien dokumenttien kohdalla; ja noin 29 pyyntöä minuutissa kuvatussa Rerank-skenaariossa. Lyhyiden hakutekstien upotusvektorien muodostamisessa kirjoittajat arvioivat rajan olevan kymmeniä tuhansia pyyntöjä minuutissa.
Luvut perustuvat tiettyihin oletuksiin: yhteen NVIDIA A10 -näytönohjaimeen, ympärivuorokautiseen täyden käyttöasteen toimintaan, mainittuihin pyyntökokoihin ja julkaistuihin hintoihin. Cohere huomauttaa erikseen, että kuvaajat ja raja-arvot muuttuvat, jos käyttöaika, laitteistokokoonpano, alennukset tai dokumenttien määrä ovat erilaisia. Lukuja kannattaa pitää laskentatavan havainnollistuksena, ei yleispätevinä ohjearvoina.
Valintaperiaate soveltuu silti esimerkkejä laajemmin. Ennustettava ja jatkuva kuormitus voi hyödyntää varattua kapasiteettia paremmin, kun taas lyhyet kuormituspiikit pitkine hiljaisine jaksoineen sopivat usein käyttöperusteiseen hinnoitteluun. Vuorovaikutteisessa haussa on myös tarkistettava viive odotetulla kuormituksella: laitteiston suurin läpimeno ei takaa tavoiteltua vastausaikaa käytännössä.
Näin sovellat analyysiä omaan hakuusi
Mittaa ennen vaihtoehtojen vertailua muutamia asioita todellisesta liikenteestä: tokenien ja dokumenttien määrä pyyntöä kohden, indeksointierien koko, uudelleenjärjestettävien ehdokkaiden määrä, kuormitushuippujen kesto ja tavoiteviive. Laske sitten kustannukset todellisen käyttörytmin perusteella, älä pelkästään pyyntöjen keskimääräisen määrän mukaan. Tarkista ajantasaiset hinnat ja käyttöehdot Coheren hinnastosivulta: omistettu malli ja käyttöperusteinen käsittely hinnoitellaan eri tavoin.
Yhdistetyssä hakujärjestelmässä eri vaiheet kannattaa arvioida erikseen: taustalla tehtävä luettelon uudelleenindeksointi, lyhyet käyttäjähaut ja ehdokkaiden uudelleenjärjestely. Näin voi selvittää, kannattaako käyttää yhtä infrastruktuuria vai toteuttaa konveijerin eri osat eri käyttöönottomalleilla. Coheren julkaisun käytännön viesti on yksinkertainen: mittaa ensin, kuinka paljon työtä kukin pyyntö aiheuttaa, ja valitse vasta sitten hinnoittelu- ja resurssimalli.