您说:
补充表格中的空白字段,你需要阅读并理解表中每个开源项目
为了补充表格中这些开源 RAG 项目的空白字段,我需要进一步明确以下几点:
是否需要涵盖所有字段的补充?例如:文档格式、嵌入模型/检索方式、向量数据库、最大Token数、文档解析方法。
你是否只关心这些项目的默认配置,还是也包括它们支持的可选配置?
是否有时间或版本限制?比如仅考虑2025年的最新信息,或者只看稳定版本?
请分享你的具体要求,这样我可以更准确地进行补充。
明白了。我将会补充表格中以下开源 RAG 系统(RAGFlow、AnythingLLM、LlamaIndex、Mem0、GraphRAG、lightRAG)在2025年最新稳定版本中所有空白字段,包括默认配置与可选配置,涵盖:文档格式、嵌入模型/检索方式、向量数据库、最大 Token 数、文档解析方法。
我会尽快整理详细信息并反馈给你。
补充开源 RAG 项目的空白字段信息(2025年最新版)
项目 | 文档格式 | 嵌入模型/检索方式 | 向量数据库 | 最大 Token 数 | 文档解析方法 |
---|---|---|---|---|---|
RAGFlow | 支持多种复杂格式:Word文档、PPT 幻灯片、Excel表格、纯文本、图片(包括扫描件)、结构化数据、网页等github.com。 | 默认采用向量+关键词混合检索:使用嵌入向量相似度结合关键词权重的混合搜索ragflow.io。内置向量嵌入模型包括 BAAI 的 bge-large-zh-v1.5 和 bce-embedding-base_v1(完整版 Docker 镜像已预载)ragflow.io。支持配置自定义 LLM 和嵌入模型github.com;高级检索可选知识图谱、自动关键词和自动问题等策略用于增强检索ragflow.io。 | 默认使用 Elasticsearch 存储全文和向量索引github.com;可选切换为自研的 Infinity 向量数据库(通过设置环境变量 DOC_ENGINE=infinity )github.com。 | 文档总长度理论上不受限——RAGFlow 能处理“几乎无限”长度的语料github.com。单次问答的上下文长度取决于所配置的 LLM 模型(例如 OpenAI GPT-3.5/4 通常4K~8K Tokens 等),系统本身无固定限制。 | 具备深度文档理解解析:对复杂文档进行模板化切分github.com。默认采用智能模板式分块策略,将文档划分为更小单元(可视化切分结果便于人工调整)github.com。能够提取文档中的文本、表格和结构信息firecrawl.dev,找到“大文档中的针”般的细粒度内容github.com。 |
AnythingLLM | 支持多种文件类型:例如 PDF、TXT、DOCX 等常见文档格式github.com(拖拽上传后自动解析)。 | 默认使用内置本地嵌入模型(AnythingLLM Native Embedder)生成向量github.com并进行相似度检索;也可选用第三方嵌入服务(OpenAI、Azure OpenAI、LocalAI、Ollama、Cohere 等)替代github.com。检索主要通过向量语义相似度搜索在选定的向量库中找出相关片段。 | 默认集成开源向量库 LanceDBgithub.com存储嵌入;可选支持 PGVector、Astra DB、Pinecone、Chroma、Weaviate、Qdrant、Milvus、Zilliz 等多种向量数据库github.com。 | 上下文容量取决于所选用的LLM模型。系统本身无固定Token上限:例如,使用OpenAI GPT系列可达4K或8K以上上下文;内置可下载的本地模型(如 “Llama-3”、“Phi-3” 等)一般支持约2K上下文docs.anythingllm.com。 | 文档上传后自动切分处理:系统会将文件内容自动拆分为较小段落并嵌入向量,无需手工配置reddit.com。默认采用内置的PDF等文件解析管道将文档拆解,并保留引用以在回答时提供来源。具体切分粒度未明确公布,一般按固定长度或段落进行分块。 |
LlamaIndex | 支持广泛的数据源和格式:可从API、数据库以及本地文件加载,例如 PDF、Office文档、Markdown/HTML文本、图片音频(通过OCR/转录)等firecrawl.devdocs.llamaindex.ai。内置 Readers 和 Connectors 可处理CSV、DOCX、EPUB、Markdown、PDF、PNG/JPG图片、PPT、MP3/MP4等多种类型docs.llamaindex.ai。 | 默认使用 OpenAI 的 text-embedding-ada-002 模型生成文本嵌入docs.llamaindex.ai并构建向量索引,实现语义检索。支持灵活配置嵌入模型:可替换为本地 HuggingFace 模型等自定义 Embedderdocs.llamaindex.ai。除向量检索外,LlamaIndex 还支持关键词索引和知识图谱索引等方式,可根据需要选择不同检索模式firecrawl.dev(例如简单关键词匹配或图谱遍历)。 | 默认使用内存向量存储(SimpleVectorStore)保存嵌入docs.llamaindex.ai;亦支持超过20种外部向量库(通过模块化集成),例如 Pinecone、PGVector/Postgres、Qdrant、Weaviate、Chroma、Milvus 等github.comdocs.llamaindex.ai。用户可根据需求选择不同存储后端。 | 默认将 LLM 上下文窗口大小设为 4096 tokens(与 GPT-3.5 相符)docs.llamaindex.ai并预留部分输出长度(默认保留256 token生成空间docs.llamaindex.ai)。实际可处理的总 Token 数取决于所用底层模型的上下文限制(可通过 Settings.context_window 调整以匹配GPT-4等更长上下文模型docs.llamaindex.ai)。 | 内置节点解析/文本分割器,将文档拆解为较小的“节点”块。默认使用 SentenceSplitter 按 ~512 个 token 大小分块,重叠20个 tokendocs.llamaindex.ai。这种分块策略确保每块内容长度适中,且通过 overlap 保留上下文衔接。分块后的节点向量化后用于索引。docs.llamaindex.ai用户可通过修改 Settings.chunk_size 和 chunk_overlap 调整分块长度。 |
Mem0 | (不以外部文件为主要知识源)以会话文本和用户信息为记忆内容。不直接解析PDF等文档,而是存储对话记录、用户偏好等文本形式数据作为长期记忆。 | 采用语义向量+图谱结合的记忆检索:通过嵌入模型将对话内容编码为向量,支持语义相似检索重要片段,同时利用图数据库跟踪实体关系和引用频次,实现记忆的相关性和新鲜度排序firecrawl.dev。默认需要配置一个LLM用于分析摘要对话内容(默认使用 OpenAI 的 gpt-4o-mini 模型)github.com;支持多种LLM和嵌入来源,例如 OpenAI、Azure、Ollama 本地模型、HuggingFace、Gemini、Vertex AI、Together等提供的嵌入模型docs.mem0.ai。记忆写入时由LLM自动提取关键信息存储,检索时结合嵌入相似度和图关系查询返回最相关记忆。 | 双层存储架构:使用向量数据库存储记忆向量,图数据库维护实体关系firecrawl.dev。默认情况下,Mem0 内置嵌入式向量库(如 ChromaDB)本地持久化记忆向量medium.com,并在内部维护关系图谱。亦支持用户自定义后端:Mem0 提供配置对接 Milvus、Postgres/PGVector、MongoDB、SQLite、Redis、Qdrant 等多种向量数据库,以及可选图数据库(如 Neo4j)以实现分布式存储firecrawl.devdocs.mem0.ai。 | 受限于所使用的 LLM 上下文窗口。Mem0 本身对存储的单条记忆长度未明确限制(可按需要将长对话摘要后存储,以节省长度)。默认 OpenAI GPT-4 系列模型上下文 ~8K tokens(“gpt-4o-mini” 属于 GPT-4 模型家族)github.com;Mem0 会针对每次查询自动检索少量最相关记忆片段加入提示,以确保不会超过模型上下文大小。 | 自动会话摘要与更新:Mem0 的文档解析侧重于对话内容的处理。它拦截每轮对话,将消息内容经过LLM处理提取关键信息(实体、事实等)并生成记忆条目存储firecrawl.dev。记忆库会随着交互不断更新,能自动消歧和合并重复或冲突信息firecrawl.dev。对于长对话,Mem0 可利用滚动摘要将旧对话压缩存储,从而长期保留重要信息,形成用户的个性化长期记忆。 |
GraphRAG | 支持纯文本(.txt)、CSV(按行作为文档)、JSON(对象数组)等文本数据格式microsoft.github.iomicrosoft.github.io。不直接解析二进制文档(PDF等需先转换为文本)。 | 知识图谱增强检索:GraphRAG 将文档内容构建为知识图谱用于检索,从而超越单纯向量匹配microsoft.github.io。默认使用 OpenAI GPT-4 系列模型执行问答(内置针对 GPT-4/GPT-3.5 的提示优化)microsoft.github.iomicrosoft.github.io。在查询阶段,系统结合全局语义搜索和基于图的局部搜索:既可进行向量相似度检索(基线RAG方式),又利用知识图谱关系在关联节点中检索答案线索microsoft.github.io。GraphRAG 主要针对 OpenAI 接口设计(需OpenAI兼容API)microsoft.github.io;也支持通过代理 API 接入非OpenAI模型(提供兼容的接口即可)microsoft.github.iomicrosoft.github.io。 | 无专用向量数据库模块:索引数据存储在内存数据结构中(采用 Pandas DataFrame 和 NetworkX 图等)medium.commicrosoft.github.io。构建索引时,会将文本拆分和向量化并暂存于本地(小规模可直接内存,大规模部署可结合 Azure 云资源); 图结构存储在Neo4j等图数据库中只在加速器方案中涉及,开源代码默认仅用 Python 数据结构表示知识图谱。 | 默认使用 OpenAI GPT-4 模型回答,单轮上下文窗口 ~8,192 token(GPT-4 8k版本)microsoft.github.io。GraphRAG 通过检索相关文档片段来辅助LLM,无需将整个语料塞入上下文,因此文档总规模不受单次Token限制。但在一次回答中引用的知识量受模型上下文限制(GPT-4 可扩展到32k等更大窗口模型)。过去版本曾显式使用 max_tokens 控制回复长度,但2.2.0后改为通过提示控制,通常让模型留出约20%上下文生成空间microsoft.github.io。 | 分块+图谱构建:首先将原始文档按 Token 大小切分成小块(默认每块约1200个Token)newsletter.theaiedge.io并可配置 chunk_size 和 overlap。然后利用 LLM 对每个文本块进行知识三元组抽取,识别其中的实体及它们之间关系,生成诸如 [实体1, 实体2, 关系] 的三元组列表newsletter.theaiedge.io。这些三元组被用于构建文档的知识图谱结构,节点表示实体/概念,边表示关系。查询时,模型在知识图谱上执行全局检索(如向量相似找相关节点)和局部检索(图邻域扩展)相结合,从图谱中提取组装出最终答案microsoft.github.io。 |
lightRAG | 支持多种文件类型:内置 Textract 支持直接导入 PDF、Word(.DOC)、PPT、CSV 等文件并提取文本内容进行索引github.com;也可处理纯文本数据集。 | 双层检索架构:LightRAG 将图结构引入索引和检索过程,结合低层次的向量语义检索与高层次的知识图谱检索arxiv.org。索引阶段对文档既生成嵌入向量又构建知识关系图,查询阶段同时利用向量相似度和图谱关系进行综合检索,能高效找出相关实体及其关联信息arxiv.org。模型方面,支持注入多种 LLM 与嵌入模型:兼容 OpenAI 风格的聊天/嵌入接口(如 GPT-3.5/4 或国产OpenAI代理 Upstage 的Solar系列等)github.com;也支持纯本地 HuggingFace 或 Ollama 模型运行github.com。用户需在初始化时提供LLM调用函数和嵌入函数,默认示例使用 Upstage 提供的 Solar 小型模型(聊天模型“solar-mini”搭配嵌入模型“solar-embedding-1-large”)github.com。 | 默认采用本地文件存储方式保存索引数据:向量和图谱数据保存在工作目录下(称为“dickens”数据目录)的JSON文件中,便于快速读写(更换嵌入模型时需清空重建该目录)github.com。此外支持外部数据库集成:向量部分可选用 PostgreSQL(集成 PG Vector 扩展存储向量)github.com,图谱部分可选用 Neo4j 图数据库存储和查询实体关系github.com。这种可插拔存储设计使LightRAG既可轻量运行于本地文件,也能扩展到生产环境的数据库后端。 | 单次查询上下文限制取决于所用模型。LightRAG 示例中使用的 Upstage Solar 模型支持 8192 tokens 上下文输入github.com;如改用 OpenAI GPT-4 32k等模型则上限更高。LightRAG 本身通过减少每次提示中检索内容的碎片冗余来提高效率,因此在相同上下文窗口下往往比普通RAG容纳更多有用信息firecrawl.dev。 | 句级分割与增量图更新:LightRAG 将文档划分为细粒度句子级别的小块learnopencv.com,以确保检索的内容精细多样,避免冗余firecrawl.dev。在索引过程中,它对这些文本块执行与 GraphRAG 类似的预处理:抽取实体和关系并构建初始知识图谱learnopencv.com。LightRAG 实现了高效的增量更新算法,新文档或更新内容可及时融入图谱而无需重建全图arxiv.org。查询时采用双层检索:先全局向量检索锁定相关文本块,再通过图谱邻居扩展获取关联信息,最终综合得到准确且多样的结果arxiv.org。此外提供可视化界面用于浏览知识图谱和调试检索效果github.comfirecrawl.dev。 |
说明:以上信息依据各项目截至2025年发布的最新稳定版本官方文档和资料整理。如某些配置未在官方明确说明,已根据文档推导补充(例如 AnythingLLM 的默认分块策略等)。