AI가 또 틀렸다. 이번에는 답변보다 도구를 보자

AI가 엉뚱한 답을 내놓았다. 모델을 바꾸면 해결될까. Confident AI는 10월 9일 업데이트에서 조금 다른 곳을 보게 하는 기능을 내놨다. 어떤 도구가 자주 실패하고, 어떤 에이전트가 도구를 잘못 고르는지 묶어 보는 Tool Failure Analytics다.

에이전트는 문장만 만드는 데서 끝나지 않는다. 필요한 정보를 찾거나 외부 기능을 호출한 뒤 결과를 받아 다음 일을 한다. 그러니 마지막 답변이 틀렸다고 해서 문제의 시작도 마지막 문장이라고 볼 수는 없다. 이번 기능은 그 앞의 선택과 호출을 들여다본다.

회사가 제시한 관찰 항목은 실패가 잦은 도구, 자주 들어가는 인자, 잘못된 도구를 고르는 에이전트다. 인자는 도구에 넘겨주는 검색어와 조건 같은 입력이다. 도구 자체의 문제와 도구를 부르는 방식의 문제를 나눠 살필 재료를 제공한다는 설명이다.

SOCRA의 가상 예로, 고객 정보를 찾을 때 주문 조회 도구를 계속 부르는 상황을 생각해 보자. 주문 조회 기능이 멀쩡해도 필요한 답은 나오지 않을 수 있다. 이때 고쳐야 할 곳은 도구의 성능보다 어떤 도구를 선택할지 정하는 흐름일 가능성이 있다.

다만 오류가 많이 나온 도구가 반드시 가장 나쁜 도구는 아니다. 많이 쓰였기 때문에 실패 건수도 많을 수 있다. 호출 수와 실패 수, 어떤 조건에서 문제가 났는지를 함께 봐야 한다는 것이 SOCRA의 해석이다. 새 기능의 이름만으로 원인이 확정되지는 않는다.

같은 업데이트의 Span Trees는 전체 실행에서 한 구간의 가지를 따로 볼 수 있게 한다. 여러 에이전트가 일을 나눠 하는 경우에도 특정 하위 에이전트의 흐름에 집중할 수 있다는 설명이다. 긴 기록에서 문제와 가까운 구간으로 범위를 좁히는 방식이다.

사람이 평가하는 과정에도 변경이 있다. 자동 평가와 검토자의 판단이 얼마나 맞는지 보는 그래프에 검증 데이터를 더했고, 테스트 사례를 주석 대기열에 넣을 수 있게 했다. 운영 기록을 보는 자리와 시험 결과를 읽는 자리의 연결을 강화한 셈이다.

이 기능들이 실제 서비스의 오류를 얼마나 줄였는지는 이번 변경 기록만으로 알 수 없다. SOCRA도 제품을 실행해 개선율을 측정하지 않았다. 도구별 기록이 보이는 것과 팀이 그 기록을 바탕으로 원인을 고쳐 사용자의 문제를 해결하는 것은 별도의 단계다.

AI 제품을 기획하는 사람에게는 실패를 묻는 방식이 달라질 수 있다. 답변이 마음에 들지 않는다는 반응을 모은 뒤, 정보가 없었는지 도구를 잘못 골랐는지 입력 조건이 틀렸는지를 따라가는 것이다. 모델 교체 전에 살펴볼 질문이 더 구체적으로 생긴다.

이번 소식의 중심은 더 그럴듯한 답변이 아니다. 틀린 답에 이르기까지 어디서 일이 어긋났는지 보는 화면이다. AI가 일을 여러 단계로 처리할수록 제품의 경쟁력에는 잘 말하는 능력과 함께, 실패를 설명하고 고칠 수 있는 구조도 들어온다.