생성형 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 엔지니어가 사용 사례에 가장 적합한 기반 모델을 식별합니다. 각 모델의 장점, 단점, 비용을 고려하여 정보에 입각한 결정을 내립니다.
- 개발 및 실험: 개발자는 프롬프트 엔지니어링을 사용하여 입력 프롬프트를 만들고 수정하여 필요한 출력을 얻습니다. 가능한 경우 Few-Shot 학습, 매개변수 효율적인 미세 조정(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) 및 Tensor Processing Unit (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 애플리케이션의 경우 왜곡도 측정도 해야 합니다. 애플리케이션을 평가하는 데 사용한 입력 데이터의 분포와 프로덕션에서 애플리케이션에 대한 입력의 분포를 비교하여 편향을 측정할 수 있습니다. 두 분포가 서로 멀어지면 추가로 조사해야 합니다. 출력 데이터에도 동일한 프로세스를 적용할 수 있습니다.
드리프트 감지
편향 감지와 마찬가지로 드리프트 감지는 두 데이터 세트 간의 통계적 차이를 확인합니다. 하지만 평가와 제공 입력을 비교하는 대신, 편차는 입력 데이터의 변경사항을 찾습니다. Drift를 사용하면 입력을 평가하여 시간이 지남에 따라 사용자의 행동이 어떻게 달라지는지 확인할 수 있습니다.
애플리케이션의 입력은 일반적으로 텍스트이므로 다양한 방법을 사용하여 왜곡 및 편차를 측정할 수 있습니다. 일반적으로 이러한 방법은 평가 데이터 세트와 비교할 때 프로덕션 데이터의 텍스트적 (예: 입력 크기) 및 개념적 (예: 입력의 주제)인 중요한 변화를 식별하려고 합니다. 이러한 모든 메서드는 애플리케이션이 현재 수신되는 새 데이터의 특성을 성공적으로 처리할 준비가 되지 않았음을 나타낼 수 있는 변경사항을 찾습니다. 다음과 같은 몇 가지 일반적인 방법이 있습니다.
- 임베딩 및 거리 계산
- 텍스트 길이 및 토큰 수 집계
- 데이터 세트에서 어휘 변화, 새로운 개념 및 인텐트, 프롬프트, 주제 추적
- 최소 제곱 밀도 차이(PDF), 최대 평균 불일치 (MMD), 학습된 커널 MMD (PDF) 또는 문맥 인식 MMD와 같은 통계적 접근 방식을 사용합니다.
생성형 AI 사용 사례는 매우 다양하므로 데이터의 예상치 못한 변화를 더 잘 포착하는 맞춤 측정항목을 추가로 필요로 할 수 있습니다.
지속적 평가
연속 평가는 생성형 AI 애플리케이션 모니터링에 사용되는 또 다른 일반적인 접근 방식입니다. 연속 평가 시스템에서는 모델의 프로덕션 출력을 캡처하고 이 출력을 사용하여 평가 작업을 실행하여 시간이 지남에 따라 모델의 성능을 추적합니다. 평점과 같은 직접적인 사용자 의견을 수집하여 출력물의 인식된 품질에 대한 즉각적인 통계를 얻을 수 있습니다. 동시에 모델에서 생성된 응답을 기존의 실측값과 비교하면 성능을 더 심층적으로 분석할 수 있습니다. 사람의 평가를 통해 정답을 수집하거나 앙상블 AI 모델 접근 방식의 결과로 정답을 수집하여 평가 측정항목을 생성할 수 있습니다. 이 프로세스를 통해 모델을 개발할 때의 평가 측정항목이 현재 프로덕션에 있는 측정항목으로 어떻게 변경되었는지 확인할 수 있습니다.
제어
MLOps 맥락에서 거버넌스는 코드, 데이터, 모델 수명 주기와 관련된 모든 활동을 포함하여 머신러닝 모델의 개발, 배포, 지속적인 관리에 대한 제어, 책임, 투명성을 확립하는 모든 관행과 정책을 포괄합니다.
예측 AI 애플리케이션에서 계보의 역할은 머신러닝 모델의 전체 여정을 추적하고 이해하는 것입니다. 생성형 AI에서 계보는 모델 아티팩트를 넘어 체인의 모든 구성요소로 확장됩니다. 추적에는 데이터, 모델, 모델 계보, 코드, 상대 평가 데이터 및 측정항목이 포함됩니다. 계보 추적을 사용하면 모델을 감사, 디버그, 개선하는 데 도움이 됩니다.
이러한 새로운 관행과 함께 표준 MLOps 및 DevOps 관행을 사용하여 데이터 수명 주기를 관리하고 생성형 AI 구성요소 수명 주기를 관리할 수 있습니다.
다음 단계
Vertex AI를 사용하여 생성형 AI 애플리케이션 배포