LLM 캐스케이드가 기반으로 하는 앙상블 이론을 위반하는 이유

요약 — 캐스케이드(Cascades), 라우터(routers), 모델 혼합(model mixtures)은 고전적인 앙상블 이론에서 설계 논리를 차용합니다. 이 이론이 효과를 발휘하려면 포함된 모델들이 서로 다른 입력에 대해 각기 다른 이유로 실패해야 합니다. 하지만 유사한 명령어 튜닝 방식과 중첩되는 웹 규모 코퍼스로 학습된 LLM들은 같은 입력에 대해 같은 이유로 실패하는 경향이 있어, 저가 계층의 신뢰도 신호가 고가 계층의 정확도와 상관관계를 갖지 못할 때가 많습니다. 해결책은 더 나은 신뢰도 임계값(confidence thresholds)을 설정하는 것이 아니라, 비용의 다양성뿐만 아니라 실패가 발생하는 구조적 다양성을 고려하여 아키텍처를 설계하는 것입니다.

캐스케이드는 현재 프로덕션 LLM 시스템 어디에나 존재합니다. 저렴한 모델이 첫 번째 처리를 합니다. 만약 이 모델이 자신감이 있다면, 그 답변을 내보냅니다. 그렇지 않다면, 더 크고 느린 무언가로 에스컬레이션(escalate)시킵니다. 라우터는 유사하게 초기 단계에서 작동하며, 생성(generation)이 발생하기 전에 쿼리를 적절한 크기의 모델로 보냅니다. 혼합 방식(Mixtures) — 토큰 레벨의 MoE(Mixture of Experts)이든 별도의 모델들이 답변에 대해 투표하는 앙상블이든 — 신뢰도에 따라 분할하는 것이 아니라 전문화에 따라 작업을 분할합니다. 이 세 가지 패턴 모두 같은 방식으로 판매됩니다: 비용 절감, 품질 유지.

그 제안은 고전적인 앙상블 이론에서 거의 단어 하나 틀리지 않고 차용된 것입니다. 배깅(Bagging), 부스팅(Boosting), 스택드 일반화(stacked generalization) — 이 전체 분야는 LLM 캐스케이드를 구축하는 사람들이 잘 언급하지 않는 하나의 수학적 요구 사항에 의존합니다: 구성 요소들의 오류가 적어도 부분적으로 비상관(decorrelated)이어야 한다는 것입니다. 만약 두 모델이 같은 입력에 대해 같은 이유로 틀린다면, 그것들을 결합한다고 해서 아무것도 얻지 못합니다. 단지 두 번 잘못될 수 있는 값비싼 방법을 구축한 것일 뿐입니다.

고전적인 앙상블이 실제로 요구하는 것

랜덤 포레스트(Random Forest)의 경우, 각 트리는 서로 다른 부트스트랩 샘플(bootstrap sample)과 서로 다른 무작위 특징 부분집합(random subset of features)을 봅니다. 이 트리들은 의도적으로 동일한 정보에 접근할 수 없게 했기 때문에 서로 의견이 다릅니다. 바로 그 강제된 다양성(forced diversity)이 전체 메커니즘입니다. 부스팅(Boosting)은 다르게 작동하지만 다른 각도에서 같은 요구사항을 충족합니다. 즉, 새로운 학습자(learner)는 이전 학습자의 잔차 오차(residual errors)를 수정하도록 명시적으로 훈련되며, 이는 그 오차가 다음 모델이 이미 공유하고 있는 구조가 아닌, 활용 가능한 구조여야만 작동합니다.

하지만 이러한 메커니즘은 일반적인 LLM 캐스케이드에서는 존재하지 않습니다. 비용 계층화 시스템(cost-tiered system)에서 사용되는 소형 모델과 대형 모델은 보통 같은 계열(family)에 속하며, 중복되는 사전 훈련 데이터(overlapping pretraining data)로 훈련되고, 유사한 RLHF 또는 DPO 레시피로 정렬되며, 동일하거나 밀접하게 관련된 어휘(vocabulary)로 토큰화됩니다. 이들은 서로 다른 가설 공간(hypothesis space)에서 독립적으로 추출된 것이 아닙니다. 오히려 매개변수 수와 훈련 컴퓨팅만 다를 뿐, 같은 가설 공간 내의 매우 밀접한 지점들입니다.

캐스케이드가 무너지는 지점

캐스케이드의 전체적인 가치 제안(value proposition)은 한 가지에 달려 있습니다. 즉, 저렴한 모델이 틀렸을 때, 자신이 틀렸다는 것을 알아야 상위 단계로 에스컬레이션(escalates)할 수 있다는 것입니다. 이 신뢰도 또는 불확실성 신호—토큰 수준의 로그 확률(token-level logprobs), 샘플 전반의 자기 일관성(self-consistency across samples), 보조 분류기(secondary classifier)로부터 얻은 보정된 점수—가 누가 쉬운 트래픽을 받고 누가 비싼 트래픽을 받을지 결정하는 실제 작업을 수행합니다.

문제가 되는 실패 사례는 '저가 모델이 틀렸지만 확신하는 경우'가 아닙니다. 이는 이미 알려진 문제이며 대부분의 팀은 이를 완화할 방안을 가지고 있습니다. 실제로 아키텍처를 무너뜨리는 실패 사례는 '저가 모델이 틀리고 확신하며, 고가 모델 역시 구조적으로 동일한 이유로 틀린 경우'입니다. 훈련 데이터에서 과소 대표된 희귀 개체(rare entity)가 작은 모델과 큰 모델 모두를 어렵게 만듭니다. 왜냐하면 두 모델 모두 실질적으로 같은 웹 크롤링 데이터를 기반으로 훈련되었기 때문입니다. 특정 토큰 수준의 모호성에 의존하는 추론 함정은 두 모델 모두에 영향을 미칩니다. 이는 두 모델이 토크나이저(tokenizer)를 공유하기 때문입니다. 틈새 도메인에서의 사실적 격차는 양쪽 계층 모두에서 나타납니다. 왜냐하면 어느 모델의 사전 학습 혼합물도 다른 쪽보다 해당 도메인을 더 잘 다루지 못했기 때문입니다.

이러한 경우, 에스컬레이션(escalation)은 도움이 되지 않습니다. 큰 모델에 대한 지연 시간 및 비용 프리미엄을 지불하고 동일하게 틀린 답변만 받게 되며, 단지 표현 방식만 더 유창할 뿐입니다. 캐스케이드가 실패한 이유는 신뢰도 임계값(confidence threshold)이 잘못 조정되었기 때문이 아닙니다. 두 계층 자체가 에스컬레이션이 의미 있는 교정 단계가 될 만큼 통계적으로 독립적이지 않았기 때문에 실패한 것입니다.

라우터 역시 한 단계 앞선 곳에서 같은 사각지대를 가짐

모델 라우터(Model routers)는 생성 전에 쿼리를 분류하여 이를 해결하려고 시도합니다. 즉, 코딩 질문은 코드 전용 모델로, 간단한 조회는 작은 모델로, 개방형 추론은 최첨단 모델(frontier model)로 경로를 지정하는 방식입니다. 이는 상관관계 오류 문제(correlated-error problem)를 우회하는 것처럼 보이지만, 라우터 자체도 일반적으로 자신이 연결하는 모델들과 동일한 종류의 분포 가정(distribution assumptions)을 기반으로 훈련된 모델입니다. 만약 라우터가 특정 입력 클래스에 대한 쿼리 난이도를 잘못 판단한다면, 이는 종종 다운스트림 모델(downstream model)이 해당 입력과 어려움을 겪는 것과 같은 이유로 잘못 판단하는 것입니다. 즉, 모호한 표현 방식, 도메인의 희귀성, 다단계의 암묵적 추론입니다. 라우터의 사각지대와 목적지 모델의 사각지대는 독립적인 사건이 아니며, 둘 다가 훈련된 근본적인 데이터 분포에서 공통의 근원 원인(root cause)을 공유하는 경우가 많습니다.

혼합(Mixtures)은 다른 메커니즘이지만, 비슷한 함정에 빠진다

토큰 레벨의 Mixture-of-Experts (MoE) 모델은 전문가들(experts)이 하나의 모델 내에서 공동으로 훈련되고 게이팅(gating) 과정이 엔드투엔드로 학습되어 단순히 기대되는 것이 아니라 실제 전문화(specialization)를 만들어내기 때문에, 이 문제의 일부를 우회합니다. 이것은 구조적으로 건전한 다양성 메커니즘이며, 캐스케이드(cascade) 사례보다는 랜덤 포레스트(random forest) 사례에 가깝습니다.

하지만 여러 개의 독립적으로 훈련된 LLM들을 모아 투표하거나 심판 모델이 통합하는 방식인 Mixture-of-models는 다시 상관관계 오류 함정(correlated-error trap)에 빠지며, 종종 캐스케이드보다 더 나쁩니다. 만약 유사한 훈련 계보를 가진 세 개의 모델이 모두 투표하고, 그 세 개가 모두 사각지대(blind spot)를 공유한다면, 다수결 투표는 오류를 잡아내지 못합니다. 오히려 이를 합법화시킵니다. 세 모델 중 두 개가 동의한 잘못된 답변은 독립적으로 존재했을 때보다 더 신뢰할 수 있게 보이는데, 이는 시스템이 동의를 독립적인 검증으로 오해했기 때문입니다.

비용 다양성(Cost Diversity)이 아닌 구조적 다양성을 설계하기

실질적인 해결책은 더 나은 신뢰도 보정 곡선(confidence calibration curve)을 만드는 것이 아닙니다. 그것은 확인하려는 대상과 구조적으로 다른 에스컬레이션 및 검증 경로를 선택하는 것입니다. 단순히 크기만 큰 버전이 되는 것을 의미하지 않습니다.

오히려 오류를 분리(decorrelate)하는 몇 가지 패턴이 있습니다. 언어 모델 자체가 아닌 검증기(verifier)로 라우팅하는 것입니다 — 소스 문서에 대한 검색 기반 접지(retrieval grounding), 생성된 코드를 실행하고 출력을 확인하는 코드 실행 샌드박스, 구조화된 출력에 대한 규칙 기반 검증기 등이 있습니다. 이들은 생성기(generator)와는 다른 이유로 실패하기 때문에 동일한 예측 문제를 동일한 학습 데이터로 해결하지 않습니다. 만약 또 다른 LLM을 검사 목적으로 사용해야 한다면, 같은 연구소에서 동일한 파이프라인을 사용하는 더 큰 모델보다는 근본적으로 다른 조직에 의해 의미 있게 다른 데이터 혼합으로 훈련된 모델을 선호하십시오. 그리고 에스컬레이션 트리거를 구축할 때는 일반적인 벤치마크 정확도(benchmark accuracy)가 아닌, 공유될 것으로 예상되는 실패 클래스 — 희귀 엔티티, 모호한 토큰화, 도메인 격차(domain gaps) — 에 대해 구체적으로 테스트해야 합니다. 그렇지 않으면 문제가 발생하기 직전까지는 괜찮아 보일 것입니다.

이 모든 것이 캐스케이드(cascades), 라우터(routers), 그리고 혼합(mixtures) 패턴이 잘못되었다는 의미는 아닙니다. 이것들은 올바른 패턴이며, 대부분의 팀이 확인하지 않는 전제조건을 가진 이론에서 차용한 것입니다. 당길 가치가 있는 레버는 신뢰도 임계값이나 비용 계층이 아닙니다. 그것은 시스템 내 구성 요소들이 실제로 서로 다르게 실패하는지 여부입니다. 만약 그렇지 않다면, 당신은 안전망을 구축한 것이 아닙니다. 더 나은 제작 품질(production values)으로 동일한 실수를 반복하는 더 비싼 방법을 구축했을 뿐입니다.