[LLM] Seven Failure Points When Engineering a Retrieval AugmentedGeneration System

 RAG의 Failuer Points에 대해서 정리한 논문이 있어서 참고 겸 공부 겸 정리하고자 한다.

https://arxiv.org/abs/2401.05856

Seven Failure Points When Engineering a Retrieval Augmented Generation System

Failure Points of RAG Systems

• FP1 Missing Content
  •  Information Retrieval에 실패한 경우를 의미
  • Retrived Information이 없는 경우에 대답을 하는 Hallucination이 발생할 수 있음
• FP2 Missed Top Ranked Documents 
  • Retrived를 성공시켰지만 필요한 정보의 Rank가 Retrived된 정보들 중 높지 않아서 user의 대답 생성에 쓰이지 않은 경우를 의미한다.
• FP3 Not in context - consolidation strategy limitations
  • 추출된 여러개의 Docs를 합치는 과정에서 대답에 필요한 정보가 Hindered됨으로써 필요한 정보가 Answer generation에 쓰이는 경우를 의미한다.
• FP4 Not Extracted
  • Prompt로 필요한 정보가 들어갔지만 LLM이 대답을 생성해내는 과정에서 누락이 되는 경우를 의미한다.
• FP5 Wrong Format
  • 사용자가 특정 정보를 특정 형식으로 출력하기를 원하지만 이에 대한 Format을 맞추는데 실패한 경우를 의미한다.
• FP6 Incorrect Specificity
  • 대답의 세밀함이 부족하거나 과한 경우를 의미한다.
  • 즉, 사용자가 원하는 수준의 디테일을 못 챙기거나 TMI로 LLM이 대답을 형성하는 경우를 의미한다.
• FP7 Incomplete
  • 사용자의 질문에 대해서 어느정도 필요한 정보를 가지고 있지만 충분한 데이터를 가지지 못하는 경우를 의미한다.

Case Study to takeaways Failure Points

• FP1
  • 자주하는 질문에 대한 Sementic caching을 통해서 여러 유저가 접근할 때의 overhead를 줄임과 동시에 FP1의 Failuer Point를 완화시킬 수 있을 것이다.
• FP1, FP2
  
  • Chunk Size, Embedding 방식, Chunking 방식, Retrieval 방식, 정보 통합 방식, Context크기, Prompt등 RAG시스템의 Config에 대한 조정이 필요하다.
• FP2, FP4
  • FP2와 FP4의 실패원인은 Retrieval Model의 부족함으로 기인된 것이 많다.
  • 이를 타개하기 위해서 논문에서는 다음과 같은 방법을 제안한다.
    • Retrived Data의 메타정보를 Context로 추가한다.
    • Embedding Model을 Open-source까지 충분히 고려하여 최적의 모델을 찾는다.
    • 모든 항목들에 대해서 개별적으로 운영되는 경우 통합하였을 때 성능이 안 나올 수 있다. 따라서 전체를 통합해서 LLM에 대한 FineTuning을 진행하는 것도 하나의 전략이 될 수 있다.
• FP4
  
  • Context를 늘리는 것이 이에 대한 해결책이 될 수 있다.
  • 하지만 LLM이 Long-context에 대해서 취약하다면 해당 사항은 해결책이 될 수 없다고 생각한다.(내 생각)
• FP2 ~ FP7
  • 시스템을 만들어도 실제 런타임에서 어떻게 동작하는지 검사를 해야한다. 이러한 과정에서 생긴 Feedback으로 앞써 말한 최적화 과정을 거쳐야한다.
  • 이러한 Feedback을 위해서는 input에 대한 모니터링 시스템을 구축할 필요가 있다.
• FP 5 ~ 7
  • JailBreak를 시도하는 Input에 대해서는 RAG System을 bypass시킬 수 있어야한다.

 

이 논문의 의의는 RAG시스템의 Failuer Point에 대해서 정의하고 각각 문제에 대해서 어떻게 바라볼지 접근법을 제안한 것에 그 의의가 있다. 실제로 RAG시스템을 개발하다보면 PoC수준의 개발과 실제 Enterprise사이의 간극이 상당히 크다는 것을 알 수 있다. 그렇기에 이러한 Failure Point를 알고 내가 만든 시스템 구조도에서 각각 어느 포인트에서 Fail이 생길지 위의 논문을 참고해서 정의하고 해결해나간다면 많은 시간을 절약할 수 있다고 생각이 든다.