GC-QA-RAG 智能问答系统的文档切片

葡萄城技术团队

1086人浏览 · 2025-06-03 10:10:29

葡萄城技术团队 · 2025-06-03 10:10:29 发布

本章节介绍 GC-QA-RAG 智能问答系统的文档切片原理，即如何将原始文档的知识点切片后存入向量数据库。

1. 原始思路

将整个文档作为输入，交由大语言模型自动生成问答对（QA Pairs），以支持后续知识检索和问答系统的构建。

## 任务要求
提取下面文档中的知识点为 QA 问答对，按照指定格式输出。
{Content}

## 输出格式
[{"Question":"string","Answer":"string"}]

然而，在实际应用中我们发现该方案存在显著局限性。具体表现为：

短文档处理问题

当处理仅包含 1-2 句话的简短文本（如产品功能说明、API 简要描述）时，模型倾向于生成超出原文信息范围的问答对，出现信息编造现象。例如，对"支持多种数据格式"这样的简单描述，模型可能虚构出具体格式列表等原文未提及的内容。

长文档处理瓶颈

对于技术白皮书等长篇文档，模型输出的问答对数量存在明显天花板效应：

稳定输出区间：10-15 个 QA 对
超出阈值后出现：
- 问题重复（相同知识点不同表述）
- 信息选择性丢失（忽略重要内容细节）
- 答案偏离（过度泛化或补充外部知识）

这些局限性直接影响了知识库的完整性和准确性，促使我们深入解决两个核心问题：

短文档精准控制：
如何建立约束机制，确保生成的问答对严格限定在原文信息范围内，杜绝信息编造？
长文档完整覆盖：
如何突破数量限制，确保长篇文档中的每个关键细节都能被准确提取并转化为问答对，实现无遗漏的知识点覆盖？

2. 短文档处理策略：基于句子计数的动态控制

针对短文档，我们提出一个强假设：每个句子对应一个独立知识点，可以被转化为一个 QA 对。由此设计一套基于句子数量预估生成 QA 数量的方法。

核心流程如下：

使用中文句子分割器将文档拆分为句子列表；
计算总句数 N；
动态设置期望生成数量 QA_Count = N，并注入提示词中；
模型根据明确指示生成不少于 QA_Count 的 QA 对。

示例提示词模板如下：

single_group_template = """
需要针对文档生成不少于{{QA_Count}}个问答对...
文档内容：{{Content}}
"""

中文文本处理优化：

考虑到中文技术文档中可能存在代码片段或特殊符号（如“.”出现在变量名中），我们在分句时做了以下处理：

主要使用“。”、“？”、“！”等作为断句标志；
对包含特殊字符的语句进行保留不切分处理；
自动过滤空白句与无效段落。

该策略显著提升了短文档的信息抽取完整性与准确性。

3. 长文档处理方案：两阶段记忆-聚焦对话机制

对于长文档，直接截断会导致信息缺失，而一次性全文输入又容易造成注意力扩散、生成内容片面。我们提出一种创新性的两阶段记忆-聚焦式对话机制。

其核心思想是：

在第一轮对话中模拟“长期记忆”，向模型植入全文背景；在第二轮只发送当前片段，引导其聚焦于局部内容进行 QA 提取。

实现方式如下：

第一阶段：知识记忆（用户指令）

multi_group_template1 = "请记住下面的技术文档..."

第二阶段：聚焦生成（用户指令）

multi_group_template2 = "提取当前文档片段的 QA 问答对..."

构造完整的对话历史记录：

messages = [
    {"role": "user", "content": self.prompt_config.multi_group_template1},   # 全文记忆
    {"role": "assistant", "content": self.prompt_config.assistant_response}, # 响应确认
    {"role": "user", "content": self.prompt_config.multi_group_template2}    # 局部生成
]

处理流程总结：

将文档按句子分组（默认每组 10 句）；
对每一组执行上述两阶段对话；
合并所有分组的结果，形成最终的 QA 库。

这种机制不仅解决了上下文覆盖问题，还提高了模型在局部内容中的专注度与生成质量。

4. 详细实现

（1）文本预处理流程

步骤	描述
HTML 解析	使用 BeautifulSoup 提取 class=“main__doc” 的正文内容
句子分割	按照中文标点（句号、问号等）进行分句，并过滤空白句
动态分组	默认每组 10 个句子，若某组不足 5 句则合并至前一组

（2）统一输出格式

每个分组的输出均为标准化 JSON 格式，包含两个关键字段：

{
  "Summary": "介绍活字格的布局类型及特点",
  "PossibleQA": [
    {
      "Question": "活字格支持哪些布局方式？",
      "Answer": "支持响应式布局、固定布局等三种方式"
    },
    ...
  ]
}

（3）JSON 提取与错误处理

为应对大模型生成 JSON 时可能出现的格式错误（如引号未闭合、括号不匹配等），我们设计了 extract_qa_object 函数进行容错处理。

优先提取 JSON 块：尝试从响应中提取被 ` ```json … ````包裹的标准 JSON 内容；
强制转换为 JSON 对象：如果未提取到 JSON 内容，就将响应全文当做 JSON，尝试强制解析为 JSON 对象；
解析失败则回退正则提取：使用正则表达式手动匹配 "Question" 和 "Answer" 等字段，构造结构化输出；
异常捕获：通过 try-except 结构防止模型生成失败导致程序中断；

try:
    response = chat_to_llm(prompt)
    return extract_qa_object(response)
except Exception as e:
    logger.error(f"Error generating QA: {e}")
    return {"Summary": "", "PossibleQA": []}

（详细实现可参考开发教程中的相关章节或项目源码。）

5. 功能扩展

除了基础 QA 生成，我们进一步实现了多个实用扩展功能：

1. 摘要生成（Summary）

每个分组生成一个简洁摘要；
存入向量化数据库 payload 字段；
提升检索匹配精度与模型理解效率。

2. 答案扩展（Full Answer）

对关键 QA 对生成更详细的解释；
同样存入向量化数据库 payload 字段；
用于前端展示或辅助模型回答复杂问题。

3. 同义问法扩增（Question Variants）

为每个问题生成多种不同表述；
显著提升检索系统的召回率；
适用于用户提问多样化的场景。

6. 工程建议

维度	推荐值
模型选择	至少 70B 参数规模（如 Qwen2.5-72B）
Temperature	0.7（平衡创造性与严谨性）
Top-P	0.7（控制输出多样性）
最大 token 数	≥2048（保证输出长度）

⚠️ 注意事项：小模型的知识面小，易产生幻觉，建议在 QA 质量评估中加入人工抽检机制，以评估技术限制。本项目的整体错误率控制在 5%~10%，可供参考。

7. 适用性与扩展性分析

本方案具有良好的通用性与适应性，适用于：

文档类型广泛：技术文档、法律条规、知识百科、FAQ 页面等；
规模弹性良好：受限于模型最大上下文长度（通常 8k~128k tokens）；
易于适配扩展：通过修改提示词模版即可支持不同业务需求。

8. 实际应用案例

以下是一个完整的处理流程示例：

# 输入文档
doc = "活字格支持三种布局方式...响应式布局会根据设备尺寸自动调整...固定布局保持像素级精确..."

# 分组处理
groups = split_text_into_sentence_groups(doc)

# QA 生成
generator = QAGenerator()
result = generator.generate_by_groups(doc, groups)

# 输出结果
{
    "Summary": "介绍活字格的布局类型及特点",
    "PossibleQA": [
        {
            "Question": "活字格支持哪些布局方式？",
            "Answer": "支持响应式布局、固定布局等三种方式"
        },
        {
            "Question": "响应式布局有什么特点？",
            "Answer": "会根据设备尺寸自动调整"
        }
    ]
}