에이전트가 작업을 성공했을 때, 다음에도 할 수 있을까요?

무대 위에서는 당황스럽습니다. 실제 운영 환경에서는 신뢰성 문제입니다. 한 번은 성공했지만 사용자가 동일한 요청을 했을 때 다음에는 실패할 수 있는 워크플로우 말입니다. 금융 거래를 조정하거나 계약서에서 의무 사항을 확인하는 것과 같은 미션 크리티컬 작업의 경우, 이는 치명적인 결함이 될 수 있습니다.

대부분의 벤치마크는 이 변동성을 평균값 뒤에 숨깁니다. AppWorld에서 GPT-4.1을 사용한 ReAct 에이전트는 다섯 번 반복된 테스트 전반에 걸쳐 77.4%의 실행 성공률을 보였습니다. 하지만 단지 53.0%의 작업에서만 다섯 번 모두 성공했을 뿐이며, 이는 24.4% 포인트의 일관성 격차를 보여줍니다.

대부분의 벤치마크는 첫 번째 숫자만을 보고합니다. 우리는 두 번째 숫자를 측정하고 개선하는 방법을 만들었습니다.

이전 게시물에서 저희는 ALTK-Evolve를 소개했습니다. 이는 에이전트 자신의 과거 실행 경로(trajectories)를 재사용 가능한 가이드라인으로 변환하여, 자동으로 증류한 다음 추론 시점에 다시 주입하는 시스템입니다. 이는 작업 성공률을 측정 가능하게 개선하지만, 그 결과들 역시 평균적인 경우의 질문만 던졌습니다. 이번 게시물에서는 이 격차를 직접적으로 겨냥하는 새로운 가이드라인 유형인 **일관성 가이드라인(consistency guidelines)**을 소개합니다.

이는 저희가 **일관성 분석기(Consistency Analyzer)**라고 부르는 진단 도구를 기반으로 구축되었으며, altk-evolve의 새로운 기능입니다.

요약 (TL;DR)

정확도(Accuracy)는 신뢰성 문제를 숨깁니다. ReAct 에이전트 (AppWorld에서 GPT-4.1 사용 시 test_normal)

평균적으로 77.4%의 성공률을 보이는 에이전트가 실제로 반복 실행되는 모든 5회(all 5 repeated runs)에서 성공하는 작업은 단지 53.0%에 불과하며, 이는 24.4%p의 일관성 격차를 보여줍니다. 어려운 작업에서는 이 수치가 30%p까지 벌어집니다. 이러한 문제를 정확히 진단하기 위해 저희가 도구를 만들었습니다. Consistency Analyzer는 에이전트가 자체 기록한 트랙토리(trajectory)를 재샘플링하여 실패하기 쉬운 의사결정 지점(flip-prone decision points)을 찾아냅니다. 즉, 모델이 다른 것을 수행할 수 있는 단 하나의 토큰 샘플 거리에 있었던 단계들입니다. 이 도구는 실제 작업 전체를 다시 실행할 필요 없이, 트랙토리의 각 의사결정 지점에서 k개의 완성본(k=5가 기본값)을 요청하는 단일 호출만으로 재샘플링됩니다.이러한 진단 결과를 가이드라인으로 만들면 격차를 절반으로 줄일 수 있습니다. 24.4%p에서 12.0%p로 (동일 작업의 Pass⁵는 +16.0%p, 유사 작업은 +13.0%p) 감소하며, 평균 정확도에 비용을 지불하지 않습니다.전체 방법론 및 평가는 arXiv의 기술 보고서에 있습니다.

표준 에이전트 평가 보고서에서 Mean@k: 벤치마크를 k번 실행하여 성공률을 평균 냅니다. 보통 k=3이며, 때로는 단지 1회만 합니다. 이는 모든 리더보드에 있는 수치이며, 실질적으로

이는 더 큰 모델로 고칠 수 있는 역량 문제가 아닙니다. 이는 직교축(orthogonal axis) 문제입니다. 즉, 에이전트는 유능하면서도 일관적이지 않을 수 있습니다.

LLM 에이전트가 무언가를 결정할 때마다 — 어떤 API를 호출할지, 어떤 인수를 전달할지, 재시도할지 여부 등 — 그 결정은 다음 토큰에 대한 확률 분포에서 나옵니다. 중요한 것은 그 분포의 **모양(shape)**입니다. 날카로운(sharp) 분포는 대부분의 질량(mass)을 단일 토큰에 집중시킵니다: 2등 후보들은 멀리 뒤처지고, 같은 선택이 반복해서 나옵니다. 반면, 평탄한(flat) 분포는 여러 근접하게 동률인 토큰들에 걸쳐 비교 가능한 질량을 분산시키며, 어떤 것이 승리할지는 거의 동전 던지기와 같습니다.

그 모양은 결과를 바꾸는 데 필요한 노이즈의 양을 결정합니다. 날카로운 분포는 탄력적입니다 — GPU 부동소수점 비결합성(non-associativity), 요청 배치 처리(request batching) 및 기타 플랫폼 측 효과가 숫자를 약간 밀어낼 수는 있지만, 명확한 승자를 순위를 바꾸기에는 턱없이 부족합니다. 평탄한 분포는 바로 그러한 작은 교란에 취약합니다: 근접 동률은 작은 변화에도 순서가 바뀔 수 있습니다. 그리고 궤적(trajectory)이 수십 번의 결정을 연결하기 때문에, 단계별로 발생하는 작은 플립(flipping) 가능성은 큰 확률로 어떤 실행이 다르게 될 수 있다는 것으로 증폭됩니다. 이것이 바로 24점 차이가 발생하는 이유입니다.

이는 또한 디코딩 설정에도 불구하고 문제가 지속되는 이유이기도 합니다. Greedy decoding과 고정된 시드(fixed seed)는 모두 분포가 토큰으로 변환되는 방식을 통제할 뿐이며, 분포 자체에 대해서는 아무것도 말해주지 않습니다. 호스팅 엔드포인트에서는 확률이 실행마다 약간씩 변화하기 때문에, 온도 0인 동일한 모델에 같은 프롬프트를 사용하더라도 오늘 근접 동률은 한 방식으로 해결될 수 있고 내일은 다른 방식으로 해결될 수도 있습니다.

저희의 설정: ReAct 에이전트는 온도 0.0으로 실행되므로, 위의 변동성은 일반적인 샘플링(ordinary sampling)이 아닙니다.

이는 문제를 검색 문제로 바꿉니다: 주어진 궤적에서 어떤 단계들이 평탄한 단계였는지 — 그리고 그것을 알게 되었을 때 무엇을 해야 하는가?</content>```jsoncsharpthinker_thought_process}<tool_call|>The user wants me to act as a Korean AI/tech blog translator. I need to translate the provided English text chunk while adhering strictly to several rules: 100% information preservation, retaining professional terminology with English acronyms/terms in parentheses (e.g.,

일관성 가이드라인은 ALTK-Evolve의 기존 시스템에 연결되는 2단계 파이프라인에서 나옵니다. 새로운 소스 신호가 무엇을 작성할지 주도합니다.

1. 감지(Detect) — 일관성 분석기(Consistency Analyzer).
하나의 기록된 궤적(trajectory)이 주어지면, 이 분석기는 제어된 재샘플링을 통해 각 결정 단계(decision step)를 다시 재생하고, 그 지점에서 모델의 출력이 실제로 얼마나 변하는지를 측정합니다. 구체적으로는, 오프라인에서 한 번 수행되는 결정 단계당 추가적인 모델 호출이 발생하며 — 샘플링 매개변수(sampling parameter)가 한 번에 k개의 완료본을 추출하도록 설정됩니다 (기본값 k=5) — 이미 기록된 컨텍스트를 대상으로 다시 재생되며, 새로운 도구 호출이나 새로운 환경 상호작용, 또는 작업의 두 번째 종단 간 롤아웃(end-to-end rollout)은 아닙니다. 이를 통해 결정 단계별 일관성 점수(consistency score)가 산출되어 스코어카드에 기록되고, 어떤 결정이 다음 실행에서 뒤집힐 위험이 있는지 정확히 지적합니다. 감지는 완전히 블랙박스입니다 — 로짓(logits), 모델 내부 구조, 이미 가지고 있는 추적(trace) 이상의 계측은 없습니다.

2. 생성(Generate) — 목표 가이드라인. 모든 플래그가 지정된 단계는 표준 ALTK-Evolve 형식의 후보 일관성 가이드라인이 되며, 기존 저장 및 검색 파이프라인에 삽입됩니다. 여기 GPT-4.1이 AppWorld 작업

여기에는 작업 특화된 지식(trivia)은 없습니다. 문자열 개수 오류나 검증되지 않은 검색 결과는 여러 AppWorld 작업에서 높은 불확실성으로 나타나는 의사 결정 지점입니다. 바로 이 점이 핵심입니다. 즉, 분석기(analyzer)는 실패가 아닌 불안정성을 목표로 삼기 때문에, 에이전트가 이번에 우연히 맞혔지만 다음에는 쉽게 틀릴 수 있는 단계까지 포착합니다.

2분짜리 데모를 시청해 보세요. 이 작업에서 에이전트는 카운팅 전략에 대해 불확실성을 보여 여러 번 실행되었고, 이후 이러한 가이드라인을 컨텍스트로 적용하여 다시 실행했을 때는 다섯 번 모두 일치했습니다.

저희는 AppWorld의 test_normal (168개 작업)에서 GPT-4.1 기반 ReAct 에이전트를 사용하여 각 작업당 단일 기준 궤적(baseline trajectory)으로부터 일관성 가이드라인을 생성하고, 이를 5번의 새로운 실행에 테스트했습니다.

평균@5(Mean@5)(%), 집계치 — 위 Pass^5와 동일한 척도입니다.

일관성 격차(consistency gap)가 약 절반으로 줄었습니다. 집계 Pass^5는 53.0%에서 69.0%로 상승했고, Mean@5는 77.4%에서 81.0%로 상승하여, '가능해 보이는' 수준과 '믿을 수 있는' 수준 사이의 격차를 24.4pp에서 12.0pp로 좁혔습니다. 이전에 일관성이 부족했던 작업 중 거의 3분의 1이 에이전트가 모든 실행에서 통과하는 작업이 되었습니다.

중급(Medium) 및 고급(Hard) 티어의 개선 폭이 가장 큽니다. Medium은 +22.9pp (+44% 상대적), Hard는 +14.3pp (+45% 상대적)로 — 상대적인 측면에서는 사실상 동등하며, 절대적인 수치로는 Medium이 앞섰습니다. 쉬움(Easy)은 개선 폭이 +12.2pp로 가장 적었습니다. 이는 일관성 가이드라인이 설계된 대로 작동하여, 에이전트 자체의 불확실성이 결과에 누출되던 특정 의사 결정 지점을 찾아내고 안정화했음을 보여줍니다.

Mean@5는 절대 떨어지지 않습니다. 평균 정확도를 유지하는 것은 선택 사항이 아니라 필수 요구사항이었습니다. Pass^5를 높이기 위해 Mean@5를 희생시키는 시스템은 신뢰성을 재배치할 뿐, 근본적으로 해결하지 못합니다. 모든 난이도 수준에서 Mean 정확도는 유지되거나 향상됩니다.

이와 다르지만 관련된 AppWorld 시나리오의 다른 작업에 적용했을 때도 일관성 가이드라인(consistency guidelines)은 여전히 Pass^5를 +13.0pp 높여주는데, 이는 동일한 작업을 수행했을 때의 수치보다 단지 3포인트 낮은 수준입니다. 한 번의 실행에서 파생된 가이드라인은 단순히 그 실행을 패치하는 것이 아니라, 전이될 수 있는 무언가를 포착하고 있습니다.

더 명확한 증거는 더 약한 모델인 gpt-oss-120b에서 나옵니다. 동일 작업 Pass^5는 훨씬 낮은 기준선(10.1% → 16.1%)에서 +6.0pp 상승했습니다. 흥미롭게도, 유사 작업 일반화 수치(+8.7 pp)가 실제로는 동일 작업 증가분보다 높았는데, 이는 가이드라인이 특정 궤적의 세부 사항을 암기하기보다는 진정으로 재사용 가능한 실패 패턴을 포착했음을 시사합니다.

Mean@k 옆에 Report Pass^k를 기록하세요. 평균값만으로는 신뢰할 수 있는 에이전트와 운 좋은 에이전트를 구별할 수 없습니다. k=3조차도 여러분이 가지고 있다는 것을 몰랐던 격차를 드러낼 것입니다.난이도가 높아질수록 이 격차가 벌어질 것으로 예상하십시오. 가장 어려운 단계가 단일 평균 숫자가 가장 오해하기 쉬운 지점입니다.먼저 더 큰 모델을 찾지 마십시오. 일관성은 역량(capability)과 직교합니다. 더 강력한 모델은 Mean@k를 높이지만, 반드시 일관성 격차를 줄이는 것은 아닙니다.진단에는 채점자나 실시간 리플레이가 필요하지 않습니다. 결정 단계마다 추가 LLM 호출(기본적으로 k=5 완료 샘플링)만으로 충분합니다. 정답 데이터(ground truth)도 없고 환경에 대해 작업을 재실행할 필요도 없습니다. 이것이 바로 여러분이 종종 한 번이라도 작업 전체를 끝까지 재실행할 수 없는 프로덕션 트래픽에서 사용 가능하게 만드는 요소입니다.

ALTK-Evolve를 시도해 보세요. 이 오픈 소스 저장소에는 현재 이러한 실험에 사용된 일관성 분석기(Consistency Analyzer)와 일관성 가이드라인 생성 기능이 포함되어 있습니다. 또는 전체 방법론에 대한 기술 보고서를 arXiv에서 읽어보세요.

만약 여러분의 자체 작업에서는 재현할 수 없는 정확도 수치가 익숙하게 들린다면, 저희에게 알려주시길 바랍니다. 여러분 자신의 에이전트에서 플립(flip)-취약 행동의 구체적인 예시는 우리가 다음에 구축하는 것을 형성하는 바로 그 종류의 피드백입니다. 이슈나 토론을 열어주세요.

Mean@k. 작업을 k번 수행하고 평균 성공률을 보고하는 지표로, 대부분의 벤치마크에서