원본 논문 링크 : https://arxiv.org/abs/2406.12430
PlanRAG: A Plan-then-Retrieval Augmented Generation for Generative Large Language Models as Decision Makers
In this paper, we conduct a study to utilize LLMs as a solution for decision making that requires complex data analysis. We define Decision QA as the task of answering the best decision, $d_{best}$, for a decision-making question $Q$, business rules $R$ an
arxiv.org
1 Introduction
- 이 연구에서는 복잡한 데이터 분석을 요구하는 의사 결정 문제를 해결하기 위해 LLM을 활용하는 방법을 탐구한다.
- 이 논문에서는 비즈니스 상황에서의 의사 결정 문제를 다룬다.
- 비즈니스 상황에서의 의사 결정 문제는 아주 중요하고 복잡하며, 이는 주어진 데이터를 분석하고 가장 최적의 대안을 선택는 과정 전체를 의미한다.
- 이러한 의사 결정 과정은 보통 세 가지 단계로 이루어진다:
- (1) 어떤 분석이 필요한지 계획을 수립
- (2) 필요한 데이터를 검색하고 분석
- (3) 분석 결과를 기반으로 최적의 결정을 내리는 것
- 기존의 의사 결정 지원 시스템은 데이터 검색과 분석(2, 3단계)을 자동화하는 데 집중했으나, 어떤 분석을 수행해야 하는지 계획하는 단계(1단계)는 여전히 인간이 담당해야 했다. 이 연구는 LLM이 이 계획 단계까지 포함하여 의사 결정 전 과정을 end-to-end 수행할 수 있는지를 탐구한다.
- 이를 위해 본 논문에서는 Decision QA라는 새로운 문제 정의를 제안하며, 이는 의사 결정 질문 Q, 비즈니스 규칙 R, 데이터베이스 D를 입력으로 받아 최적의 결정을 도출하는 질의응답(QA) 형태의 문제다.
- 그러나 현재 Decision QA를 평가할 벤치마크가 없기 때문에, 두 가지 시나리오(Locating과 Building, 추후 설명)에 대한 DQA(Decision QA Benchmark)를 구축하였다.
- 이 벤치마크는 현실적인 비즈니스 문제를 모방한 두 개의 비디오 게임 Europa Universalis IV와 Victoria 3에서 추출한 301개의 상황을 기반으로 한다.
- 기존의 RAG(Retrieval-Augmented Generation) 기반 접근법은 의사 결정 문제를 해결하는 데 한계가 있다. 특히, 기존 방법들은 데이터 검색 및 분석(의사 결정 과정의 2단계와 3단계)에는 효과적이지만, 어떤 분석이 필요한지 계획을 수립하는 1단계는 제대로 처리하지 못한다.
- 이를 해결하기 위해, 저자들은 새로운 RAG 기법인 PlanRAG(Plan-then-Retrieval Augmented Generation)을 제안한다.
- PlanRAG는 먼저 의사 결정에 필요한 분석 계획을 생성한 후, 해당 계획에 따라 데이터를 검색하고 분석하며, 필요할 경우 계획을 재조정하는 방식으로 동작한다.
- 이 논문의 Contribution은 아래의 4가지이다.
- Decision QA라는 새로운 task 제안
- DQA라는 Decision QA를 다루는 새로운 벤치마크를 제안
- Decision QA task에 대한 SOTA 방법론인 PlanRAG를 제안
- PlanRAG가 다른 방법론(iterative RAG)보다 뛰어남을 입증
2 Decision QA task
- 이 섹션에서는 Decision QA라는 task를 수학적 기호로 정의한 섹션이다.
- Decision QA는 의사 결정 질문 $Q$, 비즈니스 규칙 $R$, 그리고 구조화된 데이터베이스 $D$를 기반으로 최적의 의사 결정 $d_{best}$를 도출하는 문제이다. 여기서 $Q$는 사용자가 달성하고자 하는 목표를 서술한 텍스트이며, $R$은 $d_{best}$를 추론하는 데 필요한 수식이나 규칙을 의미한다.
- 데이터베이스 $D$는 너무 크기 때문에 한 번에 LLM에 입력할 수 없다. 따라서 LLM은 데이터 분석을 위한 쿼리를 생성하여 $D$에서 필요한 정보를 검색하는 방식으로 데이터를 활용한다. 이를 데이터 분석 쿼리(data analysis query)라고 한다.
- 또한, $D$는 LPG(Labeled Property Graph) 데이터베이스 또는 RDB(Relational DataBase) 중 하나일 수 있다.
- RDB는 테이블 형식으로 데이터를 저장하며, LPG는 Node와 edge를 가지는 그래프 형태의 데이터베이스로 널리 사용된다.
- 이 연구에서는 LPG 데이터베이스를 그래프 데이터베이스(GDB)라고 부르기로 한다.
3 DQA : Decision QA benchmark
- 이 섹션에서는 본 논문에서 제시하는 새로운 벤치마크인 DQA를 설명한다.
- 이 벤치마크는 두 가지 시나리오(Locating, Building)로 구성되며, 현실적인 의사결정 문제를 모사하기 위해 Europa Universalis IV와 Victoria 3라는 전략 게임의 데이터를 기반으로 구축되었다.
- 각 시나리오의 예시
- 아래의 Figure 1은 DQA 데이터셋의 하나의 예시를 보여준다.
1. Locating 시나리오
- 특정 국가가 최대한의 이익을 얻기 위해 어느 무역 노드(trade node)에 상인을 배치해야 하는지 결정하는 문제를 다룬다.
- 데이터베이스는 관계형 데이터베이스(RDB)와 그래프 데이터베이스(GDB)로 구성되며, 각각 무역 흐름, 국가, 무역 노드 간 관계 등의 정보를 포함한다.
- 의사결정은 이익(profit)의 변화량을 최대화하는 무역 노드를 선택하는 방식으로 이루어진다.
2. Building 시나리오
- 공장에서 특정 상품을 생산하여 시장 가격을 낮추기 위해 어떤 공장의 규모를 확장해야 하는지 결정하는 문제를 다룬다.
- 데이터베이스는 상품(Goods), 수요(Demand), 공급(Supply), 공장(Buildings) 등의 정보를 포함하며, 공장 확장을 통해 상품 가격이 어떻게 변하는지를 예측해야 한다.
- 목표는 특정 상품의 시장 가격을 최소화하는 공장을 선택하는 것이다.
3. DQA의 데이터 통계
- 총 301개의 문제(Locating: 200개, Building: 101개)로 구성되었으며, 각각 관계형 데이터베이스(RDB)와 그래프 데이터베이스(GDB)로 구현되었다. 그렇기에 DQA 벤치마크에는 총 602개의 데이터베이스가 존재한다.
- 평균적으로 Locating 시나리오의 데이터는 더 많은 행(row)을 포함하며, Building 시나리오는 상대적으로 작은 규모의 데이터베이스로 구성되었다.
이 벤치마크는 기존의 RAG(Retrieval-Augmented Generation) 방식이 의사결정 문제를 잘 해결하지 못하는 한계를 극복하기 위해 개발되었으며, 이를 평가하기 위한 새로운 RAG 기법인 PlanRAG가 도입되었다.
4 Methodology: PlanRAG
- 기존의 RAG 기법은 단일 또는 반복적인 데이터 검색을 통해 최적의 결정을 찾으려 하지만, 이 방식은 의사결정을 위한 분석 계획을 수립하는 능력이 부족하다.
- PlanRAG는 이를 보완하기 위해 (1) 계획 수립(Planning), (2) 데이터 검색 및 응답(Retrieving & Answering), (3) 재계획(Re-planning)의 세 단계를 포함하는 반복적인 계획-검색 증강 생성(iterative plan-then-retrieval augmented generation) 방식을 도입했다.
- 계획 수립(Planning)
- PlanRAG는 먼저 주어진 문제(Q), 데이터 스키마(S), 비즈니스 규칙(R)을 분석하여 의사결정을 위한 초기 분석 계획을 생성한다.
- 이 단계에서 어떤 데이터를 검색하고 어떤 방식으로 분석할지 결정한다.
- 데이터 검색 및 응답(Retrieving & Answering)
- 기존의 RAG 방식과 달리, PlanRAG는 초기 계획을 기반으로 데이터 검색 쿼리를 생성하여 더 효과적으로 필요한 정보를 검색한다.
- 검색된 데이터는 다시 분석되어 추가 검색이 필요한지 판단하고, 필요한 경우 검색을 반복한다.
- 재계획(Re-planning)
- 초기에 수립된 계획이 충분하지 않을 경우, PlanRAG는 검색된 데이터와 기존 계획을 분석하여 계획을 수정하거나 보완한다.
- 이를 통해 보다 체계적으로 데이터를 검색하고 의사결정을 내릴 수 있도록 한다.
- PlanRAG는 기존의 RAG 기법과 비교하여 더 정교하고 효과적인 의사결정 지원을 제공하며, Decision QA 문제를 해결하는 데 있어 높은 성능을 보였다.
- 특히, 반복적인 계획 수립과 데이터 검색을 결합하여 기존 방법보다 더 정확한 결정을 내릴 수 있도록 한다.
5 Experiments
5.1 Experimental Setup
다음과 같은 네 가지 유형의 LLM 기반 의사결정 시스템을 비교하였다:
- SingleRAG-LM: 기존의 단일 검색(Single-turn RAG) 기반 의사결정 모델
- IterRAG-LM: 반복적인 검색(Iterative RAG) 기반 의사결정 모델
- PlanRAG-LM: 제안된 PlanRAG 기법을 적용한 모델
- PlanRAG-LM w/o RP: PlanRAG에서 재계획(Re-planning) 기능을 제외한 모델
- 각 모델의 프롬프트는 ReAct(Yao et al., 2023) 기법을 기반으로 설계되었으며, 실험에 사용된 LLM은 GPT-4이다.
- 관계형 데이터베이스(RDBMS)와 그래프 데이터베이스(GDBMS)를 위해 MySQL과 Neo4j를 사용했다.
실험 환경
- Zero-shot 설정: 모델이 사전 학습된 데이터 없이 새로운 문제를 해결하도록 평가함.
- 실제 비즈니스 상황에서는 최적의 결정을 위한 전략을 알기가 어렵고, 실험에서 few-shot setting을 하면 예시에 overfit되는 것을 관찰했다고 한다.
- single run setting: 한 번의 실행 결과를 기반으로 비교 수행.
평가 기준
- 모델이 도출한 결정이 정답 데이터(ground-truth)와 의미적으로 동일한 경우 정답으로 간주함.
5.2 Results and Analysis
Main results
- PlanRAG가 가장 좋았다.
- Locating 시나리오에서 PlanRAG가 상대적으로 더 높은 성능 향상을 보였는데, 이는 Building 시나리오가 더 긴 탐색 과정(traversal)을 요구하고, 계획 수립이 어렵기 때문이다.
- Single-turn RAG(SingleRAG-LM)는 Building 시나리오에서 매우 낮은 성능(2.5%)을 기록했으며, 이는 복잡한 쿼리 생성을 단일 검색으로 해결하기 어려웠기 때문이다.
- PlanRAG에서 Re-planning 기능을 제거한 모델(PlanRAG-LM w/o RP)의 성능은 Locating에서 10.8%, Building에서 0.9% 감소했다.
- 재계획 과정이 PlanRAG의 의사결정 정확도를 높이는 데 중요한 역할을 한다는 점을 시사함.
Analysis for SR and MR
- DQA 데이터셋의 문제를 다음 두 가지 유형으로 나누어 비교했다.
- SR(Single Retrieval): 단 한 번의 데이터 검색으로 해결할 수 있는 문제
- MR(Multiple Retrieval): 여러 번의 데이터 검색이 필요한 문제
- SR과 MR의 기준은 IterRAG-LM에서 검색이 1번 실행되었는냐 여러번 실행되었느냐로 삼았다.
- PlanRAG는 SR 유형의 문제에서 IterRAG보다 성능 향상이 두드러졌다.
- IterRAG는 복잡한 문제를 단일 검색으로 해결하려는 경향이 있어, 어려운 문제를 과소평가하는 경우가 많음.
- 반면, PlanRAG는 계획 수립 단계에서 문제의 난이도를 미리 분석하고, 필요한 검색을 반복 수행함으로써 더 정확한 의사결정을 수행함.
- MR 유형에서도 PlanRAG가 IterRAG보다 성능이 우수했는데, 이는 PlanRAG가 체계적인 검색을 수행하는 반면, IterRAG는 검색 과정이 비효율적이기 때문이다.
Analysis for RDB and GDB
- PlanRAG는 RDB와 GDB 모두에서 기존 방법보다 높은 정확도를 기록했다.
- Building 시나리오에서는 GDB에서 상대적으로 높은 성능을 보였다.
- Building 시나리오는 Locating보다 데이터 간의 연결을 더 깊이 탐색해야 하므로, GDB에서 더 효과적으로 처리될 가능성이 큼.
Rate of missed data analysis
PlanRAG와 IterRAG가 데이터를 검색하는 과정에서 필수적인 데이터 분석을 누락하는 비율을 비교했다.
- PlanRAG의 누락 비율은 Locating 1.3%, Building 21.8%로 낮았고, IterRAG는 각각 3.3%, 33.2%였다.
- PlanRAG가 더 철저한 검색 및 분석을 수행했음을 의미함.
Analysis for failure cases
- CAN: 잘못된 후보를 고려하여 질문을 해결하지 못한 경우
- 예: 그림 1에서 Deccan의 목적지(dest)를 잘못 선택하고 이를 정답으로 도출한 경우
- MIS: 데이터 분석 누락(missed data analysis). 중요한 데이터 검색 실패
- DEEP: 검색된 데이터나 수식을 부적절하게 사용한 경우
- QUR: 쿼리 생성 오류(query generation error)
- OTH: 기타 오류 (예: 토큰 길이 제한 초과 등)
- 모델의 오류 유형을 분석한 결과, PlanRAG는 IterRAG 대비 주요 오류 유형을 효과적으로 줄였다.
- 특히, 잘못된 후보를 고려하여 문제를 해결하지 못하는 CAN 오류와, 데이터 분석을 누락하는 MIS 오류가 크게 감소했다.
- 반면, PlanRAG는 DEEP 오류(잘못된 데이터 사용 및 계산 오류)가 약간 증가했는데, 이는 CAN이나 MIS 오류를 감소시킨 것에 대한 부작용으로 볼 수 있다.
- PlanRAG에서 CAN과 MIS 오류 감소 → DEEP 오류 증가 이유
- PlanRAG는 계획 수립 및 재계획을 통해 데이터를 더 효과적으로 검색하고, 필요한 분석을 빠뜨리지 않도록 개선되었다.
→ 그 결과, CAN 오류(잘못된 후보 선택)와 MIS 오류(중요한 데이터 검색 실패)가 감소했다. - 하지만, PlanRAG가 복잡한 분석을 수행하면서, 가져온 데이터를 처리하는 과정에서 계산 오류(DEEP 오류)가 증가하는 부작용이 발생했다.
→ 즉, 필요한 데이터를 잘 가져오기는 하지만, 그 데이터를 활용하는 과정에서 실수를 할 가능성이 높아진 것.
- 기존 방법(IterRAG)은 아예 필요한 데이터를 못 찾아서 틀리는 경우(MIS 오류)가 많았고, 선택해야 할 대상을 잘못 선택하는 경우(CAN 오류)도 많았음.
- 하지만 PlanRAG는 필요한 데이터를 잘 찾고, 고려해야 할 대상을 정확히 선정함.
- 대신, 복잡한 데이터를 처리하는 과정에서 실수할 확률이 높아지면서, 계산 오류(DEEP 오류)가 증가한 것.
- PlanRAG는 계획 수립 및 재계획을 통해 데이터를 더 효과적으로 검색하고, 필요한 분석을 빠뜨리지 않도록 개선되었다.
Analysis for re-planning
- PlanRAG는 Locating 문제의 6%, Building 문제의 38%에서 re-planning을 수행했다.
- Building 시나리오에서 더 자주 re-planning이 발생했으며, 일부 문제는 4회 이상 re-planning을 수행했다.
- 이는 Building 시나리오에서 초기 계획을 수립하는 것이 Locating보다 어렵기 때문이다.
- re-planning을 수행할수록 정확도가 향상되었으나, 일정 횟수를 초과하면 성능 향상 효과가 줄어드는 경향을 보였다.
8 Limitations
1, GDB나 RDB에 대해서만 고려하였고 vectorDB에 대해서는 고려하지 않았음
2. Fine-tuning과 같은 low-level method는 고려하지 않고, RAG나 prompt tuning과 같은 high-level method만 고려하였음.
3. LLM 하나만 사용하는 single LM 상황만 고려하고 multiple LM framework에 대해서는 고려하지 않았음
