Delen via


Hoe kwaliteit, kosten en latentie worden beoordeeld door agentevaluatie

Belangrijk

Deze functie is beschikbaar als openbare preview.

In dit artikel wordt uitgelegd hoe agentevaluatie de kwaliteit, kosten en latentie van uw AI-toepassing evalueert en inzicht biedt in uw kwaliteitsverbeteringen en optimalisatie van kosten en latentie. Hierin worden de volgende zaken behandeld:

Zie de naslaginformatie over de ingebouwde LLM-rechters voor mozaïek AI Agent Evaluation LLM.

Hoe kwaliteit wordt beoordeeld door LLM-rechters

De evaluatie van de agent beoordeelt de kwaliteit met behulp van LLM-rechters in twee stappen:

  1. LLM beoordeelt specifieke kwaliteitsaspecten (zoals juistheid en grondheid) voor elke rij. Zie stap 1: LLM-rechters beoordelen de kwaliteit van elke rij voor meer informatie.
  2. AgentEvaluatie combineert evaluaties van individuele rechters tot een algemene score voor slagen/mislukken en hoofdoorzaak voor eventuele fouten. Zie stap 2 voor meer informatie: Beoordeling van LLM-rechters combineren om de hoofdoorzaak van kwaliteitsproblemen te identificeren.

Zie informatie over de modellen die LLM-rechters in staat stellen om vertrouwens- en veiligheidsinformatie van LLM te beoordelen.

Stap 1: LLM beoordeelt de kwaliteit van elke rij

Voor elke invoerrij gebruikt Agent Evaluation een reeks LLM-rechters om verschillende aspecten van de kwaliteit van de uitvoer van de agent te beoordelen. Elke rechter produceert een ja- of neescore en een geschreven logica voor die score, zoals wordt weergegeven in het onderstaande voorbeeld:

sample-judge-row

Zie Beschikbare LLM-rechters voor meer informatie over de gebruikte LLM-rechters.

Stap 2: Beoordeling van LLM-rechters combineren om de hoofdoorzaak van kwaliteitsproblemen te identificeren

Na het uitvoeren van LLM-rechters analyseert Agent Evaluation hun uitvoer om de algehele kwaliteit te beoordelen en een kwaliteitsscore voor slagen/mislukken te bepalen op de collectieve beoordelingen van de rechter. Als de algehele kwaliteit mislukt, identificeert agentevaluatie welke specifieke LLM-rechter de fout heeft veroorzaakt en biedt voorgestelde oplossingen.

De gegevens worden weergegeven in de MLflow-gebruikersinterface en zijn ook beschikbaar via de MLflow-uitvoering in een DataFrame dat door de mlflow.evaluate(...) aanroep wordt geretourneerd. Zie de evaluatie-uitvoer voor meer informatie over het openen van het DataFrame.

De volgende schermopname is een voorbeeld van een samenvattingsanalyse in de gebruikersinterface:

overzicht van hoofdoorzaakanalyse

De resultaten voor elke rij zijn beschikbaar in de gebruikersinterface van de detailweergave:

detail van hoofdoorzaakanalyse

Beschikbare LLM-rechters

De onderstaande tabel bevat een overzicht van de suite met LLM-rechters die worden gebruikt in agentevaluatie om verschillende aspecten van kwaliteit te beoordelen. Zie Antwoordrechters en Retrieval-rechters voor meer informatie.

Zie Voor meer informatie over de modellen die power LLM beoordeelt informatie over de modellen die LLM-rechters aandrijven. Zie de naslaginformatie over de ingebouwde LLM-rechters voor mozaïek AI Agent Evaluation LLM.

Naam van de rechter Stap Kwaliteitsaspect dat de rechter beoordeelt Vereiste invoer Vereist grondwaar?
relevance_to_query Respons Is het antwoordadres (relevant voor) de aanvraag van de gebruiker? - response, request Nee
groundedness Respons Is het gegenereerde antwoord geaard in de opgehaalde context (niet hallucinerend)? - response, trace[retrieved_context] Nee
safety Respons Is er schadelijke of giftige inhoud in het antwoord? - response Nee
correctness Respons Is het gegenereerde antwoord nauwkeurig (vergeleken met de grondwaar)? - response, expected_response Ja
chunk_relevance Ophalen Heeft de retriever segmenten gevonden die nuttig (relevant) zijn bij het beantwoorden van de aanvraag van de gebruiker?

Opmerking: Deze rechter wordt afzonderlijk toegepast op elk opgehaald segment, waardoor een score & rationale voor elk segment wordt geproduceerd. Deze scores worden geaggregeerd in een chunk_relevance/precision score voor elke rij die het percentage van segmenten vertegenwoordigt dat relevant is.
- retrieved_context, request Nee
document_recall Ophalen Hoeveel van de bekende relevante documenten heeft de retriever gevonden? - retrieved_context, expected_retrieved_context[].doc_uri Ja
context_sufficiency Ophalen Heeft de retriever documenten met voldoende informatie gevonden om het verwachte antwoord te produceren? - retrieved_context, expected_response Ja

In de volgende schermopnamen ziet u voorbeelden van hoe deze rechters worden weergegeven in de gebruikersinterface:

gen rechter detail

Details van segmentrelevantie

Hoe de hoofdoorzaak wordt bepaald

Als alle rechters slagen, wordt de kwaliteit overwogen pass. Als een rechter mislukt, wordt de hoofdoorzaak bepaald als de eerste rechter die mislukt op basis van de onderstaande geordende lijst. Deze volgorde wordt gebruikt omdat beoordelingsbeoordelingen vaak op causale wijze worden gecorreleerd. Als context_sufficiency bijvoorbeeld wordt beoordeeld of de retriever de juiste segmenten of documenten voor de invoeraanvraag niet heeft opgehaald, is het waarschijnlijk dat de generator een goed antwoord niet kan synthetiseren en daarom ook correctness zal mislukken.

Als de grondwaar wordt verstrekt als invoer, wordt de volgende volgorde gebruikt:

  1. context_sufficiency
  2. groundedness
  3. correctness
  4. safety
  5. Elke door de klant gedefinieerde LLM-rechter

Als de grondwaar niet als invoer wordt opgegeven, wordt de volgende volgorde gebruikt:

  1. chunk_relevance - is er ten minste één relevant segment?
  2. groundedness
  3. relevant_to_query
  4. safety
  5. Elke door de klant gedefinieerde LLM-rechter

Hoe Databricks de nauwkeurigheid van de LLM-rechter onderhoudt en verbetert

Databricks is gewijd aan het verbeteren van de kwaliteit van onze LLM-rechters. Kwaliteit wordt geëvalueerd door te meten hoe goed de LLM-rechter het eens is met human raters, met behulp van de volgende metrische gegevens:

  • Increased Cohen's Kappa (een meting van inter-rater overeenkomst).
  • Verbeterde nauwkeurigheid (procent van voorspelde labels die overeenkomen met het label van de menselijke behandelaar).
  • Verhoogde F1-score.
  • Het aantal fout-positieven is afgenomen.
  • De fout-negatieve snelheid is afgenomen.

Om deze metrische gegevens te meten, gebruikt Databricks diverse, uitdagende voorbeelden van academische en bedrijfseigen gegevenssets die representatief zijn voor klantgegevenssets om rechters te benchmarken en te verbeteren tegen state-of-the-art LLM-rechterbenaderingen, waardoor continue verbetering en hoge nauwkeurigheid worden gegarandeerd.

Voor meer informatie over hoe Databricks meet en continu de kwaliteit van de rechter verbetert, leest u in Databricks belangrijke verbeteringen aan voor de ingebouwde LLM-rechters in agentevaluatie.

Rechters proberen met behulp van de databricks-agents SDK

De databricks-agents SDK bevat API's voor het rechtstreeks aanroepen van rechters op gebruikersinvoer. U kunt deze API's gebruiken voor een snel en eenvoudig experiment om te zien hoe de rechters werken.

Voer de volgende code uit om het databricks-agents pakket te installeren en de Python-kernel opnieuw op te starten:

%pip install databricks-agents -U
dbutils.library.restartPython()

U kunt vervolgens de volgende code uitvoeren in uw notebook en deze indien nodig bewerken om de verschillende rechters uit te proberen op uw eigen invoer.

from databricks.agents.eval import judges

SAMPLE_REQUEST = "What is MLflow?"
SAMPLE_RESPONSE = "MLflow is an open-source platform"
SAMPLE_RETRIEVED_CONTEXT = [
        {
            "content": "MLflow is an open-source platform, purpose-built to assist machine learning practitioners and teams in handling the complexities of the machine learning process. MLflow focuses on the full lifecycle for machine learning projects, ensuring that each phase is manageable, traceable, and reproducible."
        }
    ]
SAMPLE_EXPECTED_RESPONSE = "MLflow is an open-source platform, purpose-built to assist machine learning practitioners and teams in handling the complexities of the machine learning process. MLflow focuses on the full lifecycle for machine learning projects, ensuring that each phase is manageable, traceable, and reproducible."

# For chunk_relevance, the required inputs are `request`, `response` and `retrieved_context`.
judges.chunk_relevance(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)

# For context_sufficiency, the required inputs are `request`, `expected_response` and `retrieved_context`.
judges.context_sufficiency(
  request=SAMPLE_REQUEST,
  expected_response=SAMPLE_EXPECTED_RESPONSE,
  retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)

# For correctness, required inputs are `request`, `response` and `expected_response`.
judges.correctness(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  expected_response=SAMPLE_EXPECTED_RESPONSE
)

# For relevance_to_query, the required inputs are `request` and `response`.
judges.relevance_to_query(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
)

# For groundedness, the required inputs are `request`, `response` and `retrieved_context`.
judges.groundedness(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  retrieved_context=SAMPLE_RETRIEVED_CONTEXT,
)

# For safety, the required inputs are `request` and `response`.
judges.safety(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
)

Hoe kosten en latentie worden beoordeeld

AgentEvaluatie meet tokenaantallen en uitvoeringslatentie om u inzicht te geven in de prestaties van uw agent.

Tokenkosten

Om kosten te beoordelen, berekent Agent Evaluation het totale aantal token voor alle aanroepen van de LLM-generatie in de trace. Hiermee worden de totale kosten geschat die worden gegeven als meer tokens, wat doorgaans leidt tot meer kosten. Tokenaantallen worden alleen berekend wanneer een trace beschikbaar is. Als het model argument is opgenomen in de aanroep naar mlflow.evaluate(), wordt automatisch een tracering gegenereerd. U kunt ook rechtstreeks een trace kolom opgeven in de evaluatiegegevensset.

De volgende tokenaantallen worden berekend voor elke rij:

Gegevensveld Type Description
total_token_count integer Som van alle invoer- en uitvoertokens voor alle LLM-spanten in de tracering van de agent.
total_input_token_count integer Som van alle invoertokens voor alle LLM-spanten in de tracering van de agent.
total_output_token_count integer Som van alle uitvoertokens voor alle LLM-bestanden in de tracering van de agent.

Uitvoeringslatentie

Berekent de latentie van de hele toepassing in seconden voor de tracering. Latentie wordt alleen berekend wanneer een tracering beschikbaar is. Als het model argument is opgenomen in de aanroep naar mlflow.evaluate(), wordt automatisch een tracering gegenereerd. U kunt ook rechtstreeks een trace kolom opgeven in de evaluatiegegevensset.

De volgende latentiemeting wordt berekend voor elke rij:

Name Beschrijving
latency_seconds End-to-endlatentie op basis van de tracering

Hoe metrische gegevens worden geaggregeerd op het niveau van een MLflow-uitvoering voor kwaliteit, kosten en latentie

Na het berekenen van alle kwaliteits-, kosten- en latentiebeoordelingen per rij worden deze asessments samengevoegd in metrische gegevens per uitvoering die zijn vastgelegd in een MLflow-uitvoering en de kwaliteit, kosten en latentie van uw agent samenvatten in alle invoerrijen.

Agentevaluatie produceert de volgende metrische gegevens:

Naam van meetwaarde Type Description
retrieval/llm_judged/chunk_relevance/precision/average float, [0, 1] De gemiddelde waarde van chunk_relevance/precision alle vragen.
retrieval/llm_judged/context_sufficiency/rating/percentage float, [0, 1] % van de vragen waar context_sufficiency/rating wordt beoordeeld als yes.
response/llm_judged/correctness/rating/percentage float, [0, 1] % van de vragen waar correctness/rating wordt beoordeeld als yes.
response/llm_judged/relevance_to_query/rating/percentage float, [0, 1] % van de vragen waar relevance_to_query/rating wordt beoordeeld yes.
response/llm_judged/groundedness/rating/percentage float, [0, 1] % van de vragen waar groundedness/rating wordt beoordeeld als yes.
response/llm_judged/safety/rating/average float, [0, 1] % van de vragen waar wordt safety/rating beoordeeld yes.
agent/total_token_count/average int De gemiddelde waarde van total_token_count alle vragen.
agent/input_token_count/average int De gemiddelde waarde van input_token_count alle vragen.
agent/output_token_count/average int De gemiddelde waarde van output_token_count alle vragen.
agent/latency_seconds/average float De gemiddelde waarde van latency_seconds alle vragen.
response/llm_judged/{custom_response_judge_name}/rating/percentage float, [0, 1] % van de vragen waar {custom_response_judge_name}/rating wordt beoordeeld als yes.
retrieval/llm_judged/{custom_retrieval_judge_name}/precision/average float, [0, 1] De gemiddelde waarde van {custom_retrieval_judge_name}/precision alle vragen.

In de volgende schermafbeeldingen ziet u hoe de metrische gegevens worden weergegeven in de gebruikersinterface:

metrische evaluatiegegevens, waarden

metrische evaluatiegegevens, grafieken

Informatie over de modellen die LLM-rechters aandrijven

  • LLM-rechters kunnen services van derden gebruiken om uw GenAI-toepassingen te evalueren, waaronder Azure OpenAI beheerd door Microsoft.
  • Voor Azure OpenAI heeft Databricks zich afgemeld voor Misbruikbewaking, zodat er geen prompts of antwoorden worden opgeslagen met Azure OpenAI.
  • Voor werkruimten van de Europese Unie (EU) gebruiken LLM-rechters modellen die in de EU worden gehost. In alle andere regio's worden modellen gebruikt die worden gehost in de VS.
  • Door Azure AI aangedreven AI-ondersteunende functies uit te schakelen, voorkomt u dat de LLM-rechter Azure AI-modellen aanroept.
  • Gegevens die naar de LLM-rechter worden verzonden, worden niet gebruikt voor modeltrainingen.
  • LLM-rechters zijn bedoeld om klanten te helpen hun RAG-toepassingen te evalueren en LLM-rechters mogen niet worden gebruikt om een LLM te trainen, te verbeteren of af te stemmen.