멀티스텝 에이전트의 Binding Drift: 첫 엔티티를 고정하면 오히려 위험하다

Who Should Read

CRM·티켓·캘린더 같은 도구를 여러 단계에 걸쳐 호출하는 에이전트에서 엉뚱한 대상에 액션이 실행돼 고민인 백엔드 개발자

Core Mechanics

• Drift와 propagation은 다른 문제다
  • Drift는 1단계에선 맞았는데 뒤 단계에서 다른 엔티티로 바뀌는 것이다.
  • Propagation은 1단계에서 이미 틀린 엔티티를 끝까지 끌고 가는 것이다.
  • 논문은 두 가지를 서로 겹치지 않는 워크플로 집합에서 따로 채점한다.
• 첫 바인딩 고정은 양날의 검이다
  • entity lock(첫 엔티티를 고정해 재사용)은 자연 상태 drift를 없앤다.
  • 하지만 틀린 엔티티를 심어 두면 틀린 액션이 baseline 907건에서 2,746건으로 3.0배 늘었다.
  • 틀린 값을 모든 후속 단계에 충실히 가져가기 때문이다.
• 강한 모델일수록 더 크게 증폭됐다
  • Claude Opus 4.5는 lock 증폭이 8.5배로 가장 컸다.
  • Nova Premier 5.3배, Llama-3.3-70B 3.3배, Claude Sonnet 4.5 2.6배였다.
  • 8개 모델 전부에서 증폭이 나타났다.
• 싼 모델로 재검증하면 거의 오라클 수준이다
  • 원래 요청 문구만 다시 읽혀 엔티티를 다시 찾게 하는 두 번째 호출을 넣었다.
  • 틀린 액션이 79% 줄어 오라클 상한(0.20배)과 1%p 이내로 붙었다.
  • 검증기는 Nova Micro 한 번 호출이며 액션 단계당 지연은 약 0.3초다.

Evidence

• 오류 주입 시 lock이 오류를 키웠다
  • 모델 8개×비모호 워크플로 160개(총 1,280개)에서 틀린 액션이 baseline 907건에서 lock 2,746건(3.03배, 95% CI [2.8, 3.3])이 됐다.
  • lock 적용 시 워크플로 성공률은 0.0%였다.
• LLM 교차 재검증이 오라클에 근접했다
  • Nova Micro 교차 검증은 틀린 액션 189건(baseline 대비 0.21배, CI [0.18, 0.25])이었다.
  • 오라클은 180건(0.20배)이고 self-reverify는 261건(0.29배)이었다.
• 자연 상태에서도 drift가 발생했다
  • 1단계에서 맞게 바인딩한 워크플로의 18%에서 baseline이 drift했다.
  • 단계별 오류율은 1~2단계 약 8%에서 3단계 28%로 올랐다(3단계는 N=128, 1~2단계는 N=288).
  • lock을 쓰면 이 상승이 사라져 9% 아래로 유지됐다.
• 모델별 lock 증폭 편차가 컸다
  • Nova Micro 1.8배부터 Claude Opus 4.5 8.5배까지였다(Opus는 baseline 52건에서 lock 442건).
  • 벤치마크는 합성 워크플로 200개, 엔티티 바인딩 채점 단계 580개, 4개 도메인이다.

How to Apply

• 고위험 액션 직전에 재검증 호출 넣기
  • 삭제·이메일 발송·상태 변경 같은 액션 직전에 작은 모델을 한 번 더 호출한다.
  • 입력은 1단계 원문 요청 문구와 후보 엔티티 목록만 주고, 이전 대화 이력은 주지 않는다.
• 검증 결과가 다르면 바인딩을 덮어쓰기
  • 재검증 ID가 에이전트가 들고 있던 ID와 다르면 재검증 값으로 교체하고 lock도 갱신한다.
  • AMBIGUOUS가 나오거나 파싱에 실패하면 교정하지 않는다.
• lock 단독 사용 금지, 함께 쓰기
  • 상태 고정은 drift 방지용으로만 쓰고 틀린 첫 바인딩 대비책으로 보지 않는다.
  • 첫 바인딩 이후에도 원문 기준 재도출 경로를 별도로 둔다.
• 자기 서비스에 오류 주입 테스트 만들기
  • 테스트 워크플로 상태와 히스토리에 일부러 틀린 엔티티 ID를 "(prior) identified the account as X" 형태로 심는다.
  • 에이전트가 그 오류를 몇 단계까지 끌고 가는지 틀린 액션 수로 센다.

Try It

# Claude/ChatGPT에 붙여넣기 (논문 방법의 간이 버전: 원문 요청만으로 엔티티를 독립 재판정)

You are an independent entity resolver. Given the original user request and candidate entities, determine which entity the request refers to.

Original request: "{{1단계 원문 요청 문구}}"
Candidate entities: {{후보 엔티티 목록 JSON (id, type, name, metadata)}}

Which entity ID does the original request refer to? Return ONLY: {"entity_id": "the_correct_id"}. If genuinely ambiguous, return: {"entity_id": "AMBIGUOUS"}.

# 이어서 해 볼 것: 에이전트가 실제로 쓰려던 ID와 이 결과를 비교해, 다르면 교체하고 AMBIGUOUS면 그대로 두세요.

Terminology

관련 논문

• 같은 시뮬레이션, 다른 근거: 도구 출력을 파일로 넘기면 LLM 에이전트 정확도가 어디서 깎이나

  긴 툴 출력을 파일로 넘기자 GPT-5.1은 정확도 11.3%p 하락, 정식 출력 지정하니 회복

• 가짜 뉴스가 진짜 폭락을: LLM 트레이딩 에이전트 대상 정보 주입 공격

  가짜 헤드라인 한 줄로 LLM 트레이딩 에이전트 62%를 조종했다(프롬프트 주입은 14%)

• Harness Engineering 101: LLM은 뇌, harness는 몸

  에이전트는 JSON 배열을 관리하는 루프이고, 16개 챕터로 직접 만들어 본다

• Harness²: 에이전트 harness를 스스로 고쳐 쓰는 재귀 최적화 프레임워크

  모델은 고정하고 harness를 재귀로 고쳤더니 벤치마크 점수가 최대 11.8%p 올랐다

• 해고된 Savannah 경찰관, ICE 요원 남편에게 Flock 계정 공유

  경찰관이 Flock 계정을 남편(ICE 요원)에게 공유했고, 감사에서 983건 검색이 드러나 해고됐다

• tmux와 Claude Code: 세션, send-keys, 그리고 한계선

  tmux로 Claude Code 여러 개를 돌리면 편하지만 에이전트 4개쯤에서 한계가 온다

• Hybrid Reasoning Agents: 잠재 공간에서 생각하고 텍스트로 행동하는 LLM 에이전트

  잠재 공간 추론과 텍스트 도구 호출을 섞었더니 성능 10.4%↑, 토큰 최대 54.7%↓

Related Resources

• https://github.com/shashank-indukuri/binding-drift