CONTENT

基础概念涉及概念流程EmbeddingsChunkingVector Database缺点实操：用RAG构建个人知识库源文本选择分块算法将块embedding，存入向量数据库写查询函数query补充

基础概念

涉及概念

流程

ref

 

Embeddings

Chunking

Vector Database

缺点

1. 分块的方式不合理，不能适配所有情况：
1. 语义被机械切割
2. 问题：为什么不交给LLM去切割（已经有类似的优化切割策略了）

2. 比如：文章中某个字词出现了多少次（和每局都有微弱相关，但又不够相关，但和总体比较相关的问题）
1. 问题：这种适合正则表达式之类的机械检索方式

实操：用RAG构建个人知识库

源文本选择

分块算法

1. 针对特定篇文章的特定算法
1. 先获取内容
2. 两个回车为切割
3. 优化：＃开头的作为目录，不作切割

2. 现有的算法：langchain的Recursive Character Text Splitter

将块embedding，存入向量数据库

1. 选择适合的embedding模型
1. 一般将分割这一动作交给第三方平台
2. 所以只写接口的功能函数就行了

2. 安装对应依赖
1. 可能需要对应的api key
2. 构建相应的输入函数embed.py
3. 具体操作参考选择的模型的说明文档
4. 如：Google的Gemini嵌入模型，数据分为了存储和查询两类
1. 分类的目的是能靠其闭源算法拉近向量距理：
如：a：1是2，b：3是4，c：13是什么？；分开存a，b和c，在问c时，能够直接定位到a和b。
5. 其他模型并没有这样的分类

3. 直接返回向量数据
1. 简单demo演示，用upsert
2. 实际肯定要加入存储前的纠错机制

4. 生成选择的向量数据库的实例，把向量和原文存入数据库
1. 如chromadb的实例，生成实例
2. 依次对每个chunk做embedding
3. 用chromadb的upsert函数存入
4. create db函数存入数据库

写查询函数query

1. 先把question做embedding，

2. 查询数据库中的相关片段n

3. 组合prompt：
1. question
2. context

4. 发给LLM

补充

1. 分割方法改进
1. 算法迭代

2. 重排序模型
1. 弥补一些返回数据chunk时，受限于n值的设置，只能返回部分chunk时，前面的几个质量不太行的问题
2. reranker，用于把靠谱的往前排

1. 全局视角的改进：调用MCP类工具处理
1. RAG本质是返回部分相关的上下文context，用以补充
2. 无法回答全局类型的统计类，结构类的全局条件下的问题
3. 改进：调用MCP工具处理关系型数据库
1. 如：postgres数据库中，用NPX配置，修改json文件中的数据库地址（按格式输入账号，密码等信息）
2. 在prompt中给出数据库的存储表结构信息
4. 其实就是现阶段RAG的天然缺陷，又被用户冠以全能，一站式的功能期待，导致这部分得集成之前有的结构化数据的处理方式，才能”正常“使用。
5. 当然，还有粗暴的跟堆算力一样道理的方法：超长上下文

1. 使用自适应RAG