RAG 검색 개선을 위한 2가지 방법: 실제 고객 사례 연구

대부분의 RAG 조언은 에이전트 기반 RAG(agentic RAG), 다단계 추론(multi-hop reasoning), 이국적인 재순위 지정 파이프라인 등 유행하는 것들로 귀결됩니다. 하지만 많은 경우, 검색 오류를 수정하는 실제 해결책은 그보다 훨씬 간단합니다. 이것은 고객 프로젝트에서 나온 실제 사례 연구인데, 여기서 두 가지 간단한 변경 사항만으로 재현율(recall)을 약 50–60%에서 95%+까지 끌어올렸습니다. 모델이나 청크 분할 전략을 건드리거나 유행하는 기술을 찾지 않고도 말입니다.

참고로, **재현율(Recall)**은 검색 시스템이 주어진 질의에 대해 실제로 올바른 문서들을 얼마나 자주 찾아내는지를 측정합니다. 이는 RAG 품질에서 가장 큰 레버리지라고 할 수 있습니다. 아무리 다운스트림 프롬프트 엔지니어링을 해도 처음부터 적절한 컨텍스트를 받지 못한 LLM은 고칠 수 없기 때문입니다.

시스템 구성 (The Setup)

이것은 고객 서비스 직원을 위한 상당히 표준적인 내부 RAG 챗봇이었습니다. 회사 시스템 전반에 걸쳐 정보를 더 빨리 찾도록 돕기 위해 구축되었습니다. 파이프라인은 일반적인 형태를 따랐습니다: 소스 시스템에서 데이터를 가져와(pull data), 청크로 분할하고, 임베딩을 생성한 다음, 모든 것을 벡터 인덱스(이 경우 Azure AI Search)에 로드하고, 관련 청크를 검색하여 답변을 생성하는 챗봇을 연결했습니다.

도메인은 스파 및 웰니스 서비스였습니다. 두 가지 주요 문서 유형은 다음과 같습니다:

• 장소 (Locations) — 이용 가능한 트리트먼트, 마사지, 장비를 다루는 설명과 함께 도시 및 지역이 포함된 스파와 체육관
• 전문가 (Experts) — 마사지 치료사, 개인 트레이너 등, 제공하는 서비스에 대한 설명이 포함된 전문가

표준 인덱싱 접근 방식: 모든 텍스트 필드(설명, 도시, 지역)를 하나의 content 필드로 결합하여 전체 텍스트 검색을 수행하고, 동일한 필드의 임베딩을 생성하여 벡터 검색을 수행했습니다.

문제점 (Where It Broke)

사용자 질의는 _

벡터 검색(Vector search)은 이 사용 사례에는 부적합했습니다. 이는 모호하고 의미적인 매칭에 최적화되어 있어, 개념적으로 관련된 결과를 원할 때는 훌륭하지만, 특정 서비스와 특정 도시에 대한 정확한 일치가 필요할 때는 오히려 도움이 되지 않습니다. 벡터 검색은 다른 유형의 마사지나 헬싱키(Helsinki)와 의미적으로 가까운 다른 도시들(다른 핀란드 수도권, 같은 지역의 다른 도시)을 기꺼이 반환할 것이며, 이는 사용자가 실제로 요청한 바가 아닙니다.

BM25(전체 텍스트 검색)가 더 나았지만, 여전히 충분하지 않았습니다. 그 이유는 좀 더 미묘합니다. BM25는 용어 빈도에 따라 순위를 매기기 때문입니다. 모든 마사지 유형을 제공하지 않는 장소를 상상해 보세요. 스웨디시 마사지를 제외한 곳이라면, 설명에

동시에 벡터 임베딩(vector embedding) 필드는 완전히 제외되었습니다. 이 사용 사례에서는 정확히 일치하는 검색이 필요했기 때문에, 생성하고 저장하는 데 비용을 지불할 이유가 없었습니다.

수정 사항 #2: 인덱스뿐만 아니라 쿼리 구조화하기

두 번째이자 더 큰 변화는 쿼리 측면에서 발생했습니다. 사용자의 원시 자연어(raw natural-language) 쿼리를 검색 인덱스에 직접 실행하는 대신, LLM이 먼저 쿼리를 구조화된 필터로 구문 분석합니다.

"헬싱키의 스웨디시 마사지(Swedish massage in Helsinki)"는 다음과 같은 형태로 변환됩니다:

{
  "city": "Helsinki",
  "services": ["Swedish massage"]
... 

이렇게 구조화된 쿼리가 실제 필터로 실행됩니다 — city == "Helsinki" AND services contains "Swedish massage" — 모호한 텍스트 매칭이나 벡터 매칭 대신입니다. 이는 근사적인 관련성 점수(approximate relevance scoring)가 아니라 정확하고 정밀한 필터링이며, 이 사용 사례가 필요로 했던 바로 그것이었습니다.

결과

두 가지 변경 사항을 거친 후, 올바른 문서 검색률은 다음 사용자 테스트 라운드에서 100%에 육박하는 수치를 기록했습니다. 이는 원래의 50~60%에서 향상된 것입니다. 당시 팀은 정확한 재현율(recall) 수치(피드백을 더 질적으로 평가하고 있었기 때문에)를 가지고 있지는 않았지만, 변화는 명확했습니다. 사용자들이 이전에 제기했던 거의 모든 검색 관련 불만 사항이 사라졌고, 오직 소수의 엣지 케이스(edge cases)만이 남았는데, 이는 주로 근본적인 데이터 품질 문제로 인해 발생했으며 별도로 처리되었습니다.

트레이드오프(Tradeoffs)

여기에는 공짜가 아니었습니다:

트레이드오프(Tradeoffs)

여기에는 공짜가 아니었습니다:

• 인덱싱 비용 증가. 이제 모든 문서는 인덱스 시간에 서비스를 추출하기 위해 LLM 호출을 거칩니다. 수백 명의 내부 사용자를 지원하고 그들에게 실시간으로 도움을 주는 도구의 경우, 이 비용은 쉽게 정당화될 수 있었지만, 실제로 고려해야 할 지속적인 비용입니다.
• 쿼리 지연 시간 약간 증가. 쿼리를 구조화하는 과정에는 검색이 일어나기 전에 추가 LLM 호출이 필요합니다. 실제로는 이 단계를 위해 더 작고 빠른 모델을 사용하여 완화했습니다. 입력(짧은 사용자 쿼리)과 출력(작은 구조화된 필터) 모두 매우 작았기 때문에, 추가 지연 시간은 전체 검색 및 생성 흐름에 비해 미미했습니다.

가장 중요한 시사점 (The Bigger Takeaway)

항상 에이전트 기반 RAG(agentic RAG), 다단계 검색(multi-hop retrieval) 또는 최신 연구 논문에서 제안하는 모든 것을 필요로 하는 것은 아닙니다. 때로는 해결책이 훨씬 더 평범합니다. 즉, 사용자가 실제로 무엇을 요청하고 있는지 명확하게 살펴보고, 그에 맞춰 검색 방법을 조정해야 합니다. 여기서는 쿼리가 근본적으로 정확 일치 조회(특정 서비스, 특정 도시)였지만 자연어처럼 포장되어 있었습니다. 따라서 적절한 해결책은 더 화려한 시맨틱 검색이 아니라 구조화된 필터링이었습니다.

또한 주목할 만한 좋은 대칭성이 있습니다: RAG는 검색으로 증강된 생성(retrieval-augmented generation)을 의미하며, 검색을 사용하여 LLM 출력을 개선하는 것입니다. 하지만 이는 반대 방향으로도 작동합니다. 여기서는 LLM을 사용하여 _검색 자체_를 더 좋게 만들었습니다. 즉, 인덱스 시간에 구조화된 메타데이터를 추출하고, 검색 시점에 쿼리를 구조화한 것입니다. 두 방향 모두 여러분의 도구 상자에 갖추는 것이 가치가 있습니다.

_만약 RAG 시스템의 문제가