서버개발자로서 살아남기 - Rag & Vector search 정확도 높이기

개요

RAG는 LLM과 벡터 DB를 함께 활용해, 컨텍스트 길이 한계로 인한 LLM의 성능 저하를 보완하는 아키텍처다.

 

현재 CS 관련 업무를 진행하면서, RAG의 기반이 되는 벡터 DB에 어떤 형태로 데이터를 저장하는 것이 가장 효과적인지에 대해 GPT와 함께 얘기 나눠봤다.

 

실험한 데이터 구성 방식은 크게 세 가지

• 질문만 저장
• 답변만 저장
• 질문 + 답변 함께 저장

이 세 가지 방식 중 어떤 구성이 실제로 가장 좋은 성능을 내는지 비교·검증해보았다.

vector search

대부분의 튜토리얼/가이드 구조는 아래처럼 되어있다.

1. KB(문서/가이드/FAQ)를 chunk로 나눔
2. 각 chunk(= “답이 들어있는 텍스트 조각”)를 임베딩 → 벡터DB에 저장
3. 유저 질문이 오면:
   • 질문을 임베딩
   • 이 벡터를 쿼리로 해서 “가장 비슷한 chunk 벡터”를 찾음
4. 찾은 chunk(문장/문단)를 LLM에 넣어서 답변 생성

 

케이스별로 비교

① 질문만 임베딩 (Question-only)

구조

• 벡터DB에 저장:
  • vector = 정형 질문 문장 임베딩
  • payload = 질문, 답변, 메타데이터
• 검색:
  • 유저 질문 → 임베딩 → “정형 질문 벡터들” 중 가장 가까운 것 찾기

장점

• 구조가 직관적:
  “유저 질문이 어떤 정형 질문에 가장 가까운가?”
• canonical 질문 세트가 정말 잘 설계돼 있으면 꽤 잘 동작
• 벡터 하나(질문)만 관리하니 단순

단점

• 정형 질문에 표현되지 않은 내용을 잡기 어려움
  • 실제 유저 질문이 FAQ 질문이랑 말투/구성이 많이 다르면 성능 떨어질 수 있음
• 답변 텍스트에만 나오는 키워드/도메인 용어들을 못 활용
• 나중에 길고 복잡한 가이드 문서(섹션, 표, 예외 케이스 등)까지 커버하고 싶어지면, 질문만으로는 한계

질문만 임베딩하는 방식은 기존에 사용하던 FAQ 시스템과 매우 유사하게 동작한다.

질문 텍스트만 벡터로 저장하다 보니, 순수 FAQ 챗봇 용도로는 그럭저럭 활용 가능하지만, RAG 기반의 QA 챗봇 관점에서는 활용 범위가 꽤 제한적이다.

또 하나의 여러 개의 짧은 질문 데이터가 벡터 DB에 들어가다 보니, 특정 질문에 대해서는 유사도 스코어가 아주 높게 매칭되지만, 다양한 데이터셋으로 테스트한 결과 저점이 심각하다.

 

② 답변만 임베딩 (Answer-only)

구조

• 벡터DB에 저장:
  • vector = 답변 텍스트(또는 핵심 문단) 임베딩
  • payload = question, answer, category, service, lang …
• 검색:
  • 유저 질문 → 임베딩
  • “답변 벡터들” 중에서 가장 비슷한 것 가져오기
  • payload.answer를 그대로 쓰거나 LLM에 넣어서 리라이팅

장점

• RAG 패턴이랑 그대로 align:
  • “답이 들어있는 텍스트 조각”을 찾는 구조
• 질문이 템플릿과 많이 달라도,
  답변 텍스트에 있는 용어/표현과 의미적으로 맞으면 잘 매칭됨

단점

• 질문 문구를 그대로 활용하진 않아서,
  “정형 질문 제목으로 리스트 보여주기” 같은 UI엔 조금 덜 직관적
• 하지만 payload에 question을 같이 넣어두면 해결됨

장점에도 나왔지만 실제로 유저가 궁금해하는건 답변 내용이다. 즉 답변에 나온 키워드/표현/설명이 더 잘 맞는다.

유저 QA 챗봇인 경우 가장 무난한 기본값이다.

 

 

③ 질문 + 답변을 합쳐서 하나로 임베딩 (Q + A concat)

이건 ②의 변형인데, 임베딩용 텍스트를 이렇게 만드는 방식:

[Q] 해지 및 환불은 어떻게 하나요?

[A] 안녕하세요, ~~~입니다. 환불, 해지 방법 안내해 드립니다. ...

이 통째 텍스트를 한 번에 임베딩해서 하나의 벡터로 저장.

 

장점

• 질문에 나오는 표현 + 답변에 나오는 표현을 다 같이 반영
• 유저 질문이 정형 질문이랑 비슷하면 Q 부분이 도움되고,
  좀 다른 표현을 쓰더라도 A 부분 내용으로 보완
• 벡터는 여전히 “하나”라서 설계는 단순

단점

• 텍스트가 너무 길면 임베딩 비용/속도가 조금 더 들 수 있음
  (하지만 FAQ 답변 정도 길이면 큰 문제는 아님)

질문과 답변을 합쳐서 임베딩하는 형태인데, 단점에서 나온 임베딩 비용 속도가 크지 않다.

도메인에 따라 다르겠지만, 일반적으로 유저들은 길게 질문하는걸 선호하지 않는다.

실제로 테스트 시, 3가지 패턴 중 평균적으로 가장 유사도가 높았다.

결론

도메인에 따라 다르겠지만, 질문과 답변을 합쳐서 임베딩 하는 형태가 가장 적절한 형태의 답변을 찾아줄 것이다.