[LLM Wiki 17] HyDE Embedding: 가상의 답변으로 검색 품질을 높이는 기술

HyDE는 Hypothetical Document Embeddings의 줄임말이다. 한국어로 풀면 “가상의 문서 embedding” 정도로 이해하면 된다.

핵심은 간단하다.

일반 vector search는 사용자 질문을 바로 embedding한다. 반면 HyDE는 질문에 대한 가상의 답변 문서를 먼저 만든 뒤, 그 가상 문서를 embedding해서 실제 문서를 찾는다.

즉 HyDE는 답을 생성하는 기술이 아니라, 검색을 더 잘하기 위한 우회 기술이다.

기본 개념

일반 vector search는 이렇게 동작한다.

사용자 질문
→ 질문을 embedding
→ 문서 embedding들과 비교
→ 의미가 가까운 문서 반환

예를 들어 질문이 짧다.

인증 설정 어디서 해?

이 질문 자체를 embedding하면 의미 정보가 부족할 수 있다. “인증”, “설정”, “어디” 정도의 짧은 신호만 들어 있기 때문이다.

HyDE는 중간에 LLM을 한 번 사용한다.

사용자 질문
→ LLM이 가상의 답변 문서 생성
→ 가상 문서를 embedding
→ 실제 문서 embedding들과 비교
→ 비슷한 실제 문서 반환

예를 들어 LLM이 이런 가상의 passage를 만든다.

Authentication settings are configured by setting AUTH_SECRET, session options,
and provider configuration in the environment file.

이 문장을 embedding하면 실제 문서 중에서 AUTH_SECRET, session options, provider configuration, environment file 같은 내용을 다루는 문서와 가까워질 수 있다.

중요한 점은 이 passage를 정답으로 믿지 않는다는 것이다. HyDE passage는 최종 답변이 아니라 검색용 미끼 문서다.

왜 질문보다 가상 문서가 더 잘 맞을 수 있나

질문은 짧고 생략이 많다. 반면 문서는 보통 설명형 문장으로 쓰여 있다.

사용자는 이렇게 묻는다.

가격 때문에 막힌 고객 미팅 찾아줘

하지만 실제 회의록에는 이렇게 쓰여 있을 수 있다.

The customer delayed the purchase because the annual license cost exceeded the approved budget.

질문과 문서는 단어가 다르다. 한국어와 영어가 섞일 수도 있고, “가격” 대신 “annual license cost”, “예산” 대신 “approved budget”이 쓰일 수 있다.

HyDE는 질문을 문서처럼 바꾼다.

The customer said the product was too expensive and the deal was delayed until budget approval.

이렇게 만든 passage는 실제 회의록 문장과 더 비슷한 형태가 된다. 그래서 embedding space에서 실제 문서와 가까워질 가능성이 커진다.

장점

HyDE의 가장 큰 장점은 짧고 모호한 질문을 더 풍부한 검색 신호로 바꾼다는 것이다.

질문이 “인증 설정”, “가격 이슈”, “성능 문제”처럼 짧을수록 직접 embedding은 약할 수 있다. HyDE는 이 질문을 문서형 passage로 늘려서 vector search가 비교할 의미 정보를 늘린다.

두 번째 장점은 표현 차이에 강하다는 점이다.

사용자는 “가격 때문에 막힘”이라고 말하고, 문서에는 “budget concern”, “pricing objection”, “too expensive”, “procurement delay”라고 쓰여 있을 수 있다. HyDE passage가 이런 표현을 포함하면 실제 문서와 더 가까워진다.

세 번째 장점은 답변형 문서 검색에 잘 맞는다는 점이다.

FAQ, 기술 문서, 회의록, 트러블슈팅 문서처럼 문서가 설명형으로 쓰여 있다면, 질문 자체보다 가상의 설명문을 embedding하는 편이 검색에 유리할 수 있다.

네 번째 장점은 recall을 넓히는 데 좋다는 점이다.

검색에서 recall은 정답 후보를 놓치지 않는 능력이다. HyDE는 정답 후보가 1차 검색 결과에 들어올 가능성을 높인다. 이후 reranker가 후보를 다시 줄 세우면 precision을 보완할 수 있다.

단점과 위험

HyDE의 단점은 LLM이 가상 문서를 만든다는 데서 시작된다. 가상 문서는 실제 근거가 아니다. LLM이 그럴듯하지만 틀린 passage를 만들 수 있다.

예를 들어 질문이 이렇다.

PCC quota policy

LLM이 이를 일반적인 “quota policy”로 오해해 클라우드 사용량 제한 문서를 상상할 수 있다. 하지만 실제로는 Apple Private Cloud Compute의 first-party quota 정책을 찾는 것일 수 있다.

이렇게 되면 HyDE passage가 검색 방향을 틀어버린다.

두 번째 위험은 고유명사와 정확한 문자열을 잃는 것이다.

에러 코드, 함수명, 파일명, 고객명, 제품명은 정확한 문자열 매칭이 중요하다. HyDE가 이를 일반적인 설명으로 바꿔버리면 오히려 검색 품질이 떨어질 수 있다.

예를 들어 다음 질문은 HyDE보다 BM25가 먼저다.

SQLITE_CONSTRAINT_UNIQUE
getUserSessionToken
Q4_K_M

세 번째 위험은 노이즈 증가다.

HyDE는 후보를 넓히는 기술이다. 후보가 넓어진다는 것은 관련 없는 문서도 더 들어올 수 있다는 뜻이다. 따라서 HyDE만 쓰면 precision이 떨어질 수 있다.

네 번째 위험은 비용과 지연이다.

HyDE는 질문마다 LLM generation을 한 번 더 수행한다. 로컬 LLM을 쓰더라도 모델 로딩, 추론 시간, 메모리 사용량이 든다. 검색이 매우 빈번한 시스템에서는 부담이 될 수 있다.

언제 쓰면 좋은가

HyDE는 다음 상황에 좋다.

첫째, 질문이 짧고 모호할 때다.

인증 설정
가격 이슈
성능 문제
배포 실패

이런 질문은 문서의 실제 표현을 알기 어렵다. HyDE가 설명형 passage를 만들어주면 vector search가 더 풍부한 의미로 검색할 수 있다.

둘째, 문서가 설명형일 때다.

기술 문서, FAQ, 회의록, 고객 상담 요약, 트러블슈팅 문서처럼 문장으로 설명된 자료는 HyDE와 잘 맞는다.

셋째, 동의어와 언어 혼합이 많을 때다.

한국어 질문으로 영어 문서를 찾거나, 같은 의미가 여러 표현으로 쓰이는 경우 HyDE가 도움이 된다.

가격 부담
budget concern
pricing objection
too expensive
cost issue

넷째, 1차 후보를 넓게 모아야 할 때다.

정답을 놓치는 것이 치명적인 탐색형 검색에서는 HyDE가 유리하다. 이후 rerank로 상위 결과를 정리하면 된다.

언제 쓰지 않는 게 좋은가

정확한 키워드가 중요한 경우에는 HyDE를 조심해야 한다.

에러 코드, 함수명, 클래스명, 파일명, 고객명, 제품명, 버전명은 BM25나 exact match가 더 안전하다.

TypeError: Cannot read properties of undefined
src/store.ts
Qwen3-Reranker-0.6B
customer_id

이런 검색은 가상의 답변을 만들기보다 원문 문자열을 그대로 찾는 편이 낫다.

두 번째로, metadata 조건이 중요한 검색에는 HyDE가 적합하지 않다.

예를 들어 “지난주에 수정된 문서”, “작성자가 Jay인 문서”, “status가 blocked인 회의록” 같은 질문은 embedding보다 metadata filter가 먼저다.

세 번째로, 도메인 약어가 많은 환경에서는 조심해야 한다.

내부 프로젝트명이나 회사 고유 약어를 LLM이 일반 의미로 해석하면 HyDE passage가 틀어진다. 이 경우에는 glossary, metadata, BM25, structured query를 함께 써야 한다.

네 번째로, 최종 답변 근거가 엄격해야 하는 시스템에서는 HyDE를 답변 근거로 쓰면 안 된다.

HyDE passage는 실제 문서가 아니다. 반드시 실제 검색된 문서와 citation을 근거로 답해야 한다.

한계는 어떻게 제어하나

HyDE의 한계는 후속 검색 파이프라인으로 제어해야 한다.

첫째, BM25와 함께 써야 한다.

HyDE는 의미 검색에 강하지만 정확한 문자열에는 약할 수 있다. BM25는 고유명사, 에러 코드, 함수명, 제목 검색에 강하다. 둘을 같이 쓰면 서로의 약점을 보완한다.

둘째, RRF 같은 fusion이 필요하다.

HyDE 결과만 믿지 않고 BM25, 일반 vector search, HyDE search 결과를 합쳐야 한다. QMD 같은 hybrid search 구조에서 RRF는 여러 검색 결과를 순위 기반으로 섞는 역할을 한다.

셋째, rerank가 필요하다.

HyDE는 후보를 넓힌다. 넓어진 후보 중 실제 질문에 맞는 chunk를 위로 올리는 것은 reranker의 역할이다.

넷째, citation을 강제해야 한다.

최종 답변 LLM은 HyDE passage를 근거로 삼으면 안 된다. 실제 문서에서 검색된 chunk만 근거로 답해야 한다.

다섯째, strong keyword query에서는 HyDE를 생략할 수 있어야 한다.

질문에 명확한 에러 코드나 고유명사가 있으면 HyDE보다 exact search가 우선이다. QMD가 strong BM25 signal이 있으면 expansion을 건너뛸 수 있는 이유도 이와 비슷하다.

QMD에서 HyDE는 어떤 위치인가

QMD의 query expansion은 lex, vec, hyde 타입을 만든다.

lex는 BM25/FTS로 간다. 짧고 정확한 키워드 검색에 쓴다.

vec는 vector search로 간다. 자연어 query를 embedding해 의미 기반 검색을 한다.

hyde는 가상의 답변 passage를 만들어 embedding한다. 질문 자체보다 문서에 가까운 형태로 검색하기 위한 것이다.

즉 QMD에서 HyDE는 단독 검색 방식이 아니라 hybrid retrieval의 한 축이다. BM25, vector search, RRF, rerank와 함께 쓰일 때 의미가 있다.

실무 판단 기준

HyDE를 쓸지 말지는 다음 질문으로 판단하면 된다.

첫째, 사용자의 질문이 짧고 문서 표현을 예측하기 어려운가? 그렇다면 HyDE가 도움이 될 수 있다.

둘째, 정확한 문자열이 핵심인가? 그렇다면 HyDE보다 BM25나 exact match가 먼저다.

셋째, 문서가 설명형인가? 그렇다면 HyDE가 잘 맞을 가능성이 높다.

넷째, LLM이 도메인 용어를 오해할 가능성이 큰가? 그렇다면 HyDE만 믿으면 안 된다.

다섯째, 이후 rerank와 citation 검증이 있는가? 없다면 HyDE 결과를 그대로 최종 답변에 쓰면 위험하다.

정리

HyDE embedding은 질문을 바로 embedding하지 않고, 질문에 대한 가상의 답변 문서를 만든 뒤 그 문서를 embedding하는 검색 기법이다.

장점은 짧고 모호한 질문을 더 풍부한 의미 표현으로 바꿔 recall을 높일 수 있다는 점이다. 설명형 문서, FAQ, 회의록, 기술 문서 검색에 특히 잘 맞는다.

단점은 가상 문서가 틀릴 수 있다는 점이다. 고유명사, 에러 코드, 함수명, metadata 조건처럼 정확성이 중요한 검색에는 HyDE가 오히려 방해될 수 있다.

따라서 HyDE는 단독 정답 생성 기술이 아니라 hybrid search의 보조 장치로 써야 한다. BM25, vector search, RRF, rerank, citation 검증과 함께 사용할 때 가장 안전하다.