후보 모델

한계 재보기

Gradient boosting

허용된 재료의 최고 기록만 재는 비운영 비교자다.

1. Q. 정류장·시간만 봐도 AUC .9613인데, 왜 더 복잡하게 보나?

노선×정류장×30분 셀은 833개다. 이 중 281개(33.73%)는 학습 표본이 10건 이하다. 719개(86.31%)는 만석을 한 번도 못 봤다. 셀 비율만으로는 얇은 칸을 0% 위험으로 굳히기 쉽다.

Gradient boosting에는 허용된 신호를 한꺼번에 넣었다. 위치와 시간뿐 아니라 앞선 버스의 절대 잔여석, 직전 통과, 헤드웨이 구간, 노선 전체 좌석 분포까지 준다. 목적은 배포가 아니다. 다른 운영 후보가 놓친 신호가 얼마나 남았는지 잰다.

오픈북 모의고사와 같다. 허용된 재료는 다 펼치지만, 그 답안지를 운영안으로 내지는 않는다.

보조 코퍼스의 시간순 검증 10,040건 중 만석은 583건이었다. isotonic 보정 뒤 이 모델은 Brier .0155, log loss .0524, AUC .9910을 냈다. 잠정 운영 후보인 구간 검열 모형은 .0268, .0878, .9751이었다. 차이는 남았다. 직접 수집분 validation 443건·만석 14건에서는 이 모델이 Brier .0144, log loss .0731, AUC .9595, 구간 검열이 .0244, .0987, .9093이었다. 다만 두 모델의 차이는 이 표본으로 가리지 못한다. train과 validation이 같은 날짜라 isotonic 보정 fold가 없었고 양쪽 예측 모두 raw다.

여기서 상한은 수학적 한계가 아니다. 이번 재료, 이번 구현, 이번 검증에서 찍힌 참조 기록이다.

2. 원리

Q. 나무 한 그루는 무엇을 하나?

한 그루는 짧은 예·아니오 질문을 이어 붙인다.

• 상류 버스 잔여석이 1.5석 이하인가?
• 정류장 순번이 64 이하인가?
• 직전 통과 버스가 만석이었나?
• 지금 시각이 학습된 경계보다 이른가?

질문을 통과한 행들은 같은 잎에 모인다. 잎에는 만석 여부를 바로 적지 않는다. 현재 점수를 올리거나 내릴 보정값을 적는다. 숫자 결측은 억지로 0이나 평균으로 채우지 않는다. 나무가 결측을 어느 쪽으로 보낼지도 학습한다.

Q. 왜 한 그루로 끝내지 않나?

첫 나무가 크게 틀린 행을 다음 나무가 다시 본다. 그다음 나무도 남은 오차를 본다. 이 구현은 log loss를 줄이는 작은 나무 250개를 순서대로 더한다.

마지막에는 p_full = 1 / (1 + exp(-F_250))로 만석확률을 만든다. 250개 나무의 다수결이 아니다. 앞선 답을 뒤 나무가 조금씩 고치는 누적 계산이다. 조기 종료는 쓰지 않았다. 250개를 끝까지 더했다.

Q. 얇은 셀은 어떻게 다루나?

정류장×시간 셀을 따로 외우는 규칙은 없다. 대신 한 잎에 최소 30건이 들어가야 한다. 나무 한 그루의 잎은 최대 63개다. 잎 보정값에는 L2 10을 건다. 얇은 셀 하나만으로 잎을 만들지 못하고, 같은 갈림길을 지난 다른 정류장·시각과 묶인다.

이것이 boosting식 풀링이다. 누구와 묶을지 미리 정하지 않고 잔여석·위치·시간의 경계로 정한다. 다만 나무 250개의 잎을 겹치면 최종 구역은 30건보다 훨씬 얇아질 수 있다. 규제가 있어도 운영 모델로 바로 쓰지 않는 이유다.

3. Q. 실제 한 건은 어떻게 흘렀나?

아래 사례는 직접 수집분이 아니라 보조 코퍼스의 검증행이다.

학습분의 만석은 705/12,065건이었다. 시작 log-odds는 ln(705/11,360) = -2.7797, 만석확률은 .0584다.

첫 나무에서 이 행은 상류 잔여석 0 ≤ 1.5, 정류장 순번 55 ≤ 64를 차례로 통과했다. 학습률을 반영한 잎 보정값은 +.5084였다.

250개 잎 보정값의 합은 +5.1104였다. 최종 점수는 2.3307, raw 만석확률은 .9114가 됐다. 나무가 늘수록 확률이 한 방향으로만 움직이지는 않는다. 150개 뒤 .9365에서 마지막에는 .9114로 내려왔다.

train 내부 시간순 OOF 10,236건 중 만석 572건으로 맞춘 58개 임계점의 isotonic 보정기가 .9114를 .8577로 바꿨다. 실제 출발은 만석이었다. 한 건을 맞힌 사례일 뿐, 이 한 줄이 성능 증거는 아니다.

4. Q. 무엇을 넣고, 무엇을 뺐나?

최종 입력은 46열이다. 문자열은 노선과 원천 표시만 숫자로 바꿨다. 원천별로 따로 적합하므로 원천 표시는 한 적합 안에서 변별력이 없다.

안 넣은 재료도 명확하다.

5. 그림 명세

6. Q. 언제 무너지고, 프로토타입과 무엇이 다른가?

언제 실패하나?

• 직접 수집 학습 1,081건·만석 40건, 검증 443건·만석 14건으로 다시 적합해 AUC .9595를 냈다. 검증 만석이 14건이고 수집 날짜가 하루뿐이라 날짜 간 변동은 구간에 들어오지 않는다. 같은 날짜라 isotonic 보정 fold가 없어 이 실행의 예측은 raw다.
• 코퍼스 검증 10,040건 중 train에 없던 셀은 2건뿐이고 만석은 0건이었다. 새 노선·새 정류장·새 시간 셀 성능: 아직 없음.
• 잎 하나는 최소 30건이어도 250개 잎의 교집합은 훨씬 작아진다. 46개 입력에서 우연한 조합과 결측 패턴까지 외울 수 있다. 한 예측의 이유도 250개 경로를 합쳐야 나와 짧고 안정적인 운영 설명이 어렵다.
• 보조 코퍼스와 직접 수집은 원문 필드와 결측 구조가 다르다. 코퍼스에서 잘 먹힌 갈림길이 직접 원천에서 그대로 남는다는 근거가 없다.
• 최근접 차량은 next_observed_bus다. 90초 이하 구간에서도 숨은 제3차량 하한이 3330 17.24%, 1650 12.01%였다. 관측 열이 바뀌면 앞차·헤드웨이 특징도 함께 바뀐다.
• isotonic은 58개 임계점의 계단이다. 보정 구간의 사건이 적으면 서로 다른 raw 점수가 같은 확률로 뭉친다.
• 같은 개발 validation을 구현과 보정 선택 과정에서 반복 확인했다. 현재 신뢰구간은 이 선택 불확실성을 담지 않는다. 코드와 보정기를 얼린 뒤 새 연속 미래일로 다시 재야 한다.
• 이름의 상한은 이론적 최대가 아니다. 이번 특징집합과 네 하이퍼파라미터 설정에서 얻은 최고 기록이다.

프로토타입과 뭐가 다른가?

프로토타입의 좌석 예보를 더 복잡하게 만든 모델이 아니다. 질문부터 바뀌었다. 이 모델은 몇 석 남는지, 몇 분 기다리는지, 몇 대 보내는지 답하지 않는다. 운영 후보가 상한과 얼마나 벌어졌는지만 잰다.

재료 한눈에

아직 못 써본 것과 그 이유

• 정원·점유율 — 라벨은 출발 후 잔여석 0 하나로 정해진다. 코퍼스 가명 차량과 외부 vehId의 교집합은 0/77이다. 관측 최대는 정원의 하한일 뿐이라 대리 정원도 쓰지 않는다.
• crowded 혼잡도 — 대상 노선 유형 11은 공식 제공 유형 13·15·23 밖이다. 직접 수집분에서 같은 잔여석에 다른 코드가 붙은 값이 26개라 잔여석만의 함수는 아니지만, 같은 (vehId, 잔여석)에서는 충돌이 0셀이고 산식도 미확정이라 아직 넣지 않았다.
• queryTime·HTTP Date — 같은 노선 재호출 38쌍 중 queryTime이 7번 되감겼다. HTTP Date도 같은 시계였다. 시간·속도·헤드웨이는 로컬 응답 수신시각만 쓴다.
• 도착 ETA — 공급자의 예측값이며 v1 목표가 아니다. 분·초 필드도 6슬롯 중 2슬롯이 단순 나눗셈과 달랐다.
• 미래의 출발 후 잔여석 — 입력에 넣으면 정답 누수다. 출발 후 0/양수는 label_full을 만드는 데만 쓴다.
• -1의 0 치환 — -1은 결측이다. 0으로 바꾸면 가짜 만석이 된다. 결측으로 남긴다.

직접 수집분으로 다시 잰 성적 1회차

우리 수집기가 직접 쌓은 데이터만 쓰고 코퍼스는 뺐다. 검증분 443행·만석 14건, 정류소×날짜 125군집 부트스트랩 5,000회.

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

지금은 안 쓰는 재료 6개

• 차량 정원·점유율 — 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건이라 차량별 임계화일 가능성이 남는다. 산식은 미확정이고 아직 특징으로 써 보지 않았다.
• API queryTime 파생 시간 — GBIS getBusLocationListv2 msgHeader.queryTime; HTTP 응답 헤더 Date같은 노선 연속 38쌍 중 7쌍에서 queryTime이 뒤로 갔다. 직접 수집 92/92건에서는 응답 수신시각보다 미래였고 중앙 +17.265초였다. HTTP Date는 queryTime의 초 절삭과 92/92 일치해 독립 시계가 아니다. 감사 원문만 보존하고 나이·속도·헤드웨이·분할에 쓰지 않는다.
• 도착 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 후보 입력에서 뺐다.
• 목표 차량 ID와 미래 출발 후 좌석·라벨 — msgBody.busLocationList[].remainSeatCnt; S1 label_remain_seats, label_full, target_vehicle_hashtarget_vehicle_hash는 차량 암기를 막기 위해 감사키로만 둔다. 출발 후 좌석과 label_full은 목표 통과 뒤 생기는 미래 정답이라 학습의 y로만 쓰고 예측 행렬에는 넣지 않는다.
• remainSeatCnt=-1을 0석으로 대치 — GBIS getBusLocationListv2 msgBody.busLocationList[].remainSeatCnt20일 코퍼스 차량행에서 -1은 69건이다. 좌석 미제공이며 만석 0과 뜻이 다르므로 결측으로 둔다.

언제 실패하나

• 직접 수집 학습 1,081건·만석 40건, 검증 443건·만석 14건으로 다시 적합해 AUC .9595를 냈다. 검증 만석이 14건이고 수집 날짜가 하루뿐이라 날짜 간 변동은 구간에 들어오지 않는다. 같은 날짜라 isotonic 보정 fold가 없어 이 실행의 예측은 raw다.
• 코퍼스 검증 10,040건 중 train에 없던 셀은 2건뿐이고 만석은 0건이었다. 새 노선·새 정류장·새 시간 셀 성능: 아직 없음.
• 잎 하나는 최소 30건이어도 250개 잎의 교집합은 훨씬 작아진다. 46개 입력에서 우연한 조합과 결측 패턴까지 외울 수 있다. 한 예측의 이유도 250개 경로를 합쳐야 나와 짧고 안정적인 운영 설명이 어렵다.
• 보조 코퍼스와 직접 수집은 원문 필드와 결측 구조가 다르다. 코퍼스에서 잘 먹힌 갈림길이 직접 원천에서 그대로 남는다는 근거가 없다.
• 최근접 차량은 next_observed_bus다. 90초 이하 구간에서도 숨은 제3차량 하한이 3330 17.24%, 1650 12.01%였다. 관측 열이 바뀌면 앞차·헤드웨이 특징도 함께 바뀐다.
• isotonic은 58개 임계점의 계단이다. 보정 구간의 사건이 적으면 서로 다른 raw 점수가 같은 확률로 뭉친다.
• 같은 개발 validation을 구현과 보정 선택 과정에서 반복 확인했다. 현재 신뢰구간은 이 선택 불확실성을 담지 않는다. 코드와 보정기를 얼린 뒤 새 연속 미래일로 다시 재야 한다.
• 이름의 상한은 이론적 최대가 아니다. 이번 특징집합과 네 하이퍼파라미터 설정에서 얻은 최고 기록이다.

기존 프로토타입과 다른 점

• 프로토타입의 화면 탑승률은 셀의 1-zeroCount/samples였고 좌석 예보는 별도 계산이었다. GB 상한은 다음 관측 버스의 출발 후 label_full 하나를 맞힌다.
• 프로토타입은 현재 잔여석에서 정류장별 정규 수요를 빼며 0~80석 분포를 흘렸다. GB 상한은 46개 입력을 250개 나무로 나눠 만석 log-odds를 합친다.
• 프로토타입 history는 얇은 셀의 비만석률을 그대로 표시했다. GB 상한은 잎당 최소 30건과 L2 10으로 암묵 풀링한다.
• 프로토타입은 2분/순번, 10석 여유폭, 90분 streak 같은 고정 규칙을 썼다. GB 상한은 분할 경계를 데이터에서 학습한다.
• 프로토타입에는 별도 확률 보정층이 없었다. GB 상한은 train 내부 시간순 OOF 10,236건으로 isotonic을 맞췄다.
• 프로토타입은 사용자 화면 기능이었다. GB 상한은 비교표 전용이며 배포·채택 대상이 아니다.