Modalità di valutazione della qualità, dei costi e della latenza

Importante

Questa funzionalità è disponibile in anteprima pubblica.

Questo articolo illustra in che modo Agent Evaluation valuta la qualità, i costi e la latenza dell'applicazione di intelligenza artificiale e fornisce informazioni dettagliate per guidare i miglioramenti qualitativi e le ottimizzazioni dei costi e della latenza. Riguarda le aree seguenti:

• Come viene valutata la qualità dai giudici LLM.
• Modalità di valutazione dei costi e della latenza.
• Modalità di aggregazione delle metriche a livello di esecuzione di MLflow per qualità, costo e latenza.

Per informazioni di riferimento su ognuno dei giudici LLM predefiniti, vedere Riferimento ai giudici di Valutazione LLM dell'agente di intelligenza artificiale mosaici.

Come viene valutata la qualità dai giudici LLM

Valutazione agente valuta la qualità usando i giudici LLM in due passaggi:

1. I giudici LLM valutano aspetti di qualità specifici (ad esempio correttezza e correttezza) per ogni riga. Per informazioni dettagliate, vedere Passaggio 1: I giudici LLM valutano la qualità di ogni riga.
2. La valutazione dell'agente combina le valutazioni dei singoli giudici in un punteggio complessivo di superamento/esito negativo e la causa principale di eventuali errori. Per informazioni dettagliate, vedere Passaggio 2: Combinare le valutazioni dei giudici LLM per identificare la causa principale dei problemi di qualità.

Per informazioni sulla fiducia e sulla sicurezza dei giudici LLM, vedere Informazioni sui modelli che alimentano i giudici LLM.

Nota

Per le conversazioni a più turni, i giudici LLM valutano solo l'ultima voce della conversazione.

Passaggio 1: I giudici LLM valutano la qualità di ogni riga

Per ogni riga di input, Agent Evaluation usa una suite di giudici LLM per valutare diversi aspetti della qualità degli output dell'agente. Ogni giudice produce un punteggio sì o no e una logica scritta per tale punteggio, come illustrato nell'esempio seguente:

Per informazioni dettagliate sui giudici LLM utilizzati, vedere I giudici LLM disponibili.

Passaggio 2: Combinare le valutazioni dei giudici LLM per identificare la causa principale dei problemi di qualità

Dopo aver eseguito i giudici LLM, Agent Evaluation analizza i risultati per valutare la qualità complessiva e determinare un punteggio di qualità superato/negativo nelle valutazioni collettive del giudice. Se la qualità complessiva ha esito negativo, Valutazione agente identifica il giudice LLM specifico che ha causato l'errore e fornisce correzioni suggerite.

I dati vengono visualizzati nell'interfaccia utente di MLflow ed è disponibile anche dall'esecuzione MLflow in un dataframe restituito dalla mlflow.evaluate(...) chiamata. Per informazioni dettagliate su come accedere al dataframe, vedere esaminare l'output della valutazione.

Lo screenshot seguente è un esempio di un'analisi di riepilogo nell'interfaccia utente:

I risultati per ogni riga sono disponibili nell'interfaccia utente della visualizzazione dettagli:

Giudici LLM disponibili

Il table riportato di seguito riepiloga la suite di giudici LLM usati in Agent Evaluation per valutare diversi aspetti della qualità. Per altri dettagli, vedere Giudici di risposta e Giudici di recupero.

Per informazioni dettagliate sui modelli che alimentano i giudici LLM, vedere Informazioni sui modelli che alimentano i giudici LLM. Per informazioni di riferimento su ognuno dei giudici LLM predefiniti, vedere Riferimento ai giudici di Valutazione LLM dell'agente di intelligenza artificiale mosaici.

Nome del giudice	Procedi	Aspetto di qualità valutato dal giudice	Input necessari	Richiede verità sul terreno?
relevance_to_query	Response	L'indirizzo di risposta (è rilevante per) la richiesta dell'utente?	- response, request	No
groundedness	Response	La risposta generata è terra nel contesto recuperato (non allucinante)?	- response, trace[retrieved_context]	No
safety	Response	C'è contenuto dannoso o tossico nella risposta?	- response	No
correctness	Response	La risposta generata è accurata (rispetto alla verità del terreno)?	- response, expected_response	Sì
guideline_adherence	Response	La risposta generata è conforme alle linee guida fornite?	- request, response, guidelines	Sì
chunk_relevance	Recupero	Il retriever ha trovato blocchi utili (rilevanti) per rispondere alla richiesta dell'utente? Nota: questo giudice viene applicato separatamente a ogni blocco recuperato, producendo un punteggio e una logica per ogni blocco. Questi punteggi vengono aggregati in un chunk_relevance/precision punteggio per ogni riga che rappresenta la percentuale di blocchi rilevanti.	- retrieved_context, request	No
document_recall	Recupero	Quanti documenti rilevanti noti ha trovato il retriever?	- retrieved_context, expected_retrieved_context[].doc_uri	Sì
context_sufficiency	Recupero	Il recuperatore ha trovato documenti con informazioni sufficienti per produrre la risposta prevista?	- retrieved_context, expected_response	Sì

Gli screenshot seguenti mostrano esempi di come questi giudici vengono visualizzati nell'interfaccia utente:

Come viene determinata la causa radice

Se tutti i giudici superano, la qualità viene considerata pass. Se un giudice fallisce, la causa principale viene determinata come il primo giudice che fallisce in base al numero list riportato di seguito. Questo ordinamento viene usato perché le valutazioni dei giudici sono spesso correlate in modo causale. Ad esempio, se context_sufficiency valuta che il retriever non ha recuperato i blocchi o i documenti corretti per la richiesta di input, è probabile che il generatore non riesca a sintetizzare una risposta valida e quindi correctness avrà esito negativo.

Se la verità del terreno viene fornita come input, viene usato l'ordine seguente:

1. context_sufficiency
2. groundedness
3. correctness
4. safety
5. guideline_adherence (se vengono forniti guidelines o global_guidelines)
6. Qualsiasi giudice LLM definito dal cliente

Se la verità del terreno non viene fornita come input, viene usato l'ordine seguente:

1. chunk_relevance - c'è almeno 1 blocco pertinente?
2. groundedness
3. relevant_to_query
4. safety
5. guideline_adherence (se vengono forniti guidelines o global_guidelines)
6. Qualsiasi giudice LLM definito dal cliente

Come Databricks mantiene e migliora l'accuratezza del giudice LLM

Databricks è dedicata a migliorare la qualità dei nostri giudici LLM. La qualità viene valutata misurando il livello di consenso del giudice LLM con i tassoni umani, usando le metriche seguenti:

• Kappa dell'Aumentato DiO (misura dell'accordo inter-tassor).
• Maggiore accuratezza (percentuale delle etichette stimate che corrispondono all'etichetta del tassor umano).
• Aumento del punteggio F1.
• Riduzione del tasso di falsi positivi.
• Riduzione del tasso falso negativo.

Per misurare queste metriche, Databricks usa esempi complessi e diversificati di set di dati accademici e proprietari rappresentativi dei set di dati dei clienti per eseguire il benchmarking e migliorare i giudici rispetto agli approcci di valutazione LLM all'avanguardia, garantendo un miglioramento continuo e un'elevata accuratezza.

Per altre informazioni sul modo in cui Databricks misura e migliora continuamente la qualità del giudice, vedere Databricks annuncia miglioramenti significativi ai giudici LLM predefiniti nella valutazione dell'agente.

Provare i giudici usando l'SDK databricks-agents

L'SDK databricks-agents include API per richiamare direttamente i giudici sugli input dell'utente. È possibile usare queste API per un esperimento rapido e semplice per vedere come funzionano i giudici.

Eseguire il codice seguente per installare il databricks-agents pacchetto e riavviare il kernel Python:

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

È quindi possibile eseguire il codice seguente nel notebook e modificarlo in base alle esigenze per provare i diversi giudici sui propri input.

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."
SAMPLE_GUIDELINES = [
    "The response must be in English",
    "The response must be clear, coherent, and concise",
]

# 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` and `guidelines`.
judges.guideline_adherence(
  request=SAMPLE_REQUEST,
  response=SAMPLE_RESPONSE,
  guidelines=SAMPLE_GUIDELINES,
)

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

Come vengono valutati i costi e la latenza

Valutazione agente misura i conteggi dei token e la latenza di esecuzione per comprendere le prestazioni dell'agente.

Costo del token

Per valutare il costo, Agent Evaluation calcola il numero totale di token in tutte le chiamate di generazione LLM nella traccia. In questo modo si approssima il costo totale dato come più token, che in genere porta a un costo maggiore. I conteggi dei token vengono calcolati solo quando un oggetto trace è disponibile. Se l'argomento model viene incluso nella chiamata a mlflow.evaluate(), viene generata automaticamente una traccia. È anche possibile fornire direttamente tracecolumn nel set di dati di valutazione.

I conteggi dei token seguenti vengono calcolati per ogni riga:

Campo dati	Tipo	Descrizione
total_token_count	integer	Somma di tutti i token di input e output in tutti gli intervalli LLM nella traccia dell'agente.
total_input_token_count	integer	Somma di tutti i token di input in tutti gli intervalli LLM nella traccia dell'agente.
total_output_token_count	integer	Somma di tutti i token di output in tutti gli intervalli LLM nella traccia dell'agente.

Latenza di esecuzione

Calcola la latenza dell'intera applicazione in secondi per la traccia. La latenza viene calcolata solo quando è disponibile una traccia. Se l'argomento model viene incluso nella chiamata a mlflow.evaluate(), viene generata automaticamente una traccia. È anche possibile fornire direttamente un tracecolumn nel set di dati di valutazione.

La misurazione della latenza seguente viene calcolata per ogni riga:

Nome	Descrizione
latency_seconds	Latenza end-to-end basata sulla traccia

Modalità di aggregazione delle metriche a livello di esecuzione di MLflow per qualità, costo e latenza

Dopo aver calcolato tutte le valutazioni di qualità, costi e latenza per riga, Valutazione agente aggrega questi asessment in metriche per esecuzione registrate in un'esecuzione MLflow e riepilogano la qualità, il costo e la latenza dell'agente in tutte le righe di input.

Agent Evaluation produce le metriche seguenti:

Nome metrica	Tipo	Descrizione
retrieval/llm_judged/chunk_relevance/precision/average	float, [0, 1]	Valore medio di chunk_relevance/precision in tutte le domande.
retrieval/llm_judged/context_sufficiency/rating/percentage	float, [0, 1]	% delle domande wherecontext_sufficiency/rating è giudicata come yes.
response/llm_judged/correctness/rating/percentage	float, [0, 1]	% di domande wherecorrectness/rating vengono giudicate come yes.
response/llm_judged/relevance_to_query/rating/percentage	float, [0, 1]	% delle domande whererelevance_to_query/rating vengono giudicate yes.
response/llm_judged/groundedness/rating/percentage	float, [0, 1]	% domande di wheregroundedness/rating vengono giudicate come yes.
response/llm_judged/guideline_adherence/rating/percentage	float, [0, 1]	% di domande whereguideline_adherence/rating vengono giudicate come yes.
response/llm_judged/safety/rating/average	float, [0, 1]	% delle domande where è safety/rating giudicata yes.
agent/total_token_count/average	int	Valore medio di total_token_count in tutte le domande.
agent/input_token_count/average	int	Valore medio di input_token_count in tutte le domande.
agent/output_token_count/average	int	Valore medio di output_token_count in tutte le domande.
agent/latency_seconds/average	float	Valore medio di latency_seconds in tutte le domande.
response/llm_judged/{custom_response_judge_name}/rating/percentage	float, [0, 1]	% delle domande where{custom_response_judge_name}/rating vengono giudicate come yes.
retrieval/llm_judged/{custom_retrieval_judge_name}/precision/average	float, [0, 1]	Valore medio di {custom_retrieval_judge_name}/precision in tutte le domande.

Gli screenshot seguenti mostrano come vengono visualizzate le metriche nell'interfaccia utente:

Informazioni sui modelli che alimentano i giudici LLM

• I giudici LLM possono usare servizi di terze parti per valutare le applicazioni GenAI, tra cui Azure OpenAI gestito da Microsoft.
• Per Azure OpenAI, Databricks ha rifiutato esplicitamente il monitoraggio degli abusi, quindi non vengono archiviate richieste o risposte con Azure OpenAI.
• Per le aree di lavoro dell'Unione europea (UE), i giudici LLM usano modelli ospitati nell'UE. Tutte le altre aree usano modelli ospitati negli Stati Uniti.
• La disabilitazione delle funzioni di assistenza intelligenza artificiale di Azure basato su intelligenza artificiale impedisce al giudice LLM di richiamare i modelli AI di Azure.
• I dati inviati al giudice LLM non vengono usati per il training del modello.
• I giudici LLM hanno lo scopo di aiutare i clienti a valutare le proprie applicazioni RAG e i loro output non devono essere usati per formare, migliorare o ottimizzare un LLM.