지식 데이터 문서 포맷에 따라 AI 파이프라인 구축시 미치는 비용 분석과 전략
How Machine-Readable Document Formats Affect AI Pipeline Performance and Cost
연구 배경
2026년 3월 5일, 국가인공지능전략위원회는 정책 문서를 마크다운(.md) 형식으로 전환하여 작성·관리·공개한다고 발표하였다 1.이 정책적 전환은 HWP 중심의 시각적 편집 문서가 AI 학습·활용에 적합하지 않다는 문제의식에서 출발한다.
본 연구노트는 이 전환의 기술적 근거를 벤치마크 문헌 분석을 통해 수립하고, AI 시대의 문서 데이터 프로세싱 전략에 필요한 실증 기반(evidence base)을 구축한다.
목차
- 왜 문서 포맷이 AI 성능을 결정하는가
- 인용 논문의 저명성 및 신뢰도
- 비정형 문서의 비용: OCR이 만드는 성능 천장
- 구조화된 포맷의 이점: 검색 정확도와 추론 품질
- 포맷이 결정하는 토큰 비용: 기업 규모의 체감치
- LLM이 인식하는 포맷의 스펙트럼
- 종합: 확인된 사실과 미해결 과제
- 다음 연구를 위한 방향
- 참고문헌
1. 왜 문서 포맷이 AI 성능을 결정하는가
AI 시스템, 특히 검색 증강 생성(RAG) 파이프라인에서 외부 문서는 핵심 입력 자원이다. 같은 정보라도 어떤 형태로 투입하느냐에 따라 검색 정확도, 추론 품질, 토큰 비용이 극적으로 달라진다.
%%{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 1314 | 독립 벤치마크 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 쌍
%%{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 데이터셋에서 검증하였다.
%%{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의 처리 수치. "텍스트를 뽑았으니 괜찮다"는 가정이 위험한 이유.
%%{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. 참고문헌
국가인공지능전략위원회, "국가AI전략위, 문서 작성 체계 혁신으로 AI 활용 기반 강화한다," 보도자료, 2026.3.5. https://aikorea.go.kr/web/board/brdDetail.do?menu_cd=000012&num=363 ↩ ↩
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 ↩ ↩ ↩ ↩
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 ↩ ↩ ↩
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/ ↩ ↩ ↩
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 ↩ ↩ ↩
Peng, X. et al., "UNIDOC-BENCH: A Unified Benchmark for Document-Centric Multimodal RAG," arXiv:2510.03663, 2025. https://arxiv.org/abs/2510.03663 ↩ ↩ ↩
Bommarito, M. et al., "KL3M Tokenizers," arXiv:2503.17247, 2025 (ALEA Institute). https://arxiv.org/abs/2503.17247 ↩ ↩ ↩ ↩
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 ↩ ↩ ↩
He, J. et al., "Does Prompt Formatting Have Any Impact on LLM Performance?" arXiv:2411.10541, 2024. https://arxiv.org/abs/2411.10541 ↩ ↩ ↩ ↩
Li, Z. et al., "MDEval: Evaluating and Enhancing Markdown Awareness in Large Language Models," arXiv:2501.15000, 2025. https://arxiv.org/abs/2501.15000 ↩ ↩ ↩
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 ↩ ↩ ↩ ↩
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/ ↩ ↩ ↩ ↩
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/ ↩ ↩ ↩
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/ ↩ ↩ ↩ ↩ ↩ ↩
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/ ↩
댓글 없음