先说一个面试时的真实场景某面试官让候选人写一段代码把一份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 从纯文本到结构化文本模型解析成本的分层按模型接收成本可以把格式分成三层零成本层.txt、.log读取无阻碍模型直接可理解。轻结构化层.csv、.json、.yaml、.xml、.md需要少量解析或可直接按原始文本传入模型维持格式语义。重结构化层.html、.pdf、.docx、.xlsx依赖外部分析器的质量抽取结果直接影响模型准确性。把这层关系放在选型表里会清晰很多格式原生 token 化解析复杂度典型使用原因常见失误.txt是无日记、笔记、纯文本语料无编码检测容易乱码.csv是低表格数据、RAG切分源分隔符错位、多行单元格断裂.json是低API返回、配置数据深层嵌套截断.md是低文档、README、知识库井号层级信息被丢弃.yaml是低配置、结构化配置缩进错误后的静默失败.xml是中配置文件、跨系统数据标签冗余占token.html是中网页正文提取标签噪声干扰检索.log是中错误日志、行为日志格式不统一导致解析失败.pdf否中高官方文档、合同、论文双栏/表格识别失败.docx否中高Office文档、报告图片无法读取、样式噪声.xlsx否中表格、报表、业务数据合并单元格和多Sheet陷阱这张表值得存一份。每次看到有人抱怨“模型怎么这么笨这个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 MarkdownRAG知识库最推荐的格式.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和>