벡터 데이터베이스

검색은 오래 글자 맞추기였습니다. 사용자가 입력한 말이 문서에 들어 있으면 찾고, 없으면 못 찾습니다. 같은 뜻을 다른 말로 적으면 그 문서는 없는 것이 됩니다.

페이지덱 도움말에서 이 한계가 숫자로 드러났습니다. 검색 기록을 훑어 보니 결과가 0건인 검색이 전체의 40퍼센트였고, 그중 대부분은 문서가 실제로 있는 주제였습니다. 사용자는 "연차 어떻게 신청해요" 라고 쳤고 문서 제목은 "휴가 신청 절차" 였습니다. 두 문장에 겹치는 글자가 없어서 검색이 아무것도 내놓지 못했습니다.

여기서 필요한 것은 글자가 아니라 뜻으로 비교하는 방법이었습니다. 문장을 숫자 목록으로 바꿔 두면 뜻이 가까운 문장끼리 숫자도 가까워진다는 것이 임베딩의 발상입니다. 임베딩은 뜻을 숫자 벡터로 바꾼 표현을 말합니다. 연차와 휴가는 글자가 다르지만 숫자로 바꾸면 가까운 자리에 놓입니다.

문제는 그다음이었습니다. 문서 조각이 50만 개면 질문 하나마다 50만 번을 비교해야 하고, 한 번의 비교가 숫자 1,536개를 맞춰 보는 일입니다. 일반 데이터베이스에서 매번 전부 훑으면 검색 한 건에 몇 초가 걸립니다.

뜻으로 찾는 검색을 실제로 쓸 수 있는 속도로 만드는 것이 이 도구의 몫입니다. 안에서 하는 일은 넷입니다.

1. 벡터를 벡터로 저장합니다. 숫자 1,536개짜리 목록이 한 줄이고, 그 줄에 원본 문서 조각과 출처가 함께 붙습니다. 일반 데이터베이스에 넣으면 숫자 배열 한 덩어리로 취급되어 비교에 쓸 색인을 만들 수 없습니다.
2. 전부 비교하지 않고 찾습니다. 근사 최근접 이웃이라고 부르는 색인을 미리 만들어 후보를 줄인 다음 그 안에서만 비교합니다. 근사가 붙은 것은 가장 가까운 것을 놓칠 가능성을 조금 받아들인다는 뜻입니다. 50만 개를 전부 훑어 3초 걸리던 검색이 20밀리초가 됩니다. 정확도는 95퍼센트대로 떨어지는데, 상위 다섯 개를 보여 주는 용도에서는 거의 드러나지 않습니다.
3. 조건과 함께 찾습니다. 이 고객사 문서만, 최근 1년 문서만 골라야 하는 경우가 대부분입니다. 멀티테넌시 구조에서는 안전 장치이기도 합니다. 멀티테넌시는 여러 고객사가 한 시스템을 나눠 쓰는 구조인데, 조건이 빠지면 다른 고객사 문서가 결과에 섞입니다.
4. 넣고 지우는 것을 계속 받습니다. 문서가 고쳐지면 그 조각의 벡터도 바뀝니다. 색인을 다시 만드는 비용이 큰 방식과 조금씩 갱신하는 방식이 나뉘니, 문서가 자주 바뀌면 이 성질을 먼저 봅니다.

이 넷이 갖춰지면 RAG 배관이 성립합니다. RAG는 외부 자료를 찾아 붙여 모델이 답을 만들게 하는 방식입니다. 문서를 잘라 벡터로 넣어 두고, 질문이 오면 질문도 벡터로 바꿔 가까운 조각을 꺼내 모델에 건넵니다.

전용 제품을 쓰는 것이 유일한 길은 아닙니다. 건수와 지연 요구에 따라 넷 중에서 고릅니다.

1. 지금 쓰는 데이터베이스에 확장을 붙입니다. 관계형 데이터베이스는 표와 관계로 데이터를 저장하는 방식인데, 벡터 확장을 설치하면 같은 곳에서 유사도 검색이 됩니다. 조각이 수십만 개까지는 충분하고 운영할 시스템이 늘지 않습니다.
2. 전용 벡터 데이터베이스를 따로 둡니다. 조각이 수백만 개를 넘거나 지연을 몇십 밀리초로 묶어야 할 때 값을 합니다. 대신 원본과 벡터가 두 곳에 나뉘어 동기화 문제가 생깁니다.
3. 검색 엔진 제품에 붙은 벡터 기능을 씁니다. 이미 전문 검색을 위해 검색 엔진을 운영하고 있다면 글자 검색과 뜻 검색을 한 곳에서 돌릴 수 있습니다.
4. 글자 검색을 그대로 씁니다. 제품 코드, 사람 이름, 계약 번호처럼 정확히 일치해야 하는 검색에서는 뜻으로 찾는 방식이 오히려 나쁩니다. 두 방식을 함께 돌려 결과를 섞는 쪽이 한쪽만 쓰는 것보다 잘 동작하는 경우가 많습니다.

고르는 기준은 셋입니다. 조각 수, 허용 지연, 시스템을 하나 더 운영할 사람이 있는지입니다. 1번으로 시작해 한계에 부딪힌 뒤 옮기는 편이 덜 듭니다.

"일단 쓰는 데이터베이스에 벡터 확장 붙여서 해 보죠. 조각 8만 개면 충분합니다."

전용 제품 없이 시작할 수 있는 규모라는 판단입니다.

"검색은 20밀리초인데 임베딩 만드는 데 400밀리초 걸려요."

병목이 데이터베이스가 아니라 벡터로 바꾸는 단계에 있다는 지적입니다.

"고객사 조건을 안 걸고 검색해서 다른 회사 문서가 나왔습니다."

조건 필터가 빠져 격리가 깨졌다는 뜻입니다.

페이지덱은 도움말 검색에 이 방식을 붙였습니다. 태오가 문서 400개를 문단 단위로 잘라 8,000개 조각을 만들고, 기존 데이터베이스에 확장을 설치해 넣었습니다. 결과가 0건인 검색 비율이 40퍼센트에서 6퍼센트로 떨어졌습니다.

남은 6퍼센트를 지현이 보니 대부분 기능 이름을 정확히 쳤는데 문서에 그 이름이 없는 경우였습니다. 뜻으로도 안 잡히는 자리라 문서를 고쳐야 했고, 그래서 검색 실패 목록을 문서를 늘리는 근거로 쓰기로 했습니다.

이 도구를 넣으면 검색이 좋아진다고 읽는 경우가 가장 많습니다. 뜻으로 찾는다는 설명이 결과 품질을 약속하는 것처럼 들립니다. 하지만 이 저장소가 하는 일은 주어진 벡터끼리 가까운 것을 빠르게 찾아 주는 것뿐입니다. 결과 품질은 어떤 모델로 벡터를 만들었는지와 문서를 어떤 크기로 잘랐는지가 정합니다. 문서 하나를 통째로 한 벡터로 만들면 뜻이 뭉개져 무엇을 검색해도 그 문서가 나옵니다.

글자 검색을 대체한다고 보는 것도 흔합니다. 뜻으로 찾는 쪽이 더 나중에 나온 방식이니 그렇게 보입니다. 하지만 둘은 잘하는 자리가 다릅니다. 계약 번호나 오류 코드처럼 한 글자만 달라도 다른 것을 찾을 때는 글자 맞추기가 정확하고, 뜻으로 찾으면 비슷하게 생긴 다른 번호를 내놓습니다. 그래서 실제 제품은 두 방식을 함께 돌려 점수를 합쳐 정렬합니다.