◾Intro

🔻references

◾Main

🔻LangGraph의 등장배경

🔸Conventional RA점

1. 기존의 Hallucination 문제는 지속적
2. RAG를 적용한 답변이 실제 질문과 관계없이 RAG에 있는 ‘사전지식’만으로 답변한 것은 아닐까
3. RAG 문서에 없는 내용을 인터넷 혹은 논문 탐색을 통해 지식 보강할 순 없을까

• e.g.) 검은색 문장처럼 질문하고 파란색 문서를 참고하여 답변을 낸 상황

• Conventional RAG의 문제점

  

  • Conventional RAG의 pipeline
    1. Load : 데이터를 load
    2. Split : load한 데이터를 ‘chunk’ 단위로 분할 → fixed size chunk
    3. Embed : chunk를 embed
    4. Storage : embedding vector를 vector DB에 저장
    5. Question & Retreive : 사용자의 질문을 vector DB에서 검색 → 단, 이 검색 방법조차도 미리 정의해야 한다.
    6. Prompt : 검색 결과를 prompt에 반영 → 이 prompt가 고정된 형식

  ⇒ 결국 Conventional RAG pipeline이 단방향 구조이기 때문에 발생하는 문제점들이다.

🔸LangGraph의 제안

• Node : Conventional RAG pipeline의 각 과정들을 “Node”라고 정의 → 어떤 작업을 수행할지 정의
• Edge : Node 사이의 연결선 → 다음으로 실행할 동작(node)을 정의
• State : Node와 Node 사이에서 전달되는 정보들 → dictionary 형태의 데이터 (현재의 상태 값을 저장 및 전달)
• Cycle 연산 기능 : edge를 사용하여 과거의 워크플로우로 돌아갈 수 있게 해주는 기능
• Human-in-the-loop : 필요시 사람의 판단에 따라 conditional edge의 판단을 무시하고 다음 단계를 결정하는 방법

⇒ “Conditional Egde”를 통해 상황별 분기 처리 → RAG pipeline에 유연성을 더함.

• Query Transform 방법 예시

  

  • RAG의 문서 검색이 올바르지 않은 경우 평가자 edge를 통해 다시 question 단계로 돌아갈 수 있는데 이 때 question이 똑같으면 결과가 같으므로 question에 변화를 주는 방법이다.