RAG 技术路线知识库搭建流程主要包括以下步骤：
在构建知识库的过程中，还涉及到文档解析环节，即将各种类型的资料（包括但不限于 Word、PDF、Excel 和图片等）转换成文字，为后续流程奠定基础。针对图片一般使用 OCR 图像识别技术，针对文档一般将其转换成 Markdown 格式。文档解析完成之后，要进行预处理。
基于 Coze 的知识库问答是典型的 RAG 方案，其重要一环是文档切片（Segment），但 RAG 方案存在一些缺点，如跨分片总结和推理能力弱、文档有序性被打破、表格解析失败等。
因为利用大模型的能力搭建知识库本身就是一个RAG技术的应用。所以在进行本地知识库的搭建实操之前，我们需要先对RAG有一个大概的了解。以下内容会有些干，我会尽量用通俗易懂的描述进行讲解。我们都知道大模型的训练数据是有截止日期的，那当我们需要依靠不包含在大模型训练集中的数据时，我们该怎么做呢？实现这一点的主要方法就是通过检索增强生成RAG（Retrieval Augmented Generation）。在这个过程中，首先检索外部数据，然后在生成步骤中将这些数据传递给LLM。我们可以将一个RAG的应用抽象为下图的5个过程：文档加载（Document Loading）：从多种不同来源加载文档。LangChain提供了100多种不同的文档加载器，包括PDF在内的非结构化的数据、SQL在内的结构化的数据，以及Python、Java之类的代码等文本分割（Splitting）：文本分割器把Documents切分为指定大小的块，我把它们称为“文档块”或者“文档片”存储（Storage）：存储涉及到两个环节，分别是：将切分好的文档块进行嵌入（Embedding）转换成向量的形式将Embedding后的向量数据存储到向量数据库检索（Retrieval）：一旦数据进入向量数据库，我们仍然需要将数据检索出来，我们会通过某种检索算法找到与输入问题相似的嵌入片Output（输出）：把问题以及检索出来的嵌入片一起提交给LLM，LLM会通过问题和检索出来的提示一起来生成更加合理的答案[heading2]文本加载器（Document Loaders）[content]文本加载器就是将用户提供的文本加载到内存中，便于进行后续的处理
旁白为了更好的学习RAG，你决定自己亲身走一遍整个流程。因为你坚信：读十遍不如实践一遍[heading2]文档解析[content]为了构建你的客服机器人，你开始收集各种资料，其中包含了公司的产品（外贸大师）的使用手册：PDF格式公司层面沉淀的各种FAQ：Word文档和一些图片你自己日常沉淀的客户常问的问题：Excel表格整理出来这些文档之后，一个关键的问题摆在了面前，如何处理这些资料呢这里面就用到了RAG中的第一个流程：文档解析简单来讲文档解析：就是将各种类型的资料（包括但不限于：Word、PDF、Excel和图片等）转换成文字，为后续的流程奠定基础。针对图片一般使用OCR图像识别技术针对文档一般都会将其转换成Markdown格式文档解析完成之后，我们要进行预处理。
基于Coze的知识库问答是典型的RAG方案，其重要一环就是文档切片（Segment）。然而，不管是单分片是800 token还是2000 token，都显著暴露了RAG方案的缺点：跨分片总结和推理能力弱。这是基于RAG方案自身原理导致的。文档有序性被打破。这是基于RAG方案自身原理导致的。表格解析失败。最后一点很诧异。虽然在业内把PDF解析为结构化文本，本就是一个难题。但是Coze对PDF的解析结果甚至不如直接用pypdf这个开源Python组件解析的效果好。说明Coze这个产品对细节的打磨还不够好。在这里我们不讨论如何组织文档形式，从而可以更好的分片。后面我会专门研究这块，并产出教程。