基于RAG的三国演义问答系统实战与优化

RIDERPRINCE

1. 项目概述：基于《三国演义》的RAG问答系统实战

去年在做一个历史知识问答项目时，我发现传统的关键词检索对"草船借箭发生在哪一回"这类问题完全无能为力。这促使我开始探索如何将RAG(检索增强生成)技术应用于中文长文本场景。经过三个月的迭代，我们最终在《三国演义》上实现了Recall@5=0.8的效果。这个系统最特别之处在于采用了"章回识别+滑动窗口"的混合切分策略，完美适配了古典小说的结构特点。

这个方案的核心价值在于：

对中文长文本的适配：专门针对古典小说章回体结构设计的切分策略
完整的工程闭环：从数据预处理到效果评估的全流程可复现
实战调优经验：总结了批量插入、维度对齐等工程细节的避坑指南

2. 混合切分策略设计与实现

2.1 章回识别：结构化提取的关键

处理《三国演义》这类章回体小说时，我发现直接使用固定窗口切分会破坏原有的章节结构。比如"温酒斩华雄"这个典故，如果切分时正好把"温酒"和"华雄"分到两个chunk中，检索效果就会大打折扣。

我们的解决方案是采用两级切分：

python复制# 章回识别正则表达式（简化版）
chapter_pattern = r'^正文\s+?第[一二三四五六七八九十百千0-9]+[回章节].*$'

# 实际处理中还加入了以下增强：
1. 处理"第XX回"和"第XX章"等变体
2. 排除目录中的章节标题
3. 处理章节标题中的特殊符号（如◆等）

2.2 滑动窗口参数调优实战

在确定窗口大小时，我们对比了多种配置：

窗口大小	重叠大小	Recall@5	特点
512	80	0.53	容易丢失关键事件
256	64	0.67	部分典故仍会断裂
128	32	0.80	最佳平衡点
64	16	0.75	过于碎片化

经过实测，128/32的配置在保持语义完整性和检索精度之间取得了最佳平衡。这里有个实用技巧：可以先抽取100个典型事件，人工检查不同参数下的切分效果。

3. 工程实现关键细节

3.1 向量数据库选型与配置

我们选择Qdrant主要基于以下考量：

对批量写入的良好支持
丰富的过滤条件（这对章节检索特别重要）
轻量级的部署方案

创建集合时需要特别注意：

bash复制# 正确做法：根据实际向量维度创建集合
PUT /collections/sanguo {
    "vectors": {
        "size": 768,  # 必须与嵌入模型输出维度一致
        "distance": "Cosine"
    }
}

# 常见错误：维度不匹配会导致召回异常

3.2 批量写入的兼容性处理

在实际部署中，我们发现不同版本的Qdrant对批量写入的支持有差异。最终实现的写入逻辑包含自动降级机制：

java复制// 伪代码：带降级的写入逻辑
try {
    // 首选单点格式
    response = qdrantClient.upsert(singlePointFormat); 
} catch (QdrantException e) {
    if (e.contains("missing field ids")) {
        // 降级到batch格式
        response = qdrantClient.upsert(batchFormat);
    }
}