IBM 에이전트 일관성 테스트가 드러낸 한 번의 성공만으로는 충분하지 않은 이유

IBM의 에이전트 일관성 테스트는 벤치마크 성공과 신뢰할 수 있는 동작 사이의 뚜렷한 충돌을 드러냈다. GPT-4.1 에이전트는 AppWorld 실행의 77.4%를 완료했지만, 다섯 번의 시도를 모두 통과한 작업은 53.0%에 그쳤다.

이 24.4포인트의 격차는 성공적인 에이전트 시연이 의미하는 바를 바꾼다. 한 번의 올바른 실행은 에이전트가 필요한 역량을 갖췄음을 보여줄 수 있다. 그러나 사용자가 내일, 혹은 5분 뒤에도 같은 결과를 받으리라는 점까지 증명하지는 못한다.

IBM Research는 ALTK-Evolve의 새로운 일관성 가이드라인으로 이 차이를 다루고 있다. 이 시스템은 기록된 에이전트 궤적에서 불안정한 결정을 찾아낸 뒤, 그 약점을 재사용 가능한 지침으로 전환한다. 초기 결과는 신뢰성을 높이기 위해 항상 더 큰 모델이 필요한 것은 아님을 시사한다.

이 연구는 공급업체가 에이전트 성능을 제시하는 일반적인 방식에도 압박을 가한다. 리더보드 평균은 자주 작동하는 에이전트에 보상을 줄 수 있지만, 이전에 성공했던 뒤 얼마나 자주 실패하는지는 감출 수 있다.

IBM 에이전트 일관성 결과가 드러낸 빠진 지표

IBM의 핵심 발견은 평균 정확도와 반복 가능한 성공이 실질적으로 서로 다른 두 제품을 설명한다는 점이다.

연구진은 GPT-4.1로 구동되는 ReAct 에이전트를 AppWorld의 test_normal 분할에 포함된 168개 작업에서 테스트했다. ReAct는 애플리케이션 호출이나 저장된 정보 검색과 같은 행동과 추론 단계를 번갈아 수행하는 에이전트 설계 방식이다.

각 작업은 새로운 실행으로 다섯 번씩 수행됐다. IBM 일관성 연구에 따르면, 기준 에이전트는 Mean@5 점수 77.4%를 기록했다. Mean@5는 다섯 번의 시도에 걸친 성공률의 평균이다.

이 수치는 강력한 제품 시연에 적합해 보인다. 그러나 에이전트의 Pass^5 점수는 53.0%에 불과했다. Pass^5는 다섯 번의 시도가 모두 성공한 경우에만 작업을 성공으로 계산한다.

이 두 결과의 차이가 일관성 격차다. 여기서는 24.4퍼센트포인트에 달했다. IBM은 가장 어려운 작업군에서 이 격차가 30포인트에 이르렀다고 밝혔다.

이 구분이 중요한 이유는 Pass^5가 일부 코딩 평가에서 쓰이는 익숙한 Pass@5 지표가 아니기 때문이다. Pass@5는 다섯 번의 시도 중 적어도 한 번 성공했는지를 묻는다. Pass^5는 모든 시도가 성공했는지를 묻는다.

이 지표들은 서로 다른 제품에 적합하다. Pass@5는 시스템이 여러 후보를 생성하고, 이를 테스트한 뒤, 승자를 선택할 수 있을 때 유용하다. Pass^5는 각 실행이 신뢰할 수 있어야 하는 워크플로에 적합하다.

에이전트에게 가능한 코드 패치 다섯 가지를 요청하는 개발자는 유효한 답변 하나만으로도 혜택을 얻을 수 있다. 반면 거래를 대사해 달라고 요청하는 회계팀은 네 번의 올바른 실행과 한 번의 치명적인 실수를 안전하게 받아들일 수 없다.

같은 문제는 계약 분석에도 적용된다. 한 번의 검토에서는 의무 사항을 식별하지만 다른 검토에서는 이를 놓치는 에이전트는 단지 결과가 들쑥날쑥한 것이 아니다. 동일한 증거로부터 일관되지 않은 비즈니스 결정을 만들어낸다.

IBM의 결과가 GPT-4.1에 이러한 작업을 수행할 능력이 없음을 보여주는 것은 아니다. 평균 77.4%는 그것이 종종 가능하다는 점을 입증한다. 결과는 이 특정 에이전트 구성에서 그 역량이 반복 실행에도 신뢰성 있게 유지되지는 않았음을 보여준다.

이것이 이 글의 핵심적인 전환점이다. 첫 번째 성공은 가능성의 증거일 뿐, 운영상 신뢰성의 증거는 아니다.

더 폭넓은 평가 커뮤니티도 비슷한 결론에 도달했다. Anthropic의 에이전트 평가 가이드는 Pass@k와 Pass^k를 구분하고, 제품의 요구사항에 맞는 지표를 선택할 것을 권고한다.

Anthropic은 간단한 예시를 든다. 시행당 성공률이 75%인 작업은 세 번의 독립적인 시행을 모두 성공할 확률이 약 42%다. 요구사항이 가끔의 성공에서 중단 없는 성공으로 바뀌면서 겉으로 보이는 품질은 떨어진다.

평균값에도 여전히 가치가 있다. 전반적인 역량을 비교하고, 변경 사항이 작업 집합 전반의 결과를 개선하는지 확인하는 데 도움이 된다. 다만 구매자가 이를 신뢰성 보증으로 해석할 때 오해를 불러일으킨다.

엔터프라이즈 배포에서는 두 수치 모두 평가에 포함되어야 한다. Mean@k는 에이전트가 얼마나 자주 작동하는지를 알려준다. Pass^k는 반복 사용에서도 신뢰할 수 있는 작업이 얼마나 남는지를 알려준다.

온도 0에서도 에이전트가 경로를 바꿀 수 있는 이유

프롬프트, 모델, 도구, 디코딩 온도가 변하지 않은 것처럼 보여도 에이전트는 일관성을 잃을 수 있다.

LLM은 확률 분포에서 다음 토큰을 선택한다. 어떤 결정에는 뚜렷하게 선호되는 선택지가 있는 반면, 다른 결정에는 거의 동률인 여러 선택지가 존재한다.

IBM은 이를 뾰족한 결정과 평평한 결정으로 설명한다. 뾰족한 분포에서는 하나의 선택지에 대부분의 확률이 집중된다. 작은 계산상의 변화가 승자를 바꿀 가능성은 낮다.

평평한 분포에서는 여러 그럴듯한 선택지에 확률이 분산된다. 미세한 수치 변화만으로도 어떤 토큰이 먼저 오는지가 달라져 에이전트가 다른 경로로 들어설 수 있다.

이 차이는 도구를 사용하는 시스템에서 중요해진다. 단 하나의 변경된 토큰이 API 선택, 검색 질의, 도구 인수, 재시도 결정 또는 중간 결과의 해석을 바꿀 수 있다.

일반적인 챗봇은 일부 표현 차이를 흡수해도 최종 의미를 바꾸지 않을 수 있다. 그러나 에이전트는 중간 선택에 따라 행동한다. 바뀐 선택 하나하나가 다음 단계에서 이용할 수 있는 정보를 바꾼다.

위험은 긴 궤적 전반에 걸쳐 누적된다. 에이전트가 수십 번의 결정을 내리면, 그중 여러 결정이 불안정한 경계 근처에 놓일 수 있다. 이후의 도구 호출이나 최종 답변이 실패하려면 단 하나만 뒤집혀도 충분하다.

IBM은 ReAct 에이전트를 온도 0.0에서 실행했다. 따라서 연구진은 일반적인 샘플링이 관측된 변동성의 원인이 아니라고 주장한다.

온도 0이 모든 호스팅 모델 실행을 수학적으로 동일하게 만들지는 않는다. 요청 배치 처리, 하드웨어 동작, 부동소수점 연산, 제공업체 측 구현 세부 사항은 확률을 미세하게 바꿀 수 있다.

이러한 변화는 일반적인 텍스트 생성에서는 대개 눈에 띄지 않는다. 하지만 두 선택지가 거의 동률일 때는 중요해진다. 사용자 요청이 바뀌지 않았더라도 작은 변화가 순서를 뒤바꿀 수 있다.

고정 시드에도 한계가 있다. 이는 생성 과정의 일부를 제어하지만, 원격 추론 시스템의 모든 계층을 고정하지는 않는다. 불확실한 결정을 더 단호하게 만들지도 않는다.

이 메커니즘은 성공적인 리허설이 실제 시연 중 실패할 수 있는 이유를 설명한다. 에이전트가 반드시 작업을 잊은 것은 아니다. 동일한 결정 트리의 다른 분기로 들어선 것이다.

완료된 활동을 노트에서 세도록 요청받은 에이전트를 생각해 보자. 한 번의 실행에서는 모든 체크박스 표시를 셀 수 있다. 다른 실행에서는 체크박스 형식을 설명하는 범례까지 세어버릴 수 있다.

두 경로 모두 처음에는 그럴듯해 보일 수 있다. 그러나 의도된 합계를 만들어내는 것은 하나뿐이다. 오류는 노트에 접근하지 못해서가 아니라 문서를 어떻게 해석할지에 관한 미해결 결정에서 발생한다.

더 긴 워크플로는 이러한 행동을 증폭시킨다. 리서치 에이전트는 다른 출처를 선택하거나, 모호한 날짜를 오해하거나, 첫 번째로 일치하는 문서를 찾은 뒤 멈출 수 있다. 각각의 선택이 이후 모든 과정을 형성한다.

이는 AI 에이전트 신뢰성이 부분적으로 오케스트레이션 문제임을 뜻한다. 더 나은 기본 모델은 좋은 결정을 내릴 확률을 높일 수 있지만, 경계선상의 선택이 사라진다고 보장하지는 않는다.

외부 조건은 또 다른 층을 더한다. ReliabilityBench는 반복 실행을 바꿔 쓴 요청과 도구 실패와 함께 평가한다. 해당 프로덕션 스트레스 프레임워크는 일관성, 견고성, 내결함성을 별개의 차원으로 다룬다.

IBM의 현재 실험은 반복 실행을 더 좁게 분리해 살펴본다. 이 초점은 일관성 격차를 쉽게 검토하게 하지만, 에이전트가 마주할 모든 프로덕션 실패를 대변하지는 않는다.

실제 배포 환경에서는 변경된 데이터, 만료된 자격 증명, API 속도 제한, 부분 응답, 진화하는 스키마에 직면한다. 따라서 동일 입력에서의 안정적인 동작은 출발점의 요구사항일 뿐, 신뢰성의 전체 기준은 아니다.

ALTK-Evolve가 불확실성을 표적화된 가이드로 전환하는 방식

ALTK-Evolve는 모든 작업을 실제 환경에서 다시 실행하지 않고도 불안정한 결정을 보완하려 한다.

새 프로세스는 기록된 하나의 궤적으로 시작한다. 궤적은 에이전트 실행 중 생성된 프롬프트, 결정, 도구 호출, 관찰 결과, 응답의 순서화된 기록이다.

IBM의 Consistency Analyzer는 해당 추적에 이미 저장된 맥락을 이용해 각 결정 지점을 다시 검토한다. 여러 대체 완성을 요청하고, 모델의 선택이 얼마나 달라지는지 측정한다.

기본 구성은 결정 단계마다 한 번의 추가 모델 호출을 통해 다섯 개의 완성을 추출한다. 외부 도구 호출을 반복하거나 전체 작업을 다시 실행하지는 않는다.

이 설계는 프로덕션에서 중요하다. 전체 재실행은 이메일을 한 번 더 보내거나, 레코드를 두 번 수정하거나, 구매를 중복 처리하거나, 이미 변경된 데이터를 마주할 수 있다.

오프라인 재샘플링은 이러한 부작용을 피한다. 또한 진단 단계에서 정답 레이블이 필요하지 않도록 한다.

분석기는 블랙박스 방식이므로 모델 로짓이나 내부 접근 권한이 필요 없다. 팀은 원래의 추적을 보유하고 그 결정 맥락을 다시 제출할 수 있다면 호스팅 모델에도 적용할 수 있다.

각 결정에는 일관성 점수가 부여된다. 완성이 서로 달라지는 단계는 추가 가이드의 후보가 된다.

그런 다음 ALTK-Evolve는 이러한 후보를 간결한 행동 지침으로 전환한다. 더 넓은 목적은 이전 궤적에서 유용한 교훈을 추출하고 이후 작업 중 이를 검색하는 것이다.

노트 개수 세기 예시에서 생성된 가이드는 단순한 부분 문자열 개수 대신 줄 단위로 고정된 정규 표현식을 권장했다. 또한 노트를 선택하기 전에 여러 검색 일치 결과를 확인하도록 에이전트에 지시했다.

이 지침들은 일반적인 실패 패턴을 다룬다. 원래 작업의 올바른 수치 답변을 단순히 저장하는 것이 아니다.

이 차이는 필수적이다. 하나의 답을 암기하면 에이전트를 강화하지 않은 채 벤치마크 항목의 성적만 올릴 수 있다. 재사용 가능한 규칙은 새로운 노트, 다른 체크박스 형식 또는 관련된 검색 결정에도 도움이 될 수 있다.

ALTK-Evolve 리포지터리에는 이제 Consistency Analyzer와 가이드라인 생성 구성 요소가 포함돼 있다. 이 프로젝트는 Apache 2.0 라이선스를 사용하며 Model Context Protocol을 통한 통합을 지원한다.

검색 계층은 추론 시점에 관련 가이드라인을 에이전트의 맥락으로 가져온다. 이를 통해 모든 과거 추적을 활성 프롬프트에 남겨두지 않고도 모델에 표적화된 알림을 제공한다.

이 접근 방식은 집중된 형태의 운영 메모리와 닮아 있다. 에이전트에게 자신이 수행한 모든 일을 다시 읽게 하는 대신, 시스템은 반복되는 교훈을 정제하고 현재 작업과 연결된 내용을 검색한다.

이 구분은 지식 업무에서도 중요하다. 더 큰 아카이브가 자동으로 더 나은 결정을 만들어내지는 않는다. 유용한 메모리는 선택, 충돌 처리, 현재 요청에 적합한 맥락을 필요로 한다.

같은 원리는 잘 구조화된 AI 지식 베이스의 토대가 된다. 시스템이 작업 맥락을 넘치게 하지 않으면서 올바른 증거를 검색할 수 있을 때 저장된 자료는 가치를 갖게 된다.

ALTK-Evolve의 방법은 일반적인 지식 플랫폼보다 범위가 좁다. 이는 에이전트 행동을 대상으로 하며 궤적에서 도출된 가이드라인을 사용한다. 그럼에도 두 사례는 같은 제약을 드러낸다. 정보를 보존하는 일은, 적절한 순간에 올바른 정보를 적용하는 일보다 쉽다.

이 메커니즘은 피드백 루프도 만듭니다. 팀은 트레이스를 수집하고, 불안정한 단계를 감지하며, 후보 지침을 생성하고, 해당 지침이 이후 실행을 개선하는지 평가할 수 있습니다.

그러나 이 시스템이 테스트의 필요성을 없애지는 않습니다. 생성된 규칙은 잘못되었거나, 지나치게 광범위하거나, 이를 만든 상황 밖에서는 해로울 수 있습니다.

팀에는 여전히 버전 관리와 롤백이 필요합니다. 특히 에이전트가 규제 대상 업무나 재무적으로 중대한 업무를 수행할 때는 어떤 가이드라인이 결정에 영향을 주었는지도 추적해야 합니다.

신뢰성 향상 폭은 크지만, 근거는 제한적입니다

IBM은 상당한 개선을 보고했지만, 이 연구는 하나의 주요 벤치마크 구성에 대한 초기 평가에 머물러 있습니다.

일관성 가이드라인을 추가한 뒤, 168개 AppWorld 작업에서 Pass^5는 53.0%에서 69.0%로 증가했습니다. 이는 다섯 번의 모든 실행에서 통과한 작업 비율이 16포인트 개선된 것입니다.

Mean@5도 77.4%에서 81.0%로 상승했습니다. 이에 따라 일관성 격차는 24.4포인트에서 12.0포인트로 좁혀졌습니다.

이 결과가 중요한 이유는 평균 성과가 떨어지지 않았기 때문입니다. 에이전트를 일관되게 평범한 전략으로 몰아넣어 재현성만 높이는 방식은 근본 문제를 해결하지 못합니다.

IBM은 가이드라인이 모든 난이도에서 Mean@5를 유지하거나 개선했다고 밝혔습니다. 중간 난이도 그룹의 Pass^5는 22.9포인트 상승했고, 어려운 그룹은 14.3포인트 개선됐습니다.

상대적 향상률은 중간 난이도 작업에서 44%, 어려운 작업에서 45%였습니다. 쉬운 작업은 개선 여지가 더 적었지만 12.2포인트 상승했습니다.

IBM은 같은 AppWorld 시나리오 내에서 서로 다르지만 관련된 작업에도 가이드라인을 시험했습니다. Pass^5는 동일 작업에서 16포인트 오른 것과 비교해 13포인트 증가했습니다.

이 결과는 일부 가이드라인이 하나의 기록된 궤적을 넘어 이전될 수 있다는 주장을 뒷받침합니다. 다만 관련 없는 애플리케이션, 산업 또는 에이전트 아키텍처 전반에 걸친 폭넓은 일반화를 입증하지는 않습니다.

두 번째 실험에는 gpt-oss-120b가 사용됐습니다. 동일 작업의 Pass^5는 10.1%에서 16.1%로 증가했고, 유사 작업 성능은 8.7포인트 향상됐습니다.

더 낮은 기준 성능은 가이드라인이 역량을 완전히 대체할 수 없음을 보여줍니다. 6포인트 개선은 의미가 있지만, 모든 실행에서 성공할 확률이 16.1%에 머문다면 중요한 자동화에 적합하지 않습니다.

전체 technical report에는 이러한 주장에 관한 방법론이 담겨 있습니다. 그럼에도 독자는 이 결과를 운영 시스템 전반에서 독립적으로 확인된 사실이 아니라 저자들의 평가에서 나온 근거로 받아들여야 합니다.

주요 테스트는 하나의 ReAct 구성, 하나의 핵심 벤치마크 분할, 작업당 다섯 번의 반복 실행을 사용합니다. AppWorld는 현실적인 다중 애플리케이션 시나리오를 제공하지만, 벤치마크는 여전히 통제된 환경입니다.

다섯 번의 실행은 한 번의 실행으로는 드러나지 않는 불안정성을 보여줍니다. 하지만 수천 건의 고객 상호작용에서 나타날 수 있는 드문 실패를 정밀하게 추정하지는 못합니다.

이 평가는 통계적 질문도 제기합니다. Pass^k는 추가 시행마다 실패할 기회가 하나 더 생기므로 k가 증가할수록 자연스럽게 낮아집니다.

따라서 제품 팀은 실제 노출 수준에 따라 k를 선택해야 합니다. 다섯 번의 성공적인 실행은 합리적인 개발 단계의 검증일 수 있지만, 엔터프라이즈 규모의 신뢰성을 증명하지는 않습니다.

가이드라인은 시간이 지나며 낡을 수도 있습니다. API는 바뀌고, 정책은 변화하며, 과거의 우회책은 새 시스템 동작과 충돌할 수 있습니다.

한 불안정한 분기에서 도출된 규칙은 다른 곳에서 유효한 대안을 억제할 수 있습니다. 시스템에 축적되는 가이드라인이 많아질수록 충돌 해결과 검색 품질의 중요성도 커집니다.

일관된 행동과 올바른 행동 사이에는 차이가 있습니다. 같은 잘못된 행동을 반복하는 에이전트는 행동 안정성이 완벽해도 작업 가치는 0입니다.

IBM의 실험은 Pass^5와 함께 Mean@5를 보고함으로써 이 문제를 방어합니다. 운영 팀도 같은 지표 조합을 유지하고 결과별 안전 조치를 추가해야 합니다.

민감한 워크플로에서는 일관된 정확성이 목표가 되어야 합니다. 안정성만으로 사실 정확성, 정책 준수, 권한 확인 또는 인간의 검토를 대체해서는 안 됩니다.

더 큰 모델은 이제 시스템 수준의 경쟁자와 맞서게 됩니다

새로운 근거는 신뢰성 문제를 먼저 기반 모델 교체로 해결해야 한다는 가정에 이의를 제기합니다.

모델 업그레이드는 여러 작업을 한꺼번에 개선할 수 있어 여전히 매력적입니다. 에이전트의 메모리나 평가 시스템을 재구축하는 것보다 맞춤형 진단도 덜 필요합니다.

그러나 더 큰 모델이 기존 에이전트가 어디에서 불안정해지는지를 보여주지는 않습니다. 평균 성능을 높일 수는 있어도, 가끔 성공하는 것과 반복적으로 성공하는 것 사이의 의미 있는 격차는 남길 수 있습니다.

IBM의 접근법은 경쟁하는 다른 경로를 제시합니다. 모델을 바꾸는 대신 고위험 의사결정 지점에 제공되는 정보를 바꿉니다.

이 비교는 엄밀히 말해 모델 대 메모리의 구도가 아닙니다. 강력한 시스템은 유능한 모델, 잘 설계된 도구, 목적에 맞는 컨텍스트, 결정론적 검사, 반복 평가를 함께 사용하게 될 것입니다.

압박은 여전히 단일 성공률만 보고하는 에이전트 공급업체와 엔터프라이즈 구매자에게 가해집니다. Pass^k가 조달 논의에 들어오면 높은 평균은 근거의 일부에 불과해집니다.

구매자는 동일 작업을 반복했는지, 환경을 초기화했는지, 모든 실행이 허용 가능한 결과에 도달했는지 물을 수 있습니다. 하나의 집계 수치 대신 난이도별 결과를 요청할 수도 있습니다.

개발자도 관련된 변화를 맞습니다. 에이전트가 한 번 실패했다는 버그 보고는 더 이상 요구 시 재현되지 않을 수 있습니다. 팀은 갈라진 초기 결정을 찾기 위해 완전한 트레이스가 필요합니다.

관측 가능성은 제품 품질의 일부가 됩니다. 저장된 프롬프트, 도구 인수, 결과, 중간 선택이 없으면 불안정한 실행은 이유를 설명하지 못한 채 사라질 수 있습니다.

따라서 배포 전부터 평가 아키텍처가 중요합니다. 팀에는 대표 작업, 통제된 시작 상태, 명시적인 성공 기준, 그리고 분산을 드러낼 충분한 반복 횟수가 필요합니다.

또한 재시도 가능한 작업과 단발성 행동을 구분해야 합니다. 초안 생성은 여러 번의 시도를 허용할 수 있습니다. 결제 전송, 파일 삭제, 계약 승인에는 더 엄격한 통제가 필요합니다.

출력을 자동으로 검증할 수 있을 때 Pass@k는 첫 번째 그룹에 적합합니다. 사용자가 첫 번째 결과부터 안전하리라 기대하는 경우에는 특히 Pass^k가 두 번째 그룹에 더 많은 정보를 제공합니다.

일부 워크플로는 어느 한 지표에만 의존해서는 안 됩니다. 거래 에이전트에는 되돌릴 수 없는 행동을 실행하기 전에 권한 경계, 멱등성 통제, 감사 로그, 결정론적 검증도 필요합니다.

가이드라인은 불확실한 추론을 줄일 수 있지만, 그러한 안전장치를 대체하지는 않습니다. 신뢰할 수 있는 에이전트는 모델 점수가 아니라 시스템의 속성입니다.

이 결과는 큐레이션된 작업 컨텍스트의 필요성도 강화합니다. 팀은 이미 knowledge blending을 사용해 저장된 근거와 진행 중인 작업을 연결합니다. 에이전트 가이드라인도 행동에서 얻은 교훈에 유사한 아이디어를 적용합니다.

핵심은 절제입니다. 더 많은 검색 컨텍스트는 주의를 분산시키고, 모순과 지연 시간을 늘릴 수 있습니다. 목적에 맞는 지침은 올바른 작업에 도달하고 필수 근거를 밀어내지 않을 때만 가치가 있습니다.

바로 이 지점에 ALTK-Evolve의 장기 과제가 있습니다. 그 진단 기능은 가변적인 결정을 식별할 수 있지만, 주변 시스템은 늘어나는 교훈의 집합을 관리해야 합니다.

성공적인 배포에는 만료 정책, 충돌 감지, 출처 추적, 가이드라인 변경에 대한 평가가 필요합니다. 그렇지 않으면 어제의 수정이 내일의 숨은 실패 원인이 될 수 있습니다.

IBM의 접근법이 지속되는지 보여줄 요인

일관성 가이드라인이 표준 에이전트 계층이 될지, 유망한 벤치마크 기법으로 남을지를 결정할 세 가지 신호가 있습니다.

첫 번째 신호는 다른 벤치마크와 에이전트 아키텍처 전반에서의 독립적 재현입니다. 연구자들은 브라우저 에이전트, 코딩 에이전트, 고객 서비스 시스템, 실제 API 실패가 있는 워크플로에서 이 방법을 시험해야 합니다.

16포인트의 Pass^5 개선이 재현된다면 IBM의 핵심 주장은 더욱 강해질 것입니다. 더 작거나 일관되지 않은 개선은 AppWorld에 가이드라인 보정에 특히 잘 맞는 실패 패턴이 존재함을 시사할 수 있습니다.

비교에는 여러 기본 모델이 포함되어야 합니다. 또한 토큰 사용량, 지연 시간, 분석기 비용, 검색 오버헤드, 작업당 주입되는 가이드라인 수를 보고해야 합니다.

두 번째 신호는 더 긴 기간에 걸친 성능입니다. 유용한 학습 시스템은 충돌하거나 낡은 규칙을 축적하지 않으면서 새로운 가이드라인을 처리해야 합니다.

팀은 수백 또는 수천 개의 궤적 이후에도 이점이 유지되는지 측정해야 합니다. 또한 저장소가 커져도 가이드라인 검색이 정확하게 유지되는지 시험해야 합니다.

하나의 가이드라인 세트를 고정하고 이후 애플리케이션 버전에 대해 시험하는 평가를 주목해야 합니다. 강한 성능은 규칙이 지속 가능한 행동을 포착함을 보여줄 것입니다. 빠른 성능 저하는 유지보수 부담을 드러낼 것입니다.

세 번째 신호는 반복 실행 보고의 채택입니다. 공급업체의 평가표는 k를 명확히 밝히고 Mean@k와 Pass^k를 함께 공개해야 합니다.

이 변화는 구매자가 자주 성공하는 모델과 안정적으로 성공하는 시스템을 구분하게 해줄 것입니다. 또한 한 번의 유리한 실행을 중심으로 만든 시연을 억제할 것입니다.

이 분야는 반복과 함께 패러프레이즈 및 통제된 도구 실패도 결합해야 합니다. 동일한 프롬프트는 운영 환경에서 발생하는 압력의 한 종류만 나타냅니다.

IBM의 연구는 한 번의 성공적인 실행이 지나치게 약한 기준이라는 설득력 있는 근거를 제시합니다. 또한 모든 실제 행동을 반복하지 않고도 불확실성을 찾아내는 실용적인 방법을 제공합니다.

남은 질문은 이러한 향상이 연구 환경 밖에서도 지속되는지입니다. 개발자는 자체의 중요한 워크플로를 다시 실행하고, 완전한 트레이스를 보존하며, 모든 실행 성공률을 측정함으로써 답할 수 있습니다.

에이전트가 중요한 업무를 처리한다면, 단지 작업을 완료했는지만 묻지 마십시오. 같은 작업을 얼마나 자주 올바르게 완료하는지, 어떤 결정이 달라지는지, 그리고 어제의 가이드라인이 내일의 조건을 만났을 때 어떤 일이 일어나는지 물어야 합니다.