RAG 검색 개선기: 한국어 검색엔 한국어 임베딩 모델

썸네일이 좀 맘에 안들긴한데..

 

한동안 검색을 들여다보다 구멍을 하나 발견했다.

 

한국어 검색인데, 외래어가 섞인 질의가 자꾸 헛돌았다. 예를 들어 "스마트 팩토리"로 찾으면, 정작 스마트 팩토리를 다루는 문서가 위로 안 올라오고 엉뚱한 게 섞였다. "작년 회의 자료" 같은 평범한 한국어 질의는 멀쩡한데, 이렇게 영어에서 온 말이 한글로 적힌 구간에서만 새는 현상이 있었다.

 

문제의 원인을 찾는건 그렇게 어렵지 않았는데, 검색의 초기 버전이 임베딩 모델에 전적으로 의존하고 있었기 때문이다.

그때 쓰던 건 범용 다국어 임베딩이었다. 여러 언어를 두루 하는 모델. 검색 성능을 조금 더 올리고 싶던 참이라, 이번엔 임베딩 모델 자체를 손대보기로 했다. 한국어에 특화된 임베딩으로.

 

이 글은 RAG 구축 고려사항의 임베딩 모델 항목에 해당하는, 성능을 한 끗 올린 이야기다. (임베딩이 뭔지는 지난 글에서 다뤘다. 임베딩 차원·데이터셋 같은 얘기는 임베딩을 본격적으로 다룰 다음 글로 미룬다.)

1. 왜 외래어에서 샜나 — 그리고 왜 처음엔 티가 안 났나

먼저 왜 외래어가 약했는지부터. 범용 다국어 임베딩은 "smart factory"(영어)도 알고 "스마트 팩토리"(한글 표기)도 대충 안다. 문제는 그 한글 표기 외래어를 원래 개념에 딱 붙이는 힘이 무뎠다는 것이다. 조금 더 파고들면 이렇다.

 

이런 모델은 정해진 표현력(파라미터)을 수십 개 언어에 나눠 담는다. 그러다 보니 한글로 적힌 외래어는 원어인 "smart factory"와도, 순우리말로 된 한국어 문맥과도 어중간하게 떨어진 자리에 놓인다. 어느 쪽에도 확실히 소속되지 못한 애매한 위치인 셈이다. 그래서 "스마트 팩토리" 질의가 살짝 엉뚱한 쪽으로 흘렀다.

 

그럼 한국어 특화 모델로 바꾸면 되겠네 싶어, 두 모델을 붙여봤다 — 범용 쪽은 작고 빠른 다국어 임베딩, 특화 쪽은 한국어에 튜닝된 bge-m3-ko-q8이다. 다국어 임베딩으로 널리 쓰이는 bge-m3를 한국어에 맞춰 손보고, 온디바이스로도 돌릴 수 있게 8비트로 양자화한(q8) 판이라 골랐다.

 

그런데 첫 결과가 김이 빠졌다. 거의 똑같이 나왔다.

쉬운 평가셋 (100문항)      MRR
범용 임베딩               0.876
한국어 특화               0.874

0.876 대 0.874. 오차 수준이다. "어, 모델 차이가 없나?" 싶었는데, 파보니 문제는 모델이 아니라 평가셋이었다. 그 세트가 너무 쉬웠던 것이다. 질의의 단어가 문서에 그대로 들어 있는 경우(exact match)가 많아서, 어떤 임베딩을 쓰든 다 맞혔다. 정답 단어가 문서에 그냥 박혀 있으면, 임베딩의 미세한 품질 차이가 드러날 틈이 없다.

 

이건 평가셋 글에서 배운 걸 다시 확인한 셈이었다 — 쉬운 평가셋은 문제도, 모델 차이도 가려버린다. 정작 내가 겪던 외래어 구멍은 어려운 질의에서 났는데 세트는 쉬운 질의로 차 있었으니, 차이가 안 보일 수밖에 없었다.

2. 언어 특화로 바꾸니 '분별력'이 달랐다

점수가 같아 보인다고 두 모델이 같은 건 아니었다. 그걸 확인하려고, 점수 대신 임베딩 공간 자체를 들여다봤다.

 

한국어 단어들을 의미가 통하는 것끼리 여러 의미 그룹으로 묶어놓고(이를테면 '공장·설비·생산'을 한 묶음, '회의·일정·보고'를 다른 묶음 식으로), 같은 그룹 안의 단어끼리 얼마나 가까운지(코사인 유사도)와 다른 그룹의 단어와는 얼마나 먼지를 재봤다. 좋은 임베딩이라면 같은 그룹은 바짝 붙이고 다른 그룹은 밀어내야 한다.

 

그 벌어진 폭이 곧 "분별력"이다.

                 그룹 안    그룹 밖    벌어진 폭(gap)
범용 임베딩       0.79       0.73       0.06     ← 다 비슷하게 붙어 있음
한국어 특화       0.42       0.31       0.12     ← 거리를 더 벌림

숫자를 보면 성격이 확 갈린다. 범용 모델은 모든 게 0.7대로 조밀하게 붙어 있다 — 비슷한 말이든 상관없는 말이든 죄다 0.7 언저리라, 둘의 차이가 0.06밖에 안 난다. "비슷한 것"과 "다른 것"을 가를 여백이 좁은 것이다.

 

반면 한국어 특화 모델은 같은 그룹은 붙이고(0.42) 다른 그룹은 더 밀어내서(0.31), 그 폭이 0.12로 두 배쯤 벌어진다. 절대값 자체는 범용보다 낮지만, 중요한 건 절대값이 아니라 _벌어진 폭_이다. 특화 모델이 "비슷한 것과 다른 것"을 더 자신 있게 갈랐다.

 

비유하면 이렇다. 둘 다 시험 답은 맞혔는데, 한쪽은 "어… 아마 이거?" 하고 애매하게 맞히고, 한쪽은 "이거랑 저건 확실히 다르지" 하고 딱 갈라 맞힌 것이다. 쉬운 문제에선 둘 다 맞으니 점수가 같지만, 헷갈리는 문제에선 이 자신감의 차이가 정답률로 나타난다.

그래서 이번엔 평가셋을 일부러 어렵게 다시 짰다.

 

정답 단어가 문서에 그대로 나오는 경우(exact match)를 빼고, 다른 표현으로 바꿔 쓴 것(의역)만 정답으로 두고, 외래어가 섞인 헷갈리는 질의를 넣었다. 그제서야 차이가 드러났다.

어려운 셋 (exact 제거·의역·외래어 포함)   Recall@1  Recall@3  Recall@5    MRR
범용 임베딩                              0.17      0.53      0.67      0.378
한국어 특화                              0.18      0.61      0.75      0.420

Recall@3·Recall@5·MRR, 전 지표에서 한국어 특화가 앞섰다.

 

그리고 실제로, 그토록 새던 외래어 검색이 눈에 띄게 나아졌다. "스마트 팩토리"가 스마트 팩토리 문서를 데려오기 시작한 것이다.

트레이드오프?

트레이드오프라고 할 만한 건 오히려 이걸 일반화할 때 드러난다. 성능을 끝까지 짜내려면, 결국 언어마다 그 언어에 특화된 모델을 따로 써야 할 수도 있다.

 

범용 임베딩 하나면 여러 언어를 한 방에 처리하는 단순함이 있는데, 특화로 가는 순간 그 단순함을 내주고 '언어별로 최고를 골라 관리하는' 몫을 떠안는다. 한국어에 몰린 검색이라면 고민할 것도 없이 특화가 맞지만, 여러 언어를 두루 받아야 한다면 범용 하나의 편함*과 *언어별 특화의 성능 사이에서 저울질이 생긴다.

 

하지만 언어 특화 모델도 만능은 아니다. 외래어를 개념에 붙이는 힘이 좋아졌다곤 해도 100%는 아니어서, 신조어나 도메인 전문용어, 같은 개념을 제각각으로 적는 표기 흔들림 앞에선 여전히 헛도는 구간이 남는다.

 

그래서 임베딩 하나로 전부 메우려 하기보다, 임베딩이 놓치는 자리를 다른 장치로 받쳐주는 편이 낫다 — 외래어·동의어를 하나의 개념으로 묶어주는 용어 사전을 두거나, 용어와 개념의 관계를 노드 그래프로 엮어 검색을 보강하는 식으로.

# 용어 사전 — 표기가 흔들려도 한 개념으로 묶어준다
스마트 팩토리  ≡  스마트팩토리 · smart factory · 스마트공장
RAG           ≡  검색증강생성 · retrieval-augmented generation

실무에서 손대는 순서도 대개 값이 싼 쪽부터다 — 용어 사전과 하이브리드(키워드+임베딩) 검색으로 큰 구멍을 먼저 싸게 메우고, 관계 추론이 진짜 필요한 도메인에서만 노드 그래프까지 간다. 임베딩 교체는 그중 손이 가장 덜 가는 한 수였을 뿐이다.

마치며

돌아보면 이 교체는 드문 경우였다 — 딱히 값을 치를 게 없었다. 검색을 개선하다 보면 보통 뭔가를 내줘야 하는데(리랭커는 지연을, 하이브리드는 임베딩 비용을 치렀듯이), 범용에서 한국어 특화로 옮기는 건 그 한국어+외래어 용도에선 거의 공짜에 가까운 개선이었다.

 

굳이 이 케이스에서 값을 꼽자면, 이득이 외래어·의역 같은 어려운 구간에만 몰린다는 것과 벡터 차원이 커진다는 것 정도다(차원 얘기는 다음 글로 미룬다).

 

정리하면, 범용 임베딩으로 바닥을 깔고 그 위에서 한국어 특화 모델로 외래어 구멍을 메운 셈이다. 화려한 교체는 아니었지만, "한국어 검색이면 한국어를 더 잘 아는 모델"이라는 당연한 선택이 성능의 한 끗을 조용히 올려줬다.