深度干货|万字长文解读向量数据库的前世今生----Zilliz官网公众号
什么是腾讯云向量数据库 cloud.tencent.com/document/pr…
blog.zihanjian.com/article/225…
zhuanlan.zhihu.com/p/675509396 blog.csdn.net/onebe/artic… 不同数据如何RAG blog.csdn.net/onebe/categ… LLM专栏
什么是RAG
RAG 检索增强生成（Retrieval Augmented Generation），已经成为当前最火热的LLM应用方向之一。
RAG解决了LLM的核心痛点
RAG直接解决了标准LLM在企业应用中存在的固有局限性：
- 知识冻结： LLM的知识被冻结在其训练数据的时间点。RAG通过在推理时注入实时的、最新的信息来解决这个问题 。
- 缺乏领域专有知识： 标准LLM无法访问组织的内部私有数据。RAG则能够将LLM连接到这些内部知识库，如技术手册、政策文件等 。
- 幻觉（Hallucination）： LLM 会不同程度上地编造事实。RAG通过将模型的回答“锚定”在可验证的、检索到的证据上，提高事实的准确性和可信度 。
RAG的优劣势，不适合的场景
优劣势
一、优势
- 知识保鲜：随时把最新文档塞进向量库，不用重新训练模型。
- 幻觉刹车：回答前先“翻资料”，显著降低一本正经地胡说八道。
- 可溯源：答案附带出处链接或原文片段，方便人工复核。
- 低成本上新领域：换一批文档就能服务新场景，无需重训大模型。
- 权限隔离：同一份模型对不同用户只暴露各自有权限的文档子集。
二、劣势
- 检索不准 → 答非所问
向量化语义漂移、Top-K 漏召回、表格/数字细节丢失都会导致“找到了却答错”。 - Chunking分块大小
块太大易超上下文窗口，块太小又丢上下文。 - 延迟抖动
检索 + 重排 + 生成串行链路，毫秒级波动直接放大到秒级体感。 - 维护成本高
文档更新、权限同步、向量库版本升级、嵌入模型迭代都要持续投入。 - 对结构化数据不友好
SQL 报表、时序指标、复杂表格常被拍平成文本，精度骤降。
不适合的场景
| 场景特征 | 原因 |
|---|---|
| 毫秒级实时决策（高频交易、工业控制） | 检索链路带来不可接受的延迟与抖动。 |
| 强一致性查询（银行余额、机票余量） | 向量召回无法保证“最新且唯一”的结果。 |
| 大量精确数值计算（财务报表、实验数据，大量数据的Excel表格） | 分块后数字被截断或四舍五入，易累计误差。 |
| 超长上下文一次性理解（读 100 页合同找所有隐含条款） | 向量 Top-K 只能召回局部，易漏跨页逻辑。 |
| 极低资源环境（手机离线、IoT 终端） | 向量库 + 大模型双杀内存/算力。 |
| 高度动态且需事务回滚（多人协作 wiki 实时编辑） | 文档秒级变更 → 向量库实时更新成本爆炸。 |
RAG细分步骤
| 步骤 | 描述 |
|---|---|
| 1. 数据准备 | 收集相关领域的知识源，如文档、论文、网页、数据库等，并进行清洗和结构化处理。 |
| 2. 文本分割 | 将长文本拆分为更小的片段（Chunk），以便于检索和处理。 |
| 3. 向量存储 | 将文本片段转换为向量表示，并存储在向量数据库中。 |
| 4. 用户查询 | 用户提出一个具体的问题或请求。 |
| 5. 检索相关文档 | 使用嵌入模型从向量数据库中检索与查询相关的文档片段。 |
| 6. 上下文提取 | 从检索到的文档中提取上下文信息，用于生成回答。 |
| 7. 结合上下文和查询 | 将提取的上下文信息与用户的查询相结合，形成输入提示。 |
| 8. 生成响应 | 使用大型语言模型（LLM）基于输入提示生成最终的回答。 |
| 9. 输出结果 | 将生成的回答返回给用户，完成一次交互。 |
RAG架构分类
- Naive RAG： 即上文描述的基础实现。它适用于简单的问答场景，但在检索质量和上下文处理方面存在局限 。
- Advanced RAG： 这种范式在检索前后引入了处理步骤以提升质量，关键策略包括：
-
- 检索前处理： 采用更复杂的文本分块策略、查询转换（如StepBack-prompting）等优化检索输入 。
- 检索后处理： 对检索到的文档进行 Re-ranking 以提升相关性，并对上下文进行Compression 。
- Modular RAG： 一种更灵活、更面向系统的RAG视图，其中不同的组件（如搜索、检索、记忆、路由）被视为可互换的模块。这使得构建更复杂、更定制化的流程成为可能 。具体模式包括：
- 带记忆的RAG： 融合对话历史，以处理多轮交互，使对话更具连续性 。
- 分支/路由RAG： 引入一个路由模块，根据查询的意图决定使用哪个数据源或检索器。
- Corrective RAG, CRAG： 增加了一个自我反思步骤。一个轻量级的评估器会对检索到的文档质量进行打分。如果文档不相关，系统会触发替代的检索策略（如网络搜索）来增强或替换初始结果 。
- Self-RAG： 让LLM自身学习判断何时需要检索以及检索什么内容，通过生成特殊的检索Token来自主触发检索。
- Agentic RAG： 这是RAG最先进的形式，将RAG集成到一个智能体循环（agentic loop）中。模型能够执行多步骤任务，主动与多个数据源和工具交互，并随时间推移综合信息。
- Graph RAG： 在检索阶段把“图”作为核心索引结构，用图数据库或知识图谱中的实体-关系-属性三元组做召回，再把子图（节点+边+上下文）直接送入 LLM，让模型在生成时能同时利用结构化事实与自由文本，既保持关系可解释又提升多跳推理能力。特别适用于法律和金融领域，但消耗的Tokne量巨大。近期不少公司开源了GraphRAG框架，比如蚂蚁和微软，具体分析请看后续文章。
如何进行分块（Chunking）
高级分块策略
文本分块（Chunking）是RAG流程中最关键也最容易被忽视的一步。其目标是创建在语义上自成一体的文本块。
- 朴素分块的问题： 固定大小的分块方法虽然简单，但常常会粗暴地切断句子或段落，导致上下文支离破碎，语义不完整 。
- 内容感知分块：
-
- 递归字符分割： 一种更智能的方法，它会按照一个预设的分割符层次结构（如：先按段落，再按句子，最后按单词）进行分割，以尽可能保持文本的自然结构 。
- 文档特定分块： 利用文档自身的结构进行分割，例如，根据 Markdown 的标题、代码文件的函数或法律合同的条款来划分 。
- 语言学分块： 使用NLTK、spaCy等自然语言处理库，基于句子、名词短语或动词短语等语法边界进行分割 。
- 语义分块： 这是最先进的方法之一。它使用嵌入模型来检测文本中语义的转变点。当文本的主题或意义发生变化时，就在该处进行分割，从而确保每个分块在主题上是高度内聚的。研究表明，这种策略的性能优于其他方法 。
- 智能体分块： 一个前沿概念，即利用一个LLM智能体来决定如何对文本进行分块，例如，通过将文本分解为一系列独立的 propositions 来实现 。
表格类数据的分块
| 分块策略 | 核心思路 | 适用场景 | 优点 | 注意事项 |
|---|---|---|---|---|
| 表格感知分块 | 将表格整体或按行/列提取为独立块，保留结构（如JSON/Markdown） | 含表格的文档（PDF、Word、网页等） | 结构完整，易于后续处理 | 格式复杂时易丢失细节 |
| 面向行的分块 | 每行或若干相关行作为一个块 | CSV、数据库导出表、日志表 | 每行独立性强，便于精准检索 | 需确保标题与数据成对出现 |
| 表格到文本转换 | 将表格内容转写为自然语言描述 | 嵌入模型不擅长处理结构化数据时 | 提升语义理解，适配通用RAG流程 | 可能丢失部分结构信息 |
| 整表分块 + 摘要嵌入 | 提取整张表后生成摘要再嵌入 | 表格体量适中、内容密集 | 保留全貌，减少冗余 | 大表需额外拆分 |
| 大表拆分 | 按最大行数或逻辑分组拆分大表 | Excel、超宽/超长表格 | 避免块过大导致截断 | 需确保上下文不丢失 |
- 总结：根据实际工程情况分类
- 小表（<50行）：可直接整表作为一个块，或转为Markdown嵌入。
- 中表（50~500行）：建议 按行分块，每10至50行为一组，带标题和列名。
- 大表（>500行）：采用逻辑分组（如按“地区”、“月份”字段）或最大行数限制（如每块最多100行）。
- 表格混排文档（混合检索）：使用根据内容分块，将表格与正文隔离处理
多模态数据的分块（视频、图片、PPT等）
-
时间轴对齐层
时间轴设计为主键，先把多模态流按自然时间戳切成若干“时隙”（如 30 秒一段或一页 PPT 一块），保证任何后续处理都能回溯到原始时间点。
-
文件级 RAG 层
在每个时隙内部，再按模态/文件类型做二次分块：- PDF 页 → 按表格/段落/图表拆
- 视频关键帧 → 配 OCR 文本
- 音频 ASR → 句子级
然后把这些数据统一索引，而不是让每份文件各自跑一个独立的 RAG。
具体过程
具体过程按时间顺序展开如下，每一步只给“输入→处理→输出”的硬事实，不比喻。
-
时间边界划定
输入：一段 1 h 会议录像。
处理：以 30 s 为步长，生成 120 个区间 [0 s,30 s)、[30 s,60 s)…
输出：120 个区间编号 slot_id = “t0”“t1”…“t119”。 -
原始数据提取
对每个 slot_id：- 视频关键帧：取区间首帧、尾帧、中间帧，共 3 张。
- 语音：用 ASR 转写，得到该 30 s 内的纯文本。
- 幻灯片：OCR 识别出的文字、表格、图表截图。
结果：slot_id 下得到 4 类原始对象 {txt, img, tbl, aud}。
-
统一对象封装
把 slot_id 下的 4 类原始对象合并成一条文档，或者Json格式： doc_id = slot_id ts_start = 区间起始秒 txt_content = ASR 文本 img_list = [img1, img2, img3] 的 base64 tbl_list = [table1, table2] 的 markdown 共 120 条文档，每条包含多模态字段。 -
向量索引写入
对每条文档：- 文本部分用 Sentence-BERT 得到 768 维向量 e_txt。
- 图像部分用 CLIP 得到 768 维向量 e_img（三张图取平均）。
- 表格部分按 markdown 文本同样用 Sentence-BERT 得到 e_tbl。
- 音频无独立向量，直接忽略或并入文本。
将三向量拼接后降维到 768 维，得到最终向量 e_slot。
把 (doc_id, e_slot, 完整 JSON 文档) 插入向量数据库的同一张表。
但是LLM是否能理解不同模态、不同编码的token？
-
在线检索
输入：用户查询 Q。
处理：- 用同样模型把 Q 向量化得到 q_vec。
- 在 Milvus 做 ANN 搜索，取 Top-K=5 的 doc_id。
输出：直接返回 5 条完整 JSON 文档，每条内含该 30 s 区间的 txt、img、tbl 全部字段。
-
结果返回
前端一次性渲染：30 s 的文本、关键帧、表格在同一条记录内，无需二次拼接。
结果：
检索时，一次召回“某 30 秒内的文字+图表+关键帧”，而不是先按时间切片，再分别跑 N 个 RAG 再拼接。这样既保留时间上下文，又避免碎片化。
