Azure Databricks의 LLMOps 워크플로
이 문서에서는 LLMOps 워크플로와 관련된 정보를 추가하여 Databricks의 MLOps 워크플로를 보완합니다. 자세한 내용은 MLOps의 큰 책을 참조하세요.
LLM에 대한 MLOps 워크플로는 어떻게 변경됩니까?
LLM은 개방형 질문 답변, 요약 및 명령 실행과 같은 다양한 작업에서 선행 작업의 크기와 성능을 크게 능가하는 NLP(자연어 처리) 모델 클래스입니다.
LLM의 개발 및 평가는 기존 ML 모델과 몇 가지 중요한 방법이 다릅니다. 이 섹션에서는 LLM의 일부 주요 속성과 MLOps에 대한 의미를 간략하게 요약합니다.
| LLM의 주요 속성 | MLOps에 대한 의미 |
|---|---|
| LLM은 다양한 형태로 사용할 수 있습니다. - 유료 API를 사용하여 액세스되는 일반 독점 및 OSS 모델입니다. - 일반 애플리케이션에서 특정 애플리케이션에 따라 달라지는 기성품 오픈 소스 모델입니다. - 특정 애플리케이션에 대해 미세 조정된 사용자 지정 모델입니다. - 미리 학습된 사용자 지정 애플리케이션 |
개발 프로세스: 프로젝트는 종종 기존, 타사 또는 오픈 소스 모델에서 시작하여 사용자 지정 미세 조정된 모델로 끝나는 증분 방식으로 개발됩니다. |
| 많은 LLM은 일반적인 자연어 쿼리 및 지침을 입력으로 사용합니다. 이러한 쿼리에는 원하는 응답을 유도하기 위해 신중하게 엔지니어링된 프롬프트가 포함될 수 있습니다. | 개발 프로세스: LLM을 쿼리하기 위한 텍스트 템플릿 디자인은 종종 새 LLM 파이프라인을 개발하는 데 중요한 부분입니다. ML 아티팩트 패키징: 많은 LLM 파이프라인은 기존 LLM 또는 LLM 서비스 엔드포인트를 사용합니다. 이러한 파이프라인을 위해 개발된 ML 논리는 모델 자체가 아닌 프롬프트 템플릿, 에이전트 또는 체인에 초점을 맞출 수 있습니다. 패키지되고 프로덕션으로 승격된 ML 아티팩트가 모델이 아닌 이러한 파이프라인일 수 있습니다. |
| 쿼리에 응답하는 데 도움이 되는 예제, 컨텍스트 또는 기타 정보가 포함된 프롬프트를 많은 LLM에 지정할 수 있습니다. | 인프라 제공: 컨텍스트를 사용하여 LLM 쿼리를 보강할 때 벡터 데이터베이스와 같은 추가 도구를 사용하여 관련 컨텍스트를 검색할 수 있습니다. |
| 타사 API는 독점 및 오픈 소스 모델을 제공합니다. | API 거버넌스: 중앙 집중식 API 거버넌스를 사용하면 API 공급자 간에 쉽게 전환할 수 있습니다. |
| LLM은 매우 큰 딥 러닝 모델이며, 종종 기가바이트에서 수백 기가바이트까지 다양합니다. | 인프라 제공: LLM은 실시간 모델 서비스 및 동적으로 로드해야 하는 모델의 경우 빠른 스토리지에 GPU가 필요할 수 있습니다. 비용/성능 절충: 큰 모델에는 더 많은 계산이 필요하고 서비스 비용이 더 많이 들기 때문에 모델 크기 및 계산을 줄이기 위한 기술이 필요할 수 있습니다. |
| LLM은 단일 "올바른" 답변이 없는 경우가 많으므로 기존 ML 메트릭을 사용하여 평가하기가 어렵습니다. | 사용자 의견: 사용자 피드백은 LLM을 평가하고 테스트하는 데 필수적입니다. 테스트, 모니터링 및 향후 미세 조정을 포함하여 사용자 피드백을 MLOps 프로세스에 직접 통합해야 합니다. |
MLOps와 LLMOps 간의 공통점
MLOps 프로세스의 많은 측면은 LLM에 대해 변경되지 않습니다. 예를 들어 다음 지침은 LLM에도 적용됩니다.
- 개발, 스테이징 및 프로덕션에 별도의 환경을 사용하세요.
- Git을 버전 제어에 사용합니다.
- MLflow를 사용하여 모델 개발을 관리하고 Unity 카탈로그의 모델을 사용하여 모델 수명 주기를 관리합니다.
- Delta 테이블을 사용하여 데이터를 Lakehouse 아키텍처에 저장합니다.
- 기존 CI/CD 인프라에는 변경이 필요하지 않습니다.
- MLOps의 모듈식 구조는 기능화, 모델 학습, 모델 유추 등에 대한 파이프라인과 동일하게 유지됩니다.
참조 아키텍처 다이어그램
이 섹션에서는 두 개의 LLM 기반 애플리케이션을 사용하여 기존 MLOps의 참조 아키텍처에 대한 일부 조정을 설명합니다. 다이어그램은 1) 타사 API를 사용하는 RAG(검색 보강 세대) 애플리케이션 및 2) 자체 호스팅 미세 조정 모델을 사용하는 RAG 애플리케이션에 대한 프로덕션 아키텍처를 보여 줍니다. 두 다이어그램 모두 선택적 벡터 데이터베이스를 보여 줍니다. 이 항목은 모델 서비스 엔드포인트를 통해 LLM을 직접 쿼리하여 바꿀 수 있습니다.
타사 LLM API를 사용하는 RAG
이 다이어그램은 Databricks 외부 모델을 사용하여 타사 LLM API에 연결하는 RAG 애플리케이션에 대한 프로덕션 아키텍처를 보여 줍니다.
파인 튜닝된 오픈 소스 모델을 사용하는 RAG
다이어그램은 오픈 소스 모델을 파인 튜닝하는 RAG 애플리케이션의 프로덕션 아키텍처를 보여 줍니다.
LLMOps에서 MLOps 프로덕션 아키텍처 변경
이 섹션에서는 LLMOps 애플리케이션에 대한 MLOps 참조 아키텍처의 주요 변경 내용을 강조 표시합니다.
모델 허브
LLM 애플리케이션은 종종 내부 또는 외부 모델 허브에서 선택한 기존 미리 학습된 모델을 사용합니다. 모델을 있는 그대로 사용하거나 파인 튜닝할 수 있습니다.
Databricks에는 Unity 카탈로그 및 Databricks Marketplace에서 미리 학습된 고품질의 기본 모델이 포함되어 있습니다. 이러한 미리 학습된 모델을 사용하여 최신 AI 기능에 액세스하여 사용자 지정 모델을 빌드하는 데 드는 시간과 비용을 절약할 수 있습니다. 자세한 내용은 Unity 카탈로그 및 Marketplace에서 미리 학습된 모델을 참조하세요.
벡터 데이터베이스
일부 LLM 애플리케이션은 빠른 유사성 검색을 위해 벡터 데이터베이스를 사용합니다. 예를 들어 LLM 쿼리에서 컨텍스트 또는 도메인 지식을 제공합니다. Databricks는 Unity 카탈로그의 델타 테이블을 벡터 데이터베이스로 사용할 수 있는 통합 벡터 검색 기능을 제공합니다. 벡터 검색 인덱스는 델타 테이블과 자동으로 동기화됩니다. 자세한 내용은 벡터 검색을 참조하세요.
벡터 데이터베이스에서 정보를 검색하는 논리를 캡슐화하고 반환된 데이터를 LLM에 컨텍스트로 제공하는 모델 아티팩트를 만들 수 있습니다. 그런 다음 MLflow LangChain 또는 PyFunc 모델 버전을 사용하여 모델을 기록할 수 있습니다.
LLM 파인 튜닝
LLM 모델은 처음부터 만드는 데 비용이 많이 들고 시간이 많이 걸리기 때문에 LLM 애플리케이션은 종종 기존 모델을 파인 튜닝하여 특정 시나리오에서 성능을 향상시킵니다. 참조 아키텍처에서 미세 조정 및 모델 배포는 고유한 Databricks 작업으로 표시됩니다. 배포하기 전에 파인 튜닝된 모델의 유효성을 검사하는 것은 종종 수동 프로세스입니다.
Databricks는 사용자 고유의 데이터를 사용하여 기존 LLM을 사용자 지정하여 특정 애플리케이션에 대한 성능을 최적화할 수 있는 파운데이션 모델 미세 조정을 제공합니다. 자세한 내용은 파운데이션 모델 미세 조정을 참조 하세요.
모델 지원
타사 API 시나리오를 사용하는 RAG에서 중요한 아키텍처 변경은 LLM 파이프라인이 모델 서비스 엔드포인트에서 내부 또는 타사 LLM API에 이르기까지 외부 API 호출을 한다는 것입니다. 이렇게 하면 복잡성, 잠재적 대기 시간 및 추가 자격 증명 관리가 추가됩니다.
Databricks에서는 AI 모델을 배포, 관리 및 쿼리할 수 있는 통합 인터페이스를 제공하는 Mosaic AI 모델 Serving을 제공합니다. 자세한 내용은 Mosaic AI 모델 제공을 참조하세요.
모니터링 및 평가에 대한 사용자 의견
사용자 의견 루프는 대부분의 LLM 애플리케이션에서 필수적입니다. 사용자 의견은 다른 데이터처럼 관리되어야 하며, 근 실시간 스트리밍을 기반으로 모니터링에 통합하는 것이 이상적입니다.
Mosaic AI 에이전트 프레임워크 검토 앱을 사용하면 사용자 검토자로부터 피드백을 수집할 수 있습니다. 자세한 내용은 에이전트 애플리케이션의 품질에 대한 피드백 가져오기를 참조하세요.