요약
구글이 텍스트·이미지·오디오·영상을 기기 안에서 한 벡터 공간으로 옮기는 오픈 임베딩 모델을 공개했습니다.
임베딩(뜻이 비슷한 데이터를 서로 가까운 숫자 벡터로 바꾸는 것) 모델인 EmbeddingGemma 2를 구글 딥마인드 연구진이 소개했습니다. 2천만 회 넘게 내려받은 첫 모델의 후속작으로, 데이터를 기기 밖으로 내보내지 않는 쓰임새를 겨냥했습니다.
왜 중요한가
- 사진, 녹음, 영상을 글로 찾는 멀티모달 검색을 서버 없이 휴대폰이나 노트북에서 할 수 있게 됩니다.
- 필요 없는 인코더를 빼고 쓸 수 있어서 기기 사양에 맞춰 메모리 부담을 고를 수 있습니다.
- 아파치 2.0 라이선스로 공개되어 상업 서비스에도 쓸 수 있습니다.
핵심 내용
- Gemma 4 구조를 바탕으로 텍스트 2억 7천만, 비전 1억 7천만, 오디오 3억 파라미터를 모듈처럼 붙여 총 7억 4천만 파라미터입니다.
- 10억 파라미터 미만 멀티모달 임베딩 모델 가운데 MTEB와 MAEB 벤치마크에서 가장 높은 점수를 냈다고 밝혔습니다.
- 맥락 길이는 8K 토큰으로 4배 늘어 오디오 5.5분이나 영상 프레임 58장을 한 번에 넣을 수 있습니다.
- MRL(벡터 앞부분만 잘라 써도 되게 하는 학습법)로 768차원을 128차원까지 줄여 저장 공간을 최대 6배 아낍니다.
- 양자화하면 Pixel 11 Pro에서 텍스트 전용은 약 191MB, 전체 모델은 567MB 메모리로 돌아갑니다.
HN 반응
- 업체가 모델 제공을 끝내도 오픈 가중치로 계속 돌릴 수 있어 쌓아 둔 벡터를 다시 계산할 필요가 없다며 공개 방식을 반기는 의견이 많았습니다.
- 한편 텍스트 성능은 첫 모델과 같다는 지적과, 로컬에서 돌려 보니 공식 예제 분류마저 틀렸다는 경험담도 나왔습니다.
EmbeddingGemma 2가 Apache 2.0 라이선스로 나온 점이 정말 반갑습니다.
특히 임베딩 모델은 폐쇄적이고 독점적이며 호스팅으로만 제공되는 모델을 쓰는 게 맞지 않다고 생각합니다.
임베딩 모델을 쓰는 대부분의 애플리케이션은 수천, 많게는 수백만 개의 임베딩 벡터를 계산해 두었다가 나중에 비교하는 방식으로 동작합니다.
모델이 독점이라면 업체가 언젠가 그 모델의 제공을 중단하기로 결정할 가능성이 높습니다. 대체할 더 좋은 모델은 내놓겠지만, 이미 저장해 둔 수백만 개의 벡터를 다시 계산하는 비용은 사용자가 내야 합니다.
(2024년 4월에 오픈AI가 "새 모델로 콘텐츠를 다시 임베딩하는 사용자의 금전적 비용을 부담하겠다"고 한 적이 있지만 - https://openai.com/index/gpt-4-api-general-availability/ - 모든 업체에서 이런 걸 기대할 수 있는 건 아니라고 봅니다.)
분명히 해 두자면, 저는 모델을 직접 호스팅하고 싶지는 않습니다. 호스팅 모델에는 업체에 돈을 내고 싶습니다. 다만 그 업체가 호스팅을 중단하더라도 오픈 웨이트 버전을 직접 돌리거나, 대신 돌려 줄 다른 업체를 찾을 수 있다는 보장이 있어야 합니다.
골든 테스트(golden test)를 두는 편이 낫습니다. CPU에서 GPU로 바꾸기만 해도 토큰이 달라질 수 있습니다.
임베딩 모델에서는 별로 상관없는 얘기입니다. 무손실 PNG를 품질 99%짜리 JPEG로 압축해도 임베딩이 달라진다는 걸 생각해 보세요. 중요한 건 비트 단위로 똑같은지가 아니라 임베딩 공간에서의 거리입니다. 같은 텍스트를 CPU와 GPU에서 임베딩해도 결과는 아주 아주 비슷합니다.
텍스트와 이미지로 "Jev" 같은 작업에도 쓸 수 있다는 점도 꽤 근사합니다.
https://developers.google.com/edge/mediapipe/solutions/decision/decision_maker
로컬에서 돌려 봤는데, 웃기게도 그쪽 예시로 나온 "항공편 취소하고 신용카드로 바로 환불해 주세요."를 분류하는 데 실패하더라고요. 이 요청은 결제나 청구, 환불과 관련이 없다고 나왔어요. p(true)가 0.22였고요(true는 금융 관련이라는 뜻입니다). 이 경우엔 Laya가 훨씬 정확했고 속도도 거의 비슷했어요.
멋지네요, 감사합니다!
드디어 나왔네요. LLM과 에이전트가 동작하는 방식에 변곡점이 왔는데도 적당한 크기의 괜찮은 임베딩 모델이 없어서 슬슬 짜증이 나던 참이었거든요. 게다가 이건 멀티모달이기까지 하네요! 텍스트 전용 270M은 예전 임베딩 모델들에 비해 훌륭하고, 텍스트와 비전을 합쳐 440M인 것도 괜찮은 수준이에요.
저는 훨씬 빠르게 로컬 임베딩을 만들어 주는 도구도 갖고 있을지 모르는데요, EmbeddingGemma에 맞춰 보정해 놨지만 더 나은 임베딩 모델이 나올 때까지 공개하지 않고 있었어요.
Opus 5.5가 이미지와 오디오 입력 지원(그리고 ffmpeg를 통한 비디오 지원도, 안 될 거 없잖아요)을 추가한 뒤에 제 가상의 도구로 M3 Pro에서 다시 잰 수치입니다.
텍스트: 짧은 텍스트 기준 초당 임베딩 78개
이미지: 초당 임베딩 4개
오디오: 30초 단위 청크(인코더가 이렇게 동작합니다) 기준 초당 임베딩 6개
비디오: 영상 1분당 초당 임베딩 0.2개(인코더가 1fps로 처리하니 놀랍진 않습니다).
이 정도로 큰 모델을 노트북에서 로컬로 돌리는 것치고는 나쁘지 않은 수치입니다. M3 Pro가 나온 지 몇 년 됐으니 M5 Ultra라면 최소 5배는 나오지 않을까 싶습니다.
비디오에 쓰이는 비전뿐 아니라 오디오까지 된다니, 정말 놀랍습니다.
예를 들어 어떤 단어들과 그 단어가 발화되는 오디오, 또는 글자가 들어 있는 이미지처럼 짝을 이룬 임베딩 사이의 근접성을 이 모델이 어떻게 다루는지는 잘 모르겠습니다. 이걸로 로컬 멀티모달 검색을 만들면 정말 멋질 겁니다. 저는 CLIP으로 이런 걸 탐구해 봤는데, 이미지(오디오도 마찬가지입니다) 임베딩에는 깔끔한 "텍스트" 내용 정보와 함께 스타일, 시각·청각적 분위기 정보가 같이 담겨 있고, 이 둘을 선형으로 어느 정도 분리할 수도 있다는 점이 흥미로웠습니다.
(변호사입니다) 궁금한 점이 있습니다. 말씀하신 용도라면, 새로 생기거나 바뀐 파일을 반영하려고 기기가 임베딩을 계속 돌리며 갱신해야 하지 않습니까? 그렇다면 그 연산 부하는, 예를 들어 Spotlight가 인덱스를 계속 갱신하는 것과 비교하면 어느 정도입니까?
임베딩 모델은 메모리에 계속 올라가 있고, 검색 키워드를 임베딩으로 바꾸는 데 쓰입니다.
생각하시는 인덱스는 파일마다 한 번만 만들어 둡니다. 그다음에는 임베딩끼리 비교해서 검색하고요. 파일을 추가하거나 수정하면, 메모리에 올라가 있는 모델로 해당 임베딩을 비동기로 새로 만들거나 갱신해서 임베딩을 저장해 둔 곳(예를 들어 SQLite)에 넣으면 됩니다.
그리고 파일을 하나 이상의 항목으로 바꾸는 방법은 별개의 문제라서, 상황에 맞춰 조정해야 할 겁니다. 보통 큰 문서는 문단 단위, 때로는 그보다 더 잘게 나눕니다(청킹). 어디서 나누는 게 최적인지만 따져도 쉽지 않습니다. 이렇게 나누면 문서의 특정 부분만 검색할 수 있다는 장점이 있지만, 넓은 맥락은 반영하지 못합니다. 그래도 임베딩은 어차피 토큰이 너무 많으면 잘 못 다루는 경우가 많습니다.
안드로이드 폰에 탑재할 모델과 아마 거의 비슷할 모델을 OSS(최소한 오픈 웨이트와 라이선스)로 공개한 구글에 박수를 보냅니다.
참고로 기존 온디바이스 임베딩 모델과 달리 이 모델은 MatFormer가 아니라 MRL로 학습된 것 같습니다. 그래서 아쉽게도 저차원 임베딩을 쓸 때 모델 가중치까지 함께 줄일 수는 없습니다. 멀티모달에 MatFormer를 적용하는 방법은 아직 제대로 된 연구가 없어서 그런 걸까요?
텍스트 기준으로 https://www.voyageai.com/ 의 임베딩 모델들과 비교한 결과도 보고 싶습니다. 예전에 몇 번 써 봤는데, 여기서 비교된 Qwen 모델들보다 제 경험상 더 우수했습니다.
이 분야를 떠난 지 좀 됐지만, Voyage는 아주 좁은 틈새 업무 영역 밖에서는 제대로 된 경쟁자였던 적이 없습니다. 이 모델은 90%대의 사용 사례에서 더 낫다고 봅니다.
흥미롭네요. 한번 확인해 봐야겠습니다.
이 정도 크기의 멀티모달 모델을 기기에서 직접 돌리는 용도로는 어떤 게 있다고들 보시나요? 어떤 작업에서 정확하고, 환각 비율은 어느 정도인가요?
가장 대표적인 건 이미지를 텍스트로, 또는 그 반대로 연결하는 일입니다. 예를 들어 텍스트로 이미지를 의미 검색하는 거죠. 이미지를 인코딩하고 텍스트 질문도 같은 모델로 인코딩한 다음, 가장 가까운 이웃을 찾습니다.
아직 써 보지는 않았지만, 법률 업무에서라면 사건 파일에서 "허리케인 카트리나 이전의 멀쩡한 지붕"과 "허리케인 카트리나 이후의 파손된 지붕"을 검색해서 증거 자료 안의 증언 녹취와 관련 사진을 둘 다 찾는 데 쓸 수 있겠다고 상상해 봅니다.
파라미터 수 배분이 흥미롭습니다.
총 740M(텍스트 270M, 비전 170M, 오디오 300M)
납득이 가네요...
비전은 정지 이미지를 처리할 뿐이니까요(그래서 단연 가장 작습니다). 텍스트는 인간 언어의 엔트로피를 다뤄야 하고요. 오디오는 시간이 없으면 의미가 없죠.
텍스트 기준으로는 벤치마크가 첫 EmbeddingGemma와 똑같습니다.
하지만 이 새 모델에서는 필요 없는 부분을 켜고 끌 수 있습니다.
예를 들어 텍스트만 남겨 둘 수도 있고요.
왜 siglip2(이것도 구글 모델이죠)와는 비교하지 않았을까요? siglip2는 완전한 멀티모달이 아니라서일까요, 아니면 조직이나 팀이 달라서일까요?
일단 EG2에는 인코더가 없어서 OCR에는 쓸 수 없으니까요.
테스트를 좀 해 보고 제 하네스에 넣는 걸 고려하고 있습니다. 정말 좋은 임베딩 모델 같습니다!
RAG 변환(rag transformations)이 전설이 되겠네요.