文件解析后如何进入知识库？切分、清洗、元数据和索引怎么设计？
这道题考的是RAG系统中文档处理的完整管线设计。核心就一件事：文档从上传到进入知识库，中间要经历哪些环节，每个环节怎么设计才合理。这题看起来简单，但能答全的人不多，因为涉及的知识点确实多。我一个个说。
文档入库的六环扣
先给你把整个链路捋清楚。文档入库要经过六个标准环节：文件上传→格式校验→Layout解析→清洗去噪→Chunking→Metadata→入库。
文件上传后不是直接入库的，得先校验格式。PDF、Word、Markdown、图片，每种格式的处理逻辑不一样。格式校验通过后进入Layout解析，这个环节是识别文档结构的，章节标题、段落、表格、图片位置都要解析出来。
清洗去噪是很多人忽略的环节。原始文档里有很多"噪音"：页眉页脚、连续的空行、隐藏的格式符号。这些不清干净，后面切分出来的chunk会包含大量无意义内容。
然后才是Chunking切分，接着给每个chunk挂上元数据，最后才入库。
每个环节都可能出问题。编码混乱会导致乱码，解析器崩溃会导致部分内容丢失，向量维度不一致会导致入库失败，Token超限会导致切分失败。这条链路就像餐厅后厨的流水线，备料、洗菜、切配、烹饪、装盘，每一步都要到位，前一步出问题后面全乱。
切分策略选型
切分是整个环节里最核心的。切分策略选错了，后面怎么调embedding都救不回来。
先说通用建议：文本类文档400-512个Token，这是一个经验值，在这个范围内语义完整性比较好，embedding效果也稳定。代码类文档要小很多，大概100个Token就够了，而且重叠窗口要设到15个Token，防止函数定义被截断。
三种主流切分策略：
固定长度切分最简单，按字数或Token数直接砍。这种方式简单粗暴，但问题是会刚好把一个完整的句子、一个表格、一段代码从中间截断。语义完整性很差。
递归字符切分稍微智能一点，它会优先按段落切分，找不到段落再按句子，再找不到才按固定长度砍。这种方式比固定长度好，但仍然是基于标点符号和换行符判断的，不理解语义。
语义切分是效果最好的。按文档结构来切：Markdown按H1/H2/H3的层级切，PDF按页或章节切，代码按函数或类切。这种方式能保证每个chunk都是语义完整的单元。
这里有个折中方案叫Parent-Child Chunk。大chunk保证上下文完整性，小chunk负责精准召回。检索时用小chunk匹配，用大chunk提供上下文。召回和上下文的矛盾，用这种方式解决。
切分就像厨师切菜。固定长度是乱刀砍，顺着纹理切才好看。语义切分就是顺着文档的"纹理"切。
元数据设计
元数据是文档的身份证和户口本。很多人觉得元数据可有可无，这是不对的。没有元数据，你的知识库就是一个黑盒子，检索结果没法过滤、没法引用、没法追溯出处。
核心元数据有七类：
标题和摘要，这是最基础的。
作者和日期，用于追溯文档来源和判断时效性。
行业分类和业务分类，用于多租户场景下的权限隔离和精准检索。
权限级别，决定谁能看这个文档。
关键词和标签，用于补充文本检索的不足。
章节路径，记录这个chunk在原文档里的位置，方便回溯和引用。
元数据缺失的后果很严重。想象一下，用户问"去年第三季度的财务报表有哪些"，你没办法按日期过滤。用户问"这份报告是谁写的"，你没法追溯作者。用户问"某个表格的数据来源是什么"，你没法关联原始文档。
元数据是权限控制、时效管理、结构追溯的基础设施。这三个能力，没有元数据都实现不了。
语义丢失的四大坑
切分不当会造成语义丢失，这是RAG系统最常见的问题。语义丢失的本质是上下文断裂和结构信息丢失。
四种典型场景：
业务逻辑截断。比如一个合同条款，"甲方应于收到乙方发票后30日内支付款项"，如果刚好在"30日"后面截断，后面的"内"字跑到下一个chunk里了。这种语义丢失会导致RAG返回的片段意思完全扭曲。
位置信息丢失。文档里说"见上图"、"如上表"，如果图表和这个引用被切到不同的chunk里，单独召回这个chunk的引用部分，读者根本看不懂在说什么。
表格语义关系丢失。表格是一个整体，每行每列的语义是关联的。如果把表格从中间横切一刀，或者从某一列中间竖切，上下文的关联就断了。
专有名词截断。技术文档里有很多专有名词，比如"PostgreSQL数据库"、"Kubernetes集群"，如果刚好在词中间截断，变成"Postgre"和"SQL数据库"，embedding效果会严重失真。
解决思路有两个：重叠窗口设计，让相邻chunk有重叠部分，保证上下文延续；多模态保留，图片要有Caption和OCR结果，表格要保留完整的行列结构信息。
把完整的红烧肉切成两半，一半只有肉皮，一半只有骨头，这菜没法吃。文档切分也是这个道理。
数据质量优先
最后说一个很多人不重视的点：文档处理管线比embedding模型调优重要得多。
你的embedding模型再牛，用一堆乱码、截断、无意义的chunk去喂它，出来的效果也好不了。数据处理决定AI回答的质量上限。embedding调优只是在这个上限上做微调。
多轮清洗是必要投入。原始文档进库前要过至少两轮清洗：第一轮去格式噪音，第二轮去语义噪音。格式噪音是页眉页脚、空行、隐藏字符这些。语义噪音是重复段落、无意义符号、截断的句子这些。
分层校验策略要设计好：
第一层，空文件拒绝。上传个空白文档进来，直接拒绝。
第二层，格式不支持拒绝。你的系统不支持某种格式，直接拒绝，不要硬着头皮解析。
第三层，解析失败进人工队列。程序解析失败的，进人工处理队列，不要丢弃。
第四层，乱码率高拒绝。解析出来的内容乱码率超过阈值，拒绝入库。
第五层，Chunking异常检测。切分后发现chunk过大或过小，进入异常处理流程。
第六层，部分成功处理。文档有部分内容解析成功，部分失败，要分别处理，不能一刀切。
再好的厨师也做不出用烂菜做出的好菜。数据管线做到位，比换一百个embedding模型都管用。
面试怎么答
给你一个可以直接背的回答框架：
文档进入知识库要经过六个环节：格式校验、Layout解析、清洗去噪、Chunking、元数据挂载、入库。切分策略推荐通用文本400-512 Token，代码约100 Token加15 Token重叠，按文档结构语义切分效果最好。元数据要包含标题、作者、日期、行业分类、权限级别、关键词、章节路径这七个维度，用于权限控制和精准检索。语义丢失的坑主要有业务逻辑截断、位置信息丢失、表格关系丢失、专有名词截断，解决方法是重叠窗口和多模态保留。我始终坚持数据管线优先于embedding调优，分层校验策略把好质量关。
这是基础版，能覆盖核心要点。加分项是提到Parent-Child Chunk的折中方案、用"厨师切菜"类比语义切分的优势、强调数据管线比embedding调优更重要、能把语义丢失的四种场景和本质讲清楚。
一句话总结
文档入库的核心是：六环节链路走完整，语义切分做到位，元数据挂全，分层校验把质量关。