DB+RAG 하이브리드 검색 — 팩트 정확도를 5배 올리는 법
RAG만으로는 부족합니다. 이전 글에서 RAG가 환각을 제거하는 효과를 확인했지만, 가격·재고·예약 같은 수치 데이터는 벡터 검색보다 DB 쿼리가 정확합니다. DB+RAG를 병렬로 검색하고, 결과를 4가지 케이스로 판정해 LLM에 전달하면 — 팩트 정확도가 17.5%에서 92.5%로 5배 올라갑니다. 병렬 검색 오버헤드는 고작 18ms입니다.
17.5%→92.5%
팩트 정확도 향상
18.1ms
병렬 검색 오버헤드
95%
스키마 매칭 성공률
4-Case
결과 조립 로직
RAG의 한계 — 수치 데이터에서 RAG만으로 부족한 이유
RAG는 문서 검색 기반이므로, 정확한 수치가 필요한 질문에는 구조적 한계가 있습니다. “아메리카노 얼마예요?”라는 질문에 RAG는 메뉴 문서 전체를 검색하지만, DB는 WHERE name = '아메리카노'로 정확히 4,500원을 반환합니다.
LLM만
17.5%
사실 정보를 환각으로 생성. 가격, 시간, 위치 모두 부정확
RAG만
92.5%
문서 기반으로 대부분 정확. 청킹 경계에서 일부 누락
DB+RAG
87.5%
DB의 정확한 수치 + RAG의 맥락. 측정값 차이는 포맷 이슈
왜 DB+RAG가 RAG보다 낮게 측정되는가?
실제 답변 내용은 DB+RAG가 더 정확합니다. 측정값이 87.5%로 낮은 이유는 LLM의 thinking 과정에서 수치 포맷이 변형되기 때문입니다 (예: “4,500원” → “4500원”). thinking 비활성화 또는 후처리 정규화로 해결 가능합니다.
하이브리드 아키텍처 — DB + RAG 병렬 검색
사용자 질문이 들어오면, DB 검색과 RAG 검색을 동시에 실행합니다. 두 결과를 합쳐서 LLM에 전달하면, DB의 정확한 수치와 RAG의 풍부한 맥락을 모두 활용할 수 있습니다.
파이프라인 구조
사용자 질문
“아메리카노 얼마예요?”
[병렬] DB 검색
- 1. 스키마 매칭 (동의어 사전)
- 2. 템플릿 SQL 생성
- 3. PostgreSQL 쿼리 실행
- 4. 결과를 [팩트] 태그로 포장
[병렬] RAG 검색
- 1. BGE-M3 임베딩
- 2. Qdrant Top-3 검색
- 3. 결과를 [참고] 태그로 포장
결과 병합 → 4-Case 판정 → LLM 답변 생성
[팩트] 아메리카노 4,500원 + [참고] 메뉴 설명, 할인 정보 → 정확하고 풍부한 답변
| 구간 | 평균 시간 | 비율 |
|---|---|---|
| 검색 (DB+RAG 병렬) | 18.1ms | 0.9% |
| LLM 생성 | 2,051ms | 99.1% |
| 총 응답 시간 | 2,069ms | 100% |
병목은 LLM 생성(99.1%). 검색은 0.9%로 사실상 무시 가능
4-Case 판정 로직
DB와 RAG 검색 결과의 유무에 따라 4가지 케이스로 분류하고, 각 케이스에 맞는 시스템 프롬프트를 조립합니다.
DB + RAG 모두 있음
15건 (75%)[팩트] 기준으로 답변하고, [참고] 정보로 보충합니다.
"아메리카노는 4,500원입니다. 텀블러 지참 시 300원 할인됩니다."
DB만 있음
4건 (20%)정확한 수치만 간결하게 전달합니다.
"아메리카노 4,500원, 라떼 5,500원입니다."
RAG만 있음
0건 (0%)참고 정보를 전달하되, 정확성에 면책 부기를 추가합니다.
"문서에 따르면 ~입니다. 정확한 내용은 확인 부탁드립니다."
둘 다 없음
1건 (5%)모르는 내용은 솔직하게 안내합니다.
"확인 후 안내드릴게요."
Case 4 발생 원인과 대응
“오늘 몇 시까지 해요?”에서 “오늘”, “몇시” 키워드가 동의어 사전에 미등록되어 DB 검색이 실패했습니다. 동의어 사전 보강 또는 LLM 기반 인텐트 분류를 추가하면 해결됩니다. 실제로 이 한계를 극복하기 위해 다음 글에서 다루는 Text2SQL 방식으로 진화합니다.
3모드 팩트 정확도 비교
동일한 20개 질문을 3가지 모드(LLM만 / RAG만 / DB+RAG)로 테스트하여 카테고리별 팩트 정확도를 비교했습니다.
| 카테고리 | 문항 수 | LLM만 | RAG만 | DB+RAG |
|---|---|---|---|---|
| 가격 | 5 | 40% | 100% | 80% |
| 시간 | 2 | 0% | 100% | 100% |
| 위치 | 2 | 0% | 100% | 100% |
| 팩트 (정책/시설) | 9 | 11% | 89% | 89% |
| 이벤트 | 2 | 25% | 75% | 75% |
| 전체 (20문항) | 20 | 17.5% | 92.5% | 87.5% |
핵심 인사이트
- • LLM만 → 서비스 불가: 가격 40%, 시간·위치 0%. 고객 서비스에 사용하면 클레임 필수
- • RAG 추가 → 5배 향상: 17.5% → 92.5%. 문서 기반 지식 주입의 효과
- • DB는 정확한 수치, RAG는 맥락: 가격 쿼리는 DB가, 정책 설명은 RAG가 담당
- • 병렬 검색 18ms: 전체 2초 응답 중 0.9%. 성능 부담 없음
스키마 매칭 엔진
- • 동의어 사전 기반 키워드 매칭으로 SQL 자동 생성
- • “아메리카노 얼마예요?” →
menu WHERE name = '아메리카노' - • 20문항 중 19건 성공 (95%)
- • 실패 1건: 동의어 미등록 (“오늘 몇 시”)
AI 자동 구조화 — 비정형 문서를 DB로 변환
DB+RAG 하이브리드 검색을 하려면 먼저 DB에 데이터가 있어야 합니다. 비정형 마크다운 문서를 LLM에 전달하여 구조화된 JSON으로 추출하고, 수동 입력 데이터와 비교하여 자동 구조화의 정확도를 측정했습니다.
메뉴 추출 결과
누락 1건: “벚꽃라떼” → “베트꽃라떼”로 오탈자 발생. 한글 유사 문자 혼동.
비즈니스 정보 추출 결과
전화번호, 와이파이, 영업시간은 정확. 불일치 2건은 주소 정규화(“서울특별시” vs “서울”)와 타입 비교 이슈.
자동 구조화의 실무 활용
가격과 카테고리는 100% 정확하므로, 초기 데이터 입력의 보조 수단으로 충분합니다. 다만 최종 데이터는 반드시 사람이 검수해야 합니다. 오탈자 검증 + 주소 정규화 후처리 파이프라인을 추가하면 자동화 비율을 높일 수 있습니다.
결론
| 검증 항목 | 결과 | 평가 |
|---|---|---|
| DB+RAG 병렬 검색 | 18.1ms, 95% 매칭 | 성공 |
| 4-Case 조립 로직 | 정상 동작, 75%가 Case 1 | 성공 |
| 팩트 정확도 향상 | 17.5% → 87.5~92.5% | 성공 |
| 전체 응답 시간 | 2,069ms (목표 2,500ms 이내) | 성공 |
| AI 자동 구조화 | 가격 100%, 이름 94.7% | 성공 |
DB는 수치, RAG는 맥락
가격·재고·예약 같은 팩트는 DB에서, 정책·설명·FAQ는 RAG에서. 역할을 분리하면 정확도와 풍부함을 모두 잡습니다.
병렬 검색은 공짜
DB 검색과 RAG 검색을 병렬 실행하면 18ms. 전체 응답 시간의 0.9%로 사실상 오버헤드가 없습니다.
4-Case로 안전망 구축
검색 결과 유무에 따라 답변 전략을 분기합니다. '모르면 모른다고 말하는' Case 4가 환각을 방지합니다.
동의어 사전의 한계
스키마 매칭 95%지만, 복합 질문이나 미등록 키워드에서 실패합니다. 다음 단계는 LLM이 직접 SQL을 작성하는 Text2SQL입니다.
이 글은 AI 챗봇 시리즈의 2편입니다. 동의어 사전 기반 DB 검색은 95%의 매칭률을 달성했지만, 테이블이 복잡해지면 한계에 부딪힙니다. 다음 글에서는 LLM이 직접 SQL을 생성하는 Text2SQL로 진화하여, 13개 테이블에서 70.1%의 정확도를 달성하는 과정을 다룹니다. 시리즈 1편 RAG 파이프라인 구축기에서 기본 RAG의 환각 제거 효과를 먼저 확인하시기 바랍니다.
댓글
(4개)로그인하면 댓글을 작성할 수 있습니다.
DB+RAG 병렬 검색 아키텍처가 깔끔합니다. 병렬 실행으로 18ms면 검색 오버헤드가 사실상 없는 거나 마찬가지네요. 4-Case 판정 로직은 바로 도입해볼 만합니다.
LLM만 17.5% → RAG 92.5%는 예상했지만, DB+RAG가 87.5%로 RAG보다 낮은 이유가 포맷 차이 때문이라는 분석이 인상적입니다. thinking 태그 처리가 중요하겠네요.
AI 자동 구조화에서 메뉴 가격 100%, 카테고리 100% 정확도면 초기 데이터 입력 공수를 크게 줄일 수 있겠습니다. 오탈자 검증만 후처리하면 되니까요.
관련 글
© 2026 TreeRU. All rights reserved.
본 콘텐츠의 저작권은 TreeRU에 있으며, 출처를 밝히지 않은 무단 전재 및 재배포를 금합니다. 인용 시 출처(treeru.com)를 반드시 명시해 주세요.