LLM 기능 도입 평가서 작성법과 템플릿

풀 문제를 사람의 일로 바꿔 쓰기

“LLM을 쓰자”는 평가 항목이 될 수 없습니다. 지금 사람이 하는 일이 무엇이고 한 달에 몇 번, 몇 분씩 드는지를 적습니다. 이 사이트에 모인 LLM 응용 주제 글은 4편이고, 그중 도입 사례는 2편입니다.

도입 사례에서 평가 대상 보기

우아한형제들은 다국어 번역을 LLM 기반 시스템으로 바꾸면서, 앱 업데이트 없이 서버 배포만으로 바꿀 수 있도록 했습니다. 평가서에서는 “정확도”만이 아니라 “배포 단위가 무엇인가”도 평가 항목으로 둡니다. 번역 품질을 평가하려면 전 메뉴와 옵션 데이터 가운데 어떤 표본을 쓸지 정해야 합니다.

컬리는 사내 도메인 지식을 LLM 위키와 RAG를 섞은 구조로 검색하게 했습니다. 이때 평가 데이터는 “검색이 맞는 문서를 찾았는가”와 “답이 그 문서에 근거했는가”를 따로 봐야 합니다.

실험은 도입과 구분하기

CyberAgent는 LLM이 다중 슬롯머신 문제를 풀 수 있는지 실험했습니다. 이런 글은 연구나 실험이지 운영 도입이 아닙니다. 평가서에서는 실험 결과를 근거로 쓰되, 운영 판단은 우리 데이터로 다시 측정해야 한다고 적습니다.

실패할 때의 대응 정하기

메타의 광고 검색 사례처럼 모델과 시스템을 함께 설계하는 경우에도 실패 대응은 따로 있어야 합니다. 평가서에는 잘못된 답이 나왔을 때 누가 보고, 기능을 어느 조건에서 끌지 적습니다.

템플릿(복사용)

## 1. 풀 문제

- 지금 사람이 하는 일, 그 일의 빈도와 시간

## 2. 평가 데이터

- 정답이 있는 예시 목록, 어떻게 만들었는지

## 3. 비용과 지연 시간

| 항목 | 목표 | 측정값 | 확인 방법 |
|---|---|---|---|
| 요청당 비용 | | | |
| 응답 지연 | | | |

## 4. 실패 시 대응

- 잘못된 답이 나왔을 때 사람이 보는 절차
- 기능을 끄는 조건

## 5. 되돌림 기준

- 품질 지표와 임계값