Zestawy ewaluacyjne
Ważne
Ta funkcja jest dostępna w publicznej wersji zapoznawczej.
Aby zmierzyć jakość aplikacji agentycznej , musisz mieć możliwość zdefiniowania reprezentatywnego zestawu żądań wraz z kryteriami charakteryzującymi odpowiedzi wysokiej jakości. W tym celu należy dostarczyć zestaw ewaluacyjny. W tym artykule opisano różne opcje zestawu oceny oraz niektóre najlepsze rozwiązania dotyczące tworzenia zestawu oceny.
Usługa Databricks zaleca utworzenie zestawu oceny oznaczonego przez człowieka, który składa się z reprezentatywnych pytań i podstawowych odpowiedzi. Jeśli aplikacja zawiera krok pobierania, opcjonalnie możesz podać dokumenty pomocnicze, na których oczekujesz, że odpowiedź będzie oparta. Aby ułatwić rozpoczęcie tworzenia zestawu ewaluacyjnego, usługa Databricks udostępnia zestaw SDK do generowania wysokiej jakości pytań syntetycznych i podstawowych odpowiedzi, które mogą być używane bezpośrednio w ocenie agenta lub wysyłane do ekspertów z danej dziedziny do przeglądu. Sprawdź Zsyntezuj zestawy oceny.
Dobry zestaw oceny ma następujące cechy:
- Przedstawiciel: Powinien dokładnie odzwierciedlać zakres żądań, które aplikacja napotka w środowisku produkcyjnym.
- Trudne: Należy uwzględnić trudne i zróżnicowane przypadki, aby skutecznie przetestować pełny zakres możliwości aplikacji.
- Stale aktualizowane: należy regularnie aktualizować aplikację w celu odzwierciedlenia sposobu użycia aplikacji i zmieniających się wzorców ruchu produkcyjnego.
Aby uzyskać wymagany schemat zestawu do oceny, zobacz Schemat wejściowy oceny agenta.
Zestawy przykładowych ocen
Ta sekcja zawiera proste przykłady zestawów oceny.
Przykładowy zestaw oceny z tylko request
eval_set = [
{
"request": "What is the difference between reduceByKey and groupByKey in Spark?",
}
]
Przykładowy zestaw oceny z request
i expected_response
eval_set = [
{
"request_id": "request-id",
"request": "What is the difference between reduceByKey and groupByKey in Spark?",
"expected_response": "There's no significant difference.",
}
]
Przykładowy zestaw oceny z request
, expected_response
i expected_retrieved_content
eval_set = [
{
"request_id": "request-id",
"request": "What is the difference between reduceByKey and groupByKey in Spark?",
"expected_retrieved_context": [
{
"doc_uri": "doc_uri_1",
},
{
"doc_uri": "doc_uri_2",
},
],
"expected_response": "There's no significant difference.",
}
]
Przykładowy zestaw oceny z tylko request
i response
eval_set = [
{
"request": "What is the difference between reduceByKey and groupByKey in Spark?",
"response": "reduceByKey aggregates data before shuffling, whereas groupByKey shuffles all data, making reduceByKey more efficient.",
}
]
Przykładowy zestaw oceny z request
, response
i guidelines
eval_set = [
{
"request": "What is the difference between reduceByKey and groupByKey in Spark?",
"response": "reduceByKey aggregates data before shuffling, whereas groupByKey shuffles all data, making reduceByKey more efficient.",
"guidelines": [
"The response must be in English",
"The response must be clear, coherent, and concise",
]
}
]
Przykładowy zestaw oceny z request
, response
, guidelines
i expected_facts
eval_set = [
{
"request": "What is the difference between reduceByKey and groupByKey in Spark?",
"response": "reduceByKey aggregates data before shuffling, whereas groupByKey shuffles all data, making reduceByKey more efficient.",
"expected_facts": [
"There's no significant difference.",
],
"guidelines": [
"The response must be in English",
"The response must be clear, coherent, and concise",
],
}
]
Przykładowy zestaw oceny z request
, response
i retrieved_context
eval_set = [
{
"request_id": "request-id", # optional, but useful for tracking
"request": "What is the difference between reduceByKey and groupByKey in Spark?",
"response": "reduceByKey aggregates data before shuffling, whereas groupByKey shuffles all data, making reduceByKey more efficient.",
"retrieved_context": [
{
# In `retrieved_context`, `content` is optional, but delivers additional functionality if provided (the Databricks Context Relevance LLM judge runs to check the relevance of the provided content to the request).
"content": "reduceByKey reduces the amount of data shuffled by merging values before shuffling.",
"doc_uri": "doc_uri_2_1",
},
{
"content": "groupByKey may lead to inefficient data shuffling due to sending all values across the network.",
"doc_uri": "doc_uri_6_extra",
},
],
}
]
Przykładowy zestaw oceny z request
, response
, retrieved_context
i expected_facts
eval_set = [
{
"request_id": "request-id",
"request": "What is the difference between reduceByKey and groupByKey in Spark?",
"expected_facts": [
"There's no significant difference.",
],
"response": "reduceByKey aggregates data before shuffling, whereas groupByKey shuffles all data, making reduceByKey more efficient.",
"retrieved_context": [
{
# In `retrieved_context`, `content` is optional, but delivers additional functionality if provided (the Databricks Context Relevance LLM judge runs to check the relevance of the provided content to the request).
"content": "reduceByKey reduces the amount of data shuffled by merging values before shuffling.",
"doc_uri": "doc_uri_2_1",
},
{
"content": "groupByKey may lead to inefficient data shuffling due to sending all values across the network.",
"doc_uri": "doc_uri_6_extra",
},
],
}
]
Przykładowy zestaw oceny z request
, response
, retrieved_context
, expected_facts
i expected_retrieved_context
eval_set = [
{
"request_id": "request-id",
"request": "What is the difference between reduceByKey and groupByKey in Spark?",
"expected_retrieved_context": [
{
"doc_uri": "doc_uri_2_1",
},
{
"doc_uri": "doc_uri_2_2",
},
],
"expected_facts": [
"There's no significant difference.",
],
"response": "reduceByKey aggregates data before shuffling, whereas groupByKey shuffles all data, making reduceByKey more efficient.",
"retrieved_context": [
{
# In `retrieved_context`, `content` is optional, but delivers additional functionality if provided (the Databricks Context Relevance LLM judge runs to check the relevance of the provided content to the request).
"content": "reduceByKey reduces the amount of data shuffled by merging values before shuffling.",
"doc_uri": "doc_uri_2_1",
},
{
"content": "groupByKey may lead to inefficient data shuffling due to sending all values across the network.",
"doc_uri": "doc_uri_6_extra",
},
],
}
]
Najlepsze rozwiązania dotyczące tworzenia zestawu ewaluacyjnego
- Rozważ każdą próbkę lub grupę próbek w zestawie oceny jako test jednostkowy. Oznacza to, że każda próbka powinna odpowiadać konkretnemu scenariuszowi z jawnym oczekiwanym wynikiem. Rozważmy na przykład testowanie dłuższych kontekstów, rozumowanie z wieloma przeskokami i możliwość wnioskowania odpowiedzi z dowodów pośrednich.
- Rozważ przetestowanie niepożądanych scenariuszy ze strony złośliwych użytkowników.
- Nie ma konkretnych wytycznych dotyczących liczby pytań do uwzględnienia w zestawie oceny, ale jasne sygnały z danych wysokiej jakości zwykle działają lepiej niż hałaśliwe sygnały ze słabych danych.
- Rozważ uwzględnienie przykładów, które są bardzo trudne, nawet dla ludzi, aby odpowiedzieć.
- Niezależnie od tego, czy tworzysz aplikację ogólnego przeznaczenia, czy jest przeznaczona dla określonej domeny, aplikacja prawdopodobnie napotka wiele różnych pytań. Zestaw oceny powinien to odzwierciedlać. Jeśli na przykład tworzysz aplikację pod kątem konkretnych pytań dotyczących kadr, nadal należy rozważyć przetestowanie innych domen (na przykład operacji), aby upewnić się, że aplikacja nie ma halucynacji ani nie dostarcza szkodliwych odpowiedzi.
- Wysokiej jakości, spójne etykiety generowane przez człowieka są najlepszym sposobem zapewnienia, że podstawowe wartości prawdy podane w aplikacji dokładnie odzwierciedlają żądane zachowanie. Niektóre kroki w celu zapewnienia wysokiej jakości etykiet ludzkich są następujące:
- Agregowanie odpowiedzi (etykiet) z wielu etykiet ludzkich dla tego samego pytania.
- Upewnij się, że instrukcje etykietowania są jasne i że etykiety ludzkie są spójne.
- Upewnij się, że warunki procesu etykietowania przez człowieka są identyczne z formatem żądań przesłanych do aplikacji RAG.
- Etykiety ludzkie są z natury hałaśliwe i niespójne, na przykład ze względu na różne interpretacje pytania. Jest to ważna część procesu. Użycie etykietowania przez człowieka może ujawnić interpretacje pytań, które nie były brane pod uwagę i które mogą zapewnić wgląd w zachowanie obserwowane w aplikacji.