임베딩

텍스트·이미지·코드를 숫자 목록(벡터)으로 바꾸는 기술로, 뜻이 비슷할수록 벡터끼리 가까워져 겹치는 글자가 없어도 같은 뜻의 문서를 찾을 수 있다. 키워드가 아니라 뜻으로 찾아야 할 때 쓰며, RAG 검색, 추천, 중복 문서 찾기가 모두 이 원리로 돌아간다.

RAG에서는 쪼개고, 벡터로 바꾸고, 꺼내 쓴다

가장 흔한 사용처는 RAG다. 문서를 적당한 크기로 쪼개 벡터로 만들어 벡터 DB에 넣어 둔다. 질문이 들어오면 질문도 같은 모델로 벡터로 바꾸고, 가장 가까운 조각 몇 개를 꺼내 LLM에 함께 넘긴다.

코드로는 API 호출 한 번이면 된다. 예를 들어 text-embedding-3-large에 텍스트를 보내 벡터를 받고, Pinecone이나 pgvector 같은 벡터 DB에 저장하면 된다. 이미지와 텍스트를 한 공간에 넣는 모델을 쓰면 "노을 지는 바다"라는 문장으로 사진도 찾을 수 있다.

모델은 한 번 고르면 계속 같은 것을 쓴다

모델은 API로 쓰는 방식과 오픈 모델을 직접 띄우는 방식이 있다. 벤치마크 점수만 보지 말고 한국어 지원, 차원 수, 비용을 함께 따져 고른다. 반드시 지킬 규칙은 하나다. 문서를 저장할 때와 검색할 때 같은 모델을 써야 한다. 모델을 바꾸면 저장해 둔 문서를 전부 다시 임베딩해야 한다.

벡터 DB 저장 비용은 차원 수에 비례한다. 1,536차원 벡터 100만 건이면 벡터만 약 6GB다.

정확한 문자열은 키워드 검색과 섞어서 찾는다

에러 코드나 모델명처럼 글자 그대로 맞아야 하는 검색에서는 임베딩이 약하다. 그래서 실제 검색 시스템은 대부분 키워드 검색과 벡터 검색 결과를 합치는 하이브리드 검색을 쓴다. 더 정확하게 하려면 벡터 검색으로 후보 수십 개를 넓게 뽑은 뒤, 리랭커로 질문과의 관련도를 다시 매겨 순서를 정한다.

검색이 엉망이면 쪼개는 방식부터 본다

문서를 너무 잘게 쪼개면 앞뒤 맥락이 빠진 벡터가 되고, 너무 크게 쪼개면 여러 주제가 섞여 흐릿한 벡터가 된다. RAG 답변이 엉뚱한 문서를 근거로 든다면 LLM을 바꾸기 전에 임베딩 모델과 쪼개는 방식부터 점검하는 게 먼저다.

문서 검색부터 추천까지, 가까운 벡터를 찾는 곳이면 쓴다

가장 흔한 건 사내 문서를 임베딩해 두고 질문에 맞는 근거를 꺼내는 RAG 챗봇이다. 같은 벡터를 그대로 추천이나 중복 찾기에도 다시 쓸 수 있다.