수달이네 기술 블로그

Reflexion: Language Agents with Verbal Reinforcement Learning 본문

AI공부/논문 리뷰

Reflexion: Language Agents with Verbal Reinforcement Learning

슬픈 수달이 2026. 4. 8. 19:07

Reflexion: Language Agents with Verbal Reinforcement Learning

LLM 기반의 에이전트가 실수하며 배우고, 성능을 스스로 개선할 수 있도록 하는 자기성찰(Self-Reflection) 메커니즘을 제안.

  • 에이전트가 자신의 결과물을 평가하고, 잘못된 점을 언어적 피드백(Verbal Feedback)하게 한 후, 이를 반영하는 방식.

7. 랭그래프 Reflection기초

배경 및 결과 요약

LLM이 게임, 컴파일러, API등 외부 환경과 상호작용하는 에이전트로 활발히 사용되는 중임.

이전 강화학습 방식은 방대한 훈련 데이터가 필요하며, 모델의 가중치(Weights)를 Fine-tuning하는 방식이라 비용이 많이 든다.

  • 강화학습? → 학습의 구조(Loop)가 강화학습과 같은 방식.
    • Trial and Error(시행착오): 환경과 상호작용하며 시도함
    • Feedback(보상): 결과에 따라 신호를 받음.
    • Policy Improvement(정책 개선): 받은 신호를 통해 나은 행동으로 나아감.
    • 이전엔 숫자와 미분(신경망 방식)으로 해결했지만 Reflextion은 해당 방식을 언어, 기억으로 해결함.
    → 사실상 강화학습 아니냐?

위 방식은 비효율적! 따라서 가중치 대신 언어적 피드백으로 에이전트를 스스로 강화시키자!(Reflexion)

  • 에이전트가 작업 결과를 통해 스스로 Reflect(성찰)을 수행 → 문장(Free-from language)으로 피드백
  • 성찰 내용을 Memory Buffer에 저장
  • 다음 시도에 기억을 꺼내 더 나은 의사결정 하도록 유도

결과적으로 코딩 분야에서 91%의 정확도로 GPT-4를 크게 앞지른다.

현재까지의 에이전트

LLM 중심 에이전트

LLM이 텍스트 생성기로 사용하지 않고, 시스템의 두뇌로 활용하는 연구들의 등장

  • ReAct: LLM이 문제 해결 과정에서 추론(Reasoning), 행동(Acting)을 교차적으로 수행하도록 만드는 프롬프트 패턴 → LLM이 인간처럼 문제를 단계적으로 해결, 정보를 스스로 찾아 계획을 수정해 답을 찾음.
  • SayCan: LLM을 가치함수에 기반해 현실세계에 연결함. → 실제 세계에서 추상적이고 장기적인 명령을 따름.

위 연구들의 기술적 제약

  • 해당 에이전트들은 수천억의 파라미터를 가진 거대 모델이 기반이다.
  • 전통 강화학습 방식은 가중치를 일일히 수정해야한다. →학습 불가
  • 따라서 가중치 대신 컨텍스트(프롬프트)안에 예시, 피드백을 넣어 모델이 배우게한다.

Reflextion이 어떻게 학습을 흉내낼까?

  1. 환경에서의 피드백 수치를 LLM이 이해할 수 있는 텍스트 형태 요약으로 변환
  2. 미분 가중치를 수치값이 아닌 의미론적 신호(텍스트)를 제공
  3. 인간의 학습처럼 기억과 문맥의 이해를 통해 AI에이전트가 계획 수정

유용한 피드백 생성을 위한 방법

기여도 산정(Credit Assignment)

문제를 단순한 실패라는 결과 만으로 설정하면 정확히 어디서 틀렸는지 알기 어렵다.

  • 모델의 실수 위치를 정확히 파악하고 다음 시도에서 써먹을 수 있는 피드백(Actionable Insights)를 요약해야함.

피드백 생성 방법

해당 논문에선

  • 이진 피드백(0,1)
  • 사전 정의된 휴리스틱(자주 발생하는 실패 패턴 정의, 감지)
  • 자기 평가(스스로 이진 분류를 하고, 유닛 테스트 코드를 작성해 검증)

증폭

위 신호를 그대로 쓰지 않고, 자연어 형태의 경험 요약으로 증폭 시킴.

Reflexion의 장점

  1. Lightweight(경량화): 가중치를 직접 수정하는 파인튜닝이 필요 없음(프롬프트와 메모리 조절만 하므로)
  2. Nuanced Feedback(정교한 피드백): 정교하게 특정 행동을 바꾸라는 지침을 줄 수 있음.
  3. Interpretable Memory(명시적이고 해석 가능한 기억): 기억이 자연어로 저장되어 해석 가능하다.
  4. Explicit Hint(명확한 행동 힌트): 다음 시도에서 에이전트가 구체적으로 어떤 행동을 취할지에 대한 가이드 제공

단점

  • LLM의 성능에 따라 에이전트의 성찰 능력이 크게 변한다.
  • 수학적으로 직접 수정하는 것이 아니므로 성공을 공식적으로 보장하지 못한다.

그러나 반대로 말하면 LLM의 능력이 향상될수록 강한 힘이 될 것이다.

평가 방법

  1. 긴 과정(long Trajectory)속에서 연속적 행동 선택 능력 측정하는 의사 결정력.(Decision-making)
  2. 지식 집약적 문제에서 단일 생성 결과물을 얼마나 개선하는지에 대한 추론력(Reasoning)
  3. 컴파일러, 인터프리터 등의 외부 도구를 효과적으로 잘 쓰는지 측정하는 프로그래밍 능력(Programming)
    테스트 항목 (데이터셋) 성능 향상 폭 특징
    AlfWorld (의사결정력) +22% 상승 12번의 반복 학습(Iterative steps)만으로 달성
    HotPotQA (추론력) +20% 상승 지식 기반 질문 답변의 정확도 대폭 개선
    HumanEval (프로그래밍 능력) +11% 상승 외부 도구 피드백을 통한 코드 수정 능력 입증

기여점

1. 언어적 강화

가중치에만 의존하지 않는 LLM파라미터 + 에이전트의 기억의 조합을 정책으로 구성하는 방식 제안.

→ 모델을 새로 학습시키지 않은 채 기억을 업데이트 하는 것만으로 학습의 효과를 낼 수 있음.

2. 자기 성찰의 유용성

LLM이 스스로를 돌아보는 자기성찰(Self-reflection)능력의 유용성을 입정

→ 난이도가 높은 태스크를 성공적으로 학습 가능한지 보여줌

3. 새로운 평가 환경 구축

후속 연구를 위한 LeetcodeHardGym이라는 강화학습 환경을 구축해 공개함.

→ 에이전트의 코딩 및 논리 능력을 엄격하게 테스트 가능

4. SOTA(State-of-the-Art) 달성

벤치마크에서 뛰어난 성능을 달성함.

이전 까지의 연구

1. Self-Refine(반복적 자기 개선)

모델이 생성한 결과물을 스스로 평가하고 다듬는 반복적 프레임워크

→ 단일 생성 추론 작업에 국한 즉, 여러 단계를 거치는 복잡한 의사 결정과정에서 적응이 힘듦.

2. 프롬프트 최적화

의미론적인(Semantic)관점에서 프롬프트 작성을 최적화해 성능을 높이려 했음.

→ 단일 단계 작업에 머물러 환경과 지속적 상호작용하는 에이전트 모델로 확장되지 못함.

3. Critic model Fine-tuning

피드백을 주는 Critic모델을 파인튜닝해 추론력을 높음.

→ Reflexion이 비싼 Fine-tuning없이 In-context피드백으로 해결하려함.

4. 효율적인 탐색 전략

Action들에 대해 Stochastic beam search를 수행한다.

Stochastic beam search :자기 평가를 통해 미래를 예측하고 더 나은 의사 결정을 내리는 전략

Reflexion프레임워크의 작동 원리

프로세스(세로축)

  1. Task(목표설정): 최초 명령
  2. Trajectory(최초 시도): 에이전트의 첫 출력
  3. Evaluation(평가)
  4. Reflection(언어적 성찰): 스스로 개선하는 오답노트 책정
  5. Next Trajectory(다음 시도): 다음 출력

Task(가로축)

  • 의사 결정(Decision-making)
    1. Task: 내가 있는 환경(중앙크기의 방) → 냄비를 닦아 선반에 올려둬라
    2. Trajectory: (행동)버너1 에서 냄비를 가져온다. → (관찰) 아무일도 일어나지 않음.
    3. Evaluation: 할루시네이션 오류(환각)
    4. Reflection: 버너1에서 냄비를 찾으려는데 버너1엔 냄비가 없어.
    5. Next Trajectory: (행동)냄비를 버너2에서 가져온다. → (관찰) 냄비를 선반에 올려두었어.
  • 프로그래밍(Programming)
    1. Task: 문자열에서 괄호가 잘 닫혔는지 체크하는 프로그래밍
    2. Trajectory: 괄호의 개수를 체크하는 코드 작성
    3. Evaluation: 스스로 한 테스트 내에서 코드가 실패
    4. Reflection: 괄호의 순서 자체도 중요하구나
    5. Next Trajectory: 괄호 순서를 체크하는 함수를 작성
  • 추론(Reasoning)
    1. Task: John Lanchester와 Alan Dean Foster의 공통점이 뭐야?
    2. Trajectory: (생각) John은 소설가, 저널리스트… Alan은 소설가, 시나리오작가… → (행동) 공통점은 소설가이자 시나리오작가라는 것입니다.
    3. Evaluation: 0점 오답
    4. Reflection: 정확히 공통된 것을 찾아라.
    5. Next Trajectory: 소설가구나.

진보한 점

Decider모델(여러 세대에 걸쳐 추론), Retry 패턴(평가 단계 없이 횟수만큼 재시도), 정성적 평가(이전 결과물에 대한 평가단계를 두는 방식)에 비해

  1. 경험의 축적: 한 번만 고치지 않고, 자기 성찰을 통해 지속적인 메모리로 구축
  2. 오류 식별: 에이전트가 스스로 무엇이 잘못되었는지 고침

에이전트가 정답을 맞히는 것을 넘어 스스로 실수에서 배우는 교훈을 제안한다.

진보한 점 2 (프로그래밍)

모델

  • AlphaCode: 많은 코드를 생성한 뒤 숨겨진 테스트 케이스로 평가
  • CodeT: 모델이 스스로 유닛 테스트(Unit test)를 생성하고, 이를 통해 작성한 코드의 점수를 매김
  • Self-debugging: 코드 실행 환경에서 오는 피드백을 받아 기존 코드를 수정한다.
  • CodeRL: 강화학습의 Actor-Critic구조를 활용해 프로그램을 디버깅한다.

한계

  • 정답 의존성: AlphaCode, CodeRL은 모델이 정답 테스트 케이스를 미리 알고 있어야 한다.
  • 성찰의 부재: 에러가 났다는 사실과 코드를 고치는 행동을 이어주는 연결고리가 없다.

해결

  • 에러를 수정 신호 뿐아니라, 언어적인 성찰을 남겨 자기 학습함.

Reflexion의 구조

모델 명칭 기호 역할 (Role)
Actor $M_a$ 실제 텍스트를 생성하고 행동(Action)을 수행함.
Evaluator $M_e$ Actor가 내놓은 결과물($M_a$의 출력)에 점수를 매김.
Self-Reflection $M_{sr}$ 평가 결과를 바탕으로 무엇이 틀렸는지 '언어적 강화 신호'를 생성함.

  • 생성 → 점수 → 언어적 신호를 원하는 답이나 최대 횟수가 나올때까지 반복.

Actor($M_a$)

1. Policy역할 LLM

RL의 정책 역할을 LLM이 수행함.

  • 관찰값을 입력받아 그에 맞는 텍스트, 행동을 생성함
  • Chain of though나 ReAct등의 고도화된 추론 프롬프트 기법 적용

2. 메모리 컴포넌트(기억 저장소)

Actor가 메모리 공간을 가짐

  • 에이전트에게 문맥을 제공 → 판단 근거

3. 인 컨텍스트 정책 반복

가중치를 바꾸지 않고, 프롬프트 내 학습으로 정책을 개선한다.

Evaluator($M_e$)

1. 구조

  • 입력: Actor가 수행한 전체 과정
  • 출력: 행동이 잘 되었는지 채점(Reward Score) → 정답이 숫자로 떨어지지 않는 언어적 공간에서 객관적인 보상을 주는게 중요.

2. 태스크에 따라 다른 평가

태스크 유형 평가 방식 세부 내용
추론 (Reasoning) EM (Exact Match) 생성된 최종 정답이 예상 솔루션과 정확히 일치하는지 확인.
의사결정 (Decision-making) Heuristic Functions 미리 정의된 규칙(예: 특정 행동 금지, 시간 제한 등)에 따라 점수 부여.
코딩 & 의사결정 LLM as Evaluator 별도의 LLM이 평가자가 되어 결과물의 품질을 판단하고 보상을 생성.

3. 다각도 접근

무조건 LLM에게 평가를 맡기지 않고, 정답이 명확한 추론의 경우엔 EM을 사용해 효율성을 고려함.

Self-reflection($M_{sr}$)

1. 희소한 보상의 언어화

현재의 과정, 보상신호, 메모리를 입력받아 세밀하고 구체적인 언어 피드백을 준다.

2. 인과관계 추론

  1. 에이전트가 실패 지점을 역추적해서 추론
  2. 가상 시나리오 생성해서 명시
  3. 성공 경로에 대한 성찰을 메모리에 저장

3. 반복적 개선 루프

에이전트가 다음 시도에서 메모리를 읽고 같은 상황에서 같은 실수를 반복하지 않음

  • 복잡한 수학적 최적화 없이 언어적 피드백으로 의사결정능력을 상승시킴.

메모리

메모리는 단기기억과 장기기억의 조화로 이루어짐.

1. 두 가지 기억

구분 논문에서의 정의 (RL Context) 비유 역할
단기 기억 (Short-term) 현재 에피소드의 시도(Trajectory History) 방금 전까지 내가 무슨 말을 했는지 구체적인 맥락 제공
장기 기억 (Long-term) 성찰 모델($M_{sr}$)이 생성한 '교훈(Lessons)' 예전에 이런 상황에서 망했던 기억 성찰을 통한 압축된 지식 제공

전체 프로세스

  1. 시도: Actor가 환경과 상호작용해 궤적(시도한 기억) 생성
  2. 평가: 궤적을 보고 점수를 생성
  3. Amplify(증폭): 점수를 보고 언어적 피드백으로 변환→ 숫자데이터를 언어로 피드백 증폭
  4. 저장: 성찰 결과를 메모리에 추가

메모리 한계

LLM이 한번에 읽을 수 있는 텍스트 양에 한계 존재

  • 모든 성찰 기록을 다 넣지 않고 최근의 핵심 경험만 유지하도록(단기 → 장기)

성능

  • 의사결정력 성공률 Reflexion적용 시 22% 상승

  • 추론 정확도 20%정도 크게 상승

  • 코딩정확도 11%개선

구성요소 제거 시

유닛테스트 제거

정확도가 베이스라인인 60%에서 오히려 52%로 감소

  • 테스트 결과라는 객관적 지표가 없어 억지로 고치다가 오히려 망가짐
  • Observation은 반드시 필요

언어적 설명 제거(성찰 제거)

성능향상이 없었음

  • 원인 파악에서 개선까지의 논리적 연결고리가 없었기 때문

맹목적 시행착오의 한계

단지 여러번 시행착오 하는 것은 오히려 Rust처럼 복잡하고 엄격한 언어에서 비효율적이었다.

  • 에러 메세지를 읽고 글로 생각을 정리한 후 코드를 고치는 방식이 제일 효과적

한계

  1. RL의 근본적 문제인 지역 최적해(절대적 정답이 아닌 부분 문제에서의 정답에 빠짐)에 빠질 수 있음.
  2. 메모리를 이전 기록만 담는 슬라이딩 윈도우를 썼지만, 벡터 임베딩 DB, SQL DB등 정교한 구조가 필요
  3. 코딩 에이전트 구현 시, 결정적이지 않으며, 외부 API 상호작용시 네트워크 상태에 따라 결과가 달라지고, 실행환경에 따라 출력이 달라진다.

영향

자동화

  • 외부 환경과 상호작용하는 에이전트의 업무 효율성, 자동화 수준을 획기적으로 높일 수 있다.
  • 그러나 잘못된 목적의 피해가 우려되어 안전과 윤리에 대한 연구가 병행되어야 한다.

RL의 문제인 블랙박스 구조를 해결

  • 실수를 언어적으로 설명하므로 해당 구조를 해결 가능
  • 인간이 이해할 수 없는 도구 사용, 복잡한 행동 전에 에이전트의 의도를 로그로 미리 확인 가능해 가치관과 일치 가능하다.

후속

해당 연구진은 전통적 강화학습의 기법들을 자연어의 영역으로 가져오고 싶어함

  • Value Learning, Off-policy exploration등

내 느낀점

LLM의 성능을 Refection의 방식으로 반복해 구체적인 문제와 피드백을 주고받는 방식을 통해 LLM자체의 성능을 비약적으로 높일 수 있다는 사실이 놀라웠다.

사실 실제 에이전트 내에 해당 내용을 실시간으로 넣으면 출력 속도는 현저히 떨어질 수 있기 때문에 실시간 성이 중요한 프로젝트에선 사용하기 힘들어보였다.

그러나 실시간에서 얻은 여러 오류들이나 메세지를 로그로 남겨둔 후 추후 언어적 피드백을 한다면 상당히 좋은 결과로 이어질 수 있을 것 같았다.

예를 들어 내가 하는 프로젝트에서 실시간 MC 에이전트를 만드는데 해당 에이전트 내에서 사람이 AI에게 하는 피드백이나, 채팅의 피드백, AI 자체 피드백을 종합해 에이전트에게 수정하도록 지시하는 방식을 사용할 수도 있을 것 같다.