Open source vs. kaupallinen puhe-AI – vertailu yritykselle

Open source puhe-AI kiinnostaa yritystä yleensä kahdesta syystä: halutaan vaikuttaa siihen, missä puheludata käsitellään, tai vähentää riippuvuutta yhdestä palveluntarjoajasta. Kaupallinen puhe-AI taas houkuttelee silloin, kun puhelinpalvelu pitäisi saada käyttöön ilman oman puheteknologiatiimin rakentamista. Kumpikin tavoite on järkevä. Minuuttihinnan rinnalle tarvitaan arvio ylläpitotyöstä ja puheluiden laadusta.

Puhebotin arki ratkaistaan muualla kuin esittelypuhelussa. Asiakas korjaa osoitettaan kesken lauseen, kalenteriyhteys katkeaa ja aamuruuhkassa puheluita tulee kerralla enemmän kuin koko edellisenä iltana. Jonkun täytyy vastata siitä, että nämä tilanteet hoituvat. Avoimen lähdekoodin ja valmispalvelun vertailu kannattaa aloittaa tästä vastuusta.

Tässä vertailussa käydään läpi, mitä itse rakennettava ratkaisu sisältää, mistä kustannukset syntyvät ja millaisella pilotilla vaihtoehtoja voi arvioida reilusti. Jos koko palvelun toimintatapa on vielä uusi, aloita puhe-AI:n palvelukuvauksesta.

Open source puhe-AI on kokonaisuus, ei yksi ladattava malli

Tavallisessa vaiheistetussa puheratkaisussa puheentunnistus muuttaa äänen tekstiksi, kielimalli käsittelee asiakkaan asian ja puhesynteesi tuottaa vastauksen äänenä. Keskustelun ohjaus huolehtii esimerkiksi vuorottelusta ja keskeytyksistä. Osa ratkaisuista käsittelee puhetta suoremmin, mutta yrityksen järjestelmäyhteydet ja puheluliikenne tarvitaan niissäkin.

Avoin lähdekoodi voi koskea vain yhtä osaa tästä ketjusta. SYSTRANin faster-whisper on esimerkiksi Whisper-puheentunnistuksen toteutus, joka käyttää CTranslate2-suoritusympäristöä. Se ei yksin tarjoa ajanvarausta hoitavaa puhelinpalvelua. Projektin ohjelmistolisenssi on MIT; muut samaan toteutukseen valitut osat on arvioitava erikseen.

LiveKit Agents puolestaan on avoimen lähdekoodin kehys reaaliaikaisille agenteille. Sen ympärille voi rakentaa keskustelulogiikkaa ja liittää mallipalveluita. LiveKitin dokumentaatio kuvaa myös itse ylläpidettävän palvelinympäristön. Nämä ovat esimerkkejä rakennusosista, eivät lupaus valmiista suomenkielisestä asiakaspalvelusta.

Avoin koodi ja avoimet mallipainot ovat eri asioita

Mallin painojen lataaminen omalle palvelimelle ei vielä tarkoita, että kaikki käyttö olisi sallittua samoilla ehdoilla kuin ympäröivässä ohjelmistossa. Koodi, mallipainot ja käytettävä ääni voivat tulla eri toimittajilta. Hankintalistaan kannattaa kirjata kunkin osan tarkka versio, lisenssi ja käyttötarkoitus. Epäselvät käyttöehdot selvitetään ennen tuotantoon siirtymistä.

Myöskään kaupallinen ei tarkoita automaattisesti suljettua. Yritys voi ostaa ylläpidetyn palvelun, joka perustuu avoimeen koodiin. Toisaalta itse ylläpidetty keskustelusovellus voi kutsua suljettua puhe- tai kielimallirajapintaa. Siksi tarjouksissa on hyödyllisempää kysyä, kuka hallitsee kutakin osaa, kuin merkitä koko ratkaisu avoimeksi tai kaupalliseksi.

Mitä pitää rakentaa mallien ympärille?

Puhelinliikenteen lisäksi tarvitaan yhteydet yrityksen tietoihin, käyttöoikeuksien hallinta ja valvonta. Jos botti varaa huoltoajan, sen on erotettava onnistunut varaus pelkästä yrityksestä lähettää varauspyyntö. Jos sama pyyntö toistuu yhteysvirheen takia, kalenteriin ei saa syntyä kahta varausta.

Nämä ongelmat kuuluvat sovelluskehitykseen riippumatta mallin lisenssistä. Pelkkä hyvä litterointi ei riitä. Ostajan kannattaa pyytää toimittajaa näyttämään koko tapahtumaketju yhdestä puhelusta: mitä asiakas pyysi, mitä järjestelmään kirjoitettiin ja mitä asiakkaalle vahvistettiin. Toimintoja suorittavan järjestelmän taustaa avaa myös artikkeli AI-agenteista puhepalvelussa.

Milloin open source puhe-AI kannattaa yritykselle?

Itse rakennettava ratkaisu on vahvimmillaan, kun yrityksellä on selkeä tarve hallita arkkitehtuuria ja myös kyky ylläpitää sitä. Syynä voi olla poikkeuksellinen järjestelmäympäristö, tarve ajaa tiettyjä osia omassa verkossa tai riittävän suuri ja ennustettava käyttömäärä. Pelkkä kokeilunhalu riittää prototyyppiin, mutta tuotantopuhelin tarvitsee nimetyn omistajan.

Kaupallinen palvelu on usein käytännöllisempi lähtökohta yritykselle, jonka oma kehitystiimi on pieni tai keskittyy muihin tuotteisiin. Valmiinkin palvelun integraatiot, keskusteluohjeet ja virhetilanteet pitää testata. Toimittajan hallintanäkymä ei tee prosessista automaattisesti toimivaa.

Vertaa päätöksiä, joita haluat itse hallita

• Jos haluat vaihtaa puheentunnistuksen mallia ilman koko palvelun vaihtoa, pyydä näyttämään, miten vaihto tehdään ja testataan.
• Jos puheluliikenteen on jatkuttava yhden palvelimen vikaantuessa, selvitä varaympäristö ja sen säännöllinen testaus.
• Jos oman tiimin pitäisi korjata keskustelulogiikkaa, tarkista pääsy tarvittavaan koodiin, asetuksiin ja testiaineistoon.
• Jos haluat ostaa valmiin lopputuloksen, sovi, kuka tutkii väärän ajanvarauksen ja kuka korjaa sen syyn.

Esimerkiksi kuvitteellinen kahdeksan hengen huoltoyritys tuskin hyötyy omasta mallipalvelimesta, jos kukaan ei ehdi päivittää sitä. Sille rajattu kaupallinen takaisinsoittopyyntöjen vastaanotto voi olla hyvä ensimmäinen kokeilu. Ohjelmistoyritys, jolla on jo ympärivuorokautinen palvelinvalvonta ja oma integraatiotiimi, voi arvioida itse ylläpidettävää osaa aivan eri lähtökohdasta.

Myös yhdistelmä on mahdollinen: yritys omistaa keskustelulogiikan ja järjestelmäyhteydet mutta ostaa puheentunnistuksen tai äänen rajapintapalveluna. Tällöin riippuvuutta voidaan rajata, mutta useamman toimittajan virhetilanteiden selvittely jää jonkun vastuulle. Yhdistelmä kannattaa valita tunnistettuun tarpeeseen, ei varmuuden vuoksi.

Läheinen hankintakysymys on valmispalvelun ja räätälöidyn AI-ratkaisun vertailu. Toteutuksen räätälöitävyys ja lähdekoodin avoimuus eivät tarkoita samaa asiaa.

Kustannusvertailu: laske myös ylläpito ja epäonnistuneet puhelut

Avoimen ohjelmiston lisenssimaksu voi olla nolla, mutta laskenta ja työ eivät ole ilmaisia. Laske mukaan käyttöönotto, palvelimet, puhelinliikenne, mahdolliset mallirajapinnat ja ylläpito. Kaupallisessa vaihtoehdossa osa näistä voi sisältyä palvelumaksuun, osa tulla erikseen. Vertailussa tarvitaan sama rajaus molemmille.

Yksinkertainen laskentamalli on: kuukausikustannus = käyttöönoton kuukausiosuus + kiinteät palvelukulut + käyttöön perustuvat kulut + oman työn kustannus. Valitse käyttöönotolle sama tarkastelujakso. Kirjaa myös, lasketaanko oman henkilöstön aika sisäisellä tuntikustannuksella vai ostotyön hinnalla.

Havainnollistava laskelma, ei markkinahinta

Oletetaan kuvitteellinen palvelu, jossa puheluaikaa kertyy 3 000 minuuttia kuukaudessa. Seuraavat summat ovat laskuharjoituksen oletuksia. Ne eivät ole Aisterin hinnasto, palveluntarjoajan tarjous tai ennuste tietyn teknologian kustannuksista.

Itse ylläpidettävän vaihtoehdon käyttöönotoksi oletetaan 9 600 euroa. Kahdelletoista kuukaudelle jaettuna se on 800 euroa kuukaudessa. Laskenta, puhelinliikenne ja muut palvelukulut maksavat oletuksessa yhteensä 450 euroa. Ylläpitoon kuluu 12 tuntia kuukaudessa, ja laskennallinen työkustannus on 80 euroa tunnilta. Yhteensä kuukausikustannukseksi tulee 2 210 euroa eli noin 0,74 euroa puheminuutilta.

Kaupallisen vaihtoehdon käyttöönotoksi oletetaan 2 400 euroa eli samalla jaksolla 200 euroa kuukaudessa. Kiinteä palvelumaksu on oletuksessa 300 euroa ja käytön kustannus 0,18 euroa minuutilta eli 540 euroa. Oman tiimin työtä kuluu neljä tuntia, yhteensä 320 euroa. Kuukausisumma on 1 360 euroa eli noin 0,45 euroa minuutilta. Tässä laskelmassa käyttöveloituksen oletetaan sisältävän puhelin- ja mallikulut; oikeassa tarjouksessa asia pitää tarkistaa.

Näillä oletuksilla valmispalvelu on halvempi. Jos oman ratkaisun ylläpitotyö vähenee, kustannusero pienenee. Jos käyttö kasvaa, myös palvelinkapasiteetti, samanaikaiset puhelut ja kaupallisen palvelun hinnoittelu on laskettava uudelleen. Kolmen tuhannen minuutin laskelmaa ei voi vain kertoa kymmenellä ja olettaa arkkitehtuurin säilyvän samana.

Ratkaistu asia on minuuttia parempi loppumittari

Puheminuutin hinta auttaa budjetoinnissa. Hankintapäätöksessä tarvitset lisäksi kustannuksen oikein hoidetusta asiasta. Jos edullinen botti tuottaa paljon korjattavia varauksia, säästö siirtyy henkilöstön jälkityöksi. Vastaavasti lyhyt puhelu voi tarkoittaa joko tehokasta palvelua tai sitä, että asiakas luovutti.

Kirjaa pilotissa, kuinka moni tavoitteen piiriin kuuluva asia hoitui oikein ilman korjaustyötä. Laske kokonaiskulut ja jälkityö näitä onnistuneita tapauksia kohti. Asiakkaan perusteltu siirtäminen ihmiselle on erotettava virheestä: esimerkiksi poikkeuksellinen reklamaatio voi aivan tarkoituksella kuulua työntekijälle.

Data, tuki ja toimittajan vaihto pitää tehdä näkyviksi

Itse ylläpidetty sovellus ei takaa, että puhelun sisältö pysyy omassa ympäristössä. Se voi lähettää ääntä puheentunnistuspalveluun, tekstiä kielimallille ja virhelokeja valvontapalveluun. Piirrä tietovirrat jokaiselle vaihtoehdolle samalla tarkkuudella. Merkitse myös varmuuskopiot ja tukihenkilöstön pääsy, älä ainoastaan pääasiallista palvelinta.

Kaupalliselta toimittajalta kannattaa pyytää kirjallinen kuvaus tietojen käsittelypaikoista, säilytysasetuksista ja poistamisesta. Eri tuotteiden ominaisuudet eivät ole keskenään identtisiä. Esimerkiksi ElevenLabsin agenttikohtaisen Zero Retention Moden ohje kuvaa säilytyksen rajoittamista ja huomauttaa, että vähäinen puheludata voi vaikeuttaa ongelmien selvittämistä. Asetus on siis sovitettava myös valvonnan tarpeisiin; se ei yksin kuvaa koko yrityksen tietovirtoja.

Kuka reagoi, kun palvelu toimii väärin?

Palvelun saatavuus ja oikea toiminta ovat eri asioita. Rajapinta voi vastata normaalisti samalla, kun botti käyttää vanhentunutta aukioloaikaa. Sopimuksessa ja sisäisessä vastuunjaossa pitää erottaa infrastruktuurin häiriö, mallin ongelma ja yrityksen oman tietopohjan virhe. Jokaiselle tarvitaan henkilö tai tiimi, joka voi tehdä korjauksen.

Pyydä esimerkki häiriömenettelystä: mistä virhe huomataan, kenelle ilmoitus menee ja miten puhelut ohjataan siksi aikaa ihmiselle tai takaisinsoittopalveluun. Tarkista myös, mitä tuki kattaa iltaisin. Yhteisön keskustelupalsta voi auttaa teknisessä ongelmassa, mutta se ei ole sovittu päivystysvuoro.

Miten toimittajan vaihto onnistuisi?

Omasta lähdekoodista voi olla hyötyä palveluntarjoajaa vaihdettaessa, mutta keskustelujen ohjeet, integraatiot ja äänet voivat silti sitoa ratkaisuun. Selvitä jo hankintavaiheessa, missä muodossa saat asetukset ja tarvitsemasi tiedot ulos. Varmista myös oikeus käyttää niitä seuraavassa toteutuksessa.

Käytännöllinen testi on vaihtaa pilotissa yksi osa: esimerkiksi puheentunnistus tai mallirajapinta. Kirjaa, mitä jouduttiin muuttamaan ja miten laatu muuttui. Jos vaihto vaatii koko keskustelun kirjoittamisen uudelleen, arkkitehtuuri ei ole niin helposti vaihdettava kuin laatikkokaavio antaa ymmärtää.

Puhelupalvelun rajauksia käsitellään myös artikkelissa tekoälyn etiikasta puhepalveluissa. Asiakkaan mahdollisuus saada apua ihmiseltä kuuluu suunnitteluun toteutustavasta riippumatta.

Testaa open source puhe-AI ja valmispalvelu samalla tehtävällä

Reilu pilotti alkaa yhdestä rajatusta tehtävästä, esimerkiksi huollon takaisinsoittopyynnön vastaanotosta. Anna molemmille vaihtoehdoille sama tietopohja, sallitut toiminnot ja siirtosäännöt. Käytä keksittyjä asiakastietoja. Jos toisella ratkaisulla testataan vain siistiä esittelykeskustelua ja toisella vaikeita puheluita, tulokset eivät ole vertailukelpoisia.

Valitse testit yrityksen todellisista tilanteista. Mukaan tarvitaan tavallisen pyynnön lisäksi nimen tavaaminen, numeron korjaus, puheen keskeyttäminen, taustamelu ja asiakkaan pyyntö puhua ihmiselle. Testaa myös järjestelmäkatko: botti ei saa vahvistaa varausta, jota kalenteriin ei syntynyt.

Mittaa koko puhelu ja sen jälki

Puheentunnistuksen sanavirheet ovat teknisesti kiinnostavia, mutta asiakaspalvelussa yksi väärä puhelinnumero voi olla kymmentä täytesanan virhettä vakavampi. Tarkista siksi kerätyt tiedot kenttä kerrallaan ja seuraa, päätyivätkö ne oikein kohdejärjestelmään. Kuuntele myös, pyytääkö botti epäselvän tiedon uudelleen vai arvaako se.

Mittaa vastausviive asiakkaan puheenvuoron lopusta siihen, kun botin vastaus kuuluu. Raportoi mediaanin lisäksi hitaat tapaukset, esimerkiksi 95. persentiili. Testaa arvioitu ruuhka erikseen: yksi toimiva puhelu ei osoita, että kymmenen samanaikaista puhelua toimii yhtä hyvin.

Päätä hyväksymisehdot ennen tulosten katsomista. Virheellinen ajanvarauksen vahvistus voi olla käyttöönoton estävä virhe, vaikka ääni kuulostaisi erinomaiselta. Aloitusviestin pieni tyyliero taas voi olla korjattavissa ilman uutta arkkitehtuuria. Pidä nämä eri luokissa, jotta miellyttävä demo ei peitä toiminnallista puutetta.

Pieni pilotti auttaa löytämään virheitä, mutta sen perusteella ei kannata luvata koko vuoden ratkaisuastetta. Dokumentoi puhelumäärä, käytetyt tilanteet, samanaikainen kuorma ja tehdyt korjaukset. Pilotoinnin käytännön opas auttaa rajaamaan kokeilun ennen laajempaa käyttöönottoa.

Valitse vastuun ja näytön perusteella

Aloita kaupallisesta ratkaisusta, jos tärkein tavoite on saada rajattu palvelu käyttöön eikä omalla tiimillä ole aikaa ylläpitää puheinfrastruktuuria. Selvitä avoimen lähdekoodin toteutus, jos tarvitset sen tarjoamaa hallintaa ja pystyt nimeämään ylläpidosta vastaavan tiimin. Yhdistä osia silloin, kun yhdistelmä ratkaisee konkreettisen ongelman.

Päätöksen pohjaksi riittää aluksi selkeä tehtäväkuvaus, samalla tavalla rajattu kustannuslaskelma ja vertailukelpoiset testitulokset. Jos vaihtoehtojen rajaaminen on hankalaa, ota yhteyttä Aisteriin. Keskustelun lähtökohdaksi kannattaa tuoda puhelumäärä, hoidettava tehtävä ja käytössä olevat järjestelmät. Niistä selviää enemmän kuin valmiista suosikkimallista.