FMOps/LLMOps와 MLOps 차이점 비교 및 생성형 AI 운영하기

이 글은 영문 게시글(FMOps/LLMOps: Operationalize generative AI and differences with MLOps, by Sokratis Kartakis and Heiko Hotz)을 한글 번역, 편집하였습니다.

최근, 많은 고객들께서는 대형 언어 모델(LLM) 에 매우 높은 관심을 보이시고, 생성형 AI가 비즈니스를 어떻게 혁신할 수 있을지에 대해 고민하고 계십니다. 하지만 이러한 솔루션과 모델을 비즈니스 운영에 적용하는 것은 쉬운 일이 아닙니다. 이 블로그에서는 파운데이션 모델 운영(FMOps)으로 이어지는 MLOps 원칙을 사용하여 생성형 AI 애플리케이션을 운영하는 방법에 대해 설명합니다. 또한 FMOps의 일부이고 가장 일반적인 생성형 AI 사용 사례인 텍스트-텍스트 변환 애플리케이션과 LLM 운영(LLMOps)에 대해 심층적으로 살펴보겠습니다. 다음 그림은 우리가 논의하는 주제를 보여주고 있습니다.

구체적으로, MLOps 원칙을 간략하게 소개하고 프로세스, 사람, 모델 선택 및 평가, 데이터 프라이버시, 모델 배포와 관련하여 FMOps 및 LLMOps와 MLOps의 주요 차이점에 대해서 알아보겠습니다. 이는 즉시 사용할 수 있는 생성형 AI 서비스를 이용하시거나, 파운데이션 모델을 처음부터 만들거나, 파인 튜닝하는 고객에게 적용할 수 있습니다. 이 방법은 오픈 소스 모델과 독점 모델 모두 동일하게 적용할 수 있습니다.

ML 운영 요약

Amazon SageMaker를 사용하는 기업을 위한 MLOps 기초 로드맵에 정의된 바와 같이, ML 및 운영 (MLOps)은 기계 학습 (ML) 솔루션을 효율적으로 생산하기 위한 사람, 프로세스 및 기술의 조합입니다. 이를 위해서는 다음 그림에 나와 있는 것처럼 팀과 구성원의 페르소나가 함께 협업해야 합니다.

이들 팀은 다음과 같습니다.

고급 분석 팀 (데이터 레이크 및 데이터 메시) – 데이터 엔지니어는 여러 소스의 데이터를 준비 및 수집하고, 데이터를 큐레이팅 및 카탈로그화하기 위한 ETL (추출, 변환, 로드) 파이프라인을 구축하고, ML 사용 사례에 필요한 과거 데이터를 준비하는 일을 담당합니다. 이러한 데이터 소유자는 여러 사업부 또는 팀에 데이터에 대한 액세스를 제공하는 데 중점을 둡니다.
데이터 사이언스 팀 – 데이터 사이언티스트는 노트북에서 작업하는 사전 정의된 핵심 성과 지표 (KPI) 를 기반으로 최상의 모델을 만드는 데 집중해야 합니다. 연구 단계가 완료되면 데이터 사이언티스트는 ML 엔지니어와 협력하여 CI/CD 파이프라인을 사용하여 모델을 구축 (ML 파이프라인) 하고 프로덕션에 배포하기 위한 자동화를 만들어야 합니다.
비즈니스 팀 – 제품 소유자는 모델 성능을 평가하는 데 사용할 비즈니스 사례, 요구 사항 및 KPI를 정의할 책임이 있습니다. ML 소비자는 추론 결과 (예측) 를 사용하여 의사 결정을 내리는 다른 비즈니스 이해 관계자입니다.
플랫폼 팀 – 아키텍트는 비즈니스의 전반적인 클라우드 아키텍처와 모든 다양한 서비스가 서로 연결되는 방식을 담당합니다. 보안 SME는 비즈니스 보안 정책 및 요구 사항에 따라 아키텍처를 검토합니다. MLOps 엔지니어는 데이터 과학자와 ML 엔지니어가 ML 사용 사례를 제작할 수 있는 안전한 환경을 제공할 책임이 있습니다. 특히 이들은 비즈니스 및 보안 요구 사항을 기반으로 CI/CD 파이프라인, 사용자 및 서비스 역할, 컨테이너 생성, 모델 소비, 테스트 및 배포 방법론을 표준화하는 일을 담당합니다.
위험 및 규정 준수 팀 – 보다 제한적인 환경에서 감사자는 데이터, 코드 및 모델 아티팩트를 평가하고 비즈니스가 데이터 프라이버시와 같은 규정을 준수하는지 확인할 책임이 있습니다.

비즈니스의 규모 및 MLOps 성숙도에 따라 한 사람이 여러 페르소나를 관리할 수 있다는 점에 주의하여야 합니다.

다음 그림에 나와 있는 것처럼 이러한 페르소나에는 다양한 프로세스를 수행할 수 있는 전용 환경이 필요합니다.

환경은 다음과 같습니다.

플랫폼 관리 – 플랫폼 관리 환경은 플랫폼 팀이 AWS 계정을 생성하고 적절한 사용자와 데이터를 연결할 수 있는 곳입니다.
데이터 – 데이터 레이크 또는 데이터 메시라고도 하는 데이터 레이어는 데이터 엔지니어 또는 소유자와 비즈니스 이해 관계자가 데이터를 준비하고, 상호 작용하고, 시각화하는 데 사용하는 환경입니다.
실험 – 데이터 과학자는 샌드박스 또는 실험 환경을 사용하여 새로운 라이브러리와 ML 기술을 테스트하여 개념 증명이 비즈니스 문제를 해결할 수 있음을 입증합니다.
모델 구축, 모델 테스트, 모델 배포 – 모델 구축, 테스트 및 배포 환경은 데이터 과학자와 ML 엔지니어가 협업하여 연구를 자동화하고 프로덕션으로 전환하는 MLOps 계층입니다.
ML 거버넌스 – 퍼즐의 마지막 조각은 해당 페르소나가 모든 모델 및 코드 아티팩트를 저장, 검토 및 감사하는 ML 거버넌스 환경입니다.

다음 다이어그램은 Amazon SageMaker를 사용하는 기업을 위한 MLOps 기초 로드맵에서 이미 논의된 참조 아키텍처를 보여줍니다.

각 사업부에는 각각 중앙 집중식 또는 분산형 데이터 레이크 또는 데이터 메시에서 데이터를 검색하는 ML 사용 사례를 프로덕션화하기 위한 자체 개발 (자동 모델 교육 및 구축), 사전 프로덕션 (자동 테스트) 및 프로덕션 (모델 배포 및 제공) 계정 세트가 있습니다. 생성된 모든 모델 및 코드 자동화는 모델 레지스트리 기능을 사용하여 중앙 집중식 도구 계정에 저장됩니다. 이러한 모든 계정의 인프라 코드는 공유 서비스 계정 (고급 분석 거버넌스 계정) 으로 버전이 지정되며, 플랫폼 팀은 이 계정을 추상화하고, 템플릿화하고, 유지 관리하고, 새 팀을 MLOps 플랫폼에 온보딩하는 데 재사용할 수 있습니다.

생성형 AI 정의 및 MLOps와의 차이점

클래식 ML에서는 앞서 언급한 사람, 프로세스, 기술을 조합하면 ML 사용 사례를 서비스화하는 데 도움이 될 수 있습니다. 하지만 생성형AI에서는 사용 사례의 특성상 기존 기능의 확장이나 새로운 기능이 필요합니다. 이에 따른 새로운 개념 중 하나가 파운데이션 모델 (FM) 입니다. 다음 그림과 같이 다양한 다른 AI 모델을 만드는 데 사용할 수 있기 때문에 그렇게 이름이 붙여졌습니다.

FM은 테라바이트의 데이터를 기반으로 훈련되었으며, 생성형 AI 사용 사례의 세 가지 주요 범주를 기반으로 최적의 답변을 예측할 수 있도록 수천억 개의 매개변수를 보유하고 있습니다.

텍스트를 텍스트로 변환 – FM(LLM) 은 레이블이 지정되지 않은 데이터 (예: 일반적인 텍스트) 를 기반으로 학습되었으며 다음으로 가장 적합한 단어 또는 단어 순서 (단락 또는 긴 에세이) 를 예측할 수 있습니다. 주요 사용 사례는 사람과 비슷한 챗봇, 요약 또는 프로그래밍 코드와 같은 기타 콘텐츠 제작 등입니다.
텍스트를 이미지로 변환 – <text, image>와 같이 레이블이 지정된 데이터는 최적의 픽셀 조합을 예측할 수 있는 FM의 학습에 사용되고 있습니다.
텍스트를 오디오 또는 비디오로 변환 – 레이블이 있는 데이터와 레이블이 지정되지 않은 데이터 모두 FM 교육에 사용할 수 있습니다. 주요 생성형 AI 사용 사례 중 하나는 음악 작곡입니다.

이러한 생성형 AI 사용 사례를 생산하려면 다음을 포함하도록 MLOps 도메인을 차용하고 확장해야 합니다.

FM 운영 (FMOps) – 이를 통해 모든 사용 사례 유형들에 대한 생성형 AI 솔루션을 프로덕션화할 수 있습니다.
LLM 운영 (LLMOps) – 텍스트 변환과 같은 LLM 기반 솔루션 제작에 중점을 둔 FMOps의 하위 집합입니다.

다음 그림은 이러한 사용 사례의 중복을 보여줍니다.

클래식 ML 및 MLOps와 비교하면, FMOps와 LLMOps는 다음 섹션에서 다루는 4가지 주요 범주, 즉 사람과 프로세스, FM 선택 및 조정, FM 평가 및 모니터링, 데이터 프라이버시 및 모델 배포, 기술 요구 사항들에서 차이가 있습니다. 모니터링에 대해서는 별도의 포스트에서 다루도록 하겠습니다.

생성형 AI 사용자 유형별 운영 경로

프로세스 설명을 단순화하기 위해, 다음 그림과 같이 주요 생성형 AI 사용자 유형을 분류합니다.

사용자 유형은 다음과 같습니다.

공급자 – FM을 처음부터 구축하여 다른 사용자(파인 튜너 및 소비자)에게 제품으로 제공하는 사용자입니다. 이들은 포괄적인 ML 및 자연어 처리 (NLP) 전문 지식과 데이터 과학 기술, 대규모 데이터 레이블러 및 편집자 팀을 보유하고 있습니다.
파인 튜너 – 공급자의 FM을 사용자 지정 요구 사항에 맞게 재교육 (파인 튜닝) 하는 사용자입니다. 이들은 소비자가 사용할 수 있도록 모델을 서비스로 배포하는 과정을 조율합니다. 이러한 사용자에게는 강력한 엔드 투 엔드 ML 및 데이터 과학 전문 지식과 모델 배포 및 추론에 대한 지식이 필요합니다. 신속한 엔지니어링을 포함한 튜닝에 대한 탄탄한 도메인 지식도 필요합니다.
소비자 – 텍스트 프롬프트나 시각적 인터페이스를 통해 제공업체 또는 파인 튜너가 제공하는 생성형 AI 서비스와 상호 작용하여 원하는 조치를 완료하는 사용자입니다. ML 전문 지식은 필요하지 않지만, 서비스의 기능을 이해하는 대부분의 애플리케이션 개발자나 최종 사용자가 여기에 속합니다. 더 나은 결과를 얻으려면 프롬프트 엔지니어링이 필요합니다.

정의와 필요한 ML 전문 지식에 따르면, MLOps는 대부분 공급자와 파인 튜너에게 필요한 반면, 소비자는 DevOps 및 AppDev와 같은 애플리케이션 제작 원칙을 사용하여 생성형 AI 애플리케이션을 만들 수 있습니다. 또한, 공급자가 특정 업종 (예: 금융 부문) 에 기반한 사용 사례를 지원하기 위해 파인 튜너가 되거나 소비자가 더 정확한 결과를 얻기 위해 파인 튜너가 될 수 있는 사용자 유형 간의 이동도 확인할 수 있었습니다. 우선적으로 사용자 유형별 주요 프로세스를 살펴보겠습니다.

소비자 경로

다음 그림은 소비자 경로를 보여줍니다.

앞서 언급했듯이 소비자는 FM을 선택, 테스트 및 사용해야 하며 프롬프트라고도 하는 특정 입력을 제공하여 FM과 상호 작용해야 합니다. 컴퓨터 프로그래밍 및 AI의 맥락에서 프롬프트는 응답을 생성하기 위해 모델이나 시스템에 제공되는 입력을 말합니다. 이는 텍스트, 명령 또는 질문의 형태일 수 있으며, 시스템에서 이를 사용하여 결과를 처리하고 생성합니다. 그러면 FM에서 생성된 출력을 최종 사용자가 활용할 수 있으며 최종 사용자는 이러한 출력에 등급을 매겨 모델의 향후 반응을 개선할 수 있어야 합니다.

이러한 기본 프로세스 외에도, 파인 튜너가 제공하는 기능을 활용하여 모델을 파인 튜닝하려는 소비자들도 있습니다. 이미지를 생성하는 웹사이트를 예로 들어 보겠습니다. 여기서 최종 사용자는 개인 계정을 설정하고 개인 사진을 업로드한 다음 해당 이미지와 관련된 콘텐츠를 생성할 수 있습니다 (예: 칼을 휘두르는 오토바이를 타거나 이국적인 장소에 있는 최종 사용자의 모습을 묘사한 이미지 생성). 이 시나리오에서는 소비자가 설계한 생성형 AI 애플리케이션은 최종 사용자에게 이 기능을 제공하기 위해서 API를 통해 파인 튜너의 백엔드와 상호 작용해야 합니다.

이에 대해서 자세히 알아보기 전에, 먼저 다음 그림에서 보여지는 모델 선택, 테스트, 사용, 입력 및 출력 상호 작용, 등급 지정 과정에 대해 자세히 알아보겠습니다.

활용 가능한 15K FM 참고 자료

1단계. 주요 FM 기능 이해

파운데이션 모델을 선택할 때는 사용 사례, 사용 가능한 데이터, 규정 등에 따라 여러 차원을 고려해야 합니다. 포괄적이지는 않지만 다음과 같은 체크리스트가 유용할 수 있습니다.

독점 또는 오픈 소스 FM – 독점 모델은 대개 재정적 비용이 들지만 일반적으로 더 나은 성능 (생성된 텍스트 또는 이미지의 품질 측면에서) 을 제공하며, 최적의 성능과 안정성을 보장하는 모델 제공업체로 구성된 전담 팀이 개발하고 유지 관리하는 경우가 많습니다. 다른 한편으로는 무료라는 점 외에도 접근성과 유연성이라는 추가적인 이점을 제공하는 오픈 소스 모델도 채택되고 있습니다 (예: 모든 오픈 소스 모델은 파인 튜닝 가능). 독점 모델의 예로는 Anthrophic의 Claude 모델을 들 수 있으며, 고성능 오픈소스 모델의 예로는 2023년 7월 기준 Falcon-40B를 들 수 있습니다.
상용 라이선스 – FM을 결정할 때는 라이선스에 대한 고려는 매우 중요합니다. 일부 모델은 오픈 소스이지만 라이선스 제한 또는 특정 조건으로 인해 상업적 목적으로 사용할 수 없다는 점에 유의해야 합니다. 그 차이점은 잘 확인해야 합니다. 예를 들어 새로 출시된xgen-7b-8k-base 모델은 오픈 소스이며 상업적으로 사용 가능한 (Apache-2.0 라이선스) 인 반면, xgen-7b-8k-inst 모델의 명령어 파인 튜닝 버전은 연구 목적으로만 출시됩니다. 상용 애플리케이션용 FM을 선택할 때는 라이선스 계약을 확인하고, 제한 사항을 이해하고, 프로젝트의 용도에 맞는지 확인하는 것이 중요합니다.
매개변수 – 신경망의 가중치와 편향으로 구성된 매개변수의 수는 또 다른 핵심 요소입니다. 매개변수가 많을수록 데이터에서 더 복잡한 패턴과 상관 관계를 포착할 수 있기 때문에 일반적으로 모델이 더 복잡하고 잠재적으로 강력하다는 것을 의미합니다. 하지만 계산 리소스가 더 많이 필요하고 따라서 실행 비용이 더 많이 든다는 단점이 있습니다. 추가로, 특히 파인 튜닝되어 성능이 우수한 오픈 소스 영역 (70~400억 모델) 에서 소형 모델을 선호하는 추세도 확인할 수 있습니다.
속도 – 모델의 속도는 모델 크기에 영향을 받습니다. 모델이 클수록 계산 복잡성이 증가하기 때문에 데이터를 더 느리게 처리하는 경향이 있습니다 (더 긴 지연 시간 발생). 따라서 특히 실시간 또는 거의 실시간에 가까운 응답이 필요한 채팅 봇과 같은 애플리케이션에서는 예측력이 높은 모델 (주로 대형 모델) 의 필요성과 속도에 대한 실제 요구 사항 간의 균형을 맞추는 것이 중요합니다.
컨텍스트 윈도우 크기 (토큰 수) – 프롬프트당 입력 또는 출력할 수 있는 최대 토큰 수로 정의되는 컨텍스트 윈도우는 모델이 한 번에 고려할 수 있는 컨텍스트의 양을 결정하는 데 매우 중요합니다 (토큰은 영어의 경우 대략 0.75단어로 변환됨). 컨텍스트 윈도우가 큰 모델은 더 긴 텍스트 시퀀스를 이해하고 생성할 수 있으므로 더 긴 대화나 문서 작업에 유용할 수 있습니다.
학습 데이터 세트 – FM이 어떤 종류의 데이터를 대상으로 학습되었는지 이해하는 것도 중요합니다. 일부 모델은 인터넷 데이터, 코딩 스크립트, 지침 또는 사용자 피드백과 같은 다양한 텍스트 데이터 세트를 기반으로 학습될 수 있습니다. 텍스트와 이미지 데이터의 조합과 같은 멀티모달 데이터 세트에 대해 학습된 데이터셋도 있을 수 있습니다. 이는 다양한 작업에 대한 모델의 적합성에 영향을 미칠 수 있습니다. 또한 조직은 모델의 학습에 사용한 소스에 따라 저작권 문제를 겪을 수 있습니다. 따라서 교육 데이터 세트를 면밀히 검토하는 것이 필수입니다.
품질 – FM의 품질은 유형 (독점 버전 vs 오픈 소스), 크기, 교육 대상에 따라 달라질 수 있습니다. 품질은 상황에 따라 달라집니다. 즉, 한 애플리케이션에서 고품질로 간주되는 것이 다른 애플리케이션에서는 그렇지 않을 수 있습니다. 예를 들어 인터넷 데이터를 기반으로 학습된 모델은 대화형 텍스트를 생성할 때는 품질이 우수하다고 간주될 수 있지만 기술적이거나 전문적인 작업에서는 그렇지 않을 수 있습니다.
파인 튜닝 가능 – 모델 가중치 또는 레이어를 조정하여 FM을 파인 튜닝하는 기능은 중요한 요소일 수 있습니다. 파인 튜닝을 통해 모델이 애플리케이션의 특정 상황에 더 잘 적응하여 주어진 특정 작업의 성능을 개선할 수 있습니다. 그러나 파인 튜닝에는 추가 계산 리소스와 기술 전문 지식이 필요하며 모든 모델이 이 기능을 지원하는 것은 아닙니다. 일반적으로 오픈 소스 모델은 항상 파인 튜닝이 가능합니다. 모델 아티팩트를 다운로드할 수 있고 사용자가 마음대로 확장하여 사용할 수 있기 때문입니다. 독점 모델이 파인 튜닝 옵션을 제공하는 경우도 있습니다.
고객의 기술 수준 – FM 선택은 고객 또는 개발 팀의 기술 및 친숙도에 영향을 받을 수도 있습니다. 팀에 AI/ML 전문가가 없는 조직의 경우 API 서비스가 더 적합할 수 있습니다. 또한 특정 FM에 대한 경험이 풍부한 팀이라면 새로운 FM을 배우고 적응하는 데 시간과 리소스를 투자하는 것보다 계속 사용하는 것이 더 효율적일 수 있습니다.

다음은 두 개의 후보 명단의 예입니다. 하나는 독점 모델용이고 다른 하나는 오픈 소스 모델용입니다. 특정 요구 사항에 따라 유사한 표를 컴파일하여 사용 가능한 옵션에 대한 간략한 개요를 얻을 수 있습니다. 단, 이러한 모델의 성능과 매개변수는 빠르게 변하고, 이 글을 읽는 시점에는 오래된 내용이 될 수 있지만, 지원되는 언어와 같은 다른 기능이 특정 고객에게 중요할 수 있습니다.

다음은 AWS에서 사용 가능한 주요 독점 FM의 예입니다 (2023년 7월 기준).

다음은 AWS에서 사용할 수 있는 주목할 만한 오픈 소스 FM의 예입니다 (2023년 7월 기준).

10-20개의 잠재적 후보 모델에 대한 개요를 작성한 후에는, 이 후보 목록을 더 세분화해야 합니다. 이 섹션에서는 두 개 또는 세 개의 실행 가능한 최종 모델을 다음 라운드의 후보로 제시할 수 있는 신속한 메커니즘을 제안합니다.

다음 다이어그램은 초기 후보 등록 프로세스를 보여줍니다.

일반적으로 AI 모델이 사용자 입력을 이해하고 처리할 수 있는 고품질 프롬프트를 만드는 전문가인 프롬프트 엔지니어는 모델에 대해 동일한 작업 (예: 요약) 을 수행하기 위해 다양한 방법을 실험합니다. 이러한 프롬프트는 즉석으로 생성하지 않고, 프롬프트 카탈로그에서 체계적으로 추출하는 것이 좋습니다. 이 프롬프트 카탈로그는 복제를 방지하고, 버전 제어를 활성화하고, 팀 내에서 프롬프트를 공유하여 다양한 개발 단계에서 서로 다른 프롬프트 테스터 간의 일관성을 보장하기 위한 프롬프트의 중심 저장소입니다. 이에 대해서는 다음 섹션에서 더 말씀드리겠습니다. 이 프롬프트 카탈로그는 피처 스토어의 Git 리포지토리와 비슷합니다. 프롬프트 엔지니어와 동일인이 될 가능성이 있는 생성형 AI 개발자는 결과를 평가하여 개발하려는 생성형 AI 애플리케이션에 적합한지 결정해야 합니다.

2단계. 상위 FM 테스트 및 평가

후보 명단을 약 3개의 FM으로 줄인 후에는 FM의 기능과 사용 사례에 대한 적합성을 추가로 테스트하기 위한 평가 단계를 권장합니다. 평가 데이터의 가용성과 특성에 따라 다음 그림과 같이 다양한 방법을 제안합니다.

먼저, 사용할 방법은 레이블이 지정된 테스트 데이터 보유 여부에 따라 달라집니다.

레이블이 지정된 데이터를 가지고 있는 경우, 기존 ML 모델과 마찬가지로 데이터를 사용하여 모델 평가를 수행할 수 있습니다 (일부 샘플을 입력하고 결과를 레이블과 비교). 테스트 데이터에 개별 레이블 (예: 긍정적, 부정적 또는 중립적 감정 분석) 이 있는지 아니면 비정형 텍스트 (예: 요약) 인지에 따라 서로 다른 평가 방법을 제안합니다.

정확도 지표 – 개별 결과 (예: 감정 분석) 의 경우 정밀도, 재현율, F1 점수와 같은 표준 정확도 지표를 사용할 수 있습니다.
유사성 지표 – 출력이 비정형 (예: 요약) 인 경우 ROUGE 및 코사인 유사성과 같은 유사성 지표를 권장합니다.

일부 사용 사례에서는 하나의 정답을 얻을 수가 없습니다. (예: “5살짜리 딸을 위한 짧은 동화 만들기”). 이런 경우에는 레이블이 지정된 테스트 데이터가 없기 때문에 모델을 평가하기가 더 어려워집니다. 모델에 대한 사람의 검토와 자동 평가의 중요도에 따라 두 가지 접근 방식을 제안합니다.

Human-in-the-Loop (HIL) – 이 경우 프롬프터 테스터 팀이 모델의 응답을 검토합니다. 애플리케이션의 중요도에 따라 프롬프트 테스터는 모델 출력의 100% 또는 샘플을 검토할 수 있습니다.
LLM 기반 평가 – 이 시나리오에서는 프롬프트 테스터를 LLM으로 대체합니다. 테스트 대상보다 더 강력한 (아마도 느리고 비용이 가장 많이 드는) LLM이 이상적입니다. LLM은 모델에서 생성된 모든 응답을 검토하고 점수를 매깁니다. 이 방법을 사용하면 품질이 떨어질 수 있지만 모델 성능에 대한 좋은 초기 척도를 제공할 수 있는 저렴하고 빠른 평가 옵션입니다.

입력 쿼리, LLM 응답 및 지침이 포함된 LLM에 대한 다음 예제 프롬프트의 예를 보겠습니다. “위에 표시된 사용자 질문에 대한 답변으로 AI 어시스턴트의 성능에 대한 피드백을 요청하고자 합니다. 어시스턴트 응답의 유용성, 관련성, 정확성, 세부 수준을 평가해 주세요. 어시스턴트는 1에서 10까지의 척도로 전체 점수를 받아야 하며, 점수가 높을수록 전반적인 성과가 더 좋음을 나타냅니다.”

이 프롬프트는 평가를 위해 다른 LLM (EvalLLM) 으로 전송됩니다. 다음은 EvalLLM (이 경우는 Claude) 이 Falcon-40B 모델의 응답을 평가한 예입니다. 우리는 “수에즈 운하가 건설되지 않았다면 어땠을까요?” 라는 질문을 던집니다. 이에 대한 답변은 다음과 같습니다.

질문: 만약 수에즈 운하가 건설되지 않았다면 어땠을까요?

falcon-40b-instruct

수에즈 운하가 건설되지 않았다면 선박은 지중해와 홍해 사이를 항해하기 위해 아프리카 전역을 돌아다녀야 했을 것입니다. 이로 인해 항해에 상당한 시간과 거리가 추가되어 효율성이 떨어지고 비용이 더 많이 들 것입니다. 또한 수에즈 운하가 없었다면 중동과 북아프리카의 많은 국가들이 전 세계와의 연결이 훨씬 원활하지 않아 경제 및 문화 발전을 저해했을 것입니다.

리뷰 (점수: 9/10)

어시스턴트의 답변은 관련성이 높고 정확하며 상세합니다. 이는 수에즈 운하의 부재에 대한 사용자의 가상의 질문에 대한 훌륭한 해답을 제공합니다. 어시스턴트는 해상 여행에 미치는 영향과 중동 및 북아프리카에 미치는 경제적, 문화적 영향을 정확하게 지적합니다. 하지만 보다 포괄적인 대응을 위해 지정학적 영향이나 세계 무역 패턴에 미치는 영향에 대해 더 자세히 설명했을 수도 있습니다.

다음 그림은 엔드-투-엔드 평가 프로세스의 예를 보여줍니다.

위의 예와 같이, 평가를 수행하려면 프롬프트 카탈로그에 저장하는 예제 프롬프트와 특정 애플리케이션을 기반으로 레이블이 지정되거나 레이블이 지정되지 않은 평가 데이터 세트를 제공해야 합니다. 예를 들어 레이블이 지정된 평가 데이터 세트를 사용하여 “2023년 영국 총리의 전체 이름을 알려주세요”와 같은 프롬프트 (입력 및 쿼리) 와 “Rishi Sunak”과 같은 출력 및 답변을 제공할 수 있습니다. 레이블이 지정되지 않은 데이터셋의 경우 “소매 웹사이트용 소스 코드 생성”과 같은 질문이나 지침만 제공합니다. 프롬프트 카탈로그와 평가 데이터 세트의 조합을 평가 프롬프트 카탈로그라고 합니다. 프롬프트 카탈로그와 평가 프롬프트 카탈로그를 구분하는 이유는 후자의 경우 프롬프트 카탈로그에 포함된 일반적인 프롬프트와 지침 (예: 질문 응답) 대신 특정 사용 사례에만 사용되기 때문입니다

이 평가 프롬프트 카탈로그의 다음 단계는 최상위 FM에 평가 프롬프트를 제공하는 것입니다. 결과는 프롬프트, 각 FM의 출력 및 레이블이 지정된 출력이 점수 (있는 경우) 와 함께 포함된 평가 결과 데이터 세트입니다. 레이블이 지정되지 않은 평가 프롬프트 카탈로그의 경우 앞서 설명한 대로 HIL 또는 LLM에서 결과를 검토하고 점수 및 피드백을 제공하는 추가 단계가 있습니다. 최종 결과는 모든 산출물의 점수를 합산하여 (평균 정밀도 또는 인간 등급 계산) 사용자가 모델의 품질을 벤치마킹할 수 있는 집계된 결과입니다.

평가 결과를 수집한 후에는 여러 차원을 기반으로 모델을 선택하는 것이 좋습니다. 이는 일반적으로 정밀도, 속도, 비용 등의 요인으로 귀결됩니다. 다음 그림은 예제를 보여줍니다.

각 모델에는 이러한 차원에 따른 강점과 특정 절충점이 있습니다. 사용 사례에 따라 이러한 차원에 다양한 우선 순위를 할당해야 합니다. 이전 예시에서는 비용을 가장 중요한 요소로 지정하고 그 다음으로 정밀도, 속도를 우선시했습니다. 위의 그림에서 FM2는 FM1보다 느리고 효율적이지 않더라도 충분히 효과적이며 호스팅 비용도 훨씬 저렴합니다. 따라서 FM2를 최고의 선택지로 선택할 수도 있습니다.

3단계. 생성형 AI 애플리케이션 백엔드 및 프론트엔드 개발

이 단계에서 생성형 AI 개발자는 프롬프트 엔지니어와 테스터의 도움을 받아 특정 애플리케이션에 적합한 FM을 선택하게 됩니다. 다음 단계는 생성형 AI 애플리케이션 개발을 시작하는 것입니다. 다음 그림과 같이 생성형AI 애플리케이션의 개발을 백엔드와 프론트엔드의 두 계층으로 분리했습니다.

백엔드에서, 생성형 AI 개발자는 선택한 FM을 솔루션에 통합하고 프롬프트 엔지니어와 협력하여 최종 사용자 입력을 적절한 FM 프롬프트로 변환하는 자동화를 만듭니다. 프롬프트 테스터는 자동 또는 수동 (HIL 또는 LLM) 테스트에 필요한 항목을 프롬프트 카탈로그에 생성합니다. 그런 다음 생성형 AI 개발자가 프롬프트 체이닝(chaining) 및 애플리케이션 메커니즘을 만들어 최종 결과를 제공합니다. 이러한 맥락에서 프롬프트 체이닝은 보다 동적이고 상황에 맞는 LLM 애플리케이션을 만드는 기법입니다. 복잡한 작업을 더 작고 관리하기 쉬운 일련의 하위 작업으로 나누는 방식으로 작동합니다. 예를 들어, LLM에게 “영국 총리는 어디서 태어났고 그 장소는 런던에서 얼마나 멀리 떨어져 있습니까?” 라는 질문을 하면 작업을 개별 프롬프트로 나눌 수 있습니다. 그러면 “영국 총리는 누구인가”, “출생지는 어디입니까”, “런던에서 얼마나 떨어져 있습니까?” 와 같은 이전의 신속한 평가의 답변을 기반으로 프롬프트를 만들 수 있습니다. 특정 입력 및 출력 품질을 보장하기 위해 생성형 AI 개발자는 최종 사용자 입력 및 애플리케이션 출력을 모니터링하고 필터링하는 메커니즘도 만들어야 합니다. 예를 들어 LLM 애플리케이션이 유해한 요청과 응답을 피해야 한다면 입력과 출력에 유해성 검출기를 적용하고 이를 필터링할 수 있습니다. 마지막으로, 평가 프롬프트 카탈로그에 좋은 예와 나쁜 예시를 추가할 수 있는 등급 매커니즘을 제공해야 합니다. 이러한 메커니즘에 대한 자세한 내용은 향후 게시물에서 소개될 예정입니다.

생성형AI 최종 사용자에게 기능을 제공하려면 백엔드와 상호 작용하는 프론트엔드 웹 사이트 개발이 필요합니다. 따라서 DevOps 및 AppDevs (클라우드 기반 애플리케이션 개발자) 페르소나는 모범 개발 사례를 따라 입력/출력 및 등급 지정 기능을 구현해야 합니다.

이러한 기본 기능 외에도 프론트엔드와 백엔드는 개인 사용자 계정을 만들고, 데이터를 업로드하고, 블랙박스로 파인 튜닝을 시작하며, 기본 FM 대신 개인화된 모델을 사용하는 기능을 통합해야 합니다. 생성형 AI 애플리케이션의 제작은 일반 애플리케이션과 유사합니다. 다음 그림은 예제 아키텍처를 보여줍니다.

이 아키텍처에서는 생성형AI 개발자, 프롬프트 엔지니어, DevOps 또는 AppDev가 전용 코드 리포지토리를 사용하여 CI/CD를 통해 개발 환경 (위 그림의 생성형 AI App Dev) 에 배포하고 dev 브랜치와 병합하여 애플리케이션을 수동으로 만들고 테스트합니다. 이 단계에서 생성형 AI 개발자는 파인 튜너의 FM 제공자가 제공한 대로 API를 호출하여 해당 FM을 사용합니다. 그런 다음 애플리케이션을 광범위하게 테스트하려면 코드를 테스트 브랜치로 승격해야 합니다. 그러면 CI/CD를 통해 프리프로덕션 환경 (생성형AI App Pre-Prod) 에 배포가 시작됩니다. 이 환경에서 프롬프트 테스터는 많은 양의 프롬프트 조합을 시도하고 결과를 검토해야 합니다. 향후 테스트 프로세스를 자동화하려면 프롬프트, 출력 및 검토의 조합을 평가 프롬프트 카탈로그로 옮겨야 합니다. 이 광범위한 테스트를 거친 후 마지막 단계는 메인 브랜치 (생성형AI App Prod) 와 합병하여 CI/CD를 통해 생성형AI 애플리케이션을 프로덕션으로 승격시키는 것입니다. 참고로 프롬프트 카탈로그, 평가 데이터 및 결과, 최종 사용자 데이터 및 메타데이터, 파인 튜닝된 모델 메타데이터를 포함한 모든 데이터는 데이터 레이크 또는 데이터 메시 레이어에 저장되어야 합니다. CI/CD 파이프라인과 리포지토리는 별도의 도구 계정 (MLOps에 대해 설명한 것과 유사) 에 저장해야 합니다.

공급자 경로

FM 제공업체는 딥 러닝 모델과 같은 FM을 교육해야 합니다. 이들에게는 엔드-투-엔드 MLOps 라이프사이클과 인프라가 필요합니다. 과거 데이터 준비, 모델 평가 및 모니터링 추가가 필요합니다. 다음 그림은 이들의 경로를 보여줍니다.

클래식 ML에서는 대부분 ETL 파이프라인을 통해 실측 데이터를 제공하여 기록 데이터를 생성합니다. 예를 들어 이탈 예측 사용 사례의 경우, 자동화는 고객의 새로운 상태를 기반으로 데이터베이스 테이블을 이탈/비이탈로 자동으로 업데이트합니다. FM의 경우 레이블이 지정되거나 레이블이 지정되지 않은 수십억 개의 데이터 포인트가 필요합니다. 텍스트를 이미지로 변환하는 사용 사례에서는 데이터 레이블 팀이 수동으로 <text, image> 쌍으로 레이블을 지정해야 합니다. 이는 많은 인력을 필요로 하는 비용이 많이 드는 작업입니다. Amazon SageMaker Ground Truth Plus는 사용자를 대신하여 이 활동을 수행할 수 있는 레이블 팀을 제공할 수 있습니다. 일부 사용 사례의 경우, 예를 들어 CLIP과 유사한 모델을 사용하여 이 프로세스를 부분적으로 자동화할 수도 있습니다. 텍스트를 텍스트로 변환하는 것과 같은 LLM의 경우에는 데이터에 레이블이 지정되지 않습니다. 그러나 레이블이 지정되지 않은 기존 과거 데이터의 형식을 따르고 준비해야 합니다. 따라서 필요한 데이터 준비를 수행하고 일관성을 보장하려면 데이터 편집자가 필요합니다.

기간별 데이터를 준비했으면 다음 단계는 모델을 학습하고 제작하는 것입니다. 소비자를 대상으로 설명한 것과 동일한 평가 기법을 사용할 수 있음에 주의하시기 바랍니다.

파인 튜너 경로

파인 튜너는 기존 FM을 특정 상황에 맞게 조정하는 것을 목표로 합니다. 예를 들어 FM 모델은 범용 텍스트는 요약할 수 있지만 재무 보고서는 정확하게 요약할 수 없거나 일반적이지 않은 프로그래밍 언어의 소스 코드를 생성할 수 없습니다. 이러한 경우 파인 튜너는 데이터에 레이블을 지정하고, 학습 작업을 실행하여 모델을 파인 튜닝하고, 모델을 배포하고, 소비자 프로세스를 기반으로 테스트하고, 모델을 모니터링해야 합니다. 다음 다이어그램은 이 프로세스를 보여줍니다.

지금까지는 다음과 같은 두 가지 파인 튜닝 메커니즘이 있습니다.

Fine-tuning – FM과 레이블이 지정된 데이터를 사용하여 교육 작업에서 딥러닝 모델 계층의 가중치와 편향을 다시 계산합니다. 이 프로세스는 계산 집약적일 수 있고 상당한 양의 데이터가 필요하지만 정확한 결과를 생성할 수 있습니다.
Parameter-efficient fine-tuning (PEFT) -모든 가중치와 편향을 다시 계산하는 대신, 연구자들은 딥러닝 모델에 작은 계층을 추가하면 만족스러운 결과(예: LoRA)를 얻을 수 있음을 보여주었습니다. PEFT는 딥 파인 튜닝보다 낮은 계산 능력과 입력 데이터가 적은 교육 작업을 필요로 합니다. 단점은 정확도가 낮아질 수 있다는 것입니다.

다음 다이어그램은 이러한 메커니즘을 보여줍니다.

이제 두 가지 주요 파인 튜닝 방법을 정의했으므로, 다음 단계는 오픈 소스 및 독점 FM을 배포하고 사용하는 방법을 결정하는 것입니다.

오픈 소스 FM을 사용하면 파인 튜너가 예를 들어 Hugging Face Model Hub를 사용하여 웹에서 모델 아티팩트와 소스 코드를 다운로드할 수 있습니다. 이것은 모델을 세부적으로 조정하고, 로컬 모델 레지스트리에 저장하고, Amazon SageMaker 엔드포인트에 배포할 수 있는 유연성을 제공합니다. 이 프로세스에는 인터넷 연결이 필요합니다. 더 안전한 환경 (예: 금융 부문 고객) 을 지원하기 위해 모델을 온프레미스로 다운로드하고 필요한 모든 보안 검사를 실행한 다음 AWS 계정의 로컬 버킷에 업로드할 수 있습니다. 그러면 파인 튜너는 인터넷 연결 없이 로컬 버킷의 FM을 사용합니다. 이렇게 하면 데이터 프라이버시가 보장되고 데이터가 인터넷을 통해 전송되지 않습니다. 다음 다이어그램은 이 방법을 보여줍니다.

독점 FM을 사용하면 파인 튜너가 모델 아티팩트 또는 소스 코드에 액세스할 수 없기 때문에 배포 프로세스가 다릅니다. 모델은 독점 FM 제공업체 AWS 계정과 모델 레지스트리에 저장됩니다. 이러한 모델을 SageMaker 엔드포인트에 배포하기 위해 파인 튜너는 엔드포인트에 직접 배포할 모델 패키지만 요청할 수 있습니다. 이 프로세스를 수행하려면 독점 FM 공급자 계정에서 고객 데이터를 사용해야 하는데, 이로 인해 원격 계정에서 파인 튜닝을 수행하는 데 사용되는 고객 민감한 데이터와 여러 고객이 공유하는 모델 레지스트리에 호스팅되는 모델에 대해서 의문을 불러 일으키게 됩니다. 독점 FM 제공업체가 이러한 모델을 지원해야 하는 경우는 멀티테넌시에 대해 더 많은 문제가 제기될 수 있습니다. 파인 튜너가 Amazon Bedrock을 사용하면 이러한 문제가 해결됩니다. 데이터가 인터넷을 통해 전송되지 않고, FM 공급자가 파인 튜너의 데이터를 액세스할 수 없게 됩니다. 파인 튜너가 여러 고객의 모델에 서비스를 제공하려는 경우, 오픈 소스 모델에서도 동일한 문제가 발생합니다. 예를 들어, 앞서 말씀드린 수천 명의 고객이 개인화된 이미지를 업로드하는 웹 사이트가 그런 경우입니다. 하지만 파인 튜너만 관여하기 때문에 이러한 시나리오는 제어 가능한 것으로 간주할 수 있습니다. 다음 다이어그램은 이에 대한 방법을 보여주고 있습니다.

기술적 관점에서 볼 때, 파인 튜너가 지원해야 하는 아키텍처는 MLOps용 아키텍처와 비슷합니다 (다음 그림 참조). 파인 튜닝은 개발 단계에서 ML 파이프라인을 생성하여 수행하여야 합니다. Amazon SageMaker Pipeline을 예로 들면, 사전 처리, 파인 튜닝(훈련 작업)과 사후 처리를 수행할 수 있으며, 오픈 소스 FM을 사용할 경우 파인 튜닝 된 모델을 로컬 모델 레지스토리로 보낼 수 있습니다.(반대의 경우, 새 모델은 독점 FM 환경에 저장됩니다.) 그런 다음 사전 제작 단계에서 소비자 시나리오에 대해 설명한 대로 모델을 테스트해야 합니다. 마지막으로, 모델은 프로덕션에서 서비스되고 모니터링됩니다. 참고로 현재 (파인 튜닝 된) FM에는 GPU 인스턴스 엔드포인트가 필요합니다. 파인 튜닝 된 각 모델을 별도의 엔드포인트에 배포해야 하는 경우, 모델이 수백개가 되면 비용이 증가할 수 있습니다. 따라서 다중 모델 엔드포인트를 사용하여 멀티 테넌시 문제를 해결해야 합니다.

파인 튜너는 특정 상황에 따라 FM 모델을 조정하여 비즈니스 목적에 맞게 사용합니다. 즉, 대부분의 경우 파인 튜너는 이전 섹션에서 설명했듯이 생성형 AI 애플리케이션 개발, 데이터 레이크 및 데이터 메시, MLOps를 비롯한 모든 계층을 지원해야 하는 소비자이기도 합니다.

다음 그림은 파인 튜너가 생성형AI 최종 사용자에게 제공하는 데 필요한 전체 FM 파인 튜닝 라이프사이클을 보여줍니다.

다음 그림은 주요 단계를 보여줍니다.

주요 단계는 다음과 같습니다.

최종 사용자는 개인 계정을 만들고 개인 데이터를 업로드합니다.
데이터는 데이터 레이크에 저장되며 FM이 예상하는 형식에 따라 사전 처리됩니다.
그러면 모델을 모델 레지스트리에 추가하는 파인 튜닝 ML 파이프라인이 트리거됩니다.
그런 다음 모델을 최소한의 테스트로 프로덕션 환경에 배포하거나, HIL을 통해 광범위한 테스트를 진행하고 수동 승인 단계로 보내지게 됩니다.
최종 사용자는 파인 튜닝 된 모델을 사용할 수 있습니다.

엔터프라이즈 고객이 아닌 고객에게는 이 인프라스트럭쳐 구성이 복잡하기 때문에, AWS는 이러한 아키텍처를 구축하고 파인 튜닝 된 FM을 프로덕션에 더 가까이 가져오는 수고를 덜 수 있도록 Amazon Bedrock을 출시했습니다.

FMOps 및 LLMOps의 페르소나 및 프로세스 차별화 요소

이전 사용자 유형 여정 (소비자, 생산자, 파인 튜너) 을 기반으로, 다음 그림과 같이 특정 기술을 갖춘 새로운 페르소나가 필요합니다.

새로운 페르소나는 다음과 같습니다.

데이터 레이블러 및 편집자 – 이러한 사용자는 <text, image> 쌍과 같은 데이터에 레이블을 지정하거나 일반적인 텍스트와 같은 레이블이 지정되지 않은 데이터를 준비하고 고급 분석 팀 및 데이터 레이크 환경을 확장합니다.
파인 튜너 – 이러한 사용자는 FM에 대한 깊은 지식과 튜닝 기술을 갖추고 있어 클래식 ML에 집중할 데이터 과학 팀을 확장할 수 있습니다.
생성형 AI 개발자 – 이들은 FM 선택, 프롬프트 및 애플리케이션 연결, 입력 및 출력 필터링에 대한 심층적인 지식을 갖추고 있습니다. 이들은 생성형 AI 애플리케이션 팀이라는 새로운 팀에 속해 있습니다.
프롬프트 엔지니어 – 이 사용자는 입력 및 출력 프롬프트를 설계하여 솔루션을 상황에 맞게 조정하고 프롬프트 카탈로그의 초기 버전을 테스트 및 생성합니다. 이들의 팀은 생성형 AI 애플리케이션 팀입니다.
프롬프트 테스터 – 생성형 AI 솔루션 (백엔드 및 프런트엔드) 을 대규모로 테스트하고 결과를 제공하여 프롬프트 카탈로그 및 평가 데이터 세트를 보강합니다. 그들의 팀은 생성형 AI 애플리케이션 팀입니다.
AppDev 및 DevOps – 이들은 생성형 AI 애플리케이션의 프론트엔드 (예: 웹사이트) 를 개발합니다. 그들의 팀은 생성형 AI 애플리케이션 팀입니다.
생성형 AI 최종 사용자 – 이러한 사용자는 생성형 AI 애플리케이션을 블랙박스로 사용하고, 데이터를 공유하고, 출력 품질을 평가합니다.

생성형 AI를 통합하기 위한 MLOps 프로세스 맵의 확장 버전은 다음 그림과 같이 표현될 수 있습니다.

새로운 애플리케이션 계층은 생성형 AI 개발자, 프롬프트 엔지니어, 테스터, AppDevs가 생성형 AI 애플리케이션의 백엔드 및 프론트엔드를 만든 환경입니다. 생성형 AI 최종 사용자는 인터넷 (예: 웹 UI) 을 통해 생성형 AI 애플리케이션 프론트엔드와 상호 작용합니다. 반면, 데이터 레이블러와 편집자는 데이터 레이크나 데이터 메시의 백엔드에 액세스하지 않고 데이터를 전처리해야 합니다. 따라서 데이터와 안전하게 상호 작용하려면 편집기가 있는 웹 UI (웹 사이트) 가 필요합니다. SageMaker Ground Truth는 이 기능을 기본적으로 제공합니다.

결론

MLOps는 ML 모델을 효율적으로 제작하는 데 도움이 될 수 있습니다. 하지만 생성형 AI 애플리케이션을 운영하려면 FMOps 및 LLMOps로 이어지는 추가 기술, 프로세스 및 기술이 필요합니다. 이 게시물에서는 FMOps 및 LLMOps의 주요 개념을 정의하고 인력, 프로세스, 기술, FM 모델 선택 및 평가 측면에서 MLOP 기능과 비교한 주요 차별화 요소에 대해 설명했습니다. 또한 생성형 AI 개발자의 사고 과정과 생성형 AI 애플리케이션의 개발 라이프사이클을 설명했습니다.

앞으로는 논의한 영역별 솔루션을 제공하는 데 초점을 맞추고 FM 모니터링 (예: 유해성, 편향성, 환각) 과 RAG (Retrieval Augmented Generation) 와 같은 타사 또는 개인 데이터 소스 아키텍처 패턴을 FMOps/LLMOps에 통합하는 방법에 대한 자세한 내용을 제공할 예정입니다.

자세히 알아보시려면 Amazon SageMaker를 사용하는 기업을 위한 MLOps 기초 로드맵을 참조하시고 Amazon SageMaker JumpStart 사전 학습 모델을 사용한 MLOps 사례 구현에서 설명한 엔드 투 엔드 솔루션을 사용해 보시기 바랍니다.

AWS 기술 블로그