페이지가 아니라 토큰을 고른다 — 멀티모달 문서 RAG의 다음 단계, Doc-REFRAG와 HAM-RAG (RAG 특집 6편)

들어가며 — 37.4장

크게 보기

멀티모달 문서 RAG의 데모는 대개 이렇게 생겼다. 슬라이드 한 장이나 재무제표 한 페이지를 올리고, "3분기 매출은?"이라고 물으면, 비전-언어 모델(VLM)이 표를 읽고 답한다. 인상적이다. 그리고 실제 시스템과 거의 관계가 없다.

실제 시스템에서는 질문 하나에 여러 장이 걸린다. 검색기가 코퍼스에서 비슷한 페이지를 찾아 오는데, 그 페이지들은 서로 다른 문서에서 왔고, 대부분은 답과 무관하며, 한두 장만 정답을 담고 있다. 2026년 8월 31일 공개되고 EMNLP 2026 본회의에 채택된 Doc-REFRAG 논문은 이 현실을 숫자로 먼저 세웠다. 열다섯 개 공개 데이터셋과 과학 문서를 모아 실제 검색기를 돌려 보니, 질문 하나당 검색되는 페이지 이미지가 평균 37.4장이었다.

이 숫자가 왜 문제인지는 곱셈 한 번이면 드러난다.

그래서 현장은 타협한다. 리랭커로 상위 5장을 고르고 그것만 넣는다. 5장 안에 답이 없으면 틀린다. 리랭커를 강화하면 53.2%까지 오르지만 질문당 15초가 걸린다. 페이지를 더 넣고 싶은데 넣을 수 없고, 넣을 수 있게 압축하면 표의 숫자가 뭉개진다.

Doc-REFRAG의 답은 질문 자체를 바꾸는 것이다.

페이지 한 장을 108개의 거친 조각으로 접어 두고, 질문이 가리키는 20%의 조각만 원래 해상도로 다시 편다. 그러면 페이지당 약 150 토큰으로 20장을 통째로 넣을 수 있고, 정확도는 57.5%, 시간은 6.1초다. 리랭커 파이프라인보다 정확하고 2.5배 빠르다.

그런데 이 글에는 반대편 이야기도 있다. 같은 달 공개된 HAM-RAG는 "토큰을 아끼는 것"이 아니라 "구조를 잃지 않는 것"을 문제 삼는다. 그림과 텍스트를 낱개 조각으로 평탄화하면, 검색은 되지만 그림이 엉뚱한 문장 옆에 놓인다. 같은 페이지에 있다는 이유만으로. 문서의 장·절·문단·그림·캡션 계층을 검색과 생성에 그대로 살렸더니 이미지 배치 정확도가 24.2% 올랐다.

둘을 합치면 2026년 멀티모달 문서 RAG의 설계 원칙이 나온다. 적게 넣되, 구조를 잃지 않는다. 그리고 그 원칙을 실제로 구현하려면 텍스트 인덱스와 시각 인덱스를 어떻게 한 쌍으로 묶어야 하는지가 이 글의 후반부다.

1. 멀티모달 RAG는 어디까지 왔나

이 블로그는 멀티모달 AI의 역사와 원리를 따로 정리한 적이 있다. 여기서는 문서 검색에 한정해 2024년 이후의 흐름만 짚는다.

출발점은 2024년 6월의 ColPali(ICLR 2025)다. 그 전까지 문서 RAG는 PDF에서 텍스트를 뽑아 색인했다. 표는 깨지고, 차트는 사라지고, 레이아웃 정보는 버려졌다. ColPali는 텍스트 추출을 건너뛰고 페이지 이미지 자체를 VLM에 넣어 여러 개의 벡터로 임베딩한 뒤, 질의 토큰과 페이지 패치 사이의 late interaction(MaxSim)으로 점수를 매겼다. 그리고 그것을 잴 벤치마크 ViDoRe를 만들었다. 이후 2년간 "페이지 이미지를 직접 검색한다"는 발상은 표준이 되었고, ColQwen 계열과 Jina-Embeddings-V4 같은 검색기가 그 위에 쌓였다. 7편에서 다룰 KURE-v2의 late interaction도 같은 계보다.

그런데 검색이 해결되자 다음 병목이 드러났다. 검색된 페이지를 어떻게 읽을 것인가. 검색기는 페이지를 잘 찾아 온다. 문제는 그 페이지들이 여러 장이고, VLM은 한 장을 수천 토큰으로 본다는 것이다. Doc-REFRAG 논문의 진단은 이렇다.

"기존 멀티모달 RAG 모델은 주로 단일 이미지 또는 닫힌 문서 설정을 위해 설계되어 현실적인 다중 이미지 시나리오에서 제한된 정확도를 보인다. 또한 검색된 다수의 이미지를 처리하는 것은 무관한 시각 토큰으로 인한 상당한 계산 부담을 초래한다."

두 문장에 두 문제가 있다. 첫째, 학습 데이터가 "정답 페이지 한 장"으로 되어 있어 모델이 여러 장 중 무관한 것을 무시하는 법을 배운 적이 없다. 둘째, 무관한 페이지의 토큰이 비용을 잡아먹는다. 논문은 두 문제를 데이터셋(DocLongRAG)과 방법(Doc-REFRAG)으로 각각 다룬다.

2. 37.4장이 만드는 비용

크게 보기

2.1 DocLongRAG — 현실을 닮은 학습 데이터

DocLongRAG는 343,474개의 질문-답 쌍과 3,306,267장의 문서 이미지(PDF·슬라이드·포스터)로 이루어져 있다. 열다섯 개 공개 데이터셋에서 문맥 없이 답할 수 있는 질문, 웹 검색이 필요한 질문, 답할 수 없는 질문, 윤리적 문제가 있는 질문을 걸러 냈고(18.2% 제거), 남은 질문마다 실제 검색기가 가져올 법한 오답 페이지를 붙였다.

오답을 붙이는 방식이 이 데이터셋의 핵심이다. 정답 페이지와 비슷한 페이지를 검색기로 찾되, 500개 질의를 사람이 검토해 보니 상위 2.47장 정도는 실제로 관련이 있었다. 그래서 상위 3장은 제외하고 4위부터 20~30장을 무작위로 골라 어려운 오답(hard negative)으로 삼았다. 정답과 헷갈릴 만큼 비슷하지만 답은 없는 페이지들. 그 결과 질문당 평균 37.4장이 된다.

이 숫자는 학습 데이터의 설계값이지만, 실제 검색 환경의 근사치이기도 하다. top-k를 20~40으로 잡는 시스템이라면 정확히 이 상황을 매 질문마다 마주한다.

2.2 곱셈

VLM이 페이지 한 장을 몇 토큰으로 보느냐는 모델마다 다르다. 논문 Table 2의 값으로 계산해 보자.

위젯에서 세 가지를 확인할 수 있다.

고해상도 모델은 컨텍스트에 안 들어간다. 페이지당 2,304 토큰이면 37장은 8만 6천 토큰이다. 32K 창에는 14장이 한계다. 그래서 top-5로 자르고, 5장 안에 답이 없으면 끝이다.

고정 압축은 싸지만 틀린다. TokenPacker처럼 페이지를 144 토큰으로 무조건 압축하면 37장을 다 넣을 수 있다. 그러나 정확도가 37.5%다. 질문과 무관하게 정보를 버리기 때문에, 표의 숫자가 필요한 질문에서 그 숫자가 이미 사라져 있다.

Doc-REFRAG는 150 토큰인데 정확도가 가장 높다. 페이지당 토큰은 TokenPacker와 비슷한데 57.5%다. 차이는 압축률이 아니라 무엇을 남기느냐를 질문이 정한다는 데 있다.

3. Doc-REFRAG — 접고, 고르고, 편다

크게 보기

Doc-REFRAG는 DocOwl2를 백본으로 쓴다. DocOwl2는 페이지 한 장을 324 시각 토큰으로 보는 비교적 가벼운 문서 VLM이다. 그 324 토큰을 다음 세 단계로 처리한다.

직접 만져 보면 감이 온다.

질문을 바꾸면 펴지는 자리가 달라진다. "3분기 영업이익"을 물으면 표 영역이, "매출이 꺾인 해"를 물으면 차트 영역이 원래 해상도로 돌아온다. 나머지는 거친 임베딩으로 남아 "여기에 본문이 있다" 정도의 정보만 준다. 그 정도면 충분하다 — 그 영역은 이 질문에 필요 없으니까.

3.1 선택기는 어떻게 배우나

선택기의 학습이 이 논문에서 가장 흥미로운 부분이다. 어떤 청크를 펴야 하는지 정답 라벨이 없다. 그래서 강화학습으로 배운다. 선택기가 청크 집합을 고르면, 고정된 디코더가 그것으로 답을 내고, 그 답이 맞았는지가 보상이 된다. GRPO 방식으로 여러 선택을 샘플링해 비교하고, PPO 클리핑으로 정책을 갱신한다. 학습 중에는 예산 p를 0.1~0.3에서 무작위로 뽑아 여러 예산에 대응하도록 한다.

전체 학습은 세 단계다. 먼저 단일 이미지 재구성(DocStruct4M)으로 압축 임베딩이 원본 정보를 담도록 하고, 다음으로 다중 이미지 지속 사전학습을 커리큘럼으로(OpenDocVQA → Doc-750K → DocLongRAG) 진행하고, 마지막에 DocLongRAG에서 선택기를 RL로 학습한다. 제거 실험에서 첫 단계를 빼면 평균 정확도가 55.1%에서 19.7%로, 커리큘럼을 빼면 24.2%로, 둘 다 빼면 8.0%로 무너진다. 압축과 선택은 백본이 압축된 표현을 읽을 줄 알아야 비로소 작동한다.

3.2 DocLongRAG 자체가 다른 모델도 끌어올린다

논문의 부수적 발견 하나. Doc-REFRAG 학습에서 DocLongRAG를 빼면 55.1% → 48.9%로 떨어진다. 반대로 다른 모델을 DocLongRAG로 미세조정하면 InternVL3.5는 46.5 → 50.4, MiniCPM-V-2.6은 45.4 → 49.7, DocOwl2는 45.8 → 49.7로 오른다. "여러 장 중 무관한 것을 무시하는 법"은 데이터만으로도 일부 배울 수 있다는 뜻이다. 압축 구조를 도입하지 않더라도, 검색 노이즈가 섞인 학습 데이터로 문서 VLM을 미세조정하는 것 자체가 실무적 선택지다.

4. 왜 ‘무엇을 펼지’가 압축보다 중요한가

크게 보기

논문에서 가장 실무적인 표는 Table 3이다. 같은 압축, 같은 예산(20%)에서 선택 방법만 바꾼 실험.

두 번째 탭을 보자. 무작위 선택 38.8%, 퍼플렉시티 기반 43.7%, 검색기(ColQwen) 점수 기반 53.6%, 학습된 선택기 57.5%. 압축은 전부 같다. 오직 어느 청크를 펴느냐만 다른데 19pp가 벌어진다.

이것이 이 논문의 진짜 메시지다. 시각 토큰 압축 기법은 이전에도 많았다. 문제는 압축이 질문을 모른 채 이루어졌다는 것이다. 페이지를 미리 압축해 두면 어느 질문이 와도 같은 정보가 남고 같은 정보가 사라진다. Doc-REFRAG는 압축은 미리 하되 복원은 질문을 본 뒤에 한다. 검색기 점수로 고르는 것(ColQwen)도 나쁘지 않지만 9.3초가 걸리고, 학습된 선택기는 3.7초다. 선택기가 가볍기 때문이다.

세 번째 탭은 파이프라인 끝단이다. 실제 검색기를 앞에 붙였을 때, 상위 5장 직접 투입 46.6%(4.2초), 리랭커 파이프라인 53.2%(15.4초), Doc-REFRAG 상위 20장 57.5%(6.1초). 리랭커가 "어느 페이지"를 고르는 동안 선택기는 "어느 영역"을 고른다. 둘은 경쟁 관계가 아니라 다른 단계이고, 실무에서는 함께 쓸 수 있다 — 리랭커로 40장을 20장으로 줄이고, 선택기로 20장의 영역을 고른다.

4.1 빽빽한 텍스트에서도 버티나

압축의 당연한 걱정은 글자가 작고 빽빽한 페이지다. 논문은 A4 한 장에 4,000자를 채운 합성 문서로 이를 시험했다. 페이지당 150 토큰의 Doc-REFRAG가 ANLS 95% 이상을 유지해, 324 토큰의 DocOwl2와 256 토큰의 DeepSeek-OCR와 비슷하거나 나았다. 다만 저자들은 4,000자를 넘어가면 약 5% ANLS가 떨어진다고 한계에 적었고, 남은 오류의 64%가 빽빽하거나 구조가 복잡한 텍스트 영역에 몰려 있다고 밝혔다. 청크 크기 k가 학습 시 고정되어 추론 시 조정할 수 없는 것도 한계로 명시했다.

5. HAM-RAG — 같은 페이지라는 이유로 붙이지 마라

크게 보기

Doc-REFRAG가 "얼마나 넣을 것인가"의 문제라면, 2026년 8월 14일 홍콩과기대(광저우) 연구진이 공개한 HAM-RAG는 "넣은 것을 제자리에 놓을 수 있는가"의 문제다.

논문의 진단부터.

"기존 멀티모달 RAG 방법은 구조화된 문서를 고립된 텍스트와 이미지 단위로 평탄화하는 경우가 많아, 충실한 증거 선택과 배치에 필요한 원문의 조직과 지역적 텍스트-이미지 논리를 약화시킨다."

무슨 뜻인지 매뉴얼 하나를 떠올리면 된다. 3장 2절 "벨트 교체"의 단계 4에 그림 3이 있고, 그 옆 단에는 3장 3절 "윤활"이 시작된다. 페이지 단위로 자르면 그림 3과 "월 1회 그리스를 주입한다"가 같은 청크에 들어간다. 검색은 된다. 그러나 답변을 만들 때 모델은 그림 3을 윤활 문장 옆에 놓는다. 같은 페이지에 있었으니까.

세 문제의 오답은 전부 같은 페이지의 텍스트다. 이것이 평탄화가 틀리는 방식이다.

5.1 계층을 증거 객체에 싣는다

크게 보기

HAM-RAG는 문서를 트리로 파싱한다. 내부 노드는 문서·절·소절·절차 단계, 잎 노드는 검색 가능한 텍스트·이미지 단위, 간선은 부모-자식 관계. 각 잎은 원문 내용, 모달리티, 문서 경로, 조상 제목, 지역 문맥, 위치 관계를 가진 구조화된 증거 객체가 된다.

오프라인에서는 텍스트 단위를 "문서 제목 + 제목 경로 + 절 문맥 + 이웃 증거"와 함께 직렬화해 임베딩하고, 이미지에는 주변 문서 증거를 조건으로 한 문맥 인식 설명을 붙여 색인한다. 온라인에서는 검색된 증거를 구조화된 프롬프트로 조립하는데, 텍스트 블록에는 출처 제목과 이웃 문맥이, 이미지 블록에는 이미지 참조·캡션·출처 위치·문맥 설명이 함께 들어간다. 생성 모델은 "이 그림이 3.2절 단계 4의 그림"이라는 사실을 알고 답을 쓴다.

5.2 HAM-Bench와 결과

기존 벤치마크에는 이 문제를 잴 지표가 없었다. 그래서 논문은 벤치마크와 지표를 함께 만들었다.

핵심 지표는 Img-CBS(Image Context BERTScore)다. 답변에서 올바르게 고른 이미지의 주변 텍스트가 정답의 지역 문맥과 얼마나 맞는지를 BERTScore로 잰다. 그림을 골랐느냐(Image F1)가 아니라 그림을 제자리에 놓았느냐를 본다. 여기에 LLM이 정확성·완전성·근거·텍스트-이미지 일관성을 평가하는 종합 품질 점수가 더해진다.

결과는 위 탐색기의 네 번째 탭에 있다. 아홉 개 백본(DeepSeek-V3, Gemini-2.5, GPT-4o, GPT-5, Llama-3.1, Qwen2.5) 평균으로 멀티모달 평균 점수가 54.68 → 64.12, 17.3% 상대 개선. Wukong의 최고 Img-CBS는 50.82 → 63.10, 24.2%. 절이 깊고 그림이 빽빽한 arXiv(GPT-5 기준 44.91 → 53.23)와 절차형 Wukong에서 격차가 크고, 단일 문서인 Wiki(67.73 → 69.07)에서는 작다. 계층이 깊을수록 계층을 보존하는 이득이 크다는, 예상 가능하지만 확인이 필요했던 결과다.

제거 실험은 두 축이 서로 보완한다는 것을 보여 준다. 이미지의 문맥 인식 설명을 뺀 버전은 이미지 지표가 급락하고, 텍스트의 계층 문맥을 뺀 버전과 둘 다 뺀 버전은 평균 점수가 가장 낮다. 운영 수치도 공개했는데, 57,123회 생성 중 실패 2건(0.067%)이 모두 arXiv 부분집합에서 났고, GPT-4o 기준 질문당 약 3.6센트였다.

5.3 기술 매뉴얼과 SOP에서의 의미

이 결과가 실무에서 뜻하는 바는 명확하다. 기술 매뉴얼, 표준 작업 절차(SOP), 규정집, 공고문처럼 구조가 의미인 문서에서는 다음 계층을 파싱 시점에 보존해야 한다.

이미지와 주변 텍스트가 같은 페이지에 있다는 이유만으로 연결해서는 안 된다. 원문 계층(section_path)과 좌표 관계(bounding_box, parent_element_id)를 보존해야 하고, 그 필드들은 4편에서 정리한 문서 객체 필드 그대로다. 멀티모달은 그 필드 중 bounding_box와 caption이 선택에서 필수로 승격되는 경우다.

6. 검색 모델 — Qwen3-VL Embedding과 Reranker

크게 보기

지금까지는 "검색된 페이지를 어떻게 읽나"였다. 검색 자체는 무엇으로 하나. 2026년 1월 알리바바 Qwen 팀이 공개한 Qwen3-VL-Embedding과 Qwen3-VL-Reranker는 현재 가장 널리 쓰이는 오픈 멀티모달 검색 모델 쌍이다.

공식 권장 구조는 단순하다. 임베딩 모델이 1차 회수(수만 페이지 중 수십 장), 리랭커가 재정렬(수십 장 중 상위 몇 장). 리랭커의 수치는 이 2단계 구성에서 잰 것이다. 텍스트 질의로 페이지 이미지를 찾을 수도 있고, 이미지 질의로 비슷한 도면 페이지를 찾을 수도 있으며, "이 스크린샷과 같은 오류 화면"처럼 혼합 입력도 같은 공간에서 처리된다.

두 가지 단서를 붙인다. 첫째, 이 표의 숫자는 모델 카드의 것이고 우리 문서에서 같은 순위가 나온다는 뜻이 아니다. 7편에서 다룰 한국어 검색과 마찬가지로, 같은 청킹·후보 수·리랭킹 조건으로 직접 재야 한다. 둘째, 리랭커는 8B 크로스어텐션이므로 후보 수에 비례해 비용이 든다. 40장을 리랭킹하는 것과 200장을 리랭킹하는 것은 다른 일이다. 3편의 라우터가 후보 수를 함께 결정해야 하는 이유가 여기서도 나온다.

그리고 4장의 파이프라인 실험을 다시 보자. 리랭커로 5장을 잘 골라도 53.2%였고, Doc-REFRAG로 20장을 다 넣으니 57.5%였다. 검색 모델이 아무리 좋아도 읽기 단계가 5장밖에 못 받으면 검색의 이득이 잘린다. 검색 모델과 읽기 모델은 같이 설계해야 한다.

7. 설계 — 텍스트 인덱스 + 시각 인덱스 + 공통 메타데이터

크게 보기

이제 조립이다. 텍스트만 색인하면 표와 그림을 잃고, 이미지만 색인하면 정확한 숫자·조항·고유명사 검색이 약해지고 비용이 든다. 실무 답은 둘 다 색인하고 한쪽에서 다른 쪽으로 건너가는 것이다.

핵심은 세 번째 열이다. 두 인덱스는 따로 검색되지만 같은 메타데이터를 공유해야 한다. 그래야 텍스트 검색에서 페이지를 찾으면 시각 인덱스와 원본 페이지로 확장하고, 시각 검색에서 페이지를 찾으면 해당 위치의 OCR 텍스트와 표 구조를 함께 가져올 수 있다.

다섯 시나리오에서 반복되는 패턴을 요약하면 이렇다.

8. 우리 시스템에 넣는 순서

기존에 텍스트 RAG가 돌고 있고 표·도면·스캔 문서에서 자주 틀린다는 전제다.

9. 한계와 반론

9.1 논문이 스스로 밝힌 것

• Doc-REFRAG: 청크 크기 k가 학습 시 고정되어 추론 시 바꿀 수 없다. 4,000자를 넘는 빽빽한 페이지에서 약 5% ANLS 하락. 선택기는 정답 정확도만 보상으로 삼아 어느 청크가 기여했는지 세부 귀인이 없고, 남은 오류의 64%가 빽빽하거나 구조가 복잡한 텍스트 영역에 몰린다. DocLongRAG의 노이즈는 구성된 것이며 영어 문서만 담는다. 계산 비용 때문에 단일 학습 실행 결과다.
• HAM-RAG: 사전 공개 단계다. 계층이 없는 문서(재구성한 Wiki·arXiv)에서는 파서가 계층을 만들어 줘야 하고, 그 파서의 품질이 결과에 들어간다. 이미지의 문맥 인식 설명을 만드는 데 LLM 호출이 들어가 색인 비용이 있다. 명시적 한계 절이 없어 확장성 경계는 논문에서 알 수 없다.
• Qwen3-VL 검색 모델: 모델 카드 수치이며 벤치마크 대부분이 영어·중국어 중심이다.

9.2 이 특집이 덧붙이는 반론

백본 의존성. Doc-REFRAG는 DocOwl2 위에 지어졌다. 압축 임베딩을 읽으려면 백본이 그것을 학습해야 하므로, 아무 VLM에나 선택기를 얹을 수 있는 것이 아니다. 실무에서 “우리 VLM에 Doc-REFRAG를 붙인다”는 것은 백본을 바꾸거나 재학습한다는 뜻이다. 반면 DocLongRAG로 기존 VLM을 미세조정하는 것(3.2절)은 훨씬 가볍다.

“페이지를 다 넣는다”의 함정. 20장을 150 토큰으로 넣을 수 있다고 해서 40장, 80장으로 늘리면 좋아지는 것은 아니다. 무관한 페이지는 압축되어도 무관하고, 선택기가 볼 청크 수만 늘어난다. 검색 단계에서 후보를 줄이는 일(리랭커, 라우터의 후보 수 결정)은 여전히 필요하다.

계층은 파서가 만든다. HAM-RAG의 이득은 계층이 정확히 파싱됐을 때의 이득이다. 스캔 PDF에서 “이 그림이 어느 절에 속하는가”를 틀리게 파싱하면 계층 보존은 틀린 계층을 보존한다. 4편에서 파싱을 “가장 중요한 기반”이라고 한 이유가 여기서도 반복된다.

한국어. 이 글의 모든 벤치마크는 영어(일부 중국어)다. 한국어 스캔 문서·공고문·도면에서 OCR 품질, 멀티모달 임베딩의 한국어 텍스트 매칭, 표 셀 인식은 전부 별도 검증 대상이다. 7편으로 이어진다.

마무리 — 페이지는 검색의 단위이지 전달의 단위가 아니다

이 글은 37.4장에서 시작했다. 질문 하나에 검색되는 페이지 이미지의 평균. 그 숫자가 만드는 곱셈 때문에 현장은 상위 5장으로 타협했고, 정확도는 46.6%에서 멈췄다.

Doc-REFRAG는 페이지를 전달의 단위로 쓰지 않는다. 페이지는 검색기가 찾아 오는 단위일 뿐이고, VLM에 들어가는 것은 질문이 고른 영역의 토큰이다. 페이지를 108개로 접어 두고 20%만 편다. 그러면 20장을 다 넣고도 리랭커 파이프라인보다 정확하고 빠르다. 그리고 논문은 압축보다 선택이 성능을 결정한다는 것을 무작위 38.8% 대 학습된 선택기 57.5%로 보여 줬다.

HAM-RAG는 그 반대편을 지킨다. 적게 넣는 과정에서 구조를 잃으면, 그림은 검색되지만 엉뚱한 문장 옆에 놓인다. 장·절·단계·그림·캡션의 계층을 증거 객체에 실어 보내면 그림이 제자리를 찾는다. 계층이 깊은 문서일수록 이득이 크다.

둘을 합친 설계 원칙은 짧다. 적게 넣되, 구조를 잃지 않는다. 그리고 그것을 가능하게 하는 것은 새 모델이 아니라 파싱 시점에 저장한 좌표와 계층, 그리고 텍스트 인덱스와 시각 인덱스를 같은 열쇠로 묶는 메타데이터다.

다음 편은 한국어다. 이 글의 벤치마크가 전부 영어였다는 사실이 왜 문제인지, 그리고 2026년 8월 공개된 KURE-v2의 late interaction이 한국어 검색에서 무엇을 바꾸는지.

참고자료

연구 논문

• Hu, R., Xu, S., Hong, M., Yang, X., Zhou, S., Lei, K., Jin, T. & Zhao, Z. Doc-REFRAG: Rethinking Multimodal Document Retrieval-Augmented Generation. arXiv:2608.30163 (2026년 8월 31일) — EMNLP 2026 Main 채택. DocLongRAG 데이터셋 포함
• Li, Y., Hu, Z., Guo, Z. et al. (Tsung, F. 교신) HAM-RAG: Hierarchy-Aware Multimodal RAG for Structure-Faithful Interleaved Generation. arXiv:2608.14032 (2026년 8월 14일, 홍콩과기대 광저우) — 사전 공개
• Li, M., Zhang, Y., Long, D. et al. Qwen3-VL-Embedding and Qwen3-VL-Reranker: A Unified Framework for State-of-the-Art Multimodal Retrieval and Ranking. arXiv:2601.04720 (2026년 1월) · 코드: github.com/QwenLM/Qwen3-VL-Embedding (Apache-2.0) · 모델 카드: Qwen/Qwen3-VL-Reranker-8B
• Faysse, M., Sibille, H., Wu, T. et al. ColPali: Efficient Document Retrieval with Vision Language Models. arXiv:2407.01449 (ICLR 2025) — 페이지 이미지 직접 검색과 ViDoRe 벤치마크의 원전

벤치마크

• ChartQA · SlideVQA · InfoVQA · DUDE · ViDoRe-v2 · MMDocIR — Doc-REFRAG 평가 6종
• HAM-Bench (Wukong · Wiki · arXiv · Recipe) — HAM-RAG 논문과 함께 공개
• MMEB-V2 · JinaVDR · ViDoRe v3 — Qwen3-VL 검색 모델 평가

함께 읽으면 좋은 코어닷투데이 글

• 멀티모달 AI 완전 정복 — ViT·CLIP·GPT-4V로 이어지는 멀티모달 모델의 역사와 원리
• Vision-R1 특집 — VLM의 추론 학습
• 검색 인덱스도 스스로 고쳐진다 (RAG 특집 4편) — 이 글의 문서 객체 필드가 정의된 곳
• 검색은 파이프라인이 아니라 에이전트가 되었다 (RAG 특집 1편) — 라우팅 표의 ⑤ 경로와 navigate/read 도구
• 긴 맥락이 독이 된다: Context Rot — 무관한 토큰이 답을 망치는 이유