재료

무슨 재료를 어떻게 쓰나

재료 대조

프로토타입은 이 버스의 지금 좌석에서 시작했다. 새 후보는 이 상황을 먼저 보고, 세 후보만 실시간 좌석을 더한다.

Q. 프로토타입에서 profile과 실시간 좌석은 어디서 만나나?

둘은 학습할 때가 아니라 예보할 때 만난다.

과거 스냅샷은 먼저 profile이 된다. 같은 버스의 두 관측 사이 좌석 차이를 구간 순수요로 놓고, 이를 정류장×30분×평일/주말 셀의 평균 μ와 표준편차 σ로 푼다. 여기서 수요는 승차에서 하차를 뺀 값이다. μ가 음수면 좌석이 늘어나는 구간이다.

화면이 예보를 요청하면 forecast.ts는 remainingSeats를 한 점짜리 좌석 분포로 만든다. 2026-08-05 범계역의 실제 관측 29석이라면 29에 확률 1을 놓는다. 그 뒤 현재 정류장부터 하류 정류장까지 profile의 순수요 분포를 하나씩 적용한다.

다음 좌석 = 지금 좌석 - 그 정류장의 순수요를 확률분포 전체에 반복하는 셈이다. 통장 잔액 29에서 앞으로 나갈 금액을 항목마다 빼는 가계부와 같다. 다만 지출액이 매번 같지 않아 μ·σ로 흔들림까지 흘려보낸다. 실시간 좌석이 -1이면 예보는 빈 배열로 끝난다.

따라서 시작점은 실시간 좌석이고, 정류장마다 빼는 값은 과거 통계다. 같은 차량의 분포를 노선 아래로 계속 옮긴다. 이것이 “이 버스”를 따라간다는 뜻이다.

Q. 새 후보도 profile에서 수요를 꺼내 좌석을 빼나?

아니다. 새 후보 어느 것도 프로토타입의 수요 profile(μ·σ)을 입력으로 받지 않는다.

새 데이터셋의 정답은 한 정류장을 지난 뒤 잔여석이 0이었는가다. 후보는 순수요와 도착 좌석 수를 중간에 복원하지 않고 P(출발 후 만석 | 예측 시점까지의 재료)를 바로 배운다. 사용자에게는 그 반대인 탈 확률을 보여 준다.

프로토타입의 상태는 특정 차량의 잔여석 분포다. 주된 답도 “이 버스가 저 정류장에 갈 때 몇 석 남나”였다. 내부에서 1-P(0석)도 계산했지만 같은 차량 분포에서 파생된 값이다. 새 후보의 상태는 차량 ID 없는 한 시점의 상황이다. 정류장, 시각, 계획 배차, 필요하면 관측된 상류 버스 상태를 넣고 만석 사건의 확률 하나를 낸다.

답의 문법도 갈린다. 프로토타입은 “이 버스 29석”이고 새 후보는 “이 상황 만석 42.0%”다. 29석은 위 실제 차량 관측이다. 42.0%는 코퍼스 validation의 logistic_interactions_raw 한 행에서 나온 실측 예측값 0.420088을 반올림했다.

Q. 후보마다 지금 좌석을 어디까지 보나?

학습과 서빙에는 비대칭이 있다. 출발 후 만석 라벨은 예측 시점 뒤에 생기므로 학습에만 있다. 반대로 서빙의 상류 버스 좌석은 지금 응답에서 얻고, 학습에서는 과거 질의 시점에 저장된 같은 종류의 값으로 맞춘다. 구간 검열의 못 본 중간 통과는 전이 규칙을 배울 때만 쓴다. 서빙 때는 학습된 규칙에 현재 상류 상태와 거리를 넣는다. 보정기는 학습 때 OOF 확률 10,236건·만석 572건으로 눈금을 맞췄고, 서빙 때는 기본 확률만 받는다.

정원과 점유율은 넣지 않는다. 보조 코퍼스의 가명 차량 77대는 외부 정원과 조인이 0대였다. 서빙 응답의 원 vehId로는 정원이 붙는다. 직접 수집분에서는 학습 행 1,345/1,524(88.3%)에도 붙었다. 다만 정원·차종을 추가한 대조에서 네 지표가 한 방향으로 좋아지지 않아 여섯 후보의 공통 특징으로는 두지 않는다. 라벨에도 정원이 필요 없다. crowded도 뺀다. 대상은 노선유형 11인데 공식 제공 대상은 13·15·23이고, 180초 이하 인접 관측 81,147쌍에서 잔여석은 그대로인데 crowded만 바뀐 경우가 0건이었다.

Q. 실시간 좌석 없이 어떻게 AUC가 .96이나 나오나?

정류장과 시간이 이미 만석 위험의 대부분을 가르기 때문이다.

아무것도 안 본 평균은 AUC .5000이었다. 직전 통과 버스 상태만 보면 .7187이었다. 노선×정류장×30분만 보면 .9613이었다. 실시간 좌석을 안 쓰는 세 후보도 경험적 베이즈 .9613, 계층 로지스틱 .9632, GAM .9647을 냈다.

이 수치는 새 정류장을 잘 맞혔다는 뜻이 아니다. validation 10,040행 중 10,038행이 train에서 이미 본 셀이었다. validation 832셀 중 831셀도 겹쳤다. 정류장만 써도 AUC .9336이었고, 같은 셀의 train·validation 만석률 상관은 .9294였다. 같은 노선의 같은 정류장과 시간대가 며칠 뒤에도 비슷한 위험 순서를 보인 것이다.

누수만으로 나온 숫자도 아니다. train 라벨을 1,000번 섞어 같은 셀 조회를 다시 맞추자 AUC 평균은 .4970으로 무너졌다. 대신 범위가 좁다. 새 셀 validation은 2행·만석 0건뿐이다. 새 노선·새 정류장·새 시간대 성적은 아직 재지 못했다.

셀 자체는 강하지만 얇다. train 833셀 중 281셀(33.73%)은 표본 10건 이하고, 719셀(86.31%)은 만석을 한 번도 못 봤다. 그래서 후보들의 실제 차이는 실시간 사용 여부 하나가 아니라 이 얇은 셀을 얼마나 덜 과신하느냐에도 있다.

Q. 실시간 좌석을 쓴 후보는 실제로 얼마나 나았나?

20일 보조 코퍼스의 시간순 validation 10,040건·만석 583건에서 raw AUC를 쟀다. 정류장·시간 기준선 .9613과 비교했다.

실시간을 쓰는 세 후보가 더 높았다. 다만 이 차이 전부를 실시간 좌석의 몫으로 읽으면 안 된다. 로지스틱은 상호작용을, GBM은 나무 구조를 함께 바꿨다. 실시간 특징만 켰다 끈 공통 ablation 성적은 아직 재지 못했다.

구간 검열은 비교가 한 단계 더 가깝다. 같은 경험적 베이즈 셀 위험에 검열 전이와 현재 상류 상태를 섞자 raw AUC가 .0135 올랐고, 군집 bootstrap 95% 구간은 +.0098~+.0176이었다. isotonic 보정 뒤 AUC는 .9751이었다. 층화 기준선과의 paired 차이는 +.0138 [+.0103,+.0179]였다.

GBM .9923은 운영 성적표가 아니라 가용 특징으로 낼 수 있는 상한이다. 직접 수집 validation은 443건·만석 14건이고 날짜가 하루뿐이다. AUC 21쌍 중 16쌍을 못 가려 위 순서가 실제 운영에서도 유지되는지는 아직 모른다.

Q. 그래서 무엇을 얻고 무엇을 잃나?

실시간 좌석을 안 보는 후보는 버스 위치 응답이 비어도 노선·정류장·시각만 있으면 답을 낸다. “그 버스가 안 보여도 이 상황은 평소 얼마나 위험한가”에 답한다. 대신 눈앞의 상류 버스가 지금 0석이라는 사실도 무시한다. 역사적으로 안전한 셀이라면 현재 만석 신호를 보고도 낮은 위험을 낼 수 있다.

실시간 좌석을 보는 후보는 그 반대다. 상류 버스의 0석, 상태, 목표까지 거리를 확률에 반영한다. 버스가 안 보이면 신호가 사라진다. 구간 검열 모형은 이때 경험적 베이즈 셀 확률로 돌아가고, 로지스틱은 존재 표시와 결측 대치를 쓴다. API가 실제 다음 차량을 모두 포착한다는 보장도 없다. 90초 이하 구간에서도 숨은 제3차량 하한은 3330 17.24%, 1650 12.01%였다.

프로토타입은 “이 버스”의 좌석을 앞으로 밀었다. 새 후보는 “이 상황”의 만석 확률을 매겼다. 실시간 미사용형은 끊기지 않는 대신 지금 버스에 둔감하다. 실시간 사용형은 지금을 보지만 관측 누락에 기대고, 아직 직접 만석 검증을 통과하지 못했다.

재료 한눈에

아직 못 써본 것과 그 이유

• 정원·점유율 — 보조 코퍼스 차량과 외부 정원 조인이 0/77이다. 라벨에도 필요 없다. 학습·서빙 공통 특징에서 뺀다.
• crowded — 대상 노선유형은 공식 제공 계약 밖이고, 잔여석과 독립적으로 바뀐 인접쌍이 0/81,147이다.
• 도착 ETA·queryTime 파생값 — 공급자 예측을 다시 배우거나 서로 다른 서버 시계를 경과시간으로 오독하므로 뺀다.

쓰는 재료 70개 — 출처 필드까지

지금은 안 쓰는 재료 4개

• 차량 정원·점유율 — TBBMSVEHINFOM.SEAT_RDNG_PSN_CNT; 점유율 후보식 1-msgBody.busLocationList[].remainSeatCnt/TBBMSVEHINFOM.SEAT_RDNG_PSN_CNT20일 코퍼스 차량키가 plateNo 우선 HMAC이라 외부 정원과 조인된 차량이 0/77이다. 기존 231,048행의 capacity_exact도 모두 0이다. 관측 최대 잔여석은 정원의 하한일 뿐 고정 정원이 아니다. 라벨은 출발 후 좌석이 0인지에 정원이 필요 없다. 프로토타입의 defaultSeatCapacity=80은 분포 배열 상한이며 점유율 분모가 아니다.
• 혼잡도 — GBIS getBusLocationListv2 msgBody.busLocationList[].crowded공식 제공 노선유형은 13·15·23이고 대상 노선은 11이다. 직접 수집분에서 같은 잔여석 값에 다른 코드가 붙은 값이 26개 나와 잔여석만의 전역 함수라는 해석은 반증됐다. 다만 같은 (vehId, remainSeatCnt)에서는 충돌이 0셀이고 crowded만 바뀐 연속쌍도 0건이라 차량별 임계화일 가능성이 남는다. 산식은 미확정이고 아직 특징으로 써 보지 않았다.
• 도착 ETA — GBIS getBusArrivalListv2 msgBody.busArrivalList[].predictTime1, msgBody.busArrivalList[].predictTime2, msgBody.busArrivalList[].predictTimeSec1, msgBody.busArrivalList[].predictTimeSec2; getBusArrivalItemv2 msgBody.busArrivalItem.predictTime1, msgBody.busArrivalItem.predictTime2, msgBody.busArrivalItem.predictTimeSec1, msgBody.busArrivalItem.predictTimeSec2공급자가 만든 예측값을 다시 설명변수로 배우는 구조가 된다. 분·초 필드 관계도 실측 6쌍 중 2쌍에서 맞지 않았다. v1 후보 입력에서 뺐다.
• API queryTime 파생 시간 — GBIS getBusLocationListv2 msgHeader.queryTime; HTTP 응답 헤더 Date같은 노선 연속 38쌍 중 7쌍에서 queryTime이 뒤로 갔다. 직접 수집 92/92건에서는 응답 수신시각보다 미래였고 중앙 +17.265초였다. HTTP Date는 queryTime의 초 절삭과 92/92 일치해 독립 시계가 아니다. 감사 원문만 보존하고 나이·속도·헤드웨이·분할에 쓰지 않는다.

언제 실패하나

• 실시간 미사용 후보는 현재 상류 버스가 만석이어도 역사적 셀 위험만 낸다.
• 실시간 사용 후보는 버스 누락·결측·숨은 차량에 흔들린다.
• 코퍼스 validation의 새 셀은 2행·만석 0건뿐이다. 새 셀 일반화 성적은 아직 없다.
• 직접 수집 validation은 443건·만석 14건이고 날짜가 하루뿐이다. AUC 21쌍 중 16쌍을 못 가려 운영 원천의 후보 순위는 아직 없다.
• 실시간 특징만의 순이득을 분리한 공통 ablation은 아직 없다.

기존 프로토타입과 다른 점

• 프로토타입은 현재 잔여석을 시작점으로 특정 버스의 좌석 분포를 하류로 전파했다.
• 새 후보는 수요 profile(μ·σ)을 쓰지 않고 출발 후 만석 사건을 바로 학습한다.
• 새 후보 셋은 실시간 좌석 없이도 답하고, 나머지 셋만 상류·통과 버스 상태를 더한다.
• 프로토타입의 주된 답은 예상 잔여석 수였다. 새 v1의 유일한 모델 출력은 만석확률 하나다.