知识库方案全景与对比
结论先行
知识库没有单一“最佳方案”。选型首先取决于知识是否需要长期维护、问题是否涉及关系与多跳、权限是否复杂、是否允许云端托管，以及团队愿意承担多少工程成本。
实用选择
- 只需要搜索：全文检索或企业搜索。
- 快速文档问答：混合 RAG 平台。
- 复杂 PDF/表格：优先选择强解析管线，如 RAGFlow/Docling/Unstructured 组合。
- 实体关系和多跳：GraphRAG 或“混合 RAG + 显式图谱”。
- Agent 长期知识：GBrain、Letta/MemGPT、Zep/Graphiti 等记忆层。
- 人工维护的长期知识：Obsidian/Notion/Outline 等 Wiki-first，再外挂检索层。
先区分四个层次
很多产品对比失真，是因为把基础设施、开发框架、应用平台和成品知识库放在一起。
| 层次 | 解决的问题 | 代表方案 |
|---|---|---|
| 存储与检索基础设施 | 文本、向量、图如何存储和查询 | Elasticsearch/OpenSearch、Postgres+pgvector、Milvus、Qdrant、Weaviate、Neo4j |
| RAG 开发框架 | 如何编排解析、索引、检索和生成 | LlamaIndex、LangChain、Haystack |
| 知识库/RAG 平台 | 如何低代码导入资料、配置检索并发布应用 | Dify、RAGFlow、FastGPT、AnythingLLM、MaxKB、Quivr |
| 知识管理/Agent 记忆产品 | 如何持续积累、组织、维护并在工作流中使用知识 | Obsidian、Notion、Outline、GBrain、Letta、Zep/Graphiti |
技术路线全景
1. 全文检索
核心是倒排索引、BM25、字段权重和过滤，不依赖 LLM 或向量。
优势：速度快、成本低、结果可解释；人名、编号、错误码、产品名和原句搜索稳定。
不足：难以理解改写、同义表达和抽象语义；不会自动生成答案。
适用：站内搜索、日志、代码、法规原文、已知关键词查找。
代表：Elasticsearch、OpenSearch、Meilisearch、Typesense、Postgres FTS。
2. 基础向量 RAG
流程是文档解析、分块、Embedding、向量 Top-K、上下文拼接和 LLM 回答。
优势：实现简单，能处理同义表达和自然语言提问，适合快速原型。
不足：精确词召回、多跳关系、全局总结和复杂权限较弱；分块质量决定上限。
适用：FAQ、产品手册、内部文档问答、小规模知识助手。
代表：任意 Embedding + pgvector/Qdrant/Milvus/Weaviate/Pinecone。
3. 混合 RAG
将 BM25/全文检索与向量检索并行召回，通过 RRF 或学习排序融合，再用 reranker 精排。
优势：同时覆盖精确匹配和语义匹配，是当前通用文档问答的稳健默认方案。
不足：参数、索引、过滤和评测更复杂；仍主要围绕 chunk，关系推理能力有限。
适用：大多数生产级企业知识问答。
代表：RAGFlow、Dify、FastGPT，以及基于 Elasticsearch/OpenSearch/Weaviate/Qdrant 自建的混合检索。
4. 分层与多阶段 RAG
增加父子分块、Small-to-Big、Multi-Vector、摘要索引、查询改写、HyDE、Self-RAG、Corrective RAG 等环节。
优势：能在召回粒度与回答上下文之间取得更好平衡，也能根据问题动态修正检索。
不足：链路越长，延迟、成本、失败模式和调试难度越高。
适用：长文档、复杂问题和对答案质量要求较高的场景。
代表：LlamaIndex、LangChain、Haystack 组合实现。
5. GraphRAG
从文本抽取实体、关系和社区摘要，查询时结合图遍历与文本证据。也可采用较轻的显式 WikiLinks/业务关系图。
优势：擅长实体关系、多跳问题、跨文档全局主题和“谁与什么有关”。
不足：图构建和实体消歧昂贵；更新、冲突、本体设计与权限传播复杂；并非所有问题都比混合 RAG 好。
适用：投研、风控、科研、组织知识、人物与公司网络、复杂项目依赖。
代表：Microsoft GraphRAG、Neo4j GraphRAG、LightRAG、HippoRAG；GBrain 使用显式链接图和检索图信号。
6. Agentic RAG
由 Agent 决定是否检索、选择数据源、拆解问题、反复搜索、验证引用并综合答案。
优势：能够处理多步骤研究、跨数据源查询和结果验证。
不足：延迟和费用高，行为不完全确定，权限与 Prompt Injection 风险更大。
适用：研究助手、尽调、复杂技术支持和跨系统工作流。
代表：LlamaIndex Agents、LangGraph、Haystack Agents、GBrain 的 think/Agent 工具链。
7. 长期记忆与知识运行时
不仅检索文档，还持续写入事实、事件、用户偏好、关系和综合结论，处理遗忘、冲突和时间变化。
优势：适合长期 Agent、个人知识和组织记忆，知识会随使用演进。
不足：错误记忆、隐私、删除、冲突与自动回写治理最困难。
适用：个人助理、客户关系、团队 institutional memory、长期自治 Agent。
代表：GBrain、Letta/MemGPT、Zep/Graphiti、Mem0。
8. Wiki-first + AI
由人维护 Markdown/Wiki/数据库页面，AI 负责搜索、摘要、链接建议和问答。
优势：可读、可编辑、治理边界清晰，适合长期知识沉淀。
不足：整理成本由人承担；若缺少同步和治理，容易过期。
适用：个人 PKM、团队规范、项目文档和决策记录。
代表：Obsidian、Notion、Outline、Confluence；可外挂 Dify/RAGFlow/LlamaIndex 或 GBrain。
9. 企业搜索与权限感知知识库
重点是连接 SaaS/文件系统、沿用源系统 ACL、统一搜索和生成式回答。
优势：连接器、权限同步、审计和企业治理较成熟。
不足：价格高、定制受限、数据与供应商锁定明显。
适用：数据分散在 Google Drive、Microsoft 365、Slack、Jira、Confluence 等系统的大中型组织。
代表：Glean、Microsoft 365 Copilot、Google Agentspace/Vertex AI Search、Elastic AI Assistant 类方案。
主流开源平台对比
| 方案 | 主要定位 | 突出优势 | 主要短板 | 更适合 |
|---|---|---|---|---|
| Dify | LLM 应用与工作流平台 | UI 完整、模型与应用编排丰富、知识库易接入 | 深度检索治理和复杂解析不如专项系统 | 快速构建业务 AI 应用 |
| RAGFlow | 文档理解与 RAG 平台 | 复杂文档解析、可视化切分、引用和检索链较强 | 部署资源较重，组件较多 | PDF、表格、报告密集知识库 |
| FastGPT | 中文场景知识库与工作流 | 上手快、中文社区、可视化编排 | 深层知识治理和图谱能力有限 | 中文客服、内部问答、流程应用 |
| MaxKB | 企业知识库问答 | 部署和使用相对简单，中文友好 | 高级检索与扩展生态相对有限 | 中小团队快速私有化 |
| AnythingLLM | 桌面/自托管文档聊天 | 安装简单、模型和向量库选择多 | 大规模治理、复杂权限与评测较弱 | 个人、小团队、本地问答 |
| Quivr | AI 第二大脑/文档问答 | 产品化体验和多资料输入 | 深度定制与企业治理需评估 | 个人或轻量团队知识助手 |
| LlamaIndex | 数据与 RAG 开发框架 | 索引、检索器、Agent 与数据连接抽象丰富 | 需要工程开发，不是开箱成品 | 定制复杂 RAG |
| LangChain/LangGraph | LLM/Agent 编排框架 | 生态广、工作流和状态机能力强 | 抽象变化快，检索质量需自行设计 | 自研 Agentic RAG |
| Haystack | 检索与 NLP Pipeline 框架 | 组件化、测试与生产 Pipeline 思路清晰 | 成品 UI 和知识管理体验有限 | 后端工程团队自研 |
| Microsoft GraphRAG | 图谱增强研究方案 | 全局主题、社区摘要和关系问题 | 索引成本高、链路复杂 | 高价值关系型语料研究 |
| LightRAG | 轻量图谱 RAG | 相比完整 GraphRAG 更轻，兼顾局部与全局检索 | 图质量与真实规模表现需实测 | 希望低成本尝试 GraphRAG |
| GBrain | Agent 知识运行时 | Markdown/Git、混合检索、图、综合与持续维护一体 | 系统复杂、自动回写和运维要求高 | 长期个人/团队 Agent 知识 |
表格边界
开源项目迭代很快，“支持某能力”不等于默认效果良好。文档解析、中文召回、权限隔离、增量更新和引用正确率必须用自己的数据验证。
托管方案对比
| 类型 | 代表 | 优势 | 代价与风险 |
|---|---|---|---|
| 模型厂商托管检索 | OpenAI File Search、Azure AI Search 集成、Vertex AI RAG/Search | 接入快、与模型生态整合好 | 可控性较低、费用和数据驻留需评估 |
| 托管向量数据库 | Pinecone、Weaviate Cloud、Qdrant Cloud、Zilliz Cloud | 扩缩容、备份和高可用省心 | 仍需自建解析、权限、生成与评测层 |
| 企业统一搜索 | Glean、Microsoft 365 Copilot、Google Agentspace | 连接器、ACL、组织部署成熟 | 价格高、供应商锁定、定制边界明显 |
| SaaS Wiki + AI | Notion AI、Confluence/Rovo | 与现有内容和权限直接结合 | 跨系统检索、模型控制和可迁移性有限 |
关键能力横向比较
评分为相对趋势：低、中、高；实际结果取决于实现。
| 路线 | 上手 | 精确检索 | 语义检索 | 多跳关系 | 持续维护 | 权限治理 | 成本/复杂度 |
|---|---|---|---|---|---|---|---|
| 全文检索 | 高 | 高 | 低 | 低 | 中 | 高 | 低 |
| 基础向量 RAG | 高 | 中低 | 高 | 低 | 低 | 中 | 低中 |
| 混合 RAG + reranker | 中 | 高 | 高 | 中低 | 中 | 中高 | 中 |
| GraphRAG | 低 | 高 | 高 | 高 | 中低 | 中 | 高 |
| Agentic RAG | 中低 | 高 | 高 | 高 | 中 | 中 | 高 |
| 长期记忆/GBrain | 中低 | 高 | 高 | 高 | 高 | 中高 | 高 |
| Wiki-first + AI | 中 | 高 | 中高 | 中 | 高（依赖人） | 高 | 中 |
| 企业搜索 SaaS | 高 | 高 | 高 | 中 | 高 | 高 | 高费用 |
选型决策
只需查找原文？
├─ 是 → 全文检索/BM25
└─ 否，需要生成答案
├─ 普通文档问答 → 混合 RAG + reranker
├─ PDF/表格解析是核心 → RAGFlow 或专项解析管线
├─ 关系/多跳问题很多 → GraphRAG 或显式关系图 + 混合 RAG
├─ Agent 需要长期记忆和主动维护 → GBrain/Letta/Zep
├─ 人是知识维护主体 → Obsidian/Notion/Outline + RAG
└─ 多系统 ACL 与企业治理优先 → 企业搜索/托管方案推荐的基线架构
对于多数组织，不应直接从复杂 GraphRAG 或 Agentic RAG 起步。一个稳健基线是：
- 保留原始文档和稳定的
document_id/version/ACL。 - 使用结构感知解析和父子分块，而非只按固定字符切分。
- BM25 与向量并行召回，使用 RRF 融合。
- 对候选结果做 metadata/ACL 过滤和 reranker 精排。
- 回答必须带页码、段落或原文链接，并支持打开来源。
- 建立离线问题集，持续测 Recall@K、MRR/nDCG、引用正确率和答案忠实度。
- 只有在多跳问题确有失败证据后，再增加图谱或 Agent 循环。
常见误区
- 只比较 LLM，不评估解析、分块和召回。
- 用“回答看起来不错”代替引用正确率和检索指标。
- 在检索后才做权限过滤，造成越权信息进入上下文。
- 每次更新全量重建索引，没有版本、删除和增量同步策略。
- 为追求 GraphRAG 概念而构建低质量实体图。
- 让 Agent 自动回写权威知识，却没有审阅、来源和回滚机制。
针对当前 Obsidian Vault 的建议
推荐采用渐进式组合，而不是一次迁移到单一平台：
- 事实源：继续使用 Obsidian Markdown + Git，不改变现有 WikiLinks 和目录体系。
- 第一阶段：建立 BM25 + 向量 + reranker 的只读混合 RAG 基线。
- 第二阶段：利用现有 WikiLinks 形成显式知识图，重点测试跨项目、人物和概念问题。
- 第三阶段：用 GBrain 试验 Agent 接入、Compiled Truth 和维护周期，但默认写入隔离库。
- 敏感数据：排除
个人信息/，Embedding 与生成模型优先本地或使用明确的数据保留政策。 - 最终选型：依据自建评测集，而不是 README 功能数量决定。
参考资料
- Dify
- RAGFlow
- FastGPT
- MaxKB
- AnythingLLM
- LlamaIndex
- LangChain
- Haystack
- Microsoft GraphRAG
- LightRAG
- Neo4j GraphRAG
- Letta
- Zep/Graphiti
- Mem0
- GBrain