RAGFlow助手应用实践

原创

山西空管技术支持 2024-07-06 13:51:59 博主文章分类：AI+Agent ©著作权

©著作权归作者所有：来自51CTO博客作者山西空管技术支持的原创作品，请联系作者获取转载授权，否则将追究法律责任

Tip:

Q&A、采集、markdown、LaTeX、OmniParse、Marker、Surya、Nougat、Whisper、Florence-2、MarkText、Markdown Web Clipper、Agentic RAG（ Graph）、Redis Error、infinity、Elasticsearch、Multi-Attach error、PVC克隆、ExeSQL、text2sql、Agent API、Ubuntu 24.04 LTS运行ollama、task executor、RAPTOR、AssertionError、API Token

*：RAGFlow使用不同邮箱注册（一旦注册，电子邮件将无法更改），登录后，知识库、聊天、Agent和文件管理以及配置的“模型提供商”等是不同的隔离环境。

*omniparse项目建立在Vik Paruchuri创建的卓越marker项目之上。

*: 知识库的建立可以根据实际需求和资料的性质来决定是存放在一个库里还是多个知识库里。如果资料之间关联性强，存放在一个库里可能更有助于模型的运行和输出的效果，因为这样可以更方便地进行跨领域的综合分析和检索。如果资料类别差异大，分散在多个知识库里可能更有助于提高检索的准确性和效率。总的来说，没有绝对的优劣之分，需要根据具体情况来决定。

2024-08-08:RAGFlow 0.9.0 正式发布! 更新如下:

1. 支持Graph RAG
2. 新增更多Agent算子: 关键词提取，百度/duckduckgo/pubmed/wikipedia/bing/google等搜索算子
3. 新增支持语音文件 (语音到文字的识别)
4. 新增Gemini，Groq等大模型支持
5. 新增对LM studio/OpenRouter/LocalAI/nvidia api等推理框架/引擎/服务的支持
6. 支持xinference提供的reranker

1、word转换成excel涉及到多行转一行问题，技巧：在“飞书”新建“表格”，然后复制黏贴word的表格内容，不仅解决多行转一行问题，还去除了空白行等，然后下载到本地，导入至RAGFlow的Q&A知识库。

2、coze“知识库”添加内容，在线数据---自动采集：添加方式选“添加单个”，采集博客网页，出现内容不全的现象（例如https://blog.51cto.com/mizy/8619685）；添加方式改成“批量添加”同样这个网页博客就正常了。

手动采集（依赖安装浏览器扩展程序，采集成功率较高，支持手动标注采集范围），采集例如https://blog.51cto.com/mizy/category4.html博客会出现卡死现象。
解析后的知识库选择分段内容可以手动修改，但是不能前后调整分段内容。

2.1、扣子知识库解析PDF文档例如：民用航空飞行动态电报自动处理(MH.T4024-2008)，查看内容，有许多解析错误的字符，应该是这个pdf文档质量不好导致的。

RAGFlow助手应用实践_数据

4.3.13.1.4 在预计撤轮挡时问九后4h内航空器未起 ,也米收到CHG电报惑LIA电报,领航让 划报应失效,恢复为收到FPL电报以前的预备飞行动态。

3、OmniParse是一个平台，可将任何非结构化数据提取并解析为针对GenAI（LLM）应用程序优化的结构化、可操作数据（to high-quality structured markdown）。无论您是在处理文档、表格、图像、视频、音频文件还是网页，OmniParse都可以将您的数据准备得干净、结构化，并为RAG、微调等AI应用程序做好准备。最终目标：将当前使用的所有不同模型替换为单个MultiModel模型，以解析任何类型的数据并获取您需要的数据。to replace Surya OCR and Marker。Models being used:

Surya OCR, Detect, Layout, Order, and Texify：是一个文档 OCR 工具包，能够从图像中识别和提取文本信息，可进行布局分析，包括表格、图像、页眉等的检测。
Florence-2 base：由微软开发的一种新的视觉模型。它能够执行超过 10 种不同的视觉任务，比如图像字幕生成、对象检测、图像区域关联和分割等
Whisper Small：是 OpenAI 开发的一种通用语音识别模型。它通过在大量的多语言和多任务监督数据上进行训练，能够实现多语言的语音识别、转录以及将这些语言翻译成英语等功能。

docker pull savatar101/omniparse:0.1
# if you are running on a gpu 
docker run --gpus all -p 8000:8000 savatar101/omniparse:0.1
# else
docker run -p 8000:8000 savatar101/omniparse:0.1

4、Vik Paruchuri维护的网站https://www.datalab.to/，训练AI模型用于OCR、布局分析、PDF到markdown等。

Marker可快速准确地将PDF转换为Markdown，包括表格和方程式。
Surya处理90多种语言的OCR。它在打印文档上进行类似于Google Cloud OCR的基准测试。Surya可以识别各种文档中的布局块，如标题、图像和方程式。
Texify OCRs equations and turns them into LaTeX。LaTeX 是一种高质量的排版系统，特别适用于生成复杂的技术和学术文档。

4.1、Marker是一个PDF到Markdown的转换器，可以识别表格、OCR equations 和 re-OCRs bad pdf text。github有marker and nougat 的对比：

“Nougat”还是一个人工智能项目的名称。来自Meta全称为“Nougat: Neural Optical Understanding for Academic Documents”（神经光学理解学术文档）。是一种视觉 Transformer 模型，可以执行光学字符识别（OCR）任务，将科学文档处理成标记语言。它能够按顺序识别出文献扫描图片中的文字、数学公式和表格，并以 Markdown 的格式输出识别结果。

5、MarkText是MIT licensed的开源项目，平替Typora的开源Markdown Editor：https://www.marktext.cc/

支持中文的方法：https://github.com/ffey/ffey.github.io/issues/9
目前版本：0.17.1，汉化链接：GitHub - chinayangxiaowei/marktext-chinese-language-pack at v0.17.1

6、2024-07-08 发布的0.8 版本，支持 Agentic RAG: 基于 Graph 的工作流，RAGFlow 后端提供了完整的基于图的任务编排框架，从0.7版本升级到0.8版本只需更新镜像：image: swr.cn-north-4.myhuaweicloud.com/infiniflow/ragflow:dev

6.1、更新镜像后，首页界面增加了"Graph“一项，原来的知识库、聊天和文件管理中内容都还在。

6.2、使用聊天”川大ATC系统AI助手“出现报错：ERROR: (ProtocolError('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer')), '(Request ID: f0531003-ea12-4049-94c2-b73698aad3d3)')。

# kr exec -ti ragflow-server-6f49c447cf-k6psd -- bash
root@ragflow-server-6f49c447cf-k6psd:/ragflow# find / -name *bce-reranker*
/root/.cache/huggingface/hub/.locks/models--InfiniFlow--bce-reranker-base_v1
/root/.cache/huggingface/hub/models--InfiniFlow--bce-reranker-base_v1

在docker-compose-CN.yml中配置了 https://hf-mirror.com（趋动云，国内镜像 huggingface.co 域名）

environment:
      - TZ=${TIMEZONE}
      - HF_ENDPOINT=https://hf-mirror.com
      - MACOS=${MACOS}

或docker/docker-compose.yml配置了https://huggingface.co（官网）

environment:
      - TZ=${TIMEZONE}
      - HF_ENDPOINT=https://huggingface.co
      - MACOS=${MACOS}

——解决：在知识库中的检索测试，选择maidalun1020/bce-reranker-base_v1就报错，选择BAAI/bge-reranker-v2-m3正常，原因是模型从https://hf-mirror.com下载失败了，过一段时间模型下载后OK了。

6.3、假如聊天助理设置选择多个知识库，知识库之间配置的嵌入模型不一样，会出现提示：ERROR: Knowledge bases use different embedding models.

7、RAGFlow聊天时报错：

ERROR: (ProtocolError('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer')), '(Request ID: 3e1366df-9248-471d-8d55-4b6a25fb0ad2)')

检查K8S，ragflow-redis-6df4956d9d-rr2dt Init:ImagePullBackOff，且在RAGFlow网页-系统中也有报错提示：

RAGFlow助手应用实践_数据_02

恢复POD：ragflow-redis后等一会即正常。

8、事实：（向量转化是在数据库以外完成）

能力再强大的 LLM 也只能取代人的学习和推理能力，无法取代存储和访问数据的能力；参数再多的 LLM 也不能仅凭基于通用数据的训练就能精确表达企业内部海量且丰富的数据。而处理这类数据，才是服务企业或者私有场景的主要需求。
无论 LLM 能力发展到何种地步，只要它服务于企业，就必然需要接入企业的各类数据，包括各种文档、日志、数据库；就要面临各种跟这些数据源打通的各类问题：权限、数据清洗、数据入库、跨数据源查询。这些问题都不是 LLM 本身能够解决的。

因此，答案显而易见：RAG 将长期存在。而 RAG 搭载的核心数据库也需要不断升级迭代，以适应 RAG 未来的演进趋势，满足 RAG 长期进化的要求。这正是我们开始研发 Infinity 的主要原因。

用更好的 embedding 模型获取更好的向量：在把文字送进数据库之前，需要对文字做足够好的预加工，文字分片切也需要做得足够好，才能确保获得的向量是恰当的。
多路召回！多路召回！多路召回！重要的事情说三遍：没有多路召回的 RAG 没有未来！
排序（cross-attentional re-ranking）。所谓“跨注意力”指的是多路召回：多路召回的结果还需要经过良好的重排序（fused ranking）才能把最适当的结果交给 LLM。

2024-7-17 infinity 0.2.1（AI数据库：既可以向量查找也可以索引或者全文搜索） release了。关注向量数据库或者召回搜索等技术的同学，可以关注了解一下。0.2 版本里面主要增加的功能：

1. 对tensor的支持，支持在第一阶段召回和第二阶段重排序的使用
2. 支持稀疏向量和稀疏向量索引，相关benchmark可以在readme上看到
3. 支持以embedded形式，在python中直接使用infinity，而不需要启动server
4. Reranker 新增weighted sum; 向量距离计算支持cosine; 支持导出csv和jsonl格式; 链接: https://github.com/infiniflow/infinity

另外，RAGFlow 计划会在infinity 0.3版本发布之后，开始集成和逐步替换现在在RAGFlow中使用的数据库系统，如elasticsearch等。

8.1、RAGFlow底层依赖于数据库做信息召回。目前用的是ES，后面打算把infinity也加入支持列表。计划的集成策略是渐进式的，也就是在比较长的一段时间里，RAGFlow会同时支持两个数据库。

首先RAG框架和数据库，的确不是一个东西，不会缝合在一起。但是RAG的能力，确实依赖于数据库。再有，infinity 数据库本身目标是信息检索和召回。这部分，现在也还有不少可以挖掘的空间。目前infinity的性能比所有“向量数据库”都好。然而对于rag来说，效果比性能更重要，目前所有的试验都证明，混合搜索的方式越多，召回效果越好

8.2、infinity 是几路召回？bm25+vector+sparse vector+tensor reranker ，tensor也可以做召回，但做reranker收益更高

RAGFlow助手应用实践_数据_03

8.3、总的来说，传统的数据库无法服务好 RAG ，是因为缺乏以下这些搜索引擎必备的组件：

高效率的全文索引
多样化的排序手段
无处不在的自然语言处理

以上这些正是 Infinity 从一开始就着眼解决的问题。

8.4、Infinity vs. Elasticsearch

Infinity 从一开始就是按照一套完整的数据库架构来开发和设计的，着眼于三方面的能力：向量查询，全文搜索，结构化数据查询以及它们的融合排序。而 Elasticsearch 在十多年前就是企业搜索引擎。两者在技术层面的一个显著差异就是 Infinity 是有执行引擎的：一条查询请求进来之后会被编译成计算图，查询请求以流水线的方式在计算图流转，引擎会根据可用资源的数量决定计算图每个节点使用的并行度。而 Elasticsearch 这样的搜索引擎是没有执行引擎组件的：收到搜索请求以后，直接从倒排索引获取数据后排序返回，所有工作都在一个线程中完成。

9、问题Multi-Attach error

NAME                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
rook-ragflow-es      Bound    pvc-3880ae6a-d50c-49a3-a1e3-4bbebc082e91   100Gi      RWO            rook-ceph-block   57d 
# kr get pv pvc-3880ae6a-d50c-49a3-a1e3-4bbebc082e91  -o go-template='{{.spec.csi.volumeAttributes.imageName}}'
csi-vol-3de26aac-3361-11ef-9181-76733324c283 
bash-5.1$ rbd status replicapool/csi-vol-3de26aac-3361-11ef-9181-76733324c283
Watchers: none
！报错：
attachdetach-controller  Multi-Attach error for volume "pvc-3880ae6a-d50c-49a3-a1e3-4bbebc082e91" Volume is already exclusively attached to one node and can't be attached to another

在 Kubernetes 集群中，一个 PV 不能同时挂载到多个节点。当遇到 Multi-Attach 错误时，通常是因为 PV 已经被另一个 Pod 独占。解决步骤包括：检查 PVC 和 PV，识别 RBD 映像和日志池，定位挂载的 Node，使用 umap 解除映射，删除 VolumeAttachment。如果问题仍然存在，则需要进一步删除有问题的 VolumeAttachment。

9.1、PVC克隆，修改deploy的volumes.persistentVolumeClaim.claimName为克隆的PVC名称。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rook-ragflow-es-clone
  namespace: ragflow 
spec:
  storageClassName: rook-ceph-block
  dataSource:
    name: rook-ragflow-es
    kind: PersistentVolumeClaim
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
# kr edit deploy ragflow-es
      volumes:
      - name: ragflow-es
        persistentVolumeClaim:
          claimName: rook-ragflow-es-clone
#  kr describe pvc   rook-ragflow-es-clone
Used By:  ragflow-es-84db77cf6d-8rp68
# kr get pvc
NAME                    STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS  

rook-ragflow-es-clone   Bound    pvc-08c9966c-dd8e-4340-bdb0-e142f165aec0   100Gi      RWO            rook-ceph-block
#  kr get pv pvc-08c9966c-dd8e-4340-bdb0-e142f165aec0  -o go-template='{{.spec.csi.volumeAttributes.imageName}}'
csi-vol-d6bcd3ba-233c-4c6b-90b9-db250b7e4296
# kr describe pv pvc-08c9966c-dd8e-4340-bdb0-e142f165aec0
imageName=csi-vol-d6bcd3ba-233c-4c6b-90b9-db250b7e4296
# k -n rook-ceph exec -ti rook-ceph-tools-f6f94bfcb-7d4c5 -- bash
bash-5.1$ rbd status replicapool/csi-vol-d6bcd3ba-233c-4c6b-90b9-db250b7e4296
Watchers:
        watcher=172.17.54.128:0/1615016135 client.63582600 cookie=18446462598732840969

10、RAGFlow 0.10.0 发布! 更新如下:

支持text2sql
提供Agent API
提供针对task_executor的状态监控
新增更多Agent算子: Github，DeepL，百度翻译，QWeather，GoogleScholar等
新增指出eml文件格式
支持更多模型/推理服务: Cohere/GPT4o-mini/PerfXCloud/TogetherAI/Uostage/Novita.AI/零一万物/硅基流动/讯飞星火/百度文心一言/腾讯混元

11、测试 text2sql 记录

ExeSQL组件：循环上限（loop为当前组件循环次数上限，当循环次数超过loop的值时，说明组件不能完成当前任务，请重新优化agent）超过6时，有以下报错。

——回复：现在上限是6，loop值过大没有意义，3左右比较合适。

OverflowError('Too much loops: Generate => Switch => ExeSQL => Generate => Switch => ExeSQL')

同一个问题，有时需要多问几次才有输出。

问：查询AirNet系统中的有关CCA1353航班的FDP处理记录内容     //有时需要多执行几次才有输出
答：
Total: 59
plandata
0	b'\n7\n\x04FDP1\x12\x03fdp"\x172024-08-13 22:51:06.708(\x8b\xd8\xcd\x020\xf7\x82>8\xab\xcf\x02P;X\x01p\x01\x12\xfb\x02\n\xe5\x01\x08\x03\x10\x8c\x01\x1a\x98\x01\n\x07CCA1353\x1a\x03DEP:\x04ZBAAB\x03PEKZ\x04ZJSYb\x03SYX\xaa\x01\x01D\xca\x01\x0e20240813064300\xd2\x01\x0e20240813064300\xda\x01\x0e20240813064300\xe2\x01\x0e20240813064300'
实际执行的sql：SELECT plandata FROM tab_history_plan WHERE callsign LIKE 'CCA1353';因为plandata字段类型是blob
解码Python代码：
data = b'\n7\n\x04FDP1\x12\x03fdp"\x172024-08-13 22:51:06.708(\x8b\xd8\xcd\x020\xf7\x82>8\xab\xcf\x02P;X\x01p\x01\x12\xfb\x02\n\xe5\x01\x08\x03\x10\x8c\x01\x1a\x98\x01\n\x07CCA1353\x1a\x03DEP:\x04ZBAAB\x03PEKZ\x04ZJSYb\x03SYX\xaa\x01\x01D\xca\x01\x0e20240813064300\xd2\x01\x0e20240813064300\xda\x01\x0e20240813064300\xe2\x01\x0e20240813064300'
for byte in data:
    if 32 <= byte <= 126:  # ASCII 可打印字符的范围
        print(chr(byte), end='')
    else:
        print('.', end='')  # 对于不可打印的 ASCII 字符，用 '.' 表示
执行：
[Running] python -u "c:\Users\admin\vscode-github\mi-git\tempCodeRunnerFile.python"
.7..FDP1..fdp".2024-08-13 22:51:06.708(....0..>8...P;X.p.................CCA1353..DEP:.ZBAAB.PEKZ.ZJSYb.SYX...D...20240813064300...20240813064300...20240813064300...20240813064300

plandata 是 BLOB 类型，在 MySQL 中CAST(plandata AS CHAR)将其转换为可读的格式，CAST 函数用于将一个值或表达式从一种数据类型转换为另一种数据类型。除了 CAST 函数外，还可以使用 CONVERT 函数进行数据类型转换——但是结果都是在mysql终端执行可读方式显示，在RAGFlow显示还是二进制方式。

SELECT CAST(plandata AS CHAR) FROM tab_history_plan WHERE callsign LIKE 'CCA1353';
SELECT CONVERT(plandata,CHAR) FROM tab_history_plan WHERE callsign LIKE 'CCA1353' LIMIT 1;

（还得用LLM能力来解决）通过在提问方式增加提示：查询AirNet系统中的有关CCA1353航班的计划处理记录，以ASCII方式显示,ok!（得使用glm-4大模型，使用qwen2测试不行）

RAGFlow助手应用实践_数据_04

以下报错表示大模型不通。

RAGFlow助手应用实践_批量添加_05

12、Ubuntu 24.04 LTS系统安装ollama后默认监听127.0.0.1，修改为监听0.0.0.0

# curl -fsSL https://ollama.com/install.sh | sh     //自动安装显卡、cuda驱动
# vi /etc/systemd/system/ollama.service
增加Environment="OLLAMA_HOST=0.0.0.0:11434"
# systemctl daemon-reload
# systemctl restart ollama
# ollama serve -h    //显示变量作用
OLLAMA_HOST                IP Address for the ollama server (default 127.0.0.1:11434)
OLLAMA_MODELS              The path to the models directory（default /usr/share/ollama/.ollama/models）

13、知识库解析文档，卡在这里

RAGFlow助手应用实践_批量添加_06

新的dev版本又加了一个task executor的监控。估计是那个进程有问题。top有该进程，进入POD手动再次运行 # python3 rag/svr/task_executor.py 后解析正常。后再次出现解析文档卡住的情况，手动运行task_executor.py，也不行，报错：

assert tasks, "{} empty task!".format(msg["id"])
AssertionError: f110676c6a5111ef906612e6cd198ec5 empty task!

——>原因是有个empty task的bug修过，更新swr.cn-north-4.myhuaweicloud.com/infiniflow/ragflow:dev 后正常。

另解析文档时选了RAPTOR，会调用在设置-“系统模型设置”中指定的聊天模型（所有新创建的知识库都会使用默认的聊天LLM。），该大模型调用出错时，解析文档会报错“**ERROR**: upstream connect error or disconnect/reset before headers. reset reason: remote connection failure, transport failure reason: delayed connect error: 111”

14、聊天 API 点击“预览”或“嵌入”，提示“请先创建 API Token!”