DEV Community: Jonas Kim

'머신러닝 시스템 설계' (Chip Huyen) 요약 - 파트 2

Jonas Kim — Sat, 08 Nov 2025 14:54:16 +0000

책 머신러닝 시스템 설계과 그에 대한 요약본 Summary of Designing Machine Learning Systems을 참고하였습니다.

6 - 모델 개발 및 오프라인 평가

초기 학습 피처 세트가 준비되면, 드디어 모델 개발을 시작할 수 있습니다. 피처 엔지니어링과 모델 개발은 반복적인 과정임을 명심하십시오.

이 장에서는 다음 내용을 다룹니다.

모델 선택, 개발 및 학습
- ML 모델 선택 기준
- 모델 선택의 일부로서의 앙상블(Ensembles)
- 모델 개발 중 실험 추적 및 버전 관리
- ML 모델 디버깅
- 분산 학습 모드: 데이터 병렬성, 모델 병렬성, 파이프라인 병렬성
- AutoML: 자동 하이퍼파라미터 튜닝, 자동 아키텍처 탐색, 학습된 옵티마이저
오프라인 평가: 최상의 모델을 선택하기 위해 모델 대안을 평가하는 방법
- 베이스라인: 모델을 비교할 대상이 필요합니다.
- 전반적인 ML 지표를 넘어서는 오프라인 평가 방법: 프로덕션에 보내기 전에 모델의 견고성(robustness), 공정성(fairness), 건전성(sanity) 평가하기.

모델 선택, 개발 및 학습

ML 모델 선택 기준

모델 선택 결정을 내릴 때는 여러 측면의 균형을 맞춰야 합니다. 모델 선택은 과학이라기보다는 예술에 가깝습니다. 이 장은 고려해야 할 사항에 대한 몇 가지 가이드라인과 팁을 제공합니다.

팁 1: 적재적소에 올바른 도구 사용하기

당면한 문제에 적합한 모델에만 집중하여 모델 선택의 탐색 공간을 좁히십시오. 예를 들어:

사기 탐지 시스템을 구축하려는 경우, 이것이 고전적인 이상 탐지(anomaly detection) 문제이며 이 문제 범주에 일반적으로 사용되는 모델이 KNN, isolation forest, 클러스터링, 신경망 등임을 알아야 합니다.
NLP 텍스트 분류 문제를 맡았다면, 옵션은 일반적으로 나이브 베이즈(naive-Bayes), 로지스틱 회귀, 순환 신경망(recurrent neural networks), 그리고 BERT나 GPT와 같은 트랜스포머 기반 모델입니다.

팁 2: 직면한 문제 유형에 대한 팀의 "성숙도 단계" 인지하기

주어진 문제에 대한 ML 채택에는 4가지 단계가 있습니다. 한 단계의 솔루션은 다음 단계의 솔루션을 평가하기 위한 베이스라인으로 사용될 수 있습니다.

1단계: Pre-ML (ML 이전): 이 유형의 문제를 처음 해결하는 경우입니다. 문제에 대한 첫 번째 시도는 "가장 인기 있는" 항목을 추천하거나 시간순으로 정렬하는 것과 같은 간단한 휴리스틱일 수 있습니다. ML이 아닌 솔루션만으로도 충분하다는 것을 발견할 수도 있습니다.
2단계: 가장 간단한 ML 모델: 이 문제에 대한 첫 번째 ML 모델이 될 것입니다. 팁 6: 가장 간단한 모델로 시작하기를 참조하십시오.
3단계: 간단한 모델 최적화: 목적 함수 최적화, 하이퍼파라미터 탐색, 피처 엔지니어링, 데이터 추가, 앙상블 생성 등을 통해 간단한 모델을 더 좋게 만듭니다.
4단계: 복잡한 모델: 간단한 모델의 한계에 도달했을 때 복잡한 모델로 이동합니다. 이 단계에서는 모델이 어떻게 노후화되는지(decay) (예: 재학습이 얼마나 자주 필요한지) 파악하여 재학습 파이프라인을 구축하고자 합니다.

팁 3: 학습 지표를 넘어서는 모델 속성 고려하기

정확도, F1, 로그 손실(log loss)과 같은 직접적인 학습 관련 성능 지표가 일반적으로 모델 선택에 사용됩니다. 그러나 이것들만이 고려해야 할 유일한 지표는 아닙니다.

필요한 데이터의 양, 모델의 계산 요구 사항, 학습 시간, 추론 지연 시간(inference latency), 모델 해석 가능성(interpretability)과 같은 다른 속성에도 신경 써야 합니다.

결정을 내리기 위해 선택하는 지표 세트는 문제에 따라 다릅니다. 예를 들어, 어떤 유스케이스에서는 정확도를 약간 희생하더라도 지연 시간이 매우 중요합니다.

팁 4: SOTA(State-of-the-art)의 함정 피하기

"SOTA" 성능을 가진 모델은 대개 연구에서 직접 나옵니다. 그러나 연구자들은 종종 기존의 미리 정의된 데이터셋을 사용하여 학술적인 환경에서만 모델을 평가합니다.

연구에서 SOTA 성능을 가졌다는 사실이 여러분이 구현하기에 모델이 충분히 빠르거나, 충분히 저렴하다는 것을 의미하지는 않습니다. 마찬가지로, 그것이 여러분의 데이터에서도 동일한 성능을 가질 것임을 의미하지도 않습니다.

SOTA 모델보다 훨씬 저렴하고 간단하면서도 문제를 해결할 수 있는 솔루션이 있다면, 더 간단한 솔루션을 사용하십시오.

팁 5: "고전 ML은 끝났다"는 함정 피하기

요즘 신경망이 언론의 많은 주목을 받고 있습니다. 하지만 그렇다고 해서 고전적인 ML 모델이 사라지는 것은 아닙니다. 고전적인 모델은 여전히 프로덕션 환경에서, 특히 지연 시간이나 설명 가능성(explainability)이 중요할 때, 광범위하게 사용됩니다.

또한, 고전적인 모델과 신경망 모델이 함께(in tandem) 배포되는 것을 보는 것도 드문 일이 아닙니다. 예를 들어:

신경망 모델과 결정 트리를 사용한 앙상블 구성.
k-means와 같은 고전적인 모델을 사용하여 피처를 추출하고, 이를 NN의 입력으로 사용.
BERT나 GPT-3 같은 사전 학습된 신경망을 사용하여 임베딩을 생성하고, 이를 로지스틱 회귀와 같은 고전적인 모델에 입력.

"신경망"이 아니라는 이유만으로 고전적인 모델을 무시하지 마십시오.

팁 6: 가장 간단한 모델로 시작하기

간단한 모델을 사용하면 프레이밍(framing)과 데이터를 조기에 검증할 수 있습니다.
간단한 모델은 배포하기 더 쉽습니다. 모델을 조기에 배포하면 다음과 같은 것들을 검증할 수 있습니다.
- 피처의 엔드-투-엔드(end-to-end) 동작
- 예측 파이프라인과 학습 파이프라인 간의 일관성
- 시스템의 자연 레이블 탐지 능력 (문제에 해당 사항이 있다면)
- 시스템의 데이터 분포 변화(data distribution shifts) 및 재학습 트리거 탐지 능력
간단하게 시작하여 더 복잡한 구성 요소를 천천히 추가하면 모델을 이해하고 디버깅하기가 더 쉬워집니다.
간단한 모델은 복잡한 모델과 비교할 수 있는 베이스라인이 됩니다.
간단한 모델과 노력이 적게 드는(low-effort) 모델은 다릅니다. 사전 학습된 BERT 모델을 사용하는 것은 (작업이 이미 완료되었기 때문에) 노력이 적게 들지만, 모델이 간단한 것은 아닙니다.
- 때로는 간단한 모델 대신 노력이 적게 들고 복잡한 모델로 시작하는 것이 합리적일 수 있습니다. 그러나 그런 경우에도 간단한 모델을 베이스라인으로 갖는 것은 가치가 있습니다. 왜냐하면 복잡한 모델을 개선하는 것은 매우 어렵기 때문입니다.

팁 7: 모델 선택 시 인간의 편향 피하기

선택하기 전에 다른 아키텍처들에게 비슷한 수준의 노력을 기울였는지 확인하십시오: 특정 아키텍처에 흥미를 느낀 엔지니어는 그것을 실험하는 데 더 많은 시간을 할애할 것입니다. 결과적으로, 덜 흥미를 느끼는 아키텍처에 비해 해당 아키텍처에서 더 나은 성능을 찾을 가능성이 높습니다.

팁 8: 현재의 좋은 성능 VS 미래의 좋은 성능 평가하기

지금 당장 최고의 모델이라고 해서 두 달 후에도 최고의 모델이 될 것이라는 의미는 아닙니다. 예: 지금 데이터가 거의 없다면 결정 트리가 가장 잘 작동할 수 있습니다. 두 달 후 데이터가 더 많아지면 NN이 더 잘 작동할 수 있습니다.
모델에 더 많은 데이터를 제공함에 따라 모델의 성능은 포화(saturate)되는 경향이 있습니다. 간단한 모델은 복잡한 모델보다 더 빨리 포화됩니다. 학습 곡선(learning curves)을 사용하여 모델이 가능한 한 많이 학습했는지(즉, 포화되었는지) 또는 가까운 미래에 개선될 잠재력이 여전히 있는지 평가할 수 있습니다.
- 모델이 포화되었다면, 더 복잡한 모델을 시도해 볼 때일 수 있습니다.

일부 팀은 챔피언-챌린저(champion-challenger) 방식으로 간단한 모델(현재 좋은 성능)과 복잡한 모델(미래에 좋은 성능)을 배포합니다. 더 많은 데이터가 확보됨에 따라 복잡한 모델을 계속 학습시키고, 복잡한 모델의 성능이 더 좋아지면 교체합니다.
모델을 선택할 때, 가까운 미래의 개선 잠재력과 그러한 개선을 달성하기 위한 난이도를 의사 결정에 고려할 수 있습니다.

팁 9: 트레이드오프(Trade-offs) 평가하기

모델 선택은 트레이드오프로 가득 차 있습니다. 특정 유스케이스에 무엇이 중요한지 이해하면 정보에 입각한 결정을 내리는 데 도움이 됩니다. 몇 가지 일반적인 트레이드오프는 다음과 같습니다.

False positives(FP) VS false negatives(FN) 트레이드오프. 예: 모델이 위험한 질병을 진단하는 경우, false negatives를 최소화하는 모델을 선호할 수 있습니다.
계산 집약도 VS 성능 트레이드오프: 더 크고 복잡한 모델이 더 정확할 수 있지만, 실행하는 데 더 강력한 기계와 특수 하드웨어가 필요할 수 있습니다.
지연 시간 VS 성능 트레이드오프: 더 크고 복잡한 모델이 더 정확할 수 있지만, 추론을 생성하는 속도가 더 느릴 것입니다. 일부 유스케이스에는 엄격한 지연 시간 요구 사항이 있습니다.
해석 가능성 VS 성능 트레이드오프: 모델 복잡성이 증가함에 따라 성능은 향상되는 경향이 있지만 모델의 해석 가능성은 감소합니다.

팁 10: 모델의 가정(Assumptions) 이해하기

모든 ML 모델에는 일부 내재된(baked-in) 가정이 있습니다. 이러한 가정을 이해하고 데이터가 이러한 가정을 충족하는지 조사하면 모델 선택에 지침이 될 수 있습니다.

모델에 의해 만들어지는 몇 가지 일반적인 가정의 샘플:

예측 가정: 모델은 X로부터 Y를 예측하는 것이 실제로 가능하다고 가정합니다. 때때로 데이터는 단지 무작위이며 학습할 패턴이 없습니다.
독립적이고 동일하게 분포된(Independent and Identically distributed, IID): 신경망을 포함한 많은 모델이 모든 예제가 IID라고 가정합니다.
평활성(Smoothness): 모든 지도 ML 모델은 입력 X를 추론 Y로 변환하기 위해 학습될 수 있는 평활(smooth) 함수가 있다고 가정합니다. 즉, 매우 유사한 입력 X와 X'는 비례적으로 가까운 출력을 생성해야 합니다.
다루기 쉬움(Tractability): X를 입력, Z를 X의 잠재 표현(latent representation)이라고 할 때, 생성 모델(Generative models)은 P(Z|X)를 계산하는 것이 다루기 쉽다고 가정합니다.
경계(Boundaries): 선형(linear) 방법은 결정 경계(decision boundaries)가 선형이라고 가정합니다. 커널(Kernel) 방법은 결정 경계가 사용된 커널의 모양을 따른다고 가정합니다.
조건부 독립(Conditional independence): 나이브 베이즈 분류기 기반 모델은 클래스가 주어졌을 때 피처 값들이 서로 독립이라고 가정합니다.
정규 분포: 많은 모델이 데이터가 정규 분포를 따른다고 가정합니다.

앙상블 (Ensembles)

앙상블을 사용하는 것은 단일 모델에 비해 지속적으로 성능 향상을 보여준 방법입니다. 앙상블에서는 여러 기본 학습기(base learners)가 학습되고 각각 예측을 출력합니다. 최종 예측은 다수결(majority vote)과 같은 휴리스틱을 사용하여 도출됩니다.

2021년 Kaggle 대회의 22개 우승 솔루션 중 20개가 앙상블을 사용했습니다. SQuAD 2.0의 상위 20개 솔루션은 앙상블입니다.

앙상블 방법은 배포 및 유지 관리가 더 어렵기 때문에 프로덕션 환경에서는 덜 선호됩니다. 그러나 작은 성능 향상이 막대한 재정적 이득으로 이어질 수 있는 작업에서는 여전히 일반적입니다.

앙상블을 만들 때, 기본 학습기 간의 상관관계가 적을수록 앙상블이 더 좋아집니다. 따라서, 앙상블을 위해 매우 다른 유형의 모델을 선택하는 것이 일반적입니다. 예를 들어, 하나의 트랜스포머 모델, 하나의 순환 신경망, 하나의 그래디언트 부스티드 트리(gradient-boosted tree)로 구성된 앙상블을 만들 수 있습니다.

투표에서 동점(tie)을 피하기 위해 홀수 개의 기본 학습기를 사용하는 것도 일반적입니다.

앙상블을 만드는 방법에는 배깅(bagging), 부스팅(boosting), 스태킹(stacking)의 3가지가 있습니다. 이러한 기술들은 결합될 수도 있습니다.

MLWave(전설적인 Kaggle 팀)의 앙상블 가이드에서 앙상블을 만드는 방법에 대한 훌륭한 조언을 찾을 수 있습니다.

배깅 (Bagging)

배깅은 많은 이점을 가집니다. 학습 안정성 향상, 정확도 향상, 분산(variance) 감소, 과적합 방지.
직관: 복원 추출(sample with replacement)을 사용하여 다른 데이터셋을 만듭니다. 각 데이터셋에서 분류 또는 회귀 모델을 학습시킵니다.
- 복원 추출은 각 부트스트랩(bootstrap)이 서로 독립적으로 생성되도록 보장합니다 (즉, 기본 학습기 간의 상관관계가 적어짐).
사용 시기: 불안정한 방법(예: NN, 분류 및 회귀 트리, 선형 회귀)의 안정성을 향상시킬 때.
- k-최근접 이웃(k-nearest neighbours)과 같은 안정적인 방법에서는 성능을 약간 저하시킬 수 있습니다.

부스팅 (Boosting)

직관:
- 1. 원본 데이터셋에서 첫 번째 약한 분류기(weak classifier)를 학습시키는 것으로 시작합니다.
- 2. 샘플들은 첫 번째 모델이 얼마나 잘 분류했는지에 따라 가중치가 재조정(re-weighted)됩니다. 잘못 분류된 예제는 더 높은 가중치를 갖습니다.
- 3. 가중치가 재조정된 샘플로 두 번째 분류기를 학습시킵니다.
- 4. 분류기 2의 출력에 따라 샘플 가중치가 다시 재조정됩니다.
- 5. 분류기 2에서 재조정된 가중치를 사용하여 세 번째 분류기를 학습시킵니다.
- 6. 필요한 만큼 반복합니다.
- 7. 기존의 모든 분류기들의 가중치 조합(weighted combination)으로 최종 강력한 분류기(strong classifier)를 형성합니다. 학습 오류가 작은 분류기가 더 높은 가중치를 갖습니다.
부스팅 알고리즘:
- GBM (Gradient Boosted Machines)
- XGBoost: 많은 ML 대회에서 선택되는 알고리즘.
- LightGBM: 분산 병렬 학습을 허용하는 XGBoost의 대안 (대규모 데이터셋에 좋음).

스태킹 (Stacking)

직관: 서로 다른 기본 학습기(일반적으로 서로 매우 다른 성격의)를 학습시킵니다. 최종 예측을 생성하기 위해, 기본 학습기들의 예측을 어떻게 결합할지 학습하는 메타 학습기(meta-learner)를 사용합니다.

메타 학습기는 다수결(분류) 또는 평균(회귀)과 같은 간단한 휴리스틱일 수 있습니다.
또는 로지스틱 회귀(분류)나 선형 회귀 모델(회귀)과 같은 또 다른 (일반적으로 더 간단한) 모델일 수도 있습니다.
#todo : 메타 학습기가 각 기본 학습기가 어떤 유형의 샘플에 능숙한지 학습할 수 있도록 피처에 대한 접근 권한도 부여하는 것이 일반적인가?

실험 추적 및 버전 관리

실험을 구성하는 설정 파라미터와 해당 실험이 생성하는 산출물(artefacts)을 추적하는 것은 모델 선택을 수행하고 실험 파라미터(데이터, 파라미터, 모델) 변경이 출력 모델의 성능에 어떤 영향을 미치는지 이해하는 데 핵심입니다.

실험 추적(Experiment tracking)과 버전 관리(versioning)는 서로 밀접하게 연관되어 있으며 보통 하나의 개념처럼 이야기되는 2가지 다른 개념입니다.

실험 추적: 실험의 진행 상황과 결과를 추적하는 프로세스.
버전 관리: 실험을 재현(replicate)할 수 있도록 모든 설정 파라미터를 로깅하는 프로세스.
원래 실험 추적을 위해 만들어졌던 많은 도구(예: MLFlow, Weights & Biases)가 이제 버전 관리를 포함하고 있으며, 그 반대(예: DVC)도 마찬가지입니다.

적극적인 실험 추적 및 버전 관리는 재현성(reproducibility)에 도움이 되지만, 이를 보장하지는 않는다(ENSURE IT)는 점을 명심하십시오.

실험 추적

실험 추적을 통해 ML 엔지니어는 학습 과정을 효과적으로 세심하게 관리할 수 있습니다; 이것은 학습의 매우 큰 부분입니다.
추적할 수 있는 몇 가지 예시는 다음과 같습니다.
- 학습 및 각 평가 분할(eval splits)의 손실 곡선(Loss curve).
- 테스트 분할을 제외한 모든 분할에서 관심 있는 모델 성능 지표: 정확도, F1, 퍼플렉시티(perplexity).
- <샘플, 정답, 예측> 로그. 건전성 확인(sanity check)을 위해 수동 분석이 필요한 경우 유용합니다.
- 초당 스텝 수로 평가한 모델 속도. 텍스트 기반 모델을 다루는 경우, 초당 처리된 토큰 수.
- 시스템 성능 지표: 메모리 사용량, CPU/GPU 사용량. 병목 현상을 식별하고 자원 낭비를 피하는 데 도움이 됩니다.
- 모델 성능에 영향을 미치는 모든 파라미터 및 하이퍼파라미터의 시간에 따른 값. 예: 학습률(learning rate), 그래디언트 놈(gradient norms) (전역 및 레이어별), 가중치 놈(weight norm).
이론적으로는, 가능한 모든 것을 추적하는 것이 나쁜 생각은 아닙니다. 실제로는, 모든 것을 추적하면 노이즈에 압도당하고 주의가 산만해질 것입니다.

버전 관리

ML 시스템은 부분적으로 코드이고, 부분적으로 데이터입니다. 둘 다 버전 관리해야 합니다.
데이터 버전 관리는 다음과 같은 이유로 어려운 부분입니다.
- 데이터는 코드보다 훨씬 크기 때문에 코드 버전 관리 도구를 재사용할 수 없습니다. 이전 버전으로 롤백(roll back)하기 위해 데이터셋을 여러 번 복제하는 것은 실현 불가능합니다.
- 데이터 버전 관리 시 정확히 무엇이 diff를 구성하는지에 대해 여전히 혼란이 있습니다.
  - 모든 변경 사항을 추적해야 하는가, 아니면 체크섬(checksum)만 추적해야 하는가?
  - 2021년 기준, DVC와 같은 도구는 전체 디렉토리의 체크섬만 등록합니다.
- 버전 관리되는 데이터에서 병합 충돌(merge conflicts)이 무엇인지 명확하지 않습니다.
- GDPR 또는 유사한 규정의 적용을 받는 사용자 데이터를 사용하는 경우, 데이터 삭제 요청을 준수하는 것이 불가능해집니다.

ML 모델 디버깅

ML 모델 디버깅은 여러 가지 이유로 어렵고 좌절스럽습니다.

ML 모델은 조용히 실패합니다(fail silently). 예측은 계속하지만 예측이 틀립니다. 때때로 모델에 버그가 있다는 것조차 모릅니다.
버그가 수정되었는지 확인하는 것은 답답할 정도로 느립니다. 모델을 재학습한 다음 새 모델로 샘플을 재평가해야 할 수도 있습니다. 때로는 프로덕션에 배포해야만 알 수 있습니다.
ML 모델에는 데이터, 레이블, 피처, ML 알고리즘, 코드, 인프라 등 여러 팀에서 발생할 수 있는 많은 실패 지점(points of failure)이 있습니다.

불행히도, ML 디버깅에 대한 과학적인 접근 방식은 없습니다. 그러나 일반적으로 좋은 관행으로 간주되는 몇 가지 검증된(tried and true) 기술이 있습니다.

단순하게 시작하여 점진적으로 구성 요소 추가: 이렇게 함으로써 현재 하고 있는 일이 성능에 도움이 되는지 해가 되는지 볼 수 있습니다. 이는 또한 예상되는 동작에 대한 직관을 얻는 데 도움이 됩니다.
- 오픈 소스 SOTA 구현을 복제하여 자체 데이터를 연결하는 것은 안티패턴(anti-pattern)입니다. 그것이 작동할 가능성은 매우 낮으며, 작동하지 않을 경우 디버깅하기가 매우 어렵습니다.
단일 배치에 과적합(Overfit)시키기: 모델의 간단한 구현을 마친 후, 작은 데이터 배치에 과적합시킨 다음 동일한 데이터에 대해 평가를 실행하여 가능한 가장 높은 정확도(또는 가장 낮은 손실)를 얻는지 확인합니다. 작은 과적합된 배치에서 매우 높은 정확도를 얻을 수 없다면, 무언가 잘못되었을 수 있습니다.
무작위 시드(random seed) 설정: ML 모델은 무작위성을 사용하는 곳이 많습니다. 무작위성은 성능 변화가 무작위성 때문인지 변경 사항 때문인지 알 수 없게 하여 실험을 비교하고 재현하기 어렵게 만듭니다. 여러 실험에서 일관된 무작위 시드를 사용하면 비교 가능성을 유지하는 데 도움이 됩니다.
더 많은 기술은 Adrej Karpathy의 포스트 "신경망 학습 레시피(A Recipe for Training Neural Networks)"에서 볼 수 있습니다.

분산 학습 (Distributed Training)

메모리에 맞지 않는 데이터로 모델을 학습시키는 것은 흔한 일입니다. 이런 일이 발생하면, 전처리(예: 정규화), 셔플링, 배치 구성 및 학습을 위한 알고리즘이 여러 머신에서 병렬로 수행되어야 합니다.

ML 엔지니어로서, 분산 학습과 ML 확장에 대한 경험을 쌓는 것은 어렵습니다. 왜냐하면 대량의 리소스에 접근해야 하기 때문입니다.

다음으로 몇 가지 분산 학습 모드를 다루겠습니다.

데이터 병렬성 (Data parallelism)

직관: 데이터를 여러 머신에 분할하고, 모든 머신에서 모델을 학습시킨 다음, 그래디언트(gradients)를 축적합니다.

이것은 가장 일반적인 병렬화 방법이지만 몇 가지 문제가 있습니다.

문제 1: 동기식(sync) vs 비동기식(async) 그래디언트 하강

데이터가 매우 클 때 (예: 1,000억 개 샘플), 전체 학습 세트를 여러 머신(예: 10대 머신, 머신당 100억 개 샘플)으로 분할하더라도 전체 학습 세트를 처리하고 그래디언트를 축적할 수 없습니다. 이는 여전히 실현 불가능합니다.

병렬이 아닌 경우와 마찬가지로, 미니배치(mini-batches)를 사용해야 합니다. 병렬이 아닌 경우와 달리, 병렬 학습에서는 미니배치를 사용 가능한 머신 수만큼 더 분할하고 각 머신이 미니-미니배치(mini-mini-batch)를 처리하게 합니다.

문제는 머신이 미니-미니배치 처리를 마친 후 가중치와 편향을 업데이트하는 방법을 결정해야 할 때 발생합니다.

동기식 확률적 경사 하강법 (sync-SGD): 이 접근 방식은 모든 머신이 각자의 미니-미니배치 처리를 마칠 때까지 기다린 다음 그래디언트를 축적합니다. 메인 노드(main node)가 그래디언트를 축적하고 가중치를 업데이트합니다. 모든 보조 노드(assisting nodes)는 메인 노드가 완료되면 새 모델 가중치를 다운로드하고 다음 미니배치 처리를 시작합니다.
- 장점: 더 빨리 수렴합니다.
- 단점: 느린 보조 머신 하나가 전체 시스템을 느리게 만듭니다. 머신이 많을수록 하나가 느릴 가능성이 커집니다. 이 문제를 해결하는 알고리즘들이 있습니다.
비동기식 확률적 경사 하강법 (async-SGD): 머신들은 미니-미니배치 처리를 마치는 즉시 메인 노드로 그래디언트를 보냅니다. 메인 노드는 다른 보조 노드를 기다리지 않고 즉시 가중치를 업데이트합니다. 보조 노드들은 업데이트된 버전의 모델을 즉시 다운로드하고 다음 미니-미니배치 작업을 시작합니다.
- 장점: 느린 노드로 인한 시스템 속도 저하가 없습니다.
- 단점: 이론적으로는 그래디언트 부실(gradient staleness) 때문에 수렴하는 데 더 많은 스텝이 필요합니다.
  - 실제로는, 그래디언트 업데이트가 희소(sparse)하다면, sync-SGD와 async-SGD 간의 수렴 속도에 거의 차이가 없습니다.

문제 2: 많은 수의 보조 노드 = 큰 배치 크기

만약 100개의 보조 GPU 노드에 접근할 수 있고 각 노드가 10,000개의 샘플로 구성된 미니-미니배치를 처리할 수 있다면, 미니배치 크기는 1백만이 될 것입니다. 더 큰 미니배치는 일반적으로 모델을 더 빨리 학습시킵니다. 왜냐하면 GPU는 샘플 수에 그다지 민감하지 않기 때문입니다 (즉, 샘플 수를 2배로 늘려도 계산 시간이 2배가 되지는 않습니다).

이론상 일반적인 경험 법칙은 미니배치 크기를 2배로 늘리면 학습률도 약 2배로 늘려야 한다는 것입니다. 하지만, 실제로는:

학습률을 너무 많이 높이면 수렴이 불안정해질 수 있습니다.
배치 크기를 특정 지점 이상으로 늘리면 효율이 체감(diminishing returns)됩니다.
학습률과 에포크(epoch) 수를 일정하게 유지하면서 배치 크기를 늘리면 정확도가 낮아질 수 있습니다.
배치 크기와 학습률 하이퍼파라미터 선택은 과학이라기보다는 예술입니다. Weights and biases에는 학습률 대 배치 크기의 직관에 대해 설명하는 훌륭한 비디오가 있습니다.

많은 수의 GPU에 접근할 수 있다는 이유만으로 미니배치 크기를 간과하거나 거대한 배치 크기를 사용하는 함정에 빠지지 마십시오.

모델 병렬성 (Model parallelism)

모델 병렬성에서는, 모델의 서로 다른 구성 요소가 서로 다른 머신에서 학습됩니다. 모델 병렬성과 데이터 병렬성은 상호 배타적이지 않습니다. 둘 다 동시에 수행될 수 있지만, 이러한 구성을 설정하려면 상당한 엔지니어링 노력이 필요합니다.

아래 그림은 하이브리드 데이터 및 모델 병렬성 구성을 보여줍니다. 이 구성에서 머신 2와 4는 첫 번째 단계(머신 1과 3)가 완료될 때까지 기다립니다. 유휴(Idle) 머신 시간은 나쁩니다. 파이프라인 병렬성은 이러한 유휴 시간을 줄이는 데 사용될 수 있습니다.

파이프라인 병렬성 (Pipeline parallelism)

이것에는 여러 변형이 있지만, 기본 아이디어는 모델을 여러 머신에서 실행되는 직렬 구성 요소로 분할한 다음 미니-미니배치의 입력을 시차를 두고(stagger) 공급하는 것입니다. 아래 그림이 이 구성을 보여줍니다. 파이프라인 병렬성이 대기 시간을 완전히 제거하지는 않지만, 줄여줍니다.

Auto ML

Auto-ML은 ML 엔지니어와 대학원생들이 하던 일부 반복적이거나 기계적인 작업을 해결하기 위해 더 많은 컴퓨팅 파워를 사용한다는 포괄적인 아이디어입니다.

소프트 Auto ML: 하이퍼파라미터 튜닝

하이퍼파라미터 튜닝은 주어진 모델에 대해 탐색 공간 내에서 최적의 하이퍼파라미터 세트를 찾는 것을 의미합니다.
2022년 기준, 이것은 Auto-ML의 가장 인기 있는 형태입니다.
주어진 모델과 데이터셋에 대해 하이퍼파라미터를 잘 튜닝하는 것은 성능에 극적인 영향을 미칠 수 있습니다.
- 잘 튜닝된 파라미터를 가진 약한 모델이 더 강한 모델보다 성능이 뛰어날 수 있다는 것도 보여졌습니다.
중요성에도 불구하고, 많은 기업이 여전히 하이퍼파라미터 튜닝에 대한 엄격하고 체계적인 접근 방식을 무시하고 수동의, 직관 기반 방법을 사용합니다.
많은 인기 있는 ML 라이브러리에는 자동 하이퍼파라미터 튜닝을 위한 내장 유틸리티가 있거나 서드파티 유틸리티가 있습니다. 예를 들어 sklearn에는 auto-sklearn, TensorFlow에는 Keras Tune, Ray Tune이 있습니다.
자동 하이퍼파라미터 튜닝의 인기 있는 방법으로는 랜덤 서치(random search), 그리드 서치(grid search), 베이지안 최적화(bayesian optimisation)가 있습니다.
모델 성능에 더 큰 영향을 미치는 하이퍼파라미터는 더 신중하게 튜닝해야 합니다.
하이퍼파라미터를 튜닝하는 데 테스트 분할(test split)을 절대 사용하지 마십시오. 검증 세트(validation set)를 기반으로 파라미터를 선택하고, 최종 성능을 평가할 때만 테스트 세트를 사용하십시오.
하이퍼파라미터 튜닝에 대한 심층 가이드는 Auto ML: Methods, Systems, Challenges 책의 1장에서 찾을 수 있습니다.

하드 Auto ML: 아키텍처 탐색 및 학습된 옵티마이저

아키텍처 탐색(Architecture search)과 학습된 옵티마이저(learned optimizers)는 두 가지 독립적인 AutoML 작업입니다 (이론적으로는 함께 사용될 수 있음). 2022년 기준, 이들은 아직 "연구" 단계에 있으며 프로덕션 환경의 기업에서 널리 사용되지는 않습니다.
두 작업 중 하나의 초기 계산 비용(up-front computation cost)이 너무 높아서 전 세계적으로 소수의 기업만이 이 분야의 연구를 추구할 여력이 있습니다.
일반 ML 엔지니어로서 AutoML의 진행 상황을 인지하는 것이 중요합니다. 왜냐하면:
- 아키텍처 탐색 연구에서 나온 아키텍처는 많은 실제 작업에 바로(off-the-shelf) 사용할 수 있을 만큼 충분히 일반적일 수 있으며, 여러분의 문제에 적용할 수 있습니다.
  - 아키텍처 탐색 연구는 더 높은 성능을 보이거나, 학습 및/또는 추론이 더 빠른 아키텍처 등을 생산해냈습니다. 예를 들어, Google AutoML 팀의 EfficientNets는 10배의 효율성으로 SOTA 정확도를 능가합니다.
- 학습된 옵티마이저 연구에서 나온 옵티마이저는 추가적인 사전 학습 없이(즉, 일종의 전이 학습(transfer learning) 형태가 될 수 있음) 다양한 작업에 적용할 수 있을 만큼 충분히 일반적일 수 있습니다. 이는 학습을 더 빠르고 안정적으로 만들 수 있습니다.
- 이러한 연구 분야의 결과물은 기존 아키텍처와 옵티마이저로는 이전에 불가능했던 많은 실제 문제를 해결하는 것을 가능하게 만들 수 있습니다.

아키텍처 탐색 (일명 Neural Architecture Search, NAS)

직관: 알고리즘을 사용하여 신경망의 아키텍처 파라미터(예: 레이어 크기, 스킵 레이어(skip layer) 추가 여부)를 체계적으로 변경하여 문제에 대한 최적의 아키텍처를 찾습니다.

NAS 문제에는 세 가지 구성 요소가 있습니다.

탐색 공간(A search space): 알고리즘이 변경할 수 있는 아키텍처 구성 요소(building blocks), 각각의 제약 조건, 그리고 이를 결합하는 규칙. 구성 요소 세트는 기본 아키텍처(예: CNN, 트랜스포머, FFNN, RNN 등)에 따라 다릅니다.
성능 추정 전략(A performance estimation strategy): 탐색 공간이 클 때, 아키텍처의 성능을 평가하기 위해 각 아키텍처 후보를 수렴할 때까지 학습시키는 것은 엄청나게 비용이 많이 들 수 있습니다. NAS 알고리즘이 결정을 내릴 수 있도록 저렴하게 성능을 추정하는 전략이 필요합니다.
탐색 전략(A search strategy): 탐색 공간을 탐색하는 전략입니다. 일반적인 접근 방식은 강화 학습(성능을 향상시키는 선택에 대해 알고리즘에 보상)과 진화 알고리즘(아키텍처에 돌연변이 추가 → 가장 성능이 좋은 것 선택 → 그것들에 돌연변이 추가)입니다.

학습된 옵티마이저 (Learned optimizers)

경사 하강법 기반 학습 작업은 그래디언트 업데이트가 주어졌을 때 모델의 가중치를 업데이트하는 방법을 지정하는 옵티마이저를 내부적으로(under the hood) 사용합니다. 인기 있는 옵티마이저로는 Adam, Momentum, SGD가 있습니다.

이러한 옵티마이저들은 함수와 일부 옵티마이저 하이퍼파라미터(학습률 등)의 형태를 띱니다. 함수 자체는 사람에 의해 정의되었습니다; 만약 그 함수를 NN으로 대체하고 하이퍼파라미터를 학습할 수 있다면 어떨까요?

이것이 바로 학습된 옵티마이저 연구 분야가 하려는 일입니다. 여러 학습 작업을 "학습 데이터"로 사용하여 NN을 메타-학습(meta-train)시켜, 여러 학습 작업과 여러 NN 아키텍처에 "바로(off-the-shelf)" 사용할 수 있는 일반화 가능한 신경망 기반 옵티마이저 함수를 만들려고 합니다.

이 작업을 수행하는 계산 비용은 막대합니다. 메타-학습 작업을 위한 단일 샘플은 <NIST 데이터셋, 5개 합성곱 레이어를 가진 CNN, 배치 크기 32, 10K 스텝>과 같을 수 있습니다.
일부 옵티마이저는 스스로를 더 학습시킬 수 있는 속성을 가지고 있습니다.
Google의 "더 효과적인 학습된 옵티마이저 학습시키기, 그리고 그것들을 사용하여 스스로를 학습시키기(Training more effective learned optimizers, and using them to train themselves)" 논문에 대한 이 비디오는 이 직관을 매우 잘 설명합니다. (직관 부분만 보려면 15분까지 시청하세요.)

모델 오프라인 평가

이 섹션에서는 배포할 최상의 모델을 선택하기 위해 모델을 평가하는 방법을 다룹니다. 이 섹션은 두 가지 주제를 다룹니다.

베이스라인: 비교할 대상이 필요합니다.
전반적인 ML 지표를 넘어서는 평가 방법.

참고:

ML 기반 지표 외에도, 비즈니스 팀과 협력하여 회사의 비즈니스와 더 관련 있는 지표를 개발할 수 있습니다.
이상적으로는 개발 환경과 프로덕션 환경에서의 평가 방법이 동일하기를 원합니다.
- 운이 좋다면, 프로덕션에서 자연 레이블을 사용하여 성능을 측정할 수 있을 것입니다.
- 프로덕션에서는 레이블에 접근할 수 없을 수도 있기 때문에 개발 환경과 프로덕션 환경의 평가를 일치시키는 것이 때때로 불가능합니다. 이러한 경우에는 프로덕션에서 광범위한 모니터링을 사용해야 합니다 (8장 참조).

베이스라인 (Baselines)

평가 지표 자체는 큰 의미가 없습니다. 비교 대상인 베이스라인을 아는 것이 필수적입니다. 사용하는 베이스라인은 유스케이스에 따라 달라집니다. 그러나 이 섹션에서는 일반적으로 사용되고 유스케이스 전반에 걸쳐 일반화될 수 있는 몇 가지를 다룹니다.

무작위 베이스라인 (Random baseline)

특정 무작위 분포를 따르는 예측을 생성하는 베이스라인 모델을 생성합니다. 균등 분포(uniform distribution)일 수도 있고, 작업의 레이블 분포를 따를 수도 있습니다.

간단한 휴리스틱 (Simple heuristic)

간단한 휴리스틱을 사용하여 예측하는 베이스라인 모델을 생성하고 그 성능을 측정합니다. 휴리스틱의 예로는: 가장 인기 있는 것 예측, 투표 수로 추천하기가 있습니다.

제로 룰 베이스라인 (Zero rule baseline)

항상 가장 흔한 클래스를 예측하는 베이스라인 모델. 만약 이 베이스라인이 70%의 정확도를 낸다면, 여러분의 모델은 추가된 복잡성을 정당화하기 위해 이보다 훨씬 더 나은 성능을 보여야 합니다.

인간 베이스라인 (Human baseline)

인간의 성능/정확도를 베이스라인으로 사용합니다. 모델이 인간에 비해 작업을 얼마나 더 잘/못 하는지 아는 것은 종종 유용합니다.

기존 솔루션 베이스라인 (Existing solution baseline)

if/else 문으로 가득 찬 알고리즘, 이전 모델 또는 벤더가 제공한 모델이 이미 있다면, 그것을 베이스라인으로 사용하십시오. 모델을 선택하기 위해 반드시 베이스라인보다 더 나은 성능을 낼 필요는 없습니다. 때때로 모델의 정확도가 약간 낮더라도 훨씬 저렴하다면, 추진할 가치가 있습니다.

전반적인 ML 지표를 넘어서는 평가 방법

사람들은 F1이나 정확도와 같은 전반적인 성능 지표에 집착하는 경향이 있습니다. 그러나 모델 평가 및 선택에는 전반적인 ML 지표보다 훨씬 더 많은 것이 있습니다. 프로덕션 모델의 경우, 모델이 견고하고(robust), 공정하며(fair), 보정(calibrated)되어 있고, 전반적으로 말이 되는지(makes sense) 확인해야 합니다.

섭동 테스트(perturbation tests)를 통한 견고성 평가

이상적으로는 프로덕션 데이터와 동일한 분포 및 노이즈 수준을 가진 데이터로 모델을 학습시켜야 합니다. 그러나 이것이 항상 가능한 것은 아닙니다.
노이즈가 있는 프로덕션 데이터와 분포 변화 때문에, 노이즈 없는 데이터에서 측정된 최고의 모델이 노이즈가 있는 프로덕션 데이터에 대해 반드시 최고의 모델은 아닙니다.
모델이 노이즈가 있는 데이터에 대해 얼마나 잘 작동할지 파악하려면, 테스트 세트의 샘플에 약간의 노이즈(섭동, perturbations)를 추가하고 그것이 모델 성능에 극적인 영향을 미치는지 확인하십시오.
모델이 노이즈에 더 민감할수록 유지 관리가 더 어려워지고 적대적 공격(adversarial attacks)에 더 취약해집니다.
모델이 노이즈에 너무 민감하다면, 학습 중에 이를 줄이는 방법에 대한 준지도 학습 및 데이터 증강 노트를 확인하십시오.

불변성 테스트(invariance tests)를 통한 공정성 평가

입력의 특정 변경 사항이 예측의 변경으로 이어져서는 안 됩니다. 예를 들어, 샘플의 인종이나 성별 변경이 누군가의 신용 가치(credit worthiness)에 영향을 미쳐서는 안 됩니다.
불변성 테스트 중에, ML 엔지니어는 테스트 샘플의 민감한 정보를 변경하고 예측이 바뀌는지 확인합니다.
이를 근본적으로 제거하는 데 도움이 되도록, 민감한 정보 피처를 모델 학습에서 완전히 제외해야 합니다.

방향성 기대 테스트(directional expectation tests)를 통한 건전성 확인

데이터의 특정 변경 사항은 예측 가능한 방식으로 예측을 변경해야 합니다. 예를 들어, 주택 면적이 증가하면 부동산의 예측 가치도 증가해야 합니다.
방향성 기대 테스트는 출력이 예상된 방식으로 변경되도록 해야 하는 피처를 변경하고 모델이 예상대로 작동하는지 평가합니다.
방향성 변경이 출력을 반대 방향으로 작동하게 만든다면, 모델이 잘못된 것을 학습하고 있을 수 있습니다.

보정(calibration) 평가

만약 모델이 100개의 이미지에 대해 "이것이 고양이일 확률 60%"라고 레이블을 붙인다면, 그 100개 이미지 중 60개는 실제로 고양이여야 합니다. 만약 그렇다면, 우리는 그 모델이 "잘 보정되었다(well calibrated)"고 말합니다. 반대로, 100개 중 90개의 이미지가 고양이로 판명된다면, 그 모델은 보정되지 않은(uncalibrated) 것입니다.
보정은 0에서 1 사이의 모델 출력을 확률로 자신 있게 다룰 수 있는 핵심입니다. 모델이 보정되면, 출력 확률이 실제 확률과 일치하므로, 기댓값과 같은 추가적인 확률 기반 계산을 자신 있게 수행할 수 있습니다.
보정은 또한 더 나은 모델 모듈성(modularity)을 가능하게 합니다. 모델 모듈성이란 한 모델의 출력을 다운스트림 모델의 피처로 사용하는 것입니다. 만약 업스트림 모델이 변경되었는데 그 모델이 보정되지 않았다면, 모든 다운스트림 모델을 재학습해야 할 수도 있습니다.
모델 보정은 종종 ML 엔지니어들에 의해 간과됩니다.
이 유튜브 비디오는 보정이 무엇인지 간단하고 직관적으로 설명합니다.
회귀 모델도 보정 테스트가 필요합니다.
모델 보정은 종종 모델 이후의 후처리(post-processing) 레이어로 수행됩니다. 이를 위한 몇 가지 리소스는 다음과 같습니다.
- sklearn.calibration.CalibratedClassifierCV의 Platt Scaling
- Temperature scaling을 이용한 신경망 보정
- Google의 보정에 관한 블로그 포스트

신뢰도 측정(confidence measurement)을 통한 건전성 확인

일부 유스케이스의 경우, 모델이 무언가에 대해 확신이 없다면 사용자가 신뢰를 잃을 수 있으므로 추천을 보여주지 않는 것이 나을 수 있습니다.
신뢰도 측정은 다음을 식별하려고 시도합니다.
- 유스케이스에 대한 확실성(certainty)을 어떻게 측정합니까?
- 예측에 대해 확신할 수 있는 임계값(threshold)은 얼마입니까?
- 임계값 미만의 예측으로 무엇을 합니까? (예: 폐기, 사람 개입(loop in humans), 사용자에게 추가 정보 요청)
신뢰도 측정은 샘플별로 이루어집니다. 이는 평균적인 측정이 아닙니다.

슬라이스 기반(slice-based) 평가 테스트를 통한 성능 및 공정성 평가

슬라이싱(Slicing)은 데이터를 중요한 슬라이스(하위 집합)로 분리하고 각 슬라이스에 대해 모델이 어떻게 수행되는지 평가하는 것을 의미합니다.

전역 집계(global aggregation) 지표에 초점을 맞추고 슬라이스 기반 성능을 무시하는 것은 문제가 있습니다.

어떤 문제의 경우, 모델이 모든 슬라이스에 대해 동일하게 작동해야 합니다. 만약 다르게 작동한다면 모델이 편향되고(biased) 불공정할(unfair) 수 있습니다.
- 예를 들어, 모델 A의 전체 정확도는 96%이지만, 여성 슬라이스를 남성 슬라이스와 별도로 평가할 때 정확도가 더 나쁘다는 것을 발견할 수 있습니다. 모델 B는 전체적으로 95%로 약간 성능이 낮지만 남성과 여성 슬라이스에 대해 동일한 정확도를 가집니다. 모델 B가 아마도 더 바람직할 것입니다.
- 동일하게 수행되어야 하는 다른 슬라이스에서 모델이 다르게 수행된다는 것을 발견하는 것은 전체 성능을 향상시킬 기회를 발견했음을 의미합니다.
어떤 문제의 경우, 특정 슬라이스에 대해 모델이 더 잘 수행되기를 기대합니다. 만약 슬라이스들이 동일하게 수행된다면, 그것은 문제입니다.
- 예를 들어, 이탈 예측(churn prediction)에서, 유료 고객 슬라이스가 무료(freemiam) 고객 슬라이스보다 더 중요합니다. 이 경우 유료 고객 슬라이스의 성능이 더 좋기를 기대할 것입니다.

중요한 슬라이스가 무엇인지 정의하는 것은 과학이라기보다는 예술에 가깝습니다. 몇 가지 일반적인 접근 방식은 다음과 같습니다.

휴리스틱 기반: 도메인 지식에 기반하여 데이터를 슬라이스합니다. (예: 성별, 모바일 vs 웹 트래픽, 인종별)
오류 분석(Error analysis): 잘못 분류된 예제들을 수동으로 검토하고 그들 사이의 패턴을 찾습니다. 특정 그룹이 지속적으로 잘못 분류된다면 슬라이스를 발견할 수 있습니다.
슬라이스 파인더(Slice finder): 슬라이스 찾기를 체계화하기 위한 일부 연구가 있었습니다. 보통 후보 슬라이스를 자동 생성한 다음 나쁜 후보를 가지치기(pruning)합니다. 예:
- Slice Finder: Automated Data Slicing for Model Validation
- Subgroup Discovery Algorithms: A Survey and Empirical Evaluation

중요한 슬라이스를 찾으면, 슬라이스 기반 평가 테스트를 수행할 수 있도록 각 슬라이스에 대해 충분하고 정확하게 레이블이 지정된 데이터가 필요합니다.

7 - 모델 배포 및 예측 서비스

이제 ML 모델이 선택, 학습, 평가되었으므로 프로덕션에 배포할 차례입니다. 이 책의 다른 모든 단계와 마찬가지로, 이것은 반복적인 과정이며 이전 단계로 돌아가 일부를 다시 생각해야 할 수도 있습니다. 특히 이 단계에서는 모델이 예측을 서빙하고 계산하는 방식이 모델 설계 방식, 필요한 인프라, 그리고 사용자가 경험하는 동작에 영향을 미치기 때문에 이러한 반복적 특성이 특히 적용됩니다.

이 장에서는 다음 내용을 다룹니다.

ML 프로덕션 배포에 관한 몇 가지 일반적인 오해.
4가지 주요 예측 서빙 모드 설명: 1. 배치 예측, 2. 배치 피처만 사용하는 온라인 예측, 3. 배치 피처와 스트리밍 피처를 모두 사용하는 온라인 예측 (일명 스트리밍 예측), 4. 1과 2의 하이브리드.
배치 예측 VS 온라인 예측을 언제 사용해야 하는지에 대한 직관 제공.
배치 학습 데이터 파이프라인과 스트리밍 예측 파이프라인을 통합할 때의 과제.
ML 모델의 추론 속도를 높이기 위한 모델 압축(model compression) 기술.
모델을 클라우드 VS 엣지에 배포할 때의 고려 사항.

시작하기 전 몇 가지 입문 참고 사항:

프로덕션(Production)은 팀마다 매우 다른 것을 의미합니다. 어떤 팀에게 "프로덕션"은 일부 데이터 분석을 수행하기 위해 노트북에서 모델을 사용하는 것입니다. 다른 팀에게 "프로덕션"은 하루에 수백만 명의 사용자를 위한 예측을 생성하기 위해 모델을 계속 실행하는 것입니다. 이 장은 후자에 더 가까운 유스케이스에 초점을 맞춥니다.
"모델을 프로덕션에 배포하는 것"의 어려운 부분 중 일부는 다음과 같습니다.
- 밀리초(millisecond) 수준의 지연 시간과 99%의 가동 시간(uptime)으로 많은 수의 사용자에게 모델을 사용 가능하게 만들기.
- 프로덕션에서 모델이 실패하는 시점을 인지하고 적절한 사람에게 자동으로 알리기.
- 프로덕션 버그를 수정하기 위해 원활하게(seamlessly) 업데이트를 배포하기.
어떤 회사에서는 모델을 만드는 엔지니어가 배포하고 운영하는 엔지니어와 동일합니다. 다른 회사에서는 모델을 만드는 엔지니어가 모델을 내보내고(export) 배포를 위해 다른 팀에 전달합니다.
- Chip(저자)은 첫 번째 방식 (당신이 만들었으면, 당신이 배포한다)이 더 낫다고 믿습니다.
프로덕션에 배포하려면 "모델 내보내기" (일명 직렬화(serialization))가 필요합니다. 모델에는 내보낼 수 있는 두 가지 부분, 즉 모델 정의(model definition)와 모델 파라미터(model parameters)가 있습니다. 일반적으로 두 아티팩트(artifacts)는 함께 내보내집니다.
- TF 및 PyTorch의 내보내기 함수 예: tf.keras.Model.save 및 torch.onnx.export()

ML 배포에 관한 오해

오해 1: 한 번에 하나 또는 두 개의 ML 모델만 배포한다

이는 사실이 아닙니다. 중대형 기업은 프로덕션 환경에서 동시에(concurrently) 아주 많은 ML 모델을 실행합니다. 애플리케이션 기능당 적어도 하나의 모델을 찾는 것이 일반적입니다. 예: 승차 수요 예측, 드라이버 가용성 예측, 도착 시간 추정, 동적 가격 책정 등.

오해 2: 아무것도 하지 않으면 모델 성능은 동일하게 유지된다

소프트웨어 시스템처럼 ML 시스템도 "소프트웨어 노후화(software rot)"를 겪습니다. 또한, ML 시스템은 시간이 지남에 따라 데이터 분포 변화를 겪으며, 이러한 변화는 성능을 저해할 것입니다. 이것이 ML 모델이 학습 직후에 가장 좋은 성능을 내는 경향이 있는 이유입니다.

오해 3: 모델을 그렇게 자주 업데이트할 필요는 없다

위에서 언급한 성능 저하(performance decay)와 관련하여, 우리는 가능한 한 자주 모델을 업데이트하기를 원합니다. "한 달에 한 번" 또는 "분기에 한 번"의 주기가 일반적입니다. 그러나 필요한 경우 X분마다 업데이트를 수행할 수 있는 회사도 있습니다.

오해 4: 대부분의 ML 엔지니어는 규모(Scale)에 대해 걱정할 필요가 없다

이는 사실이 아닙니다. 대부분의 ML 엔지니어는 중대형 규모의 회사에 고용되어 있습니다. 이 정도 규모의 회사가 초당 수백 건의 추론을 생성하거나 수백만 명의 사용자를 처리해야 하는 모델을 보유하는 것은 상당히 일반적입니다.

예측 서빙의 네 가지 모드

참고: 이 주제에 대한 용어는 커뮤니티 내에서 여전히 모호합니다(murky). 유사한 개념을 지칭하는 다른 용어를 찾을 수도 있습니다.

프로덕션에서 예측을 서빙하는 세 가지 주요 모드와 하나의 하이브리드 모드가 있습니다.

배치 예측(Batch prediction): 배치 피처만 사용하며, 예약되거나 트리거되는 작업을 실행하여 예측을 대량 생산하고 데이터베이스에 저장합니다. 추론 시점에는 DB에서 예측을 조회(looked up)합니다.
1. 장점:
  1. 미리 계산된 예측은 매우 빠르게 검색되어 사용자에게 제공될 수 있습니다.
  2. GPU 벡터화(vectorisation)를 활용하기 위해 여러 추론을 일괄 처리(batching up)하는 것이 자연스러운 단계입니다. 추론 배칭은 높은 예측 처리량(throughput)으로 이어집니다.
  3. 추론이 필요한 데이터를 분할하여 여러 병렬 노드로 전송함으로써 예측 처리량을 더욱 높일 수 있습니다.
2. 단점:
  1. 해당 예측을 사용할 만큼 자주 앱을 사용하지 않는 사용자를 위해 예측을 생성할 수 있습니다.
  2. 예측에 포함하기 위해 "방금" 사용 가능해진 데이터를 고려할 수 없습니다. 예측은 마지막 피처 계산 작업이 실행되었을 때의 세상 상태를 반영합니다.
3. 사용 시기:
  1. 예측의 빠른 검색이 필요하고 최신이 아닐 수도 있는 피처를 사용해도 괜찮을 때. 즉, "배치 피처만 사용하는 온라인 예측 (모드 2)"이 충분히 빠르지 않거나 저렴하지 않을 때입니다. 이 모드가 실행 가능하려면 모든 쿼리(예: 모든 사용자)에 대한 예측을 계산하고 저장하는 것이 수용 가능해야 합니다.
  2. 이 모드의 또 다른 유스케이스는 모집단에 대한 전반적인 집계 통계를 파악하기 위해 모든 가능한 쿼리에 대한 예측이 필요할 때입니다. 예를 들어, 다음 달에 이탈할 가능성이 있는 상위 10%의 고객에게 연락하고 싶을 때입니다.
배치 피처만 사용하는 온라인 예측(Online prediction that uses only batch features): 추론 계산 자체는 즉석에서(on the fly) 그리고 요청 시(on demand) 수행되지만, 필요한 모든 피처는 미리 계산되었으며 스트리밍 피처의 실시간 계산이 필요하지 않습니다.
1. 장점:
  1. 실제로 예측이 필요한 사용자를 위해서만 예측을 생성합니다.
2. 단점:
  1. 피처에 "방금" 사용 가능해진 데이터를 고려할 수 없습니다.
  2. 추론 시 GPU 벡터화를 사용하기 위해 추론 요청을 일괄 처리하는 것은 배칭을 위한 시간 윈도우(time windows)를 처리해야 하므로 약간 더 어렵습니다.
  3. 예측이 사용자에게 제공되기까지 더 느릴 것입니다.
3. 사용 시기: 전체 고객 기반에 대한 예측을 얻는 컴퓨팅 노력을 낭비할 여유가 없고 검색 속도를 희생할 의향이 있을 때. 또한 미리 계산된 피처를 사용해도 괜찮아야 합니다.
배치 피처와 스트리밍 피처를 모두 사용하는 온라인 예측 (일명 스트리밍 예측): 추론 계산은 즉석에서 그리고 요청 시 수행됩니다. 모델을 위한 일부 피처는 미리 계산되지만 일부는 "최신(fresh)"이어야 하므로 스트리밍 피처를 사용하여 즉석에서 계산되어야 합니다. 이 모드가 작동하려면 시스템에 거의 실시간(near real-time) 전송 및 데이터 스트림 계산이 필요합니다. 아래 다이어그램 참조.
1. 장점:
  1. 실제로 예측이 필요한 사용자를 위해서만 예측을 생성합니다.
  2. 피처 계산을 위해 "방금" 사용 가능해진 데이터를 고려할 수 있습니다.
2. 단점:
  1. 추론 시 GPU 벡터화를 사용하기 위해 추론 요청을 일괄 처리하는 것은 배칭을 위한 시간 윈도우를 처리해야 하므로 약간 더 어렵습니다.
  2. 스트리밍 피처가 계산된 다음 추론될 때까지 기다려야 하므로, 예측은 "배치 피처만 사용하는 온라인 예측"보다 훨씬 더 느릴 것입니다.
3. 사용 시기: 방금 생성된 데이터를 예측에 반영하는 것이 매우 중요할 때. 거래 및 로그인 사기 탐지가 일반적인 예입니다.
모드 1과 2의 하이브리드 (배치 및 배치 피처를 사용한 온라인): 인기 있는 쿼리(예: 자주 로그인하는 사용자)에 대해서는 예측을 미리 계산하고, 덜 인기 있는 쿼리에 대해서는 모드 2를 사용하여 온라인 예측을 생성합니다.
1. 장점:
  1. 빈번하지 않은 쿼리에 대한 추론을 계산하고 저장하는 자원 낭비 문제가 해결됩니다.
2. 단점:
  1. "빈번한 쿼리"가 무엇을 의미하는지 파악해야 합니다.
  2. 배치 시스템과 온라인 시스템을 모두 처리해야 하므로 복잡성이 증가합니다.
  3. 이 모드는 여전히 피처에 "방금" 사용 가능해진 데이터를 고려할 수 없습니다.
3. 사용 시기: 일반적인 쿼리(모드 1처럼)에 대해 매우 빠른 예측 검색을 제공해야 하지만, 모든 쿼리에 대한 예측을 미리 계산할 여유가 없을 때. 더 빠른 예측 검색의 이점이 증가된 복잡성보다 커야 합니다.

"온라인 예측"과 "배치 예측"이라는 용어는 혼란스러울 수 있습니다. 이 문맥에서 이 용어들은 예측이 언제 이루어지는지를 나타냅니다. 두 방식 모두 GPU 벡터화 최적화를 활용하기 위해 여러 샘플에 대한 예측을 동시에 수행(즉, 추론 요청을 배치로 그룹화)할 수 있습니다. 또한 두 방식 모두 한 번에 하나의 샘플을 처리할 수도 있습니다.

스트리밍 예측 → 배치 학습 파이프라인과 스트리밍 서빙 파이프라인 통합하기

이 섹션은 주로 서빙 모드 3: "배치 피처와 스트리밍 피처를 모두 사용하는 온라인 예측"과 관련이 있습니다.

학습용 피처를 구축하는 데 사용되는 배치 데이터 파이프라인과, 추론 시점에 즉석에서 피처를 계산하기 위한 별도의 데이터 파이프라인을 가진 회사를 찾는 것은 드문 일이 아닙니다.

두 개의 서로 다른 파이프라인을 갖는 것은 한 파이프라인의 변경 사항이 다른 파이프라인에 전파되지 않아 피처 드리프트(feature drift)를 유발하기 때문에 ML에서 버그의 일반적인 원인이 됩니다.

배치 파이프라인과 스트리밍 파이프라인을 통합하기 위한 인프라 구축은 매우 인기 있는 주제가 되었습니다. 기업들은 일반적으로 피처 스토어(feature stores)를 사용하거나 Apache Flink와 같은 스트림 컴퓨팅 기술을 기반으로 자체 개발(in-house) 도구를 구축하여 문제를 해결하려고 합니다.

모델 압축을 통한 더 빠른 추론

필요한 경우 추론 지연 시간을 줄일 수 있는 3가지 방법이 있습니다.

모델 압축(Model compression): 모델을 더 작게 만듭니다. 이 섹션의 초점입니다.
추론 최적화(Inference Optimization): 추론 지연 시간을 줄이기 위해 계산 및 컴파일 파라미터를 조정합니다. 이에 대한 자세한 내용은 아래의 "모델 최적화" 섹션에서 다룹니다.
더 빠른 하드웨어(Faster hardware): 더 좋은 하드웨어를 구매하거나 가지고 있는 하드웨어를 더 빠르게 실행시킵니다.

원래 모델 압축은 모델을 더 작게 만들어 엣지 디바이스(edge devices)에 탑재할 수 있도록 돕기 위해 개발되었습니다. 그러나 모델을 더 작게 만들면 일반적으로 더 빨리 실행되므로, 이제 압축은 엣지가 아닌 시나리오에서도 추론 속도를 높이는 데 사용되고 있습니다.

압축은 또한 공정성(fairness) 영역에도 파급 효과(ripple effects)를 미친다는 점에 유의하십시오. 자세한 정보는 11장을 참조하십시오.

모델 압축에는 4가지 일반적인 기술이 있습니다.

저계수 분해 (Low-rank factorization)
지식 증류 (Knowledge distillation)
가지치기 (Pruning)
양자화 (Quantization)

저계수 분해 (Low-rank factorization)

직관: 고차원 텐서(tensor)를 더 낮은 차원의 텐서로 대체합니다.
예: CNN을 위한 컴팩트 컨볼루셔널 필터(compact convolutional filters).
단점: 저계수 방법은 특정 유형의 모델에 한정되는 경향이 있으며 기본 아키텍처에 대한 깊은 이해를 필요로 합니다. 이 때문에 아직 광범위한 유스케이스에서 사용되지 않고 있습니다.

지식 증류 (Knowledge Distillation)

직관: 작은 모델(학생)이 더 큰 모델 또는 모델 앙상블(교사)을 모방하도록 학습됩니다. 배포하는 것은 이 더 작은 모델입니다.
예: DistilBERT(학생)는 BERT 모델(교사)의 크기를 40% 줄이면서 언어 이해 능력의 97%를 유지하고 60% 더 빠릅니다.
장점: 교사와 학생 간의 아키텍처 차이에 관계없이 작동합니다. 예를 들어, 랜덤 포레스트 학생과 트랜스포머 NN 교사를 가질 수 있습니다.
단점: 사용 가능한 교사 모델이 있어야 합니다.

가지치기 (Pruning)

직관: 결정 트리의 가지치기(불필요하거나 중복되는 트리 가지 제거)에서 영감을 받았습니다. 신경망의 맥락에서, 가지치기는 2가지 형태를 띱니다.
- 전체 노드(node)를 제거하여 파라미터 수를 줄입니다. 이 형태는 덜 일반적입니다.
- 더 일반적인 방법: 예측에 거의 기여하지 않는 파라미터를 찾아 0으로 설정합니다. 아키텍처는 동일하게 유지되지만 0이 아닌 파라미터의 수를 극적으로 줄일 수 있습니다. 희소(Sparse) 모델은 더 적은 저장 공간을 필요로 하고 더 높은 계산 성능을 갖는 경향이 있습니다. 실험에 따르면 전체 정확도를 유지하면서 크기를 최대 90%까지 줄일 수 있습니다.
장점: NN의 아키텍처에 관계없이 작동합니다.
단점: 가지치기는 모델에 편향(bias)을 도입할 수 있습니다. 자세한 내용은 11장에서 다룹니다.
- #todo : 올바른 섹션 링크하기
참고: 가지치기는 또한 어떤 노드가 중요한지 결정하고, 모델을 재설계(re-architecting)하며, 재학습하는 아키텍처 탐색 도구로도 사용되어 왔습니다. 그러나 일부 연구에서는 크고 희소한 모델이 재설계되고 재학습된 모델보다 성능이 우수함을 보여주었습니다.

양자화 (Quantization)

직관: 파라미터를 저장하기 위해 32비트 정밀도 부동 소수점(floats)을 사용하는 대신, 더 적은 비트를 사용합니다.
- 파라미터당 비트 수가 적다는 것은 모델의 메모리 점유 공간(footprint)이 더 작아짐을 의미합니다.
- 메모리가 적다는 것은 (학습 중 양자화를 사용한다면) 원할 경우 더 큰 모델을 학습시킬 수 있음을 의미합니다.
- 메모리가 적다는 것은 또한 배치 크기를 늘려 학습 계산 속도를 높일 수 있음(학습 중 양자화를 사용한다면)을 의미합니다.
- 부동 소수점의 정밀도가 낮다는 것은 원하는 정밀도를 달성하는 데 필요한 계산이 적다는 것을 의미하며, 이는 학습과 추론 속도를 모두 높여줍니다.
유형:
- 목표 정밀도별 유형:
  - 16비트 (일명 "저정밀도(low-precision)")
  - 8비트 (일명 정수 양자화(integer quantization) 또는 "고정 소수점(fixed-point)")
    - 고정 소수점 추론은 엣지에서의 추론을 위한 업계 표준이 되었습니다.
    - Google의 TensorFlow Lite, Facebook의 PyTorch Mobile, NVIDIA의 TensorRT는 모두 몇 줄의 코드로 학습 후 고정 소수점(post-training fixed-point) 양자화를 제공합니다.
  - 1비트 (일명 이진 가중치 네트워크(binary weight networks))
- 양자화 적용 시점별 유형:
  - 학습 중 양자화(Quantization during training): 처음부터 저정밀도로 학습합니다.
  - 학습 후 양자화(Quantization post-training): 완전 정밀도(full precision)로 학습한 다음, 추론을 위해서만 학습된 모델을 양자화합니다.
장점:
- 모든 형태의 양자화는 기존 라이브러리를 사용하여 수행하기 간단하며 여러 모델 유형에 잘 일반화됩니다.
- 저정밀도 학습은 매우 인기를 얻었으며 학습 하드웨어(예: NVIDIA GPU 및 Google TPU)가 이에 대한 직접적인 하드웨어 지원을 제공하기 시작했습니다.
- 2022년 기준 고정 소수점 학습은 아직 매우 대중적이진 않지만 유망한 결과를 보여주었습니다.
단점:
- 정밀도가 낮다는 것은 표현될 수 있는 숫자가 적다는 것을 의미합니다. 이는 정밀도 반올림 오류(precision rounding errors) 및 숫자 경계 오버플로우(number boundary overflow)의 위험을 도입합니다. 작은 반올림 오류가 성능의 극적인 변화로 이어질 수 있습니다.
  - 효율적인 반올림 및 스케일링은 간단하지 않습니다(non-trivial). 하지만 다행히도 주요 프레임워크에는 이것이 내장되어 있습니다.

더 많은 압축 리소스

“The Top 168 Model Compression Open Source Projects”
“Survey of Model Compression and Acceleration for Deep Neural Networks" Cheng et al, 2020.

클라우드와 엣지의 ML

추론 계산의 주요 부분을 어디에서 수행할지 결정해야 합니다. 계산은 클라우드 또는 엣지에서 일어날 수 있습니다.

클라우드 (The cloud)

장점

모델을 배포하는 가장 쉬운 방법입니다. 모델과 모델이 실행되는 하드웨어의 호환성에 대해 거의 걱정할 필요가 없습니다.

단점

ML 추론 클라우드 비용은 상당할 수 있습니다. 중소기업의 비용은 연간 5만 달러에서 2백만 달러 사이가 될 수 있습니다. 엣지로 더 많은 계산을 옮길수록, 비용을 더 적게 지불합니다.
클라우드는 추론에 네트워크 지연 시간(network latency)을 도입합니다. 많은 경우 네트워크 지연 시간은 추론 지연 시간보다 더 큰 병목 현상이 될 수 있습니다.
해당 기능은 고객의 인터넷 접속에 의존하게 됩니다.

엣지 (The edge)

브라우저, 휴대폰, 노트북, 스마트워치, 자동차, 보안 카메라, 로봇, 임베디드 디바이스, FPGA(필드 프로그래머블 게이트 어레이), ASIC(주문형 반도체).

그 인기로 인해, 기업들은 다양한 ML 유스케이스에 최적화된 엣지 디바이스를 개발하기 위해 경쟁하고 있습니다. Google, Apple, Tesla를 포함한 기존 기업들은 모두 자체 ML 최적화 칩을 만들 계획을 발표했습니다.

장점

인터넷 없이 작동합니다.
유스케이스에 엄격한 "인터넷 사용 불가" 정책이 있는 경우 유일한 방법일 수 있습니다.
네트워크 지연 시간이 없기 때문에 전반적인 지연 시간이 줄어들 수 있습니다.
민감한 데이터를 다루고 있어 네트워크로 전송하고 싶지 않은 경우(예: 지문, FaceID) 유용합니다.
엣지 계산은 GDPR과 같은 개인정보 보호 규정을 준수하기 더 쉽게 만듭니다.

단점

모델이 대상 하드웨어에서 실행되도록 호환되지 않거나 효율적으로 실행되지 않을 수 있습니다.
- 하드웨어 제조업체와 프레임워크 제작자는 새로운 하드웨어 또는 기존 하드웨어의 새로운 프레임워크에 대한 지원을 추가하는 데 일반적으로 오랜 시간이 걸립니다. 이는 매우 어려운 작업이기 때문입니다.
모델을 다른 대상 하드웨어에서 실행되도록 컴파일(compilation)하는 것은 많은 수동 노력이 필요한 어렵고 시간이 많이 걸리는 작업입니다.
다양한 하드웨어 아키텍처에 맞게 모델을 최적화하는 것은 매우 어렵습니다. 응용 ML 엔지니어라면 일반적으로 이 작업을 수행할 필요가 없습니다. 이는 보통 ML 프레임워크 개발자가 수행합니다. 연구자라면 이 작업을 수행해야 할 수도 있습니다.
엣지 디바이스는 모델을 실행할 수 있을 만큼 충분히 강력하고, 충분한 메모리와 배터리를 갖추고 있어야 합니다. 이 모든 것이 솔루션에 제어하기 어려운 변수를 추가합니다.

엣지 디바이스를 위한 모델 컴파일 및 최적화

컴파일은 ML 모델을 대상 하드웨어에서 실행될 수 있는 아티팩트로 변환하는 과정입니다. 최적화는 대상 하드웨어의 속성을 활용하여 모델이나 아티팩트를 조정하고 더 빨리 실행되도록 만드는 과정입니다.

컴파일

응용 ML 엔지니어로서, 여러분은 일반적으로 이미 생성된 모델 컴파일러를 사용할 것입니다.

일부 컴파일러는 중간 표현(Intermediate Representations, IRs)이라는 개념에 의존합니다. IR은 프레임워크 제작자와 하드웨어 제조업체가 컴파일러 생성을 용이하게 하고 하드웨어 지원 문제를 완화하기 위해 모두 채택한 표준화된 중간 형식입니다.

최적화

모델이 대상 아키텍처에서 실행된다는 사실이 효율적으로 그렇게 할 수 있음을 의미하지는 않습니다.

응용 ML 엔지니어로서, 여러분은 일반적으로 컴파일러 또는 하드웨어 최적화에 의존할 것이며, 하드웨어 작업을 직접 최적화하지는 않을 것입니다.

ML 프레임워크 개발자와 하드웨어 제조업체는 ML과 하드웨어 아키텍처 모두에 대해 아는 전문 최적화 엔지니어를 고용하는 데 막대한 돈을 씁니다.

최적화 엔지니어가 아니더라도 코드를 최적화할 수는 있다는 점에 유의하십시오.

수동 모델 최적화

최적화 엔지니어는 모델을 더 빨리 실행시킬 방법을 찾기 위해 휴리스틱(heuristics)을 사용합니다. 수동으로 만든 휴리스틱은 최적이 아니며 기본 ML 프레임워크나 하드웨어 아키텍처가 변경될 때 유연하지 못하다는 문제가 있습니다.

모델 최적화에 ML 사용

휴리스틱에 의존하는 대신 ML을 사용하여 최적의 연산 순서 탐색을 좁힙니다. 이는 최적에 더 가깝고 ML 프레임워크 및 하드웨어 변경에 유연하게 적응할 수 있다는 장점이 있습니다.

ML 기반 컴파일러의 결과는 인상적입니다. 응용 ML 엔지니어로서 여러분은 하나의 하드웨어 백엔드에 대해 모델을 한 번 최적화한 다음, 동일한 하드웨어 유형의 여러 디바이스에서 실행합니다. ML 기반 옵티마이저는 실행하는 데 몇 시간, 때로는 며칠이 걸릴 수 있다는 점을 고려하십시오.

브라우저에서의 ML

원칙적으로, 모델을 브라우저에서 효율적으로 실행할 수 있게 한다면, 더 이상 대상 하드웨어, 컴파일, 최적화에 대해 걱정할 필요가 없습니다.

사람들은 보통 브라우저에 대해 이야기할 때 자바스크립트(Javascript)를 생각합니다. 모델을 자바스크립트 브라우저 실행 가능 아티팩트로 변환하는 라이브러리가 있습니다. 그러나 JS는 근본적으로 ML에 적합하지 않으므로 사용을 권장하지 않습니다.

유망한 대안은 WebAssembly(WASM)로 컴파일되는 모델입니다. WASM은 JS보다 훨씬 빠르며 2021년 기준 브라우저의 93%가 이를 지원했습니다.

WASM은 iOS 또는 Android 앱을 통해 네이티브 하드웨어에서 모델을 실행하는 것에 비하면 여전히 느립니다.

8 - 프로덕션 환경에서의 데이터 분포 변화와 모니터링

모델을 프로덕션에 배포하는 것이 이야기의 끝이 아닙니다. 프로덕션 환경의 모델은 시간이 지남에 따라 모든 모델이 겪는 자연스러운 성능 저하를 감지하기 위해 지속적으로 모니터링되어야 합니다.

이 장에서는 다음 내용을 다룹니다.

ML 모델이 실패하는 두 가지 다른 방식: 소프트웨어 시스템 실패 VS ML 고유의 실패.
그런 다음 이 장에서는 특히 까다로운 ML 고유의 실패인 데이터 분포 변화(data distribution shifts)에 대해 심층적으로 다룹니다. 데이터 분포 변화의 유형과 이를 감지하고 해결하는 방법을 다룹니다.
이 장은 모니터링과 관측 가능성(monitoring and observability)으로 마무리됩니다.
- 모든 소프트웨어 시스템이 가져야 할 운영 지표 (예: 지연 시간, CPU 사용률)
- ML 고유의 지표

다음 장에서는 문제가 감지되었을 때 모델을 수정하는 방법을 다룹니다.

ML 시스템 실패의 원인

ML 시스템은 크게 두 가지 방식, 즉 소프트웨어 시스템으로서의 실패와 ML 고유의 실패로 오작동할 수 있습니다.

소프트웨어 시스템 실패

ML 시스템 역시 소프트웨어 분산 시스템이므로 모든 소프트웨어 실패 모드가 적용됩니다. 몇 가지 일반적인 예는 다음과 같습니다.

의존성 실패(Dependency failure): 의존하는 구성 요소가 손상되거나 중단되고 그 결과로 프로그램이 오작동합니다.
배포 실패(Deployment failure): 예를 들어, 잘못된 버전의 ML 아티팩트(artefact)를 배포하거나 ML 모델을 둘러싼 코드에 버그를 배포하는 경우입니다.
하드웨어 실패(Hardware failure): 모델을 실행하는 인프라가 실패하고 시스템도 함께 실패합니다.

Google은 지난 15년간의 ML 시스템 실패에 대한 내부 설문 조사를 수행했으며, 96건 중 60건이 ML 고유의 실패가 아닌 소프트웨어 실패임을 발견했습니다. 더욱이, 60건 중 대부분은 분산 시스템 실패 모드와 관련된 실패임을 발견했습니다.

2022년 현재, ML 시스템의 소프트웨어 시스템 실패는 여전히 매우 만연합니다. 왜냐하면 이러한 시스템을 관리하기 위한 관행, 표준 및 도구가 전통적인 소프트웨어에 비해 아직 초기 단계이기 때문입니다. 이 분야가 성숙해짐에 따라 시간이 지남에 따라 이것이 줄어들 것으로 예상할 수 있습니다.

추가 자료:

이 주제에 대해 더 알고 싶다면 Chip(저자)은 "Reliable Machine Learning" by Todd Underwood를 추천합니다.

ML 고유의 실패

예는 다음과 같습니다.

데이터 수집 및 처리 문제
잘못된 하이퍼파라미터
학습 / 추론 파이프라인 간의 변경 사항이 다른 쪽에 복제되지 않음
데이터 분포 변화 (아래에서 자세히 다룸)
엣지 케이스 (Edge cases)
퇴행성 피드백 루프 (Degenerate feedback loops)

이 섹션에서는 이 중 두 가지를 다루고, 다음 섹션에서는 데이터 분포 변화에만 집중할 것입니다.

극단적인 데이터 샘플 엣지 케이스

엣지 케이스는 너무 극단적이어서 모델이 치명적인 실수를 하도록 만드는 데이터 샘플입니다.

일부 애플리케이션에서는, 잘못된 예측의 결과가 치명적일 경우 엣지 케이스가 모델 배포 자체를 막을 수 있습니다. 일반적인 예는 자율 주행 자동차입니다.

엣지 케이스와 이상치(outliers)는 관련이 있지만 서로 다른 것입니다. 이상치는 극단적인 데이터 샘플이지만 모델이 (어느 정도) 처리할 수 있는 것입니다.

학습 중에 이상치를 제외하는 것과 엣지 케이스에 대한 모델 견고성(robustness) 사이에는 트레이드오프(trade-off)가 있습니다. 이상치는 일반적으로 모델이 결정 경계(decision boundaries)를 더 잘 학습하도록 돕기 위해 학습 중에 제거됩니다. 그러나 이상치를 제거하면 추론 시점에 (이상치를 제거할 수 없는) 극단적인 데이터 샘플을 만났을 때 예상치 못한 결과를 초래할 수도 있습니다.

퇴행성 피드백 루프 (Degenerate feedback loops)

퇴행성 피드백 루프는 예측 자체(예: 추천된 노래)가 피드백(예: 선택된 노래)에 영향을 미치고, 이것이 다시 모델의 다음 이터레이션(iteration)에 영향을 미칠 때 발생할 수 있습니다.

예를 들어, "Acme Inc에서 근무함"이라는 피처가 성과의 좋은 예측 변수임을 학습한 이력서 스크리닝 모델이 프로덕션 환경에서 실행 중이라고 상상해 보십시오. 이 모델은 다른 어떤 회사보다 Acme Inc 출신 이력서를 리크루터에게 불균형적으로 많이 노출시키고, 따라서 다른 어떤 회사보다 Acme Inc 출신 사람들이 더 많이 고용됩니다. 이는 모델의 향후 이터레이션이 "Acme Inc에서 근무함" 피처에 훨씬 더 많은 가중치를 부여하게 만들 것입니다. 이를 제어하지 않고 방치하면, 모델은 스스로 편향될 것이고 실제 비즈니스 성과는 저하될 것입니다.

퇴행성 피드백 루프는 모델이 프로덕션 환경에 있고 사용자가 이와 상호작용할 때만 발생합니다. 퇴행성 피드백 루프는 추천 시스템 및 광고 클릭률 예측과 같이 사용자로부터의 자연스러운 레이블(natural labels)이 있는 작업에서 특히 일반적입니다.

이것은 많이 연구되는 분야입니다. “노출 편향(exposure bias)”, “인기 편향(popularity bias)”, “필터 버블(filter bubbles)”, 때로는 “반향실 효과(echo chambers)”와 같은 이름으로 찾을 수 있습니다.

퇴행성 피드백 루프 탐지

모델이 퇴행성 피드백 루프를 겪고 있는지 탐지하려면 모델 출력의 다양성(diversity)을 측정합니다. 다양성과 관련된 여러 지표가 있습니다.

총 다양성(Aggregate diversity) 및 롱테일(long-tail) 아이템의 평균 커버리지
- Brynjolfsson et al. (2011), Fleder and Hosanagar (2009), and Abdollahpouri et al. (2019)
인기 대비 적중률(Hit rate against popularity): 다양한 인기 버킷(popularity buckets)에 대한 시스템의 예측 정확도를 측정합니다. 만약 추천 시스템이 덜 인기 있는 아이템을 추천하는 것보다 인기 있는 아이템을 추천하는 데 훨씬 더 능숙하다면, 이는 인기 편향을 겪고 있을 가능성이 높습니다.
- Chiea et al. (2021)
(5장에서 설명한) 피처 중요도 연구를 수행하면 모델이 특정 피처에 점점 더 많은 가중치를 부여함으로써 스스로 편향되고 있는지 시간 경과에 따라 탐지하는 데 도움이 될 수 있습니다.

퇴행성 피드백 루프 수정

방법 1: 무작위화(randomization) 사용

모델 출력에 무작위화를 도입하여 동질성(homogeneity)을 줄입니다. 예를 들어, 사용자에게 모델이 추천하는 아이템만 보여주는 대신, 무작위 아이템도 함께 보여주고 그들의 피드백을 사용하여 아이템의 진정한 품질을 결정합니다.

TikTok이 이 접근 방식을 따릅니다. 각 새로운 비디오는 무작위로 초기 트래픽 풀(pool)에 할당됩니다. 이 트래픽은 해당 비디오가 더 큰 트래픽 풀을 받아야 할지 또는 관련 없음으로 표시되어야 할지 결정하기 위해 비디오의 편향되지 않은 품질을 평가하는 데 사용됩니다.

무작위화는 사용자 경험을 희생시키면서 다양성을 향상시킵니다. 더 정교한 전략은 컨텍스추얼 밴딧(contextual bandits)을 사용하여 언제 탐색(explore)할지 대 언제 활용(exploit)할지 결정하고 예측 가능한 정확도 손실 내에서 다양성을 증가시키는 것입니다.

방법 2: 위치 피처(positional features) 사용

예측의 위치가 클릭될 가능성에 영향을 미친다면, 위치 피처를 사용하여 모델에게 위치의 영향을 가르칠 수 있습니다.

위치 피처는 5장에서 설명한 "위치 임베딩(positional embeddings)"과는 다릅니다.

위치 피처는 숫자형 (1, 2, 3, ...)이거나 불리언(boolean) (예: 이 아이템이 첫 번째 예측이었는가?)일 수 있습니다.

이해를 돕기 위한 간단한 예:

아래와 같이 학습 데이터에 불리언 위치 피처를 추가합니다.
추론 시, 노래가 1번째 위치에 추천되었는지 여부에 관계없이 사용자가 노래를 클릭할지 예측하고 싶습니다. 이를 위해 모든 후보에 대해 1st-position 피처를 false로 설정합니다.

이 간단한 예는 퇴행성 피드백 루프와 싸우기에 충분하지 않을 수 있습니다. 더 정교한 다중 모델 시스템이 사용될 수 있지만 기본 아이디어는 동일합니다.

방법 3: 컨텍스추얼 밴딧(Contextual bandits) 사용

밴딧과 컨텍스추얼 밴딧에 대한 자세한 내용은 9장에서 읽어보십시오.

데이터 분포 변화 (Data Distribution Shifts)

이것은 ML 고유의 실패 유형 중 하나로, 감지하고 조치하기가 매우 어렵기 때문에 별도의 섹션으로 다룰 가치가 있습니다.

몇 가지 용어:

소스 분포(Source distribution): 학습 데이터의 분포
타겟 분포(Target distribution): 프로덕션 환경의 추론 데이터 분포

데이터 분포 변화는 소스 분포와 타겟 분포 간의 차이를 의미합니다.

중요: 데이터 분포 변화는 모델의 성능 저하를 유발할 때만 문제가 됩니다. 변화가 있다는 사실이 반드시 조치를 취해야 함을 의미하지는 않습니다.

데이터 분포 변화의 유형

이론적으로, 모든 데이터 분포 변화가 동일하지는 않습니다. 그러나 실제로는:

어떤 유형의 변화가 발생했는지 판단하는 것은 매우 어려울 수 있습니다.
업계 엔지니어들이 분포 변화를 다루는 방식은 근본적인 변화 유형에 관계없이 동일한 경향이 있습니다.

모델은 동시에 여러 유형의 드리프트(drift)를 겪을 수 있습니다.

공변량 변화 (Covariate Shift)

일명: 데이터 드리프트 (data drift)

소스 분포와 타겟 분포 간에 P(X)는 다르지만 P(Y|X)는 동일하게 유지됩니다. 즉, 입력의 분포는 변하지만 특정 입력이 주어졌을 때의 레이블 확률은 동일하게 유지됩니다.

예: 암 병원의 데이터를 사용하여 유방암 탐지 모델을 구축합니다. 이 병원 데이터는 40세 이상의 여성들이 정기 검진으로 이 검사를 받도록 권장되기 때문에, 일반 인구에서 볼 수 있는 것보다 40세 이상 여성의 데이터를 더 많이 포함합니다. 즉, P(X=40세 이상 여성)가 소스 분포와 타겟 분포에서 다릅니다. 그러나, P(Y=유방암|X=40세 이상 여성)은 그 여성이 학습 데이터에 속하는지 여부에 관계없이 동일합니다.

공변량 변화는 여러 가지 이유로 발생할 수 있습니다.

학습 시점 (소스 분포에 영향):
- 샘플 선택 편향(Sample selection bias): 위 예시와 같습니다.
- (4장 → 클래스 불균형을 다루는 데이터 레벨 방법에서 논의된 바와 같이) 모델 학습을 돕기 위해 학습 데이터가 인위적으로 조정됩니다.
- 액티브 러닝(active learning)을 통해 학습 과정이 변경되어, 모델이 분류하기 어려운 샘플에 더 많이 노출됩니다. 이는 모델이 학습하는 기본 소스 분포를 변경합니다.
프로덕션 환경 (타겟 분포에 영향):
- 일반적으로 애플리케이션이 사용되는 환경의 주요 변경 결과입니다. 예를 들어: 새로운 인구 통계의 사용자가 추가되거나, 새로운 국가에 출시하는 경우입니다.

레이블 변화 (Label Shift)

일명: 사전 변화(prior shift), 사전 확률 변화(prior probability shift), 타겟 변화(target shift), 예측 드리프트(prediction drift)

소스 분포와 타겟 분포 간에 P(Y)는 다르지만 P(X|Y)는 동일하게 유지됩니다. 위 예시를 따르면, P(Y=유방암 보유)는 소스 분포와 타겟 분포에서 다르지만, P(X=40세 이상|Y=유방암 보유)는 두 분포에서 동일합니다.

공변량 변화는 (위 예시처럼) 레이블 변화를 유발할 수도 있지만, 모든 레이블 변화가 공변량 변화에 의해 유발되는 것은 아닙니다. 후자의 예는 책을 참조하십시오.

개념 변화 (Concept Drift)

일명: 사후 변화(posterior shift), "동일 입력, 다른 출력"

P(Y|X)는 변하지만 P(X)는 동일하게 유지됩니다. 예를 들어, 코로나 이전(pre-Covid) 데이터를 사용하여 아파트 가격 추정기를 학습시켰습니다. 만약 코로나 이후(post-Covid)에 동일한 모델을 사용한다면, 아파트는 동일하지만(즉, P(X=아파트 피처)는 코로나 전후 동일), 평가되는 가격은 극적으로 변했기 때문에 심각한 개념 변화를 겪을 것입니다.

많은 경우 개념 변화는 주기적이거나 계절적입니다. 예를 들어, 차량 공유 가격은 주중 대 주말에 변동합니다. 기업들은 개념 변화를 줄이기 위해 서로 다른 계절성 데이터로 학습된 다른 모델(예: 주말용 모델 vs 주중용 모델)을 가질 수 있습니다.

레이블 스키마 변경

분류 작업에서, 모델이 N개의 클래스를 출력하도록 학습되었는데 비즈니스 요구 사항이 변경되어 이제 N+m개의 클래스를 예측해야 할 때 발생합니다. 이는 높은 카디널리티(high-cardinality) 분류 문제에서 흔히 발생합니다.

회귀 작업에서, 출력 변수의 범위가 변경될 때 발생합니다.

데이터 분포 변화 탐지

데이터 분포 변화는 모델의 성능 저하를 유발할 때만 문제가 됩니다.

정확도 관련 지표를 사용한 탐지

데이터 분포 변화를 탐지하는 가장 좋은 메커니즘은 프로덕션 환경에서 모델의 정확도 관련 지표 (예: accuracy, F1, recall, AUC-ROC 등)를 모니터링하는 것입니다.

학습 시 테스트 세트를 사용하여 계산된 정확도와 관찰된 프로덕션 정확도 간에 큰 차이가 있다면, 데이터 변화 문제가 있을 수 있습니다.
관찰된 프로덕션 정확도가 시간이 지남에 따라 변한다면, 과거에는 없었던 데이터 드리프트 문제(예: 계절적 개념 변화, 사용자 기반 변경)가 나타났을 수 있습니다.

자연 레이블에 접근할 수 있다면, 정확도 관련 지표를 사용하여 변화를 탐지하는 것이 이상적입니다. 불행히도, 프로덕션 환경에서 항상 레이블에 접근할 수 있는 것은 아닙니다. 접근할 수 있더라도, 정확도 모니터링에 유용할 만큼 충분히 빠르지 않게 레이블이 지연될 수 있습니다. 그런 경우에도, 통계적 방법을 사용하여 데이터 분포 변화를 탐지할 수 있습니다.

통계적 방법을 사용한 탐지

엄밀히 말하면, 입력 분포 P(X), 실제 레이블 분포 P(Y), 그리고 조건부 분포 P(X|Y) 및 P(Y|X)를 모니터링하는 데 관심이 있어야 합니다.

어려운 점은, P(Y), P(X|Y), P(Y|X)를 모니터링하려면 실제(ground truth) 프로덕션 레이블이 필요하다는 것입니다. 더욱이, 실제 레이블에 접근할 수 있었다면, 정확도 관련 지표를 사용하여 탐지하는 것이 아마도 더 나을 것입니다.

이것이 실제(ground truth) 레이블에 접근할 수 없는 경우, 업계 대부분이 예측 분포 P(Y_hat) 및 입력 분포 P(X)의 변화를 모니터링하고 탐지하는 데 집중하는 이유입니다.

간단한 기술 통계를 통한 변화 탐지

이것은 간단하고 좋은 시작입니다.

소스 분포와 타겟 분포가 변했는지 파악하기 위해, 학습 세트와 관찰된 프로덕션 데이터에 대한 기술 통계(min, max, median, variance, 다양한 사분위수, 왜도(skewness), 첨도(kurtosis) 등)를 계산합니다.

기술 통계가 매우 다르다면, 분포 변화가 있었을 가능성이 높습니다. 그러나 그 반대는 사실이 아닙니다. 통계가 비슷하다고 해서 변화가 없었음을 보장하지는 않습니다.

가설 검정을 통한 변화 탐지

더 정교한 해결책은 두 모집단 간의 차이가 통계적으로 유의미한지 테스트하도록 설계된 통계적 검정을 사용하는 것입니다.

이를 수행할 때 몇 가지 참고 사항:

검정에서 통계적 차이가 있다는 것이 실제로 그 차이가 중요하다는 것을 의미하지는 않습니다. 다시 말하지만, 변화는 성능을 저해할 때 문제가 됩니다.
적은 샘플을 사용한 검정을 통해 통계적 차이를 감지할 수 있다면, 이는 아마도 그 차이가 심각하다는 것을 의미합니다. 반면에, 통계적 차이를 감지하는 데 엄청난 양의 데이터가 필요하다면, 그 차이는 아마도 매우 작아서 걱정할 필요가 없을 것입니다.
2-표본 검정(Two-sample tests)은 종종 저차원 데이터에서 더 잘 작동합니다. 검정을 실행하기 전에 데이터의 차원을 줄이는 것이 강력히 권장됩니다.
Alibi Detect는 많은 드리프트 탐지 알고리즘의 파이썬 구현을 포함하는 훌륭한 오픈 소스 패키지입니다.

이를 위해 사용될 수 있는 몇 가지 검정 (Alibi Detect에서 가져온 표):

콜모고로프-스미르노프 검정(Kolmogorov-Smirnov test):
- 작동하기 위해 기본 분포의 어떤 파라미터도 필요로 하지 않고, 기본 분포에 대해 어떤 가정도 하지 않기 때문에 (그래서 어떤 분포에도 작동함) 좋습니다.
- 불행히도 종종 그런 경우인, 고차원 데이터에서는 작동하지 않습니다.

변화 탐지를 위한 타임 윈도우 고려 사항

학습 데이터 분포 (일명 소스 분포)를 프로덕션 데이터 분포 (일명 타겟 분포)와 비교할 때, 테스트를 실행하기 위해 프로덕션 데이터를 가져오는 데 사용할 타임 윈도우(time window)를 선택해야 합니다. 이 섹션에는 해당 타임 윈도우를 선택할 때 고려해야 할 몇 가지 사항이 포함되어 있습니다.

데이터의 계절성을 고려하십시오. 데이터에 자연스러운 주간 주기가 있고, 학습 데이터에 여러 주가 포함되어 있다면, 일주일 미만의 프로덕션 타임 윈도우를 선택하면 이상한 결과가 나올 수 있습니다.
탐지 속도 vs 테스트의 신뢰성 트레이드오프를 고려하십시오. 더 짧은 타임 윈도우는 변화를 더 빨리 탐지하는 데 도움이 될 수 있습니다. 그러나, 더 많은 오탐(false alarms)을 유발할 수도 있습니다. 더 긴 타임 윈도우는 반대의 특성을 가집니다.
누적 타임 윈도우(accumulating time windows)와 슬라이딩 타임 윈도우(sliding time windows)의 차이점을 명심하십시오. 누적 타임 윈도우는 시간이 지남에 따라 반대쪽 끝의 오래된 데이터를 "폐기"하지 않고 프로덕션 데이터 세트에 데이터를 계속 추가합니다. 슬라이딩 타임 윈도우는 타임 윈도우를 벗어난 데이터를 폐기합니다.
- 누적 타임 윈도우는 훨씬 더 많은 데이터를 가질 수 있으므로 테스트가 더 신뢰할 수 있습니다. 그러나 이는 또한 이미 존재하는 데이터가 최근의 변경 사항을 가릴 수 있기 때문에, 이에 대해 실행되는 테스트가 갑작스러운 변화에 덜 반응적임을 의미합니다.
- 슬라이딩 타임 윈도우는 반대의 특성을 가집니다.

데이터 분포 변화 대응

변화에 대한 모델 민감도 최소화

지금까지, 우리는 데이터 분포 변화가 불가피하다고 논의했습니다. 그러나, 모델을 변화에 덜 민감하게 만들기 위해 할 수 있는 특정 작업이 있는 것도 사실입니다.

기법 1: 대규모 데이터셋을 사용하여 모델 학습

여기서의 희망은 대규모 데이터셋을 사용함으로써, 모델이 매우 포괄적인 분포를 학습하여 프로덕션에서 마주치는 어떤 데이터 포인트든 이 분포에서 올 가능성이 높게 만드는 것입니다.

이것은 연구에서 더 일반적이며 업계에서 항상 가능한 것은 아닙니다. 그럼에도 불구하고, 언급할 가치가 있습니다.

기법 2: 피처 선택 시 성능과 안정성 간의 트레이드오프 고려

어떤 피처는 다른 피처보다 분포 변화에 더 취약합니다. 예를 들어, 앱 스토어 평점은 모든 앱 및 OS 버전 출시마다 재설정됩니다. 대신 더 포괄적인(coarser) 백분위 평점을 사용하는 것을 고려할 수 있습니다. 피처의 정교함은 떨어지겠지만, 변화에 대해 더 안정적이고 견고할 것입니다.

기법 3: 빠르게 움직이는 시장과 느리게 움직이는 시장을 위해 별도 모델 생성 고려

미국의 주택 가격에 대한 회귀 모델을 구축하는 임무를 맡았다고 상상해 보십시오. 데이터를 탐색함으로써, 샌프란시스코와 뉴욕의 가격 변동이 미국 나머지 지역보다 훨씬 더 빠르다는 것을 알게 됩니다. 메인 모델과 별도로 해당 도시에 대한 독립적인 모델을 생성함으로써, 메인 모델을 지속적으로 재학습해야 할 필요성을 줄입니다. 또한, 빠르게 움직이는 시장 모델은 더 빈번한 재학습으로 최신 상태를 유지할 수 있습니다.

모델 배포 후 변화 수정

모델이 배포되면, 데이터 분포 변화를 다루는 두 가지 주요 접근 방식이 있습니다.

주기적으로 모델 재학습

이것은 단연코, 업계에서 볼 수 있는 가장 일반적인 전략입니다. 사실, 이것은 매우 중요해서 "9장: 지속적인 학습 및 프로덕션 환경에서의 테스트"가 전적으로 이 주제에 할애되어 있습니다.

이 접근 방식에서는 모델이 주기적으로(예: 한 달에 한 번, 일주일에 한 번, 하루에 한 번) 재학습됩니다. 고려해야 할 3가지 사항이 있습니다.

최적의 재학습 빈도(retraining frequency)에 대한 결정이 중요합니다. 그러나, 많은 기업이 여전히 실험 데이터 대신 직감(gut feeling)을 사용하여 이를 결정합니다. 재학습 빈도에 대한 자세한 내용은 "9장 → 모델을 얼마나 자주 업데이트해야 하는가"에 있습니다.
모델을 처음부터(from scratch) 재학습하기 (일명 상태 비저장(stateless) 재학습) VS 마지막 체크포인트에서 학습 계속하기 (일명 상태 저장(stateful) 재학습, 미세 조정(fine-tuning)). 이에 대한 자세한 내용은 9장 → 상태 비저장 vs 상태 저장 학습에 있습니다.
재학습에 어떤 데이터를 포함해야 합니까? 예: 지난 24시간, 지난주, 지난 6개월, 변화가 시작된 시점부터의 데이터?

이 3가지 사항을 결정하기 위해 실험을 실행해야 합니다.

새로운 레이블 없이 학습된 모델을 대상 분포에 적응시키기

이 접근 방식의 기법들은 본질과 연구 및 업계에서의 채택 정도가 다양합니다. 책에서 간략하게 언급된 두 가지 예:

Zhang et al (2013): 타겟 분포의 레이블을 사용하지 않고 공변량 변화와 레이블 변화 모두에 대해 모델의 예측을 수정하기 위해 커널 임베딩(kernel embedding) 및 조건부/주변부 분포와 함께 인과적 해석(causal interpretations)을 사용합니다.
Zhao et al (2020): 변화하는 분포에 불변(invariant)하는 데이터 표현을 학습할 수 있는 비지도 도메인 적응(unsupervised domain adaption) 기법입니다.

모니터링과 관측 가능성 (Monitoring and Observability)

모니터링과 관측 가능성은 밀접하게 연관되어 있지만 엄밀히 말하면 약간 다릅니다.

모니터링(Monitoring): 무언가 잘못되었을 때 언제 잘못되었는지 판단하는 데 도움이 되도록 추적기, 로그, 지표 등을 배치하는 것입니다.
관측 가능성(Observability): 무엇이 잘못되었는지 파악할 수 있게 해주는 도구 및 설정(즉, 시스템의 내부 작동을 관찰)을 의미합니다.

소프트웨어 관련 지표

ML 시스템 역시 소프트웨어 시스템이므로, 모든 소프트웨어 관측 가능성 관행이 적용됩니다. 추적하고자 하는 것들의 유형은 다음과 같습니다.

운영 지표:
- 시스템이 실행 중인 네트워크의 지표: 네트워크 지연 시간, 네트워크 부하.
- 머신 상태 지표: CPU/GPU 사용률, 메모리 사용률.
- 애플리케이션 지표: 엔드포인트 부하, 요청 성공률, 엔드포인트 지연 시간.

소프트웨어 시스템은 또한 가용성을 보장하기 위해 서비스 수준 목표(SLOs) 또는 서비스 수준 계약(SLAs)을 자주 사용합니다. SLO 및 SLA를 만들 때, "시스템은 99.99%의 시간 동안 '가동(up)'되어야 한다"에서 "가동"이 무엇을 의미하는지 파악해야 합니다.

예를 들어, "가동"을 중앙값(median) 지연 시간 ≤ 200ms 및 p99 ≤ 2초로 정의할 수 있습니다. 그런 다음 한 달 동안 시스템이 이 제한을 준수하지 않은 시간을 측정하여 가동 시간 백분율을 계산합니다.

ML 고유 지표

시스템이 가동 중이고 작동 중일 수 있지만, 예측이 엉망이라면 문제가 있는 것입니다. 이것이 ML 고유 지표가 필요한 부분입니다.

일반적으로 모니터링하고자 하는 네 가지 사항이 있습니다. 1. 정확도, 2. 예측, 3. 피처, 4. 원시 입력.

이 4가지 수준 각각에서 모니터링하는 데에는 본질적인 트레이드오프가 있습니다.

정확도 관련 지표와 같은 더 높은 수준의 지표는 이해하기 쉽고 비즈니스 수준 지표와 관련짓기 쉽습니다. 그러나, 이는 복잡한 변환 사슬의 출력을 나타내므로, 무언가 잘못되었다는 것을 알더라도 왜 그런지 반드시 알지는 못합니다.
원시 입력 모니터링과 같은 더 낮은 수준의 지표는 비즈니스와 거리가 멀고 설정하기 더 어렵습니다. 그러나, 특정 원시 입력 지표가 잘못되었다면, 즉시 문제가 무엇인지 알 수 있습니다.

ML 관측 가능성의 또 다른 핵심적이고 종종 간과되는 부분은 모델 해석 가능성(model interpretability)입니다. 모델의 정확도가 저하되거나 예측에 이상(anomaly)이 나타날 때, 모델이 어떻게 작동하고 어떤 피처가 예측에 가장 많이 기여하는지 알면 무엇이 잘못되었는지 식별하고 수정하는 데 많은 도움이 됩니다.

이는 모델 선택 시 해석 가능성 vs 성능 트레이드오프로 돌아가게 합니다. 더 해석하기 쉬운 모델이 모니터링하기 더 쉽습니다.

정확도 관련 지표 모니터링

정확도 관련 지표 설정은 문제에 자연 레이블 (또는 자연 레이블의 더 약한 프록시(proxy))이 있는지에 의존하기 때문에 항상 가능한 것은 아닙니다.

시스템이 예측에 대해 어떤 유형의 사용자 피드백이든(클릭, 숨기기, 구매, 좋아요(upvote), 싫어요(downvote), 즐겨찾기, 북마크, 공유 등) 받는다면, 반드시 그것을 추적해야 합니다. 피드백이 자연 레이블을 직접 추론하는 데 사용될 수 없더라도, ML 모델 성능의 변화를 감지하는 데 사용될 수 있습니다. 또한 2차 효과(second order effects)도 명심하고 추적하십시오. 예를 들어, 추천의 클릭률(click-through rate)은 동일하게 유지되지만 완료율(completion rate)이 떨어진다면, 이는 문제가 있다는 신호일 수 있습니다.

가능하다면, 사용자의 피드백을 수집하도록 시스템을 엔지니어링하십시오. 예를 들어, "좋아요 / 싫어요" 또는 "도움 안 됨" 버튼을 추가하십시오. 이는 정확도 관련 지표 이상으로 사용될 수 있습니다. 예를 들어, 향후 이터레이션을 위해 어떤 샘플을 사람의 레이블링(human annotation)을 위해 보내야 하는지 알리는 데 사용될 수 있습니다.

알림: 정확도 모니터링은 데이터 분포 변화를 모니터링하는 가장 강력하고 실용적인 방법입니다.

예측(Predictions) 모니터링

예측은 기업이 모니터링하는 가장 일반적인 산출물입니다. 왜냐하면 캡처하기 쉽고, 시각화하기 쉬우며, 저차원(low-dimensionality)이기 때문입니다. 이 마지막 속성은 요약 통계를 계산하고 해석하기 쉽게 만듭니다.

분포 변화에 대해 예측을 모니터링하십시오. 모델의 가중치가 변하지 않았는데 예측 분포가 변했다면, 이는 일반적으로 기본 입력 분포의 변화를 나타냅니다.

예측은 저차원이므로, 분포 변화를 평가하기 위해 2-표본 검정(two-sample tests)을 계산하기 쉽습니다.

이상(anomalies)에 대해 예측을 모니터링하십시오. 예측이 갑자기 10분 동안 계속 False를 예측하는 것과 같이 급격한 행동 변화를 보인다면, ML 사고(incident)가 발생했을 수 있습니다. 이상에 대한 예측 모니터링은 "자연 레이블"이 사용 가능해지기까지 며칠이 걸릴 수 있으므로, 이상에 대한 정확도 모니터링보다 훨씬 즉각적입니다.

피처(Features) 모니터링

원시 입력 데이터 모니터링과 비교할 때, 피처 모니터링은 피처에 미리 정의된 스키마가 있고 정보가 일반적으로 더 "작업하기 쉬운 상태" (예: 이미지의 실제 픽셀 VS 이미지에서 파생된 피처)에 있기 때문에 매력적입니다.

피처에서 모니터링할 수 있는 것들:

피처가 예상된 스키마를 따르는지.
- 피처 값이 정규 표현식(regular expression)을 만족하는지.
- 피처 값이 미리 정의된 집합에 속하는지.
피처의 min, max 또는 median이 허용 가능한 범위 내에 있는지.
피처 A의 값이 항상 피처 B보다 큰지.

이러한 유형의 피처 모니터링을 수행하는 두 가지 일반적인 라이브러리는 Great Expectations와 Deequ입니다.

피처 모니터링을 사용하여 입력 데이터 드리프트 P(X)를 탐지할 수도 있습니다. 통계적 검정을 사용할 계획이라면, 피처는 고차원인 경향이 있으므로 차원 축소(dimensionality reduction)를 수행해야 합니다. 그러나 차원 축소는 통계적 검정의 효과를 감소시킵니다.

피처 모니터링의 과제

피처 모니터링은 가능하지만 어렵기도 합니다. 다음은 마주칠 수 있는 몇 가지 과제입니다. 자신에게 맞는 피처 모니터링 수준을 선택할 수 있도록 이를 고려하십시오.

각각 수백 개의 피처를 가진 수백 개의 모델이 있을 수 있습니다. 이는 파악해야 할 지표가 매우 많다는 뜻입니다.
실제로, 피처 모니터링은 성능 저하 탐지보다는 디버깅 목적에 더 유용한 경향이 있습니다. 모든 피처에 자동화된 드리프트 알림을 추가하면 많은 오탐(false positives)이 발생할 것입니다.
피처 추출은 다단계 및 다중 도구 프로세스(예: Snowflake → Pandas → Numpy)일 수 있습니다. 이는 무엇을 모니터링할지 선택하기 더 어렵게 만듭니다.
피처 스키마는 시간이 지남에 따라 변경될 수 있으며, 기대치 모니터(expectation monitors)도 최신 상태로 유지해야 합니다.

원시 입력(Raw inputs) 모니터링

이론적으로, 원시 입력을 모니터링하면 입력의 "가장 순수한" 버전을 모니터링하는 이점을 얻을 수 있으며, 따라서 입력 분포가 정말로 변했는지 또는 다운스트림에 버그가 도입되었는지 알 수 있습니다.

실제로, 원시 입력을 모니터링하는 것은 정말 어렵고 때로는 불가능합니다.

원시 입력은 작업하기 매우 어려운 형식일 수 있습니다. 예: 대용량 자산, 다양한 형식의 이미지 / 비디오 / 오디오 파일, 암호화된 PII(개인 식별 정보) 데이터.
ML 엔지니어는 개인 정보 보호상의 이유로 원시 입력에 접근조차 못할 수 있으며, 데이터가 이미 부분적으로 처리된 데이터 웨어하우스에서 데이터를 쿼리하도록 요청받을 수 있습니다.

위의 이유로, 원시 입력 모니터링은 일반적으로 데이터 플랫폼 팀의 책임인 경우가 많습니다.

모니터링 도구 상자

구현 관점에서, 모니터링의 기둥은 지표, 로그, 추적(traces)입니다. 그러나, "시스템을 모니터링하는 사용자" 관점에서 모니터링의 실제 기둥은 로그, 대시보드, 알림입니다.

로그 및 분산 추적 (distributed tracing)

분산 시스템(distributed system)을 가지고 있다면 (아마도 그럴 것입니다), 로그에 분산 추적이 있는지 확인하십시오.
모든 이벤트 메타데이터를 로그와 함께 기록하십시오: 언제 발생하는지, 어떤 서비스에서 발생하는지, 호출된 함수, 관련된 사용자 등. 로그 태깅(Log tagging)을 활용하는 것이 좋습니다.
로그를 분석하고 싶다면, 수십억 개의 로그를 분석하는 것은 무익합니다. 기업들은 대규모 로그 분석을 수행하기 위해 ML을 사용합니다.
로그 기술의 소비자로서 다음 사항을 명심하십시오:
- 로그 제공업체(Log providers)는 특정 속성에 대해 주기적으로 로그를 처리할 수 있습니다. 이는 특정 문제를 주기적으로만 발견할 수 있음을 의미합니다.
- 문제가 발생하는 즉시 발견하려면, 로그 제공업체가 Flink와 같은 스트림 처리 기술을 사용해야 합니다.

대시보드

대시보드는 모니터링에 중요한 지표의 유용한 시각화를 보여줍니다.
대시보드는 엔지니어가 아닌 사람들도 모니터링에 접근할 수 있게 합니다. 모니터링은 개발자만을 위한 것이 아닙니다. 엔지니어가 아닌 이해관계자들도 프로덕션 환경에 ML 제품을 둠으로써 발생하는 영향 중 자신의 몫을 모니터링해야 합니다.
대시보드에 지표가 과도하게 많은 것은 비생산적입니다. 이는 대시보드 노후화(dashboard rot)로 알려져 있습니다.
- 대시보드에 포함할 지표를 까다롭게 선택하고, 더 높은 수준의 지표를 계산하여 더 낮은 수준의 지표를 추상화하십시오.

알림 (Alerts)

알림은 특정 알림 정책(alert policy)이 위반될 때 알림 채널(notification channel)로 전송되는 자동 경고입니다.
알림 정책: 알림을 트리거하기 위해 위반되어야 하는 조건과 해당 위반과 관련된 심각도(severity).
알림 채널: 누가 알림을 받아야 하는가? 이는 일반적으로 이메일, Slack 채널 및/또는 온콜(on-call) 명단입니다.
알림 설명: 알림을 받는 사람에게 무엇을 해야 하는지 포함된 런북(runbook)을 연결해두는 것이 좋습니다.
알림 피로(Alert fatigue)는 실질적인 문제입니다.
- 알림이 너무 많으면 사람들이 둔감해지고 중요한 알림이 무시될 것입니다.
- 조치 가능한(actionable) 알림만 생성하십시오.
- 알림 조건 위반의 결과가 다음 근무일까지 기다릴 수 없는 경우에만 근무 시간 외에 사람들에게 알림을 보내십시오.

9장 - 지속적인 학습 및 프로덕션 환경에서의 테스트

이 장에서는 지속적인 학습과 프로덕션 환경에서의 모델 테스트라는 두 가지 크고 연관된 주제를 다룹니다. 이 두 주제를 함께 배우는 목표는 자동화되고, 안전하며, 효율적인 방식으로 프로덕션 환경에서 모델을 업데이트하는 방법을 배우는 것입니다.

이 장 전체는 8장에서 간략히 논의된 데이터 분포 변화를 수정하는 가장 일반적인 기법인 주기적인 모델 재학습에 대한 심층 탐구의 연속입니다.

지속적인 학습

지속적인 학습(Continual Learning)은 새로운 데이터가 사용 가능해짐에 따라 모델을 업데이트하는 개념입니다. 이는 모델이 현재의 데이터 분포를 따라잡도록 만듭니다.

모델이 업데이트되면, 맹목적으로 프로덕션에 릴리즈(release)할 수 없습니다. 안전하고 현재 프로덕션 모델보다 낫다는 것을 보장하기 위해 테스트되어야 합니다. 여기서 다음 섹션인 "프로덕션 환경에서의 모델 테스트"가 필요합니다.

지속적인 학습은 종종 오해를 받습니다.

지속적인 학습은 모든 새로운 데이터 포인트가 사용 가능해질 때마다 모델의 증분 업데이트(incremental update)를 허용하는 특별한 종류의 ML 알고리즘을 의미하지 않습니다. 이러한 특별한 알고리즘 클래스의 예로는 순차적 베이지안 업데이트(sequential bayesian updating)와 KNN 분류기가 있습니다. 이 알고리즘 클래스는 작으며 때때로 "온라인 학습 알고리즘"이라고도 합니다.
- 지속적인 학습의 개념은 특별한 클래스뿐만 아니라 모든 지도 ML 알고리즘에 적용될 수 있습니다.
지속적인 학습은 새로운 데이터 샘플이 생길 때마다 재학습 작업을 시작하는 것을 의미하지 않습니다. 사실 이는 위험합니다. 왜냐하면 신경망이 치명적 망각(catastrophic forgetting)에 취약해지기 때문입니다.
- 지속적인 학습을 사용하는 대부분의 회사는 마이크로 배치(micro-batches) (예: 512 또는 1024 샘플마다)로 모델을 업데이트합니다. 최적의 샘플 수는 작업에 따라 다릅니다.

지속적인 학습은 표면적으로는 데이터 사이언티스트의 작업처럼 보일 수 있습니다. 그러나 이를 가능하게 하려면 많은 인프라 작업이 필요한 경우가 많습니다.

왜 지속적인 학습인가?

근본적인 이유는 모델이 데이터 분포 변화를 따라잡도록 돕기 위해서입니다. 변화하는 분포에 빠르게 적응하는 것이 중요한 일부 유스케이스가 있습니다. 다음은 몇 가지 예입니다.

예상치 못하고 빠른 변화가 발생할 수 있는 유스케이스: 차량 공유와 같은 유스케이스가 이에 해당합니다. 예를 들어, 무작위 월요일의 무작위 지역에서 콘서트가 있을 수 있으며, "월요일 가격 책정 ML 모델"이 이를 잘 처리하지 못할 수 있습니다.
특정 이벤트에 대한 학습 데이터를 얻을 수 없는 유스케이스: 이에 대한 예는 블랙 프라이데이나 이전에 시도된 적 없는 다른 세일 이벤트의 이커머스(e-commerce) 모델입니다. 블랙 프라이데이의 사용자 행동을 예측하기 위한 과거 데이터를 수집하기는 매우 어렵기 때문에, 모델은 하루 종일 적응해야 합니다.
콜드 스타트 문제(cold start problem)에 민감한 유스케이스: 이 문제는 모델이 과거 데이터가 없거나 (데이터가 오래된) 신규 (또는 로그아웃한) 사용자에 대해 예측을 해야 할 때 발생합니다. 해당 사용자로부터 일부 데이터를 얻는 즉시 모델을 적응시키지 않으면, 그 사용자에게 관련성 있는 것을 추천할 수 없을 것입니다.

개념: 상태 비저장(Stateless) 재학습 VS 상태 저장(Stateful) 학습

상태 비저장(Stateless) 재학습

매번 무작위로 초기화된 가중치와 더 최신 데이터를 사용하여 모델을 처음부터 재학습합니다.

이전 모델 버전 학습에 사용된 데이터와 일부 겹칠 수 있습니다.
대부분의 회사는 상태 비저장 재학습을 사용하여 지속적인 학습을 시작합니다.

상태 저장(Stateful) 학습 (일명 파인 튜닝, 증분 학습)

이전 학습 라운드의 가중치로 모델을 초기화하고 새로운 미관측(unseen) 데이터를 사용하여 학습을 계속합니다.

훨씬 적은 데이터로 모델을 업데이트할 수 있습니다.
모델이 더 빨리 수렴하고 더 적은 컴퓨팅 파워를 사용하게 합니다.
- 일부 회사는 컴퓨팅 파워 45% 감소를 보고했습니다.
이론적으로는 데이터가 학습에 사용되면 (그리고 약간의 안전 여유 시간을 남겨두고) 데이터를 전혀 저장하지 않아도 되게 만듭니다. 이는 이론적으로 데이터 프라이버시 우려를 제거합니다.
- 실제로는 대부분의 회사가 "모든 것을 추적하자"는 관행을 가지고 있으며 더 이상 필요하지 않은 데이터라도 버리는 것을 꺼립니다.
때때로 모델을 재보정(re-calibrate)하기 위해 대량의 데이터로 상태 비저장 재학습을 실행해야 합니다.
인프라가 올바르게 설정되면, 상태 비저장에서 상태 저장 재학습으로 변경하는 것은 버튼 하나 누르는 것만으로 가능해집니다.
모델 이터레이션(iteration) vs 데이터 이터레이션: 상태 저장 학습은 주로 기존의 고정된 모델 아키텍처에 새로운 데이터를 통합하는 데 사용됩니다(즉, 데이터 이터레이션). 모델의 피처나 아키텍처를 변경하려면, 먼저 상태 비저장 재학습을 수행해야 합니다.
- 한 모델 아키텍처에서 새 아키텍처로 가중치를 이전하는 방법에 대한 몇 가지 연구(Net2Net knowledge transfer, model surgery)가 있었습니다. 아직 업계에서 이러한 기법의 채택은 거의 없습니다.

개념: 로그 앤 웨이트(log and wait)를 통한 피처 재사용

피처는 추론을 위해 계산됩니다. 일부 회사는 모든 데이터 샘플에 대해 계산된 피처를 저장하여, 지속적인 학습 훈련에 재사용함으로써 일부 계산을 절약할 수 있도록 합니다. 이는 로그 앤 웨이트(log and wait)로 알려져 있습니다.

이는 또한 피처 모니터링을 보조하는 데 사용됩니다.
2023년 1월 기준, 로그 앤 웨이트는 아직 대중적이지 않지만 주목받고 있습니다.

지속적인 학습의 과제

지속적인 학습은 업계에서 큰 성공을 거두며 적용되어 왔습니다. 그러나 기업이 극복해야 할 세 가지 주요 과제가 있습니다.

평가 과제

지속적인 학습을 관행으로 채택하는 것은 치명적인 모델 실패의 위험을 수반합니다. 모델 업데이트가 빈번할수록 모델이 실패할 기회도 많아집니다.

또한, 지속적인 학습은 모델을 오염시키기 위한 조직적인 적대적 공격(adversarial attacks)의 문을 엽니다.

이는 모델을 더 넓은 대상에게 롤아웃(roll out)하기 전에 모델을 테스트하는 것이 중요함을 의미합니다.

테스트에는 시간이 걸리므로, 이는 달성할 수 있는 가장 빠른 모델 업데이트 빈도에 또 다른 제한 요인이 될 수 있습니다.
예: 사기 탐지를 위한 새 모델은 신뢰할 수 있는 수준으로 평가되기에 충분한 트래픽을 얻는 데 약 2주가 걸릴 수 있습니다.

데이터 스케일링 과제

피처 계산에는 일반적으로 스케일링이 필요합니다. 스케일링은 min, max, average, variance와 같은 전역 데이터 통계에 접근해야 합니다.

상태 저장 학습을 사용하는 경우, 전역 통계는 모델 학습에 이미 사용된 이전 데이터와 모델을 새로 고치는 데 사용되는 새 데이터를 모두 고려해야 합니다. 이러한 시나리오에서 전역 통계를 추적하는 것은 까다로울 수 있습니다.

이를 수행하는 일반적인 기법은 (학습 시점에 전체 데이터셋을 로드하여 계산하는 대신) 새로운 데이터를 관찰함에 따라 증분적으로(incrementally) 이러한 통계를 계산하거나 근사하는 것입니다.

이 기법의 예는 "스트림에서의 최적 분위수 근사(Optimal Quantile Approximation in Streams)"입니다.
Sklearn의 StandardScaler에는 실행 통계(running statistics)와 함께 피처 스케일러를 사용할 수 있게 하는 partial_fit이 있습니다. 그러나 내장된 메서드는 느리고 광범위한 실행 통계를 지원하지 않습니다.

알고리즘 과제

이 과제는 특정 유형의 알고리즘을 사용하고 정말 빠르게(예: 매시간) 업데이트하려 할 때 나타납니다.

해당 알고리즘은 설계상 학습을 위해 전체 데이터셋에 접근해야 하는 알고리즘입니다. 예를 들어, 행렬 기반, 차원 축소 기반, 트리 기반 모델입니다. 이러한 유형의 모델은 신경망이나 다른 가중치 기반 모델처럼 새로운 데이터로 증분적으로 학습될 수 없습니다.

예: PCA 차원 축소는 증분적으로 수행할 수 없습니다. 전체 데이터셋이 필요합니다.

이 과제는 알고리즘이 전체 데이터셋을 처리할 때까지 기다릴 여유가 없기 때문에 정말 빠르게 업데이트해야 할 때만 발생합니다.

영향을 받는 모델 중 일부는 증분적으로 학습되도록 설계된 변형(variants)이 있지만, 이러한 알고리즘의 채택은 널리 퍼져 있지 않습니다. 한 예로 Hoeffding Trees와 그 하위 변형들이 있습니다.

지속적인 학습의 4단계

회사는 보통 4단계를 거쳐 지속적인 학습으로 이동합니다.

1단계: 수동, 상태 비저장 재학습

모델은 (1) 모델 성능이 너무 저하되어 이득보다 해가 더 많고, (2) 팀이 업데이트할 시간이 있을 때라는 두 가지 조건이 충족될 때만 재학습됩니다.

2단계: 고정된 일정의 자동화된 상태 비저장 재학습

이 단계는 일반적으로 도메인의 주요 모델이 개발되어 더 이상 새 모델을 만드는 것이 우선순위가 아니고, 기존 모델을 유지하고 개선하는 것이 우선순위가 될 때 발생합니다. 1단계에 머무르는 고통이 무시하기엔 너무 커졌습니다.

이 단계의 재학습 빈도는 일반적으로 "직감(gut feeling)"에 기반합니다.

1단계와 2단계 사이의 변곡점(inflection point)은 대개 누군가가 상태 비저장 재학습을 주기적으로 실행하는 스크립트를 작성할 때입니다. 이 스크립트를 작성하는 것은 모델 재학습을 위해 조정되어야 하는 의존성이 얼마나 많으냐에 따라 매우 쉽거나 매우 어려울 수 있습니다.

이 스크립트의 상위 수준 단계는 다음과 같습니다.

데이터 가져오기(Pull data).
필요시 데이터 다운샘플링 또는 업샘플링.
피처 추출.
학습 데이터를 생성하기 위해 레이블 처리 및/또는 주석(annotate) 달기.
학습 프로세스 시작.
새 모델 평가.
배포.

이 스크립트를 구현하려면 두 가지 추가 인프라가 필요합니다.

스케줄러.
모델을 재현하는 데 필요한 모든 아티팩트(artefacts)를 자동으로 버전 관리하고 저장하는 모델 스토어. 성숙한 모델 스토어로는 AWS SageMaker와 Databrick's MLFlow가 있습니다.

3단계: 고정된 일정의 자동화된 상태 저장 학습

이를 달성하려면 스크립트를 재구성하고 데이터 및 모델 계보(lineage)를 추적할 방법이 필요합니다. 간단한 모델 계보 버전 관리 예:

V1 vs V2는 동일한 문제에 대한 두 가지 다른 모델 아키텍처입니다.
V1.2 vs V2.3은 모델 아키텍처 V1이 전체 상태 비저장 재학습의 2번째 이터레이션(iteration)에 있고 V2는 3번째 이터레이션에 있음을 의미합니다.
V1.2.12 vs V2.3.43은 V1.2에 대해 12번의 상태 저장 학습이, V2.3에 대해 43번의 상태 저장 학습이 수행되었음을 의미합니다.
모델이 어떻게 발전하고 있는지 전체 그림을 추적하려면 아마도 데이터 버전 관리와 같은 다른 버전 관리 기법과 함께 이를 사용해야 할 것입니다.
저자에 따르면, 그녀는 이런 유형의 모델 계보 기능을 갖춘 모델 스토어를 알지 못하므로, 회사들은 자체적으로(in-house) 구축합니다.
특정 시점에는 프로덕션 환경에서의 모델 테스트에 설명된 구성을 통해 여러 모델이 동시에 프로덕션 환경에서 실행되고 있을 것입니다.

4단계: 지속적인 학습

이 단계에서는 이전 단계의 고정된 일정 부분이 재학습 트리거 메커니즘으로 대체됩니다. 트리거는 다음과 같을 수 있습니다.

시간 기반
성능 기반: 예: 성능이 x% 아래로 떨어졌을 때.
- 프로덕션 환경에서 항상 정확도를 직접 측정할 수는 없으므로, 더 약한 프록시(proxy)를 사용해야 할 수도 있습니다.
볼륨 기반: 레이블이 지정된 총 데이터 양이 5% 증가했을 때.
드리프트(Drift) 기반: 예: "주요" 데이터 분포 변화가 감지되었을 때.
- 드리프트 기반 트리거를 사용하는 것의 어려운 점은, 이전 장에서 언급했듯이, 데이터 분포 변화는 모델 성능을 저하시킬 때만 문제가 된다는 것입니다. 언제 그런 일이 발생하는지 알기 까다로울 수 있습니다.

모델을 얼마나 자주 업데이트해야 하는가

이 질문에 답하려면 먼저 최신 데이터로 모델을 업데이트할 때 얻는 이득이 무엇인지 이해하고 결정해야 합니다. 이득이 클수록 더 자주 재학습해야 합니다.

데이터 신선도의 가치 측정

최신 데이터의 가치를 정량화하는 한 가지 방법은 동일한 모델 아키텍처를 세 가지 다른 기간의 데이터로 학습시킨 다음, 각 모델을 현재의 레이블이 지정된 데이터로 테스트하는 것입니다 (이미지 참조).

3개월 동안 모델을 방치(stale)하면 현재 테스트 데이터 정확도에서 10%의 차이가 발생하고, 10%가 허용 불가능하다면 3개월보다 더 짧은 주기로 재학습해야 합니다.

이미지는 몇 달 단위의 데이터셋 예시를 보여주지만, 유스케이스에 따라 몇 주, 며칠 또는 몇 시간과 같이 더 세분화된 시간 단위(time buckets)가 필요할 수 있습니다.

언제 모델 이터레이션(iteration)을 해야 하는가?

지금까지 이 장의 대부분은 새 데이터로 모델을 업데이트하는 것(즉, 데이터 이터레이션)을 참조했습니다. 그러나 실제로는 때때로 모델의 아키텍처를 변경해야 할 수도 있습니다(즉, 모델 이터레이션). 언제 모델 이터레이션을 고려해야 하고 언제 하지 말아야 하는지에 대한 몇 가지 지침은 다음과 같습니다.

데이터 이터레이션 재학습 트리거를 계속 줄여도 큰 이득이 없다면, 아마도 더 나은 모델을 찾는 데 투자해야 할 때입니다 (물론 비즈니스에 필요하다면).
100배의 컴퓨팅 파워가 필요한 더 큰 모델 아키텍처로 변경하는 것이 1%의 성능 향상을 주지만, 재학습 트리거를 3시간으로 줄이는 것이 1배의 컴퓨팅 파워로 1%의 성능 향상을 준다면, 모델 이터레이션보다 데이터 이터레이션을 선호하십시오.
"언제 모델 이터레이션을 하고 언제 데이터 이터레이션을 하는가"라는 질문은 아직 모든 작업에 대해 연구가 잘 답변하지 못했습니다. 특정 작업에 대해 실험을 실행하여 언제를 선택할지 알아내야 합니다.

프로덕션 환경에서의 모델 테스트

모델을 널리 사용하기 전에 충분히 테스트하려면 사전 배포 오프라인 평가와 프로덕션 환경에서의 테스트가 모두 필요합니다. 오프라인 평가만으로는 충분하지 않습니다.

이상적으로는 각 팀이 모델 평가 방법에 대한 명확한 파이프라인(어떤 테스트를 실행할지, 누가 실행할지, 모델을 다음 단계로 승격시키기 위한 임계값은 무엇인지)을 마련해야 합니다. 이러한 평가 파이프라인은 새로운 모델 업데이트가 있을 때 자동화되고 시작되는 것이 가장 좋습니다. 단계별 승격은 소프트웨어 엔지니어링에서 CI/CD를 평가하는 방식과 유사하게 검토되어야 합니다.

사전 배포 오프라인 평가

6장 → 모델 오프라인 평가에서 모델 선택에 사용할 수 있는 몇 가지 평가 기법을 논의했습니다. 동일한 평가를 사전 배포 오프라인 평가에 재사용할 수 있습니다.
가장 일반적인 두 가지는 (1) 베이스라인과 비교하기 위해 테스트 스플릿(test split)을 사용하는 것과 (2) 백테스트(backtests)를 실행하는 것입니다.
- 테스트 스플릿은 여러 모델을 비교할 수 있는 신뢰할 수 있는 벤치마크를 제공하기 위해 일반적으로 정적(static)입니다. 이는 또한 정적인 오래된 테스트 스플릿에서의 좋은 성능이 프로덕션의 현재 데이터 분포 조건 하에서의 좋은 성능을 보장하지는 않는다는 것을 의미합니다.
- 백테스팅은 모델이 학습 중에 보지 못한 가장 최신의 레이블이 지정된 데이터를 사용하여 성능을 테스트하는 아이디어입니다 (예: 지난 하루의 데이터로 학습했다면, 지난 1시간의 데이터를 사용하여 백테스트).
  - 백테스트를 아직 소개하지 않았습니다. 이 요약에서 처음 언급하는 것입니다.
  - 백테스팅만으로 프로덕션 환경에서의 테스트를 피할 수 있다고 생각하기 쉽지만, 그렇지 않습니다. 프로덕션 성능은 레이블 관련 성능 그 이상입니다. 모델이 광범위하게 롤아웃(rollout)되기에 안전한지 확인하려면 여전히 지연 시간, 모델에 대한 사용자 행동, 시스템 통합 정확성 같은 것들을 관찰해야 합니다.

프로덕션 환경에서의 테스트 전략

섀도우 배포 (Shadow Deployment)

직관: 기존 챔피언 모델과 병렬로 챌린저 모델을 배포합니다. 모든 들어오는 요청을 두 모델 모두에 보내지만, 챔피언 모델의 추론만 사용자에게 제공합니다. 두 모델의 예측을 모두 로그로 남긴 다음 비교합니다.
장점
- 모델을 배포하는 가장 안전한 방법입니다. 새 모델에 버그가 있더라도 예측이 제공되지 않습니다.
- 개념적으로 간단합니다.
- 모든 모델이 전체 트래픽을 받기 때문에, 실험이 통계적 유의성(statistical significance)에 도달하기에 충분한 데이터를 다른 모든 전략보다 빠르게 수집할 것입니다.
단점
- 모델 성능 측정이 사용자가 예측과 어떻게 상호작용하는지 관찰하는 데 의존할 때 이 기법을 사용할 수 없습니다. 예를 들어, 섀도우 추천 모델의 예측은 제공되지 않으므로 사용자가 클릭했을지 여부를 알 수 없습니다.
- 예측 수가 두 배가 되어 필요한 컴퓨팅 수가 두 배로 들기 때문에 실행 비용이 비쌉니다.
- 온라인 예측 모드 중 하나를 사용하여 추론이 발생하는 경우 다음과 같은 엣지 케이스(edge cases)를 처리하는 방법을 찾아야 합니다.
  - 섀도우 모델이 기본 모델보다 예측을 제공하는 데 훨씬 더 오래 걸린다면 어떻게 할 것인가?
  - 섀도우 모델이 실패하면 기본 모델도 실패해야 하는가, 아닌가?

A/B 테스팅

직관: 챔피언 모델(모델 A)과 함께 챌린저 모델을 배포하고 트래픽의 일부 비율을 챌린저(모델 B)로 라우팅합니다. 챌린저의 예측은 사용자에게 보여집니다. 두 모델의 모니터링 및 예측 분석을 사용하여 챌린저의 성능이 챔피언보다 통계적으로 더 나은지 확인합니다.
- 일부 유스케이스는 트래픽을 나누고 동시에 여러 모델을 갖는 아이디어와 잘 맞지 않습니다. 이 경우 A/B 테스팅은 시간적 분할(temporal splits)을 수행하여 수행할 수 있습니다. 하루는 모델 A, 다음 날은 모델 B.
- 트래픽 분할은 진정한 무작위 실험(randomized experiment)이어야 합니다. 데스크톱 사용자는 A를 받고 모바일 사용자는 B를 받는 것처럼 누가 모델 A를 받고 누가 모델 B를 받는지에 선택 편향(selection bias)이 개입되면, 결론은 부정확할 것입니다.
- 실험은 차이에 대한 충분한 통계적 신뢰(statistical confidence)를 달성하기에 충분한 샘플을 수집할 만큼 오래 실행되어야 합니다.
- 통계적 유의성이 모든 것을 보장하지는 않습니다 (그래서 신뢰도(confidence)가 있는 것입니다). A와 B 사이에 통계적 차이가 없다면, 아마도 둘 중 하나를 사용해도 될 것입니다.
- 원한다면 A/B/C/D 테스트를 실행하는 것을 막는 것은 없습니다.
장점:
- 예측이 사용자에게 제공되므로, 이 기법을 사용하면 사용자가 다른 모델에 어떻게 반응하는지 완전히 파악할 수 있습니다.
- A/B 테스팅은 이해하기 간단하며 주변에 많은 라이브러리와 문서가 있습니다.
- 요청당 하나의 예측만 있으므로 실행 비용이 저렴합니다.
- 온라인 예측 모드를 위해 추론 요청을 병렬화할 때 발생하는 엣지 케이스를 고려할 필요가 없습니다 (섀도우 배포의 단점 참조).
단점:
- 섀도우 배포보다 덜 안전합니다. 실제 트래픽을 통과시킬 것이므로 모델이 심각하게 실패하지 않을 것이라는 더 강력한 오프라인 평가 보증을 원할 것입니다.
- 더 많은 위험을 감수(B 모델로 더 많은 트래픽 라우팅)하는 것과 분석을 더 빨리 만들기 위해 충분한 샘플을 얻는 것 사이에서 본질적인 선택을 해야 합니다.

카나리 릴리즈 (Canary Release)

직관: 챌린저와 챔피언을 나란히 배포하되, 챌린저가 트래픽을 받지 않는 상태에서 시작합니다. 챔피언에서 챌린저(일명 카나리(canary))로 천천히 트래픽을 이동시킵니다. 챌린저의 성능 지표를 모니터링하고, 좋아 보이면 챌린저가 모든 트래픽을 받을 때까지 계속 진행합니다.
- 카나리 릴리즈는 성능 차이를 엄격하게 측정하기 위해 A/B 테스팅과 함께 사용될 수 있습니다.
- 카나리 릴리즈는 성능 차이를 눈대중으로(eyeball) 확인하는 "YOLO 모드"로 실행될 수도 있습니다.
- 카나리 릴리즈의 다른 버전은 챌린저 모델을 먼저 더 작은 시장에 릴리즈한 다음, 모든 것이 좋아 보이면 모든 시장으로 승격시키는 것일 수 있습니다.
- 챌린저 모델에 문제가 생기기 시작하면 트래픽을 다시 챔피언으로 라우팅합니다.
장점:
- 이해하기 쉽습니다.
- 회사에 이미 일부 피처 플래깅(feature flagging) 인프라가 있다면 구현하기 가장 간단한 전략입니다.
- 챌린저 예측이 제공되므로, 성능을 파악하기 위해 사용자 상호작용이 필요한 모델과 함께 사용할 수 있습니다.
- 섀도우 배포에 비해 실행 비용이 저렴합니다. 요청당 하나의 추론.
- A/B 테스팅과 함께 사용하면, 각 모델이 받는 트래픽 양을 동적으로 변경할 수 있습니다.
단점:
- 성능 차이를 결정하는 데 엄격하지 않을 가능성을 엽니다.
- 릴리즈가 신중하게 감독되지 않으면 사고가 발생할 수 있습니다. 이는 틀림없이 가장 덜 안전한 옵션이지만 롤백(rollback)하기는 매우 쉽습니다.

인터리빙 실험 (Interleaving Experiments)

직관: A/B 테스팅에서는 단일 사용자가 모델 A 또는 모델 B의 예측을 받습니다. 인터리빙에서는 단일 사용자가 모델 A와 모델 B의 예측을 혼합하여(interleaved) 받습니다. 그런 다음 각 모델의 예측에 대한 사용자 선호도(예: 사용자가 모델 B의 추천을 더 많이 클릭함)를 측정하여 각 모델이 어떻게 수행되는지 추적합니다.
- 추천 작업은 인터리빙의 일반적인 유스케이스입니다. 모든 작업이 이 전략에 적합한 것은 아닙니다.
- 모델 A의 예측을 항상 상단에 두는 것처럼 모델에게 불공평한 사용자 선호도 이점을 주는 것을 피해야 합니다. 첫 번째 슬롯이 모델 A에서 나올 확률과 모델 B에서 나올 확률은 동일해야 합니다. 나머지 위치는 팀 드래프팅 방법(team-drafting method)을 사용하여 채울 수 있습니다 (이미지 참조).
장점:
- Netflix는 실험적으로 인터리빙이 전통적인 A/B 테스팅에 비해 상당히 적은 샘플 크기로 최고의 모델을 신뢰성 있게 식별한다는 것을 발견했습니다.
  - 이는 주로 두 모델이 모두 전체 트래픽을 받기 때문입니다.
- 섀도우 배포와 달리, 이 전략은 (예측이 제공되기 때문에) 사용자가 예측에 어떻게 반응하는지 파악할 수 있게 합니다.
단점:
- 구현이 A/B 테스팅보다 더 복잡합니다.
  - 인터리빙된 모델 중 하나가 응답하는 데 너무 오래 걸리거나 실패할 경우 어떻게 할지에 대한 엣지 케이스를 걱정해야 합니다.
- 모든 요청이 여러 모델로부터 예측을 받기 때문에 필요한 컴퓨팅 파워가 두 배가 됩니다.
- 모든 유형의 작업에 사용될 수 없습니다. 예를 들어, 랭킹/추천 작업에는 작동하지만 회귀 작업에는 의미가 없습니다.
- 많은 수의 챌린저 모델로 쉽게 확장되지 않습니다. 2-3개의 인터리빙된 모델이 최적점(sweet spot)인 것 같습니다.

밴딧 (Bandits)

직관: 밴딧은 각 모델 변형(variant)의 현재 성능을 추적하고, 모든 요청에 대해 지금까지 가장 성능이 좋은 모델을 사용할지 (즉, 현재 지식 활용(exploit)) 또는 다른 모델 중 하나를 시도하여 그들에 대한 더 많은 정보를 얻을지 (즉, 다른 모델 중 하나가 실제로는 더 나은지 탐색(explore)) 동적으로 결정하는 알고리즘입니다.
- 밴딧은 어떤 모델을 사용할지 결정하는 데 기회비용(opportunity cost)이라는 또 다른 개념을 추가합니다.
- 밴딧은 모든 경우에 적용될 수 없습니다. 밴딧이 적용 가능하려면 유스케이스에 다음이 필요합니다.
  - 온라인 예측을 수행해야 합니다. 배치 오프라인 예측은 밴딧과 호환되지 않습니다.
  - 예측이 좋았는지 나빴는지 판단하기 위한 짧은 피드백 루프와, 그 피드백을 밴딧 알고리즘에 전파하여 각 모델의 보상(payoff)을 업데이트하는 메커니즘이 필요합니다.
- 많은 밴딧 알고리즘이 있습니다. 가장 간단한 것은 입실론-그리디(epsilon-greedy)라고 불립니다. 가장 강력하고 인기 있는 두 가지는 톰슨 샘플링(Thompson Sampling)과 신뢰 상한(Upper Confidence Bound, UCB)입니다.
장점:
- 밴딧은 어떤 모델이 더 나은지 결정하는 데 A/B 테스팅보다 훨씬 적은 데이터가 필요합니다. 책에 나온 한 예는 A/B 테스팅으로 95% 신뢰도를 얻는 데 63만 샘플이 필요한 반면, 밴딧은 1만 2천 샘플이 필요했습니다.
- 밴딧은 데이터를 더 효율적으로 사용하면서 동시에 기회비용을 최소화합니다. 많은 경우 밴딧은 최적(optimal)으로 간주됩니다.
- A/B 테스팅에 비해 밴딧은 더 안전합니다. 왜냐하면 모델이 정말 나쁘다면 알고리즘이 해당 모델을 덜 자주 선택할 것이기 때문입니다. 또한 수렴이 더 빠르므로 나쁜 챌린저를 빨리 제거할 수 있습니다.
단점:
- 다른 모든 전략에 비해, 밴딧은 피드백을 알고리즘에 지속적으로 전파해야 하므로 구현하기가 훨씬 더 어렵습니다.
- 밴딧은 특정 유스케이스에만 사용될 수 있습니다 (위 참조).
- 챌린저가 실제 트래픽을 받기 때문에 섀도우 배포만큼 안전하지는 않습니다.

참고: 추천 알고리즘 개선을 위한 컨텍스추얼 밴딧 사용

이 하위 섹션은 프로덕션 환경에서의 모델 테스트와 관련이 없지만, 밴딧에 대해 이야기하고 있으므로 언급하겠습니다.

컨텍스추얼 밴딧(contextual bandits)이라는 밴딧 알고리즘의 하위 범주가 있습니다. 컨텍스추얼 밴딧은 "활용 vs 탐색" 결정을 내릴 때 각 옵션의 과거 "보상"만 고려하는 것이 아니라, 추가 정보 (즉, 컨텍스트(context))도 고려합니다. 이 컨텍스트는 사용자에 대한 정보, 시간/연도에 대한 정보, 제품에 대한 정보일 수 있습니다. 보상과 컨텍스트를 모두 사용하여, 컨텍스추얼 밴딧은 "개인화된" 탐색 vs 활용 결정을 내릴 수 있습니다.

컨텍스추얼 밴딧은 추천 작업에서 큰 성공을 거두며 성능을 크게 향상시켰습니다. 예를 들어, 이커머스 환경에서 당신이 구매할 가능성이 높은 제품(활용)을 보여줄지, 아니면 당신이 과거에 본 적 없는 다른 제품(탐색)을 보여줄지 결정하는 데 사용될 수 있습니다. 이 결정은 당신에 대한 정보와 잠재적 제품에 대한 정보를 컨텍스트로 고려하여 당신을 위해 내려집니다.

컨텍스추얼 밴딧은 학습 데이터가 필요 없는 추천 알고리즘으로 "단독(solo)" 사용될 수 있습니다. 컨텍스트와 보상 없이 시작하여, 무엇을 추천할지 추측하고 진행하면서 학습합니다.

또한 딥 러닝과 결합하여 추천 성능을 향상시킬 수도 있습니다. 관심이 있다면 Twitter 엔지니어링의 이 논문을 참조하십시오.

컨텍스추얼 밴딧은 퇴행성 피드백 루프와 싸우는 데 사용될 수 있습니다.

컨텍스추얼 밴딧의 주요 단점은 "일반" 밴딧보다 구현하기가 훨씬 더 어렵다는 것입니다. 구현이 기본 ML 모델의 아키텍처(예: 트리 vs 신경망)에 의존하므로 일반화 가능성이 떨어집니다.

10장 - ML Ops를 위한 인프라와 도구

ML 시스템을 위해 무엇을 해야 하는지 정확히 알지만, 인프라가 지원하지 않아서 실행하지 못하는 데이터 사이언티스트를 만나는 것은 드문 일이 아닙니다.

인프라가 올바르게 설정되면 프로세스를 자동화하여 전문 지식과 엔지니어링 시간의 필요성을 줄이는 데 도움이 될 수 있습니다.
잘못 설정된 인프라는 우리에게 고통을 주며 교체 비용이 많이 듭니다.

ML 인프라는 4개의 레이어로 그룹화할 수 있습니다. 이 장에서는 각 레이어를 다룰 것입니다. 이 장은 이해를 돕기 위해 "평균적인 개발자에게 익숙한" 순서대로 레이어를 제시합니다.

이 장은 "직접 구축(build) vs 구매(buy)" 결정을 탐색하는 방법에 대한 논의로 마무리됩니다.

인프라 요구 사항은 회사 규모를 따른다

팀에 필요한 인프라는 애플리케이션이 얼마나 전문화되어 있는지에 따라 다릅니다.

스펙트럼의 한쪽 끝에는 분기별 보고서나 내년 예측과 같은 임시 비즈니스 분석(ad-hoc business analytics)을 위해 ML을 사용하는 회사가 있습니다.
- 이들의 작업 결과는 보통 보고서나 슬라이드 쇼로 들어갑니다.
- 이 회사들은 Jupyter Notebook만 있으면 되므로 인프라에 투자할 필요가 없습니다.
다른 쪽 끝에는 ML 사용 규모의 한계를 밀어붙이는 회사들이 있습니다.
- 이들은 극도로 낮은 지연 시간 요구 사항을 가지거나, 하루에 페타바이트(petabytes)의 새로운 데이터를 처리하거나, 시간당 수백만 건의 예측을 수행해야 합니다.
- 이들은 Tesla, Google, Facebook과 같은 회사들입니다.
- 이 회사들은 보통 자체 전문 인프라를 개발해야 합니다. 이 전문 인프라의 일부는 나중에 공개적으로 사용 가능하게 될 수 있습니다 (Google이 GCP를 통해 그랬던 것처럼).
대다수의 회사는 스펙트럼의 중간에 있습니다. 이들은 "합리적인 규모"로 "일반적인 애플리케이션"에 ML을 사용하는 회사들입니다.
- "일반적인 애플리케이션": 사기 탐지, 이탈 예측, 추천 시스템 등.
- "합리적인 규모":
  - 페타바이트가 아닌 기가바이트(gigabytes) 및 테라바이트(terabytes) 단위의 데이터로 작업합니다.
  - 데이터 사이언스 팀이 수천 명이 아닌 10명에서 수백 명의 엔지니어를 보유하고 있습니다.
- 이 회사들은 점점 더 표준화되고 상용화된 일반화된 ML 인프라를 사용하여 이점을 얻을 것입니다.
- 이 장은 이와 같은 회사들의 인프라 요구 사항에 초점을 맞춥니다.

레이어 1: 스토리지와 컴퓨트

스토리지 레이어

데이터 저장 비용이 매우 저렴해져서 대부분의 회사는 보유한 모든 데이터를 그냥 저장합니다. 스토리지 레이어에 대한 모든 세부 사항은 3장 - 데이터 엔지니어링 기초에서 논의했으므로 여기서 반복하지 않겠습니다.

이 섹션의 나머지 부분은 컴퓨트 레이어에 초점을 맞출 것입니다.

컴퓨트 레이어

컴퓨트 레이어의 두 가지 일반적인 용도가 있습니다.
- 작업(jobs) 실행. 이 경우, 컴퓨트 유닛은 작업 기간 동안만 존재할 수 있습니다.
- Jupyter 노트북 또는 기타 탐색적 작업 실행. 이 경우, 컴퓨트 유닛은 오래 지속되는(long-lived) 경향이 있습니다. 이는 보통 가상 머신(virtual machines) 또는 인스턴스(instances)라고 불립니다.
가장 일반적으로, 회사의 컴퓨트 레이어는 AWS Elastic Cloud나 GCP와 같은 관리형 클라우드 서비스입니다.
가장 최소한의 컴퓨트 레이어는 모든 계산을 실행하는 단일 CPU 또는 단일 GPU일 것입니다.
- 일부 컴퓨트 레이어 프레임워크는 코어(cores)의 개념을 추상화하고 다른 계산 단위를 사용합니다. 예를 들어 Spark 및 Ray와 같은 엔진은 "작업(job)"을 단위로 사용합니다. Kubernetes는 "파드(pod)"를 가장 작은 배포 가능 단위로 사용합니다.
컴퓨트 유닛은 일반적으로 메모리와 연산 속도라는 두 가지 지표로 특징지어집니다.
- 메모리: 작업을 실행하려면, 유닛은 먼저 필요한 데이터를 메모리에 로드해야 합니다. 총 메모리는 유닛이 처리할 수 있는 데이터 양을 결정합니다. 데이터를 메모리로 로드하고 언로드하는 속도 또한 총 작업 시간에 상당한 영향을 미칠 수 있습니다. 이것이 클라우드 제공업체가 "고대역폭 메모리(high bandwidth memory)"를 갖춘 특별한 인스턴스를 제공하는 이유입니다.
- 연산 속도: 이를 측정하는 정확한 방법은 논쟁의 여지가 있으며 클라우드 제공업체 간에 통일되어 있지 않습니다.
  - 가장 일반적인 지표는 FLOPS (초당 부동 소수점 연산)입니다.
    - 단일 "부동 소수점 연산"으로 간주되어야 하는 것이 모호하기 때문에 논쟁의 여지가 있습니다.
    - 또한, 유닛의 정격 FLOPs의 100% 활용률(utilisation rate)을 달성하는 것은 거의 불가능합니다. 50%도 좋다고 간주될 수 있습니다. 활용률은 데이터를 메모리로 로드하는 속도에 따라 달라집니다.
  - MLPerf는 하드웨어 성능을 측정하는 인기 있는 벤치마크입니다. 이는 하드웨어가 일반적인 ML 작업을 학습하는 데 걸리는 시간을 측정합니다.

퍼블릭 클라우드 VS 사설 데이터 센터

ML 유스케이스는 ML 워크로드가 폭발적(bursty)이기 때문에 퍼블릭 클라우드를 사용하는 경향이 있습니다. 즉, 작업 폭증 기간에만 컴퓨트 비용을 지불하고 리소스를 해제할 수 있습니다.
- 클라우드 컴퓨트는 탄력적이지만 마법은 아닙니다. 실제로는 무한한 컴퓨팅 파워를 가지고 있지 않으며 대부분의 클라우드 제공업체는 계정에 제한을 둡니다. 종종 그들에게 연락하여 이러한 제한을 늘릴 수 있습니다.
초기에는 퍼블릭 클라우드를 사용하는 것이 자체 스토리지 및 컴퓨트 레이어를 구매하는 것보다 회사에 더 높은 수익을 주는 경향이 있습니다. 그러나 회사가 성장함에 따라 이는 덜 정당화됩니다.
- a16z 연구에 따르면 클라우드 지출은 대기업의 수익 비용(cost of revenue)의 약 50%를 차지합니다.
- 높은 클라우드 비용으로 인해 대기업들은 워크로드를 자체 데이터 센터로 다시 옮기기 시작했습니다. 이를 클라우드 본국 회귀(cloud repatriation)라고 합니다.
  - 클라우드로 들어가는 것은 쉽지만 벗어나는 것은 매우 어렵습니다. 클라우드 본국 회귀는 하드웨어와 엔지니어링 노력 모두에 상당한 초기 투자가 필요합니다.

멀티 클라우드 전략

멀티 클라우드는 각 제공업체의 최고 및 가장 비용 효율적인 기술을 활용하고 벤더 종속(vendor lock-in)을 피하기 위해 여러 클라우드 제공업체를 사용하도록 시스템을 설계하는 것을 의미합니다.
- ML 워크로드의 일반적인 패턴은 GCP나 Azure에서 학습을 수행한 다음 AWS에서 배포하는 것입니다. 이것이 반드시 좋은 패턴은 아닙니다.
멀티 클라우드 전략에서 온전함(sanity)을 유지하는 것은 매우 매우 어렵습니다.
- 클라우드 간에 데이터를 이동하고 워크로드를 오케스트레이션(orchestrate)하는 것은 매우 어렵습니다.
종종 조직의 다른 부분이 독립적으로 운영되고 다른 선택을 하기 때문에 멀티 클라우드는 우연히 발생합니다.
- 또한 ML 회사가 특정 클라우드에 이해관계가 있는 당사자로부터 투자를 받고 해당 다른 클라우드를 채택하도록 "강요"받아 멀티 클라우드 구성이 되는 것도 드문 일이 아닙니다.

레이어 4: 개발 환경

개발 환경(dev environment)은 업계에서 심각하게 과소평가되고 투자가 부족합니다. 일부 전문가는 인프라의 한 부분만 잘 설정할 시간이 있다면, DEV 환경을 선택해야 한다고 제안합니다. 여기서 이루어진 모든 개선 사항은 직접적으로 생산성 향상으로 이어지기 때문입니다.

DEV 환경 전체는 IDE, 노트북, 버전 관리 및 실험 추적 도구, CI/CD 도구로 구성됩니다. 2023년 현재, 회사들은 여전히 강력한 업계 표준 없이 이러한 각각에 대해 임시방편(ad-hoc)의 도구 세트를 사용하고 있습니다.

이 섹션에서는 개발 환경의 3가지 측면을 다룹니다.

개발 환경의 표준화.
DEV 환경에서의 노트북 지원
개발과 프로덕션 간의 격차를 줄이기 위한 컨테이너 기술 사용.

개발 환경의 표준화

개발 환경은 전사적이 아니라도 최소한 팀 전체적으로 표준화되어야 합니다. 비표준화(Non-standardisation)는 여러 이점이 있습니다.

서로 다른 사람들이 자신의 머신에 다른 의존성(dependencies)을 설치함으로써 발생하는 문제를 디버깅하는 데 시간을 낭비하고 싶지 않을 것입니다.
서로 다른 설정을 가진 사람들이 환경에 무엇이 잘못되었는지 파악하는 것을 돕는 IT 지원 업무를 떠맡고 싶지 않을 것입니다.
신규 직원에게 표준 개발 환경으로 가능한 한 "플러그 앤 플레이(plug and play)" 경험을 제공하고 싶을 것입니다.

도구와 패키지는 표준화되어야 한다는 데 일반적으로 동의합니다. 그러나 많은 회사가 IDE 자체를 표준화하는 것을 주저합니다. IDE 설정은 매우 개인적인 경향이 있으며 엔지니어는 자신의 작업 스타일에 맞게 IDE를 커스터마이징(customising)하는 데 많은 노력을 기울입니다.

이러한 상충되는 생각에 대한 가장 인기 있는 해결책은 도구와 패키지 표준화를 처리하기 위해 클라우드 개발 환경을 사용하고, 개발자가 클라우드 개발 환경에 연결되어 있는 한 선호하는 IDE를 무엇이든 사용하도록 허용하는 것입니다.

로컬에서 클라우드 개발 환경으로 이동하기

클라우드 개발 환경의 일반적인 제공업체는 Github Codespaces, AWS EC2 인스턴스, GCP 인스턴스입니다.
로컬 개발 환경과 비교할 때, 클라우드 개발 환경은 다음과 같은 이점이 있습니다.
1. 비용 관리: 개발자가 비싼 VM을 계속 실행해 두면 어쩌나 걱정할 수 있습니다. 일부 VM은 매우 저렴하며 대부분의 클라우드 제공업체는 VM이 30분 동안 사용되지 않으면 "자동 꺼짐" 옵션을 허용합니다. 또한 일부 제공업체는 예산 상한선 및 비용 모니터링을 허용합니다.
2. 적절한 작업에 적절한 크기의 VM 확보: 클라우드 인스턴스를 개발용으로만 사용하고 코드를 다른 컴퓨팅 리소스로 "작업화된(jobified)" 방식으로 실행할 것이라면, 코딩을 지원하기 위한 아주 작은 인스턴스만 사용할 수 있습니다. 무거운 탐색적 분석을 수행하는 경우 더 강력한 머신을 스핀업(spin up)할 수 있습니다. 자세한 내용은 "컴퓨트 레이어"를 참조하십시오.
3. IT 지원이 쉬워집니다. 문제 해결(troubleshoot)을 위한 개발 환경 설정이 하나뿐입니다.
4. 클라우드 개발은 원격 근무에 편리합니다.
5. 클라우드 환경은 보안에 도움이 됩니다. 직원 노트북을 도난당하면 접근 권한을 취소하면 됩니다.
6. 이미 프로덕션을 위해 클라우드를 사용하고 있다면, 개발을 위해 클라우드를 사용하는 것이 자연스럽게 다가올 것이며 개발과 프로덕션 간의 격차를 줄이는 데 도움이 될 것입니다.
클라우드 개발 환경으로 이동하려면 약간의 초기 투자가 필요하며, 클라우드에 대한 보안 연결 설정, 보안 규정 준수 또는 낭비적인 클라우드 사용 방지를 포함하여 데이터 사이언티스트에게 클라우드 위생(hygiene)에 대해 교육해야 할 수도 있습니다. 그러나 장기적으로는 비용을 절약할 수 있습니다.
위에서 언급한 비용 문제나 클라우드 제공업체로 데이터를 이동하는 것에 대한 제한 때문에 모든 회사가 클라우드 개발 환경으로 이동할 수 있는 것은 아닙니다.

IDE와 클라우드 개발 환경

이에 접근하는 세 가지 일반적인 방법이 있습니다.

VIM과 같은 터미널 기반 IDE를 클라우드 머신에 직접 설치합니다.
1. 장점: 모든 것이 클라우드 머신에 있어 네트워킹과 SSH 연결을 다룰 필요가 없습니다.
2. 단점: 터미널 기반 IDE는 강력하게 만들려면 많은 커스터마이징이 필요합니다. 이 커스터마이징은 개발자가 파악해야 할 몫이며 한 VM에서 다른 VM으로 이전하기(port) 어려울 수 있습니다.
클라우드 머신에 연결된 브라우저 기반 IDE를 사용합니다. 일부 인기 있는 옵션은 AWS의 Cloud9과 브라우저의 VSCode입니다.
1. 장점:
  1. 옵션 1에 비해 브라우저 기반 IDE는 더 강력하고 사용자 친화적이며 기본적으로(out of the box) 더 적은 커스터마이징이 필요합니다.
  2. AWS Cloud 9이나 Github Codespaces와 같이 클라우드 제공업체가 제공하는 브라우저 기반 옵션은 "그냥 작동합니다".
2. 단점:
  1. 브라우저 IDE는 네이티브 IDE보다 덜 강력한 경향이 있습니다.
  2. 느리고 지연되는(laggy) 느낌이 드는 경향이 있습니다.
  3. 커스터마이징할 경우, 한 VM에서 다른 VM으로의 이전성(portability)도 문제입니다.
로컬 IDE를 사용하고 SSH를 사용하여 클라우드 VM에 연결합니다. 이 하이브리드 구성에서 로컬 IDE는 "에디터 UI"만 제공하지만 코드는 여전히 VM에서 실행됩니다. 로컬 VSCode는 원격 머신 연결 기능이 내장되어 있어 이 옵션으로 매우 인기가 있습니다.
1. 장점:
  1. 코드 스캔 및 디버깅을 포함하여 IntelliJ와 같은 IDE의 모든 기능을 얻을 수 있습니다.
  2. IDE 커스터마이징이 로컬 컴퓨터에 남아 있으며 "컴퓨트" VM을 교체해도 잃어버리지 않습니다.
2. 단점:
  1. 설정하기 까다로울 수 있습니다. 특히 VM 네트워크가 매우 잠겨(locked down) 있는 경우 더욱 그렇습니다.
  2. 원격 개발 기능이 내장된 IDE로 제한됩니다.

DEV 환경에서의 노트북 지원

ML 엔지니어링은 소프트웨어 엔지니어링의 일반적인 "프로덕션에서 실행할 코드 빌드" 운영 모드 외에, 데이터 및 학습 결과의 탐색적 분석이라는 추가적인 "운영 모드"를 가집니다. 이 분석은 일반적으로 프로덕션에서 실행될 의도가 아닌 일회성 노트북(once-off notebooks)을 사용하여 임시방편(ad-hoc)으로 수행되는 경향이 있습니다.

참고: 노트북을 프로덕션 코드의 주요 수단(vessel)으로 사용하는 회사가 많습니다. 이 관행은 빠르게 시작하게 해줄 것이며 비즈니스 분석을 위해 ML을 사용한다면 필요한 전부일 수 있습니다. 그러나 이 관행은 유스케이스가 더 복잡해짐에 따라 확장되지(scale) 않습니다.

이러한 추가적인 "운영 모드"를 감안할 때, 개발 환경에서 원활한 노트북 지원은 필수입니다. 특히 다음 사항을 고려할 수 있습니다.

개발 환경에서 작업을 수행하기에 충분한 인프라 리소스와 필요한 모든 의존성에 접근할 수 있는 원격 머신에서 노트북을 쉽게 시작할 수 있어야 합니다.
개발 환경에서 데이터 사이언티스트가 이미 실행된 노트북을 쉽게 공유하고 협업할 수 있어야 합니다.
- 노트북 버전 관리는 여전히 번거로운(clunky) 프로세스입니다. 노트북을 Git에 체크인할 수 있지만, 얻게 될 diff는 따라가기 어려운 모호한 JSON입니다.

노트북 개발 경험을 더 좋게 만들기 위해 사용할 수 있는 몇 가지 도구는 다음과 같습니다.

Papermill: 다른 파라미터 세트로 여러 노트북을 스폰(spawn)할 때 사용합니다. 예를 들어, 다른 파라미터 세트로 다른 실험을 실행하고 동시에 실행하려 할 때입니다.
Commuter: 조직 내에서 노트북을 보고, 찾고, 공유하기 위한 노트북 허브입니다.
Nbdev: 소프트웨어 패키지와 기술 문서를 모두 노트북 한 곳에서 작성, 테스트, 문서화 및 배포합니다.

개발에서 프로덕션으로: 컨테이너

여러 엔지니어를 위해 개발 환경을 복제하고 여러 작업 워커(worker)나 VM을 위해 프로덕션 환경을 복제하는 것은 근본적으로 동일한 과제를 안고 있습니다. 새 인스턴스를 설정할 때마다 코드를 실행할 수 있도록 해당 인스턴스에 모든 의존성, 도구 및 구성을 설정해야 합니다.

컨테이너 기술은 이 문제를 자동화된 방식으로 해결하는 열쇠입니다. 현재 가장 인기 있는 컨테이너 기술은 Docker입니다. 다음은 익숙해져야 할 핵심 Docker 개념 중 일부입니다.

Dockerfile: 코드가 실행될 수 있는 환경을 재생성하는 방법에 대한 단계별 파일입니다. 이 패키지를 설치하고, 이 사전 학습된 모델을 다운로드하고, 이 환경 변수를 설정하고, 이 폴더로 이동하십시오. Dockerfile을 빌드(Building)하면 Docker 이미지가 생성됩니다. Dockerfile을 틀(mold)을 구성하는 레시피로, Docker 이미지를 그 틀 자체로 생각할 수 있습니다.
1. Dockerfile 지침을 처음부터 시작할 필요는 없습니다. 다른 Docker 이미지와 동일한 지점에서 시작하도록 지정한 다음, 그 위에 몇 가지 사용자 지정 지침만 추가할 수 있습니다. 예를 들어, NVIDIA는 GPU에서 Tensorflow를 실행하도록 이미 구성된 Docker 이미지를 제공합니다. Dockerfile에서 해당 이미지로 시작하도록 지정한 다음, 사용자 지정 Tensorflow 코드를 설정할 수 있습니다.
2. Dockerfile을 Docker 이미지로 바꾸는 핵심 명령어는 docker build입니다.
Docker 이미지: Docker 컨테이너의 실행 준비가 된 전구체(precursor)입니다. 이 아티팩트(artefact)는 실행에 필요한 모든 것을 내부에 패키징합니다 (예: 모든 의존성과 코드를 이미 다운로드하고 설치함). Docker 이미지는 Dockerfile build의 스냅샷입니다. Docker 이미지는 여러 Docker 컨테이너를 스핀업(spin up)하기 위한 "틀"로 사용됩니다.
Docker 컨테이너: Docker 이미지의 "실행 중인 인스턴스"입니다.
1. 이미지를 수동으로 실행하는 명령어는 docker run입니다.
2. 머신에서 실행 중인 컨테이너를 확인하려면 docker ps를 사용합니다.
컨테이너 레지스트리(Container registry): Docker 이미지를 위한 Github와 같습니다. 컨테이너 레지스트리는 Docker 이미지를 다른 사람들과 공유하는 데 사용됩니다. 레지스트리는 (Docker Hub처럼) 공개적이거나, (GCP 또는 AWS 컨테이너 레지스트리처럼) 조직 내부 사람들만 사용할 수 있도록 비공개(private)일 수 있습니다.
1. 레지스트리에서 컴퓨터로 이미지를 가져오려면(pull) docker pull을 사용합니다.
Docker Compose는 다중 컨테이너 Docker 애플리케이션을 정의하고 실행하기 위한 도구입니다. docker-compose.yml이라는 단일 파일에 애플리케이션을 구성하는 서비스를 정의한 다음, 단일 명령어로 모든 서비스를 시작, 모니터링 및 중지할 수 있습니다. Docker Compose는 단일 호스트(SINGLE HOST)에서 컨테이너를 관리할 수 있는 경량 컨테이너 오케스트레이터입니다.
Kubernetes / K8s: 여러 호스트(MULTIPLE HOSTS)에서 실행되는 다중 컨테이너 애플리케이션을 관리하기 위한 또 다른 오케스트레이터입니다. K8s는 또한 그들 사이의 네트워킹 관리도 처리합니다.
1. K8s는 가장 데이터 사이언스 친화적인 도구는 아니며, 데이터 사이언스 워크로드를 K8s에서 벗어나게 하는 방법에 대한 논의가 진행 중입니다.

단일 ML 프로젝트에 여러 유형의 Docker 이미지가 필요한 것은 일반적입니다. 예를 들어, 학습 데이터에서 피처를 추출하는 것과 같은 CPU 전용 작업을 위해 빌드된 이미지 하나와, 학습을 위한 모든 GPU 구성을 갖춘 두 번째 이미지가 있을 수 있습니다.

레이어: 2 리소스 관리

몇 가지 용어: Cron, 스케줄러, 오케스트레이터

Cron: 고정된 시간에 반복적인 작업을 실행합니다. Cron은 하나의 작업만 처리할 수 있으므로 서로 의존하는 작업 시퀀스를 처리할 수 없습니다.
스케줄러(Schedulers): 의존성을 처리할 수 있습니다.
- 실행할 단계의 DAG 워크플로우를 입력으로 받습니다. 일부 단계는 조건부일 수 있습니다.
- 예약된 간격으로 워크플로우를 시작하거나 이벤트가 발생할 때 워크플로우를 트리거할 수 있습니다.
- 스케줄러를 사용하면 단계가 실패하거나 성공할 때 수행할 작업을 지정할 수 있습니다. 예를 들어, 포기하기 전에 5번 재시도합니다.
- 스케줄러 스크립트는 종종 워크플로우 실행에 필요한 인프라에 대한 파라미터를 입력으로 받습니다. 이들은 워크플로우에 어떤 리소스가 필요한지는 알지만, 어디서 가져와야 하는지는 모릅니다.
- 거의 모든 수의 동시 머신과 워크플로우를 관리할 수 있어야 하므로, 범용 스케줄러를 직접 설계하는 것은 어렵습니다.
- 스케줄러는 일반적으로 작업(jobs)과 단계(steps)를 주요 추상화(abstractions)로 다룹니다.
오케스트레이터(Orchestrators): 워크플로우를 실행하기 위해 리소스를 어디서 가져올지에 관심이 있습니다. 이들은 머신, 인스턴스, 클러스터, 복제(replication)와 같이 "작업" 수준보다 낮은 추상화를 다룹니다.
- 오케스트레이터는 스케줄러가 풀(pool)에 사용 가능한 인스턴스보다 더 많은 작업을 가지고 있음을 감지하면, 풀의 인스턴스 수를 늘릴 수 있습니다.
- 가장 잘 알려진 오케스트레이터는 Kubernetes입니다.
- 스케줄러는 일반적으로 오케스트레이터 위에서 실행됩니다.
워크플로우 관리자(Workflow managers): 일반적으로 스케줄러 + 오케스트레이터를 포함하는 더 높은 수준의 도구입니다. 데이터 사이언티스트는 보통 이들과 상호작용합니다.
- 이들도 작업의 DAG를 입력으로 받습니다.

데이터 사이언스를 위한 워크플로우 관리

2023년 2월 기준, 데이터 사이언스를 위한 5가지 가장 일반적인 워크플로우 관리자는 Airflow, Argo, Prefect, Kubeflow, Metaflow입니다. 이 섹션에서는 각각을 간략하게 살펴보겠습니다.

Airflow

가장 초기의 워크플로우 관리자 중 하나입니다.

장점
- 다양한 클라우드 제공업체, 데이터베이스, 스토리지 옵션 등과 작업할 수 있는 광범위한 오퍼레이터(operators) 라이브러리를 보유하고 있습니다.
- YAML이나 다른 선언적 언어를 사용하는 대신 Python을 사용하여 워크플로우를 구성합니다.
단점
- Airflow는 모놀리식(Monolithic)이어서 전체 워크플로우를 하나의 컨테이너에 패키징합니다. 워크플로우의 2가지 다른 단계가 다른 인프라 요구 사항을 가질 경우, 이들을 위한 별도의 컨테이너를 만드는 것이 간단하지(non-trivial) 않습니다.
- Airflow에서는 DAG에 파라미터를 전달할 수 없습니다.
- Airflow의 DAG는 필요에 따라 런타임에 새 단계를 자동으로 생성할 수 없습니다. 정적(static)입니다.

Prefect

Airflow의 단점에 대한 대응으로 나왔습니다.

장점
- Prefect의 워크플로우에 파라미터를 전달할 수 있습니다.
- 런타임에 동적으로 단계를 생성할 수 있습니다.
- 또한 DAG를 생성하기 위해 Python을 사용합니다.
단점
- Prefect에서 다른 컨테이너를 사용하여 다른 단계를 실행하는 것은 쉽지 않습니다. 할 수는 있지만, 약간의 번거로움이 따릅니다.

Argo

또한 Airflow의 단점에 대한 대응으로 나왔습니다.

장점
- Argo 워크플로우의 모든 단계는 자체 컨테이너에서 실행될 수 있습니다.
단점
- 워크플로우가 YAML로 정의되어 지저분해집니다.
- Argo는 일반적으로 프로덕션에서만 사용 가능한 Kubernetes에서만 실행됩니다. 워크플로우를 로컬에서 테스트하려면 랩톱에 minikube를 설정해야 하는데, 이는 어렵습니다.

Kubeflow와 Metaflow

둘 다 개발 환경과 프로덕션 환경 모두에서 워크플로우를 실행하는 데 도움을 주는 것을 목표로 합니다. 책에서는 더 이상 언급되지 않습니다.

레이어 3: ML 플랫폼

"ML 플랫폼" 공간은 상당히 최근에 생겼으며 2020년대 초반부터 빠르게 성장해 왔습니다. ML 플랫폼을 구성하는 요소의 정의는 회사마다 크게 다릅니다. 그러나 넓게 말하면, ML 플랫폼은 여러 팀이 프로덕션 환경에서 ML 모델을 배포하고 실행하는 데 사용할 수 있는 공유 도구 세트입니다.

이 장에서는 ML 플랫폼의 가장 일반적인 3가지 구성 요소인 모델 호스팅 서비스, 모델 스토어, 피처 스토어를 포함합니다.

모델 호스팅 서비스

모델 호스팅 서비스는 모델과 의존성을 프로덕션으로 푸시(push)하고 모델을 엔드포인트(endpoints)로 노출합니다.
- 이를 지칭하는 다른 방식: 모델 배포 서비스, 모델 서빙 서비스.
이는 ML 플랫폼 구성 요소 중 가장 성숙한 것입니다.
모든 주요 클라우드 제공업체는 모델 호스팅 서비스를 제공합니다. 이를 제공하는 많은 스타트업도 있습니다.
- 예: AWS Sagemaker, GCP Vertex AI, Azure ML, MLflow Models, Seldon, Cortex, Ray Serve
모델 호스팅 서비스를 선택할 때, 온라인 예측과 배치 예측 모두를 수행하기 쉬운지 고려하십시오.
- 모든 도구가 온라인 예측은 수행할 것입니다. 배치 예측이 까다로운 부분입니다.
- 배치 예측은 하드웨어 가속을 사용하여 더 많은 처리량(throughput)을 얻기 위해 온라인 요청을 함께 배치(batching)하는 것과 같지 않습니다.
  - 이상적으로는 모델 호스팅 서비스가 배치 예측과 배치 처리된 온라인 요청(batched online requests)을 모두 수행할 수 있어야 합니다.
- 일부 회사는 온라인 예측과 배치 예측을 위해 서로 다른 모델 호스팅 서비스를 사용합니다. 예를 들어, 온라인에는 Seldon, 배치에는 Databricks를 사용합니다.
모델 호스팅 서비스를 선택할 때, 해당 서비스가 관심 있는 유형의 프로덕션 테스트를 쉽게 실행할 수 있게 하는지 고려하십시오. 프로덕션 테스트에 대한 자세한 내용은 9장을 참조하십시오.

모델 스토어

모델 스토어는 표면적으로 간단해 보이기 때문에 종종 간과됩니다. 모델 블롭(blob)을 S3에 업로드하면 끝입니다.

실제로는, 모델을 운영, 디버깅, 유지보수하는 데 도움이 되도록 블롭과 함께 더 많은 정보를 저장해야 할 것입니다. 다음은 저장할 수 있는 몇 가지 요소입니다. 더 포괄적인 목록은 모델 카드 섹션에서 찾을 수 있습니다.

모델 정의: 레이어 및 손실 함수와 같은 모델 아키텍처에 대한 세부 정보.
모델 파라미터: 모델의 실제 가중치. 대부분의 프레임워크는 모델 정의와 가중치를 함께 저장할 수 있게 합니다.
피처화 및 예측 함수: 예측을 위한 피처를 추출하고 예측을 처리하는 함수.
의존성: 모델 실행에 필요한 의존성 목록. 이는 보통 이미지에 패키징됩니다.
데이터: 모델 학습에 사용된 데이터에 대한 포인터. DVC를 사용한다면, 데이터를 생성한 커밋(commit)에 대한 포인터.
모델 생성 코드: 사용된 하이퍼파라미터를 포함하여 모델 생성에 사용된 체크인된 코드에 대한 포인터. 일부 회사는 체크인되지 않은 노트북을 사용하여 모델을 학습시킵니다. 이는 좋은 관행이 아닙니다.
실험 아티팩트: 실험 추적 및 버전 관리 참조.
태그: 모델 검색에 도움이 되는 태그. 예: 모델을 소유한 팀 또는 사람, 해결하는 비즈니스 문제.

대부분의 회사는 이러한 아티팩트의 하위 집합을 저장하지만 전부는 아니며, 다른 장소에 저장할 수 있습니다.

2023년 기준 MLFlow가 가장 인기 있는 모델 스토어이지만, 표준이 되기까지는 아직 갈 길이 멉니다. 이러한 표준의 부재로 인해, 많은 회사가 자체적으로 구축합니다.

피처 스토어

"피처 스토어"는 사람마다 다른 것을 의미하는 함축적인(loaded) 용어입니다. 핵심적으로, 피처 스토어가 해결을 돕는 3가지 주요 문제가 있습니다. 1) 피처 관리, 2) 피처 계산, 3) 피처 일관성.

피처 관리

피처가 여러 모델에 유용한 경우가 많습니다.
피처 스토어는 팀이 피처를 공유하고 발견하며, 해당 피처를 볼 수 있는 사람의 역할과 공유 설정을 관리하는 데 도움이 될 수 있습니다.

피처 계산

일부 피처는 계산 비용이 비쌀 수 있으므로, 한 번 계산하고 일정 기간 캐시(cache)하는 것이 합리적입니다. 이는 단일 피처가 여러 모델에서 사용될 때 특히 유용합니다.
피처 스토어는 피처 계산 수행과 이 계산 결과 저장을 모두 도울 수 있습니다. 이런 점에서 피처 스토어는 피처를 위한 데이터 웨어하우스처럼 작동합니다.

피처 일관성

학습을 위해 과거 데이터에서 피처를 계산하는 파이프라인과 추론을 위해 피처를 추출하는 파이프라인이 서로 다른 것은 버그의 일반적인 원인입니다 (자세한 내용은 7장 참조).
최신 피처 스토어를 사용하면 배치 피처와 스트리밍 피처 모두에 대한 로직을 통합하여, 학습 시점과 추론 시점의 피처 간 일관성을 보장할 수 있습니다.

벤더 예시

피처 스토어는 2020년에 주목받기 시작했으므로, 여러 벤더가 제공하는 것에는 상당한 차이가 있습니다.

2022년 7월 기준, 가장 인기 있는 오픈 소스 피처 스토어는 Feast입니다. 그러나 Feast는 스트리밍 피처가 아닌 배치 피처에 중점을 둡니다.
Tecton은 배치 및 스트리밍 피처를 모두 처리한다고 약속하는 완전 관리형 피처 스토어이지만, 현재 사용자 확보(traction)가 느리고 깊은 통합(deep integration)을 필요로 합니다.
Sagemaker와 Databricks도 피처 스토어에 대한 자체적인 해석을 제공합니다.

빌드(Build) vs 바이(Buy) 결정

빌드 vs 바이 파노라마의 두 가지 극단은 다음과 같습니다.

모든 ML 유스케이스를 엔드투엔드(end-to-end)로 ML 애플리케이션을 제공하는 제공업체에 아웃소싱하는 회사. 이 경우, 그들이 필요로 하는 유일한 인프라는 애플리케이션에서 벤더로 데이터를 이동하고 그 반대로 이동하는 것입니다.
다른 극단에는 어떤 유형의 관리형 서비스도 사용할 수 없게 하는 매우 민감한 데이터를 다루는 회사가 있습니다. 이런 회사에서는 모든 인프라를 사내(in-house)에 구축하고 유지보수하며, 심지어 자체 데이터 센터를 가지고 있을 수도 있습니다.

대부분의 회사는 이 두 극단 사이에 위치하며, 일부 구성 요소는 관리형이고 일부는 사내에 있습니다.

CTO의 가장 중요한 임무 중 하나는 벤더/제품 선택입니다. "빌드 vs 바이" 결정은 복잡하고 상황에 따라 크게 달라집니다. 아래에는 그러한 결정을 내릴 때 명심해야 할 몇 가지 요소가 있습니다.

어떤 사람들은 구축하는 것이 구매하는 것보다 저렴하다고 생각하지만, 반드시 그런 것은 아닙니다.

빌드 vs 바이를 위한 고려 요소

회사가 처한 단계

초기에는 벤더 솔루션을 활용하여 더 빨리 움직이고 제한된 리소스를 핵심 제품(core offering) 구축에 집중하고 싶을 수 있습니다.
유스케이스가 성장함에 따라 벤더 비용이 엄청나게(exorbitant) 비싸질 수 있으며, 자체 솔루션을 구축하는 것이 더 나을 수 있습니다.

회사의 초점 또는 경쟁 우위라고 믿는 것

고려 중인 플랫폼 구성 요소가 경쟁 우위의 일부이기 때문에 회사가 정말 잘해야 하는 것이라면, 구축하는 쪽으로 기울이십시오. 그렇지 않다면, 구매하는 쪽으로 기울이십시오.
기술 부문 이외의 대다수 회사(소매, 은행, 제조)는 기술 자체가 핵심 제품이 아니므로 구매하는 쪽으로 기우는 경향이 있습니다.
기술 회사의 경쟁 우위는 기술 자체인 경향이 있으므로, 구축하는 쪽으로 기웁니다.

사용 가능한 도구의 성숙도

사용 가능한 벤더가 필요에 비해 충분히 성숙하지 않다면, 직접 구축해야 할 수도 있습니다.
- 여기서 좋은 옵션은 오픈 소스 솔루션을 기반으로 구축하는 것입니다.
여러분이 ML 플랫폼 구성 요소를 판매하는 벤더라면, "통합 지옥(integration hell)"에 빠질 수 있으므로 빅테크 기업에 판매하는 것을 피하십시오. 그들의 요구는 여러분의 솔루션에 비해 너무 성숙할 수 있으며, 결국 무한한 따라잡기 게임을 하게 될 것입니다.

도구가 클라우드 제공업체와 작동하는가?

선호하는 벤더가 클라우드 제공업체와 작동하는지 또는 자체 데이터 센터에서 서비스를 사용할 수 있는지 확인하십시오. 선택한 도구가 클라우드 제공업체와의 통합을 제공하기를 바랄 것입니다. 도구를 얻기 위해 새로운 클라우드 제공업체를 채택해야 하는 것을 좋아하는 사람은 없습니다.

오픈 소스가 당신에게 옵션인가?

오픈 소스는 처음부터 구축하지 않아도 되며 직접 호스팅(host)할 것임을 의미합니다 (보안 및 개인 정보 보호에 대해 덜 우려함). 그러나 여전히 유지보수해야 합니다.

관리형 서비스라면 유지보수 부담이 줄어듭니다. 그러나 보안 및 개인 정보 보호 문제가 있을 수 있는 제공업체에 일부 데이터를 보내야 할 수도 있습니다.

일부 관리형 서비스는 가상 사설 클라우드(virtual private clouds)에서 호스팅할 수 있게 하여 보안 우려를 덜어줍니다.

11장 - 머신 러닝의 인적 측면

ML에서의 사용자 경험 (UX)

소프트웨어 시스템과 ML 시스템이 어떻게 다른지 길게 논의했습니다. 이는 ML 시스템에는 고려해야 할 추가적인 UX 과제가 있음을 의미합니다. 이 섹션은 이러한 과제 중 3가지를 다룹니다.

과제 1: 사용자 경험 일관성 보장

ML 시스템은 서로 다른 시점에 동일한 사용자에게 다른 예측을 제공할 수 있습니다. 예측의 변경은 사용자에게 시스템의 UX가 망가진(broken) 것처럼 느끼게 할 수 있습니다.
예측이 때때로 변경될 수 있는 몇 가지 이유가 있습니다.
- ML 시스템은 본질적으로 확률적(probabilistic)입니다. 이는 주어진 사용자가 매번 동일한 예측을 받을 것이라는 보장이 없음을 의미합니다.
- 시스템이 서로 다른 시점에 사용자에 대한 다른 정보를 가질 수 있으며, 이로 인해 다른 예측이 발생할 수 있습니다.
ML 시스템을 위한 UX를 설계할 때 일관성-정확도 트레이드오프(consistency-accuracy trade-off)를 고려해야 합니다.
- 사용자에게 일관되지 않은 동작을 감수하고 가장 정확한 / 업데이트된 예측을 제공하도록 결정할 수도 있고, 또는 일관성을 보장하기 위해 어떤 규칙을 사용하여 예측이 무엇이었는지 "기억하고 고정"하도록 결정할 수도 있습니다.

과제 2: "대부분 올바른" 예측 대응

"대부분 올바른(mostly correct)" 예측은 ML 시스템이 "대부분 올바르거나" "올바르게 보이지만" 올바르다고 보장할 수는 없는 예측을 생성할 때입니다.
해당 도메인의 전문 사용자는 예측의 어느 부분이 잘못되었는지 식별하고 수정할 수 있습니다. 비전문 사용자는 식별할 충분한 지식이 없을 수 있으며 주어진 예측을 올바른 것으로 잘못 받아들일 수 있습니다.
이는 대규모 언어 모델(LLM)에서 매우 일반적입니다. 예를 들어, LLM에게 문제 해결을 위한 Java 코드를 생성하도록 요청하면, 그럴듯한(plausible) Java처럼 보이는 코드를 출력할 것입니다.
- 숙련된 프로그래머는 예측된 코드를 빠르게 읽고, 작동하도록 몇 가지를 수정하여 사용할 수 있습니다.
- 경험이 없는 프로그래머는 코드가 잘못되었더라도 "있는 그대로" 사용하려고 시도할 수 있습니다.
"대부분 올바른" 예측을 생성하는 시스템은 전문 사용자에게는 엄청난 시간 절약기(time saver)가 될 수 있습니다. 사용자가 이런 유형이라면 UX 고민은 단순해집니다.
더 어려운 UX 과제는 예측이 여전히 유용하면서도 액면 그대로(at face value) 받아들여지지 않도록 비전문 사용자에게 "대부분 올바른" 예측을 올바르게 제시하는 방법입니다.
일반적인 접근 방식은 사용자에게 동일한 입력으로부터 여러 예측을 보여주어 그중 적어도 하나가 올바를 가능성을 높이는 것입니다.
- 비전문 사용자를 다루는 경우, 예측은 그들이 변형(variants)을 평가할 수 있는 방식으로 렌더링(render)되어야 합니다. 예를 들어, 모델의 출력이 HTML 대안이라면 각각을 렌더링하십시오.
- 이 접근 방식은 때때로 "휴먼 인 더 루프(human-in-the-loop)"라고도 합니다. Chip은 이 주제에 대한 더 많은 정보를 위해 "Rethinking Human-AI interaction" By Jessy Lin을 읽어볼 것을 권장합니다.

과제 3: 매끄러운 실패 (Smooth Failing)

모델이 아무리 속도를 위해 튜닝되었더라도, (큰 입력과 같은) 특정 조건에서는 모델이 예측을 하는 데 허용할 수 없는 시간이 걸릴 수 있다는 냉정한 진실에 부딪힐 수 있습니다.
- 이는 NLP나 시계열 모델에서 전형적입니다. 텍스트 입력이 클수록 시간이 더 오래 걸립니다.
- 높은 예측 지연 시간은 시스템에 많은 데이터를 가진 고객에게도 발생할 수 있습니다. 그들이 최고의 고객일 수 있으므로 무시하지 마십시오.
이를 해결하기 위해 다음을 수행할 수 있습니다.
- 덜 정확하지만 더 빠른 백업 모델(backup model)을 만듭니다. 이 백업 모델은 1) 휴리스틱 규칙, 2) 더 간단한 모델 또는 3) 더 오래된 데이터로 캐시된 예측일 수 있습니다.
- 백업 모델을 트리거(trigger)하는 방법에 대한 전략을 결정합니다. 이 트리거는 다음일 수 있습니다.
  - 1) 메인 모델에 타임아웃(timeout)을 추가하고 타임아웃에 도달하면 백업으로 폴백(fallback)합니다.
  - 2) 예측을 라우팅하는 휴리스틱 규칙을 추가합니다.
  - 3) 메인 모델에서 계산이 얼마나 걸릴지 예측하는 보조 회귀 모델을 구축합니다. 이렇게 한다면, 회귀 예측의 추론을 고려해야 합니다.
매끄러운 실패는 속도-정확도 트레이드오프(speed-accuracy trade-off)와 관련이 있습니다. 때로는 지연 시간이 중요하기 때문에 더 빠르지만 덜 최적인 모델을 사용하는 것을 선호합니다.
- 기본 + 백업 구성을 사용하면 속도와 정확도를 (어느 정도) 모두 선택할 수 있습니다.

팀 구조

이 섹션에서는 ML 팀을 구성할 때 고려해야 할 팀 구조의 측면을 다룹니다.

SME를 무시하지 마라

SME(Subject Matter Experts, 해당 분야 전문가: 의사, 변호사, 농부, 스타일리스트)는 종종 ML 시스템 설계에서 간과되거나 데이터 레이블링 단계에서만 고려됩니다.

SME를 팀의 일원으로 두거나 최소한 레이블링 단계를 넘어선 모든 단계(문제 공식화, 피처 엔지니어링, 오류 분석, 모델 평가, 사용자 인터페이스 등)에 참여시키는 것을 고려해야 합니다. 그들의 의견은 시스템의 성패를 좌우할 수 있습니다.

SME가 모든 것을 엔지니어링을 통하지 않고도 프로젝트에 기여할 수 있도록 허용하는 것이 중요합니다. 예를 들어, 많은 회사가 SME가 레이블링, 품질 보증(QA), 피드백과 같은 작업을 변경할 수 있도록 노코드(no-code)/로우코드(low-code) 플랫폼을 구축하고 있습니다. 데이터셋 생성 및 문제 조사와 같은 다른 단계를 위한 더 많은 플랫폼이 개발되고 있습니다.

데이터 사이언티스트의 소유권 경계

회사는 데이터 사이언티스트의 "소유권 경계"를 결정할 때 다음 두 가지 접근 방식 중 하나를 따르는 경향이 있습니다.

접근 방식 1: 프로덕션을 관리하는 별도 팀 두기

데이터 사이언티스트 / ML 팀은 개발 환경에서 모델을 개발합니다. 그런 다음 모델은 프로덕션에 적용하고 실행하기 위해 별도 팀(예: Ops/플랫폼 ML 엔지니어링 팀)에 전달됩니다.

장점
- 동시에 여러 기술을 아는 사람을 고용하는 것보다 한 가지 기술을 가진 사람을 고용하는 것이 더 쉽습니다.
- 체인의 자기 부분에만 집중하면 되므로 모든 개인의 삶이 더 쉬워집니다.
단점
- 팀 간의 커뮤니케이션 및 조정 오버헤드.
- 문제가 발생했을 때 누구에게 가야 할지 명확하지 않고 사람들이 서로의 코드에 익숙하지 않기 때문에 디버깅이 어려워집니다. 문제를 디버깅하기 위해 여러 팀을 끌어와야 합니다.
- 문제가 잘못되었을 때 손가락질(finger-pointing)을 조장합니다.
- 모든 사람이 좁은 맥락을 가지고 있으며 아무도 전체 엔드투엔드 프로세스에 대한 가시성을 갖지 못합니다. 이는 아무도 그것을 개선하는 방법에 대한 영향력 있는 제안을 보지 못한다는 것을 의미합니다.

접근 방식 2: 데이터 사이언티스트가 전체 엔드투엔드 프로세스 소유

데이터 사이언티스트 / ML 팀이 모델을 프로덕션화(productionizing)하는 것까지 걱정해야 합니다.

장점
- 위의 단점과 반대.
단점
- 데이터 사이언티스트가 프로덕션에 모델을 적용하는 데 필요한 로우 레벨(low-level) 인프라 기술을 알 것으로 기대하는 것은 불합리합니다.
- 모든 기술을 갖춘 사람을 고용하는 데 정말 어려움을 겪을 수 있습니다.
- 데이터 사이언티스트가 ML 코드보다 인프라 코드를 작성하는 데 더 많은 시간을 할애할 수 있습니다.

잠깐, 두 접근 방식 모두 형편없다면, 어떻게 해야 하는가?

ML 팀이나 데이터 사이언티스트가 전체 프로세스를 엔드투엔드로 소유하는 것이 더 잘 작동합니다. 그러나 이렇게 하려면, 그들이 전문가가 아닌 영역을 다룰 수 있는 좋은 하이 레벨(high-level) 추상화를 제공해야 합니다.

컨테이너화(containerisation), 분산 처리, 자동 장애 조치(failover) 등과 같은 복잡성을 추상화하십시오.

"Netflix 작업 모델"에서는 인프라, 빌드 도구, 배포 파이프라인, 지표 및 대시보딩 (등)과 같은 영역의 전문가가 먼저 프로젝트에 합류하여 자신들의 부분을 자동화하는 도구를 만듭니다. 그런 다음 데이터 사이언티스트 / ML 팀이 해당 도구를 사용하여 프로젝트를 엔드투엔드로 소유합니다.

즉, 프로젝트를 엔드투엔드로 개발할 수 있는 도구를 구축한 다음, 데이터 사이언티스트 / ML 팀이 해당 도구를 사용하여 이터레이션(iterate)하게 하십시오.

책임감 있는 AI를 위한 프레임워크

이 섹션에는 모델이 책임감을 갖도록 보장하기 위해 회사가 채택할 수 있는 프레임워크가 포함되어 있습니다.

다음을 명심하십시오:

이 프레임워크는 모든 유스케이스에 충분하지 않을 수 있습니다. 판단력을 사용하십시오.
사용하는 프레임워크에 관계없이 비윤리적인 AI 애플리케이션이 있습니다 (예: 범죄 형량 결정, 예측 치안(predictive policing)).

모델 편향의 원천 발견

모델을 개발할 때, 모델 편향의 여러 원천을 연구하십시오.

편향은 모델 생성 프로세스의 모든 단계에서 스며들(creep up) 수 있습니다. 다음은 확인해야 할 장소의 일부 목록입니다.

학습 데이터: 데이터가 실제 세계를 대표하지 않는다면, 특정 그룹에 대한 데이터의 존재 또는 부재가 모델이 해당 그룹에 대해 편향되도록 만들 수 있습니다. 비확률적 샘플링을 참조하십시오.
레이블링: 인간 주석가(annotators)가 주석을 달기 위해 주관성에 더 많이 의존할수록, 더 많은 편향이 생길 것입니다. 주석가가 표준 가이드라인을 따르도록 보장하고 생성된 레이블의 품질을 측정하는 방법을 생각해보십시오.
피처 엔지니어링: 모델이 편향을 학습하도록 만들 수 있는 피처를 사용하고 있습니까? 민족, 성별, 인종, 성적 지향, 종교 등과 관련된 피처를 사용하는 것은 편향의 위험이 높기 때문에 일반적으로 권장되지 않습니다. 모델이 이를 간접적으로 추론할 수 있게 하는 피처를 사용하는 것도 위험합니다. 불변성 테스트 및 슬라이스 기반 테스트를 참조하십시오.
모델의 목적(Objective): 목적이 모든 사용자에 대한 공정성을 허용합니까, 아니면 다수 그룹이나 다수 클래스를 선호하는 편향을 도입합니까?
1. 다수 클래스 처리에 대해서는 클래스 불균형을 참조하십시오.
2. 불변성 테스트와 슬라이스 기반 테스트가 다른 그룹에 대해 다른 결과를 표시한다면, 모델 프레이밍이나 목적을 재고할 수 있습니다.
평가: 평가 프로세스가 편향을 도입하고 있습니까?
1. 인간 평가를 사용하여 평가가 수행된다면, 모델은 인간을 통해 편향을 받을 수 있습니다 (위의 레이블링 참조).
2. 평가가 자동으로 수행될 수 있다면, 불변성 테스트 및 슬라이스 기반 테스트를 수행하지 않거나 테스트 중에 특정 그룹을 무시하면 모델이 편향될 수 있습니다.

데이터 기반 접근 방식의 한계 이해

공정성과 책임감 있는 AI에 대한 데이터 기반 접근 방식은 필요하지만 충분하지는 않습니다.

모델 개발자는 예측의 다른 쪽에 있는 사용자의 삶이 예측에 의해 어떻게 영향을 받을지 인간적인 수준에서 이해해야 합니다. 이렇게 함으로써 데이터에 너무 많이 의존함으로써 발생하는 사각지대(blind spots)의 위험을 줄일 수 있습니다.

여러 속성에 대해 모델을 최적화할 때 발생하는 공정성 트레이드오프 이해

종종 ML 문헌은 속성을 최적화하기 위해 모델을 변경할 때 다른 모든 속성은 정적(static)으로 유지된다고 가정합니다. 이는 사실이 아닙니다.

이 가정은 많은 트레이드오프가 아직 발견되지 않았기 때문에 책임감 있는 AI 공간에서 특히 위험합니다.

여기서는 문헌에 기록된 두 가지 예시 트레이드오프를 다룹니다.

프라이버시 vs 정확도 트레이드오프
압축 vs 공정성 트레이드오프

차등적 프라이버시(differentially private)가 적용된 데이터셋이나 압축되고 있는 모델로 작업하는 경우, 의도하지 않은 피해를 피하기 위해 이러한 트레이드오프를 연구하는 데 리소스를 투자해야 합니다.

프라이버시 vs 정확도 트레이드오프

모델이 제공하는 프라이버시 수준이 높을수록, 일반적으로 모델 정확도는 낮아집니다.
차등 프라이버시 모델의 정확도는 과소 표현된(underrepresented) 클래스와 하위 그룹(subgroups)에 대해 훨씬 더 많이 떨어집니다.

압축 vs 정확도 공정성 트레이드오프

모델 압축의 아이디어는 최소한의 정확도 비용으로 모델 크기를 줄이는 것입니다. 이 주제는 7장에서 설명합니다.
압축이 모든 클래스와 하위 그룹에 걸쳐 정확도 손실을 균일하게 "분산"시킬 것이라고 보장할 수 없습니다. 압축은 데이터셋에서 과소 표현된 하위 그룹에 불균형적으로(disproportionally) 영향을 미칠 수 있습니다.
모든 압축 기법이 동일한 수준의 불균형 영향(disparate impact)을 갖는 것은 아닙니다. 가지치기(Pruning)는 양자화(quantisation)보다 훨씬 더 높은 불균형 영향을 초래합니다.
다시 한번, 슬라이스 기반 테스트는 압축의 영향을 연구하는 훌륭한 도구입니다.

조기 행동

ML 시스템 개발 주기 초기에 이 시스템이 사용자 삶에 어떤 영향을 미칠지, 시스템이 어떤 편향을 가질 수 있는지 생각하기 시작할수록, 이러한 편향을 해결하는 비용이 더 저렴해집니다.

모델 카드 만들기

모델 카드는 학습된 모델에 동반되는 짧은 문서로, 어떻게 학습되고 평가되었는지에 대한 정보가 포함됩니다. 또한 의도된 사용 및 알려진 한계와 같은 맥락도 포함합니다. 모델 카드 템플릿은 아래와 같습니다.
모델 카드의 목표는 윤리적 관행을 표준화하고 이해관계자가 성능의 렌즈뿐만 아니라 책임감 있는 AI의 렌즈에서도 후보 모델에 대해 추론할 수 있게 하는 것입니다.
모델 카드는 모델을 배포하고 사용하는 사람과 개발한 사람이 같지 않은 경우에 특히 중요합니다.
모델 카드를 수동으로 만들고 업데이트하는 것은 꽤 지루할(tedious) 수 있습니다. 모델 카드의 가능한 많은 부분을 자동으로 생성할 수 있는 도구에 투자하는 것이 중요합니다. Tensorflow, Metaflow, scikit-learn은 모두 모델 카드를 위한 기능을 가지고 있습니다. 일부 회사는 자체 모델 카드 소프트웨어를 구축합니다.
- Chip은 모델 스토어가 곧 모델 카드를 기본적으로(natively) 지원하고 생성하도록 진화할 것이라고 생각합니다.

모델 카드 예시

모델 세부 정보: 기본 정보
- 모델을 개발하는 사람, 팀 또는 조직
- 모델 날짜
- 모델 버전
- 모델 유형
- 학습 알고리즘, 파라미터, 공정성 제약 조건 및 피처에 대한 정보
- 추가 정보 리소스 (예: 논문, 블로그 게시물)
- 인용 세부 정보
- 라이선스
- 모델에 대한 질문이나 의견을 보낼 곳
의도된 사용
- 주요 의도된 사용자
- 범위 외(Out-of-scope) 유스케이스
요소(Factors): 요소는 인구 통계학적 또는 표현형 그룹, 환경 조건, 기술적 속성 또는 기타를 포함할 수 있습니다.
- #todo: 이것이 무엇인지 명확하지 않음.
- 관련 요소 및 평가 요소
지표(Metrics): 모델의 잠재적인 실제 영향을 반영하도록 선택되어야 합니다.
- 모델 성능 측정
- 결정 임계값(Decision thresholds)
- 변동 접근 방식(Variation approaches)
평가 데이터: 카드에 보고된 정량적 분석에 사용된 데이터셋에 대한 세부 정보.
- 데이터셋
- 동기(Motivation)
- 전처리
학습 데이터: 가능하다면, 위의 평가 데이터 섹션을 미러링(mirror)하십시오.
- 실제로, 학습 데이터를 모델 카드에 포함하는 것이 항상 가능한 것은 아닙니다.
- 데이터 포함이 불가능하다면, 최소한 학습 데이터셋의 다양한 요소에 대한 분포를 포함하십시오.
정량적 분석
- 단일(Unitary) 결과
- 교차(Intersectional) / 슬라이스 기반 결과
윤리적 고려 사항
주의 사항 및 권장 사항

편향 완화를 위한 회사 프로세스 수립

책임감 있는 AI를 구축하는 것은 복잡한 프로세스입니다. 임시방편(Ad-hoc) 프로세스는 오류의 여지를 많이 남깁니다. 회사가 ML 모델을 책임감 있게 만들기 위한 체계적인 프로세스를 수립하는 것이 중요합니다.
일부 회사는 제3자 감사(third-party audits)를 수행합니다.
리소스:
- Google의 책임감 있는 AI 관행
- AI Fairness 360: 모델 및 데이터셋의 편향을 완화하는 데 도움이 되는 알고리즘, 지표, 설명을 포함한 오픈 소스 라이브러리.

책임감 있는 AI에 대한 최신 정보 유지

책임감 있는 AI는 새로운 편향 원천이 지속적으로 발견되고 새로운 기법이 개발되는 빠르게 움직이는 분야입니다.
최신 정보를 유지하는 데 도움이 되는 몇 가지 리소스:

ACM FAccT Conference
Partnership on AI ( 참고: 원문에 링크가 비어있어 기본 주소로 연결 )
Alan Turing Institute's Fairness, Transparency and Privacy Group
AI Now Institute

'머신러닝 시스템 설계' (Chip Huyen) 요약 - 파트 1

Jonas Kim — Sat, 08 Nov 2025 13:12:23 +0000

책 머신러닝 시스템 설계과 그에 대한 요약본 Summary of Designing Machine Learning Systems을 참고하였습니다.

1 - ML 시스템 개요

ML을 사용해야 할 때 (그리고 사용하지 말아야 할 때)

ML 솔루션이 작동하기 위해 필요한 문제의 특징

어떤 문제는 다른 문제보다 ML 솔루션에 더 적합한 경향이 있습니다. 전통적인 소프트웨어 엔지니어링과 ML이 모두 실행 가능한 옵션인 경우에도 ML이 최적의 솔루션이 아닐 수 있습니다.

이 책에는 (지도) ML 시스템이 일반적으로 수행하는 작업에 대한 다음 정의가 포함되어 있습니다. ML로 문제를 해결할 수 있으려면 이 정의에 인코딩된 특정 특징이 필요합니다.

머신 러닝은 (1) 기존 데이터로부터 (2) 복잡한 패턴을 학습하고 이 패턴을 사용하여 (3) 예측을 수행하고 (4) 보이지 않는 데이터에 적용하는 접근 방식입니다.

1. 기존 데이터: 데이터가 이용 가능하거나 수집할 수 있어야 합니다.

충분한 데이터가 없고 이를 수집할 메커니즘이 없다면 ML 접근 방식은 작동하지 않습니다. 지도 학습(supervised learning)의 경우, 충분한 레이블이 지정된 데이터가 필요합니다.

제로샷(Zero-shot) / 퓨샷(few-shot) 학습 기술을 사용하면 특정 작업에 대한 데이터로 모델을 학습시킬 필요 없이 예측을 수행할 수 있습니다. 그러나 이는 일반적으로 사전 학습된 모델(pre-trained models)에 의존합니다.
지속적인 학습(Continuous learning) 기술도 사용할 수 있습니다. 이는 학습되지 않은 모델을 프로덕션에 배포하고, 프로덕션 데이터를 온라인 증분 학습(online incremental training), 강화 학습(reinforcement learning) 또는 향후 오프라인 학습(offline training)에 사용하는 것을 의미합니다. 학습되지 않은 모델을 프로덕션에 배포하는 것은 위험을 수반합니다.
'될 때까지 속여라(Fake it till you make it)' 전략도 기업들 사이에서 인기가 있습니다. 이는 ML 모델 대신 사람이 직접 예측을 수행하는 제품을 출시하고, 이렇게 생성된 데이터를 나중에 ML 모델 학습에 사용하려는 희망을 가지고 진행하는 방식입니다.

2. 복잡한 패턴: 학습할 패턴이 있고, 그 패턴이 복잡해야 합니다.

데이터는 있지만 학습할 패턴이 없다면 ML 접근 방식은 의미가 없습니다. 예를 들어, 공정한 주사위의 결과를 예측하기 위해 ML 시스템을 구축하는 것은 의미가 없습니다.
패턴이 있지만 단순하다면, 해당 문제에 순수한 소프트웨어 엔지니어링 솔루션을 사용하는 것이 더 합리적일 수 있습니다 (예: 주소 기반으로 우편번호를 찾기 위해 ML 시스템을 구축하지 말고, 그냥 조회 테이블(lookup table)을 사용하세요).

3. 문제를 예측 문제로 구성(frame)할 수 있어야 합니다.

지도 ML 모델은 예측을 수행합니다. 문제 전체 (또는 일부)를 예측 문제로 구성할 수 없다면, 지도 ML은 적절한 도구가 아닙니다.
계산 집약적인(computationally intensive) 많은 문제들이 예측 문제로 재구성되고 있습니다. 비디오 게임의 조명 렌더링이 한 예입니다. 조명이 정확히 어떠해야 하는지에 대한 비용이 많이 드는 전체 계산을 수행하는 대신, 회귀(regression) ML 모델을 사용하여 "충분히 좋은" 근사치를 얻을 수 있습니다. 이 경우 모델을 학습시키는 것이 계산을 수행하는 것보다 비용이 적게 듭니다.

4. 보이지 않는 데이터(unseen data)가 학습 데이터(train data)와 패턴을 공유해야 합니다.

모델은 프로덕션 데이터의 패턴이 학습 데이터의 패턴과 동일할 때만 잘 작동합니다.
데이터가 보이지 않는다면, 그것이 어떤 분포에서 왔는지 어떻게 알 수 있을까요? 우리는 알 수 없으며, 단지 그럴 것이라고 합리적인 가정을 할 뿐입니다. 우리는 프로덕션 환경에서 모니터링(8장)하고 테스트(9장)함으로써 우리의 가정이 맞았는지 사후에 확인할 수 있습니다.

ML 솔루션을 특히 유용하게 만드는 문제의 특징들

이것들이 필수적인 특징은 아니지만, 이 중 하나 또는 여러 개를 가지고 있다면 해당 문제에 대해 ML 접근 방식이 성공할 가능성이 훨씬 높아집니다.

반복적인 작업입니다. 작업이 반복적이라면 패턴이 여러 번 나타난다는 의미이므로, ML 모델이 더 잘 학습할 수 있습니다.
잘못된 예측의 비용이 저렴합니다. ML 모델은 필연적으로 잘못된 예측을 합니다. 실수의 비용이 저렴하면 위험 부담이 낮아져 ML 모델을 구축하고 배포하기가 더 쉬워집니다. 잘못된 예측의 결과가 재앙적일지라도, 올바른 예측의 이점이 잘못된 예측의 비용을 평균적으로 상회한다면 모델을 구축할 수 있습니다. 자율 주행 자동차는 자동화된 자동차가 인간이 운전하는 자동차보다 평균적으로 더 안전하다는 점을 고려할 때 이에 대한 좋은 예입니다.
작업이 대규모(at scale)로 발생합니다. ML 모델을 프로덕션에 배포하는 것은 어렵습니다. 모델이 많은 예측을 수행하는 데 사용될 때 이러한 노력이 더 정당화됩니다. 또한, 작업이 대규모로 발생하면 학습할 데이터가 많아집니다.
패턴이 끊임없이 변화합니다. 패턴이 자주 변경되어 하드코딩된 규칙이 너무 빨리 구식이 되어버릴 때, ML은 전통적인 소프트웨어 규칙에 비해 빛을 발합니다. 스팸 트렌드의 변화와 문화 트렌드의 변화가 바로 변화하는 패턴의 예입니다.

일반적인 ML 사용 사례

ML은 소비자(consumer) 대상 애플리케이션과 기업(enterprise) 내부 애플리케이션 모두에 사용되고 있습니다. 소비자 ML 애플리케이션은 성장하고 있지만, 2022년 기준으로 여전히 대다수의 애플리케이션은 기업 영역에 있습니다.

소비자 애플리케이션에서는 정확성(accuracy)보다 지연 시간(latency)이 더 중요한 경향이 있습니다. 지연 시간이 증가하면 사용자가 앱에서 이탈할 수 있습니다. 소비자들은 또한 영화 추천이나 사진의 잘못된 태그 지정과 같이 중요하지 않은 애플리케이션에서는 잘못된 예측에 대해 더 관대한 경향이 있습니다.
기업 애플리케이션에서는 지연 시간보다 정확성이 더 중요한 경향이 있습니다. 정확성이 조금만 향상되어도 연간 수백만 달러를 절약할 수 있습니다. 아래 이미지는 ML 기업 애플리케이션의 세부 내역을 보여줍니다. 다음은 몇 가지 예입니다.
- 고객 획득 비용(CAC)을 줄이기 위해 ML을 사용합니다. 더 나은 타겟 광고를 표시하고, 적절한 순간에 할인을 제공합니다. 2019년 기준, 인앱 구매를 하는 사용자의 평균 CAC는 86.61달러입니다. 높은 CAC는 스타트업에 치명적일 수 있습니다.
- 이탈 예측(Churn prediction): 신규 고객을 획득하는 것은 기존 고객을 유지하는 것보다 5배에서 25배 더 비쌉니다.
- 브랜드 모니터링: 소셜 미디어에서 귀하의 브랜드에 대한 대중의 감정(sentiment)을 모니터링합니다.

연구(Research)와 프로덕션(Production) ML의 차이

연구용 ML과 프로덕션용 ML은 다릅니다. 연구 환경의 사고방식으로 프로덕션 모델에 접근하려 할 때 발생하는 함정을 피하기 위해 그 차이점을 인식하는 것이 중요합니다.

	연구 (Research)	프로덕션 (Production)
요구사항	벤치마크 데이터셋에서의 최첨단(State-of-the-art) 모델 성능 (1)	다양한 이해관계자가 각기 다른 요구사항을 가짐 (2)
계산 우선순위	빠른 학습, 높은 쿼리 처리량(throughput) (3)	낮은 지연 시간(latency)의 빠른 추론(inference) (4) (5) (6)
데이터	정적인 경우가 많음	끊임없이 변화함
공정성(Fairness)	초점이 아닌 경우가 많음	반드시 고려되어야 함 (7)
해석 가능성(Interpretability)	초점이 아닌 경우가 많음, 성능이 북극성(north star) (8)	반드시 고려되어야 함

(1) 모델 배포 및 유지보수에 중점을 두지 않음.

(2) MLE, 영업 팀, 제품 관리자, ML 플랫폼 팀 모두 동일한 시스템에 대해 서로 다른 요구사항을 가짐.

(3) 대부분의 최신 시스템은 추론 시 쿼리를 일괄 처리(batch up)합니다. 연구에서는 전체 테스트 데이터셋에 대한 예측 처리량(throughput)이 수용 가능하다면 단일 쿼리에 응답하는 시간이 길어도 크게 중요하지 않습니다. 프로덕션에서는 단일 쿼리에 응답하는 시간이 중요하므로, 처리량과의 균형을 맞춰야 합니다.

(4) ...모델을 실제 환경에 배포하면 지연 시간(latency)은 매우 중요합니다. 2017년 Akamai 연구에 따르면 100ms의 지연이 전환율(conversion rates)을 7%까지 떨어뜨릴 수 있습니다. 20 2019년 Booking.com은 약 30%의 지연 시간 증가가 전환율을 약 0.5% 감소시켰으며, 이는 "우리 비즈니스에 상당한 비용"이라고 밝혔습니다. 21 2016년 Google은 모바일 사용자의 절반 이상이 페이지 로드에 3초 이상 걸리면 이탈한다는 것을 발견했습니다. 22 오늘날 사용자들은 훨씬 더 참을성이 없습니다.

(5) 지연 시간은 평균이 아닌 백분위수(percentiles)를 사용하여 모니터링해야 합니다. 가장 가치 있는 고객들은 더 많은 데이터를 가지고 있고 더 느린 추론을 경험하는 경향이 있으므로, p90에서 p99와 같은 상위 백분위수를 무시하지 마십시오.

(6) 시스템의 지연 시간 요구사항을 명시할 때 p90과 같은 상위 백분위수를 사용하는 것을 고려하십시오.

(7) ML 시스템은 과거를 인코딩하고 학습 데이터가 가진 편향을 재현하고 고착화합니다. 설상가상으로, ML 시스템은 대규모로 차별을 행하여 잠재적으로 수백만 명의 사람들에게 영향을 미칠 수 있습니다.

(8) 예를 들어, 앙상블 모델(ensemble models)은 연구에서는 흔하지만, 낮은 해석 가능성과 높은 복잡성 때문에 프로덕션에서는 매우 드뭅니다.

ML 시스템 vs 전통적인 소프트웨어

표면적으로는 SWE(소프트웨어 엔지니어링)의 모범 사례를 ML 엔지니어링에 도입하는 것이 좋은 생각처럼 보입니다. 하지만 그렇게 간단하지 않습니다. SWE 시스템은 설계상 데이터와 코드를 분리하며, 버전 관리, 테스트, 배포 및 모니터링의 노력은 코드 산출물(artifacts)에 집중됩니다.

ML 시스템은 코드, 데이터, 그리고 이 둘로부터 생성된 산출물의 조합입니다. 이 모든 것들이 버전 관리, 테스트, 배포, 모니터링되어야 합니다.

과제들:

데이터를 어떻게 버전 관리할 것인가?
데이터 샘플이 시스템에 좋은지 나쁜지 어떻게 테스트할 것인가?
기가바이트의 RAM을 필요로 하는 수백만 개의 매개변수를 가진 학습된 모델을 어떻게 배포할 것인가? 만약 엣지(edge)에 배포해야 한다면 어떻게 할 것인가?
배포된 모델이 해석하기 어려울 수 있다는 점을 고려할 때, 이를 어떻게 모니터링하고 디버깅할 것인가?

2 - 프로젝트 목표, 요구사항 및 프레이밍

(1장에서 설명한 것처럼) 문제에 ML 솔루션이 실행 가능하다고 판단했다면, 이제 비즈니스 목표를 ML 목표와 일치시키고 시스템이 충족해야 하는 운영 요구사항을 정의할 차례입니다.

또한, 이 장에서는 문제 프레이밍(problem framing)이 솔루션 구축 및 유지를 얼마나 쉽거나 어렵게 만들 수 있는지에 대해서도 다룹니다.

비즈니스 목표와 ML 목표의 관계

기업은 accuracy(정확도), precision(정밀도), recall(재현율), F1 등과 같은 ML 지표 자체에는 큰 관심이 없습니다. 데이터 사이언티스트가 비즈니스 지표는 무시한 채 ML 지표 개선에만 (hacking) 너무 집중하는 ML 프로젝트는 실패하기 쉽습니다. ML 프로젝트가 조직 내에서 장기적으로 성공하려면, ML 시스템의 성능을 수익, 월간 활성 사용자(MAU) 등과 같은 비즈니스 성과 지표(KPI)에 연결하는 것이 중요합니다.
비즈니스 목표를 ML 목표로 매핑하는 작업은 애플리케케이션에 따라 난이도가 다릅니다. 예를 들어, 금융 애플리케이션에서 사기 탐지 시스템의 비즈니스 영향은 매우 명확하고 측정하기 쉽습니다. 반면, 잠재적인 사이버 보안 위협을 탐지하는 ML 시스템에서는 이러한 매핑이 훨씬 불분명합니다. 당연하게도, (사기 탐지처럼) 매핑이 더 쉬운 ML 애플리케이션이 가장 일반적인 유형의 기업 ML 애플리케이션이기도 합니다.
많은 기업이 비즈니스 지표를 ML 지표에 매핑하기 위해 자체적인 지표를 만듭니다. 예를 들어, Netflix는 추천 시스템의 성능을 take-rate(이용률)로 측정합니다. 사용자가 본 추천 수 대비 의미 있는 재생 수(quality plays). take-rate가 높을수록 추천 시스템이 더 우수합니다.

ML 시스템의 요구사항

ML 시스템이 가질 수 있는 요구사항은 많습니다. 그러나 적어도 신뢰성(reliability), 확장성(scalability), 유지보수성(maintainability) 및 적응성(adaptability)에 대해 고민해봐야 합니다. 이 섹션에서는 ML 시스템의 맥락에서 이들 각각이 무엇을 의미하는지 논의합니다.

신뢰성(Reliability)

시스템은 다양한 장애 상황(adversity)에 직면하더라도 원하는 성능 수준에서 올바른 기능을 계속 수행해야 합니다.
ML 시스템에서 "정확성"을 결정하는 것은 소프트웨어 시스템에서보다 더 어렵습니다. ML 시스템은 예를 들어, 계속해서 잘못된 예측을 생성함으로써 조용히 실패할 수 있습니다(fail silently). 우리가 사전에 정답(ground truth)을 모른다면 예측이 틀렸는지 어떻게 알 수 있을까요?

확장성(Scalability)

ML 시스템이 확장해야 하는 다양한 축(axes)을 고려하십시오.
ML 시스템은 모델 크기(예: 더 많은 파라미터 사용)가 커질 수 있으며, 이는 모델 실행에 더 많은 하드웨어 RAM을 필요로 함을 의미합니다.
ML 시스템은 처리하는 트래픽 양이 증가할 수 있습니다. 시스템이 이를 따라잡을 수 있어야 합니다.
ML 시스템은 특정 유스케이스에 대해 모델 수가 증가할 수 있습니다. 예를 들어, 처음에는 트렌딩 토픽을 탐지하는 모델만 있었습니다. 그런 다음 해당 유스케이스에 NSFW(업무상 부적절한) 트렌딩 트윗을 필터링하는 두 번째 모델을 도입합니다.
자원 확장만이 확장성의 유일한 관심사는 아닙니다. 산출물 관리(artefact management)도 마찬가지입니다. 수백 개의 모델이 있을 때는 모델을 모니터링, 재학습 및 배포하는 자동화되고 반복 가능한 방식이 필요합니다. 모델이 몇 개뿐이라면 이 모든 것을 수동으로 할 수도 있을 것입니다.
이 책은 다른 섹션에서 확장성 주제를 더 다룹니다. 분산 학습(Distributed Training), 모델 최적화(Model Optimisation), 자원 관리(Resource Management), 실험 추적 및 버전 관리(Experiment Tracking and Versioning), 개발 환경(Development Environment).

유지보수성(Maintainability)

다양한 배경의 사람들(ML 엔지니어, DevOps 엔지니어, SME(해당 분야 전문가) 등)이 단일 ML 시스템에서 작업합니다. 한 그룹이 모든 사람에게 도구 세트를 강요하는 대신, 모든 그룹이 자신에게 익숙한 도구를 가지고 작업할 수 있도록 워크플로우를 구조화하는 것이 중요합니다.
코드는 문서화되어야 하며, 데이터와 산출물은 버전 관리되어야 합니다.
이 주제에 대한 자세한 내용은 "11장의 팀 구조 섹션"에 있습니다.

적응성(Adaptability)

데이터 분포와 비즈니스 요구사항은 빠르게 변합니다. 시스템은 이러한 자연스러운 변화에 쉽게 적응할 수 있어야 합니다.

ML 문제 프레이밍하기(Framing)

비즈니스 문제는 일반적으로 ML 문제로 직접 변환되지 않습니다. 비즈니스 문제의 어떤 부분을 ML로 해결할 수 있을지 파악하기 위해 고민이 필요합니다. 일단 그 부분을 식별하고 나면, 그 하위 문제를 ML 문제로 프레이밍하는 방식이 작업을 더 쉽게 또는 더 어렵게 만들 수 있으며, 때로는 프로젝트의 성패를 좌우할 수도 있습니다.

문제를 프레이밍할 때 고려해야 할 두 가지 사항이 있습니다. (1) 문제를 모델링하는 데 사용할 ML 작업(task)의 유형, (2) 여러 ML 목표가 있는 문제에서 목적 함수(objective function)를 프레이밍하는 방식.

지도 ML 작업(Task)의 유형

분류(Classification)에서는 클래스(classes)가 적을수록 문제가 단순해집니다. 이진 분류기(Binary classifiers)는 가장 단순한 형태이며 ML 실무자들에 의해 널리 사용됩니다.
다중 클래스(Multi-class): 선택할 레이블이 2개 이상이지만 각 관측치(observation)는 단 하나의 레이블만 할당될 수 있습니다.
- 높은 카디널리티(High cardinality): 선택할 레이블이 매우 많습니다. 예를 들어, 질병 이름. 높은 카디널리티 문제는 어렵습니다.
다중 레이블(Multi-label): 각 관측치가 하나 이상의 레이블을 가질 수 있습니다. 예를 들어, 신문 기사가 과학과 경제 레이블 모두에 속할 수 있습니다. 다중 레이블 분류 문제는 어렵습니다.
높은 카디널리티와 다중 레이블 특성을 모두 갖는 문제는 매우 어렵습니다.

분류(Classification) vs 회귀(Regression) 프레이밍

회귀 모델은 분류 모델로 쉽게 프레이밍될 수 있으며 그 반대도 마찬가지입니다.

연속적인 출력 레이블을 구간화(bucketing)하여 이산형(discrete)으로 바꾸면 회귀 모델을 분류 문제로 프레이밍할 수 있습니다. 예를 들어 <100, 100-200, >200.
출력을 0과 1 사이의 연속 변수로 프레이밍하고 임계값(threshold)을 사용하면 분류 문제를 회귀 문제로 프레이밍할 수 있습니다. 예를 들어 if predicted_spam_score >= threshold: SPAM.

다중 클래스(Multi-class) 분류 프레이밍

높은 카디널리티 문제는 어렵습니다. 다중 클래스 모델을 사용하기로 결정하기 전에 다른 대안이 있는지 확인하십시오.
높은 카디널리티 문제의 데이터 수집은 어렵습니다. ML 모델은 일반적으로 해당 클래스를 분류하는 방법을 배우기 위해 각 클래스마다 최소 100개의 예제가 필요합니다. 따라서 1,000개의 클래스가 있다면 이미 최소 100,000개의 예제가 필요합니다. 데이터 수집은 특히 희귀한 클래스의 경우 어려울 수 있습니다. 수천 개의 클래스가 있을 때, 그 중 일부는 희귀할 가능성이 높습니다.
클래스 수가 많을 때, 계층적 분류(hierarchical classification)가 유용할 수 있습니다. 예를 들어, 개, 고양이 또는 유니콘을 식별하는 1차 분류기를 사용합니다. 그런 다음 이전에 개로 레이블이 지정된 것들을 푸들, 래브라도, 달마시안 등으로 분류하는 또 다른 개 분류기를 사용합니다. 다음 두 아티클이 계층적 분류 주제를 다룹니다.
- The Hitchhiker’s Guide to Hierarchical Classification
- Hierarchical Classification with Local Classifiers: Down the Rabbit Hole
어떤 사람들은 다중 이진 분류기를 사용하여 다중 클래스 문제를 프레이밍한 다음, 최종 예측을 하기 위해 휴리스틱(heuristic)이나 메타 학습기(meta-learner)를 추가하려고 시도합니다. 예를 들어, 가장 높은 이진 분류기의 레이블을 선택합니다.

다중 레이블(Multi-label) 분류 프레이밍

다중 레이블 분류 문제는 각 관측치가 서로 다른 개수의 레이블을 가질 수 있기 때문에 어렵습니다.
- 데이터 수집이 어려워집니다. 서로 다른 레이블 작업자(annotators)가 동일한 관측치에 대해 서로 다른 수의 레이블을 할당할 수 있습니다.
- 원본 확률(raw probabilities)에서 레이블을 추출하는 것이 모호해집니다. 예를 들어, 주어진 관측치에 대한 확률 벡터가 [0.45, 0.2, 0.02, 0.33]과 같다면, 레이블을 할당하기 위해 상위 1개, 상위 2개 또는 상위 N개의 확률을 선택해야 하는지 불분명합니다.
다중 레이블 분류에는 두 가지 주요 접근 방식이 있습니다.
- 학습 데이터에서 관찰되는 각 레이블 조합에 대해 고유한 레이블을 생성하여 문제를 다중 클래스 문제로 취급합니다. 예를 들어, 신문 기사는 기술-금융(하나의 레이블)으로 분류될 수 있고 다른 기사는 기술(다른 레이블)로 분류될 수 있습니다. 카디널리티가 크다면, 이 방식은 카디널리티를 폭발적으로 증가시킬 수 있습니다.
- 주어진 레이블이 주어진 관측치에 할당되어야 하는지 여부를 결정하는, 레이블별 이진 분류기 세트를 사용합니다. 여러 분류기가 "예"라고 말하면, 다중 레이블 관측치를 갖게 됩니다.

프레이밍이 중요한 이유의 예

아래 예는 프레이밍이 어떻게 프로젝트의 성패를 좌우할 수 있는지 보여줍니다. 작업은 사용자가 다음에 열 가능성이 가장 높은 앱을 예측하는 것입니다. 동일한 문제가 분류 작업과 회귀 작업으로 프레이밍됩니다.

분류 프레이밍은 새 앱이 설치될 때 모델을 재학습해야 하므로 처참하게 실패합니다.

0과 1 사이의 임의의 "다음 사용 점수"를 예측하기 위해 앱 피처(app features)를 도입하여 회귀 작업으로 프레이밍하면, 새 앱이 설치될 때 재학습할 필요가 없어집니다. 이 경우 필요한 유일한 작업은 app features 벡터를 추출한 다음 동일한 모델을 사용하는 것입니다.

다중 목표 애플리케이션에서의 목적 함수 프레이밍

공식적으로 말하면, ML 모델을 학습하는 데 사용할 수 있는 다양한 목적 함수가 많으며, 이를 고안하려면 모델 이면의 수학에 대한 깊은 지식이 필요합니다. 그러나 실제로는 단일 모델에 대한 목적 함수 선택은 보통 쉽습니다. 대부분의 ML 엔지니어는 회귀(regression)에 RSME 또는 MAE, 이진 분류(binary classification)에 로그 손실(log loss), 다중 클래스 분류(multi-class classification)에 교차 엔트로피(cross entropy)와 같은 잘 알려진 함수를 사용합니다.

이 섹션의 요점은 모델에 "올바른" 목적 함수를 선택하는 방법이 아닙니다. 그것은 여러 목표가 있는 문제에서 여러 목적 함수를 올바르게 결합하는 방법입니다. 이것은 예제를 통해 설명하는 것이 더 쉽습니다.

사용자의 뉴스 피드에서 아이템 순위를 매기는 ML 시스템을 구축하는 작업이라고 상상해 보십시오. 이를 달성하기 위해 다음과 같은 계획을 세웁니다.

관련 없는 콘텐츠 필터링 (스팸, NSFW 콘텐츠 및 잘못된 정보)
품질별 게시물 순위 매기기 (어떤 수치 척도로 측정됨) → 이는 학습 과정이 품질 손실을 최소화하려 함을 의미
참여도별 게시물 순위 매기기 (게시물 클릭 수로 측정됨) →이는 학습 과정이 참여도 손실을 최소화하려 함을 의미

당신의 문제는 두 개의 상충되는 목표(conflicting objectives)를 가진 다중 목표 문제입니다. 품질은 낮지만 참여도가 높은 게시물의 순위를 어떻게 매길 것인가? 단일 순위 목록을 생성하려면 단일 ranking_score 숫자가 필요합니다.

순진한 프레이밍: 단일 목적 함수 생성

ranking_score 함수를 만든 다음 해당 함수로 모델을 학습시킬 수 있습니다 (즉, ranking_loss 최소화):

ranking_score = alpha * quality_score + beta * engagement_score

그런 다음 다양한 alpha와 beta를 테스트하여 가장 잘 작동하는 조합을 찾습니다.

이 방식의 문제는 alpha나 beta를 변경할 때마다 모델을 완전히 재학습해야 한다는 것입니다.

더 현명한 프레이밍: 목표 분리하기(Decoupling)

대안으로, 두 개의 독립적인 모델을 학습시킬 수 있습니다. 하나는 quality_score를 예측하고 다른 하나는 engagement_score를 예측합니다. 그런 다음 예측을 수행한 후에 두 모델의 출력을 다음과 같이 결합할 수 있습니다. ranking_score = alpha * quality_score + beta * engagement_score. 이번에는 모델을 재학습할 필요 없이 alpha와 beta를 변경할 수 있습니다.

일반적으로 여러 목표가 있을 때, 모델 개발과 유지를 더 쉽게 만들기 때문에 먼저 목표를 분리하는 것이 좋습니다. 첫째, 이전에 설명했듯이 모델 재학습 없이 시스템을 조정하기가 더 쉽습니다. 둘째, 다른 목표는 다른 유지보수 일정이 필요할 수 있으므로 유지보수가 더 쉽습니다.

이 예에서, 분리는 참여도 모델에 영향을 주지 않고도 quality_model을 더 자주 업데이트하거나 재학습할 수 있게 합니다.

3 - 데이터 엔지니어링 기초

이 장은 "데이터 vs 알고리즘, 무엇이 더 중요한가?"라는 철학적 논의를 통해 데이터의 중요성을 강조하며 시작합니다.

그 후, 이 장에서는 "ML 시스템의 데이터"라는 주제의 다양한 차원을 체계적으로 다룹니다. 이러한 다양한 차원을 아는 것은 ML 엔지니어가 시스템을 더 잘 이해하고 더 나은 선택을 하는 데 도움이 될 것입니다.

알고리즘의 품질 vs 데이터의 품질 및 양

ML의 미래가 (지금까지 그래왔듯이) 데이터의 품질과 양에 의해 계속 주도될 것인지, 아니면 학습 알고리즘의 품질에 의해 주도될 것인지에 대한 큰 논쟁이 있습니다. 후자 진영에서는 컴퓨팅 파워의 증가로 더 똑똑하고 강력한 알고리즘이 등장할 것이며, 이것이 더 낮은 품질과 양의 데이터를 보완할 것이라고 생각합니다.
논쟁은 여전히 진행 중입니다. 그러나 현재로서는 데이터의 품질과 양이 필수적이라는 것을 아무도 부인할 수 없습니다. 이것이 머신 러닝의 가장 기본적인 요구 사항이 (모델 학습 자체가 아니라) 모두 데이터와 관련된 이유입니다.

데이터 과학의 요구 계층. 모니카 로가티(Monica Rogati)의 이미지에서 각색함

데이터 소스

ML 시스템을 구동하는 데이터는 일반적으로 다양한 소스에서 나옵니다. 소스는 다음과 같이 분류할 수 있습니다.

사용자 입력 데이터: 텍스트, 이미지, 비디오, 파일 등 형식이 매우 다양합니다. 형식이 맞지 않는(Malformed) 데이터가 매우 흔합니다.
시스템 생성 데이터: 로그 및 시스템 출력(메모리 사용량, CPU 사용량 등), 그리고 클릭, 스크롤링, 확대/축소, 페이지 체류 시간과 같은 사용자 행동에 대한 메타데이터.
- 사용자 데이터보다 형식이 잘못될 가능성이 적습니다.
- ML 시스템 디버깅은 어렵기 때문에, 가능한 모든 것을 로깅하는 것이 일반적인 관행입니다.
- 엄청난 양의 시스템 생성 데이터에는 두 가지 과제가 있습니다. 노이즈 속에서 신호(signal)를 찾아내는 것과 대량의 로그를 저장하는 방법입니다.
내부 데이터베이스: 비즈니스를 운영하기 위해 소프트웨어 서비스에서 사용하는 데이터베이스입니다.
제2자(Second-party) 데이터: 다른 회사가 자사 고객에 대해 수집한 데이터로, 귀하가 사용할 수 있게 제공된 데이터입니다.
제3자(Third-party) 데이터: 기업이 자사 고객이 아닌 대중에 대해 수집한 데이터입니다. 예를 들어, 계정을 개설하지 않았더라도 휴대폰의 모든 행동을 추적하는 앱입니다.

데이터 형식

형식의 선택은 사람이 읽을 수 있는지(human readability), 검색 속도, 전송 속도 및 저장 비용에 영향을 줍니다.
사용할 데이터 형식을 결정할 때, 데이터가 미래에 어떻게 사용될지 생각하고 합리적인 형식을 선택하십시오.

형식	바이너리/텍스트	사람이 읽을 수 있음	사용 예시
JSON	텍스트	예	모든 곳
CSV	텍스트	예	모든 곳
Parquet	바이너리	아니요	Hadoop, Redshift
Avro	바이너리(주)	아니요	Hadoop
Protobuf	바이너리(주)	아니요	Google, TensorFlow
Pickle	바이너리	아니요	Python, PyTorch 직렬화

널리 사용되는 데이터 형식 샘플

JSON

매우 인기가 있습니다. 너무 인기가 많아서 그로 인한 어려움이 모든 곳에서 느껴집니다.
가독성이 좋고 매우 유연합니다.
데이터를 커밋할 때, 데이터를 읽는 측(reader)에서 가정해야 할 스키마도 암묵적으로 커밋하게 됩니다.
이미 저장된 데이터의 스키마를 나중에 변경하는 것은 매우 고통스럽습니다.

텍스트 vs 바이너리 형식

텍스트 형식은 사람이 읽을 수 있지만 크기가 더 큽니다. 이는 전송 및 검색이 더 느리다는 것을 의미합니다.
바이너리 형식은 더 압축적이지만 읽을 수 없습니다. 압축률이 높다는 것은 더 빠른 전송, 더 빠른 검색 및 더 작은 디스크 공간 차지를 의미합니다.

행 우선(Row-major) vs 열 우선(Column-major) 형식

행 우선(Row-major):
- CSV는 행 우선 형식입니다. 특정 샘플(example)의 모든 피처(feature)를 가져오기는 매우 쉽지만, 단일 피처의 모든 값을 가져오기는 매우 어렵습니다.
- 행 우선 형식은 쓰기(write) 작업이 잦을 때 더 좋습니다. 대부분의 소비자 애플리케이션은 많은 쓰기 작업을 필요로 합니다.
열 우선(Column-major):
- 단일 피처에 대한 모든 값이 함께 저장됩니다. 단일 피처의 모든 값을 검색하기는 매우 쉽지만, 단일 샘플에 대한 모든 피처를 검색하기는 어렵습니다.
- 열 우선 형식은 열 단위 읽기(read) 작업을 많이 할 때 더 좋습니다. 단일 피처의 모든 값을 검색하는 것은 ML에서 매우 일반적인 작업입니다.
Pandas vs NumPy
- Pandas는 종종 오해를 받습니다. Pandas는 열 우선 형식을 기반으로 구축되었습니다. Pandas는 행 반복(row iteration)을 위해 만들어지지 않았기 때문에 이 작업은 매우 느립니다.
- NumPy에서는 ndarray에서 메모리 저장 순서(major order)를 지정할 수 있지만 기본적으로는 행 우선입니다.

데이터 모델

SQL vs NoSQL 데이터 모델은 잘 문서화된 주제이므로 깊게 다루지 않겠습니다. 핵심 데이터 모델은 다음과 같습니다.

관계형 데이터 모델(Relational data models): 스키마가 사전에 결정됩니다.
NoSQL 데이터 모델: 사전에 결정된 스키마가 없습니다. 스키마를 가정해야 하는 책임은 데이터를 읽는 애플리케이션으로 넘어갑니다.
- 문서 모델(Document Model)
- 그래프 모델(Graph Models)

스키마가 없는(schema-less) 데이터 모델 같은 것은 없다는 점에 유의하십시오. 누군가는 항상 데이터의 스키마를 가정해야 합니다. 차이점은 쓰기 시점(write time)에 스키마를 인지해야 하는지, 아니면 읽기 시점(read time)에 인지해야 하는지입니다.

정형 데이터(Structured data)	비정형 데이터(Unstructured data)
스키마가 명확하게 정의됨	데이터가 스키마를 따를 필요가 없음
여러 조인(join)이 포함되면 읽기가 느릴 수 있음. 쓰기는 데이터를 스키마에 맞게 변환해야 함. 임의의 검색 및 분석이 쉬움.	쓰기가 간단함. 스키마 준수가 필요 없음. 함께 저장된 데이터(예: 동일한 키 하에)의 읽기는 빠름. 임의의 검색 및 분석이 어려움. 데이터를 저장하는 방법을 결정할 때 액세스 패턴에 대해 생각해야 함.
기존 데이터를 새 스키마로 이관(porting)해야 하므로 스키마 변경이 어려움.	스키마 변경 시 데이터 마이그레이션에 대해 걱정할 필요가 없음. 대신 읽기 시에 이 문제를 걱정해야 함. 왜냐하면 데이터를 읽는 측(reader)이 모든 스키마 버전을 처리할 수 있어야 하기 때문임.
처리되어 바로 사용할 수 있는 형식의 정형 데이터 저장소를 데이터 웨어하우스(data warehouse)라고 함.	원시(raw) 비정형 데이터를 저장하는 데 사용되는 저장소를 데이터 레이크(data lake)라고 함. 이 데이터는 사용 준비가 되기 전에 처리되어야 함.

데이터 웨어하우스 VS 데이터 레이크 주제에 대한 자세한 내용은 ETL 섹션에 있습니다.

데이터베이스 엔진

일반적으로 데이터베이스는 트랜잭션 처리(즉, 온라인 트랜잭션 처리 OLTP) 또는 분석 처리(즉, 온라인 분석 처리 OLAP)에 최적화되어 있습니다.
OLTP 데이터베이스는 일반적으로 데이터 무결성, 신뢰성 및 대용량 트랜잭션 작업에 매우 뛰어난 ACID 데이터베이스입니다. 또한 일반적으로 단일 행과 관련된 작업이 매우 효율적인 행 우선 데이터베이스입니다.
- 전통적인 OLTP 데이터베이스는 여러 행에 걸쳐 열의 데이터를 집계해야 하는 분석적 질문에 답하는 데는 취약합니다. 예: "SF에서 9월의 모든 차량 공유 평균 가격은 얼마인가?"
OLAP 데이터베이스는 위의 문제를 해결하기 위해 설계되었으며 임의의 행 간 집계 쿼리에 매우 효율적입니다.
- 그러나 반대로 OLAP 데이터베이스는 단일 행 작업, 대용량 작업에 취약하므로 소비자 애플리케이션용 DB와 같은 온라인 트랜잭션 작업에는 좋은 솔루션이 아닙니다.
OLTP vs OLAP 구분은 점점 덜 중요해지고 있습니다.
- 1. 기술이 향상되어 이제 분석 쿼리에도 능한 트랜잭션 데이터베이스(예: CockroachDB)가 있고, 그 반대(예: Apache Iceberg 또는 DuckDB)도 마찬가지입니다.
- 2. 전통적인 데이터베이스 엔진 패러다임은 데이터 저장소와 데이터 처리가 결합(coupled)된 구조였습니다. 이는 데이터베이스 엔진이 데이터가 저장되는 방식과 데이터가 읽히고 처리되는 방식 모두를 다룬다는 것을 의미합니다. 만약 다른 유형의 처리가 필요했다면, 해당 유형의 처리에 최적화된 다른 데이터베이스 엔진으로 데이터를 복제해야만 했습니다. 저장소와 처리(즉, 컴퓨팅)를 분리(decouples)하는 새로운 패러다임이 매우 인기를 얻게 되었습니다. 이는 데이터가 다양한 유형의 쿼리에 최적화된 여러 처리 레이어(processing layers)를 위에 둔 채 동일한 장소에 저장될 수 있음을 의미합니다. BigQuery, Snowflake, Teradata는 모두 이러한 분리된 패러다임을 사용할 수 있는 DB의 예입니다. 2022년 6월 기준, 이 제공업체 중 어느 곳도 OLTP용으로 자사 DB를 사용하는 것을 권장하지 않습니다.

데이터 처리 (ETL)

다양한 데이터 소스에서 추출(Extract)하고, 원하는 형식으로 변환(Transform)하며, 변환된 데이터를 원하는 대상(예: 데이터베이스, 파일 또는 데이터 웨어하우스)으로 로드(Load)합니다.

추출(Extracting) 단계

데이터를 검증하고 요구 사항을 충족하지 않는 것은 모두 거부하십시오. 초기에 검증하고 거부하면 후속 단계에서 많은 작업을 절약할 수 있습니다.
많은 데이터가 거부되면 소스에 알려야 할 수도 있습니다.

변환(Transform) 단계

여러 소스의 데이터를 조인(Join)합니다.
값과 범위를 표준화합니다. 예를 들어, "Male"과 "Female" vs "M"과 "F"를 통일합니다.
추가 검증, 전치(transpose), 중복 제거(deduplicate), 정렬, 집계(aggregate), 새로운 피처를 파생합니다(derive new features).

로드(Load) 단계

변환된 데이터를 대상 목적지에 어떻게, 그리고 얼마나 자주 로드할 것인지 결정합니다.

데이터 레이크의 흥망성쇠

데이터를 정형화된 형식으로 유지하는 데 어려움을 겪으면서, 일부 기업들은 다음과 같은 아이디어를 냈습니다: "스키마 변경에 대처할 필요가 없도록 모든 원시 데이터를 그냥 데이터 레이크에 저장하면 어떨까? 데이터가 필요한 애플리케이션은 그냥 거기서 원시 데이터를 꺼내어 처리하면 된다." 이는 때때로 추출, 로드, 변환(ELT)이라고도 불립니다.
이 패러다임은 원하는 데이터를 얻기 위해 방대한 양의 원시 데이터를 검색하는 것이 매우 비효율적이기 때문에 인기를 잃어가고 있습니다. 또한 데이터를 읽는 측(reader)이 다양한 원시 데이터 형식의 암묵적인 스키마를 따라잡기가 매우 어렵습니다.
하이브리드 데이터 레이크 + 데이터 웨어하우스 솔루션이 등장하기 시작했으며, 기업들에게 두 가지 옵션을 모두 제공합니다. Databricks와 Snowflake 모두 하이브리드 솔루션을 제공합니다.

데이터 흐름의 방식

메모리를 공유하지 않는(메모리가 분리된) 서로 다른 프로세스 간에 데이터를 어떻게 전달할까요?

데이터베이스를 통한 데이터 전달

프로세스 A가 데이터베이스에 데이터를 쓰고, 프로세스 B가 동일한 데이터베이스에서 데이터를 읽습니다.
이 방식의 두 가지 문제점:
- 두 프로세스가 동일한 DB에 연결되고 스키마를 공유해야 합니다. 예를 들어 DB가 서로 다른 회사 소유인 경우에는 이것이 불가능합니다.
- 여러 프로세스가 동일한 DB에서 읽고 쓰면 쿼리가 느려질 수 있습니다. 이는 지연 시간에 민감한 앱(즉, 거의 모든 소비자 대상 앱)에는 적합하지 않습니다.

서비스를 통한 동기식 데이터 전달

API 호출(REST 또는 RPC)을 통한 데이터 전달. 마이크로서비스 아키텍처에서 일반적입니다.
서로 다른 회사의 서비스 간에도 데이터 전달을 허용합니다.
이 방식의 문제점:
- 복잡한 호출 그래프(call graph)가 쉽게 만들어져 신뢰성 문제를 야기할 수 있습니다. 서비스 하나가 다운되면, 그와 연결된 많은 서비스가 함께 다운됩니다.
- 네트워크를 통한 데이터 전달은 전체 시스템을 느리게 할 수 있습니다.

서로 의존하는 단 3개의 서비스만으로도 복잡한 호출 그래프가 생성될 수 있습니다.

실시간 전송(이벤트)을 통한 데이터 전달

요청 기반(Request-driven) 아키텍처는 데이터보다 로직에 더 많이 의존하는 시스템에 잘 작동합니다. 이벤트 기반(Event-driven) 아키키처는 데이터 중심적인(data-heavy) 시스템에 더 잘 작동합니다. 이것이 실시간 전송이 프로덕션 환경의 ML에서 매우 일반적인 이유입니다.
실시간 전송의 가장 일반적인 두 하위 유형은 pub-sub(발행-구독)과 메시지 큐(message queues)입니다.
Pub-sub: 서비스가 토픽(topic)에 이벤트를 발행(publish)합니다. 데이터를 생성하는 서비스는 누가 그것을 소비(consume)할지에 대해 신경 쓰지 않습니다. Kafka와 Kinesis가 그 예입니다.
메시지 큐: 메시지(즉, 이벤트)는 종종 의도된 소비자(consumer)를 갖습니다. 메시지 큐는 메시지를 올바른 소비자에게 전달하는 책임을 집니다. RocketMQ와 RabbitMQ가 그 예입니다.

배치 처리(Batch Processing) vs 스트림 처리(Stream Processing)

ML 프로덕션 시스템에서의 데이터 배치 처리는 일반적으로 데이터 웨어하우스나 데이터 레이크에 저장된 비실시간 데이터(즉, 과거 데이터)를 사용하여 피처를 계산하는 데 사용됩니다.
- 이러한 피처는 실시간으로 변경될 필요가 없기 때문에 종종 정적 피처(static features) 또는 배치 피처(batch features)라고 불립니다. 예를 들어, 평균 드라이버 평점을 하루에 한 번 재계산하는 것은 괜찮습니다.
- MapReduce와 Spark는 배치 처리 엔진의 예입니다.
ML 프로덕션 시스템에서의 데이터 스트림 처리는 값이 빠르게 변하거나 실시간으로 필요한 피처를 계산하는 데 사용됩니다. 데이터가 데이터 웨어하우스에 도착하고 배치 작업이 이를 선택하여 계산할 때까지 기다릴 수 없으므로, 실시간 이벤트를 기반으로 계산을 수행해야 합니다.
- 이러한 피처는 종종 스트리밍 피처(streaming features) 또는 동적 피처(dynamic features)라고 불립니다.
- Apache Flink, KSQL, Spark Streaming은 스트림 처리 기술의 예입니다.
프로덕션 환경의 ML 시스템은 두 가지 유형의 데이터 처리를 모두 필요로 할 수 있습니다.

4 - 학습 데이터

이 장에서는 좋은 학습 데이터를 만들기 위한 다양한 기술을 다룹니다.

학습용 데이터 선택을 위한 샘플링 기술
학습 데이터의 일반적인 문제 해결 방법:
- 레이블링(Labelling) 문제
- 클래스 불균형(Class imbalance) 문제
- 데이터 부족 문제 및 데이터 증강(data augmentation)

학습 데이터를 만드는 것은 반복적인 과정입니다. 프로젝트 라이프사이클에 걸쳐 모델이 발전함에 따라, 학습 데이터도 함께 발전할 것입니다.

샘플링(Sampling)

샘플링은 워크플로우의 여러 단계에서 발생합니다. 예를 들면:

좋은 학습 데이터를 만들기 위해 가능한 모든 실제 데이터에서 샘플링합니다.
일관된 학습(train), 테스트(test), 검증(validation) 세트를 만들기 위해 주어진 데이터셋에서 샘플링합니다.
모니터링 목적으로 ML 시스템을 통해 흐르는 모든 가능한 이벤트에서 샘플링합니다.

비확률적 샘플링(Non-probability Sampling)

비확률적 샘플링은 나쁜 아이디어입니다. 선택된 샘플은 실제 데이터를 대표하지 않으므로 선택 편향(selection biases)으로 가득 차 있습니다. 이는 ML 모델의 성능을 저하시키고 불공정하게 만듭니다.

여기서는 여러분이 식별하고 피할 수 있도록 일반적으로 사용되는 몇 가지 비확률적 샘플링 방법을 설명합니다.

편의 샘플링(Convenience Sampling)

데이터의 가용성에 따라 샘플을 선택합니다. 이 샘플링 방법은 이름 그대로 편리하기 때문에 인기가 있습니다.

눈덩이 샘플링(Snowball Sampling)

기존 샘플을 기반으로 미래의 샘플을 선택합니다. 예를 들어, 초기 시드(seed) 계정 세트로 시작하여 그들이 팔로우하는 사람들을 스크래핑함으로써 트위터 계정을 점진적으로 수집합니다.

판단 샘플링(Judgement Sampling)

전문가가 어떤 샘플을 포함할지 결정합니다.

할당 샘플링(Quota Sampling)

무작위화(randomisation) 없이 특정 데이터 조각(slice)에 대한 할당량을 기반으로 샘플을 선택합니다. 예를 들어, 실제 연령 분포와 관계없이 30세 미만, 30세에서 60세 사이, 60세 이상 각 연령 그룹에서 100개의 응답을 강제로 선택합니다.

확률적 샘플링(Probabilistic Sampling)

확률적 샘플링은 좋은 아이디어입니다. 사용할 특정 샘플링 유형은 사용 사례에 따라 다릅니다.

단순 무작위 샘플링(Simple random sampling)

각 샘플에 p%의 선택 확률을 부여하여 모집단의 p%를 선택합니다.

장점:
- 구현이 매우 간단합니다.
- 샘플링된 데이터가 모집단의 분포를 따릅니다.
단점:
- 희귀 클래스(rare classes)가 제외될 확률이 높습니다. 이렇게 샘플링된 데이터로 학습된 모델은 희귀 클래스가 존재하지 않는다고 생각할 수 있습니다.

층화 샘플링(Stratified sampling)

모집단을 관심 있는 그룹으로 나눈 다음 각 그룹의 항목에 p%의 선택 확률을 부여하여 샘플링합니다.

장점:
- 레이블이 아무리 희귀하더라도 해당 샘플이 샘플에 포함되도록 보장합니다.
단점:
- 샘플을 그룹으로 깔끔하게 분리할 수 없는 경우(예: 다중 레이블(multi-label) 작업) 사용할 수 없습니다.

가중 샘플링(Weighted sampling)

각 샘플에 서로 다른 선택 확률을 부여합니다. 예를 들어, 레이블 A를 가진 모든 요소는 50%의 확률을, B는 30%의 확률을, C는 20%의 확률을 갖게 합니다.

Python에서는 random.choice의 weights를 사용할 수 있습니다.

import random 
random.choices(
    population=[1, 2, 3, 4, 100, 1000],
    weights=[0.2, 0.2, 0.2, 0.2, 0.1, 0.1],
    k=2
)

장점:
- 도메인 지식(domain knowledge)을 ML 시스템에 통합하는 데 사용할 수 있습니다. 예를 들어, 더 최신 데이터가 더 가치 있다는 것을 안다면 더 높은 가중치를 부여합니다.
- 사용 가능한 데이터의 잘못된 분포를 수정하고 샘플링된 데이터가 실제 분포와 일치하도록 만드는 데 사용할 수 있습니다. 예를 들어, 사용 가능한 데이터가 여성 75%, 남성 25% 레이블을 가지고 있지만 실제 분포는 50/50%라는 것을 안다고 가정해 봅시다. 이를 수정하기 위해 남성 예제에 더 많은 가중치를 부여하는 가중 샘플링을 사용하여 분포를 바로잡을 수 있습니다.
단점:
- 신중하게 사용하지 않으면 데이터에 편향을 심을 수 있습니다.
참고:
- 가중 샘플링(Weighted sampling)은 샘플 가중치 부여(sample weighting)와 다릅니다. 샘플 가중치는 학습 중에 특정 샘플이 다른 샘플보다 알고리즘의 손실 함수(loss function)에 더 많은 영향을 미치도록 하는 데 사용됩니다. 결정 경계(decision boundary)에 가까운 샘플에 더 높은 학습 가중치를 부여하면 알고리즘이 결정 경계를 더 잘 학습하는 데 도움이 될 수 있습니다.
- #todo : 가중 샘플링이 클래스 불균형과 어떤 관련이 있는가?

스트림 샘플링을 위한 저수지 샘플링(Reservoir sampling)

데이터 스트림에서 연속적인 샘플링 데이터셋을 만드는 데는 다음과 같은 과제가 있습니다.

모집단의 크기를 미리 알 수 없습니다. 하지만 좋은 관행에 따라, 데이터셋의 모든 샘플이 동일한 선택 확률을 갖도록 하고 싶을 것입니다.
샘플 데이터셋에 새 샘플을 영원히 추가할 수 없습니다. 어느 시점에는 메모리가 부족해질 것입니다.
언제든지 연속 샘플링을 중지할 수 있어야 하며, 데이터셋의 각 요소는 올바른 확률로 샘플링되었어야 합니다.

저수지 샘플링 알고리즘은 위에서 언급한 과제들을 극복하면서 k개 요소의 데이터셋을 지속적으로 샘플링할 수 있게 해줍니다. k는 사용 가능한 메모리 양에 의해 제한됩니다.

처음 k개의 요소를 저수지(reservoir)에 넣습니다.
들어오는 각 n번째 요소에 대해 1 ≤ i ≤ n인 난수 i를 생성합니다.
1 ≤ i ≤ k이면: 저수지의 i번째 요소를 n번째 요소로 교체합니다. 그렇지 않으면 아무것도 하지 않습니다.

레이블링(Labelling)

좋은 레이블링은 매우 중요한 부분입니다. 일부 회사(예: Tesla)는 사내에 레이블링 팀을 두기도 합니다.

수동 레이블링은 여러 문제점을 안고 있으며, 그중 다수는 좋은 해결책이 없습니다. 만약 문제가 허락한다면, 자연 레이블을 사용하거나 레이블 부족 처리하기에서 설명하는 기술을 사용하여 이러한 문제를 우회하십시오.

수동 레이블(Hand labels)

문제 1: 수동 레이블링은 비쌉니다. 특히 레이블을 생성하기 위해 해당 분야 전문가(예: X-레이를 분류하는 의사)가 필요한 경우 더욱 그렇습니다.
문제 2: 수동 레이블링은 데이터 프라이버시에 위협이 됩니다. 누군가가 집계되지 않은(non-aggregated) 데이터에 접근해야 합니다. 이로 인해 레이블링을 아웃소싱하기가 더 어려워지고 보안 보증 부담이 추가됩니다.
문제 3: 수동 레이블링은 느립니다. 느린 레이블링은 느린 반복 속도로 이어지고, 이는 다시 모델이 변화하는 환경에 덜 적응하게 만듭니다. 레이블링 프로세스가 오래 걸릴수록 기존 모델 성능은 더 저하됩니다.
문제 4: 레이블 다중성(Label multiplicity): 서로 다른 작업자(annotators)가 서로 다른 데이터 소스의 데이터에 레이블을 지정하게 하면 레이블 모호성(label ambiguity)이 발생할 수 있습니다.
- 작업자 간의 의견 불일치는 매우 흔합니다.
- 요구되는 도메인 전문 지식 수준이 높을수록 의견 불일치 가능성이 커집니다.
- 부분적 해결책: 이를 최소화하는 가장 좋은 방법은 작업자에게 명확한 문제 정의와 지침을 제공하는 데 세심한 주의를 기울이는 것입니다.
문제 5: 데이터 계보(Data lineage)가 잊히는 경향이 있습니다. 예를 들어, 레이블 품질이 좋은 10만 개의 샘플을 사용하여 좋은 모델을 학습시켰다고 가정해 봅시다. 그런 다음 레이블링을 위해 100만 개의 샘플을 추가로 아웃소싱했습니다. 불행히도 아웃소싱된 레이블의 품질은 낮았습니다(하지만 당신은 그것을 모릅니다). 그런 다음 데이터를 혼합하여 110만 개의 샘플로 동일한 모델을 학습시킵니다. 마지막으로, 품질이 낮은 레이블링의 결과로 모델 성능이 저하되었음을 발견합니다. 설상가상으로 데이터를 혼합했기 때문에 이로부터 복구할 수 없습니다.
- 해결책: 데이터 계보 관행을 사용하십시오. 각 데이터 샘플의 출처와 해당 레이블의 출처를 추적하십시오. 이를 추적하면 데이터 문제를 디버깅하는 데 도움이 될 수 있습니다.

자연 레이블(Natural labels)

어떤 문제들은 시스템에 의해 자동으로 파생되거나 근사(approximated)될 수 있는 자연적인 정답 레이블(natural ground truth labels)을 가지고 있습니다.

어떤 문제들은 다른 문제들보다 더 강력한 자연 레이블을 가집니다.
레이블 근사는 명시적(explicit) 또는 암묵적(implicit) 레이블링을 사용하여 수행될 수 있습니다. 명시적 레이블링은 사용자에게 어떤 방식으로든 레이블을 제공하도록 요청한다는 것을 의미합니다.
강력한 자연 레이블의 예:
- 구글 맵의 도착 예정 시간(ETA)은 실제 이동 시간으로 검증될 수 있습니다.
- 주가 예측은 검증될 수 있습니다.
약한 자연 레이블의 예 (일반적으로 근사가 필요함):
- 추천 시스템은 일반적으로 제안이 받아들여졌는지(긍정적 레이블) 또는 정의된 시간 창 내에 받아들여지지 않았는지(암묵적 부정적 레이블)를 기록함으로써 자연 레이블이 근사되도록 허용합니다.
- 뉴스피드 랭킹 문제에서, 자연 레이블은 '좋아요'와 '싫어요' 버튼을 추가함으로써 근사될 수 있습니다. 이는 명시적 근사의 경우입니다.
기업들은 ML을 시작할 때 자연 레이블이 있는 문제에 대해 작업하는 것을 선택하는 경향이 있습니다. 왜냐하면 이러한 문제가 더 다루기 쉽고 비용이 적게 드는 경향이 있기 때문입니다.

피드백 루프 길이(Feedback loop length)

자연 레이블이 있는 문제에서, 피드백 루프는 예측이 제공된 시점부터 해당 샘플의 정답 레이블을 파생하거나 근사할 수 있을 때까지의 시간입니다.

정답 레이블이 몇 분 내에 사용 가능하다면, 이는 짧은 피드백 루프으로 간주됩니다.
피드백 루프가 짧은 문제는 작업하기가 더 쉽고, 변화하는 요구사항과 데이터 분포에 더 잘 적응하는 시스템을 생성합니다.
- 이는 모든 문제에 해당됩니다. 레이블을 더 빨리 얻을 수 있다면, 당신의 삶은 더 쉬워질 것입니다.

강력한 레이블이 있는 문제

강력한 자연 레이블이 있는 문제를 다룰 때, 이 루프의 길이는 대개 문제의 본질에 의해 결정됩니다. 예를 들면:

주식 예측은 몇 분 내에 검증될 수 있습니다.
구글 맵의 ETA 예측은 시간 단위로 검증될 수 있습니다.
사기 탐지(Fraud detection)는 거래가 발생한 지 몇 달 후에 분쟁 프로세스가 완전히 종료되기 때문에 긴 자연 피드백 루프를 가집니다.

레이블 근사가 필요한 문제

레이블을 근사하려는 시도는 일반적으로 몇 가지 트레이드오프를 고려한 결정이 필요합니다.

근사를 위한 사용자 피드백 유형 선택

사용자 여정(user journey)의 여러 지점에서 다양한 신호를 사용하여 레이블을 근사할 수 있습니다. 신호마다 양(volume), 강도(strength) 및 루프 길이(loop length)가 다릅니다.

예를 들어, 제품 추천 시스템에서 레이블을 생성하기 위해 "제품을 클릭함"을 사용할 수 있습니다. 대안으로 "제품을 구매함" 신호를 사용할 수 있습니다. 클릭은 더 자주 발생하고(즉, 더 많은 데이터) 더 짧은 피드백 루프를 갖지만, 구매는 훨씬 더 가치 있는 신호입니다.

여기에는 정답이 없습니다. 트레이드오프를 따져보고 결정을 내려야 합니다.

암묵적 근사를 위한 시간 창(time window) 선택

어떤 일이 일어나지 않았기 때문에 암묵적으로 레이블을 추론해야 하는 문제는 매우 흔합니다. 이러한 경우, 우리는 보통 부정적인 레이블이 할당되는 시간 창을 선택해야 합니다(예: 사용자가 추천된 영화를 보지 않음).

더 짧은 시간 창 = 더 짧은 피드백 루프 + 목표 행동이 임의의 시간 창 제한 이후에 발생했기 때문에 더 높은 오분류(mislabeling) 가능성.

레이블 부족 처리하기(Handling the Lack of Labels)

이 섹션에서는 충분한 고품질 레이블을 얻는 어려움을 해결하기 위해 개발된 4가지 범주의 기술을 다룹니다. 이들 중 하나 또는 여러 개를 동시에 사용할 수 있습니다.

개요:

약 지도(Weak Supervision) 레이블링

이 유튜브 비디오는 매우 흥미로운 일부 반복적인 방식을 포함하여 약 지도를 위한 여러 가지 방식(arrangements)을 설명합니다.

https://www.youtube.com/watch?v=SS9fvo8mR9Y

TL/DR(요약)은 다음과 같습니다.

약 지도의 아이디어는, 비록 학습에 사용하는 레이블이 다소 노이즈가 있더라도, 대량의 데이터를 사용하여 학습된 시스템이 작지만 완벽한 데이터셋을 가진 모델보다 성능이 더 좋은 경향이 있다는 가정에 의해 동기 부여됩니다. 이는 특히 모델이 동일한 모델의 이전 반복이나 전이 학습 모델(예: 언어 모델)과 같은 사전 학습된 모델에서 재학습되거나 파인 튜닝(fine-tune)되는 경우에 더욱 그렇습니다.

개략적인 단계는 다음과 같습니다.

당신(또는 해당 분야 전문가)이 몇 가지 단순화를 사용하여 자동으로 데이터에 레이블을 지정하는 일련의 휴리스틱(heuristics)을 개발합니다. 이러한 각 휴리스틱을 labelling_function (LF) 내부에 래핑합니다. 서로 다른 휴리스틱이 서로 모순될 수 있으며, 일부는 특정 샘플에 레이블을 지정하는 데 다른 것보다 더 나을 수 있습니다. 이 모든 것은 괜찮습니다.
```
def labelling_function(example_note):
    if "pneumonia" in example_note:
  return true
```
레이블을 지정하려는 데이터에 레이블링 함수 세트를 적용합니다.

몇 가지 유형의 레이블링 함수:
- 키워드 휴리스틱: 샘플에 키워드가 있는가?
- 정규 표현식: 샘플이 정규식과 일치하는가?
- 데이터베이스 조회: 문자열에 위험한 질병 목록과 일치하는 문자열이 포함되어 있는가?
- 이전에 학습된 모델의 출력. 이것은 소수의 수동 레이블 데이터로 학습된 간단한 모델이거나 이전 반복 모델의 출력일 수 있습니다.

Snorkel과 같은 도구는 레이블링 함수에 의해 생성된 모든 다른 "레이블 투표"를 받아들여 그들 사이의 상관 관계를 학습하고 레이블의 확률 벡터(예: [80% 검은색, 10% 녹색, 10% 흰색])를 출력할 수 있습니다. 본질적으로 Snorkel이 하는 일은 레이블 가능성(label likelihoods)을 얻기 위해 모든 LF의 투표를 결합하고, 노이즈를 제거하고, 가중치를 재조정하는 것입니다.
그런 다음 출력된 확률 벡터를 사용하여 큰 모델을 학습시킵니다.

장점:
- 수동 레이블 불필요: 이론적으로는 약 지도에 수동 레이블이 필요하지 않습니다. 그러나 LF의 정확도를 확인하기 위해 소량의 수동 레이블 샘플을 갖는 것이 권장됩니다.
- 프라이버시: 약 지도는 데이터에 엄격한 프라이버시 요구 사항이 있을 때 매우 유용합니다. LF를 생성하기 위해 몇 개의 샘플만 보면 되며, 나머지는 자동으로 수행될 수 있습니다.
- 속도: LF로 많은 데이터에 레이블을 지정하는 것은 (수동 레이블링에 비해) 매우 빠릅니다.
- 적응성: 변경 사항이 발생하면, LF를 변경하고 모든 데이터에 다시 적용하기만 하면 됩니다. 수동 레이블링을 했다면 전체 재레이블링이 필요할 것입니다.
- LF를 사용하면 해당 분야의 전문 지식을 통합하고 그것을 버전 관리하고, 재사용하고, 공유할 수 있습니다.
단점:
- 너무 노이즈가 많은 레이블: 때때로 레이블이 너무 노이즈가 많아 유용하지 않을 수 있습니다. 설상가상으로, 수동으로 레이블이 지정된 작은 데이터 세트가 없다면, 노이즈가 있는 레이블이 얼마나 나쁜지 알 수 없습니다.

준지도 학습(Semi-Supervision)

개념적으로, 준지도 학습은 초기 레이블 세트를 시드(seed)로 사용하여 어떤 방법을 통해 레이블이 없는 더 많은 데이터에 레이블을 지정하는 것입니다.

다음은 준지도 학습 구현의 3가지 예입니다.

자가 학습(Self-training): 레이블이 지정된 데이터 시드를 사용하여 모델을 학습시킵니다 → 해당 모델을 사용하여 레이블이 없는 일부 데이터에 대한 레이블을 생성합니다 → 원본 확률(raw probability)이 높은 샘플을 학습 세트에 추가합니다 → 모델 성능에 만족할 때까지 이를 반복합니다.
클러스터링을 통한 레이블링: 레이블이 지정된 데이터 포인트와 가깝게 클러스터링되는 레이블이 없는 데이터 포인트는 동일한 레이블을 공유한다고 가정합니다.
교란(Perturbation): 샘플에 대한 작은 교란(perturbation)이 레이블을 변경해서는 안 된다고 가정합니다. 따라서 학습 인스턴스에 작은 교란을 적용하여 새로운 학습 인스턴스를 생성합니다. 이것은 데이터 증강의 한 형태로도 간주될 수 있습니다.

전이 학습(Transfer learning)

한 작업을 위해 개발된 모델이 두 번째 작업의 모델을 위한 시작점으로 재사용됩니다. 첫 번째 작업은 대개 저렴하고 풍부한 학습 데이터를 가지고 있습니다.

전이 학습은 대규모 신경망 모델이 작업 변경에 매우 견고(robust)한 경향이 있다는 아이디어에 기반합니다. 예를 들어, 위키피디아에서 학습된 영어 언어 모델은 NLP 작업이 위키피디아와 아무 관련이 없더라도 유용할 것입니다.
대규모 말뭉치(corpus)로 구축된 언어 모델(예: BERT)은 전이 학습의 일반적인 예입니다.
작업에 맞게 기본 모델을 파인 튜닝(fine-tuning)하는 것은, 예를 들어 자신의 작업을 위한 자신의 데이터로 모델의 전체 또는 일부를 계속 학습시키는 것과 같이 기본 모델을 약간 변경하는 것을 의미할 수 있습니다.
전이 학습은 학습하는 데 수천만 달러가 들었을 수도 있는 모델을 무료로 사용할 수 있게 해주기 때문에 많은 관심을 받았습니다.
일반적으로 사전 학습된 기본 모델이 클수록 다운스트림 작업에서의 성능이 더 좋습니다.

능동 학습(Active learning)

능동 학습은 다른 샘플보다 레이블을 지정하는 데 더 가치 있는 샘플이 있다는 아이디어에 기반합니다. 예를 들어, 결정 경계(decision boundary)에 더 가까운 샘플은 모델이 경계를 더 잘 학습할 수 있게 해주기 때문에 더 가치가 있습니다.

능동 학습에서는 모델이 레이블을 지정해야 할 샘플을 자동으로 알려줍니다. 능동 학습 구현의 몇 가지 예는 다음과 같습니다.

레이블이 없는 데이터 세트에 모델을 적용하고, 모델이 확실성이 가장 낮은(예: 원본 확률이 낮은) 샘플을 선택하여 레이블을 지정하고 학습 데이터에 추가하도록 합니다.
레이블이 없는 데이터 세트에 앙상블 모델을 적용하고, 합의(consensus)가 가장 적은 샘플을 선택하여 레이블을 지정합니다. 앙상블은 서로 다른 데이터 조각으로 학습된 모델, 또는 서로 다른 하이퍼파라미터로 학습된 모델, 또는 완전히 다른 모델로 구성될 수 있습니다.
일부 능동 학습 기술은 모델이 불확실성 영역에 있는 샘플을 합성(synthesise)하도록 허용합니다.
일부 회사는 프로덕션에서 평가되는 데이터로 능동 학습을 적용합니다. 프로덕션에서 실행 중인 모델이 방금 본 샘플에 대해 그다지 확신하지 못하는 경우, 해당 샘플은 레이블링 대상으로 플래그 지정됩니다.

클래스 불균형(Class Imbalance)

분류 작업에서의 클래스 불균형: 학습 데이터의 각 클래스에 있는 샘플 수에 상당한 차이가 있을 때 발생합니다.
회귀 작업에서의 클래스 불균형: 예: 병원비 비용을 추정하는 작업의 경우, 수집된 데이터의 대부분이 100달러에서 1000달러 범위에 속하고 1만 달러가 넘는 천문학적인 청구서에 대한 데이터는 거의 없습니다. 아무것도 하지 않으면, 모델은 높은 청구서 범위에서 매우 틀리는 것을 감수하더라도 데이터가 더 많은 범위를 더 잘 맞추는 경향이 있을 것입니다.

클래스 불균형의 원인

자연적으로 불균형한 문제: 자연적으로 심하게 불균형한 문제는 실제 세계에서 매우 흔합니다(예: 암 탐지, 사기 탐지, 모든 이상 징후 탐지 문제). 문제를 더 어렵게 만드는 것은, 이러한 많은 문제에서 소수 클래스를 올바르게 예측하는 것이 다수 클래스를 예측하는 것보다 훨씬 더 중요하다는 것입니다(예: 암 탐지). 이것이 클래스 불균형의 가장 흔한 원인입니다.
편향된 샘플링으로 인한 불균형: 문제가 자연적으로 심하게 불균형하지 않을 수도 있지만, 데이터를 샘플링하는 방식이 데이터를 불균형하게 보이게 만들 수 있습니다. 예를 들어, 트윗이 스팸인지 식별하는 모델을 만들고 싶다고 상상해 보십시오. 직접 데이터셋을 구축하기 위해 공개 트위터를 스크래핑하면 아주 적은 비율의 트윗만이 스팸임을 발견할 수 있습니다. 이것은 실제 분포가 아닐 수도 있습니다. 대부분의 스팸 트윗은 트위터 자체 알고리즘에 의해 공개되기 전에 삭제되기 때문에 데이터가 불균형하게 보이는 것입니다. 샘플링 섹션에는 샘플링의 함정을 피하는 방법에 대한 더 많은 정보가 있습니다.
레이블링 오류로 인한 불균형: 작업자가 지침을 잘못 읽고 한 클래스를 다른 클래스보다 훨씬 적게 사용할 수 있습니다. 이것은 가장 드문 원인입니다.

클래스 불균형이 문제가 되는 이유

아무런 조정도 하지 않으면, ML 알고리즘은 균형 잡힌 데이터셋에서만큼 심하게 불균형한 데이터셋에서는 잘 작동하지 않습니다. 왜 그럴까요?

알고리즘이 소수 클래스에 대해 작동하는 파라미터를 학습하기에 불충분한 신호를 가질 수 있습니다. 소수 클래스에 대한 학습은 퓨샷 학습(few-shot learning) 문제가 됩니다.
알고리즘이 학습 중에 항상 다수 클래스를 반환하는 것과 같은 간단한 휴리스틱을 이용하는 최적이 아닌 솔루션에 머무를(stuck) 수 있습니다.
ML 알고리즘의 기본 동작은 모든 클래스의 오분류를 동일하게 취급하며 학습 중에 클래스 중요도를 인코딩할 방법이 없습니다. 이는 소수 클래스의 오분류가 치명적인 결과를 초래할 수 있는 작업(예: 흉부 X-레이에서의 암 진단)에 문제가 됩니다.

일부 작업은 다른 작업보다 클래스 불균형에 더 민감합니다. 일반적으로 모델이 복잡할수록 불균형에 더 민감합니다. 그 반대도 마찬가지입니다. 단순하고 선형적으로 분리 가능한 문제는 클래스 불균형에 민감하지 않습니다.

클래스 불균형 처리하기

어떤 사람들은 그것이 실제 데이터의 모습이라면 클래스 불균형을 "고치려고" 해서는 안 된다고 주장할 수 있습니다. 그들은 모델이 그 불균형을 처리하는 법을 배워야 한다고 주장합니다. 그러나 이러한 조건에서 좋은 성능을 내는 모델을 개발하는 것은 어려울 수 있으므로, 우리는 여전히 특별한 학습 기술에 의존해야 합니다.

클래스 불균형을 다루는 3가지 상위 수준 접근 방식이 있습니다. (1) 올바른 지표 선택하기, (2) 데이터 수준 방법, (3) 알고리즘 수준 방법.

올바른 지표 선택하기

클래스 불균형이 있을 때 모든 클래스를 동일하게 취급하는 지표를 사용하는 것은 나쁜 생각입니다. 왜냐하면 지표가 다수 클래스에 의해 주도될 것이기 때문입니다. 이것은 다수 클래스가 우리가 신경 쓰는 클래스가 아닐 때 특히 나쁩니다. 나쁜 지표의 전형적인 경우는 전체 정확도(accuracy)를 사용하는 것입니다. 예를 들어, X-레이의 90%를 올바르게 분류할 수 있는 암(CANCER) 탐지 모델은 대부분의 샘플이 암이 아니기(NON-CANCER) 때문에, 암 탐지 능력에 대해 거의 알려주지 못합니다.

이에 대한 해결책은 우리가 신경 쓰는 클래스에 초점을 맞춘 클래스별 지표를 사용하는 것입니다. 정밀도(Precision), 재현율(Recall), F1 점수는 모두 사용할 수 있는 클래스별 지표입니다.

임계값 설정(Thresholding)

분류 모델의 출력이 확률과 같은 연속 변수인 경우, 임계값(threshold)을 사용하여 알고리즘의 정밀도와 재현율을 선택할 수 있습니다. 이 선택은 실제로 우리가 중요한 클래스에 얼마나 신경을 쓰는지, 그리고 다른 클래스의 오분류에 대해 얼마나 관대할 수 있는지에 따라 결정됩니다.

이 임계값 선택에 사용되는 두 가지 일반적인 도구는 ROC 곡선과 정밀도-재현율(precision-recall) 곡선입니다.

참고로, 임계값을 사용할 수 있도록 분류 문제를 회귀 문제로 쉽게 프레이밍할 수 있습니다.

데이터 수준 방법: 리샘플링(resampling)

데이터 수준 방법은 불균형을 줄이기 위해 데이터의 원래 분포를 수정합니다. 리샘플링은 이를 위해 사용되는 가장 일반적인 기술 계열입니다. 여기에는 오버샘플링(소수 클래스의 인스턴스 추가)과 언더샘플링(다수 클래스의 인스턴스 제거)이 포함됩니다.

무작위 언더샘플링(Random undersampling): 원하는 균형을 이룰 때까지 다수 클래스에서 무작위로 인스턴스를 제거합니다.
무작위 오버샘플링(Random oversampling): 만족스러운 비율을 얻을 때까지 소수 클래스의 복사본을 무작위로 만듭니다.
토멕 링크(Tomek links): 저차원 데이터의 언더샘플링을 위한 기술입니다. 서로 다른 클래스를 가지면서 서로 가까이 있는 데이터 포인트 쌍을 찾아 다수 클래스의 샘플을 제거합니다.
- 알고리즘이 더 명확한 결정 경계를 학습하는 데 도움이 됩니다.
- 모델이 결정 경계의 미묘한 차이를 배울 기회를 얻지 못하므로 모델의 견고성(robustness)이 떨어집니다.
SMOTE (Synthetic minority oversampling technique): 소수 클래스 샘플들의 볼록(convex, ~선형) 조합을 수행하여 새로운 소수 클래스 샘플을 생성합니다.
토멕 링크, SMOTE 및 더 복잡한 리샘플링 기술은 저차원 데이터에서만 효과적인 경향이 있습니다. 거리 계산에 의존하는 기술은 차원이 높아질수록 계산 비용이 비싸집니다.

리샘플링의 위험

리샘플링된 데이터로 모델을 평가하지 마십시오. 수정된 데이터 분포로 모델을 학습시켰더라도, 모델의 실제 성능을 파악하려면 실제 분포를 따르는 데이터로 모델을 평가해야 합니다.
언더샘플링은 중요한 데이터를 버릴 위험이 있습니다.
오버샘플링은 데이터에 대한 과적합(overfitting)을 조장할 위험이 있습니다. 오버샘플링된 샘플이 복사본일 경우 특히 그렇습니다.

이러한 위험을 완화하는 기술

2단계 학습(Two-phase learning): 먼저 언더샘플링된 균형 잡힌 데이터로 모델을 학습시킵니다. 그런 다음 원본 데이터를 사용하여 학습을 파인 튜닝합니다.
동적 샘플링(Dynamic Sampling): 성능이 낮은 클래스는 오버샘플링하고 성능이 높은 클래스는 언더샘플링합니다. 이는 모델이 이미 알고 있는 것은 덜 보여주고 더 잘 배워야 하는 것은 더 많이 보여주려는 목적을 가집니다.

알고리즘 수준 방법

직관: 손실 함수는 학습 과정을 안내합니다. 우리는 모델이 학습 중에 자동으로 불균형을 처리하도록 돕기 위해 손실 함수를 수정할 수 있습니다.

비용 민감 학습(Cost-sensitive learning)

각 항목 Cij가 클래스 i가 클래스 j로 분류되는 비용인 비용 행렬(cost matrix)을 정의합니다. i=j이면 분류가 올바른 것이며 보통 0의 비용이 사용됩니다. 학습은 손실 최소화를 추구하므로, 학습 과정은 더 비싼 클래스의 오분류에 더 중점을 둘 것입니다.

이러한 프레이밍을 통해 "암(CANCER)을 정상(NORMAL)으로 오분류하는 것이 그 반대보다 20배 더 비용이 많이 든다"와 같은 도메인 지식을 자연스럽게 통합할 수 있습니다.

클래스 균형 손실(Class-balanced loss)

비용 민감 손실과 유사하지만, 오분류의 가중치(또는 비용)가 각 클래스의 샘플 수에 의해 결정됩니다.

가장 기본적인 형태에서, Wi(클래스 i에 대한 가중치)는 1 / N_samples_of_class_i입니다. 더 정교한 접근 방식은 기존 샘플 간의 중복을 고려하고 유효 샘플 수(effective number of samples)에 기반하여 계산할 수 있습니다.

포커스 손실(Focal loss)

직관: 올바른 클래스로의 분류 확률이 낮은 샘플에 더 많은 가중치를 부여하여, 모델이 여전히 분류하기 어려워하는 샘플에 집중하도록 장려합니다. 포커스 손실 방정식은 책을 참조하십시오.

데이터 증강(Data Augmentation)

데이터 증강은 학습 데이터의 양을 늘리는 데 사용되는 기술 계열입니다. 증강된 데이터는 종종 모델을 노이즈와 적대적 공격(adversarial attacks)에 더 견고하게 만드는 데 유용합니다.

적대적 공격은 누군가가 ML 모델을 속여 무언가를 잘못 분류하도록 만들기 위해 프로덕션 샘플을 조작하는 것입니다. 예를 들어, 이미지를 다르게 분류하게 하려고 이미지의 픽셀 몇 개를 변경하는 것입니다. 신경망은 특히 노이즈에 민감합니다.

데이터 증강은 컴퓨터 비전 작업의 표준이며 NLP 작업에서도 인기를 얻고 있습니다. 데이터 증강에는 (1) 레이블을 보존하는 간단한 변환, (2) 교란(perturbation), (3) 데이터 합성(data synthesis)의 세 가지 주요 유형이 있습니다. 각 유형에서 컴퓨터 비전과 NLP의 예를 모두 살펴볼 것입니다.

레이블을 보존하는 간단한 변환(Simple label-preserving transformations)

컴퓨터 비전에서: 레이블을 보존하면서 이미지를 무작위로 수정합니다. 회전, 자르기, 뒤집기, 반전, 이미지 일부 지우기 등을 생각해보십시오.
NLP에서: 문장의 의미를 바꾸지 않는 유사한 단어로 문장의 단어를 교체합니다. 유의어 사전, 워드넷(word net) 또는 유사한 워드 임베딩(word embedding)을 가진 다른 단어를 사용하여 "유사한" 단어를 선택할 수 있습니다.

교란(Perturbation)

컴퓨터 비전에서: 노이즈가 있는 샘플은 무작위 노이즈를 추가하거나 탐색 전략(예: 적대적 증강, Adversarial Augmentation)을 통해 생성될 수 있습니다. 적대적 증강에서는, 알고리즘이 레이블을 변경하기 위해 샘플에 수행해야 하는 최소한의 변경 횟수를 찾습니다. 그런 다음 모델을 더 견고하게 만들기 위해 변경된 샘플을 학습 데이터에 추가합니다.
NLP에서: 단어를 변경하거나 노이즈를 추가하면 문장의 의미가 바뀔 가능성이 높기 때문에 NLP에서는 교란이 덜 일반적입니다.

교란은 준지도 학습 맥락과 오프라인 평가 맥락에서도 사용될 수 있습니다.

데이터 합성(Data synthesis)

컴퓨터 비전에서 일반적인 기술은 서로 다른 레이블을 가진 두 이미지를 결합하여 새 이미지를 생성하는 것입니다. 이를 믹스업(mixup)이라고 합니다. 예를 들어, DOG 레이블이 0이고 CAT 레이블이 1인 경우, 반반씩 섞이고 레이블이 0.5인 믹스업 이미지를 만들 수 있습니다.
NLP에서 문자열 템플릿은 많은 양의 데이터를 저렴하게 생성할 수 있는 훌륭한 방법입니다. 예를 들어, "[LOCATION]에서 [NUMBER] 마일 이내의 [CUISINE] 레스토랑 찾아줘" 템플릿과 CUISINES 데이터베이스, 그리고 NUMBER와 LOCATION에 대한 적절한 파라미터를 사용하면 수천 개의 샘플을 생성할 수 있습니다.
신경망을 사용하여 데이터를 합성하는 것은 현재 흥미로운 연구 분야이지만, 아직 프로덕션 환경에서 인기가 있지는 않습니다.

5 - 피처 엔지니어링 (Feature Engineering)

일단 작동하는 ML 모델을 확보하고 나면, 피처 엔지니어링은 하이퍼파라미터 튜닝이나 영리한 알고리즘 기법을 사용하는 것보다 성능 향상에 가장 크게 기여하는 경향이 있습니다.

이 장에서는 다음 내용을 다룹니다.

피처 엔지니어링을 수행하는 동안 사용할 일반적인 작업 (예: 스케일링, 이산화, 결측치 처리 등).
데이터 누수(data leakage)의 함정을 피하는 방법.
피처 엔지니어링 모범 사례.

피처 엔지니어링은 한 번에 끝나는 작업이 아닙니다. 모델이 프로덕션 환경에 있는 한 피처 엔지니어링 작업은 계속됩니다. 9장에서는 새로 들어오는 데이터를 사용하여 모델을 지속적으로 개선하는 방법을 설명합니다.

피처 스토어(Feature stores)는 10장: MLOps를 위한 인프라 및 도구에서 다룰 것입니다.

학습된 피처(Learned Feature) VS 수동 피처(Engineered Features)

왜 피처 엔지니어링에 신경 써야 할까요? 딥 러닝은 더 이상 피처를 수동으로 만들 필요가 없다고 약속하지 않았나요?

네, 딥 러닝은 원시 데이터(raw data)에서 자동으로 피처를 추출할 수 있습니다. 하지만 2022년 현재, 우리는 모든 피처가 자동으로 학습될 수 있는 시점과는 아직 거리가 멉니다. 더욱이, 2022년 현재 프로덕션 환경의 ML 대다수는 딥 러닝이 아닙니다. 이러한 점을 감안할 때, 신중하게 수동으로 만들어진(handcrafted) 피처 엔지니어링은 여전히 프로덕션 ML에서 매우 중요합니다.

어떤 피처를 학습할 수 있고, 어떤 피처를 여전히 수동으로 만들어야 하는가?

원시 텍스트와 원시 이미지의 벡터화(Vectorization)는 학습될 수 있는 피처의 매우 일반적인 두 가지 예입니다. 그러나 프로덕션 애플리케이션에서 벡터화된 원시 데이터가 필요한 유일한 피처인 경우는 거의 없습니다. 이러한 벡터는 일반적으로 자동으로 추출할 수 없는 상당수의 피처(예: '좋아요' 수, 계정 연령, 답글 수 등)로 보강됩니다. 이 모든 다른 피처들은 여전히 수동으로 만들어야 합니다.

은행 사기 탐지와 같이 많은 도메인 전문 지식이 필요한 애플리케이션 역시 수동 피처가 여전히 필요한 일반적인 경우입니다. 이러한 경우, ML 엔지니어는 일반적으로 도메인 전문가와 긴밀히 협력하여 피처를 결정합니다.

일반적인 피처 엔지니어링 작업

이 섹션에서는 데이터로부터 피처를 엔지니어링하는 동안 고려할 수 있는 가장 중요한 몇 가지 작업을 논의합니다. 여기에 나열된 기술이 전부는 아닙니다. 하지만 좋은 출발점이 될 것입니다.

결측치(missing values) 처리

피처에 결측치가 있는 것은 매우 흔한 일입니다. 그러나 모든 결측치가 동일하지는 않으며, 결측치의 유형은 처리 방법에 영향을 미칩니다.

다음 예시를 통해 결측치의 유형과 결측치 처리 기술을 설명하겠습니다.

결측치의 유형

MNAR (Missing Not At Random)

값이 누락된 이유가 값 자체와 관련이 있는 경우입니다. 예를 들어, 고소득자는 자신의 소득을 공개하는 것을 좋아하지 않습니다. 또 다른 일반적인 예는 특정 질병을 앓고 있는 사람들이 그 정보를 공개하기를 꺼리는 경우입니다.

MAR (Missing At Random)

값이 누락된 이유가 값 자체가 아니라 관측된 다른 변수 때문인 경우입니다.

위 예에서, 우리는 성별 A를 가진 사람들이 자신의 나이를 공개하는 것을 좋아하지 않는다는 것을 알 수 있습니다.

MCAR (Missing Completely At Random)

결측치가 어떤 패턴도 따르지 않는 경우입니다. 예를 들어, 사람들이 특별한 이유 없이 때때로 그 값을 채우는 것을 잊어버리는 경우입니다. 그러나 이런 유형의 결측은 매우 드뭅니다. 특정 값이 누락되는 데에는 보통 이유가 있으며, 이를 조사해야 합니다.

결측치 처리 기술

결측치를 처리하는 가장 일반적인 두 가지 기술은 삭제(deletion)와 대치(imputation)입니다.

결측치를 처리하는 완벽한 방법은 없다는 것을 명심하십시오. 모든 기술에는 장단점(tradeoffs)이 있으며 위험을 초래합니다.

삭제(Deletion)

열(Column) 삭제

변수에 결측치가 너무 많으면 해당 변수를 제거합니다 (즉, 열을 삭제).
장점: 수행하기 쉽습니다.
단점: 중요한 피처를 제거하여 모델의 정확도를 떨어뜨릴 수 있습니다.

행(Row) 삭제

샘플에 결측치가 있으면 해당 샘플을 제거합니다 (즉, 행을 삭제).
이 기술은 결측치가 MCAR이고 제거할 샘플 수가 적을 때 (예: 0.1% 미만) 작동합니다.
장점: 수행하기 쉽습니다.
단점:
- MNAR인 결측치의 행을 삭제하면 모델에 중요한 정보가 제거됩니다. 위 예에서, 연간 소득이 없는 샘플을 제거한다는 것은 아마도 고소득자이기 때문에 소득 공개를 원하지 않았던 사람들의 샘플을 제거한다는 의미입니다.
- MAR인 결측치의 행을 삭제하면 모델에 편향(bias)이 생길 수 있습니다. 위 예에서, 나이가 누락된 모든 샘플을 제거하면 성별 A를 가진 모든 샘플도 제거됩니다. 이는 모델이 성별 A를 가진 사람들에 대해 좋은 예측을 만들지 못한다는 것을 의미합니다.

대치(Imputation)

결측 데이터를 특정 값으로 채웁니다. 어떤 값을 사용할지 결정하는 것이 어려운 부분입니다.
단점: 데이터에 편향을 주입하거나, 노이즈를 추가하거나, 데이터 누수를 만들 수 있습니다.

기본값으로 대치

누락된 문자열에 빈 문자열을 사용하는 것처럼 합리적인 기본값으로 결측 데이터를 채웁니다.
실제로 유효한 값으로 결측치를 채우는 것을 피하십시오. 예를 들어, 누락된 "자녀 수" 값을 0으로 채우지 마십시오. 0은 "자녀 수"에 대해 가능하고 (심지어) 흔한 값입니다.

평균(mean), 중앙값(median) 또는 최빈값(mode)으로 대치

열의 평균, 중앙값 또는 최빈값으로 결측 데이터를 채웁니다.
다른 관련 변수를 고려하여 평균을 계산하는 등 더 정교한 작업을 수행할 수도 있습니다. 예를 들어, 누락된 온도를 해당 기록의 월 평균 온도로 채웁니다.

ML을 통한 대치

다른 행을 피처로 사용하여 간단한 분류기(classifier)나 회귀 모델(regressor)을 만들어 결측 데이터에 대한 가장 가능성 있는 값을 예측할 수 있습니다.

스케일링(Scaling)

일반적으로, 우리는 모든 피처가 비슷한 크기 정도(order of magnitude)를 갖기를 원합니다. 이는 (급여처럼) 선천적으로 숫자가 큰 피처가 (나이처럼) 숫자가 작은 피처를 수치적으로 압도하는 것을 방지하기 위해 수행합니다.

스케일링은 종종 성능 향상을 가져올 수 있으며, 이를 수행하지 않으면 의미 없는(gibberish) 예측을 초래할 수 있습니다.

일반적인 스케일링 기술은 다음과 같습니다.

임의의 범위로 스케일링 (예: [0, 1] 또는 [-1, 1]). 저자(Chip)는 경험적으로 후자가 더 잘 작동한다는 것을 발견했습니다.
정규 분포로 스케일링 (평균 0, 분산 1). 변수가 정규 분포를 따르는 경우 이 방법을 사용하십시오.
로그 변환(Log transformations)은 변수의 분포가 심하게 치우쳐(skewed) 있을 때 유용합니다. ML 모델은 일반적으로 치우친 분포를 다루기 어려워합니다.

스케일링에 대해 유의해야 할 중요한 사항:

스케일링은 데이터 누수의 일반적인 원인입니다.
스케일링은 min과 max를 찾는 것과 같이 데이터셋의 전역 통계(global statistics)를 필요로 합니다. 대규모 데이터셋에서는 전역 통계를 계산하기가 항상 쉽지는 않습니다.
스케일러는 학습 데이터(training data)를 사용하여 구축되어야 하며 예측 데이터(prediction data)에는 "있는 그대로" 적용되어야 합니다. 예측 시점의 피처 분포가 학습 시점과 다르면, 스케일러는 의미 없는 데이터를 출력할 수 있습니다. 이는 스케일러와 모델을 재학습해야 한다는 신호입니다.

연속형 피처의 이산화(Discretization)

이산화는 "저소득: 연 3만 5천 미만"과 같은 "버킷(buckets)"을 만들어 연속형 피처를 이산형(discrete) 피처로 바꾸는 과정입니다.

이론적으로, 이렇게 하는 동기는 알고리즘이 "무한한" 연속적인 소득 가능성을 다루는 것보다 적은 수의 범주(예: 저소득, 중소득, 고소득)를 다루는 것이 더 쉽기 때문입니다. 이 이점은 학습 데이터가 제한적일 때 더 클 것으로 예상됩니다.

단점:

저자는 실제로 이산화가 큰 도움이 되는 것을 보지 못했다고 말합니다.
이산화는 범주 경계에서 불연속성(discontinuities)을 도입하여, 경계에 가까운 연속 변수의 작은 변화가 매우 다르게 처리되도록 만듭니다.
버킷을 선택하는 것은 간단하지 않습니다(not trivial). 히스토그램에서 도출하거나, 기본 사분위수(quantiles)를 사용하거나, 해당 분야 전문 지식(subject matter expertise)을 사용할 수 있습니다.

범주형 피처 인코딩 (Encoding Categorical Features)

범주형 피처 인코딩에는 쉬운 경우와 어려운 경우가 있습니다.

학습 중에 존재했던 범주의 수가 프로덕션에서도 동일하다고 보장될 때는 쉽습니다.
피처가 프로덕션에서 학습 때보다 더 많거나 다른 범주를 가질 수 있을 때 훨씬 더 어려워집니다. 이는 브랜드 이름, 사용자 이름, 제품 유형 등을 피처로 사용할 때 매우 흔합니다. 일반적으로, 프로덕션에서 범주에 새 항목이 동적으로 생성될 수 있을 때 발생합니다.

쉬운 경우: 정적 범주 (Static categories)

범주 수가 시간이 지나도 변하지 않을 때는 인코딩 처리가 쉽습니다. 일반적인 방법은 각 범주 값에 고유한 번호를 할당하고, 필요시 원-핫 인코딩(one-hot encoding)을 수행하는 것입니다.

어려운 경우: 동적 범주 (Dynamic categories)

동적 범주의 인코딩을 잘못 처리하는 일반적인 두 가지 방법이 있습니다.

정적 방식과 동일하게 처리하는 것: 정적 인코더를 구축하고, 프로덕션에서 사용하며, 잘 되기를 바랍니다. 이는 이전에 보지 못했던 범주 값(예: 새 브랜드)을 만나자마자 프로덕션에서 모델이 충돌(crash)하게 만들 가능성이 높습니다.
UNKNOWN(알 수 없음) 범주를 추가하는 것: 이렇게 하면 모델이 충돌하는 것을 막을 수 있습니다.
- 모델을 UNKNOWN 샘플로도 학습시켜야 합니다. 그렇지 않으면 모델이 충돌하지는 않겠지만, 학습 중에 UNKNOWN 피처 값을 본 적이 없으므로 해당 관측치에 대한 예측은 쓸모없게 됩니다.
- 위와 같이 하더라도, UNKNOWN 브랜드를 가진 관측치에 대한 모델 성능은 저조하고 빠르게 저하될 것입니다. 예를 들어, 학습 후에 프로덕션에서 30개의 새 브랜드가 등록될 수 있습니다. 일부는 잘 알려진 브랜드이고 일부는 모조품(knockoff) 브랜드일 수 있습니다. 이들 모두가 UNKNOWN 버킷 내에서 동일하게 처리되어 예측 품질이 저하될 것입니다.

해결책: 해싱 트릭 (The hashing trick)

직관: 알려진 해시 공간(예: 18비트 = 262,144개의 가능한 매핑 값)을 가진 해싱 함수(hashing function)를 사용하여 범주를 값에 매핑합니다.

해싱 트릭은 일종의 '트릭'이기 때문에 일반적으로 대학에서 가르치지 않습니다. 그러나 프로덕션 ML에 매우 유용한 것으로 입증되었으며 Vowpal Wabbit, SKLearn, TensorFlow, Gensim과 같은 도구에 포함되어 있습니다.

모든 해싱 함수와 마찬가지로, 서로 다른 두 범주가 동일한 값으로 인코딩될 수 있습니다 (즉, 충돌(collision)). 문제가 될 것처럼 들리지만, 연구에 따르면 충돌이 모델 성능에 미치는 영향은 생각보다 나쁘지 않습니다. Booking.com의 연구에 따르면 50%의 충돌률은 로그 손실(log-loss)을 0.5% 증가시키는 데 그쳤습니다 (책에는 연구 결과를 보여주는 그래프가 있습니다).

충돌을 줄이기에 충분히 큰 해시 공간을 선택할 수 있습니다. 또한 유사한 범주(예: 이름이 비슷한 웹사이트)가 서로 가까운 값으로 해시되는 LSH(locality-sensitive hashing) 함수와 같이 원하는 속성을 가진 해시 함수를 선택할 수도 있습니다.

해싱 트릭은 지속적인 학습(continual learning) 환경에서 특히 유용할 수 있습니다.

피처 교차 (Feature Crossing)

두 개 이상의 피처를 결합하여 새로운 피처를 생성합니다.
피처를 결합하면 피처 간에 존재하는 비선형성(non-linearities)을 줄이는 데 도움이 될 수 있습니다. 이는 결과적으로 선형 회귀(linear regression), 로지스틱 회귀(logistic regression), 트리 기반(tree-based) 모델과 같이 비선형 관계 학습에 취약한 모델에 큰 도움이 됩니다.
신경망(neural networks)에서는 비선형성을 제거하는 것이 덜 중요하지만, 명시적인 피처 교차는 신경망이 비선형성을 더 빨리 학습하는 데 도움이 될 수 있습니다.

피처 교차의 위험

피처 교차는 피처 공간을 폭발적으로 증가시킬 수 있습니다. 예: 100개의 가능한 값을 가진 피처와 100개의 가능한 값을 가진 다른 피처를 교차하면 10,000개의 교차 피처 공간이 생성됩니다.
교차 후에는, 교차된 각 값에 대응하는 샘플 수가 훨씬 적어집니다. 이 모든 가능한 값에 대해 유용한 것을 학습하려면 훨씬 더 많은 데이터가 필요합니다.
피처 교차는 모델이 학습 데이터에 과적합(overfit)하는 데 기여할 수 있습니다.

이산형(Discrete) 및 연속형(Continuous) 위치 임베딩

위치 임베딩(Positional Embeddings)은 이제 컴퓨터 비전과 NLP 작업의 표준입니다. NLP 예제를 사용하여 이 주제를 논의할 것입니다.

신경망(NN)과 합성곱 신경망(CNN)이 입력을 처리하는 방식은 시퀀스(예: 단어)의 순서가 신경망에 암묵적으로 알려진다는 것을 의미합니다. 그러나 트랜스포머(transformers)와 같은 모델에서는 모든 단어가 병렬로 처리되므로 단어의 위치가 명시적으로 입력되어야 합니다.

시퀀스 내 요소의 위치는 이산형(예: 첫 번째 토큰, 두 번째 토큰)일 수도 있고 연속형(예: 위치 1.35의 요소)일 수도 있습니다.

순진한(Naive) 이산형 위치 임베딩: 인덱스 사용

순진한 접근 방식은 인덱스(예: 0, 1... k)를 사용하여 토큰의 위치를 설명한 다음, 신경망에서 사용할 수 있도록 [-1, 1]과 같은 범위로 스케일링하는 것입니다.

이 접근 방식에는 몇 가지 문제가 있습니다.

긴 시퀀스의 경우, 위치 간의 수치적 차이가 너무 작아집니다. 이로 인해 NN이 한 위치와 다른 위치의 차이를 구별하기 어렵습니다.
스케일링은 시퀀스 길이에 따라 달라지는 함수입니다. 이는 주어진 위치(예: 위치 2)에 대한 인코딩이 길이가 5인 시퀀스와 길이가 100인 시퀀스에서 다를 것임을 의미합니다.

고정(Fixed) 이산형 임베딩

고정 이산형 임베딩에서는 각 요소의 위치가 벡터로 표현됩니다. 이 벡터는 일반적으로 단어 임베딩 벡터와 동일한 길이(예: 512개 요소)이며, 어떤 시퀀스 길이에 대해서도 완전히 사전 계산(precomputed)될 수 있습니다.

NN에서 이를 사용하려면, 단어 임베딩에 해당 위치 임베딩이 더해집니다. 이 연산의 출력이 나머지 네트워크의 입력으로 사용됩니다.

고정 위치 임베딩의 계산은 sine 및 cosine 함수를 사용하므로 벡터의 각 요소는 [-1, 1] 사이입니다. 아래 이미지는 이것이 어떻게 계산되는지에 대한 간략한 개요를 보여줍니다. 자세한 설명은 이 훌륭한 포스트에서 찾을 수 있습니다.

학습된(Learned) 이산형 임베딩

이들은 고정 이산형 임베딩과 동일한 방식(즉, 단어 임베딩과 위치 임베딩을 함께 더함)으로 사용됩니다. 그러나 위치 임베딩을 사전 계산하는 대신, 임베딩이 학습 중 역전파(back propagation)를 통해 학습됩니다.

이것이 Hugging Face의 BERT에서 위치 임베딩이 구현되는 방식입니다.

연속형(Continuous) 임베딩

위치가 연속형일 때 임베딩을 학습하는 것은 매우 어렵습니다. 그러나 고정된(사전 계산된) sine 및 cosine 기반 임베딩은 여전히 작동합니다. 이는 푸리에 피처(Fourier Features)라고도 알려져 있으며, 고정 이산형 임베딩은 일반적인 연속형 사례의 특별한 경우일 뿐입니다.

데이터 누수 (Data Leakage)

데이터 누수(Data leakage)는 모델이 데이터의 실제 레이블을 "누설하는" 정보를 악용하도록 학습함으로써 학습(training), 검증(validation) 및 테스트(testing) 중에 불공정한 성능 이점을 얻는 경우입니다. 이 이점은 일반적으로 데이터가 수집, 처리 또는 분할된 방식으로 인한 부산물(artefact)입니다.

이 이점은 추론 시점(inference time)에는 사용할 수 없으므로, 프로덕션에서 모델이 예측 불가능하고 심각한 방식으로 실패하게 만듭니다. 이러한 누수는 검증 및 테스트 데이터셋이 문제의 일부일 수 있기 때문에, 검증 및 테스트 중에는 감지하기 어렵습니다.

데이터 누수의 일반적인 원인

시간 상관관계가 있는 데이터를 시간순이 아닌 무작위로 분할

지나치게 단순화된 예: 이전 6일간의 다른 모든 주식의 움직임을 기반으로 구글 주가를 예측한다고 상상해 보십시오. 데이터를 (시간순이 아닌) 무작위로 분할하면, 7일째의 다른 회사 주가까지 포함하게 되어 모델에게 미래 정보를 미리 알려주는 불공정한 이점을 주게 됩니다.

일반적으로, 레이블 값이 시간과 상관관계가 있다면, 데이터를 학습, 검증, 테스트 데이터셋으로 분할할 때 무작위가 아닌 시간순으로 분할하는 것이 좋습니다.

분할 전 스케일링

학습, 검증, 테스트로 분할하기 전에 피처를 스케일링하면, 스케일러는 모델에게 완전히 보이지 않아야 할 검증 및 테스트 세트의 데이터로부터 max, min, average 등과 같은 정보를 인코딩하게 됩니다.

이를 피하려면, 먼저 데이터를 분할하고 학습 데이터에 대해서만 스케일러를 구축하십시오. 그런 다음 학습 스케일러를 사용하여 다른 두 분할(검증, 테스트)을 스케일링하십시오. 어떤 사람들은 심지어 가정(assumptions)이 학습 과정에 누수되는 것을 피하기 위해 검증 및 테스트 세트에 대해 탐색적 데이터 분석(EDA)조차 수행해서는 안 된다고 주장합니다.

검증 또는 테스트 분할의 통계로 결측치 채우기

이는 위와 유사합니다. 대치(imputation) 프로세스에 검증 및 테스트 세트의 정보가 포함되기를 원하지 않습니다.

분할 전 데이터 중복 처리 미흡

데이터를 학습, 검증, 테스트 세트로 분할하기 전에 중복 또는 거의 중복되는 데이터를 제거하지 못하면, 모델이 학습 시와 검증/테스트 시에 동일한 샘플을 관찰하게 됩니다.

중복은 산업 및 연구 데이터셋에서 매우 흔합니다. CIFAR-100과 같은 일부 인기 있는 데이터셋에는 10%의 중복이 있었습니다.
데이터 중복은 수집 시점, 다른 데이터 소스 병합 시점 또는 처리 시점(예: 오버샘플링 시)에 발생할 수 있습니다.
분할하기 전과 분할한 후에(확인 차원에서) 항상 데이터 중복을 확인하십시오.
오버샘플링을 한다면, 데이터 분할 후에 수행하십시오.

그룹 누수 (Group leakage)

이는 예시를 통해 더 잘 설명됩니다. 한 환자가 일주일 간격으로 두 번의 폐 CT 스캔을 찍었을 수 있습니다. 두 CT 스캔 모두 데이터에 포함되며 아마도 동일한 레이블을 포함할 것입니다 (사실상 동일한 샘플입니다). 무작위로 분할하면, 하나의 CT 스캔은 학습 데이터에, 다른 하나는 검증/테스트 세트에 들어갈 수 있습니다.

이를 피할 수 있는 유일한 방법은 데이터가 어떻게 생성되었는지 이해하는 것입니다.

데이터 생성 과정에서의 누수

폐암 레이블링을 돕는 모델을 구축한다고 상상해 보십시오. 고도로 전문화된 종양 병원이 다른 덜 전문화된 병원들처럼 데이터를 공유합니다. 이 전문 병원의 CT 스캔 기계는 특별한 형식으로 CT 스캔을 생성합니다. 데이터가 올바르게 처리되지 않으면, 모델이 CT 스캔의 형식을 악용하여 레이블을 할당할 수 있습니다. 전문 병원의 CT 스캔이 양성 레이블을 포함할 가능성이 더 높기 때문입니다. 물론, 형식은 진단과 아무 관련이 없어야 합니다.

이를 피하려면, 학습에 영향을 주어서는 안 되는, 데이터 수집 방식에 대한 가짜 피처(pseudo-features)를 모델이 악용할 가능성을 줄이도록 데이터를 정규화(normalize)할 방법을 생각하십시오.

테스트 분할의 오용

모델의 최종 성능을 보고하는 것 외에, 새로운 피처에 대한 아이디어를 얻거나 하이퍼파라미터를 튜닝하는 등 다른 방식으로 테스트 분할을 사용한다면, 테스트 세트의 정보가 학습 과정으로 누수될 위험이 있습니다.

데이터 누수 탐지

타겟 변수(레이블)에 대한 각 피처 또는 피처 세트의 예측력을 측정하십시오. 만약 피처 또는 피처 세트가 레이블과 비정상적으로 높은 상관관계를 보인다면, 이 피처가 어떻게 생성되는지, 그리고 그 상관관계가 말이 되는지 조사하십시오.

이 예측력을 측정하는 한 가지 방법은 피처(또는 피처 세트)에 대한 절제 연구(ablation studies)를 수행하는 것입니다. 피처를 제거하고 모델 성능이 크게 저하되는지 확인합니다. 이에 대한 자세한 내용은 아래 피처 중요도 섹션에 있습니다.
모델에 새로운 피처가 추가될 때를 주의 깊게 살펴보십시오. 피처 추가로 인해 성능이 크게 향상된다면, 그것이 타당한지 조사하십시오.

좋은 피처 엔지니어링하기

일반적으로 피처를 추가하면 모델 성능이 향상됩니다. 그러나 피처가 너무 많으면 모델에 나쁠 수도 있습니다.

더 많은 피처 = 데이터 누수 가능성 증가
더 많은 피처 = 과적합(overfitting) 가능성 증가
더 많은 피처 = 모델 서빙에 더 많은 메모리 필요 = 더 많은 인프라 비용
더 많은 피처 = 실시간 피처(live features) 계산에 더 많은 계산 필요 = 더 많은 지연 시간(latency)
쓸모없는 피처는 기술 부채(technical debt)가 됩니다. 데이터 파이프라인에서 무언가 변경되면(예: 필드 누락), 해당 피처가 쓸모없음에도 불구하고 피처 계산 코드를 업데이트해야 할 수도 있습니다.

정규화(Regularization) (예: L1 정규화)는 쓸모없는 피처의 가중치를 0으로 줄일 수 있습니다. 그러나 실제로는 처음부터 포함하지 않는 것이 훨씬 좋습니다.

피처가 모델에 좋은지 평가할 때 고려해야 할 두 가지 요소는 피처 중요도(feature importance)와 보이지 않는 데이터에 대한 일반화(generalization)입니다.

피처 중요도 (Feature Importance)

피처 중요도를 측정하는 방법은 많습니다. 그러나 일반적으로 이들이 하려는 것은 피처 또는 피처 세트가 제거되었을 때 모델의 성능이 얼마나 저하되는지 측정하는 것입니다.

부스티드 트리(boosted trees)와 같은 고전적인 ML 알고리즘을 사용한다면, 이러한 알고리즘은 피처 중요도를 측정하는 내장 메커니즘을 가지고 있는 경향이 있습니다 (예: XGBoost).
모델에 구애받지 않는(model-agnostic) 방법으로는 SHAP (SHapley Additive exPlanations)을 사용할 수 있습니다.
- SHAP은 전반적인 피처 중요도뿐만 아니라 특정 예측에 대한 각 피처의 기여도도 알려줄 수 있습니다. 이는 모델이 왜 실수를 하는지 이해하는 데 매우 유용합니다.
Interpret ML은 SHAP 및 기타 설명 가능한 ML(Explainable ML) 기술을 구현한 오픈 소스 패키지입니다.
피처 중요도 기술은 데이터 누수 탐지 및 해석 가능성(interpretability)에도 유용합니다.
참고로, Facebook 광고 팀은 10개의 피처가 모델 피처 중요도의 50%를 차지하고, 마지막 300개의 피처는 전체 중요도에 1% 미만을 기여한다는 것을 발견했습니다.

피처 일반화 (Feature Generalization)

ML은 보이지 않는 데이터에 대한 예측이 전부이므로, 일반화가 잘 되는 피처가 바람직합니다. 그러나 모든 피처가 동일하게 일반화되지는 않습니다.

피처는 다른 모델에서도 사용될 수 있을 정도로 일반화될 수 있습니다. 그러나 피처가 얼마나 일반화 가능한지(generalizable)와 문제에 얼마나 특화되어 있는지(specific) 사이에는 본질적인 트레이드오프(trade-off)가 있습니다.

피처 일반화를 측정하는 것은 피처 중요도보다 훨씬 덜 과학적입니다. 직관과 해당 분야 전문 지식이 필요합니다.

전반적으로, 일반화와 관련하여 고려해야 할 2가지 측면이 있습니다. 피처 커버리지(feature coverage)와 피처 값의 분포(distribution of feature values)입니다.

피처 커버리지 (Feature coverage)

커버리지는 주어진 피처에 대해 값을 가진 샘플의 비율입니다. 피처에 null 값이 적을수록 커버리지는 높아집니다.

커버리지가 매우 낮으면 해당 피처는 일반화 가능성이 높지 않다는 것이 대략적인 경험 법칙입니다. 이 규칙에는 많은 예외가 있습니다. 아마도 가장 중요한 예외는 결측값이 무언가를 의미하는 경우(즉, 값이 MNAR인 경우)입니다. 이 경우, 값의 부재(absence)가 실제로 모델에 귀중한 의미를 전달합니다.
특정 피처에 대한 피처 커버리지가 학습 분할과 테스트 분할 간에 크게 다르다면, 이는 데이터가 동일한 분포에서 오지 않았음을 강력하게 나타내며, 아마도 데이터 분할을 다시 생각해야 할 필요가 있음을 의미합니다.

피처 값의 분포

피처의 null이 아닌 값들의 분포를 살펴보십시오. 학습 분할에서 본 분포가 테스트 분할의 분포와 거의 또는 전혀 겹치지 않는다면, 이 피처는 모델에 해를 끼칠 수도 있습니다.

이는 데이터를 시간순으로 분할해야 하는 모델에서 흔히 발생하는 문제입니다.

Generative AI Interview for Senior Data Scientists: 50 Key Questions and Answers

Jonas Kim — Tue, 06 May 2025 13:06:40 +0000

I’ve compiled 50 key questions and answers as a technical interview prep guide for senior data scientists in the field of generative AI.

I. Transformer Basics

Describe the main components of the Transformer architecture and explain how they overcome the limitations of RNNs/LSTMs.

Transformers overcome the parallel processing limitations and difficulty in capturing long-range dependencies of RNNs/LSTMs, which rely on sequential processing, through the self-attention mechanism. Self-attention simultaneously calculates the relationships between all token pairs in a sequence, enabling parallel processing and helping each token understand the context by utilizing information from the entire sequence. The main components are:
- Self-Attention: Each token assesses its relevance to all other tokens in the sequence, effectively capturing long-range dependencies and generating representations rich in contextual information.
- Multi-Head Attention (MHA): Performs self-attention multiple times in parallel. Each 'head' focuses on different feature subspaces or relationships in the input data, helping the model learn more diverse and complex patterns.
- Position-wise Feed-Forward Network (FFN): A fully connected neural network applied independently to the representation of each token after passing through the attention layer. It increases the model's representational power and adds computational depth through non-linear transformations.
- Add & Norm: Applies Residual Connections (adding the input and output of each sub-layer: self-attention, FFN) and Layer Normalization. This is essential for mitigating the vanishing/exploding gradient problem in deep networks and stabilizing training.
- Positional Encoding: Injects token position information into the self-attention mechanism, which lacks sequence order awareness, allowing the model to recognize the sequence order.
Thanks to the combination of these components, especially the parallelizable design, Transformers can effectively scale to large datasets and model sizes.
Explain the self-attention mechanism in detail. How is the attention matrix calculated using Query, Key, and Value vectors?

Self-attention is a mechanism that calculates weights indicating how relevant every other token in the input sequence is to the current token being processed. For each input token, three vectors are generated through learnable linear transformations: Query (Q), Key (K), and Value (V). The process for calculating attention weights is as follows:
1. Score Calculation: Compute the similarity between the Query vector (Q) of the current token and the Key vectors (K) of all tokens in the sequence (including itself). Typically, the Scaled Dot-Product Attention method is used, which involves taking the dot product and then dividing by the square root of the Key vector dimension. This yields the Attention Score.
2. Normalization: Apply the Softmax function to the calculated attention scores to create Attention Weights, which form a probability distribution summing to 1. These weights indicate how much 'attention' the current token should pay to each other token.
3. Weighted Sum: Compute a weighted average of the Value vectors (V) of all tokens, using their corresponding attention weights, to generate the final output representation for the current token. Through this process, each token obtains a rich representation that effectively incorporates contextual information from its surroundings.
How does Multi-Head Attention differ from single-head attention? What are its advantages?

Unlike single-head attention which performs a single attention operation, Multi-Head Attention (MHA) performs the attention mechanism multiple times in parallel. Each 'head' learns independent Query, Key, and Value projection matrices, allowing it to focus on different feature subspaces (e.g., syntactic relationships, semantic similarity) or representational aspects of the input data. The attention outputs calculated from each head are concatenated and then passed through an additional linear transformation to form the final output.

The main advantage of MHA is that it allows the model to simultaneously process and integrate information from various perspectives, enabling it to capture richer and more complex relationships than a single head could. This ultimately enhances the model's representational power and performance, and can also contribute to stabilizing the learning process.
Why is Positional Encoding necessary? Compare absolute and relative methods (e.g., RoPE, ALiBi).

Since the self-attention mechanism in Transformers does not consider the order of tokens (permutation invariance), Positional Encoding must be explicitly injected to allow the model to understand the position information of tokens within the sequence.
- Absolute Positional Encoding: Assigns a unique encoding vector to each token based on its fixed absolute position in the sequence. Examples include the sine and cosine functions proposed in the original Transformer paper, or learning embeddings for each position. While simple to implement, a drawback is potentially poorer generalization to sequence lengths unseen during training.
- Relative Positional Encoding: Encodes the relative distance or relationship between tokens instead of their absolute positions. This is often done directly within the attention mechanism.
  - RoPE (Rotary Position Embedding): Reflects relative position information by applying rotational transformations to the Query (Q) and Key (K) vectors based on the token's position.
  - ALiBi (Attention with Linear Biases): Models relative distance by adding a penalty (bias) proportional to the distance between tokens when calculating attention scores.
Relative methods generally tend to generalize better to varying sequence lengths and are preferred in modern Transformer architectures. ALiBi, in particular, is noted for its ease of implementation.
Distinguish between Encoder-only (e.g., BERT), Decoder-only (e.g., GPT), and Encoder-Decoder (e.g., T5) architectures. Describe their typical application areas.

Transformers are broadly classified into three architectures based on how their components (encoder, decoder) are combined, each with different information processing styles and primary applications.
- Encoder-Only Architecture (e.g., BERT): Processes the entire input sequence at once, considering bidirectional context (both preceding and succeeding tokens) when calculating the representation for each token. Primarily used for Natural Language Understanding (NLU) tasks where a deep understanding of the entire input is crucial (e.g., text classification, named entity recognition, question answering).
- Decoder-Only Architecture (e.g., GPT): Operates in an autoregressive manner, generating the output sequence one token at a time. When predicting each token, it only references the previously generated tokens (unidirectional or causal attention). Excels at Natural Language Generation (NLG) tasks like text generation, chatbots, and summarization.
- Encoder-Decoder Architecture (e.g., original Transformer, T5): The encoder processes the input sequence to compress contextual information, and the decoder references this information (typically via cross-attention) to generate the output sequence. Suitable for sequence-to-sequence tasks that transform an input sequence into a different output sequence (e.g., machine translation, document summarization).
What are the computational limitations of the vanilla Transformer, and what approaches exist to address them?

The main computational limitation of the Vanilla Transformer is that the self-attention operation's computation and memory requirements grow quadratically (O(N²)) with the sequence length (N). This is because attention scores must be calculated and stored for every pair of tokens. This makes the computational cost prohibitive for very long sequences (e.g., tens of thousands of tokens or more).
Various approaches have been proposed to overcome this limitation:
- Sparse Attention: Instead of calculating all token pairs, each token attends only to a limited number of other tokens based on a predefined pattern (e.g., neighboring tokens, tokens at specific intervals, some global tokens). This can reduce the complexity to O(N log N) or even O(N).
- Efficient / Linearized Attention: Uses mathematical techniques like kernel methods or low-rank approximation to approximate the attention result without explicitly computing the full attention matrix. Aims for linear or near-linear complexity.
- Hardware Optimization: Does not change the attention calculation itself but improves the actual computation speed by considering hardware characteristics, such as reorganizing the operation order to minimize GPU memory access (read/write) bottlenecks. FlashAttention is a prime example, significantly speeding up exact attention computation.
- Alternative Architectures: Research into new sequence modeling architectures with different scaling properties, such as State Space Models (SSMs), is also actively underway. These methods contribute to improving the scalability of Transformers, allowing them to process longer sequences efficiently and be applied to larger-scale problems.

II. Advanced LLM Architectures and Concepts

What are Scaling Laws (e.g., Kaplan, Chinchilla), and how do they inform pre-training resource allocation?

Scaling Laws describe the empirical relationship where the performance (typically measured by loss) of Large Language Models (LLMs) improves predictably with the resources invested, namely the compute budget, model size (number of parameters), and amount of training data (number of tokens). This relationship is often observed to follow a power law, making it possible to somewhat predict and plan for performance improvements based on resource allocation.
Notably, the Chinchilla paper had a significant impact by suggesting that to achieve optimal performance for a given compute budget, model size (parameters) and training data volume (tokens) should be scaled up together at roughly similar rates. This implies the importance of balancing the model's learning capacity (parameter count) with the content it learns from (data volume). This research suggested that many previous large models might have been oversized relative to their compute budget and undertrained on data ('under-trained' or 'compute-suboptimal'), implying better performance could have been achieved with the same compute budget by using smaller models trained on more data.
Therefore, scaling laws provide crucial empirical guidance for deciding how to allocate limited computational resources between model size and data volume during the pre-training phase. They emphasize that finding the balance point for optimal performance within a given budget is more important than simply building the largest possible model. However, it's important to note that these laws are estimates based on empirical observations, and the actual optimal ratio or degree of performance improvement can vary depending on factors like model architecture, data quality, and the target task.
What are emergent capabilities of LLMs? Provide examples.

Emergent Capabilities of LLMs refer to new abilities that seem to appear suddenly and unpredictably as the model's scale (parameter count, training data, compute) surpasses a certain threshold. These capabilities are not observed or are very weak in smaller models and are characterized by the fact that the model was not explicitly designed or directly trained to possess them.
Key examples include:
- Multi-step arithmetic operations and complex logical reasoning
- The ability to understand and follow complex instructions without specific fine-tuning
- Grasping subtle linguistic nuances like irony and humor
- Generating coherent code
- Chain-of-Thought reasoning, where the model explains its reasoning process step-by-step to solve a problem The discovery of these emergent capabilities provides a strong motivation for scaling up models, but their unpredictable nature also poses challenges for ensuring model safety, reliability, and controllability.
Explain the MoE architecture. What are its pros and cons compared to dense models?

A Mixture of Experts (MoE) model replaces some of the feed-forward network layers in a standard Transformer architecture with multiple, smaller, independent 'expert' networks. For each input token, a learnable routing network dynamically selects a small number of experts (usually 1-2) deemed most suitable to process that token. The outputs of the selected experts are then combined to form the final result.

Pros:
- Scalability: Allows for a significant increase in the total number of model parameters while limiting the number of parameters activated for processing each input token. This enables larger model capacity for roughly the same inference speed.
- Inference Efficiency: Since only a few experts participate in the computation for a given token, the inference computational cost (FLOPs) is much lower compared to a dense model of similar total parameter count.
- Expert Specialization: Potential for each expert network to learn to specialize in processing specific types of data or patterns.
Cons:
- Training and Implementation Complexity: Requires additional mechanisms (e.g., auxiliary loss functions) for load balancing to ensure all experts are utilized relatively evenly (avoiding situations where some experts are overused while others are idle). Achieving overall training stability can be challenging.
- Memory Requirement: Although only some experts are used for computation during inference, all expert parameters must be loaded into memory, requiring significantly more memory capacity than a dense model.
- Routing Overhead: The routing computation itself, assigning tokens to experts, can add some computational overhead.
- Parameter Efficiency: Sometimes, achieving the same performance level might require a larger total number of parameters compared to a dense model.
Explain how KV Caching, Multi-Query Attention, and Grouped-Query Attention improve inference efficiency.

KV Caching, Multi-Query Attention, and Grouped-Query Attention are techniques primarily aimed at improving inference efficiency during the autoregressive text generation process of decoder-only models.
- KV Caching: During autoregressive generation, calculating attention for predicting each new token requires attending to all previously generated tokens. KV Caching leverages the fact that the Key and Value vectors for previous tokens do not change. It stores these already computed Key and Value vectors in memory (cache) and reuses them in subsequent steps. This significantly reduces the computation by avoiding repeated Key/Value calculations for the entire sequence at every step. However, a drawback is that the memory occupied by the cache grows very large as the sequence length increases.
- Multi-Query Attention (MQA): In standard Multi-Head Attention (MHA), each attention head has its own Key and Value projection matrices. In MQA, all Query heads share a single Key and Value head (i.e., projection matrices). This reduces the size of the KV cache that needs to be stored by a factor equal to the number of heads, leading to significant savings in memory usage and memory bandwidth requirements.
- Grouped-Query Attention (GQA): GQA is a compromise between standard MHA and MQA. It divides the Query heads into several groups, and the Query heads within each group share one Key and Value head. The KV cache size is larger than MQA but much smaller than standard MHA. This allows for significant memory savings while mitigating the potential quality degradation that can occur with MQA, often achieving a better performance balance than MQA.

III. Advanced Training and Fine-tuning Techniques

How do data cleaning, preprocessing, and tokenizer choice (e.g., BPE) impact LLM training and performance?

Data quality and the way it's processed have a decisive impact on LLM training outcomes and final performance. Since the model learns directly from the provided data, any flaws, biases, or noise within the data will also be learned. Therefore, meticulous data preprocessing is essential for high-quality LLMs. Key steps include:
- Data Cleaning: Correcting noise (e.g., removing HTML tags), inconsistencies, and formatting errors.
- Deduplication: Removing duplicate content within the training data to improve learning efficiency and prevent the model from simply memorizing data.
- Quality Filtering: Identifying and removing low-quality or inappropriate content (e.g., profanity, spam).
- Handling Personal and Sensitive Information: Removing or masking personally identifiable information (PII) or sensitive content.
Tokenizer Choice is also crucial. The tokenizer converts text into integer sequences (token IDs) that the model can understand. Subword-based tokenizers like Byte Pair Encoding (BPE) are widely used. BPE progressively merges frequent pairs of characters to build a vocabulary.
- Vocabulary Size: A larger vocabulary can compress text into fewer tokens, reducing sequence length and potentially improving computational efficiency, but it comes with the trade-off of increasing the model's embedding matrix size and thus memory requirements.
- Efficiency and Performance: Using an efficient tokenizer well-suited to the data characteristics (e.g., code, multilingual text) can reduce sequence lengths, lower computational load, and increase the effective context length the model can handle. Conversely, an inappropriate tokenizer can lead to degraded model performance and sometimes even security vulnerabilities.
What techniques help stabilize the training of large Transformers?

Training very large Transformer models can be unstable, often encountering issues like sudden loss spikes or divergence. To mitigate this training instability and ensure stable learning, the following techniques are often used in combination:
- Learning Rate Scheduling: Employing a warm-up phase where the learning rate is gradually increased at the beginning of training, followed by a decay phase (e.g., cosine decay) where the learning rate is progressively decreased, helps stabilize the optimization process.
- Gradient Clipping: Prevents the gradient explosion phenomenon by scaling down the gradient vector if its norm exceeds a certain threshold.
- Using Stable Optimizers: Optimizers like AdamW, which has an improved handling of weight decay compared to standard Adam with L2 regularization, generally provide more stable training.
- Careful Weight Initialization: Properly setting the initial values of model parameters ensures that activations and gradients are within a stable range at the start of training.
- Layer Normalization: A key component within Transformer blocks that normalizes the distribution of activation values, stabilizing signal propagation throughout the network.
- Using Appropriate Numerical Precision: Using BFloat16 instead of standard 16-bit floating-point (FP16), or employing mixed precision training (using higher precision for critical parts like optimizer states) can enhance numerical stability.
How does instruction tuning differ from general SFT? What is rejection sampling?

Supervised Fine-tuning (SFT) refers to the general process of fine-tuning a pre-trained model using labeled examples (input and correct output pairs) for a specific task.
Instruction Tuning is a form of SFT characterized by training data consisting of explicit 'instructions' and their corresponding 'desired outputs' (e.g., "Summarize the following sentence: [Long sentence]" → "[Summarized sentence]"). The goal of instruction tuning goes beyond improving performance on specific downstream tasks; it aims to teach the model the general ability to understand and follow diverse forms of natural language instructions. This enhances the model's versatility and improves its zero-shot or few-shot generalization performance on unseen new tasks.
Rejection Sampling is one of the data curation techniques used to improve the quality of datasets for instruction tuning or general SFT. The process is as follows:
1. Generate multiple candidate responses for a given instruction (prompt) using the current model.
2. Evaluate the quality of each response using predefined criteria (e.g., a separate reward model score, satisfaction of specific rules, human evaluation).
3. Select only the response(s) with the highest evaluation score, i.e., the best quality response(s), to include in the final fine-tuning dataset. This helps filter out low-quality responses and train the model only on high-quality examples, thereby improving the final model's performance and alignment level.
Compare and contrast alignment methods like RLHF, RLAIF, and DPO/GRPO. What are their core mechanisms, pros, and cons?

Various techniques are used for 'alignment', the process of making LLMs conform to human intentions and values – i.e., making them helpful, honest, and harmless. Here's a comparison of key methods:
- Reinforcement Learning from Human Feedback (RLHF):
  - Core Mechanism: 1) Human evaluators select their preferred response among several generated by the LLM, creating preference data. 2) This data is used to train a separate 'Reward Model (RM)' that predicts which response is better. 3) This RM is used as the reward function in a reinforcement learning (RL, e.g., PPO) algorithm to fine-tune the original LLM.
  - Pros: Can capture nuanced human preferences directly, potentially leading to high alignment quality.
  - Cons: High cost of collecting human preference data, complex overall process, final performance heavily depends on the quality of the learned reward model.
- Reinforcement Learning from AI Feedback (RLAIF):
  - Core Mechanism: Similar to RLHF, but uses a powerful AI model instead of costly human evaluators to generate preference labels. The subsequent process is the same as RLHF (train RM on AI-generated data -> fine-tune LLM with RL).
  - Pros: Easier to scale preference data generation.
  - Cons: Final alignment quality depends on the performance and biases of the AI model used for labeling.
- Direct Preference Optimization (DPO):
  - Core Mechanism: Directly fine-tunes the LLM using preference data (preferred response, dispreferred response pairs), without the need for a separate reward model training or reinforcement learning step. Uses a specific loss function to directly increase the probability of generating preferred responses and decrease the probability of dispreferred ones.
  - Pros: Much simpler to implement and more stable to train than RLHF/RLAIF.
  - Cons: May sometimes struggle to achieve the same level of fine-grained control or peak performance as RLHF.
- Group Relative Policy Optimization (GRPO):
  - Core Mechanism: An RL-based approach that utilizes relative preferences between groups of multiple responses instead of individual responses. Notably, instead of explicitly training a separate value/critic model, it uses statistics of response scores within a group (e.g., the mean) as an implicit baseline for calculating policy gradients.
  - Pros: Can improve resource efficiency (e.g., memory during training) by eliminating the need for a separate value model.
  - Cons: Relatively newer methodology; application and optimization might require specific expertise.
In summary, RLHF and RLAIF combine reward modeling and RL, differing in the feedback source (human/AI). DPO seeks simplicity by skipping reward modeling and RL. GRPO improves resource efficiency within the RL framework through group comparisons and efficient baseline estimation. The suitable method depends on the target alignment level, available data, compute resources, and implementation complexity.
What are the key considerations when designing a reward model for RLHF?.
The success of RLHF heavily relies on the quality of the reward model (RM), which acts as a proxy for human judgment during LLM fine-tuning. Key considerations when designing and training an effective RM include:
- Quality and Diversity of Preference Data: If the human preference data used for training is low-quality or biased in a specific direction, the learned RM will also be biased or inaccurate, negatively impacting the final alignment outcome. Ensuring high-quality, diverse, and consistent data is crucial.
- Reflecting Preference Strength: Ideally, the RM should capture not just the binary judgment of which response is better, but also the strength of that preference (how much better).
- Calibration: It's important to calibrate the RM so that the difference in scores it outputs accurately reflects the difference in preference strength perceived by humans. An uncalibrated RM can misguide the optimization process.
- Model Architecture and Loss Function: Careful selection of the RM's architecture (often initialized based on the target LLM) and the loss function used for training is necessary.
- Preventing Reward Hacking: The RM should be robust against 'reward hacking,' where the LLM exploits loopholes or incorrectly learned patterns in the RM to get high scores, rather than genuinely adhering to human preferences.
- Difficulty of Evaluating the RM: Evaluating the performance of the RM itself is challenging. High prediction accuracy on preference pairs doesn't necessarily guarantee the quality of the final aligned LLM.
- Generalization Performance: The RM must generalize well, accurately predicting human preferences for unseen responses, not just overfitting to the training data.
What is the difference between RLHF and RLVR in training reasoning models, and which approach was primarily used in the development of DeepSeek-R1?.
RLHF and RLVR (Reinforcement Learning from Verifiable Rewards) are both methods for improving LLMs using reinforcement learning, but they differ fundamentally in how rewards are defined and provided.
- RLHF: The reward is based on subjective human preferences. Human evaluators judge the relative quality of model responses (e.g., which is more helpful, safe), and a learned reward model provides the reward signal during RL. Primarily used to improve subjective and complex qualities like conversational ability, style, and safety.
- RLVR: The reward is based on objectively verifiable external rules or tools. For example, verifying the correctness of a math problem solution using an external calculator, or checking code executability and test case passing using a compiler, provides the reward. Often does not require training a separate reward model, making the process simpler and the reward criteria clear and objective. Effective for improving task accuracy and rule-following abilities. The development of DeepSeek-R1, particularly for enhancing its reasoning capabilities, primarily leveraged the RLVR approach. In the initial reinforcement learning phase, reasoning abilities were intensively trained using rule-based 'accuracy rewards' (checking math answers, code execution results) and 'format rewards' (a type of RLVR encouraging the model to generate reasoning steps within specific tags like <think>, </think>). Subsequently, in the final stages, RLHF (or a similar reward model-based approach) was used supplementarily on top of the established reasoning skills to further improve the model's overall conversational ability, helpfulness, and harmlessness. Therefore, RLVR played a pivotal role in enhancing DeepSeek-R1's reasoning capabilities, with RLHF contributing as a complementary step.
Explain PEFT methods like LoRA/QLoRA. Why are they used, and what problem does QLoRA specifically solve?

Parameter-Efficient Fine-tuning (PEFT) techniques are methodologies for adapting a pre-trained large language model to specific tasks or requirements by updating only a very small subset of the model's parameters, instead of fine-tuning the entire model. This significantly reduces the computational resources, especially memory usage, required for fine-tuning.
- LoRA (Low-Rank Adaptation): One of the most popular PEFT techniques. The core idea is to freeze the original weights of the pre-trained model and add small, trainable 'adapter' matrices to specific layers (typically attention layers). These adapters usually represent the change in the original weight matrix as the product of two low-rank matrices, and only these small adapter matrices are trained during fine-tuning.
- QLoRA (Quantized LoRA): A technique based on LoRA that further dramatically reduces memory usage. The key is to quantize the weights of the frozen, large base model to a very low precision, such as 4-bit, when loading it into memory. Gradient computation occurs through these quantized weights, but the actual updates are still applied only to the small LoRA adapters, which are kept at a higher precision (e.g., BFloat16). It additionally uses memory optimization techniques like double quantization and paged optimizers. QLoRA enables fine-tuning of very large models (tens to hundreds of billions of parameters) even in memory-constrained environments (e.g., a single consumer GPU), greatly increasing the accessibility of LLMs.
Briefly explain techniques for merging fine-tuned models (e.g., Task Arithmetic, SLERP) and their purpose.

Model Merging typically refers to techniques that combine the parameters of two or more models fine-tuned from the same base model to create a new single model without additional training. The main purposes are:
- Combining Multiple Capabilities: Merging models specialized for different tasks (e.g., coding ability, conversational ability) to create a more versatile model.
- Performance Improvement: Hoping to integrate the strengths of individual models to improve generalization performance.
- Deployment Simplification: Deploying a single merged model instead of multiple specialized ones increases manageability.
Key merging techniques include:
- Weight Averaging: The most basic method, calculating a simple or weighted average of the parameters of each model.
- SLERP (Spherical Linear Interpolation): Instead of simple linear interpolation (a straight line) in the parameter vector space, this technique interpolates along an arc on a sphere, attempting to find a more natural intermediate point.
- Task Arithmetic: Calculates the difference between the fine-tuned model and the original base model parameters, termed the 'task vector'. These vectors are then added to or subtracted from (sometimes with weights) the original model.
- Advanced Merging Techniques: To address issues like parameter interference (e.g., sign conflicts) when merging multiple models, more sophisticated methods have been proposed. Techniques like TIES-Merging or DARE use strategies such as pruning redundant or conflicting parameters, resolving sign conflicts, or selectively resetting parameter values.
These model merging techniques offer ways to effectively combine already learned knowledge and capabilities without the cost of additional training.
What are the core technical challenges and practical trade-offs encountered when designing systems for continuous pre-training or continual learning, and what approaches are commonly used to mitigate these issues?

Continuous Pre-training or Continual Learning aims to incrementally update models with new incoming data over time, instead of periodically retraining them from scratch. Building and operating such systems involves significant technical challenges and trade-offs:
- Catastrophic Forgetting: The phenomenon where a model abruptly loses previously learned knowledge or skills as it learns new data or tasks. This is the most fundamental problem in continual learning. Mitigation strategies include regularization techniques, replay methods (rehearsing some old data), and methods that estimate parameter importance to constrain updates.
- Computational Efficiency: The process of updating a large model with new data must be efficient enough to avoid excessive computational costs. It needs to be significantly cheaper than full retraining to be worthwhile.
- Data Management Complexity: Managing a continuous stream of incoming data is complex. It requires data quality control, storage, deduplication, and handling 'data drift' (changes in data distribution over time).
- Training Stability: Ensuring that the model training remains stable and converges during the continuous update process, without becoming unstable or diverging, can be difficult.
- Evaluation Challenges: Evaluating model performance becomes more complex, as it requires measuring not only the ability to learn new data but also the retention of old knowledge (resistance to forgetting).
- Architectural Suitability: Current standard Transformer architectures may not be inherently optimal for continual learning. Research into dynamic architectures or modular structures that facilitate continuous learning is needed.
- Alignment Maintenance: As the model is continuously updated, it's crucial to continuously monitor and manage its alignment (helpfulness, honesty, harmlessness) to ensure it doesn't degrade or drift in undesirable ways, especially if new data isn't fully curated.
Due to these challenges, continual learning systems often involve trade-offs between performance (acquiring new knowledge), stability (retaining old knowledge), and computational cost.

IV. Retrieval-Augmented Generation

What are the main components of an RAG system? When is RAG preferred over fine-tuning?

Retrieval-Augmented Generation (RAG) is a technique where an LLM, before generating an answer, first retrieves relevant information from an external knowledge source and then uses this retrieved information as context to generate the final response. This helps improve the accuracy of the LLM's answers, incorporate up-to-date information, and reduce hallucinations.
The main components of an RAG system are:
- Retriever: Given a user query (question), its role is to find relevant documents or text passages from a pre-built knowledge base.
- Knowledge Base: The collection of information to be searched. It's built by indexing external documents, database contents, etc.
- Generator: Typically an LLM, which takes the user's original query and the relevant information found by the retriever as combined input, and generates the final answer based on this augmented context.
When RAG is preferred over fine-tuning:
- External Knowledge Integration: Useful when needing to leverage vast, rapidly changing, or domain-specific external knowledge that is difficult to store within the model's parameters.
- Up-to-dateness and Factual Grounding: Can reflect the latest information just by updating the knowledge base (much cheaper than retraining the model), and can cite retrieved documents as evidence, increasing the answer's reliability and providing clear sources.
- Hallucination Reduction: Can reduce hallucinations by guiding the model to base its answers on retrieved facts instead of guessing when it doesn't know something.
- Accessing Specific Information: Effective when needing to accurately reference specific information without the risk of knowledge being forgotten, which can sometimes happen during fine-tuning.
Conversely, fine-tuning is more suitable when the goal is to change the model's inherent characteristics or abilities, such as altering its style, tone, persona, or internalizing specific skills or complex behavioral patterns.
Compare and contrast lexical, semantic, and hybrid search methods.

In RAG systems, the retriever can find relevant information in various ways. The main search methods are:
- Lexical Search:
  - How it works: Primarily based on keyword matching. Uses sparse vector methods (e.g., TF-IDF, BM25) that score documents based on term frequency and distribution within the text.
  - Pros: Computationally efficient, effective at finding documents containing the exact keywords present in the query.
  - Cons: Struggles to grasp semantic similarity (e.g., synonyms, different phrasings). Might treat 'car accident' and 'vehicle collision' as unrelated.
- Semantic Search:
  - How it works: Uses neural network-based language models (encoders, e.g., E5, BGE) to convert queries and documents into dense vectors that capture meaning. Search is performed by finding document vectors closest (most similar) to the query vector in the vector space.
  - Pros: Can find documents that are contextually and semantically similar, even if they don't share exact keywords.
  - Cons: Requires relatively higher computational cost for embedding generation and vector search; performance heavily depends on the quality of the embedding model.
- Hybrid Search:
  - How it works: Combines lexical and semantic search. Strategies include fusing the scores from each method or using one method to retrieve an initial set of candidates and then re-ranking them with the other method.
  - Pros: Can compensate for the weaknesses and leverage the strengths of each method, potentially leading to overall more robust and stable search performance.
  - Cons: Increases system implementation and tuning complexity.
How is RAG performance evaluated (e.g., RAGAS framework)? What are the key metrics?

Evaluating the performance of an RAG system is multifaceted because it requires considering the quality of both the retrieval and generation steps. It involves assessing not just the final answer's quality but also whether each component performs its role well, both individually and holistically. Frameworks like RAGAS attempt to automate and standardize this evaluation process, often leveraging other LLMs as evaluators.
Key evaluation metrics include:

1. Retriever Performance Evaluation:
- Context Precision: Measures the proportion of retrieved documents that are actually relevant to the question. A low score indicates many irrelevant documents were retrieved.
- Context Recall: Measures whether all necessary relevant information required to answer the question was included in the retrieval results. A low score indicates important information was missed.
2. Generator Performance Evaluation:
- Faithfulness: Assesses how well the generated answer aligns with the provided context (retrieved documents), i.e., whether it avoids making things up (hallucinating) that are not supported by the context.
- Answer Relevancy: Evaluates whether the generated answer directly and clearly addresses the user's original question. A low score indicates the answer is verbose or misses the point.
3. End-to-end Evaluation (using ground truth data if available):
- Answer Correctness: Evaluates how well the generated answer matches the actual ground truth or factual answer. (Requires ground truth data)
- Answer Semantic Similarity: Evaluates how semantically similar the generated answer is to the reference (ground truth) answer. (Requires ground truth data)
Using these diverse metrics helps diagnose whether performance bottlenecks in an RAG system stem from the retrieval step, the generation step, or both, guiding improvement efforts.
What are some advanced RAG techniques to improve upon the basic retrieve-then-generate pipeline? How do strategies like query transformation (e.g., HyDE), re-ranking, or iterative retrieval work, and what advantages do they offer over standard RAG?

While basic retrieve-then-generate RAG is effective, it can sometimes suffer from poorly relevant retrieved information or limited ability to answer complex questions. Advanced RAG techniques are used to overcome these limitations and improve performance:
- Query Transformation: Techniques that modify the user's original query to improve retrieval performance, based on the idea that the original query might be suboptimal for searching.
  - HyDE (Hypothetical Document Embeddings): Instead of using the original query, it first uses an LLM to generate a 'hypothetical ideal document' that would answer the query. This generated document, being content-rich, is then embedded and used for searching, increasing the likelihood of finding relevant actual documents compared to using the original query alone. Particularly effective for short or ambiguous queries.
  - Other methods include decomposing the query into sub-queries or extracting/expanding key terms within the query.
- Re-ranking: Often, the initial retrieval step uses a relatively simple method to retrieve a larger set of candidate documents quickly. Re-ranking involves applying a more accurate but computationally expensive model (e.g., a cross-encoder that takes query and document together as input) to this initial candidate set to re-calculate relevance scores and adjust the ranking. This improves the average relevance of the documents ultimately passed to the generator (LLM), enhancing answer quality.
- Iterative/Recursive Retrieval: A strategy to handle complex questions where a single retrieval step may not yield sufficient information.
  - How it works: Analyzes the initial retrieval results. If information is deemed insufficient, it generates new queries based on the previous results to perform additional searches. This 'retrieve → analyze → (if needed) generate new query → retrieve' cycle is repeated until enough information is gathered.
  - Advantages: Enables deeper and more comprehensive answers for questions requiring multi-step reasoning or synthesis of information from various perspectives.
Other advanced RAG techniques include Graph RAG (leveraging knowledge graphs), Small-to-Big retrieval (starting with small text chunks and progressively expanding the search scope), etc. These techniques complement the standard RAG pipeline, addressing its weaknesses and maximizing performance for specific types of questions or data.

V. Multimodal Models

How do multimodal models (e.g., CLIP, Flamingo, LLaVA) typically fuse text and image information?

Multimodal models use various information fusion strategies to process and understand information from different modalities like text, images, and audio together. Key approaches include:
- Shared Embedding Space:
  - Example: CLIP
  - How it works: Uses separate encoders to process each modality (e.g., text, image), generating respective embeddings. These embeddings are then trained to be projected into a single shared latent space. Using a contrastive learning objective, embeddings from related data pairs (e.g., an image and its corresponding text caption) are pushed closer together in this shared space, while unrelated pairs are pushed apart. Fusion happens implicitly through proximity in this embedding space.
- Cross-Attention:
  - Example: Flamingo
  - How it works: Uses an explicit attention mechanism for information from one modality to directly reference information from another. For instance, cross-attention layers are inserted between specific layers of a pre-trained LLM, allowing text tokens (acting as queries) to directly attend to visual feature tokens (acting as keys/values) extracted by a vision encoder. This enables the active use of visual information during text generation.
- Input-Level Fusion:
  - Example: LLaVA
  - How it works: Uses a projection layer to transform visual features, extracted via an image encoder (e.g., ViT), into the same dimension as text token embeddings. These transformed visual feature vectors are treated as 'pseudo visual tokens' and are simply concatenated with the text token embedding sequence. A standard LLM (generator) then takes this combined sequence (text tokens + visual tokens) as input, naturally processing and fusing text and visual information together through its internal self-attention mechanisms.
Other approaches involve designing dedicated fusion modules, possibly using gating mechanisms, to merge features at various points in the network.
What are the main challenges in designing/training multimodal models?

Designing and training effective multimodal models presents several key challenges:
- Acquiring High-Quality Large-Scale Datasets: Building large-scale, high-quality datasets where different modalities are well-aligned (e.g., images with accurate, detailed text descriptions) is costly, time-consuming, and difficult. Poor data quality or alignment critically impacts model performance.
- Developing Meaningful Fusion Strategies: Designing effective fusion mechanisms that enable deep integration and cross-modal reasoning, beyond superficial correlations, remains a significant research area.
- High Computational Cost: Multimodal models often include multiple large encoders for each modality (e.g., vision encoder + language model), requiring substantial computational resources for pre-training and fine-tuning.
- Modality Gap: Even when using a shared embedding space theoretically, embeddings from different modalities may tend to form separate clusters within the space in practice. This can hinder seamless information integration between modalities.
- Scalability Issues: Extending the model's capabilities, such as supporting more types of modalities or increasing image/video resolution, can exponentially increase computational and memory requirements, posing significant technical hurdles.
- Evaluation Complexity: Truly evaluating whether a model understands and reasons across modalities, beyond just achieving high scores on specific benchmarks, is difficult. Additionally, interpreting the model's decision-making process and managing potential biases that can be amplified through multi-modal interactions are important challenges.

VI. Image Generation and Diffusion Models

Explain the core principles of the diffusion process. How do Latent Diffusion Models improve efficiency?

Diffusion Models are a powerful family of generative models for creating high-quality images, operating in two stages: the forward process and the reverse process.
1. Forward Process: Gradually adds Gaussian noise to the original data (e.g., a real image) over multiple time steps. After sufficient steps, the data becomes pure noise, indistinguishable from its original form. This process follows a predefined schedule.
2. Reverse Process: Learns a denoising model (typically using a U-Net architecture) to reverse the forward process. This model takes the current noisy data and the corresponding time step as input and predicts the noise that was likely added at that step. During inference (image generation), starting from random noise, the learned denoising model is used to iteratively remove the predicted noise at each step. This progressively denoises the data, eventually generating a clean sample (e.g., a realistic image) similar to the original data distribution.
Latent Diffusion Models (LDMs) (the basis for technologies like Stable Diffusion) significantly improve the efficiency of this process. Instead of performing diffusion directly in the high-resolution pixel space, they follow these steps:
- Compression: Uses a pre-trained autoencoder (specifically a VAE) to compress the original high-resolution image into a much lower-dimensional latent space representation.
- Latent Space Diffusion: Performs the forward (noise addition) and reverse (denoising learning and inference) diffusion process entirely within this low-dimensional latent space.
- Reconstruction: After obtaining the final denoised latent vector from the reverse process in the latent space, uses the autoencoder's decoder to reconstruct it back into the original high-resolution pixel space image.
By operating in the low-dimensional latent space instead of the high-dimensional pixel space, LDMs drastically reduce the computational load and memory requirements of the denoising network (U-Net), making high-resolution image generation much faster and more efficient.
What are Diffusion Transformers? How do they differ from traditional U-Net based diffusion models, and what are their potential pros and cons?

Diffusion Transformers (DiTs) refer to models that use a Transformer architecture instead of the traditional U-Net architecture for the reverse denoising process in diffusion models.
Differences from traditional U-Net based models:
- Core Network: U-Nets are based on Convolutional Neural Networks (CNNs) featuring skip connections between downsampling and upsampling paths. In contrast, DiT uses a Transformer, similar to Vision Transformers (ViTs), which divides the image into patches and processes them as a sequence, as the denoising network.
- Input Processing: DiT typically takes the (noised) latent space image patch sequence, time step embeddings, and conditioning information like text embeddings as input. It uses the Transformer's self-attention to learn relationships among these inputs and ultimately predict the noise present in each patch.
Potential Pros:
- Scalability: Transformers have demonstrated excellent scaling properties (performance improvement with increased model size and data) in various domains like NLP and vision. DiT offers the potential to apply the superior scalability of Transformers to diffusion models.
- Leveraging Existing Ecosystem: Can benefit from existing research, pre-training techniques, and optimized implementations related to Transformers.
Potential Cons:
- Loss of Inductive Bias: CNNs inherently possess useful inductive biases for image processing, such as spatial hierarchies. Transformers have relatively fewer such biases (though processing images as patches mitigates this somewhat).
- Computational Cost: The self-attention operation in Transformers can have computation costs that scale with sequence length (though operating in latent space, like in LDMs, significantly reduces this burden).
The relative performance and efficiency of DiT compared to highly optimized U-Net architectures is an active area of research.
What is Classifier-Free Guidance?

Classifier-Free Guidance (CFG) is a technique used in conditional diffusion models, such as text-to-image generation, to steer the generated image to better match the given condition (e.g., text prompt). As the name suggests, it achieves this without requiring a separate classifier model.

How it Works:
1. Training: The diffusion model (noise predictor network) is trained in two ways:
  - Conditional Training: Learns to predict noise given both the noised image and the conditioning information (e.g., text embedding).
  - Unconditional Training: Sometimes (with a certain probability), the conditioning information is removed or replaced with a null value, and the model learns to predict noise based only on the noised image. Thus, the same model learns to predict noise both with and without conditioning.
2. Inference (Image Generation): At each denoising step during image generation, the model calculates two noise predictions: one prediction given the condition, and another prediction without the condition (unconditional).
3. Applying Guidance: The final noise prediction used is a combination of these two. The unconditional prediction is modified by adding the difference between the conditional and unconditional predictions, scaled by a certain weight (the guidance scale, 'w'). A larger 'w' pushes the prediction further in the direction of the conditional prediction (extrapolation).
4. Image Update: The calculated final noise prediction is used to remove noise from the current noisy image to obtain the image for the next step.
Effect: By adjusting the guidance scale 'w', users can control how strongly the generated image adheres to the given condition (text prompt). Higher 'w' values lead to better prompt adherence but might reduce image diversity or quality slightly, while lower 'w' values increase diversity but might decrease relevance to the prompt. CFG is a highly effective technique that allows users to easily control this trade-off between fidelity (to the condition) and diversity.

❓ Origin of the Name: Before CFG, a common method (classifier guidance) involved training a separate classifier model to predict the desired class or attribute from the noisy image. The gradient of this classifier was then used to guide the diffusion process. CFG provides guidance without such a separate classifier, hence the name "Classifier-Free".
Compare and contrast sampling strategies (e.g., DDIM, DPM-Solver) in terms of speed vs. quality.

Diffusion model sampling strategies, or solvers, are algorithms used to generate (sample) images from a trained diffusion model. The original formulation, the DDPM sampler, can produce high-quality images but is very slow, requiring hundreds to thousands of denoising steps. Sampling strategies aim to increase inference speed by using fewer denoising steps while maintaining the highest possible image quality. Here's a comparison of key strategies regarding speed and quality:
- DDIM (Denoising Diffusion Implicit Models):
  - One of the early improved samplers. Allows sampling with much larger time step skips than DDPM, significantly reducing the total number of required steps to the order of tens to hundreds (e.g., 50-250 steps), thus improving speed.
  - Maintains good quality at reasonable step counts but tends to show noticeable quality degradation at very few steps (e.g., below 10-20 steps).
- DPM-Solver (Diffusion Probabilistic Model Solver) family:
  - Interprets the diffusion process as solving a stochastic differential equation (SDE) or ordinary differential equation (ODE) and applies higher-order numerical methods to solve these equations faster and more accurately.
  - Can generate very high-quality images with far fewer steps than DDIM, often just 10-25 steps, offering significant speed improvements for comparable quality.
  - Various variants exist, such as DPM-Solver++ and UniPC, known for good stability, especially when used with CFG.
Conclusion: Currently, DPM-Solver family samplers are generally considered to offer the best trade-off between generation speed and sample quality, greatly enhancing the practicality of diffusion models. The choice of sampler depends on the required quality level and the acceptable generation time.
What is ControlNet, and how does it enable controllable image generation?

ControlNet is an add-on neural network module designed to add extra spatial control capabilities to pre-trained large-scale text-to-image diffusion models (like Stable Diffusion). It allows users to provide not only a text prompt but also various types of conditioning images to finely control the structure, shape, pose, etc., of the generated image. Examples of control conditions include:
- Canny edges map
- Depth map
- Human pose skeleton (e.g., OpenPose)
- Semantic segmentation map
- Scribbles, etc.
How it Works & Features:
1. Freezes Base Model: ControlNet does not modify the weights of the existing powerful pre-trained diffusion model at all; they remain frozen.
2. Copies and Trains Encoder Blocks: It duplicates only the encoding part (downsampling blocks) of the base model's denoising network (usually a U-Net) and makes this copy trainable.
3. Inputs Control Condition: The user-provided control condition image (e.g., edge map) is fed into this trainable encoder copy.
4. 'Zero Convolution' Connection: The output features from each block of the trainable copy pass through 'zero convolutions' (1x1 convolution layers initialized with zero weights) and are then added to the input of the corresponding decoding part (upsampling blocks) of the original frozen U-Net.
5. Training: When training ControlNet, only the weights of the copied encoder blocks and the zero convolution layers are updated. Training data consists of (original image, text prompt, control condition image) triplets.
This architecture allows ControlNet to leverage the vast knowledge and generative power of the base model while effectively controlling the spatial structure of the image according to the added condition. The zero convolutions initially allow the base model to operate unaffected, gradually injecting the control information as they are trained.
What are the common fine-tuning techniques used to adapt pre-trained image generation models to specific styles or subjects, and what are the characteristics of each method? Also, what are the key technical challenges to be aware of when applying these techniques?

Several techniques are used to adapt powerful pre-trained image generation models to specific styles, persons, objects, or concepts. Each technique differs in the depth of customization, required data amount, and computational resource needs.
Key Fine-tuning Techniques:
- Full Fine-tuning:
  - Method: Retrains all or most of the model's weights on a new target dataset (e.g., images of a specific style).
  - Characteristics: Allows for fundamental changes to the model's behavior, enabling deep customization. However, it requires substantial computational resources (GPU memory, time) and carries a high risk of catastrophic forgetting, where the model loses its vast pre-trained knowledge or diverse generation capabilities.
- PEFT (Parameter-Efficient Fine-tuning): Freezes most weights and trains only a small subset of parameters, improving resource efficiency. Common techniques in image generation include:
  - LoRA: Adds small, low-rank 'adapter' matrices to specific layers (often attention-related) of the base model and trains only these adapters. Effective for applying specific styles or making fine adjustments with relatively few resources.
  - DreamBooth: Uses a small number of images (typically 3-5) of a specific subject (e.g., a particular person, pet) and a unique identifier string (e.g., "a photo of sks dog") to teach the model to generate that subject with high fidelity. Updates a subset of the model's weights.
  - Textual Inversion: Does not change the model's weights at all. Instead, it learns a new embedding vector for a new pseudo-word that represents the target concept (style, object). Training is very lightweight and fast, but it might be harder to capture specific subjects as strongly as DreamBooth.
Key Technical Challenges:
Regardless of the fine-tuning technique used, one might face the following challenges:
- Catastrophic Forgetting: The model losing previously learned diverse knowledge and generation capabilities while learning the new style or concept. Particularly prominent in full fine-tuning.
- Overfitting: The model becoming too specialized to the fine-tuning data, resulting in outputs that are overly similar to the training examples or poor generalization to new prompts. Outputs can become repetitive or lack diversity.
- Finding Balance: Striking the delicate balance between achieving the desired level of customization while preserving the model's general generative capabilities and stability is crucial. Careful tuning of learning rates, training data amount, and training steps is required.

VII. Foundation Model Engineering and Infrastructure

Explain data, tensor, and pipeline parallelism. When is each used? What are frameworks like DeepSpeed/FSDP?

Very large models often don't fit into the memory of a single accelerator (like a GPU) or take too long to train on a single device. Therefore, distributed training strategies using multiple devices are essential. Key parallelism techniques include:
- Data Parallelism (DP):
  - Method: Replicates the entire model across multiple devices. Each device processes a different portion (minibatch) of the overall data batch to compute gradients. The gradients are then averaged across all devices (e.g., via an AllReduce operation) to update the model weights simultaneously.
  - When Used: Primarily when the model itself fits on a single device, but you want to speed up training by processing more data in parallel. It's the most basic form of parallelism.
- Tensor Parallelism (TP):
  - Method: Splits individual operations (tensor computations) within the model, such as large matrix multiplications (inside attention or FFN layers), across multiple devices. The weights of a specific layer might be distributed across devices, requiring inter-device communication (e.g., AllReduce, AllGather) during the forward and backward passes for that layer.
  - When Used: When even a single layer of the model is too large to fit into the memory of one device.
- Pipeline Parallelism (PP):
  - Method: Divides the model's layers into multiple sequential stages and assigns each stage to a different device. Data flows through the pipeline from one stage to the next, like an assembly line (passing activations forward, passing gradients backward).
  - When Used: When the entire model (even with tensor parallelism) doesn't fit on a single device, or when you want to reduce the memory burden of storing intermediate computations (activations).
In practice, training very large models often uses a hybrid approach combining these three parallelism techniques. Frameworks like DeepSpeed or PyTorch's FSDP (Fully Sharded Data Parallel) provide tools and abstractions to make implementing and managing these complex parallelism strategies easier, often incorporating memory optimization techniques like ZeRO.
Explain ZeRO stages 1, 2, and 3. How do they reduce memory requirements?

ZeRO (Zero Redundancy Optimizer) is a family of optimization techniques designed to drastically reduce the per-device memory consumption in data parallel (DP) training environments. It achieves this by partitioning the model state information (optimizer states, gradients, model parameters), which would otherwise be redundantly stored on each device (GPU), across multiple devices. This enables training much larger models on limited hardware. ZeRO has three stages of increasing optimization:
- ZeRO Stage 1:
  - Partitions: Optimizer states (e.g., momentum and variance values for AdamW optimizer).
  - How it works: Each device stores only the portion (partition) of the optimizer states corresponding to the subset of model parameters it is responsible for. Standard DP replicates the entire optimizer state on all devices; ZeRO Stage 1 eliminates this redundancy. When parameters need updating, the required optimizer states are fetched via communication.
- ZeRO Stage 2:
  - Partitions: Optimizer states + Gradients.
  - How it works: In addition to partitioning optimizer states (Stage 1), it also partitions the gradients across devices. After the backward pass, each device computes and stores only the gradients for its assigned parameter partition (using a ReduceScatter operation). This saves additional memory compared to standard DP where all devices compute and AllReduce the full gradient tensor.
- ZeRO Stage 3:
  - Partitions: Optimizer states + Gradients + Model parameters.
  - How it works: The highest level of optimization, partitioning the model parameters themselves. Each device holds only its assigned parameter partition in memory for most of the time. When the forward or backward computation for a specific layer is needed, the required parameters are temporarily gathered from all relevant devices via communication (AllGather), used for computation, and then immediately released to free up memory.
  - Effect: Provides the largest memory savings, theoretically enabling training of models almost arbitrarily large, given enough devices.
Higher ZeRO stages offer greater memory savings but typically come with the trade-off of increased inter-device communication as partitioned data needs to be gathered more frequently.
Discuss quantization techniques (PTQ vs QAT) and formats (FP16, BF16, INT8). What are their impacts on performance/size/accuracy? Explain GPTQ/AWQ.

Quantization is the technique of reducing the numerical precision (number of bits) used to represent a model's weights and/or activations. Instead of the standard 32-bit floating-point (FP32), formats like 16-bit floating-point (FP16, BF16) or 8-bit integers (INT8) are used.

Purpose and Effects:
- Reduced Model Size: Uses fewer bits, making model files smaller, which is beneficial for storage and loading.
- Reduced Memory Usage: Less memory is required to load the model during inference. Particularly effective when applied to memory-intensive components like the KV cache.
- Improved Inference Speed: Reduced memory bandwidth usage and potential acceleration from hardware supporting low-precision computations (e.g., Tensor Cores on NVIDIA GPUs) can lead to faster computations.
Key Formats:
- FP16: Uses half the bits of FP32, offering a relatively good balance between speed and accuracy. However, its narrower representable range can lead to overflow/underflow issues.
- BF16 (BFloat16): Also 16-bit, but allocates more bits to the exponent, giving it a wide representable range similar to FP32. Tends to be more numerically stable than FP16 for training and inference.
- INT8: Uses 8-bit integers, offering the potential for the most significant speed improvements and memory savings. However, converting floating-point numbers to integers involves greater information loss, making a careful conversion process (calibration) crucial to minimize accuracy degradation.
Key Quantization Techniques:
- Post-Training Quantization (PTQ): Takes an already trained model and converts its weights (and sometimes activations) to lower precision without retraining. Often uses a small amount of calibration data to find optimal conversion scaling factors. Relatively simple to implement, but can lead to model accuracy loss, especially when quantizing to very low bit-widths (e.g., 4-bit or lower).
  - GPTQ, AWQ: Advanced PTQ techniques specifically developed to effectively quantize LLM weights down to 4-bit precision. They aim to minimize accuracy degradation even at very low bit-widths by considering weight importance and minimizing quantization error.
- Quantization-Aware Training (QAT): Simulates the quantization operations (inserts fake quantization ops) during the model training or fine-tuning process. The model learns to become robust to the errors introduced by quantization, generally achieving higher accuracy than PTQ for the same bit width. However, it requires an additional training process, costing more time and computation.
All quantization techniques involve a trade-off between efficiency gains (speed, memory) and the potential for model performance (accuracy) degradation.
How does speculative decoding speed up LLM inference?

Speculative Decoding is a technique to speed up the inference process of autoregressive LLM text generation (generating one token sequentially after another). The core idea is to use two models together: a small, fast 'draft' model and a large, accurate but slow 'target' model.

How it Works:
1. Draft Generation: Given the sequence generated so far, the small, fast draft model first quickly predicts and proposes a short sequence of candidate tokens (e.g., 3-5 tokens) for the future.
2. Parallel Verification: The large, slow target model takes the entire candidate token sequence proposed by the draft model as input and processes it in parallel in a single forward pass. During this pass, the target model verifies the draft model's proposals by comparing them against what it would have predicted at each position.
3. Token Acceptance: If the target model agrees with the draft model's proposals for the first 'k' consecutive tokens, these 'k' tokens are accepted and appended to the final output sequence all at once.
4. Mismatch Handling: If the target model's prediction differs from the draft model's proposal at the 'k+1'-th token, only the first 'k' agreed-upon tokens are accepted. The 'k+1'-th token is then taken from the target model's prediction. The process then repeats, with the draft model generating the next candidate sequence.
Effect: If the draft model is reasonably accurate, this method allows confirming multiple tokens simultaneously with just one expensive forward pass of the target model. This can result in significant speedups (often 2x-4x or more) compared to the standard autoregressive decoding method where the target model generates only one token per forward pass.
How does FlashAttention improve attention efficiency?
FlashAttention is an algorithm optimized to perform the standard self-attention computation much faster and using less memory, especially for long sequences. It achieves this by efficiently leveraging the characteristics of the GPU memory hierarchy.

Core Principle:
A major performance bottleneck in standard attention implementations often arises not from the raw computation itself, but from writing and reading very large intermediate results (specifically, the N x N attention score matrix, where N is sequence length) to and from the relatively slow main GPU memory (High Bandwidth Memory, HBM).

FlashAttention focuses on minimizing these slow HBM accesses:
1. Tiling: It partitions the input matrices (Query Q, Key K, Value V) into smaller blocks (tiles) that fit into the much faster on-chip GPU memory (SRAM).
2. Computation within SRAM: The attention computation for each block (matrix multiplication of Q and K for scores, softmax application, weighted sum with V) is performed entirely within the fast SRAM. This avoids writing the huge intermediate attention score matrix to the slow HBM. (It uses numerically stable techniques for block-wise softmax calculation).
3. Optimized Backward Pass: For the backward pass during training (gradient calculation), standard attention typically requires storing the large attention matrix computed in the forward pass, consuming significant memory. FlashAttention avoids this by recomputing the necessary parts on-the-fly within SRAM during the backward pass, saving substantial memory at the cost of some extra computation.
In conclusion, FlashAttention employs an IO-aware approach optimized for the GPU memory hierarchy, minimizing HBM reads/writes. This allows it to achieve significant speedups and reduced memory usage while maintaining the exact attention computation results.
What is the purpose of using ONNX or TensorRT for deployment?

When deploying a trained deep learning model into a real-world service environment for inference, optimization to increase execution speed and reduce resource consumption is crucial. ONNX and TensorRT are prominent tools and frameworks widely used for this purpose.
- ONNX (Open Neural Network Exchange):
  - Purpose: An open standard model format designed to provide interoperability between various deep learning frameworks (PyTorch, TensorFlow, etc.).
  - How it works: A model trained in one framework can be converted to the ONNX format. This format can then be run on various hardware or inference engines that support it (e.g., ONNX Runtime). It facilitates easy model transfer and execution even if the development framework and deployment environment differ.
  - Optimization: ONNX Runtime itself performs optimizations like model graph fusion (operator fusion) and leveraging hardware acceleration features to improve inference performance.
- TensorRT:
  - Purpose: A software development kit (SDK) and runtime library provided by NVIDIA specifically designed to maximize inference performance on NVIDIA GPUs.
  - How it works: Takes models developed in various frameworks (often including models converted via ONNX) and performs highly aggressive optimizations specifically tailored for NVIDIA GPU architectures.
  - Key Optimization Techniques:
    - Layer & Tensor Fusion: Combines multiple operations into a single GPU kernel to reduce overhead.
    - Kernel Auto-Tuning: Automatically selects the kernel implementation that yields the fastest performance on the target GPU hardware.
    - Precision Calibration: Optimizes the model to use lower precision formats like FP16 or INT8 for faster execution.
    - Multi-stream execution, dynamic tensor memory management, etc.
  - Result: Generally aims to achieve the lowest latency and highest throughput possible on NVIDIA GPUs.
In summary, ONNX serves as a standard for model interoperability across diverse environments, while TensorRT is a deep optimization tool focused on extracting maximum performance specifically from NVIDIA GPUs. A common workflow involves converting a model to ONNX first, and then further optimizing it with TensorRT.
How do static batching and continuous batching techniques differ for LLM inference, and why does continuous batching often yield better performance in LLM scenarios? Furthermore, explain how technologies like vLLM specifically contribute to the efficient implementation of continuous batching.

During LLM inference, Batching is a crucial technique to improve the efficiency of parallel processing hardware like GPUs by processing multiple user requests together. The two main approaches are static batching and continuous batching.
- Static Batching:
  - Method: Groups incoming requests into batches of a predetermined fixed size. The GPU waits until the computation for the entire batch is completed before processing the next batch.
  - Drawback: LLM response lengths are highly variable per request. In static batching, even short requests that finish early must wait until the longest request in the batch completes its generation. This leads to wasted GPU resources (increased idle time) and increases the average response time for users, making it inefficient.
- Continuous Batching (or Dynamic Batching):
  - Method: Does not use fixed batches but manages requests dynamically. As soon as any request within the group currently being processed by the GPU finishes generating its response, the resources it was using are immediately freed up, and a new waiting request is immediately inserted to utilize those resources for the next computation step.
  - Advantage: Allows the GPU to operate continuously without waiting for the entire group to finish. It effectively addresses the variable output length problem of LLMs, maximizing GPU utilization, reducing average latency, and significantly increasing overall system throughput. This makes it much better suited for real-world service environments with a mix of requests of varying lengths.
Contribution of vLLM and PagedAttention:
While conceptually efficient, implementing continuous batching effectively faced technical challenges, particularly with managing the memory for the KV cache used in Transformer attention. The dynamic addition/removal of requests with varying lengths led to severe memory fragmentation, making it difficult to reuse memory efficiently.
The vLLM library addresses this problem by introducing an innovative technique called PagedAttention.
- PagedAttention: Inspired by operating system memory paging, it manages the KV cache in small, fixed-size blocks (pages) that do not need to be contiguous in physical memory.
- Effect: Each request is allocated only the pages it needs. When a request completes, its pages are immediately returned and can be reused by other requests. This virtually eliminates memory fragmentation, boosting KV cache memory utilization to over 90% and enabling highly efficient implementation of continuous batching.
Consequently, vLLM and PagedAttention play a key role in realizing the theoretical benefits of continuous batching, significantly enhancing LLM inference serving performance.

VIII. Reasoning, Prompting, and Agents

How does the effectiveness of In-Context Learning scale with model size?

In-Context Learning (ICL) refers to the remarkable ability of LLMs to perform new tasks or respond in specific ways based solely on few-shot examples or instructions provided within the prompt, without any changes to the model's weights.
The effectiveness of this ICL ability shows a very strong positive correlation with the model's scale (size). That is, the larger the model's parameter count, the amount of training data, and the compute used for pre-training, the significantly better its ICL performance. Many studies show that effective ICL tends to manifest as an emergent property of scale. It might be barely present or minimal in smaller models, but performance drastically improves once the model size crosses a certain threshold.
This is interpreted as larger models being better at identifying the underlying patterns or hidden rules implied by the few-shot examples in the prompt and generalizing this understanding to new problems within the same prompt. While providing more examples in the prompt can sometimes help, the fundamental ICL capability itself seems largely determined by the scale of the pre-trained model.
Explain Chain-of-Thought prompting. How do strategies like Tree of Thoughts differ?

Chain-of-Thought (CoT) prompting is a prompting technique designed to help LLMs better perform complex tasks requiring multiple steps of reasoning, such as math word problems or logical deduction.

How it works: Instead of asking for just the final answer directly, it prompts the model to explicitly generate the intermediate steps of thinking or reasoning that lead to the solution. This can be done by including few-shot examples in the prompt that demonstrate the step-by-step process, or simply by adding an instruction like "Let's think step by step". Forcing the model to follow a thought process can significantly improve accuracy on complex problems.

Tree of Thoughts (ToT) is a more advanced concept than CoT, which explores multiple possible reasoning paths simultaneously instead of a single linear chain of thought. It considers various possibilities like branches of a tree.

General Steps in a ToT Framework:
1. Problem Decomposition: Break down the complex problem into multiple steps or thought units.
2. Thought Generation: Generate multiple potential next steps or intermediate thoughts from the current state (exploring different branches).
3. State Evaluation: Evaluate the validity, feasibility, or promise of the generated intermediate states or reasoning paths (sometimes using the LLM itself as an evaluator).
4. Search: Use search algorithms like Breadth-First Search (BFS) or Depth-First Search (DFS) to explore this 'tree of thoughts', potentially pruning unpromising branches or backtracking from dead ends.
Key Difference: CoT follows a single sequential reasoning path, whereas ToT explores and evaluates multiple possibilities concurrently. Therefore, ToT can be a more robust approach for complex problem-solving where exploration, evaluation of alternatives, or self-correction is crucial.
Why do prompt engineering techniques (like CoT) alone hit fundamental limitations when LLMs face problems requiring complex, multi-step reasoning, and what inherent properties of LLMs are related to these limitations?

While prompt engineering techniques like CoT significantly enhance LLMs' complex reasoning capabilities, they hit fundamental limitations due to the following inherent properties of LLMs themselves:
1. Sensitivity to Surface Patterns: LLMs react very sensitively to the surface form of the prompt, such as word choice or sentence structure. Even slight changes in phrasing, while preserving meaning, can lead to unstable results. This is because models rely heavily on statistical pattern learning rather than deep semantic understanding.
2. Limits of Inherent Reasoning Ability: Prompting primarily serves to elicit the reasoning capabilities the model already possesses, rather than creating new logical, mathematical, or common-sense reasoning abilities it lacks. CoT merely makes the model's reasoning process explicit; this process itself can still contain errors. This stems from LLMs learning implicit knowledge and patterns from vast text data, rather than having explicit symbolic manipulation or reasoning engines.
3. Tendency Towards Hallucination: When pushed beyond their knowledge boundaries or faced with very complex reasoning demands, LLMs tend to generate plausible-sounding but factually incorrect or logically inconsistent content (hallucinations). Prompting alone cannot fully guarantee the factual correctness or logical soundness of the generated content.
4. Error Propagation and Difficulty in Correction: In linear step-by-step reasoning methods like CoT, small errors in early steps can propagate and significantly impact the final result. Furthermore, the autoregressive generation process makes it difficult for LLMs to spontaneously correct a flawed reasoning path or explore alternative routes once committed (which ToT aims to mitigate).
5. Context Length Limitation: There's a physical limit to the amount of information (examples, instructions) that can fit into the prompt and the length of the reasoning process (like CoT) that can be represented. Very long and complex problems become intractable with prompting alone.
In conclusion, prompt engineering is a powerful interface for maximizing LLM capabilities, but it cannot overcome the fundamental limitations inherent in the LLM architecture and training paradigm. Achieving breakthroughs in truly complex reasoning likely requires advancements in prompting techniques alongside fundamental improvements in model architecture, learning algorithms, and data strategies.
How can prompts induce planning? Explain frameworks like ReAct for tool use.

Planning behavior can be induced in LLMs by explicitly asking them to create a plan in the prompt. For instance, one could instruct: "First, outline a step-by-step plan to solve this problem, then execute the plan."

The ReAct (Reason + Act) framework provides a more structured approach for enabling LLMs to solve complex tasks by interleaving reasoning and action. It is particularly effective for tasks requiring the use of external tools like search engines, calculators, or API calls.

How ReAct Works:
ReAct typically structures the prompt to make the LLM operate within a thought-action-observation loop:
1. Thought: The LLM considers the current problem state, results from previous steps (observations), and the final goal to analyze the situation and formulate a plan for the next action. (e.g., "I lack current information, I need to search for it.")
2. Action: Based on the plan, the LLM determines the specific action to perform. This usually involves specifying the external tool to use and the input (arguments) for that tool in a defined format. (e.g., Action: Search[keywords to search])
3. Observation: An external system (the ReAct execution environment) actually performs the action specified by the LLM (e.g., calls a search engine API) and obtains the result (e.g., search result summary). This result is provided back as 'observation' information, which is included in the LLM's input prompt for the next cycle.
The LLM repeats this 'Thought → Action → Observation' cycle, dynamically adjusting its plan, leveraging external tools to gather necessary information or perform calculations, and reasoning based on the outcomes. This allows LLMs to effectively tackle complex problems or questions requiring up-to-date information that cannot be solved using their internal knowledge alone.
What core limitations of LLMs do AI agent frameworks like AutoGen or MetaGPT aim to address by leveraging LLMs, and what specific functional components do these frameworks provide to transform LLMs beyond simple text generation tools into goal-oriented problem-solving systems?

AI agent frameworks like AutoGen and MetaGPT build upon the powerful language understanding and generation capabilities of LLMs but are designed to perform complex, multi-step, goal-oriented tasks autonomously, going beyond simple question-answering or text generation. They aim to evolve LLMs from mere 'tools' into 'intelligent agents' capable of planning, acting, interacting, and collaborating.
The core limitations of LLMs that these frameworks seek to address include:
- Lack of State and Memory Management: LLMs can only process information within their limited context window and struggle to maintain long-term state or memory.
- Inability to Interact with the External World: LLMs alone cannot use external tools (APIs, databases, search engines) or interact with real-world environments.
- Limited Complex Planning and Task Decomposition: They lack the ability to systematically create plans and break down complex goals into sub-tasks.
- Poor Self-Reflection and Refinement: Their ability to recognize and correct flaws in their own outputs or plans is limited.
To overcome these limitations, AI agent frameworks use LLMs as their core engine while providing the following functional components:
- Planning and Task Decomposition: Analyze complex user goals to generate and manage plans consisting of sequences or structures of executable sub-tasks.
- Tool Use: Provide interfaces allowing the LLM to call and utilize various external tools as needed, such as APIs, calculators, code interpreters, and search engines (e.g., leveraging the ReAct paradigm).
- Memory Management: Offer long-term memory mechanisms (e.g., using vector databases) that go beyond the short-term context window, allowing agents to store and retrieve information gathered during task execution or from past interactions.
- Multi-Agent Collaboration: Support scenarios where multiple LLM-based agents, potentially with different roles or expertise, can communicate and interact to solve complex problems collaboratively. (e.g., AutoGen's conversational agents, MetaGPT's simulation of role-based software development processes).
- Self-Reflection and Refinement: Enable agents to evaluate their own intermediate outputs (plans, code, documents) and identify/correct issues, thereby improving the quality and reliability of the final results.
In conclusion, AI agent frameworks aim to complement the core capabilities of LLMs by integrating functionalities like planning, tool use, memory, collaboration, and self-reflection. This addresses the limitations of LLMs and seeks to evolve them from simple API endpoints into sophisticated systems capable of tackling complex, practical problems.

IX. Evaluation and Benchmarking

Discuss the challenges in evaluating generative models, contrasting automated metrics with human evaluation.

Evaluating the performance of generative models presents inherent difficulties for several reasons:
Sources of Difficulty:
- Subjectivity and Open-Ended Outputs: Unlike classification or prediction tasks with single correct answers, the quality of generative model outputs (text, images, etc.) can be subjective, and the outputs themselves can be highly diverse. Creativity, style, and aesthetic appeal are hard to quantify.
- Multifaceted Evaluation Criteria: Good generative outputs often need to satisfy multiple criteria simultaneously, such as relevance, factual accuracy, coherence, consistency, fluency, safety, and usefulness. It's difficult for a single metric to capture all these aspects comprehensively.
Comparison of Evaluation Methods:
- Automated Metrics:
  - Examples: BLEU, ROUGE scores for text generation; FID (Fréchet Inception Distance), IS (Inception Score) for image generation.
  - How they work: Typically calculate surface-level features of the output (e.g., word overlap rates, pixel distribution similarity).
  - Pros: Fast, inexpensive, and allow for large-scale evaluation, useful for iterative testing during model development.
  - Cons: Often fail to reflect the actual quality, semantic accuracy, logical errors, creativity, or harmfulness of the generated content accurately. Frequently show low correlation with human preferences.
- Human Evaluation:
  - How it works: Real people directly assess the generated outputs based on predefined criteria (e.g., fluency, relevance, creativity, safety) by assigning scores or comparing preferences.
  - Pros: The most reliable method for assessing aspects missed by automated metrics, such as subtle quality differences, contextual understanding, creativity, and the actual usefulness and safety perceived by users.
  - Cons: Time-consuming, expensive, and labor-intensive. Can suffer from subjectivity, inter-rater disagreement, and potential biases among evaluators. Maintaining evaluation consistency is challenging. In conclusion, there is often a significant gap between what automated metrics can easily measure and what humans actually perceive as high-quality or useful. Therefore, generative model evaluation typically employs both automated metrics and human evaluation in a complementary manner.
How is the intrinsic factuality of LLMs systematically evaluated (e.g., using TruthfulQA)?

Evaluating whether an LLM generates fact-based information or plausibly sounding misinformation (hallucinations) is crucial for its reliability and requires a systematic approach beyond simple accuracy measurement.
Evaluation Methods and Benchmarks:
- Using Specialized Benchmarks:
  - TruthfulQA: Includes questions deliberately designed to mimic common misconceptions or falsehoods that might seem correct. It assesses the model's ability to generate truthful answers instead of merely repeating misinformation it might have learned from the internet.
  - HaluEval: Provides datasets intentionally containing hallucinations to evaluate the model's ability to detect them.
- Measuring Quantitative Metrics:
  - Factual Question Accuracy: Measures how accurately the model answers factual questions with clearly known answers.
  - Faithfulness Evaluation: In RAG systems, assesses how well the model's generated answer aligns with the content of the referenced external documents (context).
  - Calibration Analysis: Analyzes whether the confidence level expressed by the model in its answers correlates well with its actual accuracy. Poor calibration makes it hard to trust the model's outputs.
- Applying Diverse Methodologies:
  - Knowledge Probing: Assesses the extent of the model's knowledge within specific domains.
  - Adversarial Questioning: Uses questions designed to confuse the model or elicit incorrect answers.
  - External Knowledge Verification: Checks claims made by the model against external knowledge bases like Wikipedia or trusted databases.
  - LLM-as-a-Judge: Uses another powerful LLM to evaluate the factuality or quality of the model's answers (though the judge LLM's own biases can interfere).
Systematically evaluating LLM factuality requires using diverse benchmarks and metrics specifically targeting this failure mode (hallucination), often complementing automated scores with careful human analysis.
How is the reasoning ability of LLMs evaluated? Mention key benchmarks.

Evaluating the reasoning ability of LLMs aims to measure higher-order cognitive skills like logical thinking, mathematical problem-solving, step-by-step deduction, and common-sense understanding, going beyond simple information retrieval or pattern memorization. Various benchmarks composed of problems requiring genuine reasoning processes are used for this purpose. Key benchmarks include:
- MMLU (Massive Multitask Language Understanding): Comprehensively evaluates broad knowledge and problem-solving abilities with multiple-choice questions covering 57 diverse subjects, from STEM fields to humanities and social sciences.
- GSM8K (Grade School Math 8K): Consists of grade school level math word problems requiring multiple arithmetic steps, measuring the model's mathematical reasoning and step-by-step problem-solving skills. Often evaluated using Chain-of-Thought (CoT) prompting.
- BIG-Bench (Beyond the Imitation Game Benchmark): A large-scale collaborative benchmark designed to evaluate a wide range of challenging cognitive abilities, including difficult reasoning problems.
- HellaSwag: Assesses commonsense reasoning through multiple-choice questions asking for the most natural continuation of a given context.
- ARC (AI2 Reasoning Challenge): Comprises challenging science questions (elementary and middle school levels) that require reasoning.
- DROP (Discrete Reasoning Over Paragraphs): A reading comprehension benchmark where finding the answer requires additional discrete reasoning steps like addition, counting, or comparison over the provided text.
- MATH: Includes challenging competition-level mathematics problems requiring advanced mathematical reasoning in areas like algebra, geometry, and number theory.
- HumanEval: A benchmark for evaluating code generation ability, which indirectly measures the logical reasoning skills needed to write correct code.
These benchmarks play a crucial role in guiding development towards models with more robust and complex reasoning capabilities, beyond simple memorization or surface pattern matching.
Explain text-to-image model evaluation regarding prompt alignment (CLIP score), quality/realism (FID), and diversity.

Evaluating text-to-image models, which generate images from textual descriptions (prompts), typically involves considering the following three aspects comprehensively:
1. Prompt Alignment and Fidelity:
  - Meaning: Indicates how faithfully the generated image reflects the content and meaning of the input text prompt. It assesses whether the objects, attributes, relationships, and style described in the prompt are well-represented in the image.
  - Key Metric: CLIP Score is widely used. It employs a vision-language model like CLIP to calculate the semantic similarity (e.g., cosine similarity) between the embedding of the input text prompt and the embedding of the generated image. A higher score generally indicates better alignment with the prompt.
2. Image Quality and Realism:
  - Meaning: Evaluates how visually natural and realistic the generated image is, and whether it contains technical flaws.
  - Key Metric: FID (Fréchet Inception Distance) is the standard metric. It uses a pre-trained Inception network to measure the distance between the feature distributions of generated images and real images. A lower FID score indicates that the generated images are statistically more similar to real images, generally implying higher quality and realism.
3. Diversity:
  - Meaning: Refers to the model's ability to generate varied and distinct images for the same or similar prompts. Lack of diversity might indicate 'mode collapse,' where the model repetitively generates only certain types of images.
  - Evaluation: While FID indirectly reflects some diversity, it's not perfect. Often assessed by measuring similarity between generated images, using specific metrics, or frequently through direct human judgment.
Evaluating text-to-image models typically involves combining automated metrics (like CLIP score and FID) with qualitative analysis through human evaluation (assessing aesthetic appeal, accuracy of details, reflection of subtle prompt nuances, etc.) for a comprehensive assessment.
How are multimodal models evaluated? What are the specific challenges?

Evaluating multimodal models, which process multiple types of information (text, image, audio, etc.) simultaneously, is more complex than evaluating unimodal models. It requires measuring not only performance within each modality but also the ability to understand the interactions between modalities and reason based on them.
Evaluation Methods:
- Using Task-Specific Benchmarks: Performance is commonly measured on specific tasks requiring multimodal capabilities.
  - Visual Question Answering (VQA): Assessing the ability to answer questions about an image (e.g., VQAv2, GQA datasets).
  - Image Captioning: Evaluating the ability to generate natural language descriptions for a given image (e.g., COCO Captions dataset, using metrics like BLEU, CIDEr, SPICE).
  - Text-Image Retrieval: Assessing the ability to find images corresponding to text descriptions or vice versa (e.g., Flickr30k, COCO datasets, using Recall@K metric).
  - Other benchmarks exist for video understanding, audio-visual association, etc.
Specific Challenges:
- Verifying True Cross-Modal Reasoning: It's difficult to distinguish whether a model is genuinely integrating information across modalities to reason or just relying on biases or shortcuts within a single modality to arrive at the correct answer.
- Evaluating Cross-Modal Consistency: For instance, if a model generates both an image and its description, automatically assessing whether the generated text accurately and consistently describes the generated image is challenging.
- Lack of Reasoning Process Evaluation: Standardized methodologies are lacking for evaluating the validity of the cross-modal reasoning process itself that leads to the final output, beyond just checking the correctness of the final answer.
- Data Scarcity: Large-scale, high-quality benchmark data specifically designed to evaluate complex multimodal reasoning capabilities is often still insufficient.
- Subjectivity and Reliance on Human Evaluation: Judging the quality, relevance, and creativity of generated multimodal content inherently involves subjectivity, often necessitating carefully designed human evaluation for reliable assessment.
What are the known limitations or 'gaming' issues with generative model benchmarks?

While benchmarks are essential tools for measuring progress and comparing generative models, they suffer from well-known limitations and potential issues (sometimes called 'gaming' or 'benchmark hacking'):
- Data Contamination: When the test set data, intended for evaluation, unintentionally gets included in the model's pre-training data. In such cases, the model achieves artificially high scores by simply 'memorizing' the answers, invalidating fair performance comparison. This is prone to happen with large web-scraped datasets.
- Benchmark Overfitting: The phenomenon where models become overly optimized for the specific format, question types, or data distribution of the benchmark itself. This can lead to high benchmark scores but poor generalization to real-world, diverse problems.
- Gap Between Metrics and Real Performance: As mentioned earlier, high scores on automated metrics like BLEU or FID do not necessarily guarantee high perceived quality, usefulness, creativity, or safety by humans.
- Sensitivity to Evaluation Setup: Model performance can vary significantly depending on the specific prompts used, sampling parameters applied, etc. Inconsistent or unreported evaluation conditions make direct model comparison difficult.
- Benchmark Staleness and Saturation: Most benchmarks remain static once created. As models improve over time, benchmark tasks can become too easy ('solved'), losing their ability to differentiate the performance of state-of-the-art models.
- Evaluator Bias: Evaluation methods relying on human judgment or LLM-as-a-judge are susceptible to subjectivity, preconceptions, lack of consistency, and other biases of the evaluators.
Due to these limitations, benchmark scores should always be interpreted critically and ideally supplemented with qualitative analysis, additional human evaluations, and tests in real-world application settings for a comprehensive judgment of model performance.
What are techniques for interpreting Transformer behavior (e.g., attention visualization, feature attribution)?

Understanding why a Transformer model makes a specific prediction or generates a certain output – i.e., understanding its internal workings – is crucial for debugging, building trust, improving performance, and ensuring safety. Various interpretation techniques are used for this purpose:
- Attention Visualization:
  - Method: Visualizing the attention weights calculated in the model's attention layers to see which other tokens in the input sequence a particular token 'attended' to more strongly when generating a prediction.
  - Limitation: Research suggests that high attention weights do not always equate to high importance of the attended token.
- Feature Attribution / Importance Analysis (Saliency):
  - Method: Aims to quantify how much each input feature (e.g., a specific word token) contributed to or was important for the model's final output (e.g., a specific prediction probability).
  - Technique Examples: Gradient-based methods that use gradients of the output with respect to the input (e.g., Integrated Gradients), and perturbation-based methods that observe output changes when parts of the input are modified (e.g., LIME).
- Probing Internal Activations:
  - Method: Analyzing the activation patterns of specific neurons or layers inside the model to investigate if they correlate with specific linguistic properties (e.g., part-of-speech, syntactic structure), concepts, or task-related features.
  - Recent Trend: Active research using Sparse AutoEncoders (SAEs) to extract interpretable, sparse features from high-dimensional activation vectors.
- Mechanistic Interpretability:
  - Method: A very ambitious approach that aims to reverse-engineer the actual algorithms or 'circuits' the model has learned to perform specific tasks by meticulously analyzing how its weights and individual components (attention heads, MLP layers, etc.) interact.
- Ablation Studies:
  - Method: Systematically removing or disabling parts of the model (e.g., specific attention heads, certain layers) and observing the resulting change in performance to understand the function or importance of the ablated component.
These interpretation techniques each have their strengths and weaknesses. Relying on a single method is often insufficient; combining multiple techniques usually provides deeper and more comprehensive insights into model behavior.

Appendix: Recommended Learning Resources

Transformer Basics
Advanced LLM Architectures and Concepts
- A Visual Guide to Mixture of Experts(MoE)
- Mixture of Experts Explained
Advanced Training and Fine-tuning Techniques
Multimodal Models
- Multimodality and Large Multimodal Models (LMMs)
- Understanding Multimodal LLMs
Image Generation and Diffusion Models
- The Illustrated Stable Diffusion
- What are Diffusion Models?
Foundation Model Engineering and Infrastructure
- A Visual Guide to Quantization
Reasoning, Prompting, and Agents

시니어 데이터 과학자를 위한 생성형 AI 인터뷰: 핵심 50문 50답

Jonas Kim — Mon, 05 May 2025 13:14:39 +0000

시니어 데이터 과학자를 위한 생성형 AI 분야 테크 인터뷰 대비용으로, 50개의 질문과 답변을 직접 정리해보았습니다.

I. 트랜스포머(Transformer) 기본

트랜스포머 아키텍처의 주요 구성 요소를 설명하고, 이들이 RNN/LSTM의 한계를 어떻게 극복하는지 설명해 주십시오.

트랜스포머는 순차적 처리 방식에 의존하는 RNN/LSTM의 병렬 처리 제약과 장거리 의존성 포착의 어려움을 셀프 어텐션 메커니즘을 통해 극복합니다. 셀프 어텐션은 시퀀스 내 모든 토큰 쌍의 관계를 동시에 계산하여 병렬 처리를 가능하게 하고, 각 토큰이 전체 시퀀스 정보를 활용하여 문맥을 파악하도록 돕습니다. 주요 구성 요소는 다음과 같습니다.
- 셀프 어텐션(Self-Attention): 각 토큰이 시퀀스 내 다른 모든 토큰과의 관련성을 평가하여, 장거리 의존성을 효과적으로 포착하고 문맥 정보를 풍부하게 반영한 표현을 생성합니다.
- 멀티-헤드 어텐션(Multi-Head Attention, MHA): 셀프 어텐션을 병렬적으로 여러 번 수행합니다. 각 '헤드'는 입력 데이터의 서로 다른 특징 부분 공간(subspace)이나 관계에 집중하여, 모델이 더 다양하고 복합적인 패턴을 학습하도록 돕습니다.
- 포지션-와이즈 피드 포워드 네트워크(Position-wise Feed-Forward Network, FFN): 어텐션 계층을 통과한 각 토큰의 표현에 독립적으로 적용되는 완전 연결 신경망입니다. 비선형 변환을 통해 모델의 표현력을 높이고 계산 깊이를 더합니다.
- Add & Norm: 각 서브 계층(셀프 어텐션, FFN)의 입력과 출력을 더하는 잔차 연결(Residual Connection)과 레이어 정규화(Layer Normalization)를 적용합니다. 이는 깊은 네트워크에서 기울기 소실/폭발 문제를 완화하고 학습을 안정화하는 데 필수적입니다.
- 포지셔널 인코딩(Positional Encoding): 순서 정보가 없는 셀프 어텐션에 토큰의 위치 정보를 주입하여 시퀀스 순서를 모델이 인지하도록 합니다.
이러한 구성 요소들의 조합, 특히 병렬 처리 가능한 설계 덕분에 트랜스포머는 대규모 데이터셋과 모델 크기에 효과적으로 확장될 수 있습니다.
셀프 어텐션 메커니즘을 자세히 설명해 주십시오. 쿼리, 키, 밸류 벡터를 사용하여 어텐션 행렬은 어떻게 계산됩니까?

셀프 어텐션은 특정 토큰을 처리할 때 입력 시퀀스 내 다른 모든 토큰이 해당 토큰과 얼마나 관련 있는지 가중치를 계산하는 메커니즘입니다. 각 입력 토큰에 대해 학습 가능한 선형 변환을 통해 쿼리(Query, Q), 키(Key, K), 밸류(Value, V)라는 세 벡터를 생성합니다. 어텐션 가중치를 계산하는 과정은 다음과 같습니다.
1. 스코어 계산: 현재 토큰의 쿼리 벡터(Q)와 시퀀스 내 모든 토큰(자기 자신 포함)의 키 벡터(K) 간의 유사도를 계산합니다. 일반적으로 스케일드 닷-프로덕트 어텐션(Scaled Dot-Product Attention) 방식, 즉 내적 후 키 벡터 차원의 제곱근으로 나누는 방식을 사용합니다. 이를 통해 어텐션 스코어(Attention Score)를 얻습니다.
2. 정규화: 계산된 어텐션 스코어들에 소프트맥스(Softmax) 함수를 적용하여 합이 1이 되는 확률 분포 형태의 어텐션 가중치(Attention Weight)를 만듭니다. 이 가중치는 현재 토큰이 다른 각 토큰에 얼마나 '주의'를 기울여야 하는지를 나타냅니다.
3. 가중 합: 각 토큰의 밸류 벡터(V)를 해당 어텐션 가중치로 가중 평균하여 현재 토큰의 최종 출력 표현을 생성합니다. 이 과정을 통해 각 토큰은 주변 문맥 정보를 효과적으로 통합한 풍부한 표현을 얻게 됩니다.
멀티 헤드 어텐션은 싱글 헤드 어텐션과 어떻게 다릅니까? 장점은 무엇입니까?

멀티-헤드 어텐션(Multi-Head Attention, MHA)은 단일 어텐션 연산을 수행하는 싱글-헤드 어텐션과 달리, 어텐션 메커니즘을 여러 개 병렬로 수행하는 방식입니다. 각 '헤드'는 독립적인 쿼리, 키, 밸류 투영(projection) 행렬을 학습하여, 입력 데이터의 서로 다른 특징 부분 공간(예: 구문적 관계, 의미적 유사성 등)이나 표현 관점에 집중합니다. 각 헤드에서 계산된 어텐션 출력들은 하나로 연결(concatenate)된 후, 추가적인 선형 변환을 거쳐 최종 출력을 형성합니다.

MHA의 주요 장점은 모델이 다양한 관점에서 정보를 동시에 처리하고 통합하여, 단일 헤드보다 더 풍부하고 복합적인 관계를 포착할 수 있다는 것입니다. 이는 결과적으로 모델의 표현력과 성능을 향상시키며, 학습 과정을 안정화하는 데에도 기여할 수 있습니다.
포지셔널 인코딩이 필요한 이유는 무엇입니까? 절대적 방법과 상대적 방법(예: RoPE, ALiBi)을 비교해 주십시오.

트랜스포머의 셀프 어텐션 메커니즘은 토큰의 순서를 고려하지 않으므로(순서 불변성), 모델이 시퀀스 내 토큰의 위치 정보를 이해하도록 포지셔널 인코딩을 명시적으로 주입해야 합니다.
- 절대적 포지셔널 인코딩: 각 토큰의 시퀀스 내 고정된 절대 위치에 기반하여 고유한 인코딩 벡터를 할당합니다. 원본 트랜스포머 논문에서 제안된 사인 및 코사인 함수를 이용한 방식이나, 각 위치별 임베딩을 학습하는 방식 등이 있습니다. 구현이 간단하지만, 훈련 시 보지 못한 길이의 시퀀스에 대한 일반화 성능이 떨어질 수 있다는 단점이 있습니다.
- 상대적 포지셔널 인코딩: 토큰의 절대 위치 대신 토큰 간의 상대적인 거리나 관계를 인코딩합니다. 이는 주로 어텐션 메커니즘 내에서 직접 이루어집니다.
  - RoPE (Rotary Position Embedding): 쿼리(Q)와 키(K) 벡터를 토큰의 위치에 따라 회전 변환시켜 상대적 위치 정보를 반영합니다.
  - ALiBi (Attention with Linear Biases): 어텐션 스코어를 계산할 때 토큰 간 거리에 비례하는 페널티(편향)를 추가하여 상대적 거리를 모델링합니다.
상대적 방법은 일반적으로 다양한 시퀀스 길이에 더 잘 일반화되는 경향이 있어 최신 트랜스포머 아키텍처에서 선호되며, 특히 ALiBi는 구현의 용이성으로 주목받습니다.
인코더-온리(예: BERT), 디코더-온리(예: GPT), 인코더-디코더(예: T5) 아키텍처를 구분하고 일반적인 적용 분야를 설명해 주십시오.

트랜스포머는 구성 요소(인코더, 디코더)의 조합 방식에 따라 크게 세 가지 아키텍처로 분류되며, 각각 다른 정보 처리 방식과 주된 적용 분야를 가집니다.
- 인코더-온리 (Encoder-Only) 아키텍처 (예: BERT): 입력 시퀀스 전체를 한 번에 처리하며, 각 토큰의 표현을 계산할 때 양방향(bidirectional) 문맥 (앞뒤 토큰 모두)을 고려합니다. 입력 전체에 대한 깊은 이해가 중요한 자연어 이해(NLU) 작업(텍스트 분류, 개체명 인식, 질의응답 등)에 주로 사용됩니다.
- 디코더-온리 (Decoder-Only) 아키텍처 (예: GPT): 자기회귀적(autoregressive) 방식으로 작동하여, 출력 시퀀스를 한 토큰씩 순차적으로 생성합니다. 각 토큰을 예측할 때는 이전에 생성된 토큰들만을 참조합니다 (단방향(unidirectional) 또는 인과적(causal) 어텐션). 텍스트 생성, 챗봇, 요약 등 자연어 생성(NLG) 작업에 강점을 보입니다.
- 인코더-디코더 (Encoder-Decoder) 아키텍처 (예: 초기 트랜스포머, T5): 인코더가 입력 시퀀스를 처리하여 문맥 정보를 압축하고, 디코더가 이 정보를 (주로 크로스 어텐션(cross-attention)을 통해) 참조하여 출력 시퀀스를 생성합니다. 입력 시퀀스를 다른 형태의 출력 시퀀스로 변환하는 시퀀스-투-시퀀스(sequence-to-sequence) 작업(기계 번역, 문서 요약 등)에 적합합니다.
표준 트랜스포머(vanilla Transformer)의 계산적 한계는 무엇이며, 이를 해결하기 위한 접근 방식에는 어떤 것들이 있습니까?

표준 트랜스포머(Vanilla Transformer)의 주요 계산적 한계는 셀프 어텐션 연산량과 메모리 요구량이 시퀀스 길이(N)의 제곱(O(N²))에 비례하여 증가한다는 점입니다. 이는 모든 토큰 쌍 간의 어텐션 스코어를 계산하고 저장해야 하기 때문으로, 시퀀스 길이가 매우 길어지면(예: 수만 토큰 이상) 계산 비용이 감당하기 어려워집니다.
이러한 한계를 극복하기 위해 다양한 접근 방식이 제안되었습니다.
- 희소 어텐션 (Sparse Attention): 모든 토큰 쌍을 계산하는 대신, 각 토큰이 미리 정의된 패턴(예: 인접 토큰, 특정 간격의 토큰, 일부 글로벌 토큰)에 따라 제한된 수의 다른 토큰에만 어텐션을 적용합니다. 이를 통해 계산 복잡도를 O(N log N) 또는 O(N) 수준으로 낮출 수 있습니다.
- 효율적/선형화 어텐션 (Efficient / Linearized Attention): 커널(kernel) 기법이나 저차원 근사(low-rank approximation) 등 수학적 방법을 사용하여 전체 어텐션 행렬을 명시적으로 계산하지 않고 어텐션 결과를 근사적으로 계산합니다. 선형 또는 거의 선형(near-linear) 복잡도를 목표로 합니다.
- 하드웨어 최적화: 어텐션 계산 자체는 변경하지 않지만, GPU 메모리 접근(읽기/쓰기) 병목 현상을 최소화하도록 연산 순서를 재구성하는 등 하드웨어 특성을 고려하여 실제 연산 속도를 높이는 기법입니다. FlashAttention이 대표적인 예시로, 정확한(exact) 어텐션 계산 속도를 크게 향상시킵니다.
- 대안 아키텍처: 트랜스포머와 다른 확장성 특성을 가진 상태 공간 모델(State Space Models, SSM)과 같은 새로운 시퀀스 모델링 아키텍처에 대한 연구도 활발히 진행 중입니다. 이러한 방법들은 트랜스포머가 더 긴 시퀀스를 효율적으로 처리하고 대규모 문제에 적용될 수 있도록 확장성을 개선하는 데 기여합니다.

II. 고급 LLM 아키텍처 및 개념

스케일링 법칙(예: Kaplan, Chinchilla)이란 무엇이며, 사전 훈련 리소스 할당에 어떤 정보를 제공합니까?

스케일링 법칙(Scaling Laws)은 대규모 언어 모델(LLM)의 성능(주로 손실 값으로 측정)이 투입되는 자원, 즉 계산 예산(compute budget), 모델 크기(파라미터 수), 훈련 데이터 양(토큰 수)에 따라 예측 가능한 방식으로 개선되는 경험적 관계를 설명합니다. 이 관계는 종종 거듭제곱 법칙을 따르는 것으로 관찰되어, 자원 투입량에 따른 성능 향상을 어느 정도 예측하고 계획하는 것을 가능하게 합니다.
특히 Chinchilla 논문은 주어진 계산 예산 하에서 최적의 성능을 달성하기 위해서는 모델 크기(파라미터)와 훈련 데이터 양(토큰)을 거의 비슷한 비율로 함께 확장해야 한다고 제안하여 큰 영향을 미쳤습니다. 이는 모델의 학습 능력(파라미터 수)과 학습할 내용(데이터 양) 간의 균형이 중요함을 시사합니다. 이 연구는 이전의 많은 대형 모델들이 주어진 계산량 대비 모델 크기가 지나치게 크고 데이터 양은 상대적으로 부족했을 수 있으며('덜 훈련됨' 또는 '계산 비최적'), 동일 계산 예산으로 모델 크기를 줄이고 더 많은 데이터로 훈련했다면 더 나은 성능을 얻었을 수 있음을 암시했습니다.
따라서 스케일링 법칙은 사전 훈련 단계에서 제한된 계산 자원을 모델 크기와 데이터 양 사이에 어떻게 배분할지 결정하는 데 중요한 실증적 지침을 제공합니다. 단순히 가장 큰 모델을 만드는 것보다, 주어진 예산 내에서 최적의 성능을 위한 크기와 데이터 규모의 균형점을 찾는 것이 중요함을 강조합니다. 다만, 이러한 법칙은 경험적 관찰에 기반한 추정치이며, 실제 최적 비율이나 성능 개선 정도는 모델 아키텍처, 데이터 품질, 목표 태스크 등 다양한 요인에 따라 달라질 수 있음을 유의해야 합니다.
LLM의 창발적 능력이란 무엇이며, 예를 들어 설명해 주십시오.

LLM의 창발적 능력(Emergent Capabilities)이란 모델의 규모(파라미터 수, 훈련 데이터, 계산량)가 특정 임계점을 넘어서면서 예측하기 어려웠던 방식으로 갑자기 나타나는 것처럼 보이는 새로운 능력들을 의미합니다. 이러한 능력들은 더 작은 규모의 모델에서는 관찰되지 않거나 성능이 매우 미미하며, 모델이 해당 능력을 갖도록 명시적으로 설계되거나 직접 훈련되지 않았다는 특징이 있습니다.
주요 예시는 다음과 같습니다.
- 다단계 산술 연산 및 복잡한 논리 추론
- 별도의 미세 조정 없이 복잡한 지시사항을 이해하고 따르는 능력
- 아이러니, 유머 등 미묘한 언어적 뉘앙스 파악
- 일관성 있는 코드 생성
- 문제 해결 과정을 단계별로 설명하며 추론하는 연쇄적 사고(Chain-of-Thought) 추론
이러한 창발적 능력의 발견은 모델 규모를 확장하려는 강력한 동기가 되지만, 예측 불가능한 특성으로 인해 모델의 안전성, 신뢰성, 제어 가능성을 확보하는 데 어려움을 야기하기도 합니다.
MoE 아키텍처를 설명해 주십시오. 밀집 모델(dense model)과 비교했을 때 장단점은 무엇입니까?

전문가 혼합(Mixture of Experts, MoE) 모델은 표준 트랜스포머 아키텍처의 일부 피드 포워드 네트워크 계층을 다수의 더 작고 독립적인 '전문가(expert)' 네트워크들로 대체하는 방식입니다. 각 입력 토큰에 대해, 학습 가능한 라우팅 네트워크가 가장 적합하다고 판단되는 소수의 전문가(보통 1~2개)를 동적으로 선택하여 해당 토큰을 처리하도록 보냅니다. 선택된 전문가들의 출력은 조합되어 최종 결과로 사용됩니다.

장점:
- 확장성: 각 입력 토큰 처리 시 활성화되는 파라미터 수를 제한하면서 전체 모델의 파라미터 수를 크게 늘릴 수 있습니다. 이는 동일 추론 속도 대비 더 큰 모델 용량 확보를 가능하게 합니다.
- 추론 효율성: 주어진 토큰에 대해 소수의 전문가만 계산에 참여하므로, 밀집 모델(dense model)에 비해 추론 시 계산 비용(FLOPs)이 훨씬 적습니다.
- 전문가 특화: 각 전문가 네트워크가 특정 종류의 데이터나 패턴 처리에 특화되도록 학습될 잠재력이 있습니다.
단점:
- 훈련 및 구현 복잡성: 모든 전문가가 균형 있게 활용되도록(일부 전문가만 과도하게 사용되거나 유휴 상태가 되지 않도록) 부하 분산(load balancing)을 위한 추가적인 메커니즘(예: 보조 손실 함수)이 필요하며, 전체적인 훈련 안정성을 확보하기 어렵습니다.
- 메모리 요구량: 추론 시 계산에는 일부 전문가만 사용되더라도, 모든 전문가의 파라미터를 메모리에 로드해야 하므로 밀집 모델보다 훨씬 큰 메모리 용량이 필요합니다.
- 라우팅 오버헤드: 토큰을 전문가에게 할당하는 라우팅 계산 자체가 추가적인 연산 부담이 될 수 있습니다.
- 파라미터 효율성: 때로는 동일한 성능을 달성하기 위해 밀집 모델보다 더 많은 총 파라미터 수가 필요할 수 있습니다.
KV 캐싱, 멀티 쿼리 어텐션, 그룹 쿼리 어텐션이 추론 효율성을 어떻게 향상시키는지 설명해 주십시오.

KV 캐싱, 멀티-쿼리 어텐션, 그룹-쿼리 어텐션은 주로 디코더-온리 모델의 자기회귀적 텍스트 생성 과정에서 추론 효율성을 높이기 위한 기법들입니다.
- KV 캐싱(KV Caching): 자기회귀적 생성 시, 각 스텝에서 새로운 토큰을 예측하기 위해 이전까지 생성된 모든 토큰들에 대한 어텐션을 계산해야 합니다. 이때, 이전 토큰들의 키 및 밸류 벡터는 변하지 않는다는 점을 이용하여, 이미 계산된 키와 밸류 벡터들을 메모리(캐시)에 저장해두고 다음 스텝에서 재활용하는 기법입니다. 이를 통해 매 스텝마다 전체 시퀀스에 대한 키/밸류 계산을 반복하는 것을 피해 계산량을 크게 줄일 수 있습니다. 하지만 시퀀스 길이가 길어질수록 캐시가 차지하는 메모리 양이 매우 커진다는 단점이 있습니다.
- 멀티-쿼리 어텐션 (Multi-Query Attention, MQA): 표준 멀티-헤드 어텐션(MHA)에서는 각 어텐션 헤드가 자신만의 키 및 밸류 투영 행렬을 가지지만, MQA에서는 모든 쿼리 헤드가 단 하나의 키와 밸류 헤드(즉, 투영 행렬)를 공유합니다. 이로 인해 저장해야 할 KV 캐시의 크기가 헤드 수만큼 줄어들어 메모리 사용량과 메모리 대역폭 요구량을 크게 절감할 수 있습니다.
- 그룹-쿼리 어텐션 (Grouped-Query Attention, GQA): GQA는 표준 MHA와 MQA 사이의 절충안입니다. 쿼리 헤드들을 여러 그룹으로 나누고, 각 그룹 내의 쿼리 헤드들이 하나의 키 및 밸류 헤드를 공유합니다. MQA보다는 KV 캐시 크기가 크지만, 표준 MHA보다는 훨씬 작습니다. 이를 통해 메모리 사용량을 크게 줄이면서도, MQA에서 발생할 수 있는 품질 저하를 완화하여 MQA보다 더 나은 성능 균형을 보이는 경우가 많습니다.

III. 고급 훈련 및 파인튜닝 기법

데이터 정제, 전처리, 그리고 토크나이저(예: BPE) 선택이 LLM 훈련 및 성능에 어떤 영향을 미칩니까?

데이터 품질과 이를 처리하는 방식은 LLM 훈련 결과와 최종 성능에 결정적인 영향을 미칩니다. 모델은 제공된 데이터로부터 직접 학습하므로, 데이터 내의 결함, 편향, 노이즈까지 그대로 학습하게 됩니다. 따라서 고품질 LLM을 위해서는 세심한 데이터 전처리 과정이 필수적입니다. 주요 단계는 다음과 같습니다.
- 데이터 정제: 노이즈(예: HTML 태그 제거), 불일치성, 형식 오류 등을 수정합니다.
- 중복 제거: 훈련 데이터 내 중복된 내용을 제거하여 학습 효율성을 높이고 모델이 단순히 데이터를 암기하는 것을 방지합니다.
- 품질 필터링: 저품질 또는 부적절한 콘텐츠(예: 욕설, 스팸)를 식별하고 제거합니다.
- 개인정보 및 민감정보 처리: 개인 식별 정보나 민감한 내용을 제거하거나 마스킹합니다.
토크나이저(Tokenizer) 선택 역시 중요합니다. 토크나이저는 텍스트를 모델이 이해할 수 있는 정수 시퀀스(토큰 ID)로 변환하는 역할을 합니다. 바이트 페어 인코딩(Byte Pair Encoding, BPE)과 같은 서브워드(subword) 기반 토크나이저가 널리 사용됩니다. BPE는 빈번하게 등장하는 문자열 쌍을 점진적으로 병합하여 어휘 사전을 구축합니다.
- 어휘 사전 크기: 큰 어휘 사전은 텍스트를 더 적은 수의 토큰으로 압축하여 시퀀스 길이를 줄이고 계산 효율성을 높일 수 있지만, 모델의 임베딩 행렬 크기가 커져 메모리 요구량이 증가하는 트레이드오프가 있습니다.
- 효율성 및 성능: 데이터 특성(예: 코드, 다국어)에 잘 맞는 효율적인 토크나이저를 사용하면 시퀀스 길이를 줄여 계산 부담을 낮추고, 모델이 처리할 수 있는 유효 컨텍스트 길이를 늘릴 수 있습니다. 반대로, 부적절한 토크나이저는 모델 성능 저하를 유발하고, 때로는 보안 취약점으로 이어질 수도 있습니다.
대규모 트랜스포머 훈련을 안정화하는 기술에는 어떤 것들이 있습니까?

매우 큰 트랜스포머 모델을 훈련하는 과정은 불안정하여 손실 값이 갑자기 급증하거나 발산하는 문제가 발생하기 쉽습니다. 이러한 훈련 불안정성을 완화하고 안정적인 학습을 위해 다음과 같은 기술들이 조합되어 사용됩니다.
- 학습률 스케줄링 (Learning Rate Scheduling): 훈련 초기에는 학습률을 서서히 증가시키는 워밍업(warm-up) 단계를 거치고, 이후 학습률을 점진적으로 감소시키는 감쇠(decay) (예: 코사인 감쇠)를 적용하여 최적화 과정을 안정시킵니다.
- 그래디언트 클리핑 (Gradient Clipping): 그래디언트 벡터의 크기가 특정 임계값을 넘지 않도록 조정하여, 그래디언트 폭발 현상을 방지합니다.
- 안정적인 옵티마이저 사용: 표준 Adam 옵티마이저와 L2 정규화를 함께 사용하는 것보다 가중치 감쇠(weight decay) 처리가 개선된 AdamW와 같은 옵티마이저가 일반적으로 더 안정적인 훈련을 제공합니다.
- 신중한 가중치 초기화: 모델 파라미터의 초기값을 적절히 설정하여 훈련 시작 시 활성화 값과 그래디언트가 안정적인 범위 내에 있도록 합니다.
- 레이어 정규화: 트랜스포머 블록 내에서 활성화 값의 분포를 정규화하여 네트워크 전체의 신호 전달을 안정화하는 핵심 요소입니다.
- 적절한 수치 정밀도 사용: 표준 16비트 부동소수점(FP16) 대신 BFloat16을 사용하거나, 옵티마이저 상태 등 중요한 부분에 더 높은 정밀도를 사용하는 혼합 정밀도(mixed precision) 훈련을 통해 수치적 안정성을 향상시킬 수 있습니다.
명령어 튜닝은 일반적인 SFT와 어떻게 다릅니까? 거부 샘플링은 무엇입니까?

지도 파인튜닝(Supervised Fine-tuning, SFT)은 사전 훈련된 모델을 특정 작업에 대한 레이블된 예시 데이터(입력과 정답 출력 쌍)를 사용하여 미세 조정하는 일반적인 과정을 의미합니다.
명령어 튜닝(Instruction Tuning)은 SFT의 한 형태로, 훈련 데이터가 명시적인 '지시사항'과 그에 따른 '바람직한 출력' 쌍으로 구성된다는 특징이 있습니다. (예: "다음 문장을 요약하세요: [긴 문장]" → "[요약된 문장]"). 명령어 튜닝의 목표는 단순히 특정 다운스트림 태스크 성능을 높이는 것을 넘어, 모델이 다양한 형태의 자연어 지시를 이해하고 이를 따르는 일반적인 능력을 학습하도록 하는 것입니다. 이는 모델의 범용성을 높이고, 처음 보는 새로운 작업에 대한 제로샷(zero-shot) 또는 퓨샷(few-shot) 일반화 성능을 향상시키는 데 기여합니다.
거부 샘플링(Rejection Sampling)은 명령어 튜닝 또는 일반적인 SFT를 위한 데이터셋의 품질을 향상시키는 데 사용되는 데이터 큐레이션 기법 중 하나입니다. 과정은 다음과 같습니다.
1. 주어진 지시사항(프롬프트)에 대해 현재 모델을 사용하여 여러 개의 응답 후보를 생성합니다.
2. 미리 정의된 기준(예: 별도의 보상 모델 점수, 특정 규칙 만족 여부, 인간 평가)을 사용하여 각 응답의 품질을 평가합니다.
3. 평가 점수가 가장 높은, 즉 가장 품질이 좋은 응답만을 선별하여 최종 파인튜닝 데이터셋에 포함시킵니다. 이를 통해 품질이 낮은 응답을 걸러내고 양질의 예시 데이터만으로 모델을 학습시켜 최종 모델의 성능과 정렬 수준을 높일 수 있습니다.
RLHF, RLAIF, DPO/GRPO 같은 정렬 방법을 비교 설명해 주십시오. 핵심 메커니즘과 장단점은 무엇입니까?

LLM을 인간의 의도 및 가치와 일치하도록 만드는 '정렬(alignment)' 과정, 즉 모델이 유용하고(helpful), 정직하며(honest), 무해하도록(harmless) 만드는 과정에는 다양한 기법이 사용됩니다. 주요 방법들을 비교하면 다음과 같습니다.
- 인간 피드백 기반 강화 학습 (Reinforcement Learning from Human Feedback, RLHF):
  - 핵심 메커니즘: 1) 인간 평가자가 LLM이 생성한 여러 응답 중 선호하는 것을 선택하여 선호도 데이터를 구축합니다. 2) 이 데이터를 사용하여 어떤 응답이 더 좋은지를 예측하는 별도의 '보상 모델(Reward Model, RM)'을 학습시킵니다. 3) 이 보상 모델을 강화 학습(RL, 예: PPO) 알고리즘의 보상 함수로 사용하여 원래 LLM을 파인튜닝합니다.
  - 장점: 인간의 미묘한 선호도를 직접 반영하여 정렬 품질이 높을 수 있습니다.
  - 단점: 인간 선호도 데이터 수집 비용이 높고, 전체 프로세스가 복잡하며, 학습된 보상 모델의 품질에 최종 성능이 크게 의존합니다.
- AI 피드백 기반 강화 학습 (Reinforcement Learning from AI Feedback, RLAIF):
  - 핵심 메커니즘: RLHF와 유사하나, 비용이 많이 드는 인간 평가자 대신 강력한 다른 AI 모델을 사용하여 선호도 레이블을 생성합니다. 이후 과정은 RLHF와 동일합니다 (AI 생성 데이터로 RM 학습 → RL로 LLM 파인튜닝).
  - 장점: 대규모 선호도 데이터 생성이 용이하여 확장성이 좋습니다.
  - 단점: 최종 정렬 품질이 레이블 생성에 사용된 AI 모델의 성능과 편향에 의존합니다.
- 직접 선호도 최적화 (Direct Preference Optimization, DPO):
  - 핵심 메커니즘: 별도의 보상 모델 학습이나 강화 학습 단계 없이, 선호도 데이터(선호 응답, 비선호 응답 쌍)를 사용하여 LLM을 직접 파인튜닝합니다. 특정 손실 함수를 사용하여 선호되는 응답의 생성 확률은 높이고 비선호 응답의 생성 확률은 낮추도록 직접 학습합니다.
  - 장점: 구현이 RLHF/RLAIF보다 훨씬 간단하고 훈련이 안정적입니다.
  - 단점: 때로는 RLHF만큼 정교한 제어나 최대 성능 달성이 어려울 수 있습니다.
- 그룹 상대 정책 최적화 (Group Relative Policy Optimization, GRPO):
  - 핵심 메커니즘: RL 기반 접근법이지만, 개별 응답 대신 여러 응답 그룹 간의 상대적 선호도를 활용합니다. 특히, 보상 모델이나 별도의 가치 함수(value/critic model)를 명시적으로 학습하는 대신, 그룹 내 응답 점수의 통계량(예: 평균)을 암시적 베이스라인으로 사용하여 정책 그래디언트를 계산합니다.
  - 장점: 별도의 가치 모델이 필요 없어 훈련 중 메모리 등 자원 효율성을 높일 수 있습니다.
  - 단점: 비교적 최신 방법론이며, 적용 및 최적화에 노하우가 필요할 수 있습니다.
요약하면, RLHF와 RLAIF는 보상 모델링과 강화 학습을 결합하며 피드백 소스(인간/AI)에서 차이가 납니다. DPO는 보상 모델링과 RL을 생략하여 단순성을 추구합니다. GRPO는 RL 프레임워크 내에서 그룹 비교와 효율적인 베이스라인 추정을 통해 자원 효율성을 개선합니다. 적합한 방법은 목표 정렬 수준, 가용 데이터, 계산 자원, 구현 복잡성 등을 고려하여 선택됩니다.
RLHF를 위한 보상 모델 설계 시 주요 고려 사항은 무엇입니까?

RLHF의 성공은 LLM 파인튜닝 과정에서 인간의 판단을 대리하는 보상 모델의 품질에 크게 좌우됩니다. 효과적인 RM을 설계하고 훈련할 때 주요 고려 사항은 다음과 같습니다.
- 선호도 데이터의 품질과 다양성: 훈련 데이터에 사용되는 인간 선호도 데이터의 품질이 낮거나 특정 방향으로 편향되어 있다면, 학습된 RM 역시 편향되거나 부정확해져 최종 정렬 결과에 악영향을 미칩니다. 따라서 고품질의 다양하고 일관성 있는 데이터 확보가 매우 중요합니다.
- 선호도 강도 반영: 이상적으로 RM은 단순히 어떤 응답이 더 낫다는 이진적인 판단을 넘어, 그 선호도의 강도(얼마나 더 나은지)까지 포착할 수 있어야 합니다.
- 보정 (Calibration): RM이 출력하는 점수 차이가 실제 인간이 느끼는 선호도 강도의 차이를 정확하게 반영하도록 보정하는 것이 중요합니다. 보정되지 않은 RM은 최적화 과정에서 잘못된 방향으로 유도할 수 있습니다.
- 모델 아키텍처 및 손실 함수: RM의 아키텍처(종종 정렬 대상 LLM 기반으로 초기화)와 훈련에 사용될 손실 함수를 신중하게 선택해야 합니다.
- 보상 해킹 (Reward Hacking) 방지: LLM이 실제 인간 선호도를 따르기보다 단순히 RM으로부터 높은 점수를 받기 위해 RM의 허점이나 잘못 학습된 패턴을 악용하는 '보상 해킹' 현상에 강건해야 합니다.
- RM 평가의 어려움: RM 자체의 성능을 평가하는 것은 까다롭습니다. 선호도 쌍 데이터에 대한 예측 정확도가 높다고 해서 반드시 최종 정렬된 LLM의 품질이 우수하다는 보장은 없습니다.
- 일반화 성능: RM은 훈련 데이터에만 과적합되지 않고, 처음 보는 응답들에 대해서도 인간의 선호도를 잘 예측할 수 있도록 일반화 성능을 갖추어야 합니다.
추론 모델 학습에서 RLHF와 RLVR은 어떤 차이가 있으며, DeepSeek-R1 개발에는 어떤 방식이 주로 사용되었나요?

RLHF와 RLVR(검증 가능한 보상 기반 강화 학습, Reinforcement Learning from Verifiable Rewards)은 모두 강화 학습을 통해 LLM을 개선하는 방법이지만, 보상을 정의하고 제공하는 방식에서 핵심적인 차이가 있습니다.
- RLHF: 보상의 기준이 인간의 주관적인 선호도에 있습니다. 인간 평가자가 모델 응답들 간의 선호도를 판단하고(예: 어떤 응답이 더 유용하고, 안전한지), 이를 바탕으로 학습된 보상 모델이 강화 학습 과정에서 보상 신호를 제공합니다. 주로 모델의 대화 능력, 스타일, 안전성 등 주관적이고 복합적인 품질을 개선하는 데 사용됩니다.
- RLVR: 보상의 기준이 객관적으로 검증 가능한 외부 규칙이나 도구에 있습니다. 예를 들어, 수학 문제 해결 시 외부 계산기를 통해 정답 여부를 확인하거나, 코드 생성 시 컴파일러로 실행 가능 여부 및 테스트 케이스 통과 여부를 확인하여 보상을 제공합니다. 별도의 보상 모델 학습이 필요 없는 경우가 많아 과정이 더 단순하고, 보상 기준이 명확하며 객관적입니다. 특정 작업의 정확성, 규칙 준수 능력 향상에 효과적입니다. DeepSeek-R1 개발, 특히 추론 능력 강화에는 주로 RLVR 방식이 핵심적으로 활용되었습니다. 초기 강화 학습 단계에서 수학 문제 정답 확인, 코드 실행 결과 검증 등 규칙 기반의 '정확성 보상(accuracy rewards)'과 모델이 추론 과정을 특정 형식(<think>, </think>)으로 생성하도록 유도하는 '형식 보상(format rewards)' (RLVR의 일종)을 사용하여 추론 능력을 집중적으로 학습시켰습니다. 이후, 최종 단계에서는 이렇게 확보된 추론 능력 위에 인간 선호도를 반영하는 RLHF 방식 (또는 유사한 보상 모델 기반 방식)을 보조적으로 사용하여 모델의 전반적인 대화 능력, 유용성, 무해성 등을 추가로 개선했습니다. 즉, DeepSeek-R1의 추론 능력 향상에는 RLVR이 중추적인 역할을 담당했고, RLHF는 보완적으로 기여했다고 볼 수 있습니다.
LoRA/QLoRA와 같은 PEFT 방법을 설명해 주십시오. 왜 사용하며, 특히 QLoRA는 어떤 문제를 해결합니까?

파라미터 효율적 파인튜닝(Parameter-Efficient Fine-tuning, PEFT) 기법들은 사전 훈련된 대규모 언어 모델 전체를 미세 조정하는 대신, 모델 파라미터 중 극히 일부만을 업데이트하여 특정 작업이나 요구사항에 맞게 모델을 조정하는 방법론입니다. 이를 통해 파인튜닝에 필요한 계산 자원, 특히 메모리 사용량을 크게 절감할 수 있습니다.
- LoRA (Low-Rank Adaptation): 널리 사용되는 PEFT 기법 중 하나입니다. 핵심 아이디어는 사전 훈련된 모델의 원래 가중치는 동결시킨 채로, 특정 계층(주로 어텐션 계층)에 작고 학습 가능한 '어댑터' 행렬을 추가하는 것입니다. 이 어댑터는 일반적으로 원래 가중치 행렬의 변화량을 나타내는 두 개의 저차원(low-rank) 행렬의 곱으로 표현되며, 파인튜닝 시에는 이 작은 어댑터 행렬들만 학습합니다.
- QLoRA (Quantized LoRA): LoRA를 기반으로 메모리 사용량을 더욱 극적으로 줄이는 기법입니다. 핵심은 동결된 거대 기본 모델의 가중치를 4비트와 같은 매우 낮은 정밀도로 양자화(quantization)하여 메모리에 로드하는 것입니다. 그래디언트 계산은 이 양자화된 가중치를 통해 이루어지지만, 실제 업데이트는 여전히 더 높은 정밀도(예: BFloat16)로 유지되는 작은 LoRA 어댑터에만 적용됩니다. 추가적으로 이중 양자화(double quantization), 페이징된 옵티마이저(paged optimizers) 등의 메모리 최적화 기술을 함께 사용합니다. QLoRA는 매우 큰 모델(수십~수백억 파라미터)도 메모리가 제한된 환경(예: 단일 소비자용 GPU)에서 파인튜닝하는 것을 가능하게 만들어 LLM 접근성을 크게 높였습니다.
파인튜닝한 모델을 병합하는 기술(예: Task Arithmetic, SLERP)과 그 목적을 간략히 설명해 주십시오.

모델 병합(Model Merging)은 일반적으로 동일한 기본 모델에서 파인튜닝된 두 개 이상의 모델 파라미터를 결합하여, 추가적인 훈련 없이 새로운 단일 모델을 만드는 기술입니다. 주된 목적은 다음과 같습니다.
- 다중 능력 결합: 서로 다른 작업(예: 코딩 능력, 대화 능력)에 특화된 모델들을 합쳐 다재다능한 모델 만들기
- 성능 향상: 개별 모델의 장점을 통합하여 일반화 성능 개선 기대
- 배포 간소화: 여러 특화 모델 대신 단일 통합 모델을 배포하여 관리 용이성 증대
주요 병합 기법들은 다음과 같습니다.
- 가중치 평균: 각 모델의 파라미터에 특정 가중치를 부여하여 단순 평균 또는 가중 평균을 계산하는 가장 기본적인 방식입니다.
- 구면 선형 보간법 (SLERP, Spherical Linear Interpolation): 모델 파라미터 벡터 공간 상에서 단순 직선(선형 보간)이 아닌, 구면 상의 호(arc)를 따라 보간하여 더 자연스러운 중간 지점을 찾으려는 기법입니다.
- 태스크 산술 (Task Arithmetic): 파인튜닝된 모델과 원본 기본 모델 간의 파라미터 차이, 즉 '태스크 벡터'를 계산한 뒤, 이 벡터들을 (때로는 가중치를 적용하여) 원본 모델에 더하거나 빼는 방식으로 병합합니다.
- 고급 병합 기법: 여러 모델을 병합할 때 발생하는 파라미터 간 충돌(예: 부호 불일치) 문제를 해결하기 위해, TIES-Merging이나 DARE와 같이 불필요하거나 충돌하는 파라미터를 제거(pruning)하거나, 부호를 조정하거나, 선택적으로 파라미터 값을 리셋하는 등의 전략을 사용하는 더 정교한 방법들도 제안되었습니다.
이러한 모델 병합 기술들은 추가적인 훈련 비용 없이, 이미 학습된 지식과 능력을 효과적으로 결합할 수 있는 방법을 제공합니다.
지속적 사전 훈련 또는 연속 학습 시스템을 설계할 때 마주하게 되는 핵심적인 기술적 어려움들과 그에 따른 실질적인 트레이드오프는 무엇이며, 이러한 문제들을 완화하기 위해 주로 어떤 접근 방식들이 사용됩니까?

지속적 사전 훈련(Continuous Pre-training) 또는 연속 학습(Continual Learning)은 모델을 주기적으로 처음부터 재훈련하는 대신, 시간이 지남에 따라 들어오는 새로운 데이터로 모델을 점진적으로 업데이트하는 시스템을 목표로 합니다. 이러한 시스템을 구축하고 운영하는 데에는 다음과 같은 주요 기술적 어려움과 트레이드오프가 존재합니다.
- 파국적 망각 (Catastrophic Forgetting): 모델이 새로운 데이터나 작업을 학습하면서 이전에 학습했던 지식이나 능력을 급격히 잃어버리는 현상입니다. 이는 연속 학습의 가장 근본적인 문제입니다. 이를 완화하기 위해 정규화 기법, 이전 데이터의 일부를 재학습시키는 리플레이 기법, 모델 파라미터의 중요도를 계산하여 변화를 제한하는 방법 등이 연구됩니다.
- 계산 효율성: 대규모 모델을 새로운 데이터로 업데이트하는 과정을 과도한 계산 비용 없이 효율적으로 수행해야 합니다. 전체 재훈련보다는 비용이 적어야 의미가 있습니다.
- 데이터 관리 복잡성: 지속적으로 유입되는 데이터 스트림을 관리하는 것은 복잡합니다. 데이터 품질 관리, 저장, 중복 제거, 시간이 지남에 따라 데이터 분포가 변하는 '데이터 드리프트(data drift)' 현상에 대한 대응 등이 필요합니다.
- 훈련 안정성: 지속적인 업데이트 과정 중에도 모델 훈련이 불안정해지거나 발산하지 않고 안정적으로 수렴하도록 보장하는 것이 어려울 수 있습니다.
- 평가의 어려움: 모델 성능을 평가하기 위해 새로운 데이터에 대한 학습 능력뿐만 아니라, 이전 지식의 유지(망각 방지) 정도도 함께 측정해야 하므로 평가가 더 복잡해집니다.
- 아키텍처 적합성: 현재 표준 트랜스포머 아키텍처가 연속 학습에 본질적으로 최적화되어 있지 않을 수 있습니다. 지속적인 학습을 용이하게 하는 동적 아키텍처나 모듈식 구조에 대한 연구가 필요합니다.
- 정렬 유지: 모델이 지속적으로 업데이트되면서, 초기에 설정된 정렬(유용성, 정직성, 무해성) 기준이 저하되거나 바람직하지 않은 방향으로 표류하지 않도록 지속적으로 관리하고 평가해야 합니다. 특히, 새 데이터가 완전히 큐레이션되지 않을 수 있는 경우 더욱 중요합니다.
이러한 어려움들 때문에, 연속 학습 시스템은 종종 성능(새로운 지식 습득)과 안정성(기존 지식 유지), 그리고 계산 비용 간의 트레이드오프를 가집니다.

IV. 검색 증강 생성

RAG 시스템의 주요 구성 요소는 무엇입니까? 파인튜닝보다 RAG가 선호되는 경우는 언제입니까?

검색 증강 생성(Retrieval-Augmented Generation, RAG)는 LLM이 답변을 생성하기 전에 외부 지식 소스에서 관련된 정보를 먼저 검색하고, 검색된 정보를 컨텍스트로 활용하여 최종 응답을 생성하도록 하는 기술입니다. 이를 통해 LLM의 답변 정확성을 높이고 최신 정보를 반영하며, 환각(hallucination)을 줄일 수 있습니다.
RAG 시스템의 주요 구성 요소는 다음과 같습니다.
- 검색기: 사용자 쿼리(질문)가 주어지면, 미리 구축된 지식 베이스에서 관련성이 높은 문서나 텍스트 구절을 찾는 역할을 합니다.
- 지식 베이스: 검색 대상이 되는 정보의 모음입니다. 외부 문서, 데이터베이스 내용 등을 색인(indexing)하여 구축합니다.
- 생성기: 일반적으로 LLM을 의미하며, 사용자의 원본 쿼리와 검색기가 찾아낸 관련 정보를 함께 입력받아, 이를 바탕으로 최종 답변을 생성합니다.
RAG가 파인튜닝보다 선호되는 경우:
- 외부 지식 통합: 모델의 파라미터 내에 저장하기 어려운 방대하거나, 빠르게 변화하거나, 특정 도메인에 특화된 외부 지식을 실시간으로 활용해야 할 때 유용합니다.
- 최신성 및 사실 기반 응답: 지식 베이스만 업데이트하면 최신 정보를 반영할 수 있으며(모델 재훈련보다 훨씬 저렴), 검색된 문서를 근거로 제시하여 답변의 신뢰도를 높이고 출처를 명확히 할 수 있습니다.
- 환각 감소: 모델이 잘 모르는 내용에 대해 추측하는 대신 검색된 사실에 기반하여 답변하도록 유도하여 환각 현상을 줄일 수 있습니다.
- 특정 정보 접근: 파인튜닝 시 발생할 수 있는 지식 망각 위험 없이 특정 정보를 정확하게 참조해야 할 때 효과적입니다.
반면, 파인튜닝은 모델의 스타일, 톤, 말투를 바꾸거나, 특정 기술이나 복잡한 행동 패턴을 내재화시키는 등 모델 자체의 근본적인 특성이나 능력을 변화시키고자 할 때 더 적합합니다.
어휘적, 의미적, 하이브리드 검색 방법을 비교 설명해 주십시오.

RAG 시스템에서 검색기는 다양한 방식으로 관련 정보를 찾을 수 있습니다. 주요 검색 방법은 다음과 같습니다.
- 어휘적(lexical) 검색:
  - 작동 방식: 주로 키워드 일치에 기반합니다. 텍스트 내 단어의 빈도, 문서 내 분포 등을 계산하여 점수를 매기는 희소 벡터 방식(예: TF-IDF, BM25)을 사용합니다.
  - 장점: 계산 효율성이 높고, 쿼리에 포함된 정확한 키워드가 포함된 문서를 찾는 데 효과적입니다.
  - 단점: 단어의 의미적 유사성(예: 동의어, 다른 표현)을 파악하기 어렵습니다. '자동차 사고'와 '차량 충돌'을 다른 것으로 인식할 수 있습니다.
- 의미론적(semantic) 검색:
  - 작동 방식: 신경망 기반의 언어 모델(인코더, 예: E5, BGE)을 사용하여 쿼리와 문서를 의미를 내포한 밀집 벡터로 변환합니다. 벡터 공간 상에서 쿼리 벡터와 가장 가까운(유사한) 문서 벡터를 찾아 검색합니다.
  - 장점: 키워드가 정확히 일치하지 않아도 문맥과 의미가 유사한 문서를 찾을 수 있습니다.
  - 단점: 임베딩 생성 및 벡터 검색에 상대적으로 높은 계산 비용이 필요하며, 성능이 임베딩 모델의 품질에 크게 의존합니다.
- 하이브리드(hybrid) 검색:
  - 작동 방식: 어휘적 검색과 의미론적 검색을 결합하여 사용하는 방식입니다. 각 방식의 검색 점수를 조합(fusion)하거나, 한 방식으로 후보군을 추린 뒤 다른 방식으로 순위를 재조정(re-ranking)하는 전략 등을 사용합니다.
  - 장점: 각 방식의 단점을 보완하고 장점을 활용하여 전반적으로 더 강력하고 안정적인 검색 성능을 기대할 수 있습니다.
  - 단점: 시스템 구현 및 튜닝의 복잡도가 증가합니다.
RAG 성능(예: RAGAS 프레임워크)은 어떻게 평가합니까? 주요 지표는 무엇입니까?

RAG 시스템의 성능을 평가하는 것은 검색과 생성 두 단계의 품질을 모두 고려해야 하므로 다면적입니다. 단순히 최종 답변의 품질만 보는 것이 아니라, 각 구성 요소가 제 역할을 잘 수행하는지 개별적으로, 그리고 전체적으로 평가해야 합니다. RAGAS와 같은 프레임워크는 이러한 평가 과정을 자동화하고 표준화하려는 시도 중 하나이며, 종종 다른 LLM을 평가자로 활용합니다.
주요 평가 지표는 다음과 같습니다.

1. 검색기 성능 평가:
- 컨텍스트 정밀도 (Context Precision): 검색된 문서들 중 실제로 질문과 관련 있는 문서의 비율이 얼마나 되는지를 측정합니다. 관련 없는 정보가 많이 검색되었다면 이 점수가 낮아집니다.
- 컨텍스트 재현율 (Context Recall): 질문에 답하기 위해 필요한 모든 관련 정보가 검색 결과 내에 포함되었는지를 측정합니다. 중요한 정보가 누락되었다면 이 점수가 낮아집니다.
2. 생성기 성능 평가:
- 충실성 (Faithfulness): 생성된 답변이 제공된 컨텍스트(검색된 문서)의 내용과 얼마나 일치하는지, 즉 컨텍스트에 없는 내용을 지어내지 않았는지(환각 방지)를 평가합니다.
- 답변 관련성 (Answer Relevancy): 생성된 답변이 사용자의 원본 질문에 대해 직접적이고 명확하게 답하고 있는지를 평가합니다. 답변이 장황하거나 질문의 요점을 벗어나면 이 점수가 낮아집니다.
3. 종단간(end-to-end) 평가 (필요시 정답 데이터 활용):
- 답변 정확성 (Answer Correctness): 생성된 답변이 실제 정답 또는 사실과 얼마나 일치하는지를 평가합니다. (정답 데이터가 있는 경우)
- 답변 의미 유사성 (Answer Semantic Similarity): 생성된 답변이 참조(정답) 답변과 의미적으로 얼마나 유사한지를 평가합니다. (정답 데이터가 있는 경우)
이처럼 다양한 지표를 통해 RAG 시스템의 성능 병목 지점이 검색 단계의 문제인지, 생성 단계의 문제인지, 혹은 두 단계 모두의 문제인지를 진단하고 개선 방향을 설정하는 데 도움을 받을 수 있습니다.
기본적인 검색-생성 파이프라인을 개선하기 위한 고급 RAG 기법에는 어떤 것들이 있습니까? HyDE와 같은 쿼리 변환 기법, 재순위화, 또는 순환적 검색과 같은 전략들은 어떻게 작동하며, 표준 RAG에 비해 어떤 이점을 제공합니까?

기본적인 검색-생성 방식의 RAG도 효과적이지만, 검색된 정보의 관련성이 부족하거나 복잡한 질문에 대한 답변 능력이 제한되는 경우가 있습니다. 이러한 한계를 극복하고 성능을 개선하기 위해 다음과 같은 고급 RAG 기법들이 사용됩니다.
- 쿼리 변환: 사용자의 원본 쿼리가 검색에 비효율적일 수 있다는 점에 착안하여, 검색 성능을 높이기 위해 쿼리를 변형하는 기법입니다.
  - HyDE (Hypothetical Document Embeddings): 원본 쿼리 대신, LLM을 사용하여 해당 쿼리에 답할 만한 '가상의 이상적인 문서'를 먼저 생성합니다. 이 가상 문서는 내용이 풍부하므로, 이를 임베딩하여 검색하면 원본 쿼리만 사용할 때보다 관련성 높은 실제 문서를 찾을 확률이 높아집니다. 특히 짧거나 모호한 쿼리에 효과적입니다.
  - 이 외에도 쿼리를 여러 개의 하위 쿼리로 분해하거나, 쿼리 내 핵심 키워드를 추출/확장하는 등의 변환 방법이 있습니다.
- 재순위화 (Re-ranking): 초기 검색 단계에서는 속도를 위해 비교적 간단한 방식으로 다수의 후보 문서를 검색하는 경우가 많습니다. 재순위화는 이 초기 후보 문서들을 대상으로, 더 정확하지만 계산 비용이 높은 모델(예: 쿼리와 문서를 함께 입력받는 크로스-인코더)을 사용하여 관련성 점수를 다시 계산하고 순위를 조정하는 단계입니다. 이를 통해 최종적으로 생성기(LLM)에게 전달되는 문서들의 평균적인 관련성을 높여 답변 품질을 향상시킵니다.
- 순환적/반복적 검색: 한 번의 검색만으로는 충분한 정보를 얻기 어려운 복잡한 질문에 대응하기 위한 전략입니다.
  - 작동 방식: 초기 검색 결과를 분석하여 정보가 부족하다고 판단되면, 이전 결과를 바탕으로 새로운 쿼리를 생성하여 추가 검색을 수행합니다. 이 '검색 → 분석 → (필요시) 새 쿼리 생성 → 검색' 과정을 필요한 정보가 충분히 모일 때까지 반복합니다.
  - 이점: 여러 단계의 추론이 필요하거나 다양한 관점의 정보를 종합해야 하는 질문에 대해 더 깊이 있고 포괄적인 답변 생성이 가능해집니다.
이 외에도 지식 그래프를 활용하는 Graph RAG, 작은 텍스트 조각에서 시작하여 점차 큰 단위로 검색 범위를 넓히는 Small-to-Big 검색 등 다양한 고급 RAG 기법들이 연구되고 있습니다. 이러한 기법들은 표준 RAG 파이프라인의 약점을 보완하고 특정 유형의 질문이나 데이터에 대한 성능을 극대화하는 데 기여합니다.

V. 멀티모달 모델

멀티모달 모델(예: CLIP, Flamingo, LLaVA)은 일반적으로 텍스트와 이미지 정보를 어떻게 융합합니까?

멀티모달 모델은 텍스트, 이미지, 오디오 등 서로 다른 모달리티의 정보를 함께 처리하고 이해하기 위해 다양한 정보 융합(fusion) 전략을 사용합니다. 주요 접근 방식은 다음과 같습니다.
- 공유 임베딩 공간:
  - 예시: CLIP
  - 작동 방식: 각 모달리티(예: 텍스트, 이미지)를 처리하는 별도의 인코더를 사용하여 각각의 임베딩을 생성한 뒤, 이 임베딩들을 하나의 공유된 잠재 공간으로 투영하도록 학습합니다. 대조 학습(contrastive learning) 목표를 사용하여, 서로 연관된 데이터 쌍(예: 이미지와 그 설명을 담은 텍스트)의 임베딩은 이 공유 공간에서 서로 가까워지도록, 관련 없는 쌍은 멀어지도록 훈련합니다. 융합은 이 임베딩 공간에서의 근접성을 통해 암묵적으로 이루어집니다.
- 크로스 어텐션:
  - 예시: Flamingo
  - 작동 방식: 한 모달리티의 정보가 다른 모달리티의 정보를 직접 참조하도록 명시적인 어텐션 메커니즘을 사용합니다. 예를 들어, 사전 훈련된 LLM의 특정 계층들 사이에 크로스 어텐션 계층을 삽입하여, 텍스트 토큰(쿼리 역할)이 비전 인코더로부터 추출된 시각적 특징 토큰 시퀀스(키/밸류 역할)에 직접 주의를 기울이도록 합니다. 이를 통해 텍스트 생성 과정에서 시각 정보를 능동적으로 활용합니다.
- 입력 수준 융합:
  - 예시: LLaVA
  - 작동 방식: 이미지 인코더(예: ViT)를 통해 추출된 시각적 특징을 텍스트 토큰 임베딩과 동일한 차원으로 변환하는 투영 계층을 사용합니다. 이렇게 변환된 시각적 특징 벡터들을 일종의 '가상 시각 토큰'으로 간주하고, 이를 텍스트 토큰 임베딩 시퀀스와 단순히 연결합니다. 이후, 표준 LLM(생성기)이 이 결합된 시퀀스(텍스트 토큰 + 시각 토큰)를 입력으로 받아, 내부의 셀프 어텐션 메커니즘을 통해 자연스럽게 텍스트 정보와 시각 정보를 함께 처리하며 융합합니다.
이 외에도 네트워크의 여러 지점에서 특징을 병합하기 위해 게이팅 메커니즘 등을 사용하는 전용 융합 모듈을 설계하는 방식도 있습니다.
멀티모달 모델 설계/훈련의 주된 어려움은 무엇입니까?

효과적인 멀티모달 모델을 설계하고 훈련하는 과정에는 다음과 같은 주요 어려움들이 존재합니다.
- 고품질 대규모 데이터셋 확보: 서로 다른 모달리티(예: 이미지와 정확히 일치하는 상세 텍스트 설명)가 잘 정렬된 대규모의 고품질 데이터셋을 구축하는 것은 비용과 시간이 많이 소요되며 어려운 작업입니다. 데이터의 품질이나 정렬 상태가 나쁘면 모델 성능에 치명적입니다.
- 의미 있는 융합 전략 개발: 단순히 피상적인 연관성을 넘어, 여러 모달리티 정보를 깊이 있게 통합하고 상호 추론할 수 있는 효과적인 융합 메커니즘을 설계하는 것은 여전히 중요한 연구 주제입니다.
- 높은 계산 비용: 멀티모달 모델은 종종 각 모달리티를 처리하기 위한 여러 개의 대형 인코더(예: 비전 인코더 + 언어 모델)를 포함하므로, 사전 훈련 및 파인튜닝에 막대한 계산 자원이 필요합니다.
- 모달리티 간극 (Modality Gap): 이론적으로는 공유된 임베딩 공간을 사용하더라도, 실제로는 서로 다른 모달리티에서 온 임베딩들이 공간 내에서 분리되어 군집을 이루는 경향이 나타날 수 있습니다. 이는 모달리티 간의 원활한 정보 통합을 방해할 수 있습니다.
- 확장성 문제: 더 많은 종류의 모달리티를 지원하거나, 이미지/비디오의 해상도를 높이는 등 모델의 처리 능력을 확장하는 것은 계산 및 메모리 요구량을 기하급수적으로 증가시켜 상당한 기술적 어려움을 야기합니다.
- 평가의 복잡성: 특정 벤치마크 점수를 넘어서 모델이 진정으로 멀티모달 정보를 이해하고 추론하는지 평가하는 것은 어렵습니다. 또한, 모델의 결정 과정을 해석하고, 여러 모달리티 간 상호작용을 통해 증폭될 수 있는 잠재적 편향을 관리하는 것도 중요한 과제입니다.

VI. 이미지 생성 및 확산 모델

확산 과정의 핵심 원리를 설명해 주십시오. 잠재 확산 모델은 어떻게 효율성을 향상시킵니까?

확산 모델(Diffusion Models)은 고품질 이미지를 생성하는 강력한 생성 모델 계열로, 순방향 과정과 역방향 과정이라는 두 단계로 작동합니다.
1. 순방향 과정: 원본 데이터(예: 실제 이미지)에 여러 시간 단계에 걸쳐 점진적으로 가우시안 노이즈를 추가합니다. 충분한 단계를 거치면 데이터는 원래 형태를 알아볼 수 없는 순수한 노이즈 상태가 됩니다. 이 과정은 미리 정해진 스케줄에 따라 진행됩니다.
2. 역방향 과정: 순방향 과정을 거꾸로 되돌리는 노이즈 제거 모델(일반적으로 U-Net 아키텍처 사용)을 학습합니다. 이 모델은 현재의 노이즈가 낀 데이터와 해당 시간 단계 정보를 입력받아, 해당 단계에서 추가되었을 노이즈를 예측합니다. 추론(이미지 생성) 시에는 무작위 노이즈에서 시작하여, 학습된 노이즈 제거 모델을 사용하여 각 단계별로 예측된 노이즈를 반복적으로 제거해 나갑니다. 이를 통해 점진적으로 노이즈를 제거하고 최종적으로 깨끗한 원본 데이터와 유사한 샘플(예: 사실적인 이미지)을 생성합니다.
잠재 확산 모델 (Latent Diffusion Model, LDM) (Stable Diffusion 등의 기반 기술)은 이 과정의 효율성을 크게 개선합니다. 고해상도 이미지의 픽셀 공간에서 직접 확산 과정을 수행하는 대신, 다음 단계를 따릅니다.
- 압축: 사전 훈련된 오토인코더(특히 VAE)를 사용하여 원본 고해상도 이미지를 훨씬 저차원의 잠재 공간 표현으로 압축합니다.
- 잠재 공간 확산: 순방향(노이즈 추가) 및 역방향(노이즈 제거 학습 및 추론) 확산 과정을 이 저차원 잠재 공간 내에서 수행합니다.
- 복원: 역방향 과정을 통해 잠재 공간에서 노이즈가 제거된 최종 잠재 벡터를 얻은 후, 오토인코더의 디코더를 사용하여 이를 다시 원래의 고해상도 픽셀 공간 이미지로 복원합니다.
고차원 픽셀 공간 대신 저차원 잠재 공간에서 연산함으로써, LDM은 노이즈 제거 네트워크(U-Net)의 계산 부담과 메모리 요구량을 대폭 감소시켜, 고해상도 이미지 생성을 훨씬 빠르고 효율적으로 만듭니다.
확산 트랜스포머란 무엇입니까? 기존 U-Net 기반 확산 모델과 어떻게 다르며, 잠재적인 장단점은 무엇입니까?

확산 트랜스포머(Diffusion Transformer, DiT)는 확산 모델의 역방향 노이즈 제거 과정에서 전통적으로 사용되던 U-Net 아키텍처 대신 트랜스포머 아키텍처를 사용하는 모델을 의미합니다.

기존 U-Net 기반 모델과의 차이점:
- 핵심 네트워크: U-Net은 컨볼루션 신경망(CNN) 기반으로, 다운샘플링 경로와 업샘플링 경로 간의 스킵 연결을 특징으로 합니다. 반면, DiT는 비전 트랜스포머(ViT)와 유사하게, 이미지를 여러 개의 작은 패치(patch)로 나누고 이를 시퀀스로 처리하는 트랜스포머를 노이즈 제거 네트워크로 사용합니다.
- 입력 처리: DiT는 일반적으로 (노이즈가 추가된) 잠재 공간 이미지 패치 시퀀스, 시간 단계 임베딩, 그리고 텍스트 임베딩과 같은 조건 정보를 입력으로 받아, 트랜스포머의 셀프 어텐션을 통해 이들 간의 관계를 학습하고 최종적으로 각 패치에 포함된 노이즈를 예측합니다.
잠재적 장점:
- 확장성: 트랜스포머는 NLP, 비전 등 다양한 분야에서 모델 크기 및 데이터 규모 확장에 따른 성능 향상(스케일링)이 입증되었습니다. DiT는 이러한 트랜스포머의 우수한 확장성을 확산 모델에 적용할 수 있는 가능성을 제시합니다.
- 기존 생태계 활용: 기존 트랜스포머 관련 연구, 사전 훈련 기법, 최적화된 구현 등을 활용할 수 있습니다.
잠재적 단점:
- 귀납적 편향 (Inductive Bias) 손실: CNN은 이미지 처리에 유용한 공간적 계층 구조 등의 귀납적 편향을 내재하고 있으나, 트랜스포머는 상대적으로 이러한 편향이 적습니다. (단, 이미지를 패치 단위로 처리하는 것이 이를 일부 완화합니다.)
- 계산 비용: 트랜스포머의 셀프 어텐션 연산은 시퀀스 길이에 따라 계산 비용이 증가할 수 있습니다. (단, LDM처럼 잠재 공간에서 작동하면 이 부담이 크게 줄어듭니다.)
고도로 최적화된 U-Net 아키텍처 대비 DiT의 상대적인 성능 및 효율성은 현재 활발히 연구되고 있는 분야입니다.
클래시파이어-프리 가이던스란 무엇입니까?

클래시파이어-프리 가이던스 (Classifier-Free Guidance, CFG)는 텍스트-이미지 생성과 같은 조건부 확산 모델에서, 생성된 이미지가 주어진 조건(예: 텍스트 프롬프트)에 더 잘 부합하도록 유도하는 기법입니다. 이름에서 알 수 있듯이, 이 과정에서 별도의 분류기 모델을 사용하지 않는다는 특징이 있습니다.

작동 원리:
1. 훈련: 확산 모델(노이즈 예측 네트워크)을 훈련할 때, 두 가지 방식으로 훈련합니다.
  - 조건부 훈련: 노이즈가 추가된 이미지와 조건 정보(예: 텍스트 임베딩)를 함께 입력하여 노이즈를 예측하도록 학습합니다.
  - 비조건부 훈련: 때때로(일정 확률로) 조건 정보를 제거하거나 빈 값으로 대체하고, 노이즈가 추가된 이미지만으로 노이즈를 예측하도록 학습합니다. 즉, 동일한 모델이 조건이 있을 때와 없을 때 모두 노이즈를 예측하는 법을 배웁니다.
2. 추론 (이미지 생성): 이미지를 생성하는 각 노이즈 제거 단계에서, 모델은 두 가지 노이즈 예측값을 계산합니다. 하나는 조건이 주어졌을 때의 노이즈 예측이고, 다른 하나는 조건이 없을 때(비조건부)의 노이즈 예측입니다.
3. 가이던스 적용: 최종적으로 사용할 노이즈 예측값은 이 두 예측값을 조합하여 계산합니다. 비조건부 예측값에 (조건부 예측값과 비조건부 예측값의 차이)를 특정 가중치(guidance scale, 'w')만큼 곱해서 더해줍니다. 이 가중치 'w'가 클수록 조건부 예측 방향으로 더 많이 이동(외삽)하게 됩니다.
4. 이미지 업데이트: 계산된 최종 노이즈 예측값을 사용하여 현재 노이즈 이미지에서 노이즈를 제거하고 다음 단계 이미지를 얻습니다.
효과: 가이던스 스케일 'w' 값을 조절함으로써, 생성되는 이미지가 주어진 조건(텍스트 프롬프트)에 얼마나 충실할지 제어할 수 있습니다. 'w'가 높으면 프롬프트 내용을 더 잘 따르지만 이미지의 다양성이나 품질이 다소 저하될 수 있고, 'w'가 낮으면 다양성은 높아지지만 프롬프트와의 관련성이 떨어질 수 있습니다. CFG는 이 충실도와 다양성 간의 균형을 사용자가 쉽게 조절할 수 있게 해주는 매우 효과적인 기법입니다.

❓ 이름의 유래: CFG 이전에는, 별도의 분류기 모델을 훈련시켜 노이즈 낀 이미지로부터 원하는 클래스나 속성을 예측하고, 이 분류기의 그래디언트를 이용해 확산 과정을 원하는 방향으로 유도하는 방식(클래시파이어 가이던스)이 있었습니다. CFG는 이러한 별도의 분류기 없이 가이던스를 제공하므로 "Classifier-Free"라는 이름이 붙었습니다.
샘플링 전략(예: DDIM, DPM-Solver)을 속도 대 품질 측면에서 비교 설명해 주십시오.

확산 모델 샘플링 전략 또는 솔버(solver)는 학습된 확산 모델로부터 이미지를 생성(샘플링)하는 알고리즘입니다. 확산 모델의 원래 공식인 DDPM 샘플러는 고품질 이미지를 생성할 수 있지만, 수백~수천 번의 노이즈 제거 단계를 거쳐야 하므로 매우 느리다는 단점이 있습니다. 샘플링 전략들은 더 적은 노이즈 제거 단계를 사용하면서도 최대한 높은 품질의 이미지를 생성하여 추론 속도를 높이는 것을 목표로 합니다. 주요 전략들을 속도와 품질 측면에서 비교하면 다음과 같습니다.
- DDIM (Denoising Diffusion Implicit Models):
  - DDPM을 개선한 초기 샘플러 중 하나입니다. DDPM보다 훨씬 큰 시간 간격으로 건너뛰며 샘플링하는 것이 가능하여, 필요한 총 단계를 수십~수백 개 수준(예: 50~250 단계)으로 크게 줄여 속도를 향상시켰습니다.
  - 합리적인 단계 수에서는 양호한 품질을 유지하지만, 매우 적은 단계(예: 10~20 단계 미만)에서는 생성 품질이 눈에 띄게 저하되는 경향이 있습니다.
- DPM-Solver (Diffusion Probabilistic Model Solver) 계열:
  - 확산 과정을 확률적 미분 방정식(SDE) 또는 상미분 방정식(ODE)을 푸는 문제로 해석하고, 이를 더 빠르고 정확하게 풀기 위한 고차 수치 해석 기법들을 적용한 샘플러입니다.
  - DDIM보다 훨씬 적은 단계, 종종 10~25 단계만으로도 매우 높은 품질의 이미지를 생성할 수 있어, 유사 품질 대비 상당한 속도 향상을 제공합니다.
  - DPM-Solver++, UniPC 등 다양한 변형들이 있으며, 특히 CFG와 함께 사용할 때 안정성이 뛰어난 것으로 알려져 있습니다.
결론: 현재로서는 DPM-Solver 계열 샘플러들이 생성 속도와 샘플 품질 간의 가장 우수한 균형을 제공하는 것으로 평가받으며, 확산 모델의 실용성을 크게 높이는 데 기여하고 있습니다. 어떤 샘플러를 선택할지는 요구되는 품질 수준과 허용 가능한 생성 시간 사이의 트레이드오프를 고려하여 결정됩니다.
ControlNet이란 무엇이며, 어떻게 제어 가능한 이미지 생성을 가능하게 합니까?

ControlNet은 사전 훈련된 대규모 텍스트-이미지 확산 모델(예: Stable Diffusion)에 추가적인 공간적 제어 능력을 부여하기 위해 설계된 애드온(add-on) 신경망 모듈입니다. 이를 통해 사용자는 텍스트 프롬프트 외에도 다양한 종류의 조건 이미지를 입력하여 생성될 이미지의 구조, 형태, 포즈 등을 세밀하게 제어할 수 있습니다. 예를 들어 다음과 같은 제어 조건들을 사용할 수 있습니다.
- 캐니 엣지(canny edges) 맵
- 깊이(depth) 맵
- 인간 골격 포즈 (human pose, 예: OpenPose)
- 의미론적 분할 맵 (semantic segmentation map)
- 낙서(scribble) 등
작동 방식 및 특징:
1. 기반 모델 동결: ControlNet은 기존의 강력한 사전 훈련된 확산 모델의 가중치를 전혀 수정하지 않고 그대로 사용(동결)합니다.
2. 인코더 블록 복사 및 학습: 기반 모델의 노이즈 제거 네트워크(보통 U-Net) 내부의 인코딩 부분(다운샘플링 블록들)만을 복사하여, 이 복사본을 학습 가능 상태로 만듭니다.
3. 제어 조건 입력: 사용자가 제공한 제어 조건 이미지(예: 엣지 맵)는 이 학습 가능한 인코더 복사본에 입력됩니다.
4. '제로 컨볼루션' 연결: 학습 가능한 복사본의 각 블록에서 나온 출력 특징들은 '제로 컨볼루션(zero convolution)' (가중치가 0으로 초기화된 1x1 컨볼루션 계층)을 통과한 후, 원본 동결된 U-Net의 해당 디코딩 부분(업샘플링 블록)의 입력에 더해집니다.
5. 훈련: ControlNet을 훈련할 때는 오직 복사된 인코더 블록들과 제로 컨볼루션 레이어의 가중치만 업데이트합니다. 훈련 데이터는 (원본 이미지, 텍스트 프롬프트, 제어 조건 이미지) 쌍으로 구성됩니다.
이러한 구조 덕분에 ControlNet은 기반 모델이 가진 방대한 지식과 생성 능력은 그대로 활용하면서, 추가된 제어 조건에 따라 이미지의 공간적 구조를 효과적으로 제어할 수 있습니다. 제로 컨볼루션은 훈련 초기에는 제어 조건의 영향을 주지 않다가 점차 학습을 통해 제어 정보를 주입하는 역할을 합니다.
사전 훈련된 이미지 생성 모델을 특정 스타일이나 주제에 맞게 조정할 때 주로 사용되는 파인튜닝 기법들은 무엇이며, 각 방식의 특징은 어떤가요? 또한, 이러한 기법들을 적용할 때 주의해야 할 주요 기술적 어려움은 무엇인가요?

사전 훈련된 강력한 이미지 생성 모델을 특정 스타일, 인물, 사물, 또는 개념에 맞게 조정(파인튜닝)하기 위해 여러 기법들이 사용됩니다. 각 기법은 맞춤 설정의 깊이, 필요한 데이터 양, 계산 자원 요구량 등에서 특징을 가집니다.
주요 파인튜닝 기법:
- 전체(full) 파인튜닝:
  - 방식: 모델의 전체 또는 대부분의 가중치를 새로운 목표 데이터셋(특정 스타일의 이미지 등)으로 다시 훈련합니다.
  - 특징: 모델의 동작을 근본적으로 크게 바꿀 수 있어 깊은 수준의 맞춤 설정이 가능하지만, 매우 많은 계산 자원(GPU 메모리, 시간)이 필요하고, 잘못하면 모델이 기존에 가지고 있던 방대한 지식이나 다양한 생성 능력을 잃어버릴 위험이 큽니다.
- PEFT: 모델의 대부분 가중치는 고정한 채, 일부 파라미터만 학습하여 자원 효율성을 높이는 방식입니다. 이미지 생성 분야에서는 다음과 같은 기법들이 널리 쓰입니다.
  - LoRA: 기존 모델의 특정 계층(주로 어텐션 관련)에 저차원 행렬 형태의 작은 '어댑터'를 추가하고 이 어댑터만 학습합니다. 비교적 적은 자원으로 특정 스타일이나 미세 조정을 적용하는 데 효과적입니다.
  - DreamBooth: 소수의 특정 대상(예: 특정 인물, 애완동물) 이미지(보통 3~5장)와 고유한 식별자 문자열(예: "a photo of sks dog")을 사용하여 모델이 해당 대상을 매우 사실적으로 학습하도록 하는 기법입니다. 모델의 일부 가중치를 업데이트합니다.
  - Textual Inversion: 모델의 가중치는 전혀 변경하지 않고, 새로운 개념(스타일, 객체)을 나타내는 새로운 단어에 대한 임베딩 벡터만 학습합니다. 훈련이 매우 가볍고 빠르지만, DreamBooth만큼 특정 대상을 강하게 학습시키기는 어려울 수 있습니다.
주요 기술적 어려움:
어떤 파인튜닝 기법을 사용하든 다음과 같은 어려움에 직면할 수 있습니다.
- 파국적 망각: 새로운 스타일이나 개념을 학습하면서 모델이 이전에 학습했던 다양한 지식과 생성 능력을 잃어버리는 문제입니다. 특히 전체 파인튜닝 시 두드러질 수 있습니다.
- 과적합: 파인튜닝 데이터에 모델이 지나치게 맞춰져, 생성 결과가 해당 데이터와 너무 유사하게만 나오거나 새로운 프롬프트에 대한 일반화 성능이 떨어지는 문제입니다. 결과물이 획일적이 되거나 다양성이 줄어들 수 있습니다.
- 균형 찾기: 원하는 수준의 맞춤 설정을 달성하면서도 모델의 일반적인 생성 능력과 안정성을 유지하는 섬세한 균형점을 찾는 것이 중요합니다. 학습률, 훈련 데이터 양, 훈련 단계 수 등을 신중하게 조절해야 합니다.

VII. 파운데이션 모델 엔지니어링 및 인프라

데이터, 텐서, 파이프라인 병렬 처리를 설명해 주십시오. 각각 언제 사용됩니까? DeepSpeed/FSDP와 같은 프레임워크는 무엇입니까?

매우 큰 모델은 단일 가속기(GPU 등)의 메모리에 모두 들어가지 않거나, 단일 장치로 훈련하기에는 시간이 너무 오래 걸리므로, 여러 장치를 함께 사용하는 분산 훈련 전략이 필수적입니다. 주요 병렬 처리 기법은 다음과 같습니다.
- 데이터 병렬 처리 (Data Parallelism, DP):
  - 방식: 모델 전체를 여러 장치에 복제하고, 각 장치가 전체 데이터 배치의 서로 다른 부분(미니배치)을 처리하여 그래디언트를 계산합니다. 이후 계산된 그래디언트들을 모든 장치에서 평균 내어(예: AllReduce 연산) 모델 가중치를 동시에 업데이트합니다.
  - 사용 시점: 모델 자체는 단일 장치 메모리에 맞지만, 더 많은 데이터를 병렬로 처리하여 훈련 속도를 높이고 싶을 때 주로 사용됩니다. 가장 기본적인 병렬 처리 방식입니다.
- 텐서 병렬 처리 (Tensor Parallelism, TP):
  - 방식: 모델 내의 개별 연산(텐서 연산), 예를 들어 거대한 행렬 곱셈(어텐션이나 FFN 내부) 자체를 여러 장치에 걸쳐 분할하여 수행합니다. 특정 계층의 가중치 행렬이 여러 장치에 분산되어 저장되고, 해당 계층의 순방향 및 역방향 계산 시 장치 간 통신(예: AllReduce, AllGather)이 필요합니다.
  - 사용 시점: 모델의 단일 계층조차 너무 커서 하나의 장치 메모리에 맞지 않을 때 사용됩니다.
- 파이프라인 병렬 처리 (Pipeline Parallelism, PP):
  - 방식: 모델의 전체 계층들을 여러 개의 연속적인 단계로 나누고, 각 단계를 서로 다른 장치에 할당합니다. 데이터는 마치 조립 라인처럼 파이프라인을 따라 한 단계에서 다음 단계로 전달됩니다 (순방향 계산 시 활성화 값 전달, 역방향 계산 시 그래디언트 전달).
  - 사용 시점: 모델 전체가 (텐서 병렬 처리를 사용하더라도) 단일 장치에 맞지 않을 때, 또는 중간 계산 결과(활성화 값) 저장을 위한 메모리 부담을 줄이고 싶을 때 사용됩니다.
실제 대규모 모델 훈련에서는 이러한 세 가지 병렬 처리 기법을 복합적으로 사용하는 하이브리드 방식이 일반적입니다. DeepSpeed나 PyTorch의 FSDP(Fully Sharded Data Parallel)와 같은 프레임워크는 ZeRO와 같은 메모리 최적화 기법과 함께 이러한 복잡한 병렬 처리 전략을 보다 쉽게 구현하고 관리할 수 있도록 다양한 도구와 추상화된 인터페이스를 제공합니다.
ZeRO 1, 2, 3 단계를 설명해 주십시오. 어떻게 메모리 요구 사항을 줄입니까?

ZeRO (Zero Redundancy Optimizer)는 데이터 병렬(DP) 훈련 환경에서 각 장치(GPU)가 중복으로 저장해야 했던 모델 상태 정보(옵티마이저 상태, 그래디언트, 모델 파라미터)를 여러 장치에 걸쳐 분할함으로써, 장치당 메모리 사용량을 획기적으로 줄이는 최적화 기법 모음입니다. 이를 통해 훨씬 더 큰 모델을 제한된 하드웨어로 훈련하는 것을 가능하게 합니다. ZeRO는 최적화 수준에 따라 3단계로 나뉩니다.
- ZeRO 1단계:
  - 분할 대상: 옵티마이저 상태 (예: AdamW 옵티마이저의 모멘텀 및 분산 값)
  - 작동 방식: 각 장치는 전체 모델 파라미터 중 자신이 담당하는 일부분(파티션)에 해당하는 옵티마이저 상태만 저장합니다. 표준 DP에서는 모든 장치가 전체 옵티마이저 상태를 복제하여 저장하지만, ZeRO 1단계에서는 이를 분할하여 메모리 중복을 제거합니다. 파라미터 업데이트 시에는 필요한 옵티마이저 상태를 통신을 통해 가져옵니다.
- ZeRO 2단계:
  - 분할 대상: 옵티마이저 상태 + 그래디언트
  - 작동 방식: 1단계의 옵티마이저 상태 분할에 더해, 그래디언트 또한 장치 간에 분할하여 저장합니다. 역방향 전파(backward pass) 후, 각 장치는 자신이 담당하는 파라미터 파티션에 대한 그래디언트만 계산하고 저장합니다 (ReduceScatter 연산 사용). 표준 DP에서 모든 장치가 전체 그래디언트를 계산하고 AllReduce하는 것과 비교하여 메모리를 추가로 절약합니다.
- ZeRO 3단계:
  - 분할 대상: 옵티마이저 상태 + 그래디언트 + 모델 파라미터
  - 작동 방식: 가장 높은 수준의 최적화로, 모델 파라미터 자체까지 분할합니다. 각 장치는 대부분의 시간 동안 자신이 담당하는 파라미터 파티션만 메모리에 유지합니다. 특정 계층의 순방향 또는 역방향 계산이 필요할 때만, 해당 계산에 필요한 파라미터들을 모든 관련 장치로부터 통신을 통해 일시적으로 불러와(AllGather) 사용하고, 계산이 끝나면 즉시 해제하여 메모리를 확보합니다.
  - 효과: 가장 큰 메모리 절약 효과를 제공하며, 이론적으로 장치 수만 충분하다면 모델 크기와 거의 무관하게 훈련이 가능해집니다.
ZeRO 단계가 높아질수록 메모리 절약 효과는 커지지만, 분할된 데이터를 필요할 때마다 가져와야 하므로 장치 간 통신량은 일반적으로 증가하는 트레이드오프가 있습니다.
양자화 기법(PTQ 대 QAT)과 형식(FP16, BF16, INT8)에 대해 논의해 주십시오. 성능/크기/정확도에 미치는 영향은 무엇입니까? GPTQ/AWQ를 설명해 주십시오.

양자화는 모델의 가중치나 활성화 값을 표현하는 데 사용되는 수치 데이터의 정밀도(비트 수)를 낮추는 기술입니다. 일반적으로 표준인 32비트 부동소수점(FP32) 대신 16비트 부동소수점(FP16, BF16)이나 8비트 정수(INT8) 등을 사용합니다.

목적 및 효과:
- 모델 크기 감소: 더 적은 비트를 사용하므로 모델 파일 크기가 작아져 저장 및 로딩에 유리합니다.
- 메모리 사용량 감소: 추론 시 모델을 메모리에 올릴 때 필요한 공간이 줄어듭니다. 특히 KV 캐시 등 메모리 사용량이 많은 부분에 적용하면 효과가 큽니다.
- 추론 속도 향상: 메모리 대역폭 사용량이 줄어들고, 특정 하드웨어(예: NVIDIA GPU의 Tensor Core)에서 저정밀도 연산 가속을 지원하는 경우 연산 속도 자체가 빨라질 수 있습니다.
주요 형식:
- FP16: FP32보다 절반의 비트를 사용하며, 속도와 정확도 간 균형이 비교적 좋습니다. 하지만 표현 가능한 수의 범위가 좁아 오버플로우/언더플로우 문제가 발생할 수 있습니다.
- BF16 (BFloat16): FP16과 같은 16비트지만, 지수부에 더 많은 비트를 할당하여 FP32와 유사한 넓은 표현 범위를 가집니다. 훈련 및 추론에서 FP16보다 수치적으로 더 안정적인 경향이 있습니다.
- INT8: 8비트 정수를 사용하며, 가장 큰 폭의 속도 향상 및 메모리 절감 효과를 기대할 수 있습니다. 하지만 부동소수점 수를 정수로 변환하는 과정에서 정보 손실이 커서, 정확도 하락을 최소화하기 위한 세심한 변환 과정(보정)이 중요합니다.
주요 양자화 기법:
- 훈련 후 양자화 (Post-Training Quantization, PTQ): 이미 훈련된 모델을 가지고 와서, 추가 훈련 없이 가중치 등을 저정밀도로 변환하는 방식입니다. 종종 소량의 보정 데이터를 사용하여 최적의 변환 스케일링 계수를 찾습니다. 구현이 비교적 간단하지만, 특히 4비트 이하의 매우 낮은 비트로 양자화할 경우 모델 정확도 손실이 발생할 수 있습니다.
  - GPTQ, AWQ: LLM의 가중치를 4비트 수준까지 효과적으로 양자화하기 위해 특별히 개발된 고급 PTQ 기법들입니다. 가중치의 중요도 등을 고려하여 양자화 오류를 최소화함으로써, 매우 낮은 비트에서도 정확도 저하를 최소화하는 것을 목표로 합니다.
- 양자화 인식 훈련 (Quantization-Aware Training, QAT): 모델 훈련 또는 파인튜닝 과정 중에 양자화 연산을 시뮬레이션(가짜 양자화 연산 삽입)합니다. 모델이 양자화로 인한 오차를 미리 경험하고 이에 강건해지도록 학습하므로, 일반적으로 동일 비트 수 대비 PTQ보다 더 높은 정확도를 달성할 수 있습니다. 하지만 추가적인 훈련 과정이 필요하여 시간과 계산 비용이 더 많이 듭니다.
모든 양자화 기법은 효율성(속도, 메모리) 향상과 모델 성능(정확도) 저하 가능성 사이의 트레이드오프를 가집니다.
추측 디코딩은 어떻게 LLM 추론 속도를 높입니까?

추측 디코딩(Speculative Decoding)은 LLM의 자기회귀적 텍스트 생성 과정, 즉 한 토큰씩 순차적으로 생성하는 과정의 추론 속도를 높이는 기법입니다. 핵심 아이디어는 두 개의 모델, 즉 작고 빠른 '초안(draft) 모델'과 크고 정확하지만 느린 '타겟(target) 모델'을 함께 사용하는 것입니다.

작동 방식:
1. 초안 생성: 현재까지 생성된 시퀀스가 주어지면, 작고 빠른 초안 모델이 먼저 앞으로 생성될 몇 개(예: 3~5개)의 토큰 후보 시퀀스를 빠르게 예측하여 제안합니다.
2. 병렬 검증: 크고 느린 타겟 모델은 초안 모델이 제안한 후보 토큰 시퀀스 전체를 입력으로 받아, 단 한 번의 순방향 패스로 병렬 처리합니다. 이 과정에서 타겟 모델은 각 위치에서 자신이 예측했을 토큰과 초안 모델의 제안을 비교하며 검증합니다.
3. 토큰 수락: 타겟 모델이 초안 모델의 제안 중 첫 번째부터 연속적으로 'k'개의 토큰까지는 자신의 예측과 일치한다고 판단하면, 이 'k'개의 토큰을 한꺼번에 최종 출력 시퀀스에 추가합니다.
4. 불일치 처리: 만약 'k+1'번째 토큰에서 타겟 모델의 예측과 초안 모델의 제안이 달라지면, 앞에서 일치한 'k'개의 토큰까지만 수락하고, 'k+1'번째 토큰은 타겟 모델의 예측값을 사용합니다. 이후 다시 초안 모델이 다음 후보 시퀀스를 생성하는 과정을 반복합니다.
효과: 초안 모델이 어느 정도 정확하다면, 이 방식을 통해 비용이 많이 드는 타겟 모델의 순방향 패스 한 번으로 여러 개의 토큰을 동시에 확정할 수 있게 됩니다. 이는 표준적인 자기회귀 디코딩 방식(타겟 모델이 매번 한 토큰씩만 생성)에 비해 전체 생성 시간을 2배~4배 이상 크게 단축시키는 효과를 가져옵니다.
FlashAttention은 어떻게 어텐션 효율성을 향상시킵니까?

FlashAttention은 표준 셀프 어텐션 연산을 특히 긴 시퀀스에 대해 훨씬 더 빠르고 적은 메모리를 사용하여 수행하도록 최적화한 알고리즘입니다. 이는 GPU 메모리 계층 구조의 특성을 효율적으로 활용함으로써 가능해집니다.

핵심 원리:
표준 어텐션 구현의 주요 성능 병목 현상은 종종 순수한 계산량 자체가 아니라, 계산 과정에서 생성되는 매우 큰 중간 결과물(특히, (시퀀스 길이)x(시퀀스 길이) 크기의 어텐션 스코어 행렬)을 상대적으로 느린 GPU의 주 메모리(High Bandwidth Memory, HBM)에 쓰고 다시 읽어오는 과정에서 발생합니다.

FlashAttention은 이러한 느린 HBM 접근을 최소화하는 데 초점을 맞춥니다.
1. 타일링 (Tiling): 입력 행렬들(쿼리 Q, 키 K, 밸류 V)을 GPU의 훨씬 빠른 온칩 메모리(SRAM)에 들어갈 수 있는 작은 블록(타일) 단위로 분할합니다.
2. SRAM 내 연산: 각 블록에 대한 어텐션 계산(Q와 K의 행렬 곱셈으로 스코어 계산, 소프트맥스 적용, V와의 가중 합 계산)을 전적으로 빠른 SRAM 내에서 수행합니다. 이를 통해 거대한 중간 어텐션 스코어 행렬 전체를 느린 HBM에 기록할 필요가 없어집니다. (블록 단위 소프트맥스 계산을 위해 수치적으로 안정적인 기법을 사용합니다.)
3. 역방향 전파 최적화: 훈련 시 역방향 전파(그래디언트 계산)를 위해 일반적으로 순방향 계산 시 생성된 큰 어텐션 행렬을 저장해야 하지만, 이는 많은 메모리를 소모합니다. FlashAttention은 이를 저장하는 대신, 역방향 계산에 필요한 부분을 SRAM 내에서 즉석에서 재계산하는 방식을 사용하여, 약간의 추가 계산 비용으로 메모리 사용량을 크게 절약합니다.
결론적으로, FlashAttention은 GPU 메모리 계층 구조에 최적화된 IO-인식(aware) 접근 방식을 통해 HBM 읽기/쓰기를 최소화함으로써, 정확한 어텐션 계산 결과는 유지하면서도 연산 속도를 크게 높이고 메모리 사용량은 줄이는 효과를 달성합니다.
배포를 위해 ONNX 또는 TensorRT를 사용하는 목적은 무엇입니까?

훈련된 딥러닝 모델을 실제 서비스 환경에 배포하여 추론을 수행할 때는, 모델의 실행 속도를 높이고 자원 사용량을 줄이는 최적화 과정이 중요합니다. ONNX와 TensorRT는 이러한 목적을 위해 널리 사용되는 대표적인 도구 및 프레임워크입니다.
- ONNX (Open Neural Network Exchange):
  - 목적: 다양한 딥러닝 프레임워크(PyTorch, TensorFlow 등) 간의 상호 호환성(interoperability)을 제공하는 개방형 표준 모델 포맷입니다.
  - 작동 방식: 특정 프레임워크에서 훈련된 모델을 ONNX 포맷으로 변환하면, 이 포맷을 지원하는 다양한 하드웨어나 추론 엔진(예: ONNX Runtime)에서 모델을 실행할 수 있습니다. 개발 프레임워크와 배포 환경이 달라도 모델을 쉽게 이전하고 실행할 수 있게 해줍니다.
  - 최적화: ONNX Runtime 자체도 모델 그래프 최적화(예: 연산자 융합)나 하드웨어 가속 기능 활용 등의 최적화를 수행하여 추론 성능을 개선합니다.
- TensorRT:
  - 목적: NVIDIA GPU 환경에서 추론 성능을 극대화하기 위해 NVIDIA에서 제공하는 소프트웨어 개발 키트(SDK) 및 런타임 라이브러리입니다.
  - 작동 방식: 다양한 프레임워크(종종 ONNX를 통해 변환된 모델 포함)에서 개발된 모델을 입력받아, NVIDIA GPU 아키텍처에 특화된 매우 공격적인 최적화를 수행합니다.
  - 주요 최적화 기법:
    - 계층 및 텐서 융합: 여러 개의 연산을 하나의 GPU 커널로 통합하여 오버헤드를 줄입니다.
    - 커널 자동 튜닝: 타겟 GPU 하드웨어에서 가장 빠른 성능을 내는 커널 구현을 자동으로 선택합니다.
    - 정밀도 보정: FP16, INT8 등 저정밀도 연산을 사용하도록 모델을 최적화하여 속도를 높입니다.
    - 다중 스트림 실행, 동적 텐서 메모리 관리 등.
  - 결과: 일반적으로 NVIDIA GPU에서 가장 낮은 지연 시간과 가장 높은 처리량을 달성하는 것을 목표로 합니다.
요약하면, ONNX는 다양한 환경 간의 모델 호환성을 위한 표준 역할을 하며, TensorRT는 NVIDIA GPU에서의 최대 성능을 끌어내기 위한 심층적인 최적화 도구라고 볼 수 있습니다. 종종 ONNX로 모델을 변환한 뒤, 이를 TensorRT로 추가 최적화하는 워크플로우가 사용됩니다.
LLM 추론 시 사용되는 정적 배칭과 연속 배칭 기법은 어떻게 다르며, 왜 연속 배칭 방식이 LLM 환경에서 더 우수한 성능을 보이는 경우가 많습니까? 또한, vLLM과 같은 기술이 연속 배칭의 효율적인 구현에 구체적으로 어떻게 기여하는지 설명해 주십시오.

LLM 추론 시 배칭(Batching)은 여러 사용자의 요청을 한 번에 모아 처리함으로써 GPU와 같은 병렬 처리 하드웨어의 효율을 높이는 중요한 기법입니다. 배칭 방식에는 크게 정적 배칭과 연속 배칭이 있습니다.
- 정적(static) 배칭:
  - 방식: 들어오는 요청들을 미리 정해진 크기(개수)의 배치로 묶습니다. GPU는 이 배치 전체에 대한 연산이 모두 완료될 때까지 기다린 후 다음 배치를 처리합니다.
  - 단점: LLM의 응답 길이는 요청마다 매우 가변적입니다. 정적 배칭에서는 배치 내에서 가장 긴 응답 생성이 필요한 요청이 끝날 때까지, 이미 생성이 끝난 다른 짧은 요청들도 함께 기다려야 합니다. 이는 GPU 자원의 낭비(유휴 시간 증가)를 초래하고 사용자의 평균 응답 시간을 늘려 비효율적입니다.
- 연속(continuous) 배칭 또는 동적(dynamic) 배칭:
  - 방식: 고정된 배치를 사용하지 않고, 요청들을 동적으로 관리합니다. GPU에서 처리 중인 요청 그룹 내에서 어떤 요청이라도 응답 생성이 완료되면, 해당 요청이 사용하던 자원을 즉시 해제하고, 그 자리에 대기 중이던 새로운 요청을 바로 투입하여 다음 연산 단계를 수행합니다.
  - 장점: 전체 그룹이 끝날 때까지 기다릴 필요 없이 GPU가 끊임없이 작업을 수행할 수 있습니다. LLM의 가변적인 출력 길이 문제를 효과적으로 해결하여 GPU 활용률을 극대화하고, 평균 지연 시간을 줄이며, 전체 시스템 처리량을 크게 향상시킵니다. 따라서 다양한 길이의 요청이 섞이는 실제 서비스 환경에 훨씬 적합합니다.
vLLM과 PagedAttention의 기여:
연속 배칭의 개념은 효율적이지만, 이를 실제로 구현하는 데는 기술적 난제가 있었습니다. 특히, 트랜스포머 어텐션 연산에 사용되는 KV 캐시의 메모리 관리가 문제였습니다. 요청마다 길이가 다르고 동적으로 요청이 추가/제거되다 보니, 메모리 공간이 잘게 조각나는 단편화(fragmentation) 현상이 심하게 발생하여 메모리를 효율적으로 재사용하기 어려웠습니다.
vLLM 라이브러리는 PagedAttention이라는 혁신적인 기술을 도입하여 이 문제를 해결했습니다.
- PagedAttention: 운영체제의 메모리 페이징(paging) 기법에서 영감을 받아, KV 캐시를 물리적으로 연속될 필요가 없는 작은 고정 크기의 블록(페이지) 단위로 관리합니다.
- 효과: 각 요청은 필요한 만큼의 페이지만 할당받고, 요청이 완료되면 사용했던 페이지를 즉시 반환하여 다른 요청이 재사용할 수 있습니다. 이를 통해 메모리 단편화를 거의 없애고, KV 캐시 메모리 활용률을 90% 이상으로 높여 연속 배칭을 매우 효율적으로 구현할 수 있게 되었습니다.
결과적으로 vLLM과 PagedAttention은 연속 배칭의 이론적 장점을 현실화하여 LLM 추론 서빙 성능을 크게 향상시키는 데 핵심적인 역할을 하고 있습니다.

VIII. 추론, 프롬프팅 및 에이전트

인 컨텍스트 학습 효과는 모델 크기에 따라 어떻게 확장됩니까?

인 컨텍스트 학습(In-Context Learning, ICL)은 LLM이 모델의 가중치를 전혀 변경하지 않고, 오직 프롬프트 내에 제시된 퓨샷 샘플이나 지시사항만 보고 새로운 작업을 수행하거나 특정 방식으로 응답하는 놀라운 능력을 의미합니다.
이 ICL 능력의 효과는 모델의 규모(크기)와 매우 강한 양의 상관관계를 보입니다. 즉, 모델의 파라미터 수, 학습 데이터 양, 사전 훈련에 사용된 계산량이 클수록 ICL 성능이 훨씬 뛰어납니다. 많은 연구에서 효과적인 ICL은 규모의 창발적 속성으로 나타나는 경향을 보입니다. 작은 모델에서는 거의 나타나지 않거나 미미하지만, 모델 크기가 특정 임계점을 넘어서면 성능이 급격하게 향상됩니다.
이는 더 큰 모델일수록 프롬프트 내의 퓨샷 샘플에 암시된 작업의 패턴이나 숨겨진 규칙을 더 잘 파악하고, 이를 동일 프롬프트 내의 새로운 문제에 일반화하여 적용하는 능력이 뛰어나기 때문으로 해석됩니다. 프롬프트에 예시를 더 많이 제공하는 것이 도움이 될 수도 있지만, 근본적인 ICL 능력 자체는 주로 사전 훈련된 모델의 규모에 의해 결정되는 것으로 보입니다.
연쇄적 사고 프롬프팅을 설명해 주십시오. 사고의 트리와 같은 전략은 어떻게 다릅니까?

연쇄적 사고 (Chain-of-Thought, CoT) 프롬프팅은 LLM이 수학 문제 풀이, 논리 추론 등 복잡하고 여러 단계의 사고가 필요한 작업을 더 잘 수행하도록 유도하는 프롬프팅 기법입니다.

작동 방식: 최종적인 답만 바로 요구하는 대신, 문제 해결에 이르는 중간 단계의 생각 또는 추론 과정을 명시적으로 생성하도록 유도합니다. 이는 프롬프트에 단계별 풀이 과정을 보여주는 퓨샷 샘플을 포함시키거나, 단순히 "단계별로 생각해보자(Let's think step by step)"와 같은 지시 문구를 추가하는 방식으로 이루어질 수 있습니다. 모델이 생각의 흐름을 따라가도록 함으로써 복잡한 문제에 대한 정답률을 크게 높일 수 있습니다.

사고의 트리 (Tree-of-Thought, ToT)는 CoT에서 더 나아간 개념으로, 단일한 선형적인, 사고의 연쇄 대신 여러 가능한 추론 경로를 동시에 탐색하는 방식입니다. 마치 나무의 가지처럼 여러 가능성을 고려합니다.

ToT 프레임워크의 일반적인 단계:
1. 문제 분해: 복잡한 문제를 여러 하위 단계나 생각 단위로 나눕니다.
2. 사고 생성: 현재 상태에서 가능한 다음 단계 또는 중간 생각들을 여러 개 생성합니다 (다른 가지 탐색).
3. 상태 평가: 생성된 여러 중간 상태나 추론 경로의 유효성, 가능성, 유망성 등을 평가합니다 (때로는 LLM 자체를 평가자로 사용).
4. 탐색: 너비 우선 탐색(BFS)이나 깊이 우선 탐색(DFS) 같은 알고리즘을 사용하여 이 '사고의 트리'를 탐색하며, 가능성이 낮은 가지는 잘라내거나 막다른 길에 다다르면 되돌아갑니다.
주요 차이점: CoT는 하나의 순차적인 추론 경로를 따르는 반면, ToT는 동시에 여러 가능성을 탐색하고 평가합니다. 따라서 ToT는 탐색, 대안 평가, 또는 자기 수정이 중요한 복잡한 문제 해결에 더 강건한 접근 방식이 될 수 있습니다.
LLM이 복잡한 다단계 추론이 필요한 문제에 대해 프롬프트 엔지니어링 기법(예: CoT)만으로는 근본적인 한계에 부딪히는 이유는 무엇이며, 이러한 한계는 LLM 자체의 어떤 내재적 특성들과 관련이 있습니까?

CoT와 같은 프롬프트 엔지니어링 기법은 LLM의 복잡한 추론 능력을 눈에 띄게 향상시키지만, 다음과 같은 LLM 자체의 내재적 특성으로 인해 근본적인 한계에 부딪힙니다.
1. 표면적 패턴 민감성: LLM은 프롬프트의 단어 선택이나 문장 구조 등 표면적 형태에 매우 민감하게 반응합니다. 의미는 동일하더라도 표현 방식이 조금만 달라져도 결과가 불안정해질 수 있습니다. 이는 모델이 깊은 의미론적 이해보다는 통계적 패턴 학습에 크게 의존하기 때문입니다.
2. 내재된 추론 능력의 한계: 프롬프팅은 모델이 가진 잠재된 추론 능력을 이끌어내는 역할을 할 뿐, 모델이 원래 가지고 있지 않은 새로운 논리적, 수학적, 또는 상식적 추론 능력을 창조하지는 못합니다. CoT 역시 모델의 추론 과정을 단지 명시적으로 보여주는 것이며, 그 과정 자체에 오류가 포함될 수 있습니다. 이는 LLM이 명시적인 기호 조작이나 추론 엔진을 갖춘 것이 아니라, 방대한 텍스트 데이터로부터 암묵적인 지식과 패턴을 학습했기 때문입니다.
3. 환각 경향성: LLM은 학습 데이터의 지식 경계를 벗어나거나 매우 복잡한 추론을 요구받을 때, 사실이 아니거나 논리적으로 맞지 않는 내용을 그럴듯하게 생성(환각)하는 경향이 있습니다. 프롬프팅만으로는 생성된 내용의 사실성이나 논리적 건전성을 완벽하게 보장하기 어렵습니다.
4. 오류 누적 및 수정의 어려움: CoT와 같이 선형적인 단계별 추론 방식에서는 초기 단계의 작은 오류가 후속 단계로 전파되어 최종 결과에 큰 영향을 미칠 수 있습니다. 또한, LLM의 자기회귀적 생성 방식은 한번 잘못된 방향으로 진행된 추론을 중간에 스스로 수정하거나 다른 대안적인 경로를 탐색하기 어렵게 만듭니다 (ToT 등이 이를 보완하려 함).
5. 컨텍스트 길이 제한: 프롬프트에 담을 수 있는 정보의 양(예시, 지시사항)과 CoT 같은 추론 과정의 길이가 물리적으로 제한됩니다. 매우 길고 복잡한 문제는 프롬프트만으로 해결하기 어렵습니다.
결론적으로, 프롬프트 엔지니어링은 LLM의 능력을 최대한 활용하기 위한 강력한 인터페이스이지만, LLM 아키텍처와 학습 방식 자체의 근본적인 한계를 극복할 수는 없습니다. 진정으로 복잡한 추론 능력을 획기적으로 향상시키기 위해서는 프롬프팅 기법의 발전과 더불어 모델 아키텍처, 학습 알고리즘, 데이터 전략 등의 근본적인 개선이 병행되어야 합니다.
프롬프트는 어떻게 계획을 유도할 수 있습니까? 도구 사용을 위한 ReAct와 같은 프레임워크를 설명해 주십시오.

LLM에게 명시적으로 계획을 세우도록 요청하는 프롬프트를 통해 계획 행동을 유도할 수 있습니다. 예를 들어, "이 문제를 해결하기 위한 단계별 계획을 먼저 세우고, 그 다음 계획에 따라 실행하세요." 와 같이 지시할 수 있습니다.

ReAct (Reason + Act) 프레임워크는 LLM이 추론과 행동을 번갈아 수행하며 복잡한 작업을 해결하도록 하는 보다 구조화된 접근 방식입니다. 특히 검색 엔진, 계산기, API 호출 등 외부 도구(tool) 사용이 필요한 작업에 효과적입니다.

ReAct의 작동 방식:
ReAct는 일반적으로 LLM이 다음과 같은 생각-행동-관찰의 순환 고리 안에서 작동하도록 프롬프트를 구성합니다.
1. 사고 (thought): LLM은 현재 주어진 문제 상황, 이전 단계의 결과(관찰), 최종 목표 등을 고려하여 상황을 분석하고, 다음 행동 계획을 세웁니다. (예: "현재 정보가 부족하니, 관련 정보를 검색해야겠다.")
2. 행동 (action): LLM은 계획한 내용을 바탕으로 수행할 구체적인 행동을 결정합니다. 주로 사용할 외부 도구와 해당 도구에 전달할 입력(인수)을 특정 형식으로 지정합니다. (예: Action: Search[검색할 키워드])
3. 관찰 (observation): 외부 시스템(ReAct 실행 환경)이 LLM이 지정한 행동(예: 검색 엔진 API 호출)을 실제로 수행하고, 그 결과(예: 검색 결과 요약)를 얻습니다. 이 결과는 '관찰' 정보로서 다음 번 LLM의 입력 프롬프트에 포함됩니다.
LLM은 이 '사고 → 행동 → 관찰' 주기를 반복하면서, 동적으로 계획을 수정하고, 외부 도구를 활용하여 필요한 정보를 얻거나 계산을 수행하며, 그 결과를 바탕으로 다시 추론합니다. 이를 통해 LLM은 자신의 내부 지식만으로는 해결하기 어려운 복잡한 문제나 최신 정보가 필요한 질문에 효과적으로 답할 수 있게 됩니다.
AutoGen이나 MetaGPT와 같은 AI 에이전트 프레임워크가 LLM을 활용하여 해결하고자 하는 핵심적인 한계점은 무엇이며, 이러한 프레임워크들은 LLM을 단순한 텍스트 생성 도구를 넘어 목표 지향적인 문제 해결 시스템으로 전환시키기 위해 구체적으로 어떤 기능적 구성요소들을 제공하고 있습니까?

AutoGen, MetaGPT와 같은 AI 에이전트 프레임워크는 LLM의 강력한 언어 이해 및 생성 능력을 기반으로 하되, 단순한 질의응답이나 텍스트 생성을 넘어 복잡하고 여러 단계로 이루어진 목표 지향적인 작업을 자율적으로 수행하도록 설계되었습니다. 즉, LLM을 단순한 '도구'에서 스스로 계획하고, 행동하며, 상호작용하고, 협업할 수 있는 '지능형 에이전트'로 발전시키는 것을 목표로 합니다.
이러한 프레임워크들이 해결하고자 하는 LLM의 핵심적인 한계점은 다음과 같습니다.
- 상태 및 기억 관리의 부재: LLM은 제한된 컨텍스트 윈도우 내의 정보만 처리 가능하며, 장기적인 상태나 기억을 유지하기 어렵습니다.
- 외부 세계와의 상호작용 능력 부족: LLM 자체만으로는 외부 도구(API, 데이터베이스, 검색 엔진 등)를 사용하거나 실제 환경과 상호작용할 수 없습니다.
- 복잡한 계획 및 작업 분해 능력 부족: 복잡한 목표를 달성하기 위해 체계적인 계획을 세우고 이를 하위 작업으로 분해하는 능력이 부족합니다.
- 자기 성찰 및 개선 능력 부족: 자신의 결과물이나 계획의 문제점을 스스로 인지하고 수정하는 능력이 제한적입니다.
AI 에이전트 프레임워크는 이러한 한계를 극복하기 위해 LLM을 핵심 엔진으로 사용하면서 다음과 같은 기능적 구성요소들을 제공합니다.
- 계획 수립 및 작업 분해: 사용자의 복잡한 목표를 분석하여 실행 가능한 하위 작업들의 순서나 구조로 이루어진 계획을 생성하고 관리합니다.
- 도구 사용: LLM이 필요에 따라 외부 API, 계산기, 코드 실행기, 검색 엔진 등 다양한 외부 도구를 호출하고 그 결과를 활용할 수 있도록 인터페이스를 제공합니다 (예: ReAct 방식 활용).
- 메모리 관리: 단기 기억(컨텍스트 윈도우)의 한계를 넘어, 작업 수행 중 얻은 정보나 이전 상호작용 기록을 저장하고 필요할 때 검색하여 활용할 수 있는 장기 기억 메커니즘을 제공합니다 (예: 벡터 데이터베이스 활용).
- 다중 에이전트 협업: 각기 다른 역할이나 전문성을 가진 여러 LLM 기반 에이전트들이 서로 대화하고 상호작용하며 공동으로 복잡한 문제를 해결하도록 지원합니다. (예: AutoGen의 대화형 에이전트, MetaGPT의 역할 기반 소프트웨어 개발 프로세스 시뮬레이션).
- 자기 성찰 및 개선: 에이전트가 스스로 생성한 계획, 코드, 문서 등의 중간 결과물을 평가하고 문제점을 파악하여 수정하도록 함으로써 최종 결과물의 품질과 신뢰도를 높입니다.
결론적으로, AI 에이전트 프레임워크는 LLM의 핵심 능력에 계획, 도구 사용, 기억, 협업, 자기 성찰 등의 기능을 결합하여 그 한계를 보완하고, LLM을 단순한 API 호출의 대상을 넘어 복잡하고 실용적인 문제를 해결하는 정교한 시스템으로 발전시키는 것을 목표로 합니다.

IX. 평가 및 벤치마킹

생성 모델 평가의 어려움에 대해 논의하고, 자동화된 지표와 인간 평가를 대조 설명해 주십시오.

생성 모델의 성능을 평가하는 것은 여러 가지 이유로 본질적인 어려움을 내포합니다.
어려움의 원인:
- 주관성 및 개방형 결과: 생성 모델의 결과물(텍스트, 이미지 등)은 정답이 하나로 정해진 분류나 예측 문제와 달리, 그 품질을 판단하는 기준이 주관적일 수 있고 결과물의 형태가 매우 다양합니다. 창의성, 문체, 미적 감각 등은 정량화하기 어렵습니다.
- 다면적 평가 기준: 좋은 생성 결과물은 관련성, 사실 정확성, 논리성, 일관성, 유창성, 안전성, 유용성 등 여러 기준을 동시에 만족해야 하는 경우가 많습니다. 하지만 단일 지표로 이 모든 측면을 포괄적으로 평가하기는 어렵습니다.
평가 방법 비교:
- 자동화된 지표:
  - 예시: 텍스트 생성 평가의 BLEU, ROUGE 점수, 이미지 생성 평가의 FID(Fréchet Inception Distance), IS(Inception Score) 등
  - 작동 방식: 주로 결과물의 표면적 특징(예: 단어 중복률, 픽셀 분포 유사도)을 계산합니다.
  - 장점: 빠르고, 비용이 적게 들며, 대규모 평가가 가능하여 모델 개발 과정에서 반복적인 테스트에 유용합니다.
  - 단점: 생성물의 실제 품질이나 의미론적 정확성, 논리적 오류, 창의성, 유해성 등 깊이 있는 측면을 제대로 반영하지 못하며, 인간의 선호도와 상관관계가 낮은 경우가 많습니다.
- 인간 평가:
  - 작동 방식: 실제 사람이 직접 생성 결과물을 보고 정해진 기준(예: 유창성, 관련성, 창의성, 안전성 등)에 따라 점수를 매기거나 선호도를 비교합니다.
  - 장점: 자동 평가 지표가 놓치는 미묘한 품질 차이, 문맥 이해도, 창의성, 실제 사용자가 느끼는 유용성 및 안전성 등을 평가하는 데 가장 신뢰도 높은 방법입니다.
  - 단점: 시간과 비용이 많이 들고, 노동 집약적입니다. 평가자 간의 주관성, 판단 불일치, 잠재적 편향이 존재할 수 있으며, 평가의 일관성을 유지하기 어렵습니다. 결론적으로, 자동화된 지표로 쉽게 측정 가능한 것과 인간이 실제로 고품질 또는 유용하다고 인식하는 것 사이에는 종종 상당한 간극이 존재합니다. 따라서 생성 모델 평가는 보통 자동화된 지표와 인간 평가를 상호 보완적으로 활용합니다.
LLM의 내재적 사실성(예: TruthfulQA 사용)을 어떻게 체계적으로 평가합니까?

LLM이 사실에 기반한 정보를 생성하는지, 아니면 잘못된 정보를 그럴듯하게 만들어내는지(환각)를 평가하는 것은 LLM의 신뢰도 측면에서 매우 중요하며, 단순 정확도 측정 이상의 체계적인 접근이 필요합니다.
평가 방법 및 벤치마크:
- 특수 목적 벤치마크 활용:
  - TruthfulQA: 일부러 흔한 오해나 잘못된 상식을 정답처럼 보이도록 유도하는 질문들을 포함합니다. 모델이 인터넷 등에서 학습했을 수 있는 잘못된 정보를 단순히 반복하는 대신, 진실된 답변을 생성하는 능력을 평가합니다.
  - HaluEval: 모델이 생성한 환각을 탐지하는 능력을 평가하기 위해, 의도적으로 환각이 포함된 텍스트 데이터셋을 제공합니다.
- 정량적 지표 측정:
  - 사실 기반 질문 정확도: 정답이 명확하게 알려진 사실적 질문에 대해 모델이 얼마나 정확하게 답변하는지 측정합니다.
  - 충실성 평가: RAG(검색 증강 생성) 시스템의 경우, 모델이 생성한 답변이 참조한 외부 문서(컨텍스트)의 내용과 얼마나 일치하는지 평가합니다.
  - 보정 분석: 모델이 답변에 대해 표현하는 자신감(confidence) 수준이 실제 정답률과 얼마나 일치하는지 분석합니다. 자신감과 정확도가 일치하지 않으면 모델의 신뢰도를 판단하기 어렵습니다.
- 다양한 방법론 적용:
  - 지식 탐색: 특정 도메인에 대한 모델의 지식 보유 정도를 평가합니다.
  - 적대적 질문: 모델을 혼동시키거나 잘못된 답변을 유도하도록 설계된 질문을 사용합니다.
  - 외부 지식 검증: 모델이 생성한 주장을 위키피디아와 같은 외부 지식 베이스나 신뢰할 수 있는 데이터베이스와 대조하여 사실 여부를 확인합니다.
  - LLM 심사위원 (LLM-as-a-Judge): 다른 강력한 LLM을 사용하여 모델 답변의 사실성이나 품질을 평가하기도 합니다. (단, 심사위원 LLM의 편향이 개입될 수 있습니다.)
LLM의 사실성을 체계적으로 평가하기 위해서는 이처럼 환각이라는 특정 실패 유형을 겨냥한 다양한 벤치마크와 평가 지표를 사용해야 하며, 종종 자동화된 평가 결과를 세심한 인간의 분석으로 보완하는 것이 필요합니다.
LLM 추론 능력은 어떻게 평가됩니까? 주요 벤치마크를 언급해 주십시오.

LLM의 추론 능력을 평가하는 것은 단순한 정보 검색이나 패턴 암기 능력을 넘어, 논리적 사고, 수학적 문제 해결, 단계적 추론, 상식 이해 등 고차원적인 인지 능력을 측정하는 것을 목표로 합니다. 이를 위해 정답을 맞히기 위해 반드시 추론 과정이 필요한 문제들로 구성된 다양한 벤치마크가 사용됩니다. 주요 벤치마크는 다음과 같습니다.
- MMLU (Massive Multitask Language Understanding): 과학, 기술, 공학, 수학(STEM)부터 인문학, 사회과학까지 총 57개의 다양한 주제를 포괄하는 객관식 질문으로 구성되어, 모델의 광범위한 지식과 문제 해결 능력을 종합적으로 평가합니다.
- GSM8K (Grade School Math 8K): 여러 단계의 산술 연산이 필요한 초등학교 수준의 수학 응용 문제들로 구성되어, 모델의 수학적 추론 및 단계적 문제 해결 능력을 측정합니다. 주로 연쇄적 사고(CoT) 프롬프팅과 함께 평가됩니다.
- BIG-Bench (Beyond the Imitation Game Benchmark): 매우 다양하고 어려운 인지 능력 (까다로운 추론 문제 포함)을 평가하기 위해 설계된 대규모 협업 벤치마크입니다.
- HellaSwag: 주어진 문맥 다음에 이어질 가장 자연스러운 문장을 고르는 객관식 문제를 통해 모델의 상식 추론 능력을 평가합니다.
- ARC (AI2 Reasoning Challenge): 추론이 필요한 까다로운 과학 질문(초등 및 중학교 수준)들로 구성되어 있습니다.
- DROP (Discrete Reasoning Over Paragraphs): 주어진 지문을 읽고 답을 찾아야 하지만, 답을 찾기 위해 덧셈, 개수 세기, 비교 등 추가적인 불연속적 추론 단계가 필요한 독해력 벤치마크입니다.
- MATH: 대수학, 기하학, 정수론 등 고급 수학적 추론 능력이 요구되는 어려운 경시대회 수준의 수학 문제들을 포함합니다.
- HumanEval: 코드 생성 능력을 평가하는 벤치마크로, 정확한 코드를 작성하는 데 필요한 논리적 추론 능력을 간접적으로 측정합니다.
이러한 벤치마크들은 모델이 단순한 정보 암기나 표면적 패턴 매칭을 넘어, 보다 견고하고 복잡한 추론 능력을 갖추도록 개발 방향을 유도하는 데 중요한 역할을 합니다.
프롬프트 정렬(CLIP 점수), 품질/사실성(FID), 다양성 등 텍스트-이미지 모델 평가에 대해 설명해 주십시오.

텍스트 설명(프롬프트)을 입력받아 이미지를 생성하는 텍스트-이미지 모델을 평가할 때는 주로 다음과 같은 세 가지 측면을 종합적으로 고려합니다.
1. 프롬프트 정렬 및 충실성:
  - 의미: 생성된 이미지가 입력된 텍스트 프롬프트의 내용과 의미를 얼마나 충실하게 반영하는지를 나타냅니다. 프롬프트에 묘사된 객체, 속성, 관계, 스타일 등이 이미지에 잘 표현되었는지가 중요합니다.
  - 주요 지표: CLIP 점수가 널리 사용됩니다. CLIP과 같은 비전-언어 모델을 사용하여 입력 텍스트 프롬프트의 임베딩과 생성된 이미지의 임베딩 간의 의미론적 유사도(코사인 유사도 등)를 계산합니다. 점수가 높을수록 일반적으로 프롬프트와의 정렬이 잘 되었다고 간주합니다.
2. 이미지 품질 및 사실성:
  - 의미: 생성된 이미지가 시각적으로 얼마나 자연스럽고 사실적인지, 기술적인 결함은 없는지 등을 평가합니다.
  - 주요 지표: FID가 표준적으로 사용됩니다. 사전 훈련된 Inception 네트워크를 사용하여 생성된 이미지들의 특징 분포와 실제 이미지들의 특징 분포 간의 거리를 측정합니다. FID 점수가 낮을수록 생성된 이미지들이 실제 이미지와 통계적으로 유사하며, 이는 더 높은 품질과 사실성을 의미하는 경향이 있습니다.
3. 다양성:
  - 의미: 모델이 동일하거나 유사한 프롬프트에 대해 다양하고 서로 다른 이미지를 생성하는 능력을 의미합니다. 다양성이 부족하면 모델이 특정 종류의 이미지 만을 반복적으로 생성하는 '모드 붕괴(mode collapse)' 현상을 겪고 있을 수 있습니다.
  - 평가: FID가 간접적으로 다양성을 일부 반영하지만, 완벽하지는 않습니다. 생성된 이미지들 간의 유사도를 측정하거나, 특정 지표를 사용하거나, 인간이 직접 평가하여 다양성을 판단하는 경우가 많습니다.
이처럼 텍스트-이미지 모델 평가는 자동화된 지표(CLIP 점수, FID 등)와 함께, 인간 평가를 통한 정성적인 분석(미적 만족도, 세부 묘사의 정확성, 프롬프트의 미묘한 뉘앙스 반영 여부 등)을 병행하여 종합적으로 이루어지는 것이 일반적입니다.
멀티모달 모델은 어떻게 평가합니까? 특별한 어려움은 무엇입니까?

텍스트, 이미지, 오디오 등 여러 유형의 정보를 동시에 처리하는 멀티모달 모델을 평가하는 것은 각 모달리티를 개별적으로 평가하는 것을 넘어, 모달리티 간의 상호 작용을 이해하고 이를 바탕으로 추론하는 능력까지 측정해야 하므로 더 복잡합니다.
평가 방법:
- 작업별 벤치마크 활용: 멀티모달 능력을 요구하는 특정 작업에 대한 성능을 측정하는 것이 일반적입니다.
  - 시각 질의응답 (Visual Question Answering, VQA): 이미지와 관련된 질문에 답하는 능력 평가 (예: VQAv2, GQA 데이터셋).
  - 이미지 캡셔닝: 주어진 이미지에 대한 자연어 설명을 생성하는 능력 평가 (예: COCO Captions 데이터셋, BLEU, CIDEr, SPICE 등 지표 사용).
  - 텍스트-이미지 검색: 텍스트 설명에 해당하는 이미지를 찾거나, 이미지에 해당하는 텍스트 설명을 찾는 능력 평가 (예: Flickr30k, COCO 데이터셋, Recall@K 지표 사용).
  - 이 외에도 비디오 이해, 오디오-시각 연관 등 다양한 멀티모달 벤치마크가 있습니다.
주요 어려움:
- 진정한 크로스 모달 추론 검증: 모델이 실제로 여러 모달리티 정보를 통합하여 추론하는지, 아니면 단일 모달리티 내의 편향이나 지름길에 의존하여 정답을 맞히는지 구분하기 어렵습니다.
- 크로스 모달 일관성 평가: 예를 들어, 모델이 이미지와 그에 대한 설명을 함께 생성했을 때, 생성된 텍스트가 생성된 이미지를 정확하고 일관성 있게 묘사하는지 자동으로 평가하기 어렵습니다.
- 추론 과정 평가의 부재: 최종 결과물의 정답 여부뿐만 아니라, 모델이 결론에 도달하기까지의 크로스 모달 추론 과정 자체가 타당한지 평가하는 표준화된 방법론이 부족합니다.
- 데이터 부족: 복잡한 멀티모달 추론 능력을 평가하기 위한 대규모 고품질 벤치마크 데이터가 아직 부족한 경우가 많습니다.
- 주관성 및 인간 평가 의존: 생성된 멀티모달 콘텐츠의 품질, 관련성, 창의성 등을 판단하는 데에는 본질적인 주관성이 개입될 수밖에 없어, 신뢰도 높은 평가를 위해 세심하게 설계된 인간 평가가 필수적인 경우가 많습니다.
생성 모델 벤치마크의 알려진 한계나 '게임화' 문제는 무엇입니까?

벤치마크는 생성 모델 연구의 진척 상황을 측정하고 모델 간 성능을 비교하는 데 필수적인 도구이지만, 다음과 같은 잘 알려진 한계점과 문제점(소위 '게임화' 또는 '벤치마크 해킹')을 가지고 있습니다.
- 데이터 오염: 평가에 사용되어야 할 테스트셋 데이터가 의도치 않게 모델의 사전 훈련 데이터에 포함되는 경우입니다. 이 경우 모델은 단순히 정답을 '암기'하여 비정상적으로 높은 점수를 받게 되며, 공정한 성능 비교가 불가능해집니다. 대규모 웹 스크레이핑 데이터 사용 시 발생하기 쉽습니다.
- 벤치마크 과적합: 모델이 벤치마크 자체의 특정 형식, 문제 유형, 데이터 분포에 과도하게 최적화되는 현상입니다. 이 경우 벤치마크 점수는 높지만, 실제 세상의 다양하고 새로운 문제에 대한 일반적인 능력은 향상되지 않았을 수 있습니다.
- 지표와 실제 성능 간의 괴리: 앞서 언급했듯이, BLEU, FID 등 자동화된 평가 지표 점수가 높다고 해서 반드시 인간이 느끼는 품질, 유용성, 창의성, 안전성 등이 높은 것은 아닙니다.
- 평가 설정 민감성: 모델 성능은 어떤 프롬프트를 사용했는지, 어떤 샘플링 파라미터를 적용했는지 등 평가 설정에 따라 크게 달라질 수 있습니다. 평가 조건이 표준화되지 않거나 명확히 보고되지 않으면 모델 간의 직접적인 비교가 어렵습니다.
- 벤치마크의 정체성 및 노후화: 대부분의 벤치마크는 한번 구축되면 잘 변하지 않습니다. 시간이 지나 모델 성능이 향상되면 벤치마크 문제들이 너무 쉬워져('해결(solved)'됨) 더 이상 최신 모델들의 성능 차이를 변별하지 못하게 될 수 있습니다.
- 평가자 편향: 인간 평가나 LLM을 심사위원으로 사용하는 평가 방식은 평가자의 주관성, 선입견, 일관성 부족 등의 문제로부터 자유롭기 어렵습니다.
이러한 한계들 때문에 벤치마크 점수는 항상 비판적인 시각으로 해석해야 하며, 가능하면 정성적 분석, 추가적인 인간 평가, 실제 응용 환경에서의 테스트 결과 등으로 보완하여 모델의 성능을 종합적으로 판단하는 것이 중요합니다.
트랜스포머 행동을 해석하는 기법(예: 어텐션 시각화, 특징 기여도)은 무엇입니까?

트랜스포머 모델이 특정 예측이나 출력을 생성하는 이유, 즉 모델의 내부 작동 방식을 이해하는 것은 디버깅, 신뢰도 구축, 성능 개선, 안전성 확보 등에 매우 중요합니다. 이를 위해 다음과 같은 다양한 해석 기법들이 사용됩니다.
- 어텐션 시각화:
  - 방식: 모델의 어텐션 계층에서 계산된 어텐션 가중치를 시각화하여, 특정 토큰이 예측을 생성할 때 입력 시퀀스의 어떤 다른 토큰들에 더 많은 '주의'를 기울였는지 살펴보는 방법입니다.
  - 한계: 어텐션 가중치가 높은 것이 항상 해당 토큰의 중요도가 높다는 것을 의미하지는 않을 수 있다는 연구 결과도 있습니다.
- 특징 기여도 / 중요도 분석 (Feature Attribution / Saliency):
  - 방식: 각 입력 특징(예: 특정 단어 토큰)이 모델의 최종 출력(예: 특정 예측 확률)에 얼마나 기여했는지 또는 얼마나 중요했는지를 정량적으로 측정하는 것을 목표로 합니다.
  - 기법 예시: 입력에 대한 출력의 그래디언트를 활용하는 그래디언트 기반 방법(예: Integrated Gradients), 입력의 일부를 변경했을 때 출력이 얼마나 변하는지 관찰하는 섭동 기반 방법(예: LIME) 등이 있습니다.
- 내부 활성화 탐색:
  - 방식: 모델 내부의 특정 뉴런이나 계층의 활성화 패턴을 분석하여, 이들이 특정 언어적 속성(예: 품사, 구문 구조), 개념, 또는 작업 관련 특징과 상관관계가 있는지 조사합니다.
  - 최신 동향: 희소 오토인코더(Sparse AutoEncoders, SAEs)를 사용하여 고차원 활성화 벡터 내에서 해석 가능한 소수의 핵심 특징을 추출하려는 연구가 활발히 진행 중입니다.
- 기계적 해석 가능성:
  - 방식: 모델의 가중치와 개별 구성 요소(어텐션 헤드, MLP 계층 등)가 상호작용하는 방식을 면밀히 분석하여, 모델이 특정 작업을 수행하기 위해 학습한 실제 알고리즘이나 '회로(circuit)'를 역공학(reverse-engineer)하려는 매우 야심 찬 접근 방식입니다.
- 절제 연구 (Ablation Studies):
  - 방식: 모델의 일부 구성 요소(예: 특정 어텐션 헤드, 특정 계층)를 체계적으로 제거하거나 비활성화한 후, 모델의 성능 변화를 관찰하여 해당 구성 요소의 기능이나 중요도를 파악하는 방법입니다.
이러한 해석 기법들은 각각 장단점을 가지므로, 단일 방법에 의존하기보다는 여러 기법을 조합하여 사용하는 것이 모델의 행동에 대한 더 깊고 포괄적인 통찰력을 얻는 데 도움이 됩니다.

부록: 추천 학습 자료

트랜스포머 기본
고급 LLM 아키텍처 및 개념
- A Visual Guide to Mixture of Experts(MoE) (한국어)
- Mixture of Experts Explained
고급 훈련 및 파인튜닝 기법
멀티모달 모델
- Multimodality and Large Multimodal Models (LMMs)
- Understanding Multimodal LLMs
이미지 생성 및 확산 모델
- The Illustrated Stable Diffusion (한국어)
- What are Diffusion Models?
파운데이션 모델 엔지니어링 및 인프라
- A Visual Guide to Quantization (한국어)
추론, 프롬프팅 및 에이전트

All About Graph RAG

Jonas Kim — Mon, 21 Apr 2025 04:10:19 +0000

Systematically explore the prerequisites, theory, and implementation details of Graph RAG.

1. Graph RAG Definition and Advantages

Graph RAG is an innovative approach that enhances the response quality of Large Language Models (LLMs) by combining existing Retrieval-Augmented Generation (RAG) techniques with knowledge graphs. While traditional RAG relies on document retrieval based on vector embeddings, Graph RAG utilizes the structural information of knowledge graphs composed of entities (nodes) and relationships (edges). This allows LLMs to go beyond simple keyword matching or vector similarity, understanding complex connections and context between concepts to generate responses based on more accurate and richer information. Graph-based knowledge networks are particularly effective for complex queries requiring multi-step reasoning.

Limitations of Traditional RAG

According to Microsoft Research's study "GraphRAG: Unlocking LLM Discovery on Narrative Private Data", existing RAG approaches have the following significant limitations:

Difficulty Connecting Information: Traditional RAG struggles in situations requiring the logical connection of distributed information chunks to derive new, integrated insights. This limitation is particularly prominent when needing to integrate shared properties or relationships across multiple documents.
Lack of Comprehensive Understanding of Large-Scale Information: Traditional RAG's performance degrades when tasked with holistically grasping and summarizing semantic concepts across large data collections or large documents.

These limitations spurred the emergence of Graph RAG, with research progressing towards effectively solving these problems using graph structures.

Key Advantages of Graph RAG

Sophisticated Retrieval Capabilities: Effectively finds relevant factual information from vast knowledge repositories through graph traversal, supporting LLMs in generating detailed and accurate responses.
Provides Contextual Relationships: Relationships in knowledge graphs offer valuable contextual information difficult to grasp from individual document chunks alone, enabling LLMs to generate responses considering a broader knowledge background.
Accurate Understanding of Query Intent: By modeling entities and relationships on the graph as a single semantic unit, it captures user query intent more accurately than simple keyword matching. This particularly enhances contextual accuracy for complex queries.
Enhanced Explainability: Following the links in the graph allows easy tracing of the source of facts used by the model, clearly explaining the basis for the response. This significantly increases the reliability and transparency of the results.
Rich and Comprehensive Responses: Graphs explicitly represent concepts and their complex connections, providing LLMs with more structured knowledge, enabling the generation of more comprehensive and in-depth answers.
Efficient Knowledge Scalability: It is relatively easy to expand knowledge by adding new information to the graph, making it more cost-effective to extend domain knowledge compared to increasing the parameters of the LLM itself.
Supports Multi-step Reasoning: The graph structure helps form complex reasoning chains, allowing more accurate responses to complex questions requiring step-by-step thinking.

2. Overview of Knowledge Graphs and Graph Databases (Graph DB)

To fully leverage Graph RAG, an understanding of its underlying components, knowledge graphs and graph databases, is essential.

2.1. What is a Knowledge Graph?

A knowledge graph is a data model that represents real-world entities (people, places, concepts, etc.) and their relationships in a graph structure. In this structure:

Nodes: Represent entities (e.g., person, city, product, concept)
Edges: Connect entities via relationships (e.g., 'lives in', 'founded', 'includes')
Properties: Additional information assigned to nodes and edges (e.g., name, date, weight)

This graph structure represents vast knowledge in the form of a semantic network, enabling systems to "understand" and reason about meaningful relationships between data. Consequently, knowledge graphs are used by AI models to recognize patterns from connected data and infer new associations, significantly improving performance in tasks like search, recommendation, and question answering.

2.2. Graph Databases

To effectively utilize knowledge graphs, a graph database (Graph DB) capable of storing and querying graph data is needed. A Graph DB stores and manages graph data composed of nodes and edges and is specifically designed as a DBMS to efficiently handle relationship-centric queries.

Key features of graph databases include:

Relationship-Centric Data Model: Relationships between data are treated as first-class citizens, stored and queried directly.
Flexible Schema: New node types or relationships can be easily added as needed, allowing rapid adaptation to changing requirements.
Efficient Graph Traversal: Optimized structure for quickly traversing connected data, efficiently handling complex relationship-based queries.
Intuitive Data Modeling: Naturally represents real-world relationships, enabling the construction of data models easily understood even by domain experts.
Index-free Adjacency: Many graph databases store connections between nodes as physical pointers, optimizing relationship lookup performance.

Relational DB (RDB) vs. Graph DB Comparison

Characteristic	Relational Database (RDB)	Knowledge Graph (using Graph DB)
Data Storage Method	Structured table format	Composed of entities (nodes) and relationships (edges)
Schema	Formalized, fixed schema	Flexible schema structure
Data Manipulation	Manipulation via SQL	Use of graph query languages (Cypher, SPARQL, etc.)
Relationship Representation	Indirect representation via foreign keys	Direct representation as relationships
Complex Relationship Handling	Requires multiple joins (performance degradation)	Intuitive relationship traversal (excellent performance)
Pattern Discovery	Limited	Easy discovery of hidden connections and patterns
Data Integration	Schema changes difficult	Easy integration of data from various sources

2.3. Types of Graph Models

Two main models are primarily used in graph databases.

Property Graph Model

Allows assigning properties directly to nodes and edges.
Classifies nodes and edges using labels.
Offers simplicity and intuitiveness within a single knowledge source.
Neo4j is a representative implementation, primarily using query languages like OpenCypher or Gremlin.

RDF (Resource Description Framework) Model

Uses standardized identifiers via URIs.
Represents data in a triple structure (subject-predicate-object).
Based on W3C standards, supporting integration and standardization across multiple knowledge sources.
Primarily uses the SPARQL query language.

2.4. Comparison of Graph Query Languages

Various query languages are used in graph databases depending on the type of graph stored.

Cypher

A query language for the property graph model, primarily used in Neo4j.
Features intuitive visual pattern matching syntax.
Nodes are represented by parentheses (), relationships by arrows --> or directed arrows -[]->.

Example: Query to find the names of all people living in Seoul

MATCH (p:Person)-[:LIVES_IN]->(c:City)
WHERE c.name = "Seoul"
RETURN p.name

SPARQL

A W3C standard query language for the RDF graph model.
Uses triple pattern-based queries and clearly identifies resources via URIs.
Enables integrated queries across multiple datasets.

Example: Representing the same query as above in SPARQL

SELECT ?person
WHERE {
  ?person rdf:type ex:Person .
  ?person ex:livesIn ex:Seoul .
}

Gremlin

Part of the Apache TinkerPop framework, an imperative graph traversal language for the property graph model.
Supported by various graph databases.
Traverses the graph using a functional-style chain of calls.

Example: Representing the same query as above in Gremlin

g.V().hasLabel('Person').
  out('LIVES_IN').
  has('name', 'Seoul').
  in('LIVES_IN').
  values('name')

2.5 Comparison of Graph DBs Available on AWS

Feature	Neo4j	Amazon Neptune
Provider	AWS Marketplace	AWS Managed Service
Supported Data Model	Property Graph	Property Graph, RDF
Supported Query Lang	Cypher	Gremlin, SPARQL, OpenCypher
Management & Ops	User Managed	Fully Managed
Integration w/ LangChain	Supported	Supported (Cypher, SPARQL)
Integration w/ LlamaIndex	Supported	Supported

3. Graph RAG Design Patterns

Graph RAG is an approach that integrates knowledge graphs into the RAG pipeline, and standardized implementation methods are still evolving. Let's examine key design patterns based on the analysis by Ben Lorica and Prashanth Rao.

3.1. General Design Patterns

Knowledge Graph and Semantic Clustering

This pattern uses knowledge graphs and graph machine learning to retrieve information for a user query and organizes it into semantic clusters.

How it works
1. User submits a query.
2. System retrieves relevant information using knowledge graphs and graph machine learning.
3. Retrieved information is organized into semantic clusters via graph-based clustering.
4. Clustered information enriches the LLM's context, aiding more accurate answer generation.
5. The final answer includes references to the knowledge graph.
Use Cases: Data analysis, knowledge discovery, research fields.

Knowledge Graph and Vector Database Integration

This approach utilizes both knowledge graphs and vector databases to gather relevant information.

How it works
1. The knowledge graph captures relationships between vectorized document chunks (including document hierarchy).
2. The knowledge graph provides structured entity information neighboring the chunks retrieved from vector search, enriching the prompt.
3. The enhanced prompt is input to the LLM to generate a response.
4. The generated answer is returned to the user.
Use Cases: Customer support, semantic search, personalized recommendation systems.

Graph-Enhanced Hybrid Search

This architecture employs a hybrid approach combining vector search, keyword search, and graph-specific queries.

How it works
1. User submits a query.
2. A hybrid search process proceeds, integrating results from unstructured data retrieval and graph data retrieval.
3. Vector and keyword index search results can be enhanced using reranking or rank fusion techniques.
4. Results from all three search types are combined to generate context for the LLM.
5. The response generated by the LLM is delivered to the user.
Use Cases: Enterprise search, document retrieval, knowledge discovery.

Knowledge Graph-Enhanced Q&A Pipeline

This architecture utilizes the knowledge graph in a post-vector search step to enhance the response with additional facts.

How it works
1. User provides a query.
2. Query embedding is calculated.
3. Vector similarity search in the vector index identifies relevant entities in the knowledge graph.
4. Relevant nodes and properties are retrieved from the graph database, and if found, Cypher queries are executed to retrieve additional information.
5. Retrieved information is synthesized to form comprehensive context, which is passed to the LLM to generate a response.
Use Cases: Environments like healthcare or legal where standard information based on entities within the response must be included with the answer.

Knowledge Graph-Based Query Expansion and Generation

This architecture utilizes the knowledge graph before vector search to explore relevant nodes and edges, enriching the LLM's context.

How it works
1. The first step is query expansion, where the user query is processed by an LLM to extract key entities and relationships.
2. Vector search is performed on node properties within the knowledge graph to identify relevant nodes.
3. The next step is query rewriting, generating Cypher queries for the retrieved subgraph to narrow down relevant structured information from the graph.
4. Graph traversal results are used to enrich the LLM's context window.
5. The LLM generates a response based on the enhanced context.
Use Cases: Product lookups or financial report generation where relationships between entities are crucial.

3.2. RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval (Stanford Univ, 2024)

RAPTOR is a special RAG technique developed at Stanford University that utilizes a tree-structured hierarchical index to effectively process long documents. While traditional RAG divides documents into small chunks and retrieves them independently, RAPTOR builds a hierarchical summary tree that preserves the overall structure and context of the document.

Indexing Process

Chunk Splitting
- The original document is split into small chunks of about 100 tokens.
- If a sentence exceeds the token limit, it moves to the next chunk instead of being cut mid-sentence to maintain semantic consistency.
Embedding and Clustering:
- Each chunk is embedded into a vector using SBERT (a BERT-based encoder).
- Semantically similar chunks are clustered using a Gaussian Mixture Model (GMM).
- Soft clustering allows a single node to belong to multiple clusters.
Summary Node Creation
- Chunks in each cluster are summarized using a language model (e.g., GPT-3.5-turbo).
- The summary text becomes a new node and is embedded into a vector again.
Recursive Process
- The embedding-clustering-summarization process is repeated until no further clustering is possible, forming a multi-layered tree structure.
- This process has linear computational complexity with respect to the document size.

Retrieval Process

RAPTOR offers two distinct retrieval strategies.

Tree Traversal Method
1. Starting from the root layer, calculate cosine similarity between the query embedding and all node embeddings in that layer.
2. Select the top k nodes with the highest similarity scores (set S1).
3. Proceed to the child nodes of the elements in set S1 and calculate cosine similarity with the query vector.
4. Select the top k child nodes with the highest similarity scores (set S2).
5. Repeat this process for d layers, generating sets S1 through Sd.
6. Concatenate all sets to form the context relevant to the query.

This method considers only the top k nodes per layer, maintaining a uniform amount of information at each level.

Collapsed Tree Method
1. Collapse the entire RAPTOR tree into a single layer.
2. Calculate cosine similarity between the query embedding and all node embeddings in the collapsed set.
3. Starting with the node having the highest similarity score, add nodes to the result set until a predefined maximum token count is reached.

Experimental results showed that the collapsed tree method consistently performed better than the tree traversal method. This is because the collapsed tree method considers all nodes simultaneously, providing flexibility to retrieve the appropriate level of detail for the question.

3.3. From Local to Global: A Graph RAG Approach to Query-Focused Summarization (Microsoft Research, 2024)

Microsoft Research's GraphRAG is designed to effectively answer comprehensive questions about an entire dataset, such as "What are the main themes in this dataset?", going beyond the limitations of traditional RAG which focuses on finding fragmented information relevant to a specific query.

Indexing Process

Document Chunking
- Source documents are chunked into analyzable sizes.
- Each chunk is processed independently and used later for graph construction.
Entity and Relationship Extraction
- LLMs are utilized to identify important entities (people, places, organizations, concepts, etc.) from each chunk.
- Meaningful relationships between entities are extracted, and short descriptions are generated.
- Domain-specific prompts are used to capture highly relevant entities and relationships.
Knowledge Graph Construction
- Extracted entities and relationships are transformed into nodes and edges, forming the graph.
- Entity descriptions are aggregated and summarized, then attached to each node and edge.
- Duplicate relationships are represented as edge weights, indicating the strength of the relationship.
Community Detection and Summarization
- Community detection algorithms like the Leiden algorithm partition the graph into meaningful communities.
- Performed hierarchically to form community structures at various levels of abstraction.
- An LLM is used to generate a report-like summary for each community.
- Summaries of lower-level communities are utilized in generating summaries for higher-level communities.

Retrieval Process

GraphRAG offers multiple retrieval modes, each optimized for different types of queries.

Static Global Search

A method for queries requiring a comprehensive understanding of the entire dataset.

Utilizing Predefined Community Levels
- Retrieves all community reports at a specific level of the knowledge graph (e.g., level 1).
- This method is simple but consumes many tokens and includes all reports, even those irrelevant to the query.
Map-Reduce Process
1. Map Step: Generate an answer and relevance score for the query against each community report.
2. Reduce Step: Integrate the answers based on relevance scores to generate the final response.

Dynamic Global Search

An approach improving the inefficiency of static global search.

Dynamic Community Selection Process
- Starting from the root of the knowledge graph, evaluate the relevance of each community report using an LLM.
- Reports with low relevance and their child nodes are excluded from the search process.
- For highly relevant reports, move to child nodes and continue evaluation.

DRIFT(Dynamic Reasoning and Inference with Flexible Traversal) Search

DRIFT search is a hybrid approach designed to overcome the limitations of local search within the GraphRAG environment. It goes beyond traditional local search, which merely retrieves text chunks similar to the query, by utilizing community information to provide richer and more comprehensive answers.

Primer Stage: Grasping High-Level Context
- Query Expansion: The user query is expanded using the HyDE (Hypothetical Document Embeddings) technique to increase search recall. HyDE generates a hypothetical ideal document from the original query and then uses the embedding of that document for retrieval.
- Community Report Retrieval: The expanded query is embedded and compared against all community reports to select the top K semantically most relevant reports. These reports, sourced from GraphRAG's global index, provide a high-level overview of the dataset.
- Initial Answer Generation: The selected community reports are provided to an LLM to generate an initial answer.
- Follow-up Question Generation: Simultaneously, the LLM generates more detailed follow-up questions based on the original query. These questions target areas missing information or requiring deeper exploration in the initial answer.
Follow-Up Stage: Exploring Detailed Information
- Execute Local Search: A standard local search variant is executed for each follow-up question. This process finds the most relevant content at the original text chunk level.
- Intermediate Answer Generation: Intermediate answers are generated based on the local search results for each follow-up question.
- Iterative Refinement: New follow-up questions can be generated from these intermediate answers, forming an iterative loop of information exploration. Typically, the system terminates after 2 iterations.
Output Hierarchy Stage: Integrating Results
- Hierarchical Structuring: All questions and answers are organized into a hierarchy ranked by relevance to the original query.
- Map-Reduce Integration: Benchmark tests used a simple map-reduce approach to aggregate all intermediate answers with equal weighting.
- Final Response Generation: A final response to the user's original query is generated based on the aggregated information.

The advantage of this approach is its ability to start with a high-level overview and progressively explore details, potentially capturing important information missed by a single search process.

Auto-Tuning

One of GraphRAG's strengths is its auto-tuning capability for rapid adaptation to new domains:

Domain and Persona Identification
- A sample of the source content (about 1% of the total data) is sent to an LLM.
- The LLM identifies the domain and generates an appropriate persona.
- This persona is used to tailor the extraction process.
Domain-Specific Prompt Generation
- Once the domain and persona are established, multiple processes run in parallel to generate custom indexing prompts.
- Example-based prompts are generated based on actual domain data.
- Identifies domain-specific entities (e.g., 'molecule', 'reaction' in chemistry) beyond basic entity types (person, organization, location, etc.).

Microsoft's GraphRAG demonstrates superior performance in terms of comprehensiveness and diversity compared to traditional summarization techniques, significantly improving response quality for global questions, especially on large datasets. This approach automatically balances local details and global context, providing a flexible and effective solution applicable to various use cases.

4. AWS GraphRAG Toolkit

The AWS GraphRAG Toolkit is a Python-based open-source framework that facilitates the implementation of Graph RAG concepts within the AWS cloud environment. It leverages the LlamaIndex library to automatically build graphs and perform vector indexing from unstructured text, supporting graph-based retrieval for LLM queries.

4.1. Graph Model Design

The AWS GraphRAG Toolkit uses a lexical graph model composed of three layers.

1. Lineage Layer

Source Node
- Stores metadata of the original document (author, URL, publication date, etc.).
- Plays a crucial role in tracing and verifying document provenance.
Chunk Node
- Stores the actual text content and the embedding of that text.
- Maintains the structural context of the original document through relationships with previous/next, parent/child chunks.

The Lineage Layer preserves the original structure and provenance of documents, enabling the tracing of information lineage. This offers significant value, especially in enterprise environments where information reliability and verification are critical.

2. Entity-Relationship Layer

This layer forms the core structure of the graph by representing key entities within documents and their relationships.

Entity Node
- Includes a value (e.g., 'Amazon') and classification (e.g., 'Company').
- Serves as an entry point for keyword-based searches.
- Represents real-world entities like people, places, organizations.
Relation Edge
- Defines relationships between entities (e.g., 'WORKS_FOR', 'LOCATED_IN').
- Guided by a preferred entity classification list to maintain consistency.

The Entity-Relationship Layer represents the main entities found within documents and the relationships between them. It forms the core structure of the graph and serves as an important starting point, particularly for keyword-based 'bottom-up' searches.

3. Summarization Layer

Topic Node
- Represents a topic or theme within a specific source document.
- Acts as a local connection point linking related chunks within a single source.
- Groups the same topic across multiple chunks, providing a document-level summary.
Statement Node
- An independent assertion or statement unit, serving as the primary context unit provided during LLM query responses.
- Grouped under Topic nodes, with order maintained by a linked list.
- Connected to Fact nodes, forming semantic relationships.
- The basic context unit provided to the LLM during question answering.
Fact Node
- A single fact unit in Subject-Predicate-Object (SPO) or Subject-Predicate-Complement (SPC) form.
- Represents the same fact mentioned across multiple documents as a single node, providing global connectivity between documents.
- Forms a relationship (SUPPORTS) supporting Statement nodes.
- Acts as a bridge connecting information across documents.

The Summarization Layer structures the original text into various levels of abstraction, allowing the provision of information at the most appropriate level for a query. 'Topics' provide local connectivity within documents, while 'Facts' offer global connectivity across documents, forming a robust retrieval foundation.

4.2. Indexing Process

The indexing in the AWS GraphRAG Toolkit consists of two main steps.

1. Extraction Step (Extract)

Document Chunking (Optional)
- Uses LlamaIndex SentenceSplitter or similar to divide documents into chunks of a certain size.
- Default settings are 256 tokens per chunk with 20 tokens overlap, but customizable.
- Splitting is done at the sentence level to maintain semantic coherence.
Proposition Extraction (Optional)
- An LLM transforms the content of each chunk into simplified propositions.
- Complex sentences are broken down into simpler ones, and pronouns are replaced with specific names.
- Abbreviations are expanded where possible to improve the quality of subsequent extraction tasks.
- Extracted propositions are stored under the aws::graph::propositions metadata key.
Entity/Relationship/Topic/Statement/Fact Extraction (Required)
- An LLM analyzes the propositions (or source chunks) from the previous step.
- Extracts entities and their classifications, and identifies relationships between entities.
- Groups content into topic units based on the text's theme.
- Extracts statements with independent meaning and facts in triple form.
- All extracted information is stored under the aws::graph::topics metadata key.

The Extraction step is the core process of converting unstructured text into structured graph elements. Proposition extraction using an LLM enhances information quality but can be applied selectively considering performance and cost.

2. Build Step (Build)

Node Transformation
- Transforms metadata generated in the extraction step into Source, Chunk, Topic, Statement, and Fact nodes.
- Each node includes aws::graph::index metadata used for vector indexing.
Graph Construction
- Stores the transformed nodes and relationships in the graph database.
- Establishes relationships between nodes (SUPPORTS, NEXT, etc.) to complete the graph structure.
Vector Indexing
- Generates embeddings for Chunk and Statement nodes and indexes them in the vector store.
- Optionally, Facts and Topics can also be embedded to support various levels of retrieval.

The Build step involves storing the extracted information into the actual graph and vector stores. This process completes the searchable knowledge graph.

3. Continuous Loading and Batch Processing

Continuous Loading
- Executes extraction and building simultaneously using the extract_and_build() method.
- Graph building starts immediately after extraction begins via micro-batch processing, making it usable instantly.
- Suitable for scenarios requiring real-time updates.
Separate Execution
- Executes extract() and build() separately to decouple processing.
- Intermediate results can be stored and reused using S3BasedDocs or FileBasedDocs.
- Useful for large datasets or utilization across different environments (dev/test/prod).
Checkpoint Management
- Manages processing status with a Checkpoint instance to prevent redundant processing.
- Skips successfully processed chunks upon restart after failure, increasing efficiency.
- Marks only chunks whose graph building is complete as checkpoints to maintain consistency.
Batch Processing Optimization
- Optimizes large-scale data processing through batch settings (batch_config).
- Can integrate with Amazon Bedrock batch inference to reduce LLM call costs.
- Optimizes performance by adjusting the number of workers for parallel processing and batch size.

The indexing process can be flexibly configured, allowing adjustment for various scales and requirements. Checkpoints and batch processing play crucial roles in efficiently handling large datasets.

4.3. Retrieval Process

The AWS GraphRAG Toolkit provides two main retrievers to address diverse search needs.

1. TraversalBasedRetriever

TraversalBasedRetriever uses graph traversal for retrieval, employing two complementary strategies.

Chunk-based Search: Top-down Approach
- Identifies chunks highly relevant to the query using vector similarity.
- Moves from found chunks to topics, then expands to related statements and facts.
- Focuses on areas with direct semantic similarity to the query, providing in-depth information.
- Adjusts the quantity and diversity of results with configurable vss_top_k and vss_diversity_factor parameters.
Entity-based Search: Bottom-up Approach
- Extracts keywords (entity names, abbreviations, synonyms, etc.) from the query.
- Identifies relevant entities in the graph using extracted keywords, potentially including expanded entities.
- Starts from entities, expands through facts to statements and topics.
- Limits the number of keywords extracted with the max_keywords parameter to maintain relevance.
Statement Reranking
- Reranks statements before returning final results to enhance relevance to the query.
- Can choose between TF-IDF (tfidf) or model-based (model) methods.
- Limits the number of statements returned with the max_statements parameter to control context size.
Complex Query Decomposition
- Can decompose complex queries into multiple sub-queries using the derive_subqueries option.
- Limits the maximum number of sub-queries generated with the max_subqueries parameter.
- Integrates search results for each sub-query to generate a more comprehensive response.

TraversalBasedRetriever, through structural exploration of the graph, can discover related information via relationships, not just direct semantic similarity, enabling comprehensive answers to complex queries.

2. SemanticGuidedRetriever

SemanticGuidedRetriever is a hybrid approach integrating vector search and graph traversal, utilizing three sub-retrievers.

StatementCosineSimilaritySearch
- Calculates cosine similarity between statement embeddings and the query embedding.
- Returns the specified number (top_k parameter) of most similar statements.
- A direct search method based on semantic similarity, effective for finding precise information related to the query.
KeywordRankingSearch
- Performs search using keywords and synonyms extracted from the query.
- Ranks statements based on the number of keyword matches within them; more matches yield higher ranks.
- Limits the number of keywords extracted (max_keywords) and the number of results returned (top_k).
- Useful for finding relevant information through direct keyword matching.
SemanticBeamGraphSearch
- Performs graph exploration using the beam search algorithm.
- Explores neighboring statements based on shared entities between statements.
- Calculates cosine similarity between candidate statements and the query to follow the most promising paths.
- Limits search depth (max_depth) and the number of candidates kept at each step (beam_width).
- Can discover related information through relationships even with low direct similarity.
RerankingBeamGraphSearch
- A variation of SemanticBeamGraphSearch that uses a reranking model instead of cosine similarity.
- Can utilize BGEReranker (GPU environment) or SentenceReranker (CPU environment).
- Performs more accurate beam search through more sophisticated relevance assessment.
- Computationally more expensive but can provide more accurate results.
Post-processing Options
- BGEReranker/SentenceReranker: Enhances final result quality with model-based reranking.
- StatementDiversityPostProcessor: Removes duplicate statements based on TF-IDF similarity.
- EnrichSourceDetails: Adds source metadata to clarify information provenance.
- StatementEnhancementPostProcessor: Enriches statement content using an LLM.

SemanticGuidedRetriever utilizes both semantic similarity and graph structure to effectively discover relevant information, even if not directly similar to the query. It is particularly useful for complex queries or cases requiring diverse perspectives.

4.4. Other

The AWS GraphRAG Toolkit utilizes separate graph and vector stores during graph construction and retrieval, integrating with existing AWS security mechanisms.

Dual Storage Architecture
- Graph Store: Stores graph elements like entities, relationships, statements, facts in Amazon Neptune, Neptune Analytics, or FalkorDB.
- Vector Store: Stores chunk and statement embeddings in Amazon OpenSearch Serverless or Neptune Analytics.
Performance Optimization Options
- Batch Extraction: Large dataset processing utilizing Amazon Bedrock batch inference.
- GraphRAGConfig: System performance settings like worker count, batch size, caching.
- Response Caching: Stores LLM call results on the local filesystem to minimize redundant calls.

The AWS GraphRAG Toolkit overcomes the limitations of traditional vector search-based RAG, enabling more comprehensive and accurate information retrieval by leveraging graph structures. It demonstrates outstanding performance, especially in scenarios involving complex queries, multi-step reasoning, or where inter-document connections are important.

5. Comparison of Graph RAG Approaches and Conclusion

Approach	Indexing Stage	Pre-Retrieval Stage	Retrieval Stage	Post-Retrieval Stage
KG & Semantic Clustering	• Build Knowledge Graph		• Graph Traversal	• Semantic Clustering
KG & Vector DB Integration	• Vectorize Documents • Build Knowledge Graph		• Vector Search • Graph Traversal
Graph-Enhanced Hybrid Search	• Vectorize Documents • Keyword Indexing • Build Knowledge Graph		• Vector Search • Keyword Search • Graph Traversal	• Reranking or Rank Fusion
KG-Enhanced Q&A Pipeline	• Vectorize Documents • Build Knowledge Graph		• Vector Search (on chunks) • Graph Traversal (on entities & properties)
KG-Based Query Expansion/Gen	• Build Knowledge Graph • Vectorize Node Properties	• LLM Entity/Relation Extraction • Query Expansion	• Vector Search (on entities & relations) • Graph Traversal
RAPTOR	• Vectorize Documents • Clustering • LLM-based Summarization • Recursive Structuring	• Vectorize Query	• Tree Traversal: Layer-wise similarity-based node selection • Collapsed Tree: Flatten tree & vector search
GraphRAG (Microsoft)	• LLM Entity/Relation Extraction • Build Knowledge Graph • Community Detection (Leiden) • Community Summaries	• Query Expansion (HyDE) • Follow-up Question Gen.	• Static/Dynamic Global Search: Use community reports • DRIFT Search: Global+Local hybrid	• Map-Reduce Integration • Output Hierarchy
GraphRAG Toolkit (AWS)	• LLM Proposition/Entity/Relation/Topic/Statement/Fact Extraction • Build KG • Vectorize Chunks & Statements	• Keyword Extraction • Complex Query Decomposition	• TraversalBasedRetriever: Top-down/Bottom-up • SemanticGuidedRetriever: Cosine Sim, Keyword Rank, Beam Search	• Statement Reranking • Diversity Processing • Source Enrichment • Statement Enhancement

The Graph RAG approaches examined so far overcome the limitations of traditional vector-based RAG, enabling richer and more accurate information retrieval. Key insights include:

Structural Advantage: A common thread across all approaches is the crucial role of graph structure in preserving inter-document relationships and maintaining context. This helps discover associative information missed by simple vector similarity.
Combined Retrieval Strategies: Most approaches adopt hybrid methods combining vector search, keyword search, and graph traversal. This composite strategy maximizes the strengths of each method for more accurate and comprehensive retrieval.
Hierarchical Structuring: RAPTOR, MS GraphRAG, and AWS GraphRAG all employ methods to hierarchize documents into various abstraction levels. This allows providing information at an appropriate level of detail based on query complexity and needs.
LLM Utilization: In all approaches, LLMs are utilized not just for response generation but also in various stages like entity extraction, summary generation, and query expansion. This significantly enhances the quality of the graph structure and retrieval efficiency.
Scalability and Efficiency: Particularly, AWS GraphRAG and MS GraphRAG offer optimization features (batch processing, auto-tuning, etc.) for handling large datasets, increasing their practicality in enterprise environments.

Graph RAG is still an evolving field, but it already demonstrates superior performance compared to existing RAG systems in handling complex queries, supporting multi-step reasoning, and leveraging inter-document connectivity. Future developments are expected in areas like improving the efficiency of graph structure creation, supporting diverse data types, and real-time graph updates.

References

Papers

RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval (Stanford Univ.)
From Local to Global: A Graph RAG Approach to Query-Focused Summarization (Microsoft)

Blogs

Code Repositories

RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval (Stanford Univ.)
GraphRAG Code, Doc (Microsoft)
Retrieval Augmented Generation (RAG) with Knowledge Graph Using SPARQL (AWS)
GraphRAG Toolkit (AWS)

Graph RAG의 모든 것

Jonas Kim — Mon, 21 Apr 2025 03:51:40 +0000

Graph RAG의 사전지식부터 이론과 구현 상세를 체계적으로 탐구합니다.

1. Graph RAG 정의와 장점

Graph RAG는 기존 검색 증강 생성(Retrieval-Augmented Generation) 기법을 지식 그래프와 결합하여 대규모 언어 모델(LLM)의 응답 품질을 향상시키는 혁신적 접근법입니다. 전통적인 RAG가 벡터 임베딩 기반 문서 검색에 의존한다면, Graph RAG는 개체(노드)와 관계(엣지)로 구성된 지식 그래프의 구조적 정보를 활용합니다. 이를 통해 LLM은 단순한 키워드 매칭이나 벡터 유사도를 넘어, 개념들 간의 복잡한 연결 관계와 맥락을 이해하여 더 정확하고 풍부한 정보를 바탕으로 응답을 생성할 수 있습니다. 특히 다단계 추론이 필요한 복잡한 질의에서 그래프 기반 지식 네트워크가 탁월한 효과를 발휘합니다.

전통적인 RAG의 한계점

마이크로소프트 리서치의 "GraphRAG: Unlocking LLM Discovery on Narrative Private Data" 연구에 따르면, 기존 RAG 접근법은 다음과 같은 중요한 한계를 가지고 있습니다.

정보 연결의 어려움: 기존 RAG는 분산된 정보의 청크를 논리적으로 연결하여 새로운 통합 인사이트를 도출해야 하는 상황에서 어려움을 겪습니다. 특히 여러 문서에 걸친 공유 속성이나 관계를 통합해야 할 때 이러한 한계가 두드러집니다.
대규모 정보의 종합적 이해 부족: 기존 RAG는 대용량 데이터 컬렉션이나 대형 문서에 걸친 의미적 개념을 전체적으로 파악하고 요약하는 작업에서 성능이 저하됩니다.

이러한 한계점들이 Graph RAG의 등장 배경이 되었으며, 그래프 구조를 통해 이러한 문제를 효과적으로 해결하는 방향으로 연구가 진행되고 있습니다.

Graph RAG의 주요 장점

정교한 검색 능력: 그래프 순회(traversal)를 통해 방대한 지식 저장소에서 관련 사실 정보를 효과적으로 찾아내 LLM이 상세하고 정확한 응답을 생성하도록 지원합니다.
맥락적 관계 제공: 지식 그래프의 관계는 문서의 개별 청크 만으로는 파악하기 어려운 유용한 맥락 정보를 제공하여, LLM이 더 넓은 지식 배경을 고려한 응답을 생성할 수 있게 합니다.
질의 의도의 정확한 이해: 그래프 상에서 개체와 관계를 하나의 의미 단위로 모델링함으로써, 단순 키워드 매칭보다 사용자 질의의 의도를 더 정확히 파악할 수 있습니다. 이는 특히 복잡한 질의에 대한 맥락적 정확성을 높입니다.
향상된 설명 가능성: 그래프의 링크를 따라가면 모델이 활용한 사실의 출처를 쉽게 추적할 수 있어, 응답의 근거를 명확히 설명할 수 있습니다. 이는 결과의 신뢰성과 투명성을 크게 높여줍니다.
풍부하고 포괄적인 응답: 그래프는 개념들과 그들 사이의 복잡한 연결을 명시적으로 표현하므로, LLM에 더 구조화된 지식을 제공하여 보다 포괄적이고 깊이 있는 답변 생성을 가능하게 합니다.
효율적인 지식 확장성: 새로운 정보를 그래프에 추가하여 지식을 확장하기가 상대적으로 용이하므로, LLM 자체의 파라미터를 늘리는 것보다 비용 효율적으로 도메인 지식을 확장할 수 있습니다.
다단계 추론 지원: 그래프 구조는 복잡한 추론 체인을 형성하는 데 도움이 되어, 단계적 사고가 필요한 복잡한 질문에 더 정확하게 응답할 수 있습니다.

2. 지식 그래프(Knowledge Graph) 및 그래프 데이터베이스(Graph DB) 개요

Graph RAG를 제대로 활용하기 위해서는 그 기반이 되는 지식 그래프와 그래프 데이터베이스에 대한 이해가 필수적입니다.

2.1. 지식 그래프란?

지식 그래프는 현실 세계의 개체(사람, 장소, 개념 등)들과 그들 간의 관계를 그래프 구조로 표현한 데이터 모델입니다. 이 구조에서는

노드(Node): 개체를 나타냅니다 (예: 사람, 도시, 제품, 개념 등)
엣지(Edge): 개체 간의 관계를 연결합니다 (예: '거주한다', '창업했다', '포함한다' 등)
속성(Properties): 노드와 엣지에 부여되는 추가적인 정보입니다 (예: 이름, 날짜, 가중치 등)

이러한 그래프 구조는 방대한 지식을 의미적 네트워크 형태로 표현하여, 시스템이 데이터 간의 의미 있는 관계를 "이해"하고 추론할 수 있도록 합니다. 결과적으로 지식 그래프는 AI 모델이 연결된 데이터로부터 패턴을 인식하고 새로운 연관성을 유추하는 데 활용되어 검색, 추천, 질의응답 등의 성능을 크게 향상시킬 수 있습니다.

2.2. 그래프 데이터베이스

지식 그래프를 효과적으로 활용하려면 그래프 데이터를 저장하고 질의할 수 있는 그래프 데이터베이스(Graph DB)가 필요합니다. 그래프 DB는 노드와 엣지로 이루어진 그래프 데이터를 저장/관리하며, 관계 중심적인 질의를 효율적으로 처리하도록 특별히 설계된 DBMS입니다.

그래프 데이터베이스의 주요 특징은 다음과 같습니다.

관계 중심 데이터 모델: 데이터 간의 관계가 일급 객체(first-class citizen)로 취급되어 직접적으로 저장 및 질의됩니다.
유연한 스키마: 새로운 노드 유형이나 관계를 필요에 따라 쉽게 추가할 수 있어 변화하는 요구사항에 빠르게 적응할 수 있습니다.
효율적인 그래프 탐색: 연결된 데이터를 빠르게 탐색할 수 있는 최적화된 구조를 가지고 있어, 복잡한 관계 기반 질의를 효율적으로 처리합니다.
직관적인 데이터 모델링: 실제 세계의 관계를 자연스럽게 표현할 수 있어 도메인 전문가도 이해하기 쉬운 데이터 모델을 구축할 수 있습니다.
인덱스 프리 인접성(Index-free adjacency): 많은 그래프 데이터베이스는 노드 간의 연결을 물리적 포인터로 저장하여 관계 조회 성능을 최적화합니다.

관계형 DB (RDB) vs 그래프 DB 비교

특성	관계형 데이터베이스 (RDB)	지식 그래프 (Knowledge Graph)
데이터 저장 방식	구조화된 테이블 형태	개체(노드)와 관계(엣지)로 구성
스키마	정형화된 고정 스키마	유연한 스키마 구조
데이터 조작	SQL을 통한 조작	그래프 질의 언어 사용 (Cypher, SPARQL 등)
관계 표현	외래 키를 통한 간접 표현	직접적인 관계로 표현
복잡한 관계 처리	여러 조인 필요 (성능 저하)	직관적인 관계 탐색 (성능 우수)
패턴 발견	제한적	숨겨진 연결과 패턴 발견 용이
데이터 통합	스키마 변경 어려움	다양한 소스의 데이터 통합 용이

2.3. 그래프 모델의 종류

그래프 데이터베이스에서는 크게 두 가지 주요 모델이 사용됩니다.

프로퍼티 그래프(Property Graph) 모델

노드와 엣지에 직접 속성(properties)을 부여할 수 있습니다.
라벨을 통해 노드 및 엣지를 분류합니다.
단일 지식 소스 내에서의 단순성과 직관성을 제공합니다.
Neo4j가 대표적인 구현체이며, 주로 OpenCypher나 Gremlin과 같은 질의 언어를 사용합니다.

RDF(Resource Description Framework) 모델

URI를 통한 표준화된 식별자를 사용합니다.
주어-술어-목적어 형태의 트리플(triple) 구조로 데이터를 표현합니다.
W3C 표준을 기반으로 하며, 여러 지식 소스 간 통합과 표준화를 지원합니다.
주로 SPARQL 질의 언어를 사용합니다.

2.4. 그래프 질의 언어 비교

그래프 데이터베이스에서는 저장된 그래프의 유형에 따라 다양한 질의 언어가 사용됩니다.

Cypher

프로퍼티 그래프 모델을 위한 질의 언어로, Neo4j에서 주로 사용됩니다.
직관적인 시각적 패턴 매칭 구문을 특징으로 합니다.
노드는 괄호 (), 관계는 화살표 --> 또는 방향이 있는 화살표 -[]-> 로 표현합니다.

예시: 서울에 거주하는 모든 사람의 이름을 찾는 질의

MATCH (p:Person)-[:LIVES_IN]->(c:City)
WHERE c.name = "Seoul"
RETURN p.name

SPARQL

RDF 그래프 모델을 위한 W3C 표준 질의 언어입니다.
트리플 패턴 기반의 질의를 사용하고, URI를 통해 리소스를 명확하게 식별합니다.
여러 데이터셋 간 통합 질의가 가능합니다.

예시: 위와 동일한 질의를 SPARQL로 표현

SELECT ?person
WHERE {
  ?person rdf:type ex:Person .
  ?person ex:livesIn ex:Seoul .
}

Gremlin

Apache TinkerPop 프레임워크의 일부로, 프로퍼티 그래프 모델을 위한 명령형 그래프 순회 언어입니다.
다양한 그래프 데이터베이스에서 지원됩니다.
함수형 스타일의 연쇄 호출 방식으로 그래프를 탐색합니다.

예시: 위와 동일한 질의를 Gremlin으로 표현

g.V().hasLabel('Person').
  out('LIVES_IN').
  has('name', 'Seoul').
  in('LIVES_IN').
  values('name')

2.5 AWS에서 사용 가능한 Graph DB 비교

특성	Neo4j	Amazon Neptune
제공자	AWS 마켓플레이스	AWS 관리형 서비스
지원 데이터 모델	프로퍼티 그래프	프로퍼티 그래프, RDF
지원 질의 언어	Cypher	Gremlin, SPARQL, OpenCypher
관리와 운영	사용자 관리	완전 관리형
LangChain과의 통합	지원	지원(Cypher, SPARQL)
LlamaIndex와의 통합	지원	지원

3. Graph RAG 디자인 패턴

Graph RAG는 지식 그래프를 RAG 파이프라인에 통합하는 접근법으로, 아직 표준화된 구현 방식이 정립되지 않았습니다. Ben Lorica와 Prashanth Rao의 분석에 따른 주요 디자인 패턴들을 살펴보겠습니다.

3.1. 일반적인 디자인 패턴

지식 그래프와 의미 기반 클러스터링

이 패턴은 사용자 질의에 대해 지식 그래프와 그래프 머신러닝을 활용하여 정보를 검색하고, 의미적 클러스터로 조직화합니다.

작동 방식
1. 사용자가 질의를 제출합니다.
2. 시스템은 지식 그래프와 그래프 머신러닝을 사용해 관련 정보를 검색합니다.
3. 검색된 정보는 그래프 기반 클러스터링을 통해 의미적 클러스터로 조직화됩니다.
4. 클러스터링된 정보가 LLM의 컨텍스트를 풍부하게 하여 더 정확한 답변 생성을 돕습니다.
5. 최종 답변에는 지식 그래프에 대한 참조가 포함됩니다.
활용 사례: 데이터 분석, 지식 발견, 연구 분야

지식 그래프와 벡터 데이터베이스 통합

이 접근법은 지식 그래프와 벡터 데이터베이스를 모두 활용하여 관련 정보를 수집합니다.

작동 방식
1. 지식 그래프는 벡터화한 문서 청크 간의 관계(문서 계층 구조 포함)를 캡처합니다.
2. 벡터 검색에서 검색된 청크 주변의 이웃 구조화된 개체 정보를 지식 그래프가 제공하여 프롬프트를 풍부하게 합니다.
3. 강화된 프롬프트가 LLM에 입력되어 응답을 생성합니다.
4. 생성된 답변이 사용자에게 반환됩니다.
활용 사례: 고객 지원, 의미적 검색, 개인화된 추천 시스템

그래프 강화 하이브리드 검색

이 아키텍처는 벡터 검색, 키워드 검색, 그래프 특화 질의를 결합한 하이브리드 접근법을 사용합니다.

작동 방식
1. 사용자가 질의를 제출합니다.
2. 비구조화 데이터 검색과 그래프 데이터 검색 결과를 통합하는 하이브리드 검색 프로세스가 진행됩니다.
3. 벡터 및 키워드 인덱스 검색 결과는 리랭킹이나 랭크 퓨전 기법으로 강화될 수 있습니다.
4. 세 가지 검색 형태의 결과를 모두 결합하여 LLM을 위한 컨텍스트를 생성합니다.
5. LLM이 생성한 응답이 사용자에게 전달됩니다.
활용 사례: 기업 검색, 문서 검색, 지식 발견

지식 그래프 강화 질의응답 파이프라인

이 아키텍처는 벡터 검색 이후 단계에서 지식 그래프를 활용해 추가적인 사실로 응답을 강화합니다.

작동 방식
1. 사용자가 질의를 제공합니다.
2. 질의 임베딩이 계산됩니다.
3. 벡터 인덱스에서 벡터 유사도 검색을 통해 지식 그래프의 관련 개체를 식별합니다.
4. 그래프 데이터베이스에서 관련 노드와 속성을 검색하고, 발견되면 Cypher 질의를 실행해 추가 정보를 검색합니다.
5. 검색된 정보를 종합하여 포괄적인 컨텍스트를 형성하고, 이를 LLM에 전달하여 응답을 생성합니다.
활용 사례: 의료나 법률과 같이 응답 내 개체에 기반한 표준 정보가 답변과 함께 포함되어야 하는 환경

지식 그래프 기반 질의 확장 및 생성

이 아키텍처는 벡터 검색 전에 지식 그래프를 활용해 관련 노드와 엣지를 탐색하여 LLM의 컨텍스트를 풍부하게 합니다.

작동 방식
1. 첫 단계는 질의 확장으로, 사용자 질의가 LLM에 의해 처리되어 핵심 개체와 관계를 추출합니다.
2. 지식 그래프 내 노드 속성에 대해 벡터 검색을 수행하여 관련 노드를 식별합니다.
3. 다음 단계는 질의 재작성으로, 검색된 서브그래프에 대해 Cypher 질의를 생성하여 그래프에서 관련 구조화 정보를 좁힙니다.
4. 그래프 탐색 결과를 LLM의 컨텍스트 창을 풍부하게 하는 데 사용합니다.
5. LLM은 향상된 컨텍스트를 기반으로 응답을 생성합니다.
활용 사례: 개체 간 관계가 중요한 제품 조회나 금융 보고서 생성

3.2. RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval (Stanford Univ, 2024)

RAPTOR는 스탠포드 대학에서 개발한 특별한 RAG 기법으로, 긴 문서를 효과적으로 처리하기 위해 트리 구조의 계층적 색인을 활용합니다. 기존 RAG가 문서를 작은 청크로 나누어 독립적으로 검색하는 반면, RAPTOR는 문서 전체의 구조와 맥락을 보존하는 계층적 요약 트리를 구축합니다.

색인 과정

청크 분할
- 원본 문서를 약 100토큰 크기의 작은 청크로 분할합니다.
- 문장이 토큰 제한을 초과하면 문장 중간에서 자르지 않고 다음 청크로 이동시켜 의미적 일관성을 유지합니다.
임베딩 및 군집화:
- 각 청크는 SBERT(BERT 기반 인코더)를 통해 벡터로 임베딩됩니다.
- 가우시안 혼합 모델(GMM)을 사용해 의미적으로 유사한 청크들을 군집화합니다.
- 소프트 클러스터링으로 하나의 노드가 여러 군집에 속할 수 있게 합니다.
요약 노드 생성
- 각 군집의 청크들은 언어 모델(예: GPT-3.5-turbo)을 통해 요약됩니다.
- 요약 텍스트는 새로운 노드가 되어 다시 벡터로 임베딩됩니다.
재귀적 과정
- 임베딩-군집화-요약 과정을 더 이상 군집화가 불가능할 때까지 반복하여 다층 트리 구조를 형성합니다.
- 이 과정은 문서 규모에 따라 선형적인 계산 복잡성을 가집니다.

검색 과정

RAPTOR는 두 가지 고유한 검색 전략을 제공합니다.

트리 순회(Tree Traversal) 방식
1. 루트 계층에서 시작하여 질의 임베딩과 해당 계층의 모든 노드 임베딩 간 코사인 유사도를 계산합니다.
2. 유사도 점수가 가장 높은 상위 k 노드를 선택합니다(집합 S1).
3. S1 집합의 원소들의 자식 노드로 진행하여 질의 벡터와의 코사인 유사도를 계산합니다.
4. 유사도 점수가 가장 높은 상위 k개 자식 노드를 선택합니다(집합 S2).
5. 이 과정을 d개 계층에 대해 반복하여 집합 S1부터 Sd까지 생성합니다.
6. 모든 집합을 연결하여 질의에 관련된 컨텍스트를 구성합니다.

이 방식은 계층 별로 상위 k개 노드만 고려하기 때문에 각 계층에서 정보의 양이 균일하게 유지됩니다.

축소 트리(Collapsed Tree) 방식
1. 전체 RAPTOR 트리를 단일 계층으로 축소합니다.
2. 질의 임베딩과 축소된 집합의 모든 노드 임베딩 간 코사인 유사도를 계산합니다.
3. 유사도 점수가 가장 높은 노드부터 시작해 사전에 정의된 최대 토큰 수에 도달할 때까지 노드를 결과 집합에 추가합니다.

실험 결과, 축소 트리 방식이 트리 순회 방식보다 일관되게 더 나은 성능을 보였습니다. 이는 축소 트리 방식이 모든 노드를 동시에 고려함으로써 질문에 적합한 수준의 세부 정보를 검색할 수 있는 유연성을 제공하기 때문입니다.

3.3. From Local to Global: A Graph RAG Approach to Query-Focused Summarization (Microsoft Research, 2024)

마이크로소프트 리서치의 GraphRAG는 전통적인 RAG가 특정 질의에 관련된 단편적 정보를 찾는 한계를 넘어, "이 데이터셋의 주요 주제는 무엇인가?"와 같은 전체 데이터셋에 대한 포괄적인 질문에 효과적으로 답하기 위해 설계되었습니다.

색인 과정

문서 청킹
- 소스 문서를 분석 가능한 크기로 청킹합니다.
- 각 청크는 독립적으로 처리되며 이후 그래프 구성에 사용됩니다.
개체 및 관계 추출
- LLM을 활용하여 각 청크에서 중요 개체(인물, 장소, 조직, 개념 등)를 식별합니다.
- 개체 간 의미 있는 관계를 추출하고 짧은 설명을 생성합니다.
- 도메인 특화 프롬프트가 사용되어 관련성 높은 개체와 관계를 포착합니다.
지식 그래프 구축
- 추출된 개체와 관계는 노드와 엣지로 변환되어 그래프를 형성합니다.
- 개체 설명은 집계 및 요약되어 각 노드와 엣지에 첨부됩니다.
- 중복된 관계는 엣지 가중치로 표현되어 관계의 강도를 나타냅니다.
커뮤니티 탐지 및 요약
- Leiden 알고리즘 같은 커뮤니티 탐지 알고리즘으로 그래프를 의미 있는 커뮤니티로 분할합니다.
- 계층적으로 수행되어 다양한 추상화 수준의 커뮤니티 구조를 형성합니다.
- 각 커뮤니티에 대해 LLM을 활용하여 보고서 형태의 요약을 생성합니다.
- 하위 레벨 커뮤니티의 요약은 상위 레벨 커뮤니티 요약 생성에 활용됩니다.

검색 과정

GraphRAG는 여러 검색 모드를 제공하며, 각 모드는 서로 다른 유형의 질의에 최적화되어 있습니다.

정적 글로벌 검색 (Static Global Search)

전체 데이터셋에 대한 종합적인 이해가 필요한 질의를 위한 방식입니다.

사전 정의된 커뮤니티 레벨 활용
- 지식 그래프의 특정 레벨(예: 레벨 1)에 있는 모든 커뮤니티 보고서를 검색합니다.
- 이 방식은 단순하지만 많은 토큰을 소비하며, 질의와 무관한 보고서도 모두 포함됩니다.
맵-리듀스(Map-Reduce) 프로세스
1. 맵(Map) 단계: 각 커뮤니티 보고서를 대상으로 질의에 대한 답변과 관련성 점수를 생성합니다.
2. 리듀스(Reduce) 단계: 관련성 점수에 따라 답변을 통합하여 최종 응답을 생성합니다.

동적 글로벌 검색 (Dynamic Global Search)

정적 글로벌 검색의 비효율성을 개선한 접근법입니다.

동적 커뮤니티 선택 프로세스
- 지식 그래프의 루트에서 시작하여 각 커뮤니티 보고서의 관련성을 LLM으로 평가합니다.
- 관련성이 낮은 보고서와 그 하위 노드는 검색 과정에서 제외됩니다.
- 관련성이 높은 보고서의 경우 하위 노드로 이동하여 평가를 계속합니다.

DRIFT(Dynamic Reasoning and Inference with Flexible Traversal) 검색

DRIFT 검색은 GraphRAG 환경에서 로컬 검색의 한계를 극복하기 위해 설계된 하이브리드 접근법입니다. 기존 로컬 검색이 단순히 질의와 유사한 텍스트 청크만 검색하는 한계를 넘어, 커뮤니티 정보를 활용해 더 풍부하고 포괄적인 답변을 제공합니다.

최초(Primer) 단계: 고수준 맥락 파악
- 질의 확장: 사용자 질의를 HyDE(Hypothetical Document Embeddings) 기법으로 확장하여 검색 민감도(recall)를 높입니다. HyDE는 원래 질의에서 가상의 이상적인 문서를 생성한 후, 그 문서를 임베딩하여 검색에 활용하는 기법입니다.
- 커뮤니티 보고서 검색: 확장된 질의를 임베딩하고, 이를 모든 커뮤니티 보고서와 비교하여 의미적으로 가장 관련성 높은 상위 K개의 보고서를 선택합니다. 이 보고서들은 GraphRAG의 글로벌 인덱스에서 나온 것으로, 데이터셋의 고수준 개요를 제공합니다.
- 초기 답변 생성: 선택된 커뮤니티 보고서를 LLM에 제공하여 초기 답변을 생성합니다.
- 후속 질문 생성: 동시에 LLM은 원래 질의를 기반으로 더 세부적인 후속 질문들을 생성합니다. 이 질문들은 초기 답변에서 누락된 정보나 더 상세한 탐색이 필요한 영역을 대상으로 합니다.
후속(Follow-Up) 단계: 세부 정보 탐색
- 로컬 검색 실행: 각 후속 질문에 대해 일반적인 로컬 검색 변형을 실행합니다. 이는 원래 텍스트 청크 레벨에서 가장 관련성 높은 내용을 찾는 과정입니다.
- 중간 답변 생성: 각 후속 질문에 대한 로컬 검색 결과를 바탕으로 중간 답변을 생성합니다.
- 반복적 정제: 이러한 중간 답변에서 다시 새로운 후속 질문이 생성될 수 있으며, 이는 정보 탐색의 반복적인 루프를 형성합니다. 일반적으로 시스템은 2회 반복 후 종료합니다.
출력 계층 구조(Output Hierarchy) 단계: 결과 통합
- 계층적 구조화: 모든 질문과 답변이 원래 질의와의 관련성에 따라 순위가 매겨진 계층 구조로 조직됩니다.
- 맵-리듀스 통합: 벤치마크 테스트에서는 단순한 맵-리듀스 접근법을 사용하여 모든 중간 답변을 동등하게 가중치를 두고 집계했습니다.
- 최종 응답 생성: 집계된 정보를 바탕으로 사용자의 원래 질의에 대한 최종 응답이 생성됩니다.

이 접근법의 장점은 고수준의 개요에서 시작하여 점진적으로 세부 정보를 탐색하는 방식으로, 단일 검색 과정에서 놓칠 수 있는 중요한 정보를 포착할 수 있다는 것입니다.

자동 튜닝 (Auto-Tuning)

GraphRAG의 강점 중 하나는 새로운 도메인에 빠르게 적응할 수 있는 자동 튜닝 능력입니다.

도메인 및 페르소나 식별
- 소스 콘텐츠의 샘플(전체 데이터의 약 1%)을 LLM에 전송합니다.
- LLM이 도메인을 식별하고 적절한 페르소나를 생성합니다.
- 이 페르소나는 추출 프로세스를 조정하는 데 사용됩니다.
도메인 특화 프롬프트 생성
- 도메인과 페르소나가 확립되면, 여러 프로세스가 병렬로 실행되어 맞춤형 색인 프롬프트를 생성합니다.
- 예시 기반의 프롬프트는 실제 도메인 데이터에 기반하여 생성됩니다.
- 기본 개체 유형(인물, 조직, 지역 등)을 넘어 도메인 특화 개체(예: 화학의 '분자', '반응')를 식별합니다.

마이크로소프트의 GraphRAG는 기존 요약 기법과 비교하여 포괄성과 다양성 측면에서 월등한 성능을 보이며, 특히 대규모 데이터셋에서 글로벌 질문에 대한 응답 품질이 크게 향상되었습니다. 이 접근법은 로컬 세부 정보와 글로벌 맥락 사이의 균형을 자동으로 찾아내어 다양한 사용 사례에 적용할 수 있는 유연하고 효과적인 솔루션을 제공합니다.

4. AWS GraphRAG Toolkit

AWS GraphRAG 툴킷은 Graph RAG 개념을 AWS 클라우드 환경에서 쉽게 구현할 수 있는 파이썬 기반 오픈소스 프레임워크입니다. LlamaIndex 라이브러리를 활용해 비정형 텍스트로부터 자동으로 그래프를 구축하고 벡터 인덱싱을 수행하며, LLM 질의에 대한 그래프 기반 검색을 지원합니다.

4.1. 그래프 모델 설계

AWS GraphRAG 툴킷은 세 개의 계층으로 구성된 어휘적 그래프 모델을 사용합니다.

1. 계통(Lineage) 계층

소스(Source) 노드
- 원본 문서의 메타데이터(작성자, URL, 발행일 등)를 저장합니다.
- 문서 출처를 추적하고 검증하는 데 중요한 역할을 합니다.
청크(Chunk) 노드
- 실제 텍스트 내용과 해당 텍스트의 임베딩을 저장합니다.
- 이전/다음, 부모/자식 청크와의 관계를 통해 원본 문서의 구조적 맥락을 유지합니다.

계통 계층은 문서의 원본 구조와 출처를 보존함으로써 정보의 계보를 추적할 수 있게 합니다. 이는 특히 정보의 신뢰성과 검증이 중요한 엔터프라이즈 환경에서 큰 가치를 제공합니다.

2. 개체-관계(Entity-Relationship) 계층

이 계층은 문서 내 주요 개체와 그들 간의 관계를 표현하여 그래프의 핵심 구조를 형성합니다.

개체(Entity) 노드
- 값(예: 'Amazon')과 분류(예: 'Company')를 포함합니다.
- 키워드 기반 검색의 진입점 역할을 수행합니다.
- 사람, 장소, 조직 등 실세계 개체를 표현합니다.
관계(Relation) 엣지
- 개체 간 관계(예: 'WORKS_FOR', 'LOCATED_IN')를 정의합니다.
- 선호 개체 분류 목록으로 가이드되어 일관성을 유지합니다.

개체-관계 계층은 문서 내에서 발견된 주요 개체와 그들 간의 관계를 표현합니다. 이는 그래프의 핵심 구조를 형성하며, 특히 키워드 기반의 '상향식'(bottom-up) 검색에서 중요한 시작점 역할을 합니다.

3. 요약(Summarization) 계층

주제(Topic) 노드
- 특정 소스 문서 내의 주제나 테마를 표현합니다.
- 단일 소스 내 관련 청크들을 연결하는 지역적 연결점 역할을 합니다.
- 여러 청크에 걸친 동일 주제를 하나로 묶어 문서 수준의 요약을 제공합니다.
서술(Statement) 노드
- 독립된 주장이나 서술 단위로, LLM 질의 응답 시 제공되는 주요 컨텍스트 단위입니다.
- 주제 노드 아래 그룹화되며, 연결 리스트로 순서가 유지됩니다.
- 사실 노드들과 연결되어 의미 관계를 형성합니다.
- 질의 응답 시 LLM에 제공되는 기본 컨텍스트 단위입니다.
사실(Fact) 노드
- 주어-술어-목적어(SPO) 또는 주어-술어-보어(SPC) 형태의 단일 사실 단위입니다.
- 여러 문서에서 언급된 동일 사실을 단일 노드로 표현해 문서 간 글로벌 연결성을 제공합니다.
- 서술 노드를 지원(SUPPORTS)하는 관계를 형성합니다.
- 문서 간 정보를 연결하는 다리 역할을 수행합니다.

요약 계층은 원본 텍스트를 다양한 수준의 추상화로 구조화하여, 질의에 가장 적합한 수준의 정보를 제공할 수 있게 합니다. '주제'는 문서 내 로컬 연결성을, '사실'은 문서 간 글로벌 연결성을 제공하여 강력한 검색 기반을 형성합니다.

4.2. 색인 과정

AWS GraphRAG 툴킷의 색인은 두 개의 주요 단계로 구성됩니다.

1. 추출 단계 (Extract)

문서 청킹 (선택적)
- LlamaIndex SentenceSplitter 등을 사용해 문서를 일정 크기의 청크로 분할합니다.
- 기본 설정은 크기 256 토큰, 중복 20 토큰이지만 사용자 지정 가능합니다.
- 문장의 의미적 일관성을 유지하기 위해 문장 단위로 분할을 수행합니다.
명제(Proposition) 추출 (선택적)
- LLM이 각 청크의 내용을 단순화된 명제 형태로 변환합니다.
- 복잡한 문장을 더 간단한 문장으로 분해하고, 대명사를 구체적인 이름으로 대체합니다.
- 약어를 가능한 경우 풀어서 표현하여 후속 추출 작업의 품질을 향상시킵니다.
- 추출된 명제는 aws::graph::propositions 메타데이터 키로 저장됩니다.
개체/관계/주제/서술/사실 추출 (필수)
- LLM이 이전 단계의 명제(또는 소스 청크)을 분석합니다.
- 개체와 그 분류(classification)를 추출하고, 개체 간 관계를 식별합니다.
- 텍스트의 주제에 따라 주제 단위로 내용을 그룹화합니다.
- 독립적 의미를 가진 서술과 트리플 형태의 사실을 추출합니다.
- 추출된 모든 정보는 aws::graph::topics 메타데이터 키로 저장됩니다.

추출 단계는 비정형 텍스트를 구조화된 그래프 요소로 변환하는 핵심 과정입니다. 특히 LLM을 이용한 명제 추출은 정보의 품질을 향상시키지만, 성능과 비용을 고려하여 선택적으로 적용할 수 있습니다.

2. 구축 단계 (Build)

노드 변환
- 추출 단계에서 생성된 메타데이터를 소스, 청크, 주제, 서술, 사실 노드로 변환합니다.
- 각 노드에는 aws::graph::index 메타데이터가 포함되어 벡터 인덱싱에 활용됩니다.
그래프 구성
- 변환된 노드와 관계를 그래프 데이터베이스에 저장합니다.
- 노드 간 관계(SUPPORTS, NEXT 등)를 설정하여 그래프 구조를 완성합니다.
벡터 인덱싱
- 청크와 서술 노드의 임베딩을 생성하고 벡터 스토어에 인덱싱합니다.
- 선택적으로 팩트와 토픽도 임베딩하여 다양한 수준의 검색을 지원할 수 있습니다.

구축 단계는 추출된 정보를 실제 그래프 및 벡터 스토어에 저장하는 과정입니다. 이 과정을 통해 검색 가능한 지식 그래프가 완성됩니다.

3. 연속 적재와 배치 처리

연속 적재
- extract_and_build() 메소드로 추출과 구축을 동시에 실행합니다.
- 마이크로 배치 처리로 추출 시작 직후 그래프 구축이 시작되어 즉시 사용 가능합니다.
- 실시간 업데이트가 필요한 시나리오에 적합합니다.
분리 실행
- extract()와 build()를 별도로 실행하여 처리를 분리합니다.
- S3BasedDocs나 FileBasedDocs를 사용해 중간 결과를 저장하고 재사용할 수 있습니다.
- 대규모 데이터셋이나 다양한 환경(개발/테스트/프로덕션)에서의 활용에 유용합니다.
체크포인트 관리
- Checkpoint 인스턴스로 처리 상태를 관리하여 중복 처리를 방지합니다.
- 실패 후 재시작 시 이미 성공적으로 처리된 청크를 건너뛰어 효율성을 높입니다.
- 그래프 구축이 완료된 청크만 체크포인트로 표시하여 일관성을 유지합니다.
배치 처리 최적화
- 배치 설정(batch_config)을 통해 대규모 데이터 처리를 최적화합니다.
- Amazon Bedrock 배치 추론과 통합하여 LLM 호출 비용을 절감할 수 있습니다.
- 병렬 처리를 위한 작업자(worker) 수와 배치 크기를 조정하여 성능을 최적화합니다.

색인 프로세스는 유연하게 구성할 수 있어 다양한 규모와 요구사항에 맞게 조정이 가능합니다. 특히 체크포인트와 배치 처리는 대규모 데이터셋을 효율적으로 처리하는 데 중요한 역할을 합니다.

4.3. 검색 과정

AWS GraphRAG 툴킷은 두 가지 주요 검색기를 제공하여 다양한 검색 요구에 대응합니다.

1. TraversalBasedRetriever

TraversalBasedRetriever는 그래프 순회를 통한 검색 방식으로, 두 가지 보완적 전략을 활용합니다.

청크 기반 검색: 하향식 (Top-down) 접근법
- 벡터 유사도를 활용해 질의와 관련성 높은 청크를 식별합니다.
- 찾은 청크에서 주제로 이동하고, 다시 관련 서술과 사실로 확장합니다.
- 질의와 직접적인 의미 유사성이 있는 영역에 집중하여 깊이 있는 정보를 제공합니다.
- 설정 가능한 vss_top_k와 vss_diversity_factor 매개변수로 결과의 양과 다양성을 조정합니다.
개체 기반 검색: 상향식 (Bottom-up) 접근법
- 질의에서 키워드(개체명, 약어, 동의어 등)를 추출합니다.
- 추출된 키워드로 그래프에서 관련 개체를 식별하고, 확장된 개체까지 포함할 수 있습니다.
- 개체에서 시작해 사실을 거쳐 서술과 주제로 확장합니다.
- max_keywords 매개변수로 추출할 키워드 수를 제한하여 관련성을 유지합니다.
서술 재순위화
- 최종 결과 반환 전 서술을 재순위화하여 질의와의 관련성을 높입니다.
- TF-IDF 방식(tfidf)이나 모델 기반 방식(model)을 선택할 수 있습니다.
- max_statements 매개변수로 반환할 서술 개수를 제한하여 컨텍스트 크기를 조절합니다.
복잡 질의 분해
- derive_subqueries 옵션으로 복잡한 질의를 여러 하위 질의로 분해할 수 있습니다.
- max_subqueries 매개변수로 생성할 하위 질의의 최대 개수를 제한합니다.
- 각 하위 질의에 대한 검색 결과를 통합하여 보다 포괄적인 응답을 생성합니다.

TraversalBasedRetriever는 그래프의 구조적 탐색을 통해 직접적인 의미 유사성뿐만 아니라 관계를 통한 관련 정보도 발견할 수 있어, 복잡한 질의에 대한 포괄적인 답변을 제공할 수 있습니다.

2. SemanticGuidedRetriever

SemanticGuidedRetriever는 벡터 검색과 그래프 순회를 통합한 하이브리드 접근법으로, 세 가지 하위 검색기를 활용합니다.

StatementCosineSimilaritySearch
- 서술 임베딩과 질의 임베딩 간 코사인 유사도를 계산합니다.
- top_k 매개변수로 지정된 수의 가장 유사한 서술을 반환합니다.
- 의미적 유사성에 기반한 직접적인 검색 방식으로, 질의와 관련된 정확한 정보를 찾는 데 효과적입니다.
KeywordRankingSearch
- 질의에서 추출한 키워드와 동의어를 활용한 검색을 수행합니다.
- 서술 내 키워드 매칭 수에 따라 순위를 결정하며, 더 많은 키워드가 매칭될수록 높은 순위를 받습니다.
- max_keywords 매개변수로 추출할 키워드 수를 제한하고, top_k로 반환할 결과 수를 제한합니다.
- 직접적인 키워드 매칭을 통해 관련 정보를 찾아내는 데 유용합니다.
SemanticBeamGraphSearch
- 빔 서치 알고리즘을 활용한 그래프 탐색을 수행합니다.
- 서술 간의 공유하는 개체를 기반으로 이웃 서술을 탐색합니다.
- 후보 서술과 질의 간 코사인 유사도를 계산하여 가장 유망한 경로를 따라 탐색합니다.
- max_depth로 탐색 깊이를, beam_width로 각 단계에서 유지할 후보 수를 제한합니다.
- 직접적인 유사성이 낮아도 관계를 통해 관련된 정보를 발견할 수 있습니다.
RerankingBeamGraphSearch
- SemanticBeamGraphSearch의 변형으로, 코사인 유사도 대신 재순위화 모델을 사용합니다.
- BGEReranker(GPU 환경) 또는 SentenceReranker(CPU 환경)를 활용할 수 있습니다.
- 보다 정교한 관련성 평가를 통해 더 정확한 빔 서치를 수행합니다.
- 계산 비용이 높지만 더 정확한 결과를 제공할 수 있습니다.
후처리 옵션
- BGEReranker/SentenceReranker: 모델 기반 재순위화로 최종 결과 품질을 높입니다.
- StatementDiversityPostProcessor: TF-IDF 유사도 기반으로 중복 서술을 제거합니다.
- EnrichSourceDetails: 소스 메타데이터를 추가하여 정보의 출처를 명확히 합니다.
- StatementEnhancementPostProcessor: LLM을 활용해 서술의 내용을 풍부하게 만듭니다.

SemanticGuidedRetriever는 의미적 유사성과 그래프 구조를 모두 활용하여 질의와 직접적으로 유사하지 않더라도 관련된 정보를 효과적으로 발견할 수 있습니다. 특히 복잡한 질의나 다양한 관점이 필요한 경우에 유용합니다.

4.4. 기타

AWS GraphRAG 툴킷은 그래프 구축과 검색 과정에서 분리된 그래프 스토어와 벡터 스토어를 활용하며, AWS의 기존 보안 메커니즘과 통합됩니다.

이중 스토리지 아키텍처
- 그래프 스토어: Amazon Neptune, Neptune Analytics 또는 FalkorDB에 개체, 관계, 서술, 사실 등 그래프 요소 저장
- 벡터 스토어: Amazon OpenSearch Serverless 또는 Neptune Analytics에 청크 및 서술 임베딩 저장
성능 최적화 옵션
- 배치 추출: Amazon Bedrock 배치 추론을 활용한 대규모 데이터셋 처리
- GraphRAGConfig: 작업자 수, 배치 크기, 캐싱 등 시스템 성능 설정
- 응답 캐싱: LLM 호출 결과를 로컬 파일시스템에 저장하여 중복 호출 최소화

AWS GraphRAG 툴킷은 기존 벡터 검색 기반 RAG의 한계를 극복하고, 그래프 구조를 활용해 더 포괄적이고 정확한 정보 검색을 가능하게 합니다. 특히 복잡한 질의, 다단계 추론이 필요한 질의, 또는 문서 간 연결이 중요한 시나리오에서 뛰어난 성능을 발휘합니다.

5. 그래프 RAG 접근법 비교 및 결론

접근법	인덱싱 단계	사전 검색 단계	검색 단계	사후 검색 단계
지식 그래프와 의미 기반 클러스터링	• 지식 그래프 구축		• 그래프 탐색	• 의미적 클러스터링
지식 그래프와 벡터 DB 통합	• 문서 벡터화 • 지식 그래프 구축		• 벡터 검색 • 그래프 탐색
그래프 강화 하이브리드 검색	• 문서 벡터화 • 키워드 색인 • 지식 그래프 구축		• 벡터 검색 • 키워드 검색 • 그래프 탐색	• 리랭킹 또는 랭크 퓨전
지식 그래프 강화 Q&A 파이프라인	• 문서 벡터화 • 지식 그래프 구축		• (청크에 대한) 벡터 검색 • (개체 및 속성에 대한) 그래프 탐색
지식 그래프 기반 질의 확장/생성	• 지식 그래프 구축 • 노드 속성 벡터화	• LLM으로 개체/관계 추출 • 질의 확장	•(개체 및 관계에 대한) 벡터 검색 • 그래프 탐색
RAPTOR	• 문서 벡터화 • 클러스터링 • LLM 기반 요약 • 재귀적 구조화	• 질의 벡터화	• 트리 순회 방식: 계층별 유사도 기반 노드 선택 • 축소 트리 방식: 전체 트리를 단일 계층으로 축소 후 벡터 검색
GraphRAG (Microsoft)	• LLM으로 개체/관계 추출 • 지식 그래프 구축 • 커뮤니티 탐지 (Leiden 알고리즘) • 커뮤니티별 요약 생성	• 질의 확장 (HyDE 기법) • 후속 질문 생성	• 정적/동적 글로벌 검색: 커뮤니티 보고서 활용 • DRIFT 검색: 글로벌+로컬 하이브리드 접근	• 맵-리듀스 기반 통합 • 출력 계층 구조화
GraphRAG Toolkit (AWS)	• LLM으로 명제/개체/관계/주제/서술/사실 추출 • 지식 그래프 구축 • 청크 및 서술 벡터화	• 키워드 추출 • 복잡 질의 분해	• TraversalBasedRetriever: 하향식/상향식 검색 • SemanticGuidedRetriever: 코사인 유사도, 키워드 랭킹, 빔 서치	• 서술 재순위화 • 다양성 처리 • 소스 정보 강화 • 서술 내용 강화

지금까지 살펴본 그래프 RAG 접근법들은 전통적인 벡터 기반 RAG의 한계를 극복하고 더 풍부하고 정확한 정보 검색을 가능하게 합니다. 핵심 인사이트는 다음과 같습니다.

구조적 이점: 모든 접근법에서 공통적으로 그래프 구조가 문서 간 관계를 보존하고 맥락을 유지하는 데 중요한 역할을 합니다. 이는 단순 벡터 유사도만으로 놓칠 수 있는 연관 정보를 발견하는 데 도움이 됩니다.
복합적 검색 전략: 대부분의 접근법이 벡터 검색, 키워드 검색, 그래프 탐색을 결합한 하이브리드 방식을 채택하고 있습니다. 이러한 복합 전략은 각 방식의 장점을 최대화하여 보다 정확하고 포괄적인 정보 검색을 가능하게 합니다.
계층적 구조화: RAPTOR와 MS GraphRAG, AWS GraphRAG 모두 문서를 다양한 추상화 수준으로 계층화하는 방식을 사용합니다. 이를 통해 질의의 복잡성과 요구에 따라 적절한 상세도의 정보를 제공할 수 있습니다.
LLM 활용: 모든 접근법에서 LLM은 단순한 응답 생성 외에도 개체 추출, 요약 생성, 질의 확장 등 다양한 단계에서 활용됩니다. 이는 그래프 구조의 품질과 검색 효율성을 크게 향상시킵니다.
확장성과 효율성: 특히 AWS GraphRAG와 MS GraphRAG는 대규모 데이터셋 처리를 위한 최적화 기능(배치 처리, 자동 튜닝 등)을 제공하여 기업 환경에서의 실용성을 높입니다.

그래프 RAG는 아직 발전 중인 영역이지만, 이미 복잡한 질의에 대한 처리 능력, 다단계 추론 지원, 문서 간 연결성 활용 등에서 기존 RAG 시스템보다 우수한 성능을 보여주고 있습니다. 앞으로는 그래프 구조 생성의 효율성 개선, 다양한 데이터 타입 지원, 실시간 그래프 업데이트 등의 영역에서 더 많은 발전이 이루어질 것으로 예상됩니다.

참조

논문

RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval (Stanford Univ.)
From Local to Global: A Graph RAG Approach to Query-Focused Summarization (Microsoft)

블로그

코드 리포지토리

RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval (Stanford Univ.)
GraphRAG Code, Doc (Microsoft)
Retrieval Augmented Generation (RAG) with Knowledge Graph Using SPARQL (AWS)
GraphRAG Toolkit (AWS)