Self-Refine: Iterative Refinement with Self-Feedback

https://arxiv.org/pdf/2303.17651

---

Abstract:

• 대형 언어 모델(LLM)은 사람과 마찬가지로 첫 시도에서 항상 최상의 결과를 내지 않는다고 함. 이 논문은 사람들이 글을 수정하는 방식에서 영감을 받아, LLM의 초기 출력을 반복적인 피드백과 개선 과정을 통해 향상시키는 접근법을 제안하는 논문임.
• 주요 아이디어는 다음과 같다:
  • 초기 출력 생성: LLM을 사용하여 첫 번째 출력을 만듬.
  • 자기 피드백 제공: 동일한 LLM이 자신의 출력에 대한 피드백을 생성함.
  • 출력 개선: 피드백을 바탕으로 출력을 반복적으로 수정하고 향상 시킴.
• Self Refine 기법은 추가적인 훈련이 필요하지 않고, 오로지 하나의 LLM 으로만 성능을 개선시킬 수 있는 방법이다.
• 이 기법으로 실험을 해보니 SELF-REFINE를 통해 생성된 출력물이 동일한 LLM으로 한 번에 생성한 결과보다 인간 평가자와 자동 평가 지표에서 더 선호되었다고 함.
• 작업 성능이 평균적으로 약 20% 절대적으로 향상되었다고 한다.

 

 

Introduction:

• LLM은 일관된 출력을 생성할 수 있지만, 복잡한 요구사항을 충족하는 데에는 종종 부족함이 있을 수 있다고 함.
• 이런 시나리오에서 LLM은 초기에는 이해할 수 있는 출력을 생성하지만, 원하는 품질을 달성하기 위해서는 추가적인 반복적 개선이 필요할 수 있다.
• 반복적 자기 개선은 인간이 문제 해결을 하는 근본적인 특징이기도 함. 초기 초안을 작성하고, 스스로 제공한 피드백을 기반으로 이를 개선하는 프로세스임.
• SELF-REFINE 방법은 피드백(feedback) 과 개선(refine) 을 번갈아 반복적으로 수행해서 개선하는 방법임:
  • 초기 출력 생성: 모델 M이 첫 출력을 생성함.
  • 피드백 획득: 이 출력을 동일한 모델 M에 다시 전달하여 피드백을 얻음.
  • 출력 개선: 피드백을 기반으로 이전 초안을 개선함.
  • 반복 수행: 지정된 횟수만큼 반복하거나, 모델 M이 더 이상의 개선이 필요 없다고 판단할 때까지 반복한다.
• Self Refine 기법의 실험 결과는 다음과 같음:
  • 자연어 및 소스 코드 생성 등 다양한 도메인의 7가지 생성 작업에서 SELF-REFINE를 평가해봤다고 함
  • GPT-3.5와 GPT-4와 같은 강력한 LLM의 직접 생성보다 5-40%의 절대적 성능 향상을 보여줬다고 한다.
  • Codex와 같은 강력한 코드 모델에 적용했을 때 초기 생성보다 최대 13%의 절대적 향상을 이뤘다고 한다.

 

 

SELF-REFINE를 통한 반복적 개선:

• 알고리즘 개요:
  • a) 초기 출력 생성 (Initial Generation): 모델 M이 입력 x와 생성 프롬프트 pgen을 기반으로 초기 출력 y₀를 생성
  • b) 피드백 단계 (FEEDBACK): 동일한 모델 M이 자신의 출력 yₜ에 대한 피드백 fbₜ를 생성. 피드백은 아마도 다양한 면을 다룰거임. 코드 최적화 예시 기준으로는 efficiency, readability, and overall quality of the code 측면에서 피드백을 작성해달라고 요청할거임 구체적이고, 실행가능한 특징을 가진 피드백으로. 
  • c) 개선 단계 (REFINE): 모델 M이 피드백 fbₜ를 바탕으로 출력을 개선하여 새로운 출력 yₜ₊₁을 생성. 입력-출력-피드백-개선된 출력의 4중쌍을 포함해야한다.
  • d) 반복 및 종료 조건: 피드백과 개선 단계를 지정된 횟수만큼 반복하거나, 모델 M이 더 이상의 개선이 필요 없다고 판단할 때까지 반복. 종료 조건은 피드백에서 추출된 지표나 지정된 반복 횟수에 따라 결정될 수 있다.
• 프롬프트 구성:
  • pgen (생성 프롬프트): 작업에 특화된 few-shot 예시를 포함하여 초기 출력을 생성
  • pfb (피드백 프롬프트): 실행 가능하고 구체적인 피드백을 생성하도록 모델을 안내
  • refine (개선 프롬프트): 피드백을 바탕으로 출력을 개선하는 방법을 모델에게 제시
• 이전 반복에서 발생한 오류나 개선 사항을 학습하여, 모델이 동일한 실수를 반복하지 않도록 하는게 중요

 

 

대화 응답 작업 기준으로 피드백은 다음처럼 여러가지 관점에서 생성될 수 있음:

 

Refine 프롬프트는 상대적으로 간단하다: 

• "Okay, let's use this feedback to improve ... " 라는 지시와 함께 피드백과 개선하고자 하는 응답을 제공해주면 됨.

 

Self-Refine 실험 결과:

• SELF-REFINE는 모든 모델 크기에서 기본 모델 대비 일관되게 성능을 향상시켰음.
• 제약 조건이 있는 생성(Constrained Generation)에서의 높은 성능 향상을 이뤘다고 함. 첫 시도에서 일부 개념을 놓칠 가능성이 높아, SELF-REFINE를 통해 이러한 누락된 개념을 후속적으로 수정할 수 있기 때문
• 대화 응답 생성에서 GPT-4의 선호도 점수가 49.2% 향상되어 25.4%에서 74.6%로 증가했다고 한다.
• 반면 수학에서는 오류를 정확하게 식별하기 어려워 성능 향상이 제한적이었다고 함. 오류는 미묘할 수 있고, 한 줄 또는 잘못된 연산에 국한될 수 있기 때문. 일관성 있어 보이는 추론 과정이 LLM으로 하여금 “모든 것이 좋아 보인다”고 착각하게 만들 수 있다고 함. (오류를 식별하는 매커니즘도 중요할 수 있다.) 
• 선호도 기반 작업에서의 큰 성능 향상을 이뤘다고 함:
  • 선호도 기반 작업은 출력물이 객관적인 정답이 없는 경우가 많으며, 인간의 주관적인 판단에 크게 의존하는 작업임.
  • 예를 들면 대화 응답 생성이나 감정 반전과 같은 작업에서는 문장의 자연스러움, 맥락 적합성, 감정 표현 등이 중요한 경우.
  • 이 작업에서 모델은 인간 평가자가 중요하게 생각하는 요소들을 고려해서 피드백을 할거임. 그래서 인간이 선호하는 여러 조건을 빠지지 않고 반영해서 높은 성능을 이뤄낼 수 있다.

 

 

결과 분석:

• 피드백의 중요성:
  • 피드백의 품질은 SELF-REFINE의 성능에 결정적인 역할을 함.
  • 구체적이고 실행 가능한 피드백: 문제점을 정확히 지적하고 명확한 개선 방향을 제시하는게 중요.
  • 일반적인 피드백은 정확성과 방향성이 부족함.
  • 코드 최적화 작업에서 구체적 피드백 사용 시: 성능 점수 27.5, 일반적 피드백 사용 시: 성능 점수 26.0, 피드백 없음: 성능 점수 24.8 을 이뤘다고 함. 
    • 구체적 피드백 예시: “for 루프에서 반복 계산을 피하세요.”
    • 일반적 피드백 예시: "코드의 효율성을 향상시키세요.” (무시할 가능성도 생김) 
• 반복적인 FEEDBACK-REFINE의 중요성:
  • 반복 횟수가 증가함에 따라 출력의 품질이 전반적으로 향상된다고 함.
  • 코드 최적화 작업: 초기 출력(y₀)의 점수는 22.0에서 세 번의 반복 후(y₃) 28.8로 증가했다고 한다.
  • 감정 반전 작업: 초기 출력의 점수는 33.9에서 세 번의 반복 후 36.8로 증가.
  • 다만 반복 횟수가 증가할수록 향상의 폭은 줄어드는 경향을 보인다고 함. (최적의 반복 횟수를 찾아야 할 수도 있다.) 
• Self-Refine 기법 대신 단순히 여러 출력을 생성하는 것 (= Self-Consistency) 으로 대체할 수 있는가?
  • SELF-REFINE의 성능 향상이 반복적인 개선 때문인지, 아니면 단순히 더 많은 출력을 생성하기 때문인지 확인해봤다고 함.
  • SELF-REFINE의 출력과 ChatGPT의 초기 k개의 출력물을 비교하여 SELF-REFINE가 모든 초기 출력보다 우수한지 평가해봤다고 한다.
  • SELF-REFINE 이 모든 출력보다 더 우수했다고 함.
• SELF-REFINE는 약한 모델에서도 작동하는가?
  • Vicuna-13B 모델로 SELF-REFINE를 구현하여 성능을 평가해봤다고 한다.
  • Vicuna-13B는 초기 출력을 생성할 수 있지만, 피드백 생성 및 개선 과정에서 어려움을 겪었다고 함.
  • 약한 모델은 피드백을 일관된 형식으로 생성하지 못하고, 피드백을 제공해도 개선에 실패하는 경향이 있다고 함.
  • 그래서 어느 정도 성능이 보장된 큰 모델에서 유효하다는 걸 발견
• 정성적 분석(Qualitative Analysis):
  • 피드백이 주로 실행 가능하고, 원래 출력의 문제점을 정확히 지적하며 수정 방법을 제안하는 경우에도 성공했지만 피드백이 부분적으로 잘못되었더라도, 문제를 해결하는 경우가 많았다고 함.
  • 그리고 실패의 주된 원인은 잘못된 피드백 때문이었으며, 잘못된 개선보다는 피드백이 오류의 위치를 부정확하게 지적하거나 부적절한 수정을 제안한 경우라고 함.
  • 실패 사례 중 33%는 오류 위치를 정확히 지적하지 못한 피드백 때문이며, 61%는 부적절한 수정 제안 때문이었다고 한다.
  • 좋은 피드백을 받고도 개선을 잘못 수행한 경우는 6%에 불과했다고 함.
• 벤치마크를 넘어선 응용(GOING BEYOND BENCHMARKS):
  • SELF-REFINE를 웹사이트 생성의 실제 사례에 적용하여 그 가능성을 탐구했다고 함.
  • 사용자가 높은 수준의 목표를 제공하면, SELF-REFINE가 이를 기반으로 웹사이트를 반복적으로 개발한다고 함.

 

추가 분석: 

• Oracle Feedback 을 줄 수 있다면 이걸로 성능 향상을 이끌어낼 수 있음. 
  • Oracle Feedback 은 모델의 응답이 올바른지, 틀린지 확실하게 알려줄 수 있는 피드백임.
• 피드백을 할 때는 출력 품질의 다양한 측면을 포착해야 함: 
  • 이런 것 없이 피드백을 한다면 한 측면에서는 성능이 증가하지만, 다른 측면에서는 성능이 감소할 수 있기 때문임. 
  • 그래서 출력을 평가할 수 있는 다양한 측면을 세우고, 이를 측정할 수 있는 최대 점수와 현재 응답은 몇 점 정도인지 매길 수 있는 시스템을 논문에서는 사용함.
  • 이렇게 한다면 수학 추론(Math Reasoning)과 감정 반전(Sentiment Reversal) 같은 다른 작업에서도 단조적으로 출력 품질을 향상 시킬 수 있다고 한다.
• Self-Refine 매커니즘의 오류 분석: 
  • 피드백 과정에서 발생하는 다양한 오류 분석: 
    • Incorrect Feedback (잘못된 피드백): 25%
    • Generic Feedback (일반적인 피드백): 30% 
    • Incorrect Scoring (잘못된 점수 매기기): 10%
  • Refine 과정에서 발생하는 다양한 오류 분석: 
    • Not being robust (견고하지 않음): 10% (이는 성능 향상이 일관되게 일으키지 않았다는 걸 의미함)
    • Ignoring feedback (피드백 무시): 25%
    • Introducing a new problem (새로운 문제 도입): 20% (모델이 응답을 개선하는 과정에서 또 다른 새로운 문제를 생성했음을 말함) 
• 이런 오류 분석에서 중요한 건 피드백이 얼마나 디테일하고 상세한지가 중요하다는 거임. 올바른 피드백을 제공할 수 있도록 개선하는 작업이 중요할 수 있다.