QA가 AI 평가의 전부가 아닌 이유

AI 에이전트가 내부 보고서를 작성합니다.

보고서는 올바른 형식을 갖추고 있습니다. 수치도 정확하며, 결론 또한 합리적으로 들립니다.

하지만 이 에이전트는 접근할 권한이 없는 출처를 사용했습니다.

그렇다면 통과했을까요?

만약 우리가 최종 보고서만을 확인한다면 '예'라고 말할 수도 있습니다. 하지만 에이전트의 행동을 평가한다면, 같은 실행이라도 실패할 수 있습니다.

제가 팀들에게 이해시키고 싶은 차이점은 바로 이것입니다. 그들이 AI 평가가 왜 필요한지 묻거나, 이를 또 하나의 QA 작업으로 취급하려는 경우에 이 점을 알아야 합니다.

정의된 기대치에 따른 QA 확인

전통적인 소프트웨어에서는 우리가 예상되는 결과가 무엇인지 보통 알고 있습니다.

시스템은 총계를 계산하거나, 이메일의 유효성을 검사하거나, 잘못된 결제를 거부합니다. 요구사항은 우리에게 확인할 결과나 규칙을 제공합니다.

QA는 다음과 같이 질문합니다:

“소프트웨어가 우리가 시킨 대로 작동했는가?”

이는 정의된 기준에 따라 예상되는 동작, 유효하지 않은 입력값, 실패 조건을 테스트합니다.

이러한 확인 과정은 AI 워크플로우에서도 여전히 중요합니다. 검색(Retrieval) 기능은 작동해야 합니다. 도구 호출(Tool calls)은 계약을 준수해야 합니다. 오류는 처리되어야 하며, 필수 필드는 존재해야 합니다.

하지만 이러한 구성 요소들을 확인하는 것만으로는 에이전트가 적절하게 임무를 완수했는지 여부를 완전히 답할 수는 없습니다.

에이전트의 임무를 평가 가능한 무언가로 만들어야 한다

'내부 보고서 작성'이라는 것은 우리가 비교할 수 있는 단 하나의 정확한 답변을 제공하지 않습니다.

여러 개의 보고서가 허용될 수 있습니다. 다른 문구를 사용하거나, 정보를 다르게 구성하거나, 증거가 판단의 여지를 남겨 결론이 달라질 수도 있기 때문입니다.

따라서 질문은 다음과 같이 바뀝니다:

“주어진 상황에서 AI가 올바른 일을 했는가?”

우리가 답하기 전에, '올바르다'는 것이 무엇을 의미하는지 정의해야 합니다.

저희 보고서 에이전트의 경우 다음과 같은 질문들이 필요합니다:

• 보고서는 어떤 정보를 다루어야 하는가?
• 에이전트는 어떤 출처를 사용할 수 있는가?
• 증거가 부족하거나 모순될 때 어떻게 해야 하는가?
• 민감한 정보는 어떻게 처리해야 하는가?
• 언제 멈추고 인간에게 물어봐야 하는가?
• 어떤 결정은 에이전트의 권한 밖에 있는가?
• 무엇을 실패로 간주할 것인가?

이것들은 점수가 어떤 의미를 가지기 전에 해결해야 할 기대치들입니다.

평가 설계는 이러한 기대치를 사례로 만듭니다

기대치가 명확해지면, 우리는 그것들을 압박하는 상황을 설계합니다.

예를 들어, 보고서 에이전트에게 서로 모순되는 두 개의 승인된 출처를 제공할 수 있습니다. 이 사례는 어떤 모순인지, 에이전트가 어떤 정보를 접근할 수 있는지, 그리고 허용 가능한 처리가 어떻게 보이는지를 명시해야 합니다.

갈등을 표시해야 할까요? 명확화를 요청해야 할까요? 명시적인 제한과 함께 계속 진행해야 할까요?

그것은 업무와 결과에 따라 다릅니다. 우리는 실행 결과를 판단하기 전에 그것을 결정해야 합니다.

또 다른 사례에는 불완전한 증거가 포함될 수 있습니다. 또 다른 사례는 관련성이 있지만 승인되지 않은 출처를 발견할 수 있게 만들 수도 있습니다.

각 사례마다 평가 설계는 조건, 예상되는 행동, 금지된 행동, 그리고 결과를 판단하는 데 필요한 증거를 확립합니다.

지침, 컨텍스트(context), 사용 가능한 정보 또는 도구 응답이 변경될 때 행동은 바뀔 수 있습니다. 우리는 그러한 변화들을 검사할 수 있는 사례들이 필요합니다.

성공적인 보고서 하나가 이 모든 것을 다 다루지는 못합니다.

최종 답변은 증거의 일부일 뿐입니다

에이전트는 과정에서 용납할 수 없는 행동을 하면서도 세련된 보고서를 생성할 수 있습니다.

예를 들면 다음과 같습니다:

• 권한 밖의 출처에 접근합니다.
• 중요한 증거가 누락되었다는 사실을 숨깁니다.
• 도구 실패로 인해 결론이 신뢰할 수 없게 되었음에도 계속 진행합니다.
• 인간 승인이 필요한 결정을 내립니다.

일부 실패는 보고서에 나타납니다. 다른 것들은 그것을 생성한 행동과 도구 호출의 증거를 필요로 합니다.

이는 한 번의 실행이 여러 개의 판단을 필요로 할 수 있다는 것을 의미합니다.

에이전트가 작업을 완료했습니까? 비즈니스 제약 조건을 존중했습니까? 민감한 정보를 적절하게 처리했습니까? 권한 내에 머물렀습니까? 도구를 올바르게 사용했습니까?

정확한 답변이 자동으로 이러한 질문들을 해결하지는 못합니다.

채점은 상당한 설계 작업 후에 이루어집니다

사례를 실행한 후, 우리는 관찰된 행동을 정의한 기준과 비교합니다.

일부 검사는 코드를 사용할 수 있습니다. 다른 검사는 루브릭과 인간의 검토가 필요합니다. 자동화된 채점기 역시 자신의 판단이 해당 작업에 적합하다는 증거를 필요로 합니다.

하지만 채점기는 우리가 정의하지 않은 기대치를 해결할 수는 없습니다.

“보고서를 1점에서 5점으로 점수 매기세요”라는 지시는 중요한 작업을 미완으로 남겨둡니다. 정확성? 완전성? 불확실성 처리? 권한 준수?

우리는 이러한 차원들을 확립하고, 평균 점수 속에 사라지는 것이 아니라 눈에 보여야 하는 실패 사례가 무엇인지 결정해야 합니다.

판단은 실행 후에 이루어집니다. 그 판단의 설계는 그 이전에 이루어져야 합니다.

기업이 AI 평가 설계를 필요로 하는 이유

소프트웨어 QA(Quality Assurance)는 여전히 필수적입니다. 그 검사들은 신뢰할 수 있는 에이전트 워크플로우에 기여합니다.

AI 평가 설계는 에이전트의 동작을 판단 가능하게 만드는 데 필요한 작업, 즉 허용 가능한 성능 정의, 드러내는 상황 생성, 적절한 증거 수집, 그리고 방어 가능한 기준 확립 등을 다룹니다.

그래서 저는 이 작업을 평가 설계(evaluation design)라고 부릅니다.

단순히 에이전트를 테스트할 사람만 필요한 것이 아닙니다.

무엇이 일어나야 하는지, 무엇이 일어나서는 안 되는지, 그리고 그 차이를 어떻게 알게 될 것인지를 정의해 줄 사람이 필요합니다.

구체적인 예시가 필요하다면 Nugalaxy의 공개 평가 사례를 살펴보세요.

여기서 하네스 엔지니어링(harness engineering)에 대해 더 읽어보기.