LLMOps 시작하기: 더 나은 AI 애플리케이션 구축하기
OpenAI의 ChatGPT 등장은 기업들 사이에서 대규모 언어 모델(LLMs)에 대한 관심의 물결을 촉발했습니다. 주요 기술 기업과 연구 기관들은 이제 LLM을 더 쉽게 접근할 수 있도록 만들고 있으며, 데이터 인프라를 강화하고, 맞춤형 애플리케이션을 위해 모델을 미세 조정하며, 환각과 편향 같은 문제를 모니터링하기 위해 노력하고 있습니다. 이러한 관심 증가는 대규모 언어 모델 운영(LLMOps)을 지원하는 기술 벤더에 대한 수요 급증으로도 이어졌습니다. 이러한 벤더들은 LLM을 개발, 미세 조정하고 프로덕션 환경에 배포하기 위한 포괄적인 워크플로를 제공합니다.
최근 Unstructured Data Meetup에서 Union.ai의 머신러닝 엔지니어인 Sage Elliott는 LLM의 배포와 관리에 대해 논의하며, 이러한 모델을 비즈니스 애플리케이션에 통합하는 데 필요한 도구, 전략, 모범 사례에 대한 귀중한 인사이트를 제공했습니다. 그의 발표는 특히 AI 개발자와 운영 관리자에게 도움이 되었으며, 프로덕션 환경에서 LLM 애플리케이션의 신뢰성과 확장성을 보장하는 데 초점을 맞췄습니다.
이 글에서는 Sage의 발표에서 나온 핵심 인사이트를 요약하고 LLMOps의 개념과 방법론에 대해 논의하겠습니다.
<< Sage Elliott의 발표 다시 보기 >>
LLMOps란 무엇인가요?
LLMOps는 Large Language Model Operations의 약자로, MLOps와 유사하지만 특히 대규모 언어 모델(LLMs)을 위한 것입니다. LLMOps를 이해하기 위해 먼저 MLOps를 살펴보겠습니다.
MLOps (Machine Learning Operations)는 프로덕션 환경에서 머신러닝 모델을 효율적으로 배포하고 유지 관리하는 데 사용되는 관행과 도구를 의미합니다. 이는 DevOps(Development and Operations)의 확장으로, 애플리케이션 개발과 운영을 하나의 응집력 있는 프로세스로 통합합니다. 이러한 접근 방식은 개발과 운영이 별도의 사일로에서 기능하기보다 함께 고려되도록 보장합니다.
MLOps란 무엇인가요?
MLOps란 무엇인가요? 이미지 출처: https://ml-ops.org/content/MLOps-principles
DevOps 방법론이 등장하기 전에는 개발 팀은 애플리케이션이나 업데이트를 가능한 한 빠르게 작성하는 데 집중한 반면, 운영 팀은 애플리케이션의 안정성, 효율성, 사용자 경험을 우선시했습니다. 이러한 분리된 접근 방식은 종종 비효율을 초래하여, 개발이 느리고 업데이트가 드문 차선의 애플리케이션으로 이어졌습니다.
DevOps는 개발 팀과 운영 팀 간의 협업을 촉진하여 이 프로세스를 변화시키고, 더 간소화되고 효율적인 워크플로를 보장합니다. MLOps는 이러한 원칙을 머신러닝으로 확장하여 ML 모델의 배포와 유지 관리 문제를 해결합니다.
LLMOps는 그 원칙을 대규모 언어 모델(LLM) 애플리케이션에 적용함으로써 MLOps의 전체론적 접근 방식에 초점을 맞춥니다. 이는 LLM 애플리케이션의 개발, 배포, 유지 관리, 지속적인 개선의 모든 측면과 관련이 있습니다.
협력이라는 중심 철학은 Sage의 LLMOps 정의인 “함께 AI 구축하기”에도 내재되어 있으며, 이는 개발, 운영, 제품 관리 등 모든 관련 사업 부서가 적시에 비용 효율적인 방식으로 가장 성능이 뛰어난 LLM 애플리케이션을 만들어내기 위해 협력해야 한다는 생각을 강조합니다.
지속적 통합 및 지속적 전달/배포(CI/CD)
DevOps와 마찬가지로 LLMOps의 핵심 원칙 중 하나는 지속적 통합/지속적 배포(CI/CD), 즉 LLM 애플리케이션 개발 수명주기를 자동화하는 프로세스입니다.
지속적 통합(CI)은 애플리케이션 업데이트를 자동으로 가져와 메인 브랜치, 즉 현재 프로덕션에서 실행 중인 LLM 애플리케이션 버전과 병합하는 관행입니다. 개발자가 GitHub와 같은 저장소에 코드를 제출하면, 이 작업은 업데이트가 통합될 준비가 되었는지 검증하는 자동화된 워크플로를 트리거합니다. CI는 개발 팀의 빈번한 변경을 장려하고 코드 병합 충돌을 방지하는 데 도움이 됩니다.
지속적 전달/배포(CD)는 통합 및 검증 후 프로덕션 환경에서 애플리케이션에 변경 사항을 자동으로 배포하는 프로세스를 의미합니다. 이 프로세스에는 기능 테스트, 사용자 인수 테스트, 인프라 구성과 같은 추가 테스트가 포함됩니다.
지속적 전달과 배포는 종종 같은 의미로 사용되지만, 둘 사이에는 차이가 있습니다. 지속적 전달은 일반적으로 조직 및 규제 준수를 보장하기 위한 사람의 최종 확인을 위해 자동 프로덕션 배포 직전에서 멈춥니다. 반대로, 지속적 배포는 애플리케이션 업데이트를 사용자에게 자동으로 릴리스합니다. 이 개념을 염두에 두면, 진정한 지속적 배포는 드뭅니다 - 특히 아직 초기 단계인 LLM 애플리케이션 개발에서는 더욱 그렇습니다.
누가 LLMOps를 사용해야 할까요?
간단히 말해, LLM 애플리케이션을 개발하는 사람이라면 누구나 어느 정도 LLMOps를 활용해야 합니다.
한편으로, LLMOps는 프로덕션 수준의 AI 애플리케이션에 필수적이며, 정확한 인프라는 애플리케이션의 필요에 따라 달라집니다. 반면, 단순한 개인 AI 프로젝트라도 간단한 LLMOps 파이프라인을 구현하면 이점을 얻을 수 있습니다.
AI 애플리케이션에 LLMOps를 통합하면 다음과 같은 이점을 제공합니다:
리소스 관리 및 확장성: 최적의 사용자 경험을 제공하기 위해 컴퓨팅 리소스 사용을 인식하는 것. LLM은 효과적으로 실행되기 위해 많은 양의 메모리를 필요로 하므로, 하드웨어, 즉 GPU가 애플리케이션의 필요에 충분한지 판단할 수 있는 것이 중요합니다.
모델 업데이트 및 개선: 더 짧은 시간 안에 모델의 실패나 단점을 인식하고 그에 따라 업데이트하는 것.
윤리적이고 책임 있는 AI 관행: AI 애플리케이션의 의도된 목적과 오작동의 잠재적 결과를 의식하는 것. LLM에 대한 주요 우려 중 하나는 “환각,” 즉 부정확하거나 관련 없는 출력을 제공하는 경향입니다; 예를 들어 의료 조언을 제공하는 애플리케이션에서는 이 문제가 재앙적일 수 있습니다.
간소화된 LLMOps 파이프라인 예시
CBInsights가 만든 시장 지도는 기업이 LLM 프로젝트를 처음부터 끝까지 관리하도록 돕는 12개 카테고리의 90개 이상의 회사를 식별합니다. 이 환경은 또한 LLMOps 시장의 규모를 보여줍니다.
LLMOps 시장 환경
LLMOps 시장 환경: 기업이 LLM 프로젝트를 처음부터 끝까지 진행하도록 돕는 12개의 다양한 카테고리에 걸친 90개 이상의 회사.
이해하기 쉽게 하기 위해, Sage는 간소화된 LLMOps 파이프라인을 만들었습니다.
간소화된 LLMOps 파이프라인
이 다이어그램의 요소를 설명해 보겠습니다:
Sys Prompt: 사용자 입력은 시스템 프롬프트의 일부가 되어 LLM에 입력됩니다.
Model: LLM은 답변 생성을 위한 애플리케이션의 기반이 됩니다.
Guardrail: 사용자가 적절한 입력만 입력하도록 보장하기 위해 마련한 제어 장치, 즉 모델이 유해하거나 불쾌한 콘텐츠를 생성하도록 시도하는 것을 방지합니다.
데이터 저장소: Vector databases는 Milvus 및 Zilliz Cloud(관리형 Milvus)와 같습니다. 이러한 데이터베이스는 LLM에 장기 기억과 맥락적 쿼리 정보를 제공하고 LLM이 더 정확한 결과를 생성하도록 돕습니다. 이 구성 요소는 특히 Retrieval Augmented Generation(RAG) 애플리케이션에서 유용합니다.
모니터: LLM 애플리케이션을 지속적으로 모니터링하는 데 사용되는 도구
CI/CD 오케스트레이터: 애플리케이션을 관리하고 프로덕션 환경으로의 통합 및 배포를 자동화하는 데 도움을 주는 플랫폼.
LLMOps 시작하기
LLMOps는 빠르게 변화하고 있고 벤더들이 매일 새로운 LLMOps 도구를 출시하고 있지만, 다행히 LLMOps의 핵심 원칙은 동일하게 유지됩니다.
다음은 LLMOps를 시작하기 위한 간단한 3단계 철학입니다.
모델 출시
모델 성능 모니터링
모델 개선
각 단계를 더 자세히 살펴보겠습니다.
모델 출시하기
모델을 출시한다는 것은 LLM 애플리케이션을 가능한 한 빨리 프로덕션 환경에 배포하는 것을 의미합니다. 이 접근 방식은 모델과 상호작용하는 사용자로부터 정확한 데이터를 얻고, LLM 애플리케이션을 사용자의 요구에 맞추는 방법을 빠르게 학습할 수 있게 해주므로 필수적입니다. 대표적인 예는 챗봇 애플리케이션으로, 테스트 환경에서 입력을 단순히 예측하는 것보다 실제 사용자 입력과 그에 대한 모델의 출력을 예시로 얻는 것이 훨씬 더 유용합니다.
HuggingFace Spaces 는 모델을 프로덕션으로 출시하는 과정을 간소화하는 훌륭한 리소스입니다. 대부분의 ML 애플리케이션을 위한 호스팅 플랫폼으로, LLM을 구동하기 위한 저비용 클라우드 GPU를 제공하므로 프로토타이핑에 이상적입니다. 또한 애플리케이션을 비공개 공간에 배포하여 LLM 애플리케이션을 테스트하고 싶은 사람들에게 제한된 액세스를 제공하거나, 공개하여 HuggingFace의 크고 활발한 커뮤니티로부터 피드백을 받을 수도 있습니다.
HuggingFace Spaces
HuggingFace Spaces
HuggingFace는 모델 배포를 위한 Spaces 이상의 것을 제공합니다. 애플리케이션을 개발하고 배포하기 위한 포괄적인 생태계를 제공합니다. 그 제공 사항의 중심에는 음성, 컴퓨터 비전, 언어 모델을 포함한 640,000개 이상의 방대한 오픈 소스 ML 모델 컬렉션이 있습니다. 또한 HuggingFace는 학습에 필요한 데이터셋과 함께 엔드투엔드 LLM 애플리케이션을 구축하는 데 필요한 모든 구성 요소를 포함하는 여러 라이브러리를 제공합니다.
HuggingFace로 LLM 애플리케이션을 구축하는 방법을 설명하기 위해, Transformer(LLM에 액세스하기 위한)와 Datasets(학습 데이터에 액세스하기 위한) 라이브러리를 사용하여 모델을 다운로드하고 학습시키는 방법을 살펴보겠습니다.
먼저, 적절한 라이브러리를 설치해야 합니다.
pip install torch transformers datasets
다음으로, 애플리케이션 내에서 사용하려는 LLM을 다운로드하겠습니다. 위에서 언급했듯이 HuggingFace에는 수십만 개의 모델이 있으며, 각 모델은 애플리케이션에 통합하는 데 필요한 코드를 제공합니다. 예를 들어, 다음과 같이 Llama 3 모델을 로드하겠습니다.
from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained("meta-llama/Meta-Llama-3-8B-Instruct”)
다음으로, 모델을 파인튜닝하기 위해 데이터셋을 로드해야 합니다. 이 예에서는 HuggingFace에서 제공하는 많은 데이터셋 중 하나를 사용하겠습니다. 하지만 도메인별 또는 작업별 목적을 위해 자체 데이터를 사용하려는 경우, 파일 경로를 학습 데이터 폴더를 가리키는 경로로 바꾸기만 하면 됩니다.
from datasets import load_dataset
dataset = load_dataset("talkmap/telecom-conversation-corpus")
데이터셋을 로드한 후에는 LLM이 쉽게 처리할 수 있는 하위 단어 토큰으로 변환하여 토큰화해야 합니다. 데이터가 사전 학습 과정과 일관되게 토큰화되고 동일한 토큰-인덱스, 즉 "어휘"를 유지하도록 Llama 3 모델과 연결된 토크나이저를 사용해야 합니다. 이 단계는 몇 줄의 코드만으로 완료할 수 있습니다.
from transformers import AutoTokenizer
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Meta-Llama-3-8B-Instruct")
# Define tokenizer function
def tokenize_function(examples):
return tokenizer(examples["text"], padding="True", truncation=True)
tokenized_dataset = dataset.map(tokenize_function, batched=True)
이제 TrainingArguments 객체를 사용하여 모델을 파인튜닝하기 위한 하이퍼파라미터 구성을 설정해야 합니다. 이 구성은 109개의 선택적 매개변수를 제공하여 학습 과정을 세밀하게 제어할 수 있게 해줍니다. 원한다면 특정 매개변수를 전달하지 않고 기본 설정에 의존할 수 있습니다.
from transformers import TrainingArguments
training_args = TrainingArguments()
마지막으로, 모델의 요소를 정의한 후에는 이를 학습 객체 안에 넣고 연결된 train 함수를 다음과 같이 호출하기만 하면 됩니다.
trainer 객체의 요소가 구성되면, 남은 일은 이를 하나로 모아 Llama 3 기본 모델을 파인튜닝하기 위해 train 함수를 호출하는 것뿐입니다.
from transformers import Trainer
trainer = Trainer(
model=model,
dataset=dataset,
args=training_args,
)
trainer.train()
이것으로 끝입니다. 단 몇 줄의 코드만으로 LLM 애플리케이션을 구동하는 데 사용할 수 있는 언어 모델을 다운로드하고 학습시킬 수 있습니다.
HuggingFace가 LLM 애플리케이션 개발을 어떻게 단순화하는지에 대한 더 구체적이고 심층적인 예시는 Milvus로 QA 애플리케이션 구축하기 튜토리얼을 참조하세요.
지속적인 모니터링 및 평가
LLM 앱을 프로덕션 환경에 배포한 후에는 다음과 같은 이유로 앱을 모니터링하는 것이 필수적입니다.
모델이 프로덕션에서 어떻게 수행되는지 확인하기 위해, 의도한 사용 사례를 충족하는가? 사용자의 기대와 일치하는가?
모델을 어떻게 개선할 수 있는가?
이후 모델을 개선했을 때, 예상한 성능 향상으로 이어지는가, 아니면 추가 변경이 필요한가?
모델이 소비하는 컴퓨팅 리소스: 애플리케이션 성능을 향상시키기 위해 더 많은 리소스(예: GPU)를 할당해야 하는가? 또한 소비하는 리소스를 고려할 때 애플리케이션은 얼마나 확장 가능한가?
추가 학습, 파인튜닝 등 변경 후에는 어떻게 수행되는가?
평가 지표는 사용자 프롬프트에 대한 응답으로 올바른 출력을 생성하는 모델의 능력을 측정하는 데 도움이 됩니다. 가장 일반적으로 사용되는 지표에는 BLEU, ROUGE, BERTScore가 있으며, 아래에 설명되어 있습니다.
| 지표 | 목적 |
| BLEU (Bilingual Evaluation Understudy) | 기계 번역에서 자주 사용되며, n-gram(n개의 연속된 단어) 중첩을 기반으로 모델이 생성한 텍스트와 참조 텍스트 간의 유사도를 측정합니다 |
| ROUGE (Recall-Oriented Understudy for Gisting Evaluation) | n-gram 중첩, 단어 시퀀스, 단어 쌍을 참조 요약과 비교하여 모델이 생성한 요약의 품질을 평가합니다. |
| BERTScore (Bidirectional Encoder Representations from Transformers) Score | BERT 임베딩을 활용하여 의미론적 의미를 포착함으로써 텍스트 유사도를 측정합니다. BLEU와 ROUGE처럼 표면적인 n-gram 중첩보다 더 상세한 평가를 제공합니다. |
또한 LLM 애플리케이션의 성능을 평가하는 다른 정성적 방법도 있습니다.
출력의 정확성과 관련성 평가: 응답이 잘 작성되었을 수는 있지만, 입력 프롬프트에 대해 얼마나 도움이 됩니까? 사용자가 기대하는 가치를 제공합니까?
사용자가 LLM 애플리케이션을 어떻게 사용하는지, 그리고 그에 따라 파인튜닝해야 하는지 판단합니다.
응답의 감정 평가: 애플리케이션이 원하는 톤으로 응답합니까?
jailbreaking 시도가 있습니까? 즉, 모델이 생성해서는 안 되는 출력을 생성하도록 유도하려는 시도입니다. 예를 들어, 챗봇에게 수제 무기를 만드는 방법을 묻는 경우입니다. 이 접근 방식은 애플리케이션에 가드레일을 포함해야 하는지, 또는 이미 구현한 가드레일을 개선해야 하는지를 판단합니다.
LLM 애플리케이션을 지속적으로 모니터링하는 것은 복잡하지 않습니다. Sage가 그의 발표에서 강조한 LangKit, Ragas, Continuous Eval, TruLens-Eval, LlamaIndex, Phoenix, DeepEval, LangSmith, OpenAI Evals 등 LLM 기반 애플리케이션을 평가할 수 있는 많은 도구가 시장에 나와 있습니다.
LLM 애플리케이션 평가에 대해 더 알아보려면 RAG evaluation.에 대한 저희 글을 살펴보세요.
모델 개선하기
모델 모니터링에서 얻은 지표와 피드백을 사용하면 훨씬 더 짧은 시간에 LLM의 새로운 반복 버전을 만들 수 있습니다. 개선 사항을 구현하는 강력하고 효율적인 방법은 Flyte와 같은 MLOps 오케스트레이터를 파이프라인에 통합하는 것입니다. MLOps 오케스트레이터는 다음과 같은 방식으로 LLM 애플리케이션 관리를 단순화합니다.
자동화된 테스트: 변경 사항이 있을 때마다 테스트를 자동으로 실행합니다.
소프트웨어 빌드: 코드를 컴파일하고 배포를 위해 준비합니다.
배포: 애플리케이션의 최신 버전을 프로덕션으로 이동합니다.
모니터링 및 보고: 빌드, 테스트, 배포의 상태를 추적하고 피드백을 제공합니다.
오케스트레이터는 특정 작업이나 목표를 실행하는 데 필요한 일련의 단계인 워크플로를 통해 애플리케이션을 관리합니다. 워크플로 내의 각 단계는 개별적으로 실행, 테스트, 검증될 수 있으며, 오케스트레이터는 각 작업이 수행되는 순서를 처리합니다. 워크플로의 예로는 LLM 학습 또는 파인튜닝, 애플리케이션을 환경에 배포, 프로덕션에서 실행 중인 애플리케이션에 새로운 기능 통합 등이 있습니다.
워크플로는 여러 방식으로 LLM 애플리케이션의 개발과 유지보수를 간소화합니다. 첫째, 워크플로는 재현 가능하므로 기존 워크플로를 여러 파이프라인에 복사할 수 있어 상당한 시간과 노력을 절약할 수 있습니다. 마찬가지로, 워크플로는 버전 관리가 가능하므로 특정 시점의 상태로 파이프라인을 되돌릴 수 있습니다.
실제로 MLOps 오케스트레이터는 여러 사람이나 팀이 개발하는 엔터프라이즈 수준의 LLM 애플리케이션에 가장 적합하며, 더 작은 애플리케이션에는 과도할 가능성이 높습니다. 오케스트레이터 대신 모델을 프로덕션에 출시하고, 사용 현황을 모니터링하며, 얻은 인사이트에 따라 애플리케이션을 수동으로 업데이트하는 것이 더 실용적인 접근 방식입니다.
요약
따라서 Sage Elliot의 LLMOps 강연을 요약하면 다음과 같습니다:
LLMOps는 LLM 애플리케이션의 효율적인 개발, 배포, 유지보수, 개선을 촉진하는 철학과 기술의 모음을 의미합니다.
LLMOps는 "함께 AI 구축하기"로도 정의할 수 있으며, 이는 (LLMOps의 기반이 된) DevOps와 마찬가지로 조직 내 서로 다른 팀들이 상반된 목표를 가지고 사일로처럼 운영되는 대신 LLM 애플리케이션을 구축하기 위해 협업한다는 의미입니다.
부담스럽게 느껴질 수 있지만, LLMOps는 3단계 프로세스로 시작할 수 있습니다:
출시: 실제 사용자 피드백을 위해 최대한 빨리 모델을 프로덕션에 배포
모니터링: 메트릭을 사용하여 성능 평가
개선: 모니터링에서 얻은 인사이트를 사용하여 애플리케이션 개선.
HuggingFace는 프로토타입을 빠르게 프로덕션에 배포하는 데 훌륭한 리소스입니다. Transformer 라이브러리를 사용하면 모델을 쉽게 다운로드하고 파인튜닝할 수 있으며, Datasets 라이브러리는 파인튜닝에 필요한 데이터를 제공하고, Spaces는 이를 프로덕션에 빠르게 배포할 수 있는 호스팅 플랫폼을 제공합니다.
Flyte는 LLM 애플리케이션 관리를 단순화하는 MLOps 오케스트레이터의 한 예입니다.
추가 자료
LLMOps에 대한 이해를 넓히고 이를 AI 애플리케이션 개발 프로세스에 적용하는 방법을 배우기 위해 아래 자료를 살펴보시기를 권장합니다.
벡터 데이터베이스, 대규모 언어 모델(LLM), 기타 주요 AI 및 머신러닝 개념에 대해 더 알아보려면 Zilliz Learn 지식 베이스를 방문하세요.
계속 읽기
Migrating from S3 Vectors to Zilliz Cloud: Unlocking the Power of Tiered Storage
Learn how Zilliz Cloud bridges cost and performance with tiered storage and enterprise-grade features, and how to migrate data from AWS S3 Vectors to Zilliz Cloud.
Data Deduplication at Trillion Scale: How to Solve the Biggest Bottleneck of LLM Training
Explore how MinHash LSH and Milvus handle data deduplication at the trillion-scale level, solving key bottlenecks in LLM training for improved AI model performance.
Bringing AI to Legal Tech: The Role of Vector Databases in Enhancing LLM Guardrails
Discover how vector databases enhance AI reliability in legal tech, ensuring accurate, compliant, and trustworthy AI-powered legal solutions.