[논문리뷰]Think-On-Graph: Deep and Responsible Reasoning of Large Language Model on Knowledge Graph
카테고리: NR
Sun, J., Xu, C., Tang, L., Wang, S., Lin, C., Gong, Y., Ni, L. M., Shum, H., & Guo, J. (2023, July 15). Think-on-Graph: Deep and responsible reasoning of large language model on knowledge graph. arXiv.org. https://arxiv.org/abs/2307.07697
Problem Statement
1. 추론 작업에 대한 정확한 답변 제공 실패
LLM은 특히 특화된 지식(specialized knowledge)와 복잡한 추론 작업에 대해 정확한 답변을 내지 못하는 경우가 종종 있다. 이는 모델의 훈련에 사용된 대규모 텍스트 데이터에 포함되지 않은 최신 정보나 흔하지 않은 정보 등을 포함하기 때문이다. 또한, 논리적 연결 고리(reasoning chain)이나 다중 단계 추론(multi-level reasoning, 여러 정보를 연결해야 답이 도출되는 경우)이 필요한 작업에서는 LLM이 정확한 결과를 제공하지 못하는 경우가 많다. 위의 그림처럼, LLM은 종종 매우 긴 context나 Multi-hop reasoning을 하에 있어서 잘못된 대답을 생성하는 경우가 종종 발생한다.
2. 책임감(Responsibility), 설명 가능성(Explainability), 투명성(Transparency)의 부재
LLM은 보통 블랙박스처럼 작동하며, 출력에 대한 명확한 이유나 설명을 제공하지 않는다. 이러한 불투명성은 생성된 텍스트의 신뢰성과 잠재적 편향에 대한 우려를 불러일으킨다. 또한, LLM은 그럴듯하지만 잘못되거나 무의미한 답변을 생성하는 “환각(hallucination)” 현상이 발생할 수 있다. 이러한 설명 가능성의 부족과 잘못된 또는 유해한 콘텐츠를 생성할 위험성은 높은 신뢰성과 책임이 요구되는 응용 분야에서 LLM을 신뢰하기 어렵게 만든다.
3. 비싼 학습 비용
LLM을 훈련하는 데는 매우 많은 양의 컴퓨터 자원(computer resource)를 요구한다. 이로 인해 모델을 최신 상태로 유지하는 것이 어렵다. 결과적으로, LLM은 시간이 지남에 따라 성능이 저하될 수 있으며, 이는 초기 훈련 데이터에 포함되지 않은 새로운 정보와 지식이 등장하기 때문이다.
이중에서도 특히 LLM의 환각(Hallucination)에 대한 문제가 매우 중요하다. LLM에서 환각 문제는 크게 다섯 가지 카테고리로 분류된다.
- 환각(Hallucination)
- 사실적 환각(Factual Hallucination): 모델이 존재하지 않는 사실을 생성하는 경우이다. 예를 들어, 실제로 존재하지 않는 사건이나 인물에 대한 정보를 생성하는 경우가 이에 해당한다.
- 언어적 환각(Linguistic Hallucination): 생성된 텍스트가 문법적으로나 언어적으로 비논리적인 경우이다. 이는 문장이 비문법적이거나, 문맥적으로 일관성이 없는 경우를 포함한다.
- 맥락적 환각(Contextual Hallucination): 질문의 맥락과 관련 없는 정보를 생성하는 경우이다. 모델이 질문을 잘못 이해하거나, 관련 없는 정보를 답변에 포함시키는 경우가 이에 해당한다.
- 내부적 환각(Intrinsic Hallucination): 모델의 내부 일관성이나 논리와 충돌하는 정보를 생성하는 경우이다. 예를 들어, 문장의 앞부분과 뒷부분이 모순되는 내용을 담고 있는 경우이다.
- 외부적 환각(Extrinsic Hallucination): 모델이 외부 지식과 충돌하는 정보를 생성하는 경우이다. 이는 모델이 잘못된 외부 정보를 기반으로 답변을 생성할 때 발생한다.
이런 환각 문제를 완화하여 LLM이 정확한 추론을 할 수 있도록 만들기 위해 최근 프롬프트 엔지니어링(Prompt Engineering)과 지식 그래프(Knowledge Graph)를 활용하는 것이 최근 연구의 트렌드이다.
Related Work
LLM with Knowledgw Graph
최근 LLM의 환각(hallucination) 문제를 완화하고자 RAG의 아이디어를 이용해 LLM 외부에서 지식 그래프(knowledge graph) 검색을 활용하려는 여러 시도들이 있었다. QA 문제를 해결함에 있어 지식 그래프는 여러 장단점을 가진다. 다음은 LLM과 KG과 상호 보완적 관계에 있음을 보여주는 그림이다.
LLM은 일반화된 지식을 학습하고, 질문에 대한 답변을 생성해 내는 등 general하게 사용할 수 있다는 장점이 있다. 하지만, Problem Statement에서 언급하였듯, 특화된 지식이나 전문 영역에서는 틀린 답을 종종 생성해내며, 이는 결국 hallucination으로 이어진다. 반면 KG는 일반화된 지식이 아닌, 지식을 자연어와 그래프로 구조화하여 저장하고, 정확하고 명시적인 지식 정보를 가지고 있다. 하지만, 그래프 형식으로 데이터를 저장하다보니 LLM의 학습 데이터인 document들에 비해 적은 양의 text를 포함하고 있고, 불완전(incomplete)하다는 단점이 존재한다. LLM은 일반화된 지식으로 KG의 단점을 보완할 수 있고, KG 또한 LLM에 구조화되고 특화된 지식을 전달해줌으로써 답변의 질을 높일 수 있다.
하지만, LLM에 KG를 접목시키는 지난 연구들은 여전히 한계점이 존자핸다. 위의 그림에서 LLM⨁KG 방식이 선행 연구들에 해당한다. LLM⨁KG는 지식 그래프 KG에서 정보를 검색하고, 이에 따라 프롬프트를 보강한 후, 보강된 프롬프트를 다시 LLM에 입력하는 방식을 취한다. 하지만 가장 단순하게 KG에 검색하는 것은 프롬프트가 길어지거나 복잡한 질문(query)에 대해서는 제대로된 답을 도출하지 못한다. 또한 단순 검색은 구조적으로 복잡한 KG의 장점을 제대로 활용하지 못한다는 한계점을 가지고 있다. 본 논문에서는 이 한계점을 극복하고 hallucination을 완화하여 KGQA문제를 푸는 프롬프트 엔지니어링 방식을 제안한다.
Method
1. Overview: Asking LLM to perform beam search on KG
Think-on-Graph(ToG)는 크게 i) Search, ii) Prune, iii) Reasoning 세 가지 과정을 거쳐서 입력으로 들어온 프롬프트에 대한 정답을 생성해낸다. 위의 그림은 ToG의 전체적인 과정을 보여준다.
1) 입력으로 들어온 프롬프트에서 Search를 시작할 엔티티들을 추출한다. 2) Search: Beam Search를 통해 관련성이 깊은 여러 엔티티들을 추출한다. 3) Prune: 해당 엔티티들을 LLM에 입력시켜 가정 적합한 엔티티를 선택한다. 4) Reasoning: 선택된 엔티티를 기반으로 입력 프롬프트의 정답을 생성할 수 있는지 LLM을 통해 평가하고 만약 불가능하다고 LLM이 판단하면 앞의 search와 prune, reasoning을 반복하여 Multi-path reasoning을 실행한다.
이 경우, 각 iteration마다 총 N개의 경로를 뽑는다고 하고, 총 D번의 iteration을 반복해서 위의 알고리즘을 실행한다면 하나의 프롬프트에 정답을 출력하는데 \(2ND + D +1\)번 호출하게 된다. \(ND\)번은 Search를 하기위해 LLM을 호출하는 횟수이고, \(ND\)는 Pruning하는데 LLM을 호출하는 횟수이다. 그리고 각 iteration마다 정답을 출력할 수 있는지 평가(reasoning)하기 위해 LLM을 호출하므로 총 reasoning을 위해 총 \(D\)번의 LLM을 홏호출한다. 마지막으로 \(1\)은 시작 엔티티를 intialization하기 위해 LLM을 호출하는 것이다.
Experiments
1. Main Result
총 9개의 dataset에 대하여 QA문제를 풀었으며, Open-Domain Question Answering(ODQA)과 Knowledge Intensive Task(KIT) 모두 포함된다. 이들 중 총 6개의 데이터셋에서 state-of-the-art(SOTA)를 달성하였다. ToG-R은 ToG에서 KG를 검색해 multi-hop path를 엔티티에 대한 정보는 사용하지 않고, relation에 대한 path만 사용하는 것이다. ToG-R에서는 random prune을 하기 때문에 총 \(ND + D +1\)번만 호출하면 된다.(모든 엔티티에 대해 일일히 평가할 필요 없이, 랜덤하게 하나를 선택하는 것)
2. Backbone별 성능 비교
ToG와 ToG-R에서 backbone LLM을 바꿔가면서 성능 비교 실험을 하였다. 당연하게도, LLM의 크기가 커질수록 성능은 증가하였으며, baseline과의 격차 역시 증가하였다.
3. Search와 Prune에 다른 모델 적용한 실험
KG에서 Search와 Prune과정을 LLM이 아닌 다른 모델(BM25, SentenceBERT)을 통해서 진행하고, Initialization과 Reasoning과정에서만 LLM을 호출하게하여 성능을 비교하는 비교실험이다. 이 때, 두 과정에서 LLM을 호출하지 않으므로 하나의 프롬프트에 대해 LLM을 호출하는 총 회수는 \(D + 1\)이 된다.
LLM으로 Search와 Prune을 할때보다는 성능이 감소하지만, LLM의 호출횟수가 압도적으로 적기 때문에 시간과 컴퓨팅 자원측면에서 효율적이다. 또한 성능 감소가 critical하지 않기 때문에 이는 ToG가 충분히 경쟁력 있음을 말해준다.
댓글 남기기