에이전트 도구 호출을 위한 제한된 재시도
우리 에이전트가 일으킨 최악의 사고는 잘못된 답변이 아니었습니다. 바로 루프였습니다.
도구 호출(tool call)이 실패했습니다. 에이전트는 재시도했습니다. 재시도도 실패했습니다. 에이전트는 계속해서 시도했습니다. 그 결과 토큰을 소모하며 1분 만에 우리 API를 수백 번 호출했습니다.
에이전트는 우리가 시킨 대로 했습니다. 우리는 도구 호출이 실패하면 재시도하라고 명령했습니다. 하지만 언제 멈춰야 하는지는 말해주지 않았습니다.
재시도는 일시적인 오류에는 유용합니다. 문제는 에이전트가 일시적인 오류와 영구적인 오류를 구분하지 못한다는 점입니다. 제한이 없다면, 에이전트는 무언가가 중단시키기 전까지 실패한 호출을 계속해서 재시도합니다.
전통적인 코드에서는 재시도 횟수 제한을 사용합니다. 에이전트 도구 호출은 이 결정을 모델의 추론 과정으로 옮겨버렸습니다. 이로 인해 루프는 눈에 보이지 않게 되었고, 제한도 없어졌습니다.
우리는 모델 외부에서 두 가지 예산(budget)을 추가하여 이 문제를 해결했습니다.
• 호출당 상한선(Per-call cap): 특정 도구에 정해진 횟수의 시도 기회를 부여합니다. 실패할 경우, 에이전트는 다른 경로를 시도해야 합니다. • 세션당 예산(Per-session budget): 전체 작업에 대해 총 도구 호출 횟수를 제한합니다. 에이전트가 이 제한에 도달하면, 작업을 멈추고 도움을 요청합니다.
제한 그 자체가 해결책은 아닙니다. 중요한 것은 제한에 도달한 후에 어떤 일이 일어나느냐입니다.
단순히 멈추기만 하면 에이전트는 교착 상태에 빠집니다. 대신, 우리는 에이전트에게 명확한 메시지를 전달합니다. 호출이 실패했으며 더 이상 재시도해서는 안 된다고 알려주는 것입니다. 이렇게 하면 루프가 하나의 '결정'으로 바뀝니다. 그러면 보통 에이전트는 새로운 접근 방식을 선택합니다.
이 기능을 추가한 이후, 도구 오용으로 인한 루프는 거의 사라졌습니다. 루프가 발생하더라도 막대한 API 비용을 발생시키는 대신, 깔끔하게 에스컬레이션됩니다.
적절한 제한 값을 찾는 것은 어렵습니다. 제한이 너무 엄격하면 긴 작업이 중단되고, 너무 느슨하면 비용이 많이 드는 루프가 발생합니다. 우리는 작업 길이의 95백분위수(95th percentile)를 기준으로 제한을 설정합니다.
이 예산을 설정하는 더 좋은 방법이 있나요? 댓글로 알려주세요.
선택 사항 학습 커뮤니티: https://t.me/GyaanSetuAi