🎯 TLDR   关键字：

BERT架构、ColBERT、分段标识符、GET/POST 请求、quote=true、milvus、多路召回、Poetry、GitHub Actions、baiduYiyan、TRACE_MALLOC_DELTA，TRACE_MALLOC_FULL

Tip:

  • vllm部署的模型通过OpenAI-API-Compatible模型厂商添加；
  • Dify 和 FastGPT 的选型：其实有一个非常重要的关键点，Dify线上版至今还不支持多LLM并行，而FastGPT 稳定支持。在某些业务场景下，这一点就足以决定选型了。
  • 24年中秋节前升级到 v0.11.0 版本：支持使用 Postgres 替代 MySQL 存储 RAGFlow 元数据
  • 20240924最新的版本大小从10.6 GiB 变为4.1 GiB，去掉了内置的embedding和rerank模型。
  • Please try infiniflow/ragflow:dev-slim. Only 1GB, without embedding models. You need to setup model provider before creating a knowledge base.
  • 在 0.12 版本中，对社区长期反馈的 Docker 镜像过大的问题进行了修正。新版本的 RAGFlow 分为 2 个镜像，一个是原来的All In One镜像，里边包含了本地可运行的 Embedding 模型和 Reranker 模型。由于这些模型推理，需要依赖完整的模型推理，因此导致 Docker 镜像过大，对于国内用户的下载非常不友好。另一个是裁剪后的 Slim 版本镜像，该镜像拿掉了本地运行的 Embedding 模型和 Reranker 模型，因此尺寸大大降低到只有 1 G，当然在使用该镜像的时候，一切依赖于模型推理的服务，都需要在外部配置。例如可以用 Ollama 或者 Xinference 启动 本地Embedding 模型和 Reranker 模型，也可以直接配置采用其他的 SaaS 服务。而大家关心的文档解析模型 DeepDoc，由于它可以只依赖 CPU 运行，因此两个版本内置都包含。在后续的版本中，除了功能和对话效果上的迭代之外，我们还将持续改进 RAGFlow 的易用性和稳定性。
  • 为啥没用milvus的，milvus不支持全文搜索，所以没办法采用，milvus多路召回只包含向量和稀疏向量，而稀疏向量是无法取代全文搜索的。
  • RAGFlow 是否有一个超级账户可以看到所有知识库，而其他账户只能看到自己的知识库？No supper user yet.
  • RAGFlow的GitHub使用的 Poetry 提供了一个现代化的工具集，使得 Python 开发者在管理项目依赖和打包时更加高效和便捷。GitHub Actions：GitHub 提供的持续集成和持续部署平台。可以通过配置 YAML 文件来定义工作流，与 Poetry 项目集成后，可以实现自动化的测试、构建和部署流程。
  • RAGFlow开源星标迅速增长的第一个原因，就是RAGFlow内置的组件DeepDoc，它能够对用户的非结构化文档进行布局检测，确保文字能够在保持语义的前提下再进行Text Chunking。
  • RAG中的一个典型痛点，就是问题和答案之间的语义鸿沟：
  • 措施1、RAPTOR，先对文档做聚类，然后让大模型针对聚类生成摘要，这些信息连同原始文本共同做混合搜索，给出答案。
  • 措施2、利用GraphRAG，让知识图谱构建这件事变成自动化和标准化；
  • RAGFlow当中，我们把Agent和工作流看做一回事。站在RAGFlow的视角，在Agent这件事情上，RAGFlow的定位从来都很清晰，RAG作为一个核心技术组件，它要解决的问题是RAGFlow的核心。如何使用RAG，这就是Agent层面的事情，可以把RAGFlow当作一个App Store那样来使用这个市场里的各种App（Agent），也可以采用外部的Agent/工作流工具来编排RAGFlow，这一切取决于用户自己的方便程度。
  • RAGFlow为什么只采用Elasticsearch，而没有采用其他向量数据库：因为Elasticsearch是开源数据库当中，为数不多可以兼具全文搜索和向量搜索两路混合召回能力的数据库（具备类似能力的云数据库Rockset，刚刚被OpenAI收购不久）。
  • 一个事实，RAG已经是一种事实上的落地标准架构，尽管它面临这样那样的问题，但确实没有其他方案可以取代。
  • 微调对比RAG：从成本和实时性角度，RAG具有压倒性优势，而效果上相差也并不大，即使需要微调介入的场景，RAG通常也不可或缺。
  • 长上下文LLM对比RAG：这个争议到如今也接近偃旗息鼓，结论同样很清晰，两者是天然的组合，在能力上取长补短。来自多方面的研究已经证实，单纯就AI能力来讲，长上下文LLM依然面临在上下文段落增加时准确率不断下降的事实，因此，在任何情况下，提供高精度的搜索系统（RAG）都是极有价值的。

RAGFlow优化 Tips_数据集

  • chunk在es和infinity里面，文件在minio里面——所以文件下载不下来，不可能是是infinity数据库的问题
  • AGFlow 0.14.0 发布！在本次版本迭代中，共有 197 个 PR 合并进入主分支，新增了 18 位贡献者，下面是 0.14.0 的主要更新内容：
  1. 同时支持 Infinity 和 ElasticSearch 两种引擎存储向量和全文索引，目前默认是Elasticsearch。
  2. 增加 Agent 对变量的支持，以及自动保存等交互优化。
  3. 新增了 Andrew Ng 的三步翻译 Agent 模板和支持 SEO 优化的博客生成 Agent 模板。
  4. 增加了对 Agent 对话的API。
  5. 在召回阶段，支持了英文同义词。
  6. 对 Term weight 的计算进行了优化，使召回用时减半。
  7. 加强了对 Task Executor 的监控。
  8. 使用 Valkey 替换 Redis
  9. 新增支持语言：印尼语，西班牙语，越南语
  • RAGFlow 0.14.1 发布！ 该版本共包含 38 个 commit，主要解决了 0.14.0 中的几个严重的错误以及 Infinity 配置的问题，更新内容如下：
  1. Infinity 本身的配置可以在 docker/infinity_conf.toml 中修改。修改文件后，重新启动 docker compose 生效。
  2. 解决打开 Chunk 界面无法显示和修改的问题
  3. 解决中文文本解析乱码问题
  4. 解决 Elasticsearch 'Not found error'
  5. 解决 Polars 库的兼容问题
  6. 解决 Infinity 无法适配 GraphRAG 的问题



1、优化模型

面壁智能推出小钢炮开源 MiniCPM3-4B AI 模型：MiniCPM3-4B 是 MiniCPM 系列的第三代产品，整体性能超过了 Phi-3.5-mini-Instruct 和 GPT-3.5-Turbo-0125，媲美多款 70 亿～90 亿参数的 AI 模型。支持函数调用和代码解释器。

  • 面壁智能还发布了 RAG 套件 MiniCPM-Embedding 模型和 MiniCPM-Reranker 模型，针对 RAG 场景还发布了微调版 MiniCPM3-RAG-LoRA 模型。

2、Cohere 公司发布了最新版本的 Command R 和 Command R+ 模型，这些企业级 AI 模型经过优化，专为商业应用场景设计。新版模型在编码、数学、推理和延迟方面进行了显著提升，特别是在处理检索增强生成 (RAG) 和多语言支持方面表现出色。

  • RAG 精度：改进了多语言环境下的检索增强生成功能，增加了行内引用，帮助用户验证模型输出，减少错误或“幻觉”的产生。

 3、Jina AI发布 Jina ColBERT v2版本，基于BERT架构开发，旨在优化查询和文档之间的匹配和排序。用于在搜索引擎、推荐系统、问答系统等应用中实现高效、精确的信息检索和排序。

  • ColBERT 是一种专门用于信息检索的模型，名字来源于 “Contextualized Late Interaction over BERT”（基于BERT的上下文化后期交互）。它结合了BERT模型强大的语言理解能力，并在此基础上引入了一种新颖的“后期交互”机制，使得搜索变得更加高效和精准。
为什么ColBERT如此特别？
  • 高效检索：传统的搜索模型在处理查询时，需要对每个可能的文档进行大量计算，而ColBERT可以预先计算并存储文档的编码，查询时只需简单对比，速度更快。
  • 支持大规模数据：由于文档编码可以提前完成，ColBERT特别适合处理大规模数据集，例如数百万甚至数十亿条文档的检索任务。
  • 节省存储空间：ColBERTv2通过压缩技术，显著减少了模型的存储需求，使得在大规模数据集上使用也不会占用过多的存储资源。

4、知识库的解析方法选择“General”，分段标识符的配置只看单字符，例如配置//，只认单/

5、v0.11.0 版本

  • 支持对语音文件中识别的文字内容解析，文档解析，传入音频文件解析成文字，主要看ASR模型（ Tencent Cloud ASR，支持对语音文件中识别的文字内容解析）是否支持，系统只是把binary给出去——在知识库--配置下的解析方法下拉框内没有audio这一项，因为音频文件的解析没得选，会强制autdio不需要配。
  • AI Search，智能回答这块使用系统默认LLM，并参考选中的知识库的搜索结果。
  • 新增RAGFlow 召回测试 Benchmark，在哪里：rag/benchmark.py

 6、在RAGFlow的API方式，不显示引文，解决：post请求，加参数quote=true

  • GET 请求：参数通常附加在 URL 中，以 “?” 开始，多个参数之间用 “&” 连接。例如：https://www.example.com/search?q=apple&category=fruit。参数会在浏览器地址栏中显示，因此不太适合传输敏感信息。由于 URL 长度有限制（不同浏览器和服务器限制不同，但一般在 2048 个字符左右），所以能携带的数据量相对较小。出现报错“AttributeError("'list' object has no attribute 'get'")”，在 Python 中，当出现 “AttributeError: 'list' object has no attribute 'get'” 错误时，原因主要在于列表（list）数据类型本身并不具备名为 “get” 的属性或方法。
  • If you want to see reference in ip:port/chat/share?shared_id=ragflow-IzN2JjNTc4NzY5ZTE4NGVhZT&from=chat. You can try to change the source code which is in api/apps/api_app.py line 197. if "quote" not in req: req["quote"] = False.
ragflow/api/apps/api_app.py
 197行：  if "quote" not in req: req["quote"] = False
  • POST 请求：参数通常放在请求体中传输。参数不会在地址栏中显示，相对安全，适合传输敏感信息。可以传输的数据量通常比 GET 请求大，理论上只受服务器性能和配置的限制。

如果涉及敏感信息，如用户密码、信用卡信息等，应选择 POST 请求。因为 GET 请求将参数暴露在 URL 中，容易被他人窃取，而 POST 请求的参数在请求体中，相对更安全。某些 API 可能明确规定某些操作只能通过 GET 请求进行查询，而某些操作必须使用 POST 请求进行数据提交。

7、聊天回答中的引文，PDF/docx格式的点击可以打开，md/doc等格式的点击是空白，原因：文件类型不支持。

8、聊天中提示知识库中未找到答案。有两种情况，你可以添加代码调试信息，一种是你检索到了块但无法回答，这种大模型能力问题，换成能力更强的大模型应该能够解决，另一种是根本没有检索到相关的块信息，或者检索到的输出是其他块信息，当然，输出也不会找到相关内容，原因可能是RagFlow自身的策略是根据历史问题的组合进行检索，这可能导致当前问题的权重被降低。 可以点击这里来区分这两种情况。

RAGFlow优化 Tips_信息检索_02

9、添加模型百度模型，一言 API KEY和一言 Secret KEY需要在“百度智能云”里“模型服务”创建“应用接入”来获取。

baiduYiyan    :   
 模型类型:chat
 模型名称:ERNIE-4.0-8K
 一言 API KEY:xxx
 一言 Secret KEY:xxx

10、《阿里云 AI 搜索 RAG 大模型优化实践》2024年11月01日摘要：

RAGFlow优化 Tips_信息检索_03

  • 响应速度问题。如果需要达到较好的效果，可能需要使用 72B 参数以上的模型；
  • Query 理解非常关键，如果能够准确理解用户的查询，那么检索到正确的文档，回答的质量基本上就有 80% 的保证。在 Query 理解方面也采取了多种策略来处理不同的问题；
  • 进行语义切片时，切片内的语义不完整：模型本身倾向于补充文本，因为它的预训练就是做文本补充。因此，它可能会根据它自己的知识生成答案，这样的回答通常都是错误的。切片可能只包含了某个步骤的一部分，模型在回答时也只回答了这部分内容，而遗漏了剩余的步骤。——提取出文档的层级结构，使切片更加完整；
  • 如果客户上传了一个 PDF 文件，会调用 PDF 解析 API，并使用结构化模型抽取 PDF 的语义层级结构，将其转换成 Markdown 文档。然后，会对文档进行切片。切片后，我们会为文档生成 embedding，包括文本的和混合索引。
  • 随着模型能处理的上下文长度越来越长，我们面临一个问题：是否还需要进行切片？理论上可以直接将整个文档输入到大模型中，让它直接生成答案，而无需进行切片。但经过我们的测试，长文本处理仍存在一些问题。首先，处理长文本会增加计算复杂度，导致耗时和成本增加。这是因为输入上下文的长度增加，计算复杂度呈平方增长，从而显著增加了处理时间。其次，更重要的是信息丢失的问题。我们测试了 GPT-4 128K 版本，发现当输入长度达到 30 多千字时，模型开始遗漏信息，导致回答不完整。文档中的噪声数据也使得模型难以精确提取信息。我们目前的策略是适当增加切片的长度，而不是完全放弃切片。我们仍在探索更好的结合长文本处理和切片的方法，以提高效率和准确性。
  • 在 RAG 环境下，即使是 GPT-4 这样的大模型，也存在大约 7% 的幻觉率。对于更小的模型，如 14B 或 7B，幻觉率通常在 20% 以上。
  • 微调过程中最大的挑战是如何评估和生成数据。

11、k8s升级istio后，“chat”和“知识库/检索测试”报错：ERROR: [Errno -5] No address associated with hostname，去掉sidecar（k label namespace ragflow  istio-injection- ），模型提供商-添加 LLM-基础 Url使用IP地址后正常，应该是之前调用embedding和chat模型使用istio的域名导致的，这与告警提示也相关——No address associated with hostname！

12、ragflow/rag/svr/task_executor.py支持两个环境变量TRACE_MALLOC_DELTA，TRACE_MALLOC_FULL，可用于诊断堆内存问题。def main()代码可用于监测程序在执行大量任务时的内存使用情况，帮助开发者发现内存泄漏或优化内存使用。

find . -type f -name "*.py" -exec grep "TRACE_MALLOC_FULL" {} +      //在当前目录及其子目录下的所有文件中搜索关键字"TRACE_MALLOC_FULL"