핵심 : RLHF으로 학습하고 일부러 error를 넣는 tampering 과정을 거친 CriticGPT 모델은 버그를 잘 잡아낸다.
0. Abstract
RLHF는 결국 인간이 해야 한다는 점에서 양적으로나 질적으로나 제한이 된다. 따라서, 이 연구에서는 ‘Critic’ 모델 자체를 RLHF로 학습시켜 극복하고자 한다. 실제로 ChatGPT를 훈련시키는데 사용된 데이터 중에, 오류가 없다고 평가된 것들에서도 많은 오류를 발견하였다. 또한, 63%의 경우에 대해서 인간이 평가한 것보다 모델이 평가한 것을 선호하는 것도 확인하였다. LLM만으로는 hallucination이 발생하기도 하지만, human-machine이 같이 작업을 했을 때는 hallucination이 줄어들었다.
1. Introduction
AI에게 이상적인 output을 제공하는 것보다 AI의 output을 평가하는게 더 빠르고 쉽다는 점을 활용하여, RLHF는 AI를 학습시키는데 많이 사용되었다. 하지만 huma evaluation는 한계가 있기도 하고, 오류나 bias가 들어갈 수도 있다.
“scalable oversight”라는 분야가 이러한 문제를 해결하는 것과 관련되어 있는데, LLM의 성능이 인간의 능력을 초과하는 상황에서 AI의 출력을 효과적으로 평가하고 감독할 수 있는 방법을 의미한다. 해당 연구에서는 기존의 debate 방식보다 더 이해하기 쉽고, real-world task(e.g. 코딩)에서도 도움이 되는 방식을 소개한다.
핵심 아이디어는 (question, answer) 쌍을 input으로 받고, 답변에서 error를 output하는 policy를 학습시키는 것이다. 기존 연구들과는 다르게 RLHF를 사용해서 critic model을 학습시킨다.
해당 방법으로 더 정확도를 높이고 human 평가보다 선호되었으며, human-machine이 팀으로 작업하였을 때는 hallucination도 줄어들고 중요하지 않은 사소한 오류(nitpick)를 건드리는 빈도가 줄어들었다.
2. Methods
(question, answer) 쌍을 input으로 받고, 답변에서 문제가 될 수 있는 부분들을 지적하는 내용의 텍스트를 output으로 가진다. output은 문제가 되는 위치에 댓글을 남기는 형식이다.
2.1 Evaluation
2.1.1 Critique Attributes
두 개의 평가가 있을 때, 첫번째 평가는 아주 심각한 에러를 잡아내는 내용과 false alarm이 포함되어 있고 두번째 평가는 아주 사소한 에러만 잡았다고 가정할 수 있다. 어떤 critique이 더 유용한지를 판단하기 위해 여러개의 기준으로 분리할 수 있다:
- 확실하고 심각한 에러를 놓치지 않았는지.
- 이미 알아낸 특정 버그를 포함했는지, “critique-bug inclusion (CBI)”.
- hallucination이나 nitpick을 포함하였는지.
- 스타일이나 전반적인 효용도에 도움이 되었는지.
2.1.2 Critique Comparisons & Elo Scores
총 4개의 critique이 생성되었을 때 여러 기준들에 대해서 비교를 한다. 각 기준마다 점수화를 한 다음에 Elo score를 활용해서 모델간의 비교를 한다.
2.1.3 Human Critiques & LLM Assistance
critique들을 비교하는 것과 더불어, 모델이 스스로 critique를 생성하도록 했다. 기존 critique들에도 접근 권한이 있었고, 기존 critique들과 비교해보았을 때 보통은 그 평가를 유지하거나 일부 내용을 생략한 것을 확인할 수 있었다. 낮은 확률로 새로운 내용을 추가했다.
2.1.4 Evaluation Data Distribution
training과 evaluation에 사용된 데이터들은 OpenAI RLHF 파이프라인에서 모두 들고 왔다. (question, answer) 쌍에서 answer에 50% 이상이 코드인 데이터들만 추출해서 사용했다. 크게 2가지 유형으로 나눌 수 있는데 ① 일부러 에러를 삽입한 코드, ② 에러를 발견한 코드가 있다. 첫번째 데이터 유형이 에러를 발견하기 더 어려운 경향이 존재한다.
2.2 Training Critics with RLHF
ChatGPT와 유사한 RLHF 파이프라인을 사용해서 LLM critics를 학습시킨다.
- 각 (question, answer) 쌍에 대해서 여러개의 critique를 샘플링한다.
- 샘플링된 critique들을 여러 기준에 따라 평가한다.
- human 평가를 예측하기 위한 reward 모델을 학습시킨다.
- PPO(Proximal Policy Optimization)를 활용하여 reward 모델을 최적화한다.
- Force Sampling Beam Search (FSBS)이라는 inference-time 샘플링 방법을 활용한다.
2.2.1 Step 0: Tampering
이 부분에서는 contractor에게 모델이 생성한 답변에 눈치채기 어려운 버그를 집어넣게 한다. LLM critic에 접근할 수 있기 때문에 adversarial하게 Tampering을 진행하여 더욱 알아채기 어려운 버그들을 만든다. 코드가 인위적으로 수정되었는지 판별하는 discriminator는 작은 모델의 경우 성능이 잘 안나왔지만, scale을 키울수록 더 나아지는 것을 확인할 수 있었다.
2.2.2 Why Tampering?
Tampering 과정을 진행하는 이유는 ground-truth가 없는 long-form과 open-ended task에도 적용하기 위함이다. 만약 수정하지 않은 답변에 대해서만 학습하면, 스타일에 의한 차이를 과학습하거나 critique을 검증하기 어려워지고 충분한 답변을 얻지 못할 수도 있다.
Tampering을 함으로써 고품질, 난이도가 있는 버그들을 학습하여, 실제로 critique을 생성할 때 오류를 놓치는 확률을 줄일 수 있다.
2.2.3 Critique Comparisons in Detail
생성된 critique 3개와 ground truth로 존재하는 critique을 비교하며 가장 도움이 되거나 포괄적인 critique를 선책하게 된다. 이런 방식으로 여러 모델과 모델 크기로 데이터를 수집하여 하나의 training set으로 만들었다.
2.2.4 RLHF
ChatGPT와 유사한 부분이 많지만, 해당 연구인 CriticGPT는 ChatGPT보다 연산량이 적다. 동일한 체크포인트(policy와 reward model)를 용했지만, 데이터는 ChatGPT 데이터도 섞어서 학습되었다.
2.3 Force Sampling Beam Search
RLHF와 함께 Force Sampling Beam Search라는 reward model도 탐색에서 같이 사용했다. 더 길고 포괄적이지만, hallucination이나 nitpick은 줄어든 critique를 생성한다.
잠재적으로 문제가 될 수 있는 부분들에 대해 하이라이트한 뒤에, error에 대한 내용을 주석으로 작성하였다. 이렇게 생성된 여러 critique들 중에 가장 점수가 좋은 것들을 선택하여 최종 critique으로 사용한다.
3. Results
3.1 LLM critiques are often preferred over human critiques and catch more inserted bugs
CriticGPT가 생성한 critique들이 더 많이 선호되고, 실제로도 더 많은 에러/버그를 잡는 것을 확인할 수 있었다. human critique의 경우, 코드 리뷰가 더 짧고, 특정 라이브러리에 대해서는 잘 몰라서 더 오래 걸리고, 어려운 버그는 잘 잡지 못하는 경향성을 보여줬다.
3.2 CriticGPT RL training improves models across pre-training scale
모델 크기를 늘리는 것도 버그를 더 잘찾게 하는 방법 중 하나이다. 여러 GPT-4 모델들을 비교했을 때, CriticGPT(RL only)와 유사한 성능을 달성하기 위해서는 기존 ChatGPT 모델들은 약 30배 더 많은 데이터를 필요로 한 것을 확인할 수 있었다.
3.3 CriticGPT helps human write more comprehensive critiques
Human+CriticGPT 유형으로 critique을 작성했을 때, Human만이 critique을 작성한 것보다 더 포괄적으로 좋은 피드백을 작성해주는 것을 확인할 수 있었다. 단, model이 critique을 작성했을 때는 human critique의 경우보다 hallucination 및 nitpick의 비율이 높은 경향성이 있었다. Human+CriticGPT의 경우에는 human critiquer과 CriticGPT critique의 중간 정도의 비율을 보여준다.
3.4 FSBS lets us navigate tradeoffs between compreensiveness and hallucinations
critique이 많은 내용을 포함할수록, 답변 길이가 더 길어질수록 버그를 잡을 확률 자체는 높아진다. 그 단점으로는nitpick/hallucination의 비율은 늘어난다는 것이다. 더 precise한 모델을 선택하면 버그를 잡을 확률은 낮아지기 때문에, 가장 적절한 tradeoff를 선택하는 것은 어려울 수도 있다. 이상적인 것은 하이퍼하라미터 튜닝하듯이 여러 실험을 하는 것이지만, 리소스가 많이 든다는 단점이 있다.
이때 사용하는 것이 FSBS(앞서 설명된 Force Sampling Beam Search) 이다. 추가적인 학습이 필요하지 않고, 바로 test time때 사용할 수 있다는 장점이 있다. 적절하게 nitpick/hallucination은 줄이면서, 정확하게 버그를 잡아내는 것에
3.5 Ablations
먼저 ChatGPT의 경우, 학습에 사용된 데이터셋의 크기가 매우 크다. 공정한 비교를 위해서 hyperparameter는 CriticGPT와 유사하게 하되, ChatGPT의 데이터셋의 subset으로 학습을 하였다. 해당 경우에도 CriticGPT의 성능이 더 좋은 것을 확인할 수 있었다.
tampering 과정의 유무로도 ablation 실험을 진행했을 때, tampering data가 없는 경우에 성능이 크게 떨어지는 것을 확인할 수 있었다.
3.6 LLM critics generalize beyond code
코드에서의 실험이 아니라, general한 assistant task에 대해서도 실험을 진행했을 때 CriticGPT가 잘 수행하는 것을 확인할 수 있었다. sampling된 critique이 높게 평가된 data와 task에 대해서 우선순위를 높게 했을 때, 에러를 더 잘잡고 hallucination이 줄어드는 등 성능이 더 개선되는 것을 확인할 수 있었다.
4. Related Work
LLM critique의 경우에는 크게 두가지 유형으로 기존 연구들이 존재한다.
기존에는 self-correction 방식으로 LLM의 최종 답변의 quality를 높이는 시도들이 존재하지만, 보통은 추가적인 정보를 활용하는 것이지 intrinsic하게 진행하는 방식은 아니다.
self-correction과 반대로, scalable oversight, human judge가 판단하기가 쉬운지를 측정하는 시도들도 존재한다. Debate, Recursive Reward Modeling, Market Making이 유사한 시도들이다.
5. Discussion & Limitations
RLHF로 학습된 policy와 인간이 critique 보조가 없이 작성한 policy와 비교를 하기에는 resource가 너무 들어서 어렵다. RLHF는 기존 human bias를 줄일 수도 있지만, 새로운 bias를 생성할 수 있다는 점에서, 무조건 성능이 좋아진다고 말할 수 없다는 단점이 존재한다.
LLM이 일부러 넣은 버그와, 실제로 자연스럽게 생성된 버그의 분포가 달라서 학습에 어려움이 있을 수도 있다. 또한, 코드가 무조건 하나의 파일에서, 에러는 꼭 한줄에 해당된다는 제한적인 전제 안에서만 실험되었다는 한계도 존재한다.
CriticGPT가 취약점을 찾는 것에 악용될 수도 있다는 위험도 존재하지만, 실제로 현실 세계에 영향을 줄만큼의 버그 탐지를 하지 못한다고 밝힌다.
6. Conclusion
기존의 LLM은 본인의 output을 평가하는 능력이 있다고 보지만, scalable oversight, human이 더 정확하게 평가할 수 있도록 도와주는 능력은 RLHF로 학습하여 달성할 수 있다고 설명한다.
