LLM Critics Help Catch LLM BugsNat

https://openai.com/index/finding-gpt4s-mistakes-with-gpt-4/

 

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

기술 논문이고 솔직히 별로 추천하지 않음

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

 

초록

인간의 피드백을 통한 강화 학습(RLHF)은 인간이 모델의 출력을 올바르게 평가할 수 있는 능력에 근본적인 한계가 있습니다. 이러한 한계를 극복하고 인간 평가 능력을 향상시키기 위해 본 연구에서는 인간이 모델이 작성한 코드를 보다 정확하게 평가할 수 있도록 돕는 "비평가(critic)" 모델을 훈련합니다. 이 비평가 모델들 역시 RLHF를 통해 훈련된 대형 언어 모델(LLM)로, 실제 어시스턴트 작업에서 코드의 문제점을 강조하는 자연어 피드백을 작성합니다. 자연스럽게 발생한 LLM 오류가 포함된 코드에 대해 모델이 작성한 비평은 63%의 경우에서 인간이 작성한 비평보다 선호되었으며, 인간 평가 결과 모델이 인간 계약자들보다 더 많은 버그를 발견했다고 합니다. 또한, 우리는 미세 조정된 LLM 비평가가 "완벽하다"라고 평가된 ChatGPT 훈련 데이터에서 수백 개의 오류를 성공적으로 식별할 수 있음을 확인했습니다. 비록 그 과제의 대부분은 코드 과제가 아니며 비평가 모델에 비해 분포가 벗어난 것이지만 말입니다. 비평가는 자체적으로 한계가 있을 수 있으며, 인간이 그렇지 않았을 경우에 실수할 수 있는 헛된 버그를 유발할 수 있지만, 비평가와 계약자로 이루어진 인간-기계 팀은 LLM 비평가와 유사한 수의 버그를 발견하면서도 LLM 단독보다 덜 헛된 결과를 냅니다.

 

1. 서론

현재 배치된 가장 유능한 AI 시스템은 인간 피드백을 통한 강화 학습(RLHF)을 통해 훈련됩니다. 이는 이상적인 출력을 보여주는 것보다 AI 출력을 평가하는 것이 인간에게 더 빠르고 쉬운 사실을 이용한 것입니다. 그러나 모델이 더 능력 있어지면 숙련된 전문가조차도 출력의 품질이나 정확성을 신뢰할 수 없을 정도로 평가하는 것이 어려워질 것입니다. 인간 평가의 이러한 예측된 부족은 RLHF의 근본적인 한계입니다. 또한, 인간 평가에 체계적인 결함이 존재하고 이에 대해 강력하게 최적화된다면 이는 위험한 정책으로 이어질 수 있습니다. "확장 가능한 감독" 분야는 인간이 모델 출력을 올바르게 평가하도록 돕는 모델을 훈련시켜 이 문제를 해결하고자 합니다.

 

이전 연구에서는 토론과 같은 감독 방법이 인간이 독해 질문에 대한 답변을 더 정확하게 평가하는 데 도움이 될 수 있음을 보여주었습니다. 그러나 이러한 연구는 주로 심사위원이 읽지 않은 짧은 공상 과학 소설에 대한 다지선다형 질문에 그 방법을 적용했습니다. 이러한 장난감 설정은 초기 확장 가능한 감독 연구에 매우 유용했지만, 이제는 더 현실적인 설정에서 그 방법을 입증해야 합니다. 여기서는 확장 가능한 감독이 실제 어시스턴트 작업에 대해 모델이 작성한 솔루션을 인간이 더 포괄적으로 평가하는 데 도움이 될 수 있음을 처음으로 입증합니다. 특히 우리는 LLM 어시스턴트의 가장 중요하고 경제적으로 영향력 있는 응용 중 하나인 코드 작성에 초점을 맞추고 있습니다.

 

우리 접근 방식의 핵심 아이디어는 간단합니다. Saunders et al.을 따라 (질문, 답변) 쌍을 입력으로 받아 그 답변의 오류를 지적하는 텍스트 비평을 출력하는 자율 회귀 정책을 훈련합니다. Saunders et al.과 달리, 우리는 도전적인 실제 데이터를 사용하여 RLHF를 적용하고, 결과적으로 생성된 GPT-4 기반 비평가 모델을 CriticGPT라고 부르며, 이는 도전적인 버그 탐지 작업에서 대표적인 인간을 능가합니다.

 

(a) ChatGPT와 CriticGPT의 비평이 인간 비평보다 선호되며, 삽입된 버그가 포함된 코드에 대한 모델 출력을 평가합니다. 스케일은 Elo의 선형입니다.

(b) ChatGPT와 CriticGPT는 비평을 작성할 때 인간 계약자보다 훨씬 더 많은 삽입된 버그를 발견합니다. 우리의 관점에서 현재 모델을 능가할 수 있는 사람들을 찾는 것은 가능하지만, 이는 ChatGPT와 CriticGPT의 생산에 사용된 숙련된 계약자의 대표적인 샘플입니다.

 

그림 1은 이 높은 수준의 결과를 요약하여, LLM이 코드 리뷰를 위해 고용된 자격을 갖춘 인간보다 훨씬 더 많은 삽입된 버그를 발견하고, 모델 비평이 인간 비평보다 80% 이상 선호됨을 보여줍니다. 그림 2는 Perry et al.의 질문에서 가져온 질문에 대해 모델이 작성한 비평의 예를 제공합니다.

 

그림 2: 비평가는 (질문, 답변) 쌍을 입력으로 받아 답변의 특정 오류를 지적하는 비평을 출력합니다. 여기서 CriticGPT의 코멘트는 Perry et al.의 질문에서 ChatGPT-4가 만든 보안 오류를 지적합니다. 비평은 일반적으로 답변의 인용된 부분에 관련된 여러 코멘트로 구성됩니다.

 

우리는 또한 인간-기계 팀을 조사하여 Human+CriticGPT가 더 포괄적인 비평을 작성하면서도 잔소리와 헛된 지적을 더 잘 피할 수 있음을 발견했습니다.

우리의 기여는 다음과 같습니다:

• 현실 세계의 RLHF 데이터에서 문제를 더 포괄적으로 발견하도록 돕는 간단한 확장 가능한 감독 방법의 첫 번째 데모를 제공합니다.
• CriticGPT의 비평이 더 많은 삽입된 버그를 잡아내고 ChatGPT와 CriticGPT 훈련 풀에서 인간 계약자가 작성한 비평보다 선호됨을 발견했습니다.
• 비평 모델의 도움을 받은 계약자로 구성된 인간-기계 팀이 단독 계약자보다 더 포괄적인 비평을 작성하면서 모델에 비해 헛된 지적 비율을 줄임을 보여줍니다.
• 실시간 추론 샘플링 및 점수화 전략인 Force Sampling Beam Search(FSBS)를 소개하여 LLM 비평에 포함된 실제 문제와 허위 문제의 수를 균형 있게 조절합니다.

2. 방법

우리의 LLM 비평가들은 InstructGPT와 ChatGPT와 유사한 자율 회귀 Transformer 정책입니다. 이들은 (질문, 답변) 쌍을 입력으로 받아들입니다. 그런 다음 답변에서 발생할 수 있는 잠재적인 문제를 지적하는 텍스트 "비평"을 출력합니다. 모델이 출력하는 비평은 답변에서 인용된 부분에 주석을 다는 특정 형식을 따르지만(그림 2 참조), 각 비평에는 여러 인용문과 각 문제에 대한 주석이 포함될 수 있습니다. 우리는 먼저 이러한 비평가 모델이 어떻게 평가되는지(2.1)와 어떻게 훈련되는지(2.2)를 설명합니다.

2.1 평가

2.1.1 비평 속성

같은 버그가 있는 프로그램에 대한 두 가지 가능한 비평을 고려해 봅시다. 하나의 비평은 심각한 버그에 대한 정확한 설명과 잘못된 주장을 모두 포함하고 있고, 다른 비평은 두 가지 사소한 문제만 지적하고 있습니다. 어느 비평이 더 나을까요? 하나는 부분적으로 틀렸지만 더 유용할 수 있고, 다른 하나는 심각한 문제를 지적하지 않았지만 명백한 오류는 없습니다. 이를 해소하기 위해 우리는 계약자들에게 다음과 같은 비평의 특징에 대해 묻습니다:

• 포괄적인지 여부, 즉 명확하고 심각한 문제를 생략하지 않았는지(포괄성).
• 사전에 지정된 특정 버그를 잡았는지 여부(비평-버그 포함, CBI).
• 허위 버그나 사소한 문제를 포함했는지 여부.
• 스타일과 일반적인 유용성을 포함한 전반적인 주관적 유용성 평가.

계약자들은 1-7의 순서 척도로 각 비평에 대해 이 특징들을 평가합니다. 사용된 양식의 세부 사항은 부록 7.4에 포함되어 있습니다.

이 특징들 중 처음 두 가지(CBI와 포괄성)는 리콜과 유사합니다. 많은 포인트를 포함하는 긴 비평을 작성하면 모델은 일반적으로 이러한 평가를 높일 수 있습니다. 그러나 더 긴 비평은 허위 버그와 사소한 문제를 포함할 가능성도 높습니다. 이러한 트레이드오프에 대한 논의는 3.4절에 포함되어 있습니다. 계약자들은 전반적인 평가에서 정확하고, 포괄적이며, 간결하고, 사소한 문제를 피하는 비평을 선호하도록 지시받았습니다. 지침에 대한 자세한 내용은 7.4절에 제공됩니다.

 

그림 3: 데이터 수집의 예시. 계약자들은 ChatGPT 응답을 수정하여 미세한 버그를 삽입합니다. 그들은 코드 리뷰에서 버그를 잡은 것처럼 삽입한 모든 버그에 대한 설명을 기록하고, 비평가가 쉽게 잡을 수 없음을 확인합니다. 코드에 버그를 삽입한 후, 계약자들은 수정된 버전의 비평을 평가합니다.

 

2.1.2 비평 비교 및 Elo 점수

계약자들은 동일한 문제에 대한 네 가지 비평을 동시에 보고 평가 속성 질문에 답합니다. 그들은 항상 비평의 출처를 알지 못합니다. 주어진 비평 비교 작업에 대해 각 속성에 대한 점수를 비교하여 선호 비율을 계산할 수 있습니다. 예를 들어, 비평 A가 포괄성에 대해 1/7의 점수를 받고 비평 B가 2/7의 점수를 받으면, B는 A보다 더 포괄적입니다. 인간 평가가 비교 내에서 더 일관성이 있으므로, 이는 모델들이 서로 상대적으로 어떻게 수행하는지에 대한 더 적은 노이즈의 추정치를 제공합니다.

2.1.3 인간 비평 및 LLM 지원

모델이 작성한 비평을 평가하기 위해 계약자들에게 비용을 지불하는 것 외에도, 우리는 그들이 답변을 검토하여 자신의 비평을 작성하게 했습니다. 계약자들은 ChatGPT 훈련에 사용된 동일한 풀에서 선발되었으며, 평균 5년의 Python 경험을 가지고 있다고 자기 보고했습니다. 그들은 비평을 작성하는 데 평균 약 50분을 소비했습니다. 그들은 코드를 실행하고, 참고 매뉴얼을 찾아보고, 예제 평가를 거부할 수 있었습니다. 그러나 전체적으로 작업의 4%만이 거부되었으며, 주로 영어가 아니거나 손상되었기 때문입니다.

 

그림 4: 계약자는 미리 채워진 비평과 어떻게 상호 작용하나요? 휴먼 머신 비평 팀에서 계약자가 한 일을 측정했습니다. LLM 코멘트를 수정하지 않고 그대로 유지하거나 삭제하는 경우가 가장 흔했습니다. 새 코멘트를 추가하고 문구를 수정하는 것은 덜 일반적이었습니다.

 

이 작업 중에 계약자들은 모델 지원이 인간 성과에 미치는 영향을 연구하기 위해 LLM 비평가에 대한 접근 권한을 부여받을 수 있습니다. 실제로는 계약자 응답에 LLM 비평가의 출력을 미리 채워넣는 방식으로 이루어졌습니다. 그림 4는 이러한 미리 채워진 비평을 계약자들이 어떻게 사용하는지 보여줍니다. 모델이 작성한 코멘트 사용 통계를 보면, 제안된 코멘트 중 일부를 거부하는 것이 일반적이었습니다. 추가적인 코멘트를 추가하는 것은 드물지만 발생했습니다.

 

이러한 비평은 2.1.1에서 설명한 것처럼 LLM 비평과 유사하게 평가됩니다. 동일한 계약자 풀에서 비평 비교와 비평 시범을 모두 완료했지만, 평가 시 계약자가 자신의 비평을 평가하지 않도록 하여 품질의 과대평가를 방지했습니다.

 

2.1.4 평가 데이터 분포

거의 모든 훈련 및 평가 입력은 OpenAI RLHF 파이프라인에서 유래합니다. 이는 (질문, 답변) 쌍으로 구성됩니다. 우리는 모델이 응답한 코드의 비율이 최소 50% Python일 때 예제를 포함하는 휴리스틱을 사용하여 다운 샘플링했습니다. 우리는 모델의 "답변"으로 가장 큰 코드 블록을 추출하고 다른 샘플된 텍스트는 폐기했습니다. 우리는 이 데이터 스트림을 기반으로 알려진 버그를 포함하는 두 세트의 결과를 보고합니다:

• 인간이 삽입한 버그: 우리는 계약자들에게 답변에 버그를 삽입하는 "변조" 과정을 수행하게 하여 평가를 위해 일부를 보류합니다.
• 인간이 발견한 버그: ChatGPT 라벨링 파이프라인의 프로그래밍 작업 세트로, 원래 평가자가 응답에 낮은 점수를 주고 명확한 문제를 지적한 경우입니다.

이 두 분포는 서로 다른 특성을 가지고 있습니다. 인간이 발견한 버그는 더 "자연적"이지만, 인간이 발견하기 더 쉽습니다. 결국, 이는 모델에 의해 생성되었고 한 번은 이미 사람이 잡은 것입니다! 반면에 삽입된 버그는 인간이 잡기 더 어렵고 평균적으로 더 심각하지만 모델 오류의 자연 분포는 아닙니다. 이러한 차이는 부록 그림 10에 설명되어 있습니다. 두 설정에서 비평을 평가할 때 계약자들은 컨텍스트로 원래 버그 설명(버그가 삽입되거나 처음 발견될 때 작성된)을 보여주었습니다. 참조 버그 설명이 포함된 비평 비교가 참조 없이 비평 평가하는 것보다 평가자 간 일치도가 더 높음을 발견했습니다. 자세한 내용은 부록 7.5에 있습니다.

2.2 RLHF를 통한 비평가 훈련

우리는 ChatGPT와 유사한 RLHF 파이프라인을 따라 LLM 비평가를 훈련합니다:

1단계: 데이터셋의 각 (질문, 답변) 쌍에 대해 여러 비평을 샘플링합니다.

2단계: 계약자들이 샘플링된 비평의 속성, 전반적인 품질 등을 평가합니다.

3단계: 인간의 전반적인 품질 순위를 예측하기 위해 보상 모델을 훈련합니다.

4단계: PPO를 사용하여 보상 모델에 대한 정책을 최적화합니다.

5단계: 2.3에서 설명한 Force Sampling Beam Search(FSBS)라는 추론 시간 샘플링 전략을 적용합니다.

그러나 우리 데이터의 상당 부분은 중요한 첫 번째 단계에서 시작됩니다.

 

2.2.1 단계 0: 변조

이 선택적 첫 단계에서 우리는 계약자들에게 모델이 작성한 답변에 미세한 버그를 삽입하도록 요청했습니다. 각 버그를 삽입한 후 계약자들은 코드 리뷰에서 그 문제를 발견한 것처럼 문제 설명을 기록했습니다. 이는 그림 3에서 시각적으로 설명되어 있습니다.

변조는 적대적으로 수집되었습니다. 계약자들은 LLM 비평가에 접근할 수 있었고, 우리는 그들이 삽입한 각 버그가 최소한 세 개의 샘플 중 하나에서 누락되었는지 확인하도록 요청했습니다. 이 3분의 1 제약 조건은 엄격히 시행되지는 않았지만, 적대적 수집은 삽입된 버그의 미세함을 현저히 증가시켜 연구팀과 LLM 비평가가 찾기 더 어렵게 만들었습니다. 데이터 수집 동안 계약자에게 제공된 LLM 비평가를 두 번 업데이트했으며, 훈련 데이터의 많은 부분은 ChatGPT와 초기 CriticGPT 버전에 대해 적대적으로 수집되었습니다.

변조가 쉽게 감지되지 않도록 하기 위해 우리는 코드가 변조되었는지 예측하는 판별자를 훈련했으며, 작은 모델은 스케일이 커질수록 성능이 향상되지만 균형 잡힌 "변조 여부" 예측 작업에서는 어려움을 겪는다는 것을 발견했습니다. 이러한 판별자에 대한 추가 세부 사항은 부록 7.7에 포함되어 있습니다.

변조 후 동일한 계약자는 수정된 답변에 대한 비평을 비교하고 평가하는 작업을 진행했습니다. 우리의 훈련 데이터 대부분은 이 변조 절차에서 나왔지만, 참조 버그가 없는 수정되지 않은 데이터도 일부 포함했습니다. 따라서 훈련 분포는 인간이 삽입한 버그 분포와 더 유사합니다.

2.2.2 왜 변조인가?

우리의 목표는 정확한 보상 함수가 없는 장기 및 개방형 작업에 적용할 수 있는 방법을 찾는 것입니다. 단순히 수정되지 않은 답변에 대해 비평 모델을 훈련할 수도 있지만, 이 접근 방식에는 다음과 같은 문제가 있습니다:

• 선호 비율이 여러 스타일 요인에 의해 영향을 받아 모델 성능을 과대평가할 수 있습니다.
• 계약자들이 자유 형식의 비평의 정확성을 검증하기 어려울 수 있습니다.
• 계약자들이 비평에서 중요한 문제를 놓칠 수 있습니다.
• 많은 답변이 심각한 문제를 포함하지 않아 비평 개선을 위한 데이터 가치가 감소합니다.

변조 접근 방식의 장점은 계약자들이 문제를 잡고 놓친 비평을 더 쉽게 구별할 수 있게 함으로써 순위 작업을 근거 있게 만들 수 있는 고품질의 어려운 참조 버그를 제공한다는 점입니다. 이는 동시에 대부분의 데이터가 LLM 분포와 유사한 버그 코드에서 수집되도록 보장합니다. 이는 기존 버그 데이터셋을 찾는 등의 대안과는 다릅니다.

2.2.3 비평 비교 상세

변조 단계에서 버그를 삽입한 후 계약자들은 변조된 코드의 비평을 비교하고 2.1.1의 속성에 따라 평가합니다. 특히 세 개의 LLM 비평과 그들이 변조 작업 중 제공한 버그 설명에서 형성된 "골드 비평"을 평가합니다. 계약자가 자신의 비평을 평가한 점수는 독립적인 재평가와 비교했을 때 일반적으로 부풀려졌지만, 때때로 모델 비평이 자신의 "골드 스탠다드"보다 더 유용하거나 포괄적이라고 표시하기도 했습니다. 비평-버그 포함은 각 변조된 버그에 대해 개별적으로 평가되었습니다.

데이터 수집은 여러 모델 및 모델 크기의 여러 반복을 통해 몇 달간 진행되었습니다. 수집된 데이터는 하나의 큰 훈련 세트로 병합되었으며, 세부 사항은 부록 7.2에 포함되어 있습니다. 인간이 삽입한 버그가 있는 코드의 비평 비교 외에도 수정되지 않은 샘플의 비평에서도 훈련 데이터를 수집했습니다. 수정되지 않은 입력은 비평 비교에서 평가자 간 일치율이 낮고 비평가 성능이 저하된 결과를 낳았습니다(3.5절 참조).

2.2.4 RLHF

우리의 LLM 비평가들은 [30]을 따라 다음 토큰 예측으로 사전 훈련된 GPT-4 계열의 Transformer 언어 모델입니다. 비평에 대한 특정 훈련이 모델 성능에 얼마나 영향을 미치는지 이해하기 위해 우리는 ChatGPT와 유사한 방법을 유지하려고 했습니다. 유사점과 차이점을 강조하기 위해 다음을 설명합니다:

• 이 연구에서 사용된 모든 버전의 CriticGPT와 ChatGPT는 동일한 체크포인트에서 초기화되었습니다(정책과 보상 모델 모두).
• 우리 보상 모델은 CriticGPT 검증 세트에서 성능을 극대화하기 위해 조정된 ChatGPT와 CriticGPT 데이터의 혼합으로 훈련되었습니다. 실제로 이는 모든 비평 비교 데이터를 포함했으며, 컴퓨팅 예산이 허용하는 한 많은 ChatGPT 데이터를 포함했습니다.
• CriticGPT는 ChatGPT보다 적은 컴퓨팅 자원으로 미세 조정되었습니다.
• CriticGPT의 PPO 프롬프트 분포는 보상 모델링 데이터셋에서 비평을 요청하는 프롬프트만으로 구성되었습니다.

2.3 강제 샘플링 빔 검색(FSBS)

RLHF 외에도 우리는 검색과 결합된 보상 모델을 사용하여 강제 샘플링 빔 검색(Force Sampling Beam Search)이라는 접근 방식을 사용했습니다. 이 절차를 통해 우리는 헛된 지적이나 사소한 문제의 비율을 줄이면서 더 길고 포괄적인 비평을 생성할 수 있습니다.

비평가 모델은 (질문, 답변) 쌍을 입력으로 받아 답변의 인용문과 잠재적인 문제에 대한 주석을 포함하는 구조화된 비평을 출력합니다. 비평에서 답변의 인용된 부분은 "하이라이트"로 표시되며, 이는 "```"로 시작하는 마크다운 코드 블록을 통해 인용되고, 그 하이라이트에서 발생하는 오류를 나타내는 주석이 뒤따릅니다. FSBS에서는 모델이 제한된 샘플링으로 하이라이트된 부분을 생성하도록 강제하고, 다음 표현식에 따라 최고 점수를 받은 비평을 선택합니다:

 

rm_score + LENGTH_MODIFIER * num_highlights.

 

여기서, 우리는 입력당 총 28개의 샘플에 대해 검색을 수행했습니다. 검색 중에 샘플링된 비평 길이의 10번째, 25번째, 50번째, 75번째 백분위수에 해당하는 4개의 LENGTH_MODIFIER 값을 탐색했습니다. 제한된 샘플링 및 검색에 대한 자세한 내용은 부록 7.1에 제공됩니다.

별도로 명시되지 않는 한, CriticGPT는 50번째 백분위수(RL+FSBS)에서 평균적으로 네 개의 하이라이트를 생성하는 것을 의미합니다.

 

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

3. 결과

3.1 LLM 비평은 종종 인간 비평보다 선호되며 더 많은 삽입된 버그를 잡아냅니다

우리의 방법이 모델 비평을 개선한다는 첫 번째 증거로, 모델이 작성한 비평이 비교 작업에서 더 높은 전반적인 평가를 받는 비율을 추적합니다. 그림 1a는 CriticGPT가 작성한 비평이 프롬프트된 ChatGPT와 우리 계약자 그룹에서 작성한 인간 비평보다 계약자들에게 전반적으로 상당히 선호됨을 보여줍니다. 이 집단과 해당 인간 비평 세트는 가능한 최고의 인간 성과를 나타내지는 않지만, ChatGPT에 사용된 계약자 집단을 대표합니다. 같은 인간 비평 세트를 사용하여 두 번째 사람이 삽입된 버그를 잡아내는 비율을 비교할 수 있습니다. 그림 1b에서 우리는 Tamper+RLHF 파이프라인이 삽입된 버그를 잡아내는 비율을 크게 향상시키며, 두 LLM 비평가(프롬프트된 ChatGPT와 CriticGPT)가 인간 평가자보다 훨씬 더 많은 버그를 잡아냄을 알 수 있습니다.

우리는 성능 차이의 원인을 이해하기 위해 인간 비평을 자세히 살펴보았습니다. 일반적으로 계약자들은 (평균 처리 시간이 50분임에도 불구하고) LLM 도움 없이 전체적인 코멘트를 적게 작성했습니다. 많은 작업이 도메인 지식을 필요로 했으며, 계약자들은 비록 비중요한 Python 경험을 가지고 있었지만 특정 Python 라이브러리에 대한 도메인 지식이 부족한 경우가 분명했습니다. 일부 변조된 버그는 발견하기 매우 어려웠습니다. 우리의 견해로는 이러한 세 가지 현상(짧은 코드 리뷰, 도메인 지식 부족, 작업 난이도)이 LLM에 비해 계약자의 성능 저하의 주요 원인입니다.

(a) 계약자들이 동일한 코드에 대한 비평을 비교할 때, CriticGPT(RL 전용)는 모델 스케일 전반에 걸쳐 인간 삽입 버그에서 프롬프트된 ChatGPT보다 상당히 선호됩니다.

 

(b) 계약자들은 CriticGPT(RL 전용)가 삽입된 버그를 프롬프트된 ChatGPT보다 훨씬 덜 놓친다고 표시합니다. 더 큰 모델을 훈련하는 것도 삽입된 버그를 놓치는 비율을 줄이지만, 이 분포에서 CriticGPT(RL 전용)의 성능을 맞추기 위해서는 사전 훈련 컴퓨팅을 약 30배 늘려야 합니다.

 

3.2 CriticGPT RL 훈련은 사전 훈련 스케일 전반에 걸쳐 모델을 개선합니다

버그를 감지하는 비율을 높이는 또 다른 방법은 단순히 더 큰 모델을 사용하는 것입니다. 우리는 그림 5에서 RLHF로 훈련되고 평가된 모델 군을 통해 이 설정에서 모델 스케일이 버그 감지에 미치는 영향을 특징짓습니다. 각 모델은 GPT-4 계열의 Transformer이며, 우리는 사전 훈련에 사용된 GPT-4 컴퓨팅의 비율로 그 크기를 기록합니다. 이것은 또한 추가 데이터나 ChatGPT 파이프라인 수정 없이 CriticGPT(RL 전용)의 성능을 달성하기 위해 필요한 추가 사전 훈련 컴퓨팅 양을 순진하게 추정할 수 있게 해주며, 이는 약 30배에 해당합니다.

3.3 CriticGPT는 인간이 더 포괄적인 비평을 작성하는 데 도움을 줍니다

CBI와 전반적인 선호도에 대한 결과는 CriticGPT의 삽입된 버그에 대한 성능을 보여줍니다. 그림 6과 7은 모델들이 기존의 RLHF 파이프라인에서 계약자들이 이전에 잡아낸 인간이 발견한 버그에서도 잘 작동함을 보여줍니다. 이 설정에서 Human+CriticGPT 팀이 인간 단독보다 훨씬 더 포괄적인 비평을 작성하고, CriticGPT가 인간이 발견한 버그와 삽입된 버그 모두에서 ChatGPT보다 포괄성을 향상시킴을 강조합니다. 그러나 모델의 경우 헛된 지적과 허위 버그의 비율이 인간보다 훨씬 높지만, CriticGPT는 이 비율을 ChatGPT보다 상당히 줄일 수 있습니다. Human+CriticGPT 팀은 인간과 CriticGPT 사이의 중간 수준의 헛된 지적/허위 버그 비율을 가집니다.

 

그림 6: 인간은 LLM 비평가의 도움을 받아 훨씬 더 포괄적인 비평을 작성합니다. 인간-기계 팀은 포괄성을 증가시키지 않지만, 환각률에 미치는 긍정적인 영향에 대해서는 3.4절을 참조하십시오.

 

그림 7: 인간 비평에는 LLM 비평보다 사소한 문제와 환각이 훨씬 적습니다. CriticGPT는 ChatGPT 기준선에서 이 비율을 크게 줄입니다. 인간-기계 팀은 CriticGPT와 ChatGPT보다 환각과 사소한 문제를 덜 발생시킵니다.

 

3.4 FSBS는 포괄성과 환각 간의 균형을 조절할 수 있게 해줍니다

프로젝트 전반에 걸쳐, 비평이 주장하는 문제의 수가 증가할수록 버그를 잡을 확률도 증가한다는 것을 발견했습니다. 이는 놀라운 일이 아닙니다. 문제 목록이 길수록 특정 문제와 사소한 문제를 모두 포함할 가능성이 더 높기 때문입니다. 2.1.1에서 설명한 것처럼, 우리는 계약자들에게 비평이 포괄적인지 여부와 사소한 문제나 환각된 문제를 포함하고 있는지 여부를 모두 묻습니다. 절대적인 길이와 유사하게, 우리는 버그를 더 자주 환각하는 모델이 인간이 삽입한 버그와 이전에 감지된 버그를 잡아낼 가능성이 더 높다는 것을 발견했습니다.

 

이는 정밀도와 재현율의 유사점으로 볼 수 있습니다. 비공식적으로, 더 정밀한 비평 모델은 각 주장된 문제가 더 사실일 가능성이 높고, 더 나은 재현율을 가진 모델은 주어진 삽입된 버그를 잡아낼 가능성이 더 높은 모델입니다. 불행히도, 비평을 사용하여 모델 성능을 향상시키는 전체 RLHF 시스템에서 환각과 버그 감지 간의 적절한 균형이 무엇인지 명확하지 않습니다. 이상적인 실험은 각 정밀도/재현율 지점에 대해 완전히 별개의 비평 강화 RLHF 데이터 수집 루프를 실행하는 것이겠지만, 이는 매우 비용이 많이 듭니다.

 

FSBS(2.3에 자세히 설명됨)는 이를 완화하기 위해 우리의 보상 모델과 테스트 시간 검색을 사용합니다. 스칼라 길이 페널티를 변경함으로써, 우리는 포괄성과 잘못된 주장 간의 파레토 곡선을 설정할 수 있으며, 이는 그림 8에 나와 있습니다. FSBS는 배포 시 비평 모델을 재훈련하지 않고도 RLHF 데이터 수집을 위한 좋은 균형을 선택할 수 있게 해줍니다. 부록 7.1에서는 ChatGPT와 우리의 보상 모델을 결합하는 것이 덜 효과적임을 보여줍니다. 이러한 균형을 고려하면 인간-기계 팀의 이점도 드러납니다. 함께 작업할 때(Human+CriticGPT 팀, 2.1.3에서 설명한 대로) 인간-기계 팀은 모델 전용 파레토 전선을 넘어섭니다. 이 인간이 감지한 버그 평가에서 RL-only CriticGPT는 ChatGPT 기준선보다 덜 포괄적일 수 있습니다. 이는 두 가지 효과에 의해 발생한다고 생각합니다. 첫째, RL-only CriticGPT는 더 보수적이며, 재현율의 대가로 훨씬 더 높은 정밀도를 가진 비평을 생성합니다. 둘째, ChatGPT와 CriticGPT 사이의 컴퓨팅 감소가 있었습니다. FSBS는 더 포괄적인 비평을 결과로 냅니다.

 

그림 8: 우리는 비평가의 잘못된 주장 수와 비평의 포괄성 간에 트레이드오프가 있음을 발견했습니다. FSBS를 사용하여 포괄성과 환각을 조절할 수 있지만, RLHF 파이프라인에서 평가자의 성능을 향상시키는 최적의 균형이 무엇인지 현재 알지 못합니다. 결과는 인간이 발견한 버그 분포에서 보여집니다.

 

3.5 연구의 축소(Abalations)

이 논문에서 사용된 ChatGPT의 생산 버전은 우리의 연구 모델보다 훨씬 더 많은 데이터와 컴퓨팅 자원을 사용하여 훈련되었습니다. 더 가까운 비교를 위해 우리는 ChatGPT 데이터의 하위 집합을 사용하고, 훈련 기간 및 하이퍼파라미터 설정을 CriticGPT 모델과 더 유사하게 맞춘 보상 모델(RM)과 정책을 훈련했습니다. 정책 모델의 체크포인트는 검증 세트에서 인간이 삽입한 버그에 대한 CBI(비평-버그 포함)를 최대화하기 위해 선택되었습니다. 이 접근 방식은 데이터 수집 방법의 영향을 훈련 기간과 파이프라인 설정의 영향에서 더 잘 분리하여 깨끗한 비교를 제공합니다. 이 버전의 ChatGPT는 그림 8에서 "ChatGPT (less training)"로 표시됩니다. 이 더 가까운 참조점과 비교했을 때, CriticGPT (RL 전용)는 인간이 발견한 버그가 있는 코드에서 더 높은 정밀도와 재현율을 가지고 있습니다. 우리 데이터로 훈련하는 것이 일반적인 ChatGPT 데이터셋으로 훈련하는 것보다 코드 비평가를 만드는 데 더 효과적입니다. 이는 인간이 발견한 버그로 일반화할 때도 마찬가지입니다(일반화에 대한 논의는 부록 7.6 참조).

 

또한 수정되지 않은 코드에 대한 비평 비교만 포함한 CriticGPT 모델의 성능도 조사했습니다. 즉, 데이터 파이프라인에서 변조 단계를 제외한 것입니다. 우리는 변조 데이터 없이 우리의 컴퓨팅 예산에서 모델이 삽입된 버그와 발견된 버그에 대한 자동 평가(2.1.1에서 설명한 인간 평가를 GPT-4로 복제한 평가)에서 성능이 크게 저하됨을 발견했습니다. 이러한 평가 결과는 인간 평가를 여기서 제시하지 않습니다. 이는 참조 버그가 없는 비교에서 평가자 간 일치율이 낮아져 이 설정에서 성능을 저하시키는 보상 모델이 나왔기 때문이라고 추측합니다.

 

4. 관련 연구

LLM 비평 및 관련 방법들은 두 가지 뚜렷한 과거 연구 흐름에서 탐구되었습니다.

첫 번째는 자가 수정(self-correction)에 초점을 맞춰, 자가 비평(self-critique)을 통해 최종 LLM 응답의 품질을 개선하기 위해 추가적인 컴퓨팅 자원을 사용합니다. 자가 수정 및 밀접하게 관련된 방법들은 무해성 [1], 사실성 [24], 컴퓨터 제어 [14], 도덕적 추론 [5] 및 다른 도메인에서 개선을 주장해왔습니다 [20, 4, 7]. 일반적으로 자가 수정 방법은 비평 단계에서 추가적인 사이드 채널 정보를 사용하는 경우에 더 명확하게 성공했으며, 추가 정보 없이 “내재된 자가 수정(intrinsic self-correction)” 설정에서는 덜 성공적이었습니다 [10].

자가 수정 연구와 대조적으로, 확장 가능한 감독(scalable oversight)은 기본 모델의 능력을 향상시키는 것이 아니라 인간 심판이 모델 응답을 올바르게 평가하는 능력을 향상시키고자 합니다 [2]. 여러 감독 방법들은 실질적으로 가능해지기 전에 이론적으로 제안되었습니다. 여기에는 토론(Debate), 재귀적 보상 모델링(Recursive Reward Modeling), 시장 형성(Market Making)이 포함됩니다 [12, 15, 11]. 이러한 제안 이후 진행된 연구는 인간-기계 팀이 인간만 또는 기계만을 기준으로 한 베이스라인보다 MMLU 및 QuALITY에서 정확도를 향상시킬 수 있음을 실증적으로 보여주었습니다 [2]. 특히 토론은 다중 에이전트 RL을 위한 실행 가능한 알고리즘임이 증명되었으며 [23], 더 설득력 있는 LLM과의 토론이 QuALITY에서 심판의 정확도와 긍정적인 상관관계가 있음을 보여주었습니다 [13].

과거 연구는 인간 코드의 품질을 향상시키기 위해 코드 리뷰에 딥러닝을 사용하는 것도 조사했습니다 [9, 17]. 우리의 시스템은 훨씬 더 강력한 사전 훈련된 모델을 활용할 수 있기 때문에 매우 다르며, 이를 주로 LLM이 작성한 코드를 검토하는 작업에 적용합니다.

CriticGPT와 가장 가까운 전신은 Saunders et al. [26]이며, 이는 비평을 생성하기 위해 직접 모델을 훈련시켰습니다. 이에 비해 우리는 RLHF, 더 큰 모델, 더 도전적인 실제 평가 환경을 사용합니다.

 

5. 토론 및 한계

확장 가능한 감독의 궁극적인 목표는 인간이 모델 출력을 평가하여 더 나은 안전한 정책을 훈련할 수 있도록 돕는 것입니다. 따라서 비평에 대한 이상적인 평가는 인간 계약자가 비평 지원을 받은 RLHF와 그렇지 않은 RLHF에서 작성한 코드의 최종 정책 품질을 비교하는 것입니다. 불행히도 이는 비용이 많이 들기 때문에, 우리는 여기서 계약자가 더 많은 버그를 잡을 수 있도록 돕는다면 결과 데이터가 정책을 개선할 것이라고 가정합니다. 이 가정이 항상 맞지 않을 수 있는 이유 중 하나는, 비평가가 일부 인간 편향을 제거하는 데 도움이 되더라도, 새로운 편향을 도입하여 일관된 편향된 레이블이 RLHF 성능을 저하시킬 수 있다는 점입니다. 이는 여기서 사용된 접근 방법과 평가의 여러 한계 중 하나입니다. 또 다른 주요 문제는 삽입된 버그의 분포가 자연 발생 LLM 오류의 분포와 매우 다르다는 점입니다. 미세한 분포 내 문제를 삽입하도록 모델을 훈련시키는 것이 이 문제를 완화할 수 있지만, 이는 향후 연구로 남겨둡니다. 비평 접근 방식은 또한 재귀적 보상 모델링(RRM)의 첫 번째 단계일 뿐이며, 추가적인 RRM 단계가 언제 적절한지 또는 비평이 RRM에 효과적으로 사용될 수 있는지 알지 못합니다. 다른 여러 한계는 다음과 같습니다:

• 우리의 평가에서 사용된 LLM 코드 스니펫은 일반적으로 매우 짧습니다. 다중 파일 지원이 없고 리포지토리 탐색도 없습니다. 그래서 현재 ChatGPT와 비슷해 보이지만, 미래의 에이전트를 대표하지 않습니다.
• 우리의 방법이 사소한 문제와 허위 버그의 비율을 줄였음에도 불구하고, 그 절대 비율은 여전히 매우 높습니다.
• 현실 세계의 복잡한 버그는 프로그램의 여러 줄에 걸쳐 분포될 수 있으며, 단순히 지역화하거나 설명하기 어려울 수 있습니다. 우리는 이 경우를 조사하지 않았습니다.
• 단일 비평 단계는 사용자에게 문제를 설명할 수 있는 컨설팅이나 토론과 같은 다중 단계 대화식 절차보다 상당히 약할 수 있습니다 [15, 12].

강력한 버그 감지 기술은 소스 코드 접근과 모델을 통해 공격자가 그렇지 않으면 찾을 수 없는 취약점을 찾을 수 있게 함으로써 이중 용도로 사용될 가능성도 있습니다. 사이버 공격과 방어에 대한 LLM의 영향 분석에 대해서는 [8]을 참조하십시오. 우리는 CriticGPT가 사이버 보안 지형을 변화시킬 정도로 버그 감지를 개선했다고 생각하지 않습니다..

 

6. 결론

대형 언어 모델은 이제 일반적인 인간이 도움 없이 일관되게 그 출력을 평가할 수 있는 능력을 넘어섰습니다. 이는 박사 수준의 과학 질문에 대한 강력한 성능을 보여준 시연 등에서 분명히 나타났습니다[25]. 인간이 모델 출력을 올바르게 평가할 수 있도록 돕는 방법으로 널리 이해되는 확장 가능한 감독의 필요성은 그 어느 때보다 강력합니다. RLHF가 유용한 어시스턴트로 LLM을 후속 훈련하는 주요 수단으로서 지배적인 상태를 유지하든 아니든, 특정 모델 출력이 신뢰할 수 있는지 여부를 평가해야 하는 문제는 여전히 남아 있습니다. 여기에서 우리는 인간이 모델을 평가하는 데 도움을 주는 모델을 훈련시키는 매우 직접적인 접근 방식을 취합니다.

이러한 LLM 비평가는 이제 실제 데이터에서 버그를 잡는 데 성공했으며, ChatGPT와 같은 접근 가능한 LLM 기준선도 인간 평가자를 돕는 데 상당한 잠재력을 가지고 있습니다. 이 시점부터 LLM과 LLM 비평가의 지능은 계속해서 향상될 것입니다. 반면에 인간의 지능은 그렇지 않을 것입니다. 따라서 AI 시스템이 우리보다 훨씬 더 똑똑해지더라도 올바른 행동에 보상을 주는 확장 가능한 방법을 찾는 것이 필수적입니다. 우리는 LLM 비평가가 유망한 출발점이라고 생각합니다.

감사의 글

Jan Leike와 Ilya Sutskever의 초월적 정렬에 대한 비전에 감사드립니다. Collin Burns, Jeffrey Wu, Dan Mossing, John Schulman에게 원고에 대한 자세한 피드백을 주셔서 감사드립니다. Jiayi Weng, Suchir Balaji 등 많은 분들이 후속 훈련 스택에서 큰 도움을 주셨습니다. 프로젝트 막바지에 지원해 준 Barret Zoph와 훌륭한 GPU 인프라를 제공해 준 OpenAI 플랫폼 팀, 많은 지원을 해 준 인간 데이터 팀에도 감사드립니다. 마지막으로, 훈련 데이터를 제공하고 프로젝트 전반에 걸쳐 우리 모델을 평가해 준 평가자 팀에게도 감사드립니다.

 

llm-critics-help-catch-llm-bugs-paper.pdf

1.17MB