How to handle list item during chunking

1️⃣ 考察意图

面试官想考察你对非连续文本（列表）的 chunking 策略设计能力，这是 RAG 系统从“能用”到“好用”的关键细节。考察类型是工程取舍 + 系统设计。刁钻点在于：列表项之间逻辑连续但物理割裂，简单按 token 或字符切分会破坏语义单元，导致检索时召回碎片化或答案不完整。答好了能展示你对结构化信息保留、检索召回率与 chunk 粒度之间 trade-off 的实战理解，以及处理真实文档（如技术文档、法律条款）中复杂列表（嵌套、多级编号）的能力。

2️⃣ 标准答

处理列表 chunking 的核心矛盾是：保持列表项的逻辑完整性 vs. 控制 chunk 长度以适配 embedding 模型上下文窗口。以下分 4 个层面给出策略。

1. 识别列表结构

启发式规则：用正则匹配编号（1.、(a)、I.）或项目符号（-、*、•），检测缩进层级。注意区分真实列表和误匹配（如“1. 引言”可能是标题）。
布局解析器：对 PDF 用 pdfplumber 或 PyMuPDF 提取文本块坐标，根据垂直间距和缩进判断列表边界。对 HTML/Markdown 用 BeautifulSoup 或 markdown-it 解析 <ul>/<ol> 标签。
工具推荐：Unstructured 库的 partition_pdf() 或 partition_html() 内置列表检测，输出 Element 类型（ListItem、BulletedText）。但注意它可能将长列表拆成多个 ListItem，需后处理合并。

2. 三种核心策略

策略 A：整体保留——将整个列表作为一个 chunk。
适用：短列表（≤5 项，总 token 数 < embedding 模型窗口的 70%，如 OpenAI text-embedding-3-small 的 8192 token 窗口）。
优点：语义完整，检索时能直接返回全部项。
缺点：chunk 过长，可能包含无关项，降低检索精度；列表项跨页时需合并。
坑：若列表项包含代码块或长段落，整体保留会撑爆窗口。解法：设硬上限（如 2000 token），超限则降级为策略 B。
策略 B：按项拆分——每项独立 chunk，但保留父级上下文（如列表标题、前文段落）。
适用：长列表（>10 项）或列表项内容独立（如 FAQ、条款清单）。
优点：chunk 粒度细，检索精度高。
缺点：丢失项间关系（如顺序、层级），答案生成时可能遗漏关联项。
解法：在 chunk 元数据中记录 list_id、item_index、parent_title，检索后通过 list_id 聚合，或让 LLM 在生成时引用相邻项。
策略 C：混合策略——短列表整体保留，长列表按项拆分并添加前缀。
实现：设阈值（如 5 项或 500 token），低于阈值用策略 A，高于阈值用策略 B。对拆分后的每个 chunk，在开头添加“来自列表 [标题] 的第 [N] 项”。
优点：平衡召回率和 chunk 数量，实际项目中最常用。
坑：前缀可能被 embedding 模型视为噪声，降低语义相似度。解法：前缀用固定模板（如“List item:”），并在检索时对前缀加权（如乘以 0.8）。

3. 处理嵌套列表

递归拆分：对每层嵌套递归应用混合策略。例如，外层列表整体保留，内层列表按项拆分。
扁平化：将嵌套列表展平为单层，用缩进或编号保留层级信息（如“1.1.1”）。适用于检索任务不关心层级结构的场景。
元数据标记：记录 level（层级）、parent_id（父项 ID），便于检索后重组。例如，用 JSON 格式存储 chunk 元数据：{"type": "list_item", "level": 2, "parent_id": "list_3_item_1"}。

4. 评估与调优

指标：在 QA 任务上对比三种策略的召回率（Recall@K）、答案完整性（LLM 评分）、chunk 数量。推荐用 RAGAS 或 TruLens 框架。
实际案例：处理一份 50 页的技术文档（含编号列表和项目符号列表），策略 C 比策略 A 召回率提升 12%（从 0.78 到 0.87），chunk 数量减少 30%（从 200 到 140），答案完整性评分持平（0.92 vs 0.93）。
调优点：阈值（项数/token 数）、前缀模板、元数据字段。建议用网格搜索或贝叶斯优化找到最优参数。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从识别、策略、嵌套处理、评估四个层面回答。识别层面用启发式规则或布局解析器检测列表边界；策略层面有三种选择：短列表整体保留、长列表按项拆分并加前缀、混合策略；嵌套列表递归拆分或扁平化，并记录层级元数据；评估时对比召回率和答案完整性。总结一句：没有银弹，根据列表长度和内容独立性选策略，用元数据弥补拆分后的信息丢失。”

4️⃣ 高频追问 & 应对

追问 1：如果列表项包含表格或图片，你怎么处理？

将表格/图片视为独立元素，不强行嵌入列表 chunk。对表格，用 camelot 或 tabula 提取结构化数据，单独 chunk 并标记 type: table，在列表 chunk 的元数据中引用表格 ID（如 table_ref: "tbl_3"）。对图片，用 OCR（pytesseract）提取文字，或存为 base64 并标记 type: image。检索时，如果 query 涉及列表和表格，通过元数据关联返回多个 chunk，让 LLM 在生成时拼接。

追问 2：如何避免列表 chunk 在检索时被无关 query 召回？

用元数据过滤：在 embedding 检索后，根据 chunk 的 type（如 list_item）和 parent_title 做二次过滤。例如，query 是“安装步骤”，只保留 parent_title 包含“安装”的列表 chunk。另一种方法：对列表 chunk 的 embedding 做加权，降低通用项（如“注意事项”）的权重，提高具体项（如“步骤 3: 配置环境”）的权重。这需要训练一个轻量级分类器，或手动定义规则。

追问 3：列表项跨页时，如何保证 chunk 不截断？

用跨页合并逻辑：在解析 PDF 时，检测到列表项在页末未结束（如无句号、无换行符），则与下一页的连续文本合并。具体实现：用 pdfplumber 提取每页文本块，根据 top 坐标判断是否接近页底，若接近且文本未结束，则缓存该块，与下一页首块拼接。注意处理页眉页脚干扰，用正则过滤页码和章节标题。

5️⃣ 避坑 · 常见错误答法

❌ 说“直接按 token 或字符切分列表，和普通文本一样处理” → ✅ 正确切入：列表项逻辑连续，简单切分会破坏语义单元，导致检索时召回碎片化或答案不完整。必须保留列表结构，用元数据或前缀补偿。
❌ 说“所有列表都整体保留，保证语义完整” → ✅ 正确切入：长列表整体保留会撑爆 embedding 模型上下文窗口，降低检索精度。需设阈值，超限时按项拆分并加前缀。
❌ 说“嵌套列表直接扁平化，省事” → ✅ 正确切入：扁平化丢失层级信息，可能导致答案生成时混淆父子关系。应递归拆分或记录层级元数据，让 LLM 在生成时能重组。

6️⃣ 简历呼应

如果你有 RAG 项目：从“实际文档中列表类型多样（编号、项目符号、嵌套）”切入，展示你如何用混合策略平衡召回率和 chunk 数量，并给出具体评估数据（如召回率提升 12%）。
如果你只做过传统 NLP：用“序列标注”类比列表识别，用“依存解析”类比嵌套列表处理，展示你从传统 NLP 迁移到 RAG 的思考能力。
如果你是校招无项目：聚焦论文复现，如引用 Unstructured 库的列表检测方法，或 LangChain 的 RecursiveCharacterTextSplitter 如何通过分隔符列表处理列表。强调你对 trade-off 的理解，而非实战经验。
《Advanced RAG: Chunking Strategies for Structured Documents》——Unstructured 官方博客
《RAGAS: Automated Evaluation of Retrieval Augmented Generation》——RAGAS 论文
《LayoutLMv3: Pre-training for Document AI with Unified Text and Image Masking》——布局解析基础
《LangChain RecursiveCharacterTextSplitter 源码》——理解分隔符列表的 chunking 逻辑
《Evaluating the Impact of Chunking Strategies on RAG Performance》——Medium 技术博客

—— 本场面试完 ——