이번 주에 동일한 에이전트를 동일한 평가 하네스 (eval harness)를 통해 두 번 실행했습니다. 유일한 변수는 네트워크가 데모처럼 동작하느냐, 아니면 실제 운영 (production) 환경처럼 동작하느냐였습니다.

깨끗한 조건, 결함 없음: 50/50 통과. 100%.

동일한 에이전트, 동일한 코드, 단 한 가지 변화: 이제 호출의 22%가 실제 부하 상황에서 모든 LLM 제공업체가 가하는 종류의 속도 제한 (rate limit)에 걸립니다. 36/50 통과. 72%.

이것은 에이전트의 버그가 아닙니다. 애초에 평가 (eval) 단계에서 이를 테스트하지 않았기 때문입니다.

대부분의 평가 하네스 (eval harnesses)는 요청을 드롭하지 않고, 타임아웃 (timeout)이 발생하지 않으며, 잘못된 형식의 응답 (malformed response)을 보내지 않는 제공업체를 대상으로 실행됩니다. 따라서 점수는 실제이지만, 단지 당신의 에이전트가 실제로 실행되지 않을 조건을 측정하고 있을 뿐입니다. 실제 운영 환경에는 제대로 작동하지 않는 재시도 (retries), 연쇄적으로 발생하는 타임아웃 (cascading timeouts), 대화 도중에 발생하는 속도 제한 (rate limits) 등이 존재합니다. 이 중 그 어떤 것도 단 한 번의 깨끗한 통과 과정에서는 나타나지 않습니다.

해결책은 더 높은 평가 점수를 얻는 것이 아닙니다. 실제 운영 환경이 실제로 겪는 실패 모드 (failure modes) 하에서 평가를 실행하고, 그 상황을 견뎌내고 살아남은 수치를 보고하는 것입니다.

정확히 이 작업을 수행하기 위해 thaghr를 구축하고 있습니다: 결함을 주입하고, 테스트를 실행하며, 무엇이 남았는지 보고합니다. 준비되는 대로 더 자세한 내용을 공유하겠습니다.