OpenTelemetry vai Langfuse? Jäljitys ei riitä arviointiin

OpenTelemetry riittää tekoälyagenttien tekniseen jäljitykseen, jos nykyinen valvontapino näyttää kutsujen kulun, viiveet, virheet ja tokenkäytön. Kun tiimin pitää yhdistää ajoihin prompttiversiot, kustannukset ja vastausten laadun arvioinnit, Langfuse on mahdollinen lisäkerros: sen OTel-integraatio vastaanottaa jälkiä ja tarjoaa LLM-kohtaisia toimintoja niiden ympärille.

Nykyistä instrumentointia ei tarvitse hylätä kummassakaan tapauksessa. Päätös riippuu siitä, riittääkö tieto siitä, missä agentin suoritus hidastui tai epäonnistui, vai pitääkö tiimin myös verrata, miten promptin muutos vaikutti vastauksen laatuun. Jälki kertoo tapahtumaketjun; laatupäätelmä tarvitsee lisäksi arviointikriteerin ja tulokset, jotka voidaan yhdistää kyseisiin ajoihin.

Mitä OpenTelemetry jo näyttää?

OpenTelemetry antaa sovellukselle yhteisen tavan tuottaa ja siirtää telemetriaa. Sen semanttiset käytännöt määrittelevät yhteisiä nimiä jälkien, metriikoiden, lokien ja resurssien tiedoille. Kun agentin mallikutsut ja työkalukutsut kuuluvat samaan jälkeen, niiden järjestystä ja kestoa voidaan tutkia nykyisessäkin APM-järjestelmässä, jos instrumentointi lähettää nämä vaiheet ja järjestelmä näyttää ne.

Myös tekoälysovelluksille on omia telemetriakenttiä. OpenTelemetryn GenAI-kuvauksessa jälki sisältää esimerkiksi mallin nimen sekä syöte- ja tulostetokenit; promptin, vastauksen ja työkalukutsun sisältö tallentuu vain, jos sisällön keruu otetaan käyttöön. Näin tokenmäärän seuraaminen ei yksin edellytä Langfusea. Näkyvyyden taso riippuu käytetystä instrumentointikirjastosta ja vastaanottavan järjestelmän näkymästä: sama kenttä voi näkyä yhdessä työkalussa selkeästi ja toisessa raakadatana.

Viisi kerrosta, kaksi erilaista tehtävää

Arkkitehtuurissa kannattaa erottaa instrumentointi, tiedonsiirto, tallennus, käyttöliittymä ja arviointi. Instrumentointi kirjaa agentin vaiheet ja niiden suhteet. Tiedonsiirto vie merkinnät vastaanottajalle, tallennus määrää niiden säilymisen ja käyttöliittymä sen, miten yksittäistä ajoa tai useiden ajojen kehitystä voi tutkia. Arviointi liittää tulokseen erikseen määritellyn laatutiedon.

OpenTelemetry koskee ennen kaikkea tiedon tuottamisen yhteisiä käytäntöjä ja sen kuljettamista. Tiimin APM-tuote hoitaa jo tallennusta ja käyttöliittymää, mutta sen LLM-näkymä voi olla suppea tai laaja. Langfuse lisää tähän oman ympäristönsä, jossa promptteja, jälkiä ja arviointituloksia voidaan käsitellä yhdessä. Sen käyttöönotto on perusteltu silloin, kun näiden yhteys on tiimin toistuva työtehtävä eikä satunnainen selvitys.

Ero näkyy esimerkiksi onnistuneessa mallikutsussa, jonka vastaus on silti käyttökelvoton. Tekninen jälki voi näyttää lyhyen vasteajan ja virheettömän suorituksen, mutta se ei päätä, oliko vastaus oikea, turvallinen tai tehtävänannon mukainen. Myös kustannustieto vaatii tokenmäärän lisäksi soveltuvan hinnoittelun ja tiedon siitä, mitä käyttöä laskelmaan sisällytetään. Nämä kysymykset kuuluvat eri kerroksiin, vaikka niitä tutkitaan saman agenttiajon yhteydessä.

Kolme tapaa rakentaa agenttien havainnointi

Nykyinen OpenTelemetry-pino

Pelkkä nykyinen pino on luonteva vaihtoehto, jos tiimi selvittää pääasiassa virheitä, hitaita työkalukutsuja, uusintayrityksiä ja mallin käyttöä. Sovellus tuottaa jäljet, Collector tai muu vientireitti toimittaa ne nykyiseen taustajärjestelmään, ja tiimi käyttää sen hälytyksiä ja näkymiä. Uusi palvelu ei tuo olennaista hyötyä vain siksi, että agentin spanit saataisiin toiseen jälkipuuhun.

Tämä vaihtoehto voi riittää myös laadun seurantaan, jos arviointiaineisto, prompttiversiot ja tulosten vertailu ovat jo toimivassa erillisessä järjestelmässä. Silloin ratkaiseva vaatimus on luotettava yhteys arviointituloksen ja alkuperäisen ajon välillä. Ilman sitä huono vastaus ja sitä edeltänyt tekninen tapahtumaketju jäävät kahteen irralliseen näkymään, vaikka molemmat olisi tallennettu.

OpenTelemetry ja Langfuse rinnakkain

Rinnakkaisessa mallissa sovellus jatkaa OTel-jälkien tuottamista, ja LLM-ajoihin liittyvä tieto viedään myös Langfuseen. Nykyinen APM säilyttää palveluketjun teknisen näkymän. Langfuseen kootaan ne ajot, joiden yhteydessä tiimi tutkii promptteja, kustannuksia ja arviointituloksia. Näin sama instrumentointiperusta palvelee kahta eri käyttötarkoitusta.

Vientisäännöillä on käytännön merkitystä. Jos suodatus lähettää Langfuseen vain mallikutsun mutta jättää agenttiajon juurispanin pois, kokonaisen suorituksen rakenne voi kadota. Samoin ajon tunnisteen ja olennaisten hakukenttien on kuljettava mukana, jotta arviointeja voidaan kohdistaa ja tuloksia ryhmitellä. Kahden tallennuspaikan mallissa on lisäksi päätettävä, mitä sisältöä kumpaankin lähetetään ja kuinka kauan sitä säilytetään.

Langfusen SDK OpenTelemetryn päällä

Pythonilla tai TypeScriptillä rakennetussa sovelluksessa Langfusen SDK voi tuottaa jäljet suoraan yhteiseen OTel-kontekstiin ja lisätä LLM-kohtaiset havainnot. Tällöin prompttilinkityksen ja pisteytyksen käsittely on lähempänä sovelluksen instrumentointia. Muilla kielillä sovellus voi lähettää OTel-jäljet Langfusen vastaanottopisteeseen ja käyttää sen muita toimintoja erillisten rajapintojen kautta.

SDK ei määrittele tiimin puolesta, mikä muodostaa kokonaisen agenttiajon tai mihin sen arviointitulos kuuluu. Mallissa on erotettava esimerkiksi ajon juurivaihe, yksittäinen malligenerointi ja työkalukutsu. Jos vain osa vaiheista kirjataan tai niiden yhteys katkeaa, valmiit käyttöliittymätoiminnotkaan eivät palauta puuttuvaa tapahtumaketjua.

Arviointipiste ei synny jälkeä lähettämällä

Langfusen suora OTel-vastaanotto tekee jäljen lähettämisestä mahdollista, mutta pisteytys on oma tapahtumansa. Langfusen siirtymäohje erottaa OTLP-jälkispanin arviointipisteestä: piste lähetetään Scores SDK:n tai rajapinnan kautta. Siksi pelkkä uuden vastaanottajan lisääminen Collector-kokoonpanoon ei vielä tuota laadun arviointeja. Tiimin on määriteltävä arvioija, arvioinnin kohde ja yhteys alkuperäiseen havaintoon.

Prompttiversion vertailu vaatii samanlaista tarkkuutta. Jos eri versioilla käsitellään erilaisia kysymyksiä, pelkkä keskimääräinen piste ei kerro muutoksen vaikutusta. Vertailun pitää yhdistää käytetty versio, syöte, vastaus ja sovittu arviointitapa. Tuotantojäljissä tämä voi tarkoittaa ihmisen antamaa arviota; hallitussa kokeessa samoja testisyötteitä voidaan ajaa usealla versiolla. Molemmissa tapauksissa jälki on tapahtuman tunniste ja konteksti, ei arvio itse.

Milloin erillinen kerros kannattaa?

Langfuse kannattaa arvioida, kun sama tiimi tutkii tuotantoajoja, ylläpitää promptteja ja seuraa vastausten laatua. Thoughtworksin Technology Radar pitää jäljityksen, arviointien ja prompttien hallinnan yhdistelmää harkinnan arvoisena itsehostattavana ratkaisuna, mutta nostaa esiin myös sen vaatiman infrastruktuurin. Etu on suurin, jos yhdistetty työnkulku korvaa useita erikseen ylläpidettäviä yhteyksiä.

Jos päätöksen kohteena ovat vain viiveet, virheet ja käyttömäärät, olemassa olevan OTel-pinon kyvykkyydet ovat ensisijainen vertailukohta. Kun päätöksen kohteena on prompttimuutoksen vaikutus vastauksiin, tarvitaan lisäksi arviointikerros. Sen voi rakentaa nykyisen pinon yhteyteen tai ottaa käyttöön Langfusen kautta; valinnan ratkaisevat tiimin jo käytössä olevat arvioinnit, tarvittava yhteys tuotantojälkiin ja uuden tallennusympäristön ylläpitotyö.

Lue myös: