RAGFlow Context Engine
将复杂数据处理为可检索、可溯源的 LLM 上下文与智能体工作流。
按维度查看评分与理由
证据显示：项目提供SECURITY.md，但其中披露了一个未修复的pickle反序列化漏洞（restricted_loads），这直接违反了最小权限原则（least_privilege），因为该函数允许导入numpy模块并执行任意命令。用户确认（user_confirmation）方面，没有证据表明在执行敏感操作前需要用户确认。数据流透明度（data_flow_transparency）方面，README描述了数据摄取和RAG流程，但未明确说明数据如何被处理或传输。敏感数据处理（sensitive_data_handling）方面，配置文件中包含API密钥和密码，但未说明如何安全存储。依赖安全（dependency_security）方面，pyproject.toml中列出了许多依赖，并包含CVE修复的约束，但SECURITY.md披露的漏洞表明依赖安全措施不充分。外部影响（external_effects）方面，项目支持与外部服务（如LLM、云存储）集成，但未说明这些交互的权限控制。回滚（rollback）方面，README提到可以切换文档引擎，但未提供明确的回滚机制。来源归属（source_attribution）方面，项目有明确的作者和许可证，但发布者未经验证。
证据显示：项目有详细的README和配置文档，自洽性（self_consistency）较好。依赖可用性（dependency_availability）方面，pyproject.toml列出了大量依赖，但未提供锁文件，可能影响可重现性。失败消息（failure_messages）方面，README提供了一些故障排除提示，但不够全面。
证据显示：项目面向企业和开发者，提供了多种部署方式（Docker、源码），受众和场景（audience_and_scenarios）明确。能力边界（capability_boundaries）方面，README列出了功能，但未明确限制。触发精度（trigger_precision）方面，未提供明确的触发条件。环境适配（environment_fit）方面，支持多种操作系统和架构，但ARM64支持有限。
证据显示：信息架构（information_architecture）清晰，README有目录。安装说明（install_notes）详细。命名稳定性（naming_stability）方面，版本号明确。示例和FAQ（examples_and_faq）方面，README提供了示例，但FAQ链接指向外部文档。已知限制（known_limitations）方面，README提到ARM64不支持，但未全面列出。许可证（license）为Apache-2.0，完整。版本变更日志（versioning_changelog）方面，README有更新日志，但未提供详细变更日志。维护责任（maintenance_responsibility）方面，项目有活跃的社区和贡献指南。
证据显示：输出可用性（output_usability）方面，项目提供API和Web界面，输出格式明确。边际价值（marginal_value）方面，项目提供了RAG和Agent功能，具有独特价值。成本效益（cost_benefit）方面，项目需要大量资源（CPU、RAM、磁盘），但未提供成本分析。
证据显示：声明可追溯性（claim_traceability）方面，README中的功能声明未提供具体实现细节。跨来源佐证（cross_source_corroboration）方面，未提供外部验证。事实与推断分离（fact_inference_separation）方面，README中的声明多为断言，未区分事实和推断。
- SECURITY.md 披露了一个未修复的 pickle 反序列化漏洞，可能导致远程代码执行，应避免在生产环境使用或尽快修复。
- 发布者身份未经验证，应谨慎评估供应链风险。
- 依赖众多且无锁文件，可能引入不可重现的构建。
这个 Agent 能做什么，适合哪些场景？
RAGFlow 是一个开源 RAG 引擎，将检索增强生成与 Agent 能力结合，用于构建 LLM 的上下文层。它使用基于 DeepDoc 的知识抽取处理非结构化资料，并提供模板化、可解释的分块流程。系统支持 Word、Slides、Excel、TXT、图像、扫描件、结构化数据和网页等来源，并以检索、融合重排序和可追溯引用支撑回答。可通过 Web 界面使用，也可用 Docker Compose 自托管；默认以 Elasticsearch 存储全文和向量，支持切换至 Infinity。开发部署包含 Python 后端、web 前端以及 MinIO、Elasticsearch、Redis 和 MySQL 等依赖服务。
RAGFlow 从 Word、Slides、Excel、TXT、图像、扫描件、结构化数据和网页等资料中提取知识；DeepDoc 负责复杂非结构化文档的理解与抽取。它按可选模板对内容分块，并展示分块结果以便人工干预。查询流程结合多路召回和融合重排序，产出带关键参考资料和可追溯引用的回答。其 Agent 提供预构建模板，README 还记录了可编排的摄取管道、MCP 支持、记忆能力，以及 Python/JavaScript code executor 组件。自托管时，docker-compose.yml 启动服务，默认由 Elasticsearch 保存全文和向量；将 docker/.env 中的 DOC_ENGINE 设为 infinity 可改用 Infinity。
- 企业知识团队需要把混合格式的内部文档整理成带引用的问答知识库。
- 开发团队需要在 Docker 环境中部署一个可配置 LLM 与嵌入模型的 RAG 服务。
- 需要审阅检索依据的客服或研究团队，希望查看文本分块及回答引用来源。
- 拥有扫描件、图片和复杂版式文档的团队，需要借助 DeepDoc 做知识抽取。
- 构建智能体工作流的开发者，需要在 RAG 数据集之上使用 MCP、记忆或代码执行组件。
这个 Agent 有哪些优点和局限？
- 基于 DeepDoc 的知识抽取面向复杂格式和非结构化文档，而非仅限纯文本。
- 分块结果可视化、关键参考资料和可追溯引用，为回答依据提供人工审阅路径。
- 支持多路召回与融合重排序，并允许配置 LLM 和嵌入模型。
- 可通过 Docker Compose 自托管，且默认 Elasticsearch 可切换为 Infinity。
- 自托管最低要求为 4 核 CPU、16 GB RAM 和 50 GB 磁盘，基础设施成本不低。
- 预构建 Docker 镜像仅面向 x86；ARM64 必须自行构建，且 Linux/arm64 上切换 Infinity 尚未获官方支持。
- 需要管理 Docker、系统 vm.max_map_count、LLM API_KEY，以及 Elasticsearch、MinIO、Redis 和 MySQL 等服务依赖。
- 代码执行沙箱功能依赖 gVisor；README 未说明不安装时该功能的替代路径。
如何安装或部署这个 Agent？
自托管前提为至少 4 核 CPU、16 GB RAM、50 GB 磁盘、Docker >= 24.0.0、Docker Compose >= v2.26.1；代码执行沙箱另需 gVisor。先确保 vm.max_map_count >= 262144，然后执行：git clone https://github.com/infiniflow/ragflow.git && cd ragflow/docker && git checkout v0.26.4 && docker compose -f docker-compose.yml up -d。容器日志 docker logs -f docker-ragflow-cpu-1 出现服务已监听 0.0.0.0 后，访问 http://IP_OF_YOUR_MACHINE。随后在 docker/service_conf.yaml.template 选择 user_default_llm 的 LLM factory，并填写对应的 API_KEY。
如何使用这个 Agent？
服务启动并完成初始化后，在浏览器打开 http://IP_OF_YOUR_MACHINE 登录。将资料导入知识库，选择合适的分块模板；可查看分块可视化结果并人工调整。配置所选 LLM factory 的 API_KEY 后，通过 RAGFlow 的界面以检索和引用方式获取回答。若需默认 Elasticsearch 以外的文档引擎，先停止容器，在 docker/.env 设置 DOC_ENGINE=infinity，再用 docker compose -f docker/docker-compose.yml up -d 启动。
这个 Agent 与同类方案有什么区别？
默认文档引擎为 Elasticsearch，可通过将 DOC_ENGINE 设为 infinity 切换到 Infinity。切换流程要求停止容器并使用 down -v；该操作会删除卷和现有数据。