PIXELRAG: Web Screenshots Beat Text for Retrieval-Augmented Generation

Source-linked AI summary

PIXELRAG: Web Screenshots Beat Text for Retrieval-Augmented Generation

arXiv:2606.28344v1

TL;DR

Web RAG는 취약하고 정보 손실이 큰 HTML parsing에 의존하는 반면, open web을 대상으로 한 screenshot 기반 retrieval은 아직 거의 탐구되지 않았다. PIXELRAG는 web scale에서 렌더링된 webpage를 image로 retrieval하고 읽으며, text-centric task를 포함한 다양한 benchmark에서 text 기반 RAG를 일관되게 능가한다. 이러한 결과는 visual 및 structural webpage 정보를 보존하는 pixel-space RAG가 점점 더 실용적인 접근법임을 뒷받침한다.

문제
Web RAG는 취약하고 정보 손실이 큰 HTML parsing에 의존하는 반면, open web에서 screenshot 기반 retrieval은 아직 거의 탐구되지 않았다.
방법
PIXELRAG는 webpage를 screenshot으로 렌더링하고, visual embedding을 색인하며, image tile을 retrieval한 뒤 vision-language reader에 직접 입력한다.
결과
PIXELRAG는 text-centric, multimodal, noisy-news, agentic benchmark 전반에서 no-retrieval 및 text 기반 RAG를 일관되게 능가한다.
시사점 및 한계
Pixel-space RAG는 visual 및 structural webpage cue를 보존하며, vision-language model이 향상될수록 점점 더 실용적이 된다. 또한 image compression을 통해 token cost를 최대 3×까지 줄인다.
시사점 및 한계
Screenshot 기반 retrieval은 실행 가능한 hyperlink structure를 잃기 때문에, multi-hop reasoning 및 entity disambiguation에서 직접적인 link following이 제한된다.

Abstract

from arXiv · show

1 서론

PIXELRAG는 복잡하고 손실이 큰 HTML parsing을 우회해 web RAG가 rendered screenshot에서 직접 작동할 수 있는지 묻는다. web-scale screenshot 기반 시스템을 도입하고 no-retrieval 및 text 기반 baseline 대비 폭넓은 성능 향상을 보고하며, image compression을 통해 token efficiency도 개선한다.

동기: HTML-to-text parsing은 복잡하고, 여러 공정을 거치며, 오류가 발생하기 쉽다 [11]. 반면 고급 parser [14] [15]조차 visual cue와 table, chart, image 같은 structured content를 버린다.이러한 손실은 retrieval index의 품질을 저하시키고, 독자에게 잡음이 많아 이해하기 어려운 선형화 텍스트를 남긴다.
접근법: PIXELRAG는 web screenshot을 indexing하고 image tile을 retrieval한 뒤, HTML parsing 없이 이를 vision-language model에 제공함으로써 pixel space에서 직접 RAG를 수행한다.이 visual pipeline은 webpage를 rendering하고 visual index를 구축하며, 독자를 위해 screenshot tile을 retrieval한다.
시스템과 규모: PIXELRAG는 web scale에서 동작하는 최초의 end-to-end screenshot 기반 RAG system으로 제시되며, 7M Wikipedia articles와 CNN, AP News, BBC의 news를 포괄한다.확장 가능한 collection pipeline은 HTML, CSS, image를 수집하고 page를 로컬에서 재구성한 뒤 대규모로 screenshot을 생성한다. retrieval에는 screenshot data에 맞게 조정된 Qwen3-VL-Embedding [28]을 사용한다.
결과: PIXELRAG는 text-centric, multimodal, noisy-news, agentic benchmark 전반에서 no-retrieval 및 text 기반 RAG baseline을 일관되게 능가한다.이러한 향상은 질문 대부분에 텍스트로 답할 수 있는 NQ 와 SimpleQA [31] 같은 Wikipedia QA task뿐 아니라 LiveVQA [32]와 agentic benchmark [33]에서도 나타난다.
효율성: Image compression과 저해상도 reader training은 accuracy–efficiency Pareto frontier를 개선하며, accuracy를 유지하면서 token cost를 최대 3× 줄인다.Pixel representation은 image compression [34] [35]을 통해 RAG token efficiency를 개선하는 추가 경로를 만든다.

2 관련 연구 및 동기

웹 데이터를 대상으로 하는 Text-based RAG는 시각적 단서, 구조화된 콘텐츠, 렌더링 과정에서만 나타나는 정보를 제거할 수 있는 취약하고 손실이 큰 HTML-to-text parsing에 의존한다. Vision-language model의 발전은 대규모 open-domain 웹 검색을 위해 pixel-based RAG를 가능하게 하며, 주로 선별된 시각 문서나 제한된 Wikipedia subset에 집중했던 기존 연구를 넘어선다.

웹 데이터의 Text Parsing: HTML-to-text parsing은 서로 다른 웹 페이지가 언어와 표, 그림, 차트, infobox, 동적 콘텐츠를 뒤섞어 구성하기 때문에 중요한 전처리 병목이다 [38] [11].현재 pipeline은 대체로 heuristic extractor에 의존하므로 대규모 환경에서 신뢰할 수 있는 웹 parsing이 어렵다.
웹 데이터의 Text Parsing: Parser는 취약하고 손실이 커서 시각적 단서와 구조화된 콘텐츠를 버리며, 하나의 extractor가 복원 가능한 웹 페이지 텍스트의 40% 초과를 제거할 수 있다 [38] [11].Parser 선택은 RAG system의 downstream 성능에 상당한 영향을 줄 수 있다 [8].
요약: 왜 Pixel-Based RAG인가?: 현대 VLM은 pixel로 렌더링된 텍스트를 이해하고 더욱 token-efficient해지면서 pixel-based RAG를 점점 더 지원하며, DeepSeek-OCR [34]와 Glyph [35] 같은 system이 이에 해당한다.VLM은 이미 표와 infobox처럼 구조적으로 풍부한 콘텐츠에서 text-only model보다 우수한 성능을 보인다 [41] [42] [43] [16].
Visual Document Retrieval: 본 연구는 소규모 PDF 및 slide benchmark [22] [44] [24] [45] [46] [47]와 제한적인 Wikipedia 연구 [23] [25]를 넘어, 대규모 open-domain Wikipedia에서 end-to-end RAG를 수행하는 visual retrieval로 확장한다.SimpleQA와 NQ를 포함한 benchmark에서 fully visual RAG가 text-based RAG를 대체할 수 있는지 평가한다.
요약: 왜 Pixel-Based RAG인가?: 보존된 콘텐츠조차 일차원 sequence로 평탄화되면 공간적 그룹화, 글꼴 계층, 강조가 사라져 답을 담은 영역을 구분하기 어려워진다.웹 페이지는 렌더링된 결과물로 설계되며, 이러한 시각적 단서는 독자가 정보를 찾는 데 도움을 준다.

3 PIXELRAG

PIXELRAG는 스크린샷 수집과 타일링부터 시각적 인덱싱 및 vision-language 생성까지 전 과정을 픽셀 공간에서 수행하는 end-to-end 웹 검색·생성 파이프라인이다. offline rendering, 고정 크기 타일, approximate nearest-neighbor retrieval을 통해 웹 규모 배포를 지원한다.

파이프라인 개요: PIXELRAG는 웹페이지를 스크린샷으로 렌더링하고, 이를 고정 크기 타일로 분할한 뒤 각 타일을 임베딩하고 임베딩을 인덱싱하여 검색된 top-K 타일을 vision-language reader에 입력한다.
데이터 수집: offline rendering은 반복적인 네트워크 및 브라우저 비용을 피한다. 캐시된 로컬 미러는 재시도 비용을 없애고 experiments reproducible을 보장하며, content-only scrolling은 길이와 무관하게 cover page를 독립적으로 수집한다.
데이터 수집: 고정 폭 875-pixel 스크린샷을 겹치지 않는 1024-pixel 타일로 분할하여 ∼30M Wikipedia tiles와 ∼3.6M news tiles를 생성한다.
인덱스 구축: 데이터스토어가 30M 타일에 달하므로 PIXELRAG는 비용이 지나치게 큰 multivector retrieval을 피하고, 확장 가능한 approximate search와 incremental updates를 위해 FAISS IVF index를 사용한다.
인덱스 구축: ∼2 days: 전체 offline pipeline은 128 CPU cores, 2 TB RAM, 8 H100 GPUs를 갖춘 단일 머신에서 7M Wikipedia articles를 처리한다.

4 Embedding Model 대조 학습 파이프라인

이 파이프라인은 screenshot datastore만으로 distribution shift 상황의 대조 학습 triple을 합성하며, LLM을 사용해 답변 가능한 query를 생성하고 false negative를 필터링한다. InfoNCE로 language backbone과 ViT를 모두 fine-tuning해 rendered webpage screenshot에서 일관된 성능 향상을 달성하며, 단일 H100에서 3시간 이내에 완료된다.

합성 대조 데이터: training set은 외부 label 없이 datastore에서 합성되며, LLM이 유일한 annotator로 사용되고 benchmark query와 label은 training 중 노출되지 않는다.각 triple은 query, positive page, 그리고 positive의 구조와 topic을 공유하지만 query에 답하지 않는 hard negative로 구성된다.
합성 대조 데이터: query는 information-dense page에서 생성한 뒤, source tile에 대한 LLM 검사로 self-containedness와 answerability를 기준으로 필터링된다.이를 통해 page를 암묵적으로 참조하는 query를 제거하고, LLM이 tile만으로 정확히 답할 수 있을 때만 pair를 유지한다.
동적 hard-negative mining: base model이 검색한 Top-K neighbor는 hard-negative candidate가 되지만, query에도 답하는 candidate는 false negative로 식별해 제거한다.이 필터는 LLM에 각 candidate를 CORRECT, WRONG, CANNOT_ANSWER 중 하나로 분류하게 하며, query마다 살아남은 첫 M=2개의 negative를 유지한다.
대조 학습: model은 mined triple과 in-batch negative에 대해 cosine similarity와 temperature parameter를 사용하여 InfoNCE loss [49]로 fine-tuning된다.
ViT를 동결하지 않는 LoRA fine-tuning: LLM backbone과 ViT 모두에 LoRA를 적용하면 rendered webpage screenshot에서 일관된 성능 향상이 나타나며, 이는 기존 document-image retriever 관행 [22]과 반대된다.저자들은 시각적으로 거의 중복되는 webpage tile에 더 강한 visual discrimination이 필요하다고 가설을 세우며, training은 단일 H100에서 3시간 이내에 완료된다.

5 평가

PIXELRAG는 6개 benchmark 모두에서 text-based RAG를 능가하며, retrieval 및 end-to-end QA accuracy가 향상된다. 특히 structured content에서 성능 향상이 크다. 이러한 장점은 modality ablation, agentic search, compression, 더 강력한 VLM reader에서도 나타난다.

5.2 주요 결과: PIXELRAG는 6개 benchmark 모두에서 end-to-end QA를 향상하며, text-based baseline보다 recall은 최대 8.3%, accuracy는 4.5% 높다. fine-tuning을 적용하면 recall은 5.3%, accuracy는 5.0% 추가 향상된다.가장 큰 향상은 NQ-Tables에서 나타나며, 이 benchmark의 answer에는 table과 infobox 같은 structured content가 필요하다.
5.5 Compression: 비슷한 token budget에서 PIXELRAG tile 2개는 더 적은 token을 사용하면서 text chunk 3개의 성능과 같거나 이를 능가하며, image resolution은 조절 가능한 compression knob를 제공한다.Lanczos resampling으로 tile을 downsampling하면 token 수가 비례하여 감소한다.
5.2 Retrieval 분석: PIXELRAG는 Trafilatura보다 answer-bearing evidence를 더 자주 검색하며, evidence Recall@3에서 83.8% 대 77.4%를 달성한다. 이러한 우위는 table과 paragraph에 집중된다.table의 evidence Recall@3은 PIXELRAG 34.8%, Trafilatura 23.8%, mwparserfromhell 5.0%이며, paragraph retrieval은 19.8% 향상된다.
5.3 Ablation: modality ablation에서 Screenshot retrieval은 일관되게 text retrieval보다 우수하며, reader가 OCR text를 입력받는 경우에도 downstream accuracy를 향상한다.retrieval과 reader input format 모두 중요하지만, 더 큰 요인은 retrieval이다. Screenshot →OCR는 두 benchmark 모두에서 Text →Text를 능가한다.
5.4 Agentic search: PIXELRAG는 MoNaCo에서 GPT-5 ReAct에 대해 가장 낮은 cost로 가장 높은 F1을 달성하며, text retrieval, Google, DS-Serve를 능가하면서 cost는 2–4× 더 낮다.MoNaCo answer에는 multivalue list가 자주 포함되고 partial credit이 적절하므로, evaluation에는 token-level F1을 사용한다.
5.6 VLM Scaling: PIXELRAG의 장점은 VLM capability에 좌우된다. 초기 소형 VLM은 text retrieval보다 12.5% 넘게 뒤처지지만, Qwen3-VL-8B와 이후 model은 text retrieval과 같거나 최대 5.9%까지 능가한다.crossover는 Qwen3-VL-4B에서 처음 발생하며, 이 model에서는 pixel retrieval이 text retrieval과 같아진다.

6 결론

PIXELRAG는 HTML 파싱과 텍스트 추출을 거치지 않고 렌더링된 웹페이지에서 직접 retrieval과 generation을 수행한다. Wikipedia 전체를 포괄하는 30M개 이상의 tile로 확장했을 때, visual reasoning이 필요하지 않은 text 중심 benchmark에서도 text 기반 RAG를 능가한다.

Wikipedia 전체를 포괄하는 30M개 이상의 tile을 통해 PIXELRAG는 visual reasoning이 불필요한 text 중심 benchmark에서 text 기반 RAG를 능가한다.
PIXELRAG는 HTML 파싱이나 텍스트 추출을 전혀 거치지 않고 렌더링된 스크린샷에서 직접 retrieval과 generation을 수행한다.
이 접근법은 web-data retrieval-augmented generation을 위해 다양한 웹페이지에서 정제된 텍스트를 추출해야 하는 지속적인 과제를 해결한다.

기술 부록 및 보충 자료 … A.4 Embedding Ablation용 Mini-Datastore

부록에서는 PIXELRAG의 rendering, datastore construction, embedding-training recipe, 효율적인 ablation evaluation을 상세히 다룬다. 대규모 corpus coverage, 다단계 data filtering, contrastive-training settings, 신속한 iteration을 위한 compact mini-datastore를 명시한다.

A.1 Rendering Pipeline: Content-only screenshots는 headless Chromium에서 Wikipedia를 rendering하고 browser UI와 whitespace를 제거한 뒤, indexing을 위해 article 영역을 tiling하여 생성한다.Figure 6은 processing 전후를 보여 준다.
A.1 Rendering Pipeline: Wikipedia storage는 ∼5.6 TB, news storage는 ∼469 GB에 이르지만, embedding 후 images를 폐기하고 query time에 top-K pages에 대해 재생성할 수 있다.또한 vector index는 LEANN [66]과 같은 low-storage methods로 compression할 수 있다.
A.2 Datastore Fetching: Datastore는 7,134,778 Wikipedia articles와 약 30M tiles, 그리고 667,523 news articles와 3.6M tiles를 포함한다.Wikipedia에는 100% content-page coverage를 갖춘 2025-08 Kiwix snapshot을 사용하며, news는 BBC, AP News, CNN을 결합한다.
A.3 Embedding Training: Data Recipe Details and Prompts: Embedding training은 tile selection, synthetic query generation, false-positive filtering, hard-negative judging, implementation details를 포괄하는, 부록에 연속적으로 문서화된 recipe stages를 사용한다.부록에는 §4에서 참조한 prompts, heuristics, implementation choices를 모아 둔다.
A.3.1 Knowledge-intensive tile sampling: Sampling에서는 failed 또는 short renders, metadata와 namespace pages, 그리고 boilerplate evidence를 피하기 위해 각 page의 처음 70%를 넘어서는 tiles를 제거한다.Render-quality gate는 page_height < 3,000 px를 사용하며, regex rules는 Template:, Wikipedia:, File:, Help:, Talk:, Module:, Draft:를 포함한 categories를 제외한다.
A.3.2 Synthetic query generation prompt: Synthetic queries는 rendered tiles에서 gemini-3.1-flash-lite-preview가 생성하며, 이 모델은 five-line Q / A / S / T / C block 또는 SKIP을 반환한다.Generation에는 temperature=0.7과 max_output_tokens=1024를 사용한다.
A.3.3 Self-contained-query filter prompt; A.3.4 Hard-negative consistency-judge prompt; A.3.5 Answerability filter; A.3.6 Training implementation details: Pipeline은 먼저 gpt-4o로 queries의 self-containment를 filtering한 다음 answerability를 filtering하고, 각 candidate tile만 visual context로 사용해 answer-and-judge stages를 거쳐 retrieved hard negatives를 평가한다.Self-containment filter는 candidates의 15.1%를 제거하여 195,079 pairs를 165,537로 줄인다. Training은 약 40K pairs를 유지하며, batch size 64, chunk size 4, hard negatives two개, 7×10−6 peak learning rate로 GradCache를 사용한다.
A.4 Embedding Ablations용 Mini-Datastore: Compact mini-datastore는 400 evaluation queries를 sampling하고, 효율적인 checkpoint evaluation을 위해 각 gold article의 tiles와 base model이 retrieved한 top-100 tiles를 결합한다.이렇게 mixed relevant-and-irrelevant candidate pool이 생성되며, passage에서는 resulting datastore가 400 questions와 7,426 …를 포함한다고 서술한다.

A.5 Reader Fine-tuning: 방법 및 결과 · B 평가 프로토콜

Reader fine-tuning은 자동 검증된 retrieval triple을 사용해 distractor가 포함된 저해상도 이미지로 reader를 학습하며, compression factor와 retrieved-tile count에 따라 compression-only reader와 SFT reader를 비교한다. Compression은 base reader의 성능을 저하시키지만, SFT는 성능을 크게 회복하고 uncompressed reference를 넘어설 수 있다.

A.5 Reader Fine-tuning: 방법 및 결과: SFT data는 embedding training에서 검증된 (q, p, a) triple을 추가 annotation 없이 재사용한 뒤, k∈{1, . . . , 6}개의 tile을 retrieve하고 p가 없으면 추가한다.Retrieved tile은 Lanczos resampling 으로 downsample한다.
A.5 Reader Fine-tuning: 방법 및 결과: Training format은 reader가 저해상도 이미지를 처리하고 distractor tile을 무시하도록 학습시킨다.이 format은 retrieved tile과 관련 passage를 결합해 retrieval setting을 모사한다.
A.5 Reader Fine-tuning: 방법 및 결과: Reader는 retrieved tile set T와 query q를 조건으로 answer token에 대해 standard token-level cross-entropy를 사용해 fine-tuning한다.Loss는 LSFT = −E(q,T ,a) t log Pϕ(at | T , q, a<t)로 정의된다.
B 평가 프로토콜: Evaluation은 held-out 500-example test set에서 GPT-4.1 LLM-judge accuracy를 사용하며, compression factor c와 retrieved-tile count k를 변화시킨다.각 compression level에서 no-SFT compression-only reader와 SFT reader를 비교하고, 1×의 uncompressed base reader를 ceiling reference로 사용한다.
A.5 Reader Fine-tuning: 방법 및 결과: 2× compression에서 0.947 average accuracy를 기록했으며, 이는 compression-only보다 +9.3pp, uncompressed 0.905 ceiling보다 +4.2pp 높다.3× compression에서 SFT는 0.910에 도달해 compression-only baseline보다 +17.2pp 높았으며, 제공된 passage는 나머지 비교에서 중단된다.
A.5 Reader Fine-tuning: 방법 및 결과: 2× compression은 base reader의 average accuracy를 0.905에서 0.854로 낮추며(−5.1pp), 3×에서는 0.738로 낮춘다(−16.7pp).이 결과는 compressed tile에 no-SFT reader를 직접 적용해 측정한 것이다.

B.1 벤치마크 세부사항 · B.2 채점 프로토콜 · C 추가 결과

평가는 시각, 텍스트, 백과사전, 뉴스 질의응답 벤치마크를 아우르며, 벤치마크별 subset과 제외 항목을 포함한다. Wikipedia task에는 deterministic GPT-4.1 LLM-as-judge 채점을 사용하고, LiveVQA에는 객관식 보기 문자에 대한 exact matching을 사용한다.

B.1 벤치마크 세부사항: 벤치마크 범위에는 NQ, NQ-Tables, SimpleQA, MMSearch, Encyclopedic VQA, LiveVQA, MoNaCo가 포함되며, Wikipedia task는 30M-page datastore를 공유하고 LiveVQA는 별도의 news datastore를 사용한다.Table 7은 datastore 범위를 명시하며, MoNaCo는 1,315개의 multi-hop Wikipedia question을 사용한다 [56].
B.1 벤치마크 세부사항: 749개의 Google Landmarks v2 [67] Encyclopedic VQA example은 automatic question을 사용하며, 공식 release에 query image가 없어 iNaturalist는 제외된다.automatic category가 가장 크며 Wikipedia section에서 생성된 자연스러운 표현의 question을 포함한다.
B.1 벤치마크 세부사항: 300개의 MMSearch example을 end to end로 평가하며, 171개의 image-query case와 129개의 text-only case로 구성된다.이는 일부를 sampling한 것이 아니라 전체 MMSearch subset을 평가한다.
B.1 벤치마크 세부사항: CNN, BBC, AP News의 6,632개 LiveVQA QA pair는 editorial photo와 question text를 joint embedding으로 사용하며, anti-bot protection으로 신뢰할 수 있는 capture가 불가능한 Forbes와 Variety는 제외된다.전체 LiveVQA dataset에는 26,888개의 QA pair가 포함되지만, 평가에는 명시된 news subset을 사용한다.
B.1 벤치마크 세부 사항: MoNaCo는 GPT-5 ReAct 에이전트로 전체 1,315개의 멀티홉 Wikipedia 질문 [56]을 평가하며, 에이전트 루프, 프롬프트, 리더는 고정한 채 검색 백엔드만 변경한다.GPT-5는 더 강하고 안정적인 에이전트 기반 동작을 위한 컨트롤러로 사용되어 검색 백엔드 효과를 분리한다.
B.2 채점 프로토콜: Wikipedia QA prediction은 temperature 0, seed 42, max_tokens=1000에서 GPT-4.1 로 채점하며, CORRECT에는 1.0, 다른 label에는 0.0을 부여한다.grader는 [31]을 따라 CORRECT, INCORRECT, NOT_ATTEMPTED를 부여하며, NQ와 NQ-Tables는 최대 10개의 gold alias 중 어느 것과든 일치하는 답을 허용한다.
B.2 채점 프로토콜: LiveVQA는 LLM 기반 평가 대신 5개 선택지 객관식 question에 대해 exact letter-match grading을 사용한다.제공된 protocol passage는 LiveVQA와 Wikipedia benchmark에 사용된 GPT-4.1 grading을 명시적으로 구분한다.

C.1 대체 Reader를 사용한 결과 … D.4 상세 실패 분해

대체 Reader와 모델 규모 전반에서 PIXELRAG의 이점은 방향성 측면에서 일관되게 유지되며, reasoning 모델에서도 마찬가지다. 분석 결과 text-retrieval 실패는 parser의 정보 손실, rank displacement, reader 오류로 추적된다. 전반적으로 text extraction은 trafilatura에서 가장 강력하지만, 구조적 한계로 인해 표와 시각적으로 조직된 증거에는 pixel-space retrieval이 필요하다.

C.1 대체 Reader를 사용한 결과: top-3에서 75.1% versus 70.3%, top-1에서 63.7% versus 58.3%라는 결과는 Qwen3-VL-4B reader에서 LoRA가 SimpleQA accuracy를 향상함을 보여주며, 모든 reader 변형에서 방향성 측면의 결과가 일치한다.Tables 8–9는 대체 reader에 대한 주요 결과를 반복해 제시한다.
C.2 VLM Performance Scaling의 전체 결과: Qwen3.5-4B reasoning의 +4.8 pp와 Qwen3.6-35B-A3B reasoning의 +4.6 pp는 더 높은 output-token 비용에도 불구하고 pixel advantage가 reasoning-mode 모델 전반에서 지속됨을 보여준다.이러한 추세는 Table 5에 요약되고 Figure 7에 시각화된 전체 31-model sweep에서 나온다.
D.1 Wikipedia Text Extractor 비교: Markdown 형식의 trafilatura는 6.40/10을 기록하고 50개 페이지 중 36개에서 승리해, 평가된 7개 Wikipedia extractor 중 가장 강력한 text parser임을 확립한다.Resiliparse는 31개 승리로 6.34/10을 기록하며 뒤를 잇고, pipeline은 text-retrieval baseline에 trafilatura를 사용한다.
D.1 Wikipedia Text Extractor 비교: 최고의 parser조차 tabular data에서는 4.38/10에 그치는데, linearization이 screenshot에는 보존되는 정렬, merged-cell 관계, spatial grouping을 잃기 때문이다.이러한 구조적 ceiling은 표가 포함된 콘텐츠에서 parser를 우회하도록 만든다.
D.2 HTML Parsing 중 시각 정보 손실: Rendered page는 거의 빈 text로 축소되거나 merged-cell table을 평탄화할 수 있어, December의 “Manager of the Month”와 같은 시각적으로 조직된 증거가 복구 불가능해진다.Figure 8은 원래 rendered page와 trafilatura가 추출한 text를 대조한다.
D.3 Text Linearization에 따른 Retrieval Signal Loss: 12-query MoNaCo trace에서 text는 top-5 안에서 정답을 포함한 percentage chunk를 한 번도 retrieve하지 못했지만, pixel retrieval은 rendered table tile을 score 0.616으로 rank 2에 배치했다.이에 대응하는 동일 article의 text table/reference chunk는 score 0.580으로 rank 38에 나타났다.
D.4 상세 실패 분해: Successful retrieval 이후에도 reader loss는 남는다. Qwen3.5-4B에서 유효한 PIXELRAG evidence가 top-3에 나타난 질문 중 7.0%에 대해 reader가 오답을 냈다.이는 799개 질문 중 56개에 해당하며, reader 오류를 parser 및 rank 실패와 구분한다.
D.4 상세 실패 분해: 91개의 rank-loss 사례 중 44%는 text가 정답 없는 infobox를 정답을 포함한 content보다 높게 ranking한 경우였다. 영향을 받은 paragraph 사례에서 PIXELRAG는 42개 질문 중 37개(88%)에 대해 top-3 evidence를 복구했다.동일한 질문에서 text의 평균 paragraph-evidence rank는 22.5였고 PIXELRAG는 1.8이었으며, infobox는 query의 75.9%에서 rank 1을 차지한 반면 PIXELRAG는 67.1%였다.

D.5 HTML DOM Lookup Baseline: 설정 및 분석

HTML DOM lookup baseline은 검색된 텍스트 청크에 대해 연속적인 raw-HTML span을 복원해 웹페이지 구조를 보존하지만, markup이 독자 맥락을 희석하므로 HTML은 flat text보다 성능이 낮다. 이는 구조를 보존하는 데 pixel-space retrieval이 더 token-efficient한 방법임을 뒷받침한다.

설정: 이 baseline은 text retrieval을 재사용한 뒤, 로컬 Kiwix ZIM archive 에서 각 청크의 원본 HTML을 복원해 reader 입력으로 사용한다.reader에는 검색된 k=3개 passage의 HTML을 연결한 내용이 입력되며, 각 passage는 <hr> delimiter로 구분된다.
설정: DOM lookup은 식별성이 높은 cell value 또는 prose fragment를 추출하고, text를 normalize한 뒤, 가장 tight한 match를 선택해 해당 span을 연속적인 direct child로 resolve한다.이를 통해 style, script, navigation element는 제거하면서 중간 table, paragraph, list는 보존하며, match되지 않은 청크는 flat text로 fallback한다.
결과: HTML은 retrieval quality 차이가 1 pp 미만인데도 SimpleQA에서 59.8% vs. 71.6% QA accuracy, LiveVQA에서 56.6% vs. 59.0%를 기록한다.따라서 이 격차는 retrieval이 아니라 reading에서 발생하며, 65k-token reader window에 맞추기 위해 oversized passage는 30k characters로 truncate한다.
HTML이 성능을 저해하는 이유: tag dilution: HTML markup은 SimpleQA context를 7,601에서 28,941 characters로 늘려 tag dilution을 일으키며, LiveVQA의 −2.4 pp 격차보다 큰 −11.8 pp accuracy gap을 초래한다.LiveVQA article은 더 짧고 DOM structure가 더 단순해 markup overhead가 줄어든다.
시사점: HTML은 linearized text보다 semantic richness가 높지만, screenshot은 markup overhead 없이 tile당 대략 875 visual tokens로 동등한 tabular 및 sectional structure를 encode한다.이러한 token efficiency는 pixel-space retrieval이 context-limited reader를 위해 document structure를 보존한다는 이 논문의 핵심 주장을 뒷받침한다.

D.6 Raw HTML 데이터에 직접 RAG 적용

완전한 HTML-native RAG 파이프라인은 DOM 구조를 보존하고 comparable한 retrieval 성능을 달성하지만, raw markup이 reader를 압도해 거의 모든 benchmark에서 plain-text RAG보다 QA 정확도가 크게 낮아진다.

설정: 이 파이프라인은 DOM boundaries에서 raw HTML을 chunking하고, row 기반 sub-chunk에서 table headers를 보존하며, navigation 및 reference elements를 필터링하고, 25.7M embeddings를 index한다.Qwen3-VL-Embedding-2B, nlist=4,096 및 nprobe=128인 FAISS IVFFlat을 사용하고, raw HTML chunks를 reader에 반환한다.
결과: NQ에서 −29.4 pp, NQ-Tables에서 −24.1 pp의 격차는 Trafilatura 대비 HTML-RAG의 QA 정확도 격차 중 가장 크며, EVQA를 제외한 모든 benchmark에서 성능이 하락한다.Retrieval은 comparable하거나 더 우수하므로, 주요 실패 원인은 relevant chunks를 찾는 것이 아니라 raw HTML을 읽는 데 있다.
결과: HTML-RAG는 NQ에서 +2.1 pp, NQ-Tables에서 +1.0 pp만큼 Trafilatura보다 Recall@3를 향상한다.DOM-boundary chunking은 의미적으로 일관된 unit을 생성하며, embedding model은 HTML markup을 어려움 없이 처리한다.
시사점: 이 실험은 HTML markup이 장황한 구조적 encoding으로서 context-window가 제한된 reader에 불리하게 작용하는 반면, screenshots는 tile당 약 875 visual tokens로 구조를 표현한다는 것을 보여준다.따라서 HTML-native chunking과 embedding을 사용하더라도 bottleneck은 retrieval quality가 아니라 token efficiency다.

E 한계, 광범위한 영향, 향후 연구 · F 프롬프트 목록

PIXELRAG의 주요 한계는 링크의 실행 가능성 상실, 상당한 screenshot 저장 공간, English-only 범위, 렌더링된 콘텐츠의 어려운 조정이며, 향후 연구는 더 폭넓은 학습과 hybrid retrieval을 목표로 한다. 부록에는 synthetic query generation, filtering, hard-negative construction, evaluation에 사용된 프롬프트가 수록되어 있다.

E 한계, 광범위한 영향, 향후 연구: PIXELRAG는 실행 가능한 hyperlink 구조를 잃는다. 링크는 시각적으로 렌더링된 상태로 남지만, target page를 retrieval하거나 link 기반 downstream reasoning을 지원하도록 따라갈 수 없다.제안된 완화책은 pixel representation과 함께 link 정보를 보존하거나 복구하는 것이다.
E 한계, 광범위한 영향, 향후 연구: 거의 6 TB에 달하는 screenshot tile이 Wikipedia datastore를 차지하므로, embedding은 유지하면서 inference 시 HTML에서 retrieval된 콘텐츠를 다시 렌더링하는 render-on-demand system이 필요하다.이는 tile embedding을 계산한 뒤 저장 공간을 줄이면서 관련 source content에 대한 접근성을 보존한다.
E 한계, 광범위한 영향, 향후 연구: 평가된 모든 datastore는 English-only이므로 언어 편향이 발생하며, multilingual corpus로의 확장이 중요한 향후 연구 방향으로 남는다.보고된 source는 English Wikipedia와 English-language news outlet이다.
E 한계, 광범위한 영향, 향후 연구: Screenshot retrieval은 HTML parsing과 text extraction을 피함으로써 시각적으로 풍부한 webpage에 이점을 제공하지만, 유해하거나 오해를 유발하거나 사적인 렌더링 콘텐츠도 보존하므로 자동으로 filtering하기 더 어렵다.따라서 대규모 deployment에는 rendering 또는 indexing 과정에서의 content filtering이 필요하다.
E 한계, 광범위한 영향, 향후 연구: 향후 연구에는 target datastore에 맞춘 embedding 조정, scientific paper와 forum 같은 source 전반에서의 cross-domain model 학습, text 기반 retrieval score와 pixel 기반 retrieval score의 결합이 포함된다.이러한 방향은 synthetic training pipeline에 의해 가능해지거나 지원되며, 상보적인 signal을 포착하는 것을 목표로 한다.
F 프롬프트 목록: Prompt appendix는 rendered tile에서의 synthetic query generation을 포함해 논문 전반에서 사용된 full verbatim prompt를 제공한다.Figures 14 and 15는 tile-to-structured-record generation process와 그 Stage 1 prompt를 보여준다.
F 프롬프트 목록: Self-contained-query filter는 각 질문에 YES 또는 NO를 부여하고, 요청을 이해하려면 특정 Wikipedia page, table, 또는 screenshot이 필요한 질문을 제거한다.Figure 16은 이를 Stage 1의 첫 번째 false-positive filter로 식별한다.
F 프롬프트 목록: Evaluation prompt는 VLM에 candidate tile에서 답하도록 요청한 뒤 candidate를 CORRECT, WRONG, 또는 CANNOT_ANSWER로 판정하여 hard negative를 구성한다. evidence QA에는 text-only variant와 multimodal variant가 포함된다.WRONG 또는 CANNOT_ANSWER로 판정된 candidate는 hard negative로 유지하고, CORRECT false negative는 제거한다.