[LLM Wiki 27] 임베딩 검색은 왜 비슷한 업무 문서를 헷갈릴까: GraphDB로 검색 범위 줄이기

![LLM Wiki 27 임베딩 검색은 왜 비슷한 업무 문서를 헷갈릴까: GraphDB로 검색 범위 줄이기

문서 검색에 임베딩을 사용하면 표현이 조금 달라도 의미가 비슷한 자료를 찾을 수 있습니다. 그러나 업무 규칙처럼 문장 대부분이 같고 일부 조건만 다른 문서에서는 이 장점이 오히려 문제가 되기도 합니다.

예를 들어 다음 세 문장을 생각해 보겠습니다.

한국 고객은 구매 후 7일 이내에 환불할 수 있습니다.
미국 고객은 구매 후 30일 이내에 환불할 수 있습니다.
기업 고객은 구매 후 14일 이내에 환불할 수 있습니다.

세 문장의 주제와 표현은 거의 같습니다. 임베딩 검색에서는 모두 높은 유사도를 받을 가능성이 큽니다. 하지만 실제 업무에서는 한국, 미국, 기업 고객, 7일, 30일처럼 몇 개의 단어가 정답을 완전히 바꿉니다.

이 문제를 줄이는 한 가지 방법은 모든 본문에서 곧바로 정답을 찾는 대신, 문서의 계층과 관계를 이용해 검색 공간, search space부터 줄이는 것입니다.

먼저 알아둘 용어

Embedding, 임베딩은 문장이나 문서의 의미를 숫자 배열인 vector, 벡터로 바꾸는 기술입니다. 의미가 비슷한 문장은 벡터 공간에서도 가까이 배치됩니다.

Chunk, 청크는 긴 문서를 검색할 수 있도록 나눈 작은 단위입니다. 보통 문단이나 일정한 토큰 길이를 기준으로 만듭니다.

Page Tree, 페이지 트리는 상위 페이지와 하위 페이지로 구성된 문서 계층입니다. 예를 들어 고객지원 → 환불 정책 → 한국 → 모바일 상품처럼 표현할 수 있습니다.

GraphDB, Graph Database, 그래프 데이터베이스는 페이지나 개념을 node, 노드로 저장하고, 그 사이의 관계를 edge, 엣지로 연결하는 데이터베이스입니다. 여기서 그래프는 통계 차트가 아니라 대상과 관계로 이루어진 연결 구조를 뜻합니다.

LLM, Large Language Model, 대규모 언어 모델은 검색된 근거를 읽고 자연어 답변을 작성합니다. LLM이 검색 자체의 오류를 항상 바로잡아 주는 것은 아닙니다.

본문 청크 전체를 검색할 때 생기는 문제

일반적인 임베딩 검색은 질문을 벡터로 바꾸고 모든 문서 청크와 비교한 뒤 가까운 결과를 상위에 배치합니다.

사용자 질문
→ 질문 임베딩 생성
→ 모든 청크와 벡터 유사도 비교
→ 상위 N개 청크 선택
→ LLM에 전달
→ 답변 생성

이 방식은 제품 소개, 회의록, 기술 문서처럼 주제가 서로 다른 자료를 찾을 때 효과적입니다. 그러나 비즈니스 규칙을 다루는 문서에는 다음과 같은 문제가 생깁니다.

국가나 고객 등급만 다른 정책이 모두 상위에 나올 수 있습니다.
버전 번호나 날짜처럼 작은 차이를 임베딩 점수가 충분히 반영하지 못할 수 있습니다.
비슷한 청크가 많아지면서 LLM에 전달할 후보가 늘어납니다.
응답 시간이 길어지고 서로 다른 규칙이 한 답변에 섞일 수 있습니다.
유사도 점수는 높지만 실제 질문의 조건에는 맞지 않는 문서가 선택될 수 있습니다.

임베딩이 숫자나 키워드를 전혀 구분하지 못한다는 뜻은 아닙니다. 다만 임베딩은 전체적인 의미의 유사도를 중심으로 표현하므로, 일부 조건의 정확한 일치가 중요한 문제를 그것만으로 해결하기 어렵다는 뜻입니다.

광범위한 질문은 왜 응답시간도 늘리는가

환불 정책, 상품, 배송처럼 범위가 넓은 단어는 검색 대상을 잘 구분하지 못합니다. 이를 선택도가 낮다고 표현할 수 있습니다.

광범위한 질문이 들어오면 키워드 검색에서는 같은 단어가 포함된 페이지가 대량으로 일치합니다. 임베딩 검색에서도 의미적으로 가까운 페이지가 여러 업무 영역에 걸쳐 나올 수 있습니다.

광범위한 질문
→ 검색 조건의 구분력 부족
→ 후보 페이지 증가
→ 권한 확인과 본문 로딩 증가
→ 재정렬할 후보 증가
→ LLM에 전달할 근거 선별과 입력 토큰 증가
→ 전체 응답시간 증가

후보가 많으면 속도만 느려지는 것이 아닙니다. 국가, 제품, 고객 유형, 문서 버전이 다른 규칙이 함께 검색되면서 답변이 서로 다른 조건을 섞을 위험도 커집니다.

top-k를 무조건 작게 줄이는 것만으로는 충분하지 않습니다. Top-k는 검색 결과에서 상위 몇 개를 가져올지 정하는 값입니다. 후보 수를 줄이면 속도는 개선될 수 있지만, 정답 문서가 상위 결과에 들지 못한 경우에는 그대로 탈락합니다. 검색 결과를 자르기 전에 어떤 범위를 검색할지 정하는 단계가 필요합니다.

질문 복잡도에 따라 검색 전략을 선택한다

모든 질문에 동일한 임베딩 검색과 동일한 top-k를 적용하는 대신, 검색 전에 질문의 특성을 분석할 수 있습니다.

이를 담당하는 구성요소를 Query Router, 쿼리 라우터 또는 Query Planner, 쿼리 플래너라고 부를 수 있습니다. 질문을 읽고 정답을 직접 만드는 것이 아니라 어떤 검색 경로를 실행할지 결정합니다.

분석할 수 있는 조건은 다음과 같습니다.

제품명, 국가, 날짜, 규정 번호처럼 정확한 조건이 있는가
한 문서에서 답할 수 있는가, 여러 문서의 관계를 따라가야 하는가
정확한 숫자와 명칭이 중요한가, 의미가 비슷한 설명이 중요한가
질문 범위가 너무 넓어 추가 조건이 필요한가
한 질문에 여러 업무 의도가 섞였는가

질문 유형에 따라 다음처럼 검색 전략을 바꿀 수 있습니다.

질문 유형	우선 적용할 전략
규정 번호와 제품명이 명확함	키워드 검색, 메타데이터 필터
표현은 다르지만 의미가 유사함	임베딩 검색
정확어와 의미가 모두 중요함	Hybrid Search, 키워드와 임베딩 결합
여러 문서의 연결이 답에 필요함	GraphDB 탐색, multi-hop 검색
질문이 지나치게 광범위함	질문 재작성, 범위 확인 질문
여러 의도가 섞여 있음	작은 하위 질문으로 분해해 각각 검색

Hybrid Search, 하이브리드 검색은 키워드의 정확성과 임베딩의 의미 유사도를 함께 이용하는 검색 방식입니다. Multi-hop search, 다단계 관계 검색은 한 문서를 찾은 뒤 거기에 연결된 다른 문서까지 따라가는 방식입니다.

예를 들어 “환불 정책 알려줘”라는 질문은 국가와 상품이 없어 너무 넓습니다. 시스템은 사용자에게 조건을 되묻거나, 앞선 대화와 사용자 업무 영역에서 조건을 찾을 수 있습니다.

“환불 정책 알려줘”
→ 범위가 넓다고 판단
→ “어느 국가와 상품의 정책인가?”
→ “한국 모바일 상품”
→ 한국, 모바일 상품 문서만 검색

추가 질문이 항상 필요한 것은 아닙니다. 검색 비용이 낮고 공통 답변으로 충분한 단순 질문은 곧바로 처리하고, 범위가 넓어 오답 위험이 큰 경우에만 확인할 수 있습니다.

1단계, 모든 페이지를 구조화한다

검색 전에 문서를 수집하고 페이지 사이의 구조를 GraphDB에 저장합니다.

[고객지원 Space]
        │ 포함한다
        ▼
    [환불 정책]
       ├── [한국]
       │      ├── [모바일 상품]
       │      └── [가전 상품]
       └── [미국]
              ├── [모바일 상품]
              └── [가전 상품]

각 페이지는 노드가 되고 다음 정보는 관계가 될 수 있습니다.

Space가 페이지를 포함한다.
상위 페이지가 하위 페이지를 포함한다.
한 페이지가 다른 페이지를 링크하거나 참조한다.
여러 페이지가 같은 제품, 시스템, 업무 영역에 속한다.
문서가 특정 버전이나 후속 문서로 연결된다.

GraphDB가 문서 관계를 자동으로 정확하게 만들어 주는 것은 아닙니다. 페이지 계층과 링크는 비교적 확실한 관계로 가져올 수 있지만, 본문에서 추출한 의미 관계는 규칙, LLM 또는 사람이 검증해야 합니다.

2단계, Page Tree 제목에서 시작 지점을 찾는다

본문의 모든 청크를 먼저 비교하지 않고 Page Tree의 제목을 임베딩 검색 대상으로 삼을 수 있습니다.

사용자가 “한국 모바일 상품의 환불 기한은?”이라고 질문했다면 다음 제목들이 시작점 후보가 됩니다.

환불 정책
한국 고객 정책
모바일 상품 정책
기업 고객 정책

제목은 본문보다 짧고 문서의 용도를 압축해서 표현합니다. 따라서 질문과 가까운 업무 영역을 고르는 내비게이션으로 활용하기 좋습니다.

이때 임베딩의 역할은 정답 문장을 바로 고르는 것이 아니라 정답이 있을 가능성이 높은 문서 영역을 고르는 것입니다.

3단계, GraphDB에서 관련 경로만 탐색한다

제목 검색으로 환불 정책을 찾았다면 GraphDB의 관계를 따라 한국 → 모바일 상품 경로로 이동합니다. 모든 관계를 무제한으로 따라가면 후보가 다시 많아지므로 탐색 규칙이 필요합니다.

허용할 관계 종류를 제한합니다.
상위, 하위 탐색 깊이를 제한합니다.
국가, 제품, 버전 같은 질문 조건으로 경로를 필터링합니다.
사용자에게 접근 권한이 있는 페이지와 관계만 통과시킵니다.
오래됐거나 폐기된 문서는 제외합니다.

이 과정을 마치면 수만 개 청크가 아니라 관련 페이지 몇 개만 본문 검색 대상으로 남습니다.

4단계, 좁혀진 본문에서 정확한 조건을 확인한다

마지막 단계에서는 임베딩만 사용하지 않고 정확한 검색 방법을 함께 적용합니다.

Keyword search, 키워드 검색으로 국가명, 제품명, 규정 번호를 확인합니다.
Lexical search, 어휘 검색으로 질문에 나온 표현이 실제 문서에 있는지 확인합니다.
Metadata filter, 메타데이터 필터로 국가, 제품, 버전, 작성 시점을 제한합니다.
Reranker, 재순위화 모델로 질문과 각 후보를 함께 읽어 순서를 다시 정합니다.
LLM이 선택된 근거를 바탕으로 답변하되 출처와 적용 조건을 함께 제시합니다.

여기서 핵심은 임베딩을 버리는 것이 아닙니다. 의미 검색과 정확 검색에 서로 다른 역할을 맡기는 것입니다.

기술별 역할을 나누면

기술	맡는 역할
임베딩	질문과 의미가 가까운 페이지 제목과 업무 영역 탐색
Page Tree	상위, 하위 페이지의 계층 표현
GraphDB	페이지, 제품, 시스템, 업무 사이의 관계 저장과 탐색
키워드 및 어휘 검색	숫자, 국가, 버전, 규정명 같은 정확한 조건 확인
메타데이터 필터	권한, 제품, 국가, 날짜를 기준으로 후보 제한
Reranker	좁혀진 후보를 질문 관련도 순으로 다시 정렬
LLM	선택된 근거를 읽고 최종 답변 생성

전체 처리 흐름

질문 입력
→ 국가, 제품, 업무 조건 분석
→ Page Tree 제목 임베딩 검색
→ GraphDB에서 관련 페이지 경로 탐색
→ 권한과 메타데이터로 후보 제한
→ 선택된 페이지의 본문만 검색
→ 키워드 일치와 rerank로 후보 정밀화
→ LLM이 근거와 적용 조건을 포함해 답변

이 구조는 계층형 검색 또는 multi-stage retrieval, 다단계 검색의 한 형태입니다. 실제 구현에서는 GraphDB가 반드시 필요한 것은 아닙니다. 문서 규모와 관계가 단순하면 관계형 데이터베이스의 부모 페이지 ID, 검색 엔진의 필터 또는 경로 메타데이터만으로도 비슷한 범위 축소를 구현할 수 있습니다.

GraphDB는 문서 사이의 연결 종류가 많거나 여러 단계를 따라가야 할 때 가치가 커집니다.

검색은 빨라질 수 있지만 아키텍처는 커진다

단순한 RAG는 질문을 임베딩 검색에 보내고 찾은 문서를 LLM에 전달하는 정도로 구성할 수 있습니다.

질문별 검색 전략과 GraphDB를 도입하면 별도의 판단, 저장, 동기화 계층이 추가됩니다.

문서 처리 경로
원본 문서
→ 변경 감지와 수집
→ Page Tree, 링크, 메타데이터 추출
→ Vector DB와 GraphDB에 각각 저장
→ 두 저장소의 문서 ID와 삭제 상태 동기화

질문 처리 경로
사용자 질문
→ 질문 복잡도 분석
→ 검색 전략과 search space 선택
→ Graph 탐색, 키워드 또는 임베딩 검색
→ 권한 필터
→ 후보 재정렬
→ 근거 검증과 답변 생성

추가되는 운영 책임은 다음과 같습니다.

Graph schema, 그래프 스키마와 관계 종류를 설계합니다.
원본 문서, Vector DB, GraphDB 사이의 변경과 삭제를 동기화합니다.
같은 제품명과 조직명을 하나의 대상으로 묶는 entity resolution, 개체 정규화를 수행합니다.
질문 유형별 검색 전략과 실패 시 fallback, 폴백을 관리합니다.
Graph 탐색 깊이와 관계 종류를 제한해 후보 폭증을 막습니다.
사용자 권한을 Vector 검색과 Graph 탐색 모두에 적용합니다.
질문 유형별 응답시간, 검색 재현율, 답변 품질을 측정합니다.

따라서 검색할 문서와 LLM 입력 토큰을 줄일 가능성은 있지만, 데이터 저장소와 처리 단계, 장애 지점도 함께 늘어납니다. GraphDB를 넣었다는 사실만으로 효과가 보장되지는 않습니다. 줄어든 검색시간과 개선된 답변 품질이 추가된 운영 비용보다 큰지 실제 질문으로 평가해야 합니다.

주의할 점

제목만 임베딩하면 제목이 부실한 문서를 놓칠 수 있습니다. 회의 자료, 정책 정리, 최종본 같은 제목만으로는 내용을 알기 어렵기 때문입니다. 제목과 함께 짧은 요약, 상위 경로, 핵심 엔터티를 임베딩하는 방법을 검토할 수 있습니다.

또한 검색 범위를 너무 일찍 좁히면 정답 문서를 탈락시키는 false negative, 거짓 음성이 생깁니다. 따라서 다음 항목을 실제 질문 데이터로 평가해야 합니다.

정답 문서가 후보에 포함되는 Recall, 재현율
잘못된 국가나 버전이 섞이지 않는 정확성
후보 수와 LLM 입력 토큰 감소량
전체 응답 시간
기존 전체 임베딩 검색과 비교한 답변 품질

한 문장으로 정리하면

임베딩으로 모든 본문에서 정답을 곧바로 찾기보다, 문서 제목과 구조로 검색 범위를 먼저 줄인 다음 좁혀진 본문에서 결정적인 키워드와 조건을 정확하게 확인한다.

임베딩은 “어디를 볼 것인가”를 찾고, GraphDB는 “문서가 어떻게 연결됐는가”를 따라가며, 키워드 검색과 필터는 “정답을 바꾸는 조건이 무엇인가”를 확인합니다.

전체 메뉴