텍스트 임베딩 해설: 작동 원리 [+예시]

텍스트 임베딩의 기본 개념은 알고 있지만 이를 실제로 어떻게 활용해야 할지 궁금하다면 제대로 찾아오셨습니다. 이 글에서는 벡터, 토큰화, 유사도 계산을 자세히 살펴보고, 임베딩 모델 평가라는 깊은 주제까지 파고든 다음, 실제 활용 사례를 소개합니다.

텍스트 임베딩이란 무엇인가요?

텍스트 임베딩은 단어, 문장 또는 문서의 의미와 관계를 담아낸 수치 표현입니다. 텍스트 임베딩은 텍스트를 벡터, 즉 머신러닝 알고리즘이 처리하고 비교할 수 있는 숫자 배열로 변환하는 임베딩 모델을 통해 생성됩니다.

ML 엔지니어는 텍스트 임베딩을 사용해 소프트웨어 애플리케이션이 단어와 문장 사이의 관계를 인식하도록 돕고, 이를 통해 대량의 데이터를 더 쉽게 검색, 분류, 분석할 수 있게 합니다.

매일 수천 건의 지원 티켓이 들어온다고 가정해 보겠습니다. 고객들은 상상할 수 있는 온갖 문제를 보고하지만, 여러분은 이를 분류하고 레이블을 지정해야 합니다. 이 과정을 자동화하는 한 가지 방법은 사전 학습된 텍스트 임베딩 모델을 사용해 각 티켓을 벡터로 변환하는 것입니다.

예를 들어 두 고객이 다음과 같은 메시지를 보냈다고 해 보겠습니다:

• “구독료가 두 번 청구되었습니다”: [0.21, -0.47, 0.83, ...]
• “제 계정에 중복 결제가 있습니다”: [0.19, -0.45, 0.80, ...]

이해를 돕기 위해 단순화한 예시 벡터입니다.

두 고객은 서로 다른 단어를 사용했지만 같은 문제를 설명하고 있습니다. 임베딩 모델은 두 벡터를 수학적 공간에서 서로 가까운 위치에 배치함으로써 이 관계를 포착합니다. 그 결과 두 티켓은 같은 범주로 분류되어 결제 팀으로 전달됩니다.

비즈니스에서의 텍스트 임베딩 활용 사례

텍스트 임베딩은 다음을 비롯한 다양한 자연어 처리(NLP) 작업에 사용됩니다:

• 시맨틱 검색: 의미를 기반으로 관련 정보를 찾습니다. Delivery Hero는 키워드 검색과 함께 상품 및 쿼리 임베딩을 활용해 식료품 고객이 관련 상품을 찾을 수 있도록 돕습니다. 예를 들어 “저지방 요거트”를 검색하면 문구가 정확히 일치하지 않더라도 그릭 요거트나 지방 함량이 0.5%인 요거트가 검색 결과에 표시될 수 있습니다.
• 텍스트 분류: 스팸 이메일을 식별하거나 문서를 주제별로 나누는 것처럼 텍스트를 범주별로 분류합니다. MindCraft.ai는 트랜스포머 기반 텍스트 임베딩과 머신러닝을 활용해 기업 문서를 분류하고 GDPR 준수를 위해 민감한 정보를 식별하는 문서 분류 시스템을 개발했습니다.
• 클러스터링: 유사한 문서나 텍스트 조각을 그룹화해 패턴을 파악합니다. Doczy.ai는 계약서 텍스트를 임베딩으로 변환하여, 서로 다른 계약서가 비슷한 의무를 다른 표현으로 기술하더라도 의미적으로 관련된 조항과 개념을 하나로 묶습니다.
• 검색 증강 생성(RAG): LLM이 더 정확하고 맥락을 반영한 답변을 생성하는 데 사용할 수 있는 관련 정보를 검색합니다. Ring은 다국어 RAG 챗봇에 Amazon Titan 텍스트 임베딩을 활용하여, 여러 해외 시장의 고객 질문에 대한 답변을 생성하기 전에 관련 지원 문서를 검색합니다.
• 추천 시스템: 텍스트 유사성을 기반으로 관련 기사, 상품 또는 기타 콘텐츠를 추천합니다. LinkedIn의 JUDE 시스템은 LLM으로 생성한 채용 공고 및 회원 프로필의 텍스트 임베딩을 사용해 지원자의 경력과 채용 중인 포지션 간의 관계를 포착함으로써 채용 추천의 품질을 높입니다.
• 개체명 인식(NER): 텍스트에서 사람, 조직, 장소의 이름을 식별하고 분류하는 데 도움을 줍니다. Amazon Health Services는 NER을 사용해 고객 쿼리에서 질병, 증상, 약물, 치료법 같은 의료 개념을 식별합니다. 그리고 이렇게 파악한 내용을 임베딩 기반 유사도 검색과 결합해 쿼리를 관련 헬스케어 제품 및 서비스와 연결합니다.
• 기계 번역: 언어 간에 텍스트를 번역하는 모델을 지원합니다. Transglot은 시맨틱 번역 메모리에 텍스트 임베딩을 활용해 의미가 비슷한 기존 번역 구절을 찾아내어, 현지화 워크플로우에서 기존 번역을 재사용할 수 있도록 돕습니다.

텍스트 임베딩은 어떻게 작동하나요?

그렇다면 임베딩 모델은 텍스트 조각에 어떤 숫자 값을 할당할지 어떻게 결정하며, 우리는 왜 그 결과를 신뢰해야 할까요?

모든 것은 학습에서 시작됩니다. 임베딩 모델은 방대한 텍스트 모음에서 단어가 함께 쓰이는 패턴을 찾아 학습합니다. 예를 들어 Word2Vec 같은 전통적인 모델은 주변 단어로 특정 단어를 예측하거나, 반대로 특정 단어로 주변 단어를 예측하는 방식으로 학습합니다. 최신 검색 중심 모델은 대조 학습을 사용하는 경우가 많습니다. 이러한 모델은 관련 없는 쌍보다 관련 있는 쿼리-문서 쌍에 더 높은 유사도 점수를 부여하도록 학습됩니다.

확대

학습을 마친 모델에 새로운 텍스트를 입력하면 다음과 같은 과정이 진행됩니다:

1. 토큰화. 모델은 먼저 텍스트를 토큰이라는 작은 단위로 나눕니다. 토큰은 단어 전체일 수도 있고, 단어의 일부나 문장 부호일 수도 있습니다. 각 토큰은 모델의 어휘에서 숫자 ID를 부여받는데, 이 ID 자체에는 아무런 의미가 없습니다.
2. 인코딩 및 풀링. 모델은 학습 중에 익힌 패턴을 사용해 이 토큰들을 처리하고 벡터를 생성합니다. 벡터의 각 숫자는 좌표 또는 성분이며, 차원은 해당 숫자가 벡터의 위치를 정의하는 축입니다. 각 값은 임베딩 공간이라고 하는 수학적 공간에서 텍스트의 위치를 결정하는 데 기여합니다.
3. 유사도 계산. 검색 시스템은 관련 텍스트를 찾기 위해 코사인 유사도나 내적 같은 유사도 척도로 쿼리 임베딩과 문서 임베딩을 비교합니다

예를 들어 온라인 스토어는 이런 방식으로 사용자의 쿼리에 맞는 상품을 보여 줍니다.

단어 임베딩, 문장 임베딩, 문서 임베딩의 차이점은 무엇인가요?

확대

가장 큰 차이는 각 임베딩이 하나의 벡터로 표현하는 텍스트의 양입니다. 포착하려는 정보에 따라 개별 단어, 완전한 문장 또는 문서 전체에 대한 임베딩을 생성할 수 있습니다.

• 단어 임베딩은 개별 단어 간의 관계를 포착하여 “장애”와 “다운타임”이 서로 관련된 개념임을 인식합니다.
• 문장 임베딩은 문장 전체의 의미를 이해하므로, 같은 생각을 다른 단어로 표현하더라도 이를 파악할 수 있습니다.
• 문서 임베딩은 문장마다 별도의 벡터를 만드는 대신 문서 전체를 하나의 벡터로 표현합니다. 이렇게 하면 전반적인 주제가 유지되어 같은 주제를 다루는 다른 문서를 찾는 데 도움이 되지만, 세부 정보는 검색하기 더 어렵거나 아예 불가능할 수도 있습니다.

그렇다면 얼마나 세분화해야 할까요? 적절한 수준은 데이터와 달성하려는 목표에 따라 달라집니다.

규모가 큰 문서는 텍스트를 더 작은 청크로 나누고 청크마다 별도의 임베딩을 생성하는 것이 일반적입니다. 이렇게 하면 문서의 전반적인 의미는 물론, 문서 임베딩 과정에서 손실될 수 있는 구체적인 세부 정보까지 모두 확보할 수 있습니다.

청크 크기는 임베딩 품질에 얼마나 영향을 미칠까요?

상당히 큰 영향을 미칩니다. Rahul Kumar Xenoss AI 엔지니어링 부문 부사장에 따르면, 핵심 과제는 중요한 맥락을 잃지 않으면서 하나의 완전한 아이디어를 담을 수 있는 청크 크기를 찾는 것입니다. 그는 이 트레이드오프를 다음과 같이 설명합니다:

“청크 크기는 하나의 임베딩이 얼마나 많은 의미적 맥락을 담을지를 결정합니다. 청크가 크면 벡터에 더 많은 맥락이 담기지만, 그 대신 더 많은 주제가 하나의 벡터로 평균화됩니다. 세 가지 주제를 다루는 청크는 그 중간 어딘가에 위치하게 되어 어느 주제와도 잘 일치하지 않습니다. 청크가 작으면 의미는 선명하게 유지되지만, 검색될 수 있게 해 주던 맥락을 잃을 수 있습니다.”

그래서 Kumar는 하나의 고정 크기를 고수하기보다 콘텐츠에 맞춰 청킹 전략을 선택할 것을 권장합니다. 그의 말을 빌리면 “오버랩을 적용한 고정 크기 방식은 이메일이나 스크랩한 웹 페이지처럼 형식이 균일한 텍스트에만 적합합니다.”

계약서나 정책 문서처럼 구조화된 문서에는 구조를 인식하는 재귀적 분할이 더 적합합니다. 한편 시맨틱 청킹은 주제나 의미가 바뀌는 지점에서 텍스트를 분할하므로 녹취록에 효과적일 수 있습니다.

텍스트 임베딩과 키워드 검색 비교

키워드로 검색하면 간단한데 왜 굳이 텍스트 임베딩을 사용할까요? 키워드 검색은 용어 일치에 의존하는 반면, 임베딩 기반 시맨틱 검색은 쿼리와 문서에 서로 다른 단어가 쓰이더라도 관련 정보를 검색할 수 있기 때문입니다.

하지만 의미적 유사성이 항상 관련성을 의미하지는 않습니다. AI Builder Academy 창립자 Shaw Talebi는 이력서 검색 시스템을 사용해 이러한 한계를 보여 줍니다. Talebi의 사례에서 “Apache Airflow 경험이 있는 데이터 엔지니어”를 검색했을 때, 상위 5개 결과 중 Apache Airflow를 언급한 결과는 단 하나였고 그마저도 3위에 그쳤습니다. 데이터 세트에는 해당 기술을 기재한 이력서가 세 개 더 있었는데도 말입니다.

즉, 시맨틱 검색은 개념적으로 관련된 정보를 찾는 데는 유용하지만, 기술 역량, 제품 식별자, 오류 코드 같은 정확한 요구 사항은 놓칠 수 있습니다.

이 문제를 해결하기 위해 Rahul Kumar는 검색 시스템의 어느 부분이 부족한지에 따라 검색 방식을 선택할 것을 권장합니다:

• 하이브리드 검색(키워드 매칭과 시맨틱 검색의 결합)은 SKU, 오류 코드, 법률 조항처럼 쿼리에 정확한 용어가 포함될 때 기본으로 사용하는 방식입니다.
• 리랭커는 검색된 맥락을 바탕으로 답변을 생성할 때처럼 상위 몇 개 결과만 중요한 경우에 비용만큼의 가치를 발휘합니다.
• 그래프 검색은 답이 서로 연결된 여러 데이터 소스에 걸쳐 있을 때 유용합니다.

Kumar는 그의 팀이 이러한 접근 방식을 실제로 어떻게 적용했는지도 공유했습니다. 한 프로젝트에서 팀은 BM25 키워드 검색과 벡터 검색을 병행 실행하고, 상호 순위 융합(RRF)으로 결과를 병합한 뒤, LLM을 사용해 상위 124개 결과를 재순위화하여 6개로 좁혔습니다.

“벡터 검색으로 유사한 잠재 공간을 찾은 다음 2홉 그래프 탐색을 수행하는 그래프 우선 검색으로 전환하자, 순위 품질(nDCG)이 0.58에서 0.67로 향상되었고 p90 검색 시간은 19초에서 3초 미만으로 단축되었습니다.”라고 Kumar는 덧붙입니다.

텍스트 임베딩 모델의 유형

모든 임베딩 모델은 대체로 같은 일, 즉 텍스트 속 관계를 학습하는 일을 합니다. 하지만 어떤 목적으로 학습되었는지, 어떤 정보를 고려하는지, 어떤 작업을 처리하도록 설계되었는지에 따라 차이가 있습니다.

정적 단어 임베딩 모델

전통적인 단어 임베딩 모델은 대규모 텍스트 모음 전반의 단어 사용 패턴을 바탕으로 단어의 밀집 수치 표현을 학습합니다. 이러한 임베딩은 정적입니다. 즉, 특정 맥락에서 어떤 의미로 쓰이든 각 단어는 항상 같은 벡터를 갖습니다.

잘 알려진 두 가지 방법은 다음과 같습니다:

• Word2Vec: 2013년 Google이 개발한 모델로, 두 가지 아키텍처를 사용해 주변 단어로부터 표현을 학습합니다. 하나는 주변 단어로 특정 단어를 예측하는 CBOW(Continuous Bag of Words)이고, 다른 하나는 주어진 단어로 주변 단어를 예측하는 스킵그램(skip-gram)입니다.
• GloVe(Global Vectors for Word Representation): 2014년 스탠퍼드 대학교에서 개발한 모델로, 단어 동시 출현 통계를 사용해 단어 간의 관계를 학습합니다.

문맥 기반 언어 모델

정적 임베딩과 달리 범용 언어 모델은 주변 텍스트에 따라 달라지는 문맥적 표현을 생성합니다. 덕분에 모델은 같은 단어의 서로 다른 의미를 구별할 수 있습니다.

• BERT(2018년, Google): 양방향 셀프 어텐션을 사용해 토큰의 양쪽에 있는 단어를 모두 고려합니다. 예를 들어 “I deposited money at the bank”(은행에 돈을 입금했다)와 “I sat on the bank of a river”(강둑에 앉았다)에서 “bank”에 대해 서로 다른 표현을 생성합니다.
• GPT(2018년, OpenAI): 다음 토큰을 예측할 때 앞선 텍스트를 반영하는 트랜스포머 기반 표현을 사용합니다. GPT 모델은 주로 언어 생성을 위해 설계되었습니다.

문장 및 문서 임베딩 모델

개별 문장부터 단락, 문서 전체에 이르기까지 더 긴 텍스트를 벡터로 표현합니다.

• Doc2Vec: Word2Vec 방식의 학습을 문장, 단락, 문서로 확장합니다. 관련 기사를 그룹화하거나 주제별로 문서를 분류하는 데 도움이 됩니다.
• Universal Sentence Encoder(USE): 2018년 Google이 시맨틱 유사도 및 텍스트 분류를 위해 문장과 짧은 단락의 고정 길이 표현을 생성하도록 개발한 모델입니다.
• Sentence-BERT(SBERT, 2019년): 다름슈타트 공과대학교의 Nils Reimers와 Iryna Gurevych가 개발한 모델로, Google의 BERT 모델을 기반으로 하며 시맨틱 검색, 패러프레이즈 탐지, 클러스터링에 널리 사용됩니다.
• pplx-embed-v1(2026년, Perplexity): 실제 환경의 웹 규모 검색을 위해 구축된 최첨단 텍스트 임베딩 모델 제품군으로, 확산 기반 사전 학습을 통해 인과적 언어 모델을 양방향 인코더로 전환합니다. 독립적으로 인코딩된 쿼리와 문서에 대해 밀집 임베딩을 생성하며, 양자화 인식 학습을 적용해 스토리지 비용을 줄입니다. 당사의 4B INT8 모델은 다국어 MTEB 검색 벤치마크에서 nDCG@10 69.66을 기록했으며, Google의 gemini-embedding-001은 67.71을 기록했습니다.
• pplx-embed-context-v1(2026년, Perplexity): 구절이 주변 텍스트와 분리되면 의미를 잃을 수 있다는 문서 청킹의 일반적인 문제를 해결합니다. 이 모델은 레이트 청킹(late chunking)을 사용해 문서 전체를 먼저 처리한 다음, 문맥이 반영된 토큰 표현을 개별 청크 임베딩으로 풀링합니다. 당사의 4B 모델은 ConTEB에서 nDCG@10 81.96을 기록했으며, voyage-context-3은 79.45를 기록했습니다.
• pplx-embed-v2-context(2026년, Perplexity): 문맥 검색을 한 단계 더 발전시킵니다. 답이 포함된 구절만 찾도록 학습하는 대신, 그 답을 설명하거나 검증하는 데 도움이 되는 뒷받침 구절을 식별하도록 학습합니다. 이 모델은 학습 과정에서 문맥 압축 모델로부터 증류한 관련성 신호를 사용하며, 추론 시에는 해당 교사 모델이 필요하지 않습니다. 당사의 9B 프리뷰 모델은 context-bench에서 상위 10개 결과 기준 답변 재현율 45.5%, 근거 재현율 40.6%를 달성했습니다.

Perplexity의 모델은 대규모 임베딩 저장도 지원합니다. 이 모델들은 INT8 및 바이너리 임베딩을 생성하여 FP32 대비 스토리지 요구 사항을 각각 4배, 32배 줄여 줍니다.

pplx-embed 모델의 차원, 컨텍스트 길이, 양자화 및 풀링 구성

밀집, 희소, 다중 벡터 임베딩

특히 시맨틱 검색과 관련해 알아 둘 만한 차이점이 하나 더 있습니다. 임베딩 모델은 텍스트를 표현하고 관련성을 계산하는 방식에서 차이가 날 수 있습니다.

• 밀집 임베딩: 대부분의 값이 0이 아닌 압축된 벡터로 텍스트를 표현합니다.
• 희소 임베딩: 대부분의 값이 0인 벡터를 사용하며, 중요한 용어에 학습된 가중치가 부여됩니다. SPLADE(2021년) 같은 모델은 관련 문서를 검색하는 데 어떤 용어가 중요한지 학습합니다.
• 다중 벡터 임베딩: 하나의 텍스트에 대해 여러 개의 벡터를 유지하여 쿼리와 문서를 더 세밀하게 비교할 수 있습니다. ColBERT(2020년) 같은 모델은 이러한 표현을 사용해 쿼리와 문서를 더 정교하게 비교합니다.
• 여러 접근 방식을 결합한 모델: BGE-M3(2024년)는 BAAI가 개발한 모델로, 하나의 모델에서 밀집, 희소, 다중 벡터 검색을 모두 지원합니다.

텍스트 임베딩 모델을 선택하고 평가하는 방법

MTEB 같은 공개 벤치마크는 좋은 출발점입니다. 이를 활용해 필요한 언어, 입력 길이, 배포 요구 사항을 지원하는 모델을 두세 개로 추려 보세요. 하지만 아직 최종 선택을 내리기는 이릅니다. 자체 데이터로 해당 모델을 테스트하는 것이 얼마나 중요한지는 아무리 강조해도 지나치지 않습니다.

실용적인 평가 워크플로우는 다음과 같습니다:

1. 테스트 데이터 세트를 구축합니다. 초기 평가 세트로 대표적인 검색 쿼리 50~100개를 수집합니다(더 많이 필요할 수도 있습니다). 이때 패러프레이즈, 기술 용어, 정확한 오류 코드 같은 까다로운 사례도 포함해야 합니다. 각 쿼리에 대해 관련 답변이 포함된 문서나 구절을 식별합니다. 이 관련성 레이블이 정답 기준(ground truth)이 됩니다.
2. 검색 품질을 측정하세요. 동일한 평가 데이터 세트로 각 모델을 테스트하되, 문서 준비와 검색 조건은 비교 가능하게 유지하면서 쿼리 형식, 정규화, 유사도 점수 산정에 관한 모델별 요구 사항을 따르세요. 그런 다음 Sentence Transformers의 InformationRetrievalEvaluator를 사용해 다음 지표를 계산하세요.
   • Recall@k: 관련 구절 중 상위 k개 결과에 포함된 비율을 나타냅니다.
   • MRR: 첫 번째 관련 결과가 순위에서 얼마나 높은 위치에 나타나는지 측정합니다.
   • nDCG@k: 상위 k개 결과가 관련성에 따라 얼마나 잘 정렬되었는지 측정합니다.
3. 지연 시간과 처리량을 벤치마킹하세요. 각 모델이 쿼리를 임베딩하는 데 걸리는 시간을 측정하고, 가능하면 실제와 비슷한 부하에서의 중앙값(p50) 및 95번째 백분위수(p95) 지연 시간을 함께 보고하세요.
4. 스토리지 및 운영 비용을 계산하세요. 벡터 스토리지는 임베딩의 개수, 차원, 수치 정밀도에 따라 달라집니다. 예를 들어 768차원 FP32 임베딩 100만 개에는 인덱싱 오버헤드를 제외하고 약 3.1GB의 원시 벡터 스토리지가 필요합니다. 스토리지 요구량을 줄이려면 벡터를 더 낮은 수치 정밀도로 양자화할 수 있습니다. 예컨대 FP32에서 INT8로 전환하면 원시 벡터 스토리지가 약 4분의 1로 줄어듭니다. 다만 압축은 검색 품질에 영향을 줄 수 있으므로, 평가를 다시 실행해 그 트레이드오프를 확인하세요.

마지막으로 검색 지표, p95 지연 시간, 처리량, 스토리지, 비용 등 결과를 나란히 비교하세요. 그리고 프로덕션 환경의 제약 안에서 품질 요구 사항을 충족하는 모델을 선택하세요.

LLM 대신 임베딩을 사용해야 하는 경우는 언제일까요?

LLM이 문서 분석부터 복잡한 추론까지 모든 것을 처리하는 요즘, 가진 텍스트를 전부 모델에 넣고 알아서 처리하게 하고 싶은 유혹이 꽤 큽니다. 하지만 그에 따른 비용을 지불하고 싶지는 않을 것입니다.

또한 LLM은 판단하고 글을 작성하는 데는 더 뛰어나지만, 하나의 프롬프트에 담을 수 있는 정보의 양에 제약을 받습니다. 반면 임베딩은 저렴하고 빠르며 일관적이고, 수백만 개의 항목에도 적용할 수 있습니다.

“임베딩은 검색, 추천(‘이와 비슷한 항목 더 보기’), 반복되는 지원 티켓 같은 중복 항목 찾기, 대량의 콘텐츠를 주제별로 묶는 작업에서 강점을 보입니다. 여러 언어에 걸쳐서도 뛰어난 성능을 발휘하죠. 반면 요약, 옵션 비교, 답변 작성처럼 추론이 필요한 작업에서는 LLM이 유리합니다. 실제 시스템은 대부분 두 가지가 모두 필요하며, 각자 잘하는 부분을 맡게 됩니다.”라고 Kumar는 결론지었습니다.

개발자들이 텍스트 임베딩에 대해 흔히 저지르는 실수

개발자들이 흔히 놓치는 부분이 무엇인지 알아보기 위해 Rahul Kumar와 Xibeijia Guan(Ahrefs 데이터 과학자)과 이야기를 나눴습니다. 두 사람은 주의해야 할 여섯 가지 실수를 꼽았습니다.

• 텍스트 전처리 생략. 입력 데이터에 HTML, 내비게이션 메뉴, 광고 등 관련 없는 콘텐츠가 포함되어 있다면, 보일러플레이트 제거 같은 전처리 단계로 불필요한 정보를 걸러 내 임베딩 품질을 높일 수 있습니다.
• 모델의 최대 입력 길이 무시. 모델마다 토큰 한도와 잘림(truncation) 방식이 다릅니다. 한도를 초과하는 텍스트는 잘릴 수 있으며, 그 결과 중요한 정보가 손실될 수 있습니다.
• 모델별 요구 사항 미준수. 일부 임베딩 모델은 query:, passage: 같은 특정 접두사를 요구하거나 작업마다 다른 지침을 요구합니다. 이러한 요구 사항을 따르지 않으면 검색 성능이 떨어질 수 있습니다.
• 호환되지 않는 유사도 측정 방식 사용. 코사인 유사도와 내적이 항상 서로 대체 가능한 것은 아닙니다. 임베딩이 정규화되어 있는지 확인하고, 모델과 벡터 인덱스에 권장되는 점수 산정 방식을 사용하세요.
• 주제 유사성을 관련성으로 착각. 도메인이 좁은 컬렉션에서는 많은 문서가 의미적으로는 비슷하지만 같은 질문에 답하지는 않을 수 있습니다. 실패한 쿼리와 순위 분포를 살펴보세요. 사용자에게 정확한 정보가 필요하다면 어휘 기반 검색이나 하이브리드 검색, 리랭킹, 메타데이터 필터를 테스트해 보세요.
• 임베딩 정규화 무시. 임베딩 모델에 따라 정규화된 벡터를 출력할 수도, 정규화되지 않은 벡터를 출력할 수도 있습니다. 사용하는 유사도 지표에 맞춰 임베딩이 정규화되어 있는지, 추가 정규화가 필요한지 확인하세요.

텍스트 임베딩 FAQ

1. 텍스트 임베딩은 어떻게 생성하나요?

가장 간단한 방법은 사전 학습된 임베딩 모델을 사용하는 것입니다. 예를 들어 Python의 Sentence Transformers 라이브러리를 사용하면 all-MiniLM-L6-v2 같은 모델을 불러온 뒤 model.encode()에 텍스트를 전달해 수치 벡터를 반환받을 수 있습니다. 또는 API를 통해 임베딩을 생성할 수도 있습니다.

시맨틱 검색이나 RAG에서는 일반적으로 문서를 청크로 분할하고, 각 청크의 임베딩을 생성한 다음, 그 벡터를 검색 가능한 인덱스에 저장합니다.

2. 텍스트에 가장 적합한 임베딩 모델은 무엇인가요?

무엇을 구축하느냐에 따라 고려해 볼 만한 모델은 다음과 같습니다.

• Perplexity의 pplx-embed-v1: 대규모 밀집 검색을 위해 설계되었으며, 벡터 스토리지 요구량을 줄여 주는 INT8 및 바이너리 임베딩을 제공합니다.
• Perplexity의 pplx-embed-context-v1: 개별 청크가 주변 맥락 없이는 의미를 잃는 긴 문서에서 구절을 검색할 때 유용합니다.
• all-MiniLM-L6-v2: 가벼운 로컬 시맨틱 검색, 클러스터링, 문장 유사도 작업에 적합합니다. 384차원의 컴팩트한 벡터를 생성하지만, 256개 워드피스를 초과하는 입력은 잘라 냅니다.
• BGE-M3: 다국어 RAG와 하이브리드 검색에 유용합니다. 100개 이상의 언어를 지원하며 밀집(dense), 희소(sparse), 멀티 벡터 표현을 결합합니다.
• Qwen3-Embedding: 다국어 검색, 코드 검색, 작업별 임베딩에 적합한 유력한 후보입니다. 지침(instruction)을 지원하는 0.6B, 4B, 8B 오픈 웨이트 모델을 제공합니다.
• OpenAI의 text-embedding-3-large: 모델을 직접 호스팅하고 싶지 않을 때 시맨틱 검색과 문서 검색에 활용할 수 있는 API 기반 옵션입니다. 최대 3,072차원을 지원하며, 스토리지를 절약하기 위해 차원을 줄일 수 있습니다.
• Google의 Gemini Embedding 모델: 관리형 검색 애플리케이션에 유용합니다. Gemini Embedding 2는 공유 임베딩 공간에서 텍스트, 이미지, 오디오, 동영상, PDF를 아우르는 검색도 지원합니다.

3. LLM을 임베딩 모델로 사용할 수 있나요?

네, 가능합니다. 다만 범용 LLM과 임베딩에 최적화된 LLM은 차이가 있습니다. LLM은 텍스트의 내부 벡터 표현을 생성하며, 이를 추출하고 풀링해 하나의 임베딩으로 만들 수 있습니다. 하지만 추가 학습 없이는 이러한 벡터가 시맨틱 검색에 꼭 유용하다고 할 수는 없습니다.

예를 들어 Qwen3-Embedding은 임베딩 및 검색 작업을 위해 추가로 학습된 LLM 백본을 사용합니다. 따라서 LLM을 임베딩 생성에 맞게 조정할 수는 있지만, 일반적으로는 전용 임베딩 모델로 시작하는 편이 더 실용적입니다.