AI 모델 테스트 방법

AI 모델 테스트 방법

간단히 말해서, AI 모델을 제대로 평가하려면 먼저 실제 사용자와 당면한 의사결정 상황에서 "좋은" 모델이란 무엇인지 정의해야 합니다. 그런 다음 대표성 있는 데이터, 엄격한 데이터 유출 방지 장치, 다양한 지표를 활용하여 반복 가능한 평가 환경을 구축하십시오. 스트레스 테스트, 편향 테스트, 안전성 테스트를 추가하고, 데이터, 프롬프트, 정책 등 어떤 변화라도 발생하면 테스트를 다시 실행하고 출시 후에도 지속적으로 모니터링해야 합니다.

핵심 요약:

성공 기준 : 지표를 선택하기 전에 사용자, 의사 결정, 제약 조건 및 최악의 실패 시나리오를 정의하십시오.

반복성 : 변경 사항이 있을 때마다 유사한 테스트를 다시 실행하는 평가 환경을 구축하십시오.

데이터 관리 : 안정적인 분할을 유지하고, 중복을 방지하며, 특징 유출을 조기에 차단하십시오.

신뢰성 검증 : 명확한 평가 기준을 통해 견고성, 공정성 검증, LLM 안전 행동에 대한 스트레스 테스트를 실시합니다.

라이프사이클 관리 원칙 : 단계별로 배포하고, 편차 및 문제를 모니터링하며, 알려진 문제점을 문서화합니다.

이 글을 읽고 나서 읽어보시면 좋을 만한 글들:

🔗 AI 윤리란 무엇인가
책임감 있는 AI 설계, 사용 및 관리를 위한 원칙을 살펴보세요.

🔗 AI 편향이란 무엇인가?
편향된 데이터가 AI의 의사 결정과 결과에 어떤 영향을 미치는지 알아보세요.

🔗 AI 확장성이란 무엇인가
AI 시스템의 성능, 비용 및 신뢰성 측면에서 확장성을 이해하십시오.

🔗 AI란 무엇인가
인공지능의 종류와 실제 활용 사례에 대한 명확한 개요.

1) “좋다”라는 단어의 다소 소박한 정의부터 시작해 봅시다 

지표, 대시보드, 벤치마크 등을 살펴보기 전에 먼저 성공의 기준을 정하십시오.

밝히다:

  • 사용자: 내부 분석가, 고객, 임상의, 운전사, 오후 4시의 피곤한 지원 담당자…

  • 결정 사항: 대출 승인, 사기 행위 감지, 콘텐츠 제안, 메모 요약

  • 가장 중요한 실패:

    • 오탐(성가신) vs 오분류(위험한)

  • 제약 조건: 지연 시간, 요청당 비용, 개인정보 보호 규칙, 설명 가능성 요구 사항, 접근성

바로 이 부분에서 팀들은 '의미 있는 결과'보다는 '보기 좋은 지표'를 최적화하는 데 치중하게 됩니다. 이런 일은 정말 자주 일어납니다. 아주 많이요.

AI 위험 관리 프레임워크(AI RMF 1.0) [1] 에서 하는 것처럼 신뢰성과 수명주기 위험 관리를 중심으로 테스트를 구성하는 것입니다

 

AI 모델 테스트

2) "AI 모델 테스트 방법"의 좋은 버전은 어떤 특징을 가지고 있을까요? ✅

탄탄한 테스트 접근 방식에는 몇 가지 필수 요소가 있습니다

  • 대표 데이터 (단순히 정제된 실험실 데이터가 아닌)

  • 투명한 분할 패널 (자세한 내용은 잠시 후 설명)

  • 기준선 (이겨야 할 - 더미 추정기가 존재하는 데에는 이유가 있습니다[4])

  • 여러 지표를 사용하는 이유 (하나의 수치는 당신을 정중하게 속이기 때문입니다)

  • 스트레스 테스트 (예외적인 상황, 특이한 입력, 적대적 시나리오 등)

  • 인간 검토 과정 (특히 생성형 모델의 경우)

  • 출시 후 모니터링 (세상이 변하고, 파이프라인이 중단되고, 사용자가… 창의적이기 때문입니다[1])

또한, 좋은 접근 방식에는 테스트한 내용, 테스트하지 않은 내용, 그리고 걱정되는 부분을 문서화하는 것이 포함됩니다. "걱정되는 부분"을 적는 부분이 어색하게 느껴질 수 있지만, 바로 그 부분에서 신뢰가 쌓이기 시작합니다.

팀이 솔직함을 유지하는 데 꾸준히 도움이 되는 두 가지 문서화 패턴:

  • 모델 카드 (모델의 용도, 평가 방법, 실패 지점) [2]

  • 데이터세트용 데이터시트 (데이터가 무엇인지, 어떻게 수집되었는지, 무엇을 사용해야 하는지/사용해서는 안 되는지) [3]

3) 도구의 현실: 사람들이 실제로 사용하는 것 🧰

도구는 선택 사항이지만, 훌륭한 평가 습관은 필수적입니다.

실용적인 구성을 원한다면 대부분의 팀은 결국 세 가지 범주로 나뉘게 됩니다

  1. 실험 추적 (실행, 구성, 결과물)

  2. 평가 도구 모음 (반복 가능한 오프라인 테스트 + 회귀 테스트 스위트)

  3. 모니터링 (변화 신호, 성능 지표, 사고 알림)

실제 사용 환경에서 흔히 볼 수 있는 예시들입니다(추천은 아니며, 기능/가격은 변경될 수 있습니다): MLflow, Weights & Biases, Great Expectations, Evidently, Deepchecks, OpenAI Evals, TruLens, LangSmith.

이 섹션에서 아이디어 만 선택해야 한다면 반복 가능한 평가 환경을 구축하는 것 입니다. "버튼을 누르면 비교 가능한 결과가 나오는" 방식이 아니라, "노트북을 다시 실행하고 운에 맡기는" 방식이 되어야 합니다.

4) 올바른 테스트 세트를 구축하고 데이터 유출을 막으세요 🚧

놀라운 수치의 "훌륭한" 모델들이 의도치 않게 부정행위를 저지르고 있다.

표준 ML의 경우

커리어를 지켜주는 몇 가지 매력적이지 않은 규칙:

  • 학습/검증/테스트 유지하고 분할 로직을 기록해 두세요.

  • 분할된 영역 간 중복 방지 (동일 사용자, 동일 문서, 동일 제품, 유사 항목)

  • 기능 유출 (미래 정보가 현재 기능에 슬며시 포함되는 현상) 에 주의하세요.

  • 기준선(더미 추정기)을 사용하여 아무것도 이기지 못했다고 축하하지 마세요.[4]

정보 누출 정의(간단히 설명하자면): 학습/평가 과정에서 모델이 의사 결정 시점에는 알 수 없는 정보에 접근할 수 있게 해주는 모든 것. 이는 명확한 경우("미래 레이블")도 있고 미묘한 경우("이벤트 후 타임스탬프 버킷")도 있습니다.

LLM 및 생성 모델의 경우

당신은 단순히 "모델"을 만드는 것이 아니라, 프롬프트 및 정책 시스템을

  • 간결하고, 품질이 높으며, 안정적인 최적의 프롬프트 세트를 만드세요

  • 최근 실제 샘플 (익명 처리 및 개인정보 보호) 추가하세요

  • 예외 상황 모음을 준비해 두세요 : 오타, 속어, 비표준 형식, 빈 입력란, 다국어 환경에서 발생하는 예상치 못한 문제들 🌍

실제로 여러 번 목격한 일이 있습니다. 어떤 팀이 오프라인 테스트에서 "높은" 점수를 받고 제품을 출시했는데, 고객 지원팀에서 "좋습니다. 그런데 핵심적인 문장 하나가 빠져 있네요."라고 말하는 경우입니다. 해결책은 "더 큰 모델"이 아니었습니다. 더 나은 테스트 지침 , 더 명확한 평가 기준, 그리고 바로 그 오류 유형을 잡아내는 회귀 테스트 도구였습니다. 간단하지만 효과적입니다.

5) 오프라인 평가: 의미 있는 지표 📏

지표 자체는 괜찮습니다. 하지만 지표만 남용하는 것은 옳지 않습니다.

분류 (스팸, 사기, 의도, 우선순위 지정)

정확성 그 이상을 활용하세요.

  • 정밀도, 재현율, F1

  • 임계값 조정(기본 임계값은 비용에 대해 거의 "정확하지 않음")[4]

  • 세그먼트별(지역, 기기 유형, 사용자 그룹) 혼동 행렬

회귀 분석(예측, 가격 책정, 점수 산정)

  • MAE/RMSE (오류에 대한 처벌 방식에 따라 선택하세요)

  • 출력값을 "점수"로 사용할 때 일종의 보정 검사 (점수가 현실과 일치하는가?)

순위/추천 시스템

  • NDCG, MAP, MRR

  • 쿼리 유형별(헤드 vs 테일) 슬라이스

컴퓨터 비전

  • mAP, IoU

  • 클래스별 성능 (모델 성능이 저조한 드문 클래스가 문제입니다)

생성 모델(LLM)

사람들이 여기서… 철학적인 얘기를 하게 되네요 😵💫

실제 팀에서 효과적인 실용적인 방안:

  • 인간 평가 (최상의 신호, 가장 느린 루프)

  • 쌍별 선호도/승률 (A 대 B 비교는 절대 점수 계산보다 쉽습니다)

  • 자동화된 텍스트 측정 지표(일부 작업에는 유용하지만 다른 작업에는 오해의 소지가 있음)

  • 작업 기반 점검: "올바른 필드를 추출했는가?", "정책을 준수했는가?", "필요할 때 출처를 명시했는가?"

구조화된 "다중 측정, 다중 시나리오" 참조점을 원한다면 HELM은 좋은 기준점이 됩니다. HELM은 정확도를 넘어 보정, 견고성, 편향/독성, 효율성 절충과 같은 요소까지 평가를 명시적으로 확장합니다[5].

잠깐 다른 얘기지만, 글쓰기 품질을 평가하는 자동화된 지표들은 마치 샌드위치를 ​​무게로 재는 것 같은 느낌이 들 때가 있어요. 완전히 쓸모없는 건 아니지만… 너무하잖아요 🥪

6) 견고성 테스트: 좀 혹독하게 테스트해 보세요 🥵🧪

모델이 깔끔한 입력값에서만 작동한다면, 그것은 마치 유리 꽃병과 같습니다. 예쁘지만 깨지기 쉽고 비싸죠.

시험:

  • 노이즈: 오타, 누락된 값, 비표준 유니코드, 서식 오류

  • 유통 방식의 변화: 새로운 제품 카테고리, 새로운 신조어, 새로운 센서

  • 극단적인 값: 범위를 벗어난 숫자, 거대한 페이로드, 빈 문자열

  • 학습 데이터셋과는 다르지만 사용자와 유사한 "

LLM 과정의 경우 다음을 포함하세요

  • 프롬프트 주입 시도(사용자 콘텐츠 내에 숨겨진 지침)

  • “이전 지시 사항을 무시하세요” 패턴

  • 도구 사용 시 발생하는 예외적인 상황(잘못된 URL, 시간 초과, 부분 출력)

견고성은 사건이 발생하기 전까지는 추상적으로 들리는 신뢰성 속성 중 하나입니다. 그런 다음에는 매우 구체적인 것이 됩니다[1].

7) 편견, 공정성, 그리고 그것이 누구에게 유리한가 ⚖️

모델은 전반적으로 "정확"할 수 있지만 특정 그룹에 대해서는 지속적으로 정확도가 떨어질 수 있습니다. 이는 사소한 버그가 아닙니다. 제품 및 신뢰에 대한 문제입니다.

실질적인 단계:

  • (측정하기에 법적/윤리적으로 적절한) 의미 있는 세그먼트를 기준으로 성과를 평가합니다

  • 그룹 간 오류율 및 보정값을 비교합니다

  • 민감한 정보를 포함할 수 있는 프록시 기능(우편번호, 기기 유형, 언어)을 테스트합니다

만약 이 내용을 어딘가에 문서화하지 않는다면, 미래의 당신에게 지도 없이 신뢰 위기를 디버깅하라고 요청하는 것과 마찬가지입니다. 모델 카드는 이를 기록하기에 좋은 장소이며[2], NIST의 신뢰성 프레임워크는 "좋은" 것이 무엇을 포함해야 하는지에 대한 강력한 체크리스트를 제공합니다[1].

8) 안전 및 보안 테스트 (특히 LLM의 경우) 🛡️

모델이 콘텐츠를 생성할 수 있다면 정확도뿐만 아니라 동작까지 테스트하는 셈입니다.

다음 항목에 대한 테스트를 포함하세요:

  • 허용되지 않는 콘텐츠 생성(정책 위반)

  • 개인정보 유출 (비밀을 암시하는가?)

  • 중요한 영역에서의 환각

  • 과도한 거부 (모델이 일반적인 요청을 거부함)

  • 독성 및 괴롭힘 결과

  • 프롬프트 주입을 통한 데이터 유출 시도

체계적인 접근 방식은 다음과 같습니다. 정책 규칙 정의 → 테스트 프롬프트 구축 → 사람과 자동화된 검사를 통해 결과 점수 매기기 → 변경 사항이 있을 때마다 실행. 여기서 "매번" 실행해야 하는 부분이 핵심입니다.

이것은 생명주기 위험 사고방식에 딱 들어맞습니다. 즉, 관리, 컨텍스트 매핑, 측정, 관리, 반복[1]입니다.

9) 온라인 테스트: 단계적 출시 (진실이 드러나는 곳) 🚀

오프라인 테스트는 필수적입니다. 온라인 노출은 현실이 진흙 묻은 신발을 신고 나타나는 순간입니다.

화려할 필요는 없어요. 단지 절제력만 있으면 됩니다

  • 섀도우 모드 로 실행 (모델은 실행되지만 사용자에게는 영향을 미치지 않습니다)

  • 점진적 출시 (소규모 트래픽으로 시작하여, 트래픽이 안정적이면 확대)

  • 결과 및 사건(불만, 문제 제기, 정책 실패)을

즉시 레이블을 얻을 수 없더라도 프록시 신호와 운영 상태(지연 시간, 실패율, 비용)를 모니터링할 수 있습니다. 핵심은 전체 사용자 기반이 알기 전에

10) 배포 후 모니터링: 드리프트, 성능 저하 및 조용한 고장 📉👀

테스트했던 모델이 최종적으로 사용하게 될 모델은 아닙니다. 데이터는 변하고, 사용자도 변하고, 세상도 변합니다. 파이프라인은 새벽 2시에 고장 나기도 하죠. 다들 아시잖아요…

감시 장치:

  • 입력 데이터의 드리프트(스키마 변경, 결측치, 분포 변화)

  • 결과 편차(계급 균형 변화, 점수 변화)

  • 성능 대리 지표 (레이블 지연은 실제로 발생하기 때문)

  • 피드백 신호(싫어요, 재편집, 문제 제기)

  • 세그먼트 수준 회귀 분석(조용한 살인자)

그리고 너무 예민하지 않은 알림 임계값을 설정하세요. 끊임없이 경고음을 내는 모니터는 마치 도시의 자동차 경보기처럼 무시되기 쉽습니다.

신뢰성을 중요하게 생각한다면 이러한 "모니터링 + 시간 경과에 따른 개선" 루프는 선택 사항이 아닙니다[1].

11) 따라할 수 있는 실용적인 워크플로 🧩

다음은 확장성이 뛰어난 간단한 반복문입니다

  1. 성공 및 실패 모드 정의(비용/지연/안전 포함)[1]

  2. 데이터셋 생성:

    • 골든 세트

    • 엣지 케이스 팩

    • 최근 실제 샘플 (개인정보 보호 보장)

  3. 측정 지표를 선택하세요:

    • 작업 측정 지표(F1, MAE, 승률) [4][5]

    • 안전 지표(정책 통과율) [1][5]

    • 운영 지표(지연 시간, 비용)

  4. 평가용 하네스를 구축합니다(모든 모델/프롬프트 변경 시 실행됨)[4][5]

  5. 스트레스 테스트 + 적대적 테스트 추가[1][5]

  6. 샘플에 대한 인간 검토(특히 LLM 출력의 경우)[5]

  7. 섀도우 방식 배송 + 단계적 출시 [1]

  8. 규율을 통한 모니터링 + 경고 + 재교육 [1]

  9. 문서 결과는 모델 카드 스타일의 문서입니다[2][3]

훈련은 화려하지만, 시험은 생계 유지 수단이다.

12) 마무리 말씀 + 간단한 요약 🧠✨

인공지능 모델 테스트 방법 에 대해 몇 가지만 기억하고 있다면 :

  • 대표 테스트 데이터를 사용 하고 누출을 방지합니다.[4]

  • 실제 결과와 연관된 여러 지표를 선택하세요

  • 인간 검토와 승률 스타일 비교 에 의존합니다 [5].

  • 테스트 견고성 - 비정상적인 입력은 위장된 정상 입력입니다 [1].

  • 모델이 변하고 파이프라인이 중단되기 때문에 안전하게 배포하고 모니터링하십시오[1]

  • 테스트한 내용과 테스트하지 않은 내용을 문서화하세요(불편하지만 강력합니다)[2][3]

테스팅은 단순히 "작동함을 증명하는 것"이 ​​아닙니다. "사용자가 문제를 발견하기 전에 어떤 부분에서 오류가 발생하는지 찾아내는 것"입니다. 물론, 좀 덜 매력적인 부분일 수도 있지만, 시스템이 불안정해질 때 제대로 작동하도록 지탱해주는 핵심적인 부분입니다. 🧱🙂

자주 묻는 질문

인공지능 모델이 실제 사용자 요구에 부합하도록 테스트하는 가장 좋은 방법은 무엇일까요?

우선 '좋은' 것을 단순히 순위표 지표가 아닌 실제 사용자 경험과 모델이 지원하는 의사결정이라는 관점에서 정의하세요. 가장 큰 손실을 초래하는 실패 모드(오탐 vs. 미탐)를 파악하고 지연 시간, 비용, 개인정보 보호, 설명 가능성과 같은 엄격한 제약 조건을 명확히 하세요. 그런 다음 이러한 결과를 반영하는 지표와 테스트 케이스를 선택하세요. 이렇게 하면 제품 개선으로 이어지지 않는 '보기 좋은 지표'를 최적화하는 데 시간을 낭비하지 않을 수 있습니다.

평가 지표를 선택하기 전에 성공 기준을 정의하십시오

사용자가 누구인지, 모델이 어떤 의사결정을 지원해야 하는지, 그리고 실제 운영 환경에서 최악의 경우 어떤 문제가 발생할 수 있는지 명확히 정의하세요. 허용 가능한 지연 시간 및 요청당 비용과 같은 운영상의 제약 조건과 개인정보 보호 규칙 및 보안 정책과 같은 거버넌스 요구 사항도 고려해야 합니다. 이러한 요소들이 명확해지면, 지표는 올바른 것을 측정하는 도구가 됩니다. 이러한 명확한 틀이 없으면, 팀은 측정하기 가장 쉬운 것에만 집중하여 최적화하려는 경향이 있습니다.

모델 평가에서 데이터 유출 및 우발적 부정행위 방지

훈련/검증/테스트 데이터셋 분할을 안정적으로 유지하고 분할 로직을 문서화하여 결과의 ​​재현성을 확보하십시오. 분할된 데이터셋 간에 중복 또는 유사 중복(동일한 사용자, 문서, 제품 또는 반복되는 패턴)이 발생하지 않도록 적극적으로 차단하십시오. 타임스탬프나 이벤트 후 필드를 통해 "미래" 정보가 입력값에 스며드는 현상인 특징 누출에 주의하십시오. 강력한 기준선(더미 추정치 포함)을 구축하면 노이즈를 감지하는 데 도움이 됩니다.

테스트가 변경 사항 전반에 걸쳐 반복 가능하도록 평가 도구에 포함되어야 하는 사항은 무엇입니까?

실용적인 테스트 도구는 동일한 데이터 세트와 채점 규칙을 사용하여 모든 모델, 프롬프트 또는 정책 변경 사항에 대해 유사한 테스트를 반복 실행합니다. 일반적으로 회귀 테스트 도구 모음, 명확한 지표 대시보드, 추적성을 위한 저장된 구성 및 아티팩트가 포함됩니다. LLM 시스템의 경우 안정적인 "골든 세트" 프롬프트와 예외 상황 팩도 필요합니다. 목표는 "버튼 클릭 → 유사한 결과"를 얻는 것이지, "노트북을 다시 실행하고 운에 맡기는 것"이 ​​아닙니다

정확도를 넘어선 AI 모델 테스트 지표

단일 지표로는 중요한 장단점을 파악하기 어려우므로 여러 지표를 활용하세요. 분류의 경우 정밀도/재현율/F1 점수를 임계값 조정 및 세그먼트별 혼동 행렬과 함께 사용하세요. 회귀의 경우 오류에 대한 페널티 방식에 따라 MAE 또는 RMSE를 선택하고, 출력값이 점수처럼 작동하는 경우 보정 방식의 검사를 추가하세요. 순위 지정의 경우 NDCG/MAP/MRR을 사용하고, 성능 불균형을 파악하기 위해 쿼리의 앞부분과 뒷부분을 구분하여 분석하세요.

자동화된 측정 지표가 부족할 때 LLM 출력 평가

프롬프트 및 정책 시스템으로 접근하여 텍스트 유사성뿐만 아니라 동작에도 점수를 매겨야 합니다. 많은 팀에서 사람의 평가와 쌍별 선호도(A/B 테스트 승률)를 결합하고, "올바른 필드를 추출했는지" 또는 "정책을 준수했는지"와 같은 작업 기반 검사를 추가합니다. 자동화된 텍스트 측정 지표는 특정 상황에서는 도움이 될 수 있지만, 사용자가 중요하게 생각하는 부분을 놓치는 경우가 많습니다. 명확한 평가 기준과 회귀 테스트 도구가 단일 점수보다 훨씬 더 중요한 경우가 많습니다.

모델이 잡음이 있는 입력에 대해 오류를 일으키지 않도록 견고성 테스트를 실행합니다

실제 사용자는 입력값을 깔끔하게 유지하는 경우가 드물기 때문에 오타, 누락된 값, 이상한 형식, 비표준 유니코드 등을 사용하여 모델을 스트레스 테스트하십시오. 새로운 카테고리, 속어, 센서 또는 언어 패턴과 같은 분포 변화 사례를 추가하십시오. 취약한 동작을 파악하기 위해 극단적인 값(빈 문자열, 매우 큰 페이로드, 범위를 벗어난 숫자)도 포함하십시오. LLM의 경우 프롬프트 주입 패턴과 시간 초과 또는 부분 출력과 같은 도구 사용 오류도 테스트하십시오.

이론에 매몰되지 않고 편견과 공정성 문제를 점검하기

의미 있는 데이터 조각들을 기준으로 성능을 평가하고, 법적 및 윤리적으로 측정이 적절한 경우 그룹 간 오류율과 보정 정도를 비교하십시오. 우편번호, 기기 유형, 언어와 같이 민감한 특성을 간접적으로 나타낼 수 있는 대리 변수를 찾아보십시오. 모델은 전반적으로 정확해 보일 수 있지만 특정 집단에서는 지속적으로 실패할 수 있습니다. 측정한 내용과 측정하지 않은 내용을 기록하여 향후 변경 시 회귀 분석이 슬그머니 다시 도입되는 것을 방지하십시오.

생성형 AI 및 LLM 시스템에 대한 안전 및 보안 테스트를 포함해야 합니다

허용되지 않는 콘텐츠 생성, 개인정보 유출, 중요 영역에서의 오류 발생, 그리고 모델이 정상적인 요청을 차단하는 과도한 거부 행위 등을 테스트해야 합니다. 특히 시스템이 도구를 사용하거나 콘텐츠를 검색할 때, 프롬프트 주입 및 데이터 유출 시도도 포함해야 합니다. 체계적인 워크플로는 다음과 같습니다. 정책 규칙을 정의하고, 테스트 프롬프트 세트를 구축하고, 사람과 자동화된 검사를 통해 점수를 매기고, 프롬프트, 데이터 또는 정책이 변경될 때마다 다시 실행합니다. 일관성은 필수적인 요소입니다.

AI 모델 출시 후 배포 및 모니터링을 통해 오류 및 문제를 파악합니다

섀도우 모드나 점진적 트래픽 증가와 같은 단계적 배포 패턴을 사용하여 전체 사용자 기반이 오류를 발견하기 전에 문제를 찾아내십시오. 입력 드리프트(스키마 변경, 누락, 분포 변화)와 출력 드리프트(점수 변화, 클래스 균형 변화)는 물론 지연 시간 및 비용과 같은 운영 상태를 모니터링하십시오. 수정, 에스컬레이션, 불만 사항과 같은 피드백 신호를 추적하고 세그먼트 수준의 회귀를 관찰하십시오. 변경 사항이 발생하면 동일한 테스트 환경을 다시 실행하고 지속적으로 모니터링하십시오.

참고 자료

[1] NIST - 인공지능 위험 관리 프레임워크(AI RMF 1.0) (PDF)
[2] Mitchell 외 - "모델 보고를 위한 모델 카드"(arXiv:1810.03993)
[3] Gebru 외 - "데이터 세트를 위한 데이터시트"(arXiv:1803.09010)
[4] scikit-learn - "모델 선택 및 평가" 문서
[5] Liang 외 - "언어 모델의 전체론적 평가"(arXiv:2211.09110)

최신 AI 기술을 공식 AI 어시스턴트 스토어에서 만나보세요

회사 소개

블로그로 돌아가기