본문바로가기
Hybrid RAG
Vector + BM25 Search Engine
Hybrid RAG
Vector + BM25 Search Engine
Hybrid RAG
Hybrid RAG System
사내 문서를 AI가 정확히 찾아 답변하는 하이브리드(Vector+BM25+Graph) 검색 + 문서 전처리 시스템
  • PostgreSQL 17
  • VectorChord
  • BM25
  • Graph Search
  • FastAPI
  • LangGraph
  • FlashRank
  • OCR-LLM
  • Project
    Hybrid RAG System
  • Period
    2026.04 (6주)
  • Type
    Search Engine / RAG Backend
  • Role
    아키텍처 설계 및 백엔드 개발
고객사
싸이버로지텍
프로젝트 유형
RAG Backend / Hybrid Search + 문서 전처리
기술 스택
PostgreSQL 17, VectorChord, BM25, Graph Search, FastAPI, LangGraph, FlashRank, OCR-LLM
검색 방식
Vector (Cosine) + BM25 (Keyword) + Graph 병렬 Hybrid Search
랭킹 알고리즘
RRF (k=60) Fusion + FlashRank Reranking
특수 기술
VectorChord RaBitQ 인덱스, Bert 토크나이저
문서 전처리
OCR-LLM, Office to md 변환 → Chunk 단위 임베딩
신뢰도 보완
RAG 검색과 별개로 md 문서를 LLM이 직접 읽어 2중 보완
Hybrid RAG - 아키텍처 개요
Architecture
Overview

사내 문서 검색 시스템에서 Vector 검색만으로는 키워드 매칭이 누락되고, BM25만으로는 의미적 유사성을 잡지 못하는 한계가 있었습니다. 두 방식 모두 단독으로는 검색 정확도를 보장할 수 없었습니다.

이를 해결하기 위해 Vector + BM25 + Graph 3종 병렬 검색에 RRF 결합과 Cross-Encoder 리랭킹을 더한 하이브리드 파이프라인을 설계했습니다. 또한 OCR-LLM과 Office to md 변환으로 비정형 문서까지 Chunk 단위로 임베딩하고, RAG와 별개로 md 문서를 LLM이 직접 읽어 신뢰도를 2중 보완하는 구조를 구축했습니다.

Hybrid RAG - 검색 파이프라인
Search
Pipeline

각 검색 방식이 서로 다른 강점을 가지기 때문에, 파이프라인은 병렬 검색 → 점수 통합 → 정밀 재정렬 3단계로 구성했습니다.

• Hybrid Search: Vector(의미 유사도) + BM25(키워드 정확도) + Graph(관계 탐색)를 병렬 실행하여 각 방식의 누락을 상호 보완
• RRF Fusion: 이질적인 점수 체계를 순위 기반으로 통합 (k=60), 스케일 차이 문제 해소
• FlashRank: Cross-Encoder로 최종 재정렬하여 실제 질문-문서 관련성 기준 정밀도 확보

LangGraph 워크플로우로 각 단계를 연결하여 검색 흐름을 제어합니다.

Troubleshooting 1 | BM25 동시 INSERT 데드락

상황: 사내 문서를 대량으로 등록할 때, 100개씩 나눠 넣도록 제한했는데 실제로는 105개가 들어가는 등 데이터 정합성이 깨지고, 동시 INSERT 시 데드락이 발생했습니다.

판단: BM25 인덱스 특성상 동시 쓰기가 내부 락 경합을 일으키는 구조라 판단. 병렬 처리 속도보다 데이터 정합성이 우선이므로 동시성을 제어하기로 결정했습니다.

액션: Semaphore로 동시 INSERT를 1개로 제한하고, 실패 시 지수 백오프 재시도 로직을 적용했습니다.

결과: 데드락이 완전히 해소되었고, 대량 문서 등록 시에도 정합성이 보장되는 안정적인 인덱싱 파이프라인을 확보했습니다.

Troubleshooting 2 | VectorChord 특수 문법

상황: 대용량 벡터 검색 성능 최적화를 위해 VectorChord와 RaBitQ 인덱스를 도입했으나, 표준 pgvector와 다른 특수 연산자(<=>)와 타입(bm25vector)을 사용해 기존 코드와 호환이 되지 않았습니다.

판단: VectorChord의 성능 이점(RaBitQ 양자화 기반 고속 검색)이 마이그레이션 비용보다 크다고 판단. 호환성 문제를 코드 레벨에서 해결하기로 결정했습니다.

액션: search_path에 bm25_catalog, tokenizer_catalog를 포함하고, 전용 SQL 패턴을 문서화하여 일관된 쿼리 작성 방식을 확립했습니다.

결과: VectorChord 전환이 완료되어 대용량 벡터 검색 성능이 최적화되었고, 문서화된 패턴 덕분에 이후 유지보수에서도 혼선 없이 운영할 수 있었습니다.

Key Algorithms | 핵심 알고리즘

• Vector Search: Cosine Distance (1 - distance = similarity)
• BM25 Search: Bert 토크나이저 기반 키워드 검색
• Graph Search: 관계 기반 문서 탐색
• RRF Fusion: Score = Σ(1 / (k + rank)), k=60
• FlashRank: ms-marco-MiniLM-L-12-v2 Cross-Encoder

What I Learned | 배운 점

• 검색 설계 관점: Vector 단독 검색의 키워드 누락, BM25 단독의 의미 누락을 직접 겪으며 하이브리드 검색이 '선택'이 아닌 '필수'임을 체감
• 동시성 제어: BM25 인덱스의 동시 쓰기 데드락을 해결하며, 성능 최적화보다 데이터 정합성을 먼저 확보해야 한다는 원칙을 학습
• 문서 전처리의 중요성: OCR-LLM, Office to md 변환 없이는 비정형 문서가 RAG 검색 대상에서 빠지며, 전처리 품질이 곧 검색 품질임을 확인
• 2중 신뢰도 설계: RAG 검색 + LLM 직접 읽기 병행으로 단일 경로 의존 리스크를 줄이는 아키텍처 패턴을 습득

Back to Main
거인소프트 대표작을 만나보세요.