RAG 파이프라인 실전 공개: HyDE로 질의를 보강해 검색 정확도를 끌어올린 사례

핵심 메시지

• RAG는 LLM에 외부 문서를 붙여 답변의 근거를 만드는 기법으로, 반세기 된 정보 검색 문제의 연장선에 있다.
• 단어 일치 기반의 희소 검색에서 의미 기반의 밀집 검색으로 옮겨 왔지만, 실전 파이프라인은 여전히 선택지마다 성능이 흔들린다.
• 일상 대화에서는 '무엇이 정답인지' 자체가 모호해, 검색이 꼭 필요한 경우와 있으면 좋은 경우를 구분해야 한다.
• 대화 전체를 그대로 임베딩하면 분량이 많은 주제 쪽으로 벡터가 쏠려 정작 필요한 기억을 놓친다.
• HyDE는 질의를 바탕으로 가상의 문서를 생성해, 저장된 문서와 형태를 맞춘 뒤 검색하는 우회로다.

쉽게 이해하기

영상은 낯선 코드베이스에서 원하는 파일을 정확히 찾아주는 AI 경험에서 출발한다. 질의에 쓴 단어가 코드에 한 번도 등장하지 않는데도 답을 찾아내는 일이 바로 RAG가 푸는 문제다. 진행자는 맥락 창이 계속 커지는 지금도 검색이 필요한가, 필요하다면 무엇이 정답인가라는 논쟁이 뜨겁다고 짚는다.

기술적 배경은 간결하게 정리된다. 과거 정보 검색은 문서별 단어 빈도 행렬 위에서 점수를 계산하는 희소 검색이었고, 이후 신경망이 텍스트를 벡터 공간에 투영하면서 글자가 아니라 의미로 매칭하는 밀집 검색이 자리 잡았다. 다만 이론과 달리 실제 파이프라인은 청킹 방식, 임베딩 모델 선택, 가져올 문서 수, 재순위 여부 같은 결정마다 결과가 크게 달라진다.

진행자는 추상적인 논쟁 대신 실제 사례를 보여주겠다며 협찬이 아님을 분명히 밝히고, 단체 채팅에 참여하는 대화형 AI를 만드는 팀의 엔지니어를 초대한다. 이 팀의 문제의식은 뚜렷하다. 사용자가 굳이 요청하지 않아도 지난 대화에서 취향과 사정을 자연스럽게 꺼내 써야 '내 말을 듣고 있다'는 느낌이 생긴다는 것이다.

그런데 잡담에서는 검색이 쉽지 않다. 저녁 식사 장소를 물으면 검색 없이도 그럴듯한 답이 나오므로, 검색은 정답을 만드는 필수 조건이 아니라 답을 개인화하는 장치가 된다. 게다가 대화 대부분이 다른 주제로 채워져 있으면, 그 대화를 통째로 임베딩한 벡터는 마지막에 던진 질문과 상관없는 쪽으로 쏠려 버린다.

해법으로 제시된 것이 HyDE다. 질의를 그대로 쓰는 대신 LLM으로 '있을 법한 대화'를 여러 개 지어내고, 저장된 대화들과 같은 형식·밀도를 갖춘 그 가상 문서들의 임베딩으로 이웃을 찾는 방식이다. 발표자는 이 방법으로 지역 상권 선호, 알레르기 언급, 식당 추천 기록을 모두 끌어올 수 있었다고 설명하면서, 지연 시간 증가와 후보 폭증이라는 대가도 함께 짚는다.

주요 인사이트

• 질의와 문서의 '구조'가 다르면 같은 인코더를 써도 유사도가 약해진다. 질의 전용 인코더를 따로 학습하는 대신, 질의를 문서 형태로 바꿔 맞추는 편이 스타트업에게 현실적인 선택이라고 발표자는 말한다.
• 질의 재작성만으로는 이 문제가 풀리지 않는다. 짧은 질문은 의미 밀도가 낮아, 문장을 다듬어도 여러 주제가 겹겹이 쌓인 저장 문서 옆까지 다가가지 못하기 때문이다.
• 가져오는 문서를 늘리면 놓칠 위험은 줄지만 맥락이 오염되는 이른바 '컨텍스트 로트'가 생긴다. 걸러내려고 재순위를 붙이면 다시 지연이 늘어, 품질과 속도의 저울질이 매 결정마다 반복된다.
• 발표자는 생성한 가상 대화의 말투가 실제 사용자와 어긋날 위험도 언급하지만, 좋은 임베딩 모델은 문체보다 의미를 담기 때문에 상대적으로 덜 걱정한다고 밝힌다.
• 슬랙 대화·설계 문서·코드처럼 성격이 다른 자료가 섞이면 하나의 처리 방식으로는 감당되지 않는다. 진행자는 만능 해법은 없으며 업계 사례에서 배우는 편이 낫다고 정리한다.

자주 묻는 질문

관련 AI 소식