搬家那天,你站在老房子里犯愁:书柜里塞着积压多年的合同(PDF),抽屉里是打印出来的论文(Word),收藏夹里躺着几十个网页(HTML),邮箱里还有一堆往来邮件。真要一股脑全搬进新家,以后想找“去年那份租房合同”,无异于大海捞针。专业的做法是先请一位整理师上门:她把物品分门别类,书籍归书籍、票据归票据、相册归相册,装进统一的收纳箱,每个箱子贴好标签、编好号。搬进新家后,你只需要告诉管家“我要找某样东西”,管家顺着标签几秒钟就能翻出来。 这个故事讲的正是搭建 AI 问答系统时的第一道工序:在把文档交给检索系统之前,先由一位“文档整理师”——也就是本文的主角 Unstructured——把 PDF、Word、HTML、邮件等五花八门的文档,变成干净、结构清晰、带标签的知识库“收纳箱”。本篇文章会带你认识这位整理师的分拣逻辑、元素体系、解析流程,以及它如何与切分策略、检索系统完美配合,让 AI 回答问题的质量稳稳提升。

岗位关联

对 AI 从业者的价值:文档解析是 RAG 的第一道工序,解析质量直接决定检索召回率与回答准确率。掌握 Unstructured,你就能在处理复杂格式文档时游刃有余,这是构建生产级 RAG 应用的必备技能。

目录
  1. 可视化演示
  2. 解析价值:收纳决定管家能力
  3. 解析器核心:一个“分拣台”
  4. 元素类型:给每件物品归类
  5. 解析流程:拆解复杂文档
  6. 切分策略:装成统一的收纳箱
  7. 元数据加持:给箱子贴标签
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示词语经嵌入层映射为高维向量,通过余弦相似度衡量语义关联,并演示词类比推理。

本节配有交互动效(进入视口后自动加载,约 3KB)。

词向量嵌入表示 每个词映射为8维向量,不同维度捕获不同语义特征 相似词的向量在各维度上相近 v(w)∈Rd Word2Vec/GloVe学习得到

解析价值:收纳决定管家能力

搬进新家的第一天,你想找去年那份租房合同,管家翻遍所有柜子也没找到。是管家不努力吗?不是——是搬家整理师把合同和一堆旧报纸混装在同一个箱子里,连标签都没贴。在 RAG 系统里,“整理师”就是文档解析环节,它的工作质量,直接决定了检索能把东西找回来多少。

RAG 的标准流程是:先解析文档,再切分成块,然后向量化入库;用户提问时,检索系统把最相关的块找出来,交给大模型生成答案。这条流水线的第一道工序就是文档解析。如果解析环节把表格丢了、把标题和正文糊在一起、把页眉页脚当成正文,后续的切分、检索都会在错误的地基上盖楼。

现实中的文档远比想象中复杂:有文本型 PDF,有扫描图片型 PDF,有带目录和多栏排版的 PDF;还有 Word、PPT、HTML、邮件、CSV……每种格式的“内部构造”都不一样。Unstructured 这类解析库专门解决“把任意格式变成结构化文本”的问题。衡量解析效果的一个重要指标是召回率,它回答的是:“该找到的信息,有多少真的被找回来了?”

所以,想提高 RAG 的问答质量,与其反复调提示词、换向量模型,不如先回头检查“整理师”有没有把文档理清楚。解析做好了,后面每一步都顺;解析偷了懒,再强的检索模型也救不回来。

Recall=N命中N相关×100%\displaystyle \text{Recall} = \frac{N_{\text{命中}}}{N_{\text{相关}}} \times 100\%
召回率 = 检索系统实际找到的相关内容 ÷ 知识库中全部相关内容。比率越高,说明“整理师”装箱和“管家”翻找配合得越好。
  1. N_相关(应找出的目标)知识库中与问题真正相关的全部内容数量,相当于搬家清单上你真正需要的物品总数。
    N相关N_{\text{相关}}
  2. N_命中(实际找到的)检索系统实际召回的相关内容数量,即整理师装进“正确箱子”且管家成功翻出的物品数。
    N命中N_{\text{命中}}
  3. 比值与百分比用命中的相关量除以全部相关量再乘以 100%,得到召回率——衡量“该找的东西找到了几成”。
    N命中N相关×100%\frac{N_{\text{命中}}}{N_{\text{相关}}} \times 100\%

解析器核心:一个“分拣台”

整理师上门的第一件事,是看这堆东西到底是纸箱、信封还是电子设备。纸箱要拆封,信封要开信刀,电子设备要装进防静电袋——处理方式完全不同。Unstructured 的 partition 函数就是这位“分拣台”:任何文件进来,它先判断“你是什么”,再决定“送你到哪条流水线”。

partition 是所有解析的统一入口,它通过扩展名、MIME 类型和文件头魔数自动检测文件格式,然后路由到对应的专属解析器:partition_pdf 处理 PDF、partition_docx 处理 Word、partition_html 处理 HTML、partition_email 处理邮件。调用方只需要写一行 elements = partition(filename="手册.pdf"),完全不关心内部走了哪条通道。

每个解析器背后是插件化的依赖生态:PDF 解析依赖 pypdf 或 PDFMiner,DOCX 解析依赖 python-docx,HTML 解析依赖 lxml。正因如此,Unstructured 才能以“一个 API、多种策略”的形式,覆盖日常工作中绝大多数文档格式。

有了“分拣台”,整理师就不必为“来的是什么”发愁,只需要把每个类型的处理流程打磨到极致。这正是 Unstructured 能以统一 API 应对千奇百怪文档的底气所在。

Strategy(f)={partition_pdf(f),if type(f)=PDFpartition_docx(f),if type(f)=DOCXpartition_html(f),if type(f)=HTML\displaystyle \text{Strategy}(f) = \begin{cases} \text{partition\_pdf}(f), & \text{if } \text{type}(f)=\text{PDF}\\ \text{partition\_docx}(f), & \text{if } \text{type}(f)=\text{DOCX}\\ \text{partition\_html}(f), & \text{if } \text{type}(f)=\text{HTML} \end{cases}
这个分段函数描述“分拣台”的路由逻辑:根据输入文件 f 的类型,选择不同的解析策略,最终都输出统一的元素列表。
  1. 文件 f(待处理的物品)输入的文件对象,包含字节内容、路径与扩展名,是分拣台收到的“包裹”。
    ff
  2. 类型判定 type(f)通过扩展名、MIME 类型或文件头识别文件属于哪种格式,相当于拆包裹前先看寄件单。
    type(f)=PDF\text{type}(f) = \text{PDF}
  3. 策略分发(走哪条通道)根据判定结果把文件交给对应解析器,各解析器返回结构完全一致的元素列表,方便下游统一处理。
    Strategy(f)={partition_pdf(f),PDFpartition_docx(f),DOCXpartition_html(f),HTML\text{Strategy}(f) = \begin{cases} \text{partition\_pdf}(f), & \text{PDF}\\ \text{partition\_docx}(f), & \text{DOCX}\\ \text{partition\_html}(f), & \text{HTML} \end{cases}

元素类型:给每件物品归类

整理师会把物品分成衣物、书籍、文件、杂物,每类的装法完全不同:衣物用真空袋压缩,书籍立放防潮,文件按项目装进文件夹。解析器也一样,它输出的“元素”(Element)就是文档的物品分类。

Unstructured 把文档内容拆成带类型的元素:Title 标题、NarrativeText 段落正文、Table 表格、Image 图片、ListItem 列表项,以及 Header/Footer 页眉页脚、PageBreak 分页符。元素按照文档原有的阅读顺序排列,每个元素都携带文本内容和元数据,比如标题元素会记录它是几级标题。

元素类型不是摆设:它决定了后续的切分策略和检索方式。表格可以转成 Markdown 结构化文本,图片可以配合说明文字单独处理,页眉页脚则可以在入库前被过滤掉。类型体系越完整,下游“装箱”就越有章法。

有了类型标签,“装箱”环节就能按物品特性决定怎么装,而不是把衣物和电器塞进同一个纸箱。分类清晰,是后续一切操作的前提。

Doc=[ E1,E2,…,En ],Ei∈{Title,NarrativeText,Table,Image,ListItem}\displaystyle \text{Doc} = [\,E_1, E_2, \ldots, E_n\,], \qquad E_i \in \{\text{Title}, \text{NarrativeText}, \text{Table}, \text{Image}, \text{ListItem}\}
整篇文档被表示成一个有序的元素序列,每个元素只能属于有限的类型集合。这就像整理师给每件物品盖了一个“类别戳”。
  1. Doc 是有序序列整篇文档被表示为一系列元素的列表,顺序就是文档原本的阅读顺序,不能打乱。
    Doc=[E1,E2,…,En]\text{Doc} = [E_1, E_2, \ldots, E_n]
  2. E_i 元素(每件物品)每个元素携带文本内容和元数据,比如标题元素带层级、表格元素带行列结构。
    EiE_i
  3. 类型集合(物品分类)元素只能属于有限的类型集合,类型决定了后续的切分与检索策略。
    Ei∈{Title,NarrativeText,Table,Image,ListItem}E_i \in \{\text{Title}, \text{NarrativeText}, \text{Table}, \text{Image}, \text{ListItem}\}

解析流程:拆解复杂文档

整理 PDF 就像整理一个旧文件柜:先拉开柜门读取文件,再看柜子里有没有分隔板(版面布局),有些文件被塑封着(扫描件),还得先“拆膜”——也就是 OCR 光学字符识别——才能读到里面的字。

PDF 解析分两条路:文本型 PDF 自带文字层,直接提取即可;扫描型 PDF 本质是图片,需要 OCR 识别。Unstructured 提供 fast 和 hi_res 两种模式,hi_res 模式会用版面检测模型划分区域——标题区、正文区、表格区、图片区——然后逐区域提取内容,复杂排版也能从容应对。

表格是解析的重头戏:识别出表格区域后,解析器还要还原单元格边界与行列结构,最终输出成 Markdown 表格文本,让大模型能直接读懂“第几行第几列是什么”。图片则会被裁剪保存并配上说明文字。最后还有一道“文本清理”:去掉页码、页眉页脚等噪音,合并被断行拆散的段落。

“拆膜”“拉抽屉”“誊账目”这些动作做完,文件内容才真正裸露出来,可以放心地归类装箱。解析流程的扎实程度,决定了后面每一步能走多远。

Table  ⇒  Theader⊕R1⊕R2⊕⋯⊕Rm  ⇒  Markdown 文本\displaystyle \text{Table} \;\Rightarrow\; T_{\text{header}} \oplus R_1 \oplus R_2 \oplus \cdots \oplus R_m \;\Rightarrow\; \text{Markdown 文本}
表格的解析本质是“网格结构还原”:先拆出表头和数据行,再拼接成 Markdown 表格。好比把抽屉里的票据按“日期 + 金额”重新排成账目表。
  1. 原始表格输入(抽屉票据堆)从 PDF 或图片中识别出的表格区域,本质是一张二维单元格网格。
    Table\text{Table}
  2. 表头与数据行(账目的表头和明细)把网格拆成首行表头和其余数据行,表头给出每列的含义,数据行是具体内容。
    Theader⊕R1⊕R2⊕⋯⊕RmT_{\text{header}} \oplus R_1 \oplus R_2 \oplus \cdots \oplus R_m
  3. 序列化输出(誊写成清单)用竖线与换行把表头和数据行拼成 Markdown 表格文本,供大模型直接阅读。
    Table⇒Markdown 文本\text{Table} \Rightarrow \text{Markdown 文本}

切分策略:装成统一的收纳箱

书不能全部塞进一个大箱——太重搬不动,检索时噪音也多;也不能一本书装一个箱——箱子数量爆炸,管家无从下手。整理师的策略是:按“项目”分区,每箱装适量物品,箱与箱之间留一点缓冲,防止分界处的物品被拆散。

切分(chunking)就是决定“每个收纳箱装多少”。Unstructured 提供元素感知的切分方法,比如 chunk_by_title 会按标题把其下属的段落、表格聚合在一起,保证一个块属于同一个语义单元。块大小通常控制在 300–800 token,重叠(overlap)约 50–100 token。

元素感知切分避免了“表格被拦腰截断”的尴尬,重叠则保证跨块的语义依然连贯。切分完成后,每个块还会重新拼接所属章节标题等元数据,让块在检索时自带上下文。

装箱策略直接决定管家翻找的体验:箱子太大太重(块过大、噪音多)、太碎(块过小、语义不全)、没有缓冲(无重叠、语义断裂),都会让检索事倍功半。

n=⌈L−sk−s⌉\displaystyle n = \left\lceil \frac{L - s}{k - s} \right\rceil
给定文档总长度 L、块大小 k、重叠长度 s,就能算出会切成多少块。分母 k−s 是“每切一块实际前进的距离”,分子 L−s 是“第一块之外还需覆盖的长度”。
  1. L 总长度(全部物品的体量)把文档所有元素文本拼接后得到的总 token 数,相当于要装箱的物品总量。
    LL
  2. k 块大小与 s 重叠(箱容与缓冲)k 是每个块的期望 token 数,s 是相邻块共享的 token 数,重叠区就是箱与箱之间的缓冲垫。
    k−sk - s
  3. 分子 L−s(净长度)总长度减去一个重叠长度,对应“第一个块完整占据 k,后续每个块只新增 k−s”的排布方式。
    L−sL - s
  4. 向上取整(最后按箱计)净长度除以每块实际前进步长,向上取整得到块数,最后不满一箱也要算一箱。
    n=⌈L−sk−s⌉n = \left\lceil \frac{L - s}{k - s} \right\rceil

元数据加持:给箱子贴标签

收纳箱装好后,整理师会在每只箱子外贴上标签:“财务—2024 发票—箱 3”“人力资源—员工手册—箱 7”,还写上所在房间和楼层。搬进新家后,管家按标签几秒钟就能定位。元数据,就是 RAG 世界里箱子的标签。

Unstructured 为每个元素附上丰富的元数据:来源(source)、页码(page_number)、元素类型(type)、标题层级(category_depth)等。这些信息会跟着切分后的块一起存入向量库,在检索时作为过滤条件使用——比如“只搜表格”或“只搜某份制度的第 2 页”——也能在回答时提供可追溯的引用来源。

检索打分时,还可以把元数据匹配作为加权项:基础相似度加上“元数据一致”的加分,让类型对、页码对的块排名更靠前。元数据越规范,检索系统就越像一个熟门熟路的管家。

有了标签,管家不仅能找到东西,还能告诉你东西来自哪只箱子、哪一层楼——这正是 RAG 需要“引用来源”的原因。整理师的最后一步,也是一切检索体验的开始。

Score(q,d)=Sim(q,d)+λ⋅1[meta(q)=meta(d)]\displaystyle \text{Score}(q, d) = \text{Sim}(q, d) + \lambda \cdot \mathbf{1}\big[\text{meta}(q) = \text{meta}(d)\big]
最终得分 = 向量相似度 + λ × 元数据匹配加分。当用户指定“只要表格”而某块恰好是 Table 元素时,指示函数取 1,该块被额外加分。
  1. Sim 基础相似度(内容本身的匹配度)查询与文档块之间的向量余弦相似度,是检索的基线分数。
    Sim(q,d)\text{Sim}(q, d)
  2. 指示函数(标签是否吻合)查询要求的元数据(如“表格”“页码 2”)与块的元数据一致时取 1,否则取 0。
    1[meta(q)=meta(d)]\mathbf{1}[\text{meta}(q) = \text{meta}(d)]
  3. λ 权重(标签的加分力度)调节元数据匹配对最终排序的贡献:过大则过度依赖过滤,过小则标签形同虚设。
    Score(q,d)=Sim(q,d)+λ⋅1[meta(q)=meta(d)]\text{Score}(q, d) = \text{Sim}(q, d) + \lambda \cdot \mathbf{1}[\text{meta}(q) = \text{meta}(d)]

AI 应用场景

场景 1:企业制度手册问答机器人

阶段:RAG 预处理(文档解析与切分)

解决的问题:传统做法把 HR 的 PDF 制度全文硬切,表格和正文混在一起,员工问“差旅住宿标准”时常检索到无关段落。用解析后的元素切分,表格独立成块、标题层级还原,检索能精准命中。

具体案例:某公司用 Unstructured 解析员工手册、报销制度、差旅标准等 200 份 PDF,表格转成 Markdown 后标注“制度类型 + 年份”元数据。员工提问“2024 年差旅住宿上限是多少”,检索系统先按“表格”类型过滤再排序,回答附上原文页码,准确率显著提升。

场景 2:合同审核辅助系统

阶段:文档解析(多格式 + OCR)

解决的问题:合同常以扫描件、Word、邮件附件多种形式存在,法务要快速找到特定条款,人工翻阅效率极低。解析管线需要统一处理多格式并保留结构化信息。

具体案例:系统解析扫描 PDF 时自动启用 OCR,识别出“违约责任”“金额”等条款块,按合同编号和条款类型打标入库。律师问“某合同的违约金比例”,系统定位到对应 Table 或段落块,并引用页码给出依据。

场景 3:多源帮助文档统一客服

阶段:文档解析(HTML 噪音过滤)

解决的问题:官网 FAQ、更新日志、技术博客格式不一,导航栏和页脚噪音混杂,直接切分会让向量库充满垃圾信息。

具体案例:将官网帮助页统一用 partition_html 解析,过滤导航、页脚等噪音元素,只保留标题和正文元素再切分入库。客服机器人回答准确率从 62% 提升到 84%,且回答可追溯到具体帮助页面链接。

Python 演示

python85 行
# Simulate the Unstructured pipeline: partition -> elements -> chunks.# 分拣台 -> 元素提取 -> 切块, 中文注释使用半角标点.import os  class Element:    def __init__(self, etype: str, text: str, **meta):        self.etype = etype      # 元素类型: Title / NarrativeText / Table        self.text = text        # 元素文本, 后续送入 embedding        self.meta = meta        # 元数据: page / source / 标题层级     def __repr__(self):        return "<{} {}>".format(self.etype, self.text[:16] + "...")  def partition_document(file_path: str):    """Route a file to its parser by detected type."""    ext = os.path.splitext(file_path)[1].lower()    if ext == ".pdf":        return parse_pdf(file_path)    if ext in (".docx", ".doc"):        return parse_word(file_path)    if ext in (".html", ".htm"):        return parse_html(file_path)    raise ValueError("unsupported format: " + ext)  def parse_pdf(file_path: str):    # 真实项目中使用 partition_pdf(filename=file_path)    return [        Element("Title", "2024 Employee Handbook", page=1, source=file_path),        Element("NarrativeText", "Chapter 1: Onboarding guide for new hires.",                page=1, source=file_path),        Element("Table", "Team | Owner | Seat\nTech | Alice | A301",                page=2, source=file_path),        Element("ListItem", "Submit the form 15 days before probation ends.",                page=3, source=file_path),    ]  def parse_word(file_path: str):    # 真实项目中使用 partition_docx(filename=file_path)    return [        Element("Title", "Weekly Report (Week 12)", page=1, source=file_path),        Element("NarrativeText", "Retrieval module is online, recall up by 5%.",                page=1, source=file_path),    ]  def parse_html(file_path: str):    # 真实项目中使用 partition_html(filename=file_path)    return [        Element("Title", "Help Center: Reset Password", page=1, source=file_path),        Element("NarrativeText", "Open the login page and follow the email link.",                page=1, source=file_path),        Element("ListItem", "Check the spam box if no email is received.",                page=1, source=file_path),    ]  def chunk_by_size(elements, chunk_size=3, overlap=1):    """Split elements into windows with overlap."""    chunks, i, total = [], 0, len(elements)    while i < total:        chunks.append(elements[i: i + chunk_size])        i += chunk_size - overlap      # 前进步长 = 块大小 - 重叠    return chunks  def main():    docs = ["manual.pdf", "weekly.docx", "help.html"]    all_chunks = []    for doc in docs:        print("== partition:", doc)        elems = partition_document(doc)        for e in elems:            print("  ", e)        for idx, c in enumerate(chunk_by_size(elems), 1):            all_chunks.append((doc, idx, c))            print("   chunk #{}: {} elements".format(idx, len(c)))    print("== total chunks:", len(all_chunks), "-> ready for embedding")  if __name__ == "__main__":    main()
目的:用不到 100 行代码模拟 Unstructured 的核心管线——按格式分拣、提取带元数据的元素、按重叠窗口切块,演示解析到入库前的完整流程。
  1. def partition_document(file_path: str):对外统一入口,像整理师的“分拣台”,调用方不关心内部格式差异。
  2. ext = os.path.splitext(file_path)[1].lower()按扩展名识别格式,决定把文件送到哪个解析通道。
  3. Element("Table", "Team | Owner | Seat\nTech | Alice | A301", page=2, source=file_path)表格被保留为独立元素,并携带页码和来源两个元数据,这就是“给箱子贴标签”。
  4. while i < total:用循环窗口遍历所有元素,逐个切块,对应“装箱”循环。
  5. i += chunk_size - overlap # 前进步长 = 块大小 - 重叠每次前进“块大小减重叠”,让相邻块共享一段内容,防止语义在接缝处断裂。
  6. chunks.append(elements[i: i + chunk_size])把当前窗口的元素作为一个块保存,之后便可批量送入 Embedding 模型。

常见误区

误区“解析文档不就是把 PDF 里的文字抽出来吗?用个 PDF 库就能搞定,何必这么大动干戈?”

正解提取文本只是第一步。真正的解析要识别版面结构:标题层级、段落边界、表格网格、图片位置、页眉页脚,并输出带类型的元素。好比搬家时把物品倒进箱子只是搬运,整理师还要分类、贴标签。没有结构的纯文本,切分时会把表格和正文搅在一起,检索照样不准。

为何常见:简单的文本型 PDF 用文本提取确实能应付,让人误以为所有文档都这么简单,直到遇到扫描件和复杂排版才翻车。

误区“把文档切成 50 个 token 的小块,检索肯定更精准,因为不会混入无关内容。”

正解块太小会切断上下文。比如“员工入职需提交体检报告”被拦腰切成两块,“体检报告”就失去了主语。切分应按元素边界进行,保持语义完整,通常 300–800 token 并带少量重叠。收纳箱太大会搬不动、噪音多,太碎则会拆散成套物品、语义残缺,合适才是关键。

为何常见:直觉上“越小越精确”,但忽略了 LLM 需要完整语义来判断相关性。

误区“表格和图片反正 LLM 也看不懂,解析时直接扔掉,只留文字就够了。”

正解表格是高密度信息载体,报销标准、合同金额都在里面,丢掉等于把“贵重物品”留在旧房子。Unstructured 会把表格转成 Markdown 表格文本,图片提取后配合描述文字,检索时按类型过滤,LLM 也能读懂结构化表格并给出精确回答。

为何常见:纯文本 RAG 也能回答不少问题,让人低估表格的价值;一旦遇到“出差补贴标准”这类问题就露馅了。

误区“Unstructured 解析出元素后,直接 embedding 入库就行,不需要再做任何处理。”

正解解析输出还需要清洗:去重、过滤页眉页脚与导航噪音、合并碎片段落,再做切分和元数据增强。整理师只是把东西分类装好,新房管家还要登记入册。解析和预处理是一整条流水线,跳过任何一环都会掉链子。

为何常见:官方 API 一步就能出结果,让人忽略了中间的质量损耗环节,直到检索结果飘忽不定才回头排查。

误区“反正都是文本,把 PDF、Word、HTML 都交给同一个解析函数不就行了?”

正解不同格式的存储方式差异巨大:PDF 有文本层和布局信息,DOCX 本质是 XML 包裹的段落结构,HTML 有标签层级,邮件有头部和附件。Unstructured 的 partition 就是自动识别格式并路由到专属解析器。正如整理师看到纸箱、信封、电子设备,会采用完全不同的打包方式。

为何常见:对常见纯文本 PDF 的经验被错误推广到所有格式,遇到 HTML 的导航噪音或 DOCX 的样式嵌套就无从下手。

面试题

Q1. partition 函数的核心职责是什么?

单选题 · easy

  • A.自动识别文件类型并路由到对应解析器← 正确答案
  • B.对所有文件统一使用 OCR 识别文字
  • C.将解析结果直接存入向量数据库
  • D.负责生成文档的嵌入向量表示

答案:A。partition 就像搬家整理师的分拣台:先判断文件类型,再路由到 PDF、DOCX、HTML 等专属解析器。OCR 只针对扫描件,入库和向量化是下游环节,均不属于 partition 的职责。

Q2. 扫描版 PDF 主要依赖哪种技术来提取文字?

单选题 · easy

  • A.OCR 光学字符识别← 正确答案
  • B.正则表达式匹配
  • C.JSON 数据序列化
  • D.数据压缩算法

答案:A。扫描版 PDF 本质是图片,没有文字层,必须用 OCR 把图像里的字“认”出来,就像整理师要先把塑封膜拆开才能读文件。正则、序列化、压缩都解决不了“图像变文字”的问题。

Q3. 切分文档时设置重叠(overlap)的主要目的是?

单选题 · mid

  • A.增加向量库的存储开销
  • B.防止语义在切缝处断裂← 正确答案
  • C.加快文档解析的整体速度
  • D.减少待存储的块的数量

答案:B。重叠区相当于箱与箱之间的缓冲垫,让相邻块共享一段内容,避免“员工入职需提交体检报告”被切成两块后语义残缺。增加存储开销是副作用而非目的,更不会加快解析或减少块数。

Q4. 下列哪一项是 Unstructured 输出的 Table 元素?

单选题 · mid

  • A.图片文件的二进制字节
  • B.带行列结构的表格文本← 正确答案
  • C.整张页面的截图缩略图
  • D.表格所在页的页眉信息

答案:B。表格解析会把网格还原为表头加数据行,再序列化成 Markdown 表格文本,供大模型直接阅读。图片字节、页面截图、页眉信息都不是 Table 元素的形态。

Q5. 文档解析质量会直接影响哪些环节?

多选题 · mid

  • A.向量检索的召回准确率← 正确答案
  • B.生成回答的事实依据← 正确答案
  • C.推理卡的显存占用
  • D.知识库的切分粒度← 正确答案

答案:ABD。解析决定元素质量和元数据,切分粒度、检索召回都建立在它之上;检索到的内容又决定大模型回答的事实依据。显存占用由模型参数量和推理框架决定,与解析质量无关。

Q6. chunk_size 设置过大时最典型的负面问题是?

单选题 · hard

  • A.单个块包含无关噪音过多← 正确答案
  • B.向量化的计算速度更快
  • C.检索的结果更加精准
  • D.元数据变得不再需要

答案:A。箱子太大,必然混入与问题无关的内容,向量表示被稀释,检索返回的块“大而不准”。块越大向量化越慢而非越快,检索精度下降而非上升,元数据依然重要。

Q7. 解析出的页眉页脚等噪音元素应如何处理?

单选题 · mid

  • A.作为检索的高权重内容
  • B.识别后过滤或降权← 正确答案
  • C.与正文随机混合切分
  • D.统一转换成图片存储

答案:B。页眉页脚反复出现、信息量极低,会让向量库充满重复噪音。整理师的做法是把这类物品单独放一边,不塞进正品箱。高权重、混合切分、转图片都会污染检索结果。

Q8. 元数据(标题、页码、来源)在 RAG 中的作用有哪些?

多选题 · hard

  • A.检索时按来源过滤候选文档← 正确答案
  • B.回答时提供可追溯的引用← 正确答案
  • C.直接替代向量相似度检索
  • D.按章节或类型做精细筛选← 正确答案

答案:ABD。元数据是箱子的标签:既能当过滤器缩小检索范围,也能在回答时给出原文出处。但它无法替代向量相似度本身——内容是否相关还得靠语义匹配,标签只能做加权和筛选。

Q9. 下列哪种文件通常不需要版面布局分析?

单选题 · easy

  • A.纯文本格式的 txt 文件← 正确答案
  • B.复杂多栏排版的 PDF
  • C.扫描图片型的历史档案
  • D.图文混排的杂志页面

答案:A。纯文本没有排版结构,直接按段落读取即可,不需要布局分析。多栏 PDF、扫描件、杂志页面都有复杂的空间布局,必须先通过版面分析才能正确还原阅读顺序。

Q10. 哪些步骤属于 RAG 的文档预处理阶段?

多选题 · mid

  • A.格式识别与元素提取← 正确答案
  • B.文本清洗与噪音过滤← 正确答案
  • C.按语义边界切分块← 正确答案
  • D.生成最终的回答文本

答案:ABC。预处理是“整理师”阶段:识别格式、提取元素、清洗噪音、切块打包,最终送入向量库。生成回答文本是大模型在检索之后做的事,不属于预处理范畴。