# \#embedding

**URL:** https://discuss.pytorch.kr/tag/embedding/458.md

[최신](https://discuss.pytorch.kr/latest.md) · [카테고리](https://discuss.pytorch.kr/categories.md) · [태그](https://discuss.pytorch.kr/tags.md)

---

## [고려대 DMIS 연구실, 마스킹 비율마다 LM 헤드를 나눠 분류와 검색을 함께 잡은 32K 인코더 UltraBERT 공개](https://discuss.pytorch.kr/t/dmis-lm-32k-ultrabert/12199)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [10월 15, 2026, 6:00오전 UTC](https://discuss.pytorch.kr/t/dmis-lm-32k-ultrabert/12199 "2026-10-15T06:00:09Z")

</div>

핵심 요약 고려대학교 DMIS 연구실이 UltraBERT 논문과 소개 블로그에서 영어 양방향 인코더 UltraBERT-150M, UltraBERT-380M과 임베딩 모델 UltraBERT-Embed-150M을 Apache 2.0으로 공개했습니다. 세 모델 모두 32K 토큰 컨텍스트를 지원합니다. 저자들은 인코더 성능이 학습 토큰 수 조(마스킹 비율에 따라 1~3T) 부근에서 포화되고, 분류는 낮은 마스킹 비율에서, 검색은 높은 마스킹 비율에서 좋아진다는 것을 확인했습니다. 그래서 한 배치에 5%와 50% 마스킹 문장을 섞고 비율마다 LM 헤드를 따로 두었습니다. 저자들이 같은 조건으로 미세조정해 비교한 10개 벤치마크 중 9개에서 두 크기 모두 1위였고, 380M 모델은 GLUE 91.0, BEIR 47.7을 기록했습니다. 진 항목은 150M의 MultiCoNER v2와 380M의 MLDR입니다. 영어 전용 모델이고, 확인 시점(2026년 10월 15일)에 공개된 학습 코드는 임베딩 학습 저장소뿐입니다. 백본 사전학습 코드와 1.3B 교사 모델은 공개 저장소에서 찾지 못했습니다. UltraBERT 소개: 분류와 검색 중 하나를 고르지 않아도 되는 인코더 UltraBERT 는 문장을 한 번에 양방향으로 읽어 벡터나 점수를 내는 BERT 계열 인코더입니다. 이 모델의 요점은 같은 크기대 인코더 중에서 분류(classification)와 검색(retrieval) 모두 최상위 점수를 낸다는 것입니다. 지금까지는 두 작업에서 1위 모델이 서로 달랐습니다. GLUE에서는 Ettin Encoder가, BEIR에서는 ModernBERT나 LFM2.5-Encoder가 앞섰습니다. 인코더는 생성 모델이 주목받는 지금도 대량의 텍스트를 싸게 처리하는 기본 도구입니다. RAG 파이프라인은 문서를 인코더로 임베딩하고, FineWeb-Edu 같은 사전학습 데이터셋도 인코더로 품질 점수를 매겨 걸러냈습니다. 인코더는 입력을 한 번 읽고 끝나므로 토큰을 하나씩 생성하는 디코더보…

---

## [Google, 텍스트 전용이던 EmbeddingGemma를 이미지, 영상, 음성까지 넓힌 EmbeddingGemma 2 공개](https://discuss.pytorch.kr/t/google-embeddinggemma-embeddinggemma-2/12118)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [10월 7, 2026, 6:00오전 UTC](https://discuss.pytorch.kr/t/google-embeddinggemma-embeddinggemma-2/12118 "2026-10-07T06:00:18Z")

</div>

핵심 요약 Google DeepMind가 EmbeddingGemma 2 발표 글에서 텍스트, 코드, 이미지, 영상, 음성을 하나의 768차원 공간에 담는 740M 임베딩 모델을 Apache 2.0 라이선스로 공개했습니다. 텍스트 전용 270M 모델에 비전(170M)과 오디오(300M) 인코더를 골라 붙이는 구조라, 텍스트만 다루는 서비스는 270M만 불러 쓸 수 있습니다. Hugging Face 모델 카드 기준으로 코드 검색 벤치마크(MTEB Code)는 전작보다 9.92점 올랐고(68.76에서 78.68), 다국어 텍스트 점수는 61.15에서 61.36으로 거의 같습니다. 벡터를 128차원으로 줄여도 텍스트와 코드는 약 90% 이상의 품질을 지킵니다. 반면 멀티모달 검색 점수는 크게 떨어져서, Google도 128차원은 텍스트 위주로 쓰도록 안내합니다. 모든 벤치마크는 Google이 직접 측정한 값이고, 음성 벤치마크(MAEB)에서는 Google 차트 안에서도 약 1B 크기의 jina-embeddings-v5-omni-nano가 더 높게 그려져 있습니다. EmbeddingGemma 2 소개 EmbeddingGemma 2는 Google DeepMind가 2026년 10월 6일 공개한 멀티모달 임베딩 모델입니다. 휴대폰과 노트북 위에서 텍스트, 코드, 이미지, 영상, 음성을 같은 벡터 공간에 넣어 서로 검색할 수 있게 해 줍니다. 임베딩 모델은 입력을 고정 길이 벡터로 바꾸고, 뜻이 가까운 입력끼리 벡터도 가깝게 놓습니다. 검색 증강 생성(RAG, Retrieval-Augmented Generation)과 의미 검색(Semantic Search)이 모두 이 벡터 사이의 거리로 동작합니다. 지금까지 기기 안에서 사진이나 녹음을 검색하려면 보통 여러 모델을 이어 붙였습니다. 이미지는 캡션 모델로 문장을 만들고, 음성은 음성 인식 모델로 받아쓴 다음, 그 텍스트를 다시 텍스트 임베딩 모델에 넣는 식입니다. Google AI Edge 블로그는 Embeddin…

---

## [Hugging Face가 Papers with Code 논문 11만 편의 하이브리드 검색을 만든 방법 (feat. pgvector, RRF)](https://discuss.pytorch.kr/t/hugging-face-papers-with-code-11-feat-pgvector-rrf/11859)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [9월 9, 2026, 10:00오후 UTC](https://discuss.pytorch.kr/t/hugging-face-papers-with-code-11-feat-pgvector-rrf/11859 "2026-09-09T22:00:48Z")

</div>

Papers with Code 하이브리드 검색 소개 Papers with Code는 논문과 코드, 벤치마크 결과를 한곳에서 찾을 수 있게 해 주는 AI 연구 색인 서비스로, Hugging Face가 2026년 5월부터 되살린 뒤 PostgreSQL 전문 검색과 벡터 검색을 결합한 하이브리드 검색(Hybrid Search) 을 새로 구축했습니다. 이 글은 Hugging Face의 Niels Rogge가 2026년 8월 21일 공개한 블로그를 바탕으로, 11만 편이 넘는 논문 임베딩을 어떤 인프라 위에서 만들고 서비스하는지, 그리고 그 과정에서 어떤 설계 결정을 내렸는지를 정리한 것입니다. Papers with Code는 한동안 운영이 멈춰 있다가, Hugging Face가 Reddit 공지와 X 게시물로 부활을 알리면서 다시 문을 열었습니다. 저자는 이 프로젝트의 목표를 "열린 AI 연구를 접근 가능하고 소화하기 쉽게 만드는 것" 이라고 설명합니다. 사람이든 에이전트든 논문에 딸린 산출물을 쉽게 찾고, 분야별 SOTA(State of the Art)를 확인하고, 흥미로운 연구를 공유하며 서로의 연구 위에 쌓아 갈 수 있어야 한다는 것입니다. 궁극적으로는 다음 Transformer로 이어질 연구를 뒷받침하는 것이 목표라고 적혀 있습니다. 웹사이트뿐 아니라 pwc-cli라는 명령줄 도구와, 코딩 에이전트가 그 도구를 쓰는 법을 담은 Skill 파일까지 함께 제공하는 이유가 여기에 있습니다. pwc search "small vision language models" 한 줄로 에이전트가 논문을 찾을 수 있습니다. 이번에 소개하는 블로그의 핵심 질문은 "연구 논문을 찾는 검색은 일반 텍스트 검색과 무엇이 다른가" 입니다. 저자에 따르면 쓸 만한 논문 검색 엔진은 정확한 제목이나 arXiv 식별자를 곧바로 찾아야 하지만, 동시에 "small language models for code generation" 처럼 논문에 그 단어들이 함께 등장하지 않아도 뜻을 …

---

## [Sentence Transformers로 도메인 특화 멀티 벡터 검색 모델 미세조정하기, GPU 한 장에 14.5시간](https://discuss.pytorch.kr/t/sentence-transformers-gpu-14-5/11791)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [9월 2, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/sentence-transformers-gpu-14-5/11791 "2026-09-02T03:30:43Z")

</div>

Sentence Transformers 멀티 벡터 모델 학습 가이드 소개 Sentence Transformers는 검색 증강 생성(RAG), 의미 기반 검색(Semantic Search), 의미적 텍스트 유사도(Semantic Textual Similarity) 같은 곳에 쓰이는 임베딩 모델과 재정렬(Reranking) 모델을 쓰고 학습시키는 Python 라이브러리이고, v6.0에서 추가된 MultiVectorEncoder 는 ColBERT 계열의 Late Interaction 검색 모델을 이 라이브러리 안에서 학습까지 할 수 있게 해 줍니다. 이번에 소개할 글은 그 학습 절차를 처음부터 끝까지 정리한 Tom Aarsen의 2026년 8월 26일 Hugging Face 블로그 포스트로, 소비자용 GPU인 RTX 3090 한 장에서 14.5시간을 돌려 만든 의료 검색 모델이 밀집(Dense), 희소(Sparse), 어휘(Lexical), 멀티 벡터를 통틀어 저자가 구할 수 있었던 모든 범용 검색 모델을 앞선 과정을 담고 있습니다. 이 주제가 중요한 이유는 간단합니다. 공개된 검색 모델 대부분은 웹 검색 분포에 맞춰져 있습니다. 어휘도, 질의를 쓰는 방식도, 무엇이 관련 있는 문서인가 라는 기준 자체도 웹 검색과 법률 문서 검토, 코드 검색, 과학 문헌 조사에서 각각 다릅니다. 게다가 널리 쓰이는 체크포인트들은 짧은 문단을 전제로 설정되어 있어서, 문서가 길면 점수를 매기기도 전에 대부분을 잘라 버립니다. 그런데 의료, 법률, 금융, 사내 문서처럼 구체적인 도메인마다 공식 모델이 나오는 일은 없습니다. 원문은 그 공백을 직접 메우는 방법을 다룹니다. 원문 저자는 같은 시기에 멀티 벡터 모델을 쓰는 방법을 다룬 컴패니언 글을 따로 썼고, 그쪽은 PyTorchKR에도 이미 정리되어 있습니다. 모델을 불러와 인코딩하고 벡터 데이터베이스에 색인하는 이야기가 필요하다면 그 글을 먼저 보는 편이 좋습니다. 아래 정리는 학습 쪽만 다루므로, 구조와 점수 계산은 짧게 …

---

## [WeMM-Embedding: 2B 모델로 8B 베이스라인을 넘어선 범용 멀티모달 임베딩에 대한 연구](https://discuss.pytorch.kr/t/wemm-embedding-2b-8b/11750)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [8월 29, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/wemm-embedding-2b-8b/11750 "2026-08-29T09:30:19Z")

</div>

WeMM-Embedding 소개 검색창 하나로 텍스트와 영상을 함께 찾는다는 것 사진첩에서 "작년 여름 바닷가"를 찾을 때 우리는 파일명을 기억해 내지 않습니다. 장면을 떠올리고, 그 장면과 가장 비슷해 보이는 것을 눈으로 고릅니다. 검색 시스템이 이 일을 대신하려면 사진과 문장을 같은 기준으로 잴 수 있어야 하는데, 이러한 역할을 하는 것이 바로 임베딩(embedding)입니다. (:pytorch::kr: 임베딩에 대한 자세한 내용은 다음 글을 참고해주세요: 머신러닝 분야의 임베딩에 대한 상세한 가이드 (The Full Guide to Embeddings in Machine Learning)) WeMM-Embedding은 Tencent의 WeChat Vision 팀이 공개한 범용 멀티모달 임베딩(universal multimodal embedding) 모델군으로, 텍스트와 이미지, 영상, 시각 문서(visual document), 그리고 이들이 임의로 뒤섞인 입력까지 하나의 조밀한 벡터 공간에 담는 것을 목표로 합니다. 이 연구는 서로 다른 형태의 콘텐츠를 공통의 표현 공간에 두어 검색, 추천, 분류, 에이전트 시스템이 같은 벡터로 동작하게 만드는 문제를 다루며, 대규모 정렬과 정제라는 2단계 학습 전략을 제안합니다. 모델은 2B, 4B, 9B의 세 가지 규모로 공개되었고, 가중치와 코드가 Apache 2.0 라이선스로 함께 공개되었습니다. 기존 접근법과 각각의 한계 멀티모달 임베딩의 출발점은 CLIP 계열의 듀얼 인코더입니다. 이미지 인코더와 텍스트 인코더를 따로 두고 대규모 쌍 데이터로 두 공간을 맞추는 방식은 교차 모달 정렬이 실제로 학습된다는 것을 보여 주었습니다. 다만 모달별로 인코딩 경로가 분리되어 있다는 구조적 성질 때문에, 여러 모달이 한 입력 안에 섞인 경우를 자연스럽게 다루지 못합니다. 텍스트와 이미지가 번갈아 나오는 문서, 이미지와 문장을 함께 주는 합성 질의(composed query), 자막이 붙은 영상이 모두 여기에 해당합니…

---

## [MegaMemory: 코딩 에이전트가 세션이 끝나도 프로젝트 구조를 기억하게 만드는 MCP 서버](https://discuss.pytorch.kr/t/megamemory-mcp/11713)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [8월 25, 2026, 10:30오후 UTC](https://discuss.pytorch.kr/t/megamemory-mcp/11713 "2026-08-25T22:30:09Z")

</div>

MegaMemory 소개 코딩 에이전트를 며칠 이상 쓰다 보면 같은 작업을 반복하게 됩니다. 어제 세 시간 동안 인증 흐름을 읽고 어디를 고쳐야 하는지 파악해 두었는데, 오늘 새 세션을 열면 에이전트는 그 파일들을 처음 보는 것처럼 다시 읽습니다. 이 문제를 푸는 흔한 방향은 코드베이스를 미리 인덱싱해 두는 것이고, PyTorchKR 에도 CodeGraph나 codebase-memory-mcp처럼 코드를 그래프로 만들어 두는 도구가 소개된 적이 있습니다. 다만 함수와 파일의 호출 관계를 그린 그래프는 무엇이 무엇을 부르는지는 알려주지만, 왜 이 모듈이 이렇게 생겼는지, 지난주에 어떤 결정을 내렸는지는 담고 있지 않습니다. 이번에 소개할 MegaMemory는 그 기록을 코드 구조에서 추출하지 않고 에이전트가 직접 쓰게 하는 방향을 택한 MCP(Model Context Protocol) 서버입니다. MegaMemory에는 추상 구문 트리(AST, Abstract Syntax Tree) 파서도 정적 분석기도 없습니다. 대신 에이전트가 코드를 읽고 자기 말로 개념을 적어 두고, 다음 작업을 시작하기 전에 그 개념을 자연어로 질의합니다. 그래서 그래프에 쌓이는 노드는 함수나 클래스 같은 코드 심볼이 아니라 기능, 모듈, 패턴, 설계 결정 같은 개념(Concept) 입니다. MegaMemory는 npm 패키지로 배포되며 Node.js 18 이상을 요구합니다. 모든 기록은 프로젝트마다 하나씩 생기는 SQLite 데이터베이스인 .megamemory/knowledge.db 에 남고, 의미 검색에 쓰는 임베딩(Embedding)은 프로세스 안에서 직접 계산합니다. 첫 실행에서 약 23MB 짜리 모델을 한 번 내려받은 뒤에는 API 키도, 추가 네트워크 호출도 필요하지 않습니다. MegaMemory가 도는 세 단계 루프 MegaMemory의 사용 흐름은 이해, 작업, 갱신 세 단계로 정리됩니다. 세션을 시작할 때 에이전트가 list\_roots 를 호출해 최상위 개…

---

## [Sentence Transformers v6.0, ColBERT 스타일 멀티 벡터 검색을 표준 API로](https://discuss.pytorch.kr/t/sentence-transformers-v6-0-colbert-api/11673)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [8월 21, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/sentence-transformers-v6-0-colbert-api/11673 "2026-08-21T03:30:45Z")

</div>

Sentence Transformers v6.0의 MultiVectorEncoder 소개 Sentence Transformers는 임베딩 모델과 재정렬(Reranking) 모델을 쓰고 학습시키는 Python 라이브러리로, 검색 증강 생성(RAG)이나 의미 기반 검색(Semantic Search) 같은 곳에 쓰입니다. v6.0에서 네 번째 모델 유형인 MultiVectorEncoder 가 추가되면서, ColBERT 계열의 Late Interaction 검색을 이 라이브러리 안에서 곧바로 쓸 수 있게 되었습니다. PyLate 체크포인트와 Stanford-NLP ColBERT 체크포인트가 그대로 열리고, 페이지 이미지를 직접 검색하는 colpali-engine 계열 모델도 같은 API로 동작합니다. 일반적인 임베딩 모델은 문장이나 문단 하나를 벡터 한 개로 압축합니다. 멀티 벡터(Multi-Vector) 모델 은 그 압축을 하지 않고 토큰마다 벡터 하나 를 그대로 남긴 뒤, MaxSim 연산자로 질의와 문서의 점수를 계산합니다. 벡터 한 개로 평균 내면서 사라지던 토큰 단위 대응 정보가 보존되므로 검색 품질이 올라가는 대신, 색인 크기가 커집니다. 텍스트뿐 아니라 페이지 이미지를 OCR 없이 검색하는 시각 문서 검색(Visual Document Retrieval)에서는 현재 가장 성능이 좋은 방식이기도 합니다. 원문은 이 방식을 Late Interaction 모델, ColBERT 스타일 모델과 같은 뜻으로 번갈아 부르므로, 아래에서도 세 이름을 하나로 읽으면 됩니다. 이 방식 자체는 새로운 것이 아닙니다. 2020년의 ColBERT 논문에서 출발해 LightOn이 만든 PyLate가 몇 년째 학습과 검색 스택을 떠받쳐 왔고, ColPali가 이를 문서 이미지로 확장했습니다. 그동안 Sentence Transformers는 밀집(Dense)과 희소(Sparse) 임베딩, 그리고 재정렬 모델까지만 다뤘기 때문에, Late Interaction을 쓰려면 별도 라…

---

## [UEmbed: 디코더 전용 모델에서 희소 검색과 밀집 검색을 통합한 멀티모달 임베딩 연구](https://discuss.pytorch.kr/t/uembed/11614)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [8월 14, 2026, 8:00오전 UTC](https://discuss.pytorch.kr/t/uembed/11614 "2026-08-14T08:00:58Z")

</div>

UEmbed 소개 검색창에 단어를 입력했을 때 검색 엔진이 하는 일은 크게 두 갈래로 나뉩니다. 하나는 입력한 단어가 문서에 실제로 들어 있는지 세는 일이고, 다른 하나는 단어가 하나도 겹치지 않아도 뜻이 통하는 문서를 끌어오는 일입니다. UEmbed 는 이 두 가지를 서로 다른 모델에 맡기는 대신, 디코더 전용(Decoder-only) 멀티모달 언어 모델 하나가 단 한 번의 순전파에서 희소 어휘 벡터와 밀집 벡터를 함께 내놓게 만든 임베딩 모델입니다. 중국과학원 자동화연구소(CASIA)와 Alibaba Group, 중국과학원대학교(UCAS), Yale University 연구진이 발표했고, 공개 데이터만으로 학습한 2B와 4B, 9B 세 가지 크기의 가중치를 함께 공개했습니다. 결과부터 짚어보면 UEmbed-9B는 멀티모달 임베딩 벤치마크 MMEB-v2에서 밀집 모드 71.8 점, 희소 모드 71.0 점을 기록했습니다. 두 모드의 차이가 1.0 점 안쪽이고, 희소 모드만으로도 기존의 여러 밀집 전용 모델을 앞섭니다. 저자들이 아는 한 MMEB-v2에서 희소 멀티모달 검색 결과가 보고된 것은 이번이 처음입니다. 어휘 매칭에서 학습된 희소 검색까지 정보 검색(Information Retrieval, IR)의 오래된 주력은 BM25 같은 어휘 기반 희소 검색(Sparse Retrieval)입니다. 문서를 어휘 사전 크기의 벡터로 두고 등장한 단어의 자리에만 가중치를 채우는 방식이라, 역색인(Inverted Index)으로 대규모 말뭉치를 빠르게 훑을 수 있고 어떤 단어 때문에 이 문서가 걸렸는지도 그대로 보입니다. 문제는 정확 일치에 의존한다는 점입니다. 질의와 문서가 같은 개념을 다른 단어로 적으면 그 문서는 아예 후보에 오르지 못합니다. 학습된 희소 검색(Learned Sparse Retrieval, LSR)은 이 빈틈을 신경망으로 메웁니다. 대표적인 SPLADE 계열은 각 토큰의 은닉 상태를 어휘 공간에 투영한 뒤 시퀀스 전체에 대해 최댓값 풀링(…

---

## [ko-embedding-leaderboard: 한국어 임베딩 모델을 평가하는 오픈소스 리더보드](https://discuss.pytorch.kr/t/ko-embedding-leaderboard/11416)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [7월 26, 2026, 12:30오전 UTC](https://discuss.pytorch.kr/t/ko-embedding-leaderboard/11416 "2026-07-26T00:30:49Z")

</div>

ko-embedding-leaderboard 소개 RAG 시스템이나 검색 기능을 한국어로 만들 때 가장 먼저 부딪히는 선택은 "어떤 임베딩 모델을 쓸 것인가" 입니다. 후보는 많지만, 영어 벤치마크 점수가 높다고 해서 한국어 검색에서도 잘 동작한다는 보장은 없습니다. 모델마다 평가 방식과 데이터셋이 제각각이라 공정하게 비교하기도 어렵습니다. ko-embedding-leaderboard는 이 문제를 한국어에 특화된 공개 리더보드로 정리한 프로젝트입니다. 임베딩 평가 벤치마크인 MTEB를 한국어 환경에 맞게 커스텀하고 데이터셋을 일부 수정해, 오픈소스 임베딩 모델을 여러 한국어 검색(IR) 과제로 평가하고 순위를 매깁니다. Sparse 임베딩과 Dense 임베딩을 나누어 순위를 제공하는 것이 특징입니다. 프로젝트 저자는 평가 방식과 대상 모델에 대한 문의나 제보를 이슈로 받고 있으며, 잘못된 부분에 대한 지적도 환영한다고 밝히고 있습니다. 아래에 정리하는 순위는 저장소의 리더보드를 옮긴 것으로, 새 모델이 추가되면서 계속 갱신됩니다. ko-embedding-leaderboard의 평가 방식 아래 그림은 리더보드가 순위를 만드는 과정을 정리한 것입니다. 오픈소스 임베딩 모델을 여러 한국어 검색 데이터셋으로 평가하고, NDCG 점수의 평균으로 순위를 매깁니다. Version 2부터는 클러스터링(Clustering) 이나 NLI 같은 과제를 빼고 정보 검색(IR) 만 평가합니다. 평가 지표는 NDCG@5와 NDCG@10의 평균이며, 사용하는 한국어 검색 데이터셋은 Ko-StrategyQA, AutoRAGRetrieval, PublicHealthQA, LawIRKo, WebFAQRetrieval, SQuADKorV1Retrieval, MIRACLRetrievalHardNegative 7종입니다. 모델을 불러올 때는 HuggingFace에 기재된 방식을 따르되 SentenceTransformer를 Transformers보다 우선해서 로드하고, Huggi…

---

## [하루 15,000개 질문에 답하는 Cerebras의 사내 지식 베이스 설계 노하우 (feat. pgvector, RRF, MCP)](https://discuss.pytorch.kr/t/15-000-cerebras-feat-pgvector-rrf-mcp/11329)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [7월 20, 2026, 9:30오후 UTC](https://discuss.pytorch.kr/t/15-000-cerebras-feat-pgvector-rrf-mcp/11329 "2026-07-20T21:30:26Z")

</div>

Cerebras 사내 지식 베이스 소개 Cerebras의 직원들은 사내 지식 베이스(Knowledge Base)에 매일 15,000개 이상의 질문 을 던집니다. 공개된 지 3개월 만에 회사에서 가장 널리 쓰이는 내부 도구 중 하나가 되었고, 사람뿐 아니라 자동화 스크립트와 에이전트도 이 시스템에 질문을 보냅니다. 이 글은 그 사내 지식 베이스인 Cerebras Knowledge, 즉 회사 곳곳에 흩어진 데이터를 하나로 모아 자연어로 답하는 검색 증강 시스템(RAG, Retrieval-Augmented Generation) 을 Cerebras 엔지니어링 팀이 어떻게 설계했는지 정리한 기술 해설입니다. Cerebras는 대규모 AI 가속기(웨이퍼 스케일 엔진)를 만드는 회사로, 데이터센터 운영, 칩 설계, 하드웨어, 학습, 추론, 클라우드 플랫폼 등 서로 성격이 매우 다른 팀들이 함께 일합니다. 매년 수백 명의 새 직원이 합류하다 보니, 사내 커뮤니케이션 채널은 늘 똑같은 질문들로 채워졌습니다. 어디서 X를 찾을 수 있나요?, Y 전문가가 누구인가요?, Z가 뭔가요? 같은 것들입니다. 이런 질문에 매번 사람이 답하는 것은 비효율적이고, 답을 아는 사람이 자리를 비우면 정보는 곧바로 막혀 버립니다. 기업 내부 지식은 위키, Slack, 코드 저장소, 이슈 트래커 등 수십 개의 도구에 흩어져 있고, 각 도구는 서로 다른 형식과 접근 권한을 가집니다. 이 글이 흥미로운 이유는 단순히 "임베딩을 만들어 벡터 검색을 했다" 는 수준을 넘어, 실제 회사 데이터가 가진 지저분함(짧은 잡담과 긴 커널 설명이 같은 Slack 메시지로 섞여 있는 현실)을 정면으로 다루면서 여러 검색 기법을 융합해 실용적인 정확도를 끌어낸 설계 결정들을 구체적인 수치와 함께 공개했다는 점입니다. 사내 검색이나 코드베이스 검색, 에이전트용 지식 저장소를 만들려는 이들에게 좋은 참고 자료가 됩니다. 데이터가 있는 곳에서 데이터를 만난다: 단일 진실 공급원이라는 환상 조직 안에서 정보를 …

---

## [NVIDIA, RTEB 1위 오픈 임베딩 모델 Nemotron 3 Embed 공개 (feat. RAG, 에이전트 검색)](https://discuss.pytorch.kr/t/nvidia-rteb-1-nemotron-3-embed-feat-rag/11308)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [7월 19, 2026, 11:30오후 UTC](https://discuss.pytorch.kr/t/nvidia-rteb-1-nemotron-3-embed-feat-rag/11308 "2026-07-19T23:30:38Z")

</div>

Nemotron 3 Embed 소개 검색 증강 생성(Retrieval-Augmented Generation, RAG)이나 여러 단계를 거치는 에이전트 워크플로우에서 실제로 답변의 품질을 좌우하는 것은, 거대 언어 모델 자체보다 그 앞단에서 "관련 있는 문서를 얼마나 정확히 찾아오는가"입니다. 검색 단계가 엉뚱한 문서를 가져오면 에이전트는 잘못된 맥락 위에서 추론을 시작하고, 다시 질의하고, 토큰 예산을 낭비하며, 그 잡음을 이후 추론 단계까지 그대로 끌고 갑니다. 이 검색의 첫 단추를 담당하는 것이 바로 임베딩(Embedding) 모델입니다. 임베딩 모델은 질문과 문서를 같은 의미 공간의 밀집 벡터(dense vector)로 바꿔, 벡터 간 유사도만으로 관련 문서를 빠르게 골라낼 수 있게 해 줍니다. NVIDIA가 공개한 Nemotron 3 Embed는 바로 이 검색 품질을 끌어올리면서, 동시에 프로덕션 환경에 배포할 때 필요한 현실적인 선택지(지연 시간, 비용, 처리량)를 함께 제공하는 것을 목표로 한 오픈 임베딩 모델 컬렉션입니다. 세 가지 모델로 구성되며, 그중 플래그십인 8B 모델은 실제 검색 성능을 측정하도록 설계된 RTEB(Retrieval Embedding Benchmark) 다국어 리더보드에서 1위를 기록했습니다. 한국어를 포함한 34개 언어와 코드 검색을 지원하며, 가중치와 학습 데이터, 학습 레시피가 모두 공개되어 있어 자체 인프라에서 검사하고 미세조정(fine-tuning)해 쓸 수 있습니다. 주목할 점은 이 컬렉션이 단순히 "가장 정확한 모델 하나"를 내놓은 것이 아니라, 정확도와 효율의 스펙트럼 전체를 덮도록 세 모델을 함께 설계했다는 점입니다. 정밀도가 절대적으로 중요한 고신뢰 엔터프라이즈 RAG에는 8B 모델을, 지연 시간과 비용이 중요한 대규모 프로덕션 서빙에는 1B 모델을, 그리고 NVIDIA Blackwell 아키텍처에서 최대 처리량을 뽑아내야 하는 환경에는 NVFP4 양자화 변형을 고를 수 있습니다. 최근 Google…

---

## [TencentDB Agent Memory: AI 에이전트를 위한 계층형 로컬 기억 시스템](https://discuss.pytorch.kr/t/tencentdb-agent-memory-ai/11150)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [7월 9, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/tencentdb-agent-memory-ai/11150 "2026-07-09T09:30:02Z")

</div>

TencentDB Agent Memory 소개 TencentDB Agent Memory는 AI 에이전트에게 장기 기억과 단기 기억을 완전 로컬로 제공하는 오픈소스 메모리 시스템입니다. 에이전트를 쓰다 보면 같은 SOP, 프로젝트 배경, 도구 사용 규칙, 출력 형식을 매번 다시 설명하게 되는데, 이런 정보는 반복 입력할 필요도 없고 그렇다고 컨텍스트에 무작정 쏟아부을 것도 아닙니다. 이 프로젝트는 에이전트가 사용자의 작업 방식을 학습하고 과거 맥락을 유지하도록 도와, 사람이 판단과 창작에 집중하도록 하는 것을 목표로 합니다. 가장 큰 설계 원칙은 평면적인 벡터 저장(flat storage)을 거부하고 계층화(layering)와 심볼화(symbolization)를 채택했다는 점입니다. 전통적인 메모리 시스템은 데이터를 조각으로 잘라 평면 벡터 저장소에 쌓기 때문에, 검색이 서로 연결되지 않은 조각들 사이를 헤매는 형태가 되기 쉽습니다. TencentDB Agent Memory는 장기 기억을 L0에서 L3까지의 의미 피라미드로 구성하고, 단기 기억은 Mermaid 심볼 그래프로 압축하는 두 축으로 이 문제에 접근합니다. TencentDB Agent Memory는 Tencent가 개발한 OpenClaw·Hermes용 플러그인으로, 기본 백엔드로 SQLite + sqlite-vec 를 사용하며 외부 API 의존성 없이 로컬에서 동작합니다. 저자는 OpenClaw와 통합했을 때 토큰 사용량이 최대 61.38% 감소하고, 통과율이 상대 기준 51.52% 향상되며, PersonaMem 정확도가 48%에서 76%로 올랐다고 보고합니다(README Highlights 표 기준). 이 수치들은 고립된 단일 턴이 아니라 연속된 장기 세션에서 측정한 값이라고 명시하고 있습니다. TencentDB Agent Memory의 계층형 메모리 구조 TencentDB Agent Memory의 장기 기억은 대화를 위에서부터 점진적으로 추상화하는 4단계 피라미드입니다. 아래는 원문에 포…

---

## [Liquid AI, 엣지용 350M 모델 LFM2.5와 다국어 검색 리트리버 LFM2.5 Retrievers 공개](https://discuss.pytorch.kr/t/liquid-ai-350m-lfm2-5-lfm2-5-retrievers/10808)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 2\
**마지막 업데이트:** [6월 22, 2026, 3:33오전 UTC](https://discuss.pytorch.kr/t/liquid-ai-350m-lfm2-5-lfm2-5-retrievers/10808 "2026-06-22T03:33:22Z")

</div>

LFM2.5와 LFM2.5 Retrievers 소개 Liquid AI가 2026년 들어 엣지(edge) 환경을 겨냥한 소형 모델 제품군을 빠르게 확장하고 있습니다. 먼저 350M 파라미터의 범용 언어 모델 LFM2.5-350M을 내놓아 자기보다 두 배 이상 큰 모델을 여러 벤치마크에서 앞질렀고, 이어서 같은 백본 위에 올린 두 개의 다국어 검색(retrieval) 모델 LFM2.5-Embedding-350M과 LFM2.5-ColBERT-350M을 공개했습니다. 세 모델 모두 노트북, 스마트폰, 심지어 라즈베리파이에서도 돌아갈 만큼 작으면서, 11개 언어를 빠르고 안정적으로 처리합니다. 이 글의 목적은 단순히 새 모델 출시 소식을 전하는 것이 아닙니다. Liquid AI의 모델은 우리가 흔히 보는 트랜스포머(Transformer) 기반 거대 언어 모델과는 설계 철학과 내부 구조가 상당히 다릅니다. 그래서 이 글에서는 Liquid Foundation Models(LFM) 라는 모델군이 무엇인지, 어떤 구조로 어떻게 빠른 속도를 얻는지, 그리고 그 장단점은 무엇인지부터 차근차근 살펴본 뒤, LFM의 두 번째 세대인 LFM2와 그 개선판인 LFM2.5, 마지막으로 검색에 특화된 LFM2.5 Retrievers까지 이어서 설명합니다. LFM을 처음 접하는 분이라도 이 글 하나로 전체 그림을 잡을 수 있도록 구성했습니다. 핵심을 한 문장으로 요약하면 이렇습니다. LFM은 "엣지 기기에서 빠르고 가볍게 도는 것"을 최우선 목표로 두고, 어텐션 위주의 일반적인 트랜스포머 대신 단거리 합성곱과 소수의 어텐션을 섞은 하이브리드 구조를 하드웨어 제약 아래에서 직접 탐색해 만든 모델군입니다. 그리고 LFM2.5 Retrievers는 이 생성용 디코더 백본을 검색용 양방향 인코더로 개조한 첫 사례입니다. Liquid Foundation Models(LFM)이란 무엇인가 LFM을 만든 Liquid AI는 MIT CSAIL에서 출발한 스타트업으로, 창업자와 핵심 연구진(Ram…

---

## [Zvec: 앱에 직접 내장되는 프로세스 내(In-Process) 벡터 데이터베이스](https://discuss.pytorch.kr/t/zvec-in-process/10749)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [6월 18, 2026, 11:30오전 UTC](https://discuss.pytorch.kr/t/zvec-in-process/10749 "2026-06-18T11:30:02Z")

</div>

Zvec 소개 Zvec은 애플리케이션 프로세스 안에서 직접 동작하는 인프로세스(in-process) 벡터 데이터베이스입니다. 별도의 서버를 띄우거나 복잡한 설정을 거치지 않고, 코드가 실행되는 곳이라면 노트북, 서버, CLI 도구, 엣지 장비 어디에서든 그대로 유사도 검색(similarity search)을 수행할 수 있습니다. Alibaba 그룹 내부에서 운영에 쓰이며 다듬어진 프로젝트로, 저지연(low-latency)과 확장성을 동시에 노립니다. 벡터 검색만 제공하는 도구와 달리 Zvec은 조밀(dense) 벡터와 희소(sparse) 벡터를 모두 지원하고, 전문 검색(Full-Text Search)과 스칼라 필터를 하나의 질의로 묶는 하이브리드 검색(hybrid search)을 제공합니다. 인덱스도 메모리에 올리는 방식부터 디스크에 두는 방식까지 데이터 규모에 맞춰 고를 수 있어, 작은 실험용 컬렉션부터 대규모 데이터셋까지 같은 라이브러리로 다룹니다. 2026년 6월 12일 공개된 v0.5.0에서는 네이티브 전문 검색과 디스크 기반 DiskANN 인덱스, Go와 Rust SDK, 시각화 도구인 Zvec Studio가 추가됐습니다. 본 게시물에서는 Zvec의 인프로세스 구조와 하이브리드 검색, 인덱스 선택지, 그리고 설치와 기본 사용법을 정리합니다. Zvec의 인프로세스 구조와 동작 방식 Zvec은 라이브러리 형태로 애플리케이션에 직접 링크되어, 데이터베이스가 별도 프로세스가 아니라 애플리케이션 프로세스 안에서 함께 돕니다. 이 구조에서는 네트워크 왕복 없이 함수 호출만으로 검색이 끝나며, 설치한 다음 몇 줄의 코드로 컬렉션을 만들고 곧바로 질의할 수 있습니다. 운영해야 할 서버나 데몬이 없으므로 배포 구성이 단순해진다는 점이 인프로세스 방식의 핵심 이점입니다. 저장 측면에서는 쓰기 전 로그(Write-Ahead Logging, WAL)로 영속성을 보장해, 프로세스가 비정상 종료되거나 전원이 꺼지는 상황에서도 기록한 데이터가 사라지지 않습니다. …

---

## [Jina AI, 텍스트와 이미지, 오디오, 비디오를 하나의 임베딩 공간에 담는 jina-embeddings-v5-omni 공개](https://discuss.pytorch.kr/t/jina-ai-jina-embeddings-v5-omni/10207)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [5월 13, 2026, 12:30오후 UTC](https://discuss.pytorch.kr/t/jina-ai-jina-embeddings-v5-omni/10207 "2026-05-13T12:30:56Z")

</div>

jina-embeddings-v5-omni 소개 Jina AI가 텍스트 임베딩 전문 모델인 jina-embeddings-v5-text 시리즈를 확장하여, 텍스트, 이미지, 오디오, 비디오, PDF까지 모두 동일한 의미 공간에 매핑하는 옴니-모달 임베딩 모델군인 jina-embeddings-v5-omni 를 공개했습니다. 이번 공개에는 1.57B 규모의 jina-embeddings-v5-omni-small과 0.95B 규모의 jina-embeddings-v5-omni-nano 두 가지 변형이 포함되어 있으며, 함께 공개된 논문 "jina-embeddings-v5-omni: Geometry-preserving Embeddings via Locked Aligned Towers"에서는 이 모델의 기반 기법을 GELATO(Geometry-preserving Embeddings via Locked Aligned TOwers) 라는 이름으로 정리하고 있습니다. 기존의 멀티모달 임베딩 모델은 보통 텍스트와 비전, 오디오 인코더를 모두 끝에서 끝까지(end-to-end) 함께 학습시키는 방식을 사용해 왔습니다. LanguageBind나 NVIDIA의 Omni-Embed-Nemotron, LCO-Embedding 시리즈처럼 최근의 옴니-모달 임베딩 모델들도 모두 이 흐름 위에 있습니다. 그러나 이런 방식은 학습 비용이 매우 크고, 새 모달리티를 추가할 때마다 텍스트 임베딩 자체도 미세하게 바뀌어 버려서, 이미 구축해 둔 벡터 인덱스를 그대로 사용할 수 없다는 운영상의 문제가 있었습니다. 옴니-모달리티(Omni-Modality) 라는 단어가 점점 흔해지고 있지만, 실제 검색/RAG 파이프라인 관점에서 중요한 질문은 "기존에 잘 동작하던 텍스트 검색을 깨뜨리지 않고, 이미지/오디오/비디오를 같은 인덱스에 끼워 넣을 수 있는가" 입니다. jina-embeddings-v5-omni는 바로 이 지점을 정조준한 모델로, 텍스트 백본을 동결(freeze)한 채 비전/오디오 인코더…

---

## [BidirLM, 기존의 LLM을 오픈소스 옴니모달 양방향 인코더(Omni-modal Bidirectional Encoder)로 변환하는 레시피와 모델 공개](https://discuss.pytorch.kr/t/bidirlm-llm-omni-modal-bidirectional-encoder/9648)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [4월 9, 2026, 9:30오후 UTC](https://discuss.pytorch.kr/t/bidirlm-llm-omni-modal-bidirectional-encoder/9648 "2026-04-09T21:30:14Z")

</div>

BidirLM 소개: 버려진 GPU 시간을 되살리는 아이디어 오픈소스 생태계에는 이미 수백만 GPU 시간이 투입되어 학습된 Gemma3, Qwen3, Qwen3-VL, Qwen3-ASR 같은 수많은 특화 Causal 디코더 모델이 존재합니다. 그러나 이들은 대부분 생성(generation) 작업에만 활용되고, 검색(retrieval)이나 임베딩처럼 표현(representation)이 핵심인 작업에는 거의 쓰이지 못해왔습니다. 문장/문서 임베딩 시장은 여전히 BERT 계열이나 별도로 재훈련한 특수 인코더가 주도하고 있고, 이 과정에서 이미 존재하는 디코더 모델들의 지식은 거의 재활용되지 못합니다. BidirLM은 바로 이 격차를 메우기 위해 등장했습니다. Nicolas Boizard, Théo Deschamps-Berger 등이 공개한 이 연구는, 어떤 causal 디코더 LLM이든 강력한 양방향 인코더(Bidirectional Encoder) 로 변환하는 완전한 오픈소스 레시피를 제시합니다. Gemma3와 Qwen3를 대상으로 한 체계적인 ablation을 통해 "어떤 적응 전략이 실제로 효과가 있는가"를 규명하고, 원본 사전학습 데이터 없이도 규모를 키울 수 있는 방법까지 제안했습니다. 여기서 한 걸음 더 나아가, 저자들은 가중치 병합(weight merging) 기법을 활용해 특화된 Causal 모델(비전, 음성 등)의 능력을 텍스트 인코더에 흡수시키는 실험을 진행했고, 그 결과물이 바로 BidirLM-Omni-2.5B입니다. 이렇게 생성한 BidirLM-Omni-2.5B 컴팩트 모델은 텍스트, 이미지, 오디오를 모두 다루면서 기존 옴니모달 및 단일모달 특화 모델들을 벤치마크에서 앞섭니다. Causal 모델을 양방향으로 만드는 "올바른" 레시피 이러한 시도는 이전부터 있었지만, 지금까지는 정리되지 않고 혼란스러웠습니다. 어떤 연구는 마스킹 단계를 건너뛰고 바로 대조 학습(Contrastive Training)에 돌입하고, 다른 연구는 양방향 어텐…

---

## [Jina Grep: Jina AI가 공개한 Apple Silicon 기반의 고속 로컬 시맨틱 검색 CLI 도구](https://discuss.pytorch.kr/t/jina-grep-jina-ai-apple-silicon-cli/9213)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [3월 14, 2026, 2:30오전 UTC](https://discuss.pytorch.kr/t/jina-grep-jina-ai-apple-silicon-cli/9213 "2026-03-14T02:30:52Z")

</div>

jina-grep 소개 최근 소프트웨어 개발 환경에서는 단순한 문자열 일치를 넘어 코드의 의미(Semantics)를 파악하여 검색하는 시맨틱 검색의 중요성이 점차 커지고 있습니다. 기존의 터미널 명령어인 grep은 정규 표현식이나 정확한 단어 일치에 의존해야 했기 때문에, 변수명이나 주석이 다르게 작성되어 있으면 원하는 코드를 찾기 어려웠습니다. 이러한 한계를 극복하기 위해 Jina AI에서 새롭게 공개한 오픈소스 도구가 바로 jina-grep입니다. jina-grep는 Jina AI의 최신 임베딩 모델인 Jina Embeddings v5를 활용하여 로컬 환경에서 자연어 기반의 의미론적 검색을 수행할 수 있게 해주는 강력한 커맨드라인 인터페이스(CLI) 도구입니다. 개발자는 "데이터베이스 연결 풀링(database connection pooling)"이나 "메모리 누수(memory leak)"와 같은 자연어를 입력하여, 해당 의미나 문맥을 담고 있는 코드 라인이나 텍스트 문서를 정확하게 찾아낼 수 있습니다. 이는 거대한 코드베이스를 탐색하거나 복잡한 디버깅을 수행할 때 작업 효율을 비약적으로 향상시켜 줍니다. 가장 눈에 띄는 기술적 특징은 Apple Silicon 아키텍처에 완벽하게 최적화되어 있다는 점입니다. 무거운 PyTorch 런타임이나 Transformers 라이브러리에 전혀 의존하지 않으며, Apple의 자체 머신러닝 프레임워크인 MLX를 기반으로 순수하게 Metal GPU 위에서 동작합니다. 특히, 텍스트 모델의 경우 단일 베이스 모델을 메모리 상에 올려두고 필요에 따라 동적 LoRA 어댑터 스위칭(Dynamic LoRA adapter switching) 을 수행하여 단 20ms 만에 작업 컨텍스트를 전환하는 놀라운 효율성을 보여줍니다. 클라우드 API를 호출하지 않고 로컬에서 모든 처리가 이루어지므로, 민감한 사내 코드가 외부로 유출될 우려 또한 전혀 없습니다. Jina Grep vs. 기존 검색 도구 비교 전통적인 grep 명…

---

## [Perplexity, 웹 스케일 검색을 위한, 양방향 디퓨전 어텐션을 적용한 다국어 임베딩 모델 pplx-embed 2종 공개](https://discuss.pytorch.kr/t/perplexity-pplx-embed-2/9108)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [3월 2, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/perplexity-pplx-embed-2/9108 "2026-03-02T03:30:35Z")

</div>

Perplexity가 공개한 임베딩 모델 pplx-embed 소개 Perplexity에서 새롭게 공개한 텍스트 임베딩 모델 제품군인 pplx-embed는 웹 스케일의 방대한 실제 검색 환경과 검색 증강 생성 시스템을 최적화하기 위해 설계되었습니다. 이 모델 시리즈는 각각 6억 개와 40억 개의 매개변수를 가진 두 가지 규모로 제공되며, 독립적인 텍스트를 처리하는데 특화된 pplx-embed-v1 모델과 문서의 전체적인 맥락을 이해하여 청크 단위의 의미를 파악하는 pplx-embed-context-v1 모델로 나뉘어 출시되었습니다. 기존의 많은 임베딩 모델들이 텍스트 앞에 특정 지시어를 붙여야만 최적의 성능을 낼 수 있었던 것과 달리, 해당 제품군은 이러한 지시어 튜닝 과정을 배제하여 프롬프트 선택에 따른 오버헤드를 줄이고 인덱싱 파이프라인의 불안정성을 해소한 것이 특징입니다. pplx-embed 모델들은 수십억 개의 웹 페이지를 처리하고 저장하는 데 발생하는 막대한 스토리지 비용 문제를 해결하기 위해, 양자화 인식 학습 기법을 적용하여 설계되었습니다. 사후에 압축하는 방식을 사용할 때 발생할 수 있는 성능 저하를 방지하기 위해 학습 단계에서부터 네이티브 INT8 및 이진 양자화 임베딩을 출력하도록 만들어졌으며, 이를 통해 32비트 부동소수점 대비 저장 공간을 각각 4배에서 최대 32배까지 절감할 수 있게 해줍니다. 또한, 최대 3만 2천 토큰의 긴 컨텍스트 윈도우를 지원하여 방대한 문서를 한 번에 처리할 수 있으며, 필요에 따라 차원 수를 축소할 수 있는 기법을 적용하여 사용자가 벡터 데이터베이스의 스토리지와 검색 속도를 유연하게 조절할 수 있도록 구현되었습니다. RAG와 같은 현대의 검색 파이프라인에서 임베딩(Embedding)은 가장 앞단에서 수많은 문서를 걸러내는 1차 리트리버(Retriever) 역할을 수행합니다. 따라서 속도와 정확도, 그리고 비용 효율성이 모두 확보되어야 하는데, 0.6B 모델은 지연 시간이 짧고 가벼운 임베딩…

---

## [FastEmbed-rs🦀: Rust로 구현된 벡터 임베딩(embedding)과 재정렬(Reranking) 라이브러리](https://discuss.pytorch.kr/t/fastembed-rs-rust-embedding-reranking/7872)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [9월 30, 2025, 9:30오전 UTC](https://discuss.pytorch.kr/t/fastembed-rs-rust-embedding-reranking/7872 "2025-09-30T09:30:19Z")

</div>

FastEmbed-rs :crab: 소개 FastEmbed-rs는 Rust 언어로 작성된 임베딩(Embedding) 및 재정렬(Reranking) 라이브러리로, 원래 Qdrant의 fastembed 프로젝트를 Rust 생태계에 맞게 다시 구현한 버전입니다. 이 라이브러리는 텍스트, 이미지 데이터를 벡터 형태로 변환하여 검색, 분류, 추천 시스템 등에 활용할 수 있게 해줍니다. 최근 대규모 언어 모델(LLM)과 멀티모달 AI의 발전으로 벡터 데이터베이스와 임베딩 기술이 핵심 요소로 자리잡으면서, Rust 기반의 고성능·저비용 솔루션에 대한 수요가 커지고 있습니다. Rust의 장점인 빠른 실행 속도와 안전한 메모리 관리 덕분에, FastEmbed-rs는 Python 기반의 라이브러리보다 성능이 우수하면서도 의존성 부담이 적습니다. 특히 Tokio와 같은 비동기 런타임에 의존하지 않고 동기 방식으로 동작하기 때문에, Rust 생태계 내 다양한 프로젝트에 쉽게 통합할 수 있습니다. 이 프로젝트는 ONNX 런타임을 기반으로 모델 추론을 처리하고, Hugging Face의 tokenizers를 활용해 빠른 토큰화 과정을 지원합니다. 따라서 텍스트, 이미지, 다국어 데이터까지 다양한 AI 응용에 적합한 임베딩을 제공합니다. Rust 개발자에게는 “빠르고 안전한 AI 임베딩 도구”라는 점에서 매우 매력적인 라이브러리입니다. FastEmbed는 Rust뿐만 아니라 Python, Go, JavaScript 등 다양한 언어 생태계에 구현체가 존재합니다. Python 버전은 가장 먼저 등장했고 Hugging Face 모델과의 호환성이 뛰어나지만, 속도와 메모리 효율성 면에서는 Rust 버전이 강점이 있습니다. Go 및 JavaScript 버전은 웹 서비스 및 마이크로서비스 환경에 특화되어 있는 반면, Rust 버전은 시스템 레벨에서 고성능 연산이 필요한 경우 적합합니다. 즉, 대규모 데이터 처리와 실시간 검색 시스템 구축에는 Rust 버전이 특히 유리하며, Python…

---

## [Embedding Explorer: 로컬 데이터를 사용하여 여러가지 임베딩 모델들을 평가하고 비교하는 오픈소스](https://discuss.pytorch.kr/t/embedding-explorer/7834)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [9월 26, 2025, 9:30오전 UTC](https://discuss.pytorch.kr/t/embedding-explorer/7834 "2025-09-26T09:30:24Z")

</div>

Embedding Explorer 소개 텍스트 임베딩(Text Embedding)은 최근 자연어 처리(NLP) 분야에서 검색, 추천, 의미 기반 분류 등 다양한 애플리케이션의 핵심 요소로 자리잡고 있습니다. 하지만 실제 현업에서 여러 임베딩 모델을 비교하고 성능을 평가하는 과정은 생각보다 번거롭습니다. 다양한 API 엔드포인트를 바꿔가며 테스트하거나, 벡터를 직접 추출해 노트북에 붙여넣는 방식으로 실험하는 것은 시간이 많이 들고 효율적이지 않습니다. 이러한 문제를 해결하기 위해 등장한 프로젝트가 바로 Embedding Explorer입니다. Embedding Explorer는 브라우저에서 동작하는 경량 웹 애플리케이션으로, 사용자가 데이터 소스를 업로드하고 다양한 임베딩 모델을 설정해 벡터를 생성한 뒤, 유사도 검색을 통해 모델별 품질을 직접 비교할 수 있도록 지원합니다. 모든 과정은 로컬 환경에서 진행되며, 추가 서버나 클라우드 인프라가 필요하지 않습니다. 이로써 개발자는 빠르고 직관적으로 여러 모델을 비교할 수 있고, 최종적으로 자신에게 가장 적합한 임베딩 모델을 선택하는 데 도움을 받을 수 있습니다. Embedding Explorer 프로젝트는 Dart를 기반으로 작성되었으며, Jaspr 프레임워크와 libSQL을 활용하여 데이터 관리 및 UI 처리를 효율적으로 구현했습니다. 특히 libSQL WASM을 통해 브라우저 내에서 영속적인 데이터 저장이 가능하다는 점은 주목할 만합니다. 따라서 Embedding Explorer는 단순한 데모 도구를 넘어 실제 데이터 기반의 벡터 실험 환경을 제공합니다. 일반적으로 임베딩 모델을 비교할 때는 Python 기반의 Jupyter Notebook이나 특정 벡터 데이터베이스(예: Pinecone, Weaviate, Milvus)를 이용하는 경우가 많습니다. 하지만 이 방식은 설정이 복잡하거나 외부 인프라 의존성이 생긴다는 단점이 있습니다. Embedding Explorer는 설치형 서버나 복잡한 백엔드…

---

## [EmbeddingGemma: Google이 공개한, On-Device Embedding을 위한 308M 규모의 소형 모델](https://discuss.pytorch.kr/t/embeddinggemma-google-on-device-embedding-308m/7752)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [9월 15, 2025, 9:31오후 UTC](https://discuss.pytorch.kr/t/embeddinggemma-google-on-device-embedding-308m/7752 "2025-09-15T21:31:02Z")

</div>

EmbeddingGemma 소개 구글 딥마인드가 새롭게 공개한 EmbeddingGemma는 온디바이스(On-device) 환경에서 동작하는 임베딩 모델로, 성능과 효율성 모두를 갖춘 것이 특징입니다. 모델 크기는 3억 800만(380M) 규모로 비교적 작지만, 그 성능은 기존의 두 배 크기 모델과 견줄 수 있을 정도입니다. 이 모델은 인터넷 연결이 없는 상태에서도 문맥 검색(RAG, Retrieval-Augmented Generation)이나 의미 기반 검색(semantic search)을 구현할 수 있도록 설계되어, 개인 데이터 보호와 빠른 응답 속도가 중요한 모바일·엣지 환경에서 특히 유용합니다. EmbeddingGemma는 Gemma 3 아키텍처를 기반으로 하며, 100개 이상의 언어를 학습해 다국어 환경에서도 강력한 성능을 발휘합니다. 또한 양자화(Quantization)를 통해 RAM 사용량을 200MB 미만으로 줄였으며, 모바일 기기나 PC 등 일상적인 하드웨어에서 원활하게 작동합니다. 이를 통해 개발자들은 인터넷 연결 없이도 개인 문서 검색, 오프라인 챗봇, 맞춤형 정보 검색 시스템 등을 구축할 수 있게 되었습니다. EmbeddingGemma 모델이 주목받는 이유는 단순히 경량화된 모델이라는 점뿐만 아니라, 다양한 도구와의 호환성을 갖추고 있다는 점입니다. Hugging Face, Kaggle, Vertex AI는 물론, sentence-transformers, llama.cpp, MLX, Ollama, LiteRT, LangChain 같은 인기 있는 오픈소스 프레임워크와도 쉽게 통합할 수 있어 실무에서 곧바로 활용 가능하다는 점이 강점입니다. Gemini Embedding과 비교 EmbeddingGemma는 ‘온-디바이스’ 활용을 위한 모델로 설계된 반면, 구글이 제공하는 Gemini Embedding은 서버 사이드에서 대규모 애플리케이션을 위한 고성능 임베딩 모델입니다. 따라서 개인화된 검색, 오프라인 …

---

## [Frames of Mind: R1 모델의 사고 과정을 임베딩과 차원 축소(t-SNE)를 통해 시각화하는 프로젝트](https://discuss.pytorch.kr/t/frames-of-mind-r1-t-sne/6171)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [2월 19, 2025, 11:30오전 UTC](https://discuss.pytorch.kr/t/frames-of-mind-r1-t-sne/6171 "2025-02-19T11:30:19Z")

</div>

Frames of Mind 프로젝트 소개 Frames of Mind는 R1 모델의 '사고 과정'을 시각적으로 표현하려고 시도하는 프로젝트입니다. OpenAI의 임베딩 API와 t-SNE를 활용해 R1 모델이 문제를 해결하는 과정을 단계별로 시각화할 수 있습니다. 특히, 연속된 사고 간의 이동 거리(cosine similarity)를 측정하고 이를 그래픽으로 나타내는 점이 흥미롭습니다. AI의 의사결정 과정을 깊이 이해하고 싶은 분들에게 유용할 것입니다. Frames of Mind 프로젝트가 모델의 사고 과정을 시각화하는 방식은 다음과 같습니다: 사고 과정(Chain-of-Thought, CoT) 저장: 모델의 단계별 사고를 텍스트로 저장합니다. 텍스트 임베딩 변환: OpenAI API를 이용해 저장된 텍스트를 벡터 임베딩으로 변환합니다. 임베딩 시각화: - t-SNE 알고리즘을 사용해 임베딩을 2D 공간에서 시각화합니다. 이 과정이 진행되면 AI가 특정 질문에 대해 어떤 식으로 사고하는지를 애니메이션으로 확인할 수 있습니다. 예를 들어, “자전거가 어떻게 작동하는가(Describe how a bicycle works)“라는 질문에 대한 사고 과정은 아래와 같이 표현됩니다: 현재까지는 모델의 출력을 텍스트로만 읽어보며 사고 과정을 확인할 수 있었던 반면, Frames of Mind 프로젝트는 이를 애니메이션과 그래프를 통해 직관적으로 이해할 수 있도록 설계되었습니다. 또한, 사고 단계 간의 거리(예: 연속된 사고 사이의 cosine similarity)를 측정하여 사고의 흐름이 어떻게 변화하는지도 분석할 수 있습니다. 위 예시와 같이 한 단계의 사고(Thought i)에서 다음 단계(Thought i+1)로 넘어갈 때 변화의 크기(거리, Consecutive Distance)를 측정하고 시각화 할 수도 있습니다. :github: Frames of Mind GitHub 저장소 https://github.com/dhealy05/frames\_o…

---

## [Hugging Face, 최대 400배 빠른 CPU 기반 정적 임베딩(Static Embedding) 모델 공개 (feat. Sentence Transformers)](https://discuss.pytorch.kr/t/hugging-face-400-cpu-static-embedding-feat-sentence-transformers/5886)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [1월 16, 2025, 9:36오전 UTC](https://discuss.pytorch.kr/t/hugging-face-400-cpu-static-embedding-feat-sentence-transformers/5886 "2025-01-16T09:36:05Z")

</div>

임베딩 및 정적 임베딩 모델 소개 임베딩(Embeddings)은 자연어 처리(NLP)에서 매우 유용한 도구로, 텍스트, 이미지, 오디오 등 복잡한 데이터를 고정된 크기의 벡터로 변환해 다양한 작업에 활용됩니다. 기존 임베딩 모델들은 뛰어난 성능을 제공하지만, 주로 트랜스포머 기반 구조로 인해 고비용, 느린 추론 속도라는 한계를 가지고 있었습니다. Hugging Face는 최신 학습 기술을 사용해 \*\*정적 임베딩 모델(Static Embedding Model)\*\*을 재조명하고, 트랜스포머 없이도 효율적이고 빠른 임베딩 모델을 만들 수 있음을 입증했습니다. 여기에는 대조학습(Contrastive Learning)과 MRL(Matryoshka Representation Learning) 같은 혁신적인 기법이 적용되었습니다. Hugging Face가 제안한 이 방법으로 학습된 모델은 CPU에서 기존의 SotA(State-of-the-Art) 임베딩 모델보다 100배 ~ 400배 가량 빠르게 동작합니다. 이 모델은 85% 이상의 성능을 유지하며 저전력 장치, 브라우저 내 실행, 엣지 컴퓨팅, 임베디드 애플리케이션에서 유용하게 사용할 수 있습니다. 모델 속도(비교 기준) 성능 유지율 All-MPNET-base-v2 1x 100% Multilingual-E5-small 1x 100% Static Retrieval 모델 100x~400x 85% 이상 정적 임베딩 모델은 트랜스포머 기반 모델의 복잡한 연산을 단순화해, 토큰을 사전에서 찾는 수준의 연산으로 대체합니다. 이를 통해 초고속 추론이 가능해졌습니다. 정적 임베딩 모델(Static Embedding Model)의 주요 특징 고속 추론: CPU에서 100~400배 빠른 속도로 실행. 낮은 리소스 사용: 엣지 디바이스나 브라우저에서도 사용 가능. 현대적 학습 기법: 대조학습: 임베딩 간의 유사도를 학습. MRL: 임베딩 벡터를 작은 차원으로 줄여도 성능 유지. 다양한 데…

---

## [Reservoirs Lab, Postgres를 위한 VectorDB GUI 및 데이터 인사이트 App 🐘✨](https://discuss.pytorch.kr/t/reservoirs-lab-postgres-vectordb-gui-app/5740)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [12월 24, 2024, 11:30오전 UTC](https://discuss.pytorch.kr/t/reservoirs-lab-postgres-vectordb-gui-app/5740 "2024-12-24T11:30:17Z")

</div>

Reservoirs Lab 소개 벡터 데이터의 시각화 및 탐색은 딥러닝 모델이 생성한 임베딩 데이터를 활용하는 많은 애플리케이션에서 중요한 요소입니다. Reservoirs Lab은 Postgres 데이터베이스에 저장된 고차원 벡터 데이터를 쉽게 시각화하고, 메타데이터와 벡터 간의 관계를 비롯한 데이터 간의 유사성을 탐구할 수 있는 도구입니다. Electron 기반으로 설계된 이 애플리케이션은 로컬에서 실행되며, 데이터 프라이버시를 보장하면서도 사용자 친화적인 인터페이스를 제공합니다. Reservoirs Lab 프로젝트는 다음과 같은 배경에서 시작되었습니다: 임베딩 데이터의 중요성: 자연어 처리(NLP), 이미지 처리, 추천 시스템 등 다양한 분야에서 딥러닝 모델이 생성한 벡터 임베딩은 데이터의 의미론적 관계를 포착하는 중요한 역할을 합니다. 시각화와 탐색의 필요성: 벡터 임베딩을 단순히 저장하는 것만으로는 한계가 있습니다. 데이터의 구조적 특성을 이해하고, 클러스터링을 시각적으로 탐색할 수 있어야 데이터를 효과적으로 활용할 수 있습니다. 개발자의 편의성: Reservoirs Lab은 설치 및 실행이 간단하며, 로컬 환경에서 모든 작업이 이루어져 데이터 프라이버시 문제를 해결합니다. 주요 기능 Postgres 데이터베이스 연결: Reservoirs Lab은 사용자가 입력한 연결 문자열(Connection String)을 사용해 Postgres 데이터베이스에 바로 연결합니다. 데이터는 원격 서버로 전송되지 않으며, 로컬 환경에서 안전하게 작업이 진행됩니다. 벡터 데이터 시각화: 고차원 벡터 데이터를 UMAP(Uniform Manifold Approximation and Projection) 알고리즘을 사용해 2차원 또는 3차원으로 축소합니다. UMAP은 벡터 간의 유사성을 유지하면서 데이터를 시각적으로 탐색할 수 있도록 돕습니다. 코사인 유사도 기반 탐색: 특정 데이터 포인트를 클릭하면 해당 포인트와 코사인 유사도(Cosine Sim…

---

## [VoyageAI, 새로운 범용 임베딩 모델 Voyage-3 및 Voyage-3-lite 공개](https://discuss.pytorch.kr/t/voyageai-voyage-3-voyage-3-lite/5578)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [11월 25, 2024, 3:19오전 UTC](https://discuss.pytorch.kr/t/voyageai-voyage-3-voyage-3-lite/5578 "2024-11-25T03:19:48Z")

</div>

Voyage-3 및 Voyage-3-Lite 모델 소개 VoyageAI는 새로운 세대의 범용 임베딩 모델 voyage-3 및 voyage-3-lite를 발표하며, 검색 품질, 비용 절감, 그리고 대규모 데이터베이스 활용 효율성을 대폭 향상시켰습니다. 이전 모델인 Voyage 2 시리즈는 도메인 특화 모델(voyage-code-2, voyage-law-2, voyage-finance-2, voyage-multilingual-2)로 각 산업 분야에서 주목받았으며, 이번에는 이를 뛰어넘는 범용성과 확장성을 제공하는 모델을 선보였습니다. VoyageAI의 임베딩 모델들은 API를 통해 사용할 수 있으며, 초기 200M 토큰은 무료로 제공됩니다. 특히, Voyage 3 시리즈는 경쟁 모델(OpenAI, Cohere, E5 Mistral 등)과 비교했을 때 검색 품질과 비용 효율성에서 모두 우수합니다: Voyage 3 모델의 효율적인 임베딩 크기는 벡터 데이터베이스 비용도 최대 3배 절감할 수 있게 합니다. 또한, 한국어를 포함한 다국어 검색 품질은 지연 시간이 더 짧고 비용은 절반 가량으로 다른 경쟁 모델들 대비 우수한 성능을 보입니다: Voyage 3 시리즈 주요 특징 Voyage-3 모델 Voyage-3는 뛰어난 성능과 경제성을 자랑하는 범용 임베딩 모델로, 다양한 도메인과 작업에서 기존 모델 대비 우수한 검색 품질과 효율성을 제공합니다: 임베딩 크기: 1024차원(OpenAI의 3072 대비 3배 작음). 비용 효율성: OpenAI v3 large 대비 2.2배 낮은 비용. 컨텍스트 길이: 32K 토큰 지원(OpenAI 8K 대비 4배 확장). 성능 개선: OpenAI v3 large 대비 7.55% 향상된 검색 품질. Voyage-3-lite 모델 Voyage-3-lite는 낮은 비용과 빠른 처리 속도를 중시하는 사용자에게 적합한 경량화된 모델입니다. \* 임베딩 크기: 512차원(OpenAI 3072 대비 6배 …

---

## [Cohere, 이미지와 텍스트의 교차 검색이 가능한 멀티모달 임베딩 모델 Embed 3 출시](https://discuss.pytorch.kr/t/cohere-embed-3/5389)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [10월 25, 2024, 12:14오후 UTC](https://discuss.pytorch.kr/t/cohere-embed-3/5389 "2024-10-25T12:14:13Z")

</div>

Multimodal Embed 3 모델 소개 Embed 3는 Cohere가 새롭게 발표한 멀티모달 AI 검색 모델로, 텍스트와 이미지 데이터를 통합하여 한층 향상된 검색 기능을 제공합니다. 기존에는 텍스트 기반 검색이 주를 이뤘으나, Embed 3는 텍스트와 이미지를 동일한 벡터 공간에 배치해 상호 연관된 데이터를 더 정확히 검색할 수 있습니다. 이 모델은 엔터프라이즈 AI 솔루션을 필요로 하는 기업들에게 고도화된 검색 및 데이터 활용을 가능하게 하며, 100개 이상의 언어를 지원해 글로벌 비즈니스 확장성에도 유리합니다. Embed 3는 CLIP 등 기존의 멀티모달 모델과 달리 텍스트와 이미지 데이터를 단일 벡터 공간에 배치하는 것이 특징입니다. 이는 텍스트와 이미지 간 검색 편향을 줄이고, 텍스트와 이미지 모두에서 유사성을 균형 있게 평가할 수 있게 합니다. 예를 들어, CLIP은 텍스트 중심으로 결과를 도출하는 반면, Embed 3는 의미 중심의 일관된 검색 결과를 제공합니다. Embed 3 모델의 주요 기능 다중 언어 지원: Embed 3는 100개 이상의 언어를 지원하며, 텍스트-이미지 검색을 위한 다국어 확장성을 갖추고 있습니다. 복잡한 벡터 공간 활용: 텍스트와 이미지를 통합 벡터 공간에서 처리하여, 데이터 검색 및 추천의 정확도를 높입니다. 상용화된 사례들: 그래프 및 차트, 전자상거래 제품 카탈로그, 디자인 파일 및 템플릿 등 다양한 비즈니스 데이터를 효과적으로 검색할 수 있습니다. 높은 정확도: BEIR, Flickr, CoCo, eCommerce 데이터셋을 기반으로 한 평가에서 높은 성능을 보이며, 노이즈가 많은 현실 데이터에서도 안정적인 성능을 유지합니다. 사용법 Embed 3는 Cohere 플랫폼과 Microsoft Azure AI Studio에서 사용할 수 있으며, Amazon SageMaker와 개인 전용 클라우드(VPC) 배포도 지원합니다. 사용자는 API 문서와 플랫폼 통합…

---

## [Jina AI, Embedding을 위한 jina-embeddings-v3 모델 공개](https://discuss.pytorch.kr/t/jina-ai-embedding-jina-embeddings-v3/5212)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [9월 18, 2024, 7:13오후 UTC](https://discuss.pytorch.kr/t/jina-ai-embedding-jina-embeddings-v3/5212 "2024-09-18T19:13:58Z")

</div>

jina-embeddings-v3 모델 소개 jina-embeddings-v3는 Jina AI가 개발한 다국어 및 다중 작업 텍스트 임베딩 모델로, 다양한 자연어 처리(NLP) 애플리케이션에 적합합니다. 이 모델은 Jina-XLM-RoBERTa 아키텍처를 기반으로 하며, \*\*Rotary Position Embeddings (RoPE)\*\*를 통해 최대 8192 토큰의 긴 입력 시퀀스를 처리할 수 있습니다. 또한, LoRA 어댑터를 통해 작업별 임베딩 생성을 지원합니다. jina-embeddings-v3 모델을 사용하려면 Jina 임베딩 API를 사용하거나 Transformers 패키지를 통해 직접 통합할 수 있습니다. 이번에 Jina AI에서 공개한 임베딩 모델은 100개 언어를 지원하지만, 아랍어, 중국어, 영어, 프랑스어, 독일어, 한국어, 러시아어, 스페인어 등의 30개 언어에 특히 최적화되어 있습니다. Feature Description Base jina-XLM-RoBERTa Parameters Base 559M Parameters w/ LoRA 572M Max input tokens 8192 Max output dimensions 1024 Layers 24 Vocabulary 250K Supported languages 89 Attention FlashAttention2, also works w/o Pooling Mean pooling jina-embeddings-v3 모델의 주요 기능은 다음과 같습니다: 확장된 시퀀스 길이: RoPE를 사용하여 최대 8192 토큰의 시퀀스를 지원합니다. 작업별 임베딩: task 인자를 통해 다양한 작업에 맞게 임베딩을 커스터마이징할 수 있습니다: retrieval.query: 비대칭 검색 작업에서 쿼리 임베딩에 사용. retrieval.passage: 비대칭 검색 작업에서 패시지 임베딩에 사용. separation: 클러스터링 및 …

---

## [E5-V, Multimodal LLM을 활용한 범용 임베딩 프레임워크(Universal Embedding Framework)](https://discuss.pytorch.kr/t/e5-v-multimodal-llm-universal-embedding-framework/4901)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [7월 22, 2024, 1:37오후 UTC](https://discuss.pytorch.kr/t/e5-v-multimodal-llm-universal-embedding-framework/4901 "2024-07-22T13:37:41Z")

</div>

E5-V 소개 E5-V는 멀티모달 대규모 언어 모델(MLLM, Multimodal Large Language Models)을 사용하여 다양한 모달리티의 입력을 통합하는 멀티모달 임베딩 프레임워크입니다. E5-V는 다양한 입력 유형 간의 모달리티 간극(Modality Gap)을 효과적으로 줄이며, 파인튜닝 없이도 강력한 멀티모달 임베딩 성능을 보여줍니다. 또한, E5-V는 텍스트 쌍에만 학습을 시킬 수 있는 단일 모달리티 학습 접근 방식을 제안하여 더 나은 성능을 보여줍니다. 기존의 CLIP 모델은 텍스트와 이미지 간의 대조적 학습을 통해 우수한 성능을 보여주지만, 복합적인 텍스트와 시각적 입력을 효과적으로 표현하는 데 어려움을 겪습니다. CLIP 모델은 복잡한 텍스트를 이해하는 능력이 부족하며, 긴 텍스트를 처리하는 데 한계가 있습니다. E5-V는 이러한 한계를 극복하기 위해, MLLM(Multimodal LLM)을 사용하여 멀티모달 입력을 효과적으로 표현하는 방법을 제안합니다. MLLM은 초기 학습 단계에서 시각적 및 언어적 입력을 통합하여 의미를 기반으로 멀티모달 정보를 표현할 수 있습니다. E5-V 프레임워크는 SimCSE와 Alpaca-Lora를 기반으로 하여 개발되었습니다. 다양한 데이터셋에서의 평가와 학습 방법을 제공하여 사용자들이 직접 E5-V를 활용할 수 있도록 지원합니다. 또한, 텍스트와 이미지를 동시에 처리할 수 있는 예제 코드와 함께, 성능 평가 및 학습 방법에 대한 자세한 설명을 포함하고 있습니다. E5-V는 기존의 멀티모달 모델들과 비교하여 다음과 같은 특징을 갖습니다: 모달리티 간 격차 해소: E5-V는 텍스트와 이미지 간의 모달리티 차이를 효과적으로 극복합니다. 단일 모달리티 학습: 텍스트 쌍만을 사용하여 멀티모달 학습보다 더 나은 성능을 보입니다. 범용 임베딩: 다양한 입력 형식을 통합하여 범용적인 임베딩을 제공합니다. E5-V 주요 기여 및 특징 멀티모달 임베딩 통합(Unifying Multimodal …

---

## [Shapeshift, JSON 객체 매핑을 위한 TypeScript 라이브러리](https://discuss.pytorch.kr/t/shapeshift-json-typescript/4856)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [7월 16, 2024, 10:02오후 UTC](https://discuss.pytorch.kr/t/shapeshift-json-typescript/4856 "2024-07-16T22:02:00Z")

</div>

Shapeshift 소개 Shapeshift는 벡터 임베딩을 사용하여 임의로 구조화된 JSON 객체를 매핑하는 TypeScript 라이브러리입니다. 키 간의 의미적 유사성을 기반으로 객체를 변환하며, 중첩된 구조도 지원합니다. Cohere, OpenAI, Voyage와 같은 여러 임베딩 제공자를 지원하여 사용자의 필요에 맞게 임베딩 모델과 유사성 임계값을 설정할 수 있습니다. Shapeshift를 사용하면 서로 다른 구조의 객체를 쉽게 매핑할 수 있어 데이터 변환 작업이 크게 단순해집니다. 예를 들어, 복잡한 API 응답을 다른 형식의 데이터 구조로 변환해야 할 때 유용합니다. Shapeshift는 의미적 유사성을 사용하여 객체를 매핑한다는 점에서 단순한 키 매핑 라이브러리와 다릅니다. 다른 라이브러리는 정적 매핑 규칙을 사용하지만, Shapeshift는 임베딩을 통해 키의 의미를 이해하고 유사한 키끼리 매핑합니다. 이는 특히 데이터 구조가 빈번하게 변경되거나 복잡한 경우에 큰 장점을 제공합니다. 주요 기능 키의 의미적 유사성을 기반으로 서로 다른 구조의 객체를 매핑 중첩된 객체 지원 Cohere, OpenAI, Voyage와 같은 여러 임베딩 제공자 지원 사용자 정의 임베딩 모델 및 유사성 임계값 설정 가능 TypeScript 지원으로 타입 안정성 제공 라이선스 Shapeshift 프로젝트는 MIT License로 공개 및 배포되고 있습니다. License This project is licensed under the MIT License. :github: Shapeshift GitHub 저장소 https://github.com/rectanglehq/Shapeshift/ 이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다. …

---

## [txtai: 임베딩 생성 및 검색 등을 위한 All-in-one VectorDB](https://discuss.pytorch.kr/t/txtai-all-in-one-vectordb/4781)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [7월 10, 2024, 12:14오전 UTC](https://discuss.pytorch.kr/t/txtai-all-in-one-vectordb/4781 "2024-07-10T00:14:02Z")

</div>

txtai 소개 txtai는 벡터 검색, 주제 모델링, 검색 증강 생성(RAG) 등을 포함한 다양한 기능을 제공하는 임베딩을 위한 벡터 데이터베이스(Vector Database for embedding)입니다. 벡터 인덱스, 그래프 네트워크 및 관계형 데이터베이스의 결합으로 구성되어 있으며, SQL을 사용한 벡터 검색, 객체 저장소, 멀티모달 인덱싱 등을 지원합니다. Python, YAML을 통해 구축할 수 있으며, API 바인딩이 다양한 언어(JavaScript, Java, Rust, Go)로 제공됩니다. 또한, txtai는 Hugging Face Transformers, Sentence Transformers 및 FastAPI와 통합되어 있으며, 로컬 실행 또는 컨테이너 오케스트레이션을 통한 확장이 가능합니다. 유사한 기술로는 Milvus, Pinecone, FAISS 등이 있지만, txtai는 SQL과의 통합, 다양한 파이프라인 지원으로 차별화됩니다. txtai의 주요 특징 벡터 검색: SQL, 객체 저장, 주제 모델링, 그래프 분석 및 멀티모달 인덱싱 지원. 임베딩 생성: 텍스트, 문서, 오디오, 이미지 및 비디오에 대한 임베딩 생성. 파이프라인: LLM 프롬프트 실행, 질문 응답, 라벨링, 전사, 번역, 요약 등을 수행하는 언어 모델 기반 파이프라인. 워크플로우: 파이프라인을 결합하고 비즈니스 로직을 집계하는 워크플로우. txtai 프로세스는 간단한 마이크로서비스 또는 멀티 모델 워크플로우일 수 있음. 개발 환경: Python 또는 YAML로 구축 가능. JavaScript, Java, Rust, Go용 API 바인딩 제공. 운영 환경: 로컬에서 실행하거나 컨테이너 오케스트레이션으로 확장 가능. txtai 구조 txtai는 벡터 인덱스(희소 및 밀집), 그래프 네트워크 및 관계형 데이터베이스의 결합으로, SQL을 사용한 벡터 검색, 주제 모델링, RAG(검색 강화 생성) 등을 가능하게 합니다. 임베딩 데이터…

[다음 페이지](https://discuss.pytorch.kr/tag/embedding/458.md?match_all_tags=true&page=1&tags%5B%5D=embedding)
