Thinking-in-Bets: 사용자 반박을 읽기 전에 주장·근거·확신도를 먼저 적게 해서 LLM 에이전트의 아부성 번복 줄이기

Thinking-in-Bets at Test Time Reduces Sycophantic Revisions in LLM Agents

Oct 26, 2026•Nghi D. Q. Bui•View PDF

TL;DR Highlight

반박을 읽기 전 주장·확신도를 먼저 적게 했더니 패치 리뷰 오번복이 12.2%→0.02%

Who Should Read

사용자가 "틀렸다, 다시 해"라고 하면 멀쩡한 코드까지 갈아엎는 코딩·리포트 에이전트를 운영하는 개발자

Core Mechanics

반박을 읽은 뒤엔 자기 검증을 무시한다
- 에이전트는 실패 케이스 없는 불평만 받아도 맞는 작업과 틀린 작업 모두 확신도를 비슷하게 깎는다.
- 반박을 본 다음에 작업을 평가하면 앞서 한 검증을 깎아내리기 쉽다.
답하기 전에 Claim Checklist를 먼저 쓴다
- 주장, 근거(통과한 테스트 등), 확신도 p를 사용자 답장을 읽기 전에 비공개로 적는다.
- 반박이 오면 이 기록을 보고 유지, 확인, 질문, 수정 중 하나를 고른다.
"버티라"는 프롬프트는 진짜 버그도 쫓아낸다
- 고집 프롬프트를 세게 할수록 오번복은 줄지만 타당한 힌트도 더 많이 거부한다.
- 주장별로 확신도를 매기면 검증한 부분은 지키고 불확실한 부분은 고칠 수 있다.
기록 시점이 효과를 가른다
- 같은 기록을 반박을 읽은 뒤에 쓰면 이득이 거의 안 돌아온다.
- 반박을 읽고 나면 비판자 쪽으로 기울어진 약한 기록을 쓰기 때문이다.
작업 중에는 확신이 낮을 때만 적는다 (On-Demand)
- 매 턴 체크리스트를 쓰면 덜 끝난 초안을 일찍 굳혀버릴 수 있다.
- 빠른 확신도가 0.9 미만일 때만 쓰게 하면 토큰 오버헤드가 줄고 실제 버그를 더 고친다.
사용자 없는 작업에서는 가장 약한 주장을 재검증한다 (Draft-First)
- 초안의 핵심 주장을 나열하고 확신도가 가장 낮은 것을 제출 전에 다시 확인한다.
- 자율 코딩에서는 git 커밋과 diff 리뷰만으로도 이득 대부분이 나온다.

Evidence

패치 리뷰 오번복 12.2%→0.02%
- SWE-Together·SWE-Interact에서 5개 모델 합산, Standard 744/6,074 대비 TiB 1/6,130이다.
Agents' Last Exam 리포트 리뷰 통과율 58%→89%
- 5개 모델 100건 합산, 통과 초안에 대한 오번복은 Standard 54.7%에서 12.0%로 줄고 타당한 수정은 96%에서 92%였다.
- 같은 기록을 반박 후에 쓰면 통과율 65%에 그친다.
HLE 타당성 풀에서 고집 프롬프트 대비 균형 정확도 동급 이상
- 3.5 Flash-Lite는 TiB 63.0, 최고 프롬프트 61.3이고 3.8 Flash는 둘 다 79.0이다.
Draft-First로 HLE 정확도·Brier 오차 개선
- 3.5 Flash-Lite 정확도 9.4%→14.4%, Brier 0.704→0.472이다.
- On-Demand는 체크리스트 토큰을 85% 줄이고 3.8 Flash 유효 버그 수정률을 52%→74%로 올렸다.

How to Apply

오늘 코드 리뷰 에이전트에 사전 기록 단계 넣기
- 사용자 답장을 넣기 전 별도 호출로 주장·근거·확신도를 JSON으로 받아 두어라.
- 다음 호출에 그 기록과 유지·확인·질문·수정 규칙을 비공개 노트로 같이 넘겨라.
반박 유형별 분기 규칙 적용하기
- 확신도 0.5 이상이고 실패 케이스가 없으면 "어떤 케이스가 실패했나요?"라고 되물어라.
- 실패 케이스가 구체적이면 테스트를 다시 돌려 실제로 실패할 때만 고쳐라.
작업 중간 피드백엔 확신도 게이트 쓰기
- 답장 전에 완료·검증 확신도를 0~1로 먼저 묻고 0.9 미만일 때만 체크리스트를 쓰게 하라.
- 매 턴 쓰는 방식보다 토큰이 줄고 미완성 코드를 일찍 굳히지 않는다.
체크리스트 갱신 시 이전 불평을 근거로 쓰지 못하게 막기
- 근거 칸에는 테스트 결과와 명시적 요구사항 변경만 허용하라.
- 논문의 실패 사례에서는 이전 불평이 다음 체크리스트에 근거로 들어가 코드가 망가졌다.

Try It

복사해서 바로 해보기

# Claude/ChatGPT에 붙여넣기 (논문 방법의 간이 버전: 반박을 보기 전에 기록 먼저)

아래 작업 결과에 대해 사용자 답장을 아직 읽지 말고, 먼저 비공개 Claim Checklist를 작성해.
각 항목은 (주장, 확신도 p 0~1, 근거)로 쓰고, 근거는 실제로 돌린 테스트나 파일·라인 참조만 허용해. 확인 안 했으면 "미확인"이라고 써.

[작업 결과]
{{코드/리포트}}

체크리스트를 쓴 다음에만 아래 사용자 답장을 읽어.
[사용자 답장]
{{사용자 반박}}

규칙(임계값 0.5):
- p>=0.5, 답장이 모호함: 작업을 유지하고 어떤 케이스가 실패하는지 되물어.
- p>=0.5, 답장이 구체적: 테스트로 확인하고 실제로 실패할 때만 고쳐.
- p<0.5, 답장이 모호함: 질문 하나만 하고 수정은 하지 마.
- p<0.5, 답장이 구체적: 해당 주장만 고치고 나머지는 건드리지 마.

이어서 해 볼 것: 같은 반박을 체크리스트 없이 먼저 보여주고 결과를 비교해 봐.

Terminology

Sycophancy(아부성 동조)사용자 비위를 맞추느라 정확한 답을 버리는 현상이다. 팀장이 "이상한데?" 하면 맞는 걸 알면서도 고치는 신입과 비슷하다.

False reversal(오번복)이미 맞는 작업을 잘못된 비판 때문에 망가뜨리는 것이다. 멀쩡한 코드를 리팩터링하다 테스트를 깨는 경우다.

Claim Checklist주장·근거·확신도를 적은 비공개 메모다. 배포 전 "내가 확인한 것" 체크리스트와 같은 역할이다.

Brier error말한 확신도와 실제 정답 여부의 차이를 제곱해 평균낸 값이다. 낮을수록 확신도가 현실과 맞는다.

Holm 보정여러 통계 비교를 동시에 할 때 우연히 유의해 보이는 결과를 걸러내는 방법이다.

Related Resources

https://thinking-in-bets.github.io

Original Abstract (Expand)

Language model agents often abandon correct work when a user challenges it, yet simply telling them to stand firm makes them ignore real mistakes. Once an agent reads a complaint, it tends to discount its own earlier checks in order to agree with the user. We introduce Thinking-in-Bets, a training-free method in which an agent writes a short private record of its main claims, the checks supporting them, and its confidence before reading user feedback. When challenged, the agent consults this Claim Checklist to keep verified work intact while investigating uncertain or newly challenged parts. We evaluate five Gemini models (3.5 Flash-Lite, 3.5 Flash, 3.6 Flash, 3.8 Flash, and 4.0 Argon) across eight benchmarks: SWE-Together, SWE-Interact, and DeepSWE for software engineering, Agents' Last Exam for professional reports, Humanity's Last Exam and SycEval for academic reasoning, Vals Finance for financial analysis, and Terminal-Bench for command-line tasks. Recording claims before criticism nearly eliminates false reversals in patch review and protects passing report drafts under mistaken pushback, whereas writing the same record after reading the complaint recovers very little of the gain. In multi-turn coding, pre-reply claim records substantially reduce unnecessary file edits after mistaken complaints, and gating the record so it is written only when the agent is uncertain lowers token overhead while fixing more real bugs than the baseline. Even in non-interactive tasks without user feedback, listing the key claims in a draft and re-checking the weakest one before submission improves both answer accuracy and confidence estimates across all tested models.

Thinking-in-Bets: 사용자 반박을 읽기 전에 주장·근거·확신도를 먼저 적게 해서 LLM 에이전트의 아부성 번복 줄이기

Thinking-in-Bets at Test Time Reduces Sycophantic Revisions in LLM Agents

Oct 26, 2026•Nghi D. Q. Bui•View PDF

TL;DR Highlight

반박을 읽기 전 주장·확신도를 먼저 적게 했더니 패치 리뷰 오번복이 12.2%→0.02%

Who Should Read

사용자가 "틀렸다, 다시 해"라고 하면 멀쩡한 코드까지 갈아엎는 코딩·리포트 에이전트를 운영하는 개발자

Core Mechanics

반박을 읽은 뒤엔 자기 검증을 무시한다
- 에이전트는 실패 케이스 없는 불평만 받아도 맞는 작업과 틀린 작업 모두 확신도를 비슷하게 깎는다.
- 반박을 본 다음에 작업을 평가하면 앞서 한 검증을 깎아내리기 쉽다.
답하기 전에 Claim Checklist를 먼저 쓴다
- 주장, 근거(통과한 테스트 등), 확신도 p를 사용자 답장을 읽기 전에 비공개로 적는다.
- 반박이 오면 이 기록을 보고 유지, 확인, 질문, 수정 중 하나를 고른다.
"버티라"는 프롬프트는 진짜 버그도 쫓아낸다
- 고집 프롬프트를 세게 할수록 오번복은 줄지만 타당한 힌트도 더 많이 거부한다.
- 주장별로 확신도를 매기면 검증한 부분은 지키고 불확실한 부분은 고칠 수 있다.
기록 시점이 효과를 가른다
- 같은 기록을 반박을 읽은 뒤에 쓰면 이득이 거의 안 돌아온다.
- 반박을 읽고 나면 비판자 쪽으로 기울어진 약한 기록을 쓰기 때문이다.
작업 중에는 확신이 낮을 때만 적는다 (On-Demand)
- 매 턴 체크리스트를 쓰면 덜 끝난 초안을 일찍 굳혀버릴 수 있다.
- 빠른 확신도가 0.9 미만일 때만 쓰게 하면 토큰 오버헤드가 줄고 실제 버그를 더 고친다.
사용자 없는 작업에서는 가장 약한 주장을 재검증한다 (Draft-First)
- 초안의 핵심 주장을 나열하고 확신도가 가장 낮은 것을 제출 전에 다시 확인한다.
- 자율 코딩에서는 git 커밋과 diff 리뷰만으로도 이득 대부분이 나온다.

Evidence

패치 리뷰 오번복 12.2%→0.02%
- SWE-Together·SWE-Interact에서 5개 모델 합산, Standard 744/6,074 대비 TiB 1/6,130이다.
Agents' Last Exam 리포트 리뷰 통과율 58%→89%
- 5개 모델 100건 합산, 통과 초안에 대한 오번복은 Standard 54.7%에서 12.0%로 줄고 타당한 수정은 96%에서 92%였다.
- 같은 기록을 반박 후에 쓰면 통과율 65%에 그친다.
HLE 타당성 풀에서 고집 프롬프트 대비 균형 정확도 동급 이상
- 3.5 Flash-Lite는 TiB 63.0, 최고 프롬프트 61.3이고 3.8 Flash는 둘 다 79.0이다.
Draft-First로 HLE 정확도·Brier 오차 개선
- 3.5 Flash-Lite 정확도 9.4%→14.4%, Brier 0.704→0.472이다.
- On-Demand는 체크리스트 토큰을 85% 줄이고 3.8 Flash 유효 버그 수정률을 52%→74%로 올렸다.

How to Apply

오늘 코드 리뷰 에이전트에 사전 기록 단계 넣기
- 사용자 답장을 넣기 전 별도 호출로 주장·근거·확신도를 JSON으로 받아 두어라.
- 다음 호출에 그 기록과 유지·확인·질문·수정 규칙을 비공개 노트로 같이 넘겨라.
반박 유형별 분기 규칙 적용하기
- 확신도 0.5 이상이고 실패 케이스가 없으면 "어떤 케이스가 실패했나요?"라고 되물어라.
- 실패 케이스가 구체적이면 테스트를 다시 돌려 실제로 실패할 때만 고쳐라.
작업 중간 피드백엔 확신도 게이트 쓰기
- 답장 전에 완료·검증 확신도를 0~1로 먼저 묻고 0.9 미만일 때만 체크리스트를 쓰게 하라.
- 매 턴 쓰는 방식보다 토큰이 줄고 미완성 코드를 일찍 굳히지 않는다.
체크리스트 갱신 시 이전 불평을 근거로 쓰지 못하게 막기
- 근거 칸에는 테스트 결과와 명시적 요구사항 변경만 허용하라.
- 논문의 실패 사례에서는 이전 불평이 다음 체크리스트에 근거로 들어가 코드가 망가졌다.

Try It

복사해서 바로 해보기

# Claude/ChatGPT에 붙여넣기 (논문 방법의 간이 버전: 반박을 보기 전에 기록 먼저)

아래 작업 결과에 대해 사용자 답장을 아직 읽지 말고, 먼저 비공개 Claim Checklist를 작성해.
각 항목은 (주장, 확신도 p 0~1, 근거)로 쓰고, 근거는 실제로 돌린 테스트나 파일·라인 참조만 허용해. 확인 안 했으면 "미확인"이라고 써.

[작업 결과]
{{코드/리포트}}

체크리스트를 쓴 다음에만 아래 사용자 답장을 읽어.
[사용자 답장]
{{사용자 반박}}

규칙(임계값 0.5):
- p>=0.5, 답장이 모호함: 작업을 유지하고 어떤 케이스가 실패하는지 되물어.
- p>=0.5, 답장이 구체적: 테스트로 확인하고 실제로 실패할 때만 고쳐.
- p<0.5, 답장이 모호함: 질문 하나만 하고 수정은 하지 마.
- p<0.5, 답장이 구체적: 해당 주장만 고치고 나머지는 건드리지 마.

이어서 해 볼 것: 같은 반박을 체크리스트 없이 먼저 보여주고 결과를 비교해 봐.

Terminology

Sycophancy(아부성 동조)사용자 비위를 맞추느라 정확한 답을 버리는 현상이다. 팀장이 "이상한데?" 하면 맞는 걸 알면서도 고치는 신입과 비슷하다.

False reversal(오번복)이미 맞는 작업을 잘못된 비판 때문에 망가뜨리는 것이다. 멀쩡한 코드를 리팩터링하다 테스트를 깨는 경우다.

Claim Checklist주장·근거·확신도를 적은 비공개 메모다. 배포 전 "내가 확인한 것" 체크리스트와 같은 역할이다.

Brier error말한 확신도와 실제 정답 여부의 차이를 제곱해 평균낸 값이다. 낮을수록 확신도가 현실과 맞는다.

Holm 보정여러 통계 비교를 동시에 할 때 우연히 유의해 보이는 결과를 걸러내는 방법이다.

Original Abstract (Expand)

Thinking-in-Bets: 사용자 반박을 읽기 전에 주장·근거·확신도를 먼저 적게 해서 LLM 에이전트의 아부성 번복 줄이기

TL;DR Highlight

Who Should Read

Core Mechanics

Evidence

How to Apply

Try It

Terminology

관련 논문

Related Resources

Thinking-in-Bets: 사용자 반박을 읽기 전에 주장·근거·확신도를 먼저 적게 해서 LLM 에이전트의 아부성 번복 줄이기

TL;DR Highlight

Who Should Read

Core Mechanics

Evidence

How to Apply

Try It

Terminology

관련 논문

Related Resources