1.marker-pdf中PdfConverter总控调度器学习；
1️⃣ override_map
用来自定义/替换某一类 Block 的实现
2️⃣ use_llm
是否启用 LLM 增强
3️⃣ default_processors（核心流水线）
这是整个 PDF 结构重建的“流水线”，“不抽表格”去掉 TableProcessor。
4️⃣ default_llm_service
默认用 Gemini的LLM模型。
marker-pdf只认文件路径；
file_input: Union[str, io.BytesIO]
➡️ BytesIO 会被写成临时 PDF 文件 ➡️ 下游组件只认文件路径
语义过滤（processors）各项说明：
default_processors: Tuple[BaseProcessor, ...] = (OrderProcessor, # ✅【必须】# 修正文档阅读顺序（多栏 / 流式）# 没它 = 文本顺序乱BlockRelabelProcessor, # ⚠️# 修正 block 类型（正文 / 标题 / 引用等）# 对结构化输出有帮助，纯 RAG 可选LineMergeProcessor, # ✅【必须】# 合并 PDF 强制换行# 不然一句话会被切成多行BlockquoteProcessor, # ⚠️# 识别引用块（论文、规范）# RAG 中通常价值一般CodeProcessor, # ⚠️# 识别代码块（API 文档 / 教程有用）# 普通文档可关DocumentTOCProcessor, # ❌（RAG 通常不需要）# 识别目录（Table of Contents）# TOC 本身几乎不参与问答EquationProcessor, # ⚠️# 识别数学公式（非 LLM）# 理工论文可能有用FootnoteProcessor, # ❌# 脚注（引用编号、来源）# 噪声密度极高IgnoreTextProcessor, # ✅【强烈推荐】# 忽略明确噪声文本（如 watermark）# 成本低、收益高LineNumbersProcessor, # ❌# 行号（法律 / 标准文档）# 对 RAG 基本是毒药ListProcessor, # ⚠️# 列表结构（条款、步骤）# 对 chunking 有帮助PageHeaderProcessor, # ✅【强烈推荐】# 页眉页脚（书名、页码）# 必须去掉SectionHeaderProcessor, # ✅【推荐】# 章节标题# 对 chunk 边界 & RAG 很重要TableProcessor, # ❌（除非你明确需要表格）# 规则表格解析# 会产生大量碎文本LLMTableProcessor, # ❌❌（RAG 默认关）# 用 LLM 解析表格# 成本高 + 噪声大LLMTableMergeProcessor, # ❌# 合并 LLM 表格# 对问答价值低LLMFormProcessor, # ❌# 表单识别（合同 / 表格）# 非问答核心内容TextProcessor, # ✅【必须】# 最终正文抽取# 没它就没文本LLMComplexRegionProcessor, # ❌# 复杂版面修复# 成本高，不稳定LLMImageDescriptionProcessor, # ❌# 图片转文字# RAG 中噪声极大LLMEquationProcessor, # ⚠️# LLM 公式理解# 理工文献可考虑LLMHandwritingProcessor, # ❌# 手写识别# RAG 极少用LLMMathBlockProcessor, # ⚠️# 数学块整体识别# 非数学场景建议关LLMSectionHeaderProcessor, # ⚠️# 用 LLM 修复标题# 可有可无LLMPageCorrectionProcessor, # ❌# LLM 修正文档结构# 性价比低ReferenceProcessor, # ❌【强烈建议关】# 参考文献# 对问答几乎无价值BlankPageProcessor, # ⚠️# 空页处理# 有无影响不大DebugProcessor, # ❌# 调试输出# 生产环境必关
)
2.PdfConverter的输入类型全是str问题；
目前，需要marker-pdf的过滤器；
marker 的核心设计目标是：
“所有组件都能通过 CLI + 配置文件 + JSON 反射加载”
➡️所以PdfConverter所有输入都是字符串str的形式，非常不利于开发
➡️ConfigParser是CLI → config 的官方映射表，能从这看到大多数的config类型
case "page_range":config["page_range"] = parse_range_str(v) # list[int]case "disable_multiprocessing":config["pdftext_workers"] = 1 # intcase "disable_image_extraction":config["extract_images"] = False # bool
3.PDF文档的RAG（检索增强生成）
大模型（LLM）本身有 3 个硬伤：
❌ 不知道你的私有数据
❌ 上下文长度有限
❌ 容易胡编（幻觉）
① 文档加载（你现在做的就是这一步）
② 文本切块（Chunking）
③ 向量化（Embedding）
④ 向量检索（Retrieval）
⑤ 生成回答（Generation）
与传统直接将PDF喂给LLM模型的区别
| 方式 | 问题 |
|---|---|
| 直接粘 PDF | ❌ 超长 / 乱 / 贵 |
| 微调模型 | ❌ 成本高 / 更新慢 |
| RAG | ✅ 灵活 / 实时 / 可控 |
4.Python：默认参数里，永远不要 new 对象
