前阵子帮朋友排查一个RAG项目他的知识库用的是现成的RAG框架向量库、召回、生成环节看起来都没毛病但检索结果就是又碎又乱。查了两天问题不在模型也不在框架而是卡在最前面那个最不起眼的步骤数据导入与解析。几十个txt文件被原封不动丢进切块器目录、页眉、网页复制下来的广告全成了向量检索自然乱成一团。这个场景太典型了。RAG这条链路里数据入口最容易被当成“不是技术活”但它恰恰决定了后续切块、向量化、召回的上限。这篇先写系列第一篇聚焦通用文本怎么把txt这类最“没有结构”的文本处理干净并转成Markdown这种带结构的中间格式。对象是正在搭RAG知识库、或者被召回效果折磨的开发者。不管你在Mac还是Windows上搭环境数据准备这一关绕不开看完你至少能把通用文本解析这个大头老老实实走通。1. RAG项目里最容易翻车的不是模型而是数据入口1.1 RAG整条链路里数据准备决定了什么先说清楚RAG的完整链路数据导入 - 文档解析 - 文本切块 - 向量化 - 语义检索 - 生成回答。很多人用现成RAG框架时只管调接口把文件往里一丢就完事忽略了中间每个环节的质量。结果就是检索出来的top-k结果十个有八个是废话大模型再聪明也只能在垃圾上生成答案。这类问题有个通用说法叫“Garbage ingarbage out”在RAG里体现得格外明显。数据准备这一步决定了三件事第一一句话会不会被拦腰截断。txt里的换行经常是视觉换行不是语义换行直接按换行切块会让“苹果是一种水果富含维生素C”变成两个孤立碎片。第二一个概念能不能被正确归属到所属章节。没有结构信息时向量检索分不清“Windows安装”和“Windows常见问题”到底谁是谁。第三无效字符会不会污染语义。页眉、页脚、目录页码、版权声明这些内容一旦进入向量库检索时它们会大量命中挤占有效的top-k位置。换句话说数据入口的质量不是“锦上添花”而是“决定天花板”。模型再强框架再成熟解析这关糊弄过去后面全部白搭。1.2 三类最典型的“脏txt”场景我在实际项目里见过最多的脏txt基本逃不出下面三类你可以对照自己的数据源看看有没有中招。场景A从各种网站上扒下来的小说、教程、电子书txt。这类文件里通常带着目录、章节标题、作者简介、更新公告甚至还有“本小说来自某某论坛请支持正版”这种广告行。它们的问题不是乱而是“半结构”——明明有章节结构但没有统一格式目录和正文挤在一起直接切块会把目录里的章节名变成高权重向量导致检索时频频命中目录而不是正文。场景BPDF转txt导出的文件。这类txt最坑的地方在于PDF里每一页的页眉页脚、页码、“第X页共X页”全部保留英文单词还会在行尾被断成两半比如“informa- tion”。最麻烦的是PDF表格转出来后变成一堆空格和制表符看起来对齐实际上在Markdown里根本没法用。场景C日志文件、老系统导出数据、爬虫抓取的网页正文。这类文件里混着时间戳、特殊分隔符、HTTP状态码、重复的导航文案。如果解析时不做清洗这些噪音片段会被当成正常文本向量化检索效果可想而知。所以通用文本解析的第一步不是你急着转Markdown而是先搞清楚你的txt里到底有什么。看一眼原始文件长什么样比自己瞎猜结构重要得多。2. txt不是一种格式编码、脏字符与伪结构的基础排查2.1 编码问题从“锟斤拷”说起txt看起来是个文件后缀实际上它根本不是一种“格式”而是一坨没有任何结构信息的纯字节流。处理txt最先遇到的坑是编码。中文环境里最常见的三套编码是UTF-8、GBK、GB18030。现代RAG框架默认按UTF-8读取但老系统、Windows记事本另存的txt经常是GBK或GB18030。你用UTF-8去解GBK文件中文就变成“锟斤拷烫烫烫”这种经典乱码。乱码的根源不复杂同一个字节序列用不同编码规则解码出来的字符完全不同。GBK里一个汉字占两个字节UTF-8里一个汉字占三个字节错位之后原本“知识库”三个字就可能变成一堆符号替代符UFFFD。这种文本进入向量化环节不仅浪费Token还会产生完全无意义的向量。检测编码的方法有很多命令行优先在Linux或Mac下直接执行file -i 文件名.txt大部分情况下能直接告诉你编码类型。想更精确就用Python的chardet库它会基于统计学给出可能的编码候选。VS Code用户更简单打开txt文件右下角会显示当前编码点击就能切换和重新保存。拿到编码后务必统一转成UTF-8这是后续一切解析的前提。2.2 换行符、BOM与控制字符看不见的搅局者编码之外还有三类看不见的字符在暗中搞事。第一类是换行符。Windows用CRLF\r\nUnix/Linux/Mac用LF\n老版Mac用CR\r。如果你把不同系统的txt拼接在一起或批量合并文件里可能混着两种甚至三种换行。切块时如果对这些换行一视同仁逻辑上没错但有些解析器会把\r当成普通字符残留在切块结果里看起来就是每段末尾多了一个奇怪的符号。更麻烦的是Markdown解析器对\r的处理标准不一可能导致渲染出现异常空行。第二类是BOM头。Windows记事本保存UTF-8文件时经常加一个BOM字节顺序标记对应字节序列是EF BB BF在Python里读取后会变成字符串开头的\ufeff。这个看不见的字符一旦进入切块器会被算成一个独立Token。排查方法可以用Hexdumphexdump -C 文件名.txt | head -n 1看到开头是ef bb bf就说明有BOM。第三类是控制字符。日志文件里经常夹着\x00、\x1a这类不可见控制字符它们不会在编辑器里正常显示但会在解析时制造异常边界。处理思路也很简单只保留正常文本字符把ASCII控制字符剔除掉。2.3 伪结构txt里没有真正的“结构”txt最大的问题不是脏而是“没有结构”。所谓章节、层级、列表在txt里全靠视觉惯例表达缩进、数字编号、下划线分隔线。这些惯例在不同文件里千奇百怪程序无法直接识别。举个典型的例子看为什么不能简单粗暴地判断标题。假设有一行文本是“3. 根据上述内容总结如下这是一个非常长的段落里面讲了很多东西……”。它看起来像是有个数字编号“3.”但你把它当成标题就会出大问题。真实项目里必须设计规则标题行通常很短、有编号模式、后面多半跟一个空行或正文段落。而正文里的“3.”只是某个句子的开头。所以解析txt的核心思路是先清干净脏数据再靠规则把“视觉结构”还原成“语义结构”。这个过程不可能100%完美但足够把大部分文档处理得很像样。后面我会给出具体代码。2.4 清洗操作清单把上面说的整理成一张可执行的检查清单每次处理txt前过一遍问题类型典型表现处理方式编码错误中文变“锟斤拷”或乱码检测后统一转UTF-8BOM残留切块首字符异常删除\ufeff换行符混杂段落间多出符号或空行全部统一为\n控制字符显示为乱码方块正则过滤只保留可见字符全角符号检索不准确NFKC规范化转为半角连续空行切块产生空白碎片压缩为单个空行页眉页脚/广告污染向量库用规则或黑名单过滤表格看起来简单但每一条都是真实项目的血泪。尤其全角符号很多中文文档里的括号、逗号、空格都是全角你不做NFKC规范化切出来的文本里就会混着两种看似相同但字节不同的符号导致检索匹配率下降。3. 为什么Markdown适合当RAG的“中间层”3.1 Markdown的语义标签就是切块边界处理完txt的脏数据后下一步不是直接切块而是先转成一种“中间格式”。我强烈推荐Markdown因为它天生就是为内容分块设计的。井号标题#、##表示层级列表项表示并列内容表格表示结构化数据代码块用反引号包裹引用块用大于号开头粗体和斜体补充强调信息。这些东西看上去只是排版标记实际上每一类都对应一种语义边界。切块时Markdown的标题层级可以直接复用一个二级标题下的内容天然是一个候选块三级标题则可以作为子块。代码块、表格、公式单独成块避免被普通段落切碎。相比纯txt那种只能靠空白和换行猜测段落Markdown给了切块器一套明确的规则让整个RAG链路的安全感提升一大截。数学公式也要提一句很多人关心Markdown数学公式插件其实在RAG解析阶段你不需要一个“渲染插件”你只需要保证LaTeX语法的完整保留。比如$f(x) x^2$行内公式和$$Emc^2$$块级公式只要切块时不把$$从中间断开后续检索和展示都能正常工作。3.2 为什么不用HTML、JSON或纯txt中间格式不是越复杂越好关键看“解析成本”和“下游适配”。我把几种格式放在一起对比过格式人读性结构化程度解析成本RAG适配度txt一般无低差需大量规则Markdown好半结构化中好切块边界明确HTML差噪音多结构化高标签冗余中需深度清洗JSON差结构化中适合元数据不适合正文HTML其实也能表达结构但网页文本里标签、class、style、脚本残留实在太多解析它需要额外做一层噪声过滤。JSON作为正文格式更是灾难你会被嵌套和引号转义搞疯阅读性极差。有些项目纠结“wiki格式还是Markdown”我的观点是只要能形成统一的标准两者都可以但Markdown生态更统一各种解析器、渲染器、向量数据库插件支持最广踩坑最少。3.3 现成工具摸底pandoc、markdownify与本地拆解处理Markdown转换我常用的工具链包括pandoc、markdownify、trafilatura。pandoc是格式转换的瑞士军刀能把txt、HTML、docx、epub等各种格式转成Markdown功能极其强大。markdownify是Python库专门处理HTML转Markdown写爬虫管线时很顺手。trafilatura主攻网页正文提取能自动滤掉导航栏和页脚适合RAG语料采集。但注意这些工具对已经“有格式”的文件效果很好处理txt这种裸文本时能力有限。pandoc转txt时往往只做简单包裹不会帮你识别“第一章”这种伪结构。所以如果你想完全省力还有一条路用语言模型做结构化解析。让LLM直接把整篇txt按内容重排成Markdown效果在复杂文档上确实好但成本高、速度慢、有幻觉风险。我的建议是先上规则脚本规则搞不定的边缘case再让LLM补刀。这也是为什么我坚持要你掌握下一节的手写转换流程——不是为了炫技而是它能让你在“规则”和“模型”之间自由切换。4. 不依赖轮子手写txt到Markdown的转换流程4.1 整体流程设计手写转换器听起来工程量大实际只要拆成五步就很清晰读原始字节 - 检测编码 - 解码与清洗 - 行级分类与结构推断 - 输出Markdown。关键是每步只做一件事避免在一步里塞进太多逻辑。我先给一个整体的架构思路清洗完的文本按行拆开程序逐行判断它是什么类型是标题列表引用表格还是普通段落。判断完成后再重构为Markdown字符串。这个“先分类、后输出”的好处是你可以随时调整单行的识别规则不会破坏整条链路。很多人可能会说“这类活我直接用大模型几行提示词不就行了”大模型确实可以但规则脚本在批量处理时更稳定、更便宜而且可解释。解析出问题时你能一眼看出是哪条正则误判而不是去翻模型输出排查为什么把“3. 一个普通句子”当成了标题。我个人建议的搭配是规则为主、模型为辅。4.2 编码检测与文本清洗代码第一段代码解决“读进来”的问题。以下Python函数读取txt文件自动检测编码清洗BOM、换行符和控制字符并返回UTF-8的统一文本import re import unicodedata import chardet def read_txt_clean(path): with open(path, rb) as f: raw f.read() # 1. 编码检测 encoding chardet.detect(raw)[encoding] if encoding is None: encoding utf-8 # 2. 解码errorsreplace能保证解码失败时不中断 text raw.decode(encoding, errorsreplace) # 3. 去BOM text text.replace(\ufeff, ) # 4. 统一换行符 text text.replace(\r\n, \n).replace(\r, \n) # 5. NFKC规范化全角字母、数字、空格转半角 text unicodedata.normalize(NFKC, text) # 6. 过滤控制字符保留\n和\t text .join(ch for ch in text if ch \n or ch \t or ord(ch) 31) return text, encoding这里有个细节值得多说一句errorsreplace。如果你直接使用text.decode(encoding)遇到无法解码的字节会直接抛异常整个文件挂掉。使用errorsreplace后那些异常字节变成符号替代符UFFFD虽然看着丑但不会中断流程。真正重要的文本内容仍然能保留大部分后续交给规则清洗再优化。4.3 结构推断规则怎么把“视觉结构”还原成“语义结构”第二步是识别每一行的类型。我对常见txt总结了几个高命中率模式def classify_line(line): s line.strip() # 章节标题第X章 / 第X节 / 第X篇 if re.match(r^第[0-9一二三四五六七八九十百][章节篇部], s): return heading # 数字编号标题1. 简介 / 1、背景 / 2.1 方法 if re.match(r^\d{1,3}([.、\s])\s*\S, s) and len(s) 50: return heading # 无序列表 if re.match(r^[-*•]\s, s): return bullet_list # 有序列表 if re.match(r^\d{1,3}[.)、]\s, s): return ordered_list # 引用块 if re.match(r^\s?, s): return quote # 表格行至少包含一个竖线分隔符 if s.count(|) 2: return table_row return paragraph注意几个设计细节。标题限制在50字符以内是为了避免把一大段以数字开头的正文误判为标题“第X章”的正则优先级最高因为它模式足够强列表识别放在标题之后否则“1. 第一章内容”可能会先被当成标题再看前缀才识别为有序列表那就错了。表格识别的逻辑比较粗糙但仍很实用。txt里真正规整的表格不多更多是用制表符或竖线粘在一起的伪表格。你可以在此基础上加入“同行竖线数量是否一致”的判断能进一步降低误判率。这套规则不完美没事。它最大的优势是“可解释”“可修”—某条规则误判了你改一行正则马上能验证。不要把规则写得太大太复杂保持简单让难以处理的长尾问题交给模型。4.4 输出Markdown与校验统计第三步是把分类后的行输出为Markdown。这一步同时要处理两个问题格式生成和校验统计。格式生成的思路是标题前加对应数量的井号普通段落之间用空行隔开列表项前加“-”或“1.”引用行前加“”。表格行则保留竖线并在输出前确保单元格内没有换行符。我建议在转换末尾加一个统计报告打印出基本信息这个简单步骤能帮你快速判断这次转换是否离谱def to_markdown(text): lines text.split(\n) md_lines [] block_count 0 heading_count 0 for line in lines: kind classify_line(line) if kind heading: heading_count 1 md_lines.append(f## {line.strip()}) block_count 1 elif kind bullet_list: md_lines.append(f- {line.strip()[1:].strip()}) elif kind ordered_list: md_lines.append(f1. {line.strip()}) elif kind quote: md_lines.append(f {line.strip()}) else: md_lines.append(line) # 段落之间补空行 md_lines.append() md \n.join(md_lines) return md, heading_count, block_count这里的heading_count就是后续切块的重要输入指标。如果一份5000字的文档解析出来没有标题说明规则没有匹配到这个文档的标题风格需要你回去再调正则。如果标题数量暴涨到50个大概率存在误判。这种“数字反馈”比肉眼抽查快得多。输出完成后用VS Code的Markdown预览或者任意渲染器看一眼效果。结构清楚、标题层级正确、表格不破才说明解析真的通过了。5. 结构化之后切块与元数据注入5.1 标题树与“父子路径”Markdown转换完成后下一步就是切块。很多RAG框架内置了切块器默认按固定字符数比如500或800硬切。这种一刀切的方式在长文档上问题很大一个观点可能正好被切成两半或者一个大段落因为字符数超标被塞进多个chunk。用Markdown结构切块就优雅很多。思路很简单把文档解析成“标题树”每个叶子节点保存从根节点到自身的完整路径以及路径下对应的正文内容。举例说明假设转换后的Markdown长这样## 用户手册 ### 安装 #### Windows 安装过程分为三步... #### macOS 直接拖入应用程序文件夹... ### 常见问题 启动闪退怎么处理...切块时你可以得到两个主语义块路径为“用户手册 安装 Windows”的内容块和路径为“用户手册 安装 macOS”的内容块。向量化时把“用户手册 安装 Windows”这一串路径文本拼到正文前面检索“Windows安装失败”时这个块会因为路径里有强相关词而更靠前。这是纯文本切块完全做不到的。5.2 表格、代码块、公式的特殊处理标题树能解决大部分文档但表格、代码块和公式需要单独对待。表格在RAG里是个麻烦角色。一个40行的表格整块塞进一个chunk很容易超Token而且表格中很多单元格单独拿出来没有完整语义。我的做法是按行或行组分切比如每5行切成一个小块并在块前面加上列头作为上下文。如果表格本身有“表头表格正文”的结构务必保留表头信息否则检索出来的内容会让人看不懂在说什么。代码块单独成块最好保留语言标注比如python、bash。这样后续甚至可以针对代码块做特殊的检索或过滤。公式的处理前文提过块级公式和行内公式都必须保持完整不能在切块时拦腰截断。这里补充一个细节用Markdown表示公式时行内用$...$块级用$$...$$切块器的正则要先把$$...$$整体识别为一个单元再从公式外寻找切分点。还有一个经常被问到的点RAG知识库能存图片吗答案是Markdown里的图片语法!alt文本](路径)在RAG索引时实际被处理的往往是alt文本或文件路径而不是图片本身。如果你需要直接检索图片内容那已经不是“文本解析”的范畴得接多模态模型或者CLIP向量化管线。所以指望把图片放进txt转Markdown就能让RAG看懂图片是定位错了方向。5.3 元数据让检索按来源与上下文过滤切块之后还有一道工序很多人会漏掉给每个块加元数据。元数据的价值体现在场景上。你有一个包含几十种文档的知识库用户只关心“运营手册”里的内容检索时如果不按来源过滤就可能把“技术文档”里的相似内容也捞出来。在chunk前添加YAML格式的元数据块就是个很实用的做法--- source: manual_2024.txt title: 用户手册 section_path: 安装 Windows chunk_id: manual_2024_0032 ---source记录原始文件方便排查问题title是文档标题section_path是标题树路径检索时可以作为过滤条件或拼接上下文chunk_id用于去重和调试。有了这些字段你可以在向量检索时做字段过滤比如“只检索section_path里包含‘安装’的块”效果会精准非常多。6. 实战复盘我在真实项目里踩过的解析坑6.1 编码推断翻车不只是chardet的锅有一次我在处理一批短文件时chardet把两个UTF-8编码的文件识别成了windows-1252结果中文全部乱码。后来排查发现短文件信息量太少统计检测算法容易误判。现在我会用双重策略兜底先用chardet给出候选再按候选顺序逐个尝试解码并统计解码后中文字符占比占比最高者胜出。如果中文字符占比都过低就优先回落UTF-8。简单说不要盲信任何单一检测器的结果数据量太小时宁可多试几种编码。6.2 正则误判把正文句子当成标题前面写过标题规则要限制长度这个想法不是凭空来的。我曾经用^\d{1,3}[.、]\s*当标题识别规则结果文档里“3. 根据以上分析可以得出结论……”这种句子全部被标记成标题。输出后我一看统计一份文档冒出三十多个标题才意识到正则太激进。修复思路是组合条件数字编号 短行 下一行是空行。只有满足这三个条件的才认定是标题。你可以继续增加规则但原则不变——宁可漏掉几个标题也不要误判一堆正文。漏检的后果只是切块变大误判的后果是语义边界彻底错乱。6.3 表格转Markdown后渲染破损手写转换器把带竖线的txt转成Markdown表格看着很简单实际容易翻车。有一次某个单元格里含有换行符转出来的表格多了一行整个表格在渲染器里错位。后来我在写入表格行时强制把单元格内的换行替换成空格并保证续表行数与表头一致。这个修复很小但对后期人工阅读和检索质量影响很大。6.4 验证指标与最小召回测试解析做完别急着灌进向量库先做三件事。第一跑一遍统计脚本确认总字符数、行数、段落数、标题数、表格数在一个合理范围。第二人工抽检20行看看标题分类和列表识别是否正确。第三在RAG系统里做一次“最小召回测试”用几个你真实关心的业务问题去检索看看返回的是不是对应的核心章节。这三步走完数据入口才算真正守住。上面这些坑几乎每一条都在实际项目里出过问题。我自己现在跑通用文本解析时会先准备好一套固定规则脚本再搭配人工抽检确认统计指标正常后才会进切块。如果你刚起步建议先拿三五十个真实文件跑一遍看看标题分类准不准比急着调向量模型有用得多。数据入口稳了后面的RAG链路才算真的稳。