“앱 구축하는 것보다 어렵다” LLM을 테스트하는 4가지 전략

AI 코파일럿을 사용한 수작업 감소, 코드 생성기를 사용한 소프트웨어 개발자 생산성 향상 등 생성형 AI를 통한 혁신에 많은 관심과 기대가 집중되고 있다. 비즈니스 기회를 본 많은 개발팀이 벡터 데이터베이스로 지식 기반을 구축하고 애플리케이션에 LLM(Large Language Model)을 집어넣고 있다.
 

LLM 기능을 사용한 애플리케이션 구축의 일반적인 사용례는 검색 경험, 콘텐츠 생성, 문서 요약, 챗봇, 고객 지원 애플리케이션 등이다. 산업 분야별로 구체적으로 보면 의료 분야의 환자 포털 개발, 금융 서비스 분야의 실무자 워크플로우 개선, 제조 분야의 미래 공장을 위한 토대 마련 등이 대표적이다. 

LLM에 투자하는 기업은 데이터 품질에 대한 데이터 거버넌스 개선, LLM 아키텍처 선택, 보안 위험 해결, 클라우드 인프라 계획을 포함한 몇 가지 장애물에 직면하게 된다. 특히 필자는 기업에서 LLM 모델과 애플리케이션 테스트를 어떻게 계획하고 있는지 우려된다. 뉴스를 보면 챗봇이 제안한 환불을 수용한 항공사, 저작권 침해에 대한 소송, 환각 위험 감소 등 LLM의 이면이 심심찮게 등장하기 때문이다.  

소프트웨어 개발 업체 로즈(Roadz)의 공동 창업자이자 COO인 아미트 자인은 "LLM 모델을 테스트하려면 기술적 엄격함 이상의 다면적 접근 방법이 필요하다. 팀은 반복적인 개선을 통해 모델의 개발 프로세스, 테스트 방법론, 성능 메트릭을 기록하는 세부적인 문서를 만들어야 한다. 베스트 프랙티스를 벤치마크하고 공유하기 위해 연구 커뮤니티와 교류하는 것도 효과적"이라고 말했다.

임베디드 LLM을 위한 4가지 테스트 전략

개발팀에는 LLM 테스트 전략이 필요하다. 맞춤형 애플리케이션에 내장되는 LLM을 테스트하기 위한 출발점으로 고려할 만한 방법은 다음과 같다.
 

• 소프트웨어 QA 확장을 위한 테스트 데이터 만들기
• 모델 품질 및 성능 테스트 자동화
• 사용례를 기반으로 RAG 품질 평가
• 품질 메트릭 및 벤치마크 개발

1. 소프트웨어 QA 확장을 위한 테스트 데이터 만들기

대부분 개발팀에서는 일반화된 LLM을 만들 일은 없다. 특정 최종 사용자 및 사용례를 위한 애플리케이션을 개발한다. 테스트 전략을 수립하려면 관련된 사용자 페르소나, 목표, 워크플로우, 품질 벤치마크를 이해해야 한다.

AI 기반 지식 검색 플랫폼 업체 마인드브리즈(Mindbreeze) CTO 제이콥 프라허는 "LLM 테스트의 첫 번째 요구사항은 LLM이 해결해야 할 작업을 이해하는 것이다. 이런 작업의 경우 테스트 데이터 집합을 구성해서 LLM 성능에 대한 메트릭을 설정할 수 있다. 그런 다음 프롬프트를 최적화하거나 모델을 체계적으로 미세 조정할 수 있다"라고 말했다.

예를 들어, 고객 서비스용으로 설계된 LLM에는 일반적인 사용자 문제와 최선의 응답으로 구성된 테스트 데이터 집합이 포함될 수 있다. 다른 LLM 사용례에는 결과를 간단히 평가할 방법이 없을 수 있지만, 개발자는 여전히 테스트 데이터를 사용해 검증할 수 있다.

데이터 분석 플랫폼 업체 솔릭스 테크놀로지(Solix Technologies)의 엔지니어링 VP 키쇼어 가디라주는 "LLM을 테스트하는 가장 안정적인 방법은 관련된 테스트 데이터를 만드는 것이지만 그러한 데이터 집합을 만들기 위한 비용과 시간이 문제다. 다른 모든 소프트웨어와 마찬가지로 LLM 테스트에는 단위, 기능, 회귀, 성능 테스트가 포함된다. 또한 LLM 테스트에는 편향성, 공정성, 안전성, 콘텐츠 제어, 설명 가능성 테스트도 필요하다"라고 조언했다.

2. 모델 품질 및 성능 테스트 자동화

테스트 데이터 집합이 준비되면 개발팀은 품질 목표, 위험, 비용 고려 사항에 따라 여러 테스트 접근 방법을 고려해야 한다. 데이터 라벨링 솔루션 업체 톨로카 AI(Toloka AI)의 CEO 올가 메고스카야는 "기업은 사람이 수행하는 평가에서 자동화된 평가 방법으로 전환하기 시작했다. 시간과 비용 효율성 측면에서 유리하기 때문이다. 그러나 자동화된 시스템이 놓칠 수 있는 미묘한 차이를 포착하는 것이 중요한 상황에서 여전히 도메인 전문가가 필요하다"라고 말했다.

자동화와 휴먼 인 더 루프(human-in-the-loop) 테스트 사이에서 적절한 균형점을 찾는 것은 개발자나 데이터 과학자에게 쉽지 않은 일이다. 데이터 오케스트레이션 플랫폼 업체 아스트로노머(Astronomer)의 데이터 과학 및 AI 부문 SVP 스티븐 힐리온은 "모델링 프로세스의 각 단계에서는 자동화된 벤치마킹을 사용하고 엔드 투 엔드 시스템에서는 자동화와 수동 검증을 혼합해 사용하는 방법을 권한다. 주 애플리케이션 릴리스에서는 거의 항상 최종적으로 테스트 집합에 대한 수동 검증이 필요하다. 특히 전체적인 품질 수준을 높이기 위해 새로운 임베딩, 새로운 모델 또는 새로운 프롬프트를 채택한 경우에는 더욱 그렇다. 많은 경우 이를 통해 얻는 개선은 포착하기가 어렵거나 주관적이기 때문"이라고 설명했다. 

강력한 LLM 테스트 플랫폼이 나오기 전까지는 수동 테스트가 신중한 조치다. 관계형 지식 그래프 관리 시스템 제공업체 릴레이셔널AI(RelationalAI)의 연구 ML 부문 VP인 니콜라스 바실로글로우는 "체계적인 테스트를 위한 최첨단 플랫폼은 없다. 신뢰성과 환각 측면에서 지식 그래프 질문 생성 봇이 최선의 솔루션"이라고 강조했다.

가디라주는 다음과 같은 LLM 테스트 라이브러리와 툴을 제안했다.
 

• AI 페어니스 360(AI Fairness 360) : ML 모델의 차별화, 편향성을 검사, 보고, 완화하는 데 사용되는 오픈소스 툴킷
• 딥이밸(DeepEval) : 파이테스트(Pytest)와 비슷한 오픈소스 LLM 평가 프레임워크지만 LLM 출력의 단위 테스트에 특화됨
• 베이스런(Baserun) : 모델의 디버깅, 테스트, 반복적 개선에 도움이 되는 툴
• 엔비디아 니모-가드레일(NeMo-Guardrails) : LLM 출력에 프로그램 가능한 제약 조건을 추가하기 위한 오픈소스 툴킷

IBM 데이터 및 AI의 데이터 과학 툴 및 런타임 책임자인 모니카 로밀라가 제시하는 엔터프라이즈 사용례의 2가지 LLM 테스트 영역은 다음과 같다.
 

• 모델 품질 평가 : 분류, 추출, 요약, 생성, RAG(Retrieval-Augmented Generation)과 같은 사용례에 대해 학술 및 내부 데이터 집합을 사용해서 모델 품질을 평가한다.
• 모델 성능 테스트 : 모델의 지연(데이터 전송 경과 시간)과 처리량(특정 시간 동안 처리된 데이터의 양)을 검증한다.

로밀라는 성능 테스트는 동시 요청의 수와 생성되는 토큰(모델이 사용하는 텍스트 뭉치)의 수, 2가지 핵심 매개변수에 따라 달라진다면서 "다양한 부하 크기와 유형을 테스트하고 기존 모델과 성능을 비교해서 업데이트가 필요한지 여부를 확인하는 것이 중요하다"라고 부연했다. 

데브옵스와 클라우드 설계자는 LLM 애플리케이션의 성능 및 부하 테스트를 수행하기 위한 인프라 요구사항을 고려해야 한다. SADA의 솔루션 엔지니어링 부문 이사인 헤더 순다임은 "LLM을 위한 테스트 인프라 배포에는 강력한 컴퓨팅 리소스, 스토리지 솔루션, 테스트 프레임워크 설정이 포함된다. 테라폼(Terraform)과 같은 자동화된 프로비저닝 툴, 깃과 같은 버전 제어 시스템이 재현 가능한 배포와 효과적인 협업에서 핵심적인 역할을 한다"라며, 안정적인 LLM 테스트를 위한 리소스와 스토리지, 배포 전략, 협업 툴 간의 균형의 중요성을 강조했다.

3. 사용례를 기반으로 RAG 품질 평가

LLM 정확도를 개선하기 위한 방법으로는 콘텐츠 중앙 집중화하기, 최신 데이터로 모델 업데이트하기, 쿼리 파이프라인에 RAG 사용하기 등이 포함된다. RAG는 LLM의 강력한 기능과 회사의 사유 정보를 결합하는 데 있어 중요하다.

일반적인 LLM 애플리케이션에서는 사용자가 프롬프트를 입력하면 앱이 이를 LLM에 전송하고, LLM이 응답을 생성하면 앱이 다시 사용자에게 이 응답을 전달한다. RAG에서는 앱이 프롬프트를 먼저 검색 엔진이나 벡터 데이터베이스와 같은 정보 데이터베이스로 전송해서 주제와 관련된 정보를 찾는다. 앱은 프롬프트와 이 컨텍스트 정보를 LLM으로 전송하고, LLM은 이를 사용하여 응답을 만들어 낸다. 즉, RAG는 LLM의 응답을 관련성 있고 맥락에 맞는 정보로 제한하는 역할을 한다.

프라이온(Pryon) CEO 이고르 자블로코프는 "RAG는 특히 핵심 인프라에서 소스 콘텐츠에 대한 검증 가능한 어트리뷰션(attribution)이 필요한 엔터프라이즈 스타일의 배포에 더 적합하다"라고 말했다.

RAG를 LLM과 함께 사용하면 환각이 감소하고 정확도가 개선되는 것으로 나타났다. 그러나 RAG를 사용할 경우 새로운 구성요소가 추가되고 이 구성요소의 관련성과 성능을 테스트해야 한다. 테스트 유형은 RAG와 LLM의 응답을 얼마나 쉽게 평가할 수 있는지, 그리고 개발팀이 최종 사용자 피드백을 어느 정도 범위까지 활용할 수 있는지에 따라 달라진다.

필자는 최근 포어소트(Forethought)의 CEO 디온 니콜라스와 이 회사의 생성형 고객 지원 AI에 사용되는 RAG를 평가하는 방법에 대해 이야기를 나눴다. 니콜라스가 말한 3가지 접근 방법은 다음과 같다.
 

• 질의에 대한 올바른 답으로 구성되어 모델 성능의 벤치마크 역할을 할 기준 데이터 집합 또는 사람이 레이블을 지정한 데이터 집합
• 강화 학습, 또는 챗봇과의 상호작용 이후 사용자의 만족도를 묻는 것과 같은 실제 시나리오에서 모델 테스트
• 적대적 네트워크, 또는 보조 LLM을 학습시켜 주 LLM의 성능을 평가. 이는 사람의 피드백에 의존하지 않고 자동화된 평가를 제공함

니콜라스는 "각 방법에는 장단점이 있으며, 사람의 노력과 오류를 간과할 위험 사이에서 균형이 필요하다. 최선의 시스템은 시스템 구성요소 전반에서 이런 방법을 활용하여 오류를 최소화하고 견고한 AI 배포를 촉진한다"라고 설명했다.

4. 품질 메트릭과 벤치마크 개발

테스트 데이터, 새로운 또는 업데이트된 LLM, 테스트 전략이 준비됐으면 다음 단계는 정해진 목표를 기준으로 품질을 확인하는 것이다.

컨트랙트팟Ai(ContractPodAi)의 최고 제품 책임자 아테나 레이아니는 "안전하고 신뢰할 수 있는 AI 개발을 위해서는 구체적이고 측정 가능한 KPI를 만들고 확실한 가드레일을 정립하는 것이 중요하다. 고려해야 할 기준은 정확성, 일관성, 속도, 도메인별 사용 사례와의 관련성 등이다. 개발자는 대상 도메인에서 전체 LLM 생태계와 운영 모델을 평가해서 정확하고 관련성 있고 포괄적인 결과를 제공하도록 해야 한다"라고 조언했다.

여러 LLM의 결과를 비교하기 위한 개방형 환경인 챗봇 아레나(Chatbot Arena)를 참고할 만하다. 챗봇 아레나는 경쟁 게임에서 플레이어의 순위를 매기는 데 자주 사용되는 알고리즘인 엘로(Elo) 레이팅 시스템을 사용하지만, 사람이 다양한 LLM 알고리즘 또는 버전의 응답을 평가할 때 효과적이다.

이뮤타(Immuta)의 연구 VP 조 레젠버거는 "특히 실제 환경에서 나타나는 쿼리에 대해 LLM을 강화할 때 사람의 평가는 테스트의 핵심적인 부분이다. 챗봇 아레나는 크라우드 소싱 테스트의 한 사례이며, 이런 유형의 인간 평가자 연구는 사용자 피드백 통합에 중요한 피드백 루프를 제공할 수 있다"라고 말했다.

IBM 데이터 및 AI 부문의 로밀라는 LLM의 사용례에 따라 다음과 같은 3가지 메트릭을 고려할 수 있다고 말했다.
 

• F1 점수 : 정밀도와 재현율에 대한 종합 점수로, LLM이 분류 또는 예측에 사용될 때 적용된다. 예를 들어 고객 지원 LLM이 고객에게 일련의 조치를 얼마나 잘 권장하는지를 평가할 수 있다.
• 루즈L(RougeL) : 요약 사용 사례에서 RAG와 LLM을 테스트하는 데 사용할 수 있지만 일반적으로 결과를 벤치마크하기 위해 사람이 만든 요약이 필요하다.
• 세이커블루(sacreBLEU) : 원래 언어 번역을 테스트하는 데 사용되던 방법으로, 현재 TER, ChrF, BERTScore 등의 다른 방법과 함께 LLM 응답의 정량적 평가에 사용된다.

일부 업계에는 고려해야 할 품질 및 위험 메트릭이 있다. 에이세라(Aisera)의 제품 관리 및 마케팅 담당 VP인 카틱 스즈는 "교육에서는 연령 적합성과 독성 회피 평가가 중요하지만 소비자와 접하는 애플리케이션에서는 응답 관련성과 지연이 우선 사항"이라고 말했다.

모델이 배포됐다고 해서 테스트가 끝나는 것은 아니다. 데이터 과학자는 최종 사용자의 반응, 성능 메트릭 및 기타 피드백을 받아 모델을 개선해야 한다. 앰플리튜드(Amplitude)의 엔지니어링 VP 겸 CISO인 더스틴 피어스는 "배포 후에는 결과를 행동 분석과 통합하는 것이 중요하다. 이를 통해 빠른 피드백을 얻고 모델 성능을 더 명확하게 측정할 수 있다"라고 말했다.

프로덕션에 대비하기 위한 중요한 단계는 애플리케이션에서 기능 플래그를 사용하는 것이다. AI 기술 기업인 앤트로픽, 캐릭터AI(Character.ai), 노션(Notion), 브렉스(Brex)는 기능 플래그를 사용해서 제품을 구축해 애플리케이션을 협업적으로 테스트하고 대규모 그룹에 서서히 기능을 도입하고 다양한 사용자 세그먼트에 실험을 타겟팅한다.

LLM 애플리케이션을 검증하기 위한 새로운 기법이 등장하고 있지만 구현하기 쉽거나 확실한 결과를 제공하는 기법은 없다. 현재로서는 앱 테스트와 개선 지원에 필요한 작업에 비하면 RAG와 LLM이 통합된 앱을 구축하는 것은 쉬운 부분일 수 있다.
editor@itworld.co.kr