LLM Twin 개념과 아키텍쳐 이해

LLM Twin 개념

LLM Twin 이란

복잡한 AI 모델인 LLM에 자신의 글끄기 문체, 어조, 성격을 반영한 AI 페르소나

Fine Tuning 글쓰기 스타일, 어조, 성격을 모방함.

LLM Twin 을 만들어야 하는 이유

• 브랜드 구축
• 글쓰기 과정 자동화
• 창의적인 새로운 아이디어 발굴

LLM Twin 핵심

• 어떤 데이터를 수집하는가?
• 데이터를 어떻게 전처리 하는가?
• LLM에 데이터를 어떻게 공급하는가?
• 원하는 결과를 위해 여러 프롬프트를 어떻게 연결하는가?
• 생성된 콘텐츠를 어떻게 평가하는가?

다음 단계를 모두 캡슐화 하고 자동화 하는 LLM 시스템을 구축해야 한다.

• 데이터 수집
• 데이터 전처리
• 데이터 저장, 버전 관리 및 검색
• LLM 파인튜닝
• RAG
• 콘텐츠 생성 평가

LLM Twin의 제품 기획

주요 목표: 제품을 만들기 위해 가용 지원을 활용해 우리의 아이디어를 현실적이고 실현 가능한 비즈니스 목표에 맞추는것

MVP란

최소 기능 제품(Minimun Viable Product)은 초기 사용자를 유지하고 개발 초기 단계에서 제품 컨셉의 실행 가능성을 테스트 하기위한 최소한의 기능만을 포함한 제품. 목적은 최소한의 노력으로 시장의 통찰력을 얻는것.

• 빠른 시장 진입: 신속한 제품 출시를 통해 초기 관심 유도
• 아이디어 검증: 전체 개발 투자 전에 실제 사용자를 대상으로 테스트
• 시장 조사: 타겟 고객의 반응 파악
• 위험 최소화: 시장 성공이 불확실한 제품에 투자되는 시간과 자원 감소

‘V(Viable)’ 를 지키는것이 중요함. 즉 제품이 최소한의 기능만 있더라도 미완성 기능 없이 사용자에게 완전한 경험을 제공해야함. 좋은 사용자 경험을 제공하고, 사람들이 좋아하고, 계속 사용하고 싶어하는 실행 가능한 제품.

LLM Twin MVP 정의

• 링크드인, 서브스택, 미디엄, 깃허브 프로필에서 데이터 수집
• 수집된 데이터로 오픈 소스 LLM 파인튜닝
• RAG를 위한 벡터 DB에 디지털 데이터 저장
• 다음을 바탕으로 링크드인 게시물 작성
  • 사용자 프롬프트
  • RAG 기반 기존 콘텐츠 재사용 및 참조
  • 새로운 게시물, 기사, 논문을 LLM에 추가 지식으로 활용
• 아래와 같이 LLM Twin과 상호작용 할 수 있는 간단한 웹 인터페이스 제공
  • 소셜 미디어 링크를 설정하고 데이터 수집 단계를 실행
  • 프롬프트나 외부 리소스 링크를 전송

시스템은 항상 비용 효율적이고 확장 가능하며 모듈화 되어야 한다.

특성, 학습, 추론 파이프라인 기반 ML 시스템 개발

LLM Twin 아키텍처를 구체적으로 살펴보기 전에 ML 시스템의 패턴인 특성, 학습, 추론(Feature, Training, Inference) 아키텍쳐를 이해해야 한다. FTI 파이프라인 설계의 전반적인 개요와 ML 애플리케이션을 구성하는 방법을 살펴볼것이다. 그리고 FTI 파이프라인을 LLM Twin 아키텍쳐에 어떻게 적용할 수 있는지 알아볼것이다.

ML 시스템 개발의 문제점

프로덕션 수준의 ML 시스템 구축은 단순히 모델을 학습하는 것보다 훨씬 어렵다. 엔지니어링 관점에서 모델 학습은 대부분의 경우 가장 단순한 단계이다. 다만 올바른 아키텍쳐와 하이퍼파라미터를 결정할 때는 복잡해진다. 이는 엔지니어링이 아니라 연구의 영역이다.

우리는 프로덕션에 바로 적용 가능한 아키텍쳐 설계에 집중한다. 높은 정확도로 모델을 훈련하는 것은 중요하지만, 정적인 데이터셋에서 모델을 훈련시키는 것만으로는 안정적인 배포가 어렵다. 따라서 프로덕션 배포를 위해서는 다음의 사항들을 고려해야 한다.

• 새로운 데이터의 수집, 정제, 검증
• 학습 환경과 추론 환경 설정의 차이
• 적절한 환경에서 특정 연산 및 처리
• 비용 효율적인 모델 서빙
• 데이터셋과 모델의 버전 관리, 추적, 공유
• 인프라와 모델의 모니터링
• 확장 가능한 인프라 기반 모델 배포
• 배포와 학습의 자동화

이는 ML/MLOps 엔지니어가 고려해야 하는 문제 유형들이며, 연구 팀이나 데이터 사이언스 팀은 주로 모델 학습을 담당한다.

Google Cloud 팀이 제안한 ML/MLOps 시스템의 이상적인 구성 요소: ML 코드를 중심으로… 설정, 자동화, 데이터 수집, 데이터 검증, 테스트 및 디버깅, 자원 관리, 모델 분석, 프로세스 및 메타데이터 관리, 서빙 인프라, 모니터링 등 여기서 가장 중요한 점은 ML 모델의 프로덕션 배포를 위해 이렇게 많은 요소를 고려해야 한다는것

이 모든 구성 요소를 어떻게 하나의 통합된 시스템으로 연결 할 수 있을까? ML 시스템을 명확하게 설계할 수 있는 표준 템플릿이 필요하다.

일반적인 ML 아키텍쳐의 문제점

모놀리식 배치 아키텍쳐

동일한 코드로 특성을 생성하기 때문에 학습-서빙 왜곡 문제가 발생하지 않는다. 이 패턴은 작은 데이터를 다룰 때 잘 작동한다. 파이프라인은 배치 모드로 일정에 따라 실행되며 예측 결과는 대시보드와 같은 외부 애플리케이션으로 출력된다.

모놀리식 배치 아키텍쳐: 시스템의 여러 구성요소가 하나의 단일 코드베이스나 애플리케이션으로 통합되어 있는 구조. 유지보수는 어려울 수 있지만, 구성 간 일관성을 확보하기 쉽다.

학습 서빙 왜곡: 모델 학습 중에 사용한 전처리 방법이 추론에 사용되는 방법과 일치하지 않아 모델이 동작하지 않거나 성능이 저하되는 문제

그러나 이러한 모놀리식 배치 시스템은 다음과 같은 많은 문제가 발생한다.

• 특성의 재사용성이 낮음
• 데이터 증가 시 파이스파크 또는 레이 사용을 위해 전체 코드 리팩터링 필요
• 예측 모듈을 C++, 자바, 러스트 등 더 효율적인 언어로 재작성하기 어려움
• 특성 학습, 예측 모듈을 여러 팀이 나누어서 작업하고 공유하기 어려움
• 실시간 학습을 위한 스트리밍 시스템으로 전환하기 어려움

실시간 시스템에 대한 아키텍쳐

기본적으로 예측하기 위해서는 클라이언트 요청을 통해 모든 정보와 상태를 전송해야 특성을 계산하고 모델에 전송할 수 있다.

영화 추천 모델을 생각해보자. 영화 추천 예측을 위해서는 예측 모델에 단순히 사용자 ID만 전달하는 것이 아니라 이름, 나이, 성별, 지난 시청 기록 등 사용자의 모든 정보와 상태를 전송해야 한다. 이 방식은 클라이언트가 모든 정보와 상태의 접근 방법을 완전히 이해해야 하므로 오류 가능성이 높다. 그리고 클라이언트와 모델 서비스가 밀접하게 연결되어 있어 한쪽에서 문제가 발생하면 시스템 전체에 문제가 발생할 수 있다.

실시간 시스템의 다른 예로 RAG 기반의 LLM 시스템을 생각해보자. 쿼리와 함께 문맥으로 제공되는 문서들은 시스템의 외부에서 온다. 이러한 데이터들을 벡터 DB에 저장하지 않는다면 매번 사용자 쿼리와 함께 문서를 전달하고 처리해야 한다. 그렇게 하려면 클라이언트 애플리케이션이 문서를 쿼리하고 검색하는 방법을 알고 있어야 하는데, 이는 불가능하다. 클라이언트 애플리케이션이 특성에 액세스하거나 계산하는 방법을 알아야 하는 것은 안티패턴이다.

안티패턴: ‘권장사항’과 반대되는 설계나 코드로, 처음에는 효과적처럼 보이지만 장기적으로 비효율과 유지보수 어려움을 초래하는 관행

결론적으로, 핵심은 클라이언트가 모든 정보와 상태를 전달하지 않더라도 예측에 필요한 모든 특성을 어떻게 불러올 것인가이다. 예를 들어, 앞서 언급한 영화 추천 모델의 예시에서 클라이언트 측에서는 사용자 ID 정보만을 제공한다면 추천 모델을 어떻게 돌릴 수 있을까?

ML 시스템을 위한 파이프라인

FTI 파이프라인 아키텍쳐는 특성 계산, 모델 학습, 예측/추론이라는 ML 시스템의 세가지 핵심 단계를 기반으로 한다. 이는 앞서 설몀한 아키텍쳐와 달리, 누구나 쉽게 이해하고 따라 할 수 있는 명확하고 직관적인 개념이다.

이 아키텍쳐에 따르면 모든 ML 시스템은 특성, 학습, 추론이라는 세가지 파이프라인으로 요약할 수 있다.(전통적인 소프트웨어의 DB, 비즈니스 로직, UI 계층과 유사). 이는 각 파이프라인의 범위와 인터페이스를 명확하게 한다. 또한 세 가지 구성 요소가 상호작용하는 방식을 쉽게 이해할 수 있다. 각 파이프라인은 서로 다른 프로세스나 하드웨어에서 독립적으로 실행될 수 있는 독립된 구성 요소라는 점을 먼저 이해해야 한다. 따라서 각 파이프라인은 서로 다른 기법을 적용하거나 각각 다른 팀이 개발하는 등 서로 다르게 발전시킬 수 있다.

특성 파이프라인

원시 데이터를 입력받아 처리한 후 모델 학습이나 추론에 필요한 특성과 레이블을 출력한다. 이러한 특성과 레이블은 모델에 직접 전달되지 않고, 특성 저장소에 저장된다. 특성 저장소는 특성 저장, 버전 관리, 추적 및 공유 역할을 한다. 특성 저장소에 특성을 저장하면 항상 특성의 상태를 파악할 수 있다. 이는 학습 및 추론 파이프라인으로 언제든지 특성을 쉽게 보낼 수 있다.

데이터 버전이 관리되므로 학습 및 추론 시점의 특성이 일치하는지 항상 확인할 수 있다. 따라서 학습-서빙 왜곡 문제를 해결할 수 있다.

학습 파이프라인

저장된 특성으로부터 특성과 레이블을 가져온 후, 하나 이상의 학습 모델을 생성한다. 생성된 모델은 모델 레지스트리에 저장된다. 그 역할은 특성 저장소와 비슷하며, 특성 대신 모델이 보관 대상이다. 모델 레지스트리는 모델을 저장하고, 버전을 관리 및 추적하고, 추론 파이프라인과 공유하는 역할을 한다.

최근 대부분의 모델 레지스트리는 모델의 학습 과정을 기록하는 메타데이터 저장소를 지원한다. 모델 레지스트리에서 가장 중요한 것은 모델 학습에 사용된 특성, 레이블 및 버전 기록이다. 이들로부터 모델이 어떤 데이터를 기반으로 학습되었는지 언제든지 파악할 수 있다.

추론 파이프라인

특성 저장소의 특성과 레이블, 모델 레지스트리의 학습된 모델을 입력으로 받는다. 이 두가지를 사용하면 배치 또는 실시간 예측을 쉽게 수행할 수 있다.

이 패턴은 매우 유연해 예측 결과의 처리 방식을 여러분 선택에 따라 결정할 수 있다. 배치 처리 시스템에서는 예측 결과를 DB에 저장하고, 실시간 시스템에서는 예측 결과를 요청한 클라이언트에 전달한다. 그리고 모델 배포를 쉽게 업그레이드 하거나 롤백할 수 있다. 예를 들어, 모델 v1은 특성 F1, F2, F3을 사용하고, 모델 v2는 F2, F3, F4를 사용한다는 것을 언제든지 확인할 수 있다. 따라서 모델과 특성 간의 연결을 빠르게 변경할 수 있다.

FTI 아키텍쳐의 이점

파이프라인 인터페이스:

• 특성 파이프라인: 데이터를 입력받아 특성과 레이블을 생성하고 이를 특성 저장소에 저장한다.
• 학습 파이프라인: 특성 저장소에서 특성과 레이블을 쿼리해서 가져오고, 이를 기반으로 모델을 생성해 모델 레지스트리에 저장한다.
• 추론 파이프라인: 특성 저장소에서 특성을, 모델 레지스트리에서 모델을 가져와 예측한다.

ML 시스템이 아무리 복잡해져도 이 기본 구조는 변하지 않는다.

장점:

• 세 가지 구성 요소만 존재하므로 직관적으로 이해하고 사용하기 쉽다.
• 각 구성 요소는 독립적으로 구현되므로 대규모 데이터 처리나 스트리밍 데이터와 같은 특정 요구에 맞는 기술 스택을 유연하게 적용할 수 있다.
• 세 가지 구성 요소 간 명확한 인터페이스가 있어, 필요 시 각 구성 요소를 각각 다른 팀에서 개발할 수 있다. 즉 개발의 관리와 확장이 쉬워진다.
• 모든 구성 요소를 독립적으로 배포, 확장 및 모니터링 할 수 있다.

마지막으로 FTI 아키텍처에서 유의할점은 시스템이 반드시 세가지 파이프라인으로만 구성될 필요가 없다는 것이다. 대부분의 경우 더 많고 복잡한 파이프라인을 포함한다. 예를 들어, 특성 파이프라인은 특성을 생성하는 파이프라인과 데이터를 검증하는 파이프라인으로 나누어 구성할 수 있다. 또한 학습 파이프라인은 학습과 평가를 나누어 구성할 수 있다.

FTI 파이프라인은 논리적 계층 역할을 한다. 따라서 각각이 복잡하고 여러 모듈을 포함해도 전혀 문제가 없다. 특성 저장소와 모델 레지스트리를 통해 FTI 파이프라인이 서로 상호작용할 때 항상 동일한 인터페이스를 유지하는 것이 핵심이다. 이렇게 하면 각 FTI 구성 요소는 서로의 세부 사항을 몰라도 독립적으로 개발하거나 업데이트 할 수 있고, 시스템을 중단하지 않고도 변경할 수 있다.

LLM Twin 의 시스템 아키텍쳐 설계

LLM Twin 애플리케이션의 기술적 요구 사항을 살펴보고, FTI 아키텍처를 활용한 LLM 시스템 설계로 문제를 해결하는 방법을 알아본다. 각 구성요소의 범위, 인터페이스 및 상호 연결성에 중점을 둔다.

LLM Twin 아키텍쳐의 기술적 요구 사항

데이터 측면에서는 다음과 같이 수행한다:

• 링크드인, 미디엄, 서브스택, 깃허브에서 데이터를 정해진 일정에 따라 자동으로 수집한다.
• 크롤링된 데이터를 표준화해서 데이터 웨어하우스에 저장한다.
• 원시 데이터를 정제한다.
• LLM 파인튜닝을 위한 지시문 데이터셋을 생성한다.
• 정제된 데이터를 청킹하고 임베딩 한다.
• 벡터화된 데이터를 RAG용 벡터 DB에 저장한다.

학습을 위해 다음과 같이 수행한다:

• 다양한 크기의 LLM(7B, 14B, 30B, 70B 파라미터) 파인 튜닝
• 다양한 크기의 지시문 데이터셋에 대한 파인튜닝
• 다양한 LLM 간 전환(예: 미스트랄, 라마, GPT)
• 실험 추적 및 비교
• 배포 전 프로덕션용 LLM 후보 테스트
• 새로운 지시문 데이터셋 준비 시 자동으로 학습 시작

추론 코드는 다음과 같은 속성을 갖는다:

• 클라이언트가 LLM Twin과 상호작용할 수 있는 REST API 인터페이스
• RAG를 위한 실시간 벡터 DB 액세스
• 다양한 크기의 LLM을 사용한 추론
• 사용자 요청에 따른 자동 스케일링
• 평가 단계를 통과한 LLM 의 자동 배포

LLMOps 구현을 위해 다음과 같은 기능을 지원한다.

• 지시문 데이터셋 버전 관리, 계보(lineage) 및 재사용성
• 모델 버전 관리, 계보 및 재사용성
• 실험 추적
• 지속적 학습(CT), 지속적 통합(CI), 지속적 배포(CD)
• 프롬프트 및 시스템 모니터링

FTI 파이프라인을 사용해 LLM Twin 아키텍처를 설계하는 방법

3개의 파이프라인으로 구성된 FTI 파이프라인에 데이터 파이프라인을 추가하여 4개의 핵심 구성 요소로 나눌 수 있다.

다음과 같이 팀별로 나누어 담당한다:

• 데이터 엔지니어링 팀은 데이터 파이프라인을 담당한다.
• ML 엔지니어링 팀은 FTI 파이프라인을 담당한다.