Utvärderingsuppsättningar
Viktigt!
Den här funktionen finns som allmänt tillgänglig förhandsversion.
För att mäta kvaliteten på ett agentiskt program måste du kunna definiera en representativ uppsättning begäranden tillsammans med kriterier som kännetecknar högkvalitativa svar. Det gör du genom att tillhandahålla en utvärderingsuppsättning. Den här artikeln beskriver de olika alternativen för din utvärderingsuppsättning och några metodtips för att skapa en utvärderingsuppsättning.
Databricks rekommenderar att du skapar en mänskligt märkt utvärderingsuppsättning, som består av representativa frågor och svar på grund av sanningen. Om ditt program innehåller ett hämtningssteg kan du ange de stöddokument som du förväntar dig att svaret ska baseras på. För att hjälpa dig att komma igång med att skapa en utvärderingsuppsättning tillhandahåller Databricks en SDK för att generera högkvalitativa syntetiska frågor och grundsanningssvar som kan användas direkt i Agentutvärdering eller skickas till ämnesexperter för granskning. Se Syntetisera utvärderingsuppsättningar.
En bra utvärderingsuppsättning har följande egenskaper:
- Representant: Det bör korrekt återspegla det antal begäranden som programmet kommer att stöta på i produktion.
- Utmanande: Det bör innehålla svåra och olika fall för att effektivt testa hela programmets funktioner.
- Uppdateras kontinuerligt: Den bör uppdateras regelbundet för att återspegla hur programmet används och de föränderliga mönstren för produktionstrafik.
Det obligatoriska schemat för en utvärderingsuppsättning finns i Indataschema för agentutvärdering.
Exempel på utvärderingsuppsättningar
Det här avsnittet innehåller enkla exempel på utvärderingsuppsättningar.
Exempel på utvärderingsuppsättning med endast request
eval_set = [
{
"request": "What is the difference between reduceByKey and groupByKey in Spark?",
}
]
Exempel på utvärderingsuppsättning med request
och 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.",
}
]
Exempel på utvärderingsuppsättning med request
, expected_response
och 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.",
}
]
Exempel på utvärderingsuppsättning med endast request
och 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.",
}
]
Exempel på utvärderingsuppsättning med request
, response
och 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",
},
],
}
]
Exempel på utvärderingsuppsättning med request
, response
, retrieved_context
och 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.",
"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",
},
],
}
]
Exempel på utvärderingsuppsättning med request
, response
, retrieved_context
, expected_response
och expected_retrieved_context
level_4_data = [
{
"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_response": "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",
},
],
}
]
Metodtips för att utveckla en utvärderingsuppsättning
- Överväg varje exempel eller grupp med exempel i utvärderingsuppsättningen som ett enhetstest. Det innebär att varje exempel ska motsvara ett specifikt scenario med ett explicit förväntat resultat. Överväg till exempel att testa längre kontexter, resonemang med flera hopp och möjlighet att härleda svar från indirekta bevis.
- Överväg att testa skadliga scenarier från skadliga användare.
- Det finns ingen specifik riktlinje för antalet frågor som ska tas med i en utvärderingsuppsättning, men tydliga signaler från högkvalitativa data presterar vanligtvis bättre än brussignaler från svaga data.
- Överväg att ta med exempel som är mycket utmanande, även för människor att svara på.
- Oavsett om du skapar ett generellt program eller riktar in dig på en specifik domän, kommer din app sannolikt att stöta på en mängd olika frågor. Utvärderingsuppsättningen bör återspegla detta. Om du till exempel skapar ett program för att ställa specifika HR-frågor bör du fortfarande överväga att testa andra domäner (till exempel åtgärder) för att säkerställa att programmet inte hallucinerar eller ger skadliga svar.
- Högkvalitativa, konsekventa etiketter som genereras av människor är det bästa sättet att se till att de grundsanningsvärden som du tillhandahåller programmet korrekt återspeglar det önskade beteendet. Några steg för att säkerställa högkvalitativa mänskliga etiketter är följande:
- Aggregera svar (etiketter) från flera mänskliga etiketter för samma fråga.
- Se till att etiketteringsinstruktionerna är tydliga och att de mänskliga etiketterna är konsekventa.
- Se till att villkoren för processen för mänsklig etikettering är identiska med formatet för begäranden som skickas till RAG-programmet.
- Mänskliga etiketter är av naturen bullriga och inkonsekventa, till exempel på grund av olika tolkningar av frågan. Detta är en viktig del av processen. Användning av mänsklig etikettering kan avslöja tolkningar av frågor som du inte hade övervägt och som kan ge insikt i beteendet som du observerar i ditt program.