[논문리뷰]ChatKBQA: A Generate-then-Retrieve Framework for Knowledge Base Question Answering with Fine-tuned Large Language Models

Date: 2024.09.16 Updated: 2024.09.16

카테고리: NR

Problem Statement

C1. 낮은 검색 정확도

자연어 형태의 질문의 경우 Knowledge Base에 있는 형태와 다름.
종종 엔티티나 릴레이션이 잘못 검색되거나, 검색하지 못하는 경우가 발생.
Ex) “한국의 수도는 어디인가?”
- In KB, ‘수도’ = m2476, ‘서울’ = m748

C2. 잘못된 검색 결과는 의미 분석을 혼란 시킴.

C1에서와 같이 검색 결과가 자연어가 아닌 엔티티 ID가 섞여 같이 LLM에 입력되면 의미상 혼란이 발생할 수 있음.
Ex) 질문: “한국의 수도는 어디인가?”, KB 검색 결과: (한국, ~이다, m2476), (m2476, 포함되다, m748)
- LLM ← “한국의 수도는 어디인가? (한국, ~이다, m2476), (m2476, 포함되다, m748)”
- 답변: 경주

C3. “검색(Retrieve)”, “변환(Transform)”, “생성(Generation)”의 반복 구조로 모델의 복잡성 증가

기존의 KBQA에서 RAG를 사용하는 모델들은 대부분 “Retrieve-then-Generation” 기반
LLM이 1)입력으로 들어오는 질문을 해석, 2)Database에 검색, 3)검색된 엔티티와 릴레이션을 자연어로 변환, 4)LLM에 입력, 5)정답 생성

Method

논리적 형식(Logical Form)

논리적 형식(Logical Form)은 복잡한 자연어 질문을 지식 베이스에서 실행할 수 있는 형식으로 변환한 것이다. 그래프 쿼리(Graph Query)는 지식 베이스 상에서 조건을 만족하는 경로를 탐색하는 질의다. 위 사진에서는 고혈압과 심부전에 적합하면서 신부전에 금기사항이 아닌 약물들을 찾아, 그 중 상호 상승 효과가 있는 약물을 탐색하는 과정이 그래프 형태로 표현된 것이다.

그래프 쿼리에서 AND와 NOT 연산자는 질의에서 여러 관계를 동시에 만족시키거나 배제하는 역할을 한다. 예를 들어, Hypertension과 Heart Failure에 모두 적합한 약물을 찾아야 하므로 이 둘 사이에는 AND 연산이 사용되고, Kidney Failure에 금기사항인 약물을 제외하기 위해 NOT 연산이 사용된다.

지식 베이스(Knowledge Base, KB)는 RDF(Resource Description Framework) 그래프의 한 종류로, 지식을 (주체, 술어, 객체) 형태의 트리플로 저장한다. KB는 \(\mathcal{K} = (s, r, o)\)로 표현한다. 논리적 형식 자연어 질문을 구조화된 표현으로 나타낸 것이다. S-표현식(S-expression)에 기반해 트리플을 표현한다. S표현식이란 리스트와 기호로 이루어진 단순한 형태의 표현 방식이다.

One-hop 쿼리 = triple = (s, r, o)
- (s, r, ?) = (JOIN (R r), S)
- (?, r, o) = (JOIN r o)
- E1과 E2의 interaction = (AND E1 E2)
- E1을 counting = (COUNT E1)

이외에도 논문에서는 여러 가지 기호를 사용하여 정의한다. ChatKBQA는 주어진 질문에 대한 정답을 찾기 위해 지식 베이스를 검색하고, 그 과정에서 SPARQL을 사용하게된다. 입력으로 들어온 자연어 질문(query)과 KB를 각각 \(\mathcal{Q}\), \(\mathcal{K}\)라 할 때, 먼저 ChatKBQA는 논리적 형식으로 바꾸는 작업을 한다. 논리적 형식을 \(F\)라 할 때, 자연어 질문을 바꿔주는 Semantic parsing 함수를 \(\text{Sp}(Q)\)라고 하면\(F = \text{Sp}(Q)\)로 표의

이전 연구들에서는 주로 지식 베이스를 활용한 QA 문제를 풀 때 Retrieve-then-Generate 형식을 취했다. 즉, 주어진 질문과 관련된 토픽 엔티티(Topic entity)를 기반으로 KB에 검색하고, 토픽 엔티티를 기반으로 정답 엔티티로 가능 추론 경로(reasoning path)를 추출하고, 이 추론 경로를 LLM에 넣어주어 정답을 생성하는 방식이다. 예를 들어 RoG나 GNN-RAG같은 모델이 이에 해당한다.

혹은 입력으로 들어온 질문에 대해 먼저 KB에서 관련된 엔티티와 릴레이션을 검색하고 이를 기반으로 의미 분석(Semantic parsing)을 통해 논리적 형식을 생성하는 방법을 따른다. 이러한 방식은 ChatKBQA와 정반대 방식이며, 검색된 엔티티나 릴레이션이 부정확한 경우 이후 논리적 형식이 잘못될 수 있다는 치명적인 단점이 존재한다. 따라서, 중간 단계에서 한 번 잘못 검색되면 최종 답변에 부정적인 영향을 주게된다.

반면 ChatKBQA는 Generate-then-Retrieve 방식이다. 먼저 논리적 형식(Logical form)을 생성하고, 이를 SPARQL 쿼리로 변환 후 KB에 검색하는 방식이다. 논리적 형식을 먼저 생성하기 때문에, 잘못된 검색 결과가 논리 구조에 영향을 주지 않으며, 따라서 검색의 오류를 줄여 더 정확한 결과를 도출할 수 있게 된다.

Model Architecture

ChatKBQA는 크게 네 단계에 걸쳐 정답을 생성하게 된다. 가장 먼저 논리적 형식을 생성하기 위해 1)LLM을 fine-tuning한다. 그리고 학습된 LLM을 사용해 질문에 대한 논리적 형식을 생성하고 2)Beam search를 통해 가장 좋은 논리적 형식을 생성하게 된다. 최종적으로 생성된 논리적 형식은 자연어만을 포함하기 때문에, 이를 3)엔티티의 ID와 릴레이션 ID로 변환하는 과정을 거치고, 변환된 논리적 형식을 고정된 함수에 넣어 4)SPARQL 쿼리로 변환한다. 그리고 변환된 쿼리를 통해 KB에 검색하고 정답을 찾게된다.

1) Fine-tuning LLM

ChatKBQA이 LLM을 학습하는 처음이자 마지막인 단계이다. LLM이 입력으로 들어오는 자연어 질문 쿼리에 대해 논리적 형식(Logical form)을 출력할 수 있도록 Fine-tuning하는 단계이자, 이는 곧 Instruction tuning과도 동일하다. 다시 말해, LLM이 입력으로 들어온 질문에 대해 Instruction 형태로 결과를 출력하도록 학습을 유도한다. LLM은 Llama2-7B와 Llama2-13B를 사용하였다.

예를 들어, 입력으로 “What is the name of Justin bieber’s brother?“라는 질문이 들어왔을 때 LLM이 출력하는 논리적 형식은 다음과 같다.

"( AND ( JOIN [ people , person , gender ] [ Male ] ), 
 	     ( JOIN ( R [ people , sibling relationship , sibling ]),
       ( JOIN ( R [ people , person , siblings ] ) [ Justin Bieber])"

2) Beam Search using Fine-tuned LLM

다음으로 학습된 LLM을 논리적 형식을 만드는 과정이다. LLM은 fine-tuning을 통해 의미 분석(semantic parsing)을 위해 자연어 질문을 논리적 형식으로 변환하는 지식을 습득하였다. 저자들은 학습 중 등장하지 않은 test set의 질문들에 대해 미리 정답이 되는 논리적 형식을 만들고, LLM이 출력한 논리적 형식과 비교하였다. 그 결과, LLM은 63%의 정확도로 정확하게 논리적 형식을 생성해내었다.

논문에서는 좀 더 높은 정확성을 위해 Beam Search를 통한 논리적 형식 생성 방식을 제안한다. 또한 후보 논리적 형식에서 채워지지않은 엔티티와 릴레이션의 자리를 []로 대체한 논리적 형식의 스켈레톤 구조를 통해 더 정확한 논리적 형식을 생성해 내도록 하였다. 예를 들어, LLM이 ( JOIN ( R [ people , person , siblings ] ) [ Justin Bieber]) S-표현식에서 릴레이션의 정보를 찾지 못했다면 다음과 같이 모델이 출력한다. 참고로 (JOIN (R r), S)은 헤드와 릴레이션(=주체와 술어)이 주어진 상태를 의미한다.

# (s, r, ?) = (**JOIN** (R r), S)

"( AND ( JOIN [ people , person , gender ] [ Male ] ), s

Beam search는 단일 호출로 끝나는 것이 아니라 여러 번의 반복적인 추론이 필요하다. 먼저 LLM이 다양한 후보 논리적 형식(logical forms)를 생성하고, 이를 기반으로 최적의 결과를 선택하는데, 이 과정에서 여러 번의 호출이 이루어질 수 있다. Beam Search를 통해 여러 개의 후보 답변을 생성하고, 각 후보에 대해 추가적으로 평가가 이루어진다. 이때 각 후보에 대해 LLM이 반복적으로 호출된다. 따라서, LLM이 한 번만 호출되는 것은 아니다. 후보군을 평가하고 비교하는 과정에서 여러 번의 호출이 이루어지며, 이를 통해 최적의 결과를 찾게 된다. Beam Search의 결과는 예를 들어 다음과 같다.

#Input: What is the name of Justin bieber's brother?

# 후보 1 (완전한 논리적 형식)
  (AND 
  (JOIN [people, person, gender] [Male]) 
  (JOIN (R [people, sibling relationship, sibling]) 
  (JOIN (R [people, person, siblings]) [Justin Bieber])))

# 후보 2 (부분적으로 릴레이션을 찾지 못한 경우)
  (AND 
  (JOIN [people, person, gender] [Male]) 
  (JOIN (R [] [])  # 이 부분에서 릴레이션을 정확히 예측하지 못함
  (JOIN (R [people, person, siblings]) [Justin Bieber])))

# 후보 3 (다른 릴레이션 사용)
  (AND 
  (JOIN [people, person, gender] [Male]) 
  (JOIN (R [family relationship, sibling]) 
  (JOIN (R [people, person, siblings]) [Justin Bieber])))

# 후보 4 (다른 구조 사용)
  (AND 
  (JOIN [people, person, gender] [Male]) 
  (JOIN (R [person, relative])
  (JOIN (R [people, person, siblings]) [Justin Bieber])))

# 후보 5 (부분적으로 릴레이션을 찾지 못한 경우)
  (AND 
  (JOIN [people, person, gender] [Male]) 
  (JOIN (R [] [sibling])  # 일부 릴레이션을 찾지 못함
  (JOIN (R [people, person, siblings]) [Justin Bieber])))

3) Transform and Retrieve

SimCSE는 유사도 계산을 위한 모델로서, 문장 임베딩을 생성하는 데 사용된다. 이 모델은 대조 학습을 기반으로 학습되며, 유사한 문장끼리의 의미적 유사성을 잘 포착하는 능력을 갖춘다. 알고리즘에서 SimiEntities나 SimiRelations 함수가 SimCSE를 이용해 엔티티나 릴레이션의 유사도를 계산하는 역할을 한다. 사전 학습된 SimCSE를 통해 효율적이고 정확하게 유사한 엔티티나 릴레이션을 검색할 수 있는 장점이 있다.

Unsupervised retrieval은 fine-tuned LLM이 생성한 논리적 형식의 구조(logical form skeleton)을 기반으로, KB에서 엔티티와 릴레이션을 찾아오는 방법이다. 이 방식은 phrase-level의 의미적 유사성을 기준으로 엔티티와 릴레이션을 검색하여 최종적으로 실행 가능한 SPARQL 쿼리로 변환하는 것을 목표로 한다.

# 후보 1 (완전한 논리적 형식)
  (AND 
  (JOIN [people, person, gender] [Male]) 
  (JOIN (R [people, sibling relationship, sibling]) 
  (JOIN (R [people, person, siblings]) [Justin Bieber])))

Phrase-level의 의미적 유사성이랑 다시 말해 완전한 논리적 형식이 주어졌을 때, 논리적 형식에서 전체 구조를 한번에 평가하는 것이 아니라, 각각의 부분(예: 엔티티와 릴레이션)을 개별적으로 처리한다는 의미이다. 즉, 순차적으로 (JOIN [people, person, gender] [Male]), (JOIN (R [people, sibling relationship, sibling]), (JOIN (R [people, person, siblings]) [Justin Bieber])를 처리하며 이 과정에서도 각 자연어 순서대로 엔티티 ID나 릴레이션 ID로 변환하게 된다.

Unsupervised Retrieval의 핵심은 논리적 형식에 존재하는 자연어를 KB에 존재하는 엔티티와 릴레이션의 ID로 변환하는 과정이라는 것이다. Algorithm 1은 LLM이 생성한 후보 논리적 형식(candidate logical forms)을 입력으로 받아, 각 엔티티와 릴레이션에 대해 유사도 기반으로 최적의 결과를 찾아낸다.

1. 엔티티 검색
1) 입력으로 주어진 논리적 형식 목록에서 각 논리적 형식(\(F\))을 순회한다.
2) 논리적 형식 내의 각 엔티티(\(e\))에 대해, 지식베이스의 엔티티 집합 E에서 엔티티 \(e\)와 유사한 엔티티 \(e'\)의 유사도(\(s_e\))를 계산한다. 여기서 유사도 계산은 \(\text{SimiEntities}(e, e')\) 함수가 수행한다.
3) 유사도가 높은 순으로 엔티티를 정렬한 후, 상위 \(k_e\) 개의 엔티티를 선택하고 유사도 임계값 te를 넘는 엔티티들만 남긴다.
4) 각 엔티티 자리에 대해 여러 조합(PermuteByEntity)을 수행하여 후보 논리적 형식 목록을 업데이트한다. 최종적으로 새로운 후보 논리적 형식 목록(\(C'\))을 얻는다.

2. 릴레이션 검색
1) 업데이트된 논리적 형식 목록(\(C'\))에서 다시 각 논리적 형식(\(F\))을 순회한다.
2) 논리적 형식 내의 각 릴레이션(\(r\))에 대해, 해당 논리적 형식의 엔티티 집합 EF와 관련된 릴레이션 \(r'\)와의 유사도(\(s_r\))를 계산한다. 유사도 계산은 \(\text{SimiRelations}(r, r')\) 함수가 수행한다.
3) 엔티티 검색과 유사하게 유사도가 높은 순으로 정렬하고, 상위 \(k_r\) 개의 릴레이션과 임계값 \(t_r\)을 넘는 릴레이션들을 선택한다.
4) 릴레이션 자리에 대해서도 조합(PermuteByRelation)을 수행하여 논리적 형식 목록을 업데이트하고, 새로운 후보 논리적 형식 목록(\(C''\))을 얻는다.

3. SPARQL 쿼리 변환
1) 엔티티와 릴레이션 검색이 끝나면 최종적으로 논리적 형식 \(C''\)에서 각 논리적 형식을 SPARQL 쿼리로 변환한다.
2) 변환변환된 쿼리가 실행 가능한지 확인하고, 실행 가능하면 그 쿼리를 반환한다. 그렇지 않으면 다음 논리적 형태로 넘어간다.

SPARQL 쿼리로 변환하는 과정은 고정된 변환 함수를 사용하여 이루어진다. 논리적 형식이 엔티티와 관계로 변환된 후, 이를 SPARQL 쿼리로 변환하는 것은 일정한 규칙과 구조를 따르는 변환 함수에 의해 수행된다. 즉, 논리적 형식을 SPARQL 쿼리로 변환하는 과정은 이미 정의된 규칙에 따라 고정된 방식으로 이루어지며, 각 논리적 형식의 구성 요소가 SPARQL의 쿼리 구조에 맞게 매핑된다. 예를 들어, 논리적 형식의 JOIN, AND 등의 연산자는 SPARQL 쿼리의 대응하는 부분으로 변환되고, 엔티티와 관계는 KB에 존재하는 ID로 변환된 후 SPARQL 쿼리 내에서 사용된다.

이렇게 고정된 변환 과정을 통해 최종적으로 SPARQL 쿼리가 생성되고, 이는 KB에 실행되어 답을 얻는 데 사용된다.

Experiments and Results

Main Result

ChatKBQA는 다른 QA모델에 비해 성능이 압도적인 것을 알 수 있다. 하지만, Oracle Entity Linking Annotation을 했을 땨와 안했을때 성능 차이가 많이 나는 것을 알 수 있다.

Oracle Entity Linking Annotation(OELA)의 역할
Oracle Entity Linking Annotation은 정답 엔티티를 미리 주어진 상태에서 수행하는 방법을 의미한다. Oracle이라는 용어는 실제 지식베이스에 있는 엔티티를 정확하게 알고 있는 상태에서 질문을 처리한다는 뜻이다.

일반적인 KBQA 시스템에서는 자연어 질문에서 엔티티 추출 및 엔티티 연결 과정을 거친다. 이 과정에서 질문에 등장하는 문구를 지식베이스에 있는 정확한 엔티티 ID로 매핑해야 하는데, 이는 복잡하고 오류가 발생할 가능성이 있다. 하지만 OELA에서는 이러한 엔티티 연결 과정에서 발생할 수 있는 오류를 무시하고, 이미 정답 엔티티가 연결된 상태에서 모델이 성능을 평가받는다.

예를 들어, 질문이 “What is Justin Bieber’s brother’s name?”이라면:

일반적인 엔티티 링크 과정에서는 “Justin Bieber”라는 이름을 Freebase나 Wikidata와 같은 KB의 고유 ID로 연결해야 한다.
Oracle entity linking에서는 이미 Justin Bieber가 해당 KB의 고유 ID로 정확히 주어진 상태에서 작업이 진행된다.

왜 사용하는가?
OELA는 엔티티 연결 과정에서 발생하는 잡음(noise)을 제거하고, 모델이 정확한 논리적 형식 생성이나 관계 추론에서 얼마나 성능이 좋은지를 평가하기 위해 사용된다. 즉, 엔티티 추출 및 연결에서의 오류 없이, 순수한 모델의 능력을 평가하는 목적이 있다. ChatKBQA에서는 OELA을 사용한 실험은 정확한 엔티티가 미리 주어진 상태에서, 모델이 논리적 형식을 생성하고 관계를 추론하는 능력을 평가하기 위한 것이다.

Ablation Study and Analysis

1. LLM의 파인튜닝(Fine-tuning) 효과

Figure 4(a)에 따르면, KBQA의 성능은 훈련 데이터 양이 증가함에 따라 향상되는 경향을 보인다. 파인튜닝을 통해 LLM이 적은 양의 데이터만으로도 높은 학습 성과를 보여주며, 20%의 데이터만을 사용했을 때도 F1 점수가 70%를 넘는 것을 확인할 수 있다. 이는 LLM이 제한된 데이터셋에서도 학습을 잘 수행할 수 있음을 나타낸다.

2. Beam Search의 효과

Figure 4(b)에서는 Beam Search가 논리적 형태 생성을 개선하는 데 기여한 것을 볼 수 있다. Beam 크기가 커질수록 성능이 향상되며, F1, Hits@1, Acc 모두 일정한 증가 추세를 보인다. 이는 더 많은 후보를 생성하고 그 중 최적의 논리적 형태를 선택하는 Beam Search가 KBQA 성능 향상에 효과적임을 보여준다.

3. Entity Retrieval(ER)의 효과

ER(엔티티 검색)의 효과는 Figure 4(b)에 잘 나타나 있다. ER을 사용하지 않았을 때보다, ER을 사용했을 때 F1 점수가 약 15% 정도 증가한다. 이는 LLM이 생성한 논리적 형태가 훈련 세트에 없는 엔티티를 포함하는 경우에도, 지식베이스에서 적절한 엔티티를 검색하여 정확한 응답을 얻을 수 있음을 보여준다.

4. Relation Retrieval(RR)의 효과

RR(릴레이션 검색)은 F1 점수를 약 5% 정도 향상시키는 것으로 확인된다. 비록 자연어 질문에서 릴레이션이 명시적으로 등장하는 경우가 많지 않지만, 릴레이션의 종류는 상대적으로 적기 때문에 릴레이션 검색이 더 효율적일 수 있다. LLM이 릴레이션 정보를 잘 학습하기 때문에, ER과 RR을 함께 사용하면 KBQA의 성능이 최적화되는 것을 확인할 수 있다.

결론적으로, 파인튜닝된 LLM을 통해 데이터가 제한된 상황에서도 높은 성능을 보일 수 있으며, Beam Search, Entity Retrieval(ER), Relation Retrieval(RR)의 사용이 성능 향상에 중요한 역할을 한다. 또한 우측 표에 의하면 Llama2-13B를 사용했을 때 가장 성능이 좋음. 하지만, beam size와의 trade-off가 있다. 또한 LoRA + SimCSE 조합의 성능이 가장 뛰어나다.

Error Analysis

WebQSP 테스트 세트에서 ChatKBQA가 oracle entity linking 없이 정답을 맞추지 못한 질문들에 대한 오류 분석은 다음과 같이 요약할 수 있다.

1. Logical form skeleton error (40.10%)

오류의 대부분은 ChatKBQA가 질문에 대한 올바른 논리적 형식 스켈레톤을 제공하지 못한 경우에서 발생한다. 예를 들어, "(JOIN (R []) (JOIN (R []) []))" 대신 "(JOIN (R []) [])"를 예측하는 것과 같은 오류이다. 이는 훈련 세트에서 복잡한 스켈레톤에 대한 제한된 표현으로 인해 발생한다.

2. Entity retrieval error (27.17%)

정확한 논리적 형식 스켈레톤을 예측한 후에도 올바른 엔티티를 검색하지 못한 경우가 있다. 예를 들어, "(JOIN (R []) m.0d3k14)"를 "(JOIN (R []) m.07618sw)"로 예측하는 것이 그 예시이다.

3. Relation retrieval error (19.48%)

논리적 형식 스켈레톤 예측과 엔티티 검색에 성공한 경우에도 관계 검색에서 오류가 발생할 수 있다. 이는 올바른 논리적 형식을 생성하지 못하게 하여 정답과 일치하지 않는 결과를 초래한다. 예를 들어, "(JOIN (R finance.currency.countries_used) m.0kz1h)" 대신 "(JOIN (R finance.currency.currency_code) m.0kz1h)"를 예측하는 경우이다.

4. SPARQL 변환 오류 (13.26%)

마지막으로, 남은 오류의 작은 부분은 생성된 논리적 형식이 정답과 일치하지만 SPARQL로 변환할 때 실행되지 않거나, 변환 과정에서 답변이 일관성이 없는 경우에서 발생한다. 이는 논리적 형식에서 SPARQL로 변환하는 과정에서의 손실로 인해 발생할 수 있다.

Limitations and Contributions

Limitations
- 어느 모듈이 구체적으로 성능 기여를 크게 하는지 파악이 안됨
Contribution
- sLM을 사용했음에도 불구하고 ChatGPT와 같은 초거대 LLM 기반의 모델들보다 성능이 좋음
- SOTA달성

Reference

[1] Haoran Luo, Haihong E, Zichen Tang, Shiyao Peng, Yikai Guo, Wentai Zhang, Chenghao Ma, Guanting Dong, Meina Song, Wei Lin, Yifan Zhu, and Luu Anh Tuan. 2024. Chatkbqa: A generate-then retrieve framework for knowledge base question answering with fine-tuned large language models.

Meaningful