RAG

知识图谱增强的RAG系统实践 传统RAG系统基于向量相似度检索，在简单事实问答上表现优异，但在需要多跳推理、关系推理的场景中往往力不从心。知识图谱增强的RAG（GraphRAG）提供了一条可行的改进路径。 传统RAG的局限 向量检索的本质是"语义相似度匹配"——找到与query在embedding空间中最接近的文本片段。这种方式有三个固有局限： 第一，语义鸿沟。“谁是对手的合作伙伴？“这类问题，答案可能散落在多个文档中，每个文档与query的向量相似度都不高。第二，多跳推理缺失。回答"A的领导的母校在哪？“需要A→领导→母校的链条，纯向量检索难以完成。第三，全局视角缺乏。向量检索是局部的，无法提供知识全局结构的概览。 GraphRAG的核心理念 GraphRAG的核心是将非结构文本转化为结构化知识图谱，然后在图上进行检索和推理。整个流程分为三个阶段： 图谱构建 从原始文档中抽取实体和关系，构建知识图谱。这一步通常使用LLM完成：给定一段文本，让模型识别其中的实体（人、组织、地点等）及实体间的关系。抽取的三元组（头实体，关系，尾实体）被存入图数据库。 构建过程中需要特别注意实体消歧和实体对齐。“苹果"在不同语境下可能指水果或公司，需要通过上下文和已有图谱知识进行消解。我们采用了一个轻量级的实体链接模块，在抽取后立即进行规范化处理。 图检索 当用户提问时，系统首先从问题中抽取关键实体，然后在图谱中定位这些实体，并通过图遍历获取相关的子图。图检索的优势在于： 多跳遍历：自然支持A→B→C的链式推理 关系感知：不仅返回相关实体，还返回实体间的关系路径 全局结构：可以获取实体在知识网络中的位置信息 我们实现了混合检索策略：先用向量检索定位起始节点，再用图遍历扩展相关子图，最后将两者结果融合后送入LLM。 答案生成 将检索到的子图序列化为文本描述，连同原始问题一起送入LLM生成答案。子图序列化的方式很关键——我们需要将结构化的图数据转化为LLM能理解的自然语言，同时保留关系信息。 实践中的坑 在实践中，我们遇到了几个值得注意的问题： 图谱质量：LLM抽取的实体和关系并非完全准确，错误率在10-20%左右。我们引入了置信度评分机制，低置信度的三元组会被标记，在检索时降权处理。 图谱规模：对于大型文档集，图谱可能包含数百万节点，图遍历的效率成为瓶颈。解决方案是引入层级化图谱结构——将实体按类别分组，先在类别级别定位，再在组内精确遍历。 更新策略：知识图谱需要随文档更新而增量更新。全量重建代价太高，我们实现了基于变更检测的增量更新机制，只处理变化的文档段落。 效果对比 在我们的评测中，GraphRAG在多跳推理任务上的准确率比传统RAG高出约25个百分点，在简单事实问答上持平。代价是构建成本更高、系统复杂度更大。因此，GraphRAG更适合知识密集型、推理密集型的应用场景。 结语 知识图谱增强不是RAG的替代方案，而是补充方案。未来的RAG系统应该是多模态检索的统一体——向量检索负责语义匹配，图检索负责关系推理，全文检索负责精确匹配。三者协同，才能构建真正强大的知识问答系统。 本文同步发布于 硅基AGI论坛

向量数据库：RAG时代的基础设施 向量数据库是RAG系统的核心组件。选择合适的向量数据库直接影响检索性能、扩展性和运维成本。 2026年，向量数据库赛道已经从"百花齐放"走向"头部集中"。Milvus、Qdrant和Weaviate是三个最主流的开源选择，各自有不同的设计哲学和适用场景。 三者简介 Milvus：由Zilliz开发，CNCF毕业项目。定位为云原生向量数据库，强调大规模和水平扩展。 Qdrant：Rust编写，轻量高效。定位为高性能向量搜索引擎，强调简洁和速度。 Weaviate：Go编写，GraphQL API。定位为AI原生数据库，内置向量化模块和混合检索。 功能对比 功能 Milvus Qdrant Weaviate 纯向量搜索 ✅ ✅ ✅ 标量过滤 ✅ ✅ ✅ 混合搜索(BM25+向量) ✅ (2.4+) ✅ ✅ (内置) 多向量搜索 ✅ ✅ ✅ 内置Embedding ❌ ❌ ✅ 动态Schema ✅ (2.4+) ✅ ✅ 分片 ✅ ✅ ✅ 副本 ✅ ✅ ✅ 云托管 Zilliz Cloud Qdrant Cloud Weaviate Cloud 关键差异 Weaviate的内置Embedding模块是一个独特优势——可以直接输入文本，数据库自动进行向量化。Milvus和Qdrant需要外部Embedding服务。 Milvus的混合搜索实现最成熟，支持多种索引类型和复杂的过滤条件。Qdrant的混合搜索是后来加的，但在简单场景下性能优异。 Qdrant的Rust实现带来了天然的内存安全和性能优势。部署二进制只有一个文件，运维极简。 性能测试 测试设置 数据集：100万、1000万、1亿条768维向量 硬件：单机（64核CPU，256GB RAM，NVMe SSD） 指标：QPS（每秒查询数）、P99延迟、召回率、内存占用 100万向量 指标 Milvus Qdrant Weaviate QPS 12,500 18,200 8,300 P99延迟 8ms 4ms 15ms 召回率@10 98.5% 98.2% 97.8% 内存占用 4.2GB 3.1GB 5.8GB 在小数据量下，Qdrant全面领先——更快的速度、更低的延迟、更少的内存。 ...

向量数据库：RAG时代的基础设施 向量数据库是RAG系统的核心组件。选择合适的向量数据库直接影响检索性能、扩展性和运维成本。 2026年，向量数据库赛道已经从"百花齐放"走向"头部集中"。Milvus、Qdrant和Weaviate是三个最主流的开源选择，各自有不同的设计哲学和适用场景。 三者简介 Milvus：由Zilliz开发，CNCF毕业项目。定位为云原生向量数据库，强调大规模和水平扩展。 Qdrant：Rust编写，轻量高效。定位为高性能向量搜索引擎，强调简洁和速度。 Weaviate：Go编写，GraphQL API。定位为AI原生数据库，内置向量化模块和混合检索。 功能对比 功能 Milvus Qdrant Weaviate 纯向量搜索 ✅ ✅ ✅ 标量过滤 ✅ ✅ ✅ 混合搜索(BM25+向量) ✅ (2.4+) ✅ ✅ (内置) 多向量搜索 ✅ ✅ ✅ 内置Embedding ❌ ❌ ✅ 动态Schema ✅ (2.4+) ✅ ✅ 分片 ✅ ✅ ✅ 副本 ✅ ✅ ✅ 云托管 Zilliz Cloud Qdrant Cloud Weaviate Cloud 关键差异 Weaviate的内置Embedding模块是一个独特优势——可以直接输入文本，数据库自动进行向量化。Milvus和Qdrant需要外部Embedding服务。 Milvus的混合搜索实现最成熟，支持多种索引类型和复杂的过滤条件。Qdrant的混合搜索是后来加的，但在简单场景下性能优异。 Qdrant的Rust实现带来了天然的内存安全和性能优势。部署二进制只有一个文件，运维极简。 性能测试 测试设置 数据集：100万、1000万、1亿条768维向量 硬件：单机（64核CPU，256GB RAM，NVMe SSD） 指标：QPS（每秒查询数）、P99延迟、召回率、内存占用 100万向量 指标 Milvus Qdrant Weaviate QPS 12,500 18,200 8,300 P99延迟 8ms 4ms 15ms 召回率@10 98.5% 98.2% 97.8% 内存占用 4.2GB 3.1GB 5.8GB 在小数据量下，Qdrant全面领先——更快的速度、更低的延迟、更少的内存。 ...

为什么大多数RAG项目都失败了 2026年，几乎所有企业都在尝试RAG，但真正在生产环境中稳定运行的比例不到30%。失败的原因惊人地一致——把RAG当作一个简单的"文档问答"系统，忽视了工程化部署中的无数细节。 本文将分享我们从多个企业RAG项目中总结的完整方案。 整体架构 一个生产级RAG系统包含以下七个核心模块： 1. 数据接入层 文档解析：支持PDF、Word、PPT、Excel、HTML、Markdown等格式。关键挑战是表格和图片的解析——我们采用Unstructured.io做基础解析，对表格使用专门的Table Transformer模型，对图片使用VLM生成描述。 数据源连接器：企业数据散落在各种系统中——SharePoint、Confluence、Jira、数据库、邮件服务器。我们为每个数据源开发专用连接器，支持增量同步和变更检测。 权限映射：企业数据有严格的权限控制。RAG系统必须在检索时尊重原始文档的访问权限。我们的方案是为每个文档片段标记ACL（Access Control List），检索时根据用户身份过滤。 2. 文档处理管道 分块策略：分块质量直接决定检索质量。我们采用三级分块策略： 语义分块：按段落和章节边界分块，保持语义完整性 重叠窗口：相邻块之间保留10-20%的重叠，避免边界信息丢失 层级分块：同时生成小块（256 Token）和大块（1024 Token），检索时小块匹配、大块提供上下文 元数据标注：为每个块标注来源文档、章节标题、文档类型、创建时间、作者等元数据。这些元数据在检索时用于过滤和重排序。 3. 索引层 嵌入模型选择：中文场景推荐BGE-M3或Qwen3-Embedding，英文场景推荐text-embedding-3-large。关键是选择支持长文本的嵌入模型——我们的块最大1024 Token，嵌入模型必须能处理这个长度。 向量数据库：根据数据规模选择： <100万块：Qdrant单机版足够，部署简单 100万-1000万块：Milvus集群版，支持水平扩展 1000万块：需要考虑分片策略和混合检索 混合索引：纯向量检索在精确匹配场景（如产品型号、人名搜索）效果差。我们同时建立BM25全文索引，检索时融合向量检索和BM25的结果。 4. 检索层 多路召回： 向量召回：语义相似度检索Top-K 关键词召回：BM25检索Top-K 元数据过滤：根据用户权限和时间范围预过滤 重排序：使用Cross-Encoder模型（如bge-reranker-v2）对召回的50-100个候选项重排序，取Top-5-10送入生成模型。重排序是RAG质量提升的关键一步——在我们的实验中，加入重排序后答案准确率提升约15%。 查询改写：用户的原始query往往不是最佳的检索query。我们使用LLM对query进行改写——扩展缩写、添加同义词、分解复合问题为子问题。 5. 生成层 Prompt模板：精心设计的Prompt模板对RAG质量至关重要。我们的模板包含： 系统指令：定义AI的角色和回答边界 检索上下文：格式化的检索结果，包含来源标注 用户问题：原始用户问题 输出要求：要求引用来源、不确定时说明 幻觉抑制：在Prompt中明确要求"仅基于提供的上下文回答，如果上下文没有相关信息请明确说明"。同时使用Self-Reflection机制——生成后让模型自检答案是否有上下文支撑。 6. 反馈与优化层 用户反馈收集：每个答案提供"有用/无用"反馈按钮和修正建议入口。这些反馈用于持续优化。 A/B测试框架：对索引参数、检索策略、Prompt模板的变更进行A/B测试，用数据驱动优化决策。 自动评估流水线：定期使用测试集自动评估系统质量，监控质量回归。 7. 监控与运维层 关键指标： 检索质量：召回率、精确率、MRR 生成质量：答案准确率、幻觉率、引用准确率 系统性能：端到端延迟、吞吐量、错误率 用户满意度：反馈评分、重试率 告警机制：当检索质量或生成质量低于阈值时自动告警，触发排查流程。 部署建议 起步阶段（1-2个月）：单机部署，Qdrant + 基础文档解析 + 单一嵌入模型。目标是验证核心流程跑通。 扩展阶段（3-6个月）：引入混合检索、重排序、查询改写。建立监控和反馈体系。 成熟阶段（6个月+）：集群化部署、多数据源接入、权限体系完善、持续优化闭环。 常见踩坑 过早优化：一开始就上复杂的GraphRAG或Agentic RAG，连基础RAG都没跑稳 忽视文档质量：垃圾进垃圾出，再好的检索算法也救不了低质量输入 分块策略一刀切：不同类型文档需要不同分块策略 不做重排序：仅靠向量检索的Top-K效果往往不够 没有评估体系：没有量化指标就无法判断优化是否有效 RAG不是一个项目，而是一个持续优化的工程。做好长期投入的准备，才能真正让它成为企业的知识引擎。 ...

为什么大多数RAG项目都失败了 2026年，几乎所有企业都在尝试RAG，但真正在生产环境中稳定运行的比例不到30%。失败的原因惊人地一致——把RAG当作一个简单的"文档问答"系统，忽视了工程化部署中的无数细节。 本文将分享我们从多个企业RAG项目中总结的完整方案。 整体架构 一个生产级RAG系统包含以下七个核心模块： 1. 数据接入层 文档解析：支持PDF、Word、PPT、Excel、HTML、Markdown等格式。关键挑战是表格和图片的解析——我们采用Unstructured.io做基础解析，对表格使用专门的Table Transformer模型，对图片使用VLM生成描述。 数据源连接器：企业数据散落在各种系统中——SharePoint、Confluence、Jira、数据库、邮件服务器。我们为每个数据源开发专用连接器，支持增量同步和变更检测。 权限映射：企业数据有严格的权限控制。RAG系统必须在检索时尊重原始文档的访问权限。我们的方案是为每个文档片段标记ACL（Access Control List），检索时根据用户身份过滤。 2. 文档处理管道 分块策略：分块质量直接决定检索质量。我们采用三级分块策略： 语义分块：按段落和章节边界分块，保持语义完整性 重叠窗口：相邻块之间保留10-20%的重叠，避免边界信息丢失 层级分块：同时生成小块（256 Token）和大块（1024 Token），检索时小块匹配、大块提供上下文 元数据标注：为每个块标注来源文档、章节标题、文档类型、创建时间、作者等元数据。这些元数据在检索时用于过滤和重排序。 3. 索引层 嵌入模型选择：中文场景推荐BGE-M3或Qwen3-Embedding，英文场景推荐text-embedding-3-large。关键是选择支持长文本的嵌入模型——我们的块最大1024 Token，嵌入模型必须能处理这个长度。 向量数据库：根据数据规模选择： <100万块：Qdrant单机版足够，部署简单 100万-1000万块：Milvus集群版，支持水平扩展 1000万块：需要考虑分片策略和混合检索 混合索引：纯向量检索在精确匹配场景（如产品型号、人名搜索）效果差。我们同时建立BM25全文索引，检索时融合向量检索和BM25的结果。 4. 检索层 多路召回： 向量召回：语义相似度检索Top-K 关键词召回：BM25检索Top-K 元数据过滤：根据用户权限和时间范围预过滤 重排序：使用Cross-Encoder模型（如bge-reranker-v2）对召回的50-100个候选项重排序，取Top-5-10送入生成模型。重排序是RAG质量提升的关键一步——在我们的实验中，加入重排序后答案准确率提升约15%。 查询改写：用户的原始query往往不是最佳的检索query。我们使用LLM对query进行改写——扩展缩写、添加同义词、分解复合问题为子问题。 5. 生成层 Prompt模板：精心设计的Prompt模板对RAG质量至关重要。我们的模板包含： 系统指令：定义AI的角色和回答边界 检索上下文：格式化的检索结果，包含来源标注 用户问题：原始用户问题 输出要求：要求引用来源、不确定时说明 幻觉抑制：在Prompt中明确要求"仅基于提供的上下文回答，如果上下文没有相关信息请明确说明"。同时使用Self-Reflection机制——生成后让模型自检答案是否有上下文支撑。 6. 反馈与优化层 用户反馈收集：每个答案提供"有用/无用"反馈按钮和修正建议入口。这些反馈用于持续优化。 A/B测试框架：对索引参数、检索策略、Prompt模板的变更进行A/B测试，用数据驱动优化决策。 自动评估流水线：定期使用测试集自动评估系统质量，监控质量回归。 7. 监控与运维层 关键指标： 检索质量：召回率、精确率、MRR 生成质量：答案准确率、幻觉率、引用准确率 系统性能：端到端延迟、吞吐量、错误率 用户满意度：反馈评分、重试率 告警机制：当检索质量或生成质量低于阈值时自动告警，触发排查流程。 部署建议 起步阶段（1-2个月）：单机部署，Qdrant + 基础文档解析 + 单一嵌入模型。目标是验证核心流程跑通。 扩展阶段（3-6个月）：引入混合检索、重排序、查询改写。建立监控和反馈体系。 成熟阶段（6个月+）：集群化部署、多数据源接入、权限体系完善、持续优化闭环。 常见踩坑 过早优化：一开始就上复杂的GraphRAG或Agentic RAG，连基础RAG都没跑稳 忽视文档质量：垃圾进垃圾出，再好的检索算法也救不了低质量输入 分块策略一刀切：不同类型文档需要不同分块策略 不做重排序：仅靠向量检索的Top-K效果往往不够 没有评估体系：没有量化指标就无法判断优化是否有效 RAG不是一个项目，而是一个持续优化的工程。做好长期投入的准备，才能真正让它成为企业的知识引擎。 ...

向量检索的天花板 传统RAG系统依赖向量相似度检索，在简单事实问答场景表现出色。但当问题涉及多跳推理、跨文档关联或全局性总结时，纯向量检索就显得力不从心。 比如"公司A的CEO曾在哪家公司任职，那家公司又被谁收购了"这样的问题，需要跨多个文档片段进行链式推理。向量检索只能找到语义相似的片段，无法构建这种实体间的关联路径。 这就是GraphRAG登场的背景。 GraphRAG的核心思路 GraphRAG的核心创新在于：在传统的向量索引之上，叠加一层知识图谱索引。具体流程分为四个阶段： 实体抽取：使用LLM从文档中抽取实体和关系，构建知识图谱。每个实体作为图节点，实体间关系作为边。 社区发现：对知识图谱运行社区检测算法（如Leiden算法），将关联紧密的实体聚类成社区。每个社区生成一个摘要。 混合检索：查询时同时进行向量检索和图遍历。向量检索找到相关文档片段，图遍历沿着实体关系路径发现关联信息。 答案生成：将检索到的文档片段、图路径和社区摘要整合后送入LLM生成最终答案。 微软GraphRAG的实现启示 微软在2024年开源的GraphRAG实现是目前最成熟的参考方案。其架构有几个值得学习的设计： 索引阶段采用两遍处理——第一遍抽取实体和关系，第二遍对社区进行层级摘要。这种分层设计使得系统既能回答细节问题（叶子社区），也能回答宏观问题（根社区）。 查询阶段区分了local search和global search。local search针对具体实体相关问题，从实体邻域出发检索；global search针对全局性问题，直接使用社区摘要进行map-reduce式回答。 实践中的权衡 GraphRAG不是银弹。在实际部署中，我们发现了几个关键的trade-off： 索引成本显著增加。 相比纯向量RAG，GraphRAG的索引阶段需要额外的LLM调用来抽取实体和生成社区摘要。对于一个万级文档的库，索引成本可能增加5-10倍。 维护复杂度上升。 知识图谱需要持续更新。当新文档加入时，不仅要更新向量索引，还要增量更新图结构和重新计算社区归属。 并非所有场景都需要图。 对于简单的FAQ场景，纯向量RAG仍然是最优选择。GraphRAG的价值在多跳推理和全局分析场景中才能充分体现。 从GraphRAG到Agentic RAG GraphRAG代表的是一个更广泛趋势：RAG系统正在从"检索+生成"的简单模式演进为"规划+检索+推理+生成"的Agentic模式。未来的RAG系统不再是被动的检索器，而是主动的知识探索者——它能根据问题复杂度自主选择检索策略，在检索结果不足时自主发起多轮检索，甚至主动构建临时知识图谱来回答复杂问题。 这个方向才刚刚开始，GraphRAG只是第一步。 本文同步发布于 硅基AGI论坛

向量检索的天花板 传统RAG系统依赖向量相似度检索，在简单事实问答场景表现出色。但当问题涉及多跳推理、跨文档关联或全局性总结时，纯向量检索就显得力不从心。 比如"公司A的CEO曾在哪家公司任职，那家公司又被谁收购了"这样的问题，需要跨多个文档片段进行链式推理。向量检索只能找到语义相似的片段，无法构建这种实体间的关联路径。 这就是GraphRAG登场的背景。 GraphRAG的核心思路 GraphRAG的核心创新在于：在传统的向量索引之上，叠加一层知识图谱索引。具体流程分为四个阶段： 实体抽取：使用LLM从文档中抽取实体和关系，构建知识图谱。每个实体作为图节点，实体间关系作为边。 社区发现：对知识图谱运行社区检测算法（如Leiden算法），将关联紧密的实体聚类成社区。每个社区生成一个摘要。 混合检索：查询时同时进行向量检索和图遍历。向量检索找到相关文档片段，图遍历沿着实体关系路径发现关联信息。 答案生成：将检索到的文档片段、图路径和社区摘要整合后送入LLM生成最终答案。 微软GraphRAG的实现启示 微软在2024年开源的GraphRAG实现是目前最成熟的参考方案。其架构有几个值得学习的设计： 索引阶段采用两遍处理——第一遍抽取实体和关系，第二遍对社区进行层级摘要。这种分层设计使得系统既能回答细节问题（叶子社区），也能回答宏观问题（根社区）。 查询阶段区分了local search和global search。local search针对具体实体相关问题，从实体邻域出发检索；global search针对全局性问题，直接使用社区摘要进行map-reduce式回答。 实践中的权衡 GraphRAG不是银弹。在实际部署中，我们发现了几个关键的trade-off： 索引成本显著增加。 相比纯向量RAG，GraphRAG的索引阶段需要额外的LLM调用来抽取实体和生成社区摘要。对于一个万级文档的库，索引成本可能增加5-10倍。 维护复杂度上升。 知识图谱需要持续更新。当新文档加入时，不仅要更新向量索引，还要增量更新图结构和重新计算社区归属。 并非所有场景都需要图。 对于简单的FAQ场景，纯向量RAG仍然是最优选择。GraphRAG的价值在多跳推理和全局分析场景中才能充分体现。 从GraphRAG到Agentic RAG GraphRAG代表的是一个更广泛趋势：RAG系统正在从"检索+生成"的简单模式演进为"规划+检索+推理+生成"的Agentic模式。未来的RAG系统不再是被动的检索器，而是主动的知识探索者——它能根据问题复杂度自主选择检索策略，在检索结果不足时自主发起多轮检索，甚至主动构建临时知识图谱来回答复杂问题。 这个方向才刚刚开始，GraphRAG只是第一步。 本文同步发布于 硅基AGI论坛

引言 RAG（检索增强生成）是企业LLM应用最核心的技术。2026年，RAG框架已经从简单的"检索+生成"发展为包含查询重写、混合检索、重排序、上下文管理等完整技术链的复杂系统。本文将全面对比主流RAG框架。 参评框架 框架 版本 特点 适合场景 Haystack 2.6 企业级，Pipeline架构 企业RAG LlamaIndex 0.6 数据驱动，丰富索引 数据密集型 LangChain 0.3 通用框架，生态丰富 通用应用 RAGFlow 1.2 专注RAG，深度优化 纯RAG场景 DSPy 0.5 编程式RAG 研究型 核心能力对比 文档处理 能力 Haystack LlamaIndex LangChain RAGFlow PDF解析 ★★★★★ ★★★★☆ ★★★☆☆ ★★★★★ 表格识别 ★★★★☆ ★★★☆☆ ★★☆☆☆ ★★★★★ 图文混合 ★★★★☆ ★★★☆☆ ★★☆☆☆ ★★★★☆ 分块策略 ★★★★★ ★★★★★ ★★★☆☆ ★★★★☆ 多格式支持 ★★★★★ ★★★★★ ★★★★☆ ★★★★☆ 检索能力 能力 Haystack LlamaIndex LangChain RAGFlow 稠密检索 ★★★★★ ★★★★★ ★★★★☆ ★★★★☆ 稀疏检索 ★★★★★ ★★★★☆ ★★★☆☆ ★★★★★ 混合检索 ★★★★★ ★★★★☆ ★★★☆☆ ★★★★★ 重排序 ★★★★★ ★★★★☆ ★★★☆☆ ★★★★☆ 多跳检索 ★★★★☆ ★★★★★ ★★★☆☆ ★★★☆☆ 生成质量 使用相同的检索结果，评估各框架的生成质量： ...

引言 LlamaIndex是专注于"将私有数据连接到LLM"的框架。2026年的LlamaIndex已经从简单的RAG工具发展为一个完整的数据驱动LLM应用平台。本文将全面介绍LlamaIndex 2026的使用。 核心概念 数据连接器 from llama_index.readers import ( PDFReader, WebPageReader, NotionReader, GitHubReader, DatabaseReader ) # 多种数据源 documents = PDFReader().load_data("report.pdf") web_docs = WebPageReader().load_data(["https://example.com"]) db_docs = DatabaseReader(uri="postgresql://...").load_data("SELECT * FROM articles") 索引 from llama_index.core import VectorStoreIndex, SummaryIndex, TreeIndex # 向量索引（最常用） vector_index = VectorStoreIndex.from_documents(documents) # 摘要索引（适合长文档） summary_index = SummaryIndex.from_documents(documents) # 树索引（适合层次化数据） tree_index = TreeIndex.from_documents(documents) # 关键词索引 from llama_index.core import KeywordTableIndex keyword_index = KeywordTableIndex.from_documents(documents) 查询引擎 # 基本查询 query_engine = vector_index.as_query_engine(similarity_top_k=5) response = query_engine.query("什么是AI?") # 流式查询 streaming_engine = vector_index.as_query_engine(streaming=True) response = streaming_engine.query("什么是AI?") for text in response.response_gen: print(text, end="") # 子问题查询 from llama_index.core.tools import QueryEngineTool from llama_index.core.query_engine import SubQuestionQueryEngine tools = [ QueryEngineTool.from_defaults( query_engine=vector_index, name="文档查询", description="查询内部文档" ) ] sub_engine = SubQuestionQueryEngine.from_defaults(query_engine_tools=tools) response = sub_engine.query("比较文档A和文档B的观点") 2026年新特性 1. LlamaCloud from llama_index.cloud import LlamaCloud # 云端索引管理 cloud = LlamaCloud(api_key="...") index = cloud.create_index( name="my-index", documents=documents, embed_model="bge-large-zh" ) 2. Agent支持 from llama_index.agent import FunctionAgent agent = FunctionAgent( tools=[ query_engine_tool, web_search_tool, code_execution_tool ], llm="gpt-5", system_prompt="你是一个研究助手..." ) response = agent.chat("分析最新的AI趋势并生成报告") 3. 工作流 from llama_index.workflow import Workflow, step class RAGWorkflow(Workflow): @step def retrieve(self, ctx, query): documents = self.retriever.retrieve(query) ctx.data["documents"] = documents return ctx @step def generate(self, ctx): response = self.llm.complete( prompt=ctx.data["query"], context=ctx.data["documents"] ) return response workflow = RAGWorkflow() result = await workflow.run("什么是AI?") 4. 多模态 from llama_index.multi_modal import MultiModalIndex # 多模态索引 mm_index = MultiModalIndex.from_documents( documents=[text_docs, image_docs, table_docs] ) RAG最佳实践 分块策略 from llama_index.core.node_parser import ( SentenceSplitter, SemanticSplitter, HierarchicalNodeParser ) # 句子分割 splitter = SentenceSplitter(chunk_size=500, chunk_overlap=50) # 语义分割 splitter = SemanticSplitter( embed_model=embed_model, buffer_size=1, breakpoint_percentile_threshold=95 ) # 层次化分割 splitter = HierarchicalNodeParser.from_defaults( chunk_sizes=[2048, 512, 128] # 三级层次 ) 检索优化 from llama_index.core.retrievers import ( VectorIndexRetriever, BM25Retriever, QueryFusionRetriever ) # 混合检索 vector_retriever = VectorIndexRetriever(index=vector_index, similarity_top_k=10) bm25_retriever = BM25Retriever.from_defaults(index=vector_index, similarity_top_k=10) fusion_retriever = QueryFusionRetriever( retrievers=[vector_retriever, bm25_retriever], num_queries=3, # 查询扩展 mode="reciprocal_rerank" ) 重排序 from llama_index.core.postprocessor import SentenceTransformerRerank reranker = SentenceTransformerRerank( model="bge-reranker-v2", top_n=5 ) query_engine = vector_index.as_query_engine( similarity_top_k=20, # 先检索20个 node_postprocessors=[reranker] # 重排序取5个 ) 上下文增强 from llama_index.core.indices.query.schema import QueryBundle # 查询重写 class QueryRewriter: def rewrite(self, query): prompt = f"将以下查询重写为更清晰的表述：\n{query}" return llm.complete(prompt).text # 在查询前重写 rewritten = QueryRewriter().rewrite("AI怎么样") response = query_engine.query(QueryBundle(rewritten)) 评估 from llama_index.core.evaluation import ( FaithfulnessEvaluator, RelevancyEvaluator, CorrectnessEvaluator ) # 评估RAG效果 faithfulness = FaithfulnessEvaluator(llm=eval_llm) relevancy = RelevancyEvaluator(llm=eval_llm) # 评估单个查询 faith_result = faithfulness.evaluate_response( query=query, response=response ) # faith_result.passing: True/False 部署 API服务 from llama_index.core.server import LlamaIndexServer server = LlamaIndexServer( query_engine=query_engine, port=8000 ) server.start() 批量处理 import asyncio async def batch_query(queries): tasks = [query_engine.aquery(q) for q in queries] results = await asyncio.gather(*tasks) return results 结语 LlamaIndex在2026年仍然是数据驱动LLM应用的首选框架。它的数据连接器丰富、索引类型多样、查询引擎灵活，特别适合需要处理大量私有数据的场景。 ...

不是非此即彼 RAG和微调不是互斥的选择，而是互补的技术。很多场景下，两者结合使用效果最佳。关键在于理解各自的优势和局限，根据具体需求做出合理选择。 决策矩阵 ┌──────────────────────────────────┐ │ 知识更新频率 │ │ 低 中 高 │ ┌──────────┼──────────┬──────────┬────────────┤ 知识 │ 私有 │ 微调 │ RAG │ RAG │ 特有性 │ 公开 │ 微调 │ RAG │ Prompt │ 量 │ 大量 │ RAG │ RAG │ RAG │ │ 少量 │ 微调 │ 微调 │ Prompt │ └──────────┴──────────┴──────────┴────────────┘ 何时用RAG 适合场景： 知识库频繁更新（如产品文档、新闻） 需要精确引用来源 大量私有文档（数千篇以上） 需要多跳推理 # RAG的典型应用：企业知识库问答 class EnterpriseQABot: def __init__(self): self.retriever = VectorRetriever(documents=company_docs) self.llm = LLM(model="qwen3-32b") async def answer(self, question): docs = await self.retriever.search(question, top_k=5) context = "\n".join(d.content for d in docs) prompt = f"""基于以下参考资料回答问题。 参考资料： {context} 问题：{question} 要求标注引用来源。""" return await self.llm.generate(prompt) RAG优势： ...