//
현명한 비즈니스 결정은 여전히 투자 수익률을 기준으로 한다. 애플리케이션이 배포되려면 그 가치를 명확히 보여주어야 하고, 실제 운영 환경에서 널리 사용되는 엔터프라이즈 애플리케이션은 대부분 명확한 평가 기준을 가지고 있다.
소프트웨어 엔지니어링에서 TDD(Test Driven Development)가 테스트를 먼저 작성하듯, AI 엔지니어링에서는 평가 기준을 먼저 정의한 뒤 개발을 진행해야 한다. 평가 없이 프롬프트를 반복 수정하는 것은 테스트 없이 코드를 수정하는 것과 같다.
신뢰할 수 있는 평가 파이프라인을 구축할 수 있다면 많은 새로운 애플리케이션의 가능성이 열린다.
모델이 필요한 능력을 갖추었는지 평가한다. 객관식 문제(MCQ)로 체크하는 방식은 "지식"과 "추론" 평가에 적합하다.
생성된 응답에 대한 평가로, 핵심은 사실 일관성이다.
사실 관계를 평가하기 위한 정교한 기법으로 다음이 있다.
모델이 주어진 지시를 얼마나 잘 따르는지를 평가한다.
파레토 최적화는 여러 목표를 동시에 최적화하는 접근법이다. 여러 목표를 최적화할 때는 각 목표에 대해 타협 가능한 수준을 명확히 정해야 한다.
어떤 모델이 가장 좋은지보다, 애플리케이션에 가장 적합한 모델이 무엇인지가 중요하다.
전반적으로 네 단계의 깔때기 형태로 진행되며, 각 단계를 거칠수록 후보가 줄어든다.
각 기법에 대한 선택은 두 단계로 이뤄진다.
모델 공개 수준에 따른 분류가 있다.
비교 시 고려해야 할 요소들이 있다.
| 요소 | 설명 |
|---|---|
| 데이터 프라이버시 | 데이터가 외부로 나가는지 여부 |
| 데이터 계보와 저작권 | 학습 데이터의 출처와 법적 문제 |
| 성능 | 특정 작업에서의 능력 |
| 기능 | 확장성, 함수 호출, 출력 구조, 가드레일 |
| API 비용 vs 엔지니어링 비용 | 전체 비용 구조 비교 |
| 제어, 접근성, 투명성 | 모델에 대한 통제 수준 |
| 온디바이스 배포 | 엣지에서 실행 가능 여부 |
여러 벤치마크에서 모델을 평가하는 데 도움이 되는 도구는 평가 하네스(Evaluation Harness)로, 약 400개 이상의 벤치마크를 지원한다.
주요 리더보드로는 허깅페이스 리더보드, 스탠퍼드의 HELM 리더보드 등이 있다.
데이터 오염 문제도 있다. 벤치마크 데이터가 학습에 포함되어 올바르지 않은 평가 결과가 나올 수 있으며, n-gram 중복이나 퍼플렉시티로 오염을 감지한다.
AI 애플리케이션의 성공 여부는 좋은 결과와 나쁜 결과를 구분하는 능력에 달려 있다.
복합적인 AI 시스템에서는 최종 출력뿐 아니라 각 구성 요소를 개별적으로 평가해야 한다.
예를 들어, RAG 시스템이라면 검색기의 정밀도/재현율과 생성 모델의 응답 품질을 별도로 평가해야 한다. 검색이 잘못되면 아무리 좋은 생성 모델도 올바른 답을 내지 못한다.
평가 파이프라인에서 가장 중요한 단계다.
평가 기준표(Rubric)는 처음부터 완벽할 필요가 없다. 실제 출력을 보면서 반복적으로 개선하는 것이 핵심이다. 좋은 기준표의 특징은 서로 다른 평가자가 같은 출력에 대해 일관된 점수를 매기는 것이다.
이 장은 저자 스스로도 가장 어려운 주제였다고 말한다. 3장에서 다룬 평가 기술과 기준을 실제 파이프라인에 적용하는 것이 핵심이다. AI 엔지니어링은 평가 주도 개발 방식을 취하면서, 실패를 최소화하기 위해 계획적으로 접근해야 한다. 평가 기준으로 도메인 특화, 생성, 지시 수행, 비용과 시간을 다루고, 모델 선택과 벤치마크 활용, 그리고 체계적인 평가 파이프라인 설계까지 포괄적으로 살펴보았다.