给你一部长篇小说，怎么做文档切割
1️⃣ 考察意图
面试官想考察你对非结构化长文本的工程化处理能力，而非简单背概念。刁钻点在于：长篇小说有章节、段落、对话、叙事流等复杂结构，直接按固定 token 切会破坏语义连贯性，导致 RAG 检索时上下文碎片化。答好了能展示你对 chunking 策略的 trade-off 理解（如粒度 vs 完整性）、对语义分割工具（如 Semantic Chunker）的实战经验，以及如何用评估指标（如 Recall@5、答案连贯性）量化切割质量。这是系统设计题，需要从业务场景出发，给出可落地的方案。
2️⃣ 标准答
长篇小说切割的核心是保留叙事连贯性，同时适配下游 RAG 的检索粒度。我会分三步走：先分析文本结构，再设计切割策略，最后评估优化。
第一步：分析文本结构
- 长篇小说有天然层级：卷 > 章 > 节 > 段落 > 句子。章节是语义单元，段落是逻辑单元。
- 对话密集区（如《红楼梦》的日常对白）需要更细粒度切割，避免跨角色混切；而描写段落（如《百年孤独》的开篇）可保留较大 chunk。
- 坑：直接按固定 token 数（如 512）切，会把章节标题和正文分离，导致检索时丢失章节上下文。
第二步：设计切割策略（分层递进）
- 策略 1：基于章节的粗粒度切割用正则或 NLP 库（如 spaCy 的
sentencizer）识别“第 X 章”等标题，按章节切分。每个 chunk 保留章节标题作为元数据。为什么这么做：章节是作者设计的语义边界，切割后 chunk 内部逻辑完整，检索时能直接定位到相关章节。Trade-off：章节长度不均（如《三体》第一部长达 30 万字，短章仅 2000 字），长章需进一步切分。 - **策略 2：基于语义的细粒度切割（Semantic Chunker）**对长章，先用固定窗口（如 256 tokens）滑动，计算相邻窗口的 embedding 余弦相似度（用
text-embedding-3-small）。当相似度低于阈值（如 0.6）时，在此处切分。实际落地的坑：阈值设置敏感，过低导致 chunk 过大（如 5000 tokens），过高则切碎对话。解法：用验证集（如 100 个问答对）调参，或采用自适应阈值（基于窗口内相似度标准差）。工具：LangChain 的SemanticChunker或 LlamaIndex 的SentenceSplitter，但需自定义 embedding 模型和阈值。 - **策略 3：重叠切割（Overlap）**每个 chunk 保留前后 10-20% 的 overlap（如 50 tokens），确保跨 chunk 的实体（如人物名“贾宝玉”）和指代（如“他”）不丢失。为什么这么做：RAG 检索时，overlap 能提升召回率（Recall@5 提升 5-10%），但增加索引存储（约 20% 开销）。
第三步：评估与优化
- 离线评估：构建 50-100 个问答对（如“林黛玉进贾府时看到了什么？”），用不同切割策略建索引，计算 Recall@5 和答案连贯性（人工评分）。经验数据：章节切割 + 语义细切 + overlap 的组合，在《红楼梦》测试集上 Recall@5 达 0.85，优于纯固定窗口（0.72）。
- 在线优化：如果检索结果碎片化（如答案跨两个 chunk），引入 reranker（如 Cohere rerank）重排，或动态合并相邻 chunk。
总结：核心是“先粗后细，保留语义边界，用 overlap 兜底”。不要迷信单一工具，要根据小说类型（如悬疑小说需保留伏笔连贯性）调整策略。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，分析小说结构，识别章节和段落作为天然边界；第二，设计分层策略——先按章节粗切，再对长章用语义相似度细切，并加 overlap 保留上下文；第三，用 Recall@5 和答案连贯性评估，调阈值和 chunk 大小。总结一句：切割不是一刀切，而是基于语义和结构的工程权衡。”
4️⃣ 高频追问 & 应对
追问 1：如果小说是《百年孤独》这种魔幻现实主义，对话和描写混杂，怎么调参？
应对策略：这类文本语义跳跃大，固定阈值容易误切。解法：用动态阈值——计算滑动窗口内 embedding 相似度的标准差，当标准差 > 0.3 时（表示语义变化剧烈），降低切分阈值（如从 0.6 降到 0.5）。或者改用递归切割：先用段落分割，再对长段落（> 300 tokens）用语义切分。实际测试中，动态阈值在《百年孤独》上 Recall@5 提升 8%。
追问 2：你提到 overlap 提升召回，但索引存储增加 20%，怎么权衡？
应对策略：存储成本可接受（20% 增量在百万级 chunk 下约 2GB），但检索延迟会因重复 chunk 增加。优化：只对关键 chunk（如包含高频实体）加 overlap，或压缩 overlap 长度（从 20% 降到 10%）。更激进的做法：用 HNSW 索引的
ef_search参数控制召回，减少 overlap 依赖。
追问 3：如果小说是《三体》这种多线叙事，章节间有跳跃，怎么保证切割后检索不丢失跨章线索？
应对策略：引入“全局元数据”——为每个 chunk 打标签（如“人物：叶文洁”、“事件：三体游戏”），检索时用元数据过滤。同时，在切割时保留章节标题和摘要（如用 LLM 生成 50 字摘要），作为 chunk 的前缀。这样即使跨章，检索也能通过元数据关联。实际落地中，元数据索引使跨章问答准确率提升 15%。
5️⃣ 避坑 · 常见错误答法
- ❌ “直接按固定 token 数切，比如 512 tokens，简单高效。”→ ✅ “固定 token 切会破坏章节和段落边界，导致检索时上下文碎片化。应该先基于结构粗切，再对长块语义细切。”
- ❌ “用 LangChain 的 RecursiveCharacterTextSplitter 就行，默认参数。”→ ✅ “默认参数（chunk_size=1000, chunk_overlap=200）对长篇小说不够用。需要根据小说类型调参，比如对话多的小说 chunk_size 设小（500），描写多的小说设大（1500）。”
- ❌ “切割后直接建索引，不用评估。”→ ✅ “必须用问答对评估切割质量，否则上线后检索效果差。至少用 Recall@5 和人工评分验证，否则可能白费功夫。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“我在项目中用 Semantic Chunker 处理了 10 万字小说，对比固定切割，Recall@5 提升 12%”切入，展示调参和评估经验。
- 如果你只做过传统 NLP：用“文本分割类似句子分割任务，但长篇小说需要层级结构——我借鉴了篇章分析中的 RST 理论，按修辞关系切分”类比，体现迁移能力。
- 如果你是校招无项目：聚焦“我复现了 LlamaIndex 的 SentenceSplitter，并在《红楼梦》上做了对比实验，发现章节切割 + overlap 最优”，展示动手能力和论文阅读（如《Text Segmentation by Topic》）。
- 《Text Segmentation by Topic: A Survey》（论文，综述文本分割方法）
- LangChain 官方文档：RecursiveCharacterTextSplitter 与 SemanticChunker 对比
- LlamaIndex 博客：Chunking Strategies for RAG（实战调参指南）
- 《Attention Is All You Need》中位置编码对长文本的影响（理解 chunk 顺序）
- 博客：How to Chunk Text for RAG（含代码示例和评估指标）