google-bigquery

2 개의 포스트

google4분 읽기큐레이션 요약

TabFM 소개: 표 형식 데이터를 위한 제로샷 파운데이션 모델

TabFM은 표 형식 데이터를 위한 제로샷 파운데이션 모델로, 별도의 모델 학습·하이퍼파라미터 튜닝·복잡한 피처 엔지니어링 없이 분류와 회귀를 수행한다. 전체 학습 데이터와 예측 대상 행을 하나의 문맥으로 입력해 인컨텍스트 러닝(ICL) 방식으로 관계를 파악하며, 단 한 번의 순전파로 예측을 생성한다. Google은 TabArena 평가에서 TabFM이 기존의 튜닝된 트리 기반 모델들과 경쟁력 있는 성능을 보였다고 설명하며, BigQuery의 `AI.PREDICT` SQL 명령으로 제공할 계획이다. ## 기존 표 형식 머신러닝의 한계 - 고객 이탈 예측, 금융 사기 탐지 등 표 데이터 기반 분류·회귀 문제는 기업의 핵심 업무에 널리 사용된다. - AdaBoost, XGBoost, 랜덤 포레스트 같은 지도학습 트리 모델이 오랫동안 강력한 성능을 보여왔다. - 하지만 새로운 데이터셋마다 다음 작업을 반복해야 한다. - 모델 학습 - 하이퍼파라미터 최적화 - 도메인별 피처 엔지니어링 - 검증 및 재학습 - 따라서 단순히 `.fit()`을 호출하는 것만으로는 실무에서 신뢰할 만한 성능을 얻기 어렵다는 문제가 있다. ## 표 데이터를 위한 인컨텍스트 러닝 - TabFM은 기존처럼 데이터셋별로 모델 가중치를 업데이트하지 않는다. - 과거의 학습 행과 예측할 테스트 행을 하나의 통합된 입력 문맥으로 제공한다. - 모델은 추론 시점에 행과 열 사이의 관계를 분석해 새로운 작업을 수행한다. - 이는 대규모 언어 모델이 예시와 지시문만으로 새로운 작업을 수행하는 제로샷·인컨텍스트 러닝과 유사하다. - 결과적으로 데이터셋별 반복 학습, 튜닝, 수작업 피처 설계가 필요하지 않다. ## 행·열 구조를 반영한 하이브리드 아키텍처 표는 자연어처럼 일렬로 정렬된 토큰 시퀀스가 아니라, 행과 열로 구성된 2차원 구조이며 행이나 열의 순서를 바꿔도 의미가 본질적으로 달라지지 않는다. TabFM은 이를 처리하기 위해 TabPFN과 TabICL의 아이디어를 결합한 구조를 사용한다. - **행·열 교차 어텐션** - 여러 층의 어텐션 모듈이 열 방향과 행 방향을 번갈아 처리한다. - 각 피처의 상호작용과 각 샘플 간의 관계를 함께 학습한다. - 기존 피처 엔지니어링이 담당하던 복잡한 변수 간 의존성 추출을 모델 내부에서 수행한다. - **행 압축** - 각 행에서 얻은 풍부한 문맥 정보를 하나의 밀집 벡터로 압축한다. - 이후 단계가 원본 2차원 테이블 전체가 아니라 압축된 행 표현을 사용하도록 만든다. - **압축 표현 기반 ICL** - 전용 Transformer가 압축된 행 벡터들의 시퀀스에 어텐션을 적용한다. - 원시 테이블 전체에 직접 어텐션하는 방식보다 계산량이 크게 줄어든다. - 데이터셋 규모가 커져도 비교적 효율적으로 예측할 수 있도록 설계됐다. ## 합성 데이터로 대규모 사전 학습 - 산업용 표 데이터는 기업의 독점 스키마와 민감한 정보를 포함하는 경우가 많아 공개된 대규모 학습 데이터가 부족하다. - TabFM은 이 문제를 해결하기 위해 수억 개의 합성 데이터셋으로만 학습됐다. - 합성 데이터는 구조적 인과 모델(SCM)을 이용해 동적으로 생성된다. - 다양한 무작위 함수와 데이터 분포, 복잡한 피처 관계를 포함하도록 설계됐다. - 실제 데이터를 직접 대량 확보하지 않고도 다양한 표 구조를 학습해, 보지 못한 실제 데이터셋에 일반화하는 것을 목표로 한다. ## TabArena 벤치마크와 두 가지 모델 설정 - TabArena에서 분류 38개, 회귀 13개 데이터셋을 대상으로 평가했다. - 데이터셋 크기는 약 700개에서 150,000개 샘플까지 다양하다. - 모델 간 일대일 승률을 바탕으로 Elo 점수를 계산해 성능을 비교한다. - **TabFM** - 기본 제공 모델이다. - 튜닝이나 교차 검증 없이 한 번의 순전파로 예측한다. - 제로샷 사용 편의성을 중시한 설정이다. - **TabFM-Ensemble** - 성능 향상을 위해 교차 피처와 SVD(특이값 분해) 피처를 추가한다. - 비음수 최소제곱법으로 32개 모델 앙상블의 최적 가중치를 계산한다. - 분류 문제에서는 Platt scaling을 이용해 예측 확률을 보정한다. - 기본 TabFM보다 추가 계산과 처리 과정이 필요하지만 더 높은 성능을 목표로 한다. ## 제공 방식과 기대 효과 - TabFM은 Hugging Face와 GitHub를 통해 공개된다. - Google BigQuery에도 통합될 예정이며, 사용자는 `AI.PREDICT` SQL 명령으로 분류·회귀를 실행할 수 있다. - 별도의 머신러닝 전문 지식이나 전통적인 모델 개발 파이프라인 없이 표 데이터 예측을 수행하는 것이 목표다. 실무에서는 빠른 기준선 모델이나 반복적인 데이터셋별 모델 개발을 줄이는 용도로 TabFM을 먼저 적용할 수 있다. 다만 중요한 의사결정에 사용할 때는 데이터 누수, 예측 확률의 보정, 기존 모델과의 실제 데이터셋별 비교 및 비용·지연 시간까지 함께 검증하는 것이 좋다.

원문 읽기(새 탭에서 열림)
discord원문

dbt 오버클러킹 (새 탭에서 열림)

디스코드는 2,500개 이상의 데이터 모델과 100명 이상의 개발자가 협업하는 페타바이트급 데이터 환경을 관리하기 위해, dbt의 기본 기능을 넘어선 커스텀 확장 시스템을 구축했습니다. 초기 도입 시에는 20분이 넘는 컴파일 시간과 개발자 간의 작업 충돌 등 확장성 한계에 부딪혔으나, 이를 자동화된 백필(Backfill)과 생산성 도구로 해결하며 견고한 데이터 분석 기반을 마련했습니다. 이 사례는 대규모 데이터 웨어하우스 환경에서 dbt를 효율적으로 확장하려는 기업들을 위한 기술적 청사진을 제시합니다. ### dbt 선정 배경과 주요 장점 * **엔지니어링 철학과의 일치:** 오픈 소스를 지향하고 엔지니어링의 유연성과 투명성을 중시하는 디스코드의 철학에 따라 dbt를 채택했습니다. * **도구 간 통합 및 모듈화:** 오케스트레이터인 Dagster와의 원활한 통합은 물론, SQL 기반의 모듈식 설계를 통해 코드 재사용성과 유지보수성을 확보했습니다. * **품질 관리:** 데이터 품질을 보장할 수 있는 포괄적인 테스트 프레임워크를 활용하여 신뢰할 수 있는 데이터 변환 프로세스를 구축했습니다. ### 대규모 데이터 환경에서의 한계점 * **긴 컴파일 대기 시간:** 프로젝트 규모가 커짐에 따라 전체 프로젝트를 재컴파일하는 데 20분 이상이 소요되어 개발 생산성이 급격히 저하되었습니다. * **증분 전략의 비효율성:** dbt가 기본적으로 제공하는 증분(Incremental) 구체화 전략은 디스코드의 페타바이트급 데이터 볼륨을 처리하기에 최적화되어 있지 않았습니다. * **동시성 충돌 문제:** 여러 개발자가 동시에 작업하는 과정에서 서로의 테스트 테이블을 덮어쓰는 등 협업상의 혼선과 자원 낭비가 발생했습니다. ### 확장성을 위한 커스텀 최적화 전략 * **성능 중심의 코어 확장:** dbt의 표준 기능을 확장하여 대규모 조직에 적합한 커스텀 시스템을 구축함으로써 개발 사이클을 획기적으로 단축했습니다. * **자동화된 백필 시스템:** 수동 개입이 많이 필요한 복잡한 데이터 백필 과정을 자동화하여 운영 리소스를 절감하고 데이터의 정합성을 높였습니다. * **플랫폼 독립적 설계:** Google BigQuery를 사용하면서도 특정 클라우드 제공업체에 종속되지 않는(Provider-agnostic) 구조를 취해 범용적인 적용이 가능하도록 설계했습니다. 디스코드의 이러한 시도는 단순한 도구 도입을 넘어, 대규모 데이터 스택을 운용할 때 발생하는 병목 현상을 엔지니어링 기반의 커스텀 솔루션으로 해결할 수 있음을 보여줍니다. 데이터 규모가 급격히 성장하는 조직이라면 dbt의 기본 기능에만 의존하기보다, 자사의 인프라에 맞춘 자동화와 확장 도구를 결합하는 전략이 필수적입니다.