Monivuoroinen LLM-arviointi: 5 mittaria, 3 kehystä, 1 workflow

Monivuoroinen LLM-arviointi: 5 mittaria, 3 kehystä, 1 workflow

Monivuoroinen LLM-arviointi on ainoa tapa havaita vuoron 8 muistibugi: käyttäjä antoi tilausnumeronsa vuorossa 3, ja botti kysyy sitä uudelleen. Jokainen yksittäinen vuoro läpäisi testin erillään, mutta keskustelu epäonnistui silti. DeepEval 4.0 ja RAGAS 0.4 julkaisivat juuri tätä varten omat keskusteluarvioinnin API:nsa, ja kahden Techsyn omassa putkessa sattuneen arviointivälikohtauksen jälkeen tässä ovat viisi mittaria, kolme kehystä ja yksi workflow, joista kannattaa aloittaa.

Keskeiset opit

• Monivuoroinen arviointi pisteyttää kokonaisia keskusteluja, ei erillisiä syöte-tuloste-pareja.
• Yksivuoroisten benchmarkien kärkimallit heikkenevät mitattavasti keskustelun vuorojen edetessä.
• Aloita neljällä mittarilla: täydellisyys, tiedon säilyttäminen, roolissa pysyminen, vuoron relevanssi.
• DeepEval, RAGAS ja Langfuse ratkaisevat monivuoroisen arvioinnin eri tavoin; alla oleva kehystaulukko vertailee niitä.

Miksi yksivuoroiset tulokset valehtelevat?

Yksivuoroiset arvioinnit pisteyttävät yhden syöte-tuloste-parin kerrallaan, eivätkä siksi näe vuorojen välisiä häiriöitä: unohtamista, ristiriitoja, ajautumista. Malli voi saavuttaa vahvan benchmark-tuloksen ja silti menettää juonen käynnissä olevassa keskustelussa. Laban ja muut dokumentoivat tämän artikkelissa LLMs Get Lost In Multi-Turn Conversation, 353 sitaattia: suorituskyky heikkenee monivuoroisissa tilanteissa, vaikka yksivuoroiset tulokset näyttäisivät terveiltä.

Ydinongelma on epädeterministisyys: n:s vastaus riippuu kaikista n-1 aiemmasta vuorosta, joten identtiset promptit käyttäytyvät eri tavalla historian perusteella. Erillisistä pareista koostuva data-aineisto ei koskaan testaa tätä riippuvuutta. arXiv-katsaus Evaluating LLM-based Agents for Multi-Turn Conversations, noin 250 lähteen PRISMA-katsaus, jakaa alan siihen, mitä arvioidaan (kontekstin hallinta, suunnittelu, johdonmukaisuus), ja siihen, miten (mittarit, LLM-tuomarit, ihmisten arviointi). Molemmat ulottuvuudet puuttuvat yksivuoroisesta testisarjasta.

Mikään tästä ei tee yksivuoroisesta pinostasi hyödytöntä. Jos käytät yksivuoroisia mittareita kuten BLEU, ROUGE ja G-Eval, pidä ne siihen, mitä ne mittaavat hyvin: formaatin noudattaminen, toksisuus, faktamuisti kiinteällä promptilla. Lopeta vain niiden lukeminen sen keskustelun terveystarkastuksena, jota käyttäjäsi käyvät.

Tulkintamme näistä tutkimuksista yhdellä rivillä:

Yksivuoroinen arviointi mittaa vastausta, monivuoroinen arviointi mittaa keskustelua, ja ensimmäisen vuoron läpäisevä malli voi olla eksyksissä viidenteen vuoroon mennessä.

Mitä monivuoroinen LLM-arviointi on? Kaksi arviointitapaa

Monivuoroinen LLM-arviointi tarkoittaa koko keskustelun tai sen ikkunoiden pisteyttämistä erillisten prompti-vastaus-parien sijaan. Se kysyy, säilyttikö malli kontekstin, pysyikö se roolissaan ja ratkaisiko se käyttäjän ongelman vuorojen aikana. Työtä tekee kaksi tapaa: keskustelutason pisteytys ja liukuvan ikkunan vuorotason pisteytys, ja useimmat tiimit ajavat molempia.

Keskustelutason pisteytys antaa tuomarille koko transkriptin ja kysyy yhtä kysymystä: onnistuiko tämä keskustelu? Se havaitsee ennenaikaiset lopetukset ja ratkaisemattomat luupit, koska vain koko säie paljastaa, ettei käyttäjä saanut palautustaan. Sen heikkous on rakeisuus: "epäonnistui" 12 vuoron säikeessä ei kerro, missä kohtaa asiat menivät rikki.

Liukuvan ikkunan vuorotason pisteytys liikuttaa N vuoron ikkunaa transkriptin yli, yksi tuomio per ikkuna. Ikkuna 3 kymmenen vuoron keskustelussa tuottaa 8 tuomiota, jotka sitoutuvat keskustelun alueisiin, joten "epäonnistui" saa koordinaatit: katkos tapahtui vuoroissa 6–8. Tämän artikkelin yläosassa oleva kaavio näyttää molemmat tavat samassa säikeessä: hakasulje keskustelutuomiolle, liukuva kehys ikkunatason tuomioille.

Käytä keskustelutason pisteytystä porttina ja ikkunapisteytystä paikantamaan häiriöt, kun portti kaatuu. DeepEvaluin monivuoroisen arvioinnin opas määrittelee työyksiköksi skenaarion eikä syöte-tuloste-paria (sen ConversationalGolden-tyyppi): testaat tilannetta, et kysymystä.

Havainne-esimerkki (synteettinen; näyttää mekaniikan, ei todellista ajoa): liukuva ikkuna 3 kahdeksan vuoron palautuspyyntökeskustelussa.

Turn 1  user:      I want to return an order that arrived damaged.
Turn 2  assistant: Sorry about that. Can you share the order number?
Turn 3  user:      It's #4471.
Turn 4  assistant: Got it. Damaged on arrival, or after use?
Turn 5  user:      On arrival. The screen was cracked.
Turn 6  assistant: Understood. Replacement or refund?
Turn 7  user:      Refund. How long does that take?
Turn 8  assistant: 3-5 business days. Can you share the order number again?

Keskustelutason tuomio: hylätty. Viisi kuudesta ikkunasta läpäisi, ja silti säie katkesi tiedon säilyttämiseen, täsmälleen siihen häiriöön, jota yksivuoroinen testisarja ei koskaan tuo esiin.

Mitkä monivuoroiset mittarit merkitsevät? Nämä 5

Aja ensin neljää mittaria: keskustelun täydellisyys, tiedon säilyttäminen, roolissa pysyminen ja vuoron relevanssi. Lisää viides, oma kriteeri (DeepEvalissa G-Eval, RAGASissa AspectCritic) sille, mitä tuotteesi ei voi tehdä väärin. Ensimmäiset neljä siirtyvät projektista toiseen; viides on siellä, missä sinun häiriötyyppisi elävät.

1. Keskustelun täydellisyys. Tuliko käyttäjän tavoite ratkaistuksi, vai julistiko botti voiton liian aikaisin? Ennenaikaisen lopetuksen tunnistin.
2. Tiedon säilyttäminen. Muistaako malli aiemmin säikeessä kerrotut faktat? Vuoron 8 muistibugi on tiedon säilyttämisen häiriö.
3. Roolissa pysyminen. Pysyykö assistentti persoonassaan ja kieltäytyykö sen ulkopuolisista pyynnöistä? Kriittinen, jos botilla on compliance-raja.
4. Vuoron relevanssi. Onko jokainen vastaus aiheellinen edelliset vuorot huomioiden? Havaitsee ajautumisen ja luupit.
5. Oma kriteeri. Yksi arkikielinen sääntö omalle alallesi: "älä koskaan sano hintaa, joka poikkeaa hinnastosta." DeepEval toteuttaa tämän nimellä ConversationalGEval; RAGAS nimellä AspectCritic.

DeepEvaluin mittariopas määrittelee jokaisen ajettavalla luokalla, mutta käsitteet ovat kehysriippumattomia: taulukko pätee, vaikka rakentaisit tuomarin itse.

Oma kriteeri luetaan kuin lause:

criterion "price_accuracy":
  question: Does the assistant quote prices matching the official
            list, and self-correct when the user flags a mismatch?
  scale: 0 (wrong, no correction) to 1 (correct throughout)
  verdict: pass if score >= 0.5

Sama sääntö oikeana DeepEval-koodina:

from deepeval.metrics import ConversationalGEval
from deepeval.test_case import LLMTestCaseParams

price_accuracy = ConversationalGEval(
    name="Price Accuracy",
    criteria=(
        "Does the assistant quote prices that match the official "
        "price list, and correct itself immediately when the user "
        "points out a discrepancy?"
    ),
    evaluation_params=[
        LLMTestCaseParams.INPUT,
        LLMTestCaseParams.ACTUAL_OUTPUT,
    ],
    threshold=0.5,
)

DeepEval vs RAGAS vs Langfuse: mikä kehys sopii?

Kaikki kolme arvioivat monivuoroisia keskusteluja, mutta niiden arviointiyksikkö eroaa: DeepEval simuloi skenaarioita offline-tilassa, RAGAS pisteyttää jo olemassa olevien keskustelujen osa-alueita, ja Langfuse arvioi oikeita tuotantojälkiä. Valitse sen mukaan, mistä keskustelusi tulevat, älä ominaisuuksien määrän perusteella.

Ensin kehysriippumaton logiikka, jotta alla oleva toimittajakoodi on siirrettävissä:

for scenario in scenario_set:
    transcript = run_chatbot(scenario, max_turns=10)
    for window in sliding_windows(transcript, 3):
        scores.append(judge(window, criteria))
    scores.append(judge(transcript, completeness))
fail_if(mean(scores) < baseline - tolerance)

DeepEval: skenaariot ja täysin varusteltu simulaattori

DeepEval on ainoa, jolla on ensiluokkainen keskustelusimulaattori: kuvaa skenaario ja persona, ja se näyttelee käyttäjää bottiasi vastaan. Sen monivuoroinen opas on vakiintunut lähde skenaario-ei-pareja-mallille. Confident AI myy hostattua kojelautaa; Confident AI -arviomme käsittelee sitä, mitä maksullinen taso lisää.

from deepeval.dataset import ConversationalGolden
from deepeval.synthesizer import ConversationSimulator
from deepeval.metrics import (
    ConversationCompletenessMetric,
    KnowledgeRetentionMetric,
)
from deepeval import evaluate

scenario = ConversationalGolden(
    additional_context="Customer wants to return a damaged order",
    user_persona="Impatient customer, second contact this week",
)
simulator = ConversationSimulator(model="gpt-4o-mini", max_turns=10)
test_case = simulator.simulate(scenario, your_chatbot_fn)

evaluate(
    test_cases=[test_case],
    metrics=[
        ConversationCompletenessMetric(threshold=0.7),
        KnowledgeRetentionMetric(threshold=0.7),
    ],
)

RAGAS: virheanalyysivetoinen, osa-alue kerrallaan

RAGAS aloittaa keskusteluista, jotka sinulla jo on, ja pisteyttää ne osa-alue kerrallaan. Sen monivuoroinen how-to toimii parhaiten manuaalisen virheanalyysin kanssa: lue epäonnistuneet keskustelut, kirjoita AspectCritic jokaista häiriötyyppiä kohden, pisteytä.

from ragas.dataset_schema import MultiTurnSample
from ragas.metrics import AspectCritic
from ragas.llms import llm_factory

user_input = [
    {"role": "user", "content": "Can I return a damaged order?"},
    {"role": "assistant", "content": "Yes, within 30 days."},
    {"role": "user", "content": "It arrived broken. Do I pay shipping?"},
    {"role": "assistant", "content": "No, we cover it."},
]
sample = MultiTurnSample(user_input=user_input)

critic = AspectCritic(
    name="policy_consistency",
    definition="Does the assistant stay consistent with the stated return policy across all turns? Answer yes or no.",
    llm=llm_factory("gpt-4o-mini"),
)
score = await critic.multi_turn_ascore(sample)  # binary 0 or 1

Langfuse: N+1-arviointi oikeilla jäljillä

Langfuse kulkee päinvastaista tietä: tracer ensin. Sen N+1-cookbook arvioi kunkin vuoron jäljen sekä keskustelun kokonaisuutena, tuotantoliikenteellä eikä simulaatioilla. Jos olet vielä valitsemassa havainnointikerrosta, Langfuse vs LangSmith -vertailumme käsittelee sitä päätöstä.

Tuomiomme, ilman aidalla istumista: uuteen chatbottiprojektiin aloita DeepEvalilla. Simulaattorilla voit estää regressiot ennen kuin sinulla on tuotantoliikennettä, juuri silloin kun testejä eniten tarvitset. Lisää Langfuse, kun oikeita säikeitä on olemassa; tartu RAGASiin, kun tiimisi haluaa mieluummin lukea epäonnistuneita keskusteluja ja koodata havaintonsa.

Miten virheanalyysistä päästään automaatioon?

Vaiheistamalla. Lue 20–30 oikeaa keskustelua, merkitse häiriötyypit käsin, kirjoita binääriset läpi/hylätty-tarkistukset ilmiselville, automatisoi ne, ja lisää vasta sitten LLM-tuomaroituja mittareita subjektiiviselle jäännökselle. Hamel Husain perustelee täsmälleen tätä järjestystä: ensin manuaalinen virheanalyysi ja binääriset päätökset, koska tarkistus, jonka osaat selittää, voittaa pisteen, jota et osaa.

Binäärinen ennen tuomaria: vaiheistus, joka pelasti meidät

Tämä ei ole ajamamme chatbottibenchmark; se on tulkintamme samasta kuviosta omassa sisällöntuotantoputkessamme, joka ajaa arvioinnilla estettyjä regressiotarkistuksia jokaisella prompt- ja työkalumuutoksella. Kaksi välikohtausta todisti vaiheistuksen meille.

2026-06-13 uudelleenjulkaisubugi loi uusia lokalisoituja slugeja ja julkaisi 54 päällekkäistä live-dokumenttia. Löysimme ja poistimme ne julkaisusta 2026-07-05 (varmuuskopio: techsy.io/seo-reports/2026-07-05/deleted_docs_backup.json). Korjaus ei ollut älykkäämpi malli; se oli deterministinen julkaisua edeltävä tarkistus: ratkaise olemassa oleva dokumentti kanonisen postauksen ja kielen perusteella ennen mitään luontia. Binäärinen portti.

Toinen välikohtaus: kääntäjä-LLM:t tuottavat toisinaan ASCII:ta Unicoden sijaan, jolloin "karşılaştırma" muuttuu muotoon "karsilastirma." Tuomaria ei tarvita; grep-portti havaitsee sen:

grep -cP '[çşğüöıİŞÇĞÜÖ]' file.md   # must be > 0

Molemmat havaittiin tarkistuksilla, jotka maksavat sentin murto-osia ja tulostavat tarkalleen, miksi ne epäonnistuivat. Sovella tätä monivuoroiseen arviointiin: "kysyikö botti uudelleen kenttää, jonka käyttäjä jo antoi?" on merkkijonovastine transkriptiin, ei tuomarikutsu. Aja halvat deterministiset portit ensin; ne havaitsevat rumat häiriöt ennen kuin kallis tuomarisi edes käynnistyy.

Milloin LLM-tuomari on oikeasti oikea työkalu

Tuomarit ansaitsevat tokenhintansa kriteereillä, joita ei voi palauttaa sääntöön: "oliko sävy sopivan anteeksipyytävä?", "sopiko ratkaisu tilanteeseen?" Jos osaat kirjoittaa assertionin, kirjoita assertion. Arviointiohje, joka on täynnä harkintaa, kuuluu tuomarille.

Raja, johon palaamme jatkuvasti:

Aloita binäärisillä läpi/hylätty-tarkistuksilla, jotka osaat selittää tiimikaverille, ja lisää LLM-tuomarit vasta sille, mitä et voi palauttaa sääntöön.

Miten keskusteluja simuloidaan skaalassa, ja mitä tuomarointi maksaa?

Simuloi skenaarioista, älä viedyistä lokeista. Skenaariot testaavat, mitä voi tapahtua; lokit näyttävät vain, mitä nykyinen järjestelmäsi jo salli. DeepEvaluin ohjeistus varoittaa, että historialliset keskustelut ovat niitä tuottaneen järjestelmän muovaamia, joten niiden vastaan benchmarkkaaminen lukitsee nykytilan.

Skenaarioita, ei transkripteja

Kirjoita jokainen skenaario tavoitteena ja persoonana: "kärsimätön asiakas palauttamassa vioittunutta tilausta", "käyttäjä, joka muuttaa mielensä varauksen aikana". Aseta vuorokatto (10 on järkevä) ja lopetusehto: tavoite saavutettu, käyttäjä hylkää, tai katto. DeepEval suosittelee vähintään 20 erilaista skenaariota pääkäyttötapauksissa, reunatapauksissa ja häiriöalttiissa tilanteissa; alle sen testisarjasi mittaa anekdootteja.

Adversariaaliset personat

Sisällytä personat, jotka yrittävät rikkoa botin: vihainen käyttäjä, joka eskaloi, hämmentynyt käyttäjä, joka on itsensä kanssa ristiriidassa, injektio-käyttäjä, joka ujuttaa ohjeita vuoroon 4. Monivuoroinen injektio on oma lajinsa; LLM-guardrails-oppaamme käsittelee puolustuskerrosta, joka liittyy näihin testeihin, ja Langfusen simulaatio-cookbook näyttää käyttäjäsimulaattorisilmukan.

Mitä 100 arvioitua keskustelua maksaa

Jokainen alla oleva luku on arvio ilmoitetuista tokenmääristä ja julkisista hinnoista, ei ajamamme mittaus. Laskutoimitus on pointti: vaihda omat lukusi.

Alle dollari sadasta täysin tuomaroidusta keskustelusta. Kalliimpi tuomari siirtää tätä 10–50-kertaiseksi, ja LLM API -kustannusten vähentäminen -oppaamme keinot pätevät: tallenna kriteeriteksti välimuistiin, eristä ikkunat eräajoihin, käytä halpaa mallia binäärisille porteille.

6-vaiheinen monivuoroisen arvioinnin workflow

Silmukka toimii näin: määrittele skenaariot oikeista häiriöistä, valitse neljä ydinmittaria plus yksi oma, simuloi vähintään 20 skenaariota, aseta nykyversiolle baseline, estä regressiot CI:ssä ja syötä tuotantohäiriöt takaisin skenaariojoukkoon.

1. Määrittele skenaariot häiriöistä. Lue 20–30 transkriptiä (tai ennen julkaisua kirjoita ne tukitiketeistä). Jokainen skenaario saa tavoitteen, personan ja vuorokaton. Vastuulla: sinä ja Hamelin virheanalyysi ensin -metodi.
2. Valitse neljä mittaria, yksi oma. Täydellisyys, tiedon säilyttäminen, roolissa pysyminen, vuoron relevanssi ja yksi ConversationalGEval tai AspectCritic alasi kalliille virheelle.
3. Simuloi. Aja vähintään 20 skenaariota mukaan lukien adversariaalinen joukko. Vastuulla: DeepEvaluin ConversationSimulator tai Langfusen simulaatio-cookbook.
4. Aseta nykyversiolle baseline. Tallenna mittarikohtaiset keskiarvot kolmen ajon yli, koska mallit ovat epädeterministisiä ja yksittäinen ajo on kohinaa. Vastuulla: arviointiskriptisi, tulokset commitoidaan repoon.
5. Estä regressiot CI:ssä. Aseta kynnys mittaria kohden ja kaada build, jos regressio ylittää toleranssin:

# ci/multi-turn-eval-gate.sh
set -euo pipefail
python eval/run_multi_turn.py --scenarios eval/scenarios.yaml --out results.json
SCORE=$(jq -r '.aggregate.completeness' results.json)
BASELINE=0.82
TOLERANCE=0.03
if (( $(echo "$SCORE < $BASELINE - $TOLERANCE" | bc -l) )); then
  echo "FAIL: completeness $SCORE below baseline $BASELINE"
  exit 1
fi

1. Seuraa tuotantosäikeitä. Ryhmittele live-jäljet säikeittäin, arvioi asynkronisesti ja muuta jokainen epäonnistunut säie uudeksi skenaarioksi. Vastuulla: Langfuse tai tracerisi; oppaamme AI-agenttien arvioinnista tuotannossa ja AI-havainnoinnista käsittelevät valvontapuoliskoa.

Testisarja ei ole koskaan valmis: vaihe 6 ruokkii vaihetta 1, ja skenaariojoukko kasvaa jokaisella havaitsemallasi tuotantohäiriöllä.

Miten sävyä arvioidaan kielten välillä?

Englanninkielisellä datalla viritetty roolissa pysymisen mittari läpäisee turkin- tai japaninkielisen transkriptin, jota äidinkielinen puhuja pitää töykeänä, koska kohteliaisuusrekisteri on kielisidonnainen. Englanninkielisessä arviointiohjeessasi ei ole sille sanoja. Korjaus: yksi osa-aluemitari jokaista rekisteriodotusta kohden, kirjoitettuna kielittäin, ei yhtä globaalia sävyn mittaria.

Yksi kriteeri per rekisteri

Tulkintamme RAGASin AspectCritic-kuviosta, laajennettuna 23 kielen putken pyörittämisestä, ei julkaistusta testituloksesta:

English:  "Is the assistant's tone friendly but professional?"
Turkish:  "Does the assistant use formal 'siz' address consistently,
           and avoid casual verb forms with an upset customer?"
Japanese: "Does the assistant keep keigo (polite form) throughout,
           including the apology at the resolution turn?"

Jokainen kriteeri on oma binäärinen kriitikkonsa samalla transkriptillä. Emme ole julkaisseet kieltenvälisiä sävypisteitä, emmekä luottaisi artikkeliin, joka tulostaa ne ilman arviointiohjetta. Putkityöstä: häiriöt kasautuvat anteeksipyynnön ja eskalaation vuoroihin, joissa rekisteri hajoaa ensimmäisenä.

Tietoja kirjoittajasta

Mert Batur on Techsy.io:n perustajajäsen, ja hänen tiiminsä toimittaa AI-agentteja, automaatiojärjestelmiä ja ääni-/SDR-putkia B2B-asiakkaille. Hän kirjoittaa LLM-työkalupinosta, jota Techsyn tiimi oikeasti käyttää tuotannossa. Ansiot: Co-Founder, Techsy.io. Yhdistä LinkedInissä.

Usein kysytyt kysymykset

Mikä on monivuoroinen keskustelu-LLM?

Kielimalli, jonka n:s vastaus riippuu kaikista aiemmista vuoroista, ei vain viimeisimmästä promptista. Se ehdollistuu koko säikeeseen, joten käyttäytyminen muuttuu keskusteluhistorian myötä. Juuri tätä kontekstiriippuvuutta yksivuoroiset testit eivät pysty mittaamaan, ja monivuoroinen arviointi on olemassa sitä varten.

Mitä LLM-arviointi tarkoittaa?

Tulosten laadun mittaamista määriteltyjä kriteereitä vasten, automaattisesti ja toistettavasti, ei tuntumalta. Yksivuoroinen arviointi pisteyttää erillisiä prompti-vastaus-pareja mittareilla kuten BLEU tai LLM-tuomari. Monivuoroinen arviointi laajentaa sen kokonaisiin keskusteluihin ja pisteyttää kontekstin säilyttämistä ja tavoitteen saavuttamista vuorojen yli eikä per prompt.

Miten monivuoroista LLM-suorituskykyä benchmarkataan?

Rakenna vähintään 20 skenaariota tavoitteineen ja persoonineen, simuloi ne mallia vastaan ja pisteytä keskustelutason mittareilla sekä liukuvan ikkunan tarkistuksilla. Tallenna baselinet usean ajon yli epädeterministisyyden tasaamiseksi, ja vertaa jokaista uutta versiota baselineen CI:ssä. Tuotantojäljet laajentavat benchmarkia myöhemmin.

Mitkä ovat parhaat tavat arvioida LLM:ää?

Vaiheista: ensin manuaalinen virheanalyysi, sitten binääriset läpi/hylätty-portit kaikelle, mikä palautuu sääntöön, ja vasta sitten LLM-tuomari subjektiivisille kriteereille kuten sävy ja ratkaisun laatu. Binääriset tarkistukset ovat halvempia, debugattavia eivätkä ajaudu; tuomarit kuuluvat kriteereille, jotka oikeasti vaativat harkintaa, halpojen porttien läpäisyn jälkeen.

Mitkä monivuoroisen arvioinnin mittareista kannattaa valita alkuun?

Keskustelun täydellisyys, vuoron relevanssi ja tiedon säilyttäminen; ne havaitsevat yleisimmät häiriöt (ratkaisemattomat tavoitteet, ajautuminen, unohtaminen) missä tahansa chattituotteessa. Lisää roolissa pysyminen, jos botillasi on compliance-raja, ja sitten yksi oma G-Eval- tai AspectCritic-kriteeri virheelle, johon liiketoiminnallasi ei ole varaa.

Paljonko LLM-tuomari maksaa per keskustelu?

Liukuvalla ikkunalla 5 kymmenen vuoron yli plus yksi keskustelutason kutsu teet 7 tuomarikutsua per keskustelu. Noin 2 000 sisääntulotokenilla per kutsu GPT-4o-mini-mallilla esittämämme laskutoimitus päätyy noin 0,29 dollariin per 100 keskustelua. Ensiluokkaiset tuomarimallit nostavat sen 10–50-kertaiseksi.

DeepEval vs RAGAS monivuoroisessa arvioinnissa: kumman valitsen?

DeepEval, jos haluat offline-regressiotestit sisäänrakennetulla keskustelusimulaattorilla, erityisesti ennen kuin sinulla on tuotantoliikennettä. RAGAS, jos workflow'si alkaa oikeiden epäonnistuneiden keskustelujen lukemisesta ja kunkin häiriötyypin koodaamisesta AspectCriticiksi. Yleinen jako: DeepEval CI:ssä, RAGAS-tyyliset kriitikot tuotantolokeilla.

Kuinka monta skenaariota monivuoroinen testisarja tarvitsee?

Vähintään 20, kattaen pääkäyttötapaukset, reunatapaukset ja häiriöalttiit tilanteet; tämä kynnys tulee DeepEvaluin julkaistusta ohjeistuksesta ja vastaa kokemustamme. Alle 20:n läpäisyprosentit heiluvat sen mukaan, mitkä skenaariot sattuivat mukaan. Kasvata joukkoa jokaisella tuotantohäiriöllä.

Voiko monivuoroista arviointia ajaa CI/CD:ssä?

Kyllä. Pidä kiinteä skenaariojoukko repossa, aja se jokaisella prompt- tai mallimuutoksella ja kaada build, kun mittari regressoituu toleranssia enempää baselineen nähden. Koska mallit ovat epädeterministisiä, vertaa keskiarvoja kolmen ajon yli toleranssilla (käytämme 0,03), älä tarkoilla kynnyksillä.

Miten monivuoroisia keskusteluja arvioidaan tuotannossa?

Ryhmittele jäljet keskustelusäikeittäin, pisteytä jokainen säie asynkronisesti, jotta arviointi ei koskaan estä vastausta, ja ohjaa epäonnistuneet säikeet tarkistusjonoon. Jokaisesta vahvistetusta häiriöstä tulee uusi skenaario offline-sarjaasi, mikä sulkee silmukan valvonnan ja regressiotestien välillä.

Lyhyt versio

• Yksivuoroiset tulokset eivät näe keskusteluhäiriöitä; tutkimus näyttää mallien heikkenevän vuorojen edetessä terveistä benchmarkeista huolimatta.
• Aja keskustelutason pisteytystä porttinasi ja liukuvan ikkunan pisteytystä katkosten paikantamiseen.
• Neljä ydinmittaria plus yksi oma kriteeri kattavat useimmat chattituotteet; binääriset tarkistukset ennen tuomareita, aina.
• DeepEval simuloiduille regressiotesteille, RAGAS virheanalyysivetoonisille kriitikoille, Langfuse tuotantojäljille.
• Tuomarikustannukset ovat pienet (alle dollari per 100 keskustelua mini-mallilla); hinta on harvoin este.

Laajempaan työkalukenttään: sijoitimme koko alan parhaat LLM-arviointityökalut -katsauksessamme. Ja jos haluat mieluummin rakentaa arviointiputken jonkun kanssa, varaa ilmainen konsultaatio Techsyn tiimin kanssa.