Direct Preference Optimization (DPO)

DPO는 LLM에서 사용하는 튜닝 방법입니다.

GPT는 Pretrained 단계를 거쳐 Fine-tuning에서 RLHF라는 사람의 피드백에 의한 강화학습을 합니다.

PPO라는 것을 쓰는데요.

채점 모델을 만들어 채점모델이 모델이 생성한 텍스트를 채점하게 해서 그걸 다시 학습으로 돌려서 모델의 성능을 개선하는 방법입니다.

대표적으로 ChatGPT가 이 방법을 사용합니다.

DPO는 인간의 피드백없이 그냥 선호하는 데이터로 모델을 튜닝하는 방법입니다.

일반 fine-tuning하고 뭐가 따른지가 궁금할텐데 일반 fine-tuning은 인간의 피드팩 데이터를 넣지 않을 수도 있고 넣을 수도 있만 DPO는 인간의 피드백을 그 자체로 학습에 사용하는 방법입니다.

대표적으로 Llama3가 이 방법을 사용합니다.

데이터브릭스 데이터 인텔리전스 데이 서울 2024

제목이 좀 기네요.

데이터브릭스 이벤트행사에 다녀왔습니다. 이 이벤트는 컨퍼런스 형식입니다.
모든 세션을 다 듣지 못했지만 들은 세션의 내용을 가지고 종합하면

좋았던 점

  1. 궁금한 것에 대해서 뭘 하고 있는지 어떻게 대응하고 있는지 잘 설명해줬다.
  2. 내용이 알찼고 섬세했다.
  3. 사용자의 LLM의 생성과 튜닝에 대해 준비가 어떻게 되어 있는지 잘 알려주고 있다.
  4. LLM을 응용한 여러가지 편의 기능과 최적화 기능 들은 인상적이었다.

아쉬운 점

  1. 설명할 내용이 많았는지 스피커들의 스피치속도가 빨라서 정식 없었다.
  2. 성공사례 발표가 많지 않았고 와닿지 않았다. 이건 다른 컨퍼런스도 마찬가지이지만 이게 아쉽네요.
  3. 협찬업체가 적어서 경품 부쓰가 적었다.

이렇습니다.

느낌은
무료 컨퍼런스임에도 매우 알차고 괜찮어서 만족스러웠습니다.
데이터브릭스 직원분들 능력이 좋은 것 같습니다.
사람이 많아서 많이 정신 없고 피곤했습니다. 인기 실감

Iphone에서 MLX로 Llama3 로딩 성공

iPhone에서 Llama3 8B 모델을 구동시키는데 성공했다는 뉴스가 나오자마자 인터넷 곳곳에서 따라하기에 성공사례가 연달아 나오고 있습니다.

정리하자면

애플 실리콘은 애플이 독자적으로 만든 반도체입니다. 그래서 인텔, AMD의 프로세서와 Nvidia GPU용으로 만들어진 모델이 그냥 작동하지 않습니다. Llama3도 마찬가지입니다. 돌아간다고 하더라도 효율이 문제인데 그래서 애플은 애플 실리콘에서 작동하는 자체 고속행렬연산 프레임워크인 MLX라는 것을 만들었습니다.

Llama3를 애플의 아이폰, 아이패드에서 돌리려면 MLX에서 돌도록 해야 제대로 되는데 그걸 매우 쉽게 했다는 것입니다.

아이폰 다음 모델에는 거의 온디비이스 AI 탑재될 것이 분명합니다.

온디바이스AI는 디바이스내에서 외부 통신없이 자체 능력만으로도 AI 프로세싱을 처리할 수 있는 것을 말합니다.

세상이 바뀌는 순간이 매우 빠르게 오고 있다는 느낌이 듭니다.

다음은 Llama3 8B를 iPhone 15 Pro Max에 설치하는 방법입니다. 편의상 영문 그대로 올립니다.

UPDATE: Successfully ran Llama3 8B Instruct on iPhone 15 Pro Max

Steps:

1. Install LLM Farm

2. Download Llama3 8B Instruct GGUF from Huggingface

3. Import & Run the model in LLM Farm

LLM Farm: https://llmfarm.site

Model File: https://huggingface.co/FaradayDotDev/llama-3-8b-Instruct-GGUF… Detailed steps coming soon!

Llama3의 성능 비교표

스펙과 성능에 대한 비교표입니다.

전반적으로 GPT-4가 가장 성능은 뛰어난 것으로 평가 받고 있습니다.
비용효율과 사용성 측면을 고려하면 성능을 조금 포기하고 모델의 크기와 같은 하드웨어적 특징을 고민해야 하기때문에 용도에 맞는 것을 선택해야 하겠습니다.

아무리 GPT가 성능이 좋아도 오픈소스경량 LLM인 Llama3의 매력을 무시하기는 어려울 것 같습니다.

LLM AI의 할루시네이션을 극복하려면?

할루시네이션은 언어 AI 모델(LLM)이 사실이 아닌 엉뚱한 소리를 사실 처럼 확증적으로 말하는 것을 말합니다.

할루시네이션(Hallucination)은 거짓말과는 다른데 거짓말은 의도적으로 진실을 말하지 않고 다르게 말하는 것인지만 AI는 진실과 거짓을 구별하지 못하고 의식이 없기 때문에 의도라는 것 자체도 없습니다.

그래서 틀린 사실도 매우 당연하다는 듯이 사실처럼 생성하기도 합니다. 그런데 AI가 생성한 텍스트가 진실인지 아닌지 알아차릴 수 있는 지식이 없다면 AI의 거짓을 착각해서 믿게 됩니다.

LLM은 할루시네이션 극복을 하기 힘들다

LLM 의 구조적인 특징으로 인해 할루시네이션은 AI모델 자체로는 완벽하게 극복이 안됩니다. 나중에 개선된 모델이나 다른 방법이 나온다면 가능하겠지만 지금은 아닙니다.

LLM의 작동방식은 확률적으로 입력한 단어의 다음 단어가 나올 것을 예측하고 그것을 매우 긴 단어의 연결에 대해 연속적으로 행하는 모델이기 때문입니다. 깊은 고찰이나 인과적 사실 검증, 사실 의심 같은 인간의 고급 사고 능력이 LLM에게 없기때문입니다.
그리고 인간도 할루시네이션이 있습니다. 잘못 알고 있는 것을 잘 알고 있다고 착각하고 우기는 것 말입니다. 하지만 인간은 자신이 틀렸을지도 모른다는 의심 또한 하기 때문에 현명한 사람들은 할루시네이션이 거의 없습니다.

학습량을 마구 늘리면 할루시네이션이 극복되지만 얼마까지 늘려야 눈치채지 못할 만큼 줄어드는지는 알 수 없습니다.

RAG (Retrieval Augmented Generation)

현재 LLM의 할루시네이션을 극복하는 거의 유일한 방법은 RAG (Retrieval Augmented Generation)을 사용하는 것입니다.

RAG는 AI가 대답할 때 질문과 관련이 있는 자료를 찾아서 참고해서 대답하게 만드는 방법입니다.

간단하게 말하면 AI가 대답하기 전에 벡터데이터베이스를 뒤져서 자료를 찾은 다음에 대답할 때 참고하도록 합니다. 당연히 벡터DB에는 사실만 저장되어 있어야 합니다.

RAG는 AI모델에 검색 엔진을 결합한 것

RAG에서 사용하는 DB또는 검색엔진 꼭 벡터 기반일 필요는 없습니다. 텍스트기반의 검색엔진인 엘라스틱 등을 사용해도 되고 DB를 사용해도 됩니다. 벡터 기반을 사용하는 이유는 벡터기반이 렉시컬 기반이 아닌 컨텍스트 기반으로 매치가 가능하기 때문입니다. 전통적인 검색엔진이나 DB는 단어들이 얼마나 일치하는지를 찾는 방법으로 쓰지만 벡터 기반은 의미가 비슷한지를 확인하는 구조로 되어 있습니다.

ASI모델을 사용할 때 RAG로 해결해야 하는 문제는 프롬프트와 관련이 있는 또는 챗봇의 경우 사용자가 질의한 것가 관련이 있는 것만 잘 추출해서 지시어로 넣어주어야 한다는 것입니다.
잘못된 검색 결과는 의미가 일치하지 않는 콘텐츠를 지시어로 넣어주면 할루시네이션이 생기거나 조금 엉성하고 엉뚱한 답을 하게 됩니다.

RAG가 정말 할루시네이션을 해결 해주는가?

다른 구조의 모델이 나오거나 파인튜닝을 엄청나게 많이 하지 않으면 RAG외에는 할루시네이션을 없애는 방법은 없습니다.

RAG를 위해서 필요한 것

  • 벡터검색엔진
  • 벡터검색엔진에 넣을 콘텐츠
  • RAG가 적용되어 빌드된 모델
  • 좋은 청킹 방법

여기서 가장 중요한 것은 2번입니다. RAG가 적용된 모델은 없어도 지시어로 충분히 해결할 수 있지만 있다면 더 매끄러운 결과를 보여줍니다.

청킹은 매우 중요한 기술인데 콘텐츠를 어떻게 잘라서 검색엔진에 추가할지에 대한 방법입니다. RAG에서 가장 중요한 노하우라고 할 수 있습니다.

좋은 방법은 잘 알려지지 않고 각 기업의 내부에서만 사용되고 있습니다. OpenAI도 RAG를 지원하지만 어떤 방법으로 청킹을 하는지에 대해서는 오픈하고 있지 않습니다.

RAG의 미래는?

AI모델을 실시간으로 빌드할 수 있는 방법은 없습니다. 모델을 만드는데 계산양이 매우 많기 때문입니다. 최신 지식을 인간처럼 곧바로 업데이트하지 못합니다.

유일한 방법은 어디선가 사실을 가져와서 모델내에 실시간으로 넣어주는 방법뿐입니다.

그래서 당분간은 RAG가 중요하게 쓰일 수 밖에 없습니다.

Llama3 발표

메타(Meta, 페이스북)의 LLaMa3 가 공개되었습니다.

앤드류 응 교수는 출시되지 마자 다음과 같은 멘트를 했습니다.
Meta released Llama 3 on my birthday! 🎂 Best present ever, thanks Meta! 😀

생일인데 Llama3이 발되었다고 좋은 선물이라고 하는데, 조금 오버입니다만 오버를 할 정도로 대단한 뉴스라는 것을 알 수 있습니다.

다른 많은 엔지니어들도 코멘트를 남겼으며 벌써 테스트를 해본 사람까지 있었습니다.

현재까지의 평가는 작은 사이즈에 비해 기존 모델과 비슷한 품질을 보여줘서 상당히 고무적이라는 평가입니다.
특히 Llama3의 가장 작은 모델은 8B모델은 LLama2의 7OB모델보다 MMLU 점수가 더 높았습니다.

MMLU는 언어모델의 지식 범위와 깊이를 측정하는 기준입니다.

LLama3에 대한 간단한 요약입니다.

  1. 24000개 H100 GPU가 붙은 클러스터 2개를 이용해서 모델 빌드
  2. 기존과 구조는 바꾼것 없이 데이터만 더 넣어서 성능 개선
  3. 제공 모델 크기는 8B, 70B, 400B+ (400B+은 아직 학습 중)
  4. 동급에 가장 리더보드 스코어가 높음
  5. 학습량 15T 토큰량. 5% 정도의 30개국어. 구글의 전세계 색인 문서의 1/4 수준
  6. 인스트럭션 러닝에도 많은 투자가 있었음. 즉 지시에 잘 따르고 말 잘듣게 학습시킴
  7. Azure에서 API, 웹페이지에서 모델 다운로드 가능
  8. 한국어 능력은 LLaMA2에 비해 크게 나아지지 않음. 다국어 학습량이 매우 부족해서 추가 필요
  9. 튜닝 후 배포할 땐 llama3- 라고 꼭 적어야함

아직 한국어는 좋지 않지만 조만간 튜닝이 된 파생 모델이 쏟아져 나올 것입니다.

이제 LLM은 ChatGPT가 출시된 첫번째 격동기에서 두번째 격동기에 접어들었습니다.

MMLU – 대규모 멀티태스크 언어 이해력 평가

MMLU: 대규모 멀티태스크 언어 이해력 평가

https://paperswithcode.com/sota/multi-task-language-understanding-on-mmlu

인공지능의 평가 및 비교를 볼 때 MMLU라는 지표를 자주 보게 됩니다.

MMLU(Massive Multitask Language Understanding)는 인공지능 모델의 지식 습득 능력을 종합적으로 평가하기 위한 벤치마크 중 하나입니다. 이 평가는 인공지능이 어느 정도까지 다양한 지식 영역을 이해하고 있는지를 측정하기 위해 고안되었습니다.

즉, 인공지능이 얼마나 다양한 지식을 가지고 있는지 평가하는 지표입니다.

MMLU의 특징

  • 다양한 주제 범위: MMLU는 STEM(과학, 기술, 공학, 수학), 인문학, 사회과학 등 약 57가지의 다양한 주제에 대한 이해를 평가합니다.
  • 다지선다 형식의 문제: 평가는 주로 다지선다 형식의 문제를 사용하여, 모델이 주어진 정보를 바탕으로 가장 적절한 답을 선택하도록 요구합니다.
  • zero-shot 및 few-shot 학습 환경: 이 벤치마크는 특히 모델이 사전에 해당 주제에 대한 특정한 학습 없이도 얼마나 잘 수행할 수 있는지(zero-shot), 또는 매우 제한된 데이터로 학습한 후의 성능(few-shot)을 평가합니다.

현재 성과와 리더보드

최신 인공지능 모델들의 성능은 Papers with Code 웹사이트의 MMLU 벤치마크 섹션에서 확인할 수 있습니다. 현재 GPT-4가 86.4%의 높은 정확도로 최고 성능을 기록하고 있습니다.

자료 및 리소스

  • 공식 GitHub: MMLU의 구현과 관련된 자세한 정보, 데이터셋 접근 및 사용 방법 등은 GitHub 페이지에서 확인할 수 있습니다. 이 페이지에는 또한 연구자들이 자신의 모델을 벤치마크에 적용해 볼 수 있는 지침과 도구들이 제공됩니다.

MMLU의 중요성

MMLU는 단순히 특정한 지식 영역에서의 모델 성능을 측정하는 것을 넘어, AI 모델이 얼마나 광범위하고 다양한 주제를 이해하고 있는지를 평가함으로써, 인공지능 기술의 종합적인 이해력과 다재다능성을 테스트합니다.

요약하면

MMLU는 현재 AGI를 만들어가는데 중요한 평가지표입니다.

OpenAI Assistant API v2 달라진점

OpenAI Assistant API는 openapi에서 모델을 활용해서 개발하게 하는 API인데 2023 말에 Beta V1을 발표했습니다.

하지만 몇가지 단점과 한계, 버그가 있었는데 새 버전 2가 발표되었습니다.

간략한 요약은 다음과 같습니다.

2024년 4월 발표. OpenAI Assistants API의 기본 버전에 새로운 기능과 개선 사항을 넣어 OpenAI-Beta: assistants=v2 릴리즈로 만듦

  • 파일 검색 도구 개선: ‘file_search’ 도구는 이전보다 500배 많은 최대 10,000개 파일을 처리할 수 있습니다. 이 도구는 검색 속도가 빠르고, 멀티 스레드 검색을 통한 병렬 쿼리를 지원하며, 향상된 재정렬 및 쿼리 재작성 기능을 제공합니다. 기능 개선 및 신규 지원
  • 벡터 스토어 객체 도입: 파일이 벡터 스토어에 추가되면 자동으로 파싱, 청킹, 임베딩되어 검색 준비가 완료됩니다. 벡터 스토어는 여러 보조기와 스레드에 걸쳐 사용할 수 있어 파일 관리와 결제가 간소화됩니다. 신규 지원
  • 토큰 사용 최대치 제어: 실행할 때 사용하는 최대 토큰 수를 제어할 수 있어 토큰 사용 비용을 관리할 수 있습니다. 또한, 각 실행에서 사용되는 이전/최근 메시지의 수에 대한 제한을 설정할 수 있습니다. 신규 지원
  • 도구 선택 매개변수 지원: 특정 실행에서 특정 도구(예: file_search, code_interpreter 등)의 사용을 강제할 수 있는 ‘tool_choice’ 매개변수를 추가했습니다. 신규 지원
  • 역할이 보조인 메시지 생성 가능: Threads에서 사용자 정의 대화 이력을 생성할 수 있습니다.
  • 보조 및 실행 객체의 모델 구성 매개변수 지원: 인기 있는 모델 구성 매개변수(온도, 응답 형식(JSON 모드), top_p 등)를 지원합니다. 신규 지원
  • 미세 조정 모델 사용 가능: 현재는 gpt-3.5-turbo-0125의 미세 조정 버전만 지원됩니다. 신규 지원
  • 스트리밍 지원: Assistants API가 이제 스트리밍을 지원합니다. 신규 지원
  • 스트리밍 및 폴링 도우미 추가: Node 및 Python SDK에 여러 스트리밍 및 폴링 도우미를 추가했습니다. 신규 지원
  • 마이그레이션 가이드 제공: 최신 버전의 Assistants API로 도구 사용을 마이그레이션하는 방법에 대해 자세히 알아볼 수 있습니다. 신규 지원

데이터 사이언스의 스킬 범위

데이터 사이언스에 대한 좋은 도표가 있어 공유합니다.

그림처럼 Python만 써야 하는 것은 아닙니다. Python은 데이터과학을 하는데 필요한 컴퓨터 기술을 통칭한다고 생각하면 됩니다.

데이터분석과 데이터과학을 구별하지 못할 때가 많은데 차이점은 도메인 날리지(업무 지식)

이 이야기는 데이터과학이라는 용어가 생겼을 때부터 데이터과학의 정의에 항상 설명되어 있는 내용입니다.

데이터과학은 모든 기술을 업무 문제를 해결하는데 집중합니다.

반면 데이터분석은 현재 데이터의 상태를 확인하고 검증하는 것으로 끝냅니다.

현실의 문제를 해결하려는 목적없이 기계학습 모델만 만들고 싶어하면 단순한 ML엔지니어이고 통계적 분석만 한다면 단순한 분석가가 되는 것입니다.

하지만 복잡하고 풀기 곤란한 현실의 비즈니스 문제에 개입하고 싶지 않으려는 사람들이 많은데 그 사람들은 도메인 날리지를 제외하고 나머지 부분만을 데이터과학이라고 주장합니다.

A/B 테스트를 95% 대 5% 비율로 해도 괜찮을까?

답부터 말하면

안 괜찮습니다.

사실 비율 보다는 샘플의 크기가 중요하지만 어쨌든 95%대 5%로는 A/B테스트는 문제를 만듭니다.

A/B테스트 흔히 온라인서비스에서는 버킷테스트라고 하는데 이 테스트에서 A와 B 두개의 샘플의 수가 서로 불균등하다고 하면 대부분의 통계학자들은 표정이 안좋아지며 심각하게 생각하지만 개발자들은 별것 아니라고 생각합니다.

이게 논란의 여지가 항상 있는 것이므로 조심스럽지만

A/B테스트는 통계학에서 나온 것이므로 통계학자들이 더 잘 알것이므로 이쪽을 더 신뢰하는 것이 맞습니다. 통계학자들은 경험과 이론을 통해 그게 왜 문제인지 설명하지만 개발자들은 그런 설명을 하지 않습니다.

개발자들은 근거를 말하지 않지만 통계학자들은 근거를 말합니다.

A/B 테스트, 버킷테스트는 여러개의 샘플에 각기 다른 처치(작용 또는 변화를 주는것)를 하고 그게 정말 효과가 있는 지 살펴보는 것이라는 것을 기억해야 합니다.

A/B 테스트는 샘플이 중요하다

A/B 테스트는 통계학에서 다루는 실험 운영 방법입니다. 실험계획법이라는 통계학 과목이 있습니다. 과목이 따로 있을 만큼 만만한 것이 아닙니다

통계학은 샘플을 매우 중요하게 생각합니다.
적어도 통계학파 중에 빈도주의자(Frequatist)들은 매우 중요하게 생각합니다.
그와 비교되는 다른 학파들도 있지만 이건 다음에 얘기하겠습니다.

샘플은 어떤 집합에서 일부를 떼어 낸 것을 말합니다.

통계학에서 샘플을 중요하게 생각하는 이유는 샘플을 통해서 원래 전체 데이터의 특성을 파악해야 하기 때문입니다. 샘플을 사용해서 원래 집합을 알아내려고 하는 이유는
대부분의 전체 데이터를 다 확인하는 것은 불가능하기 때문입니다.

“빅데이터 플랫폼도 있는데 전체데이터 확인을 왜 못하냐?” 라고 물어볼 수 있습니다. 잘못 이해한 것인데 거기서 말하는 전체데이터는 실제로 알고자 하는 사실을 얻어야 하는 대상의 전체가 아니기 때문입니다.
예를 들어서
어제까지 가입한 쇼핑몰 전체의 고객 데이터는 전체 데이터가 맞긴 하지만 쇼핑몰의 고객 전체는 아닙니다. 앞으로도 가입할 사람이 있을 것이고 탈퇴할 사람도 있을 것이기 때문입니다. 그런 관점에서 통계학에서 생각하는 전체 데이터를 얻는 것은 불가능하다고 할 수 있습니다.

어제까지 전체 고객 데이터는 통계학에서는 전체데이터가 아닌 그냥 매우 큰 샘플데이터입니다.

A/B테스트에서 A와 B는 각각 전체 모집단에 대한 샘플이라고 봅니다.

A/B테스트에서 샘플 수가 균등하지 않으면 통계 검정을 할 수 없는가?

그래서 A/B의 비율이 5:5로 균등하지 않으면 정확한 비교를 하지 못하는가?
라는 의문이 있을 것이다.
할 수는 있습니다.
다만 꽤 복잡한 방법을 써야 하고 정확하지 않은데다 선택한 검정 자체를 적용하는 것 자체가 맞는지 안맞는지는 확인하려고 하는 것은 노련하고 뛰어난 통계학자도 매우 어렵게 하는 것입니다.

간단하게 공식 몇 개 넣어서 계산하면 되는 것이 아닙니다.

그래서 이렇게 불균등한 샘플 비교를 최대한 피해야 합니다.

샘플 간의 성능 비교를 한다면 균등한 것이 낫다

균등하지 않은 샘플로 샘플의 불균형성을 극복하면서 테스트하는 것 보다 균형 샘플을 만들어서 테스트하는 것이 더 쉽고 돈도 더 적게 듭니다. 균등하지 않은 샘플로 서로를 비교하는 것은 일반적으로 실험계획이 잘못된 경우나 하지 못한 후시 테스트일 가능성이 높습니다.

A/B 테스트와 관련되었대고 하면 무조건 샘플 수를 맞추고 시작합니다.

불균등한 것이 뭐가 그리 문제인가?

샘플이라고해서 그렇게 거창한 것은 아닙니다.
A그룹에서 추출한 숫자들, B그룹에서 추출한 숫자들을 비교하는 것인데
샘플이 균등하지 않으면 크게 달라질 수 있는 것이 파라미터(모수, parameter)인데 평균과 분산입니다.
A/B테스트는 A와 B의 평균과 분산이 실험 후에 많이 차이가 나는지 아닌지를 보는 것입니다.
이때 샘플의 수 그러니까 숫자의 갯수가 많이지면 숫자의 갯수가 적을 때 보다 분산은 무조건 커집니다.
이게 자연적인 현상입니다.
그래서 샘플의 수가 50대 50으로 균등하지 않으면 샘플 수로 인해서 생길 수 있는 기본적인 분산의 차이를 보정하고 검정을 해야 하는데 보정이 매우 어렵고 보정을 해도 정확도가 떨어집니다.

실험결과를 잘못 해석하게 됩니다.
이런 결과로 결정을 하면 비즈니스에 큰 실패를 가져올 수 있습니다.

실험 자체를 잘못하는 것은 그 실험을 없었던 것으로 하면 되기 때문에 피해가 덜하지만
결과를 잘못해석하면 틀렸다는 것 자체를 의심하지 않기 때문에 큰 문제를 생깁니다.

한쪽을 언더샘플링(Under sampling)을 하면 어떤가?

크기(갯수)가 다른 두 샘플들이 있을 때 크기가 적은 샘플 수만큼을 크기가 큰 색플에서 도려내서 숫자를 맞추는 것이 언더샘플링(under sampling)이라는 방법입니다.
간단히 말하면
그냥 큰 쪽을 작은쪽의 크기 만큼 잘라서 맞추는 것입니다.
보통 자를 때 무작정 자르지 않고 랜덤으로 샘플링을 합니다. (확실하게 랜덤으로 분할 한 것과 같은 것으로 분할 할 수 있으면 랜덤 샘플링을 하지 않아도 됩니다. 이건 따로 설명하지요)

어쨌든 이러면 괜찮지 않은가?
라고 생각할 수 있는데
이것도 괜찮지 않습니다.

언더샘플링을 하는 순간 샘플의 모집단이 달라지게 됩니다. 샘플이 뽑힌 것의 자유도라는 것도 다르기 때문에 두 샘플은 비교하기 어렵게 됩니다.
부모가 낳은 형과 동생을 비교하다가 형과 동생의 아들인 조카를 비교하는 꼴인 것이다.
부트스트래핑을 쓰면 하게되면 이러 불균형에서 샘플링을 통해 문제를 해결할 수 있지만 역시 그 보다는 샘플 수를 맞추는게 편하고 낫습니다.

대부분의 버킷시스템은 샘플 수를 맞추도록 설계되어 있다

빅테크 회사들의 버킷시스템이 존재합니다. A/B테스트를 할 수 있도록 플랫폼이 갖춰줘 있고 샘플의 수 등을 수정할 수 있습니다.
저런 대형 기업들의 시스템에서도 기본으로 두 비교군의 샘플 수를 맞추도록 설계되어 있습니다.
다른 대기업들도 모두 마찬가지입니다.
그들은 왜 모두 그렇게 하는지 생각을 해보기로 합시다.
그냥 그렇게 하거나 단순한 전통이어서 그렇게 하는 걸이다 아닙니다.
그것이 통계적이고 과학적으로 실험의 결과를 오해석하지 않는 최선의 방법이기 때문입니다.

통계학자들이 무능하고 실력이 없으면서 복잡해 보이기 좋아하기 때문에 저렇게밖에 못한다고 생각할 수도 있지만.

버킷시스템에서는 언더샘플링이 가능하다

추가로 말하면 대부분의 버킷시스템은 사용자의 ID 또는 비식별ID를 비트연산을 통해 그룹을 나눠서 관리하도록 되어 있습니다.

따라서 많은 쪽의 비트 몇개를 무시해서 언더샘플링을 하면 샘플비교를 할 수 있습니다.
조금 복잡하니 자세한 것은 따로 설명하겠습니다.

참고

A/B테스트에 대해 포스트를 올린적이 있습니다. 시간이 있다면 자세한 내용은 그걸 참조하세요.