RAG 在企业数智化场景下的设计与改进

内容纲要

一、从 GenAI 的发展看企业数智化架构

01｜从基础设施看数智化系统架构的演变趋势

当前的典型企业GenAI架构

（其实不太合理，传统大数据平台的建设思路，根深蒂固）

GenAl在企业应用现状

算力建设优先，软件应用滞后
传统大数据平台建设思路根深蒂固
软件重复建设，应用效果无法保证
LLM 在企业没有真正用起来

企业数字化基础设施

从 AlInfra 和 Data Infra 的结合看数智化基础设施

RAG 是一种架构而不单是一类应用

从数字化到数智化

新视角下的企业GenAl架构

为什么以RAG为核心--数据层

02｜从数智化场景看RAG：是临时方案，还是终局架构？

RAG的争议由来已久

RAG vs 长上下文 LLM ——完美互补

RAG与LLM ——硬盘论

AI能力进化

2个B端最常用的能力（2023年）

翻译能力
摘要能力

RAG的本质——新一代搜索引擎

RAG与搜索引擎的区别——不考虑内容生成

RAG是搜索引擎的下一代

03｜国内和海外企业对于GenAI的需求的共识和差异

RAG典型生态位（工作原理）

海外RAG的典型生态位

提供完整RAG服务的海外公司分类

提供RAG能力的公司分类对比

国内和海外RAG应用现状对比

当前RAG实施现状4

场景单一，局限在知识库场景
效果不佳，国内企业付费意愿低
以LLMOps为主
LLM当下不是瓶颈
重视Agent多于RAG

二、如何做好RAG

04｜数据清洗和解析对RAG的影响和解决方案

为什么要重视数据清洗和解析质量

对话意图明确时的命中率对比

如何提供好的数据清洗和解析

什么叫表格结构识别模型

表格结构识别模型

多模态大模型
目标检测
deepdoc https://github.com/infiniflow/ragflow//tree/main/deepdoc
Transformer

文档“大”模型

“雕花”还是LLM？

【PDF】CharXiv: Charting Gaps in Realistic Chart Understanding in Multimodal LLMs

https://arxiv.org/abs/2406.18521

https://github.com/princeton-nlp/charxiv

05｜如何保证高命中率，如何选型向量数据库？

为什么向量数据库在RAG的数据库中占据主导？

RAG本质就是下面这4个问题

RAG本质是搜索系统
向量搜索是一种对搜索引擎的简化
根据提问搜索文本-模糊搜索--语义相似度--向量
向量搜索性能高

向量搜索的限制

向量搜索的2个缺点

向量表征文本是有语义损失的
向量无法表征精确

向量搜索的补救手段

混合搜索
- 多种Chunking方式
- 多种搜索方式
- 全文搜索 is a MUST
重排序

混合搜索

混合搜索更好的方式，是做这种三路混合搜索，这是在今年2024年4月份IBM的一个Research发了一篇论文叫做BlendedRAG

【PDF】https://arxiv.org/abs/2404.07220

https://github.com/ibm-ecosystem-engineering/Blended-RAG

如何做融合排序（2种）

RRF：每路搜索每个结果按它的排名倒数赋分，如ES
简易加权融合：每路搜索的权重归一化加权叠加

混合搜索——IBM Blended RAG

nDCG是考虑我们搜索出来的结果，它的一个排名的一个加权的一个得分。

混合搜索——稀疏向量

混合搜索——全文搜索

Tensor张量搜索

Tensor重排序的效果

Tensor ranker还是reranker？

张量做重排序会更好，做排序不那么合适

延迟交互是RAG的未来

RAG数据库选型对比

Share Nothing：如果对这种datainfor比较了解的话，不是基于共享存储的，这种架构部署在云上，会面临伸缩性问题，对伸缩性成本上可能都会有问题

LanceDB和MyScale都用了前面的库：tantivy，这个库是一个提供了全文搜索引擎的一个库

Rockset，是OpenAI2024年6月份收购的公司，提供了为数不多的全文搜索和向量搜索。

去年OpenAI使用的是Qdrant，现在使用的是Rockset，核心原因是Rockset是一个索引数据库，提供了全文搜索，也提供了向量，并且还是一个标准的数据库，所以满足OpenAI对未来的需求。

纵坐标：效率、性能

横坐标：

传统数据库：具备向量能力，如Postgre，通过一些插件具备向量能力，一般不推荐使用，因为只是一个向量无法承担RAG、特别是企业RAG的需求。
向量数据库：一般具备向量、稀疏向量、两路召回、两路混合搜索的能力
具备全文搜索能力的数据库（上图没有打虚框的）：ES、RocketSet，还包括像采用了一些搜索全文搜索库的数据库，如LanceDB、MyScaleDB，他们具备两路混合搜索能力，因此效果上比一般向量库好一些。

06｜如何解决复杂问答？

什么是复杂问答

长文本提问
Query Focused Summarization
多跳问答
单个问题可以分解为多个子问题
查询意图

复杂问答之Agentic RAG

AGentic RAG意思就是：我们用Agent的方式去编排RAG。

复杂问答之文档预处理——RAPTOR

复杂问答之文档预处理--HippoRAG

解决复杂提问，最有效的就是知识图谱

基于知识图谱的复杂问答举例

HybridRAG——GraphRAG 和 RAG 的关系

知识图谱的限制和要求

手工构建知识图谱工作量巨大
三元组的知识图谱自动构建存在挑战
图数据库更适合精确点查询
知识图谱更需要子图检索
GNN结合知识图谱更有价值

07｜如何构建企业级Agent？

下一代RAG

Agent编排引擎——有向无环图还是循环图?

开源Agent编排引擎

核心在线算子

Naive RAG(检索)
Generation(生成)
分类器(查询意图、问题分类、…)
是否相关判定器
查询重写

开源图/工作流编排引擎

LangGraph
Llamalndex
Dify
RAGFlow

工具类算子

外部接口
定制API

企业级Agents开发——算子开发

企业级Agent编排样例

下图是由RagFlow制作

08｜如何构建企业级的RAG和Agent集群架构？

RAG系统架构

企业级RAG部署考虑因素

效果与成本Trade Off

文档类型和复杂程度，是否需要高级理解模型(GPU)，还是初级文档布局即可
知识图谱构建模型 Token 消耗惊人，是否需要以及当前阶段如何规避