▲

Claude Code 성능 저하 추적용 일일 벤치마크

 (marginlab.ai)
6P by GN⁺ 22시간전 | ★ favorite | 댓글 2개
  • Claude Code Opus 4.5의 SWE 작업 성능을 매일 측정해 통계적으로 유의한 성능 저하를 탐지하는 추적 시스템
  • SWE-Bench-Pro의 선별된 하위 집합을 사용해 매일 50개 테스트 인스턴스를 평가하며, 결과는 CLI 환경에서 직접 실행된 실제 모델 성능을 반영
  • 최근 30일간의 평균 통과율 54% , 기준선 58% 대비 통계적으로 유의한 4.1% 하락이 감지됨
  • 일간 및 주간 결과는 95% 신뢰구간과 유의성 임계값(±14.0%, ±5.6%) 을 기준으로 분석되어, 단기 변동과 장기 추세를 구분
  • 독립적인 제3자 기관이 운영하며, 모델 또는 실행 환경의 변화로 인한 성능 저하를 조기 탐지하는 도구

개요

  • 이 트래커의 목적은 Claude Code Opus 4.5의 SWE 작업 성능에서 통계적으로 유의한 저하를 감지하는 것
    • 매일 SWE-Bench-Pro의 오염 저항성 하위 집합을 사용해 평가 수행
    • Claude Code CLI에서 직접 실행하며, 별도의 커스텀 하니스 없이 실제 사용자 환경을 반영
  • 독립적인 제3자 기관으로, 프런티어 모델 제공자와의 제휴 없음
  • 2025년 9월 Anthropic의 성능 저하 관련 포스트모템 이후, 향후 유사 사례를 조기에 탐지하기 위한 리소스로 운영

성능 요약

  • 기준선 통과율: 58%
  • 최근 30일 통과율: 54% (655회 평가 기준)
  • 최근 7일 통과율: 53% (250회 평가 기준)
  • 최근 1일 통과율: 50% (50회 평가 기준)
  • 30일간 성능 저하는 p < 0.05 수준에서 통계적으로 유의함
    • 30일 변화폭: -4.1%
    • 유의성 임계값: ±3.4%
  • 1일(-8.0%) 및 7일(-4.8%) 변화는 통계적으로 유의하지 않음

일간 및 주간 추세

  • 일간 추세(Daily Trend)
    • 최근 30일간의 일별 통과율을 시각화
    • 기준선 58% , 유의성 임계 구간 ±14.0%
    • 95% 신뢰구간 표시 가능, 표본 수가 적을수록 구간이 넓어짐
  • 주간 추세(Weekly Trend)
    • 7일 이동 평균을 통해 일간 변동성을 완화한 추세 제공
    • 기준선 58% , 유의성 임계 구간 ±5.6%
    • 동일하게 95% 신뢰구간 표시 가능

변화 개요(Change Overview)

  • 1일 변화(어제 대비) : -8.0%, 통계적으로 유의하지 않음
    • 50회 평가 기준, ±14.0% 변화 필요(p < 0.05)
  • 7일 변화(지난주 대비) : -4.8%, 통계적으로 유의하지 않음
    • 250회 평가 기준, ±5.6% 변화 필요(p < 0.05)
  • 30일 변화(지난달 대비) : -4.1%, 통계적으로 유의함
    • 655회 평가 기준, ±3.4% 변화 필요(p < 0.05)

방법론(Methodology)

  • 각 테스트를 베르누이 확률 변수로 모델링하고, 95% 신뢰구간을 계산
  • 일간, 주간, 월간 통과율의 통계적 차이를 분석해 유의한 성능 저하 여부를 보고
  • 매일 50개 테스트 인스턴스로 평가 수행, 단기 변동성 존재
  • 주간 및 월간 집계 결과는 보다 안정적인 추정값 제공
  • 모델 변경 또는 실행 하니스 변경으로 인한 성능 저하 모두 탐지 가능

알림 기능

  • 성능 저하가 통계적으로 감지될 경우 이메일 알림 발송
  • 사용자는 이메일 주소를 등록해 구독 가능
  • 구독 확인 후 알림 수신 가능, 오류 발생 시 재시도 안내
▲
iolothebard 7시간전  [-]

클로드 코드가 멍청해진게 아니라… 쓰는 사람이 클로드를 더 잘 활용하게되서… 일지도…

답변달기
▲
GN⁺ 22시간전  [-]
Hacker News 의견들

  • Claude Code 팀의 Thariq임
    1월 26일에 발생한 harness 문제를 수정했음. 1월 28일에 바로 롤백 완료했으니 claude update 명령으로 최신 버전으로 업데이트할 것을 권장함

    • Claude 2.1.x 버전이 자주 멈추거나 CPU를 100% 사용해서 사실상 쓸 수 없을 정도임. 관련 이슈는 GitHub #18532에 있음
    • Claude가 토큰을 낭비했는데 이에 대한 보상이 있는지 궁금함
    • “harness issue”가 정확히 무엇을 의미하는지, 그리고 어떤 영향이 있었는지 더 알고 싶음
    • 문제는 1월 26일 이전부터 있었음. 그때부터 Claude가 “개선”이라며 계획을 임의로 수정하기 시작했음
    • 모델 자체보다 품질 관리 체계가 궁금함. 실제 출력 샘플을 주기적으로 점검하거나 벤치마크로 성능 저하를 감시하는 내부 프로세스가 있는지 의문임. AI 안전성 측면에서도 이런 검증은 필수적임

  • SWE-bench 공동 저자임
    현재 테스트는 50개 작업만 대상으로 하루 한 번만 실행되는 것 같음. 정확도를 높이려면 300개 작업에 대해 하루 5~10회 테스트 후 평균을 내야 함. 서버 부하 같은 랜덤 요인이 결과에 큰 영향을 줄 수 있음

    • 서버 과부하로 인한 성능 저하도 측정 대상이어야 하지 않음? 만약 모델 증류만 측정하려는 게 아니라면 말임
    • 모델 실행 비용이 문제일 듯함. Anthropic이 약간의 크레딧 지원을 해주거나, 기부 링크를 열면 좋겠음
    • 하루 중 시간대별로 성능 차이가 더 클 수도 있음
    • SWE-bench 실행 비용이 너무 비싸서 충분히 돌리기 어렵다는 고민이 있음. mafia-arena.com에서 비슷한 문제를 겪고 있음
    • “서버가 과부하라서 측정이 정확하지 않다”는 말이 이상함. 그렇다면 Claude가 잘 작동하는 근무 시간이라도 있는 건가?

  • Anthropic이 사용자에게 더 나쁜 모델을 제공한다고 믿지 않는 이유를 정리함

    1. 정확도 하락폭이 작고 진동 형태로 오르내림
    2. Sonnet 4.5와 비교 기준이 없고, GPU 부하 시 Opus가 Sonnet 수준으로 떨어질 수도 있음
    3. 여러 체크포인트를 A/B 테스트 중일 가능성이 높음. Claude Code 버전 업데이트나 토큰 샘플링의 비결정성도 원인일 수 있음
    • 과학적 설명은 이해하지만, 매일 써보면 확실히 성능이 나빠지는 느낌임
    • 나도 A/B 테스트가 주요 원인이라 생각함. 컨텍스트 윈도우 제한이나 시스템 프롬프트 변경 등 투명하게 공개되면 좋겠음. 사용자가 직접 버전을 선택해 피드백을 주는 방식이 이상적임
    • 그래프가 1월 8일부터 시작된 이유가 궁금함. 그 시점이 비정상적으로 높았던 날일 수도 있음
    • 부하에 따라 성능-비용 조정을 자동으로 바꾸는 구조일 수도 있음. 처음엔 고성능으로 시작했다가 점차 비용 절감을 위해 모델을 축소하거나 MoE 전문가 수를 줄이는 식으로 조정했을 가능성 있음
    • “하락폭이 너무 작다”는 주장은 통계적 유의성을 무시한 주관적 판단일 뿐임

  • 통계 방법론이 이상함
    그들은 이전 값의 신뢰구간만 고려하고 새 값이 그 밖에 있는지를 보는 식인데, 이는 차이의 통계적 유의성을 검증하는 올바른 방법이 아님. 두 측정치 모두 불확실성이 있으므로 차이 자체의 신뢰구간을 계산해야 함. 또한 월간 비교라면 60~31일 전 데이터와 30일 전~어제 데이터를 비교해야 하므로, 그래프는 최소 두 달치를 보여야 함

  • 일주일 전쯤 Claude가 약 한 시간 다운된 적이 있었음. 복구 직후엔 사용자 수가 줄어서 그런지 속도가 3배 이상 빨라졌음. 그 한 시간 동안 평소 반나절 분량의 일을 처리했음. 자원 제약이 없는 미래의 모습을 잠깐 본 느낌이었음

    • 미국 휴일 기간에도 사용 제한이 완화되면서 모든 게 훨씬 부드럽게 작동했음
    • 나도 며칠 전 같은 경험을 했음. 너무 빨라서 “claude speed boost”를 검색했을 정도임. 예전 모뎀 업그레이드 때처럼 순간적인 번개 속도였음
    • 너무 빨라지면 오히려 아쉬움. 지금은 모델이 열심히 일하는 걸 느낄 수 있어서 좋음

  • 사용자 프롬프트에서 욕설 빈도를 측정하면 모델 성능 저하 시 사용자 적대감 상승을 감지할 수 있음

    • 그런데 Claude 사용자 프롬프트를 ‘단순히’ 스캔할 수 있는 방법이 있나?
    • “How’s Claude Doing This Session?” 같은 피드백 요청 직후 욕설이 늘어나는 상관관계가 있음
    • 나는 원래 욕을 자주 써서 데이터가 왜곡될 수도 있음
    • 나도 그런 편이라 안심됨
    • 가끔 너무 멍청한 답을 할 때 욕이 나옴. 기대치가 높아서 생긴 반응임

  • 시간이 지나면서 모델을 점진적으로 양자화(quantization) 할 가능성이 있음. 이렇게 하면 확장성과 비용 절감이 쉬워지고, 새 버전이 더 “좋아 보이는” 효과도 생김

    • 매일 5~10시간씩 쓰는데, 최근 일주일은 확실히 더 멍청해진 느낌임. 그들이 부인하더라도 체감상 변화가 있음
    • 굳이 양자화하지 않아도 대화 길이 축소나 추론 시간 단축 등으로 부하를 줄일 수 있음
    • 오픈 모델 GPT-OSS나 Kimi K2.x도 4bit 레이어로 학습되었음. Opus 4.5는 토큰당 비용이 8배 비싸서 더 큰 모델일 가능성이 높지만, 구독제 가격 구조 때문에 단순 비교는 어려움
    • Anthropic이 인프라 비용에 그렇게 제약받는 회사로 보이지 않음. 경쟁이 치열한 상황에서 품질을 의도적으로 낮추는 건 나쁜 전략임. 아마도 사용자들이 ‘허니문 효과’ 이후 결함을 더 잘 인식하게 된 것일 수도 있음
    • 그래도 이런 점진적 저하 전략은 충분히 가능해 보임. 새 모델의 상대적 개선 효과를 극대화할 수 있으니까

  • API 모드에서 Claude가 일정 토큰 수를 넘기면 갑자기 멍청해지고, “23번째 줄에 버그가 있다”더니 전체 기능을 삭제하는 식으로 엉뚱한 행동을 함. ChatGPT 3.5로도 가능한 간단한 수정조차 실패함. 왜 이런 일이 생기는지 이해할 수 없음

    • 아마 리소스 제약 때문일 것임. 일부 사용자에게 좋은 답을 주기보다, 더 많은 사용자에게 적당한 답을 주는 쪽을 택했을 가능성이 높음
    • 나도 같은 경험을 했음. Claude가 점점 게을러진 느낌임

  • 최근 일주일 사이 Claude의 코드 품질이 눈에 띄게 나빠짐. 예를 들어 Enum에 frozen을 쓰라고 하거나, 이미 urlparse를 쓰는 함수에서 다시 urlparse를 제안함. 예전엔 이런 기본적인 실수를 하지 않았음

  • LLM 제공업체의 추론 능력 일관성 부족이 큰 불만임. ChatGPT도 마찬가지로, 45k 토큰 이상 입력 시 지능이 급격히 떨어지거나 입력이 잘리는 현상이 있음. 차라리 “거절” 메시지를 주는 게 낫지, 몰래 다운그레이드되는 건 신뢰를 잃게 함. 투명성이 정말 중요함

답변달기