애플리케이션별 평가 접근 방식

아래에서는 몇 가지 인기 있는 LLM 애플리케이션 유형의 평가에 대해 설명합니다.

​

에이전트

LLM 기반 자율 에이전트는 세 가지 구성 요소를 결합합니다: (1) 도구 호출, (2) 메모리, (3) 계획. 에이전트는 응답을 생성하기 위해 계획(예: 주로 프롬프팅을 통해)과 메모리(예: 주로 단기 메시지 기록)를 사용하여 도구 호출을 사용합니다. 도구 호출을 통해 모델은 두 가지를 생성하여 주어진 프롬프트에 응답할 수 있습니다: (1) 호출할 도구와 (2) 필요한 입력 인자. 아래는 LangGraph의 도구 호출 에이전트입니다. assistant node는 입력을 기반으로 도구를 호출할지 여부를 결정하는 LLM입니다. tool condition은 assistant node가 도구를 선택했는지 확인하고, 그렇다면 tool node로 라우팅합니다. tool node는 도구를 실행하고 출력을 도구 메시지로 assistant node에 반환합니다. 이 루프는 assistant node가 도구를 선택하는 동안 계속됩니다. 도구가 선택되지 않으면 에이전트는 LLM 응답을 직접 반환합니다. 이는 사용자가 자주 관심을 갖는 세 가지 일반적인 유형의 에이전트 평가를 설정합니다:

• 최종 응답: 에이전트의 최종 응답을 평가합니다.
• 단일 단계: 에이전트 단계를 독립적으로 평가합니다(예: 적절한 도구를 선택하는지 여부).
• 궤적: 에이전트가 최종 답변에 도달하기 위해 예상된 경로(예: 도구 호출의 경로)를 따랐는지 평가합니다.

아래에서는 이러한 평가가 무엇인지, 각각에 필요한 구성 요소(입력, 출력, 평가자), 그리고 언제 이를 고려해야 하는지 다룰 것입니다. 이러한 유형의 평가 중 여러 가지(전부는 아니더라도!)를 수행하고 싶을 가능성이 높습니다 - 이들은 상호 배타적이지 않습니다!

​

에이전트의 최종 응답 평가

에이전트를 평가하는 한 가지 방법은 작업에 대한 전반적인 성능을 평가하는 것입니다. 이것은 기본적으로 에이전트를 블랙박스로 취급하고 단순히 작업이 완료되었는지 여부를 평가하는 것을 포함합니다. 입력은 사용자 입력과 (선택적으로) 도구 목록이어야 합니다. 일부 경우에는 도구가 에이전트의 일부로 하드코딩되어 있어 전달할 필요가 없습니다. 다른 경우에는 에이전트가 더 일반적이며, 이는 고정된 도구 세트를 갖지 않고 런타임에 도구를 전달해야 함을 의미합니다. 출력은 에이전트의 최종 응답이어야 합니다. 평가자는 에이전트에게 요청하는 작업에 따라 달라집니다. 많은 에이전트는 상대적으로 복잡한 단계 세트를 수행하고 최종 텍스트 응답을 출력합니다. RAG와 유사하게, LLM-as-judge 평가자는 이러한 경우 평가에 종종 효과적입니다. 텍스트 응답에서 직접 에이전트가 작업을 완료했는지 평가할 수 있기 때문입니다. 그러나 이러한 유형의 평가에는 몇 가지 단점이 있습니다. 첫째, 실행하는 데 일반적으로 시간이 걸립니다. 둘째, 에이전트 내부에서 발생하는 어떤 것도 평가하지 않으므로 실패가 발생할 때 디버깅하기 어려울 수 있습니다. 셋째, 적절한 평가 지표를 정의하기 어려울 수 있습니다.

​

에이전트의 단일 단계 평가

에이전트는 일반적으로 여러 작업을 수행합니다. 종단 간 평가가 유용하지만, 이러한 개별 작업을 평가하는 것도 유용할 수 있습니다. 이것은 일반적으로 에이전트의 단일 단계, 즉 무엇을 할지 결정하는 LLM 호출을 평가하는 것을 포함합니다. 입력은 단일 단계에 대한 입력이어야 합니다. 무엇을 테스트하는지에 따라 이것은 단순히 원시 사용자 입력(예: 프롬프트 및/또는 도구 세트)일 수 있거나 이전에 완료된 단계를 포함할 수도 있습니다. 출력은 해당 단계의 출력으로, 일반적으로 LLM 응답입니다. LLM 응답에는 종종 도구 호출이 포함되어 있으며, 이는 에이전트가 다음에 취해야 할 작업을 나타냅니다. 이에 대한 평가자는 일반적으로 올바른 도구 호출이 선택되었는지에 대한 이진 점수와 도구에 대한 입력이 올바른지에 대한 휴리스틱입니다. 참조 도구는 단순히 문자열로 지정할 수 있습니다. 이러한 유형의 평가에는 몇 가지 이점이 있습니다. 개별 작업을 평가할 수 있으므로 애플리케이션이 실패하는 위치를 정확히 파악할 수 있습니다. 또한 실행 속도가 상대적으로 빠르며(단일 LLM 호출만 포함하기 때문에), 평가는 종종 참조 도구에 대한 선택된 도구의 간단한 휴리스틱 평가를 사용합니다. 한 가지 단점은 전체 에이전트를 캡처하지 않고 특정 단계만 캡처한다는 것입니다. 또 다른 단점은 데이터셋 생성이 어려울 수 있다는 것입니다. 특히 에이전트 입력에 과거 기록을 포함하려는 경우 더욱 그렇습니다. 에이전트 궤적의 초기 단계에 대한 데이터셋을 생성하는 것은 비교적 쉽지만(예: 입력 프롬프트만 포함할 수 있음), 궤적의 후기 단계에 대한 데이터셋을 생성하는 것은 어려울 수 있습니다(예: 이전의 많은 에이전트 작업 및 응답 포함).

​

에이전트의 궤적 평가

에이전트의 궤적을 평가하는 것은 에이전트가 취한 모든 단계를 평가하는 것을 포함합니다. 입력은 다시 전체 에이전트에 대한 입력(사용자 입력 및 선택적으로 도구 목록)입니다. 출력은 도구 호출 목록으로, “정확한” 궤적(예: 예상되는 도구 호출 시퀀스)으로 구성되거나 단순히 예상되는 도구 호출 세트(순서 무관)로 구성될 수 있습니다. 여기서 평가자는 취한 단계에 대한 일부 함수입니다. “정확한” 궤적을 평가하는 것은 시퀀스의 각 도구 이름에 대한 정확한 일치를 확인하는 단일 이진 점수를 사용할 수 있습니다. 이것은 간단하지만 몇 가지 결함이 있습니다. 때로는 여러 올바른 경로가 있을 수 있습니다. 또한 이 평가는 궤적이 단일 단계만큼 벗어난 것과 완전히 잘못된 것 사이의 차이를 캡처하지 않습니다. 이러한 결함을 해결하기 위해 평가 지표는 취한 “잘못된” 단계의 수에 초점을 맞출 수 있으며, 이는 가까운 궤적과 크게 벗어난 궤적을 더 잘 설명합니다. 평가 지표는 또한 예상되는 모든 도구가 순서에 관계없이 호출되는지 여부에 초점을 맞출 수 있습니다. 그러나 이러한 접근 방식은 도구에 대한 입력을 평가하지 않으며 선택된 도구에만 초점을 맞춥니다. 이를 고려하기 위해 또 다른 평가 기법은 전체 에이전트의 궤적(참조 궤적과 함께)을 메시지 세트(예: 모든 LLM 응답 및 도구 호출)로 LLM-as-judge에 전달하는 것입니다. 이것은 에이전트의 완전한 동작을 평가할 수 있지만, 컴파일하기 가장 어려운 참조입니다(다행히 LangGraph와 같은 프레임워크를 사용하면 도움이 될 수 있습니다!). 또 다른 단점은 평가 지표를 생각해내기가 다소 까다로울 수 있다는 것입니다.

​

검색 증강 생성 (RAG)

검색 증강 생성(RAG)은 사용자의 입력을 기반으로 관련 문서를 검색하고 이를 처리를 위해 언어 모델에 전달하는 강력한 기법입니다. RAG는 외부 지식을 활용하여 AI 애플리케이션이 더 정보에 입각하고 맥락을 인식하는 응답을 생성할 수 있도록 합니다.

​

데이터셋

RAG 애플리케이션을 평가할 때 핵심 고려 사항은 각 입력 질문에 대한 참조 답변이 있는지(또는 쉽게 얻을 수 있는지) 여부입니다. 참조 답변은 생성된 응답의 정확성을 평가하기 위한 정답 역할을 합니다. 그러나 참조 답변이 없는 경우에도 참조가 필요 없는 RAG 평가 프롬프트를 사용하여 다양한 평가를 수행할 수 있습니다(아래 예제 제공).

​

평가자

LLM-as-judge는 텍스트 간의 사실적 정확성이나 일관성을 평가하는 효과적인 방법이기 때문에 RAG에 일반적으로 사용되는 평가자입니다. RAG 애플리케이션을 평가할 때 참조 출력이 필요한 평가자와 그렇지 않은 평가자를 사용할 수 있습니다:

1. 참조 출력 필요: RAG 체인의 생성된 답변 또는 검색 결과를 참조 답변(또는 검색 결과)과 비교하여 정확성을 평가합니다.
2. 참조 출력 불필요: 참조 답변이 필요하지 않은 프롬프트를 사용하여 자체 일관성 검사를 수행합니다(위 그림에서 주황색, 녹색, 빨간색으로 표시됨).

​

RAG 평가 적용

RAG 평가를 적용할 때 다음 접근 방식을 고려하세요:

1. 오프라인 평가: 참조 답변에 의존하는 모든 프롬프트에 대해 오프라인 평가를 사용합니다. 이것은 참조가 정답인 RAG 답변 정확성 평가에 가장 일반적으로 사용됩니다.
2. 온라인 평가: 참조가 필요 없는 모든 프롬프트에 대해 온라인 평가를 사용합니다. 이를 통해 실시간 시나리오에서 RAG 애플리케이션의 성능을 평가할 수 있습니다.
3. 쌍별 평가: 서로 다른 RAG 체인에서 생성된 답변을 비교하기 위해 쌍별 평가를 활용합니다. 이 평가는 자체 일관성이나 정답 참조를 사용하여 평가할 수 있는 정확성보다는 사용자가 지정한 기준(예: 답변 형식 또는 스타일)에 초점을 맞춥니다.

​

RAG 평가 요약

평가자	세부사항	참조 출력 필요	LLM-as-judge?	쌍별 평가 관련
문서 관련성	문서가 질문과 관련이 있는가?	아니오	예 - 프롬프트	아니오
답변 충실성	답변이 문서에 근거하고 있는가?	아니오	예 - 프롬프트	아니오
답변 유용성	답변이 질문을 해결하는 데 도움이 되는가?	아니오	예 - 프롬프트	아니오
답변 정확성	답변이 참조 답변과 일치하는가?	예	예 - 프롬프트	아니오
쌍별 비교	여러 답변 버전을 어떻게 비교하는가?	아니오	예 - 프롬프트	예

​

요약

요약은 자유 형식 글쓰기의 한 가지 특정 유형입니다. 평가 목표는 일반적으로 일련의 기준에 따라 글쓰기(요약)를 검토하는 것입니다. 요약할 텍스트의 개발자 큐레이션 예제는 평가에 일반적으로 사용됩니다(데이터셋 예제는 여기를 참조하세요). 그러나 프로덕션(요약) 앱의 사용자 로그는 아래의 참조가 필요 없는 평가 프롬프트와 함께 온라인 평가에 사용할 수 있습니다. LLM-as-judge는 일반적으로 요약(및 기타 유형의 글쓰기) 평가에 사용되며, 제공된 기준을 따라 요약을 평가하는 참조가 필요 없는 프롬프트를 사용합니다. 요약은 창의적인 작업이고 가능한 올바른 답변이 많기 때문에 특정 참조 요약을 제공하는 것은 덜 일반적입니다. 참조가 필요 없는 프롬프트를 사용하기 때문에 온라인 또는 오프라인 평가가 가능합니다. 쌍별 평가는 서로 다른 요약 체인(예: 다른 요약 프롬프트 또는 LLM) 간의 비교를 수행하는 강력한 방법이기도 합니다:

사용 사례	세부사항	참조 출력 필요	LLM-as-judge?	쌍별 평가 관련
사실적 정확성	요약이 원본 문서에 비해 정확한가?	아니오	예 - 프롬프트	예
충실성	요약이 원본 문서에 근거하고 있는가(예: 환각 없음)?	아니오	예 - 프롬프트	예
유용성	요약이 사용자 요구에 비해 유용한가?	아니오	예 - 프롬프트	예

​

분류 및 태깅

분류 및 태깅은 주어진 입력에 레이블을 적용합니다(예: 유해성 감지, 감정 분석 등). 분류/태깅 평가는 일반적으로 아래에서 자세히 검토할 다음 구성 요소를 사용합니다: 분류/태깅 평가의 핵심 고려 사항은 참조 레이블이 있는 데이터셋이 있는지 여부입니다. 그렇지 않은 경우, 사용자는 입력(예: 텍스트, 사용자 질문 등)에 레이블(예: 유해성 등)을 적용하기 위해 기준을 사용하는 평가자를 정의하기를 원합니다. 그러나 정답 클래스 레이블이 제공되는 경우, 평가 목표는 정답 클래스 레이블에 대한 분류/태깅 체인의 점수를 매기는 데 초점을 맞춥니다(예: 정밀도, 재현율 등의 지표 사용). 정답 참조 레이블이 제공되는 경우, 정답 레이블을 체인 출력과 비교하기 위해 사용자 정의 휴리스틱 평가자를 단순히 정의하는 것이 일반적입니다. 그러나 LLM의 출현으로 인해 정답 참조 없이 지정된 기준에 따라 입력의 분류/태깅을 수행하기 위해 LLM-as-judge를 단순히 사용하는 것이 점점 더 일반적입니다. 참조가 필요 없는 프롬프트와 함께 LLM-as-judge를 사용하는 경우 온라인 또는 오프라인 평가가 가능합니다. 특히 사용자가 애플리케이션 입력(예: 유해성 등)을 태그/분류하려는 경우 온라인 평가에 적합합니다.

사용 사례	세부사항	참조 출력 필요	LLM-as-judge?	쌍별 평가 관련
정확도	표준 정의	예	아니오	아니오
정밀도	표준 정의	예	아니오	아니오
재현율	표준 정의	예	아니오	아니오

---