1부에서 Pixel RAG의 기본 개념을 살펴봤다면, 이번에는 조금 더 실전적인 이야기를 해보자.
이미 운영 중인 RAG 시스템에 Pixel RAG를 추가하려면 무엇을 바꿔야 할까?
결론부터 말하면 기존 RAG를 버리고 Pixel RAG로 다시 만드는 것은 좋은 접근이 아니다.
오히려 현실적인 구조는 다음과 같다.
Text RAG + Pixel RAG = Hybrid Document RAG
텍스트 검색이 잘하는 것은 그대로 텍스트 RAG에게 맡기고, 표·차트·이미지·레이아웃처럼 시각적인 정보가 중요한 부분만 Pixel RAG가 담당하도록 만드는 것이다.
1. 기존 RAG 파이프라인부터 다시 보자
일반적인 RAG 시스템의 문서 적재 과정은 다음과 같다.
질문이 들어오면 반대 방향의 검색 과정이 시작된다.
이 구조는 일반적인 텍스트 문서에서는 상당히 잘 작동한다.
문제는 문서가 항상 텍스트만으로 이루어져 있지 않다는 것이다.
2. 문서를 텍스트로 바꾸는 순간 정보가 사라진다
다음과 같은 보고서가 있다고 생각해보자.
2026년 제품별 매출
────────────────────────
2025 2026
제품 A 100 180 ▲80%
제품 B 200 150 ▼25%
제품 C 80 160 ▲100%
[ 매출 추이 그래프 ]
※ 해외 매출 제외사람은 이것을 보는 순간 구조를 이해한다.
- 행은 제품이다.
- 열은 연도다.
- 화살표는 증가·감소를 의미한다.
- 아래 그래프는 표와 관련되어 있다.
- 각주는 전체 숫자에 대한 조건이다.
그런데 PDF Parser가 이것을 텍스트로 변환하면 다음처럼 될 수도 있다.
2026년 제품별 매출
2025 2026
제품 A 100 180
제품 B 200 150
제품 C 80 160
80% 25% 100%
해외 매출 제외글자는 대부분 살아 있다.
하지만 글자 사이의 관계가 사라졌다.
이것이 상당히 중요한 차이다.
Pixel RAG가 해결하려는 핵심 문제도 여기에 있다.
3. Pixel RAG에서는 페이지 자체도 데이터다
Pixel RAG를 추가하면 문서 처리 과정에서 새로운 경로가 하나 생긴다.
같은 PDF에서 두 종류의 검색 데이터를 만드는 것이다.
Text Representation
chunk #101
"제품 A의 2026년 매출은..."그리고
Visual Representation
page #7
[페이지 전체 이미지]둘은 서로 경쟁하는 데이터가 아니다.
같은 원본 문서를 서로 다른 관점에서 표현한 데이터다.
4. Chunk 중심에서 Page 중심으로 하나의 축이 추가된다
기존 RAG에서 검색의 기본 단위는 대부분 Chunk다.
Document
├─ Chunk 1
├─ Chunk 2
├─ Chunk 3
└─ Chunk 4Pixel RAG에서는 Page라는 검색 단위가 추가된다.
Document
├─ Page 1
│ ├─ Chunk 1
│ ├─ Chunk 2
│ └─ Visual Representation
│
├─ Page 2
│ ├─ Chunk 3
│ ├─ Chunk 4
│ └─ Visual Representation
│
└─ Page 3
├─ Chunk 5
└─ Visual Representation여기서 굉장히 중요한 설계 포인트가 생긴다.
Chunk와 Page 사이의 관계를 반드시 알고 있어야 한다.
예를 들어 Chunk 검색 결과가 다음과 같다고 하자.
chunk_id = 392
document_id = 15
page_no = 27그러면 시스템은 필요할 경우 즉시
document 15의 page 27 이미지를 가져올 수 있어야 한다.
이 관계가 Hybrid RAG의 핵심이다.
5. 저장 구조는 어떻게 달라질까?
기존 시스템이 다음과 같은 구조를 가지고 있다고 해보자.
documents
│
├── chunks
│ │
│ └── embeddings
│
└── original_filePixel RAG를 추가하면 대략 다음과 같은 구조가 된다.
documents
│
├── original_file
│
├── pages
│ ├── page_001.png
│ ├── page_002.png
│ └── page_003.png
│
├── chunks
│ └── text_embeddings
│
└── visual_embeddings관계형 DB로 표현한다면 예를 들어 다음과 같이 설계할 수 있다.
documents
---------
id
file_name
storage_path
document_pages
--------------
id
document_id
page_no
image_path
width
height
chunks
------
id
document_id
page_id
text
chunk_index
text_embeddings
---------------
chunk_id
vector_id
visual_embeddings
-----------------
page_id
vector_id
model특히
chunks.page_id관계가 중요하다.
텍스트 검색에서 찾은 Chunk가 원본 문서의 어느 페이지에 존재하는지 알아야 하기 때문이다.
6. Qdrant에는 어떻게 저장할까?
여러 방법이 있지만 가장 이해하기 쉬운 방법은 Collection을 분리하는 것이다.
예를 들어 기존 Text RAG가
documents_textCollection을 사용한다면 Pixel RAG용으로
documents_visual을 추가할 수 있다.
Text Collection
{
"document_id": 15,
"chunk_id": 392,
"page_no": 27,
"text": "제품 A의 매출은...",
"vector": [...]
}Visual Collection
{
"document_id": 15,
"page_id": 128,
"page_no": 27,
"image_path": "documents/15/pages/027.png",
"vector": [...]
}그러면
documents_text
+
documents_visual두 개의 Retrieval 경로를 사용할 수 있다.
7. 그렇다면 질문할 때 둘 다 검색해야 할까?
여기서 재미있는 문제가 하나 등장한다.
사용자가 이렇게 질문했다고 해보자.
회사의 개인정보 보관 기간은 몇 년인가?
이 질문은 거의 완전히 텍스트 기반이다.
굳이 페이지 이미지를 VLM에 전달할 필요가 없다.
반면 다음 질문은 다르다.
2025년과 2026년 제품별 매출 증가율을 비교해줘.
관련 정보가 표에 있다면 Pixel Retrieval이 유리할 가능성이 높다.
또 이런 질문도 있다.
이 보고서의 17페이지 그래프에서 가장 크게 증가한 항목은 뭐야?
이건 사실상 Visual Question이다.
따라서 질문을 먼저 분류할 수 있다.
User Query
│
▼
Query Analyzer
│
┌───────────┼───────────┐
│ │ │
▼ ▼ ▼
TEXT VISUAL HYBRID
│ │ │
▼ ▼ ▼
Text RAG Pixel RAG Both Search
예를 들어 Query Analyzer가 다음처럼 판단할 수 있다.
{
"retrieval_mode": "visual",
"reason": "question refers to chart comparison"
}또는
{
"retrieval_mode": "hybrid",
"reason": "requires both textual explanation and table data"
}8. 하지만 처음부터 Query Router를 만드는 것이 최선일까?
꼭 그렇지는 않다.
초기 시스템에서는 오히려 항상 두 검색을 실행하는 방식도 충분히 현실적이다.
User Query
│
├──────────────┐
▼ ▼
Text Search Visual Search
│ │
Top-K Top-K
│ │
└──────┬───────┘
▼
Result Merge
│
▼
Reranker
│
▼
LLM장점은 구현이 단순하다는 것이다.
단점은 당연히 비용과 검색량이 증가한다는 것이다.
서비스가 성장하면 이후에 Query Router를 넣어 최적화할 수 있다.
1단계
Always Hybrid
↓
2단계
Rule Based Router
↓
3단계
LLM Query Router
↓
4단계
Retrieval 결과까지 이용하는
Adaptive Router개인적으로는 이런 순서가 훨씬 현실적이라고 생각한다.
처음부터 똑똑한 Router를 만드는 것보다 먼저 실제 질문 데이터를 모으는 편이 낫다.
9. 검색 결과를 어떻게 합칠 것인가?
Text Search 결과가 다음과 같다고 해보자.
Chunk 392 score 0.91
Chunk 102 score 0.87
Chunk 812 score 0.82Visual Search에서는
Page 27 score 0.94
Page 12 score 0.89
Page 43 score 0.83가 나왔다.
단순히 score를 비교해서 합치면 문제가 생길 수 있다.
두 Embedding Model의 score 의미가 동일하지 않기 때문이다.
따라서 보통은 Ranking 기반 결합을 생각할 수 있다.
대표적인 방법이 **RRF(Reciprocal Rank Fusion)**다.
개념은 간단하다.
Text Ranking
1. Page 27
2. Page 12
3. Page 5
Visual Ranking
1. Page 12
2. Page 27
3. Page 33두 결과를 합치면
Final Ranking
1. Page 27
2. Page 12
3. Page 5
4. Page 33처럼 만들 수 있다.
여기에 Reranker까지 적용하면 더욱 정교하게 만들 수 있다.
10. VLM은 언제 등장할까?
여기서 많이 헷갈리는 부분이 있다.
Pixel RAG라고 해서 모든 페이지를 VLM에게 보내는 것은 아니다.
그렇게 하면 비용이 너무 커진다.
먼저 Retrieval을 수행한다.
1000 Page PDF
│
▼
Visual Retrieval
│
▼
Top 5 Pages그리고 Top-K 페이지만 VLM에 전달한다.
User Question
+
Page 17 Image
Page 23 Image
Page 81 Image
│
▼
VLM
│
▼
Answer즉 Pixel Retrieval의 중요한 목적 중 하나는
VLM이 봐야 할 페이지를 먼저 찾아주는 것
이라고 할 수 있다.
11. 그래서 비용 구조도 달라진다
기존 Text RAG에서는 주로 다음 비용이 발생한다.
문서 적재
Parsing
↓
Embedding
↓
Vector Storage질의에서는
Query Embedding
↓
Vector Search
↓
LLM정도다.
Pixel RAG를 추가하면 다음 비용이 추가된다.
Page Rendering
+
Visual Embedding
+
Image Storage
+
Visual Retrieval
+
VLM Input특히 수천 페이지짜리 문서를 많이 저장하는 SaaS라면 이 비용을 무시하면 안 된다.
그래서 모든 문서를 무조건 Pixel RAG로 처리할 필요도 없다.
12. 문서별로 Pixel RAG를 선택적으로 적용할 수도 있다
문서 적재 과정에서 Document Analyzer를 둘 수 있다.
Document
│
▼
Document Analyzer
│
┌────────────┴────────────┐
│ │
▼ ▼
Text 중심 Visual 중심
│ │
▼ ▼
Text RAG Hybrid RAG
예를 들어
TXT
Markdown
HTML 문서등은 Text RAG만 수행한다.
반대로
PDF 보고서
PPT
스캔 문서
표가 많은 문서
차트가 많은 문서
복잡한 레이아웃 문서는 Pixel RAG까지 수행한다.
이렇게 하면 비용을 상당히 줄일 수 있다.
13. 또 하나의 방법 — 검색된 페이지에 대해서만 VLM 사용하기
더 현실적인 절충안도 있다.
Visual Embedding 자체를 모든 페이지에 만들지 않는 것이다.
먼저 기존 Text RAG로 검색한다.
User Query
│
▼
Text Retrieval
│
▼
Chunk Top-K
│
▼
Page Number 확인
│
▼
원본 Page Image 로딩
│
▼
VLM예를 들어 Text Search가
chunk 382 → page 17
chunk 912 → page 32
chunk 128 → page 17을 찾았다면
page 17
page 32두 장만 이미지로 가져와 VLM에게 보여준다.
이 방식에는 Visual Retrieval이 없다.
따라서 엄밀히 말하면 완전한 Pixel Retrieval 구조와는 다르지만, 기존 RAG를 크게 변경하지 않으면서 문서의 시각 정보를 활용할 수 있다는 장점이 있다.
실제 서비스를 개발한다면 꽤 매력적인 첫 단계다.
14. 현실적인 도입 단계를 정리해보자
기존 RAG 시스템이 이미 있다면 다음 순서가 안전하다.
Phase 1 — Page Mapping
기존 Chunk에
document_id
page_no정보를 정확하게 저장한다.
Chunk
│
└── Page관계를 만든다.
Phase 2 — Page Image 저장
PDF를 적재할 때 페이지 이미지를 생성한다.
original.pdf
→ page_001.webp
→ page_002.webp
→ page_003.webpObject Storage에 저장한다.
아직 Visual Embedding은 만들지 않는다.
Phase 3 — Text Retrieval + VLM
기존 검색 결과에서 Page를 찾는다.
Text Retrieval
↓
Relevant Chunk
↓
Page Image
↓
VLM이 단계만 적용해도 표와 차트 질문의 품질이 크게 달라질 수 있다.
Phase 4 — Visual Retrieval 추가
그 다음에 필요하면 ColPali나 ColQwen 계열과 같은 Visual Document Retrieval을 도입한다.
Page Image
↓
Visual Embedding
↓
Vector DB이제 텍스트 파서가 놓친 페이지도 직접 찾을 수 있게 된다.
Phase 5 — Hybrid Retrieval
최종적으로
User Query
│
┌──────────┴──────────┐
▼ ▼
Text Retrieval Visual Retrieval
│ │
└──────────┬──────────┘
▼
Fusion
│
▼
Rerank
│
▼
Text
마무리
15. 최종적으로 이런 아키텍처가 된다
지금까지 설명한 내용을 하나의 그림으로 합치면 Hybrid Pixel RAG는 다음과 같은 구조가 된다.
이 구조에서 중요한 것은 Pixel RAG가 기존 RAG를 대체하지 않는다는 것이다.
오히려 기존 RAG가 가지고 있던 텍스트라는 하나의 정보 표현 방식에 ‘문서의 시각적 표현’이라는 또 하나의 검색 축을 추가하는 것에 가깝다.
16. 모든 RAG가 Pixel RAG가 되어야 하는 것은 아니다
Pixel RAG가 흥미로운 기술이라고 해서 모든 문서를 이미지 기반으로 처리해야 하는 것은 아니다.
예를 들어 다음과 같은 문서는 기존 Text RAG가 훨씬 효율적이다.
- Markdown
- TXT
- 소스코드
- 구조가 단순한 HTML
- 일반적인 텍스트 중심 문서
반면 다음과 같은 문서에서는 Pixel RAG의 가치가 커진다.
- 표가 많은 PDF
- 재무 보고서
- 통계 보고서
- 논문
- 프레젠테이션
- 제품 카탈로그
- 매뉴얼
- 스캔 문서
- 차트와 그래프가 많은 문서
- 복잡한 레이아웃을 가진 문서
결국 중요한 것은
문서의 의미가 텍스트만으로 충분히 보존되는가?
라는 질문이다.
그렇다면 Text RAG면 충분하다.
그렇지 않다면 Pixel RAG를 고려할 이유가 생긴다.
17. Pixel RAG의 진짜 의미
RAG 기술은 그동안 상당 부분 다음 문제에 집중해왔다.
“텍스트를 어떻게 잘 나눌 것인가?”
그래서 Chunk Size, Overlap, Semantic Chunking 같은 기술들이 중요했다.
하지만 Pixel RAG는 질문 자체를 조금 바꾼다.
“문서를 반드시 텍스트로 변환해야 하는가?”
사람은 보고서를 읽을 때 글자만 읽지 않는다.
표의 행과 열을 보고,
그래프의 높이를 보고,
제목과 본문의 위치 관계를 보고,
이미지와 설명의 관계를 보고,
페이지 전체의 구조를 함께 이해한다.
그런 의미에서 Pixel RAG는 단순히 새로운 Embedding 기술 하나가 아니다.
RAG가 다루는 정보의 단위를 Text에서 Document 자체로 확장하려는 흐름이라고 볼 수 있다.
마치며
기존 RAG 시스템에 Pixel RAG를 도입한다고 해서 처음부터 시스템 전체를 다시 만들 필요는 없다.
가장 현실적인 접근은 단계적으로 시작하는 것이다.
기존 Text RAG
│
▼
Chunk ↔ Page Mapping
│
▼
Page Image 저장
│
▼
Text Retrieval + VLM
│
▼
Visual Retrieval
│
▼
Hybrid Retrieval
│
▼
Adaptive Multimodal RAG특히 기존 RAG 시스템을 운영하고 있다면 Text Retrieval + Page Image + VLM 정도부터 실험해보는 것이 좋다.
이 방법은 기존 검색 파이프라인을 거의 그대로 유지하면서도 표, 차트, 레이아웃 정보를 활용할 수 있기 때문이다.
그리고 여기까지 구현했을 때 다음 질문이 생긴다.
“그렇다면 실제 Pixel RAG는 어떤 모델을 사용하고, 페이지 이미지를 어떻게 Embedding하며, Qdrant에는 어떤 형태로 저장해야 할까?”
여기서 ColPali, ColQwen 같은 Visual Document Retrieval 모델이 등장한다.
다음 3부에서는 개념 설명을 넘어 실제 구현 관점에서 살펴본다.
다음 글
Pixel RAG 3부 — ColPali·ColQwen과 Qdrant로 구현하는 Visual Document Retrieval
- ColPali는 무엇인가?
- 일반 Image Embedding과 무엇이 다른가?
- Multi-Vector Embedding이 필요한 이유
- Late Interaction은 무엇인가?
- 페이지 한 장에서 왜 여러 Vector가 나오는가?
- Qdrant에는 어떻게 저장하는가?
- Text RAG와 Visual Retrieval을 어떻게 결합하는가?
- Python으로 만드는 간단한 구현 구조
- 실제 서비스에 적용할 때 GPU와 비용은 어느 정도 필요한가?
3부부터는 실제로 만들 수 있는 수준의 아키텍처와 코드를 중심으로 들어가 보자.