| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |
- 정보처리기사
- Python
- python 기초
- LangGraph
- python기초
- RDBMS
- RNN
- 생성형 인공지능
- 알고리즘
- ASR
- 자연어처리
- 힙정렬
- CLIP
- 데이터엔지니어
- 소프트웨어 개발
- 객체지향
- 랭그래프
- Transformer
- 에이전트
- UMAP
- CNN
- 머신러닝
- 트랜스포머
- 캐글
- 기초
- dementional reduction
- TTS
- SQL
- 데이터 시각화
- 딥러닝
- Today
- Total
수달이네 기술 블로그
Reflexion: Language Agents with Verbal Reinforcement Learning 본문
Reflexion: Language Agents with Verbal Reinforcement Learning
LLM 기반의 에이전트가 실수하며 배우고, 성능을 스스로 개선할 수 있도록 하는 자기성찰(Self-Reflection) 메커니즘을 제안.
- 에이전트가 자신의 결과물을 평가하고, 잘못된 점을 언어적 피드백(Verbal Feedback)하게 한 후, 이를 반영하는 방식.
배경 및 결과 요약
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이 어떻게 학습을 흉내낼까?
- 환경에서의 피드백 수치를 LLM이 이해할 수 있는 텍스트 형태 요약으로 변환
- 미분 가중치를 수치값이 아닌 의미론적 신호(텍스트)를 제공
- 인간의 학습처럼 기억과 문맥의 이해를 통해 AI에이전트가 계획 수정
유용한 피드백 생성을 위한 방법
기여도 산정(Credit Assignment)
문제를 단순한 실패라는 결과 만으로 설정하면 정확히 어디서 틀렸는지 알기 어렵다.
- 모델의 실수 위치를 정확히 파악하고 다음 시도에서 써먹을 수 있는 피드백(Actionable Insights)를 요약해야함.
피드백 생성 방법
해당 논문에선
- 이진 피드백(0,1)
- 사전 정의된 휴리스틱(자주 발생하는 실패 패턴 정의, 감지)
- 자기 평가(스스로 이진 분류를 하고, 유닛 테스트 코드를 작성해 검증)
증폭
위 신호를 그대로 쓰지 않고, 자연어 형태의 경험 요약으로 증폭 시킴.
Reflexion의 장점
- Lightweight(경량화): 가중치를 직접 수정하는 파인튜닝이 필요 없음(프롬프트와 메모리 조절만 하므로)
- Nuanced Feedback(정교한 피드백): 정교하게 특정 행동을 바꾸라는 지침을 줄 수 있음.
- Interpretable Memory(명시적이고 해석 가능한 기억): 기억이 자연어로 저장되어 해석 가능하다.
- Explicit Hint(명확한 행동 힌트): 다음 시도에서 에이전트가 구체적으로 어떤 행동을 취할지에 대한 가이드 제공
단점
- LLM의 성능에 따라 에이전트의 성찰 능력이 크게 변한다.
- 수학적으로 직접 수정하는 것이 아니므로 성공을 공식적으로 보장하지 못한다.
그러나 반대로 말하면 LLM의 능력이 향상될수록 강한 힘이 될 것이다.
평가 방법
- 긴 과정(long Trajectory)속에서 연속적 행동 선택 능력 측정하는 의사 결정력.(Decision-making)
- 지식 집약적 문제에서 단일 생성 결과물을 얼마나 개선하는지에 대한 추론력(Reasoning)
- 컴파일러, 인터프리터 등의 외부 도구를 효과적으로 잘 쓰는지 측정하는 프로그래밍 능력(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프레임워크의 작동 원리

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

Decider모델(여러 세대에 걸쳐 추론), Retry 패턴(평가 단계 없이 횟수만큼 재시도), 정성적 평가(이전 결과물에 대한 평가단계를 두는 방식)에 비해
- 경험의 축적: 한 번만 고치지 않고, 자기 성찰을 통해 지속적인 메모리로 구축
- 오류 식별: 에이전트가 스스로 무엇이 잘못되었는지 고침
에이전트가 정답을 맞히는 것을 넘어 스스로 실수에서 배우는 교훈을 제안한다.
진보한 점 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. 인과관계 추론
- 에이전트가 실패 지점을 역추적해서 추론
- 가상 시나리오 생성해서 명시
- 성공 경로에 대한 성찰을 메모리에 저장
3. 반복적 개선 루프
에이전트가 다음 시도에서 메모리를 읽고 같은 상황에서 같은 실수를 반복하지 않음
- 복잡한 수학적 최적화 없이 언어적 피드백으로 의사결정능력을 상승시킴.
메모리
메모리는 단기기억과 장기기억의 조화로 이루어짐.
1. 두 가지 기억
| 구분 | 논문에서의 정의 (RL Context) | 비유 | 역할 |
| 단기 기억 (Short-term) | 현재 에피소드의 시도(Trajectory History) | 방금 전까지 내가 무슨 말을 했는지 | 구체적인 맥락 제공 |
| 장기 기억 (Long-term) | 성찰 모델($M_{sr}$)이 생성한 '교훈(Lessons)' | 예전에 이런 상황에서 망했던 기억 | 성찰을 통한 압축된 지식 제공 |
전체 프로세스
- 시도: Actor가 환경과 상호작용해 궤적(시도한 기억) 생성
- 평가: 궤적을 보고 점수를 생성
- Amplify(증폭): 점수를 보고 언어적 피드백으로 변환→ 숫자데이터를 언어로 피드백 증폭
- 저장: 성찰 결과를 메모리에 추가
메모리 한계
LLM이 한번에 읽을 수 있는 텍스트 양에 한계 존재
- 모든 성찰 기록을 다 넣지 않고 최근의 핵심 경험만 유지하도록(단기 → 장기)
성능

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

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



- 코딩정확도 11%개선
구성요소 제거 시
유닛테스트 제거
정확도가 베이스라인인 60%에서 오히려 52%로 감소
- 테스트 결과라는 객관적 지표가 없어 억지로 고치다가 오히려 망가짐
- Observation은 반드시 필요
언어적 설명 제거(성찰 제거)
성능향상이 없었음
- 원인 파악에서 개선까지의 논리적 연결고리가 없었기 때문
맹목적 시행착오의 한계
단지 여러번 시행착오 하는 것은 오히려 Rust처럼 복잡하고 엄격한 언어에서 비효율적이었다.
- 에러 메세지를 읽고 글로 생각을 정리한 후 코드를 고치는 방식이 제일 효과적
한계
- RL의 근본적 문제인 지역 최적해(절대적 정답이 아닌 부분 문제에서의 정답에 빠짐)에 빠질 수 있음.
- 메모리를 이전 기록만 담는 슬라이딩 윈도우를 썼지만, 벡터 임베딩 DB, SQL DB등 정교한 구조가 필요
- 코딩 에이전트 구현 시, 결정적이지 않으며, 외부 API 상호작용시 네트워크 상태에 따라 결과가 달라지고, 실행환경에 따라 출력이 달라진다.
영향
자동화
- 외부 환경과 상호작용하는 에이전트의 업무 효율성, 자동화 수준을 획기적으로 높일 수 있다.
- 그러나 잘못된 목적의 피해가 우려되어 안전과 윤리에 대한 연구가 병행되어야 한다.
RL의 문제인 블랙박스 구조를 해결
- 실수를 언어적으로 설명하므로 해당 구조를 해결 가능
- 인간이 이해할 수 없는 도구 사용, 복잡한 행동 전에 에이전트의 의도를 로그로 미리 확인 가능해 가치관과 일치 가능하다.
후속
해당 연구진은 전통적 강화학습의 기법들을 자연어의 영역으로 가져오고 싶어함
- Value Learning, Off-policy exploration등
내 느낀점
LLM의 성능을 Refection의 방식으로 반복해 구체적인 문제와 피드백을 주고받는 방식을 통해 LLM자체의 성능을 비약적으로 높일 수 있다는 사실이 놀라웠다.
사실 실제 에이전트 내에 해당 내용을 실시간으로 넣으면 출력 속도는 현저히 떨어질 수 있기 때문에 실시간 성이 중요한 프로젝트에선 사용하기 힘들어보였다.
그러나 실시간에서 얻은 여러 오류들이나 메세지를 로그로 남겨둔 후 추후 언어적 피드백을 한다면 상당히 좋은 결과로 이어질 수 있을 것 같았다.
예를 들어 내가 하는 프로젝트에서 실시간 MC 에이전트를 만드는데 해당 에이전트 내에서 사람이 AI에게 하는 피드백이나, 채팅의 피드백, AI 자체 피드백을 종합해 에이전트에게 수정하도록 지시하는 방식을 사용할 수도 있을 것 같다.