一、引言
小说知识库的质量，很大程度上取决于文本分块的质量。如果分块太大，单个块会包含过多不相关信息，检索精度下降；如果分块太小，又可能破坏语义完整性，导致检索结果无法支撑有效的RAG应用。在长文本的小说场景中，找到合适的分块策略尤为关键。
StoryVerse的文本处理流程经历了多轮迭代，从最初的简单按字符切分，到后来基于段落的语义保留策略，每个设计决策都经过仔细权衡。本文将从多个维度剖析这些设计思路。
二、文本预处理流程
2.1 文件读取与基础清洗
当用户上传小说文件后，系统首先将其读取为纯文本，并进行初步清洗。在实际处理中，需要考虑各种编码问题、换行符差异、特殊字符等。虽然当前实现相对简洁，但其中蕴含着重要设计考虑。
文本清洗有几个基本目标：一是统一换行符格式，将Windows的\r\n和老式Mac的\r统一为\n；二是移除无效的控制字符，保留有意义的文本内容；三是处理BOM（Byte Order Mark）标记，避免解析问题。这些虽然是细节工作，但对后续处理影响重大。
2.2 文本长度限制策略
系统对处理文本进行长度限制，这是一个重要的权衡：
private static final int MAX_PROCESSING_CHARS = 20000;
private String limitProcessingText(String fullText) {
if (fullText == null) {
return "";
}
if (fullText.length() <= MAX_PROCESSING_CHARS) {
return fullText;
}
return fullText.substring(0, MAX_PROCESSING_CHARS);
}限制为20000字符的设计考虑了多重因素：首先，LLM的上下文窗口有限，过长的文本会导致处理成本过高或超时；其次，大多数小说的开篇部分已经足够引入主要角色和世界观设定，这对MVP阶段的角色扮演功能已经够用；最后，这也为后续的渐进式处理预留了空间。
在更完善的版本中，可以考虑先处理前20000字符建立基础知识库，然后在后台继续处理后续内容，逐步丰富知识库。这种策略平衡了即时可用性和完整性。
三、分块策略实现
3.1 基于段落的分块算法
核心的分块逻辑围绕着保持段落完整性设计：
private static final int MAX_CHUNK_CHARS = 1200;
private List<NovelKnowledgeClient.PlotChunk> buildPlotChunks(String fullText) {
List<NovelKnowledgeClient.PlotChunk> chunks = new ArrayList<>();
// 按段落分割，过滤空行
List<String> paragraphs = fullText.lines()
.map(String::trim)
.filter(line -> !line.isBlank())
.toList();
if (paragraphs.isEmpty()) {
throw new BusinessException("解析后的小说文本为空");
}
// 合并段落形成块
StringBuilder buffer = new StringBuilder();
int chunkIndex = 0;
for (String paragraph : paragraphs) {
// 避免截断段落
if (!buffer.isEmpty() && buffer.length() + paragraph.length() + 1 > MAX_CHUNK_CHARS) {
chunks.add(new NovelKnowledgeClient.PlotChunk(buffer.toString(), chunkIndex++));
buffer.setLength(0);
}
if (!buffer.isEmpty()) {
buffer.append('\n');
}
buffer.append(paragraph);
}
if (!buffer.isEmpty()) {
chunks.add(new NovelKnowledgeClient.PlotChunk(buffer.toString(), chunkIndex));
}
return chunks;
}这个算法有几个精妙之处。首先，它按段落作为基本单位，确保单个段落不会被拆分到两个不同的块中。段落通常表达一个完整的意思，保持段落完整性对语义理解至关重要。
其次，分块决策是在添加新段落前进行的：if (!buffer.isEmpty() && buffer.length() + paragraph.length() + 1 > MAX_CHUNK_CHARS) 。这个判断确保只有在添加当前段落会导致溢出时，才将缓冲区内容作为新块，然后开始新的缓冲区。这样可以尽可能地保持段落间的联系。
最后，为每个块分配chunkIndex，记录块在原文中的顺序。这个索引在后续检索中很有价值，因为有时最相关的信息可能不只是最相似的，还可能出现在相近的位置。
3.2 分块大小的经验选择
1200字符的限制是经过实验调整的结果。对于中文文本，1200字符大致相当于200-300个词语，这既足够包含一个完整的场景或对话，又不会让单个块包含太多不同的主题。
分块大小的选择需要考虑多种因素：Embedding模型的最大输入长度、向量检索的精度、下游LLM能处理的上下文窗口大小等。例如，如果使用的Embedding模型支持更大的输入，可能可以适当增加分块大小，以获得更好的语义连贯性。
值得注意的是，不同类型的文本可能需要不同的分块策略。对于对话密集的小说，可能需要更小的块来捕捉特定对话；对于描述性强的小说，可能需要稍大的块来保留环境和氛围描写。
四、知识提取中的文本处理
4.1 世界观提取中的文本选择
在构建世界观总结时，系统使用了小说全文但进行了截断：
MAX_WORLD_SUMMARY_CHARS = 12000
world_text = self._chat_completion(
system_prompt=(
"你是小说知识库整理助手。请基于小说正文提炼世界观总结。"
"输出一段中文正文，不要标题，不要列表，不要解释。"
),
user_prompt=(
f"小说标题：{request_model.novel_title}\n\n"
f"小说全文：\n{self._truncate_text(request_model.full_text, self.MAX_WORLD_SUMMARY_CHARS)}"
),
)限制为12000字符的设计是因为世界观设定通常出现在小说的前半部分，特别是开篇章节。通过限制输入长度，既控制了LLM调用成本，又避免了后面内容对世界观提取的干扰。
截断方法本身也有设计：
def _truncate_text(self, text: str, max_chars: int) -> str:
if len(text) <= max_chars:
return text
return text[:max_chars] + "\n...[truncated]"在截断处添加标记，让LLM知道文本被截断了，这可以微妙地影响模型行为，使其更谨慎地总结，避免做出超出给定文本范围的断言。
4.2 角色识别中的摘要策略
角色识别使用了不同的文本选择策略，它不仅使用全文摘要，还提供前几个剧情块的摘录：
MAX_CHARACTER_FULL_TEXT_CHARS = 6000
MAX_CHARACTER_CHUNKS = 8
MAX_CHARACTER_CHUNK_CHARS = 240
plot_excerpt = "\n\n".join(
f"[chunk {item.chunk_index}] {self._truncate_text(item.text, self.MAX_CHARACTER_CHUNK_CHARS)}"
for item in request_model.plot_chunks[: self.MAX_CHARACTER_CHUNKS]
)这种双管齐下的策略很重要。全文摘要提供了整体背景，而剧情块摘录则提供了更具体的角色出场和互动的细节。每个剧情块被截断为240字符，这样可以在有限的上下文窗口中提供更多样化的片段，增加模型识别到所有主要角色的机会。
为每个块添加[chunk index]前缀也很有意义，这可以让模型知道文本的相对顺序，可能有助于理解角色的出场顺序和关系发展。
五、向量化前的文本规范化
5.1 向量生成中的文本处理
在生成向量之前，系统不需要复杂的预处理，因为Embedding模型通常能够处理原始文本。但在构建本地兜底方案的摘要时，系统进行了空白字符规范化：
private String truncateText(String text, int maxChars) {
if (text == null || text.isBlank()) {
return "";
}
String normalized = text.replaceAll("\\s+", " ").trim();
if (normalized.length() <= maxChars) {
return normalized;
}
return normalized.substring(0, maxChars) + "...";
}将所有空白字符序列替换为单个空格，确保文本的格式一致性。这对本地兜底很重要，因为它们直接向用户展示，格式整齐度会影响用户体验。
5.2 稳定ID生成中的文本处理
另一个重要的文本处理是用于生成稳定向量ID的slugify方法：
def _slugify(self, value: str) -> str:
normalized = unicodedata.normalize("NFKC", value).strip().lower()
slug = re.sub(r"[^0-9a-z\u4e00-\u9fff]+", "-", normalized)
return slug.strip("-") or "unknown"这里使用了unicodedata.normalize("NFKC")进行Unicode归一化，这确保了看起来相同但编码不同的字符（如全角和半角字符）能生成相同的ID。将文本转为小写，确保不区分大小写的一致性。
正则表达式[^0-9a-z\u4e00-\u9fff]+只允许数字、小写字母和中文字符，其他所有字符都被替换为连字符。这种设计既保持了足够的可识别性，又避免了特殊字符导致的问题。
六、分块质量的优化方向
6.1 基于语义边界的分块
当前基于段落和长度的策略虽然有效，但仍有改进空间。更智能的分块策略可以尝试识别文本中的自然语义边界，比如章节划分、场景转换、视角切换等，在这些边界处切分，而不是仅仅依赖长度。
例如，可以检测章节标题、明显的场景转换指示（如空行分隔、时间地点标记）等，优先在这些地方进行切分，使每个块更可能包含一个完整的语义单元。
6.2 重叠分块策略
在检索中，相关信息可能出现在分块边界附近。重叠分块（Overlapping Chunks）策略让相邻块有一定重叠，这样即使切分不完美，重要信息也更可能完整地出现在至少一个块中。
典型的重叠大小可以是分块大小的10-20%。当然，这会增加存储和计算成本，需要在质量和效率之间进行权衡。
6.3 分层分块设计
另一个方向是分层分块：同时维护几个不同粒度的分块方案，如短段落级、场景级、章级。在检索时，可以根据查询性质选择合适粒度的块进行搜索，或者融合不同粒度的检索结果。这种设计提供了更大的灵活性。
七、总结
文本分块和预处理是构建高质量知识库的基石，其重要性不亚于Embedding模型选择或向量数据库设计。StoryVerse的实现虽然简洁，但每个决策都有其考虑：基于段落的分块策略保持了语义完整性，精心选择的长度限制平衡了多种需求，各种文本规范化处理确保了系统的鲁棒性。
分块工作看似平凡，实则直接影响检索质量，进而影响整个RAG应用的效果。通过持续优化分块策略，结合语义边界识别、重叠分块、分层设计等技术，可以不断提升知识库的质量，为用户提供更准确、更相关的知识检索服务。