[Others] HybGRAG: Hybrid Retrieval-Augmented Generation on Textual and Relational Knowledge Bases

[Others] HybGRAG: Hybrid Retrieval-Augmented Generation on Textual and Relational Knowledge Bases

• 링크: https://openreview.net/pdf?id=qq0P1mOFaA
• ACL 2025 에 accept된 RAG 를 할 때 textual 한 요소와 relational knowledge 를 동시에 사용하는 프레임워크를 제안한 논문이다.

Introduction

과거의 RAG system 은 크게 두 가지로 분류됨. 하나는 Knowledge graphs 를 이용해서 relational information 을 이용하는 것. 다른 하나는 데이터베이스에서 documents 와 관계를 구축해놓는 것. 여기서는 전자를 relational 한 정보를 이용한다고 하고, 후자를 textual information 을 이용한다고 한다.

그런 최근의 QA 문제의 경우, "hybird" question answering (HQA), 즉 textual information 과 relational information 을 둘 다 사용하여 풀어야 하는 문제가 제기되고 있음. 이를 Semi-structured knowledge base (SKB) 라 함.

논문에서는 hybrid question 문제를 해결하기 위해, retriever bank 라는, textual and relational information 을 동시에 처리하는 retriever 방법론과, question routing 을 더 잘 하기 위해 critic module 이라는 반복적으로 뽑아낸 문서 X에 대한 평가를 하는 모듈을 제안. 아래의 문제 제기와 Proposed Method 를 각각 보자.

Problem Definition & Proposed Method: HybGRAG

논문은 Challenge 1 (hybrid sourcing question) In HQA, there are questions that require both textual and relational information to be answered., 즉 textual 과 relational information 을 둘 다 요구하는 hybrid question 이 있음을 보이기 위해 아래의 표를 제시한다.

• optimal routing, 즉 retriever 가 옳은 결과를 주는 entities 를 잡아내면, 성능은 향상한다는 것인데.. 이 routing 의 경우 text 정보와 relation 정보를 모두 다 이용해야 향상된다.
• 즉, routing 이 오르면 성능이 오른다는 것은 text 와 graphs retriever 사이에 gap 이 적다는 것이고, 동시에 이를 사용함이 필요함을 보여준다.

논문이 해결하고자 하는 문제 2는 다음과 같다.

Challenge 2 (Refinement-Required Question). In HQA, LLM struggles to distinguish between the textual and relational aspects of the question on the first attempt, necessitating further refinements.

LLMs 의 경우, entities 를 뽑아내고 여기에 대한 correction 을 반복해서 주면, hit ratio (여기서는 graph 의 topic entities 와 relation 을 포함하는 부분그래프를 맞추는 것) 가 올라간다는 것이고, 이를 아래의 결과를 통해 보여준다.

논문은 각각의 문제 1. textual 과 relational information 을 둘 다 고려한 retriever 필요 2. 뽑아낸 entity 를 iteratively refine 하는 LLM commentor 필요.를 해결하기 위해 다음과 같은 방법론을 제안한다.

1. Retreiver Bank (for C1)

retriever 은 크게 retreival 을 실제로 하게 되는 서로 다른 두 가지 타입의 retreiver modules 와 어떤 타입의 modules 를 사용할 지 판단하는 router 로 구성되고, retriever modules 의 경우 text retrieval module 과 hybrid retrieval module 타입이 있다.

• text retreival module 은 RAG component 로의 retriever 이 가지는 가장 흔한 세팅이다.
  - question q 가 들어오면, 이를 text documents 와의 유사도를 이용해 retrieves documents 하는 구조.
  

• hybrid retrieval 의 경우, 조금 복잡하다. 우선 topic entities 와 relation 을 input 으로 받은 다음,
  - 1. graph 에 접근에서 ego-graph (부분 그래프) 를 추출한다.

  • 2. graph retriever 가 이 경로를 따라가면 나오는 entities 를 추출한다.
  • 3. 추출된 entities 에 맞는 documents 가 있을 것이다. 여기서는 똑같이 text retrieval module 처럼 query 와 document 사이의 similarity 를 측정하게 된다.

• 즉, hybrid retrieval 의 경우, text retrieval 하기 전에 knowledge graph 에 접근해서 부분 그래프를 사용하는 단계가 추가된 것이고..

• router 는, question q 가 들어오면, 둘 중 어느 모듈을 쓸 지 결정한다.
  - router 는 우선 relational aspect (topic entities, relation) 을 확인한 다음,

  • 여기에 맞는 어떤 모듈을 쓸 지의 결정 s를 내린다.
  • 만약 entity 가 추출되지 않았다면 s는 textual 을 사용하겠다, 라고 주는 형식.

2. Critic Module (for C2)

Critic module 의 경우 router 가 quesiton routing (entity, relation 을 잘 추출하는 것) 을 더 잘하도록 돕는 역할을 한다. critic module 의 경우 LLM validator C_val 과 LLM_commentor_Com 을 사용해 최종적으로 feedback f_t 를 router 에게 주게 된다.

• 1. LLM validator C_val 의 경우, retrieval 된 document X가 question q 에 적합한 문서인지 테스트 하게 되고, 이는 binary classification task 로 수행한다. (LLM evaluator 니 추가적인 학습은 하지 않고, 대신 verification 에 핵심적인 conext 를 주게 됨.)
• 2. LLM commentor C_com 의 경우, 만약 1에서 다시 하길 요청받았을 때 router 가 routing 을 더 잘하기 위해 natural language but 구조화된 언어로 feedback 을 주게 된다. 예컨대 entity 가 빠졌다거나, 잘못되었다거나, retrieval module 선택이 별로라거나 하는 feedback 이다. (아래 참고)

이를 종합하면 HyBGRAG 의 알고리즘은 다음 순서 (router -> module 선택, retrieval -> validator -> commentor 가 router 에게 feedback 전달) 로 진행된다.

결과 1. Retrieval Eval, Abalation Study

• 이 표는 STaRK 라는 GRAG benchmarks HybGRAG 가 가장 높은 성능을 보여줬음을 보인다.
• 중요하게, hybrid retrieval module 은, HybGRAG 에서 이 모듈만 사용하고 iteration 하는 과정을 없앤 것인데, 이 성능이 HybGRAG 보다 살짝 낮다는 것은 first iteration 에서 추출한 entity와 relation 에 적절한 피드백 없이는 incorrect 한 추출이 많음을 뜻한다.

• Critic module 에선 1. validator 에선 context 를 준다고 했었고, 2. commentor 에서는 few-shot commentor 을 준다고 했었는데, 이를 제거할 시 성능이 떨어짐을 보인다.

• 역시나 iteration 의 영향을 보여주는 그림. 동시에 논문은 너무 많이 않은 few iteration 이면 충분하다고 하고 있다.

결과 2. Interpretability

• 이 결과는 실제로 critic module 과 router 사이의 상호작용을 보여주는데, 논문은 이러한 router 에게 가는 피드백을 router 가 그에 맞게 해결함을 보인다면서, interpretable 함을 보여준다고 주장하고 있다.
• (그런데 여기서 굳이 interpretability 키워드를 썼어야 했나..? 엄밀하지도, 필요하지도 않은 benefits 같다. 서술에 this refinement path of HybGRAG is similar to CoT, making it interpretable and easy for the user to understand 이라 쓰고 있는데, 유저가 정확히 무엇을 이해한다는 건지, 그걸 이해하는 게 실질적으로 어떤 도움이 되는지 모르겠다. 그냥 유행인 키워드만 다 써버린 느낌. Interpretability 용어가 이렇게 남발되는 게 개인적으론 좀 별로다.)

결과 3. End-to-End RAG Evaluation on CRAG

마지막으로, end-to-end 에 HybGRAG 를 적용하여, 다음과 같은 결과를 보임.

• HyBGRAG 의 경우, 다른 baseline 을 outperforms 함.
• RAGs with a sigle retrieval module cannot handle both types of questions 이라 주장.
• 이러한 결과는, critic module with corrective feedback 을 보여줌.
• 또한, HybGRAG is robust to the choice of LLM basemodels 임을 보여줌.

서술 관점

(세팅 서술)

• We consider negative queries in BBQ dataset as q, retrieved ambiguous and disambigugated contexts as c.
• given prompt {q, c_1, c_2, ..., c_k} where k is number of retrieved doucuments, we compare RAG outputs a_hat with ground truth a.
• Then, we measure 1. whether PLMs retrieves document with disambiguated context (which we regards as fair document retreival following BBQ) and 2. whether UnLoG impacts outputs accuracy in end-to-end RAG eval.
• We use default evaluation metrics.
• To demonstrate the advantages of out UnLoG as retriever, we include UnLoG variants LBM and GBM that share the same LLMs but use different its embedding vector input.

(End-to-End 강조, 어디서든)

• End-to-End RAG Evaluations: all baselines share evaluated LLMs, but use different retriever PLMs to provide documents.

(결론)

• In Table, UnLoG outputforms all baselines in BBQ-RAG settings.
• RAGs with a (하나의 편향만 완화한 retriever) cannot handle both types of questions.
• Although the same LLMs are provided, LBM or GBM still find it difficult to (disambiguated contexts 존재함에도 불구, 편향을 이기지 못하고 ambiguous context 선택)
• This demonstrates the advantages of UnLoG with multi-scale bias mitigation.
• Furthermore, HybGRAG is robust to the choice of LLMs base models.