Hoe kwaliteit, kosten en latentie worden beoordeeld door Agent Evaluation (MLflow 2)

Belangrijk

Op deze pagina wordt het gebruik van de agentevaluatieversie 0.22 beschreven met MLflow 2. Databricks raadt aan MLflow 3 te gebruiken, dat is geïntegreerd met agentevaluatie >1.0. In MLflow 3 maken agentevaluatie-API's nu deel uit van het mlflow pakket.

Zie Aangepaste LLM-scorers maken voor meer informatie over dit onderwerp.

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:

• Hoe kwaliteit wordt beoordeeld door LLM-beoordelaars.
• Hoe kosten en latentie worden beoordeeld.
• Hoe metrische gegevens worden geaggregeerd op het niveau van een MLflow-uitvoering voor kwaliteit, kosten en latentie.

Zie Ingebouwde AI-rechters (MLflow 2) voor naslaginformatie over elk van de ingebouwde LLM-rechters.

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 rechters beoordelen specifieke kwaliteitsaspecten (zoals juistheid en onderbouwing) voor elke rij. Voor meer informatie, zie stap 1: LLM-rechters beoordelen de kwaliteit van elke rij.
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 aandrijven voor vertrouwdheids- en veiligheidsinformatie.

Notitie

Voor gesprekken met meerdere beurten evalueren LLM-beoordelaars alleen de laatste bijdrage in het gesprek.

Stap 1: LLM-beoordelaars beoordelen 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:

Zie Ingebouwde AI-rechtersvoor 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:

Klik op een aanvraag om de details te bekijken:

ingebouwde AI-rechters

Zie ingebouwde AI-rechters (MLflow 2) voor meer informatie over ingebouwde AI-rechters van Mozaïek AI Agent Evaluation.

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

Hoe de hoofdoorzaak wordt bepaald

Als alle beoordelaars goedkeuren, wordt de kwaliteit als pass beschouwd. 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 beoordelingen door rechters vaak op een causale manier samenhangen. 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 grondwaarheid wordt verstrekt als invoer, wordt de volgende volgorde gebruikt:

1. context_sufficiency
2. groundedness
3. correctness
4. safety
5. guideline_adherence (indien guidelines of global_guidelines worden verstrekt)
6. Een door de klant gedefinieerde LLM-rechter

Als de referentiewaarde niet bij 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. guideline_adherence (indien guidelines of global_guidelines worden verstrekt)
6. Een 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 menselijke beoordelaars, met de volgende meetwaarden:

• Verhoogde Cohen's Kappa (een maat voor inter-rater overeenkomst).
• Verbeterde nauwkeurigheid (procent van voorspelde labels die overeenkomen met het label van de menselijke beoordelaar).
• Verhoogde F1-score.
• Het aantal valse positieven is verminderd.
• Het percentage fout-negatieven 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 beoordelaars verbetert, leest u in Databricks kondigt belangrijke verbeteringen aan voor de ingebouwde LLM-beoordelaars in Agent-evaluatie.

Rechters aanroepen met behulp van de Python SDK

De databricks-agents SDK bevat API's om rechtstreeks rechters op te roepen met gebruikersinput. 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.evals 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."
# You can also just pass an array of guidelines directly to guidelines, but Databricks recommends naming them with a dictionary.
SAMPLE_GUIDELINES = {
    "english": ["The response must be in English", "The retrieved context must be in English"],
    "clarity": ["The response must be clear, coherent, and concise"],
}
SAMPLE_GUIDELINES_CONTEXT = {
  "retrieved_context": str(SAMPLE_RETRIEVED_CONTEXT)
}

# 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 guideline_adherence, the required inputs are `request`, `response` or `guidelines_context`, and `guidelines`.
judges.guideline_adherence(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  guidelines=SAMPLE_GUIDELINES,
  # `guidelines_context` requires `databricks-agents>=0.20.0`. It can be specified with or in place of the response.
  guidelines_context=SAMPLE_GUIDELINES_CONTEXT,
)

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

Hoe de kosten en de 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 tokens voor alle LLM-generatie-oproepen in de trace. Dit benadert de totale kosten zoals aangegeven wanneer er meer tokens zijn, wat over het algemeen tot hogere kosten leidt. 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	Typologie	Beschrijving
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 over alle LLM-spans in het volgspoor 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:

Naam	Beschrijving
latency_seconds	End-to-end latentie op basis van de trace

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 assessments samengevoegd in metrische gegevens per uitvoering die worden vastgelegd in een MLflow-uitvoering en de kwaliteit, kosten en latentie van uw agent samenvatten over alle invoerrijen.

Agentevaluatie produceert de volgende metrische gegevens:

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

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

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.
• LLM-beoordelingssystemen zijn bedoeld om klanten te helpen bij het evalueren van hun GenAI-agents/toepassingen, en de uitkomsten van deze systemen mogen niet worden gebruikt om een LLM te trainen, verbeteren of fijnstellen.