본문으로 건너뛰기
엔지니어링

Agentic RAG로 가는 길: Classic RAG가 충분하지 않았던 이유

AICLUDE Engineering

검색은 잘 되는데 답은 왜 어긋날까

RAG를 처음 붙였을 때는 대개 잘 돌아갑니다. 임베딩해서 벡터 DB에 넣고 top-K를 찾아 LLM에 넘기면 그럴듯한 답이 나오죠. 그러다 이런 질문에서 막힙니다.

  • "우리 회사 환불 정책을 전부 알려줘." — 정책이 여러 문서에 흩어져 있어서 top-K로는 일부만 답합니다.
  • "프리미엄 플랜 무제한이면 rate limit은 없나요?" — 질문의 단어와 직접 매칭되는 청크에 rate limit 문장이 없습니다.
  • "스탠다드랑 프리미엄 차이가 뭐야?" — top-K에 두 플랜 설명이 같이 들어오지 않습니다.
  • "500 에러 어떻게 해결해?" — 증상 → 원인 → 해결책 체인을 한 청크가 담고 있지 않습니다.

이것이 Classic RAG의 한계입니다. 단일 홉 검색은 "질문과 가장 비슷한 청크 한 묶음"만 가져올 뿐, 관련된 주변 사실이나 반대편 케이스를 끌어오지 못합니다.

세 가지 RAG 세대

세대방식강점약점
Classic RAGQuery → Embed → Vector DB → Top-K → LLM빠름, 단순단일 홉, 분산 정보에 약함
Graph RAGQuery → Entity/Relation Graph → Connected Context → LLM관계 추론 가능그래프 구축 비용, 오류 전파
Agentic RAGReasoning Agent가 여러 소스와 도구를 자율 선택 → Self-Evaluation적응형, 자기 교정설계·검증 체계가 필수

AICLUDE는 이 흐름을 "제품 한 덩어리"로 구현하는 방향을 선택했습니다. 각 세대의 장점을 따로 쓰는 것이 아니라, 같은 파이프라인 안에 겹쳐 두는 접근입니다.

AICLUDE가 선택한 조합

1. 명제(Proposition) 단위 청킹

문서를 고정 길이로 자르지 않고 내용을 명제 단위로 다시 정리합니다. "프리미엄 플랜은 API 호출 무제한이다." "단, 초당 100회 rate limit이 있다." 이렇게 하면 문장 하나하나가 그 자체로 완결된 사실이 됩니다. 문서를 넣을 때 할 일은 늘지만 그 뒤의 검색과 답변 품질은 눈에 띄게 좋아집니다.

2. 이중 지식베이스 (SAM + RAG)

유형내용용도
SAMQ&A 쌍 기억이전에 정확히 답한 질문을 즉시 재사용
RAG문서 청크새로운 질문의 근거 검색

두 곳에서 함께 찾습니다. 이전에 답한 질문과 아주 비슷한 질문이 들어오면 LLM을 거치지 않고 SAM에 저장해 둔 답을 바로 돌려줍니다. 반복되는 질문에는 거의 공짜로 답하는 셈이죠.

3. 청크 링크 그래프 + N-hop 확장

전통적인 Knowledge Graph(엔터티-관계 트리플)를 만들지 않고, 청크 사이의 의미적 유사도와 공유 키워드로 자동 링크를 만듭니다.

사실상 같은 뜻의 중복 내용이나 관계가 약한 내용은 잇지 않습니다. 그래서 링크가 많아져도 관계없는 내용이 섞여 들어오는 일이 적습니다.

검색할 때는 먼저 찾은 내용에서 링크를 몇 단계 따라가 관련 내용까지 함께 가져옵니다. 멀리 이어진 내용일수록 비중을 낮춰 질문의 초점이 흐려지지 않게 합니다. 그래프 전용 시스템을 따로 설치하거나 운영하지 않고도 Graph RAG의 핵심 효과를 얻습니다.

4. Adaptive RAG — 스스로 부족함을 판단

검색 결과가 질문에 답하기에 충분한지 먼저 가늠합니다. 근거가 모자라고 질문이 실시간 정보나 사실, 뉴스를 묻는다면 웹 검색 도구를 자동으로 불러 근거를 보탭니다.

5. 3단계 Self-Evaluation

답 하나를 세 단계에 걸쳐 확인합니다.

  • Quick Verification: 답이 나오자마자 경량 LLM이 한 번 더 살펴보고 틀린 곳이 있으면 고칠 점을 반영해 그 자리에서 다시 생성합니다.
  • Deep Verify: 답을 보낸 뒤 페르소나 일치도, 사실성, 도구 결과 반영, 안전성을 따로 채점합니다. 사용자는 이 채점을 기다리지 않습니다.
  • Cross-turn Correction: Deep Verify가 짚은 점을 다음 대답부터 자동으로 반영합니다. 턴을 넘나드는 자기 교정 루프인 셈이죠.

Classic vs. AICLUDE에서 답이 달라지는 예

"스탠다드 플랜과 프리미엄 플랜 차이가 뭐야?"

  • Classic: top-K에 스탠다드 설명만 들어와 반쪽 답변이 나옵니다.
  • AICLUDE: 스탠다드 청크를 찾고, 링크를 따라 프리미엄 청크까지 hop 확장. 양쪽 플랜을 같이 비교하는 답이 나옵니다.

"500 에러 해결 방법은?"

  • Classic: "500은 서버 내부 오류" 청크 하나만 반환합니다.
  • AICLUDE: "500 에러" → "DB 커넥션 풀 초과" → "최대 연결 수 조정"의 2-hop 체인을 따라 증상·원인·해결책을 한 번에 답합니다.

같은 "Graph RAG"라도 방식은 다릅니다

"Graph RAG"라는 단어는 두 가지로 쓰입니다.

  • 엔터티-관계 기반 Knowledge Graph: 사람·조직·개념 단위로 관계를 추출해 그래프로 저장.
  • 청크 링크 기반 그래프: 벡터 유사도와 키워드로 자동 링크.

AICLUDE는 후자를 택했습니다. 전자는 구축 비용이 크고 잘못 뽑은 관계 하나가 뒤따르는 답변으로 번지기 쉽기 때문입니다. 후자는 엔터티와 관계를 미리 설계하고 관리할 필요 없이 문서를 올리면 관련 내용끼리 자동으로 이어집니다. 여기에 명제 단위 청킹과 N-hop 확장을 더해 여러 문서에 흩어진 사실을 함께 찾아 답합니다.

검색 품질이 답변 품질을 결정하고, 검증 루프가 답변 품질을 보장합니다. AICLUDE RAG는 이 두 축을 같은 제품 안에 묶는 방식으로 설계되어 있습니다.


블로그 목록으로

aiclude.com은 방문 통계를 내기 위해 Google Analytics 쿠키를 씁니다. 동의하면 방문한 페이지와 시각, 브라우저·기기 종류, IP 주소가 Google(미국)로 전송됩니다. 동의하지 않아도 웹사이트는 그대로 이용할 수 있고, 선택은 아래쪽 쿠키 설정에서 언제든 바꿀 수 있습니다. 쿠키 정책