Lu, Weizheng, et al. "Large language model for table processing: A survey." Frontiers of Computer Science 19.2 (2025): 192350.
https://doi.org/10.1007/s11704-024-40763-6

KCC에 제출했던 논문과는 별개로, 새로운 연구 주제를 정하기 위해 서베이 논문들을 열심히 읽고 있다.
LLM과 평소 관심있던 Table data를 엮어보려고 열심히 아이디어를 짜내고는 있는데, 일단 LLM으로 자동화할 수 있는 테이블 관련 작업(Task)이 무엇인지 파악하는 것이 더 중요하다는 생각이 들었다.
이 논문은 LLM이 테이블 데이터를 기반으로 수행할 수 있는 다양한 작업들을 구체적으로 정리했고, 특히 '테이블 데이터'를 명확하게 분류하고 정의했다는 점에서 매우 유용하다고 느꼈다.

Abstract

해당 논문은 Frontiers of Computer Science저널에 개제된 survey 논문으로써, Table과 관련된 작업을 LLM(Large Language Model), 또는 VLM(Visual Language Model)에 적용한 연구들에 대해 체계적으로 정리하였다.

이 때, 테이블과 관련된 작업들은 1)DB Query, 2) Spread Sheet 조작, 3) Web Table QA, 4) 이미지 기반의 테이블 정보 추출 등, 사용자의 시나리오와 기술적 측면 모두를 포함한다.

이에 따라 테이블 처리에 특화된 LLM, VLM을 학습시키는 기술 및 LLM 기반 에이전트를 활용하는 prompt engineering 기법들도 소개한다. 또한, CoT(Chain of Thought)에 기반한 slow thinking과 같은 여러 도전과제들을 제시한다.

LLM의 tabular data 처리에 관한 다른 survey와의 큰 차이점은 테이블 작업을 사용자의 입장에서 분류하고 제시하였다는 점이다. 또한, 대부분 서베이는 모델의 사전학습이나 파인튜닝에 초점을 맞추거나, 특정 테이블 작업에만 맞추는데 해당 논문은 전반적인 테이블 작업에 대한 시나리오를 다루었다는 점에서 의의가 있다.

Ⅰ.Introduction

일반적으로 LLM을 학습시킬 때 사용하는 텍스트 데이터와는 달리, Table data는 구조화되어있는 2차원의 Schema이다. 인간은 해당 테이블을 수직(column), 수평(row)로 이해할 수 있으나, LLM은 테이블의 다차원적 구조를 이해하는데 있어 어려움을 겪는다.

이에 더해 테이블 데이터를 처리하기 위한 작업들은 수치 연산(comparisons, aggregations), 데이터 전처리(type annotaion, missing value detection etc...), 피처 엔지니어링과 시각화 등 매우 복잡한 추론을 필요로 한다.

끝으로 LLM이 효과적으로 테이블 데이터를 처리하기 위해서는 인간이 사용하는 외부 도구(Excel, Python, SQL)와의 통합과 활용이 필요하다.

---

이에 따른 초기 연구들의 방향성은 LLM을 Tabular Data에 맞추어 pre-training, 혹은 fine-tuning하는 것이었다. 예를 들어, Positional Embedding, Attention, Pre-training object 등을 Tabular data에 맞추어 적용하였다. 이러한 방법은 Table QA, 사실 검증(Fact Verification)등 특정 작업에서는 좋은 성능을 보였으나, 범용성이 부족하다는 한계가 존재했다.

최근에는 LLM 기반의 테이블 작업에 대한 접근 방식이 아래 두 가지 방식으로 변화하고 있다.
1) 테이블 데이터셋을 수집하고, 전용 모델을 fine-tuning 하거나, pre-training한다.
2) LLM의 강력한 reasoning을 활용하여 prompting을 하거나, LLM 기반 agent를 구현한다.

이러한 기술들은 Instruction-Tuning, In-Context Learning(ICL), Chain-of-Thought reasoning(CoT) 등을 포함하거나 활용한다.

Ⅱ. Table types and table tasks

1. Table definition

(a) SpreadSheet(SS)
전 세계 인구의 10%정도가 사용할 정도로 폭넓게 사용되는 테이블 데이터 시스템이다. 폰트나 색상같은 스타일로 가독성이 높고, 특정 데이터를 강조할 수 있다. 하지만, Fig.2의 (a)에 제시되어있듯이 셀 병합, 계층적인 열 구조, 주석 등 정형화되지 않은 레이아웃은 기계가 parsing하기 어렵게 하는 주요 요인이다.

(b) Web Table(WT)
웹에서의 테이블은 HTML, Markdown, JSON, XML 등 다양한 형식과 언어로써 존재한다.
이에 대한 대표적인 예시로 Wikipedia page가 Fig2의 (b)에 제시되어있다. 또한, 웹 테이블을 구조화하기 위한 프로젝트인 WDC(Web Data Commons) project는 Common Crawl에서 수집한 Billion 단위의 웹 페이지들을 테이블로 변환하고, Wikipedia에서 million 단위의 테이블을 추출하기도 하였다.

(c) Database(DB)
Fig.2의 (c)에 제시되었듯이 관계형 DB는 매우 구조화되어있고, Schema가 명확하게 정의된 상태에서 생성된다. 유저가 이와 상호작용하기 위해서는 SQL이 필수적이다.

(d) Document(DOC)
또 다른 유형의 테이블은 문서 format 내부에 삽입되어있는 테이블이다. 즉, Fig.2의 (d)에 제시된 것처럼 .png, .jpg, .pdf, .docx 등이 해당된다.
DOC 내부에 존재하는 테이블은 문서 내에서 위치를 파악하고, 내용을 추출하여 구조화한 뒤, 다른 테이블 형식(SS, WT)와 같은 형태로 변형해야한다.

SS는 주로 사용자 조작을 자동화하는 copilot 역할을 목표로, WT는 QA 작업에, DB는 NL2SQL을 활용해 분석 작업을 보조하는 역할을 한다. 또한 DOC는 탐지 -> 구조화 -> 변환의 과정을 거쳐야한다. 테이블은 정확한 2차원 좌표계를 기반으로 하므로, 해당 과정에서 열이나 행이 어긋날 경우 정보가 의미가 사라진다는 어려움이 존재한다.

2. Table tasks

Table.1은 LLM을 통해 자동화 가능한 테이블 task들을 요약한 결과이다.

먼저, 가장 전통적인 Table-to-text 작업으로는 Table QA와 fact verificaiton이 있다.

외부 지식에 기반한 작업은 data cleaning(데이터 정제), Column/Row/Cell population(열, 행, 셀에 대한 자동 생성), Entity Linking(개체 연결), column type annotation(column의 데이터타입 분류)로 분류 가능하다.

Spreadsheet manipulation의 경우 앞서 언급한 바와 같이 SS에 대한 조작을 AI가 API, 또는 수식을 활용해 자동으로 수행하는 것을 의미한다. NL2SQL은 자연어 질문을 SQL query로 번역하는 작업으로 매우 오랜 시간동안 연구되어온 주제이다.

Data analysis의 경우 기존에 전문가에 의해 수행되던 feature engineering, ML 등의 요소로 구성되며, Table detection/extraction은 DOC에서 테이블의 위치를 탐지하고, 내용을 추출하는 과정을 의미한다.

3. Data lifecycle

테이블 데이터의 lifecyle은 아래와 같다.

1. 데이터 입력(Data Entry)
2. 데이터 정제(Data Cleaning)
3. 데이터 CRUD(Create, Read, Update, Delete)
4. 데이터 분석(Data Analysis)
5. 데이터 시각화(Data Visualization)

최종 사용자(end-user)는 이 단계들 중 어딘가에 위치해있다. 따라서 end-user가 AI와 상호작용하는 것은 다음 3가지 중 하나가 된다.

(a). Beside : Applicaiton 옆에 copilot을 추가
(b). Inside : AI 기반 데이터 분석, LLM이 중심인 경우 등
(c). Outside : AI가 여러 application과 작업을 orchestration하는 경우.

Ⅲ. Table data representation

1. Text Representation

LLM은 선형적인 prompt를 요구하지만, 테이블은 2차원 구조와 schema를 가진다. 따라서 테이블을 프롬프트로 변환할 때는 의미를 유지하는 것이 가장 중요하다.

가장 단순하고 흔한 방식은 테이블을 Markdown 형태로 serialize 하는 것이다. 각 row는 줄바꿈으로, 셀은 '|'과 같은 seperator를 이용해 분리한다.

여러 연구에서 직렬화 방식(CSV, markdown, JSON, HTML, pandas dataframe, etc...)을 비교하여 LLM이 테이블 데이터를 얼마나 잘 이해하는지 평가했는데, 결과적으로는 HTML과 markdown, csv가 가장 효과적임이 밝혀졌다. 이는 LLM이 code와 web table 형식을 가장 많이 학습하였기 때문으로 추측된다.
그러나, Spreadsheet의 경우 병합된 셀이나 계층적인 구조가 존재하기에 단순한 직렬화로는 부족하다. Tian et al.은 이러한 문제점에 대해 이질적인 행과 열을 기준(anchor)로 설정하고, 역색인(inverted index) 스타일의 encoding을 활용해 셀의 위치, 값, 스키마를 JSON 딕셔너리 형태로 변환하는 방법을 제시하기도 하였다.

일부 연구는 NL2SQL을 위해 Schema 표현에 대해 집중하였는데, 이는 프롬프트에 NL question, table schemas, instructions를 포함하는 방식이였다.
예를 들어, table schema는 일반적인 text나 SQL 형태(ex. CREATE TABLE)과 같이 표현 가능하고, Foreign key는 여러 테이블 간의 관계를 나타낼 수 있다.

2. Visual and Layout Representation

Web Table, Spreadsheet, DOC와 같은 형태의 table은 색상, 강조(bold체) 등 시각적인 단서를 포함할 수 있다. 이러한 단서는 VLM이 정확한 정보를 처리하는데 도움이 될 수 있을 것이다. 이에 대해 Deng et al.은 LLM이 Text table을, VLM이 image table을 처리할 때 성능을 비교하였고, 이미지 기반의 테이블 표현이 복잡한 추론에 있어 유리하다는 결론을 제시하였다.

LayoutLM과 같은 모델은 광학 문자 인식(Optical Character Recognition, OCR), PDF parser를 활용해 이미지 또는 PDF 테이블을 처리한다. 혹은 Table-LLaVA, Xia et al.과 같은 연구에서는 멀티모달을 활용하기도 한다.

Visual Embedding을 생성할 때는 image, position, segment embedding을 모두 조합한다. 이 때 LayoutLM, TableVLM은 ResNet을, Table-LLaVA는 ViT를 사용한다.

Layout Embedding은 테이블 이미지 내에서 공간 정보, 즉 행과 열의 분리 정보를 포착한다. LayoutLM과 TableVLM은 좌표를 0~1000 사이의 정수로 정규화/이산화 하고, x축과 y축에 대한 별도의 임베딩을 생성하여 2차원 공간 정보를 표현한다.

---

=> 4절 부터는 (2)에서 이어서 작성