做RAG项目的人十个里有八个把精力花在选Embedding模型、调向量库参数上真正上线后才发现召回质量差得离谱。后来排查一圈问题往往不是模型不行而是喂进去的数据本身就是一锅粥。尤其是一堆txt文档别说分层级了连编码都是乱的。这篇我想把RAG数据导入与解析这件事掰开揉碎讲清楚第一期先聚焦最基础也最关键的路径从txt到Markdown的通用文本与结构化解。这个系列适合三类人正在搭建RAG知识库但检索效果不理想的、手里攒了大量txt历史资料不知道怎么处理的、以及被文档解析折腾到怀疑人生的。不管你是技术负责人还是独立开发者这篇都值得停下来看完因为数据解析这步做对了后面整个RAG链路才会真正顺起来。1. RAG项目的真正瓶颈数据导入与解析1.1 RAG链路上最容易被低估的一环RAG的完整链路看起来不复杂采集文档、解析内容、切分块、做Embedding、存向量库、召回、交给大模型生成。很多人把注意力放在“召回”和“生成”上但实际上决定RAG上限的往往是第一步和第二步数据导入与解析。为什么这么说因为RAG的检索质量本质上取决于两件事一是向量检索能不能命中相关片段二是命中的片段能不能被大模型正确理解。这两件事都建立在同一个前提上——进入知识库的文本是干净、有结构、语义完整的。如果原始txt文件里充满了乱码、多余空行、无意义的页眉页脚或者一整本几十万字的小说被当成一个超长文本块塞进去那后面无论用多强的Embedding模型都救不回来。我见过不少RAG项目前期调研时demo做得花团锦簇一到真实数据就露馅。典型症状是用户问了一个文档里明明有的信息系统却答非所问。把文档拉出来一看要么是分块把一句话从中间截断了要么是表格被揉成了无法理解的纯文本。这些问题的根源都指向同一个地方数据导入与解析阶段没有做好结构化处理。1.2 为什么偏偏是“txt到Markdown”可能有人会问现在都什么年代了还有人在用txt喂RAG实际情况是大量企业级知识库里最不缺的就是txt。老系统导出的历史记录、产品说明书的纯文本版本、从PDF里复制出来的内容、各种日志和对话记录这些文件数量庞大格式混乱但内容价值极高。直接放弃它们不现实却又很难直接拿来用。txt的问题在于它是“纯文本流”没有任何结构信息。没有标题层级、没有列表语义、没有表格结构甚至连段落边界都可能因为换行符的差异而变得模糊。而RAG系统的解析器恰恰需要这些结构信号来做准确的分块和索引。Markdown恰好是解决这个问题的最优解。它是一种极轻量的标记语言用几个符号就能表达标题、列表、表格、代码块、引用等结构信息。相比起复杂的Word或PDF格式Markdown天然就是纯文本处理成本极低相比起纯txt它又多了一层“结构骨架”。换句话说Markdown是介于“完全无结构”和“强结构”之间的半结构化格式是RAG数据预处理里非常理想的中间载体。所以“从txt到Markdown”并不是一个简单的格式转换问题而是在为后续的分块、Embedding和检索打地基。这一步做好了知识库就成功了一大半。1.3 知识库的分类RAG知识库与结构知识库聊到这儿有必要把“RAG知识库”和“结构知识库”这两个概念拎出来区分一下因为很多人在建库时根本没有想清楚自己要的是什么。RAG知识库一般指的是把非结构化或半结构化文本向量化后存入向量数据库通过相似度检索来召回相关片段。它的强项是处理开放域问答、语义检索比如“这份手册里有没有提到超时重试的机制”这类问题。它的典型特征是以文本块为单位语义相关但上下文可能是碎片化的。结构知识库则是另一套体系典型代表是知识图谱或本体库。它存储的是实体、关系、属性比如“张三任职于某公司该公司位于某城市”。这类知识库非常适合多跳推理、关系查询例如“找出与项目A相关的所有供应商及其联系方式”。但它构建成本高需要做实体识别、关系抽取、对齐消歧往往需要大量人工介入。那Markdown在中间扮演什么角色它是通往结构知识库的桥梁。一份Markdown文档里的标题层级、列表结构、表格字段天然带有“主题、条目、属性”的信号。你可以先利用这些信号做好RAG的文本切片让向量检索效果拉满当文本量足够大、关系足够复杂时再基于Markdown结构化结果去做实体与关系的抽取升级成结构知识库。所以从txt到Markdown这一步不只是解决眼前RAG的检索质量问题也在为后续更复杂的知识体系建设铺路。2. 通用文本导入txt解析的完整流程与避坑2.1 编码检测第一道坎真做过txt导入的人都知道编码问题是第一个让人原地爆炸的坑。Windows下用记事本保存的txt默认可能是ANSI即GBK系列而Linux和macOS下大多是UTF-8。更麻烦的是有些文件带BOM头有些没有有些看似正常但里面混杂了各种历史遗留的转义字符。如果解析器一上来就按UTF-8读大概率得到一堆乱码或者读到第一个标题时发现前面黏着一个不可见的“”。我的经验是导入txt之前优先级最高的任务是做编码检测和归一化。Python里可以用charset-normalizer或chardet这类库来检测文件的实际编码然后统一转成UTF-8。检测逻辑很简单但非常管用from charset_normalizer import from_bytes def detect_and_read(path): raw open(path, rb).read() result from_bytes(raw).best() text str(result) return text转成UTF-8之后还要注意BOM的处理。UTF-8 BOM\ufeff一般不会让文本彻底乱掉但会在第一个字符前留下隐藏字符导致Markdown解析时第一个标题识别不出来。解决办法是读取后直接text text.lstrip(\ufeff)或者在写入时用encodingutf-8-sig去掉BOM。这一步没有技术难度但必须放在整个流程的最前面因为一旦编码错了后面的清洗、结构化、分块全是白做。2.2 文本清洗既要去噪也要克制编码归一化之后下一步是文本清洗。这里的核心原则是让文本变得可解析而不是让文本变得“好看”。很多人在清洗阶段用力过猛结果把文档里的语义结构也洗没了。常见的清洗操作包括以下这些去掉不可见控制字符比如\x00到\x1f范围内的字符这些通常来自老系统的导出。统一换行符把\r\n统一成\n避免Windows和Linux混用导致段落识别出错。处理全角半角混用中文文本里经常混着全角括号、逗号、冒号建议统一成半角尤其要注意标点前后不要粘连。去掉无意义空行和页眉页脚很多txt是从PDF或打印排版转换来的开头和结尾会有一堆“第X页 / 共X页”之类的噪音。合并被硬换行打断的段落有些txt每行都换行看起来像诗实际上是Word导出时的硬回车这种需要根据句末标点判断是否合并。但要注意清洗要有底线。标题、列表序号、表格分隔符这些内容绝对不能动。我曾经接手过一份被人为“清洁”过的txt所有以数字开头的行都被当成列表序号删掉了结果整份文档的层级结构全丢了重新标注比直接处理原始文件还麻烦。清洗的目的是去掉噪声而不是替文本做“语义判断”。2.3 分块策略到底怎么切才不伤语义RAG必须分块这是由Embedding模型的输入长度限制和检索精度共同决定的。但你如果不做结构化直接对txt按固定长度切片切出来的块往往语义不完整检索时要么漏掉关键信息要么召回的块跟前言不搭后语。分块的核心指标有两个块大小chunk size和重叠overlap。块大小通常以token数计中文场景下可以按字符数粗略估算1个token约等于1到2字。我自己常用的配置是块大小400到600 token重叠80到120 token。块太小语义上下文不足块太大向量化时信息被稀释检索精度下降。但相比参数更关键的是分块的“边界”选择。最优做法是优先让结构边界成为切分边界即先按Markdown的标题层级切出段落组再在段落组内部根据token长度做二次细分。比如一个二级标题下有三段文字总长超过了块大小限制就可以按段落边界切而不是硬从句子中间切断。如果多个小标题下的内容都很短也可以合并到一个块里保证主题完整性。纯txt的问题恰恰在于没有这些边界所以必须先在Markdown层把结构识别出来再谈分块。这也是为什么我一直强调“先转Markdown、再做分块”的顺序。跳过结构直接硬切后面检索出再多的“看似相关”片段也拼不出一段连贯的答案。3. 结构化升级从txt到Markdown的关键路径3.1 Markdown为什么是知识库的好地基Markdown作为一种半结构化格式最被低估的价值在于它把“文本”和“结构”写在了同一个文件里。标题层级直接表达了文档的树状结构列表和表格表达了并列关系和数据字段代码块和引用则把特殊内容从正文中区分出来。对RAG解析器来说这些结构信号就是天然的“路标”。一个能识别Markdown结构的解析器可以做到遇到#级别的标题时开启一个新的章节块遇到|开头的行时识别为表格并保留表头遇到列表时把列表项串成一个语义完整的条目组。对比一下纯txt里这些信息全部丢失解析器只能靠空行和缩进猜效果大打折扣。我做过一个对比测试同一批txt文档一批直接硬切分块灌进RAG另一批先做Markdown结构化再分块灌进去。在完全相同的Embedding和检索配置下后者的召回命中率top-5命中相关片段提高了约30%生成的答案也明显更完整。这就是结构化的价值不要在小看这几个井号和一个竖线。3.2 手动标记方案给txt打上结构骨架从txt到Markdown最简单可靠的方式是“半自动标记”先用规则和正则去识别txt里的潜在结构再打上Markdown标记。之所以叫半自动是因为真实文本的格式太乱了完全依靠自动识别会出错至少需要一个规则引擎再加一轮人工抽检。常见的识别规则包括标题识别匹配行首的“第一章”“第X节”“第X部分”“一、”“1.”这类模式根据数字层级映射到#、##、###。列表识别匹配行首的“1、”“1.”“-”“•”等模式替换为Markdown无序或有序列表。表格识别如果文本里出现了固定的分隔符比如|或连续的制表符尝试解析并转成Markdown表格语法。引用识别匹配行首的“”或“注”等模式替换成引用块。这套方案的优点是不需要为每个文件单独写逻辑规则一套通用缺点是需要针对具体语料调正则否则漏检率很高。调正则没有捷径就是拿一批样本反复跑把识别错误的case一条条捞出来补规则。3.3 工具链与自动化转换如果文档数量多纯手工标记不现实需要引入自动化工具链。Pandoc是命令行转换的通用选择但它更适合处理已经有一定格式的文档比如docx、latex转Markdown对于纯txtPandoc能做的事情有限因为它没法从纯文本里“猜”出结构。更实际的做法是写一个面向你的语料特点的转换脚本。下面这段逻辑是我在项目里用过的一个简化版本核心是按照规则把txt里的候选结构行替换成Markdown标记并且保留原始文本内容import re def txt_to_markdown(text): lines text.split(\n) md_lines [] for line in lines: stripped line.strip() # 识别一级标题第X章/部/部分 if re.match(r^第[一二三四五六七八九十百千0-9][章节部], stripped): md_lines.append(f# {stripped}) # 识别二级标题数字序号开头 elif re.match(r^[一二三四五六七八九十]、, stripped): md_lines.append(f## {stripped}) # 识别有序列表 elif re.match(r^\d[\.、)]\s*, stripped): md_lines.append(f- {stripped}) # 识别表格行制表符分隔 elif \t in stripped and re.match(r^[\w\u4e00-\u9fff]\t, stripped): cols stripped.split(\t) md_lines.append(| | .join(cols) |) else: md_lines.append(line) return \n.join(md_lines)这个脚本并不完美但作为起点足够了。每处理完一批文件我会随机抽出几篇用Markdown阅读器打开看一眼标题层级有没有乱、表格有没有被吞、列表项有没有被合并错。这种抽检非常重要规则再全也架不住实际数据里的意外格式。4. 实操演示一次导入解析的真实流程4.1 准备工作与目标定义说再多原理不如完整走一遍流程。我拿一个真实项目来举例手头有大约300份txt格式的产品培训资料内容包含章节标题、技术参数表格、FAQ问答列表以及一些常见问题的说明文字。目标是做一个能回答产品使用问题的RAG知识库。在动手之前我先明确几个目标第一所有txt统一转为UTF-8无BOM编码第二将文档中的章节层级转换为Markdown标题第三将参数表识别为Markdown表格第四把FAQ列表转成列表结构第五分块后入库。这五件事不搞清楚后面每走一步都会反复返工。4.2 清洗与转换脚本我写了一个组合脚本分三步处理。第一步做编码检测和归一化第二步做基础清洗第三步做Markdown转换。清洗这一步我只保留了“去掉控制字符、统一换行符、去掉页眉页脚”这三项。当时我特意没有做合并断行处理因为培训资料里很多地方是故意换行的比如列表项、参数说明强行合并反而会把结构搞坏。转换脚本则是先跑规则识别标题和列表然后再跑表格识别。几千字的文档跑不了几秒速度完全不是问题。整个300份文件处理完不到一分钟真正的耗时在抽检和修正规则上。我抽查了约30篇发现两个问题一个是表格识别时表头行和分隔行没区分清楚导致有的表格少了表头另一个是FAQ里有一些以“Q1”开头的行被当成了有序列表但实际应该保留“Q1”这个前缀信息。针对这两个问题我在规则里加了两个补丁表格识别时如果第一行符合“字段名 字段名 字段名”的连续模式就在下一行自动插入| --- | --- |作为表头分隔以“Q”开头的行则优先映射为引用块而不是列表。4.3 结果验证与分块合理性转换完成之后我写了一个简单脚本检查结果统计每篇Markdown文档的标题层级数量、表格数量、列表数量生成一个汇总报告。这份报告帮我快速定位规则没覆盖到的文档而不是一篇篇去翻。分块上我用了按标题层级优先的切法先按一级标题切大段再按二级标题切中段如果中段超长再按段落边界和句号边界细分。块大小设成500 token重叠100 token。切完之后跑了几条典型问题比如“产品A的最大工作温度是多少”系统能从对应的表格块里准确召回数据而不是答非所问。实操下来最大的体会是解析脚本不是一次写好的它是一个不断被语料“教育”的过程。每遇到一批新格式的txt就要补一批规则。与其追求一次搞出万能解析器不如针对你的具体语料做一套能快速迭代的规则库性价比高得多。5. 常见问题与排查技巧实录5.1 表格在Markdown里被切碎这是个高频问题。Markdown表格语法要求表头和分隔行必须连续但很多txt里的表格是不严格的比如表头下面有空行或者字段之间用多个空格而不是制表符。转换之后表格变成了散落的文本行RAG分块时还会把表头行单独切走导致检索到的是一个没有字段名的数字列。解决办法是两层第一转换规则里要识别表头模式并在表头下自动补上| --- |分隔行第二分块时如果检测到一个完整的表格块不要在外面硬切把它当作一个独立语义单元。表格本身就是强结构信息优先保证表头和数据行在同一块。5.2 数学公式解析失败RAG项目里如果文档涉及数学公式Markdown的公式语法$...$和$$...$$经常会在解析时被搞丢。原因是很多Markdown解析器把$当成普通字符而分块器又可能在公式中间切断导致LaTeX语法残缺。我的建议是如果公式不多直接在清洗阶段用代码块藏起来如果公式很多考虑先用专门工具比如Mathpix之类把公式转成LaTeX再放到Markdown的公式块里。同时要测试你的分块器会不会把$$之间的内容完整保留否则就加一条规则遇到$$开头的行把它和后续所有内容直到另一个$$合并成一个块。5.3 列表嵌套与层级污染txt转Markdown时无序列表和有序列表的嵌套很容易出问题。常见情况是原始文本里缩进表示层级但转换成Markdown后缩进没有被正确保留结果所有列表项都变成了同级失去了从属关系。排查方法是转换后用程序统计列表项的缩进深度再对照原始文档抽查。如果发现层级丢失就在转换规则里增加一个“缩进计数”的逻辑把每一级的缩进对应到Markdown嵌套列表的层级。不要依赖源文件里是否已经用Tab缩进很多时候源文件里根本没有任何缩进信号只有人工抽检才能发现。5.4 图片与附件路径失效很多txt里的插图在转换后变成了一堆乱码文本或者图片路径是相对路径搬到服务器上之后路径失效。RAG对这种图片没有直接的理解能力与其保留无效路径不如在清洗阶段就把图片引用转换成描述文字比如[图片产品拆解示意图]。如果图片本身是OCR出来的文章最好把OCR文本附在图片引用后面这样RAG能检索到图片对应的语义内容。相对路径问题则统一改成绝对路径或图床URL否则入库后图片彻底失联。5.5 问题速查表问题常见原因解决办法文本乱码编码检测失败先用charset-normalizer统一检测再转UTF-8标题前有隐藏字符未处理BOM读取后lstrip(\ufeff)表格被切碎表头缺失或分块硬切补表头分隔行表格作为独立块公式丢失解析器不识别$用代码块包住或专门工具转LaTeX列表层级丢失缩进信号缺失根据缩进补嵌套层级人工抽检图片失效路径和格式问题转描述文字或统一绝对路径这套速查表是长期实操攒下来的每一条背后都对应着一个出过问题的真实数据案例。碰到类似情况时优先按表里的思路排查能省下大量debug时间。做数据导入解析这件事看起来不如调模型“高级”但恰恰是它决定了RAG项目最终能不能跑通。我自己踩过最深的坑就是在项目初期跳过了解析直接让RAG吃原始txt结果上线后被业务同事连续问倒了一周。后来老老实实回到数据源头花了两天时间把文档全部转成规范的Markdown检索质量立刻上了一个台阶。所以如果你现在也在做RAG的知识库建设我强烈建议从数据导入这步开始先把txt到Markdown这个基本功练扎实后续的一切才有的谈。 
长河君 · 2026/10/27 15:40:24 · 阅读 1.2k RAG数据解析：从txt到Markdown，打好知识库地基
做RAG项目的人十个里有八个把精力花在选Embedding模型、调向量库参数上真正上线后才发现召回质量差得离谱。后来排查一圈问题往往不是模型不行而是喂进去的数据本身就是一锅粥。尤其是一堆txt文档别说分层级了连编码都是乱的。这篇我想把RAG数据导入与解析这件事掰开揉碎讲清楚第一期先聚焦最基础也最关键的路径从txt到Markdown的通用文本与结构化解。这个系列适合三类人正在搭建RAG知识库但检索效果不理想的、手里攒了大量txt历史资料不知道怎么处理的、以及被文档解析折腾到怀疑人生的。不管你是技术负责人还是独立开发者这篇都值得停下来看完因为数据解析这步做对了后面整个RAG链路才会真正顺起来。1. RAG项目的真正瓶颈数据导入与解析1.1 RAG链路上最容易被低估的一环RAG的完整链路看起来不复杂采集文档、解析内容、切分块、做Embedding、存向量库、召回、交给大模型生成。很多人把注意力放在“召回”和“生成”上但实际上决定RAG上限的往往是第一步和第二步数据导入与解析。为什么这么说因为RAG的检索质量本质上取决于两件事一是向量检索能不能命中相关片段二是命中的片段能不能被大模型正确理解。这两件事都建立在同一个前提上——进入知识库的文本是干净、有结构、语义完整的。如果原始txt文件里充满了乱码、多余空行、无意义的页眉页脚或者一整本几十万字的小说被当成一个超长文本块塞进去那后面无论用多强的Embedding模型都救不回来。我见过不少RAG项目前期调研时demo做得花团锦簇一到真实数据就露馅。典型症状是用户问了一个文档里明明有的信息系统却答非所问。把文档拉出来一看要么是分块把一句话从中间截断了要么是表格被揉成了无法理解的纯文本。这些问题的根源都指向同一个地方数据导入与解析阶段没有做好结构化处理。1.2 为什么偏偏是“txt到Markdown”可能有人会问现在都什么年代了还有人在用txt喂RAG实际情况是大量企业级知识库里最不缺的就是txt。老系统导出的历史记录、产品说明书的纯文本版本、从PDF里复制出来的内容、各种日志和对话记录这些文件数量庞大格式混乱但内容价值极高。直接放弃它们不现实却又很难直接拿来用。txt的问题在于它是“纯文本流”没有任何结构信息。没有标题层级、没有列表语义、没有表格结构甚至连段落边界都可能因为换行符的差异而变得模糊。而RAG系统的解析器恰恰需要这些结构信号来做准确的分块和索引。Markdown恰好是解决这个问题的最优解。它是一种极轻量的标记语言用几个符号就能表达标题、列表、表格、代码块、引用等结构信息。相比起复杂的Word或PDF格式Markdown天然就是纯文本处理成本极低相比起纯txt它又多了一层“结构骨架”。换句话说Markdown是介于“完全无结构”和“强结构”之间的半结构化格式是RAG数据预处理里非常理想的中间载体。所以“从txt到Markdown”并不是一个简单的格式转换问题而是在为后续的分块、Embedding和检索打地基。这一步做好了知识库就成功了一大半。1.3 知识库的分类RAG知识库与结构知识库聊到这儿有必要把“RAG知识库”和“结构知识库”这两个概念拎出来区分一下因为很多人在建库时根本没有想清楚自己要的是什么。RAG知识库一般指的是把非结构化或半结构化文本向量化后存入向量数据库通过相似度检索来召回相关片段。它的强项是处理开放域问答、语义检索比如“这份手册里有没有提到超时重试的机制”这类问题。它的典型特征是以文本块为单位语义相关但上下文可能是碎片化的。结构知识库则是另一套体系典型代表是知识图谱或本体库。它存储的是实体、关系、属性比如“张三任职于某公司该公司位于某城市”。这类知识库非常适合多跳推理、关系查询例如“找出与项目A相关的所有供应商及其联系方式”。但它构建成本高需要做实体识别、关系抽取、对齐消歧往往需要大量人工介入。那Markdown在中间扮演什么角色它是通往结构知识库的桥梁。一份Markdown文档里的标题层级、列表结构、表格字段天然带有“主题、条目、属性”的信号。你可以先利用这些信号做好RAG的文本切片让向量检索效果拉满当文本量足够大、关系足够复杂时再基于Markdown结构化结果去做实体与关系的抽取升级成结构知识库。所以从txt到Markdown这一步不只是解决眼前RAG的检索质量问题也在为后续更复杂的知识体系建设铺路。2. 通用文本导入txt解析的完整流程与避坑2.1 编码检测第一道坎真做过txt导入的人都知道编码问题是第一个让人原地爆炸的坑。Windows下用记事本保存的txt默认可能是ANSI即GBK系列而Linux和macOS下大多是UTF-8。更麻烦的是有些文件带BOM头有些没有有些看似正常但里面混杂了各种历史遗留的转义字符。如果解析器一上来就按UTF-8读大概率得到一堆乱码或者读到第一个标题时发现前面黏着一个不可见的“”。我的经验是导入txt之前优先级最高的任务是做编码检测和归一化。Python里可以用charset-normalizer或chardet这类库来检测文件的实际编码然后统一转成UTF-8。检测逻辑很简单但非常管用from charset_normalizer import from_bytes def detect_and_read(path): raw open(path, rb).read() result from_bytes(raw).best() text str(result) return text转成UTF-8之后还要注意BOM的处理。UTF-8 BOM\ufeff一般不会让文本彻底乱掉但会在第一个字符前留下隐藏字符导致Markdown解析时第一个标题识别不出来。解决办法是读取后直接text text.lstrip(\ufeff)或者在写入时用encodingutf-8-sig去掉BOM。这一步没有技术难度但必须放在整个流程的最前面因为一旦编码错了后面的清洗、结构化、分块全是白做。2.2 文本清洗既要去噪也要克制编码归一化之后下一步是文本清洗。这里的核心原则是让文本变得可解析而不是让文本变得“好看”。很多人在清洗阶段用力过猛结果把文档里的语义结构也洗没了。常见的清洗操作包括以下这些去掉不可见控制字符比如\x00到\x1f范围内的字符这些通常来自老系统的导出。统一换行符把\r\n统一成\n避免Windows和Linux混用导致段落识别出错。处理全角半角混用中文文本里经常混着全角括号、逗号、冒号建议统一成半角尤其要注意标点前后不要粘连。去掉无意义空行和页眉页脚很多txt是从PDF或打印排版转换来的开头和结尾会有一堆“第X页 / 共X页”之类的噪音。合并被硬换行打断的段落有些txt每行都换行看起来像诗实际上是Word导出时的硬回车这种需要根据句末标点判断是否合并。但要注意清洗要有底线。标题、列表序号、表格分隔符这些内容绝对不能动。我曾经接手过一份被人为“清洁”过的txt所有以数字开头的行都被当成列表序号删掉了结果整份文档的层级结构全丢了重新标注比直接处理原始文件还麻烦。清洗的目的是去掉噪声而不是替文本做“语义判断”。2.3 分块策略到底怎么切才不伤语义RAG必须分块这是由Embedding模型的输入长度限制和检索精度共同决定的。但你如果不做结构化直接对txt按固定长度切片切出来的块往往语义不完整检索时要么漏掉关键信息要么召回的块跟前言不搭后语。分块的核心指标有两个块大小chunk size和重叠overlap。块大小通常以token数计中文场景下可以按字符数粗略估算1个token约等于1到2字。我自己常用的配置是块大小400到600 token重叠80到120 token。块太小语义上下文不足块太大向量化时信息被稀释检索精度下降。但相比参数更关键的是分块的“边界”选择。最优做法是优先让结构边界成为切分边界即先按Markdown的标题层级切出段落组再在段落组内部根据token长度做二次细分。比如一个二级标题下有三段文字总长超过了块大小限制就可以按段落边界切而不是硬从句子中间切断。如果多个小标题下的内容都很短也可以合并到一个块里保证主题完整性。纯txt的问题恰恰在于没有这些边界所以必须先在Markdown层把结构识别出来再谈分块。这也是为什么我一直强调“先转Markdown、再做分块”的顺序。跳过结构直接硬切后面检索出再多的“看似相关”片段也拼不出一段连贯的答案。3. 结构化升级从txt到Markdown的关键路径3.1 Markdown为什么是知识库的好地基Markdown作为一种半结构化格式最被低估的价值在于它把“文本”和“结构”写在了同一个文件里。标题层级直接表达了文档的树状结构列表和表格表达了并列关系和数据字段代码块和引用则把特殊内容从正文中区分出来。对RAG解析器来说这些结构信号就是天然的“路标”。一个能识别Markdown结构的解析器可以做到遇到#级别的标题时开启一个新的章节块遇到|开头的行时识别为表格并保留表头遇到列表时把列表项串成一个语义完整的条目组。对比一下纯txt里这些信息全部丢失解析器只能靠空行和缩进猜效果大打折扣。我做过一个对比测试同一批txt文档一批直接硬切分块灌进RAG另一批先做Markdown结构化再分块灌进去。在完全相同的Embedding和检索配置下后者的召回命中率top-5命中相关片段提高了约30%生成的答案也明显更完整。这就是结构化的价值不要在小看这几个井号和一个竖线。3.2 手动标记方案给txt打上结构骨架从txt到Markdown最简单可靠的方式是“半自动标记”先用规则和正则去识别txt里的潜在结构再打上Markdown标记。之所以叫半自动是因为真实文本的格式太乱了完全依靠自动识别会出错至少需要一个规则引擎再加一轮人工抽检。常见的识别规则包括标题识别匹配行首的“第一章”“第X节”“第X部分”“一、”“1.”这类模式根据数字层级映射到#、##、###。列表识别匹配行首的“1、”“1.”“-”“•”等模式替换为Markdown无序或有序列表。表格识别如果文本里出现了固定的分隔符比如|或连续的制表符尝试解析并转成Markdown表格语法。引用识别匹配行首的“”或“注”等模式替换成引用块。这套方案的优点是不需要为每个文件单独写逻辑规则一套通用缺点是需要针对具体语料调正则否则漏检率很高。调正则没有捷径就是拿一批样本反复跑把识别错误的case一条条捞出来补规则。3.3 工具链与自动化转换如果文档数量多纯手工标记不现实需要引入自动化工具链。Pandoc是命令行转换的通用选择但它更适合处理已经有一定格式的文档比如docx、latex转Markdown对于纯txtPandoc能做的事情有限因为它没法从纯文本里“猜”出结构。更实际的做法是写一个面向你的语料特点的转换脚本。下面这段逻辑是我在项目里用过的一个简化版本核心是按照规则把txt里的候选结构行替换成Markdown标记并且保留原始文本内容import re def txt_to_markdown(text): lines text.split(\n) md_lines [] for line in lines: stripped line.strip() # 识别一级标题第X章/部/部分 if re.match(r^第[一二三四五六七八九十百千0-9][章节部], stripped): md_lines.append(f# {stripped}) # 识别二级标题数字序号开头 elif re.match(r^[一二三四五六七八九十]、, stripped): md_lines.append(f## {stripped}) # 识别有序列表 elif re.match(r^\d[\.、)]\s*, stripped): md_lines.append(f- {stripped}) # 识别表格行制表符分隔 elif \t in stripped and re.match(r^[\w\u4e00-\u9fff]\t, stripped): cols stripped.split(\t) md_lines.append(| | .join(cols) |) else: md_lines.append(line) return \n.join(md_lines)这个脚本并不完美但作为起点足够了。每处理完一批文件我会随机抽出几篇用Markdown阅读器打开看一眼标题层级有没有乱、表格有没有被吞、列表项有没有被合并错。这种抽检非常重要规则再全也架不住实际数据里的意外格式。4. 实操演示一次导入解析的真实流程4.1 准备工作与目标定义说再多原理不如完整走一遍流程。我拿一个真实项目来举例手头有大约300份txt格式的产品培训资料内容包含章节标题、技术参数表格、FAQ问答列表以及一些常见问题的说明文字。目标是做一个能回答产品使用问题的RAG知识库。在动手之前我先明确几个目标第一所有txt统一转为UTF-8无BOM编码第二将文档中的章节层级转换为Markdown标题第三将参数表识别为Markdown表格第四把FAQ列表转成列表结构第五分块后入库。这五件事不搞清楚后面每走一步都会反复返工。4.2 清洗与转换脚本我写了一个组合脚本分三步处理。第一步做编码检测和归一化第二步做基础清洗第三步做Markdown转换。清洗这一步我只保留了“去掉控制字符、统一换行符、去掉页眉页脚”这三项。当时我特意没有做合并断行处理因为培训资料里很多地方是故意换行的比如列表项、参数说明强行合并反而会把结构搞坏。转换脚本则是先跑规则识别标题和列表然后再跑表格识别。几千字的文档跑不了几秒速度完全不是问题。整个300份文件处理完不到一分钟真正的耗时在抽检和修正规则上。我抽查了约30篇发现两个问题一个是表格识别时表头行和分隔行没区分清楚导致有的表格少了表头另一个是FAQ里有一些以“Q1”开头的行被当成了有序列表但实际应该保留“Q1”这个前缀信息。针对这两个问题我在规则里加了两个补丁表格识别时如果第一行符合“字段名 字段名 字段名”的连续模式就在下一行自动插入| --- | --- |作为表头分隔以“Q”开头的行则优先映射为引用块而不是列表。4.3 结果验证与分块合理性转换完成之后我写了一个简单脚本检查结果统计每篇Markdown文档的标题层级数量、表格数量、列表数量生成一个汇总报告。这份报告帮我快速定位规则没覆盖到的文档而不是一篇篇去翻。分块上我用了按标题层级优先的切法先按一级标题切大段再按二级标题切中段如果中段超长再按段落边界和句号边界细分。块大小设成500 token重叠100 token。切完之后跑了几条典型问题比如“产品A的最大工作温度是多少”系统能从对应的表格块里准确召回数据而不是答非所问。实操下来最大的体会是解析脚本不是一次写好的它是一个不断被语料“教育”的过程。每遇到一批新格式的txt就要补一批规则。与其追求一次搞出万能解析器不如针对你的具体语料做一套能快速迭代的规则库性价比高得多。5. 常见问题与排查技巧实录5.1 表格在Markdown里被切碎这是个高频问题。Markdown表格语法要求表头和分隔行必须连续但很多txt里的表格是不严格的比如表头下面有空行或者字段之间用多个空格而不是制表符。转换之后表格变成了散落的文本行RAG分块时还会把表头行单独切走导致检索到的是一个没有字段名的数字列。解决办法是两层第一转换规则里要识别表头模式并在表头下自动补上| --- |分隔行第二分块时如果检测到一个完整的表格块不要在外面硬切把它当作一个独立语义单元。表格本身就是强结构信息优先保证表头和数据行在同一块。5.2 数学公式解析失败RAG项目里如果文档涉及数学公式Markdown的公式语法$...$和$$...$$经常会在解析时被搞丢。原因是很多Markdown解析器把$当成普通字符而分块器又可能在公式中间切断导致LaTeX语法残缺。我的建议是如果公式不多直接在清洗阶段用代码块藏起来如果公式很多考虑先用专门工具比如Mathpix之类把公式转成LaTeX再放到Markdown的公式块里。同时要测试你的分块器会不会把$$之间的内容完整保留否则就加一条规则遇到$$开头的行把它和后续所有内容直到另一个$$合并成一个块。5.3 列表嵌套与层级污染txt转Markdown时无序列表和有序列表的嵌套很容易出问题。常见情况是原始文本里缩进表示层级但转换成Markdown后缩进没有被正确保留结果所有列表项都变成了同级失去了从属关系。排查方法是转换后用程序统计列表项的缩进深度再对照原始文档抽查。如果发现层级丢失就在转换规则里增加一个“缩进计数”的逻辑把每一级的缩进对应到Markdown嵌套列表的层级。不要依赖源文件里是否已经用Tab缩进很多时候源文件里根本没有任何缩进信号只有人工抽检才能发现。5.4 图片与附件路径失效很多txt里的插图在转换后变成了一堆乱码文本或者图片路径是相对路径搬到服务器上之后路径失效。RAG对这种图片没有直接的理解能力与其保留无效路径不如在清洗阶段就把图片引用转换成描述文字比如[图片产品拆解示意图]。如果图片本身是OCR出来的文章最好把OCR文本附在图片引用后面这样RAG能检索到图片对应的语义内容。相对路径问题则统一改成绝对路径或图床URL否则入库后图片彻底失联。5.5 问题速查表问题常见原因解决办法文本乱码编码检测失败先用charset-normalizer统一检测再转UTF-8标题前有隐藏字符未处理BOM读取后lstrip(\ufeff)表格被切碎表头缺失或分块硬切补表头分隔行表格作为独立块公式丢失解析器不识别$用代码块包住或专门工具转LaTeX列表层级丢失缩进信号缺失根据缩进补嵌套层级人工抽检图片失效路径和格式问题转描述文字或统一绝对路径这套速查表是长期实操攒下来的每一条背后都对应着一个出过问题的真实数据案例。碰到类似情况时优先按表里的思路排查能省下大量debug时间。做数据导入解析这件事看起来不如调模型“高级”但恰恰是它决定了RAG项目最终能不能跑通。我自己踩过最深的坑就是在项目初期跳过了解析直接让RAG吃原始txt结果上线后被业务同事连续问倒了一周。后来老老实实回到数据源头花了两天时间把文档全部转成规范的Markdown检索质量立刻上了一个台阶。所以如果你现在也在做RAG的知识库建设我强烈建议从数据导入这步开始先把txt到Markdown这个基本功练扎实后续的一切才有的谈。