이 페이지는 Cloud Translation API를 통해 번역되었습니다.

생성형 AI 애플리케이션 배포 및 운영

생성형 AI는 예측 AI와는 다른 방식으로 AI 애플리케이션을 빌드하고 운영하는 새로운 방법을 도입했습니다. 생성형 AI 애플리케이션을 빌드하려면 다양한 아키텍처와 크기 중에서 선택하고, 데이터를 선별하고, 최적의 프롬프트를 설계하고, 특정 작업에 맞게 모델을 조정하고, 실제 데이터에 모델 출력을 그라운딩해야 합니다.

이 문서에서는 DevOps 및 MLOps 프로세스를 조정하여 기존 파운데이션 모델에서 생성형 AI 애플리케이션을 개발, 배포, 운영하는 방법을 설명합니다. 예측 AI 배포에 관한 자세한 내용은 MLOps: 머신러닝의 지속적 배포 및 자동화 파이프라인을 참고하세요.

DevOps와 MLOps란 무엇인가요?

DevOps는 개발과 운영을 연결하는 소프트웨어 엔지니어링 방법론입니다. DevOps는 지속적 통합 및 지속적 배포 (CI/CD)와 같은 관행을 사용하여 소프트웨어 개발 수명 주기를 간소화하기 위해 공동작업, 자동화, 지속적인 개선을 촉진합니다.

MLOps는 DevOps 원칙을 기반으로 머신러닝 (ML) 시스템을 구축하고 운영하는 데 따르는 문제를 해결합니다. 머신러닝 시스템은 일반적으로 예측 AI를 사용하여 패턴을 식별하고 예측을 수행합니다. MLOps 워크플로에는 다음이 포함됩니다.

데이터 검증
모델 학습
모델 평가 및 반복
모델 배포 및 서빙
모델 모니터링

파운데이션 모델이란 무엇인가요?

파운데이션 모델은 생성형 AI 애플리케이션의 핵심 구성요소입니다. 이러한 모델은 데이터 세트를 사용하여 사람의 개입 없이 학습하고 결정을 내리는 대규모 프로그램입니다. 파운데이션 모델은 텍스트, 이미지, 오디오, 동영상 등 다양한 유형의 데이터로 학습됩니다. 파운데이션 모델에는 Llama 3.1과 같은 대규모 언어 모델 (LLM)과 Gemini와 같은 멀티모달 모델이 포함됩니다.

특정 작업을 위해 집중된 데이터 세트로 학습되는 예측 AI 모델과 달리 파운데이션 모델은 방대하고 다양한 데이터 세트로 학습됩니다. 이 교육을 통해 기반 모델을 사용하여 다양한 사용 사례에 맞는 애플리케이션을 개발할 수 있습니다. 기반 모델에는 새로운 속성(PDF)이 있어 명시적인 학습 없이도 특정 입력에 대한 대답을 제공할 수 있습니다. 이러한 창발적 속성으로 인해 기본 모델을 만들고 운영하기가 어려우며 DevOps 및 MLOps 프로세스를 조정해야 합니다.

파운데이션 모델을 개발하려면 상당한 데이터 리소스, 특수 하드웨어, 상당한 투자, 전문 지식이 필요합니다. 따라서 많은 기업이 기존 파운데이션 모델을 사용하여 생성형 AI 애플리케이션의 개발 및 배포를 간소화하는 것을 선호합니다.

생성형 AI 애플리케이션의 수명 주기

생성형 AI 애플리케이션의 수명 주기에는 다음 단계가 포함됩니다.

검색: 개발자와 AI 엔지니어가 사용 사례에 가장 적합한 기반 모델을 식별합니다. 각 모델의 강점, 약점, 비용을 고려하여 정보에 입각한 결정을 내립니다.
개발 및 실험: 개발자는 프롬프트 엔지니어링을 사용하여 필요한 출력을 얻기 위해 입력 프롬프트를 만들고 개선합니다. 사용 가능한 경우 퓨샷 학습, 파라미터 효율적인 파인 튜닝(PEFT), 모델 체이닝은 모델 동작을 안내하는 데 도움이 됩니다. 모델 체이닝은 워크플로를 만들기 위해 특정 시퀀스에서 여러 모델에 대한 호출을 오케스트레이션하는 것을 말합니다.
배포: 개발자는 프롬프트 템플릿, 체인 정의, 삽입된 모델, 검색 데이터 스토어, 미세 조정된 모델 어댑터 등 배포 프로세스에서 여러 아티팩트를 관리해야 합니다. 이러한 아티팩트에는 자체 거버넌스 요구사항이 있으며 개발 및 배포 전반에 걸쳐 신중한 관리가 필요합니다. 생성형 AI 애플리케이션 배포 시 대상 인프라의 기술적 기능을 고려하여 애플리케이션 하드웨어 요구사항을 충족해야 합니다.
프로덕션 환경에서의 지속적인 모니터링: 관리자는 모델 출력의 공정성, 투명성, 책임성을 보장하는 등 책임감 있는 AI 기술을 통해 애플리케이션 성능을 개선하고 안전 표준을 유지합니다.
지속적인 개선: 개발자는 프롬프트 기법을 통해 파운데이션 모델을 지속적으로 조정하거나, 모델을 최신 버전으로 교체하거나, 성능 향상, 비용 효율성 또는 지연 시간 감소를 위해 여러 모델을 결합합니다. 반복적인 미세 조정이나 인간 피드백 루프 통합이 필요한 시나리오에서는 기존의 지속적 학습이 여전히 유용합니다.

데이터 엔지니어링 관행은 모든 개발 단계에서 중요한 역할을 합니다. 신뢰할 수 있는 출력을 생성하려면 사실에 기반한 그라운딩 (모델의 출력이 정확하고 최신 정보를 기반으로 함)과 내부 및 엔터프라이즈 시스템의 최신 데이터가 있어야 합니다. 조정 데이터를 사용하면 모델을 특정 작업과 스타일에 맞게 조정하고 지속적인 오류를 수정할 수 있습니다.

사용 사례에 맞는 기반 모델 찾기

파운데이션 모델을 빌드하는 데는 리소스가 많이 필요하므로 대부분의 비즈니스에서는 사용 사례에 최적화된 기존 파운데이션 모델을 사용하는 것을 선호합니다. 파운데이션 모델이 많기 때문에 적합한 파운데이션 모델을 찾기가 어렵습니다. 각 모델은 아키텍처, 크기, 학습 데이터 세트, 라이선스가 다릅니다. 또한 각 사용 사례에는 고유한 요구사항이 있으므로 여러 측정기준에서 사용 가능한 모델을 분석해야 합니다.

모델을 평가할 때는 다음 요소를 고려하세요.

품질: 테스트 프롬프트를 실행하여 출력 품질을 측정합니다.
지연 시간 및 처리량: 이러한 요소는 사용자 환경에 직접적인 영향을 미치므로 사용 사례에 필요한 올바른 지연 시간과 처리량을 결정합니다. 예를 들어 챗봇은 일괄 처리된 요약 작업보다 지연 시간이 짧아야 합니다.
개발 및 유지보수 시간: 초기 개발 및 지속적인 유지보수에 필요한 시간을 고려하세요. 관리형 모델은 직접 배포하는 공개 모델보다 노력이 덜 드는 경우가 많습니다.
사용 비용: 모델과 관련된 인프라 및 소비 비용을 고려합니다.
규정 준수: 관련 규정 및 라이선스 약관을 준수하는 모델의 능력을 평가합니다.

개발 및 실험

생성형 AI 애플리케이션을 빌드할 때 개발과 실험은 반복적이고 조율됩니다. 각 실험 반복에는 데이터 개선, 기본 모델 적응, 결과 평가가 포함됩니다. 평가에서는 지속적인 피드백 루프에서 후속 반복을 안내하는 피드백을 제공합니다. 성능이 기대치에 미치지 못하는 경우 데이터를 더 수집하거나, 데이터를 보강하거나, 데이터를 추가로 선별할 수 있습니다. 또한 프롬프트를 최적화하거나, 미세 조정 기법을 적용하거나, 다른 기반 모델로 변경해야 할 수도 있습니다. 평가 통계에 기반한 이 반복적인 개선 주기는 머신러닝 및 예측형 AI와 마찬가지로 생성형 AI 애플리케이션을 최적화하는 데도 중요합니다.

파운데이션 모델 패러다임

파운데이션 모델은 다목적 모델이므로 예측 모델과 다릅니다. 파운데이션 모델은 특정 작업의 데이터로 단일 목적을 위해 학습되는 대신 광범위한 데이터 세트로 학습되므로 다양한 사용 사례에 파운데이션 모델을 적용할 수 있습니다.

또한 파운데이션 모델은 입력의 변화에 매우 민감합니다. 모델의 출력과 모델이 실행하는 작업은 모델에 대한 입력에 따라 결정됩니다. 파운데이션 모델은 입력을 변경하는 것만으로 텍스트를 번역하거나, 동영상을 생성하거나, 데이터를 분류할 수 있습니다. 입력에 사소한 변경사항이 있어도 모델이 작업을 올바르게 수행하는 능력에 영향을 미칠 수 있습니다.

파운데이션 모델의 이러한 속성에는 서로 다른 개발 및 운영 관행이 필요합니다. 예측 AI 컨텍스트의 모델은 자급자족적이고 작업에 특화되어 있지만, 기반 모델은 다목적이며 사용자 입력 외에 추가 요소가 필요합니다. 생성형 AI 모델에는 프롬프트, 더 구체적으로는 프롬프트 템플릿이 필요합니다. 프롬프트 템플릿은 사용자 입력을 수용하기 위한 자리표시자와 함께 지침과 예시의 집합입니다. 애플리케이션은 프롬프트 템플릿과 동적 데이터 (예: 사용자 입력)를 결합하여 완전한 프롬프트를 만들 수 있습니다. 완전한 프롬프트는 파운데이션 모델에 입력으로 전달되는 텍스트입니다.

프롬프트 모델 구성요소

프롬프트의 존재는 생성형 AI 애플리케이션의 특징입니다. 모델과 프롬프트만으로는 콘텐츠를 생성할 수 없습니다. 생성형 AI에는 둘 다 필요합니다. 모델과 프롬프트의 조합을 프롬프트 모델 구성요소라고 합니다. 프롬프트 모델 구성요소는 생성형 AI 애플리케이션을 만드는 데 충분한 가장 작은 독립 구성요소입니다. 프롬프트가 복잡할 필요는 없습니다. 예를 들어 '다음 문장을 영어에서 프랑스어로 번역해 줘'와 같은 간단한 요청 사항 뒤에 번역할 문장이 올 수 있습니다. 하지만 이러한 사전 지침이 없으면 파운데이션 모델이 필요한 번역 작업을 수행하지 않습니다. 따라서 애플리케이션에 필요한 작업을 수행하도록 파운데이션 모델에 요청하려면 입력과 함께 프롬프트(기본 요청 사항이라도)가 필요합니다.

프롬프트 모델 구성요소는 생성형 AI 애플리케이션을 개발할 때 MLOps 관행에 중요한 차이를 만듭니다. 생성형 AI 애플리케이션을 개발할 때는 프롬프트 모델 구성요소의 컨텍스트에서 실험과 반복을 실행해야 합니다. 생성형 AI 실험 사이클은 일반적으로 프롬프트의 변형을 테스트하는 것으로 시작합니다. 즉, 명령어의 문구를 변경하거나, 추가 컨텍스트를 제공하거나, 관련 예시를 포함하여 이러한 변경사항의 영향을 평가합니다. 이러한 방식을 일반적으로 프롬프트 엔지니어링이라고 합니다.

프롬프트 엔지니어링에는 다음과 같은 반복 단계가 포함됩니다.

프롬프트: 특정 사용 사례에 맞게 파운데이션 모델에서 원하는 동작을 유도하도록 프롬프트를 작성하고 개선합니다.
평가: 모델의 출력을 평가합니다(프로그래매틱 방식이 이상적). 프롬프트의 안내를 이해하고 이를 충족하는지 확인합니다.

평가 결과를 추적하려면 실험 결과를 등록하면 됩니다(선택사항). 프롬프트 자체가 프롬프트 엔지니어링 프로세스의 핵심 요소이므로 실험에 포함된 아티팩트 중에서 가장 중요한 아티팩트가 됩니다.

하지만 생성형 AI 애플리케이션을 실험하려면 아티팩트 유형을 식별해야 합니다. 예측 AI에서는 데이터, 파이프라인, 코드가 다릅니다. 하지만 생성형 AI의 프롬프트 패러다임에서는 프롬프트에 컨텍스트, 요청 사항, 예시, 가드레일, 다른 곳에서 가져온 실제 내부 또는 외부 데이터가 포함될 수 있습니다.

아티팩트 유형을 확인하려면 프롬프트에 다양한 구성요소가 있으며 다양한 관리 전략이 필요하다는 점을 인식해야 합니다. 다음 사항을 고려하세요.

데이터로서의 프롬프트: 프롬프트의 일부는 데이터와 똑같이 작동합니다. 퓨샷 예시, 기술 자료, 사용자 질문과 같은 요소는 기본적으로 데이터 포인트입니다. 이러한 구성요소에는 데이터 검증, 드리프트 감지, 수명 주기 관리와 같은 데이터 중심 MLOps 관행이 필요합니다.
코드로 프롬프트: 컨텍스트, 프롬프트 템플릿, 가드레일과 같은 다른 구성요소는 코드와 유사합니다. 이러한 구성요소는 프롬프트 자체의 구조와 규칙을 정의하며 승인 프로세스, 코드 버전 관리, 테스트와 같은 코드 중심 관행이 더 필요합니다.

따라서 생성형 AI에 MLOps 관행을 적용할 때는 개발자가 프롬프트를 쉽게 저장, 검색, 추적, 수정할 수 있는 프로세스가 있어야 합니다. 이러한 프로세스를 통해 빠른 반복과 원칙에 기반한 실험이 가능합니다. 프롬프트의 한 버전이 특정 모델 버전에서는 잘 작동하지만 다른 버전에서는 잘 작동하지 않는 경우가 많습니다. 실험 결과를 추적할 때는 프롬프트, 구성요소 버전, 모델 버전, 측정항목, 출력 데이터를 기록해야 합니다.

모델 체이닝 및 증강

생성형 AI 모델, 특히 대규모 언어 모델 (LLM)은 최신성을 유지하고 할루시네이션을 방지하는 데 있어 고유한 어려움이 있습니다. LLM에 새로운 정보를 인코딩하려면 배포하기 전에 비용이 많이 들고 데이터 집약적인 사전 학습이 필요합니다. 사용 사례에 따라 프롬프트 모델 하나만 사용하여 특정 생성을 수행하는 것이 충분하지 않을 수 있습니다. 이 문제를 해결하려면 프롬프트가 지정된 여러 모델을 외부 API 호출 및 코드로 표현된 로직과 함께 연결하면 됩니다. 이러한 방식으로 연결된 프롬프트 모델 구성요소의 시퀀스를 일반적으로 체인이라고 합니다.

다음 다이어그램은 체인의 구성요소와 상대적인 개발 프로세스를 보여줍니다.

개발 프로세스의 모델 체인

세부 조정

기반 모델이 포함된 생성형 AI 사용 사례를 개발할 때 특히 복잡한 작업의 경우 프롬프트 엔지니어링과 체이닝만으로는 사용 사례를 해결하기 어려울 수 있습니다. 작업 성능을 개선하기 위해 개발자는 모델을 직접 미세 조정해야 하는 경우가 많습니다. 파인 튜닝을 사용하면 모델의 모든 레이어 또는 일부 레이어 (매개변수 효율적인 파인 튜닝)를 적극적으로 변경하여 특정 작업을 수행하는 기능을 최적화할 수 있습니다. 모델을 조정하는 가장 일반적인 방법은 다음과 같습니다.

지도 미세 조정: 지도 방식으로 모델을 학습시켜 주어진 입력에 대한 올바른 출력 시퀀스를 예측하도록 가르칩니다.
인간 피드백 기반 강화 학습 (RLHF): 인간이 대답으로 무엇을 선호할지 예측하도록 보상 모델을 학습합니다. 그런 다음 이 보상 모델을 사용하여 조정 프로세스 중에 LLM을 올바른 방향으로 유도합니다. 이 프로세스는 사람 심사위원 패널이 모델의 학습을 안내하는 것과 비슷합니다.

다음 다이어그램은 실험 주기 동안 튜닝이 모델을 개선하는 방법을 보여줍니다.

모델 미세 조정

MLOps에서 미세 조정은 모델 학습과 다음 기능을 공유합니다.

튜닝 작업의 일부인 아티팩트를 추적하는 기능 예를 들어 아티팩트에는 입력 데이터나 모델을 조정하는 데 사용되는 매개변수가 포함됩니다.
튜닝의 영향을 측정하는 기능 이 기능을 사용하면 학습된 특정 작업에 대해 조정된 모델을 평가하고 동일한 작업에 대해 이전에 조정된 모델 또는 고정된 모델과 결과를 비교할 수 있습니다.

지속적 학습 및 조정

MLOps에서 지속적 학습은 프로덕션 환경에서 머신러닝 모델을 반복적으로 재학습하는 방식입니다. 지속적인 학습을 통해 시간이 지남에 따라 실제 데이터 패턴이 변경되더라도 모델이 최신 상태를 유지하고 우수한 성능을 발휘할 수 있습니다. 생성형 AI 모델의 경우 데이터 및 컴퓨팅 비용이 많이 들기 때문에 재학습 프로세스보다 모델의 지속적인 미세 조정이 더 실용적인 경우가 많습니다.

지속적 미세 조정 접근 방식은 특정 사용 사례와 목표에 따라 달라집니다. 텍스트 요약과 같이 비교적 정적인 작업의 경우 지속적 미세 조정 요구사항이 낮을 수 있습니다. 하지만 지속적인 인간과의 정렬이 필요한 챗봇과 같은 동적 애플리케이션의 경우 인간 피드백을 기반으로 하는 RLHF와 같은 기법을 사용하여 더 자주 조정해야 합니다.

적절한 지속적 조정 전략을 결정하려면 사용 사례의 특성과 시간 경과에 따른 입력 데이터의 변화를 평가해야 합니다. 컴퓨팅 인프라가 조정 속도와 비용에 큰 영향을 미치므로 비용도 중요한 고려사항입니다. 그래픽 처리 장치 (GPU)와 텐서 처리 장치 (TPU)는 미세 조정에 필요한 하드웨어입니다. 병렬 처리 능력으로 알려진 GPU는 컴퓨팅 집약적인 워크로드를 처리하는 데 매우 효과적이며 복잡한 머신러닝 모델을 학습하고 실행하는 데 자주 사용됩니다. 반면 TPU는 머신러닝 작업을 가속화하기 위해 Google에서 특별히 설계했습니다. TPU는 딥 러닝 신경망에서 흔히 볼 수 있는 대규모 행렬 연산을 처리하는 데 탁월합니다.

데이터 관행

이전에는 ML 모델 동작이 학습 데이터에 의해서만 결정되었습니다. 파운데이션 모델의 경우 이 점이 여전히 유효하지만 파운데이션 모델을 기반으로 빌드된 생성형 AI 애플리케이션의 모델 동작은 다양한 유형의 입력 데이터로 모델을 적응시키는 방식에 따라 결정됩니다.

파운데이션 모델은 다음과 같은 데이터를 학습합니다.

사전 학습 데이터 세트 (예: C4, The Pile, 독점 데이터)
요청 사항 조정 데이터 세트
안전 조정 데이터 세트
인간 선호도 데이터

생성형 AI 애플리케이션은 다음과 같은 데이터를 기반으로 적응됩니다.

프롬프트
증강 또는 그라운딩된 데이터 (예: 웹사이트, 문서, PDF, 데이터베이스 또는 API)
PEFT용 작업별 데이터
태스크별 평가
인간 선호도 데이터

예측 ML과 생성형 AI의 데이터 관행의 주요 차이점은 수명 주기 프로세스의 시작 부분에 있습니다. 예측 ML에서는 데이터 엔지니어링에 많은 시간을 할애하며, 적절한 데이터가 없으면 애플리케이션을 빌드할 수 없습니다. 생성형 AI에서는 기본 모델, 몇 가지 지침, 몇 가지 예시 입력 (예: 컨텍스트 내 학습)으로 시작합니다. 데이터가 거의 없어도 애플리케이션을 프로토타입으로 만들고 출시할 수 있습니다.

하지만 프로토타입 제작의 용이성에는 다양한 데이터를 관리해야 하는 추가적인 문제가 따릅니다. 예측 AI는 잘 정의된 데이터 세트를 사용합니다. 생성형 AI에서 단일 애플리케이션은 완전히 다른 데이터 소스의 다양한 데이터 유형을 모두 함께 사용할 수 있습니다.

다음 데이터 유형을 고려하세요.

컨디셔닝 프롬프트: 파운데이션 모델에 출력을 안내하고 생성할 수 있는 항목의 경계를 설정하기 위해 제공되는 요청 사항입니다.
퓨샷 예시: 입력-출력 쌍을 통해 달성하려는 목표를 모델에 보여주는 방법입니다. 이러한 예시는 모델이 특정 작업을 이해하는 데 도움이 되며, 많은 경우 성능을 향상시킬 수 있습니다.
그라운딩 또는 증강 데이터: 기반 모델이 전체 기반 모델을 재학습하지 않고도 특정 컨텍스트에 대한 답변을 생성하고 응답을 최신 상태로 유지하며 관련성을 유지할 수 있도록 하는 데이터입니다. 이 데이터는 외부 API (예: Google 검색) 또는 내부 API 및 데이터 소스에서 가져올 수 있습니다.
작업별 데이터 세트: 특정 작업을 위해 기존 기본 모델을 세부 조정하여 해당 특정 영역에서 성능을 개선하는 데 도움이 되는 데이터 세트입니다.
전체 사전 학습 데이터 세트: 기본 모델을 초기 학습하는 데 사용되는 대규모 데이터 세트입니다. 애플리케이션 개발자는 이러한 정보나 토큰화 도구에 액세스할 수 없지만 모델 자체에 인코딩된 정보는 애플리케이션의 출력과 성능에 영향을 미칩니다.

이러한 다양한 데이터 유형은 데이터 조직, 추적, 수명 주기 관리 측면에서 복잡성을 더합니다. 예를 들어 RAG 기반 애플리케이션은 사용자 쿼리를 다시 작성하고, 선별된 예시 집합을 사용하여 관련 예시를 동적으로 수집하고, 벡터 데이터베이스를 쿼리하고, 정보를 프롬프트 템플릿과 결합할 수 있습니다. RAG 기반 애플리케이션에서는 사용자 쿼리, 선별된 소수의 예가 포함된 벡터 데이터베이스 및 회사 정보, 프롬프트 템플릿 등 여러 데이터 유형을 관리해야 합니다.

각 데이터 유형은 신중한 구성과 유지보수가 필요합니다. 예를 들어 벡터 데이터베이스에서는 데이터를 임베딩으로 처리하고, 청크 전략을 최적화하고, 관련 정보만 사용할 수 있도록 해야 합니다. 프롬프트 템플릿에는 버전 관리 및 추적이 필요하고 사용자 쿼리는 다시 작성해야 합니다. MLOps 및 DevOps 권장사항은 이러한 작업을 지원할 수 있습니다. 예측 AI에서는 추출, 변환, 로드를 위한 데이터 파이프라인을 만듭니다. 생성형 AI에서는 버전 관리, 추적, 재현 가능한 방식으로 다양한 데이터 유형을 관리, 발전, 적응, 통합하는 파이프라인을 빌드합니다.

파운데이션 모델을 파인 튜닝하면 생성형 AI 애플리케이션 성능을 높일 수 있지만 모델에는 데이터가 필요합니다. 애플리케이션을 실행하고 실제 데이터를 수집하거나, 합성 데이터를 생성하거나, 둘 다 혼합하여 이 데이터를 얻을 수 있습니다. 대규모 모델을 사용하여 합성 데이터를 생성하는 것은 이 방법이 배포 프로세스를 가속화하기 때문에 인기를 얻고 있지만, 품질 보증을 위해 사람이 결과를 확인하는 것이 여전히 중요합니다. 다음은 데이터 엔지니어링 목적으로 대규모 모델을 사용하는 방법의 예시입니다.

합성 데이터 생성: 이 프로세스에는 특성과 통계적 속성 측면에서 실제 데이터와 유사한 인공 데이터를 만드는 작업이 포함됩니다. 이 작업은 대개 크고 성능이 우수한 모델이 완료합니다. 합성 데이터는 생성형 AI의 추가 학습 데이터로 사용되어 라벨이 지정된 실제 데이터가 부족한 경우에도 패턴과 관계를 학습할 수 있습니다.
합성 데이터 수정: 이 기법은 기존 라벨이 지정된 데이터 세트 내의 오류와 불일치를 식별하고 수정하는 데 중점을 둡니다. 생성형 AI는 더 큰 모델의 기능을 사용하여 잠재적인 라벨링 실수를 표시하고 수정사항을 제안하여 학습 데이터의 품질과 신뢰성을 개선할 수 있습니다.
합성 데이터 증강: 이 접근 방식은 새로운 데이터를 생성하는 것 이상입니다. 합성 데이터 증강은 기존 데이터를 지능적으로 조작하여 필수 기능과 관계를 유지하면서 다양한 변형을 만드는 것을 말합니다. 생성형 AI는 학습 중에 예측 AI보다 더 광범위한 시나리오를 접할 수 있으므로 일반화가 개선되고 미묘하고 관련성 있는 출력을 생성할 수 있습니다.

예측 AI와 달리 생성형 AI를 평가하기는 어렵습니다. 예를 들어 기반 모델의 학습 데이터 분포를 알 수 없습니다. 필수, 평균, 특이 사례를 비롯한 모든 사용 사례를 반영하는 맞춤 평가 데이터 세트를 빌드해야 합니다. 미세 조정 데이터와 마찬가지로 강력한 LLM을 사용하여 강력한 평가 데이터 세트를 빌드하기 위한 데이터를 생성, 선별, 증강할 수 있습니다.

평가

평가 프로세스는 생성형 AI 애플리케이션 개발의 핵심 활동입니다. 평가는 사람이 완전히 주도하는 것부터 프로세스에 의해 완전히 자동화되는 것까지 다양한 수준의 자동화를 가질 수 있습니다.

프로젝트를 프로토타입으로 제작할 때는 평가가 수동 프로세스인 경우가 많습니다. 개발자는 모델의 출력을 검토하여 모델의 성능을 정성적으로 파악합니다. 하지만 프로젝트가 성숙해지고 테스트 사례 수가 증가하면 수동 평가가 병목 현상이 됩니다.

평가를 자동화하면 두 가지 큰 이점이 있습니다. 더 빠르게 이동할 수 있고 평가의 신뢰성이 높아집니다. 또한 사람의 주관성을 고려하지 않으므로 결과를 재현할 수 있습니다.

하지만 생성형 AI 애플리케이션의 평가를 자동화하는 데는 여러 가지 어려움이 따릅니다. 예를 들어 다음 사항을 고려해 보세요.

입력 (프롬프트)과 출력 모두 매우 복잡할 수 있습니다. 단일 프롬프트에는 모델이 관리해야 하는 여러 명령과 제약 조건이 포함될 수 있습니다. 출력 자체는 생성된 이미지나 텍스트 블록과 같이 고차원인 경우가 많습니다. 이러한 출력의 품질을 간단한 측정항목으로 포착하기는 어렵습니다. 번역의 경우 BLEU, 요약의 경우 ROUGE와 같은 일부 기존 측정항목은 항상 충분하지 않습니다. 따라서 맞춤 평가 방법이나 다른 기본 모델을 사용하여 시스템을 평가할 수 있습니다. 예를 들어 대규모 언어 모델 (예: AutoSxS)에 다양한 측면에서 생성된 텍스트의 품질을 평가하도록 프롬프트를 표시할 수 있습니다.
생성형 AI의 많은 평가 측정항목은 주관적입니다. 한 출력이 다른 출력보다 나은 이유는 의견에 따라 달라질 수 있습니다. 측정항목이 사용자의 생각을 신뢰할 수 있는 프록시가 되도록 자동 평가가 사람의 판단과 일치해야 합니다. 실험 간의 비교 가능성을 보장하려면 개발 프로세스 초기에 평가 접근 방식과 측정항목을 결정해야 합니다.
특히 프로젝트 초기 단계에서 그라운드 트루스 데이터가 부족합니다. 한 가지 해결 방법은 인간의 피드백을 통해 시간이 지남에 따라 개선할 수 있는 임시 정답 역할을 하는 합성 데이터를 생성하는 것입니다.
생성형 AI 애플리케이션을 적대적 공격으로부터 보호하려면 포괄적인 평가가 필수입니다. 악의적인 행위자는 민감한 정보를 추출하거나 모델의 출력을 조작하기 위해 프롬프트를 조작할 수 있습니다. 평가 세트는 프롬프트 퍼징 (모델에 프롬프트의 무작위 변형을 제공) 및 정보 유출 테스트와 같은 기법을 통해 이러한 공격 벡터를 구체적으로 다뤄야 합니다.

생성형 AI 애플리케이션을 평가하려면 다음을 구현하세요.

평가 프로세스를 자동화하여 속도, 확장성, 재현성을 보장합니다. 자동화를 사람의 판단의 대리자로 간주할 수 있습니다.
사용 사례에 필요한 대로 평가 프로세스를 맞춤설정합니다.
비교 가능성을 보장하려면 개발 단계에서 가능한 한 빨리 평가 접근 방식, 측정항목, 정답 데이터를 안정화하세요.
실제 정답 데이터가 부족한 경우를 대비하여 합성 정답 데이터를 생성합니다.
이러한 공격에 대한 시스템 자체의 신뢰성을 테스트하기 위해 평가 세트의 일부로 적대적 프롬프트의 테스트 사례를 포함합니다.

배포

프로덕션 수준의 생성형 AI 애플리케이션은 상호작용하는 구성요소가 많은 복잡한 시스템입니다. 생성형 AI 애플리케이션을 프로덕션에 배포하려면 생성형 AI 애플리케이션 개발의 이전 단계와 함께 이러한 구성요소를 관리하고 조정해야 합니다. 예를 들어 단일 애플리케이션이 데이터베이스와 함께 여러 LLM을 사용할 수 있으며, 이 모든 것이 동적 데이터 파이프라인에 의해 제공됩니다. 이러한 각 구성요소에는 자체 배포 프로세스가 필요할 수 있습니다.

생성형 AI 애플리케이션을 배포하는 것은 데이터베이스 및 Python 애플리케이션과 같은 시스템 구성요소를 배포해야 하므로 다른 복잡한 소프트웨어 시스템을 배포하는 것과 유사합니다. 버전 관리 및 CI/CD와 같은 표준 소프트웨어 엔지니어링 관행을 사용하는 것이 좋습니다.

버전 제어

생성형 AI 실험은 개발, 평가, 수정의 주기를 반복하는 반복적인 프로세스입니다. 구조화되고 관리 가능한 접근 방식을 보장하려면 수정 가능한 모든 구성요소에 엄격한 버전 관리를 구현해야 합니다. 이러한 구성요소는 다음과 같습니다.

프롬프트 템플릿: 특정 프롬프트 관리 솔루션을 사용하지 않는 한 버전 관리 도구를 사용하여 버전을 추적하세요.
체인 정의: 버전 관리 도구를 사용하여 체인을 정의하는 코드의 버전을 추적합니다 (API 통합, 데이터베이스 호출, 함수 포함).
외부 데이터 세트: RAG 시스템에서 외부 데이터 세트는 중요한 역할을 합니다. BigQuery, PostgreSQL용 AlloyDB, Vertex AI Feature Store와 같은 기존 데이터 분석 솔루션을 사용하여 이러한 변경사항과 데이터 세트 버전을 추적합니다.
어댑터 모델: 어댑터 모델을 위한 LoRA 튜닝과 같은 기술은 끊임없이 발전하고 있습니다. 확립된 데이터 스토리지 솔루션 (예: Cloud Storage)을 사용하여 이러한 애셋을 효과적으로 관리하고 버전을 관리합니다.

지속적 통합

지속적 통합 프레임워크에서 모든 코드 변경사항은 병합되기 전에 자동 테스트를 거쳐 문제를 조기에 포착합니다. 단위 및 통합 테스트는 품질과 안정성에 중요합니다. 단위 테스트는 개별 코드에 중점을 두는 반면 통합 테스트는 여러 구성요소가 함께 작동하는지 확인합니다.

지속적 통합 시스템을 구현하면 다음 작업을 할 수 있습니다.

안정적이고 고품질 출력 보장: 엄격한 테스트를 통해 시스템의 성능과 일관성에 대한 신뢰도를 높일 수 있습니다.
버그 조기 발견: 테스트를 통해 문제를 식별하면 다운스트림에서 더 큰 문제가 발생하는 것을 방지할 수 있습니다. 버그를 일찍 포착하면 시스템이 더 강력해지고 특이 사례와 예상치 못한 입력에 더 탄력적으로 대응할 수 있습니다.
유지보수 비용 절감: 문서화가 잘 된 테스트 사례는 문제 해결을 간소화하고 향후 수정사항을 원활하게 적용할 수 있도록 지원하여 전반적인 유지보수 노력을 줄입니다.

이러한 이점은 생성형 AI 애플리케이션에 적용됩니다. 프롬프트 템플릿, 체인, 체인 연결 로직, 모든 내장 모델, 검색 시스템을 비롯한 시스템의 모든 요소에 지속적 통합을 적용합니다.

하지만 생성형 AI에 지속적 통합을 적용할 때는 다음과 같은 문제가 발생합니다.

포괄적인 테스트 사례 생성의 어려움: 생성형 AI 출력의 복잡하고 개방적인 특성으로 인해 모든 가능성을 포괄하는 완전한 테스트 사례를 정의하고 생성하기가 어렵습니다.
재현성 문제: 생성 모델은 동일한 입력에 대해서도 출력에 내재된 무작위성과 가변성이 있는 경우가 많기 때문에 결정적이고 재현 가능한 결과를 얻기가 어렵습니다. 이러한 무작위성으로 인해 예상되는 동작을 일관되게 테스트하기가 어려워집니다.

이러한 과제는 생성형 AI 애플리케이션을 평가하는 방법에 관한 광범위한 질문과 밀접한 관련이 있습니다. 생성형 AI용 CI 시스템 개발에 동일한 평가 기법을 많이 적용할 수 있습니다.

지속적 배포

코드가 병합되면 지속적 배포 프로세스가 시작되어 빌드되고 테스트된 코드를 최종 배포 전에 추가 테스트를 위해 프로덕션과 매우 유사한 환경으로 이동합니다.

개발 및 실험에 설명된 대로 체인 요소는 생성형 AI 애플리케이션을 근본적으로 구성하므로 배포할 주요 구성요소 중 하나가 됩니다. 체인을 포함하는 생성형 AI 애플리케이션의 제공 프로세스는 지연 시간 요구사항과 사용 사례가 일괄인지 온라인인지에 따라 다를 수 있습니다.

일괄 사용 사례에서는 프로덕션에서 일정에 따라 실행되는 일괄 프로세스를 배포해야 합니다. 배포 전 프로덕션과 유사한 환경에서 통합의 전체 파이프라인을 테스트하는 데 배포 프로세스가 중점을 둡니다. 테스트 프로세스의 일환으로 개발자는 배치 프로세스 자체의 처리량에 관한 특정 요구사항을 어설션하고 애플리케이션의 모든 구성요소가 올바르게 작동하는지 확인할 수 있습니다. (예를 들어 개발자는 권한, 인프라, 코드 종속 항목을 확인할 수 있습니다.)

온라인 사용 사례에서는 체인을 포함하고 지연 시간이 짧은 상태로 사용자에게 응답할 수 있는 애플리케이션인 API를 배포해야 합니다. 제공 프로세스에는 프로덕션과 유사한 환경에서 통합 API를 테스트하는 작업이 포함됩니다. 이러한 테스트는 애플리케이션의 모든 구성요소가 올바르게 작동하는지 확인합니다. 부하 테스트를 비롯한 일련의 테스트를 통해 비기능 요구사항 (예: 확장성, 안정성, 성능)을 확인할 수 있습니다.

배포 체크리스트

다음 목록에서는 Vertex AI와 같은 관리형 서비스를 사용하여 생성형 AI 애플리케이션을 배포할 때 취해야 하는 단계를 설명합니다.

버전 제어 구성: 모델 배포에 버전 제어 관행을 구현합니다. 버전 관리를 사용하면 필요한 경우 이전 버전으로 롤백하고 모델 또는 배포 구성에 적용된 변경사항을 추적할 수 있습니다.
모델 최적화: 모델을 패키징하거나 배포하기 전에 모델 최적화 작업 (증류, 양자화, 가지치기)을 실행합니다.
모델 컨테이너화: 학습된 모델을 컨테이너로 패키징합니다.
타겟 하드웨어 요구사항 정의: 타겟 배포 환경이 GPU, TPU, 기타 특수 하드웨어 가속기와 같은 모델의 최적 성능을 위한 요구사항을 충족하는지 확인합니다.
모델 엔드포인트 정의: 모델 컨테이너, 입력 형식, 출력 형식, 추가 구성 매개변수를 지정합니다.
리소스 할당: 예상 트래픽 및 성능 요구사항에 따라 엔드포인트에 적절한 컴퓨팅 리소스를 할당합니다.
액세스 제어 구성: 인증 및 승인 정책에 따라 엔드포인트에 대한 액세스를 제한하는 액세스 제어 메커니즘을 설정합니다. 액세스 제어를 사용하면 승인된 사용자 또는 서비스만 배포된 모델과 상호작용할 수 있습니다.
모델 엔드포인트 만들기: 모델을 REST API 서비스로 배포하기 위해 엔드포인트를 만듭니다. 엔드포인트를 사용하면 클라이언트가 엔드포인트에 요청을 보내고 모델로부터 응답을 받을 수 있습니다.
모니터링 및 로깅 구성: 엔드포인트의 성능, 리소스 사용률, 오류 로그를 추적하도록 모니터링 및 로깅 시스템을 설정합니다.
맞춤 통합 배포: 모델의 SDK 또는 API를 사용하여 모델을 맞춤 애플리케이션 또는 서비스에 통합합니다.
실시간 애플리케이션 배포: 데이터를 처리하고 실시간으로 응답을 생성하는 스트리밍 파이프라인을 만듭니다.

로깅 및 모니터링

생성형 AI 애플리케이션과 그 구성요소를 모니터링하려면 기존 MLOps에 사용하는 모니터링 기법에 추가할 수 있는 기법이 필요합니다. 애플리케이션의 전체 입력 및 출력과 모든 구성요소를 로깅하고 모니터링하는 등 애플리케이션을 엔드 투 엔드로 로깅하고 모니터링해야 합니다.

애플리케이션에 대한 입력은 여러 구성요소가 출력을 생성하도록 트리거합니다. 특정 입력에 대한 출력이 사실적으로 부정확한 경우 어떤 구성요소가 제대로 작동하지 않았는지 확인해야 합니다. 실행된 모든 구성요소의 로깅에 계보가 필요합니다. 입력과 구성요소를 입력 및 출력을 분석할 수 있도록 종속된 추가 아티팩트 및 매개변수에 매핑해야 합니다.

모니터링을 적용할 때는 애플리케이션 수준에서 모니터링하는 것을 우선시하세요. 애플리케이션 수준 모니터링에서 애플리케이션이 제대로 작동하는 것으로 확인되면 모든 구성요소도 제대로 작동한다는 의미입니다. 그런 다음 프롬프트된 모델 구성요소에 모니터링을 적용하여 더 세부적인 결과를 얻고 애플리케이션을 더 잘 이해할 수 있습니다.

MLOps의 기존 모니터링과 마찬가지로 드리프트, 스큐 또는 성능 저하가 감지되면 애플리케이션 소유자에게 알리는 알림 프로세스를 배포해야 합니다. 알림을 설정하려면 알림 및 알림 도구를 모니터링 프로세스에 통합해야 합니다.

다음 섹션에서는 편향 및 드리프트 모니터링과 지속적인 평가 작업을 설명합니다. 또한 MLOps의 모니터링에는 리소스 사용률 및 지연 시간과 같은 전체 시스템 상태의 측정항목 모니터링이 포함됩니다. 이러한 효율성 측정항목은 생성형 AI 애플리케이션에도 적용됩니다.

편향 감지

기존 ML 시스템의 편향 감지는 프로덕션의 특성 데이터 분포가 모델 학습 중에 관찰된 특성 데이터 분포와 다를 때 발생하는 학습-서빙 편향을 의미합니다. 사전 학습된 모델을 함께 연결되어 출력을 생성하는 구성요소에서 사용하는 생성형 AI 애플리케이션의 경우 스큐도 측정해야 합니다. 애플리케이션을 평가하는 데 사용한 입력 데이터의 분포와 프로덕션에서 애플리케이션에 대한 입력의 분포를 비교하여 편향을 측정할 수 있습니다. 두 분포가 서로 멀어지면 추가로 조사해야 합니다. 출력 데이터에도 동일한 프로세스를 적용할 수 있습니다.

드리프트 감지

편향 감지와 마찬가지로 드리프트 감지는 두 데이터 세트 간의 통계적 차이를 확인합니다. 하지만 평가와 서빙 입력을 비교하는 대신, 드리프트는 입력 데이터의 변경사항을 찾습니다. 드리프트를 사용하면 입력을 평가할 수 있으므로 시간 경과에 따라 사용자 행동이 어떻게 변하는지 확인할 수 있습니다.

애플리케이션의 입력은 일반적으로 텍스트이므로 다양한 방법을 사용하여 스큐와 드리프트를 측정할 수 있습니다. 일반적으로 이러한 방법은 평가 데이터 세트와 비교할 때 텍스트 (예: 입력 크기) 및 개념 (예: 입력의 주제) 모두에서 프로덕션 데이터의 중요한 변경사항을 식별하려고 합니다. 이러한 모든 메서드는 이제 수신되는 새로운 데이터의 특성을 애플리케이션이 성공적으로 처리할 준비가 되어 있지 않음을 나타낼 수 있는 변경사항을 찾습니다. 일반적인 방법은 다음과 같습니다.

임베딩 및 거리 계산
텍스트 길이 및 토큰 수 계산
데이터 세트의 어휘 변경사항, 새로운 개념 및 의도, 프롬프트, 주제 추적
최소 제곱 밀도 차이(PDF), 최대 평균 불일치 (MMD), 학습된 커널 MMD (PDF) 또는 컨텍스트 인식 MMD와 같은 통계적 접근 방식을 사용합니다.

생성형 AI 사용 사례는 매우 다양하므로 데이터의 예기치 않은 변화를 더 잘 포착하는 추가 맞춤 측정항목이 필요할 수 있습니다.

지속적 평가

지속적인 평가는 생성형 AI 애플리케이션 모니터링의 또 다른 일반적인 접근 방식입니다. 지속적 평가 시스템에서는 모델의 프로덕션 출력을 캡처하고 해당 출력을 사용하여 평가 작업을 실행하여 시간이 지남에 따라 모델의 성능을 추적합니다. 출력의 인식된 품질에 대한 즉각적인 통계를 제공하는 평가와 같은 직접적인 사용자 의견을 수집할 수 있습니다. 이와 동시에 모델 생성 응답을 확립된 그라운드 트루스와 비교하면 성능을 더 심층적으로 분석할 수 있습니다. 인간 평가를 통해 또는 평가 측정항목을 생성하기 위한 앙상블 AI 모델 접근 방식의 결과로 정답을 수집할 수 있습니다. 이 프로세스를 통해 모델을 개발한 시점부터 현재 프로덕션 환경에 있는 모델까지 평가 측정항목이 어떻게 변경되었는지 확인할 수 있습니다.

제어

MLOps의 맥락에서 거버넌스는 코드, 데이터, 모델 수명 주기와 관련된 모든 활동을 포함하여 머신러닝 모델의 개발, 배포, 지속적인 관리에 대한 통제, 책임, 투명성을 확립하는 모든 관행과 정책을 포괄합니다.

예측 AI 애플리케이션에서 계보는 머신러닝 모델의 전체 여정을 추적하고 이해하는 데 중점을 둡니다. 생성형 AI에서 계보는 모델 아티팩트를 넘어 체인의 모든 구성요소로 확장됩니다. 추적에는 데이터, 모델, 모델 계보, 코드, 상대 평가 데이터 및 측정항목이 포함됩니다. 계보 추적은 모델을 감사, 디버그, 개선하는 데 도움이 됩니다.

이러한 새로운 관행과 함께 표준 MLOps 및 DevOps 관행을 사용하여 데이터 수명 주기와 생성형 AI 구성요소 수명 주기를 관리할 수 있습니다.

다음 단계

Vertex AI를 사용하여 생성형 AI 애플리케이션 배포

저자: Anant Nawalgaria, Christos Aniftos, Elia Secchi, Gabriela Hernandez Larios, Mike Styer, Onofrio Petragallo

생성형 AI 애플리케이션 배포 및 운영 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.