RAG 知识库：从传统检索到智能问答的技术演进
本文基于一次内部技术分享整理而成，系统介绍 RAG（检索增强生成）知识库的核心概念、技术原理与实践经验。
一、什么是知识库
结构化知识集合
知识库本质上是一个结构化的知识集合。例如企业内部知识库，将产品手册、流程规范等信息分类存储，方便员工快速检索使用。
智能交互载体
在 AI 时代，知识库不再是静态的文档仓库，而是一个智能交互载体 —— 它可以解析用户问题，调取相关资料生成精准回答，就像客服系统自动回复常见咨询一样。
知识库的核心价值
- 提升企业协作效率：集中管理项目文档，帮助团队成员快速获取所需信息，促进跨部门协作更加顺畅高效
- 加速新员工培训：存储产品信息与操作指南，为新员工提供自主学习资源，帮助其快速熟悉业务流程和岗位要求
- 保障知识资产沉淀：归档代码注释与解决方案，确保核心技术知识得到有效保存，减少因人员变动带来的知识损失风险
二、传统知识库检索的困境
在 AI 技术成熟之前，知识库检索主要依赖以下几种方式：
传统检索方法
| 方法 | 描述 | 典型场景 |
|---|---|---|
| 关键词匹配检索 | 需精确输入关键词才能找到结果，同义词或模糊表述无法识别 | CNKI 等学术数据库 |
| 分类目录导航 | 采用层级分类目录，用户需逐层点击才能找到资源 | 早期门户网站（如雅虎） |
| 人工索引卡片 | 纸质索引卡片记录书籍主题、作者等信息，需人工翻查 | 20 世纪图书馆 |
传统检索的三大局限
- 关键词匹配僵化：用户输入”数据备份”无法匹配到”备份策略”文档，需反复调整搜索词
- 语义理解缺失：检索”合同纠纷时效”时，系统仅返回含相同词组的文档，无法关联”诉讼时效”等近义术语
- 跨库整合困难：纸质档案与电子文档独立存储，用户需分别检索不同系统，获取完整资料耗时极长
三、RAG 知识库的核心概念
什么是 RAG
检索增强生成（Retrieval Augmented Generation，RAG） 是一种通过将外部知识整合到生成过程中，增强大语言模型（LLM）性能的技术方案。
简单来说，RAG = 检索（Retrieval） + 增强（Augmented） + 生成（Generation）。
它的核心思路是：不让 LLM 仅凭”记忆”回答问题，而是先从知识库中检索相关内容，再将检索结果作为上下文交给 LLM 生成回答。
下图展示了 RAG 的整体架构：
图：RAG 系统架构 —— 从文档入库到查询生成的全流程
RAG 的两大核心流程
流程一：文档向量化（离线索引）
原始文档 → 文档解析 → 文档分块 → 向量化 → 存入向量数据库 |
图：文档向量化流程时序图 —— 用户上传文档后，系统依次完成解析、分块、向量化并存入向量数据库
流程二：查询处理（在线检索）
用户提问 → 查询向量化 → 向量检索 → 获取相关文档块 → 组合 Prompt → LLM 生成回答 |
图：查询处理时序图 —— 用户提问后，系统经过问题优化、向量检索、ReRank 重排序，最终由 LLM 生成回答
四、RAG 核心技术详解
4.1 文档解析
文档解析是从原始文档中提取结构化或非结构化数据的过程，目的是将文档内容转化为可被后续处理（如分块、向量化、检索）的格式。
主流解析方式对比
| 解析方式 | 技术原理 | 优势 | 劣势 | 适用场景 | 费用 |
|---|---|---|---|---|---|
| Native 解析 | 基于文档原生格式的解析器，直接提取文本、表格、图像等结构 | 速度快，资源消耗低；保留原始排版 | 对复杂格式（扫描 PDF、嵌套表格）支持差 | 纯文本或结构化文档（合同、报告） | 本地解析，免费 |
| MinerU 解析 | 基于深度学习模型（如 LayoutLM、TableMaster）解析文档布局 | 高精度表格识别；支持复杂排版；输出结构化数据 | 计算资源消耗高；对非表格内容解析较弱 | 含复杂表格的文档（财务报表、科研论文） | 私有化部署 |
| DeepDoc 解析 | 结合 OCR（如 Tesseract）与 NLP 模型，解析非结构化文档 | 支持扫描件和图像文档；可处理手写体、多语言 | OCR 精度依赖图像质量；处理速度较慢 | 扫描件、图像文档（发票、合同扫描件） | 私有化部署 |
| VLM 模型解析 | 基于视觉-语言模型（如 LayoutLMv3、Donut）联合理解文档 | 端到端理解文档图像与文本；多模态能力 | 模型体积大，推理成本高 | 多模态文档（含图表、公式的论文） | 调用第三方模型服务 |
| Doc2x 解析 | 将文档转换为中间格式（如 Markdown、JSON），再结构化处理 | 支持多格式转换；易于后续处理 | 转换可能丢失复杂格式 | 需将文档转为结构化格式的场景 | 调用第三方 SaaS 服务 |
如何选择解析方式
- 纯文本或结构化文档 → 优先 Native 解析，速度快且资源消耗低
- 复杂表格和结构化数据 → 使用 MinerU 解析，高精度识别表格和复杂排版
- 扫描件和图像文档 → 选择 DeepDoc 解析，支持手写体和多语言
- 多模态文档和高精度语义解析 → 使用 VLM 模型解析，理解复杂文档内容
- 多格式转换和结构化处理 → 使用 Doc2x 解析，便于转为中间格式
4.2 文档分块
文档分块是将长文档分割为较小的、语义连贯的单元（chunk）的过程。
好的分块策略需要：
- 精确识别核心观点与论据
- 建立语义关联
- 确保文档结构完整性
分块质量直接影响后续检索的精度 —— 块太大会引入噪音，块太小会丢失上下文。
4.3 向量检索（语义检索）
向量检索是 RAG 的核心检索方式，基于语义相似度而非关键词匹配。
工作原理
- 向量表示：将文本转化为高维向量。例如 OpenAI 的
text-embedding-ada-002模型可将文本转为 1536 维向量，实现语义的数字化表示 - 相似度计算：通过余弦相似度计算向量间的夹角，余弦值 0.8 以上判定为高度相似
- 检索流程：先对知识库文本向量化建库，用户查询时生成查询向量，通过最近邻搜索快速匹配 TopK 相似结果，耗时通常在毫秒级
向量索引
实践中常使用 HNSW（Hierarchical Navigable Small World） 算法构建向量索引。HNSW 是一种专为高维向量数据设计的近似最近邻搜索（ANN）索引结构，可以在海量数据中快速找到语义最相近的内容。
实践：向量存储表结构
下图展示了一个典型的向量存储表结构设计。核心字段包括 chunk_id（关联分块）、content_vector（存储向量化结果）、team_id（租户隔离）等：
图：向量存储表结构 —— content_vector 字段使用 PostgreSQL 的 vector 类型存储嵌入向量
实践：HNSW 索引创建
在 PostgreSQL 中，可以通过 pgvector 扩展创建 HNSW 索引，实现高效的向量近似搜索：
图：使用 pgvector 创建 HNSW 索引，参数 m=16 控制图的连接度，ef_construction=64 控制构建时的搜索范围
实践：向量检索代码实现
以下是向量检索的核心代码，展示了从查询向量化到数据库检索的完整流程：
图：向量检索实现 —— 将查询文本向量化后，通过 SQL 查询在向量数据库中进行相似度匹配
4.4 全文检索
全文检索是传统但依然有效的检索方式，基于关键词匹配。
核心技术
- 索引构建：使用 Elasticsearch 或 PostgreSQL 插件构建倒排索引，将文档拆解为关键词-文档 ID 映射，检索响应速度可提升至 0.1 秒内
- 分词处理：采用 jieba 等分词器对中文内容进行切分，如”人工智能应用”拆分为”人工”、”智能”、”应用”等词条，提升匹配精度
- 相关性排序：通过
fts_vector算法计算文档与检索词的相关度，按分数排序返回结果
实践：全文检索表结构
全文检索需要额外的分词字段来支持关键词匹配。下图展示了分块表中用于全文检索的字段设计：
图：分块表结构 —— 包含 fts_vector 等用于全文检索的字段
实践：jieba 分词与 tsvector 生成
利用 PostgreSQL 的 jieba 分词插件，可以自动为不同类型的分块（QA 模式、图片模式、普通模式）生成 tsvector：
图：通过 GENERATED ALWAYS AS 计算列，根据分块类型（QA/图片/普通）自动拼接不同字段进行 jieba 分词
实践：全文检索代码实现
以下是全文检索的核心代码实现，展示了如何利用 PostgreSQL 的 tsvector 进行关键词匹配和相关性排序：
图：全文检索实现 —— 使用 jieba 分词对查询进行处理，通过 tsvector 匹配并按相关度排序
4.5 混合检索
混合检索是将向量检索（语义相似度）与全文检索（关键词匹配）结合的方案，通过加权评分或排序模型，提升检索的准确性与覆盖率。
核心机制
- 双路检索：同时执行向量检索和全文检索，获得两组结果
- RRF 融合排序：使用 RRF（Reciprocal Rank Fusion） 算法 —— 一种无监督的多结果排序融合算法，将多个独立检索系统的排序结果合并为一个综合排序列表
- 重排序（ReRank）：通过重排序模型对融合后的结果再次打分，进一步优化排序质量
混合检索的优势在于：语义检索擅长理解用户意图，全文检索擅长精确匹配关键词，两者互补可以显著提升检索效果。
实践：混合检索配置
下图展示了一个实际的混合检索配置界面，可以灵活调整语义检索和全文检索的权重比例，以及 ReRank 模型参数：
图：混合检索配置 —— 支持语义检索（权重 0.58）与全文检索（权重 0.42）的比例调节，以及 ReRank 重排序模型选择
实践：混合检索代码实现
以下代码展示了混合检索的实现逻辑，包括双路检索的并行执行和 RRF 融合排序：
图：混合检索实现 —— 并行执行向量检索与全文检索，通过 RRF 算法合并结果
五、RAG 知识库的优化方向
RAG 技术仍在快速演进，以下是一些主要的优化方向：
| 优化阶段 | 技术方向 |
|---|---|
| 基础优化 | 语义分块、上下文增强检索、上下文标题、文档增强 |
| 查询优化 | 查询转换、假设文档生成（HyDE） |
| 检索优化 | 混合检索、重排序、相关片段扩展（RSE） |
| 生成优化 | 上下文压缩、反馈循环 |
| 高级架构 | 自适应 RAG、自反思 RAG（Self RAG）、纠错 RAG（CRAG） |
| 知识增强 | 知识图谱、层次索引 |
每个方向都在解决 RAG 流程中的不同痛点：
- 语义分块：让分块边界更贴合语义，而非机械切割
- HyDE：先让 LLM 生成一个假设性回答，用这个回答去检索，往往比直接用问题检索效果更好
- Self RAG：让模型学会自我反思检索结果是否足够，不够则继续检索
- CRAG：在生成过程中检测并纠正潜在的知识错误
- 知识图谱：为文档间的关系建立显式图结构，增强推理能力
如何评估 RAG 效果
评估 RAG 系统效果时，最常用的两个指标是准确率（Precision）和召回率（Recall）：
图：准确率 P = A/(A+B)，即检索到的结果中有多少是相关的；召回率 R = A/(A+C)，即所有相关内容中有多少被检索到了
- 准确率关注”检索结果的质量” —— 返回的内容是否都是有用的
- 召回率关注”检索结果的完整性” —— 有用的内容是否都被找到了
在实际应用中，需要根据业务场景在两者之间取得平衡。
总结
RAG 知识库技术正在从”能用”走向”好用”。从最初的简单向量检索，到混合检索、重排序，再到自适应和自反思 RAG，每一步进化都在让知识库更准确、更智能地服务于用户的真实需求。
对于正在建设企业知识库的团队，建议的技术路线是：
- 起步阶段：选择合适的文档解析方式 + 基础 RAG（向量检索）
- 优化阶段：引入混合检索 + 重排序模型
- 进阶阶段：根据业务场景逐步引入高级 RAG 架构
关键不在于追求最复杂的方案，而在于针对业务场景选择最合适的技术组合。