# 지식 데이터 문서 포맷에 따라 AI 파이프라인 구축시 미치는 비용 분석과 전략

**How Machine-Readable Document Formats Affect AI Pipeline Performance and Cost**

---

> **연구 배경**  
> 2026년 3월 5일, 국가인공지능전략위원회는 정책 문서를 마크다운(.md) 형식으로 전환하여 작성·관리·공개한다고 발표하였다 [^1].
> 
> 이 정책적 전환은 HWP 중심의 시각적 편집 문서가 AI 학습·활용에 적합하지 않다는 문제의식에서 출발한다.
> 
> 본 연구노트는 이 전환의 기술적 근거를 벤치마크 문헌 분석을 통해 수립하고, AI 시대의 문서 데이터 프로세싱 전략에 필요한 실증 기반(evidence base)을 구축한다.

---

## 목차

1. [왜 문서 포맷이 AI 성능을 결정하는가](#1-왜-문서-포맷이-ai-성능을-결정하는가)
2. [인용 논문의 저명성 및 신뢰도](#2-인용-논문의-저명성-및-신뢰도)
3. [비정형 문서의 비용: OCR이 만드는 성능 천장](#3-비정형-문서의-비용-ocr이-만드는-성능-천장)
4. [구조화된 포맷의 이점: 검색 정확도와 추론 품질](#4-구조화된-포맷의-이점-검색-정확도와-추론-품질)
5. [포맷이 결정하는 토큰 비용: 기업 규모의 체감치](#5-포맷이-결정하는-토큰-비용-기업-규모의-체감치)
6. [LLM이 인식하는 포맷의 스펙트럼](#6-llm이-인식하는-포맷의-스펙트럼)
7. [종합: 확인된 사실과 미해결 과제](#7-종합-확인된-사실과-미해결-과제)
8. [다음 연구를 위한 방향](#8-다음-연구를-위한-방향)
9. [참고문헌](#9-참고문헌)

---

## 1. 왜 문서 포맷이 AI 성능을 결정하는가

AI 시스템, 특히 검색 증강 생성(RAG) 파이프라인에서 외부 문서는 핵심 입력 자원이다. 같은 정보라도 **어떤 형태로 투입하느냐**에 따라 검색 정확도, 추론 품질, 토큰 비용이 극적으로 달라진다.

```mermaid
%%{init: {'theme': 'neutral', 'themeVariables': {'fontSize': '14px', 'fontFamily': 'IBM Plex Sans, Pretendard, sans-serif'}}}%%
flowchart LR
    subgraph legacy["비정형 문서 파이프라인"]
        direction TB
        A["PDF / HWP / 스캔본"] --> B["OCR 텍스트 추출"]
        B --> C["포맷팅 노이즈 발생"]
        C --> D["글자수 기반 기계적 Chunking"]
        D --> E["검색 실패 · 환각 · 토큰 낭비"]
    end

    subgraph modern["기계가독형 문서 파이프라인"]
        direction TB
        F["Markdown / HTML"] --> G["태그 기반 의미 파싱"]
        G --> H["계층 구조 보존"]
        H --> I["의미 기반 Chunking"]
        I --> J["고정밀 검색 · 정확한 추론 · 토큰 절약"]
    end

    E -. "성능·비용 격차" .-> J

    style legacy fill:none,stroke:#b0b0b0,stroke-width:1px
    style modern fill:none,stroke:#2563eb,stroke-width:2px
    style E color:#b91c1c,stroke:#b91c1c
    style J color:#15803d,stroke:#15803d
```

> *그림 1. 비정형 문서와 기계가독형 문서의 RAG 파이프라인 구조 비교*

국가AI전략위원회가 밝힌 전환 이유: *"기존 한글 문서는 글꼴, 자간, 기호표 등 다양한 편집 요소가 적용돼 AI가 문장과 문단 구조를 정확히 인식하는 데 어려움이 있다"* [^1].

---

## 2. 인용 논문의 저명성 및 신뢰도

선정 시 특정 벤더의 자사 제품 홍보 성격이 강한 논문은 배제하였으며, 구조화 포맷의 효과를 일관되게 지지하는 독립적 연구만을 선별하였다.

| 논문 | 게재처 | 게재처 위상 | 저자·소속 | 학술적 기여 |
|:-----|:-------|:----------|:---------|:----------|
| **OHR-Bench** [^2] | ICCV 2025 | CV Top-3, h5-index 291, 수락률 27% | 북경대 Wentao Zhang 그룹 | OCR→RAG 연쇄 영향 최초 전용 벤치마크 |
| **HtmlRAG** [^3] | WWW 2025 | 웹/IR 최고 학회, CORE A* | 중국인민대 Ji-Rong Wen (IR 저명) | HTML RAG 활용 최초 연구, GH 460+ stars |
| **DocLLM** [^4] | ACL 2024 | NLP Top-1, h5-index 279 | JPMorgan AI Research | 레이아웃 인식 LLM 최초 제안, 인용 200+ |
| **LAD-RAG** [^5] | arXiv 2025 | 프리프린트 | USC 외 다기관 | 레이아웃 인식 동적 RAG, 4개 벤치마크 검증 |
| **UniDoc-Bench** [^6] | arXiv 2025 | 프리프린트 | Salesforce AI Research | MM-RAG 통합 벤치마크 최초, 70k PDF 규모 |
| **KL3M** [^7] | arXiv 2025 | 프리프린트 | ALEA Institute (Stanford/MSU) | 법률/금융 토크나이저 최초 공개, Apache 2.0 |
| **BigDocs** [^8] | ICLR 2025 | ML Top-3, h5-index 304 | Mila (Bengio 연구소), 43명 공저 | 7.5M 문서 오픈셋, **Yoshua Bengio 공저** |
| **Prompt Format** [^9] | arXiv 2024 | 프리프린트 | CVS Health 독립 연구팀 | 포맷별 LLM 성능 비교 최초 체계적 실험 |
| **MDEval** [^10] | arXiv 2025 | 프리프린트 | 화중과기대(HUST) | LLM Markdown 인식 평가 최초 전용 벤치마크 |
| **StructEval** [^11] | arXiv 2025 | 프리프린트 | Waterloo대 Wenhu Chen 그룹 | 18개 포맷·44개 태스크 구조적 출력 벤치마크 |
| **PDFbench** [^12] | 독립 벤치마크 2025 | Applied AI (독립 리서치) | 800+ 실제 업무 문서, 17개 파서 비교 | 텍스트 정확도와 구조 복원율을 분리 측정한 최초 대규모 벤치마크 |
| **Improving Agents** [^13][^14] | 독립 벤치마크 2025 | Improving Agents (AI 에이전트 최적화 전문) | 11개 포맷, 1,000건 테이블 + 1,000건 중첩 데이터 | LLM 입력 포맷별 이해 정확도·토큰 효율 최초 대규모 비교 |
| **Skyvern** [^15] | 실무 보고 2024 | Skyvern (브라우저 자동화 스타트업) | 프로덕션 환경 HTML vs JSON 전환 | 토큰 11% 절감 + 성공률 3.9% 향상 실무 검증 |

> *표 1. 인용 논문 저명성 요약. h5-index는 Google Scholar Metrics 2025 기준.*

---

## 3. 비정형 문서의 비용: OCR이 만드는 성능 천장

### 3.1 OHR-Bench — 모든 OCR은 실패한다

**OHR-Bench** (ICCV 2025) [^2]는 OCR이 RAG 시스템에 미치는 연쇄적 영향을 측정한 최초의 전용 벤치마크이다.

**실험 규모:** 7개 도메인 / 8,561개 문서 이미지 / 8,498개 QA 쌍

```mermaid
%%{init: {'theme': 'neutral', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'IBM Plex Sans, Pretendard, sans-serif'}}}%%
xychart-beta
    title "OHR-Bench: Ground Truth 대비 F1 하락폭 (%)"
    x-axis ["Qwen2.5-VL-72B", "MinerU", "GOT-OCR", "Pipeline OCR"]
    y-axis "F1 Score Loss (%)" 0 --> 25
    bar [14, 18, 20, 22]
```

> *그림 2. OCR 솔루션별 F1 하락폭. 최우수 솔루션에서도 14% 하락 관찰.*

| 핵심 발견 | 수치 | 의미 |
|:---------|:-----|:-----|
| 최우수 OCR 전체 F1 하락 | **-14%** | 현존 최고 기술로도 원본 대비 14% 손실 |
| EM@1 하락 | **-1.9** | 정확 매칭 기준 유의미 저하 |
| F1@1 하락 | **-2.93** | 검색·생성 단계 모두에서 누적 |

연구진 결론: *"평가된 모든 OCR 솔루션이 성능 저하를 보였으며, 고품질 RAG 지식베이스 구축에 적합한 솔루션은 존재하지 않았다."*

**해석:** 비정형 문서→텍스트 추출→RAG 투입 파이프라인은, 어떤 OCR을 사용하든 **구조적 성능 상한선(ceiling)**을 가진다. 문서를 처음부터 기계가독형으로 생산하는 것만이 이 상한선 자체를 제거할 수 있다.

---

## 4. 구조화된 포맷의 이점: 검색 정확도와 추론 품질

### 4.1 HtmlRAG — 구조 보존이 RAG 품질을 높인다

**HtmlRAG** (WWW 2025) [^3]는 평문 대신 **구조가 보존된 HTML**을 RAG 입력으로 사용할 경우의 성능 우위를 6개 QA 데이터셋에서 검증하였다.

```mermaid
%%{init: {'theme': 'neutral', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'IBM Plex Sans, Pretendard, sans-serif'}}}%%
flowchart TD
    A["웹 문서 원본 HTML"] --> B{"RAG 투입 방식"}
    B -->|"평문 추출"| C["헤딩·표 구조 소실"]
    B -->|"HTML 보존 + Pruning"| D["구조적 의미 유지"]
    C --> E["6/6 QA 데이터셋에서 열위"]
    D --> F["6/6 QA 데이터셋에서 일관 우위"]

    style C stroke:#b91c1c,stroke-dasharray:5 5
    style D stroke:#2563eb,stroke-width:2px
    style E color:#b91c1c
    style F color:#15803d,font-weight:bold
```

> *그림 3. HtmlRAG의 실험 구조. 구조 보존 경로가 6개 데이터셋 전체에서 우위.*

마크다운의 `#`, `##`, `|표|` 구문은 HTML의 `<h1>`, `<h2>`, `<table>`을 경량화된 형태로 보존한다. HtmlRAG의 핵심 발견 — **"구조적 의미가 보존될수록 RAG 품질이 높아진다"** — 은 마크다운의 가치를 구조적 관점에서 뒷받침한다.

### 4.2 DocLLM — 레이아웃 정보의 정량적 가치

**DocLLM** (ACL 2024) [^4]은 bounding box 정보만으로 문서의 공간 구조를 파악하는 disentangled spatial attention 메커니즘을 도입하였다.

| 실험 설정 | 결과 | 비고 |
|:---------|:-----|:-----|
| 16개 데이터셋 SotA 달성 | **14/16** (87.5%) | 이미지 인코더 없이 달성 |
| 미확인 데이터셋 일반화 | **4/5** (80%) | STDD 설정 |
| Llama2-7B 대비 성능 향상 | **+15% ~ +61%** | 미확인 4개 데이터셋 기준 |

> *표 3. DocLLM 핵심 실험 결과.*

레이아웃 정보가 보존되면 LLM의 문서 이해 성능이 15~61% 향상된다. 마크다운의 제목 계층, 들여쓰기, 표 구문은 이 레이아웃 정보의 핵심을 텍스트 수준에서 보존하는 수단이다.

### 4.3 LAD-RAG — 구조 메타데이터가 검색을 결정한다

**LAD-RAG** (arXiv 2025) [^5]는 문서의 레이아웃 구조와 페이지 간 의존성을 심볼릭 그래프로 구축하여 동적으로 검색하는 프레임워크이다. 4개 벤치마크(MMLongBench-Doc, LongDocURL, DUDE, MP-DocVQA)에서 평가하였다.

| 측정 항목 | 수치 | 조건 |
|:---------|:-----|:-----|
| 평균 Perfect Recall | **90% 이상** | top-k 튜닝 없음 |
| 베이스라인 대비 Recall 향상 | **최대 +20%** | 동일 노이즈 수준 비교 |

> *표 4. LAD-RAG 핵심 실험 결과.*

구조적 메타데이터(섹션 헤더, 페이지 간 관계, 요소 유형)를 명시적으로 인덱싱하면 고정 top-k 방식보다 현저히 높은 recall을 달성한다. 마크다운의 `#`, `##`, `---` 등이 이 메타데이터를 자연스럽게 표현하며, 평문에서는 불가능하다.

### 4.4 UniDoc-Bench — 텍스트만으로는 부족하다

**UniDoc-Bench** (arXiv 2025, Salesforce AI Research) [^6]은 70k PDF 페이지, 1,600개 멀티모달 QA 쌍으로 4가지 RAG 패러다임을 동일 조건에서 비교하였다.

| 순위 | RAG 패러다임 | Completeness | 비고 |
|:-----|:-----------|:------------|:-----|
| 1위 | **텍스트-이미지 융합** (text-image fusion) | **68.4%** | 별도 텍스트·이미지 검색기를 결합 |
| 2위 | 텍스트 전용 (text-only) | 65.3% | 텍스트만으로도 융합의 95% 수준 |
| 3위 | 멀티모달 공동 임베딩 (joint retrieval) | 64.1% | 단일 임베딩으로 두 모달리티를 처리 |
| 4위 | 이미지 전용 (image-only) | 54.5% | 텍스트 대비 **-10.8%p**, 최하위 |

> *표 5. UniDoc-Bench 4가지 RAG 패러다임의 Completeness 점수(1,600 QA, GPT-4.1 기반 평가). top-k=10.*

텍스트도 이미지도 단독으로는 불충분하다. 그러나 **텍스트가 잘 구조화되어 있을수록 fusion의 품질도 높아진다.** 마크다운은 이 "잘 구조화된 텍스트"를 가장 경량으로 생산하는 수단이다.

---

## 5. 포맷이 결정하는 토큰 비용: 기업 규모의 체감치

### 5.1 기업 서비스 규모에서의 비용 환산

LLM의 모든 연산은 "토큰" 단위로 이루어진다. 동일한 정보를 더 적은 토큰으로 전달할수록 GPU 사용 시간, 전기 비용, 응답 지연이 줄어든다.

아래 표는 KL3M [^7]의 9-17% 문서 전체 토큰 절감 결과를 기반으로, 실제 서비스 기업의 규모에서 비용을 환산한 것이다. 15% 절감(중간값)을 적용하였다.

| 규모 | 비구조화 평문 | 구조화 마크다운 (15% 절감) | 절감 효과 |
|:-----|:-----------|:---------------------|:---------|
| **일 10만 건 · 문서당 5,000토큰** | | | |
| — 일간 토큰 수 | 5억 | 4.25억 | **-7,500만 토큰/일** |
| — 일간 API 비용 ($10/M) | $5,000 | $4,250 | **$750/일** |
| — **연간 API 비용** (250 영업일) | **$1,250,000** | **$1,062,500** | **연 $187,500 절감** |
| — 연간 A100 GPU 시간 | 약 2,083시간 | 약 1,770시간 | **313시간 절감** |
| — 연간 전력 (A100 300W) | 625 kWh | 531 kWh | **94 kWh 절감** |
| | | | |
| **일 100만 건 (대형 플랫폼)** | | | |
| — **연간 API 비용** | **$12,500,000** | **$10,625,000** | **연 $1,875,000 절감** |
| — 연간 A100 GPU 시간 | 약 20,833시간 | 약 17,708시간 | **3,125시간 절감** |

> *표 6. 기업 서비스 규모에서의 토큰 비용 환산. 15% 절감 기준(KL3M 중간값).*
>
> *참고: 도메인 특화 용어가 많은 경우(법률: 최대 83%, 금융: 39%) 절감폭은 이보다 훨씬 크다. 또한 토큰 절감은 API 비용뿐 아니라 Context Window 활용 효율, 응답 지연(latency), 배치 처리량에도 복합적으로 기여한다.*

### 5.2 KL3M Tokenizers — 도메인 특화 토크나이저의 효과

**KL3M Tokenizers** (arXiv 2025, ALEA Institute) [^7]는 약 1.5T 토큰의 법률/금융 텍스트 코퍼스에서 훈련된 도메인 특화 BPE 토크나이저이다.

| 적용 범위 | GPT-4o 및 Llama3 대비 절감 |
|:---------|:-------------------------|
| 법률/금융/행정 **문서 전체** | **9-17%** |
| 법률 전문 용어 (예: "Fed. R. Civ. P. 56(a)") | **최대 83%** |
| 금융 전문 용어 (예: "EBITDA") | **39%** |

> *표 7. KL3M 토크나이저의 토큰 절감 효과. 83%는 용어 단위 수치, 문서 전체는 9-17%.*

### 5.3 BigDocs-Bench — 구조화 데이터의 훈련 가치

**BigDocs** (ICLR 2025, Mila / Yoshua Bengio 공저) [^8]는 7.5M 멀티모달 문서와 329k 훈련 샘플을 포함하는 대규모 오픈 데이터셋이다.

| 측정 항목 | 수치 |
|:---------|:-----|
| BigDocs fine-tune 모델 vs GPT-4o (구조화 출력 태스크) | **+25.8%** |
| 인간 평가 선호도 vs GPT-4o | **63%** |
| 인간 평가 선호도 vs Phi3.5 Instruct | **88%** |

> *표 8. BigDocs-Bench 결과. 구조화 문서 훈련의 가치를 입증.*

사내 문서를 마크다운으로 축적하면 향후 모델 fine-tuning 데이터로도 활용 가능하다.

---


## 6. 왜 Markdown인가 — 포맷 선택의 다차원 비교

### 6.1 측정 차원의 분리

포맷 비교에서 흔히 빠지는 오류는, **LLM이 특정 포맷을 "생성하는 능력"과 특정 포맷을 "입력받아 이해하는 능력"을 혼동하는 것**이다. JSON은 LLM이 생성할 때 90%+ 정확도를 보이지만(StructEval [^11]), 이것이 "JSON으로 데이터를 넣으면 AI가 잘 이해한다"를 의미하지는 않는다. 실제로는 정반대 결과가 나온다. 이 차이를 명확히 하기 위해, 포맷 성능을 **3개 차원**으로 분리한다.

### 6.2 차원 A — LLM의 포맷 생성 정확도

StructEval [^11]에서 측정한, LLM이 자연어로부터 각 포맷을 정확하게 생성하는 능력이다. JSON, HTML, CSV, Markdown 모두 90% 이상으로 **이 차원에서는 4개 포맷 간 유의미한 차이가 없다.**

| 포맷 | 생성 정확도 |
|:-----|:----------|
| JSON / HTML / CSV / Markdown | 모두 **90% 이상** (AI 친화 포맷 군) |

> *표 9-A. StructEval 기준 LLM 포맷 생성 정확도. 4종 모두 90%+로 차이 없음.*

### 6.3 차원 B — 포맷을 입력으로 받았을 때의 이해·추론 정확도

이 차원에서 **Markdown과 JSON의 차이가 벌어진다.** 동일 데이터를 서로 다른 포맷으로 LLM에 입력했을 때의 정확도이다.

**추론 태스크** (Prompt Format [^9], GPT-4 MMLU):

| 포맷 | 정확도 |
|:-----|:------|
| **Markdown** | **81.2%** |
| Plain Text | 77.0% |
| YAML | 75.5% |
| JSON | **73.9%** |

**테이블 이해 태스크** (Improving Agents [^13], 11개 포맷, 1,000건):

| 포맷 | 정확도 |
|:-----|:------|
| **Markdown-KV** | **60.7%** |
| JSON | 50.8% |
| CSV | 44.7% |

**중첩 데이터 이해** (Improving Agents [^14], 1,000건 질의, GPT-5 Nano·Gemini):

| 포맷 | 결과 |
|:-----|:-----|
| YAML | 1위 |
| **Markdown** | 2위 (YAML과 근접) |
| JSON | **하위권** (GPT-5 Nano·Gemini에서 성능 저조) |
| XML | **최하위** (Markdown 대비 80% 더 많은 토큰 사용하면서도 최저 정확도) |

> *표 9-B. 입력 포맷별 LLM 이해·추론 정확도. Markdown이 일관되게 상위권이며, JSON은 "생성은 잘 하지만 이해는 떨어지는" 역전 현상을 보인다.*

### 6.4 차원 C — 토큰 효율성

동일 데이터를 각 포맷으로 표현했을 때의 토큰 소비량이다.

| 포맷 | JSON 대비 토큰 비율 | 출처 |
|:-----|:------------------|:-----|
| **Markdown** | **-34~38%** | Improving Agents (중첩) [^14] |
| YAML | Markdown보다 약 10% 많음 | Improving Agents (중첩) [^14] |
| JSON | 기준 (100%) | — |
| XML | **+80%** (Markdown 대비) | Improving Agents (중첩) [^14] |

> *표 9-C. 동일 데이터의 포맷별 토큰 소비량.*

### 6.5 3개 차원 종합: 왜 Markdown이 최적인가

| 차원 | JSON | HTML | CSV | **Markdown** |
|:-----|:-----|:-----|:----|:------------|
| A. 생성 정확도 | 90%+ | 90%+ | 90%+ | **90%+** |
| B. 입력 시 추론 정확도 | 73.9% | — | 44.7% | **81.2%** |
| C. 토큰 효율 (JSON 대비) | 기준 | -11% | 최소 | **-34~38%** |
| 인간 가독성 | 낮음 | 중간 | 표 한정 | **높음** |
| 범용성 | 데이터 교환 특화 | 웹 특화 | 표 한정 | **문서 전반** |

> *표 10. 3개 차원 종합 비교.*

**핵심:** JSON·HTML·CSV는 "LLM이 잘 만들어내는 포맷"이지 "LLM이 잘 이해하는 포맷"이 아니다. **Markdown은 생성도 잘 하고(90%+), 이해도 잘 하며(81.2%), 토큰도 적게 쓰고(-34~38%), 사람도 읽기 쉬운** 유일한 포맷이다.

### 6.6 비구조화 문서와의 격차

| 처리 방식 | 수치 | 출처 |
|:---------|:-----|:-----|
| 비구조화 PDF → 텍스트 추출 정확도 | 75% | PDFbench [^12] |
| 비구조화 PDF → **구조 복원율** | **13%** | PDFbench [^12] |
| 비구조화 PDF → RAG F1 하락 | **-14%** | OHR-Bench [^2] |

> *표 11. 비구조화 PDF의 처리 수치. "텍스트를 뽑았으니 괜찮다"는 가정이 위험한 이유.*

```mermaid
%%{init: {'theme': 'neutral', 'themeVariables': {'fontSize': '13px', 'fontFamily': 'IBM Plex Sans, Pretendard, sans-serif'}}}%%
xychart-beta
    title "포맷별 LLM 이해·추론 정확도 (%)"
    x-axis ["MD(MMLU)", "PlainText", "YAML", "JSON(MMLU)", "MD-KV(Tbl)", "JSON(Tbl)", "CSV(Tbl)", "PDF구조"]
    y-axis "Accuracy (%)" 0 --> 90
    bar [81, 77, 75, 74, 61, 51, 45, 13]
```

> *그림 4. "입력 시 이해 정확도" 기준 비교. Markdown이 최상위, 비구조화 PDF가 최하위.*

### 6.7 MDEval — LLM은 이미 마크다운을 이해한다

**MDEval** (arXiv 2025) [^10]은 LLM 마크다운 인식 능력 평가 최초 벤치마크이다.

| 발견 | 상세 |
|:-----|:-----|
| 자발적 구조 생성 | GPT-4o 등은 지시 없이도 Markdown 구조를 출력 |
| 능력 간 상관관계 | Markdown Awareness와 코딩·추론 능력 간 양의 Spearman 상관 |
| 향상 가능성 | QLoRA fine-tuning으로 개선 가능 (~20GB GPU, 13B) |

> *표 12. MDEval 핵심 발견.*

Markdown이 이해에서 우위를 보이는 근본 이유: **LLM 훈련 데이터에 Markdown이 압도적으로 포함**되어 있기 때문이다. GitHub README, 기술 문서, 위키, 블로그 등 웹 상의 구조화된 텍스트 대부분이 Markdown으로 작성되어 있다.

---

## 7. 종합: 확인된 사실

### 7.1 확인된 사실

| 영역 | 확인된 사실 | 핵심 수치 | 근거 |
|:-----|:---------|:---------|:-----|
| OCR의 한계 | 모든 OCR이 RAG 성능을 저하시킴 | F1 -14% (최우수) | OHR-Bench [^2] |
| 구조 보존 | 구조가 보존된 포맷이 평문보다 RAG에서 우위 | 6/6 QA 일관 우위 | HtmlRAG [^3] |
| 레이아웃 | 공간 레이아웃 정보가 LLM 이해도에 직접 기여 | 14/16 SotA, +15~61% | DocLLM [^4] |
| 구조 메타데이터 | 명시적 구조 인덱싱이 검색 recall을 극대화 | 90%+ Recall | LAD-RAG [^5] |
| 멀티모달 | 텍스트-이미지 융합이 단일 모달리티보다 우위 | 68.4% vs 54.5% (이미지단독) | UniDoc-Bench [^6] |
| 토큰 효율 | 구조화 포맷이 토큰을 절감 | 문서 전체 9-17% | KL3M [^7] |
| 훈련 가치 | 구조화 문서가 훈련 데이터로서 높은 가치 | +25.8% vs GPT-4o | BigDocs [^8] |
| 포맷 선택 | Markdown이 추론 태스크에서 최적 포맷 | 81.2% (GPT-4) | Prompt Format [^9] |
| MD 인식 | LLM이 이미 Markdown을 이해하도록 훈련됨 | Spearman 양의 상관 | MDEval [^10] |
| 포맷 스펙트럼 | JSON·HTML·CSV·MD가 AI 친화 포맷 군 형성 | 생성 90%+ | StructEval [^11] |
| 구조 vs 텍스트 | 텍스트 75% 추출 가능해도 구조 복원은 13% | 구조 13% | PDFbench [^12] |
| 이해 정확도 역전 | MD 입력 시 추론 정확도가 JSON보다 높음 | 81.2% vs 73.9% | Prompt Format [^9] |
| 테이블 이해 | Markdown-KV가 11개 포맷 중 1위 | 60.7% vs JSON 50.8% | Improving Agents [^13] |
| 토큰 효율 (포맷) | Markdown이 JSON 대비 34-38% 토큰 절감 | -34~38% | Improving Agents [^14] |

> *표 13. 확인된 사실 종합.*



## 9. 참고문헌

[^1]: 국가인공지능전략위원회, "국가AI전략위, 문서 작성 체계 혁신으로 AI 활용 기반 강화한다," 보도자료, 2026.3.5. https://aikorea.go.kr/web/board/brdDetail.do?menu_cd=000012&num=363

[^2]: Zhang, J. et al., "OCR Hinders RAG: Evaluating the Cascading Impact of OCR on Retrieval-Augmented Generation," ICCV 2025, pp. 17443–17453. https://arxiv.org/abs/2412.02592

[^3]: Tan, J. et al., "HtmlRAG: HTML is Better Than Plain Text for Modeling Retrieved Knowledge in RAG Systems," WWW 2025. https://arxiv.org/abs/2411.02959

[^4]: Wang, D. et al., "DocLLM: A Layout-Aware Generative Language Model for Multimodal Document Understanding," ACL 2024, pp. 8529–8548. https://aclanthology.org/2024.acl-long.463/

[^5]: Sourati, Z. et al., "LAD-RAG: Layout-aware Dynamic RAG for Visually-Rich Document Understanding," arXiv:2510.07233, 2025. https://arxiv.org/abs/2510.07233

[^6]: Peng, X. et al., "UNIDOC-BENCH: A Unified Benchmark for Document-Centric Multimodal RAG," arXiv:2510.03663, 2025. https://arxiv.org/abs/2510.03663

[^7]: Bommarito, M. et al., "KL3M Tokenizers," arXiv:2503.17247, 2025 (ALEA Institute). https://arxiv.org/abs/2503.17247

[^8]: Rodriguez, J. et al., "BigDocs: An Open Dataset for Training Multimodal Models on Document and Code Tasks," ICLR 2025. https://arxiv.org/abs/2412.04626

[^9]: He, J. et al., "Does Prompt Formatting Have Any Impact on LLM Performance?" arXiv:2411.10541, 2024. https://arxiv.org/abs/2411.10541

[^10]: Li, Z. et al., "MDEval: Evaluating and Enhancing Markdown Awareness in Large Language Models," arXiv:2501.15000, 2025. https://arxiv.org/abs/2501.15000

[^11]: Yang, J. et al., "StructEval: Benchmarking LLMs' Capabilities to Generate Structural Outputs," arXiv:2505.20139, 2025 (Univ. of Waterloo). https://arxiv.org/abs/2505.20139

[^12]: Applied AI, "The State of PDF Parsing: What 800+ Documents and 7 Frontier LLMs Taught Us About Parser Selection," PDFbench, 2025. https://www.applied-ai.com/briefings/pdf-parsing-benchmark/

[^13]: Improving Agents, "Which Table Format Do LLMs Understand Best? (Results for 11 Formats)," 2025. https://www.improvingagents.com/blog/best-input-data-format-for-llms/

[^14]: Improving Agents, "Which Nested Data Format Do LLMs Understand Best? JSON vs. YAML vs. XML vs. Markdown," 2025. https://www.improvingagents.com/blog/best-nested-data-format/

[^15]: Skyvern, "How we cut token count by 11% and boosted success rate by 3.9% by using HTML instead of JSON in our LLM calls," 2024. https://blog.skyvern.com/how-we-cut-token-count-by-11-and-boosted-success-rate-by-3-9-by-using-html-instead-of-json-in-our-llm-calls/