企业官网建设流程全解析

做RAG项目最容易被低估的环节，其实是数据导入。我见过不少团队把精力全扑在向量模型选型和提示词调优上，结果知识库里的文档压根没洗干净，检索出来的内容七零八落——问一个连续的问题，模型拿到的却是被硬生生切碎的半句话，这锅真不能让召回算法背。

这个系列我打算从最基础的文本类型开始写，第一篇先聚焦大多数知识库最常见的原料：txt文件，以及如何把它处理成对RAG最友好的Markdown结构。标题里说"通用文本"，指的是那些没有固定排版约束的纯文本文档——笔记导出、网页另存、电子书复制、OCR识别结果，都属于这一类。这类文本最大的问题不是内容复杂，而是"没有结构"，而RAG的检索质量恰恰建立在结构之上。

这篇会把我的完整处理链路拆开讲：从编码识别、噪声清理，到转Markdown的方法选型，再到结构化解对检索效果的量化影响。适合正在搭本地知识库、用RAG做问答但效果不理想的人参考。

1. 为什么RAG的第一步是"文本脏活"：解析优先级判断

1.1 检索效果的上限，在导入阶段就定了

很多人对RAG有个误区，认为向量化之后一切就都靠embedding模型了。实际上，embedding模型只能对"传入它的一段文本"做语义编码，它管不了这段文本本身是否完整、是否有语义边界、是否包含干扰信息。如果你把一个章节拆成了三段不连贯的碎片，embedding再强也没办法还原上下文。

我在实际项目里做过一次对比实验：同一份产品手册，第一种方式直接把txt按固定字符数切成512字符的块，第二种方式先解析成Markdown、再按标题层级切块。在完全相同的embedding模型和检索参数下，第二组的top-5命中准确率提升了大约三成。这充分说明，解析阶段才是决定RAG质量天花板的地方。

这也是为什么我把数据导入和解析单独做成一个系列——它不是工程里的边角料，而是整套RAG系统的地基。

1.2 "通用文本"的真实来源和它们各自的问题

说"通用文本"，到项目里实际会碰到的是这几类：

• 笔记软件导出的纯文本：通常有规律的分隔线或缩进，但缺少明确的层级标记
• 网页抓取后去标签的正文：段落基本完整，但可能残留导航文字、广告位文本
• 电子书章节复制出来的内容：经常有目录页、页眉页脚、页码混在里面
• OCR跑出来的文字：断行位置随机，标点符号丢失，偶尔有错别字

这些文本的共同特点是：人类读起来没问题，模型切起来全是问题。因为RAG处理文本需要的是"机器可识别的结构"，而txt恰恰只保留了线性字符流。

1.3 结构化的目标层级：先别急着上知识图谱

提到"结构化"，有人马上想到实体关系抽取、知识图谱构建，这个方向在RAG里确实有应用场景，但对大多数中小项目来说，性能开销和工程复杂度都太高了。

我的建议是分三个层级来看：

对于通用文本，先做到基础层和增强层就够了。把txt清洗成Markdown，本质就是完成这两个层级的解析。别一上来就追求高级层，否则很容易陷入"做了三个月知识图谱，问答效果还不如简单切块"的尴尬。

2. txt文件的"入场体检"：编码、换行与噪声清理

2.1 编码识别：UTF-8是常态，GBK是常态的坑

先从最不起眼但最容易翻车的地方说起：编码。一个txt文件，如果编码识别错误，后面所有环节都会输出乱码，而且这个乱码会被直接向量化。

我推荐用charset-normalizer这个库做编码识别，它在中文场景下比chardet更准。示例代码：

import charset_normalizer def detect_encoding(file_path): with open(file_path, 'rb') as f: raw = f.read(10000) result = charset_normalizer.from_bytes(raw).best() return result.encoding if result else 'utf-8'

读取前先采样前10KB足够判断大多数情况。注意一个隐蔽问题：带BOM的UTF-8文件。如果识别到utf-8-sig，建议在转存时统一去掉BOM，否则后续按行处理时第一行会带着不可见字符，影响标题识别。

2.2 换行符与段落边界：CRLF、LF、空行的三种处理策略

txt文件的换行符五花八门。Windows记事本导出的是\r\n，macOS和Linux下保存的多是\n，还有个别文本会用单独的\r做分隔。处理时统一归一化到\n：

content = content.replace('\r\n', '\n').replace('\r', '\n')

真正影响RAG分块的是"空行边界"的处理。空行在txt里通常代表段落分隔，但并不是所有空行都该保留。我的经验是分两种情况：

• 正文段落之间的空行：保留，后续转Markdown时它就是段落的天然分隔符
• 连续两个以上空行：压缩成单个空行，避免产生大量"空白块"进入向量库

另外还要留意"短行"问题。OCR出来的文本经常一行就是一个小短句，然后用换行符硬拆开。遇到这种文件，建议先做"行合并"：如果某一行不以句号、问号、感叹号、冒号结尾，且下一行长度超过20个字符，就把两行拼接在一起。

2.3 噪声清理：目录页、页眉页脚、连续重复段的清洗清单

我总结了一个清洗清单，按优先级从高到低：

1. 目录页识别：如果文件前20行里连续出现"第X章"、"....."、纯数字页码这类模式，说明是目录页。规则是："第X章/节"配合点号或页码，命中两个以上特征就整体截掉，直到出现第一次正文特征（比如超过50字的连续段落）。
2. 页眉页脚：电子书导出的文本里经常有书名+章节名反复出现的模式。如果同一行文本在文件里出现超过3次且间隔均匀，基本可以判定是页眉，全局删除。
3. 页码行：独立成行且内容只有数字或"第X页"的，直接删除。
4. 连续重复段落：某些抓取工具会重复拼接正文，检测方法是取每段前30个字符做哈希，如果同一哈希值出现在多个位置，且完全重复的行超过50行，就要怀疑是重复内容。

实际操作中我不建议写一套"万能清洗规则"，因为不同来源的txt噪声特征差异太大。更靠谱的方案是：先抽样3到5个文件，人工看一下噪声类型，然后针对性地写清洗规则，最后批量跑。RAG导一次数据往往需要反复迭代，清洗规则也应当跟着数据源的变化持续维护。

3. 从纯文本到Markdown的三条路径与方法选型

3.1 规则转换：稳定、可解释、成本最低

把txt转成Markdown，最直接的方式是写规则。核心逻辑就一句话：通过模式匹配识别标题、列表、表格等元素，然后打上对应的Markdown标记。

一份典型的转换规则：

• 全数字编号行（如"1"、"2.1"、"3.2.4"）配合短文本，识别为标题
• 以"-"或数字加"."开头的行，识别为无序/有序列表
• 以制表符或空格对齐的列，且连续多行模式一致，识别为表格
• 有明确"第X章"、"Chapter X"等关键词的行，强制设为一二级标题

下面是我经常用的一个最小实现思路：

def txt_to_markdown(content): lines = content.split('\n') md_lines = [] for line in lines: stripped = line.strip() # 标题识别：形如"2.1 背景介绍" if re.match(r'^\d+(\.\d+)*\s+\S', stripped): level = stripped.split(' ')[0].count('.') + 2 md_lines.append(f"{'#' * level} {stripped.split(' ', 1)[1]}") # 无序列表 elif re.match(r'^[-*•]\s+', stripped): md_lines.append(f"- {re.sub(r'^[-*•]\s+', '', stripped)}") # 有序列表 elif re.match(r'^\d+[.、]\s+', stripped): md_lines.append(f"{stripped}") # 普通段落 elif stripped: md_lines.append(stripped) else: md_lines.append('') return '\n'.join(md_lines)

这段代码只是一个骨架，真实场景里要处理的是大量边缘情况，比如"2.1"后面没有空格、标题行本身就是加粗文本、列表项跨行等。但它演示了一个关键思想：规则转换的每一步都可解释、可调试、可针对失败样例补充规则。

3.2 LLM辅助解析：适合复杂文本，但要控制成本和幻觉

如果txt文本本身没有规律——比如章节编号混乱、段落边界模糊、甚至混用了多种排版风格——规则转换会变成一个无底洞。这时候可以考虑用LLM做结构化抽取。

做法是构造一个解析Prompt，让模型输出Markdown格式的正文：

你是一个文档结构化引擎。请把下面输入的正文重写为Markdown格式： 1. 识别标题层级，使用#、##、###标记 2. 保留段落缩进与列表结构 3. 表格数据使用Markdown表格语法 4. 不要做任何内容改写、摘要或翻译 输入内容如下： {chunk}

注意这里的措辞是"重写为"而不是"提取"，目的是让模型保持原文措辞，减少信息损耗。我测过几个模型，在结构化抽取任务上，把输入切成2000字以内的小段效果最稳，超过3000字很容易出现标题丢失或列表结构错乱。

使用LLM辅助解析的最大风险是幻觉——模型可能生成原文里没有的章节标题，或者把普通段落"脑补"成列表。对策是在解析结果里做对比校验：用difflib比较原始文本和解析后文本的字符重叠率。如果重写后的内容被大段替换，说明模型做了改写，需要重新解析。

3.3 工具链参考：pandoc与textutil的适用边界

除了自己写代码，有些现成工具可以省不少力：

• pandoc：能把多种格式转成Markdown，支持自定义模板。但它默认处理的是有结构的格式（docx、html、epub等），对无结构的txt无能为力。它的用武之地在"二次精修"——把已经带基础Markdown标记的文本统一规范化。
• textutil（macOS自带）：可以把txt转成html，再通过html间接获得一些段落结构。多一步转换，结果可控性一般，适合linux/mac环境下快速批量处理。
• VS Code / Sublime Text插件：Markdown All in One、Markdown Preview Enhanced这类插件主要用于预览和编辑，不适合批处理，但在抽样检查转换效果时非常好用——直接在编辑器里看标题树是否正常。

工具选型的原则：规则能解决的不用LLM，LLM能解决的不用人工。pandoc这类通用工具适合做格式转换，不适合做内容清洗。

4. Markdown结构化解：解析后的信息骨架如何决定检索质量

4.1 标题层级树：分块切分的天然锚点

Markdown对RAG最大的价值，是#标题提供了明确的层级信息。这意味着分块不再依赖"固定字符数硬切"，而是可以以标题为单位，把相邻内容聚合到同一块里。

我常用的分块策略是"标题树聚合"：

1. 解析Markdown，提取标题间的包含关系
2. 从某个二级标题开始，把下属内容组合成一个候选块
3. 如果候选块超过分块上限（比如1500字符），沿三级标题继续拆分
4. 在每块的文本前自动拼上所属的完整路径，如"## 安装指南 > ### 环境要求"

第四步是关键：给子块拼上祖先标题路径，相当于给每个块注入了上下文信息。这种方法比单纯切字符分的块语义要完整得多，实测检索效果提升非常明显。

4.2 表格的语义保留：别让关系型信息变成碎片

txt里如果混着表格，是最容易被解析环节毁掉的。典型错误是：把表格每一行当成独立段落切块，向量化之后行与行之间的对应关系全丢了。

转成Markdown之后，表格有了明确的语法边界（|竖线分隔），建议单独处理：

• 小表格（行数少于10行）：整体作为一个块保留，不要切分
• 大表格：按逻辑行分组切分，每组保留表头作为上下文前缀
• 检索时把表格块的标题路径加进块内容，避免"只知道表格内容、不知道表格主题"

如果你后续有把Markdown表格转成Excel分析的需求，注意保留表头的完整性和分隔行（|---|---|）的格式。有些工具导出表格时会把分隔行丢掉，导致解析器识别不了表头。

4.3 代码块、引用块、数学公式的边界处理

这三个元素在RAG场景里的共同点是：不能和普通正文混在一起切块。

• 代码块：用````围栏包裹，切块时优先保留代码块完整性。如果代码超过分块大小，宁可整块作为一个超长块，也不要从中间切开——切开的代码没有任何语义。
• 引用块：一般对应原文中的强调或回填说明，可以跟后续正文合并，但要保留>标记，让向量模型识别到这是引用语气。
• 数学公式：如果用的是带$分隔的LaTeX语法，切块时避开$...$的中间位置，否则公式符号会被拦腰截断。网上搜"markdown数学公式插件"能查到不少渲染方案，处理逻辑上核心就一条：公式边界优先于分块边界。

4.4 元数据注入：给每个块配一张"身份证"

结构化解除了做格式转换，还应该顺带提取元数据。元数据是很多RAG项目完全忽略的一块，但它的作用非常大。

至少建议注入以下字段：

有了这份元数据，你后续做RAG的过滤器、时间衰减、增量更新都有抓手。很多人等到检索效果不好才回头补元数据，那时候数据已经向量化入库了，补起来非常痛苦。

5. 结构化解的实际收益：一次可复现的对比验证

5.1 测试设计：同源文本，两种处理路径

光说"结构化好"没有说服力，我分享一个实测的对比验证，你可以直接在项目里复现。

取一份约5000字的产品开发文档，做两组处理：

• A组（纯文本路径）：识别编码后，按512字符固定长度切块，overlap设64字符，不做任何结构化处理
• B组（Markdown路径）：先用规则转为Markdown，按标题树聚合切块，子块自动拼接标题路径

两组使用完全相同的embedding模型（我测的时候用的bge-large-zh-v1.5），向量检索用相同的TopK参数。设计20个覆盖各章节细节的问题，按"命中正确答案所在块"作为评估指标。

5.2 对比结果与统计分析

我的测试结果如下表：

最直观的差异是碎片化截断：A组里有好几个问题检索到的都是"把一句话拦腰切断"的片段，模型回答时只能靠猜；B组这种问题几乎不存在。

另一个有意思的发现是，B组的"无效块召回"明显更少——原因很简单：纯文本切块会把正文和目录、页脚混在一起，这些垃圾块经常被无关问题检索到，白白占用上下文窗口。

5.3 收益边界：不是所有文档都值得做结构化

不过也要客观说一句：结构化解析不是银弹。我总结了三个"不值得做"的场景：

1. 全文档无层级：比如一份纯FAQ列表，没有标题树可依，结构化能做的只是列表识别，收益有限
2. 单次丢进去跑着玩的测试数据：如果只导入几个文件做验证，多花的时间可能比检索收益还大
3. 已有高质元数据的源头：如果源系统（比如数据库或知识库）已经带了结构化字段，直接从源头拿数据就好，没必要从txt再造一遍

结构化解析的最大价值在于批量、长期、持续更新的知识库构建——成本一次性，收益持续发生。

6. 落地过程中的高频坑位与补救手段

6.1 标题被切碎与层级错乱

规则转换里最常见的问题是"假标题"。一个段落开头写了"2024.03.18 项目启动会记录"，正则如果匹配"数字.数字"就会误判成三级标题。对策是给标题识别加约束条件：标题行结尾不能以标点符号（。，；：）收尾，且标题长度不超过30个字。这两条规则能过滤掉八成以上的误判。

另一个问题是"同一份txt里，不同章节的标题风格不一致"——第一章用"第X章"，第二章用"X.X. 标题"，第二章里又有居中大字。这种情况下先统计全文的标题格式分布，选最频繁的一种作为主规则，剩余的交由人工抽查修正，比强求一套规则覆盖所有情况更高效。

6.2 转义与特殊符号的坑

Markdown里触发语法的字符很多，txt里经常原样出现。最典型的：表格里的竖线|。如果原文是一段说"使用A | B进行对比"，转成Markdown表格语法时竖线会被解析成分隔符。这种情况需要统一转义为\|，否则表格列数乱掉。

代码块里如果本身包含三个反引号，围栏语法会被提前终止。我的处理是用四个反引号围栏包裹内含三个反引号的块，或者干脆对内容做HTML实体编码。建议在转Markdown后的校验环节加一个"语法完整性检查"：统计反引号围栏是否成对、表格行竖线数是否一致、标题层级是否连续。

6.3 分块器与Markdown结构的配合：别让后道工序毁掉前道成果

即使你把文本完美转成了Markdown，如果后端的文本分块器不理解Markdown语法，之前的工作就白做了。

不要直接用通用文本Splitter处理Markdown。推荐两种方案：

• 使用Markdown感知的分块器：很多主流框架（比如LangChain的MarkdownHeaderTextSplitter，或是LlamaIndex的MarkdownNodeParser）已经内置了标题感知逻辑
• 自研"两步走"分块：第一步按标题层级切分得到大块，第二步对大块内部，再按段落或固定字符数细分

自研的好处是可控性更强——比如你可以决定哪些标题层级参与切块（通常只用H2和H3），哪些需要合并（H4及以下一般合并到父标题里，避免块太碎）。

6.4 中小项目的一条省心成绩单

最后给一个可以直接参考的管线配置，适合中小规模的本地RAG知识库：

1. 数据接入：读取txt，用charset-normalizer识别编码并统一UTF-8
2. 噪声清洗：按2.3节的清单规则批量处理
3. 结构转换：正则规则做第一轮Markdown转换
4. 人工抽查：每批次随机抽5个文件，用Sublime Text或VS Code打开，检查标题树和表格占位
5. 复杂文档兜底：规则转换效果差的文件，走LLM辅助解析通道
6. 元数据注入：写入source_file、title_path、chunk_type等字段
7. Markdown感知分块：按标题层级切分，并拼接标题路径到子块
8. 向量化入库前最后的校验：统计空块、超长块、孤儿标题的数量，异常数据单独拉出排查

这套流程我跑过不少项目，最大的体会有两个：一是先小步迭代再批量跑，别一开始就在几千个文件上跑全流程；二是每个环节都保留中间产物，清洗前后的diff、Markdown解析的结果都存下来，排查问题时能直接溯源。

把这块做好，你的RAG知识库才真正有了可靠的地基。