▲

GN⁺: 코드에서 발생하는 환각은 LLM 오류 중 가장 덜 위험한 형태임

 (simonwillison.net)
9P by neo 11일전 | ★ favorite | 댓글 1개
  • 많은 개발자들이 LLM을 코드 작성에 사용하려다 환각(Hallucination)을 경험하고 신뢰를 잃음
    • LLM이 존재하지 않는 메서드나 라이브러리를 창작하는 것은 흔한 일
    • 하지만 코드에서의 환각은 가장 덜 위험한 유형의 환각임
  • 가장 위험한 것은 LLM이 오류를 만들어내지만 컴파일러나 인터프리터에서 즉시 감지되지 않는 경우
    • 환각된 메서드는 실행 즉시 오류를 발생시키므로 쉽게 발견할 수 있음
    • 오류 메시지를 LLM에 다시 입력하면 자동으로 수정할 수도 있음
  • 일반적인 텍스트 환각과 달리, 코드는 실행을 통해 사실 확인이 가능함
  • 자동 오류 수정 기능이 있는 LLM
    • ChatGPT Code Interpreter, Claude Code 등의 도구는 LLM이 작성한 코드를 실행하고 오류를 감지하여 스스로 수정함
    • LLM이 작성한 코드를 실행도 안 하고 평가하는 것은 비효율적임
  • 일부 개발자들은 LLM이 환각된 메서드를 생성했다는 이유로 기술 자체를 배척하려 함
    • 하지만 효과적으로 사용하려면 학습과 실험이 필수적임
    • 필자는 2년 넘게 AI 기반 코드 작성에 대해 연구하고 있으며, 여전히 새로운 기술을 배우고 있음
  • 코드의 수동 테스트는 필수임
    • 코드가 정상적으로 실행된다고 해서 기대한 대로 동작한다는 보장은 없음
    • 코드 리뷰나 자동화된 테스트만으로 코드의 정확성을 완전히 검증할 수 없음
    • 직접 실행하고 검증하는 과정이 필수적임
    • LLM이 생성한 코드는 가독성이 뛰어나기 때문에 방심할 가능성이 있음
    • 사람의 코드도 마찬가지로, 직접 실행해보기 전까지는 신뢰해서는 안 됨
  • 환각을 줄이는 방법
    • 다른 모델 사용: 특정 플랫폼에 대한 학습 데이터가 더 풍부한 모델을 선택
      • 예: Claude 3.7 Sonnet (thinking mode 활성화), OpenAI o3-mini-high, GPT-4o (Python Code Interpreter 포함)
    • 맥락(context) 활용: 특정 라이브러리를 LLM이 모르더라도 예제 코드를 제공하면 패턴을 학습 가능
    • 안정적인 기술 선택: 오래된 라이브러리를 선택하면 LLM이 더 잘 다룰 가능성이 높음
  • 코드 리뷰의 중요성
    • "LLM이 작성한 코드를 전부 리뷰해야 한다면 직접 작성하는 게 빠르다"는 주장에 반박함
    • 이는 코드 리뷰 능력 부족을 드러내는 발언일 수도 있음
    • LLM이 생성한 코드 리뷰는 실력을 향상시킬 좋은 기회가 될 수 있음
  • 보너스: Claude 3.7 Sonnet의 피드백
    • 필자는 블로그 초안을 Claude 3.7 Sonnet의 "extended thinking mode"에 검토 요청함
    • "이 글의 논리가 설득력 있는지, 개선할 점이 있는지, 빠진 내용이 있는지 검토해 달라"고 요청함
    • Claude는 초안의 어조를 부드럽게 만드는 데 도움을 줌
    • Claude 피드백 대화 링크
▲
neo 11일전  [-]
Hacker News 의견

  • 작성자가 이전 글에서는 동의했지만 이번 글에는 동의하지 않음

    • "LLM이 작성한 모든 코드를 검토해야 한다면, 내가 직접 작성하는 것이 더 빠르다"는 의견에 반대함
    • 다른 사람의 코드를 읽고 이해하며 검토하는 능력에 대한 투자가 부족하다는 주장에 동의하지 않음
    • 검토는 작성자의 전문성과 신뢰도에 따라 다르며, 익명의 기여를 검토하는 것은 다름
    • 코드의 의도와 접근 방식을 추론하고 비교하는 것이 중요하며, LLM의 경우 그 범위가 제한적임
    • 동기 부여는 중요하며, 모든 개발자가 코드 검토를 좋아하는 것은 아님
    • LLM의 코드는 사회적 측면이 없으며, 다른 사람이 변경 사항을 검토해야 함

  • LLM이 생성한 코드가 잘 작동하더라도, 작성자가 아니면 버그나 논리적 결함을 찾기 어려움

    • 코딩을 잘 설계된 계획을 구현하는 것이 아니라 조각을 맞추는 것으로 본다면, 알고리즘이 추측으로 조각을 맞추는 것에 대한 우려가 있음
    • LLM은 인간이 감수할 수 있는 위험을 감수하지 않으며, 특정 맥락에서의 코드 블록의 의미를 이해하지 못할 수 있음

  • LLM 생성 코드는 깔끔하지만, QA와 정리 작업에 더 많은 시간을 소비하게 됨

    • 코드가 잘 작동하고 오류가 없다고 해서 올바른 일을 하고 있다는 것을 의미하지 않음
    • 코드를 실행하고 테스트하는 것만으로는 코드의 정확성을 증명할 수 없으며, 논리적으로 추론해야 함

  • The Primeagen과 Casey Muratori가 최신 LLM 코드 생성기의 출력을 검토함

    • LLM의 훈련 데이터에 잘 대표된 작업을 제공하여 개발이 쉬워야 함
    • 실제로는 반복적인 개발이 쓸모없는 코드로 수렴하며, LLM이 점점 더 진전을 이루지 못함

  • Simon이 간과한 또 다른 오류 범주는 모델이 기능을 잊어버리는 환각임

    • 코드가 컴파일되는 긍정적인 측면보다 핵심 기능을 잊어버리는 부정적인 측면이 더 어려움
    • 코드가 대화/컨텍스트 창 외부에 있을 것으로 예상되는 코드에 따라 기능이 약간 변할 수 있음

  • 환각된 메서드는 작은 장애물이며, 사람들이 이를 불평할 때 시스템을 효과적으로 사용하는 방법을 배우는 데 최소한의 시간을 보냈다고 가정함

    • 이는 매우 잘못된 가정이며, 사람들이 환각을 보고 "가장 쉬운 것도 일관되게 맞추지 못한다면 더 어려운 것을 신뢰할 수 없다"고 생각함

  • 환각 자체가 LLM이 제기하는 가장 큰 위험은 아님

    • 더 큰 위험은 챗봇이 인간을 해치도록 설득할 수 있다는 것임
    • 이는 이미 발생한 사례가 있으며, 더 위험한 것이 무엇인지에 대한 아이디어는 공유하고 싶지 않음

  • 컴파일 오류의 제한된 맥락 내에서만 덜 위험함

    • 프로그래머가 실제 솔루션을 찾는 노력을 피하기 위해 전체 라이브러리를 발명했다면 더 화가 날 것임
    • 환각을 단순한 속도 저하로 간주한다면 LLM이 실제로 해야 할 일을 과소평가하는 것임

  • LLM에서 좋은 결과를 얻기 위해 많은 노력이 필요함

    • 이는 과대 광고를 꿰뚫는 것임
    • LLM이 무엇에 유용한지, 신뢰할 수 없는 결과를 얻기 위해 수년간 학습해야 한다면 무엇을 기대할 수 있는지에 대한 의문이 있음

  • 의료 센터에서 환자의 '주요' 클리닉을 찾는 코드 작성 경험

    • 임상 예약만을 고려하여 가장 최근의 예약을 찾아야 했음
    • 임상 예약이 없으면 모든 종류의 가장 최근 예약을 찾아야 했음
    • 데이터를 정렬하여 코드를 작성했으나, ChatGPT가 문서화하는 과정에서 정렬을 반대로 이해함
    • 이는 "코드가 실행되지 않음"보다 훨씬 나쁜 실수임
답변달기