정확하게 찾아내는 방법
벡터 DB · 하이브리드 검색 · 리랭킹

1. 벡터 데이터베이스가 따로 필요한 이유

회사에서 쓰는 일반적인 데이터베이스는 정확한 값을 찾는 데 최적화되어 있습니다. "사번이 12345인 사람"이나 "3월 매출 합계" 같은 질의는 순식간에 처리합니다.

그런데 우리가 하려는 일은 다릅니다. "이 벡터와 방향이 가장 비슷한 벡터 열 개를 찾아라"입니다. 일반 데이터베이스에는 이런 기능이 없어서 저장된 모든 벡터와 하나씩 비교해야 합니다. 수백만 건이면 수 초에서 수십 초가 걸립니다. 챗봇으로는 쓸 수 없는 속도입니다.

그래서 이 작업만을 위해 만들어진 벡터 데이터베이스를 씁니다.

사내망에서 대량의 문서를 다룬다면 Milvus가 무난합니다. 아래 설명은 Milvus를 기준으로 하지만, 원리는 어느 제품이든 같습니다.

저장되는 내용

벡터만 저장하면 검색은 되지만 답을 만들 수 없습니다. 2편에서 말씀드린 대로 원문과 출처를 함께 저장해야 합니다.

{
  "id": 1042,
  "vector": [0.12, -0.09, ...],        ← 검색에 사용
  "text":   "이용 수수료는 서비스 유형에 따라...",   ← LLM에게 전달
  "source": "이용안내.pdf",             ← 출처 표기에 사용
  "page":   4,
  "doc_type": "manual"                  ← 문서 종류로 걸러낼 때 사용
}

2. 밀리초 검색의 비밀 — HNSW

벡터 데이터베이스가 빠른 이유는 전부 비교하지 않기 때문입니다.

가장 널리 쓰이는 방법이 HNSW입니다. 벡터들을 미리 그물처럼 연결해 두고, 위층에서 대략적인 방향을 잡은 다음 아래층으로 내려가며 정밀하게 좁혀 갑니다.

지도에서 길을 찾는 것과 비슷합니다. 서울에서 부산의 어떤 골목을 찾을 때 전국의 모든 골목을 뒤지지 않습니다. 고속도로로 부산까지 간 다음, 시내 도로로 동네를 찾고, 마지막에 골목을 찾습니다. HNSW도 같은 방식으로 계층을 오르내립니다.

정확도를 조금 양보하는 대신 속도를 수천 배 얻는 방식입니다. 이런 접근을 근사 검색이라고 합니다. 100건 중 한두 건을 놓칠 수 있지만, 챗봇에서는 사실상 체감되지 않습니다.

세 값 모두 크게 잡을수록 정확해지고 느려집니다. 기본값에서 시작해 필요할 때 조정하시면 됩니다.

3. 의미 검색이 놓치는 것들

지금까지 설명한 방식, 즉 임베딩 벡터로 찾는 검색을 의미 검색 또는 Dense 검색이라고 부릅니다. 숫자가 빽빽하게 채워진 벡터를 쓰기 때문에 이런 이름이 붙었습니다.

의미 검색은 표현이 달라도 뜻이 같으면 찾아냅니다. 이것이 가장 큰 장점입니다.

단어가 하나도 겹치지 않는데도 찾아냅니다. 키워드 검색으로는 불가능한 일입니다.

그런데 반대 방향에서는 의외로 약합니다.

임베딩 모델 입장에서 "4.2.1"과 "4.2.2"는 거의 같은 것으로 보입니다. 사람에게는 완전히 다른 버전이지만, 의미의 세계에서는 구분되지 않습니다.

이것이 의미 검색만으로 시스템을 만들면 안 되는 이유입니다. 정확히 그 글자를 찾는 방법이 따로 필요합니다.

4. 키워드 검색과 BM25

전통적인 검색은 단어가 실제로 들어 있는지를 봅니다. 이것을 키워드 검색 또는 Sparse 검색이라고 합니다.

이 방식에서 문서는 이렇게 표현됩니다. 어휘 전체 크기의 목록을 두고, 실제로 등장한 단어 자리에만 점수를 매깁니다. 나머지는 전부 0입니다. 대부분이 비어 있어서 "성긴(sparse)"이라는 이름이 붙었습니다.

{"수수료": 0.82,
 "이용":   0.44,
 "SDC":    0.71,
 ... 나머지 99,997개 단어는 전부 0}

점수를 매기는 표준 방법이 BM25입니다. 검색 엔진에서 오래도록 쓰여 온 검증된 방식입니다. 두 가지를 봅니다.

• 얼마나 드문 단어인가 — "은, 는, 이, 가"처럼 모든 문서에 나오는 단어는 점수가 낮습니다. 특정 문서에만 나오는 전문 용어는 점수가 높습니다.
• 문서 안에서 몇 번 나오는가 — 자주 나올수록 높습니다. 다만 긴 문서가 유리해지지 않도록 길이를 보정합니다.

"반출심의"라는 단어가 질문에 들어 있고 특정 문서에만 그 단어가 있다면, BM25는 그 문서를 정확하게 1위로 올립니다. 의미를 전혀 이해하지 못하면서도 말입니다.

표를 보시면 두 방식의 강점과 약점이 정확히 반대라는 것을 알 수 있습니다. 그렇다면 답은 하나입니다.

5. 하이브리드 검색 — 둘을 합치기

두 검색을 동시에 돌리고 결과를 합치는 것을 하이브리드 검색이라고 합니다. 실무 RAG에서는 사실상 기본 구성입니다.

합칠 때 문제가 하나 있습니다. 두 검색의 점수 체계가 서로 다릅니다. 의미 검색은 0~1 사이의 유사도를 내고, BM25는 상한이 없는 점수를 냅니다. 그냥 더하면 한쪽이 일방적으로 결과를 지배합니다.

그래서 점수 대신 순위를 씁니다. 이 방법을 RRF라고 합니다. 각 검색에서의 순위를 역수로 바꿔 더하는 방식입니다.

점수 = 1 / (60 + 순위)  를 각 검색마다 계산해서 더함

문서 A : 의미 검색 2위, 키워드 검색 1위
   → 1/(60+2) + 1/(60+1) = 0.0161 + 0.0164 = 0.0325

문서 B : 의미 검색 1위, 키워드 검색 5위
   → 1/(60+1) + 1/(60+5) = 0.0164 + 0.0154 = 0.0318

→ 양쪽 모두에서 상위인 A가 최종 1위

결과적으로 한쪽에서만 1등인 문서보다, 양쪽에서 고르게 상위인 문서가 우선됩니다. 사람의 직관과도 잘 맞습니다.

Milvus에서는 이 과정이 기능으로 제공되어 설정만 하면 됩니다.

from pymilvus import AnnSearchRequest, RRFRanker

의미검색 = AnnSearchRequest(data=[벡터], anns_field="dense_vector", limit=10)
키워드검색 = AnnSearchRequest(data=[단어점수], anns_field="sparse_vector", limit=10)

결과 = collection.hybrid_search(
    [의미검색, 키워드검색],
    rerank=RRFRanker(k=60),
    limit=10)

6. 리랭킹 — 다시 줄 세우기

여기까지 해도 문제가 하나 남습니다. 검색은 빠르지만 순위가 항상 정확하지는 않습니다. 정말 필요한 문서가 3위나 4위에 있는 경우가 흔합니다.

예를 들어 "이용 수수료 기준이 어떻게 되나요"라고 물었을 때 이런 결과가 나왔다고 해 보겠습니다.

가장 정확한 문서가 4위에 있습니다. 점수 차이도 0.06밖에 나지 않습니다. 벡터 검색만으로는 "안내"와 "상세 기준"의 차이를 구분하지 못한 것입니다.

왜 이런 일이 생기는가

지금까지의 검색 방식은 질문과 문서를 각각 따로 숫자로 바꾼 뒤 비교합니다. 문서 벡터는 미리 계산해 저장해 둘 수 있어서 대단히 빠릅니다. 대신 질문과 문서를 함께 놓고 따져 보지는 않습니다.

더 정확한 방법이 있습니다. 질문과 문서를 한꺼번에 넣고 "이 둘이 얼마나 맞는가"를 직접 판정하게 하는 것입니다. 훨씬 정확하지만, 미리 계산해 둘 수가 없어서 질문이 바뀔 때마다 모든 문서를 새로 계산해야 합니다.

그래서 두 단계로 나눕니다

빠른 방법으로 후보 50개를 먼저 추리고, 그 50개에만 정확한 방법을 적용해 최종 5개를 고릅니다. 이 두 번째 단계를 리랭킹이라고 합니다.

수백만 건에 정밀 계산을 돌리는 것은 불가능하지만 50건이라면 충분히 가능합니다. 앞의 예시에 리랭킹을 적용하면 순서가 이렇게 바뀝니다.

점수 분포도 달라졌습니다. 리랭킹 전에는 0.81~0.87 사이에 몰려 있어 구분이 어려웠지만, 리랭킹 후에는 0.42~0.94로 벌어져 관련 없는 문서를 잘라내기 쉬워졌습니다.

이 점수 차이를 활용하면 품질을 한 번 더 올릴 수 있습니다. 예를 들어 0.4 미만은 아예 버리도록 하면, 관련 없는 문서가 LLM에게 전달되는 일을 막을 수 있습니다.

from FlagEmbedding import FlagReranker

reranker = FlagReranker('BAAI/bge-reranker-v2-m3')

질문 = "이용 수수료 기준이 어떻게 되나요?"
후보 = [문서1, 문서2, ...]                    # 하이브리드 검색 결과 50개

쌍 = [[질문, 문서] for 문서 in 후보]           # 질문과 문서를 함께 넣음
점수 = reranker.compute_score(쌍, normalize=True)

상위5개 = [문서 for _, 문서 in
          sorted(zip(점수, 후보), reverse=True)[:5]]

리랭킹은 할루시네이션 감소에 직접 기여합니다. 1편에서 말씀드린 대로 RAG의 잘못된 답은 대부분 검색 실패에서 시작되기 때문입니다.

7. 질문마다 다른 길로 보내기

마지막으로 검색만으로는 풀 수 없는 경우를 다루겠습니다.

"교수가 3일 이용하면 수수료가 얼마인가요"라는 질문을 생각해 보겠습니다. 검색은 수수료 기준표를 잘 찾아옵니다. 그런데 곱셈은 LLM이 합니다. LLM은 계산에 약해서 "대략 15만원 정도"처럼 틀린 답을 낼 수 있습니다.

그래서 질문의 종류를 먼저 판단해 서로 다른 길로 보냅니다.

어느 길로 보낼지 판단하는 부분을 라우터라고 합니다. 두 단계로 만들면 비용을 아낄 수 있습니다.

# 1차 — 키워드로 빠르게 판단 (LLM 호출 없음, 즉시 처리)
계산_키워드 = ["수수료", "얼마", "비용", "계산", "추천"]
목록_키워드 = ["변수", "항목", "포함된 조사", "데이터 목록"]

# 2차 — 애매하면 LLM에게 물어봄
"""사용자 질문을 아래 셋 중 하나로 분류하세요. JSON으로만 답하세요.
 - "문서검색" : 절차, 규정, 안내
 - "함수실행" : 수수료 계산, 서비스 추천
 - "목록조회" : 조사 목록, 데이터 항목
질문: {질문}"""

LLM이 함수를 호출하게 하기

계산이 필요할 때 쓰는 방식을 Tool Calling이라고 합니다. LLM이 직접 계산하는 대신, 어떤 함수를 어떤 값으로 부를지만 결정하게 하는 것입니다. 실제 계산은 우리가 만든 프로그램이 합니다.

사용자 : "교수인데 인가 서비스 3일 이용하면 얼마예요?"

1단계 — LLM이 호출할 함수와 값을 결정
   {"함수": "수수료계산",
    "값": {"서비스": "인가", "일수": 3, "구분": "교수"}}

2단계 — 우리 프로그램이 실제로 계산
   수수료계산(서비스="인가", 일수=3, 구분="교수")
   → {"기간제": 90000, "정액제": 120000, "추천": "기간제"}

3단계 — 결과를 LLM에게 돌려주고 문장으로 만들게 함
   "교수님이 인가 서비스를 3일 이용하실 경우 기간제는 9만원,
    정액제는 12만원입니다. 3일 이내라면 기간제가 유리합니다."

계산은 프로그램이 하고 LLM은 말만 만듭니다. 그래서 결과가 항상 정확합니다. 실제 함수는 평범한 코드입니다.

요금표 = {
  "공공": {"교수": 20000, "학생": 10000, "일반": 30000},
  "인가": {"교수": 30000, "학생": 15000, "일반": 50000},
}

def 수수료계산(서비스, 일수, 구분):
    하루 = 요금표[서비스][구분]
    return {"기간제": 하루 * 일수,
            "정액제": 하루 * 5,
            "추천": "기간제" if 일수 < 5 else "정액제"}

문서에 답이 없을 때

검색 점수를 보고 대응을 바꾸는 방법도 있습니다.

최고점수 = 검색결과 중 가장 높은 점수

if   최고점수 >= 0.75 :   내부 문서로 충분 → 그대로 답변
elif 최고점수 >= 0.50 :   부분적으로 관련 → 추가 자료와 함께 답변
else                  :   관련 문서 없음 → "찾을 수 없습니다"로 답변

주의 — 기준점을 너무 높이면 문서가 있는데도 못 찾았다고 답하고, 너무 낮추면 관련 없는 문서로 엉뚱한 답을 만듭니다. 0.6~0.75 사이에서 시작해 실제 질문 기록을 보며 조정하시기 바랍니다. 처음부터 정답을 맞히려 하지 말고, 운영하면서 맞춰 가는 값이라고 생각하시는 편이 좋습니다.

8. 자주 나오는 질문

다음 편에서는 지금까지의 내용을 실제로 동작하는 챗봇으로 조립하는 방법을 다룹니다.