13. LLM 운영하기

 

 

 

1. MLOps

---

 

◯  DevOps

 

•  소프트웨어 개발과 운영의 협업과 자동화에 초점을 맞춘 방법

 

 

◯  MLOps

 

•  데이터와 머신러닝 모델이라는 2가지 핵심 요소를 DevOps에 더해 확장한 것

•  데이터 수집, 전처리, 모델학습, 평가, 배포, 모니터링 등 머신러닝 프로젝트의 전 과정을 자동화하고 효율화 하는 것 👉 데이터과학자와 엔지니어 간의 협업을 강화하고 모델의 품질과 안정성을 향상하며, 비즈니스 가치 실현까지의 시간을 단축할 수 있다. 

 

•  모델의 재현성 (Reproducibility)를 보장하는 것이 매우 중요하다. 이전에 수행된 ML Workflow를 그대로 반복했을 때 동일한 모델을 얻을 수 있는지 여부를 의미한다. 데이터와 모델, 코드의 버전관리가 이루어지고 모든 단계의 입력값과 파라미터를 추적하고 기록해야 한다. 

 

•  모델 학습을 자동으로 트리거하여 새로운 데이터로 지속적으로 모델을 업데이트한다. 

 

•  성능 저하 시 자동으로 재학습과 배포가 이루어지도록 함으로써 모델이 최적의 상태를 항상 유지하도록 만든다. 이는 DevOps의 지속적 통합/배포 (CI/CD) 개념을 머신러닝에 적용한 것이다. 

 

 

📍 데이터 준비 - 모델 학습 - 모델평가/저장소 - 모델 배포 - 모니터링 - 재학습 - 데이터 준비 ~ 

 

 

 

◯  1.1 데이터 관리

 

•  데이터 범위 선택, 전처리 방식, 피처 엔지니어링등의 방법에 따라 원천 데이터에서 다양한 버전의 데이터셋이 생성 

•  데이터셋의 버전을 관리하고 어떤 학습 데이터셋으로 모델을 학습시켰는지 기록 👉 Data Version Control (DVC)와 같은 도구를 사용할 수 있다. 

 

 

 

◯  1.2 실험 관리 

 

•  어떤 모델을 사용할지 결정, 하이퍼파라미터 최적화

•  실험관리 추적 도구를 사용 : MLflow, W&B

•  정확한 실험 추적을 통해 실험의 재현성을 갖춘다

 

 

◯  1.3 모델 저장소 

 

•   Model registry 는 머신러닝 모델을 체계적으로 관리하고 버전을 제어하는데 필수적이다. 머신러닝 파이프라인에서 다양한 실험을 통해 여러 버전의 모델이 생성되는데, 모델 저장소를 활용하면 다양한 모델을 하나로 통합해 관리할 수 있다. 모델 전체 수명 주기를 추적하고 관리할 수 있고 모델의 변경 이력을 기록하기 때문에 문제가 발생하는 경우 빠르게 이전 버전으로 되돌릴 수 있게 된다. 

 

•   모델의 메타 데이터 (생성일, 성능지표, 하이퍼파라미터) 를 저장해 모델에 대한 주요 정보를 쉽게 확인할 수 있게 한다. 모델 저장소와 연동해 모델을 서빙하고 배포하는 과정을 자동화하여 모델의 배포와 관리가 간소화된다. 

 

•   MLflow 모델 저장소, AWS Sagemaker 모델 저장소 등 

 

 

 

◯  1.4 모델 모니터링 

 

•   모델이 실제 환경에 배포된 후에도 지속적으로 의도한대로 작동하는지 모니터링 하는 것이 매우 중요하다. 데이터가 모델을 학습시켰을 때와 분포에 변화가 생길 수 있기 때문에 운영 과정에서 모델의 버전을 확인해야한다. 모델의 성능 뿐만 아니라 시스템의 기본적인 지표 (CPU, GPU, 지연 시간 등)을 기록해 시스템에 문제가 없는지, 추가적인 리소스의 확보가 필요한지, 낭비는 없는지 확인이 필요하다. 

 

•   대표적인 모니터링 도구로는 Prometheus, Grafana가 있고 AWS의 Sagemaker의 Model Monitor같은 관리형 서비스도 있다. 모니터링 도구로 입력 데이터부터 모델의 예측값, 시스템 성능까지 전방위적으로 모니터링하며 모델의 성능 저하를 조기에 포착하고 신속히 조치를 취할 수 있다. 

 

 

 

 

2. LLMOps

---

 

◯ 2.1  상업용 모델과 오픈소스 모델 선택하기

 

•   LLMOps에서 다루는 LLM은 기존 머신러닝 모델에 비해 훨씬 크고 OpenAI나 구글과 같은 일부 기업이 API기반으로 상업용 모델을 제공한다는 점이 가장 큰 차이점이다. 또한 ML은 평가지표가 명확하나, LLM은 생성 작업을 수행하기 때문에 결과물을 정량적으로 평가하기 어려워졌다.

 

•   대규모 언어모델 → (1) API를 통해 사용할 수 있는 상업용 모델, (2) 직접 모델을 학습시키고 실행해 활용할 수 있는 오픈소스 모델 

 

•   (1)과 같은 상업용 모델은 사용하는 만큼 비용이 발생하기 때문에 (토큰 당 과금방식) 비용 관리가 쉽지 않고 비싸다. 또한 대부분의 상업용 모델은 미세조정 기능을 지원하지 않거나 일부 모델만 지원하므로 사용자는 프롬프트 일부 하이퍼파라미터를 통해서만 모델을 커스터마이징 할 수 있다. 

 

•   (2)와 같은 오픈소스 모델은 직접 모델의 파라미터를 변경할 수 있어 미세조정이 가능하고 요구사항에 맞춰 추론 속도를 충분히 높일 수 있다. 그러나 직접 인프라를 관리해야 하므로 관련 인력과 다양한 실험이 필요하므로 기술적 난이도는 (1)보다 높다. 그러나 특정한 작업을 위해 미세조정을 하면 비용 효율적이면서 상업용 모델에 못지않은 성능을 달성할 수 있다. 

 

 

 

◯ 2.2  모델 최적화 방법의 변화 

 

•   LLM 최적화 방법 : 사전학습, 미세조정, 프롬프트 엔지니어링, RAG(검색 증강 생성) 

 

•   사전학습된 모델을 가져와 미세조정하는 '전이학습'을 기본으로 사용한다 : 지도미세조정, DPO (4장) 

 

•   LLM에 입력하는 프롬프트를 구조화해 원하는 결과를 얻는 프롬프트 엔지니어링을 사용할 수도 있다. 모델의 학습이 완료된 상태에서 프롬프르만으로도 상당한 성능 향상을 가져올 수 있으므로 LLM이 더 좋은 품질의 텍스트를 반환하도록 프롬프트를 구조화하는 프롬프트엔지니어링이 활발히 연구되고 있다. 입력하는 프롬프트에 따라 모델의 성능이 달라지므로, 프롬프트도 하이퍼파라미터 실험 대상이 된다. (W&B,MLflow에서 프롬프트 성능 추적 기능을 지원한다) 

 

 

 

 

◯ 2.3 LLM 평가의 어려움 

 

•   LLM 모델의 평가는 아직 완전히 풀리지 않은 문제이고 현재도 활발히 연구되는 분야이다. LLM은 다양한 작업이 가능해지기 때문에 특정 작업의 성능 평가 방식으로 모두 평가할 수 없고 프롬프트에 따라 성능이 달라지기도 해서 명확한 기준을 잡기 어렵다. 

 

 

 

 

 

 

3. LLM 평가하기

---

 

◯  3.1 정량적 지표

 

•   BLUE : 번역 성능 평가 : n그램 기반으로 모델이 생성한 무장과 참조 문장 간의 precision 계산

•   ROUGE : 요약/번역 성능 평가 : 모델이 생성한 요약문과 사람이 작성한 참조 요약문 사이의 n그램 중복도를 재현율 관점에서 측정 

•   Perplexity : 모델이 새로운 단어를 생성할 때 불확실성을 수치화 한 것으로 값이 낮을수록 모델의 예측 성능이 우수하다 

 

•   그러나 위의 세 가지 정량 지표는 문장의 의미, 문법, 유창성 등 질적인 측면의 평가에는 한계가 있고, 실제 사람의 주관적 판단과 불일치하는 경우가 많다. 

 

 

 

◯  3.2 벤치마크 데이터셋을 활용한 평가 

 

•   다양한 모델 성능을 비교하기 위해 공통으로 사용하는 데이터셋을 벤치마크 데이터셋이라고 한다. 

•   LLM에 많이 사용되는 벤치마크 데이터셋 : ARC, HellaSwag, MMLU, TruthfulQA데이터셋 등 (사지선다형 문제, 질답 문제 등 수능 문제 같은 형식이 많음)

 

•   lm-evaluation-harness : 일관된 형태로 LLM을 평가할 수 있도록 하는 기능을 제공. 모델과 평가에 사용할 데이터셋을 넣으면 평가 결과 확인이 가능

 

•   NIA와 업스테이지가 함꼐 한국어 LLM 리더보드도 제공하고 있다. 

 

•   2024년 4월 MLOps 및 LLMOps 플랫폼 기업인 W&B에서 새로운 한국어 LLM 리더보드인 호랑이를 공개했다.공개 평가 데이터셋을 통해 쉽게 llm을 평가할 수 있도록 만든 llm-kr-eval프레임워크와 multi-turn 대화 성능을 평가하는 MT-Bench를 한국어로 번역한 데이터셋을 활용해 LLM의 성능을 평가할 수 있도록 지원한다. 

 

 

 

◯  3.3 사람이 직접 평가

 

•  사람이 직접 LLM의 생성 결과를 보고 확인하는 방법을 통해 정량적 지표를 보완해야 하는 경우도 있다. 그러나 사람이 평가하는 방식은 시간이 오래 걸리고, 비용이 많이 들기 때문에 LLM 자체를 평가자로 활용하는 방법이 활발히 연구되고 있다. 

 

 

 

◯  3.4  LLM을 통한 평가

 

•  벤치마크 데이터셋은 언어모델이 '얼마나 똑똑한지'는 확인할 수 있으나, '사람의 요청에 얼마나 잘 대응'하는지는 판단하지 못한다. 

 

•  UC버클리와 스탠퍼드 연구진은 사람의 선호를 잘 반영하고 멀티 턴 대화에서 사람의 요청과 잘 정렬된 대답을 하는지 확인하기 위해 LLM을평가지표로 활용하는 방법을 발표했다. 챗봇아레나 데이터를 사용하는데, 이는 동일한 요청에 대해 2개 모델을 사용자에게 보여주고 어떤 응답이 더 좋은지 사용자가 선택한 데이터를 수집한 것이다. 

 

•  LLM을 활용해 비교적 적은 비용으로 빠르고 정확하게 평가를 수행해 사람이 직접 평가하는 양을 줄일 수 있다. 그러면 제품의 주기나 실험 주기를 줄이는 데 큰 도움이 된다. 

 

 

 

 

◯  3.5 RAG 평가 

 

•   LLM애플리캐이션의 핵심인 RAG방식의 성능도 평가하기 어렵다. 

•   RAG는 관련된 문서를 찾기 위한 '검색단계'와 검색한 내용을 바탕으로 '생성하는 단계'로 나눌 수 있다. 이에 기반해서 (1) 질문, (2) 맥락 데이터, (3) 생성 데이터 이 3가지 측면에서 RAG모델의 성능을 평가할 수 있다. 

 

•   (1) 신뢰성 - 생성된 응답이 검색된 맥락 데이터에 얼마나 사실적으로 부합하는가, (2) 답변 관련성 - 생성된 답변이 요청과 얼마나 관련성이 있는지 평가, (3) 맥락 관련성 - 검색 결과인 맥락 데이터가 요청과 얼마나 관련있는지 평가 

 

•   Ragas : RAG 평가 프레임워크 (Question, Answer, Context 검색된 맥락 데이터, Ground truth)