infiniflow/ragflow

如果你做 RAG 的痛点出在文档层——扫描版 PDF、无框线表格、格式混杂的办公文件——而不是向量库层，RAGFlow 值得认真试一次。但要留出真实的部署时间，并且用手上最难解析的文档验证切分质量，而不是拿示例文件判断。

解决什么问题

你想就一批内部文档提问，并拿到带出处的答案。常规做法是抽文本、切块、向量化、再拼一个聊天界面；问题在于抽取这一步会把最要紧的内容弄坏——表格、多栏排版、扫描页——后面所有回答都继承这些错误。RAGFlow 把工作前移到可视化的文档解析流程：结合版面结构解析文档，切块结果可人工查看和调整，检索基于这份清洗过的上下文。最终得到的是能追回到具体文本块、且你亲眼确认过的答案，而不是一个看不出所以然的相似度命中。

有什么不同

机制核心是深度文档理解加上显式的切块模板，README 用“输入质量决定输出质量”来概括这组搭配（项目说明）。切块过程可视化、可编辑，所以切分方式在变成检索事实之前就能被检查和修正，答案也附带可追溯的引用。在此之上，项目持续叠加 Agent 式检索：模型可以拆解复杂问题、多轮检索并核对证据，用 Low/Medium/High/Ultra 四档思考模式控制每次查询的检索与推理深度。2026 年 8 月加入的知识编译功能，还能把文档和数据集内容整理成 Wiki、图谱、树、思维导图、时间线和“技能”等结构化产物（发布记录）。

代价是功能面铺得很宽。Agent、编译模板、思考模式每一层都是新的配置项和新的排查对象；给检索放权越多，越难解释某段文本为什么被用上或没被用上。把 Agent 模式当作需要在你自己的问题上和普通检索对比的选项，而不是默认就更强的开关。

谁值得试

适合瓶颈在异构素材的团队：财报与合同、扫描报告、表格多的 Excel、幻灯片，或者普通文本抽取会把表格拍平的内部知识库。如果你需要在这类语料上拿到带引用的回答，并且愿意花时间复核切块，可视化的解析流程就是选它而不是自己拼一堆解析器的理由。反过来，如果你的语料本来就是干净文本、检索链路也跑得通，这套文档加工几乎没有收益，多出来的配置只是负担。想先看效果再决定是否本地部署的，可以用官方托管的 RAGFlow Cloud。

使用条件与边界

项目给出两条路径：云服务和需要你自己运维的本地部署。本地部署是一整套多服务系统——仓库主语言是 Go，但系统横跨多个组件——意味着你要管理服务、存储和模型配置，而不是运行一个单文件程序。Agent 相关能力依赖有能力的模型；思考模式和知识编译会增加模型调用与处理时间，问题复杂度会直接影响响应延迟和开销。

解析质量还高度依赖具体语料。2024 年有评论者称赞布局识别模型能正确处理某些单列无框线表格，连付费 API 都漏掉了，但明确说没有基准测试、结果也可能是碰巧（HN 评论，2024-04-01）。这个保留意见正好说明了该怎么评估：拿自己最糟糕的文档去试，而不是拿示例 PDF。

HotRepo 点评

HotRepo 可追踪的记录很有限：2026 年 8 月有 4 天出现在日榜，最近一次是 2026-08-15 的 88,511 星；2026-10-27 在 Go 周榜排第 #17。据此无法判断热度能否持续。真正需要在采用前确认的一件事，是当前解析流程对你手头最难处理的表格或扫描件效果如何——README 里的后续版本与 2024 年的解析反馈相隔多个版本，只有你自己的文档能回答这个问题。