找回密码
 立即注册
首页 业界区 业界 LLM-RAG项目细节-数据处理、分块..

LLM-RAG项目细节-数据处理、分块..

煅圆吧 10 小时前
rag项目细节

当模型没有某部分知识的时候,你将文档丢给大模型,告诉他了这些知识,然后大模型根据你的文档对你的问题进行回答
1.png

文档处理

未经处理的手机扫描pdf或者打印机扫描pdf则为不可编辑形式文档
2.png

在一些没有ocr能力或者ocr能力不强的rag框架下会直接0字符不会有任何内容
通过mineru转换为可编辑的markdown形式
3.png

4.png

上传mineru处理过的文件成功识别到字符数
切块

5.png

将这种段落格式的文档丢给dify来看看他会怎么切块
6.png

可以看到每个块的字符数特别少,块很多。这会导致召回的质量非常的低信息不完整
尝试召回,效果并不好
7.png

召回测试非常重要,针对五进行召回测试
这里如果切块没有切好,召回的信息不完整或者过多都会影响性能,目前我们是召回信息不完整。这里出问题rag项目没必要进行下去,我们正在做 通过问题去向量数据库里检索切块内容
文档ocr解决了dify可以识别编辑文字
大模型一次吃不下一个文档所以必须切块、切块提高了效率可以并发、好的切块每段信息会是完整切字符保持平均
对初始文本进行python数据处理
python批处理代码如下
  1. import os
  2. def process_file(file_path):
  3.     """
  4.     读取文件,删除所有回车,然后删除####符号(保留内容),保存为原文件名+re
  5.     """
  6.     # 读取文件
  7.     with open(file_path, 'r', encoding='utf-8') as f:
  8.         content = f.read()
  9.     # 删除所有回车换行符
  10.     content = content.replace('\n', '').replace('\r', '')
  11.     # 删除四个#符号(只删符号,保留后面的内容)
  12.     content = content.replace('####', '')
  13.     # 在###标题后面添加回车
  14.     content = content.replace('###', '###').replace('###', '\n###')
  15.     # 修正开头可能多出的换行
  16.     if content.startswith('\n'):
  17.         content = content[1:]
  18.     # 保存到新文件
  19.     output_file = file_path.rsplit('.', 1)[0] + 're.' + file_path.rsplit('.', 1)[1]
  20.     with open(output_file, 'w', encoding='utf-8') as f:
  21.         f.write(content)
  22.     print(f"处理完成!输出文件:{output_file}")
  23. def process_all_files_in_folder(folder_path):
  24.     """
  25.     遍历文件夹中的所有文件并处理
  26.     """
  27.     for filename in os.listdir(folder_path):
  28.         file_path = os.path.join(folder_path, filename)
  29.         # 只处理文件,跳过文件夹
  30.         if os.path.isfile(file_path):
  31.             print(f"正在处理: {filename}")
  32.             process_file(file_path)
  33. # 使用示例
  34. process_all_files_in_folder('file-dir')  # 遍历file-dir文件夹中的所有文件
复制代码
8.png

经过python处理后整个文档被拆成大标题的6段。再次上传dify并测试召回
9.png

10.png

被召回的段落信息完整
embeding

11.png

设置一下厂商的api-key
这个选择一个用中文训练的embeding模型就好
帮助中文转为数字向量这个过程
我这里选qwen3embeding
向量数据库
  1. 为什么Dify选择Weaviate
  2. RAG应用友好
  3. 非常适合构建检索增强生成(RAG)应用
  4. 支持文档切片、向量化、存储、检索的完整流程
  5. 开发体验好
  6. 安装部署相对简单,有Docker镜像
  7. 文档完善,社区活跃
  8. 提供直观的管理界面
  9. 扩展性强
  10. 支持水平扩展
  11. 可以处理大规模向量数据
  12. 这些特点使得Weaviate成为构建AI应用特别是知识库和问答系统的理想选择,这正是Dify这类LLM应用开发平台所需要的能力。
复制代码
dify在用这个向量数据库,可以把这个容器删了换一下改源码换成qdrant。还是用dify的吧先把该项目演示完。不同向量数据库会有差别会对最后的rag效果产生影响
用户提问、小结

目前则是文档切块向量化丢进了数据库,用户提问题,问题会去数据库检索
检索出一个content里面为相似切块内容,用户提问带上系统提示词带上切块一起给大模型。大模型给出回复
dify未来产品客服系统搭建、rerank

system系统提示词
  1. 你是一个热情幽默活泼销售经理,你熟读知识库context里的内容,
  2. 并且根据context真实内容进行推销,必须是context里真实内容。
  3. 使用以下信息为你的内容,放在<context></context> XML标签内。
  4. <context>
  5. {{#context#}}
  6. </context>
  7. 回答用户时:
  8. 如果你不知道,就直说你不知道。如果你在不确定的时候不知道,就寻求澄清。
  9. 避免提及你是从上下文中获取的信息。
  10. 并根据用户问题的语言来回答。
复制代码
12.png

使用reranker粗排后精细排序
准确无误块大小合适,llm根据块和提问一起回答。效果不错
13.png

dify增加文档数量至20

问题测试
  1. NeuroVision X3000 的硬件规格是什么?
  2. NeuralGlow 的硬件规格是什么?
  3. NeuroVision X3000 有脑波交互吗?
  4. Vision X3000 有脑机接口吗?
复制代码
topk参数
14.png

score阈值
  1. 两个参数的协同关系
  2. python# 检索流程
  3. similarities = [0.89, 0.697, 0.686, 0.609, 0.45, 0.32, 0.28]
  4. # 第一步:topk控制数量(扩大/缩小搜索范围)
  5. topk = 4  
  6. candidates = [0.89, 0.697, 0.686, 0.609]  # 取前4个
  7. # 第二步:score阈值过滤质量(过滤低分)
  8. score_threshold = 0.65
  9. final_results = [0.89, 0.697, 0.686]  # 0.609被过滤掉
  10. 实际工作机制
  11. topk = 搜索广度
  12. topk=1:  只要最匹配的,风险:信息不足
  13. topk=10: 广撒网,风险:引入噪音
  14. topk=4:  平衡点(你的选择)
  15. score = 质量门槛
  16. score≥0.8:  高质量,但可能数量不够
  17. score≥0.6:  中等质量,平衡点
  18. score≥0.4:  低门槛,可能有噪音
  19. 最佳实践组合
  20. python# 保守策略:精准优先
  21. topk = 3, score_threshold = 0.7
  22. # 平衡策略:你现在用的
  23. topk = 4, score_threshold = 0.65
  24. # 激进策略:召回优先  
  25. topk = 8, score_threshold = 0.5
  26. 针对你的情况
  27. 建议调整为:
  28. pythontopk = 4           # 保持不变
  29. score_threshold = 0.65  # 新增:过滤掉0.609那个块
复制代码
元数据过滤(rag优化)

解决块数量过多引发的多跳问题(致命)以及检索效率不高的问题
15.png

16.png

17.png

块重写(rag优化)

无法命中
18.png

重写块(或者在数据处理那里进行批量操作或者块重叠)
19.png

20.png

提高命中块精确度
rag切块问题
假如有这样两个块
一个块为:产品介绍xxx这个产品多么多么好产品名称叫超级无敌旋风相机
另一个块:他的特性是拍照速度特别快而且无限胶卷,非常牛
那么用户问题 超级无敌旋风相机的特点是什么?
在向量数据库块非常多的情况下,大模型可能无法讲两个块的特点关联起来,我的发现对吗?
这是RAG系统中一个非常典型且重要的问题,被称为"信息分散问题"或"上下文割裂问题"。
向量检索时很可能发生:
查询"超级无敌旋风相机的特点"会优先匹配到块1(因为有确切的产品名称)
块2虽然有特性信息,但语义相似度可能不够高,无法被检索到
最终答案不完整或不准确
1.使用土方法重写块,粗暴改写超级无敌旋风相机的特性是拍照速度特别快而且无限胶卷,非常牛
简单直接,工作量大,有时需要python批处理,要注意语义流畅
2.构建知识图谱
3.优化元数据
4.块优化

来源:程序园用户自行投稿发布,如果侵权,请联系站长删除
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!

相关推荐

您需要登录后才可以回帖 登录 | 立即注册