대부분의 AI 출시 사례들은 언어 모델 (Language Models)이 모든 분야에서 유용해 보이도록 만들려고 노력합니다.

Google의 TabFM은 머신러닝 (Machine Learning)에서 가장 화려하지 않은 부분인 테이블 (Tables)을 겨냥합니다. 고객 행 (Customer rows), 사기 플래그 (Fraud flags), 이탈 데이터 (Churn data), 재고 스프레드시트 (Inventory spreadsheets) 같은 것들 말이죠. 수익을 창출하면서도 왠지 모르게 final_v7_really_final.ipynb라는 이름의 노트북에 담기게 되는 그런 종류의 데이터들입니다.

이것이 바로 이번 출시가 중요한 이유입니다.

TabFM은 6월 30일 Google Research에서 발표한 정형 데이터 (Tabular data)를 위한 제로샷 파운데이션 모델 (Zero-shot foundation model)입니다. 이 모델은 scikit-learn 스타일의 API를 사용하여 혼합된 수치형 (Numerical) 및 범주형 (Categorical) 컬럼에 대한 분류 (Classification) 및 회귀 (Regression)를 처리합니다. 핵심 개념은 간단합니다. 레이블이 지정된 학습 행 (Labeled training rows)을 컨텍스트로 제공하고, 예측할 새로운 행을 제공하면 단 한 번의 순전파 (Forward pass)로 예측을 생성합니다.

데이터셋별 학습 루프 (Training loop)도 필요 없고, 하이퍼파라미터 스윕 (Hyperparameter sweep)도 필요 없습니다. 아이디어가 유용한지 확인하기도 전에 거쳐야 하는 피처 엔지니어링 (Feature-engineering) 우회로도 없습니다.

만약 이것이 벤치마크 차트 밖에서도 성능을 유지한다면, 정형 데이터 머신러닝 (Tabular ML)은 전문적인 파이프라인이라기보다 쿼리 시점의 기본 요소 (Query-time primitive)처럼 느껴지기 시작할 것입니다.

기존의 정형 데이터 워크플로우는 절차가 너무 복잡합니다

구조화된 데이터 (Structured data)는 텍스트나 이미지만큼의 화려함을 얻지는 못했지만, 대부분의 유용한 비즈니스 예측은 여전히 그곳에 존재합니다. 고객 지원 팀은 에스컬레이션 위험에 따라 티켓의 순위를 매기고 싶어 합니다. 작은 SaaS 기업은 이탈 점수 (Churn scores)를 원합니다. 운영 팀은 사람이 오후 시간을 허비하기 전에 이상한 주문을 찾아내고 싶어 합니다.

이러한 종류의 문제에 대해 일반적인 경로는 너무 무겁습니다.

데이터를 정제하고, 피처 (Features)를 선택하고, XGBoost나 LightGBM 또는 CatBoost를 고르고, 튜닝하고, 교차 검증 (Cross-validate)하고, 보정 (Calibrate)하고, 누군가가 신뢰할 수 있을 만큼 모델을 설명한 다음, 제품이나 분석 워크플로우에서 호출할 수 있도록 전체를 래핑 (Wrap)해야 합니다. 유능한 팀들이 그렇게 하는 데에는 이유가 있습니다. 테이블 데이터에서는 트리 (Trees) 모델을 이기기가 짜증 날 정도로 어렵고, 검증에 관한 지루한 규율이야야 예측 기능이 대시보드 위의 난수 생성기로 전락하는 것을 막아주기 때문입니다.

하지만 첫 번째 유용한 베이스라인 (baseline)을 얻기 전까지는 많은 설정 과정이 필요합니다.

그 설정 비용이야말로 정형 데이터 파운데이션 모델 (tabular foundation models)이 유용해지는 바로 그 지점입니다. 이 모델들이 모든 곳에서 튜닝된 트리 앙상블 (tree ensembles)을 대체할 필요는 없습니다. 그저 첫 번째 신뢰할 만한 모델을 충분히 저렴하게 만들어, 더 많은 팀이 예측을 시도해 볼 수 있게만 해주면 됩니다.

TabFM이 실제로 하는 일

TabFM은 테이블을 인컨텍스트 학습 (in-context learning) 문제로 취급합니다. 학습 행 (rows)은 컨텍스트 (context)가 되고, 테스트 행은 쿼리 (query)가 됩니다. 각 데이터셋마다 새로운 가중치 (weights)를 맞추는 대신, 사전 학습된 (pretrained) 모델이 작은 학습 세트를 읽고 새로운 행에 대한 누락된 레이블 (labels)을 예측합니다.

Google은 TabFM이 구조적 인과 모델 (structural causal models)로부터 생성된 수억 개의 합성 데이터셋 (synthetic datasets)을 통해 전적으로 학습되었다고 밝혔습니다. 이 선택은 매우 중요합니다. 실제 산업용 테이블은 종종 비공개 상태이며, 지저분하고, 독점적이며, 파운데이션 모델 규모로 수집하기에는 법적으로 까다롭습니다. 합성 데이터는 Google이 모든 사람의 CRM을 스크래핑하지 않고도 광범위한 테이블 형태의 변동성을 제조할 수 있는 방법을 제공합니다.

이 아키텍처는 CSV를 단순히 어색한 텍스트인 것처럼 가장하는 대신, 행과 열을 위해 구축되었습니다. 모델은 행 및 열 어텐션 (row and column attention)을 사용한 다음, 인컨텍스트 학습 트랜스포머 (in-context learning transformer)를 사용합니다. 공개된 Hugging Face 모델 카드는 구체적인 형태 (shape) 선택 사항을 나열하고 있습니다: 256차원 임베딩 (embeddings), 3개의 열 어텐션 블록, 3개의 행 어텐션 블록, 24개의 ICL 트랜스포머 블록, 최대 10개 클래스까지의 분류, 그리고 별도의 분류 및 회귀 체크포인트 (checkpoints)입니다.

이 부분이 제가 출시 홍보 문구보다 더 신뢰하는 대목입니다. 이것은 "스프레드시트를 채팅창에 던져 넣고 요행을 바라는 것"이 아닙니다. 정형 데이터 구조를 중심으로 형성된 모델입니다.

현재 출시된 버전은 직접 시도해 볼 수 있을 만큼 실용적입니다. GitHub 저장소는 scikit-learn과 호환되며, JAX 및 PyTorch 백엔드를 지원하고, 실행 가능한 분류 (classification) 및 회귀 (regression) 예제와 Hugging Face의 사전 학습된 (pretrained) v1.0.0 가중치 (weights)를 제공합니다. 코드는 Apache 2.0 라이선스입니다. 하지만 가중치는 그렇지 않습니다. 모델 카드 (model card)에 따르면 가중치는 TabFM 비상업적 라이선스 (Non-Commercial License) v1.0을 따릅니다.

이러한 차이는 놓치기 쉽지만 매우 중요합니다. 상업적 이용 경로가 확보되지 않았다면, 당분간 공개된 가중치는 연구 및 평가용으로만 취급하십시오.

BigQuery 관점이 진정한 제품 신호입니다

Google의 게시물에서 가장 유용한 문구는 벤치마크 (benchmark) 주장이 아닙니다. 바로 BigQuery 통합입니다.

Google은 TabFM이 BigQuery에 통합될 예정이며, 이에 따라 사용자들이 향후 몇 주 내에 AI.PREDICT SQL 명령을 통해 분류 (classification) 및 회귀 (regression)를 실행할 수 있게 될 것이라고 밝혔습니다. 이것이 원활하게 출시된다면, 대상 고객은 ML 엔지니어뿐만이 아닙니다. 이미 데이터 옆에서 작업하고 있는 분석가 (analysts)와 제품 엔지니어 (product engineers)들까지 포함됩니다.

이는 워크플로 (workflow)의 형태를 변화시킵니다.

테이블을 내보내고, 학습 작업 (training job)을 구축한 뒤, ML 파이프라인 (pipeline)이 그 가치를 증명할 때까지 기다리는 대신, 개발자가 테이블이 이미 있는 곳에서 바로 예측을 요청하는 모습을 상상해 보십시오. 고객 행 (rows) 옆에 이탈 위험 (churn risk)을 배치하고, 트랜잭션 (transactions) 옆에 사기 가능성 (fraud likelihood)을 배치하며, CRM 내보내기 데이터 옆에 리드 점수 (lead scoring)를 배치하는 것입니다. 의심의 여지 없는 운영 모델 (production model)로서가 아니라, 빠른 베이스라인 (baseline) 및 분류 (triage) 도구로서 말입니다.

이는 일반적인 "이것이 ML을 대체한다"라는 프레임워크보다 파운데이션 모델 (foundation-model) 기반의 정형 데이터 예측에 훨씬 더 적합한 방식입니다.

이 기술의 첫 번째 유용한 버전은 완전히 자율적인 의사 결정 엔진이 아닙니다. 인간을 위해 작업을 순위 매기고, 필터링하고, 우선순위를 정하는 방법입니다. 내부 도구, 운영 큐 (Ops queues), 분석가 실험, 그리고 전체 모델링 프로젝트를 정당화하기 전에 대략적이지만 검증된 예측이 유용한 SaaS 프로토타입 (prototypes) 등이 이에 해당합니다.

벤치마크 이야기는 강력하지만, 그것이 전부가 아닙니다

Google은 헤드투헤드 (head-to-head) 승률을 기반으로 한 Elo 점수를 사용하여 방법론들을 비교하는 살아있는 벤치마크인 TabArena에서 TabFM을 보고했습니다. 그들의 평가는 700개에서 150,000개의 샘플에 이르는 51개의 데이터셋(분류 38개, 회귀 13개)을 아우릅니다.

두 가지 버전이 중요합니다. 일반 TabFM은 튜닝이나 교차 검증 (cross-validation) 없이 단일 순방향 패스 (forward pass)로 실행됩니다. TabFM-Ensemble은 교차 특징 (cross features), SVD 특징, 32개 방식의 앙상블 (ensemble)에 대한 비음수 최소제곱 블렌딩 (non-negative least-squares blending), 그리고 분류를 위한 Platt 스케일링 (Platt scaling)을 추가합니다.

Google은 이 모델이 그래디언트 부스팅 트리 (gradient-boosted trees)를 포함하여 고도로 튜닝된 지도 학습 (supervised) 베이스라인들을 능가한다고 밝히며, 리포지토리 (repo)에 폴드별 (per-fold) 결과 파일을 공개했습니다.

이는 중대한 주장입니다. 또한, 제가 프로덕션 스택 (production stack)을 재작성하기 전에 잠시 멈춰서 생각하게 되는 지점이기도 합니다.

정형 데이터 (tabular) 벤치마크는 까다롭습니다. 하나의 집계된 Elo 점수는 귀하의 비즈니스가 중요하게 여기는 정확한 실패 모드 (failure mode)를 숨길 수 있습니다: 고카디널리티 (high-cardinality) 범주형 변수, 결측치 패턴 (missingness patterns), 분포 드리프트 (distribution drift), 보정 (calibration), 추론 비용 (inference cost), 개인정보 보호 제약, 또는 작년에 퇴사한 사람에게만 의미가 있었던 이상한 타겟 정의 등이 이에 해당합니다.

또한 경쟁도 빠르게 진행되고 있습니다. Prior Labs의 TabPFN-2.5 보고서에 따르면, 그들의 모델은 50,000개의 행과 2,000개의 특징까지 확장 가능하며, TabArena에서 튜닝된 트리 모델들을 능가하고 AutoGluon 1.4의 4시간짜리 극한 앙상블 (extreme ensemble)과 대등한 성능을 보입니다. AutoGluon 1.5는 이제 더 새로운 정형 데이터 파운데이션 모델 (tabular foundation model) 옵션과 더 강력한 정형 데이터 프리셋 (tabular presets)을 포함하고 있습니다. 이것은 더 이상 하나의 모델이 호기심을 증명하는 단계가 아닙니다. 이는 벤치마크 격전지를 중심으로 하나의 카테고리가 형성되고 있는 것입니다.

사용자에게는 좋은 일이지만, 게으른 채택 (lazy adoption)에는 좋지 않은 일입니다.

제가 가장 먼저 사용할 곳

저는 대출 승인, 의료 분류 (medical triage), 사기 자동 차단, 또는 잘못된 예측이 조용히 누군가에게 해를 끼칠 수 있는 그 어떤 작업으로도 시작하지 않을 것입니다.

저는 예측이 인간이 업무를 더 빠르게 분류하도록 돕는 곳에서 시작할 것입니다:

• 고객 성공(Customer Success) 팀이 어디를 먼저 살펴봐야 할지 알 수 있도록 이탈 가능성이 높은 계정 순위 매기기
• 재검토가 필요한 지원 티켓(Support tickets) 표시하기
• 수동 검토 전 내부 리드(Leads) 점수 매기기
• 복잡한 백오피스 예외 사항의 우선순위 지정하기
• 전체 ML 파이프라인(ML pipeline)을 구축하기 전에 기능 프로토타입 제작하기

이 패턴은 지루하며, 이는 보통 좋은 신호입니다. 챌린저 모델(Challenger model)로서의 TabFM. 제로샷 베이스라인(Zero-shot baseline)으로서의 TabFM. 트리를 튜닝하는 데 일주일을 소비하기 전에 "여기에 신호(Signal)가 있는가?"라는 질문에 답하는 방법으로서의 TabFM.

그다음에도 여전히 성인스러운 작업(Adult work)을 수행해야 합니다: 홀드아웃 평가(Holdout evaluation), 보정 확인(Calibration checks), 슬라이스 분석(Slice analysis), 모니터링, 그리고 폴백 경로(Fallback path)를 마련하는 것 말입니다. 만약 모델이 특정 세그먼트에서 틀렸다면, 대시보드가 이를 예쁜 평균값 아래로 숨겨서는 안 됩니다.

불편한 부분: 더 쉬워진 ML은 검토되지 않은 곳에서의 더 많은 ML을 의미한다

이것이 트레이드오프(Tradeoff)입니다.

예측이 SQL 호출이 될 때, 더 많은 사람이 유용한 도구를 만들 수 있습니다. 그것이 장점입니다. 하지만 동일한 마찰 감소는 아무도 지루한 질문을 던지지 않은 채 더 많은 예측 기능이 나타날 수 있음을 의미하기도 합니다.

정확한 타겟 레이블(Target label)은 무엇인가? 과거의 레이블이 공정하다고 누가 결정했는가? 우리가 선택한 임계값(Threshold)에 대해 모델이 충분히 보정(Calibrated)되었는가? 소규모 고객, 새로운 지역, 희소한 행(Sparse rows), 또는 이상한 에지 케이스(Edge cases)에 대해 다르게 동작하는가? 이 가중치(Weights)를 상업적으로 사용할 수 있는가? 점수가 틀렸을 때 실패의 책임은 누구에게 있는가?

과거의 ML 워크플로우는 느렸지만, 그 느림이 어느 정도의 검토를 강제했습니다. AI.PREDICT는 더 나은 개발자 경험(Developer experience)을 제공할 것입니다. 하지만 그것이 검증을 건너뛰기 위한 허가증이 되어서는 안 됩니다.

이것이 제가 TabFM을 접하며 계속 되새기는 경계선입니다. TabFM이 흥미로운 이유는 판단력을 쓸모없게 만들기 때문이 아니라, 정형 데이터 예측(Tabular prediction)의 활성화 에너지(Activation energy)를 공략하기 때문입니다.

테이블(Tables)은 수많은 유용한 소프트웨어가 존재하는 곳입니다. 만약 파운데이션 모델(Foundation models)이 그 테이블 옆에 앉아 괜찮은 첫 번째 예측을 제공할 수 있다면, 그것은 구체적인 변화입니다. 그저 첫 번째 유스케이스(Use case)를 지루하게 유지하고, 인간을 루프 안에 두며(Human in the loop), 누군가 그것을 프로덕션(Production)이라고 부르기 전에 슬라이스(Slices)를 확인하십시오.

정형 데이터 AI (Tabular AI)는 SQL 명령어가 될 수도 있습니다. 하지만 책임(Responsibility)은 여전히 그렇지 않습니다.