생성형 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 호출 및 코드로 표현된 로직과 함께 여러 프롬프트된 모델을 함께 연결할 수 있습니다. 이러한 방식으로 함께 연결된 프롬프트된 모델 구성요소의 시퀀스를 일반적으로 체인이라고 합니다.
다음 다이어그램은 체인의 구성요소와 상대적 개발 프로세스를 보여줍니다.
날짜순 및 할루시네이션 관련 완화
날짜순 및 할루시네이션을 완화할 수 있는 두 가지 일반적인 체인 기반 패턴은 검색 증강 생성 (RAG)(PDF)과 에이전트입니다.
- RAG는 데이터베이스에서 검색한 지식으로 선행 학습된 모델을 보강하므로 사전 학습의 필요성이 사라집니다. RAG는 최신 사실 정보를 생성 프로세스에 직접 통합하여 그라운딩을 가능하게 하고 할루시네이션을 줄입니다.
- ReAct 프롬프팅 기술(PDF)로 대중화된 에이전트는 LLM을 RAG 시스템, 내부 또는 외부 API, 커스텀 확장 프로그램, 다른 에이전트 등 다양한 도구와 상호작용하는 미디에이터로 사용합니다. 에이전트는 관련 정보 소스를 동적으로 선택 및 사용하여 복잡한 쿼리와 실시간 작업을 지원합니다. LLM은 에이전트 역할을 하며 사용자의 쿼리를 해석하고, 사용할 도구를 결정하고, 검색된 정보를 바탕으로 응답을 계산합니다.
RAG 및 에이전트를 사용하여 대규모 정보 네트워크에 연결된 멀티 에이전트 시스템을 만들어 정교한 쿼리 처리 및 실시간 의사 결정을 지원할 수 있습니다.
다양한 모델, 로직, API를 조정하는 것은 생성형 AI 애플리케이션에 새로운 것이 아닙니다. 예를 들어 추천 엔진은 협업 필터링 모델, 콘텐츠 기반 모델, 비즈니스 규칙을 결합하여 사용자에게 맞춤설정된 제품 추천을 생성합니다. 마찬가지로 사기 행위 감지에서 머신러닝 모델은 규칙 기반 시스템 및 외부 데이터 소스와 통합되어 의심스러운 활동을 식별합니다.
이러한 생성형 AI 구성요소 체인의 차별점은 구성요소 입력의 분포를 사전에 특성화할 수 없으므로 개별 구성요소를 개별적으로 평가하고 유지하기가 훨씬 더 어렵다는 점입니다. 조정은 생성형 AI를 위한 AI 애플리케이션을 개발하는 방식에 패러다임 변화를 일으킵니다.
예측 AI에서는 개별 모델 및 구성요소를 격리된 상태로 반복한 다음 AI 애플리케이션에서 체이닝할 수 있습니다. 생성형 AI에서는 통합 중에 체인을 개발하고 체인 엔드 투 엔드 실험을 수행하며 체이닝 전략, 프롬프트, 기반 모델, 기타 API를 조정된 방식으로 반복하여 특정 목표를 달성합니다. 특성 추출, 데이터 수집, 추가 모델 학습 주기 없이 프롬프트 템플릿의 문구만 변경하면 되는 경우가 많습니다.
생성형 AI를 위한 MLOps로 전환하면 예측 AI를 위한 MLOps와 달리 다음과 같은 차이가 발생합니다.
- 평가: 체인이 긴밀하게 결합되어 있기 때문에 체인의 전반적인 성능과 출력 품질을 측정하려면 각 구성요소뿐만 아니라 엔드 투 엔드 평가가 필요합니다. 평가 기법 및 측정항목 측면에서 연쇄 평가는 프롬프트된 모델을 평가하는 것과 유사합니다.
- 버전 관리: 체인을 전체 아티팩트로 관리해야 합니다. 분석과 재현성을 위해, 변경사항이 출력에 미치는 영향을 이해하기 위해 체인 구성을 자체 업데이트 기록으로 추적해야 합니다. 로그에는 체인의 입력, 출력, 중간 상태, 각 실행 중에 사용된 체인 구성이 포함되어야 합니다.
- 지속적인 모니터링: 체인에서 성능 저하, 데이터 드리프트, 예상치 못한 동작을 감지하려면 사전 모니터링 시스템을 구성해야 합니다. 지속적인 모니터링은 생성된 출력의 품질을 유지하기 위해 잠재적인 문제를 조기에 식별하는 데 도움이 됩니다.
- 점검: 체인의 내부 데이터 흐름 (즉, 각 구성요소의 입력과 출력)과 전체 체인의 입력 및 출력을 검사해야 합니다. 체인을 통해 흐르는 데이터와 그에 따른 콘텐츠에 대한 가시성을 제공함으로써 개발자는 오류, 편향 또는 바람직하지 않은 동작의 원인을 정확히 찾아낼 수 있습니다.
다음 다이어그램은 최신성 및 할루시네이션을 줄이기 위해 생성형 AI 애플리케이션에서 체인, 프롬프트된 모델 구성요소, 모델 조정이 어떻게 함께 작동하는지 보여줍니다. 데이터가 선별되고, 모델이 조정되며, 체인이 추가되어 응답을 더욱 세분화합니다. 결과가 평가된 후 개발자는 실험을 기록하고 계속 반복할 수 있습니다.
미세 조정
기반 모델이 포함된 생성형 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 및 데이터 소스에서 가져올 수 있습니다.
- 태스크별 데이터 세트: 특정 태스크의 기존 기반 모델을 미세 조정하여 특정 영역에서 성능을 개선하는 데 도움이 되는 데이터 세트입니다.
- 전체 사전 학습 데이터 세트: 초기 기반 모델을 학습시키는 데 사용되는 대규모 데이터 세트입니다. 애플리케이션 개발자가 이러한 API나 tokenizer에 액세스하지 못할 수 있지만 모델 자체에서 인코딩된 정보는 애플리케이션의 출력과 성능에 영향을 미칩니다.
이처럼 다양한 데이터 유형 범위는 데이터 구성, 추적, 수명 주기 관리 측면에서 복잡성을 한층 더 높여줍니다. 예를 들어 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을 사용할 수 있습니다. 이러한 각 구성요소에는 자체 배포 프로세스가 필요할 수 있습니다.
데이터베이스 및 Python 애플리케이션과 같은 시스템 구성요소를 배포해야 하므로 생성형 AI 애플리케이션 배포는 다른 복잡한 소프트웨어 시스템을 배포하는 것과 유사합니다. 버전 제어 및 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 애플리케이션 배포
저자: 아난트 나왈가리아, 크리스토스 아니프토스, 엘리아 섹치, 가브리엘라 에르난데스 라리오스, 마이크 스티어, 오노프리오 페트라갈로