TAPAS: SQL 없는 약지도 학습 기반 테이블 질의응답과 Beancount에 주는 의미

최근 BIRD, DIN-SQL, MAC-SQL 등 텍스트 투 SQL(text-to-SQL) 계보를 연구해 왔지만, 이들 모두는 한 가지 가정을 공유하고 있습니다. 바로 테이블 질의응답(QA)을 위한 올바른 인터페이스가 SQL을 생성하는 것이라는 가정입니다. Google Research의 Herzig 등이 ACL 2020에서 발표한 TAPAS는 이와 반대되는 선택을 했습니다. TAPAS는 쿼리를 생성하지 않습니다. 대신 정답 표기(denotations)만으로 종단간(end-to-end) 학습되어 셀을 선택하고 선택적으로 스칼라 집계를 적용합니다.

논문 내용

TAPAS는 표준 위치(position) 및 세그먼트 ID 위에 6개의 새로운 임베딩 차원을 추가하여 테이블을 인코딩하도록 BERT를 확장합니다. 열 ID(Column ID)와 행 ID(Row ID)는 각 토큰이 테이블 그리드의 어디에 위치하는지 표시합니다. 순위 ID(Rank ID)는 정렬 가능한 열 내에서 상대적인 숫자 순서를 인코딩합니다(순위 0은 비교 불가, i번째로 작은 값은 순위 i+1). 이전 답변(Previous Answer) 표시기는 이전 대화 턴에서 선택된 셀을 플래그합니다. 질문 토큰과 테이블 토큰을 구별하는 바이너리 세그먼트 임베딩과 결합하여 TAPAS는 7가지 유형의 토큰 표현을 갖게 됩니다.

추론 시 모델은 각 셀별 확률에 임계값을 적용하여 셀 집합을 선택한 다음, NONE, COUNT, SUM, AVERAGE 중 하나의 집계 연산자를 적용하여 최종 답변을 생성합니다. 중간 단계의 SQL이나 논리적 형태는 존재하지 않습니다. 사전 학습은 620만 개의 영어 위키백과 테이블-텍스트 쌍에 대해 표준 마스크 언어 모델(MLM) 목표로 수행됩니다.

주요 개념

• 열/행 임베딩이 핵심적인 역할을 합니다. 절제 연구(ablation study)에 따르면 이를 제거할 경우 SQA에서 19.4점, WikiSQL에서 10.6점, WikiTQ에서 11.6점의 정확도 손실이 발생하며, 이는 다른 어떤 아키텍처 구성 요소보다 큰 영향력을 가집니다.
• 테이블 사전 학습 역시 중요합니다. 이를 제거하면 미세 조정(fine-tuning) 후에도 SQA는 12.5점, WikiTQ는 11.1점 하락합니다.
• SQA(대화형 테이블 QA)에서 TAPAS는 정확도를 55.1%에서 67.2%로 12포인트 끌어올렸습니다. 이전 답변 토큰 임베딩은 별도의 상태 추적기 없이도 대화의 맥락을 이어가게 하는 메커니즘입니다.
• WikiSQL(단일 테이블, 주로 조회 및 집계)에서 TAPAS는 83.6%에 도달하여, SQL 생성 없이도 최고 수준(SOTA)의 시맨틱 파서인 83.9%와 대등한 성능을 보였습니다.
• WikiSQL에서 WikiTQ(다단계, 다중 열 추론)로의 전이 학습(transfer learning)은 당시 최고 수준보다 4.2점 높은 48.7%를 기록했습니다. SQA 전이는 48.8%를 기록했습니다.
• 약지도 학습(Weak supervision)은 이 모델의 핵심적인 경제성 주장입니다. 모델이 (질문, SQL, 답변) 삼중 항이 아닌 (질문, 답변) 쌍으로 학습되므로, SQL 전문 지식 없이도 대규모 말뭉치에 주석을 달 수 있습니다.

유효한 점과 그렇지 않은 점

많은 테이블 QA 질문이 셀을 선택하고 네 가지 스칼라 연산 중 하나를 적용함으로써 해결될 수 있다는 핵심 통찰은 테스트된 벤치마크에서 실증적으로 타당함이 입증되었습니다. 그러나 WikiTQ에 대한 논문의 정직한 오류 분석은 시사하는 바가 큽니다. 오류의 37%는 저자들조차 분류하지 못했고, 16%는 모델이 수행할 수 없는 문자열 조작을 요구하며, 10%는 복잡한 시간적 추론을 포함합니다. 이는 TAPAS의 한계가 집계 연산자가 잘못되었기 때문이 아니라, 특정 범주의 질문들이 구조적으로 범위 밖에 있기 때문임을 의미합니다.

512개 토큰 제한은 강력한 장벽입니다. 약 500개 이상의 셀이 있는 테이블은 잘려야 하며, 모델은 다중 테이블 추론 메커니즘이 없습니다. 이는 튜닝의 문제가 아니라 아키텍처의 문제입니다. 또한 모델은 집계를 중첩할 수 없습니다. "평균 잔액이 0보다 큰 계좌는 몇 개인가?"와 같은 질문은 두 번의 패스(COUNT 조건 내의 AVERAGE)가 필요하지만, 4가지 연산자 헤드로는 이를 표현할 수 없습니다.

TAPEX(ICLR 2022)는 위키백과 테이블 MLM을 자동 생성된 프로그램의 합성 SQL 실행으로 대체하여 사전 학습 병목 현상을 직접 해결했으며, WikiTQ를 57.5%(+4.8), SQA를 74.5%(+3.5)로 끌어올렸습니다. 이는 유의미한 격차입니다. 그러나 TAPEX 역시 테이블 크기와 구성 깊이에 대한 동일한 아키텍처적 한계를 상속받았습니다.

두 논문 모두 다루지 않은 더 깊은 미해결 문제는 셀 선택 패러다임이 벤치마크 정확도가 아닌 감사 가능성(auditability)과 정확성 보장이라는 실무적인 측면에서 SQL 생성보다 실제 테이블 QA에 더 적합한가 하는 점입니다. 셀 선택은 불투명합니다. 답변은 얻지만 프로그램은 얻을 수 없습니다. SQL 생성은 장황하지만 검증 가능합니다. 프로덕션 환경에서는 이러한 트레이드오프가 정확도 몇 포인트보다 더 중요합니다.

이것이 금융 AI에 중요한 이유

Beancount 장부는 사실상 평면적인 구조화된 테이블입니다. 행에는 계정, 열에는 금액, 날짜, 통화, 태그가 있습니다. TAPAS의 직접적인 셀 선택 패러다임은 "3월 식비 지출 총액은 얼마인가?"와 같은 가장 일반적인 장부 쿼리에 자연스럽게 매핑됩니다. 이는 필터링된 행에 대한 SUM 및 COUNT 집계와 정확히 일치합니다. 이전 답변 임베딩은 사용자가 쿼리를 구체화하는("작년은 어떤가요?") 대화형 세션에서 직접적으로 유용합니다.

하지만 대규모 Beancount 장부는 TAPAS의 제약 조건을 벗어납니다. 수천 개의 거래가 포함된 다년치 장부는 512개 토큰 예산을 수십 배 초과합니다. 계층 구조는 행 그룹 간의 추론을 요구합니다. "지난 3년 동안의 평균보다 순유출이 큰 계정은 어디인가?"와 같은 쿼리는 4가지 연산자 헤드가 표현할 수 없는 중첩 집계가 필요합니다. 결정적으로, 데이터 쓰기 작업의 안전성을 위해 셀 선택은 변경 사항을 커밋하기 전에 확인할 수 있는 감사 가능한 프로그램을 제공하지 않습니다. SQL은 최소한 검사 가능한 결과물이라도 제공합니다.

저의 잠정적인 결론은 셀 선택 패러다임이 소규모 장부 스냅샷(한 달 치 거래, 단일 계정 내역 등)에 대한 자연어 읽기 전용 쿼리 계층에는 적합한 인터페이스라는 것입니다. 전체 장부 추론이나 데이터 쓰기가 포함된 모든 작업의 경우, 프로그램 합성 방식(SQL 스타일이든 Beancount DSL이든)이 여전히 더 안전하고 표현력이 풍부합니다.

더 읽어볼 거리

• TAPEX: 신경망 SQL 실행기 학습을 통한 테이블 사전 학습 (arXiv:2107.07653, ICLR 2022) — 위키백과 MLM을 합성 SQL 실행으로 대체한 직접적인 후속 연구로, 프로그램 사전 학습이 텍스트 사전 학습보다 테이블 QA에 더 효과적인지 직접적으로 답합니다.
• Binder: 언어 모델을 기호 언어에 결합하기 (arXiv:2210.02875) — GPT-3를 사용하여 테이블에 대한 SQL 또는 Python 프로그램을 생성하고 WikiTQ에서 SOTA를 달성했습니다. 셀 선택 지지자들이 고려해야 할 하이브리드 접근 방식입니다.
• OmniTab: 테이블 QA를 위한 자연 및 인공 구조 데이터 (arXiv:2207.02270) — 자연어 테이블 말뭉치와 합성 SQL 데이터를 단일 사전 학습 레시피로 결합하여 TAPAS와 TAPEX가 경쟁 관계가 아닌 상호 보완 관계인지 테스트합니다.