재현성과 엔드투엔드 프로젝트: 모든 것을 결합

이득:

• 4가지 핵심 요소(시드 고정, 데이터 버전 관리, 배지 동결, 실험 모니터링)로 재현성을 보장하고 동일한 실행을 반복할 때 동일한 결과를 생성하는 능력
• 엔드투엔드 체인에서 모듈의 모든 단계(메트릭, 데이터, 모델, LLM 구성 요소, 평가, 공정성, 보안, 배포, 모니터링)를 결합하는 기능
• 각 정지 지점에서 중요한 결정이 사람의 몫인지 확인하고 감사 가능한 방식으로 프로젝트를 문서화하는 능력

ML 프로젝트의 가장 교활한 실패는 충돌이 아닙니다. "다시는 같은 결과가 나오지 않습니다." 3개월 전에 생산에 투입한 모델의 점수를 현재 재현할 수 없다면 해당 모델을 실제로 제어할 수 없는 것입니다. 이 마무리 단위에서 우리는 재현성을 강화합니다. 즉, 동일한 입력으로 동일한 결과를 안정적으로 얻고 엔드투엔드 프로젝트 분야에서 전체 모듈을 결합하는 능력입니다.

재현성이 어려운 이유

일반 소프트웨어에서는 동일한 코드가 동일한 출력을 제공합니다. ML에는 결과를 결정하는 더 많은 변수가 있습니다.

• 무작위성: 데이터 섞기, 가중치 초기화, 데이터 분할 등은 모두 무작위성에 의존합니다.
• 데이터: 동일한 코드는 데이터 버전이 다른 다른 모델을 생성합니다.
• 환경: 라이브러리 버전, 하드웨어(CPU/GPU), 심지어 운영 체제도 결과를 변경할 수 있습니다.
• 숨겨진 사례: 저장되지 않은 하이퍼파라미터, 수동 전처리 단계, 언급되지 않은 선택.

재현성은 "있으면 좋은 것"이 아니라 과학적이고 공학적인 필수 요소입니다. 재현할 수 없는 결과는 증명할 수 없는 주장입니다.

재현성의 네 가지 기둥

1. 무작위성을 수정합니다. 데이터 분할, 모델 초기화, 데이터 섞기 등 모든 무작위 시드를 한 곳에 설정합니다. 고정 시드는 "동일한 실행을 반복해도 동일한 결과" 보장의 기본입니다.

2. 데이터 버전을 지정합니다. 각 실험이 수행된 데이터 버전을 기록합니다(단위 2의 데이터 버전 관리). "최신 데이터"는 모호합니다. "데이터 버전 v3, 해시 abc123"이 정확합니다.

3. 배지를 동결시킵니다. 모든 종속성을 정확한 버전에 고정합니다(예: 요구사항.txt의 numpy==1.26.4 또는 컨테이너 이미지와 같은 정확한 버전). "최신 버전"은 언젠가 모든 것을 깨뜨릴 것입니다.

4. 모든 것을 추적합니다(실험 추적). 코드 버전(git commit), 데이터 버전, 모든 하이퍼파라미터, 메트릭 및 출력 구조 등 각 실험에 대해 자동으로 저장됩니다. MLflow, Weights & Biases와 같은 실험 추적 도구는 이를 체계적으로 수행합니다. 등록하지 않으면 "어떤 설정이 가장 좋았는지"라는 질문에 대한 답이 남아 있습니다.

주의: "나중에 기억하겠습니다"는 가장 비용이 많이 드는 오류입니다. 2주 후에는 어떤 시드, 어떤 데이터, 어떤 하이퍼파라미터를 사용했는지 기억하지 못할 것입니다. 자동 추적은 메모리에 대한 의존도를 제거합니다.

약한 접근 / 강력한 접근

약함: "가장 좋은 모델을 찾았습니다. 노트북에 있어요. 점수가 89%인 것 같아요."

Strong: "실험 추적 도구에서 #147을 실행합니다. git commit a3f9c, 데이터 버전 v3(해시 abc123), 시드 42, 등록된 모든 하이퍼 매개변수, 테스트 PR-AUC 0.887. 동일한 명령을 다시 실행하면 조금씩 동일한 결과가 나타납니다. 모델은 레지스트리의 이 실행에 따라 다릅니다."

차이점: 강력한 접근 방식에서는 결과가 메모리를 기반으로 하는 것이 아니라 고정되고 모니터링되는 체인을 기반으로 합니다. 누구나 매번 같은 결과를 얻을 수 있습니다.

엔드 투 엔드 프로젝트: 모듈 조합

이제 전체 모듈을 단일 프로젝트 흐름으로 결합해 보겠습니다. 실제 ML 시스템은 이러한 중지를 거치며 각 중지는 이전 중지를 기반으로 구축됩니다.

1. 문제 정의: 우리는 무엇을 해결하고 있으며 성공을 측정하는 방법(단원 3: 올바른 측정 기준, 비즈니스 컨텍스트). 측정항목과 임계값은 처음부터 명확합니다.
2. 데이터 파이프라인: 수집, 검증, 정리, 누출 없는 파티셔닝, 버전 관리(단위 2).
3. 모델 개발: 훈련, 기준 비교, 교차 검증, 하드 시드(유닛 3 + 이 유닛).
4. LLM 구성 요소(해당하는 경우): RAG(단위 4) 및/또는 에이전트(단위 5) 필요한 경우 미세 조정(단위 6).
5. 평가: 에지 및 보안 사례가 포함된 평가 클러스터, LLM 시스템의 다층 평가(단위 8).
6. 정의 및 윤리 감사: 하위 그룹 분석, 모델 카드, 설명 가능성(단위 10).
7. 보안 감사: 신속한 주입, 개인 정보 보호, 공급망(9부).
8. 배포: 패키징, 점진적 배포, 롤백, 모델 등록(단위 7).
9. 모니터링: 3계층 모니터링, 드리프트 경보(장치 8).
10. 재현성: 전체 체인(이 단위)에 걸쳐 시드, 데이터 버전, 미디어 및 실험 추적.

이 흐름에서 AI는 모든 정류장에서 가속기이자 청사진 생성기 역할을 합니다. 그러나 지표 선택, 데이터 결정, 공정성 우선 순위 지정, 배포 임계값 및 릴리스 승인 등 중요한 결정은 사람의 몫입니다. 이것이 모듈의 본질입니다.

문서화: 미래는 당신에게 감사할 것입니다

좋은 ML 프로젝트는 그 자체를 문서화합니다. 최소한 문제 및 성공 기준, 데이터 원본 및 버전, 모델 선택 및 타당성, 평가 결과(하위 그룹 포함), 알려진 제한 및 위험, 배포 및 검색 절차, 모니터링 계획 등을 작성해야 합니다. 이 문서는 6개월 후에 프로젝트에 복귀하는 사람(아마도 당신일 수도 있음)의 가장 친한 친구입니다.

세 개의 미니 케이스

사례 1 - 결과가 손실되었습니다. 한 엔지니어가 훌륭한 모델을 훈련했지만 시드를 수정하지 않았고 데이터 버전을 저장하지 않았습니다. 그가 직장을 그만뒀을 때, 누구도 그 결과를 재현할 수 없었습니다. 이 모델은 "블랙박스 전설"이 되었고 결국 처음부터 다시 만들어졌습니다. 몇 주가 낭비되었습니다. 교훈: 재현할 수 없는 결과는 존재하지 않는 결과입니다.

사례 2 - 환경 붕괴. 한 팀은 종속성을 수정하지 않았습니다. 라이브러리가 자동으로 업데이트되면 모델 출력이 자동으로 변경되고 생산이 중단되었습니다. 문제를 찾는 데 며칠이 걸렸습니다. 종속성이 고정되고 최종 버전으로 컨테이너화되면 문제가 다시 발생하지 않았습니다. 교훈: 환경을 얼려라.

사례 3 - 모니터링의 힘. 팀은 각 실험을 자동으로 모니터링했습니다. 3개월 후 규제 감사 중에 그들은 "어떤 데이터, 어떤 설정, 어떤 그룹에서 어떤 성능을 얻었습니까?"라는 질문에 답했습니다. 몇 분 안에 전체 녹음이 가능합니다. 점검은 순조롭게 진행되었습니다. 교훈: 모니터링은 단순한 엔지니어링 도구가 아닌 규정 준수 도구입니다.

복사 가능한 템플릿

이 ML 프로젝트에 대한 재현성 검사를 수행합니다.- 모든 임의성 시드가 고정되어 있습니까(분할, 초기화, 셔플)?- 데이터 버전이 관리됩니까?- 종속성이 정확한 버전으로 고정되어 있습니까?- 모든 실험(코드 커밋, 데이터, 초매개변수, 메트릭)이 추적됩니까? 누락된 각 열을 수정하는 방법에 대한 구체적인 단계를 작성하세요. 프로젝트 구조: [설명]

이 엔드투엔드 ML 프로젝트에 대한 계획 뼈대를 생성합니다. 문제: [설명] 문제/메트릭, 파이프라인, 모델, (RAG/에이전트/미세 조정?), 평가, 공정성, 보안, 배포, 모니터링, 재현성 등 다음 중지를 다루고 각 중지에서 인간 결정이 있는 위치를 표시합니다. 각 정류장별 주요 위험 및 검증 단계를 작성합니다.

이 프로젝트에 대한 기술 문서 템플릿을 생성합니다. 섹션: 문제+성공 기준, 데이터(소스+버전), 모델 선택+정당성, 평가(하위 그룹 포함), 알려진 제한+위험, 배포+롤백, 모니터링 계획. 각 섹션에 대해 채워야 할 필드를 질문으로 제공하십시오.

내 실험 모니터링 설정을 확인하세요. git 커밋, 데이터 버전/해시, 모든 하이퍼파라미터, 모든 메트릭, 환경(라이브러리 버전) 등 실행할 때마다 자동으로 저장되나요? 동일한 실행을 다시 실행해도 동일한 결과가 나오나요? 설정: [설명]. 결함과 수정 사항을 나열하십시오.

재현성 열 표

기둥

무엇이 고쳐졌는가

차량 예시

무작위성

모든 씨앗

시드 설정

데이터

데이터 버전/해시

DVC

환경

라이브러리 버전

요구 사항 핀, Docker

모니터링

코드+데이터+설정+메트릭

MLflow, W&B

일반적인 실수

• 씨앗을 고치지 않습니다. 결과는 반복될 수 없습니다.
• 데이터 버전을 저장하지 않습니다. "무슨 데이터로요?" 답변이 없습니다.
• 얼어붙는 중독이 아닙니다. 업데이트하면 모든 것이 자동으로 중단됩니다.
• 실험은 기억에 남겨두세요. 2주가 지나면 아무것도 기억나지 않습니다.
• 중요한 결정은 인공지능에게 맡기세요. 측정항목, 정의, 배포 결정은 사람들에게 맡겨야 합니다.
• 서류 미루기. 미래의 팀(그리고 당신)이 대가를 치르게 됩니다.

요약하면

재현성은 진지한 ML 엔지니어링의 특징입니다. 재현 불가능한 결과는 증명할 수 없는 주장입니다. 무작위성 수정, 데이터 버전, 환경 고정, 각 실험 추적 등 4개의 열이 제공됩니다. 엔드 투 엔드 프로젝트는 이 모듈의 모든 단계(메트릭, 데이터, 모델, LLM 구성 요소, 평가, 공정성, 보안, 배포, 모니터링)를 상호 연결된 체인에 결합합니다. 인공지능은 모든 단계에서 가속기 역할을 하지만 중요한 결정은 인간의 몫입니다. 향후 팀 및 감사를 위해 모든 것을 문서화합니다. 이 분야는 모듈 전체에서 배우는 모든 것을 유지하는 프레임워크입니다.

응용과제

네 가지 재현성 요소(시드가 변경되지 않는지, 데이터 버전이 지정되어 있는지, 환경이 동결되어 있는지, 실험이 추적되는지)에 대해 ML 프로젝트를 확인하세요. 누락된 열을 수정하고 동일한 실행을 두 번 실행하여 동일한 결과를 얻을 수 있음을 증명합니다. 그런 다음 프로젝트의 전체 흐름(10개 중지)을 한 페이지에 출력하고 각 중지마다 "인간의 결정이 있는 위치"를 표시합니다. 마지막으로 짧은 기술 문서 초안을 작성합니다.

체크리스트

• [ ] 모든 무작위성 시드가 수정되었습니다.
• [ ] 각 실험마다 데이터 버전/해시가 기록됩니다.
• [ ] 종속성은 회사 버전(핀/컨테이너)으로 고정됩니다.
• [ ] 각 실험은 자동으로 모니터링됩니다(코드+데이터+설정+측정항목).
• [ ] 같은 실행을 반복해도 같은 결과가 나옵니다.
• [ ] 엔드투엔드 흐름에서 중요한 결정은 인간이 내리는 것을 확인하고 문서화했습니다.

모듈 시험

1. ML 엔지니어로서 워크플로에 인공 지능을 배치할 때 가장 좋은 접근 방식은 무엇입니까?

• A) AI는 위험도가 낮은 비즈니스의 가속기입니다. 측정항목, 데이터, 생산과 같은 중요한 결정은 검증된 상태로 유지되며 사람의 몫입니다. ✔
• B) AI 출력이 좋아 보이면 검증할 필요가 없습니다.
• C) 모델을 생산에 투입하는 결정을 인공 지능에 맡기면 시간이 절약됩니다.
• D) 인공지능은 텍스트 작성에만 유용하며 데이터 및 모델 작업과는 아무런 관련이 없습니다.

설명: AI는 코드, 데이터 다이제스트, 문서 등 위험이 낮고 쉽게 확인할 수 있는 작업을 위한 강력한 가속기입니다. 그러나 측정항목 선택, 교육에 사용할 데이터, 모델을 프로덕션에 적용하는 등 돈, 기밀성, 법적 책임에 영향을 미치는 결정에 대한 책임은 자격을 갖춘 엔지니어와 팀에 있습니다. 각 출력을 검증 없이 사용해서는 안 됩니다.

2. 데이터 파이프라인 시작 부분에 스키마 유효성 검사를 배치하는 이유는 무엇입니까?

• A) 모델의 정확도가 직접적으로 높아지기 때문입니다.
• B) 데이터 버전 관리가 불필요해지기 때문입니다.
• C) 손상된 데이터를 가장 빠르고 저렴한 시점에 잡아서 다음 단계로 유출되는 것을 방지해주기 때문이죠 ✔
• D) 라벨링이 필요 없기 때문에

설명: 손상된 데이터를 조기에 발견할수록 수정 비용이 더 저렴해집니다. 스키마 검증은 라인 시작 부분에서 예상 유형 및 범위를 벗어나는 데이터를 거부함으로써(예: 단위 변경에 따라 가격이 100배 변경됨) 손상된 데이터가 교육이나 생산에 조용히 유출되는 것을 방지합니다. 생산 중에 발견된 동일한 오류는 몇 배 더 비쌉니다.

3. 시간(시계열)과 관련된 문제에서 데이터를 훈련과 테스트로 나눌 때 올바른 접근 방식은 무엇입니까?

• A) 항상 가장 공정한 방법이기 때문에 무작위 분할을 사용합니다.
• B) 시간 분할 사용: 과거를 학습하고 미래를 테스트하여 누출 방지 ✔
• C) 모든 데이터를 훈련과 테스트로 사용
• D) 훈련 전에 테스트 데이터를 확장 매개변수에 통합

설명: 시계열에 대한 무작위 분할은 모델에 프로덕션에서는 결코 발생하지 않는 '미래 예측' 이점을 제공하고 측정항목을 인위적으로 부풀립니다(시간적 누출). 올바른 것은 시간 분할입니다. 과거로 훈련하고 미래로 테스트합니다. 이는 생산을 유지하는 실제 성능을 측정합니다.

4. 양성 클래스 비율이 1.5%인 사기 탐지 모델에서 정확도가 오해를 불러일으키는 이유는 무엇입니까?

• A) 불균형 데이터에서는 정확도가 항상 낮기 때문입니다.
• B) 정확도는 회귀 문제에만 사용할 수 있기 때문입니다.
• 다) 정확도 계산에는 많은 처리 능력이 필요하기 때문에
• D) 다수 계층을 예측하는 하찮은 모델이라도 매우 정확하여 실제 성공을 숨길 수 있습니다 ✔

설명: 불균형 데이터에서는 '모든 것을 부정적이라고 가정'하는 기본 모델도 약 98.5%의 정확도를 얻지만 단 한 건의 사기도 포착하지 못합니다. 따라서 불균형 분류에서는 정확도 대신 정밀도, 재현율, F1 또는 PR-AUC가 사용되며 각 지표는 기본 모델에 따라 해석됩니다.

5. 모델의 지표에 관해 이야기할 때 기준선 비교가 필수적인 이유는 무엇입니까?

• A) 기본 모델은 항상 실제 모델보다 우수하기 때문입니다.
• B) 단순한 기준 모델과 비교했을 때에만 측정 항목이 의미가 있는지 여부가 분명하기 때문입니다 ✔
• C) 기본 모델은 교차 검증을 불필요하게 만들기 때문에
• 라) 모든 보고서에는 법적으로 기본모델이 요구되기 때문에

설명: 메트릭 자체는 좋거나 나쁘지 않습니다. 기본 모델에 따르면 좋기도 하고 나쁘기도 하다. '85% 정확'이라는 문장은 기본 모델이 이미 84%를 얻으면 거의 쓸모가 없고, 50%를 얻으면 완벽하다는 것을 의미합니다. 비교 기준이 없으면 측정항목은 의미가 없습니다.

6. RAG(Retrieval-Augmented Generation) 시스템의 생산 프롬프트에 포함되어야 하는 가장 중요한 보안 요소는 무엇입니까?

• A) 주어진 출처에만 의존하고, 출처가 없으면 '모른다'고 말하고, 출처를 인용하라는 지시 ✔
• B) 가능한 한 길고 창의적인 답변을 생성하도록 모델에 지시
• C) 모델은 자원보다 자체 교육 지식을 우선시합니다.
• D) 명령으로 가져온 문서의 모든 지침을 구현합니다.

설명: RAG의 가장 중요한 지침은 모델에게 주어진 출처에만 의존하도록 지시하고, 해당 정보가 출처에 없으면 '모른다'고 말하고 꾸며내지 않고 출처를 인용하라는 것입니다. 이 트라이어드가 없으면 모델은 맥락을 무시하고 환각을 생성할 수 있으며 답을 확인할 수 없게 됩니다.

7. RAG 시스템은 잘못된 답변을 제공합니다. 진단을 시작하기에 가장 좋은 곳은 어디입니까?

• A) 먼저 가져오기 측정(Recall@K): 올바른 제품이 도착합니까? ✔
• B) 즉시 더 큰 모델로 교체하십시오.
• C) 프롬프트를 무작위로 변경하고 계속 시도합니다.
• D) 미세 조정을 통해 모든 문서를 모델에 포함

설명: RAG의 가장 약한 링크는 일반적으로 프로덕션이 아닌 가져오기입니다. 올바른 부분을 가져오지 않으면 프롬프트가 아무리 개선되더라도 모델은 해당 정보를 생성할 수 없습니다. 따라서 먼저 Recall@K를 측정하여 올바른 부품이 도착했는지 확인합니다. 가져오기가 양호하면 생산 및 프롬프트가 검사됩니다.

8. 에이전트에게 도구를 제공할 때 사람의 승인 뒤에는 어떤 조치가 있어야 합니까?

• A) 없음; 에이전트는 모든 작업을 자율적으로 수행할 수 있어야 합니다.
• B) 데이터 읽기, 검색 등 되돌릴 수 있는 작업만
• C) 송금, 삭제, 전송 등 되돌릴 수 없거나 영향이 큰 행위 ✔
• D) 계산만 포함하는 작업

설명: 작업은 위험 수준에 따라 구분됩니다. 초안 읽기, 검색, 계산, 생성과 같은 검색 가능한 작업을 자율적으로 수행할 수 있습니다. 그러나 송금, 이메일 전송, 데이터 삭제, 주문 등 되돌릴 수 없거나 영향이 큰 작업에는 사람의 승인이 필요합니다. 취소할 수 없는 모든 조치는 동의를 받아야 합니다.

9. 간접 즉각 주입의 위험에 대비한 최선의 설계 접근 방식은 무엇입니까?

• A) 시스템 프롬프트에 '잘못된 지침을 무시하세요'라는 한 문장만 추가하면 충분합니다.
• B) 외부 콘텐츠의 지침에 의존하여 모델에 더 많은 권한을 부여합니다.
• 다) 주사를 예방할 수 없기 때문에 예방 조치를 취하지 않음
• D) 외부 콘텐츠를 신뢰할 수 없는 데이터로 격리하고 최소한의 권한, 승인, 출력 제어로 계층적 방어 구축 ✔

설명: 웹페이지, 문서, 이메일 등 에이전트나 RAG가 처리한 외부 콘텐츠는 신뢰할 수 없는 데이터이며 비밀 지침이 포함될 수 있습니다. 올바른 접근 방식은 계층화된 방어입니다. 명확한 구분 기호를 사용하여 외부 콘텐츠를 '명령이 아닌 데이터'로 격리하고, 최소한의 권한을 적용하고, 취소할 수 없는 작업을 사람의 승인에 바인딩하고, 출력을 감사합니다. 한 줄의 지침만으로는 충분하지 않습니다.

10. 문제를 미세 조정으로 해결해야 할지 RAG로 해결해야 할지 결정할 때 주요 차이점은 무엇입니까?

• A) 정보 문제는 RAG로 더 잘 해결되고, 동작/형식 문제는 미세 조정으로 더 잘 해결됩니다. ✔
• B) 모든 문제는 항상 미세 조정을 통해 해결되어야 합니다.
• 다) RAG는 코드 생성에만 사용되고, Fine-tuning은 번역에만 사용됩니다.
• D) Fine-tuning은 항상 RAG보다 저렴하고 빠르게 업데이트 가능

설명: 모델에 새로운 정보를 가르치는 데 있어 미세 조정은 약하고 위험합니다. 그러나 행동, 형식, 어조 및 스타일을 가르치는 데는 강력합니다. '모델 회사는 우리 데이터를 모른다'는 정보 문제이며 RAG에 속합니다. '모델이 항상 엄격한 형식으로 출력되도록 합니다'는 행동 문제이자 미세 조정의 후보입니다. 또한 미세 조정 전에 프롬프트 및 소수의 샷을 소비해야 합니다.

11. 새로운 모델을 생산에 투입할 때 안전한 배포를 위해 필수 사항은 무엇입니까?

• A) 모델이 테스트 결과 좋으면 바로 100% 트래픽으로 오픈하세요.
• B) 배포 후 모니터링을 전혀 설정하지 않음
• C) 단계적 배포(섀도우/카나리아) 및 사전 테스트된 롤백 계획 ✔
• D) 평가 기준을 충족하지 못하더라도 모델을 공개하는 것

설명: 새 모델을 모든 트래픽에 직접 여는 것은 위험합니다. 잘못되면 모두가 영향을 받습니다. 올바른 점은 점진적인 배포(섀도우, 카나리아)이며 모든 배포에는 테스트된 롤백 계획이 있다는 것입니다. 회수 계획이 없으면 배포가 완료되지 않습니다. 몇 분 내에 이전 버전으로 되돌릴 수 있으므로 모델이 프로덕션에서 예기치 않게 작동할 때 사용자를 보호할 수 있습니다.

12. ML 모델이 프로덕션에서 어떻게 '조용히' 실패할 수 있으며 이를 포착하는 방법은 무엇입니까?

• A) 모델이 붕괴됩니다. 서버 로그는 이것을 보여줍니다
• B) 실수 없이 잘못된 예측을 함으로써; ✔ 운영, 입력 및 출력 계층 모니터링을 캡처합니다.
• C) 모델은 결코 자동으로 실패할 수 없으며 항상 경보를 울립니다.
• D) 지연 시간을 모니터링하는 것만으로도 성능 저하를 포착하기에 충분합니다.

설명: 충돌이나 오류 없이 잘못된 예측을 생성함으로써 모델이 실패할 수 있습니다. 그 주된 이유는 데이터 드리프트와 개념 드리프트입니다. 운영 지표(지연 시간, 오류율)를 모니터링하는 것만으로는 충분하지 않습니다. 입력 분포와 출력/예측 분포도 모니터링해야 합니다. 입력 드리프트는 실제 결과가 지연되는 경우 조기 경고를 제공합니다.

13. LLM 시스템을 평가하기 위해 LLM을 판사로 사용할 때 필수적인 원칙은 무엇입니까?

• A) LLM 심판은 항상 정확하므로 사람의 검증은 필요하지 않습니다.
• B) 심판은 답변 길이에만 기초하여 결정을 내려야 합니다.
• 다) 심판을 사용하는 경우 규칙 기반 통제 및 인간 평가를 완전히 폐기해야 합니다.
• D) 심사위원 점수는 사람이 라벨링한 샘플을 사용하여 보정되어야 하며 신뢰되기 전에 편견이 측정되어야 합니다. ✔

설명: LLM 심판도 모델입니다. 환각적이고, 편파적이며(길고 자신감 있는 답변을 선호함), 일관성이 없을 수 있습니다. 따라서 심판 점수는 인간이 라벨링한 샘플을 사용하여 보정되어야 하며 생산 결정이 내려지기 전에 체계적 편향을 측정해야 합니다. 검증되지 않은 심판은 잘못된 자신감을 준다.

14. 모델 편향을 평가할 때 전반적인 정확도를 보는 것이 왜 부적절합니까?

• A) 항상 최악의 그룹의 성과를 반영하기 때문에 전체적인 정확도는 충분하다.
• B) 전체 정확도만으로는 하위 그룹 간의 체계적인 차이(숨겨진 변별)를 모호하게 할 수 있으므로 충분하지 않습니다.
• 다) 정확도는 편향과는 아무런 관련이 없는 척도이기 때문에
• D) 편향은 모델에서만 발생하며 데이터와는 아무런 관련이 없습니다.

설명: 전반적인 정확성으로 인해 하위 그룹 간의 체계적인 차이가 모호해질 수 있습니다. 예를 들어 전체 정확도는 88%이지만 재현율은 한 그룹에서는 91%, 다른 그룹에서는 67%일 수 있습니다. 모델은 체계적으로 해당 그룹을 놓치게 됩니다. 따라서 모델은 하위 그룹(인구통계/세분화)을 기반으로 평가되어야 하며 어떤 정의의 우선순위를 정해야 하는지는 이해관계자와 함께 결정해야 합니다.

15. ML 결과를 재현하려면 무엇을 함께 수정해야 합니까?

• 가) 모델명, 사이즈, 가격, 출시일만
• B) GPU 브랜드와 인터넷 속도만
• C) 모델의 최종 정확도 점수만; 나머지는 메모리에 보관할 수 있습니다
• D) 무작위성 시드, 데이터 버전, 환경(종속성 버전) 및 실험 추적 ✔

설명: 재현성은 무작위 시드 수정, 데이터 버전 관리(버전/해시), 환경 동결(정확한 라이브러리 버전/컨테이너), 각 실험 추적(코드 커밋, 데이터, 하이퍼 매개변수, 메트릭)이라는 네 가지 요소를 통해 달성됩니다. 이 체인이 없으면 동일한 결과를 재현하는 것이 불가능합니다. 재현 불가능한 결과는 입증할 수 없는 주장입니다.