大模型读文件：11种格式解析与统一转换链实战

先说一个面试时的真实场景：某面试官让候选人写一段代码，把一份PDF里的表格数据提取出来。候选人上来就是pypdf一行读文本，结果表格横七竖八、数值全部错位，debug到天黑。问题的根源不是代码写得不好，而是人对“模型和文件格式之间的关系”理解错了。

大型语言模型通过API或开源模型推理时，本质上只吃文本token。所谓“能够理解的格式”，是指不经过额外转化、或仅需少量结构化处理就能被模型直接识别的文件形态。网上聊这个主题的文章很多，但大多停留在罗列扩展名。这周我整理了11种实际项目里真正用得上的格式，顺带把转换链、编码问题、超长输入和幻觉处理一并讲了，看完你至少能少踩一半的坑。

1. 为什么模型读取文件有“偏好”：路径依赖与标记语言基础

很多刚接触大模型应用开发的人会问：模型不是号称什么都懂吗，为什么不能直接塞一个二进制文件进去？这里有个基础概念必须先讲清楚——大型语言模型的输入窗口，本质上是token序列。模型能“理解”的，是能被分词器切分、映射为向量、进入注意力机制计算的字符流。一切文件格式最终都要落到这个约束上。

对于文本类文件，例如.txt和.csv，解析成本极低，文件内容几乎能无损映射到token上。对于二进制类文件，例如.docx、.pdf，模型本身并不直接读取文件内部的XML结构或字体渲染信息，而是依赖外层工具先抽取出可用的文本流，再交给模型。所以这里会产生一个分支：

• 原生可读格式：.txt、.csv、.json、.md、.html、.xml、.yaml、.log、代码文件，这类文件本身就是字符编码，直接读、直接喂。
• 需转换才能读的格式：.pdf、.docx、.xlsx，这类文件是压缩包或页面描述语言，必须先用解析工具转成文本或表格，才能进入模型的上下文窗口。

这个分类的意义不只是技术洁癖。项目里有一类很典型的返工：给一份PDF做知识库问答，不去先OCR或做版面分析，直接把pypdf抽出来的文本丢给模型，结果所有表格、页眉页脚、双栏排版全部揉成一条线，检索召回率惨不忍睹。模型对格式的理解上限，取决于你对格式底层结构的理解。

所谓“标记语言基础”，指的是一种思维转变：任何结构化格式在模型眼中，都是带有显式或隐式标记的token序列。.json有大括号和键名，.xml有标签对，.html有DOM层级，.md有井号和星号。这些标记不仅能帮模型区分“这是表格”“这是标题”“这是链接”，还能在意图识别、信息抽取时提供更强的位置信号。同一句话放在JSON值里和放在HTML的<h1>里，模型给出的解析结果差异非常大。

理解了这层路径依赖，才谈得上选型。下面这11种格式，我按“从最纯文本到最接近二进制”的顺序拆开讲，每种格式都带上读取逻辑、适用场景和我在实际项目里踩过的坑。

1.1 从纯文本到结构化文本：模型解析成本的分层

按模型接收成本，可以把格式分成三层：

1. 零成本层：.txt、.log，读取无阻碍，模型直接可理解。
2. 轻结构化层：.csv、.json、.yaml、.xml、.md，需要少量解析或可直接按原始文本传入，模型维持格式语义。
3. 重结构化层：.html、.pdf、.docx、.xlsx，依赖外部分析器的质量，抽取结果直接影响模型准确性。

把这层关系放在选型表里会清晰很多：

这张表值得存一份。每次看到有人抱怨“模型怎么这么笨，这个PDF都读不明白”，十有八九是先检查一下解析层，而不是怪模型。

2. 核心11种格式逐个拆解：读取逻辑、转换工具与常见坑

2.1 TXT：最稳妥也最容易被忽略的“万能格式”

.txt几乎没有解析成本，直接读取，直接映射。适合放纯文本语料、知识库问答的基础文档、临时笔记。这个格式最大的坑不在读取，在于编码。中文环境下最常见的问题是GBK和UTF-8混用。文件头不带BOM时，chardet偶尔也会判错。我的做法是读取时强制指定参数，遇到乱码就直接抛错，让用户去改源文件，而不是让模型读进一堆乱码还硬算。

在实际的知识库项目中，我通常会把.txt作为数据清洗的目标格式。无论是从PDF抽出来的文本，还是从网页正文提取的结果，统一落成.txt再做清洗，能避开后续一堆格式兼容问题。模型对.txt的解析非常稳定，不会出现标签泄漏、字段错位这类状态问题。

一个容易忽略的细节是行尾符号。Windows的\r\n和Linux的\n混在一起时，RAG分段工具容易把一段话切出莫名其妙的空行。建议统一走一遍行尾转换，因为换行符号的影响远远不止显示，它会导致后续按段落切片的逻辑彻底错乱。

2.2 CSV：让模型读慢一点，反而更准

.csv是结构化表格里模型比较友好的一种，因为它的每一行就是一个完整记录，分隔符给了模型天然的边界。模型读CSV时，更像是在读一行一行的自然语言，而不是二进制展开的表格块。适合问答机器人读取小规模业务数据，比如商品清单、人员名单、设备台账。

CSV在真实项目里有两个高频坑：

第一个坑是单元格内含逗号和换行。很多导出工具没有做正确的引号转义，导致一行数据被拆成两行，模型读到的记录错位。我的经验是先做一次行级校验，通过字段数量一致性检查排除异常行，再决定是跳过还是修补。

第二个坑是编码。CSV文件在中文场景中经常以GBK保存，Excel默认导出行为会在部分历史版本中保留GBK。读取时统一用utf-8-sig或gb18030，不要直接用utf-8去读，这样安全很多。

在给模型喂CSV之前，我还会做一个操作：把CSV转成结构化的文本块。比如把原文件按“前十行原始CSV+后续每行的自然语言描述”的方式拼prompt，模型对字段边界的感知会大幅提升。直接丢一个几百行的原始CSV进去，模型在超长上下文里的注意力衰减很明显，字段越多、行数越多，召回越差。这不是模型笨，是把任务放进了它不擅长的区域。

2.3 JSON：结构即语义，但别把整个JSON硬塞给模型

.json是语言模型最舒服的格式之一，键名本身就是语义提示。模型能通过键值对的配对关系，推断出实体、关系甚至意图。比如{"product_name": "无线鼠标", "price": 49.9}，模型看到键名product_name就知道这个词是产品名，不需要额外的字段说明。

处理JSON的第一原则：能精简就精简。模型吃的是token，而嵌套JSON会产生大量{}、[]、缩进空格和冗余键名。若原始数据有几十个字段，但业务只需要五六个，之前我会先抽取，做完能省近一半token。

第二原则：深嵌套要拍平。超深层嵌套的JSON直接喂给模型，不是解析不了，而是让模型在提取信息时分心。实际项目里，我会将一个多层嵌套的对象展开成带路径的扁平键，比如user.address.city，每一行一个字段。这样模型提取信息时能看到清晰的层级上下文，同时注意力能聚焦到具体那个键上。

有人习惯直接让模型输出JSON，再二次解析，这本身没有问题，但要注意模型偶尔会输出注释（虽然JSON标准不允许）或尾逗号。用容错性高的JSON解析器，同时给模型明确的输出schema示例，比事后正则修复省心得多。

2.4 XML：结构完整但token成本高，适合小文档

.xml和.json类似，也是自描述结构。不同点是XML的字段信息藏在标签对里，标签重复出现，导致大量token消耗在结构噪音上。模型能理解XML，但理解成本偏高。

适合使用XML的场景是小规模配置文件、跨系统报文、老系统的数据对接。处理XML时，我第一步会做标签压缩：长标签名改成短别名，比如<organization_member_details>改成<omd>，读取时通过映射表还原。这么做之后，token消耗能下降30%左右，模型提取准确率也不受影响。

另一个坑是命名空间。XML里的xmlns定义会带来大量重复前缀，在喂给模型前尽量剥掉。保留核心业务标签就够了，程序中降本增效最见效的一招就是清洗标签。

2.5 Markdown：RAG知识库最推荐的格式

.md可以说是为语言模型量身定做的最优文档格式。它天然保留了标题层级、列表结构、表格语法、代码块、链接、引用等语义信息。这些信息对模型理解文档上下文帮助极大。使用RAG做知识库时，我会把尽量多的原始资料转成规范Markdown，转换之后切片再嵌入选取，效果通常远好于直接处理HTML或PDF。

Markdown的标题层级非常重要。很多人在把网页正文存成Markdown时，把原本的<h1>、<h2>全拍平了。拍平之后模型对文档结构的感知就会降级。正确做法是按层级保留井号，让模型一眼看出当前段落位于整篇文章的哪个部分。切片时也按标题层级做父子联动，检索的时候能带出更完整的上下文。

有些细节容易被忽略：表格语法|和---如果格式不规范，模型可能会误读成普通文本。代码块里的语言标记要不要留？我建议保留。模型在读代码块时，语言标记能激活对应的代码理解先验，提升提取准确率。

2.6 YAML：配置友好，但缩进错误是隐性地雷

.yaml是配置文件里最贴近自然语言的格式。冒号加缩进的可读性，比JSON舒服很多。模型对YAML的解析准确率也不错，因为键值对结构清晰。

但YAML对缩进极其敏感，而且错误往往是静默的。某开发者配置过一次多层级列表，因为缩进多了一个空格，解析出来变成了一个带空格的字符串键，排错排了半天。因此实际操作中我不建议直接让模型去解析复杂YAML再输出结果。更稳妥的做法是先转换成JSON结构，再交给模型。让模型理解YAML可以，但让它在YAML语法上做严格推理，本质是浪费它的能力。

2.7 HTML：标签是定位符，也是噪音源

.html是模型常见输入之一，但问题也很典型：标签太吵。一个网页的原始HTML中，正文文本可能只占30%，其余全是style、script、class和>