您说：
补充表格中的空白字段，你需要阅读并理解表中每个开源项目
ChatGPT 说：
为了补充表格中这些开源 RAG 项目的空白字段，我需要进一步明确以下几点：
-
是否需要涵盖所有字段的补充？例如：文档格式、嵌入模型/检索方式、向量数据库、最大Token数、文档解析方法。
-
你是否只关心这些项目的默认配置，还是也包括它们支持的可选配置？
-
是否有时间或版本限制？比如仅考虑2025年的最新信息，或者只看稳定版本？
请分享你的具体要求，这样我可以更准确地进行补充。
您说：
1. 涵盖所有字段的补充
2. 关心这些项目的默认配置和可选配置
3. 考虑2025年的最新信息和稳定版本
ChatGPT 说：
明白了。我将会补充表格中以下开源 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 的默认分块策略等）。
ChatGPT 也可能会犯错。请核查重要信息。查看 Cookie 首选项。