하나의 인코더로 이미지와 텍스트를 함께 읽는 법

별도 비전 타워 없이 단일 트랜스포머로 이미지와 다국어 텍스트를 처리하고 문서 검색에서 작은 크기로 강한 성능을 낸 NeoMME 연구 해설

원문 논문 보기
'하나의 인코더로 이미지와 텍스트를 함께 읽는 법' 기사 커버 이미지

이번 글에서 다루는 연구는 Hcompany의 Aurélien Lac와 Tony Wu가 허깅페이스 블로그에 2026년 9월 3일 공개한 NeoMME: an efficient Multimodal-native and Multilingual Encoder이며 기술 리포트는 arXiv 식별자 2609.01657로도 공개된 연구입니다. 원문 링크는 제목 아래에 붙어 있습니다.

이 연구의 주장은 별도의 사전학습 비전 타워나 생성형 언어 디코더 없이 단일 양방향 트랜스포머 하나로 이미지 패치와 다국어 텍스트 토큰을 함께 처리하는 260M과 800M 규모의 인코더를 처음부터 학습해도 문서 이미지 검색에서 대형 모델에 맞먹는 효율과 성능을 낼 수 있다는 것이며, 이 글에서는 왜 그런 설계가 필요했는지와 어떻게 학습했는지와 검색용으로 어떻게 다듬어졌는지를 차례로 풀어봅니다.

왜 또 다른 멀티모달 인코더가 필요했나

최근 문서 검색과 분류와 토큰 단위 판단 같은 일은 생성형 거대 모델을 빌려 오는 방식으로 많이 해결되어 왔습니다. 따로 학습된 비전 인코더가 이미지 특징을 뽑고 프로젝터가 그 특징을 언어 모델의 입력 공간으로 옮기고 인과적 디코더가 이미지와 텍스트를 함께 읽는 구조입니다. 글을 새로 써내는 일이라면 이 구조가 자연스럽습니다. 다음 토큰을 순서대로 예측하는 기계가 필요하기 때문입니다. 그러나 검색은 글을 써내는 일이 아닙니다. 입력된 질문과 문서가 서로 얼마나 가까운지를 벡터 공간에서 재는 일입니다. 분류도 마찬가지입니다. 정해진 선택지 가운데 어디에 속하는지를 가리는 일입니다. 이런 일에 인과적 디코더까지 통째로 얹는 것은 목적에 비해 덩치가 큽니다. 파라미터도 많이 들고 계산도 무겁고 서빙 부담도 커집니다.

양방향 인코더 진영에서는 이미 효율화의 흐름이 있었습니다. 모던버트 계열의 연구가 인코더 구조와 학습 방식을 다듬어 같은 크기에서 더 빠르고 더 정확하게 만드는 길을 보여주었습니다. 문서 검색 쪽에서는 모던브이비이알이 비슷한 시도를 했습니다. 텍스트 쪽은 양방향 모던버트 스타일로 가져가면서 비전 쪽은 기존의 시그립 계열 타워를 그대로 얹는 방식이었습니다. 절충안이었습니다. 텍스트 인코더는 가볍게 다듬었지만 이미지는 여전히 별도로 학습된 큰 눈을 빌려 쓴 셈입니다. 그래서 무게의 절반은 그대로 남았습니다. 비전 타워의 파라미터와 계산 부담을 통째로 짊어지는 구조에서는 경량화의 끝을 보기 어렵습니다.

이 연구가 던지는 질문은 그 지점에서 시작합니다. 처음부터 끝까지 인코더 하나로 이미지와 텍스트를 함께 처리하면 어떻게 될까. 남의 눈을 빌리지 않고 처음부터 함께 키운 눈과 언어 감각이면 검색 같은 벡터 판단 일을 더 가볍게 해낼 수 있지 않을까. 연구진은 이 물음에 답하기 위해 기존의 비전 타워도 기존의 텍스트 인코더도 기존의 텍스트 디코더도 가져오지 않기로 합니다. 하나의 트랜스포머 인코더가 텍스트 토큰과 이미지 패치를 같은 계산 경로로 처리합니다. 학습은 처음부터 새로 합니다. 멀티모달 네이티브라는 말이 가리키는 바가 바로 이것입니다. 나중에 끼워 맞춘 결합이 아니라 태생부터 함께 처리하는 설계입니다. 효율이라는 말도 여기서 무게를 얻습니다. 생성에 필요한 장치를 덜어내고 벡터 표현에 필요한 장치만 남기겠다는 뜻입니다.

하나의 트랜스포머로 이미지와 텍스트를 함께 처리한다는 것

네오엠엠이의 뼈대는 단순합니다. 크기는 260M과 800M 두 가지이며 두 변형은 같은 구조를 공유합니다. 텍스트 입력은 인수분해된 토큰 임베딩으로 들어가고 이미지 입력은 겹치지 않게 나눈 32픽셀 격자 패치로 들어가 작은 다층 퍼셉트론을 거쳐 같은 트랜스포머 인코더로 들어갑니다. 따로 노는 길이 없습니다. 같은 층을 지나고 같은 어텐션을 거치고 같은 피드포워드 계산을 거칩니다. 듀얼 타워 구조에서는 이미지와 텍스트가 각자의 길로 가다가 늦게 만납니다. 생성형 결합 구조에서는 비전 특징이 언어 공간으로 번역되어 디코더로 들어갑니다. 여기서는 처음부터 같은 방에서 함께 계산합니다. 그래서 사전학습과 미세조정과 병렬화와 서빙을 두 양식에 걸쳐 같은 방식으로 다룰 수 있습니다. 인프라 관점에서 보면 이 단순함이 큽니다. 모달리티마다 다른 최적화와 다른 배포 경로를 들고 있을 필요가 줄어들기 때문입니다.

세부 설계도 인코더의 최신 문법을 충실히 따릅니다. 그룹 쿼리 어텐션과 쿼리 키 정규화와 게이트 어텐션과 이차원 회전 위치 임베딩과 제곱 렐루 기반 다층 퍼셉트론 같은 개선이 들어가 있습니다. 어느 하나가 극적인 비약이라기보다 검증된 개선을 차곡차곡 쌓은 모습입니다. 인코더 연구의 흐름을 따라온 독자라면 익숙한 이름들입니다. 중요한 점은 이런 개선이 이미지와 텍스트를 가리지 않고 같은 스택에 적용된다는 사실입니다. 이미지 전용 장치와 텍스트 전용 장치를 따로 두지 않으니 개선의 효과가 양쪽에 함께 스밉니다. 한쪽을 고치면 다른 쪽도 함께 좋아지는 구조입니다.

다국어 지원도 뼈대에 새겨져 있습니다. 연구진은 다국어 텍스트와 코드와 수학과 기계가 만든 이미지 전사 자료에서 처음부터 학습한 13만 토큰 규모의 바이트 페어 인코딩 토크나이저를 사용합니다. 영어 중심 모델을 나중에 여러 언어로 늘리는 방식이 아닙니다. 처음부터 여러 언어의 분포를 함께 보는 토크나이저입니다. 검색은 언어 장벽 앞에서 자주 무너집니다. 질문은 한국어로 들어오고 문서는 영어로 있고 표 안의 숫자는 또 다른 표기로 적혀 있는 일이 흔합니다. 인코더가 처음부터 여러 언어를 함께 배웠다는 것은 그런 현장의 뒤섞임을 정면으로 다룬다는 뜻입니다. 이 글의 뒤쪽에서 검색 성능을 볼 때 이 대목을 다시 떠올리게 됩니다. 작은 크기가 여러 언어에서 통했다는 보고는 토크나이저와 학습 분포의 선택과 떼어 생각하기 어렵기 때문입니다.

동적 해상도와 긴 문맥이 만드는 문서 읽기 능력

문서 이미지는 크기가 제각각입니다. 어떤 페이지는 글자가 빽빽한 고밀도 보고서이고 어떤 이미지는 여백이 많은 사진 한 장입니다. 모두 같은 크기로 뭉개어 넣으면 밀도 높은 페이지는 글자가 뭉개지고 여백 많은 이미지는 쓸데없는 계산만 늘어납니다. 이 연구는 이미지의 종횡비와 크기를 유지하는 동적 해상도를 택합니다. 정보 밀도가 높은 고해상도 문서 페이지에는 더 많은 토큰을 쓰고 내용이 적은 작은 이미지에는 적은 토큰을 씁니다. 문서 검색의 현장 감각에 맞는 선택입니다. 검색 대상이 되는 기업 보고서와 논문과 청구서와 도면은 해상도를 뭉개는 순간 표와 그래프의 미세한 구분이 사라집니다. 글자 크기와 자간과 표의 선과 차트의 범례 같은 시각 단서가 함께 날아갑니다. 동적 해상도는 그런 단서를 살리는 쪽을 택합니다.

문맥 길이도 넉넉합니다. 두 모델 모두 16384 토큰의 문맥을 가지며 이는 표준적인 4케이 고해상도 이미지 두 장 정도를 한 번에 담을 수 있는 규모입니다. 페이지를 통째로 보지 못하고 잘라 보는 모델은 표가 페이지 경계에 걸쳐 있을 때 맥락을 잃습니다. 앞장에서 본 숫자의 단위가 다음 장에 있을 때 잘린 조각만으로는 답을 찾기 어렵습니다. 긴 문맥은 그런 끊김을 줄입니다. 계산 부담을 다스리기 위해 대부분의 층에서는 대칭 슬라이딩 윈도 어텐션을 쓰고 여섯 층마다 한 번씩과 마지막 층에서는 전체 어텐션을 쓰는 절충 구조를 택합니다. 가까운 이웃은 촘촘히 보고 먼 관계는 정해진 지점에서 한 번씩 훑는 방식입니다. 고해상도 문서를 읽을 때는 가까운 글자 사이의 관계가 중요하면서도 페이지 전체의 제목과 표와 본문 사이의 먼 관계도 함께 봐야 합니다. 이 교대 구조는 그 두 가지 필요를 함께 다룬 설계로 읽힙니다.

현장에서 일하는 엔지니어의 눈으로 보면 이 두 선택은 서로 맞물립니다. 동적 해상도는 입력 토큰 수를 상황에 맞게 늘렸다 줄였다 하고 긴 문맥과 윈도 어텐션은 늘어난 토큰을 감당할 그릇을 마련합니다. 한쪽만 있으면 반쪽입니다. 해상도만 높이고 그릇이 작으면 잘라내야 하고 그릇만 크고 해상도가 고정되면 빈 공간에 계산을 낭비합니다. 이 연구는 두 바퀴를 함께 굴리는 쪽을 택했습니다. 문서 검색이라는 구체적인 일을 염두에 둔 조율입니다. 뒤에서 볼 인덱싱 속도와 저장소 압축 이야기도 이 토대 위에서 이해해야 합니다. 입력 토큰을 유연하게 다루는 능력이 있어야 고해상도 검색의 비용 문제를 정면으로 다룰 수 있기 때문입니다.

가려진 텍스트를 맞히며 이미지에서 배우는 학습법

학습 방식은 이 연구에서 가장 눈여겨볼 대목입니다. 연구진은 모델 전체를 처음부터 이산 마스크 확산 방식의 텍스트 잡음 제거기로 학습합니다. 텍스트만 있는 예제에서는 오염률을 0과 1 사이에서 균일하게 뽑고 각 텍스트 토큰을 그 확률로 독립적으로 가립니다. 멀티모달 예제에서는 오염률을 0점3과 1 사이에서 뽑습니다. 이때 이미지 패치는 그대로 보여주면서 가려진 텍스트를 복원하게 합니다. 오염이 가벼우면 주변 텍스트만으로도 빈칸을 맞힐 수 있습니다. 고양이라는 단어는 이미지가 없어도 앞뒤 문장에서 충분히 추측됩니다. 그러나 오염이 짙어지면 언어 단서만으로는 답이 나오지 않습니다. 주변에 남은 단어가 거의 없으니 이미지를 보지 않고는 빈칸을 메울 수 없습니다. 높은 마스킹이 이미지 근거에 기대는 설명을 강제하는 장치가 되는 셈입니다.

이 설계의 미덕은 언어 지름길을 차단하는 데 있습니다. 멀티모달 학습에서 흔한 실패는 모델이 이미지를 보지 않고도 텍스트 상관관계만으로 답을 맞히는 것입니다. 학습 데이터에 박힌 상투적인 문장 패턴을 외우면 이미지를 볼 이유가 사라집니다. 그러면 눈은 있어도 쓰지 않는 모델이 됩니다. 오염률을 높이는 조작은 그 지름길을 막습니다. 텍스트가 거의 지워진 상태에서는 외운 패턴이 소용없습니다. 보이는 이미지 증거에서 단서를 끌어와야 합니다. 고양이가 매트 위에 앉았다는 문장의 빈칸을 메우려면 실제로 그 장면이 이미지에 있는지를 봐야 합니다. 이런 압력이 반복되면 모델은 이미지와 텍스트를 잇는 진짜 대응을 배웁니다. 표의 숫자와 본문의 설명과 차트의 추세가 어떻게 서로를 가리키는지를 익힙니다.

학습 분포와 규모도 분명히 밝히고 있습니다. 다국어 텍스트와 코드와 수학과 자연 이미지와 문서 이미지를 섞어 학습하며 각 모델은 패킹된 입력 토큰 기준으로 약 5240억 토큰을 처리합니다. 그 가운데 텍스트만 있는 예제가 약 2900억 토큰입니다. 모던버트의 2조 토큰 학습 예산과 비교하면 텍스트 예산이 상대적으로 작습니다. 그래서 데이터 효율을 높이기 위해 노르뮤온 옵티마이저를 택했다고 설명합니다. 작은 예산으로 처음부터 키우려면 한 걸음마다 배우는 양을 늘려야 합니다. 옵티마이저 선택이 그 고민의 답입니다. 친구 두 명이 제한된 시간과 계산 자원으로 시작한 곁가지 탐구였다는 후일담과 겹쳐 읽으면 이 대목이 더 선명해집니다. 큰 예산을 전제로 한 설계가 아니라 적은 예산에서도 통하는 설계 쪽에 무게를 둔 연구입니다.

검색용으로 다듬기, 조밀한 벡터와 늦은 상호작용을 한 번에

뼈대가 되었다면 이제 그 뼈대가 실제로 일을 하는지를 보여줘야 합니다. 연구진은 콜팔리가 도입한 페이지 이미지 방식을 그대로 가져와 시각 문서 검색용으로 미세조정합니다. 전통적인 텍스트 검색은 문서에서 텍스트 조각을 뽑아내어 색인합니다. 이 과정에서는 광학 문자 인식 같은 전처리가 필요합니다. 그런데 인식이 완벽해도 레이아웃과 차트와 표와 글꼴 크기와 굵기 같은 시각 단서는 납작해집니다. 페이지 자체를 이미지로 보고 순위를 매기면 그런 단서가 살아남습니다. 표의 선이 어디에서 끊기는지와 차트의 막대가 얼마나 높은지와 제목이 본문보다 얼마나 큰 글자로 적혀 있는지가 검색 신호로 남습니다. 텍스트 추출이 평평하게 만드는 정보를 이미지째로 쓰는 선택입니다.

검색 헤드는 두 개를 함께 학습합니다. 조밀 헤드는 뼈대의 은닉 상태 벡터들을 평균내어 정규화된 하나의 벡터로 만듭니다. 오늘날 가장 흔한 형태이며 근사 최근접 이웃 탐색과 잘 어울려 빠른 검색에 유리합니다. 작고 다루기 쉽습니다. 늦은 상호작용 헤드는 각 텍스트 토큰과 각 이미지 패치의 출력 은닉 상태를 128차원의 정규화 벡터로 각각 투영합니다. 쿼리 토큰 하나하나와 이미지 영역 하나하나 사이의 국소적 대응을 살립니다. 조밀한 벡터가 문서 전체의 분위기를 한 주머니에 담는다면 늦은 상호작용은 토큰과 영역 사이의 잘게 쪼갠 대응을 보존합니다. 어느 쪽이 더 좋다고 미리 정하지 않고 두 표현을 한 번의 순전파로 함께 내보냅니다. 쓰는 쪽에서 고르면 됩니다.

활용 지침도 실용적입니다. 일반적으로는 늦은 상호작용 임베딩을 권합니다. 더 강력하고 개방형 라이브러리로 쉽게 쓸 수 있기 때문입니다. 그러나 말뭉치가 아주 크다면 한 번의 순전파로 조밀 임베딩을 뽑아 근사 탐색으로 소수의 후보를 먼저 추린 뒤 그 후보에만 늦은 상호작용으로 재정렬하는 이단계를 쓸 수 있습니다. 빠른 그물과 정밀한 손질을 함께 쓰는 셈입니다. 인프라와 예산에 따라 무게중심을 옮길 수 있는 유연함이 이 설계의 매력입니다. 작은 팀은 조밀 검색으로 시작해 비용이 감당되는 선에서 재정렬을 얹을 수 있고 큰 조직은 처음부터 늦은 상호작용을 전면에 둘 수 있습니다. 하나의 뼈대에서 두 가지 손잡이가 나오는 구조이니 배포 경로도 단순해집니다.

작은 크기로 맞먹는 성능, 벤치마크를 뜯어보기

성능 보고의 중심은 비도어 3종에서의 결과입니다. 이 지표는 상위 10개 결과의 순위를 재는 방식이며 숫자가 높을수록 원하는 문서가 위쪽에 뜬다는 뜻입니다. 260M 검색 모델은 0점523을 기록해 800M 미만 구간에서 평가된 모델 가운데 가장 높은 점수를 받았습니다. 파라미터가 약 14배 큰 콜크웬 계열과는 0점002 차이입니다. 800M 검색 모델은 0점556으로 같은 규모대의 경쟁 모델과 0점009 차이입니다. 두 모델 모두 모델 크기와 정확도의 경계선 위에 놓였습니다. 크기를 키우지 않고도 경계선을 미는 자리에 섰다는 뜻입니다. 효율을 내세우는 연구라면 반드시 보여줘야 하는 그림에서 할 말을 한 셈입니다.

이전 세대 지표에서도 흐름은 이어집니다. 비도어 1과 2는 상위 5개 기준이며 이 무대에서는 260M 모델이 콜모던브이비이알과 두 배 큰 500M급 모델을 앞섰고 800M 모델은 3점6배 큰 콜팔리 1점3을 앞섰다고 보고합니다. 크기가 곧 성능이던 시절의 상식을 뒤집는 대목입니다. 물론 벤치마크는 벤치마크일 뿐입니다. 현장의 말뭉치는 벤치마크보다 지저분하고 언어 분포도 다르고 문서 품질도 들쭉날쭉합니다. 그러나 같은 자에서 같은 잣대로 쟀을 때 작은 모델이 큰 모델의 턱밑까지 쫓아갔다는 사실은 가볍지 않습니다. 특히 비전 타워를 빌리지 않고 처음부터 키운 뼈대가 그런 결과를 냈다는 점이 중요합니다. 남의 눈을 빌리지 않아도 눈을 뜰 수 있음을 숫자로 보인 셈이기 때문입니다.

이 결과를 해석할 때 놓치지 말아야 할 것은 다국어와 고해상도라는 맥락입니다. 비도어 3종은 여러 언어와 다양한 문서 양식을 함께 봅니다. 작은 모델이 이 무대에서 선전했다는 것은 토크나이저와 학습 분포와 동적 해상도 같은 앞선 선택들이 함께 먹혔다는 뜻입니다. 어느 하나만의 공이 아닙니다. 토크나이저가 여러 언어를 품지 못했다면 다국어 질문에서 무너졌을 것이고 해상도를 뭉갰다면 표와 차트가 많은 페이지에서 밀렸을 것입니다. 연구진이 듀얼 헤드로 조밀한 표현과 세밀한 표현을 함께 뽑은 것도 점수에 스며 있습니다. 거친 추림과 정밀한 대조를 함께 쓰면 순위 지표가 좋아지는 것은 자연스러운 일입니다. 숫자는 설계의 합산입니다. 이 연구의 숫자는 처음부터 끝까지 벡터 판단에 맞춘 설계의 합산으로 읽힙니다.

고해상도 검색의 무거운 짐, 저장소를 255분의 1로 줄이기

늦은 상호작용의 오랜 약점은 저장소입니다. 출력 벡터 수에 비례해 저장소가 늘어나니 해상도가 높아질수록 짐이 무거워집니다. 2048픽셀 정사각형 페이지 하나가 4200개의 벡터를 낳고 단정밀도 기준으로 약 2점1메가바이트를 차지합니다. 비도어 3종 평균으로 따져도 문서 한 장당 약 1점5메가바이트입니다. 백만 장이면 테라바이트 단위입니다. 아무리 정확해도 저장소가 이렇게 불어나면 현업에서 쓰기 어렵습니다. 검색 품질과 저장소 비용 사이의 줄다리기가 바로 고해상도 검색의 현실입니다.

연구진은 서로 보완적인 두 가지 압축을 함께 씁니다. 첫째는 계층적 토큰 풀링입니다. 하나의 다중 벡터 임베딩 안에서 서로 비슷한 문서 벡터들을 묶어 평균으로 대체해 페이지당 벡터 수를 줄입니다. 비슷한 영역끼리 묶으니 국소 대응의 요지는 살리면서 개수는 줄어듭니다. 둘째는 비대칭 양자화입니다. 문서 임베딩을 정수 8비트나 이진 형태로 양자화합니다. 쿼리 임베딩은 저장하지 않고 그때그때 만들면 되니 높은 정밀도로 둡니다. 저장되는 쪽만 가볍게 만드는 비대칭 발상입니다. 묶어서 줄이고 깎아서 줄이는 두 손잡이를 함께 당기는 셈입니다.

결과 수치는 뚜렷합니다. 풀링 배율 10에 쿼리와 문서를 모두 8비트로 두면 페이지당 약 1점5메가바이트가 약 39킬로바이트로 줄어듭니다. 약 39분의 1이며 기준 정확도의 99퍼센트 이상을 유지합니다. 더 과감한 설정으로 풀링 배율 8에 쿼리는 8비트 문서만 이진으로 두면 페이지당 6킬로바이트까지 내려갑니다. 약 255분의 1이며 원래 검색 품질의 95퍼센트 이상을 지킵니다. 사용자는 저장소 예산과 요구 품질에 따라 이 경계선 위에서 설정을 고르면 됩니다. 정확도를 조금 내주고 저장소를 크게 아낄지 아니면 저장소를 조금 더 쓰고 정확도를 꽉 잡을지의 선택지가 숫자로 주어진 셈입니다. 압축을 사후 땜질이 아니라 설계의 일부로 다룬 태도가 돋보이는 대목입니다.

인덱싱 속도, 초당 51페이지가 바꾸는 현장의 계산

저장소 다음은 속도입니다. 말뭉치를 검색하려면 먼저 모든 문서를 벡터로 바꿔 벡터 저장소에 넣어야 합니다. 이 색인 과정이 느리면 그래픽 처리 장치 사용 시간이 늘고 계산 비용이 늘어납니다. 문서를 새로 넣을 때마다 기다림이 길어집니다. 연구진은 전처리된 이미지 텐서를 기준으로 모델별과 이미지 크기별로 배치 크기를 따로 맞춘 뒤 인코딩 속도를 쟀습니다. 같은 2048픽셀 입력 크기에서 단일 엘40에스 기준으로 260M 검색 모델은 초당 약 51페이지를 인코딩했습니다. 같은 조건의 콜모던브이비이알이 초당 약 26페이지였으니 거의 두 배입니다. 800M 모델도 작은 입력 이미지에서 비교 대상보다 빨랐다고 보고합니다.

이 숫자가 현장에서 뜻하는 바를 풀어보겠습니다. 백만 페이지 말뭉치를 처음 색인한다고 하겠습니다. 초당 26페이지면 약 10시간이 넘게 걸립니다. 초당 51페이지면 절반 이하로 줄어듭니다. 그래픽 처리 장치 대여료로 환산하면 바로 돈입니다. 하루 단위로 빌리는 현장에서는 몇 시간의 차이가 예산표의 한 줄을 바꿉니다. 증분 색인도 마찬가지입니다. 매일 수천 장씩 쌓이는 보고서와 청구서와 도면을 그날그날 색인해야 하는 조직에게 속도는 곧 신선도입니다. 전날 문서가 오늘 검색에 잡히느냐의 문제입니다. 두 배의 속도는 같은 예산으로 두 배 자주 색인하거나 같은 빈도로 절반 비용에 색인한다는 뜻입니다.

속도의 원천도 뼈대 설계로 거슬러 올라갑니다. 별도의 비전 타워와 프로젝터와 디코더를 거치지 않고 단일 인코더로 바로 처리하니 단계가 짧습니다. 윈도 어텐션 중심의 계산 구조도 고해상도 입력에서 부담을 덜어줍니다. 작은 크기는 배치 크기를 키울 여지를 줍니다. 한 번에 더 많은 페이지를 묶어 처리할 수 있습니다. 어느 하나가 마법이 아니라 설계 선택의 합이 속도로 모인 모습입니다. 효율이라는 말이 추상적인 구호가 아니라 초당 페이지라는 구체적인 숫자로 떨어지는 순간입니다. 뒤에서 볼 비주얼 검색 증강 흐름에서도 이 속도는 전제가 됩니다. 검색기가 빨라야 생성기의 답도 신선한 문서 위에서 나옵니다.

직접 써보는 길, 트랜스포머스와 문장 임베딩과 비주얼 검색 증강

연구의 또 다른 미덕은 내놓는 방식입니다. 모델 점검점은 아파치 2점0 허가로 공개되며 허깅페이스 트랜스포머스에서 바로 쓸 수 있습니다. 260M과 800M 본체와 검색용 파생 모델이 함께 나옵니다. 한 번의 순전파로 조밀 임베딩과 다중 벡터 임베딩을 함께 받을 수 있으며 예제에서는 두 개의 텍스트 질문을 두 개의 문서 페이지 이미지에 점수 매기는 흐름을 보여줍니다. 늦은 상호작용 점수에는 평균 최대 유사도를 쓰고 조밀 점수에는 코사인 유사도를 씁니다. 프랑스어 질문과 영어 질문을 함께 던지는 예제가 눈에 띕니다. 다국어라는 말이 구호가 아니라 쓰는 장면에서 확인되도록 만든 구성입니다. 질문의 언어와 문서의 언어가 어긋나도 같은 벡터 공간에서 만나게 하겠다는 뜻입니다.

미세조정 길도 열어 두었습니다. 문장 임베딩 여섯 번째 판본과 함께 쓰도록 조밀용과 늦은 상호작용용으로 나눈 별도 점검점을 제공합니다. 문장 임베딩 쪽은 현재 한 모델당 하나의 검색 헤드만 지원하니 두 헤드를 따로따로 다듬을 때는 나눈 점검점을 쓰고 두 헤드를 함께 학습할 때는 검색용 클래스로 직접 학습기를 짜면 됩니다. 텍스트 인코더인 모던버트가 걸어온 길과 같은 패턴입니다. 뼈대는 같은 클래스로 불러오고 용도에 맞는 머리만 갈아끼우는 방식입니다. 이미 텍스트 임베딩 다룸에 익숙한 팀이라면 낯설지 않은 흐름입니다. 이미지까지 품은 인코더를 텍스트 다루듯 다룰 수 있게 맞춘 셈입니다.

검색을 넘어서는 그림은 비주얼 검색 증강입니다. 시각 문서 검색을 일단계로 두고 원본 페이지 이미지를 그대로 시각 언어 모델에 넘겨 답을 만들게 합니다. 텍스트 검색 증강이 뽑아낸 텍스트 조각을 넘긴다면 비주얼 검색 증강은 페이지 이미지 자체를 넘깁니다. 표와 그림과 도표와 페이지 배치가 납작해지지 않고 살아남습니다. 순서는 분명합니다. 먼저 각 피디에프 페이지를 이미지로 바꾸고 검색 모델로 임베딩을 만들어 벡터 저장소에 넣습니다. 다음으로 사용자 질문을 같은 모델로 임베딩해 상위 몇 개 페이지를 꺼냅니다. 마지막으로 질문 뒤에 이미지들을 이어 붙여 시각 언어 모델에 보내 답을 받습니다. 온라인 시연 공간도 함께 열려 있어 이 흐름을 바로 시험해 볼 수 있습니다. 검색 연구가 논문 속 숫자로 끝나지 않고 손으로 만지는 흐름으로 이어지는 대목입니다.

결론과 다음 질문, 가벼운 인코더가 여는 다음 장

정리하면 이 연구는 따로 학습된 이미지와 텍스트 인코더를 긴 문맥의 단일 양방향 트랜스포머 하나로 바꾼 일입니다. 처음부터 다국어 텍스트 토큰과 32픽셀 원시 이미지 패치를 함께 처리하도록 학습합니다. 검색용 파생 모델은 한 번의 순전파로 조밀 표현과 늦은 상호작용 표현을 함께 냅니다. 260M 모델은 자신보다 작은 구간에서 가장 높은 점수를 받았고 같은 해상도에서 기존 결합형의 두 배 가까운 처리량을 냈습니다. 늦은 상호작용의 큰 저장소 짐은 계층적 풀링과 비대칭 양자화로 페이지당 6킬로바이트까지 줄이면서 원래 품질의 95퍼센트 이상을 지켰습니다. 작은 크기와 빠른 속도 youthful한 보고서가 아니라 같은 조건에서 잰 숫자로 효율을 말한 연구입니다.

남는 질문도 분명합니다. 첫째는 뼈대 자체의 평가입니다. 검색에서 통했다는 것은 벡터 표현이 downstream 일에 맞게 잘 익었다는 신호이지만 분류와 군집과 문장 유사도 같은 다른 벡터 일에서도 같은 효율이 나올지는 더 봐야 합니다. 둘째는 학습 예산의 해석입니다. 약 5240억 토큰이라는 예산은 큰 예산이 아니며 텍스트 쪽은 2900억 토큰 수준입니다. 적은 예산에서 옵티마이저 선택으로 효율을 끌어올렸다는 설명은 설득력이 있지만 예산을 늘리면 곡선이 어디까지 이어질지는 열려 있습니다. 셋째는 압축의 일반화입니다. 비도어 3종에서의 경계선이 전혀 다른 말뭉치와 언어 분포에서도 같은 모양일지는 현장 검증이 필요합니다. 풀링과 양자화는 문서 양식에 따라 민감할 수 있기 때문입니다.

그럼에도 현장의 시사점은 뚜렷합니다. 검색 인프라는 크고 무거운 눈과 입을 함께 짊어지는 대신 작고 함께 학습된 하나의 인코더로 갈아탈 선택지를 얻었습니다. 색인 비용과 저장소 비용과 서빙 복잡도가 함께 내려가는 그림입니다. 다국어 지원이 처음부터 뼈대에 들어 있으니 언어마다 다른 파이프라인을 들고 있을 이유도 줄어듭니다. 아파치 2점0 공개와 트랜스포머스 당일 지원은 그 선택지를 실험이 아니라 도입 검토의 자리로 옮깁니다. 두 친구의 곁가지 탐구에서 시작했다는 후일담이 그래서 더 울림을 줍니다. 제한된 자원에서도 설계의 방향을 바꾸면 경계선을 밀 수 있음을 보인 사례이기 때문입니다. 다음 장은 이 뼈대 위에서 무엇을 쌓을지의 문제로 넘어갑니다. 더 많은 언어와 더 다양한 문서와 더 까다로운 질문 앞에서 가벼운 눈이 어디까지 볼 수 있을지를 묻는 차례입니다.

참고 자료

  1. NeoMME: an efficient Multimodal-native and Multilingual Encoder · huggingface.co

    리뷰 원문