🤖 AI

Structured Feedback Improves Repair in an LLM Agent Loop

이 논문은 실패 위치, 관찰된 값, 그리고 허용 가능한 대안을 포함하는 구조화된 피드백을 LLM에 제공하는 것이 원시 진단이나 불완전한 피드백을 제공하는 것보다 반복적인 작업에서 수리 성공률을 유의미하게 향상시킨다는 것을 입증하는 코드 제어 에이전트 루프인 VeriHarness를 소개한다.

원저자: Jaideep Ray, Ankit Goyal

게시일 2026-07-17

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Jaideep Ray, Ankit Goyal

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

당신이 아주 똑똑하지만 약간은 글자 그대로만 받아들이는 로봇에게 비디오 게임 하는 법을 가르치고 있다고 상상해 보세요. 당신은 로봇에게 "보물을 찾아라"와 같은 목표를 주고, 로봇은 세상 속을 돌아다니며 움직이려고 노력합니다. 때때로 로봇은 실수를 합니다. 예를 들어, 이미 열려 있는 문을 열려고 시도하거나, 존재하지 않는 아이템을 집으려고 하는 식이죠. 인공지능의 세계에서 이 로노는 "LLM 에이전트"라고 불리며, 로봇의 움직임이 유효한지 확인하는 부분은 "검증기(validator)"라고 불립니다.

오랫동안 로봇이 실수했을 때, 검증기는 그저 "아니, 틀렸어"라고 말하며 로봇이 다시 시도하게끔 내버려 두었습니다. 이는 마치 학생에게 왜 답이 틀렸는지, 혹은 정답이 무엇인지 알려주지 않은 채 "다시 해봐"라고만 말하는 선생님과 같습니다. 로봇은 운 좋게 맞출 때까지 그저 다시 추측할 뿐이었죠. 하지만 만약 검증기가 더 도움이 될 수 있다면 어떨까요? 만약 검증기가 정확히 어디에서 실수가 발생했는지 짚어주고, 로봇이 실제로 무엇을 했는지 보여주며, 심지어 로봇이 대신 할 수 있었던 일들의 목록을 제안할 수 있다면 어떨까요? 이 논문은 다음과 같은 단순하지만 강력한 질문을 던집니다. 상세한 "수리 키트(repair kit)" 정보를 제공하는 것이 단순히 "다시 해봐"라는 메시지를 주는 것보다 로봇이 실수를 더 빠르고 효과적으로 고치는 데 도움이 되는가?

연구진은 이 실험을 위해 VeriHarness라는 특별한 테스트 환경을 구축했습니다. 이것은 엄격한 심판(검증기)이 로봇(AI 모델)의 게임 플레이를 지켜보는 비디오 게임 레벨과 같습니다. 만약 로봇이 잘못된 움직임을 보이면, 심판은 게임을 멈추고 로봇에게 쪽지를 건넵니다. 연구팀은 어떤 종류의 쪽지가 가장 효과적인지 테스트하고 싶었습니다. 그들은 네 가지 유형의 쪽지를 테스트했습니다:

원시 쪽지(The Raw Note): "명령 1이 유효하지 않습니다"와 같이 단순한 에러 메시지만 전달합니다.
산문 쪽지(The Prose Note): 실수가 어디에서 발생했는지, 로봇이 무엇을 보았는지, 그리고 무엇을 했어야 했는지를 설명하는 친절한 단락 형태입니다.
구조화된 쪽지(The Structured Note): 산문 쪽지와 동일한 정보를 담고 있지만, 기술적인 라벨(JSON 파일처럼)이 붙은 목록 형태로 구성되어 있습니다.
"위치 전용" 쪽지(The "Location Only" Note): 로봇이 어디에서 실수했는지와 무엇을 보았는지는 알려주되, 대안은 제시하지 않습니다.

그들은 두 가지 AI 모델(Qwen과 Llama라고 불리는)이 텍let 기반 어드벤처 게임을 플레이하는 실험을 50회 실시했습니다. 목표는 로봇이 4번의 기회 안에 얼마나 자주 결승선에 도달하여(게임을 승리하여) 성공하는지 보는 것이었습니다.

결과는 "원시 쪽지"를 지지하던 사람들에게 큰 놀라움을 안겨주었습니다. 실수가 발생한 위치를 알려주고, 무엇을 관찰했는지 보여주며, 대신 할 수 있는 허용 가능한 대안들의 목록을 포함한 상세한 쪽지를 받았을 때, 로봇은 챔피언이 되었습니다.

Qwen 모델의 경우, 성공률이 원시 에러 메시지를 받았을 때의 **28%**에서 상세한 쪽지를 받았을 때 **72%**로 급증했습니다. 이는 44 퍼센트 포인트의 향상입니다.
Llama 모델의 경우, **16%**에서 **58%**로 뛰어올랐으며, 이는 42 퍼센트 포인트의 상승입니다.

이 발견의 가장 흥럽고 흥미로운 부분은 바로 왜 이런 결과가 나왔는가 하는 점입니다. 연구진은 로봇이 단순히 "구조화된 쪽지"(기술적 라벨이 있는 것)의 깔끔하고 조직적인 외형을 좋아해서 그런 것이 아닐까 의심했습니다. 하지만 그들은 이를 확인하기 위해 산문 형태의 영어 문장인 "산문 쪽지"와 "구조화된 쪽지"를 비교했습니다. 결과는 어땠을까요? 두 방식은 거의 동일한 성과를 보였습니다. 조언이 친절한 단락으로 쓰였든 기술적인 목록으로 쓰였든 그것은 크게 중요하지 않았습니다. 마법의 핵심 요소는 형식이 아니라 바로 내용이었습니다.

구체적으로, "위치 전용" 쪽지(실패한 위치는 알려주지만 새로운 아이디어를 주지 않는 것)는 별로 도움이 되지 않았습니다. 이 방식은 원시 에러 메시지의 낮은 성공률 근처에 머물렀습니다. 이는 단순히 실수를 지적하는 것만으로는 충분하지 않으며, 로봇에게 선택할 수 있는 유효한 대안들의 목록을 쥐여주어야 한다는 것을 증명합니다. 이는 선생님이 "너 'cat' 철자를 틀렸어"라고 말하는 것과 "너 'cat' 철자를 틀렸어. 대신 'bat', 'hat', 또는 'mat'이라고 쓸 수 있었어"라고 말하는 것의 차이와 같습니다.

연구진은 또한 이 기법이 코딩 작업(HumanEval이라는 문제 세트 사용)에서도 작동하는지 확인했습니다. 그들은 이 방법이 검증기가 실제로 실수를 볼 수 있을 때만 작동한다는 것을 발견했습니다. 만약 로봇이 눈에 보이는 테스트는 통과했지만 검증기가 볼 수 없는 숨겨진 테스트에서 실패한다면, 아무리 상세한 피드백을 주어도 고칠 수 없습니다. 이는 상세한 피드백이 강력한 초능력이긴 하지만 마법은 아니라는 점을 시사합니다. 즉, 검증기가 볼 수 있는 것만 고칠 수 있다는 것입니다.

결론적으로, 이 논문은 우리가 AI 에이전트가 스스로의 실수를 더 잘 고치기를 원한다면, 단순히 다시 추측하게 해서는 안 된다고 제안합니다. 우리는 검증기가 코치처럼 행동하도록 만들어야 합니다. 즉, 구체적인 오류를 지적하고, 실제로 어떤 일이 일み했는지 보여주며, 다음에 시도할 수 있는 올바른 옵션들의 메뉴를 제공해야 합니다. AI에게는 구체적이고 실행 가능한 조언 한 마디가 수천 번의 "다시 해봐"보다 훨씬 더 가치 있는 법입니다.

기술 요약: 구조화된 피드백이 LLM 에이전트 루프의 수리 성능을 향상시킨다

문제 정의

대규모 언어 모델(LLM) 에이전트는 모델이 후보를 생성하고 외부 검증기가 이를 거절하는 반복 루프를 자주 활용하지만, 검증기와 후속 모델 호출 사이의 인터페이스는 명확히 규정되어 있지 않습니다. 현재 시스템은 종종 "원시 진단(raw diagnostics)"—단순한 거절 메시지(예: "명령 1은 허용되지 않습니다")—에 의존하며, 이는 모델이 성공적인 수리를 생성하는 데 필요한 구체적인 맥락이 부족할 수 있습니다. 핵심 질문은 다음과 같습니다: 결정론적 검증기가 다음 모델 호출에 전달하여 수리 성공을 극대화할 수 있는 구체적인 정보는 무엇인가?

방법론

시스템 아키텍처: VeriHarness

저자들은 생성과 수용을 분리하는 코드 제어 에이전트 루프인 VeriHarness를 소개합니다.

오케스트레이션: 주 오케스트레이터가 모델의 컨텍스트 창 외부에서 상태, 예산 및 트레이스를 관리합니다.
워크플로우: LLM 워커는 구조화된 후보(예: JSON 플랜)를 생성합니다. 외부 게이트(검증기)는 스키마, 아티팩트 및 환경 동작에 대해 후보를 검사합니다. 공통 인터페이스로 게이트별 세부 정보를 매핑하는 "실패 인코더(failure encoder)"가 리페어 페이로드를 반환합니다. 모델은 압축된 작업 상태와 현재의 수리 피드백만을 수신하며, 스스로 검증할 수는 없습니다.
피드백 루프: 후보가 실패하면, "실패 인코더"가 게이트별 세부 사항을 공통 인터페이스로 매핑하여 모델에 수리 페이로드를 반환합니다.

실험 설계

본 연구는 50개의 쌍으로 된 TextWorld 게임(3개 방, 4개 객체, 2단계 퀘스트)을 사용하여 두 가지 모델인 Qwen2.5-Coder-14B와 Llama-3.1-8B를 대상으로 피드백 정책을 평가합니다. 주요 제약 조건은 게임당 4회 호출 제한입니다.

저자들은 네 가지 피드백 정책을 비교합니다 (표 1):

RawDiag: 명시적인 수리 필드 없이 원래의 검증 오류 문자열을 반환합니다.
SameNL: 유형화된 레이블 없이 실패 위치, 관찰된 값, 그리고 허용 가능한 대안들을 자연어 산문 형태로 제공합니다.
LocObs: 실패 레이블과 위치 및 관찰된 값을 위한 명명된 JSON 필드를 제공하지만, 허용 가능한 대안은 생략합니다.
TypedFields: 실패 레이블, 위치 및 관찰된 값을 위한 명명된 JSON 필드와 더불어, 허용 가능한 대안 목록을 포함하는 필드를 제공합니다.

강건성 검사

예산 민감도: 15개 게임 서브셋에 대해 2, 4, 6, 8회의 호출 예산을 테스트했습니다.
디코딩 변동성: 세 개의 시드에 대해 샘플링 디코딩(온도 0.3, top-p 0.9)을 사용하여 Qwen을 테스트했습니다.
범위 체크: 검증기가 단 하나의 공개 어설션(assertion)만 보는 HumanEval 실험을 통해, 메커니즘이 실제로 실패가 노출될 때만 테스트되도록 보장했습니다.

주요 결과

1. 구조화된 피드백이 성공률을 유의미하게 향상시킨다

4회 호출 제한 하에서, 위치, 관찰된 값, 그리고 허용 가능한 대안을 포함하는 피드백은 원시 진단보다 압도적으로 우수한 성능을 보였습니다.

Qwen2.5-Coder-14B: 성공률이 **28% (RawDiag)**에서 **72% (TypedFields)**로 증가했습니다 (+44 퍼센트 포인트).
Llama-3.1-8B: 성공률이 **16% (RawDiag)**에서 **58% (TypedFields)**로 증가했습니다 (+42 퍼센트 포인트).
통계적 유의성: 이러한 개선은 Holm-조정된 $p < 0.001$ 수준에서 통계적으로 유의미하며, Qwen의 경우 [28–60], Llama의 경우 [28–56]의 95% 부트스트랩 구간을 가집니다.

2. 개선의 원천: 수리 값 vs 포맷

절제 연구(Ablation studies)를 통해 성능 향상의 원인을 격리했습니다:

허용 가능한 대안이 결정적임: LocObs 정책(위치 + 관찰값은 제공하지만 대안은 없음)은 RawDiag 베이스라인과 유사한 성능을 보였습니다 (Qwen의 경우 36% vs 28%, Llama의 경우 18% vs 16%). 이는 단순히 어디가 그리고 무엇이 실패했는지 아는 것만으로는 부족하며, 대신 무엇을 해야 하는지를 아는 것이 필수적임을 나타냅니다.
포맷은 부차적임: SameNL(산문)과 TypedFields(키가 지정된 JSON)는 거의 동일하게 작동했습니다.
- Qwen: SameNL (70%) vs TypedFields (72%).
- Llama: SameNL (58%) vs TypedFields (58%).
- 수리 값이 일치할 때 산문과 JSON 포맷 간에는 유의미한 차이가 없음을 통계적 테스트( $p=1.0$ )로 확인했습니다. JSON 포맷이 추론 능력을 직접적으로 향상시키지는 않았으나, 총 호출 횟수를 약간 줄이는 효과는 있었습니다.

3. 예산 및 디코딩 강건성

예산 민감도: 호출 예산이 2에서 4로 증가함에 따라 구조화된 피드백과 원시 진단 사이의 성능 격차가 벌어집니다. RawDiag 성능은 4회 호출 이후 정체되는 반면, 구조화된 피드백은 추가 호출과 함께 계속 개선됩니다.
디코딩: 샘플링 디코딩 설정에서도 결과의 순서(TypedFields/SameNL > LocObs > RawDiag)가 유지되었습니다.

4. HumanEval에 의해 드러난 한계점

HumanEval 범위 체크에서, 첫 번째 답변이 모든 15개 태스크의 가시적 테스트를 통과했으므로 검증기가 수리 기회를 반환하지 않았습니다. 결과적으로 모든 정책은 동일한 성공률(14/15)로 한 번의 호출 후에 중단되었습니다. 이는 구조화된 피드백이 검증기가 실패를 감지하거나 노출하지 못할 경우 이를 수리할 수 없음을 확인시켜 줍니다.

의의 및 주장

본 논문은 LLM 에이전트 수리 루프의 주요 병목 현상이 모델의 추론 능력이 아니라 피드백의 정보적 내용이라고 주장합니다.

검증기 설계: 검증기는 일반적인 거절 메시지 대신 실패 위치, 관찰된 값, 그리고 허용 가능한 대안 목록과 같은 구체적인 수리 정보를 반환해야 합니다.
포맷 불가지론(Format Agnosticism): 특정 구문(JSON vs 산문)은 수리 값 자체의 존재보다 덜 중요합니다. JSON은 로깅 및 라우팅에는 도움이 되지만, 이 문맥에서 모델의 추론 능력을 본질적으로 향상시키지는 않습니다.
조건부 유용성: 이 메커니즘은 검증기가 실패를 노출할 수 있을 때만 유효합니다. 만약 검증기가 대안을 열거하거나 특정 오류를 감지할 수 없다면, 수리 루프는 작동할 수 없습니다.

저자들은 에이전트 설계에 있어, 프롬프트 오케스트레이션을 최적화하는 것보다 실패 시 실행 가능한 열거된 대안을 반환하는 결정론적 검증기를 엔지니어링하는 데 집중해야 한다고 결론짓습니다.