모델 검증이란?

단순히 “모델이 답을 생성하는가?”라고 묻는 대신, 모델 검증에서는 모델의 설계, 가정, 데이터, 구현, 결과물, 한계 및 지속적인 동작이 사람들이 해당 모델을 활용해 내리는 의사결정에 사용할 만큼 충분히 신뢰할 수 있는지를 평가합니다.

모델 검증을 통해 기업은 모델이 주어진 역할을 얼마나 잘 수행하는지 선제적으로 평가하여 모델 위험, 즉 모델이 부정확하거나 편향되거나 불안정하거나 안전하지 않은 결과를 생성하거나 잘못 사용될 위험을 줄일 수 있습니다.

간단한 검증의 경우 모델 개발자는 개발 과정에서 후보 모델을 검증 세트, 즉 ML 엔지니어와 데이터 과학자가 모델의 학습 상태를 확인하는 데 사용하는 예제 집합을 기준으로 평가하기만 하면 됩니다.

하지만 모델 위험 관리 차원에서 모델 검증은 훨씬 더 광범위합니다. 일반적으로 엔터프라이즈 모델 검증은 전체 모델 라이프사이클에 대한 독립적인 평가입니다. ML 모델은 모델을 개발하지 않은 사람이 검토하며, 모델이 어떻게 구축, 출시, 사용, 모니터링 및 변경되었고 최종적으로 어떻게 폐기되는지까지 검토합니다.

성공적인 검증 프로세스에서는 다음 5가지 사항을 확인합니다.

1. ML 모델의 목적이 명확하고 대상 집단, 범위 및 의사결정 컨텍스트가 정의되어 있습니다.
2. 모델의 개념적 접근 방식, 즉 입력을 출력에 매핑하는 기본적인 방법, 로직 및 가정이 해당 목적에 적합합니다.
3. 모델이 사용하는 데이터와 모델 구현이 정확하고 적절하게 통제됩니다.
4. 모델은 개발 과정에서 접하지 않은 데이터를 비롯한 관련 데이터에서 적절한 성능을 발휘합니다.
5. 기업은 모델의 한계를 파악하고 있으며 성능이 저하될 경우 필요한 조치를 취합니다.

일반적으로 모델 검증 프로세스의 엄격성은 모델의 용도에 따라 달라집니다. 영향이 적은 내부 예측 툴은 주택담보대출을 승인하거나 은행의 사기성 트랜잭션을 탐지하는 모델만큼 엄격하게 검토할 필요가 없습니다.

중요한 점은 모델 검증이 일회성 승인 절차가 아니라는 것입니다. 처음에는 우수한 성능을 보이더라도 모델은 출시 후 드리프트가 발생하고 성능이 저하될 수 있으므로, 지속적인 ML 모델 검증은 기업의 인공지능(AI) 거버넌스 관행에 포함되는 경우가 많습니다.

NIST AI Risk Management Framework에 따르면 모델 신뢰의 핵심 요소에는 유효성과 신뢰성, 안전성, 보안과 복원력, 책임성과 투명성, 설명 가능성과 해석 가능성, 개인정보 보호 강화, 공정성과 편향 관리가 포함됩니다.

머신 러닝 모델 검증은 모델 신뢰, 즉 모델이 적절하게 작동할 것이라고 합리적으로 확신할 수 있는 수준을 확립하고 유지하는 데 도움이 됩니다. 기업은 ML 모델의 결과물을 기반으로 의사결정을 내리므로 모델 신뢰는 단순히 평판을 위한 목표가 아닙니다. 이는 AI를 안전하고 효과적으로 대규모로 활용하기 위한 기반입니다. 실제로 모델 신뢰에 대한 목표는 모델 검증 방식을 결정하는 데 중요한 기준이 되는 경우가 많습니다.

또한 개발자가 모델을 “책임감 있는 AI”라고 부른다는 이유만으로 해당 모델을 신뢰할 수 있다고 판단할 수는 없습니다. 모델은 맡은 작업을 안정적으로 수행하고, 사람과 데이터를 보호하고, 오용에도 견딜 수 있어야 하며, 모델의 작동 방식을 이해하고 거버넌스를 적용할 수 있어야 합니다. 이러한 수준의 신뢰는 AI 모델 검증 과정에서 입증 가능한 통제 항목을 적용하고 지속적으로 증거를 수집함으로써 확보해야 합니다.

모델 신뢰의 핵심 요소를 이해하는 데 널리 활용되는 프레임워크로 미국 국립표준기술연구소(NIST)의 AI 위험 관리 프레임워크가 있습니다. 이 프레임워크에서는 신뢰할 수 있는 AI의 7가지 상호 의존적인 특성을 제시합니다.

신뢰할 수 있는 모델은 해당 작업에 적합한 유효성을 갖추고 예상되는 다양한 조건에서 시간이 지나도 안정적으로 작동해야 합니다. 유효성은 모델이 실제로 의도한 대상을 측정, 예측, 분류 또는 생성하는지를 평가합니다.

신뢰성은 서로 다른 사용자, 환경, 데이터 소스 및 기간에서 얻은 입력을 비롯해 유사한 입력이 주어졌을 때 모델이 일관되고 안정적으로 작동하는지를 평가합니다.

안전성은 모델이 기술적으로 설계된 대로 작동하더라도 사람, 재산, 조직 또는 사회에 피해를 줄 수 있는지를 중점적으로 평가합니다.

모델이 정확하면서도 안전하지 않을 수 있습니다. 예를 들어 고객 서비스 챗봇이 계정 정보를 정확하게 검색하더라도, 조작을 통해 민감한 데이터가 노출될 수 있다면 배포하기에 안전하지 않습니다. 안전성을 확보하려면 팀에서 배포 전에 예측 가능한 피해를 파악하고 시스템 설계를 통해 선제적으로 해결해야 합니다.

보안은 악의적인 액세스나 조작으로부터 모델과 모델의 데이터, 인터페이스 및 관련 애플리케이션을 보호합니다. 최신 AI 시스템에서 공격 표면은 모델 가중치를 훨씬 넘어서는 범위까지 확장됩니다. 여기에는 학습 데이터, 검색 소스, 프롬프트, 애플리케이션 프로그래밍 인터페이스(API), 플러그인, 사용자 아이덴티티, 배포 인프라, 로그 및 모델 공급망도 포함됩니다. 보안 통제 항목은 전체 공격 표면을 관리할 수 있어야 합니다.

복원력은 문제가 발생했을 때 모델이 계속 안전하게 작동하거나 적절하게 복구되거나 안전하게 기능을 중단할 수 있는 능력을 의미합니다. 즉, 모델이 사이버 공격뿐만 아니라 악의적이지 않은 장애에도 대응할 수 있는지 검증해야 합니다. 영향이 큰 환경에서는 단순히 가용성을 유지하는 것보다 문제가 발생했을 때 안전한 상태를 유지하는 것이 더 중요할 수 있습니다.

책임성은 지정된 소유자가 모델의 설계, 배포, 결과 및 시정 조치에 책임을 지는 것을 의미합니다. 책임성이 없다면 문제가 발생했을 때 기업이 “AI가 결정한 것”이라며 책임을 회피할 수 있습니다.

투명성은 시스템과 시스템의 결과물, 한계 및 거버넌스에 관한 모든 관련 정보를 필요한 사람이 확인할 수 있어야 한다는 것을 의미합니다. 투명성을 확보하기 위해 기업이 독점 소스 코드나 민감한 보안 세부 정보를 공개해야 하는 것은 아닙니다. 이해관계자가 시스템의 전반적인 범위를 이해할 수 있도록 정확하고 활용 가능한 정보를 충분히 공개하는 것을 의미합니다.

설명 가능성과 해석 가능성은 모델이 작동하는 방식과 실제 의사결정의 맥락에서 모델의 결과물이 의미하는 바를 이해하는 데 도움이 됩니다. 쉽게 말해 설명 가능성은 “어떤 요인이나 프로세스를 거쳐 이 결과물이 나왔는가?”라는 질문에 답합니다. 해석 가능성은 “이 결과물은 무엇을 의미하며, 사람은 이를 어떻게 활용해야 하는가?”라는 질문에 답합니다.

이 요소는 의사결정의 영향이 크거나, 이견의 소지가 있거나, 규제 대상이거나, 되돌리기 어려운 경우에 특히 중요합니다. 예를 들어 신용 위험 모델링이 이에 해당합니다.

개인정보 보호는 보안과 밀접하게 연관되어 있지만 서로 다른 개념입니다. 보안은 권한이 없는 주체의 데이터 액세스를 방지하는 반면, 개인정보 보호는 데이터가 적절하게 수집, 사용, 저장 및 공유되도록 하는 데 중점을 둡니다.

개인 데이터를 처리하도록 명시적으로 설계되지 않은 모델도 개인정보 보호 위험을 초래할 수 있습니다. 모델 학습 세트에 민감한 정보가 포함될 수 있으며, 일시적으로만 저장되어야 하는 사용자 데이터가 로그에 계속 남아 있을 수도 있습니다. 모델 검증을 통해 기업은 AI 툴의 보안을 확보하고 개인정보 보호 규칙을 준수할 수 있습니다.

공정성을 확보하려면 기업은 유해한 편향을 식별, 측정, 완화 및 모니터링해야 합니다. 그렇다고 해서 모든 사람에게 항상 동일한 결과물을 제공해야 하는 것은 아닙니다. 대신 대우나 결과의 차이는 정당하고 합법적이며 해당 작업과 관련이 있어야 하고, 피할 수 있거나 유해한 편향에서 비롯되어서는 안 됩니다.

모델 검증에는 일반적으로 다양한 점검 및 검증 기법이 포함됩니다.

개념적 타당성은 모델의 기본 로직과 설계를 평가합니다. 모델이 지원하도록 설계된 의사결정에 방법론, 입력값, 가정, 정성적 판단 및 설계 선택이 적합한지 평가합니다. 타당성 점검에는 다음이 포함됩니다.

• 모델의 방법론 평가 : 모델이 데이터를 결과물로 변환하는 방식을 파악합니다.

• 특성과 입력값 검토 : 각각의 중요한 특성이 관련성이 있고 사용 가능하며 적법한지 확인합니다.

• 가정 검토: 문서화 및 모니터링을 위해 가정의 타당성을 검토합니다.

• 한계 및 누락된 요인 파악 : 모델이 알지 못하는 사항을 파악하고 모델의 신뢰성이 떨어지는 상황을 이해합니다.

• 해석 가능성 및 사용 적합성 평가: 모델이 특정 결과물을 생성하는 이유와 모델이 제대로 작동하지 않을 수 있는 상황을 파악합니다.

데이터 검증을 통해 팀은 모델을 구축, 튜닝, 테스트 및 실행하는 데 사용되는 데이터를 신뢰할 수 있는지 판단할 수 있습니다.데이터 검증에는 다음이 포함됩니다.

• 데이터 품질 평가. 데이터 품질 점검은 데이터 레코드가 정확하고 완전하며 관련성과 대표성을 갖추고 적절하게 레이블이 지정되었으며, 합법적으로 수집되고 보호 및 분리되어 있는지 확인하는 것을 목표로 합니다.

• 출처 및 데이터 계보 확립. 검증 과정에서는 각 데이터세트와 특성을 식별 가능한 원본 소스까지 추적할 수 있어야 합니다.

• 작업 관련성 확인. 관련성을 확인한다는 것은 모델의 각 데이터 요소가 모델의 목적과 유의미하게 관련된 정보를 반영하는지 점검하는 것을 의미합니다.

• 레이블 및 정답 데이터 검증. 레이블 검증은 레이블이 목표 결과를 정확하고 적절하며 일관되게 정의된 방식으로 나타내는 결과물을 생성하도록 합니다. 또한 무엇이 사실인지 판단할 수 있는 가장 신뢰할 만한 기준인 참조 표준을 식별합니다.

결과 분석은 두 가지 주요 목적을 수행합니다. 첫째, 모델의 결과물이 모델이 예측하고자 하는 실제 상황과 일치하는지 판단합니다. 둘째, 결과물을 활용하는 것이 허용할 수 없는 피해, 비용 또는 위험을 초래하지 않으면서 기업이 의도한 목표를 달성하는 데 실제로 도움이 되는지 평가합니다. 결과 분석을 위해 팀에서 다음과 같은 작업을 수행해야 할 수 있습니다.

• 예측과 실제 결과를 비교합니다. 결과 분석에서는 모델의 “정답 데이터”가 확보될 때까지 기다리거나 이를 수집 또는 확립한 다음 모델의 결과물과 비교합니다.

• 백테스팅을 사용합니다. 백테스팅은 과거의 특정 시점에 이용할 수 있었던 정보만 사용하여 해당 시점의 사례에 모델을 적용한 다음, 모델의 예측과 실제로 발생한 결과를 비교합니다.

• 재현율과 예측 오류를 검토합니다. 문제가 있는 모델은 거짓 양성과 거짓 음성을 생성할 수 있습니다. 결과 분석에서는 두 가지 오류 유형을 모두 측정하고 그에 따른 영향을 평가하여 기업의 위험 임계값을 초과하는지 판단합니다.

• 보정 상태를 확인합니다. 보정은 모델이 제시하는 확률이 실제로 관측된 빈도와 일치하는지 평가합니다. 모델이 1,000건의 트랜잭션에 사기일 확률을 70%로 산정했다면, 최종적으로 약 700건이 사기로 확인되어야 합니다. 250건만 사기로 확인되거나 850건이 사기로 확인된다면 모델이 위험을 잘못 추정하고 있는 것입니다.

• 비즈니스 및 운영 영향을 평가합니다. 결과 분석에서는 모델이 실제로 배포 목적에 해당하는 목표를 달성하는 데 기여하는지 평가합니다.

모델의 견고성과 민감도를 검증하면 불완전하거나 비정상적이거나 의도적으로 적대적인 조건에서도 모델이 계속 안정적으로 작동하도록 할 수 있습니다.

민감도 자체가 나쁜 것은 아닙니다. 일부 입력값은 모델의 결과물에 큰 영향을 미치는 것이 적절합니다. 예를 들어 최근에 권한 있는 계정에 변경 사항이 발생했다면 해당 계정의 사이버 보안 위험 점수가 달라지는 것은 합리적입니다. 문제가 되는 것은 정당한 이유 없이 민감하게 반응하는 경우로, 사소하거나 관련성이 없거나 일상적인 변경 사항이 모델의 동작에 지나치게 큰 영향을 미치는 경우입니다.

팀은 다음과 같은 조건에서 모델을 테스트할 수 있습니다.

• 노이즈가 있거나 불완전한 입력값. 견고성 점검에서는 데이터 누락이나 잘못된 입력과 같은 조건을 시뮬레이션하여 정제되지 않은 데이터가 모델의 성능과 응답에 어떤 영향을 미치는지 확인합니다. 이를 통해 과소적합(모델이 학습 데이터에서 충분히 학습하지 못해 패턴을 인식하지 못하는 경우)과 과적합(모델이 노이즈를 포함한 학습 데이터를 지나치게 많이 암기하는 경우)을 방지할 수 있습니다.

• 조건의 변화. 머신 러닝 모델은 새로운 정책, 서비스 중단, 개념 드리프트 등으로 인해 프로덕션 데이터가 더 이상 개발 데이터와 유사하지 않게 되는 분포 변화에 대응할 수 있어야 합니다. 검토자는 이후 기간의 데이터, 새로운 환경 및 의도적으로 구성한 분포 외 사례를 사용하여 모델의 성능이 허용 가능한 수준을 넘어 저하되는지 확인할 수 있습니다.

• 엣지 케이스와 불확실성. 엣지 케이스는 모델에 내재된 숨겨진 가정을 드러내는 경우가 많습니다. 이러한 시나리오에 모델이 어떻게 대응하는지 확인하면 모델이 불확실성을 인식하고 적절한 대체 방식을 사용하는지 파악할 수 있습니다.

• 적대적 입력값. 적대적 입력 검증에서는 누군가 의도적으로 모델을 조작하여 부정확하거나 안전하지 않거나 승인되지 않았거나 오해의 소지가 있는 결과물을 생성하게 할 수 있는지 평가합니다.

• 모델 드리프트. 팀은 드리프트 시뮬레이션을 사용하여 프로덕션 데이터, 사용자 행동 또는 입력값과 결과 간의 관계가 변화한 시나리오를 의도적으로 만든 다음, 모델의 성능이 통제된 방식으로 저하되고 통제 항목이 올바르게 대응하는지 확인할 수 있습니다.

벤치마킹과 챌린지 테스트에서는 모델을 신뢰할 수 있는 대안과 비교하여 실제로 가치를 더하는지 평가합니다. 기업은 이러한 방식을 활용하여 모델이 더 단순한 방법, 이전 모델, 사람이 수행하는 프로세스 또는 독립적으로 개발된 경쟁 모델(후보 모델의 동작을 검증하기 위해 특별히 구축하거나 선정한 모델)보다 실질적으로 더 나은 성능을 보이는지 파악합니다.

• 벤치마크(예: 이전 프로덕션 모델 또는 경쟁 모델)는 ML 모델을 평가하는 데 사용되는 기준점입니다. 기본 모델이 모든 성능 메트릭에서 모든 대안보다 우수할 필요는 없습니다. 팀은 장단점을 파악하여 선택한 모델의 타당성을 설명할 수 있으면 됩니다.

• 챌린지 테스트 는 모델이 의도한 용도에 적합하지 않음을 입증하기 위해 다양한 방식으로 검증하는 광범위한 방식을 의미합니다. 챌린지 테스트에서는 모델이 제대로 작동할 것으로 예상되는 상황뿐만 아니라 문제가 발생할 가능성이 가장 높은 시나리오도 점검합니다.

안전성, 보안 및 개인정보 보호 점검에서는 모델이 초래할 수 있는 다양한 위험을 평가하지만, 많은 취약점은 모델 자체가 아니라 ML 모델과 연동되는 시스템에 존재합니다.

예를 들어 모델 자체에는 기밀 정보 공개를 방지하는 강력한 내부 정책이 적용되어 있더라도 애플리케이션의 검색 시스템이 문서 권한을 제대로 적용하지 못하면 비공개 문서가 노출될 수 있습니다. 마찬가지로 모델 자체는 기본적인 탈옥 공격에 강하더라도, 검색한 웹페이지에 간접적인 프롬프트 인젝션이 포함되어 있으면 해당 모델을 기반으로 구축된 에이전트가 여전히 안전하지 않은 작업을 수행할 수 있습니다.

따라서 효과적인 검증을 위해서는 모델뿐만 아니라 모델을 둘러싼 전체 에코시스템을 평가해야 합니다.

문서화와 재현 가능성을 확보하면 모델이 “작동한다”는 비공식적인 주장에 그치지 않고 검증 결과를 감사 가능한 증거로 제시할 수 있습니다.

문서화는 초기 비즈니스 사례부터 개발, 검증, 배포, 모니터링, 중대한 변경을 거쳐 최종 폐기에 이르기까지 ML 모델의 전체 라이프사이클에 걸쳐 이루어집니다. 여기에는 모델의 계보를 기록하고 명확한 버전 관리를 유지하는 작업이 포함되며, 이를 통해 검토자는 시간의 흐름에 따라 모델이 어떻게 변경되는지 파악할 수 있습니다.

재현 가능성을 확보하면 자격을 갖춘 독립적인 검토자가 문서화된 자료를 사용하여 모델 개발 또는 검증 프로세스를 반복하고 대체로 동일한 결과를 얻을 수 있습니다.

모델 검증, 모델 테스트 및 모델 모니터링은 서로 연관된 품질 보증 방식이지만, 머신 러닝 모델의 라이프사이클에서 서로 다른 시점에 각기 다른 질문에 답합니다.

• 검증에서는 “모델이 의도한 용도에 적합하고 신뢰할 수 있으며 적절하게 설계되었는가?”를 평가합니다.

• 테스트에서는 “최종 모델이 사전에 정의된 기술, 비즈니스, 안전 및 운영상의 승인 기준을 충족하는가?”를 평가합니다.

• 모니터링에서는 “배포된 모델이 실제 환경에서 실제 데이터를 사용해 계속해서 제대로 작동하고 있는가?”를 평가합니다.

모델 테스트는 개발 프로세스 전반에 걸쳐 이루어지지만, 공식적인 테스트 세트 평가는 일반적으로 팀에서 주요 설계 선택과 튜닝 관련 결정을 확정한 후에 이루어집니다. 테스트는 모델 개발 관련 의사결정에 참여하지 않은 사람이 수행하는 경우가 많습니다. train_test_split 기법의 경우 학습, 하이퍼파라미터 튜닝, 임계값 선택 또는 모델 선택에 사용되지 않은 별도의 테스트 데이터세트를 사용하여 최종 모델이 실제로 처음 접하는 데이터에서 어떤 성능을 보일지 신뢰할 수 있고 편향 없이 추정합니다.

기업은 다양한 모델 평가 방식을 선택할 수 있습니다.

예를 들어 홀드아웃 세트는 데이터의 일부를 학습 및 모델 개발에 사용하지 않고 따로 보관한 다음, 이 데이터를 사용하여 최종 모델이 처음 접하는 사례에서 얼마나 우수한 성능을 보이는지 평가합니다. 팀은 k-겹 교차 검증을 사용할 수 있습니다. 이 방식에서는 데이터의 서로 다른 부분을 사용하여 모델을 k 번 학습하고 테스트한 다음 그 결과의 평균을 구합니다. 또는 더 엄격한 형태의 k-겹 교차 검증을 위해 팀에서 하나씩 제외하는 교차 검증(LOOCV)을 수행하여 모든 개별 데이터 포인트에서 모델을 동시에 테스트할 수도 있습니다. 어떤 방법을 사용하든 모델 테스트는 ML 모델을 배포하기 전에 실제 환경에서의 품질을 예측하는 것을 목표로 합니다.

테스트가 품질 평가에 중점을 두는 반면, 모델 모니터링은 학습된 모델과 이를 둘러싼 에코시스템이 배포 후 예상대로 작동하는지 확인하는 데 중점을 둡니다. 지속적으로 또는 미리 정해진 일정에 따라 수행할 수 있는 모니터링에서는 실제 운영 중인 모델의 입력값, 결과물 및 운영 동작을 관찰하여 위험 관리 팀이 변화가 본격적인 성능 저하나 더 심각한 장애로 이어지기 전에 이를 탐지할 수 있도록 합니다.

모니터링은 문제가 있는 모델 동작을 조기에 파악할 수 있는 경고 체계를 기업에 제공하지만 검증을 대체할 수는 없습니다. 모델 검증은 일반적으로 개발 팀이 모델을 구축하는 동안 반복적으로 수행하는 평가 프로세스이지만, 승인 전에 독립적인 프로세스로 수행하고 승인 후에도 정기적으로 실시할 수 있습니다.

검증, 테스트 및 모니터링은 서로 별개의 프로세스이지만, 일반적으로 기업이 ML 모델의 전체 수명에 걸쳐 성능과 신뢰성을 최적화하려면 이 세 가지가 모두 필요합니다.

생성형 AI와 AI 에이전트에도 다른 ML 시스템과 동일한 핵심 검증 방식이 필요합니다. 하지만 이러한 툴은 예측 모델 검증만으로는 완전히 파악하기 어려운 위험을 초래할 수 있습니다. 생성형 AI 시스템은 정해진 형식에 제한되지 않는 결과물을 생성하며, 에이전트는 이러한 결과물을 활용하여 서로 연결된 시스템에서 작업을 계획하고 수행할 수 있습니다.

일반적인 ML에서는 모델의 결과를 정답 레이블과 직접 비교하여 평가할 수 있는 경우가 많습니다. 사기 탐지 모델이 특정 트랜잭션을 “사기”로 예측하고 이후 조사에서 실제 사기로 확인되었다면 해당 예측은 정확한 것입니다. 수요 예측 모델이 1,150개를 예측했지만 실제 수요가 1,600개였다면, 팀은 모델의 예측값이 실제 값에 얼마나 가까운지를 평가하는 회귀 메트릭인 평균 제곱 오차를 사용하여 그 차이를 정확하게 측정할 수 있습니다.

일반적으로 생성형 AI의 결과물에는 하나의 정답 표현이 존재하지 않으며, 완전한 하나의 “정답” 자체가 없을 수도 있습니다. 구조화된 추출이나 툴 선택과 같이 범위가 제한된 일부 작업은 명시적으로 예상되는 결과물을 기준으로 평가할 수 있습니다. 하지만 일반적으로 모델의 동작은 상호 작용할 때마다 달라질 수 있는 런타임 컨텍스트에 크게 좌우됩니다. 생성형 AI는 환각을 일으켜 프롬프트에 대한 응답으로 사실이 아니거나 잘못된 정보를 확신에 찬 어조로 제시할 수도 있습니다.

따라서 생성형 AI를 검증할 때는 실제 사용 상황을 반영한 프롬프트, 승인된 소스 자료, 예상 답변에 포함되어야 할 요소 및 채점 기준이 포함된 평가 세트를 사용해야 합니다. 채점 기준을 사용하면 모델이 여러 가지 허용 가능한 응답을 생성할 수 있도록 하면서도 각 응답에 특정 사실을 포함하고, 근거 없는 진술을 피하며, 불확실성이 있는 경우 이를 명시하도록 할 수 있습니다.

AI 에이전트는 계획을 수립하고, 액세스 권한을 부여하고, 레코드를 수정하고, 메시지를 전송하고, 새로운 에이전트를 활용하는 완전히 새로운 워크플로를 시작할 수 있습니다. 따라서 AI 에이전트에는 생성형 AI와 동일하게 결과물에 중점을 둔 모든 점검이 필요하며, 개발자는 결과물을 바탕으로 이루어지는 의사결정과 작업도 검증해야 합니다. 에이전트의 파운데이션 모델 변경이나 새로운 검색 리포지터리 연결과 같은 중대한 변경 사항이 발생하면 재검증을 수행해야 합니다.