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

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

1. 原始思路

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

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

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

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

短文档处理问题

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

长文档处理瓶颈

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

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

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

1. 短文档精准控制：
   如何建立约束机制，确保生成的问答对严格限定在原文信息范围内，杜绝信息编造？

2. 长文档完整覆盖：
   如何突破数量限制，确保长篇文档中的每个关键细节都能被准确提取并转化为问答对，实现无遗漏的知识点覆盖？

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

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

核心流程如下：

1. 使用中文句子分割器将文档拆分为句子列表；
2. 计算总句数 N；
3. 动态设置期望生成数量 QA_Count = N，并注入提示词中；
4. 模型根据明确指示生成不少于 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}    # 局部生成
]

处理流程总结：

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

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

4. 详细实现

（1）文本预处理流程

（2）统一输出格式

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

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

（3）JSON 提取与错误处理

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

1. 优先提取 JSON 块：尝试从响应中提取被 ```json ... ``` 包裹的标准 JSON 内容；
2. 强制转换为 JSON 对象：如果未提取到 JSON 内容，就将响应全文当做 JSON，尝试强制解析为 JSON 对象；
3. 解析失败则回退正则提取：使用正则表达式手动匹配 "Question" 和 "Answer" 等字段，构造结构化输出；
4. 异常捕获：通过 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. 工程建议

⚠️ 注意事项：小模型的知识面小，易产生幻觉，建议在 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": "会根据设备尺寸自动调整"
        }
    ]
}

该方案融合了句子级处理、上下文记忆、结构化输出、错误控制与功能扩展等多项关键技术，具备良好的通用性与工程实用价值，可有效提升知识检索问答的准确率和用户体验。

葡萄城 AI 搜索地址： https://ai-assist.grapecity.com.cn/