marker-pdf中PdfConverter总控调度器学习；PdfConverter的输入类型全是str问题；PDF文档的RAG（检索增强生成）；Python：默认参数里，永远不要 new 对象；

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                  # int

case "disable_image_extraction":
    config["extract_images"] = False               # bool

3.PDF文档的RAG（检索增强生成）
大模型（LLM）本身有 3 个硬伤：
❌ 不知道你的私有数据
❌ 上下文长度有限
❌ 容易胡编（幻觉）
① 文档加载（你现在做的就是这一步）
② 文本切块（Chunking）
③ 向量化（Embedding）
④ 向量检索（Retrieval）
⑤ 生成回答（Generation）
与传统直接将PDF喂给LLM模型的区别

方式	问题
直接粘 PDF	❌ 超长 / 乱 / 贵
微调模型	❌ 成本高 / 更新慢
RAG	✅ 灵活 / 实时 / 可控

4.Python：默认参数里，永远不要 new 对象