本章节介绍 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": "会根据设备尺寸自动调整" } ]}该方案融合了句子级处理、上下文记忆、结构化输出、错误控制与功能扩展等多项关键技术，具备良好的通用性与工程实用价值，可有效提升知识检索问答的准确率和用户体验。
葡萄城 AI 搜索地址： ai-assist.grapecity.com.cn/
