올해 인공지능 분야에서는 LLM(Large Language Model)이 많은 관심의 대상이 되었습니다. LLM은 다양한 자연어 처리(NLP) 작업, 특히 추론 분야에서 상당한 진전을 이루었습니다. 하지만 복잡한 추론 작업에서는 LLM의 성능이 여전히 향상되어야 합니다.
LLM이 자체 추론에 오류가 있다고 판단할 수 있나요? 최근 케임브리지 대학교와 구글 리서치가 공동으로 진행한 연구에 따르면 LLM은 자체적으로 추론 오류를 감지할 수 없지만, 연구에서 제안한 역추적 방법을 사용하여 오류를 수정할 수 있다는 사실이 밝혀졌습니다
이 논문으로 인해 일부 논란, 누군가 이에 대해 이의를 제기했습니다. 예를 들어, Hacker News에서 누군가는 논문 제목이 과장되었고 약간의 클릭베이트라고 논평했습니다. 다른 사람들은 논리적 오류를 수정하기 위해 논문에서 제안한 방법이 논리적 방법을 사용하는 것이 아니라 패턴 일치를 기반으로 한다고 비판했습니다. 이 방법은 실패하기 쉽습니다
Huang et al. 아직" 지적: 자체 수정은 모델 출력의 스타일과 품질을 향상시키는 데 효과적일 수 있지만 LLM이 외부 피드백 없이 자체 추론과 논리적 오류를 식별하고 수정하는 능력이 있다는 증거는 거의 없습니다. 예를 들어 Reflexion과 RCI는 모두 Ground Truth의 수정 결과를 자체 수정 주기를 중지하는 신호로 사용합니다.
케임브리지 대학교 연구팀과 Google Research 팀은 새로운 아이디어를 제안했습니다. 즉, 자체 수정 프로세스를 오류 발견과 출력 수정의 두 단계로 나누는 것입니다.
이 기사의 주요 기여는 다음과 같습니다.
BIG-Bench에는 CoT 스타일을 사용하는 2186개의 궤도 정보 세트가 포함되어 있습니다. 각 궤적은 PaLM 2-L-Unicorn에 의해 생성되었으며 첫 번째 논리적 오류 위치에 주석이 추가되었습니다. 표 1은 4단계에서 오류가 발생한 궤적의 예를 보여줍니다
이 궤적은 BIG-Bench 데이터세트의 5개 작업(단어 정렬, 섞인 객체 추적, 논리적 추론, 다단계 산술 및 연산)에서 나온 것입니다. 딕 언어.
각 작업의 질문에 답하기 위해 CoT 프롬프트 설계 방식을 사용하여 PaLM 2를 호출했습니다. CoT 궤적을 명확한 단계로 나누기 위해 "React: Synergizing Reasoning and Acting in Language Model"에서 제안한 방법을 채택하여 각 단계를 별도로 생성하고 줄바꿈을 정지 표시로 사용합니다
모든 궤적을 생성할 때 이 데이터세트, 온도 = 0일 때 답변의 정확성은 정확한 일치에 의해 결정됩니다.
새로운 버그 발견 데이터세트인 GPT-4-Turbo, GPT-4 및 The Accuracy of GPT- 3.5 터보는 표 4에 나와 있습니다.
각 질문에는 정답 또는 오답의 두 가지 답변이 있습니다. 오류인 경우 N 값은 첫 번째 오류가 발생한 단계를 나타냅니다.
모든 모델은 동일한 3개의 프롬프트로 입력되었습니다. 그들은 세 가지 다른 프롬프트 디자인 방법을 사용했습니다.
be rewrite is: 관련 토론
결과는 세 모델 모두 이 새로운 오류 발견 데이터 세트에 대처하는 데 어려움이 있음을 보여줍니다. GPT는 가장 좋은 성능을 발휘하지만 직접적인 단계 수준 프롬프트 디자인에서는 52.87의 전체 정확도만 달성할 수 있습니다.
이는 현재 최첨단 LLM이 가장 단순하고 명확한 경우에도 오류를 찾는 데 어려움을 겪고 있음을 보여줍니다. 대조적으로, 인간은 특별한 전문 지식 없이도 높은 일관성을 가지고 오류를 찾을 수 있습니다.
연구원들은 LLM이 오류를 감지하지 못하는 것이 LLM이 추론 오류를 자체 수정할 수 없는 주된 이유라고 추측합니다.
신속한 설계 방법 비교
연구원들은 직접 궤적 수준 접근 방식부터 CoT 접근 방식의 단계 수준 접근 방식까지 오류 없이 궤적의 정확도가 크게 떨어지는 것을 발견했습니다. 그림 1은 이러한 절충안을 보여줍니다
연구원들은 그 이유가 모델 출력의 수 때문일 수 있다고 믿습니다. 세 가지 방법 모두 점점 더 복잡한 출력을 생성해야 합니다. 궤적을 직접 생성하는 프롬프트 설계 방법에는 단일 토큰이 필요하고, 단계를 직접 생성하는 프롬프트 설계 방법에는 단계당 하나의 토큰이 필요하며, CoT 단계 수준 프롬프트 설계 방법에는 각 단계에 여러 문장이 필요합니다. 빌드 호출당 오류율이 발생할 확률이 있는 경우 추적당 호출이 많을수록 모델이 하나 이상의 오류를 식별할 가능성이 커집니다.
오류 위치를 정확성을 위한 프록시로 사용하는 샘플이 거의 없음 프롬프트 디자인
연구원들은 이러한 신속한 설계 방법이 잘못된 위치가 아닌 궤도의 정확성을 확실하게 결정할 수 있는지 조사했습니다.
모델이 궤적에 오류가 있는지를 올바르게 예측할 수 있는지 여부를 기준으로 평균 F1 점수를 계산했습니다. 오류가 있는 경우 모델이 예측한 궤적이 "오답"으로 간주됩니다. 그렇지 않으면 모델이 예측한 궤적을 "정답"으로 간주합니다
corrept_ans 및 false_ans를 양성 레이블로 사용하고 각 레이블의 발생 횟수에 따라 가중치를 부여하여 연구원은 평균 F1 점수를 계산했으며 그 결과는 다음과 같습니다. 표 5에 나와 있습니다.
이 가중치 F1 점수는 프롬프트를 통해 오류를 찾는 것이 최종 답변의 정확성을 결정하는 데 좋지 않은 전략임을 보여줍니다.
Huang 등은 LLM이 외부 피드백 없이는 논리 오류를 자체 수정할 수 없다고 지적했습니다. 그러나 많은 실제 응용 프로그램에서는 사용할 수 있는 외부 피드백이 없는 경우가 많습니다. 이 연구에서 연구원들은 소량의 외부 피드백에 대해 훈련된 경량 분류기를 채택했습니다. 기존 강화 학습의 보상 모델과 유사하게 이 분류자는 출력을 개선하기 위해 생성기 모델에 다시 피드백하기 전에 CoT 궤적의 논리적 오류를 감지할 수 있습니다. 개선을 극대화하려면 여러 번 반복할 수 있습니다.
연구원들은 논리적 오류의 위치를 역추적하여 모델의 출력을 향상시키는 간단한 방법을 제안했습니다.
이전의 자체 수정 방법과 비교할 때 이 역추적 방법은 많은 장점이 있습니다.
연구원들은 BIG-Bench Mistake 데이터 세트를 사용하여 역추적 방법이 LLM이 논리 오류를 수정하는 데 도움이 될 수 있는지 알아보는 실험을 수행했습니다. 실험 결과는 표 6을 참조하세요
Δaccuracy✓는 원래 답이 올바른_ans일 때 궤적 집합의 정확도_ans의 차이를 나타냅니다.
오답 궤적 결과의 경우 정확도를 다시 계산해야 합니다.
이 점수 결과는 잘못된_ans 궤적을 수정하는 이득이 원래 정답을 변경하여 발생하는 손실보다 크다는 것을 보여줍니다. 또한 무작위 벤치마크도 개선을 얻었지만 실제 오류 위치를 사용할 때보다 그 이득이 훨씬 적습니다. 무작위 벤치마크에서는 실제 오류의 위치를 찾을 가능성이 더 높기 때문에 더 적은 단계를 포함하는 작업에서 성능 향상이 발생할 가능성이 더 높습니다.
좋은 레이블을 사용할 수 없을 때 어떤 정확도 수준의 보상 모델이 필요한지 알아보기 위해 시뮬레이션된 보상 모델을 통해 역추적을 사용하여 실험했습니다. 이 시뮬레이션된 보상 모델의 설계 목표는 다양한 정확도 수준의 레이블을 생성하는 것입니다. 그들은 Accuracy_RM을 사용하여 지정된 오류 위치에서 시뮬레이션 보상 모델의 정확도를 나타냅니다.
주어진 보상 모델의 Accuracy_RM이 X%일 때 BIG-Bench Mistake X%의 잘못된 위치를 사용합니다. 나머지 (100 − X)%에 대해서는 오류 위치가 무작위로 샘플링됩니다. 일반적인 분류기의 동작을 시뮬레이션하기 위해 오류 위치는 데이터 세트의 분포와 일치하는 방식으로 샘플링됩니다. 연구진은 또한 샘플의 잘못된 위치가 올바른 위치와 일치하지 않도록 하는 방법도 찾았습니다. 결과는 그림 2에 나와 있습니다.
손실률이 65%에 도달하면 Δ 정확도가 안정화되기 시작하는 것을 볼 수 있습니다. 실제로 대부분의 작업에서 정확도_RM이 약 60-70%일 때 Δaccuracy ✓는 이미 Δaccuracy ✗를 초과합니다. 이는 정확도가 높을수록 더 나은 결과를 얻을 수 있지만 표준 오류 위치 레이블이 없어도 역추적은 여전히 작동함을 보여줍니다
위 내용은 Google: LLM은 추론 오류를 찾을 수 없지만 수정할 수는 있습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!