近日，有道发布了QAnything 1.4.1。
这是一个开源的本地知识库RAG问答系统，支持用户上传多种格式的文档，以构建知识库，并采用两阶段检索机制及混合检索技术，提升检索效率和准确性。
在本文中，我将基于对源码的分析，介绍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的源码。
