도구가 부분적인 성공을 반환하면 AI 에이전트가 일찍 중단하는 이유는 무엇인가요?

AI 에이전트는 성공적인 도구 응답을 모든 필수 작업 조건이 완료되었다는 증거로 잘못 판단해 너무 일찍 중단할 수 있습니다.

홈 에이전트는 도구에 파일 10개 복사, 여러 캘린더 일정 업데이트, 문서 일괄 처리, 종속 서비스 재시작 또는 페이지로 나뉜 레코드 검색을 요청할 수 있습니다. 도구는 일부 항목만 완료했거나, 대기열 작업을 수락했거나, 내부 한도에 도달한 뒤에도 유효한 응답을 반환할 수 있습니다. 에이전트가 호출이 오류 없이 반환되었는지만 추적하면 부분적인 진행 상황을 전체 성공으로 바꿔 주장할 수 있습니다. 아래 섹션에서는 전송 성공, 작업 진행 상황, 검증된 완료를 구분합니다.

성공적인 도구 호출은 하나의 로컬 이벤트일 뿐입니다

HTTP 성공 코드, 유효한 JSON 응답 또는 “ok”라는 도구 상태는 호출이 도구의 계약에 따라 수락되었거나 처리되었음을 보여 줍니다. 하지만 이것만으로 사용자의 전체 목표가 달성되었다고 볼 수는 없습니다.

Microsoft Research는 신뢰할 수 있는 에이전트 평가에 결과 검증이 필요하다고 밝혔습니다. 표면적인 성공 신호가 실제 목표 상태와 일치하지 않을 수 있기 때문입니다.

에이전트는 호출 성공, 항목별 진행 상황, 최종 상태, 사용자에게 보이는 승인 여부를 위한 별도의 조건을 갖춰야 합니다.

일괄 처리 및 페이지 처리 도구는 유효한 일부 결과만 반환할 수 있습니다

도구는 첫 번째 페이지만 처리하거나, 검증을 통과한 레코드만 처리하거나, 시간 초과 전에 완료된 항목만 처리할 수 있습니다. 이 경우 응답은 해당 일부 항목에 대해서는 올바를 수 있습니다.

CAR-bench는 불확실성, 부족한 정보, 상호 연결된 도구로 인해 로컬 수준에서 유효한 한 단계 이상이 필요할 때 발생하는 에이전트의 성급한 작업을 드러냅니다.

도구 스키마는 모호한 단일 성공 필드 대신 요청된 개수, 완료된 개수, 실패한 항목, 계속 진행하기 위한 토큰, 대기 중인 작업 ID, 재시도 가능 여부를 반환해야 합니다.

도구가 입력을 조용히 잘라냈거나 의도한 모든 항목을 열거하지 않았다면, 실패 목록이 비어 있다는 것만으로는 충분하지 않습니다.

에이전트는 작업 상태에서 완료되지 않은 의무를 잃을 수 있습니다

긴 프롬프트와 여러 단계로 구성된 계획에는 여러 제약 조건이 포함됩니다. 도구가 긍정적인 응답을 반환하면 모델은 완료된 단계에 집중한 나머지 남은 체크리스트를 유지하지 못할 수 있습니다.

Berkeley Function Calling Leaderboard는 상태를 유지하는 다단계 작업을 평가합니다. 이러한 작업에서는 유효한 호출 하나만으로 모든 필수 의무가 계속 표현되고 완료되었다고 볼 수 없습니다.

내구성 있는 작업 원장은 검증자가 증거가 충족되었다고 표시할 때까지 모든 의무를 열린 상태로 유지해야 합니다. 자연어 메모리만으로는 긴 일괄 작업과 분기형 워크플로를 안정적으로 처리하기 어렵습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

확신에 찬 마무리 문구가 실제 검증을 대신할 수 있습니다

언어 모델은 긍정적인 도구 응답 뒤에 일반적으로 이어지는 “완료했습니다”, “성공적으로 완료되었습니다”와 같은 표현과 간결한 요약 패턴을 학습했습니다.

감사 가능한 조기 중단에 관한 연구는 확신에 찬 마무리 문구가 아니라 검증 가능한 중단 조건을 요구합니다.

최종 응답은 마지막 도구 메시지의 감정적 어조나 표현에서 직접 생성해서는 안 되며, 상태를 검증한 뒤에만 생성해야 합니다.

부분 성공에는 명시적인 다음 상태 계약이 필요합니다

신뢰할 수 있는 도구는 완료, 부분 완료, 대기열 등록, 재시도 가능한 실패, 영구 실패, 알 수 없는 결과를 구분해야 합니다. 각 상태에는 오케스트레이터가 다음에 수행해야 할 작업이 명시되어야 합니다.

장시간 실행되는 에이전트의 엔지니어링에서는 명시적인 진행 상태를 사용해 컨텍스트 변경과 서비스 재시작 이후에도 완료된 작업과 미완료 작업이 유지되도록 합니다.

홈 에이전트의 다음 상태는 다음 페이지를 계속 처리하기, 작업 상태 조회하기, 실패한 항목 재시도하기, 외부 상태 조정하기, 승인을 요청하기, 또는 중단하고 정확히 해결되지 않은 일부 항목을 보고하기일 수 있습니다.

부분 결과는 완전히 검증된 작업과 동일한 최종 상태를 가져서는 안 됩니다.

대상 시스템의 증거를 바탕으로 완료 여부를 결정하세요

“완료했습니다”라고 말하기 전에 파일 개수와 해시, 이벤트 ID, 서비스 상태, 데이터베이스 레코드, 작업 상태 또는 다른 읽기 전용 검증 엔드포인트를 사용해 요청한 결과를 현재 상태와 비교하세요.

정량적 목표 지속성 연구는 검증기 기반 완료를 제안합니다. 이를 통해 측정 가능한 의무가 충족되지 않은 상태에서 에이전트가 종료되는 것을 막을 수 있습니다.

ZimaSpace의 읽기 전용 에이전트 도구 가이드는 파일, 서비스, 장치, 계획을 확인하면서 추가적인 부작용을 일으키지 않는 더욱 안전한 검증 계층을 제공합니다.

대상 시스템이 완료를 입증하지 못한다면 에이전트는 성공적인 최종 답변으로 포장하지 말고, 부분적인 진행 상황을 보고하고 해결되지 않은 항목을 나열하며 재개 가능한 작업 ID를 보존해야 합니다.

자주 묻는 질문

HTTP 200 응답은 완전한 성공을 의미하나요?

아니요. HTTP 200 응답은 프로토콜 수준에서 요청이 어떻게 처리되었는지를 나타냅니다. 요청한 모든 작업이 완료되었는지는 응답 본문과 대상 시스템의 상태를 통해 확인해야 합니다.

에이전트가 부분 결과를 자동으로 재시도해야 하나요?

도구 계약이 실패한 항목을 식별하고, 재시도가 멱등적이거나 안정적인 작업 키로 보호되는 경우에만 재시도해야 합니다.

언어 모델 자체가 완료 여부를 검증할 수 있나요?

언어 모델은 증거를 바탕으로 추론할 수 있지만, 개수, ID, 상태 및 필수 출력에 대해서는 대상 시스템을 대상으로 한 결정론적 검사가 더 신뢰할 수 있습니다.