핵심 : step-by-step 추론 과정에서 각 step을 새롭게 생성하고 원래 생성된 결과와 비교함으로써 에러를 검출하고자 한다.
0. Abstract
CoT와 같은 기법으로 LLM이 단계별 추론이 가능해졌다. 하지만 단순하고 선형적인 추론이 아닌 더 복잡한 문제에서는 성능이 좋은 LLM들도 실수를 한다. 따라서 단계별 추론에서 실수했는지 확인하는 과정을 추가한 SelfCheck라는 새로운 방식을 소개한다. SelfCheck의 checking 과정에서 생성된 여러 개의 답변들 중에서 weighted voting을 통해 성능을 향상시킨다.
1. Introduction
CoT처럼 단계별로 추론을 했을 때, 하나의 단계에서 실수를 할 확률은 낮지만 최소 한 개의 실수를 할 확률은 높아서 최종 답변을 잘 못하는 것이다. 이 문제를 해결하기 위해서 기존의 방법들은 추가적인 training data나 domain-specific한 예시를 사용하지만, SelfCheck는 더 general하면서 zero-shot이며 외부 resource를 사용하지 않는 방법이다.
각 step마다 error를 체크할 때, 단순히 한 step만 놓고 error가 있는지 확인하라는 naive 방식을 취하지 않는다. 해당 step을 regenerate한 뒤에 원래 generation과 비교하는 과정을 취한다. 이러한 방식은 각 step의 정확도 예측을 높이는 동시에 최종 답의 정확도를 높일 수 있다. 여러 개의 답변에서 confidence score를 weight 삼아 정확도를 높일 수도 있다.
2. Related Work
Few-shot verifivation
기존의 방식들은 도출된 답변만을 가지고 backward prediction을 하거나 특정 포맷에서만 단계별로 체크하기 때문에 general한 단계별 검증은 어렵다.
Verification with external resources
외부 resource의 가용성에 의존이 높고, 특정 유형의 에러만 검증할 수 있다는 한계가 있다.
Training/finetuning a verifier
출이 과정 전체를 검증하거나 각 step의 정확도를 위해 train/finetuning할 수 있고, 아예 각 step마다 정확한 라벨링을 한 데이터셋을 만든 시도들이 있다. 하지만 추가적인 데이터가 필요하고 쉽게 사용할 수 없다는 한계가 있다.
- confidence score = 각 step마다 틀린 것인지 확인한 값을 모두 수합한 것.
3. SelfCheck : Using LLMs to Check Their Own Reasoning
CoT 프롬프팅으로 생성된 적절한 step마다 checking을 진행한다. SelfCheck의 경우 LLM에게 직접적으로 체크하라고 시키는게 아닌, 새로운 방식을 채택한다.
3.1 Step Checking
현재 step에서 정확한 답을 내기 위해서는 이전 step들이 정확한지에 많이 의존한다. 하지만 모든 context와 함께 현재 step을 제공했을 때, LLM이 실제로 check를 잘하지 못한다. 너무 많은 특성들을 고려해야 될뿐만이 아니라, training corpus에 ‘checking’과 관련된 데이터가 적기 때문이다. 그리고 동일한 LLM으로 진행하기 때문에, 동일한 실수를 만들 확률도 높다.
따라서 SelfCheck는 4가지 단계로 분리한다.
Target Extraction → Information Collection → Step Regeneration → Result Comparison
현재 step에 해당하는 이미 생성된 결과 값을 보고 무엇을 하려고 하는지와 어떤 정보가 사용되었는지 확인한다. 이 필수적인 정보들만을 바탕으로 새롭게 해당 step을 재생성한 다음에 원래 생성된 내용과 비교한다.
3.2 Results Integration
원래 생성된 결과와 새롭게 재생성된 결과를 각 step마다 비교하면, 타당함/관련없음/타당하지 않음으로 1/0/-1 숫자로 수치화할 수 있다. 각 check마다 가지는 이 값들을 통합할 때, 적절히 고려하되 check 하나의 영향을 너무 크게하지 않기 위해서 soft approach를 사용한다. 그리고 타당한 check의 절대적인 수를 기준으로 삼지 않는 이유는 풀이과정이 더 길수록 선호되지 않기 때문이다.
해당 식으로 계산된 confidence score는 여러 개의 output이 있을 때 그중에서 가장 좋은 것을 고르거나, 올바르지 않은 답변을 필터링할 수 있게 한다.
4. Experiments
3개의 math-reasoning 관련 데이터셋들을 (GSM8K, MathQA, MATH) 사용했지만, 프론프트 변경을 통해 일반적인 추론이나 QA도 가능하다.
Deductive-Verification이나 Self-Verification 등에 대해서 비교를 진행한다. GPT-3.5와 GPT-4로 실험을 진행하고, GPT-3.5와 GPT-4를 섞어서도 실험한다. 다른 LLM을 사용했을 때 성능이 더 높은데, 동일한 에러를 만들지 않을 확률이 높아서로 추측한다.
confidence score가 낮은 solution들을 제외했을 때 성능이 더 높게 나온다. confidence score가 낮은 correct solution도 있지만, 전반적으로 confidence score를 믿을 수 있다는 것이다.
5. Analysis
5.1 More Solutions per Question?
solution의 개수는 9를 넘어가면 정확도는 saturated된다. majority voting보다 SelfCheck의 정확도가 항상 높다.
5.2 Ablation Studies
Global vs step-by-step checking : 전체 풀이과정을 던져주면 보통의 경우에는 올바르다고 착각을 한다.
Single state vs multiple stage step cheking : 각 스텝을 4개의 과정으로 분리했을 때 더 성능이 좋게 나온다. 여러 개의 쉬운 sub-task들로 분리해야 LLM이 더 쉽게 check할 수 있기 때문이다.
Error check vs regenerate and compare : LLM은 검사하는 것보다는 생성에 더 강하기 때문에, 답변을 재생성하고 비교하는 것이 더 효과적이다.
6. Conclusion
general-purpose, 제로샷, step-by-step checking을 하는 SelfCheck이라는 방식을 소개한다. 생성된 결과에서 에러를 알아내기 위해 재생성하고 비교하는 방식을 채택한다.
