Select a result to preview

AI Engineering - 4장: AI 시스템 평가하기

#devlog #ai-engineering

모델은 의도한 목적에 맞게 작동해야 유용하다. 모델은 애플리케이션의 용도에 맞게 평가가 진행되어야 함을 의미한다.

이번 장은 아래 세 가지를 살펴본다

  1. 앱 평가 기준을 정의하고 계산하는 방안
  2. 모델 선택방안 - 벤치마크 살펴보기, 벤치마크 선택하기, 리더보드 신뢰에 대해 생각해보기
  3. 애플리케이션 평가 및 개발방안

평가 기준

앱을 만들려 해도 앱 평가 기준이 명확해야한다. 이를 평가 주도 개발(evaluation-driven development)이라 한다. 이는 개발 전 평가 기준을 정의하는 것을 의미한다.

평가 주도개발 활용사례

이를테면 이렇게 활용될 수 있다:

  1. 추천 시스템 - 참여도, 구매전환률 증가로 성과 판단
  2. 사기 탐지 시스템 - 사기 예방으로 돈 절약
  3. 코딩 - 기능적 정확성으로 판단
  4. 파운데이션 모델 - 의도 분류, 감성 분석, 다음 행동 예측 등의 폐쇄형 작업 평가

앱에 맞는 평가기준을 잘 잡고 그걸로 시작해야한다. 이는 도메인 특화능력, 생성능력, 지시준수능력, 비용 및 지연시간으로 잡을 수 있다.

예를 들어, 모델에게 법률 계약서를 요약했다고 해보자. 큰 틀에서 보면, 도메인별 능력 지표는 모델이 법률 계약서를 얼마나 잘 이해하는지 알려준다. 생성 능력 지표는 요약이 얼마나 일관되고 충실한지 측정한다. 지시 준수 능력은 요약이 길이 제한 같은 요청된 형식을 제대로 지켰는지 보여준다. 비용과 지연 시간 지표는 이 요약에 얼마의 비용이 들고 얼마나 기다려야 하는지 알려준다.

도메인 특화 능력

내가 작업하고자 하는 업무 이해도를 가진 모델을 설계해야한다. 업무 이해도를 갖추는 것을 '도메인 특화 능력'이라고 지칭한다. 이는 모델 구조, 크기 등의 설정이나 학습에 쓰인 데이터에 따라 달라진다.

이 능력을 확인하기 위해 공개/비공개 도메인 특화 벤치마크로 확인할 수 있으며 점점 많아지는 추세다. 이를 테스트할 때는 정확성, 효율성, 가독성 등 주관/객관이 모두 고려되며 이런 능력은 객관식 문제 같은 폐쇄형 문제로 평가한다. 또한 대부분의 공개 벤치마크가 이런 방식을 따른다.

객관식 문제는 하나 이상의 정답이 있을 수 있다. 일반적인 지표는 모델이 맞힌 문제 수다.
분류는 모든 문제에서 같은 선택지를 사용하되 부정/중립/긍정 중 하나를 고르게 한다. 이 때는 정확도 외에도 F1 score, 정밀도, 재현율이 있다.

문제 생성도 비교적 수월하고 검증이 쉬우며 무작위 베이스라인에 비해 성능평가가 쉽지만, 문제와 선택지가 조금만 다르게 표현되어도 모델의 성능이 달라질 수 있다. Alzahrani(2024)[1] 등의 연구에 따르면 문제와 응답 사이 추가 공백이나 선택지: 같은 추가 지시 구문을 넣으면 모델이 답을 바꿀 수 있다는 사실이 발견되었다. 프롬프트 민감도와 프롬프트 엔지니어링 모범사례는 5장에서 살펴본다.

객관식은 좋은 응답, 나쁜 응답을 구별하는 분류법을 테스트하기 매우 좋고, 좋은 응답을 생성하는 능력을 평가하기에는 어려움이 있음에 유의하자.

생성 능력

생성형 AI 이전에도 AI는 개방형 출력을 생성하는데 쓰였다. 자연어 처리(NLP) 분야에서는 이런 개방형 출력의 품질을 평가하는 방안을 자연어 생성(NLG, natural language generation)으로 연구해왔다.

이때 당시의 지표는 유창성(fluency)와 일관성(coherence)이 포함되었다. 유창성은 문장이 문법적으로 올바르고 자연스럽게 들리는지(원어민이 쓴 것처럼 들리는지)를 측정한다. 일관성은 전체 텍스트가 얼마나 잘 구조화됐는지 (논리적 구조를 따르는지)를 측정한다

각 작업엔 이 뿐 아니라 고유 지표를 별도로 식별할 수 있다. 예를 들어, 번역 작업에서는 충실성(faithfulness)을 지표로 쓸 수 있다. 충실성은 번역문이 원문의 의미를 얼마나 잘 담아 냈는가를 확인한다. 요약에서는 관련성(relevance)을 평가할 수 있다. 관련성은 요약문이 원본 문서에서 가장 중요한 내용을 잘 다루고 있는가를 확인한다[2].

그렇지만 파운데이션 모델이 발전하며 이런 지표가 덜 중요해졌지만, 성능이 떨어지는 모델이나 창의적 글쓰기, 저자원 언어를 다루는 애플리케이션에서는 여전히 유용하다. 이런 유창성이나 일관성은 AI를 평가자로 활용하거나, 퍼플렉시티로 평가할 수 있다.

요즘은 원하지 않는 환각이나 사실관계의 일관성 같은 지표가 더 중요시된다. 제품의 개발방안에 따라 논쟁이 될 수 있는 부분을 판단하기도 한다.

사실 일관성과 비일관성

사실 비일관성(factual inconsistency)은 치명적인 결과를 초래할 수 있다. 따라서 많은 기법이 발견되었고 여기서는 개요를 살펴보자.

모델 출력의 사실 일관성은 두 방향으로 검증할 수 있다. 하나는 명시적으로 제공된 사실(컨텍스트)을 기준으로 검증하는 것이고, 다른 하나는 공개된 지식을 기준으로 검증하는 것이다.

모델의 출력이 얼마나 정확한지 평가하는 기준은 참조하는 정보의 범위에 따라 국소적 단위와 전역적 단위로 나뉜다.

이를 표로 정리하면 아래와 같다:

구분 평가 기준 우선순위 비유
국소적 주어진 입력 문서 컨텍스트 내 논리 "시험 문제지에 적힌 대로 답하기"
전역적 일반 상식 및 외부 데이터 보편적 사실 관계 "상식 퀴즈 풀기"

사실 일관성은 명시적 사실에 대해 확인하는 것이 훨씬 쉽다. 신뢰할 만한 출처가 제공되면 더 쉽게 확인할 수 있다. 컨텍스트가 주어지지 않으면 신뢰할 만한 출처를 찾고 사실도출 후 이에 맞게 진술을 확인해야 한다.

그렇다면 '무엇이 사실인가?' 라는 점을 잘 판단할 필요가 있다. 이를 위해 'AI 모델이 어떤 증거를 설득력있다고 판단하는가?'에 대한 연구가 이어지고 있다.

환각을 측정하는 지표를 설계할 때는 모델의 출력 결과를 분석해 어떤 종류의 질의에서 환각이 더 자주 발생하는지 파악하는 것이 중요하다. 따라서 벤치마크를 구성할 때는 이런 질의 유형에 더 집중해야 한다. 예를 들어, 이전에 필자가 진행했던 프로젝트에서 사용했던 모델은 다음 두 가지 유형의 질의에서 환각을 일으키는 경향을 보였다.

  1. 최소한의 지식을 요구하는 질의
  1. 존재하지 않는 정보를 묻는 질의

그럼 이어서 사실 일관성에 대해 평가하려면 '출력을 평가할 컨텍스트'를 이미 가지고 있어야 한다(이 컨텍스트 확보는 6장에서 다룬다). 3장에서 보았듯 AI 평가자는 사실 일관성을 포함해 무엇이든 평가할 수 있다. 이를 위해 이런 프롬프트를 활용할 수 있다:

사실 일관성: 요약문이 원문에서 뒷받침되지 않는 거짓이나 오해의 소지가 있는 내용을 
포함하고 있나요?
원문:
{{문서}}
요약:
{{요약}}
요약문에 사실 관계가 맞지 않는 내용이 있는가?
응답:

이를 위한 AI 판단기법은 자체검증과 지식강화 검증이 있다.

환각 검증 기법 (Hallucination Verification) - AI 모델의 응답 신뢰도를 높이기 위해 제안된 두 가지 주요 검증 프레임워크다.

자체 검증: SelfCheckGPT (Manakul et al., 2023) - 모델이 생성한 응답들 사이에 모순이 발생하는지 확인하여 환각 여부를 판단하는 기법이다.

지식 강화 검증: SAFE (Search-augmented Factuality Evaluator) - 구글 딥마인드가 제안한 기법으로, 검색 엔진(Google Search)의 실시간 데이터를 활용하여 응답의 사실 관계를 정밀하게 검증한다.

진술이 주어진 컨텍스트와 일치하는지 확인하는 것은 NLP의 텍스트 함의(textual entailment)로 표현할 수 있다. 이는 두 진술간의 관계를 파악하는 과정을 거치는 것이다. 전제(컨텍스트)가 주어지면 가설(출력 또는 출력의 일부)이 다음 범 주 중 어디에 속하나 살펴본다.

  1. 개별 사실로 문장 분리
  2. 문장을 독립적으로 수정
  3. 관련성을 확인
  4. 검색으로 평가

이 과정을 통해 함의/모순/중립을 도출한다. 각각 아래와 같다:

이러한 사실일관성은 RAG 시스템의 중요한 평가기준이다. 모델 컨텍스트 보강을 위해 외부 DB에서 관련 정보를 검색하는데, 이 응답은 검색된 컨텍스트와 사실 일관성이 있어야 한다.

안전성

OpenAI의 컨텐츠 중재 엔드포인트와 메타의 논문 LLaMA Guard (Iana et al., 2023)[3]의 분류법이 있다. AI 모델의 위험성과 시스템 안전 실제 방안은 5장에서 다룬다. 위험 컨텐츠는 아래와 같이 분류된다:

지시 수행 능력

이 모델이 주어진 지시를 얼마나 잘 따르는가를 살펴본다. 응답 자체를 넘어, 그 응답에 대한 구조를 잘 따르는 지를 보는 것이다. 단, 모델의 성능은 지시 품질에 따라 달라지므로 지시 품질 자체에 대한 검증을 하고서야 모델이 나쁜지를 파악할 수 있을 것이다.

지시 수행 기준

구글의 IFEval 이라거나 INFOBench 같은 지시로 점검할 수 있다. 예상에 맞는 형식을 준수하는지, 금지단어를 안쓰고 빈도를 어떻게 관리하는지 등.

이런 벤치마크로 모델이 지시를 얼마나 준수했는지를 캐치할 수 있다. 그렇지만 실 세계에서의 실태와는 차이가 있으므로 벤치마크 점수가 높다고 해서 항상 모델이 좋은 성능을 보이는 것은 아니다.

역할 연기

가상의 페르소나를 가정하도록 요청하는 것도 많이 일어난다. 이런 평가는 자동화가 어렵다. RoleLLM[4]과 CharacterEval[5]같은 요소가 있다. 이들은 연기 측면을 5점으로 평가하는 보상 모델을 가지거나 유사도 점수와 AI 평가자를 활용하여 모델이 페르소나를 얼마나 잘 모방하나 평가한다.

역할마다 AI 평가자에게 다른 프롬프트가 필요하다. AI 평가자의 프롬프트가 어떤 모습인지 감을 잡을 수 있도록, 특정 역할 수행 능력을 기준으로 모델의 순위를 매기는 RoleLLM AI 평가자의 프롬프트 일부는 아래와 같다:

시스템 지시:
당신은 역할 연기 수행 비교 도우미입니다. 모델의 응답에서 나타나는 역할 특성과 텍스트 품질을 기준으로 순위를 매겨야 합니다. 순위는 파이썬 딕셔너리와 리스트를 사용해 출력합니다.

사용자 프롬프트:
아래 모델들은 '{역할_이름}'역할을 수행해야 합니다. {역할_이름}의 역할 설명은 {역할_설명과_특징적인_표현},입니다. 다음 두 가지 기준에 따라 모델의 순위를 매겨주세요. 어떤 모델이 더 뚜렷한 역할 말투를 보이고, 역할 설명에 더 부합하게 말하는지. 말투가 독특할수록 좋습니다. 어떤 모델의 출력이 해당 역할과 관련된 지식과 기억을 더 많이 포함하는지. 더 풍부할 수록 좋습니다. (질의에 참조 응답이 포함되어 있다면, 역할별 지식과 기억은 참조 응답을 기준으로 합니다.)

비용과 지연 시간

고품질이지만 너무나 느리고 비용이 많이 드는 모델은 쓸모없다. 품질/지연시간/비용의 삼박자의 균형을 내게 맞게 맞추는 것이 더 중요하다. (9장에서 자세히 다룬다)

이 목표를 최적화하는 연구를 파레토 최적화(Pareto optimization)라고 한다. 여러 목표를 최적화할 때는 각 목표에 대해 타협 가능한 수준을 명확히 정해야 한다. 예를 들어, 지연 시간을 타협할 수 없다면, 먼저 각 모델의 예상 지연 시간을 확인하고, 지연 시간 요구사항을 충족하지 못하는 모델을 모두 제외한 다음, 남은 모델 중에서 가장 좋은 것 을 선택하면 된다.

파운데이션 모델의 지연 시간 지표는 첫 토큰까지 걸리는 시간, 토큰당 시간, 토큰 간 시간, 질의당 시간 등 여러 가지가 있다. 각 목표에 따라 어떤 지연 시간 지표가 중요한지 이해하는 게 중요하다.

지연 시간은 기반 모델뿐 아니라 각 프롬프트와 샘플링 변수에도 영향을 받는다. 자기회귀 언어 모델은 보통 토큰을 하나씩 생성하므로 생성해야 할 토큰이 많을수록 전체 지연 시간이 길어진다.

파운데이션 모델은 API로 호출하기 때문에 토큰 단위의 비용책정이 이루어지고, 이를 절감하는 것이 곧 비용절감의 핵심이다.

자체 모델 운용의 경우, 메모리구성을 최대한 활용한다. 이런 모델들이 7B, 65B인 것은 GPU가 16GB, 24GB, 48GB, 80GB라 그렇다.

모델 선택

모델이 얼마나 좋은가? 는 사실 별 의미없는 고민이었다. 애플리케이션에 적절한 모델을 고르는 것이 훨씬 중요하다. 앱의 기준점이 잡혔다면 이 기준에 따라 모델을 평가해야 한다.

앱 개발을 하며 모델을 반복적으로 선택해야 한다. 실현가능성을 위해 가장 성능이 좋은 모델로 시작했다가, 작은 모델로 가능했다가를 반복해야 한다. 모델을 직접 깎는다면 작은 모델로 시작했다가 하드웨어 제약조건에 맞는 모델로 확장할 수 있다.

즉, 아래 과정이 되겠다:

  1. 달성할 수 있는 최고 성능 확인하기
  2. 비용-성능 축에 모델을 배치하고 ROI가 높은 모델 고르기

모델 선택 과정

하드속성과 소프트속성으로 갈린다.

하드 속성은 모델 제공업체의 결정(라이선스, 학습 데이터, 모델 크기)또는 자체 정책 (개인 정보 보호, 제어)의 결과인 경우가 많다. 일부 활용 사례에서는 하드 속성 때문에 사용 가능한 모델의 풀이 크게 줄어들 수 있다.

소프트 속성은 정확도, 유해성, 사실 일관성과 같이 개선할 수 있는 속성이다. 특정 속성을 얼 마나 개선할 수 있는지 추정할 때는 낙관적인 태도와 현실적인 태도 사이에서 균형을 맞추기가 까다로울 수 있다.

전반적으로는 아래 단계로 구성이된다.

  1. 하드 속성(Hard Constraints) 필터링 - 모델의 성능을 논하기 전에, 프로젝트의 물리적·비즈니스적 제약 조건을 만족하는지 검토한다.

    • 비용(Budget): API 호출 단가 또는 GPU 인프라 유지비.
    • 지연 시간(Latency): 사용자 경험을 해치지 않는 응답 속도.
    • 보안 및 규제: 데이터 전송 가능 여부 및 라이선스 정책.
    • 배포 환경: 자체 호스팅 시 가용 VRAM 용량 등 하드웨어 사양.

  2. 공개 정보 기반의 후보군 압축 - 이미 검증된 리더보드와 벤치마크 성능을 활용해 실험할 가치가 있는 모델을 선정한다.

    • 리더보드 참조: MMLU(텍스트), FID/CLIP Score(이미지), VBench(비디오) 등.
    • 트레이드오프 분석: 모델 품질, 지연 시간, 비용 사이의 균형점을 고려하여 유망한 후보를 3~5개로 추린다.

  3. 자체 평가 파이프라인 실험 - 선정된 후보 모델들이 **'우리 서비스의 특수 목적'**에 실제로 부합하는지 정량적으로 검증한다.

    • 전용 데이터셋: 서비스 시나리오를 반영한 프롬프트 세트 구축.
    • 객관적/주관적 평가: AI 평가자(LMM Judge)와 사람의 교차 검증을 통해 최적의 모델을 최종 낙점한다.

  4. 운영 환경 모니터링 및 피드백 루프 - 도입된 모델이 실제 환경에서 지속적으로 제 성능을 내는지 감시하고 개선한다.

    • 실패 감지: 환각, 물리적 왜곡, 성능 저하(Model Drift) 실시간 모니터링.
    • 데이터 플라이휠: 사용자의 피드백을 수집하여 평가셋을 업데이트하고 시스템을 고도화한다.

이 과정은 순환적으로 처리한다. 하다보면 모델을 바꾼다거나 하는 식으로 의사전환이 빠르게 일어날 수도 있다. 또한 10장에서는 모니터링, 사용자 피드백 수집을 하는 방안도 함께 살펴본다.

모델 자체 개발 vs 사용 모델 구매

기술을 활용할 때 기 업들이 늘 마주치는 고민은 직접 개발할지 구매할 것인가다. 대부분의 기 업이 처음부터 파운데이션 모델을 개발하지는 않을 것이므로, 이 고민은 상용 모델 API를 사용 할지 아니면 오픈 소스 모델을 직접 호스팅할지로 좁혀진다. 이 고민에 대한 결론은 후보 모델 풀을 크게 줄일 수 있다.

오픈 소스, 오픈 가중치, 모델 라이선스

모델을 다운로드 받을 수 있으면 오픈소스모델이라고 하는데, 혹자는 모델의 성능은 학습데이터로부터 오니, 학습데이터 또한 공개해야 오픈된 모델이라 하는 사람도 있다. 이는 학습데이터에 대한 접근권리를 요구하는 것으로도 확장될 수 있다. 이런 다양한 관점을 놓고보아 데이터 없이 공개된 모델은 ‘오픈 웨이트’, 데이터와 함께 공개된 모델은 ‘오픈 모델’로 부른다.

현존 공개모델은 어지간해선 오픈웨이트에 불과하다. 학습 데이터를 공개했다가 일어나는 법적 분쟁때문이다.

또한 라이센스도 중요한 제약이다. 상업적 활용여부를 체크하자.

오픈 소스 모델과 모델 API 비교

사용자가 모델에 접근하려면 이를 호스팅하고 실행할 서버가 필요하다. 모델을 호스팅하고 사용자의 질의를 받아서, 모델을 실행해 질의에 대한 응답을 생성하고, 이 응답을 사용자에게 반환하는 서비스를 추론 서비스라고 한다. 사용자가 상호작용하는 인터페이스를 모델 API라고 한다. 모델 API라는 용어는 일반적으로 추론 서비스의 API를 지칭 하지만, 파인튜닝 API나 평가 API와 같은 다른 모델 서비스를 위한 API도 있다. (9장에서 후술)

모델 API를 바꾸는 것은 매우 큰 내용이므로, 전환시 테스트는 필수적으로 처리해야 한다. 독점 API를 통해 사용하고, 리밋이나 제약은 없는지 이런 부분 하나하나를 잘 신경써야한다.

모델을 호스팅하건, 모델 API를 쓰건 활용사례에 따라 다르게 접근된다. 아래 사항들은 반드시 고려되어야 한다.

데이터 프라이버시

데이터 반출여부, 누출여부 등의 민감성을 캐치하기

데이터 계보와 저작권

모델의 데이터 학습계보(어떻게 학습되어왔고 어떤 식으로 모델에 쓰이게 되었는지)를 파악해야한다. 최소한 흐름이라도 이해해야하는데, 이게 되어야 AI 관련 지적재산권법에 어떻게 저촉될지 여부가 틀어진다. AI 앱의 특허는 혁신에 대한 사람의 기여도가 특허를 받기에 충분한지에 따라 달려있다.

성능

5샷 MMLU 벤치마크를 보면 오픈소스모델과 독점모델의 차이가 좁혀지고 있다고 한다. 그렇지만 강력한모델로는 그냥 장사하고 약한모델은 오픈소스로 푸는 게 기업의 입장에서 수지타산이 맞지 않을까.

기능

모델에 필요한 기능을 살펴보자.

모델 API를 쓰면 그 API가 되는 기능만 쓸 수 있다. 직접적으로 로그프롭(logprobs)같은 게 있다. 하지만 보통은 못쓰거나 제한적으로 쓸 수 있다. 이는 7장에서 다룬다.

API 비용 vs 엔지니어링 비용

호스팅 비용과 ML 클러스터 구성 및 엔지니어링 비용 모두 부과된다. 이를 잘 생각해야 한다.

제어, 접근성, 투명성

제어와 커스터마이징 때문에 기업들이 오픈소스 모델을 사용하길 원한다 통제권이 얻어지니까. 상용모델 중심이면 이것에 완전히 휘둘릴 수 밖에 없다.

온디바이스 배포

모종의 사유로 디바이스에 모델을 심을 때는 서드파티 API를 사실상 못쓴다. 그건 그냥 로컬에서 구동하는 게 답일 수 밖에 없다.

공개 벤치마크 탐색하기

세상에 널린 벤치마크 중 도움이 되는 도구는 평가 하네스(evaluation harness)이다. EleutherAI의 Im-evaluation-harness는 400개 이상의 벤치마크를 지원한다. 오픈AI의 evals는 약 500개의 기존 벤치마크를 실행하고 오픈AI 모델을 평가하기 위한 새로운 벤치마크를 등록할 수 있게 해준다. (2023년 경에도 이랬다는 것)

벤치마크 선택 및 집계

어쨌거나 핵심은 나만의 벤치마크에 대한 리더보드가 구성되어야 한다는 것이다.

공개 리더보드

벤치마크 개선사항 (updated June 2024)

  • GPQA
  • MuSR
  • BBH
  • IFEval

공개 벤치마크로 맞춤형 리더보드 만들기

공개 벤치마크로 모델을 평가할 때는, 이 과정의 목적이 자체 벤치마크와 평가 지표로 더 엄격 히 실험할 모델을 추려내는 것임을 명심해야 한다. 이는 공개 벤치마크가 애플리케이션의 필요 를 완벽히 반영하지 못할 수 있고, 오염되었을 가능성이 높기 때문이다.

공개 벤치마크의 데이터 오염

여러 번 기술하였듯 무작위 수집된 데이터로 인해 오염이 발생될 수 있을 가능성이 높다. 모델에 답안지를 가르쳐줘서 벤치마크 점수가 높게 나올 수도 있다. 테스트세트로 학습을 해서 답을 잘 맞추는 케이스도 있다.

평가 파이프라인 설계하기

이번 절 에서는 개방형 과제 평가에 초점을 맞춘다. 한편 폐쇄형 과제 평가는 더 쉬우며, 개방형 과제 평가를 이해하면 폐쇄형 파이프라인도 쉽게 유추할 수 있다.

1단계: 시스템의 모든 구성요소 평가하기

애플리케이션의 구성요소를 해제한다. 과제별, 단계별, 중간 출력별 등 다양한 수준에서 살펴볼 수 있다.

엔드투엔드 출력과 각 구성 요소의 중간 출력을 독립적으로 평가해야 한다. 이력서 PDF에서 현재 직장을 추출하는 애플리케이션을 예로 들어보자. 이는 다음 두 단계로 작동한다.

  1. PDF에서 모든 텍스트를 추출한다.
  2. 추출한 텍스트에서 현재 직장을 찾아낸다

모델이 현재 직장을 제대로 추출하지 못한다면, 이는 두 단계 중 어느 단계 때문일 수 있다. 각 구성 요소를 독립적으로 평가하지 않으면 시스템이 정확히 어디서 실패하는지 알 수 없다. 첫 번째 PDF-텍스트 변환 단계는 추출된 텍스트와 실제 텍스트의 유사도로 평가할 수 있다. 두 번째 단계는 정확도로 평가할 수 있다. 만약 텍스트가 정확하게 추출되었다면, 이 기능은 현재 직장을 얼마나 정확하게 찾아낼까?

가능하다면, 애플리케이션을 턴별로 그리고 작업별로 모두 평가해야 한다. 하나의 턴은 여러 단계와 메시지로 구성될 수 있다. 시스템이 결과물을 생성하기 위해 여러 단계를 거치더라도 이는 여전히 하나의 턴으로 간주된다.

턴 기반 평가(turn-based evaluation)는 각 출력물의 품질을 평가한다. 반면 작업 기반 평가는 시스템이 작업을 완료했는지를 평가한다. 애플리케이션이 버그 수정에 도움이 되었는가? 작업을 완료하 는 데 몇 번의 대화가 필요했는가? 시스템이 문제를 2번만에 해결하는 것과 20번만에 해결하 는 것은 큰 차이가 있다

2단계: 평가 가이드라인 만들기

만드는 앱에서 뭐가 나쁜건지를 짚어내야 한다.

평가 기준 정의하기

'좋다'란 평을 들을 수 있는 것이 무엇인지 정하는 것이 필요하다. 쓰는 사람이 뭐가 필요할지, '이거 좋네' 소리 들으려면 뭘 해야되는지를 파악해야한다.

뭐가 좋은 응답을 만드는 것일지도 생각해봐야 한다. 랭체인의 현황에 따르면, 사용자에게는 2-3개의 유형에 해당하는 피드백을 사용했다.

고객 지원 애플리케이션을 예로 들면 좋은 응답이 이런 식으로 도출될 것이다.

예시와 함께 평가 기준표 만들기

3장에서 살펴본 평가 기준표를 사용해서 각자의 기준표를 만들어보자.

평가 지표를 비즈니스 지표와 연결하기

비즈니스 지표에 대한 정량적 수치가 나와야 한다. 뻔하다면 뻔하지만, 수립하고 앱개발하는 것과 그렇지 않은 것은 너무나 차이가 크다.

3단계: 평가 방법과 데이터 정의하기

평가 방법 선택하기

서로 다른 기준에는 서로 다른 평가 방법이 필요할 수 있다. 이를테면

평가 데이터 주석 달기

턴 기반 평가와 작업 기반 평가, 둘 다 시스템의 각 구성 요소와 각 기준을 평가하기 위해 주석이 달린 데이터가 필요하다. 가능하다면 실제 운영 환경의 데이터를 사용하자. 애플리케이션에 사용할 수 있는 자연스러운 레이블이 있다면 좋다. 그렇지 않다면, 사람 또는 AI를 사용해 데이터에 레이블을 지정할 수 있다.

상용 모델에서는 그게 어려울 수 있으니 이런 식의 접근을 할 수 있겠다:

저장 필드 데이터 성격 활용 목적 (Engineering Value)
Input Prompt 원시 데이터 어떤 입력에서 실패/성공이 잦은지 패턴 분석
Generated Output 결과물 (S3 링크 등) 나중에 AI 평가자나 사람이 재검토할 대상
User Feedback 자연스러운 레이블 사용자의 만족도를 직접적인 '정답'으로 활용
AI Judge Score 자동 주석 실시간 품질 모니터링 및 대시보드 시각화
Latency/Cost 메타데이터 성능 대비 비용 효율성(ROI) 계산

평가 파이프라인 평가하기

  1. 지표와 비즈니스 결과의 정렬 (Alignment)- 평가 점수가 높다고 해서 반드시 좋은 서비스는 아니다. 지표가 실제 비즈니스 가치와 연결되는지 확인해야 한다.
    • 상관관계 확인: 더 나은 응답(고득점)이 실제로 사용자의 높은 만족도나 유지율(Retention)로 이어지는가?
    • 실효성 검증: 평가 지표의 개선이 실제 비즈니스 KPI(결제율, 다운로드 수 등)의 상승을 견인하는가?
  2. 평가의 재현성과 신뢰성 (Reliability & Reproducibility) - 동일한 조건에서 실행했을 때 일관된 결과가 나와야 공학적인 '기준'이 될 수 있다.
    • 결과 일관성: 같은 파이프라인을 두 번 실행했을 때 점수가 달라지는가?
    • 분산 관리: 서로 다른 데이터셋으로 여러 번 실행했을 때, 결과의 분산(Variance)이 수용 가능한 범위 내에 있는가?
    • 일관성 유지 전략: AI 평가자(LMM Judge)를 사용할 경우, 확률적 변수를 최소화하기 위해 온도(Temperature) 파라미터를 0으로 설정하는 것이 필수적이다.
  3. 지표 간 상관관계 분석 (Correlation Analysis) - 불필요한 중복을 제거하고 지표의 희소성을 확보해야 한다.
    • 중복 제거: 두 지표가 너무 높은 상관관계를 보인다면, 리소스 낭비를 막기 위해 하나만 선택한다.
    • 통찰력 확보: 만약 두 지표 사이에 상관관계가 전혀 없다면, 모델의 새로운 특징을 발견한 것이거나 혹은 특정 지표가 신뢰할 수 없다는 신호일 수 있다.
  4. 비용과 지연 시간의 균형 (Cost & Latency) - 평가는 견고해야 하지만, 서비스 운영에 방해가 될 정도로 무거워서는 안 된다.
    • 트레이드오프: 정교한 평가는 비용과 지연 시간을 발생시킨다. 하지만 지연 시간을 줄이기 위해 평가를 아예 생략하는 것은 **"보이지 않는 곳에서 시스템이 무너지는 것을 방치하는 위험한 도박"**이다.
    • 효율적 설계: 모든 생성물에 대해 전수 조사를 할 것인지, 혹은 샘플링을 통해 부분 평가를 할 것인지 전략적으로 결정해야 한다.

반복

요구사항과 사용자 행동이 변화하면서. 평가 기준도 진화할 것이고 평가 파이프라인을 반복적으로 개선해야 할 것이다. 평가 기준을 업데이트하고, 평가 기준표를 변경하고, 예시를 추가하거나 제거해야 할 수도 있다. 반복이 필요하지만, 평가 파이프라인에서는 일정 수준의 일관성을 기대할 수 있어야 한다.

마무리

신뢰할 수 있는 평가 파이프라인 구축은 AI 도입의 리스크를 줄이고 성능 개선의 기회를 제공하는 필수적인 과정이다. 최근에는 모델 자체의 개발보다 애플리케이션의 목적에 맞는 적합한 모델을 선택하는 것이 개발자의 핵심 과제가 되었으며, 이를 위해 사실 일관성, 안전성, 유창성 등 전통적 NLP에서 진화한 다양한 기준들이 평기에 활용된다. 또한 데이터 프라이버시, 성능, 비용 등 7가지 측면을 고려하여 모델 직접 호스팅과 API 사용 중 최적의 접근 방식을 결정하는 과정이 수반되어야 한다.

공개 벤치마크나 리더보드는 부적격한 모델을 걸러내는 데 유용하지만, 학습 데이터 오염 가능성과 집계 방식의 불명확성 때문에 특정 애플리케이션에 최적화된 모델을 찾는 데는 한계가 있다. 따라서 자신의 요구사항에 맞춘 '개인 리더보드'를 구축하는 것이 중요하며, 단일 지표의 편향성을 극복하기 위해 여러 평가 방법을 병행하는 다각적인 접근이 필요하다. 이러한 평가 체계는 개발 전반에 걸쳐 검색 시스템, 에이전트, 메모리 사용량 및 사용자 피드백 검증 등으로 확장되며 지속적으로 수행된다.

  1. https://arxiv.org/abs/2402.01781 ↩︎

  2. https://arxiv.org/abs/2203.05227 ↩︎

  3. https://arxiv.org/abs/2312.06674 ↩︎

  4. https://arxiv.org/abs/2310.00746 ↩︎

  5. https://arxiv.org/abs/2401.01275 ↩︎