조 단위 규모의 데이터 중복 제거: LLM 학습의 가장 큰 병목을 해결하는 방법
LLM 스케일링 경쟁—그리고 보이지 않는 비용
LLM은 현대 AI의 거의 모든 측면을 변화시키며 콘텐츠 생성, 소프트웨어 개발, 추론, 자율적 도구 사용에서 새로운 지평을 열었습니다. 그리고 그 역량은 둔화될 기미를 보이지 않습니다.
가장 최근 발표를 보겠습니다: X.ai의 Grok 4와 Moonshot의 Kimi K2는 더 강력한 추론 능력, 더 나은 도구 사용, 더 일관된 생성을 선보이며—이 모든 것은 훨씬 더 크고 다양한 학습 말뭉치에 의해 가능해졌습니다.
추세는 명확합니다: 역량의 최전선은 전례 없는 규모의 학습을 통해 앞으로 밀려나고 있습니다. 최근 모델들의 데이터 규모를 살펴보겠습니다:
| 모델 | 출시 | 파라미터 | 학습 데이터 |
|---|---|---|---|
| Kimi K2 | 2025 | 1T | 15.5조 토큰 |
| Grok 4 | 2025 | ~175B | Grok 2보다 100배 많음, 아마도 조 단위 규모 |
| GPT-4 | 2023 | 1.8T (추정) | 13조 토큰 |
| LLaMA 3.1 | 2024 | 405B | 15조 토큰 |
예를 들어 Kimi K2는 단 6개월 만에 데이터셋 크기를 세 배로 늘렸습니다—이는 인터넷의 확장 속도를 거의 앞지르는 성장률입니다. 15.5조 토큰에 달하는 이 규모는 전 세계 주요 도서관의 누적 콘텐츠를 모두 합친 것보다도 몇 배나 큽니다.
하지만 이러한 성장 속에는 데이터가 많을수록 항상 성능이 좋아진다는 가정이 숨어 있습니다. 실제로는 단순히 더 많은 토큰을 추가함으로써 얻는 한계 이익은 줄어들고 있으며, 데이터 품질에 의해 점점 더 제약받고 있습니다.
이것이 우리를 현대 LLM 학습에서 첫 번째이자 어쩌면 가장 과소평가된 병목으로 이끕니다: 데이터 중복입니다.
데이터 중복 제거: LLM 학습에 중요한 이유
현대 LLM 사전학습 데이터셋은 주로 대규모 웹 크롤, 오픈 저장소, 공개 말뭉치, 웹에서 스크래핑한 도메인 특화 문서에서 수집됩니다. 이러한 파이프라인이 커질수록 중복은 단지 흔한 현상이 아니라 시스템적인 문제가 됩니다.
사소한 변형(예: 형식 변경, 푸터, 상용구 헤더)이 있는 문서들이 서로 다른 도메인에서 다시 나타납니다. 인기 있는 페이지는 다른 웹사이트에 미러링되거나, 번역되거나, 재게시됩니다. 코드베이스와 지식 문서는 포럼, 위키, 보관된 스냅샷 전반에 걸쳐 중복됩니다. Wikipedia와 같은 구조화된 소스조차도 링크 경로와 미러에서 반복을 보입니다.
이러한 중복 콘텐츠가 검증 없이 학습 세트로 흘러 들어가면 그 결과는 상당합니다:
컴퓨팅 비효율: 반복된 예시는 새로운 정보를 제공하지 않지만 동일한 컴퓨팅 자원을 소모합니다.
과적합 위험: 반복된 표현, 구조, 콘텐츠 패턴에 노출된 LLM은 이러한 패턴에 지나치게 의존하게 되어 일반화 능력이 저하될 수 있습니다.
축어적 암기: 높은 중복은 모델이 특정 시퀀스를 암기할 위험을 증가시켜 안전, 개인정보 보호, IP 관련 우려를 높입니다.
평가 누수: 학습 세트와 검증/테스트 세트 사이에 중복이 존재하면 벤치마크 점수가 인위적으로 부풀려져 모델 품질에 대한 오해의 소지가 있는 인상을 줄 수 있습니다.
요컨대, 중복은 단순한 골칫거리가 아닙니다. 이는 대규모, 고비용 학습 실행에 있어 실존적인 문제입니다.
당사의 엔터프라이즈 고객 중 한 곳—최상위 LLM 제공업체—이 바로 이 문제에 직면했습니다. 그들은 수집되기 전에 수백억 개의 문서를 중복 제거해야 했습니다. 정확한 해시 매칭 도구는 근접 중복을 놓쳤습니다. 시맨틱 모델은 대규모로 실행하기에 너무 비쌌습니다. 그리고 기존 데이터 정제 스택은 시간 및 자원 제약을 도저히 충족할 수 없었습니다.
이러한 맥락에서 중복 제거는 전처리 과정의 부차적인 고려사항이 아니라 미션 크리티컬 인프라가 되었습니다.
중복 제거 기법 개요
대규모 중복 제거에는 세 가지 지배적인 전략이 있으며, 각각 정밀도, 비용, 실현 가능성 측면에서 트레이드오프가 있습니다.
정확 매칭: 암호화 해싱을 사용해 동일한 문서를 찾습니다. 빠르고 정밀하지만, 사소한 형식 차이가 있는 유사 중복 문서는 놓칩니다.
의미 기반 매칭: 벡터 임베딩 모델을 활용해 개념적으로 유사한 콘텐츠를 찾습니다. 정확도는 매우 높지만 대규모에서는 계산 비용이 많이 듭니다.
근사 매칭: MinHash LSH 및 Jaccard 유사도와 같은 확률적 알고리즘을 사용해 유사 중복을 찾습니다. 정확도와 계산 효율성의 균형을 맞추며, 조 단위 토큰 데이터셋에 완벽하게 적합합니다.
사전 학습 코퍼스가 테라바이트 또는 페타바이트에 이르면서, 쌍별 비교와 같은 전통적인 정확 매칭 방법은 계산적으로 실현 불가능합니다. 의미 기반 중복 제거는 임베딩 모델을 사용해 벡터를 생성하므로 상당한 오버헤드를 추가합니다.
우리는 비용을 관리 가능한 수준으로 유지하면서 재현율과 정밀도의 균형을 맞추어 대규모 중복 제거를 실용적으로 만드는 MinHash LSH와 같은 더 혁신적인 근사 방법이 필요합니다.
MinHash LSH: 조 단위 규모 데이터셋에서 유사 중복 탐지
대규모 LLM 학습의 맥락에서 효율적인 중복 제거에는 정확할 뿐만 아니라 수백억 개 문서 규모에서도 계산적으로 실현 가능한 매칭 알고리즘이 필요합니다. MinHash LSH (Locality Sensitive Hashing)는 바로 이러한 유형의 시나리오를 위해 특별히 설계되었습니다.
MinHash: 확장 가능한 유사도 추정
MinHash는 명시적인 쌍별 교집합을 계산하지 않고 집합 간 Jaccard 유사도를 추정하도록 설계된 확률적 기법입니다. 문서 중복 제거의 맥락에서는 대규모 코퍼스 전반의 유사도 구조를 보존하는 손실 압축 메커니즘으로 작동합니다.
프로세스는 다음과 같이 작동합니다:
각 문서는 일반적으로 고정 길이의 문자 또는 단어 n-그램인 shingle 집합으로 분해됩니다.
일련의 독립적인 해시 함수가 이러한 집합에 적용됩니다.
각 해시 함수에 대해 shingle 집합 전체에서 나온 결과값 중 최솟값이 유지됩니다.
이로써 각 문서에 대해 고정 길이의 MinHash signature가 생성됩니다. 핵심 속성은 다음과 같습니다: 임의의 두 문서에 대해, 특정 해시 값이 두 signature의 동일한 위치에서 공유될 확률은 두 문서의 Jaccard 유사도를 근사합니다.
이는 대규모 유사도 탐지의 계산 부담을 극적으로 줄여 줍니다. 전체 문서를 비교하는 대신 짧은 signature 벡터를 비교합니다. 하지만 확장성 문제가 있습니다. 이러한 최적화에도 불구하고 모든 문서 쌍을 비교하는 것은 웹 규모에서는 여전히 계산적으로 실현 불가능합니다.
Locality Sensitive Hashing: 유사도 검색 가속화
MinHash를 수십억 규모 코퍼스에 실용적으로 적용하기 위해, signature 벡터 위에 Locality Sensitive Hashing (LSH)을 적용합니다. LSH의 핵심 아이디어는 전체 비교를 요구하지 않으면서 유사한 문서가 적어도 하나의 해시 버킷에서 충돌할 가능성을 높이는 것입니다.
작동 방식은 다음과 같습니다:
각 MinHash signature는 여러 band로 나뉘며, 각 band에는 signature 차원의 부분집합이 포함됩니다.
각 band는 독립적으로 해싱되어 bucket에 매핑됩니다.
두 문서가 동일한 bucket으로 해싱되는 band를 적어도 하나 공유하면, 잠재적 중복 후보로 간주됩니다.
이 banding 전략은 높은 유사도(즉, 공유된 MinHash 값이 많은)를 가진 문서가 충돌할 가능성을 훨씬 더 높여 줍니다. band의 수와 band당 row 수를 조정함으로써, 재현율(포착된 정확한 중복의 수), 정밀도(피한 오탐의 수), 성능 사이에서 트레이드오프를 조절할 수 있습니다.
그 결과 수백억 개의 문서를 포함하는 코퍼스에 적용하더라도 다루기 쉬운, 확장 가능한 근사 중복 제거 시스템이 만들어집니다.
MinHash LSH를 Milvus 및 Zilliz Cloud와 통합하기
전통적으로 중복 제거는 기본 검색 또는 스토리지 인프라와 분리된 독립형 전처리 파이프라인에서 처리됩니다. 이는 다양한 비효율을 초래합니다:
중복 제거 컴포넌트와 벡터 인덱싱 컴포넌트 간의 비용이 많이 드는 데이터 전송.
데이터 정규화와 shingling을 위한 중복된 로직.
중복 제거와 검색 파이프라인을 함께 확장하기 어려움.
우리는 이 문제에 다르게 접근했습니다. Milvus가 고처리량 벡터 데이터베이스로서 강점을 갖고 있음을 인식하고, 우리는 이렇게 물었습니다: MinHash LSH가 일급의 네이티브 통합 인덱싱 프리미티브가 된다면 어떨까?
이는 Milvus 2.6 및 Zilliz Cloud(관리형 Milvus)에 MinHash LSH를 네이티브로 통합하는 결과로 이어졌고, 근사 중복 제거를 벡터 인덱싱 및 검색 워크플로의 핵심 부분으로 전환했습니다.
이 통합이 가능하게 하는 것
엔드투엔드 워크플로: 수집 및 MinHash 시그니처 생성부터 근사 중복 탐지와 다운스트림 의미론적 검색까지—모두 Milvus 내에서 이루어집니다.
분산 규모: Milvus의 클라우드 네이티브 아키텍처를 기반으로 구축된 LSH 인덱싱은 테라바이트 또는 페타바이트 규모의 데이터 전반에서 수평 확장됩니다.
통합 API: 의미론적 임베딩 검색에 사용되는 동일한 API가 이제 MinHash 기반 중복 제거 쿼리도 지원할 수 있어, MLOps 워크플로가 더 깔끔하고 유지 관리하기 쉬워집니다.
현재 구현에서는:
사용자가 외부에서 MinHash 시그니처를 생성합니다(예: 선호하는 shingling 및 해시 전략 사용).
이러한 시그니처 벡터(일반적으로
uint32배열)가 Milvus에 삽입됩니다.LSH 인덱싱은 위에서 설명한 banding 전략을 사용하여 근사 중복 탐지를 위한 후보 공간을 좁힙니다.
이 설계는 추가 스토리지 계층이나 분리된 전처리 로직을 도입하지 않고도 팀이 대규모로 학습 코퍼스를 중복 제거할 수 있도록 해줍니다.
우리는 또한 하이브리드 삽입(의미론적 벡터와 MinHash 벡터), 동적 인덱스 구성, 배치 중복 제거 쿼리와 같은 워크플로를 지원하도록 기본 API를 확장했습니다. 이러한 기능은 여전히 발전 중이며, 이를 프로덕션에 배포하는 팀들의 피드백을 환영합니다.
MinHash LSH로 수백억 개 문서의 중복을 제거하는 엔지니어링 과제
MinHash LSH를 프로덕션에서 작동하게 만드는 것은 수년 동안 업계의 백경이었습니다.
이 과제는 두 가지 가혹한 요구 사항으로 귀결됩니다:
MinHash와 LSH 알고리즘 모두에 대한 깊은 전문성뿐만 아니라, 이를 매끄럽게 통합할 수 있는 엔지니어링 역량이 필요합니다.
MinHash LSH의 실제 사용 사례는 수백억, 수천억, 심지어 수조 개의 데이터 포인트 중복 제거를 수반합니다. 이는 대부분의 팀이 충족할 수 없는 수준의 성능 및 엔지니어링 역량을 강하게 요구합니다.
완벽한 예가 있습니다: 약 1년 전, 한 선도적인 AI 회사가 겉보기에는 간단해 보이는 요청을 가지고 우리에게 접근했습니다. 그들은 수백억 개의 데이터 포인트(780차원 int32 형식)의 중복을 제거해야 했으며, 서비스를 빠르게 시작하고 중복 제거 및 삽입을 위해 데이터를 신속하게 처리할 수 있어야 했습니다.
우리는 곧바로 중대한 장애물에 부딪혔습니다: 대부분의 벡터 데이터베이스는 기본적으로 float32 데이터 형식을 사용하지만, MinHash 벡터는 uint32 해시 값의 모음입니다.
얼핏 보면 이는 문제가 아닌 것처럼 보입니다—float32는 대부분의 경우 uint32 값을 표현할 수 있지 않나요?
틀렸습니다.
함정은 이렇습니다: float32는 0부터 16,777,216 범위의 부호 없는 정수만 표현할 수 있는 반면, uint32는 0부터 4,294,967,295까지 포괄합니다. 해시 값이 16,777,216을 초과하면 float32는 최하위 비트에서 정밀도를 잃기 시작합니다.
다행히 Milvus와 Zilliz Cloud의 이진 벡터 지원은 이 문제를 우아하게 해결합니다.
이것은 사소한 기술적 세부 사항처럼 보일 수 있지만, 중요한 점을 부각합니다. 다양한 데이터 형식, 대규모 스케일, 다양한 엔터프라이즈 요구사항을 처음부터 처리하도록 설계된 데이터베이스가 필요하다는 것입니다. 처음부터 엔터프라이즈급 시나리오를 염두에 두고 구축하지 않는다면, 이와 같은 아주 작은 호환성 문제조차 나중에는 고객 경험의 재앙으로 바뀔 수 있습니다.
하지만 데이터 형식의 과제는 시작에 불과했습니다. 고객들은 극한의 성능도 요구했습니다. 통합 과정에서 클라이언트는 단도직입적으로 말했습니다. "고정밀 벡터 중복 제거를 즉시 수행할 수 있는 Zilliz Cloud 서비스를 빠르게 구동해야 합니다. 모든 가져오기에는 780차원 int32 시그니처 데이터가 포함된 30GB 파일이 사용되며, 전체 가져오기 프로세스는 15분 이내에 완료되어야 합니다."
처음 보면 불가능한 임무처럼 보이지만, 우리는 빠르게 답을 내놓았습니다. 15분은 잊으세요. 4분 안에 끝내겠습니다.
이 성능 돌파구는 두 가지 핵심 Milvus 최적화에서 비롯되었습니다:
첫째, 기존의 직렬 가져오기 병목을 깨뜨린 다중 파일 병렬 처리를 구현했습니다. 이제 시스템은 여러 데이터 파일을 동시에 처리할 수 있어 전체 처리량과 가져오기 속도를 크게 높입니다.
둘째, 작업의 복잡도와 규모에 따라 컴퓨팅 리소스를 지능적으로 스케줄링하는 동적 리소스 할당을 통합했습니다. 이를 통해 리소스 낭비와 경합을 제거하는 동시에 활용률을 극대화합니다. 이러한 최적화가 결합되어 Milvus는 최신 하드웨어 성능과 클라우드 스토리지의 동시 읽기-쓰기 특성을 충분히 활용하여, 거의 실시간에 가까운 데이터 가져오기 경험을 제공합니다.
가져오기 과제를 해결하는 것은 단지 첫 번째 단계였습니다. 대규모에서 빠른 배포와 연산은 어떻게 처리할까요?
대형 AI 모델 학습 시나리오는 까다로운 요구사항들이 한꺼번에 몰려드는 완벽한 폭풍을 만들어냅니다. 막대한 유입 데이터 볼륨, 거대한 기존 데이터베이스, 초당 44,000건의 벡터 검색에 달할 수 있는 피크 부하를 다뤄야 합니다. 이는 대부분의 시스템을 무너뜨리는 극한의 동시성입니다. 데이터가 계속 유입되고 데이터베이스가 기하급수적으로 성장함에 따라, 연산 수요도 그에 맞춰 증가하며 시스템 성능에 끊임없는 압박을 가합니다.
해결책에는 강력한 분산 컴퓨팅 역량이 필요합니다. Zilliz Cloud의 클라우드 네이티브 아키텍처는 지능적인 워크로드 분산과 탄력적 확장을 통해 이러한 과제를 해결하도록 특별히 설계되었습니다.
비밀 병기: Cardinal Engine 통합
앞으로 MinHash LSH는 시작에 불과합니다. 우리는 이 기능을 Zilliz Cloud의 독자적인 Cardinal engine에 통합하고 있으며, 이를 통해 전반적인 비정형 데이터 처리가 더욱 가속화될 것입니다.
Cardinal은 최신 C++와 최첨단 근사 최근접 이웃 검색(ANNS) 알고리즘을 기반으로 처음부터 구축된 차세대 AI 기반 벡터 검색 엔진입니다. 목표는 간단합니다: 동일한 하드웨어 리소스로 더 많은 사용자 요청을 처리하는 것.
알고리즘 수준 최적화: Cardinal은 IVF 및 그래프 인덱싱과 같은 핵심 알고리즘에 대해 광범위한 성능 튜닝을 제공하여, 속도와 메모리 효율성 사이의 최적 균형을 달성합니다.
엔지니어링 수준 혁신: 이 엔진은 검색 파이프라인의 유연한 구성을 가능하게 하는 모듈형 컴포넌트 아키텍처와 함께, 맞춤형 메모리 할당자와 지능형 메모리 풀링을 특징으로 합니다. 각 파이프라인은 특정 미션 크리티컬 사용 사례에 맞게 세밀하게 튜닝될 수 있습니다.
하드웨어별 최적화: Cardinal에는 여러 전문화된 컴퓨트 커널이 포함되어 있으며, 각각은 특정 하드웨어 플랫폼과 워크로드 패턴에 맞춰 수작업으로 최적화되어 있습니다.
이러한 포괄적인 최적화를 통해 Cardinal은 24시간 내내 최대 효율로 운영되며, 업계 최고 수준의 벡터 검색 성능을 제공합니다. Zilliz Cloud를 구동하는 Cardinal을 통해 우리는 오픈소스 Milvus 대비 10배의 성능 향상을 달성했으며, 초고속 쿼리 속도와 높은 재현율을 결합했습니다. 대규모 데이터셋을 처리하든 번개처럼 빠른 응답 시간이 요구되는 애플리케이션을 구축하든, Cardinal은 뛰어난 사용자 경험과 경쟁력 있는 AI 애플리케이션을 위한 성능 기반을 제공합니다.
미래는 비정형입니다—그리고 우리는 준비되어 있습니다
LLM 학습 데이터 중복 제거는 훨씬 더 큰 변화 이야기의 서막일 뿐입니다. IDC는 2027년까지 비정형 데이터가 전 세계적으로 거의 250ZB까지 폭증하여, 존재하는 모든 데이터의 86.8%를 차지할 것이라고 예측합니다. 이 데이터는 정형 데이터보다 처리하고 저장하는 데 훨씬 더 많은 비용이 들지만, 텍스트, 이미지, 오디오, 비디오, 센서 로그, 소셜 미디어 콘텐츠, PDF, 웹 페이지, 코드 저장소, 의료 영상, 위성 사진 속에 잠겨 있는 가치는 결코 무시할 수 없습니다.
이는 우리 시대를 규정하는 과제를 만들어냅니다: 기하급수적으로 증가하는 비정형 데이터에서 비용 부담을 폭증시키지 않고 어떻게 효율적으로 가치를 추출할 수 있을까요?
AI 학습을 위해 우리가 구축한 중복 제거 기능은 이 더 큰 퍼즐의 한 조각일 뿐입니다. 비정형 데이터가 계속 폭발적으로 증가함에 따라, 지능형 알고리즘, 엔터프라이즈 규모의 엔지니어링, 클라우드 네이티브 성능이라는 동일한 원칙은 모든 데이터 중심 조직의 필수 인프라가 될 것입니다.
미래는 비정형 데이터의 혼돈을 구조화된 경쟁 우위로 바꿀 수 있는 기업의 것입니다. 우리는 한 번에 하나의 알고리즘씩 그 미래를 구축하고 있습니다. 함께할 준비가 되셨나요?
AI 학습 파이프라인을 위한 대규모 중복 제거를 살펴볼 준비가 되셨나요? Milvus 2.6의 MinHash LSH 기능에 대해 자세히 알아보려면 종합 문서, 프로덕션 워크로드용 Zilliz Cloud (관리형 Milvus)를 사용해 보거나, 특정 사용 사례를 논의하려면 Discord 에서 엔지니어링 팀과 연결하세요.
계속 읽기
Why Context Engineering Is Becoming the Full Stack of AI Agents
Discover how context engineering unifies prompts, RAG, and tools to build smarter, production-ready AI agents powered by Milvus.
Announcing VDBBench 1.0: Open-Source VectorDB Benchmarking with Your Real-World Production Workloads
Discover VDBBench 1.0, an open-source tool for benchmarking vector databases with real-world production data, streaming ingestion, and concurrent workloads.
Why Deepseek is Waking up AI Giants Like OpenAI And Why You Should Care
Discover how DeepSeek R1's open-source AI model with superior reasoning capabilities and lower costs is disrupting the AI landscape and challenging tech giants like OpenAI.