← AI 모델과 시스템
심층 리포트DEEPER INTO TECHNOLOGY

Granite 시계열 앙상블: 예측 네 개를 평균내면 놓치는 것

Granite의 네 시계열 예측을 어떻게 합쳐야 모델 간 의견 차이를 보존하고 발주량 판단에 활용할 수 있을까?

댓글 남기기 ↓
먼저 읽는 핵심

여러 모델이 낸 중앙값을 평균내면 서로 얼마나 다르게 예측했는지가 사라질 수 있다. Granite Timeseries Ensemble은 분위수 값들을 모아 다시 분위수를 구하는 방식을 기본으로 쓴다. 이 차이는 다음 날 수요의 중앙값보다 부족 가능성까지 고려해 주문해야 하는 업무에서 중요하다.

네 예측을 하나로 만들기 전에 정할 질문

내일 필요한 부품 수를 네 모델에 물었다고 하자. 두 모델은 80개에서 90개 안팎, 나머지 둘은 140개 안팎을 예상한다. 중앙값을 평균내면 114개쯤으로 정리할 수 있다. 그러나 담당자가 알아야 하는 것은 평균 하나만이 아니다. 모델들이 114개 근처에 동의한 것인지, 낮은 수요와 높은 수요로 갈린 것인지에 따라 발주 판단이 달라진다.

IBM Research가 2026년 10월 22일 소개한 Granite Timeseries Ensemble은 네 사전학습 시계열 모델의 출력을 결합하는 레시피다. 합쳐진 새 가중치 파일을 배포하는 방식은 아니다. 모델별 예측을 얻은 뒤 결합하므로, 시작할 때 어느 단일 모델이 내 데이터에 맞을지 하나로 결정하는 부담을 줄인다. IBM Research 발표

이 글은 11월 2일 확인한 공식 자료와 집계 코드의 분석이다. 아래 숫자는 직접 만든 가상 수요로 계산했다. Granite 체크포인트를 실행하거나 실제 재고 비용을 측정하지 않았다. 독자가 얻을 결과는 결합 방식이 발주량을 바꾸는 이유와 자신의 데이터로 비교할 평가표다.

모델을 합치는 게 아니라 예측 출력을 합친다

기본 레시피에는 PatchTST-FM-r1, PatchTST-FM-r2, FlowState-r1.1, TTM-r3가 들어간다. 서로 다른 구조의 예측기를 같은 출력 인터페이스에 연결한다. 기본 출력은 0.1부터 0.9까지 아홉 분위수이며, 0.5 분위수를 점 예측값으로 사용한다. 고정 버전의 기본 설정

분위수는 예측 분포에서 위치를 가리키는 값이다. p50은 중앙값, p90은 분포상 90% 위치다. 예를 들어 p90이 145개라면 그 예측 분포는 수요가 그 이하일 확률을 약 90%로 표현한다. 실제로 열 번 중 아홉 번 맞았다는 관측 결과와는 다르다. 실제 빈도와 맞는지는 뒤에서 별도로 확인해야 한다.

이 구조에서는 네 모델의 가중치를 평균내거나 새 모델을 재학습하지 않는다. 예측 시점마다 나온 수치들을 합친다. 따라서 이미 단일 예측기를 쓰는 팀이라면 기존 출력과 앙상블 출력을 같은 시점·같은 기간에서 비교할 수 있다. 반면 입력 데이터의 누락, 상품 단위, 예측 기간이 서로 다르면 결합 전에 그 차이부터 해결해야 한다.

p90 네 개의 평균과 36개 값의 p90은 다르다

공식 기본 방식인 linear_pool은 각 모델의 아홉 분위수, 총 36개 값을 모은 뒤 원하는 분위수를 다시 구한다. 확인한 코드의 가중치 없는 경로는 이 배열에 np.quantile을 적용한다. 아래 계산은 그 정렬·선형 보간 규칙을 Python 표준 라이브러리로 따로 구현했다. 집계 구현의 고정 커밋

다음은 특정 모델을 흉내 낸 성능 데이터가 아니라 같은 부품의 다음 날 수요에 대한 가상 예측이다. A부터 D까지는 실제 Granite 모델 이름과 대응하지 않는다. 각 행은 p10부터 p90까지 아홉 값을 갖는다.

가상 예측기 아홉 분위수 값 p50
A 80, 81, 82, 83, 84, 85, 86, 87, 88 84
B 84, 85, 86, 87, 88, 89, 90, 91, 92 88
C 136, 137, 138, 139, 140, 141, 142, 143, 144 140
D 140, 141, 142, 143, 144, 145, 146, 147, 148 144

같은 분위수끼리 평균내면 p10은 (80 + 84 + 136 + 140) / 4 = 110, p90은 (88 + 92 + 144 + 148) / 4 = 118이다. 낮은 쪽과 높은 쪽이 중간에서 만나 폭이 좁아졌다.

반면 36개 값을 모으면 낮은 집단과 높은 집단이 그대로 남는다. 정렬한 배열의 p90 위치는 0부터 센 인덱스 (36 - 1) × 0.9 = 31.5다. 31번 값 144와 32번 값 145의 중간인 144.5가 된다. 이는 이번 예제의 경험적 분위수 보간 규칙이며 모든 통계 도구가 항상 같은 보간 규칙을 쓰는 것은 아니다.

결합 방식 p10 p50 p90
같은 분위수의 산술평균 110 114 118
36개 값을 모은 기본 풀 방식 83.5 114 144.5

두 방법의 중앙값은 114로 같다. 중앙값 오차만 비교하면 예측 폭의 차이를 놓칠 수 있다는 뜻이다. 그렇다고 풀 방식이 언제나 정확한 것은 아니다. 높은 쪽 두 모델이 같은 잘못된 가정을 공유했다면 넓은 구간도 잘못될 수 있다. 네 모델이 모두 같은 100개라는 점 예측만 내놓는 반례에서는 이 예제의 두 결과가 모두 100이다.

낮은 수요와 높은 수요로 갈린 가상 예측을 평균하면 좁은 중간 구간이 되고, 풀 방식은 넓은 구간을 남기는 설명도

직접 계산한 가상 값의 설명도다. 실제 모델 응답이나 정확도 비교가 아니다. 중앙값이 같아도 p10·p90과 의견 차이는 달라진다.

또한 아홉 분위수는 연속 분포 전체가 아니다. 이 구현은 제공된 값들을 이산적으로 모으므로, 완전한 누적분포함수(CDF)를 정확하게 적분한 결과로 읽으면 안 된다. 입력 분위수 간격이나 보간 규칙을 바꾸면 값도 달라질 수 있다. 이 글은 공식 기본 설정의 균등한 아홉 수준에 범위를 한정한다.

118개와 145개 주문 중 어느 쪽이 나을까

담당자가 부족을 줄이기 위해 p90을 발주 기준으로 정했다고 가정하자. 보유 재고는 없고, 한 개 단위로 주문하며, 예측 대상인 다음 날에 입고되어 바로 쓸 수 있다고 놓는다. 소수는 올림한다. 이 규칙에서 단순 평균은 118개, 풀 방식은 145개 주문으로 이어진다.

다음 표도 가상으로 정한 두 수요 시나리오의 산술이다. 어느 수요가 더 자주 일어나는지는 알 수 없다.

나중에 확인된 수요라는 가정 118개 주문 145개 주문
90개 28개 남음 55개 남음
145개 27개 부족 잔여·부족 없음

넓어진 예측이 높은 수요에 대비하는 데 도움이 되는 대신, 낮은 수요에서는 재고를 더 남길 수 있다. 그래서 “p90이 더 높다”를 “좋은 예측이다”로 바꿔 말할 수 없다. 재고 비용, 품절 영향, 납기, 최소 주문량이 달라지면 선택할 분위수와 주문 규칙도 달라진다. p90은 IBM이 모든 발주 업무에 권장한 값이 아니라 이 사례가 정한 정책이다.

납기가 일주일이라면 다음 날 수요 p90을 그대로 발주에 쓰면 안 된다. 필요한 것은 납기 동안의 수요와 현재 재고·입고 예정량을 반영한 판단이다. 일별 p90을 더한 값도 주간 합계의 p90이라고 보장되지 않는다. 날짜별 수요가 함께 오르거나 내리는 관계가 합계 분포에 영향을 주기 때문이다. 예측기의 출력 기간과 업무의 결정 기간을 먼저 맞춘다.

이처럼 값을 얻는 일과 업무 결정을 내리는 일은 분리된다. 문서에서 읽은 값·계산·미래 추정이 섞인 상황은 Clairic의 값 출처 구분과 이어서 볼 수 있다.

IQR 방식은 무엇을 더 믿는가

다른 레시피인 iqr_weighted는 예측 구간이 좁은 모델에 더 큰 비중을 준다. 보통 IQR은 p75와 p25의 차이를 뜻한다. 다만 기본 아홉 분위수에는 이 두 수준이 없어서, 확인한 구현은 p80과 p20의 차이를 쓴다. 정확한 25·75 분위수가 있으면 그 값을 사용한다. 구간 선택과 가중치 코드

이 폭의 역수에 온도 조절과 정규화를 적용해 비중을 구하고, 대응하는 분위수를 가중 평균한다. 필요하면 한 모델의 비중에 상한을 둘 수 있다. 과거 정답을 얼마나 잘 맞혔는지 학습한 가중치가 아니라 지금 출력한 폭을 이용한 가중치라는 점이 선택의 핵심이다.

좁은 구간이 유익할 때도 있다. 안정적인 수요에서 잘 맞는 모델이 다른 모델보다 일관되게 좁은 구간을 내놓는다면 검토할 이유가 있다. 그러나 행사 수요를 놓친 모델이 평소 수요 주변에 아주 좁은 구간을 내놓을 수도 있다. 그때 좁음은 정확성이 아니라 과신이다. 위 가상 A와 B의 좁은 구간만 보고 이들이 C·D보다 더 믿을 만하다고 말할 근거는 없다.

구간이 뒤집히지 않도록 정렬 관계를 보정하는 처리 역시 정확도 보증은 아니다. p10이 p90보다 큰 모순을 없애는 것과 실제 수요가 예측 구간에 잘 들어오는 것은 다른 검사다. 예측 분포를 결합한다고 보정(calibration)이 자동으로 유지되는 것은 아니라는 점은 Gneiting·Ranjan의 예측 분포 결합 연구에서도 다룬다.

공식 성적표가 말해 주는 범위

공식 발표는 2026년 10월 20일 GIFT-Eval 스냅샷의 97개 데이터 구성을 비교한다. 아래는 공급자가 공개한 값이며 이 글에서 재실행한 성적이 아니다. 계절 나이브 기준으로 정규화한 뒤 구성별 점수를 기하평균한 집계다. 두 열 모두 낮을수록 좋다. 공식 비교 표

예측기 점 예측 오차 MASE 확률 예측 점수 CRPS/MWQL
기본 Probabilistic Ensemble 0.683 0.471
IQR Ensemble 0.684 0.471
단일 PatchTST-FM-r2 0.685 0.467

MASE에서는 기본 앙상블이 낮지만, 확률 예측 점수에서는 이 단일 모델이 낮다. 순위 평균과 오차 집계도 서로 다른 기준이다. 따라서 “여러 개를 합치면 모든 지표에서 이긴다”는 결론은 이 표가 뒷받침하지 않는다. 상품별·예측 기간별 성능과 구간의 실제 포함률도 집계표만으로 알 수 없다.

현재 레시피는 다변량 채널을 독립적으로 예측하며 채널 간 정보를 사용하지 않는다. 네 체크포인트를 불러오는 비용도 남는다. 여러 상품 열을 넣었다고 대체 상품의 매출 이동까지 공동으로 모델링했다고 해석하면 안 된다. 확장 레시피는 별도 라이선스 조건의 모델을 추가할 수 있으므로 기본 구성과 구별해야 한다. 모델 카드의 범위와 제약

실제 데이터로 비교할 때 남길 표

우선 현재 쓰는 단순 예측과 단일 모델을 기준선으로 남긴다. 앙상블 두 방식만 비교하면 복잡한 구성이 단순한 기준보다 나은지 알 수 없다. 다음은 부품 수요 업무에 적용할 미실행 평가 설계다.

평가 항목 같은 조건으로 비교할 것 판단에 쓸 기록
예측 시점 매주 정한 날짜까지 당시 알 수 있던 자료만 입력 입력 마감·당시 알려진 행사·예측 기간
중심값 같은 상품·같은 날짜의 실제 수요와 p50 오차와 상품별 실패, 기준선 대비 차이
예측 구간 p10부터 p90까지의 구간과 이후 실제값 포함 건수/전체 건수, 평균 폭, 부족 방향의 이탈
발주 정책 같은 재고·납기·최소 주문량 규칙 잔여·부족 수량과 각각의 업무 비용
실행 비용 같은 장치·입력 길이·예측 기간 완료 시간·메모리·성공한 모델 수

시간 순서를 지키는 것이 중요하다. 9월까지 자료로 10월 첫 주를 예측한 다음, 시점을 한 주 옮겨 다시 예측하는 식으로 평가 창을 만든다. 어느 방법을 쓸지 선택한 기간과 마지막으로 확인할 기간은 구분한다. 10월 실제 수요를 보고 가중치나 발주 기준을 고른 뒤 같은 10월을 최종 성적이라고 제시하면 선택에 사용한 정보를 다시 평가하는 셈이다.

원자료가 매출이라면 품절일도 살펴야 한다. 판매가 0이었다고 수요도 0이었다고 단정할 수 없다. 예측 정답을 무엇으로 삼는지 잘못 정하면 결합 규칙을 정교하게 비교해도 업무 판단이 빗나간다. 이는 본문의 발주 사례에서 추가로 확인할 데이터 조건이다.

가령 명목상 80% 구간을 10건 만들었는데 실제값이 6건 들어왔다면 포함률은 6 / 10 = 60%다. 이것은 계산 설명용 가정이며 Granite의 성적이 아니다. 열 건이라는 작은 표본만으로 영구적인 보정 실패를 확정할 수도 없다. 상품·기간별로 표본 수와 폭을 함께 보아야 지나치게 넓은 구간으로 포함률만 높이는 경우를 구별할 수 있다.

마지막으로 모델 수를 확인한다. 읽어 본 공식 실행 코드에서는 일부 멤버가 실패하면 경고를 남기고 남은 예측으로 계속할 수 있다. 결과가 반환됐어도 네 모델 모두 성공한 레시피와 같다고 볼 수 없다. 비교표에는 실제 참여 수와 실패를 기록해야 한다. 멤버 실행·실패 처리

계산을 다시 해 보고 첫 비교를 정한다

가상 분위수 계산 Python과 실행 결과 JSON을 제공한다. Python 3 표준 라이브러리만 사용한다. 파일을 내려받아 같은 폴더에서 다음 명령을 실행하면 위 표와 발주 시나리오를 다시 계산한다.

python3 granite-quantile-pooling-lab.py

제공하는 실행 결과 JSON은 Python 3.14.5에서 생성했다. 정상 계산 외에 멤버 누락·뒤집힌 분위수·유효하지 않은 수치 입력을 거부하고 정상 입력으로 돌아오는 것을 확인했다. 이 예제는 비교 조건을 고정하려고 네 입력을 모두 요구한다. 앞서 설명한 공식 라이브러리의 실패 처리와는 다른 자체 예제 정책이다. 모델 설치나 추론 속도를 시험한 자료는 아니다.

처음 도입한다면 하나의 상품군과 한 예측 기간을 정해 단순 기준선·단일 모델·기본 풀을 같은 창에서 비교할 수 있다. 구간 폭이 유용한 신호인지 확인한 뒤 IQR도 추가한다. 최종 선택은 중앙값 순위 하나보다 실제 부족·잔여와 운영 비용에 맞춘다. 결과가 같고 단일 모델이 충분히 빠르다면 네 모델을 계속 운영할 이유가 약해질 수 있다.

이 글의 계산표와 평가표는 상단 저장 기능으로 다시 찾을 수 있다. 다른 AI 출력의 비교 기준은 AI 시스템 모음, 평가 설정에 따른 판단 변화는 AI 심사자의 프롬프트별 판정 비교로 이어 읽을 수 있다. 새 분석을 받아보려면 RSS를 이용하면 된다.

다시 읽을 때의 기준
  • 같은 분위수끼리 평균내는 것과 모든 분위수 값을 모아 다시 분위수를 구하는 것은 다르다. 모델 간 의견 차이가 예측 폭에 반영되는 방식도 달라진다.
  • IQR 방식은 좁은 구간을 내는 모델에 더 큰 비중을 준다. 좁은 구간 자체가 정확성이나 신뢰도의 증거는 아니다.
  • 실제 도입은 단일 모델·앙상블을 같은 과거 예측 시점에서 비교하고, 점오차·구간 포함률·재고 부족·실행 비용을 나누어 판단한다.
SOURCES & CONTEXT

근거와 원자료

자료의 발행 시점과 이번 글에서 참고한 범위를 함께 기록합니다.

  1. Ensemble forecasting with IBM Granite time-series models ↗IBM Research · 2026

    October22 announcement; October20 supplier GIFT-Eval snapshot,97 configurations; no independent inference benchmark. Actual body and comparison anchor verified.

  2. Granite Timeseries Ensemble R1 model card ↗IBM Granite · 2026

    Pinned model card 90a45c945c731e27b3a3578119ad0406faf5d39f; default/expanded recipe scope, independent channels, member cost/licensing and calibration limitations. Model not run.

  3. Granite Timeseries Ensemble R1 default configuration ↗IBM Granite · 2026

    Pinned four-member default; linear_pool, nine quantile levels, null weights. Recipe pin alone does not pin all runtime model files.

  4. Granite TSFM ensemble aggregation implementation ↗IBM Granite · 2026

    Code read at 5991892635904a1ef01d19dd63375fa577524c05: flatten and np.quantile unweighted path, IQR q20/q80 default, softmax and isotonic handling. Own stdlib arithmetic mirrors unweighted rule; full package not executed.

  5. QuantileEnsembleForecaster member execution ↗IBM Granite · 2026

    Member failures logged/skipped; all failed raises. Code inspection only, not a fault injection test of Granite runtime.

  6. Combining Predictive Distributions ↗Tilmann Gneiting · Roopesh Ranjan · 2013

    General theory of forecast combination and calibration; no claim that product implementation satisfies all theorem assumptions. Public full text read.

갱신 기록

첫 원고. 공식 레시피와 집계 코드를 고정해 읽고 자체 가상 분위수·발주 계산을 실행했다. Granite 추론과 실제 수요 예측 성능은 측정하지 않았다.

오류를 발견했다면 댓글로 알려 주세요 →
S
Starhunter

테크독해 운영·편집. AI·IT의 개념과 기술을 연결해 읽습니다.

QUESTIONS & DISCUSSION

이 글에 댓글 남기기

댓글 공개 방식을 확인하고 있습니다. 개인정보나 비밀 값은 적지 마세요.

댓글을 불러오는 중입니다.

    새 댓글

    8자 이상. 비밀번호를 잊으면 직접 수정·삭제할 수 없습니다. 다른 서비스와 다른 비밀번호를 사용해 주세요.

    내 댓글 확인·수정·삭제

    등록 후 안내된 댓글 번호와 비밀번호를 입력하세요. 승인 대기 중인 댓글도 확인할 수 있습니다.