다음을 통해 공유

세트 평가

  • 아티클

Important

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

에이전트 애플리케이션의 품질을 측정하려면 고품질 응답의 특징을 지정하는 조건과 함께 대표적인 요청 집합을 정의할 수 있어야 합니다. 평가 집합을 제공하여 이 작업을 수행합니다. 이 문서에서는 평가 집합에 대한 다양한 옵션과 평가 집합을 만들기 위한 몇 가지 모범 사례를 설명합니다.

Databricks는 대표적인 질문과 근거 없는 답변으로 구성된 인간 레이블 평가 집합을 만드는 것이 좋습니다. 애플리케이션에 검색 단계가 포함된 경우 필요에 따라 응답의 기반이 될 것으로 예상되는 지원 문서를 제공할 수 있습니다. 평가 집합 작성을 돕기 위해 Databricks는 에이전트 평가에 직접 사용하거나 검토를 위해 주제 전문가에게 보낼 수 있는 인공으로 생성된 고품질의 질문과 기본 진실 답변을 생성하는 SDK를 제공합니다. 평가 집합을 합성하여을 참조하세요.

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

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

평가 집합의 필수 스키마는 에이전트 평가 입력 스키마를 참조하세요.

샘플 평가 집합

이 섹션에는 평가 집합의 간단한 예제가 포함되어 있습니다.

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

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 애플리케이션에 제출된 요청 형식과 동일한지 확인합니다.
  • 예를 들어 질문의 해석이 다르기 때문에 사람 레이블은 본질적으로 시끄럽고 일관성이 없습니다. 이는 프로세스의 중요한 부분입니다. 사용자 레이블 지정을 사용하면 고려하지 않은 질문의 해석이 표시될 수 있으며, 이는 애플리케이션에서 관찰하는 동작에 대한 인사이트를 제공할 수 있습니다.