다단계 AI 에이전트의 상태 드리프트를 줄이는 실용적인 기법

문제 파악하기

다중 단계 또는 다중 에이전트 워크플로우를 구축할 때 흔히 발생하는 문제는 각 요소가 독립적으로는 작동하지만 단계 간에 연결되면 오류가 발생한다는 것입니다. 주요 증상은 다음과 같습니다:

• 동일한 입력이 실행마다 다른 결과를 생성함
• 에이전트가 이전 결정을 "잊어버림"
• 디버깅이 거의 불가능해짐

처음에는 이러한 문제들이 프롬프트 문제, 온도 무작위성, 또는 불량 검색으로 오인되었지만, 근본 원인은 상태 드리프트였습니다.

효과적인 실용적 해결책

"최신 컨텍스트" 의존 중단

대부분의 설정에서 N단계는 현재 존재하는 컨텍스트를 읽습니다. 문제는 컨텍스트가 불안정하다는 점입니다—특히 병렬 단계나 비동기 업데이트가 있을 때 더욱 그렇습니다.

스냅샷 기반 읽기 도입

"최신 상태"를 읽는 대신, 각 단계는 고정된 스냅샷에서 읽습니다. 예를 들어, 3단계는 "현재 메모리"를 읽지 않고 스냅샷 v2(고정)를 읽습니다. 이렇게 하면 실행이 결정론적이 됩니다.

쓰기를 추가 전용으로 설정

공유 메모리를 변경하는 대신, 모든 단계는 덮어쓰지 않고 새로운 버전을 작성합니다. 따라서 v2 → 단계 → v3 생성, 그 다음 v3 → 다음 단계 → v4 생성. 이렇게 하면 다음과 같은 것이 가능해집니다:

• 흐름 재생
• 정확한 실패 디버깅
• 실행 비교

"상태"와 "컨텍스트" 분리

이 구분이 중요했습니다. 이제 다음과 같이 처리합니다:

• 상태 = 구조화된, 지속적인 (결정, 출력, 변수)
• 컨텍스트 = 임시적인 (모델이 단계별로 보는 내용)

두 가지를 혼합하지 마세요.

상태를 최소화하고 구조화하기

전체 채팅 기록을 덤프하는 대신, 다음과 같은 내용을 저장합니다:

• 목표
• 현재 단계
• 지금까지의 출력
• 내린 결정

다른 모든 것은 필요할 때 파생됩니다.

온도를 전략적으로 사용하기

온도가 주요 문제는 아니었습니다. 더 효과적인 방법은 다음과 같습니다:

• 상태 변경 단계에는 낮은 온도(0–0.3) 사용
• 더 높은 온도는 "창의적인" 말단 단계에만 사용

결과

이러한 변경 사항을 구현한 후:

• 실행이 재현 가능해짐
• 다중 에이전트 조정이 개선됨
• 디버깅이 추측에서 추적 가능한 작업으로 전환됨

저자는 다른 사람들이 이 문제를 어떻게 처리하고 있는지 묻습니다: 기록에서 상태를 재구성하는지, 벡터 검색을 사용하는지, 명시적 구조화된 상태를 저장하는지, 아니면 다른 방법을 사용하는지?