AI 시간 지평선 두 배 증가율은 곡선 피팅의 산물일 뿐

지난달에 기획 회의에 참석했는데, 누군가 'AI 시간 지평선이 몇 달마다 두 배로 늘어난다'는 말을 입으로 내뱉었고, 그 말로 팀 규모를 결정하는 것을 보았습니다. 저도 그런 말을 해본 적이 있습니다. 슬라이드에도 넣어봤습니다. 제 자체 평가 시스템(eval harness)을 재구축한 일주일 동안 생각해보니, 그것은 모델의 속성이라기보다는 우리가 곡선을 피팅하는 방식에서 비롯된 산물인 것 같습니다.

플롯이 실제로 의미하는 바

프레임을 제거하고 보면 간단합니다. 각 작업에 인간의 완료 시간이 부여된 작업 세트(task suite)를 가져옵니다: 2분, 15분, 4시간 등. 모델을 이 모든 것에 실행해봅니다. 인간 시간별로 버킷팅(Bucket)하여 각 버킷에서의 성공률을 측정하고, 성공률이 50%를 넘는 지점을 찾습니다. 그 교차점이 모델의 '시간 지평선(time horizon)'이라고 불립니다. 이것을 일련의 모델에 대해 수행하고, 달력 시간(calendar time)에 걸쳐 이 교차점들에 지수 함수(exponential)를 피팅하면 두 배 증가율이 나옵니다.

문제는 우리가 임계값(thresholding)으로 삼는 것의 모양입니다. 대부분의 작업 세트에서 인간 작업 시간 2분에서 30분 사이의 성공률은 거의 평평합니다. 5분짜리 작업을 70% 처리하는 모델은 20분짜리 작업을 아마도 65% 정도 처리할 것입니다. 큰 변화가 없습니다. 그러다가 그 이후 어딘가부터 곡선이 절벽처럼 떨어지고, 50% 교차점은 이 절벽 안에 위치하게 됩니다.

따라서 지수 피팅은 이 절벽에 의해 주도됩니다. 평평한 영역은 기울기에 거의 기여하지 못하고, 가파른 영역이 거의 모든 것을 기여합니다. 우리가 얻는 것은 모델이 이미 능숙했던 부분의 곡선을 통과하는 임계값의 속도를 설명하는 숫자이며, 마치 모델이 아직 능숙하지 않은 부분을 설명하는 것처럼 인용됩니다. 이것이 신화입니다. 두 배 증가율은 능력 향상의 비율처럼 보이지만, 실제로는 쉬운 영역을 통과하는 임계값 이동률에 가깝습니다.

평평한 영역이 존재하는 이유

장기 지평선 작업(Long-horizon tasks)은 주로 사소한 이유로 실패합니다. 도구 호출이 쓰레기를 반환하거나, 파일 경로가 잘못되거나, 에이전트가 컨텍스트 압축 후 흐름을 잃고 이미 했던 작업을 반복하는 식입니다. 이러한 실패는 단계마다 대략 일정하게 발생하므로, 성공률은 단계 수에 따라 곱셈적으로 감소합니다. 이를 인간 시간의 로그(log human-time)와 그래프로 그리면 초반에는 완만한 기울기를 보이다가 나중에 급격한 절벽(cliff)을 만듭니다.

이 메커니즘이 중요한 이유는 이것이 '모델이 20분 동안 추론할 수 없다'는 것과는 다르기 때문입니다. 오히려 '실행 환경(harness)에서 매 단계마다 약간의 누수(leakage)가 발생한다'는 것입니다. 저는 올해 모델을 교체하는 것보다 도구 출력에 스키마 검증기(schema validator)를 추가하여 장기 지평선 실패 문제를 더 많이 해결했습니다. 만약 당신의 절벽이 실행 환경의 인공물이라면, 당신의 두 배 증가율은 당신의 실행 환경을 측정하고 있는 것입니다.

세 가지 통계적 문제점

버킷별 작업 수가 적습니다. 몇십 개의 작업을 기반으로 추정한 50% 교차점(crossing)은 인간 시간 수 시간에 걸쳐 신뢰 구간(confidence interval)이 벌어질 수 있습니다. 버킷 간에 두 개의 작업을 이동시키면 교차점이 움직입니다. 제가 부분 점수(partial credit)를 채점하는 방식을 변경한 후, 같은 모델, 같은 가중치, 같은 오후였음에도 불구하고 저의 교차점 지점이 대략 2배로 뛰어오르는 것을 목격했습니다.

함수 형태는 선택 사항입니다. 지수 함수(Exponential), 로지스틱 함수(Logistic), 거듭제곱 법칙(Power law) 등 — 데이터가 있는 범위 내에서는 세 가지 모두 거의 동일하게 잘 맞습니다. 그 범위를 벗어나면 급격히 달라집니다. 두 배 증가율은 당신이 선택한 모델의 매개변수일 뿐, 세상에 대한 측정치가 아닙니다. 로그 시간으로 로지스틱 함수를 피팅하면 헤드라인은 바뀌지만 데이터는 변하지 않습니다.

교차점 이동은 역량(capability) 문제가 아닌 이유로 발생합니다. 재시도 예산(Retry budgets), 도구 가용성, 채점기의 엄격함, 릴리스 간에 테스트 스위트가 쉬워졌는지 여부 등 모든 것이 그 임계점을 변화시킵니다. 이들 중 어느 것도 모델이 더 똑똑해진 것을 의미하지 않습니다.

정직한 해석

변환 곡선(Conversion curve). 인간 분(Human-minutes)에서 AI 난이도(AI-difficulty)로의 변환입니다. 이것은 제가 실제로 궁금해하는 질문에 답합니다. 제 앞에 놓인 작업 중 오늘날 어느 정도 비율이 선 아래에 있는가? 이것은 용량 계획 입력값(capacity-planning input)입니다. 예측(forecast)이 아니며, 날짜를 동반하지 않습니다.

저는 그렇게 보고하기 시작했습니다. 제가 실제로 에이전트에게 전달하는 작업 로그 — 벤치마크가 아닌 것들 — 를 인간의 시간 단위로 분류하고, 그에 따라 성공률을 그래프로 그립니다. 제 로그에서 중간값(median)으로 측정되는 작업은 몇 분 정도의 인간 노동 시간이 걸리며, 이는 제가 처리해야 할 백로그 대부분이 곡선이 내일과 관련하여 거의 아무것도 알려주지 않는 평평한 영역에 있다는 것을 의미합니다. 누군가 '언제 에이전트가 X를 수행할까요?'라고 물으면, 저는 두 가지로 답합니다. 오늘 날짜 기준으로 X가 곡선의 어느 지점에 위치하는지, 그리고 지난 분기 이후 곡선이 얼마나 움직였는지입니다. 그런 다음 제가 그 구간(interval)을 보여줍니다. 이 구간은 보통 민망할 정도인데, 그것이 요점입니다.

다음에 받고 싶은 것들

하나의 통합된 곡선 대신 도메인별 곡선을 원합니다. 코딩과 연구와 운영(ops)은 각기 다른 난관(cliffs)을 가지고 있으며, 이들을 평균 내는 것은 아무도 활용할 수 없는 숫자를 만들어냅니다. 버킷별로 출판된 작업 건수. 모든 교차 지점에 대한 신뢰 구간(Confidence intervals). 그리고 마지막 측정된 버킷을 넘어서 외삽(extrapolate)하는 것을 명시적으로 거부해야 합니다.

마지막 것이 가장 어렵습니다. 왜냐하면 외삽이 모두가 인용하는 부분이기 때문입니다. 평평해 보이는 구간에 가파른 구간과 피팅된 지수 함수를 더한 것은, 희박한 데이터로부터 자신감 있는 날짜를 생성하는 기계이며, 이 작업에 매우 능숙합니다.

이 모든 것이 진전이 없다는 것을 의미하지는 않습니다. 단지 헤드라인 숫자가 곡선의 쉬운 부분만을 측정하고 그것을 전부인 것처럼 취급한다는 뜻입니다. 만약 이것을 근거로 인력 충원 계획을 세우고 있다면, 당신은 가진 데이터 중 가장 평평한 데이터를 기반으로 계획하는 것입니다.

저는 그들의 피팅(fit)을 직접 재현하지 않았습니다. 논문을 읽었을 뿐, 그들의 파이프라인을 다시 실행하지 않았으므로 제 독해는 독해로 간주해 주십시오. 확인하고 싶다면 여기에서 비교할 수 있습니다: [https://arxiv.org/abs/2610.12466v1]