패스트캠퍼스 환급챌린지 39일차 : 테디노트의 RAG 비법노트 강의 후기

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

 

▶  RAG 개발 단계에서 우려해야할점

1. LLM이 생성한 답변이 Hallucination이 아닐까?
2. RAG를 적용하여 받은 답변이 문서에는 없는 '사전지식'으로 답변한 건 아닐까?
3. 문서 검색에서 원하는 내용이 없을 경우
   → 인터넷 혹은 논문에서 부족한 정보를 검색하여 내용을 보강할 수는 없을까?

 

이를 해결하기 위해 반복 검색하거나 Hallucination을 방지하는 LLM을 추가하면,

→ 코드가 점점 길어지고 복잡해짐

→ LLM의 일관되지 않은 답변이 마치 나비효과로 이어져 답변 품질저하로 이어짐

 

Hallucination은 사후방지보다 구조적 예방이 중요

• LLM 뒤에 Hallucination Checker를 붙이면 → 코드 복잡도 증가, 비용 증가, 판단 기준의 불안정성
• LangGraph는 '잘못된 흐름이면 다시 돌아가라'는 구조 자체를 제공
  → Hallucination을 결과가 아니라 과정에서 제어해야함. 

Conventional RAG 문제점

• 사전에 정의된 데이터 소싱(PDF, DB, Table 등) 자원
• 사전에 정의된 Fixed Size Chunk
• 사전에 정의된 Query 입력
• 사전에 정의된 검색 방법
• 신뢰하기 어려운 LLM 혹은 Agent
• 고정된 프롬프트 형식
• LLM의 답변 결과에 대한 문서와의 관련성/신뢰성

'Document Loader(데이터 로드) > Answer(답변)' RAG 파이프라인이 단방향 구조이기 때문에

→ 모든 단계를 한번에 다 잘해야 함

→ 이전 단계로 되돌아가기 어려움(이전 과정의 결과물을 수정하기 어려움)

LangGraph 제안

• 각 세부과정을 노드(Node)라고 정의
• 이전노드 > 다음노드 : 엣지(Edge) 연결
• 조건부 엣지를 통해 분기 처리

⇒ RAG 파이프라인을 보다 유연하게 설계

 

LangGraph

• Node(노드), Edge(엣지), State(상태관리)를 통해 LLM을 활용한 워크플로우에 순환(Cycle)연산 기능을 추가하여 손쉽게 흐름을 제어
• RAG 파이프라인의 세부 단계별 흐름제어가 가능
• Conditional Edge : 조건부(if, elif, else,,,etc.) 흐름 제어
• Human-in-the-loop : 필요시 중간 개입하여 다음 단계를 결정
• Checkpointer : 과거 실행 과정에 대한 '수정'&'리플레이' 기능

상태(State)

노드와 노드 간에 정보를 전달할 때 상태(State) 객체에 담아 전달

• TypedDict : 일반 파이썬 dict에 타입힌팅을 추가한 개념이지만, 쉽게 dictionary로 생각해도 됨
• 모든 값을 다 채우지 않아도 됨
• 새로운 노드에서 값을 덮어쓰기(Overwrite)방식으로 채움
• Reducer(add_messages 혹은 operator.add) : 자동으로 list에 메세지를 추가해 주는 기능

Reducer

• Reducer (add_messages 혹은 operator.add) : 자동을 list에 메세지를 추가해
  - 'left' (Messages) : 기본 메시지 리스트
  - 'right' (Messages) : 병합할 메세지 리스트 또는 단일 메세지

---

 오늘 학습한 내용은 RAG 개발 단계에서 반드시 고민해야 할 문제점들과 이를 구조적으로 해결하기 위한 LangGraph 입니다. RAG를 적용할때 가장 우려되는 부분은 '이 답변이 Hallucination은 아닐까?', '문서에 없는 사전 지식으로 답한 건 아닐까?' 입니다. 또한 문서 검색 결과가 부족할 경우, 외부 검색이나 추가 자료를 활용해 보완하는 방법에 대한 고민도 하게 됩니다.

 이 문제를 해결하기 위해 반복 검색이나 Hallucination 방지용 LLM을 덧붙이게 되면, 코드는 점점 길어지고 복잡해집니다. 더 큰 문제는 LLM의 판단이 일관되지 않아, 마치 나비효과처럼 이어져 전체 답변 품질이 오히려 저하될 수 있다는 것입니다. 결국 이는 개별 기법의 문제가 아니라 Conventional RAG 구조 자체의 한계라고 볼 수 있습니다. 기존 RAG는 사전에 정의된 데이터 소스, 고정되 Chunk 크기, 고정된 Query와 검색 방법, 고정된 프롬프트를 기반으로 단방향 파이프라인이기 때문에,  RAG의 모든 리스크가 최종 답변에 그대로 반영될 수밖에 없는 구조입니다. 이러한 문제에 대한 대안으로 제시된 것이 LangGraph 입니다. LangGraph는 RAG 파이프라인의 각 세부 과정을 노드로 정의하고, 노드 간의 흐름을 엣지로 연결합니다. 특히 조건부 엣지를 통해 조건문 형태의 분기 처리가 가능해지면서 RAG 파이프라인을 유연하게 설계할 수 있습니다.

 

 

 

 

커리어 성장을 위한 최고의 실무교육 아카데미 | 패스트캠퍼스