나만의 LLM 트윈 만들기: FTI 파이프라인을 활용한 효율적인 개발 전략

이 프로젝트는 “LLM Engineer’s Handbook: Master the art of engineering large language models from concept to production” 읽기 온라인 세미나 참여자들과 함께, 책 내용을 기반으로 합니다. 이 세미나는 페이스북 그룹 인텔리전트 대화형 소프트웨어 개발 – Rebooting Life에서 진행합니다.

이 글은 1장 내용을 다루는 첫 번째 세미나 두 개의 내용 정리 중 두 번째 입니다. 글 읽기는AIPilotSmarteasy GiantStep 나 교수와 함께하고, 글 작성은 차 교수에게 시켰습니다. 생성형 AI 공급사는 구글을 선택했습니다. 나 교수와 대화한 내용을 그대로 인용한 부분이 많았습니다. 마지막 부분에 “저스틴)”으로 제 의견을 달았습니다.

=======

LLM 트윈을 개발하기 위한 아키텍처를 설계합니다. FTI 파이프라인 아키텍처를 아키텍처 패턴으로 선택하여, LLM 트윈의 아키텍처를 설계합니다.

FTI(Feature/Training/Inference) 파이프라인 아키텍처

FTI 파이프라인 아키텍처의 가장 큰 장점은 세 가지 파이프라인의 명확한 인터페이스를 유지하면서 각 파이프라인을 독립적으로 개발, 배포, 확장, 모니터링할 수 있다는 것입니다. 이는 개발 과정의 유연성과 효율성을 크게 향상시켜 LLM 트윈 개발의 복잡성을 효과적으로 관리할 수 있도록 합니다.

1. 피처(Feature) 단계: 원시 데이터를 수집하고 모델 훈련 및 추론에 필요한 피처와 레이블을 생성하고, 피처 저장소(Feature Store)에 저장합니다. 훈련 및 추론 단계에서 이 저장소에서 필요한 피처를 가져옵니다.
– 입력: 원시 데이터 (다양한 형태의 데이터 가능)
– 출력: 피처와 레이블 (피처 저장소에 저장)

2. 훈련(Training) 단계: 피처 저장소에서 피처와 레이블을 가져와 모델을 훈련시키고, 훈련된 모델을 모델 레지스트리(Model Registry)에 저장합니다. 모델 훈련에 사용된 피처, 레이블, 버전 등의 메타데이터를 저장하여 모델의 투명성과 재현성을 높입니다
– 입력: 피처 저장소의 피처와 레이블
– 출력: 훈련된 모델 (모델 레지스트리에 저장)

3. 추론(Inference) 단계: 피처 저장소에서 피처와 레이블을, 모델 레지스트리에서 훈련된 모델을 가져와 예측을 생성합니다. 애플리케이션 요구사항에 따라 배치 또는 실시간 모드로 동작합니다. 사용된 피처, 레이블, 모델의 버전을 관리하여 모델 업데이트 및 롤백을 용이하게 합니다.
– 입력: 피처 저장소의 피처와 레이블, 모델 레지스트리의 훈련된 모델
– 출력: 예측 결과 (데이터베이스 또는 클라이언트에게 직접 제공)

아키텍처는 높은 수준의 설계 결정이며, 이러한 결정에는 항상 명확한 기술적 이유가 뒷받침되어야 합니다.

LLM Twin 기술적 요구사항

1. 데이터 측면:
– 자동화된 데이터 수집: LinkedIn, Medium, Substack, GitHub에서 정기적으로 데이터를 자동 수집해야 합니다.
– 데이터 저장 및 표준화: 수집된 데이터를 표준화하여 데이터 웨어하우스에 저장해야 합니다.
– 데이터 정제: 원시 데이터를 정제하고 전처리해야 합니다.
– 지시 데이터셋 생성: LLM 미세 조정을 위한 지시 데이터셋을 생성해야 합니다.
– 벡터 데이터 생성 및 저장: 정제된 데이터를 청크(chunk) 단위로 나누고 임베딩하여 벡터 데이터베이스(Vector DB)에 저장해야 합니다. 이는 RAG(Retrieval Augmented Generation)를 위한 것입니다.
2. 훈련 측면:
– 다양한 크기의 LLM 미세 조정: 다양한 크기의 LLM (7B, 14B, 30B, 70B 파라미터)을 미세 조정해야 합니다.
– 다양한 크기의 지시 데이터셋 사용: 다양한 크기의 지시 데이터셋을 사용하여 미세 조정을 수행해야 합니다.
– 다양한 LLM 유형 지원: Mistral, Llama, GPT 등 다양한 유형의 LLM을 지원해야 합니다.
– 실험 추적 및 비교: 실험 결과를 추적하고 비교하여 최적의 모델을 선택해야 합니다.
– 모델 평가 및 배포: 잠재적인 프로덕션 LLM 후보를 평가하고 배포해야 합니다.
– 자동화된 훈련 시작: 새로운 지시 데이터셋이 생성되면 자동으로 훈련을 시작해야 합니다.
3. 추론 측면:
– REST API 인터페이스: 클라이언트가 LLM Twin과 상호 작용할 수 있도록 REST API 인터페이스를 제공해야 합니다.
– 실시간 벡터 DB 접근: RAG를 위해 실시간으로 벡터 데이터베이스에 접근해야 합니다.
– 다양한 크기의 LLM 추론: 다양한 크기의 LLM을 사용하여 추론을 수행해야 합니다.
– 자동 확장: 사용자 요청에 따라 자동으로 확장되어야 합니다.
– 자동화된 LLM 배포: 평가 단계를 통과한 LLM을 자동으로 배포해야 합니다.
4. LLMOps 기능:
– 데이터셋 버전 관리, 계보, 재사용성: 지시 데이터셋에 대한 버전 관리, 계보, 재사용성을 지원해야 합니다.
– 모델 버전 관리, 계보, 재사용성: 모델에 대한 버전 관리, 계보, 재사용성을 지원해야 합니다.
– 실험 추적: 실험 결과를 추적해야 합니다.
– CT/CI/CD (지속적 훈련, 지속적 통합, 지속적 배포): CT/CI/CD를 지원해야 합니다.
– 프롬프트 및 시스템 모니터링: 프롬프트와 시스템을 모니터링해야 합니다.

LLM Twin 아키텍처

FTI 아키텍처와 비교할 때 가장 큰 변화는 “데이터 파이프라인”이 첫 번째 단계로 추가된다는 점입니다. 이런 큰 변화의 이유는 FTI 아키텍처가 데이터 파이프라인은 별도 팀에서 구축하는 것으로 가정하기 때문입니다. 소규모 팀으로 할 때는 이 부분도 직접 개발해야 합니다.

데이터 수집 파이프라인은 기사(Medium, Substack), 게시물(LinkedIn) 및 코드(GitHub)에서 개인 데이터를 크롤링하는 작업을 포함합니다. 데이터 파이프라인으로서, 소셜 미디어 플랫폼에서 데이터를 추출하고 표준화하여 데이터 웨어하우스에 로드하기 위해 추출, 로드, 변환(ETL) 패턴을 사용합니다.

이 구성 요소의 출력은 데이터 웨어하우스 역할을 하는 NoSQL DB가 됩니다. 본질적으로 비정형적인 텍스트 데이터를 처리하므로 NoSQL DB가 적합합니다. MongoDB와 같은 NoSQL DB는 데이터 웨어하우스로 분류되지 않지만, 우리 관점에서는 데이터 웨어하우스 역할을 합니다. 왜냐하면 다양한 ETL 파이프라인에서 수집한 표준화된 원시 데이터를 저장하며, 이 데이터는 ML 시스템에 쉽게 수집될 준비가 되어 있기 때문입니다.

저스틴) LLM Twin의 기술적 요구사항까지 보니, 절묘한 선택이라는 생각이 듭니다.
제시하는 기술적 요구사항이 LLM 파운데이션 모델, LLM 파인튜닝 모델, LLM 한계 보완을 위한 RAG까지 다루는 아키텍처를 필요로 하네요. 거기에 운용까지.

FTI 파이프라인 아키텍처의 다른 세 부분도 LLM Twin의 기술적 요구사항에 따라 구체화되어야 합니다. 그림 1.6을 보면서 설명해야 하는데, 책이 없는 분들도 있는 상황에서 이 부분에 대해서는 다음 기회에 설명하는 것으로 하고 넘어가겠습니다. 그래도 궁금해 하실 분들이 있을 수도 있을테니 책의 텍스트 내용 기반의 차 교수 설명을 전달하겠습니다.

======

LLM 트윈의 피처 파이프라인의 몇 가지 사용자 정의 속성은 다음과 같습니다.

세 가지 유형의 데이터(기사, 게시물, 코드)를 다르게 처리합니다.
미세 조정 및 RAG에 필요한 세 가지 주요 처리 단계(정제, 청킹, 임베딩)를 포함합니다.
디지털 데이터의 두 가지 스냅샷을 생성합니다. 하나는 정제 후(미세 조정에 사용), 다른 하나는 임베딩 후(RAG에 사용)입니다.
특수화된 피처 저장소 대신 논리적 피처 저장소를 사용합니다.

논리적 피처 저장소 부분을 조금 더 자세히 살펴보겠습니다. 모든 RAG 기반 시스템과 마찬가지로 인프라의 중심 부분 중 하나는 벡터 DB입니다. 다른 DB, 보다 구체적으로 특수화된 피처 저장소를 통합하는 대신, 벡터 DB와 시스템에 필요한 피처 저장소의 모든 속성을 확인하는 추가 로직을 사용했습니다.

벡터 DB는 훈련 데이터셋의 개념을 제공하지 않지만 NoSQL DB로 사용할 수 있습니다. 즉, ID와 컬렉션 이름을 사용하여 데이터 포인트에 액세스할 수 있습니다. 따라서 벡터 검색 로직 없이도 벡터 DB에서 새 데이터 포인트를 쉽게 쿼리할 수 있습니다. 궁극적으로 검색된 데이터를 버전 관리, 추적 및 공유 가능한 아티팩트로 래핑합니다(아티팩트에 대한 자세한 내용은 2장 참조). 현재로서는 이것이 이전에 나열된 속성으로 데이터를 래핑하고 풍부하게 하는 데 사용되는 MLOps 개념이라는 것을 알아야 합니다.

나머지 시스템은 논리적 피처 저장소에 어떻게 액세스할까요? 훈련 파이프라인은 아티팩트로 지시 데이터셋을 사용하고, 추론 파이프라인은 벡터 검색 기법을 사용하여 추가 컨텍스트에 대해 벡터 DB를 쿼리합니다.

우리의 사용 사례에서는 다음과 같은 이유로 이것으로 충분합니다.

아티팩트는 훈련과 같은 오프라인 사용 사례에 매우 적합합니다.
벡터 DB는 추론에 필요한 온라인 액세스를 위해 구축되었습니다.

하지만 향후 장에서는 세 가지 데이터 범주(기사, 게시물, 코드)를 정제, 청킹 및 임베딩하는 방법을 설명하겠습니다.

결론적으로, 원시 기사, 게시물 또는 코드 데이터 포인트를 가져와 처리하고 피처 저장소에 저장하여 훈련 및 추론 파이프라인에서 액세스할 수 있도록 합니다. 모든 복잡성을 제거하고 인터페이스에만 집중하는 것이 FTI 패턴과 완벽하게 일치합니다. 아름답지 않나요?

훈련 파이프라인

훈련 파이프라인은 피처 저장소에서 지시 데이터셋을 사용하여 LLM을 미세 조정하고 조정된 LLM 가중치를 모델 레지스트리에 저장합니다. 보다 구체적으로, 논리적 피처 저장소에 새 지시 데이터셋이 있으면 훈련 파이프라인을 트리거하고 아티팩트를 사용하여 LLM을 미세 조정합니다.

초기 단계에서는 데이터 과학 팀이 이 단계를 담당합니다. 자동 하이퍼파라미터 튜닝 또는 수동으로 작업에 가장 적합한 모델과 하이퍼파라미터를 찾기 위해 여러 실험을 실행합니다. 최상의 하이퍼파라미터 집합을 비교하고 선택하기 위해 실험 추적기를 사용하여 중요한 모든 것을 기록하고 실험 간에 비교합니다. 궁극적으로 최상의 하이퍼파라미터와 미세 조정된 LLM을 선택하고 LLM 프로덕션 후보로 제안합니다. 제안된 LLM은 모델 레지스트리에 저장됩니다. 실험 단계가 끝나면 프로세스의 수동 제약을 제거하기 위해 찾은 최상의 하이퍼파라미터를 저장하고 재사용합니다. 이제 지속적인 훈련으로 알려진 훈련 프로세스를 완전히 자동화할 수 있습니다.

미세 조정 중보다 자세한 분석을 위해 테스트 파이프라인이 트리거됩니다. 새 모델을 프로덕션에 적용하기 전에 더 엄격한 테스트 집합에 대해 평가하는 것은 최신 후보가 현재 프로덕션에 있는 것보다 더 나은지 확인하는 데 중요합니다. 이 단계를 통과하면 모델은 최종적으로 승인되고 프로덕션 추론 파이프라인에 배포됩니다. 완전히 자동화된 ML 시스템에서도 새 프로덕션 모델을 승인하기 전에 수동 단계를 수행하는 것이 좋습니다. 중요한 결과를 초래하는 중요한 작업 전에 빨간 버튼을 누르는 것과 같습니다. 따라서 이 단계에서 전문가는 테스트 구성 요소에서 생성된 보고서를 검토합니다. 모든 것이 양호하면 모델을 승인하고 자동화를 계속할 수 있습니다.

이 구성 요소의 특징은 다음과 같은 LLM 측면에 있습니다.

LLM과 무관한 파이프라인은 어떻게 구현합니까?
어떤 미세 조정 기법을 사용해야 합니까?
다양한 크기의 LLM과 데이터셋에서 미세 조정 알고리즘을 어떻게 확장합니까?
여러 실험에서 LLM 프로덕션 후보를 어떻게 선택합니까?
LLM을 프로덕션에 적용할지 여부를 결정하기 위해 어떻게 테스트합니까?

이 책의 끝까지 이러한 모든 질문에 대한 답을 알게 될 것입니다.

마지막으로 명확히 하고 싶은 한 가지는 CT입니다. 모듈식 설계를 통해 ML 오케스트레이터를 빠르게 활용하여 다양한 시스템 부분을 예약하고 트리거할 수 있습니다. 예를 들어, 데이터 수집 파이프라인을 예약하여 매주 데이터를 크롤링할 수 있습니다.

그런 다음 데이터 웨어하우스에 새 데이터가 있고 새 지시 데이터셋이 있으면 피처 파이프라인과 훈련 파이프라인을 트리거할 수 있습니다.

추론 파이프라인

추론 파이프라인은 마지막 조각입니다. 모델 레지스트리와 논리적 피처 저장소에 연결됩니다. 모델 레지스트리에서 미세 조정된 LLM을 로드하고 논리적 피처 저장소에서 RAG를 위해 벡터 DB에 액세스합니다. REST API를 통해 클라이언트 요청을 쿼리로 받습니다. 미세 조정된 LLM과 벡터 DB에 대한 액세스를 사용하여 RAG를 수행하고 쿼리에 응답합니다.

모든 클라이언트 쿼리, RAG를 사용하여 풍부해진 프롬프트 및 생성된 답변은 시스템을 분석, 디버깅 및 더 잘 이해하기 위해 프롬프트 모니터링 시스템으로 전송됩니다. 특정 요구 사항에 따라 모니터링 시스템은 수동 또는 자동으로 조치를 취하기 위해 경고를 트리거할 수 있습니다.

인터페이스 수준에서 이 구성 요소는 FTI 아키텍처를 정확하게 따르지만, 자세히 살펴보면 다음과 같은 LLM 및 RAG 시스템의 고유한 특성을 관찰할 수 있습니다.