에이전트가 잘못된 도구를 호출할 때, 배포 가능한 신뢰성 있는 함수 호출

출처: Dev.to

첫 번째로 실제 도구 앞에 에이전트를 배치했을 때, ‘고객의 마지막 주문을 환불하라’는 요청에 대해 it 은 cancel_subscription을 호출했고, issue_refund 대신요. 두 도구 모두 존재했으며, 둘 다 불만스러운 고객과 관련이 있을 수 있었습니다. 모델은 잘못된 도구를 선택하고 완전하게 신뢰하면서 실행했습니다.

이것은 데모에서 생략되는 에이전트 엔지니어링의 부분입니다. 모델이 텍스트를 생성하는 것은 쉽지만, 시스템 내에서 행동을 취하게 하는 — 함수 호출, API 호출, 상태 변경 — 는 신뢰성이 존재하거나 존재하지 여부가 있는 단계입니다.

다음은 프로덕션에 넣을 만큼 신뢰할 수 있게 함수 호출을 만드는 방법입니다.

에이전트에게 제공되는 도구가 많아질수록 잘못 선택할 가능성도 커집니다. 단일 에이전트가 20개 이상의 도구를 가지고 있을 때 정확도가 급격히 하락하는 것을 우리는 목격했습니다.

두 가지 해결책: 도구 집합을 작고 명확하게 유지하고, 각 도구를 혼동이 어렵도록 정확히 이름 붙이고 설명합니다.

refund_order에 ‘완료된 주문에 금전적 환불을 이슈합니다; 구독을 취소하지 않습니다’라는 설명이 있을 때, 매번 흐릿한 handle_order보다 우수합니다.

설명은 문서가 아니라 모델이 실제로 결정을 내릴 때 읽는 지시문입니다.

에이전트가 올바른 도구를 선택하더라도, 환불 금액이 주문보다 클 수 있음, 날짜 형식이 잘못됨, 존재하지 않는 고객 ID, 음의 수량과 같은 허무한 데이터를 전달할 수 있습니다.

모델은 검증된 것이 아니라 합리적으로 보이는 주장을 생성합니다. 따라서 모든 노출된 도구는 서버 측에서 아무 작업도 하기 전에 입력을 엄격히 검증합니다 — 타입 체크, 범위 체크, 존재 체크, 비즈니스 규칙 체크.

잘못된 호출은 데이터를 손상시키지 않고 에이전트가 읽고 수정할 수 있는 명확한 오류를 반환합니다.

에이전트에서 제공받은 인수는 인터넷 상의 익명의 사용자 입력과 동일하게 취급해야 합니다: 절대 신뢰하지 마세요.

데이터를 읽는 것은 위험도가 낮고, 데이터를 변경하는 것은 그렇지 않습니다. 우리는 도구를 이 두 클래스로 구분하고 매우 다르게 대합니다.

읽기 전용 도구는 에이전트가 자유롭게 호출할 수 있습니다.

쓰기 전용 도구(예: 금액 이동, 메시지 전송, 레코드 삭제, 주문 변경)와 같이 상태를 바꾸는 작업은 추가적인 검증 게이트를 거칩니다. 여기에는 더 엄격한 입력 검증, 레이트 제한, 그리고 가장 중요한 행동에 대해서는 인간 승인 절차가 포함됩니다.

에이전트는 작업을 준비하고, 사람이 이를 확인합니다.

특정 워크플로우에 대한 신뢰가 쌓이면 게이트를 완화할 수 있습니다. 초기에는 그렇지 않습니다.

에이전트는 재시도합니다. 도구 호출이 타임아웃되면 에이전트는 실패한 것으로 가정하고 다시 호출하지만, 첫 번째 호출은 실제로 성공했습니다. 이제 두 번 환불되었습니다.

상태 변경 도구마다 결정적 식별자인 서버가 확인하는 idempotency key를 두어, 반복 호출 시 다시 실행되지 않고 원래 결과를 반환하도록 합니다.

가능한 한 가역적인 작업을 선호합니다. 예를 들어, 인간이 해제할 수 있는 ‘초안’ 또는 ‘보류’ 상태와 같은 작업을 선택하고, 즉시 에이전트가 커밋하는 비가역적 작업보다는 그러는 것이 좋습니다.

도구가 실패할 때 반환되는 내용이 매우 중요합니다.

일반적인 ‘오류’를 반환하면 에이전트는 당황해 무작정 재시도하거나 사용자에게 가짜 성공 메시지를 전송합니다.

구체적이고 읽기 쉬운 메시지를 반환하세요 — 예: ‘환불 실패: 주문 4471은 이미 완전히 환불되었습니다’ — 그러면 숙련된 모델은 이를 정확히 이해하고, 사용자에게 설명하거나 대안 경로를 선택할 수 있습니다.

도구 오류 메시지를 설계의 1급 요소로 취급합니다. 이는 다음에 할 일을 결정해야 하는 독자를 위해 작성됩니다.

생산 환경에서 에이전트가 수행한 놀라운 행동은 도구가 어떤 순서로, 어떤 인수와 함께 호출됐는지, 그리고 어떤 결과를 반환했는지를 확인하는 것이 유일한 방법입니다.

우리는 모든 도구 호출을 구조화된 레코드로 로깅합니다. 이것은 선택 사항이 아니라, ‘1시간 안에 해결했다’와 ‘무슨 일이 일어났는지 알 수 없다’의 차이입니다. 또한 이는 배포 전 다음 회귀를 포착할 평가 집합을 구축하는 데 도움을 줍니다.

대부분의 팀은 에이전트가 올바른 말을 하는지 테스트합니다. 훨씬 적은 팀이 그것이 실제로 올바른 행동을 하는지 검증합니다.

우리는 ‘고객이 이미 환불된 주문에 대한 환불을 요청함’, ‘사용자가 취소하라고 요구하지만 실제로는 일시 중지를 의미함’과 같은 시나리오 모음을 구축하고, 에이전트가 생성하는 실제 도구 호출에 대해 단언합니다. 이는 말이 아닌 행동을 검증하는 것입니다.

실제 버그는 여기 숨어 있으며, 행동 취하는 에이전트를 안심하고 배포하려면 이것이 유일합니다.

챗봇에서 에이전트로의 전환은 단어 생성에서 행동을 취하는 전환이며, 행동에는 결과가 따릅니다.

신뢰할 수 있는 함수 호출은 한 가지 기술이 아니라 작은 학문의 스택입니다: 제한된 도구 집합, 강력한 검증, 게이트된 쓰기, idempotency, 정직한 오류, 그리고 행동을 검증하는 테스트.

그들을 적용하면 에이전트가 진정으로 유용해집니다. 그들을 건너뛰면 생산 시스템에 예측 불가능한 손을 얹은 것이 됩니다.

Shanti Infosoft에 관하여: Shanti Infosoft는 CMMI Level 5 AI 개발 회사로, 16개 이상의 산업에서 700건 이상의 프로젝트를 성공적으로 완료했습니다. 우리는 팀이 AI 아이디어를 신뢰할 수 있는 프로덕션 급 소프트웨어로 전환하도록 돕습니다 - shantiinfosoft.com | AI 개발 서비스.

에이전트가 충분히 자주 잘못된 도구를 호출해 당신을 불안하게 만든다면, 우리는 그 함수 호출 레이어를 강화하여 배포할 만큼 신뢰성을 확보할 수 있습니다. 우리 팀에 연락하세요.

관련 읽기: AI는 코드를 4배 씩 작성합니다. 여기서 4배 버그를 막는 QA 레이어가 있습니다

Rishabh Jain은 Shanti Infosoft의 디렉터로, 팀은 실제 비즈니스 운영을 위한 AI 에이전트와 자동화를 구축합니다.