안녕하세요.
이번 글에서는 Reflexion: Language Agents with Verbal Reinforcement Learning (NeurlPS 2023) (Noah Shinn, Federico Cassano) 에 대해서 정리해보려고 합니다.
본 논문에서는 전통적인 강화학습 방법인 기존의 스칼라 값을 피드백으로 주어 모델의 성능을 올리는 방식이 아닌,
언어적인 피드백을 통해 모델의 성능을 올리는 방법을 제안합니다.
쉽게 설명하자면, 수학 문제를 푸는 상황을 가정했을 때, 문제를 풀고 -> 답이 틀렸다면 -> 오답 노트(Self-Reflexion)를 작성하고 -> 오답 노트를 토대로 다시 문제를 푸는 것을 반복하는 과정 이라고 보면 될 것 같습니다.
이해한 흐름대로 최대한 쉽고 자세하게 정리해보겠습니다.
1. 연구 배경
LLM은 목표 지향적인 에이전트로서
게임, 컴파일러, API 같은 외부 환경과 상호작용하는 방식으로 점점 더 많이 사용되고 있습니다.
그런데 여기서 문제가 생깁니다.
기존 방법론 한계
(1) Fine-tuning 기반 학습의 부담
- 모델 가중치를 업데이트하는 방식은
많은 학습 데이터가 필요하고 학습 비용이 비쌉니다.
(2) Credit assignment 문제
- 강화학습처럼 reward를 받아도,
“수많은 행동 중에 대체 무엇 때문에 보상을 받은 거지?”가 애매해집니다.
(결정적인 원인이 무엇이었는지 추적이 어려움)
그래서 Reflexion은 이렇게 생각합니다.
“가중치를 업데이트하지 말고,
실패 이유를 언어로 피드백해서 다음 시도에 반영하면 되지 않을까?”
즉, 언어적 피드백(verbal feedback) 으로 에이전트를 강화하는 접근입니다.
2. Reflexion 방법론 (Framework)
Actor가 행동(Action) → 환경 실행 → Observation/Reward → Trajectory 기록 → Evaluator 평가 → Self-reflection(반성문) 작성 → Experience(장기기억) 저장 → 다음 시도에서 참고
여기서 핵심은, “반성문(Self-Reflexion)”이 메모리로 남고, 그게 다음 시도에 영향을 준다는 점입니다.
이 과정을 계속 반복하다가
정답이라고 판단되면 Finish로 끝냅니다.
3. 구성요소: Actor / Evaluator / Self-reflection
(1) Actor
- 상태(observation)를 보고 행동과 텍스트를 생성합니다.
- 논문에서는 Actor로 ReAct / CoT 같은 구조도 사용합니다.
- 중요한 점: Actor는 memory(장기기억) 를 함께 프롬프트로 받아서 다음 행동을 결정합니다.
(2) Evaluator
- Actor가 만든 trajectory(전체 수행 기록) 를 보고 평가합니다.
- 여기서 평가 결과는 보통
- 성공/실패 같은 이진 신호
- 또는 스칼라 reward 형태로 생각할 수 있는데,
- 실험 세팅에 따라 “평가 방식”이 달라집니다.
(3) Self-reflection
- Evaluator 결과 + trajectory를 보고
- 실패 원인을 요약하고 “다음엔 어떻게 해야 하는지”를 자연어 반성문으로 생성합니다.
- 이 반성문이 experience(장기기억) 로 저장됩니다.
4. Experiment 1 : ALFWorld (Sequential Decision Making)
(1) 데이터/환경 세팅
- 텍스트 기반 상호작용 환경(TextWorld 기반)
- 총 134개 서로 다른 환경
- 6가지 유형의 multi-step 작업
구체 예시는:
- 숨겨진 물건 찾기: 서랍에서 주걱 찾기
- 물건 이동: 칼을 도마로 옮기기
- 물건 조작: 토마토를 냉장고에 넣어 차갑게 만들기
(2) Baseline: ReAct
- 긴 trajectory 의사결정에서 성공을 보여서 baseline으로 선택
- Thought → Action → Observation 사이클 반복
(3) LLM 모델 / few-shot
- 사용 모델: GPT-3
- 도메인 특화 few-shot trajectory 2개 제공
(4) Evaluator: “self-reflection이 필요한지” 판단하는 방식
ALFWorld에서는 환경이 “성공/실패”를 바로 친절하게 주지 않아서,
중간에 지금 막혔는지를 감지하는 게 중요합니다.
그래서 Evaluator가 “반성할 타이밍”을 아래 두 방식으로 잡습니다.
방법 1) 휴리스틱 기반(Heuristic-based)
(a) Hallucination 검출
- 조건: 동일한 action + 동일한 response를 3회 이상 반복
- 의미: 루프에 빠져서 진전이 없는 상태
예)
- “문을 연다” → “이미 열려있다”
- “문을 연다” → “이미 열려있다”
- … 반복
(b) Inefficient planning 검출
- 조건: 현재 환경에서 action 횟수가 30번 초과
- 의미: 너무 많은 시도로 비효율적 탐색을 하는 경우
(예: 물건 찾으려고 서랍을 30개 이상 무작정 열어보는 상황)
방법 2) LLM 기반 자연어 분류(GPT-based)
- LLM에게 전체 trajectory를 보여주고
- “이 궤적이 성공적인가? 반성이 필요한가?”를 질문해서
- 필요/불필요 이진 분류를 하게 함
(5) 결과
- ReAct + Reflexion(Heuristic) : 134개 중 130개 성공(약 97%), hallucination/inefficient planning이 거의 0
- ReAct only : 6~7번 trial 이후 성능 정체, 실패 케이스(루프/비효율 탐색)가 상대적으로 많음
5. Experiment 2 : HotPotQA (Reasoning)
HotPotQA는 Wikipedia 기반 multi-hop QA:
- 총 11만 3천 개 Q-A
- 여러 문서를 엮어서 reasoning해야 하는 태스크
여기서는 실험 목적이 2개로 분리됩니다.
(1) Reasoning 능력만 평가: Reflexion + CoT
CoT는 “행동/검색”이 없기 때문에
순수 reasoning 개선을 보기 위해 세팅을 2개로 둡니다.
- Q → A : 질문만 주고 답 생성
- Q, Cgt → A : 질문 + 정답 근거 문서(Cgt) 를 주고 답 생성
(여기서 Cgt를 주는 이유는 검색 없이도 긴 문맥 위에서 추론을 하게 만들어서 “reasoning만” 분리해서 평가하려는 목적)
(2) Retrieval + Reasoning 전체 평가: Reflexion + ReAct
- Wikipedia API로 문서를 검색(action)
- 그걸 바탕으로 step-by-step 추론(reasoning)
(3) Evaluator: Exact Match 기반 Binary Reward
- HotPotQA에서는 정답 평가를 Exact Match(EM) 로 하고,
- 성공/실패를 binary signal 로 제공합니다.
(4) 결과
- baseline(Reflexion X)은 실패한 문제를 다시 시도해도 개선이 거의 없는데, Reflexion은 trial이 쌓이며 성능이 꾸준히 상승
- ground truth context를 준 CoT(GT)도 39%는 틀리는데, Reflexion이 이를 추가로 14% 개선
- ablation study에서도 단순 episodic memory보다 self-reflection이 8% 더 큰 향상
6. Experiment 3 : Programming (MBPP / HumanEval / LeetcodeHardGym)
다음은 코드 작성에서의 성능 검증입니다.
(1) 데이터셋
- MBPP: 비교적 기본적인 파이썬 문제 → 함수 body 생성
- HumanEval: 더 정교한 구현 + 엣지케이스 처리 능력 평가
- LeetcodeHardGym: 논문에서 새로 제안한 데이터 셋, GPT-4 pretraining cutoff 이후 공개된 Leetcode hard 40문제로 generalization 평가
(2) Multi-language 평가(Rust)
Reflexion이 특정 언어에만 국한되지 않는지 보기 위해
- Python + Rust 코드 생성 실험 진행
- MultiPL-E로 HumanEval/MBPP 일부를 Rust로 변환
(Python 문제를 18개 언어로 번역 가능한 compiler 모음)
(3) Evaluator: Self-generated Unit Tests
프로그래밍은 실행 기반 평가가 가능하니까,
Reflexion은 스스로 unit test를 만들어서 자기 코드를 검증합니다.
Unit test 생성 과정은 PPT 기준으로 이렇게 정리됩니다.
- CoT prompting으로 다양한 테스트 생성
- AST parsing으로 문법적으로 valid한 테스트만 필터링
- 최대 6개 테스트를 샘플링해 test suite 구성
- Reflexion loop는 동일하지만 memory는 1개만 유지(LLM context 제한 문제)
(4) 결과
- Reflexion은 거의 모든 환경에서 SOTA 달성
(단, MBPP Python에서는 GPT-4보다 낮음)
(5) 왜 MBPP Python에서 성능이 떨어졌나? (TP/FN/FP/TN)
논문은 unit test 품질 문제를 지적합니다.
- TP: unit test 통과 + 실제 정답도 맞음
- FN: unit test 실패 + 실제 코드는 정답
- FP: unit test 통과 + 실제 코드는 오답
- TN: unit test 실패 + 실제 코드도 오답
특히 MBPP Python은 FP가 많이 나와서 문제가 됩니다.
FP(False Positive) 상황
테스트가 허술(flaky)하면,
틀린 코드인데도 테스트를 통과해서 정답이라고 착각할 수 있음.
FN(False Negative) 상황
테스트를 잘못 작성하면,
정답 코드인데도 일부 테스트가 실패해서 오답이라고 착각할 수 있음.
결국 이렇게 정리할 수 있을 것 같습니다.
self-reflection 기반 코드 에이전트는 “좋은 unit test를 만들 수 있는 능력”이 중요하다.
(6) 추가 실험(Ablation): Test vs Reflection 기여도 분리
- Reflection만 하면 성능 하락(0.52)
→ 실패 원인을 판단할 근거가 부족 - Test만 넣으면 성능 변화 거의 없음(0.60)
→ 오류는 잡지만 “어떻게 고칠지 방향”이 없음 - Test + Reflection 결합이 최고(0.68)
→ 실패 감지 + 언어적 반성으로 개선 방향 학습
7. 한계점 & 결론
한계점(Limitations)
- Local minima 문제: policy optimization 자체가 강력하지만 최고 해를 보장해주지는 않는다.
- Memory 구조의 단순함: 현재는 memory제한을 두고 있습니다.(sliding window로 최근 경험만 유지)
→ 향후 벡터 DB, SQL DB 등으로 확장 가능성 - Test-driven 한계(코드): 현실 함수는 입력-출력 매핑이 어려운 경우가 많음(비결정적 함수, API 상호작용, 하드웨어 의존, 병렬/동시성 등)
결론(Conclusion)
Reflexion은 verbal reinforcement를 통해
에이전트가 과거 실패를 반성하고 학습하는 방법입니다.
self-reflection을 memory로 저장함으로써
기존 decision-making agent보다 훨씬 높은 성능을 보였고,
앞으로는 전통 RL의 기법들(자연어 기반 value learning, off-policy exploration)까지 확장 가능하다고 봤습니다.
혹시 직접 코드를 돌려보고 싶으신 분들도 계실 것 같아 github 링크 첨부합니다!
https://github.com/noahshinn/reflexion
GitHub - noahshinn/reflexion: [NeurIPS 2023] Reflexion: Language Agents with Verbal Reinforcement Learning
[NeurIPS 2023] Reflexion: Language Agents with Verbal Reinforcement Learning - noahshinn/reflexion
github.com