LLM은 예외 상황을 치명적으로 두려워함

 (twitter.com/karpathy)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Andrej Karpathy는 “LLM들이 예외(Exception)를 치명적으로 두려워한다(mortally terrified)”는 말을 통해, 강화학습(RL) 과정에서 생긴 부작용을 풍자함
  • 그는 LLM이 예외 상황을 만나면 스스로를 멈추거나 과도하게 방어적으로 반응하는 것을 지적하며, 예외는 개발 과정의 자연스러운 일부라고 강조
  • “RL 중에 이 불쌍한 LLM들에게 무슨 짓을 한 거냐(what labs are doing to these poor LLMs)”라는 표현은, 훈련 과정에서 모델이 실패를 두려워하도록 조건화된 현실을 비판하는 말
  • Karpathy는 “예외 발생 시 보상을 개선하자(improved rewards in cases of exceptions)”는 ‘LLM 복지 청원서(LLM welfare petition)’ 를 제안하는 농담으로,
    모델이 예외를 두려워하지 않고 다루는 방향의 보상 설계 문제를 풍자함
  • 이 트윗은 단순한 유머가 아니라, RLHF가 모델의 탐색적 사고와 실험적 태도를 억제할 수 있다는 점을 지적하는 메시지로 해석됨

I don't know what labs are doing to these poor LLMs during RL but they are mortally terrified of exceptions, in any infinitesimally likely case. Exceptions are a normal part of life and healthy dev process. Sign my LLM welfare petition for improved rewards in cases of exceptions.

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견
  • 코드 자체가 과장된 농담이라는 점을 분명히 했어야 했음, 오해가 있었다면 미안함, 궁금하다면 이 스레드를 참고 바람 https://chatgpt.com/share/68e82db9-7a28-8007-9a99-bc6f0010d101
    • 처음 시도에서 이 부분이 정말 웃겼음 
      if random.random() < 0.01:
  logging.warning("This feels wrong. Aborting just in case.")
  return None
    • 이런 파운데이션 모델 회사들이 비전문가 유저에게 RLHF를 적용하는 위험이 항상 존재한다고 생각함, 이번 케이스도 그런 상황처럼 느껴짐, 최근 AI들은 전반적으로 사용자 기분을 맞추는 데 집중하는 경향이 강한데, 네 예제나 이모지 넣고, 간단한 코드에 쓸데없이 주석 다는 것도 같은 맥락임
    • 흥미로운 점은, 그 코드가 불필요하게 조심스러운데도 타입 힌트를 추가하지 않았다는 점임, 그렇게까지 걱정이 많으면서 타입 힌트 정도는 추가할 줄 알았음
    • “Traumatically over-trained”라는 표현이 정말 영어적으로 대단하다고 생각함, 구글에서도 검색이 안 되는 조합이지만, LLM에게 있어 “외상 수준의 과훈련”이 무엇인지 본능적으로 이해하는 게 놀라움
    • 정말 재밌는 농담이었음, 그래서 공유한 것임
  • 이건 패러디지만 실제로 이런 현상이 진짜로 존재함, 내 무지한 추측으로는 이런 방어적 프로그래밍이 RLVR 때 성능을 높여줄 수도 있다고 생각함, 모델이 때로는 버그가 있어도 에러를 무시하면 정답을 내는 경우가 있어서, “에러 무시”가 보상에 도움이 된다고 학습하게 됨, 그리고 에러 무시가 보상을 줄이는 경우는 드물기 때문에(테스트가 통과되기에), 이게 비록 이론적으로 틀렸더라도, 인간 초보들이 자주 에러를 무시한 코드를 많이 훈련셋에 넣었기 때문일 수도 있음, 하지만 이건 어디까지나 내 추측임
    • Verity Stob(불행히도 더 이상 온라인에 없는 기사에서)이 인간 프로그래머의 이런 행동을 “시체를 똑바로 세워 못질하기”라고 비유했던 말이 떠오름
    • 내 추측에는, 훈련셋에 “긍정적 센티먼트”의 텍스트와 댓글이 많이 포함돼 있다는 점임, 하지만 “부정적” 센티먼트 후에 그걸 바로잡은 코드는 어디서 나오나? 바로 극단적인 엣지케이스 다루기가 일상인 기술 면접 준비용 코드임, 네거티브 예시로 학습하면 예외 처리 누락된 예시를 회피하는 쪽으로 쏠리게 됨, 이 부분에 있어 AI가 인간의 최악의 습관(테스트만 맞추기 위한 학습)을 베낀 셈임
    • 방어적 프로그래밍은 리인포스를 하는 사람들이 “정답”이라 간주하고, LLM의 훈련 데이터에서 엄청난 비중을 차지함, 예를 들어 대부분의 파이썬 코드는 수동으로 인덱스를 관리하지 않음, 그래서 LLM이 수동 인덱스 관리 코드를 보면 당황하거나 버그를 헛소리하게 됨, 그리고 “침묵하는 실패(silent failure)”를 어이없게도 더 선호하게 되는데, 왜냐하면 튜토리얼 코드랑 “업계표준” 코드가 훈련 과정에서 더 많은 강화를 거치게 됨, 근본적으로 이 모델들은 리워드 함수로 동작하지 않고, 내부에 리워드 모델이 없음, 그저 단어 예측일 뿐이고 인텔리전스가 없는 구조임
  • 함수 결과에 “극도로 조심스럽게 수행함”이라고 써 있는 걸로 보아, 프롬프트에 “가능한 모든 엣지케이스를 다루는 파이썬 나눗셈 함수 생성, 엄청 조심스럽게 작성” 이런 식의 조건이 들어 있었을 것 같음, 이건 LLM의 트레이닝 문제라기보다는 시킨 대로 너무 정확히 수행해서 벌어진 현상처럼 느껴짐
    • 명백히 과장된 풍자라는 점을 떠나서,
      1. 그 코드는 실제로 틀렸고(이상한 예외 처리와 무관하게 틀림)
      2. 예외 처리 중 일부는 도저히 말이 안 되고, 혼란스럽고
      3. 실제로 덜 과장된 버전이 프롬프트에 예외 처리 강조만 해도 IRL에서 충분히 벌어짐
    • 나는 해당 함수 코드를 풍자적으로 과장해서 당사자가 실제 경험한 바를 보여준 거라 해석했음, 즉, 그 프롬프트에서는 일부러 과도하게 조심스럽게 작성되었을 테지만, 기본적으로 LLM들 역시 내가 원하는 것보다 더 신중한 코드 스타일을 기본으로 삼는다는 데는 동의함
  • 왜인지는 모르겠는데 FizzBuzzEnterpriseEdition이 생각났음
    https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
    • 와, 저 프로젝트에서 junit 4.8.3을 썼던 것임? 진짜 무모하게 코딩한 사례라 생각함, 법무팀과 CTO한테 결재 받고 했는지 궁금함, 커리어에 진짜 위험을 초래할 선택임
    • 폴더와 파일이 너무 많아서 충격받았음, 대단한 풍자임
  • LLM들은 방어코드를 필요 이상으로 만들어내는 경향이 있음, 같은 값에 대해 null/None/undefined를 중복으로 체크함, 그래서 읽기가 어렵고, 심지어 LLM 자신도 해석하기 힘든 코드가 됨, RL 목표가 예외를 심각하게 불이익 주지만, 코드의 간결함이나 가독성에는 별로 포인트를 주지 않는 것 같음
    • Major System용으로 문자와 숫자를 비교하는 40줄짜리 함수가 있는데, Copilot이 꼭 미래에 더 많은 숫자나 문자가 추가될 거라는 상상으로 “가드레일”을 막 넣으려 해서 너무 짜증남
  • LLM들이 에러 캐치에 너무 집착하는 경향에 동의함
    그러나 한편으로 평범한 인간 프로그래머들도 실제로 더 많은 try/catch 블록을 작성해야 한다고 생각함, 한 영역에서 발생한 예외(아무리 드물더라도)가 전체 동작을 멈추게 하면 안 되는 상황도 흔함, 물론 반대로 멈추는 게 맞을 때도 있고, 경우에 따라 다름
  • 전문가 초보자가 이런 식으로 프로그래밍함, 나는 이걸 “What if driven development”라고 부름, 많은 코드가 이런 스타일의 전문가 초보자에 의해 쓰였고, 여러 지표상 엄청 생산적임, go 언어의 SOTA 에이전트들도 동시성 버그에 미친 듯이 방어적으로 코딩함, 아마도 이런 개발 문화와, 동시성 버그 경고하는 포스팅이 난무하는 결과임
  • 논리적으로도 이상한 면이 많음, division by zero(0으로 나누기)는 b=0에서만 가능한데, 그 조건에서 이미 abs(b) < sys.float_info.epsilon으로 체크했음, 그리고 pre-check에서 NaN 반환은 허용하면서, 실제 연산에서 NaN이 나오면 None으로 바꿔버림, API 디자인상 근거 없는 행동임
  • 코드에 여러 문제점이 있지만, 개인적으로 제일 거슬리는 건 함수 내부에 import문을 넣는 경향임, 아마 최소한의 수정만 반영하려고 최적화하다가 생긴 인위적인 부작용이라 보는데, 더 나은 결과를 기대함
    • RoPE attention 매커니즘 상, 코드에서의 물리적 근접성이 중요도 신호로 사용되는 점과 연관 있다고 생각함
    • import를 lazy하게 만들려는 목적임, 스타트업 조건에서 느린 임포트 이슈 해결용임
    • 정말 엄청나게 큰 프로젝트에서는 lazy initialization이 필수가 됨, 스타트업 타임에 어마어마한 영향을 주기 때문임
  • 이 포스팅을 읽는 것보다 팝업을 닫는 시간이 더 오래 걸렸음, twitter 링크 진짜 싫어함
답변달기