LLM은 Tabular Data에 어떻게 활용될 수 있을까?

LLM은 Large Language Model의 약자다.

말 그대로 방대한 텍스트를 학습하고,
언어를 이해하고 생성하는 모델이다.

LLM은 수많은 문장 속에서
단어와 개념 사이의 의미 관계를 학습한다.

그래서 다음과 같은 일을 할 수 있다.

- 자연어 지시 이해
- 질문에 대한 답변 생성
- 새로운 문제에 대한 Zero-shot 추론
- 적은 예시만으로 Few-shot 학습
- 현실 세계의 개념과 도메인 지식 활용

그런데 여기서 한 가지 의문이 생겼다.

LLM은 언어 모델인데
행과 열로 구성된 Tabular Data에는 어떻게 활용할 수 있을까?

Tabular Data는 문장이 아니다.

나이 | 연봉 | 직업 | 대출 승인 여부
25  | 3000 | 학생 | 거절
42  | 8000 | 회사원 | 승인

LLM은 기본적으로 token sequence를 입력으로 받는다.

그렇다면 이런 표를
LLM이 이해할 수 있는 언어 형태로 바꿔야 한다.

이번 강의는 바로 이 질문에서 시작한다.

LLM의 Semantic Knowledge를
Tabular Machine Learning에 어떻게 활용할 수 있을까?

---

기존 Tabular Model과 LLM의 차이

기존 Tabular Model은 주로
실제로 관찰된 값과 통계적 패턴을 학습한다.

예를 들어 다음 데이터가 있다고 해보자.

Age	BMI	Diagnosis Code	Target
58	31.2	E11	Diabetes
24	21.4	Z00	Normal

XGBoost나 Random Forest 같은 모델은
각 column의 값과 target 사이의 통계적 관계를 학습한다.

하지만 BMI나 Diagnosis Code가
실제 세계에서 어떤 의미를 가지는지는 알지 못한다.

반면 LLM은 이미 텍스트 학습을 통해
다음과 같은 지식을 가지고 있을 수 있다.

BMI는 체질량지수를 의미한다.

E11은 당뇨병과 관련된 진단 코드다.

특정 직업이나 도시, 질병, 상품 이름은
현실에서 각각 특정한 의미를 가진다.

즉, LLM은 Tabular ML에
Semantic Context를 추가할 수 있다.

기존 모델이

숫자 값과 통계적 패턴

을 학습했다면, LLM은 여기에

Column 이름의 의미
Value의 현실적 의미
Task 설명
도메인 지식

을 활용할 수 있다.

강의의 핵심 문장을 정리하면 다음과 같다.

LLM은 Tabular ML을 단순한 수치 패턴 학습에서
Semantic Context를 활용한 추론으로 확장한다.

---

강의에서 다룬 네 가지 질문

이번 강의에서는 LLM과 Tabular Data의 관계를
크게 네 가지 질문으로 나누었다.

1. LLM이 Tabular Data를 직접 예측할 수 있는가?

2. LLM이 다른 Tabular Predictor의 성능을 높일 수 있는가?

3. LLM이 의미적으로 이상한 Sample을 탐지할 수 있는가?

4. 여러 Table과 Task에 전이 가능한
   LLM 기반 Tabular Foundation Model을 만들 수 있는가?

하나씩 정리해보자.

---

1. Table을 Text로 바꾸기

LLM은 표 구조를 그대로 입력받지 않는다.

따라서 Tabular Data를
일렬의 Token Sequence로 변환해야 한다.

이 과정을 다음과 같이 부른다.

Serialization
또는
Linearization

예를 들어 다음 row가 있다고 해보자.

name	age	job
Helen	47	Engineer

이를 여러 형식으로 바꿀 수 있다.

---

JSON 형식

{
  "name": "Helen",
  "age": 47,
  "job": "Engineer"
}

---

Markdown 형식

| name | age | job |
| --- | --- | --- |
| Helen | 47 | Engineer |

---

Attribute-Value 형식

name: Helen, age: 47, job: Engineer

---

문장 형식

Helen is 47 years old and works as an engineer.

---

Python DataFrame 형식

pd.DataFrame({
    "name": ["Helen"],
    "age": [47],
    "job": ["Engineer"]
})

강의 자료에는 이외에도
LaTeX, HTML, CSV와 비슷한 구분자 형식 등
여러 Serialization 방식이 소개됐다.

여기서 중요한 점은 이것이다.

Serialization은 단순한 전처리가 아니라
모델 설계의 일부다.

같은 데이터라도 어떤 형식으로 표현하느냐에 따라
LLM이 보는 구조가 달라질 수 있다.

또한 Token 사용량도 달라진다.

긴 자연어 문장
→ 의미 전달은 좋지만 Token 비용이 큼

짧은 Key-Value 형식
→ Token은 적지만 Context 전달이 부족할 수 있음

즉, LLM을 Tabular Data에 사용할 때는
입력 형식을 어떻게 구성하는지가 매우 중요하다.

---

LIFT

LIFT는 다음 아이디어를 사용한다.

언어가 아닌 머신러닝 Task를
언어 입력과 언어 출력 문제로 바꾸자.

예를 들어 Iris 분류 문제를 생각해보자.

원래 입력은 다음과 같다.

sepal length = 5.1
sepal width = 3.5
petal length = 1.4
petal width = 0.2

이를 문장으로 바꾼다.

An Iris plant has a sepal length of 5.1cm,
a sepal width of 3.5cm,
a petal length of 1.4cm,
and a petal width of 0.2cm.
The class is:

LLM은 다음과 같은 텍스트를 출력한다.

Iris-setosa

즉, 입력도 언어로 만들고
정답도 언어로 출력하게 한다.

LIFT의 특징은
LLM의 Architecture나 Loss를 크게 바꾸지 않는다는 점이다.

기존 언어 모델을
자연어 인터페이스를 통해 Tabular Task에 Fine-tuning한다.

---

TabLLM

TabLLM은 하나의 Tabular Row를
자연어 문자열로 변환한 뒤 분류에 사용한다.

예를 들어 다음 데이터가 있다고 해보자.

Age = 42
Education = Master
Capital Gain = 594

이를 문장으로 바꾼다.

The person is 42 years old.
The education level is Master's degree.
The capital gain is 594 dollars.

그리고 Task를 설명한다.

Does this person earn more than 50,000 dollars?
Answer Yes or No.

LLM은 Zero-shot이나 Few-shot 방식으로
정답을 예측할 수 있다.

TabLLM에서 중요한 결과 중 하나는 다음과 같다.

같은 Table이라도 Serialization 방식에 따라
예측 성능이 달라질 수 있다.

즉,

Column 이름만 나열한 형식
Value만 나열한 형식
자연어 문장
LLM이 변환한 문장

이 각각 다른 결과를 만들 수 있다.

LLM을 사용한다고 끝나는 것이 아니라
어떤 형태로 Table을 보여주는지가 중요하다.

---

TABLET

TABLET은 자연어 Instruction이
Tabular Prediction에 얼마나 도움이 되는지를 분석한다.

예를 들어 환자의 증상 데이터만 주는 경우와
질병에 대한 설명까지 함께 주는 경우를 비교한다.

단순한 입력은 다음과 같을 수 있다.

기침: 아니오
코막힘: 예
귀 통증: 예

여기에 Task Instruction을 추가할 수 있다.

백일해는 보통 반복적인 심한 기침과
특정 호흡기 증상을 동반한다.

주어진 환자가 백일해 진단 대상인지 판단하라.

LLM은 단순한 Feature 값뿐만 아니라
질병에 대한 설명과 판단 기준도 함께 활용한다.

TABLET의 결과는 다음을 보여준다.

- 자연어 Instruction은 Zero-shot 성능을 높일 수 있다.
- Few-shot 환경에서도 Task 설명이 도움이 될 수 있다.
- 사람이 작성한 Instruction뿐 아니라
  자동 생성된 Instruction도 유용할 수 있다.

강의 자료에서는
기존 분류기로부터 두 종류의 Instruction을 만들었다.

Ruleset 기반 Instruction
Prototype 기반 Instruction

Ruleset 방식은 다음과 비슷하다.

결혼 상태가 Married이고
교육 수준이 Bachelor 이상이라면
고소득일 가능성이 높다.

Prototype 방식은 대표 Sample과의 유사성을 설명한다.

이 사람은
고소득 그룹의 대표적인 Sample과 더 비슷하다.

즉, 기존 Tabular Model이 학습한 정보를
LLM이 이해할 수 있는 자연어 Instruction으로 바꾼 것이다.

---

LLM이 직접 예측하는 방식의 한계

여기까지 보면 LLM이
Tabular Predictor 역할을 직접 수행할 수 있다.

하지만 현실적으로 문제가 많다.

1. 모든 Row를 Text로 변환해야 한다.

2. 모든 Sample마다 LLM을 호출해야 한다.

3. 입력 Prompt와 Serialization 형식에 민감하다.

4. 긴 Table은 Context Window를 많이 사용한다.

5. Numerical Reasoning이 항상 정확하지는 않다.

6. 추론 비용과 Latency가 크다.

예를 들어 100만 개의 고객 row를 예측해야 한다고 해보자.

각 row마다 LLM API를 호출한다면
비용과 시간이 매우 커질 수 있다.

따라서 대규모 Tabular Prediction에서는
LLM이 모든 Sample을 직접 예측하는 방식이
항상 현실적인 것은 아니다.

여기서 새로운 방향이 등장한다.

LLM이 최종 예측자가 되지 않고,
기존 Tabular Model을 도와주면 어떨까?

---

2. LLM을 Semantic Component로 사용하기

직접 예측의 대안은
LLM을 Tabular ML Pipeline의 일부로 사용하는 것이다.

예를 들어 LLM은 다음 일을 맡는다.

- 새로운 Feature 생성
- Feature 생성 Rule 개선
- Decision Tree Rule 보정
- 도메인 지식 주입

최종 예측은 다음과 같은 모델이 맡는다.

XGBoost
LightGBM
Random Forest
Linear Model
MLP

즉, 구조는 다음과 같다.

LLM
↓
Semantic Feature 또는 Rule 생성
↓
일반 Tabular Model
↓
최종 Prediction

이 방식은 모든 Test Row를 LLM에 넣지 않아도 된다.

따라서 비용과 Latency를 줄이면서
LLM의 Semantic Knowledge를 활용할 수 있다.

---

CAAFE

Tabular Data에서는
Feature Engineering이 성능에 큰 영향을 준다.

예를 들어 원본 Feature가 다음과 같다고 해보자.

Weight
Height
Income
Debt
Last Login Date

도메인 지식을 활용하면 다음 Feature를 만들 수 있다.

BMI = Weight / Height²

Debt Ratio = Debt / Income

Days Since Last Login

하지만 이런 Feature를 만들려면
데이터와 도메인을 이해해야 한다.

CAAFE는 LLM에게 다음 정보를 제공한다.

- Dataset 설명
- Column 이름
- Task 설명
- 기존 Feature

그리고 LLM에게
새로운 Feature를 만드는 Python 코드를 작성하게 한다.

흐름은 다음과 같다.

1. Dataset Context 제공

2. LLM이 Feature Engineering 코드 생성

3. 생성된 Python 코드 실행

4. Tabular Model로 Cross-validation 수행

5. 성능이 좋아지면 Feature 유지

6. 다시 새로운 Feature 생성

예를 들어 LLM이 다음과 같은 코드를 만들 수 있다.

df["debt_ratio"] = df["debt"] / (df["income"] + 1e-6)

새로운 Feature를 추가한 뒤
모델 성능을 평가한다.

성능 향상
→ Feature 유지

성능 하락
→ Feature 제거

CAAFE의 핵심은 이것이다.

LLM은 Column 이름과 Task 설명에 담긴 의미를
실제 모델이 사용할 수 있는 Feature로 변환한다.

또한 더 강한 LLM이
더 유용한 Feature를 생성할 가능성도 확인됐다.

---

LLM as Few-Shot Feature Engineer

Label이 매우 적은 Few-shot 환경에서는
복잡한 모델을 학습하기 어렵다.

이 연구에서는 LLM에게
적은 수의 학습 Sample과 Task 설명을 보여준다.

그다음 Class별 Rule을 생성하게 한다.

예를 들면 다음과 같다.

Rule 1:
Age >= 50이고 Debt Ratio가 높으면
고위험 Class일 가능성이 높다.

Rule 2:
Age < 30이고 Income이 높으면
저위험 Class일 가능성이 높다.

각 Rule은 새로운 Binary Feature가 된다.

Rule 1 만족 → 1
Rule 1 불만족 → 0

이렇게 생성된 Feature를 이용해
간단한 Linear Classifier를 학습한다.

또 LLM이 서로 다른 Rule을 여러 번 생성하면
각 Rule은 서로 다른 Semantic Hypothesis를 담을 수 있다.

그래서 여러 Predictor를 만든 뒤
Ensemble한다.

LLM Rule Set 1 → Linear Model 1

LLM Rule Set 2 → Linear Model 2

LLM Rule Set 3 → Linear Model 3

↓ Ensemble

최종 예측

즉, LLM은 직접 모든 Row를 예측하지 않는다.

LLM은 Rule과 Feature를 만들고,
최종 Prediction은 가벼운 모델이 수행한다.

---

Decision Tree Reasoning을 활용한 Feature Generation

다음 연구에서는 LLM을
Feature Generation Rule의 Optimizer로 사용한다.

기본 흐름은 다음과 같다.

1. LLM에게 새로운 Feature 아이디어 요청

2. 해당 Feature를 만드는 Rule 생성

3. Rule을 적용해 새로운 Column 생성

4. Tabular Model 학습

5. Validation Score 측정

6. Decision Tree Rule을 이용해 결과 해석

7. 해석 결과를 다시 LLM에 제공

8. Rule 개선

예를 들어 질병 예측 문제에서
LLM이 다음 Feature를 제안했다고 해보자.

흡연 가능성

원본 데이터에는 흡연 여부가 직접 없을 수 있다.

하지만 다음 Feature를 조합해
간접적인 Rule을 만들 수 있다.

호흡 곤란이 있고
특정 증상이 존재하면
흡연 가능성이 높다.

새로운 Column을 만든 뒤
모델의 성능을 평가한다.

여기서 단순히 Validation Score만 주는 것이 아니라
Decision Tree가 만든 Rule을 함께 피드백한다.

호흡 곤란 = Yes
피로 = Yes
→ 질병 예측

이 Rule은 LLM에게
이전 Feature가 어떤 방식으로 사용되었는지 알려준다.

강의 자료에서는 Decision Tree Reasoning이
도움이 되는 이유를 다음처럼 설명한다.

Validation Score만 제공
→ 왜 성능이 변했는지 알기 어려움

Decision Tree Rule 제공
→ 어떤 Feature와 조건이 유용했는지 해석 가능

즉, Decision Tree는
LLM에게 간결하고 해석 가능한 Feedback을 제공한다.

이 과정을 반복하면
LLM이 점점 더 나은 Feature Rule을 생성할 수 있다.

---

DeLTa

DeLTa는 LLM과 Decision Tree를 결합하지만
Feature Generation과는 방향이 조금 다르다.

핵심은 다음과 같다.

여러 Decision Tree의 Rule을 LLM이 정제하고,
그 Rule을 이용해 기존 Tree의 예측 오류를 보정한다.

구조는 다음과 같다.

여러 Decision Tree
↓
Tree Rule 추출
↓
LLM이 Rule 통합 및 개선
↓
Refined Rule 생성
↓
기존 Decision Tree 예측 보정

중요한 점이 하나 있다.

DeLTa는 반드시 Column 이름의 Semantic Knowledge를 사용하는 방식은 아니다.

강의 자료에서는
Column 이름의 의미보다 Decision Tree Rule 자체를 이용한다고 설명한다.

즉, LLM은 다음과 같은 Rule을 읽고 정제한다.

x1 > 3.2
x4 <= 0.7
x7 = 1

Column 이름이 의미 없는 x1, x4여도
Rule 구조를 바탕으로 개선을 시도할 수 있다.

이 점에서 DeLTa는
LLM의 일반적인 Semantic Prior뿐만 아니라
Language Reasoning 능력 자체를 활용하는 사례라고 볼 수 있다.

---

LLM을 Semantic Component로 사용하는 이유

이 방식의 장점은 명확하다.

- 모든 Test Row를 LLM에 넣지 않아도 된다.
- 추론 비용이 줄어든다.
- Latency를 줄일 수 있다.
- 기존 Tabular Model의 빠른 예측 성능을 유지한다.
- Semantic Knowledge를 Pipeline에 주입할 수 있다.

즉, 실제 시스템에서는

LLM이 직접 예측하기보다
모델이 더 잘 예측할 수 있도록 돕는 역할

이 더 현실적인 사용 방법일 수 있다.

---

3. LLM을 이용한 Tabular Anomaly Detection

Anomaly Detection은 이상치를 찾는 문제다.

처음에는 이상치를 이렇게 생각하기 쉽다.

값이 너무 크거나 작으면 이상치다.

하지만 실제 이상치는 그렇게 단순하지 않다.

희귀한 값이라고 항상 이상치는 아니다.

반대로 자주 등장하는 값도
잘못된 Context에서는 이상할 수 있다.

예를 들어 다음 거래를 보자.

결제 금액: 500만 원
결제 지역: 서울
사용자 직업: 기업 임원

이 거래는 큰 금액이지만
반드시 이상 거래라고 할 수는 없다.

반대로 다음 거래는 금액이 작아도 이상할 수 있다.

결제 금액: 5만 원
결제 지역: 해외
직전 결제 위치: 서울
시간 차이: 2분

숫자 하나만 보면 평범하지만
전체 Context를 보면 의심스럽다.

즉, Anomaly는 도메인과 상황에 따라 결정된다.

기존 모델은 주로 Raw Feature Value를 사용한다.

하지만 LLM은 다음 정보를 활용할 수 있다.

- Column 설명
- 단위
- Dataset 설명
- 도메인 지식
- Feature 사이의 의미 관계

---

AnoLLM

AnoLLM은 정상 Tabular Row를
Text로 변환하고 LLM에 학습시킨다.

기본 아이디어는 다음과 같다.

정상 데이터와 비슷한 문장은 높은 확률을 갖고,
비정상 데이터는 낮은 확률을 가질 것이다.

흐름은 다음과 같다.

1. Normal Row를 표준화된 문장으로 변환

2. 정상 데이터만 사용해 LLM Fine-tuning

3. Test Row를 Text로 변환

4. LLM Likelihood 계산

5. Likelihood가 낮으면 Anomaly로 판단

예를 들어 정상 거래가 다음 형태라면

User 1 made a transaction of 50 dollars in San Jose.

모델이 본 적 없는 이상한 조합은
낮은 Likelihood를 가질 수 있다.

User 1 made a transaction of 1599 dollars in Delhi.

AnoLLM의 장점은
숫자형과 범주형이 섞인 데이터도
Text 형태로 통합할 수 있다는 것이다.

하지만 한계도 있다.

- 정상 데이터로 LLM을 Fine-tuning해야 한다.
- 추론 비용이 크다.
- 낮은 Language Likelihood가
  항상 실제 Semantic Anomaly를 의미하지는 않는다.

즉, 언어 모델이 문장을 낯설게 느끼는 것과
현실에서 비정상인 것은 완전히 같지 않을 수 있다.

---

ReTabAD

필기에서 RETADAD라고 적은 부분은
정확히는 ReTabAD다.

ReTabAD가 던지는 질문은 다음과 같다.

Tabular Anomaly Detection에서
Metadata가 얼마나 중요한가?

기존 Anomaly Detection Benchmark는
주로 Feature 값만 제공했다.

0.31, 25, 117, 1, 0

하지만 각 값이 무엇을 의미하는지 설명하지 않는 경우가 많다.

- Column 이름
- 단위
- Feature 설명
- Dataset 설명
- Label의 의미
- 도메인 Context

이런 정보가 빠져 있었다.

그런데 LLM의 장점은
바로 Textual Metadata와 Semantic Knowledge를 활용하는 것이다.

Metadata가 없다면 LLM도
값의 의미를 알기 어렵다.

ReTabAD는 기존 Tabular Dataset에
다음 정보를 복원한 Benchmark를 만든다.

- Dataset 이름
- Dataset 설명
- Column 이름
- Column 설명
- 데이터 타입
- Label 설명
- Anomaly 정의

예를 들어 Prothrombin = 11.5라는 값만 보면
무슨 의미인지 알기 어렵다.

하지만 다음 설명을 함께 제공하면 달라진다.

Prothrombin:
혈액 응고 시간을 초 단위로 나타낸 값이며,
간 기능 이상과 관련될 수 있다.

이제 LLM은 단순히 숫자가 크다는 것뿐 아니라
그 값이 간 기능 저하를 의미할 수 있다는 Context를 활용한다.

ReTabAD는 Semantic Metadata를 활용하면
Context-aware Zero-shot Anomaly Detection과
더 해석 가능한 Reasoning이 가능하다는 점을 보여준다.

---

AutoAnoEval

Anomaly Detection에서는
어떤 모델이 좋은지 선택하는 것도 어렵다.

왜냐하면 Validation Set에
실제 Anomaly Label이 없을 수 있기 때문이다.

정상 Sample만 존재
↓
어떤 Detector가 좋은지 평가하기 어려움

또 Anomaly Detector마다
잘 잡는 이상치 종류가 다를 수 있다.

- 극단적으로 큰 값
- 정상 경계에 가까운 미세한 이상치
- Feature 조합이 이상한 Sample
- 특정 도메인 Rule을 위반하는 Sample

그래서 AutoAnoEval은 다음 질문을 던진다.

평가용 Anomaly를 직접 생성할 수는 없을까?

핵심 아이디어는
Decision Tree와 LLM을 이용해
의미 있는 Pseudo-Anomaly를 생성하는 것이다.

먼저 정상 데이터를 기반으로
Decision Tree의 정상 경로를 추출한다.

Temperature <= 37.5
Humidity <= 80
Pressure >= 1000

그다음 LLM이 이 정상 경로의 일부 조건을
의미 있게 비튼다.

Temperature > 42
Humidity는 정상
Pressure는 정상

너무 무작위적인 값을 만드는 것이 아니라
도메인적으로 가능한 Anomaly Rule을 생성한다.

이렇게 만든 Pseudo-Anomaly를 이용해
여러 Detector를 평가한다.

Pseudo Evaluation Set
↓
여러 Anomaly Detector 평가
↓
가장 좋은 모델 선택

강의 자료에서는
이렇게 만들어진 평가 Set이
실제 Anomaly에서의 모델 성능과 가까운 추정치를 제공할 수 있다고 설명한다.

즉, LLM은 여기서 Anomaly를 직접 탐지하기보다
Detector를 평가하고 선택하기 위한 데이터를 만드는 역할을 한다.

---

LLM이 Anomaly Detection에 유용한 이유

정리하면 LLM은 Tabular Anomaly Detection에서
세 가지 방식으로 활용될 수 있다.

1. Anomaly Scoring
정상 Row의 Language Likelihood를 학습

2. Context-aware Detection
Metadata와 Domain Knowledge를 이용해 이상 여부 판단

3. Model Selection
Semantic Pseudo-Anomaly를 생성해 Detector 평가

기존 Anomaly Detection이

값이 얼마나 희귀한가?

를 중심으로 봤다면, LLM은

이 값과 조합이
현실적인 Context에서 말이 되는가?

를 판단하는 데 도움을 줄 수 있다.

---

4. LLM 기반 Tabular Foundation Model

마지막 질문은 이것이다.

여러 Table과 Task에서 학습한 지식을
새로운 Table에도 전이할 수 있을까?

이미 자연어에서는 Foundation Model이 존재한다.

대규모 Text Pretraining
↓
새로운 Task에 Zero-shot / Few-shot 적용

Tabular Data에서도 같은 방향을 생각할 수 있다.

수많은 Table과 Prediction Task 학습
↓
새로운 Table에 적용

하지만 Tabular Data는 매우 이질적이다.

Table마다 Column 수가 다름

Column 이름이 다름

데이터 타입이 다름

Label 의미가 다름

Task가 분류일 수도 있고 회귀일 수도 있음

따라서 여러 Table을
하나의 공통 형식으로 통합하는 것이 어렵다.

---

TabuLa-8B

TabuLa-8B는
LLM을 기반으로 만든 Tabular Foundation Model이다.

Base Model은 Llama 3-8B다.

핵심 아이디어는 다음과 같다.

수많은 Tabular Prediction Task를 Text로 Serialization한 뒤
LLM을 대규모로 Fine-tuning한다.

강의 자료에 따르면 학습 데이터는 다음 규모다.

약 21억 개의 Row

400만 개 이상의 고유 Table

329개의 Unseen Dataset에서 평가

각 Table을 공통된 언어 형식으로 바꾼 뒤
여러 Prediction Task를 학습시킨다.

그 결과 새로운 Dataset에서도
Zero-shot 또는 Few-shot Prediction을 수행할 수 있다.

Foundation Model의 장점은
Label이 적은 환경에서 특히 드러난다.

학습 Sample이 충분함
→ 기존 XGBoost도 강력함

학습 Sample이 매우 적음
→ 사전학습된 Tabular Foundation Model이 유리할 수 있음

즉, TabuLa-8B는
LLM의 사전학습과 Transfer Learning 능력을
Tabular Prediction에 적용한 시도라고 볼 수 있다.

---

전체 흐름 정리

이번 강의의 흐름을 정리하면 다음과 같다.

---

1. LLM이 직접 예측

Table
↓
Serialization
↓
Prompt + Task Description
↓
LLM
↓
Prediction

대표 연구:

LIFT
TabLLM
TABLET

장점:

- Semantic Knowledge 활용
- Zero-shot / Few-shot 가능
- 자연어 Task 설명 활용

단점:

- 비용이 크다.
- 긴 Table에 약하다.
- Serialization에 민감하다.
- Numerical Reasoning이 어려울 수 있다.

---

2. LLM이 다른 Model을 보조

LLM
↓
Feature 또는 Rule 생성
↓
일반 Tabular Model
↓
Prediction

대표 연구:

CAAFE
LLM Few-shot Feature Engineer
OCTree
DeLTa

장점:

- LLM을 매 Row마다 호출하지 않아도 된다.
- 기존 모델의 빠른 추론을 유지할 수 있다.
- Semantic Knowledge를 Feature와 Rule로 변환할 수 있다.

---

3. LLM을 Anomaly Detection에 활용

정상 Row의 Likelihood 학습

Metadata를 이용한 Semantic Reasoning

Pseudo-Anomaly 생성과 Model Selection

대표 연구:

AnoLLM
ReTabAD
AutoAnoEval

---

4. LLM 기반 Tabular Foundation Model

다양한 Table과 Task에서 사전학습
↓
새로운 Dataset에 Zero-shot / Few-shot 전이

대표 연구:

TabuLa-8B

---

이번 강의를 들으며 느낀 점

처음에는 이렇게 생각했다.

LLM은 언어 모델인데
굳이 Tabular Data를 맡길 이유가 있을까?

숫자 예측은 XGBoost나 LightGBM이 더 빠르고,
이미 Tabular Data에서 강력한 모델도 많다.

실제로 LLM에게 모든 Row를 직접 예측하게 하는 방식은
비용과 효율 측면에서 좋은 방법이 아닐 수 있다.

하지만 강의를 들으면서
LLM의 역할을 조금 다르게 보게 되었다.

LLM의 진짜 장점은
숫자 계산 그 자체가 아니었다.

Column 이름의 의미를 이해하고,

Task 설명을 이해하고,

도메인 지식을 활용하고,

새로운 Feature와 Rule을 제안하고,

왜 특정 조합이 이상한지 설명하는 것

이 LLM의 강점이었다.

즉, LLM을 기존 Tabular Model의 대체재로만 볼 필요는 없다.

오히려 다음과 같은 역할이 더 잘 맞을 수 있다.

Semantic Feature Engineer

Rule Optimizer

Decision Tree Feedback Interpreter

Anomaly Context Reasoner

Foundation Model

---

결론

결론은 간단하다.

LLM은 Tabular Data를 직접 예측할 수 있다.

Table을 Text로 Serialization하고
Task Description과 Instruction을 제공하면
Zero-shot 또는 Few-shot Prediction도 가능하다.

하지만 모든 Sample을 LLM에 입력하는 방식은
비용과 Context Length 측면에서 한계가 있다.

그래서 더 현실적인 방향은 다음과 같다.

LLM의 Semantic Knowledge를 활용하고,
최종 예측은 효율적인 Tabular Model이 수행하도록 하는 것.

LLM은 다음과 같은 작업에 강점을 가진다.

- 의미 있는 Feature 생성
- Rule 개선
- Decision Tree 예측 보정
- Context-aware Anomaly Detection
- Pseudo-Anomaly 생성
- 새로운 Table로의 Knowledge Transfer

결국 이번 강의의 핵심은 이것이라고 생각한다.

LLM을 Tabular Predictor로 무조건 사용하는 것이 아니라,
Tabular ML Pipeline에서 Semantic Knowledge가 필요한 지점에 배치하자.

Tabular Data의 성능은
Feature를 어떻게 구성하고
Task와 Context를 어떻게 이해하느냐에 따라 크게 달라진다.

그리고 LLM은 바로 그
의미를 이해하고 활용하는 부분에서
기존 Tabular Model을 보완할 수 있다.