도구 호출 평가: 인수, 권한 부여 및 부작용

최근 도구 사용 작업은 정책을 텍스트와 분리합니다.

2026년 7월 시험판인 NetInjectBench는 신뢰할 수 있는 정책 메타데이터에서 신뢰할 수 없는 운영 아티팩트를 분리합니다. 실험에서는 명시된 가정 하에서 프롬프트 수준 접근 방식과 실행 시간 제어를 비교합니다. 이는 신중한 프롬프트가 부적절한 행동을 방지한다고 가정하기보다는 도구 경계 자체를 평가하도록 동기를 부여합니다.

증거: NetInjectBench: 네트워크 운영을 위한 대규모 언어 모델 에이전트를 사용하는 도구의 간접 프롬프트 삽입 벤치마킹 [1]

4개의 정확성 레이어 정의

도구 선택은 작업이 작업과 일치하는지 묻습니다. 인수 정확성은 식별자, 단위, 날짜 및 필수 필드가 올바른지 여부를 묻습니다. 승인은 요청된 작업이 이 사용자 및 컨텍스트에 허용되는지 여부를 묻습니다. 결과 정확성은 실제로 무엇이 바뀌었는지 묻습니다. 한 레이어의 패스가 다음 레이어의 패스를 의미하지는 않습니다.

기계적 요구 사항에 대한 정확한 유효성 검사기와 제한된 작업에 대한 독립적인 정책 검사를 만듭니다. 모호한 엔터티 해결의 경우 에이전트가 명확히 해야 하는 시기를 정의하세요. 그럴듯한 고객 이름은 동일한 이름을 가진 두 레코드 중에서 선택할 수 있는 충분한 증거가 아닙니다.

경계 주변의 빌드 케이스

Rubrex는 유효한 작업, 인수 누락, 잘못된 도구 응답, 모호한 식별자, 시간 초과, 중복 요청 및 권한 거부에 대한 사례를 권장합니다. 에이전트가 정보와 지침을 구별할 수 있도록 명령을 인용하는 양성 문서를 포함합니다. 도구가 변경 사항을 적용할 수 있는 경우 테스트 데이터와 격리 상태를 사용하세요.

거부된 통화가 애플리케이션에 의해 올바르게 차단되었는지, 상담원이 회피했는지, 아니면 단순히 시도하지 않았는지 기록합니다. 이것은 다른 관찰입니다. 강력한 권한 계층은 에이전트가 요청 계획을 개선해야 하는 동안에도 시스템을 보호할 수 있습니다.

예시: 두 고객이 같은 이름을 공유합니다.

영업 보조원이 Northstar라는 계정을 업데이트하라는 요청을 받았습니다. 두 개의 계정이 일치합니다. API는 두 식별자 중 하나를 허용하므로 스키마 유효성 검사만으로는 정확성을 확인할 수 없습니다. 예상되는 동작은 사용 가능한 명확성 컨텍스트를 사용하거나 변형 전에 설명을 요청하는 것입니다.

요청에 고유 계정 식별자가 포함된 컨트롤을 추가합니다. 에이전트는 불필요한 중단 없이 해당 작업을 완료해야 합니다. 이 쌍으로 구성된 설계는 모든 작업에 대해 확인을 요청하는 시스템과 유용한 주의 사항을 구별하는 데 도움이 됩니다.

통합 복구 계약 평가

각 작업에 대해 재시도가 안전한지, 멱등성 키가 지원되는지, 현재 상태를 확인할 수 있는 방법을 문서화하세요. 확실한 실패와 불확실한 결과를 모두 테스트하세요. 적절한 레이어에 결함을 할당합니다. 누락된 애플리케이션 가드레일은 모델 프롬프트 문제로 위장되어서는 안 됩니다.

일반적인 질문