LLM Wiki 与 RAG 海量知识检索调研总结
面向企业知识库、Agentic RAG、GraphRAG、Hybrid Search、评测、安全与生产治理的系统调研。
这份调研面向正在建设企业知识库、智能搜索、AI Agent 知识层、研发文档助手、客服知识库或内部 Wiki 的团队。结论先说：生产级 RAG 不是“向量数据库 + 大模型”的简单组合，而是一套围绕知识生命周期、检索质量、生成可信度、权限治理和持续评测构建的知识基础设施。
一句话判断
LLM Wiki 的核心价值不是让模型“知道更多”，而是让模型在回答时能够访问、理解、引用、审计和更新组织自己的知识。
如果系统不能回答“这段答案来自哪里、为什么检索到它、用户是否有权限看到它、这次回答是否比上个版本更好”，它还只是一个 RAG Demo，不是生产级知识系统。
技术全景
生产系统通常分成两条链路：离线或准实时索引链路，以及在线问答链路。离线链路决定知识是否干净、完整、可追溯；在线链路决定召回是否准确、上下文是否紧凑、回答是否可信；评测和观测链路决定系统是否能持续变好。
权威资料地图
| 方向 | 推荐资料 | 价值 |
|---|---|---|
| RAG 原始思想 | Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks | RAG 的经典起点，解释参数化记忆与外部知识索引的组合价值。 |
| RAG 系统综述 | Retrieval-Augmented Generation for Large Language Models: A Survey | 将 RAG 拆成 Naive、Advanced、Modular 三阶段，适合建立学习框架。 |
| 企业 RAG | Azure AI Search RAG overview | 讨论 query understanding、多源数据、token 约束、响应时间、安全治理和 agentic retrieval。 |
| GraphRAG | Microsoft GraphRAG Docs | 解释 TextUnit、实体关系抽取、社区发现、Global Search、Local Search、DRIFT Search。 |
| RAG 框架 | LlamaIndex RAG | 将 RAG 拆成 loading、indexing、storing、querying、evaluation 五个阶段。 |
| Agent 编排 | LangGraph | 适合复杂 RAG 工作流、状态机、人机协同、可恢复执行。 |
| 混合检索 | Elastic Hybrid Search | 解释 BM25、向量检索、稀疏检索和多路融合的工程价值。 |
| 向量数据库 | Milvus Docs、Qdrant Docs、Weaviate Docs、Pinecone Docs | 对比索引、过滤、多租户、混合检索、托管服务和生产运维能力。 |
| 评测 | Ragas、LangSmith Evaluation、Arize Phoenix | 覆盖 context precision、faithfulness、trace、dataset、LLM-as-judge 和回归实验。 |
| 安全治理 | OWASP Top 10 for LLM Applications、NIST AI RMF | 提供 prompt injection、敏感信息泄露、权限绕过、审计和风险管理框架。 |
关键趋势
从 Naive RAG 到 Modular RAG
最早的 RAG 常见链路是：文档切块、Embedding、Top-K 向量召回、拼上下文、调用 LLM。这个链路能快速验证想法，但在真实知识库里很容易失败：用户问题含糊、术语不匹配、文档结构复杂、权限要求严格、召回结果重复、上下文过长、引用不可靠。
新的工程共识是 Modular RAG：把 query rewrite、hybrid retrieval、router retriever、multi-query、reranker、context compression、citation、evaluation、observability 都变成可替换模块。系统质量不再依赖单个模型，而依赖完整链路的组合优化。
Hybrid Search 成为默认选项
只用向量检索会漏掉编号、代码、专有名词、产品名、政策条款和罕见词；只用 BM25 又无法处理同义表达和语义泛化。生产知识库更合理的默认方案是 BM25 + dense vector + sparse vector，再用 RRF、线性融合或学习排序做结果融合。
Reranker 是质量分水岭
第一阶段检索追求 recall，宁可多召回一些；第二阶段重排追求 precision，把真正能回答问题的证据放到前面。Reranker 的代价是延迟和成本，因此工程上常见做法是先召回 Top-50 或 Top-100，再重排到 Top-5 或 Top-10。
GraphRAG 解决全局理解和关系推理
GraphRAG 不应该被理解成“比向量 RAG 更高级的默认替代品”。它更适合跨文档综合、实体关系、多跳问题、组织网络、风险传播、主题归纳和全局总结。它的代价也明显：索引成本高、抽取误差会传播、增量更新复杂、查询路径更难调试。
Agentic RAG 从固定流水线变成动态策略
Agentic RAG 的价值在于让系统可以先理解问题，再决定是否检索、检索哪些数据源、拆成几个子问题、是否调用 SQL/Graph/API 工具、是否需要二次验证。Azure AI Search 的 agentic retrieval、LangGraph 的状态机编排、LlamaIndex 的 router 和 multi-step query 都在朝这个方向演进。
主要取舍
| 取舍 | 适合什么 | 风险 |
|---|---|---|
| RAG vs Fine-tuning | RAG 适合动态知识、引用、权限；微调适合风格、格式和任务习惯 | 把企业知识直接微调进模型会带来更新、权限和审计问题。 |
| 向量检索 vs BM25 | 向量适合语义相似，BM25 适合精确匹配 | 单一路线都容易漏召回。 |
| 大 Chunk vs 小 Chunk | 大 Chunk 保留上下文，小 Chunk 更精确 | 大 Chunk 噪声高，小 Chunk 容易断裂。 |
| GraphRAG vs 普通 RAG | GraphRAG 适合关系和全局问题，普通 RAG 适合局部事实问答 | GraphRAG 成本高，不适合所有场景。 |
| Agentic RAG vs 确定性流水线 | Agentic 灵活，确定性流水线稳定可控 | Agentic 更难评测、延迟更高、行为更不确定。 |
| LLM-as-judge vs 人工评测 | LLM 评测便宜快速，人工评测更可信 | LLM judge 有偏差，必须用人工样本校准。 |
生产级检查清单
- 数据源是否有负责人、更新时间、版本、权限和删除策略？
- 文档解析失败是否可见，是否有重试和人工修正入口？
- Chunk 是否保留标题层级、来源 URL、页码、锚点、权限元数据？
- 是否默认使用混合检索，而不是只用向量 Top-K？
- 是否记录 query rewrite、召回结果、重排分数、上下文包和最终答案？
- 是否支持按用户身份做 document-level security trimming？
- 是否有 golden dataset、bad case 归因和上线前回归评测？
- 是否能统计 P50/P95 延迟、token 成本、重排成本、向量库成本？
- 是否有 prompt injection、检索污染和敏感信息泄露防护？
- 是否有拒答机制，而不是证据不足时强行回答？
建议文章路线
- 《LLM Wiki 是什么：企业知识库为什么不能只是向量库 + 大模型》
- 《RAG 的真实架构：从文档摄取到可引用答案的完整链路》
- 《Naive RAG 为什么容易失败：召回、切分、上下文和幻觉的四类根因》
- 《Chunking 工程指南：如何切分 PDF、网页、表格、代码和长文档》
- 《Hybrid Retrieval 深度解析：BM25、向量检索、稀疏向量与 RRF 如何协同》
- 《Reranker 是 RAG 质量的分水岭：从召回优先到答案相关性优化》
- 《Query Rewriting 与 Multi-Query：让用户问题变成检索系统能理解的问题》
- 《向量数据库选型：Milvus、Qdrant、Pinecone、Weaviate、pgvector 与 Elastic 的工程取舍》
- 《GraphRAG 入门：为什么企业知识库需要实体、关系和社区摘要》
- 《RAG 评估体系：Context Precision、Recall、Faithfulness 和 Answer Relevancy 怎么用》
结论
RAG 的竞争点正在从“有没有接向量库”转向“有没有可运营的知识系统”。真正有价值的 LLM Wiki 应该同时具备五个能力：知识可更新、检索可解释、答案可引用、权限可治理、质量可评测。后续文章应该围绕这五个能力展开，而不是堆工具名和模板代码。
讨论
继续讨论这篇笔记
有问题、补充案例或不同观点，可以通过 GitHub Discussions 继续交流。