[AI Search] FineWeb2: Multilingual Search를 위한 데이터 파이프라인

한 줄 요약

FineWeb2는 “영어에서 잘 되던 web-scale data curation pipeline을 1000개 이상의 언어에 어떻게 확장할 것인가?”를 다루는 논문이다. AI Search 관점에서는 검색 모델 논문이라기보다, multilingual search/RAG의 바닥 품질을 결정하는 data layer 논문으로 읽는 게 좋다.

앞선 GlotLID 글이 “문서가 어떤 언어인지 먼저 제대로 알아야 한다”는 이야기였다면, FineWeb2는 그 다음 질문을 다룬다.

언어를 알아냈다고 치자. 그러면 각 언어의 웹 문서를 어떤 기준으로 걸러내고, 중복을 제거하고, 다시 샘플링해야 좋은 multilingual corpus가 될까?

논문이 제시하는 답은 꽤 명확하다. 모든 언어에 같은 영어 기준을 적용하지 말고, 언어별 통계와 downstream 모델 성능을 이용해 pipeline을 자동으로 조정하자는 것이다.

Common Crawl
  ↓
HTML extraction / URL filtering
  ↓
Language Identification
  ↓
Language-wise deduplication
  ↓
Language-adaptive quality filtering
  ↓
Dedup/quality-aware rebalancing
  ↓
FineWeb2 multilingual corpus

최종 결과물은 96개 Common Crawl snapshot에서 만든 약 20TB, 50억 문서 규모의 multilingual dataset이다. 논문 기준으로 1,868개 language-script pair를 포함하고, 100개 이상의 문서를 가진 pair는 1,226개다.

왜 이 논문이 AI Search에 중요한가

AI Search라고 하면 보통 embedding model, vector DB, reranker, agentic search를 먼저 떠올린다. 그런데 multilingual search로 가면 모델 이전에 더 기초적인 문제가 생긴다.

검색 대상 corpus 자체가 깨끗하지 않으면, retrieval은 그 위에서 아무리 좋아져도 한계가 있다.

검색 시스템에서 corpus quality는 종종 “데이터팀이 알아서 해주는 것”처럼 밀려난다. 하지만 RAG나 enterprise search를 만들어 보면 결국 품질 문제의 상당 부분은 retrieval algorithm이 아니라 데이터 쪽에서 온다.

예를 들면 이런 문제들이다.

• 한국어 corpus에 영어 boilerplate가 섞여 있다.
• 특정 언어의 문서가 거의 Bible/Wikipedia 복사본뿐이다.
• 같은 문서가 수천 번 반복되어 embedding space를 오염시킨다.
• 영어 기준의 “좋은 문서” 필터를 중국어·태국어·독일어에 그대로 적용한다.
• low-resource 언어 문서가 너무 적어서 noisy document 하나가 전체 corpus에 큰 영향을 준다.

FineWeb2는 이런 문제를 “모델을 더 크게 만들자”가 아니라 “언어마다 다르게 동작하는 data curation pipeline을 만들자”로 푼다.

문제: 영어용 FineWeb pipeline을 그대로 번역할 수 없다

FineWeb은 영어 pretraining data curation에서 중요한 dataset/pipeline이다. 그런데 영어에서 잘 되는 pipeline을 다른 언어에 그대로 적용하면 바로 문제가 생긴다.

가장 단순한 예는 필터 threshold다.

논문은 low-resource 언어에서 특히 다음 문제가 크다고 본다.

1. corpus quality를 평가할 benchmark 자체가 부족하다.
2. language identification이 더 어렵다.
3. filtering rule을 언어별로 조정해야 한다.
4. 단어 분리/tokenization조차 언어마다 다르다.
5. 언어별 expert가 pipeline을 수작업으로 만드는 방식은 1000개 언어에 확장되지 않는다.

그래서 FineWeb2의 목표는 “모든 언어에 하나의 고정 pipeline”이 아니다. 더 정확히는 하나의 pipeline 구조를 유지하되, 내부 threshold와 도구 선택을 언어별 통계로 자동 조정하는 것이다.

핵심 아이디어 1: GlotLID 기반 language identification

FineWeb2의 첫 번째 핵심 단계는 language identification이다.

논문은 Common Crawl에서 영어로 분류되지 않은 나머지 대량의 문서를 출발점으로 삼는다. FineWeb의 영어 필터 기준을 통과한 문서가 전체의 약 40%였고, FineWeb2는 나머지 약 60%의 non-English 후보 문서를 대상으로 한다.

여기서 어떤 LID classifier를 쓰느냐가 중요하다.

FineWeb2는 최종적으로 GlotLID를 선택한다. 이유는 단순히 benchmark 점수가 높아서만은 아니다.

논문은 FT176과 GlotLID로 분류한 문서 각각으로 canary language별 모델을 학습해 downstream 성능을 비교했다. 결과적으로 GlotLID는 high-resource 언어에서는 FT176보다 나았고, low-resource 언어에서는 약간 뒤지는 경우도 있었다. 그래도 FineWeb2는 GlotLID를 선택한다. 훨씬 넓은 언어 coverage와 script 구분, noise label이 pipeline 전체 관점에서 더 중요하다고 봤기 때문이다.

여기서 좋은 포인트는 논문이 LID를 “분류 정확도 benchmark”만으로 고르지 않았다는 점이다. 실제 pretraining dataset을 만들었을 때 downstream model quality가 좋아지는지를 본다. 이 관점은 검색에서도 그대로 중요하다.

LID가 좋아 보인다는 것과, 그 LID로 만든 corpus가 좋은 검색 품질을 만든다는 것은 같은 말이 아니다.

핵심 아이디어 2: 언어별 confidence threshold

LID classifier는 보통 “이 문서는 Swahili일 확률 0.73” 같은 confidence score를 낸다. 기존 multilingual dataset들은 종종 모든 언어에 같은 threshold를 적용한다.

예를 들어:

confidence > 0.7 이면 keep
아니면 drop

겉보기에는 깔끔하지만, 논문은 이 방식이 언어별 차이를 무시한다고 본다. 어떤 언어는 classifier가 매우 자신 있게 예측하고, 어떤 언어는 closely related language 때문에 confidence가 낮게 나온다. 같은 0.7이라는 숫자가 모든 언어에서 같은 의미를 갖지 않는다.

FineWeb2는 canary language에서 여러 threshold를 실험한 뒤, 최종적으로 score distribution의 median에서 standard deviation 하나를 뺀 값을 사용하고, 이를 [0.3, 0.9] 범위로 clip하는 방식을 쓴다.

language-specific threshold
  = median(confidence scores) - std(confidence scores)
  clipped to [0.3, 0.9]

예를 들어 논문은 Arabic이나 Russian은 높은 threshold가 좋고, Swahili는 더 낮은 threshold가 좋은 사례를 언급한다. 이것은 “low-resource 언어일수록 무조건 더 엄격하게 걸러야 한다”가 아니라, 언어별 score distribution을 보고 조정해야 한다는 뜻이다.

검색 pipeline으로 가져오면 이런 식이다.

ko 문서: confidence 0.75면 충분히 keep
xx-low-resource 문서: confidence 0.75가 오히려 매우 높은 신호일 수 있음
closely-related language group: confidence threshold를 낮추거나 별도 audit 필요

핵심 아이디어 3: deduplication을 마지막이 아니라 앞에서 한다

FineWeb2는 deduplication을 pipeline 후반이 아니라 비교적 앞쪽에서 수행한다.

Deduplication은 MinHash 기반 fuzzy deduplication을 사용한다. 동일하거나 매우 유사한 문서 cluster를 찾고, cluster당 하나의 문서를 남긴다. 논문은 FineWeb과 같은 MinHash 설정을 사용하고, 언어별로 global deduplication을 수행한다.

여기서 흥미로운 점은 두 가지다.

첫째, deduplication을 먼저 해서 filtering 실험 결과가 deduplication 효과와 섞이지 않게 만든다. FineWeb2는 매우 많은 filtering ablation을 돌리는데, 뒤에서 dedup을 하면 “필터가 좋아진 건지, dedup이 좋아진 건지” 해석이 어려워진다.

둘째, deduplication할 때 cluster size를 버리지 않는다. 어떤 문서가 몇 개의 duplicate를 대표하는지 기록해두고, 나중에 rehydration에서 이 정보를 사용한다.

검색 관점에서도 이건 중요하다.

중복 제거 전:
  같은 문서 100개가 candidate pool에 반복 등장
  → retriever/reranker가 같은 신호를 과대평가
 
중복 제거 후:
  문서는 하나만 남김
  → 하지만 원래 얼마나 많이 반복됐는지는 metadata로 보존

단순 dedup은 “중복을 다 없애자”로 끝나지만, FineWeb2는 “중복 수가 품질 또는 중요도에 대한 약한 신호일 수도 있다”는 점까지 활용한다.

핵심 아이디어 4: language-adaptive filtering

FineWeb2에서 가장 실무적인 부분은 filtering이다.

기존 영어용 quality filter는 다음과 같은 rule을 쓴다.

• 문서 내 반복 단어/문장 비율
• 평균 단어 길이
• punctuation으로 끝나는 line 비율
• stopword 포함 여부
• 특정 quality heuristic 기준

문제는 이 rule의 threshold가 언어별로 달라야 한다는 점이다. 영어 기준의 평균 단어 길이나 stopword rule을 중국어, 태국어, 아랍어, 독일어에 그대로 쓰면 이상한 결과가 나온다.

FineWeb2는 각 언어의 reference corpus에서 통계를 뽑아 threshold를 자동으로 정한다. 참고한 source는 크게 세 가지다.

1. Wikipedia
2. GlotLID-Corpus
3. Common Crawl에서 해당 언어로 분류된 데이터

그리고 여러 threshold 선택 방법을 비교한다.

논문은 filter group별로 여러 방법을 조합해 실험했고, canary language마다 모델을 학습해 평균 rank를 비교했다. 이 과정에서 207개의 ablation model을 각각 29B token 규모로 학습했다고 한다.

여기서 중요한 건 “필터를 잘 설계했다”보다 “필터 설계를 downstream model performance로 검증했다”는 점이다. Corpus filtering은 직관적으로 그럴듯한 rule이 많지만, 실제로는 과도하게 좋은 데이터를 버리거나 나쁜 데이터를 남길 수 있다.

AI Search에서도 마찬가지다. 문서 ingestion rule을 만들 때 다음 질문이 필요하다.

이 필터가 사람이 보기엔 합리적인가? 보다, 이 필터를 통과한 corpus로 검색 품질이 좋아지는가?

핵심 아이디어 5: rehydration — dedup 정보를 다시 샘플링에 사용하기

FineWeb2에서 개인적으로 가장 재미있는 부분은 rehydration이다.

Deduplication은 중복 문서를 제거한다. 그런데 모든 중복이 똑같이 나쁜 것은 아니다. 어떤 문서는 template spam이라서 중복이 많고, 어떤 문서는 여러 곳에서 인용된 고품질 문서라서 중복이 많을 수 있다.

FineWeb2는 dedup cluster size와 filtering 결과를 같이 사용해 upsampling weight를 정한다. 논문 Figure 2는 French 문서에서 MinHash cluster size별 filtering rate를 보여주고, cluster size가 품질 proxy로 사용될 수 있음을 설명한다.

직관적으로는 이런 방식이다.

문서 A: duplicate cluster가 크고, 같은 cluster size 구간의 filtering rate가 낮음
  → 상대적으로 품질 좋은 반복 문서일 가능성
  → upsample 가능
 
문서 B: duplicate cluster가 크고, 해당 구간의 filtering rate가 높음
  → spam/boilerplate 반복일 가능성
  → 덜 upsample 또는 제외

논문은 이 dedup-informed upsampling을 rehydration이라고 부른다. 완전히 dedup된 dataset의 깔끔함은 유지하되, 원래 웹에서 자주 등장한 고품질 content의 분포 신호를 일부 되살리는 방식이다.

검색 시스템에서도 비슷한 문제가 있다.

• 완전 dedup만 하면 인기 있는 canonical 문서의 신호가 사라질 수 있다.
• 중복을 그대로 두면 retrieval 결과가 duplicate로 도배될 수 있다.
• 그래서 검색 index에는 하나만 남기되, ranking feature에는 duplicate count나 source diversity를 넣는 식의 절충이 필요하다.

FineWeb2의 rehydration은 pretraining dataset용 기법이지만, 검색 ranking에서도 꽤 좋은 analog가 있다.

실험과 결과

논문은 pipeline을 설계할 때 9개 canary language를 사용한다.

핵심 결과는 크게 세 가지다.

첫째, pipeline의 각 단계가 성능에 기여한다. 논문 Figure 1은 350B token 규모 모델 평가에서 LID, deduplication, filtering, rehydration이 각각 성능 향상에 기여한다고 보여준다.

둘째, FineWeb2는 비교한 14개 언어 중 11개에서 기존 multilingual dataset보다 더 좋은 모델 성능을 냈다. 여기에는 pipeline 설계에 사용한 canary language뿐 아니라 unseen language도 포함된다. 논문은 unseen language로 German, Indonesian, Italian, Japanese, Vietnamese를 사용해 generalization을 확인한다.

셋째, language-specific dataset이 여전히 이기는 경우도 있다. 논문은 일부 언어에서는 native speaker나 language expert가 수작업으로 설계한 단일 언어 pipeline이 FineWeb2보다 나을 수 있다고 인정한다.

이 균형감이 중요하다. FineWeb2는 “자동 pipeline이 모든 언어 전문가를 대체한다”는 논문이 아니다. 오히려 다음에 가깝다.

1000개 이상의 언어를 다루려면 expert-designed single-language pipeline만으로는 확장되지 않는다. 대신 자동 적응형 pipeline을 baseline으로 깔고, 중요한 언어에서는 expert tuning이 추가될 수 있다.

AI Search Stack에서의 위치

이 시리즈 흐름으로 보면 FineWeb2는 GlotLID 바로 다음에 놓는 게 자연스럽다.

Data / Corpus layer
  Roaring Bitmap: 빠른 filter/index primitive
  GlotLID: multilingual corpus의 language routing
  FineWeb2: multilingual corpus cleaning / dedup / filtering / balancing
 
Retrieval layer
  ColBERT / PLAID / SPLATE
  LIMIT / Gemini Embedding / Position Bias
 
Reranking / Context layer
  AcuRank / LDAR
 
Agentic search / Evaluation layer
  SWE-agent / DGM / Debate Helps Weak Judges

FineWeb2가 직접 search engine을 만들지는 않는다. 하지만 좋은 multilingual search engine을 만들려면 결국 이런 data layer가 필요하다.

특히 다음 세 경우에는 FineWeb2식 사고가 중요하다.

1. Multilingual RAG
   언어별 문서 품질이 다르면 retrieval 품질이 언어별로 크게 흔들린다.

2. Domain-specific corpus curation
   의료, 법률, 금융처럼 web data를 그대로 쓰기 어려운 영역에서는 filtering rule과 dedup policy가 ranking만큼 중요하다.

3. Low-resource / long-tail search
   데이터가 적은 언어·도메인에서는 문서 하나하나의 오염도가 훨씬 크게 작용한다.

실무적으로 생각해볼 점

FineWeb2를 그대로 가져와 enterprise search pipeline에 넣을 수는 없다. pretraining corpus curation과 production search index curation은 목적이 다르다. 그래도 가져올 만한 원칙은 많다.

1. 언어별 threshold를 분리해야 한다

문서 길이, punctuation ratio, stopword 비율, boilerplate 비율 같은 필터는 언어별로 threshold가 달라야 한다.

한국어와 영어만 비교해도 tokenization, 조사, 문장부호 사용, 평균 어절 길이가 다르다. 여기에 일본어, 중국어, 태국어까지 들어오면 “global threshold”는 거의 반드시 문제를 만든다.

2. LID는 routing metadata이지 단순 label이 아니다

문서의 언어 label은 이후 모든 단계에 영향을 준다.

language label
  → analyzer/tokenizer 선택
  → embedding model 선택
  → reranker 선택
  → query-document matching policy 선택
  → evaluation bucket 선택

그래서 LID confidence를 metadata로 남겨야 한다. lang=ko만 저장하는 것보다 lang=ko, confidence=0.91, classifier=GlotLID, script=Kore처럼 남기는 쪽이 나중에 audit하기 좋다.

3. Dedup은 삭제가 아니라 feature extraction이다

검색 index에서는 중복 문서를 제거하는 것만으로 끝내기 쉽다. 하지만 duplicate cluster size, source diversity, canonical URL, near-duplicate relation은 ranking과 debugging에 유용한 feature가 된다.

index에는 canonical 문서 하나만 저장
ranking/debug metadata에는 duplicate_count, duplicate_sources 저장

FineWeb2의 rehydration은 이 생각을 pretraining data sampling에 적용한 사례로 볼 수 있다.

4. Filtering rule은 benchmark로 검증해야 한다

“짧은 문서는 버린다”, “표가 많은 문서는 버린다”, “중복 line이 많으면 버린다” 같은 rule은 만들기 쉽다. 그런데 실제 검색에서는 그런 문서가 정답 근거일 수도 있다.

따라서 ingestion filter는 최소한 query set과 relevance judgment, 또는 downstream answer quality로 검증해야 한다. FineWeb2가 canary language와 early-signal task를 만든 이유도 여기에 있다.

5. Long-tail corpus의 다양성을 따로 봐야 한다

논문에서 가장 중요한 한계 중 하나는 low-resource corpus의 상당수가 Bible/Wikipedia 중심이라는 점이다. 최종 dataset의 1,868개 language-script pair 중 70%, 즉 1,320개는 문서의 절반 이상이 Bible 또는 Wikipedia 관련 domain에서 온다고 한다.

이건 search에서도 매우 현실적인 문제다.

문서 수만 보면 “언어 coverage가 있다”고 말할 수 있지만, 실제로는 특정 source type에 과도하게 편중되어 있을 수 있다. Corpus diversity를 별도 metric으로 봐야 한다.

한계와 열린 질문

논문도 한계를 꽤 명확히 적는다.

첫째, FineWeb2는 많은 언어를 포함하지만, 실제 실험으로 검증한 언어는 전체의 작은 일부다. 1,868개 language-script pair를 모두 downstream training으로 검증하는 것은 현실적으로 어렵다.

둘째, evaluation task는 early-signal 기준으로 선택됐다. 짧은 학습 구간에서 의미 있는 signal을 주는 benchmark를 고른 것이고, 더 긴 학습이나 더 큰 모델에서도 같은 task가 같은 의미를 갖는지는 별도 문제다.

셋째, task selection이 cultural alignment, bias, diversity 같은 요소를 충분히 측정하지 않는다. Multilingual model에서 “언어를 처리한다”는 것과 “그 언어권의 문화적 맥락에 잘 맞는다”는 것은 다르다.

넷째, low-resource 언어의 상당수는 Bible/Wikipedia content에 크게 의존한다. 이건 dataset 품질의 문제가 아니라 웹에 존재하는 공개 텍스트의 구조적 한계이기도 하다.

다섯째, FineWeb2는 영어를 포함하지 않는다. 전체 언어 coverage를 원하면 FineWeb과 함께 써야 한다.

제 해석

FineWeb2는 “데이터셋 논문”처럼 보이지만, 저는 이 논문을 multilingual AI Search의 운영 논문에 가깝게 읽었다.

검색 품질을 올리려고 하면 보통 더 좋은 embedding model, 더 좋은 reranker, 더 긴 context를 생각한다. 그런데 multilingual이나 long-tail domain으로 가면, 가장 먼저 무너지는 건 모델이 아니라 corpus hygiene이다.

• 이 문서가 정말 이 언어인가?
• 이 언어의 filter 기준은 적절한가?
• 같은 문서가 반복되어 ranking을 오염시키고 있지 않은가?
• low-resource corpus가 사실상 Bible/Wikipedia clone은 아닌가?
• 문서 품질을 사람이 정한 rule이 아니라 downstream 품질로 검증했는가?

FineWeb2의 메시지는 단순하다.

Multilingual system에서는 “하나의 pipeline”보다 “언어별로 적응하는 pipeline”이 중요하다.

이건 검색에도 그대로 적용된다. AI Search stack을 제대로 만들려면 vector DB나 agent layer 이전에, corpus를 언어별·도메인별로 다르게 다루는 ingestion layer가 있어야 한다. FineWeb2는 그 ingestion layer를 web-scale multilingual setting에서 어떻게 설계할 수 있는지 보여주는 좋은 reference다.

정리

FineWeb2를 한 문장으로 정리하면 다음과 같다.

FineWeb2는 Common Crawl에서 1000개 이상의 언어를 위한 pretraining corpus를 만들기 위해, language identification, deduplication, language-adaptive filtering, quality-aware rebalancing을 하나의 자동 적응형 pipeline으로 묶은 논문이다.

AI Search 관점에서 중요한 포인트는 이거다.

• multilingual search 품질은 retrieval model만으로 결정되지 않는다.
• 언어 식별과 corpus filtering이 search stack의 첫 번째 품질 게이트다.
• 영어 기준의 filter를 모든 언어에 적용하면 안 된다.
• dedup 정보는 버릴 게 아니라 ranking/sampling feature가 될 수 있다.
• low-resource coverage는 문서 수뿐 아니라 source diversity까지 봐야 한다.

다음 글에서는 data curation에서 query/document understanding 쪽으로 넘어가, arbitrary entity extraction을 다루는 GLiNER를 보면 자연스럽다. Search가 단순히 문서를 찾는 것이 아니라, 문서와 query 안의 entity를 어떻게 구조화해서 이해할 것인가의 문제로 이어지기 때문이다.