이번 행사 글 대부분에 RAG가 나옵니다. S3 Vectors는 RAG용 저장소로, Foundry IQ는 RAG를 "한 번 찾기"에서 "따져 보며 찾기"로 바꾸겠다고 했습니다. 너무 자주 나와서 오히려 정의를 건너뛰고 읽게 됩니다. 원래 무엇을 풀려던 방법인지, 그리고 검색 품질을 올리는 하이브리드 검색이 무엇인지 정리해 둡니다.
RAG가 풀려던 문제
RAG라는 이름은 2020년 Lewis 등의 논문 "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"에서 나왔습니다.
초록이 짚는 문제는 두 가지입니다.
- 언어 모델은 사실 지식을 파라미터 안에 저장하지만, 그 지식에 정확히 접근하고 다루는 능력은 제한적이다.
- 답의 출처를 보여 주는 일과 지식을 최신으로 바꾸는 일은 아직 풀리지 않았다.
해법은 메모리를 둘로 나누는 것입니다. 모델 가중치에 담긴 지식(파라메트릭 메모리)에, 바깥에서 꺼내 볼 수 있는 문서 색인(비파라메트릭 메모리)을 붙입니다. 논문에서는 위키피디아를 밀집 벡터 색인으로 만들고, 신경망 검색기로 관련 문단을 찾아 생성에 넣었습니다.
비유하면 오픈북 시험입니다. 외운 것만으로 답하지 않고, 책을 펴서 찾은 뒤 답합니다. 책을 바꾸면 모델을 다시 학습하지 않아도 답이 바뀝니다. 어느 쪽을 펴 봤는지도 보여 줄 수 있습니다.
그래서 검색이 반이다
RAG의 답은 찾아온 문단보다 좋아질 수 없습니다. 엉뚱한 문단을 찾으면 모델은 엉뚱한 근거로 그럴듯하게 답합니다.
그런데 검색 방식마다 약점이 다릅니다.
| 방식 | 잘 찾는 것 | 놓치는 것 |
|---|---|---|
| 키워드 검색 | 제품명, 오류 코드, 고유명사처럼 글자가 정확히 맞는 것 | 같은 뜻의 다른 표현 ("램이 늘어남" ↔ "메모리 누수") |
| 벡터 검색 | 표현이 달라도 뜻이 가까운 것 | 드물게 나오는 정확한 단어, 숫자, 코드 |
둘을 같이 돌려 결과를 합치는 것이 하이브리드 검색입니다.
섞는 법 1: 점수를 섞는다
가장 직관적인 방법은 두 점수에 가중치를 주고 더하는 것입니다.
이 블로그의 검색이 이렇게 합니다. 검색 개선 글에 적은 대로, 단어 점수와 의미 점수를 0~1로 맞춘 뒤 반씩 더합니다.
const sem = clamp((cos - 0.40) / (0.65 - 0.40), 0, 1);
const score = 0.5 * lex + 0.5 * sem;
문제는 0.40, 0.65, 0.5 같은 숫자입니다. 키워드 점수와 코사인 유사도는 단위가 달라서, 같은 눈금으로 맞추는 기준을 직접 정해야 했습니다. 임베딩 모델을 바꾸면 이 숫자도 다시 맞춰야 합니다.
섞는 법 2: 순위만 쓴다 (RRF)
**RRF(Reciprocal Rank Fusion)**는 점수를 아예 보지 않습니다. 각 검색 결과에서 몇 위였는지만 씁니다.
Elasticsearch 문서의 식은 이렇습니다. 문서마다, 각 결과 목록에서의 순위로 다음 값을 더합니다.
score = Σ 1 / (k + rank)
k는 상수이고 기본값은 60입니다. 키워드 검색에서 1위, 벡터 검색에서 3위인 문서라면 1/61 + 1/63을 받습니다. 한쪽에만 나온 문서는 한 항만 받습니다.
문서가 꼽는 장점은 튜닝이 필요 없다는 것입니다. 점수 단위를 맞출 필요가 없으니, 서로 관계없는 지표끼리도 합칠 수 있습니다. k를 키우면 아래 순위 문서의 영향이 커집니다. 각 검색에서 몇 개를 가져와 합칠지는 rank_window_size로 정합니다.
둘 중 무엇을 쓸까
RRF는 손댈 숫자가 거의 없어서 시작점으로 좋습니다. 대신 "1위가 압도적으로 확실하다" 같은 점수의 크기 정보는 버립니다.
점수 섞기는 그 크기를 쓸 수 있지만, 기준값을 평가 세트로 맞춰야 합니다. 이 블로그는 질문 32개짜리 평가 세트로 결과를 재며 기준값을 정했습니다. 평가 세트가 없다면 RRF부터 쓰고, 평가 세트를 만든 뒤 바꿔 보는 순서가 안전해 보입니다.
어느 쪽이든 조건 필터를 붙이면 결과가 모자랄 수 있다는 점은 따로 확인해야 합니다.
