大模型RAG实战｜开源RAG引擎QAnything技术栈解析

近日，有道发布了QAnything 1.4.1。

这是一个开源的本地知识库RAG问答系统，支持用户上传多种格式的文档，以构建知识库，并采用两阶段检索机制及混合检索技术，提升检索效率和准确性。

来源：https://qanything.ai/

在本文中，我将基于对源码的分析，介绍QAnything的技术栈，探索其背后采用的技术组件及实现方法。

 1 

加载 Loading

将各种格式的文件加载与解析成文档（Document），始终是构建大模型RAG系统最重要的环节。

QAnything开源版本，基于Langchain的文件解析组件，提供了一个较为全面的方案，可支持以下10种文件或网页的解析，包括PDF、DOCX、TXT、JPG等。

1）网页URL

构造了MyRecursiveUrlLoader，用来爬取指定网页及该网页上的子链接，并通过Langchain的WebBaseLoader加载和提取爬取到的网页内容。

2）Markdown文件

直接使用Langchain的UnstructuredFileLoader处理.md文件。

3）TXT文件

直接使用Langchain的TextLoader处理.txt文件。

4）PDF文件

对PDF文件的处理，相对复杂一些。系统构造了UnstructuredPaddlePDFLoader，按照以下步骤处理PDF文件。

• 使用PyMuPDF模块（fitz），加载 PDF文件

• 将加载的PDF文件中的每一页，转成图片

• 通过PaddleOCR将图片识别成文本，输出到一个文本文件

• 使用unstructured库的partition_text处理该文本文件
  

5）JPG/JPEG/PNG文件

图片首先通过PaddleOCR识别成文本，然后使用UnstructuredFileLoader加载。

6）DOCX文件

直接使用Langchain的UnstructuredWordDocumentLoader处理。

7）XLSX文件

原本直接使用Langchain的UnstructuredExcelLoader，后来改为pandas的read_excel方法，将Excel文件中的每一个sheet，处理和输出为CSV文件，然后构造了CSVLoader，将CSV文件的每一行中的内容，以键值对的形式，输出为一个document。

8）CSV文件

使用上述的CSVLoader处理。

9）PPTX文件

直接使用Langchain的UnstructuredPowerPointLoader处理。

10）EML文件

直接使用Langchain的UnstructuredEmailLoader处理。

值得注意的是，以上文件加载与解析方式来自于开源版本。

据官网称，其企业版针对所有文档类型做更精细的单独优化，解析结果均为markdown格式，可以更好地保留原有的结构。

 2 

转换 Transformation

此阶段将文件或网页URL加载解析后生成的文档（Document）分割为文本块（Chunk），步骤如下。

1）中文文本分割

针对以上网页URL、TXT文件、PDF文件、JPG/JPEG/PNG文件、DOCX文件，系统加载文件后，还会基于Langchain的 CharacterTextSplitter，构造和使用ChineseTextSplitter。其主要功能是根据中英文标点符号，对文本进行切割。

2）中文标题增强

如果开启了中文标题增强（默认关闭），系统基于Langchain Document构建了zh_title_enhance。其功能为判断文字是否为标题，如果是标题，则将该文字的元数据标注为标题，并把后续文字与此标题关联。

3）进一步分块

如果单个文档（Document）的文本长度大于800 tokens，则利用Langchain的RecursiveCharacterTextSplitter将其拆分成多个Chunk，参数chunk_size=400。

4）添加元数据

每个文档的metadata里注入来源文件的信息，包括file_id和file_name。

 3 

嵌入 Embedding

此阶段对上述转换分割好的文本块进行向量嵌入（Vector Embedding），并存储到向量数据库中，创建索引，以供未来检索。

1）嵌入模型

QAnything使用有道自研的嵌入模型bce-embedding-base_v1，可使用本地或线上版本。通过嵌入模型将每个文本块生成向量表示，保存到向量数据库中。

2）向量数据库

系统使用的向量数据库为Milvus。通过嵌入模型生成向量后，系统把上述每个文本块的文本内容、对应的向量、以及文件ID、文件名、文件路径等元数据信息，保存到向量数据库中，以支持向量语义检索。

3）关键词检索

如果开启混合检索，那么文本块的数据同时也需要保存在ElasticSearch中，以支持BM25关键词检索。

4）知识库管理

系统采用MySQL存储知识库相关信息，主要有三个表：用户表、知识库表和文件表，以方便管理知识库。

 4 

检索 Retrieval

如何完整和准确地检索到问题相关的内容，是RAG系统的关键。

QAnything采用了两阶段检索的方式。

第一阶段引入了混合检索（Hybrid Search），提升检索的准确性。

第二阶段的重排（Rerank）解决知识库内容越来越多时，相似内容造成的干扰所导致的检索退化问题。

1）第一阶段：混合检索

QAnything的第一阶段检索可以采用混合检索的方式。首先，针对查询中的关键字，通过ElasticSearch使用BM25算法进行检索，快速找到包含特定关键字的内容。

同时，系统通过Milvus向量数据库中进行向量语义相似度检索，找到与查询语义最相关的文档部分（TOP_K）。系统将两次检索到的文档片段合并，交给第二阶段检索。

2）第二阶段：重排序

QAnything通过一个重排（Rerank）步骤，结合前述混合检索结果，通过重排模型bce-reranker-base_v1，对检索到的文档片段进行综合排序。重排可以优化检索结果的相关性，确保最终提供给大模型生成回答时，用的是最准确的信息。

 5 

生成 Generation

检索到准确的信息后，生成阶段的重点是大语言模型和相应的Prompt优化。

1）大语言模型（LLM）

QAnything开源版本采用的是微调后的通义千问Qwen 7B，由FastChat提供API服务。系统同时也支持其他与OpenAI-API兼容的大模型服务，包含Ollama、通义千问DashScope等。

选择QWen 7B作为基座模型的原因是，基座模型应支持中英文、至少具备4K上下文窗口的模型，且能在单块GPU上部署，优先考虑7B以下参数规模的模型以便于未来在消费级硬件上部署。

进行微调的原因有两个，一是增强模型对含有专业术语或通俗缩写的理解，二是提升大模型在参考信息不足时的诚实度。

2）提示词（Prompt）

QAnything采用的Prompt模板如下：

"""参考信息：{context}我的问题或指令：{question}请根据上述参考信息回答我的问题或回复我的指令。前面的参考信息可能有用，也可能没用，你需要从我给出的参考信息中选出与我的问题最相关的那些，来为你的回答提供依据。回答一定要忠于原文，简洁但不丢信息，不要胡乱编造。我的问题或指令是什么语种，你就用什么语种回复,你的回复："""

可以看出，给出的指令比较清晰，适合RAG应用场景。

以上，总结了QAnything从文件加载、转换、嵌入、索引、存储、检索到生成，整个RAG链路所采用的技术组件与方法。如有兴趣进一步了解，建议你深入研究QAnything的源码。