怎么用rag构建企业级知识库

以前企业中的知识库，就是用来保存企业中各个部门的资料

这么多文档 企业会作为一个知识库系统，统一的保存起来，但是保存完毕之后怎么做更好的检索 这是一个问题

随着技术的发展，有了es，但是es只能根据关键字进行检索

比如说 搜索价格 搜索出来一堆文档

呢我现在比如说 用户嫌弃价格贵 我搜索价格，我要查出这些文档， 我才可以用一个合理的理由解释用户嫌贵的问题

现在我们引入了ai 所谓的检索增强

我作为一个销售 我希望ai 帮我们理解这个问题 帮我们检索这些相关文档
最终根据 文档中相似的信息给我生成一个满意的答案

######################>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
我是一个销售 我根据这些文档总结一个话术 呢他能够可以提供高我的工作效率
并且我们作为开发 如果我接手一个项目 我们如果对这个项目需求不熟悉的话会焦头烂额的
怎么去更改

如果有rag 知识库系统 我们可以根据这个rag去问 比如说xxx系统以前是怎样的 规则是怎样的
通过这些资料 帮我们提供对应的说明

我作为一个新手开发 我就可以通过rag知识库快速的 了解项目的相关东西， 可以说rag 是任何一个公司的ai应用场景
########>>>
比如说用户觉得xxx太贵 rag 是怎么检索到这些相似信息的

##########<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

可以使用向量数据库 这里面涉及一个关键的问题，叫做向量数据库
他不像我们关系型数据库一样 用来做精确匹配的
向量数据库是用来做相似度匹配的， 只要语义相似，就可以检索出来

前提是你的要把这些文档信息提前存储在向量数据库中

并不是像以前的关系型数据库一样存储的文本
他存储的是向量

什么是向量， 比如说我存储 早上好 你好这些向量 我就可以通过上午好的向量检索到跟他语义相似的文本

向量就是用来检索相似性

比如说你好， 我通过向量化就可以得到对应的数值坐标

你好--------->5 通过什么才可以将文本编程向量
（向量模型）
这个向量模型和我们LLM 不同， 我们的LLM 是做智能对话的
=============================>>>>>>>>>>>>>>>>>>>>>>>>>>>>
x向量模型 是用来 第一理解文本的语义的，然后把他生成一个向量的数值
向量模型很多 比如说阿里的千问

通过向量模型，我们就可以让他去理解 文本，从而生成一个坐标

比如说hello 你好，这些从语义上来说是相近的，所以我必须从语义上去理解这些相似的文本
从而去生成一个对应的数值

相似语义的文本， 他们的坐标，就会比较近一些
而语义相似比较大的话，他们的坐标就会比较远一些
我们就的根据向量来检索跟他坐标哎的比较近的， 也就是语义比较近的文本信息

也就是通过向量模型 他会理解语义的意思 然后转化成一个坐标

#########################>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
我们只是举例了一些一维度的坐标
第二步 多维向量

特征越多 相似性检索的精度就会越高 代表检索的精确性越高（多代表多维度）

所以我们在选择向量模型的时候 呢种维度太少的模型 不要用
因为性能比较差

对于一个物品 我们需要维度来提取他的坐标 不管他是多少维

基于这些维度 他是怎么检索到相似性文本的

可以进行余弦相似度 这是进行相似度检索的一个算法
比如说两个狗的夹角 夹角越小 代表相似度越高
夹角越大，代表相似度越小
自然这个相似度不需要我们去记忆
向量数据库已经帮我们完成了， 我们只需要放一个向量进去就可以了
他内部会根据各种算法（比如说余弦相似度） 从而检索出来

所以我们需要进行相似度检索，需要3个关键东西

1.向量 2. 向量模型 3， 向量数据库

########################>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>…
呢如果我们要落地到我们的实现 具体要怎么去做
比如说我们现在问 迟到扣多少钱 基础大模型LLM 肯定不知道

我们现在想要根据我企业中垂直的信息去回答
这个我们就要用到RAG 的相似性检索

所以我们现在要先进性embeding 的数据嵌入阶段， 把我们的资料保存到向量数据库中
比如说有什么 人事手册 企业规章 怎么去保存

我们通常不会把我们的pdf 直接保存到我们的向量数据库中

1. 文档可能token 过大
   2 .比如说这个文档会有几兆 如果把这个文件通过向量模型转换成数值（向量维度是有限的）
   在有限的向量 去转换很大的文件，他这个文本的主题就会被稀释

token过大 假如说我直接把这个文档存储在向量数据库中 即便我后续搜索到了
他也会把这个文本 发给大模型 超出大模型的token上线

token过大==费用过大 推理时间变长
说白了 你发给大模型的信息 他就是token

所以 token 如果过大 费用高 推理时间就会边长 用户的延迟就会边长
所以我们不建议直接把一个大的文本直接存储在向量数据库中

我们一般会对我们的数据 文件进行分片处理
从而我们就会把这些一个个的片段去进行向量化

存储到我们向量数据库中
之前我们叫做embe 嵌入
现在我们叫做检索