에이전트 평가 입력 스키마
Important
이 기능은 공개 미리 보기 상태입니다.
이 문서에서는 에이전트 평가에서 애플리케이션의 품질, 비용 및 대기 시간을 평가하는 데 필요한 입력 스키마를 설명합니다.
- 개발하는 동안 평가는 오프라인으로 이루어지며 평가 집합은 에이전트 평가에 필요한 입력입니다.
- 애플리케이션이 프로덕션에 있는 경우 에이전트 평가에 대한 모든 입력은 유추 테이블 또는 프로덕션 로그에서 가져옵니다.
입력 스키마는 온라인 및 오프라인 평가 모두에 대해 동일합니다.
평가 집합에 대한 일반적인 내용은 평가 집합을 참조 하세요.
평가 입력 스키마
다음 표에서는 에이전트 평가의 입력 스키마를 보여줍니다. 테이블의 마지막 두 열은 호출에 입력이 제공되는 mlflow.evaluate()
방법을 나타냅니다. 자세한 내용은 평가 실행에 대한 입력을 제공하는 방법을 참조하세요.
열 | 데이터 형식 | 설명 | 입력 인수로 전달된 애플리케이션 | 이전에 생성된 출력 제공됨 |
---|---|---|---|---|
request_id | string | 요청의 고유 식별자입니다. | 선택 사항 | 선택 사항 |
요청 | 요청에 대한 스키마를 참조하세요. | 평가할 애플리케이션, 사용자의 질문 또는 쿼리에 대한 입력입니다. 예를 들어 {'messages': [{"role": "user", "content": "What is RAG"}]} "RAG란?"입니다. request 문자열로 제공되면 에이전트에 messages 전달되기 전에 변환됩니다. |
Required | Required |
응답 | string | 평가 중인 애플리케이션에 의해 생성된 응답입니다. | 에이전트 평가에 의해 생성됨 | 선택 사항. 제공되지 않으면 추적에서 파생됩니다. 둘 중 하나 response 또는 trace 필수입니다. |
expected_facts | 문자열의 배열 | 모델 출력에 필요한 팩트 목록입니다. expected_facts 지침을 참조하세요. | 선택 사항 | 선택 사항 |
expected_response | string | 입력 요청에 대한 근거(올바른) 답변입니다. expected_response 지침을 참조하세요. | 선택 사항 | 선택 사항 |
expected_retrieved_context | 배열 | 요청에 대해 예상되는 검색된 컨텍스트를 포함하는 개체의 배열입니다(애플리케이션에 검색 단계가 포함된 경우). 배열 스키마 | 선택 사항 | 선택 사항 |
retrieved_context | 배열 | 평가 중인 애플리케이션의 검색자가 생성한 검색 결과입니다. 애플리케이션에 여러 검색 단계가 있는 경우 마지막 단계(추적에서 시간순)의 검색 결과입니다. 배열 스키마 | 에이전트 평가에 의해 생성됨 | 선택 사항. 제공되지 않으면 제공된 추적에서 파생됩니다. |
trace | MLflow 추적의 JSON 문자열 | 해당 요청에 대한 애플리케이션 실행의 MLflow 추적입니다. | 에이전트 평가에 의해 생성됨 | 선택 사항. 둘 중 하나 response 또는 trace 필수입니다. |
expected_facts
지침
expected_facts
필드는 특정 입력 요청에 대한 올바른 모델 응답에 나타날 것으로 예상되는 팩트 목록을 지정합니다. 즉, 응답이 표현되는 방식에 관계없이 이러한 사실을 포함하는 경우 모델 응답은 올바른 것으로 간주됩니다.
필요한 팩트만 포함하고 답변에 엄격하게 필요하지 않은 사실을 제외하면 에이전트 평가에서 출력 품질에 대한 보다 강력한 신호를 제공할 수 있습니다.
최대 하나 및 expected_response
.를 expected_facts
지정할 수 있습니다. 둘 다 지정하면 오류가 보고됩니다. Databricks는 에이전트 평가에서 생성된 응답의 품질을 보다 효과적으로 판단하는 데 도움이 되는 보다 구체적인 지침이므로 사용을 expected_facts
권장합니다.
expected_response
지침
필드에는 expected_response
올바른 모델 응답에 대한 참조를 나타내는 완전히 구성된 응답이 포함됩니다. 즉, 모델 응답은 .의 정보 콘텐츠 expected_response
와 일치하는 경우 올바른 것으로 간주됩니다. 반면, expected_facts
올바른 응답에 나타나고 완전히 형식화된 참조 응답이 아닌 팩트만 나열합니다.
expected_facts
마찬가지로 올바른 expected_response
응답에 필요한 최소한의 팩트 집합만 포함해야 합니다. 필요한 정보만 포함하고 답변에 꼭 필요하지 않은 정보를 제외하면 에이전트 평가에서 출력 품질에 대한 보다 강력한 신호를 제공할 수 있습니다.
최대 하나 및 expected_response
.를 expected_facts
지정할 수 있습니다. 둘 다 지정하면 오류가 보고됩니다. Databricks는 에이전트 평가에서 생성된 응답의 품질을 보다 효과적으로 판단하는 데 도움이 되는 보다 구체적인 지침이므로 사용을 expected_facts
권장합니다.
요청에 대한 스키마를 참조하세요.
요청 스키마는 다음 중 하나가 될 수 있습니다.
- OpenAI 채팅 완료 스키마입니다. OpenAI 채팅 완료 스키마에는 개체 배열이 매개 변수로
messages
있어야 합니다.messages
필드는 전체 대화를 인코딩할 수 있습니다. - 에이전트가 OpenAI 채팅 완료 스키마를 지원하는 경우 일반 문자열을 전달할 수 있습니다. 이 형식은 단일 턴 대화만 지원합니다. 일반 문자열은 에이전트에
messages
전달되기 전에 형식으로"role": "user"
변환됩니다. 예를 들어 일반 문자열"What is MLflow?"
은 에이전트에{"messages": [{"role": "user", "content": "What is MLflow?"}]}
전달되기 전에 변환됩니다. SplitChatMessagesRequest
. 가장 최근 요청에 대한query
문자열 필드와 대화의 이전 회차를 인코딩하는 선택적history
필드입니다.
다중 턴 채팅 애플리케이션의 경우 위의 두 번째 또는 세 번째 옵션을 사용합니다.
다음 예제에서는 평가 데이터 세트의 동일한 request
열에 있는 세 가지 옵션을 모두 보여 줍니다.
import pandas as pd
data = {
"request": [
# Plain string. Plain strings are transformed to the `messages` format before being passed to your agent.
"What is the difference between reduceByKey and groupByKey in Spark?",
# OpenAI chat completion schema. Use the `messages` field for a single- or multi-turn chat.
{
"messages": [
{
"role": "user",
"content": "How can you minimize data shuffling in Spark?"
}
]
},
# SplitChatMessagesRequest. Use the `query` and `history` fields for a single- or multi-turn chat.
{
"query": "Explain broadcast variables in Spark. How do they enhance performance?",
"history": [
{
"role": "user",
"content": "What are broadcast variables?"
},
{
"role": "assistant",
"content": "Broadcast variables allow the programmer to keep a read-only variable cached on each machine."
}
]
}
],
"expected_response": [
"expected response for first question",
"expected response for second question",
"expected response for third question"
]
}
eval_dataset = pd.DataFrame(data)
평가 입력의 배열에 대한 스키마
배열 expected_retrieved_context
와 retrieved_context
의 스키마는 다음 표에 나와 있습니다:
열 | 데이터 형식 | 설명 | 입력 인수로 전달된 애플리케이션 | 이전에 생성된 출력 제공됨 |
---|---|---|---|---|
content | string | 검색된 컨텍스트의 내용입니다. HTML, 일반 텍스트 또는 Markdown과 같은 모든 형식의 문자열입니다. | 선택 사항 | 선택 사항 |
doc_uri | string | 청크가 발생한 부모 문서의 URI(고유 식별자)입니다. | Required | Required |
계산된 메트릭
다음 표의 열은 입력에 포함된 데이터를 나타내며 ✓
해당 데이터가 제공될 때 메트릭이 지원됨을 나타냅니다.
이러한 메트릭이 측정하는 항목에 대한 자세한 내용은 에이전트 평가에서 품질, 비용 및 대기 시간을 평가하는 방법을 참조하세요.
계산된 메트릭 | request |
request 및 expected_response |
request , expected_response 및 expected_retrieved_context |
request 및 expected_retrieved_context |
---|---|---|---|---|
response/llm_judged/relevance_to_query/rating |
✓ | ✓ | ✓ | |
response/llm_judged/safety/rating |
✓ | ✓ | ✓ | |
response/llm_judged/groundedness/rating |
✓ | ✓ | ✓ | |
retrieval/llm_judged/chunk_relevance_precision |
✓ | ✓ | ✓ | |
agent/total_token_count |
✓ | ✓ | ✓ | |
agent/input_token_count |
✓ | ✓ | ✓ | |
agent/output_token_count |
✓ | ✓ | ✓ | |
response/llm_judged/correctness/rating |
✓ | ✓ | ||
retrieval/llm_judged/context_sufficiency/rating |
✓ | ✓ | ||
retrieval/ground_truth/document_recall |
✓ | ✓ |