Lee, Wonjin, et al. "Piece of Table: A Divide-and-Conquer Approach for Selecting Subtables in Table Question Answering." arXiv preprint arXiv:2412.07629 (2024).

Piece of Table: A Divide-and-Conquer Approach for Selecting Subtables in Table Question Answering

Abstract

Language Model(LM)을 테이블에 적용하는 것은 2차원 테이블과 1차원 텍스트 간의 본질적인 구조적 차이 때문에 어렵다. LM은 원래 1차원 텍스트를 위해 설계되었기 때문이다. 더욱이, 선형화된(linearized) 테이블을 LM에 적용할 경우, self-attention 메커니즘이 부과하는 최대 토큰 길이 제약으로 인해 대규모 테이블에 걸쳐 있는 컨텍스트를 포괄적으로 이해하기 어렵다.
이러한 문제들을 해결하기 위해 우리는 subtable 기반 Question Answering(QA)을 위한 새로운 프레임워크인 PieTa (Piece of Table) 를 제안한다.
PieTa는 다중 해상도(multiresolution) 반복 프로세스를 통해 작동한다:

1. 테이블을 더 작은 window로 분할한다.
2. 각 window 내에서 LM을 사용하여 관련 셀을 선택한다.
3. 이 셀들을 병합하여 subtable을 형성한다.

이러한 접근 방식은 긴 컨텍스트 입력의 한계를 완화하면서 여러 행과 열에 걸친 종속성을 모델이 포착할 수 있도록 한다. 간단한 반복적인 subtable union 알고리즘으로 구현된 PieTa는 기존의 subtable 기반 QA 접근 방식보다 크게 향상된 성능을 달성한다.

1 Introduction

테이블은 정보를 선별된 행과 열로 구성하여 일반 텍스트보다 더 접근하기 쉽고 이해하기 쉽게 만듦으로써 데이터 복잡성을 효과적으로 완화한다. 결과적으로, 테이블 질의응답(QA)을 포함한 다양한 자연어 처리 task들이 이러한 구조화된 형식에서 정보를 추출하고 해석하기 위해 개발되었다 (Zhong et al., 2017; Pasupat and Liang, 2015; Nan et al., 2022).

그러나 테이블에 (대규모) **Language Model (LM)**을 적용하는 것은 테이블과 텍스트 간의 본질적인 구조적 차이 때문에 어렵다. LM에 익숙한 텍스트는 1차원적이며 선형 시퀀스(예: 래스터 순서)로 읽히고, 문장 내에서 문맥적 관계가 제한된다. 토큰 순서가 변경되면 문장의 의미가 극적으로 바뀔 수 있다. 반면, 테이블은 본질적으로 2차원적이며, 수평 및 수직 해석이 모두 필요하다. 텍스트와 달리 테이블은 셀 간에 명확한 문맥적 흐름이 없는 경우가 많으며, 열이나 행의 순서를 변경해도 반드시 의미가 바뀌지는 않는다 (Li et al., 2024).

Question: How many total medals has the United States won in women's figure skating?

Figure 1: 제안하는 PieTa (Piece of Table) 프레임워크 개요. 입력 테이블과 질문으로 시작하여, 우리의 알고리즘은 테이블을 더 작은 window로 반복적으로 나누고, 이 window 내에서 Language Model을 사용하여 관련 셀을 선택(중간 subtable 형성)하고, 최종 subtable이 구성될 때까지 이들을 병합하여 subtable을 합성한다. 코드는 승인 후 공개될 예정이다.

테이블 QA의 최근 발전은 이러한 구조적 차이를 수용하는 데 중점을 두었다. 예를 들어, Liu et al. (2022); Jiang et al. (2022)은 보조 SQL 쿼리에 의해 유도되는 테이블 QA 특정 pre-training objective를 사용했고, Herzig et al. (2020); Yang et al. (2022); Yin et al. (2020)은 linearized table에 positional embedding을 적용하는 것을 탐구했다. 이러한 holistic approach의 주요 한계는 Transformer 기반 모델의 계산 제약에 있다. Transformer는 일반적으로 self-attention을 512 또는 1,024 토큰으로 제한하는데, 이는 대규모 테이블을 처리하기에는 턱없이 부족하다 (Figure 5 참조). 결과적으로, 이러한 방법들은 대규모 테이블이나 관련 없는 항목이 많은 테이블에서 어려움을 겪는다 (Patnaik et al., 2024).

Holistic approach의 한계를 극복하기 위해 다른 방법들은 테이블에서 관련 정보를 미리 추출하는 데 중점을 둔다. 이러한 방법들은 먼저 LM을 사용하여 주어진 질문을 SQL 또는 Python 스크립트와 같이 tabular data retrieval에 적합한 논리적 형식으로 변환한다 (Cheng et al., 2023; Ni et al., 2023). 이상적으로, 잘 생성된 코드는 관련 정보를 효과적으로 검색하여 후속 QA 프로세스가 관련 없는 방해 요소를 우회할 수 있도록 한다. 그러나 LM이 테이블의 광범위한 변형을 수용할 수 있을 만큼 다재다능한 유연한 프로그램을 생성하도록 하는 것은 여전히 상당한 도전 과제이다 (Liu et al., 2024b).

Subtable selection 방법은 holistic approach와 code generation 방법의 한계를 균형 있게 완화하는 것을 목표로 한다. 이러한 방법들은 먼저 관련 subtable을 추출하여 검색 공간을 줄인 다음, 이를 테이블 QA 리더에 공급하여 최종 답변을 구성한다.

예를 들어, Lin et al. (2023)의 **inner table retriever (ITR)**는 질문과 각 개별 행 또는 열 간의 유사성을 계산하여 주어진 질문과 일치하는 행과 열을 선택한다. 이 접근 방식은 계산적으로 효율적이며 간단한 질문에 답하는 데 효과적이다. 그러나 여러 행 및/또는 열에 걸친 종속성을 포착하는 데 어려움을 겪을 수 있다. 예를 들어, "Which was the next aircraft that came into service after Cessna 404 Titan?"이라는 질문에 답할 때, ITR은 Cessna 404 Titan 이후에 서비스를 시작한 항공기를 식별해야 하지만, 언제 서비스를 시작했는지에 대한 정보가 없기 때문에 어려움에 직면한다.

Ye et al. (2023)의 Dater는 LM in-context learning을 사용하여 여러 행을 함께 선택함으로써 이러한 한계를 해결한다. 이는 독립적인 행 선택을 개선하지만, linearized table에서 직접 답변을 생성할 때 발생하는 문제와 유사하게, 2차원 테이블에 적용된 1차원 LM의 한계를 여전히 계승한다. 또한, LM은 일반적으로 긴 문맥 입력을 이해하고 결합하는 데 어려움을 겪는데 (Liu et al., 2024a; Wang et al., 2024), 이는 대규모 테이블을 포함하는 테이블 QA에서 특히 두드러지는 문제이다.

본 논문에서는 subtable 기반 QA를 위한 새로운 프레임워크인 **PieTa (Piece of Table)**를 제시한다. PieTa는 세 가지 주요 단계를 통해 작동한다: Divide 단계에서는 주어진 테이블이 더 작은 window로 분해된다. 이어서 Conquer 단계에서는 LM이 각 window에서 주어진 질문과 일치하는 셀을 선택하여 (Figure 1) 중간 subtable을 구성한다. 마지막으로 Combine 단계에서는 개별 window에서 추출된 중간 subtable들이 병합되어 새로운 테이블을 형성한다. 이 과정은 결과 테이블을 새로운 입력으로 간주하여 최종 subtable이 구성될 때까지 반복된다.

PieTa는 긴 문맥 입력의 문제를 피하면서 여러 행 또는 열에 걸친 종속성을 효과적으로 포착한다. 이는 원본 테이블 내에서 장기적인 종속성을 포착할 수 있도록 하는 multi-resolution combination approach를 통해 달성된다. WikiTableQuestions (WikiTQ; Pasupat and Liang, 2015) 및 WikiSQL (Zhong et al., 2017) 데이터셋에서 평가된 PieTa는 QA 정확도 및 subtable selection 성능에서 상당한 개선을 달성한다.

2 Related Work

Holistic table QA readers.
Table QA에서 reader는 종종 **Language Model (LM)**로 구현되며, 전체 테이블 또는 사전 처리된 subtable을 사용하여 질문에 대한 답변을 생성한다. 예를 들어, TaPEx reader는 SQL query 쌍을 사용하여 테이블에서 답변을 합성함으로써 SQL 실행 엔진을 모방한다 [Liu et al., 2022]. 이 모델은 BART backbone model [Lewis et al., 2020]을 사용하며, 이 모델은 합성 SQL query로 사전학습된 후 자연어 질문에 답변하도록 fine-tuning된다.

대규모의 고품질 table-SQL query 쌍을 생성하여 명확한 답변을 도출하는 것은 비용이 많이 들 수 있다. OmniTab은 복잡한 SQL query를 일반 텍스트 설명으로 대체하여 이 과정을 단순화한다 [Jiang et al., 2022]. 이 모델은 각 테이블에 텍스트 설명이 동반된다고 가정하며, 이 설명은 table QA task에 대한 fine-tuning 전에 사전학습에 사용된다.

이러한 holistic 접근 방식은 대규모 테이블에 적용될 때 LM의 한계를 물려받는다. 일반적으로 테이블의 셀 중 작은 부분집합만이 주어진 질문과 관련되기 때문이다 [Patnaik et al., 2024]. 우리의 접근 방식은 이러한 관련 셀을 효율적으로 식별하고 선택하여 reader가 더 정확한 답변을 생성하도록 안내한다.

Guiding readers through subset selection.
질문별로 테이블에서 관련 없는(irrelevant) 정보와 중복된(redundant) 정보를 필터링하는 것은 LM reader가 주의 산만(distraction)을 피하는 데 도움이 될 수 있다. Subtable selection 방법은 각 질문에 맞춰진 subtable을 구성함으로써 이를 달성한다. Lin et al. [2023]은 dense passage retriever encoder [Karpukhin et al., 2020]를 fine-tuning하여 관련 행과 열을 선택했다. 그들의 **inner table retriever (ITR)**는 답변 셀을 포함하는 행과 열을 positive로 레이블링하여 supervised contrastive loss를 사용한다. 이 기술은 원래 입력 테이블 크기가 LM이 관리할 수 있는 최대 토큰 제한 내에 있도록 설계되었다. 그러나 이 방법은 정확도(precision)와 재현율(recall)의 균형을 최적으로 맞추는 최소 subtable을 명시적으로 구성하지 않는다. 이 기술을 확장하여 관련 없는 정보를 필터링하는 것이 가능하더라도, 여러 행이나 열에 걸친 종속성(dependencies)을 포착할 수 없다 (Section 1). 이와 대조적으로, 우리의 방법은 관련 정보를 유지하면서 subtable 크기를 효과적으로 줄여 QA 성능을 향상시킨다.

Dater는 LM의 in-context learning을 사용하여 주어진 테이블과 질문으로부터 subtable과 sub-query 쌍을 합성한다 [Ye et al., 2023]. 그러나 이 접근 방식은 LM이 테이블 구조를 완전히 이해하고 효과적인 선택 전략을 수립하기 위해 확장된 prompt를 필요로 하며, 이는 대규모 테이블의 경우 심각한 부담이 된다. 일반적으로 LM의 성능은 극도로 긴 prompt를 처리할 때 저하되는 경향이 있다 [Liu et al., 2024a; Wang et al., 2024].

TabSQLify는 LM이 subtable 선택을 위한 SQL query를 생성하도록 행의 부분집합(모든 열 포함)을 입력으로 선택하여 table QA 성능을 크게 향상시킨다 [Nahid and Rafiei, 2024]. 그러나 Dater와 유사하게, 이 방법도 LM의 in-context learning에 의존하며 확장된 prompt를 요구하는 동일한 한계에 직면한다. 우리의 접근 방식은 대규모 테이블을 더 작은 window로 선제적으로 분할함으로써 이 문제를 극복한다. 이를 통해 LM은 각 window 내에서 관련 셀을 추출하는 데 집중할 수 있어, 긴 prompt를 처리하는 부담을 완화한다.

3 Divide-and-Conquer Subtable Selection

테이블 질의응답(Table Question Answering, QA) task는 테이블 $T$와 사람이 이해할 수 있는 질문 $Q$가 주어졌을 때, 답변 $A$를 생성하는 것을 요구한다. 답변 $A$는 질문과 테이블의 유형에 따라 숫자, 단어, 구, 문장 등 다양한 형태를 가질 수 있다. 답변은 $T$에서 직접 추출되거나, $T$ 내의 정보를 reader $\mathcal{R}$에 의해 합성되어 생성된다.

서브테이블 기반 QA 접근 방식에서는 selector $\mathcal{S}$가 먼저 $T$로부터 서브테이블 $T_s$를 생성하고, 이 $T_s$가 reader $\mathcal{R}$에 입력되어 최종 답변을 생성한다:

$$A=\mathcal{R}\left(T_{s}, Q\right), \quad T_{s}=\mathcal{S}(T, Q)$$

본 연구는 selector $\mathcal{S}$를 개선하는 데 중점을 두며, reader는 수정하지 않는다. 하지만 원칙적으로 $\mathcal{R}$과 $\mathcal{S}$를 함께 튜닝하는 것도 가능하다.

3.1 Subtable selection

우리의 subtable 선택 알고리즘은 세 가지 주요 단계를 반복적으로 적용한다. Divide 단계에서는 입력 테이블 $T$가 슬라이딩 윈도우(sliding window) 방식을 사용하여 $w \times w$ 크기의 작고 겹치는 윈도우 $\left\{W_{i}\right\}_{i=1}^{N}$로 분할된다 (Algorithm 2). Conquer 단계에서는 (subwindow) selector $\mathcal{S}^{\prime}$가 입력 질문 $Q$와 prompt instruction $\mathcal{P}$ (Appendix A.2 참조)에 따라 각 윈도우 $W_{i}$ 내에서 subwindow $V_{i}$를 추출한다:

Algorithm 1 SubtableSelection ( \(\mathcal{S}\) ).
    Input: Table \(T\) and question \(Q\)
    Parameter: Window size \(w\)
    Output: Final subtable \(T_{s}\)
    \(t \leftarrow 1\)
    \(T^{t} \leftarrow T ; T^{0} \leftarrow \varnothing\)
    while \(T^{t-1} \neq T^{t}\) do
        \(T^{t-1} \leftarrow T^{t}\)
        \(\left\{W_{i}\right\}_{i=1}^{N} \leftarrow \operatorname{DivideTable}\left(T^{t} ; w\right)\)
                \(\triangleright\) Divide step; see Algorithm 2
        \(T^{t} \leftarrow \varnothing\)
        for \(W_{i}\) in \(\left\{W_{i}\right\}_{i=1}^{N}\) do
                \(V_{i}^{t} \leftarrow \mathcal{S}^{\prime}\left(\mathcal{P}\left(W_{i}, Q\right)\right) \quad \triangleright\) Conquer step
                \(T^{t} \leftarrow T^{t} \cup V_{i}^{t} \quad \triangle\) Combine step
        end for
        \(t \leftarrow t+1\)
    end while
    \(T_{s} \leftarrow T^{t}\)

$$V_{i}=\mathcal{S}^{\prime}\left(\mathcal{P}\left(W_{i}, Q\right)\right) .$$

Combine 단계는 생성된 subwindow $\left\{V_{i}\right\}_{i=1}^{N}$를 새로운 테이블 $T^{t}$로 병합한다. 구체적으로, $T^{t}$는 subwindow $\left\{V_{i}\right\}_{i=1}^{N}$ 내의 모든 셀들의 **집합 합집합(set union)**으로 얻어진다. 이 단계들은 생성된 테이블 $T^{t}$가 더 이상 업데이트되지 않을 때까지 반복되며, 각 반복 $t$에서 $T^{t}$를 Divide 단계의 새로운 입력 $T$로 사용한다. 전체 subtable 선택 과정은 Algorithm 1에 요약되어 있다.

3.2 Fine-tuning the selector

우리는 Llama3.1 모델을 fine-tuning하여 selector $\mathcal{S}^{\prime}$를 구축한다. 원칙적으로는 우리의 방법이 어떤 LM 기반 selector에도 적용 가능하다. 데이터 생성 (Data generation)
학습 데이터는 SQUALL (Shi et al., 2020) 및 WikiSQL (Zhong et al., 2017) 학습 데이터셋에서 입력 window (크기 $w \times w$)를 샘플링하여 생성된다. 이 데이터셋은 테이블, 질문, 그리고 관련 target subwindow로 구성된다 (Section 4 참조).

우리는 condition column을 질문에 명시된 조건을 만족하는 셀을 포함하는 열로 정의한다. condition column의 각 셀은 주어진 조건을 만족할 수도 있고 만족하지 않을 수도 있다. 유사하게, 질문이 찾는 정확한 셀 값을 포함하는 열을 answer column이라고 한다. 예를 들어, Figure 2에 제시된 예시 질문에서 Horwood, Total, Result 열은 condition column이고, Goodman은 answer column이다.

각 학습 window $W_i$는 테이블 $T$와 해당 질문 $Q$에서 샘플링되며, target subwindow $V_i$는 먼저 $W_i$ 내의 모든 condition column과 answer column을 선택하여 구성된다. 그런 다음, 선택된 이들 열에 대해 $W_i$에 존재하는 모든 조건을 만족하는 행만 포함된다.

Figure 2는 학습 데이터 생성 과정을 보여준다. 첫 번째 window $W_1$은 Horwood, Total, Result 세 개의 condition column을 포함한다. target subwindow $V_1$은 Horwood에서 7, 총점 31, 그리고 safe 결과라는 조건을 동시에 만족하는 이들 열의 셀들로부터 생성된다. 두 번째 window $W_2$는 condition column Horwood와 answer column Goodman을 포함한다. $V_2$를 생성하기 위해 Horwood에서 7이라는 조건을 만족하는 이들 열의 부분집합이 포함된다. 그러나 이 조건을 만족하는 셀이 없으므로, $V_2$는 열 헤더만 포함하는 빈 테이블로 구성된다. 세 번째 window $W_3$는 answer column만 포함한다. 조건이 부과되지 않았으므로, 이 열의 모든 셀이 $V_3$에 포함된다.

이러한 target window 생성 전략은 selector $\mathcal{S}^{\prime}$가 예측을 수행할 때 오직 입력 window $W$에만 집중할 수 있도록 한다. 자세한 내용은 Appendix A.5를 참조하라.

Figure 2: window 크기가 $w=4$인 생성된 학습 데이터의 예시. 테이블과 질문은 WikiSQL 학습 데이터셋 (Zhong et al., 2017)에서 가져왔다. 세 가지 조건과 해당 셀 값은 녹색으로 색상 코딩되어 있다. 래스터 순서로 배열된 세 가지 예시 입력 window $\left\{W_{i}\right\}_{i=1}^{3}$는 주황색 상자로 강조되어 있으며, 해당 학습 target $\left\{V_{i}\right\}_{i=1}^{3}$는 오른쪽에 표시되어 있다.

Figure 3: subtable 표현의 예시 ($w=3$). 조건 Total과 일치하는 정보가 열 헤더가 아닌 셀에 위치한다. Description Losses 열이 선택되지 않았기 때문에 index 및 table 표현 모두 셀 Total을 선택하지 못한다. 제안된 coordinate 표현은 입력 window 구조와 관련 셀 내용을 보존함으로써 이러한 한계를 극복한다.

3.3 Representing subtables

subtable 생성에서 LM을 위한 일반적인 표현 방식으로는 선택된 행과 열을 해당 인덱스와 헤더를 사용하여 식별하는 index representation과, 선택된 셀들을 구조화된 테이블 형식으로 구성하는 table representation이 있다. 이 두 가지 표현 방식 모두 효과성에 영향을 미치는 내재적인 한계를 가지고 있다.

Index representation은 관련 콘텐츠를 식별하는 데 필요한 정보가 행 또는 열 헤더가 아닌 셀 내부에 포함되어 있을 때 어려움을 겪는다. 이 방식은 헤더에만 의존하기 때문에 셀 내용을 직접적으로 포착할 수 없으며, 이로 인해 selector가 쿼리를 내장된 정보와 정렬하는 방법을 학습하기 어렵게 만든다. 예를 들어, Figure 3(a)에서 보듯이, 'Description Losses' 열은 질문에 명시적으로 언급되지 않았지만, 'Total'이라는 조건과 일치하는 내용은 셀 내부에 나타난다.

Figure 4: (sub)table과 해당 QA 결과 예시. 원본 테이블에는 두 개의 조건 열(Fuel 및 Years produced)과 하나의 답변 열(Engine)이 있으며, 이는 질문에 제시된 조건 및 예상 결과와 각각 일치한다. 두 조건과 해당 셀 값은 색상으로 구분되어 있다. Union table은 최소한 하나의 조건을 만족하는 행들로 구성되는 반면, gold table은 모든 조건을 만족하는 행들로 구성된다. gold table을 추정하는 것은 전체 입력 테이블에 대한 포괄적인 이해를 요구하므로 어렵다. 각 테이블 아래의 답변은 해당 TaPEx reader의 출력이다. 원본 전체 테이블을 입력으로 사용하면 잘못된 결과가 나오지만, gold table과 union table 모두 올바른 답변을 생성한다.

이러한 불일치로 인해 LM은 'Description Losses' 열을 관련성 있는 것으로 인식하지 못한다.

반면, table representation은 토큰 생성 과정의 autoregressive 특성으로 인해 오류가 발생하기 쉽다. 각 토큰 예측이 이전 예측에 의존하기 때문에, 시퀀스 초기의 오류가 전파되어 누적될 수 있으며, 이는 정확도를 크게 떨어뜨린다 (Bachmann and Nagarajan, 2024; Ross and Bagnell, 2010; Bengio et al., 2015; Lamb et al., 2016). 예를 들어, Figure 3(b)에서 LM이 열 헤더 'Description Losses'를 예측하지 못하면, 해당 열의 모든 셀이 제외된다.

이러한 한계를 극복하기 위해 우리는 coordinate representation을 제안한다. 이 방식은 입력 subwindow 구조를 보존하고, 선택된 셀의 위치를 나타내기 위해 coordinate token (<row_index, column_index>)을 사용한다. 선택되지 않은 셀은 empty token (<empty, empty>)으로 표시된다. 이 접근 방식은 Figure 3(c)에서 'Total' 셀을 성공적으로 식별한 것처럼, 초기에 열이 간과되더라도 모델이 관련 셀을 식별하는 능력을 향상시킨다.

3.4 Discussion

우리 접근 방식의 핵심은 테이블 (하위)창(subwindows)을 기반으로 구축되는 다중 해상도 테이블 형성 기술에 있다. 이미지에서 인접 픽셀은 종종 강한 상관관계를 보이며, 이는 CNN의 convolutional kernel이나 vision Transformer의 attention window와 같은 작은 창을 사용하는 것을 정당화한다. 그러나 테이블은 반드시 그러한 공간 구조를 나타내지는 않는다. 예를 들어, Figure 4에 제시된 테이블에서 1995-1997과 1998-2001과 같은 인접 셀들은 'Years produced' 열 내에서 더 유사하다. 반대로, 'Model 725tds' 행의 셀들은 1995-2001이 'M51D25 turbocharged I6'보다 'Diesel'과 더 밀접하게 관련되어 있지 않은 것처럼, 비교할 만한 관계가 부족하다. 이러한 맥락에서, subwindow를 사용하는 것은 처음에는 불필요한 제약을 가하는 것처럼 보일 수 있다.

우리의 union 기반 subwindow 결합 접근 방식은 이러한 잠재적 제약을 효과적으로 극복하는 동시에, 적절한 크기의 최종 subtable을 구성하여 집중적인 답변 생성을 보장한다. Figure 4의 테이블에 대해 "1988-2001년에 생산된 디젤 연료 엔진 각각을 나열하시오"라는 질문이 제시되었다고 가정해 보자. 이 질문에 답하기 위한 이상적인 subtable은 Figure 4의 오른쪽 열 하단 테이블에 나타난 것처럼, 'diesel fuel' 및 '1998-2001' 조건을 충족하는 셀들과 'Engine' 열의 해당 셀 값들을 교차할 것이다.

이러한 gold table을 직접 식별하는 것은 전체 테이블에 대한 포괄적인 이해를 필요로 한다. 대신, 우리 알고리즘은 각 창 내에서 식별된 subwindow들을 반복적으로 병합한다. 예를 들어, 'Diesel' 또는 '1998-2001'과 일치하는 셀들을 선택하고 이를 subtable로 결합하여, 효과적으로 이들의 union을 취한다 (Figure 4의 오른쪽 열 상단 테이블 참조).

이러한 union 접근 방식은 상당한 이점을 제공한다. 첫째, 작은 창 내에서 관련 subwindow를 식별하는 것은 전체 테이블에 걸쳐 조건을 교차해야 하는 gold table을 찾아내는 것보다 훨씬 간단하다. 선택 모듈(LMs)은 각 창 내의 셀에만 집중할 수 있어, 긴 context 입력으로 인한 어려움을 피할 수 있다. 우리의 학습 목표 생성 과정은 이러한 설계와 일치한다. 각 목표 subwindow는 해당 입력 창 내에 존재하는 조건과 출력만을 기반으로 구성된다.

또한, 우리는 결과 union subtable의 크기가 원래의 전체 테이블보다 상당히 작다는 것을 경험적으로 검증했으며, 이는 후속 답변 생성 단계를 용이하게 한다. 평균적으로 union 테이블의 셀 수는 원래 테이블 크기의 13.91%로 감소했다. gold table보다 약간 크지만, 이 접근 방식은 최종 테이블 기반 QA task에서 비교할 만한 성능을 제공한다. Table 1은 subtable 구축의 예시를 보여주며, 최종 테이블 QA 성능에서 상당한 개선을 입증한다.

Table 1: 세 가지 다른 subtable 유형에 대한 exact match (EM; %) 기준 테이블 QA 성능. 우리가 목표로 하는 union 테이블은 gold table과 유사한 성능을 달성하면서도 구성하기가 훨씬 쉽다.

4 Experiments

우리는 제안된 PieTa 모델의 성능을 WikiTQ (Pasupat and Liang, 2015) 및 WikiSQL (Zhong et al., 2017) 데이터셋을 사용하여 평가한다. 이 데이터셋에 대한 자세한 설명은 Appendix A.4에 제공되어 있다.
window $W$에 대한 target subwindow $V$를 생성하는 데 사용되는 condition 및 answer column은 해당 SQL 쿼리에서 파생된다. 각 subwindow $V$에 대한 target을 주석하기 위해, 우리는 SQUALL (Shi et al., 2020) 및 WikiSQL 데이터셋의 SQL 쿼리를 사용했다. SQUALL은 WikiTQ의 11,468개 질문에 대한 SQL 주석을 제공한다.

Table 2: WikiSQL의 subtable 생성 sub-task에 대한 subtable selection 알고리즘 성능 (precision (%) 및 recall (%)로 평가).
이후부터 (P)와 (R)은 각각 precision과 recall을 나타낸다. 마지막 네 행은 우리의 반복적인 subtable 형성 접근 방식(Section 3.1 참조)의 효과를 강조한다. 총 반복 횟수는 인스턴스마다 다르며, PieTa는 subtable이 변경되지 않으면 종료된다.

PieTa의 유일한 하이퍼파라미터는 **입력 window size $w$**이며, 이는 모든 실험에서 4로 고정된다. 다양한 window size의 영향은 Section 4.3에서 분석된다.

평가는 두 가지 관점에서 수행된다.
첫째, table QA 성능을 위해 PieTa가 생성한 subtable은 기존 reader $\mathcal{R}$에 입력되어 답변을 얻는다. 우리는 **OmniTab (Jiang et al., 2022)**과 **TaPEx (Liu et al., 2022)**를 사용하며, 이들은 각각 WikiTQ와 WikiSQL에 fine-tuning되었다. 또한, table QA에 fine-tuning되지 않은 일반 모델에 대한 PieTa의 유용성을 입증하기 위해 GPT-3.5와 **DP&Agent (Liu et al., 2024b)**를 reader로 사용한다 (자세한 내용은 Appendix A.3 참조). 평가는 exact match (EM) 점수를 기반으로 하며, 이는 ground truth와 정확히 일치하는 예측의 비율을 반영한다.

둘째, subtable selection을 위해 WikiSQL의 주석된 레이블을 사용하여 condition 및 answer column과 row의 선택을 평가한다. Precision과 recall이 지표로 사용되며, 이때 기본 gold table의 셀은 positive로, 그 외의 셀은 negative로 간주된다.

4.1 Subtable selection results

기존 접근 방식들과 PieTa를 비교 평가하기 위해, 우리는 ITR (Lin et al., 2023), TabSQLify (Nahid and Rafiei, 2024), 그리고 입력 테이블에서 직접 subtable을 생성하도록 LM을 fine-tuning하는 간단한 baseline 알고리즘 (Holistic LM)[^2]을 사용하여 실험을 수행했다. 이들 중 TabSQLify, PieTa, Holistic LM은 LM selector를 사용한다. PieTa와 Holistic LM의 경우, 우리는 Llama3.1을 한 epoch 동안 fine-tuning했다 (Section 3.2 참조). TabSQLify의 경우, 우리는 Llama3.1과 GPT-3.5를 모두 평가하여, 가장 좋은 성능을 달성한 모델을 선택했다 (Nahid and Rafiei, 2024에서 GPT-3.5를 사용했기 때문).

Table 2는 결과를 요약한다. 열과 행을 독립적으로 평가하는 ITR은 낮은 precision을 보인다. 이와 대조적으로, PieTa는 열과 행 간의 상호 의존성을 효과적으로 포착하여 ITR 대비 47.43%의 precision 향상을 가져왔다.

PieTa와 유사하게, TabSQLify도 공동 의존성(joint dependencies)을 모델링할 수 있다. 그러나 TabSQLify는 subtable 선택을 위해 in-context learning에 의존하며, 이는 긴 prompt를 필요로 하여 LM에 부담을 준다. TabSQLify의 선택 전략은 먼저 몇 개의 행을 추출한 다음 (Nahid and Rafiei, 2024에서와 같이 첫 세 행을 추출하며, 우리 실험에서도 이를 따랐다), 조건(condition) 및 답변(answer) 열을 결정한다. 이 접근 방식의 한계는 초기 행 선택에 필요한 모든 조건이 포함되어 있지 않으면, 알고리즘이 관련 없는 열을 샘플링하여 최적화되지 않은 선택으로 이어질 수 있다는 점이다. 추출하는 행의 수를 늘리면 이 문제를 해결하는 데 도움이 될 수 있지만, 더 긴 context 처리로 인해 LM selector에 추가적인 부담을 주어, 결국 성능이 정체되고 우리 모델보다 훨씬 낮은 수준에 머무르게 된다 (Appendix A.6 참조).

TabSQLify를 포함하여 SQL 쿼리를 생성하는 접근 방식의 또 다른 단점은 작동 불가능한 SQL 코드를 생성할 위험이 있다는 것이다 (Xie et al., 2024). 우리는 TabSQLify가 WikiSQL 데이터셋의 15,878쌍 중 425쌍, WikiTQ 데이터셋의 4,344쌍 중 83쌍에 대해 실행 불가능한 SQL 코드를 생성했음을 경험적으로 관찰했다.

subtable 선택에서 높은 recall을 달성하는 것은 매우 중요하다. 관련 행이나 열을 놓치면 정보가 불완전해져서, 결국 다운스트림 table QA 모델의 성능을 저하시킬 수 있기 때문이다. 비교된 subtable 선택 알고리즘 중, ITR만이 저자가 제공한 기본 설정에서 본질적으로 높은 recall을 생성한다. 다른 접근 방식들은 precision과 recall의 균형을 맞추는 직접적인 메커니즘이 부족하다. PieTa는 높은 recall을 위해 명시적으로 최적화되지는 않았지만, 다른 접근 방식에 비해 일관되게 높은 recall을 달성하는 경향을 보인다. Table 3은 PieTa가 다양한 수의 답변 열과 행에 걸쳐 높은 recall을 유지함을 보여준다.

Table 3: WikiSQL에서 조건 및 답변 열의 수(왼쪽)와 답변 행의 수(오른쪽) 변화에 따른 subtable 생성 성능.

4.2 Table QA results

Table 4는 WikiTQ 데이터셋에서 다양한 subtable selection 방법과 여러 reader를 조합했을 때의 table QA 성능을 보여준다. 우리는 또한 TaPEx, OmniTab, CABINET (Patnaik et al., 2024), GPT-3.5, Binder (Cheng et al., 2023), StructGPT (Jiang et0 al., 2023), Chain-of-Table (Wang et al., 2024), ReAcTable (Zhang et al., 2024), DP&Agent (Liu et al., 2024b)를 포함한 state-of-the-art holistic table QA reader들과도 비교했다.

PieTa가 생성한 subtable은 더 집중적이고 관련성 높은 정보를 제공함으로써 reader의 성능을 향상시킨다. 대부분의 reader 구성에서 PieTa는 holistic reader 및 다른 subtable selection 방법들보다 일관되게 우수한 성능을 보이며, 원본 테이블 대비 상당한 개선을 이룬다. 유사한 성능 향상 추세는 WikiSQL 데이터셋에서도 관찰된다 (Table 5). 유일한 예외는 TaPEx와의 조합인데, 이 경우 TabSQLify가 WikiTQ 데이터셋에서 약간 더 나은 성능을 보인다.

또한, Figure 5는 PieTa가 다양한 입력 테이블 크기에서도 강력한 table QA 성능을 유지함을 보여준다.

4.3 Ablation study

Fine-tuning vs. in-context learning.
우리는 LM selector에 대한 fine-tuning 접근 방식과 two-shot 설정의 in-context learning 방식을 비교했다. Table 6에서 볼 수 있듯이, in-context learning은 fine-tuning에 비해 현저히 낮은 성능을 보인다. 이는 주로 subtable selection에 특화되지 않은 LM이 의도된 task에서 벗어나, 예를 들어 subwindow 내용에 직접적으로 질문에 답하려고 시도하는 경향이 있기 때문이다.

Table 4: WikiTQ에서 subtable selector와 reader 조합의 Table QA 성능 (EM; %)
가장 좋은 결과는 굵은 글씨로, 두 번째로 좋은 결과는 이탤릭체로 강조되어 있다. 'Holistic'은 원본 테이블이 reader에 직접 입력으로 제공됨을 나타낸다. GPT-3.5 ${ }^{\text {Dat }}$ 및 GPT-3.5 ${ }^{\text {Tab }}$의 경우, 각각 Dater 및 TabSQLify의 GPT reader 구성이 사용되었다 (자세한 내용은 Appendix A.3 참조).

반면, fine-tuning은 selector의 기능을 subtable selection task에 맞춰 정렬하고, 출력 형식을 좌표 표현으로 조정한다. 이는 긴 prompt의 필요성을 없애고 전반적인 성능을 향상시킨다.

Subtable representation.
Table 6은 제안된 좌표 기반 subtable representation이 기존의 index 및 table representation보다 Table QA 성능에서 훨씬 우수함을 보여준다.

Window sizes.
PieTa의 기본 window size는 $4 \times 4$이다. 그 영향을 평가하기 위해 $3 \times 3, 5 \times 5$, 그리고 모든 열을 포함하는 $4 \times n$ (평균 약 6개 열; Appendix A.4 참조)을 테스트했다. Table 6에서 볼 수 있듯이, $4 \times 4$와 $3 \times 3$ 모두 강력한 성능을 보인 반면, $5 \times 5$는 약간의 성능 저하를, $4 \times n$은 눈에 띄는 성능 저하를 보였다. 이는 window가 클수록 selector가 모든 조건을 만족하는 cell을 식별하기 더 어려워진다는 것을 시사한다.

Figure 5: WikiTQ (상단) 및 WikiSQL (하단)에서 다양한 테이블 크기(셀 수)에 따른 Table QA 성능 (EM; %).

Table 5: WikiSQL 데이터셋의 Table QA 결과.

5 Conclusion

테이블 질의응답(Table Question Answering)에서 subtable selection의 어려움을 탐구했으며, 특히 기존 접근 방식이 행과 열에 걸친 joint dependency를 포착하는 데 한계가 있고, 언어 모델에서 긴 토큰 시퀀스를 관리하는 데 어려움이 있다는 점에 주목했다.
우리의 알고리즘은 입력 테이블을 작은 window로 나누고 그 안에서 subtables를 독립적으로 구성함으로써 이러한 어려움을 해결한다.
그 결과로 얻어진 multi-resolution windowing 전략은 간단한 union 연산을 통해 subtables를 효과적으로 결합하여, 불필요한 연산 가정을 부과하지 않고도 장거리 관계(long-range relationships)를 보존하면서 subtable selection을 간소화한다.
WikiSQL 및 WikiTQ 데이터셋에서 평가한 결과, 우리의 방법은 state-of-the-art 방법들보다 상당한 개선을 보였다.

Table 6: WikiSQL validation set (TaPEx reader)에서 우리 알고리즘의 변형에 따른 Table QA 성능. 첫 번째 행은 selector LM fine-tuning과 coordinate 기반 subtable representation을 통합한 최종 방법을 나타낸다. 결과는 이러한 설계 선택이 개별적으로 그리고 집합적으로 성능을 향상시킨다는 것을 보여준다.

Limitations

우리의 연구는 최종 답변을 생성하는 reader와는 독립적으로 subtable selection 프로세스를 개선하는 데 중점을 두었다. 이 접근 방식은 선택 프로세스를 어떤 유형의 reader와도 쉽게 결합할 수 있다는 유연성을 제공한다. 예를 들어, 우리의 알고리즘은 자연어 답변과 SQL 쿼리를 모두 생성하는 reader의 성능을 직접적으로 향상시킬 수 있다. 그러나 원칙적으로는 reader에 특화된 subtable selector를 맞춤 제작하는 것이 성능을 더욱 향상시킬 수 있다. 향후 연구에서는 subtable selection 프로세스와 reader를 공동으로 최적화할 가능성을 탐구해야 한다.

Acknowledgments

본 연구는 삼성전자(주) (IO240508-09825-01), 한국연구재단(NRF) 과제 (2021R1A2C2012195), 그리고 정보통신기획평가원(IITP) 과제 (RS-2019-II191906, 인공지능대학원 프로그램 (POSTECH))의 지원을 받아 수행되었으며, 이는 대한민국 정부(과학기술정보통신부)의 재원으로 운영된다.

A Appendix

A. 1 Subwindow sampling process

Algorithm 2는 입력 테이블로부터 window를 생성하는 과정을 자세히 설명한다. DivideTable 알고리즘은 입력 테이블 $T$ 위로 $w \times w$ 크기의 window를 stride 1로 슬라이딩하여 하위 window 집합 $W=\left\{W_{i}\right\}_{i=1}^{N}$를 생성한다.

Algorithm 2 DivideTable
    Input: R개의 행과 C개의 열을 가진 테이블 \(T\)
    Parameters: Window 크기 \(w\)
    Output: Window 집합 \(W=\left\{W_{i}\right\}_{i=1}^{N}\)
    \(W \leftarrow \varnothing\)
    for \(i=0\) to \(R\) by 1 do
        for \(j=0\) to \(C\) by 1 do
            if \(i+w>R\) then
                \(i=R-w\)
            end if
            if \(j+w>C\) then
                \(j=C-w\)
            end if
            \(W_{i}=T[i: i+w, j: j+w] \quad \triangleright\) Window 슬라이싱
            \(W=W \cup\left\{W_{i}\right\}\)
        end for
    end for

A. 2 Input prompt structure for selector $\mathcal{S}$

selector $\mathcal{S}$의 입력 prompt는 Figure A.1에 나타난 바와 같이 고정된(fixed) 구성 요소와 가변적인(variable) 구성 요소로 이루어져 있다. 파란색과 녹색으로 강조된 가변적인 구성 요소는 각각 **질문(question)과 테이블 윈도우(table window)**를 나타낸다. 고정된 구성 요소는 모든 테이블과 질문에 걸쳐 변경되지 않는다.

Prompt
Below is an instruction that describes a task, paired with an input that provides further
context.
Write a response that appropriately completes the request.

Instruction:

이것은 주어진 테이블에서 질문에 답하기 위한 **골드 정보(gold information)**를 포함하는 **서브테이블(subtable)**을 추출하는 task이다. 구체적으로, 필요한 정보를 포함하는 행과 열을 선택해야 한다. 그런 다음, 해당 행과 열로 서브테이블을 생성한다. 각 셀은 <row_index,column_index> 형식으로 표시된다. 불필요한 셀은 <empty,empty>로 표시한다.

Input:

Question: Who played in the Toronto Raptors from 1995-96?

Table:

Col: <0,1> Player | <0,2> School/Club Team | <0,3> Years in Toronto | <0,4> No. <1,1> patrick o'bryant | <1,2> bradley | <1,3> 2009-10 |<1,4> 13.0 <2,1> jermaine o'neal | <2,2> eau claire high school | <2,3> 2008-09 |<2,4> 6.0 <3,1> dan o'sullivan | <3,2> fordham |<3,3> 1995-96 |<3,4> 45.0 <4,1> hakeem olajuwon | <4,2> houston | <4,3> 2001-02 | <4,4> 34.0

### Response:

Figure A.1: Prompt의 예시. 질문 $Q$와 window $W$가 주어지면, prompt generator $\mathcal{P}$는 텍스트 prompt를 생성한다 (상단). 이 prompt는 subwindow selector $\mathcal{S}^{\prime}$에 입력되어 출력 subwindow를 구성한다 (하단). 전체 질문 $Q$와 입력 window $W$는 각각 파란색과 녹색으로 강조되어 있다. Instruction에서는 입력 window와 target window를 각각 table과 subtable이라고 지칭한다.

A. 3 Configurations of the GPT-3.5 reader

Holistic 설정과 우리의 접근 방식 모두에서 GPT-3.5 reader를 사용한 실험(Table 4 및 5)의 경우, 우리는 $DP\&Agent$ (Liu et al., 2024b)와 유사한 전략을 따라 GPT-3.5가 SQL 쿼리와 텍스트 출력 답변을 모두 생성하도록 허용한다. 만약 SQL 쿼리 실행 결과가 단일 셀(single-cell) 결과를 반환하면, 해당 셀의 내용이 최종 답변으로 사용된다. 그렇지 않고 쿼리가 여러 셀을 생성하거나 실행 불가능한 경우에는 텍스트 출력이 최종 답변으로 사용된다.

SQL 및 텍스트 출력 모두에 대해 in-context learning이 적용된다: SQL 출력에는 (Nahid and Rafiei, 2024)에 따라 10-shot learning을, 텍스트 출력에는 (Nahid and Rafiei, 2024)의 holistic reader 실험 설정과 일관되게 2-shot learning을 사용한다. 이 실험들에서 사용된 prompt는 Figure A.2에 제시되어 있다.

이 설정은 TabSQLify (Nahid and Rafiei, 2024) 및 Dater (Ye et al., 2023)에서 subtable selection과 결합된 GPT-3.5 reader가 사용되는 방식과는 차이가 있다. TabSQLify에서는 subtable을 추출하는 데 사용된 SQL 쿼리가 reader prompt에 통합된다. 또한, 추출된 subtable이 단일 셀만 포함하는 경우에는 reader의 입력에서 생략되고, 해당 셀 자체가 직접 답변으로 사용되었다. 이와 대조적으로 Dater의 reader는 subtable뿐만 아니라 question decomposer의 출력도 처리하여, 복잡한 쿼리를 효과적으로 처리하기 위한 질문 분해(question decomposition)를 강조한다. 공정한 비교를 위해, 우리는 이러한 원래 GPT-3.5 구성을 사용한 결과도 보고하며, Table 4 및 5에서는 각각 GPT-3.5$^{\text{Tab}}$ 및 **GPT-3.5$^{\text{Dat}}$**로 표기한다.

$DP\&Agent$의 경우, GPT-3.5의 환각(hallucination)을 방지하기 위해 에이전트에게 다음 추가 지침을 제공한다: 주어진 질문에 집중하세요(Stay focused on the given question): 답변은 주어진 질문에 엄격하게 기반해야 합니다. 관찰 단계 이후에는 새로운 질문을 생성하거나 추론하지 마세요.

A. 4 Details of experimental settings

학습 설정 (Training settings)
selector는 NVIDIA A100-80G GPU를 사용하여 AdamW optimizer로 단일 epoch 동안 학습된다. 초기 learning rate는 $10^{-5}$로 설정된다. batch size는 8이며, 4단계의 gradient accumulation을 사용한다. 학습 과정은 WikiSQL과 다음 데이터셋 모두에 대해 약 2시간이 소요된다.

Figure A.2: holistic GPT-3.5 reader가 텍스트 답변(상단)과 SQL 쿼리(하단)를 생성하기 위한 템플릿 prompt로, (Nahid and Rafiei, 2024)에서 발췌 및 수정되었다. prompt 내의 각 {} placeholder는 해당 변수 구성 요소로 대체된다.

WikiTQ datasets.

데이터셋 (Datasets)
WikiSQL과 WikiTQ 데이터셋은 모두 Wikipedia에서 추출된 테이블에서 파생되었으며, 광범위한 도메인을 다룬다. WikiTQ는 **최상급(superlatives), 집계(aggregations), 비교(comparisons)**와 같은 연산을 포함하며, 4,344개의 테스트 예시를 제공한다. 테스트 테이블은 평균적으로 6.3개의 열과 25.8개의 행을 가지며, 일부 테이블은 최대 21개의 열과 517개의 행에 달한다. WikiSQL은 집계, 열 선택, 조건을 포함하는 더 간단한 질문들로 구성된다. 이 데이터셋은 15,878개의 테스트 예시를 포함하며, 평균 테이블 크기는 6.4개의 열과 18.6개의 행이고, 최대 23개의 열과 1,950개의 행을 가진다. 두 데이터셋 모두 (Lin et al., 2023; Nahid and Rafiei, 2024)를 포함한 테이블 QA 연구에서 널리 사용된다.

우리의 실험은 Jiang et al. (2022)의 실험 프로토콜을 따르며, WikiTQ와 WikiSQL 데이터셋 각각에 대해 명확하게 분리된 훈련, 검증, 테스트 세트를 사용하여 단일 실행을 수행한다. 우리 알고리즘은 어떠한 무작위 요소도 포함하지 않는다.

비교된 테이블 QA 알고리즘 (Table QA algorithms compared)
Table 4와 5의 실험을 위해, 우리는 OmniTab, CABINET, GPT-3.5, ITR, TabSQLify, Dater (GPT-3.5 ${ }^{\text {Dat }}$ reader가 사용된 경우는 제외)의 결과를 **각 저자들이 제공한 코드 및 서비스(GPT의 경우)**를 사용하여 재현하였다. 그러나 Table 4의 GPT-3.5 ${ }^{\text {Dat }}$를 사용한 Dater와 Binder의 경우, 원본 연구는 **Codex (Chen et al., 2021)**에 의존했는데, 이는 우리 실험 당시에는 사용할 수 없었다. 대신, 우리는 GPT-3.5를 사용한 (Nahid and Rafiei, 2024)의 결과를 보고한다. 다른 알고리즘의 경우, 각 논문에 제시된 결과를 보고한다.

데이터 증강 (Data augmentation)
우리는 selector 훈련 데이터를 증강하기 위해, window 내에서 target cell과 동일한 값을 가진 cell들을 훈련 데이터셋의 target으로 레이블링하였다. 이 증강은 WikiTQ 데이터의 8%와 WikiSQL 데이터의 21%에 적용되었다.

A. 5 Details of training data sampling

예비 실험에서, 우리는 학습 데이터(입력 $W_i$와 해당 타겟 $V_i$ 서브윈도우 쌍)를 무작위로 샘플링할 경우, $S'$가 의미 없는 단일 열 타겟 테이블을 생성하는 문제를 자주 관찰했다. 이 문제는 타겟 윈도우 크기 분포의 불균형으로 인해 발생한다.

크기 $w \times w$의 주어진 입력 윈도우 $W$에 대해, 가능한 타겟 윈도우 크기는 $w(w+1)$가지이다: $\{[1,1], \ldots,[1, w], \ldots,[w, 1], \ldots,[w, w]\}$ 테이블은 적어도 하나의 열을 포함해야 하므로, $[0,0],[1,0],[2,0], \ldots$, $[w, 0]$와 같은 경우는 제외된다. 유효한 경우들 중, 단일 열 타겟 윈도우가 지배적이며 (Figure A.3), 전체 입력 윈도우 $W$가 타겟이 되는 경우는 드물다. 후자의 시나리오는 $W$의 모든 열이 조건(condition) 또는 답변(answer) 열이어야 하며, 모든 셀이 주어진 질문을 만족해야 한다. 이러한 불균형을 해결하기 위해, 우리는 학습 세트를 샘플링할 때 타겟 윈도우 크기 분포를 명시적으로 조정한다.

Figure A.3: WikiSQL에 대해 생성된 $4 \times 4$ 윈도우 학습 데이터의 분포를 나타내는 히스토그램. 'raw' 히스토그램은 원본, 필터링되지 않은 데이터를 나타내며, 'balanced' 히스토그램은 클래스 불균형을 완화하기 위해 조정된 데이터를 보여준다. 하단 행에서 x축은 [답변 행의 수, 조건 및 답변 열의 수]를 나타낸다. y축 스케일은 히스토그램마다 다름에 유의하라.

타겟 서브테이블의 행과 열 수에 대한 균형 잡힌 분포를 달성하기 위해, 우리는 그들의 발생 빈도를 균등하게 맞춘다. 먼저, 타겟 서브테이블의 열 수 $n \in\{1,2, \ldots, w\}$를 결정하고, 이들을 조건(condition) 또는 답변(answer) 열로 지정한다. 나머지 $w-n$개의 열은 비조건(non-condition), 비답변(non-answer) 열로 채워진다. 유사하게, 행의 경우, 조건을 만족하는 $m$개의 행을 선택하고, 나머지 $w-m$개의 행은 조건을 만족하지 않는 셀로 채운다. $n$과 $m$을 균등하게 샘플링함으로써, 우리는 잘 균형 잡힌 데이터셋을 생성할 수 있다.

A. 6 Additional results

TabSQLify는 LM이 subtable selection을 위한 SQL 쿼리를 생성하도록, 일부 행(특히, 모든 열을 포함하는 처음 세 행)을 입력으로 선택한다. 이 접근 방식의 주요 한계점은 초기 행에 필요한 모든 조건이 포함되어 있지 않으면,

Table 7: TabSQLify의 Table QA 성능 (EM; %)을 행 수 변화에 따라 비교한 결과. 우리의 방법과 비교했으며, 두 방법 모두 GPT-3.5 reader를 사용했다 (TabSQLify의 경우 GPT-3.5 ${ }^{\text {Tab }}$). 추가 비교는 Table 4를 참조하라.

알고리즘이 관련 없는 열을 샘플링하여 최적화되지 않은 선택으로 이어질 수 있다는 점이다. 추출되는 행의 수를 늘리면 이 문제를 완화하는 데 도움이 될 수 있지만, 이는 또한 LM selector에 더 긴 context 처리 부담을 주어 결국 성능이 정체되고 우리의 방법보다 현저히 낮은 수준에 머무르게 된다 (Table 7).

A. 7 Potential risks

PieTa는 관련 subtable을 추출하기 위해 사전학습된 Language Model(LM)에 의존하므로, 이러한 모델에 존재하는 모든 편향을 상속하고 반영할 수 있다. 마찬가지로, PieTa가 학습 데이터에 기반하여 subtable을 식별하는 방법을 학습함에 따라, 데이터셋 내에 존재하는 편향을 의도치 않게 강화할 수 있다.

우리는 특정 문제가 될 만한 시나리오를 예상하지는 않지만, subtable 선택은 테이블 내용의 선택적 샘플링으로 인해 의도치 않은 편향을 도입할 위험을 본질적으로 내포하고 있다. 더욱이, 적대적 환경(adversarial settings)에서는 subtable 선택 시스템이 특정 의제를 지지하는 데이터를 선택적으로 제시하고 모순되는 증거를 생략하는 데 악용될 수 있다.