검색 품질 높이기

좋은 답변은 좋은 검색에서 시작된다

RAG에서 모델은 검색된 문서를 보고 답합니다. 따라서 검색 결과가 틀리면 답변도 쉽게 틀어집니다. 아무리 좋은 LLM을 써도 질문과 관련 없는 청크를 넣으면 그럴듯하지만 부정확한 답이 나옵니다.

검색 품질을 높인다는 것은 단순히 더 많은 문서를 가져오는 일이 아닙니다. 사용자의 질문 의도를 파악하고, 그 의도에 맞는 문서 조각을 정확히 찾는 일입니다. 이때 한 가지 검색 방식만 믿으면 놓치는 정보가 생깁니다.

벡터 검색이 놓치는 것들

벡터 검색은 의미가 비슷한 문서를 찾는 데 강합니다. 예를 들어 "회원 탈퇴는 어떻게 해?"라는 질문은 문서에 "계정 삭제 절차"라고 적혀 있어도 잘 찾을 수 있습니다. 표현은 다르지만 의미가 가깝기 때문입니다.

하지만 벡터 검색은 정확한 단어가 중요한 상황에서 약해질 수 있습니다. 제품명, 코드명, 주문 번호, 날짜, 버전명처럼 글자 자체가 중요한 정보가 그렇습니다.

예를 들어 사용자가 "Plan-B-17 오류 해결 방법"을 찾는다고 해봅시다. 벡터 검색은 이 문장을 "오류 해결"이라는 넓은 의미로 이해해 비슷한 장애 대응 문서를 가져올 수 있습니다. 그러나 사용자가 원하는 것은 반드시 Plan-B-17이라는 식별자가 들어간 문서입니다. 이 경우 의미적으로 비슷한 문서보다 정확히 같은 단어가 포함된 문서가 더 중요합니다.

키워드 검색의 강점

키워드 검색은 단어 일치에 강합니다. 특정 제품명, API 이름, 함수명, 날짜, 문서 번호를 찾을 때 유용합니다. 사용자가 "2025년 3월 가격 정책"이라고 물었다면 2025, 3월, 가격 정책이 들어간 문서를 우선 찾아야 합니다.

대표적인 키워드 검색 방식으로 BM25가 있습니다. BM25는 검색어가 문서에 얼마나 잘 등장하는지, 너무 흔한 단어인지, 문서 길이는 어떤지를 함께 고려해 점수를 매깁니다. 쉽게 말해 "중요한 단어가 적절하게 들어 있는 문서"를 높게 평가합니다.

반면 벡터 검색은 Dense Retrieval이라고도 부릅니다. 문장과 문서를 임베딩 벡터로 바꾼 뒤 의미적으로 가까운 항목을 찾습니다. 표현이 달라도 의미가 비슷한 문서를 찾는 데 적합합니다.

Hybrid Search 설계하기

실전 RAG에서는 BM25와 벡터 검색을 함께 쓰는 Hybrid Search가 효과적입니다. 두 방식이 서로의 약점을 보완하기 때문입니다.

기본 구조는 단순합니다.

1. 사용자 질문을 받습니다.

2. 같은 질문으로 BM25 검색을 실행합니다.

3. 같은 질문을 임베딩해 벡터 검색을 실행합니다.

4. 두 결과를 합칩니다.

5. 중복 문서를 제거하고 점수를 재조정합니다.

6. 상위 결과를 LLM 프롬프트에 넣습니다.

예를 들어 "OAuth callback URL 설정 오류"라는 질문이 들어오면 키워드 검색은 OAuth, callback URL이 정확히 들어간 문서를 찾습니다. 벡터 검색은 "로그인 리다이렉트 설정", "인증 후 이동 주소"처럼 다른 표현으로 적힌 문서를 찾을 수 있습니다. 둘을 합치면 검색 범위가 넓어지면서도 핵심 단어를 놓치지 않습니다.

질문을 검색하기 좋은 형태로 바꾸기

사용자의 질문은 항상 검색에 적합한 형태로 들어오지 않습니다. "이거 왜 안 돼?"처럼 짧거나, "지난번에 말한 설정"처럼 맥락에 의존할 수도 있습니다. 그래서 검색 전에 질문을 다듬는 과정이 필요합니다.

Query Expansion은 질문에 관련 표현을 추가하는 방법입니다. "계정 삭제"라는 질문에 "회원 탈퇴", "사용자 삭제", "프로필 제거" 같은 동의어를 함께 검색하는 식입니다.

질의 재작성도 자주 씁니다. 사용자가 "요금제 바꾸는 법 알려줘"라고 물으면 검색용 질문을 "요금제 변경 방법, 플랜 변경 절차, 결제 설정 변경"처럼 바꿀 수 있습니다. 대화형 서비스라면 이전 대화도 반영해야 합니다. "그 기능은 어디서 켜?"라는 질문은 앞선 대화의 주제가 "알림 설정"이었다면 "알림 기능 활성화 위치"로 재작성해야 합니다.

다만 확장은 조심해야 합니다. 관련 없는 단어를 너무 많이 추가하면 검색 결과가 흐려집니다. 좋은 질의 개선은 질문의 의미를 넓히되, 사용자의 의도를 벗어나지 않습니다.

검색 실패 로그 분석하기

검색 품질은 한 번에 완성되지 않습니다. 실제 사용자의 질문과 검색 결과를 기록하고 실패 사례를 분석해야 합니다.

먼저 사용자의 질문, 검색된 문서, 최종 답변, 사용자의 피드백을 함께 저장합니다. 그다음 실패 원인을 나눠 봅니다. 질문에 중요한 키워드가 있었는데 검색이 놓쳤는지, 문서에는 답이 있지만 청킹이 잘못되어 흩어졌는지, 메타데이터 필터가 너무 강했는지 확인합니다.

예를 들어 사용자가 특정 버전의 기능을 물었는데 최신 문서만 검색되었다면 날짜나 버전 메타데이터 필터를 조정해야 합니다. 제품명을 검색했는데 일반 개념 문서만 나왔다면 키워드 검색 비중을 높여야 합니다. 질문이 짧아 의도가 불명확했다면 질의 재작성이나 추가 질문이 필요합니다.

좋은 RAG 시스템은 검색 방식을 고정하지 않습니다. 벡터 검색, 키워드 검색, 질의 개선, 로그 분석을 함께 사용해 계속 조정합니다. 좋은 답변은 결국 좋은 검색에서 시작됩니다.