다음을 통해 공유

세트 평가

  • 아티클

Important

이 기능은 공개 미리 보기 상태입니다.

에이전트 애플리케이션의 품질을 측정하려면 고품질의 정확한 응답이 어떤 모습인지 정의할 수 있어야 합니다. 평가 집합을 제공하여 이 작업을 수행합니다. 이 문서에서는 평가 집합에 있는 데이터 및 평가 집합을 만들기 위한 몇 가지 모범 사례를 기반으로 계산되는 평가 집합의 필수 스키마에 대해 설명합니다.

Databricks는 사용자 레이블이 지정된 평가 집합을 만드는 것이 좋습니다. 이것은 대표적인 질문과 지상 진실 답변의 집합입니다. 신청서에 검색 단계가 포함된 경우 응답의 근거가 될 것으로 예상되는 증빙 문서를 선택적으로 제공할 수도 있습니다.

좋은 평가 세트에는 다음과 같은 특징이 있습니다:

  • 담당자: 애플리케이션이 프로덕션에서 발생하는 요청 범위를 정확하게 반영해야 합니다.
  • 도전: 애플리케이션의 모든 기능을 효과적으로 테스트하려면 어렵고 다양한 사례가 포함되어야 합니다.
  • 지속적으로 업데이트: 애플리케이션이 사용되는 방법과 프로덕션 트래픽의 변화하는 패턴을 반영하도록 정기적으로 업데이트해야 합니다.

평가 집합을 사용하여 평가를 실행하는 방법을 알아보려면 평가를 실행하고 결과를 보는 방법을 참조하세요.

평가 집합 스키마

다음 표에서는 mlflow.evaluate() 호출에 제공된 DataFrame에 필요한 스키마를 보여줍니다.

열 데이터 형식 설명 입력 인수로 전달된 애플리케이션 이전에 생성된 출력 제공됨
request_id string 요청의 고유 식별자입니다. 선택 사항 선택 사항
요청 string 평가할 애플리케이션, 사용자의 질문 또는 쿼리에 대한 입력입니다. 예를 들어 "RAG란?” 요청에 대한 스키마를 참조하세요. Required Required
expected_retrieved_context 배열 요청에 대해 예상되는 검색된 컨텍스트를 포함하는 개체의 배열입니다(애플리케이션에 검색 단계가 포함된 경우). 배열 스키마 선택 사항 선택 사항
expected_response string 입력 요청에 대한 근거(올바른) 답변입니다. expected_response 지침을 참조하세요. 선택 사항 선택 사항
응답 string 평가 중인 애플리케이션에 의해 생성된 응답입니다. 에이전트 평가에 의해 생성됨 선택 사항. 제공되지 않으면 추적에서 파생됩니다. 둘 중 하나 response 또는 trace 필수입니다.
retrieved_context 배열 평가 중인 애플리케이션의 검색자가 생성한 검색 결과입니다. 애플리케이션에 여러 검색 단계가 있는 경우 마지막 단계(추적에서 시간순)의 검색 결과입니다. 배열 스키마 에이전트 평가에 의해 생성됨 선택 사항. 제공되지 않으면 제공된 추적에서 파생됩니다.
trace MLflow 추적의 JSON 문자열 해당 요청에 대한 애플리케이션 실행의 MLflow 추적입니다. 에이전트 평가에 의해 생성됨 선택 사항. 둘 중 하나 response 또는 trace 필수입니다.

expected_response 지침

근거 사실 expected_response에는 올바른 답변에 필요한 최소한의 사실만 포함되어야 합니다. 다른 소스에서 응답을 복사하는 경우 정답으로 간주되는 데 필요하지 않은 텍스트를 제거하도록 응답을 수정해야 합니다.

필요한 정보만 포함하고 답변에 엄격하게 필요하지 않은 정보를 제외하면 에이전트 평가에서 출력 품질에 대한 보다 강력한 신호를 제공할 수 있습니다.

요청에 대한 스키마를 참조하세요.

요청 스키마는 다음 중 하나가 될 수 있습니다.

  • 일반 문자열입니다. 이 형식은 단일 턴 대화만 지원합니다.
  • OpenAI 채팅 완료 스키마를 따르고 전체 대화를 인코딩할 수 있는 messages 필드입니다.
  • 가장 최근 요청에 대한 query 문자열 필드와 대화의 이전 회차를 인코딩하는 선택적 history 필드입니다.

다중 턴 채팅 애플리케이션의 경우 위의 두 번째 또는 세 번째 옵션을 사용합니다.

다음 예제에서는 평가 데이터 세트의 동일한 request 열에 있는 세 가지 옵션을 모두 보여 줍니다.

import pandas as pd

data = {
  "request": [

      # Plain string
      "What is the difference between reduceByKey and groupByKey in Spark?",

      # Using the `messages` field for a single- or multi-turn chat
      {
          "messages": [
              {
                  "role": "user",
                  "content": "How can you minimize data shuffling in Spark?"
              }
          ]
      },

      # Using 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

애플리케이션이 입력 인수 model를 통해 전달될 때 사용할 수 있는 메트릭

계산된 메트릭은 평가 집합에 제공하는 데이터에 의해 결정됩니다. 이 표에서는 애플리케이션을 입력 인수로 사용하는 평가에 대한 종속성을 보여 줍니다. 열은 평가 집합에 포함된 데이터를 나타내며, X는 해당 데이터가 제공될 때 메트릭이 지원됨을 나타냅니다.

이러한 지표가 측정하는 항목에 대한 자세한 내용은 에이전트 매트릭 및 LLM 판정을 사용하여 앱 성능을 평가하기를 참조하세요.

계산된 메트릭 request request 및 expected_response request, expected_response 및 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 ✓

request만 있는 샘플 평가 세트

eval_set = [
    {
        "request": "What is the difference between reduceByKey and groupByKey in Spark?",
    }
]

request와 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.",
    }
]

request, expected_response와 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.",
    }
]

애플리케이션 출력이 제공될 때 사용할 수 있는 메트릭

계산된 메트릭은 평가 집합에 제공하는 데이터에 의해 결정됩니다. 이 표에서는 평가 집합 및 애플리케이션 출력을 사용하여 데이터 프레임을 제공하는 평가에 대한 종속성을 보여 줍니다. 열은 평가 집합에 포함된 데이터를 나타내며, X는 해당 데이터가 제공될 때 메트릭이 지원됨을 나타냅니다.

계산된 메트릭 request 및 response request, response 및 retrieved_context request, response, retrieved_context 및 expected_response request, response, retrieved_context, expected_response 및 expected_retrieved_context
response/llm_judged/relevance_to_query/rating ✓ ✓ ✓ ✓
response/llm_judged/safety/rating ✓ ✓ ✓ ✓
agent/request_token_count ✓ ✓ ✓ ✓
agent/response_token_count ✓ ✓ ✓ ✓
고객 정의 LLM 판정 ✓ ✓ ✓ ✓
retrieval/llm_judged/chunk_relevance/precision ✓ ✓ ✓
response/llm_judged/groundedness/rating ✓ ✓ ✓
response/llm_judged/correctness/rating ✓ ✓
retrieval/llm_judged/context_sufficiency/rating ✓ ✓
retrieval/ground_truth/document_recall ✓

request와 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.",
    }
]

request, response와 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",
            },
        ],
    }
]

request, response, retrieved_context와 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",
            },
        ],
    }
]

request, response, retrieved_context, expected_response와 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",
            },
        ],
    }
]

평가 집합을 개발하기 위한 모범 사례

  • 평가 집합에서 각 샘플 또는 샘플 그룹을 단위 테스트로 고려합니다. 즉, 각 샘플은 명시적 예상 결과가 있는 특정 시나리오에 해당해야 합니다. 예를 들어 더 긴 컨텍스트, 다중 홉 추론 및 간접 증거에서 답변을 유추하는 기능을 테스트하는 것이 좋습니다.
  • 악의적인 사용자의 악의적인 시나리오를 테스트하는 것이 좋습니다.
  • 평가 집합에 포함할 질문 수에 대한 구체적인 지침은 없지만 고품질 데이터의 명확한 신호는 일반적으로 약한 데이터의 시끄러운 신호보다 더 잘 수행됩니다.
  • 인간이 대답하는 경우에도 매우 어려운 예를 포함하는 것이 좋습니다.
  • 범용 애플리케이션을 빌드하든 특정 도메인을 대상으로 하든 앱에 다양한 질문이 발생할 수 있습니다. 평가 집합은 이를 반영해야 합니다. 예를 들어 특정 HR 질문에 대한 애플리케이션을 만드는 경우 애플리케이션이 환각되거나 유해한 응답을 제공하지 않도록 다른 도메인(예: 작업)을 테스트하는 것이 좋습니다.
  • 고품질의 일관된 인간 생성 레이블은 애플리케이션에 제공하는 기본 진리 값이 원하는 동작을 정확하게 반영하도록 하는 가장 좋은 방법입니다. 고품질 휴먼 레이블을 보장하기 위한 몇 가지 단계는 다음과 같습니다.
    • 동일한 질문에 대한 여러 사용자 레이블러의 응답(레이블)을 집계합니다.
    • 레이블 지정 지침이 명확하고 사용자 레이블 지정자가 일관성이 있는지 확인합니다.
    • 사용자 레이블 지정 프로세스에 대한 조건이 RAG 애플리케이션에 제출된 요청 형식과 동일한지 확인합니다.
  • 예를 들어 질문의 해석이 다르기 때문에 사람 레이블은 본질적으로 시끄럽고 일관성이 없습니다. 이는 프로세스의 중요한 부분입니다. 사용자 레이블 지정을 사용하면 고려하지 않은 질문의 해석이 표시될 수 있으며, 이는 애플리케이션에서 관찰하는 동작에 대한 인사이트를 제공할 수 있습니다.