임베딩과 벡터 검색, 따라 해본 기록

 

RAG를 공부하다 보면 어느 설명에서나 "임베딩"이라는 단어가 먼저 튀어나옵니다.
처음에는 용어만 익숙해지고 실제로 무슨 일이 일어나는지는 와닿지 않았어요.
그래서 개념 설명을 읽고, 작은 예제를 따라 해보고, 그 내용을 기획자가 이해할 수준으로 다시 적어보기로 했습니다.
개발자가 아니라서 코드를 깊게 다루지는 않았고, 어떤 입력이 들어가서 어떤 출력이 나오는지 흐름을 확인하는 데 집중했습니다.

 

임베딩을 한 문장으로 말하면, 글의 의미를 숫자들의 나열(벡터)로 바꾸는 것입니다.
모델에 문장을 넣으면 수백에서 수천 개 정도의 숫자가 나오는데, 이 숫자들이 그 문장의 의미를 좌표처럼 나타냅니다.
핵심은 의미가 비슷한 문장일수록 좌표가 가깝게 놓이도록 만들어진다는 점이에요.

예를 들어 아주 단순하게 숫자를 세 개로 줄여서 상상해보겠습니다.
이건 실제 값이 아니라 이해를 돕기 위한 가정 예시입니다.
"예약을 취소하고 싶어요"가 (0.9, 0.1, 0.2), "예약 취소는 어떻게 하나요"가 (0.85, 0.15, 0.25)라면 두 점은 매우 가깝습니다.
반면 "주차할 수 있나요"가 (0.1, 0.9, 0.3)이라면 앞의 두 문장과는 멀리 떨어져 있겠죠.
실제로는 이 좌표가 훨씬 많은 차원으로 이루어져 있어서 사람이 직접 읽을 수는 없지만, 가깝고 먼 관계는 같은 원리로 작동합니다.

저는 이걸 "지도 위에 문장을 찍는다"고 이해하니까 훨씬 편했어요.
의미가 비슷한 문장은 같은 동네에 모이고, 전혀 다른 주제는 먼 동네에 찍힙니다.
그러면 검색이란 "질문이 찍힌 위치 근처에 있는 문장을 찾는 일"이 됩니다.

 

그럼 가깝다는 건 어떻게 계산할까요.
자주 쓰이는 방법 중 하나가 두 벡터가 가리키는 방향이 얼마나 비슷한지를 보는 코사인 유사도입니다.
수학을 깊게 알 필요는 없고, "두 벡터가 같은 방향이면 1에 가깝고, 상관없으면 0 근처"라는 감각 정도면 기획자에게는 충분하다고 느꼈어요.

검색 흐름을 순서대로 적으면 이렇습니다.
먼저 검색 대상이 되는 문서들을 미리 임베딩으로 바꿔서 저장해둡니다.
사용자가 질문하면 질문도 같은 방식으로 임베딩으로 바꾸고, 저장된 벡터들 중 가장 가까운 몇 개를 찾아옵니다.
이 몇 개가 "질문과 의미상 가까운 문서 조각"이고, 이것을 RAG에서 모델에게 근거 자료로 넘겨줍니다.

문서 양이 많아지면 모든 벡터와 일일이 거리를 재는 건 느려질 수 있어서, 이 과정을 빠르게 해주는 벡터 데이터베이스나 인덱스 방식이 따로 존재한다는 것도 알게 됐어요.
다만 어떤 제품을 쓸지는 규모와 비용에 따라 달라지는 문제라서, 지금은 개념 수준까지만 이해하기로 했습니다.

 

개념만 읽으면 금방 잊어버릴 것 같아서 아주 작은 예제를 따라 해봤습니다.
가상의 예약 서비스 FAQ 문장 열 개 정도를 준비하고, 각각을 임베딩으로 바꿔서 저장했습니다.
FAQ에는 취소 규정, 영업시간, 주차, 결제 방법, 예약 변경 같은 내용이 들어 있었어요.

그다음 "일정을 바꾸고 싶은데요"라는 질문을 넣어봤습니다.
FAQ 문장 중에는 "일정 변경"이라는 표현이 없고 "예약 시간 수정 방법"이라는 제목만 있었는데도, 가장 가까운 결과로 그 문장이 나왔습니다.
키워드 검색이었다면 "일정"과 "바꾸고"가 문서에 없어서 못 찾았을 가능성이 높아요.
의미로 찾는다는 게 이런 거구나 하고 처음으로 체감한 순간이었습니다.

반대로 어색한 결과도 있었습니다.
"주차 가능한가요"라고 물었더니 주차 안내가 잘 나왔지만, 두 번째 후보로 전혀 상관없는 결제 안내가 따라왔어요.
가까운 순서대로 몇 개를 가져오기만 하면 관련이 약한 문장도 섞여 들어올 수 있다는 걸 확인했습니다.
그래서 "상위 몇 개를 가져올지", "일정 점수 이하는 버릴지" 같은 기준이 필요하다는 것도 배웠어요.

 

두 방식은 어느 쪽이 더 낫다기보다 잘하는 일이 다르다고 정리했습니다.
키워드 검색은 정확한 단어, 예를 들어 상품 코드나 고유한 이름을 찾을 때 강합니다.
임베딩 검색은 표현이 달라도 뜻이 비슷한 문장을 찾는 데 강하고요.
그래서 실제 서비스에서는 두 방식을 함께 쓰는 경우도 많다고 읽었는데, 제가 직접 확인한 부분은 아니어서 참고 수준으로 적어둡니다.

한계도 분명했습니다.
임베딩은 의미가 가깝다는 것만 알려줄 뿐, 그 문장이 사실인지, 최신인지는 판단하지 못합니다.
숫자나 날짜처럼 정확성이 중요한 정보는 의미 검색만으로는 미세한 차이를 놓칠 수 있어요.
"화요일 휴무"와 "수요일 휴무"가 의미상 매우 가까운 문장으로 취급될 수 있다는 점은 예약 서비스에서 특히 조심해야 한다고 느꼈습니다.
또 문서를 어떤 단위로 잘라서 임베딩하느냐에 따라 결과가 크게 달라진다는 점도 있었는데, 이건 청킹 이야기라서 RAG 글에서 이어서 다루고 있습니다.

 

임베딩과 벡터 검색은 어려운 수학이라기보다 "의미를 위치로 바꿔서 가까운 것을 찾는" 단순한 아이디어라는 게 이번 실습의 가장 큰 수확이었습니다.
기획자 입장에서는 이 기술이 무엇을 잘하고 못하는지를 알아야 요구사항을 현실적으로 쓸 수 있다고 생각해요.

앞으로 더 확인해보고 싶은 것은 한국어 문장에서 결과가 얼마나 안정적인지, 테넌트별로 문서를 분리해서 검색할 때 어떤 구조가 안전한지입니다.
특히 테넌트 구조에서는 다른 업장의 문서가 검색 결과에 섞이면 안 되기 때문에, 이 부분은 별도로 더 공부해볼 계획입니다.