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

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

RAG를 처음 붙였을 때 대부분 잘 동작합니다. 임베딩을 하고, pgvector에 넣고, top-K를 찾아 LLM에 붙이면 꽤 그럴듯한 답이 돌아오죠. 그러다 이런 질문에서 막힙니다.

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

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

세 가지 RAG 세대

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

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

AICLUDE가 선택한 조합

1. 명제(Proposition) 단위 청킹

문서를 고정 길이로 자르는 대신, LLM에 5W1H 기준으로 원자적 명제를 추출하게 합니다. "프리미엄 플랜은 API 호출 무제한이다." "단, 초당 100회 rate limit이 있다." — 각 문장이 하나의 완결된 사실이 됩니다. 대규모 ingestion 비용은 있지만, 이후 단계의 품질이 극적으로 좋아집니다.

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

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

두 소스를 병렬로 검색합니다. SAM에서 유사도가 일정 임계값을 넘으면 LLM 호출 없이 저장된 답을 바로 반환하는 패스트패스가 발동합니다. 반복되는 질문은 거의 공짜로 답할 수 있다는 뜻입니다.

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

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

유사도 0.7 ~ 0.9  AND  공유 키워드 존재
        ↓
knowledge_links 테이블에 양방향 'related' 링크 저장

• 유사도 > 0.9는 중복으로 간주해 제외.
• 유사도 < 0.7은 무관으로 간주해 제외.
• 키워드 교집합으로 노이즈 링크 추가 제거.

검색 시에는 재귀 CTE로 최대 3-hop 까지 확장하고, 홉마다 0.7의 decay를 곱해 점수를 감쇠시킵니다. Neo4j 같은 별도 그래프 DB 없이, PostgreSQL 한 곳에서 Graph RAG의 핵심 효과를 냅니다.

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

검색 결과로 coverageLevel(none / low / medium / high) 을 계산합니다. high가 아니고 질문이 실시간·사실·뉴스성이라면, 자동으로 웹 검색 도구를 호출해 컨텍스트를 보강합니다. "RAG가 부족한지 아닌지"를 LLM에 또 물을 필요 없이 규칙으로 판단합니다.

5. 3단계 Self-Evaluation

Quick Verification  →  즉시 재생성 (동기)
    ↓
Deep Verify         →  다차원 점수 + DB 기록 (비동기)
    ↓
Cross-turn Correction → 다음 턴 시스템 프롬프트에 자동 주입

• Quick Verification: 답이 나오자마자 경량 LLM이 재검토해, 틀리면 correction_prompt를 끼워 그 자리에서 재생성.
• Deep Verify: 스트리밍 후 fire-and-forget으로 페르소나 일치도, 사실성, 도구 결과 반영, 안전성을 채점.
• Cross-turn Correction: Deep Verify의 지적을 다음 턴 시스템 프롬프트에 자동 주입 — 턴을 넘어가는 자기 교정 루프.

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

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

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

"500 에러 해결 방법은?"

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

마케팅 수사에 주의 — 무엇을 어느 정도 구현했는가

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

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

AICLUDE는 후자입니다. 전자는 구축 비용이 크고 오류 전파가 심해 아직 도입하지 않았습니다. 대신 명제 청킹 + 청크 링크 + N-hop 확장으로 전자가 얻으려는 효과의 실용적인 부분을 얻고 있습니다. 멀티홉 사실 체인 추적이 필요한 극단적인 케이스에서는 추가 레이어가 필요할 수 있고, 이는 향후 확장 영역으로 열어 두고 있습니다.

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