在当前LLM（大型语言模型）的应用浪潮中，检索增强生成（RAG）已成为相对成熟且应用最广的落地模式之一。但无论是从最初的Naive RAG演进到Advanced RAG，还是最新的Agentic RAG，其核心都离不开一个关键底座：知识库管理系统。
对于面向落地应用RAG的产品经理和工程化技术人员而言，如果只是停留在对LLM能力或RAG流程的表面理解，很难在真实复杂的业务场景中建立起高效、稳定的智能咨询系统。
笔者结合项目落地经验，以及对RAGFlow、dify、AnythingLLM等主流知识库产品的使用实践，从产品逻辑和技术架构层面，将RAG知识库产品抽象提炼为清晰的三层架构，进行一次系统性的解构分析。
理解这三层架构及其核心组件，是确保RAG系统在工程化实践中实现高精准度、高效率的技术基础，接下来本文自底向上逐层展开介绍。
注，本文播客内容如下：
知识存储层：RAG系统的地基存储结构
知识存储层是整个RAG知识库系统的地基，它必须能够应对RAG所需的三种核心数据类型和存储模式。
1. 结构化存储 (Structured Storage)
结构化存储主要用来支撑文档和知识的列表管理，记录知识的基本信息和系统级元数据（如文档名、上传时间、所属业务等）以及文档和知识分块之间的映射关系等。
可选组件：关系型数据库如MySQL、MariaDB、PostgreSQL等是主流选择。
2. 向量库存储 (Vector Database Storage)
这是RAG进行“检索”的核心支撑。知识库中所有经过向量化处理的知识分块，都存储在这里，用于执行相似度搜索。
可选组件：工业级向量库如Milvus、ChromaDB、Weaviate，兼容倒排索引的ElasticSearch、以及轻量级的Faiss等。
3. 对象存储 (Object Storage)
对象存储用于安全、可靠地存储用户上传的原始文档（如PDF、PPT、DOC等），以便在检索后能够支撑用户查看原文，进行事实核验和信息溯源。
可选组件：MinIO、Ceph、OSS（阿里云）、S3（AWS）等。
工程洞察： RAG知识库的架构复杂性在于，它并非单一数据库系统，而是必须协同工作的三种存储模式的集合。确保这三种存储之间的数据一致性和高可用性，是工程团队的首要挑战。
知识处理层：从原始文档到向量分块的“炼丹炉”
知识处理层是RAG系统进行“知识提炼”的核心引擎。它决定了知识分块（Chunk）的质量，直接影响最终的检索召回率和精准度。
1. 文件解析与OCR识别
RAG系统首先需要处理各种格式的文档（如PDF、PPT、DOC）。文件解析器负责将这些复杂格式转化为Markdown等易于处理的文本内容。如果文档中含有图片或扫描件，则需要调用OCR（光学字符识别）模型进行文字识别。
可选组件：文件解析器包括MinerU、DeepDoc、DifyExtractor等。OCR识别模型可选择PaddleOCR、RapidOCR等。
2. 分块切分（Chunking）策略的深度博弈
分块切分是RAG工程化中的核心难点，它决定了知识的粒度。如果分块太小，信息上下文丢失；分块太大，向量化精度下降。
当前业界的分块算法已从简单的固定长度切分，发展到更高级的策略：
结构化切分：按特殊字符、标题样式、章节目录、段落等进行切分，保留了文档的结构信息。
语义切分：基于语义关联度进行动态切分，确保每个分块内部语义的完整性。
工程洞察：优秀的知识库产品（如RAGFlow）都会允许用户对Chunking策略进行精细化调整，以适应不同业务文档（如代码、财报、法律文件）的特点，详见《RAGFlow切片方法深度实测：Manual/Book/Laws等对比分析》这篇文章。
3. 向量化处理
切分好的知识分块需要被转化为高维向量语义，才能被向量库存储和检索。向量模型（Embedding Model）的选择直接决定了语义理解的深度和检索的有效性。
可选模型：当前主流的高性能模型包括BGE-M3、Qwen3-Embedding等。
知识管理与检索层：从知识收录到输出的业务闭环
最上层的知识管理与检索层，是用户直接交互和工程运营的界面，它承担着从知识收录到知识输出的业务闭环。
1. 知识管理：从上传到“打标”的知识收录过程
知识管理功能涵盖了文件上传、解析、分块等过程。但对于追求高精准度的工程项目而言，知识打标（Metadata Tagging）是PM和工程师必须深度关注的重点。
如我们在上篇文章《知识打标和元数据维护》中所述，纯粹依赖向量语义相似度的检索，容易在大型知识库中造成结果泛滥。通过在知识管理层引入元数据（Metadata），可以标记知识的“业务领域”“时间范围”“适用对象”等，可以实现对知识的结构化管理和定向检索。
另外在解析、分块、打标等技术措施之上，要保障知识的质量，还需要做好知识的运营管理，详见《RAG准确率上不去？别只关注技术》这篇文章内容。
2. 知识检索：混合检索的必然趋势
知识检索是RAG的最终输出环节。虽然语义检索是RAG的核心，但纯语义检索在面对术语、ID或新名词时往往表现不佳。因此，成熟的RAG知识库系统必须支持更多的检索模式：
全文检索（Full-text Retrieval）： 依靠倒排索引，解决关键词的精确匹配问题。
混合检索（Hybrid Retrieval）： 将语义检索与全文检索结合，平衡召回率和精准度。
工程洞察： 在混合检索的基础上，通常要进一步通过“元数据筛选”的方式，大幅度减少了待检索的分块数量，在牺牲少量召回率的基础上，极大地提升了最终结果的精准率（Precision）。这在工程实践中是高价值的取舍。
总结：系统性认知是RAG落地的基石
RAG技术已经度过了“能用”阶段，正在迈向“用好”阶段。对于面向落地应用的PM和工程技术人员而言，必须跳出对LLM本身的迷恋，转向对知识库这一关键底座的系统性认知。
本文梳理三层架构图（知识存储、知识处理、知识管理与检索），绝不是简单地堆叠技术组件，而是帮助读者在这三层架构的每个环节都做出精细化的工程设计和产品选择，希望对您构建真正具备商业价值、能稳定运行的智能咨询和内容生成类AI系统有所帮助。
本文总结：结合项目落地经验，以及对RAGFlow、Dify、AnythingLLM等主流知识库产品的使用实践，从产品逻辑和技术架构层面，将RAG知识库产品抽象提炼为清晰的三层架构，进行一次系统性的解构分析。
本系列说明：基于项目实践经验，总结RAG知识库产品体系架构，分享知识存储设计、分片策略和打标机制等基础技术，梳理上层知识运营管理业务逻辑，欢迎读者持续关注完整合集《RAG实践》。
—End—
