预告：
- Vector Store 向量存储与检索
- Chroma向量数据库使用
- 向量数据库选型
- RAG高级进阶实战
- 文本分割粒度
- 检索后排序
- Re-Ranker模型
- 混合检索（Hybrid Search）
- RRF
- PDF文档表格处理
- GraphRAG基本介绍
向量数据库
向量数据库，是专门为向量检索设计的中间件。
向量数据库其实最早在传统的人工智能和机器学习场景中就有所应用，在大模型兴起后，由于目前大模型的token数限制，很多开发者倾向于将数据量庞大的知识，新闻，文献，语料等先通过嵌入算法转变为向量数据，然后存储在chroma等向量数据库中。当用户在大模型输入问题后，将问题本身embedding，转换为向量，在向量数据库中查找与之最匹配的相关知识，组成大模型的上下文，将其输入给大模型，最终返回大模型处理后的文本给用户，这种方式不仅降低大模型的计算量，提高响应速度，也降低成本，并避免了大模型的token限制，是一种简单高效的处理手段。此外，向量数据库还在大模型记忆存储等领域发挥其不可替代的作用。
Chroma向量数据库
官方文档:docs.trychroma.com/docs/overvi…
澄清几个关键概念:
- 向量数据库的意义是快速的检索
- 向量数据本身不生成向量，向量是由Embedding模型产生的。
- 向量数据与传统的关系型数据库是互补的，不是替代关系，在实际应用中根据实际需求经常同时使用。
Chroma向量数据库服务
主流向量数据库功能对比
推荐以下：
- Milvus
- Qdrant
扩展阅读： guangzhengli.com/blog/zh/vec…
基于向量检索的RAG
OpenAI新发布的两个Embedding模型
- text-embedding-3-large
- text-embedding-3-small 其最大特点是，支持自定义的缩短向量维度，从而在几乎不影响最终效果的情况下降低向量检索与相似度计算的复杂度。
rag系统基本需要用到2个模型
- embedding模型
- 文本生成模型
向量模型的精确度，直接影响query相似度检索，文档召回率。
实战RAG系统的进阶知识
文本分割的粒度
直接影响文本检索的好坏和精度问题
缺陷
- 粒度太大可能导致检索不精准，粒度太小可能导致信息不全面
- 问题的答案可能跨越两个片段
nktk. 没有固定模式。 chunk_size: 一般根据文档内容或大小来设置 overlap_size: 一般设置chunk_size大小的10%-20%之间
文本合理切割：
- chumksize和overlap来切割
- 对于复杂文本，总是不完美。推荐使用NSP任务来进行微调训练。A和B两个句子（段落）是否有关系，若有关系则进行合并。拿自己业务的数据来喂投。
- 有图片，表格什么的，需要单独处理
检索后排序
方案：
- 检索时召回一部分文本
- 通过一个排序模型对query和document重新打分排序
一些Rerank的API服务
- Cohere Rerank: 支持多语言
- Jina Rerank: 目前只支持英文
bge-reranker-large 要做到好的话，还是需要微调
混合检索（Hybid Search）
在实际生产中，传统的关键字检索（稀疏表示）与向量检索（稠密表示）各有优劣。
所以，有时候需要结合不同的检索算法，来达到比单一检索算法更优的效果，这就是混合检索。混合检索的核心是，综合文档d在不同检索算法下的排序名次（rank），为其生成最终排序。
一个最常用的算法叫Reciprocal Rank Fusion (RRF)
PDF文档中的表格怎么处理
1.将每页pdf转成图片
2.识别图片中的表格
怎么识别pdf中的表格？可以模型识别。 要识别AI是否能处理。
一些面向RAG的文档解析辅助工具
- PyMuPDF
- RAGFlow
说说 GraphRAG
- 什么是GraphRAG 核心思想是将知识预先处理成知识图谱
- 优点：适合复杂问题，尤其是以查询为中心的总结
- 缺点：知识图谱的构建，清洗，维护更新等都有可观的成本
- 建议：
- GraphRAG不是万能
总结
- 离线步骤
- 文档加载
- 文档切割
- 向量化
- 灌入向量数据库
- 在线步骤
- 获得用户问题
- 用户问题向量化
- 检索向量数据库
- 将检索结果和用户问题填入prompt模板
- 用最终获得的Prompt调用LLM
- 由LLM生成回复
