技术架构

架构概览 - 基于 QA 预生成的 RAG 方案

本系统采用典型的 RAG（Retrieval-Augmented Generation）三阶段架构，分为构建（ETL）、检索（Retrieve）和生成（Generate）三个核心阶段：

构建（ETL）：从原始文档中提取知识，生成结构化问答对，并向量化后存储至向量数据库；
检索（Retrieval）：在用户提问时，结合关键词与语义理解、混合排序策略，快速定位最相关的知识点；
生成（Generation）：基于大语言模型和检索结果，生成自然语言回答。

整个流程通过模块化设计，实现了高可用性、可扩展性和良好的工程落地能力。

知识构建（ETL）

ETL 是整个系统的基础环节，其目标是将非结构化的原始文档转化为可用于检索的知识点。该过程主要包括以下几个步骤：

获取文档

知识来源包括公司官网的帮助文档、技术论坛中的求助帖和教程贴等：

官方帮助文档：约 4,000 篇
技术论坛 - 求助中心：约 50,000 条帖子
技术论坛 - 专题教程：约 4,000 条帖子

后续计划拓展以下内容源：

API 接口文档
公开课视频文本
产品插件说明、应用市场商品资料
成功案例分析

支持定时增量爬取机制，对于更新频率较高的内容设置更短的抓取周期，确保知识库的时效性。

切片（Chunking）

不同于传统的段落切分方式，我们采用了基于大语言模型的“QA 切片”方法，即将文档内容转化为若干组问答对（QA Pairs）。这种方式更加聚焦于实际的知识点，提升了后续检索和生成的有效性。

具体流程如下：

使用 LLM 将原始文档转换为结构化问答对；
对生成的 QA 进行质量校验，人工抽检部分样本以检验准确率；
输出标准化 JSON 格式，便于后续加工处理。

相较于粗粒度的文本段落，QA 对形式更贴近用户的真实查询意图，有助于提高检索系统的召回率与相关性。

文本嵌入（Text Embedding）

为了提升检索的准确性与鲁棒性，我们采用“双向向量化”策略，同时使用稀疏向量（BM25）和稠密语义向量（Dense Vector）进行多维度表示。

除此之外，我们在向量化过程中还引入了多项增强机制：

Summary 概要生成

为每个 QA 对匹配一段由大语言模型生成的简要摘要，描述其所在文档上下文的背景信息，用于辅助后续生成模型更好地理解上下文。

Full Answer 扩展

针对重要或高频问题，额外生成一个更详细的答案版本，作为 payload 存储，用于前端展示或为生成环节提供更丰富的上下文支持。

Prefix 前缀机制

为了避免不同文档中相似问题造成的“空间混叠”现象，我们将 QA 所在文档所属的类别和标题作为前缀添加到原始文本前再进行向量化。

示例模板：

[Category/Title] + Question
[活字格/连接到外部数据库/连接到 Oracle] 连接到 Oracle 数据库前需要先做什么？

此策略能有效区分语义相同但应用场景不同的问题，提升检索的精准度。

向量字段

共生成四类向量特征：

Prefix_Question_Dense
Prefix_Answer_Dense
Prefix_Question_Sparse
Prefix_Answer_Sparse

Payload 字段

每个知识条目包含如下元数据，供后续检索和生成使用：

Question：用户可能提出的问题
Answer：简洁标准答案
FullAnswer：详细解释版本
Summary：上下文摘要
Url：原文链接
Title：文章标题
Category：所属分类
Date：创建时间（Unix 时间戳）

通过以上设计，我们的向量化方案兼顾了关键词匹配和语义理解，显著提高了检索效果，同时也为生成阶段提供了更丰富的上下文支撑。

Payload 示例

{
    "Question": "连接到 Oracle 数据库前需要先做什么？",
    "Answer": "需要先配置 Oracle，配置完成才能连接 Oracle。",
    "FullAnswer": "# 连接 Oracle 数据库前的准备工作 在连接到 Oracle 数据库之前，需要完成一些必要的配置步骤......",
    "Summary": "本文档介绍了如何连接到 Oracle 数据库，包括配置 Oracle 的步骤以及在活字格中连接 Oracle 的具体操作......",
    "Url": "https://www.grapecity.com.cn/solutions/huozige/help/docs/connecttoexternaldatabase/connecttooracle",
    "Title": "连接到 Oracle",
    "Category": "活字格中文文档/第十五章 连接到外部数据库"
    "Date": 1746093654
}

检索机制（Retrieval）

检索阶段的目标是从知识库中找出与用户问题最相关的知识条目。我们采用多通道混合检索策略，并结合 RRF（Reciprocal Rank Fusion）算法进行融合排序，确保返回结果的相关性与多样性。

混合检索策略

我们采用两种主流检索方式：

稀疏检索（BM25）：基于倒排索引和关键词频率，适用于关键词明确的查询；
稠密检索（Dense Vector）：基于语义向量，适用于模糊语义理解和复杂表达。

每一路检索单独获取 TopK=40 条结果，最终通过 RRF 算法进行融合排序，选取最终 TopK=8 条最优结果返回。

检索输入路径如下：

UserInput → [Question(BM25 & Dense), Answer(BM25 & Dense)]{TopK=40} → RRF 融合排序 → Hits{TopK=8}

我们同时检索 QA 的问题和答案字段，以提升整体召回率。例如，如果用户的问题表述偏向答案内容，也能被正确匹配并返回。

目前未引入时间衰减因子，因为多个版本的产品文档共存，用户可能仍然需要旧版本的信息。

生成机制（Generation）

在生成阶段，系统基于检索出的相关知识，结合大语言模型的能力，生成自然流畅的中文回答。

输入结构

系统接收以下两个主要输入：

用户问题（User Input）
检索结果（Hits from Retrieval）

将这些信息整合进提示词中，输入给大语言模型进行推理和回答生成。

提示词示例（Prompt Template）

"""
你正在和用户对话，请综合参考上下文以及下面的用户问题和知识库检索结果，回答用户的问题。回答时附上文档链接。
## 用户问题
{keyword}

## 知识库检索结果
{hits_text}
"""

思考模式（Reasoning Mode）

除直接输出答案外，我们还支持“思考模式”，即由推理型 LLM 明确输出中间推理过程，增强用户对回答的信任感和透明度。

多轮问答支持

系统支持多轮对话场景，能够根据历史对话上下文，自动识别用户当前真正想问的问题。

实现流程如下：

历史对话 → [LLM提示词] → 改写问题 → [改写问题 + 检索结果] → [LLM提示词] → 生成最终答案

通过以下提示词引导模型识别用户意图：

"""
你是一个问题生成器，你需要从下面的对话中识别出用户想要查询的问题，直接输出该文本，该文本将用于在知识库中检索相关知识。
## 对话内容
{contents}
"""

总结

通过上述技术架构的详细设计与实现，我们构建了一套完整的基于 QA 预生成的 RAG 知识检索与问答系统。从文档的解析、QA 对的生成、向量索引的构建，到多路混合检索和基于大模型的答案生成，各模块协同工作，实现了高质量的知识服务输出。

在整个流程中，我们不仅引入了先进的文本处理与语义理解技术，还通过 Prefix 机制、Full Answer 扩展、RRF 融合排序等手段，显著提升了系统的准确性、鲁棒性与实用性。

展望下一阶段：工程落地方案

在完成了核心功能的设计与验证之后，下一步我们将重点探讨本系统的 工程化落地实现方案，确保其在实际生产环境中的可用性、稳定性与扩展性。

在《工程方案》一章中，将详细介绍以下内容：

1. 系统部署架构

整体系统结构图（包括知识库构建模块、检索服务、生成服务、LLM 中间件等）
各组件之间的调用关系与数据流向
微服务拆分与容器化部署建议

2. 核心组件说明

知识检索与问答服务：基于 Qdrant 的向量检索 + MySQL 的元数据辅助查询
Server 应用：对外提供统一 API 接口，协调检索与生成流程
Client 应用：集成到产品 UI 中的智能问答组件
ETL 应用：定时任务驱动的 QA 提取与索引更新模块
第三方 LLM 服务接入：如通义千问、DeepSeek 等，支持灵活配置与切换

3. 性能优化策略

异步处理与缓存机制（如 Redis 缓存高频问题结果）
向量索引预加载与内存映射优化
检索与生成任务的负载均衡设计

4. 限流与容错机制

请求频率控制（Rate Limiting）与令牌桶算法实现
LLM 调用失败重试、超时熔断与降级策略
错误日志采集与监控告警系统集成

5. 用户体验增强措施

响应延迟优化（如预加载、异步加载部分上下文）
多轮对话状态管理与意图识别优化
可视化反馈机制（用户可对回答质量进行评分或纠错）